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
> 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 :)

For proposed patch to improve ki18n docu see https://phabricator.kde.org/D5455

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/f5c0e2f9/attachment-0001.html>