There shouldn't be any context issues. For each request, the "optimal" page
is delivered. The algorithm that determines "optimal" is left open to the
document author/server developer - the HTTP spec simply says that in the
Accept-Language: request fields list languages in the order of preference.
Furthermore, the spec says "If the server cannot fulfill the request with one
or more of the languages given, or if the languages only represent a subset
of a multi-linguistic Entity-Body, it is acceptable to serve the request
in an unspecified language", though I suppose you could also send an
error code 406, "None Acceptible" and offer links to the versions you
support.
So, your pages should work like this: http://host/path/docA has
pointers to /path/docB and /path/docC, where you don't give *any*
filename extensions, and the server can determine based on the request
headers whether a request for docB means docB.en or docB.it.
I posted a week ago here that we needed a mechanism in URL's to express
request headers, so that some sort of addressing can be used to obtain
specific representations of objects (i.e., *exactly* the Italian version
without requiring that the Italian version have its own URL). I didn't
get any response, but I also hear that the mail list redistributor blew
up last week - did anyone respond to that?
> I have made a little change in the NCSA httpd server to help us.
So have we - Apache supports content negotiation not just on Accept:
but on also on Accept-Language: headers. Now we just need smarter and
more configurable clients.
> When you choice a language (with href=URL?language=xx, where xx is
> the ISO 639 code of the language), your client is registered on
> the server (his IP address) with the choiced language. when you get
> a document, the server should give you the document in the right language
> (the choice or the default if it doesn't exists).
> example:
Ew - it maintains state on the server side, which is absolutely possible
and absolutely inscalable :)
> But the best way in not to register the language of the client on the server ;
> The client should be do a GET URL?language=fr,nl,en, and if the server
> supports multi-language, it should give the fr version, if not, the nl
> version, if not, the en version, if not the default version. But
> this needs to change the client side ...
Check out
http://www.w3.org/hypertext/WWW/Protocols/HTTP1.0/HTTP1.0-ID_24.html#HEADING40
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/