Multilingual website translation glossary and handoff QA checklist

Most translation defects begin before a translator opens the file. Teams hand over incomplete source copy, hide strings inside designs, change English during translation, or omit the context needed to choose the correct term. The result is inconsistent language, clipped layouts, broken links, and pages that cannot target local search intent.

Treat localization as a release workflow shared by content, SEO, design, development, translation, and legal reviewers. A glossary controls recurring language; a structured handoff controls scope; rendered-route QA proves that the final website works.

• Do not start from screenshots, exported PDFs, or a list of URLs without field-level content.
• Separate translation defects from CMS mapping, layout, routing, and deployment defects.
• Assign one owner for source changes and one approver for each target locale.
• Keep page status visible: draft, source frozen, translating, reviewing, implemented, QA passed, or published.

Write a locale brief before estimating words. A language code alone does not describe a market. English for the United States and English for Singapore may use different offers, proof, units, legal text, and contact routes. Record whether each locale is a direct translation, a market adaptation, or an independent page.

Build a URL inventory from the real sitemap and CMS, then assign a source page, target route, canonical policy, hreflang partner, content owner, translator, reviewer, and publish decision. Exclude obsolete or duplicate URLs before they create unnecessary translation cost.

• Locale and market: language, region, currency, units, time zone, and regulatory scope.
• Route rule: subdirectory, subdomain, domain, locale switcher behavior, and fallback behavior.
• Page decision: translate, adapt, consolidate, redirect, keep untranslated, or exclude from indexing.
• Approval chain: source owner, subject expert, local reviewer, legal reviewer, and publisher.
• Service availability: verify that every localized promise and CTA can be fulfilled in that market.

A useful glossary is a decision log, not a two-column word list. Add enough context to distinguish product names, service terminology, interface verbs, SEO phrases, and regulated claims. Review it with local subject experts before bulk translation begins.

Give every term a stable ID so feedback can be resolved without ambiguity. When a term changes, record the date, owner, affected locales, and pages that require an update. Keep official brand names separate from generic product language.

• Source term, approved translation, locale, definition, part of speech, and capitalization rule.
• Do-not-use variants, common mistranslations, and words that must remain untranslated.
• Context sentence, screenshot or component reference, character limit, and grammar notes.
• SEO target term, natural-language alternative, and guidance on when exact phrasing is inappropriate.
• Status, approver, approval date, change reason, and affected content IDs.

Translation should start from an approved source snapshot. Freeze the source version, export all translatable fields, and keep stable identifiers for pages, sections, components, and strings. If urgent source changes are allowed, record them in a delta log rather than silently replacing the handoff file.

Package content in a structured format that can return to the CMS without manual reordering. Include field names, content type, component name, URL, context, character guidance, and whether markup or variables must be preserved.

• Include navigation, footer, cookie banner, forms, errors, emails, search states, and empty states.
• Include title tags, meta descriptions, social fields, image alt text, captions, and structured-data copy.
• Protect placeholders, Liquid or template variables, HTML, Markdown, SKU values, and tracking parameters.
• Flag text embedded in images or video and replace it with editable or separately localized assets.
• Publish a source-change cutoff plus an escalation path for legal, pricing, or product corrections.

Before importing translated copy, document how locale entries relate in the CMS. Each equivalent page needs a shared translation key or relation, while market-only pages need an explicit fallback and indexing decision. Never infer relationships from similar titles.

Test one representative page with every field and component before importing the full batch. This reveals character limits, unsupported rich text, broken references, missing locale fields, and components that still read from the default language.

• Map title, slug, navigation label, headings, body, CTA, metadata, alt text, and related content fields.
• Decide whether slugs are translated and preserve old public URLs with redirects when they change.
• Connect equivalent pages for hreflang and prevent default-locale canonicals from overriding local pages.
• Resolve locale-specific internal links rather than copying source-language destinations.
• Keep untranslated mandatory fields from silently falling back on published pages.

Search demand does not translate word for word. Validate the local term set, SERP intent, buyer vocabulary, and level of brand awareness before approving metadata and headings. The best glossary term for product consistency may differ from the phrase people use when searching, so document how both should appear naturally.

Localize the path after the click as carefully as the landing page. Forms, calendars, phone links, privacy text, thank-you pages, CRM routing, and response expectations must work for the target market. A translated CTA that leads to an unavailable service is a content and operational defect.

• Research local primary and supporting queries; do not mechanically translate keyword lists.
• Write unique title tags and descriptions within realistic pixel and character constraints.
• Check local examples, proof, currencies, units, date formats, addresses, and trust signals.
• Route forms and leads to the right team, language, consent record, and follow-up sequence.
• Use locale-specific related posts and services to build useful internal-link clusters.

Review the content in the rendered website, not only in a spreadsheet or translation tool. Linguistic reviewers need real layout and navigation context; developers need reproducible defects tied to routes, viewports, components, and content IDs.

Test representative templates first, then every high-value and indexable URL. Record expected versus actual behavior, severity, owner, and retest status. Keep language corrections separate from engineering bugs so each can reach the right person quickly.

• Linguistic: terminology, grammar, tone, omissions, truncation, line breaks, and mixed-language fragments.
• Functional: switcher, navigation, search, filters, forms, validation, downloads, checkout, and emails.
• SEO: status code, indexability, canonical, hreflang, metadata, headings, sitemap, and structured data.
• Visual: mobile and desktop layout, long strings, buttons, tables, RTL behavior where relevant, and font coverage.
• Analytics: locale value, consent, CTA events, form success, ecommerce events, and campaign parameters.