Behind the Screens: App Localization 101

The world of app localization can seem a complex place. For starters, there’s a hefty helping of terminology to unpack and understand; what is a string? A repo? What does it mean to cut a build? And how does the content for translation travel all the way from software developer to translator? There’s a lot to tuck into here, so consider this part one in a short series that takes you behind the screens to explore the work involved in creating an app that’s truly global. In this first instalment, we’ll get a little more familiar with the two terms that sit at the centre of it all – internationalization and localization.

Internationalization vs. Localization

Localization (l10n for short) is the part of creating a multilingual product that we tend to be more familiar with in our daily lives, and refers to adapting content for specific markets or languages. This can include a wide variety of activities ranging from translation, transcreation, and copywriting, to changing images, fonts, or colours to better represent each market. Depending on the scope of the localization work, individual languages or regions might have very different versions of the same product – as each version has been custom made for success in particular markets.

Internationalization (i18n), on the other hand, is the tech infrastructure that allows an app to work well in any potential language or market. Examples of i18n practices include using Unicode encoding so that text in all major languages will display correctly, building responsive user interfaces that can dynamically resize for longer or shorter text, using internationalization libraries to help handle conversions of numbers, and externalizing strings from the rest of the app’s code (more on externalization another day).

Good internationalization is crucial to allow tech companies to scale, because it is not sustainable to customize an app for every individual language. Let’s say, for example, that we have a successful English-language rideshare app, and now we want to expand into a few new territories. Not only do we need to translate all of the words in the app and transcreate all of the catchy headlines we use to attract users, but what happens when we need to show our users how much their rides cost, or what time their driver will arrive? Do we need to ask our linguists to tell us where to put dashes, slashes, dots, commas, or colons whenever we display a number? Our app uses one sentence to tell drivers they are picking up “a passenger” and another sentence when they’re picking up “passengers” but what about when we translate into Polish, for example, and we need different sentences depending on if there is one passenger, two passengers, or five passengers? How will our app handle all of these custom scenarios, in every language and region we want to support?

It doesn’t make sense to do these customizations for every new market. Instead, if we set up our app to work with internationalization libraries that manage numbers and pluralization – computers can help us remember and implement these rules. Without internationalization to give us this framework, we would have a lot of custom work to redo every time we plan to enter a new market.

Best Practices: l10n and i18n

Now that we have a handle on what these terms mean, let’s take a look at some best practices that we can put into action.

●     Responsive and flexible design

A translation can often be much longer than the original source text, so any design elements in an app user interface need to accommodate both long and short text automatically. Fonts and text boxes should automatically resize when text is long, and text should wrap automatically to the next line instead of allowing long words to shoot off the edge of the screen.

●     Font support

Fonts need to support all characters in all languages so you don’t end up with errors in the middle of your strings – following Unicode standards helps ensure special characters won’t be corrupted.

●     One message, one string

Lastly, wherever possible, strings should not be concatenated. “Concatenation” is a technical term for making one message out of multiple short strings. It can save time when writing code, but it is not considered good internationalization practice because there’s no guarantee that the phrases you have combined in the source language can be combined in the same way in all translation languages.

 An example of concatenation would be:

 String 1: “You have_____.”

String 2: # messages

String 3: # friend requests

String 2 and String 3 are options that can fill in the blank in String 1.

This is a problem for localization, because translators have to ensure that “You have” agrees with both string 2 and string 3, as well as anything else that could conceivably be added later on – which is not possible in many languages because the gender of a verb depends on the gender of the noun(s) in the sentence. Also, if syntax rules differ between the source and the target languages, and the linguists aren’t able to change the location in string 1 to insert string 2 or string 3, they may end up with very clunky, unnatural sentences in an attempt fit the pattern set by the source strings.

With internationalization in mind, the correct way to structure this string would be to create two separate strings, each containing its own complete message:

String 1: “You have # messages.”

String 2: “You have # friend requests.”

This way, the linguists can ensure that all parts of the sentence will have the correct grammatical agreements. Remembering “one message, one string” can solve a lot of localization headaches.

Ready for more on the ins and outs of app localization? Dive into our next piece, App Localization 2.0, to untangle the importance of strings when it comes to creating a global app.