Different languages/Translations

[hotdp]

Hi,
The application I am developing for my work should be in 12 different languages.
So every button, tabbutton..... Has its own "text" depending on the language selected on the first view.


How do I solve this in the designer?

[Phil.Strong]

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

[hotdp]

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

Sounds good. But we have a lot of customers with the need for languages. So I need temp solution.

Any good advise? I did it in ST1 by having a object for every language, like danish.hello world give "hej".

But I don't see how I could set a text property to something else then a String in the Designer?

[Phil.Strong]

Would have to be done after the fact outside of designer. You could use Designer to do it in one language and then use favorite text editor and find/replace tactics to replace the strings with objects

[hotdp]

Would have to be done after the fact outside of designer. You could use Designer to do it in one language and then use favorite text editor and find/replace tactics to replace the strings with objects

I have to change the language inside the application. So the first view is a language selector and the language in the whole application should be the selected one.

My deadline is soon so I have to figure this out. If no one has any sugestions I might post my solution here. Language selection will be essential for many of our apps.

[ssamayoa]

I have to change the language inside the application. So the first view is a language selector and the language in the whole application should be the selected one.

My deadline is soon so I have to figure this out. If no one has any sugestions I might post my solution here. Language selection will be essential for many of our apps.

Mmmmm...

I been thinking on such issue and the only solution you have is to write some sort of interceptor on constructor and/or initComponent() which read language resource, traverse the DOM tree and replace properties (label, title, etc.) of already instantiated views.

Regards.

[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.