With or Without Guice
If you have read earlier posts, you will know that my V7 project uses Guice. The I18N implementation I have developed so far does not use Guice a great deal and would be easy to extract to another DI framework, or manual injection.Approach
I was trying to come up with a design that would simplify some of the repetitive nature of coding for I18N support. I came to the conclusion that I would actually need two methods which can be used together, as the developer decides. The documentation gives a better explanation, but I've summarised it in this post.Using Annotations
Annotations would seem to be quite a neat way to support I18N. It means that the I18N key is defined alongside the component to which it relates. There are limitations, however, particularly if you are using translations with parameters, as there is no easy way to define the parameter values to be used.I have completed the implementation of the annotation based implementation, and it works quite well for many circumstances. That includes nested components which also need I18N support. Vaadin tables also need a little special handling because of course, the column headings would normally be translatable.
The code for this is still in the develop branch, but has reasonably well tested.
