As the platform has been growing over the years, the use-cases have massively expanded. For example, when I started my SN journey way back when, we only needed to consider purely internal employee scenarios and so the expectation of an end-user needing to change their session language was so rare it wasn't really a need to cater for in portals. This was because as we would import users either via LDAP or other Account sources we could set their language preference in that process.
However, now that we have the likes of CSM etc, things are very different. Not only could a user need to change their language via the portal, they may also not yet be a registered / authenticated user. So in the Tokyo release we've added a whole bunch of features to cater for that.
This is going to be quite long, so get a warm cup of coffee ready and some nibbles, because there's a lot to get through. Let's begin...
The Dream
For quite a while we've wanted to be able to do this for any user right? In fact, I've even blogged about this idea for authenticated users in the past here detailing the various UX considerations to think about for this type of scenario. And for authenticated users it's not really been a massive problem because we've been able to add the "language-switcher" widget to cover that scenario, the challenge has always been for non-authenticated users.
Over the years, some people have tried to create logic on the "Guest" user, but the problem with that approach was that every non-authenticated user uses that account. So if you change the language for "Guest" you are in effect changing it for every non-authenticated user at the same time = not good let alone ideal.
So in the Tokyo release we've created the ability to show a switcher in the header (by default!)
How do we achieve this magic?
Let's get the first elephant out the way, yes you still need to install your language or have an active language record and add the translations - this isn't a short cut. So in my screenshot above, this is showing what is available on the instance I took the image from.
There are a few short steps to perform in order to show the widget:
Step1 - find the property glide.sp.portals.language_selector_enabled You will then need to enter in the sys_id of the portal in question (it's a comma separated list incase you want to add more than one),
If you need to revisit this because this step didn't work you can review the docs article here
Step2 - You will need to decide how granular you would like the selection to be:
Option 1 - With regional breakdowns:
Option 2 - without regional breakdown:
Note the difference in the selector, this is because we now have some clever tables that account for the Region vs the Country vs the Language (all part of the Locale support functionality I detail in the Language Support Guide post).
In the "System Localization" application, you will now see the following modules:
These tables essentially allow you to create a pyramid of data as per your needs. You may even find there are some pre-populations after your upgrade.
For a quick reference:
Language Regions -> [sys_language_region]
Languages -> [sys_language] the very same table you've known for years
Regions -> [sys_i18n_region]
To learn more about how to use these tables, check the docs article here.
To add it to the /esc portals
Currently, ootb the widget is not included on the /esc portals. It might in the future but ootb it isn't. So we will need to make some modifications to the Theme's > Header in order to call it.
In the "Body HTML template" field you will need to add the following code:
<!-- Language Selector Menu -->
<sp-widget widget="::data.langSelector"></sp-widget>
In the screenshot below, you can see I placed mine just before the "Header Navbar" (where you place it is important):
Then in the "Server Script" field you will need to add the following code:
data.langSelector = $sp.getWidget('sp-lang-selector');
Important note - because you are modifying the portal's header, you will likely get a fair few Cross Scope privilege errors. So you will need to re-approve these (either manually, or via the method provided)
If the above method does not work, then you can try something like this as a fix script (I can't promise it will work for your specific set up, just that the concept in principle should work):
// fix /esc portal errors
var check = new GlideRecord('sys_restricted_caller_access');
check.addEncodedQuery('sys_scopeSAMEAStarget_scope^status!=2^ORstatus=NULL^source!=1f7e93f01b982410ca4955bf034bcb16^ORsource=NULL');
check.query();
while(check.next()){
check.status='2';
check.update();
}
When done correctly, this should then present on the /esc portal like this:
**Update**
If you are having some issues with languages not showing, this almost certainly will be due to a lack of labels. If you go to the [sys_language] table and expose the "Display Label" field via the cog on a list (this is a personal customization of the list rather than a system one as we have to remember best practice 🙂 ). You'll need to ensure that every record has a value in that field, then they will show in the widget.
- For reference, this field was added in the Tokyo release for some new features and some future features.
So what have we learned?
Because of our various communities feedback, and the constant evolution of use-cases in the platform, we have added some extremely powerful new features. You now have the ability to present users who are or are not logged in with the ability to easily change their language - with no code required.
The super cool bit is, for a non-authenticated user, if they change their language it will be persistent (and used as their first language preference when they first login) because it will be stored in their browser's cookie until they become a fully logged in user.
As usual, if you found this post useful, please like share and subscribe for more as it always helps
Hi Alex
I tried the sp, csm, csp portal language picker and it worked perfectly. I thought it would be helpful to provide a few more detailed steps with screenshots.
1.1 To open the property list, type "sys_properties.list" in the navigator and press Enter key.
1. 2 From the property list search for "glide.sp.portals.language_selector_enabled" record and open the form.
1.3 Copy sp, csm, csp portals sys_id and set the Value field with a comma separator in the property form.
1.4 Click the Update button to update the property settings.
1.5 Confirm the language picker on the sp portal page.
1.6 Confirm the language picker on the csm portal page.
1.7 Confirm the language picker on the csp portal page.
Hi @kostyakozachuk,
That's actually an incredibly difficult thing to achieve because different browsers have different mechanisms of calling their "language" or "locale" values.
For example in Chrome based browsers you can "detect" the user's locale with the following Javascript in the console:
The problem is, this is a BCP-47 locale prefix which won't correspond to a language record. The ootb "English" is an "ISO-639-1" code of "en" and not all languages follow the same convention.
The widget itself is purposefully designed however to work for unauthenticated users in the CSM portal to allow them to set their language preference. My advice would therefore be to present a message to ask them to confirm their language, this will then be stored in their cookie on that browser until such time they have created an account and logged in where it will be stored on their user profile,
- the portal sys_id just needs to be added to the property for it to show in the CSM portal (none of the code changes mentioned above are required for the CSM portal),
Many thanks,
kind regards
Hi @Sabrina Devett ,
Assuming you've installed the language packs, and therefore assuming the languages in [sys_language] are "active=true" (they must be active languages) they should show. However, if you are using the "Region" mapping (due to the property) you may need to make some entries in [sys_language_region] like this (per region you want that language to show as):
For non-ootb provided languages (aka a "self localized" language) the logic is still such that the entry in [sys_language] for that given language is "active=true",
Many thanks,
kind regards
@Alex Coope - SN Thanks for the quick answer!
I've attached some screenshots - as you see I have several languages that is "active" but many of these are not showing in the language picker in portal. I have not set up Regions.
@Leri Andrews and @Alex Coope - SN , actually, Language Selector is available in ESC as OOTB. Just it is not on the Header, as Alex has shown here in this article.
Having Language Selector on the Header is really nice for manual Translation testing, while in most cases it makes no sense for the real users, as users rarely to never change their language.
The OOTB capability of changing the language is supported in ESC as OOTB in two (2) ways:
- if "Employee Profile" is not enabled and not being used, then you navigate to ["Avatar" > Profile] (it will open "hri_user_profile" page, unless you have Page Route Map redirect) and see Language Selector there; same view with Language Selector will be if you open someone's else profile, e.g. by clicking on someone's avatar on Ticket or Request page, or by opening someone's profile from Org Chart;
- if you opt-in to "Employee Profile", so that navigating to ["Avatar" > Profile] opens "employee_profile" page with multi-tab view, which has no Language Selector - "Avatar" dropdown menu will get another link, which is "Preferences", and navigating to it ["Avatar" > Preferences] will open "preferences" page with Language Selector on it.
All these Language Selectors: (a) Header one, (b) User Profile, and (c) Preferences - work identically same way, though "Header" one has slightly different visual dropdown.
Screenshots from PDI:
1) "My Profile" / HRI User Profile [hri_user_profile]
2) "User Profile" / User Profile [user_profile]
3) "Employee Profile" / Employee Profile [employee_profile]
4) "User Preferences" / Preferences [preferences]
