Localisation review
Have the model review translated screens and strings in context, flagging mistranslations, truncation, inconsistent terminology and formats that are wrong for the locale.
How it works
Translation is usually checked string by string, but many localisation bugs only show on the screen: a label cut off because the German is noticeably longer, a button text that is grammatically correct but wrong for its function, a date or currency in the source locale's format, an untranslated string in an otherwise translated view. The model is given screenshots per locale together with the source strings and a glossary, and reviews each screen for those problems. It also checks consistency across the product — the same concept translated three different ways — which is tedious for people and practical for a model with the whole string set in front of it.
When to use it
Before releasing a new language; after large UI changes in a multilingual product; when translations come from several translators or vendors; and for languages nobody on the team reads.
Limitations
Model quality varies a great deal by language, and is weakest for the less widely used ones, which are often the ones the team can't check either. It can judge fluency better than appropriateness — tone, formality and cultural fit need a native speaker who knows the audience. Right-to-left layouts, input methods and locale-specific sorting need testing in the running product, not screenshots.
Watch for
A fluent string with the wrong meaning in a language nobody on the team reads, such as “cancel subscription” translated as the word for closing a dialog, and the review passes it. Have a native speaker check irreversible actions, payment and legal text in context.
What you still own
Native-speaker review for anything customer-facing, and the decision that a language is ready to ship.
Cite this
Qlarify Labs. (2026). Localisation review. Retrieved from https://labs.qlarify.fi/ai-in-testing/localisation-review


