KDE4 proposal: Paths in i18n strings

[Krzysztof Lichota]

Chusslove Illich napisał(a):
> 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.

The problem is to remember to put argPath(). In most cases developer
will forget to put it, especially if he is only starting to code for
KDE. If you have type detection, it is done automatically. It has also
the advantage that you can do it later and consistently for all
ocurrences of the same type.

>> 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.

I thought we are talking about passing something like QPath, for the
purpose of transforming it to platform-dependent representation :)
Using strings as paths makes it harder and error-prone.

>> 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.

I don't understand this example.
My point is that if there are 2 prefixes and developer will have to
choose which, in some cases he chooses wrong. Applying
internationalization should be no-brainer: "put i18n around the string".

>> 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 :)

I'd prefer to see Qt adopting this kind of translatable strings for Qt :)

	Krzysztof Lichota


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060707/f8f36242/attachment.sig>