<table><tr><td style="">kossebau added inline comments.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D5439" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D5439#inline-22277" rel="noreferrer">View Inline</a><span style="color: #4b4d51; font-weight: bold;">kossebau</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kaboutdata.h:314</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">Update from irc: both <a href="https://phabricator.kde.org/p/ltoscano/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;" rel="noreferrer">@ltoscano</a> 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).</p>
<p style="padding: 0; margin: 8px;">Given that the requirement of an qapp instance is nowhere documented in <a href="https://api.kde.org/frameworks/ki18n/html/prg_guide.html" class="remarkup-link" target="_blank" rel="noreferrer">https://api.kde.org/frameworks/ki18n/html/prg_guide.html</a> the question now is if that is a regression or simply never has worked.</p>
<p style="padding: 0; margin: 8px;">More on that another day though.</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Aha! i18n() calls before the creation of QApplication instance currently fail (or rather: only return the untranslated string) for this reason:<br />
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.<br />
To unlock all categories for being set via the environment variables, the quickest way is to call <tt style="background: #ebebeb; font-size: 13px;">setlocale(LC_ALL, "");</tt>. And this is what is done during the Q*Application instance creation, on Unix.</p>
<p style="padding: 0; margin: 8px;">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.</p>
<p style="padding: 0; margin: 8px;">See also<br />
<a href="http://man7.org/linux/man-pages/man3/setlocale.3.html" class="remarkup-link" target="_blank" rel="noreferrer">http://man7.org/linux/man-pages/man3/setlocale.3.html</a><br />
<a href="https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#_ZN23QCoreApplicationPrivate10initLocaleEv" class="remarkup-link" target="_blank" rel="noreferrer">https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#_ZN23QCoreApplicationPrivate10initLocaleEv</a><br />
<a href="http://stackoverflow.com/questions/25661295/why-does-qcoreapplication-call-setlocalelc-all-by-default-on-unix-linux" class="remarkup-link" target="_blank" rel="noreferrer">http://stackoverflow.com/questions/25661295/why-does-qcoreapplication-call-setlocalelc-all-by-default-on-unix-linux</a></p>
<p style="padding: 0; margin: 8px;">No instant proposal myself how this could/should be fixed best.</p>
<p style="padding: 0; margin: 8px;">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 <tt style="background: #ebebeb; font-size: 13px;">setlocale(LC_ALL, "");</tt> one itself, and then restore any previous value perhaps even, just to stay clean.<br />
In any case: no i18n() in static construction code, that is racy and should be simply considered to not work.</p>
<p style="padding: 0; margin: 8px;">So tasks seem to be:</p>
<ol class="remarkup-list">
<li class="remarkup-list-item">change the example code to have needed order</li>
<li class="remarkup-list-item">write patch for ki18n docu</li>
<li class="remarkup-list-item">make some blog post to raise awareness</li>
</ol>
<p style="padding: 0; margin: 8px;">First though: device-less leisure time :)</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R244 KCoreAddons</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D5439" rel="noreferrer">https://phabricator.kde.org/D5439</a></div></div><br /><div><strong>To: </strong>kossebau, Frameworks, stikonas, mpyne, aacid, ltoscano<br /><strong>Cc: </strong>dfaure<br /></div>