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
>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 ;)
However, pluggable mechanism is possible with my second proposal :
adding Request.setLocale(). This method can be called by whatever
mechanism you want.
>>>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" ?
>>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
>
>P.S. Btw, what is the coding standart for Cocoon sources? I use Sun's
>format, but somebody has reformatted several sources to something different
>and unusual.
>
The Sun format should be used. What sources are you talking about ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
