Well, one question is: which standard? There are plenty we could use... It sounds like in this case we're using basically the same cheap-ish method to internationalize that other Apache projects are using, so from one perspective, Xalan is just fine as it is.
On the other hand, I18N is a thing that can tend to get short shrift in the design space for open source projects, and Sun probably does have some good guidelines for useful and extendible ways to do it. For the short term, I'm not sure what to do, other than hope the Sun JDK integration team can find their own way (hopefully low risk) to modify their own version of the code. Long term, this is a Xalan community issue to decide 1) how much extra effort we want to put into customizing our software to better fit Sun's model (which is probably a more organized one than we have anyway for I18N), and 2) finding the resources/volunteers to do the work without destabilizing us or messing up existing user's translations. ---- you <[EMAIL PROTECTED]> wrote ---- > Bugid: 4452624 was filed at Sun against the version of Xalan that is built into > JDK1.4 (Merlin) saying the xalan and xpath packages don't follow standard > internationalization. I'd like to get some feedback on whether this > is a real problem in Xalan that needs to be resolved. > [Here's Costin's evaluation] > Xalan is an Apache-developed product. This "style" for messages has been around > for at least 2 years, and is used extensively in most xml.apache.org sources. > Changing it ( on Apache ) is very unlikely - it is a very big change and it'll > affect other's people translations. The only solution would be to fork it and > change our local copy - but that would make it very hard/impossible to integrate > future versions of xalan. Note that the same style is used in apache-xerces and > other xml apache projects. > > The workaround is to translate the ErrorResources.java files. It would be possible to \ > "hack" it so it redirects to a properties file, but again I don't think it would be > possible to put it back on apache.ErrorResource extends ListResourceBundle. > > Regarding the Makefile - this will be fixed in the next integration ( by replacing \ > NEW_RESOURCE_BUNDLES_PROPERTIES with ..._JAVA ), but changing the > xalan message handling - I don't think it can be fixed ( at least in > this version ) (Thanks to Costin for the good overview!) Note also that the makefiles they're talking about are Sun-internal, and Apache does not appear to have access for them - so discussions about that are a Sun matter. This is still an exciting and ever changing frontier - Sun redistributing external Java code as part of the JDK. Very nice in some ways, a bit of a bumpy process in others. ===== - Shane <eof aka="mailto:[EMAIL PROTECTED]"; .sig="Du sublime au ridicule il n'y a qu'un pas." /> __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/
