[keycloak-dev] Locale cookie vs ui_locales priority

[Johannes Knutsen]

We do already add the user's locale to the token and will try to
update the clients locale based on the token.
However, since the common case is that the same user uses the browser
on each login, the ui_locales parameter is typically just ignored and
gives very little value as it is currently implemented. For the common
cases where you would like to have the default behavior, the
ui_locales parameter is simply not sent to the auth request. When the
ui_locales parameter is provided from the client, I still think it
should be used and override the locale cookie if the locale value is
not present in ui_locales.

A LocaleSelectorSPI does make sense. Not sure of the demand, however
localization is typically something I guess people would never agree
upon. Thus, giving the option to customize it makes sense. A custom
implementation could for example use a locale cookie global to an
organization's root domain instead of the realm specific locale
cookie.

I will try to have a look at the amount of work required to extract such a SPI.

On Tue, Aug 14, 2018 at 8:32 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 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