proposal for WG responsed to issue-88

=== for WG review ===
=== based on Richard's text with my own insidious changes ===
=== objections/edits to the list ASAP ===

I am writing on behalf of the Internationalization WG in response to the Issue-88 survey that is currently on-going. These are our objections/thoughts on the various proposals presented:

[1] Objections to the Change Proposal to make the Content-Language pragma non-conforming

We are concerned that this interferes with the original intended use of the http-equiv markup and compatibility between the corresponding HTTP header and HTML markup. We note, however, (a) that usage of <meta> for language declaration continues to be unclear and (b) allowing the content-language pragma to be used for language declarations is confusing to authors.

[2] Objections to the Change Proposal to require user agents to ignore pragmas that specify multiple languages

We have a strong objection to this proposal because it changes syntax of the <meta> Content-Language pragma to support only one language value. This is very likely to compound existing confusion about how the <meta> Content-Language element should be used because it makes it appear more like a duplicate of the lang attribute while breaking both existing content and compatibility with the corresponding HTTP header (the only header for which this is true).  Warnings are only likely to be seen by people validating their content. That is an issue with all of the proposals, but this proposal compounds the confusion by making it seem like the meta Content-Language element is *designed* as an alternative method for expressing the default document processing language for the page. We really need to help people move to a single, consistent method.

[3] Objections to the Change Proposal to let multiple language tags continue to be legal

The Internationalization WG is happiest with this proposal (compared to the others) because it is most consistent with our view that existing content should not be harmed or required to change the syntax of <meta> Content-Language, while the document processing language should be clearly defined, independent of document metadata, and derived primarily from @lang.

We object to the proposal as written because, although it provides a workable defaulting mechanism that may help with legacy pages, it is likely to prolong the confusion experienced by users creating new pages. In the absence of a lang attribute on the <html> tag, declaring language in <meta> Content-Language will continue to produce an effect.  Users will only find out that you shouldn't do that if they validate their pages - and the people we're talking about who get this wrong are quite likely not to validate.

The CP also proposes two methods to remove any warnings. These involve removing the meta and/or HTTP information rather than adding a lang attribute.  This seems inconsistent with the goal of encouraging people to use language declarations. Insertion of lang attributes is preferred to removing information from the page, even if that information is not used by user-agents.

We would prefer that the CP be modified so that browsers must not guess at the default language for the page by looking at the HTTP headers and/or meta elements. This would result in a CP that does not remove or change the http-equiv information (as the "non-conforming" CP proposes) but would render it harmless.  We believe that the defaulting mechanism proposed will occasionally confuse users when newer features in CSS3 (for example) are activated by the HTTP header value or by metadata injected by (for example) their CMS. This, of course, is an argument against the main raison d'être of this CP.

The Internationalization WG also STRONGLY disagrees with the proposal to change 'pragma-set default language' to 'pragma-set locale language'. We feel that the definition of locale (which is to do with API settings) is not to be confused with the declaration of content language. Although these are related in some ways, in fact the "locale" is not set by @lang and it should not be implied to be so.

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

Internationalization is not a feature.
It is an architecture.

Received on Wednesday, 30 June 2010 20:40:55 UTC