Bug 375385 - Kajongg does not load its translation catalog from local install folder
Summary: Kajongg does not load its translation catalog from local install folder
Status: RESOLVED FIXED
Alias: None
Product: kajongg
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Wolfgang Rohdewald
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-21 20:32 UTC by Burkhard Lück
Modified: 2017-01-22 16:41 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: master


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Burkhard Lück 2017-01-21 20:32:11 UTC
master kf5 (l10n-kf5, frameworks, workspace, applications, extragear, playground) build from sources as separate user installed in dir $KF5=/home/kdeframeworks/kf5

strace kajongg 2>&1  | grep $KF5/share/locale/|grep kajongg shows no hit, i.e. it does not load the translation catalog in $KF5

full strace output shows that the frameworks catalogs *_qt.qm in $KF5 are loaded
Comment 1 Wolfgang Rohdewald 2017-01-21 21:32:37 UTC
I  have no idea how to find the correct path for .mo files. Right now /usr/local/share/locale and /usr/share/locale are hard coded.

Does kf5-config --path locale return the correct path for you?

But - I have not been able to find the source code for kf5-config. Can you give me a hint?

Please remember that this is Python and there are currently no usable KF5 bindings for Python, so I cannot simply use KF5 classes - I have to simulate what they do. This will never be perfect, but right now at least it should work for standard installations.



*qt.pm are a different case:
1. using QLibraryInfo.location(QLibraryInfo.TranslationsPath), 'qtbase_{}.qm'.format(language)))
2. qtpaths does not seem to return that path at all  (see qtpaths --types)
3. kajongg does actually load *.qm but makes no use of them because KDE has support for many more languages and until now I found no place where kajongg actually needs them. Will remove loading *.qm. (see commits 9c429f29 and 8b98952)
Comment 2 Wolfgang Rohdewald 2017-01-21 21:45:01 UTC
Maybe using the Qt translations path might help. If you apply the following patch to master and start kajongg from shell, it will print that path. For me, that is 

Qt translation path:/usr/share/qt5/translations

Is there a formal method to compute the correct KF5 .mo path from this one?
But that will probably only help if you also build qt5 in the same local install folder. Is that the standard case when building kf5?

diff --git a/src/kdestub.py b/src/kdestub.py
index aeefa25c..772581b9 100644
--- a/src/kdestub.py
+++ b/src/kdestub.py
@@ -211,6 +211,7 @@ class KApplication(QApplication):
 
     def initQtTranslator(self):
         """load translators using Qt .qm files"""
+        print('Qt translation path:{}'.format(QLibraryInfo.location(QLibraryInfo.TranslationsPath)))
         for language in reversed(list(MLocale.extendRegionLanguages(KGlobal.currentLanguages()))):
             self.installTranslatorFile(os.path.join(
                 QLibraryInfo.location(QLibraryInfo.TranslationsPath), 'qtbase_{}.qm'.format(language)))
Comment 3 Burkhard Lück 2017-01-21 22:01:50 UTC
(In reply to Wolfgang Rohdewald from comment #1)
> I  have no idea how to find the correct path for .mo files. Right now
> /usr/local/share/locale and /usr/share/locale are hard coded.
> 
> Does kf5-config --path locale return the correct path for you?
> 
> But - I have not been able to find the source code for kf5-config. Can you
> give me a hint?
> 
Forget kf5-config, it is in frameworks/kdelibs4support/, therefore deprecated

> Please remember that this is Python and there are currently no usable KF5
> bindings for Python, so I cannot simply use KF5 classes - I have to simulate
> what they do. This will never be perfect, but right now at least it should
> work for standard installations.
> 
asked on #kde-games about kf5 python bindings when kajongg switched to kf5 and got these replies:
[Dienstag, 17. Januar 2017] [22:14:38 CET] <heirecka> looks like they were added after 5.30: https://cgit.kde.org/ki18n.git/commit/?id=ff1e3a6f3e916ebc70288459c55c1145d413f55f
[Dienstag, 17. Januar 2017] [22:15:08 CET] <heirecka> no clue how functional they are

But why use ki18n when there are no python bindings for it?
Beside frameworks we have some application using qt translation system:
zanshin, kcachegrind, marble, step, gcompris and all of them are fully translated in my system with a user installation
Comment 4 Burkhard Lück 2017-01-21 22:39:33 UTC
(In reply to Wolfgang Rohdewald from comment #2)
> Maybe using the Qt translations path might help. If you apply the following
> patch to master and start kajongg from shell, it will print that path. For
> me, that is 
> 
> Qt translation path:/usr/share/qt5/translations
> 
Here it is (local installation of 5.6.1)
/home/kdeframeworks/Qt5.6.1/5.6/Src/qttranslations/translations/

Use the dirs you get with
"$ qtpaths --paths GenericDataLocation
/home/kdeframeworks/.local5:/home/kdeframeworks/kf5/share:/usr/share"
to search for locale/[LANG]/LC_MESSAGES/kajongg.po 
(or kajongg_qt.qm for qt translation system)
and you will pick up the correct catalog - first user install, second system install


> Is there a formal method to compute the correct KF5 .mo path from this one?
> But that will probably only help if you also build qt5 in the same local
> install folder. Is that the standard case when building kf5?
> 
No, see above
Comment 5 Wolfgang Rohdewald 2017-01-22 14:57:32 UTC
Python kf5 bindings are heavily being worked on - see kde-bindings mailing list, but not yet ready. Plus - I want kajongg to run on windows too - and I do not believe Python kf5 bindings will ever run on windows. So - when kf5 bindings are available, I will use them but I will always need a python-only alternative anyway.

kajongg always used the normal *.mo gettext translation system like most KDE program do, I see no advantage in changing that to the Qt system.

I know kf5-config is deprecated but I wanted to see its source code.

It seems like the paths in kf5-config are hard coded at compile time.

So that is what current master kajongg now does: cmake creates a python script defining those paths. If this does not work for you, please tell me what cmake writes into kajongg/kdepaths.py for you.

I would not really like to use qtpaths/QStandardDirs because I am quite sure it is possible to compile KDE into a separate user installed directory using the system-based Qt5 packages. Qt5 would then be in /usr/share but KDE would not.
Comment 6 Burkhard Lück 2017-01-22 16:41:40 UTC
(In reply to Wolfgang Rohdewald from comment #5)
> So that is what current master kajongg now does: cmake creates a python
> script defining those paths. If this does not work for you, please tell me
> what cmake writes into kajongg/kdepaths.py for you.
> 
Kajongg loads the catalog from local install folder now, many thanks.