> Piroumian, Konstantin wrote :
>
> <snip/>
>
> >>I was thinking about how to merge these two different sources for
> >>locale. Having request.getLocale() and LocaleAction.getLocale()
> >>returning different results is IMO a bad thing since it can lead to
> >>inconsistencies between components that use one method or the other.
> >>
> >>We should have a single source for this information, and this is
> >>obviously the Request object.
> >>
> >>So I see two possible solutions, but there might be other :
> >>- having Request.getLocale() use the behaviour of
LocaleAction.getLocale()
> >>- adding Request.setLocale(Locale) to set the value returned by
> >>Request.getLocale(). This method would be called by LocaleAction.
> >>
> >>What do you think ?
> >>
> >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?
>
> >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.
>
> 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 ;)
>
> >>>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
So, maybe you'd start from LocaleAction (or Request interface) until I'll
send my latest version of i18n transformer?
>
> >>I also had a look at the key lookup stuff (including XMLResourceBundle),
> >>and it seems to me it is really performance-killing. Since I also need
> >>pluggable sources for translations, I will take this subject if you
> >>don't mind.
> >>
> >Sure. I'm not much expert in Avalon, lifecycles, etc. Note, that
> >XMLResourceBundle and XMLResourceBundleFactory are from Avalon scratchpad
> >and they can be out of date now.
> >
Konstantin
>
> 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]
