W3C home > Mailing lists > Public > www-international@w3.org > January to March 1997

Re: Language labelling

From: Gary Adams - Sun Microsystems Labs BOS <gra@zeppo.East.Sun.COM>
Date: Mon, 24 Feb 1997 09:45:45 -0500 (EST)
To: www-international@w3.org
Message-ID: <libSDtMail.9702240945.29374.gra@zeppo/zeppo>
# Date: Sat, 22 Feb 1997 11:35:02 -0500
# From: Francois Yergeau <yergeau@alis.com>
# Subject: Re: Language labelling

On Sat 22 Feb,  François wrote :
# It certainly is, but the question at hand is a bit different.  Given that
# we want to have a single language tag in a document (no potential
# conflict), where is the best place to put it?
# Tomas is for <META HTTP-EQUIV...> (also legal) because this is explicitely
# designed for HTTP servers to pick up and send as an HTTP header.
# I'm for <HTML LANG=xx>, because it fits into the structure of the HTML
# document and applies to the whole document.  Although not designed
# explicitly for this purpose, servers may still pick up a language tag from
# there to put in an HTTP header.  This is not forbidden, just like indexing
# engines are not forbidden to use the <TITLE>, some other special-purpose
# <META> or even comments for their purposes.
# If an HTML document is retrieved from something else than an HTTP server
# and displayed, the HTML parser will be aware of a LANG attribute on <HTML>
# and should do any language-dependent rendering correctly.  If it sees a
# <META HTTP-EQUIV>, however, it may well think "this is only for HTTP
# servers" and ignore it.  The standards do not require HTML parsers to know
# anything about the meaning of HTTP headers found within <META> elements,
# only to parse the latter correctly.

I agree that the best place to place the language label (if there will be
only one label) is to place it on the outermost "container" which
holds the document contents. In the case of HTTP transported documents
the META tag provides the opportunity to promote the language label into 
the meta data associated with the transmitted document. This enables
additional functionality to be performed by proxy agents such as 
content negotiation.

While RFC2070 currently focuses on the I18N problems of HTML/HTTP I think
it would be prudent to apply the same underlying philosophy to other SGML
documents and to other transport protocols where appropriate. e.g. the W3C
XML format is already based on Unicode, but will require Language labels
to work correctly, also new URL schemes such as the imap and webnfs protocols
should follow the I18N guidelines for URIs where possible.

Received on Monday, 24 February 1997 09:50:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:16 UTC