Making your app internationally accessible can open it up to a huge audience of previously-undiscovered users. By default, an app can be available for download everywhere in the world on Google Play and the Apple App Store – there are settings on the app stores that allow you to select which regions your app is available in.
But unless you specifically localise your app to display in other languages or with other regional content, users around the world will only see the app in its unlocalised state (e.g. in English with references to Australia), rather than seeing the content customised to their needs.
What in-app content needs to be localised?
Text is an obvious one; you’ll need translations for the copy in your app. iOS and Android translations are implemented via ‘strings’, which act as placeholders in the code to display translations according to the user’s settings.
For example, a heading in the app might say “My Profile” in English, but instead of this text being hard-coded, it’s represented in the code by a string labelled my_profile. ‘Based on a user’s language settings, the app will display a single translation for the user within the range of translations associated with that string. If your existing app copy is hard-coded, it will need to be ‘internationalised’ to use strings before any translations can start to be implemented.
For Vodafone Foundation’s DreamLab, which is currently localised for 17 different international markets, we use a translation tool called POEditor for our iOS and Android copy. POEditor is a database of strings and their translations, organised by language. Different translators can log in and update the translations for a particular language, and then we can export all of the finished translations and ingest them into DreamLab’s code.
Translation challenges and tips
- Provide as much context for your translators as possible – This will minimise the amount of translations that need to be replaced once they’re seen in-app.
- Google Translate can’t be relied upon to produce decent app translations – It is not a replacement for human translators.
- Translations will need to be formatted in the same way to display the same way for every language – For example, if your English translation has a new line in it to display the copy across multiple lines in the app, your German translation will also need to include that new line.
- If a translation is much shorter or longer than the original copy, it may not display properly in the app – For example, the translation may not fit on a button properly. In these circumstances, you can either update the design/UI of the app, or you can source a replacement translation of a more appropriate size.
- Some translations may actually require logic changes – For example, a single word in English may require multiple translations in Greek depending on the context that word is being used in.
You may not want to keep all of the translations within the iOS and Android code. For example, about a third of the translations for Vodafone Foundation’s DreamLab are served to the user from the backend, with different content served depending on the user’s region setting. There are advantages and disadvantages to the localised content coming from either source, so the split (if any) between these sources can be a strategic decision according to the nature of a particular app.
What else needs to be localised?
First off, there might be images that you need to localise. These could be assets like logos, photos, illustrations or infographics. While a logo or infographic might be obvious candidates for localisation, as the words inside these images may vary according to the international region, you may also want to change some of your photos or illustrations so they resonate better with your users culturally. What looks like ‘fun’ or ‘terrible’ to one part of the world may not read the same to another. So you may want several different versions of an image to appear depending on where in the world your users are.
You will probably need to localise any legal documents in your app too. For example, it’s likely that you’ll need different Terms & Conditions and Privacy Policies depending on the region and/or language of the user.
And finally, you may need to localise any contact details supplied in the app. If French users should contact your organisation using different details than South African users, you’ll want the right contact details to display (or pre-populate) for each group of users.
What about the app’s listings on the app stores?
Every app on the Apple App Store or Google Play has a default listing. A listing includes an app’s public-facing description and screenshots, and may also include items like the app’s Support URL or Marketing URL. When you localise your app for an international audience, it’s strongly recommended that you also create additional listings that will display for users from the countries you’ve localised for, such as a dedicated German listing for German users. The listing that a user sees will depend on their app store settings.
Considerations when localising app store listings
- Some regions can’t have a dedicated listing as the app stores won’t allow it – Instead of seeing a listing specifically for Irish users (for example), these users will see an app’s default listing instead. You may want to consider updating your default listing so that it is more inclusive of these sorts of users.
- Some regions can have dedicated listings on Google Play but not the App Store – Double check what’s possible with both app stores to see what you need to do.
- There are several localised items that need to be added for regions that can have dedicated listings – These include localised app store copy, localised app screenshots and app store artwork, and a handful of other smaller pieces like localised keywords and a support URL for (potential) users.
- There is some app store content that cannot be localised – For example, Vodafone Foundation’s DreamLab can only have one privacy statement URL for the entire app, worldwide, on Google Play.
- Be aware of the 4000 character limit on app store descriptions, regardless of language – A description that fits well in English may not fit anymore once translated, and will need to be cut before it’s added.
How do you determine a user’s language and region?
While Apple and Google handle which app store listings your users will see on their respective app stores, you still need to determine which localised content users see once they’re actually using your app. There are several ways you can choose to do this:
Option 1: Perhaps the most obvious way is to allow users to change their language and/or region from within the app itself, via an in-app menu. Although this means that users can reliably receive the localised content that is most relevant to them, it does take effort to build this user interface and functionality.
Option 2: You can determine the user’s language from their device settings. If the language in their device settings is English, your app will display in English. If the user changes the language in the devices settings to German, your app will display in German. This is a pretty safe option because your app is displaying in the same language as the rest of their phone.
Option 3: You can determine your user’s region from their device settings. This is very straightforward in iOS because language and region are distinctly separate settings, but can cause some confusion in Android as the region settings are nested underneath the language settings. This means that many users assume that the region setting is a language variant (e.g. UK English) rather than understanding the region setting for what it actually is.
Option 4: You can determine your user’s region based on their SIM card. If a user has a German SIM then they will be served German content in your app. If the user has an Australian SIM then they will be served Australian content instead. While this is not a perfect method, it may be preferred for Android apps in particular because it is somewhat more straightforward than using the regional device settings.
You may also want to consider the content that displays if a user’s language and region don’t traditionally ‘match up’. For example, if my region is set to German but my language is set to English, do I see 100% of the app in English, including any references to Germany? Do I see most of the app in English, but the region-specific content displays in German? There is no hard and fast rule for how this scenario must appear in your app, but it’s good to think about this early in the localisation process so that you can plan accordingly.
Final tips for localising your app
- Research and test with local users – When localising for a new language or region for the first time, you may like to send localised screenshots of your app to people who speak that language (or people who are from that region) before it goes live, so that they can check everything is appearing correctly in context.
- Be consistent with updates and improvements – Once your app has been successfully localised, every time that you implement a new feature with new copy, then you will need to source translations for that copy for all of the languages that your app supports.
- Don’t forget the finer details – Every time you do an iOS or Android release you will need to source translations for the release notes (aka “What’s new” copy) for all of the regions your app is localised for on the app stores.
- Look for quick wins – Any localisation changes on the backend are usually much quicker and easier to release to users than localisation changes in the iOS or Android code.
If you’d like to discuss localising your app for an international audience, or you’re simply ready to take the plunge and get it done, please contact the experienced team at Transpire who would be pleased to talk with you.
