KDE4 proposal: Paths in i18n strings

[Frans Englich]

On Wednesday 05 July 2006 17:09, Chusslove Illich wrote:
> > [: Frans Englich :]
> > Where something will end up isn't necessarily determined at compile
> > time, but is a dynamic thing. It all depends on where messages will be
> > redirected. [...]
> >
> > [...] I don't suggest that any widgets should be changed in anyway.
> > (What makes you think that would be required?)
>
> So, what then decides at runtime on formatting to be used?

I was first a bit confused about how KLocalizedString works. Now, I'm less 
confused ;-)

I'm thinking about rewriting KlocalizedString such that substitution is 
postponed until when the conversion happens. KLocalizedString would be passed 
a QList or QVector containing all arguments to be inserted, and then 
substitute appropriately depending on output format. Examples:

myWidget->setWindowTitle(i18n("Howdy"));

Here, i18n returns KLocalizedString, and C++ kicks in "operator QString() 
const", which substitutes into rich text. Existing code works.

(Should perhaps call it toRichText().)

In all other cases, it all depends on what the caller does with the 
KLocalizedString. Example:

       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.

Wouldn't this also remove the need for ki18n*()?

Is it possible to implement this? The list containing the arguments passed to 
KLocalizedString could be a QVector<QPair<ArgumentType, QString> > where 
ArgumentType is an enum telling what type it is(path, identifier, etc). The 
QString is only the raw data: a double converted to QString, a QDir converted 
to QString -- but no markup such as rich text or console color codes have 
been added.

> Or perhaps I better clarify the other point:
> > I would with interest see why my suggestion of adding a QString
> > operator to KLocalizedString combined with letting i18n return
> > KLocalizedString, doesn't hold.
>
> Presently this can be done, that's what ki18n* functions are for:
>
> KLocalizedString kstr = ki18n("Blah %1 blah %2").subs(arg1).subs(arg2);
>
> One then needs to use toString() to get a QString:
>
> kstr.toString();
>
> The only thing missing is implicit conversion, since some people think it's
> evil.

I myself dislike implicit conversion but the question is whether there's 
a /better/ solution. Also, we don't make current code less safe, we only make 
things better, although not in the most optimal way(the optimal way would be 
somekind of QLocalizedString for all translatable fields in Qt widgets)

> And there is no "compact" call to return KLocalizedString, because 
> KLocalizedString's were not planned to proliferate around.

This is KDE 4 development. The opportunity to fix whatever we like, however we 
like ;-)


Cheers,

		Frans