> [: 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. > I'm just wondering about the TRANSLATION_DOMAIN define vs the use of > setApplicationDomain. When is one more suited than the other from the > frameworks point of view? Since frameworks are typically libraries, then the define-way is the proper one. It can also be used always, regardless of what type of code it is. But if there are actually some programs with i18n calls, in them setApplicationDomain can be used. > 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. -- Chusslove Illich (Часлав Илић)
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
