forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: i18n errors, bad downgrading
Date Fri, 12 Mar 2004 10:40:22 GMT
Juan Jose Pablos wrote:

Sjur: I do plan to reply to your previous post - honest!

> Sjur Nørstebø Moshagen wrote:
> <snip how I8n works/>
> I think that most of this has been already implemented on httpd, so I 
> do not think that we should be doing it again.

Forrest might not want to, but if there's I18N functionality where 
Cocoon is deficient, that is not good. I want to understand how Cocoon 
is supposed to be deficient, and if necessary, fix it.

> Before This I think that mostly we need to define the goal. What is 
> the output file name  that you want for static and there URI request 
> for dynamic sites?.

Surely I've covered that in my CLI extensions proposal?

> For Apache httpd server to work:
> index.html.{locale}  should be fine for static, but if you want to 
> request this uri: localhost:8888/index.html.{locale} This will fail 
> badly mainly because forrest relay on .html as the final extension.

Noooooooo. The way I've got it planned is to feed the locale from the 
CLI into the Cocoon 'environment' in _exactly_ the same way as the HTTP 
environment does. So, to see a particular page, via your browser, you go 
to localhost:8888/index.html, having specified your preferred locale in 
your browser.

> So you could:
> 1) Use index.{locale}.html on dynamic sites and create .var filenames 
> with the list of files per directory.

Shouldn't be needed.

> 2) Forget Dynamic and only use static

No. We shouldn't do that.

> 3) Use CLI to run as many times as locales defined on a config file.

That is what we'll have the CLI do for us.

Basically, as far as a Forrest site is concerned, it _should not_ need 
to know if it is going to be deployed static or dynamic. It should work 
exactly the same in either environment. When you can to create a static 
site, you configure the CLI to produce the site in a way that is 
suitable for your particular web server (mainly httpd).

Make sense?


>> One more example - the site I'm working on:
> <snip Example/>
> I think that this user case seems very common. ( I hope that you would 
> not expect us to do you homework :-) )
> But at the moment we are more focus on the "limits of static content 
> creation". :-)
>> One question that comes to mind, is: what happens when a page is 
>> _not_  available in the requested locale? Presently Cocoon/Forrest 
>> fails.
> This is a bug, and on another mail I told you, that this funcionality 
> was missing.
>  If
>> given only one locale, it can be argued that this is correct 
>> behaviour  for a server, although a better aproach would be to have a 
>> default  fallback language/file (which you would need to have anyway 
>> - if not,  what would you serve a user without a locale specification 
>> at all, or  with only locales that are foreign to your site?).
> There is an error code for this 406, but I am afraid that the best 
> approach is to show the user any content rather than an error page.
>  The fallback file
>> could either be the regular content in the language decided upon by 
>> the  webmaster, or a simple page telling the user that the page/site 
>> is only  available in some specified languages, perhaps with a link 
>> to a page  explaining how to set the languages/locales for a browser.
> I would not do that, I would display the content

View raw message