Bug 372151 - /etc/sysconfig/i18n locale settings not propagating into X session
Summary: /etc/sysconfig/i18n locale settings not propagating into X session
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
Reported: 2007-11-09 04:22 UTC by Mike A. Harris
Modified: 2014-03-17 03:11 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-26 18:56:32 UTC

Attachments (Terms of Use)
i18n config file (325 bytes, text/plain)
2007-11-09 04:22 UTC, Mike A. Harris
no flags Details
a potential fix (819 bytes, patch)
2008-04-22 18:33 UTC, Ray Strode [halfline]
no flags Details | Diff
a better patch (859 bytes, patch)
2008-04-23 15:58 UTC, Ray Strode [halfline]
no flags Details | Diff
Handle all exportable variables (2.60 KB, patch)
2008-04-25 10:02 UTC, Jarkko
no flags Details | Diff
Handle all exportable variables (cleaned version) (2.33 KB, patch)
2008-04-25 10:35 UTC, Jarkko
no flags Details | Diff
Handle all exportable variables (csh version) (3.24 KB, patch)
2008-04-25 13:30 UTC, Jarkko
no flags Details | Diff
Handle the SSH case (549 bytes, patch)
2008-04-28 19:17 UTC, Jarkko
no flags Details | Diff
Handle the SSH case (csh version) (841 bytes, patch)
2008-04-28 19:32 UTC, Jarkko
no flags Details | Diff

Description Mike A. Harris 2007-11-09 04:22:58 UTC
Description of problem:
Only the $LANG variable stored in /etc/sysconfig/i18n gets propagated into the
user's X session in Fedora 8, but for some reason all of the other locale
variables such as LC_COLLATE and LC_MESSAGES do not propagate.  This is
discovered by typing "locale" at the prompt inside gnome-terminal or KDE's
konsole terminal.  Since only the $LANG variable propagates, the rest of the
variables get set automatically to the value of $LANG, so if you manually do a
"exec bash -login" to try to force it to reprocess the lang.sh script that sets
these variables at system startup time, it doesn't work because lang.sh bails if
$LANG is set already.

This suggests to me that something is hardcoding the value of LANG somewhere in
the gdm startup sequence, when it should be sourcing the /etc/sysconfig/i18n
file instead.  I looked at the prefdm script and it seems to be ok, so it looks
like it is something screwy going on in the X initscripts.

Version-Release number of selected component (if applicable):


How reproducible: 100%

Steps to Reproduce:
1. Clean Fedora 8 installation with all defaults.
2. Install the /etc/sysconfig/i18n file that I am going to attach shortly.
3. Reboot the computer.
4. Boot into runlevel 5 using the default *dm which I believe is gdm
5. Log in as a regular user
6. Start a gnome-terminal from the "Applications" menu.
7. Type "locale" at the prompt
Actual results:
pts/1 mharris@hammer:~$ locale

Expected results:
LC_COLLATE and LC_MESSAGES should be set to the defaults I have set them in
/etc/sysconfig/i18n as follows:


Here's what I've troubleshooted so far:

Correct operation:
Booting into runlevel 3 and logging in at the console, or booting to runlevel 5,
switching to VT1 and logging in as root or non-root and running "locale", the
locale variables are set correctly as expected.  This shows that the lang.sh
script is being sourced properly during login and everything is getting set up

I compared the lang.sh found in Fedora 7 with the one in Fedora 8 and they are
identical, so no changes there which could cause this problem.

In Fedora 7, I was logging in as user "mharris", then running "startx" to
initiate X.  Since console logins appear to source the i18n variables correctly,
it seems that it propagated correctly into my startx induced X session, as the
variables were set correctly in Fedora 7.

Additional info:
Not yet sure if this problem occurs under "startx" in Fedora 8 or not, but I'm
going to try that next as well.  I'm also not sure if the problem occurs under a
gdm X session in Fedora 7 (for comparison) as I didn't have an i18n file set up
when I used gdm under Fedora 7.  I can test that out also however if that would
be useful.

My .bash_profile .bashrc and other login related files are all stock Fedora 8
and unmodified so far, so no chance of interference from that.  Also, I do not
have any homemade .xinitrc or similar scripts set up.  Just a pretty stock
Fedora 8 installation with default config files, etc.

I'm going to go try a "startx" session now to see how that goes.

Comment 1 Mike A. Harris 2007-11-09 04:22:58 UTC
Created attachment 252411 [details]
i18n config file

Comment 2 Mike A. Harris 2007-11-09 06:02:29 UTC
Here's another test I just did:

pts/5 mharris@hammer:~$ locale
pts/5 mharris@hammer:~$ unset LANG
pts/5 mharris@hammer:~$ exec bash -login
pts/5 mharris@hammer:~$ locale

So, if LANG is unset when lang.sh is processed, the correct thing does actually
happen.  This implies to me that:

- gdm based X startup is not happening within a login shell
- /etc/sysconfig/i18n is not getting sourced manually (nor $HOME/i18n)
- something somewhere is setting just the LANG environment variable, which
causes later login shell processing of /etc/profile.d/lang.sh to occur with LANG
set, causing all other settings in /etc/sysconfig/i18n to end up being ignored.

Comment 3 Mike A. Harris 2007-11-09 08:55:53 UTC
Ok, I've rebooted into runlevel 3, logged in as "mharris", ran startx, and
opened up a terminal.  The locale environment was properly propagated:

pts/1 mharris@hammer:~$ locale

Looks like this is definitely a problem with gdm based X server startup
somewhere along the line.  grepping /etc/X11 didn't yield any obvious clues though.

A quick ugly hack might be to hack Xsession (or the appropriate files for
gdm/kdm if they still have their own local hacks) to have:

unset LANG
. /etc/profile.d/lang.sh

although that'd only be a horrible hack workaround if it works.

Comment 4 Lassi Pölönen 2007-11-13 13:39:46 UTC
I'm not sure if this is releated but there's "ugly hack" in
/etc/gdm/locale.alias which is not real locale.alias (explained in file's
comments). There are defined the languages one can choose from gdm's login
screen. If I choose for example Finnish, the LC_* are set to fi_FI.UTF-8 without
honoring /etc/sysconfig/i18n (the file says LANG is en_US.UTF-8). That makes
also me believe somehow gdm doesn't undertand the locales except LANG.

Comment 5 Mike A. Harris 2007-11-15 13:14:05 UTC
Yeah, it looks like gdm is breaking OS standards.  Not sure if the problem is
also present under kdm or xdm, but I'll try those in the future as well.

Comment 6 Tomasz Ostrowski 2007-11-24 17:47:28 UTC
The same problem is with user i18n setting in $HOME/.i18n file. It is ignored.
This is very annoying as it is very useful to have for example english messages:
but native language sorting
etc. It is much easier to find online help in english searching for english
failure message than localized one.

It should not be ignored at least when "System Default" language is chosen at
login screen.

Comment 7 Marcin Zajaczkowski 2007-12-08 19:36:19 UTC
I also use LANG=en_US.UTF-8 for English texts, but locale like time, monetary,
etc. have in Polish (by changing /etc/sysconfig/i18n). It worked up to FC6 (not
tested in F7).

Other locales seem to be taken from LANG and propagated to all started GUI
application (so "LC_TIME=pl_PL.UTF-8 some-graphic-app" doesn't work).
I'm using Gnome.

Comment 8 Jens Petersen 2008-02-07 05:37:29 UTC
AFAIK this also still happens with rawhide.

Comment 9 Radek Liboska 2008-02-15 09:34:38 UTC
Still not fixed! In my opinion it is a serious bug. Probably "severity:low" and
"priority:low" bugs are ignored by Redhat people.

Comment 10 Ray Strode [halfline] 2008-02-15 14:03:41 UTC
This should be fixed now.  If it's not, I'll need to investigate.

(Note I don't ignore severity:low and priority:low bugs.  In fact, I ignore
severity and priority entirely, since people frequently set their pet peeve bugs
to "urgent")

Comment 11 Christian Menzel 2008-02-15 16:49:33 UTC
In which package is it fixed? Is the package already available in Updates?

Comment 12 Ray Strode [halfline] 2008-02-15 22:34:44 UTC
This bug is filed against rawhide.  If it's a problem in F8 too then it'll need
a separate fix there.

Comment 13 Christian Menzel 2008-02-15 22:48:56 UTC
Well, the description says Fedora 8. And I can confirm the bug exists in F8.
Could someone with the appropriate rights change the version info of this bug to
8 or should we file a new bug?

Comment 14 Jens Petersen 2008-02-21 02:31:54 UTC
Should gdm still be respecting "$HOME/.i18n"?

Comment 15 Ray Strode [halfline] 2008-02-21 15:04:39 UTC
not specifically.

gdm runs the Xsession script which ensures that exactly one login shell is run
(which runs /etc/profile)

It may have some logic for ~/.i18n.  not sure.

Comment 16 Stephanos Manos 2008-03-03 20:02:48 UTC
When is the fix going to show up?

XDM and KDM respect my $HOME/.i18n  (as GDM did in F7 and prior).

Comment 17 Jarkko 2008-04-20 00:49:45 UTC
The guess the guilty file is: /etc/profile.d/lang.sh

It used to be like this:
for langfile in /etc/sysconfig/i18n $HOME/.i18n ; do
    [ -f $langfile ] && . $langfile && sourced=1

Now it is like this:

if [ -n "$LANG" ]; then
    for langfile in /etc/sysconfig/i18n $HOME/.i18n ; do
        [ -f $langfile ] && . $langfile && sourced=1

Comment 18 Ray Strode [halfline] 2008-04-21 01:49:52 UTC
Oh yea, I talked to jensp about this on IRC.  The bug report that mentions that
change has notting saying "I've commited this change, but I bet it will break
something".  He jinxed us all.

 /etc/sysconfig/i18n and ~/.i18n should be loaded separated since we want the
former to be a default and the latter to be an override.

Comment 19 Jarkko 2008-04-21 05:30:18 UTC
It works like that. Because $HOME/.i18n is after /etc/sysconfig/i18n there,
$HOME/.i18n overrides /etc/sysconfig/i18n.

Comment 20 Jarkko 2008-04-21 05:39:39 UTC
Sorry guys. I was wrong about /etc/profile.d/lang.sh being the guilty file. (Or
it could still be, but the older configuration does not make this bug go away.)

I wasn't using F8 box at the time I wrote that comment about
/etc/profile.d/lang.sh. Now I am. I tested with the older config, and it doesn't
have any effect unfortunately.

Comment 21 Jarkko 2008-04-21 06:07:15 UTC
X/gdm/gnome must be reading and setting locale stuff by itself. Whatever I test
in /etc/profile.d/lang.sh does not have any effect at all. I even did this in

export LANG
exec /usr/sbin/gdm-binary "$@"

$ cat /etc/sysconfig/i18n

I ended up in a gnome session with en_GB.UTF-8 set to all locale variables,
LANGUAGE being unset.

$ env | grep LANG

So X/gdm/gnome must be reading /etc/sysconfig/i18n by itself. It reads that
LANGUAGE is en, and then overrides LANG with it...

Also previously GDM_LANG was only set, if something else than the default
language was being used. Now it is always set.

Comment 22 Andy 2008-04-21 16:46:09 UTC
**** For Rawhide ****

I can ack the thing Jarkko stated above:
GDM doesnt respect /etc/sysconfig/i18n nor $HOME/.i18n.

But... the GDM_LANG gets set on the new GDM Login screen.

Reproduce it:
Select a User to Login -> On the Bottom of the screen pops a "language"
dropdown. If you choose the Language there, it's getting right.

The "confusing" thingy. The "Set Language on System/Administration" turns
useless if you dont choose the right language on GDM Login !!!

This is imho a HIGH Priority Bug in Rawhide (because there will be a _lot_ of
confused users), at final F9. imho...


Comment 23 Bill Nottingham 2008-04-21 16:52:46 UTC
> Reproduce it:
> Select a User to Login -> On the Bottom of the screen pops a "language"
> dropdown. If you choose the Language there, it's getting right.
> The "confusing" thingy. The "Set Language on System/Administration" turns
> useless if you dont choose the right language on GDM Login !!!

This has *always* been this way. system-config-language sets the default
language; users are free to choose a different one in GDM.

Comment 24 Jarkko 2008-04-22 11:17:12 UTC
What I meant was that previously GDM_LANG was the variable which showed up only
if the user picked a language from the dropdown. If it was around, it told that
the default language had been overridden. Now it seems to be always present.
Perhaps (and probably) this does not have any effect for the behavior in this
bug (it might tell us something though), but it's just a thing I noticed.

Perhaps Andy has saved his language selection. Then you don't get the system
default language but your own GNOME session default language.

GDM login screen follows the system language by default (it can be started with
another language, but by default it follows the system default). GDM login
screen also actually properly follows /etc/sysconfig/i18n. So this bug happens
with GNOME session (perhaps with other environments as well - I haven't tested)
- not with GDM login screen.

If you create another user account, you should be getting the system default
language by default. And if you then change the system default, your GNOME
session will be in the new language accordingly.

If you choose a language from the dropdown and then save that selection, you
will always get GNOME in that language - unless you explicitly choose another
language from the dropdown again.

This bug is about: GNOME (at least - I don't know if others too) does not
execute /etc/profile.d/lang.sh but perhaps reads /etc/sysconfig/i18n on its own
and reads only $LANG from it - or GDM sends only $LANG to GNOME.

GNOME reading /etc/sysconfig/i18n does not feel probable because that would mean
Fedora patching GNOME to do that. The most probable cause for this weirdness is
that GDM only sends $LANG to GNOME. If that is true, this happens with all
environments. Also, then this bug is in GDM itself - not in the X initscripts.
Another possibility is that GNOME does not read other variables than $LANG.
(Then this does not happen with other desktop environments.)

Perhaps this is a common GDM/GNOME bug from upstream and not about
initscripts..? We should test if this happens with all desktop environments or
only with GNOME. If it happens with GNOME only, GNOME has the bug. If it happens
with all, it is either initscripts or GDM. Because I can't find anything from
the scripts, my money is on GDM. :)

Comment 25 Jarkko 2008-04-22 11:44:27 UTC
It's definitely not GNOME. I just tested this:

1) I logged out from the GNOME session started from GDM

2) I went to the console side, logged in there

3) I executed: startx -- :1

--> I got everything as configured in /etc/sysconfig/i18n

So this is related to GDM. It is either GDM or some scripts related to GDM.

Comment 26 Jarkko 2008-04-22 11:52:08 UTC
Now I installed xmd, ran telinit 3, started xdm... Logged in from the xdm login
screen and... I got everything as configured in /etc/sysconfig/i18n - again.

This must be a bug in gdm itself - coming from upstream.

So, this bug should be reassigned to: gdm

Comment 27 Jarkko 2008-04-22 11:59:25 UTC
I know this corrective comment is not necessary, but I can't resist correcting
myself. :)

I of course meant I installed xdm - xorg-x11-xdm to be precise.

$ rpm -q --whatprovides xdm

Anyways, clearly as this happens only with gdm, it is very unlikely that
initscripts is responsible for this. I bet gdm has the bug.

I could test by starting xdm with the exact same command that /etc/X11/prefdm
uses though... But I would be very surprised if xdm started to behave
differently then.

Comment 28 Jarkko 2008-04-22 12:15:57 UTC
Okay... I tested that by setting XDM as DISPLAYMANAGER in
/etc/sysconfig/desktop. The result: I got everything as configured in
/etc/sysconfig/i18n - as expected.

I also tested to run "gdm" manually from the command line. It does not have any
effect weather gdm is started from /etc/X11/prefdm (inittab) or manually.

--> This bug must be in gdm itself - coming from upstream. I think my tests show
that initscripts is not the one to blame. There aren't any gdm specific scripts
in the initscripts package even (judging from rpm -ql output).

This bug should be reassigned to gdm because gdm must be the one with the bug.

The bug in gdm might be something like... When the desktopt environment is
started, only LANG is sent to the environment. Perhaps the environment is
started with some kind of exec like call and only LANG is sent with the call...

Comment 29 Ray Strode [halfline] 2008-04-22 18:23:26 UTC
Let me explain what's going on.

lang.sh has something like...

1) if LANG isn't set, source /etc/sysconfig/i18n and ~/i18n
2) if GDM_LANG is set, force LANG to be GDM_LANG 

before bug 229102 it had

1) even if LANG is set, pull LANG from /etc/sysconfig/i18n and ~/i18n
2) if GDM_LANG is set, force LANG to be GDM_LANG

gdm no longer sets GDM_LANG in addition to LANG.  It used to set both.  We can
add that back if we really need to, but it doesn't offer a lot, so I'ld like to
avoid it.

What it should probably be is.

1) if LANG is set, save LANG to SAVED_LANG
2) source /etc/sysconfig/i18n and ~/.i18n
3) if SAVED_LANG is set, restore LANG from SAVED_LANG

Also, lang.sh has this variable "sourced" which means "pass the LC_ variables
set in /etc/sysconfig/i18n through to the session", but it sometimes gets set
when /etc/sysconfig/i18n isn't sourced so there are no LC_ variables to pass

Comment 30 Ray Strode [halfline] 2008-04-22 18:33:35 UTC
Created attachment 303357 [details]
a potential fix

This is a stab at it.  I haven't tested it.

Comment 31 Bill Nottingham 2008-04-22 19:44:51 UTC
The problem with this is that GDM only sets $LANG, which means that other things
set in /etc/sysconfig/i18n  and ~/.i18n would still take effect (LC_MESSAGES,
LC_COLLATE, etc.) and there would be no (simple) way for the user to override
them for their login session.

Comment 32 Ray Strode [halfline] 2008-04-22 20:53:27 UTC
isn't that what we want?  hidden advanced features still working?

Comment 33 Jarkko 2008-04-23 15:47:54 UTC
/etc/sysconfig/i18n sets global language and locale settings. The system (also
GDM/GNOME) should follow those settings by default. This is how GNU/Linux should

~/.i18n overrides those settings (and possibly sets some more). This is also how
GNU/Linux should work.

GDM can override the LANG variable from /etc/sysconfig/i18n and ~/.i18n, but it
really should not override the LC_* variables. If you don't like the idea of
LC_* variables not being overridden, don't set any LC_* variables in

This is what I think. The current behavior doesn't follow the general idea how
the i18n stuff should work. At least I think so.

Comment 34 Ray Strode [halfline] 2008-04-23 15:58:18 UTC
Created attachment 303519 [details]
a better patch

The previous patch had a bug where it would ignore LANG in i18n completely
instead of using it as an overridable default.

Comment 36 Jarkko 2008-04-23 18:27:05 UTC
I'm not totally sure if it's a good or a bad thing to override the LC_*
variables in general (when user chooses some language explicitly from the list),
but one thing is sure (and I think we all think this way):

GDM should not remove any settings (like the LC_* variables) coming from
/etc/sysconfig/i18n and ~/.i18n by default (when no language is selected from
the language dropdown or saved by the user).

I must have been doing something wrong when I tested that the lang.sh script
didn't have any effect. I'll test that again later - with the changes from that
commit. I hope it behaves logically now. :)

Comment 39 Jarkko 2008-04-24 11:22:17 UTC
It's better but not 100% correct.

LC_* variables (and $LANGUAGE) are now passed to the session, but if I have e.g.
LANG="fi_FI.UTF-8" and LANGUAGE="en_US.UTF-8:en.UTF-8" in /etc/sysconfig/i18n,
GDM overrides $LANG to be "en_US.UTF-8" from the LANGUAGE variable.

This is not correct. GDM should not override anything by default. (It should
override when a language is explicitly selected from the list, but by default it
should not change any i18n settings.)

It is better, but not quite right.

Comment 40 Jarkko 2008-04-24 11:27:54 UTC
> gdm no longer sets GDM_LANG in addition to LANG.

gdm-2.20.3-1.fc8.x86_64 does. Either it does set it or a newer version does not

Comment 41 Ray Strode [halfline] 2008-04-24 13:55:00 UTC
f9 gdm should work better in this respect.  Actually the latest 2.20 of upstream
may work better, too.  I can try pushing that to testing.

The gdm in f8 sets GDM_LANG, the one in f9 does not.

Comment 42 Fedora Update System 2008-04-24 14:24:16 UTC
gdm-2.20.5-1.fc8 has been submitted as an update for Fedora 8

Comment 43 Ray Strode [halfline] 2008-04-24 14:33:30 UTC
mind giving http://koji.fedoraproject.org/koji/buildinfo?buildID=47107 a try?

Comment 44 Christian Menzel 2008-04-24 15:11:38 UTC
gdm-2.20.5-1.fc8 works, but one still needs the lang.sh patch to set the LC_*
values, maybe initscripts should be updated as well?

Comment 45 Jarkko 2008-04-25 09:33:02 UTC
I've patched /etc/profile.d/lang.sh according to
from comment #35.

I've installed:
$ rpm -q gdm

I went to runlevel 3 and back to 5 so that I get a "fresh start" for gdm. (I've
noticed that otherwise it might remember previous settings like the i18n stuff.)

At the moment I have this:
$ cat /etc/sysconfig/i18n

I don't have any saved language preference for my GDM/GNOME session. So I should
get the system default i18n settings, when I log in without choosing any
language from the list.

This is what is set after login:
$ env | grep LANG
$ locale

So yes, it is working logically now. First I thought "but it *does* set
GDM_LANG", but hey - this is not F9. :) So this is normal I guess.

If we really want to make GDM (and other login managers as well) behave totally
logically, we should improve the lang.sh (and lang.csh) patch a little bit more.
The 100 % correct way to behave would be to save all locale and language related
variables (plus _XKB_CHARSET - all variables which the lang.sh script exports)
before sourcing i18n configuration files. That way things like:

# LC_MESSAGES="en_US.UTF-8" gdm

...would actually work. I bet that doesn't work at the moment, because lang.sh
only "remembers" the LANG variable.

Comment 46 Jarkko 2008-04-25 10:02:36 UTC
Created attachment 303769 [details]
Handle all exportable variables

This patch adds handling of all the variables (not only LANG) that the lang.sh
script exports.

The patch is against

from comment #35.

Comment 47 Jarkko 2008-04-25 10:13:16 UTC
Uups. Sorry, the patch is not against that version from the git repository. :)

It is against the version in F8 + saved_lang from that git commit...

Comment 48 Jarkko 2008-04-25 10:19:24 UTC
It doesn't matter though. I created a new patch against that version from the
git repository --> no changes to the actual patch.

Comment 49 Jarkko 2008-04-25 10:35:52 UTC
Created attachment 303770 [details]
Handle all exportable variables (cleaned version)

I cleaned the patch a bit. This takes fewer lines and is perhaps more readable.

Comment 50 Jarkko 2008-04-25 13:00:31 UTC
About the overriding...

I think gdm should override LANG, LANGUAGE and LC_MESSAGES when the user selects
a language from the list (or have saved the selection). Otherwise the user
doesn't necessarily get the selected language in all cases. BUT notice: I think
this functionality does not belong to the lang.sh script. gdm should do that by

Now that we have lang.sh respecting pre-existing variables (if you commit my
patch of course :)), gdm can do the override. gdm should just unset LANGUAGE and
LC_MESSAGES when it sets LANG in that case (not always - just when the user
chooses a language from the list or has a saved language). It should be an easy
change I think.

Comment 51 Jarkko 2008-04-25 13:30:19 UTC
Created attachment 303782 [details]
Handle all exportable variables (csh version)

This patch adds handling of all the variables (not only LANG) that the lang.csh

script exports.

The patch is against

from comment #35.

Comment 52 Bill Nottingham 2008-04-25 17:19:50 UTC
I'm not sure I like this idea, if for no other reason than it really uglifies
the scripts. What's the usage case for this? When would you want to set this in
a way other than using ~/.i18n?

Comment 53 Jarkko 2008-04-25 17:54:02 UTC
It would be possible to run the graphical environment in different
language/locale than the system by setting (exporting) the variables before the
display manager starts. Is it needed? Perhaps - perhaps not. But it would be
possible. (I can imagine that sometimes people could want to run the system in
English, but the graphical environment in the local language.)

Setting the language from the language selection list could be handled by gdm.
(Which would be the architecturally correct way.)

If we think about logic... If we override LANG, we should override all the
variables. That would be the most consistent behavior.

Is this *really* needed? I don't know... But handling all the pre-existing
variables we export would be the most logical thing to do.

Comment 54 Jarkko 2008-04-25 18:28:16 UTC
Actually we can't do what I suggested in the patches. I don't like my idea
either. :)

The lang.sh and lang.csh scripts are part of what gets run when /etc/profile is

I believe /etc/profile should reset all environment variables to the values
configured in system configuration. For example, if LANG is "en_US.UTF-8" and
I've changed it to, let's say "fi_FI.UTF-8", and I then execute /etc/profile...
The correct behavior then is, that LANG resets back to the original value -

I think we should replace the saved_lang idea with GDM_LANG. We should not
support any pre-existing values for the variables we export. GDM_LANG is not one
of those, so if GDM_LANG would be set, it would be okay to override LANG with it
(and also unset LANGUAGE and LC_MESSAGES).

Comment 55 Jarkko 2008-04-25 19:34:56 UTC
Actually we broke the fix for bug #229102. :) The saved_lang idea only saves
$LANG. Other passed variables a overridden from i18n configuration.

The only way that could be avoided would be to use my patches.

I just wonder if it's correct if /etc/profile does not reset all variables.
Either way, something breaks. :)

Comment 56 Jarkko 2008-04-28 12:15:22 UTC
When passing locale and language variables between systems, the correct behavior
is to either use the local or the remote settings - not to mix them!

1) My patches would mix them (if the ssh client side sends some new variables,
they would be exported to the session causing e.g. situations where we have
latin and unicode variables existing at the same time). --> Not good.

2) The current fix (the commit) also mixes them (if the local side has other
settings also than LANG, and the client side then sends different encoding in
$LANG). --> Not good.

3) The previous way didn't mix them. But GNOME didn't start with all i18n
settings, and also I'm not sure if the passed variables through ssh were
exported properly to the session. --> Buggy and not perfect.

How to make this work correctly?

Well... To begin with, the exporting should always happen I think - so that we
can be sure the variables are actually exported to the session (and not just to
the currently running application like gdm or bash).

Secondly... We should either use only values from the i18n configuration or only
from the pre-existing settings (like coming through ssh). How to actually
properly accomplish this, I'm not sure... The problem with gdm is that it sets
LANG by itself but only LANG... Could this work if gdm would only set GDM_LANG
and leave the actual environment stuff to /etc/profile scripts..? The other
solution which comes to mind is that gdm sources the i18n configuration files by
itself... (And /etc/profile would then just run an export for them.)

Comment 57 Jarkko 2008-04-28 14:21:10 UTC
I think this is the only way to properly solve this:

* If (and only if) LANG is _not_ set, source /etc/sysconfig/i18n and ~/.i18n.

* Does sshd export the variables it receives from the client? If not, we need to
execute the exporting part of the script every time. If it does, we naturally
only need to execute the exports when the i18n configuration files are sourced
by the lang.sh/lang.csh script.

--> gdm should not set LANG if it does not source /etc/sysconfig/i18n and
~/.i18n by itself. Either make gdm to source the i18n configuration files (and
either export the variables already by gdm or later in the lang.sh/lang.csh
script) or add GDM_LANG back and _do not set LANG_ in gdm - or somehow make sure
the i18n settings are already exported when gdm login is executed (and handle it
so that LANG gets exported if it is changed by gdm).

If we don't change the system drastically, this would mean in practise, that gdm
would only set GDM_LANG (not LANG at all) if it changes the default LANG value.
Then the lang.sh/lang.csh script would know to change LANG to be GDM_LANG.

Comment 58 Jarkko 2008-04-28 16:27:21 UTC
Actually this can of course be done even if gdm sets LANG - if it also sets
GDM_LANG. (We can sourse i18n conf always if GDM_LANG is set.)

The other solution could be to somehow determine that we are on a ssh session
(perhaps some variable tells us this).

Comment 59 Bill Nottingham 2008-04-28 16:39:42 UTC
I think this can be closed - the X case is certainly handled.

Comment 60 Jarkko 2008-04-28 19:17:05 UTC
Created attachment 304029 [details]
Handle the SSH case

Now I got it! This way it works properly.

Both the X and the SSH case are handled correctly doing it this way, I think -
and no need for GDM_LANG. Everybody's happy. :)

I know the SSH case is a separate issue, but because the fix for this bug
affected the SSH case bug, here is the fix for that effect.

This patch is against the latest version from the git repo.

Comment 61 Jarkko 2008-04-28 19:32:59 UTC
Created attachment 304034 [details]
Handle the SSH case (csh version)

Here is the csh version.

This patch is against the latest version from the git repo.

Comment 62 Jarkko 2008-04-29 07:35:52 UTC
I'm sorry for sending so many comments to this bug! This should be my last
comment now.

Tested the lang.sh patch (lang.csh is identical in its logic):

Works correctly with X and with SSH.

Please commit the patches to the git repo. Thank you.

Comment 63 Bill Nottingham 2008-04-29 13:47:45 UTC
At this point, probably not until after F9 final.

Comment 64 Bill Nottingham 2008-04-29 15:54:08 UTC
I did something different, but similar.


If LANG is set, read the user customizations (and keep that LANG).
If LANG is not set, read the system and user customizations.

Not intending to touch this again for a while. :)

Will be in 8.74-1.

Comment 65 Jarkko 2008-04-29 19:56:39 UTC
Sorry! One more comment coming up. :)

That is actually a very elegant solution. I really like it! :)

With X: It supports all the default system and user settings when no language is
selected. Then when a language is selected, it actually sets the whole
environment to the selected value (you get what you ask by default, which is
logical). But still if you want to use some LC_* settings with all languages,
you can - by defining them in ~/.i18n. --> It does by default the expected
thing, still being very customizable.

With SSH: It supports all the settings the client sends. This is a very good
thing because this way the character sets won't get mixed. And again, still,
there can also be local overrides, if this is what the user wants - using
~/.i18n. (Remember here also that very often the home directory is shared
between multiple hosts. Supporting also ~/.i18n is sometimes useful.) --> It
does by default the expected thing, still being very customizable.

Please *don't* touch this for a while. :)

This 8.74-1 is coming to F9?

It might be a good idea to release this change as a F8 update too. That was
requested by Christian Menzel in comment #44.

Anyway, thanks! I really like the solution.

Comment 66 Fedora Update System 2008-04-29 20:58:37 UTC
gdm-2.20.5-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gdm'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-3389

Comment 67 Jarkko 2008-04-30 09:14:38 UTC
"If problems still persist, please make note of it in this bug report."

The lang.sh/lang.csh script is ok now (I'm using the latest from the git repo),
but now gdm (at least gdm-2.20.5-1.fc8) has a bug:

It sets LANG always (and this F8 version also sets GDM_LANG, but that doesn't
matter anymore + F9 version doesn't set it anymore anyway).

It really should not do that when there is no language selected from the list or
the user has not saved a preference. Now that it always sets LANG,
lang.sh/lang.chs thinks that the locale was overridden by gdm. -->
/etc/sysconfig/i18n is not sourced when it should be.

Comment 68 Ray Strode [halfline] 2008-04-30 14:01:10 UTC
I think GDM should make sure LANG is always set since having it unset provides a
less than working experience.

lang.sh should account for that.

Comment 69 Jarkko 2008-04-30 14:15:15 UTC
The problem with gdm now is that it removes everything else but leaves LANG.

gdm itself has the environment properly set (environment is in place when gdm is
started), but it doesn't pass it to the X session.

Perhaps the solution is to make gdm to pass the environment to the X session. At
least LANG, LC_*, LANGUAGE and LINGUAS should be passed to the X session. Either
only them all just the whole environment.

Comment 70 Fedora Update System 2008-05-10 13:49:45 UTC
gdm-2.20.5-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 71 Tony Fu 2008-09-10 03:18:46 UTC
requested by Jens Petersen (#27995)

Comment 72 Bug Zapper 2008-11-26 08:15:08 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 73 Mike A. Harris 2009-03-11 08:52:55 UTC
My bugzilla bug emails were vanishing into a void due to a .procmailrc glitch so I reviewed this bug just now.  Due to the problem I initially reported, I switched to using "startx" as a temporary workaround, but just kept using it like that.  Unfortunately I never noticed the progress made on this issue above so never tried to test any of it.  My bad.  ;)

Glad to see the issue was tackled and presumably resolved in erratum and rawhide et al.

I'm currently using CentOS 5 with no easy way to test current Fedora releases for my originally reported issue, so I'll assume it has been resolved and when I get a chance to bang on a newer release in the future I'll check it out.

Thanks for giving attention to this issue guys!

Comment 74 Jarkko 2009-03-11 10:40:26 UTC
Well... :)

One thing is clear in my opinion: initscripts handles this correctly. I think there's no bug in initscripts regarding this. The lang.sh/lang.csh handles this in a general and correct way IMO.

If you find this isn't still working as it should, I think no bugs should be applied (or this one reopened) against initscripts. Instead, in such case IMO it's a bug in the actual application... Which means in practise:

If you think this still isn't working as it should, you should file a new bug against gdm because then it's gdm which doesn't work like you think it should. :)

Regarding gdm... It depends on how you see its language selection I guess (what the selection is actually about; if it's about selecting LC_MESSAGES or about selecting full locale).

If the gdm's language selection is seen as full locale selection, gdm behaves correctly when it resets the /etc/sysconfig/i18n locale settings by resetting env and then setting its own locale settings - in practise, LANG. (Btw. If the language selection is actually about full localization, perhaps it should use the term locale or similar in the UI instead of language...).

Also... The current GDM doesn't have a "default system language/locale" selection anymore like it used to, so it doesn't have to support the system locale settings (if the selection is seen as full locale selection instead of just language (LC_MESSAGES)).

If you think it's not good that way, perhaps some kind of feature request should be filed for gdm... I don't know as this all depends on how you even see gdm should work... But the general solution at initscripts is IMO correct and that shouldn't be touched again. :)

Comment 75 Mike A. Harris 2009-03-11 12:51:18 UTC
I filed the bug originally against xorg-x11-xinit as that initially seemed where the problem was.  After exporing the issue briefly it was determined to be a problem caused by gdm.

All I personally care about, is the original problem that I filed.  Feel free to file your own bug report against the package you feel most appropriate however if the issue you were personally having is unresolved.

Comment 76 Jarkko 2009-03-11 19:07:01 UTC
This is how it is in F10:

1) The system in general respects /etc/sysconfig/i18n

* If you log into a local text console, you get what you've set to /etc/sysconfig/i18n (~/.i18n overrides).

* So if you run startx you naturally get /etc/sysconfig/i18n + ~/.i18n

* This means also that the gdm login screen respects /etc/sysconfig/i18n (if you e.g. change LC_TIME, the clock at the login screen's bottom right corner gets localized accordingly).

* ~/.i18n is always applied. This means that if you log in with ssh to the machine, ~/.i18n overrides the locale settings (with ssh, it's actually by default more complex: /etc/sysconfig/i18n + remote locale settings + ~/.i18n).

--> In my opinion this is correct behavior. And I doubt anyone disagrees.

2) The new gdm does not have a feature like "default system language/locale". You always select the language (of course it suggests something by default which is your last selection or if you've never changed it, it's the system's LANG from /etc/sysconfig/i18n).

* The gdm's language selection behaves actually like a locale selection. It's a fully localized language selection. (At least this is how it works, so I guess the GNOME/Fedora developers see it as such - because why would gdm be resetting the environment otherwise there. So it doesn't take anything from /etc/sysconfig/i18n as it sets the whole locale of the X session to the selected locale. Technically gdm does this by resetting the environment and then setting LANG. When LANG is already set, the system's profile scripts don't override it and possible other locale variables.)

* Also here, ~/.i18n is always applied. So if you put e.g. LC_* variables there, they are propagated to your X session.

--> Is this correct behavior? If you see the language selection as a fully localized language selection (= a locale selection), then I think it actually is correct.

I personally think it's perhaps best the way it is now because:

1) The selection actually sets the language always to the selected value. (Imagine if you had LC_MESSAGES in the system's locale configuration. Then the gdm's language selection would not seem to work at all. That could be confusing.)

2) In some cases the fully localized language is really what you want. E.g. in big user environments you don't want the same LC_* settings to be applied to all X sessions.

3) ~/.i18n works so you can always do what you need.

So I'd say all is good. But that's of course my opinion only. :)

Comment 77 Dmitry Bolkhovityanov 2013-04-28 11:38:27 UTC
(In reply to comment #76)
> 3) ~/.i18n works so you can always do what you need.
> So I'd say all is good. But that's of course my opinion only. :)

Unfortunately, this is NOT good. Current behaviour breaks the general principle "administrator sets system-wide preferences in /etc/, user can override in ~/.-files".
With current buggy GDM approach it is impossible to set separate values for different locale categories globally.

And GDM is the ONLY one which exibits such non-compliant behaviour.

Comment 78 Jarkko 2013-04-28 14:25:49 UTC
IIRC what I meant was that the initscripts part of this is correct. GDM is the one to blame here. GDM resets the locale settings.

Note You need to log in before you can comment on or make changes to this bug.