search

mitreid-connect / OpenID-Connect-Java-Spring-Server

An OpenID Connect reference implementation in Java on the Spring platform.
Other
1.48k stars 766 forks source link

Locale is not auto-detected #1058

Open liouxiao opened 8 years ago

liouxiao commented 8 years ago

Current OIDC choose locale by setting related property in server-config.xml, e.g. 

        <!-- This property sets the locale for server text -->
        <!-- <property name="locale" value="sv" /> -->

however, it limits the UI to a single (pre-determined) locale. Instead, users might expect the server could choose proper locale according to their browsers' language settings.

jricher commented 8 years ago

In practice we've found this to be unreliable at best, thus we had the explicit locale property in the configuration. We could perhaps have a resolver that checks the configuration first and then falls back to automated detection if the property isn't set.

merric commented 8 years ago

We are taking the stance to letting the client (resource requester) determine the locale of the request. That way the AS only has to translate the needed payload. We are doing this by passing an explicit locale in the header and the absence of the header defaults to the server property. I think the AS having to determine business logic like that is a bad idea when each calling app could desire something different.

jricher commented 8 years ago

We also want to respect the current user's Locale, from https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-common/src/main/java/org/mitre/openid/connect/model/UserInfo.java#L169, if it's available. Currently we don't do that either.

merric commented 8 years ago

That's a good point. We blew away most of UserInfo in our implementation, but I'd imagine the base app would want to respect that if populated.

jricher commented 8 years ago

In ee537c404bdabaf6e9a399158a7d470ded0de57a we externalized the locale resolver configuration component. This will at least allow it to be overridden for server-side messages, but it doesn't play nicely with the client-side (JS) messages yet. Keeping issue open until there's a more robust solution.