W3C home > Mailing lists > Public > www-international@w3.org > January to March 2004

How to organise a multilingual website

From: Richard Ishida <ishida@w3.org>
Date: Tue, 10 Feb 2004 13:35:32 -0000
To: <www-international@w3.org>
Message-ID: <004001c3efda$cd36de60$cd01000a@w3cishida>

I am exploring alternatives for organising static (ie. Not dynamically built from a database) multilingual files comprising a site.  I'd welcome any comments and suggestions.

Let's assume a concrete situation, to help us be practical.  I have a bunch of static files on an Apache server that can be viewed in English or French. The base URL is http://www.example.org/uniview/ Some files are not language sensitive: this includes .js, and .gif files.  There is one image, however, which has to be different in the French version. All internal links are relative.

I'm assuming that,
1. to help avoid errors and reduce time during the localization process, we'd prefer to avoid the need to change links during translation
2. to save server space and facilitate maintenance we'd prefer not to have duplicate copies of the same file
3. we'd want to be able to do language negotiation for files on the server, using the Accept-Language information in the HTTP header, to get people to the right starting point.

Let's also assume that there are two possible usage scenarios: 
1. the files are read from the server
2. the files are read from server or CD

I put together a few models for discussion. The tabbed lists show possible directory structures. The files local.xx.css import the file shared.css and add any language overrides or extensions needed.


[1] Content negotiation
-----------------------
uniview
	index.html
	index.fr.html
	conversion.html
	conversion.fr.html
	u.js
	u.fr.js
	descriptions.js
	descriptions.fr.js
	local.css
	local.fr.css
	shared.css
	functions.js
	conversion.js
	images
		img1.gif
		img2.gif
		img2.fr.gif

This seems to be the simplest model.  All links are specified without extensions. No links need translation.

Apache can do language negotiation for relative internal links. This, unfortunately, would not work if read from a CD, and the site would fail.

Users reading from the server could be automatically directed to the appropriate starting point based on their Accept-Language preferences. (CD users would have to specify the correct index file for any of these alternatives.)

Seems like this would be best for server-only sites; not an option though for CD-based sites.  Translation cost would be minimal.





[2] Silos
---------
uniview
	en
		index.html
		conversion.html
		u.js
		descriptions.js
		local.css
	fr
		index.html
		conversion.html
		u.js
		descriptions.js
		local.css
		images
			img2.gif
	shared
		functions.js
		conversion.js
		shared.css
		images
			img1.gif
			img2.gif


In this model all links are specified with standard extensions. No links need translation apart from those linking to /fr/images/img2.gif.

The relative internal links would work equally well on server or CD.

I can't see how you could automatically route people to the right starting point on the server based on their Accept-Language preferences.  Alternatives include:
A. link to the correct index explicitly
B. provide a (probably annoying) intermediate page to allow language selection
C. link to invisible index pages, uniview/index.html and uniview/index.fr.html, that automatically redirect you to uniview/en/index.html or uniview/fr/index.html (seems a little complicated, but may work)

Seems like this would be fine for CD-based sites, but would require extra stuff to allow language negotiation to serve up the right index file. Translation cost would be minimal other than for the localised img file(s).



[3] Half & half
---------------
uniview
	index.html
	index.fr.html
	en
		conversion.html
		u.js
		descriptions.js
		local.css
	fr
		conversion.html
		u.js
		descriptions.js
		local.css
		images
			img2.gif
	shared
		functions.js
		conversion.js
		shared.css
		images
			img1.gif
			img2.gif

In this model all links except those to the index files would have standard extensions.  Links to the index files, and img2.gif files would need translation.  All links in the index files would need translation.

All relative internal links would work equally well on server or CD.

Language negotiation could be used on the server to point the person to the appropriate index file for starting.

Seems like this would work equally well on server- or CD-based sites. But translation complexity would be higher.



Are there any other models? Are these conclusions correct?  Comments and suggestions welcome!

RI


============
Richard Ishida
W3C

contact info: http://www.w3.org/People/Ishida/ 

http://www.w3.org/International/ 
http://www.w3.org/International/geo/ 

W3C Internationalization FAQs http://www.w3.org/International/questions.html
RSS feed: http://www.w3.org/International/questions.rss 
Received on Tuesday, 10 February 2004 08:36:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:11 UTC