that's true. i wouldn't like to have the code assume which bundle either.
but now in hindsight, perhaps one bundle per language would be better than having the ability to specify many different bundles (per language). because in the end, all of the message keys would work just as well if they were all in the same bundle provided that care was taken to ensure that each message key was unique.
hmm... it really seems the ability to specify which bundle to use is more trouble than it's worth because now everytime we want to display a message we need to worry about the correct bundle.
if organizing messages into separate files is really desired, then perhaps some sort of 'include' directive in these property files would be better.
having only one bundle would also make it easier to build compound key messages (messages with multiple keys i guess, which is essentially what my original post was about -- however, it came about not from a bundle issue, but an optimization issue)
and also to put in logic to display the key literally, instead of throwing an exception when the key is not found.
to sum up, we would have: - one bundle per language (get rid of need to specify bundle in all places) - the ability to include other property files from within property files - modify to display all message keys literally if not found in bundle (and assume all parameters are keys)
that would be perfect, wouldn't it?
Well, no, because what about when you have a number, like: "Your search returned {0,choice,0#no results, 1#one result, 1>{0} results}"? (amazed if I got the choice format syntax right from memory!) The main reason for replacement values is this: to include data like numbers and dates, not to make it easier to get by with less messages. So definitely not a good idea to assume that all parameters are keys.
Note that there is no need to specify bundle in all places -- just the support for it if people find more bundles a better way to manage their files. Perhaps it would be nice to have some include syntax, but that would, of course, require action from Sun, since we're using standard properties files here. I suspect folks with large internationalized applications find some comfort in being able to partition their message bundles.
You might want to look at commons-resources, which has been factored out of Struts and which will soon be used in place of its predecessor code in Struts 1.3.x It provides enough API flexibility that you might actually be able to specify a message resolution system which did the recursive lookup for you. It also supports alternate message sources like XML and databases -- XML, at least, provides a decent include syntax with entities, although I am still not very clear on the rules for resolving relative paths for entities which represent files... Perhaps instead of trying to find a universal way to make Struts do it, you could come up with a Message Resources implementation which accepted some limitations (less bundles) in exchange for different functionality (recursive lookup of replacement keys).
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
