<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/4/15 9:52 AM, Cantor, Scott
      wrote:<br>
    </div>
    <blockquote cite="mid:8BB18B6B-1E96-4298-A7E4-5DA42976F39F@osu.edu"
      type="cite">
      <pre wrap="">On 11/4/15, 8:53 AM, "users on behalf of Simon Lundström" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofsimlu@su.se"><users-bounces@shibboleth.net on behalf of simlu@su.se></a> wrote:



</pre>
      <blockquote type="cite">
        <pre wrap="">The import works alright, but changing locale via the QS parameter still
doesn't work.
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
    <br>
    <blockquote cite="mid:8BB18B6B-1E96-4298-A7E4-5DA42976F39F@osu.edu"
      type="cite">
      <pre wrap="">

If you can use cookies, you don't need a query parameter. Just use Javascript from a link to set the cookie instead.</pre>
    </blockquote>
    <br>
    That probably works too, if one is specifically using the cookie
    locale strategy.<br>
    <br>
    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.<br>
  </body>
</html>