I think that the only thing missing from the toolchain to support this is being
able to include the headers from the translation in the compiled application;
I’ve just pushed a version of QxCompiler that now adds this.
I have not done the corresponding changes to qx.locale.Manager because it’s
probably easier for you to mod that :) but at least the data is ready when you
have a moment. In qx.locale.Manager, the data is available at
this.__translations[locale + ":__header__"] or globally as
qx.$$translations[locale + ":__header__”].
I’m not 100% sure that this is the best way to output the header information,
so if you want a different layout let me know or take a look at
qxcompiler.targets.Target on lines 328 to 343:
function(cb) {
async.each(t.getLocales(),
function(localeId, cb) {
analyser.getTranslation(library, localeId, function(err, translation) {
if (err)
return cb(err);
var dest = pkgdata.translations[localeId + ":__header__"] = {};
var src = translation.getHeaders();
for (var key in src)
dest[key] = src[key];
cb();
});
},
cb);
},
Note that there is another change in this release of QxCompiler that changes
the directory names inside source-output (more on that in a moment) so it’s
best to delete the source-output directory before you try again.
John
From: Dimitri <mi...@cargosoft.ru>
Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Date: Monday, 22 February 2016 at 16:42
To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net>
Subject: [qooxdoo-devel] Supporting multiple plural forms in translations
In qooxdoo's translation mechanism, multiple plural forms are not supported.
The corresponding issue has been reported almost 10 years ago. Time to revise
it?
This is essential for many languages, eg. of Baltic and Slavic families.
Contrary to English, these languages may have, say, one plural form to denote
2, 3,4 items and another for >=5 items. For example, let's take the word
"korova" ("cow" in Russian and Ukrainian):
1 korova [singluar]
2,3,4 korovy [plural 1]
5-20 korov [plural 2]
21,31,41... korova [plural equals to singular]
22,23,24 korovy
25-30 korov etc.
The original GNU gettext (which qooxdoo's translation facility is modeled
after) provides such a mechanism. There is a special "Plural-Forms" PO file
header that contains:
- total number of plural forms;
- a formula to factorize ordinals into classes of plurals. msgstr lookup is
then done based on the plural class (the result of evaluation of the formula),
rather than on the ordinal itself.
For Russian, Ukrainian, Belarusian, Serbian and Croatian, the formula looks
like this:
Plural-Forms: nplurals=3;plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4
&& (n%100<10 || n%100>=20) ? 1 : 2;
With the above, the translation itself would look like this (transliterated for
better perception):
msgid "cow"
msgid_plural "cows"
msgstr[0] "korova"
msgstr[1] "korovy"
msgstr[2] "korov"
Per specification, the formula should be a valid C language expression, limited
to one variable (n).
It would be nice to have it implemented in qooxdoo. However, that would require
changes in both framework and toolchain. At the moment, internal translations
structure looks like that:
translations: {
...
"ru": {
"cow": "korova",
"cows": "korovy"
}
}
This could be changed to:
translations: {
...
"ru": {
"cow": "korova",
"cows": [ "korova", "korovy", "korov" ]
}
}
and locales structure could contain a function to compute plural form from
ordinal, created from a Plural-Forms PO header by the compiler. A valid C
expression will be a valid JavaScript expression, too, and we can benefit from
this. I've examined several gettext implementations for JavaScript; those that
do support Plural-Forms simply evaluate this expression unchanged as
JavaScript. For security purposes, we could validate the expression first, to
make sure it is restricted to arithmetic, logical and ternary operators.
I think that we could start with implementing minimal, non-breaking changes in
framework, namely internal structure for translations, plural classifier in
locales, translation logic in tr*() functions. Meanwhile, we could experiment
with John Spackman's QxCompiler to introduce Plural-Form parsing. As soon as
POC is ready, it can be ported to generate.py or Grunt based toolchain,
whichever becomes mainstream at that moment.
John, guys, what do you think?
Dimitri
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end
web transactions and take corrective actions now Troubleshoot faster and
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________
qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
