Used by teams at
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.
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.
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 that the project loads:
npx @inlang/cli validate --project ./project.inlangAn optional automation can create draft translations with a configured provider:
npx @inlang/cli machine translate --project ./project.inlangThe resulting translation files can be committed and reviewed in a pull request. validate checks project setup; it does not check translation completeness or placeholder quality. Generated translations need review before shipping. See the CLI documentation for provider setup.
Found a problem or have an idea? Open an issue. To contribute code, see the contributing guide.