How do you guys handle localization in your applications?
My first approach was this:
// In initialization
setLocale(new Locale("fi"));
...
// Retrieve "testKey" from db with current locale (fi)
Label l = new Label(translateFromDB("testKey"));
...
Then I naturally had a small problem 8)
How do you CHANGE the users language on the fly- we can call the “setLocale()” again but the already created labels etc. will not be updated.
Maybe restart the app with some parameter “…/app?locale=en” so that the whole UI is repainted again?
Is there a way to do this without logging the currently logged in user out?
Im handling localization in some similar way, by providing a global translation manager which is accessible from all applications. It loads resources from application’s theme folder. You may take a look at it in the TPT project in contrib section.
Regarding language switching, if you restart the app, all states will be lost, which is not very nice. One thing which can be done is that translation manager will provide a way to register locale change listener, so all UI components may register themselves and receive an event when locale is changed and update labels accordingly. Then translation manager (after processing of all registered listeners callbacks) should force toolkit UI to repaint in order to update translated labels at the client side.
One possible solution for i18n is gettext-commons by Google. One could for example easily implement a subclass of Application class which delegates the i18n stuff to gettext-commons.
I’m working on two distinct Vaadin apps and we’ve yet to solve a decent way of doing localization for them. We have a translation manager in place, but haven’t decided on how to do language switching.
If UI components register themselves as listeners to a translation manager, won’t I have to manage their construction / destruction closely? The manager will have a memory pointer to them, which will prohibit garbage collection even if they are no longer used elsewhere. As the manager would be shared among applications, would this not ultimately lead to a crash due to memory running out?
I hope localization gets some more thought in future versions. Having to explicitly handle language switching for every single component is really boring, not to mention error-prone. Forget a label and you get a label that doesn’t switch even the rest of the UI does.
Thanks for the link, the conversation on that thread was quite interesting.
We were able to sell to our customer the idea that language changing is only needed in application entry-points instead of everywhere. This makes localization a whole lot easier to us.
However, no matter how much we theorize about it, Vaadin competes with other web frameworks. And most of those other frameworks can offer substantially easier localization. Sure, it’s because they’re stateless, but that’s not a word I’m going to be using in a meeting with a customer. Because of this, having an easier way to embed localization into Vaadin apps would be appreciated.
Valtteri - would it be an acceptable solution to move your main window creation away from init(), use language as a parameter for it and just switch main windows when the user changes the language? This way user wouldn’t have to “log in” and could change the language “on fly”. Also - if you are planning to support multiple simultaneous browser tabs, you need something like this.
I’m not the original poster, sorry for hijacking the thread. The log in problem is not something we’re suffering from. We use a Spring session scoped bean to hold current user data. If the bean has user data, we don’t show a login form.
And yes, having main window creation distinct from init() does enable us to “restart” the app with a new locale. We use fragments for shortcuts to certain parts of the app, and these help retain the state somewhat. “Restart” navigates the user back to where the fragment points. Still not ideal, but a bit better. And no actual language switching code is required, which is very good.
The simultaneous browser tabs look very interesting. One of our Vaadin projects has a requirement for two distinct windows because the customer setups have two displays. We’ve turned down the requirement, but naturally getting a chance to fulfill it would be great. Thank you for the link, Joonas.