URI: start; vary="type,language" URI: dk.html Content-type: text/html Content-language: da URI: de.html Content-type: text/html Content-language: de URI: jp.html Content-type: text/html; charset=iso-8859-1 Content-language: ja
This is known to work with Mosaic-2.6-L10N+. The desired language(s) are entered in the Accept-languages box, and the server serves the one which matches first. Mosaic-L10N doesn't, however, select the correct charset using the charset parameter (though it does auto-detect Japanese). E.g., if the browser sends an HTTP_ACCEPT_LANGUAGE header of "en,fr,de" (or "en-GB,fr,de", etc.) and the server has French, Japanese, and German available, the negotiation will yield French, since this is the first one to match.
Language negotiation is now supported in Netscape. Use
Options|General|Language preference for Win/Mac. Under Unix set the X
resource (in .Xdefaults) Netscape*httpAcceptLanguage, e.g.
"Netscape*httpAcceptLanguage: fr, en-US"
(This was previously stated incorrectly). Specifying a quality factor, e.g.
Content-type: text/html; qs=0.5does not work properly with HTTP_ACCEPT_LANGUAGE. It is not (currently - 1996, Apache 1.0.0) possible to generate a weighted preference. The qs factor will overrule the browser preference given by the HTTP_ACCEPT_LANGUAGE ordering. It might still be used in a case where one language variant on the server is so bad that it should only be served to someone who can't read anything else. Blank qs is equivalent to a qs of 1.0. Here, Pig Latin is served to someone who requests x-pig-latin and no other listed language.
To see what languages your browser accepts, see e.g. http://vancouver-webpages.com/cgi-bin/test.cgi
Content-type: text/plain;charset=x-euc-jpThis may be generated using the Asis feature in Apache (set in srm.conf).
This is known to work with Netscape 2.0 for X-11. It overrides the language selection and automatically selects the correct font. Netscape 2.0 (X11) currently uses these locales. Netscape 3.0 does things slightly differently; this page lists the currently (3.0b4) understood languages and charsets.
Other browsers, however, mostly mis-interpret the charset parameter and thinks the document is a binary file.
Netscape 3.0 appears to understand this parameter in a META tag, e.g.
<META HTTP-EQUIV="Content-type" CONTENT="text/html;charset=x-euc-jp">which will probably be ignored by other browsers, thus may be safe to use (assuming the server does not parse HTTP-EQUIV headers into real http headers).
en-CA,en-GB,en-US,fr,de using qs prefers en-CA, Var file
en-CA,en-GB,en-US,fr,de using qs prefers en-GB, Var file
en-CA,en-GB,en-US,fr,de using qs prefers en-US, Var file
en-CA,en-GB,en-US,fr,de using qs prefers French (fr), Var file