Skip navigation

Jive Release Blog

1 Post authored by: todd

Product Internationalization

Posted by todd Aug 10, 2007

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.


Locale Support

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 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.


Email Templates

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.



To localize date formats, we make use of the Java API using the DateFormat and SimpleDateFormat classes.  With Forums, we recently localized the date picker and text box processing for Announcements and Polls.  We wrote a customized freemarker template for the webwork ww:datepicker tag, and added in a commercial javascript calendar called Zapatec.  Thanks to webwork, the customization was quite easy.



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.


Other issues with accessibility that we've run into include adding focus to an error message.  By default, screen readers start at the top of a page whenever it is loaded.  Rather than reading over the entire page again only to find there was an error message, we recently added some javascript in Forums to place the focus on the error message text as early as possible.  We extended the webwork ww:text tag to add this feature, since error messages are also internationalized.


Bidirectional support

Bidirectional support, or bidi for short, means adding support for mixed direction texts, such as Hebrew and Arabic.  This topic has been a challenging one. For the most part, browsers provide support for automatically reversing general html elements, such as tables.  However, when a div or span is used, explicit instruction needs to be given to tell the browser the text direction.  The problem is that the browser doesn't easily provide the text direction of the user's locale via javascript, and neither does the Java Locale API!  If anyone is familiar with this problem, and has a solution, please let us know how you implemented this.  Since direction:ltr and direction:rtl need to be set on spans and divs, we were forced to create a map of locale to direction and handle it manually - yuck!


So, internationalization is sometimes tricky and cumbersome to implement, but overall is quite necessary to acceptance in the international market.

Filter Blog

By date: By tag: