Public bug reported: I run Kubuntu. Since I write in English, German, French and Dutch, I set all these languages in 'Locale'; under System Settings. There, the sequence of 'preferred languages' starts with British English. Now, if I continue with settings; or even in the terminal, I get a horrible mix of all these languages. Sure, when one looks at my 'locale', it is quite a mix. But that ought not override the sequence of *languages* as selected. Therefore, what happens is a mess of languages; what ought to happen is the use of the uppermost preferred language. Reproducible: Always Steps to Reproduce: 1. set more than one languages in 'locale' 2. 3. Actual Results: All system languages are a mixture of all languages Expected Results: The preferences are respected
Created attachment 83618 [details] Shows the weird mixture of all languages
The way the preference lists works is to set the order of lookup for translated strings. All KDE gui strings are written in en_US and then translated into other languages, including en_GB. What happens is KDE then works its way down the list of preferred languages looking for the first match. Unfortunately en_GB is not currently at 100% translated state, so some strings do not have an en_GB translation, so it goes to the next language in your list, so German, and if that doesn't have a translation then French, and so on until there are no more languages in teh preferred list and it falls back to en_US. This is how you get mixed up languages. It does seem a little strange that German is incomplete for the same module and you get French added in, but I'd need to look at the translation files to see how complete they are. If you only want you gui in all English, you should remove all the other languages so that if a string lookup in en_GB fails it will fall-back to the en_US instead which will always have a translation. There might be a case that we should automatically fall back to en_US if there is no en_GB. Oh, and the reason why en_GB is incomplete is it's a special case translation, we have a team of native English speakers doing the en_GB translations to check that the original en_US strings written by our international development team of non-English speakers are correct English, so the process is somewhat slower and they have a backlog.
Would it make sense to special case the lookup of en_GB? If no en_GB translation is provided, immediately use en_US, without looking next language in list.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
This happens with en_US to me as well and with Plasma 5.16. I have American English as default, some other language in second place and what happens is all the GTK apps are in the second language, while in KDE apps it bleeds through here and there. Example in Dolphin, note the "Ordner": https://i.imgur.com/aXLRXM7.png Example in a GTK app: https://i.imgur.com/MX7JhoD.png
See recent related bug in KDE Neon that is reproducible. https://bugs.kde.org/show_bug.cgi?id=409313
I can trivially reproduce Filip's issue.
*** Bug 410139 has been marked as a duplicate of this bug. ***
When only one language is present in the list, the issue doesn't appear. But once you add at least one more, it will happen.
Hi Nate, Yeah, in fact I removed spanish and let english only, and I'm getting the console messages in english now. But I won't be able to work properly with Libreoffice, because I write in spanish. So it's still an important problem. Regards, Luis.
Yep, I was just posting a workaround, not a real fix or solution. It's definitely a bug that needs to be fixed.
I've run into this recently with fresh installs of openSUSE Leap 15.1, using the default Plasma 5.12.8 with Frameworks 5.55.0, Qt 5.9.7. I see the following bugs are related and can be linked here: https://bugs.kde.org/show_bug.cgi?id=352903 https://bugs.kde.org/show_bug.cgi?id=344588 Also some possible background to this in https://bugs.kde.org/show_bug.cgi?id=176650 Finding the culprit on my own systems has been something of an adventure but reading some of the comments in the above-linked bugs only leaves me confused. Essentially, the application of the language settings seems illogical to me. In Regional Settings -> Language, I put British English first, followed by American English, then français third. The result is a mishmash of languages, with most KDE/Qt apps in English, but many others in either French or a confusion of French and English. openSUSE's YaST Control Centre shows its primary menu in French but subsequent modules in English. Konsole is in English for my user account but when I su to root, I get console messages in French. Firefox and Thunderbird show many but not all interface elements in French. I tried deselecting certain language packages and editing locale settings but nothing I changed had the desired effect. I finally tried removing français from the third (last) place in the Preferred Languages list and everything is back to English. But this is not logical. In my example, I would only expect to see French translations if there was no English available at all, be it British or American. It is the last fallback. Somehow it is instead being pushed forward and preferred over those others. Ultimately for my own needs, I can either add français on occasions I need it, put it top of the list, then log out and back in, or for some KDE apps I can switch the interface language independently from the Help menu. But I'd prefer to have one, overarching logical and easily managed setting than a personal way of dealing with a quirk.
*** Bug 419911 has been marked as a duplicate of this bug. ***
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 176650, bug 176650 M +21 -10 startkde/startplasma.cpp https://invent.kde.org/plasma/plasma-workspace/commit/edc64d04a1e569d7032c41e6ee0ebf59833c26f2
*** Bug 426473 has been marked as a duplicate of this bug. ***
(In reply to Filip Fila from comment #6) > I have American English as default, some other language in second place and > what happens is all the GTK apps are in the second language, while in KDE > apps it bleeds through here and there. reported as bug 416771
bug 192019 seems related/duplicate
*** Bug 192019 has been marked as a duplicate of this bug. ***
*** Bug 427773 has been marked as a duplicate of this bug. ***
*** Bug 429273 has been marked as a duplicate of this bug. ***
As per #2 if no translations exist, we fall back to English. This is expected behaviour and not a bug. This ticket has a very messy history and marking dupes with 10 year old bug reports isn't very helpful
*** Bug 406097 has been marked as a duplicate of this bug. ***
Created attachment 133784 [details] attachment-18811-0.html Sounds like, marking it as a duplicate is a permanent fix Thanks On Tue, 2020-12-01 at 16:01 +0000, Nate Graham wrote: > https://bugs.kde.org/show_bug.cgi?id=327757 > > Nate Graham <nate@kde.org> changed: > What |Removed |Added---------------------- > --------------------------------------------------- > --- CC| |priit@ww.ee > > --- Comment #24 from Nate Graham <nate@kde.org> ---*** Bug 406097 has been > marked as a duplicate of this bug. *** >
If I understand comment 23 correctly, it works as intended. Otherwise, please clearly state which information is missing to further investigate the issue.
(In reply to David Edmundson from comment #23) > As per #2 if no translations exist, we fall back to English. > > This is expected behaviour and not a bug. > > This ticket has a very messy history and marking dupes with 10 year old bug > reports isn't very helpful This bug is about one specific issue and is not messy at all. The issue is that the language KCM's priority list seems broken such that adding additional languages farther down in the list will inappropriately cause some apps and command-line programs to use text from those languages, even if text exists for languages *higher up* in the priority list. For example if you have American English as the top language, you should never see text from any other languages, because American English is by definition 100% complete since it's the language that all other languages are translated from. It has no missing strings. Can still reproduce the bug of mixed-up languages in apps once you add multiple languages to the KCM; re-opening.
Hmm no actually maybe you're right you're right. The issue I'm describing is reported originally by Bug 192019, not this. Re-marking duplicates (which are all reporting the issue I described).