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. > > 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. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
