Gunnar Hjalmarsson [2010-11-24 17:20 -0000]:
> Please note that the gdm patch, i.e. the Xsession code changes, is not
> part of my suggestion any longer. [...] As you know, I tried to
> 'sell' the idea upstream, but wasn't very successful...
Right, but I think we should still patch the Xsession script in the
Ubuntu gdm package instead of this profile.d hacking; first, it would
be a bit confusing for someone who looks at gdm's script, and second,
it hasn't been tested with other login managers and might just break
stuff there.
I think the gdm patch will be rather small, so that it won't be a
burden to maintain.
> As a result of that, I replaced the previously suggested Xsession
> changes with two new language-selector files:
> /etc/profile.d/gdm-lang-unset.sh
> /etc/X11/xinit/xinitrc.d/language-environment.sh
That would again duplicate code, though? Also, it would mean that gdm
behaves differently when language-selector is installed or not. I'm
not totally avert to this, but I'd rather avoid it. (See above)
> > - in the second part of language_update(), why would $GDM_LANG not
> > be a valid locale? this does some rather expensive things like
> > locale -a and grep and iterating over all available locales. So far
> > we trusted that $GDM_LANG was the format of a locale name, and also
> > a valid locale (gdm already tests that); under that assumption,
> > couldn't we simply set $LC_MESSAGES to $GDM_LANG?
>
> 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 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?
> Hence $GDM_LANG (or $GDM_LANGUAGE) may well be just 'en.utf8',
> 'sv.utf8' or 'de.utf8', none of which is a valid locale (at least
> not on my box).
Right, but I think $GDM_LANG assuming these values is a bug in the
first place.
> As regards efficiency ("expensive things"), please note that the
> language_update() function is called only when the user changes the
> language from the GDM greeter.
Thanks, noted. I agree that we can add some computational overhead
just for this case.
> > - in the new_language check at the bottom, I think we should
> > additionally check that $GDM_LANG != $LANG [...]
> [...]
> If s/he picks German (Germany) from the GDM greeter, i.e. changes the
> language from English to German, $GDM_LANG/$GDM_LANGUAGE would equal
> $LANG. But now, when we complete the separation of LANG from the
> translation language, that has nothing to do with it any longer, has it?
Of course, you are right. So let's forget this.
> I'd like to raise a couple of Kubuntu related questions.
I'm afraid I don't know anything about the KDE bits; it's worth
speaking to the kubuntu-dev folks about it. However, I think as a
first step we should make these changes to /etc/gdm/Xsession first and
see how it goes out in the field. Then we can see how to apply these
to kdm and whether there's something to factor out. WDYT?
Hello Gunnar,
Gunnar Hjalmarsson [2010-11-24 17:20 -0000]:
> Please note that the gdm patch, i.e. the Xsession code changes, is not
> part of my suggestion any longer. [...] As you know, I tried to
> 'sell' the idea upstream, but wasn't very successful...
Right, but I think we should still patch the Xsession script in the
Ubuntu gdm package instead of this profile.d hacking; first, it would
be a bit confusing for someone who looks at gdm's script, and second,
it hasn't been tested with other login managers and might just break
stuff there.
I think the gdm patch will be rather small, so that it won't be a
burden to maintain.
> As a result of that, I replaced the previously suggested Xsession d/gdm-lang- unset.sh xinit/xinitrc. d/language- environment. sh
> changes with two new language-selector files:
> /etc/profile.
> /etc/X11/
That would again duplicate code, though? Also, it would mean that gdm
behaves differently when language-selector is installed or not. I'm
not totally avert to this, but I'd rather avoid it. (See above)
> > - in the second part of language_update(), why would $GDM_LANG not gdm/$USER/ dmrc
> > be a valid locale? this does some rather expensive things like
> > locale -a and grep and iterating over all available locales. So far
> > we trusted that $GDM_LANG was the format of a locale name, and also
> > a valid locale (gdm already tests that); under that assumption,
> > couldn't we simply set $LC_MESSAGES to $GDM_LANG?
>
> 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/
> are now updated 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?
> Hence $GDM_LANG (or $GDM_LANGUAGE) may well be just 'en.utf8',
> 'sv.utf8' or 'de.utf8', none of which is a valid locale (at least
> not on my box).
Right, but I think $GDM_LANG assuming these values is a bug in the
first place.
> As regards efficiency ("expensive things"), please note that the
> language_update() function is called only when the user changes the
> language from the GDM greeter.
Thanks, noted. I agree that we can add some computational overhead
just for this case.
> > - in the new_language check at the bottom, I think we should $GDM_LANGUAGE would equal
> > additionally check that $GDM_LANG != $LANG [...]
> [...]
> If s/he picks German (Germany) from the GDM greeter, i.e. changes the
> language from English to German, $GDM_LANG/
> $LANG. But now, when we complete the separation of LANG from the
> translation language, that has nothing to do with it any longer, has it?
Of course, you are right. So let's forget this.
> I'd like to raise a couple of Kubuntu related questions.
I'm afraid I don't know anything about the KDE bits; it's worth
speaking to the kubuntu-dev folks about it. However, I think as a
first step we should make these changes to /etc/gdm/Xsession first and
see how it goes out in the field. Then we can see how to apply these
to kdm and whether there's something to factor out. WDYT?