No idea about that. The JSTL algorithm is defined in Chapter 8 of the JSTL spec
(1.0 & 1.1), so that's probably not changing in the near future. I haven't
looked at commons-resources too deeply so I can't comment on whether that will
help. The key concepts with JSTL seem to be an ordered list of preferred locales
(ServletRequest.getLocales) and a fallback locale combined with deferred loading
of the root resource. I don't think commons-resources currently embraces that
approach (not that it couldn't).

Quoting Adam Hardy <ahardy.struts@(protected)>:

> Presumably the Jakarta Taglibs developers and the Struts people are
> going to centralize on the Commons-Resources package at some point in
> the future, in which case the divergence will disappear?
>
> On 11/11/2003 08:31 PM Kris Schneider wrote:
> > The JSTL algorithm will only use the root resource (your
> > ApplicationResources.properties) as a last resort. It will walk through the
> set
> > of locales returned by ServletRequest.getLocales and try to find a match.
> If it
> > can't, JSTL implements the concept of a fallback locale that it will
> attempt to
> > match. If a match is still not found, only then will the root resource
> get
> > loaded. So, if your set of locales is:
> >
> > en
> > de
> >
> > And you've got the following resources:
> >
> > ApplicationResources.properties
> > ApplicationResources_de.properties
> >
> > Then JSTL will find a match for "de" and use it. If you add the resource:
> >
> > ApplicationResources_en.properties
> >
> > Then it'll match "en" first. If you just make the "en" resource an empty
> file,
> > it'll pick up all the entries from the root. Kooky, huh? If you're using
> a
> > Servlet 2.3 container, why not use a Filter to keep the Struts and JSTL
> locales
> > in sync? Something like this might work (untested):
> >
> > import javax.servlet.jsp.jstl.core.Config;
> > ...
> > HttpSession session = request.getSession(true);
> > Locale locale = (Locale)session.getAttribute(Globals.LOCALE_KEY);
> > if (locale == null) {
> >  locale = request.getLocale();
> > }
> > Config.set(session, Config.FMT_LOCALE, locale);
> >
> > Quoting Adam Hardy <ahardy.struts@(protected)>:
> >
> >
> >>Struts and JSTL seem to have different algorithms to establish the
> >>locale to use.
> >>
> >>I have JSPs which use <fmt:message> for titles, labels, comments etc and
> >>I have also just started to program a page which will include an
> >>underlying language page to incorporate big paragraphs of localized text.
> >>
> >>I thought I would use the struts locale setting in my session for this,
> >>but then I found that with my current browser settings, struts has
> >>chosen EN but JSTL has chosen DE.
> >>
> >>I have EN as my first locale preference in my browser, followed by DE,
> >>being in Germany.
> >>
> >>In my app I have a default ApplicationResources.properties and just now
> >>to create a test, I copied it to ApplicationResources_de.properties.
> >>
> >>Bug or feature, logically expected or are Struts and JSTL purposefully
> >>diverging?
> >>
> >>
> >>Adam
> >>
> >>PS if I rename ApplicationResources to ApplicationResources_en then JSTL
> >>and Struts agree again, on EN.
> >>
> >>PPS I can work-around with this:
> >><c:set var="localeKey">
> >>  <%=org.apache.struts.Globals.LOCALE_KEY %>
> >></c:set>
> >><fmt:setLocale value="${sessionScope[localeKey]}"/>
> >>
> >>to make JSTL follow Struts.

--
Kris Schneider <mailto:kris@(protected)>
D.O.Tech     <http://www.dotech.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@(protected)
For additional commands, e-mail: struts-user-help@(protected)