Technology Evaluation - Internationalising and Localising UI strings

From wiki.gpii
Revision as of 16:29, 20 July 2017 by CStrobbe (talk | contribs) (The Candidates: column with licence info added)
Jump to: navigation, search


To support the work on the dev PMT, Steve Githens asked if we could add the ability to internationalise messages to gpii-handlebars. I first looked into the support within handlebars itself, they suggest making a helper that accepts some kind of message key.

Writing a helper is not difficult, but we need to look around at what might power this helper, i.e. what would actually be taking a locale, a message string, and variables, and turning that into internationalised text to be displayed.

The Requirements

We need an approach that:

  1. Lets us provide locale-specific wording in our user interfaces.
  2. Supports cleanly interpolating variables.
  3. Works in supported browsers (for client-side rendering).
  4. Works in supported Node versions (for server-side rendering).
  5. Is open source with a compatible license.
  6. Does not introduce an inordinate amount of complexity, for example, by:
    1. Requiring us to convert node libraries using browserify
    2. Requiring loading many and/or very large libraries.
    3. Forcing us to adopt large parts of another framework just to handle this specific problem.

The Candidates

First, we have the i18n support build into Infusion itself. We should consider this as one starting point, but also look at what else is out there. With that in mind, I reviewed every library mentioned in this excellent overview on StackOverflow (including a few mentioned within those projects).

Here is a summary table of all candidates:

Library Meets Requirements Node Support Browser Support Community Complexity Licence
browser-i18n Possibly (when paired with node-i18n or node-i18n2) no yes Long-lived project with very very infrequent updates (years between commits). Low (single library). MIT
counterpart Yes yes yes Modest but consistent activity over the years. Primarily a single maintainer. Low (single library). MIT
ECMAScript i18n API No (no support for strings) yes, in later versions. yes, in most modern browsers. It’s a standard, so the community is the ECMAScript community. Very low (built into the language)  ?
i10n.js No (no node support) no yes Seems like a more or less single maintainer, and the project seems dead at this point. Even their docs site is a 404. Low (single library). MIT
i18n-node-2 Possibly (when paired with browser-i18n) yes no Limited activity, year-long gap between recent commits. Low (single library). MIT
i18n-node Possibly (when paired with browser-i18n) yes no Consistent, but spiky commits. Low (single library). MIT
i18next Yes yes yes By far the healthiest-seeming community with huge momentum, especially recently. Good industry adoption, but limited core committers. Low (single library). MIT
Intl.js Yes yes yes Seems to have less recent activity, but otherwise healthy. Low (single library). MIT
jQuery globalize No (no node support) no yes Massive and vibrant. Low (only requires jQuery). MIT
jQuery Localisation Plugin No (no node support) no yes Very low activity, and none since 2012. Seems dead. Low (only requires jQuery). GPL and MIT
jQuery.i18Now No (no node support) no yes No activity since late 2014. Low (only requires jQuery). MIT
js-lingui No (too complex) maybe yes New project, very active. Seems to be mainly a single maintainer. High (claims neutrality, but heavily skewed towards React) MIT
l10ns No (too complex and not a strong enough community) yes yes Seems like mainly a single maintainer, and not much recent activity. Moderate. They have their own templating and lookup languages. Apache 2.0
l20n.js No (no node support) no yes Seems healthy and fairly active. They look like they’re steadily gaining momentum. Low (single library). Apache 2.0
moment.js No (only dates) yes yes Steady flow of commits and releases, modest group of core committers. Low (single library). MIT
numbro.js No (only numbers) yes yes Slower, but steady flow of commits and releases. Low (single library). MIT
requirejs-i18n No (too complex) yes yes Massive effort, less activity recently. High (requires using a different module loader). MIT
YUI internationalisation No (no node support) no yes No activity since late 2014. Moderate to high, requires using YUI. BSD

After the initial review, the final candidates are:

  1. Infusion itself
  2. i18next
  3. intl.js
  4. counterpart
  5. browser-i18n paired with i18n-node or i18n-node-2

Detailed Review

Once we have discussed the list of candidates, each of the candidates should be reviewed in more depth.


Once there is a detailed breakdown and we have discussed, the conclusions will appear here.