Description of problem: After a clean cauldron plasma net-install on real h/w today, with en_GB as primary lang and various other multi-langs including French selected during install, the output in 'konsole': [baz@localhost ~]$ echo $LC_ALL [baz@localhost ~]$ echo $LANG en_GB.UTF-8 [baz@localhost ~]$ echo $LANGUAGE en_GB.UTF-8:en_GB:en [baz@localhost ~]$ [baz@localhost ~]$ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= After using MCC -> System -> "Change the localization setting for your system" to French/France then log out/in, only LANGUAGE as displayed in konsole or xterm has changed: [baz@localhost ~]$ echo $LANG en_GB.UTF-8 [baz@localhost ~]$ echo $LANGUAGE fr_FR.UTF-8:fr [baz@localhost ~]$ locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= [baz@localhost ~]$ This causes dates in e.g. 'rpm -qa -last' output to be still in English. Using: LANG=fr_FR rpm -qa --last displays the dates in French The above is the same for konsole and xterm, however switching to tty2 the dates are displayed in French correctly, and $LANG is fr_FR. Output from tty2: $LANG: fr_FR.UTF-8 $LANGUAGE: fr_FR.UTF-8:fr locale output: LANG=fr_FR.UTF-8 LC_CTYPE="fr_FR.UTF-8" LC_NUMERIC="fr_FR.UTF-8" LC_TIME="fr_FR.UTF-8" LC_COLLATE="fr_FR.UTF-8" LC_MONETARY="fr_FR.UTF-8" LC_MESSAGES="fr_FR.UTF-8" LC_PAPER="fr_FR.UTF-8" LC_NAME="fr_FR.UTF-8" LC_ADDRESS="fr_FR.UTF-8" LC_TELEPHONE="fr_FR.UTF-8" LC_MEASUREMENT="fr_FR.UTF-8" LC_IDENTIFICATION="fr_FR.UTF-8" LC_ALL= This appears to be a bug, not in plasma I suspect, since xterm has the same issue but I am new to i18n so any help comments would be appreciated.
Hmmm, so this looks in summary as if when you change the system language, it only shows up correctly: - in virtual consoles - $LANGUAGE but $LANG remains as the principle language in desktop virtual terminals, which is reflected by command outputs. Can you say what happens with GUI applications that should accommodate both languages?
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #1) > Hmmm, so this looks in summary as if when you change the system language, it > only shows up correctly: > - in virtual consoles No, tty and: > - $LANGUAGE > but $LANG remains as the principle language in desktop virtual terminals, > which is reflected by command outputs. Yes > > Can you say what happens with GUI applications that should accommodate both > languages? They are OK as far as tested and I have been using cauldron in French for a few days, except that Firefox needs a manual locale change in the program settings, after which it is OK. It does not pick up the required language from the system even though all the needed lang packs were installed at install time. I have noticed this while testing remove-old-kernels which runs in the default terminal, so konsole for plasma. I have added this in the script as a workaround: LANG=$(echo $LANGUAGE|cut -d: -f1) ...but I don't think that should be needed.
$LANG and $LANGUAGE are different variables. It seems that draklocale changes $LANGUAGE and not $LANG, which may be OK. There is a brief discussion of language environment variables here: https://www.baeldung.com/linux/locale-environment-variables So this does not look like a bug, but that determination is "above my pay grade" and will leave it to more knowledgeable folks.
CC: (none) => waterbearer54
(In reply to aguador from comment #3) > $LANG and $LANGUAGE are different variables. It seems that draklocale > changes $LANGUAGE and not $LANG, which may be OK. > > There is a brief discussion of language environment variables here: > > https://www.baeldung.com/linux/locale-environment-variables > > So this does not look like a bug, but that determination is "above my pay > grade" and will leave it to more knowledgeable folks. That is a useful read - thanks! I have read it four times so far but this does not seem to make much sense: 3.1. LANG The LANG environment variable deals with the language of a Linux system. When we specify a language using the LANG variable, it’ll use that variable to print out messages in the language we choose. If no language is set, or if a message doesn’t have a translation in that language, then it defaults to English How can it say that LANG sets the language and then in the next breath say "If no language is set,..." I wish it said how "no language is set" if LANG has not set it. In another mail you said: "On my es_ES-only system, $LANG is set to "es_ES.UTF-8" and $LANGUAGE is not set." Can you please check $LANGUAGE and locale output in a tty on that machine? Is it cauldron or Mga8?
(In reply to Barry Jackson from comment #4) > How can it say that LANG sets the language and then in the next breath say > "If no language is set,..." It would have been clearer if it said "If $LANG is not set", which is the point. $LANG is an environment variable which overrides the default system language, en_US. > In another mail you said: > "On my es_ES-only system, $LANG is set to "es_ES.UTF-8" and $LANGUAGE is > not set." > > Can you please check $LANGUAGE and locale output in a tty on that machine? > Is it cauldron or Mga8? This is my Cauldron machine. For some reason I do not have CTL-ALT_F2 access to tty2, but did reboot at runlevel 2. There $LANGUAGE shows as "es_ES.UTF-8". Forgot to run locale, but it would undoubtedly come up the same. In the link it stated that $LANGUAGE overrides $LC_ALL, but apparently $LANG as well. I think what you are seeing in the output is that draklocale sets $LANGUAGE, while $LANG remains unchanged. Changing $LANGUAGE allows the messages to be displayed in the language specified OTHER (apparently) than the terminal which will continue to reflect the $LANG setting. I suspect that is the intended behavior for draklocale, which I why I doubted this is a bug. However, that is for the devs to say.
ArchWiki may help: https://wiki.archlinux.org/title/Locale#LANG:_default_locale Key points: "[LANG] will be used for all the LC_* variables that are not explicitly set." "Programs which use gettext for translations respect the LANGUAGE option in addition to the usual variables." So the GUI programs use gettext and display whatever locale is set in $LANGUAGE. Since the terminal does not use gettext, it displays whatever is set by $LANG. I assume if $LANG is not specified the display will use en_US.
(In reply to Barry Jackson from comment #2) > (In reply to Lewis Smith from comment #1) > > Hmmm, so this looks in summary as if when you change the system language, it > > only shows up correctly: > > - in virtual consoles > No, tty Semantics! 'Terminal' is often used for desktop GUI terminals, 'virtual consoles' (what you rightly call 'tty') being the Ctrl/Alt/Fn character ones. (In reply to Barry Jackson from comment #4) > (In reply to aguador from comment #3) > this does not seem to make much sense: > "3.1. LANG > The LANG environment variable deals with the language of a Linux system. > When we specify a language using the LANG variable, it’ll use that variable > to print out messages in the language we choose. If no language is set, or > if a message doesn’t have a translation in that language, then it defaults > to English" > How can it say that LANG sets the language and then in the next breath say > "If no language is set,..." > I wish it said how "no language is set" if LANG has not set it. I do not see any problem with the paragraph. "If no language is set" is surely another way of saying "if LANG is not set". LANG 'setting' something is enigmatic. Never mind. There is a problem, as you described in comment 0, resumed in comment 3. Assigning to MageiaTools, since only the devs can decide what should happen.
Assignee: bugsquad => mageiatoolsSource RPM: draklocale => drakxtoolsCC: lewyssmith => (none)
This is a Plasma issue. draklocale sets the system-wide locale, stored in /etc/locale.conf and /etc/sysconfig/i18n. Other DEs use the settings stored in these files unless the user chooses to override them in ~/.i18n. The first time you start it, Plasma copies the system-wide locale into ~/.config/plasma-localerc and after that uses that user-specific locale.
CC: (none) => mageia
Thanks Martin, I have not been ignoring this, just trying to get my head around it whilst battling with other issues. Thanks for your explanation. I see that /etc/locale.conf is owned by systemd, but it probably gets it's data from /etc/sysconfig/i18n which is unowned, so where that comes from I have not yet discovered. There is an error in the Norweigian nb_NO $LANGUAGE which appears in both files, so I have been trying to find the source. It was suggested to me that systemsettings may also be controlling the content of ~/.config/plasma-localerc, however the localization dialogue in Mga9 systemsettings seems dumbed down compared to that in current Mga8. I will do more testing in clean Mga9 installs to try to figure out whether manually editing ~/.config/plasma-localerc affects this bug. /OT @Martin. I see some bad graphics in installer stage2 during bootloader-config - probably 'Please wait' boxes but they are badly broken - I did 6 net-installs yesterday in different languages :(
I think /etc/sysconfig/i18n is the old Mandrake/Mandriva way of doing things. It is initially written by the installer, and modified by draklocale. I don't know if anything else still uses it. In /etc/profile.d/lang.sh we have # only source one of the possible files, and in that order; # if system wide and user config are mixed and different, umpredictable # things will happen... for langfile in "$HOME/.i18n" /etc/locale.conf /etc/sysconfig/i18n ; do [ -f $langfile -a "$LC_SOURCED" != 1 ] && . $langfile && LC_SOURCED=1 && export LC_SOURCED done which comes from a Mageia patch to initscripts. The installer and draklocale also write /etc/locale.conf. That was added as a result of bug 15464, which was presumably a consequence of switching to systemd. The code that writes those two files can be found in the write() subroutine in /usr/lib/libDrakX/lang.pm. /OT A new bug report with a screenshot would help. I've not seen any such problems, but I normally only test using English.