I18N4Java is a I18N framework for Java which provides an alternative way to internationalization for Java. It's annoying to read code from other developers only with references to property strings without knowing the correct syntax of the message and also the correct meaning. It's cleaner to get the whole message in the code to understand the purpose and the syntax.
What code do you like better?
1)
label.setText(translations.getString(HELLO_MESSAGE, name, date,time));
2)
label.setTest(translator.i18n("Hello Mr. {0}, today is {1} and you local time {2}", name, date, time));
The ultimate advantage of the second line is that all information is obvious. In the first sample it is not clear whether there are arguments for the string and if, which order is needed.
Additionally, this framework provides features for multi-lingual applications in environments where application should be presented in two (or more) languages at the same time e.g. for training purposes.
Why do one need another I18N framework?
The standard way for I18N in Java is to write all messages which are to be translated into property files and all translations go into additional property files with the same property keys. In dependence to the language to be used another property file is loaded to change the message strings. For more information have a look at http://java.sun.com/docs/books/tutorial/i18n/index.html
One of the major issues is, that within the code the correct message syntax is not visible and the correct meaning is also not present to get an idea about the need to change this message. It's even more difficult if the Java MessageFormat is used to format parameters within this messages. Which parameter was at position one? What format?
The goal for this framework is to overcome this issue of unclean code. Additionally, a feature shall be included which gives the possibility to show an application in two or more languages at the same time e.g. for training courses in international environments.
General concepts of i18n4java
The idea of how to integrate such messages was borrowed from the C++ framework QT which is the base for KDE and a lot of successful, internationalized applications. For more information have a look to the QT Project site.
At first for I18N there are two major issues to be solved:
- Handling of localization information
- Formatting capabilities for translations where the order of parameters within a message string can be changed
Localization (L10N)
Due to Java's excellent L10N framework is the localization information handled within this. The main class for that is Locale.
