# A correct translation still produces a broken screenshot

Companion to /learn/localization/quality-assurance/

## Outcome
Run a release review that catches language, product, layout and configuration failures.

Fictional example, not a client result.

## Scenario
FocusDesk is a fictional productivity app preparing a German listing. The translated caption is accurate, but it wraps across the important part of the product screen. A second image displays an English interface, and the localized description refers to a feature that is not yet released. A spellcheck would miss most of the launch risk.

## Reasoning
Review localization in layers: language meaning, product truth, visual execution and publishing configuration. Give each layer an owner. Native review should inspect the final asset in context, not only an isolated text sheet. Product review should compare the promise with the version users can actually access. Release review should check what became visible in the store.

## Action
Shorten the caption with the native reviewer rather than shrinking it until unreadable. Replace or accurately frame the English screen, and remove the unreleased feature claim. Recheck the assembled listing after changes. Save the approved package and final publication evidence; approval of a spreadsheet is not approval of an asset that was subsequently edited.

## Trap to avoid
Do not use an overall “approved” checkbox to hide unresolved defects. Separate blockers from optional improvements, name the owner and record the final resolution. A feature claim that is false needs a different response from a minor stylistic preference.

## Advanced considerations
For repeated releases, sample low-risk unchanged assets only after establishing a reliable inventory and change record. Re-review changed claims, new product screens and high-risk messages directly. Automation can catch missing files or dimensions, but it cannot replace a competent review of whether a localized promise is meaningful and true.

## Exercise
A designer changes a native-reviewed caption to fit the image. Is the previous language approval still sufficient?

## Suggested answer
No. Send the changed caption back for review in its final layout. Small edits can alter meaning or naturalness. Version the approval so everyone can see which exact asset was accepted.

## Your worksheet

### Locale, release version and asset inventory
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Native language reviewer and findings
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Product-claim verification
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Readability and screenshot consistency
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Final configuration and publication check
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Unresolved blockers and signed-off version
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

## A defect register for the FocusDesk release
This fictional register turns the German-listing scenario into concrete decisions. A status of closed requires evidence of the fix and re-review. Checklist completion alone cannot override an unresolved misleading claim or unreadable asset.

Illustrative release defects and closure evidence. These are not observed client incidents.
Defect and consequence | Owner and correction | Closure evidence
DE-01: caption obscures key product information | Designer and native reviewer shorten the caption together | Final exported image reviewed at realistic viewing size
DE-02: screenshot shows an unexpected interface language | Product owner confirms available UI; designer replaces or accurately contextualises image | Asset and available product language checked together
DE-03: description promises an unreleased feature | Product owner and writer remove the unsupported claim | Revised final copy approved against the available version
DE-04: late caption edit after language approval | Publisher holds the affected asset for renewed native review | Approval references the exact revised file
DE-05: live listing differs from approved package | Publisher compares upload configuration and visible listing | Dated observation confirms the intended locale and version

### Define the unit of approval
Record an identifiable version for source copy, localized copy and exported images. A practical release manifest lists each asset, locale, version, reviewer and decision. When one caption changes, reopen the affected language and layout checks. Do not assume every unchanged asset needs a new full review, but verify that a shared source change has not affected it.

### Separate blockers from discretionary improvements
A false feature claim or unreadable essential message should be resolved before promotion. A minor stylistic preference can be recorded for later when it does not alter meaning or usability. State the consequence and acceptance criterion for each issue so severity is not decided by whoever argues most strongly in the review meeting.

### Close the release with a live comparison
After publication, inspect the intended context and compare the visible version with the approved manifest. Record the date, locale and relevant device/storefront information. If the result differs, investigate configuration and display context before rewriting the translation. Keep a correction owner and document any fallback decision; do not call the release verified merely because files were uploaded successfully.

## Continue reading
- /learn/localization/screenshot-adaptation/
- /learn/localization/strategy/
- /learn/measurement/metadata-change-log/