×

Discussion Board

Results 1 to 14 of 14
  1. #1
    Super Contributor
    Join Date
    Mar 2004
    Location
    Bangalore,India
    Posts
    2,146

    Locale support on J2ME

    Hi All,

    I am planning to create an application that would have both static data(i.e. labels/text and input fields), as well as dynamic data(information which comes from the server). As for the static data since they are always the same I can have resource bundles which will have language strings for say Japanese/Chinese etc. But how do I deal with the dynamic information so to display it in the language selected on the device?

    Other information I am looking to localize are :-

    1. Calendar/date formats
    2. Currency fields
    3. Text/char encoding schemas if any

    Also I would like to understand if the user changes language from say English to Chinese, if I am using say an editor, will the user be able to enter text in Chinese or how does that work?

    Another thing I need to understand is that the call system.getproperty("microedition.locale") would work on all devices or is that constrained by the manufacturer driven profiles on top of the MIDP?
    Last edited by mayankkedia; 2009-05-26 at 08:00.
    Cheers,
    Mayank

  2. #2
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Locale support on J2ME

    For formating of things like dates and currency, I recommend you write formating methods similar to those in J2SE, and then include format strings in the localized resource files.

    For example, for dates:
    Code:
    GB: "{1}/{2}/{3}"
    JP: "{3}/{2}/{1}"
    US: "{2}/{1}/{3}"
    For currency:
    Code:
    GB: "£#0.00"
    IE: "€#0.00"
    FR: "#0,00€"
    To avoid text encoding issues, all text resources and text from your server should be encoded at UTF-8.

    On a Chinese device, Chinese input should be supported automatically by text input components (such as TextBox). You will need to depend on the device for this.

    MIDP defines three legal values for microedition.locale:

    1. null
    2. language ("en", "fr", "ro", "ru", etc.) (ISO-639)
    3. language-region ("en-GB", "en-CA", "en-IE", "en-US", etc.) (ISO-3166-2)

    (So far as I know, there is no official way to differentiate between Simplified-Chinese and Traditional-Chinese, since the MIDP specification describes only language and region, not script. However, it may make sense to assume that "zh-CN" (China) and "zh-SG" (Singapore) will use Simplified, and "zh-HK" (Hong Kong), "zh-MO" (Macao) and "zh-TW" (Taiwan) will use Traditional.)

    Since null is legal, you might not be able to determine the locale of the host device.

    If you are using the high-level UI components, some UI elements may be localized by the device, outside your control. For example, the "Options" or "Menu" softkey label used when multiple Command objects are assigned to the same softkey.

    Graham.

  3. #3
    Super Contributor
    Join Date
    Mar 2004
    Location
    Bangalore,India
    Posts
    2,146

    Re: Locale support on J2ME

    Thanks for the informative reply buddy, appreciate it.

    Quote Originally Posted by grahamhughes View Post
    For formating of things like dates and currency, I recommend you write formating methods similar to those in J2SE, and then include format strings in the localized resource files.

    For example, for dates:
    Code:
    GB: "{1}/{2}/{3}"
    JP: "{3}/{2}/{1}"
    US: "{2}/{1}/{3}"
    So if I understand correctly it ends up being like a string with something like "{%d}/{%d}/{%d}" where the different things can correspond to mm/dd/yy at runtime depending upon the locale selected?

    For currency:
    Code:
    GB: "£#0.00"
    IE: "€#0.00"
    FR: "#0,00€"
    Ditto for currency?

    To avoid text encoding issues, all text resources and text from your server should be encoded at UTF-8.
    So now if all the data from the server is unicode/UTF8 how exactly does it gets rendered in say Chinese on the device, do I have to do anything specifically or the underlying framework handles that for me?

    On a Chinese device, Chinese input should be supported automatically by text input components (such as TextBox). You will need to depend on the device for this.
    You mean could vary from manufacturer to manufacturer, where say Nokia might give me this feature while Samsung might decide not to? If thats the case is there some work around to standardize it?

    MIDP defines three legal values for microedition.locale:

    1. null
    2. language ("en", "fr", "ro", "ru", etc.) (ISO-639)
    3. language-region ("en-GB", "en-CA", "en-IE", "en-US", etc.) (ISO-3166-2)

    (So far as I know, there is no official way to differentiate between Simplified-Chinese and Traditional-Chinese, since the MIDP specification describes only language and region, not script. However, it may make sense to assume that "zh-CN" (China) and "zh-SG" (Singapore) will use Simplified, and "zh-HK" (Hong Kong), "zh-MO" (Macao) and "zh-TW" (Taiwan) will use Traditional.)

    Since null is legal, you might not be able to determine the locale of the host device.
    If it is null, is there no way to find the locale, maybe I end up having a setting page in my aplication for a locale change then,doesnt that work?

    If you are using the high-level UI components, some UI elements may be localized by the device, outside your control. For example, the "Options" or "Menu" softkey label used when multiple Command objects are assigned to the same softkey.
    Graham.
    So if I understand correct it ends up meaning that "Options" would remain options even in Chinese and not get translated so to say?
    Cheers,
    Mayank

  4. #4
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Locale support on J2ME

    Quote Originally Posted by mayankkedia View Post
    So if I understand correctly it ends up being like a string with something like "{%d}/{%d}/{%d}" where the different things can correspond to mm/dd/yy at runtime depending upon the locale selected?
    Kind of, except don't use "{%d}". Take a look at the way classes like MessageFormat work in J2SE. It's very important to have format strings that do not depend on the order of the arguments in the code.

    For example:

    Code:
    String s = "Page " + page + " of " + pageCount;           // BAD!!
    
    String s = format("Page %d of %d", page, pageCount);      // BAD!!
    
    String s = format("Page {1} of {2}", page, pageCount);    // GOOD!!!!  :)
    Why is the last one good? Because in another language, the sentence structure might be something like "Of pageCount pages, this is page". You can't fit that into the first two, without changing the code. In the last case, the format string just becomes "Of {2} pages, this is {1}". Since, in reality, the format string would be in a locale-specific resource file (not in the code), no code change is required.

    Quote Originally Posted by mayankkedia View Post
    Ditto for currency?
    Yup. In my example format strings, "0" denotes a required digit, and "#" denotes one or more optional digits. Something like:

    Code:
    "£###,###,##0.00"
    "###.###.##0,00€"
    Would be better.

    These allow you to encode things like thousand separators, decimal separators, currency symbol, currency symbol placement, and so on, in the resource file.

    Quote Originally Posted by mayankkedia View Post
    So now if all the data from the server is unicode/UTF8 how exactly does it gets rendered in say Chinese on the device, do I have to do anything specifically or the underlying framework handles that for me?
    All Strings in Java are Unicode, so as far as Java is concerned, there is no difference between Latin characters, Cyrillic, Arabic, Chinese or whatever.

    You do depend on what characters exist in the device's font. A device sold in Europe, for example, probably doesn't have Chinese characters in its font (to save space). However, a device sold in China will do.

    (Be aware that a Nokia device sold in China will have Chinese-specific firmware. It will not be identical to the same model sold in other parts of the world. Sony Ericsson distinguish these by model name (for example, the K700 is known as the K700c (Chinese), K700a (America) or K700i ("international")). Nokia do not, so it is less apparent. If you look at the list of languages supported in the setup of your device, it will be specific to the region in which you bought the device.)

    Quote Originally Posted by mayankkedia View Post
    You mean could vary from manufacturer to manufacturer, where say Nokia might give me this feature while Samsung might decide not to? If thats the case is there some work around to standardize it?
    I mean that a Nokia 6230i (for example) sold in the UK will not support Chinese input. A Nokia 6230i sold in China will. Likewise, a Nokia 6230i sold in Russia will support Cyrillic input.

    Quote Originally Posted by mayankkedia View Post
    If it is null, is there no way to find the locale, maybe I end up having a setting page in my aplication for a locale change then,doesnt that work?
    Yes, that would be your only option.

    Quote Originally Posted by mayankkedia View Post
    So if I understand correct it ends up meaning that "Options" would remain options even in Chinese and not get translated so to say?
    The word "Options" will be supplied by the device, so will depend on the device's language set up. On a Chinese device, configured for Chinese language, the word will be correctly translated.

    The point here is: if you are unable to determine the device's locale (because, microedition.locale is null), and you need to provide your own language setting in your application, there will be some UI elements that you cannot set. If the user sets the device's locale to "English" and your application to "French", different parts of the UI will be in different languages. There is nothing you can do about this: you simply need to be aware of it.

    Graham.

  5. #5
    Super Contributor
    Join Date
    Mar 2004
    Location
    Bangalore,India
    Posts
    2,146

    Re: Locale support on J2ME

    All Strings in Java are Unicode, so as far as Java is concerned, there is no difference between Latin characters, Cyrillic, Arabic, Chinese or whatever.

    You do depend on what characters exist in the device's font. A device sold in Europe, for example, probably doesn't have Chinese characters in its font (to save space). However, a device sold in China will do.
    That makes a lot of sense, so lets say if the device does have Chinese fonts, then if my strings from the server are in unicode do they get rendered on the UI as Chinese?(I dont care about the various Chinese variants for instance right now!!)

    Also I am wondering why would they have a microedition.locale call returning a NULL would there a reason to it or what?

    Thanks for all the other replies, clears a lot of doubts :-)
    Cheers,
    Mayank

  6. #6
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Locale support on J2ME

    Yes. Take a String with two characters:

    Code:
    "\u4f60\u597d"
    A device with Chinese characters in its font will render this string as "你好" (assuming your PC has Chinese suport installed!). A device without Chinese characters will render this string something like "□□" (depending on how the device renders characters it doesn't know).

    So far as I know, all Nokia devices will return some kind of locale information. However, the MIDP specification says only that microedition.locale must return the locale information (in one of the two formats I gave earlier) if the return value is not null. Some devices will return null, simply because the manufacturer never implemented any functionality to provide locale information.

    Most devices do return a locale string. Your bigger problem is that some will return only language, not region. This means you cannot rely on differentiating (for example) "en-GB" and "en-US". This is dependent on whether the device has settings for "English (UK)" and "English (US)", or just "English". (Not a unique problem to English. Same applies any language that is spoken in multiple regions, where the different regions may use different spellings, different currencies, different date formats, and so on.)

    Nokia emulators (certainly Series 40 emulators) can usually emulate the device as you would see it in different locales, so you can see what your app will look (and behave) like on a Chinese handset.

    Graham.

  7. #7
    Super Contributor
    Join Date
    Mar 2004
    Location
    Bangalore,India
    Posts
    2,146

    Re: Locale support on J2ME

    Sorry to wake up this slightly old thread here.

    So now lets say I have content endcoded in UTF8 at the server and sent to the client, would the same UTF8 be rendered to Chinese/Hebrew/Arabic(basically whatever is the currently selected language on the device)?

    Where my doubt comes from is say the server sends me just UTF8, since its language agnostic, it should translate to whatever language is selected and provided the font libraries are installed.

    For instance if the server sends me UTF8 for some text that was Chinese, and the language on the device is English, what happens?
    Cheers,
    Mayank

  8. #8
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Locale support on J2ME

    The characters you send will be the same when they are received. The language selected on the device is irrelevant. UTF8 is just a way to encode unicode characters (which are 16 bits each) into bytes (which are, of course, 8 bit chunks).

    If the server needs to send text, then the device should send a code to the server to indicate the required language.

    Graham.

  9. #9
    Super Contributor
    Join Date
    Mar 2004
    Location
    Bangalore,India
    Posts
    2,146

    Re: Locale support on J2ME

    oh alright so then it means if the server sends me chinese in unicode, if the chinese font is there, i will see it in chinese. if the server sends me hebrew in unicode i see it as hebrew on the device. the currently selected language on the device wouldnt make any difference?

    so its not like if server sends me unicode it can get rendered to any language i chose on the client?
    Cheers,
    Mayank

  10. #10
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Locale support on J2ME

    That's right. There is no language translation. It's just a sequence of characters.

    Graham.

  11. #11
    Super Contributor
    Join Date
    Mar 2004
    Location
    Bangalore,India
    Posts
    2,146

    Re: Locale support on J2ME

    Hopefully the last question in this chain.

    I am developing all my UI in a custom way using the low level API's, which means that the settext sort of functions have to handled by me only. So in that case if the server sends me Chinese in UTF8 encoded content, do I need to tokenize the UTF8 content back to strings and then pass them to my settext function or how because if i just pass '\u4f60\u597d' directly to it, it doesnt understand, so probably i need to remove the '\u' from each of the characters or how?

    If not in UTF8 is there any other way this can be done. J2ME applications do render/support localization for multiple-languages where some content could be coming directly from the server instead of hard-coded strings in resource bundles on the client side, right?
    Cheers,
    Mayank

  12. #12
    Nokia Developer Champion
    Join Date
    Feb 2009
    Location
    Noida, India
    Posts
    3,085

    Re: Locale support on J2ME

    If your target device support "Chinese" i.e. that the fonts on the device has extended Chinese unicode characters then it directly prints/displays the UTF-8 encoded strings.

    But if your device character set does not support Chinese characters then above will be rendered as blanks or square boxes, and you need have your own implementation of bitmap fonts to supports these extended unicode character set.


    thanks,
    ~Amitabh
    Follow me on my blog for Innovative Mobile Apps
    Last edited by im2amit; 2009-09-03 at 17:48.

  13. #13
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Locale support on J2ME

    The "\uxxxx" form is only used in source code. If you create a string like this dynamically at run time, it will display as "\uxxxx". The translation of \u codes into characters is done by the compiler.

    I think you're worrying too much about unicode characters. Unicode characters are just characters. Russian, Chinese, Greek, Latin, it doesn't matter. You don't have to handle them in a special way. All characters are unicode.

    On the server:

    Code:
    byte[] utf = myString.getBytes("UTF-8");
    When you receive the data on the phone:

    Code:
    String s = new String(utf, "UTF-8");
    That's it. That's all you need to do.

    Graham.

  14. #14
    Super Contributor
    Join Date
    Mar 2004
    Location
    Bangalore,India
    Posts
    2,146

    Re: Locale support on J2ME

    For some reason I keep re-opening this thread :-)

    I am implementing a text-box using low level API instead of using the high level text-box provided by J2ME. Now the thing is I want to support entering the text in different languages, in this case Simplified Chinese and English. Using the low-level implementation I am not sure how this works, just wanted to understand the internal working of the high level text-box to see if the same can be implemented.

    How does the text-box provide the Chinese alphabets when user presses the keys? What sort of a mapping exists there, so I can think of a similar mapping for my low-level text-box as well. Is it implemented using the image strips concept or how possibly?
    Cheers,
    Mayank

Similar Threads

  1. j2ME and DRM support
    By Paranoid_Android in forum Mobile Java Networking & Messaging & Security
    Replies: 3
    Last Post: 2009-01-14, 12:15
  2. Does J2ME support simulate key event?
    By andy205214 in forum Mobile Java General
    Replies: 2
    Last Post: 2008-07-31, 04:14
  3. GSM call support in Symbian J2ME platform
    By lss0986 in forum Mobile Java Networking & Messaging & Security
    Replies: 1
    Last Post: 2008-04-11, 01:24
  4. A2DP support in J2ME
    By ppiggy in forum Bluetooth Technology
    Replies: 4
    Last Post: 2006-11-07, 21:39
  5. Does J2ME support "Timer()" ?
    By spartchou in forum Mobile Java General
    Replies: 3
    Last Post: 2005-08-06, 06:33

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×