jamiefolsom
commented
6 years ago @akstuhl and @mkobayashi21 is this obsoleted by #63 ?
Open akstuhl opened 6 years ago
jamiefolsom
commented
6 years ago @akstuhl and @mkobayashi21 is this obsoleted by #63 ?
akstuhl
commented
6 years ago @jamiefolsom What's left to be done on i18n (and fits into this issue) is to figure out the way in which the back-end adapter can pass a locale specifier to the front-end application (i.e. the locale attached to the current user signed in to the Omeka S instance). Several possible ways to do this: add an options endpoint for styling, locale, and other configuration options to be specified by the back-end; set the locale specifier as a window variable similar to the JWT; include the locale as part of the information about the user included in the JWT itself. Since locale is specified through the user in Omeka S and we want to make other additions to the JWT payload, my inclination might be toward this last approach.
jamiefolsom
commented
6 years ago @akstuhl adding the locale to the JWT makes sense to me -- we should document what's passed in the JWT if we haven't already.
feralresearch
commented
6 years ago Per convo with Jamie:
Include locale setting in JWT claims, if we have it, this should be the default, but we should provide a user facing switch to override.
Omeka allows you to specify in two places: https://neatline-3-staging.herokuapp.com/admin/site/s/public-site/settings https://neatline-3-staging.herokuapp.com/admin/user/31/edit#user-settings
As a Neatline developer, I want the API specifications to include a straightforward and well-documented approach to retrieving localization options from the back-end adapter. These options may be passed from the back-end to the front-end app by a single API endpoint possibly containing other appearance-related settings, and/or be part of the interaction between the front-end app and its rendering container.