New i18n interface for KDE 4

[Nicolas Goutte]

On Thursday 08 September 2005 09:16, Frerich Raabe wrote:
> On Monday 05 September 2005 13:41, Chusslove Illich wrote:
(...)
> > 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.

The language issue was a point that was not solved on kde-i18n-doc.

Chusslove Illich prefered Guile. It seems to have advantages but the 
inconveniences are that not everybody knows and likes LISP-like languages.

Python is a big problem, due to its strict white space rules, making it 
unsuitable for being put in PO files. (KBabel would need special support for 
it, which will not available for KDE 3.5.x.)

Perl could be used. The only problem that I see is that there seems to be a 
move away from Perl (to Python) in KDE. (Also real Unicode-compatibility in 
strings requires Perl 5.8.)

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

That is the version that I prefer too, especially as it makes it independant 
of the future evolution of QString (for example in Qt5).

>
(...)
>
> - Frerich

Have a nice day!