I know I can write an i18n Transformer in XSLT faster than I can modify the Java Code. Is this how we want to go?
I don't want to make something just for my applications, when I can contribute the solution to the community. I feel we can make the change to an XSLT implementation of the transformer fairly transparent. Basically, just change the definition of the transformer in the sitemap... mark the existing Java Code as deprecated for the next release, and provide an alternative definition for the transformer in XSLT. Alternatively we can take the existing Java class, and make it a wrapper for a new XSLT implementation as an upgrade pathway. XSLT will be more extensible for site-specific configurations, and more maintainable than the existing Java code. AJ On 17 April 2006 9:00 am, Joerg Heinicke wrote: > > That's what we actually had in a former project, an XSLT-based i18n > transformer. It was much more flexible, but I don't know any numbers > about performance. But if caching is applied appropriately, it should > not be that bad. > > Our solution had catalogue aggregation based on a pipeline (additional > flexibility, part one: you can aggregate arbitrary catalogues, not just > by locale). And the texts could be translated recursively (additionale > flexibility, part two) by applying the templates to i18n tags in the > catalogues. > > Regards, > > Jörg
