From: "Ard Schrijvers" <[EMAIL PROTECTED]>
Date: Tue, 12 Sep 2006 10:24:53 +0200
> On 9/12/06, Yves Zoundi <[EMAIL PROTECTED]> wrote:
>
> > ...If you have any ideas please let me know...
I just think it works for you: you do think it doesn't because you cannot
switch between language in your browser due to browser cache, right? In
real live, that doesn't matter, because somebody in fr will get it al the
time in fr, and somebody in en all the time in en....
>
> Specifiying the locale in the URL path would certainly work
> around this problem.
>
> Even though URL purists (understandably) hate them, URLs like
>
> fr/yourpage
> en/yourpage
>
> seem like the safest option with today's browsers.
It is not only about browsers when you have high traffic live sites. with
caching on several levels: If you use squid or mod_cache, you might
configure caching according the language settings (though
I don't know how), but normally, when you cache in mod_cache or squid, you
cache based on the
url (inl request params ofcourse). This implies, that the first browser
with a hit fills the cache according to that language, serving the same
pages to other browsers. If you come with a solution that you *can* specify
mod_cache to cache according language settings, I will reply that you then
still have the problem that *many* persons these days are within companies
having there own proxy, you certainly don't control :-)
The Vary response header would help with this. See
http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6
"A server SHOULD use the Vary header field to inform a cache of what
request-header fields were used to select among multiple representations of
a cacheable response subject to server-driven negotiation. ... When the
cache receives a subsequent request whose Request-URI specifies one or more
cache entries including a Vary header field, the cache MUST NOT use such a
cache entry to construct a response to the new request unless all of the
selecting request-headers present in the new request match the corresponding
stored request-headers in the original request."
So specifying
response.setHeader("Vary", "Accept-Language");
means that when the French-speaking user requests the page from a proxy
that's previously cached the English version, it will fetch a fresh copy.
It's not perfect - if you allow the user to switch languages with a request
parameter and/or cookie value instead of by selecting an alternate language
in their browser settings that will suffer the same problem - but it's an
improvement.
Similarly, if you're using Cocoon's BrowserSelector to e.g. work around
browser differences and return different pages/CSS depending on whether the
user has Firefox or IE, you should include User-Agent in the Vary response
header.
Andrew.
So those evangalists hating /fr/foo, well....whatever :-)
Regards Ard
>
> -Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
