4 ms·

My experience with using Inertia.js for Laravel has always been smooth and pleasant. But I can't say the same with translations/localisation.

0xblinq 2y ago
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.
- cheald 2y ago
  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.
  - 0xblinq 2y ago
    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)
    - cheald 2y ago
      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.
ncphillips 2y ago
Really? What's been the issues? We have our app fully translated and it's seemed fine.

0xblinq 2y ago

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.

cheald 2y ago
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.
- 0xblinq 2y ago
  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)
  - cheald 2y ago
    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.

ncphillips 2y ago

Really? What's been the issues? We have our app fully translated and it's seemed fine.