Tips for Localizing Android Applications

I am not multilingual (since programming languages don’t count). Initially, localizing Android apps was difficult for me because I lacked experience with other languages, but I’ve learned a few simple tricks that help avoid common pitfalls:

1. ALWAYS use string resources for ANY text you show to the user.
2. Explicitly specify a locale when using date/time formatters.
3. Pay attention to the Right-to-Left layout linter warnings in Android Studio

I’ve found that following these rules adds almost no time to the development process, especially when your IDE is properly configured to help you remember to follow them.

String Resources

Every Android tutorial that I’ve seen touches on string resources at some point, so most Android developers are aware of them and use them on a regular basis. By default, Android Studio will warn you about using hard-coded strings in your layout files.

Thats great, but what about when you set the text of a UI element from your code? I recommend turning on the “Hard Coded Strings” inspection since it is not enabled by default. Open the Android Studio settings (Cmd + ,) and go to “Editor > Inspections > Internationalization Issues” to enable it. With this inspection enabled, you will be warned when you use a string literal in your code.

There are a lot of valid reasons to use hard-coded strings outside the UI, so you may also want to enable the “Ignore literals assigned to constants” option and the “Ignore lines containing this comment” option. Then, if you use a hard-coded string in a place that is not shown on the UI, you can silence the warning by adding a comment “// NON-NLS”.

Android Studio also has a nice feature that hides the verbose code for using string resources and shows the string that the resource points to instead. Go to “Editor > General > Code Folding” in settings and make sure that “Android string resources” is checked. Once enabled, Android Studio will automatically fold your string resources.

Date/Time Formatting

I learned this one the hard way. In converting an app that was English only to support Spanish, I discovered that I was saving dates to a database without specifying the format of the date string. When using SimpleDateFormat, if a locale is not given, the current locale of the system will be used. If I switched the language on my phone to Spanish, the data in the database was not readable because the app was now expecting the dates to be in Spanish.

The Android documentation of the Locale class has a short warning that describes when it is appropriate to use the default locale. Basically:

• Use the default locale when the date/time info is going to be shown to the user.
• Don’t use the default locale when the date/time info is supposed to be interpreted by your code.

Android Studio can check for this too. Go to “Editor > Inspections > Internationalization issues” in settings and enable “Instantiating a SimpleDateFormat without a Locale”.

If you do intend to use the default locale, say so explicitly in your code by using Locale.getDefault() as the locale.

Another mistake that I’ve been guilty of is assuming that the arrangement of the date elements in a date format will be the same for all languages. In English, we might format today’s date as “February 9, 2016”, but in Spanish it should be “9 de febrero de 2016”. The SimpleDateFormat class can’t account for these differences, so the DateFormat class should be used instead.

The DateFormat class provides several presets for common date formats that adjust properly for the given locale. For example, the dates above can be correctly formatted using the DateFormat.LONG preset:

DateFormat df = DateFormat.getDateInstance(DateFormat.LONG, Locale.getDefault());
String date = df.format(new Date());
// "February 9, 2016" in English, "9 de febrero de 2016" in Spanish

Right-to-Left Layouts

Android 4.2 Jelly Bean (API 17) introduced native support for right-to-left languages (such as Arabic). Basically, this means you should use “end” instead of “right” and “start” instead of “left” when defining attributes like padding or margin. For example, paddingRight becomes paddingEnd. If you need to support Android versions below API 17, you would just use both left/right and start/end together since the older versions of Android ignore start/end.

Android Studio will warn you if you make a layout that might not look correct when the device is in RTL mode.

Make sure you enable “Using left/right instead of start/end attributes” in “Editor > Inspections > Android Lint” (default is enabled). Most times, the start/end attributes will have the same values as left/right, so it’s very easy to add them as you create the layouts. Adding support for RTL after the fact will take much more time, so I always fix RTL warnings even if there are no current plans for RTL language support.

To test how your layout looks with a RTL language, you can force RTL mode without changing the device language by enabling “Force RTL layout direction” in “Developer Options > Drawing” in the device settings.