Yast language does not match system language selection in one computer, depends on system-settings!

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.

Have you tried running “qtconfig” from a root shell?

Yast is probably running under settings for the root user rather than for you.

I haven’t dissected your post, but interested to know if this guide is consistent with your experience…

Does this report as expected?


Remember YaST runs as root.

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.

No, I expected what is described item 4.1:

Applications not belonging to your desktop framework are not affected by this change and may still appear in the language that was set in YaST.

It reports the same in all three boxes, run as root and as the local user:

:~> localectl
   System Locale: LC_CTYPE=pt_BR.UTF-8
       VC Keymap: br
      X11 Layout: br
       X11 Model: microsoftpro
     X11 Options: terminate:ctrl_alt_bksp

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.

I think it depends on how you start Yast.

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 …

I always start from the menu, which seems to authenticate with kdesu.

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 …

That’s not the problem, please see previous posts.

Me too. Makes it easier to see when I’m running dolphin as user or root.

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 …

And, if it is, then a KDE Bug Report is needed …