Created attachment 137673 [details] Screenshot with inconsistencies highlighted SUMMARY While having some issues with localization on my new Tumbleweed installation I noticed that certain parts of KDE seems to decide on localization differently than others. This was also noticeable in KRunner where, for instance, the name and description of Discover was translated into Swedish but the application itself was in English and displayed the English title on the taskbar. However, I decided to file this specifically for systemsettings since that was the most consistent in displaying the issue. This is not about missing localization strings in Swedish causing it to default to English, but English localization with just a few Swedish translations here and there. STEPS TO REPRODUCE Not sure how to replicate this to be honest, the issue seems to stem from trying to use a mix of locales, in this case US English for LANG and LC_MESSAGES and Swedish for the rest. Somehow the various components of locale.conf, (systemd?), YaST and KDE ended up fighting each other. After a lot of fiddling, system settings is now all in English but I don't know what fixed it. OBSERVED RESULT Mix of localization in the UI, issue highlighted in the attached screenshot. EXPECTED RESULT Expected system settings to be displayed in one language consistently, either English or Swedish, not a mix. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20210414 KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.81.0 Qt Version: 5.15.2 Kernel Version: 5.11.12-1-default Graphics Platform: X11 ADDITIONAL INFORMATION These are the locale settings that was desired: $ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: sv-latin1 X11 Layout: se X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp $ locale LANG=en_US.UTF-8 LC_CTYPE=sv_SE.UTF-8 LC_NUMERIC=sv_SE.UTF-8 LC_TIME=sv_SE.UTF-8 LC_COLLATE=sv_SE.UTF-8 LC_MONETARY=sv_SE.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=sv_SE.UTF-8 LC_NAME=sv_SE.UTF-8 LC_ADDRESS=sv_SE.UTF-8 LC_TELEPHONE=sv_SE.UTF-8 LC_MEASUREMENT=sv_SE.UTF-8 LC_IDENTIFICATION=sv_SE.UTF-8 LC_ALL= KDE settings were set to : Plasma translations: "American English (default)" "svenska" Formats: Region: United Statets (en_US) Detailed Settings: All set to "Sverige - svenska (sv_SE)" I have since removed "svenska" from Plasma Translations.
Was this only affecting System Settings? Or other pieces of KDE software as well? Or also other non-KDE software?
Created attachment 137804 [details] Application launcher showing mixed locales
(In reply to Nate Graham from comment #1) > Was this only affecting System Settings? Or other pieces of KDE software as > well? Or also other non-KDE software? This was affecting other KDE software as well like KRunner (alt+F2) and the Application Launcher (is that also KRunner?). As mentioned my locales were wonky, however non-KDE software were consistent in picking either Swedish or English. I have since managed to coerce my into a consistent state with the locales I want, so the error is no longer visible.
How did you manage this coercion? :)
By probably making it worse in the long-run. I: - set all the RC_LC variables in YaST - set all the settings in KDE - exported all the the LC variables in ~/.i18n - sourced .i18n in .profile - deleted ~/.config/locale.conf Also there might have been some cursing involved... But this issue interested me because I'm not sure how it would happen. In the application launcher for instance, is it trying to determine locale per item and getting some kind of race-condition? But that also seems strange since I did for instance notice that Help was always displayed in Swedish which seems unlikely for a race condition... I would be happy to help look into this if perhaps I could get some pointers on where in the code-base to look, I had a quick glance and there was a lot of it. ;P I will also try to replicate it in a VM when I get a bit of time. All in all, not a high-prio issue at all, it was more of a coincidence that I found it, and I wanted to document the behavior in case it was a symptom of something else.
Heh I wish I could help but unfortunately this stuff is a bit of a mystery to me too. I am but a simple bug triager.
I was unable to reproduce this one. Still think there is either a race condition somewhere, or possibly use of differing API that might have caused it, from what I could see with my limited knowledge of the code the panels in question draw everything the same so it might be deeper. Either way, this can be closed as not being reproducible and kept as documenting a symptom, in case it helps in a future bug.
*** This bug has been marked as a duplicate of bug 192019 ***