Lgtm On Mar 26, 2012 4:59 PM, "Norbert Lindenberg" < [email protected]> wrote:
> While everybody is reviewing the draft specification of the ECMAScript > Internationalization API [1] in preparation for this week's TC 39 meeting, > here are a few issues that have come up, with proposed resolutions: > > > Issue 1, IsWellFormedLanguageTag (6.2.2), raised by Allen: > > The specification referenced here, RFC 5646 section 2.1, says nothing > about the case of duplicate extension subtags (example: the duplicate -u- > in "de-u-nu-latn-u-ca-gregory"), although RFC 5646 section 2.2.9 and > section 3.7 say tat duplicate extension subtags are invalid. The > ResolveLocale abstract operation (Globalization API, 9.2.1) will only > consider the first extension subtag sequence it sees, and ignore others, > without giving applications any hint as to what's going on. > > Should IsWellFormedLanguageTag be enhanced to check for duplicate > extension subtags? And then probably also duplicate variant subtags? > > The one thing I'm sure we don't want is validation against the IANA > Language Subtag Registry. > > My proposed resolution: Add checking for duplicate extension subtags and > duplicate variant subtags, and throw exception if they exist. > > > Issue 2, CanonicalizeLanguageTag (6.2.3), raised by Allen: > > The spec used to say (before February 23): "Implementations are allowed, > but not required, to also canonicalize each extension subtag sequence > within the tag according to the canonicalization specified by the standard > registering the extension, such as RFC 6067 section 2.1.1." > > Allen points out that the result is visible to ECMAScript code, and that > this is the sort of situation were TC39 prefers to mandate a consistent > result across all implementations. > > Counterarguments to requiring extension subtag sequence canonicalization: > 1. New extensions are being defined that implementations may not know > about (and have no need to know about). > 2. For the extension that this API cares about, the -u- extension, a > comparison of language tags as complete strings isn't very useful because > different functionality cares about different extension keys - Collator > about -co- and a few others, NumberFormat about -nu-, and DateTimeFormat > about -ca-. ResolveLocale picks out the extension keys that are relevant > for its caller. > > Note that canonicalization according to BCP 47 is mandatory; only the > additional rules created by extension specifications are currently optional. > > My proposed resolution: Clarify that the quoted statement is only about > canonicalization rules that go beyond those of BCP 47; don't change the > behavior. The new wording in the February 23 draft is: > "The specifications for extensions to BCP 47 language tags, such as RFC > 6067, may include canonicalization rules for the extension subtag sequences > they define that go beyond the canonicalization rules of RFC 5646 section > 4.5. Implementations are allowed, but not required, to apply these > additional rules." > > > Issue 3, InitializeDateTimeFormat and ToDateTimeOptions (13.1.1), raised > by Nebojša: > > The spec doesn't allow the creation of a formatter with time elements > only. InitializeDateTimeFormat calls ToDateTimeOptions with arguments true > for date and false for time. Specifying time elements (hour, minute, > second) won't trigger needDefault = false since time = false (step 6.), so > we go to the section that defines date properties (step 7). You end up > having date elements you didn't ask for in addition to any time elements > you did ask for. > > My proposed resolution: Replace the date and time parameters of > ToDateTimeOptions with: > - required: which component groups are required, values "date", "time", > "any" > - defaults: which component groups should be filled in if required > components aren't there, values "date", "time", "all". > Update the ToDateTimeOptions algorithm as well as the calls to it from > InitializeDateTimeFormat and Date.prototype.toLocale(|Date|Time)String > accordingly. > > > Issue 4, InitializeDateTimeFormat (13.1.1), raised by me: > > The algorithm looks for a property "formatMatch" in the options argument. > The name agreed on in the November 15 meeting of the internationalization > team was "formatMatcher", and there is a parallel property "localeMatcher". > > My proposed resolution: Rename the property to "formatMatcher". Rename the > *Match abstract operations in parallel. > > > Regards, > Norbert > > [1] > http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
