Guide
Localization QA for live websites and web apps
Loqalit is an agentic localization QA platform that checks your live and staging websites and web apps in every language you ship. It catches translation, context and layout bugs in the rendered product, scores them with MQM, and routes fixes into Crowdin or Phrase.
This guide covers localization QA for the live, rendered product: how it works, what it catches that file and TMS QA miss, and which tools do it.
Updated October 2026
How do you check translation quality on a live website?
You check translation quality on a live website by reviewing the rendered pages in each language, not the translation files, because many localization bugs only exist after the text lands in the layout.
There are three ways to do it:
Manual review. A linguist opens each page in each language and logs issues. It’s accurate, but coverage scales with hours, and it stops at the screens someone has time to open.
Visual regression testing. Screenshot diffs between builds flag layout changes, but they don’t understand language.
Rendered-product localization QA. A tool opens your live or staging pages in a real browser, reads the text as it renders, and checks both language and layout in every locale.
If you only do one thing, check the pages that changed since your last release, in every language you ship.
What is in-context LQA for web apps?
In-context LQA (linguistic quality assurance) for web apps means evaluating translations inside the running product, where each string sits next to the element it labels, instead of in a spreadsheet or string list.
Context changes the verdict. A translation can be correct as a segment and still be wrong in place: the wrong sense of an ambiguous word, a label too long for its button, or a term that changes from one screen to the next.
In-context LQA can be human-led, with a reviewer working in an in-context editor, or automated, with a tool doing the review across every page on a schedule. Loqalit does the automated version. Its agents open your pages in a real browser, judge each string where it renders, and score what they find with MQM.
What does rendered-product QA catch that file and TMS QA miss?
Rendered-product QA catches bugs that only exist after translated text is rendered: overflow, truncation, layout overlap, RTL mirroring errors, translations that are wrong in context, hardcoded strings that never reached the TMS, and terminology that drifts between screens.
File QA tools like Xbench check the translation file. TMS QA checks strings against rules. Loqalit checks what your users actually see.
Error type | File QA (e.g. Xbench) | TMS QA | Loqalit |
|---|---|---|---|
Missing translations | Yes | Yes | Yes |
Terminology vs glossary | Yes | Yes | Yes |
Placeholder mismatches | Yes | Yes | Yes |
Text overflow in the rendered UI | No | No | Yes |
Truncation and clipping | No | No | Yes |
Layout breaks and overlap | No | No | Yes |
RTL mirroring errors | No | No | Yes |
Context-wrong but segment-correct translations | No | No | Yes |
Cross-screen terminology conflicts | Within the file only | No | Yes |
Hardcoded / untranslated strings in the build | No | No | Yes |
MQM-scored severity across the product | No | No | Yes |
File and TMS QA still matter. They catch errors earlier and more cheaply, before anything is built. Rendered-product QA is the layer after them, not a replacement. See how TMS QA checks and in-context QA work together.
How does continuous localization quality monitoring work?
Continuous localization quality monitoring means scanning the same pages in every language on a schedule, so a regression is caught when a release ships rather than when a customer reports it.
In Loqalit, it works in four steps:
Schedule. Choose pages, languages and frequency once: daily, weekly, quarterly or a single date. Scans run with nobody logged in.
Scan. Scout crawls from a page you give it, reads the sitemap, and proposes which pages are worth watching. The agents open each page in a real browser, in each language.
Detect regressions and drift. Every scanned page is fingerprinted, so the next scan shows what changed since your last release, not the whole backlog. When a change introduces a regression, the right person gets an alert by email or Slack.
Score and route. Editor reads the exact string a scan flags and drafts a correction that respects your glossary, brand voice, and style guide. Verifier resizes the browser, measures the element, photographs it, and checks the glossary again before anything is marked as a real finding. Each finding carries a screenshot, a plain-language reason and an MQM severity. You accept or reject it, and accepted fixes go into Crowdin or Phrase.
Language coverage and its trend over time are tracked, so a drop can be dated.
The Chrome extension is one way to run Loqalit on demand; the platform runs scheduled scans without anyone logged in.
Which tools do this?
Only a few tools check translations on the rendered page. Most localization QA tools check files or strings.
Loqalit: agentic rendered-product QA for live and staging websites and web apps. MQM-scored findings, with fixes routed into Crowdin or Phrase.
LocHub QA Insights: crawls live multilingual websites from a URL and flags mixed-language errors on a central dashboard.
Visual regression tools (Applitools, Percy, Chromatic): catch layout changes between builds, but don’t evaluate language.
In-context editors (Crowdin In-Context, Lokalise Live Edit, Phrase In-Context Editor, Lingoport LocalyzerQA): give a person visual context; the person does the checking.
For bilingual-file checks before delivery, a file QA tool like Xbench is still the right choice. See all six categories of localization QA tools.
Frequently asked questions
Can I check translation quality on a staging site before launch?
Yes. Rendered-product QA works on any live or staging page, so you can scan a release candidate in every language before it ships.
Does rendered-product QA replace my TMS QA checks?
No. Keep your TMS’s built-in checks switched on. They catch string-level errors early. Rendered-product QA checks what those checks can’t see: the product after rendering.
Which languages can be checked?
Any language your site renders, including non-Latin scripts and right-to-left languages such as Arabic. Loqalit analyses the text on the page instead of using a fixed language list.
Is Loqalit a Chrome extension?
No. Loqalit is a platform. The Chrome extension is one way to run Loqalit on demand; the platform runs scheduled scans without anyone logged in.
How is translation quality scored?
With MQM (Multidimensional Quality Metrics). Each finding gets an error category, such as accuracy, terminology or design, and a severity. Read our MQM scoring guide.
Does it work with Crowdin and Phrase?
Yes. Accepted fixes are routed server-side into Crowdin or Phrase, where your translators already work.
How much does Loqalit cost?
Plans start at $12/month.