I like the idea of a ThreadLocal, or the equivalent via a Threaded/Pooled
service which holds the "currentLocale." Maybe we could make Messages a
full-fledged service and allow something like HiveMindFilter to set the
"currentLocale" on it...
public interface Messages
{
public void setCurrentLocale( Locale locale );
}
When it goes back into the pool (if it's pooled), it would revert back to
the default locale. The messages implementation should change the way it
looks up messages, by using the "currentLocale." I think Messages already
only loads messages from the current module, correct? Doesn't that address
what we need? It's early and I haven't had my first cup of coffee yet, so I
might be missing something.
-----Original Message-----
From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 11, 2004 8:42 AM
To: [email protected]
Subject: Re: Use of a Locale...
I can see stripping out %key. Likewise, the resource translator does
a localized lookup, and that could be removed (it's easy enough to do
using the Resource API).
I still like the idea of being able to inject a Messages instance into
a service and have it "do the right thing" w.r.t. Locale ... but
Locale would be thread local. Can we pursue that?
I think that Locale may no longer be needed by RegistryBuilder ... or,
of it is, it's merely a default locale that isn't necessarily used
when constructing the Registry.
On Fri, 10 Sep 2004 18:59:18 -0400, James Carman
<[EMAIL PROTECTED]> wrote:
> Well, how often do you really need to actually store the localized
messages
> within your implementation code? I wouldn't think that folks would use
> localized message values for configuration data (db usernames, etc.). I
> guess you could use that sort of information to make a service act more
> "snooty" if it's in a French locale. ;-)
>
> Even the HiveMind framework itself uses the MessageFormatter class to
> dynamically lookup message values rather than storing their values. I
would
> vote +1 (soon to be binding) to remove the %key mechanism. I never could
> come up with a good use for it, myself. I think we could come up with a
> more robust i18n service implementation outside of the core framework (in
> either lib or a "contrib" package).
>
> One problem with creating an i18n implementation is that you wouldn't want
> modules to step on the localization keys of each other (two modules define
a
> message with the "errorMessage" key for example). That brought up an
idea!
> How about a new "module" service model? Each module would have its own
> instance of the implementation object. And, for those services which need
> to ONLY load resources from their own module (a sort of swim lane, if you
> will), we could provide them with a ResourceLoader (or whatever you want
to
> call it) which does just that. It's just a thought (or 2 or 3).
>
>
>
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 10, 2004 10:21 AM
> To: [email protected]
> Subject: Re: Use of a Locale...
>
> Messages are loaded just-in-time, using the Registry's locale.
>
> For me, the issue is that the Locale is fixed which works fine (I
> guess) for a standalone program, but becomes problematic for web apps
> (Tapestry apps) where different concurrent users need messages in
> different locales.
>
> I suppose we could implement a kind of thread-local to store the
> user's locale. This would be used when accessing localized messages
> from code (i.e., via a Messages object).
>
> The problem is the %key mechanism in contributions, which is another
> way to allow access to localized messages. These become strings, or
> parts of strings, that then can "flow" (via contributions, schemas,
> collaborating services, etc.) into all kinds of unpredictable places.
> So what locale is used for them ... and how do they get properly
> localized? I don't have a solution.
>
> To some degree, what's needed iis a way to keep messages virtual (keys
> + parameters) right up until there's a known locale, then fold them
> down to localized strings. I can see this as a service on top of
> HiveMind. I'd like one solution that covers everything, magically,
> but I don't seem to have it!
>
> On Fri, 10 Sep 2004 16:09:01 +0200, Mika�l Cluseau <[EMAIL PROTECTED]>
> wrote:
> >
> >
> > James Carman wrote:
> > > The locale-specific registry building has always had a bad smell to
me.
> > > I just don't know if it belongs in a "microkernel" like HiveMind.
Sure,
> > > we should provide a service that allows access to internationalized
> > > messages, but that doesn't have to be part of the core framework.
Maybe
> > > I'm not seeing the benefits. Am I missing something?
> > >
> >
> > I thought it was for module messages (i.e. to localize logs). Indeed,
> > they need to be loaded by HiveMind just-in-time, depending on the
> > system's default locale.
> >
> > I may miss something too ;-)
> >
> > --
> > Mika�l
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
> http://howardlewisship.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
