Hello all,
We are developing an application with support to internationalization (i18n) of messages. Almost all of this messages will be defined by us, of course. We’ve actually developed a custom handling of this messages, so they can be loaded from a DB and even modified by the user.
We also want the user to be able to switch the application’s language without reloading the application (and therefore loosing its state). I think I can redraw my components as needed, inserting the messages in the current language (I haven’t done it yet, though).
But, what about the messages inside the SmartGWT components? The list grid, e.g., has messages like ‘Sort Ascending’, ‘Sort Descending’, etc. Is there a way I can switch the language of these messages without reloading the application?
I know I could programmatically change every message, with methods like setSortFieldAscendingText() in the ListGrid class. But, can I somehow change the current locale and reload all components automatically?
I’m almost sure the answer is no, since as I understand the messages are hard-coded in the <HASH>.cache.html files. But, I thought it wouldn’t hurt to ask. This seens like a rather commom behavior to me. How should I handle these situations to allow the user to change his/her language of preference during runtime without loosing the application’s state?
Thank you!
Thiago
They’re not hard-coded. The same code that you can see in the locale files can be used to set them dynamically at runtime. However this will not effect already created components, and making it effect already created components is something we consider a non-goal.
Hi Isomorphic,
I would have to set the messages one by one at runtime (using methods like ‘setSortFieldAscendingText()’ for ListGrid)?
Is there any way I could tell SmartGWT: “from now on, start drawing the components using messages in the language X”? In other words, it would automatically affect all internationalized messages defined by SmartGWT.
Dynamically loading the locale files we ship with SmartClient would do this (they are just .js files).
But you should probably reconsider your goals. Do you anticipate that users will log in, use the application in German for a while, accumulate some state, then decide they want to use the interface in Italian after all and be annoyed that the context is lost? This seems like an unlikely usage pattern, if so, there is no reason to go to extra efforts to try to switch locale on the fly.
Yes, I have to agree with you it’s an odd behavior. I would like to support it if I could, but probably it would not get used very much.
But there is a specific situation where I need to change the locale dynamically. When the user first opens the application, a login page is shown. In the server, I set the GWT locale (via meta tag) to the locale configured in the browser (I get this information in the Accept-Language header of the HTTP request).
So, the application initially is configured with the locale of the browser. But after the user successfully log in, I want the application to use the locale chosen by that user (which I assume may be different from the browser locale).
I can’t reload the application since the information about the logged in user is held in a static variable.
I don’t know if this is a completely wrong way to build a SmartGWT application. I’m working with this technology for only 2 months now. So, any suggestions are very welcome!
PS: By the way, I’m using only the client-side SmartGWT, not the Smart Client Server.
Right, don’t store the user information in a static variable 
Provide the ability to load that information from the server, then you won’t be in a situation where a reload breaks the whole app.
Up to now, I was not keeping an open session between the client and the server. Every request from the client had to carry information like the logged in user, and this information was obtained from the static variables.
I guess this is not the recommended approach, right? Probably I should keep an open session and let the server supply this kind of information.
I’ll take a look at this approach.
Thank you very much for all your help and prompt responses, Iso!