InfoQ spoke to messages creator Stephan Schmidt to find out more about the new framework:
There are several problems with the current Java way. There is no support for thread local locales (useful for web applications, easy to get the locale everywhere). Usually i18n code in Java is very noisy, with lots of i18n code, it's very difficult to read and understand business code.The end result is replacing the following typical Java 5 internationalization code:
Usually an application has several bundle files. But then when doing i18n the developer has to think about which bundle to use for each class. With Messages he just has to supply "this" to Messages and the framework will find the correct bundle. As the configuration of the bundle mappings is done outside of the application code, the developer can change the mapping afterwards.
com.accounting.AccountService.java
public Account create(String name) {
Account account = new Account( name );
Locale locale = new Locale("en", "");
ResourceBundle bundle = ResourceBundle.getBundle("accounting", locale);
MessageFormat formatter = new MessageFormat("");
formatter.setLocale(locale);
formatter.applyPattern( messages.getString("ACCOUNT_CREATED") );
show( formatter.format( account ) );
return account;
}
With this simpler Cintoo Messages code (after associating a bundle with the com.accounting package):
com.accounting.AccountService.java
public Account create(String name) {
Account account = new Account( name );
show( $(this, “ACCOUNT_CREATED”, account) );
return account;
}
According to Stephan, "indirect competiors are IDE plugins which do i18n automatically (with all the problems) and commercial vendors who sell i18n applications which do the same as the plugins, finding "hello world" strings and replacing them with i18n code. Both solve the i18n problem in a different way than cintoo Messages which focuses on developer written i18n code. But I plan to provide automatic string replacement and i18n QA in the next versions."