Before you take your app to the global market, you need to get your code up to scratch. This process is known as mobile app internationalization, and we’ve created this guide to get you off to a flying start.

What is app internationalization and how does it differ from localization?

Not to be confused with localization, app internationalization is the process of customizing your app’s code to make sure it is ready for localization. Enabling it to be changed to a host of world languages once you release it.

It is part of the localization and greater globalization process, but you should consider it as a step before the core localization process.

Internationalization involves separating the content you have from code and allowing the app to run using external files. Using this method, you can translate the app easily by adding new external language files.

This sounds complicated but, if done right, whenever and wherever a user opens your app, be it Korea, Germany, or the USA, they open it to content localized to them.

What to consider when internationalizing an app

Before you rush to get your dev team together, take a moment and consider what internationalization involves.

What content needs localizing?

Internationalization is your step before the localization process. So, understanding what content you need to create is key.

When localizing your app, you will localize all your content. This means you must also prepare to customize all your code.

This, of course, includes much more than just text, but also images and graphics and videos as well. Your code needs to be prepared to display a range of localized content, depending on what region you are launching it in.

Context is key

When it comes to internationalizing, context is key. There can be many variations of the same language, all littered with subtle linguistic differences. So be prepared to code the local language variants for where they are being displayed.

Normally we would take the US and UK as an example, but other languages also face the same differences. For example, if your app is being launched in Spain, but also Argentina, it is important that you prepare two sets of external files. One in Castilian and one in Argentinian Spanish. Although they are the same language, there are key differences in tone, word spelling, and colloquialisms.

Build an app with the right fonts

An extension of picking the right language variant is knowing that not all fonts contain suitable characters for certain languages.

You will need to code your app with specific fonts that allow the special characters from different languages to be used.

Spend some time on this because it is important to keep all your fonts consistent across your apps. It’s a key part of your product’s branding and style. So, when picking your font, make sure it has cross compatibility.

It’s not as easy as ABC

Sometimes special characters will be the last of your internationalization worries. Obviously, not all languages are going to be the same, and you will also need to provide the structure for alternate alphabets to be used in your app.

This is also true with dates, times, numbers, and text direction. Your app will need to change to reflect the differences in different locals. An example of slight change would be the simple switch from US to UK date formats.

However, more complex tasks will include changing a horizontal, left-to-right reading style to a vertical, top-to-bottom method to accommodate a Chinese, Japanese or Korean market.

How to internationalize your app

Now you know what to consider before internationalizing your app, how do you go about doing it?

Plan ahead

Before you internationalize your app, always start by planning. When planning ahead consider the following:

Be flexible

There is no one way to modify a code that will perfectly adapt to every new location. This makes code flexibility a key thought whenever you go into the internationalization process.

Be like the river and prepare yourself to adapt and change your code for regions as you go along!

Don’t over do it

Alongside being flexible, it is important to remember not to overdo it. It's easy to get caught up in a ‘just in case’ mentality. But if you’re not planning to enter that region and are never likely to, you shouldn’t go about changing your code for it.

To clarify, you don’t need to support languages and locations you won’t be using. Only create for the countries you know you will expand into.

Keep up to date with the law

This is a big one. Make sure the app complies with all local laws. Regardless of where the user finds it, you’ll be held responsible if it breaks the law in that locale. A good example is gambling apps. Gambling laws differ from country to country, so prepare your code to adjust certain aspects of the app depending on which country you are localizing it for.

Keep in mind that you may also run into legal issues depending on how your app is being used. So, make sure you know the laws of where you are releasing inside and out.

Internationalizing your app

You’ve planned ahead, you’re ahead of law, and you’ve got flexibility on the mind. Now it’s time to get into the techy bit.

Android App store internationalization:

To internationalize your Android app, you will need to transform your content into strings, specifically the “strings.xml” file. This will be the hub file for all your data.

“string.xml” is like a database for your content which allows you to set further strings such as:

>Text_a =”headline text”

>Text _b = “paragraph text”

Once you’ve integrated your content inside of the string file, you’ll ‘call’ the string inside the code. This lets your app automatically know which translation to pick for each string.

The app can find the file by following the route:

“res/values/strings.xml”

Your app will work out where to extract the data by using a country code integrated into the XML file name.

So when you localize the strings, you add the country code to the end.

For example, res/drawable-fr/ (for France)

According to Androids app developer guidelines,

“The default resource set must also include default drawables and layouts, and can include other types of resources such as animations:

1. res/drawable/(required directory holding at least one graphic file, for the app’s icon on Google Play)
2. res/layout/ (required directory holding an XML file that defines the default layout)
3. res/anim/ (required if you have any res/anim- folders)
4. res/xml/ (required if you have any res/xml- folders)
5. res/raw/ (required if you have any res/raw- folders)”

Note: If your app runs a locale that doesn’t have its own XML file, it will stop running and display an error message.

iOS App store internationalization

This is largely the same process as Android, however, instead of using a .xml file you will use a .strings file type.

The default name for all your localized text strings on iOS is “Localizable.strings”.

When creating a .string file for iOS, you have to define the key and content inside. All your lines must end with a semicolon.

The key is the .strings name that you will integrate into the app's code.