LocaLens — Localization QA Tool
A tool that measures how much translated UI text grows and flags exactly which strings will break their layout, before a translation ships.
Context
Most translation tools stop at the text — they translate a string but say nothing about whether the translated version still fits the button, label or card it was designed for. Teams typically only discover layout breakage after a translated build ships. LocaLens set out to catch that earlier, from a screenshot alone.
The Challenge
The product needed to go from a UI screenshot to a reliable overflow risk assessment — extracting text, translating it, and measuring whether the result still fits its original container — without requiring access to the actual codebase or design file.
Research
Researched how much text length typically expands or contracts across common target languages — German and Finnish tend to expand, Japanese and Chinese often contract — and used that as the baseline for what counts as a meaningful overflow risk versus normal variation.
Insights
The key findings that shaped the direction.
Translation length, not translation quality, breaks layouts
A perfectly accurate translation can still break a UI if it's 40% longer than the source string — length risk and translation quality are separate problems that most tools conflate.
OCR position data is what makes the check useful
Extracting the text alone isn't enough — knowing where each text block sits and how wide its container is is what turns a translation into an actual overflow measurement.
Privacy was a precondition, not a feature
Teams testing pre-release UI screenshots won't upload them to a third-party server — client-side OCR was the only way to make the tool usable for real, unreleased work.
Design Strategy
How decisions were made.
Start from a screenshot, not a codebase
Built the tool around OCR extraction from a UI screenshot, so it works on any interface — shipped or in-progress — without needing design file or code access.
Measure expansion, not just translate
Calculated a character-expansion percentage per text block and compared rendered width against the original container, turning 'is this translated' into 'does this still fit.'
Flag risk in three tiers
Colour-coded every text block as Safe, Review or High-risk, so a team can triage a screen with dozens of strings in seconds instead of reading every translation.
Keep it client-side
Ran OCR entirely in the browser so screenshots of unreleased UI never leave the user's machine, making the tool safe to use on pre-launch work.
Build solo, with AI as the engineering partner
Designed and built end-to-end using Claude Code as a development partner — from the OCR extraction pipeline to the risk-scoring logic — without a dedicated engineering team, while keeping every architectural and UX decision in my hands.
Solution
A client-side localization QA tool that extracts text from a UI screenshot via OCR, translates it into 10 languages, and flags exactly which strings risk breaking their original layout.
A look at the work.
The live product at localensapp.vercel.app.
Core capabilities — OCR extraction, translation, side-by-side compare and multi-format export.
The risk-scoring output a team actually sees — safe, review and high-risk blocks for a screenshot.
Design System Thinking
This project wasn't designed as a one-off — here's how it connects back to the system.
Components
A reusable risk-badge component (Safe / Review / High-risk) applied consistently across the comparison view and exported reports.
Tokens
A three-tier risk colour scale shared between the live comparison view and every export format.
Patterns
A side-by-side comparison pattern with synchronized zoom and pan across source and translated versions.
Governance
Fully client-side processing — screenshots and extracted text never leave the browser, by design rather than by policy.
Impact
LocaLens shipped as a working QA step most localization workflows skip entirely, turning 'ship the translation and see what breaks' into a check a team can run before release.
Reflection
This was the clearest case of a tool needing a genuinely different data model than I expected going in — I started thinking of it as a translation tool and only later realised the actual product was a measurement tool that happens to use translation as an input.