IMHO, internationalization is best done on the tail-end rather than up front. This is a little bit backwards compared to how you're probably used to doing it.
My approach would be to scatter xml elements like <message key="foo"/> throughout your base XML and XSLT transforms, making sure that they pass unmolested to the last transform. The last transform would be a simple stylesheet that included the identity transform and a bunch of templates that look like this: <xsl:template match="message[@key='foo']">The Foo Message</xsl:template> <xsl:template match="message[@key='bar']">The Bar Message</xsl:template> Assuming you have a framework that allows multiple XSLT transforms to be chained together using SAX events, this should actually be quite efficient. About a year ago a friend and I wanted an MVC framework that allowed us to work with XSL. Struts was very tightly coupled to JSP at the time (and arguably still is), so we wrote our own. It is very similar to Struts in many ways, but it is designed around building what the JavaWorld article calls "Model 2X". Like Struts, Maverick (our framework) offers an XML sitemap configuration, but unlike Struts: * Each view can have multiple, iterative transformations * You can halt the transformation process at any step and obtain static XML that designers can work with offline. * JavaBeans are automatically "domified" with an adapter that uses Java reflection to provide a lazily-loaded DOM façade. No need to ever generate or parse text XML. * Designed from the start to be template-language agnostic; you can seamlessly mix and match XSLT, JSP, Velocity, or other views. * View and transform types are pluggable. Not only can you use XSLT transforms, but also DVSL transforms and "document" transforms that let you use JSP or Velocity to simply wrap the content of previous steps. * Framework will automatically pick from multiple views based on Accept-Language or any other request characteristic, automating internationalization, browser customization, etc. * Actions (called Controllers in Maverick) can work either like Struts Actions (which are singletons) or like WebWork Actions (which are instantiated, used, and thrown away on every request). I'm not just writing this to publicize a competing framework (http://mav.sourceforge.net :-). I am beginning to wonder if maybe there is some potential to merge it with the Struts codebase. It sounds like Struts is being decoupled from JSP and generally moving in the direction of a view-agnostic MVC framework. If a year ago I had suggested making changes to the Struts config file format to accommodate XSL, I think I would have been booed, but I'm not so sure anymore. Any thoughts? Anyone familiar with the Struts config file would probably be amused by seeing the Maverick equivalent. Here is what a Maverick config file looks like for an XSL app (a simple contact-list manager): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/opt-domify/examples/f riendbook-domify/WEB-INF/maverick.xml?rev=1.4&content-type=text/vnd.view cvs-markup Here is the exact same app (uses the same Controller aka Action classes) using JSP (with the JSTL ea3 taglib): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/examples/fri endbook-jsp/WEB-INF/maverick.xml?rev=1.5&content-type=text/vnd.viewcvs-m arkup Here is the exact same app using Velocity: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/opt-velocity/examples /friendbook-velocity/WEB-INF/maverick.xml?rev=1.2&content-type=text/vnd. viewcvs-markup And here is a simple config file which shows using the internationalization feature: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/examples/shu nting-jsp/WEB-INF/maverick.xml?rev=1.3&content-type=text/vnd.viewcvs-mar kup Perhaps there merging the two projects is worth investigating? Jeff Schnitzer [EMAIL PROTECTED] Maverick: http://mav.sourceforge.net >-----Original Message----- >From: Chappell, Simon P > >1. I18N. Agreed. This is a problem. Having gotten used to I18N >in my apps, I really have no desire to give it up. According >to the book XSLT (by Doug Tidwell, Pub: O'Reilly, Aug 2001) it >is possible to extend XSL/XSLT with Java extensions. Could we >brave souls not write an XSL/XSLT extension to give us the >I18N that we get in struts-powered JSPs? On the other hand, as >I re-read this before I hit send, the XSL/XSLT only process >the XML that it's given. It's up to what ever generates the >XML to perform the I18N. With a struts/XSL/XSLT mix, who's >responsibility would it be to provide I18N? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
