cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Using I18NTransformer with Dynamic Locales
Date Wed, 15 Feb 2012 18:36:04 GMT
Hash: SHA1


On 12/2/11 4:04 PM, Cédric Damioli wrote:
> Le 01/12/2011 17:49, Christopher Schultz a écrit :
>> All,
>> I'd like to start using the I18NTransformer so I can localize
>> the output of my XSLTs. We have what I believe to be a somewhat
>> unique situation with regard to the actual source of the locale
>> information.
>> Here goes:
>> We have Cocoon set up as a webapp all by itself, separate from
>> our "real" webapp. Our pipelines take incoming HTTP requests and 
>> essentially forward them, with modifications of course, to our
>> "real" webapp that produces XML for consumption by Cocoon. The
>> Cocoon webapp does not maintain session state of any kind: it
>> merely forwards requested session ids from the incoming request
>> through the outgoing request to the "real" webapp.
>> The "real" webapp knows what the user's preferred Locale is, and
>> can provide that information back to Cocoon if necessary. We have
>> lots of options: HTTP response headers, something in the XML
>> document returned, etc.
>> Unfortunately, I'm not sure how to get any of those data when
>> calling the I18N transformer itself.
>> Can anyone offer any suggestions?
>> If I can't come up with anything else, I'll have to encode the
>> locale in each request's URL which, while doable, will likely be
>> fragile and a total PITA to actually accomplish.
>> Thanks, -chris
> The locale of the I18nTransformer may be set a sitemap parameter : 
> <map:transform type="i18n> <map:parameter name="locale"
> value="XXXX"/> </map:transform>
> In this cas, the actual locale value may be computed in a
> surrounding action :
> <map:act type="proxy"> <map:generate/> <map:transform type="i18n> 
> <map:parameter name="locale" value="{locale}"/> </map:transform> 
> <map:serialize/> </map:act>
> where the "proxy" action actually proxy the request to your "real"
>  webapp, get the responses header you mentionned and put it in the 
> result map.

I've considered this approach and I definitely think it will work.
However, I'm wondering if I can avoid another round-trip to the
original server that is producing the XML document currently being

I can alter this XML document to contain the locale itself if that's
any help. Is there a way to extract a piece of information from the
event stream and use *that* as a variable for the pipeline?

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message