In portals, all the resources that are not portlets themselves but are accessed through portlets - reading data through PortletRequest, and writing to PortletResponse - are referred to as 'bridged'. Any resources that are accessed directly, bypassing portal filters and servlets, are referred to as 'non-bridged'.

Non-bridged servlets, and .jsps have no access to PortalRequest. They do not use PortletRequest.getLocale() to determine current Locale. Instead, they use ServletRequest.getLocale() which is subject to precise semantics defined by Servlet specification - it reflects browser's language preference.

In other words, non-bridged resources do not have a notion of current Locale in the same sense that portlets do. The result is that when mixing portlets and non-bridged resources there may be a localization mismatch - an inconsistency in the language used by different resources composing your portal page.

This problem is addressed by LocalizationFilter. This is a filter that changes the behaviour of ServletRequest.getLocale() method so that it behaves the same way as PortletRequest.getLocale(). That way even localization of servlets, and .jsps accessed in a non-bridged manner can stay in synchronization with the portlet localization.

LocalizationFilter is installed through the gatein.ear/portal.war/WEB-INF/web.xml file of the portal.

<filter>

    <filter-name>LocalizationFilter</filter-name>

    <filter-class>org.exoplatform.portal.application.localization.LocalizationFilter</filter-class>

</filter>

...



<filter-mapping>

   <filter-name>LocalizationFilter</filter-name>

   <url-pattern>*.jsp</url-pattern>

   <dispatcher>INCLUDE</dispatcher>

   <dispatcher>FORWARD</dispatcher>

   <dispatcher>REQUEST</dispatcher>

   <dispatcher>ERROR</dispatcher>

</filter-mapping>

One tiny limitation to this mechanism is that it is unable to determine the current portal, and consequently its default language. As a result, the portalLocale defaults to English, but can be configured to something else by using filter's PortalLocale init param. For example:

<filter>

    <filter-name>LocalizationFilter</filter-name>

    <filter-class>org.exoplatform.portal.application.localization.LocalizationFilter</filter-class>

    <init-param>

       <param-name>PortalLocale</param-name>

       <param-value>fr_FR</param-value>

    </init-param>

</filter>

By default, LocalizationFilter is applied to *.jsp, which is considered the minimum required by GateIn 3.5 to properly keep its non-bridged resources in synchronization with the rest of the portal. Additionally, deployed portlets and portal applications may need broader mapping to cover their non-bridged resources.

Avoid using /, /public/ ,/private/*, and similar broad mappings as LocalizationFilter sometimes adversely interacts with the processing of portlet requests. Use multiple filter-mappings instead to specifically target non-bridged resources.

Keeping the mapping limited to only non-bridged resources will minimize any impact on performance as well.