Problems with the translations of desktop launchers

amartinromero · February 27, 2023, 1:58pm

Good morning, we have detected that lubuntu 22.04 has a problem with the translations of the Names, Comments, and other parameters of the desktop type files (*.desktop) that make use of the X-Ubuntu-Gettext-Domain directive for their translations .

Examples of this are /usr/share/applications/system-config-printer.desktop or /usr/share/applications/nm-connection-editor.desktop, which do not use Name[lang] or Comment[lang] for their translations to other languages, but from X-Ubuntu-Gettext-Domain.

This makes the environment a bit chaotic, since certain applications appear in the application menus correctly translated and others do not. In my case, it is Spanish, but surely the same thing happens with any other language that is not English.

In Lubuntu 18.04 this problem did not occur. Please, could you tell me how to solve the above problem and ensure that all applications appear translated in the menus? Thank you very much in advance.

Fritz · February 28, 2023, 7:56am

You should realise that you are using a software system - free of charge - that exists thanks to the dedication of hundreds, thousands of enthousiasts. Not only from the work done by people who form the Lubuntu-team.

Architects, designers, software developers, packagers, testers, technical writers and translators, to name few groups of people, are involved in a continuous process of making each and every component better.

An operating system is like a layered cake. There are many layers of software involved, and hence many different groups of people or organisations do their thing. Hopefully what they like best and are good at. Depending on the area (the kernel, a specific OS, a specific application) some, or even perhaps many of those people get paid, others certainly don’t.

Software evolves. Every major or minor update of any software part in the whole chain may require new translations, or adaptations to existing translations.

A lot of work involved. It seems that in your case, the translations you miss have not been provided in the respective language-pack (in the case of the respective *.desktop files you’ve mentioned the translation provided by the “X-Ubuntu-Gettext-Domain”-mechanism).

You can read more about that here: UbuntuDevelopment/Internationalisation/InternationalizationPrimer/Gettext - Ubuntu Wiki

I’ve been testing it in the Spanish language on Lubuntu 22.10 with the Castillian language packs installed. Same situation here on 22.10: the translations do not show. They just may not been provided (which is unlikely since there will be many Spanish language users of Ubuntu/Lubuntu around the globe), or something else is wrong.

Since the layered-cake-ish-nes of software and responsibilities, it is maybe not the primary task of the Lubuntu team (which I am not a member of) to assure that all and every bit of needed translation is provided. “We do our best”.

First we need to find out where the error lies. Seems you’ve have done your research already, and maybe know how to use a terminal. If you’re interested, try the following:

      # check if your required language-packs are indeed installed:
      $ apt search language-pack | grep "\-es"

      WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

      language-pack-es/kinetic,kinetic,now 1:22.10+20221013 all [installed]
      language-pack-es-base/kinetic,kinetic,now 1:22.10+20221013 all [installed,automatic]
      language-pack-gnome-es/kinetic,kinetic,now 1:22.10+20221013 all [installed
      language-pack-gnome-es-base/kinetic,kinetic,now 1:22.10+20221013 all [installed,automatic]
      language-pack-kde-es/kinetic,kinetic,now 1:19.10.0ubuntu1 all [installed]apt search language-packs | grep "\-es" 

      # get a translation (available, and shown on your desktop)
      $ LANGUAGE=es_ES gettext -d software-properties "Additional Drivers"
      Más controladores
      
      # get a translation (also available, BUT NOT shown on your desktop)
      $ LANGUAGE=es_ES gettext -d system-config-printer "Printer"
      Impresora

The gettext application queries the various language packs for the desired translation. You can skip the “LANGUAGE=es_ES” part, since your desktop is already using Castillian. I am using American English on my desktop, and need this “trick”. This trick works only, after installing the given language packs, which I did, of course.

The -d-part is not hocus-pocus, but tells the gettext-application which ‘domain’ to use. It is the value of the ‘X-Ubuntu-Gettext-Domain’ qualifier, as specified in the related *.desktop file.

As far as I know the correct, and correct number of “language-packs” have been installed (at least on my system).

My conclusion is that the translation (in this particular case) is properly provided, but not used by the part of LXQt that should handle it.

To be continued.

Fritz · February 28, 2023, 11:37am

I’ve been digging a bit further. Seems that current SparkyLinux (running LXQt 0.16.0) is somewhat hybrid in this. Same problem, that is, some desktop-entries that I’ve inspected have a proper Spanish translation. Their *.desktop file is bloated with traditional method translation, e.g.

GenericName[es]=Configuración de impresión
Comment[es]=Configurar impresoras
etc…

…in dozens of languages. But, it also contains the following

X-Ubuntu-Gettext-Domain=system-config-printer

I guess it is a transitional version of the respective *.desktop file, not quite working as it should (the new way, using Gettext) on LXQt 0.16.

I did not check it, but I guess the situation on Sparky is exact the same as on Lubuntu 18.04.

Next, I’ve spun up a fresh Lubuntu 22.04.2 VM, and saw the same as on Lubuntu 22.10 earlier (missing translations). No surprise (the old-style translations are not present in the desktop files).
Another VM, the next version of Lubuntu, Lunar, 23-04 has the same behaviour: no translations on the desktop items - just like in your case.
I’ve downloaded and compiled the latest LXQt sources on a fresh Lubuntu 22.04.2 VM. In particular I am interested in the lxqt-panel component (the part you interact the most with, the horizontal panel at the base of your screen). I can’t do any harm on this machine, and am free to experiment a bit. Most likely to put some debugging in place, and see what’s going on exactly.

To be continued (later).

Roberalz · February 28, 2023, 4:01pm

this maybe can help you.

Fritz · February 28, 2023, 4:58pm

I’ve been busy today. I’ve found the root cause of the phenomenon reported by amartinromero.

The short explanation
Any some-application-quicklaunch.desktop file that relies (in Lubuntu) on gettext and the X-Ubuntu-Gettext-Domain-moving of translations from the respective desktop file to a precompiled language-pack-file will loose their translations. No matter what language, it disappears. Simply because it is not implemented in LXQt (not in 1.2.0, and not in earlier versions).

At least, that is my conclusion at this moment. I just don’t see it in the codebase of LXQt. I can’t explain why or how the X-Ubuntu-Gettext-Domain appeared at any given time in history in some *.desktop files. Most likely that the Ubuntu desktop is using X-Ubuntu-Gettext-Domain (and invented there as well). Maintainers are slowly removing the traditional style translations from their *.desktop files when it suits them. Since Lubuntu heavily relies on Ubuntu the removals appear in Lubuntu. Unnoticed by many.

The longer explanation

TODO (later)

Conclusion
I am very glad that amartinromero reported this flaw. I’ve noticed the same on Lubuntu with a less commonly spoken European language. I always thought…well, it is a community thing…maybe it is not translated yet…etc, etc.

Now I know better. Many software packages do provide correct translations through gettext. I’ve demonstrated this in my first installment with the text “Additional Drivers”, which gettext translates correctly in the Spanish language. I fear that Ubuntu maintainers will continue removing old-skool translations from their *desktop files. Simply because they can. It is of nu use for Ubuntu.

I’ve checked the situation on the next stable Debian version (Debian 12), which can be configured to use LXQt (version 1.2.0). Surprise, surprise, the traditional style translations (which have been vanished on Lubuntu in some desktop files) are still present. Ofcourse.

There are two solutions:

Lubuntu overrules the Ubuntu *.desktop files (if available). Lots of work, error prone.
Or, someone has to implement the handling of the “X-Ubuntu-Gettext-Domain”-tag in LXQt. My evaluation is that will be a relative small change in LXQt.

To be specific about the change in LXQt: file lxqt/libqtxdg/src/qtxdg/xdgmenuapplinkprocessor.cpp would be a good starting point.

Take a closer look at function XdgMenuApplinkProcessor::step2(): this is where the desktop files are being processed and where the traditional style translations are picked up.

Someone has got to do it. The change has to be peer reviewed and tested. I don’t think it will have high priority for the LXQt-project, since only one distribution (or maybe a few Lubuntu clones as well) have this problem.

Anyhow, this problem should be picked up by the Lubuntu team.

I am done with my analysis (for now). It is clear to me. I’ve learned a lot today

Fritz · February 28, 2023, 5:12pm

Thanks. Seems point 1) of my story below your entry is already covered

Fritz · March 1, 2023, 6:35am

After a good night sleep, I can iterate on this thread a bit more:

my texts are long and verbose (as always, due to my prosaic style of writing)
all is a reflection of my personal forensic tour, or labour, or endeavour if you like.
maybe this blog is not the best suited place for my eructations. I have a tendency to dig too deep, too early. Not everybody may like my style of working. People zoom out quickly, as I understand it
my texts should be read linear: all I’ve written was true to me, at the time of writing. Proceeding knowledge on my part make some things perhaps less correct, or even a bit asumptious (not sure that word exists). I’ve made some corrections before I posted, but not all was ameliorated
considering this, I had a good time doing some research. I have hopes this logging this will be beneficiary for someone in the future (perhaps even for ‘moi’, who knows)
I’ve learned a lot about LXQt. How to compile it, how to debug it. How to play with it essentially
perhaps amartinromero’s question will shake things up a bit. The problem was already known by at least one Lubuntu member (Roberalz), but without a proper follow-up as one would expect. Rather ad hoc, manually, and not published.
as I see it now (after reading Dan Simmons response to Roberalz post - Pending translations) the impact is pretty small. Not much is missing, and fixes could be easily provided at large. Someone has got to do it, as usually.

Perhaps in release 23.10 a permanent solution will be available for everyone. Lubuntu (and LXQt) deserve it.

tsimonq2 · March 3, 2023, 12:19am

Wrong. I’m finding quite a bit of your messages helpful, what is more confusing is the LXQt code

Since you were able to correctly track down which component and what lines of code this was at, I wonder if you have a code solution? Worth a shot…

Well, if a fix is presented prior to then, I’d be all for including it in 23.04. Just need some work done.

tsimonq2 · March 3, 2023, 1:59am

Try this potential fix in an hour or so, once it’s fully published.

EDIT: Confirmed working, please double check.

Fritz · March 3, 2023, 6:08am

Would be great, right?

The problem is that at my first job I’ve “learned” three things (well, they were almost forcefully pushed down on me by my former employer, a software company):

assumptions, assumptions, assumptions…
do never goldplate
your customer pays your salary

…among many other things, like two-colour-painting, testing, etc.

Assumptions were my dangerous bend in this case. I assumed that a paradigma shift was and is slowly happening. That more and more applications are generally offering meta-translatations. Meta in the sense that such translations are not part of the application-proper, but provided as being handy in the ecosystem were an application lives in (the desktop). And that Ubuntu’s desktop more or less invented and implemented this consuming were the Lubuntu-desktop doesn’t.

That would explain that some desktop translations lost their desktop-translations somewhere between Lubuntu 18 and 20, since our upstream Ubuntu packaging partners freely may, can and will remove bulky translations from their desktop-files. Lubuntu almost inherits the various desktop-files unnoticed (mind you, I am talking about the timeframe 2018 - 2022). A slow process. (I am still not sure all my assumptions here are valid.)

Secondly goldplating: if there is a cheap and rather easy solution for a problem, or if the problem does not really exist (“Roberalz”, https://launchpad.net/~tsimonq2/+archive/ubuntu/translations ), do not try to reinvent the wheel. Would there be a real benefit (audience) for fixing the problem the correct way (elegantly, avoiding repeating efforts each distro release, etc…)?

I’ve pinpointed where changes could be made in LXQt. My evaluation and estimate is - I carefully avoid saying ‘assumption’ - that it is very doable. It should not take too much time (coding, programmer ftesting, upload a branch to LXQt). However, I have been following the activities at LXQt a bit the last months. Seems there is not much activity going on there. It is probably an understaffed project (like Lubuntu), and perhaps their lead members have learned some facts about assumptions, goldplating and paychecks too

Considering the millions and millions users the LXQt project has, it is wise to be prudent, conservative and slow. My impression is that it will be difficult to get my change promoted to their product in a timely fashion. This is not an assumption. I’ve checked the activity on their Gits. Other subject, I wonder what the next big thing will be in release LXQt 1.3.0, if any.

Paying customers. This is a metaphore for OSS in general. Unfortunately, there are no paying customers. I happen to have enough time to spare, and enough experience with programming in general to maybe fix this rather quickly. It would be my first real thing on Qt and LXQt programming, but doable.

If I would. But should I? If the missing translations can be somehow restored quickly, why should I bother. I’ve taken up another Qt / LXQt endeavour already (an application in the style of other LXQt configuration applications which could replace bluedevil). See Why is "KDE System Settings" in 22.10 and Lunar? - #7 by Fritz). Same goes there, why should I endeavour a task to create a new and better application if solutions already exist if my personal gain, beside pride and learing a lot, is minimal. Personally I use Bluetooth seldom, and configuring things with bluetoothctl is good enough for me. For the record, my effort with that so far is that I am able to scan for bluetooth devices already. Its a start. So many other interesting things to do and read.

To round up things here. I am not part of the LXQt community, and miss the personal screwdriver or crowbar that is needed to get things going over there, after I’d “improved” their code for the small benefit of the Lubuntu project.