Website localization review

Run an evidence-based smoke test before releasing a target locale. Record the build, critical task and owner; mark failures; then download the release record.

INPUTBuild, locale, critical task, tester

ACTIONRun the smoke test and evidence every failure

OUTPUTDownloadable release acceptance record

Use for a new language or market version of a website, store or web app. The 45-minute smoke test finds release blockers; it does not replace full functional, security, payment, legal or accessibility testing.

1. Define this test

Target locale and marketTest URL or buildCritical user taskTester / ownerTest date

2. Run the 45-minute smoke test

Language and URL foundation1. The root element declares the correct language, for example html lang="en"2. The language switch opens a stable locale URL; refresh and sharing do not lose the locale3. Indexable versions self-canonicalise; hreflang is reciprocal and uses valid language codes4. There is no accidental noindex, sign-in wall, redirect loop or 4xx/5xx response5. Missing translations have a defined fallback; no blank controls, raw keys or mixed-language fragments appearFailures in this group: evidence, severity, owner, retest date

Content, formats and product data6. Product name, model, specifications, variants and images match the version sold7. Dates, times, numbers, decimals, grouping, currency and units follow target-market conventions8. Price, tax, discount, shipping and final payable amount stay consistent through the journey9. Terms, controls and errors use one vocabulary; literal translation does not make the task ambiguous10. Legal notices, returns policy, contact details and service scope apply to the target marketFailures in this group: evidence, severity, owner, retest date

Layout, input and accessibility11. At 390px mobile and desktop widths, headings, controls, tables and prices do not clip or overlap12. After text expansion, navigation, dialogs, forms and verification remain usable13. Keyboard, IME, paste and autofill work; name, phone, postcode and address accept local formats14. Fonts contain required characters with no tofu or substitutions; direction is correct where needed15. Form labels, errors, focus order and control names are understandable to assistive technologyFailures in this group: evidence, severity, owner, retest date

Critical conversion journey16. Search, filters, categories and internal links lead to the correct content or product17. Registration, sign-in, verification and password reset complete end to end18. Cart, address, shipping, promotion, tax and payment complete one realistic test task19. No-result, out-of-stock, payment and form errors give a recoverable next step in the target language20. Confirmation, email, SMS, order status, cancellation, refund and support use the same language and order factsFailures in this group: evidence, severity, owner, retest date

Measurement and hand-off21. Page view, search, add-to-cart, checkout and success events are neither lost nor duplicated in the new locale22. Analytics does not collect passwords, full payment details or unnecessary personal data23. Every failed item has evidence, severity, an owner and a retest date24. The target-language support or operations owner confirms readiness to receive and handle real issuesFailures in this group: evidence, severity, owner, retest date

3. Make the release decision

BLOCK RELEASE

Critical task cannot complete; price, tax or currency is wrong; privacy or consent fails; transactional messages use the wrong language; an indexable page has noindex or the wrong canonical.

FIX BEFORE RELEASE

Untranslated content, clipped controls, invalid local formats, unusable errors or missing accessible names.

TRACK

Wording or visual details that do not prevent task completion may enter a later release with an owner and target date.

Final decision, open issues and approver

Entries are not uploaded automatically. Download your record, or explicitly save it to a private project after signing in.

Save this work record

Record titleSources & evidence notes Sign in and create a project to save →

How to use this checklist

Choose one real critical task and prepare a safe test account, product and payment environment.
After smoke testing passes, complete browser, device, payment, accessibility, security and legal regression based on product risk.
After release, use real monitoring for errors, conversion breaks and support feedback; no checklist replaces production monitoring.

Primary references

Continue the workflow

Plan the localisation journey →Standardise product data first →Check fulfilment ownership →