KDE4 proposal: Paths in i18n strings

[Frans Englich]

On Friday 07 July 2006 14:08, Chusslove Illich wrote:
> > [: Frans Englich :]
> > I'm thinking about rewriting KlocalizedString such that substitution is
> > postponed until when the conversion happens. [...]
>
> This is already so with ki18n*. Arguments are stored inside a container,
> and the final string assembly happens only when toString() is called.

Yeah, missed that, thanks.

[...]
> >        QFile file("out.txt");
> >        QTextStream out(&file);
> >        out << i18n("foo");
> >
> > Here, the QTextStream streaming operator is overloaded and calls
> > something like KLocalizedString::toConsoleString(). Library backends
> > can then spec their APIs with KLocalizedStrings.
>
> In the example you give, it's just luck that we can provide an operator. In
> general we'd end up with places where unambiguous conversion is possible
> and places where it is not.

Could you give an example of where we would get this ambiguity?

> When not, programmer would have to think of 
> which to*String() to use,

Again, could you give an example? (Just trying to identify what exactly we're 
dealing with.)

> and that would be nice source of errors, since 
> he wouldn't be accustomed to do it routinely.

The question is what's better. If not going the way I've proposed, how is the 
user supposed to achieve that messages are properly formatted in the console?

> Also, is there no case where something might take either rich or plain
> text, depending on intention of the code?
>
> > Wouldn't this also remove the need for ki18n*()?
>
> ki18n is anyway needed when it is very, very convenient to provide
> arguments later in the code.

I know. But by letting i18n return KLocalizedString, we can skip the ki18n 
calls since i18n already provides the ability to postpone substitution(by 
returning KLocalizedString, just like ki18n).

The big difference is that the user doesn't have to think. He doesn't have to 
think about using k18n or i18n. 

Cheers,

		Frans