Piroumian, Konstantin wrote: >><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 getBrowserLocale(). >> >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()? > Mmmmh... ||I consider that the contract for request.getLocale() is to return the locale to be used to answer the request ? This definition doesn't make any assumption on where this locale comes from (remember that Cocoon's environment, even if similar, is abstracted from servlets, and even in servlets, the @return tag for getLocale() is "the preferred |Locale| for the client").
If people use this request.getLocale(), it is because they want to provide localized content. If two components used to produce a page use respectively request.getLocale() and request.getUserLocale(), it is likely you will obtain a mixed-language result ! Allowing to change the value returned by request.getLocale() means that the application-defined locale is handled in a nearly transparent manner (just add LocaleAction in the sitemap). Now who uses getBrowserLocale() ? IMO, it is limited to some user-settings page where we want to display things like "You have set your preferred language to chinese, but your browser is configured for brazilian". >Are there any other opinions on this? > Yes, team, as it means some changes to environment.Request, what do you think ? <snip/> >>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 :) > That was an arbitrary restriction that was recently removed. Now you can have a top-level action. <snip/> >>>>>>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, what about the following changes : - remove the configuration stuff related to _sitemap_ variable names, as it has no added value [is someone using names other than the default ones ?] - add a configuration for the name of the _request_ parameter for the locale, with the default to "cocoon-locale". Sylvain -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
