> <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().
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
setUserLocale()?
Are there any other opinions on this?
>
> >>>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 :)
Good idea! I've always thought on why it's not possible to have global
actions or at least pipeline actions :)
>
> >>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" .../>
Yes, that's true
>
> >>>>>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().
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.
Konstantin
>
> >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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
