Should you localise your mobile app?

If you have an app that could be used by people who speak different languages, you might consider localising it so it feels more natural to more of your audience. But is it worth it for your app? Well, as always, it’s all about the business value. If the extra business value you can drive with a localised app outweighs the costs of implementing localisation, then yes, you should localise your app. Let’s take a look at how you weigh up the costs and benefits for your app.

What is localisation?

A localised app uses device settings to respect a user’s locale. The largest component of this is language, but it can also include things like date and time formats, currency, and number formats.

What are the benefits of localisation?

Localisation allows you to meet your audience where they are. It makes your app accessible to a wider audience, that might not otherwise choose to use your app. And since it will feel more natural to those in other locales already using the app, it will encourage people to use the app more often and for longer. A bigger audience, using the app more, equates to more user engagement. Since user engagement is the way you drive business value from mobile apps, localisation can directly increase the business value you can drive from the app.

Depending on how you set up localisation, you may also be able to change text in your app remotely, without needing to release a whole new app version. Whilst on its own this isn’t reason enough to localise your app, it does give the added benefit of being able to fix typos quickly, and being able to get faster feedback if you’re testing the impact of different text, for example when optimising your app onboarding.

What are the costs of localisation?

Localisation requires effort to set up and maintain. There are four main areas of work you’ll need to do. They are:

1. Change the code to support localisation.

2. Set up and manage app translations.

3. Create localised versions of App Store / Play Store pages.

4. Create localisations of user facing communications.

Let’s look at each of these in detail.

1. Change the code to support localisation

There are two main things that you’ll nee to do in your code to support localisation. The first is to wire it up so that everywhere that displays text, first looks up the correct translation. This can be quite straightforward if your code is well structured, but could be much more time consuming if not. There are some nuances around supporting dynamic text, which is when a phrase is generated on the fly depending on data in the app. A simple example is plurals, where you might display something like ‘1 message’ or ‘5 messages’ depending on the data. In different languages this won’t necessarily be a one to one substitution. Words in the phrase might be in a different order, and different words might need to be dynamic. Your lookups need to account for this to provide the correct translations.

The second is that you’ll need to make sure that your UI (user interface) doesn’t break when you fill it with translated text. Text in other languages will take up different amounts of space, and that could mean text is cut off, squashed, or oddly spaced. At best this will leave you with an app experience that is less appealing, and at worst your app will be unusable. Either way, if you don’t fix it, your user engagement with the app in different languages might even be worse than before you added localisation. If the app was designed and built to be flexible, with the UI able to adjust itself around elements of different sizes, this won’t be a large problem. However if this hasn’t been considered before, it could be a lot of work and an expensive undertaking.

On top of how well structured the code is and how flexibly the UI was built, the size of your app has a big impact on the effort required to support localisation.

A bigger app = more changes = more effort = more cost

I’d like to add a quick note here about getting off to the right start. If you are in the early stages of development of your app and you’re wondering if you should localise it, you absolutely should.

There are no additional costs to setting your code up to be well structured and have a flexible UI at the start. You can set up localisation whilst only supporting one language, so you won’t have to cover the cost of translations until you’re ready. Even if you never add an additional language, you’ll get the added benefit that future changes, such as a rebrand or a spruce up of your app’s appearance, will be much easier.

Once you’ve set up localisation for one language, you’re done the bulk of the work in the code. Although you might need to tidy up the UI in some places, there will be very little to do in the code for each subsequent language you add.

2. Set up and manage app translations

The next area of work to think about is setting up and maintaining app translation files. You’ve set up your code to look up each piece of text to display. Next you need to add translations for each of those pieces of text in every language you are supporting.

There are various ways to support this. You can pay a translator to translate your app text. You could crowdsource enthusiastic users who want to help out. You could use AI to create translations for you. Or you could use a 3rd party localisation service to provide translations for you.

Once you have the translations, you need to get them into a format that your app can lookup. You could get your techies to manually transfer translations into lookup files. You could train your translators to create the lookup files directly. Or you could use a 3rd party localisation service to provide you with an easy interface to add, generate and edit translations, and automatically deliver them to your app in the format it needs. This last approach is less error prone and more user friendly.

Then you need to be able to verify for each language that all the text in your app has a translation, is translated correctly, and is displaying correctly. That’s really tricky for a language you don’t speak, so you’re going to need help for any languages where you don’t have coverage. You could get translators to check your app, or you could wait for friendly users to report errors to you. The level of effort you need to go to here is determined by how mission-critical having correct translations is to the success of your app.

Finally, don’t overlook the ongoing maintenance of supporting localisations. When you add any new text to your app, you will need to add a translation for each of your languages. This can be problematic if you can’t access on-demand translation, because it could block changes to your app, and make your app releases harder to manage. A 3rd party localisation service can help by making it easy for you to track what text needs translating, and by allowing you to make changes to translations without needing to release a new version of the app.

So the cost of managing your translations depends on the number of languages you are supporting, the size of your app and the approach you decide on. Hiring translators isn’t cheap, but a DIY approach can cost you in terms of quality. 3rd party services make the whole process much easier, but are usually expensive. But as your app and the number of translations grows, the cost of a service will be less than the cost of managing the process manually. The good news is that once you’re set up for localisation, changing to a different approach is relatively easy, meaning you can start simple and level up only when you need to.

3. Create localised versions of App Store / Play Store pages

The next area of work to talk about is creating localised versions of your App Store and Play Store pages. This is essential since one of the major benefits of localisation is to make your app accessible to a wider audience. Without localised store pages, that audience would never know, stopping you achieving the increased engagement you hoped for. Creating localised store pages isn’t trivial, and is more work than it might seem on first glance.

First of all, you need to add translations of the main text on the store page. If you’re leveraging ASO (App Store Optimisation) to drive downloads, you’ll need to make sure that your keywords are optimised for each language. You’ll need to make changes to marketing text as and when required, and provide translations for ‘What’s New In This Release’ with each release.

The most difficult area to set up and maintain will be your app screenshots. You’ll need to provide each of your marketing screenshots for each required screen size for each of your languages. As an example, if you had five screenshots at five different sizes and three supported languages, and you’re in two stores (App Store for iOS and Play Store for Android), that would be 5 x 5 x 3 x 2 = a staggering 150 screenshots that would potentially need updating when you make a change! There are tools you can use to automate some of this work, but you can’t always get the results you need using them.

So the cost in this area is made up of the cost of translations, setting up automations and / or the design work needed to create and update screenshots in different languages.

4. Create localisations of user facing communications.

The final area of work to consider is the cost of localising user facing communications. Here I’m taking about the notifications and emails you might be sending your users to keep them engaged with your app. Sending these communications has an associated cost, particularly if you’re using 3rd party services to send them. It follows that you should send these comms in a user’s preferred language to maximise your ROI (Return On Investment ) for this spend, because you’re unlikely to get much engagement if you send someone a message in a language they don’t understand. There are a couple of aspects to consider here.

First, you’ll need to translate communications into the required languages.

Second, you’ll need the capability to send different messages to different users. This will be easier if you’re using a 3rd party service, but you might need to make technical changes if you have your own implementation.

Finally, you’ll need a way to segment your users and record their chosen language. Whilst your app will display the correct language based on a user’s device settings, you won’t have access to this on your messaging platforms by default. You’ll need to set up a way to save this preference for individual users.

To sum up, the cost here depends on the number of languages you are supporting, and any up front technical work you’ll need to do to support sending the right translation to the right user.

Gotchas

There are some gotchas you should be aware of with localisations, otherwise you could get caught out by spending a lot on localisation, but not getting the full return that you could.

First is that I’ve mostly focused on language in this article, but as I mentioned at the top, there are other elements that vary across locales, such as date and time formats, currency, and number formats. In the US, dates are written in a different order to in the UK (‘MM dd YYYY’ vs. ‘dd MM YYYY’), and it’s really confusing to see them in wrong format for your locale. Military time, or 24h clock is preferred in Europe, but is completely alien to US users. And in Europe, a decimal place is denoted by a comma rather than a point. If you don’t also support these localisations, users won’t feel at home in your app, even if you support their language, and that will translate to less engagement for you.

Second, you need to consider the direction of flow of the languages you want to support. For example, English is LTR, or ‘left to right’. If you wanted to support a direction that is different to your primary language, it would be a much more involved task. As well as the aspects I’ve already discussed, you’d also need to change the layout and flow of graphical elements of your UI. If you’re considering supporting a different direction, you could be better off building it as a separate app, developed by people who understand the language direction natively.

Finally, there are other cultural differences in different locales that can impact how at home users will feel in your app. An example that is often cited is that the colour red is associated with danger in the west, but is seen as lucky in China. Even between European countries, different phrasing, styling and colours might convey brand image or drive engagement with different levels of success. For that reason, it’s not uncommon for enterprises to have separate teams in different regions to independently develop different versions of the same app. So be aware that simply adding one to one translations might not generate the results you were hoping for.

Weighing up the costs and benefits

So, how should you go about weighing up if localisation is worth it for your app?

Start by looking at the additional market that you could reach if you localised your app, and the potential you have for converting that extra engagement into business value. If you have an app that is universally applicable, you could be leaving a large amount of value on the table by not localising. You could get a feel for this at minimal cost, for example by creating a localised store page and tracking how many additional views and downloads it generates, or by adding a button to your app inviting users to register interest in translations in different languages.

Next, review your code to assess how much work it will be to make the necessary code changes. Look at the size of the app, how difficult it will be to add translation lookups, and the degree to which you’ll need to change your UI to make it flexible. The best way to get a feel for is to test it out, by applying the changes to a single screen. You don’t have to drive this from device settings, and you don’t need to use real translations, substituting in obviously different text will get you the information you need (just be careful not to accidentally release it!). From there you can get a rough idea of how much work would be needed, and how much that would cost.

Then, review any other technical changes you might need to make, for example around segmenting for communications campaigns, or creating automations to help with App Store localisations.

Finally, look at what would be involved both in getting the translations you need, and in managing and maintaining those translations. Look at the costs of engaging and retaining any translation services you would need, and the cost of 3rd party services that you might use for managing everything. For services you are interested, try to get free trials so you can get a sense of what’s involved, and the size of any integration you might need to do. For anything you choose to manage in house, don’t forget to account for the cost of the time it will take you to do so.

This will give you a sense of what you stand to gain from localisation, and an order of magnitude of how much it will cost. Using this, you can make an informed decision as to whether or not localisation is a good idea for your app.