Language selection is too restrictive

[Felix Krull]

When running on a (Linux) system with the locale set to de_AT (German (Austria) which e.g. Fedora happily allows), the user interface is English. That was arguably to be expected since the translation is de_DE, but it really should use the sole German translation we have rather than falling back to English. This isn't isolated, it also happens with French (Canada).

In general, for any languages where we only have one translation anyway, we should just chop off the country code so that it can also be loaded for locales with a different country code (probably using the other QTranslator::load overload in the process).

[Helder Correia]

Interesting, I never expected <lang>_<country> to fallback to <default lang> at all when the exact combination doesn't exist. I've always though it would fallback to <lang> if it existed.

[Tey']

@heldercorreia it does already fallback to <lang> if it exists, the problem is it does not exist in our files (e.g., there's no file de.qm, only de_DE.qm), so in the end, it fallback to no translation at all (I guess load() returns false).

We just need to copy the *.pm file we believe should be the default for its language as the country-less filename (e.g., de_DE.pm should be copied as de.pm). If we can create links between Qt resources, it's even better.

In general, for any languages where we only have one translation anyway, we should just chop off the country code so that it can also be loaded for locales with a different country code (probably using the other QTranslator::load overload in the process).

Sure, but note the current QTranslator::load function we use already tries to use the country-less language file if it exists, so I don't really see the point in using the other load() method (which doesn't allow us to specify a language manually).

[Pol Welter]

The Qt resource files (.QRC) allow the use of an alias name, AFAIK.

[Tey']

The Qt resource files (.QRC) allow the use of an alias name, AFAIK.

Great, adding aliases (something like <file alias="locale/de.qm">locale/de_DE.qm</file>) fixes that issue for me.

There is a similar issue in ManualServer::deployDocs(), but QCH/QHC resources already have one alias defined, and we can't define more than one :(

[Pol Welter]

I guess its not a problem to navigate around that issue. IIRC Felix made this alias thing to avoid having that extra level of hierarchy in the resource file (:/manual/en_US/manual-en_US.qch). If there is no reason other than aesthetics of the path for having that alias, I'd say we can ditch it.

[Tey']

Okay. Unfortunately, the alias trick won't work with manual files anyway, because it implies renaming the files (:/manual/en_US/manual-en_US.qch => :/manual/en/manual-en.qch) and the QCH file name is hard-coded into the associated QHC file, so it won't find it if it's renamed.

We can probably use a generic lookup algorithm (e.g., if there's no file for lang_COUNTRY, try lang_LANG) and a lookup table for specific cases (en_EN is invalid, so we need to use en_GB instead).

[Tey']

Translate the UI even if the country is not supported (fixes #626).

→ <<cset 8475be3f239b>>

Edit: looks like bitbucket automatically resolves an issue if it's referenced in a commit log.

[Felix Krull]

What prompted me to check for this, actually, was that I was setting up proper translations for the Linux .desktop file and the appdata stuff, which is yet another distinct place that deals with translations. My point is, why fix the problem locally in the application with aliases or whatever if we can just fix it at the source, by renaming the translations -- so, also in Transifex, I think. If "de_DE" should serve as the fallback for all "de_*" locales (and it should), then why don't we just call it "de"?

Sure, but note the current QTranslator::load function we use already tries to use the country-less language file if it exists

Oh, I see; from the signature, I didn't expect it to mangle the file name.

(which doesn't allow us to specify a language manually).

It does by passing a QLocale. TBH, I'd sleep better if that piece of code made less use of explicit locale mangling and just relied on QLocale much more. There's so much awkwardness with locales, it seems safer to let Qt handle it.

[Tey']

It does by passing a QLocale. TBH, I'd sleep better if that piece of code made less use of explicit locale mangling and just relied on QLocale much more. There's so much awkwardness with locales, it seems safer to let Qt handle it.

Ah sorry, I misunderstood how QLocale::uiLanguages() actually worked. I agree playing with locales by ourselves is prone to error. I'll change the PR to make use of QLocale when possible.

[Helder Correia]

Merged in issue626_alt (pull request #64)

Translate the UI even if the country is not supported (fixes #626) [alternative]

→ <<cset 88aa8a7180a7>>

[Helder Correia]

See pull request #64.