New i18n interface for KDE 4

[Nicolas Goutte]

On Thursday 15 September 2005 13:28, Michael Olbrich wrote:
> 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);

That does not work with the patched xgettext that KDE uses, not even if you 
would define the text in the i18n call.

This could however work with a normal xgettext (with the text defined in the 
call), as some of the Gettext functions are printf-like. But then we have 
again the problem that we cannot switch easily to a normal Gettext now. (It 
has to be done carefully and in steps, starting by changing the runtime, and 
even that is controversial currently.)

>
> 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

Have a nice day!