Fun with Content Server Localization

Oracle / Stellent Content Server provides some pretty robust localization support. I’m often suprised how much functionality there is to support localized data. Strings and dates can be returned in a variety of languages and formats all based on the user’s locale. Schema/DCL data also support multiple locales, both through the javascript version of the lc function and also through display rules in the view. The level of localization support and easy of use reminds me of what we tend to see from some of the European CMS vendors, who for obvious reasons seem to place a greater priority on localization.

The one issue I’ve run in to though is when developing web sites in Site Studio I find it’s hard to tap in to all of that wonderful localization functionality without changing the default system locale. The problem appears to be that the localization is based on the user and since all anonymous users are essentially using the same account, they all appear to have the same locale. I’ve read some posts on how to change the user’s locale by updating a cookie, either server side or by Javascript, but to be honest I’m not super crazy about that method. Odds are everything will work fine 99.99% of the time, but what if a user has cookies disable or if the user is actually a search crawler which is ignoring cookies? It’s probably not going to work so well.

Enter the IdcLocale object

Changing the user’s locale during a service execution is actually an extremely easy thing to do. Localization data is held in the IdcLocale object(intradoc.common package), which is stored during exection as a cached object named “UserLocale”. If you wanted to access a user’s IdcLocale object, the syntax looks something like this:

IdcLocale MyLocale = (IdcLocale)context.getCachedObject("UserLocale");

Changing the locale take a couple more steps. You first need load a new IdcLocale object specific to your locale and then you need to overwrite the old one. Creating a new IdcLocale object is pretty simple, you use the LocaleResources object and call the static method, getLocale. It takes a single argument, the name of the Locale you’re loading:

IdcLocale ItalianLocale = LocaleResources.getLocale("Italiano");

Once you have the new IdcLocale object, you only need to overwrite the old one and your locale is changed :

context.setCachedObject("UserLocale", ItalianLocale);

Putting it in action

I’ve put together a sample component which adds functionality for changing the user’s locale dynamically. In tinkering with user locales, there are two customizations which I think can come in handy.

The first is customization is a filter attached to the ‘afterInitLocale’ event, which is fired right after the user’s locale is set during a service call and I’m pretty sure was put there specifically for changing the locale. In the component, the filter looks for a local binder value called ForceUserLocale. If it’s there and it’s a valid Locale name, then it swaps out the current user’s IdcLocale object with a new one. Post-switch, the service continues it’s execution evaluting the new Locale object.

The other customization basically wraps that same code in a new IDOC script function called setLocale. SetLocale takes a single argument, LocaleName, which is of course the name of a valid locale in the system. Calling the function immediatly switches out the user’s Locale with a new one. This is pretty cool if you’re working on a web page or template and wish to show the same or multiple strings in different languages.

Using the new setLocale function, the following code would display the same string on the same page in different languages:
<$setLocale("Italiano")$> <$lc("wwPoweredBy")$> <$setLocale("Italiano")$> < $lc("wwPoweredBy")$>

Controllato dal sistema di gestione dei contenuti Powered by Content Management System

Changing the Locale dynamically with a local binder value might not be the best fit for all implementations. If you install the sample component adding ForceUserLocale=Italiano to the URL will change the locale to Italian, which may or may not be undesirable. Nevertheless, I think the component demostrates some of the cool things you can do with the IdcLocale object.

The sample Anonymous User Locale component is can be downloaded here:
Anonymous User Locale Component