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
