Skip to content

Latest commit

 

History

History
61 lines (41 loc) · 2.75 KB

File metadata and controls

61 lines (41 loc) · 2.75 KB

Default Behaviours for some Intl APIs

A TC39 proposal to make available default, well-defined, locale-independent behaviour for the Intl APIs for which no stable (zxx) behaviour is proposed in the Stable Formatting proposal

Stage: 1

Champions: Eemeli Aro, Henri Sivonen

Presentations:

Motivation

Default, well-defined, locale-independent behaviour exists for the Intl APIs for which no stable (zxx) behaviour is proposed. These should be made available to users.

From tc39/ecma402#549:

I expected to be able to specify the "und" locale tag with Intl.Collator, in order to access the so-called "root" collation and obtain a reasonably language-agnostic sort order (or the closest thing available).

See also the discussion at proposal-stable-formatting#13.

Proposed Solution

For Intl APIs that ingest localized content and for which no stable behaviour is proposed (Intl.Collator, Intl.Segementer, and String.prototype.toLocale{Lower,Upper}Case), explicitly support und ("undetermined") as a reference for the root locale, via which some default locale-independent behaviours are made available.

Using a valid locale identifier rather than e.g. root or a well-known symbol is preferred, as at least collation should explicitly support und-u-co-emoji as a way to select emoji collation.

When the zxx locale is requested for an API that does not support it but does support und, use that as its fallback locale.

Intl.Collator

When the und locale is used, CLDR root collation is used, with unified ideographs ordered either by block and then by code point, or by radical-stroke.

Intl.Segmenter

When the und locale is requested together with the default 'grapheme' granularity, UAX #29 segmentation with extended grapheme clusters is used, without tailorings.

Non-grapheme segmenters ('word' and 'sentence') shall comply with UAX #29 and UAX #14, potentially with tailorings, but shall not enable tailorings that the implementation does not enable for all locales.

String.prototype.toLocaleLowerCase & String.prototype.toLocaleUpperCase

When the und locale is requested, the string is converted to the appropriate case using the Unicode Default Case Conversion algorithm, i.e. we apply the same rules as already used by String.prototype.toLowerCase and String.prototype.toUpperCase.