The new search experience should work everywhere both for users and developers. If users can't use our components, they won't be used. If developers can't //re//use our components, they won't be used. To this end, the internationalization strategy for components should work robustly and with as few dependencies on the MediaWiki ecosystem as possible (in production and during development). This task is to identify the options available and their tradeoffs.
This task is focused on identifying an appropriate internationalization project infrastructure. For example, `mw.msg()`. T249300 focuses on components themselves and is distinct.
== Acceptance criteria
- [] Different Vue.js internationalization options are identified including [[ https://github.com/santhoshtr/vue-banana-i18n | Santhosh's vue-banana-i18n ]], [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/585797/1/resources/src/vue/i18n.js | Roan's fork ]], and [[ https://kazupon.github.io/vue-i18n/ | the standard recommend by Vue School, vue-i18n ]].
- [] The tradeoffs for each solution are enumerated herein.
- [] A decision for the approach to take is made and a task is created.
== Open questions
- `mw.msg()`-based solutions have a [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/25abda6/resources/src/mediawiki.jqueryMsg/mediawiki.jqueryMsg.js#62 | dependency on jQuery ]]? Should this be considered an isolated exception to avoiding jQuery usage in shared components? Does this mean i18n support won't be very good outside of MW?