cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject Re: i18n transformer update
Date Thu, 24 Jan 2002 13:34:10 GMT
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message