Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40EE7BC3.60507@reverycodes.com>
Date: Fri, 09 Jul 2004 07:04:35 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Document based I18n sites with Cocoon
References: <0EC4528B-D18D-11D8-AC4F-000393BD5B24@kolumbus.fi>
 <40EE6FA1.3040809@upaya.co.uk>
 <C9DB5D09-D196-11D8-B1F0-000393BD5B24@kolumbus.fi>
In-Reply-To: <C9DB5D09-D196-11D8-B1F0-000393BD5B24@kolumbus.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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.

Vadim