A localization handoff that design, QA, and engineering can all use

AI disclosure: This tutorial was generated with AI. The reward dialog is a hypothetical example; no production screenshot or test result is claimed.

Describe the failure at the string level

A localization issue often arrives as “German breaks the popup.” That report mixes several decisions: whether the translation is correct, whether the layout can accommodate it, and whether the right resource reaches the UI. Give each decision an owner before requesting a fix.

Use a small example: a reward dialog has a button with the English source string “Claim reward.” In the German locale, the approved translation is longer than the available space at the smallest supported viewport. The designer owns the layout rule, a locale reviewer owns the language, and engineering owns how the component applies both.

Do not shorten the translation solely to fit an arbitrary character count. Characters have different widths, and a short phrase can still be semantically wrong.

Create a task from this template

task: Fix reward-dialog action-label clipping
string_key: rewards.claim_cta
source_locale: en
source_string: Claim reward
target_locale: de
target_string: use the locale reviewer's approved resource value
screen: daily reward confirmation dialog
state: reward available; no network request in progress
viewport: smallest supported mobile viewport, exact dimensions required
font: record actual family, weight, size and fallback behavior
context_screenshot:
  before: attach a real capture showing the whole dialog and clipped label
  after: capture the same viewport, locale, state and build configuration
scope: this dialog's action-label layout
exclude: translation rewrites, reward logic, global typography changes
preparer: QA with design
executor: UI engineer using their own authorized development tools
reviewers:
  language: locale reviewer
  layout: designer
  acceptance: QA lead

The screenshot entries are evidence requirements, not links to nonexistent images. Before using this as a real ticket, attach a capture from the affected build and record its revision. Crop out private account information, but retain enough surrounding UI to explain what the button does.

Work the handoff in three decisions

First, QA reproduces the clipping and records the locale, device scale, viewport, and loaded font. A fallback font can change the result, so a screenshot without font context is insufficient. QA also checks whether the defect appears before or after the translation resources finish loading.

Second, design specifies an acceptable layout behavior. For example, permit the action region to grow vertically while preserving the existing minimum touch target and the approved gap to the secondary action. This is an example decision, not a universal prescription. If the product requires a single-line button, design must instead define an approved width strategy or language-review escalation.

Third, the engineer changes only the relevant component and returns the diff with comparable before/after captures. If the implementation discovers a shared component issue, expand the scope explicitly before changing every dialog in the game.

An assistant can help find uses of the string key, draft a test matrix, or propose a constrained component change. That is expert supervised AI execution when the human owners provide the context and review the evidence. Wagglet's studio-stack discussion provides a related framework for coordinating those roles. It does not make an AI-generated translation an approved resource.

Verify content and layout separately

Use this acceptance checklist for the example:

• The exact approved target string renders without clipping or ellipsis.
• The label remains inside the action area at each supported narrow viewport.
• The button still performs the same reward action exactly once.
• English remains readable and the secondary action remains reachable.
• The locale reviewer approves meaning and tone independently of layout.
• QA captures the final state using the same setup as the original report.

Add an automated layout assertion if the application exposes suitable bounds. Check the rendered text against its actual containing region after fonts and translations are ready. A character-count check cannot establish that the text fits. For a canvas UI, use the engine's text and container bounds and retain a visual capture; DOM text measurements may not represent the canvas renderer.

The engineer should record what ran, what failed, and what was not checked. “All locales fixed” is too broad if only English and German were exercised.

Keep the limits visible

Pseudo-localization helps expose constrained layouts, but it does not certify grammar, right-to-left behavior, or cultural suitability. This example does not supply a real failing build or screenshot. Treat it as a reusable handoff recipe and replace the evidence fields when applying it to your game.

The final acceptance decision belongs to the named reviewers. A clean diff and a plausible screenshot are inputs to that decision, not substitutes for it.