Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 92: Localizable Text

This JSR has been Withdrawn
Reason: Both JSR-92 and JSR-150 address the issue of 'distributed internationalization' in the J2EE world. JSR-92 is somewhat client-centric in nature while JSR-150 attempts to provide a server-side solution. The progress of JSR-92 is rather slow, and some of the issues raised in JSR-92 can be addressed more elegantly by the technology advocated in JSR-150. The existence of two separate JSRs for the same issue of distributed internationalization can generate unnecessary confusion. Hence we feel JSR-92 should be withdrawn from the JSR space altogether. We will incorporate relevant portions of JSR-92 in JSR-150.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: Localizable Text is the infrastructure necessary to translate language neutral information (in an object) from anywhere in a distributed network. When the object is formatted the Locale, TimeZone and language neutral information is sent to a server where the translated text is assembled from Resource Bundles.

Section 1. Identification

Submitting Member: IBM

Name of Contact Person: Dave Gulczinski, Mark T Schleusner

E-Mail Address:,

Telephone Number: +1 507 253 6442, +1 507 253 6236

Fax Number: N/A

Specification Lead: Dave Gulczinski

E-Mail Address:

Telephone Number: +1 507 253 6442

Fax Number: N/A

Section 2: Request

2.1 Please describe the proposed Specification:

A user creates a LocalizableTextFormatter object containing language neutral information to be used for translation to any locale. When a format method is called on the LocalizableTextFormatter object, the JVM's default Locale/TimeZone, or a passed Locale/TimeZone, is sent along with the language neutral information to a server where the Resource Bundles (property or class files) contain the translated text. On the server the translation to the client's desired locale is done using the existing Java ResourceBundle and MessageFormat classes. The translated string is then returned to the user. The same LocalizableTextFormatter object can be passed around the network and wherever it is formatted, it will return the desired translated text.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

A distributed client and EJB server environment (desktops and servers).

2.3 What need of the Java community will be addressed by the proposed specification?

In a distributed environment, Localizable Text does the proper translation of text information to the users desired locale.

2.4 Why isn't this need met by existing specifications?

Java's current locale processing deals with only one JVM, not multiple JVMs in a distributed environment

2.5 Please give a short description of the underlying technology or technologies:

Localizable Text uses a language neutral LTF (LocalizableText Formatter) object which contains a resource bundle name, resource bundle key, and an optional argument array to do the translation. When the LTF's format method is called this information is sent to a server where the translated text is assembled. The below diagram shows one possible use of how the translation could occur.

  1. A client on a desktop PC makes a request from an application on a server.
  2. The server application detects a problem and creates a LTF object which contains the language neural information to describe the problem.
  3. The LTF is returned to the client. Note: Typical user may have the LTF contained within another object.
  4. The client does a format() on the LTF.
  5. The LTF finds a LTB (Localizable Text Bean) on an EJB server. Note: This bean could be a Stateless Session EJB.
  6. The default Locale and TimeZone of the client's JVM, plus the LTF's language neutral information is sent to the bean.
  7. Assembly of the translated text takes place. Using the passed information, the bean calls a java.util.ResourceBundle getBundle method to access the user supplied bundles, processes the optional argument array, then does a jave.text.MessageFormat format method to get the translated text.
  8. The translated text is returned to the client's LTF. Note: The translated text for this Locale and Time Zone may be cached within the LTF for future use.
  9. The translated text is returned to the client.

The optional LTF argument array is used as input to the java.text.MessageFormat arguments after special processing of the below arguments. These special arguments all implement the Localizable Interface or reference objects that implement the Localizable Interface. The Localizable Interface has methods: format(), format(Locale), format(TimeZone) or format(Locale, TimeZone).

- LTFs, a LTF can be used as an argument for another LTF. LTFs implement all the Localizable Interfaces
- User written arguments which implement a Localizable Interface
- EJB Objects which reference Enterprise Beans that implement a Localizable interface
- Handles which reference Enterprise Beans that implement a Localizable interface

To overcome problems with TimeZones in a distributed environment, a special class called LocalizableTextDateTimeArgument has been developed. This class uses the client's desired Locale and TimeZone to localize a Date object for processing as an argument in a LocalizableTextFormatter object. An implementation of this LocalizableTextDateTimeArgument class should be considered along with this JSR as many users may want to have their time zones properly processed.

The java.text.MessageFormat formatters are not supported because they are positional. Users can write their own argument classes to do whatever argument formatting they desire.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.8 Are there any security issues that cannot be addressed by the current security model?


2.9 Are there any internationalization or localization issues?


2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.11 Please describe the anticipated schedule for the development of this specification.

Community Review: October 2000
Public Review: November to December 2000
Proposed Final Draft: February 2001
Reference Implementation and Technology Compatibility Kit Available: Q3 2001

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

IBM WebSphere Application Server, Version 4.0 - External link to Localizable Text User Documentation

IBM WebSphere Application Server, Version 4.0 - External link to Localizable Text API documentation (Javadoc)

IBM WebSphere Application Server, Version 4.0 - A free trial download of the WebSphere Application Server. It may be used to evaluate the actual Localizable Text function.

3.2 Explanation of how these items might be used as a starting point for the work.

The Localizable Text design document and presentation can be used as the starting point.
The implementation can be used as a proof of concept, as well as an initial code base.