[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: MO files not optimised enough (esp. en_GB, en_CA, etc) in KDE
From:       Simos Xenitellis <simos.lists () googlemail ! com>
Date:       2007-07-23 17:34:03
Message-ID: 1185212043.5561.90.camel () computer
[Download RAW message or body]

Στις 23-07-2007, ημέρα Δευ, και ώρα 18:49 +0200, ο/η Chusslove Illich
έγραψε:
> > [: Simos Xenitellis :]
> > There is an issue in gettext-tools regarding an optimisation [...]
> > Translation teams often copy the msgid string to msgstr [...] There is an
> > effort to get "msgfmt" automatically to ignore those copied messages [...]
> 
> (Hi Simos, not sure if you've seen my short reply on bug-gnu-utils, here it
> is again.)
> 
> Wouldn't this have adverse affect to the language fallback mechanism? For
> example, if the user has set $LANGUAGE to lang1:lang2, and lang1 PO had
> given message same as original, while lang2 had it different, under the no-
> inclusion rule the user would get lang2 string, which is wrong.
> 

Thanks, I can see this point. 

I believe that it captures a small minority of cases. 

Normally, when for a message the english original is used for lang1, you
would expect that the same goes for lang2. If lang1 and lang2 are
similar (such as es and es_MX), the problem would arise if in
spanish_spanish a word is left as is but in mexican_spanish it is
translated. 
A spaniard would have LANGUAGE=es, so no problem would arise. A mexican
would have LANGUAGE=es_MX:es so that any translations specific to
spanish would make it first. The problem would arise if a Mexican wanted
to keep the original english translation of a word and not use the
spanish/spanish one. Are there such cases?

For users that set LANGUAGE=es:fr (not common in default installations),
the effect (with the porposed optimisation) would be that the end-user
would have more chances to see the message in a translated form.

Are there other practical examples for this?

Simos

[prev in list] [next in list] [prev in thread] [next in thread]