Feel free to submit a patch. It would certainly be considered. It would
be helpful if you could also run some basic benchmarks to compare the
two implementations.
Ralph
Adrien Guillon wrote:
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
