Accesskey n skips to in-page navigation. Skip to the content start

This document contains examples in another language/script.

This document is a translation. In the case of any discrepancy or errors, the latest English original should be considered authoritative. Original copyright belongs to W3C, as shown below.

Go to W3C Home PageGo to Architecture Domain home page  Internationalization 
 

___TITLE

Intended audience: users, XHTML/HTML coders (using editors or scripting), script developers (PHP, JSP, etc.), CSS coders, schema developers (DTDs, XML Schema, RelaxNG, etc.), XSLT developers, Web project managers, and anyone who is new to internationalization and needs guidance on topics to consider and ways to get into the material on the site.

Question

When is it appropriate, or not, to use language negotiation?

Background

Terminology

In this article we refer to the value of a language attribute such as fr-CA as a language tag. The fr and CA parts are referred to as subtags when described as parts of a tag. When described as members of an ISO list of languages or countries, fr and CA are referred to as codes.

Language negotiation is a function of the HTTP protocol which lets a server choose among several language versions of a page, based on the URL and on preference information sent by the browser (specifically in the Accept-Language header). This is distinct from page selection based on the IP address of the browser or from a manual selection by the user on a language-selection page. If there is no match between the preferences expressed by the browser and the languages available on the server, either a language-selection page is shown or a default language is served.

This FAQ addresses the question of when it is appropriate (or not) to set up language negotiation on the server. [Jump to the answer]

Answer

The short answer is: always.

A slightly longer answer is: almost always, but not alone.

Language negotiation does not always work as intended; there are techniques to make up for the shortcomings; one should also provide for stickyness in navigation.

Shortcomings of language negotiation

Lead in. Language negotiation is evidently a useful thing, but before implementing it across the board, it is important to understand its limits. To illustrate these, we will use the example of a site, www.example.be, that offers its content in Flemish, French and German, implements language negotiation and defaults to Flemish for all pages. Our visitor, Sylvia, will be Italian-speaking, but able to deal with German. Several situations may arise:

Level 4 heading.

Numeric substrings do not work well in sentence-like arrangements.

Hopefully the picture is now clear: language negotiation does not always give the intended result.

Navigation

If the site implements a session mechanism (for instance using cookies), then it is a fairly simple matter to arrange for language to be part of the session state. Once Sylvia clicks on the German control, this gets stored (either in the cookie itself or in the server, to be matched by a session number in the cookie) and from then on she gets German when navigating the site. The cookie can even be made persistent (although this makes privacy issues more acute), so that Sylvia gets German pages automatically the next time she returns to www.example.be. Sites that provide a login mechanism can also store language preferences as part of each user's profile, and serve pages accordingly. Language negotiation is then used only for users that have not yet logged in.

Another way to diminish frustration is to make all internal links within the site be language-specific. In the German home page, links to deeper pages would be of the form href="company/about.de.html" (instead of company/about.html, which would be language-generic)*. Navigation is then constrained to remain in German, until overriden by the special language controls.

* Note that the particular forms of language-specific and language-generic URLs shown here (company/about.de.html vs company/about.html) depend on the technology used on the server side to implement language negotiation. Using Apache MultiViews, one would rather see company/about.html.de and company/about.html or, forgoing the .html extension entirely, company/about.de and company/about.

By the way

The HTTP Accept-Language header is not the only source of language information available. All browsers also send a User-Agent header identifying the browser's make, version number and in some cases language version. This can be used to guess at the user's preferred language if the Accept-Language header is missing, but it is less reliable and more limited (one language only) than Accept-Language. Use with extreme care.

Language negotiation is only one aspect of HTTP content negotiation. Other aspects that can be automatically negotiated are the media type (i.e. the format: HTML, PDF or plain text for instance), the character encoding and the transfer encoding (encrypted, compressed, etc.). Language negotiation is the most useful and most used.

Tell us what you think

Was this useful?
Poor Excellent

I am a:




Further reading

Author: ___NAME, ___ORGANISATION. Modified by: ___NAME, ___ORGANISATION. Translator: ___NAME, ____ORGANISATION.

Valid XHTML 1.0!
Valid CSS!
Encoded in UTF-8!

Content first published ___26 February, 2006. Last substantive update ___2004-02-26 15:10 GMT. This version ___2004-02-26 15:10 GMT