New i18n interface for KDE 4

[Chusslove Illich]

> [: Michael Olbrich :]
> In that case, why use the class at all?
>
> const char *msg = "Blah, blah: %1";
> ...
> i18n(msg, foo);
>
> Does the same job.

In this way there is nothing to tell message extractor that it should take 
the message out. 

Currently, we are having situations where something like this is required, 
and then there are several noop macro wrappers (eg. I18N_NOOP) just to 
give signal to the extractor. But these usually appear only in starting 
segments of programs, before i18n layer has been activated. For general 
use in the code, it seems to me that the class solution is cleaner.

And i18n() templates themselves are best kept as short as possible, which 
the existence of class assures. I like to think of i18n() templates as 
only a convenience: the programmer himself doesn't have to call arg() 
methods, nor the ending toString().

> However, both cases allow nasty things like:
>
> QString msg = i18n("Blah, blah: %1");
> ...
> msg.arg(foo);
>
> Maybe whatever gettext replacement or preprocessor we get could do some
> sanity checks here.

True, that would be one possibility for check.

Also, since the conversion inside i18n() templates is explicit, it can also 
be checked at runtime -- big warning in shell output, or even an abort, in 
debug mode...

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050915/d0b4720e/attachment.sig>