Localise all textual elements and values

This changeset localises all textual elements as well as the format of dynamic values.

Many dynamic values (dates especially) were not properly formatted, even in the original French language.

It also:

Modifies the header description (which hardcoded French elements).
Adds the ability to override textual elements in configuration, which allow to localise each instance very precisely while still supporting shared i18n strings.
Adds another example configuration for Aotearoa New Zealand (even though I intend to modify the config loading mechanism altogether in a future pull request).
Sets English as the default language for missing strings.
Fixes the document title change mechanism.
Does small-scale refactors. I tried to keep refactoring as low as possible, and extracted as many as I could in a future separate PR to ease review, but some parts of the code were too hard to work on without an initial cleanup pass.

It is worth noting that:

All the UI changes have been validated with users.
All the English translations have been checked with native English speakers.
I am not expecting feedback on phrasings: this is about localising, not about copywriting. The only possible exception could be the header, with strong evidence.
There is a lot of room for improvement and refactoring the whole code. Even refactors made in this PR are partial.

Screenshots for main changes

Header

Before

screen shot 2018-05-20 at 16 04 58

After — `fr-FR`

screen shot 2018-05-20 at 16 10 52

After — `en-US`

screen shot 2018-05-20 at 16 11 13

Parameter view

Before

screen shot 2018-05-20 at 15 48 31

After — `fr-FR`

screen shot 2018-05-20 at 15 48 43

After — `en-US`

screen shot 2018-05-20 at 15 48 36

Scale view

Before

screen shot 2018-05-20 at 14 48 34

After — `fr-FR`

screen shot 2018-05-20 at 15 04 57

After — `en-US`

screen shot 2018-05-20 at 15 05 06

Fix #146.

Glad to see this app once limited to France going global 🙂

I'm rusty on this codebase, but the change seem sensible to me, and the result is definitely an improvement (tested with a French and English browser.)

One limitation of this configuration system is that we can't work in development mode with any country other that the country template. That is not per se a regression, as before this used to be possible only for OpenFisca France, but I hope we can improve that in the future.

Consequently, the command npm run dev:prod-api doesn't make much sense anymore, as it uses the France web API but country template config elements. I removed it.

we can't work in development mode with any country other that the country template

Oh, we can! This is how I run in dev with actual data: API_URL='https://fr.openfisca.org/api/v21' npm run dev 🙂

I agree that npm run dev:prod-api was bad though, but there is a bigger piece of work that's needed for the config loading mechanism to be internationalised.

Oh, we can! This is how I run in dev with actual data: API_URL='https://fr.openfisca.org/api/v21' npm run dev 🙂

Not entirely, as openfisca/country-template and the development environment will still be used from the config

openfisca / legislation-explorer