Ki18n mostly ready

[Chusslove Illich]

> [: Albert Astals Cid :]
> to make it more obvious maybe it should be KI18N_TRANSLATION_DOMAIN ?

Well possibly, but to me it looks redundant: "translation domain" is already
Gettext-specific terminology, and it would be bizarre to use more than one
Gettext-based system in the same piece of code so as to need differentiating
between them.

>> [: Chusslove Illich :]
>> Code files can get TRANSLATION_DOMAIN everywhere through CMake-configured
>> header (.h.cmake).
>
> [: Albert Astals Cid :]
> What includes that header?

For simplicity, I would make every .cpp file include it. This is e.g. what I
did inside kdelibs/staging/kunitconversion/. Of course, if there is already
a private header included by all files, this header can include the
generated one. (But see also below.)

> Anything that needs manual intervention will break because most people
> don't care about i18n and almost noone tries their code with a non english
> locale, so let's not go for anything manual if possible.

One nice thing about static binding of calls to catalogs is that now we can
have code checks which alarm when something is amiss! There is no more the
need to analyze the code for entry points where to put insertCatalog()
calls, and which catalogs should be inserted. In other words, one can now
fix translation without understanding the code initialization, one being
orthogonal to the other.

For example, it should not be too hard to check that each main() (outside of
tests/) has setApplicationCatalog(), and if there is no main() in the
project, that each file with some i18n() calls eventually includes a header
file with TRANSLATION_DOMAIN definition.

And for .rc files, even if we leave it at manual adding of translation
domain attribute, it is totally easy to verify that each .rc file has this
attribute, and that it matches the TRANSLATION_DOMAIN set in the first
parent CMakeLists.txt.

In fact, the check could take as reference not CMakeLists.txt, but
Messages.sh, and then proceed veryfing everything below it. (Yes, this would
need a bit more discipline in Messages.sh, e.g. that it extracts exactly one
.pot file, but I think this is a good idea anyway.)

-- 
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/20130806/d370dd63/attachment.sig>