>>>>> "Tzafrir" == Tzafrir Cohen <[EMAIL PROTECTED]> writes:
Tzafrir> There are a number of incompatible ways to encode Hebrew
Tzafrir> (e.g: ISO-8859-8/visual, cp1255/logical and UTF-8). So
Tzafrir> simply saying that the language is Hebrew is not enough
Tzafrir> for the browser.
No one is suggesting that the HTTP Content-type header should indicate
a language. Rather, the Content-type header indicates a character
set, and in some places an encoding as well. For example:
Content-type: text/html; charset=utf-8 # Unicode, UTF-8
Content-type: text/html; charset=iso-8859-8 # Hebrew + English
Content-type: text/html; charset=windows-1255 # Heb/Eng Windows encoding
A browser receiving the above headers knows not only that the content
is in Hebrew and English (or in Unicode), but also what the encoding
is (and thus how to display it).
Naming the encoding explicitly would only be a problem on a site that
uses multiple encodings. For example, if your site has some pages in
UTF-8 and others in Latin-1 and still others in ISO-8859-8, then you
would be in trouble. But in such a (rare) case, you can remove the
default encoding and allow people to use meta tags.
On a site that has a single, consistent encoding, it's nice to have
the server take care of such things for you, avoiding the need for
meta tags.
Tzafrir> Setting a server-wide default to a certain charset is
Tzafrir> certainly not a wise default. I would consider it a
Tzafrir> misconfiguration of RH's side.
Given that this is the W3C's preferred way of doing things, it strikes
me as a pretty reasonable approach, actually. The implied default of
Latin-1 strikes me as pretty short-sighted in a world where a large
(and growing) number of Internet users come from outside of the US.
Reuven
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
