| Summary: | KDE doesn’t respect country chosen in user’s locale | ||
|---|---|---|---|
| Product: | [Translations] i18n | Reporter: | Karl Ove Hufthammer <karl> |
| Component: | general | Assignee: | John Layt <jlayt> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | annma, bugs, caslav.ilic, erecio, fincer89, gokcen.eraslan, jlayt, kde, lasse.liehu, martin.schlander, michaelaquilina, nate, olsmondi, sam |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Unspecified | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/commit/edc64d04a1e569d7032c41e6ee0ebf59833c26f2 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | screenshot | ||
|
Description
Karl Ove Hufthammer
2008-12-01 21:37:04 UTC
Karl: what env var should be picked to set the country please? I also do not understand why the list is not populated by languages and what the Add Language combobox is for. This module needs some work on design and needs fixing. I’m not 100% certain, but I belive it is 1) LC_ALL if it exists, and 2) LANG if it does not. So if you have LC_ALL=nn_NO.UTF-8 LANG=da_DK.UTF-8 the country should be NO (Norway). If you only have LANG=da_DK.UTF-8 or LANG=da_DK the country should be DK (Denmark). If the variables are set to ‘C’ or ‘POSIX’ the generic (C) ‘country’ should be used. About the language list: It is a list of languages in preferred order. A translation is taken from the first language in the list that has a translation of the string. The explanation you get when you hover over the list is thus misleading. According to this blog entry http://jtechinda.blogspot.com/2009/04/on-brighter-side-of-things-kubuntu-904.html this bug is fixed in Kubuntu. But from what I gather from the blog, the Kubuntu developers did not contribute the fix upstream, so this bug is still present in KDE. i looked and think that the ubuntu patch that have to be reviewed for inclusion is this one : http://patches.ubuntu.com/k/kdebase-workspace/extracted/kubuntu_13_startkde_set_country.diff i just added it on mandriva to see if it works ok for us too It doesn’t look like the patch take the user-specific LC_MESSAGES or LC_ALL into consideration, only LANG and the system defaults. LC_ALL overrides LC_MESSAGES, and both override LANG. The correct way to find the correct country is thus to look at both LC_ALL LC_MESSAGES LANG system defaults and use the *first one* of these that contain the country. I'd just like to clarify why this bug isn't fixed in KDE, upstream. For language, detection based on environment can work cleanly: in KDE settings, the default language is "System Default", in which case environment is examined; and user can at any time select specific language, or return to system default. So, pretty much as soon Karl Ove opened the bug, I made a patch to do similar autodetection for locale too. However, possible issues started to crop up. First, there is no obvious link between system (as in libc) locale name and KDE's locale name. Sure, with common locale strings (contains country code, not an alias) and common countries (de, fr...) just taking country from the environment variables will work; but in general not. Then, even when autodetection manages to hit proper KDE locale name, once a hapless user selects a locale in KDE settings, there is no way to go back to autodetection of system locale (unlike with language). And this is not a simple issue of locale control module interface, because... If the user tweaks some locale settings, then if autodetection is in effect, the manually tweaked settings would not change as system locale changes, while others would. And without any indicator to the user whatsoever which one has and which one has not been manually tweaked. This is both hard to fix under the hood, and to design a proper interface to present it. The central problem is that KDE and "system" (i.e. libc) locale systems are completely separate, with different interfaces and sets of features, and it is nowhere near easy to design and implement a sane bridge between them. (Note that above patch in Kubuntu will work only once; if the user later changes system locale, this will not reflect upon KDE, even if in the meantime the user didn't even touch KDE settings. In fact, given the above ugly effects of real autodetection, this kind of one-shot autodetection may be for the best. But since it's just replacing one bug with another, albeit perhaps more amiable, I would let it remain upon distributions whether to do it. One extra suggestion would be to, instead of manually rumaging through kdeglobals, use: kwriteconfig --group Locale --key Country $country where $country is KDE locale name guessed from environment.) > First, there is no obvious link between system (as in libc) locale name and > KDE's locale name. Sure, with common locale strings (contains country code, > not an alias) and common countries (de, fr...) just taking country from the > environment variables will work; but in general not. But won’t we be 99% there by doing this? This will be infinitely better than the current situation, where we are 0% there, and always falls back to POSIX defaults, which is only suitable for US English. > Then, even when autodetection manages to hit proper KDE locale name, once a > hapless user selects a locale in KDE settings, there is no way to go back to > autodetection of system locale (unlike with language). Why not just have a ‘(System default)’ option for both language and country? > If the user tweaks some locale settings, then if autodetection is in effect, > the manually tweaked settings would not change as system locale changes, > while others would. One solution would be to always let the autodetection override the changes. You could for example grey out all options when the ‘(System default)’ Country and Language is selected. > (Note that above patch in Kubuntu will work only once; if the user later > changes system locale, this will not reflect upon KDE, even if in the > meantime the user didn't even touch KDE settings. Yes, this is very unfortunate. Like Karl Ove I don't see how anything could be worse than, or even remotely as bad as, the current state. This bug causes some nasty issues, like for example whenever any Danish user will reply to an e-mail with KMail, the date format will be completely wrong - and anyone receiving such an e-mail will see that Linux/KDE sucks. Unless the user thinks to go to systemsettings -> Regional and language and set the locale manually... which ain't gonna happen 99.5% of the time. Would it be possible to have a special string in translation files, so that languages can specify a *default* country? I.e., setting the language (perhaps automatically via the LANG variable) will implicitly select a country. For instance, setting the language to Danish would select Denmark, and setting the language to British English would select the UK? This won’t be a perfect solution, as some languages are spoken in more than one country, but will for the vast majority of languages be a great improvement (and the country settings for a country that share the same language will probably be a much better match than the settings for the ‘C‘ country is). Assign to me as I'm currently trying to sort a solution for this in KLocale :-) Step 1 is at http://reviewboard.kde.org/r/4915/ which is code to guess a host system country on Win/Mac/Linux. We may require better heuristics, but it's a framework to do so. Step 2 is improving the kcm to better show which settings are defaults, which are a users choices, and to toggle between them. That's a WIP. See also threads on the k-c-d mailing list. SVN commit 1166797 by jlayt: Try to choose a default locale Country if the user hasn't set one yet. See http://reviewboard.kde.org/r/4915/ Under Linux this will use QLocale to try obtain a default country. Under Windows and Mac this will fake locale support by loading the KDE settings for the system country, proper support using real host settings will follow later. Fix my stupidity with not understanding how virtual call work in constructors. Add validation checking to country code values, and improve documentation. Compiled and tested under Linux and Windows, I am unable to build a Mac test environment atm, please patch or beat me up if it fails under Mac. CCMAIL: kde-windows@kde.org CCMAIL: kde-mac@kde.org CCBUG: 176650 M +7 -3 klocale.cpp M +14 -2 klocale.h M +84 -26 klocale_kde.cpp [POSSIBLY UNSAFE: system] M +15 -0 klocale_mac.cpp M +13 -0 klocale_mac_p.h M +31 -1 klocale_p.h [POSSIBLY UNSAFE: system] M +23 -2 klocale_win.cpp M +12 -0 klocale_win_p.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1166797 Just to explain what the new code does from KDE 4.5.2 onwards. If the user has never set a country in the Locale KCM, then: * KDE will make a guess every time you log in. * On Windows and Mac this will be the system country. * On Linux this will use QLocale to make the guess, which involves lots of magic around env vars and CLDR. * If the user changes the system locale, at next start-up KDE will pick up the change and possibly guess a different country. * If the user goes into the KDE Locale control module and overrides any settings other than the country, then these settings will persist even if the user changes the system locale. * If KDE guesses the wrong country the user can override this in the Locale control module and this setting will persist. * In 4.6, a new control module will show the user that KDE is using the system country, and provide easy ways to identify where they have overridden the default settings and reset individual settings to the default. If the user has already explicitly set their country in the control module then: * This setting will always be applied and the system locale ignored. * In 4.6 the control module will allow the user to change to use the system derived country instead. If anyone spots weird behaviour please let me know. In particular, I can add a whitelist of system locales that Qt returns the wrong result for a particular system locale. You can test this by going into your .kde4/share/config/kdeglobals file and remove from the [Locale] section any line with "Country=xx" (In reply to comment #13) > Just to explain what the new code does from KDE 4.5.2 onwards. So will you backport this change to 4.5? I couldn't see in KDE websvn of 4.5 branch. Anyway it would be awesome. Whoops! I did backport it, but forgot to commit. Sorry, that will now be in 4.5.3. (In reply to comment #15) > Whoops! I did backport it, but forgot to commit. Sorry, that will now be in > 4.5.3. Ignore that if you've committed but I still couldn't find the commit in 4.5 branch. SVN commit 1192086 by jlayt: Backport to 4.5 KLocale fix for guessing the users country if not manually set. Unlike the 4.6 version, the 4.5 version uses QLocale for all platforms. Qt uses some heuristics to make good guesses, but may still get it wrong, but anything has to be better than defaulting to C. CCBUG: 176650 M +25 -2 klocale.cpp [POSSIBLY UNSAFE: system] WebSVN link: http://websvn.kde.org/?view=rev&revision=1192086 I can confirm this problem is present in Kubuntu 13.04 as well. if i set country to say American English in the language settings control panel, the 'locale' command will still items such as LC_TIME and LC_NUMERIC to my 'system detected language' Maltese, i.e. mt_MT.UTF-8. This means that all my desktop is shown in English, but other things like date and time are shown in Maltese (which is very inconsistent and annoying). The only way i've found to solve this is to edit the 'setlocale.sh' file that is run at startup. If you add 'export LC_ALL=en_US.UTF-8' to the end of the file then everything will be shown in english. (In reply to comment #18) > I can confirm this problem is present in Kubuntu 13.04 as well. > The only way i've found to solve this is to edit the 'setlocale.sh' file > that is run at startup. setlocale.sh is specific to Kubuntu, and isn't in the general KDE distribution. See https://bugs.kde.org/show_bug.cgi?id=322688 and https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1204182 This is still valid for 5.3 linux-0gts:~> locale LANG=en_US.utf8 LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL= linux-0gts:~> env | grep LANG LANG=en_US.utf8 LANGUAGE=en_US The date is still represented in Finnish Created attachment 92703 [details]
screenshot
KDE/Plasma 5. Framework 5.32, KDE 5.9.4. Is there a specific reason the system gives me odd locales like "en_FI" or similar which are not recognized by the rest of my system programs and shouldn't exist at all. KDE understands these strange locales fine but by using them cause easily problems with programs such as perl. Basically, I'm trying to use locale "fi_FI" for my time/date but KDE locale settings doesn't give that choice at all. Why? I'm currently forced to use "en_US" locale setting which is not I'm looking for since I'm not used to read calendar like US people. For the rest of locale settings, I use "en_US". A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/100 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/100 Git commit edc64d04a1e569d7032c41e6ee0ebf59833c26f2 by Alexander Lohnau. Committed on 25/06/2020 at 13:18. Pushed by alex into branch 'Plasma/5.19'. Fix broken ENV variables for detailed settings Related: bug 417070, bug 327757 M +21 -10 startkde/startplasma.cpp https://invent.kde.org/plasma/plasma-workspace/commit/edc64d04a1e569d7032c41e6ee0ebf59833c26f2 Git commit edc64d04a1e569d7032c41e6ee0ebf59833c26f2 by Alexander Lohnau. Committed on 25/06/2020 at 13:18. Pushed by alex into branch 'Plasma/5.19'. Fix broken ENV variables for detailed settings Related: bug 417070, bug 327757 M +21 -10 startkde/startplasma.cpp https://invent.kde.org/plasma/plasma-workspace/commit/edc64d04a1e569d7032c41e6ee0ebf59833c26f2 We had to revert the commit that fixed this as it caused Bug 423995. We'll work on finding another way. any progress on this? |