TRANSLATION_DOMAIN not to be used for app code (was: Re: announcement: Kwave is in kdereview)

[Friedrich W. H. Kossebau]

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*

Cheers
Friedrich