Bug 3167

Hi Roman,
this is a topic Slavek and I discussed long ago.

The messages are translated on master only, because it would be very messy to mix the two branches together for translations and we don't want the user to translate strings twice.
Translations of common strings are synced from master to R14.0.x, but strings only present in R14.0.x are basically not updated.
Each time we move to a new R14.x.0 release, strings will naturally sync.

Unfortunately for R14.1.0, the release time has been unbearably long due to poor planning in the years 2014-2017. We have a list of things we must complete before releasing that and it is going to take a while, but after that we will try to keep R14.x release cycle shorter, minimizing the translation issue too.

(In reply to Michele Calgaro from comment #1)
> this is a topic Slavek and I discussed long ago.
> 
> The messages are translated on master only, because it would be very messy
> to mix the two branches together for translations and we don't want the user
> to translate strings twice.

And do you want the user see constantly such untranslated messages on his work system?

> Unfortunately for R14.1.0, the release time has been unbearably long due to
> poor planning in the years 2014-2017. We have a list of things we must
> complete before releasing that and it is going to take a while, but after
> that we will try to keep R14.x release cycle shorter, minimizing the
> translation issue too.

So, I should translate the problematic PO-file directly and send it to branch R14.0.x... :/

In an other bug message I have told about wrong positioning of the project for such things...

I am commonly wonder why such kind of separation is provided for an established project and why do you disturbed about immediately changing that bad API?

If I want such sort of instability - flowing developing, I will use KDE. :)

And that project, I think and wait, must be targeted for flowing stabilisation - for USING, so the master branch must be the stable branch and all long term developing must be performed in separated branches. Otherwise you propose now a solution with yet many problems, more of whose already somewhere fixed but inaccessible and what are blocking of fixing other problems.

Created attachment 3002 [details]
Translation to Ukrainian of the stable branch mismatches with the master branch

Hi Roman, thanks for the patch. 
It currently partially failed against the latest R14.0.x sources.

checking file tde-i18n-uk/messages/tdebase/kate.po
checking file tde-i18n-uk/messages/tdebase/kicker.po
checking file tde-i18n-uk/messages/tdebase/ksmserver.po
checking file tde-i18n-uk/messages/tdebase/tdeio_media.po
Hunk #1 FAILED at 13.
Hunk #6 FAILED at 876.
2 out of 6 hunks FAILED

Can you please adjust and re submit? Again, if you create a PR on TGW on top of the current r14.0.x branch, it would make the process much simpler :-)

Created attachment 3003 [details]
Translation to Ukrainian of the stable branch mismatches with the master branch

(In reply to Michele Calgaro from comment #4)
> checking file tde-i18n-uk/messages/tdebase/kate.po
> checking file tde-i18n-uk/messages/tdebase/kicker.po
> checking file tde-i18n-uk/messages/tdebase/ksmserver.po
> checking file tde-i18n-uk/messages/tdebase/tdeio_media.po
> Hunk #1 FAILED at 13.
> Hunk #6 FAILED at 876.
> 2 out of 6 hunks FAILED

You can just remove those hunks.

> Can you please adjust and re submit? Again, if you create a PR on TGW on top
> of the current r14.0.x branch, it would make the process much simpler :-)

Sure, just after the patches won't be hung there also. :)

The last attachment cleared from such unprincipal hunks!

Merged to r14.0.x branch as commit 4080f0b3da. Thanks for sending the patch in.

IF no other objection, I will close this bug, since as I explain translations happen on master branch for the tiem being.

At the time the TWTW was being prepared, there was a need to decide how it would be integrated with the GIT repository. Here are some ways to deal with multiple branches.

1. Define all catalogs for all branches as separate components. This was immediately rejected because it would cause great clutter and, above all, the translators would have to translate practically everything twice.

2. Use master branch for translations. Because all strings to the stable branch normally come from the master branch, this seems like a good choice. At the same time, it was clear that we needed to be able to work on translating strings from the master branch so that users could translate the strings before the stable version was released.

3. Generate POT files so that they contain not only strings from the master branch, but also from the stable branch. Although this would be an ideal way, here are some technical issues to accomplish this.

Currently, the generation of POT files is perfectly integrated as CMake rules in individual modules (see CMakeL10n). It is easy to create, maintain, use and does not need any special external spells.

Generating POT files common to all branches would either require a special disk structure not usable for any activities other than generating POT files, while the existing CMakeL10n rules would then not be usable with the normal structure. Or POTs would have to be generated separately for all branches and then post-processing  would have to be performed to merge them into a single file, and the references to the source files would be modified to reference the files in the respective branches. So a lot of external spells would be needed.

While option 2 is very clear, easy to use, and the only external spell is to merge translations from the master branch to the stable branch, option 3 seems to be too complicated and takes a lot of effort to make it work. At the same time there are only a small number of strings that are in the stable branch and are no longer in the master branch. So it looks like a very unbalanced balance of effort and benefit.

Therefore, option 2 is used there. And translations of strings that are no longer part of the master branch must be done using pull requests in TGW.

Closing this bug off, after agreeing with Slavek. As he explained in detail, the current framework for translations is the best compromise between functionality and resource requirements.