KDE4 proposal: Paths in i18n strings

[Chusslove Illich]

> [: 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. And 
i18n* is just a wrapper which does:

ki18n*.subs(...).subs(...)....toString()

> myWidget->setWindowTitle(i18n("Howdy"));
>
> Here, i18n returns KLocalizedString, and C++ kicks in "operator
> QString() const", which substitutes into rich text. Existing code works.
> [...]
> 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.

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. When not, programmer would have to think of 
which to*String() to use, and that would be nice source of errors, since 
he wouldn't be accustomed to do it routinely.

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.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060707/61c6cd58/attachment.sig>