- From: CE Whitehead <cewcathar@hotmail.com>
- Date: Fri, 30 Apr 2010 16:15:41 -0400
- To: <xn--mlform-iua@xn--mlform-iua.no>, <mjs@apple.com>
- CC: <addison@lab126.com>, <public-html@w3.org>, <public-i18n-core@w3.org>, <www-international@w3.org>
- Message-ID: <SNT142-w484E030E6396264D03F8A0B3000@phx.gbl>
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
Received on Friday, 30 April 2010 20:16:16 UTC