Piroumian, Konstantin wrote:
<snip/>
>>>Request object wraps HttpServletRequest and returns the locale that the user
>>>has selected in his browser, but that locale can be different from the 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 to 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 getRawLocale().
>>>Maybe it'll be better to pass selected locale externaly it to the
>>>transformer in the sitemap? This way we can use any locale
>>>selection/determination mechanism and have transformer that don't depend
>>>on an action.
>>>
>>>
>>> <map:match pattern="*.xml">
>>> <map:action name="locale-select">
>>> <map:generate src="{1}.xml"/>
>>> <map:transform type="i18n">
>>> <map:parameter name="locale" value="{cocoon-locale}" />
>>> </map:transform>
>>> <map:transform src="simple.xsl"/>
>>> <map:serialize/>
>>> </map:action>
>>> </map:match>
>>>
>>>What about this?
>>>
>>I goes in the direction of what I want to avoid : multiple sources to
>>get the locale ;)
>>
>
>You can setup a matcher for all i18n requests and have single source -
>LocaleAction.
>
What do you mean by "i18n requests" ? Requests that use the i18n
transformer ? Then LocaleAction will be a top-level element in my
sitemaps :)
>>However, pluggable mechanism is possible with my second proposal :
>>adding Request.setLocale(). This method can be called by whatever
>>mechanism you want.
>>
>
>So, you'll need an action to call it - we are back to the LocaleAction ;)
>
Sure. But if LocaleAction changes the locale returned by
request.getLocale(), this value is then globally available, thus
avoiding the need for <map:parameter name="locale" .../>
>>>>>Are there any other wishes/suggestions/comments regarding i18n?
>>>>>
>>>>Yes : use the "cocoon-" prefix for the "locale" request parameters, as
>>>>for "cocoon-view" and "cocoon-action", to avoid potential naming conflicts,
>>>>
>>>'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().
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.
>So, maybe you'd start from LocaleAction (or Request interface) until I'll
>send my latest version of i18n transformer?
>
Please go on, as I don't have much time for this now.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
