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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
