Your popular app is stable and bug-free. The new design is just stellar, but does your app support languages other than English?
If your answer is anything other than “yes,” you need to act on it before it’s too late. As the internet is making the world a smaller place, assuming that everyone will use your app in English is just inconsiderate. Internationalization is important in order to reach the global market.
As the internet is making the world a smaller place, assuming that everyone will use your app in English is just inconsiderate.
App localization (l10n for the nerdy folk) is the adaptation of an internationalized app to fit a specific language or culture. It isn’t just displaying your strings in a different language. It also involves using the correct formats for data like dates, times and quantities.
In this blog series, I’m writing about localizing Android apps in three parts:
- String resources
- Common mistakes people make while localizing
- Tools to aid app localization
This part will focus on string resources — what they are, how to define them and use them in your code.
We’ve spent the last few years building an Android app for the most remote, rugged parts of the world. Here are our learnings on how to build apps for the “next billion”.
What Are String Resources?
Hard-coding text and assets directly into code will make app localization difficult, if not impossible. Android SDK solves this by using resources. Resources are text strings, layouts, sounds, graphics, and any other static data that your Android app needs.
An app can include multiple sets of resources, each customized for a different device configuration. When a user runs the app, Android automatically selects and loads the resources that best match the device. Export all your strings into res/values/strings.xml to make localizing strings easier.
To provide alternate values for your resources, use multiple resource directories with configuration qualifiers like res/values-fr-FR/strings.xml for French as spoken in France. The localized string resources for your application must be in the res/values-<language code> or res/values-<language code>-<country code> folder. (More on why it is better include the country qualifier later in this series.)
Here is an example of your default string resources in res/values/strings.xml. We usually supply resources here in the en-US locale.
An alternate version of the above resource file in French as spoken in France will be placed in /res/values-fr-FR/strings.xml.
Using String Resources in Layouts
To use your resources in layout XMLs, call that resource using its resource type, which in this case is @string. Android will automatically select the appropriate resource for the selected configuration. So, @string/hello_world will show up as “Bonjour le monde!” when the locale is set by the user to fr-FR, and “Hello world!” will be displayed otherwise.
Here is an example of a TextView using a string resource:
Using String Resources in Code
The identifiers of all our string resources can be referenced in code using R.string. Just like @string.hello_world in layouts, R.string.hello_world will be used in code.
The above code gives the same result as using android:text in your XML.
You can format your resource strings just like we do String.format(). You use Context.getString() for this purpose.
We all don’t speak the same language. App localization opens up your app to a larger audience, which translates into increased sales and increases the chances of your app becoming a worldwide hit.
Resources are just one part of localizing your app. Stay tuned for the next blog in this series, which will help you not break language and avoid common app localization mistakes!
Coming soon in this series:
- Android Localization: 10 things that are not as easy as they seem.
- Easier translations and collaboration with Weblate
Header image credit to Soner Eker.