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