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.

You're also missing the "Translators" tab in the application about dialog if 
you don't set your application domain properly.

Cheers,
  Albert