SUMMARY The layered accretion of different i18n mechanisms in the entirety of the KDE-over-Qt ecosystem has reached the level of complexity where the technical skill necessary for succeeding at a simple intention like "I want to run this program in a different language than configured in Systemsettings, one-off, without changing settings for the purpose and reverting them afterwards" is now beyond the ability of a regular human. We need software utilities for solving these problems. Specifically, I propose creating a `withlang` utility that could be used to launch a KDE program in a terminal, and will SUCCESSFULLY AND THOROUGHLY launch it in a specified localization, so that EVERY string displayed in that program's window (as opposed to ONLY SOME strings) will be displayed in the desired language: ``` withlang en plasma-systemmonitor ``` STEPS TO REPRODUCE 1. Using Systemsettings, set all localization-related settings to Polish. 2. Log out and back in for good measure. Dzień dobry-śmobry digidi bejbi! 3. In xterm, try to apply your best envvar-fu to SUCCESSFULLY launch plasma-systemmonitor in English, so that ALL UI strings within the program window's client area will be shown in English, as opposed to just SOME. You think it's easy? You've been living blissfully secure in your conviction that setting some environment variable(s) on the command line is all it takes? Well then, I DARE YOU TO TRY, and I welcome you to post your experience in comments. OBSERVED RESULT No matter what I try - LANG, KDE_LANG, KDELANG, LANGUAGE, LC_*, LC_ALL, en([_-]US)?(\.(utf|UTF)-?8)?, I can only get SOME of the strings in the program to show in English. Others are shown in Polish. EXPECTED RESULT A utility like `withlang` should exist and be part of the KDE distribution, so that I could just run `withlang en plasma-systemmonitor` and Get What I Want. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.22.0 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.9-zen1-1-zen (64-bit) Graphics Platform: X11 Processors: 8 × AMD FX(tm)-8320 Eight-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 960/PCIe/SSE2
There is a "Configure Language" menu item in the "Configure" menu of most KDE apps. Is this not sufficiently simple and obvious? Does it not work for you?
1) There is no "Configure" menu in plasma-systemmonitor. 2) Any workaround that involves making and subsequently un-making persistent configuration changes is not sufficiently simple.
3) Adding the missing configurability to plasma-systemmonitor will not solve the general issue.
Let's step back a bit. In general it's helpful to describe the problem accurately instead of proposing a complicated, detailed solution. Because if your proposed solution is rejected, then the problem remains and you're frustrated. https://community.kde.org/Get_Involved/Issue_Reporting#Describe_the_problem_instead_of_proposing_a_solution So can I ask you why exactly you want to be able to override the system language for specific KDE apps?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
> So can I ask you why exactly you want to be able to override the system language for specific KDE apps? I don't want to be able to override the system language for specific KDE apps. I want to be able to override the system language for a **single run** of **any** KDE app. The reason I want it is simple: for writing bug reports in English, and to be able to see the EXACT form of English UI strings to google for when looking for solutions/workarounds. Like this brilliant idea of the "Copy in English" button at the bottom of kinfocenter's summary page, but universal: "run this program in English".
Couldn't you just change the in-app language using the existing functionality (again, for apps that implement it) and then change it back afterwards?
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
> Couldn't you just change the in-app language using the existing > functionality (again, for apps that implement it) and then change it back > afterwards? No and no. No to treating the fact that some apps don't implement it as a minor point, and no to having to make and subsequently un-make a persistent configuration change. It is doable, but it is an insult to the principle which asserts that software should serve the user, not vice versa.
Looking around it looks like setting LANGUAGE env var would work[1] e.g. from terminal: LANGUAGE=en dolphin [1]https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kswitchlanguagedialog_p.cpp#L69
(In reply to Ahmad Samir from comment #11) > Looking around it looks like setting LANGUAGE env var would work[1] e.g. > from terminal: > LANGUAGE=en dolphin > > [1]https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/ > kswitchlanguagedialog_p.cpp#L69 Nope. Screenshot will follow.
Created attachment 150585 [details] Thorough mix of English and Polish. `LANGUAGE=en plasma-systemmonitor` results in this. It fails to launch the program *completely* in English.
... and with dolphin, LANGUAGE has exactly ZERO effect, as opposed to about 40% in the case of plasma-systemmonitor. I'm not even making a screenshot, because it shows no evidence that running it in English was even attempted.
What is the output of the following commands in a new fresh terminal window? echo $LANGUAGE echo $LANG cat ~/.config/plasma-localerc
(In reply to Nate Graham from comment #15) > What is the output of the following commands in a new fresh terminal window? > > echo $LANGUAGE > echo $LANG > cat ~/.config/plasma-localerc ``` $ echo $LANGUAGE pl:en_US $ echo $LANG pl_PL.UTF-8 $ cat ~/.config/plasma-localerc [Formats] LANG=pl_PL.UTF-8 LC_COLLATE=pl_PL.UTF-8 useDetailed=true [Translations] LANGUAGE=pl:en_US ```
> $LANGUAGE > pl:en_US > [Translations] > LANGUAGE=pl:en_US These are invalid settings; putting en_US as the last item in the list always causes mixed-up translations. The new KCM in Plasma 5.36 will warn you about this, thankfully. Please remove en_US from the list of languages, reboot, and try Ahmad's suggestion again.
If putting "en_US" last is an invalid setting, then what is the VALID setting that expresses the intention "use Polish if available and fall back to en_US"? Because that is a perfectly valid intention, and if it is not possible to express it validly with configuration, then we have another issue.
ERRATA (rewriting the above comment, because it is impossible to edit or delete comments) If putting "en_US" last is an invalid setting, then what is the VALID setting that expresses the intention "use Polish if available and fall back to English"? Because that is a perfectly valid intention, and if it is not possible to express it validly with configuration, then we have another issue. Also, exactly WHY does this cause mixed translations, and shouldn't this behavior be fixed instead of being warned against?
I removed en_US from the configuration: ``` $ echo $LANGUAGE pl $ echo $LANG pl_PL.UTF-8 $ cat ~/.config/plasma-localerc [Formats] LANG=pl_PL.UTF-8 LC_COLLATE=pl_PL.UTF-8 useDetailed=true [Translations] LANGUAGE=pl ``` No effect. Symptoms persist.
Ah, my mistake, I was mis-remembering. The bug happens when en_US is *first*, not last. Regardless, en_US is always used as the fallback language automatically, so you don't need to deliberately add it. Beyond that, I don't know how to proceed here.
Changing the status from "reported" to "confirmed" or something similar would be one way to proceed. Could you reproduce this?
I have not tried, as getting translations applied to my built-from-source KDE code isn't trivial.
(In reply to Nate Graham from comment #23) > I have not tried, as getting translations applied to my built-from-source > KDE code isn't trivial. If you currently lack the capability to reproduce l10n issues, wouldn't it be worthwile to step back and do something about that? Why are translations even "applied to (...) code"? As far as I understand, there's one locale-agnostic code, and there are message catalogs, and "applying" a locale should happen entirely at runtime.
I think that Android starting with version 13 has such a feature, maybe it any developer trying to fix this: https://developer.android.com/guide/topics/resources/app-languages https://android-developers.googleblog.com/2022/11/per-app-language-preferences-part-1.html I have not tried it on my Android 13 phone, but I find it useful to have such a feature.
kcachegrind is another program that I find myself unable to run 100% in English when the current user's locale is Polish.