Please combine all the translations for each locale's modules into a single qt_??.qm file

https://doc.qt.io/qt-6/localization.html#deploy-translations mentions the following:

In addition to the application's QM files, you need to deploy the QM files for the Qt modules that you use in the application, unless they are installed on the system.

The QM files are split up by module and there is a so-called meta catalog file which includes the QM files of all modules. However, you only need to deploy the QM files for the modules that you use in the application.

You can use the lconvert tool in the deploy step to concatenate the required QM files into one file that matches the meta catalog file. For example, to create a German translation file for an application that uses the Qt Core, Qt GUI, and Qt Quick modules, run:

lconvert -o installation_folder/qt_de.qm qtbase_de.qm qtdeclarative_de.qm

I'm in the process of migrating my project from linuxdeployqt to linuxdeploy with the linuxdeploy-plugin-qt plugin and have just spotted that the latter is including (in my particular case) qtbase_xx.qm and qtmultimedia_xx.qm for each locale whereas the former does produce the combined qt_xx.qm that the above suggests. I would point you to the shared.cpp file in that project but since it is GPL licenced whereas this one is MIT I don't want to lead anyone to precisely copy what is there as it can't be used here. I'm guessing that (inline bool) deployTranslations(appdir::AppDir&, const fs::path&, const std::vector<QtModule>&) is the place to fix this...

Why would linuxdeploy have to do this, though? Wouldn't it be just as easy to run it manually if needed? I don't see the advantage (yet).

If they are not merged together then in an application it has to find and load the Qt translations for each module individually - whereas if they are combined it only has to instantiate one QTranslator instance to hold all the Qt modules' translations. In my application I'd have to rewrite https://github.com/Mudlet/Mudlet/blob/development/src/mudlet.cpp#L1376 to find each module's corresponding locale translation and then load them all making for more complexity.

I've worked around things temporarily by running linuxdeploy twice - the first time with this plug in - to assembly all the translation files, then used a bit of bashery to combine them in the manner that Qt themselves suggest (with lconvert) and then delete the individual files leaving behind the combined ones before running linuxdeploy again (without this plugin) to merge the changes back into the AppDir. Running linuxdeploy is not a particularly fast process - even in the GitHub CI/CB process (it takes a couple of minutes on my Desktop) so having to run it twice is not nice...

Ah, some timing details from the most recent run I've done like this: https://github.com/Mudlet/Mudlet/actions/runs/14411660189/job/40420749088?pr=7806

The first run with this qt and the gstreamer plugins:
Fri, 11 Apr 2025 20:53:25 GMT to Fri, 11 Apr 2025 20:54:19 GMT = 55 seconds
The second run without either plugin just to update the translation files in the AppImage after combining them:
Fri, 11 Apr 2025 20:54:19 GMT to Fri, 11 Apr 2025 20:54:56 GMT = 35 seconds

I also vote for this.

Note that windeployqt, the Qt deployment tool for Windows only includes qt_??.qm files, no qtbase, qtmultimedia or anything else.

My Qt program is written to read qt Qt translation files compatible with windows deployment. This also works with packaged installation, because distros¹ package qt qm files alongside the more specific ones.

The only outlier in my deployment process is linuxdeploy-plugin-qt now. Like SlySven, I am unwilling to rewrite my code just for this outlier, so I'll have to hack this together myself somehow.

I checked only a few distros, I do not know whether this is common for most. ↩

I'm willing to contribute a fix, but I need to discuss with maintainers how to do this in a sensible and backwards compatible way.

I think the most sensible option is to deploy both library specific and qt qm files for backwards compatibility, add a flag to let the user choose betwen one or the other (or both).

I'd also add a flag that would let the user pick languages which are bundled. Current behavior seems to be to bundle everything there is to bundle. For example the aforementioned windeployqt has a --translations flag which can limit the bundled translations.

I'd like to deprecate library specific translation files as default (but perhaps keep it if overriden by the flag proposed above). I don't know how linuxdeploy-plugin-qt would handle such deprecations.

Thanks for the additional research. I am still not 100% sure when to perform such a step, but I am not opposed to it at all. It looks like since translations are scattered across, we'd have to register all .qm files and run lconvert as a post-processing step or so in the plugin. Is that assumption right?

The aggregated qt qm files are usually¹ available alongside the library specific ones. No need to lconvert if it's already there.

I guess making linuxdeploy-plugin-qt capable of lconverting its own qt file could prove useful in some scenarios, but the qt qm file should just be copied over if it's there.

UPDATE: It appears to be more complicated than that. The fact that a /usr/share/qt6/translations/qt_??.qm file exists doesn't have to mean that it has any usable content. On ubuntu:22.04, the qt6-translations-l10n package does provide qt files, but they don't contain anything useful. Here's for example qt_cs.qm:

00000000  3c b8 64 18 ca ef 9c 95  cd 21 1c bf 60 a1 bd dd  |<.d......!..`...|
00000010  a7 00 00 00 02 63 73 96  00 00 00 38 00 00 00 12  |.....cs....8....|
00000020  00 71 00 74 00 62 00 61  00 73 00 65 00 5f 00 63  |.q.t.b.a.s.e._.c|
00000030  00 73 00 00 00 1e 00 71  00 74 00 6d 00 75 00 6c  |.s.....q.t.m.u.l|
00000040  00 74 00 69 00 6d 00 65  00 64 00 69 00 61 00 5f  |.t.i.m.e.d.i.a._|
00000050  00 63 00 73 88 00 00 00  06 01 01 ff 04 02 04     |.c.s...........|
0000005f

Here are all translations: qt6-translations-l10n-6.2.4-1.tar.gz

Perhaps qm files can transparently link to other qm files? That would explain such small qm files. The paste above perhaps links to qtbase and qtmultimedia. I don't know.

Ubuntu 22.04 is a bit old, it is possible that Qt changed how qt is bundled in newer versions. But with this discovery in mind, I believe that using lconvert is the best solution.

Again, I am speaking about the few distros I tested this on. ↩

So the idea is: detect app .qm files and combine them to qt_*.qm with lconvert into a known position, retaining the original ones?

I've updated my previous comment, please read that.

I haven't talked about app .qm files yet. Their handling is simpler. There are two ways to bundle translations: to bundle them into the executable with qrc or to provide separate .qm files.

Bundled translations do not require special attention from linuxdeploy-plugin-qt.

If the build system is instructed to install things into the AppDir as described in https://docs.appimage.org/packaging-guide/from-source/native-binaries.html#using-the-build-system-to-build-the-basic-appdir, it should install qm translations into a sensible direcory.

With that in mind, app translations shouldn't require special attention from linuxdeploy-plugin-qt.

I'd certainly add a section on translations into the project's README alongside my implementation PR.

Qt's translation loading mechanism is quite manual, the file names and directory locations are hardcoded to a certain extent. Renaming the translations or merging them with lconvert would most likely break things.

Kind of confused now. A draft PR would be very welcome to showcase the concept.

TBH I had abandoned migrating my project from linuxdeployqt to linuxdeploy as eventually probonod updated things in the former so it would work with the (then later libc I think) in the GH Actions ubuntu 22.04 runner - this was during/shortly after the depreciation/removal of the older ubuntu 20.04 runner.

However the same situation is going to occur again by April 2027 as now the 22.04 runner is on death-row - so I may have to look again.

Navigation Menu

Repository navigation

Please combine all the translations for each locale's modules into a single qt_??.qm file #194

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Please combine all the translations for each locale's modules into a single qt_??.qm file #194

Description

Activity

TheAssassin commented on Apr 11, 2025

SlySven commented on Apr 11, 2025

meator commented on Aug 18, 2026

Footnotes

meator commented on Aug 18, 2026

TheAssassin commented on Aug 18, 2026

meator commented on Aug 18, 2026

Footnotes

TheAssassin commented on Aug 18, 2026

meator commented on Aug 18, 2026

TheAssassin commented on Aug 18, 2026

SlySven commented on Aug 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions