W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2011

Re: Minor comments on Widgets

From: Marcos Caceres <marcosc@opera.com>
Date: Thu, 17 Mar 2011 14:02:29 +0100
Message-ID: <4D820665.8060108@opera.com>
To: Robin Berjon <robin@berjon.com>, "Phillips, Addison" <addison@lab126.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
On 3/17/11 1:43 PM, Robin Berjon wrote:
> On Mar 17, 2011, at 20:21 , Marcos Caceres wrote:
>> On Tue, Mar 15, 2011 at 4:41 PM, Phillips, Addison<addison@lab126.com>  wrote:
>>> I happened to be referring to the Widget spec this morning
> Out of curiosity: in what context?
>>> 1. Section 5.3 (Zip Relative Paths). The ABNF defines "language-range". I think this is not desirable. Language ranges are input to the matching algorithm (i.e. the user's request). You don't really want paths like "locale/de-*-1901". You want concrete paths here and "*" has no business in a path. Ideally you would reference the "Language-Tag" production in BCP 47 (RFC 5646). However, since it is a large production and you don't probably want to directly incorporate it, you could incorporate the "obs-language-tag" production in the same document instead. You should still say that language tags used in paths "must" be valid language tags according to the more formal production.
>> Valid point. I don't think anyone will complain if we change this.
> +1, it's a bug.
>>> 2. Section 5.3. The same production corresponds to BCP 47 (RFC 4647) "extended-language-range", although it only allows the tags to use lowercase letters. I really feel that mixed case is not that difficult to support and that it will save many developers from inexplicable silent failures.
>> This is true... however, most engines implemented the case sensitive
>> requirement (implementers had concerns about Unicode case
>> comparisons)). I think it might be hard to fix this one without
>> breaking a bunch of runtimes and maybe content.... need to think about
>> it.
> I would very much prefer that we stuck with case-sensitive; I think that developers can handle that trivially.

I agree. I would be weird to have some aspects work as case-sensitive 
and other parts not.

I propose this be the rule (which is what we originally intended):

lang-tag       = primary-subtag *( "-" subtag )
primary-subtag = 1*8low-alpha
subtag         = 1*8(alphanum)
alphanum       = low-alpha  / DIGIT
low-alpha      = %x61-7a
Received on Thursday, 17 March 2011 13:04:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:23:07 UTC