Open format TMS (translation management system)
See the codeKeep 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 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.
Found a problem or have an idea? Open an issue. To contribute code, see the contributing guide.
(top 24 of 30)
3,743 followers · starred Jun 2025
106 followers · starred Dec 2025
259 followers · starred Oct 2021
445 followers · starred Jul 2024
Open format TMS (translation management system)
See the codeKeep 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 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.
Found a problem or have an idea? Open an issue. To contribute code, see the contributing guide.
(top 24 of 30)
3,743 followers · starred Jun 2025
106 followers · starred Dec 2025
259 followers · starred Oct 2021
445 followers · starred Jul 2024