Multilingual manifest labels

[dvhassel]

M3 seems to have an issue with multilingual manifest labels. This manifest should render the DE / EN label in the multilingual demo but regardless the locale picked, the first label is displayed.

[cbeer]

Thanks for creating the issue. @camillevilla and I took a look at the issue and suspect a bug or regression upstream in manifesto, but probably needs more investigation and a test case to file an issue upstream.

@jbaiter , any chance you have any insight here?

[jbaiter]

I just looked into it, it seems that this is due to a mix of Mirador using a deprecated API for getting the value of a property value, and Manifesto having a broken deprecation path for it (introduced by yours truly in this PR :grimacing: ).

To be more specific, in the current API, propVal.getValue takes one or more locales as parameters, and if none are passed, simply returns the first of the available values, regardless of its language. I think the previous API would use the propVal._defaultLocale to determine the value.

I'll try to fix this on both ends, i.e. make Mirador pass the explicit locale to all PropertyValue#getValue calls, and fix the backwards-incompatibility in Manifesto.

[cbeer]

Ah -- that sounds like a better API for us.. I think our current approach is to completely re-parse the manifest when the locale changes.

[jbaiter]

Another advantage of the new API is that it accepts a list of locales (in descending order of preference), which maps nicely to the window.languages property most modern browsers have. This should allow for a better "give me the most appropriate value for my language settings" implementation that is more in line with the intention of the algorithm outlined in the IIIF spec.

My current plan for the implementation is:

• Add a new userLanguages: string[] field in the Redux store
• Initialize it in AppProviders#componentDidMount after i18n.changeLanguage has been called, with the value of i18n.languages, which is a list that contains the language from the preceding call in the first position, and a list of fallback languages after that.
• Inject the languages from the Redux store as a prop wherever necessary
• Wherever M3 would previously call pv.getValue() or pv.getValues() will be replaced with pv.getValue(userLanguages) and pv.getValues(userLanguages)

What do you think?

[cbeer]

That sounds reasonable. I'm struggling to remember what the original UX intention was regarding fallback languages and if there's anything there that might trip up your plans.