Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 97902 invoked from network); 17 Apr 2006 14:48:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Apr 2006 14:48:05 -0000 Received: (qmail 29918 invoked by uid 500); 17 Apr 2006 14:47:54 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 29789 invoked by uid 500); 17 Apr 2006 14:47:54 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 29745 invoked by uid 99); 17 Apr 2006 14:47:53 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Apr 2006 07:47:53 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [216.191.214.243] (HELO mailwn.dainty.ca) (216.191.214.243) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Apr 2006 07:47:53 -0700 Received: from gentoo-server (gentoo-server.dainty.ca [192.168.202.201]) by mailwn.dainty.ca (8.12.9/8.12.9) with ESMTP id k3HEVbGi031119 for ; Mon, 17 Apr 2006 10:31:37 -0400 Received: from testip.dainty.ca (testip.dainty.ca [192.168.202.160]) by gentoo-server (8.12.11/8.12.11) with ESMTP id k3HElXkw012319 for ; Mon, 17 Apr 2006 10:47:34 -0400 From: Adrien Guillon Organization: Dainty Foods (a Division of MRRM Canada Inc.) To: dev@cocoon.apache.org Subject: Re: [Proposal] i18n Transformer: Support Multiple Languages in One Document Date: Mon, 17 Apr 2006 10:48:07 -0400 User-Agent: KMail/1.9.1 References: <200604170830.33518.guila@dainty.ca> <44439173.5020001@gmx.de> In-Reply-To: <44439173.5020001@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200604171048.07981.guila@dainty.ca> X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on mailwn X-Virus-Status: Clean X-Scanned-By: milter-spamc/1.6.369 (mailwn [192.168.202.11]); Mon, 17 Apr 2006 10:31:38 -0400 X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: NO, hits=1.60 required=5.00 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I know I can write an i18n Transformer in XSLT faster than I can modify the= =20 Java Code. Is this how we want to go? I don't want to make something just for my applications, when I can contrib= ute=20 the solution to the community. I feel we can make the change to an XSLT=20 implementation of the transformer fairly transparent. Basically, just chang= e=20 the definition of the transformer in the sitemap... mark the existing Java= =20 Code as deprecated for the next release, and provide an alternative=20 definition for the transformer in XSLT. Alternatively we can take the=20 existing Java class, and make it a wrapper for a new XSLT implementation as= =20 an upgrade pathway. XSLT will be more extensible for site-specific configurations, and more= =20 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=F6rg