Open littledan opened 6 years ago
See also https://github.com/tc39/ecma402/issues/31 . It proposes Intl.DisplayName. We also need options for name variants (official, causal, in-sentence, for menu item, etc).
See also tc39/ecma402#31 . It proposes Intl.DisplayName.
This is potentially a separate API. We implemented both: Intl.getDisplayNames
and Intl.get{Language|Region|Locale}DisplayNames
:
I'm happy to revisit and unify, but I believe that the reason we kept locale in particular as a separate API is that it does pattern operation on language/region pair. getDisplayNames
just returns names from CLDR. (of course that means that getDisplayNames
could cover standalone language and standalone region, just not the locale).
The reason I want for of what Daniel describes as a second variant is because all our usecases were lists. It almost never happened that a user needs to retrieve a display name of 2 locales. In some cases its one, but in almost all cases its a high number of locales - usually for a language/region/locale selection list/menu etc.
of course that means that getDisplayNames could cover standalone language and standalone region, just not the locale
@zbraniecki please could you give examples for standalone language and standalone region?
@littledan let's also compare the space complexity of each proposal. It seems like individual functions such as Intl.getLanguageDisplayNames
makes available specific portions of i18n data (i.e., CLDR), while other flavors would make available a much more broader portion (i.e., all supported features) of CLDR for later use.
@rxaviers Do you mean this as a vote in favor of the constructor-based approach?
Sure, let me clarify. Not a vote yet because I don't know if there are real implications...
I am wondering what's the cost in terms of storage for the different proposals. I guess both constructor-based approaches (i.e., the Locale method and factory object) would need to carry the complete set of data when initialized, because it doesn't know beforehand which "subfeatures" user would use (e.g., region display names, language display names, etc). How much space does this instance cost? Is this data already available in memory or does it have to be initialized? What's the cost for multiple instances?
The specific Intl function such as Intl.getLanguageDisplayNames
already defines the scope, i.e., in this example the language display names only. Therefore, it requires a smaller data subset, a smaller footprint. It's worth to point out the same could be achieved on the constructor-based approaches if it took a "scope" option such as new Intl.DisplayName("sr", {languages: true})
.
That being said, I'd like to hear about folks who have already implemented this and know the details. :)
I'd be surprised if the instances had nontrivial size. I thought they would just be views onto whatever data exists in a data file and might be loaded into memory on demand, or all at once at startup (not sure how ICU loads this data exactly).
No heap allocation. Icu data is usually memory-mapped.
Ok thanks for clarifying...
sorry. made some mistake in the UI and accidentally close it.
In favor of a factory object
I am in favor of the "factory object" approach
Hi all- 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.
Please either close this issue or refile this and other issues in that other repo so everything can be tracked together. I think this one can be closed, right? We have sort of settled on the factory approach.
@nciric originally suggested this feature as a method on
Intl.Locale
, rather than a function propertyIntl
. Personally, I was originally thinking that we would eventually go with this as a method on locales. There's a third possibility, of making a display name factory, analogous to other Intl formatters. Let's discuss the pros and cons of each path here:In favor of a Locale method
var x = new Intl.Locale('sr-Latn') x.languageNameOf('en') // Engleski x.regionNameOf('GB') // Velika Britanija
In favor of a factory object
var x = new Intl.DisplayName('sr-Latn') x.languageNameOf('en') // Engleski x.regionNameOf('GB') // Velika Britanija