cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] Document based I18n sites with Cocoon
Date Fri, 09 Jul 2004 11:04:35 GMT
Sjur Nørstebø Moshagen wrote:

> På 9. jul. 2004 kl. 13.12 skrev Upayavira:
>>> 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.

Why do you named it {full-locale}, not simply {locale}.

>>> 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}.

This list should be compatible with LocaleAction: language (not lang), 
country, variant.

>>> {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.
> OK.

If no default is given, it should defaults to empty locale.

>> 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;)

Well, you can do it even today, but sitemap snippet for this would be 
rather large.


View raw message