Application Workflow
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.
Project Structure​
A minimal i18n-friendly project can have the following structure:
projectRoot
|-- src
| |-- App.js
|-- lang
| |-- en-US.json
| |-- fr.json
|-- package.json
|-- .eslintrc.js
where 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.
Pipeline​
A generic translation pipeline looks something like this:
- Extraction: This step aggregates all
defaultMessage
s from your application into a single JSON file along withdescription
, 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
- Bundler plugin for compiling TypeScript/JavaScript