Dynamic Language Support (Internationalization)

[sandip.sahoo]

Hi,

We are using Enterprise SGWT 3.1.

The use case we have is, we use GWT's internationalization support for adding languages to our application.
I.e. use Message interface with annotation and corresponding properties files with the language code suffixed, i.e. en, de, fr.

However, what we are looking for is how to add language dynamically. Say today i build an war with 2 language support english and french. And ship this out to the customer.

Tomorrow the customer comes back saying he needs support for Japanese. How can we provide the japanese language directly without needing to rebuild the entire war file. Something like just shipping the corresponding japanese property file.

I am aware, GWT needs to compile these language permutations for a new language support.

But just wanted to check if there are solutions available in GWT/SmartGWT which can provide an alternative solution for this.

Thanks,
Vicky

[Blama]

Hi Vicky,

please see this thread. You'll need to recompile as far as I understand.

Best regards,
Blama

[Isomorphic]

No, not true. Take a look at the Internationalization overview for SmartClient. You can use this approach and completely ignore GWT's mechanisms, and then you will not need GWT compilation for either framework or application messages.

[Blama]

Hi Isomorphic,

that's good news. But this contradicts the answer in the linked thread, doesn't it?
Anways, I'll try that once I come to the i18n of my app.
Is any of the approaches better with respect to the result (date / number formatting)?
The JS-way is probably better than the GWT-way when it comes to compile time, app size, typos and language installation after deployment. Does it also have downsides?

Best regards,
Blama

[Isomorphic]

Hi Isomorphic,

that's good news. But this contradicts the answer in the linked thread, doesn't it?

Nope. The linked thread says that you must compile if your localization approach is to use SmartGWT's integration with GWT. Here we are discussing direct use of the SmartClient approach, which still works in SmartGWT.

Anways, I'll try that once I come to the i18n of my app.
Is any of the approaches better with respect to the result (date / number formatting)?

No, not really.

The JS-way is probably better than the GWT-way when it comes to compile time, app size, typos and language installation after deployment. Does it also have downsides?

No, not really. We designed the SmartGWT localization approach so that it "just works" with the way people expect to use GWT. But the SmartClient approach has functional parity and is more dynamic.

[Blama]

Hi Isomorphic,

great, thank you. I'll definitely try the SmartClient approach then once I'm there.

Best regards,
Blama

[sandip.sahoo]

Hi Isomorphic,

I am not sure if i understand the SmartClient approach very clearly. I suppose you are hinting at these statements,

" A second common technique is to load internationalized messages as a JavaScript Object mapping from a message name to the internationalized message. For example, if your messages are stored in Java .properties format, you could load your .properties file as a standard Java Properties object, and use the server-side com.isomorphic.js.JSTranslater.toJSVariable() API to output the properties as a JavaScript variable.

If the variable name chosen was 'i18nMessages', code to make use of the .properties data would look like:

isc.Button.create({ title: i18nMessages["buttonTitle"] });
"

So yes, in my case the messages are stored in individual language property files. My application does not have a server piece. It's largely all SmartGWT client talking to API's.

However the above explanation seems to mention that i need to have a server code to load this properties and then user SmartGWT server API to convert it to javascript object. But then how do i pass this js object to the client.

Do you have an example for reference which i can look at and try to understand this a little better.

Thanks,
Vicky

[Isomorphic]

We'll assume you understand the framework localization part, which is just loading a JS file.

As far as application localization, what you are doing is switching from GWT implicitly loading your i18n messages as part of the application's static resources, to explicitly loading your messages from the server.

You mention your application is "all SmartGWT client talking to API's", from that point of view, what you need is a new API that takes a locale and returns a bundle of messages, probably as a Java Map. You can then store that Map as a static variable and use it in the ordinary Java way; there is no reason to think about this in terms of JavaScript at all.

For example, let's say you define a class I18N with a static Map "messages" and populate it, then you are creating a "Save" button at some point whose title needs to react to the locale:

myButton.setTitle(I18N.messages.get("saveButtonTitle"));