Ext Localization Concept


First of all, if you haven’t yet read article Localization of Ext Applications, do not continue here but read it now please (or the example might not make any sense).

Now, this example is somehow different from others for other examples demonstrate how to use various aspects of Ext, best coding practices or practical solutions – they illustrate how to use what we have. This one shows what we could have. It tries to implement an ideal localization system and it is in the development stage of “concept proof.”

It is not complete and it has issues, nevertheless, when completed and debugged, it might become the localization platform we always dreamed of.

Note: The idea is not mine but, I think, Mitchell Simoens is the author of the fiddle that inspired me. I have simplified it and made it more coherent with the ideals I describe in the above article.

Live Demo

Open example in new window.

How it works

The entire system is implemented as overrides of many Ext components (and some other classes). This way it is separate from the main application that does not need any, or only a few changes.

There is a special setter created for every localizable class property that is responsible for translating the property value to another language. The properties for localization are listed in the new configuration option localeProperties:[] introduced by the overrides. The current locale is saved per each localizable property.

The translations are kept in a (configurable) store. The idea is that the records do not have ids that would be significant for the translation logic. When setter runs it searches the text in the current locale field and, if the record is found, uses the translation to the desired language. This way it is not necessary to change anything in the application texts. Also, there we can have many languages used at the same time.

It is also very easy to provide a grid for editing this store so translators must only translate plain texts without any programming constructs. They can translate on-line and see their work in action immediately.

New locale related methods are created by overrides: setLocale, getLocale and cascadeLocale.

Known issues

  1. The code is probably clumsy and it has not been optimized in any way.
  2. Localization of Ext.Date needs to be redesigned.
  3. Date Field and Date Picker need analysis and debugging. Note: Date picker is a very unfortunate, poorly written component. It would deserve a complete rewrite from scratch.
  4. List of columns in grid column menu does not translate reliably. Needs debugging.
  5. Message box and possibly also other components have not been addressed at all.

Example Files (relative to example root)

The example has been initially generated with sencha generate app in a workspace. The following list contains only the relevant files:

If you want to see the example code, login or sign-up. Free membership is available.
Follow me:


I'm a well seasoned developer, consultant and educator of web applications based mainly on Sencha libraries, PHP, MySQL and Node.js. Besides (Apple) computers, I love photography and mountain biking.
Follow me:

Latest posts by Saki (see all)


  1. David MacLean says

    Looks like you pretty much nailed it. Very nice.

    It uses a private property called “configurator”. Using privates makes me nervous but this is just “proof of concept” so I guess that could come. You got muscle at sencha, right ? 😉

    It certainly adds a level of complexity and maintenance, and more bulk to download. How easy will it be to track down changes when sencha releases 7? I do not think I would know how to build all of the overrides that you did. The sheer amount of code to be maintained gives me pause.

    I have a related issue: My server side (site-wide, app-wide) phrase table is 16Mb and growing. Problem is: how to extract all and only the strings used in the final build? Currently each string is of the form __(‘Hello’) or LANG.Hello, so I have utilities that know how to extract language strings from the build, then generate a json resource from the server-side master table. With this solution, I no longer know how to get a list of every string I need to supply. Need to think about that. Brilliant suggestions welcome.

    Much as I love the instant switching, I may need to load by language, again because there are too many languages, too much data (and in reality, very few users will switch at runtime). This will still be much more impressive than a page refresh. Future builds please bear in mind, not all languages will be loaded initially.

    Finally I worry about the freedom to correct punctuation, spelling and wording on the fly. I want to make those corrections as I go (it was among our requirements), but I will forget I made a change almost instantly. Now the lookup key is broken, all other languages will revert to English. With freedom comes great responsibility (who said that), and it is a responsibility I don’t want. There needs to be an automated step to catch my changes so the mapping between a modified phrase and all the translations stays intact. Or discipline? Or another idea?

    I cannot help but think my issue is about extracting translatable strings from the built app, so that I may then run utilities and verification using the master resource. This is where I get on my “Why can’t Cmd do it” bandwagon. I like this solution, but it takes away my “marker” that let me know a phrase is required/was used in code. And yes that was part of what we wanted. Well like most “clients”, in the end it turns out I want it both ways, Ha!

    It is not ready to run standalone, the current implementation requires the resource. We missed that requirement. I assume the fix is easy. But we want it in from the start 😉

    Thought-provoking stuff. I am very glad to subscribe. Thank you Saki.

  2. says

    Hi David,

    thank you for your thorough analysis and the description of your requirements in real-life. I haven’t thought of several points such as text extraction, on-demand language loading and corrections on the fly.

    I’m not in the acute need of a localization (it may change in the near future) so I don’t plan invest into it immediately. Of course, once a question is asked, an answer can come at any time – you have asked valid valuable questions so if something comes to my mind in this area I’ll post back here.


  3. Michael Wong says

    Hi Saki,

    I bought this solution for my project, and I must say it is worth every penny!

    I have one issue though…

    I found that cascadeLocale() does not localise the “emptyText” of text field, I tried adding “emptyText” to localeProperties as below…

    Ext.define(‘Ext.overrides.form.field.Text’, {
    override : ‘Ext.form.field.Text’,

    localeProperties : [

    but got the following error…

    Uncaught TypeError: instance[names.set] is not a function

    Any idea how to fix it?


  4. Claudia Bressi says

    Hi Saki,

    Do you know a possible hint on how to address the MessageBox component as well you did for ComboBox ? Would it be feasible to write a similar override settting significant properties ?

    Kind regards,

    • says

      Ext.MsgBox (other name is Ext.MessageBox) is a singleton so it’s not enough to override the class (Ext.window.MessageBox) but you have to re-create it. Something like:

      Ext.MessageBox = Ext.Msg = Ext.create('Ext.window.MessageBox');

We will be happy to hear back from you

Please Login to post a comment