Further on the road to new i18n API for KDE4

[Nicolas Goutte]

On Wednesday 15 March 2006 21:07, Chusslove Illich wrote:
> > [: Nicolas Goutte :]
> > As I suppose that you know my position from previous discussions (and
> > therefore do not need it re-iterated), here just a few comments on
> > details.
>
> Indeed 'tis true that I know your stances, but I am kind of afraid that not
> many other comments came up (both now and before). I suppose that the
> change in i18n API is going to hit just about everybody, and there are
>
> many little things that can be done this or that way. Like:

Yes, I know. (It will be similar as with the change to cmake, people will 
complain but nearly nobody would have taken part toward the decision.)

> >> [: Chusslove Illich :]
> >> ki18n("%1, %2...").argf("foo%1").argf(10).toString()
> >
> > [: Nicolas Goutte :]
> > What happens when the developer uses arg() and not argf(). I expect that
> > this will be done quite a number of times.
>
> In short, a compile time error, as KLocalizedString is not inherited from
> QString. 

Ah, yes, I was sure I forgot something.

> But the intent here is more important: I want to discourage
> general use of this form (thus the new names, ki18n and argf), to limit it
> only to (rare) special situations. For general use, I intend the short
> (template) forms:
>
> i18n("%1, %2...", "foo", "bar") // ordinary
> i18nc("Dear Translator...", "%1, %2...", "foo", "bar") // context
> i18np("%1 image out of %1", "%n images out of %1", sel, tot) // plural
>
> If we drop the short forms, thus making toString() call necessary for
> *every* i18n'd message, then the names ki18n and argf might as well revert
> to i18n and arg. But I think forcing people to use toString() all the time
> is too much (is it? that's one question to which I didn't get a clear
> answer so far).

Yes, that is part of the questions I was and I am still not sure about how to 
answer.

>
> > In which time would you be ready to put it in trunk/KDE?
>
> Coding is the smallest issue here, I could quite quickly implement whatever
> is agreed upon (and convert kdelibs to new API); also piece up transition
> instructions, including how to use the conversion script. But I would
> really like to get more people agreeing on the new API.

Sorry, I did not mean to hurry you, rather the contrary.

Have a nice day!