Soluling home   Document home

MIDlet Localization

Deprecated. Use as it is, but we do not give support or develop the format anymore.

The original Java Micro Edition, Java ME, (Wikipedia) CLDC configuration and MIDP profile did not contain any string resource classes. There was an API to read files stored in the JAR file but there was no real internationalization method. Programmers had to either ignore localization or implement their own resource class. Implementing such a resource class is difficult. This is why most programmers choose not to localize their applications at all.

Sun recognized this problem and they started an internationalization Java Specification Request (JSR 238). It finally provided a proper resource class to be used for strings and images. Unfortunately this API is not a part for CLDC or MIDP. It is an optional API. Some phone vendors include it (e.g. Motorola) but some other do not include it (e.g. Nokia). If the phone does not contain the class this API can not be used. So we are back is the original situation where there is no real resource class.

Fortunately Soluling can overcome this problem. It can use source code localization. This means that Soluling reads the original source code files (.java), extracts hard coded strings from file, and finally creates localized source code files. These source code files are identical to the original source code files except some or all strings have been replaced with translated strings.

This gives you three choices to localize midlets.

Use Mobile Internationalization API (JSR 238)

If your target phones support Mobile Internationalization API (JSR 238) and you can modify your source code you better use this API. This process will place the strings into resource files (.res) inside your application JAR file. Then you just add your JAR files into Soluling project and it creates you either localized JAR and JAD files (one for each language) or one single multilingual JAR and JAD file. Soluling can localize all resource types in addition of mobile resource files. This makes it possible to localized image, audio, text and XML data that is stored inside JAR files.

Let Soluling to localize source code files

If your target phones do not contains JSR 238 or you don't want to use it you don't have to do anything. Just add your JAR file into Soluling project. The application reads the class files inside the JAR, finds the corresponding source code files (.java), and reads them. When creating localized items, Soluling first creates localized source code files, them compiles them into class files and replaces the original class files inside the JAR file with the translated class files. As a result you will have one localized JAR and JAD file for each language. Just like in the above case you can also localized image, audio, text and XML data.

If you use a complex post compilation manipulation such as obfuscation it may be that Soluling can not compile localized source code files in the same way that you compiled the original source code files. In that case make Soluling to create just the localized source code files in language specific sub directories. It is then up to you to compile files and create JAR package(s).

Use LWUIT

LWUIT is a new technology to write mobile applications. It uses a Swing like UI widget components. Learn more about LWUIT localization.

Comparing above methos

Both above methods work on every cases. Both methods have advatages and minor disadvantages. Following table presents them.

No matter which one method you use you can also localize image, audio, video, text and XML data in JAR file