Set the preferred locale with the javax.servlet.jsp.jstl.Config class, via the static set(HttpSession, String, Object) method. Locale is "es_ES_foo". When accessing any page that uses <fmt:message/>, the default bundles are used, which happen to be in English. Doesn't matter if the bundles are set as the default for the page, to a scope variable, or via Config or an init param. However, passing in just "es_ES" via the Config class does cause the Spanish bundles to be properlu found and included in the LocalizationContext objects. There are no basename_es_ES_foo bundles, but in other, custom code, looking up basename_es_ES_foo will successfully fall back to basename_es_ES instead of completely failing and just returning basename. This happens under Weblogic 6.1 sp2 and Tomcat 4.1.18.
Would love to help, but trying to parse the description of the problem as well as to build a test case that reproduces it is asking way too much :-( Please provide a war file with a simple test case that reproduces the problem. Then we'll be happy to fix any bug that may exist. Changing state to WORKSFORME until you can provide us with that information.
Created attachment 5078 [details] Tarred and bzipped WAR that demonstrates problem
Ignore the attachment, it is worthless. The WAR file I created is just over 1 mb and I cannot seem to upload it directly to Nagoya. The attachment, 5078, was my attempt to compress the war but something went wrong and Nagoya won't let me delete the attachment.
Get the WAR that demonstrates the problem from http://www.gideonfamily.org/tom/bug_17440.war instead of the botched attachment. Sorry for the confusion. By the way, I tried removing the JSTL jars I thought were non-essential to reduce the size of the WAR but the JSP then failed to compile. I can furnish a version of the WAR without the JSTL jars if that is required.
Indeed there was a bug. Thanks for bringing this to our attention. The code did not take into account the fact that an exact match could fail because of the variant, and not necessarily because of the country.
AFAICT this was fixed on the 1.1 branch only. When I saw pierre on infra discussing getting back onto minotaur, I was reminded of this. I backported changes from the 1.1 branch to the 1.0 branch by simply overlaying org/apache/taglibs/standard/tag/common/fmt/SetLocaleSupport.java and org/apache/taglibs/standard/tag/common/core/Util.java. This may bring along some baggage but I've had no trouble as yet. br, Matt
Looks like this was fixed.