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
