Localisation standards in Vaadin 7?


I am using Vaadin 7.1.0 and after looking into all documentation, threads, addons I am still not able to get thread-safe multi-user localization working in my application.

The problem is that I have atm a singleton class that loads all resource bundles for easy access and every time I look up a string, it looks for the locale in VaadinSession.getCurrent().getLocale().

It then dispatches an event using MVP-Lite to update all views with the new strings.
The problem I have is that when I have 2 different users opening the same app, user 1 starts in dutch, user 2 starts in french, when user 1 changes to french, user 2 can no longer change to dutch.

So then I tried looking into the I18N4Vaadin add-on but that one generates code which I am supposed to use and I am not a fan of using generated code like this since I don’t have it during development.

So that is why I was wondering if there is a better, more standardized method of translating applications on the fly.
I also tried using listeners in that singleton but then I have threading issues since user 2 then gets his page translated the next time the page is repainted.

For the record, yes I am setting the locale on VaadinSession.getCurrent.setLocale() and yes I read that either I could reload the page (but I cannot find anywhere in the documentation how to do this in the code) or that I should re-create my view in the init method, but the code showing how to do that is outdated and for Vaadin 6 only.

Any help would be most appreciated!

I don’t know about standard, but in my most recent project we solved that problem by having a language handling class called Lang that had static cache for the different translations. The Lang class was then instantiated for each user separately, and when translations were needed they were selected using that user’s chosen language. Then we only had to make sure that each view had a way to always reference that user.


I faced the similar issue with my application: I had to switch between two languages. In my case it was not required to switch the UI on the fly, instead I could refresh the whole application (closing the session and jumping back to the home page) if the user switched the language. It is usually ok, because the user don’t switch back and force and keeps the language once it is set.

In my case I created a class which was extending the vaadin service, so I could set the locale to the thread local field. By that the locale was available to all underlying layers of the applications. I could not use a new vaadin enhancement for avoiding thread locals, because I don’t like my business logic to be dependent from a UI framework.
For the localization I used the regular java bundles which are already cached by default rather aggressively within the java implementation.