KDE4 proposal: Paths in i18n strings

[Chusslove Illich]

>> [: Chusslove Illich :]
>> First is, how to tell what an argument is, so that formatter in 
>> KLocalizedString can act accordingly?
>
> [: Krzysztof Lichota :]
> If you want it to be extensible by user [...]

Not exactly. We want to provide certain number of formattings for 
frequently occuring kinds of arguments, like paths, etc., so that user 
doesn't have to think what kind of formatting to apply (either tags or 
quotes inside message, or writing own formatting functions, or whatever).

However, one way or the other, user has to specify the semantics:

- with special placeholders: i18n("Path %'1'", pathstr)
- with overloaded types: i18n("Path %1", QFile(pathstr))
- with tag-functions: i18n("Path %1", argPath(pathstr))

To me, the third option seems best. I don't like special placeholders for 
the reasons I put up before, and for the overloaded types, why should user 
think which type corresponds to desired meaning of the argument string? 
The logic of the third option is exactly same as in markup languages, like 
Docbook.

> If type is defined by user, there is always room for mistakes, forgotten
> calls, etc. Type should be determined by compiler.

I'd say it is unavoidable that user has to specify the meaning. For 
example, an outside reported message ("Foo reported: %1") could have 
special formatting, and it is certainly going to be just some general 
string type. I guess paths too are frequently just a string.

>> [: Chusslove Illich :]
>> This is the second problem, how to signal "formatting class" for the 
>> arguments (rich, plain, ...)?
>
> [: Krzysztof Lichota :]
> I think it should be solved by passing some KLocalizedStringFormatter
> class to toString() method.
> [...]
> I think creating many Xi18n prefixes will confuse developers and it is
> not extensible for other formatting types.

Well, compare:

ki18n("Error in %1 at %2:")
     .subsPath(file).subs(lineno).toString(KLocalizedStringFormat::plain);

pi18n("Error in %1 at %2:", argPath(file), lineno);

One has to have in mind the special position of i18n subsystem: it is not 
hot developement area and it is ubiquotous throughout code. For these 
reasons, people anyway need to learn it and will use it frequently (hence 
better the brevity), and we have solid base (like 100k messages) to make 
decisions. Eg. now we see need for rich and plain text, and I don't think 
there will be sudden expansion of other possibilities.

On the other hand, the first of the above examples would anyway be there. 
My logic is this: ki18n* functions are all peachy C++, and *i18n* 
templates are lean and mean workhorses for 99% of expected situations.

> I have been playing with similar idea as described above, but for Qt,
> not KDE. I have modified some widgets to accept only special QtTrString
> class [...]

So it boils down to programmers being prohibited from using pure Qt 
widgets. Not that I personally have any strong opinion of that, but as far 
as I understood from previous discussions, that was considered an 
unreasonable request :)

-- 
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/20060704/a509815d/attachment.sig>