i18n-fetcher application icon

i18n-fetcher

АКТИВНО

i18n-fetcher moves translations between a database and JSON files, in either direction, so a CI/CD pipeline can pull the latest copy for a build, or push updated translation files back where they came from.

What it actually does

One config file describes the DB source, the target table/columns, and the destination files. Secrets (DB host, user, password) can live in the config directly or in a separate .env file, kept out of the config so it's safe to commit. The config's shape is generated straight from its TypeScript type via ts-json-schema-generator, so pointing a config file's $schema at it gets real IDE autocomplete and validation -- including reading the schema straight off the repo's raw URL, no local install needed. Run it the same zero-install way as the rest of the family: npx -p @incrediblez/i18n-fetcher run --env=./.env --config=./config.json

A genuinely clever trick: synthetic languages

Set synthetic_column_name to any language code (the docs use Esperanto, eo, as the example) and the export generates one extra "language" where every value is just its own translation key. Select that language anywhere your app renders translations, and every placeholder shows you exactly which key it is instead of translated text -- which turns out to be the fastest way to debug a missing or mismatched translation key, or to hand a content specialist a way to see structure without guessing.

Going the other direction: import mode

Add --instruction=import and the flow reverses: it reads flat-key LANG.json files, diffs them against the current DB rows, and merges the changes in -- new keys get added, changed values get updated, and a language that's gone missing for a specific key only clears that language's value, not the whole row. Import mode is pickier about file shape than export (flat keys only, one file per language, simply named), which the docs are upfront about rather than pretending it's as flexible as the export side.

Where it stands today

Considerably further along than a fresh project -- v1.3.1, MIT licensed, actively maintained (a translation-handling bugfix landed as recently as this January). The honest caveat, straight from its own docs:

Currently tool supports only MySQL2 as a source. Currently tool supports only one mode, when translations table contains translations in columns [...] as currently we are the only ones who are using the tool -- we scope development to our accute needs.

Further development tracks community requests and their own needs, in that order.