Localization QA
By Emirhan Karahasan
How to Detect Truncated Text and Untranslated Strings in a UI
How to detect truncated text and untranslated strings in a UI: DOM overflow checks, pseudo-localization, fallback-string detection and screenshot diffs, and what each method misses.


To detect truncated text and untranslated strings in a UI, check the rendered interface in every language: measure overflowing elements in the DOM, run pseudo-localization before translation, scan rendered text for fallback strings and raw keys, and compare screenshots between locales. Each method catches a different part of the problem, so most teams combine two or more.
How do you detect truncated text in the DOM?
An element is clipping its text when its content is wider or taller than its visible box: scrollWidth is greater than clientWidth (or scrollHeight greater than clientHeight) on an element whose overflow is hidden or that uses text-overflow: ellipsis. Running this check in a headless browser, for every locale and at several viewport widths, finds truncation a reviewer would have to scroll through every screen to see.
It misses text that overflows visibly instead of being clipped, and anything inside images or canvas.
How does pseudo-localization help?
Pseudo-localization replaces source strings with longer, accented versions, such as [Ŝéţţîñĝš ~~~], before real translation starts. Brackets that get cut off show truncation; text that stays plain English shows strings that bypass your translation pipeline. Run it in CI so layout problems surface while the component is still being built.
It misses real translations: it can’t tell you whether the German wording is right, only whether longer text fits.
How do you find untranslated strings on a live page?
Look for text that shouldn’t be there in the target language:
Fallback strings: when a translation is missing, many i18n libraries fall back to the source language or show the raw key, such as
checkout.button.label.Source-language text: compare rendered text against your source strings, or detect the language of each text node.
Unfilled placeholders:
{count}or%sshowing up in the rendered UI.
Pages that mix languages are the clearest sign. This also catches hardcoded strings that never entered your TMS.
What do screenshot diffs add?
Comparing screenshots of each locale with the source locale, or with the previous build, flags layout shifts, overlaps and broken alignment. It shows that something moved, not whether the text is correct, so it complements the checks above rather than replacing them.
Which method catches what?
Method | Catches | Misses |
|---|---|---|
DOM overflow checks | Clipped and truncated text, per locale and viewport | Visible overflow, text in images |
Pseudo-localization | Expansion problems and hardcoded strings, before translation | Real translation issues |
Fallback-string detection | Missing translations, raw keys, unfilled placeholders | Translations that exist but are wrong |
Screenshot diffs | Layout shifts and overlaps | Whether the language is correct |
How Loqalit does this on every page and language
Loqalit runs these checks on the rendered page, on a schedule, without anyone logged in. Its agents open your live or staging pages in a real browser, in every language, measure where text overflows or is cut off, flag untranslated and mixed-language text, and evaluate each string in context. Every finding comes with a screenshot, a reason and an MQM severity.
Localization QA for live websites and web apps → · The localization QA checklist →


