Change Date Format

Hi,

This whole date format issue gave me so much pain that I spent a couple of weekends nutting out how the V5 PDK worked. At the time I found that there are two areas that cause problems:

1. Finding the locale for a user

2. Finding the date pattern for that locale

Finding the Locale

Although documented in the PDK at: "Documentation > Portal Services > Internationalization" the default behavior for choosing a user's locale in the PDK can be obscure.

In summary, the algorithm seems to be:
· If the component profile (e.g. an iView's default.properties file) has the properties ForcedRequestLanguage and ForcedRequestCountry defined, then they always override any other setting. (These properties can be made personalizable.)
· Otherwise, if the field request.mandatorylanguage in file workplace.properties located in folder %IRJ_HOME%/WEB-INF/plugins/portal/system/properties is set then use this language.
· Otherwise, for users who are

not

logged on, use the locale is defined in the fields request.defaultlanguage and request.defaultcountry in file workplace.properties located in folder %IRJ_HOME%/WEB-INF/plugins/portal/system/properties.

· For users who are logged on, the locale is defined in the field .locale in the file KMUsers.properties, located in folder %IRJ_HOME%/WEB-INF/plugins/portal/services/usermanagement/data

All the above settings in the PDK have priority over the language settings in the browser. For example, if there is a language setting in workplace.properties or KMUsers.properties, the language setting in the browser is ignored.

The setting in the user's browser is only used when none of these have been set.

Choosing a Format for a Locale

When choosing the format to render data in for a locale, the PDK will first use the locale language to find a suitable format, and then if it does not find anything, it will use language and country together to find a suitable format.

This often leads to the wrong format being used.
For example, if the portal wants to render a date for the English-Australia locale ‘en_AU’, it will search for a format for the language ‘en’, find the format ‘en_US’ and use that format (which happens to be ‘mm/dd/yyyy’).

It should look for a match on language

and

country first. If it did this, it would search for ‘en_AU’, find the correct format for English-Australia, and use that (which happens to be ‘dd.mm.yyyy').

I ended up creating a framework that addressed what I saw as problems. You can find the framework (called HTMLX) on SDN. It's a long way from perfect, but it's open source and it may help you find answers/workarounds.

If you do a search within this forum you will find lots of other posts on this issue as well.

BTW, you may experience a javascript error with the date picker popup. This can be avoided by using a full ip address rather than 'localhost' (yes this realy works - it's all to do with domain relaxing - which is another discussion altogether).

Alan