Review Localization in Context, Not in a Spreadsheet

Workflow area: Content & UX Writing · Tier: Core · Hands-on time: ~30 minutes

Traditional localization ships strings to translators in a spreadsheet: no screen, no flow, no idea whether "Save" is a button, a menu item or a noun. The result is grammatically correct copy that breaks layouts, misses register, and translates the wrong sense of ambiguous words. Multimodal models flip the workflow: they can see the screenshot, read the flow, and draft with context the spreadsheet never carried. That doesn't make them native speakers — it makes them context-aware drafters whose output a designer can review visually and a native speaker can gate efficiently.

When to use — and when not to

• Use it when strings ship to translation without screensif your current pipeline is context-free, adding screenshots to AI drafting is the single biggest quality jump available.
• Use it for design-review of returned translationseven human-translated strings need the layout and register pass; a vision model reading the localized build catches overflow and truncation fast.
• Use it for long-tail languages you can't staffAI drafts plus a periodic native review beat the nothing those markets currently get.
• Skip the AI-only path for launch marketsanywhere revenue or reputation is concentrated, the native-speaker gate is non-negotiable; the AI drafts, a human owns.
• Skip it for legal, medical and consent stringsregulated copy needs certified translation, not a drafting pipeline.

The recipe

1. 1.

   Package context, not just strings. For each batch: the string with its ID, a screenshot of the screen it lives on, what the element is (button, title, tooltip), character or width constraints, and one line of flow context ("appears after the user cancels a paid plan"). This package is the whole trick — it is what the spreadsheet never had.

2. 2.

   Draft with a register brief per market. Language alone underspecifies: German business software expects Sie, a fitness app might use du. Decide register per market before drafting:

   Copy

   Translate these UI strings to [LANGUAGE] for [MARKET].
   
   PRODUCT: [one line]. REGISTER: [formal/informal, e.g. German Sie;
   concise; no anglicisms where a natural native term exists].
   
   For each string you get: ID, English source, element type, max
   characters, flow context, and a screenshot reference.
   
   Rules:
   1. Fit the character limit. If natural [LANGUAGE] cannot fit,
      return your best short form AND flag it OVERFLOW-RISK with the
      natural longer form noted.
   2. Match the element: buttons are verbs/actions, titles are nouns.
   3. Flag AMBIGUOUS any English string whose sense you had to guess.
   4. Keep product terms from this glossary untranslated: [TERMS].
   
   ID: btn.trial.start | "Start free trial" | button | max 20 chars |
   pricing page, primary CTA | screenshot 1
   [PASTE BATCH]
   

   Good output looks like this:

   Copy

   btn.trial.start → "Jetzt kostenlos testen" (22 chars) OVERFLOW-RISK
   short form: "Kostenlos testen" (16 chars) — natural, keeps meaning.
   dlg.cancel.title → AMBIGUOUS: "Cancel" = abort dialog or cancel
   subscription? Screenshot suggests subscription → "Abo kündigen".
   

3. 3.

   Run the visual layout pass on real screens. Get the drafts into the actual UI — a localized staging build, or Figma frames with strings swapped in. Screenshot each screen and have a vision model sweep it: text overflowing buttons, truncated labels, wrapped headings, mixed-language leftovers. German runs ~30% longer than English and will find every fixed-width container you forgot.

4. 4.

   Review register and culture like a designer, not a proofreader. Ask the model to self-audit the batch — formality consistency (no Sie/du mixing), date/number/currency formats, idioms that don't travel, imagery or metaphors with unintended local meaning — then read its findings as claims to check, not verdicts to accept.

5. 5.

   Gate with a native speaker — efficiently. Send the native reviewer the flagged subset first (OVERFLOW-RISK, AMBIGUOUS, register flags) plus a random 20% sample of the unflagged rest, with screenshots. If the random sample surfaces problems the flags missed, widen the review; if it's clean, ship and log the reviewer's corrections back into the glossary and register brief so the next batch starts smarter.

Make it yours

• Gemini for the visual sweep: its long context takes an entire flow of localized screenshots in one pass — ask for a screen-by-screen defect table with severity, then fix in Figma or file tickets.
• Crowdin or Lokalise as the pipeline home: both attach screenshots to strings and carry AI translation with context natively; use this playbook's prompts as the drafting brief and keep the term base synced from your pb-29 sweep.
• Pseudo-localization first: before translating anything, run a pseudo-loc pass (lengthened accented gibberish) through the same visual review to find every breakable layout — then real translations arrive into containers that already survived the stress test.

Quality check

• Every draft saw its screena string translated without its screenshot is spreadsheet localization with extra steps.
• Constraints were honored or flaggedsilent overflow is the failure; OVERFLOW-RISK flags with alternatives are the system working.
• Register is consistent per marketone informal string in a formal product reads as a bug in any language.
• Ambiguity was surfaced, not guessed awaythe AMBIGUOUS flags are where mistranslation was prevented; an output with zero flags on idiomatic English deserves suspicion.
• The native gate ran for target marketsand its corrections were fed back into the glossary, so the reviewer teaches the pipeline instead of re-fixing it forever.