useTranslation - override language

[joekur]

🚀 Feature Proposal

Allow useTranslation to take an optional lng prop to override the language passed to getFixedT (link).

Motivation

In a server-side rendering (SSR) environment, there is no single language, since a single server could handle different requests in different languages. This requires you to manage multiple i18n instances, one per language, in order for a useTranslation somewhere down the react tree to work. While something like next-i18next may handle this for you, we have use-cases for shared component libraries that may execute in both SSR and client-side environments, which requires to hand-roll some code for synchronizing language between app and library, and initializing an i18n instance (or multiple) for the component library to use (with its own translation files).

To correctly support SSR in the component library, this seems to require creating an i18n instance per supported language, and initializing each of them with the translation files, so that the correct one for the given request's language can be passed down via context. However if we could instead just pass down, say, the current language via context, we could have just a single i18n instance, and we could wrap useTranslation in a hook that passes that language to it.

Example

Simple example:

const { t } = useTranslation('ns1', { lng: 'es' });

How this might be used in a component lib (let's keep it simple and say our component takes a lng prop itself):

const i18n = i18next.createInstance(...);

const MySharedComponent = ({ lng }) => {
  cons { t } = useTranslation('ns1', { i18n, lng });
  return t('foo');
};

[adrai]

workaround:

const { i18n } = useTranslation('ns1');
const t = i18n.getFixedT('en');

Does this work for you?
fyi: that would return the appropriate t function, but the translation resources needs to be loaded before... maybe use the preload option in the init call.

if that's ok, we could adapt the useTranslation like that:

[joekur]

I had actually thought about that - my uncertainty was around if that t would inherit the other properties that are being passed to the getFixedT inside useTranslation - namely the namespaces and keyPrefix as shown in your code screenshot?

[joekur]

And yeah as far as we're currently concerned, we would load translation files upfront - we wouldn't be using any other special backends for these component libraries.

[adrai]

ok, try v12.3.0

this should work:

const i18n = i18next.createInstance(...);

const MySharedComponent = ({ lng }) => {
  cons { t } = useTranslation('ns1', { i18n, lng });
  return t('foo');
};

[jamuhl]

not a fan of that change...might work for this scenario...but all others (using this not serverside with backends) will complain:

cons { t } = useTranslation('ns1', { lng });

// -> i get missings....why useTranslation does not assert lng get loaded?!?

[adrai]

not a fan of that change...might work for this scenario...but all others (using this not serverside with backends) will complain:

cons { t } = useTranslation('ns1', { lng });

// -> i get missings....why useTranslation does not assert lng get loaded?!?

react-i18next v12.3.1 + i18next v22.5.0 should also address that

[Kamahl19]

@adrai the result of these changes is that the resolvedLanguage is now string | undefined instead of always string

const { i18n } = useTranslation();
i18n.resolvedLanguage // string | undefined

Is this intentional change? I thought resolvedLanguage is always supposed to be resolved

[adrai]

There is no guarantee resolvedLanguage is always defined, but can you please provide a minimal reproducible example showing resolvedLanguage to be undefined? Just tested in a normal client side environment, and at least there it seems to be defined.

[adrai]

Or do you mean this? i18next/i18next#1960
for 'cimode' or 'dev' resolvedLanguage is not "set"

[Kamahl19]

Yes, sorry about that