W3C home > Mailing lists > Public > www-international@w3.org > April to June 2010

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 6 May 2010 16:05:00 +0200
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "public-html@w3.org" <public-html@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, www-international@w3.org, Ian Hickson <ian@hixie.ch>
Message-ID: <20100506160500287451.42e2fa29@xn--mlform-iua.no>
fantasai,

Very good improvements you suggest. Tempted to say that I agree 
completely! :-) Very much in tune with intentions of the proposal. For 
the moment I'll leave the proposal as is, in waiting of more input - 
and more time to actually edit it ...

regards,
Leif H Silli


fantasai, Wed, 05 May 2010 17:00:36 -0700:
> On 05/05/2010 11:22 AM, Leif Halvard Silli wrote:
>> 
>> Updated change proposal:
>> 
>> Let multiple language tags continue to be legal.
>> (http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages)
>> 
>> == Summary ==
>> ...
>> == Rationale ==
>> 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.
> 
>> == Impact ==
>> === Positive Effects ===
>> ...
>> === Negative Effects ===
>> ...
>> === Conformance Classes Changes ===
>> ...
>> === Risks ===
>> ...
>> == References ==
>> ...
> 
> I agree completely with the intention of this change proposal. I have,
> however, some comments on the specific text changes:
> 
>> == Details ==
>> Proposed spec changes, to section [4.2.5.3 Pragma directives]:
> 
> I recommend also adding some explanation of what this pragma does, since
> it is completely unclear from this section what its purpose is.
> 
> I suggest changing this sentence:
>      # This pragma sets the <dfn>pragma-set default language</dfn>.
> To something like this:
>      | This pragma sets the <dfn>pragma-set audience language</dfn>,
>      | which, if present, must <q>describe the natural language(s) of the
>      | intended audience of the document</q>. [HTTP] It can also be 
> _consulted
>      | as a fallback_ [link to fallback paragraph in 3.2.3.3] when other
>      | content language information is not available. However authors should
>      | use the _lang_ attribute on the root element, not this pragma or its
>      | corresponding HTTP header, to set the document's primary language.
> 
> And adjusting other occurrences of "pragma-set default language" as 
> necessary.
> 
>> Replace the following text
>>    # Note: Conformance checkers will include a warning if this pragma is
>>    # used. Authors are encouraged to use the @lang attribute instead.[HTTP]
>> 
>> with the following
>>    | Note: The semantics of this pragma, as well as of the HTTP
>>    | Content-Language header, are different from the semantics of the @lang
>>    | attribute. [HTTP]
> 
> This part of the note makes sense to be here, although with a better
> explanation of the pragma's purpose, may no longer be necessary.
> 
>>    | 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.
> 
> However, I think this explanation belongs in the fallback section, not
> here. I'm also not convinced it belongs in the spec at all. I'd rather
> see a simple normative statement in the fallback paragraph that conformance
> checkers should/must emit a warning when the fallback is triggered.
> The explanation here is otherwise superfluous.
> 
>> 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.
> 
> I agree with the last two changes.
> 
> ~fantasai
> 
> P.S. IIRC public-html will block my reply, so you may need to quote
> it in its entirety if replying to that list.
Received on Thursday, 6 May 2010 14:05:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 May 2010 14:05:42 GMT