RE: Null change proposal for ISSUE-88 (mark II): proposed note

Richard Ishida, Fri, 9 Apr 2010 10:04:48 +0100:
>> We can make the pragma entirely non-conforming instead of conforming
>> with a warning, if that would help. 
> 
> I have indeed been coming to the same conclusion over the past week, and I
> discussed it with i18n folks on Wednesday and got no major objections
> (though the i18n Chair, Addison, wasn't in the discussion, so I don't know
> his view yet - and he's on vacation for another 10 days).

The chair's words were clear enough: [1]

]] The Internationalization working group maintains that, for 
compatibility with existing documents, authoring practice, and 
non-browser tools and user-agents, the existing syntax of HTML <meta> 
Content-Language really MUST be preserved. We do thank you for the 
other changes, but herewith request that the remainder of our Change 
Proposal be accepted by the HTML WG. [[

Even though his evaluation of the state of affairs does no quite concur 
with the evaluation found in the Best praxis Note that you produced in 
2007: [2]

]] Best Practice 6: Choosing between Content-Language and attributes
Use language attributes rather than HTTP or meta elements to declare 
the default language for text processing.
Discussion: The basic reason is that current user agents rarely use 
information in the HTTP header or meta element for text-processing 
language applications, and such implementations as there are are 
inconsistent (see the test results). [[

I have to say though, that the dilemma, "Choosing between 
Content-Language and attributes", is an oddly formulated one - I did 
not know that I could choose ... And also, when @lang is the correct 
feature to use, then it is strange, to hear that the reason for using 
@lang is that it *works* better than content-language - one misses the 
more principal justification. For example the word "fallback" doesn't 
occur at all in that note.

In that note, I can also not find any discussion of of the main problem 
with Content-Language, as I see it: That it interferes with the 
interpretation of an empty lang=""/xml:lang="".

  [...]
> I'm inclined to think that deprecating its use by authors by 
> making it non-conforming, would be the best solution. It would
> certainly significantly simplify the explanations of how authors
> should declare language information in HTML as we go forward.

Here I don't follow.

The I18N wg can develop advice about how to (not) use content-language, 
independent of HTML5. There is nothing in the current state of affairs 
which requires you to formulate the dilemma "Choosing between 
Content-Language and attributes". 

In a Best practise document about @lang and content-language, how will 
you explain to authors how they can avoid the problem that 
Content-Language (the HTTP headers) interferes with Gecko's 
interpretation of lang="" and xml:lang="", if it is not permitted to 
place Content-Language meta element inside the document which can be 
used to cancel this effect?

If forbidding Meta Content-Language makes the I18N WG think that it 
suddenly became much simpler to give advice, then I think that this is 
a reason to to not remove Content-Language, because the fact of the 
matter is that Content-Language constitutes a problem/challenge 
regardless. It is better to keep Content-Language and instead 
to define how to avoid the problems that it poses.

[1] http://lists.w3.org/Archives/Public/public-html/2010Apr/0065

[2] http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.110827800

-- 
leif halvard silli

Received on Saturday, 10 April 2010 16:13:37 UTC