IDPv3 internationalization via links and cookies

Brent Putman putmanb at georgetown.edu
Wed Nov 4 12:48:34 EST 2015



On 11/4/15 9:52 AM, Cantor, Scott wrote:
> On 11/4/15, 8:53 AM, "users on behalf of Simon Lundström" <users-bounces at shibboleth.net on behalf of simlu at su.se> wrote:
>
>
>
>> The import works alright, but changing locale via the QS parameter still
>> doesn't work.
> I would very surprised if it did, and I douubt that you can. For one thing, SWF will drop almost any query parameter at many places in the flow. It simply won't carry over to where it would need to be.

You probably know better than I what the behavior of SWF is here.  But
IIRC, the locale param doesn't need to persist across requests here. 
It just needs to be there once, on the initial inbound request, so it
is seen by that handler interceptor impl.  That "permanently" changes
the locale in effect (by calling the setLocale(...) method on the
LocaleResolver).  Once it processes it, the param can go away.

In fact, as a general web app thing, I personally wouldn't want the
locale param to have to appear on every subsequent request.  Don't want
it polluting my URL space.



>
> If you can use cookies, you don't need a query parameter. Just use Javascript from a link to set the cookie instead.

That probably works too, if one is specifically using the cookie locale
strategy.

I think the intent of the above MVC handler interceptor methodology is
to make the locale update "signal" independent of the underlying locale
strategy used. For example, they also have a Java Session-based
LocaleResolver, which I believe would work transparently with the
locale handler interceptor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151104/93cf33b5/attachment.html>


More information about the users mailing list