Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Multilingual manifest labels #3470

Open
dvhassel opened this issue Jun 23, 2021 · 5 comments · May be fixed by #4054
Open

Multilingual manifest labels #3470

dvhassel opened this issue Jun 23, 2021 · 5 comments · May be fixed by #4054
Labels
user experience

Comments

@dvhassel
Copy link
Contributor

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
Copy link
Collaborator

cbeer commented Jun 24, 2021

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?

@cbeer cbeer removed the Mirador3 label Jun 24, 2021
@jbaiter
Copy link
Collaborator

jbaiter commented Jun 25, 2021

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 😬 ).

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
Copy link
Collaborator

cbeer commented Jun 25, 2021

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
Copy link
Collaborator

jbaiter commented Jun 25, 2021 •
edited
Loading

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
Copy link
Collaborator

cbeer commented Jul 10, 2021

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.

jbaiter added a commit to jbaiter/mirador that referenced this issue Jul 17, 2021
@jbaiter
Refactor property value internationalization (fixes ProjectMirador#3470)
f28b81c 
This admittedly huge changeset refactors the way the correct language
value for a given property value is determined. A recent change in the
Manifesto library made it possible to pass a list of languages (in
descending order of preference) to the `PropertyValue.getValue` and
`PropertyValue.getValues` methods, instead of relying on a single
default locale that would be set when parsing the manifest. This allows
for a better user experience, since we can now dynamically respond to
changes in the user's language preferences without having to re-parse
the manifest. Additionally, we can make use of the browser's language
preferences to better match the user's language abilities.

However, this required a substantial reworking of quite a few parts of
Mirador, namely:

- Introduced a new `config.userLanguages` redux state variable that
  has the list of languages in descending order of preference (as
  returned by i18next.languages after setting the configured language)
- Every selector that would previously simply call `getValue` on a
  property value was changed to retrieve the user languages from the
  store and pass them to `getValue`. Additionally, for property values
  that are displayed in the companion window, where the locale can be
  overridden separately from the global language, selectors are extended
  to take a third `overrideLanguages` parameter that allows
  customization of the languages passed to `getValue`/`getValues`
- When changing the global language setting, the value in the companion
  window's `LocalePicker` (if enabled) now will select the next-best
  available language according to the langauge pereferences, if the
  desired language is not part of the metadata.

As a whole, these changes now allow on-the-fly switching of languages
via both the global language selector and the companion window locale
picker for all property values parsed from the manifest, with support
for falling back according to the user's client language preferences.
jbaiter added a commit to jbaiter/mirador that referenced this issue Jul 17, 2021
@jbaiter
Refactor property value internationalization (fixes ProjectMirador#3470)
84298aa 
This admittedly huge changeset refactors the way the correct language
value for a given property value is determined. A recent change in the
Manifesto library made it possible to pass a list of languages (in
descending order of preference) to the `PropertyValue.getValue` and
`PropertyValue.getValues` methods, instead of relying on a single
default locale that would be set when parsing the manifest. This allows
for a better user experience, since we can now dynamically respond to
changes in the user's language preferences without having to re-parse
the manifest. Additionally, we can make use of the browser's language
preferences to better match the user's language abilities.

However, this required a substantial reworking of quite a few parts of
Mirador, namely:

- Introduced a new `config.userLanguages` redux state variable that
  has the list of languages in descending order of preference (as
  returned by i18next.languages after setting the configured language)
- Every selector that would previously simply call `getValue` on a
  property value was changed to retrieve the user languages from the
  store and pass them to `getValue`. Additionally, for property values
  that are displayed in the companion window, where the locale can be
  overridden separately from the global language, selectors are extended
  to take a third `overrideLanguages` parameter that allows
  customization of the languages passed to `getValue`/`getValues`
- When changing the global language setting, the value in the companion
  window's `LocalePicker` (if enabled) now will select the next-best
  available language according to the langauge pereferences, if the
  desired language is not part of the metadata.

As a whole, these changes now allow on-the-fly switching of languages
via both the global language selector and the companion window locale
picker for all property values parsed from the manifest, with support
for falling back according to the user's client language preferences.
jbaiter added a commit to jbaiter/mirador that referenced this issue Jul 17, 2021
@jbaiter
Refactor property value internationalization (fixes ProjectMirador#3470)
c0102d0 
This admittedly huge changeset refactors the way the correct language
value for a given property value is determined. A recent change in the
Manifesto library made it possible to pass a list of languages (in
descending order of preference) to the `PropertyValue.getValue` and
`PropertyValue.getValues` methods, instead of relying on a single
default locale that would be set when parsing the manifest. This allows
for a better user experience, since we can now dynamically respond to
changes in the user's language preferences without having to re-parse
the manifest. Additionally, we can make use of the browser's language
preferences to better match the user's language abilities.

However, this required a substantial reworking of quite a few parts of
Mirador, namely:

- Introduced a new `config.userLanguages` redux state variable that
  has the list of languages in descending order of preference (as
  returned by i18next.languages after setting the configured language)
- Every selector that would previously simply call `getValue` on a
  property value was changed to retrieve the user languages from the
  store and pass them to `getValue`. Additionally, for property values
  that are displayed in the companion window, where the locale can be
  overridden separately from the global language, selectors are extended
  to take a third `overrideLanguages` parameter that allows
  customization of the languages passed to `getValue`/`getValues`
- When changing the global language setting, the value in the companion
  window's `LocalePicker` (if enabled) now will select the next-best
  available language according to the langauge pereferences, if the
  desired language is not part of the metadata.

As a whole, these changes now allow on-the-fly switching of languages
via both the global language selector and the companion window locale
picker for all property values parsed from the manifest, with support
for falling back according to the user's client language preferences.
jbaiter added a commit to jbaiter/mirador that referenced this issue Jul 17, 2021
@jbaiter
Refactor property value internationalization (fixes ProjectMirador#3470)
f4152fd 
This admittedly huge changeset refactors the way the correct language
value for a given property value is determined. A recent change in the
Manifesto library made it possible to pass a list of languages (in
descending order of preference) to the `PropertyValue.getValue` and
`PropertyValue.getValues` methods, instead of relying on a single
default locale that would be set when parsing the manifest. This allows
for a better user experience, since we can now dynamically respond to
changes in the user's language preferences without having to re-parse
the manifest. Additionally, we can make use of the browser's language
preferences to better match the user's language abilities.

However, this required a substantial reworking of quite a few parts of
Mirador, namely:

- Introduced a new `config.userLanguages` redux state variable that
  has the list of languages in descending order of preference (as
  returned by i18next.languages after setting the configured language)
- Every selector that would previously simply call `getValue` on a
  property value was changed to retrieve the user languages from the
  store and pass them to `getValue`. Additionally, for property values
  that are displayed in the companion window, where the locale can be
  overridden separately from the global language, selectors are extended
  to take a third `overrideLanguages` parameter that allows
  customization of the languages passed to `getValue`/`getValues`
- When changing the global language setting, the value in the companion
  window's `LocalePicker` (if enabled) now will select the next-best
  available language according to the langauge pereferences, if the
  desired language is not part of the metadata.

As a whole, these changes now allow on-the-fly switching of languages
via both the global language selector and the companion window locale
picker for all property values parsed from the manifest, with support
for falling back according to the user's client language preferences.
jbaiter added a commit to jbaiter/mirador that referenced this issue Jul 19, 2021
@jbaiter
Refactor property value internationalization (fixes ProjectMirador#3470)
ea883b6 
This admittedly huge changeset refactors the way the correct language
value for a given property value is determined. A recent change in the
Manifesto library made it possible to pass a list of languages (in
descending order of preference) to the `PropertyValue.getValue` and
`PropertyValue.getValues` methods, instead of relying on a single
default locale that would be set when parsing the manifest. This allows
for a better user experience, since we can now dynamically respond to
changes in the user's language preferences without having to re-parse
the manifest. Additionally, we can make use of the browser's language
preferences to better match the user's language abilities.

However, this required a substantial reworking of quite a few parts of
Mirador, namely:

- Introduced a new `config.userLanguages` redux state variable that
  has the list of languages in descending order of preference (as
  returned by i18next.languages after setting the configured language)
- Every selector that would previously simply call `getValue` on a
  property value was changed to retrieve the user languages from the
  store and pass them to `getValue`. Additionally, for property values
  that are displayed in the companion window, where the locale can be
  overridden separately from the global language, selectors are extended
  to take a third `overrideLanguages` parameter that allows
  customization of the languages passed to `getValue`/`getValues`
- When changing the global language setting, the value in the companion
  window's `LocalePicker` (if enabled) now will select the next-best
  available language according to the langauge pereferences, if the
  desired language is not part of the metadata.

As a whole, these changes now allow on-the-fly switching of languages
via both the global language selector and the companion window locale
picker for all property values parsed from the manifest, with support
for falling back according to the user's client language preferences.
@ggeisler ggeisler mentioned this issue Jan 30, 2023
Closed
@cbeer cbeer mentioned this issue Jan 10, 2024
Closed
@brittnylapierre brittnylapierre moved this to In Development in Accessibility + UX Aug 27, 2024
@cbeer cbeer linked a pull request Dec 17, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
user experience
Projects
Accessibility + UX
Status: In Development
Milestone
No milestone
3 participants
@cbeer @dvhassel @jbaiter