Currently, the format of this field is an ordered, comma-delimited list of languages,
with optional dialects. For instance, you might enter
which would mean that your first preference is for UK English, then US english, then French, then German.
The language codes are taken from the ISO639 2-character codes and the dialects are taken from the ISO3166 2-character country codes (as used in Internet domains).
In future, you might be able to assign a weight to these, depending on how well you can read the language, for instance:
but for now only the ordering is significant.
When your browser is configured, you will notice that it emits an HTTP_ACCEPT_LANGUAGE string in addition to the usual strings of HTTP_ACCEPT, HTTP_USER_AGENT, etc.
A typical Type Map file looks like this:
URI: start; vary="type,language" URI: English.html Content-type: text/html Content-language: en-GB URI: American.html Content-type: text/html Content-language: en-US URI: Quebec.html Content-type: text/html Content-language: fr-CA URI: French.html Content-type: text/html Content-language: fr URI: German.shtml Content-type: text/x-server-parsed-html Content-language: de URI: Japanese-iso.html Content-type: text/html; charset=iso-2022-jp Content-language: ja URI: Japanese-euc.html Content-type: text/html; charset=x-euc-jp Content-language: jaWith this configuration, assuming that you have set DirectoryIndex to this file (e.g. index.var), a user coming into this directory will see the index in their preferred language automatically, without having to click on a Français Ici link or similar aid. Note that all the entries in the Type Map file must be regular html files, not CGI scripts or redirects.
There are many approaches to building a multilingual structure; one could use Type Map indices in all directories, and keep all language versions of a document together in one directory, or one could use a Type Map file to split the directory structure at the root, and use separate hierarchies for different languages. If the first approach is used, it is possible to see the same document in different languages simply by changing the Accept Languages setting on the browser and reloading the document.
In the proposed HTTPD 1.1, the server should send the http Vary header, as follows:
Vary: Accept-Languagewhich indicates to a proxy cache that content-negotiation is taking place and that the cached document may be incorrect.
Here is a script "select-lang" which performs content-negotiation using http redirects. This resolves the cacheing problem at the expense of requiring another (small) transfer. The script may be modified to guess languages based on ip address. Here is an example of the script in action. Here it is again using the Apache Action directive (cgi-bin is hidden).
It is recommended that the charset be specified in the parent document also, so
that the browser will have the correct font selected before any of the document
is parsed, for instance:
<A HREF="DocumentURL" CHARSET="iso-8859-5">Document Name<\A>
Future browsers are recommended to implement the HTTP Accept-Charset header in order to negotiate properly in those cases (Cyrillic, Japanese) where multiple fonts exist for the language.
The META generator at Vancouver Webpages will generate some charset and language tags.