Ki18n mostly ready

[Chusslove Illich]

> [: 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 (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130801/af1c9460/attachment.sig>