Lrelease and dependency
-
Hi,
I try to use the translations for Qt5.2.1 with lrelease qt_de.ts. This file contains dependencies to other ts files which are apparently not resolved. lrelease runs without errors but because it does not invoke the dependencies the qm file is empty.
How can I get lrelease to work properly?Thanks!
-
You can invoke lrelease on the .pro file from your project.
-
I use cmake so this is not an option. On the other hand, how does lrelease know that I want to have the translations of Qt itself?
-
In that case, take a look at lconvert tool (located in qtbase/bin of your Qt installation). Quoting from it's help:
[quote]If multiple input files are specified, they are merged with
translations from later files taking precedence.[/quote]So you can use that to merge all your TS files into one and then use lrelease on the output.
As for translations of Qt itself: the QM files are in qtbase/translations. I doubt lrelease knows anything about those.
-
I know that the qm files are there but they have the same problem. The one for de is generated from the one which references the others and this does not work properly.
-
I see. Well, translations can be tricky :) I don't have the code at hand right now, so I can't check properly for a clean solution.
One possibility, although a bit ugly, is to deploy separate QM files (one for your app, one for Qt), and install them with QTranslations separately.
-
That is exactly what I do and I will not change that but the problem is the Qt translation itself.
Might this be a bug and worth to open one in the bugtracker? -
I am not sure how including translations of Qt is usually done, so no definite answer from me. You can ask on IRC or mailing lists, or indeed file a bug report.
-
I filed a bug report: https://bugreports.qt-project.org/browse/QTBUG-38179
-
Ok, thanks. I've added myself to the watchlist.
-
If you read this thread, be sure to look at the bug report. The response was (paraphrasing): its not a bug, at runtime QTranslator looks for the dependencies.
So evidently, you must do as the OP is doing and as sierdzio suggests above: deploy the QM's for all dependencies, and at runtime, install translations for the dependencies. If you don't like that solution, then you need to use lconvert.
I don't understand why for example, qt_es.ts is different from qt_de.ts. Who made the choice to combine (lconvert?) the depencies for es, and not for de?
Also, I could not find the QM files in the gitorious repository at qtbase/translations as sierdzio suggests. I suppose he means: thats where the files are in an installed Qt. I suppose the Qt project considers them ephemeral build products that don't need to be version controlled in the repository.
I would prefer that they were version controlled, since not every deployment of a Qt app relies on an installed Qt on the user's machine, and might not even have an installation of Qt with all needed QM's (for targeted languages) on the development machine. For example, when using PyQt and building the QM's into a resource file.
-
[quote author="bootchk" date="1404404000"]I would prefer that they were version controlled, since not every deployment of a Qt app relies on an installed Qt on the user's machine[/quote]
Well, same is true for all other parts of Qt: libraries, platform plugins, etc. You as a developer can always generate all these during compilation, and then it is your choice what how to use them.
-
Yes, its just a matter of convenience. Everyone could be required to build Qt from source, but for convenience, the Qt project provides pre-built executables for most platforms.
Are the .qm files universal, and usable on any platform? All the more reason to provide them pre-built, there is no technical reason to build per platform. I'm not sure they are universal, I see that the qt_es.qm file distributed for OSX is a different size than the one distributed on Linux !
The agrument about whether to pre-build is very commmon. On Github, they have waffled. First they were allowing version controlling .exe, then they weren't, and now they are again. If the reason not to version control buildable artifacts is to save disk space, that reason is quickly dissappearing.