[keycloak-dev] Locale cookie vs ui_locales priority

[Stian Thorgersen]

The most common case is that the same user uses the browser. So if the user
has actively changed the locale in Keycloak it should stay like that. I
would actually suggest that if the user has changed the locale in Keycloak,
you should have the locale added to the token so the application can update
it's locale. That would result in all applications in the realm using the
same locale for the user.

Now if we change it to what you are suggesting you can end up with
situations where the first login page is displayed in one language, then
once the user has entered username/email it would end up switching to the
locale associated with the user.

If you really don't like that behaviour I would suggest we either introduce
a LocaleSelectorSPI where you can change the logic with a custom provider.
Alternatively, we could potentially add an option on the realm to be able
to disable the locale selector on Keycloak, which means that the user
wouldn't be able to change the locale and ui_locales would always take
precedence. In either case I think it's best to keep the current behaviour
as the default, with some way of being able to change it.

On Tue, 14 Aug 2018 at 12:56, Johannes Knutsen <johannes at kodet.no> wrote:

> It currently works the way you describe it. The ui_locales parameter
> is taking effect as long as the locale cookie isn't set. However, the
> logic implies that you always expect the same user to authenticate and
> our preference is that the user should get a login page matching the
> locale of the client which sends the user to the login page, if the
> client specified preferred locales as an ui_locales parameter.
> Using the locale cookie to override the ui_locales parameter makes the
> user experience inconsistent when moving from a client with a locale
> different from the last logged in user's preferred locale.
>
> A proposed change is to change locale priority as follows:
> 1. kc_locale query parameter. This updates the user's locale and locale
> cookie.
> 2. user profile locale if a user is authenticated. This updates the
> locale cookie.
> 3. ui_locales query parameter. If ui_locales contains the locale
> cookie value, return it. Otherwise, return the first locale available
> from ui_locales
> 4. locale cookie
> 5. accept language http header
>
> Is this change something you would consider merging if I create a pull
> request? Any other adjustments or thoughts regarding such a change?
>
> - Johannes
>
> On Tue, Aug 14, 2018 at 9:16 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > The way at least it was supposed to work was that the Locale cookie would
> > only be set if a user has explicitly changed the locale. That way we can
> > remember a users preference even when the user is logged out.
> >
> > Are you seeing ui_locales not taking affect without a user having used
> the
> > locale drop-down?
> >
> > On Mon, 13 Aug 2018 at 23:42, Johannes Knutsen <johannes at kodet.no>
> wrote:
> >>
> >> Currently the LocaleHelper#getUserLocale chooses locale priority based
> >> on the following order:
> >>
> >> 1. kc_locale query parameter
> >> 2. Locale cookie
> >> 3. User profile
> >> 4. ui_locales query parameter
> >> 5. Accept-Language http header
> >>
> >> We are building clients which uses the ui_locales parameter to select
> >> localization of the login to match the locale of the client.
> >> Since the locale cookie has a higher priority than the ui_locales
> >> query parameter, the ui_locales query parameter is ignored for any
> >> auth requests with a kc_locale cookie present.
> >>
> >> 1. Do you see any implications of prioritizing the ui_locales
> >> parameter above the locale cookie when resolving locale?
> >> 2. Are there reasons why the ui_locales does not update the locale
> >> cookie value the same way kc_locale parameter does it?
> >>
> >> Best regards,
> >> Johannes Knutsen
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>