My use case is the following: I want all applications to provide native english text. But I also want the numbers, time, currency, mesasurement units, etc.. be shown in German style. So I set the following option in systemsettings: 'Regional Setting - Formats - Region' to "de_AT" (in my case) but left the "preferred languages" set to "American English". Now I expect my above statement to be fullfilled. But what happens is this: - Plasma is providing english text. That's okay. - Some applications provide german text. For example firefox. I suspect, that the reason for this is, that setting Region de_AT above also sets all locale variables to de_AT: $ locale LANG=de_AT.UTF-8 LC_CTYPE="de_AT.UTF-8" LC_NUMERIC="de_AT.UTF-8" LC_TIME="de_AT.UTF-8" LC_COLLATE="de_AT.UTF-8" LC_MONETARY="de_AT.UTF-8" LC_MESSAGES="de_AT.UTF-8" LC_PAPER="de_AT.UTF-8" LC_NAME="de_AT.UTF-8" LC_ADDRESS="de_AT.UTF-8" LC_TELEPHONE=de_AT.UTF-8" LC_MEASUREMENT="de_AT.UTF-8" LC_IDENTIFICATION="de_AT.UTF-8" LC_ALL= which as a side effect also means that most console applications also talk to me in german. I guess setting LANG just to the Region setting is wrong. Instead it should be the one set in "Translations". Btw: In kde4-plasma it seems that the locale-variables are not touched at all (which I suspect to be also wrong but my use case works). Reproducible: Always
If you set LANG, you'll get translated messages. This is what's likely being picked up by Firefox. For the measurements, times, etc. settings, I'd suggest to set the individual default settings to the right locale. The detailed settings should not set LANG, so applications should not be translated. Just set numbers, time, currency, measurement and collation to the de_AT locale, and don't touch the rest. This should achieve what you expect.
Well. The point is I didn't set LANG. Plasma did. Or do you suggest to set "Region" to the locale I want the language to be? If that's the case, why is the "Region" setting called "Region" and not "Language"?
Because it's not about the language, but about formatting of things such as time, currency, etc. The language can be set in the Translations KCM.
(In reply to Sebastian Kügler from comment #3) > Because it's not about the language, but about formatting of things such as > time, currency, etc. > > The language can be set in the Translations KCM. As stated in the first comment I did that but it didn't work. It always sets LANG to the value assigned to "Region" and LANG seems to be independent from the language set in the Translations KCM. The setting in the Translations KCM seems to affect all kde stuff, but not all applications (including firefox). You stated the likely reason for this is that they obey the LANG setting. So my proposal is: 1) either [if plasma cares about non kde apps] DO override the LANG variable via the Translation KCM settings 2) or [if plasma doesn't care about non kde apps] DO NOT touch the LANG variable via the "Region" setting.[*] This way one could manually set the LANG variable. [*] Although you stated the "Region" setting doesn't affect LANG I claim it _somehow_ does. I see this by setting "Region" to "A". Then logging out, logging in. I observe, that LANG is set to "A". The setting in the Translation KCM was kept constant. Just to clarifiy: I never changed the LANG value by myself. I just observe it. --- I'm sorry to repeat myself but it feels like we are going round circles here.
I have the same issue (with fr_FR.UTF-8), my workaround is to create a ~/.i18n file, with : LC_MESSAGES=en_US.UTF-8 You can't modify $LANG, but $LC_MESSAGES should be enough. You need to logout to see the changes, as kde only reads the environment on startup.
I did that, but the problem is that for example dolphin uses US-style date formatting etc. then, not german ones. (all other LC- variables are set to german). Within your setup, does dolphin show dates in the correct (france) format?
(In reply to Lukas Schneiderbauer from comment #6) > Within your setup, does dolphin show dates in the correct (france) format? No. It seems LC_MESSAGES overrides the date format in dolphin (but not the translations !), which is strange since Qt5 uses LC_CTIME for dates in QSystemLocale, and the digital clock correctly uses the french date format.
The whole glibc locale formatting is retarded. If you set LC_TIME=de_DE.UTF-8 and LC_MESSAGES=en_US.UTF-8, you get German formats *and* date/month names. Intelligent people would expect LC_TIME to not affect date/month names. Now, to work around that I actually ended up changing the de_DE locale in /usr to give me English names and have iso date format (yyyy-mm-dd). And my /etc/locale.conf looks like this: LANG=en_US.UTF-8 LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 This gets me what I want from every application. And it's pretty much the only thing you can do since glibc does have no way of overriding a format other than changing a locale (or making a custom one, but who knows what application might break if you feed it a LC_*=custom locale). But guess what? Plasma 5 is now adding some own retarded behavior to this. The date format is *not* my custom de_DE locale, but the vanilla one shipped by glibc (with all the joy of having wrong date format and stupid German names in my otherwise English setup) even though that file is actually my custom one. If you don't know how this is supposed to work: "man 7 locale" or https://wiki.archlinux.org/index.php/Locale Basically, LC_ALL > LC_$category > LANG > LANGUAGE. Except where it doesn't. Some applications decide to use LANGUAGE over anything else, some even decide to use some LC_$category (expect of course LC_MESSAGES) to use for everything (yes, some programs are just braindead). So basically, what should be provided is only one kcm that gives you the option to select the language to use (setting LANG and LC_MESSAGES and maybe LANGUAGE if they selected fallback languages), and then have the other categories settable as well (hidden under the detailed settings checkbox). And completely do away with the translations kcm (to remove confusion and makes things simple). Though, what's *really* needed is an overhaul of glibc, making it possible to easily override defaults *and* to use LC_MESSAGES for date/month names. This is why I originally never liked the plasma 5 locale handling as it was proposed/announced back then on the blog.
I have the exact same issue. I wouldn't mind having my datestrings in German, but what really bothers me is that I select the "language" to be English and the "formats" to be German, but I end up getting German output on the console. The reasons for this unexpected behaviour is that `.config/plasma-localerc` sets LANG when I choose a format: ``` [Formats] LANG=de_DE.UTF-8 [Translations] LANGUAGE=en_GB:en_US:de ``` This results in the following `.config/plasma-locale-settings.sh` being generated: ``` # 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=de_DE.UTF-8 export LANGUAGE=en_GB:en_US:de ``` I would expect System Settings > Regional Settings > Translations to set LC_MESSAGES, LANG and LANGUAGE, while ... > Formats should set all other LC_*. That should be correct according to the specs - any misbehaving application would mean a bug in that application that KDE developers should not worry about.
I'm running into the same problem: in KDE's settings, under Translations I set Preferred Languages: American English, while under Formats I set Region: Nederland - Nederlands (nl_NL). However, I get Dutch output from some programs now, for example Make. As Dennis wrote, the cause seems to be ~/.config/plasma-locale-settings.sh which sets LANG to nl_NL. If I unset LANG, Make returns to printing English messages. POSIX.1-2008 describes LANG as: This variable shall determine the locale category for native language, local customs, and coded character set in the absence of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME) environment variables. This can be used by applications to determine the language to use for error messages and instructions, collating sequences, date formats, and so on. Since this definition mixes up language and regional settings, which should be two entirely separate things, in my opinion it's best to not set LANG at all.
Hmm... 2018 and still broken. Not even CONFIRMED... Same use case: I want languages in English, formats in German. I just switched from KDE4 and there this worked with out problems. I'm not sure about the individual meanings of those locale enviroment vars, but globally setting $LANG seems wrong.
The LANG environment variable assumes that the user will always want the application language and the regional settings to match. This assumption is wrong for people who prefer application language to be English and regional settings from their own country. In particular computer-savvy people who know all the terminology in English but may find the translated terminology confusing. My estimate would be that a lot of KDE users who are not native English speakers fall into this category. So please... don't set LANG.
(In reply to Dennis Schridde from comment #9) > I have the exact same issue. > > I wouldn't mind having my datestrings in German, but what really bothers me > is that I select the "language" to be English and the "formats" to be > German, but I end up getting German output on the console. > > The reasons for this unexpected behaviour is that `.config/plasma-localerc` > sets LANG when I choose a format: > ``` > [Formats] > LANG=de_DE.UTF-8 > > [Translations] > LANGUAGE=en_GB:en_US:de > ``` > > This results in the following `.config/plasma-locale-settings.sh` being > generated: > ``` > # 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=de_DE.UTF-8 > export LANGUAGE=en_GB:en_US:de > ``` > > I would expect System Settings > Regional Settings > Translations to set > LC_MESSAGES, LANG and LANGUAGE, while ... > Formats should set all other > LC_*. That should be correct according to the specs - any misbehaving > application would mean a bug in that application that KDE developers should > not worry about. This bug is going strong, years go by and nobody fixes this. I've seen major bugs here live well over 10 years and nothing happens. These days I don't report anything new, just whine in comments. This is just a big joke.
*** Bug 430229 has been marked as a duplicate of this bug. ***
After looking at the code all day, I feel able to say something semi-intelligent here. :) Basically all this KCM does is set the $LANGUAGE environment variable. It's up to apps to respect that environment variable when it's set in addition to the $LANG environment variable. Unfortunately this appears to be a convention rather than a formal spec; the POSIX spec specifies that the values set by $LANG are overridden by setting other $LC_* environment variables. However it does not specify a way to override the language. This looks to be an oversight in the spec, sadly. However despite this, many apps will treat the $LANGUAGE environment variable as an override for $LANG, which is what this KCM expects. I'm not surprised that there are apps which don't respect $LANGUAGE and always use the language in $LANG. It's just a bug in the app, sadly. There's nothing we can do from the KDE side because if we tried something tricky like not setting $LANG at all and only setting $LANGUAGE, apps which don't read $LANGUAGE would always be displayed in English (via the fallback C locale) instead of respecting the languages you set in the Languages KCM. It would simply trade one set of bugs for another. Ultimately you just need to report bugs on individual apps that aren't respecting the value of $LANGUAGE ans are always reading $LANG instead. Sorry for the bad news. Hope that makes sense.
An alternative would be to do the following: 1. Abuse $LANG to treat it as purely a setting for the language (which it is not intended to be) and always override it by setting all LC_* environment variables. Then you could change $LANG and it would only affect the language. 2. Delete the Languages KCM, or merge it into the Formats KCM and make sure that it is kept in sync with $LANG such that the value of $LANG and the top language listed in the language list are the same thing. Then the language list would basically function purely to determine fallback languages for apps that respect $LANGUAGE (which not all do; Firefox being a prominent example).
In terms of the user interface, it would look more or less the same as how it currently looks. But on the backend, checking the "Use Detailed Settings" checkbox would instantly assign values to all the LC_* vars. Then there would be a new "Language" control. Clicking on it would take you to a new page where you would be able to put languages in your preferred order. The top item would be assigned to $LANG. There would be no separate Language KCM. This would be a somewhat gross abuse of the POSIX locale system, but the POSIX locale system is very limited and largely unsuitable in its current form for providing a good user experience, so I think we'd have to if we want to solve this issue on the KDE side.
(Oh and those of you who are getting mixed-up localized text in your apps when setting American English as the top language in the Languages KCM with other languages beneath it and $LANG is set in the Formats KCM to something else, you are hitting Bug 192019 which I just submitted a merge request to fix: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087)
This'll be fixed by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1147!
Git commit 134e2d5c989c36ac0e985ee0ae382996c6b7b56e by Han Young. Committed on 02/07/2022 at 09:29. Pushed by hanyoung into branch 'master'. merge Language and Formats Related: bug 192019, bug 341235, bug 394477, bug 397974, bug 397975, bug 403580, bug 417564, bug 420268, bug 429474, bug 431292, bug 444772, bug 446785, bug 447787, bug 448324, bug 448355, bug 451919, bug 451944, bug 454991 closes https://invent.kde.org/plasma/plasma-workspace/-/issues/23 M +1 -0 .kde-ci.yml M +52 -8 CMakeLists.txt M +2 -1 config-workspace.h.cmake D +0 -2 doc/kcontrol/formats/CMakeLists.txt D +0 -63 doc/kcontrol/formats/index.docbook R +1 -1 doc/kcontrol/region_language/CMakeLists.txt [from: doc/kcontrol/translations/CMakeLists.txt - 063% similarity] R +- -- doc/kcontrol/region_language/go-top.png [from: doc/kcontrol/translations/go-top.png - 100% similarity] R +36 -23 doc/kcontrol/region_language/index.docbook [from: doc/kcontrol/translations/index.docbook - 050% similarity] A +- -- doc/kcontrol/region_language/list-remove.png D +- -- doc/kcontrol/translations/list-remove.png M +1 -2 kcms/CMakeLists.txt D +0 -30 kcms/formats/CMakeLists.txt D +0 -5 kcms/formats/Messages.sh D +0 -61 kcms/formats/formatssettings.kcfg D +0 -80 kcms/formats/kcmformats.cpp D +0 -34 kcms/formats/kcmformats.h D +0 -183 kcms/formats/localelistmodel.cpp D +0 -140 kcms/formats/optionsmodel.cpp D +0 -126 kcms/formats/package/contents/ui/main.qml A +75 -0 kcms/region_language/CMakeLists.txt A +8 -0 kcms/region_language/Messages.sh R +2 -27 kcms/region_language/exampleutility.cpp [from: kcms/formats/exampleutility.cpp - 052% similarity] A +22 -0 kcms/region_language/exampleutility.h [License: GPL(v2.0+)] A +82 -0 kcms/region_language/kcm_regionandlang.desktop [TRAILING SPACE] ** [TRAILING SPACE] ** R +4 -4 kcms/region_language/kcm_regionandlang.json [from: kcms/formats/kcm_formats.json - 098% similarity] A +250 -0 kcms/region_language/kcmregionandlang.cpp [License: GPL(v2.0+)] A +58 -0 kcms/region_language/kcmregionandlang.h [License: GPL(v2.0+)] A +372 -0 kcms/region_language/languagelistmodel.cpp [License: GPL(v2.0+)] A +100 -0 kcms/region_language/languagelistmodel.h [License: GPL(v2.0+)] A +30 -0 kcms/region_language/localegenerator.cpp [License: LGPL(v2.0+)] A +17 -0 kcms/region_language/localegenerator.h [License: LGPL(v2.0+)] A +19 -0 kcms/region_language/localegeneratorbase.cpp [License: GPL(v2.0+)] A +23 -0 kcms/region_language/localegeneratorbase.h [License: GPL(v2.0+)] A +32 -0 kcms/region_language/localegeneratorglibc.cpp [License: GPL(v2.0+)] A +24 -0 kcms/region_language/localegeneratorglibc.h [License: GPL(v2.0+)] A +101 -0 kcms/region_language/localegeneratorubuntu.cpp [License: GPL(v2.0+)] A +27 -0 kcms/region_language/localegeneratorubuntu.h [License: GPL(v2.0+)] A +36 -0 kcms/region_language/localegenhelper/CMakeLists.txt A +187 -0 kcms/region_language/localegenhelper/localegenhelper.cpp [License: GPL(v2.0+)] A +46 -0 kcms/region_language/localegenhelper/localegenhelper.h [License: GPL(v2.0+)] A +20 -0 kcms/region_language/localegenhelper/org.kde.localegenhelper.conf A +21 -0 kcms/region_language/localegenhelper/org.kde.localegenhelper.policy A +8 -0 kcms/region_language/localegenhelper/org.kde.localegenhelper.service.in A +158 -0 kcms/region_language/localelistmodel.cpp [License: GPL (v2+)] R +22 -22 kcms/region_language/localelistmodel.h [from: kcms/formats/localelistmodel.h - 060% similarity] A +197 -0 kcms/region_language/optionsmodel.cpp [License: GPL(v2.0+)] R +21 -11 kcms/region_language/optionsmodel.h [from: kcms/formats/optionsmodel.h - 054% similarity] A +204 -0 kcms/region_language/package/contents/ui/AdvancedLanguageSelectPage.qml [License: LGPL(v3.0+)] A +238 -0 kcms/region_language/package/contents/ui/main.qml [License: LGPL(v3.0+)] A +64 -0 kcms/region_language/regionandlangsettings.cpp [License: GPL(v2.0+)] A +21 -0 kcms/region_language/regionandlangsettings.h [License: GPL(v2.0+)] A +37 -0 kcms/region_language/regionandlangsettingsbase.kcfg R +2 -2 kcms/region_language/regionandlangsettingsbase.kcfgc [from: kcms/formats/formatssettings.kcfgc - 055% similarity] A +17 -0 kcms/region_language/settingtype.h [License: GPL(v2.0+)] D +0 -49 kcms/translations/CMakeLists.txt D +0 -2 kcms/translations/Messages.sh D +0 -191 kcms/translations/language.cpp D +0 -32 kcms/translations/language.h D +0 -312 kcms/translations/package/contents/ui/main.qml D +0 -86 kcms/translations/translations.cpp D +0 -53 kcms/translations/translations.h D +0 -193 kcms/translations/translationsmodel.cpp D +0 -72 kcms/translations/translationsmodel.h D +0 -27 kcms/translations/translationssettings.cpp D +0 -24 kcms/translations/translationssettings.h D +0 -28 kcms/translations/translationssettingsbase.kcfg D +0 -6 kcms/translations/translationssettingsbase.kcfgc The files marked with ** at the end have a problem. Either the file contains a trailing space or the file contains a call to potentially dangerous code. Please read: https://community.kde.org/Sysadmin/CommitHooks#Email_notifications for further information. Please either fix the trailing space or review the dangerous code. https://invent.kde.org/plasma/plasma-workspace/commit/134e2d5c989c36ac0e985ee0ae382996c6b7b56e