You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Robert Simpson <RS...@Verizon.net> on 2003/02/08 20:33:43 UTC
[Jakarta Commons Locale] PROPOSAL
Proposal for Commons Locale component
This is a proposal for creating a Locale component in the Jakarta Commons
subproject, superseding and encompassing the "Resources" component
that is currently in the Jakarta Commons sandbox.
An HTML version of this proposal can be found at http://iToolSet.com/locale/PROPOSAL.html
0) Rationale
There are many different types of Java(TM)* objects that may be included in
Java applications that support internationalization (i18n). These include
resources, message strings, formatters, Calendars, Currency objects, TimeZones,
Exceptions, Collators, and BreakIterators, among others.
There currently is a "Resources" component in the Jakarta Commons sandbox.
However, there should be a common architecture for internationalization of any
object, not one that is limited to Resources. Therefore, a "Locale" component
should be added to the Jakarta Commons proper. The functions provided by the
"Resources" component currently in the sandbox could be provided in a subpackage
under the package created for the new Locale component.
1) Scope of the Component
The proposal defines a common framework for internationalization of various
Java classes. This internationalization typically occurs by localizing
instances of Java objects to a specific Locale. The proposed framework would
facilitate the internationalization of all objects to a single Locale per user,
in either a single-user or multi-user environment. For example, when localizing
messages, both the message patterns and the inserted arguments should be localized
to the same Locale. This is a good example of why internationalization should occur
at a higher level than simply the resources that supply the localized message patterns.
Two interfaces, "Localizable" (used by classes that implement both a get and
set method for the Locale) and "Localized" (for classes that implement a get method
only) would be defined. Other implementers would be encouraged to declare their
classes with one of these interfaces where appropriate. Where this occurs, any
Factory classes which generate localized/localizable (localized/able) versions of
those objects would be included in that same package, rather than under the Locale
component. This is appropriate, since it makes sense to keep the Factory and the
base class or interface it creates in the same package. In contrast, for classes
provided by Sun Microsystems or third parties, where the source code could not be
modified, a localized/able subclass of the Sun/third party class would be created
within the Locale component, typically in a subpackage structure that in some way parallels
the structure in which the base class resides (in the initial code, this has already
been done for most of the Java SDK classes). This would allow other Jakarta
subprojects and components to locate and include such classes in a consistent manner.
1.5) Interaction With Other Subpackages and Components
In the initial code, there are a number of classes that abstract various classes provided
in different versions of the Java SDKs that can be used for configuration parameters (Properties,
Preferences, and the Preferences SPI). These classes might be most appropriately placed in the
Jakarta Commons Util component (with specific implementations in "props" and "prefs" subpackages).
If this was not acceptable, those classes could be placed under the Locale component.
The proposed component will probably contribute only to other components within the Jakarta
Commons subproject, primarily the "util" (as mentioned above) and possibly "lang" component.
On the other hand, it is expected that other components and subpackages will make use of the
Locale component anywhere they need to provide for internationalization of their objects,
resulting in much heavier interaction inbound rather than outbound, which should be typical
of the Commons subpackage in general.
2) Initial Source of the Package
The initial source of the package would be obtained from existing code (after the
addition of comments to meet Apache requirements), which can be found in a .zip file
that can be downloaded from http://iToolSet.com/locale/CommonsLocale.zip. This code
has been revised somewhat to demonstrate how it might appear in the Apache world, and
to provide a working example. The example, which simulates the use of localized resources
in a multi-user (ex: servlets) environment with both local client-side (multiple users with
distinct locales) and remote server-side (single server with it's own locale) destinations,
can be run by executing the "test2.bat" batch file or the "test2.sh" shell script.
(The test is currently set up to run under version 1.4).
The JavaDoc for the initial code can be found http://iToolSet.com/locale/docs/index.html".
Code for new classes, such as for Factory classes that could produce Localized instances of objects
for third-party classes could be submitted by other developers, most likely via communication
with one or more of the committers for this component or the Commons subproject. The committer(s)
would verify conformance with the interfaces, scope and principles of this component before
permanently adding the new classes.
3) Required Jakarta-Commons Resources
CVS Repository
New directory "locale" in the
"jakarta-commons" CVS repository. Revise initial
committers based on initial committers list (below).
Revise committers list or designate contact with committer privileges for
subpackages for classes which may be more appropriately placed in other Jakarta
Commons components (see "Interaction with Other Packages and Components" above).
Create "props" and "prefs" subdirectories under the Commons "util" directory.
Check in the initial code for abstraction of Sun's "java.util.Properties" and
"java.util.prefs.Preferences" classes into those three directories.
Mailing List
Discussions will take place on the general Jakarta
"commons-user" and "commons-dev" mailing lists. To help
list subscribers identify, sort or filter messages of interest, it is suggested that
the message subject of messages about this component be prefixed with "[Locale]".
Bugzilla
New component "Locale" under the "Commons" product
category, with appropriate version identifiers as needed.
4) Initial Committers
The initial committers on the Locale component shall be Robert Simpson and,
tentatively, Craig McClanahan, Michael Schachter, Jason van Zyl, and Daniel Rall.
(For the "tentative" committers, who had some interest in the Resources component,
an e-mail would be sent to them asking if they would still be willing to be committers
for the Locale component. They would be included in the committers list based on
their agreement.)
* Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [DISCUSSION] PROPOSAL for Jakarta Locale or Commons Locale
Posted by Robert Simpson <RS...@Verizon.net>.
Thanks for steering me in the right direction. Being relatively new to the Apache stuff, I wasn't quite sure of the approach to take, so the proposal was a combination of what I found at http://jakarta.apache.org/site/newproject.html and an existing proposal, which now looks like it had come from the URL you referenced (sorry, I had missed that one). And therefore it's probably not ready for a binding vote yet.
One point of discussion is whether the "Internationalization" stuff belongs as a Jakarta subproject, or as a Commons component (or neither, in which case it simply disappears). Any suggestions on how that determination might be made would be helpful.
Thanks again.
Robert Simpson
Rodney Waldhoff wrote:
> You might want to try this again on the commons-dev@jakarta.apache.org
> list, instead of jakarta-general (see #17 at
> <http://jakarta.apache.org/commons/charter.html>) preferably with [VOTE]
> in the subject line as well as "PROPOSAL", if your intention is to call a
> binding vote right now (as opposed to discussion of the proposal).
>
> (I'll note Robert used the conventional proposal format, so we can
> probably assume the to line was accidental.)
>
> On Sat, 8 Feb 2003, Robert Simpson wrote:
>
> > Proposal for Commons Locale component
> >
> > This is a proposal for creating a Locale component in the Jakarta Commons
> > subproject, superseding and encompassing the "Resources" component
> > that is currently in the Jakarta Commons sandbox.
> >
> > An HTML version of this proposal can be found at http://iToolSet.com/locale/PROPOSAL.html
> >
> >
> > 0) Rationale
> >
> > There are many different types of Java(TM)* objects that may be included in
> > Java applications that support internationalization (i18n). These include
> > resources, message strings, formatters, Calendars, Currency objects, TimeZones,
> > Exceptions, Collators, and BreakIterators, among others.
> >
> > There currently is a "Resources" component in the Jakarta Commons sandbox.
> > However, there should be a common architecture for internationalization of any
> > object, not one that is limited to Resources. Therefore, a "Locale" component
> > should be added to the Jakarta Commons proper. The functions provided by the
> > "Resources" component currently in the sandbox could be provided in a subpackage
> > under the package created for the new Locale component.
> >
> >
> > 1) Scope of the Component
> >
> > The proposal defines a common framework for internationalization of various
> > Java classes. This internationalization typically occurs by localizing
> > instances of Java objects to a specific Locale. The proposed framework would
> > facilitate the internationalization of all objects to a single Locale per user,
> > in either a single-user or multi-user environment. For example, when localizing
> > messages, both the message patterns and the inserted arguments should be localized
> > to the same Locale. This is a good example of why internationalization should occur
> > at a higher level than simply the resources that supply the localized message patterns.
> >
> > Two interfaces, "Localizable" (used by classes that implement both a get and
> > set method for the Locale) and "Localized" (for classes that implement a get method
> > only) would be defined. Other implementers would be encouraged to declare their
> > classes with one of these interfaces where appropriate. Where this occurs, any
> > Factory classes which generate localized/localizable (localized/able) versions of
> > those objects would be included in that same package, rather than under the Locale
> > component. This is appropriate, since it makes sense to keep the Factory and the
> > base class or interface it creates in the same package. In contrast, for classes
> > provided by Sun Microsystems or third parties, where the source code could not be
> > modified, a localized/able subclass of the Sun/third party class would be created
> > within the Locale component, typically in a subpackage structure that in some way parallels
> > the structure in which the base class resides (in the initial code, this has already
> > been done for most of the Java SDK classes). This would allow other Jakarta
> > subprojects and components to locate and include such classes in a consistent manner.
> >
> > 1.5) Interaction With Other Subpackages and Components
> >
> > In the initial code, there are a number of classes that abstract various classes provided
> > in different versions of the Java SDKs that can be used for configuration parameters (Properties,
> > Preferences, and the Preferences SPI). These classes might be most appropriately placed in the
> > Jakarta Commons Util component (with specific implementations in "props" and "prefs" subpackages).
> > If this was not acceptable, those classes could be placed under the Locale component.
> >
> > The proposed component will probably contribute only to other components within the Jakarta
> > Commons subproject, primarily the "util" (as mentioned above) and possibly "lang" component.
> > On the other hand, it is expected that other components and subpackages will make use of the
> > Locale component anywhere they need to provide for internationalization of their objects,
> > resulting in much heavier interaction inbound rather than outbound, which should be typical
> > of the Commons subpackage in general.
> >
> >
> > 2) Initial Source of the Package
> >
> > The initial source of the package would be obtained from existing code (after the
> > addition of comments to meet Apache requirements), which can be found in a .zip file
> > that can be downloaded from http://iToolSet.com/locale/CommonsLocale.zip. This code
> > has been revised somewhat to demonstrate how it might appear in the Apache world, and
> > to provide a working example. The example, which simulates the use of localized resources
> > in a multi-user (ex: servlets) environment with both local client-side (multiple users with
> > distinct locales) and remote server-side (single server with it's own locale) destinations,
> > can be run by executing the "test2.bat" batch file or the "test2.sh" shell script.
> > (The test is currently set up to run under version 1.4).
> > The JavaDoc for the initial code can be found http://iToolSet.com/locale/docs/index.html".
> >
> > Code for new classes, such as for Factory classes that could produce Localized instances of objects
> > for third-party classes could be submitted by other developers, most likely via communication
> > with one or more of the committers for this component or the Commons subproject. The committer(s)
> > would verify conformance with the interfaces, scope and principles of this component before
> > permanently adding the new classes.
> >
> >
> > 3) Required Jakarta-Commons Resources
> >
> > CVS Repository
> >
> > New directory "locale" in the
> > "jakarta-commons" CVS repository. Revise initial
> > committers based on initial committers list (below).
> >
> > Revise committers list or designate contact with committer privileges for
> > subpackages for classes which may be more appropriately placed in other Jakarta
> > Commons components (see "Interaction with Other Packages and Components" above).
> >
> > Create "props" and "prefs" subdirectories under the Commons "util" directory.
> > Check in the initial code for abstraction of Sun's "java.util.Properties" and
> > "java.util.prefs.Preferences" classes into those three directories.
> >
> > Mailing List
> >
> > Discussions will take place on the general Jakarta
> > "commons-user" and "commons-dev" mailing lists. To help
> > list subscribers identify, sort or filter messages of interest, it is suggested that
> > the message subject of messages about this component be prefixed with "[Locale]".
> >
> > Bugzilla
> >
> > New component "Locale" under the "Commons" product
> > category, with appropriate version identifiers as needed.
> >
> >
> > 4) Initial Committers
> >
> > The initial committers on the Locale component shall be Robert Simpson and,
> > tentatively, Craig McClanahan, Michael Schachter, Jason van Zyl, and Daniel Rall.
> > (For the "tentative" committers, who had some interest in the Resources component,
> > an e-mail would be sent to them asking if they would still be willing to be committers
> > for the Locale component. They would be included in the committers list based on
> > their agreement.)
> >
> >
> > * Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [Jakarta Commons Locale] PROPOSAL
Posted by Rodney Waldhoff <rw...@apache.org>.
You might want to try this again on the commons-dev@jakarta.apache.org
list, instead of jakarta-general (see #17 at
<http://jakarta.apache.org/commons/charter.html>) preferably with [VOTE]
in the subject line as well as "PROPOSAL", if your intention is to call a
binding vote right now (as opposed to discussion of the proposal).
(I'll note Robert used the conventional proposal format, so we can
probably assume the to line was accidental.)
On Sat, 8 Feb 2003, Robert Simpson wrote:
> Proposal for Commons Locale component
>
> This is a proposal for creating a Locale component in the Jakarta Commons
> subproject, superseding and encompassing the "Resources" component
> that is currently in the Jakarta Commons sandbox.
>
> An HTML version of this proposal can be found at http://iToolSet.com/locale/PROPOSAL.html
>
>
> 0) Rationale
>
> There are many different types of Java(TM)* objects that may be included in
> Java applications that support internationalization (i18n). These include
> resources, message strings, formatters, Calendars, Currency objects, TimeZones,
> Exceptions, Collators, and BreakIterators, among others.
>
> There currently is a "Resources" component in the Jakarta Commons sandbox.
> However, there should be a common architecture for internationalization of any
> object, not one that is limited to Resources. Therefore, a "Locale" component
> should be added to the Jakarta Commons proper. The functions provided by the
> "Resources" component currently in the sandbox could be provided in a subpackage
> under the package created for the new Locale component.
>
>
> 1) Scope of the Component
>
> The proposal defines a common framework for internationalization of various
> Java classes. This internationalization typically occurs by localizing
> instances of Java objects to a specific Locale. The proposed framework would
> facilitate the internationalization of all objects to a single Locale per user,
> in either a single-user or multi-user environment. For example, when localizing
> messages, both the message patterns and the inserted arguments should be localized
> to the same Locale. This is a good example of why internationalization should occur
> at a higher level than simply the resources that supply the localized message patterns.
>
> Two interfaces, "Localizable" (used by classes that implement both a get and
> set method for the Locale) and "Localized" (for classes that implement a get method
> only) would be defined. Other implementers would be encouraged to declare their
> classes with one of these interfaces where appropriate. Where this occurs, any
> Factory classes which generate localized/localizable (localized/able) versions of
> those objects would be included in that same package, rather than under the Locale
> component. This is appropriate, since it makes sense to keep the Factory and the
> base class or interface it creates in the same package. In contrast, for classes
> provided by Sun Microsystems or third parties, where the source code could not be
> modified, a localized/able subclass of the Sun/third party class would be created
> within the Locale component, typically in a subpackage structure that in some way parallels
> the structure in which the base class resides (in the initial code, this has already
> been done for most of the Java SDK classes). This would allow other Jakarta
> subprojects and components to locate and include such classes in a consistent manner.
>
> 1.5) Interaction With Other Subpackages and Components
>
> In the initial code, there are a number of classes that abstract various classes provided
> in different versions of the Java SDKs that can be used for configuration parameters (Properties,
> Preferences, and the Preferences SPI). These classes might be most appropriately placed in the
> Jakarta Commons Util component (with specific implementations in "props" and "prefs" subpackages).
> If this was not acceptable, those classes could be placed under the Locale component.
>
> The proposed component will probably contribute only to other components within the Jakarta
> Commons subproject, primarily the "util" (as mentioned above) and possibly "lang" component.
> On the other hand, it is expected that other components and subpackages will make use of the
> Locale component anywhere they need to provide for internationalization of their objects,
> resulting in much heavier interaction inbound rather than outbound, which should be typical
> of the Commons subpackage in general.
>
>
> 2) Initial Source of the Package
>
> The initial source of the package would be obtained from existing code (after the
> addition of comments to meet Apache requirements), which can be found in a .zip file
> that can be downloaded from http://iToolSet.com/locale/CommonsLocale.zip. This code
> has been revised somewhat to demonstrate how it might appear in the Apache world, and
> to provide a working example. The example, which simulates the use of localized resources
> in a multi-user (ex: servlets) environment with both local client-side (multiple users with
> distinct locales) and remote server-side (single server with it's own locale) destinations,
> can be run by executing the "test2.bat" batch file or the "test2.sh" shell script.
> (The test is currently set up to run under version 1.4).
> The JavaDoc for the initial code can be found http://iToolSet.com/locale/docs/index.html".
>
> Code for new classes, such as for Factory classes that could produce Localized instances of objects
> for third-party classes could be submitted by other developers, most likely via communication
> with one or more of the committers for this component or the Commons subproject. The committer(s)
> would verify conformance with the interfaces, scope and principles of this component before
> permanently adding the new classes.
>
>
> 3) Required Jakarta-Commons Resources
>
> CVS Repository
>
> New directory "locale" in the
> "jakarta-commons" CVS repository. Revise initial
> committers based on initial committers list (below).
>
> Revise committers list or designate contact with committer privileges for
> subpackages for classes which may be more appropriately placed in other Jakarta
> Commons components (see "Interaction with Other Packages and Components" above).
>
> Create "props" and "prefs" subdirectories under the Commons "util" directory.
> Check in the initial code for abstraction of Sun's "java.util.Properties" and
> "java.util.prefs.Preferences" classes into those three directories.
>
> Mailing List
>
> Discussions will take place on the general Jakarta
> "commons-user" and "commons-dev" mailing lists. To help
> list subscribers identify, sort or filter messages of interest, it is suggested that
> the message subject of messages about this component be prefixed with "[Locale]".
>
> Bugzilla
>
> New component "Locale" under the "Commons" product
> category, with appropriate version identifiers as needed.
>
>
> 4) Initial Committers
>
> The initial committers on the Locale component shall be Robert Simpson and,
> tentatively, Craig McClanahan, Michael Schachter, Jason van Zyl, and Daniel Rall.
> (For the "tentative" committers, who had some interest in the Resources component,
> an e-mail would be sent to them asking if they would still be willing to be committers
> for the Locale component. They would be included in the committers list based on
> their agreement.)
>
>
> * Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org