Re: Using I18NTransformer with Dynamic Locales

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cédric,

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
processed.

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?

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk87+xQACgkQ9CaO5/Lv0PB9RACeJbi86fHX4xA2HyYipOcnBxtk
ohoAn0+btE5WUBwcW7E8LXVUi4DdST3T
=Pnci
-----END PGP SIGNATURE-----

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