struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Question about message-resources
Date Tue, 25 Mar 2003 21:04:50 GMT


On Tue, 25 Mar 2003 Mick.Knutson@ubsw.com wrote:

> Date: Tue, 25 Mar 2003 09:25:50 +0100
> From: Mick.Knutson@ubsw.com
> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message