[mikewhy]

Are there any advantages over i18n-js[1]? Can't say I'm a huge fan of this method of pluralization:

    Cart: {itemCount} {itemCount, plural,
        one {item}
        other {items}
    }

[1]: https://github.com/fnando/i18n-js

[drewfish]

Yeah, for a simple plural that can be a bit longer. In other languages, though, the pluralization rules get rather complicated[1]. (For example, Arabic has both complicated pluralization rules -and- a lot of people who speak it.)

The strength of the ICU message format, in my mind, is that the messages can be "nested" so that the translation can be customized for multiple concerns (plural, gender, whatever).

Also, with the integrations (dust, handlebars, react) the details of translation and display of data lives in the message format and/or template. This is the "view layer", and means that your controller/code isn't littered with a bunch of calls to a translation library.

[1] http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/la...

[mikewhy]

Nice, I didn't know that about Arabic, and the many other languages.

Though i18n-js does let you write your own pluralizations rules (taken from the readme), while supporting zero/one/many out of the box:

    I18n.pluralization["ru"] = function (count) {
      var key = count % 10 == 1 && count % 100 != 11 ? "one" : [2, 3, 4].indexOf(count % 10) >= 0 && [12, 13, 14].indexOf(count % 100) < 0 ? "few" : count % 10 == 0 || [5, 6, 7, 8, 9].indexOf(count % 10) >= 0 || [11, 12, 13, 14].indexOf(count % 100) >= 0 ? "many" : "other";
      return [key];
    };

I've posted an example below, but I don't consider `@div null, @t('welcomeMessage', { username })` "littering" my code.

[drewfish]

There are a few NPM libraries (make-plural, cldr, probably others) which will help you write those pluralization functions. The CLDR data does get updated from time to time, so it's nice to rely on another package to trace those changes.

[caridy]

I haven't look into i18n-js library in details, but this is what I can spot so far:

* the message format in i18n-js seems to be compatible with ICU message syntax, the industry standard used in other programming languages and the one used by formatJS as well. we will have to check if they really implemented all the specs, which makes the messages more advanced, e.g.:

``` Cart: {itemCount, plural, =0 {no items} one {one item} other {# items} } ```

including the fact that itemCount from `other` option will be formatted as a number, saying "1,030" in EN, vs "1 030" in FR.

* i18n-js is a js library, which means you have to do the formatting in your js code, then passing the formatted data into the template engine where you have the placeholders for them, while FormatJS focuses more on the high-level declarative form that you can use in your templates directly, which makes things simpler, if you use handlebars, you could do: {{formatMessage "Cart" itemCount=numItems}} right in your template.

[mikewhy]

> i18n-js is a js library, which means you have to do the formatting in your js code, then passing the formatted data into the template engine where you have the placeholders for them

Not sure I follow, taken from a React component:

    Component = React.createClass                                                
      render: ->                                                                
        @div null,
          @t('welcomeMessage', username: @props.CurrentUser.displayName)

[ougawouga]

I have nothing against Coffeescript, and use it myself sometimes. But please don't respond to something about "js" and then put down a single coffeescript snippet with no additional context. It's very confusing.

I had to re-read the last line several times before I looked up at the function arrow and realized it was coffeescript, and that the "@" were not part of the i18n library, but rather the syntactic sugar for "this".