views:

417

answers:

4

Does anyone have some knowledge with internationalization with JavaME? I'm looking for as much information as possible like examples, experiences and maybe some best practices. Thanks

+2  A: 

A few thoughts. J2ME doesnt support i18n as it the api support is not there (cant use resource bundles). But we can do this to a limited extent. Here is what I found out.

  1. It is difficult if not impossible to support english and say chinese languages (typographic characters) for a given J2ME app. But easier to support english and say spanish (I forgot the correct nomenclature to talk about i18n support but you get the idea).
  2. We can have all strings in one config class, that way you can swap this one out for different languages.
  3. We can have the text/strings downloaded from server on initial launch of app and thus have the ability to swap it out from server.
  4. Because of different screen sizes, it is best to work with custom fonts so that code can be written to calculate the text length while displaying it. This will make multiple language support easier.
  5. Image assets can also be downloaded from server based on different languages. But I dont think we can change the midlet icon, so it should be generic.

With this in mind it is possible to design multiple language support.

omermuhammed
Thanks, I will keep in mind your suggestions.Only one thing, about point 3, this would be a problem since it requires the Midlet to be signed or the device will complain and ask for authorization.
Stefano Driussi
I had assumed signed apps. It is an unfortunate aspect of J2ME work on most carriers (atleast in US). They require apps to be signed for network connectivity
omermuhammed
+1  A: 

omemuhammed's answer is an excellent coverages of localization in the mobile space.

I've only had to support EFIGS (English, French, Italian, German, and Spanish). We stored all strings in XML, had an XML pack for each language. We would then compile these XML packs into proprietary binary data and had the ability to build either all 5 languages into a build, have only one language for the build in cases where the application size was tight, or download the binary from a server.

Other considerations with localization is screen layout. I also recommend custom fonts in order to have better control of the display across many different devices. You will need some auto-wrapping code to be able to adjust to different screen resolutions and aspect ratios and you will need a way to handle strings that run off the screen on some devices. Either paging or or scrolling would be a good solution.

Finally, just know that German will screw up your formatting. Try to allow 20-30% padding in English for menus and other UI elements as the German translations will be much longer than the other languages.

Fostah
Thanks a lot, i didn't know the "issue" with german translation
Stefano Driussi
A: 

See the actual internationalization spec for JavaME: http://www.jcp.org/en/jsr/detail?id=238

Recent Symbian phones should support this.

One obvious advice is to actually try your application on a localized phone: Get a phone from switzerland (it should support at least 4 languages) and another from hong kong (with 3 different version of "chinese"). It might be worth looking into eastern europe/ex-ussr too.

When the actual characters aren't your usual ascii ones, you do need to use a TextBox or TextField in order to have the localized native control on the screen.

QuickRecipesOnSymbianOS
A: 

Keep in mind that when you use RTL (righ to left) languages, like arabic, you should invert positions of almost everything on the screen, like a list would look like this on latin languages

  • List item 1
  • List item 2
  • List item 3

but the bullets would be on the other side of the screen on arabic (tried make it here, but I could´n generate na inverted list :P )

One other thing is that is better to store your strings in a class than a plain text properties, as this may cause some errors interpreting the unicode of some languages depending on the OS and text editor you are using.

What I usually do is have a I18nManager Class that stores the language in the startApp and through this class I get all the strings I need.

Decio Lira