Proposal of adding languageNameOf and regionNameOf methods to Locale

[nciric]

Intl project started mostly because collation requires large amounts of data. Language and region name translations also carry steep size penalty for developers, so it would be nice to expose this data through API for say language and region pickers, or labeling maps, etc.

var t = new Intl.Locale('sr')
t.languageNameOf('en')   // Енглески
t.regionNameOf('GB')     // Велика Британија

var x = new Intl.Locale('sr-Latn')
x.languageNameOf('en')   // Engleski
x.regionNameOf('GB')     // Velika Britanija

For languageNameOf we can accept both string literal or already created Locale object.

For regionNameOf we would accept only string literal with two letter country code. Possibility that would make implementation harder is to also accept Locale object, and expand region using maximize if it's missing.

Question - what do we return if translation is not supported/available? We can return default English names, undefined or throw.

[zbraniecki]

At Mozilla we use mozIntl.getLanguageDisplayNames/getRegionDisplayNames/getLocaleDisplayNames - https://firefox-source-docs.mozilla.org/intl/dataintl.html#mozintl-getlanguagedisplaynames-locales-langcodes

I'd propose we keep this as a separate API set from Intl.Locale since it is a raw localization database, and Intl.Locale is meant to be a lightweight semantic object to operate on locales.

[nciric]

We were deciding between the two, standalone or Locale method - and both have merits, but I do agree, lets keep it separate.

[nciric]

Added new proposal - https://github.com/brawer/proposal-intl-displaynames/blob/master/README.md

[littledan]

I personally like the first proposal better, of a method on Locale! But let's follow up in the new repository either way; given that Intl.Locale is at Stage 3, we should pursue this as a separate proposal at this point.