D5439: API dox: more info about KAboutData's orgDomain/desktopFileName properties

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> kossebau wrote in kaboutdata.h:314
> Update from irc: both @ltoscano and me could reproduce by patching kpartloader or okteta that with some current KF (e.g. 5.32) the i18n calls done as part of the KAboutData constructor call seem to fail when done before the QApplication instance is created (yes,  KLocalizedString::setApplicationDomain() always called before the first i18n() call).
> 
> Given that the requirement of an qapp instance is nowhere documented in https://api.kde.org/frameworks/ki18n/html/prg_guide.html the question now is if that is a regression or simply never has worked.
> 
> More on that another day though.

Aha! i18n() calls before the creation of QApplication instance currently fail (or rather: only return the untranslated string) for this reason:
gettext(), as used internally by ki18n, looks at the locale names set for the different locale categories (LC_*). By default at program start, those are all fixed to "C". Only if they are set to "" (empty string) then the environment variables are looked at, otherwise those are ignored for the respective category.
To unlock all categories for being set via the environment variables, the quickest way is to call `setlocale(LC_ALL, "");`. And this is what is done during the Q*Application instance creation, on Unix.

That is why before QApplication app(c, v); any calls to i18n will return the untranslated version, because internally "C" is set as value for LC_MESSAGES category, ignoring whatever the respective environment variables contain. Only after qapp sets "" as locale name for the LC_MESSAGES category via the mentioned call, gettext() will fall back to get the locale name from the env var, with the "LANGUAGE" var being the first taken into account, which is also the one ki18n uses to pass the locale name for which a catalog has been found.

See also
http://man7.org/linux/man-pages/man3/setlocale.3.html
https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#_ZN23QCoreApplicationPrivate10initLocaleEv
http://stackoverflow.com/questions/25661295/why-does-qcoreapplication-call-setlocalelc-all-by-default-on-unix-linux

No instant proposal myself how this could/should be fixed best.

Possibly it should be simply only documented, that code either has to delay any i18n calls until QApplication instance is created. And if one really needs to use i18n() calls without a QApp instance, to call `setlocale(LC_ALL, "");` one itself, and then restore any previous value perhaps even, just to stay clean.
 In any case: no i18n() in static construction code, that is racy and should be simply considered to not work.

So tasks seem to be:

1. change the example code to have needed order
2. write patch for ki18n docu
3. make some blog post to raise awareness

First though: device-less leisure time :)

REPOSITORY
  R244 KCoreAddons

REVISION DETAIL
  https://phabricator.kde.org/D5439

To: kossebau, #frameworks, stikonas, mpyne, aacid, ltoscano
Cc: dfaure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170414/e05052bf/attachment-0001.html>