Here are some proposals :
Internationalization is a large domain, but I assume that the current scope is to support :
- regional languages
- non-latin typography
- regional numeric and date formats
Generally localization (l10n) is excluded, so we don't care about different cultures, for example to know if some colors/texts/symbols are subjects to misinterpretation or viewed as insensitive. Read this article for more details. Moreover right-to-left texts will not be implemented in the first version.
Let's talk now about technical implementation. Sonar 1.11 already supports numeric and date formats. It uses the locale sent by the browser. There are no server-side mechanisms to store the user locale (session, preferences, ...). The locale can be overridden with the parameter 'locale'. See the analysis date of these examples : english and french.
Because GWT includes its own easy-to-use mechanism, translations in french are already done on some pages (see hotspots).
Most of the current extension points are written in Java, so I'd rather use the java.util.ResourceBundle lib than the Ruby on Rails default lib. It will be more easy to re-use, and writing properties files is a lot more usual than writing YAML/ruby hash files.
It's crazy, but Java5 bundles does not support UTF-8 properties files ! It has been fixed in Java6. For example all the chinese characters must be written with their unicode : \uxxx. The workaround is keep the file in UTF-8 then convert it to latin encoding during the build : see the native maven plugin.
A convention must be chosen to name message keys : page.message, PAGE_MESSAGE, ... ? Examples : hostpots.title, HOTSPOTS_TITLE, ... Which format is usually recommended ? Is it page oriented ?
The ruby on rails API must be used to implement a backend that loads java bundles and the core rails bundles (see config/locales/defaults/). Messages are declared in ruby views with <%= t ''message.key" %>. The default rails implementation loads all languages in memory. It would be better if bundles are loaded on demand. New version of the Globalize plugin can be a good starting point.
In a first step we can assume that there is only one bundle in classpath : /sonar/Message_xx.properties. Then we could define one bundle by plugin, so that each plugin defines its own translations (for example /sonar/technical-debt/Message_xx.properties).
Defining all languages of core messages in the sonar project, not in a i18n independent plugin, does not bother me. Anyway it's inevitably the case with GWT pages (need all bundles all compile time).
Two problems remain :
- some maven plugins generate messages that are directly saved in database, for example Checkstyle violations. It currently uses the default system locale. I think that using a global sonar locale would be better. It could be defined in a global parameter, and it could be overridden on projects.
- name/description of metrics and coding rules are hardcoded in Java or XML files. They have to be loaded by new Sonar extensions like MetricsReferential and RulesReferential. API could include :
public MetricInfo getMetricInfo(String metricKey, Locale locale), and MetricInfo defines localized name and description. Default implementations load messages from classpath, whereas advanced plugins could connect to remote servers (wikis ?).
New Feature
The best library seems to be globalite.