KDE4 proposal: Paths in i18n strings

[Frans Englich]

On Monday 03 July 2006 20:58, Chusslove Illich wrote:
[...]

> But since using some semantic marking might indeed be most universal, how
> about wrapping arguments themselves? "Tags" would be set of same-prefix
> functions returning wrapper objects under control of KLocalizedString. For
> example:
>
> i18n("Here is path %1 there is URL %2", argPath(myPath), argUrl(myUrl));
>
> where:
>
> KLocalizedString::ArgPath argPath(const QString &path);
> KLocalizedString::ArgUrl argUrl(const QString &url);
> etc.
>
> and subs methods would be overloaded for these wrappers.
>
> This would also go the way of semantics versus presentation, so it should
> be a familiar and consistent concept.

Sounds sensible to me. However, I think there should still be many 
argPath/argURl overloads accepting Dstuff like QDir such that users don't 
have to do the conversion stuff manually(in order to save code, and achieve 
consistency).

Which ones are needed? Thoughts:

- i18nUri() -- formats a URI/URL, handles displaying passwords, etc
- i18nPath() -- formats a path. Similar to the one above
- i18nIdentifier() -- the argument is somekind of "system" identifier(user 
name, keyword in programming language, and so on)
- i18nQuote() -- quotes a text in natural language

Jarosław suggested i18nArgPath() but perhaps i18nPath(etc) is a bit cleaner 
while still avoiding clashes? Perhaps a namespace should be used.

> Looking this way, overloading for particular types might end up being same
> thing, but with unnecessary extra layer of indirection. One would easily
> expect then to find things like:
>
> i18n("Here is path %1 there is URL %2", QFile(myPath), KURL(myUrl));
>
> > [: Jarosław Staniek :]
> > Posible problem: we may want to display the mesage with path to a log
> > file or std(out|err}. The KLocalizedString class should know it's the
> > case, so there may be aditional flag for doing this
>
> This is the second problem, how to signal "formatting class" for the
> arguments (rich, plain, ...)?
[...]
> So I think we could settle on one default formatting class, and have
> programmers chose others. For example, we can say i18n* calls do rich
> text, and have pi18n* calls for plain text.
>
> i18n("Filename: %1", argPath(fname)); // -> Filename: <b>%1</b>
> pi18n("Filename: %1", argPath(fname)); // -> Filename: "%1"

I don't think this works. 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. Especially if you write a library where messages 
are sent back via callbacks, then you don't know what the user is gonna do 
with it. Sometimes it might be several output destinations. Destination 
shouldn't be hard coded.

Also, the user shouldn't have to think about display details such as how 
something where/how something should be displayed. The user should focus on 
meaning, not representation.

Perhaps all i18n stuff could be completely rich text based and not be 
destination-aware. Instead of letting the i18n code adapt to the output 
format, the output code adapts to the i18n. That is, the output code converts 
the rich text to whatever it needs. This again would require KLocalizedString 
objects, it seems(no?).

If one adds a to-QString operator to KLocalizedString, i18n() can return 
KLocalizedString while working with existing code. In turn, one can overload 
output code(such as streaming operators) to accept KLocalizedString and apply 
necessary remove-rich-text conversion. No? I know close to nothing about 
these code paths.

[...]
> Hm, this is all turning Docbook/Latex, isn't it? :)

I know!


Cheers,

		Frans