When creating any kind of application, it’s important to build it for the users you expect to be supporting. Because of this, it may be necessary to display different strings, images, and other content based on the language or region of your users.
While creating the translations of an app can be a lengthy process, enabling content localization in an Android app is as simple as adding new files and folders to your resources.
Localizing Strings by Language
By default, strings in Android apps are kept in the strings.xml file. This doesn’t change much when enabling localization, except that you will have one strings file for each language you need to support.
To begin, you’ll want to make sure your project hierarchy in Android Studio is set to Project Files ordering, which will split up the different language folders you add.
The default strings file is located under res/values/strings.xml. When you add new languages, the file path will change, adding in the corresponding locale. The default strings file will be located at res/values/strings.xml, while any additional strings.xml files will be located at res/values-XX/strings.xml (with the actual locale in place of “XX”). The locale will follow ISO-639-1 standards.
If your current app language is English, your strings file could look like this:
// res/values/strings.xml
<string name=“hello”>Hello!</string>
<string name=“good_morning”>Good morning</string>
<string name=“good_night”>Good night</string>
To add a strings file for another language, you can use the same keys that you did in your default language file. If you translate an app into Spanish, the strings file would look like this:
// res/values-es/strings.xml
<string name=“hello”>¡Hola!</string>
<string name=“good_morning”>Buenos días</string>
<string name=“good_night”>Buenas noches</string>
If your app is looking for a key in the strings file and can’t find the correct one in a certain language file, it will fall back to the default strings.xml. Because of this, it’s important to make sure you account for all keys for translated strings.
Localizing Strings by Region
So what happens if you need to localize different strings for different regions? Say your default app language is English, but you support users in both the United States and Great Britain. Not only are there slight spelling differences (localization vs. localisation among others), but if you were to localize support phone numbers or contact information, you couldn’t guarantee that they’d be the same in both regions.
In a case like this, you’ll need to include a country code in the file path. The format for using a region for content is similar to using locale. The default path will still be res/values/strings.xml ,and any other file will be res/values-XX-rYY/strings.xml where XX is the locale and YY is the 2-digit country code.
For example, if your English strings file is intended for American users, your file path will look like this:
res/values/strings.xml
When you add in support for British users, you’ll have a strings file at the following path:
res/values-en-rGB/strings.xml
From here, we’ll use the same steps as we did for different languages, but with fewer string keys duplicated between each file.
Localizing Other Content
Much like strings, you may want to display images or other content based on a user’s locale. To do this, just follow the same pattern as you did for strings: adding files and folders tagged with languages and country codes.
Along with the default locale content folders (values, drawable, color, etc.), for every new language or region, you’ll want to add a corresponding folder if the content differs from the default. For example, if you support both English and Spanish, but all of your drawables are the same between the two languages, you’ll only have one drawable folder. However, if you have different images based on the language, you’ll have both a drawable folder and a drawable-es folder if your default language is English.
Tips for Success
- Any strings that don’t need to be localized should be kept in the main strings.xml file. This includes things like product names and placeholder text (i.e. “-“ or “…”).
- Avoid putting text on images. Although images can also be localized, it’s usually a better practice to separate localized strings and images.
- For more information and best practices for localization, refer to the Android developer docs and training guides.