Please, keep multi-language support in LXQt like in LXDE

Hi, everyone.

I have always been a locale-fallback feature user. With Lubuntu 18.04 LTS I haven’t any problem:

I can’t put a link here due the st*pid limits.

The computer users are fluent in those languages, except in English (the default one). If there’s a string untraslated in one language, it jumps and try to show the string of the next listed language and so on.

In most of the programs the fallback works, but the LXQt menu, some details like some dialogs, don’t work well, even editing /etc/default/locale file:

LANG="pt_BR.UTF-8"
LANGUAGE="pt_BR:pt_PT:gl_ES:es_ES:en"
LC_NUMERIC="pt_PT.UTF-8"
LC_TIME="pt_PT.UTF-8"
LC_MONETARY="pt_PT.UTF-8"
LC_PAPER="pt_PT.UTF-8"
LC_NAME="pt_PT.UTF-8"
LC_ADDRESS="pt_PT.UTF-8"
LC_TELEPHONE="pt_PT.UTF-8"
LC_MEASUREMENT="pt_PT.UTF-8"
LC_IDENTIFICATION="pt_PT.UTF-8"

It doesn’t work even installing and configuring locales with language-selector-gnome, which is not installed by default on Lubuntu 20.04.

If I try to change the main language, I see that most of translations exist, either in one language or another. So the problem is with the fallback, determined by the LANGUAGE = section in /etc/default/locale.

Using Spanish as first language:
Spanish as first language
Using Galician as first language:
Galician as first language

We are not the only ones with this problem, polyglot people or inhabitants of regions with languages with two different spelling regulations can be combined in this way.

Perhaps the LXQt desktop environment has the language configuration files in another location. It needs to be reviewed.

Thank you for your attention.

2 Likes

I opened a bug in Launchpad, but it has been closed, making mention, for reference, of this entry in this forum.

Gunnar Hjalmarsson (gunnarhj) wrote:
Thanks for your report!

The fallback language feature, represented by the LANGUAGE environment variable, is a gettext thing, and should work in all applications which use gettext to pick the translations.

Non-GNU applications, for instance Firefox, Thunderbird and LibreOffice, don’t use gettext, so the LANGUAGE variable is ignored. As regards LXQt, I don’t really know what the problem may be. Possibly the desktop includes its own ways to set the display language, in a similar way that KDE does.

In any case it’s not a bug in language-selector, so closing this bug.

I would recommend you to bring up the issue in some Lubuntu and/or LXQt forum.

More information here:

https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1869592

We can reopen that bug against the right LXQt component but I’m not sure which it is. @hmollercl @Noumeno etc. do you have any ideas?

yesterday I wrote a message to the user to give me more details, but I have no answer yet @wxl

^^ waiting on you @pcgaldo

I can lose my job due to the current situation in the world and the measures being taken in Spain. Now I can not address this issue. Sorry, you’re going to wait a little.

As I mentioned in the bug report, and which @pcgaldo included above too, the fallback language feature is provided by gettext. If I understand it correctly, translations are stored in .qm files for the LXQt stuff (see this file list as an example), and that would indicate that gettext is not involved at all for handling translations for LXQt components.

And if so, the relevant question is: Does Qt offer any equivalent to the gettext fallback language feature? Personally I haven’t heard of such thing; AFAIK only gettext provides the option to enable fallback languages. Hopefully I’m wrong. :wink:

1 Like

ok don’t worry, as long as you can we keep trying to fix it

Thank you,

I’m out of a job, but I’m back. I’ve already sent you an answer.