How to switch language without having to log off and re-log in
My application is bi-lingual (English and Dutch). If I change locale in my operator record from en_NL to nl_NL, and log off and re-log in then all texts are properly translated. Now, for the requirement mentioned in subject line, I'm writing an activity which has the following java code :
oLog.infoForced("Exception thrown while trying to change locale: "+t.toString());
} Where ‘LangCode’ is a local variable which at runtime will be either EN or NL.
On execution of this activity, I see only STANDARD thread's pxSecuritySnapshot.pxUserRulesetLocalized is being updated with all the '_nl' rulesets. But all other threads remain unchanged. As a result, only few texts in designer studio are being translated, but not my user portal. (Even in designer studio, other tabs (if any is opened) are not translated)
If anyone has implemented this before, kindly let me know the solution.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
I would recommend looking at the OOTB activity UpdateLocaleSettings - it has exactly code you need.
After you call this activity you need to refresh the portal using generic window.location.reload script.
Pay attention to this in the documentation:
Localization operates completely only for users who have WorkManager, WorkUser, Manager, or User portal rules (or similar portal rules) as the Default Portal Layout on the Settings tab of the access group instance. Localization is not complete if you use the Designer Studio as Default Portal Layout and later open a second portal that uses the WorkManager or WorkUser portal rule.
So if you want to test it on user portal while logged in as administrator this will not work.
Also - this seemed not working in IE when using URL and onclick events. It works in dropdowns, icons and buttons.
Hope this helps. If you have any questions let me know. We just worked on it few weeks ago and made it work.
The code I posted here, that is exactly what OOTB activity UpdateLocaleSettings does. I also tried using this OOTB activity itself directly.
But the frustrating observations are:
1. From end user portal, on execution of my activity (or the OOTB one), no texts are translated. Only date formats are changed. Clipboard shows the securitysnapshot page has not been updated with the localized rulesets.
2. From designer studio, on executing the same activity (either manually, or by opening a secondary portal and clicking on link/button) and refreshing the window, the home page gets changed. But any new tab opened are once again in previous language. Clipboard shows only STANDARD thread's security snapshot page is being updated with '_nl' (for Dutch) rulesets, but not other threads.
I tried to test the 'locale settings' wizard from user portal by playing with the url [../PRServlet?pyActivity= Code-Pega-Requestor.UpdateLocaleSettings&useLocale=nl]. Even then the observation is same: in case of user portal - no texts are translated, only date format changes; and in case of designer studio - only home page gets translated, not other tabs.
I have already opened a SR, lets see how that goes..
Krithigassree, Samya has already checked the post you refer to. However, as it is internal post he does not have access to it. As for going to browser setting and changing the language there it is not an optimal solution and definitely not user friendly. Being a lazy Internet user as I am - I prefer to just click on the link/icon/button etc on the website that do so many clicks to change the language for just one website.
There are several reasons why updating the locale of the browser and relying on the locale of the browser is not a good approach.
If its a customer web self service solution you don't want to be having to explain to the general public how to make changes to the system. If you're on a Mac, if on a Windows, if using Chrome, if using IE, if using Firefox, if using an iPhone - the burden should not shift to the end user to make life a little easier for the developer
reading the browser locale and 'assuming' its correct is a risky proposition. Many versions of Chrome in the UK are downloaded from Google.com, not Google.co.uk which means they get US English as the defualt locale. That in no way means I'm an American user and I want date formats in MM/DD/YYYY.
Browser locale also does not equal what I'm working on. Swapping GBP for USD beacuse my locale is EN_us in my browser isn't a good idea for financial institutions.
I traced the ootb UpdateLocaleSettings and found 'nl' is being passed for Dutch. Still I have tried with everything: 'nl', 'NL' and 'nl_NL'. Nothing worked.
There is a story behind the language package being used. It turns out that the language package was imported when all applications were running in PRPC 6.X version. Later client upgraded to 7.1.7, but the language package still remained the same. Latest development of the SR is Abhijit Sarkar (the person from pega who is looking into the SR) has tried out my code with latest language package in his environment and that worked [even on Designer studio, which pega help says wont work]. So, now we're planning to import the latest version of Dutch language package and see if that helps.
Latest development of the SR is Abhijit Sarkar (the person from pega who is looking into the SR) has tried out my code with latest language package in his environment and that worked [even on Designer studio, which pega help says wont work]. So, now we're planning to import the latest version of Dutch language package and see if that helps.
Be aware, UpdateLocaleSettings will update settings for current user session only : if you switch portal or application locale settings come back to default value.
Thus, calling window.location.reload after OOTB activity UpdateLocaleSettings might not work ( it did not for me). Instead, you could use a Run script action pega.desktop.activateDocument to reload default portal page
This SR has been resolved. Problem was a certain prconfig setting, which was not allowing the api 'setLocale' to update the ruleset stack. After changing the value of "Authorization/RSLUpdateBehavior" from 'fixedreq' to 'immediate', our code started working as expected.