Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document
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 June 2006 3:50 pm, Vadim Gritsenko wrote: > 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 two different versions as > > configurable options might make sense, in particular if there is much > > of a performance difference. Even if there is not, some people may > > not feel that XSLT is "more maintainable" than the existing Java > > code > > I can even give some examples of that... > > Sitemap XSLT vs TreeProcessor: Java was considered more maintainable than > XSLT. XSP vs JXTemplate: Ditto. > > Vadim
Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document
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 two different versions as configurable options might make sense, in particular if there is much of a performance difference. Even if there is not, some people may not feel that XSLT is "more maintainable" than the existing Java code I can even give some examples of that... Sitemap XSLT vs TreeProcessor: Java was considered more maintainable than XSLT. XSP vs JXTemplate: Ditto. Vadim
Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document
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 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. > I don't see that you'd necessarily have to mark the existing implementation deprecated. Having the two different versions as configurable options might make sense, in particular if there is much of a performance difference. Even if there is not, some people may not feel that XSLT is "more maintainable" than the existing Java code -- Peter Hunsberger
Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document
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
Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document
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
Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document
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 performance hit, unless we had some way to keep the XSLT stylesheet and parsed XML document resident in memory for whenever it's needed. 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
[Proposal] i18n Transformer: Support Multiple Languages in One Document
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 capable of
overriding its locale. Example: Hello
World.
This way, even if the default language parameter in the transformer was
'fr', I can represent certain elements in 'en'. This case especially applies
to Canada, where many printed forms must be in both English and French (and
this is basically what I need to do).
I spent my weekend tracing through the source code of the i18n transformer.
Two thoughts arise:
1) Indeed we can extend the source to support multiple languages.
Basically, we could include a Map of locales used, with a simple data
structure like:
class LocalePack { public Locale locale; public CatalogueInfo catalogue; }
This way we can load new language packs into the Map structure as we
encounter them in nodes.
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 performance hit, unless we had some way to keep the
XSLT stylesheet and parsed XML document resident in memory for whenever it's
needed.
Thoughts?
AJ
