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? (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. Cheers Friedrich