Internationalization in uPortal3

Features

From the user standpoint, uPortal should provide the following internationalization features:

• allow user to specify an ordered set of preferred locales for
  • the whole portal
  • specific profile
  • specific portlet
  • content piece, such as fragment (optional)
• automatically determine optimal locale for the content being presented
• allow content publishers to specify different or restricted set of available content locales

UTF-8 encoding should be used.

Locale Manager

This section covers the following JIRA issues: UPT-42

Goal

Locale manager coordinates resolution of locale preferences coming from different sources. The exact set of sources is determined by locale manager configuration, and so is the resolution logic. The framework will query locale manager to obtain a best matching locale. Alternatively, top preferred or complete locale ordering may be queried.

Sources of locale preferences

Locale preferences are defined at multiple levels, by user, administrators, system or some other entity. The exact set of locale sources is configurable. Below is a listing of major locale sources, in the order of importance:

• User. For most installations, user preferences will be most important. The user should be able to define their top preference, their second preference, and so on. The user should be able to specify such preferences for:
  • portlet-window-specific preference
  • session-specific preference (initally empty, can be specified at runtime)
  • portal-wide locale preferences
• Browser. accepts-language http header specifies a locale preference
• Installation. locale preferences configured for this uPortal installation
  • default locale preferences for all users

Later on, other sources of locale preferences can be added, including:

• (User) locale preference for a specific piece of content (i.e. user layout node, fragment, etc.)
• (Installation) local preferences based on group membership

Locale resolution

When presented with a set of locales available for a particular resource, locale manager will be tasked with choosing the best-fitting locale, based on the combined locale preferences for that user, node, etc.
The resolution logic should be configurable. As locale specifies both language and country dialect, some implementations may try to match the most preferred language, while others may avoid unspecified dialects.

Implementation

The installation preferences can be configured statically in spring. The user-specific and request-specific preferences can be configured in the portlet context (implementing request-specific ones as request parameter processor components). Currently the framework will use locale manager in two ways:

• resolving locale for a specific portlet window
• resolving locale for a portal context component, such as an XSLT transformer

/**
 * This is a general method that can be used to resolve
 * locale for various components
 * @param availableLocales unordered set of supported locales
 * @return best matching locale given various locale preferences
 **/
 public Locale resolveLocale(Set availableLocales);

/**
 * This is a specific framework method for resolving
 * locale for a specific portlet window
 * 
 * Note: the initial implementation can just call method above
 * with locales provided by portletWindow.getSupportedLocales().
 * This will automatically support locale preferences/restrictions
 * defined at publish or subscribe time.
 * After that, we can add ability to specify locale preferences
 * for a specific portlet window, but that can be left for another 
 * milestone.
 *
 **/
 public Locale resolveLocale(IPortletWindow portletWindow);