Localization testing ensures that translated content displays correctly, the UI adapts to different text lengths, and the overall experience feels natural to users in each supported language. This page covers hands-on testing procedures for localized Meta Quest apps. For the full localization workflow, see Localization.
Set up your testing environment
Before testing localized content, configure your testing environment:
Change device language: On your Quest headset, go to Settings > Device > Language and select the target language. The Quest supports 25 languages.
Use release channels: Deploy LQA builds to a dedicated release channel so testers can access the latest localized build without affecting production users.
Create test accounts: Set up test user accounts with different locale configurations to verify locale-specific behavior.
Test locale detection and fallback
Your app should detect the user’s device language and serve the appropriate localized content. Verify the following:
The app loads in the correct language when the device language matches a supported locale
The app falls back to English when the device language is not supported
If your app includes a custom language selector, verify that it overrides the device language correctly
Locale detection works correctly after app restart
Translated text is often longer than English and can cause layout issues. Check for:
Text truncation: Strings cut off or hidden behind UI elements
Text overflow: Translated text extending beyond button or panel boundaries
Overlapping text: Labels colliding with other UI elements or each other
Broken line wrapping: Words split incorrectly, especially in languages that use minimal spacing
Missing translations: Untranslated strings still showing in English (or as raw string IDs)
Placeholder errors: Variables like {player_name} displaying as literal text instead of resolved values
Pay special attention to UI elements with fixed sizes, such as buttons, menus, and in-headset panels where space is limited.
Test fonts and character rendering
Non-Latin scripts require fonts that include the appropriate glyphs. Without them, text renders as square blocks (known as “tofu”). Verify the following for each supported language:
All characters render correctly with no tofu or missing glyphs
Font style is consistent with the app’s visual design
Dynamic font atlas generation works at runtime (for Unity TextMeshPro, verify Atlas Population Mode is set to Dynamic)
Font rendering performance is acceptable on device — large glyph sets (especially CJK) can impact load times and memory