We use Keycloak in a Docker container (image: jboss/keycloak:10.0.1) and a custom theme, which contains a locale selector (analogous to the keycloak theme). So the "Internationalization Enabled" flag is set to true. Additionally we store that locale in the user profile of Keycloak, using a mapper (Client Scopes > profile > Mappers > locale (Token mapper; User Attribute))
When an user connects to that Keycloak instance - without cookies - the language of the browser is used for the login screen, so it is for example displayed with Spanish translations. Also the locale is selected in the combobox, which looks like this:
<#if realm.internationalizationEnabled>
<div id="kc-locale" class="${properties.kcLocaleClass!}">
<div id="kc-locale-wrapper" class="${properties.kcLocaleWrapperClass!}">
<div class="kc-dropdown" id="kc-locale-dropdown">
<a href="#" id="kc-current-locale-link">${locale.current?no_esc}</a>
<ul>
<#list locale.supported as l>
<li class="kc-dropdown-item">
<a href="${l.url}">${l.label?no_esc}</a></li>
</#list>
</ul>
</div>
</div>
</div>
</#if>
Now the problem is that the Cookie KEYCLOAK_LOCALE is not set automatically for this first access. The login page is displayed in the correct language, but in the request (Java servlet) the locale of the user profile is used. This can lead to the case, that a Spanish user has the login screen in the correct language, but when he access the application it is displayed in the default language (e.g. English), respectively which is defined in the user profile. The locale value itself is not updated in the user profile.
This is not the case when the user sets the locale in the selector again. Then the cookie KEYCLOAK_LOCALE is for example set to "es" and when accessing our application, the locale is correctly set in the request.
Is there any possibility to have the correct locale for the first access, so without existing cookies (which would set the last chosen value)?
One possibility would to handle this by selecting the locale value in the selector again if the cookie is not set (using JavaScript), but this would lead to a reload of the page and in my opinion this would be a bad workaround.