Bug#748215: gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup

[Jakub Wilk <jwilk@debian.org>]

[I'm not (e)glibc maintainer, just a random gettext user.]

* Zygmunt Krynicki <zygmunt.krynicki@canonical.com>, 2014-05-15, 12:57:
> If the LANGUAGE environment variable is set to a nonempty value, and 
> the locale is not the "C" locale, the value of LANGUAGE is assumed to 
> contain a colon separated list of locale names. The functions will 
> attempt to look up a translation of msgid in each of the locales in 
> turn. This is a GNU extension.

This semantics of LANGUAGE is confusing and error-prone (it overrides 
LC_ALL... except when it doesn't). The exception for "C" was needed not 
to break existing software that set LC_ALL=C with the expectation that 
it resets all internationalization settings.

But the C.UTF-8 locale is newer invention that the LANGUAGE variable, so 
there is no need to add such exception.

> This part works as expected. I would like to propose that the same 
> special-case behavior is used when the locale is "C.UTF-8" as it is 
> becoming the de-facto "better C" and it is unexpected to see, for 
> example, translated gettext messages when using such locale.

What I find unexpected is this:

$ LANGUAGE=de LC_ALL=de_DE.UTF-8 stat /moo
stat: cannot stat '/moo': No such file or directory

$ LANGUAGE=de LC_ALL=pl_PL.UTF-8 stat /moo
stat: der Aufruf von stat für „/moo“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden

At least with the advent of C.UTF-8, I don't have to hunt for an 
installed locale, and just use:

$ LANGUAGE=de LC_ALL=C.UTF-8 stat /moo
stat: der Aufruf von stat für „/moo“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden

which works everywhere.

--
Jakub Wilk