[keycloak-dev] Internationalization support (KEYCLOAK-301)

[Marek Posolda]

On 24.2.2015 07:40, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi at me.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Marek Posolda" <mposolda at redhat.com>, "Stan Silvert" <ssilvert at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 24, 2015 7:37:10 AM
>> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
>>
>>
>>
>> Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen <stian at redhat.com>:
>>
>>
>>
>> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Michael Gerber" <gerbermichi at me.com>, "Stan Silvert"
>> <ssilvert at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 23, 2015 6:48:00 PM
>> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
>> Will the order be configurable? For example admin may want to configure
>> realm locale (5) and wants users to use this one instead of
>> Accept-Language header (4) ?
>>
>> Is that really required?
>>   
>> A configurable order doesn't make sense for me, because you shouldn't change
>> step 1, 2, 3 and 5.
>> The only possible solution would be to make step 4 (Accept-Language)
>> optional. So, the admin can disable it in the admin console.
> Yes, that was what I was thinking, swapping 4 and 5 is the same as disabling Accept-Language. I can't see why anyone would want to do that though.
Maybe just because he wants to enforce showing login page in "tested" 
language like English ? Accept-Language can contain anything in it, so 
it may contain language, which is "partially" supported by Keycloak (not 
all labels and messages properly translated) and it may lead to the 
unproper login page with some labels in english and some in the second 
language, which may not look good.

But I don't know, maybe the use-case is really just theoretic. I agree 
that other changes in order instead of removing Accept-Language are 
likely not needed.

Marek
>
>>
>> Marek
>> On 23.2.2015 18:40, Michael Gerber wrote:
>>> The algorithm to determine the correct locale is like that:
>>> 1. Locale cookie
>>> 2. User profile (UserModel.attribute)
>>> 3. ui_locales query parameter
>>> 4. Accept-Language http header
>>> 5. Default realm locale
>>>
>>> The login page has also a dropdown with all available locales. The selected
>>> value will be stored in the locale cookie.
>>>> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
>>>>
>>>> On 2/23/2015 12:00 PM, Bill Burke wrote:
>>>>> What's the best practice for choosing local?
>>>> As I understand it, the thing to do is to use the accept-language header
>>>> as a starting point. If it's the only thing you have to go on then use
>>>> it.
>>>>
>>>> But I think we should definitely have a UserModel.attribute that is
>>>> settable by the user.
>>>>
>>>> Also, we have talked about building an "application switcher" component
>>>> that developers can include in their apps. That app switcher should
>>>> include a dropdown to switch locale as well as one for switching the
>>>> application.
>>>>> * User-Agent header?
>>>>> * From a login hint? I think OIDC has something like this (but what
>>>>> about SAML)?
>>>>> * Should we store this information somewhere (cookie,
>>>>> UserModel.attribute, etc..)
>>>>>
>>>>>
>>>>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I started to work on the internationalization support
>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>>>>>
>>>>>> I’ve already implemented the realm config in the admin console. I’ve put
>>>>>> it into the „Theme Setting“ (see screenshot)
>>>>>> I added the possibility to enable internationalization, add supported
>>>>>> locales and a select a default locale.
>>>>>>
>>>>>> Now I’d like to implement the logic which choose the correct locale.
>>>>>> Therefore I need the http header, cookie, query parameter, realm and
>>>>>> user.
>>>>>> The LoginFormsProvider and AccountProvider have all this information
>>>>>> apart from the http header and the cookie.
>>>>>> So I thought I could replace the UriInfo with the HttpRequest, but that
>>>>>> doesn’t work, because I can not access the UriInfo through the
>>>>>> HttpRequest (java.lang.NoSuchMethodError:
>>>>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>>>>>> So, I will add the HttpHeader to the LoginFormsProvider
>>>>>> and AccountProvider, or does anyone have a better idea?
>>>>>>
>>>>>> @Bill
>>>>>> How do you plan to store the claim „locale“ on a user? Will it be
>>>>>> accessible through the UserModel interface?
>>>>>>
>>>>>> Best
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev