Section 9.1 AvailableLocales shouldn't require base language if script is present

[sffc]

It seems like it should be allowed for AvailableLocales to support zh-Hant but not zh, since zh implies zh-Hans. However, the spec currently states:

Additionally, for each element with more than one subtag, it must also include a less narrow language tag with the same language subtag and a strict subset of the same following subtags (i.e., omitting one or more) to serve as a potential fallback from ResolveLocale.

[gibson042]

since zh implies zh-Hans

Is there any spec text supporting this claim? I would consider it perfectly reasonable for an implementation that has data for "zh-Hant" but not "zh-Hans" to use the former in service of requested locale "zh", and any application that specifically warrants "zh-Hans" should be specific.

On the other hand, it would seem bizarre and in violation of the spirit (if not also the letter) of BCP 47 to support narrow data in absence of covering broad data. Some excerpts:

• «A language tag is composed from a sequence of one or more "subtags", each of which refines or narrows the range of language identified by the overall tag»
• «In the lookup scheme, the language range is progressively truncated from the end until a matching language tag is located. Single letter or digit subtags (including both the letter 'x', which introduces private-use sequences, and the subtags that introduce extensions) are removed at the same time as their closest trailing subtag.»
• «For example, a user who reads both Simplified and Traditional Chinese, but who prefers Simplified, might use the range "zh" for filtering (matching all items that user can read) but "zh-Hans" for lookup (making sure that user gets the preferred form if it's available, but the fallback to "zh" will still work)»
• «Whether a subtag adds distinguishing value can depend on the context of the request… If the user cannot be sure which scheme is being used (or if more than one might be applied to a given request), the user SHOULD specify the most specific (largest number of subtags) range first and then supply shorter prefixes later in the list to ensure that filtering returns a complete set of tags.»

I don't think that's invalided by Unicode likelySubtags logic, which improves "best case" results but should not preempt such "worst case" scenarios.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2024-12-19.md#section-91-availablelocales-shouldnt-require-base-language-if-script-is-present-947

[sffc]

CC @eemeli

I think my main problem here is that the spec requires zh to be supported if zh-Hant is supported, even if the user agent does not believe that this is an appropriate fallback. A user agent can and should be allowed to strictly follow "likely subtags" locale matching.

[gibson042]

even if the user agent does not believe that this is an appropriate fallback

I don't agree with the characterization of "zh" as a fallback for "zh-Hant"... it's a generalization that uses the same language but lacks any specification of script, and therefore encompasses "Hant" but also "Hans" (and for that matter, "Hani" and "Hanb" and "Latn" as well).

A user agent can and should be allowed to strictly follow "likely subtags" locale matching.

Well, lookup by prefix is pretty strongly baked in via localeMatcher: "lookup" and required by RFC 4647 section 3.4, and disregarding it would seem to necessarily be backwards-incompatible. I don't consider such changes lightly, so could you provide a concrete example (i.e., using ECMA-402 APIs) of how it would be beneficial?