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

On 05/05/2010 11:22 AM, Leif Halvard Silli wrote:
> Updated change proposal:
> Let multiple language tags continue to be legal.
> (
> == 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 [ 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] 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.


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 00:01:33 UTC