Equivalent of `supportedLocalesOf` for letter-case conversion (`toLocaleLowerCase`, `toLocaleUpperCase`)

๐Ÿ’ก Ideas
1

I originally asked on StackOverflow if there's any way of introspecting the supported locales supported by toLocaleLowerCase and toLocaleUpperCase, and the answer seems to be a resounding no.

In JavaScript, you can introspect support for various internationalization functionality by use of static supportedLocalesOf methods of the various classes namespaced under Intl. For example:

Intl.PluralRules.supportedLocalesOf(['pt', 'yue', 'hyw']) // ['pt', 'yue']
Intl.Segmenter.supportedLocalesOf(['pt', 'yue', 'hyw']) // ['pt']

I'm not talking about feature detection, which can be done on an ad-hoc basis if you know how to feature detect specific characteristics of the locale:

const turkishIsSupported = 'i'.toLocaleUpperCase('tr') === 'ฤฐ'

However, checking like this requires custom logic and knowing what features to test for. What would be useful is a simple way of checking that a given locale is supported, without prior knowledge of that locale's features.

I'm not sure where such a method would logically live, given that there is no namespaced class under Intl for letter-case conversion methods. Some options:

  • Add one (seems a bit overkill if it's only used for this one purpose):
    Intl.LetterCase.supportedLocalesOf(locales)
// or...
Intl.CaseMapper.supportedLocalesOf(locales)
  • Attach the method as a property of the string prototype methods (is there much precedent for this in the web platform?)
    String.prototype.toLocaleLowerCase.supportedLocalesOf(locales)
'xyz'.toLocaleUpperCase.supportedLocalesOf(locales)
  • A top-level method on Intl:
    Intl.supportedLocales('letter-case', locales)
Intl.supportedLocales('plural-rules', locales)
  • Something else?
2

You may be interested in the related discussion about toLocaleUpperCase locale resolution: Normative: Update String toLocale{Lower,Upper}Case to ResolveLocale with best-fit matching by gibson042 ยท Pull Request #956 ยท tc39/ecma402 ยท GitHub

Basically, asking whether formatting is "supported" is much different than asking if text transformation is "supported". In practice, all i18n libraries "support" all locales for text transformation, for two reasons:

  1. These operations are script-based more than language-based, and all scripts are "supported" (at least up to the engine's Unicode version).
  2. Some locales may have tailorings on top of the script rules, but they are just that, tailorings. Without the tailorings, you still get intelligible results, unlike in a formatter where your output might be in a completely different language than requested and therefore unintelligible.