GNOME Bugzilla – Bug 633295
Language selector in greeter interferes with non-language locale settings
Last modified: 2010-12-18 21:29:20 UTC
Created attachment 173359 [details] [review] proposed code change in Xsession This bug has been reported and discussed here: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/553162 Summary ------- Ever since the Ubuntu language support feature was changed to distinguish between language for message translation and non-language locales such as date formats, it has not played well with GDM's language selector. Example: People who want date formats, default paper sizes etc. match their current geographical location, while using some other locale for controlling message translation, have encountered confusing, unexpected behavior. The suggested solution with respect to GDM is to turn the language selector in the GDM login screen into a pure ditto: * Don't mess with the LANG environment variable * Update LANGUAGE, set LC_MESSAGES and edit ~/.profile if language was switched from greeter Attached please find a patch for the data/Xsession.in file.
I don't think it works for other platforms. The script would be better to move to /etc/X11/xinit/xinitrc.d/* since GDM can loads the files. Setting different LC_* has a problem for other applications which uses LC_ALL. LANGUAGE setting could be moved to /etc/profile.d
On 2010-10-28 03:26, Takao Fujiwara wrote: > Setting different LC_* has a problem for other applications which uses > LC_ALL. Please note that LC_ALL is not set currently either. It's LANG that is set, which means that the LC_* variables - except for LC_ALL - inherit their values from LANG unless explicitly set. I can't see how setting LC_MESSAGES explicitly would be a problem. The fact that Xsession currently sets LANG out from the value of GDM_LANG is a problem, however, if you want to offer the possibility to distinguish between message translation and other localization aspects. While it from an Ubuntu perspective is important to get away from that, creating /etc/X11/xinit/xinitrc.d and moving the suggested code there would probably be fine. > LANGUAGE setting could be moved to /etc/profile.d Nope. ~/.profile needs to be read first. Personally I'm convinced that supporting a distinction between language for message translation and other localization aspects is a step in the right direction. Hence I believe that code changes in GDM would be preferable before an Ubuntu specific solution.
(In reply to comment #2) > On 2010-10-28 03:26, Takao Fujiwara wrote: > from LANG unless explicitly set. I can't see how setting LC_MESSAGES explicitly > would be a problem. Some distributions set LC_*. E.g. if LC_CTYPE and LC_MESSAGES and set fr by default but LC_MESSAGES is set fr_FR.UTF-8 by GDM, it would be a problem when an application read LC_ALL. The problem is this patch set users' .profile without notices. If remove desktop is run on de_DE.UTF-8 and LC_MESSAGES is set fr_FR.UTF-8 in .profile, it would be a problem. I think modifying $HOME/.profile is a bit complicated to manage the login locales. If the locale setting is recommended by a distribution, I think it could be moved to a distribution system directory, e.g. /usr/lib/locale/$LANG/locale_map and /etc/X11/xinit.d/* scripts can load the files and $HOME/.profile . > > The fact that Xsession currently sets LANG out from the value of GDM_LANG is a > problem, however, if you want to offer the possibility to distinguish between Yes, it would be no problem because distributions can customize the value with /etc/sysconfig/i18n . If necessary, distributions can unset all LC_* and set GDM_LANG. It would be expected that system boot is English but GUI is the chosen locale. > message translation and other localization aspects. While it from an Ubuntu > perspective is important to get away from that, creating > /etc/X11/xinit/xinitrc.d and moving the suggested code there would probably be > fine. > > > LANGUAGE setting could be moved to /etc/profile.d > > Nope. ~/.profile needs to be read first. The /etc/profile.d scripts can load ~/.profile at first.
(In reply to comment #3 from Takao Fujiwara) > Some distributions set LC_*. E.g. if LC_CTYPE and LC_MESSAGES and set fr > by default but LC_MESSAGES is set fr_FR.UTF-8 by GDM, it would be a problem > when an application read LC_ALL. How could it as long as LC_ALL is not set? > The problem is this patch set users' .profile without notices. > ... > I think modifying $HOME/.profile is a bit complicated to manage the login > locales. Martin Pitt is hesitant over that too, but it should be seen in the light of the starting-point for the patch, i.e. making GDM's language selector play well with Ubuntu's language support tool (package language-selector), which does edit ~/.profile. I believe that the users have reasons to assume that GDM's language selector is an alternative way to set the user language persistently, like the keyboard layout selector and the session type selector set their respective values persistently. I'm suggesting changes to language-selector as well, btw: https://code.launchpad.net/~gunnarhj/language-selector/suppl-fix-553162/+merge/38596 I understand that you prefer to see this as a distribution specific matter, and I don't feel that I'm experienced enough to really question your view in that respect. But given that, I do think that this code in Xsession is an obstacle: if [ -n "$GDM_LANG" ]; then LANG="$GDM_LANG" export LANG fi Of course, it might be circumvented by unsetting GDM_LANG, but such a solution would appear rather 'hackish', wouldn't it?
(In reply to comment #4) > How could it as long as LC_ALL is not set? There is no problem if GDM doesn't override user's setting of .profiles. You could test the setlocale(LC_ALL, NULL) if LC_* has different values. > Martin Pitt is hesitant over that too, but it should be seen in the > light of the starting-point for the patch, i.e. making GDM's language > selector play well with Ubuntu's language support tool (package > language-selector), which does edit ~/.profile. I believe that the users I think the tool is for Ubuntu specific. E.g. some platforms uses the different locales between GLI login and GUI login and I think it's good for GDM not to set LC* and LANGUAGE persistently. > have reasons to assume that GDM's language selector is an alternative > way to set the user language persistently, like the keyboard layout > selector and the session type selector set their respective values > persistently. > > I'm suggesting changes to language-selector as well, btw: > https://code.launchpad.net/~gunnarhj/language-selector/suppl-fix-553162/+merge/38596 I think the change also would causes problems for some platforms. But probably it's good if it's applied to Ubuntu only. Basically I think when users choose a locale from GDM, GDM should set $LANG only but not modifying $LC_*. Some platform would set the different values in LANG and LC_* but it's too complicated to be generally upstreamed to support their legacy systems and currently they could use /etc/X11/xinit.d/*. > Of course, it might be circumvented by unsetting GDM_LANG, but such a > solution would appear rather 'hackish', wouldn't it? I think setting GDM_LANG is a bit different situation to save the LC_* and LANG in .profile by a login manager. Probably I wish GDM_LANG also could be removed in the future not to support the compatibility.
For the record, in my POV modifying ~/.profile from gdm during login is a no-go. It should also not be required at all, gdm should just set the right env vars at the right time. However, I became reasonably convinced that gdm's language selector should indeed just set LC_MESSAGES and $LANGUAGE, so that other tools can still configure the locale in its entirety ($LANG usually).
Created attachment 173578 [details] [review] New Xsession patch On 2010-10-29 09:20, Takao Fujiwara wrote: > There is no problem if GDM doesn't override user's setting of .profiles. Well, I don't think that the word "override" accurately describes what I'm suggesting. If the first LANGUAGE item corresponds with GDM_LANG, which would be the case if the user did not switch language from the greeter, GDM would not set anything. Only if the user did switch the language, and in order to make that change persistent, GDM would set LANGUAGE and LC_MESSAGES, both in the env. variables and in ~/.profile. On 2010-10-29 15:52, Martin Pitt wrote: > For the record, in my POV modifying ~/.profile from gdm during login > is a no-go. > ... > However, I became reasonably convinced that gdm's language selector > should indeed just set LC_MESSAGES and $LANGUAGE, so that other tools > can still configure the locale in its entirety ($LANG usually). Hmm.. I think you opened a door there, Martin. The reason why I suggested (still suggest) that ~/.profile is edited is that the Ubuntu specific tool language-selector both reads and writes to ~/.profile. But since language-selector is an Ubuntu specific tool, I now realize that that argument is not valid here. Consequently I moved the code that edits ~/.profile to the language-selector patch. The final discussion on whether it makes sense to keep it there can now be a pure Ubuntu conversation. Takao: If you have remaining doubts about setting LC_MESSAGES and LANGUAGES instead of LANG, I'll be happy to talk more about that. But it will have to wait a few hours - it's over midnight here. ;-) Martin: You mentioned that you will be rather busy next week too. I'd like to 'defend' my latest language-selector patch, but let's wait until you have sufficient time to think it through all the way.
I don't think setting LC_MESSAGES and LANGUAGES by system is good. I'd hope you will move to your settings to Ubuntu specific files likes /etc/X11/xinit.d/*.
(in reply to comment #8) I have made such an alternative, where all the code changes would be made in the Ubuntu specific language-selector package: https://bugs.launchpad.net/gdm/+bug/553162/comments/57 Can't help wondering, though, if no other distribution but Ubuntu has encountered (or may encounter) similar buggy behavior when distinguishing between language for message translation and other localization aspects. I don't know the answer, but I believe it's a relevant question.
Ubuntu GDM patches, which address the issues discussed above, have been released: https://launchpad.net/ubuntu/+source/gdm/2.32.0-0ubuntu2 Therefore I set the status of this bug to "resolved - notgnome".