And even closing/reopening the browser doesn't completely fix it.

Sadly, browser caching does not completely explain the reported behavior. I
enabled Struts' no-caching support via the following XML snippet in
struts-config.xml:

<controller 
   processorClass="com.redhat.rhn.frontend.struts.RhnRequestProcessor"
   nocache="true" />

And verified that the appropriate headers were being sent to the browser. This
cleared up a few minor instances of wrongly cached content. This didn't fix the
bulk of the problem.

After more digging I've unearthed a multi-layer problem which will take a bit to
fix correctly. Here are the issues I know about:

1) We are using the <%@ include %> directive to include our html fragment files. 
This directive is meant for static content and has caching and other
persistence-related problems when used with dynamic content
(http://www-128.ibm.com/developerworks/java/library/j-jsp04293.html). The
<jsp:include> tag should be used since it is more compatible with dynamic content.

2) Fragment files end in .jspf.
By default the jsp servlet is mapped to *.jsp and *.jspx. Once I addressed #1
and converted the user locale preferences page to use <jsp:include> I had
problems getting the include fragment to execute, ie I was seeing raw,
unexecuted jsp tags in the browser (<c:out>, <c:if>, etc). I was able to fix
that by adding the following servlet mappings to web.xml:

  <servlet-mapping>
    <servlet-name>jsp</servlet-name>
    <url-pattern>*.jsp</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>jsp</servlet-name>
    <url-pattern>*.jspx</url-pattern>
  </servlet-mapping>
  
  <servlet-mapping>
    <servlet-name>jsp</servlet-name>
    <url-pattern>*.jspf</url-pattern>
  </servlet-mapping>

3) Fragment files do not contain necessary taglib declarations
In fixing #2 I discovered that some custom tags were not executing. Further
digging revealed that most of our jsp fragments do not include necessary taglib
declarations, instead relying on the including page to declare the necessary tags.

After addressing all the above issues for the user locale preferences page I am
still not seeing localized text change uniformly when the user's locale changes.
My current suspicion is that something in our templating mechanism is getting in
the way. My investigation continues. 

Discovered the actual cause of the problem this morning. Struts' MessageResource
class caches, IMHO very very incorrectly, the first value resolved for a given
localized string. Subsequent calls return the cached value instead of performing
the lookup again. This ultimately has the effect of resolving only one
translation per localized string -- meaning that a string can be resolved to
only one language, period.

I was able to workaround this behavior by clearing MessageResource's cache in
each call to getMessage(). I've verified that this fix works without the fixes
noted in my previous update. I still feel that the above items are things which
should be addressed, but since they are not required to fix the actual problem
reported I will leave them out of the committed fix.

Test Plan:

1) Login to RHN

2) Click the Locale Preferences selection

3) Select a locale and save

Expected Result: The entire locale preferences page should render in the new
language.

Verified.  I moved locales all over the place, changed the browser locale, etc.
 Looks good.

closing -- currentrelease