Re: Using I18NTransformer with Dynamic Locales
-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=/ /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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Using I18NTransformer with Dynamic Locales
Hi Christopher,
The locale of the I18nTransformer may be set a sitemap parameter :
map:transform type=i18n
map:parameter name=locale value=/
/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.
Regards,
Cédric
Le 01/12/2011 17:49, Christopher Schultz a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7XsBIACgkQ9CaO5/Lv0PBAxwCdER3GqI5TLETkSIeRzstvFcYn
nAkAoJ+5dPRr0zymd6dMez9pm4we4JJS
=GlJl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Using I18NTransformer with Dynamic Locales
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7XsBIACgkQ9CaO5/Lv0PBAxwCdER3GqI5TLETkSIeRzstvFcYn nAkAoJ+5dPRr0zymd6dMez9pm4we4JJS =GlJl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
