Ki18n mostly ready

Albert Astals Cid aacid at kde.org
Thu Aug 1 20:03:36 UTC 2013


El Dijous, 1 d'agost de 2013, a les 12:54:07, Kevin Ottens va escriure:
> Hello,
> 
> On Thursday 01 August 2013 11:58:44 Chusslove Illich wrote:
> > > [: Kevin Ottens :]
> > > What's needed for kconfig_compiler? Because currently kconfig isn't
> > > supposed to depend on ki18n at all.
> > 
> > It does generate translation calls as necessary, and currently it accepts
> > an option (from .kcfgc file) whether to generate tr or i18n calls. So
> > another option to specify the translation domain would be added.
> 
> OK, sounds good. We should make tr the default if that's not already the
> case though.

Disagree. ki18n is our i18n framework. If something else that depends on 
kconfig_compiler wants to use the poor man's solution, it's up to them, but i 
don't see why we should force it by default to everyone.

Cheers,
  Albert

> 
> > > Also having this #define before including klocalizedstring.h looks like
> > > a
> > > weird "API" to me.
> > 
> > Yes, but there was no better suggestion so far :) (and not only in KDE).
> > Under the requirement that it is statically resolved which i18n call draws
> > translations from which translation domain.
> > 
> > The only alternative (suggested by Oswald) would be to do something on the
> > level of CMake, such that setting the translation domain is nowhere
> > visible
> > in the code. But I thought this is an overkill (e.g. compared to
> > kunitconversion example in the diff), and anyway someone can always
> > orthogonally provide it if desired.
> 
> Might be better indeed. Could easily be wrapped in a cmake macro I guess.
> 
> Regards.



More information about the Kde-frameworks-devel mailing list