DEV Community: shipi18n

Stop Shipping Broken Strings: Placeholder-Safe i18n in Node.js + Express

shipi18n — Sun, 21 Dec 2025 18:03:37 +0000

Stop Shipping Broken Strings: Placeholder-Safe i18n in Node.js + Express

One missing {{name}} can crash an email template, break a UI render, or—worse—silently corrupt analytics payloads. The scary part is that placeholder bugs often don’t show up in the language you test (usually English). They wait until a specific locale hits production and then fail in the most inconvenient place: a password reset email, a checkout confirmation, a PDF invoice, or an event pipeline you only notice weeks later.

This is the classic localization trap: placeholder drift. It’s a “looks fine in review” bug because the translation change is just a string diff… until runtime tries to interpolate variables that no longer match.

This article shows how to build an Express i18n pipeline that:

Validates placeholders automatically (so missing variables and typos are caught immediately),
Fails fast in CI (so broken locale files never ship),
Degrades safely in production (so you don’t take down critical flows when something slips through).

Let’s define the problem precisely, then implement the guardrails.

1) The real problem: how placeholder drift breaks apps (and why it’s hard to catch in review)

1.1 What placeholder drift looks like in the wild

Placeholder drift happens when translation strings across locales stop matching the placeholder contract you intended.

Common mismatch types include:

Missing placeholders: base has {{name}}, another locale forgot it.
Renamed placeholders: {{orderId}} becomes {{orderID}} (case changes are brutal).
Extra placeholders: a translator adds {{company}} because it “reads better”.
Changed nesting: {{user.name}} vs {{name}}.
Plural/select inconsistencies: one plural branch forgets {{count}}, so it only breaks for certain values.

Where does it show up? Anywhere strings are templates:

Transactional emails (subject, preheader, body blocks)
Notifications and UI microcopy
Logs and analytics events (especially labels/properties)
PDF generation, invoices, receipts

And the impact is high:

Runtime exceptions (templating engines can throw)
Broken rendering (raw {{name}} leaks to users)
Wrong attribution (analytics labels missing identifiers)
Partial output (some libs replace unknown vars with empty strings)

Here’s a minimal example. Imagine you store translations as JSON and use a simple mustache-like renderer:

locales/en.json

{
  "email": {
    "reset": {
      "subject": "Reset your password, {{name}}"
    }
  }
}

locales/fr.json

{
  "email": {
    "reset": {
      "subject": "Réinitialisez votre mot de passe"
    }
  }
}

If your email code assumes {{name}} is present, you might send:

English: “Reset your password, Sam”
French: “Réinitialisez votre mot de passe” (missing personalization)

Or, depending on your templating pipeline, you might crash if the template engine expects a variable that isn’t there (or if you validate inputs but only for English).

The key point: this isn’t a “translation quality” issue—it’s an API contract issue.

1.2 Why review doesn’t catch it (and why tests often miss it)

Placeholder drift is uniquely sneaky because localization workflows live outside your normal type system and compilation pipeline.

Translators often edit strings in a TMS, CSV export, or JSON file. Placeholder edits don’t trigger compile errors.
Reviewers don’t speak every language, and diffs are noisy. It’s easy to miss {{orderId}} → {{orderID}} buried in a paragraph.
Unit tests commonly cover only one locale (usually en) and only a subset of keys.
Dynamic keys make static analysis harder: t(\email.${type}.subject) can’t easily be enumerated by a linter.

A realistic PR diff might look like this:

- "subject": "Votre commande {{orderId}} est confirmée"
+ "subject": "Votre commande {{orderID}} est confirmée"

That’s a one-character change that can break every French confirmation email.

So the goal isn’t “review harder.” The goal is make placeholder correctness automatic: safe translation calls + validation across locales.

1.3 Define the contract: placeholders are part of the API

Treat each translation string like a function signature:

Key: email.reset.subject
Parameters: { name: string }
Return: localized string

If you change the placeholders, you changed the signature. That’s an API change.

A practical contract policy looks like this:

Base locale is canonical (often en): its placeholder set defines the required variables.
Every other locale must match the placeholder set for the same key.
Strictness varies by environment:
- CI/dev: fail fast (throw)
- Production: degrade safely (fallback to base locale or sentinel placeholders), but always log/alert

Now let’s implement that in Node.js + Express.

2) Implementing placeholder-safe translation calls in Node.js/Express

To keep examples self-contained, we’ll use JSON locale files and a simple translation function. You can adapt the same approach to i18next, node-polyglot, @formatjs/intl, etc.

2.1 Choose a template format and extraction strategy (Mustache/Handlebars/ICU)

If your placeholders look like {{name}}, extraction is straightforward and fast. If you use ICU MessageFormat (recommended for plural/select), you should parse with an ICU parser rather than regex.

For this article we’ll implement Mustache-style extraction, and later discuss ICU.

extractPlaceholders() (TypeScript, but works in JS too):

// i18n/placeholders.ts
export function extractPlaceholders(template: string): Set<string> {
  // Matches {{ name }}, {{user.name}}, but not {{{triple}}} specifically.
  // Adjust to your template syntax.
  const re = /{{\s*([a-zA-Z0-9_.-]+)\s*}}/g;
  const out = new Set<string>();
  let match: RegExpExecArray | null;

  while ((match = re.exec(template)) !== null) {
    out.add(match[1]);
  }
  return out;
}

This gives you a placeholder set you can compare to provided variables.

Your next move: wrap translation calls so validation is the default.

2.2 Build a `tSafe()` helper that validates placeholders at runtime (dev/test)

We’ll create:

a basic t() that resolves the localized string for a key
a tSafe() wrapper that:
- extracts placeholders from the resolved template
- checks missing variables
- optionally checks extra variables (great for catching typos)
- throws in strict mode, otherwise falls back safely

First, a tiny translator implementation:

// i18n/translator.ts
export type LocaleDict = Record<string, any>;

function getByPath(obj: any, key: string): unknown {
  return key.split(".").reduce((acc, part) => (acc ? acc[part] : undefined), obj);
}

export function createTranslator(dict: LocaleDict) {
  return function t(key: string): string {
    const value = getByPath(dict, key);
    if (typeof value !== "string") return key; // simple fallback
    return value;
  };
}

Now the safe wrapper:

// i18n/tSafe.ts
import { extractPlaceholders } from "./placeholders.js";

type OnErrorMode = "throw" | "fallbackToBase" | "sentinel";

export type SafeOptions = {
  strict?: boolean;              // fail fast
  checkExtraVars?: boolean;      // catch typos
  onError?: OnErrorMode;         // production behavior
  baseT?: (key: string) => string; // fallback translator
  logger?: (info: Record<string, any>) => void;
};

function renderMustache(template: string, vars: Record<string, any>): string {
  return template.replace(/{{\s*([a-zA-Z0-9_.-]+)\s*}}/g, (_, name) => {
    const v = vars[name];
    return v === undefined || v === null ? "" : String(v);
  });
}

export function createSafeTranslator(
  t: (key: string) => string,
  locale: string,
  opts: SafeOptions
) {
  const strict = opts.strict ?? false;
  const checkExtra = opts.checkExtraVars ?? true;
  const onError: OnErrorMode = opts.onError ?? (strict ? "throw" : "fallbackToBase");

  return function tSafe(key: string, vars: Record<string, any> = {}): string {
    const template = t(key);
    const placeholders = extractPlaceholders(template);

    const provided = new Set(Object.keys(vars));
    const missing = [...placeholders].filter((p) => !provided.has(p));
    const extra = checkExtra ? [...provided].filter((p) => !placeholders.has(p)) : [];

    if (missing.length === 0 && extra.length === 0) {
      return renderMustache(template, vars);
    }

    const errorInfo = {
      type: "i18n_placeholder_mismatch",
      key,
      locale,
      missing,
      extra,
      templateSnippet: template.slice(0, 120)
    };

    opts.logger?.(errorInfo);

    if (onError === "throw") {
      const msg =
        `i18n placeholder mismatch for "${key}" (${locale}). ` +
        (missing.length ? `Missing: ${missing.join(", ")}. ` : "") +
        (extra.length ? `Extra: ${extra.join(", ")}. ` : "") +
        `Template: "${template.slice(0, 80)}..."`;
      throw new Error(msg);
    }

    if (onError === "sentinel") {
      // Replace missing placeholders with visible markers
      const sentinelVars = { ...vars };
      for (const p of missing) sentinelVars[p] = `[missing:${p}]`;
      return renderMustache(template, sentinelVars);
    }

    // fallbackToBase
    if (opts.baseT) {
      const baseTemplate = opts.baseT(key);
      const basePlaceholders = extractPlaceholders(baseTemplate);
      const baseMissing = [...basePlaceholders].filter((p) => !(p in vars));

      if (baseMissing.length === 0) return renderMustache(baseTemplate, vars);

      // If even base can't render, last-resort sentinel
      const sentinelVars = { ...vars };
      for (const p of baseMissing) sentinelVars[p] = `[missing:${p}]`;
      return renderMustache(baseTemplate, sentinelVars);
    }

    // No base translator provided: return key as last resort
    return key;
  };
}

This gives you a single translation API that enforces the contract whenever you want. In CI, set strict: true. In production, use fallbackToBase + logging.

Next: wire it into Express so every request gets the correct locale and a safe translator.

2.3 Express middleware: locale detection + request-scoped translator

You can detect locale from Accept-Language, a user profile, a cookie, or a URL prefix. Here’s a simple Accept-Language detector with a supported-locale list.

// i18n/middleware.ts
import type { Request, Response, NextFunction } from "express";
import { createTranslator } from "./translator.js";
import { createSafeTranslator } from "./tSafe.js";

type MiddlewareConfig = {
  dictionaries: Record<string, any>; // { en: {...}, fr: {...} }
  baseLocale: string;
  supportedLocales: string[];
  strict: boolean;
  logger?: (info: Record<string, any>) => void;
};

function pickLocale(acceptLanguage: string | undefined, supported: string[], base: string) {
  if (!acceptLanguage) return base;
  // Extremely simplified parsing: "fr-CA,fr;q=0.9,en;q=0.8"
  const candidates = acceptLanguage.split(",").map((s) => s.trim().split(";")[0]);
  for (const c of candidates) {
    const normalized = c.toLowerCase();
    const exact = supported.find((l) => l.toLowerCase() === normalized);
    if (exact) return exact;

    // match "fr-CA" -> "fr"
    const lang = normalized.split("-")[0];
    const baseMatch = supported.find((l) => l.toLowerCase() === lang);
    if (baseMatch) return baseMatch;
  }
  return base;
}

export function i18nMiddleware(config: MiddlewareConfig) {
  const baseT = createTranslator(config.dictionaries[config.baseLocale]);

  return (req: Request, res: Response, next: NextFunction) => {
    const locale = pickLocale(
      req.header("accept-language"),
      config.supportedLocales,
      config.baseLocale
    );

    const t = createTranslator(config.dictionaries[locale]);
    const tSafe = createSafeTranslator(t, locale, {
      strict: config.strict,
      onError: config.strict ? "throw" : "fallbackToBase",
      baseT,
      logger: config.logger
    });

    (req as any).locale = locale;
    (req as any).t = t;
    (req as any).tSafe = tSafe;

    res.locals.locale = locale;
    res.locals.t = tSafe; // convenient for server-rendered views

    next();
  };
}

Usage in your app:

import express from "express";
import en from "./locales/en.json" with { type: "json" };
import fr from "./locales/fr.json" with { type: "json" };
import { i18nMiddleware } from "./i18n/middleware.js";

const app = express();

app.use(
  i18nMiddleware({
    dictionaries: { en, fr },
    baseLocale: "en",
    supportedLocales: ["en", "fr"],
    strict: process.env.STRICT_I18N === "true",
    logger: (info) => console.warn(JSON.stringify(info))
  })
);

Now every request has req.tSafe(key, vars) and your templates can use res.locals.t(...).

2.4 Real-world examples: emails, UI strings, and analytics events

Emails: the most common place placeholder drift becomes expensive.

// email/sendResetEmail.ts
type ReqWithI18n = { tSafe: (key: string, vars?: any) => string };

export async function sendResetEmail(req: ReqWithI18n, to: string, name: string, link: string) {
  const subject = req.tSafe("email.reset.subject", { name });
  const body = req.tSafe("email.reset.body", { name, link });

  // send with your provider...
  return { to, subject, body };
}

If French drops {{link}} or renames {{name}}, you’ll catch it in strict mode (CI/dev). In production, you can fallback to English rather than sending a broken email.

UI / API responses:

app.get("/api/not-found", (req, res) => {
  const t = (req as any).tSafe;
  res.status(404).json({
    code: "NOT_FOUND",
    message: t("errors.notFound", { resource: "Page" })
  });
});

Analytics: placeholder bugs here can silently corrupt dashboards.

function track(event: string, props: Record<string, any>) {
  // your analytics client
}

app.post("/checkout/start", (req, res) => {
  const t = (req as any).tSafe;
  const plan = "Pro";

  track("Checkout Started", {
    label: t("analytics.checkoutLabel", { plan }), // avoid raw {{plan}} leaking
    locale: (req as any).locale
  });

  res.json({ ok: true });
});

Runtime checks are great, but you don’t want to rely on runtime to find issues. Next: enforce placeholder parity in CI.

3) Automated checks: CI validation of placeholder parity across locales + safe fallbacks

3.1 CI script: validate placeholder parity for every key across locales

The CI validator should answer one question:

For every key, do all locales have the same placeholder set as the base locale?

To do that, you need to flatten nested JSON keys.

// scripts/validate-i18n.ts
import fs from "node:fs";
import path from "node:path";
import { extractPlaceholders } from "../i18n/placeholders.js";

function flatten(obj: any, prefix = "", out: Record<string, any> = {}) {
  for (const [k, v] of Object.entries(obj)) {
    const key = prefix ? `${prefix}.${k}` : k;
    if (v && typeof v === "object" && !Array.isArray(v)) flatten(v, key, out);
    else out[key] = v;
  }
  return out;
}

function loadJson(p: string) {
  return JSON.parse(fs.readFileSync(p, "utf8"));
}

const localesDir = path.join(process.cwd(), "locales");
const baseLocale = "en";

const localeFiles = fs
  .readdirSync(localesDir)
  .filter((f) => f.endsWith(".json"))
  .map((f) => ({ locale: path.basename(f, ".json"), file: path.join(localesDir, f) }));

const dicts: Record<string, any> = {};
for (const { locale, file } of localeFiles) dicts[locale] = loadJson(file);

if (!dicts[baseLocale]) {
  console.error(`Base locale "${baseLocale}" not found in ${localesDir}`);
  process.exit(2);
}

const baseFlat = flatten(dicts[baseLocale]);
const baseKeys = Object.keys(baseFlat);

let failed = false;

for (const { locale } of localeFiles) {
  if (locale === baseLocale) continue;
  const flat = flatten(dicts[locale]);

  for (const key of baseKeys) {
    const baseVal = baseFlat[key];
    const val = flat[key];

    // Optional: enforce key presence
    if (val === undefined) {
      console.error(`[${locale}] Missing key: ${key}`);
      failed = true;
      continue;
    }

    // Enforce string type parity (optional but useful)
    if (typeof baseVal === "string" && typeof val !== "string") {
      console.error(`[${locale}] Key not a string: ${key}`);
      failed = true;
      continue;
    }

    if (typeof baseVal !== "string") continue; // ignore non-string branches

    const basePH = extractPlaceholders(baseVal);
    const ph = extractPlaceholders(val);

    const missing = [...basePH].filter((p) => !ph.has(p));
    const extra = [...ph].filter((p) => !basePH.has(p));

    if (missing.length || extra.length) {
      console.error(
        `[${locale}] Placeholder mismatch: ${key}\n` +
          `  base(${baseLocale}): ${JSON.stringify([...basePH])}\n` +
          `  ${locale}: ${JSON.stringify([...ph])}\n` +
          (missing.length ? `  missing: ${missing.join(", ")}\n` : "") +
          (extra.length ? `  extra: ${extra.join(", ")}\n` : "")
      );
      failed = true;
    }
  }
}

process.exit(failed ? 1 : 0);

Add it to package.json:

{
  "scripts": {
    "i18n:validate": "node --enable-source-maps scripts/validate-i18n.ts"
  }
}

Run it in CI with STRICT_I18N=true (for runtime tests) and npm run i18n:validate (for file parity).

Next, let’s talk about the hard part: plurals/select.

3.2 Handling plural/select and complex messages (ICU) without false positives

If you use ICU MessageFormat, placeholders aren’t just {{name}}. You’ll see patterns like:

{count, plural,
  one {You have {count} message}
  other {You have {count} messages}
}

A naive regex will miss variables, or worse, extract garbage. The fix is to parse ICU into an AST and collect variables properly. In Node, you can use packages such as:

@formatjs/icu-messageformat-parser (AST parsing)
intl-messageformat (formatting + parsing support in the FormatJS ecosystem)

Your CI script should then:

Parse each message
Collect all variable names used
Optionally validate that each plural branch includes the required variables (depending on your policy)

Even if you stick with Mustache for now, plan ahead: plural/select is where teams get tempted to “just tweak the string,” and drift becomes more likely. If you’re using Shipi18n (or any TMS), it’s worth enabling ICU-aware validation at import/export time so translators can’t accidentally break syntax.

3.3 Production-safe fallbacks: degrade gracefully but surface signals

Even with CI checks, production needs a safety net. Files can be hotfixed, experiments can introduce new keys, or a third-party translation sync can go wrong.

A good production policy:

For critical paths (emails, payments): consider onError: "fallbackToBase" or even "throw" if you prefer to block rather than send wrong content.
For UI microcopy: "fallbackToBase" is usually fine.
For analytics: "sentinel" can be better than empty strings because it keeps issues visible in dashboards.

Whatever you choose, always emit signals:

Structured logs with { key, locale, missing, extra, release }
Sentry events tagged by key and locale
Metrics like:
- i18n_placeholder_mismatch_total{locale,key}
- i18n_fallback_used_total{locale,key}

Because tSafe() already takes a logger, wiring this up is straightforward.

4) Production workflow: integrating Shipi18n with translators, versioning, and monitoring regressions

4.1 Source-of-truth and versioning strategy (keys, placeholders, and releases)

Once you treat placeholders as an API contract, you need a lightweight versioning mindset:

Base locale (en) defines the contract for each key.
Placeholder changes are breaking changes for that key:
- rename {{orderId}} → {{orderID}} = breaking
- remove {{name}} = breaking
- add {{company}} = breaking unless you guarantee it’s always provided

In practice, teams handle this by:

Keeping locale files in the repo
Requiring PRs for translation updates
Running placeholder parity validation in CI
Adding a checklist item in PR templates, e.g. “Did you change placeholders? If yes, update all locales or add a migration plan.”

This keeps changes visible and enforceable.

4.2 Shipi18n integration: syncing keys, protecting placeholders, and translator guidance

A TMS can reduce drift if it understands placeholders as protected tokens. Shipi18n fits naturally here because you can structure your workflow so placeholders are:

Marked as non-editable tokens (translators can move them, but not rename them)
Validated on import/export (placeholder parity checks before content lands in your repo)
Documented per key (translator notes: what {{name}} represents, capitalization rules, etc.)

Even without a specific config format, the principle is consistent: make placeholders first-class in the translation UI. Provide examples like:

“Use {{orderId}} exactly; do not change casing.”
“Keep {{count}} in all plural forms.”

This reduces drift at the source, not just at the build gate.

4.3 Monitoring and alerting: catch regressions fast in production

Finally, close the loop with monitoring. Add:

A counter for placeholder mismatches and fallbacks
Alerts on spikes after deploys
A post-deploy canary that renders critical templates across your top locales (password reset, order confirmation, invoice generation)

A simple canary can be as small as a script that loads your locale files and renders a set of known keys with sample variables. The goal is to catch “only breaks in fr-CA” issues minutes after a release, not days.

Conclusion

Placeholder drift is expensive because it hides in plain sight: a translation diff that looks harmless, until runtime hits the wrong locale and the wrong code path.

The fix is to treat placeholders like an API contract and enforce that contract everywhere:

Add a tSafe() helper so correct placeholder usage is the default.
Attach it via Express middleware so every request gets a request-scoped, locale-aware safe translator.
Validate placeholder parity in CI across all locales to fail fast before production.
In production, degrade safely (fallback/sentinel) and emit logs + metrics so nothing fails silently.
If you use a TMS like Shipi18n, protect placeholders and validate them during sync to prevent drift before it reaches your repo.

Pick one critical template this week—usually a password reset or order confirmation email—wrap it with tSafe(), add the CI validator script, and expand from there. Once you’ve felt the relief of never shipping broken placeholders again, you won’t go back.

How I Built a Multilingual Developer News Hub in a Weekend

shipi18n — Mon, 15 Dec 2025 10:21:31 +0000

TL;DR: I built a news aggregator that automatically translates article summaries to 5 languages the moment they're published. Here's how I did it with RSS feeds, Claude AI, and my own translation API.

The Problem

I wanted a developer news feed on shipi18n.com - curated content about React, Next.js, AI, and i18n. But our users speak different languages. Building separate feeds for each language? That's a maintenance nightmare.

What if every article was automatically available in Spanish, French, German, Japanese, and Chinese?

The Architecture

RSS Feeds → Superfeedr Webhook → Lambda → AI Summary → Translation API → DynamoDB
                                                           ↓
                                              React Frontend (i18next)

Three key components:

Feed aggregation - Superfeedr pushes new articles via webhook
AI summarization - Claude generates concise summaries
Auto-translation - Every summary gets translated instantly

Step 1: Setting Up RSS Aggregation

Instead of polling dozens of feeds, I use Superfeedr - they monitor RSS feeds and POST new items to my webhook.

// Lambda webhook handler
export async function handleSuperfeedrWebhook(req, res) {
  const payload = JSON.parse(req.body);

  for (const item of payload.items) {
    // Store article
    const result = await storeArticle(item, feedUrl);

    // Translate immediately
    if (result.created) {
      await queueTranslation(result.articleId, result.article);
    }
  }
}

Feeds I'm aggregating:

Frontend: Smashing Magazine, CSS-Tricks, Vercel Blog
AI: OpenAI, Anthropic, Hugging Face
i18n: W3C Internationalization
SaaS: Indie Hackers, Stripe

Step 2: AI-Generated Summaries

Most RSS feeds have terrible summaries - often just the first paragraph with HTML junk. Claude Haiku fixes that:

async function generateAISummary(article) {
  const response = await fetch('https://api.anthropic.com/v1/messages', {
    method: 'POST',
    headers: {
      'x-api-key': process.env.ANTHROPIC_API_KEY,
      'anthropic-version': '2023-06-01',
    },
    body: JSON.stringify({
      model: 'claude-3-haiku-20240307',
      max_tokens: 150,
      messages: [{
        role: 'user',
        content: `Write a 1-2 sentence summary of this article for developers.
                  Be concise and informative.
                  Title: "${article.title}"
                  URL: ${article.url}`
      }]
    })
  });

  const data = await response.json();
  return data.content[0].text;
}

Haiku is perfect for this - fast, cheap ($0.25/M input tokens), and the summaries are actually good.

Step 3: The Translation Magic

Here's where it gets seamless. I built Shipi18n specifically for this use case - translating strings programmatically without managing translation files.

async function queueTranslation(articleId, article) {
  const targetLangs = ['es', 'fr', 'de', 'ja', 'zh'];
  const translations = {};

  for (const lang of targetLangs) {
    // Translate title
    const titleResult = await translateText(article.title, 'en', lang);

    // Translate summary
    const summaryResult = await translateText(article.summary, 'en', lang);

    translations[lang] = {
      title: titleResult.translatedText,
      summary: summaryResult.translatedText,
    };
  }

  await updateArticleTranslations(articleId, translations);
}

The translateText function calls my own API:

const response = await fetch('https://api.shipi18n.com/translate', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': process.env.SHIPI18N_API_KEY
  },
  body: JSON.stringify({
    text: text,
    sourceLanguage: 'en',
    targetLanguages: [targetLang]
  })
});

One API call, instant translation. No translation files to manage.

Step 4: Frontend with i18next

The React frontend uses i18next for UI translations, and the article translations come from the API:

const { i18n } = useTranslation();
const currentLang = i18n.language?.split('-')[0] || 'en';

// Get translated content based on user's language
const getTranslatedContent = (article) => {
  if (currentLang === 'en' || !article.translations?.[currentLang]) {
    return { title: article.title, summary: article.summary };
  }
  return {
    title: article.translations[currentLang]?.title || article.title,
    summary: article.translations[currentLang]?.summary || article.summary,
  };
};

When a Japanese user visits, they see:

📰 React 19の新しいコンパイラがパフォーマンスを劇的に向上
Reactチームが新しいコンパイラを発表。手動のメモ化なしで...

When a Spanish user visits:

📰 El nuevo compilador de React 19 mejora drásticamente el rendimiento
El equipo de React anunció un nuevo compilador que...

Same article, automatic localization.

The Result

What I got:

News hub with 5 categories (i18n, Frontend, AI, SaaS, Creative)
Every article translated to 5 languages instantly
Language switcher that respects user's browser locale
Globe icon to preview all translations

Cost breakdown:

Superfeedr: ~$5/month for 30 feeds
Claude Haiku: ~$2/month for summaries
Shipi18n: Free tier covers it (90-day cache means repeat translations cost nothing)

Time to build: One weekend

Key Takeaways

Don't poll RSS feeds - Use a service like Superfeedr that pushes updates
AI summaries > raw excerpts - Claude Haiku is cheap enough to run on every article
Translate at ingest, not render - Doing it server-side means instant page loads
Cache translations - Shipi18n's 90-day cache means I only pay once per string

Try It

Check out the live news hub at shipi18n.com/news. Use the language switcher in the top navigation to switch between English, Spanish, French, German, Japanese, and more - watch all the article titles and summaries update instantly.

Want to add automatic translations to your own project? Get started with Shipi18n - the API that makes i18n feel effortless.

Building something multilingual? I'd love to hear about it. Find me on Twitter or join our Discord.

Stop Copy-Pasting Into Google Translate: Automate React i18n in 5 Minutes

shipi18n — Fri, 28 Nov 2025 23:44:11 +0000

You're about to deploy. Marketing just added 47 new strings to the app.

You copy the first one into Google Translate. Paste the Spanish back into your JSON file. Then French. Then German.

Thirty minutes later, you're still copying and pasting, and you've only done half.

Your deployment window closes in an hour.

There has to be a better way.

The Problem

Manual translation workflows are killing developer productivity.

Here's what the typical process looks like:

Copy each string from your en.json file into Google Translate
Manually paste translations back into es.json, fr.json, de.json
Fix the formatting that got broken during copy-paste
Debug placeholder variables like {username} that translators accidentally changed
Repeat for every single deployment when new strings are added
Waste 30-60 minutes per deploy on work a script should handle

The real kicker?

This manual process introduces errors about 15-20% of the time. A misplaced placeholder, a forgotten escape character, or a copy-paste mistake.

Suddenly your production app is showing undefined instead of user names.

The Solution

Automation.

Instead of manually shuttling text between Google Translate and your codebase, use a CLI tool that handles the entire translation pipeline automatically.

The concept is simple: your source JSON goes in, translated JSON files come out, with all placeholders preserved and formatting intact.

No more human copy-paste errors. No more wasted time.

Quick Example

# Instead of spending 45 minutes copying and pasting...
shipi18n translate

# Done. All your JSON files are translated.

That's it. Your en.json is now translated into every target language you've configured, with zero manual intervention.

Step-by-Step Guide

Let's set up automated translation for a React app. This should take about 5 minutes.

Step 1: Install shipi18n CLI

npm install -g shipi18n-cli

Step 2: Get Your API Key

The free plan includes 3 languages and 100 translation keys—perfect for side projects and small apps. No credit card required.

Set it as an environment variable:

export SHIPI18N_API_KEY=your_api_key_here

Step 3: Initialize Your Project

Navigate to your React project and run:

shipi18n init

This creates a shipi18n.config.js file:

module.exports = {
  apiKey: process.env.SHIPI18N_API_KEY,
  source: {
    path: './src/locales/en.json',
    language: 'en'
  },
  targets: [
    { language: 'es', path: './src/locales/es.json' },
    { language: 'fr', path: './src/locales/fr.json' },
    { language: 'de', path: './src/locales/de.json' }
  ],
  preserve: {
    placeholders: true,  // Keeps {username} intact
    htmlTags: true,      // Preserves <strong>, <em>, etc.
    formatting: true     // Maintains \n, \t, etc.
  }
}

Step 4: Run Your First Translation

shipi18n translate

You'll see output like this:

✓ Loaded source: en.json (127 keys)
✓ Translating to Spanish...
✓ Translating to French...
✓ Translating to German...
✓ Validated placeholders in all files
✓ Done! 3 files updated in 8 seconds

Step 5: Review and Deploy

Check the generated files:

{
  "welcome": "Bienvenido, {username}!",
  "itemCount": "Tienes {count} artículos en tu carrito"
}

Notice how {username} and {count} stayed intact? That's automatic placeholder preservation at work.

Automate with CI/CD (Bonus)

Want translations to happen automatically when you update en.json?

Add this to your GitHub Actions workflow:

# .github/workflows/translate.yml
name: Auto Translate
on:
  push:
    paths:
      - 'src/locales/en.json'

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install Shipi18n
        run: npm install -g shipi18n-cli

      - name: Translate
        env:
          SHIPI18N_API_KEY: ${{ secrets.SHIPI18N_API_KEY }}
        run: shipi18n translate

      - name: Commit translations
        run: |
          git config user.name "GitHub Actions"
          git config user.email "actions@github.com"
          git add src/locales/
          git commit -m "Auto-translate: update translation files"
          git push

Now every time someone updates the English translations, the other languages update automatically.

Time Savings Breakdown

Method	Time per deploy	Error rate	Placeholder safety
Manual Google Translate	45 min	~15%	Manual checking
Shipi18n CLI	2 min	<1%	Automatic

If you deploy twice a week, that's 75 hours per year saved per developer.

Key Takeaways

Manual translation workflows waste 30-60 minutes per deployment and introduce errors 15-20% of the time
CLI automation reduces translation time by 95% while virtually eliminating human error
Automatic placeholder preservation means no more {username} turning into {nombreDeUsuario}
CI/CD integration enables fully automated translation pipelines

Get Started

Start free with Shipi18n - 3 languages, 100 keys, no credit card
Check out the GitHub Action for CI/CD

Stop copying. Start shipping.

Originally published on shipi18n.com

DEV Community: shipi18n

Stop Shipping Broken Strings: Placeholder-Safe i18n in Node.js + Express

Stop Shipping Broken Strings: Placeholder-Safe i18n in Node.js + Express

1) The real problem: how placeholder drift breaks apps (and why it’s hard to catch in review)

1.1 What placeholder drift looks like in the wild

1.2 Why review doesn’t catch it (and why tests often miss it)

1.3 Define the contract: placeholders are part of the API

2) Implementing placeholder-safe translation calls in Node.js/Express

2.1 Choose a template format and extraction strategy (Mustache/Handlebars/ICU)

2.2 Build a tSafe() helper that validates placeholders at runtime (dev/test)

2.3 Express middleware: locale detection + request-scoped translator

2.4 Real-world examples: emails, UI strings, and analytics events

3) Automated checks: CI validation of placeholder parity across locales + safe fallbacks

3.1 CI script: validate placeholder parity for every key across locales

3.2 Handling plural/select and complex messages (ICU) without false positives

3.3 Production-safe fallbacks: degrade gracefully but surface signals

4) Production workflow: integrating Shipi18n with translators, versioning, and monitoring regressions

4.1 Source-of-truth and versioning strategy (keys, placeholders, and releases)

4.2 Shipi18n integration: syncing keys, protecting placeholders, and translator guidance

4.3 Monitoring and alerting: catch regressions fast in production

Conclusion

How I Built a Multilingual Developer News Hub in a Weekend

The Problem

The Architecture

Step 1: Setting Up RSS Aggregation

Step 2: AI-Generated Summaries

Step 3: The Translation Magic

Step 4: Frontend with i18next

The Result

Key Takeaways

Try It

Stop Copy-Pasting Into Google Translate: Automate React i18n in 5 Minutes

The Problem

The Solution

Quick Example

Step-by-Step Guide

Step 1: Install shipi18n CLI

Step 2: Get Your API Key

Step 3: Initialize Your Project

Step 4: Run Your First Translation

Step 5: Review and Deploy

Automate with CI/CD (Bonus)

Time Savings Breakdown

Key Takeaways

Get Started

2.2 Build a `tSafe()` helper that validates placeholders at runtime (dev/test)