Inlang

Localization infrastructure, honestly reviewed. Not a translation SaaS — something more fundamental, and more niche.

TL;DR

• What it is: An open project format and SDK for localization tooling — not a translation platform, not a new message syntax, but a shared file-based substrate that lets your IDE extension, CLI, translation editor, and i18n runtime all read the same source of truth without glue code [README].
• Who it’s for: JavaScript/TypeScript developers building multilingual apps who are tired of every i18n tool inventing its own sync format. Non-technical founders looking for a Crowdin alternative should look elsewhere — this is developer infrastructure [README][1].
• Cost savings: The open-source layer is free. The comparison isn’t Inlang vs. Lokalise on a monthly bill; it’s Inlang vs. the hours you spend writing glue scripts between your translation editor, your CI pipeline, and your i18n runtime [README].
• Key strength: A coherent ecosystem — Paraglide (typesafe i18n library), Fink (browser-based translation editor), Sherlock (VS Code extension), and a CLI — all built on the same .inlang file, so switching one tool doesn’t require migrating data from another [README].
• Key weakness: 1,834 GitHub stars as of this review. This is a small project. The ecosystem is young, the community is small, and the “open format” bet only pays off if toolmakers adopt it — which hasn’t happened at scale yet [merged profile][2].

---

What is Inlang

Inlang is best understood as an attempt to do for localization what SQLite did for embedded databases: define a small, portable, queryable format that every tool can speak natively instead of everyone rolling their own.

The problem it addresses is real. A typical web app with i18n requirements touches several systems: an i18n runtime library (i18next, next-intl, svelte-i18n), a translation editor where non-developer collaborators can add strings, a VS Code extension for in-editor previews, and a CI lint step that catches missing translations before they ship. In the current world, these tools don’t share data. The editor exports a JSON file, a developer commits it, the CI parses it with a custom script, and the runtime consumes it with its own loader. Every handoff is a potential failure point and a maintenance burden.

Inlang’s answer is the .inlang project file — a shared, queryable store with database semantics (structured reads/writes, queries across locales and variants, versioning, merging) that each tool reads directly instead of maintaining its own format [README]. Plugins handle import/export to and from your actual file formats (JSON, ICU MessageFormat v1, i18next, XLIFF), so you don’t have to abandon your existing translation files [README].

The repository lives at https://github.com/opral/inlang (it migrated from inlang/inlang to opral/inlang). The project describes itself as “not a new message syntax or a SaaS translation backend” [README] — which is accurate and worth taking seriously. If you came looking for a Crowdin or Lokalise replacement with a translation UI, that’s only one piece of what’s here (Fink), and it’s not the main pitch.

---

Why people choose it

The third-party coverage available for Inlang is thin — the sources indexed for this review are directory listings (Awesome Translations, Gitroom) rather than detailed user reviews [1][2][3]. That absence is itself a signal: this is not a project with a loud evangelism community. The case for Inlang has to come primarily from its own README and design rationale, which is worth reading carefully because it is unusually honest about scope.

The argument Inlang makes is structural. It draws this diagram:

WITHOUT INLANG:
i18n lib ──✗── Translation Tool ──✗── CI/CD Automation

WITH INLANG:
i18n lib ──┐
           ├──→ .inlang file ←──┤
CI/CD   ──┘                    Translation Tool

If you’ve maintained a multilingual codebase with more than two tools touching the translation layer, this diagram will resonate. The real cost of the current state isn’t the per-seat price of Crowdin — it’s the afternoon spent writing a script to convert your translation memory export into the format your CI linter understands, and then the morning spent debugging why a new translator’s additions didn’t make it into the next build [README].

Inlang also shows up in the Awesome Translations curated list [1] specifically for its approach to this coordination problem, listed alongside Weblate, Tolgee, and Crowdin — but positioned as infrastructure rather than a standalone platform.

The Gitroom repository index [2] tags it under “collaboration” with i18n, localization, vscode, localisation — which is accurate. The VS Code extension (Sherlock) is one of the more concrete near-term value propositions: it lets developers see translation previews inline while writing code, without switching to a separate tool [README].

---

Features

The format and SDK:

• .inlang project file as a shared, queryable source of truth for all tooling [README]
• Message-first data model with structured CRUD, cross-locale queries, metadata, and variant support [README]
• Versioning and collaboration primitives via lix, a separate project from the same org [README]
• Plugin system for import/export: JSON, ICU MessageFormat v1, i18next, XLIFF [README]
• TypeScript SDK (@inlang/sdk) — loadProjectFromDirectory, queryable via SQL-style builder [README]

The tool ecosystem (all using the same .inlang file):

• Paraglide — i18n library for JS/TS: fully translated, typesafe, reportedly fast setup [README]
• Fink — browser-based translation editor with collaborator invites; positioned as the “non-developer” interface [README][1]
• Sherlock — VS Code extension to translate directly in your editor [README]
• Parrot — Figma plugin to see translations in design files [README]
• CLI — lint messages, machine translate, run quality checks in CI/CD [README]

What you can build yourself:

• The SDK is public. You can load an inlang project, query all messages in a locale, filter by missing translations, and pipe them wherever you want — the README ships a working three-liner [README]

What’s not here:

• No built-in machine translation service (the CLI can invoke one, but you configure the provider)
• No hosted backend — this is a file format, not a cloud service
• No translation memory, TM matching, or glossary features documented in available sources

---

Pricing: SaaS vs self-hosted math

This section looks different from a typical SaaS comparison because Inlang is not a SaaS product and doesn’t have pricing tiers. The format and SDK are open source. The apps (Paraglide, Fink, Sherlock, CLI) are free to use.

Pricing data for Inlang’s managed offerings is not available in any of the reviewed sources — the project does not appear to have a commercial tier as of this writing.

The relevant cost comparison is against the tools you’d replace or augment:

Tool	Type	Pricing
Crowdin	SaaS translation platform	From $50/mo, per-seat
Lokalise	SaaS translation platform	From $120/mo
Weblate	Open-source, self-hostable	$0 self-hosted, $90/mo hosted
Tolgee	Open-source, self-hostable	$0 self-hosted, free tier hosted
Inlang (format + SDK)	Open-source	$0

The realistic comparison: if you’re already paying $50–$120/mo for a translation platform and spending engineering hours maintaining sync scripts between it and your CI/code tools, Inlang is an argument for replacing those sync scripts with a shared format. It doesn’t directly replace the translation platform — Fink is the translation editor in this stack, but it’s far less mature than Crowdin or Lokalise.

If you’re a solo developer or small team using free-tier tools and writing manual JSON files, Inlang’s overhead may not pay for itself yet. If you’re a mid-size engineering team with multiple people touching i18n, the coordination cost savings are real but require buying into the full ecosystem.

---

Deployment reality check

Inlang has no server to deploy. The .inlang format is a local file in your repository. You install the CLI, add a project file, configure plugins for your existing message format, and the rest of the tooling reads from there.

What you actually set up:

1. Add a project.inlang file to your repo (a few lines of config)
2. Install the CLI: npx @inlang/cli@latest
3. Configure a plugin for your message format (JSON, i18next, etc.)
4. Optionally: install the VS Code extension (Sherlock) for in-editor previews
5. Optionally: open Fink at inlang.com and point it at your repo for the browser editor

There’s no Docker Compose, no VPS, no database server. The “deployment” is committing a config file.

What can go sideways:

• The ecosystem is young. Plugin quality varies. If your message format has edge cases not covered by the existing plugins, you may be writing a plugin or filing issues.
• Lix (the versioning layer) is a separate project still in development. The collaboration primitives are partly a roadmap promise, not a fully shipped feature.
• With 1,834 stars and no visible enterprise adoption in the reviewed sources, you are an early adopter. Support is Discord-based [README].
• The VS Code extension, Figma plugin, and browser editor each have their own maturity curve — using all of them together as an integrated workflow hasn’t been validated by many teams publicly.

For a developer already comfortable with TypeScript and config files, setup is probably under an hour. For a team trying to onboard non-technical translators to Fink, the experience depends on how polished Fink’s onboarding is — which isn’t addressed in available sources.

---

Pros and Cons

Pros

• Solves a real structural problem. The fragmentation of i18n tooling is genuine, and the “shared project file” framing is technically sound. You don’t have to convince yourself the problem is real [README].
• Non-destructive adoption. You keep your existing translation files and message format. Plugins handle import/export. No migration required upfront [README].
• Paraglide is the strongest individual piece. A typesafe i18n library that generates per-language bundles at build time is a legitimately good idea, and several sources list it as a reason to look at the ecosystem [1][README].
• SDK is queryable and programmable. project.db.selectFrom("message") is a sane API. If you want to build your own tooling on top, the surface is clean [README].
• Everything is free. No per-seat pricing, no task limits, no commercial tier gating core functionality [merged profile].
• Figma integration is a differentiator. Seeing translations in design files (Parrot) is a workflow gap most platforms don’t close without custom integrations [README].

Cons

• Very small community. 1,834 stars is modest for a project pitching itself as infrastructure. Compare: Weblate has 4,500+, Tolgee has 2,000+. Fewer stars isn’t disqualifying, but it means fewer plugins, fewer forum answers, and fewer people who’ve hit your specific edge case before you [merged profile][2].
• The “open format” bet is unproven at scale. The value multiplies when third-party i18n libraries, editors, and CI tools build native inlang support. That hasn’t happened yet to any visible degree in the reviewed sources.
• Fink is not a Crowdin replacement today. If you need translation memory, TM matching, translator CAT features, glossary enforcement, or translator workflow management, Fink doesn’t cover that ground based on available documentation.
• No pricing transparency. It’s unclear whether any commercial layer exists or is planned. Open source infrastructure projects eventually need a business model — not knowing what that looks like is a risk if you’re building critical tooling on top.
• License not specified in available data. The merged profile shows an empty license field, which is unusual for a project positioning itself as open infrastructure. This needs verification before production adoption [merged profile].
• Lix versioning is an in-progress dependency. The collaboration and merging promises depend on a separate project that’s still being built [README].

---

Who should use this / who shouldn’t

Use Inlang if:

• You’re a JS/TS developer building an app that needs i18n and you want a typesafe, well-structured approach from day one (start with Paraglide).
• You maintain a multilingual codebase where multiple tools (editor, CI, runtime) all touch translation files and you’re maintaining sync scripts between them.
• You want to contribute to or build tooling in the localization space — the SDK gives you a clean API and you don’t have to reinvent format parsing.
• You’re comfortable being an early adopter on non-critical infrastructure and are willing to file issues when you hit gaps.

Skip it (use Weblate or Tolgee instead) if:

• You need a self-hosted translation platform with a mature translator-facing UI, translation memory, and CAT features. Both Weblate and Tolgee are further along here.
• You want an active community with documented solutions to common deployment problems.

Skip it (use Crowdin or Lokalise) if:

• You need a professional translation workflow with agency integrations, translator assignment, per-word billing, and enterprise SLA. Inlang doesn’t compete here.

Skip it entirely if:

• You are a non-technical founder. This is developer infrastructure. The tools in the Inlang ecosystem don’t have the onboarding, documentation, or support model for non-technical users managing a translation budget.

---

Alternatives worth considering

• Weblate — open source (AGPL), self-hostable, 4,500+ stars, far more mature translator-facing UI, well-documented deployment. The go-to if you want a free Crowdin replacement you can run yourself [1].
• Tolgee — open source, self-hostable, developer-friendly with in-context translation (click a string in your app to edit it). Closer to Inlang’s developer-first pitch but with a hosted option and more complete translator features [1].
• i18next + Locize — i18next is the dominant JS i18n library; Locize is the paid SaaS backend made by the same team. If you’re already on i18next and want managed hosting without self-hosting, this is the path of least resistance.
• Crowdin — closed source SaaS, $50/mo+, the professional market leader. Relevant if you have a dedicated localization team and need TM, glossary, agency integrations.
• Lokalise — closed source SaaS, $120/mo+, strong developer API and CI integrations. Worth it for larger teams with active translation pipelines.
• LRM — self-hosted CLI/TUI localization manager, free, recently added to Awesome Translations. Relevant if you want something minimal and scriptable with no web UI [1][3].

The honest shortlist for a developer-first team choosing open source: Tolgee vs. Weblate vs. Inlang. Tolgee if you want in-context translation and are building a web app. Weblate if you need the most complete translator workflow. Inlang if you believe in the “common format as substrate” architecture and want to build on it early.

---

Bottom line

Inlang is a technically coherent answer to a real problem — the fragmentation of localization tooling. If you’ve spent time writing glue scripts between your JSON files, your CI lint step, and your translation editor, the pitch lands. The .inlang shared project format, the clean TypeScript SDK, and the Paraglide i18n library are solid pieces of infrastructure. The honest limitation is that the value scales with ecosystem adoption, and that adoption is still early. With 1,834 stars, an unspecified license, and third-party reviews that amount to directory listings rather than detailed user reports, this is a project to watch closely — and to adopt cautiously if your i18n setup is anything more than a side project. For non-technical founders, it’s the wrong tool entirely. For a JS/TS team that wants to get localization architecture right from the start, Paraglide alone is worth a look.

---

Sources

1. Awesome Translations (mbiesiad/awesome-translations) — Curated list of i18n/l10n tools; lists Inlang as “The globalization ecosystem for software companies” and Fink as a translation editor. https://mbiesiad.github.io/awesome-translations/
2. Gitroom / GitLibrary.club — Repository list — Directory listing categorizing inlang under TypeScript, i18n, localization, vscode. https://gitlibrary.club/collaboration/1
3. Track Awesome List — mbiesiad/awesome-translations weekly — Tracks Inlang and ParaglideJS added to Awesome Translations in January 2024. https://www.trackawesomelist.com/mbiesiad/awesome-translations/week/

Primary sources:

• GitHub repository and README: https://github.com/opral/inlang (1,834 stars)
• Official documentation: https://inlang.com/documentation
• Apps directory: https://inlang.com/c/apps
• Paraglide: https://inlang.com/m/gerre34r/library-inlang-paraglideJs
• Fink: https://inlang.com/m/tdozzpar/app-inlang-finkLocalizationEditor
• Sherlock (VS Code): https://inlang.com/m/r7kp499g/app-inlang-ideExtension
• CLI: https://inlang.com/m/2qj2w8pu/app-inlang-cli