RE: ISSUE-88 - Change proposal (new update)

Hi Addison,

Great! 

Chairs, I hope you take note w.r.t. preparations for the poll. [1]

[1] http://www.w3.org/mid/4BE1A208.4000804@intertwingly.net


Regards,
Leif Halvard Silli


Phillips, Addison, Wed, 5 May 2010 11:26:38 -0700:
> Hello Leif,
> 
> The I18N WG started to consider this proposal today, but will not 
> have a resolution in place on it until next week.
> 
> Regards,
> 
> Addison
> 
> Addison Phillips
> Globalization Architect (Lab126)
> Chair (W3C I18N, IETF IRI WGs)
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> 
>> -----Original Message-----
>> From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no]
>> Sent: Wednesday, May 05, 2010 11:22 AM
>> To: Maciej Stachowiak
>> Cc: Phillips, Addison; public-html@w3.org; public-i18n-core@w3.org;
>> www-international@w3.org
>> Subject: Re: ISSUE-88 - Change proposal (new update)
>> 
>> [I'm resending my message from 30 Apr 2010, with a properly
>> formated
>> keyword - ISSUE-88 (earlier I forgot the hyphen) so that the
>> proposal
>> gets listed on this issue's tracker page -
>> http://www.w3.org/html/wg/tracker/issues/88.  Also corrected a
>> typo.]
>> 
>> Updated change proposal:
>> 
>> Let multiple language tags continue to be legal.
>> (http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages)
>> 
>> == Summary ==
>> * Multiple language tags (a comma separated list) in @http-equiv
>>   Content-Language continues to be legal.
>> * Conformance checkers will emit a warning whenever  – and only
>> if –
>>   the fallback language algorithm kicks in.
>> * The fallback warning will kick in regardless of whether the
>> fallback
>>   comes from HTTP or Content-Language.
>> 
>> == Rationale ==
>> The problems with the current specification are
>> 
>> 1. That it prevents authors from legally using multiple values to
>>    replicate the language fallback effect of doing the same thing
>>    in a HTTP header.
>>   * That no language gets set, as HTML5 requires from multiple tags
>> whether they occur in HTTP or in @http-equiv, is still an effect.
>> The
>> spec is therefore incorrect in claiming about the latter that “[for
>> instance it only supports one language]”.
>> 2. That it prevents @http-equiv from being used as a reference to
>> what
>> the HTTP Content-Language is/was meant to be.
>>   * Consider Firefox’ Page Info panel. Consider some CMSes.
>> Consider
>> simply authors themselves.
>> 3. That it underlines the confusion that may exist today, about the
>> nature of @lang versus Content-Language, by requiring:
>>   * different syntax rules for features that are expected to be
>> identical (HTTP and @http-equiv )
>>   * similar syntax rules for features that are different (http-
>> equiv
>> and lang)
>>   * a warning message which asks authors to “use @lang instead” –
>> as if
>> they were juxtaposable alternatives.
>> 
>> Conformance checking and warnings are in place, but should be about
>> the
>> correct things.
>> 
>> 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.
>> 
>> 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 when the fallback language algorithm is
>> activated.
>> * For the HTML5 spec: see the Details section above.
>> 
>> === Risks ===
>> In legacy UAs, there is a risk that multiple language tags cause
>> them
>> to report that the document is in a meaningless language. However,
>> this
>> is a low risk. And authors can avoid it by using the @lang and
>> xml:lang
>> attributes. This change proposal ensures that authors will continue
>> to
>> be encouraged to use lang, and not Content-Language, for setting
>> the
>> language.
>> 
>> == References ==
>> Section [14.12 Content-Language] of [RFC 2616]:
>> HTML4’s general [HTTP-EQUIV explanation]
>> HTML4, section [8.1.2 Inheritance of language codes]

Received on Wednesday, 5 May 2010 21:52:03 UTC