Skip to main content

Globalize y[our] mobile applications!

Posted by brunogh on June 4, 2007 at 1:33 PM PDT

I have heard the phrase "Mobile is global" in a JavaOne 2007 session video and I have started thinking about it. You can find deep meanings for the word global, but, for me, a good one is crossing cultures! So, have you ever heard about software internationalization (i18n)? Do you know what software localization (l10n) is? Before I try to explain these concepts, just imagine how many countries, languages, writing systems, hourly spindles, calendar systems and money types we have in our world. I can guarantee, it is a lot!

In simple words, i18n is closely related to the structure that a software can has - for example, isolating resources such as messages (externalizing strings), and access them at runtime - to allow it to be localized. Localize a software is make it adapted to the desired locale (country/region and language). But, do not think that l10n is made just by translating words, documents or changing images. It can be much more complex, because, remember, you will be dealing with another culture, language and conviction! As I have seen before, sometimes, because of that, user interfaces needs to be rebuild as well. Think about it, for example:

if(!you are Arabian){
Think about the Arabic writing system, as far as I know, they write from the right to the left.
} else {
Think about the American writing system, they write from the left to the right.
}
Is not so different to you? Got the global view?!

So, let is get our focus to mobile development and talk a little bit about JSR 238, which is also called Mobile Internationalization API (MIA). Before this specification, internationalization in MIDP/CLDC used to be much more difficult. MIDP did not have things to treat it well and people used to create its own classes to handle this stuff. According to JSR 238, this API provides culturally correct data formatting (by javax.microedition.global.Formatter class), sorting of text strings (by javax.microedition.global.StringComparator class) and application resource processing (by javax.microedition.global.ResourceManager class). That is a great start in order to globalize our MIDlets!

The basic idea of MIA to help the resource processing is having one or more resource files - also called bundles, it is like a property files in Java SE - in a binary format for each locale that you want inside the jar file structure, like /global/{locale}/{Resourcefile}.res (note that locale follows the format en-US, cs-CZ, etc). If you want a common resource to be accessed, just put it in the global folder directly, like /global/Common.res. After that, the locale can be loaded and you will get the structure to access the strings and images at runtime by code. Download the JSR 238 RI, it contains a ResourceMaker to create the binary file. For the sorting, if you want to use it, you will have to implement a compare method that is avaiable to manage two strings. And finally, for the formatter, you can use the Formatter class that will adapt the dates, times, numbers, and currencies for the desired locale. You probably now want more code details, so take a look in our community demo box, there is three cool MIDlets examples of these things!

But, all these stuff does not make sense at all, because JSR 238 is an optional package. So, how could we make global applications if a lot of devices does not support MIA? I got the solution! Guess what?! Another point to MSA (take look in my last post to get familiar with it), it is mandatory on its main group! So, life will be much easier after we got a lot of umbrella-compliant mobiles, we are walking for that! Do not forget to try JSR 238! Thanks!

See you,

Bruno Ghisi

Related Topics >>