i18n transformer future plans?

[Peter Royal <pr...@managingpartners.com>]

kudo's to all towards the 2.0 release. you're one step closer now :)

we finally sync'd up to the latest of the 2.0 branch today, getting the new 
XMLResourceBundle based i18nTransformer. There are some improvements I'm 
going to be making immediately for our use here, and I'd like to 
co-ordinate with other users.

1) Support for multiple catalogs. Right now each defined instance of the 
transformer is tied to a single catalog. I am going to modify the 
transformer to allow for the selection of a catalog name as a sitemap 
parameter, with a constraint of all catalogs being inside of the defined 
catalog directory

2) Making the transformer Cacheable. I don't see any reason at the moment 
for it to not be Cacheable, as it appears that once a catalog is parsed as 
a Document, no further checks are done to see if it has changed. Naturally 
the CacheValidity would be based upon the requested locale.

3) Support for having keys with no translation "fall-through". Right now if 
a given translation element is not found, the enclosed value, or the 
defined untranslated text are substituted. I need to have the original 
i18n-namespaced elements returned. We have found is very cumbersome here to 
have all translation entries for our entire webapp in a single document, 
aside from the fact that we have had many duplicate entries based on how I 
had structured my keyspace. I was planning on breaking it up into multiple 
catalogs for easier maintenance, and so if a translation is not found in a 
more specific catalog, near the end of my translation pipeline would be a 
catalog with many generic terms.

I'm going to start hacking right away, and when I'm done I'll send patches 
against the current CVS version. As it stands, the HEAD and 2.0 branch have 
identical copies of the i18nTransformer. Any input/suggestions/critiques 
are welcome.
-pete

-- 
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org