|Summary:||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|
|Component:||kcm_language||Assignee:||Nate Graham <nate>|
|Severity:||normal||CC:||alex4orly, annma, auxsvr, axel.braun, bugseforuns, carlo, caslav.ilic, cougar73, dchmelik, doggoofspeed, dschridde+kde, gjditchfield, luiseduardovp, miklcct, mpyne, nate, plasma-bugs, postix, sadiyumusak, sebastian, smorg, tusooa, wazhai|
|Latest Commit:||https://invent.kde.org/plasma/plasma-workspace/commit/134e2d5c989c36ac0e985ee0ae382996c6b7b56e||Version Fixed In:|
Screenshot of English + occasional German
screenshot of mixed languages (mostly english in spite of language settings)
System Settings Keyboard Layout in German as top language
The Type property is still in French while in SystemSettings English US is first language and French second.
Some KHelpCenter entries are in French in the content index with a UTF8 problem. EnglishUS is first language is SystemSettings and French is second.
Description stompdagger1 2009-05-08 12:06:50 UTC
Version: 4.2.3 (using Devel) Compiler: gcc-4.3.3 OS: Linux Installed from: Compiled sources sorry for the kinda not related issue to systemsettings, I had no idea how to label this. I have 3 languages set, the first one is english, second is hebrew and third is spanish. the gui I see is in english. but, for example, when I open helpcenter, all the manuals are in spanish, more over, when using dolphin, most of the things are in english but when I view a file's information, the type is in spanish too.
Comment 1 stompdagger1 2009-06-25 06:19:55 UTC
got more data, if I add english and hebrew in regional & languages no problem occurs, but when I add spanish the error happens.
Comment 2 Anne-Marie Mahfouf 2009-06-25 09:14:06 UTC
What distribution do you use? If you put English on top, everything should be in English, the others being only fallbacks. I just tried with French and Arabic in trunk and it works OK. This will allow you change the language per application using the Help -> Switch Application Language... dialog but should leave everything in English. You said "got more data, if I add english and hebrew in regional & languages no problem occurs, but when I add spanish the error happens." When you add Spanish, do you then put English back as top language? Do you see systemsettings GUI language change as you do? Can you add a screenshot of SystemSettings dialog with the 3 languages please?
Comment 3 stompdagger1 2009-06-25 11:31:28 UTC
(In reply to comment #2) > What distribution do you use? > > If you put English on top, everything should be in English, the others being > only fallbacks. I just tried with French and Arabic in trunk and it works OK. > This will allow you change the language per application using the Help -> > Switch Application Language... dialog but should leave everything in English. > > You said "got more data, if I add english and hebrew in regional & languages no > problem occurs, but when I add spanish the error happens." > When you add Spanish, do you then put English back as top language? Do you see > systemsettings GUI language change as you do? Can you add a screenshot of > SystemSettings dialog with the 3 languages please? I use gentoo, adding english and hebrew causes no problems, but the minute I add spanish, no matter if I select english on top, the description is still n spanish whereas the gui is in english. strangely, I'm unable to repreduce it right now, will try on my new profile and report backm,y findings.
Comment 4 Michael Pyne 2009-06-26 05:06:55 UTC
I can confirm, using US English followed by German as a secondary language. I will attach a screenshot so you can see what the reporter is referring to. I also see the problem in displayed mimetypes (not just in Dolphin, but basically anywhere, including KFileDialog).
Comment 5 Michael Pyne 2009-06-26 05:09:07 UTC
Created attachment 34818 [details] Screenshot of English + occasional German This screenshot shows US English pretty much everywhere, except for the left sidebar, which shows up translated into German. This is with US English and German languages available in the Regional settings, with US English as the priority.
Comment 6 Anne-Marie Mahfouf 2009-06-26 09:25:03 UTC
I don't reproduce, nor with US English as 1 and French as 2 or with US English as 1 and German as 2. I restarted KDE to be sure after setting German as second language. I don't see a word of German anywhere. Does the bug happens as soon as you set German as second language? Maybe this is triggered by some global variables related to languages, mine from set are LANG=en_GB LANGUAGE=en_GB:en LC_ADDRESS=fr_FR LC_COLLATE=en_GB LC_CTYPE=en_GB LC_IDENTIFICATION=fr_FR LC_MEASUREMENT=fr_FR LC_MESSAGES=en_GB LC_MONETARY=fr_FR LC_NAME=fr_FR LC_NUMERIC=fr_FR LC_PAPER=fr_FR LC_SOURCED=1 LC_TELEPHONE=fr_FR LC_TIME=en_GB
Comment 7 Skander Morgenthaler 2009-06-27 06:52:55 UTC
Created attachment 34856 [details] screenshot of mixed languages (mostly english in spite of language settings) I am having this problem the other way around. I want German localization and it is the only language set in systemsettings, but menues, toolbars etc. still stick to English. Some other strings are translated, though. Specifying en_US as the second language does not change anything (it should not anyway). For an example see my attached screenshot. I am also using gentoo (amd64) and have seen this behaviour ever since I set up this computer (kde 4.2.x | x>0).
Comment 8 Anne-Marie Mahfouf 2009-06-27 12:00:22 UTC
Skander, it looks like you did not restart SystemSettings after you set German. You need to restart any app before it is fully localized. Michael, the bug reporter, do you also experiment Skander's bug when you set only German?
Comment 9 Skander Morgenthaler 2009-06-27 13:01:19 UTC
I did. By now I even restarted my computer. As in the past it did not help at all, KDE and SystemSettings still look exactly the same.
Comment 10 Anne-Marie Mahfouf 2009-06-27 13:54:06 UTC
Skander, I think this is on your system, I asked on IRC and Gentoo users with German do not reproduce this for System Settings for example. ENglish is only present when German translations are missing. I cannot reproduce any of the problems on my system (self build from KDE sources) If I set German on top in System Settings, I get all German, if I set English on top then German, I get all in English. I also use KDE in French to check French translations and only get English words when the translation to French is missing. I never heard of such a problem except with Ubuntu installations when Ubuntu do not ship KDE translations but some own translations files.
Comment 11 Michael Pyne 2009-06-27 20:39:09 UTC
annma, when I set only German I get the German strings but most of the strings on the spell checking and keyboard layout dialogs are still untranslated (I'm not sure if that's due to missing translation or not though :-/) I will say that I didn't see this the bug that was reported until I had setup German as a second language to US English. When it was just US English everything was fine, now mimetypes and some other strings get translated even though German has been removed from the list. Only thing I can think of is that adding a language tweaks some flags/settings that are not updated when removing a language from the list?
Comment 12 stompdagger1 2009-06-27 21:08:25 UTC
I'm not using germen, I think the issue is when adding second layout other than english which is latin based
Comment 13 Anne-Marie Mahfouf 2009-06-28 10:08:07 UTC
Created attachment 34881 [details] System Settings Keyboard Layout in German as top language
Comment 14 Anne-Marie Mahfouf 2009-06-28 14:10:25 UTC
OK I can indeed reproduce now the Type translation problem. Settings French on top then switching to English US as first and French second, the type in a Properties file is still in French. See attached screenshot. Same for some elements in KHelpCenter but not the same as you Michael. Also screenshot attached If I remove the second language in SystemSettings then the problems get fixed (if I only keep English US then the French part in Dolphin Properties, Type: disapeears.
Comment 15 Anne-Marie Mahfouf 2009-06-28 14:12:53 UTC
Created attachment 34887 [details] The Type property is still in French while in SystemSettings English US is first language and French second.
Comment 16 Anne-Marie Mahfouf 2009-06-28 14:15:14 UTC
Created attachment 34889 [details] Some KHelpCenter entries are in French in the content index with a UTF8 problem. EnglishUS is first language is SystemSettings and French is second.
Comment 17 Anne-Marie Mahfouf 2009-06-28 14:18:15 UTC
CCing Chusslove Illich who is l10n guru. Chusslove, can you please have a look to that bug and re-assign it to the right component? Thanks a lot!
Comment 18 stompdagger1 2009-06-28 14:19:26 UTC
great, that is exactly what I see.
Comment 19 Chusslove Illich 2009-06-28 14:57:12 UTC
I think all the problematic strings on screenshots come not from PO files at runtime, but from other, special sources (.desktop files, documentation stack...) There should be no problem with English on top for strings from runtime POs, but these special sources are questionable, as English may be incorrectly treated as "raw source string, look for translation". On the other hand, English on top (as opposed to English-only) is a strange setting, and I don't think it's worth the time to examine every problematic code path and see what and how to fix to honor it -- that would make this bug "won't fix". Stompdagger1, what's your reason for English-Hebrew- Spanish, instead of just English?
Comment 20 stompdagger1 2009-06-28 19:25:43 UTC
the fact that I'm not the only one that is using the computer and they speak hebrew/spanish better than english... I understand the low severity of this issue but marking this as wont fix is disrespecting users by releasing a program with a known bug. that is something I came to expect from oses like windows and osx but not from the open source community. think of the repercussion when an outsider sees that minor bugs are been ignored in kde, what should he think on major bugs that are hard to track down. I urge you not to mark it has won't fix and not ignoring this issue. on the other hand, why were this feature designated for?
Comment 21 Chusslove Illich 2009-06-28 19:38:52 UTC
Do we have a misunderstanding here? A bug of this magnitude in the ordering (from top to bottom) Spanish-Hebrew-English or Hebrew-Spanish-English would be something for which the release of the whole of KDE would be delayed until fixed. The odd ordering, the one which I don't understand the need for, and therefore asking you why you are using it, is English-Whatever- Whatever.
Comment 22 András Manţia 2009-06-28 19:55:32 UTC
If the same computer (and account) is used by different speaking users Engligh-Somelanguage-Someotherlanguage is not uncommon. One user knows a language, the other another one, the other from the list only Enligh. Actually I have a setup like that in a public place (running KDE3) where on login they select the language, and in that case the order can be anything, like English-Hungarian-Romanian or Hungarian-English-Romanian, etc.
Comment 23 stompdagger1 2009-06-28 22:11:30 UTC
(In reply to comment #21) > Do we have a misunderstanding here? A bug of this magnitude in the ordering > (from top to bottom) Spanish-Hebrew-English or Hebrew-Spanish-English would > be something for which the release of the whole of KDE would be delayed > until fixed. The odd ordering, the one which I don't understand the need > for, and therefore asking you why you are using it, is English-Whatever- > Whatever. I've never said that this bug should in anyway delay the entire release. what I've said that by labeling this bug has "wont fix", the bug will not be resolved in later releases. all I'm saying is that, due to the minority of the bug, it should be fixed, when? it is up to you to decide because you are the one incharge of this. again, I have more then one users on the computer, not much of space and I don't want to dedicate unneeded space allocation for another 2 profiles. in the bottom line, what ever you decide, we will have to accept it.
Comment 24 Chusslove Illich 2009-06-30 02:21:46 UTC
SVN commit 989334 by ilic: Do not automatically push English to lowest priority, honor user settings. CCBUG: 192019 M +2 -2 kdebase/runtime/khelpcenter/view.cpp M +2 -2 kdelibs/kdecore/localization/klocale.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=989334
Comment 25 Chusslove Illich 2009-06-30 02:31:45 UTC
SVN commit 989336 by ilic: When a comment does not have a language set, assume and explicitly store it as English. Otherwise, English is getting overriden if higher by priority then another language which also has a comment in it. CCBUG: 192019 M +5 -4 kbuildmimetypefactory.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=989336
Comment 26 Chusslove Illich 2009-06-30 02:46:57 UTC
I've fixed the two bugs clearly demonstrated by Anne-Marie's screenshots. Other issues are probably due to caching of stuff, so log out/in, possibly delete everything in ~/.kde/cache-*/ if relogging doesn't work. In general, switching language, or any other setting, under the same account all the time, due to different users using that same account, is very poor usage habit on a multiuser operating system (with the possible exception of Andras' case of a public machine, where I've no idea what the best practices are...) I hope these fixes do not encourage it. I'd rather not close the bug yet, in case there is something more amiss.
Comment 27 stompdagger1 2009-06-30 07:07:43 UTC
thanks for the update, as soon as I can get the chance to test it, I'll try and post my findings.
Comment 28 Skander Morgenthaler 2009-07-05 04:33:21 UTC
Unfortunately neither deleting the cache-directory nor moving away .kde (and .kde4) nor updating to 4.3RC1 made my language mix go away. Any idea where I could start looking for solutions? Are there system variables that override settings made within kde that need to have a certain value?
Comment 29 Michael Pyne 2009-07-05 05:20:51 UTC
Skander, Chusslove's fixes were revisions 989334 through 989337 so you need to make sure your kdelibs is more recent. You said you were testing RC1 but according to Websvn, the tag for kdelibs was created 10 days ago and is only up to 986427. Or in other words you need to update to latest 4.3 branch or trunk to test.
Comment 30 Skander Morgenthaler 2010-02-24 02:56:21 UTC
I finally found out more , parts of the localization seem to depend on the value of the LANG environment variable. LANG=de_DE.utf-8: KDE is completely localized, everything is German or English, depending on language settings in systemsettings LANG=en.utf-8: LANG=some language not present on my system: LANG not set/unset: KDE is either completely in English (if set to English in systemsettings) or a mix of German and English if set to German. I had LANG set to de_DE.utf-8 - but only for my normal user (using ~/.bashrc). When starting KDE from within kdm, it is set to the systemwide default, wich was not set in my case.
Comment 31 Chusslove Illich 2010-02-24 11:39:35 UTC
For anything regarding locales to function properly (application language included), LANG or LC_ALL have to be set to an existing system locale (they can be listed by locale -a). (LC_ALL has higher priority than LANG.)
Comment 32 Nate Graham 2020-09-28 13:28:33 UTC
*** This bug has been marked as a duplicate of bug 327757 ***
Comment 33 Nate Graham 2021-09-30 18:59:18 UTC
Can still reproduce by making American English the top language and adding any other languages. In this case, I 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. However instead GUI apps and CLI programs display a mix of languages.
Comment 34 Nate Graham 2021-09-30 18:59:33 UTC
*** Bug 427773 has been marked as a duplicate of this bug. ***
Comment 35 Nate Graham 2021-09-30 18:59:44 UTC
*** Bug 429273 has been marked as a duplicate of this bug. ***
Comment 36 Nate Graham 2021-09-30 19:00:10 UTC
*** Bug 410139 has been marked as a duplicate of this bug. ***
Comment 37 Nate Graham 2021-09-30 19:00:16 UTC
*** Bug 419911 has been marked as a duplicate of this bug. ***
Comment 38 Nate Graham 2021-09-30 19:00:23 UTC
*** Bug 426473 has been marked as a duplicate of this bug. ***
Comment 39 Nate Graham 2021-09-30 19:05:02 UTC
From BUG 437565: Setting “LANGUAGE=en_US” (just one language) or “LANGUAGE=C:fr:ko” fixes the command line. I suppose that few packages have any “en” localizations, and rely on the fall-back “C” strings to serve English users. Perhaps kcm_language should never put an English locale by itself in LANGUAGE; it should always follow it with C, as in “LANGUAGE=fr:en_CA:C:ko”.
Comment 40 Nate Graham 2021-09-30 19:05:12 UTC
*** Bug 437565 has been marked as a duplicate of this bug. ***
Comment 41 Nate Graham 2021-09-30 19:05:21 UTC
*** Bug 422636 has been marked as a duplicate of this bug. ***
Comment 42 Nate Graham 2021-09-30 19:05:40 UTC
*** Bug 417420 has been marked as a duplicate of this bug. ***
Comment 43 Nate Graham 2021-09-30 19:22:10 UTC
*** Bug 435852 has been marked as a duplicate of this bug. ***
Comment 44 gjditchfield 2021-09-30 19:34:24 UTC
(In reply to Nate Graham from comment #39) > Perhaps kcm_language should never put an English locale by itself in > LANGUAGE; it should always follow it with C, as in “LANGUAGE=fr:en_CA:C:ko”. ... more specifically, follow the right-most English locale: "LANGUAGE=fr:en_CA:en_GB:en:C:ko"
Comment 45 Nate Graham 2021-09-30 20:00:18 UTC
Yeah, makes sense. Should be a simple fix. I can look into it.
Comment 46 Nate Graham 2021-09-30 20:59:24 UTC
*** Bug 416771 has been marked as a duplicate of this bug. ***
Comment 47 Nate Graham 2021-09-30 21:00:40 UTC
And from Bug 416771: The problem seems to be that many GTK apps don't explicitly name or alias their English locale as "en" or "en_US", but instead make it the default locale, which is "C". For these apps if you have "LANGUAGE=en_US" it will try to find the en_US locale, fail, and fallback to the default locale, C, which just usually happens to be English, so it *seems* to work. But if you have "LANGUAGE=en_US:zh_CN" it tries to find en_US, fails, moves onto zh_CN, finds it, and so displays Chinese. This can be verified by using "LANGUAGE=C:zh_CN", which for most GTK apps should cause them to display English. Or at least *mostly* English: for Evolution it causes some fields/labels to be in Chinese. Possible solutions: 1) When generating plasma-localerc, try to guess a good place to insert "C" into LANGUAGE. 2) In the "Configure Plasma translations" GUI, have a "GTK default" language which will be second in the list when plasma-localerc has no [Translations] section. The user can then change its position in the list or delete it. --- #1 is similar to the already-proposed idea, which I like because it will be invisible to users and we won't have to explain all this stuff in the UI. I'll try to block out some time to work on that.
Comment 48 Bug Janitor Service 2021-10-01 04:11:48 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087
Comment 49 Patrick Silva 2021-11-15 19:34:18 UTC
*** Bug 445450 has been marked as a duplicate of this bug. ***
Comment 50 Nate Graham 2022-01-12 19:32:36 UTC
*** Bug 447783 has been marked as a duplicate of this bug. ***
Comment 51 Michael Tsang 2022-01-13 15:23:19 UTC
(In reply to Nate Graham from comment #47) > And from Bug 416771: > > The problem seems to be that many GTK apps don't explicitly name or alias > their English locale as "en" or "en_US", but instead make it the default > locale, which is "C". For these apps if you have "LANGUAGE=en_US" it will > try to find the en_US locale, fail, and fallback to the default locale, C, > which just usually happens to be English, so it *seems* to work. But if you > have "LANGUAGE=en_US:zh_CN" it tries to find en_US, fails, moves onto zh_CN, > finds it, and so displays Chinese. This can be verified by using > "LANGUAGE=C:zh_CN", which for most GTK apps should cause them to display > English. Or at least *mostly* English: for Evolution it causes some > fields/labels to be in Chinese. > > Possible solutions: > > 1) When generating plasma-localerc, try to guess a good place to insert "C" > into LANGUAGE. > > 2) In the "Configure Plasma translations" GUI, have a "GTK default" language > which will be second in the list when plasma-localerc has no [Translations] > section. The user can then change its position in the list or delete it. > > > --- > > > #1 is similar to the already-proposed idea, which I like because it will be > invisible to users and we won't have to explain all this stuff in the UI. > I'll try to block out some time to work on that. From my understanding C should mean "untranslated", so the above behaviour is expected and a bug report should be filed to the appropriate software for not coming with English translation.
Comment 52 Nate Graham 2022-01-13 15:32:19 UTC
Yes, tons of apps treat C as "American English" instead of having an explicit en_US translation. That's the cause of this issue. Unfortunately we can't fix the world especially for such a widespread issue. Feel free to follow up with the apps in question, but from the Plasma perspective, all we can do is either warn people about it or prevent configuring it this way. This comment in my merge request seemed to sum it up nicely: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087#note_313992 > In a way, this is a work-around for a bug in society. Most programmers put English strings > in the C locale, assume that they can fall back to C, and hence don't bother to provide full > English localizations. That only works if English is at the end of the LANGUAGE variable. > The resulting feedback loop makes C an English locale in practice.
Comment 53 Nate Graham 2022-04-18 15:31:55 UTC
*** Bug 452714 has been marked as a duplicate of this bug. ***
Comment 54 Nate Graham 2022-06-28 18:52:14 UTC
*** Bug 456050 has been marked as a duplicate of this bug. ***
Comment 55 hanyoung 2022-07-02 09:30:26 UTC
Git commit 134e2d5c989c36ac0e985ee0ae382996c6b7b56e by Han Young. Committed on 02/07/2022 at 09:29. Pushed by hanyoung into branch 'master'. merge Language and Formats Related: bug 341235, bug 344588, bug 394477, bug 397974, bug 397975, bug 403580, bug 417564, bug 420268, bug 429474, bug 431292, bug 444772, bug 446785, bug 447787, bug 448324, bug 448355, bug 451919, bug 451944, bug 454991 closes https://invent.kde.org/plasma/plasma-workspace/-/issues/23 M +1 -0 .kde-ci.yml M +52 -8 CMakeLists.txt M +2 -1 config-workspace.h.cmake D +0 -2 doc/kcontrol/formats/CMakeLists.txt D +0 -63 doc/kcontrol/formats/index.docbook R +1 -1 doc/kcontrol/region_language/CMakeLists.txt [from: doc/kcontrol/translations/CMakeLists.txt - 063% similarity] R +- -- doc/kcontrol/region_language/go-top.png [from: doc/kcontrol/translations/go-top.png - 100% similarity] R +36 -23 doc/kcontrol/region_language/index.docbook [from: doc/kcontrol/translations/index.docbook - 050% similarity] A +- -- doc/kcontrol/region_language/list-remove.png D +- -- doc/kcontrol/translations/list-remove.png M +1 -2 kcms/CMakeLists.txt D +0 -30 kcms/formats/CMakeLists.txt D +0 -5 kcms/formats/Messages.sh D +0 -61 kcms/formats/formatssettings.kcfg D +0 -80 kcms/formats/kcmformats.cpp D +0 -34 kcms/formats/kcmformats.h D +0 -183 kcms/formats/localelistmodel.cpp D +0 -140 kcms/formats/optionsmodel.cpp D +0 -126 kcms/formats/package/contents/ui/main.qml A +75 -0 kcms/region_language/CMakeLists.txt A +8 -0 kcms/region_language/Messages.sh R +2 -27 kcms/region_language/exampleutility.cpp [from: kcms/formats/exampleutility.cpp - 052% similarity] A +22 -0 kcms/region_language/exampleutility.h [License: GPL(v2.0+)] A +82 -0 kcms/region_language/kcm_regionandlang.desktop [TRAILING SPACE] ** [TRAILING SPACE] ** R +4 -4 kcms/region_language/kcm_regionandlang.json [from: kcms/formats/kcm_formats.json - 098% similarity] A +250 -0 kcms/region_language/kcmregionandlang.cpp [License: GPL(v2.0+)] A +58 -0 kcms/region_language/kcmregionandlang.h [License: GPL(v2.0+)] A +372 -0 kcms/region_language/languagelistmodel.cpp [License: GPL(v2.0+)] A +100 -0 kcms/region_language/languagelistmodel.h [License: GPL(v2.0+)] A +30 -0 kcms/region_language/localegenerator.cpp [License: LGPL(v2.0+)] A +17 -0 kcms/region_language/localegenerator.h [License: LGPL(v2.0+)] A +19 -0 kcms/region_language/localegeneratorbase.cpp [License: GPL(v2.0+)] A +23 -0 kcms/region_language/localegeneratorbase.h [License: GPL(v2.0+)] A +32 -0 kcms/region_language/localegeneratorglibc.cpp [License: GPL(v2.0+)] A +24 -0 kcms/region_language/localegeneratorglibc.h [License: GPL(v2.0+)] A +101 -0 kcms/region_language/localegeneratorubuntu.cpp [License: GPL(v2.0+)] A +27 -0 kcms/region_language/localegeneratorubuntu.h [License: GPL(v2.0+)] A +36 -0 kcms/region_language/localegenhelper/CMakeLists.txt A +187 -0 kcms/region_language/localegenhelper/localegenhelper.cpp [License: GPL(v2.0+)] A +46 -0 kcms/region_language/localegenhelper/localegenhelper.h [License: GPL(v2.0+)] A +20 -0 kcms/region_language/localegenhelper/org.kde.localegenhelper.conf A +21 -0 kcms/region_language/localegenhelper/org.kde.localegenhelper.policy A +8 -0 kcms/region_language/localegenhelper/org.kde.localegenhelper.service.in A +158 -0 kcms/region_language/localelistmodel.cpp [License: GPL (v2+)] R +22 -22 kcms/region_language/localelistmodel.h [from: kcms/formats/localelistmodel.h - 060% similarity] A +197 -0 kcms/region_language/optionsmodel.cpp [License: GPL(v2.0+)] R +21 -11 kcms/region_language/optionsmodel.h [from: kcms/formats/optionsmodel.h - 054% similarity] A +204 -0 kcms/region_language/package/contents/ui/AdvancedLanguageSelectPage.qml [License: LGPL(v3.0+)] A +238 -0 kcms/region_language/package/contents/ui/main.qml [License: LGPL(v3.0+)] A +64 -0 kcms/region_language/regionandlangsettings.cpp [License: GPL(v2.0+)] A +21 -0 kcms/region_language/regionandlangsettings.h [License: GPL(v2.0+)] A +37 -0 kcms/region_language/regionandlangsettingsbase.kcfg R +2 -2 kcms/region_language/regionandlangsettingsbase.kcfgc [from: kcms/formats/formatssettings.kcfgc - 055% similarity] A +17 -0 kcms/region_language/settingtype.h [License: GPL(v2.0+)] D +0 -49 kcms/translations/CMakeLists.txt D +0 -2 kcms/translations/Messages.sh D +0 -191 kcms/translations/language.cpp D +0 -32 kcms/translations/language.h D +0 -312 kcms/translations/package/contents/ui/main.qml D +0 -86 kcms/translations/translations.cpp D +0 -53 kcms/translations/translations.h D +0 -193 kcms/translations/translationsmodel.cpp D +0 -72 kcms/translations/translationsmodel.h D +0 -27 kcms/translations/translationssettings.cpp D +0 -24 kcms/translations/translationssettings.h D +0 -28 kcms/translations/translationssettingsbase.kcfg D +0 -6 kcms/translations/translationssettingsbase.kcfgc The files marked with ** at the end have a problem. Either the file contains a trailing space or the file contains a call to potentially dangerous code. Please read: https://community.kde.org/Sysadmin/CommitHooks#Email_notifications for further information. Please either fix the trailing space or review the dangerous code. https://invent.kde.org/plasma/plasma-workspace/commit/134e2d5c989c36ac0e985ee0ae382996c6b7b56e
Comment 56 wazhai 2023-02-07 21:59:55 UTC
*** Bug 465373 has been marked as a duplicate of this bug. ***
Comment 57 wazhai 2023-02-07 22:13:46 UTC
Created attachment 156049 [details] still happens This bug isn't fixed for good as shown in the attached image and my duplicate bug report, but a fix seems impossible to do in a satisfactory way. What has happened is the implementation of a warning in the Language&Region KCM when en_US is the top language which says that: "Putting American English above other languages will cause undesired behavior in some applications. If you would like your system to use American English, remove all other languages." The reason it can't be fixed is that even en_US isn't necessarily 100% complete because many programs rely on falling back to C for English and don't have en_US strings, while rarely some others will have a non-English language as their "unlocalized C". This means "C" can't simply be appended in a suitable place as a catch-all solution to always show English. For more details: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087 In this issue is deemed action-worthy or actionable at all, this bug can be reopened.
Comment 58 Nate Graham 2023-02-08 04:06:41 UTC
So the way we "solved" this was to put in a warning message not to add any non-English languages below English. But we only did this for American English! We need to do it for the other Englishes as well, like British English and Australian English. Because the same thing happens there too, if your language list ends up looking like en_GB:de_DE. This is invalid, but the user won't know unless we tell them. If this still isn't enough, we might want to reconsider https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1087 and always internally insert "C" after the last en_* language in the list. There was discussion in there about maaaaybe having to do it anyway but hopefully a warning message is enough. So let's start by fixing this issue with the warning message not appearing for other English languages and then see where that leaves us.