W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

[Bug 14709] lang tag validation is insufficiently specified

From: <bugzilla@jessica.w3.org>
Date: Mon, 07 Nov 2011 18:05:42 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RNTZm-0004sU-CJ@jessica.w3.org>

--- Comment #7 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-11-07 18:05:40 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > For example, OpenType defines its own language system tag (LangSysTag) registry
> > [1], which is distinct from (though based in part on) ISO639, and thus distinct
> > from BCP47 and HTML5's lang/xml:lang value spaces.
> > 
> > [1] http://www.microsoft.com/typography/otspec/languagetags.htm
> I neglected to mention it, but apropos your example, OpenType uses 'BRM ' as
> the language tag for Burmese, and not 'my' or 'myr'. So one would have to
> perform a mapping here in either case (of 2 or 3 character ISO639 tags).

That is true, but not germane to the issue. It would have been germane to the
issue only if 'mya' had been a (grandfathered) BCP 47 language (sub)tag. As it
is, only 'my' is a BCP 47 language (sub)tag.

An example of a grandfathered language (sub)tag is 'no-nyn' for 'Norwegian
(nynorsk)' The preferred tag for 'Norwegian (nynorsk)' is 'nn'. The 'no-nyn'
subtag is registered in the official subtag registry
(http://www.iana.org/assignments/language-subtag-registry). If a subtag doens't
occur in that registry, then it isn't a (grandfathered) BCP47 subtag.

There should be nothing wrong if an application mapped from 'no-nyn' to 'nn',
on the contrary, I guess. However, for instance in CSS, the Web author must 
manually make the mapping by giving e.g. *:lang(nn) and *:lang(no-nyn) the same

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 7 November 2011 18:05:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:08 UTC