What is lingosync?
Most i18n setups start the same way: one en.json, then someone adds es.json by hand, then fr.json, and within a few months keeping every locale file's keys in sync becomes its own part-time job. Every new feature means remembering to add the same key to every language file, or your app crashes trying to render a missing translation — or worse, silently shows the raw key to a user.
lingosync flips that around. You maintain one master file — the source-of-truth language, usually English — and declare which locales you want in your package.json. Running lingosync sync:
- Translates any key that's new or changed in the master, for every configured locale, using a translation provider of your choice.
- Removes any key that was deleted from the master, everywhere.
- Leaves everything else untouched — including translations you or a teammate already wrote by hand, and anything you've explicitly pinned with an override.
It's not a translation management platform, it doesn't require an account, and it doesn't store your content anywhere but your own repository. It's a small CLI that does one job: keep your locale files' keys in sync. What each key says in each language is still up to you — lingosync just makes sure nothing is missing or stale.
Why not just use <X>?
Full-blown translation management platforms (Lokalise, Crowdin, Phrase, and similar) are the right call for larger teams juggling translator workflows, review pipelines, and non-technical stakeholders editing copy. If that's you, use one of those.
lingosync is for the much more common case: a small-to-mid-sized team that just wants their locale files to stop drifting apart, without signing up for another SaaS product or handing translation content to a third-party platform. It's a dependency, not a service.
Next steps
Head to Getting Started to add lingosync to your project.