search

brawer / proposal-intl-displaynames

A template for ECMAScript proposals
MIT License
3 stars 2 forks source link

Support Intl.Locale objects in the second param #1

Open zbraniecki opened 6 years ago

zbraniecki commented 6 years ago

Once we have Intl.Locale, we could make the API support it as a second param, it could work like this:

let loc1 = new Intl.Locale("en-US");
let loc2 = new Intl.Locale("fr", {
  region: "CA"
});
let names = Intl.getRegionDisplayNames(navigator.languages, [loc1, loc2]);
names == ["United States", "Canada"];
brawer commented 6 years ago

For getRegionDisplayNames, could the argument be either a string region id such as JP, or an Intl.Locale such as und-JP? (Note the asymmetry between the string region ID, and the string expected by the Locale constructor. To people familiar with BCP47, this is probably obvious. But not sure if general programmers might get confused?)

What result should Intl.getRegionDisplayNames(navigator.languages, [new Intl.Locale('ja')]) return? (Should an implementation maximize the locale?)

zbraniecki commented 6 years ago

Region is an interesting case, because the first subtag is not the language there.

If we support "US" as a string, then we cannot support BCP47 language tag as an argument because it would then take tag like "sr" and interpret it as region Serbia rather than language Serbian.

What result should Intl.getRegionDisplayNames(navigator.languages, [new Intl.Locale('ja')]) return?

Imho it should act as you passed an empty string "" (so, throw?)

(Should an implementation maximize the locale?)

I'd be against that. If you want a maximized version, you can maximize and pass. My main goal in supporting Intl.Locale as an argument is to simplify the scenario when you already have an object and you want to retrieve its region.

brawer commented 6 years ago

If we support "US" as a string, then we cannot support BCP47 language tag as an argument because it would then take tag like "sr" and interpret it as region Serbia rather than language Serbian.

Exactly. So for getRegionDisplayNames, the argument would either be a region code string, or an Intl.Locale object (whose constructor obviously needs a BCP47 code, not a region code). Sounds fine to me.

I'd be against [requiring implementations to maximize the locale]. If you want a maximized version, you can maximize and pass.

Agree.

FrankYFTang commented 5 years ago

@zbraniecki @brawer I am taking over the champion of this proposal now. Somehow, as a novice of github I messed up the transfer process and use a different process that won't carry all the fired issues to https://github.com/tc39/proposal-intl-displaynames. Could you refile your issue in https://github.com/tc39/proposal-intl-displaynames/issues ? Check my two proposed changes on https://github.com/tc39/proposal-intl-displaynames/pulls first. I think that address the issue you have here. I would like to ask to abandon this old one but move all discussion to https://github.com/tc39/proposal-intl-displaynames/issues instead.