Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
From: Adrien Guillon <guila@dainty.ca>
Organization: Dainty Foods (a Division of MRRM Canada Inc.)
To: dev@cocoon.apache.org
Subject: [Proposal] i18n Transformer: Support Multiple Languages in One
 Document
Date: Mon, 17 Apr 2006 08:30:33 -0400
User-Agent: KMail/1.9.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604170830.33518.guila@dainty.ca>

   Hello All,

   The current implementation of the i18n transformer is able to output only a 
single language in <i18n:text> 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:  <i18n:text locale="en">Hello 
World</i18n:text>.

   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 <i18n:text> 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