- From: Alan J. Flavell <flavell@a5.ph.gla.ac.uk>
- Date: Thu, 23 Nov 2000 14:08:49 +0000 (GMT)
- To: Charles McCathieNevile <charles@w3.org>
- cc: WAI Guidelines List <w3c-wai-gl@w3.org>
On Thu, 23 Nov 2000, Charles McCathieNevile wrote: > it should be en-US actually. Yes, that's what I thought too! > And I don't know, but since I know that there > are speech synthesisers out there that have english and american voices, I > would guess that the support is as for other language switching - With respect, the language of a document is a property of the document, irrespective of whether any clients "support" it today. Marking it up does no harm to any application that does not support it. If one doesn't encourage authors to use "advanced" features of the markup language, how can we ever motivate developers of client software to implement support for those features? Here's the only, minor, "gotcha" that I'm aware of in language support: it's in the area of language negotiation. If a reader configures their client to request, say, en-US, and an author marks up a document as, say, en-GB then the negotiation will fail, asserting that the document is "not acceptable". Users need to be helped to realise that they're expected to include also an unqualified "en" in their list of acceptable languages if they are willing to be sent other versions of English. It's at least arguable that the client dialog should assume that a request to configure "en-US" should imply "en-US, en", if "en" isn't already in their acceptance list, otherwise many users find the correct behaviour counter-intuitive, despite the fact that it's perfectly logical when you think it through. It would actually be a violation of protocol for a server to send an en-GB document when the client said they only accept en-US. However, the server is allowed to send them a menu of available variant(s), even if the menu contains only one entry. best regards
Received on Thursday, 23 November 2000 09:08:56 UTC