- From: Masayasu Ishikawa <mimasa@w3.org>
- Date: Wed, 02 Sep 1998 15:23:27 +0900
- To: w3c-wai-ig@w3.org
Charles McCathieNevile <charlesn@sunrise.srl.rmit.edu.au> wrote: > >>If I put an HTTP-EQUIV Content-type into a web page then (as I understand > >>it) I don't need to rely on the person who runs the server setting it up > >>to give the correct content-type for all my pages. In some servers, it might be possible. But (as I understand it) most servers don't do so, and as Lynn pointed out, it's not a general solution. For example, if the resource is plain text, where to put an HTTP-EQUIV Content-type? > In addition, I produce HTML material to be run from a CD-ROM as files > - there is no server to program, so the HTTP-EQUIV is the only mechanism > available. I have heard (and done) this kind of discussion quite number of times - I know both have advantages and disadvantages. That's why XML has introduced encoding declaration. But putting the HTTP-EQUIV into your HTML document doesn't mean that you don't have to label your HTTP header correctly. "David Norris" <kg9ae@geocities.com> wrote: > Well, kind of. They might get double hits for every one of your files. > (Browser bug or feature? Hmmm. I can only guess that the browser switches > accept languages on the second request. I am not really clear on why there > is a second request. IE does this, I know. I am not sure how Nav handles > other charsets.) Once to read the file and realize the server sent the > wrong header, and, the second to retrieve it using the equivalent header. To display the document correctly, browsers have to know the character encoding of the document. If the proper character encoding information is provided via HTTP header, browsers are able to know how to display the document *before* parsing the document. But if the character encoding information is only available via HTTP-EQUIV, browsers have to parse the document to know that information, then try to display the document again. That's one of the disadvantages of HTTP-EQUIV. Charles: > A related question is how to specify the Language of a document - as I > understand it it is possible to use an HTTP-EQUIV to 'fake' a server > response, but I can't recall what it is (Content-language: en ???) Does > anybody know? In HTTP, you're right, you can use the "Content-Language" header. In HTML, you may use the LANG attribute, something like the following: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <HTML lang="en"> <HEAD> .... David: > Also, some servers (Such as Apache) support multilingual webs. With this > configuration, index.html would be the server's default language page (often > English), index.html.fr would be the default page for browsers with FR > (French) as the primary accept language, index.html.es would be the default > for browsers with ES (Spanish) set as the primary accept language, etc. > This, of course, depends on proper configuration of the server. In effect, > a French browser that requests http://someserver/index.html would seamlessly > be served http://someserver/index.html.fr with a properly configured server. > Pages without translations would use the default language version of the > page. W3C's Web server is configured to do so. For example, try the press release of XSL 1.0 Working Draft [1]. Our server will send the document either in English, Dutch, German, Swedish or Japanese, depends on your language request. [1] http://www.w3.org/Press/1998/XSL-WD In Apache, this language negotiation can be used to label the document correctly. The following example shows how to associate the specific charset parameter with the specific language. <Files ~ "\.html\.ja$"> ForceType 'text/html; charset=ISO-2022-JP' </Files> Regards, -- Masayasu Ishikawa / mimasa@w3.org W3C - World Wide Web Consortium
Received on Wednesday, 2 September 1998 02:23:38 UTC