★ wanayoo — archive 1999 http://developer.java.sun.com/developer/community/chat/JavaLive/1997/jl0506.htmlNouvelle recherche | Portail wanayoo
Java Technology Home Page
A-Z Index

Java Developer Connection(SM)
Chat

Downloads, APIs, Documentation
Java Developer Connection
Tutorials, Tech Articles, Training
Online Support
Community Discussion
News & Events from Everywhere
Products from Everywhere
How Java Technology is Used Worldwide
Print Button
 
JavaLive Transcripts Index

Java Live
Internationalization
May 06, 1997

Moderator (MDR): MDR-lisa

Guest Speaker (SPK): SPK-name

MDR-lisa: Hi, I'm Lisa Stapleton, and I'll be your moderator today. Brian Beck, the team leader for the internationalization features of the JDK, will be joining me shortly. Feel free to start sending in questions, and he'll answer them when he gets here.

jdempsey: Hi Brian, Do most of the JDK Internationalization capabilities address only UI concerns (labels, informational messages, etc.)? How is actual data handled, or is that left to the developer to handle. For instance, a part description is stored in a database and may need to be displayed to one user in a particular language, and another user in a different language.

SPK-BrianBeck: Do you mean that your parts description is stored as text in some particular language?

jdempsey: Yes, I could see storing it in lookup (decode) tables of some sort, and then using the locale ID as a key for the lookup.

MDR-lisa: I joined in as a moderator. The forum is now moderated

robink: Hello Lisa, I am Robin Kidd from IBM Education and Training. Will there be full double-byte character support available?

SPK-BrianBeck: Yes. You could certainly use Locales as a key in a database. We made Locale objects very lightweight just for this reason. Of course you could also use ResourceBundles, which is a storage mechanism that is indexed by Locale What do you mean by full double-byte support? Are you referring to character set conversion only? Or do you mean all the support necessary for Asian languages?

MDR-lisa: My question queue is empty, so feel free to let 'er rip. Meanwhile, Brian, would you like to expand on recently added internationalization features, and perhaps future directions?

SPK-BrianBeck: Well, improved Asian language support is a big one right now. One big limitiation with JDK 1.1 was the support for Input Methods. JDK 1.1 was only able to use host Input Methods through the AWT peers. That meant that AWT TextField and TextArea could connect to an IM but you could not, for example, write your own text editor control from a Canvas and have it use an IM. So addressing this is an important part of JDK 1.2 We will have an Input Method Framework that will accomplish two things. First it will allow you to plug in any various existing Input Method Engines. Second, it will present a common API to these engines through the AWT.

dlocker: HI Brian. I seem to be having probems formatting messages according to the intlspec.doc5.html. Under Formatting Messages there is a set of code. The fmt.format(...) method returns me the pattern string without plugging in my arguments.

SPK-BrianBeck: Hmm. We made a change to the MessageFormat syntax during one of our betas. The old syntax was something like: "Here is a %0, and a %1" The new syntax is: "Here is a {0} and a {1}" Is it possible you are still using the old syntax? This would explain the fact that you are not seeing any substitution.

dlocker: I think that's it. I was looking through the code and saw a switch referencing '{' and '}'. The light has come on!

SPK-BrianBeck: Good. That change has thrown a bunch of people. But it was necessary to have a start and end delimiter ( the { and } ) because we also added the ability to inline syntax from other format objects. So now you can say something like: "Here is a date {0,date,MM dd yy}. " to get a date like 12 04 67. Another new item we're working on for 1.2 is better text rendering capabilities. This will be added as part of the 2D Graphics API. We will be adding a LineLayout class that will be able to layout lines of text and do interesting things like bi-directional layout. It will also be designed to handle vertical text layout - although that might not be fully implemented for 1.2

dlocker: Is there a more current set of documentation?

SPK-BrianBeck: The documentation on our website, java.sun.com, is the most current available. While the "spec" document is out of date with the code, the JavaDoc is in good shape.

MDR-lisa: The question queue just went dry. Anyone want to ask Brian Beck, our internationalization team lead, about new or planned features, etc.? So vertical text layout would let you do languages that run down the page?

SPK-BrianBeck: We are of course continuing to improve our documentation set. We're hoping to begin work on a "Guide to Internationalization in Java" type book. It will probably take awhile to get written but I think it will be an excellent resource. That's right. And we will support both top-to-bottom, right-to-left as is used in China and Japan, as well as top-to-bottom, left-to-right as is used in Mongolia.

MDR-lisa: What about calendaring? Where are we in this release, and where are we going?

SPK-BrianBeck: JDK 1.1 introduces the Calendar class which is an abstract class for interpreting a date according to some calendar system. We also provided the GregorianCalendar sub-class which knows about the Gregorian calendar system that is used by most European countries. There are, of course, other important calendar systems that need to be supported. The Japanese Imperial calendar is probably the first one on our list. But eventually there should be support for other systems such as Chinese lunar calendars, or Arabic lunar calendars. These will be supported by adding new sub-classes of Calendar.

kchang: Hi: I used get method to talk to CGI. It works for Java application. But, when I tried with Java Applet, it failed at getInputStream. Is this a bug?

MDR-lisa: Questions, anyone? Don't be shy

SPK-BrianBeck: So maybe I can ask a question here. Are there any year 2000 experts in the group? We have an issue with our DateFormat class that needs to be resolved. The problem is that DateFormat lets you write two digit numeric dates like 1997 -> "97" The problem is how should we interpret these when we parse them back in? A number of possible rules: Assume current century Assume a century that makes the date closer in time to the current date, thus 1/1/02 would be 2002 not 1902. Allow user to say dates should be parsed as "in the past" Allow user to say dates should be parsed as "in the future" Any other ideas

shaji: I am new to Internationalization. In the Java scheme of things who is responsible for shipping fonts?

MDR-lisa: Interesting problem that you pose, Brian. We've got about ten more minutes, so if you have questions or comments, send them in soon.

SPK-BrianBeck: Well, this is a good question. JDK does not currently ship any fonts. We use whatever is on the host system. JDK 1.1 introduced a configuration file called font.properties that allows you to specify what system fonts to use. The problem of course is what to do when a particular system doesn't have the fonts you want. This may be because you wrote a document and chose a font that the client doesn't have. Or it may be because you need a font for a certain language that the client doesn't have. We are hoping to sort these things out in the 2-D Graphics API.

sellhorn: I'm also very new to this subject ... How could you internationalize this error string: "There is currently no <a> <b> in the store" Where a is "red" and "b" is a car. I'm asking this because in spanish it would be "No hay ningun <b> <a> en la tienda" Where b is "carro"(car) and a is "rojo"(red)

MDR-brian: You would use a MessageFormat object to do this. The English pattern string would be "There is currently not {0} {1} in the store". The Spanish pattern string would be: "No hay ningun {1} {0} en la tienda" You would have the pattern strings stored in a ResourceBundle under their appropriate locale. You might also have the argument translations in a ResourceBundle as well.

sellhorn: I guess I've got to read the API. The resource bundle is sort of like a "dictionary" of properties (gotten from a resource file)?

MDR-brian: That's right. It's a dictionary whose keys include a locale component. ResourceBundles do not specifically dictate that you store the resources in properties files. You can write subclasses that obtain the resource from anywhere. We do have one particular kind of ResourceBundle - the PropertyResourceBundle that does use properties files however.

MDR-lisa: This is the two-minute warning, and then we'll have to go. Well, that's all for today. Thanks to Brian, our guest, and to all of the other participants. A transcript will go up on our JDC page later this week.

vijayam: I am able to read and display Chinese characters using ReadChar method, in Text area but not in Canvas. How do we do this?

vijayam: Is anyone still there who can answer my question? I know, I am a bit too late.

MDR-lisa: Brian just left before we got your question, but I'll ask him to send you mail, if you send a private message to me at lisast@eng.sun.com. Last moderator (me) signing off. The forum is now unmoderated


Print Button
[ This page was updated: 30-Mar-2000 ]
Products & APIs | Developer Connection | Docs & Training | Online Support
Community Discussion | Industry News | Solutions Marketplace | Case Studies
Glossary - Applets - Tutorial - Employment - Business & Licensing - Java Store - Java in the Real World
FAQ | Feedback | Map | A-Z Index
For more information on Java technology
and other software from Sun Microsystems, call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's AT&T Direct Access Number first.
Sun Microsystems, Inc.
Copyright © 1995-2000 Sun Microsystems, Inc.
All Rights Reserved. Terms of Use. Privacy Policy.