Different languages/Translations

[jturle]

I can't seem to get it working with the output from Sencha Architect... Has anyone had any luck? I'm using 2.0.0-beta3.

Cheers.

JT

[ssamayoa]

What you mean?

Sencha Architect 2.0.0-beta3?

Sencha Architect is already released and current version is 2.0.o build 412.

[m@rcello]

We plan to add multi lang support further in the road map. We don't support it directly as of yet

Hi Phil,
do you have a planned date for this feature?
Thanks,
Marcello

[Phil.Strong]

There are no dates set for this feature. Others on the forum have come up with some pretty promising solutions however.

[apsq]

Sencha obviously didn't develop the frameworks with I18N/translation in mind. Strings in component definitions are treated as strings (rather than, say, getters) and need to be set before the component is initialized and rendered; the text won't update automatically.

There are two ways to go about this really:

1. Static translation. You write a script which runs over the generated JS files and does a string replace (e.g. by using translation keys with a common prefix). You need to do this every time you export from ExtDesigner/Architect.

2. Dynamic translation. The strings are translated automatically as the components are initialized.

We have been going with approach #1 in a previous project. As Architect 2 now seems to generate the files on every save, however, we have been looking into a way to approach #2. We wanted to wait for Architect 2 because we were told translation would be addressed "soon", but apparently that's a stretch.

Here's what we did:

Every JS file generated by Architect applies the properties by calling Ext.applyIf. You can hook into that (assign Ext.applyIf to a private variable and assign a new function to Ext.applyIf that does some magic before calling the original) and iterate over the passed config object recursively, doing a pattern match on any strings you find. You will hit a recursion limit if you do this the obvious way (i.e. use recursion), so you need to work around that.

I think there may be cases where the configuration will be in what's passed to Ext.define or Ext.create itself, so you may need to override those, too.

I'm not entirely sure where to place this code as JS resource files added in Architect seem to be loaded *after* the application (i.e. when all the Ext.applyIf/etc calls have already been made), but I'm sure there's a way to sort this out.

All this wouldn't be necessary if Architect allowed inserting arbitrary code instead of strings because we could then simply put a function call instead of a string, but as Architect uses JSON literals to define components, I'm not sure this would be possible without breaking compatibility with the current XDS format.

In any case, keep in mind that the changes likely won't show up in Architect itself as you're applying these changes at runtime.

EDIT: Note that there are examples for I18N with ExtJS 4. They completely rely on implementing the translation on the server side or otherwise manipulating the application state before runtime. There is no way to change the locale at runtime without regenerating the entire DOM and possibly redefining various components. This behaviour is due to the way ExtJS was designed.

[ssamayoa]

2. Dynamic translation

I would prefer dynamic translation "a la" gettext on already instantiated components.
This is more easy than post-processings generated JS files and allows you to change language at run time and (not confirmed yet) without the need of redefining components.

Look for a project I posted few weeks ago.

Regards.

[apsq]

Here's my implementation for a function to apply a function to each and every property to an object recursively without running into recursion depth errors:

    function convert(object, func) {
        var
            result = [],
            visited = [],
            input = [object],
            temp;

        while (input.length) {
            // poor man's unrolled recursion
            temp = input;
            input = [];
            Ext.Array.each(temp, function(object) {
                if (!Ext.isArray(object) && !Ext.isObject(object)) {
                    // we don't want to touch any properties of things
                    // that aren't trivial data structures.
                    return;
                }
                Ext.Array.each(Ext.Object.getKeys(object), function(key) {
                    var value = object[key];
                    if (visited.indexOf(value) === -1 && !func(value, key, object)) {
                        value = object[key];
                        visited.push(value);
                        input.push(value);
                    }
                });
            });
        }
    }

You can supply a function(value, key, object) like such:

     function func(value, key, object) {
        var matches;
        if (typeof value === 'string') {
            matches = /i18n:(.+)/.exec(value);
            if (matches) {
               object[key] = _(matches[1]);
            }
            return true;
        }
        return false;
    }

(I'm assuming your gettext equivalent is called '_' and you use a prefix of "i18n:" to mark strings that should be translated as Architect won't allow you to enter anything but strings where it expects strings.)

To apply it whenever applyIf is called, you can override the function:

    var applyIf = Ext.applyIf;
    Ext.applyIf = function(object, config) {
        convert(config, func);
        return applyIf(object, config);
    };

Note that this will be executed only when applyIf is called. You could probably do the same to define and create for a more bulletproof solution. It's definitely not perfect, but I'm certain if the project is important enough, you know better than to copy code off the internet.

Anyhow, a real runtime translation is sadly impossible because ExtJS and Sencha Touch do a lot of magic to make things fast. Unless Sencha decides to rewrite both libraries for the benefit of internationalization over speed, it's unlikely we'll get "real" dynamic translations.

(EDIT: Above code is dual-licensed under WTFPL (http://sam.zoy.org/wtfpl/) or Unlicense (http://unlicense.org/), depending on which one you prefer. In other words: I waive all copyright where possible and grant unrestricted usage where not.)

[devtig]

There are no dates set for this feature.

This doesn't sound promising to say the least. First requests for this feature date back to april 2010:
http://www.sencha.com/forum/showthread.php?97366-Localization
http://www.sencha.com/forum/showthre...tilanguage-app

Responses from the Sencha development team made it sound like it was coming. At the time the Designer maybe wasn't ready, but now the Architect is totally ready for having multi language support.

[charlez]

• Replies: 27
• Views: 1,545

Well this seems like about the most viewed and commented thread in the forum - and oddly enough I'm working on a multi-language app as well (who isn't these days?)

Would be great if this feature got priority :-D

[aconran]

We're aware of the need and it's on our radar.