Fix loading and setting of translations in KDEMarble app
AbandonedPublic

Authored by kossebau on Jun 3 2016, 8:17 PM.

Details

Reviewers
nienhueser
rahn
Group Reviewers
Marble
Summary

Qt translations for the libs and plugin need to be actively loaded not only in the QtMarble app, but also in the KDEMarble app. Because the lib or the plugins do not do it themselves.
The KLocalizedString translation domain also needs to be set before the first i18n calls are made, which includes the calls during setting up the KAboutData setting.

Diff Detail

Repository
R34 Marble
Lint
Lint Skipped
Unit
Unit Tests Skipped
kossebau updated this revision to Diff 4201.Jun 3 2016, 8:17 PM
kossebau retitled this revision from to Fix loading and setting of translations in KDEMarble app.
kossebau updated this object.
kossebau edited the test plan for this revision. (Show Details)
kossebau added reviewers: Marble, nienhueser, rahn.
kossebau set the repository for this revision to R34 Marble.
aacid added a subscriber: aacid.Jun 5 2016, 11:35 PM

Why not using the ecm bits that do this for you? (the qt part)

In D1764#32925, @aacid wrote:

Why not using the ecm bits that do this for you? (the qt part)

Those bits typically are added to the lib, not the app. While adding to the app sources would work as well, it felt strange to me, so I wrote the same logic explicitely.
Adding to the lib is not possible given the Marble main devs wanted to keep that ECM free. Possibly as Marble code is not only targeting the usual Linux desktop world.

aacid added a comment.Jun 7 2016, 11:44 AM
In D1764#32925, @aacid wrote:

Why not using the ecm bits that do this for you? (the qt part)

Those bits typically are added to the lib, not the app. While adding to the app sources would work as well, it felt strange to me, so I wrote the same logic explicitely.

You say you added it to the lib? It's on the app no? I agree with you it makes more sense to add to the lib.

Adding to the lib is not possible given the Marble main devs wanted to keep that ECM free. Possibly as Marble code is not only targeting the usual Linux desktop world.

That makes no sense, in what sense is ECM "targetting the usual Linux desktop world"?

In D1764#33304, @aacid wrote:
In D1764#32925, @aacid wrote:

Why not using the ecm bits that do this for you? (the qt part)

Those bits typically are added to the lib, not the app. While adding to the app sources would work as well, it felt strange to me, so I wrote the same logic explicitely.

You say you added it to the lib? It's on the app no? I agree with you it makes more sense to add to the lib.

? "Those bits typically are added to the lib" I said, not "I added it to the lib".
With libmarble translations though are by design and use-cases e.g. in embedded worlds left to the user of the libmarble to provide. Not my decision, but I see no pressing need to change that, even if it would be nice to have for consistency with the average library product from KDE, agreed on that point.

Adding to the lib is not possible given the Marble main devs wanted to keep that ECM free. Possibly as Marble code is not only targeting the usual Linux desktop world.

That makes no sense, in what sense is ECM "targetting the usual Linux desktop world"?

ECM is surely also targetting more (and you interpreted here my words a little too much), but it has not reached all places yet (e.g., where can I download ready-to-use ECM packages for Windows?).
What I meant is: Marble has to deal with being first in some, so where ECM is not part of the platform SDK or otherwise easily(!) available yet.
One example I have experienced myself is SailfishOS. Using ECM would be nice, but it means extra hurdles for everyone working on Marble Maps on SailfishOS, Besides, minimum requirements might not be met (are not with SFOS). Same reason why KF5 are not a possibility, even if it would be nice to have.

kossebau abandoned this revision.Jun 10 2016, 6:22 PM

Committed as part of D1763