I18N feedback on Issue-88


The Internationalization Core WG discussed Issue-88 and various proposed solutions during our teleconference last week. In our last communication with you we supported Ian Hickson's proposal to make <meta> Content-Language non-conforming because we felt this compromise position would meet our WG's understanding of what was best for users. 

However, our working group's position is somewhat more nuanced and we felt our comments needed to be focused more specifically on our areas of concern.

In discussing this issue, we found group consensus as follows:

1. The default document processing language will affect how the page is drawn, especially since there are newer mechanisms such as :lang and language-dependent rendering in CSS3 fonts that depend on the language of a particular span of text. It would be best if such processing were somewhat deterministic and not affected by "spooky" values imposed from HTTP headers and <meta> tags.

2. The Content-Language header and pragma were intended for different purposes originally (per HTTP). Their syntax and content are not consistent with document processing such as that in (1) and we foresee continued confusion about how to properly declare language and the effectiveness of features such as :lang when the values are applied as the default language.

3. It really is a requirement that HTML5 clearly specify if (and if so, how the) HTTP Content-Language and/or the Content-Language pragma is assigned to html@lang when html@lang is itself not present. The I18N WG could accept language specifying the assignment of the (unmodified) Content-Language syntax header/pragma to html@lang, as long as such an assignment were completely unambiguous, although we really would prefer that no such linkage is created.

Therefore, our narrowed position is:

- HTML should (continue to) strongly recommend the presence of @lang (and warn in validators if it is not present)
- HTML should spell out that the Content-Language (HTTP or <meta>) MUST NOT be used to assign the value of @lang when the latter is not present.

We feel that it is preferable to make the focus of document authors on @lang, where it belongs. It would be acceptable to us if user-agents were permitted to use whatever information to assign language an empty @lang, but generally speaking it would be best if document language were as deterministic as possible so that document authors have a chance of figuring out how the markup and styling interact.

The I18N WG recognizes that most browsers *do* use Content-Language as a fallback. However, heretofore this has not affected almost any real-world page processing. The WG thinks that permanently separating HTTP C-L from html@lang would be the best way to achieve interoperable and consistent document processing. 

(for I18N WG),


Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

Received on Wednesday, 19 May 2010 04:23:52 UTC