The localization feature is really nice and helps a lot, but you also can have some trouble using it. The first problem is that the language codes which are used in XPages are different from the language codes in java.util.Locale.
This SSJS code for example will not work:
var locale = new java.util.Locale( "fr_BE" ); context.setLocale( locale ); context.reloadPage();
It will not work because the java.util.Locale object returns „fr_be„, but the PageDetails are set to „fr_BE„, and that’s why the setting the language does not work.
<xp:text escape="true" id="computedFieldLocale"> <xp:this.value> <![CDATA[#{javascript: var locale = new java.util.Locale( "fr_BE" ); locale.getLanguage()}]]> </xp:this.value> </xp:text>
[This SSJS Code returns „fr_be“]
[In PageDetails „fr_BE“ is used]
But if you set the locale string manually with the setLocaleString() method of the context object, it works as designed.
The second problem I ran into is the aggressive transformation of all texts on a XPage. I copied a simple CSS Style definition from another database, but after copy/pasting it I was unable to see any changes in the browser, as soon I switched to another than the default language. The CSS style didn’t work anymore:
<?xml version="1.0" encoding="UTF-8"?> <xp:view xmlns:xp="http://www.ibm.com/xsp/core"> <style> .red { color:rgb(255,0,0 ) } </style> <p>TEXT</p> </xp:view>
[Default Language, it worked]
[Other Language, not working anymore]
The CSS style was transformed by the localization feature and was now „translated“. In the generated HTML code, the tag looked like this:
<style>[en| .red { color:rgb(255,0,0 ) } ]</style>
Same result for directly copied JavaScript-Code, Text etc. (as shown in the screenshot above).
But I still love this feature. It makes developers life a lot easier.