You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2005/01/29 21:32:41 UTC
DO NOT REPLY [Bug 33298] -
consider second languages in accept-language header
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33298>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33298
------- Additional Comments From Joe@Germuska.com 2005-01-29 21:32 -------
I understand your reasoning for this kind of feature, but I wonder how it might
be implemented in practice. It doesn't seem like you'd want to test for which
of the user's preferred locales are supported by the application each time you
went to retrieve a message.
I can imagine a very simple (to implement) solution which requires the
application author to configure a list of supported locales (slightly redundant
and error-prone compared to simply looking at what resource bundles are in the
file system); this list would be configured in the chain-config for the
SelectLocale command, and the command's "getLocale()" method could take the list
into account.
Your suggestion assumes that Struts can simply "know" which locales are
supported. Noting that theoretically, Resources can come from sources other
than properties files, it would probably be necessary to expose that directly in
the resources API. There has been talk about replacing all of Struts' message
handling with the commons-resources library, so we'd want to see if that's still
going to happen before making big changes to either API. But since there may be
other reasons besides messages that an application cares about which locales are
supported, I'm not sure I believe that this responsibility should be set upon
that API.
In a Struts 1.2.x (and earlier) application, the RequestProcessor offers the
"processLocale" method which could also be overridden for an immediate local
solution not dependent on a change to the Struts source code.
http://struts.apache.org/api/org/apache/struts/action/RequestProcessor.html#processLocale(javax.servlet.http.HttpServletRequest,%20javax.servlet.http.HttpServletResponse)
Is it too much to ask a developer to enumerate a list of supported locales in
some configuration? If not, I think the solution is pretty clear.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org