Run Context-Rich LLM Translation with a Human Gate

Tier: Core · Workflow area: Styling, responsive & i18n

The difference between machine translation that embarrasses you and LLM translation that reads native is almost entirely context engineering, plus the humility to keep a human gate on the way out.

Prerequisites

• •
  Externalized strings with stable keys (see the externalization sweep playbook) in ICU or i18next format.
• •
  Screenshots of the major surfaces, or a Storybook the model can be shown frame by frame.
• •
  A glossary: product terms that never translate (brand names, feature names), terms with mandated translations, and tone rules (formal vs informal address per language — du vs Sie, tu vs vous — decided before translating, not per string).

The recipe

1. 1.

   Build the context pack once per project. This is what separates this playbook from feeding a JSON file to a chatbot:

   Copy

   You are translating a B2B invoicing web app from en-US to de-DE.
   Audience: finance professionals; register: formal (Sie). Attached:
   (1) glossary.md — do-not-translate list and mandated term choices,
   (2) six annotated screenshots of the main flows,
   (3) flow-notes.md — one paragraph per screen on what the user is doing.
   Rules: preserve ICU syntax exactly ({count, plural, ...}, {name});
   never translate interpolation variable names; keep markup tags and
   their nesting; German compounds tend long — flag any translation
   likely to exceed ~130% of the source length as TIGHT.
   

2. 2.

   Translate in batches with per-string context columns. Send strings as a table, not a blob:

   Copy

   Translate the attached 80 rows. Input columns: key | source string |
   where it appears (screen + element type: button/label/toast/empty-state)
   | max length if constrained. Output columns: key | translation |
   confidence (high/medium/low) | notes. Mark LOW anything where you had
   to guess referent, gender, or number — do not guess silently. "Start"
   on a button and "Start" as a column header are different words in German;
   the element type column is why you know which is which.
   

   The confidence column is the routing mechanism: high-confidence rows go to reviewer skim; low-confidence rows go to reviewer attention. A model that marks nothing low is not being honest — say so and re-run.

3. 3.

   Machine-check before any human sees it. Cheap automated validation catches the mechanical breakage: run the translated files through your framework's parser (ICU syntax errors), diff the interpolation variables per key (source {name} must appear exactly once in the translation), and check markup tag parity. An agent can write this validator in ten minutes; it saves reviewers from burning attention on {nom} bugs.

4. 4.

   Run the pseudo-and-real layout pass. Load each locale in the running app (or Storybook) and screenshot the main flows. German and Finnish break buttons; Arabic flips the layout (test RTL explicitly if in scope); Japanese changes line-breaking behavior. Route every TIGHT-flagged string plus every visual overflow to a fix: shorter translation, text-overflow handling, or a layout change. This pass is agent-automatable with a browser tool driving the locale switcher.

5. 5.

   Gate each market on native review, structured. Give reviewers the same context pack plus a triage protocol so review is hours, not weeks: skim high-confidence rows for tone drift, scrutinize every low-confidence and TIGHT row, and spot-check 10% at random against screenshots. Reviewer verdicts per row: approve / fix (with correction) / escalate. Corrections flow back into the glossary and tone rules — the context pack compounds, so batch two reviews faster than batch one.

6. 6.

   Ship through the TMS, not around it. Import the approved batch into Lokalise/Crowdin (or your git-based flow) so translation memory records every approved pair. Next quarter's fifty new strings get pre-filled from memory, LLM-drafted for the remainder, and the same gate — the pipeline is now standing infrastructure.

Tool variations

• Claude / Gemini with vision: the screenshot-grounded translation lane; multimodal context is what disambiguates short strings, so prefer these for UI copy over text-only translation models.
• Lokalise / Crowdin built-in AI: both offer in-platform AI translation with your glossary and translation memory applied automatically; use it when you want the workflow inside the TMS, and keep the same native-review gate.
• Agent + browser for the layout pass: Claude Code with a browser tool can switch locales, walk the route list, and screenshot every flow per language — turning step 4 from an afternoon into minutes.
• Mobile: identical pipeline for strings.xml / String Catalogs; add device-size screenshots since mobile buttons hit length limits hardest, and remember store-listing metadata needs the marketing lane, not this one.

Quality check

• Context pack exists and versionedglossary, register decision, and flow notes are in the repo, not in a chat history.
• No silent guessesthe confidence column is populated honestly; every LOW row got human attention.
• Mechanical validation is greenICU parses, variables match, tags balanced, before human review started.
• Layout pass per localescreenshots of main flows in each shipped language, TIGHT strings resolved.
• Native sign-off recordeda named reviewer approved each market; corrections were folded back into the glossary.