RFE: move to gettext

[kloczek]

Most of the KDE projects already moved to gettext.
It would be good to follow that path to getter reuse in memory of the code with other application.

[kloczek]

gentle ping 😄

[frankosterfeld]

Hmm, gettext is not a dependency I'd want for the other platforms qtkeychain can be used on, i.e. Windows, macOS, Android/iOS.

[kloczek]

Android and MOX in libc have i18n support.
On Windows there is no any issues with use gettext as well.

[michaelk83]

This should probably be at Qt level, rather than any specific application or library. Qt can decide internally which text utilities to use on each platform, and provide a cross-platform interface to Qt applications.

Also, since QtKeyChain is a library, not a user-facing app, I don't understand where gettext is even relevant for QtKeyChain.

[kloczek]

This should probably be at Qt level, rather than any specific application or library. Qt can decide internally which text utilities to use on each platform, and provide a cross-platform interface to Qt applications.

Nope.
Both are habdled over different API routines and this is not at abot text because .qm and .mo files are binary files. Source used to generate .qm files is xml and .po text file to generate .mo files.
In bot cases source tree needs to be adapted to use qt specyfic .qm fiels or gettet i18n support.
Cuurrently your project is using .qm and most of the projests (even core Qt) are using gettext.

I don't know is it any plan to drop Qt specyfic .qm supprt however I would be not surprised if it is alredy on mid/short term ToDo list.

[mhoeher]

Hi @kloczek,

I'm just a user of QtKeychain, but I'd still like to share some thoughts here...

First, I'd really prefer if QtKeychain does not have further dependencies. Currently, it only depends on the sole Qt core libraries - this makes it very easy to integrate into other apps. Yes, for apps that are developed in the KDE ecosystem, a dependency on GNU gettext is certainly not an issue, but for everything else, this will complicate things.

Second, considering file formats: I'd like to point out that it is perfectly possible to convert between the different formats using lupdate (if this helps in any way). I do this for my own app (i.e. extract *.ts, convert to *.po for use with an online translation service and than covert back).

And lastly, I really don't think Qt is using gettext itself. Yes - you will find some *.po files in their source tree, but this is - as far as I can tell - rather for testing their tools (the mentioned lupdate tool). As far as I can see, there is no use of gettext in their code base, though. Should this ever change, then converting to gettext might get more useful - Qt itself would rely on gettext and hence, it needs to be there anyway, so it wouldn't be an additional dependency any more.

[kloczek]

Currently, it only depends on the sole Qt core libraries

This not precisely true.
qtkeychain depend on extra-cmake-modules, qt5-qttools (cmake(Qt5LinguistTools)), libsecret-1, doxygen (if you rebuilding it with BUILD_QCH=ON).

dependency on GNU gettext is certainly not an issue, but for everything else, this will complicate things.

From that point of view swithing to gettext does not add any new dependencies (so I dont't see to much sense in that comment 😋 )
After converting translations to .po lupdate is no longer neded. Remove .qm files and add ..po ones -> commit and lupdate is no longer needed.

[mhoeher]

Sorry, but I disagree here:

1. ECM files needed are included in-source, so one does not need to have them installed in addition. qt5-qttools is part of the standard Qt installation - if one e.g. installs via the Qt Online installer (which most non-Linux(/non-distro developer) users do). libsecret is - while useful - only an optional dependency and on top only needed on Linux, no other OS is affected. And lastly, as you pointed out yourself - doxygen only is needed when one builds additional stuff - which rarely happens in consuming applications. On the other side, introducing a dependency on gettext adds a new mandatory dependency which all downstream developers on all platforms have to install first in order to build QtKeychain. So sorry, but I would not agree here at all 😉

2. AFAIR Qt cannot consume the *.po files directly. So to stick with Qt's built-in translation mechanism, one has to convert back to .ts. However, the act of converting can be fully automated, so the sole file format in which the translations are stored for further processing by the translators is IMAO a no-topic. Of course, I am open here if you have anything else in mind - I'd gladly get rid of the conversion forth and back in my own projects. But as I wrote: I am not aware that Qt handles anything else than *.ts directly.

[mhoeher]

And by the way... Looking at the implementation of ECM, more specifically, the ECMPoQmTools, I doubt KDE uses gettext (in the sense of that the gettext runtime libraries are loaded and their functions being used):

https://github.com/KDE/extra-cmake-modules/blob/master/modules/ECMPoQmTools.cmake#L181

Basically, what happens is that these *.po files are - during the build - converted first back to .ts and then to the *.qm tools. Internally, I think that KDE then uses Qt's translation service under the hood (at least, throwing an ldd on some of the KDE utils and libraries I have installed, I don't see a dependency on the gettext library).

So maybe what you mean is: Would it make sense using *.po the main files used by translators for doing their work? Looking at the more wider support of that format in upstream translation software the answer could more likely be: Yes.

But this does not mean that QtKeychain needs to use the gettext library and tools - which is a completely different thing.

[kloczek]

2. AFAIR Qt cannot consume the *.po

qtbase has no any translatiins (qt based or gettest based).

[mhoeher]

The translations are stored in the qttranslations module - as far as I can see, there are .ts files for a lot of Qt's libraries. Just clone/download the Qt sources and find -name '*.ts'.