Windows | UI Language wrong if user preference != system default

[tmontes]

Issue

On the Windows platform, when the user language preference is different from the system default language preference, Mu assumes the system default one, instead of the user's.

Observed on Windows 10. Not sure about other releases.

Steps to reproduce

(assuming an English based installation, otherwise will vary)

1. Log in with an administrative user.

2. The general UI should be displayed in English (check the start menu, for example).

3. Go to "Settings" > "Time & Language" > "Region & Language".

4. Confirm that "Windows display language" is set to English.

5. Add a language, say "Français (France)" taking care in deactivating "Set as my Windows display language" during the process. This may take a little while.

6. When done, the language should be listed as "Language pack installed".

7. Confirm that "Windows display language" is still set to English.

8. Close the "Settings" window and sign out.

9. Log in as a different, non-administrative user.

10. The general UI should be displayed in English (check the start menu, for example).

11. Go to "Settings" > "Time & Language" > "Region & Language".

12. In my experiments, the admin-installed language isn't available yet. It needs to be "reinstalled" so repeat the procedure of installing "Français (France)", this time leaving the "Set as my Windows display language" active during the process -- for some reason, this needs an admin password (also, none of this works on my system if I don't do the language install as admin).

13. Confirm that "Windows display language" is set to "Français (France)" (set it, otherwise). Again, in my experience, I had to close the "Settings" and re-open it to get the option to be selectable.

14. Close the "Settings" window, sign out and sign back in.

15. The general UI should be displayed in French (check the start menu, for example), even though the default system language is still English.

Finally:

16. Launch Mu
17. The UI is presented in English instead of French.

Investigation

When faced with this, and after believing that Qt's QLocale would handle all of these troubles for us, as shared in #763 and implemented in #764, I quickly experimented with a REPL with the Mu Python environment as of the current master:

>>> from PyQt5.Qt import QLocale
>>> QLocale.system().name()
'en_US'

I then tried the previously used:

>>> import locale
>>> locale.getdefaultlocale()
('en_US', 'cp1252')

How cool is this? Or frustrating?... :-)

I then browsed the QLocale API docs and found QLocale().uiLanguages() which seems promising:

>>> from PyQt5.Qt import QLocale
>>> QLocale().uiLanguages()
['fr-fr', 'en-US']

macOS

I tried it on macOS 10.14.6 where my Language settings are "English" but region is "Portugal", that gives me:

>>> from PyQt5.Qt import QLocale
>>> QLocale().uiLanguages()
['en-PT', 'pt-PT']

...which, I guess, kind of makes sense, even though 'en-PT' isn't a common language spec.

Ubuntu Linux

Then, on Ubuntu 18.04 LTS, with the UI language set to Portuguese:

>>> from PyQt5.Qt import QLocale
>>> QLocale().uiLanguages()
['pt-PT', 'en-US', 'en']

Parting Words

All in all this is a very tiny detail, but one that can be improved by using QLocale().uiLanguages(). The macOS solution might need some adjustments given the 'en-PT' I'm getting: I suppose other Language/Region combinations will produce similarly funny / non-matching language codes for the locales that Mu includes. But that doesn't feel difficult to handle.

This is it. Feedback welcome. :)

[aroberge]

This, to my mind, is another reason to add a language selector so that the user can pick the language they want, rather than the one deduced by whatever algorithm is put in place.

Another bonus of having a language selector is that developers could easily confirm that all UI elements have a valid translation in languages that are supposed to be supported.

[tjguk]

I admit to a certain frustration with users here ;) My own feeling is:

• There is already a (system or user-wide) means of setting preferred language in every operating system we support
• We ask the OS what the preferred language is (possibly not correctly as here; but that could be corrected)
• We supply an interface in that language just as your browser, "Start Menu" etc. do
• ... and then you say you want to change it because, although your entire system is operating in Catalan [one of my young coders] you actually want the editor to be in English!

IOW -- although I accept that several people are asking for this very thing -- I feel that a language selector is exactly something we shouldn't need to support because it's supported by the operating system itself. Perhaps to too great an extent, I value the fact that Mu doesn't have a myriad dials and buttons which let you tweak every single aspect of the UI or behaviour.

Now I can produce an argument against my own position here because we already have a Light/Dark/Contrast style switcher which could also, arguably, be said to supersede the OS style selector. I can probably come up with some more or less convincing reason why this is A Good Thing (eg because in particular lighting conditions this would be useful in a classroom situation). But perhaps we could do something here, too, to default to an OS-selected colour scheme?

Anyway, I think there's enough call for the language switcher (and I think it's either been implemented or is in the pipeline) so I doubt that my frustration here is going to lead to anything. I just thought I'd hijack @tmontes vaguely related issue to vent my feelings :)

[tmontes]

@tjguk, @aroberge,

Thanks for sharing your thoughts. While going a bit off-topic here (this is a very clear and specific issue, including a possible fix) I'll share my "explicit language selector UI" perspective:

In my understanding, after a few observations working with kids, it may be considered as an accessibility issue. It is not uncommon for kids to be using their parents / older siblings laptops that, sometimes, are set to a default "non-kid-native" language: I have seen Portuguese kids using laptops with English based interfaces. In those cases, the possibility of clicking a non-distracting but also non-hidden-away button to change UI language comes as a useful accessibility tool -- that's what I envisioned in my note here.

A not so clear additional benefit could be the ease with which developers could try out different UI languages to check things are working nicely -- might be useful in the context of #887, for example.

PS: Over with off-topic thoughts. Suggest continuing this particular sub-discussion in the related outstanding issues #518 and/or #692. :-)

[aroberge]

After seeing a tweet about the new language selection, I just had to try it and was going to suggest to close this issue. However, I found a small bug where switching from the default language used by the OS (French for me) to English does affect the message shown briefly at the start in the status bar.

That being said, +1000 for this addition to Mu.

[carlosperate]

Hi @aroberge, thanks for the report!

To keep things tidy could you open a new issue? Then we can close this one as implemented (even if there are open issues), and look into this as a current bug.

[tmontes]

Quick note/thoughts:

• The addition of a language selection UI thingie helps address many people's desires.
• @aroberge notes that there might be issues with that implementation.
• This issue, however, describes a different thing WRT the automatic selection of UI language on the Windows platform:

On the Windows platform, when the user language preference is different from the system default language preference, Mu assumes the system default one, instead of the user's.

• I do agree that with the recent changes it does have less impact. :)