Living in a country with two official lanaguage means that you don’t get far into a project before the question of internationalization (aka i18n to anyone who has to type it more than a few times) comes up.
There are a few options for dealing with this in Javascript, but it’s taken a while to find one I like. First, I expect to use the same library on the server and on the client, and I expect to be able to use it with libraries like React.
React-Intl works OK on the client side, but using the underlying Intl on the server looks under-documented and deeply clunky. I18next is reasonable on the server and has integrations with most client side frameworks. While it’s a decent choice, there is something about the way it works which rubs me the wrong way.
i18next.init({
lng: 'en',
fallbackLng: 'en',
resources: {
en: {
translation: {
person: {
firstName: "First name",
lastName: "Last name",
}
},
},
fr: {
translation: {
person: {
firstName: "Prénom",
lastName: "Nom de famille",
}
},
},
}
})
The above code shows how to use it. It’s a pretty standard setup (very familiar if you’ve ever done i18n in Rails), some singleton object (you can make others if you need to) with an internal collection of messages which are stored as a JSON object.
One of the things that I dislike about this approach is that the translations stored in that JSON object tend to accumulate and hang around long after the code that needs that message is gone.
The other thing I find doesn’t sit well with me is the way you access those messages: i18n.t('mutation.fields.purchase.args.expiryYear').
What you are looking at is a function call that assumes the existence of an object like {translation:{fields:{purchase:{args:{expiryYear: "Expiry year"}}}}}. This an example of structural coupling, my code depends on the structure of that object. This sort of thing is normally considered an anti-pattern, a violation of the “law of Demeter”, but it’s pretty common among i18n libraries. I have to decide on the structure to start with, and after that, changing that structure (say if you decide you didn’t make the right decision about how to structure it originally) is going to break a lot of things.
Poking around I stumbled on a library that takes a different approach: Lingui.
Lingui is interesting because it builds a nice translation workflow by leveraging the now ubiquitous infrastructure of Babel.
Aside from the core code in lingui-i18n (and other packages dealing with React) the heart of lingui’s approach are two babel plugins: babel-plugin-lingui-extract-messages and babel-plugin-lingui-transform-js.
We can install what we need for the server side like this.
yarn add lingui-cli lingui-i18n
The babel-plugin-lingui-extract-messages plugin does what is advertised on the tin. First we need a little test code to extract.
const { i18n } = require('lingui-i18n')
i18n.t`I do like a bit of gorgonzola.`
i18n.t`Not even Wensleydale?`
Then we need to create some locales using the helper supplied by lingui-cli:
[mike@longshot lingui]$ lingui add-locale en fr Added locale en. Added locale fr. (use "lingui extract" to extract messages) [mike@longshot lingui]$ tree . ├── index.js ├── locale │ ├── en │ │ └── messages.json │ └── fr │ └── messages.json ├── package.json └── yarn.lock
Next we use babel-plugin-lingui-extract-messages via the Lingui CLI commandlingui extract to scan our code for those internationalized strings and extract them into translation files.
[mike@longshot lingui]$ lingui extract Extracting messages from source files… Collecting all messages… Writing message catalogues… Messages extracted! Catalog statistics: ┌──────────┬─────────────┬─────────┐ │ Language │ Total count │ Missing │ ├──────────┼─────────────┼─────────┤ │ en │ 2 │ 2 │ │ fr │ 2 │ 2 │ └──────────┴─────────────┴─────────┘ (use "lingui add-locale <language>" to add more locales) (use "lingui extract" to update catalogs with new messages) (use "lingui compile" to compile catalogs for production)
Lingui prints out a nice summary of the state of my translations.
A look at the translation files shows how Lingui can solve that coupling problem; it generates an object with the content of the strings used as the keys. This way my translations are looked up by content, rather than via their location in some stucture. Since Lingui defaults to showing the message id (which is actually the English content string from the source) we’ll just edit the French messages file.
[mike@longshot lingui]$ cat locale/fr/messages.json
{
"I do like a bit of gorgonzola.": {
"translation": "Je aime un peu de gorgonzola.",
"origin": [
[
"index.js",
3
]
]
},
"Not even Wensleydale?": {
"translation": "Pas même Wensleydale?",
"origin": [
[
"index.js",
4
]
]
}
}
With that done we need to compile the json into JS files for use with lingui compile. The missing piece now is the how those i18n.t tagged template literals are going to produce our translated strings at runtime, and the answer is babel-plugin-lingui-transform-js.
Since a picture is worth a thousand words, I think the best way to explain it is this:
[mike@longshot lingui]$ cat index.js | babel --plugins lingui-transform-js
const { i18n } = require('lingui-i18n');
i18n._('I do like a bit of gorgonzola.');
i18n._('Not even Wensleydale?');
As you can see, all the calls to i18n.t`` are replaced with calls to i18n._(). This is underscore function is the low level api that Lingui uses to actually give you the translated strings.
Now that we know that, let’s take a look at what using the library looks like.
[mike@longshot lingui]$ node
> var { i18n, unpackCatalog } = require('lingui-i18n')
undefined
> i18n.load({fr: unpackCatalog(require('./locale/fr/messages.js')), en: unpackCatalog(require('./locale/en/messages.js'))})
undefined
> i18n.availableLanguages
[ 'fr', 'en' ]>
> i18n.activate('en')
undefined
> i18n._('I do like a bit of gorgonzola.')
'I do like a bit of gorgonzola.'
> i18n.activate('fr')
undefined
> i18n._('I do like a bit of gorgonzola.')
'Je aime un peu de gorgonzola.'
Lingui has some more tricks up it’s sleeve like pluralization, but one of the things I’m happiest about is that this approach also solves that “unused messages” problem that I mentioned.
If we delete our “Not even Wensleydale?” message and run lingui extract again we can see the benefits of this static analysis style approach: Lingui knows when there is nothing referencing a message, and marks it as obsolete.
[mike@longshot lingui]$ cat locale/fr/messages.json
{
"I do like a bit of gorgonzola.": {
"translation": "Je aime un peu de gorgonzola.",
"origin": [
[
"index.js",
3
]
]
},
"Not even Wensleydale?": {
"translation": "Pas même Wensleydale?",
"origin": [
[
"index.js",
4
]
],
"obsolete": true
}
}
Better still, Lingui will clean out the obsolete messages for you with lingui extract --clean.
[mike@longshot lingui]$ lingui extract --clean
Extracting messages from source files…
Collecting all messages…
Writing message catalogues…
Messages extracted!
Catalog statistics:
┌──────────┬─────────────┬─────────┐
│ Language │ Total count │ Missing │
├──────────┼─────────────┼─────────┤
│ en │ 1 │ 1 │
│ fr │ 1 │ 0 │
└──────────┴─────────────┴─────────┘
(use "lingui add-locale <language>" to add more locales)
(use "lingui extract" to update catalogs with new messages)
(use "lingui compile" to compile catalogs for production)
[mike@longshot lingui]$ cat locale/fr/messages.json
{
"I do like a bit of gorgonzola.": {
"translation": "Je aime un peu de gorgonzola.",
"origin": [
[
"index.js",
3
]
]
}
}
For me this is pretty much the holy grail for i18n. Here I’ve focused on using Lingui without any other libraries, but it’s just as awesome with React. With locale files that can be plausibly handed over to a translator, and tooling that both find and remove translations Lingui has become my goto i18n library.
mike.williamson 
Is it only for study projects at school?
With real life projects when using original strings as keys you can’t change a single character in them without ruining all other translations (the key won’t be found).
It’s very bad decision to use original strings for keys.