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

[Michael Gerber]

Am 24. Februar 2015 um 09:47 schrieb Marek Posolda <mposolda at redhat.com>:

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
 
The admin can configure the supported locales, so he can add only english, if he wants to support only english.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150224/d17121d4/attachment-0001.html