User Context Locale

Is there a way to find the user context locale(in SessionObject) and use it in the templates? The sys_lang System field in the content type stores the specific locale. But, I need the locale stored in the session.
In other words, I would like to use the session locale variable in a template, which is rendered on a content item with different locale value stored in the sys_lang System field.

There’s no easy way to do this. I can think of a couple of hard ways, all of which involve taking the session id from $rx.session.getPSSessionID() and performing some internal Java hocus-pocus on it.

However, the real question is: why do you need to do this? When the site is published, the locale of the Publisher User is always the same. This won’t tell you anything about the selected locale of your site visitors.

Tell us more about what you are trying to accomplish.


I need to allow the users to preview the localized jsps. Users can view them after publish, but they want to preview it inside the CMS. Ofcourse, i can publish them to a development box before the final publish. But, the ideal solution would be to preview the localized items inside the CMS.
So, I was trying to extract the user context locale to assemble the correct template, so that the users can preview the localized pieces inside the CMS.
Would appreciate if you provide an alternate solution.

In a JSP page that runs under the Rhythmyx App Context (e.g. inside rxapp.war/user/pages), you can access the Locale from the IPSRequestContext.

<%IPSRequestContext ipsreq  = (IPSRequestContext)request.getAttribute("RX_REQUEST_CONTEXT");%>
My locale is: <%=ipsreq.getSessionPrivateObject("sys_lang")%>

It’s also possible to use similar techniques to modify the “Preview” Action, but if you’re going to use a JSP page, this way is simpler.

I’ve attached the complete page (zipped, because the forum doesn’t recognized JSP attachments).


Thank you Dave for the jsp solution in rxapp.
I am looking forward for a solution where the preview of the content item will pick the locale in user session object and render the page in the preview window. Please let me know how I can use it in the Preview action.

To do this in preview, you have to change the Preview resources in rxs_cxSupport. There are 2 of them (both named “variantList”, the only difference between them is how they handle communities).

In the mapper, you will see an entry for “sys_MakeAbsLink”. This is what generates the preview URL. In the first empty parameter fill in a name (e.g. “user_lang”) and a value of PSXUserContext/User/SessionObject/sys_lang. (Note that you have to follow the menu here, you cannot just type the value).

Once you do this, the parameter you added (“user_lang”) will be available in the template as $sys.params.user_lang. Of course, it’s a “String Array” just as all of the other params are.

If you’re familiar with 5.7, the XML Server view will seem very familiar, it’s just like the old Workbench. If you’re not a 5.7 veteran, it can be somewhat difficult to navigate. Just be thankful that you don’t have to use it every day.


Thank you for the Preview Action solution.
Now I have user_lang added to the $sys.params, which provides me the locale stored in the user session.
But, I have the following problem:
The preview page has links to other pages generated using $rx.location.generate(Item/AssemblyItem). Clicks to these links take me to pages where I lose “user_lang”.
I can think of few solutions like:

  1. After $pagelink=$rx.location.generate(Item/AssemblyItem)
    use $"$pagelink",“user_lang”,"$locale")) to add the parameter. May be create a velocity macro.
  2. Create another extension to add the user_lang to the url.

Both, these solutions demand a change in all my snippet templates, where $rx.location.generate is used to generate the link.
Is there any other way so that user_lang is added to $sys.params at one place, and all subsequent calls to $rx.location.generate in different snippets are taken care?

What you’re really asking for is a solution like the one I alluded to in a previous post:

There’s no way that I can find to do this with the purely public API. We’ll have to discuss internally what the safest way to expose this is.