New i18n interface for KDE 4

[Chusslove Illich]

> [: Frerich Raabe :]
> I think it's pretty cool that you're investigating. I had *endless*
> private email discussions with translators of a bazillion languages
> about translating the fuzzy clock (I thought it'd be just a tiny clock
> mode, boy was I wrong).

Heh, with scripting, it would be a matter of minutes to... Awh, you know :)

> I have no opinion on the overhead, I'd rather profile it first.

So I did. It is just that one shouldn't compare the performance of the 
current system with the scripted system in terms of ratio in execution 
time of i18n() calls. That is bound to be disastrous :) Instead, I've 
chosen to think in absolute terms, like: I want my i18n system to be able 
of delivering at least 1000 *scripted* messages per second, so that user 
doesn't feel any holdup in interface.

I've put up a document about this scripting stuff altogether, you can jump 
to performance section:

http://caslav.gmxhome.de/writings/ktranscript.html

> I'm not knowledgeable when it comes to security aspects (I just fail
> to think along the lines of how an evil user thinks, I find it hard to
> misuse stuff intentionally - I always do that unintentionally). 

Same here, I even don't like to poke much, so I don't break anything at 
all :)

> I assume that covers the 'What scripting language to use, anyway?'
> part) - I guess whitespace-dependant languages like Python are out 
> of the question [...]

I wouldn't count out Python because of such a trivial matter :) There might 
be not so hard ways to deal with it.

But there are other problems.

First, with this newly planed organization of kdelibs, I am not sure that a 
full fledged external interpreter can be available at the same (or lower) 
level as i18n calls. Or say it can on some platforms, I don't know. That 
is why I would like to wait a bit with this part.

Second, there are nice-to-have properties that you mentioned, but there is 
also syntactic cleanliness of Scheme, as I pointed out in the other 
message, which is perfect for translation scripting. And to be quite 
frank, I used Scheme in form of Guile as a test engine also because it was 
damn easy to. I have yet to see how it goes with Perl or Python.

>> [: Chusslove Illich :]
>> First is that KI18n is inherited from QString, and only has the smart
>> arg() methods which override QString's.
>
> [: Frerich Raabe :]
> This sounds totally very wrong to me.

I am certainly not a daily practitioner of C++, but I would like some more 
reasons for this. If for nothing else, to really purge it out of my head.

Nicolas mentions the non-dependability on QString due to possible changes 
in next major Qt, which is nice, but I said I think that many other things 
would have to be fixed throughout Qt-using code if QString changes, so 
that KI18n would be just a drop in a sea. Or is it not so?

> Source-compatibility ought to be almost guaranteed (except on those
> cases where you depend on two or three user-defined conversions in a
> row, I guess) if you provide a 'operator QString() const;', no? The
> compile would (should!) choose your special KI18N::arg() over those
> provided by QString (it's one conversion less).

Well, as I said, I did run some checks. In summary, for basic KDE modules, 
I got some 500+ conversion errors. Most of them (about 75%) were when the 
needed argument was a KGuiItem, which has implicit conversion to QString 
through one of the constructors. Most of the rest were because of 
QVariant, which also has a constructor from QString.

So, one thing I tried, just to see what will happen, is to duplicate 
KGuiItem's constructors to take KI18n. But then, there were many errors 
where the functions were overloaded to take both KGuiItem and QString, so 
compiler now refused to pick the conversion. And I couldn't do this for 
QVariant, as it is not "ours". Perhaps I could put implicit conversion to 
QVariant in KI18n, but... you see how it goes :)

-- 
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/20050908/f440f713/attachment.sig>