Doesn't the current approach allow values to be "injected" into the messages at
runtime? If so, the preprocessor wouldn't work in
that case, would it?
(If it doesn't currently allow that, well, my point is rather moot.)
> Although it is convenient and neat to place internationalised messages in
> resource bundles and load them on the fly, would this not add a big
> performance hit to a large/heavily loaded system ?
>
> In previous designs I have concluded that this may be a problem and
proposed
> designs based on a preprocessor to create multiple JSP files, one per
source
> file per language. The preprocessor would use resource bundles, but the
file
> reading and extraction would be done statically, not on the fly. Then the
> running system just has to worry about serving pre-compiled JSPs, and not
> doing expensive file operations. This is a lot more cumbersome, but if
> performance is important to you I think it is worth considering.
If you have or are developping such a preprocessor, I'm sure the Struts
authors will be eager to include it in a future release...
In the mean time, we're stuck with the dynamic approach. The burden added to
the server is not that big, depending on the size of your application and
the number of different languages you need to support. All messages are kept
in a cache, so the penalty is paid by the first user asking for a language
not already loaded.
As always, this is a trade between cost (ease of coding) and performance.
Depending on your wealth (and time), you'll write such a preprocessor or buy
a CPU upgrade...
Another solution is to form teams of local web programmers and have them
code the application in their native language. Manual preprocessing ;-)
Pierre Métras
