Date: prev next · Thread: first prev next last
2017 Archives by date, by thread · List index


Hi,

On 10/17/2017 2:39 PM, Eike Rathke wrote:
Hi Mike,

On Sunday, 2017-10-15 10:55:17 +0000, Kaganski Mike wrote:

The source string is the key for all translations, and is kept immutable
after creation. But the localization string might change later, e.g. to
be consistent, like this:

      source             locale
"do foo action"    "Do Foo action"

so they go out of sync.

And that is bad. If what is visible in the English UI does not match the
source then finding the source string of some UI element gets
complicated. Being able to locate the source of an UI string and from
there dive into its use in the code is a helpful procedure.

Why not sustainable? Actually, we somehow expect all of our translations
to be kept in sync (as well as possible); so why do we think about this
one differently? Actually we have multiple places in code that should be
kept synchronized at all times, and this works well (e.g., some
enumeration values);

Translations (pootle etc.) are not code. In fact the primary source of
translations isn't even in a code repository, just merged from time to
time to the translations/ submodule. Technically it also doesn't matter
how much is translated to one language or if translations are accurate
(with a few exceptions).

and if the sync state is being checked at compile
time (like some plugin maybe), this is absolutely possible.

Maybe I got you wrong. Are you talking about some merge back from
translations into source code to have the source synced with the English
translation?

This should be considered in context of #2 of the original message 
(https://lists.freedesktop.org/archives/libreoffice/2017-October/078629.html), 
which is "The English translation should be created in a different way 
(in a dedicated source file?) to be easy for developers to change."

With that in sight, I assume something like this:

1. Source files that contain references to translatable strings (in the 
form like "do foo action" above). Already present.
2. Per-module (?) "localization.en_US.txt", with pairs like
     "do foo action" = Do Foo action
   - this already makes it possible to locate the code from UI string 
with single indirection
3. A script that is run by make that checks that each string from #1 has 
its counterpart in #2, and errors out on failure; otherwise, compiles 
the en-US localization.

The other translations continue to be served as they are now. But in 
case an English string changes in a localization.en_US.txt, then all 
other translations flag their relevant string as needed to be reviewed 
(but not loose their current translations!). That could be possible, 
because underlining code string (identifier "do foo action") stays 
unchanged. That needs a script, that would to that trick (checking if 
English translation of a string is changed) when other translations' 
pootles are updated.

This could be further extended to allow including context into the 
reference string in code, to look like
   gettext("moduleX/dialogY/do foo action")
(but I don't know if that's helpful, and this isn't a subject of my 
proposal).

On 10/17/2017 2:46 PM, Eike Rathke wrote:
For a new string replacing an old one and introducing a different
functionality a new context string should be used as well. I don't see
a problem with this.

If you have many strings that you not only have to check, but also old 
translation is lost, (and it's not always easy for translator to get 
access to a part of UI with that string to get clear idea about it) the 
problem is evident. AFAICT, those who complain encounter that problem on 
a regular basis. Being able to just flag strings, but not loose current 
translation, is the main idea.

-- 
Best regards,
Mike Kaganski

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.