ExtJS MVC, dynamic loading and i18n

Question

I would like to translate my ExtJS application in different languages. My issue is that I'm using ExtJS MVC framework, and most of my JS files are downloaded dynamically by the framework itself.

The ideal solution (that I thought of) would be to have an extra option in the Ext.Loader (or in my Ext.app.Application) that would define the language to use, and depending on this to automatically download such file as "a.MyClass.fr.js" after loading my "a.MyClass.js" (which would contain an Ext.apply, overriding my string resources). That's probably not available in the ExtJS framework at the moment.

The alternative solution I can see, is to perform a trick on the server-side. First, a cookie would be created on the client, to set to the language. On the server-side, I could catch all the requests to JS files, then if a cookie is set (='fr' for example), I'd combine the requested JS file (MyClass.js) with its i18n's friend (MyClass.fr.js) dynamically on the server and return the result. That would work, but it's really tricky because it implies other things (caching...).

Maybe the best way is to implement the first behavior I described in the ExtJS framework myself...

What do you think? I'm looking for a really clean and neat way of doing it! Thanks :)

Answer 1

I recently struggled with the same problem.

Finding a clean way to do this was quite a challenge - most alternatives were either..

1) Duplicate your code base per locale (WTH)

2) Download localized files overriding each of your components (Maintenance hell? What about the poor translators?)

3) Use/generate a static file containing translations and refer to it (All languages are downloaded? Extra build step to generate it? How do you keep them in synch?)

I tried to get the best of all worlds and ended up with a utility class responsible for:

1) Loading the ExtJS translation files (which basically apply overrides to extjs base components)

2) Loading a locale specific property resourcebundle (specifying which locale to load) from the server.

3) Prototyping String with a translate() method which queries the loaded store (containing the message bundle from the server) and returns the translation based on the value of the string.

This is the gist of things:

Bundle & prototyping:

localeStore.load({
    callback : function(records, operation, success) {
        // Define translation function (NB! Must be defined before any components which want to use it.)
        function translate() {
            var record = localeStore.getById(this.valueOf()) ;
            if(record === null) {
                alert('Missing translation for: ' + this.valueOf()); // Key is not found in the corresponding messages_<locale>.properties file.
                return this.valueOf(); // Return key name as placeholder
            } else {
                var value = record.get('value');
            }
            return value;
        }

        String.prototype.translate = translate;
        callback.call(); // call back to caller(app.js / Ext.Application), loading rest of application
    }
});

As an example from a view:

this.copyButton = Ext.create('Ext.button.Button', {
    disabled: true,
    text: 'DOCUMENT_LIBRARY_MENU_COPYTO_BUTTON'.translate(),
    action: 'openCopyDialog'
});

Bundle on the server (mesages_en.properties): DOCUMENT_LIBRARY_MENU_COPYTO_BUTTON=Copy file etc..

Pros:

• No-fuss code, 'Your_key'.translate() makes it easy to read and aware that this is a localized string
• None/little maintenance overhead (Keeping an override file for each locale? Jesus..)
• You only load the locale you need - not the whole shabang.
• If you really want to, you could even have your own translation for the ExtJS locale files in the same bundle.
• You could write unit tests to ensure that all bundles contain the same keys, thus avoiding orphaned translations later

Cons:

• Synchronous - the store must be loaded before your main app starts. I solved this by adding a callback from the utility class which was called once all texts were loaded.
• No real-time population of texts.. though I didn't want to make my users overload the server either :P

So far my approach has worked out pretty well for my requirements. Site load isn't noticeably slower and the bundles (containing ~200 keys/values per bundle) measure out at ~10kb during load.