cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Nørstebø Moshagen <>
Subject Re: [RT] Document based I18n sites with Cocoon
Date Fri, 09 Jul 2004 10:57:36 GMT
På 9. jul. 2004 kl. 13.12 skrev Upayavira:

> The way it is currently coded, if de_AU was not found, it wouldn't 
> find de. Which is not ideal. I'll extend it so that for ru_EE-KOI8 it 
> will try:
> * ru_EE-KOI8
> * ru_EE
> * ru
> in turn. Is that the correct behaviour?


>> This way it is possible for the subsequent i18n processing to cater 
>> for country-(or whatever)-specific requirements in menus etc. without 
>> the document itself necessarily being adjusted for such variation.
> Then, we can have {matched-locale} being the one that was actually 
> matched, e.g. ru_EE, {full-locale} being the full, original locale 
> that caused the match, e.g. ru_EE-KOI8. That's easy, it is just a 
> question of chosing decent names.

This looks fine, and your suggested names look good as well.

>> 2) What happens if the locale of the returned document is not 
>> available in the rest of the i18n chain? There are at least two 
>> possible solutions:
>> - just use the default locale
>> - provide in {locale} not only the returned locale of the document, 
>> but the whole list of preferred locales _from the document match on_. 
>> In the example above that would have given:
> Making various bits of the locale available would allow the site 
> developer handle this as they please. {lang}, {locale}, {encoding}, 
> etc, etc as well as the above.

I guess the full list would be: {lang}, {country}, {encoding}, 
{variant}, {full-locale}, {matched-locale}. {locale} could be a 
shorthand for {full-locale}.

>> {locale} = de_AU, sv_FI, ru_EE-KOI8
> That would be {locales}

Excellent! Do we want/need to also provide the complete, unabbrigded 
list of request locales, e.g {all-locales}? And further: we need to 
check that the existing i18n transformer is given what it expects when 
giving it more than one locale.

> Site default locale is defined within the config of the matcher at the 
> top of the sitemap. It could easily be overridden with a 
> <map:parameter name="default-locale" value="xxxx"/> within the matcher 
> itself.


>>> When I've finished implementing this, I'll go onto extend the CLI to 
>>> be able to work effectively with this kind on i18n site, enableing 
>>> it to crawl a site for each of a range of locales. But that's for 
>>> another time.
>> Looking forward to it;)))
> Let's get this first bit working, first!


> Thanks. I'm glad to have got this one off the ground, at last, and to 
> have at last worked out a way that isn't just way too complicated for 
> sitemap developers to understand.

With this in place, Cocoon can finally claim full support for i18n;)


View raw message