Andrew Cockburn wrote:
> I am just starting to think about this too -
>
> A question :
>
> 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 ?
>
There is definitely some effect on performance, but it's been negligible in the
apps I have played with -- especially given the low cost of throwing more
hardware at a high volume web site.
The messages are cached in memory after being accessed the first time, and are
looked up via Hashtable.get() type calls, so it's pretty efficient.
>
> 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.
My very first internationalized app started on the path of having separate pages
per language, and the controller framework I built (essentially a predecessor to
Struts) took care of things like appending a correct language suffix to the
requested page name when forwarding to a JSP. However, when we went from four
languages, to five, and then on up to eight, it became incredibly tedious and
error prone to make changes in the UI across all the copies.
Creating a preprocessor tool to do some of this for you would ease some of the
burden, but puts you in the tools-maintenance business along with the
application development business. Make sure you have sufficient developer time
if you go this way. (And you will most likely still have some on-the-fly
lookups of dynamic internationalized messages for things like error messages).
>
> Regards,
>
> Andrew
>
Craig
