If you don’t mind loading the translations dynamically on initialization, then I would also recommend using a custom backend + namespaces. The idea is that you configure au-i18n (and thereby i18next ) with a set of custom namespaces, and a custom backend. After initialization, i18next will invoke the
read method in your backend implementation. This looks like this:
language: string, //<-- current locale
namespace: string, //<-- namespace for which translation is required
callback, // error-first callback for i18next
i18next will invoke this method for each namespaces you have configured. The advantage is that you translation loading and aggregation logic is centralized in your backend. Apart from that, it offers more flexibility in terms of manipulating the translation resources (for example, you need call a service, and then adapt the service response to a form that is consumable by your app translation keys). Also once the current locale is changed, i18next invokes the same method in order to load the translations for the new locale. Also, it does not request for any existing namespace and/or language.
I am super biased towards this recipe, as it works for my use-case quite well and let me conveniently manage the translations using namespaces, and from heterogenous sources. However, if you want to load the resources just-in-time, then probably you are already on right track, provided you manually take care of that.