Localization with build-all

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Localization with build-all

Varol Okan
Hey,

I am using QooxDoo with the Desktop libs, which I compiled using "./generate.py build-all"

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

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.

What is the proper way to get E.g. the Date format of a Locale when using "build-all" ?

Thanks in advance.

Varol :)
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Localization with build-all

Thomas Herchenroeder
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).


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

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



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?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Localization with build-all

Varol Okan
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 ?

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

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

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.




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

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Localization with build-all

Thomas Herchenroeder
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Localization with build-all

dfrost999
This post has NOT been accepted by the mailing list yet.
In reply to this post by Varol Okan
Hey Varol,

did you manage to solve your locale-problem with build-all?
I have the same problem (and I think Mr. T is being cheeky by pretending build-all doesn't exist ;))
I tried defining LOCALES in config.json but the entry seems to get ignored...

config.json:
...
"jobs":
...
  "build-all":
...
      "let" :
      {
        "LOCALES" : ["de", "de_DE"]
      },
...

Cheers,

Deacon