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

[Albert Astals Cid]

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