Re: kdm locale problem
On 11 Jun 2003 LeVA <email@example.com> wrote:
> I am using Debian with woody (stable) packages. This comes with xfree
> 4.1.0. I have added an apt source for the new kde binaries
> (http://download.kde.org... etc...). I have installed kde 3.1.2 from that
> apt source. Everything is just fine :)
> Yeah it is working. The kdm runs, and I am using 4.2.1 xfree. But you
> know in every good thing, there is something bad :) And here comes the
> real problem:
> If I start kde from kdm, I lose my localisation settings in kde. I am
> using hu_HU in locales. If I start kde from a console with startx,
> everything is Ok. But when I am starting kde from kdm, the programs that
> uses the translated .m4 or .po files, or just have some translated files,
> does not seems to be in hungarian language (ex.: xchat, licq). They are
> in english.
> In the kde control center, I can set up kdm to display the kdm buttons
> and messages (login, shutdown etc...) in hungarian. So that is ok. The
> problem is when I start kde from the kdm login manager, it seems, that
> kdm "resets" the localisations, and sets the lang to en, or en_US (or
> something like that). If I start a konsole from kde, and run this:
> echo $LANG
> I get "hu_HU".
Sounds like the locale for X sessions is not set to 'hu_HU', or probably not
set at all and therefore defaulting to 'C', while it is set to 'hu_HU' for
virtual consoles and shells in X terminals. This can easily happen because
the startup scripts that are run for shells and X sessions are not the same.
I am not using kdm and KDE but xdm and Gnome, and with that setup xdm calls
the user's .xsession script to start the X session, with the last line in
that script being a call to gnome-session to start Gnome. This means that
every user can set the locale for X sessions to his/her liking by inserting
export LANG=<locale> LC_ALL=<locale>
into his/her .xsession before the call to gnome-session. I assume something
similar can be done when using kdm and KDE.
It pays to study man bash (or man tcsh or man <whatever shell one uses>) to
learn what startup scripts are read under what circumstances. Issues to be
aware of are (in the following the use of xdm and bash is assumed but similar
considerations apply to other graphical logins and shells, I believe):
- xdm replaces login but does not set up the environment in exactly the same
way as login does, for instance xdm does not set MAIL.
- the shell of an X terminal is not a login shell (the user is already
logged in through xdm) so the startup scripts for login shells,
/etc/profile and ~/.bash_profile in the case of bash, are not executed!
This easily causes the environment of shells on virtual consoles to be
radically different from the environment of shells in X terminals.
- environment variables have to be set only once and are inherited by all
processes that are children of the login shell or the X session,
but things like aliases and shell options have to be set every time
a shell is started.
To ensure that:
- the environment is the same in all shells
- X programs know the same environment variables as shells
- on startup shells do not read more startup scripts than necessary
I did the following:
- put all settings of environment variables in /etc/profile and ~/.bash_profile
- put all aliases and shell options in /etc/bash.bashrc and ~/.bahsrc
- made /etc/profile source /etc/bash.bashrc
- made ~/.bash_profile source ~/.bashrc
- made ~/.xsession source both /etc/profile and ~/.bash_profile,
after setting a variable that to /etc/profile and ~/.bash_profile signals
that they have been sourced by ~/.xsession;
in that case they do not need to source /etc/bash.bashrc resp. ~/.bashrc,
and instead unset that environment variable.
- have default versions of .bash_profile, .bashrc and .xsession in which the
above is implemented available in /etc/skel.
With this recipe it should be sufficient to put
export LANG=hu_HU LC_ALL=hu_HU
to make Hungarian the system-wide default for all programs,
while every user can put a line
export LANG=<locale> LC_ALL=<locale>
to choose another language, provided the locale of that language is installed.
Hope this solves your problem
Anjelierstraat 1, 2014 TC Haarlem, Netherlands
tel +31 23 5324909, firstname.lastname@example.org