VR App Localization - Planning and Execution Guide
App localization enables you to reach a global audience by not just translating text and voice over content, but also updating elements of your design to ensure that it is enjoyed the way you 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 your app.
This topic contains the following sections to guide you through the app localization process:
- How to plan and design your app for VR app localization
- Execute your localization process
- Submit your localized app for store approval
- What’s next?
How to plan and design your app for VR app localization
To help save time and resources during localization, we recommend that you design and engineer with the mindset that you will eventually translate your application and share your experience with a broader audience. See below for a series of best practices that you can implement as you plan your development process and move into an alpha version of your build.
Prep your 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 your localized content, and we recommend that you keep in mind the following as you plan and build your string file for maximum efficiency.
- Assign one point-of-contact on your 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 your app. This will streamline your 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 your strings. If you must, 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.
Build localization-ready UI
Designing and developing flexible, easily resizable UI will save you 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 your 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 your localization process when you need to manually wrap each word, 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 your 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 your app within the developer notes.
- Be sure to perform a full round of review on your strings prior to kicking off your 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 your app
While the Oculus App supports 25 languages, you may decide to localize your app targeting only a few specific languages. Your 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 Oculus platform SDK or native Android methods, then use the object to determine what localized version of your 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 your app so that users can choose their preferred language. If you do not 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.
As you work to manage your localization files, be sure to also consider using Language Packs as these can reduce your installation app size.
Test font support
To ensure that your localized content is consistent with your established look and feel, we suggest you research and implement those fonts that fit your original style. There are many free fonts available as well as licensed fonts you can purchase for commercial-use.
TextMesh Pro for Unity: Take any .TTF or .OTF file and generate a font atlas. For larger character sets, remember to scan the text to compute the total used characters.
You should compute all used characters because most font systems like TextMesh Pro convert the font into an image. 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. Do your best 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 your app in those languages if they are common within your target markets. Remember that unsupported glyphs (characters) will not display when you deploy your test build, or may appear simply as squares.
Execute your localization process
You’ve prepared your app to ensure a smooth and efficient localization process, and you know which languages you will target. Here are the best practices and considerations you should have in mind as you move forward with localizing your app.
Add localization into your release pipeline and plan accordingly. It can require weeks or months to translate and test your app depending on word count, test and bug complexity, but if you lock the content before the work begins it will enable your localization team to provide accurate timeline and cost estimates, and ensure a relatively simple, hassle free experience. This is the case whether you release in English first, followed by your localized version(s), or ship your app 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 your app, bug fixes, etc. are inevitable, you must do your best to lock your content (i.e. String Lock) before you kickoff localization and avoid changes until localization is complete. If design/build changes are required during localization, you’ll need to rely heavily on version control, as communication and build management can become especially challenging when you’re adding update upon update to your 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. As you send this to the translation team (whether you have an internal team or external service providers), be sure that these files are locked until the initial round of localization is complete. If you make any changes to the strings after localization has started, you’ll need 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 you respect the string lock.
Translate and upload your Oculus Store content
The Oculus 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 your store content. Here, you can 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 Oculus 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 your 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 the app name helps your product look and feel local to our international users. While Oculus users from western countries tend to have higher English proficiency, we’ve found that 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, you show that you care about these local users, and hopefully attract an even larger audience to your content.
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. We recommend that you take suggestions from your localization team before deciding how to market your IP in these local regions.
Review and test your localized content
As you may have noticed, translation teams rely on the English source text and your 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 your 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 your LQA team along with all other materials you 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 your 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 your app that do not have localized design changes or translated text.
To wrap-up your LQA phase, deploy a new build with the localization bugs resolved and have your LQA team verify these updates. Repeat this process until your LQA team has approved the overall quality of your new, localized build without any major outstanding issues, and get ready to submit your app for store approval.
Submit your localized app for store approval
Congratulations! You are almost ready to launch your localized app. Follow the steps below to submit your 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, you can import the translated TSV file by selecting Bulk Localization within the Developer Dashboard.
- In the Specs section of the App Manager, add your 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 your app by selecting Save & Continue
- Tip for launching your localized app: Bundle your app localization update with a major content update for a better chance to get featured on the Oculus Store.
What’s next?
When your app is approved and has been released to the public, monitor the analytics provided in the Oculus developer dashboard. Leverage this data to inform future updates that further improve your app reviews and general popularity.
For each content update, you will need to repeat the localization process. We recommend planning accordingly so you can release the localized content on the same day you release it for the English audience to simplify your launch communication and messaging.
To learn more about how to optimize your app utilizing the built-in analytics and improve app discoverability, check out the App Analytics, Reviews and Discoverability Guide.