RE: ISSUE-88 content-language: informal consensus check

Richard Ishida, Thu, 29 Apr 2010 15:47:50 +0100:
  [...]
> I expect it to be *much* easier to explain to content authors: You set the
> language of the content using the language attribute. Oh and btw if for some
> reason you fail to do this, the browser may go look at *other* information,
> ie. the metadata in the http header, to see if it can guess at a language.

I expect it to be confusing that it suddenly is no danger if fallback 
language kicks in from server, whereas there is a big danger if it 
kicks in from http-equiv. The pedagogical way would be to treat both 
issues as equally problematic.

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. 

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.

This is what my change proposal now says.

http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages

Leif H Silli


>> -----Original Message-----
>Leif Halvard Silli 29 April 2010 14:40

>> Like the I18N WG, I have changed my mind - and have been revising my
>> change proposal to reflect this. In essence, I now support the I18N
>> WG's original proposal, which, in effect (on the spec) basically is
>> identical with what Julian and Roy is saying.
>> 
>> Otherwise, what Addison says on behalf of the I18N WG, does not hold
>> true: making Content-Language non-conforming will *not*, quote:
>> "eliminate the confusing (and not useful) overlap in language
>> declaration".
>> 
>> Making the META content-language non-conforming, will only move the
>> "confusion" one step higher up. Because, the HTML5 spec is clear on the
>> fact that HTML5 conforming user agents will inherit the language from
>> the server whenever there isn't whether a @lang attribute nor a META
>> content-language element.
>> 
>> Leif Halvard Silli
>> 
>> Maciej Stachowiak, Wed, 28 Apr 2010 21:09:42 -0700:
>>> 
>>> Since the I18N WG endorses this Change Proposal, and the editor also
>>> agrees, I'd like to hear if anyone else would object to this as a
>>> resolution to ISSUE-88. If no one objects, the Chairs will seek to
>>> close this issue by amicable resolution. If there are objections,
>>> then we will seek some other way to resolve this issue promptly, such
>>> as using a survey.
>>> 
>>> Regards,
>>> Maciej
>>> 
>>> On Apr 28, 2010, at 3:12 PM, Phillips, Addison wrote:
>>> 
>>>> On 9 April 2010, Ian Hickson proposed [1] a solution to Issue-88
>>>> that said in part:
>>>> 
>>>> --
>>>> SUMMARY
>>>> People are confused by the Content-Language pragma, so it should be
>> made
>>>> non-conforming.
>>>> --
>>>> 
>>>> The Internationalization Core WG has officially endorsed this
>>>> proposed solution [2]. Existing, legacy documents (and non-browser
>>>> processes that use this markup) will not be harmed by this solution
>>>> while this will eliminate the confusing (and not useful) overlap in
>>>> language declaration.
>>>> 
>>>> (for I18N Core),
>>>> 
>>>> Addison
>>>> 
>>>> [1] http://lists.w3.org/Archives/Public/public-html/2010Apr/0308.html
>>>> [2] http://www.w3.org/2010/04/21-core-minutes.html#item04
>>>> 
>>>> Addison Phillips
>>>> Globalization Architect -- Lab126
>>>> Chair -- W3C Internationalization WG
>>>> 
>>>> Internationalization is not a feature.
>>>> It is an architecture.
>>>> 
>>>> 
>>> 
>> 
>> 
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.814 / Virus Database: 271.1.1/2841 - Release Date: 04/28/10
>> 19:27:00
>

Received on Friday, 30 April 2010 04:38:04 UTC