- From: Richard Ishida <ishida@w3.org>
- Date: Tue, 10 Feb 2004 13:35:32 -0000
- To: <www-international@w3.org>
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