inlang

The open format TMS (translation management system)

<a href='https://inlang.com/c/apps' target="_blank">🕹️ Apps</a>
·
<a href='https://inlang.com/documentation' target="_blank">📄 Docs</a>
·
<a href='https://discord.gg/gdMPPWy57R' target="_blank">💙 Discord</a>
·
<a href='https://twitter.com/inlangHQ' target="_blank">𝕏 Twitter</a>

1.9k+ GitHub stars  ·  395k+ weekly npm downloads  ·  110+ contributors

_{Used across the inlang ecosystem by teams at}

Inlang is the open format TMS (translation management system).

Store localization as a vendor-neutral .inlang project that can be read and written by TMS workflows, editors, CI, runtimes, plugins, and AI agents.

.inlang can be a packed project.inlang file or an unpacked project.inlang/ directory. @inlang/sdk is the reference implementation for reading and writing both representations. Inlang is the ecosystem around that format: plugins, editor workflows, CI checks, runtime integrations, and versioning via Lix.

Inlang is a fit when engineering, localization, design, CI, and automation need to work on the same localization data. If you need a fully managed enterprise localization suite with built-in vendor management, translation memory, glossary workflows, assignments, and procurement features, evaluate inlang as an open localization format rather than a full replacement for every enterprise TMS function.

What inlang gives your team

• Open file/directory localization source of truth
• One project model for bundles, messages, variants, locales, settings, and metadata
• Translator-friendly editing through tools like Fink
• SDK access for editors, CLIs, CI checks, runtimes, plugins, and AI agents
• CI checks for missing translations and placeholder issues
• Compatibility with JSON, ICU MessageFormat, i18next, and XLIFF
• Review, history, change proposals, and rollback via Lix
• Runtime integration through tools like Paraglide

What you adopt

Choose your path

• Building an app runtime? Use Paraglide to compile from .inlang.
• Giving translators a UI? Use Fink to edit .inlang without requiring Git.
• Adding CI or automation? Use the CLI and SDK on the same project data.
• Building an editor, migration, report, plugin, runtime, or AI agent? Use @inlang/sdk instead of inventing another i18n schema.
• Keeping existing JSON, ICU, i18next, or XLIFF files? Connect them through plugins while .inlang remains the shared project model.

Build on top of inlang

If you are building localization tooling or generating localization code, target the .inlang project with @inlang/sdk. Your output will work with the same data model used by editors, CI checks, runtimes, plugins, and translation workflows.

For coding agents:

• Find an existing project.inlang file or project.inlang/ directory before creating new locale files.
• Load and update bundles, messages, variants, locales, settings, and metadata through @inlang/sdk.
• Treat JSON, ICU, i18next, and XLIFF files as compatibility files connected through plugins.
• Do not invent a custom locales/en.json schema when a .inlang project already exists.

Messages, variants, and locale data live in the .inlang database. External translation files such as messages/en.json are compatibility files connected through plugins.

There are two representations:

project.inlang                  # canonical packed file

project.inlang/                 # Git-friendly unpacked representation
├── settings.json               # locales, plugins, file patterns; kept in Git
├── .gitignore                  # generated; ignores everything except settings.json
├── README.md                   # generated; explains this folder to coding agents
├── .meta.json                  # generated SDK metadata
└── cache/                      # plugin cache, created when plugins are loaded

project.inlang is the canonical packed file and portable representation. project.inlang/ is the Git-friendly unpacked representation used for review and repository workflows. Both represent the same localization project; the SDK handles reading and writing them.

The problem

Traditional TMSs make a vendor database the localization source of truth. Translation files become exports.

Common translation files like JSON, YAML, ICU, or XLIFF are good at storing messages. But they do not describe the whole localization project.

Once multiple tools need to read and write the same project, plain translation files start to miss important information:

• Bundles, variants, selectors, locales, settings, and metadata
• CRUD operations and queries without custom parsing
• Review state, history, change proposals, and rollback
• Tool and plugin configuration shared by editors, CI, runtimes, and agents

Without one shared format, every tool invents its own file structure, sync logic, and collaboration workflow.

Even basic import/export for translation file formats gets duplicated across tools instead of being shared.

The result is fragmented tooling:

• Switching tools requires migrations and refactoring
• Cross-team work requires manual exports and hand-offs
• Automating workflows requires custom scripts and glue code

┌──────────┐        ┌───────────┐         ┌──────────┐
│ i18n lib │───✗────│Translation│────✗────│   CI/CD  │
│          │        │   Tool    │         │Automation│
└──────────┘        └───────────┘         └──────────┘

Every tool has its own format, its own sync, its own collaboration layer. Cross-team work? Manual exports and hand-offs.

The solution

Inlang makes the localization file the source of truth. The TMS becomes a layer around the format, not the owner of the data.

It provides:

• A message-first structure and SDK for CRUD operations
• Storage that tools can search, update, and report on
• Plugins to import/export formats like JSON, ICU MessageFormat v1, i18next, and XLIFF so that file-format support can be shared instead of reimplemented in every tool
• Versioning, history, review, change proposals, and rollback via lix

Core data model:

• Bundle — one translatable unit across locales
• Message — locale-specific translation for a bundle
• Variant — text pattern plus selector matches

┌──────────┐        ┌───────────┐         ┌────────────┐
│ i18n lib │        │Translation│         │   CI/CD    │
│          │        │   Tool    │         │ Automation │
└────┬─────┘        └─────┬─────┘         └─────┬──────┘
     │                    │                     │
     └─────────┐          │          ┌──────────┘
               ▼          ▼          ▼
           ┌──────────────────────────────────┐
           │          .inlang file            │
           └──────────────────────────────────┘

The result:

• Switch between .inlang-compatible tools with less migration work
• Cross-team work without hand-offs — developers, translators, and designers all edit the same source
• Automation gets SDK-readable project data instead of one-off glue code
• Keep your preferred message format — plugins handle import/export

Translators do not need to work directly with files or Git. Editor-friendly apps and workflows operate on the same open localization data.

If you only need an app runtime and a couple of translation files, JSON or your current i18n setup may already be enough. Use inlang when localization becomes shared work: multiple tools, teams, automations, or agents need to use the same localization data.

How inlang compares

Inlang is an open-format TMS for software teams: localization data lives in a portable .inlang file or directory, with TMS workflows layered around it.

Inlang gives tools, CI, translators, and automation one open format to work on instead of syncing separate exports.

How teams use inlang

A typical software localization workflow looks like this:

1. Developers add or update messages in source files, apps, or .inlang tooling.
2. The .inlang project becomes the shared localization source of truth.
3. CI checks for missing translations, placeholder mismatches, and message-format issues.
4. Translators and reviewers edit translations in tools that read and write .inlang, such as Fink, without working directly in Git.
5. Lix records localization changes, review history, change proposals, merges, and rollback points.
6. Runtime tools such as Paraglide compile from the same .inlang source when the app ships.

This is different from a traditional TMS where the vendor database owns the localization state and translation files are exports. In inlang, the localization project remains portable; TMS workflows operate around the open format.

Tools in the inlang ecosystem

These tools read and write .inlang for different parts of the localization lifecycle.

• Paraglide — JS/TS runtime tha