A proposal for separate English localization
mikekaganski at hotmail.com
Fri Oct 13 21:31:41 UTC 2017
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
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.
More information about the LibreOffice