Game Localization · All Services
Localization QA Services — In-Engine LocQA for Games
Native translators. Translation Memory. In-build LocQA. Get a free quote →
Localization QA (LocQA) is the testing stage that verifies translated strings render correctly in your actual game build — font coverage, text overflow, layout direction, locale-sensitive formatting, and functional behavior in localized flows. File-level QA on string files catches translation and formatting errors; LocQA catches issues that only appear when localized text is live in the engine: truncated dialog boxes, missing CJK glyphs, reversed RTL layouts, broken placeholder variables, and locale-specific functional failures. SandVox provides in-engine LocQA for PC, mobile, and console game builds across all major game engines and target languages.
What Localization QA Tests
LocQA is distinct from linguistic QA. Linguistic QA reviews translation quality — accuracy, fluency, terminology consistency — and happens at the file level before localized strings are in-engine. Localization QA tests the integration of those translations in a running build. LocQA test categories include: Cosmetic/Layout QA — text overflow (strings exceeding UI container bounds), truncation (strings cut off at field limits), text clipping (characters overlapping UI elements or each other), and font rendering (correct glyph rendering for all scripts). CJK-specific QA — Japanese, Chinese, and Korean glyph coverage, line-break behavior at CJK text wrap points, character width handling in fixed-width UI elements. RTL-specific QA — Arabic and Hebrew layout direction (full UI mirroring), bidirectional text (mixed RTL/LTR strings), and number formatting (Arabic-Indic vs. Western numerals). Functional QA — locale-sensitive date, number, and currency formatting; locale switching behavior at runtime; placeholder variable rendering in format strings; pluralization logic in all target languages. Locale-specific functional QA — save/load behavior in localized builds, in-app purchase flows in target storefronts, and any game system that branches on locale.
Why File-Level QA Is Not Enough
String file review — checking translated .po, .xliff, or .json files for quality and formatting — is a necessary first step, but it cannot substitute for in-engine testing. File-level QA cannot detect: font rendering issues (a missing glyph produces a box in-engine, not in a text editor), UI layout problems (a 40-character German string that overflows a dialog box sized for 20-character English text), engine-specific rendering behavior (Unity’s TextMeshPro and uGUI handle CJK text wrapping differently), RTL layout direction (only visible in a running build with a localized UI rendering), or locale-specific functional behavior (runtime locale switching errors, locale-dependent code paths). The localization bugs that damage player reviews — garbled text, broken layouts, boxes instead of CJK characters — are almost universally in-engine issues, not file-level issues. LocQA in a running build is the only test that catches them.
CJK Localization QA
CJK (Chinese, Japanese, Korean) localization QA has the highest technical complexity of any language group. LocQA for CJK covers: Font coverage — verifying the embedded font covers all required CJK Unicode ranges; Simplified Chinese requires approximately 6,763 GB2312 characters, Traditional Chinese requires BIG5 coverage, Korean requires full Hangul syllable block coverage, Japanese requires Hiragana + Katakana + approximately 2,000–6,000 Kanji. Missing glyphs produce tofu boxes (□) at runtime, which are invisible in file-level review. Line-break behavior — CJK text wraps differently than Latin text; Japanese and Chinese text can break between any character; line break handling must be verified in UI containers with wrapping behavior. Character width — CJK characters are full-width (em-width); UI elements designed for Latin text at specific pixel widths will display fewer CJK characters than expected. Vertical text — Japanese UI sometimes uses vertical text layout (tategumi), which requires specific engine and font support. CJK LocQA is conducted in running engine builds — Unity, Unreal, Godot, or custom — where rendering behavior is engine-specific.
Console Certification LocQA
Console platform certification requirements include localization-specific test cases. Nintendo Switch Lotcheck: text overflow in any locale is a failure; CJK font rendering must be verified; language fallback must be tested. PlayStation TRC: trophy text must be within byte limits in all locales; system messages must be localized; PSN metadata must meet quality thresholds. Xbox XR: machine translation is a certification failure; locale detection must be correct; achievement text must not overflow character limits. For each platform, we run LocQA test cases that map to the certification checklist localization items, flagging any issues before you submit. Post-certification patches for localization failures are costly — getting LocQA right before submission avoids submission failure, resubmission fees, and schedule delays.
Frequently Asked Questions
What is the difference between LocQA and LQA?
LocQA (Localization QA) and LQA (Linguistic Quality Assurance) are distinct test phases. LQA reviews translation quality — accuracy, fluency, terminology consistency, cultural appropriateness — and happens at the string file level. LocQA tests the integration of translated strings in a running game build — font rendering, text overflow, layout direction, functional behavior. LQA catches translation errors; LocQA catches rendering and integration errors. Both are necessary: LQA before LocQA, since fixing translation errors before in-engine testing avoids testing stale strings.
Can you do LocQA if we don’t have a development build to share?
In-engine LocQA requires access to a build of the game. We work with standard distribution methods: executable builds shared via secure file transfer, Steam branches (we can be added to a Steam partner account for a test branch), or console development kits for Switch/PS5/Xbox builds. We sign NDAs before receiving any build access. For teams that can’t share a full build, we can provide a LocQA test specification document — a checklist of issues to test for in each language — that your QA team runs internally, with us reviewing the results.
What game engines do you support for LocQA?
We conduct LocQA in Unity (TextMeshPro, uGUI, Unity Localization Package), Unreal Engine (FText, Unreal localization dashboard, slate/UMG), Godot (GNU gettext .po pipeline, TextServer), and custom engines that export standard string file formats. Engine-specific LocQA matters because rendering behavior differs: Unity TextMeshPro handles CJK differently than uGUI; Godot 4 has native RTL support while Godot 3 does not; Unreal’s font atlas behavior for CJK requires specific configuration. We account for engine-specific behavior in LocQA test design.
What does LocQA typically cost and how long does it take?
LocQA cost depends on the number of target languages, the platform (PC vs. console), and the UI complexity of the game. A typical PC game LocQA pass for 5 European languages takes 3–5 business days. CJK LocQA (Japanese, Chinese, Korean combined) adds 3–5 days due to font coverage validation and rendering complexity. RTL LocQA (Arabic or Hebrew) adds 2–3 days. Console LocQA adds time for platform-specific certification item testing. We quote LocQA after reviewing a build or a screen recording of the game’s UI — contact us with your target languages and platform for a specific scope and timeline.
Start Your Localization QA Services Project
Tell us your word count, target languages, and platform. We return translated files ready for import — with Translation Memory and terminology glossary included. Free quote in one business day.