Skip to content

Instantly share code, notes, and snippets.

@liy
Last active March 10, 2020 16:10
Show Gist options
  • Save liy/5db1d5dbf98b7dcefc6f38b23b0217a2 to your computer and use it in GitHub Desktop.
Save liy/5db1d5dbf98b7dcefc6f38b23b0217a2 to your computer and use it in GitHub Desktop.
Translation architecture desision record

1. Translation Framework

Date: 10/03/2020

Status

proposed

Context

The new basket needs a framework to handle localisation in UK and Gemernay. Preferrably it should have these features:

  1. Ease to use key value API for daily use.
  2. Dynamically loading locale resources.
  3. Nurmeral, pluralize formating.

Decisions

i18next + react-i18next is the preferred approach.

Several libaries has been tested and reviewed:

  • i18next: mini 38.kb + react-i18next: mini 16.5 kb
  • react-intl: mini 48.3kb
  • intl-messageformat: mini 30.4kb
  • @lingui/core: mini 4.3kb
  • @lingui/react: mini 7.4kb
  • eo-locale: mini 1.7kb

i18next and react-i18next

Slightly bigger than react-intl. Its namespace functionality will be very useful if component is using context API and shared across different places.

API is very clean and simple.

It has plugin system which could come in handy for loading the RESX file.

react-intl

It is used in responsive checkout but it is quite hard to work with and documentation is difficult to navigate around. In older version we have difficulty to translate element attributes, because internal API is not exposed.

intl-messageformat

It is part of react-intl. It only handles message formatting, extra resource managing code needs to be introduced.

lingui

The compile time t() function is not ideal, as we need to lazy load locale data. Dynamic loading is quite complex

Personally I don't like the "i18n._(t `Image caption`)" API style.

eo-locale

It is not popular enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment