Externalize i18next in Vite's rollupOptions

[marlo-longley]

Fixes an issue with integrating plugins that also have translations.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.05%. Comparing base (6d27937) to head (7699582).
Report is 5 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4095   +/-   ##
=======================================
  Coverage   95.05%   95.05%           
=======================================
  Files         315      315           
  Lines       15906    15906           
  Branches     2494     2494           
=======================================
  Hits        15120    15120           
  Misses        782      782           
  Partials        4        4           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cbeer]

I'm mildly suspicious of this solution because I'm worried it'll have an impact on downstream projects that import mirador. By making react-i18next + i18next external/peer dependencies, those projects will always have to install those dependencies in their project (whether they're using mirador-dl-plugin or not). In practice, I'm not sure that's a big deal but it does seem unfortunate?

Two (dumb?) alternatives come to mind:

• have mirador re-export useTranslation (so downstream projects have to import { useTranslation } from 'mirador' instead of from 'react-i18next'.
• update withPlugins and PluginHook to continue passing t into the plugins (which is, I guess, how this was work ok previously?)

[marlo-longley]

@cbeer out of those options, number 2 seems more reasonable to me. It seems potentially confusing to re-export useTranslation and require plugin devs to realize they need to import from mirador (option 1)?

Do you have any links to this previous paradigm for option 2?

[cbeer]

I was actually inclined towards option 1; I think there's maybe something nice about saying "if you want to use Mirador's i18n stuff, import our function".

Option 2 relied on all the HOCs calling withTranslation in their stack and it feels a little mysterious that a random t prop just magically shows up 🤷‍♂️.

[lutzhelm]

Option 1 would require 3rd party plugin developers who want to use translations to move to function components. I don't think that should stop us, just wanted to point it out.