In a number of cases, it is very valuable to have formatting - esp. for dates and numbers - to default to a different locale than that of the translation. For example, one might only have US English translations, but want British and German users to see dates formatted appropriately for their locale.
Description
In a number of cases, it is very valuable to have formatting - esp. for dates and numbers - to default to a different locale than that of the translation. For example, one might only have US English translations, but want British and German users to see dates formatted appropriately for their locale.
We now have RequestContext.getFormattingLocale(), and a <formatting-locale> element in trinidad-config.xml that can be used to set this (optionally with an EL expression).
LocaleContext now has both getFormattingLocale() and getTranslationLocale() methods (as well as a deprecated getLocale() method, pointing at getFormattingLocale() for temporary backwards compatibility).
DateTimeConverter and NumberConverter both follow getFormattingLocale(), if set (and if their locale is not explicitly set)
Adam Winer added a comment - 28/Oct/06 02:28 AM We now have RequestContext.getFormattingLocale(), and a <formatting-locale> element in trinidad-config.xml that can be used to set this (optionally with an EL expression).
LocaleContext now has both getFormattingLocale() and getTranslationLocale() methods (as well as a deprecated getLocale() method, pointing at getFormattingLocale() for temporary backwards compatibility).
DateTimeConverter and NumberConverter both follow getFormattingLocale(), if set (and if their locale is not explicitly set)
ADFFACES-268: Add support for formatting locale, separate from translation locale. Also, fix a bug in DateTimeRangeValidator to avoid a NullPointerException when one of min or max isn't set
New Feature
Resolved
Major
Add support for formatting locale, separate from translation locale
LocaleContext now has both getFormattingLocale() and getTranslationLocale() methods (as well as a deprecated getLocale() method, pointing at getFormattingLocale() for temporary backwards compatibility).
DateTimeConverter and NumberConverter both follow getFormattingLocale(), if set (and if their locale is not explicitly set)