Since Jive is a vendor in the international market space, our products need to handle a variety of aspects of internationalization, or i18n. Typically, this involves extracting human readable text from the UI and moving it into a ResourceBundle. But, it doesn't stop there. We also need to handle localization of email templates, dates, bidirectional support, and accessibility. Most of this is not glamorous development work, but it's really important to a lot of our customers, and improves the usability of our products in general. Below are some high level details of our approach to these topics.
Forums and Clearspace both support locales at a variety of levels in the object hierarchy. This includes user, "container objects", and global locales. With Forums, locales can be defined in the Category and Forum container objects. With Clearspace, locales can be defined in the Community/Space container objects. If a user specifies a locale, that is chosen first in the decision matrix. After that comes the container object, and finally the global locale. A customer webwork interceptor applies the appropriate local to a given request.
Within the UI layer, we use webwork ww:text tags to retrieve the locale specific text String. The various ResourceBundles are specified in the webwork.properties file, and webork applies the locale that is set by the custom interceptor. Within the Action layer, we provide an implementation of the TextProvider interface. If an i18n String is required outside of an Action, the LocaleUtils class provides an alternate implementation of TextProvider.
Since email templates from our notification system can be quite lengthy, we provide the ability to create new set of email templates for each locale without having to muck with a ResourceBundle. This approach provides for a better user interface, and lets us store the customized templates into the database with the specified locale. In Clearspace, we created a nice UI to easily customize email templates for any number of locales.
International companies have stronger legal requirements for accessibility than the US. With software, we need to support screen readers for the visually impaired. Screen readers pay attention to every detail of the UI, which can come across quite differently than the visual representation. In general, pay attention to meta tags like "alt" for giving valuable details to images. It doesn't help someone out very much to hear "rockin_icon.gif, smileyface123.png" over and over again. Instead, we provide meaningful information in the alt attributes and the reader will announce those instead.
So, internationalization is sometimes tricky and cumbersome to implement, but overall is quite necessary to acceptance in the international market.