ecm_create_qm_loader() uses Q_COREAPP_STARTUP_FUNCTION to inject the
loader of the additiona translator. The macro does not seem to work
when the loader is linked in a separate static library (the code
which uses Qt translations is all inside libcore and libviews).
So call the ECM macro (and then link the special loader) where
the Q(Core)Application is defined.
Many previously untranslated strings are not translated.
Details
Details
- Reviewers
weidendo - Group Reviewers
Localization - Commits
- R49:3c0f3423e58f: Correctly load the Qt-native translations
The code compiles, and content of the right pane (coming from
libviews and libcore) is now translated.
Diff Detail
Diff Detail
- Repository
- R49 KCacheGrind
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Josef Weidendorfer, KCacheGrind's maintainer, did not log in into Phabricator, so I can't add him; I sent him an email.
Comment Actions
Right, even if it is more a demo program and it is not installed, but I can try to see if it works.
Comment Actions
I think that linking the loader to qcachegrind is pointless because most of its translations are not extracted.
Comment Actions
Thanks for patch!
As I do not really know how this is expected to work, I only can test this on my system (in the next days). But the patch looks
simple enough, and if you say it works on your system, I am fine with the patch.
Regarding qcachegrind: I do not really see a need for translation here, as there is nothing installed. However, it should not be
any overhead to add translations, as it really only should reuse strings also found in KCachegrind (I try to keep the GUI in sync
as good as possible).
Comment Actions
qcachegrind and kcachegrind uses two different translation systems, and right now the strings for kcachegrind are extracted in kcachegrind.po, which would not be directly usable for qcachegrind (the native Qt system uses translation context in a... peculiar way).
But that's can be dealt separately; if you accept the review (with the specific option :) it would be an improvement already.
(the things I'd like to more is whether my guess about Q_COREAPP_STARTUP_FUNCTION is correct, but the solution so far is fine and the problem is limited to only 2 applications on all kde.org afaik, so it's fine).
Comment Actions
the things I'd like to more is whether my guess about Q_COREAPP_STARTUP_FUNCTION is correct
As far as I see, the Q_COREAPP_STARTUP_FUNCTION macro uses the Q_CONSTRUCTOR_FUNCTION macro.
According to https://wiki.qt.io/QtResources (Q_CONSTRUCTOR_FUNCTION uses the "constructor function trick"):
The constructor function trick works only if the generated C++ file is compiled and linked to the main application directly. If the resources are used in a static library and the library is then linked to the main application, the constructor function will never get called. This is the by nature of C/C++ linking- functions and variables in libraries that are unused/uncalled from the final program are removed from the final binary (optimized out). If the resources are in a shared library, then the constructor function does get invoked.
So your guess is correct.