inlang
Open format and ecosystem that makes software localization a portable, repo-owned file instead of a vendor database.
About
inlang is an open-source localization ecosystem built around a simple idea: localization data should live in your repository as a vendor-neutral project, not inside a translation vendor's database. The .inlang format stores messages, locales, variants, and settings, and the @inlang/sdk gives editors, CLIs, CI checks, and AI agents one read/write API over it. Plugins bridge existing formats like JSON, ICU MessageFormat, i18next, and XLIFF, so teams can adopt it without rewriting their catalogs.
Around the format sits a practical toolchain: Fink, a translation editor for non-developers who never want to touch Git; Sherlock, a VS Code extension for inline translation editing; Paraglide, a compiler-based i18n runtime that ships tree-shakeable, fully typed messages; and Lix, which adds review, history, change proposals, and rollback. CI checks catch missing translations and placeholder mismatches. It is a good fit for engineering-led teams that want localization in version control; teams needing built-in vendor management and procurement should evaluate it as an open format rather than a full enterprise TMS replacement.
What it can do
- Open .inlang project format as the shared localization source of truth
- @inlang/sdk read/write API for editors, CLIs, CI, and AI agents
- Plugins for JSON, ICU MessageFormat, i18next, and XLIFF
- Fink translation editor and Sherlock VS Code extension
- Paraglide compiler-based i18n runtime (tree-shakeable, typed)
- Lix versioning: review, history, change proposals, rollback
Setup
- Install the inlang CLI and initialize a project.inlang in your repo.
- Point the format plugin at your existing JSON, i18next, or XLIFF files.
- Add Paraglide or your runtime of choice to compile messages at build time.
- Give translators Fink access and add CI checks for missing translations.
Prerequisites
Use cases
Works with
Trust score — 8/10
Scored 8/10 (TIER verified, metrics-v1). Evidence: active open-source repo github.com/opral/inlang (renamed from inlang/monorepo, 2,005 GitHub stars, pushed Oct 2026) with real adoption documented in production repos (e.g. open-source projects migrating from i18next), an ecosystem of maintained companion tools (Paraglide, Fink, Sherlock), and clear architecture docs. Strengths: genuinely open format, strong developer ergonomics, no vendor lock-in, CI-friendly. Docked for: (1) smaller community than i18next/Weblate, so long-term maintenance depends on the core team; (2) positioned as an open format, not a full enterprise TMS, which limits its scope. License: open source (check the monorepo for the current license).
★ 2,005 GitHub stars
How the trust score is built
Full methodology →- Adoption · stars/downloads, log-scaled vs peers
- 7.0/10
- Maintenance · recency, releases, issue load
- 8.0/10
- Openness · license + docs
- 10.0/10
- Manual review · sanity read + red-flag check
- 7.0/10
- · Active open-source repo github.com/opral/inlang (renamed from inlang/monorepo); 2,005 GitHub stars, pushed Oct 2026; production adoption documented in OSS projects.
- · Companion tools maintained: Paraglide, Fink, Sherlock, Lix, CLI.
- · Smaller community than i18next/Weblate; maintenance rests on core team.
- · Positioned as an open format, not a full enterprise TMS.
Sources
Every fact above was checked against these sources. Where a claim comes from the provider and couldn't be independently verified, the text says so.