It’s 2017: If you are publishing content or producing software in the current tech landscape, it’s likely that you are going mobile…and in more than one country. If localizing your mobile software has not been a priority for your organization in the past, you may benefit from reading recommendations from people who deal with software localization on a daily basis.

Mobile vs. Traditional Software

Recommendations for localizing mobile apps and software are very similar—mobile apps are simply a special type of software application made for mobile platforms.

So what is the difference?

One major difference is that mobile apps have space limitations. Translated text often ends up being more characters than the original English. For traditional desktop applications, it is often preferred to design an interface that allows for text expansion, but the space simply may not be available on a mobile display. Often companies will turn to text abbreviations as a stop-gap, but this can cause user confusion if done without care or as a last-minute fix. To avoid this, some thought should be put into where abbreviations are appropriate and how to use them consistently and meaningfully.

Another important difference between mobile app localization and desktop applications is the variety of platforms that are used in the process. List the platforms that your app runs on as well as the supported device configurations. Do you publish on iOS and Android, for example? Your developers may already be working with consistent design guidelines, but it is also good to look into reusing the text as much as possible to ensure consistency on both platforms.

If you support many device configurations, this probably also affects the testing effort.

Tip: Start your testing process on the smallest display that you support. If the content fits, it will usually fit on larger displays as well—a final check for aesthetic purposes is recommended, though!

When testing on several different device configurations, testers and developers often make use of emulators. There may be a limitation if additional hardware is needed, but otherwise, emulators can be helpful.

Internationalization

The process of readying your software for the localization process is called internationalization. Some of the key phases of the internationalization process are as follows:

• Place UI text into separate files—not in the programming code
• Set up a multilingual architecture so your app can run in the language that is set on the user’s device
• Design a localization-friendly interface
• Avoid text on graphics
• Make an inventory of country adaptations

If you are working with a language service provider with a technical team of localization engineers, they can help you with the internationalization initiative. They will not be as deeply involved in the code as your developers are, but can add valuable insight by pseudo-localizing your text or giving advice based on their experience with other projects. Pseudo-localization is performed by replacing content with dummy text showing special characters—and usually extending the text length. This is a good test to make sure that your app does not produce unexpected bugs and that your interface allows for text expansion.

What To Send To Your Language Service Provider

Professional translators will typically translate in a translation environment that links to translation memory (a database of translations that offers identical and similar translations as a reference) and offers integrated QA tools. Having your language service provider “parse” (read in) your “strings” or XML files directly will save you tedious copy-and-paste work to transfer the translatable text into Excel or other formats. Localization engineers who do this preparation work will also detect items such as variables and protect them from accidental overwriting. If strings are parsed with their identifiers, updates are quick and easy, because the translation memory software will tell you which strings have been updated or added.

Very often, several parties are involved in reviewing text and making changes (e.g., a local marketing office). Integrate everyone into the process. Ideally, comments from a local reviewer can be made in an environment that is intuitive to use, but also captures review changes in the translation memory. Otherwise, you need to enter the changes again and again in future updates.

If your localization provider has a trained technical team, you can outsource the full process (i.e you send them the complete environment for compiling the app and they send back the localized app, ready for release). This is only feasible if your confidentiality rules allow the code to be sent to an external party. Even if it is allowed, you will still want to take some time to determine the most efficient process. For example, weighing the startup time and effort needed by your language service provider against the efficiency gain of saving on “back and forth” between the linguists and your developers when implementing bug fixes. Find a language service provider who can partner with you and will explain the pros and cons to you transparently.

Testing

While your QA team probably uses a structured testing approach using documented test cases and a central bug-tracking database, it is smart to integrate testing into your localization process as well. At a minimum, you should have your app tested by native speakers to eliminate the risk of untranslated text, text in the wrong place, out-of-context translations, or truncations that may not be visible to non-native speakers. If you involve your language service provider in testing, you add valuable linguistic insight to the translation process.

In order to ensure that your testing process is consistent and meets your criteria, you should document the localization test or ask your language service provider to suggest a localization test plan for you to sign off. There are a range of different approaches as far as test coverage is concerned, ranging from the 20/80 rule to full coverage of every single text item that the software contains.

If your testing effort results in more than a few issues, it will be helpful to use a bug-tracking system where both you and your language service provider log in and share the bugs found during testing.

Conclusion

There are many variables to mobile software localization, but you can get ahead of the process by thinking about it early in the development process. It is also highly beneficial to partner with a language service provider who can bring their linguistic and technical experience to your project, and do so in a flexible way to find a process that is most efficient for your needs.