Guides Full-store QA

Field guide 01

WooCommerce Multilingual Store QA Checklist: Products, Cart, Checkout, and Emails

A multilingual WooCommerce store is not ready merely because its product descriptions have been translated. Use this checklist to test the complete buying journey in every supported language.

How to use this checklist

Customers move through navigation, search, product selection, cart, checkout, payment, shipping, account pages, and transactional emails. Each step can behave differently by language.

Use this checklist before launch, after a translation project, after a major catalog import, and whenever WooCommerce, Polylang, the theme, payment gateways, or other critical extensions are updated.

For the most reliable result, repeat the journey in every supported language, on both desktop and mobile, using a staging environment that closely matches production.

1. Prepare a safe test environment

  • Create a current backup. Include the database and the wp-content files. Confirm that you know how the backup would be restored.
  • Use staging. Test updates and important workflows on a staging copy before customers are affected.
  • Match production closely. Use the same WooCommerce, Polylang, theme, gateway, shipping, tax, caching, and multilingual extension versions whenever possible.
  • Protect real data. Use test customers and test payment modes. Do not publish screenshots that expose orders, addresses, API keys, or commercially sensitive prices.
  • Write down the test matrix. List every supported language, currency, market, customer role, device type, payment method, and shipping region that materially changes the buying experience.

2. Verify language architecture

  • Language assignment: Every product, category, tag, global attribute, required page, menu, and relevant media item has the intended language.
  • Translation relationships: Each translated item points to the correct counterparts and the relationship works in both directions.
  • Language switcher: It is visible where intended, uses clear labels, preserves context, and does not route users to unrelated or missing pages.
  • Fallback behavior: The team understands what happens when content does not exist in a language and has accepted that behavior.
  • URL structure: Language paths, domains, or parameters are consistent, indexable where intended, and free from avoidable redirect loops or 404 responses.

3. Audit the product catalog

  • Coverage: Every product has the translations required for the markets in which it should be sold.
  • Publication status: Translated products are published, visible, and included or excluded from the catalog intentionally.
  • Core content: Product name, full description, short description, purchase notes, and theme-specific fields are complete and current.
  • Taxonomies: Products use the correct translated categories and tags, and archive pages show the expected items.
  • Related products: Upsells, cross-sells, grouped products, and related-product sections lead to the appropriate language versions.
  • Freshness: Source changes have been reviewed in translations; outdated claims, specifications, and promotion dates have been corrected.

4. Check attributes and variations

  • Global attribute translations: Attribute names and terms are translated before they are used in multilingual products.
  • Equivalent choices: Translated parents contain the intended colors, sizes, materials, or other options.
  • Variation combinations: Every valid combination has the expected translated counterpart; there are no unexplained missing or duplicate combinations.
  • Commercial fields: Enabled status, prices, sales, SKU behavior, stock, tax, weight, dimensions, shipping class, and download settings follow the store’s synchronization model.
  • Defaults and images: Default selections resolve to purchasable variations, and option-specific images match the selected term and language.
  • Front-end behavior: Selecting options updates the price, image, availability, and add-to-cart state correctly.

5. Review media and visual content

  • Featured and gallery images: The intended images appear in each language and do not contain untranslated embedded text.
  • Alternative text: Meaningful product images have appropriate alt text for the language and context; decorative images are handled appropriately.
  • Video and documents: Captions, audio, manuals, size charts, safety sheets, and downloadable files are available in the correct language where required.
  • Media strategy: The team has deliberately chosen whether to translate media metadata or use separate files for language-specific artwork.

6. Test navigation, search, and discovery

  • Menus and links: Header, footer, mobile, account, and campaign links stay in the chosen language.
  • Search: Translated product names, SKUs where relevant, and common local terms return useful results.
  • Filters: Category, price, stock, rating, and attribute filters use translated labels and return valid products.
  • Breadcrumbs: Labels and destinations match the current language and taxonomy hierarchy.
  • Empty states: No-results messages, unavailable-product notices, and validation errors are translated and helpful.

7. Test product-to-cart behavior

  • Simple products: Price, sale state, stock, quantity limits, and add-to-cart behavior are correct.
  • Variable products: Representative combinations can be selected and added with the correct variation data.
  • Cart identity: Product names, attributes, images, prices, quantities, taxes, discounts, and links remain correct after adding an item.
  • Cart persistence: Changing pages or languages produces the behavior the business has chosen and does not silently replace, duplicate, or corrupt items.
  • Coupons and notices: Success, warning, and error messages are translated and the underlying rule works for the intended market.

8. Complete checkout in every language

  • Checkout fields: Labels, placeholders, required markers, validation messages, address formats, and consent text are correct.
  • Shipping: Methods, rates, pickup instructions, delivery estimates, and threshold messages are available and correctly translated for the test address.
  • Taxes and totals: Tax labels, inclusive or exclusive display, discounts, fees, shipping, and final totals match the business configuration.
  • Payments: Gateway names, descriptions, instructions, redirects, hosted fields, return pages, failures, and cancellations work in the selected language.
  • Policies and consent: Terms, privacy, refund, subscription, and marketing-consent links lead to the correct language. Have legal or compliance specialists review obligations for each market.
  • Order creation: A successful test produces the correct order status, line items, customer details, currency, tax, shipping, and payment metadata.

9. Verify account pages and transactional emails

  • Account journey: Registration, login, password reset, addresses, orders, downloads, subscriptions, and logout are translated and functional.
  • Email language: New-order, processing, completed, refunded, failed, account, and password emails use the intended customer language.
  • Email content: Subject, heading, body, button labels, product data, totals, addresses, footer, and support links are correct.
  • Deliverability and layout: Messages reach the test inbox and remain readable on desktop and mobile. Test plain-text fallbacks if the store relies on them.

Polylang for WooCommerce provides translation support for settings such as email notifications, shipping methods, payment gateways, and taxes through Languages → Translations. Confirm that the source strings exist in settings and that translated strings have been saved.

10. Check SEO and sharing

  • Titles and descriptions: Each indexable language version has useful, non-placeholder SEO metadata.
  • Canonical and alternate-language signals: The SEO and multilingual plugins output the intended canonical and hreflang relationships. Validate a sample from every content type.
  • Structured data: Product names, offers, currency, price, availability, and identifiers reflect the visible page and do not mix languages.
  • Social previews: Shared product URLs produce the correct language title, description, image, and destination.
  • Sitemaps and indexing: Intended language versions are included; drafts, test pages, internal search, and duplicate utility URLs are handled appropriately.

11. Test accessibility, layout, and localization quality

  • Keyboard and focus: Language switchers, variation selectors, cart controls, dialogs, and checkout can be used without a mouse.
  • Readable forms: Labels remain associated with controls and errors explain what needs correction.
  • Long and right-to-left text: Translated labels do not overlap, clip, or disappear; layouts support the writing direction when applicable.
  • Locale formats: Dates, numbers, decimals, currency symbols, units, names, telephone numbers, and addresses suit the intended market.
  • Human review: A fluent reviewer checks tone, terminology, product claims, and context rather than relying only on machine translation.

12. Check performance, caching, and integrations

  • Cache separation: Page, object, CDN, and browser caches do not serve one language’s content to another language’s URL or session.
  • Logged-out test: Repeat key journeys in a private browser window to see what real visitors receive.
  • Mobile performance: Product, cart, and checkout pages remain usable on a realistic mobile connection.
  • Analytics and consent: Page views, ecommerce events, language dimensions, and consent behavior are recorded once and with the intended market context.
  • External systems: Feeds, marketplaces, ERP, CRM, search, tax, fulfillment, and translation integrations receive the intended language and product identifiers.

13. Establish a repeatable regression routine

A multilingual store changes continuously. New products, imports, copy edits, promotions, stock updates, plugin releases, and theme changes can reintroduce problems after launch.

  • Before every major release: Back up, test on staging, and run the critical purchase journeys in every language.
  • After catalog imports or bulk edits: Audit translation relationships, taxonomies, attributes, variations, and freshness.
  • Weekly for active stores: Review a small sample of top-selling and recently changed products in each language.
  • Monthly or after major changes: Run a complete multilingual catalog scan, review unresolved issues, and record intentional exceptions.
  • After incidents: Add the failure to this checklist so the same class of bug is tested next time.

Use TranslateGuard as the catalog layer of your QA

TranslateGuard for WooCommerce can reduce the manual work in the product-catalog portion of this checklist. Its WordPress.org release provides manual resumable scans, ten multilingual checks, searchable and filterable findings, CSV export, scan history, diagnostics, and local data storage without telemetry.

It does not replace storefront testing. Cart, checkout, payment, shipping, email, SEO, accessibility, and third-party integrations still need end-to-end testing in each supported language.

  1. Run TranslateGuard before the manual journey. Fix obvious catalog relationship, content, taxonomy, attribute, variation, and freshness findings first.
  2. Complete the storefront checklist. Test the actual customer experience in every language and market combination that matters.
  3. Rescan after fixes. Retain the result and your manual test record as a release checkpoint.

Release decision

Do not launch when: a critical language cannot complete payment, prices or totals are wrong, required products are unavailable, consent or policy links are incorrect, order emails use the wrong language, or a known data defect can affect inventory or fulfillment.

Lower-severity wording or formatting issues can be assessed against business risk, but they should still have an owner and a target date. A documented exception is better than an unexplained failure.

Start with a free, read-only catalog scan →

Sources and further reading