Behind the Screens: App Localization 2.0

Following our first instalment on this topic (Behind the Screens: App Localization 101),?you’re hopefully now a little more familiar with both localization and internationalization, and how they work together to create an app that’s geared up for global success? We hope that’s a resounding “yes”, as it’s time to journey on and unpack the next aspect of app localization – externalizing strings.

Getting Strings Straight

Firstly, what exactly do we mean when we talk about “strings”? In computer science terms, a string is “a type of data that represents text” (source). And in the simplest of localization terms, strings are what we translate. But if you’re not a software developer and you’re looking at a text file full of code, it’s not always obvious what is considered a string. Different coding languages tend to use words that look like English text but are actually part of the code holding the app together (“initialize,” “variable,” “class,” etc.). You might be tempted to translate everything that looks like an English word, but if you translate something you shouldn’t, you could break something in the process. So, how do you know what is a translatable string and what isn’t?

Omit the Risk

The good thing is, when strings are externalized, you don’t have to worry about this. When strings are externalized, that means they are saved in a separate file, outside of the source code for the rest of the app. And because the text displayed in the app is separated from the code that forms the app, we remove the risk that a linguist will inadvertently translate something they shouldn't and by doing so, break the code. Linguists are also spared from having to parse through complicated code in order to find what they need to translate. Translations can also be updated with ease, as the entire code of the app need not be updated whenever a translation changes.

Finally, externalizing strings reduces the risk involved in sharing content with vendors. If you are working with a language service provider (LSP) or a freelance translator, you only need to share the files that contain the content for translation. You do not need to expose your entire code base to an external user, which reduces the risk of leaking proprietary information. Separating your strings from the rest of your code is an important practice both for information security and for smooth localization.

Resourceful Storage

The externalized files where all strings in an app are stored are called “resource files.” The source language and all of the translation languages each exist in their own separate resource files.

Essentially, resource files are a two-column table of keys and values. The keys uniquely identify every string, and tell the app where to display them, while the values are the strings that are actually displayed on screen to the user. When we translate a resource file, the keys stay the same, while each of the values gets translated. Once translation is complete, you receive back one resource file per language, where all of the values have been replaced by translations.

Then when you open an app on your mobile device, the app determines what language resource file to show you by reading the language your device is set to. The app then loads the corresponding resource file for that language, and for each key it finds the corresponding translated value in the resource file and displays that string of text to the user. Pretty nifty!

And just before you go, it’s also worth noting that different platforms have different requirements for naming and formatting their resource files. The most common ones you will encounter in your software localization journey are:

●????Android: strings.xml

●????iOS: localizable.strings

Still with us? Then stay tuned for our last instalment on app localization, where we’ll explore the translation pipeline right through to the final phase of publishing your app for the world to enjoy!