New i18n interface for KDE 4

[Michael Olbrich]

On Tue, Sep 13, 2005 at 04:28:59PM +0200, Chusslove Illich wrote:
> > 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();
> }
[...]
> 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();

In that case, why use the class at all?

const char *msg = "Blah, blah: %1";
...
i18n(msg, foo);

Does the same job. 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.

michael