RE: ISSUE 88 - Change proposal (new update)

 

Hi Leif, 

 

This is a great solution!

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 
Date: Fri, 30 Apr 2010 05:25:48 +0200


> Updated change proposal:

> Let multiple language tags continue to be legal.
> . . .
> 1. The current warning about using @lang instead of Content-Language 
> should be changed into a warning which informs that a fallback language 
> measure has kicked in, and recommend that authors create a language 
> declaration (via @lang) rather than relying on the fallback feature.  
> This warning should be shown regardless of whether the fallback comes 
> from @http-equiv or from the higher level (HTTP). Justification: Since 
> it is a fallback feature, and with other semantics, there is no 
> guarantee that the author has used it for the language effect.
This is an excellent proposal Leif!

> 2. To hold the syntax rules of HTTP (which permits multiple language 
> tags) as the conforming ones (rather than those of @lang, which forbids 
> multiple languages), will have the effect of underlining that @lang and 
> Content-Language have different purposes. For instance, since the 
> fallback algorithm doesn’t kick in whenever multiple languages are used 
> in the pragma or on the server, there would not be any warning in these 
> cases.

> == Details ==
> Proposed spec changes, to section [4.2.5.3 Pragma directives]:

> Replace the following text
>  ]]  Conformance checkers will include a warning if this pragma is 
> used. Authors are encouraged to use the @lang attribute instead.[HTTP]  
> [[

> with the following
>  ]]  The semantics of this pragma, as well as of the HTTP 
> Content-Language header, are different from the semantics of the @lang 
> attribute. [HTTP] Thus, there is no guarantee that the author 
> consciously used either of them for setting the language. Therefore, 
> conformance checkers will include a warning, whenever HTML5’s fallback 
> language algorithm is activated, whether it is the higher protocol or 
> this pragma that kicks in. Authors are informed about which language 
> the document falls back to, and are encouraged to not rely on the 
> fallback feature but to instead explicitly use the @lang attribute on 
> the root element.  [[

> After the following text,
>  ]]  the content attribute must have a value consisting of a valid BCP 
> 47 language tag  [[

> then add the following:
> ]]  , or a comma separated list of two or more BCP 47 language tags  
> [[

> Delete the following text:
>  ]]  This pragma is not exactly equivalent to the HTTP 
> Content-Language header, for instance it only supports one language.  [[


> == Impact ==
> === Positive Effects ===
> 1. More stable: same syntax as before continues to be permitted. 
> 2. More permissive: authors, CMS-es and browsers can continue to take 
> advantage of @http-equiv ’s ability to reference what the HTTP header 
> is/was supposed to be, including replicating its fallback effect.
> 3. More correct: the difference between @lang and Content-Language is 
> pointed out, while the link between @http-equiv and HTTP is emphasized.
> 4. More useful: a warning that a fallback feature has kicked in, is 
> more useful than a warning which focuses on one of the places where the 
> fallback language could potentially kick in from. Why tell authors to 
> “use @lang insetad” if the author has already made sure that the @lang 
> attribute is in place?

> === Negative Effects ===
> none

> === Conformance Classes Changes ===
> * For UAs: none, compared with the change that HTML5 already requires.
> * For validators: They must validate a comma separated list as 
> conforming. They must check that HTTP Content-Language and @http-equiv 
> are identical. They must check when the fallback language algorithm is 
> activated. 
I agree absolutely it's the validators not the UA's that are going to be easiest to change!

> * For the HTML5 spec: see the Details section above. 

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 
Date: Fri, 30 Apr 2010 06:37:30 +0200

> The simple way to explain Content-Language vs @lang to content authors 
> is already present today: Emphasize that the semantics of 
> Content-Language differ from those of @lang, *regardless* of whether it 
> comes from pragma or from HTTP.  Since they are different, there is 
> *therefore* no guarantee that Content-Language was used with the 
> purpose of setting the language. And *therefore* the validator should 
> warn. But it should only warn whenever the fallback effect kicks in. 
> And it should warn *also* when the fallback kicks in from the server. 
Agreed.
> Validation example: 

> 1. If root element lacks @lang attribute
>      - validator checks the pragma
> 2. If pragma contains single value
>   - validator emits a fallback language warning
>    If pragma contains multiple values
>   - then proceed to HTTP header if any
> 3. If HTTP header contains single value
>    - validator emits a fallback language warning
 >  If HTTP header contains multiple values
>      - nothing happens.
+1
> This is what my change proposal now says.

> http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages


Thanks many times over again (hope someone will listen), and

Best,

C. E. Whitehead
cewcathar@hotmail.com