Ext.LocaleManager

[mitchellsimoens]

Want to dynamically load locale files? Ext.LocaleManager can load a JS script tag on the fly.

Want to refer to locale text easily in your application? Ext.LocaleManager has a simple get method that you can use to access locale text even if the text is nested.

https://github.com/mitchellsimoens/Ext.LocaleManager

Easy to setup and use:

Ext.LocaleManager.setConfig({
    language : 'en',      //default is 'en'
    ns       : 'locale',  //default is 'locale'
    path     : '/locale'  //default is 'locale'
});

Ext.onReady(function() {
    var callback = function(manager) {
        console.log(manager.get('helpText'));
        console.log(manager.get('button.action'));
    };

    Ext.LocaleManager.loadLocale(callback);
});

Sample locale looks like:

{
    helpText : 'Click me for help',
    buttons  : {
        action : 'Action'
    }
}

On my wishlist:

• Get into the Ext JS 4.x framework
• Support Ajax loading, not just script tag loading (Added 8/5/11)
• More advanced locale settings like date differences

Updated (8/5/11):

• Ajax support! (need feedback)
• Default text parameter on get method
• New Ajax example
• Update Simple example to show default text usage
• Updated MVC app example to have a language ComboBox

[Dumbledore]

Nice! I will implement this in my application...

[Dumbledore]

just an idea... it will better to have a default value like this...

    Ext.LocaleManager.get('fields.title', 'My Title');

[mitchellsimoens]

I like that idea. Tonight I will be working on this some more to include Ajax support and will fold this in. This suggestion to add will not hard at all

Keep up the suggestions! So far this is very simplistic but very needed IMO.

[mitchellsimoens]

Here are some changes I just made:

• Ajax support! (need feedback)
• Default text parameter on get method
• New Ajax example
• Update Simple example to show default text usage
• Updated MVC app example to have a language ComboBox

As always, let me know so I can keep improving!

[Henrik Rutzou]

Hi,

here is another way that I use in v3.3:

Translation of general text used in controllers is done in the browser by adding a javascript file with the appropriate language:

1. A simple javascript translate file are included in the main page:

function i18n(translate) {            
 switch (translate) {                 
                                      
  case 'Search'   : return 'Søg';    
  case 'Search:'  : return 'Søg:';  
  case 'Create'   : return 'Opret';   
.....
                                   
  // Return Default Value          
  default : return translate;      
 }                                 
}                                  


2. Example of code in the Controller:

{xtype:'label'
   ,text: i18n('Search:')
   ,cls: 'ytb-text'
}

For i18n translation of text in forms, grids, combo's and even data, dateformats and punctuation is done on the server because I use templates and metadata and all view's are generated "on the fly" by the server based on what language the user selected on the session, what design the user has been set up to and the rules for the user or the user group he belongs to:

http://216.109.205.54/pextcgi/pxdctemp.pgm?template=date

The server can be set in collection mode and will collect all text used by an application in a table where it can be "raw" translated using google translate api and then afterwards manually adjusted.

[mberrie]

Hi mitchell,

I have been thinking about the asynchronous character of the load operation in LocaleManager.

I can see that you trigger the load in Application.launch and then delay the viewport creation until the locale data has been loaded.

IMHO the LocaleManager should trigger the file loading earlier in the application load process and then delay execution of Application#launch until the data is loaded.
Of course this is an optimization that might not be required at this stage in development.

Another issue I see is that you cannot use LocaleManager as part of the class definition, e.g.
[CODE]
Ext.define('MyPanel', {
extend: 'Ext.panel.Panel',

title: Ext.LocaleManager.get('mypanel.title');
});

but have to defer calls to LM#get() to within the constructor/initComponent or later.


I wonder if it would make sense to load the language data in a blocking script tag that would guarantee that the data is loaded and LocaleManager is ready to serve requests long before Ext.onReady().

Changing the language at runtime is nice. Is it safe to use viewport.destroy() and re-launch the application?

What do you think?

[mitchellsimoens]

They way I did it was the easiest instead of hacking Ext.app.Application.

About not being able to define title, why not put the all locale text into initComponent or constructor?

You don't need to destroy your Viewport... just remove and add items.

[mberrie]

About not being able to define title, why not put the all locale text into initComponent or constructor?

Sure that's what I meant by writing this:

Another issue I see is that you cannot use LocaleManager as part of the class definition [...] but have to defer calls to LM#get() to within the constructor/initComponent or later.

It would be more robust if LocaleManager didn't have this restriction.

IMHO localization is a very low level service in terms of application infrastructure, and should be available also for configs that are passed to Ext.define.

However, a downside of this would be that switching language by re-creating the UI components (destroy and relaunch) would not affect those localized values because the class definition itself is not re-executed.


I still worry that switching the language this way asks for troubles with tangled objects etc. Do you know what the lifecycle of controllers is in this scenario.
Looking at your MVC example app, the controllers are correctly bound to the new viewport. That's neat!
Will the call to Application#launch cause new instances of controllers to be created, and if so, what happens to the old ones.

Just trying to give feedback here!

[mitchellsimoens]

You say localization is low level except when you have to support it, it's actually very important. If you define things like title in initComponent and the LocaleManager has been loaded, you don't have any problems then.

The launch method won't be called again as it's only called once like onReady would be so no worries there. That being said, getController will first look to see if the controller exists, if not it will create it. Same goes for getStore and the others.