Localization was stuck in the past. We built l10n to move it forward.

If you've ever shipped software in more than one language, you know the drill. You pick a localization platform, connect it to your repository, and then spend the rest of your time managing the sync. Content goes out, translations come back, and somewhere in between things break.

That overhead, the constant round-trip of content from and to your repository, is the tax every team pays for using today's localization tools. It sounds minor until you're the one debugging why a translation PR broke your site build at 6 PM on a Friday.

A design inherited from before the internet

Most localization platforms were designed around concepts that predate the modern development workflow. Translation memories. Fuzzy matching. Human translators working inside proprietary editors, supported by tools that suggest similar strings from a database.

These ideas made sense when translation was a manual, offline process. But companies turned translation memories into a lock-in mechanism. Your past translations, the institutional knowledge you paid for, live inside their platform. Moving to another provider means starting from scratch, or paying for an export that never quite works.

The result is an industry built on artificial friction. Your content leaves your repo, enters a black box, and returns on someone else's schedule.

The CI problem nobody talks about

At Tuist, we localize our documentation site and our marketing site. We used external localization platforms, and we frequently found ourselves dealing with pull requests opened by those tools that failed our automated checks.

The problem is structural: external localization tools can't run your CI pipeline. They don't know about your linters, your build step, your link checker, your frontmatter schema. They push translated content back to your repo and hope for the best.

This was genuinely frustrating. We'd get a batch of translations, the PR would fail CI, and someone on the team had to stop what they were doing to fix formatting issues, broken syntax, or invalid markup that the translation tool introduced. It took energy away from real work to solve things that shouldn't be problems in the first place.

A conversation that changed everything

The idea for l10n came from thinking and talking with Maria Jose, whose experience in localization was critical in making ideas click. She understood both the linguistic side and the tooling frustrations intimately.

Together, we asked a simple question: what if localization agents could use the same tools developers use?

Not a platform that syncs files back and forth. Not a web editor disconnected from your codebase. Instead, coding agents that have access to your project, your environment, and your validation tools. Agents that can translate a file, run your linter, check the output, and retry if something breaks, all before opening a pull request.

The idea was to bring localization closer to where development happens, eliminating the intermediaries. Just your project, an environment, and a CLI that orchestrates the work.

l10n is our gift to the software industry

We built l10n because we want more software to be localized, not less.

Complicated processes and expensive platforms make localization inaccessible to small teams, indie developers, and open-source projects. If your translation workflow requires a procurement process, a per-word pricing negotiation, and a project manager to coordinate handoffs, most teams will just ship in English and call it a day.

l10n is open source. It uses models you already have access to. It runs in your terminal. And it validates output with your own tools, not ours.

We think localization should be as natural as running your test suite.

What's next: a human input experience

Today, l10n is a CLI tool designed for developers. But we know that not everyone who contributes to localization quality is a developer.

We'd like to explore what a human input experience can look like, in the same way OpenAI abstracted away the terminal with a desktop app for Codex. An experience where a linguist doesn't need to think about branches, compilation, or JSON. They see the content, the context, and the translation side by side. They refine what needs refining. And the tool handles everything else: committing, validating, opening the pull request.

The terminal is the right starting point because it's where the hardest problems get solved first. But the finish line is an experience that welcomes everyone who cares about making software speak every language.

Get started

Install the CLI with mise:

mise use github:tuist/l10n

Then initialize your project:

l10n init

This creates a L10N.md file at the root of your repository where you configure your LLM provider, source files, and target languages. Once configured, translate your content with:

l10n translate

Check what's stale with l10n status, and validate outputs with l10n check. That's it. No platform to sign up for, no dashboard to manage, no vendor to negotiate with.

l10n is completely free and open source. If it feels like a polished product, that's intentional. At Tuist, we treat our open source work as products too. We put the same care, the same attention to developer experience, and the same quality standards into l10n that we put into everything we ship. We believe open source deserves that level of craft, and so do the teams that rely on it.