forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertrand Delacretaz" <>
Subject Re: Using browser headers for i18n? (was: Per-project i18n LocaleAction and LocaleMatcher configuration)
Date Tue, 23 May 2006 08:05:46 GMT
Hi Cheche,

On 5/23/06, Juan Jose Pablos <> wrote:
> ...Bertrand Delacretaz wrote:
> > I'm preparing a simple patch against the trunk, to make i18n more
> > consistent, mostly by using a single definition of the LocaleAction
> > and LocaleMatcher, in the main sitemap.
> >
> Back in 2003 the were objections about doing this way:

Quoting from that message: "...I'd have thought it makes more sense to
define the component where it is used.  Putting subsitemap component
definitions in the root
sitemap breaks the separation of concerns between sitemaps...."

I tend to agree but i18n is a cross-cutting concern, which has to
apply consistently everywhere. So for i18n I think a central
configuration of these components is better.

> ...but It does not work in my side. I am not able to produce local content,
> I will investigate the reason...

ok, if you come up with failure scenarios please post them here so
that we can find out what's wrong.

> >... This allows the locale to be selected reliably by a request parameter
> > (?locale=fr for example)
> ok, but when you try to build a static site, you end up with:
> index.html
> index.html_locale=de
> index.html_locale=fr
> That is why we do not want to use get parameters...

Agreed, in that case, and when you want to have explicit locale
selection in the URLs, it's better to use something like


Which is what I'm after in fact, and currently it seems to work fine
with a matcher such as

  <map:match type="regexp" pattern="(de|fr|en|it)/(**).html">
    <map:generate src:="cocoon://{2}.html?locale={1}"/>
    <!-- post-process links here to get the right locale in them -->
    <map:serialize type="html"/>

Where the ?locale= parameter is generated internally.

It's not a general solution for now, but it requires the browser
headers detection to be disabled, to work reliably.

> ...I had a look on your patch, but for me it is not working.
> If I revert this line:
>  > -                  <map:parameter name="locale" value="{request:locale}"/>
>  > +                <map:parameter name="locale" value="{locale}"/>
> Then your stuff fails, so I guess that we need to find why both options
> can not work well together...

What is your use case, what is not working for you?

I think the goal would be to get either

a) browser-based locale selection
b) URL-based locale selection (parameter or path)

to work, based on configurable options (sitemap patching at worst).
But maybe you have another use-case in mind?


View raw message