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##SELECTION_END##. 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
