Return-Path: 
 <cocoon-dev-return-21619-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 19171 invoked by uid 500); 24 Jan 2002 15:19:05 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 19151 invoked from network); 24 Jan 2002 15:19:02 -0000
From: "Piroumian, Konstantin" <KPiroumian@flagship.ru>
To: cocoon-dev@xml.apache.org
Message-ID: <019601c1a4ea$6f920e70$6150000a@flagship.ru>
References: <006101c1a4b9$33e84690$6150000a@flagship.ru>
 <3C4FF48F.9050600@anyware-tech.com>
 <00c701c1a4d0$05752280$6150000a@flagship.ru>
 <3C50086D.1060608@anyware-tech.com>
 <013701c1a4db$ce14d770$6150000a@flagship.ru>
 <3C501C92.8070109@anyware-tech.com>
Subject: Re: i18n transformer update
Date: Thu, 24 Jan 2002 18:18:54 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> <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: 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