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
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