Locales outside of the java definition

Rhythmyx Technical Discussion
1

Hi

I know that Rhythmyx uses the java definition for locales but what happens if the locale requested is not included in this list.

We have a site that required two locales one of which is Irish Gaelic. Can this still be implemented?

Cheers
James

2

I know it has been some time, but we finally have an answer on creating locales that are not part of the JRE.

The problem is that the Workbench validates locales, even though the server does not. Therefore, it is possible to create locales in the server that are not “officially recognized”. These “fake locales” can be very useful, but they do come with some limitations, which I will describe later.

To create a fake locale, you must do the following:

In the NEXTNUMBER table, look for the entry ‘localeid.’ The value you use for the localeid in the following step should be this value+1. Update this entry by adding 1 to the value.

Add an entry to the RXLOCALE table. Follow the pattern of an existing entry. The SORTORDER column can be left blank as it is not used any more. The DESCRIPTION value is optional. A value of 1 in the STATUS column means it is enabled.

Open the file explorer to <rxroot>/rx_resources. For each of the following directories, css, images and js, create a new sub-directory whose name matches the value you placed in the LANGUAGESTRING column in the previous step. For each of these directories copy the files in the en-us directory to the newly created directory.

Restart the server.

There are several UDFs that will not work with fake locales: sys_ConvertDateLocale, sys_FormatDateToLocale, sys_FormatDateToUserLocale. You will also have trouble with code that attempts to pass an arbitrary locale to $user.psoStringTool.getLocale() or one of the $tools.date.format() methods.

If you encounter any additional problems, please let us know.

3

Hi Dave

We’ve since upgraded the installation to 6.7 and now see this message in the console.log on startup:

2009-11-03 09:31:15,521 INFO [com.percussion.search.lucene.analyzer.PSLuceneAnalyzerFactory] Could not find a user registered or system analyzer for locale “ga-ie”. WhiteSpaceAnalyzer will be used for indexing and searching content.

As the message is labelled “INFO” I guess it’s nothing to worry about but can you confirm?

Cheers
James

4

Hi,

We have to implement non standard locales within CMS. I have related concerns

  1. Will the solution provided here work with database publishing?

  2. We have something like $sys.item.getProperty(‘rx:sys_lang’).String and
    $user.psoSlotTools.getSlotPropertyValues($transItems,‘rx:sys_lang’) in our database template bindings. Will it return correct values?

  3. Can we create translation settings for each content type in the target locale and community correctly?

  4. We have some static text in our snippet templates for which we have created translation keys in RX_ResourceBundle.tmx file. Will these translations get picked up when publishing snippets templates to database?

Also let me know if there are any others issues related to database publishing.

Thanks
Pallavi

5

Java Strings are not locale sensitive (they are Unicode), so the only place you get in trouble is where you serialize them to bytes, which typically happens when you write the strings to a file. Getting properties should not cause problems.

There have been some problems with the database publisher using the “system default” character set (US-ANSI on Windows machines) which does not include many characters commonly used in non-English languages. I believe all of these are now patched, but which patch depends on which version you have. Check with support if you encounter problems with the database publisher to make sure you have the appropriate patch level.

Dave

6

We are using the UDFs $user.psoStringTool.getLocale() and $tools.date.format() for formatting the dates published out. I believe then the solution provided here will not work for our implementation. Is there a way around this?



$tools.date.format("MMMM dd, yyyy", $sys.item.getProperty("rfh_pubdate").Date, $user.psoStringTools.getLocale($sys_lang))

We need English locales for all European countries like en-BE, en-NL etc. If these locales are passed to the above methods then will it get confused and throw error or will it default to the date format for en-us locale? I know that $user.psoStringTools.getLocale($sys_lang) returns a java.util.Locale object so my question might not be entirely valid. But this is the only issue that we need to have a workaround for to get this thing working for us.