Re: I18N feedback on Issue-88

Jonas Sicking, Wed, 19 May 2010 10:15:55 -0700:
> On Wed, May 19, 2010 at 2:21 AM, fantasai  wrote:
>> On 05/19/2010 02:06 AM, Henri Sivonen wrote:
>>> "Addison Phillips"  wrote:
>>> 
>>>> - HTML should (continue to) strongly recommend the presence of @lang
>>>> (and warn in validators if it is not present)
>>> 
>>> If validators did that, there'd be even more templates, etc., filling in a
>>> placeholder value that doesn't necessarily have anything to do with the
>>> actual content.
>> 
>> In that case, I would suggest following Leif's suggestion and only
>> posting a warning about a missing lang="" if the Content-Language
>> HTTP header or <meta http-equiv> pragma is present. This is more
>> likely to catch authors who are trying to specify the language but
>> doing so wrongly, and avoid the authors who don't care.
> 
> Wouldn't you get the same effect by warning every time the <meta
> http-equiv> pragma is present?

If by "effect" you mean "the occasions on which you will be told to not 
use the pragma", then the answer is no. 

In fact, my proposal doesn't include a single time when you will be 
told to not use the pragma. Instead, it focuses on getting authors to 
use @lang, without pressing them to do so. (And thanks to fantasai for 
improving this side of the proposal!)

1. To ask authors to "use html@lang instead" is not helpful if they 
have already made use of @lang on the root element - hence no warning 
in such cases. (Better then to eventually ask them to remove 
Content-Language, without any direct advice that implicates that @lang 
is a better version of Content-Language. However such a proposal is so 
far not on the table anywhere.)

2. Even if html@lang is not used, but Content-Language is without any 
observable effect in a HTML5 compatible parser (namely, whenever 
Content-Language contains multiple values), then there is no point in a 
warning.

3. It is not helpful to point authors to use @lang only when there is a 
pragma version of it, when the HTTP version will have the same effect. 
(Better then - as indicated by the I18N WG - to completely remove the 
fallback effect of both pragma and HTTP. However such a proposal has 
thus far not been suggested - and it requires all UAs to change and 
/could/ "break the web" - even if the I18Nwg say that they think it 
would not.)

4. If the focus is on getting authors to use @lang, then it is better 
to focus on the cases when something *other* than lang - namely 
Content-Language -takes control over the language. And this, is the 
essence of my proposal: if html@lang is used (on the root element) then 
there never is any warning [unless the syntax of Content-Language is 
incorrect].

> At least if such a warning includes
> language to recommend that @lang is a better solution. 

On the contrary: the current draft is problematic *especially* because 
it comes with the explanation "to use @lang instead". That 
recommendation assumes that authors have an *incorrect* perception of 
what Content-Language is in the first place. E.g. moving an incorrect 
"en-us" to <html lang="en-us"> if the document is in Chinese, is no 
improvement. Likewise, to move "en,de" to <html lang="en,de"> is also 
not any improvement - on the contrary! It is also no improvement to 
simply delete the pragma, if a Content-Language HTTP header value then 
steps in. 

It seems better if the validator makes a careful judgment of whether 
there is any fallback effect at all.

> IMHO validators
> should always include recommendation of what the "new correct way" is
> whenever warning about deprecated features.

Content-Language is not a full fallback for @lang - it is only, 
eventually, a fallback for @lang inside the root element.
-- 
leif halvard silli

Received on Wednesday, 19 May 2010 18:41:01 UTC