We’re making use of the new universal login with the templating. This works fine, but in order for the widget to show up in the language we want we have to set ui_locales on createAuth0Client before the redirect. The rest of our template allows to change language while on the universal login page. We initially fixed this by having the language links redirect to our app with a language parameter, which would then redirect back to login with the correct ui_locales set.
Like so:
Thai user goes to app
Is not logged in and is redirected to login page
Everything is in English but user wants Thai, so clicks on Thai
App is called with ?language=th and redirect to login again with ui_locales=th
Everything is Thai.
So far so good. However now we run into the issue that if the user resets their password, the page might be in a different language so they want to change it. This resets the entire flow and now lands them on the login page, instead of password reset page.
Is it possible to change the language of the new widget without having to refresh the entire page?
You should be able to control the New Universal Login’s language with the Accept-Language header as an alternative to using the ui_locales parameter for some more flexibility outside of the /authorize flow, provided that the language in their request’s headers has been enabled on your tenant. Otherwise the page will use the default language set for your tenant.
Unfortunately I don’t really understand when and where I would be using the Accept-Language header. From my (perhaps limited) understanding the current flow goes like this:
User chooses to change password (through forgot password? on login page)
User received email with link to change the password.
User clicks link and is redirected to page hosted by auth0
At no point during this process can I control the headers. Am I missing something?
There is absolutely no way to change the language of the widget after the page has loaded, is there?
Also what is the use of passing multiple languages on ui_locales? I see it is a space delimited parameter, but if it’s not possible to change language once you’re on the page, what is the use of passing multiple?
Hi @aldert.vaandering , no you are right, you don’t have control over this; the headers should be set by the user’s browser, based on their language selection within the browser. Provided your tenant has the language, or at least one of the languages enabled that the end user’s browser sends in the header, it should automatically render the Universal Login and other screens in that language.
Unfortunately, I did some quick tests and it looks like the password reset screen doesn’t make use of ui_locales, or remembers what the user picked originally. It always seems to use the Accept-Language headers to choose which language to display.
I couldn’t find anything about ui_locales taking multiple languages in the documentation, and from trying it out I found it will just use whichever the first language in the ui_locales list sent that is also enabled in your tenant’s language settings. As it isn’t documented I wouldn’t advise trying to utilise that behaviour though, as it could be subject to change without notice.
Hi @aldert.vaandering - sorry I didn’t think to look at the SDK docs and was looking at our more general documentation for this which didn’t cover the space-delimited option.
It looks like what I mentioned before is indeed expected based on the SPA-JS reference, as it orders them by preference, so the first locale that is enabled in your tenant is chosen. I’ll ask internally whether this should/could be documented on the non SDK specific docs.
Is this topic still open for discussion?
I just found out this Reset Password screen doesn’t respect the ui_locales querystring parameter.
I believe this is necessary to be able to override the browsers language setting (considering typical scenario’s where people are using company computers that are setup the same for all users).
Or is there a way where the generated link (which is in the Reset your password e-mail) can be changed so that it will affect the display language for the reset password screen?