commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [DISCUSSION] PROPOSAL for Commons Locale (or Jakarta Internationalization)
Date Mon, 10 Feb 2003 00:05:27 GMT
From: "Robert Simpson" <>
> The proposal defines a common framework for internationalization of
> Java classes. This internationalization typically occurs by localizing
> instances of Java objects to a specific Locale.  The proposed framework
> facilitate the internationalization of all objects to a single Locale per
> in either a single-user or multi-user environment.  For example, when
> messages, both the message patterns and the inserted arguments should be
> to the same Locale.  This is a good example of why internationalization
should occur
> at a higher level than simply the resources that supply the localized
message patterns.
> Two interfaces, "Localizable" (used by classes that implement both a get
> set method for the Locale) and "Localized" (for classes that implement a
get method
> only) would be defined.  Other implementers would be encouraged to declare
> classes with one of these interfaces where appropriate.  Where this
occurs, any
> Factory classes which generate localized/localizable (localized/able)
versions of
> those objects would be included in that same package, rather than under
the Locale
> component.  This is appropriate, since it makes sense to keep the Factory
and the
> base class or interface it creates in the same package.  In contrast, for
> provided by Sun Microsystems or third parties, where the source code could
not be
> modified, a localized/able subclass of the Sun/third party class would be
> within the Locale component, typically in a subpackage structure that in
some way parallels
> the structure in which the base class resides (in the initial code, this
has already
> been done for most of the Java SDK classes).  This would allow other
> subprojects and components to locate and include such classes in a
consistent manner.

I have difficulty with an API that mandates one locale for the user. In my
day job, the system uses two locales - a display locale and a system locale.
The display locale is the language that the web page should be returned in,
the system locale handles things like what currency should be used (eg.
Canada - two languages, one currency).

I kinda feel there are various possible solutions to handling locale issues,
each of which may be valid depending on your situation:
- context - the application might pass a context object to each method, from
which one or more locales can be extracted.
- aspects - AspectJ solutions could probably factor out locale behaviour
- subclass - this is the route you've adopted

Your code demonstrates that it requires a lot for subclassing to work. A lot
of new classes, new things to learn, etc - as with any framework.
Essentially, you are trying to make classes in the JDK implement new
interfaces, something that always seems to end in tears.

It occurs to me that the majority of what you are trying to achieve with the
subclasses could be achieved using reflection:
  void  LocaleUtils.setLocale(Object object, Locale loc)
  Locale  LocaleUtils.getLocale(Object object);
This seems a less intrusive solution...

On a side note, you may find that the Avalon project at Apache may be
interested in the framework. They are the server side framework group
(framework perhaps being significant here). (They are undergoing major
changes at present though)

> In the initial code, there are a number of classes that abstract various
classes provided
> in different versions of the Java SDKs that can be used for configuration
parameters (Properties,
> Preferences, and the Preferences SPI).  These classes might be most
appropriately placed in the
> Jakarta Commons Util component (with specific implementations in "props"
and "prefs" subpackages).
> If this was not acceptable, those classes could be placed under the Locale

FYI, the Util component no longer exists in commons. Code is now in IO,
Collections and Lang.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message