Re: How to organise a multilingual website

I vote for number 2 for human reasons. Localization management is much 
easier with silos and less prone to errors/lost files, unless there is 
some content management solution layered on top of everything.

I suspect the ideal solution will come down to the structure of the Web 
management teams. If you have people who are in charge of specific 
languages, possibly in separate locations, they may feel more 
comfortable with silos, whereas a small, centralized team may prefer 
everything lumped together.

On Feb 10, 2004, at 8:35 AM, Richard Ishida wrote:

>
> 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 22:05:16 UTC