KDE/Plasma on three desktop computers, all updated today.
Yast control center is in pt_BR, the system language set in all three, with no secondary language set.
BUT, in just one of the desktops all Yast modules open in English, not in pt_BR as the other two!
Now, of the two correct boxes, one has no language set in system-settings>local configurations, and the other has this set to pt_BR.
The “wrong” box, however, has both pt_BR and English set as preferred languages, with pt_BR on top, which I suppose makes English the secondary KDE language.
If I remove English from system-settings>local config>language, yast modules are shown in pt_BR after restarting the session.
WTH??? Yast modules language depend on KDE/Plasma settings, but not Yast’s control center? And how can user Plasma settings affect Yast that run as root???
I thought it would be a qtconfig setting, but apparently not.
No, I didn’t get that far. The issue was fixed with local kde settings, that is the puzzling part.
AFAIK that’s how it normally runs. Isn’t yast’s language settings system-wide, while kde system-settings language is user-specific?
My surprise is in that a local setting could affect a root-owned yast module. It seems like a mix-up.
Interestingly, when run for the first time after boot in the “wrong” box, it took many seconds to return the result. Subsequent runs were instantaneous, including after a session restart.
So, I re-added American English in kde system-settings language, below pt_BR, and after restarting the session, the yast modules reverted to English, but localectl still reports the same.
If you do “su -” at the command line, and then run “yast2” from that root command line, Yast will see $HOME as “/root” and use the setting for user root. I’m not sure what happens if you use “kdesu” since I don’t do that. But it may leave $HOME as your home directory and use your settings. And if you start Yast from menus, it probably use “xdg-su” or similar, and that probably works the same as “kdesu”.
For YaST, it’s in ‘/etc/sysconfig/language’ – at the end of the file: INSTALLED_LANGUAGES=“de_DE” – in my case …
A “Gotcha” is in ‘/etc/sysconfig/keyboard’ : once again, for YaST, at the end of the file there’s YAST_KEYBOARD=“german,pc104” – in my case. If anything other than ‘pc104’ is used, then the experience is unpleasant – there’s an old post somewhere in this Forum …
OK, but what puzzles me is why a kde setting changes all yast modules language setting. It shouldn’t, and if it should, why don’t it also changes the Yast interface (i.e., Yast command center) language?
Normally, YaST runs with everything associated with the user “root”.
On a KDE system, you have to login to a KDE session as the user “root” and then set-up the user “root”; including “~/.profile” (the language EXPORT) and, the KDE preferences …
Currently, I tend to set-up the KDE Window appearance for the user “root” differently to my “normal” user’s window appearance …
Assuming that, it’s only possible to start a KDE YaST session if the ‘root’ password is known and, the user ‘root’ (and therefore YaST as well) is set-up to use the language that the SysAdmin wishes to use and, the Admin logged out and logged back in again after the language settings for the user ‘root’ and YaST were set-up, then, the user’s KDE settings shouldn’t be affected the YaST windows …