By contrast, Mozilla’s L20n framework handles pluralization by letting the translator for each language write macros. They advise you to define a plural macro, such as this one for Slovenian:

<plural($n) {
  $n == 0 ? "zero" : 
  $n % 100 == 1 ? "one" : 
  $n % 100 == 2 ? "two" : 
  $n % 100 == 3 || $n % 100 == 4 ? "few" : 
  "many" 
}>

You only need to define plural once per language, and a native speaker of that language can probably implement its pluralization rules in 10 minutes. So L10ns’s and MessageFormat’s automatic categorization of the plurality of numbers sounds convenient, but not that important a feature. Though I don’t know whether L20n also makes you reimplement other information in the CLDR, like a language’s date and currency formats.

The article’s Benefits of Inlining section touts the way inlining lets you avoid writing the same phrase in multiple strings. Yet the ICU’s official page on MessageFormat advises that you not use this feature, and use a more repetitive but simpler style:

It is tempting to cover only a minimal part of a message string with a complex argument (e.g., plural). However, this is difficult for translators for two reasons: 1. They might have trouble understanding how the sentence fragments in the argument sub-messages interact with the rest of the sentence, and 2. They will not know whether and how they can shrink or grow the extent of the part of the sentence that is inside the argument to make the whole message work for their language.

Honestly, I’m just thrilled to hear people talking about i18n at all. But for what it’s worth, this article has a nice primer on one of the possible technology stacks for dealing with it, and lots of nice technical detail.