Localization: Use of country specific locales only involves some restrictions

[pmattern]

Using country specific translation files only is restricting the usage of translations.

A country specific translation like de_DE is only used when exactly the same locale is set at runtime. So if a translation like this is the only available one of a particular language the corresponding application will not make use of it and fall back to English on systems were a different country specific locale like de_CH is used. FWIW a more verbose explanation of the problem is available here.
Official documentation how to deal with this doesn't seem to exist. On LXQt we worked around the problem by using language specific locales like de as long as only a single translation of the language is available which behaves exactly as desired in all kinds of contexts.

I thought this would be the same with RSS Guard and created a branch l10n-drop-countries which doesn't work, though. It compiles flawlessly but a language specific locale like de doesn't get used with any of the country specific ones, no clue why.

[martinrotter]

Okay, I perfectly get it. This "problem" actually influences all platforms. It really makes sense to mark all localizations as more general and less specific, unless there are at least two localizations for one language, for example en_GB vs en_US.

[martinrotter]

I will check your branch.

[pmattern]

Confirming the issue is basically fixed.
It is fixed as of b5240a5 only, though. In 8dba235 the GUI always came up in English here, no matter which locale was set.
Also, it isn't possible to test whether country specific translations get applied as expected as simply no suitable one exists yet. (If I'm not mistaken the only difference between en and en_GB is some minor formatting which should be nasty to detect in the GUI.)

[martinrotter]

Wait. So if you delete RSS Guard settings. Change your DESKTOP language to let's say Czech. Then you start RSS Guard and it is not in Czech and starts in English instead?

[martinrotter]

Please, test with latest build, I added some more logging. Post logs here: rssguard > log.txt 2>&1.

[martinrotter]

For me, when I switch language of my distro to "cs_CZ" and then launch clean RSS Guard, it works. Language magic is made and "cs" localization is loaded (as exactly "cs_CZ" is not available).

[pmattern]

No, this was a misunderstanding.

The translations which are currently available all work exactly as expected. E. g. launch 1b4ea72 with LANG=de_{AT,CH,DE}.UTF-8 and the GUI comes up in German, similarly everything is fine with LANG=fr_{FR,CH}.UTF-8 or LANG=it_{IT,CH}.UTF-8.

All I wanted to say that it is not possible to test whether country specific translations are working all right as simply no usable one exists.
Look, the only that basically exists is en_GB. But currently it's exactly the same as en except some minor formatting which is probably hard to detect in a running instance and hence can't be used to check whether or not country specific translations work as expected.
In other words, it cannot be tested right now what happens on a system with say locale pt_BR when two translations pt_{BR,PT} exist.

IMO it is not even necessary to reopen this issue. If there sould be something wrong it will come to our attention once country specific translations exist.

[martinrotter]

In other words, it cannot be tested right now what happens on a system with say locale pt_BR when two translations pt_{BR,PT} exist.

Well, the method QTranslator::load(...) tries to load the most specific localization first. So if you want to load pt_BR and the exact specific localization pt_BR is available, it is loaded. It pt_BR is not found, another variant is tried.

See docs