On Tue, 25 Mar 2003 [EMAIL PROTECTED] wrote:
> Date: Tue, 25 Mar 2003 09:25:50 +0100 > From: [EMAIL PROTECTED] > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Question about message-resources > > I am looking into struts-menu, and am confused about the extent I can use > message-resources. > Like: (struts-config.xml) > <message-resources parameter="TrackerRes"/> > <message-resources parameter="ISOCodeRes" key="ISOCodeRes"/> > > I am creating a multi-lingual app, and am finding there are heaps of > entries in my ApplicationResources.properties already, and it is going > to get much worse as I have only done 2 pages and I have about 16 to go. > > So, can someone please explain what the above multiple message-resources > definition does, and how I might leverage splitting up some of my > message-resources, to make these files more manageable? > One principle I always follow -- the fact that you might put all your messages into a single properties file in the deployed webapp does *not* mean that they all have to be in a single file in your development environment. Consider having your build process combine the resource entries for various logical subsets of your app into a single ApplicationResources.properties file (or one for each language, if you're localizing). That way, the developers of each portion of the overall app can maintain their own localizable translations, without interference from developers working on other portions. On the other hand, if you (or a very small number of developers) are going to develop the resources for all 18 page, who really cares how many entries there are (at runtime, it's a HashMap, so the number of entries is basically irrelevant to performance)? The important factor there (and, in reality, its true for a larger scale distributed development environment as well) is to make sure that you don't have clashes over the message lookup keys -- you should define some conventions on how such keys are created (for example, including the logical forward name defining this page as part of the key) to avoid problems. On the other hand, you want to leverage cases where you can use the same message string (and therefore the same translation) across multiple pages -- having a resource bundle (or fragment of a resource bundle) for shared translations is also very useful. If you do this, I recommend that your message keys include some indication that the correspoding translations are shared (in much the same spirit that many general purpose packages like Struts have a Java package named "util" package for shared things). IMHO, the reasons that one might choose multiple message resource bundles can almost always be mitigated by appropriate build scripts that assemble the ultimate properties files from individual fragments -- the capability to support multiple resource bundles exists in the Struts framework for those cases where it is really necessary, but IMHO you should avoid it (for simplicity's sake) wherever possible. > ========= > Thank You > > Mick Knutson > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
