i18n.getMessage() pluralization

[xPaw]

Currently it is not possible to easily implement correct pluralization using existing i18n apis.

There is Intl.PluralRules, and a proposal for Intl.MessageFormat here: https://github.com/tc39/proposal-intl-messageformat

But since extension localization is stored in JSON, it might be simpler to do something like this:

"new_notifications": {
	"message": {
		"zero": "You have no new notifications",
		"one": "You have $count$ new notification",
		"two": "You have $count$ new notifications",
		//"few": "",
		//"many": "",
	},
	"placeholders": {
		"count": {
			"content": "$1"
		}
	}
}

The keys match return values of Intl.PluralRules. However with this particular example it only allows matching against one placeholder, maybe it should be done in placeholders:

"new_notifications": {
	"message": "$count$",
	"placeholders": {
		"count": {
			"match": "$1", // this could more closely represent matches in MessageFormat 2.0
			"content": {
				"zero": "You have no new notifications",
				"one": "You have $1 new notification",
				"two": "You have $1 new notifications",
			}
		}
	}
}

[aphillips]

You should probably pay attention to the Intl.MessageFormat work (and its parent, the Unicode MessageFormat v2 specification, which is in Technical Preview). (Note that I am chair of the Unicode MF working group).

Intl.PluralRules are insufficient for most applications, since you often will need specific value matching. Messages also frequently need more than one plural selection in a single message. MFv2 provides message structure for this, along with the supporting algorithms and the ICU library (built in to many browsers) provides an implementation.

The MFv2 syntax might be decomposed into a more JSON-like structure (instead of being kept as a single string). There is discussion of creating a MessageResource format standard at Unicode, or, if your format is sufficiently developed/deployed, you might describe MFv2 messages using a JSON structure. I would be tremendously sad if a competing syntax (or five) were developed.

[xPaw]

The MFv2 syntax might be decomposed into a more JSON-like structure (instead of being kept as a single string).

That's mostly what I was suggesting, I just threw a quick example since the web extensions i18n uses JSON for the messages. The real problem is that i18n api does not support pluralization at all currently.

[oliverdunk]

We discussed this during an in-person meeting at TPAC, both during our issue triage session and a joint session with the W3C Internationalization (I18N) Working Group. We are all supportive of expanding the browser.i18n API and agree that MFv2 seems like the best candidate for this.

Tentatively, our plan is to wait for the MFv2 specification to be finalized and we will then look at the next steps here.

Normally we'd favor the first issue opened on a given topic (thanks for opening this!), but there's now a more concrete proposal in #698. We agreed that in this case we'd prefer to use that issue for tracking purposes.

Closing this in favor of #698.