Open liouxiao opened 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.
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.
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.
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.
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.
Current OIDC choose locale by setting related property in
server-config.xml
, e.g.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.