Design
Localization
Updated: Sep 3, 2024
App localization helps reach a global audience by not just translating text and voice over content, but also updating elements of a design to ensure that it is enjoyed the way it was intended. This process does require time and resources, but it is recommended as it will open up the possibility for a new, global audience to discover and purchase an app.
How to plan and design an app for localization
To help save time and resources during localization, design and engineer with the mindset that an application will be translated and shared with a broader audience. See below for a series of best practices during planning and development pre alpha build.
Prep the string file
Localization requires a bilingual file-oriented process, this is why the string file is so important to the success and efficiency of this process. This string file should contain all of the in-app content strings that make up localized content. Keep the following in mind during plan and build for maximum efficiency.
- Assign one point-of-contact on a team to be responsible for localization planning and execution.
- Leverage a single master file for all in-app content.
- Externalize the strings so that they are ready for translations. Do not hard-code any text.
- Make sure the string file is compatible with localization tools. XLS, PO, JSON, XML, CSV are widely accepted as standards in the industry.
- Assign unique string IDs/Keys for each string, even if the same source text is used within different areas of an app. This will streamline the process when translating a single word into multiple languages and add flexibility for when different text layouts are required.
- Ensure string IDs are static and do not change during the export process. New string IDs are flagged and reviewed by localization tools, requiring unnecessary work and additional translation cost.
- Avoid mentioning any specific platforms within strings. If necessary, add variant strings for all platform-specific text and remember to modify/remove this content accordingly.
- Add developer notes specific to the localization process to ensure the linguists translate each section accurately. Provide context as to the purpose of the text/string, clarify parts of speech (verb, noun, etc), clarify the speaker in a given scene, highlight when a complex turn of phrase or pun is used, etc.
See below for an example XLS file formatted for localization.
| string_ID | English | Developer Notes |
|---|---|---|
mainmenu_start_button | START | UI button to start the game |
mainmenu_credits_button | CREDITS | Main menu to view credits for the game |
scene_1_cutscene_char1_1 | Hey, wake up! | Dialogue, Max Character Limit: 15 |
scene_2_objective_name_record | Record | VERB. Name of objective: Record the conversation using a voice recorder |
Build localization-ready UI
Designing and developing flexible, easily resizable UI will save a great deal of time during the localization process. Compared to English, sentences and words in many other languages tend to be 2-3X longer in visual length, while some languages require layouts that are slightly taller to accommodate extra accents and stroke characters. See below for more ways to ensure a UI is localization-ready:
- Enable responsive layouts to accommodate changes that may occur based on different language character types. This includes auto-resizing of text boxes, buttons, and text.
- Support horizontally scrollable, ticker tape boxes as a solution to resolve challenges with word wrapping.
- Integrate rich text tags within the translation file for line breaks and no-break tags (e.g.
<br>,<nbsp>). This will streamline the localization process for line wrapping, especially within those languages that use minimal spacing between each word. - Document all visual assets that include text baked within the layout to more effectively plan the localization process.
- If a layout only has enough space for a specific number of characters, be sure to document the maximum character count for that section of an app within the developer notes.
- Be sure to perform a full round of review of strings prior to kicking off any localization process. Remove obsolete strings that do not need to be translated and fix any typos, grammar, and punctuation errors to further optimize the localization process.
- Avoid using country flags to represent languages as a language can be spoken in multiple regions around the globe.
Manage language support in an app
While the Quest App supports 25 languages, it is possible to target specific languages. In-app language should be served by the user’s device language if the locales match between the two. Detect the locale object at runtime using the Meta Quest platform SDK or native Android methods, then use the object to determine what localized version of an app will be sent to that specific user. See the following documentation page for more on how to Get the User Locale.
Note that it is still strongly recommended to have a custom language selector in an app so that users can choose their preferred language. If there is no plan to support the user’s device language, the app must load in English by default. For other requirements to keep in mind, check out the Quest Virtual Reality Check (VRC) Guidelines.
When managing localization files, be sure to also consider using Language Packs as these can reduce installation app size.
Font for international language support
By default, many game engines and frameworks do not render non-Latin characters properly and display them as blocks. (usually known as ‘tofu’). To render non-Latin languages, it is necessary to include the fonts for those languages.
Korean text displayed with Unity’s default font Liberation Sans. It is rendered as square blocks since there are no Korean glyphs found in Liberation Sans.
Korean text displayed properly with Noto-Sans font which supports Korean glyphs.
To ensure that localized content is consistent with an app’s established look and feel, research and implement fonts that fit the original style. There are many free fonts available as well as licensed fonts available for commercial-use.
Unity: Import the font file into Unity then create a Text Mesh Pro asset. By default, Atlas Population Mode is set to Dynamic. Don’t worry about the huge texture size since the texture for each glyph will be generated on runtime. For example, if using static texture images for the Asian languages with complex strokes and variations such as Chinese and Japanese, it could become over hundreds megabytes. However, with dynamic texture, texture size can be reduced to as little as 10KB.
If using a static texture, for multi-byte languages with thousands of characters, it is impractical to include every possible character in the image. Therefore, the most common practice is to scan the text to produce a library of characters that are included within the string file, and generate an image including only those characters.
Unreal and other third party engines: For most game engines, the text printing method tends to be an entirely custom process. Try to be flexible and offer a number of supported fonts.
To test a new font, deploy a build with a block of randomly translated text. Note many fonts are not compatible with Asian or Cyrillic languages, so be sure to test an app in those languages if they are common within its target markets. Remember that unsupported glyphs (characters) will not display when deploying a test build or may appear simply as squares.
Execute the localization process
To ensure a smooth and efficient localization process, follow these best practices and considerations as an app moves forward localization.
Add localization into a release pipeline and plan accordingly. It can require weeks or months to translate and test an app depending on word count, test and bug complexity, but if content is locked before the work begins it will enable a localization team to provide accurate timeline and cost estimates, and ensure a relatively simple, hassle free experience. This is the case whether an app is released in English first, followed by localized version(s), or shipped in multiple languages simultaneously (aka sim-ship).
See below for a snapshot of the steps that make up the localization process:
- Lock the string file
- Translate in-app and store content
- Review and test translated content
- Fix localization issues and bugs
- Submit for store approval
Version control and change management
While updates to an app, bug fixes, etc. are inevitable, lock content (i.e. String Lock) before kicking off localization and avoid changes until localization is complete. If design/build changes are required during localization, rely on version control, as communication and build management can become especially challenging when adding update upon update to the localization process.
Translate in-app content: The importance of the string lock
To kickoff localization, gather all strings to be translated within a single string file. When sending this to the translation team (whether in-house or external), be sure that these files are locked until the initial round of localization is complete. If any changes are made to strings after localization has started, it will be necessary to send the updated string file and ask the translation team to make these additional changes, causing additional overhead work and cost. This could also add confusion to the testing process if the QA team hasn’t been notified of the changes, and/or they end up testing an outdated build. In the end, it’s highly recommended that one respect the string lock.
Translate and upload Meta Horizon Store content
The Meta Quest Developer Dashboard supports the import and export of TSV files for easy bulk localization. Fill in the English store metadata and click Bulk Localization for the recommended steps to localize store content. Then, export the TSV file by clicking Download TSV on the pop-up modal and send it to the translation team from there.
See below for the required Meta Horizon Store metadata:
- App name: Maximum 80 characters
- Short App Description: Maximum 500 characters
- Full App Description: Maximum 1,000 characters
- Search Keywords: Maximum 50 characters per keyword, with a maximum of 5 keywords (optional but recommended). No spaces are permitted within a keyword.
- For tips on how to build keywords, check out the App Name and Asset Best Practices as well as the Store Submission Success Guide
Note: App name localization and why it’s recommended
Localizing an app name helps it look and feel local to international users. While users from western countries tend to have higher English proficiency, users from eastern countries tend to miss the intended meaning of certain titles, and some may even struggle with legibility. With a localized app name, an app will attract a larger audience.
It’s worth noting that most movie studios translate or transliterate their film titles. Transliterate, meaning to convert letters from one alphabet into a similar-sounding alphabet. i.e. Hebrew word חנוכה can be transliterated to Hanukkah or Chanukah in English. For apps that are originally developed in English, we often see that when they target Eastern languages, the transliterated app title is the preferred option, while the original English title tends to be recommended for Western languages due to the higher English proficiency. Take suggestions from a localization team before deciding how to market a new IP in these local regions. For non-localized titles in Asian languages, add the transliterated title as a search keyword for the app in App Manager so it appears in the search results.
Review and test localized content
Translation teams rely on the English source text and developer notes to ensure the most accurate translations, but this has its limitations as linguists are typically unable to view the full app experience (UI design, narrative context, etc.). It can be difficult for them to understand the connection between each string in a string file, and there is the potential for bugs during this process such as translations not displaying as intended, lack of support for special characters, and translated text overlapping with the UI. This is where quality assurance testing specifically for localization is needed. Often called Localization Quality Assurance (LQA), this process traditionally includes professional, bilingual QA testers to review the localized build, enabling these updates to be improved and localization-specific issues to be fixed with increased efficiency.
In regards to UI, see below for common UI bugs found during LQA testing:
To prepare for LQA testing, share the translated string file with a LQA team along with all other materials shared with the translation team. Deploy a new build with the latest translations implemented and add the LQA team to the build channel. Ensure the LQA test plan includes the most efficient paths to test localization-focused elements of an app. For example, guide them to skip certain areas that are not affected by the localization process, and ensure that all areas that include translation-focused updates are triggered. Also be sure to provide a debug tool so that they can skip through sections of the app that do not have localized design changes or translated text.
To wrap-up the LQA phase, deploy a new build with the localization bugs resolved and have the LQA team verify these updates. Repeat this process until the LQA team has approved the overall quality of new, localized build without any major outstanding issues, and get ready to submit the app for store approval.
Submit localized app for store approval
Follow the steps below to submit a localized build for store review.
- Provide all required store assets following the App Review Guidelines.
- Enter localized store metadata: App name, app descriptions, and search keywords. For a quick and easy update, import the translated TSV file by selecting Bulk Localization within the Developer Dashboard.
- In the Specs section of the App Manager, add any new Supported Languages at the bottom of the page.
- Update and save any other data or assets to be included within the new localized version
- Submit the app by selecting Save & Continue
- Tip for launching a localized app: Bundle the app localization update with a major content update for a better chance to get featured on the Store.
What’s next?
When the app is approved and has been released to the public, monitor the analytics provided in the developer dashboard. Leverage this data to inform future updates that further improve app reviews and general popularity.
For each content update, repeat the localization process. Plan accordingly so localized content is released on the same day the app is released for the English audience to simplify launch communication and messaging.
To learn more about how to optimize an app utilizing the built-in analytics and improve app discoverability, check out the App Analytics, Reviews and Discoverability Guide.
Did you find this page helpful?
Build with Meta
Virtual reality / Meta Horizon
Support and legal