UI Localization Review: Prepare Strings, Context and Layout for Translation

A translator receives the word “Label” without a screenshot. Does it mean a shipping document, a field name or an action that assigns a category? A designer receives the translated button text without its error state. The text fits the default screen, but the customer still cannot understand what to do when the document is unavailable.

A UI localization review connects those fragments before they become a release problem. It gives language reviewers the meaning and context of each message, then checks the translated experience with the states and layout it will use. Prepare representative screens in Mockitt's UI design workspace so wording, controls and supporting information can be reviewed together.

This guide uses a fictional return portal for return R-406. Its example translations and screen variants illustrate the review process; a language specialist must approve the wording for an actual market. The prototype is a design reference, not an automatic translation system.

Define the flow and locales before collecting strings

Choose a complete customer task. For R-406, the customer opens an existing return and downloads its shipping label. Creating a return, calculating shipping charges and printing with a particular carrier are outside the example. Those boundaries prevent a simple download action from acquiring unsupported promises in translation.

Record the source-language version, target locale, relevant states and review owner. A language name alone may be insufficient when the product deliberately supports different regional terminology or formats. Identify the actual supported variants instead of assuming that one English or German version covers every market.

The example review covers the ready-to-download state and the state where the document cannot currently be retrieved. It also includes the return-list count message because that message introduces a different translation problem. Keep account settings, marketing emails and legal documents out of this review unless they are explicitly assigned.

Agree the source wording first. Resolve an unclear action or contradictory status in the source design rather than asking translators to interpret competing versions. The principles of clear and consistent UX writing still apply; localization adds context and language-specific decisions rather than replacing them.

Build a context record, not a list of isolated words

Give every message a stable identity and enough explanation to distinguish its purpose. The identity belongs to the content handoff; it need not appear in the customer's interface. Attach a screen reference that shows the surrounding heading, associated control and the state in which the message appears.

For the main R-406 action, a useful record is:

Message identity

return.label.download

Source message

Download return label

Meaning

Label means the shipping document for returning an item. It does not mean a text label or a category.

Action and state

The button downloads the existing document for the return currently displayed. It does not create a new return. It appears only when that document is available.

Context

Return R-406, with the heading Return shipping label. Include the ready-state screen and the unavailable-state reference.

Variables

The button has none. The return identifier appears in a separate heading; R-406 must stay unchanged.

Layout guidance

The full action must remain visible. The control may grow or wrap according to the agreed layout; do not replace an accurate translation with an unexplained abbreviation merely to fit a fixed width.

Review status

Translation proposed; language review pending; design layout reviewed separately.

This record prevents two common mistakes: translating a word without knowing its role and treating a successful layout check as approval of the language. A screenshot helps, but a short written explanation is still needed when the action's consequence is not visible in that screenshot.

Provide terminology decisions with reasons. If “return” consistently means a merchandise-return request, say so and identify any context where the word means something else. Reuse an approved translation only when the meaning is genuinely shared; matching English text does not guarantee that two messages serve the same role.

Keep messages complete when variables and counts change

Do not hand off a sentence as separately translated fragments such as “Your return,” the identifier and “is ready.” Give the translator the complete message with a named placeholder and an explanation that the placeholder is a return identifier. The language may require a different word order.

W3C's internationalization guidance highlights the problems created by composing sentences from separate strings. In this example, the team can specify the meaning “The label for return R-406 is available” without fixing the identifier's position in every language. Engineering should use its localization system's supported message format, rather than assemble the translated sentence from English-order pieces.

Counts need the same care. For the source interface, the return list might show “1 return” and “3 returns.” Do not deliver “return(s)” as the universal solution, or assume that every language chooses a form using the same two English cases. Unicode CLDR's plural guidance documents categories that vary by language; the localization system and reviewer need representative values for the supported locale.

Separate a zero-count product decision from plural grammar. An empty list might say “No returns yet” and offer an appropriate next action. That is a designed empty state, not evidence that every language has a grammatical zero category. Record which message the product selects and which grammatical forms that message needs.

Keep variables realistic and identifiable during review. R-406 is deliberately stable across these examples. Replacing it with an arbitrary short number in one locale could hide wrapping or direction problems and make reviewers compare different records.

Review the translated action in its actual context

Place the proposed translation in the real component treatment, using the intended font and surrounding content. The illustrative German action Rücksendeetikett herunterladen is longer than Download return label. Its purpose remains downloading the shipping document for R-406.

The illustrative R-406 screens preserve the return identifier and shipping-document meaning while the longer German action wraps inside a roomier control.

For the example, a two-line action is an explicit layout proposal. Review its line height, padding, reading order and relationship to the nearby heading. If the product's component rules require a different treatment, use an agreed wider or full-width action rather than silently clipping the words. A design review should resolve that rule, not leave each translation to improvise.

W3C's discussion of text size in translation explains why translated strings, compound words and script characteristics need flexible space. One universal expansion percentage is not a substitute for representative content. A short control can create a larger relative layout problem than a paragraph, even when both are translated correctly.

Inspect the actual rendered text: missing glyphs, unsuitable fallback fonts, clipped accents, unnatural line breaks and cramped multiline controls can survive a spellcheck. Keep interface text editable in the design instead of embedding it in a decorative image that must be recreated for every locale.

Use the wider and narrower screen variants to review the same task. The responsive layout rules should preserve the complete action and important return information as space changes. Do not make a translated variant appear tidy by removing content the source interface still provides.

Include recovery states and the direction of mixed content

In the unavailable-document state, the source message could say “We could not load the return label.” The designed recovery action is Try again, assuming the service actually supports retrying the same retrieval. Provide both messages and the state context together. A translator should not have to infer whether retrying downloads an existing document or submits a new return.

Do not claim “Downloaded” merely because the button was selected. Record which known event the implementation can confirm and use wording consistent with that event. Translation review can reveal a misleading source message, but the team still has to resolve the underlying behavior with engineering.

If a right-to-left locale is in scope, make it a separate review case. A screenshot mirrored horizontally is not a translated experience. Identifiers such as R-406, numbers, punctuation and embedded left-to-right content can require different handling from the surrounding paragraph. W3C's direction guidance distinguishes language from base text direction and explains why the working interface must handle both explicitly.

The English and German frames here do not validate an RTL locale. For an actual RTL release, obtain appropriate reviewed text, specify the intended reading order and ask engineering to verify mixed-direction content in the built interface. Keep the return identifier intact and check that it stays associated with the correct record.

Choose review cases that answer different questions

A compact review matrix is more useful than a large collection of almost identical translated screens. For this flow, use four named cases:

1. Available document: R-406 with the complete action in each supported locale. Review whether the wording describes the same document and consequence.
2. Long action at narrow width: the proposed German action in the actual control treatment. Review wrapping, glyphs and available space without changing the record or task.
3. Unavailable document: explanation plus the supported recovery action. Review whether the user can distinguish retrying retrieval from creating another return.
4. Return counts: the locale's necessary representative values, plus the product's empty-state message. Review complete message forms and their selection rules.

Add an RTL case, regional format or another state when it belongs to the release. Do not fill the matrix with every imaginable language while leaving the supported German action unreviewed. Each row should identify the screen version, locale, content status, reviewer and unresolved issue.

Pseudolocalization can help engineering expose structural problems before real translations arrive. Android's pseudolocale tools, for example, exercise expanded text and direction-related behavior. Those are development capabilities of the platform. Manually lengthening text in a Mockitt frame is a layout stress example; it does not detect hardcoded strings in the application or certify that every message is localizable.

Hand off the decisions and verify the built experience

Package the current source messages, context records, approved translations, representative screen states and layout decisions together. Keep the status of each language explicit. “Design checked” and “translation approved” are different statements, and neither one proves that the implemented product uses the right resource at runtime.

Assign the remaining work by responsibility. The language reviewer checks meaning, terminology and grammar in context. Design checks hierarchy, legibility and the intended component behavior. Engineering checks message selection, placeholders, fallback, direction and the supported download behavior. Product resolves ambiguities about what the service actually does.

Add these records to the design handoff package. When translations change after review, identify the affected messages and revisit their screens instead of accepting a new text file while leaving old screenshots marked approved.

In the built interface, repeat the named cases with the actual locale selected. Confirm that R-406 remains the same return, the complete action is visible, the unavailable state offers the agreed recovery, and count messages use the correct forms. The review is complete for that scope when the words, layout and behavior agree—not simply when every English string has a translated value.