Comment 30 for bug 553162

@ David
Thanks for your praising comment.

It seems to me that you, and possibly also Martin, assume that $LANG ought to correspond to the first language in the $LANGUAGE list. That, I believe, is a misconception, at least from a language-selector perspective, and I fear that we have talked at cross-purposes so far.

In an attempt to help changing that, I wrote a wiki-page:
https://wiki.ubuntu.com/GdmLanguageSelectorDissonance

It summarizes my view on where we stand, where we want to go ("Desired behavior"), and my proposed solution in English. It would be great if you, Martin and anybody else with an interest in this issue could study the page and add your possible objections and comments.

Basically, what I hope to convince you about is that since it's only language that the users can set from GDM, and not any other locale aspects, GDM should not do anything with the $LANG variable. Not at any point. Never.
Instead GDM should update $LANGUAGE and set $LC_MESSAGES. That appears to be sufficient to reliably control which language is used in menus and messages. $LANG is used for the non-translation locale aspects, and its value shall not be used as a fall back by programs that don't understand $LANGUAGE.

As regards apps that don't understand $LANGUAGE:
> Rather than using a workaround, would it not be better to fix the
> bug in the affected applications? I see you've followed up on
> Firefox already.

If I have understood it correctly, $LANGUAGE is a gettext specific variable, and certain applications' inability to understand that variable is not a bug per se. Consequently I think that Ubuntu in any case shall provide the preferred translation language also via the $LC_MESSAGES variable, and I don't think that's a workaround. Rather should the Firefox fix I provide at bug 550222 be considered a workaround IMO.

I noted that you don't consider this issue a matter for the translation community. But it's a borderline case, isn't it? ;-)