Bug 352903 - "Preferred Languages" are applied very strangely
Summary: "Preferred Languages" are applied very strangely
Status: RESOLVED WORKSFORME
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_language (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: John Layt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-19 12:12 UTC by Sasha Unspecified
Modified: 2021-01-06 15:17 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sasha Unspecified 2015-09-19 12:12:31 UTC
I use systemsettings 4.11.11 (in KDE 4.13.3 in KUbuntu 14.04.1 LTS).

I have the following "Preferred Languages" in systemsettings: American English, British English and Ukrainian (in that order). However, many applications are still displayed in Ukrainian. I don't believe that they don't have English translation!

Sample applications are: apt-get, inkscape, buttons in `NVidia XServer Settings`, messages in `bash`. The `locale` command reports: "LANG=en_US.UTF-8 || LANGUAGE=en:uk:en || LC_CTYPE="en_US.UTF-8" || LC_NUMERIC=en_US.UTF-8 || LC_TIME=en_US.UTF-8 || LC_COLLATE="en_US.UTF-8" || LC_MONETARY=en_US.UTF-8 || LC_MESSAGES="en_US.UTF-8" || LC_PAPER=en_US.UTF-8 || LC_NAME=en_US.UTF-8 || LC_ADDRESS=en_US.UTF-8 || LC_TELEPHONE=en_US.UTF-8 || LC_MEASUREMENT=en_US.UTF-8 || LC_IDENTIFICATION=en_US.UTF-8 || LC_ALL=".

Before I added anything to "Preferred Languages" (i.e. when "Preferred Languages" list was empty), everything was ok. Even when running same program (e.g. apt-get or bash) from text console (tty1-tty6), everything is ok.

Reproducible: Always

Steps to Reproduce:
1. Add some custom language to "Preferred Languages" in systemsettings (e.g. Ukrainian).
2. Add American English and British English _before_ it (higher priority).


Actual Results:  
apt-get, bash, insckape, NVidia XServer Settings and other apps are fully or partially in Ukrainian.

Expected Results:  
I expect languages to be tried in the specified order; next language in the list should be taken ONLY if the application has no translation to previous language.

$ locale
LANG=en_US.UTF-8
LANGUAGE=en:uk:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

It seems that `LANGUAGE` variable matters. E.g.:
$ LANGUAGE='' bash -c aaaaaaaa
bash: aaaaaaaa: command not found
$ LANGUAGE='en:uk:en' bash -c aaaaaaaa
bash: aaaaaaaa: команду не знайдено
(However, 'en:uk:en' seems to be correct value, and anyway, I haven't specified it in any way, systemsetting did it for me.)

$ locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX
uk_UA.utf8

$ dpkg -l | awk '{print $2}' | egrep -- '-en'
aspell-en
firefox-locale-en
gtk2-engines-oxygen:i386
gtk3-engines-oxygen:i386
hunspell-en-us
hyphen-en-us
kde-l10n-engb
language-pack-en
language-pack-en-base
language-pack-gnome-en
language-pack-gnome-en-base
language-pack-kde-en
libreoffice-help-en-us
myspell-en-au
myspell-en-gb
myspell-en-za
mythes-en-us
xfonts-encodings

$ dpkg -l | awk '{print $2}' | egrep -- '-uk'
firefox-locale-uk
kde-l10n-uk
language-pack-gnome-uk
language-pack-gnome-uk-base
language-pack-uk
language-pack-uk-base
libreoffice-l10n-uk
myspell-uk
Comment 1 Nate Graham 2021-01-06 00:23:06 UTC
Is this still happening for you with a recent version of Plasma, like 5.18 or 5.20?
Comment 2 Sasha Unspecified 2021-01-06 12:59:20 UTC
(In reply to Nate Graham from comment #1)
> Is this still happening for you with a recent version of Plasma, like 5.18
> or 5.20?

I use different settings now, so I can't say for sure, but, I think, we can assume that the bug is gone. Thanks.
Comment 3 Nate Graham 2021-01-06 15:17:50 UTC
Thanks!