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

Stian Thorgersen stian at redhat.com
Tue Feb 24 01:26:49 EST 2015



----- 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?

> 
> 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
> 



More information about the keycloak-dev mailing list