Re: WAI and i18n (Internationalisation)

Here's an answer from Martin Duerst, our local I18N expert.

> ------- Forwarded Message
> 
> Date: Wed, 2 Sep 1998 19:23:54 +1000 (EST)
> From: Charles McCathieNevile <charlesn@sunrise.srl.rmit.edu.au>
> To: WAI <w3c-wai-ig@w3.org>, WAI PF group <w3c-wai-pf@w3.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Subject: WAI and i18n (Internationalisation)
> Resent-From: w3c-wai-pf@w3.org
> X-Mailing-List: <w3c-wai-pf@w3.org> archive/latest/365
> X-Loop: w3c-wai-pf@w3.org
> Sender: w3c-wai-pf-request@w3.org
> Resent-Sender: w3c-wai-pf-request@w3.org
> Precedence: list
> 
> Having access to material in an appropriate language is an Accessibility 
> issue, but I am not sure if wai-ig is the right place to discuss it, or 
> if it belongs more properly in the i18n domain somewhere (can someone 
> more official help us out?)

Looks indeed like i18n.


> Anyway, I am bringing the issue back to the list (after a few hours).
> 
> My concerns come from two areas.
> 
> One is the use of CD-ROM, disc, Zip, etc to provide websites. This is a 
> common technique, as it means a large amount of material can be easily 
> used offline as well as having access to further material online. Sunrise 
> Research Laboratory has produced more than 20 000 such CDs which are used 
> in schools throughout Australia. Being able to carry multilingual 
> information and have it properly dealt with would be a Good Thing (TM) 
> for such collections.

I guess you are referring to the fact that you don't have a server on
a CD-ROM. But I guess having a small server-like thing might actuall
give a lot of other benefits.


> The second concern, although much more widespread, is based on my 
> assumption that the vast majority of web authors do not have control over 
> their webservers, and cannot 'force' language negotiation to be carried 
> out. I don't know if this applies to GeoCities and their ilk, but it 
> certainly applies to many public and private service organisations in 
> Australia. Part of the problem is a lack of skills on the part of 
> sysadmins, but the need for someone to manage the server is greater than 
> the ready availability of affordable and skilled sysadmins, a situation 
> which doesn't sppear likely to improve in the near future.

This is indeed a problem, but more of education than anything else.
I'm planning to upgrade the i18n pages on the w3c site to explain
this in more detail. For Apache, for example, only one change is
needed in the central setup, and the rest can be done locally in
each directory.


> One suggestion has been the use of <LINK REL="alternate" LANG="xx" 
> HREF="this.de.htm"> (or something like it). This would solve the problem 
> nicely, but needs to be implemented by browsers. The use of HTTP-EQUIV 
> seems a difficult way to solve this problem, since I don't know that 
> there is an http-header that can redirect selectively based on language. 
> So we will always have a legacy problem, but it is one that ought to be 
> solved for the future.

The number of browsers that implement other, much more widely used
links such as "home" and "up" is very low. If link as a general
construct takes off, it may be a good idea to think about this.

But there is a big problem with all these approaches. If you add a new
language, you have to update all the parallel documents! This of course
applies less to a CD-ROM, but e.g. for servers of the European Union
and similar cases. There, automatic language negotiation is the best
way to go.


> At the moment there is a mish-mash of solutions, with some languages 
> relying on font remapping (Vietnamese) and others using full character 
> sets (Chinese, Japanese and Korean, often written CJK).

Above, as far as I was understanding, you were speaking about language
negotiation (i.e. how is the right document sent back if there are
several in different languages).



> Any thoughts?
> 
> Charles McCathieNevile
> 
> (In the meantime, I use HTTP-EQUIV to specify charsets sometimes, and 
> other times I specify a font like .VnTime, and let it default to ISO-8859-1)

Here the answer is VERY clear. Use HTTP-EQUIV or the equivalent on the
server. The "trick" with the font is against all standards, and will
lead to all kinds of problems, e.g. wrong results from search engines,...

Regards,   Martin.

------- End of Forwarded Message

Received on Thursday, 3 September 1998 03:56:30 UTC