New i18n interface for KDE 4

[Chusslove Illich]

> [: Michael Olbrich :]
> I think we can all agree that it is _possible_ to inherit Ki18n from
> QString. The question should be whether it makes sense from a design
> point of view. The only argument _for_ inheriting I've seen so far is
> that it breaks less code. But is that really an argument? We are at the
> beginning of a release cycle. Right now is the time to break things to
> do it _right_.

It is not just that I don't want to break current code, but also that I 
cannot figure out a new syntax which would be no more disturbing to 
programmers than the current one.

And from implementation point of view, I want to avoid having to tweak 
things in the future, as it seems to me would be the case with any sort of 
implicit converters.

> So I think we should stop discussing what is possible and think about
> the best way of doing it.

If you insist, I do have one untried idea, but it looks to me a bit 
grotesque. And it certainly changes the programming practices.

As I mentioned before, we make KI18n non-inherited, without implicit 
conversions, but with a method to finalize the translation and return a 
QString, like that t(). But then, instead of making i18n() functions 
return KI18n, we make them as series of templates which return QString, 
like this:

// Basic, no arguments
QString i18n(const char *text) {
    return KI18n(text).t();
}

// Basic, one argument
template <typename A1>
QString i18n(const char *text, const A1 &a1) {
    return KI18n(text).arg(a1).t();
}

// Basic, two arguments
template <typename A1, typename A2>
QString i18n(const char *text, const A1 &a1, const A2 &a2) {
    return KI18n(text).arg(a1).arg(a2).t();
}

// Etc, up to some (big) number of arguments...

This way, programmer can write:

i18n("Tag %1 not found in file %2", tagName, fileName);

which is shorter than current syntax.

There are three problems, however.

First, different flavors of i18n() functions would have to have different 
names, like i18n() for basic, i18nc() for context and i18np() for plural 
messages. On the other hand, this would bring us more to Gettext 
conventions, where they use different names for basic and plural handling 
calls.

Second, if programmer wants to defer adding of arguments to a later point, 
he must call t() himself *and* use fourth, special version of i18n, which 
returns a KI18n, like this:

KI18n msg = di18n("Blah, blah: %1");
...
msg.arg(foo).t();

This kind of splitting should be rare and discouraged, so this might not be 
much of a problem, or in fact a small advantage. Still, there would also 
have to exist di18nc() and di18np(), for deferred context and plural calls 
(could be overloaded, but then it would be in discord with immediate 
i18n's). Getting out of hands, yet?

(A short digression here: in order to avoid friend templates, those 
ordinary i18n's above would actually have calls like 
di18n(text).arg(a1).arg(a2)... inside them.)

Third problem is that a new message extractor would have to be written. As 
per Stephan Kulow, this is anyway in todo queue, as he would like to dump 
current patched version of Gettext. He also hinted that the extractor 
could actually be just an intermediate transformer of the source file into 
temporary file that Gettext extractor can parse. With that solution there 
would be no additional qualitative trouble with this template approach.

-- 
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/20050913/8d627910/attachment.sig>