Localization and Multilingual Content

Multilingual Review Checklist

Review a localized asset for preserved meaning, natural language, approved terminology, locale conventions, layout, links, accessibility, and release readiness.

Free editable Markdown · Localization reviewers, editors, and translators · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Review setup

Asset and version: [Title, URL or file, commit, or release]
Source locale and version: [Enter]
Target locale and language variety: [Enter]
Audience and task: [Who uses it and what they must do]
Content type and risk: [Marketing, help, product, policy, or another]
Source owner: [Name or team]
Translator: [Name or provider]
Linguistic reviewer: [Name and qualifications]
Subject or product reviewer: [Name]
Release owner and date: [Name and target]

Meaning and language review

No required sentence, label, list item, caption, or note is omitted.
The target adds no unsupported fact, promise, instruction, or implication.
Negation, conditions, sequence, scope, certainty, and causation match the source.
Claims, names, numbers, quotations, and limitations remain accurate.
Approved terminology is used consistently and in the correct grammatical form.
Register, formality, tone, spelling, punctuation, and word order fit the locale.
Idioms and examples are understandable without introducing a stereotype.
Unresolved source ambiguity is returned to the source owner instead of guessed.

Functional and locale review

Placeholders, variables, plurals, gender, code, and protected tokens render correctly.
Text fits controls and layouts at required screen sizes and zoom levels.
Reading order, headings, focus context, alternatives, captions, and transcripts work.
Dates, time zones, numbers, currencies, units, names, addresses, and ranges follow policy.
Links open the intended reviewed locale and retain necessary context.
Images, screenshots, audio, video, and downloadable files match the target language.
Metadata, structured data, language declarations, and locale navigation are accurate.
The complete task succeeds using realistic sample data.

Defect and decision record

Defect ID and location: [Enter]
Source and target excerpt: [Enter]
Category: [Meaning, terminology, fluency, locale, functional, visual, accessibility]
Severity: [Blocker, high, medium, low with user impact]
Correction and owner: [Enter]
Retest evidence: [Build, screenshot, URL, or notes]
Status: [Open, fixed, accepted risk, deferred]
Final decision: [Approve, approve with recorded follow-up, or hold]
Approver and date: [Name and YYYY-MM-DD]
Live verification: [URL, date, and result]

How to use this template

Record the exact source version, target locale, asset scope, audience, owners, and release criteria.
Compare meaning first, then review fluency, terminology, tone, grammar, and locale conventions.
Test the complete rendered experience, including variables, layout, media, links, accessibility, and metadata.
Log every defect with impact, evidence, correction owner, deadline, and required review level.
Retest corrections, record approval or a safe hold, and verify the live localized asset after release.

Separate meaning, language, and functional passes

Begin by confirming that the target contains the same required information, relationships, level of certainty, and action as the locked source. Look specifically for omissions, additions, reversed conditions, altered scope, false causation, and softened limitations. Then assess whether the target is natural for the defined audience and follows approved terminology, register, grammar, spelling, and punctuation. A sentence can be accurate but awkward, or fluent but wrong. Keeping these passes distinct helps reviewers explain defects and prevents stylistic preferences from hiding material meaning errors.

Inspect the content where people will use it

Open the localized page, email, product state, document, or media asset rather than reviewing strings alone. Check headings, reading order, controls, error recovery, text expansion, line breaks, clipping, bidirectional behavior, subtitles, alternatives, and localized destinations. Render sample placeholders and plural forms with realistic values. Verify names, dates, times, time zones, currencies, units, decimal separators, ranges, and telephone or address formats. Confirm that search metadata, structured data, downloads, screenshots, and linked help are in the same reviewed locale rather than silently falling back to source text.

Triage defects by user impact

Record each issue with location, source and target excerpts, category, severity, proposed correction, owner, and retest evidence. A mistranslated safety condition or broken payment action should block release; a minor preference may wait for a planned revision. Do not close a defect merely because an updated file was delivered. The assigned reviewer should verify the corrected rendered experience against the same source version. If reviewers disagree, preserve the rationale and escalate material risk. Publish only locale variants with complete approval, and use explicit safe staging for unfinished locales.

See the fields in context

Fictional example: appointment reminder

North Window Clinic is invented, and the appointment flow below does not describe real medical guidance.

Meaning defect: A target message omits “local time,” making the fictional appointment hour ambiguous for travelers.
Functional defect: A localized reschedule button is clipped at 200% zoom, while its link opens an English destination.
Correction: The reviewer restores the time-zone cue, the interface owner expands the control, and the link points to a reviewed target page.
Retest: A bilingual reviewer checks meaning and a QA reviewer completes the rendered flow with a sample appointment.
Decision: Release remains on hold until both defects are verified in the deployment candidate.

Frequently asked questions

Is this checklist a substitute for bilingual QA?

No. It coordinates the wider review. Bilingual QA provides a detailed source-to-target comparison, while this checklist also covers natural language, locale formats, visual rendering, links, accessibility, and release.

Can the translator review their own work?

Self-review is useful, but independent review is stronger for important content because familiarity can hide omissions and assumptions. Match independence and expertise to risk.

Should every stylistic disagreement block release?

No. Classify user impact. Meaning, safety, legal, task, or functional defects may block release; a defensible non-material preference can be documented for later resolution.

When is review complete?

When corrections are retested against the locked source, a named owner approves the locale, and the intended live experience is verified—not when a translation file is first delivered.