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 Note however, that to some people this is considered an ugly hack. I don't mind personally, as I've never seen a real-world use of the variant field anyway, but check with your design guidelines first. Oscar -- ,-_ I love deadlines. /() ) I like the whooshing sound they make as they fly by. (__ ( -- Douglas Adams =/ () ------------------------------------------------------------------------- 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
