Hacker News Reader

Comment by 0xblinq | Hacker News Reader

Translations are a pain in the "SPA world".

Having to load every single string from your entire application is something I don't like at all. I wish at some point we have a solution where we can just create a bundle per language so we can get code splitting, etc and just ship what's necessary for your locale.

For the Inertia project I work on at my job, we just use a "frontend" translation solution and keep the Rails translations system just for the backend.

View on HN

We do actually have per-language code splitting with React/Vite. We essentially just have a map of [language, loader], where the loader utilizes lazy imports. Vite is smart enough to split those all out of the main bundle and they get loaded on demand as expected.

    const LOCALE_MAP: any = {
      en: () =>
        document.body.dataset["appEnv"] === "development"
          ? Promise.resolve({ default: {} as LocaleMap })
          : import("@locales/admin.en.compiled.json"),
      fr: () => import("@locales/admin.fr.compiled.json"),
      es: () => import("@locales/admin.es.compiled.json"),
      ...
    };

Then we consume it in a component which accepts the language key, lazy-loads the bundle by just calling `LOCALE_MAP[key]()`, and then uses it as the string translation set for a context function which looks up keys in a dict. Super simple.

This is still loading all strings for the current language, right?

(Don’t tell me about having the option to manually do separate bundles like “common”, “admin”, etc… that’s just more madness)

Yes, it's all the strings per language, for the SPA. We also have services which we can use to request a bundle of strings from the backend, which I guess could in theory be an avenue for JIT translation on the frontend, but so far the per-language bundle splitting has kept things managable for us.

Reply on news.ycombinator.com