I think I am -0 on this name change.
There are Java APIs which deal with resource.properties and will automatically find the correct localized version of the property file. The property file is qualified with a package name, so it is unique and 'standard'. Could we have a bit more of the justification for this change? Why does axis need a unique filename? This has a ripple effect on our products and our i18n and l10n. -- Tom Jordahl Macromedia -----Original Message----- From: Richard Sitze [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 3:08 PM To: [EMAIL PROTECTED] Subject: RE: [axis] finding NLS (National Language Support) properties That could be an interesting discussion. More importantly, there are standards, specific to different corporate entities, regarding content and format of NLS (National Language Support) messages. IBM's rules are going to be different than other corporate entities. So, IBM will be investing effort into making the current AXIS NLS properties file adhere to the IBM required standards for US English, and our translation efforts will be based on that foundation, not the axisNLS.properties file in it's current form. It's not clear how much 'value' that will have to the AXIS community unless the community were to adopt IBM standards. Being good open-source citizens, we don't want to dictate that. On the other hand, we would like a way to override the current axisNLS.properties file. An overall goal is to allow that override to occur without mangling the AXIS build (hence all the hook points Russell and Rich are so interested in, in other areas of AXIS). That is the basis of the change (and I'm open to a better name, if anyone has a suggestion). axisNLS could be debated, but it is an accurate reflection of what it "is". My current thought is to do something similar to what is going on with the configuration file: override the class loader to use the thread-context class loader, call getBundle("axisNLS"), and see if it finds an axisNLS.properties file in the classpath (no package). Failing that, reset the class loader to the "class's class loader", which prepends the package name, and see if a second call to getBundle will find "org.apache.axis.utils.axisNLS.properties". It's not clear if this will work (or what will break in other environments), but that's the experiment I'm going to be trying. Comments/feedback before I commit to anything? <ras> ******************************************* Richard A. Sitze [EMAIL PROTECTED] CORBA Interoperability & WebServices IBM WebSphere Development Glen Daniels <gdaniels@macrom To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> edia.com> cc: Subject: RE: cvs commit: xml-axis/java build.xml 05/22/2002 01:41 PM Please respond to axis-dev I don't recall seeing discussion on this, and I don't honestly know what "NLS" means (non-local strings?). I don't think I'd have voted for that name, myself. This affects everyone's internationalized versions, so I'd really prefer this had been discussed first. Incidentally, does it make sense for our various companies to share the translated versions and check them in? I.e. Macromedia can contribute French + Japanese, IBM can contribute German + Spanish, etc....? --Glen > -----Original Message----- > From: Richard Sitze [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 22, 2002 2:06 PM > To: [EMAIL PROTECTED] > Subject: RE: cvs commit: xml-axis/java build.xml > > > We are sorting through some issues related to NLS properties files. A > property file name that was more specific to AXIS was a > recuring theme, and > since that seems to be a fairly harmless change, I just charged ahead. > > Consider my hand slapped, if it needs to be. > <ras> > > ******************************************* > Richard A. Sitze [EMAIL PROTECTED] > CORBA Interoperability & WebServices > IBM WebSphere Development > > > > > Glen Daniels > > <gdaniels@macrom To: > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > edia.com> cc: > > Subject: RE: > cvs commit: xml-axis/java build.xml > 05/22/2002 12:29 > > PM > > Please respond > > to axis-dev > > > > > > > > > > > I ask again - what's this about? Was this discussed? > > --G > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, May 22, 2002 1:22 PM > > To: [EMAIL PROTECTED] > > Subject: cvs commit: xml-axis/java build.xml > > > > > > rsitze 02/05/22 10:22:24 > > > > Modified: java build.xml > > Log: > > rename of resources.properties to axis.nls.properties > > > > Revision Changes Path > > 1.135 +4 -3 xml-axis/java/build.xml > > > > Index: build.xml > > > =================================================================== > > RCS file: /home/cvs/xml-axis/java/build.xml,v > > retrieving revision 1.134 > > retrieving revision 1.135 > > diff -u -r1.134 -r1.135 > > --- build.xml 21 May 2002 13:20:36 -0000 1.134 > > +++ build.xml 22 May 2002 17:22:24 -0000 1.135 > > @@ -112,6 +112,7 @@ > > <pathelement location="${regexp.jar}"/> > > <pathelement location="${junit.jar}"/> > > <pathelement location="${excalibur.jar}"/> > > + <pathelement location="${j2ee.jar}"/> > > <pathelement location="${java.home}/../lib/tools.jar"/> > > <fileset dir="lib"> > > <include name="*.jar"/> > > @@ -269,15 +270,15 @@ > > toDir="${build.dest}/org/apache/axis/client"/> > > <copy file="${src.dir}/log4j.properties" > > toDir="${build.dest}"/> > > - <copy > > file="${src.dir}/org/apache/axis/utils/resources.properties" > > + <copy > > file="${src.dir}/org/apache/axis/utils/axis.nls.properties" > > toDir="${build.dest}/org/apache/axis/utils"/> > > > > <tstamp> > > <format property="build.time" pattern="MMM dd, yyyy > > (hh:mm:ss z)"/> > > </tstamp> > > - <replace > > file="${build.dest}/org/apache/axis/utils/resources.properties" > > + <replace > > file="${build.dest}/org/apache/axis/utils/axis.nls.properties" > > token="#today#" value="${build.time}"/> > > - <replace > > file="${build.dest}/org/apache/axis/utils/resources.properties" > > + <replace > > file="${build.dest}/org/apache/axis/utils/axis.nls.properties" > > token="#axisVersion#" value="${axis.version}"/> > > > > <jar jarfile="${build.lib}/${name}.jar" > > basedir="${build.dest}" > > > > > > > > > > > >
