alt Hacker NewsOne practical thing I appreciated about MessageFormat is how it eliminates a bunch of conditional UI logic.
I used to write switch/if blocks for:
• 0 rows → “No results” • 1 row → “1 result” • n rows → “{n} results”
Which seems trivial in English, but gets messy once you support languages with multiple plural categories.
I wasn’t really aware of how nuanced plural rules are until I dug into ICU. The syntax looked intimidating at first, but it actually removes a lot of branching from application code.
I’ve been using an online ICU message editor (https://intlpull.com/tools/icu-message-editor) to experiment with plural/select cases and different locales helped me understand edge cases much faster than reading the spec alone.
Replies
Did not gettext have this for decades? https://www.gnu.org/software/gettext/manual/html_node/Plural...
This reminds me of https://perldoc.perl.org/Locale::Maketext::TPJ13
Seems like to get it right for every use case / language, you would need functions to translate phrases - so switch statements may be a valid solution. The number of text elements needed for pagination, CRUD operations and similiar UI elements should be finite :)
I checked the spec and don't get that really. Something should specify the formula for choosing the correct form (ie 1 for 21 in Slavic languages) and the format isnt any better compared to the gettext of 30 years ago
that's a lazy feature. dealing with this on the front end is the right thing so you can have rich empty states anyway.
This post shows a lot of the challenges with localisation, that many seemingly simple tools don't have an answer to: https://hacks.mozilla.org/2019/04/fluent-1-0-a-localization-...
(Fluent informed much of the design of MessageFormat 2.)