Testing a Localized Website Before Launch

Quick answer — Test a localized site in three passes: pseudo-localization before translation to find layout and encoding faults, then rendered-page checks per language, then the SEO mechanics after publishing.

Vitra.ai Universe creates, translates, adapts and publishes from one place.

Pseudo-localization first, before any translator

Replace every string with a padded, accented version of itself. The page still reads as English, and every structural fault becomes visible.

This costs almost nothing and finds the expensive class of bug while it is still a code fix rather than a re-translation. Doing it after translation means fixing the code and then re-running the translation.

Then test the rendered page, per language

A string file proves text exists. It does not prove it fits. Check the longest language you support — usually German or Russian — on the narrowest viewport you support. That combination surfaces most layout problems in one pass.

Then check right-to-left separately if you support it, since mirroring is a different failure mode entirely, covered in RTL layouts.

The checks that keep failing

Truncated buttons and labels. Dates in an ambiguous numeric form. Decimal separators. Currency symbol placement. Links pointing back at source-language pages. Form validation messages still untranslated because they live in a different file. Error and empty states, which nobody navigates to during a review.

Error states are worth calling out. They are the least-visited screens and the most likely to be untranslated, and a user only sees them when something has already gone wrong.

Images and video are separate

Text inside images will not have been touched by any of the above, and it is frequently where the size chart, the diagram callouts and the campaign headline live — image translation work.

Video needs captions checked against the rendered clip rather than the transcript.

After publishing

The SEO mechanics and sitemap coverage can only be verified once pages are live and crawled.

Run quality control across every page rather than sampling, and have one native speaker per market look at the live site — thirty minutes each, and it catches what no automated check can. Forms are where that walkthrough pays for itself — citizen form translation.

FAQ

What is pseudo-localization and when should it run? Replacing strings with padded, accented versions of themselves before any translation. It exposes hard-coded text, fixed-width containers and encoding faults while they are still code fixes.

What should be tested on a rendered localized page? The longest language you support on the narrowest viewport, which surfaces most layout problems at once. Right-to-left layouts need a separate pass because mirroring fails differently.

Which localized screens are most often untranslated? Error and empty states. They are the least visited during review and the most likely to be missed, and a user only reaches them when something has already gone wrong.

What can only be checked after launch? The SEO mechanics and sitemap coverage, since hreflang, canonicals and indexing behaviour are only verifiable once pages are live and have been crawled.