I am located in Germany but I am using English as my main language (German is secondary). YAST is configured English as primary and Germany as additional language.
Following the installation of LEAP 15.1, I found that $LANG is set to “de_DE.UTF-8”. I tried to figure out where this information is set in order have my terminal speak English to me.
I would appreciate very much if someone could point me into the direction of where to fix this problem. Thanx.
You use the imagary “my terminal speaks to me”, but you do not specify any details. Is this terminal a console, or on a terminal emulator in a Desktop Environment, are you using the terminal as root or as another user?
“My terminal” is the bash Konsole (Version 18.12.3), $LANG is de_DE.UTF-8 for both user and root.
However, when switching to a terminal outside the desktop (via ctrl+alt+F2), $LANG is en_EN.UTF-8.
Wilfried
Within the user’s ‘~/.profile’ file, to have that user’s session – equal if per GUI or VT – changed to English, the following line should be present:
export LANG=en_GB.UTF-8
In addition, if it’s a GUI session, the user should check the GUI’s language and country settings after logging in …
@dcurtisfra](https://forums.opensuse.org/member.php/42186-dcurtisfra)
Thank you for your reply, I am sure that will fix the issue. But I would like to understand the root cause of this issue: Why is the setting “de_DE” if the whole system should be in “en_XX”? The primary system language is set to “en_US”, why is the konsole in “de_DE”?
While I do not have a direct solution to your “why” questiosn, IMHO you are not fulle aware of how things work.
LANG is an process environment variable. It is a parameter that can be set (not always for all of them) and read by a running process. It is inherited by child processes.
Thus when a bash process, being a child of a konsole process, itself being a child of one of the processes that are together childs of the DE login process has LANG=“de_DE.UTF-8”. that is so either because it is set during the running of that bash process (mostly done immdetatly after it is started by using .profile and/or .rcbash files) or it has the value inheritid from it’s parents. And the parents have it from the DE configuration files. And those are set by he user (e.g. KDE kanguage settings) or default to the system settings (most often chosen at installation).
Now, what yoy describe is indeed a bit confusing. But giving an answer on how this could be created is a bit difficult. The system itself can have a long history after installation. And duringgthat history, the system deafult may have been changed. As a consequence the values used as default at first usage of a DE by a user may have been different at that time then it would be witha (new?) user that uses the DE now. Also each user may set his/her own preferences (including language(s) used) and change that at will.
BTW, one thing that wonders me specaily is that you say that running bash as user root doews not follow the system here. How do you “become root” in those cases?
Thank you, Henk, for the verbose reply.
Let me start at the end: I logon as normal user (using the account I am mostly using) and open a KDE Konsole via /usr/share/applications/org.kde.konsole.desktop.
> echo $LANG
> sudo echo $LANG
> su …
> echo $LANG
all reply with “de_DE.UTF-8”.
Somewhere along the various profile scripts $LANG (or some other environment variable for that matter) is set to “de_DE.UTF-8”. I just wish I could find out where this happens.
I have another account (normally not used) where $LANG shows always “en_EN.UTF-8” …
Do you have a clue where I should start searching? Any idea on how to debug this issue?
First look in ~/.profile.
There are examples there and the one not starting with # is the active one. When all start with #, it uses a system default.
It’s all a matter of “Locale” – the magic UNIX® multi-lingual support …
> localectl status
System Locale: LANG=de_DE.UTF-8
VC Keymap: de-latin1-nodeadkeys
X11 Layout: de
X11 Model: pc105
X11 Variant: nodeadkeys
X11 Options: terminate:ctrl_alt_bksp
>
> cat /etc/locale.conf
LANG=de_DE.UTF-8
>
As you can see, this system has the System Locale «setup by YaST» set to German.
The setting in the user’s ~/.profile file overrides the system setting for that user’s login sessions …
I guess I found the problem: KDE uses its own “Regional Settings” within the KDE “System Settings”.
Within the Regional Settings, the dialog “Formats” allows you to specify a “Region”: This will determine the LANG environment variable.
As for the issue discussed above, I think the problem is resolved and the thread can be closed. At this time I think KDE behaves rather strange but I will discuss this issue there. Thank you for your help.
Understood but in my configuration it showed (before I found the problem with the Regional Settings within KDE):
wilfried@localhost:~> localectl status
System Locale: LANG=en_US.UTF-8
VC Keymap: de-nodeadkeys
X11 Layout: de
X11 Model: microsoftpro
X11 Variant: nodeadkeys
X11 Options: terminate:ctrl_alt_bksp
wilfried@localhost:~> cat /etc/locale.conf
LANG=en_US.UTF-8
wilfried@localhost:~> echo $LANG
de_DE.UTF-8
wilfried@localhost:~>
For the time being, I have a solution to my problem. Thank you.
Yes, the desktop user (I guess all of them, but certainly KDE) has it’s own settings. They will probably overrule those set in .profile. Well, I am not even sure it ever looks in .profile. For the several sheels it can be read in their man pages and bash uses .profile and .bashrc under differnet circumstances.
KDE tries to help (I assume) the users by letting them choose a Region and it then will set all sorts of environment variables, including language, currency, how to format amounts and dates. Formerly you could strill deviate from what KDE thinks that is standard for a Region. Nowadays that is not possible anymore to the anoyance of many (e.g. many people want an ISO date format rgardless what their region is).
Which is what I mentioned earlier.
- Except that, KDE Plasma normally respects the setting in ~/.profile – assuming that, the Profile setting has been made before the user’s first login …
You seem to have the KDE Plasma Locale settings from your initial login, which have not been overridden by the Profile setting …
- Once you’ve correcting the settings then, everything should be as wished for …
Which, possibly, isn’t strange at all …
OP, I don’t for sure know the answer of where user and system locale settings are initialized, but your question was easily understood, in my opinion:
As root, run yast2, System => Language => adjust Primary Language
Also, yast2 => System => /etc/sysconfig Editor then System > Environment > Language > RC_LANG
Cheers!
The original poster mentioned that, in YaST the primary system language is US English and, the secondary system language is German.
- In addition, because the OP is located in Germany, the system keyboard has the German key layout …
Just for the record, this morning I used my British English Test User for the following test sequence:
- Login as the Test User by means of a VT and, delete everything
in that user’s home directory. 1. “cp --archive” the contents of ‘/etc/skel/’ to the Test User’s home directory – the user “root” is needed to copy ‘.bash_history’ to the user’s home directory … - Logout from the VT.
- Login to the Test User via SDDM – KDE Plasma session.
- The system Locale is “de_DE.UTF-8” – the KDE Plasma user’s Locale also – the KDE Plasma session uses the German language.
- Open a Konsole window and edit the user’s ‘.profile’ – insert “export LANG=en_GB.UTF-8” – save and close the Konsole window.
- Logout from the KDE Plasma session.
- Log back into the KDE Plasma session.
- Et voilà ! – the KDE Plasma session is British English …
- Diving into the KDE Plasma settings, the Spell Checking is British English but, the location (number, time and currency format) is Germany …
It’s possibly advisable to setup the preferred KDE Plasma language to be British English …
It’s possibly not advisable to change the location «application (such as Mail) and timestamp dependencies» – if British English documents are being written then, the number, time and currency format will need to be dealt with manually …
Sure, there is system wide locale:
karl@erlangen:~> cat /etc/locale.conf
LANG=de_DE.UTF-8
karl@erlangen:~>
There is user locale in ~/.profile but also elsewhere overriding ~/.profile:
karl@erlangen:~> cat ~karl/.config/plasma-localerc
[Formats]
LANG=de_DE.UTF-8
karl@erlangen:~>
erlangen:~ # cat ~charlemagne/.config/plasma-localerc
[Formats]
LANG=en_DE.UTF-8
erlangen:~ #
Additional configuration files may be lurking, such as .config/plasma-locale-settings.sh. Thus, whenever problems arise, users may want to create a new user for testing the configuration.
Now, that’s interesting …
Before I setup the British English user KDE Plasma System Settings “Regional Settings” → “Language” → “Preferred Languages” – the GUI was displaying with English – whether or not it was British English wasn’t easily detectable by visual inspection … :
test002@xxx:..Test-Benutzer/test002> cat .config/plasma-localerc
[Formats]
LANG=de_DE.UTF-8
[Translations]
LANGUAGE=
test002@xxx:..Test-Benutzer/test002>
And after setting the “Preferred Languages” to “British English”:
test002@xxx:..Test-Benutzer/test002> cat .config/plasma-localerc
[Formats]
LANG=en_GB.UTF-8
[Translations]
LANGUAGE=en_GB
test002@xxx:..Test-Benutzer/test002>
test002@xxx:..Test-Benutzer/test002> cat .config/plasma-locale-settings.sh
# Generated script, do not edit
# Exports language-format specific env vars from startkde.
# This script has been generated from kcmshell5 formats.
# It will automatically be overwritten from there.
export LANG=en_GB.UTF-8
export LANGUAGE=en_GB
test002@xxx:..Test-Benutzer/test002>
test002@xxx:..Test-Benutzer/test002> echo $LANG
en_GB.UTF-8
test002@xxx:..Test-Benutzer/test002>
test002@xxx:..Test-Benutzer/test002> localectl status
System Locale: LANG=de_DE.UTF-8
VC Keymap: de-latin1-nodeadkeys
X11 Layout: de
X11 Model: pc105
X11 Variant: nodeadkeys
X11 Options: terminate:ctrl_alt_bksp
test002@xxx:..Test-Benutzer/test002>
Please note that, the KDE Plasma System Settings warns that the settings will take effect at the next login …