Freeze the approved source, define terminology, review meaning and consequential instructions with a qualified target-language reader, then test the complete translated journey. Fluency alone is insufficient.
A good AI-assisted translation preserves what the website means, not merely its general tone. Begin with an approved source version, supply a terminology list, and arrange a competent target-language review of claims, conditions and instructions. Then inspect the complete page and the connected journey in that language.
This guide focuses on editorial quality. Choosing a multilingual plugin, URL architecture or browser-translation control is a separate implementation decision. A site can have correctly linked language pages and still give customers the wrong information.
Freeze the source and define the audience
Record which version is being translated and which country or language community the page serves. Correct unclear source wording before translation. Ambiguity in the original becomes harder to diagnose when several language versions interpret it differently.
Identify what the reader must understand or do: compare a package, submit an enquiry, follow setup instructions or decide whether delivery is available. The level of review should follow the consequences of misunderstanding. A casual blog introduction and an important product warning should not receive identical treatment merely because both are text fields.
The NIST Generative AI Profile describes risks from erroneous generated output. Treat an AI translation as a draft requiring verification, even when it reads smoothly to someone who cannot assess the target language.
Create a terminology list that explains the context
List product names, plan labels, technical terms, service names and phrases with a specific business meaning. Include approved translations where they exist, terms that must remain exact, and a short explanation of each ambiguous concept. A glossary containing only isolated word pairs is less useful than one showing how the term is used.
| Source item | Review rule | Reason |
|---|---|---|
| Plan or product name | Use the approved brand form | Preserve identity |
| Technical identifier | Keep exact characters where required | Avoid changing the referenced item |
| Billing term | Explain the actual commitment | Prevent a monthly equivalent implying monthly payment |
| Warning or exclusion | Review meaning in the whole sentence | Negation can change the action |
For a fictional subscription service, distinguish “billed annually” from “per year equivalent”. The translator needs to understand the actual billing arrangement before selecting wording. Do not ask the tool to make an uncertain commercial term sound natural without resolving what it means.
Compare meaning before polishing style
Review the original and target text side by side. Check additions, omissions, numbers, units, comparisons, conditions and negation. Ask the reviewer to explain any substantive departure from the source. A stylistic preference can be accepted; a changed promise needs the business owner’s decision.
W3C’s Internationalization Tag Set includes localisation quality issue categories. A small publisher need not implement its markup to benefit from separating error types such as terminology, omission and mistranslation in a review log.
Give each issue a location, explanation, correction and severity. “Sounds odd” is less actionable than “this sentence makes setup mandatory when the source says optional”. Keep these comments separate from the public content so internal uncertainty does not accidentally become the customer-facing answer.
A worked review of a service page
Imagine a source page stating: “The review includes recommendations, not implementation. A follow-up meeting is optional.” An initial draft reverses the first qualification and makes the meeting part of every package. It can be grammatically excellent while describing a different service.
The reviewer should restore the scope, check the same wording in pricing cards and inspect the request form. If the translated button invites the reader to buy implementation, correcting the paragraph alone does not repair the journey. Review the promise across all the places where it is repeated.
Next check an illustrative deadline such as “within two business days after we receive the final materials”. A translation that removes the starting condition changes expectations. The important task is preserving the trigger and type of day, not simply retaining the numeral two.
Review numbers and local conventions deliberately
Check currency, tax wording, decimal separators, dates, phone numbers, postal addresses and measurement units. Translation is not currency conversion. A local-looking amount must still represent the approved offer, and an automatically reformatted date must remain unambiguous to the intended audience.
W3C’s internationalisation tips address language declarations, local formats and text expansion. Apply those checks to the published page: longer translated labels can wrap badly, disappear from buttons or become difficult to compare on a narrow screen.
Review screenshots and diagrams too. Embedded source-language labels may contradict translated instructions. Where an image is kept in the original language for accuracy, explain the necessary terms in the surrounding text. Do not recreate a branded screenshot with invented interface wording.
Use a reviewer who can judge the subject
A target-language reader should be able to assess both natural phrasing and the relevant subject matter. Ask a specialist to review consequential technical, legal or safety wording where appropriate. General bilingual fluency alone does not establish competence to approve every type of instruction.
Back-translation can help expose differences, but it is another generated interpretation rather than proof of accuracy. Two tools agreeing can share the same mistake. Resolve disputed meaning against the approved source, business process and qualified review.
Do not publish a consequential language version simply because no reviewer is available. Narrow the scope, obtain suitable help or provide a clear alternative route. The review requirement follows the actual risks of the content, not a desire to make every language selector look complete.
Test the complete language journey
Open the page in the intended language on a phone and desktop. Follow internal links, forms, errors, confirmations and any important policy destinations. Record where the journey unexpectedly returns to another language or presents an untranslated term essential to completion.
Check that headings, lists and tables retain their meaning and that the selected language is understandable in navigation. For right-to-left content, use appropriate implementation review rather than assuming that changing text alignment is sufficient. Editorial approval and technical language support are connected checks.
Keep the source version, reviewer and date with the translated record. When the original changes, mark affected translations for review rather than silently leaving old terms live. A maintained translation process is more valuable than an impressive launch count that becomes inconsistent the next time pricing or scope changes.
Continue with the relevant checks
Separate editorial translation from interface-string architecture. Distinguish a maintained edition from browser translation. Verify links and language signals after editorial approval.
Sources and verification
Editorial review 2026-10-18. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- NIST Generative AI ProfileChecked Generated output can be erroneous despite fluent presentation.
Limits: Not a translation benchmark. - W3C ITS 2.0 localisation qualityChecked Quality issue categories for localisation assessment.
Limits: Does not certify the proposed editorial workflow. - W3C internationalisation tipsChecked Language, formatting and text expansion considerations.
Limits: Introductory guidance, not a complete multilingual implementation specification.