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:
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.
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.
See below for an example XLS file formatted for localization.
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:
<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.
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.
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.
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:
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.
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.
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:
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.
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.
Congratulations! You are almost ready to launch your localized app. Follow the steps below to submit your localized build for store review.
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.