A proposal for separate English localization
erack at redhat.com
Tue Oct 17 11:39:35 UTC 2017
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
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the LibreOffice