Return-Path: 
 <users-return-71612-apmail-cocoon-users-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-users-archive@www.apache.org
Received: (qmail 50619 invoked from network); 17 Aug 2004 14:08:29 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 17 Aug 2004 14:08:29 -0000
Received: (qmail 93657 invoked by uid 500); 17 Aug 2004 14:08:14 -0000
Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org
Received: (qmail 93468 invoked by uid 500); 17 Aug 2004 14:08:12 -0000
Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:users-help@cocoon.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@cocoon.apache.org>
list-post: <mailto:users@cocoon.apache.org>
Reply-To: users@cocoon.apache.org
Delivered-To: mailing list users@cocoon.apache.org
Received: (qmail 93453 invoked by uid 99); 17 Aug 2004 14:08:12 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [66.111.4.30] (HELO frontend1.messagingengine.com)
 (66.111.4.30)
  by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 17 Aug 2004 07:08:09 -0700
X-Sasl-enc: /t2DHN3/rdVgqJO2gzN/2A 1092751686
Received: from [127.0.0.1] (unknown [213.48.13.39])
	by www.fastmail.fm (Postfix) with ESMTP id C07D2C14870
	for <users@cocoon.apache.org>; Tue, 17 Aug 2004 10:08:06 -0400 (EDT)
Message-ID: <41221187.7020504@upaya.co.uk>
Date: Tue, 17 Aug 2004 15:09:11 +0100
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Good practise for international site (URI-designing)
References: <95F3F750-EF63-11D8-8C07-000A95C53096@iki.fi>
 <4120CAB5.2090608@petit-atelier.ch> <4121A10B.4090504@upaya.co.uk>
 <4121E2FD.1080007@petit-atelier.ch> <4121F103.3090100@upaya.co.uk>
 <41220F1E.8090301@petit-atelier.ch>
In-Reply-To: <41220F1E.8090301@petit-atelier.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Olivier Lange wrote:

> Perhaps one point to take into account to help deciding:
>
> The idea behind the URI scheme I used is that *every* page of the site 
> is available in *each* language (even if it is not translated, I 
> derive the text from another language). Once a user choosed a 
> language, say "fr/", he safely navigates thru pages which are all in 
> the fr/* URI space for instance.
>
Interesting. I was going to have Apache do that for me. But (especially 
with the LocaleMatcher) I could have Cocoon do it and be done with it.

The only issue that gives me is how to deal with legacy URLs for the 
currently English site, which doesn't have /en/ in the URL.

> For me, it implied that I generate the message catalogs from a little 
> database (Access in that case), which contains all texts. And some 
> text can be marked as being derived from the one in another language, 
> and I resolve them when exporting the catalogs.

I have my own linkmap system (inspired by the Forrest one), and with the 
LocaleMatcher, it has been pretty easy to base the site around source 
XML (actually, HTML) files, with the LocaleMatcher offering the pipeline 
the correct source file for further processing. With the information in 
my linkmap, and the different translated source files (stored, for 
example in /xml/<lang>/foo.html), I have got a translated site working.

>
> With the index.html.fr|en|es|de approach, I believe Apache can 
> fallback on a default language if one is not available for the locale.
>
> And there is only one URI space, am I right? You access 
> /description/index.html, not /description/index.html.fr? This is 
> completely transparent to the user, but he cannot put an explicit link 
> on the french page for instance. It depends on the locale he defined 
> in the browser.

You are right. What I've been thinking of is using both. One version 
that uses the browsers locale, on the default URI space, and one with 
the locale provided as a part of the URI. I'm starting to wonder about 
that - is it really necessary...

(I will read your other message on link rewriting - I would really like 
to understand how the LinkRewriter helps in these scenarios.)

Regards, Upayavira

>
>> Olivier Lange wrote:
>>
>>> > Interesting. But if I set my browser's locale to French, that 
>>> isn't taken into account, is it?
>>>
>>> Indeed, it is a static publication, all done with the CLI (many 
>>> thanks Upayavira!), there are no locale matchers.
>>>
>> :-)
>>
>> It is my intention to change the CLI so that you can say:
>>
>>     <uri type="append" src-prefix="" src="index.html" 
>> dest="build/dest/"  locales="en,fr,es,de"/>
>>
>> and it will create:
>> index.html.en
>> index.html.de
>> index.html.fr
>> index.html.es
>>
>> This is the format that Apache server expects files in if it is to 
>> use its own I18n functionality.
>>
>> But, yours is pretty simple, and works. Hmm.
>>
>>> I let the user themselves choose the language on the very homepage 
>>> (a Flash animation). Then there is a homepage for each language.
>>>
>> As I say, it is simple, and works. And I could get my site working 
>> much quicker if I followed this approach.
>>
>> Regards, Upayavira
>>
>>>
>>> Upayavira wrote:
>>>
>>>> Olivier Lange wrote:
>>>>
>>>>> Hi Joose
>>>>>
>>>>> I used option 2 for a large site, with a complete user request 
>>>>> space available in all langages. If some content is not available 
>>>>> in some language, I put an explicit mention about the missing 
>>>>> translation on that page, plus a text in some other langage.
>>>>>
>>>>> For instance: this page is available in french, german, italian 
>>>>> and english, but not rumantsch; so there's a mention:
>>>>> http://www.gallerie-ph.ch/rm/events/construct-sonor/klanginstall/index.html 
>>>>>
>>>>>
>>>>> All this handled thru Linkrewriter and i18n message catalogs, so 
>>>>> there is no link manipulation needed in the XSLT. By the way: the 
>>>>> linkmap gets translated in each language also, of course. The 
>>>>> message catalogs are generated.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Interesting. But if I set my browser's locale to French, that isn't 
>>>> taken into account, is it?
>>>>
>>>> I must look into the link rewriter, maybe it'll be helpful here.
>>>>
>>>> I'm working on an i18n site at the moment, and have created the 
>>>> I18nMatcher (soon to become the LocaleMatcher) for just this 
>>>> purpose. I also intend to get the Command Line Interface to be able 
>>>> to handle the creation of pages in different languages.
>>>>
>>>> Maybe just the homepage could respond to a browser locale, and the 
>>>> rest are served as en/page.html, fr/page.html, etc.
>>>>
>>>> Hmm.
>>>>
>>>> Upayavira, who is a complete newbie when it comes to i18n.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org