i18n in Frameworks, the lightweight version

[Aaron J. Seigo]

On Monday, December 5, 2011 12:23:30 Chusslove Illich wrote:
> Regarding yesterday's chat, to shortly (really!) sum up my stance on i18n.
> 
> 1) I see no point at striving for single translation system for apps based
> on Qt and Qt plus KDE Frameworks. Qt should keep the tr()/Linguist system,
> and Frameworks should continue to offer the i18n()/PO system.
> 
> 2) The application developer would choose which translation system to use
> based on whatever criteria, like choosing between any other two libraries
> covering the same need. We could put up an article describing the relative
> advantages of the two systems.

that is precisely the problem. nobody wants to choose between two translation 
systems. nobody wants to have to figure out what libraryFoo uses for 
translation (that one uses tr, this one use i18n, this other one also uses 
i18n, that one uses tr ..) and try to align their app with that.

on the device side, i certainly do not want the overhead of two translation 
systems.

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".

> 5) KDE i18n currently uses KJS. I saw that KJS will be a tier 1 component,
> and if I recall tier 1 components must not depend on other tier 1
> components -- that would make i18n tier 2, right? If so, is that actually
> bad? Is i18n needed in other tier 1 components? The alternative is of course
> to port to QtScript, but I wouldn't want to do it right now without an
> organization-related reason (i.e. considering performance/extension-API
> irrelevant for the moment).

the reason to move to QtScript is pretty straight forward: the code would be a 
lot cleaner, likely more performant and we would lose a dependency that is 
redundant with what is provided in Qt.

we also have more people who are deeply familiar with using QtScript.

from a dependencies perspective, it makes sense.
from a performance perspective, it makes sense.
from a maintenance perspective, it makes sense.

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.

looking at:

http://techbase.kde.org/Localization/Concepts/Transcript#The_Transcript_Interface

there are ~30 function calls and the one Ts object in the javascript 
namespace. that is not a large amount of work.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20111206/4ba2d9dd/attachment.sig>