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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
