Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Message-ID: <3FBB5BEF.5070902@upaya.co.uk>
Date: Wed, 19 Nov 2003 12:02:55 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: forrest-dev@xml.apache.org
Subject: Re: whole site i18n
References: <1068917850.3fb6645a5579a@secure.solidusdesign.com>
 <3FB66F31.7030002@upaya.co.uk> <3FBA9FE7.6080500@che-che.com>
In-Reply-To: <3FBA9FE7.6080500@che-che.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Juan Jose Pablos wrote:

> Upa,
>
>>
>> I did discuss with Cheche about making the CLI able to render 
>> multiple versions of a page, one for each of a set of locales. It 
>> shouldn't be too hard to do.
>
>
> We end up trying to simulate what the client was doing if this was a 
> http client, so I took the impression that we need to implement with a 
> browser and then with the CLI.
>
> Are we still thinking that right?

Not sure if I understand.

Basically, when working online, the User agent (browser) interacts with 
Cocoon, giving it the current locale, etc.

With the CLI, the CLI is effectively the user agent, and needs to 
simulate the activities of the browser.

So, if a browser can pass a locale to Cocoon, then the CLI needs to be 
able to also.

At present, the CLI passes a default, unconfigurable locale to Cocoon.

Now, things are different with the CLI from an online scenario. Online, 
we can hand exactly the page the user has requested, translated 
correctly for their locale. With the CLI, we need to pregenerate all 
locales for a page. So if we have 10 possible locales, we need to 
regenerate that page 10 times.

This is not implemented in the CLI, but could be.

If any of you want to have a go, I'll happily give you pointers.

Regards, Upayavira