It is not safe to rely on the browser language, as the user can override their language settings in their Jive preferences. For Apps (and hopefully tiles) the language code that the Jive UI is displayed in is passed as a query parameter to the request to the html of the view. E.g. ?lang=en
Alternatively, the set locale is part of the user profile, and you can read it from it (e.g. : https://community.jivesoftware.com/api/core/v3/people/@me has a locale field as part of the jive section)
Awesome - thanks Nils - this gives me a good starting point.
Following up on the potential of using the @me local field.
From what I can tell - I cannot distinguish between the user explicitly setting their preferences to en_US and having to render in en_US even if browser is set to say, French, and the language not being set, the default being passed as en_US, and the UI having to render in French because that's how the browser is set..
I found this documentation: Locale & Time Zone Settings
The precedence hierarchy is listed here, with the first given the highest precedence:
- Locale chosen in the user's preferences in the application. See How can I set default preferences for things like notifications, time zone, and locale?
- Locale set for the user's browser. (For example, a browser set to English will override global settings you make for another locale.)
- Locale set at the space level (in Spaces > Settings > Space Settings ). See Setting Space Name, Locale, and Allowed Content Types Setting Space Name, Locale, and Allowed Content Types.
- Locale set at the global level ( System > Management > Locale ).
I ran a quick test, and this seems to be correct.
1) If no "language" set under the users -> preferences
Then Jive will use the browser language settings for rendering.
2) If the users preferences->language is set - it overrides the browser language setting and displays in the Jive preferences specified language.
From my tests above, if "Language" is set in user->preferences, the UI renders in that language even if browser settings are different.
The main problem is /api/core/v3/people/@me will always have "locale": "en_US" whether the user explicitly selected that locale from within users -> preferences or whether its still set to (---).
Ryan - The issue I'm having is reliable method of UI language detection. How do I know whether to use the browser setting or the users API "locale" setting?
This issue comes from the fact that the "locale" key is set even if the user does not specify a locale (and the UI is then rendering via the default browser language).
This setting produces "en_US" @me JSON and I *should* use @me locale for language rendering.
But, unfortunately, setting (---) also produces "en_US" @me JSON, and I *should not* use @me locale, and instead use the browser settings for rendering.
It looks like Tiles do not have a ?lang= query string parameter passed to them? Could I possibly be doing something wrong here?
A dump of the $_REQUEST received by my server shows only a "features" key passed.
Array( [features] => core-v3,tile,os-2.5,oauth,jq-1.11,responsive )
Ryan, are you able to weigh in here on what the correct process is for determining the UI language inside Tiles?