forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: [I18n] Alternatives locales for a given page.
Date Wed, 28 Apr 2004 09:56:01 GMT
Upayavira wrote:

> Juan Jose Pablos wrote:
>> Upayavira,
>>>> Just curious: how is it going?
>>> Oh. Done. Recursive input module support is now in Cocoon CVS.
>>> I'm now trying to get my head around encoding - my first language is 
>>> Polish. Once I've got that sorted, I'll be looking at how to get 
>>> navigation between languages working.
>>> Regards, Upayavira
>> Could you post more info on how to use it?
>> I can test if we can use it with latest cocoon.
> Well, the nested input module support isn't that spectacular, it just 
> means you can do {request-param:{1}}, for example, which you couldn't 
> do before.
> Here's some further thoughts, had during a nice warm bath:
> The below assumes that the content is stored in the following structure:
> /xml/en/*.xml
> /xml/de/*.xml
> /xml/pl/*.xml
> Syntax isn't quite right yet, but the idea is there:
> <!-- This one handles urls like -->
> <map:match type="locale" pattern="*/**.html">
>  <map:generate src="xml/{1}/{2}.xml"/>
>  ...
> </map:match>
> <!--This one handles urls like -->
> <map:match type="host" pattern="*">
>  <map:match pattern="**.html">
>    <map:generate src="xml/{../1}/{1}"/>
>    ...
>  </map:match>
> </map:match>
> <!-- This one handles urls like, using the 
> locale to
>        identify which language, with appropriate fallback -->
> <map:match pattern="**.html">
>  <map:generate src="{i18n:xml/LOCALE/{1}.xml"/>
>   ...
> </map:match>
> This _should_ be compatible with the CLI and Apache, I think.
> What do you think?

And to state how this would work with the CLI:

The last match, the one that uses an 18n input module {i18n:...}, would 
be used by the CLI to generate multiple versions of the same page by 
supplying different locales to each page, and saving then as 
foo.html.en,, etc, ready for Apache.

For the match that uses my as yet fictitious locale matcher, the pages 
would be generated again, a second time, but this time with the locale 
in the URL, so that links to language pages can work, overriding the locale.

[Just looked behind the scenes on the httpd docs, and they support both 
locale based and url based i18n, but with a single file. I'll have to 
work out how they do that, and whether it can be done with a .htaccess 

As to the two approaches to crawling - start at each language's homepage 
and follow from there, or request each language for each page, I suspect 
I'll implement both and let the user choose.

So, that's my thoughts.

Regards, Upayavira

View raw message