Skip to main content

Getting started with Mobile internationalization API. Part 1

Posted by tbrandalik on February 9, 2007 at 5:29 AM EST

Mobile Internationalization API (JSR 238) or shortly called MIA comes as a part of wireless toolkit version 2.5. This entry is a quick start for those who wants to get familiar with this new API. You may object that user won't find devices supporting JSR238 on the current market. Yes, that's true, but the time when MSA replaces current JTWI standard is coming and it's always good to be ready ;-) ...

Briefly JSR238 is a solution for internationalization and localization of MIDP applications. Who likes reading a theory has a chance to read more about both terms here. I personally like one sentence explanation which says that:

  • internationalization is a process of designing applications that way that it can be localized to various languages and regions."
  • localization is a process of translating software user interfaces from one language to another and adapting it to suit a foreign culture."

    Looking back at CLDC/MIDP it has already introduced essential support for internationalization. I'm sure you remember that:

  • Characters encoding is Unicode.
  • Locale identification (see RFC 3066) and microedition.locale property were defined.
  • Date, Calendar, TimeZone classes are available.
  • InputStreamReader and OutputStreamWriter allow reading/writing character streams.

    JSR238 goes further and addresses following problems:

  • Separating of resources from the application source code. All localizable resources are stored out of the source code. It helps to easier translate an application without need to recompile and lowers possibility to introduce error.
  • Formatting of dates, times, numbers, currencies and messages. These items are correctly formatted according to locale set by application.
  • String collation. Collation is correct for the locale set by application.

    Locale identification
    Locale is the only way how to tell jsr238 implementation classes to behave according to desired locale. Locale identifier follows pretty same rules like in javaSE and is built as 2 letters of language code followed by 2 letters of country code and optionally a language variant. As a separator both underscore "_" and dash "-" are allowed.

    en-US, cs-CZ, zh-CN, ja-JP ...

    Interesting thing is that also empty string "" as a locale identifier is valid and signals that neutral formatting is required. I will talk about neutral formatting in next part of the guide ...

    Resource files
    To allow easy localization of application all localizable resources has to be stored into separate resource file. JSR 238 defines 2 categories of resources. device resources and application resources. The application resources are the resources bundled with the application, device resources are "burned into" the device. Application developer is responsible for creating and maintaining application resources, on the other hand device resources are read only.
    Resource files are hold in a structure of folders defined by the specification. If you have WTK 2.5 installed (and I hope you have ;-)), go into apps folder and look into i18nDemo a project which contains JSR238 sample MIDlet. Open MIDlet binary i18nDemo.jar and along with package folders containing classes there is also folder global with resources. Global is a root folder for all resource files. You will notice subfolders which naming follows locale identification schema. These folders then contain localized resource files. Look at following picture:
    basenames.png

    Resource file "common" appears there in 3 localized versions. Each is identified by the full path to the resource file.

    /global/common
/global/en/common
/global/en-US/common

    Resource inheritance principle was implemented here to save space. It means resource don't repeat in resource files. If a resource, we are looking for, isn't found in /global/en-US/common next resource file /global/en/common is queried and then as a last try common resource file /global/common is queried. You've probably noticed resource file stored directly under /global folder. It's good strategy to store resources which aren't intended to be translated into resource files right under /global folder. These are called common resources.
    Inspecting a structure of resource files and resource files itself just in file browser isn't very comfortable. We prepared small utility i18n Resource Manager which really simplifies the work with resources. Run WTK Toolbar and load i18nDemo project. I18n Resources Manger is right in project menu here:

    i18nmanager.png
    Another possibility to launch i18n Resource Manager is a script WTK_HOME/bin/i18ntool. Launch it with parameter <path to any resource global folder>

    i18ntool ../apps/i18nDemo/res

    In the next part we will look closer at resource files structure ...

    Related Topics >>
    Blog Links >>