Normative: Intl Locale API proposal for Stage 4

[FrankYFTang]

The spec text change for https://github.com/tc39/proposal-intl-locale-info

We should discuss this once Intl Locale Info API is ready to move to stage 4.
This is one of the require task.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-12-19.md#intl-locale-info-api-for-stage-4

[sffc]

TG2 approval: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-10-13.md#intl-locale-info-for-stage-4-1

[FrankYFTang]

Ready to be review for merging if Intl Locale Info advanced to Stage 4. Still need to merge tc39/proposal-intl-locale-info#92 into this PR first if TC39 approve both

[FrankYFTang]

@ben-allen @gibson042 @ryzokuken will be nice if you can voice your concern or support about this PR from the editor's view ASAP before the TG1. Thanks

[gibson042]

A few things to fix before approval.

[gibson042]

This logic seems like it belongs in TimeZonesOfLocale, replacing the assertion and bringing it in better alignment with LocaleDirection.

         1. Let _region_ be GetLocaleRegion(_loc_.[[Locale]]).
-        1. Assert: _region_ is not *undefined*.
+        1. If _region_ is *undefined*, return *undefined*.
         1. Let _list_ be a List of unique canonical time zone identifiers, which must be String values indicating a canonical Zone name of the IANA Time Zone Database, of those in common use in _region_. The list is empty if no time zones are commonly used in _region_. The list is sorted according to lexicographic code unit order.
         1. Return CreateArrayFromList( _list_ ).

Suggested change

	1. Let _region_ be GetLocaleRegion(_loc_.[[Locale]]).
	1. If _region_ is *undefined*, return *undefined*.

[gibson042]

Does test262 cover absence of a "direction" property in any case? I'd strongly prefer it to always be present on the returned object, rather than potentially falling through to Object.prototype (even though resolvedOptions output is also vulnerable to that issue).

[FrankYFTang]

prefer it to always be present on the returned object

that will be a normative change, right?

[gibson042]

Well, that's exactly what I'm getting at. On my machine, all implementations supporting Intl.Locale.prototype.getTextInfo (JavaScriptCore, LibJS, and V8) include a non-empty string-valued direction property for each of the 26**2 + 26**3 = 18252 language-subtag-only alpha{2,3} sequences—are you aware of a locale for which any of them would fail to exercise this CreateDataPropertyOrThrow step? Because if there isn't one, then I'd consider this a non-normative change that we should make now to avoid problems in the future.

[FrankYFTang]

are you asking me which locale that the (new Intl.Locale(locale))getTextInfo().direction would be undefined?

[FrankYFTang]

According to the spec, the following value should be undefined but V8 and Safari currently is not implemented correctly

(new Intl.Locale("und-Zyyy")).getTextInfo().direction
(new Intl.Locale("und-Zinh")).getTextInfo().direction
(new Intl.Locale("und-Zzzz")).getTextInfo().direction
(new Intl.Locale("und-Brai")).getTextInfo().direction

See discussion in tc39/proposal-intl-locale-info#101

[gibson042]

Then it seems to me like this change is still appropriate, especially since tc39/proposal-intl-locale-info#101 (comment) documents the TG1 decision as

The API getTextInfo can return an object with a field containing the string value "ltr", the string value "rtl", or undefined

(i.e., that the field should be present with value undefined rather than absent)

@ben-allen @ryzokuken what are your thoughts?

[FrankYFTang]

I see this kind of if x is not undefined CreateDataPropertyOrThrow pattern in many places

1. all resolvedOptions() in ECMA402
2. in ecma262
   https://tc39.es/ecma262/#sec-frompropertydescriptor
   https://tc39.es/ecma262/#sec-copydataproperties
   https://tc39.es/ecma262/#sec-object.getownpropertydescriptors

[FrankYFTang]

PTAL
I adress your feedback
I also merge the last PR in the proposal

and in 2025-11-18 TC39 this stage 4 proposal is advanced to stage 4

[FrankYFTang]

PTAL