`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.