cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: i18n transformer update
Date Thu, 24 Jan 2002 16:49:59 GMT
Piroumian, Konstantin wrote:

>>>>>Request object wraps HttpServletRequest and returns the locale that the
>>>>>user has selected in his browser, but that locale can be different from
>>>>>one that the system supports. I don't know if any browser can set a new
>>>>>value to the http header that indicates the user locale. IMO, it's better
>>>>>leave Request object as it is now and have a helper class that will perform
>>>>>custom language selection.
>>>>That's really because environment.Request is an interface that what I
>>>>propose is possible : determination of the locale can be interposed in
>>>>the wrapper before actually calling HttpServletRequest.getLocale(). This
>>>>has nothing to do with tweaking the browser's header or
>>>>HttpServletRequest which BTW is not possible
>>>But what if somebody will need the original user locale?
>>I knew this question would come ;)
>>So what about Request.getBrowserLocale() ? This way, request.getLocale()
>>give access to the locale as defined by the application (using
>>LocaleAction or other means) and getBrowserLocale() gives access to the
>>raw locale sent by the browser.
>>Note that if no locale was set by the application, getLocale() should
>>fall back calling getBrowserLocale().
>I don't like the idea of overriding the expected behavior of
>Request.getLocale(). Most of the people expect that it will return that same
>value as the HttpServletRequest. Maybe do the opposite thing: add
>Request.getAppLocale() and setAppLocale() or better getUserLocale() and
Mmmmh... ||I consider that the contract for request.getLocale() is to 
return the locale to be used to answer the request ? This definition 
doesn't make any assumption on where this locale comes from (remember 
that Cocoon's environment, even if similar, is abstracted from servlets, 
and even in servlets, the @return tag for getLocale() is "the preferred 
|Locale| for the client").

If people use this request.getLocale(), it is because they want to 
provide localized content. If two components used to produce a page use 
respectively request.getLocale() and request.getUserLocale(), it is 
likely you will obtain a mixed-language result !

Allowing to change the value returned by request.getLocale() means that 
the application-defined locale is handled in a nearly transparent manner 
(just add LocaleAction in the sitemap).

Now who uses getBrowserLocale() ? IMO, it is limited to some 
user-settings page where we want to display things like "You have set 
your preferred language to chinese, but your browser is configured for 

>Are there any other opinions on this?
Yes, team, as it means some changes to environment.Request, what do you 
think ?


>>What do you mean by "i18n requests" ? Requests that use the i18n
>>transformer ? Then LocaleAction will be a top-level element in my
>>sitemaps :)
>Good idea! I've always thought on why it's not possible to have global
>actions or at least pipeline actions :)
That was an arbitrary restriction that was recently removed. Now you can 
have a top-level action.


>>>>>>Yes : use the "cocoon-" prefix for the "locale" request parameters,
>>>>>>for "cocoon-view" and "cocoon-action", to avoid potential naming
>>>>>'locale' parameters are configured in sitemap, so you can use any name
>>>>>for them (e.g.: 'locale-attribute" config param)
>>>>Ah, sorry, didn't notice that. But wouldn't it be better to default to
>>>>"cocoon-locale" ?
>>>Have nothing against it. +0
>>I thinks there's a misunderstanding here : I was talking about the
>>_request_ parameter and not the _sitemap_ parameter returned by
>>LocaleAction. From what I can see, the _request_ parameter name is
>>hardcoded to "locale" in getLocale().
>I understood you correctly, but the implementation were different from what
>I was expecting.
>>Also, I don't see a real need to configure the name of sitemap
>>parameters returned by LocaleAction since there is no possibility of
>>naming conflict, since the sitemap component is unambiguously defined by
>>the number of '../' in attribute values.
>Absolutely agree. That was my proposal to have i18n attribute name
>configuration parameter, but the implementation were made not by me and it
>is not what I was thinking about.
So, what about the following changes :
- remove the configuration stuff related to _sitemap_ variable names, as 
it has no added value [is someone using names other than the default ones ?]
- add a configuration for the name of the _request_ parameter for the 
locale, with the default to "cocoon-locale".


Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message