> [: Axel Hecht :] > While looking at our status quo at Mozilla, and looking at other > attempts, I'm seeing limitations in both what we can do and what > others can do, and came up with an alternative proposal [...] > [...] a solution for plain strings of course, but plurals and > declensions, too. [...] > This proposal is done with Mozilla on my mind, but it is in no way > limited to Mozilla [...] I'm brewing a similar concept for some time, to be used in KDE4, albeit at a less ambitious scale: on top of existing gettext universe, with as little disturbance as possible, bolt a system which provides message arguments with the text itself, and a known scripting language to operate on them at runtime. Here is a bit outdated proposal, but the concept is still the same: http://caslav.gmxhome.de/writings/ktranscript.html Section "Using The Scripting System" is Gettext-translator oriented, while others are more on KDE implementation (though, the "Performance considerations" might also be interesting). However, there is nothing KDE essential to the system, it could be made as an independent library (ie. only Gettext + scripting engine dependent) with language bindings. In the meantime, as opposed to the document above, the scripting engine will likely switch from Guile to KJS, a JavaScript implementation already built into kdelibs. And the new KDE4 i18n API, which can support this system under the hood, can be seen at: http://api.kde.org/cvs-api/kdelibs-apidocs/kdecore/html/classKLocalizedString.html From programmer's point of view, the API is no more complicated than ordinary gettext (section "General Usage"); note that QStrings in the examples are run-of-the-mill Qt/KDE strings, they have nothing to do with the i18n system. The more complicated calls (section "Specialized Usage") are present for handling some rare cases described therein. Also note that there is no mention of translation scripting in the i18n API itself -- these are now sufficiently decoupled, so that any changes to translation-side system can be made without breaking binary compatibility of KDE library. KDE4 can thus field test the viability of these new, "live" I would call them, translation concepts. > All of this is new enough to take Localization from version 1.0 to 2.0 > (yeah, I'm all web 2.0), so I took the freedom to codename this l20n. > Pronounced l-twenty, I drop the 'n'. Aren't we all in codenames -- I call mine "Transcript" :) (On a side note, I too started with an idea replacing venerable PO format itself, but have been wisely suggested to go along a cohabitative path; this was my first take, late 2003: http://caslav.gmxhome.de/writings/cotras-intro.html ) -- Chusslove Illich (Часлав Илић)
Attachment:
pgp4sxSQmA9XR.pgp
Description: PGP signature