[bug #53516] $LANGUAGE doesn't take "en" into account

[Mikko Rantalainen]

Follow-up Comment #5, bug #53516 (project gettext):

> [comment #2:]
> > To put it in another way, it makes no sense to have en before any other
language in the LANGUAGE priority list. Ever.

> [comment #4:]
> This is valid when en_US is the default language, which I give you is
probably true in 99% of the cases. I don't object to it being the default, I
just don't want to assume.

I agree. The source language (the msgid string) should be considered to be of
language called "C", not English nor en_US. And it seems to be the current
implementation, too!

However, most English speaking developers do not understand this difference
and as a result we have *technically missing* English localizations for pretty
much all software.

Now, the current setup is obviously very problematic for people that *prefer*
english but know some other languages well, too. For example, my *native*
language is Finnish but I know English well enough to prefer it for computer
use. As you said, many applications have empty strings for English
localization so you always get fallback to alternative language instead of
getting the English when the original developers intent was that their "C"
variant is the official English version.

Of course, the correct way would require that *every* developer that thinks
their "C" version is the official English version, runs the command "msgen"
for every release they do. However, as this is obviously not happening, you
cannot configure your locale to prefer English and fallback to any other
language.

This is *not* because gettext assumes that English is default but because
English translation is nearly always *completely missing* and it therefore
uses fallback to another language.

Perhaps there could be some kind of magic like environment variable

   GETTEXT_ASSUME_EMPTY_EN_IS_COMPLETE_ENGLISH=1

which makes gettext pretend that if en.mo is missing or is full of empty
strings (obviously, the msgid "" would still have metadata) then assume that
"C" is the complete English translation instead of English translation missing
all the strings. However, if the translation has even a single localized
string assume that it's the best translation that the original developers were
able to create and the intent is to fallback to another language for any
missing strings.

This would allow applications that have *real* partial English localization to
use partial English UI and fallback to user selected alternative language(s)
for the rest of the strings (as originally designed for the LANGUAGE setting).
However, lazy English speaking developers could continue doing half-assed job
with their English / "C" localization and everything could still work more or
less correctly for *all* languages.

It might be even sensible to make that default and request current behavior on
such special environment flag only. However, it would make the current 3rd
party developer assumption that "C" === "English" permanent forever.

Of course, an obvious optimization would be to skip such special logic if "en"
is not part of environment variable LANGUAGE because that's the only commonly
mis-used language with gettext.

However, in my opinion it's not okay to pretend that everything is fine as
things stand now. The reality is that all those applications are technically
missing all the localizations and the *only* way to use those applications in
English is to fallback all the way to "C". I'm pretty sure that it wasn't the
original developer intent. But that's the reality we have.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?53516>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/