Expose parentLocale info via public API about intl-messageformat HOT 3 CLOSED

I suggest this since not all parents can apparently be determined by removing the portion from the last hyphen; the following shows the current mappings from your source that break this rule:

• pt-AO -> pt-PT
• en-150 -> en-001
• es-AR -> es-419
• es-BO -> es-419

(Incidentally, the mappings https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry does not appear to be informed by these potentially useful mappings of regional script relationships (e.g., that Angolan Portuegese is apparently related more closely to Portuguese from Portugal than general Portuguese), as it only indicates encompassed->macrolanguage mappings for (oral) languages.)

from intl-messageformat.

In the case of your code, I just noticed that it states, "Since we lack the proper parentLocale data here, we must take a naive approach to traversal", which seems puzzling as your locale-data files do add parentLocale info and that code should be able to access it if available.

However, maybe my request is more suited for its own Intl spec since such a lookup is not limited to message formatting--though message formatting does drive home its necessity (as would it be nice to have a generic auto-detecting directionality (ltr/rtl) utility (from IANA "Suppress-Script"?) for the sake of locales) (I see the latter is being discussed at tc39/ecma402#46 ).

from intl-messageformat.

Closing this in favor of tc39/ecma402#87 (for which a polyfill will hopefully come along sooner rather than later)...

from intl-messageformat.