W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2004

Re: [WAI-IG] Serving my page in the right language

From: Jesper Tverskov <jesper.tverskov@mail.tele.dk>
Date: Sun, 21 Mar 2004 13:09:23 +0100
To: <w3c-wai-ig@w3.org>
Message-ID: <000001c40f3d$5c1d9200$440bc650@tversdata>
 

The most amazing thing about the HTTP language accept-header is probably that it has been an almost complete failure so far. Very few users have heard about it, not many users have actively selected languages in the preferences menu of the browsers. What is served as http language header is almost always the default language of the browser for the http header, usually the language of the browser, or as is the case for Internet Explorer, the system language is used as default for http language header.

 

Negotiation almost never takes place as intended, since the user has not been actively involved. The irony is that the HTTP language accept-header probably works just as well anyway. Thanks to Internet Explorer's patronizing, most users get what they would probably have chosen themselves as first language. But because IE has already made the first obvious choice for most users, they never get involved in the preferences setup and don't even know that the feature exists.

 

One could argue that since the HTTP language accept-header is implemented on the false assumption that the user has once and for all chosen her languages, the implementation probably works less than optimal for some users. Since the user has not actively selected a language in most cases, the user ought to be given the choice at least the first time she visits a web site.

 

One could even argue that the HTTP negotiation makes it marginally more difficult for some users, and probably the weaker ones, to get to their preferred language. They are not presented with the fact that they can choose languages right away but just get a language they have most often not actively selected themselves and then they most find out about the option of other languages after being served a specific language. This thesis could be tested in a usability lab.

 

What is much more important is what happens after the language negotiation. Is the user served a language version with an URL pointing to that version and is the URL visible in the address line of the browser? How is preferred or selected language passed on from page to page?  If cookies are used, the users having disabled them cannot choose another language and make it stick to the next page. Even session-cookies are not accepted by some users.

 

You can also pass preferred or selected language on to the next page using parameters in the URL or you can have different URLs and sets of files for each language. URLs should be shown in the address line. This will make it possible to link to other languages than the preferred one and to bookmark other language versions than the preferred one. It will also make it possible to link to and bookmark more than one language version.

 

Google is an example of a bad implementation.  If you go to  <http://www.google.com> www.google.com, you are always redirected to the language version of Google, like  <http://www.google.dk/> www.google.dk,  based on the HTTP language header. From the language version you have a link to google.com. If the link is followed a cookie is set and from now on Google is the English language version. (A language version can even have menus in another language just to make things even more complicated.) If cookies are not accepted by the user the link to the English version of Google is just dead. If cookies are not supported the user can go to all language versions of Google except www.google.com! Unless your preferred language detected in the HTTP header is English.

 

The HTTP language accept-header opens up for many faulty or bad implementations causing problems for navigation, bookmarking and linking. But if implemented right, if the user is actually taken to a URL pointing to a specific language, and this is visible in the address line, language negotiation has potential benefits since it is often nice to avoid the welcome page in some categories of websites.

 

As I have pointed out in another mail, most international organizations and national web sites where several languages must be available and served equally prominent, and if equal language versions are an important part of the image, would probably prefer to use a welcome page. A welcome page is for these categories of web sites a method to look more authoritative, to look more like international cooperation, more like national unity living up to a law or charter specifying that all official languages must be equally prominent presented.

 

Language negotiation could also fail in some use cases, if the browser is not personal but public: libraries, internet caf├ęs, kiosks, etc. Even if language negotiation succeeded for all users, it would be less obvious for all that we have an international or national web site serving several languages equally prominent.

 

Cheers,

Jesper Tverskov

 <http://www.smackthemouse.com/> www.smackthemouse.com
Received on Sunday, 21 March 2004 07:01:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:32 UTC