KDE4 proposal: Paths in i18n strings

[Chusslove Illich]

>> [: Chusslove Illich :]
>> 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.
>
> [: Frans Englich :]
> Could you give an example of where we would get this ambiguity?

There are two ambiguities I have in mind.

One is that of a implicit conversion.

Some time back, I did a compile-only run through KDE 3.(something) modules, 
and there were several hundred cases where implicit QString->[QK]Something 
were performed. Though half of that was with respect to KGuiItem, and 
someone told its constructor should be explicit in KDE4 (don't know what 
happens there).

But even bigger problem with implicit conversion is that, following many 
years of habit or indeed legal Qt style, one might do this:

QString tmp = i18n("Blah %1"); // implicit conversion kicks in
// ...
tmp.arg(foo)

(which is by the way reason I used subs() instead of arg(), to make things 
as distinct as possible). Yes, there will be warnings in the shell, and I 
even got suggestion to abort in debug mode, but...

Second ambiguity is because some Qt stuff might be able to use rich text 
and some not (or I'm wrong here?), and that we couldn't always introduce 
an operator to cover it (not to mention that discoverability of such 
overloads would be dubious).

> If not going the way I've proposed, how is the user supposed to achieve
> that messages are properly formatted in the console?

I was following the line of "feed the dog and don't touch anything" -- ie. 
so far programmers had to decide where to use and where not to use rich 
text, and so they would have to continue doing.

A little crazy idea also went through my mind, namely that KLocalizedString 
could check whether message starts with <qt> and decide formmatting upon 
that. But then, as far as I have seen, programmers sometimes do "<qt>" + 
i18n("...") + "</qt>", which would invalidate the approach (though, I 
wonder, perhaps that practice should be deprecated?)

> I know. But by letting i18n return KLocalizedString, we can skip the
> ki18n calls since i18n already provides the ability to postpone
> substitution [...]

Gotcha :) But coupled with implicit conversion, it's dangerous.

It would also encourage splitting messages, which is 99% of the time not 
necessary. As it is now, I have script which goes through i18n*() calls, 
and checks whether all arguments are in place and whether there are no 
known number formatting calls (KLocalizedString should handle that). I 
also had an idea of extracting arguments into POT comments, as a possible 
help to translators (which would make even extra sense with argument 
tags). So it's really nice when the complete message is in place :)

-- 
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/20060708/a9aef46b/attachment.sig>