> Piroumian, Konstantin wrote:
>
> >Hi, C2ers!
> >
> >As I have a little free time, I'm going to make some code clean up in
i18n
> >transformer and LocaleAction. I've already added JavaDoc comments to all
> >public members and polished a little class comments.
> >
> Cool ! We're using i18n on our projects and I started digging in the
> code last Monday. I wanted to propose some changes (see below).
You're welcome ;)
>
> >Next I am going to create an I18nUtils class that will contain all
general
> >purpose i18n routines, such as locale string parsing, date/number
formatting
> >and parsing, etc. Currently, it will be placed in org.apache.cocoon.i18n
> >package.
> >
> +1.
>
> >Also, I'm going to add a new <i18n:get-locale> element that will use
> >LocaleAction.getLocale() to return the current selected Locale (it can be
> >different from request.getLocale()). (It'd be good also to move
getLocale()
> >to the new I18nUtils, but now getLocale() has a lot of dependencies from
> >Cocoon, but I want to keep I18nUtils as much general as possible).
> >
> 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.
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?
>
> >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)
> 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.
>
> 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]
