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]
