Translation Quality Assurance

Common checks

• missing translations
• English leakage
• reader-facing localization completeness
• structural parity against fresh generated output
• native-language readability and natural expression
• placeholder mismatches
• broken links
• glossary drift
• accessibility text coverage
• screenshot and diagram parity

Freshly generated output requirement

Before structural parity review, semantic review, or manual article comparison:

1. regenerate the site from the current repository state
2. run validators against the current generated output
3. inspect generated HTML artifacts
4. only then perform manual parity assessment

This rule exists because source Markdown and generated output can temporarily diverge during development, and QA findings should be based on current artifacts rather than stale generated files.

Structural parity review

Structural parity review should look for loss of reader value even when the localized article still broadly preserves meaning.

Typical signals include:

• missing major sections
• collapsed heading hierarchy
• missing examples
• compressed practical guidance
• reduced governance discussion
• shortened review or validation guidance

Warnings from structural parity validators are review prompts, not automatic proof of a bad translation. They should be interpreted together with the generated HTML and, where needed, browser-rendered output.

Native-language expression review

Translation QA should also look for text that is technically correct but not what a native speaker would naturally choose.

This includes:

• direct English sentence structure
• direct translation of English idioms
• wording that sounds translated rather than authored
• terminology that still reveals the source language

Examples of the pattern include phrases equivalent to:

• candidate content
• validation strategy
• workflow artifact
• curated tools
• curated skills

These are not always translation errors. They are often cases where a native speaker would instinctively rewrite the sentence.

Native-speaker preference test

For important prose sections, reviewers should ask:

If a competent native speaker were writing this idea from scratch, would they likely write it this way?

If not, reviewers should:

• preserve the meaning
• preserve semantic parity
• preserve structural parity
• improve the phrasing

This test is especially useful for:

• introductions
• summaries
• educational explanations
• practical guidance
• governance discussions
• conclusions

Natural expression review

Treat technically correct but unnatural wording as a quality issue.

Reviewers should prefer wording that sounds naturally authored in the target language, even when the original translation is understandable.

The goal is not only a correct translation. The goal is a document that feels as though it had originally been written for native readers.

Natural-language improvements must not weaken:

• semantic parity
• structural parity
• educational coverage
• examples
• practical guidance
• governance guidance

Reader-facing localization validator

One validator class should explicitly fail CI when a page appears localized but still exposes source-language reader-facing content.

Examples that should fail:

• localized title with English summary
• localized article with English tags
• localized article with English headings or lists
• localized article with English callouts or captions
• localized article with English diagram labels or alt text
• mixed-language related-content cards

This is a fail condition, not merely a warning, because readers experience such pages as visibly unfinished.

Defect-class audit

Translation QA should maintain explicit defect classes with:

• description
• occurrence count
• root cause
• validator coverage
• recurrence risk
• closure plan

Required categories include:

• untranslated summaries
• untranslated bodies
• placeholder draft publishing
• untranslated metadata
• mixed-language publishing
• future discovered classes

A class is closed only when its count reaches zero and CI prevents it from returning without failure.

Human review evidence

Translation QA should also preserve short human review records for representative AI-assisted corrections.

Minimum fields:

• original text
• corrected text
• error category
• root-cause hypothesis
• reviewer rationale

Native-speaker review findings should be preserved as a growing corpus, not as isolated one-off notes. Repeated findings should feed back into validator design, contributor guidance, and future AI-agent instructions.

Before signing off on an AI-assisted translation, reviewers should:

• read relevant entries from the structured findings corpus for that language or topic
• check for recurring defect patterns from human review
• confirm that the current draft does not reintroduce known issues before signoff

Every reported native-speaker defect should also be evaluated for:

• content correction
• review-guidance update
• terminology-guidance update
• prompt improvement
• validator opportunity
• regression-test opportunity

This matters because even when the overall meaning is preserved, AI-generated translations may require native-speaker review to correct subtle issues in grammar, modality, terminology, and domain-specific register. These issues are often difficult to detect through automated quality metrics alone.

Concrete reported errors are not advisory-only. Each one should end up fixed, systematized, intentionally unresolved with justification, or still explicitly tracked in the findings corpus.

Common AI translation error taxonomy

• grammar
• modality
• terminology
• register
• fluency
• literal translation
• ambiguity
• context loss
• word order
• collocation
• script or orthography
• domain-policy phrasing
• accessibility wording

Lightweight benchmark scoring

For repeatable AI-translation evaluation, use a lightweight 0-3 rubric instead of relying only on pass/fail judgment.

Recommended dimensions:

• meaning accuracy
• grammar and fluency
• terminology and domain fit
• register and style
• review effort

Recommended release labels:

• blocker
• major revision
• minor revision
• ready with review signoff

This creates scorecard-friendly data without requiring a heavyweight localization-measurement framework.