KDE4 proposal: Paths in i18n strings
Chusslove Illich
caslav.ilic at gmx.net
Tue Jul 4 16:56:21 BST 2006
>> [: 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>
More information about the kde-core-devel
mailing list