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.
Description
Please direct comments on this JSR to the Spec Lead(s).
Stage timeline
| Stage | Access | Start | Finish |
|---|---|---|---|
| Withdrawn | 08 Feb, 2005 | ||
| Expert Group Formation | 14 Nov, 2000 | ||
| JSR Review Ballot | View results | 31 Oct, 2000 | 13 Nov, 2000 |
Team
Specification Leads
- Debasish BanerjeeIBM
Expert Group
- Art Technology Group Inc.(ATG)
- IBM
- Novell, Inc.
- Vosicki, Gordan
Proposal
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.
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: gulczins@us.ibm.com, schleus@us.ibm.com Telephone Number: +1 507 253 6442, +1 507 253 6236 Fax Number: N/A Specification Lead: Dave Gulczinski E-Mail Address: gulczins@us.ibm.com Telephone Number: +1 507 253 6442 Fax Number: N/A
Section 2: Request
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. A distributed client and EJB server environment (desktops and servers). In a distributed environment, Localizable Text does the proper translation
of text information to the users desired locale.
Java's current locale processing deals with only one JVM, not multiple
JVMs in a distributed environment
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.
Arguments
- LTFs, a LTF can be used as an argument for another LTF. LTFs
implement all the Localizable Interfaces
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. java.text.LocalizableText No No No No Community Review: October 2000
Section 3: Contributions
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.
The Localizable Text design document and presentation can be used as the
starting point.
2.1 Please describe the proposed Specification:
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
2.3 What need of the Java community will be addressed by the proposed specification?
2.4 Why isn't this need met by existing specifications?
2.5 Please give a short description of the underlying technology or technologies:
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).
- 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
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.
Public Review: November to December 2000
Proposed Final Draft: February 2001
Reference Implementation and Technology Compatibility Kit Available:
Q3 2001
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.
http://www-4.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/was/atswpgpm.html#HDRPMELOC
http://www-4.ibm.com/software/webservers/appserv/doc/v40/aes/apidocs/com/ibm/websphere/i18n/localizabletext/package-summary.html
http://www-4.ibm.com/software/webservers/appserv/3.2 Explanation of how these items might be used as a starting point for the work.
The implementation can be used as a proof of concept, as well as an
initial code base.