> But this doesn't yet work for the official 1.1 release, I think. > At least the case of the generator failing on marked expressions. > I'm excited for the new release in that case :-)
You have to check Bugzilla to find the exact revision when it went in, but yes, it will be in the 1.2 release. > >>This, too, already exists: qx.locale.Manager.addTranslation(). > > Is the format of the map we supply here documented anywhere? It's just key-value pairs, the key being the message id, the value the translated string. > How is the plural case formatted in such a map, for example? Plural forms are just separate keys. > Does it remove the translations already available, or simple 'add to it' ? Good question, I don't know. You have to try it out or read the code. When you found out, send a patch for the docs. > > 1. Generating forms based on information about the structure from the > backend. The form-labels need to be translated, but aren't marked in the > application. It's the backend that decides with fields to show, and > tells the application what the fields are called and what type of > validation needs to be applied. Ok, so you would use .addTranslation() to add the new keys with their translation strings (assuming it actually adds, which I would expect) before adding the widget that uses the key. > > Workarounds i've used here is: > - provide translated labels together from the backend when fetching > form-structures. Negatives: i have two places where there are > translations and i can't dynamically change the locale anymore. Mh, I don't get that. As you say the client app doesn't even know in advance which labels are being used (as they are dynamically provided by the backend), there is no other way than the backend providing the keys together with their translations, is there?! And with a switch of locale, the backend has to provide the appropriate new translations. > 3. Needing the customer to be able to alter the translations on the fly. > Just like with any other CMS. The focus here is not the translation > itself, but the fact that the choice of words is something that needs to > be configurable. I haven't hit this one yet, because I haven't made a > public based qooxdoo site. (it's usually incompatible with SEO > requirements anyways) But I would hit it as soon as I would make a > public site, and typical customers have communication "experts" that > reconsider every publicly readable string of text every day. (don't ask > me why). The translation has to come from a database in this setup and > part of the application is managing the translations. That means you want to have the GUI editable in a way, right?! I don't see why this should not work with .addTranslation() as well (again, assuming it supports merging/overwriting of translation keys). > But the idea is the same. From the above definition: > - we infer a database migration (comparing it with the current schema > and suggesting a migration script) > - a json file with the structure of all tables and their fields (this > file is loaded by the qooxdoo-based application) > - we get the same validation in both the client and the back-end So you are using the built qooxdoo app not as a GUI, but as a GUI-engine that is actually Json-driven. I wouldn't call this out-of-line with the qooxdoo 'philosophy', but yes, it is an unusual use case for us. But others are also pushing the borders of what you can do with qooxdoo (e.g. RAP, qxTransformer, ...). > As for translations, I think you can imagine the problem with using a > .POT file and marked strings. > Fortunately it sounds like, with the new release, I can use the > localisation support for my own strings as well. > And just create a json database dump that I feed > to qx.locale.Manager.addTranslation(). Good :). T. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
