Kind of - I think there’s a mistake in your JSON for ru.cows, or in ru.po,
should it be:
translations: {
"es": {
"cow": "vaca",
"cows": "vacas"
},
"ru": {
"cow": "korova",
"cows": [ "korovy", "korov" ]
}
}
Or should the ru.po be:
msgid "cow"
msgid_plural "cows"
Hi Dimitri,
On Tue, 23 Feb 2016, Dimitri wrote:
> Re: msgstr array - I think that's gonna be a good start. Let's
> implement it that way and see what qooxdoo guys say.
"qooxdoo guys" is an at best poorly defined concept nowadays ... ;-)
Cheers,
Fritz
--
Oetiker+Partner AG tel:
Hi John,
Re: msgstr array - I think that's gonna be a good start. Let's
implement it that way and see what qooxdoo guys say. A verbose example
to make sure I understood it right:
es.po:
msgid "cow"
msgid_plural "cows"
msgstr[0] "vaca"
msgstr[1] "vacas"
ru.po:
msgid "cow"
msgid_plural "cows"
Hi Dimitri
Re multi-line: OK, I see the error now: that’s a bug in my book :) I’ll get
onto it
Re msgstr as array: how about if msgstr is an array only if there is more than
one value to output? The advantage would be that the generator.py can still
output code which is compatible with the
John,
Translations seem to work fine now, thanks!
I'm OK with the headers approach, and I'm eager to fiddle with
qx.locale.* stuff. However, two things are yet to be done on the side
of toolchain:
1. (minor priority) Support multi-line headers. Typical PO header for
Russian localization looks
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
Thumbs up! "Make qooxdoo great again" ;)
P.S. Could you please elaborate a bit on what projects you are using
qooxdoo in? Ours is a communication application (think web-based Pidgin
embeddable into virtually any website).
> Dimitri,
>
> I think it is a good idea.
> We have developed language
Dimitri,
I think it is a good idea.
We have developed language support for different "direction" languages...not
only LTR instead including RTL, TB, BT, MTR etc. It also includes different
calendars etc...
It might be something we could include in that package and then make a pull
request on
Hi Dimitry,
Today Dimitri wrote:
[...]
> 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",
>
