Localization and Multilingual Content

Bilingual Quality Assurance

Compare source and target content for omissions, additions, meaning shifts, terminology, numbers, variables, functional consequences, and verified corrections.

Free editable Markdown · Bilingual reviewers, localization managers, and quality teams · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

QA setup

Asset and content type: [Title, page, product flow, document, or media]
Source locale and version: [Locale and exact version]
Target locale and version: [Locale and exact version]
Comparison scope: [Included and excluded sections]
Audience and task: [Who relies on the content and why]
Risk level and reason: [Low, medium, high, or critical]
Translator: [Name or provider]
Bilingual reviewer and qualifications: [Enter]
Subject owner: [Name or team]
Review date and release target: [Dates]
Authorized adaptation reference: [Brief or decision record]

Segment comparison

Segment or component ID: [Stable location]
Source text: [Exact text]
Target text: [Exact text]
Source meaning: [Actor, action, object, condition, timing, and outcome]
Required context: [Screenshot, prior state, term, or evidence]
Comparison result: [Pass, question, or defect]
Preserved adaptation: [If non-literal, explain approved function]
Defect category: [Omission, addition, mistranslation, term, number, token, or other]
User consequence: [What could be misunderstood or fail]
Severity: [Blocker, high, medium, or low with reason]
Proposed correction: [Enter]
Correction owner: [Translator, source owner, product owner, or other]

Systematic transfer checks

All headings, paragraphs, lists, controls, captions, notes, and alternatives are represented.
Actors, actions, negation, conditions, exceptions, scope, and certainty remain equivalent.
Product and subject terminology follows the approved concept entries.
Names, dates, times, numbers, percentages, currencies, units, and ranges match.
Quotations, citations, links, attributions, and disclosures remain connected correctly.
Variables, placeholders, plurals, gender behavior, code, and protected syntax are intact.
Cross-references, table relationships, sequence, and pronoun references remain clear.
Authorized adaptations preserve function without inventing claims or removing limits.

Resolution and signoff

Source defect escalation: [Question, owner, answer, and affected segments]
Corrected target: [Exact final text or version]
Retest evidence: [Build, file, screenshot, or notes]
Nearby-content regression check: [Result]
Open issues for functional/cultural review: [List]
Bilingual QA decision: [Pass, conditional pass, or fail]
Reviewer and date: [Name and YYYY-MM-DD]
Final release owner: [Name or team]

How to use this template

Record the locked source and target versions, locale pair, asset scope, reviewer qualifications, and risk.
Compare each unit for preserved actors, actions, facts, conditions, scope, certainty, sequence, and intended result.
Run separate high-risk passes for terminology, numbers, names, links, variables, disclosures, and non-body content.
Log source or target defects with category, severity, user impact, correction owner, and required escalation.
Recompare corrected content in context, record evidence and approval, and hand remaining functional issues to the wider review.

Compare meaning in manageable units

Choose a comparison unit appropriate to the asset: sentence, interface component, subtitle segment, table row, or connected group of strings. Read the source for proposition, actor, action, object, condition, time, scope, certainty, and intended result before judging the target. Check for information that disappeared, appeared without support, moved into the wrong relationship, or became more or less certain. Pay close attention to negation, exceptions, comparisons, pronoun reference, causal wording, sequence, and modal verbs. Do not assume a target is accurate because it contains recognizable equivalents for the source words.

Trace high-risk details systematically

Create dedicated passes for names, product terms, numbers, dates, currencies, units, ranges, links, quotations, citations, variables, placeholders, code, and required disclosures. Compare headings, captions, footnotes, alternative text, metadata, and error states, not only body paragraphs. Use the translation context packet to understand ambiguous short strings and rendered values. When adaptation is authorized, record the preserved function and approval instead of incorrectly labeling every non-literal choice as an error. Conversely, fluent creative wording must be corrected when it strengthens a claim, hides a limitation, or changes what the user can expect.

Classify, correct, and verify

Describe defects neutrally with source and target evidence plus the likely user consequence. Classify omission, addition, mistranslation, terminology, consistency, number, token, style affecting meaning, or source defect. Severity should reflect impact and reach: a reversed safety instruction is not equivalent to a minor punctuation issue. Assign a correction owner and keep the original finding visible. The bilingual reviewer should retest the corrected segment in the assembled asset and confirm that the fix did not introduce a new error nearby. Escalate unclear source meaning rather than quietly repairing the target alone.

See the fields in context

Fictional example: data export notice

Quarry Finch is an invented analytics service. Its export behavior and messages are illustrative.

Source meaning: A fictional export link remains available for seven days after the notification is sent.
Target defect: The target says the export itself is deleted after seven days, changing what the time limit applies to.
Impact: Users may believe their underlying fictional data will disappear, so the issue is classified high severity.
Correction: The reviewer restores “download link,” verifies the numeral and time unit, and checks the connected button label.
Retest: Source and corrected target are compared in the final email preview before bilingual QA passes the segment.

Frequently asked questions

Is bilingual QA the same as proofreading?

No. Proofreading checks the target for surface errors. Bilingual QA compares source and target meaning, including omissions, additions, altered relationships, and transferred details.

Must every non-literal translation be reported as a defect?

No. Natural, authorized adaptation can preserve meaning better than literal wording. Record the rationale when it is consequential, and report only changes that violate required meaning or boundaries.

What if the source itself is unclear?

Open a source defect with an owner. Do not guess, and do not silently improve only one locale because that can create inconsistent product behavior or claims.

Does a bilingual pass approve the release?

Not by itself. The complete asset may still need linguistic, functional, visual, cultural, accessibility, subject, legal, or live-environment checks.