You may also need to override HttpServletRequestWrapper.getHeaders so that it returns a non-empty Enumeration for the Accept-Language header. In other words, always make JSTL think that the client has supplied the header. JSTL should then use ServletRequest.getLocales for the list of preferred locales.
Quoting Andreas Schildbach <[EMAIL PROTECTED]>: > Hello everyone, > > for the i18n of my web application, I have written a servlet filter that > implements the following model: > > - if the user or guest has selected a language from the navigation menu, > use it (it is stored in the users HttpSession). > - else if the user is logged in use his/her language preference from the db. > - else if the browser sends an accept-language header, use it. > - else use the default (english). > > After the filter has detected the locale to use, it wraps the > HttpServletRequest and overrides the getLocale() and getLocales() > methods to return that locale (resp. a one-element-list containing the > locale). > > I am under the impression that this should be completely transparent to > all Servlets/JSP pages that use HttpServletRequest.getLocale(). If I > access this method myself in a JSP page to display the name of the > currectly displayed language, everything works. > > But JSTLs <format:message>-tags have got problems: If a client doesn't > send an accept-language header, no localization context seems to be > created and each <format:message> is replaced by its "???key???" > default. This can be easily reproduced with "curl" or "wget". > > Could it be that the standard JSTL implementation (1.10) uses other ways > to retrieve the user selected locale? > > Regards, > > Andreas -- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
