tc39 / proposal-intl-locale-info Goto Github PK

In 2020-12-03 ECMA402 meeting @sffc suggest the item inside the "defaults" to be an "order list" string instead of a single string to return the preferences . Agree and argue the list should also respect the unicode extension keyword not just return the value from the locale data.

The "direction" property is computed in CharacterDirectionOfLocale from the characterOrder element of UTS 35 layout elements. characterOrder can be one of:

• left-to-right
• right-to-left
• top-to-bottom
• bottom-to-top

which means the "direction" property can be "ttb" and "btt" in addition to "ltr" and "rtl". (Also see #52.)

This in turn means the "direction" property has more possible values than CSS direction, which can lead to compatibility issues and makes it ambiguous which direction (horizontally or vertically) is meant.

cc @jfkthame and @zbraniecki

This is the split of item3 from #26

For all functionality added with this proposal, there should be an appropriate entry added to https://tc39.es/ecma402/#annex-implementation-dependent-behaviour to account for the case when an implementation doesn't ship the necessary data for a specific locale.

CreateArrayFromListOrRestricted() can be simplified to either:

1. If preferred is undefined, then
   1. Return ! CreateArrayFromList(list).
2. Return ! CreateArrayFromList(« preferred »).

Or:

1. If preferred is not undefined, then
   1. Set list to « preferred ».
2. Return ! CreateArrayFromList(list).

In any case, add "!" before CreateArrayFromList.

When passing a language tag which includes the "ca" Unicode extension to ICU, the calendar is taken into account when retrieving the week-info attributes from ICU's UCalendar. Or more concretely, if and only if the calendar is "iso8601", it's taken into account.

Because this makes only a difference when the calendar is "iso8601" and always only modifies firstDay to Monday and minimalDays to 4 days, I don't think providing this feature provides any real value and we should make it clear in the specification that "ca" Unicode extensions shouldn't be taken into account.

Example when "iso8601" is passed to ICU:

js> new Intl.Locale("en-US").weekInfo
({firstDay:7, weekendStart:6, weekendEnd:7, minimalDays:1})
js> new Intl.Locale("en-US-u-ca-iso8601").weekInfo
({firstDay:1, weekendStart:6, weekendEnd:7, minimalDays:4})

CalendarsOfLocale, CollationsOfLocale, and NumberingSystemsOfLocale should return canonical identifiers.

For example "gb2312" instead of "gb2312han" for new Intl.Locale("zh").collations.

During 2020-08-13 ECMA402 meeting. ZB:

This is important info that I can give numerous use-cases for. Lots of applications would require this kind of information eventually.

@zbraniecki: please provides. Thanks

TimeZonesOfLocale ( loc )

• Any reason why the returned names aren't canonicalised?
• If the names are canonicalised, "Link names" can't be appear here, so step 4 should be reworded accordingly.

In the context of TZ Canonicalisation . getTimezones() seems problematic:

1. What are the values for this? Presume Locale 'is_IS' then the canonical timezone according to IANA is Africa/Abidjan which isn't even in the country. See TZ Canonicalisation for more.
   But even if we strike canonical from the proposed specification text, then it's still problematic. First off which timezone would be picked as this information isn't necessarily available (definitely not in TZDB).

2. The second issue is the string sorting applied to that list. That piece of the spec might destroy an intentional order provided by underlying data. Are we sure we want to alphabetically sort timezones?

I noticed that the calendar preference is missing. Actually, we're missing the defaults for most of the unicode extension keywords.

I thought one of the main motivations for this proposal was so you could do:

navigator.locales[0].prefs.calendar[0]

During the 2021-04-08 ECMA402 meeting

"
FYT: OK to change spec to shorter option and go to TC39 Stage 3? Support or object?
RGN: In principle, I’m on board but the current explanation does not support semantics we’ve just been discussing.
...
SFC: Do we have consensus on Intl Locale Info for Stage 3? I support it.
...
RGN: +1, contingent on the changes we talked about
"
This is related to the decision that we treat the -u- extension as a way to "restrict" (vs "to expand")
the list return by

get Intl.Locale.prototype.calendars
get Intl.Locale.prototype.collatiions
get Intl.Locale.prototype.hourCycles
get Intl.Locale.prototype.numberingSystems
get Intl.Locale.prototype.timeZones

@gibson042 @sffc @zbraniecki

Any suggestion WHERE such explanation need to be added?
Do you think we should added to each of these getter? or somewhere else?

This issue is similar to #47.

TimeZonesOfLocale is currently defined to return an empty Array object when no time zones are in use for a specific region. This matches the behaviour of ICU4C. (See also #47)

The other abstract operations ({Calendars,Collations,HourCycles,NumberingSystems,CharacterDirection,WeekInfo}OfLocale) don't define their fallback behaviour. To match the ICU4C behaviour, the description should be updated to say that the locale "und-001" is used as the fallback when the input locale is unsupported. (At least I think that's the default fallback behaviour in ICU4C.)

For example in CalendarsOfLocale, change step 4 from:

Let list be a List of 1 or more unique canonical calendar identifiers, which must be lower case String values conforming to the type sequence from UTS 35 Unicode Locale Identifier, section 3.2, sorted in descending preference of those in common use for date and time formatting in locale.

To something like:

Let list be a List of 1 or more unique canonical calendar identifiers, which must be lower case String values conforming to the type sequence from UTS 35 Unicode Locale Identifier, section 3.2, sorted in descending preference of those in common use for date and time formatting in locale. When no calendar information for locale is available, use the calendar identifiers in common use for the locale "und-001".

For example returning ["gregory"] for new Intl.Locale("tlh").calendars doesn't match the actual calendar used in tlh, but instead reflects that the fallback locale und-001 is used.

There isn't a way for a user to detect when the fallback locale is used instead of the input locale, but that's a pre-existing issue in this proposal.

The other abstract operations are all accepting Intl.Locale objects, only CharacterDirectionOfLocale and WeekInfoOfLocale receive the locale-id as a String value. Maybe worth making this consistent throughout the proposal?

Follow-up to #6

Let's bikeshed the name of .defaults, and whether or not the children are singular or plural.

• locale.defaults.calendars (status quo)
• locale.defaults.calendar (singular)
• locale.prefs.calendar[s]
• locale.likely.calendar[s]
• locale.calendars (pull to the top level; make plural, since the singular is the extension keyword)

TimeZonesOfLocale ( loc )

• Define behaviour when region is an unsupported region.
• For example what is the return value of TimeZonesOfLocale("und-ZX"), where "ZX" isn't a registered region subtag, or what is returned for TimeZonesOfLocale("und-ZZ"), where "ZZ" is the unknown region placeholder, also what should be returned for larger regions like TimeZonesOfLocale("und-019"), where "019" is the region subtag for the Americas?

Related: #30, tc39/ecma402#580

If I write

new Intl.Locale("en-u-fw-tue").getWeekInfo()

then I should get that the first day is Tuesday, but it currently ignores the -u-fw.

From https://tc39.es/proposal-intl-locale-info/#sec-time-zones-of-locale:

Let list be a List of 1 or more time zone identifiers, which must be String values indicating a Zone or Link name of the IANA Time Zone Database, sorted in descending preference of those in common use in region.

In addition to the issue mentioned in #26, TimeZonesOfLocale should be changed to require that the names are sorted alphabetically, because there's no clear preference order for time zones and alphabetical order matches ICU.

A getter can behave this way:

let locale = new Intl.Locale("en-GB");

Object.is(locale.textInfo, locale.textInfo); // false

Then again, { ...obj } could send a fax. Neither the getter nor the trap would violate an invariant, but I’d still be surprised. :)

Getters like this in userland cause bugs when they meet something that expects values read with property access to constitute some meaningful aspect of state that would not have changed as a consequence of this typically “inert” act. For example the old Angular 1 digest loop would have choked on this API for that reason: no matter how many times it read locale.textInfo, it’d always be “dirty again” and an update would be triggered, etc.

Existing intrinsic getter behaviors are idempotent vis a vis the state associated with their receivers. It need not be a simple 1:1 relationship, but the values returned from [[Get]] do not change unless some related state changed. From a [[Get]] object method POV, the builtin getters implement the same relationship to the receiver’s state that the receiver’s own data properties already exhibit. If the textInfo getter produces novel state (especially new object identity) every time it’s evaluated, it’s may be returning results about the receiver’s state (method), it’s not modeling it (getter).

There’s no formalization or definition for this distinction to my knowledge. My attempt at describing the pattern may be pretty bad, but the pattern itself has been followed super consistently to date. There may not be a single exception to it in ECMA-262.

I’d suggest either of these alternatives:

1. Change it to a method (align the API with the existing semantics)
2. Change its behavior to returning a persistently associated frozen object (aligning the semantics with the existing API)

ICU has provided ucurr_getKeywordValuesForLocale() since ICU 4.2. Using this, it should be possible to provide functionality similar to getCalendars(), getCollations(), etc.

Has this been discussed for addition to the Intl Locale Info proposal? If so, what were the reasons for excluding it? If not, is it something you would consider adding?

CharacterDirectionOfLocale as currently written gives the impression that script and region subtags can be ignored and instead there should only be a lookup for characterOrder from UTS 35 layout elements.

This can lead to wrong results, for example:

1. Locale is "az-Arab":
   1. There is no explicit locale for "az-Arab" in https://github.com/unicode-org/cldr/blob/main/common/main/, so the lookup for characterOrder defaults to its parent locale "az".
   2. "az" has no explicit characterOrder definition, so it defaults to its parent locale, the root locale.
   3. The root locale definition for characterOrder is "left-to-right".
   4. But the expected result is "right-to-left", because the script is Arabic.
2. Locale is "az-IR":
   1. Similar to "az-Arab", there's also no explicit "az-IR" locale in https://github.com/unicode-org/cldr/blob/main/common/main/.
   2. But adding likely subtags to "az-IR" gives the locale "az-Arab-IR".
   3. That means the expected result is again "right-to-left".

cc @jfkthame and @zbraniecki

This is spin off from #20 for the last part which will take a longer time to address the request of editorial improvement.

From @sffc

Section 1.4.22: Optional: Convert the paragraph of weekday numbers at the bottom into a table.

I have a following use case:
When I have locale set to en-gb and enter 23/01/2023 I need it to be able to get correct javascript date but I don't see a way to get it using Intl. Maybe this can be something this proposal can cover?

// Kinda want something like DateTimeFromLocale
const dateFromEnGB = new Intl.DateTimeFromLocale('en-gb').format('23/01/2023').toFormat({
		day: '2-digit',
		month: '2-digit',
		year: 'numeric',
});

filing at the request of @sffc
cc @iwsfutcmd

In the current model (proposed in tc39/ecma402#205), textInfo.direction determines ltr vs rtl, likely for the HTML dir tag. Overall; writing system directionality is a far more complicated concept; many writing systems have multiple directionalities, and many are vertical inline.

For example, Chinese can either be written as a horizontal-tb LTR script (like Latin), or a vertical-rl script. Occasionally, one may see vertical-lr in some embedding cases, and shop signs sometimes use horizontal-tb RTL, though we can probably consider these to be stylizations (similar to vertical neon signs in Latin). Either way, there are multiple writing directions on roughly equal footing.

CSS took a lot of time to get out of the rut of privileging horizontal scripts, and I'm worried that direction being a simple property from the start will come and bite us in the future where vertical scripts don't get handled properly.

For the purposes of figuring out HTML dir info perhaps we should have .defaultHorizontalDirection or something more explicit, and/or have direction return something more detailed.

Thoughts?

I've checked afb1e26 and I think the spec does not define the ordering of days in [[Weekend]]. Like, when Saturday and Sunday are weekend, it is possible that weekend array becomes [7, 6].

It is good if we specify that numbers in this array is sorted via %Array.prototype.sort%.

I have reviewed the spec text and approve it modulo the following issues.

Section 1.1.1: You don't need ! on a string literal; see https://tc39.es/ecma262/#sec-createiterresultobject

Section 1.1.2: Replace item 4 with the following version that fixes typos and adds clarifications:

Let list be a List of 1 or more calendar identifiers, which must be String values conforming to the type sequence from UTS 35 Unicode Locale Identifier, section 3.2, sorted in descending preference of those in common use in the locale for date and time formatting.

Section 1.1.3 and 1.1.5: Please make similar changes to the paragraphs as suggested above. You could use the following template, filling in the "_____" as appropriate:

Let _list_ be a List of 1 or more _____ identifiers, which must be String values conforming to the `type` sequence from <a href="https://unicode.org/reports/tr35/#Unicode_locale_identifier">UTS 35 Unicode Locale Identifier, section 3.2</a>, sorted in descending preference of those in common use in the locale for _____.

Section 1.1.4: Apply the same pattern, modified slightly:

Let _list_ be a List of 1 or more hour cycle identifiers, which must be String values indicating either the 12-hour format (*"h11"*, *"h12"*) or the 24-hour format (*"h23"*, *"h24"*), sorted in descending preference of those in common use in the locale for date and time formatting.

And 1.1.6:

Let _list_ be a List of 1 or more time zone identifiers, which must be String values indicating a Zone or Link name of the IANA Time Zone Database, sorted in descending preference of those in common use in _region_.

Sections 1.4.16-20: locale is used before it is defined.

Section 1.4.22: Optional: Convert the paragraph of weekday numbers at the bottom into a table.

getTimeZones() returns undefined when no region subtag is present, whereas getWeekInfo() and getHourCycles() are spec'ed to work even when no region subtag is present.

The underlying CLDR data for week information requires the region to be present. getWeekInfo() even links UTS 35's Week Elements. Same applies for hour-cycle settings, see CLDR timeData element.

Does the current region subtag restriction for getTimeZones just reflects the ICU4C API? And if yes, does it make sense to apply the same restriction to ECMA-402?

ICU4C computes week and hour-cycles information by adding likely-subtags, so even when no explicit region subtag is present, it's still possible to use the corresponding CLDR data by using the likely region subtag. The same approach could be used for time zone information. #53 even kind of implies that implementations should consider always adding likely-subtags to compute the best possible results. Maybe there should even be an explicit step to add likely subtags for each of the new Intl.Locale.prototype.getX() methods?

CharacterDirectionOfLocale mentions characterOrder from UTS 35 layout elements, but only handles the left-to-right and right-to-left cases. It should also handle the top-to-bottom and bottom-to-top cases allowed in UTS 35 for the characterOrder element:

If the value of lineOrder is one of the vertical values, then the value of characterOrder must be one of the horizontal values, and vice versa.

cc @jfkthame and @zbraniecki

I guess we should avoid to replicate the issues from:

• https://unicode-org.atlassian.net/browse/ICU-20805
• https://unicode-org.atlassian.net/browse/CLDR-13294

CLDR doesn't yet provide data for non-contiguous weekends, but maybe we should consider providing an API which can represent them? But I'm not sure how to best represent them, we could have:

• An array of (array) tuples: [[start1, end1], [start2, end2], ...]
• An array of objects with start and end properties: [{start: start1, end: end1}, {start: start2, end: end2}, ...]
• A flattened array of number values: [start1, end1, start2, end2, ...]
• something else...

This is reported by @trflynn89 in #70 (comment)

Copy over here
"Hello - I'm implementing this change over in Serenity's LibJS and had a question. Do the AO definitions of WeekdayToNumber and WeekdayToString seem backwards? Currently WeekdayToNumber returns a string, and WeekdayToString returns a number, which seems pretty confusing to me."
"
It also seems like it's possible to hit the Assert: Should not reach here. step in WeekdayToNumber if we provide an invalid value as a -u-fw extension.

For example, if the user provides en-u-fw-100, then in step 34 of Intl.Locale:

34. Let r be ! ApplyUnicodeExtensionToTag(tag, opt, relevantExtensionKeys).

Then r.[[fw]] will have a value of 100. We will pass that to WeekdayToNumber and fail that assertion.
"

The new abstract operations are missing preambles. There should be at least one of:

When the OP_NAME abstract operation is called with arguments ARG1, ARG2, and ARG3, it performs the following steps:

or:

When the OP_NAME abstract operation is called with arguments ARG1, ARG2, and ARG3, the following steps are taken:

We need to decide the semantic of u extension toward default

Let's let me use zh locale to explain

zh Locale has ["gregory", "chinese"] as commonly used calendars
zh-TW has ["gregory", "roc", "chinese"] as commonly used calendars
now, what is the commonly used calendar for "zh-TW-u-ca-japanese" locale?
There are two possible answers
A. ["japanese", "gregory", "roc", "chinese"]
B. ["japanese']

Answer B mean since zh-TW-u-ca-japanese mean Chinese in Taiwan using Japanese calendar system, the commonly used calendar is only Japanese, but not including [ "gregory", "roc", "chinese"] since the ca-japanese already restrict the calendar to japanese in locale

Another example to consider
ar has ["gregory", "coptic", "islamic", "islamic-civil", "islamic-tbla"] as commonly used calendars
ar-SA has ["islamic-umalqura", "gregory", "islamic", "islamic-rgsa"] as commonly used calendars
ar-EG has ["gregory", "coptic", "islamic", "islamic-civil", "islamic-tbla"] as commonly used calendars

now, what should be the defaults.calendars for ar-u-ca-persian, ar-SA-u-ca-persian, ar-EG-u-ca-persian ?
A
(new Intl.Locale("ar-u-ca-persian")).defaults.calendars return
["persian", "gregory", "coptic", "islamic", "islamic-civil", "islamic-tbla"]

(new Intl.Locale("ar-SA-u-ca-persian")).defaults.calendars return
["persian", "islamic-umalqura", "gregory", "islamic", "islamic-rgsa"]

(new Intl.Locale("ar-EG-u-ca-persian")).defaults.calendars return
["persian", "gregory", "coptic", "islamic", "islamic-civil", "islamic-tbla"]

B
(new Intl.Locale("ar-u-ca-persian")).defaults.calendars return
["persian"]

(new Intl.Locale("ar-SA-u-ca-persian")).defaults.calendars return
["persian"]

(new Intl.Locale("ar-EG-u-ca-persian")).defaults.calendars return
["persian"]

@sffc

Also some quick review notes for this proposal:

1. CreateArrayFromListAndPreferred()

• Can be simplified to either:

1. If preferred is undefined, then
   1. Return ! CreateArrayFromList(list).
2. Return ! CreateArrayFromList(« preferred »).

• Or:

1. If preferred is not undefined, then
   1. Set list to « preferred ».
2. Return ! CreateArrayFromList(list).

• In any case, add "!" before CreateArrayFromList.

2. CalendarsOfLocale ( loc )

• Add requirement that the values are in lower-case.
• Add requirement that no duplicates are returned.
• Prefix CreateArrayFromListAndPreferred with "!".
• Also applies to all other sections.

3. CalendarsOfLocale ( loc )

• For all functionality added with this proposal, there should be an appropriate entry added to https://tc39.es/ecma402/#annex-implementation-dependent-behaviour to account for the case when an implementation doesn't ship the necessary data for a specific locale.

4. CalendarsOfLocale ( loc )

• I think "in common use in the locale" should be "in common use in locale", so without the "the".
• Also I wonder if "for date and time formatting" should appear directly after "in common use".
• Please check both points with native speakers.
• (Same issue also applies to other sections.)

5. TimeZonesOfLocale ( loc )

• Any reason why the returned names aren't canonicalised?
• If the names are canonicalised, "Link names" can't be appear here, so step 4 should be reworded accordingly.
• Define behaviour when region is an unsupported region.
• For example what is the return value of TimeZonesOfLocale("und-ZX"), where "ZX" isn't a registered region subtag, or what is returned for TimeZonesOfLocale("und-ZZ"), where "ZZ" is the unknown region placeholder, also what should be returned for larger regions like TimeZonesOfLocale("und-019"), where "019" is the region subtag for the Americas?

6. get Intl.Locale.prototype.textInfo

• I wonder if the character order computation should be moved into a separate abstract operation.
• That way it's easier to add the "implementation defined behaviour" marker resp. link to it from https://tc39.es/ecma402/#annex-implementation-dependent-behaviour.

7. get Intl.Locale.prototype.weekInfo

• Same issue about moving the locale-specific computation into a separate abstract operation as mentioned for textInfo.
• This separate abstract operation could be defined to return a record {[[FirstDay]], [[WeekendStart]], [[WeekendEnd]], [[MinimalDays]]}, which is then processed in weekInfo.

From https://tc39.es/proposal-intl-locale-info/#sec-collations-of-locale:

Let list be a List of 1 or more collation identifiers, which must be String values conforming to the type sequence from UTS 35 Unicode Locale Identifier, section 3.2, sorted in descending preference of those in common use in the locale for string comparison.

But from https://github.com/unicode-org/icu/blob/4b6e6e1bc9ef90001b4eb169e84ed33d7840b225/icu4c/source/i18n/unicode/ucol.h#L871-L891:

Given a key and a locale, returns an array of string values in a preferred
order that would make a difference. These are all and only those values where
the open (creation) of the service with the locale formed from the input locale
plus input keyword and that value has different behavior than creation with the
input locale alone.

I don't think "preferred order that would make a difference" is equivalent to "sorted in descending preference of those in common use".

For example compare:

js> new Intl.Locale("en").collations
["standard", "emoji", "eor", "search"]
js> new Intl.Locale("de").collations 
["standard", "phonebk", "search", "emoji", "eor"]

I'm not sure "search" is less common in English than in German, is it? And that "eor" is more common than "search" in English.

FWIW ICU returns the order simply based on how the collations are listed in the collation data files. For example for German, the order is constructed as follows:

1. Take the entries from https://github.com/unicode-org/icu/blob/main/icu4c/source/data/coll/de.txt.
   • Order of appearance: "phonebook" and "search".
   • It appears that the entries are simply ordered alphabetically.
2. Append the entries from the root locale https://github.com/unicode-org/icu/blob/main/icu4c/source/data/coll/root.txt
   • Order of appearance: "emoji", "eor", "search", "standard"
   • It appears that the entries are simply ordered alphabetically.
3. Remove duplicates to get the list « "phonebook", "search", "emoji", "eor", "standard" ».
4. Move the default collation, for German that's the default inherited from the root locale, so "standard" to the top.
5. The final result is then « "standard", "phonebook", "search", "emoji", "eor" ».

So the collation order returned by ICU is more like:

• First entry is the default collation.
• The remaining entries are sorted alphabetically by each locale in the locale inheritance chain.

get Intl.Locale.prototype.timeZones is spec'ed to return IANA names, so if we ever extend Intl.Locale to support the "tz" Unicode extension, I have to assume that get Intl.Locale.prototype.timeZone will also return the resolved IANA name instead of the "tz" value. For example new Intl.Locale("en-u-tz-usnyc").timeZones will then return ["America/New_York"]. And following that line of thought, I assume new Intl.Locale("en-u-tz-usnyc").timeZone (so singular "timeZone") will then also return "America/New_York", to keep things consistent.

Do we expect that this will cause any issues for users who want to access the actual value "usnyc"?

@sffc in 2020-12-03 meeting suggest that the unit info / measurement system in CLDR is not really mature yet and suggest we not put the unitInfo at this stage. Agree with @sffc and will remove it from the speicifcation.

Per https://tc39.es/proposal-intl-locale-info/#sec-hour-cycles-of-locale:

Let list be a List of 1 or more collation identifiers, which must be String values conforming to the type sequence from UTS 35 Unicode Locale Identifier, section 3.2, sorted in descending preference of those in common use in the locale for string comparison.

Intl.Collator suppresses "standard" and "search" collations, because they're handled through the "usage" property. I'm not sure the same reasoning also applies to CollationsOfLocale(), especially because the current spec text describes that the commonly used collations should be returned, which normally do include "standard" and "search".

However we decide to handle those two collation identifiers, we should definitely explicitly mention them in CollationsOfLocale().

UTS 35 defines a number of locale keyword extensions that aren't yet in 402. We should design an API that cannot conflict with them. For example:

+ get Intl.Locale.prototype.measurementSystem

That would conflict with the -u-ms- extension.

In general, of the properties you are adding, some of them are supported by locale keywords, and some are not. These settings are supported by locale keywords:

• get Intl.Locale.prototype.firstDayOfWeek (-u-fw-)
• get Intl.Locale.prototype.defaultHourCycle (-u-hc-)
• get Intl.Locale.prototype.measurementSystem (-u-ms-)
• get Intl.Locale.prototype.defaultCalendar (-u-ca-)

The following are not currently supported by locale keywords. However, all of them except maybe "direction" could potentially be supported in a future version of UTS 35:

• get Intl.Locale.prototype.minimalDaysInFirstWeek
• get Intl.Locale.prototype.weekendStart
• get Intl.Locale.prototype.weekendEnd
• get Intl.Locale.prototype.direction
• get Intl.Locale.prototype.commonCalendars

You may wish to mention https://github.com/gamtiq/weekstart which is probably currently the best standalone solution for getting first day of the week.

I golfed it heavily for a StackOverflow answer.

Entrance Criteria for Stage 3 (Candidate) require
Designated reviewers have signed off on the current spec text

So we need at least 2 stage 3 reviewer for this proposal.
I somehow thought the Stage 3 reviewers are needed AFTER advanced to Stage 3 to review spec DURING Stage 3 so I didn't ask people to sign up us Stage 3 Reviewers while I proposed to move from Stage 1 to Stage 2.

@sffc @ryzokuken @zbraniecki @anba

Intl.Locale.prototype.textInfo only returns the characterOrder, cf. CharacterDirectionOfLocale, but UTS 35 layout elements also defines lineOrder.

For example the characterOrder for the locale "mn-Mong" is "top-to-bottom" and its lineOrder is "left-to-right". Also see https://en.wikipedia.org/wiki/Mongolian_script.

cc @jfkthame and @zbraniecki