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

Re: [IndexedDB] Spec changes for international language support

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 18 Feb 2011 11:34:41 +0100
To: Pablo Castro <Pablo.Castro@microsoft.com>
Cc: public-webapps WG <public-webapps@w3.org>
Message-ID: <96gsl6l0mhrtefu24f5bvq05au484bdvid@hive.bjoern.hoehrmann.de>
* Pablo Castro wrote:
>We discussed international language support last time at the TPAC and I
>said I'd propose spec text for it. Please find the patch below, the
>changes mirror exactly the proposal described in the bug we have for
>tracking this: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903

You should anticipate objections to that; collation is not a property of
language, for instance, for de-de you typically have dictionary sorting
and phone book sorting (and of course you have "de-de", "de-ch", and so
on, so "de" alone would be rather meaningless). So far the W3C and the
IETF have used resource identifiers to specify collations (see XPath 2.0
and RFC 4790) where the IETF allows shorthands like "i;ascii-casemap".

I do understand that Microsoft uses an extension of language tags for
the `CultureInfo` in the .NET Framework, where, say, `de-DE_phoneb` is
used to refer to german phone book sorting, but BCP 47 does not allow
for that, neither could you devise a language tag to define something
like "i;ascii-casemap" (which simply defines A-Z = a-z).

I would expect that if browsers offer collations, there would be an in-
terface for that so you can use them in other places, as such it might
be wiser to accept something other than a language identifier string. As
above, URIs, or RFC 4790 values plus URIs, or, in anticipation of some
such interface, some other object, might be a better choice. And the
method and attribute should probably not use "language" in their names.

I also note that collation often involves equivalence testing, but it
is not clear from your proposal whether that is the case here. It might
also be a good idea to clearly spell out interoperability expectations;
if two implementations support some collation, will they behave the same
for any and all inputs as far as collation is concerned, or should one
be prepared for slight differences among implementations?
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Friday, 18 February 2011 10:35:11 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC