Understand Android's hierarchy for selecting resources
Android loads text for your project from the res/values directories. The default file is called strings.xml, but this is the fallback file. By implementing folders smartly for each language you plan to support, the operating system will select the most appropriate translation at run-time.
For example, let's say you've included the following in your project:
A user who has her phone configured for English (United Kingdom) will get the prompts from resource #1. Since we've provided no English (United States) resource, a user with her phone configured for English (United States), gets the prompts from resource #2. A user with her phone configured for Deutsch, will get the prompts stored in resource #3.
This is a very flexible model, and it doesn't require that you support every language all at once to sell your app around the world. It does require that you take the time to understand how it works. If you aren't familiar with this construct you can (and should) get the full details on how Android manages resources at http://developer.android.com/guide/topics/resources/providing-resources.html.
Resources aren't limited to text strings
While probably not critical to successfully supporting your app in multiple countries, a handy and sometimes overlooked feature of the Android platform is the capability to add location specific graphic resources. Just like you can include multiple versions of your project's /res/values folder, you can use the same technique for /drawable folders.
For example, you might choose to display a flag.png image on one of your application screens. If you wanted to swap out the image at run time with a British vs. an American flag depending on the user's location setting, you would include a /res/drawable-en-rUK/flag.png resource, as well as a /res/drawable-en-rUS/flag.png resource. Again, in the case where the location specific resource is not found, /drawable/flag.png will act as the default.
Beware of Java's formatting classes
Not all issues with localizing your app are specific to Android; Java has its fair share of currency, date, and number formatting-related classes that will eat your lunch if you don't watch it. Take for example the following code snippet:
//get today's date
Date today = new Date();
//using a non-localization aware technique
SimpleDateFormat formatter = new SimpleDateFormat("M/d/yy");
String notSoGoodDate = formatter.format(today);
//using a localization aware technique
DateFormat anotherFormatter = DateFormat.getDateInstance(DateFormat.SHORT, Locale.getDefault());
String goodDate = anotherFormatter.format(today);While both appear to be reasonable implementations (at least here in the USA), one in fact can lead to unintended results. To see what I mean, take a look at the images below. Figure B shows the code running on a device configured for an English keyboard, and Figure C shows the same code running on a device configured with a Deutsch keyboard. With the SimpleDateFormat technique illustrated, your user may assume you mean August the 9th when you intended September the 8th. Worse, if you are parsing this string manually, your app could crash entirely expecting to tokenize on the '/' character, which is not used at all as a date separator in some places around the world. Figure B
Android configured for EnglishFigure C
Android configured for Deutsch
Test, test, test!I admit the Android emulator isn't perfect, but there is a whole lot of testing that can be done using this tool, and validating localization is one of those areas where the emulator can be a lifesaver. To see how your app fares, choose Settings from the Home screen (Figure D). Then go to Language & Keyboard (Figure E), followed by Select Language (Figure F). Figure D
Localizing an app for the Android marketplace requires a little extra work. In my experience though, the payoff well exceeds the effort. Even if you only support a single language, making sure your app operates as intended regardless of what language and keyboard the user has selected on their device will help to keep customers happy, and has the potential to drastically increase your download count.
Share your tips and experiences
Android developers, if you have localization do's or don'ts that I didn't include in my checklist, please offer them up in the comments. Windows Phone 7and iOS developers, let us Android gurus know what sorts of localization issues you deal with on your platform.
William J Francis began programming computers at age eleven. Specializing in embedded and mobile platforms, he has more than 20 years of professional software engineering under his belt, including a four year stint in the US Army's Military Intelligence Corps. Throughout his career William has published numerous technical articles, as well as the occasional short story.