Home > Uncategorized > 10 Internationalization Tips for Android Application

10 Internationalization Tips for Android Application

You’ve got your Android app out there, and it’s selling like hotcakes. You’ve got the momentum, but you need more users. Now may be the time to consider internationalizing your Android application and publishing it to a much broader user base. Not every Android application is suitable for internationalization though. You will need to consider design and development issues, publication complications, and product suitability issues.

In this article, we list the 10 things Android app developers should think about when pondering “going global.” These considerations apply whether you’re using the latest and greatest Android Honeycomb (3.x) SDK or an older SDK.
1. String Manipulation

When people think about internationalization, they usually think about String tables. And sure, that’s where a lot of the work for internationalization of your app occurs: specifying alternative string resources for your application to load for different users. Luckily, Android makes this very easy and flexible. You can internationalize any resources you add to your project, be they strings, graphics, colors, layouts, dimensions, etc. Keep in mind that if you load and use custom fonts, you should have a fallback plan for foreign characters your font family doesn’t support.

When it comes to string manipulation, you’ve got ample APIs for handling Unicode and other world-friendly character encodings.

2. Flexible User Interfaces

Have you ever noticed how long German words are? How intricate a Japanese character can be? Or that some foreign languages are read top down, or back to front? Your application user interface needs to be flexible enough to handle these idiosyncrasies, within reason.

When possible, make your navigation controls, and such, visual instead of textual. Buttons like play, pause, stop, next, and previous are universally understood and can save you time and effort when internationalizing your user interfaces. Consider also what input methods and software keyboards are most appropriate for your application.

3. Currency Formats

If your application is financial in nature, or deals in currency formats, then you’ll want to be aware of a few things. First, you can use alternate format string resources to display currencies in the appropriate format. For example, some regions use commas and periods in different ways, others put the currency symbol before or after the value. Beyond formatting currencies correctly, things can get very tricky if you’re doing any sort of conversions.

In terms of selling your apps, the Android Market supports numerous currencies in which you can sell your application. That said, some countries do not currently allow for paid applications through the market, but this has been changing as the platform grows and the Android Market works out the legal details.

4. Dates

Think about how many ways we talk about dates. We use all numbers, we spell out the months, we shorten the month to a three letter version. Well, when you start looking at the calendaring of the world, things can get pretty complex. Not all users live by the Gregorian calendar system. Luckily, you’ve got a number of calendaring and date formatting APIs available within the Android SDK to help you sort this out.

5. Time

Just like dates, time formats vary throughout the world, as does the actual time, whether or not there is a daylight savings time, etc. You’ll find Android APIs that help smooth over time zone issues and the like, as well as date/time formatters for pretty-printing a date and/or time in the format you desire. It can get a bit tricky when you’re trying to sync up times in multiple places, like an application server in California and a user in Calcutta.

6. Names and Addresses

Names and addresses also come in different forms, such as family names, forenames, surnames, given names, middle names, and initials. Sometimes you’re best off just giving users a single field for all their various and sundry names, and not trying to categorize their parts.

Addresses are much worse. Some countries have post codes, others have provinces, states, counties, townships, and territories. Again, sometimes your best bet is to give users one big multi-line field for the “middle part” of their address that can be formatted any which way, instead of trying to compartmentalize and order the specific items.

7. Server-Driven Apps

Some Android applications are very lightweight, leaving all the heavy lifting to an application server or the cloud. These applications often have very few package assets — they simply get all their content from the server, be it text, images, media files, or what have you. These sorts of applications fall into a special category of internationalization because, really, it’s the content you want to internationalize, not the application skeleton.

Here you’ve got a few options. You can try to detect the current language or regional settings on the device programmatically and request the appropriate locale-aware assets from your server. You may want to establish your own set of supported languages that are configurable by the user in the form of application preferences, separate from the Android device settings, so that you can clearly state which locales your app supports. The benefit here is that you can always add new language support on the server side, even after the app has been published. This choice may depend on if your application is accessible from the web or other devices that don’t give users a choice for their language and locale.

8. Export and Law

Most application developers won’t have to worry too much about export law these days. But there are some exceptions. There are still rules about exporting certain encryption techniques and such. The Android Market has a reasonable write-up on this, but really, the short answer is: knowing the law is your responsibility, not Google’s. The terms of service on all these distribution mechanisms limit their liability, not yours.

More common are the problems with compliance with local law. Not all countries are governed by the same rules. Once you sell your application in a foreign land, it’s a good idea to make sure you’re not unwittingly breaking its laws (in case you might someday want to visit). Some countries have very strict rules when it comes to privacy, use of user data, where that data is stored, how it is transmitted, etc. Be especially aware if your application is of a financial nature. Other nations have laws outlawing gambling and pornography, and their legal definitions vary. But we are developers, and not lawyers, our best advice here is seek professional help.

9. Taxes

You can read up on the tax implications of selling on the Android Market, but other tax implications may exist as well, especially if you self publish. Again, as we are developers and not accountants, our best advice here is seek professional help.

10. Device Availability

While Android devices are available on every continent, the devices found in Kenya will not necessarily be the same sorts you find at your neighborhood Verizon store. Device availability in certain regions varies, in fact it trends. The “hottest” new devices tend to start out in places like Asia and the United States and migrate to other areas. Third-world countries are huge growth markets in mobile, but most individuals are not using top-of-the-line smartphones, but some of the older phones, running older versions of the Android platform. This means that remaining backwards compatible to Android 1.6 is more important if you want to support users worldwide.

Android Internationalization Bonus Tip: Cultural Differences –Real or Imagined

Consider this a soft topic for software. Despite everything you do to make your application world friendly, some applications are just not appropriate for certain regions. This is a judgment call more than anything, and dependent on the amount of risk and potential flack you’re willing to take — as a company or in terms of your market ratings.

Sometimes, this is just a matter of being sensitive to your potential users. Games especially can be highly stereotypical. It may be part of the storyline, but consider internationalizing those aspects of your application as well. How many first person shooter bad guys have German accents? In fact, there are laws in many countries about that particular topic, especially the visuals concerning it.

Other times it’s simply a matter of an app’s utility relying fundamentally on its region or regions. After all, why would an Android user in Southern Sudan need an app to find the nearest New York bagelry or London chip shop? Simply use common sense: not all apps are meant to be internationalized. That said, an application that targets a region that is multi-lingual would do well to support its secondary languages, be they American Spanish, French Canadian, or what have you.

Conclusion

Internationalizing your application may seem daunting at first, but as you can see from this simple checklist, most applications currently on the Android Market can be easily updated to support multiple languages, locales and a more diverse set of users. Still, many app developers do not devote the small amount of time and effort necessary to take this step — giving those who do a decided market advantage.

Sources

Advertisements
Categories: Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: