I mass-translated 200 keys into 5 languages. It went wrong in ways I didn't expect.

Franco Ortiz — Tue, 07 Apr 2026 19:36:29 +0000

Last project I had to internationalize an app with around 200 keys across 5 languages. I figured it would take a morning. It took most of a day, and the interesting part wasn't the translating. It was everything else.

The actual translations were fine. DeepL, Google Translate, whatever. Ten minutes. What killed me was the workflow around it:

Creating 5 copies of every JSON file. Keeping them in sync. Discovering that {name} got translated to {nombre} in the Spanish file and broke interpolation. Finding a typo (settigns.title) that rendered as blank in production because there's no runtime error for a missing key. Realizing a week later that I forgot three keys in Japanese entirely.

The thing that surprised me was the ratio. The translation itself was maybe 10% of the time. The other 90% was file management, variable protection, and chasing silent failures.

What silent failures actually look like

This is the part nobody talks about. Your app doesn't crash when a translation key is wrong. It just renders nothing. Or it renders common.header.subtitl as literal text. Or it works in English and Spanish but breaks in Japanese because you have {count} items and the variable got mangled.

You don't catch these in development because you're developing in English. They show up in production, reported by users who don't speak English, often weeks later.

How I stopped doing it manually

I built i1n to automate the parts that kept breaking. The whole workflow now:

i1n push --translate es,fr,de,ja,pt

One command. Variables stay untouched in every language. And it generates a .d.ts file, so if I typo a key, TypeScript catches it before I even run the app.

But the real shift was adding an MCP server. If you use Cursor or Claude Code, you can tell your agent "internationalize this component" and it extracts the strings, translates, and rewrites the code. I was skeptical about this one. For repetitive extraction work, it's genuinely good.

The 85% problem

AI translation isn't perfect though. It gets context wrong on short strings ("Save" as a verb vs "Save" as a noun), goes too literal on idioms, and sometimes loses tone completely. I've seen it translate "Drop us a line" as the equivalent of "drop a rope" in Japanese.

That's why I ended up building a dashboard too. The AI handles the first pass, you review what it generated, fix what needs fixing, and mark those as approved so they don't get overwritten next time. If your source text changes later, the system flags which translations went stale.

85% automation, 15% human review. That split turned a full day of work into maybe 20 minutes.

What I'd tell someone setting up i18n today

Don't start with the translation. Start with the workflow. Figure out how you're going to keep files in sync, how you'll catch missing keys before production, and how you'll handle variables across languages. The translation is the easy part.

The CLI and dashboard are open source (MIT) if you want to try it: i1n.ai

How are you handling translations? I keep running into teams that either set up a full TMS they barely use, or just skip internationalization entirely because the workflow is too painful.

I told my AI agent "internationalize this" and it actually did it

Franco Ortiz — Tue, 31 Mar 2026 13:37:36 +0000

I've set up i18n in Next.js App Router projects more times than I'd like to admit. It's always the same: middleware config, a pile of JSON files, wiring up the provider, copy-pasting keys between locales, discovering at 11pm that common.heor.title returns undefined in production.

The last time it happened I was mass-translating 40+ keys across 5 languages by hand. I stopped halfway through and thought: why am I still doing this manually?

So I built i1n, an open source CLI (MIT) that pushes your translation keys and gets them back translated with full TypeScript types. Free tier, no credit card, no 14-day trial tricks.

Let me walk you through the setup.

Prerequisites

A Next.js project (App Router or Pages Router)
Node.js 18+
~5 minutes

Step 1: Install and init

npm install -g i1n
i1n init

It'll ask for an API key (you can grab one at i1n.ai, Google or GitHub login). After that it detects your framework and sets up the locale directory automatically.

Step 2: Write your source strings

locales/en_us/common.json:

{
  "hero": {
    "title": "Welcome to our app",
    "subtitle": "The best tool for {task}",
    "cta": "Get Started"
  },
  "nav": {
    "home": "Home",
    "about": "About",
    "pricing": "Pricing"
  }
}

Nothing new here — same JSON structure you're probably used to.

Step 3: Push and translate

i1n push --translate es,fr,de,ja

One command. It pushes your keys, translates to 4 languages, and generates i1n.d.ts with autocomplete for every key. Variables like {task} are left untouched in every language.

Step 4: Use it

import { t } from 'i1n';

export function Hero() {
  return (
    <section>
      <h1>{t('hero.title')}</h1>
      <p>{t('hero.subtitle', { task: 'building products' })}</p>
      <button>{t('hero.cta')}</button>
    </section>
  );
}

If you typo a key, TypeScript yells at you before it ever hits production. No more t('hera.titl') silently rendering nothing.

If you're already on i18next or next-intl, there's a Bridge Mode that wraps your existing setup with type safety. One line, no migration. Details in the docs.

Bonus: MCP Server

This part is honestly the most fun. If you use Cursor, Claude Code, or Windsurf:

claude mcp add i1n -- npx i1n mcp

Now you can just tell your AI agent "internationalize this component" and it actually does it. Reads the file, extracts the strings, pushes them, translates everything, rewrites the code with t() calls. What used to take me an hour is like 30 seconds now.

What does your i18n setup look like? I've been going back and forth between next-intl and i18next with the App Router and I'm curious what other people landed on.

DEV Community: Franco Ortiz