A proposal for separate English localization

[Kaganski Mike]

Hello!

Recently I was approached by members of our local community who manage 
the translation of LibreOffice UI to Russian. I was told that they have 
a regularly recurring problem, that each time a developer changes an 
English string in LibreOffice UI, they have that string untranslated in 
pootle, and need to repeat same actions again to re-translate it. What's 
worse, the translation that pootle suggest in that case is oftentimes wrong.

This is *not* related to changes that were recently made by Caolan to 
the localization machinery; rather, it's more like commit 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc where 
hundreds of strings were slightly changed for consistency in UI. That's 
of course necessary to do, but the specifics of our translation makes 
the English (built in) translation the source for all others, and every 
change in it (even irrelevant for a other translation that, say, has the 
strings capitalized consistently) forces *all translation teams* to do 
the extra work.

I received a proposal that looks like that: make an English translation 
yet another ordinary translation, and make strings in code immutable. 
When a developer decides to change English strings, those changes would 
go to the translation, not to the source. This way, the new strings 
would, as before, add work to translation teams, but changes to English 
translation that are irrelevant to other translations will be local.

I had a discussion on the topic with erAck, and he raised several 
concerns. First, the English translation is the fallback in case there's 
no localized translated string. Second: developers would not work with 
pootle, and that would raise need for English localization team. Third, 
that developers don't know if thier change to English UI is or is not 
relevant to other translation; English being the source for others, the 
change might need to be reflected in the other translations, so each 
change should be reviewed by localizers anyway.

When I discussed the topic with Olivier, he also told me that the 
workflow is very uncomfortable for translation teams, and stressed that 
the tooling gives wrong proposals for changed translations, thus not 
helping in the process.

I wanted to ask all interested parties to discuss the topic, and share 
your opinions. From my side, I suppose that the concerns raisedby Eike 
could be sloved like this:

1. The English translation becomes the fallback. In case that there's no 
English string for an element, that should be blocked on compilation 
stage, or alternatively the immutable code string would become the fallback.

2. The English translation should be created in a different way (in a 
dedicated source file?) to be easy for developers to change.

3. Any change in English translation (not in immutable source strings!) 
would trigger all other translations of this string to become fuzzy 
(thus not loosing previous translation, but just signaling the 
requirement to review).

Hope this makes sense. I must admit that I myself don't have a deep 
knowledge in our localization machinery, so if this isn't reasonable, 
please ignore my proposals.

-- 
Best regards,
Mike Kaganski