- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 19 Dec 1996 01:12:58 +0100 (MET)
- To: kweide@tezcat.com (Klaus Weide)
- Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-international@w3.org
Klaus Weide: > [...] >Examples where "Language" is treated as carrying charset meaning >(not just repertoire, but "charset" including encoding): First, thanks for collecting these examples. >Pages that do the poor-man's negotiation of letting the user select >a "language" manually, than return a page whose charset may vary >depending on the language choice. > <URL: http://www.alis.com/internet_products/language.en.html> > <URL: http://www.accentsoft.com/> > <URL: http://www.dkuug.dk/maits/> Hm, I would not call this `language carrying implied charset meaning'. If I were to make a page like the ones above, I would leave out all mention of requiring support for the appropriate charset too, because of stylistic reasons. >Another example, which does "real" (automatic) negotiation: > <URL: http://www.dkuug.dk:81/maits/summary> >(For example, with "accept-language: el, en" you get Greek in iso-8859-7 >- even when also sending an "accept-charset" which excludes iso-8859-7.) I guess this is a case of a CGI programmer making something that is good enough in the usual case instead of 100% optimal. How many current user agents send a (reliable) Accept-Charser header anyway? So I don't interpret your examples as the Accept-Language/Content-language headers carrying charset meaning. Which is good, actually, because if they had carried charset meaning, that would have created a nasty negotiation problem. > Klaus Koen.
Received on Wednesday, 18 December 1996 19:13:03 UTC