dialectHandling values and defaults

[anba]

CLDR defines three choices for language display names:

• dialect
• standard
• menu

The current proposal text doesn't seem to allow the "menu" kind. Should it be supported?

---

Additionally it seems unfortunate that "dialect" is duplicated in the key ("dialectHandling") and the value ("dialectName"). I wonder if we should avoid the repetition. Also I'm not sure why the "Name" suffix is actually needed in both "dialectName" and "standardName". Can't this just be "dialect" and "standard"?

---

SpiderMonkey follows the recommendation from https://unicode-org.atlassian.net/browse/CLDR-13430 and doesn't use "dialect" as the default value. Should we follow that recommendation instead of using the legacy ICU default of "dialect"? V8 uses the ICU default "dialect" and JSC followed V8 only to increase the compatibility with V8, cf. patch notes in https://bugs.webkit.org/show_bug.cgi?id=209779.

And because SpiderMonkey uses a different default and because we didn't yet receive any web-compatibility bug reports, it seems possible to use either value as the default in ECMA-402.

Also, if ECMA-402 keeps using the legacy ICU default "dialect", does that mean ICU4X will also end up using the same defaults? (Because ICU4X often orients itself at ECMA-402 to allow a seamless integration when using ICU4X as the backend for ECMA-402.)

(SpiderMonkey is actually currently using the "standard" name choice instead of "menu" though, but I no longer remember why "menu" wasn't used. For most names, "standard" is equal to "menu", though.)

---

cc @zbraniecki @codehag

[FrankYFTang]

@sffc

[ryzokuken]

$ eshost -e 'new Intl.DisplayNames("en", {type: "language"}).of("en-US")'
#### JavaScriptCore
American English

#### SpiderMonkey
English (United States)

#### V8
American English

[ryzokuken]

I talked to @zbraniecki about this briefly and as @anba pointed out too, there aren't any bug reports about the inconsistency so it would be fine in my opinion to switch either way.

[sffc]

ICU has two different knobs for "dialect" and "menu". The "dialect" knob is specific to language display names. The "menu" knob is part of the display context, which is tracked by tc39/ecma402#355.

We could either:

1. Add the "menu" variant right now as part of this proposal
2. Wait and let it be done as part of Add support for DisplayContext ecma402#355

The use case for the "menu" variant is described as:

For languages that are part of a larger family, the Survey Tool may request translations of a “menu variant” of the language name that puts the family name first so it will be grouped in a menu together with other languages of the same family.

http://cldr.unicode.org/translation/displaynames/language-names

If we think that's an important use case, then maybe we should make "menu" part of this proposal.

[sffc]

If we were to add it to this proposal, the API could be:

new Intl.DisplayNames("en", { type: "language", languageDisplay: "standard" })
new Intl.DisplayNames("en", { type: "language", languageDisplay: "dialect" })
new Intl.DisplayNames("en", { type: "language", languageDisplay: "menu" })

This would be parallel to "currencyDisplay" and such in Intl.NumberFormat. The options are relevant only for certain types.

[ryzokuken]

In the absence of any strong use-cases for "menu" (after adding "standard"), wouldn't it be best to tackle display contexts in a separate proposal?

[sffc]

Well, the "strong use case" is that this is the format CLDR recommends for drop-down menus (i.e. language pickers), and I think language pickers are one of the main use cases for Intl.DisplayNames.

[sffc]

In some instances, I favor general solutions, and in others, I favor specific ones. This is a case where I think the general solution (display context) may be overkill, and we should consider a specific solution. A specific solution does not exclude the possibility of still adding display context in the future.

[FrankYFTang]

For languages that are part of a larger family, the Survey Tool may request translations of a “menu variant” of the language name that puts the family name first so it will be grouped in a menu together with other languages of the same family.

I think the following should also be quoted together

If your standard translation of the language name already puts the family name first (as in “Kurdish, Central”) then you can supply the same name as the menu variant.

[codehag]

Since this came up in committee, I will try to give a bit of shape to what we want to do here, and give us some next steps.

The two items that need to be addressed are what is the default, and what is the naming.

The default is currently, "dialect" and SM would be happy to align.

Ideally, we would change displayName/standardName -> display/standard.

We haven't come to a conclusion for the "menu" option, but this could be seen as an add on unless we have a compelling reason to add it right away.

Perhaps, in the next month we can answer that question and see this proposal again next meeting.

[FrankYFTang]

Ideally, we would change displayName/standardName -> display/standard.
I support such change to the spec change.

[ryzokuken]

I support shortening to dialect/standard (and menu if we choose to add it as @sffc suggested). Also if we want to avoid repeating dialect in dialectHandling one contender might be languageHandling?

[FrankYFTang]

I am not yet comfortable to add support of "menu" and need more time to research to figure out it is merit for the addition. This is a new feature request and I spin off to a new issue #30 . Please discuss the need and merit of accepting of such new value (as well as implementation difficulty) there instead.

[FrankYFTang]

I also spin off @sffc 's suggestion of renaming dialectHandling to languageDisplay to #31 so we can address independently.