Locales
What locales means
A locale is a combination of country and language. Sometimes we build a locale from user settings, e.g. we know you are in Spain and you've told us your language is Basque.
The current locale
The current locale will depend on various settings and requests. There is a system wide default locale, usually based on the location of the server. Users can also set their preferred locale. Browsers also report their locale and finally websites can provide links to set the current locale.
The order of preference is:
- Explicitly requested
- User preference
- Browser setting
- System default
Do we want a settable system value? We can set the system locale when we run the server but this probably affects all applications. We probably want a BwSystem value which will be used and can be set to any value. For hosted services this is probably a requirement. So the last choice probably becomes two - use the BwSystem value(s) or if not set use Locale.default
Note also, that a locale possibly does not have a language setting. We should require that the BwSystem locale has a country code AND a language. We can then reasonably default.
Language resources
(Still under development) As part of 3.5 and to be used in the xsl rewrite which will be part of 4.0 we will now have a resource bundle defining all the Strings which may be used internally by bedework or externally in the xsl. The build process requires the default locale which must correspond to one of the resources in the bundle. If such a resource does not exist you will need to help us create one.
(The location of the resources - a set of proeprty files - is a property which you can override).
Using the default locale we copy the resource property files into a location for use by the build. In addition we copy the default locale into a property file which has a name which does not contain the locale - thus providing a default for the ResourceBundle class. e.g. we have the file !BwResources_en_US.properties, !BwResources_en_UK.properties, !BwResources_fr_CA.properties. The default is fr_CA so we will copy those file to the appropriate location and also copy !BwResources_fr_CA.properties into BwResources.properties.
At the same time we create a set of xsl files which allow us to define xsl paramaters with default values.
We will also need a build property which allows us to specify which locales we want to support. This allows us to limit the number of resource files.
Components changed for locale stuff in 3.5
BwSystem
To add a locale value. Change schema, admin client.
package edu.rpi.cct.uwcal.resources
(Re)discovered some unused code which needs renaming and reusing.
- package edu.rpi.cct.uwcal.resources should be renamed to a bedework package. We can possibly use it for localized resources we've been talking about.
- org.bedework.mail.MailUtil may not be used anywhere
UtilActionForm
Following methods in UtilActionForm call edu.rpi.sss.util.TimeDateFormatter methods. Now changed to provide the locale explicitly from the currentLocale form object.
- getCurTime
- getCurDate
- getCurDateTime
- getCurShortDate
- getCurShortDateTime
These changes add the getCurrentLocale and setCurrentLocale methods to the form. setCurrentLocale should be called whenever the locale changes. Classes using that form value should call getCurrentLocale every time the locale is needed as it may change.
edu.rpi.sss.util.servlets.ConfiguredXSLTFilter
This sets configuration based on the request locale in method updateConfigInfo. Probably needs no changes. Note that it calls request.getLocale(). This is based on the ACCEPT header from the browser or, in its absence, the server default locale. Thus this value represents the last two options above.
We do have
private static final Locale localeDefault = Locale.getDefault();
We might want to change that so the default locale is settable.
org.bedework.appcommon.CalendarInfo
Has a locale field. It also has no imports other than standard java classes. This class should probably be moved down some levels, at least into the svc level and then the getLocale and setLocale methods changed to be static methods using a thread local variable. We should store in that variable an instance of CalendarInfo initialized with that locale and add a static getInstance method to return that single thread local instance.
org.bedework.calfacade.util.CalFacadeUtil
Has two public fields defLocale and defLang. We should track down references to these and redirect them to elsewhere.
org.bedework.calfacade.util.DateTimeUtil
Method getPeriod needs to use the current locale.
Freebusy aggregator
Has references to Locale - leave for the moment.
org.bedework.webcommon.misc.WebCalendarAction
Needs to use new means of getting locale
org.bedework.webcommon.misc.BwAbstractAction
All uses should disappear if we remove Locale parameter from MyCalendarVO and CalendarInfo
org.bedework.webcommon.misc.BwActionFormBase
Needs to use new means of getting locale - probably form getCurrentLocale
org.bedework.webcommon.FormattedFreeBusy
Probably OK as it stands as the call in the constructor will get changed if we change CalendarInfo
Changes made
These may not be complete. Some instances may get embedded and need replacing if the locale is changed.
BwLocale added
Saves current locale in Thread local object. Needs to be set on entry based on a number of parameters.
CalendarInfo
Made constructor private. Add static map indexed by locale. CalendarInfo? is a read only object so we can share the instances. Two new static methods getInstance and getInstance(Locale)
MyCalendarVO
Remove locale as a constructor. Removed private copy of CalendarInfo?. We may need to track down instances stored in the session and replace them if the locale changes. However, try to make it self checking.
org.bedework.appcommon.TimeView
Removed calInfo as a constructor parameter - just calls getInstance. persistant TimeView? instances may eb a problem if locale is changed mid-session
org.bedework.appcommon.TimeViewDailyInfo
Defines a FormattedDate? class which creates date time formmatters based on locale. Need to check this out. Removed use of CalendarInfo? and called BwLocale? directly Removed calInfo as a constructor parameter - just calls getInstance.
org.bedework.appcommon.DateTimeFormatter
Also had calInfo as a constructor parameter - just calls getInstance.
