Since `en` is considered as the main fallback for all locales
ensure that it is present in all environments.
Note: Setting `config.i18n.fallbacks` to `true` means use the default locale
which means that if a particular instance is not using an `en` based locale
(the parent `en` locale is automatically derived as a fallback) then `en` will
not be available as a fallback.
This setting defines which locales will be exported to the frontend.
In general, ofn currently functions under a single locale
(which is also the default locale) but all translations are made from
the `en` locale.
The current process of ensuring translations are translated and make
their way into code is manual and prone to issues so occasionally
translations for keys in the default locale of a particular instance
are not deployed and the UI displays `missing translation` messages.
In these cases, it is far friendlier for the user to see fallbacks to
`en` rather than these errors so this commit ensure that at the very
least apart from the current default locale, `en` is also made available
and as such will be exported to the frontend so that it's translations
are available as a fallback in JS land.
I18n fallback config was already enabled in both frontend and backend.
Until now, available locales may not have been set (determined by the
`AVAILABLE_LOCALES` env var) and the translations for `en` not therefore
be present in the frontend for fallback to actually work.
This commit will ensure that a fallback to `en` is always possible in the
case of missing translations.
Otherwise, there are no log lines for any request, which makes it
impossible to find out anything about the app in production.
Obviously this increases the size of the log files but this has to be
dealt with log rotation. The data is our most important asset.
