Bug 199323 - user LANG settings are ignored
Summary: user LANG settings are ignored
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 5
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
: 199324 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-18 21:34 UTC by Sam Steingold
Modified: 2014-03-17 03:00 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-04-17 00:04:37 UTC

Attachments (Terms of Use)

Description Sam Steingold 2006-07-18 21:34:10 UTC
Description of problem:

my linux (fc5) box is shared by several people, 
so it runs at runlevel 5 with several virtual consoles.
a user finds an unused virtual console, 
logs in and types at the bash prompt "startx -- :1"
or "startx -- :2" etc, depending on which server is available.
the users switch between their X/gnome desktops using Ctrl-Alt-F[789].

now, the "global" setting for LANG in /etc/sysconfig/i18n is 
which is what "most" users want.

Now, the dissident users that want to use a different locale try to set LANG
in their ~/.bash_profile and, indeed, after they login in the virtual console,
they observe the correct value of LANG:
$ echo $LANG

alas, when they open a gnome-terminal in X, the value of LANG is reverted to 
the system-wide default "en_US.UTF-8".

So, how can different users use different locales?

How reproducible:

Steps to Reproduce:
2.~/.profile:export LANG="BAR"
3.login on a virtual console
4.echo $LANG ==> "BAR"
7.echo $LANG ==> "FOO"
Actual results:
LANG in xterm is "FOO"

Expected results:
LANG is xterm is "BAR"

Comment 1 Matthias Clasen 2006-08-04 02:00:18 UTC
Users can select a language in the gdm login screen, and make it the default
for future sessions. gdm stores this information in ~/.dmrc

Comment 2 Sam Steingold 2006-08-04 03:19:43 UTC
I am NOT running xdm or gdm.

Comment 3 Ray Strode [halfline] 2006-08-04 04:13:56 UTC
Are they putting it in ~/.profile or ~/.bash_profile ?

Note bash will only source one of those files (~/.bash_profile) if both exist.

If your users are putting it in ~/.bash_profile and they have 

if [ -f ~/.bashrc ]; then
  . ~/.bashrc

at the top of the file, then they must put it after that.

The language is probably getting reset by

Comment 4 Sam Steingold 2006-08-05 03:48:28 UTC
(In reply to comment #3)
> Are they putting it in ~/.profile or ~/.bash_profile ?
> Note bash will only source one of those files (~/.bash_profile) if both exist.

come on! please read the original report: the LANG variable IS SET
after the login at the virtual console.
it gets reset when I run startx

> The language is probably getting reset by
> /etc/profile.d/lang.sh
so it appears that the users must put their settings i18n in ~/.i18n -
maybe /etc/profile.d/lang.sh should test if LANG is already set before
resetting it by sourcing /etc/sysconfig/i18n?

Comment 5 Sam Steingold 2006-08-05 03:50:42 UTC
since /etc/profile.d/lang.sh is in initscripts, I am changing the component.

Comment 6 Ray Strode [halfline] 2006-08-05 05:04:41 UTC
Oh, I think i know what's going on...

Note when you start a gnome-terminal instance, it starts an interactive,
non-login shell, and when you login from a virtual console it starts an
interactive, login shell.

/etc/profile.d/lang.sh only gets run in the case of a non-login shell.

On the other hand, .bash_profile *doesn't* get run when you start a non-login shell.

.bashrc will get run if you start an interactive shell though. 

So, if you make sure 

export LANG=ru_RU.utf8 

is at the bottom of .bashrc (not above the bit that sources /etc/bashrc), I
think it should work. Using .i18n is better of course.

Does that work okay?

Comment 7 Sam Steingold 2006-08-05 13:15:15 UTC
yeah, OK, but it would still be better if /etc/profile.d/lang.sh did not source
/etc/sysconfig/i18n when LANG is already set (it's OK to source ~/.i18n)

Comment 8 Ray Strode [halfline] 2006-08-06 06:36:38 UTC
Possibly.  That might fix your problem, too.

When you startx, your X session is started through a login shell, so
~/.bash_profile gets read (and your user's language settings get set).

Then when you start a gnome-terminal window, /etc/profile.d/lang.sh gets run and
resets LANG. So if we make the change your suggesting, we won't reset LANG and
things should just work.

On potential problem is that LANG might get set to C or something early in the
boot process and break things for people who don't set LANG in their

Can you do some experiments and see if your change

1) fixes your problem
2) doesn't break things for other people


Comment 9 Sam Steingold 2006-08-28 13:10:08 UTC
*** Bug 199324 has been marked as a duplicate of this bug. ***

Comment 10 Sam Steingold 2006-08-28 13:18:01 UTC
one solution would be:
1. scripting: do NOT run /etc/profile.d/lang.sh if LANG is already set.
2. gui: there should be a user setting specifying LANG. this gui front-end may
write ~/.i18n but it MUST first check that ~/.profile and ~/.bash_profile do NOT
set LANG already so that ~/.i18n is not ignored as mandated by [1].

where is the ~/.i18n hack documented?

Comment 11 Miloslav Trmač 2006-11-10 19:49:37 UTC
(In reply to comment #10)
> 1. scripting: do NOT run /etc/profile.d/lang.sh if LANG is already set.
That would break ~/.i18n completely, it needs to override the system default LANG.

> 2. gui: there should be a user setting specifying LANG.
We have such a GUI included in gdm.

> but it MUST first check that ~/.profile and ~/.bash_profile do NOT
> set LANG already so that ~/.i18n is not ignored as mandated by [1].
Checking whether a general program does or does not set LANG is probably
infeasible, although some kind of hack could solve most cases.

> where is the ~/.i18n hack documented?
Currently nowhere.  I have added a reference to it to the same place
/etc/syscofnig/i18n is documented, which is

Thanks for your report.

Comment 12 Bill Nottingham 2007-04-17 00:04:37 UTC
This is changed somewhat in the current rawhide development trees - LANG is not
necessarily overridden if it's already set. Please test.

Comment 13 Mike A. Harris 2007-11-09 14:04:31 UTC
Whatever was changed here for this bug, might have inadvertently created bug
#372151 which I'm investigating currently.

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