Imported translations should override LP-done ones if there is no previous imported translation

[Данило Шеган]

When we are importing packaged translations, we should override LP-provided translation for a message if there is no previous imported translation.

Basically, most of the 'changed in LP' translations appear because Ubuntu translators do them in LP before upstreams do them (usually during their own 'string freezes', which happen in the middle of Ubuntu cycles). So, these changes are not intentional, but rather inadvertent changes from upstream which we later keep. By checking for existence of previous imported translation, we can make sure to only keep intentional changes, and revert to upstream ones automatically.

Of course, this won't help with already 'changed' messages (many of which have happened by accident, but we are solving that with a revert-translation spec).

[Данило Шеган (danilo)]

Derived from bits of #188907.

[TLE (k-nielsen81)]

Ok, let me see if I get this right. Say upstream package A has string "I" which has previously been translated upstream and string "II" which has not. This package is imported into launchpad and here a translator changes string "I" and translates string "II". In the mean time the upstream translator has another look at the package, makes changes and this new package is imported into LP later.

If the upstream translator translates string "I", then the upstream translation should override the LP because string "I" had not previously been changed. As for string "II" it does not matter of the upstream translator changes it or not, it will not override LP since it had already been imported.

Do I understand that correctly?

What about fuzzies. Will an upstream non-fuzzy string override a fuzzy LP string, even if it has previously been imported?

[Данило Шеган (danilo)]

TLE: you don't get it completely right :)

I'll explain it with a slight modification of your example.

Upstream PO file we initially imported:
msgid "I"
msgstr "one"

msgid "II"
msgstr ""

msgid "III"
msgstr "three"

LP translation done for "II" to "LP-two", and for "III" to "LP-three"

and new upstream translation of:

msgid "I"
msgstr "one-b"

msgid "II"
msgstr "two"

msgid "III"
msgstr "three-b"

the status in LP will, after import, match upstream for both "I" and "II", but translation will be "LP-three" for "III".

IOW, where someone intentionally modified upstream translation, it will stick. Where they didn't, it will be reverted back to the upstream one.

Fuzzy messages are now completely ignored in LP, and we are using only suggestions for providing, well, messages that need review.

[TLE (k-nielsen81)]

Ahh ok. So it is only if I approve bugfix changes of translations in LP that I will have a branching translation

[Jeroen T. Vermeulen (jtv)]

Bug fixes, or cases where there needs to be a difference. For example, you might be translating an Ubuntu package where the upstream translators and Ubuntu use different words for "folder."

[Данило Шеган (danilo)]

Fixed in RF (and I am calling it RF, because it's still the fuel for our rockets) 7221.

[Данило Шеган (danilo)]

Even though this is going to come in 2.1.11, it's not going to be practically useful before bug 183491 fix lands (barely missed our deadline).