Browser extension i18n without a TMS subscription

What a TMS actually requires you to do

Every major TMS follows the same onboarding flow. Before you can translate a single string, you must:

For a team shipping a complex SaaS product with continuous deployments and multiple translators, this overhead is justified. For a developer with a 60-key messages.json who wants to add 10 languages before a Chrome Web Store update, it is a multi-hour setup with a monthly recurring cost.

What TMS platforms cost

Published pricing as of early 2026. All plans require a monthly or annual subscription — there is no pay-per-translation option on any major TMS.

Verify current pricing on each platform before purchasing.

What the extension i18n format actually looks like

The WebExtension i18n API reads from _locales/{locale}/messages.json. Each key maps to a message object with a message field, an optional description, and optional placeholders:

// _locales/en/messages.json
{
  "appName": {
    "message": "Tab Manager Pro",
    "description": "The extension name shown in the browser"
  },
  "welcomeMessage": {
    "message": "Welcome, $USER$",
    "description": "Greeting shown on first open",
    "placeholders": {
      "user": {
        "content": "$1",
        "example": "Alice"
      }
    }
  },
  "tabCount": {
    "message": "$COUNT$ tabs open",
    "placeholders": {
      "count": { "content": "$1" }
    }
  }
}

A translated file keeps the same structure. Key names and $PLACEHOLDER$ tokens must not change — only the message value changes:

// _locales/de/messages.json
{
  "appName": {
    "message": "Tab Manager Pro",
    "description": "The extension name shown in the browser"
  },
  "welcomeMessage": {
    "message": "Willkommen, $USER$",
    "description": "Greeting shown on first open",
    "placeholders": {
      "user": {
        "content": "$1",
        "example": "Alice"
      }
    }
  },
  "tabCount": {
    "message": "$COUNT$ Tabs geöffnet",
    "placeholders": {
      "count": { "content": "$1" }
    }
  }
}

This is a straightforward JSON-to-JSON transformation. The structure stays the same; only the string values inside message fields change, with $PLACEHOLDER$ tokens preserved exactly. A TMS is not required for this transformation.

The three real options for indie extension developers

When a TMS is the right choice

TMS platforms exist for good reasons. They are the right tool when:

If none of these apply — if you are a solo developer shipping an extension update and need 10 locale files this week — a TMS subscription is not the right tool.

The DIY approach: translate messages.json with the DeepL API

If you want to own the full translation pipeline, here is a minimal Node.js script that translates a messages.json file using the DeepL API while preserving $PLACEHOLDER$ tokens. DeepL supports XML tag protection — wrap tokens before sending and unwrap after:

// translate-extension.mjs
// Requires: npm install deepl-node
// Uses the DeepL free API tier (500k chars/month)

import * as deepl from "deepl-node";
import { readFileSync, writeFileSync, mkdirSync } from "node:fs";
import { join } from "node:path";

const DEEPL_KEY = process.env.DEEPL_API_KEY;
const TARGET_LANGS = ["DE", "FR", "JA", "ES", "PT-BR", "ZH"];

const translator = new deepl.Translator(DEEPL_KEY);
const source = JSON.parse(readFileSync("_locales/en/messages.json", "utf8"));

const TOKEN_RE = /\$([A-Z0-9_]+)\$/g;

async function translateEntry(messageStr, targetLang) {
  // Wrap $TOKEN$ as <keep>TOKEN</keep> so DeepL ignores it
  const wrapped = messageStr.replace(TOKEN_RE, (_, name) => `<keep>${name}</keep>`);

  const result = await translator.translateText(wrapped, "en", targetLang, {
    tagHandling: "xml",
    ignoreTags: ["keep"],
  });

  // Restore $TOKEN$ from <keep>TOKEN</keep>
  return result.text.replace(/<keep>([^<]+)<\/keep>/g, (_, name) => `$${name}$`);
}

for (const lang of TARGET_LANGS) {
  const output = {};

  for (const [key, entry] of Object.entries(source)) {
    const translated = await translateEntry(entry.message, lang);
    output[key] = { ...entry, message: translated };
  }

  const dir = join("_locales", lang.toLowerCase().replace("-", "_"));
  mkdirSync(dir, { recursive: true });
  writeFileSync(join(dir, "messages.json"), JSON.stringify(output, null, 2));
  console.log(`Written: ${dir}/messages.json`);
}

What to check before shipping translated files

Whether you translate manually, with a script, or with a service, run these checks before packaging your extension:

See Validate messages.json before shipping for ready-to-run validation scripts covering all of these checks.

The _locales folder structure

Chrome, Firefox, Edge, Safari, and Opera all expect the same folder layout. Locale codes use underscores, not hyphens (pt_BR not pt-BR). The default_locale in manifest.json must match one of the folder names exactly:

_locales/
  en/
    messages.json    ← default_locale
  de/
    messages.json
  fr/
    messages.json
  ja/
    messages.json
  es/
    messages.json
  pt_BR/             ← underscore, not hyphen
    messages.json
  zh_CN/
    messages.json

manifest.json
  "default_locale": "en"   ← must match a _locales/ folder name

See Chrome extension i18n: _locales structure and default_locale for the full reference including supported locale codes.

Summary: which approach fits your situation

Related guides