El dilluns, 10 d’octubre de 2016, a les 0:38:23 CEST, Friedrich W. H. Kossebau va escriure: > Am Sonntag, 9. Oktober 2016, 22:21:56 CEST schrieb Albert Astals Cid: > > El diumenge, 9 d’octubre de 2016, a les 18:05:29 CEST, Friedrich W. H. > > Kossebau va escriure: > > > Am Sonntag, 9. Oktober 2016, 17:44:02 CEST schrieb Albert Astals Cid: > > > > El diumenge, 9 d’octubre de 2016, a les 11:44:16 CEST, David > > > > > > > > Faure va escriure: > > > > > AFAIK KLocalizedString::setApplicationDomain isn't > > > > > > > > necessary, you should > > > > > > > > > instead define the domain as a -D flag during compilation, but > > > > > > > > I'm no expert > > > > > > > > > on that, check the wiki. > > > > > > > > Don't recomend the domain flag for anything that is not a > > > > library, it is a bad idea, several things in applications break if > > > > you do that. > > > > > > What breaks exactly? > > > > Anything using KLocalizedString::applicationDomain() > > > > https://lxr.kde.org/search?_filestring=&_string=KL.*%3AapplicationDoma > > The XMLGUI ones though only fallback to that if the rc file has no domain > tag set, so there one would be safe (unless missing the tag, but that is > also needed with libs). > > But kcheckaccelerators testing and KTipDialog seems to indeed rely on that > property, was not on my radar, thanks for the info. Guess I simply never > used them, so did not affect me. > > > > (Actually I turned to use the flag also in app code to avoid 3rd-party > > > plugins being able to ruin translations in the app code by wrongly > > > calling > > > KLocalizedString::setApplicationDomain, seen that too often (fixed it of > > > course when seen :) )). > > > > > > The only price I know of is extra QByteArray creation per each i18n* > > > call... > > > > > > In any case, everybody reading this, when switching to use > > > KLocalizedString::setApplicationDomain() as intended by the ki18n > > > developers, make sure that all app code is not seeing any > > > TRANSLATION_DOMAIN definition, as otherwise any i18n*() call will use > > > the > > > flag-based variant and thus internally ignore to whatever > > > applicationDomain > > > was set. > > > So e.g. if having lib and app code in one build system, only set > > > TRANSLATION_DOMAIN for the lib code. > > > > Isn't that obvious? > > At least from my own experience and the code from others where I saw related > issues, all the i18n magic is sadly not always obvious. > Example for definition also existing for app code that I just found: > https://lxr.kde.org/source/kde/pim/kmail/src/CMakeLists.txt > (cc:ed pimsters for heads-up) > > *cough* also > https://lxr.kde.org/source/kde/kdegraphics/okular/CMakeLists.txt *cough*
FWIW I have had almost no involvement with okular's frameworks port. Also it's not really terrible if you have both TRANSLATION_DOMAIN and setApplicationDomain set to the same value, it's not optimal but AFAICS it all will work fine. Cheers, Albert > > Cheers > Friedrich