Bug 327757 - Internationalisation: languages mixed
Summary: Internationalisation: languages mixed
Status: RESOLVED INTENTIONAL
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_language (show other bugs)
Version: 5.16.5
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-18 10:51 UTC by Uwe Dippel
Modified: 2021-09-30 19:00 UTC (History)
16 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Shows the weird mixture of all languages (82.19 KB, image/png)
2013-11-18 10:53 UTC, Uwe Dippel
Details
attachment-18811-0.html (1.19 KB, text/html)
2020-12-01 19:42 UTC, Alex Evans
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Dippel 2013-11-18 10:51:41 UTC
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
Comment 1 Uwe Dippel 2013-11-18 10:53:02 UTC
Created attachment 83618 [details]
Shows the weird mixture of all languages
Comment 2 John Layt 2013-11-18 11:21:54 UTC
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.
Comment 3 Christoph Feck 2013-11-18 13:30:52 UTC
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.
Comment 4 Andrew Crouthamel 2018-11-11 04:23:11 UTC
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!
Comment 5 Andrew Crouthamel 2018-11-21 04:50:25 UTC
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!
Comment 6 Filip Fila 2019-07-12 07:27:33 UTC
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
Comment 7 ianp 2019-07-12 08:38:05 UTC
See recent related bug in KDE Neon that is reproducible.
https://bugs.kde.org/show_bug.cgi?id=409313
Comment 8 Nate Graham 2019-07-12 14:11:51 UTC
I can trivially reproduce Filip's issue.
Comment 9 Nate Graham 2019-07-23 16:38:42 UTC
*** Bug 410139 has been marked as a duplicate of this bug. ***
Comment 10 Nate Graham 2019-07-24 16:31:43 UTC
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.
Comment 11 Luis Vivero Peña 2019-07-24 16:37:40 UTC
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.
Comment 12 Nate Graham 2019-07-24 16:58:55 UTC
Yep, I was just posting a workaround, not a real fix or solution. It's definitely a bug that needs to be fixed.
Comment 13 gumb 2019-09-03 15:29:45 UTC
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.
Comment 14 Nate Graham 2020-04-15 03:22:19 UTC
*** Bug 419911 has been marked as a duplicate of this bug. ***
Comment 15 Bug Janitor Service 2020-06-20 08:22:10 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/100
Comment 16 Alexander Lohnau 2020-06-25 13:19:36 UTC
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
Comment 17 Patrick Silva 2020-09-27 15:18:50 UTC
*** Bug 426473 has been marked as a duplicate of this bug. ***
Comment 18 Patrick Silva 2020-09-27 15:21:23 UTC
(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
Comment 19 Patrick Silva 2020-09-27 15:23:50 UTC
bug 192019 seems related/duplicate
Comment 20 Nate Graham 2020-09-28 13:28:33 UTC
*** Bug 192019 has been marked as a duplicate of this bug. ***
Comment 21 Patrick Silva 2020-10-15 20:03:24 UTC
*** Bug 427773 has been marked as a duplicate of this bug. ***
Comment 22 Nate Graham 2020-11-18 21:02:20 UTC
*** Bug 429273 has been marked as a duplicate of this bug. ***
Comment 23 David Edmundson 2020-11-25 00:08:54 UTC
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
Comment 24 Nate Graham 2020-12-01 16:01:40 UTC
*** Bug 406097 has been marked as a duplicate of this bug. ***
Comment 25 Alex Evans 2020-12-01 19:42:12 UTC
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. ***
>
Comment 26 Christoph Feck 2020-12-11 17:20:19 UTC
If I understand comment 23 correctly, it works as intended. Otherwise, please clearly state which information is missing to further investigate the issue.
Comment 27 Nate Graham 2021-09-30 18:52:18 UTC
(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.
Comment 28 Nate Graham 2021-09-30 18:56:52 UTC
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).