cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document
Date Mon, 17 Apr 2006 16:30:06 GMT
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.


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

View raw message