On 10/21/2013 11:35 AM, Varol Okan wrote: > Mr T. > > Thanks for your answer please see below. > > Another question I now have is : > how does "./generate.py translate" pull out the required strings > from the source code ?
It traverses the source code of the classes, locates calls to 'tr', 'trn', ... and extracts the first argument. For this to work, the first argument has to be a literal string, like "foo". Variable references won't work, and the generator will warn about them. > > Thanks, > > Varol > > On 10/21/2013 03:59 AM, thron7 wrote: >> On 10/19/2013 05:55 PM, Varol Okan wrote: >>> Hey, >>> >>> I am using QooxDoo with the Desktop libs, which I compiled using >>> "./generate.py build-all" >> >> What is "build-all"? (It's none of the predefined jobs). > "build-all" is what saves my project and what allowed me to port it > from 0.7.4 top 3.0.1. You have to un-comment that line in config.json I've never heard of such a job, and I'm pretty sure none of the recent qooxdoo releases contained it. Where did you get this config.json from? >>> >>> All is fine and nice however I am trying to figure out how to >>> localize my app and for the Deutsches mgr.getDateFormat () all I get >>> back is "M/d/yy" instead of "dd.MM.yy" as is in the example under >>> http://demo.qooxdoo.org/current/demobrowser/#showcase~Localization.html >>> <http://demo.qooxdoo.org/current/demobrowser/#showcase%7ELocalization.html> >> >> It seems you have an 'en' locale in effect when calling >> Date.getDateFormat(). Either supply a locale parameter like >> .getDateFormat('short', 'de') (for a one-shot query), or set the >> locale for the app to 'de' and then invoke .getDateFormat('short'). >> See [1] (make sure to open the 'Log' pane in Playground). >> >> [1] http://tinyurl.com/k3mv53g > Thanks, > > I copied the code over to my app and still get "M/d/yy" :( > BTW I have "LOCALES" : [ "de", "en" ], set in config.json but it > seems the resulting javascript file does not change when I add/remove > language defs. For one you should be using the 'source' version of your app for all debugging purposes. 'source' gives you much more hints and additional infos which are disabled in the 'build' version. So you should e.g. run 'generate.py source-all' to build your app. Then, in the browser open the browser console (like Chrome's 'Developer Tools' or Firefox' 'Firebug'). You can enter interactive commands to inspect your application: qx.locale.Manager.getInstance().getAvailableLocales() ... should allow you to verify that the registered locales are 'de' and 'en'. If this is not the case, check where your LOCALES is defined. Is it in the top-level "let" section of your config.json? > >> >> >>> >>> I can of course add this manually to the >>> this.__locales["de"]["cldr_date_format_short"] in qx.locale.Manager >>> >>> though that would be hacking the system. >> >> Indeed. >> >>> >>> What is the proper way to get E.g. the Date format of a Locale when >>> using "build-all" ? >> >> See above. It usually doesn't depend on the type of build you are >> creating. >> >>> Ps: is this a bug on line 402, as language is used further down >>> https://github.com/qooxdoo/qooxdoo/blob/release_3_0_1/framework/source/class/qx/locale/Manager.js#L402 >> >> No - why? > Coming from C++, "var language" would go out of scope in case "locale" > is set. Actually the compiler would simply optimize it out. This would > cause line 416 "if (!txt && catalog[language]) {" to break Mh. For one thing, JavaScript doesn't have block-scope, so "... { var x ... }..." doesn't restrict x' visibility to the enclosing block. Rather, all variables declared with 'var' are visible in the *entire* function that encloses them - even *before* the 'var' declaration (this is called 'hoisting'). One of the idioms you will find in JS code is that the 'var' declaration is used on the first occurrence of the variable, as in this case. Think of it as if 'var language' had been written at the very beginning of the function block (l.390). All other references to 'language' will refer to this same variable, wherever they appear in the function body. So the 'language' variable is defined in the entire __lookupAndExpand function, has value 'undefined' before l.401, and has some defined value after l.408 (as both branches of the 'if' assigne a value to it). T. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
