Is there a way to have a sync i18nObject function when loading the translation asynchronously

[phil714]

Hello,

I know this sounds counter intuitive but let me explain.

I'm currently trying to implement this library currently using the React adapter and loadLocalesAsync: true. My problem is that, when I want to use the i18nObject function outside of the react context, the function is asynchronous because it needs to import the translation file. For us that is very inconvenient because that would mean that anytime we use that translation module outside of React, it would need to be asynchronous. Where I'm confused is that the LL function returned by the React context is not asynchronous even if it uses the function getTranslationForLocale which is asynchronous.

Anyway we would really like to be able to call i18nObject through a LL wrapper (the same way the node adapter works) synchronously. Our use case is that when the app is initiated, the language is loaded and when the customer change the language, the whole app reloads. That means that we only really need to fetch a single language on init. This is why I used the loadLocalesAsync: true because I don't want to customer to have to load all the languages on start if he won't change to them (without reloading). So once the first language is imported/loaded, everything should be synchronous.

Let me know if any of this make sense and if you have an idea to achieve this.

Thank you

[ivanhofer]

Hi @phil714,
if you take a closer look, only the initialization of the i18nObject is asynchronos. So you basically would only need to initialize it somewhere and then you could use it in a synchronos way.

I think you just have to use the "raw" i18nObject function exported from i18n-util.ts in addition to the react adapter (you must initialize each version separately).

If you can't make asynchronos calls, you can always import the i18nObject from typesafe-i18n directly. See here how to initialize it. Just make sure to pass the generated Types as Generics when initializing it to get full typesafety support.

Your code will look something like this:

import { i18nObject } from 'typesafe-i18n'
import type { Translation, TranslationFunctions, Formatters, Locales } from './i18n-types'

i18nObject<Locales, Translation, TranslationFunctions, Formatters>(locale, translations, formatters)

Does one of the solutions above fit your needs?

[phil714]

Hello,

Yes I had tried doing what you said but I wasn't using the raw function directly which I guess doesn't make sense. For some reason I thought that this was a singleton so if the react adapter initialized it, I didn't need to initialize the one outside of react context. By using your proposed solution of calling the "raw" i18nObject, I was able to make it work. What I did is that I exported a synchronous function that get initialized by an asynchronous call. The init function is called before the app is fully renderered while we are fetching the user data. The init function is calling the i18nObject function like you said and put the returned function into an exported function that can be used synchronously.

// equivalent of App.tsx

// fetch user locale through jwt claims
await init18n(locale);
// finish setting everything up and render for the first time

// index.ts in the ./src/i18n directory

import { Locales, TranslationFunctions } from './i18n-types';
import { i18nObject } from './i18n-util';

export async function init18n(locale: Locales): Promise<void> {
  LL = await i18nObject(locale);
 // init react as well here
}

export let LL: TranslationFunctions;

The only downside to this that I can see is that the LL would be undefined if called before the init which make the typing inaccurate and can causes problem. I still think this is an acceptable solution but let me know if you would improve something of this or if that's not exactly what you meant.

Thank you

[ivanhofer]

Why can't you await the initialization of initI18n inside your root file? You say you are fetching some user data, I assume this is also an asynchronous call.

With your approach you could encounter some timing issses if the user data get's loaded before your translations. To not get an error inside your application, you could initialize LL like this:

const getFallbackProxy = (prefixKey?: string): any =>
   new Proxy((prefixKey ? () => prefixKey : {}), {
      get: (_target, key: string) => getFallbackProxy(prefixKey ? `${prefixKey}.${key}` : key),
   })
   
export let LL: TranslationFunctions = getFallbackProxy()

This fallback proxy emulates the key resolving of a translation file and outputs the full path instead of the translation. So you would get

LL.this.is.a.test() => 'this.is.a.test'

It is not ideal, but at least you don't get an error

[phil714]

I did await it but there is still a small possibility that the function could be called before the initialization. This is an extremely minor problem so I think we'll be fine with it. Your fallback proxy solution seems to make sense, I might add it as well. Thank you for the response!