Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n.getMessage() pluralization #639

Closed
xPaw opened this issue Jun 14, 2024 · 3 comments
Closed

i18n.getMessage() pluralization #639

xPaw opened this issue Jun 14, 2024 · 3 comments
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time supportive: safari Supportive from Safari topic: localization

Comments

@xPaw
Copy link

xPaw commented Jun 14, 2024

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",
			}
		}
	}
}
@github-actions github-actions bot added needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time labels Jun 14, 2024
@carlosjeurissen carlosjeurissen added the i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. label Jun 20, 2024
@xeenon xeenon added supportive: safari Supportive from Safari and removed needs-triage: safari Safari needs to assess this issue for the first time labels Jun 20, 2024
@aphillips
Copy link

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
Copy link
Author

xPaw commented Jun 26, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time supportive: safari Supportive from Safari topic: localization
Projects
None yet
Development

No branches or pull requests

6 participants