Ext.LocaleManager

[galdaka]

Loading script tags after the fact isn't going to be sync. You would have to do a sync Ajax call to the JS file. Unless you know of a way to load a script tag sync

Would be posible load json file in "loadAjaxRequest" and separate locale managment of server side language. What do you think?

[mitchellsimoens]

If you want locale to be sync... the only way I see to do it is via Ajax

[galdaka]

If you want locale to be sync... the only way I see to do it is via Ajax

Done. You can view in action in: www.jadacosta.es

I use JSON locale files and work fine!

Thanks for your help!!

[mitchellsimoens]

Seems to work great! Fantastic! Keep suggestions coming! Or you can fork the GitHub repo and do pull requests

[galdaka]

Only one suggestion. I would add specific configutation in your component if you want load JSON files intead JS files. Now I use this configuraton:

lm.setConfig({
     ajaxConfig : {
       method : 'GET',
       async  : false
     },
     path       :  lParam ? 'locale/locale_' + lParam + '.js' : 'locale/locale_es.js',
     type       : 'ajax'
  }); 

Would be great if I could use this one:

  lm.setConfig({
     ajaxConfig : {
       method : 'GET',
       async  : false
     },
     path       :  '/locale',
     type       : 'ajax',
    language:  lParam
  }); 

In "loadAjaxRequest" mode you can´t define "language" and "file" type mode.

I think would be more clean.

Thanks and greetings,

[koblass]

Hi,

What would be very nice is the ability to dynamically change the locale without any need to restart the application.

The idea of having a Ext.LocaleManager is great, but this manager should have a "change" event that is raised when the locale is changed. This LocaleManager should also provide methods methods in order to retrieved and set locale.

Like this every component would be able to add an event listener to the "change" event on the LocaleManager and then change its translation.

An instance of the LocaleManager should by created by default by the app, so like this all the ExtJs components that require translation (like datePicker) could be translated automatically, but we should keep in mind to be able to have multiple LocaleManager instances inside of our application in order to avoid key collision.

This is definitely something that has to be added in ExtJs if we want to be able to dynamically change the locale of the application, which is a must have !

Best
Daniel

[mitchellsimoens]

I have been brainstorming about this but I am worried about performance but I think I have something that may work at least.

[koblass]

Hi Mitchell,

I've bee working like this for years now with an other framework (bindows, not to mention), and they have a great BiStringBundle component that does the work.

Performances are not an issue at all and switching from one language to another is just instantaneous.
The only thing to keep in mind is to keep string bundles (locale dictionary) not too big, that's why we need to be able to create as many StringBundles or LocaleBundle as needed.

If I would do the component myself I would do it like this :

One Ext.LocaleManager which is a singleton. This LocaleManager is just in charge of keeping track of the loaded locale (language / country codes) and raising the "change" event when the locale changes.

Then have a StringBundle class or LocaleBundle, that is just a dictionary key/value, with a set of useful methods, like getString or getFormattedString (same thing, but with parameters)

The LocaleManager should have a collection o LocaleBundle that can be accessed by a getter and setter method.

Like this it would be easy to have something like this :

Ext.LocaleManager.get('Ext') // This will return the LocaleBundle stored under the "Ext" key

Ext.LocaleManager.addEventListener("change", ..... ); // The method will be called when the locale changes

// Be able to do the same directly on the LocaleBundle
Ext.LocaleManager.get('Ext').addEventListener("change", ..... );

// To store a new LocaleBundle
Ext.LocaleManager.add('myKey', new Ext.LocaleBundle(...));

The LocaleManager should also raise an event when we try to access to a LocaleBundle that is not loaded/defined. Like this, we can easily handle the loading of the LocaleBundle. Ideally a proxy should by defined in the LocaleManager, which would be in charge of loading the LocaleBundle from the server. Of course this proxy could be replaced in order to fit everybody's needs.


Hope to have helped you with this input and if you need any feedback, I would be happy to help.

Best
Daniel

[mitchellsimoens]

What do you mean a "bundle"? Like using the getter, it will return an Object of locale strings?

Using events is something that I hadn't thought of, amazingly. So the Component adds a change event and when fired, updates all the Component's things that need locale?

[koblass]

Hi Mitchell,

For be a bundle is just a dictionary component that provide a "change" event and two methods "getString" and "getFormattedString" (same method as getString, but takes parameters for injections within the translated string)

That's exactly how it works ! Events are fired and the components refresh their translations.

One important thing, is that the translation loading needs to be "on demand".
In order to perform this the LocaleManager is in charge of creating the LocaleBundle when requested and load asynchronously the translation regarding the locale. During this phase (when the translations are not loaded), the "getString" and "getFormattedString" method of the LocaleBundle return a default text (that should be present in the main LocalBundle for instance), like "Loading...". Then when the content of the LocaleBundle is loaded the "change" event should also be fired on this LocaleBundle object, so that the components who access to those translations can update themselves.

I thought a little bit about it this week end, and I think that we definitely need to have a proxy and a reader (a little bit like for the data package). Like this we can personalize the way the translations are received (use a webservice/json-rpc, etc...), and the way they are formatted (ini, json, etc...)

So basically, we should have 4 distinct classes. A Ext.LocaleManager, Ext.LocaleBundle, Ext.LocaleProxy and Ext.LocaleReader. (change the names accordingly of course)

Best regards
Daniel