[i18n] Internationalization project
To: [EMAIL PROTECTED] On the Jakarta General list, we've been discussing the possibility of introducing an Internationalization project into incubation. It seems the consensus is that it should be targeted for a top-level programming-language-independent and spoken-language-independent Apache project, rather a Jakarta subproject. (To anyone on the JG list: I used a blind CC so that this is the only message on [EMAIL PROTECTED] which should be CCd to JG. You can set up message filters on [i18n] on both lists to follow the discussions in either place) A preliminary organization of the project based on the JG discussions is included in my message below. I don't mind spearheading the incubation myself. Is there anyone else interested whom we can add to the list of contributors (see A through F below)? Is there anything else we should consider before requesting entry into incubation? TIA. Robert Simpson Original Message Subject: Re: [i18n] Internationalization subproject sponsor? Date: Sun, 13 Jul 2003 21:32:36 +0100 From: robert burrell donkin [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] On Monday, July 7, 2003, at 01:14 PM, Robert Simpson wrote: snip I am surprised there isn't more interest in a common internationalization framework within Jakarta. But then I have been assuming that there are non-English-speaking members in Jakarta, not just committers and other users of the code. i think that there several jakarta members who are not native english speakers. as Tetsuya Kitahata pointed out there are far fewer members than committers and i'm not sure whether there are any jakarta members who are native speakers of non-latin languages. it takes a lot of energy to spearhead an incubation and it's a big commitment for a member to make. but i don't think that the member would have to come from jakarta (even if that's where those people involved with the product hope that it will end up). i wonder whether you might have more luck finding a sponsor over in xml-land. since many of their products are multi-language a common i18n framework may be of more pressing importance than here. i also have an idea that there are members whose native languages are non-latin. i like the idea of an apache wide i18n project along the lines suggested by Tetsuya Kitahata. - robert Original Message Subject: Re: [i18n] Internationalization subproject Date: Sat, 12 Jul 2003 08:55:00 -0400 Reply-To: Jakarta General List [EMAIL PROTECTED],[EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] WRT Santiago's point about keeping the different translations in sync, the solution is to have each word/phrase in (1) or each section in (2) identified in the XML with a version number. Then it would be a simple matter to have a program compare the two documents, and indicate where the translation needs to be updated (the program could even provide an initial translation of the section via machine translation, to be refined by the human translator). The XML should also indicate who made each change and whether a change was prompted by a need to change the document (additions to content, for example) or as a translation of another version. That way, no particular translation would have to be the primary document, and any conflicts could be identified and handled. For example, a Spanish-speaking person could add a missing section to the Spanish translation of a document, and that section could then be translated back into the original and other translations. This arrangement could also handle proposed additions (the XML equivalent of I, a Spanish translator, propose to add a new section here), which could be commented on (ex: that section would be better placed over there) and/or voted on by translators of other languages, etc Am I getting the feeling right that the Internationalization project would be ultimately targeted for a top level, multiple-programming-language Apache project? If so, I think the best approach would be to get the Java support done first, to demonstrate its viability and usefulness. But still, from the start, the intent should be to design with language-independence as the ultimate goal. So, in summary, the organization of the project would be: 1. code common to both (1) and (2) 1.1 code This would include any code that supports both (2) and (3), such as the code to do comparisons between translations 1.1.1 any programming-language-neutral stuff (configuration files, XML, etc) 1.1.2 Java 1.1.2.1 source code 1.1.2.1.1 source code contributors (committers) 1.1.3+ other programming languages, similarly 2. user interface internationalization (words and phrases) 2.1 code This would include the code to generate
Re: [i18n] Internationalization subproject sponsor?
David, The one-liner you sent (it's a static method rather than a static reference) would not change, but within the Localization class, the localization could be implemented using [i18n]: private static final ResourceBundleFamily rbf = ResourceBundleFamilyFactory.getForClass/Package(someClass); I've just started using Velocity, thanks for the tip - looks like a nice feature Robert Simpson David Sean Taylor wrote: On Wednesday, July 9, 2003, at 05:17 AM, Robert Simpson wrote: Santiago Gala, I haven't seen the Turbine localization service code, but maybe that could be separated out and used as the initial code for the Internationalization project (pretty much what I have done to date with it). Turbine might also provide some of the language translations A couple things I like about the code I've provided, is that it's pretty much a one-liner to include resources in a class or package, and that it's a static reference. Is the Turbine approach similar? Turbine Localization has been decoupled from Turbine and is now available in the Fulcrum subproject. Its not a static reference: String value = Localization.getString(key); or getString(locale, key); there are other variations, see http://jakarta.apache.org/turbine/fulcrum/apidocs/org/apache/fulcrum/ localization/package-summary.html The localization service can be accessed from within a Velocity tool, nice to look up a localized key named LOCALIZED_NAME from Velocity for ex $localization.LOCALIZED_NAME -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Rob, Some differences I see The commons-resources component does not include/encourage multilingual support as a goal. It simply abstracts the source for resources. I view the i18n code as being at a higher level than what's currently in commons-resources. The Factory's in i18n could be modified to make use of the different sources found in commons-resources. It may be necessary/useful to change some of the concrete object classes to interfaces, but those changes can come if/after it becomes a subproject. I had tried to see if I could make use of commons-resources within the code early this year, but it didn't solve the problem that I was trying to solve. Robert Simpson Rob Leland wrote: Robert Simpson wrote: Andrew, In one sentence, it intends to provide a framework for internationalization of Java projects, within the Apache/Jakarta projects themselves and for users of the Apache/Jakarta code outside Apache. I am sorry for jumping in late to this thread. How does this proposal differ from the commons-resources project in the commons-sandbox that provides for internationalization? It can load resources from a properties/XML or database ? I had started out trying to see where I could make use of the Jakarta code, and eliminate duplication of effort on my part. But the one thing I ran into was most of the Jakarta subprojects do not provide for internationalization, which is a shame, because the Java SDK does quite a good job of providing support for that. That might actually be a good thing, since there currently is the opportunity to provide a framework for doing it in one place, rather than having each subproject do it differently. Robert Simpson Andrew C. Oliver wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Santiago Gala, I haven't seen the Turbine localization service code, but maybe that could be separated out and used as the initial code for the Internationalization project (pretty much what I have done to date with it). Turbine might also provide some of the language translations A couple things I like about the code I've provided, is that it's pretty much a one-liner to include resources in a class or package, and that it's a static reference. Is the Turbine approach similar? As far a document and resource translation, I'm not sure if you are referring to machine translation, or human translation. My focus has been on human translation, mainly because machine translation is still pretty far from perfect. There could be APIs for interfaces to various machine translation tools, such as Systransoft, but I think that should be a later, secondary priority. Even if there was support for machine translation, I would prefer that it could be augmented by human proofreading and revision. So it's probably just as easy to let the language translator use whatever machine translation tool s/he prefers. As opposed to something that needs to be coordinated with each Apache project, the Internationalization subproject should simply provide a common means for Apache projects to provide for internationalization. However, because the language translations for an Apache subproject should probably be distributed with those other subprojects, the InternationalizationLibrary for those subprojects would be included with those subprojects themselves, not the i18n subproject. I think the relationship between the other subprojects and i18n should be loose and unidirectional. OTOH, the InternationalizationLibrary's included with i18n would be more general application- or industry-specific (security, accounting, medical, etc). Things that would get re-used fairly often. Robert Simpson Santiago Gala wrote: Robert Simpson escribió: I also fear that if I go back to simply continuing the development of the code myself, that eventually the need in Jakarta will be recognized, but I will be too far along at that point to convert everything to it. Or worse yet, the need will be recognized at different times within each Jakarta subproject, resulting in each subproject doing internationalization their own way. Jetspeed is already using i18n (or is it l10n?) for most of its strings. We use the Turbine 2.2 localization service for client specific ResourceBundles lookup and caching. I think Tomcat has also some effort already done. The main problem I see in your proposal is not coding it, but getting any/some/most of the jakarta projects to use the code, and agree in ways to handle the files back and forth as the development process progresses. Also, I think this is not a pure java issue, and looking at it from the whole Apache might help (as the web sites and the project documents would also need translation effort). I think a project which would take care of document and/or Resource bundle translation, coordinated with each Apache project requiring so would be a great thing in terms of infrastructure. I cc: community for insight, since there is much more in Apache than jakarta (even in the java world, there is a lot of XML people working in java) Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Andrew, In one sentence, it intends to provide a framework for internationalization of Java projects, within the Apache/Jakarta projects themselves and for users of the Apache/Jakarta code outside Apache. I had started out trying to see where I could make use of the Jakarta code, and eliminate duplication of effort on my part. But the one thing I ran into was most of the Jakarta subprojects do not provide for internationalization, which is a shame, because the Java SDK does quite a good job of providing support for that. That might actually be a good thing, since there currently is the opportunity to provide a framework for doing it in one place, rather than having each subproject do it differently. Robert Simpson Andrew C. Oliver wrote: From the proposal I was not able to determine *what it intends to do*.. Besides that, the criteria for helping is IMHO a bit discouraging. Granted its hard to help if you've never been outside of Kansas, but maybe Dorothy darn tootin cares about i18n and wants to make sure that toto can use her application... Perhaps there is something left for her to do even if she only speaks 'merican. -Andy On 7/5/03 12:16 AM, Tetsuya Kitahata [EMAIL PROTECTED] wrote: Hello, Robert, Personally, I am interested in this project, but I am not a *member* in ASF. (Just a *committer* in jakarta) How about posting your message to [EMAIL PROTECTED] ?? (subscribe: [EMAIL PROTECTED]) Maybe, you can find the ASF *member* outside of jakarta. Here's a list of the number of *committer* and *member* in ASF umbrella ( Originally created by Steven Noels) -- Amount of committers: 677 Name,committers,members ant,34,8 apr,42,32 avalon,80,15 cocoon,60,14 commons,10,10 db,35,9 embperl,13,6 httpd,145,111 incubator,26,12 jakarta,314,35 james,13,3 java,7,1 maven,25,4 mod_dtcl,9,4 modperl,18,7 tcl,9,4 ws,86,11 xml,259,28 -- There are only 35 potential Mentors (I mean, sponsors) in jakarta, as you can see. If you are confident you can build a powerful community, IMHO you do not have to stick to seek the Mentor in jakarta. I hope this mail might help you to some extent. Sincerely, -- Tetsuya ([EMAIL PROTECTED]) - On 3 Jul 2003 15:23:10 - (Subject: [i18n] Internationalization subproject sponsor?) Robert Simpson [EMAIL PROTECTED] wrote: To current members of the Jakarta project: Is there any current member of the Jakarta project who would be interested in sponsoring the entry of the Internationalization subproject into the incubator? The Internationalization subproject would be somewhat different than the other Jakarta projects in that there would be two types of contributors: 1. the (traditional) code contributors 2. the language translation contributors So far, the reponses I have received regarding people would would be interested in contributing have all been outside Jakarta - mostly language translators. Since the Internationalization subproject would most likely fit into the Jakarta project, it would help to have a sponsor from within Jakarta, per the Incubation Process documentation. The subproject proposal and initial code contribution can be found earlier in the Jakarta General mailing list, or here: http://www.itoolset.com/i18n/PROPOSAL.html Without a sponsor, I will probably move the code that was extracted in preparation for submission to Apache back into the iToolSet package hierarchy and let it pass as an Apache contribution until there is more interest in a common Internationalization architecture within Apache itself. Thanks in advance. Robert Simpson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [i18n] Internationalization subproject sponsor?
Tetsuya Kitahata, The Incubation Process document on the web site had indicated that the sponsor should come from the project that the incubating code would eventually be promoted into. Since trying to make use of Jakarta code is where I noticed the missing piece, that's the most obvious place it would go. I am surprised there isn't more interest in a common internationalization framework within Jakarta. But then I have been assuming that there are non-English-speaking members in Jakarta, not just committers and other users of the code. When the proposal was first submitted to the list, there seemed to be some initial interest - I even got some suggestions for improving the code and incorporated those into later revisions. But if there isn't much interest at this point, I fear it will be difficult to get it into Jakarta at a later time. I also fear that if I go back to simply continuing the development of the code myself, that eventually the need in Jakarta will be recognized, but I will be too far along at that point to convert everything to it. Or worse yet, the need will be recognized at different times within each Jakarta subproject, resulting in each subproject doing internationalization their own way. BTW, thanks for sending the test properties file in Japanese. I did incorporate that into the code, but just on my side so far. Robert Simpson Tetsuya Kitahata wrote: Hello, Robert, Personally, I am interested in this project, but I am not a *member* in ASF. (Just a *committer* in jakarta) How about posting your message to [EMAIL PROTECTED] ?? (subscribe: [EMAIL PROTECTED]) Maybe, you can find the ASF *member* outside of jakarta. Here's a list of the number of *committer* and *member* in ASF umbrella ( Originally created by Steven Noels) -- Amount of committers: 677 Name,committers,members ant,34,8 apr,42,32 avalon,80,15 cocoon,60,14 commons,10,10 db,35,9 embperl,13,6 httpd,145,111 incubator,26,12 jakarta,314,35 james,13,3 java,7,1 maven,25,4 mod_dtcl,9,4 modperl,18,7 tcl,9,4 ws,86,11 xml,259,28 -- There are only 35 potential Mentors (I mean, sponsors) in jakarta, as you can see. If you are confident you can build a powerful community, IMHO you do not have to stick to seek the Mentor in jakarta. I hope this mail might help you to some extent. Sincerely, -- Tetsuya ([EMAIL PROTECTED]) - On 3 Jul 2003 15:23:10 - (Subject: [i18n] Internationalization subproject sponsor?) Robert Simpson [EMAIL PROTECTED] wrote: To current members of the Jakarta project: Is there any current member of the Jakarta project who would be interested in sponsoring the entry of the Internationalization subproject into the incubator? The Internationalization subproject would be somewhat different than the other Jakarta projects in that there would be two types of contributors: 1. the (traditional) code contributors 2. the language translation contributors So far, the reponses I have received regarding people would would be interested in contributing have all been outside Jakarta - mostly language translators. Since the Internationalization subproject would most likely fit into the Jakarta project, it would help to have a sponsor from within Jakarta, per the Incubation Process documentation. The subproject proposal and initial code contribution can be found earlier in the Jakarta General mailing list, or here: http://www.itoolset.com/i18n/PROPOSAL.html Without a sponsor, I will probably move the code that was extracted in preparation for submission to Apache back into the iToolSet package hierarchy and let it pass as an Apache contribution until there is more interest in a common Internationalization architecture within Apache itself. Thanks in advance. Robert Simpson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] : [EMAIL PROTECTED] http://www.terra-intl.com/ (Apache Jakarta Translation, Japanese) http://jakarta.terra-intl.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Internationalization subproject sponsor?
To current members of the Jakarta project: Is there any current member of the Jakarta project who would be interested in sponsoring the entry of the Internationalization subproject into the incubator? The Internationalization subproject would be somewhat different than the other Jakarta projects in that there would be two types of contributors: 1. the (traditional) code contributors 2. the language translation contributors So far, the reponses I have received regarding people would would be interested in contributing have all been outside Jakarta - mostly language translators. Since the Internationalization subproject would most likely fit into the Jakarta project, it would help to have a sponsor from within Jakarta, per the Incubation Process documentation. The subproject proposal and initial code contribution can be found earlier in the Jakarta General mailing list, or here: http://www.itoolset.com/i18n/PROPOSAL.html Without a sponsor, I will probably move the code that was extracted in preparation for submission to Apache back into the iToolSet package hierarchy and let it pass as an Apache contribution until there is more interest in a common Internationalization architecture within Apache itself. Thanks in advance. Robert Simpson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][i18n] Internationalization subproject
for the examples, for three reasons: 1. The set of words, phrases, messages, etc for the Apache projects would not be the same as for the existing code. The Internationalization Libraries should be built based on the needs within the Apache code. Users of the Apache Internationalization subproject (including the developers of the initial code, following the eat your own cooking principle), would build upon the code and libraries downloaded from Apache. 2. The developers of the Apache Internationalization Libraries would be volunteers contributing specifically to the Apache effort, rather than developers targeting a specific subject area for other purposes (such as a company supporting their customers). However, outside contributions of Internationalization Libraries in general subject areas (such as science, legal, etc) that were not already addressed within Apache would be welcomed. For areas already addressed, extending the existing libraries for those subject areas would be the preferred approach. 3. The initial code has been converted for the purpose of making it more general and usable by a large target audience, in preparation for submission as an Apache subproject. However completion of the conversion to build internal code on top of the Apache Internationalization subproject would not make much sense until the subproject proposal has been accepted (in other words, we don't want to build too much internal code on top of a non-existent Apache project). 3) Required Jakarta Resources CVS Repository New directory i18n in the Jakarta CVS repository. Revise initial committers based on initial committers list (below). Mailing List Create mailing lists i18n-user and i18n-dev. Bugzilla New subproject i18n under the Jakarta project, with appropriate version identifiers as needed. 4) Initial Committers The initial committers on the Internationalization subproject shall be Robert Simpson and at least some of those who have expressed interest in the Commons Resources component (Craig McClanahan, Michael Schachter, Jason van Zyl, and Daniel Rall). (An e-mail would be sent to at least some of those additional committers to determine if they would still be willing to be committers for the internationalization subproject. They would be included in the committers list based on their agreement.) 4.5) Additional Contributors In addition to code contributors, this subproject would also be seeking persons who would be interested in contributing to the language translation effort. These persons should be natively fluent in a language other than English, and be able to read English as a second language. Any persons with such qualifications may contact the author of this proposal at [EMAIL PROTECTED] * 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL][i18n] Internationalization subproject
Proposal for Internationalization Subproject This is a proposal for creating an internationalization subproject under the Jakarta project. The intention of this submission to the Jakarta general list is to solicit comments on this version of the draft. An HTML version of this proposal can be found at http://iToolSet.com/i18n/PROPOSAL.html 0) Rationale One of the functions that is common to many applications, especially those that are accessed or distributed via the Internet, is the need to display prompts, messages, along with their replaceable parameters, and other text in the language preferred by the user. In the Java(TM)* SDK Exceptions classes, there are methods (getLocalizedMessage) which are intended for localization of exception messages, but those localization functions are left to the subclass implementations. Subclasses which provide the implementation need to be created. Certain prompts, messages or text may be common among various applications, while others may be unique to specific applications. Collections of localized resources can be created for both types, each stored in their own libraries. A common framework can be created to support internationalization of resources using these libraries. There currently is a Resources component in the Jakarta Commons sandbox. The intent is to provide a common interface for access to resources of various types. The functions provided by this component could be provided in a subpackage under the package created for the new internationalization component. These various efforts for providing functions that enable internationalization of applications should be combined into one place, to encourage interoperability between these various functions. 1) Scope of the Component The proposal defines a common framework for internationalization of Java resources. This internationalization typically occurs by localizing instances of these resources 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. The Internationalization subproject would consist of two major components: 1. the code component 2. a set of Internationalization libraries libraries for general application areas Some libraries, which would provide resources for certain general application areas, would be created as part of the Internationalization subproject. For example, localized resources related to common security functions (such as user instructions pertaining to user names and passwords) that could be used by various applications would be part of this subproject. application-specific libraries Additional libraries that would provide internationalization resources for specific applications could be created within the scope of those applications. For example, resources related to the ANT build tool would be created and stored as part of that Apache project. 1.5) Interaction With Other Subpackages and Components It is expected that other components and subpackages will make use of the internationalization component anywhere they need to provide for internationalization of resources, resulting in much heavier interaction inbound rather than outbound. 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/i18n/initsrc.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/i18n/docs/index.html;. 3) Required Jakarta Resources CVS Repository New directory i18n in the Jakarta CVS repository. Revise initial committers based on initial committers list (below). Mailing List Create mailing lists i18n-user and i18n-dev. Bugzilla New subproject i18n under the Jakarta project, with appropriate version identifiers as needed. 4) Initial Committers The initial committers on the Locale component shall be Robert Simpson
Re: [DISCUSSION] PROPOSAL for Jakarta Locale or Commons Locale
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 [EMAIL PROTECTED] 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
