Bug: i18n is a server-side singleton #545
Description
Our I18n translater is currently a server-side singleton.
So, a race condition could result in a user getting SSRed content in the locale of a different active user.
We re-initialize i18n on every page load. So, the correct locale is usually used.
But a second parallel request could set the locale to something else that is then used for both responses.
In other words, we need to put a translater into the context that explicitly uses the user's correct locale.
The library lets you pick a locale per translation we just haven't used that feature.
Here's the game plan:🏏
- Put Fix i18n for emails #535 on hold for now, because there's sort of a bug, but it's only really reproducible in dev.
- 🚨 Always use English and hide display language select #546 (same as in prod now)
- Always use a translator from the Svelte Context API that explicitly passes a user's locale when translating each string (hopefully that's also easy when rendering emails?)
- Make sure Emails not being translated #534 is covered (i.e. merging most of Fix i18n for emails #535, but not initializing i18n in server.hooks.ts, but rather using the context API for emails as well)