Keep translation files in your Git repo. Inlang gives editors, agents, and automation a shared localization model, so they can work with those files without making a hosted TMS the source of truth.
One project, many tools
Fink · Sherlock · CLI · Paraglide · your own tool
│
inlang SDK
│
.inlang project
│
plugins
│
translation files in Git
An inlang project describes messages, variants, locales, and settings. Plugins connect that model to the files your app uses, including JSON and i18next resources. Tools can use the SDK instead of each building its own parser and project model.
That gives tool builders a common format to work with. You can use an editor, add an automation, or build your own tool around the same localization model.
Use your Git workflow
my-app/
├── src/
├── messages/
│ ├── en.json
│ └── de.json
└── project.inlang/
└── settings.json
In this setup, Git tracks the translation files and project settings. A configured plugin reads and writes the message files. Localization changes can follow the same path as code changes:
Change source text → update translations → run CI → review the pull request → ship
For example, CI can check the translations:
npx @inlang/cli check --project ./project.inlang
An optional automation can create draft translations with a configured provider:
npx @inlang/cli machine translate --project ./project.inlang
The resulting translation files can be committed and reviewed in a pull request. check reports project errors, missing translations, missing or unknown variables and, for Paraglide projects, unused messages; it does not judge translation quality. Generated translations need review before shipping. See the CLI documentation for provider setup.
Get started
Contributing
Found a problem or have an idea? Open an issue. To contribute code, see the contributing guide.
