[I'm not (e)glibc maintainer, just a random gettext user.]
* Zygmunt Krynicki <zygmunt.kryni...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
