Programming Tutorials

Internationalization Support in J2ME MIDP

By: Henry  

Realistically, an i18n solution on any platform is somewhat constrained by the resources and API mechanisms available to applications. The ease with which a programmer can implement i18n support—and the comprehensiveness of that support—depends largely on the level of explicit support for the major areas of i18n development. The MIDP platform provides the following elements in support of i18n development:

• Calendar, Date, and TimeZone classes: java.util package
• system properties: microedition.encoding, microedition.locale
• conversion between character encoding sets: java.io package
• user-defined MIDlet suite attributes: application descriptor file (JAD file)
• retrieval of resources (files) from the MIDlet suite JAR file:
Class.getResourceAsStream(String resourceName)

The MIDP java.util package contains three classes that are related to i18n, namely Calendar, Date, and TimeZone. These classes, however, are not themselves internationalized. That is, their concrete implementations don't support operations in multiple locales. For example, Calendar doesn't perform calculations according to a particular locale's calendar. The Date class doesn't do locale-sensitive date and time formatting. Neither do they present localized resources themselves. These classes do, however, present basic definitions that can be subclassed.

The Calendar and TimeZone classes are abstract. MIDP implementations must provide at least one concrete subclass for each of them. Although not internationalized, their implementations will be compatible with the locale supported by the MIDP implementation. For instance, in the United States, an implementation would most likely support a Gregorian calendar. The majority of MIDP implementations support only one locale. In fact, the MIDP specification only requires an implementation to support a single locale and only requires implementations to support the Greenwich Mean Time (GMT) time zone.

Note: The MIDP specification only requires that implementations support one locale. MIDP implementations currently don't define adequate support for internationalization and localization, which require too many resources.

Realistically, application developers who hope to deliver applications to multiple platforms must build support for locales other than the one supported by the manufacturer's implementation. To support true i18n and l10n, developers must build application level APIs that support multiple time zones, calendars, and so forth. Manufacturers may provide some of this support in the form of native APIs and Java libraries that sit on top of their MIDP implementation. Developers must be aware of the level of i18n and l10n support provided, if any, and they must plan their application design accordingly.

Support for a single time zone and a single calendar implementation might suffice in the majority of cases. Manufacturers may, however, provide additional calendar and time zone resources for an implementation. The motivation for this kind of additional support would be to support multilingual computing.

Device manufacturers typically support the locale associated with the device's target market. An implementation that supports only one locale need not be internationalized. Although this approach may work in the majority of markets for now, things could change. Single locale support does not support multilingual computing. Applications may need to do messaging in one locale, monetary formatting in another, and so forth.

Readers who are familiar with i18n support on the J2SE platform will notice that the MIDP has a comparatively distinct lack of comprehensive i18n support (see the J2SE java.text package). The reason, once again, is the constrained environment of mobile devices. The MIDP has no java.text package. In fact, MIDP has no API support for i18n features such as resource bundles, message formatting, number formatting, locale-sensitive date and time formatting, and so forth. The MIDP is also missing the new i18n features in version 1.4 of the JDK java.text package, such as collation, bidirectional text support, annotations, attributes, and so forth.

I18N Frameworks

Basically, the crux of all i18n designs is the mechanism that enables applications to retrieve the right version of localized resources at runtime. Unlike J2SE, the MIDP has no real API or classes that support general retrieval of localized resources. There's no ResourceBundle class or any of its subclasses. MIDP applications must create their own mechanisms for l10n resource definition and retrieval. Realistically, the most viable approaches are:

• Retrieve l10n resources from the JAD file.
• Retrieve l10n resources from a text file that's part of the application JAR file.
• Retrieve l10n resources from a Java class file, such as an application-defined, J2SE-style resource bundle mechanism.

Messaging
 
Unfortunately, the MIDP also lacks explicit support for messaging. Unlike J2SE, the MIDP offers no messaging API, and there's no MessageFormat class. In designing a messaging solution for MIDP applications, designers should consider the following issues:

• location of the localized data
• mechanism for accessing the localized data
• format of the localized data and character encoding set used
• footprint of localized resources
• runtime performance
• localization process issues such as management of development resources, maintenance,
  and so forth
• real wireless network environments, application provisioning environments, and
  deployment issues

String Collation

The MIDP has no support for string collation. If your applications need to perform lexicographic sorting of any kind, you'll have to design and implement your own mechanism to do it. Although this support exists in J2SE, the classes consume too many resources for a MIDP device environment at the present time.

Date, Time, and Numeric Formatting

The MIDP provides no support for formatting date, time, numeric, or monetary values. The MIDP has none of the J2SE platform classes that support this formatting; there are no DateFormat, NumberFormat, and DecimalFormat classes. Manufacturers may provide implementationspecific classes to support these formatting capabilities, however.

The MIDP defines Date and TimeZone classes in its java.util package, but these classes aren't really internationalized. That is, their interfaces don't define any capabilities that address locale-sensitive processing.

The Date class simply represents a specific instance of time in Coordinated Universal Time (UTC). There's no MIDP support for conversion of a Date quantity to represent a time value in any other time zone, or to format time values for display to users. This behavior is consistent with the J2SE platform's definition of Date objects. The J2SE platform, however, has related classes (such as DateFormat) that can format date quantities in a locale-sensitive manner. The MIDP has no such support classes.

The MIDP supports time zones with its java.util.TimeZone class. This class is abstract. Your MIDP implementation will provide at least one concrete subclass that represents the GMT time zone. The MIDP specification only requires support for the GMT time zone; however, your implementation might support others as well.

The TimeZone.getDefault() method returns a TimeZone object that represents the default time zone for the host on which your application is running. Be aware that it might define the GMT time zone, even if that's not the time zone in which your host application operates. The TimeZone.getTimeZone(String id) method returns a TimeZone object for the threeletter time zone argument specified in the call. Be forewarned that the object returned might not represent the time zone you requested because the implementation might not support it. Clearly, it's important that you, the application developer, be aware of which time zones your platform support. 
 
Calendar and Time Zone Support

Again, unlike the J2SE platform, the MIDP has only limited calendar support. The java.util.Calendar class is abstract. Therefore, every MIDP platform will provide at least one concrete implementation. Most likely, it won't be internationalized.

The platform's concrete Calendar subclass will most likely implement one particular calendar, such as a Gregorian or lunar calendar. This might or might not be an appropriate calendar for the locale contexts in which you deploy your applications. The Calendar.getInstance(TimeZone zone) method returns a Calendar object that uses the specified time zone and the platform's default locale. Note that this factory method doesn't make Calendar a fully internationalized class. It still doesn't return an appropriate calendar based on the locale context. For example, if you specify Chinese Standard Time, you won't get an object that represents a lunar calendar as used in China with all MIDP implementations. This means that you need to be aware of what calendar is supported

Archived Comments