A proposal for separate English localization
erack at redhat.com
Tue Oct 17 11:46:46 UTC 2017
On Monday, 2017-10-16 12:16:01 +0000, Kaganski Mike wrote:
> On 10/16/2017 10:08 AM, David Tardon wrote:
> > On Fri, Oct 13, 2017 at 09:31:41PM +0000, Kaganski Mike wrote:
> >> 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).
> > Wouldn't it be better to aim just for this and skip the hassle of adding
> > a separate English translation?
> Well, I'm not sure how that solution would help to tell apart the two
> different situations:
> 1. When a string is being corrected
> 2. When a string goes, but another string comes.
> First is simply a correction of existing string, that means that the
> translations should only review if their old translations are still OK.
> Second is when one feature was, e.g., removed from a dialog, but
> entirely different feature is added there. This is something that should
> be definitely translated by teams independently of some text that could
> exist there before.
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.
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