Per language translation splitting and lazy loading #13

Open
opened 2025-08-29 17:26:08 +02:00 by VityaSchel · 4 comments
VityaSchel commented 2025-08-29 17:26:08 +02:00 (Migrated from github.com)

Currently the bundle includes all paraglide's languages which totals to ~800 kb

Image

If we can make languages lazy load, user would have to load the main app + ~25 kb of translations instead of almost a megabyte.

Blocked by https://github.com/opral/inlang-paraglide-js/issues/88

Currently the bundle includes all paraglide's languages which totals to ~800 kb <img width="443" height="494" alt="Image" src="https://github.com/user-attachments/assets/4c9088fd-8727-484d-ada9-907e821977b7" /> If we can make languages lazy load, user would have to load the main app + ~25 kb of translations instead of almost a megabyte. Blocked by https://github.com/opral/inlang-paraglide-js/issues/88
samuelstroschein commented 2025-08-29 19:39:13 +02:00 (Migrated from github.com)

Your build likely has an issue that is unrelated to paraglide js.

If your SPA is not split by page/route, the entire app is loaded at once. Irrespective of async await import() calls. Your bundler should await import() by page, which enables per page translations. The latter is hyper efficient, see https://inlang.com/m/gerre34r/library-inlang-paraglideJs/benchmark.

The only Paragelide JS related problem that comes to mind is that you use dynamic keys which bypass tree-shaking https://inlang.com/m/gerre34r/library-inlang-paraglideJs/basics#dynamically-calling-messages

Your build likely has an issue that is unrelated to paraglide js. If your SPA is not split by page/route, the entire app is loaded at once. Irrespective of async `await import()` calls. Your bundler should `await import()` by page, which enables per page translations. The latter is hyper efficient, see https://inlang.com/m/gerre34r/library-inlang-paraglideJs/benchmark. The only Paragelide JS related problem that comes to mind is that you use dynamic keys which bypass tree-shaking https://inlang.com/m/gerre34r/library-inlang-paraglideJs/basics#dynamically-calling-messages
VityaSchel commented 2025-08-29 19:49:09 +02:00 (Migrated from github.com)

That's because the app itself is mostly one page with majority of translated strings in it. I believe splitting build by pages won't shrink bundle size compared to splitting locales and only load the one selected.

That's because the app itself is mostly one page with majority of translated strings in it. I believe splitting build by pages won't shrink bundle size compared to splitting locales and only load the one selected.
samuelstroschein commented 2025-08-30 20:58:20 +02:00 (Migrated from github.com)

Is your app one single page or do you have multiple? Looking at the demo, you have one page. If that's the case, then indeed per page/component splitting wont help.

We would need per locale builds here. But that's the crux. How do we ahieve per locale builds with vite?

Is your app one single page or do you have multiple? Looking at the demo, you have one page. If that's the case, then indeed per page/component splitting wont help. We would need per locale builds here. But that's the crux. How do we ahieve per locale builds with vite?
VityaSchel commented 2025-08-30 21:22:11 +02:00 (Migrated from github.com)

Is your app one single page or do you have multiple? Looking at the demo, you have one page. If that's the case, then indeed per page/component splitting wont help.

We would need per locale builds here. But that's the crux. How do we ahieve per locale builds with vite?

I thought about dynamically loading translation files by using await import but from your tests it appears that this will take 10 times longer than just loading 800kb of all translations bundled with the app. We can't know which locale user wants before downloading main bundle, executing javascript and determining their preferred language.

> Is your app one single page or do you have multiple? Looking at the demo, you have one page. If that's the case, then indeed per page/component splitting wont help. > > We would need per locale builds here. But that's the crux. How do we ahieve per locale builds with vite? I thought about dynamically loading translation files by using `await import` but from your tests it appears that this will take 10 times longer than just loading 800kb of all translations bundled with the app. We can't know which locale user wants before downloading main bundle, executing javascript and determining their preferred language.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: hloth/lufin#13
No description provided.