"case-syntax" parsing isn't robust.

[askvortsov1]

Hi! I'm a core developer on the Flarum FOSS Project. We're currently considering options to support ICU MessageFormat syntax in our frontend translator, since we need a consistent API with our backend Symfony translator, which recently dropped a proprietary pluralization format in favor of ICU MessageFormat. I was excited to come across your project after finding alternatives to be absolutely massive in size. I've found a few bugs, and would be glad to contribute fixes.

Consider the following message template:

{gender_of_host, select,
	female {{host} invites you to her party}
	male {{host} invites you to his party}
	other {{host} invites you to their party}
}

If the value given is male, the current algorithm will pick up the suffix of female and return the wrong string. This issue is symptomatic of a greater problem with the current parsing strategy used in pluralTypeHandler and selectTypeHandler:

• Nested "case" blocks fail (https://runkit.com/askvortsov/606a9e81ef6d2a001a82da44)
• =N syntax is hard to implement

I've solved this by making a custom parser, and using that to implement the type handlers. I'll open a PR.

Beyond this, there's a few further additions I think would be cool, but wanted to run by you first. I might be able to PR these as well if time allows.

• With the parseCases system I mentioned above, it should be very easy to support the offset:n argument available to plural blocks.
• The plural one special case is currently hardcoded to be 1, but that's not particularly useful for localization. It might be useful to be able to supply custom logic per-locale to identify matching plural rules. Perhaps pluralTypeHandler could be wrapped by a factory function that would accept a list of such callbacks?
• I see that in https://github.com/ultraq/react-icu-message-formatter you implement react components in translations via type handlers. Being able to use surrounding angle brackets would be more conventional though (as done in https://github.com/format-message/format-message/tree/master/packages/format-message#formatmessagerichpattern-args-locales). We implement a similar system within Flarum (https://github.com/flarum/core/blob/master/js/src/common/Translator.js#L72-L103). Perhaps a system similar to type handlers but for HTML/XML-type tags might make sense to be included.
• TypeScript!

[ultraq]

Hey there! 👋 Thanks for checking out my project and finding some bugs in it.

If the value given is male, the current algorithm will pick up the suffix of female and return the wrong string.

Oh dear 🤦 I'll definitely give your PR a look. You mentioned a custom parser, but it doesn't look like the PR is so huge that it adds a tonne of code except for tests (I know intl-messageformat/react-intl uses a parser under the hood and it makes up for quite a good portion of that library), so that makes me happy.

I'll get to your other points after the PR - you've definitely given me a lot to look at! 😅

[ultraq]

(Reopening issue since there's still all those other points to discuss)

[ultraq]

OK, probably time I closed this! The original issue about the case parsing has been solved by the linked PRs, and being able to use <...> syntax within messages has been implemented with the OP's projects that builds atop this. I'm also working on a release that includes type definitions so it's not quite TypeScript but it should clear those 'cannot find type declarations' errors in TypeScript projects.