On Jun 17, 2008, at 9:28 PM, Oscar Westra van Holthe - Kind wrote: > On 17-06-2008 at 20:54, Will Hartung wrote: >> >> If LocalizationBundleFactory can be used to return any >> ResourceBundle, why not implement your own version of ResourceBundle >> that is aware of the hierarchy of property files? > > Or if you prefer not to do that, you can (ab)use that hierarchy by > overriding > the Locale to use: as soon as the customer is identified, add a > variant to > the Locale. > > This will ensure the following, using made up Locale names: > 1. When available, custom translations for "en_US_myCustomer" are > used. > 2. Otherwise, suitable defaults from "en_US" are used. > 3. If that fails, maybe you have generic english translations for > "en". > 4. And as a last resort, a ResourceBundle loads global "translations" > (for example the support email address, settings for displaytag, > etc.). > > The properties files used by a standard ResourceBundle would then be: > StripesResources_en_US_myCustomer.properties > StripesResources_en_US.properties > StripesResources_en.properties > StripesResources.properties >
Clever I like it. But does it have the granularity at the string level? i.e. if I have a StripesResource_en_US_myCustomer.properties, and it doesn't have "msg.nextpage", will it walk the hierarchy to find the message or will it stop because it found a property file, even tho it may not have the message? That I don't know. Regards, Will Hartung ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
