I18N Repsonse to XHTML2 comment 35c

Dear HTML WG,

Thank you for your responses to our XHTML 2 comments. I am writing this message on behalf of the I18N Core WG in response to your proposed resolution of our item 35c.

Our comments can be located here:

Review: http://www.w3.org/International/2004/10/xhtml2-i18n-review.html


Your response can be located here:

http://lists.w3.org/Archives/Public/public-i18n-core/2005JanMar/0089.html


On this issue you said:

<q xml:lang="en-GB">
35c: Since the behaviour in *correct* situations (i.e. when the document
really is in that language) will be identical, and only in error situations
will be different (and in XHTML2 clearer than in XHTML1), we believe that
retaining the name is acceptable.</q>

We believe quite strongly that this is a mistake and would like you to reconsider.

The problem here is that the current "hreflang" attribute in XHTML1 and HTML4 makes an assertion about the language of a particular resource. This information may be useful in selecting which link to click on or some other thing about the link, but it doesn't affect the resource itself.

XHTML2, by contrast, specifies that the user agent should set its Accept-Language HTTP header to match the XHTML2 hreflang attribute when requesting the resource. This means that it is no longer an assertion about the content. It is the content author overriding the user's preferences.

The behavior in "correct" situations may not apply equally to dynamically generated or updated content. Accept-Language can be (and is) used in myriad ways to negotiate content or lookup specific language version resources.

It is entirely possible that what you term an "error" situation may not, in fact, represent an actual error. Currently the penalty to being wrong with an hreflang assertion is that the user may see referred content in a different language based on the user's preferences. The penalty for being wrong with an hreflang assertion with XHTML2's design would be that a language of the content author's preference might be shown (or its direct fallback).

This marks a radical departure from current practice when authoring content and the meaning of the attribute. 

We can visualize use cases in which the content author wishes to override the user agent's accept-language. This should, for consistency's sake, use a new attribute called "acceptLanguage" that is not an assertion about the referred content's language.

Please consider our comments and let us know if you need more information or wish to discuss further. Additional comments will be forwarded under separate cover. Please note that this WG has recently changed to a public model (similar to TAG). If you wish to discuss things in email of a Member Confidential nature, please use our other mail list (member-i18n-core).

Best Regards,

Addison

Addison P. Phillips
Globalization Architect, Quest Software
http://www.quest.com


Chair, W3C Internationalization Core Working Group
http://www.w3.org/International


Internationalization is not a feature.
It is an architecture.

Received on Tuesday, 29 March 2005 21:36:03 UTC