I agree with you, Andy the simplest way to handle i18n is to load a different properties file, while mantaining the default one for not defined entries (well, this is the standard behavior for java.util.properties). You only will need to duplicate entry for i18n messages, not for common config options. It's not so hard to make this working properly (for 1.0), the only possible issue could be performance, since actually property are not reloaded each time.
Let me know if you plan to work on this task fabrizio On Fri, 17 Sep 2004 13:17:37 -0500, Andy Pruitt <[EMAIL PROTECTED]> wrote: > A simpler approach may be to merge the properties files at runtime, with property > values from more specific locales overriding those from the more general locales. > ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
