- 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>
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:44 UTC