Question

In my application(GWT(EXT_GWT) + Spring) I need to set user(after login) his native language, without get params. For example: user filling his login&pass at login form and then redirecting at ready-to-work form (this form must be with native user language. Locale I get from db). My language files written at .properties files and enumerated in module.gwt.xml config.

So question is – how I can set language? Maybe with session or post params? But I don’t understand how GWT before loading page choose needed locale. Some methods to set locale at gwt before page loaded?

Thanks!

Answer 1

Using the built-in internationalization and using it as intended, you can’t do this without reloading the page. The built-in i18n relies on only loading the compiled permutation that corresponds to the selected locale. This means you can’t just add a meta tag, you can’t just flip a setting, and you won’t be able to read from the built in LocalInfo class.

Two options, as I see it. First, make the reload less expensive, so you can use the i18n stuff GWT comes with. To do this, break out the rest of the app from the login, either by making a new app, or by using split points, so as little code as possible is loaded. Compiles files should be caches, so it shouldn’t affect the download time, just the time it takes to start the app.

Second option, following your constraint of not reloading: Don’t use the built in I18n, but find another way to pull in strings based on runtime data (as opposed to the usual compile-time approach).

• GWT documents one such way of doing this with the Dictionary class, allowing you to read from strings loaded by javascript (see http://code.google.com/webtoolkit/doc/latest/DevGuideI18n.html#DevGuideDynamicStringInternationalization). This could be done by loading a JS file with these strings after login (consider ScriptInjector for this so you know when it is ready). This has the additional advantage that you don’t need to recompile to change strings, if you consider that an advantage, and the disadvantage that you need to have the strings in JS, not java and properties files (though some careful server work could allow you to generate that js from java/properties).
• Make several I18n interfaces instead of just one. They should probably all implement a common interface so you can pass along the instances to anything that needs them, widgets, etc. The problem with this approach is that while you are using the built-in I18n, you are compiling in all of the strings, whether they are used or not. To ameliorate this, consider a split point for each locale required, and make sure you only load one of them.