Round-trip conversion — eg displayNames.for(‹name›, ‹locale›)

[SMotaal]

I may have missed it, but it might be worth considering to offer a convenience method(s) for going from specific locales other than English.

This could roughly take the form of displayNames.for(‹name›, ‹locale›) with more or less verbose parameters where applicable.

[FrankYFTang]

Not sure how is that usage? Current you do

let names = new Intl.DisplayNames("fr", {style: "language"});
names.of("en") // Get the name for "English" in French

for the above use case, what will be the call in your suggestion? I assume you have then make the for as a method for Intl.DisplayNames instead of a prototype of Intl.DisplayNames instance, right? so with your suggestion the code will look like

Intl.DisplayNames.for("en", {style: "language"}, "fr") // Get the name for "English" in French

Is this what you are suggesting?

[sffc]

I assume the suggestion is one of the form,

let names = new Intl.DisplayNames("en", {style: "language"});
names.parse("English");  // "en"

Parsing is a fundamentally more challenging problem.

• Languages, countries, and other entities handled by Intl.DisplayNames can have multiple valid names. For example, "North Macedonia" (current) vs "Former Yugoslav Republic of Macedonia" (obsolete but still used). Do we only support one name, or should we support more?
• How do you handle abbreviations, like "US" vs "USA" vs "United States" vs "United States of America"? Only match names strictly being output from the Intl.DisplayNames instance?
• Names can be ambiguous, like "Congo" or "Korea" (which Congo or Korea?)

In general, without a significant amount of extra data and logic, such a feature is not useful for parsing free-form user input. At best, it can be used to round-trip the strings, but then that raises the question about why this is needed in the first place. You should always work with identifiers in your code, and convert the identifiers to display names only at the very last second.

[SMotaal]

Wasn't sure how to best frame it at first… but now, a round-trip example based on the README doc might do the trick 😄

console.log(currencyNamesZH.of('USD')); // "美元"
console.log(currencyNamesEN.for('美元', 'zh-Hant')); // "USD"

I am not particularly concerned about how the actual interface would work, just the idea that sometimes end-users will get json data from various sources. So, while their UI requirements (ie output locales) are fixed, the source data they might want to work on (ie input locales) are philosophically speaking everyone on planet earth.

Practically speaking anyway, there is likely, in more use cases, a locale variability factor of input data, compared to potentially fewer use cases (imho) like a client-side universal translator that works only with Intl data where the variability factor of output data may still be well served by the need for managing separate instances.

If both input and output required new instances, my fear is that this exponentially makes it less appealing to the end-user, if not untenable for more critical applications.

[FrankYFTang]

this api is not aiming to provide a "conversion" from one string to another string but instead to access a string by a given ID. Therefore, I do not believe the concept of "round-trip CONVERSION" apply here. I understand the desire to have a way to "understand" what a string in natural language represent, but that I believe is beyond the charter of this API we first established.

[SMotaal]

Thanks for clarifying.

Could this be considered as a future extension?

Note: Apologies if this sounds redundant to your previous answer — I guess I am seeking just clarity by asking.

[sffc]

If you are passing around JSON data, you should always use the country identifier. That's the point of having a standardized identifier. The display name of the country is intended for human consumption only, not for interchange.

You are welcome to open an issue for this on the main ecma402 repository if you want to follow up. I'm closing this issue though because this is out of scope of the current proposal.