Bug 435852

Summary: Mix of localization text in the UI
Product: [Applications] systemsettings Reporter: Sebastian Hörberg <sebastian>
Component: kcm_languageAssignee: Eike Hein <hein>
Severity: normal CC: nate, plasma-bugs
Priority: NOR    
Version: 5.21.4   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Screenshot with inconsistencies highlighted
Application launcher showing mixed locales

Description Sebastian Hörberg 2021-04-17 17:09:24 UTC
Created attachment 137673 [details]
Screenshot with inconsistencies highlighted

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.

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.

Mix of localization in the UI, issue highlighted in the attached screenshot.

Expected system settings to be displayed in one language consistently, either English or Swedish, not a mix.

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

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

KDE settings were set to :
  Plasma translations: 
    "American English (default)"
    Region: United Statets (en_US)
    Detailed Settings: All set to "Sverige - svenska (sv_SE)"

I have since removed "svenska" from Plasma Translations.
Comment 1 Nate Graham 2021-04-21 18:25:08 UTC
Was this only affecting System Settings? Or other pieces of KDE software as well? Or also other non-KDE software?
Comment 2 Sebastian Hörberg 2021-04-22 18:30:08 UTC
Created attachment 137804 [details]
Application launcher showing mixed locales
Comment 3 Sebastian Hörberg 2021-04-22 18:37:28 UTC
(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.
Comment 4 Nate Graham 2021-04-22 19:10:27 UTC
How did you manage this coercion? :)
Comment 5 Sebastian Hörberg 2021-04-23 00:10:45 UTC
By probably making it worse in the long-run. 
- 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.
Comment 6 Nate Graham 2021-04-23 19:44:29 UTC
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.
Comment 7 Sebastian Hörberg 2021-07-31 16:38:59 UTC
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.
Comment 8 Nate Graham 2021-09-30 19:22:10 UTC

*** This bug has been marked as a duplicate of bug 192019 ***