i18n in Frameworks, the lightweight version

[Chusslove Illich]

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.

3) Linguist should be "fully" integrated into "Scripty". By "fully" I mean
that the application maintainer should only see TS files all the time, but
translators should work on PO regardless. By "Scripty" I mean whatever
automation on the side of KDE Translation Project. It would be great if
someone else could be convinced to make this possible, but if not, I would
do it.

4) KDE Frameworks translation system would pretty much remain as it is now,
only provided by a standalone Frameworks component. At the moment I would
*not* go for the system I proposed at http://nedohodnik.net/gettextbis/,
because its main advantage would be generality over all programming
languages/foundations, and this elicited no third-party interest so far.
Without generality as the main pusher, the rest does not warrant a forced
habit shock upon all KDE programmers.

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

-- 
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/20111205/e90014df/attachment.sig>