While our Installation guide can help you get started, most production-ready i18n applications require a translation pipeline and workflow. This guide will give you an idea of how to build one.
A minimal i18n-friendly project can have the following structure:
lang folder is where the aggregated strings file from your application would live. Integration with 3rd-party translation vendor can consume the
en-US.json file and produce
fr.json or other locale files accordingly.
A generic translation pipeline looks something like this:
- Extraction: This step aggregates all
defaultMessages from your application into a single JSON file along with
description, ready to be translated.
- Upload Messages: This step uploads the JSON file to your translation vendor.
- Download Translations: This step either polls your translation vendor or hook into your vendor to download translated messages in the set of locales that you configured.
- Commit: This commits back translation messages to the codebase.
Where formatjs comes in
The goal of this project is not to provide a solution for the whole pipeline, but rather focus on Developer Experience via tooling and best practices so devs are i18n-aware. This includes:
- Declaring i18n-friendly messages
- Linter that enforces such messages
- CLI for extraction & compilation
- Polyfills for a stable i18n runtime environments