Localization testing checks a translated product the way a local user would meet it. Native speakers in the market read the strings in context, use the screens, and flag what sounds wrong, what no longer fits, and what does not make sense locally. You get the list of what to send back, and why.
Book a free 30-min callProjects from €399.
La plataforma de asistencia digital mejorando los resultados mundiales.
La plataforma de asistencia digital que mejora los resultados en todo el mundo.
Most translated products are accurate and still wrong. The words mean what they should and the sentence reads like it was written by somebody who has never been to the country. That is a tone problem, not a dictionary problem, and no translation memory catches it.
The rest breaks in the layout. German runs long and pushes a button onto two lines. Thai has no spaces between words, so character limits and truncation behave differently. Dates, currencies and address forms follow local conventions that look like bugs to a user when they are wrong. All of it is invisible in a spreadsheet of strings and obvious the moment somebody local opens the screen.
Whether the register fits, formal or familiar, and whether anything reads as blunt, childish or oddly corporate to a local ear.
Where expanded text breaks buttons, labels and navigation, and where truncation cuts a word in the wrong place.
Examples, payment methods, name and address formats, and references that do not travel. The parts that are right at home and wrong there.
Reviewed in the product wherever possible, because most of these faults only appear once the words are in place.
Buttons, labels, navigation and empty states, read in context rather than in a file.
The first five minutes, where a confusing phrase costs you the account.
Written under pressure in the source language and usually translated last.
Whether the claim still persuades, or merely still parses.
Title, subtitle and first lines, which decide the install before anything is read.
Local conventions, including calendars that are not the Gregorian one.
Name order, postal formats and phone fields that reject valid local input.
Scored against a rubric you define. Also covered under AI evaluation.
We recruit native speakers living in the market, not bilingual speakers living somewhere else, because the second group stops noticing what sounds foreign. Each reviewer works through the product against a rubric you agree beforehand, scoring naturalness, tone and local fit, and flagging anything that needs a person rather than a model.
Where the decision is bigger than wording, we run sessions instead, so you can watch somebody local use the translated product and see where they hesitate. The markets we reach are the same ones we recruit for.
A staging build, a live URL, a string file, an app store listing or a set of screenshots. Testing inside the product beats testing a spreadsheet, but if strings are all you have, we will work from strings and tell you what we could not judge without context.
Localization testing checks a translated product the way a local user would meet it. Native speakers in the market read the strings in context, use the screens, and flag what sounds wrong, what no longer fits, and what does not make sense locally, which is different from checking whether the translation is accurate.
Yes. A proofreader checks the text. Localization testing checks the text inside the product, so it catches the things that only appear in situ: a button label that now runs over two lines, a date format nobody uses locally, a tone that reads as rude in that market.
We recruit native speakers living in the market rather than drawing on a fixed roster, so coverage follows the brief. We work most often across Southeast Asia, Europe and the Americas. Tell us the markets and we will confirm before anything is agreed.
Yes, and it is one of the most common reasons people come to us. Machine translation is usually accurate and often sounds wrong. Human raters score each string against a rubric you define and send back the ones that need a person.
A staging build, a live URL, a string file, an app store listing or a set of screenshots. Testing in the product is better than testing a spreadsheet of strings, because most localization faults only appear once the words are in place.
Send us the build or the strings and the markets, and we will come back with a scope and a figure.