Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Mime-Version: 1.0 (Apple Message framework v612)
In-Reply-To: <4055BE14.7030701@upaya.co.uk>
References: <60FEA972-72A0-11D8-BE54-000393BD5B24@kolumbus.fi>
 <DF3CA225-72A3-11D8-BE54-000393BD5B24@kolumbus.fi>
 <404FADF6.6030301@che-che.com>
 <5FD58A52-732D-11D8-BE54-000393BD5B24@kolumbus.fi>
 <40503851.8060702@upaya.co.uk>
 <392E5FF6-7366-11D8-BE54-000393BD5B24@kolumbus.fi>
 <40519191.2020605@che-che.com>
 <6795A7D4-7415-11D8-BE54-000393BD5B24@kolumbus.fi>
 <4051A051.5090608@che-che.com>
 <8E832BDC-742D-11D8-BE54-000393BD5B24@kolumbus.fi>
 <40557520.20300@upaya.co.uk>
 <FAC5A1D2-7688-11D8-BE54-000393BD5B24@kolumbus.fi>
 <4055BE14.7030701@upaya.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <E1300DCD-7692-11D8-BE54-000393BD5B24@kolumbus.fi>
Content-Transfer-Encoding: quoted-printable
From: =?ISO-8859-1?Q?Sjur_N=F8rsteb=F8_Moshagen?= <sjur.moshagen@kolumbus.fi>
Subject: Re: i18n suggestion
Date: Mon, 15 Mar 2004 17:10:22 +0200
To: forrest-dev@xml.apache.org

P=E5 15. mar. 2004 kl. 16.30 skrev Upayavira:

> Sjur N=F8rsteb=F8 Moshagen wrote:
>
>> The only point about debugging was that it should be _possible_=20
>> (without us doing anything) to request filename_{locale}.html, in the=20=

>> same way that it is now possible to request menu_{lang}.html.
>
> Fair enough.

I think it should have been menu_{locale}-filename.html;)

>> 1) i18nFile generator:
>
> Okay, as I said in a previous mail, I think we might do better with an=20=

> Input Module: I18NModule. This would enable you to say something like:
>
> <map:match pattern=3D"**/*.html">
>  <map:generate src=3D"{1}/{i18n:{2}.{locale}.xml}"/>
>
> So, we'd be using the file generator still, as all we need is a=20
> filename conversion. And so long as we can come up with a suitable=20
> module syntax, it should be easier to implement.

Sounds fine (you are the expert here, I'm just trying to understand and=20=

learn Cocoon;)

>> Thus, you can localise most things, BUT NOT WHOLE PAGES ON A FILE=20
>> LEVEL. This is where the i18nFile
> Exactly my problem right now too!

;)

> What we need to do is generalise out the stuff to do with filename=20
> handling, and have a module share its code.

Sounds OK - except that I don't understand the last part;)

>> My suggestion is thus to extend the present i18n block with one more=20=

>> function, which should be easily based on what's already there.
>
> Exactly. Except for that it isn't a block, it is core functionality.

Still learning...

>> In the case that there is no localised version of a file, one could=20=

>> just let the i18nFile generator pick a default file/locale, and save=20=

>> the static file _without any locale at all_ (but that should not be=20=

>> the case if even one letter has been localised, i.e. if the menu, or=20=

>> the tabs, or some other included element is coming from a localised=20=

>> src - in all these cases the generated static file should be treated=20=

>> as if it was completely localised).
>
> Hmm. How to handle defaults, that's interesting.

I am not sure about this - the above is just one possible suggestion.=20
Other ideas, anyone? How do we define a default locale for the CLI?

> One remaining point: how do we handle crawling? Do we crawl a page,=20
> then seek all translations of it, or do we crawl from each language's=20=

> homepage, following links that way? Make sense?
...
> a.html <en
> a.html <de
> b.html <en
> b.html <de
> c.html <en
> c.html <de
> d.html <en
> d.html <de

Maybe this? That is, crawl a page, then all translations of it?

Sjur