Key takeaways
- LQA is performed on a playable build, not on text files, so testers see each string in its real context.
- Typical LQA bugs include truncation, untranslated or hard-coded text, broken placeholders, wrong plurals, missing glyphs and context errors.
- Microsoft's Store policy requires that the experience a product provides must be reasonably similar in all languages it supports.
- Xbox accessibility guidance recommends subtitle lines of no more than 40 characters and no more than two lines on screen, which LQA should verify in every language.
- Pseudo-localisation finds many technical bugs before translation, but it cannot replace testing by native speakers.
This article is for producers, QA leads and developers preparing a localised game for release. It explains what linguistic quality assurance covers, how a test pass is run, how bugs are prioritised and what testers need from the studio.
Translation and review happen on text, usually in a translation tool or spreadsheet. LQA is the stage where native speakers see that text inside the game, on the target platform, and check that it reads, fits and works as intended.
What is LQA in game localisation?
Linguistic quality assurance (LQA) is the testing of a localised game build by native-speaking testers to find language, display and cultural errors in context. It is different from functional QA, which looks for crashes and gameplay bugs, and from linguistic review, which checks the translation text before it goes into the build.
Testers play through the game, trigger menus, dialogue and edge cases, and log each issue with a screenshot, its location and a suggested fix. The translation team then corrects the strings and the testers check the fixes in the next build.
What kinds of bugs does LQA find?
LQA finds bugs that only appear when translated text meets the real interface, code and game situation. The table below lists the most common categories and their usual causes.
| Bug type | Example | Usual cause |
|---|---|---|
| Truncation or overflow | A German button label cut off mid-word | Fixed-width UI and longer target text |
| Untranslated text | An English tooltip in the French build | Hard-coded strings or a missed file |
| Broken placeholders | "You found {0} {1}" shown with raw variables | Placeholder edited or deleted in translation |
| Grammar from concatenation | Adjective and noun in the wrong order | Sentences assembled from fragments in code |
| Wrong plural forms | "1 items" or the wrong Polish plural form | Code that assumes only singular and plural |
| Missing glyphs | Empty boxes instead of Japanese or Polish characters | Font without the needed characters |
| Context errors | "Fire" translated as dismissal instead of shooting | String translated without a screenshot or note |
| Inconsistent terminology | One item with two different names | No glossary, or several translators without a shared memory |
| Subtitle problems | Lines too long to read or out of sync | No line-length rules or timing checks |
| Cultural or rating issues | A gesture or symbol that is offensive locally | No culturalisation review |
Plural bugs are more common than many developers expect. The Unicode CLDR project defines six plural categories, "zero", "one", "two", "few", "many" and "other", and warns that "A common mistake is to think that “one” is only for only the number 1." (Unicode CLDR: Plural Rules).
How does an LQA test pass work?
An LQA test pass is a structured playthrough of a localised build, run against a test plan, with every issue logged in a shared bug tracker. A typical pass follows these steps:
- Prepare the build. The studio supplies a build for each platform, with cheats, level select or save files so testers can reach all content.
- Share the reference material. Testers receive the glossary, style guide, character list and a walkthrough or test plan.
- Agree the bug format. Each report includes the language, location, screenshot, current text, suggested text and severity.
- Run the first pass. Testers cover menus, tutorials, dialogue, items, achievements, error messages and legal screens.
- Fix the strings. Translators update the source files and the studio integrates them into a new build.
- Run regression. Testers check that each fix is correct and has not caused new problems.
- Sign off. The language lead confirms that no open bugs remain above the agreed severity.
How are LQA bugs classified by severity?
LQA bugs are classified by severity so that the team fixes what affects players most before release. Studios define their own scales, but most use four levels.
Critical
The issue blocks progress, misleads the player about how to play, or creates legal or rating risk. A wrong instruction in a tutorial or an offensive term belongs here.
Major
The issue is clearly visible and damages understanding or quality, such as truncated menu text, untranslated dialogue or a mistranslated quest objective.
Minor
The issue is noticeable but does not affect understanding, such as a typo, inconsistent capitalisation or a slightly awkward phrase.
Preferential
The suggestion is stylistic. It is logged for review but usually not required for release.
Which platform and accessibility requirements should LQA check?
LQA should check that each language meets the rules of the platforms you publish on, not only that the text is correct. Store policies set minimum standards for localised products.
Section 10.7 of the Microsoft Store Policies states:
"You must localize your product for all languages that it supports. The text of your product's description must be localized in each language that you declare. … The experience provided by a product must be reasonably similar in all languages that it supports."
Steam works in a similar way: for each language you declare whether you support the interface, full audio or subtitles, so testers should confirm the build matches the store page.
Subtitles need checking in every language too. Microsoft's Xbox Accessibility Guideline 104 advises avoiding lines of more than 40 characters and showing no more than two lines of subtitles at a time. Translated subtitles often grow longer than English, so this is a frequent LQA finding.
Can pseudo-localisation replace LQA?
Pseudo-localisation cannot replace LQA, but it catches many technical problems earlier and more cheaply. Pseudo-localisation replaces source text with an artificial, longer, accented version so that developers can spot hard-coded strings and layout problems before any translation exists.
Android, for example, offers pseudolocales that expose "UI layout issues caused by text expansion" and strings split by concatenation (Android Developers: Test your app with pseudolocales). They do not show whether a translation is accurate, natural or culturally appropriate. Only native-speaking testers can judge that.
Common mistakes that make LQA slower and more expensive
Most LQA delays come from poor preparation by the studio rather than from the translations themselves. Avoid these:
- No way to reach late content. Without cheats or save files, testers spend hours replaying instead of testing.
- Testing too late. LQA started a week before release leaves no time for fixes and regression.
- No string IDs on screen. A debug mode that shows string IDs makes each bug much faster to locate and fix.
- Untested fonts. Missing glyphs are found late if fonts are not checked with real target text early.
- Skipping legal and system text. End-user licence screens, error messages and platform prompts are often forgotten.
- Treating LQA as optional. It is a separate budget line; see how much game localisation costs.
LQA is one stage of the wider process described in our complete guide to video game localisation. Cultural problems found during testing are covered in more depth in our article on game culturalisation, and broader quality checks in our guide to translation quality assurance.
How TranslationWorks can help
TranslationWorks is a UK-based translation agency whose IT and gaming translation team localises game text with native-speaking linguists in 150+ languages. We translate and review strings, dialogue and store copy. If you need help with checking localised builds, our custom language services are the place to start, and we will confirm in your quote exactly what we can provide.
Because testers handle unreleased builds, security matters: we are ISO 17100 certified for translation services, ISO 27001 registered for information security, ISO 9001 registered for quality management and Cyber Essentials certified. Tell us your platforms, languages and word count, and we will scope the work with you. Request a free localisation quote and we will reply within 24 hours.
