Multilingual Web Design Specifications

This document was originally written by Jerome Froment-Curtil on December 8, 1999. Please submit comments and suggestions regarding this document’s content directly to him.

Abstract: This document aims at describing the principles behind BabelCow, explaining how it works and providing guidelines for anyone updating web pages on nodezero to ensure they are doing things properly.

Background

One of the ways for distributed.net to reach out towards more users has been to make the content of the website (http://www.distributed.net/) available in languages other than English. This was meant to allow non English speakers to discover what distributed.net is about and to eventually get them to participate in our projects, despite the obvious language barrier. A system was devised that allowed a loosely coordinated team of translators to create translated versions of the English pages on our website and update them when needed, based on the modifications on the English version of the site. This web-based system and the associated infrastructure in the /htdocs/ directory of nodezero.distributed.net will be referred to as BabelCow in the sequel (in reference to Altavista’s Babelfish translation utility and our beloved DCTI mascot).

Overview

BabelCow uses the Apache content negotiation module which enables the web server to support multiple versions of a given HTML file, thanks to the addition of a ‘.xx’ extension to the end of filenames, based on the mapping of language extensions onto languages.

The envisionned system would enable the users to browse the distributed web site in two ways: via content negotiation and language links.

Content Negotiation

Content negotiation enables the user to choose in the browser configuration and in order of preference the languages in which he or she prefers to view web pages. The browser will then negotiate with the web server to determine, based on the available languages on the server side, which page will be served to the browser. If content negotiation fails, the server will default back to the English version of the pages. This means that a single index.html type page can actually represent multiple copies of that page in multiple languages, based on the index.html.xx file name format.

Pros:

Once the user sets the language preferences, the actual content negotiation is totally transparent and the user can, for example, browse our home page in any supported language by simply typing http://www.distributed.net/

Cons:

If the user cannot change his or her language preferences in the browser, pages will potentially be served in a language not desired by the user or unknown to the user. This typically happens in computer labs where browser settings are inalterable.
If the user does not know how to change his or her language preferences in the browser, the full potential of the multilingual website will never be used. The purpose of our multilingual website is not to educate people on how to set the appropriate language settings in their respective browsers. We do not want to have to provide support for browser setup via help@distributed.net or regional-xx@distributed.net.
Lastly, a user might want to view the site http://www.isupportmultiplelanguages.com/ in French and still decide to want to read the distributed.net web site in English. Apart from manually changing the browser preferences based on the user’s language preference on a site-by-site basis, there is no solution to that conflictual situation.

From the above pros and cons, we clearly see that content negotiation is a great tool that we should support on our multilingual website, but we should also provide alternate means of accessing any web page in as many languages as those currently supported.

Language Links

Another additional means of accessing the translated versions of each page is necessary. A rather straightforward way of doing so consists in adding links on each page to all translated version of that page. Thus, with the click of a mouse, a user can selectively switch to any supported language.

Pros:

The user can decide which language he wants to read the page in, on a page by page basis.
The user can tell by viewing the available links on a given page which languages are available for that page.
This system takes advantage of the content negotiation file naming scheme with the .html.xx extensions, but in no way relies on anything else from content negotiation but that single feature.

Cons:

A user wanting to browse the site in German, for example, will have to click on the ‘Deutsch’ link at the top of each English page to get its equivalent German version, if it exists. This is not practical at all from a user standpoint if for each page the user needs to repeatedly call the translated version manually.

A better idea would be to consider these ‘language links’ as a portal to skip to another website in a different language altogether, and not simply to one isolated web page in a different language. The key to this is to make sure that once a language link is clicked, subsequent links on the new page will keep the user hopping to other pages in the site in the same language. To revert back to another language, the user only needs to click on the appropriate language link. This solves the problem pointed out above, but needs everyone to create HTML link references in a standard and consistent way described in the subsequent section.

For content negotiation and language links to be effective, a few guidelines are described below. They are directed towards anyone who is likely to create or update web pages on nodezero.

Guidelines for creating and updating documents in /htdocs/ on nodezero

Do not edit .html.xx files other than the English one (.html.en).