I prefer XSLT... I believe it is much more maintainable if done properly...
especially with XSLT and XPath 2.0.
I wound up creating my own translation engine in XSLT 2.0, and it works quite
well. It only took a couple of hours, whereas the Java code was a mess to
trace through...
AJ
On 9 Jun
Peter Hunsberger wrote:
On 4/17/06, Adrien Guillon <[EMAIL PROTECTED]> wrote:
XSLT will be more extensible for site-specific configurations, and more
maintainable than the existing Java code.
I don't see that you'd necessarily have to mark the existing
implementation deprecated. Having the
On 4/17/06, Adrien Guillon <[EMAIL PROTECTED]> 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
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
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 transf
On 17.04.2006 14:30, Adrien Guillon wrote:
2) Why use Java at all? Would we take that much of a performance hit if
we used straight XSLT? We could just aggregate the language packs and use a
stylesheet to process the i18n text nodes and substitute them. A large
dictionary would be a per
Hello All,
The current implementation of the i18n transformer is able to output only a
single language in tags. In the majority of cases this is what
is desired, however I need to be able to output multiple languages in a
single document. I'd like to extend the i18n text tag to be capa
