[Bug 553162] Re: Set $LANGUAGE if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing

[Martin Pitt]

Hello Gunnar,

I see a ton of new MPs and replies here, so I'll reply/catch up with
them one by one. So some of my replies here might already be obsolete
now.

Gunnar Hjalmarsson [2010-11-30 12:12 -0000]:
> > and second, it hasn't been tested with other login managers and might
> > just break stuff there.
> 
> Don't see the difference in that respect between an Xsession patch and
> sub-scripts.

If you patch /etc/gdm/Xsession, it'll just affect gdm. If you add
something to /etc/profile.d/ and xinitrc.d/, it will affect all login
managers, and will even run for console and ssh logins.

> Doesn't the maintenance aspect speak in favour of sub-scripts that
> belong to the language-selector package?

I don't think it makes much difference where the script changes are
maintained (in gdm or l-s), but in gdm they'll only apply to gdm,
which I think is the safer approach for now. There's another aspect to
this: The upstream gdm Xsession script already sets $LANG. With the
changes that you have in mind, it needs to stop doing that; with
separate .d directory scripts, you can only additionally set $LC_*,
but the original $LANG value is lost.

> > Also, it would mean that gdm behaves differently when
> > language-selector is installed or not.
> 
> Yes. Isn't that what we want for the time being, considering that the
> idea was rejected upstream?

It sounds strange to me. Why would you desktop language suddenly
change if you uninstall (or install) language-selector? I don't think
that this meets the principle of least surprise.

> >> I think that the reason why there is a need to ensure that LC_MESSAGES
> >> is assigned a valid locale is that ~/.dmrc and /var/cache/gdm/$USER/dmrc
> >> are now updated by language-selector when LANGUAGE is set.
> > 
> > That's the part I don't understand. The format of LANG and LC_MESSAGES
> > is the same -- a valid locale string. There shouldn't ever be a change
> > which sets "Language=" in .dmrc to a non-locale string (cf.
> > compatibility to older gdm and other *dm); is there?
> 
> Hmm.. If I recall it correctly, we agreed a few weeks ago to
> conceptually convert GDM's locale selector to a pure language picker, in
> order to make it play well with the language tab in language-selector.

Right, but without upstream taking some of those more intrusive
changes we need to have a compromise where we don't change the meaning
of .dmrc. Since other DMs also use that file, we can't just redefine
the meaning of the Language= option there anyway.

> It should be noted that language-selector's language tab is not
> designed to set LC_MESSAGES, but to build LANGUAGE lists.

Correct, but that's orthogonal to gdm. language-selector has both a
language list (for $LANGUAGE) in the first tab, and a locale picker in
the second tab (for time, currency format, etc.).

> The language tab menu includes both ll_CC combinations and pure ll
> options, and that's the kind of values that has been passed to the
> dmrc Language field (and with that $GDM_LANG) in all the variants I
> have uploaded the past few weeks.

Right, and that's what I'm continuing to object to :) We can't do that
only in Ubuntu without getting agreement between other users of .dmrc
(kdm/xdm/lxdm/ltsp/..., presumably not all of them use .dmrc, though)

> So, why doesn't language-selector pass the same string to dmrc as it
> does to LC_MESSAGES? My reason for not wanting to do it that way is that
> it would result in incorrect pre-selected options in GDM's language
> picker. For instance, if you would drag "Deutch" to the top of the menu
> in language-selector's language tab, you would see "German (Austria)" as
> the pre-selected option at next login. Certainly not a disastrous bug,
> but significant enough IMO to not introduce intentionally.

I agree that this is confusing, but I think that's the kind of
compromise we have to make if this is going to be a non-upstreamable
change.

> I brought it up now since Kubuntu is also using language-selector, and
> there is a separate Kubuntu binary.
> 
> Only changing the Xsession behavior, without changing language-selector
> at the same time, wouldn't make much sense, would it?

I don't have a strong opinion here, but of course it would be better
to be consistent with what gdm does. Especially since the
language-selector-qt port should do pretty much the same as the GTK
variant.

> But I'm in favour of committing something very soon.

Right, so let's keep the KDE discussion separate, and limit the
changes to gdm for now?

> > This needs to be tested with other window managers, though, that they
> > don't stumble over these new fields.
> 
> The new fields don't appear automatically in the files - you need to
> write to either /var/cache/gdm/$USER/dmrc or ~/.dmrc first. Then the
> files update each other with changes. Therefore I don't think there is
> such a risk. Or am I missing something here?

I meant that if on one machine you use GDM and put a new field in your
~/.dmrc, and on another machine you use KDM, then KDM shouldn't
suddenly act up on the new field. Since this is an ini-style file
shared by different *dms, it should (and will) probably just ignore
the new field. I just brought it up as something which should be
confirmed by testing.

> To sum it up, I feel ready to prepare final (almost) branches to be
> merged into Natty. For reasons stated above, and for the time being, I'd
> like
> 
> * that the dmrc Language field may be assigned values that may not
> represent valid locales

This has my strong veto. I'd rather add a new LanguageList (or
similar) field to it on demand.

> * By using sub-scripts belonging to language-selector instead of
> patching Xsession, we initially change the GDM behavior only for Ubuntu
> users who have the new version of language-selector installed.

See above. You'd also change behaviour for Kubuntu, ssh, and VT
logins.

> * Let's make language-selector keep updating ~/.profile with LANGUAGE
> and LC_MESSAGES changes transitionally, even if it also writes to
> /var/cache/gdm/$USER/dmrc. Doing so may prevent both undesired effects
> to Kubuntu users and the kind of backwards compatibility issues in
> networks that you mentioned.

I agree.

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/553162

Title:
  Set $LANGUAGE if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing

Status in GDM: The Gnome Display Manager:
  New
Status in Ubuntu Translations:
  Triaged
Status in “gdm” package in Ubuntu:
  In Progress
Status in “language-selector” package in Ubuntu:
  In Progress

Bug description:
  Binary package hint: gdm

This is a follow-up to bug 407300, which has been fixed but a separate issue remains. I'm opening a separate task for language-selector, as it refers to the interaction between it and gdm.

The problem is basically that GDM seems to always override the LANG values set by language selector, and quite easily one can get to a situation where LANGUAGE and LANG differ and the desktop is a mixture of two languages.

Steps to reproduce (a):

 * New install, choosing Catalan in the installer
 * I log in without doing any changes to the language in GDM
 * I start System > Administration > Language support
 * I choose English there
 * I log out
 * I log back in without doing any changes in the GDM language chooser
 * My session is half English and half Catalan due to LANGUAGE=en and LANG=ca_ES.utf8 (Firefox in Catalan, gnome-panel in English, gnome-menus in Catalan).

Steps to reproduce (b):

 * Perform a full installation in English, as per http://testcases.qa.ubuntu.com/Install/NonEnglishLanguage#Installation%20Full%20Network%20Support
 * Go to System > Administration > Language Support
 * Install the Traditional Chinese language
 * Bring Traditional Chinese to the top of the list to become the main desktop language
 * Press the "Apply System-wide..." button
 * Reboot
 * When entering the session, you'll notice the desktop half translated in English, half in Chinese. The most noticeable parts shown in English are all the menus and Firefox. These applications seem to ignore the LANGUAGE variable
 * Running 'locale' on the terminal shows that LANG=en_US.UTF-8 and LANGUAGE=zh_K:en_US:en

I understand that this might be a problem in each application, as they should give LANGUAGE preference. Rather than filing a bug in each app right now, would it not make more sense to ensure that at least the first locale in LANGUAGE, the one in LANG and LC_MESSAGES are the same? (assuming it is possible to do such a thing, of course).

Also see the related bug 552664