Bug 465373

Summary: Possible regression causing mixed-language text when multiple languages are configured
Product: [Applications] systemsettings Reporter: wazhai <wazhai>
Component: kcm_regionandlangAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal CC: hanyoung, nate
Priority: NOR    
Version: 5.26.5   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Screenshot of bug
Fedora installation

Description wazhai 2023-02-06 15:43:12 UTC
Created attachment 155999 [details]
Screenshot of bug

SUMMARY
I'm experiencing the issue with various programs (especially command line) showing mixed-language text because there isn't an en_US/en_GB translation and they rely on falling back to unlocalized "C" to display English.
Bug 192019 - Adding multiple languages to the KCM causes some apps and CLI programs to display some text from languages lower down in the priority list even if higher languages have an appropriate string 

Above bug was supposed to be fixed in 5.26 with
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1147
but I'm still seeing it in action on Fedora. Or could this be a distro-specific bug? Apologies in that case, I can file it against Fedora.

STEPS TO REPRODUCE
1. In Region & Language, set some English variant on top and any number of other languages below
2. Restart session
3. Use the command line

OBSERVED RESULT
Mixed-languages as in Bug 192019

EXPECTED RESULT
Only English is shown everywhere.

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 37
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Graphics Platform: X11

ADDITIONAL INFORMATION
A workaround is to manually put "C" in the language list below English and above the remaining languages, which shouldn't be needed.
Comment 1 hanyoung 2023-02-06 16:18:20 UTC
There is a warning for putting en_US in the first row. As for your screenshot, that's expected behavior, because British English != en_US. The default English is America English.
Comment 2 wazhai 2023-02-06 17:02:48 UTC
Created attachment 156000 [details]
Fedora installation

During Fedora installation, I had to choose an English variant among many (see attachment) and did so according to my preferences. After installation, en_US is NOT in the KCM language list on Fedora, only British English is.

Wouldn't it make more sense to default to en_US/C text if there's no en_GB available rather than showing a mix of completely different languages? And are users expected to be aware of this quirk in case they want to add another language to this list?
Comment 3 hanyoung 2023-02-07 04:33:15 UTC
> Wouldn't it make more sense to default to en_US/C text if there's no en_GB available

Do you want to see Japanese, Traditional Chinese if Simplified Chinese is not available? Or would you like to see Latin when Italian, French is not available? American English is not fallback language to British English even if they're related. Your argument make no sense.
Comment 4 wazhai 2023-02-07 04:54:42 UTC
Selecting a non-US English doesn't produce a mix of other languages on any other system like GNOME (which I believe puts "en_GB:en" in LANGUAGE), Android or Windows, but ok. I never saw any warning and en_US wasn't in my language list on Fedora. It's simply not good UX and KDE seems the broken one when English is the same language with minute spelling differences. 

Right now there doesn't seem to be much use in having multiple languages on this list because it doesn't do much, but there's valid use cases such as Bug 366328 (installing language support) and Bug 465384 (CJK variants)
Comment 5 hanyoung 2023-02-07 05:02:13 UTC
> Selecting a non-US English doesn't produce a mix of other languages on any other system like GNOME (which I believe puts "en_GB:en" in LANGUAGE)

Yeah, maybe you should put en_GB:en_US in KDE too instead of British English, Germany and Japanese in your screenshot.
Comment 6 wazhai 2023-02-07 05:34:41 UTC
I've fixed it by putting C below en_GB but this shouldn't be needed IMO.

Fedora users are presented with such a long list of English variants, but all of them (except en_US?) are broken when the goal is to have an English system? It's also a valid use case to have other languages below en_US while wanting to keep an English system, so I think another solution should be found rather than the warning to keep only en_US in the list.

This warning also applies to en_GB or en_AU just as well because it results in non-English text as soon as another language is added. Should this be filled a separate bug? (Show warning for all English)

KDE should reconsider the NOTABUG stance because English variants (without an en_US or C crutch) don't result in mixed languages on other systems like GNOME and non-Linux
Comment 7 hanyoung 2023-02-07 05:41:03 UTC
(In reply to wazhai from comment #6)
> I've fixed it by putting C below en_GB but this shouldn't be needed IMO.
> 
> Fedora users are presented with such a long list of English variants, but
> all of them (except en_US?) are broken when the goal is to have an English
> system? It's also a valid use case to have other languages below en_US while
> wanting to keep an English system, so I think another solution should be
> found rather than the warning to keep only en_US in the list.
> 
> This warning also applies to en_GB or en_AU just as well because it results
> in non-English text as soon as another language is added. Should this be
> filled a separate bug? (Show warning for all English)
> 
> KDE should reconsider the NOTABUG stance because English variants (without
> an en_US or C crutch) don't result in mixed languages on other systems like
> GNOME and non-Linux

Why we only have warning for en_US? Because en_US is KDE's default locale, in KDE, en_US == C. That's means any language below en_US won't be displayed. If you put C or en_US below en_BR, then the Germany and Japanese won't be show at all. 

Why you add Germany and Japanese at all if you only want to fallback to some kind of English?
Comment 8 wazhai 2023-02-07 05:48:28 UTC
"Why you add Germany and Japanese at all if you only want to fallback to some kind of English?"

Due to my expectations coming from other systems. If you want German spell checking in Office, want to set a CJK preference, or have a Japanese input method, you add it to the language list.

"There's valid use cases such as Bug 366328 (installing language support) and Bug 465384 (CJK variants)"
Comment 9 hanyoung 2023-02-07 06:26:20 UTC
>  want German spell checking in Office

Config it in Office or spell checking program
> want to set a CJK preference

No way to support it
> have a Japanese input method

Unrelated
Comment 10 wazhai 2023-02-07 07:19:25 UTC
want German spell checking in Office
Config it in Office or spell checking program
> have a Japanese input method
Unrelated

Both of these fall under adding language support by installing the necessary packages for e.g. spell checking dictionaries and an IME, but if that's out of the scope of the language KCM as per the closure of Bug 366328 ... Alright.

Is it a unique feature of Ubuntu to have a download arrow in the KCM for language support?
Comment 11 hanyoung 2023-02-07 07:24:02 UTC
(In reply to wazhai from comment #10)
> want German spell checking in Office
> Config it in Office or spell checking program
> > have a Japanese input method
> Unrelated
> 
> Both of these fall under adding language support by installing the necessary
> packages for e.g. spell checking dictionaries and an IME, but if that's out
> of the scope of the language KCM as per the closure of Bug 366328 ...
> Alright.
> 
> Is it a unique feature of Ubuntu to have a download arrow in the KCM for
> language support?

Ubuntu has a distro specific "check-language-support" package that defines list of additional language support packages for each locale. It includes fonts, translation package for office etc. AFAIK, no other distros provides this kind of packages. There is absolutely no way for Plasma to figure out what package to install for a language.
Comment 12 Nate Graham 2023-02-07 20:45:27 UTC
> American English is not fallback language to British English even if they're related
I'm afraid that's not a correct statement. American English is definitely an acceptable fallback language for British English because they're actually the same language; "British English" "and "American English" are mutually intelligible because they're dialects of the same basic language with only extremely minor differences between them.

That said, Han is right that you shouldn't have any non-English languages below English as it doesn't make any logical sense given the way translation fallbacks work. This list is a priority queue that essentially lets you choose your preferred workaround for the current state of KDE's translation were we don't have 100% translation coverage. Here's what you've essentially told the system to do:

"Try your best to display text in British English, but if you come across any piece of text that isn't available in that language, look for a German string, and if you can't find one, look for a Chinese one, and if you still can't find one, just display the original text in plain old American English".

Clearly that's not what you wanted. :) What you wanted was this:

"Try your best to display text in British English, but if you come across any piece of text that isn't available in that language, just display the original text in plain old American English."

Given this intention, you can actually remove all the other languages from the list since their presence doesn't make sense. As Han said, you don't need to add other languages into here to use them in specific use cases. This config UI is for determining what language you want the user interface of your programs to be localized.
Comment 13 Nate Graham 2023-02-07 20:47:35 UTC
We can probably make all of this clearer in the UI, though.

Right now we display a warning when you put any other language below American English. But we don't do that for any of the other English variants. We probably should.

So you said: 

> Should this be filled a separate bug? (Show warning for all English)

Yes please. Go ahead and file that. Thanks!
Comment 14 wazhai 2023-02-07 21:27:48 UTC
In my view Bug 192019 wasn't actually fixed and this bug is a duplicate of it, but I wasn't sure about reopening that one so I filed a new bug. There are 84 results when you ctrl+f for "English" on that page, and this exact scenario is what everyone there was trying to avoid and resolve there. 

"you shouldn't have any non-English languages below English as it doesn't make any logical sense given the way translation fallbacks work"

The reason I put other languages below en_GB in the first place is because
- on Kubuntu, this lets you install some language support packages like an IME and spell checking dictionaries
- I hoped it would work as a CJK preference Bug 465384
- this doesn't cause side effects on GNOME, Windows, or Android; all text remains in English. KDE is the odd one out here.

Be it for lack of understanding, to try to install language support packages or whatever other reason, users' actions often don't make logical sense and some users have put (Bug 192019) and will continue to put more languages below English and experience an undesired mixed-language UI.

Is there a valid use case of wanting to read "colour" in British English but fall back to German for everything else? I think every user who has English as the primary language only expects to see English. 

"American English is definitely an acceptable fallback language for British English"
Why is there opposition to implementing this? Is it not preferable to address the root cause rather than have a special warning for English? I think this solution would be better than than trying to prevent user error through warnings.
Comment 15 wazhai 2023-02-07 21:40:44 UTC
Perhaps a more valuable discussion about this can be found under https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087
The KCM merge was supposed to address this issue
Comment 16 wazhai 2023-02-07 21:59:55 UTC
Thank you both, Han and Nate, for your extensive responses! I don't think continuing to discuss this in here would produce fruitful results, so I will mark it as the duplicate of Bug 192019 that it really is and write a short status ping there. If this is deemed action-worthy or actionable at all, that bug can be reopened.

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