Android Localization: Getting Started

Creating a New Strings File

Create a new strings.xml file in this directory by right clicking on the directory. Then choose New ▸ Values resource file.

In the window that pops up, enter the name strings.xml and press OK. It’s important to give this file the same name as your default strings file, in the values directory, so the system can swap them out as needed.

You’ll see the new strings.xml has a little Union Jack to help you identify it in the Project panel and open file tabs.

In this new file, you can add any translations you want to show when the device is set to British English. Remember, you don’t need to provide translations for every string in the app here. As long as the string is defined in the default strings.xml, any strings which haven’t been defined in the British file will fall back to their default value.

Add the following translations to the new strings.xml between the resources tags. The string names exactly match the ones already defined in the default file. Only the value has been translated.

<string name="top_sweater">Jumper</string>
<string name="bottom_pants">Trousers</string>
<string name="shoes_sneakers">Trainers</string>

And that’s it— you’ve added translations to your app! But how do you know if it worked? You can test in Android Studio before you run it on a device.

Previewing in Android Studio

Open activity_main.xml in Android Studio. At the bottom of the file, make sure you’ve selected the Text tab so you can see the xml code.

You’ll see a Preview panel on the right of the screen. You may need to expand it from the side panel if isn’t already.

In the Preview pane’s toolbar there’s a Locale for Preview dropdown which shows Default (en-us). This is your default strings file.

Now that the project has multiple locale directories, you can change this option in the preview to see how it looks. Select English (en) in United Kingdom (GB) from the dropdown menu.

One snag— nothing’s changed!

The three translations were all for values used in the Spinners. These get added to the code programmatically rather than in the xml file. The xml layout file doesn’t know about these values and can’t populate them in the preview.

For the sake of this tutorial, add another string translation to your en-rGB/strings.xml for the title at the top of the screen. This value gets assigned to the TextView in the xml code so Android Studio knows how to populate it for the preview.

This translation is a temporary addition for testing purposes. You’re not going to ship with it. So, for now, add a string you’ll recognize to show it worked in preview:

<string name="title_select_characteristics">This is British English</string>

Go back to activity_main.xml preview. With English(en/GB) still selected, you should now see the temporary title in preview. Congratulations, it worked!

This preview is useful because it shows you how your layouts look with different values. Some languages may have longer or shorter translations than your defaults. This is a good way to catch any problems with your layouts early on.

Before you forget, go back and remove the temporary string you added.

Testing on an Emulator

Next you should test on an emulator. Build and run the app. Initially, nothing should look any different than when you first ran this project.

The emulator is like a real device. You can change the primary language in the same way you would on your Android phone.

On the emulator, open the Settings app and navigate to System ▸ Languages & input ▸ Languages. If it’s not already there, add English (United Kingdom) as a language to your Language Preferences. Move it to the top of the list.

Reopen the sample app in the emulator. You’ll now see the spinner options have changed to display the translated values.

The app is now pulling in the translated strings from the GB resource directory to comply with the primary device language set by the user. Your app now supports multiple locales!

Tips for Getting Good Translations

Knowing how to support multiple languages in your app is all well and good. But to provide that support to your users, you need to actually get translations for the text in your app.

Unless you’re a master linguist, it’s unlikely you can translate all your strings into all the languages you want to provide support for. So, you’ll need to find someone who can translate it for you.

Maybe you have international friends you trust to provide local translations for you. Failing that, there are many companies that provide translation services.

However you obtain your translations, in most cases, you’re going to send them across strings.xml. So, the more context you can provide about where those strings are used, the better.

Some of the words will be straightforward to translate. Others may have different translations with different meanings depending on the context in which they’re used.

In strings.xml, you should provide comments with the context for each string. Look in the sample app and you’ll see there are comments providing context about what the strings are for and where they’re used in the app.

Other things to consider:

You should use formatted strings rather than hardcoded values or method calls to convert numbers or dates to strings in your app logic. This lets the system format the numbers with the correct set of digits according to the region. Read more about this here.

• Untranslatable strings: If you don’t want a string to be translated, you can add translatable=”false” to the string declaration after you define the name.
• Formatters: If you’re not sure what formatters are, check the formatting and styling documentation. With the broad range of regional support Android provides, there can be differences in formats for things like dates and times within the same locale.

  You should use formatted strings rather than hardcoded values or method calls to convert numbers or dates to strings in your app logic. This lets the system format the numbers with the correct set of digits according to the region. Read more about this here.

• Positional string arguments: For some locales, the order of the parameters provided may differ. So, you should annotate the ordering in your strings file. There’s an example of this kind of annotation in the sample app share_text string: I just generated a cool character with %1$s hair, wearing a %2$s, %3$s and %4$s!