i18n in Frameworks, the lightweight version

[Chusslove Illich]

> [: Aaron J. Seigo :]
> nobody wants to choose between two translation systems.

Everyone already must do this -- pure Gettext is always the alternative.
This is especially so in pure Qt apps, if one does not want to use Linguist;
I personally would always pick pure Gettext over Linguist. It is only in KDE
apps that this choice didn't make much sense so far, given that KDE system
is Gettext-with-extras.

> nobody wants to have to figure out what libraryFoo uses for translation
> [...] and try to align their app with that.

Nobody should do this at all. Library's translation system should be its
internal bussines. This is the state since forever with libraries using pure
Gettext. The fact that this is not so with KDE-/Qt-based libraries is a
technical failure. And this failure is the absolute primary thing to fix for
Framework's translation module. (Ideas welcome, or else it's going to be
preprocessor macros! :)

> there is simply no way to justify the current state of affairs, other than
> "it's how it's always been done, it's already implemented".

I have a softer and a harder view on this.

The softer view is that there are and there will always be different
libraries covering same needs with a different approach. I consider this
good, in the long term even essential.

The harder view is that every translation system needs to justify its
existance next to pure Gettext. Justification for current KDE system is:
translation scripting. Justification for current Linguist is: none.

I tried to initiate merging of KDE system's extra features into Gettext
proper, but that failed so far, so we have to stick to a more specific
system.

> the only reason i can see to not move to QtScript is that the code using
> KJS is already written. i offered in the past to port this to QtScript,
> and that offer remains.

Right, that is the reason. I said that performance and maintainance are not
an issue at present, and I find it hard to take dependency as an issue as
long as KJS is part of Frameworks. It is beyond great that you offer to port
it yourself, but I don't see a solid reason yet.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20111206/5dd4c565/attachment.sig>