Bug 199324 - user LANG settings are ignored
user LANG settings are ignored
Status: CLOSED DUPLICATE of bug 199323
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-18 17:35 EDT by Sam Steingold
Modified: 2008-08-02 19:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-28 09:10:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sam Steingold 2006-07-18 17:35:04 EDT
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 
LANG="en_US.UTF-8"
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
ru_RU
$

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:
always

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

Expected results:
LANG is xterm is "BAR"
Comment 1 Leon Ho 2006-08-28 01:49:49 EDT
The user LANG preference should be stored in ~/.i18n instead. Can you reproduce
with it again?
Comment 2 Sam Steingold 2006-08-28 09:10:03 EDT

*** This bug has been marked as a duplicate of 199323 ***

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