On 24.2.2015 10:03, Michael Gerber wrote:
Am 24. Februar 2015 um 09:47 schrieb Marek Posolda <mposolda(a)redhat.com>:
> On 24.2.2015 07:40, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Michael Gerber" <gerbermichi(a)me.com
<mailto:gerbermichi@me.com>>
>>> To: "Stian Thorgersen" <stian(a)redhat.com
<mailto:stian@redhat.com>>
>>> Cc: "Marek Posolda" <mposolda(a)redhat.com
>>> <mailto:mposolda@redhat.com>>, "Stan Silvert"
<ssilvert(a)redhat.com
>>> <mailto:ssilvert@redhat.com>>, keycloak-dev(a)lists.jboss.org
>>> <mailto:keycloak-dev@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(a)redhat.com <mailto:stian@redhat.com>>:
>>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda(a)redhat.com
>>> <mailto:mposolda@redhat.com>>
>>> To: "Michael Gerber" <gerbermichi(a)me.com
>>> <mailto:gerbermichi@me.com>>, "Stan Silvert"
>>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>>
>>> Cc: keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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
The admin can configure the supported locales, so he can add only
english, if he wants to support only english.
Ok, looks that might be sufficient. I
have just "theoretical" usecase.
Maybe it's not needed and if later there is request for "disable
Accept-Language" it can be added sometime later.
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(a)redhat.com
>>>>> <mailto:ssilvert@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(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev