Hydrogen: macOS locale detection broken

[digitalraven]

Hydrogen version * : 1.0.0
Operating system + version : MacOS 10.15.6
Audio driver + version : n/a

---

Hydrogen does not follow the macOS preferred system locale when more than one locale is defined.

On startup, Hydrogen goes through the list of available languages defined in the Language and Region control panel, and uses the first one it finds an i18n file for in the Hydrogen package. Since macOS reports UK English (correctly) as en_GB, Hydrogen ignores it — the i18n file looks like it's expecting a locale approximating en_UK, but that does not exist, per the language codes defined in ISO 693-1.

As an additional wrinkle on this bug, If Portuguese (Brazilian) is anywhere in the macOS list of available languages, Hydrogen uses it. It does not matter where Portuguese is in the list or what else is in the language list.

With UK English set as the preferred language in macOS, the only way to get Hydrogen to display an English UI is to remove _all_ other preferred languages from the macOS Language and Region control panel.

Hydrogen package contents:

Language settings: French preferred, Brazilian Portuguese included:

Hydrogen UI with those language settings:

Language settings (UK English preferred, with non-Portuguese alternates):

Hydrogen UI with those settings

---

• H2 version : see 'Info - About', or in case you build Hydrogen from source use 'git rev-parse HEAD'
  ** if you are reporting a bug, please describe how the bug can be reproduced

[digitalraven]

Following up on myself, I think this is two separate bugs:

1. UK English localisation detection is broken in some way.

2. Portuguese (Brazilian) is always selected if it is in the list of available languages.

[elpescado]

Actually I did notice this on my work Mac. Hydrogen loaded Polish locale even though that Mac is set to English. I just assumed it was somehow reading my mind;)

[cme]

Ugh. So, after some digging, and reproducing:

It seems this is a consequence of the order that QTranslator::load() looks for translations in.

In an attempt to replicate this, I added a couple of extra languages to my Mac, and noted that it always reports the preferred UI language with both a language and a region. The region defaults to the system region if it's not specified. So adding French as a language, Spanish, Spanish Latinoamérica and Portugês (Brasil), I get UI languages:

("en-GB", "fr-GB", "es-GB", "es-419", "pt-BR")

The Qt docs' description of the search order is ropey, but the example list makes it clear that the search order is (more or less):

1. Exact match any UI language
2. Any UI language with a '-' stripped off.
3. ...any UI language with another '-' stripped off.

So, in effect it prefers the exact match of "pt-BR" over the looser matches that appear earlier in the list.

This seems pretty wrong to me, and it's not clear what, if anything, Hydrogen should do about it. I'll have a look to see if this issue is noted against Qt anywhere.

A corresponding issue is that we don't actually have a hydrogen_en translation of any sort, so on a system with multiple UI languages, one of which is not English, Hydrogen will get the non-English one no mater whether it's first or not. This is probably what @elpescado is running into. We should fix that.

(On a system with only English UI languages, no translation will be found and the untranslated UI, which happens to be in English, will be used)

[elpescado]

What if we add empty hydrogen_en "translation"? Hydrogen will pick that up, and since it defines no translations, it will display untranslated (in other words, English) UI.

[digitalraven]

I think an empty hydrogen_en would be a starting point that'd help with cases where people don't have pt-BR or hu-HU (the only i18n files [currently] that specify regions).

I'm trying to think of a way around that sort order and not coming up with anything.

[cme]

I think an empty hydrogen_en would be a starting point that'd help with cases where people don't have pt-BR or hu-HU (the only i18n files [currently] that specify regions).

I'm trying to think of a way around that sort order and not coming up with anything.

Options include

1. Fix Qt
2. Generate / symlink translation filenames with the obvious default regions as well as languages in the suffix
3. Explicitly find the right translation ourselves rather than rely on Qt's search path.

3 isn't actually much hassle to do so I may do that as well as adding the empty *_en.ts (and probably also an _en_GB.ts to fix some spellings) but I have a nagging doubt that it may not be so obvious as it seems what the right thing to do is.

[elpescado]

By the way, could this affect other OSes? I.e. do Linux/Windows allow setting multiple languages?

[elpescado]

Related?
https://github.com/keepassxreboot/keepassxc/issues/1924
https://github.com/keepassxreboot/keepassxc/issues/3030

Funny thing, they provide en, and en_US translations that are idempotent (they actually define translations for every string, eg. "About" -> "About", "Contributors" -> "Contributors"); and three variations of Portuguese (pt, pt_BR and pt_PT).

[cme]

Related?
keepassxreboot/keepassxc#1924
keepassxreboot/keepassxc#3030

Funny thing, they provide en, and en_US translations that are idempotent (they actually define translations for every string, eg. "About" -> "About", "Contributors" -> "Contributors"); and three variations of Portuguese (pt, pt_BR and pt_PT).

Hahaha, from their source code:

        // NOTE: this is a workaround for the terrible way Qt loads languages
        // using the QLocale::uiLanguages() approach. Instead, we search each
        // language and all country variants in order before moving to the next.

Yup, exactly.

[cme]

Filed this

[elpescado]

After reading QTranslator::load docs like five times in a row it seems that it is indeed desired (if you asked me, wrong) behaviour:

For example, an application running in the locale with the following ui languages - "es", "fr-CA", "de" might call load(QLocale(), "foo", ".", "/opt/foolib", ".qm"). load() would replace '-' (dash) with '_' (underscore) in the ui language and then try to open the first existing readable file from this list:

1. /opt/foolib/foo.es.qm
2. /opt/foolib/foo.es
3. /opt/foolib/foo.fr_CA.qm
4. /opt/foolib/foo.fr_CA
5. /opt/foolib/foo.de.qm
6. /opt/foolib/foo.de
7. /opt/foolib/foo.fr.qm
8. /opt/foolib/foo.fr
9. /opt/foolib/foo.qm
10. /opt/foolib/foo.
11. /opt/foolib/foo

As you can see, "de" is tried before "fr", although "fr-CA" is before "de" in ui languages list.

[cme]

Yes, the implementation and documentation do at least match. I think I'm increasingly convinced that any simple priority ordering of selection of a non-ideal language and country can't adequately represent all the reasons users may have given language and regions set up, and language capabilities; and that having a selection menu somewhere to let the user pick their preferred language is necessary.

[digitalraven]

Agreed. I think the way you have it in 48d3825 is the “correct” order for anything not strongly region-dependant. At the same time, far in the future, it may be an idea to instead show a language picker on first launch if no matches are found for the primary language, with any secondary languages given prominence over the rest of the translations as there’s no guarantee that the ordering of them is significant — I may have French and German selected (in that order) as I’m learning those languages, but I’m much better able to read German despite coming to it later, sort of thing.

[cme]

Closed, fix (including menu for user language selection) is merged to master.

[readeral]

Having just installed the latest 1.0.1 linked from Source Forge, I just came across this bug. I use a Greek keyboard for typing in Ancient Greek, but Hydrogen started up in Greek.