add qx translation

[hkollmann]

to extract *.po files. Similar to generate translation

[cajus]

That is already done automatically. The .po files are extracted and updated by the compiler.

[hkollmann]

Then there is missing some doc.

qx create test -I cd test

add "de" to locales: "locales": ["en", "de"],

run qx compile

i can't find any po file?

[cboulanger]

see https://github.com/qooxdoo/qooxdoo-cli/issues/38#issuecomment-346944443

[johnspackman]

You need to be calling this.tr("myMessageId"), that's how the compiler finds the message and know to generate a translation for it

[hkollmann]

ok, got it. I'll change the text in readme.txt of the skeletons

[cboulanger]

@johnspackman has noted that "de", "en" etc. won't work anyways because the compiler requires "real" locale codes such as "de_DE" etc.

a) This seems to be not BC with existing applications, which use only two-letter locales b) we need to validate locales in qx create and ideally, use the same locale data that qxcompiler uses to validate entries. @johnspackman, is there a way to use the qxcompiler API to get this data easily?

[cajus]

@cboulanger existing applications use both, two-letter and combined locale definitions. de is for de* (i.e. it catches de-AT and de-DE if they don't exist.

[cboulanger]

@cajus Ah ok, thank you. I didn't know that.

[cajus]

Just checked with an existing one. Current correct spelling would be en_US for american english. So dash vs underline.

[cboulanger]

But won't two-letter code apps break with the new compiler, @johnspackman? If so we need to remember to provide an upgrade.

[cajus]

I don't know the state of the Part support in qx-compiler, but that's also a must have:

"i18n-as-parts" : true

is present in the current generator. It can bundle locales as parts - which makes sense if you've 25 locales with ~200k each.

[johnspackman]

@cboulanger No, what happens is that if you just specify the language you will only get the default localisation settings for that language; this means that "en" will always return a date format "m/d/y" because the defaults happen to be US-centric (for dates anyway). It works but it's wrong (unless you happen to be in the US). If you specify "en_GB", the GB localisation data for "en" is loaded on top of the "en" data, overriding those "en" defaults.

It means though that you have to know in advance which language/locale combinations you want to support, so that the generator/compiler knows to extract the data it requires and insert it into the boot loader.

@cajus the i18n-as-parts is not in compiler at the moment, however it only loads a tiny subset of locale data is provided with the app - the entire "en" language is 4,698 bytes (pretty printed, un-minimized JSON data), and the "en_GB" specialization is another 1,858 bytes. When minimized, "en" and "en_GB" combined come to 4,782 bytes.

[cajus]

@johnspackman yes, but if you have large translations, it's a problem. Or at least a waste of resources. For one application I've more than 4MB of translations. If this is pulled in at a time, 1/25 is used. 24/25 are wasted and would be loaded.

@hkollmann just deleted my de.po and it's getting re-generated upon qx compile. The contents is not valid in the moment, because qooxdoo-compiler needs an update on npm AFAIK.

[johnspackman]

ah, yes I see what you mean! That's not supported yet but it needs to be. I'll create an issue

[cajus]

Maybe it would be nice to have a seperate command to extract the translations (i.e. qx translate). Most of the time, you don't want qx compile make that.

[johnspackman]

This issue was moved to qooxdoo/qooxdoo-compiler#85