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

RE: Regarding update of language declaration tests (I81NWG)

From: CE Whitehead <cewcathar@hotmail.com>
Date: Mon, 19 Apr 2010 19:47:57 -0400
Message-ID: <SNT142-w354997976C81A60D2CB912B30B0@phx.gbl>
To: <xn--mlform-iua@xn--mlform-iua.no>, <www-international@w3.org>, <ishida@w3.org>

I looked at your proposal Leif:
"The value of the content attribute of the last occurring meta content-language element must be the empty string."
{ MY COMMENT:  no not really;
I think it should optionally be lang="" and some single language declaration tag;
yes this is for fallback -- but if there is a single audience language and only one meta content-language element
-- and I do not expect either applications (such as Front Page) or content authors to start inserting two such elements anytime soon --
in these cases (where there is a single audience language) a single language subtag can go into the meta content-language element for the purposes of content-negotiation -- if content negotiation is ever done! 
The single language subtag should then match the html lang= subtag  -- or two meta-content language elements would be needed after all! } 
"Ianís language determination algorithm is changed in one point: If the last occurring meta content-language declaration is empty, then it must be interpreted by user agents as having the same semantics as an empty lang or xml:lang attribute Ė meaning that they must not ask if the HTTP header has any other language information to provide. (Thus, only when the last occurring meta declaration contains multiple language tags, would conforming user agents be required to pay attention to whether the HTTP header contains a language tag or not.)"
{ MY COMMENT:  o.k.; it's not your intention to interpret the absence of any meta content-language element at all as the same as lang = the empty string, however, is it???  That is, for cases where I have the html root with head  -- 

the head with title style and maybe javascript; and then the body element, omitting meta or at least meta content-language tags }
"By not counting the value of possible preceding meta content-language elements when HTML5 conformance is evaluated, we satisfy two communities: the I18N community (who want to be able to use multiple values) and authors wanting to create HTML5 documents that works in Mozilla browsers (they want to be able to cancel the effect of HTTP headers in Gecko) "
{ MY COMMENT:  +1 Agreed this is a good solution; thanks. }

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 
Date: Mon, 19 Apr 2010 01:38:49 +0200
To: CE Whitehead <cewcathar@hotmail.com> 
Cc: www-international@w3.org 
> CE Whitehead, Sun, 18 Apr 2010 19:19:15 -0400:
>> Leif Halvard Silli,  Sat, 17 Apr 2010 02:45:31 +0200
>> Elsewhere however Koch notes that:
>>> in languages based on XHTML Modularization 1.1, the empty string is 
>>> (formally) DTD-valid and XML-Schema-valid.
>> and that:
>>>  in "XHTML 1.1 + RDFa" the empty string is (formally) DTD-valid.
> And he could have added HTML5 and XHTML5, were it is also valid.
>> As I think you know, Richard Ishida suggests using lang="und"  
>> where lang= the empty string is not supported in xml; otherwise his 
>> article recommends
>> the use of the emptry string that the working group is now trying to 
>> make invalid; see:
>> http://www.w3.org/International/questions/qa-no-language
Oops, I meant to say that the working group is trying to make the emptry string invalid for  the meta Content-language element; apparently the emptry string will remain valid for the html tag regardless -- whether it's processed or not.
> Thanks for the pointer. Since XHTML5 and HTML5 support the empty 
> string, the consequence of the advice in that article, must be that one 
> should *not* use "und" in XHTML5 and HTMl5.
> The problem, however, is browser support ... They do not seem to care 
> about the so called "schema". 'und' has better support than the empty 
> string.
So -- if the emptry string is disallowed for the meta content-language element -- 
lang='und' will be the best option?
(It sort of bugs me to declare the language as 'und' when there are two known document languages -- neither having preference of course or that could be the language declaration in the meta content-language element in this case --; but if 'und' works . . .)

C. E. Whitehead

Received on Monday, 19 April 2010 23:48:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:40:58 UTC