Bug 372643

Summary:	kcachegrind in kf5 has untranslated gui messages from catalog kcachegrind_qt.po
Product:	[Developer tools] kcachegrind	Reporter:	Burkhard Lück <lueck>
Component:	general	Assignee:	Josef Weidendorfer <josef.weidendorfer>
Status:	RESOLVED FIXED
Severity:	normal	CC:	aacid, luigi.toscano
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://commits.kde.org/kcachegrind/3c0f3423e58f65f93bf062b319a346dcea11daff	Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	patch to load kdcachegrind_qt

Description Burkhard Lück 2016-11-18 19:13:47 UTC

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.

Comment 1 Josef Weidendorfer 2016-11-21 10:30:16 UTC

> 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.

Comment 2 Albert Astals Cid 2016-11-21 10:49:36 UTC

> 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?

Comment 3 Josef Weidendorfer 2016-11-21 16:59:26 UTC

(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!

Comment 4 Burkhard Lück 2016-11-21 20:20:36 UTC

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

Comment 5 Albert Astals Cid 2016-11-21 21:26:32 UTC

That's the "wrong" patch, ECM has support for that, it's just that marble people refuse to use ECM because reasons

Comment 6 Luigi Toscano 2017-03-19 00:47:09 UTC

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.

Comment 7 Josef Weidendorfer 2017-03-20 12:56:11 UTC

Ah, I should have closed this bug after Luigi's fix,
which uses the ECM feature.