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

RE: How to organise a multilingual website

From: Richard Ishida <ishida@w3.org>
Date: Tue, 10 Feb 2004 22:47:31 -0000
To: "'Richard Ishida'" <ishida@w3.org>, <www-international@w3.org>
Message-ID: <001101c3f027$ef7e79e0$6601a8c0@w3cishida>

Just thought of a drawback to models [5] and [1]: you can't on the server easily navigate through the whole site in a language other than that specified in your Accept-Language header.  The server will keep choosing the wrong language for you.  So perhaps, if this is important, we're back to model [4].  (Sorry localization folks!)


> -----Original Message-----
> From: Richard Ishida [mailto:ishida@w3.org] 
> Sent: 10 February 2004 22:35
> To: 'Richard Ishida'; www-international@w3.org
> Subject: RE: How to organise a multilingual website
> A fourth and fifth model came to mind as I drove home from 
> the office.  
> [4] eliminates advantages for localization, but offers 
> significant linking benefits when linking to files on a server.
> The arrangement of files is as for model [1] (see below), 
> (ie. all localised versions of a given file in the same 
> place) but all internal links explicitly reference a specific 
> language version.  For example, to link from index.fr.html to 
> conversion.fr.html your href would be "conversion.fr.html" 
> (whereas in model 1 that would have been simply 
> "conversion").  This would mean that all links would need to 
> be 'translated'.  So why do it?  Because let's suppose that 
> conversion.html could be linked to directly from outside the 
> site - you'd want to have a single URI and enable content 
> negotiation. If conversion.html and  conversion.fr.html were 
> in different directories (as they are in the other models) 
> this wouldn't work.
> The explicit links enable the internal links to work equally 
> well from a CD.
> The motivation behind this model appears to provide a good 
> reason for avoiding any silo based approach.
> [5] comes at the problem from a different angle.  This model 
> uses exactly the same approach as model [1] for accessing 
> files on the server, but before files are accessed from CD 
> some process is run to convert all links to explicit, 
> language-specific ones. 
> This seems to be the only approach that reaps the benefits 
> all round. Whether you supply the server version or the CD 
> version for localisation, they don't need to change any 
> links. Content negotiation works on the server. Converted 
> links also work on the CD.  You just need to be able to 
> convert between the two.
Received on Tuesday, 10 February 2004 17:49:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:40:48 UTC