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. _______________________________________________ Kde-frameworks-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
