[lxqt-config-locale] list issues

[Vladimir-csp]

Hi!
Two suggestions about the list of locales:

• Put those locales which are actually built on the system at the top of the list. All other - after a separator, or under some 'other' section, or in /dev/null. Why would a hundred of non-existing locales be listed anyway?
• Sort by locale name, then by comment (Also put name first). The list is a mess right now.

[Vladimir-csp]

It also seems to ignore en_DK locale, I can not find it in the list for time format. And when I set it by editing .config/lxqt/LXQt-config-locale.conf, GUI says "No change".

[Vladimir-csp]

Why the main list is called 'Region'? It lists locales, not regions, so it should be called 'Locale'.

[pmattern]

Both selection and order of topics provided by the list should get improved, indeed. Otherwise it's very likely that problems as posted in #894 will come up on a regular basis.

The best selection isn't that obvious, though.
lxqt-config-locale is setting environment variables which aren't sourced by LXQt only but other applications as well. So it can very well be reasonable to set a locale that's not supported by LXQt (yet) but by other applications that are to be run in an LXQt session.
Xfce can only make use of locales available in terms of locale -a. I've never seen this behaviour with any other software. But if other applications should behave similarly this kind of locale would have to be taken into account, too.
It's not obvious which locales should be considered as supported by LXQt as the translated locales aren't the same in all LXQt components.
Maybe just leave the selection as is and add some comment explaining the situation?

@Vladimir-csp
Just to get it right, what you're writing about locale en_DK here is different from your findings in #890, isn't it?
Also, I'd suggest to add your thoughts about terms "Region" vs. "Locale" to #872 which is already covering some similar topics.

[Vladimir-csp]

lxqt-config-locale does not see en_DK.

I'm not sure what do you mean by locales that are (not) supported by LXQt and why it matters to the list in lxqt-config-locale. If there is no translation available, an app should show strings from C locale. Is that right? This has nothing to do with which locales to list in config dialog. And there is no reason for excluding a locale from the list if LXQt does not have strings in that locale, other applications might have.

Locales from locale -a should at least have a priority in listing, because they are present on the system. Other locales might not even be listed, because selecting them would basically result in having C locale.

[Vladimir-csp]

If I launch

export LANG=en_DK.UTF-8
export LC_ALL=en_DK.UTF-8
lxqt-config-locale

It shows 'No change' in all fields. I assume, LXQt has some internal way of generating the list. But it should dynamically rely on system-wide situation, via locale -a for example.

[pmattern]

I'm not sure what do you mean by locales that are (not) supported by LXQt

By "not supported (yet)" I simply meant a translation isn't available in LXQt yet.

and why it matters to the list in lxqt-config-locale

For the reason you state as well:

there is no reason for excluding a locale from the list if LXQt does not have strings in that locale, other applications might have.

Just found this word mentioning in my previous post as it's one of the things that have to be considered if it comes to selecting the locales that should be part of the list.

[Vladimir-csp]

The reason I state and you've quoted is actually about why it shouldn't matter. ) If locale is shown by locale -a, it should be in the list, regardless of LXQt translation for that locale.