announcement: Kwave is in kdereview

[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

> (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?

Cheers,
  Albert

> 
> Cheers
> Friedrich


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20161009/7ff89b28/attachment.htm>