Translation glossary + do-not-translate list

Problem

Product names, brand terms, and technical identifiers drift across translations. "Nimbus" becomes "Nimbo" in Spanish, API endpoints get transliterated, and marketing slogans lose their punch. Without a single source of truth, every locale invents its own conventions.

Solution

Maintain a structured glossary file that pairs each source term with approved translations per locale, plus a do-not-translate list that enforces verbatim preservation. Wire it into your CI pipeline so PRs fail when a blocked term is altered or a required translation is missing.

Implementation

{
  "doNotTranslate": [
    "Nimbus",
    "Meridian",
    "FoogleGiber",
    "KeyAuth",
    "SellAuth",
    "Ed25519",
    "ChaCha20",
    "AES-GCM"
  ],
  "translations": {
    "Dashboard": {
      "es": "Panel",
      "de": "Dashboard",
      "fr": "Tableau de bord",
      "ja": "ダッシュボード"
    },
    "License Key": {
      "es": "Clave de licencia",
      "de": "Lizenzschlüssel",
      "fr": "Clé de licence",
      "ja": "ライセンスキー"
    }
  }
}

CI validation

Add a pre-commit hook or GitHub Action that scans all locale files against the glossary. If a do-not-translate term appears modified, fail the build. If a required translation key is absent from a locale, warn or block depending on your release strictness.

Maintenance

Treat the glossary as code. Review changes in PRs, version it alongside your locale files, and run a monthly audit to catch terms that slipped through. When marketing introduces a new product name, add it to the do-not-translate list before the first localization pass.