Implementing Full Application Internationalization

Some types of applications require complete internationalization. Providing custom resources for each supported language and locale is a time-intensive endeavor, and you should not do it unless you have a really good reason to do so because the size of the application grows as you include more resources. This approach often necessitates breaking the individual languages into separate APK files for publication, resulting in more complex configuration management. However, this allows a developer to tailor an application for each specific marketplace to a fine degree.

Some of the pros of this strategy are the following:

► The application is fully tailored and customized to individual audiences; this strategy allows for tweaks to individual locales.

► It builds user loyalty by providing users with the best, most customized experience. (This is also a technique used by Google.)

Some of the cons of this strategy are the following:

► It is the most lengthy and complicated strategy to develop.

► Each internationalized version of the application must be fully tested as if it were a completely different application (which it may well be, if you are forced to split it into different APK files due to application size).

Beware of over-internationalizing an application. The application package size will grow as you add language- and locale-specific resources. There is no reason to head down this road unless you have a compelling reason to do so—and unless you have the development, testing, and product team to manage it. Having a poorly localized version of an application can be worse to your image than having no localization at all.

OSfr

Using Localization Utilities

The Android SDK includes support for handling locale information. For example, the Locale class (java.util.Locale) encapsulates locale information.

0 0

Post a comment