Bug#632798: libc6: broken LANGUAGE design

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Vincent,

Vincent Lefevre wrote:

> LANGUAGE=
[...]
> LC_MESSAGES=fr_FR
[...]
> ypig% ssh localhost locale
> Connected to ypig (from ::1)
> LANG=POSIX
> LANGUAGE=en_US:en
[...]
> LC_MESSAGES=fr_FR
[...]
> LC_ALL=
[...]
> The problem is that the system sets LANGUAGE in the user's back, so
> that the standard user's choice (LC_MESSAGES=fr_FR) is no longer taken
> into account.

I agree that this is not very good.  Before deciding how to fix it,
let's describe the mechanism.

1. On my local machine, I could not reproduce the same effect.  That's
   probably because no default locale is configured here.  After making
   the default locale de_DE.UTF-8 using "dpkg-reconfigure -plow locales",
   /etc/environment is empty and /etc/default/locale looks like this

	#  File generated by update-locale
	LANG=de_DE.UTF-8
	#LANGUAGE=en_US

   and "ssh localhost locale" still shows "LANGUAGE=".  Any idea what's
   different between your setup and mine?

2. openssh-server has the following in its default sshd/config:

	AcceptEnv LANG LC_*

   That is unfortunate.  Independently of everything else, this list
   ought to be expanded to include LANGUAGE.

3. The locale C.UTF-8 does not work like C for the sake of this feature:

	$ LC_ALL=C LANGUAGE=de_DE cp
	cp: missing file operand
	Try `cp --help' for more information.
	$ LC_ALL=C.UTF-8 LANGUAGE=de_DE cp
	cp: Fehlendes Dateioperand
	„cp --help“ gibt weitere Informationen.

   If I understand the purpose of C.UTF-8 correctly, that's another bug
   (independent, though).

4. Despite what the gettext manual[*] says, setting LANG does not cause
   LANGUAGE to take effect.  This is another bug, as far as I can tell.

	$ LANG=en_US LANGUAGE=de_DE cp
	cp: missing file operand
	Try `cp --help' for more information.

5. As you mentioned, when LANGUAGE has an effect, it takes precedence
   over LC_MESSAGES.  The principle of least surprise might indicate
   that the locale in LC_MESSAGES should be used in preference to
   LANGUAGE, but that would make it impossible to express something
   like what is currently meant by

	LANGUAGE=fr:de
	LC_MESSAGES=de

   on an installation where most programs are translated to German.
   (It means: programs using catgets should use German, while programs
   using gettext should prefer French if possible.  Intent: "I'd
   prefer French, but barring that, please give me German instead of
   English").

   If one is willing to break with >10 years of gettext behavior, it
   should be possible to change this without that downside by
   prepending $LC_MESSAGES to LANGUAGE when and only when it is not
   already an item in $LANGUAGE.

   A nice side-effect would be the ability to partially work around
   (2), as you mentioned.

What do you think?  What pieces does the above description miss?

Thanks for your attention to detail.
Jonathan

[*] http://www.gnu.org/software/gettext/manual/gettext.html#The-LANGUAGE-variable