The messages from subdirs libcore + libviews are extracted using Qt translation system ( tr() calls ) into the catalog kcachegrind_qt, but this catalog is not loaded into kcachgrind nor into qcachegrind. In KF5 a translation catalog named *_qt.po by default is installed as qm translation catalog and can not be used by a kf5 app any more, such a catalog has to be loaded using the Qt Translator. Solutions for this issue: 1) use a function loadTranslation(..) as in https://cgit.kde.org/marble.git/tree/src/apps/marble-kde/kdemain.cpp to load the Qt catalog translations into kcachgrind 2) use xgettext for the subdirs libcore + libviews to extract all messages into one single catalog kcachegrind and merge the existinhg translations in the catalog kcachegrind_qt into the catalog kcachegrind From my pov no 1) is completely useless because there is no application loading the translation from the catalog kcachegrind_qt not even qcachegrind. @Josef: what is the preferred solution for the maintainer? I can file a review request for solution 2) but not for 1) until I see code in qcachegrind that loads translations from a qm catalog.
> but this catalog is not loaded into kcachgrind nor into qcachegrind. Oops. I think that translations in a developer tool such as kcachegrind often is more confusing than useful, but it has to work. My point of view: (*) of course, libviews + libcore must be translateable, with translations usable in kcachegrind, (*) qcachegrind (the pure-Qt version of kcachegrind) should just depend on Qt, and no need for it to support translations. I would like to keep qcachegrind around for people which compile themselves but without the need for a full KDE development environment. For your solution (2), do we need source code changes in libviews + libcore at all? Ie. can calls into the Qt translation system be redirected into xgettext functions? As said above, I want qcachegrind to just depend on Qt.
> qcachegrind (the pure-Qt version of kcachegrind) should just depend on Qt, and no need for it to support translations. What makes qcachegrind differnet than kcachegrind? > As said above, I want qcachegrind to just depend on Qt. That is just fine, did you read the email i sent?
(In reply to Albert Astals Cid from comment #2) > > qcachegrind (the pure-Qt version of kcachegrind) should just depend on Qt, and no need for it to support translations. > What makes qcachegrind differnet than kcachegrind? It does not get installed, as it has the same feature set as kcachegrind. I keep the qcachegrind sources here (more or less just a main window embedding widgets from libviews) to keep the variants consistent. If supporting translating qcachegrind is easy, of course it would be nice. > > As said above, I want qcachegrind to just depend on Qt. > That is just fine, Perfect! > did you read the email i sent? Only now; thanks for the link!
Created attachment 102373 [details] patch to load kdcachegrind_qt copy of https://cgit.kde.org/marble.git/commit/src/apps/marble-kde/kdemain.cpp?id=d365180db0382239e5a2dbc1c49d58ecf1f34a7f make the gui translated except the QT_TR_NOOP strings
That's the "wrong" patch, ECM has support for that, it's just that marble people refuse to use ECM because reasons
I think that I have fixed this bug with: https://commits.kde.org/kcachegrind/3c0f3423e58f65f93bf062b319a346dcea11daff which comes from https://phabricator.kde.org/D4795 Sorry, I didn't see this bug.
Ah, I should have closed this bug after Luigi's fix, which uses the ECM feature.