Surprising side-effects from gdm setting LC_MESSAGES in natty

[Gunnar Hjalmarsson]

[ Third time lucky? Seems like the list program screws up all UTF-8
encoded messages, so I try ISO-8859-1. My apologies... ]

Hi Michael,

Thanks for your message! I sent a copy of my reply to the ubuntu-desktop
mailing list, to make more people aware of the existence of the issue
you reported.

On 2010-12-28 17:09, Michael Bienia wrote:
> I'm not sure if I what I saw on my system is expected behaviour or some
> sort of bug in upgrading the .dmrc.
> I'm using "en_IE.utf8" as locale (to have english messages and the €)
> and the upgrade of gdm worked so far fine.
> The "problem" showed up when I did a ssh connection to a Debian system
> and wondered why my umlauts stopped working as expected suddenly (they
> worked without problems till now) and "locale" complained about a non-
> existing locale (on the remote host). After some debugging I figured out
> that as now LC_MESSAGES is also set, ssh transmits it to the remote
> host. The problem was that LC_MESSAGES was set to en_AG.utf-8 which
> doesn't exist on the remote host. I finally found out that this value
> came from my .dmrc. I didn't look into the code why LCMess didn't got
> set to "en_IE.utf8" on upgrade (I edited my .dmrc now) but picked
> en_AG.utf8 instead (the first UTF-8 locale in "locale -a").

If I understand you correctly, it's the environment variable LANG that
contains "en_IE.utf8", while "en" makes up the whole list in the
LANGUAGE variable.

The value in the "LCMess" field in .dmrc, and with that the LC_MESSAGES
variable, is derived from the first item in the LANGUAGE list. The LANG
value is not taken into consideration, and that's intentional. We have
focused on making it work as expected for users who use a LANG locale
with some other language than the language they want to apply for
message translation. LANGUAGE and LC_MESSAGES control the language for
translation, while LANG controls other localization aspects.

As you have noticed, since only the language ("en") is specified in
LANGUAGE, the first available (English) locale is assigned to
LCMess/LC_MESSAGES. In your case, since the available locales on the
remote machine do not include "en_AG.utf8", you need to be more specific
when setting LANGUAGE. Both language-selector's "Language" tab and GDM's
login page allow you to specify country, and that would be the easiest
way to achieve the settings you need. Manually editing .dmrc works too,
but that had not been necessary.

I'm not sure whether this is a bug either. ;-) One way to reduce the
risk for the behavior you described would be to assign LC_MESSAGES a
locale that represents the main dialect, when the first LANGUAGE item
consists of a language code only. I haven't figured out a way yet to
determine the main dialect, though, so I'd appreciate tips on how to do
that. It would be useful also for a closely related idea:
https://launchpad.net/bugs/693337

Rgds,
Gunnar
https://launchpad.net/~gunnarhj