Public portal language based on custom URL without page refresh?

[Weird]

As an example let's say we have two languages. English and French.
The French portal is accessed from french.firm.com/sp and the English one is english.firm.com/sp. These would be custom URLs for the same instance.

Now if a guest user accesses the French portal they should be automatically set to use French language and similarly English link should change language to English. Now I have a setup working based on the OOB language picker but as I need to check the URL on client side there's an unfortunate refresh of the page happening and it's both annoying to the users and ugly to see.

Any ideas on what would be the best way to set the language before the page loads. I was considering trying to use sp.getParameter on server level, but I'd rather avoid using parameters as solution as people can access the pages without those. Perhaps someone has tackled a similar problem and solved it before?

[kostyakozachuk]

Hi @Weird 

Did you figure it out? We have the same requirements: to accept URL attribute that will set the language for public service portal for unauthorized users.

[Weird]

Hi,
Kinda. Since server side can't access the first part of the URL I instead included a URL parameter lang to the URL to recognize the language before the page has fully loaded. It's not perfect, but gets the job done:

	data.currentLangParm = $sp.getParameter("lang");

	if(data.currentLangParm){
		var langPref = gs.getSession().getUser().getPreference('user.language');
		if(!langPref){
			if(data.currentLangParm == "sv"){
					gs.getSession().getUser().setPreference('user.language', "sv");
			}else{
					gs.getSession().getUser().setPreference('user.language', "fi");
			}
		}
	}

The idea is that we include the parameter to any URL shared. For example:
yourinstance.fi/csp?lang=sv

Then if it's a new session the script can't find a session preference for language and it will set it and the page will load with the correct language.
You could make this work with multiple languages, but we just needed two, so the fall back is always "fi" if someone ends up changing the lang parameter value to something that we can't recognize.

if the user, for whatever reason, uses the URL without lang parameter we'll be forced to use the old logic to recognize url in client side and refresh the page.

Btw. one option we considered was to actually make a copy of the portal for any custom language URL's.
The portals would be identical with same widgets, but the portal suffix would be detected on server side with some glide uri action.
For example
french.firm.com/fp -> server could recognize fp
english.firm.com/ep -> server could recognize sp


Technically however there's a risk that widgets are removed or added and it would require extra testing and we'd rather avoid that.

[kostyakozachuk]

Thanks for the explanation!

And I found this ServiceNow Community article (and specifically, the section called "Force the language via the URL to Service Portals").

TLDR: Starting from Tokio release the URL param &lang=<language> can be utilized.

[Weird]

Thanks, I'll need to check on that.
Tbh I just immediately made the background logic as well, so I never actually tried if I could just hit &lang= into the url and whether it worked. Perhaps I can remove my custom logic if it works without.