Translation coverage does not measure a completed task
Complete language files help check the text inventory. Approving a multilingual interface also requires evidence that the task works.
Complete files can conceal unresolved problems
A fully translated text list is a useful intermediate result. It shows which planned texts are present. It does not establish whether someone can correctly understand and complete a request in their language. That requires considering language in the actual workflow.
Consider two fictional versions of a project portal, A and B. Both have every planned translation key filled in. We assume the following different behaviours for comparison; these are not user-test results.
Point in the workflow | Version A | Version B |
|---|---|---|
Approval label | Unclear abbreviation to make the text fit | Complete, understandable action |
Currency display on language change | Symbol changes from euros to dollars; amount stays the same | Agreed currency and amount are preserved |
Input on language change | Draft disappears | Draft is preserved |
Identical text coverage conceals different product states here. The currency symbol is also part of a number’s meaning. In this example, another language must not silently replace the agreed currency. A linguistically correct individual line offers little help if its place in the workflow or the data retained are wrong.
Early layout checks remain useful
Waiting for final translations to answer every design question would be unnecessary. Artificially extended test text and a few deliberately chosen pilot languages can reveal early where components are too tight or text is hard-coded. That is a good reason to perform these checks before full localisation.
Their evidence remains limited. W3C describes differences in text length and character width; a general space allowance does not ensure every label fits. Microsoft notes that a few pilot languages cannot uncover every language-dependent problem. Passing an early layout trial therefore does not establish usability in all ten intended languages.
Record evidence for each language
For the portal, acceptance should show whether someone can understand, edit and complete the same request with data preserved. This includes an error state and changing language while editing. The record identifies the checked language, version and task, and the state reached. Missing states remain named. This makes it possible to trace which language version was actually checked for which workflow.
Sources
Written by
- Anna NeumannEditor for Content and Digital MarketingAnna Neumann plans and writes content on digital marketing at ASES. Her topics include search engine optimisation, content strategy and web analytics, with a focus on evaluating marketing activities and their results in a transparent way.
Read more
All articles
Design & UX with ASES
User experience, interfaces and brand presence