New i18n interface for KDE 4

[Frerich Raabe]

On Monday 05 September 2005 13:41, Chusslove Illich wrote:
> On kde-i18n-doc there has been some discussion about how to provide more
> power to KDE translators, especially for translating into mid to highly
> inflected languages.
>
> For example, one of the problems is that sometimes an argument in a
> message, like "Open with %1", in some languages requires form (case)
> different than the basic one, so that it is in agreement with sentence
> structure. A very thorough demonstration of this kind of problem (as well
> as a lot of talk regarding how we can solve it with new interface) can be
> found in, what I believe to be quite infamous, thread on kde-i18n-doc:
> http://lists.kde.org/?t=112300742000007&r=1&w=2

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). 
It can be so painful when you get beyond the trivial 'Press this button to 
apply the changes'.

> The idea is to allow translators to somehow operate on arguments at
> runtime, what I refer to as "translation scripting". The realization of
> this concept can be divided into two decoupled parts: an i18n interface
> capable of "capturing arguments", and choice of scripting engine for the
> translator. Decoupled means that the choice of scripting engine (or
> translator side interface) would not influence the application interface,
> ie. could be tweaked at will without breaking binary compatibility.
>
> From discussion so far, the second part (scripting engine) seems to be more
> problematic, due to concerns of overhead, security and organization. So I
> would postpone talk about this point until new structure and policies for
> kdelibs are established. But it can also turn out there is a show-stopper
> for the first part (new i18n interface), and then there is no point
> talking about the second part :)

I have no opinion on the overhead, I'd rather profile it first. 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). Regarding the 
'organization' (I assume that covers the 'What scripting language to use, 
anyway?' part) - I guess whitespace-dependant languages like Python are out 
of the question (*sob*), you probably want a language

- which KDE already depends on (so that you don't annoy the packages)
- which is reasonably popular (so that you've got plenty of people who can 
help fix problems and so that you can get tutorials and whatnot)
- which supports a wide range of styles, from compact/unreadable to verbose 
(so that you can do tiny one-liner if you want to, but still use expressive 
switch statements and whatnot if you need to)

For these reasons, Perl sounds like an interesting candidate to me. I barely 
know Perl but I guess for the translations you usually need just a tiny 
subset of the language - and *that* could be documented in some I18N HOWTO or 
so.

> Instead, i18n() functions should return a special class, named say KI18n,
> which would have its own arg() methods, smart enough to store arguments as
> they come, and perform the translation only when all the arguments have
> been supplied (passing the arguments to underlying scripting engine...)

I think this is a reasonable solution (the proverbial extra level of 
indirection).

> First is that KI18n is inherited from QString, and only has the smart arg()
> methods which override QString's.

This sounds totally very wrong to me.

> Second one is to not inherit KI18n from QString, but provide some
> facilities for implicit conversion to QString, and some more overriding
> methods to QString's original ones. This is in order to preserve as much
> as possible of source compatibility and current programming habits.
> Positive here is that there is no dependency on QString, and negative is
> that implicit conversions are double-edged sword, selection of overriding
> methods is dubious, and still it might not be able to achieve same level
> of source compatibility as with inherited version.

Of these three suggestions, I prefer this one. 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).

> Third approach is again with non-inherited KI18n, but also without implicit
> conversions and (possibly) without extra overriding methods. Instead, KDE
> widgets taking QString's would be changed to take KI18n's. This approach
> is both clean and would force programmers not to forget to wrap naked UI
> messages (they would get compile time error), but there are problems with
> choosing what exactly constitutes as UI string arguments in classes, and
> with the fact that pure Qt widgets are used as well.

This requires touching so much code in so many places, and I don't see a 
simple way to make it work for Qt widgets (and you do want it to work for 
those).

- Frerich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050908/4acb7d78/attachment.sig>