[i18n] Entry qualifier (was Re: Status?)

[Mattias J <mj...@expertsystem.se>]

At 2005-04-18 10:33, Daniel Florey wrote:
> > i18n is appealing to me because it allows for multiple properties (such as
> > title and details) under a common key. We solve very similar problems in
> > our project, but I would like to use a generic API reusable among several
> > projects. Although I see some changes I would like to make ti i18n. For
> > example, I'd like the ability to qualify the entry with a source (i.e. 
> base
> > name). This requires some other changes of the internal structure.
>
>Do you want to introduce something like a namespace for message keys? I've 
>been thinking of something comparable in the past but dropped it as it 
>would introduce addintional complexity.
>You can add namespaces by prefixing the message-keys.

My though was to re-use the basename or id used when "installing" 
ResourceBundle or XML providers. For example, after issuing
   ResourceBundleMessageProvider.install("errorMessages");
I would like to be able to qualify the newly installed messages with
   MessageBundle msg = new MessageBundle("errorMessages", "unexpectedError");
but also keep the existing alternative with
   MessageBundle msg = new MessageBundle("unexpectedError"); // 
"unexpectedError" from any source

This may seem like a minor change at a first glance, but to also improve 
performance my thought was to to change the MessageManager class from 
holding a list of provider instances - which in turn can contain multiple 
resources (and thus assumes one instance per provider class) - to holding a 
Map from basename/id/namespace/qualifier to provider instance, where each 
instance only contains a single resource (i.e. XML-file/ResourceBundle).
Though I planned on backwards compatibilty, by looping over the Map values 
- instead of the List entries - in the current MessageManager.getText() method.
(Did I make myself clear?)

I'm also considering adding a DatabaseMessageProvider as a starting point 
for database resouces (which is what I will be using primarily).

  Mattias Jiderhamn 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org