Room for improvement with Remix + i18n

[Xiphe]

👋 Hey translation fans (or haters)

🚄 TL;DR:

If you have a minute to spare please have a look at remix-polyglot, my prove of concept about all the things that could be even better with i18n + remix.
I'd love to get some feedback to wether I'm too nerdy about this or if I should continue pushing this discussion.

---

I just listened to the Call Kent podcast about "i18n and Remix" where @kentcdodds¹ describes i18next and remix-i18next as the de-facto solutions to internationalisation with remix.
👍 I fully agree with this statement regarding "stood the test of time" and "adoption rate" criteria and would advise anyone planing to build a stable, translated app with remix to go with this exact solution.

But... as someone trying to optimise UX, performance and DX to the highest possible level 🚀, I want to point out some edge-cases and areas where I see room for improvement in the i18n sector.

1. EdgeCase: Flash of untranslated content when splitting i18n files in remix-i18next².
   I've discussed this with @sergiodxa. And we both agree that remix needs a way to declare route dependencies as blocking in order to solve this.
2. Opportunity: Technically translation files can be fingerprinted and cached as immutable. But placing them in /public (like with remix-i18next²) without further tooling makes this really hard if not impossible for most current remix stacks.
3. Opportunity: Remix could even pre-load additional translation files in parallel when requesting loader data and route modules in the frontend. For that we'd need some kind of routing hook that would allow to dynamically define additional assets for the route.
   The current LinksFunction is not sufficient here because it does not have access to route or cookies (where i18n state would be stored)
   (this is also true for stylesheets)
4. Opportunity: type-safe translations. Even though Typescript is overwhelmingly popular right now, all i18n solutions I know of work using a untyped DSL that make it really easy to shoot yourself in the foot with typos in translation keys, missing interpolation values etc.

To demonstrate that all these things are in fact solvable I've created remix-polyglot as a prove of concept.

So If this sounds somewhat interesting to you, please get in touch with me 🙏.

---

¹ Hi Kent, hope you don't mind the mention I'd really love know your opinions on this.
² I don't want to bash remix-i18next in any way. I have the highest respect for the work done here. I feel referencing it is required to make my point and would love to help getting my findings integrated into the package given there is interest.

[osdiab]

1. is a definite requirement for me, and 2) personally type safe translations would be amazing. remix-polyglot makes it just work (although on unstable APIs) and it is so nice.

I don't think you're being "too nerdy" about this, Remix just doesn't have a good story for i18n right now (after setting up remix-i18next, I wouldn't call it really "clean" either). The underlying platform can definitely use work and for anyone making an app that isn't just for Americans, this is critical.

Until then I'm probably just going to try rolling i18n manually with some clever routing and loaders, with the hope that in the future something stable comes out that ticks more of the boxes.

[miku86]

Hi @Xiphe ,

any news about your project/case study since your last commit 3 months ago?

[sergiodxa]

I consider remix-i18next mostly in maintenance mode because I don’t feel there’s anything extra to add.

The lib does what it needs to do, any feature request (eg detect locale from route params) is something that’s easier to do in user land (params.locale) so doing it in the lib will give you nothing and make it more complex.

And most of the issues and errors while using it are typically due a miss configuration of how the i18next backend and not remix-i18next itself.

[Xiphe]

Fully agree with @kiliman & @sergiodxa.

For me the app I was planning to build with remix turned out to not be translated, so I have not kept track on the topic very much...

From what I understand, the points I brought up in my initial post are still valid but might become solvable in user-land when remix/react-router eventually adds middleware.

I don't think remix needs buildin i18n support, but it should provide primitives to build top notch, high performant solutions. From what I see remix-i18next does the maximum that's currently possible with remix. Once remix adds middleware we might be able to create further performance optimizations.

[juniorforlife]

@Xiphe I agree with your point but unfortunately, from what I saw in the roadmap it won’t be implemented until after v2. Again, not to bash Remix but I don’t understand why such an important feature has not been implemented even tho it’s been heavily requested for over a year

[Xiphe]

Can't speak for the team but I genuinely trust them to allocate their resources to the topics that have the most value/impact. I also fully understand that it can be frustrating to find out when these don't align with our personal agenda ;)

[sergiodxa]

I think the reason why they didn't added support is because most of it can be done in userland, they added optional route segments which was requested a lot to do /:locale/something and /something work with the same route file.

Aside of that I think the only missing feature would be to support translating static route segments, using the example above /something can become /algo, but aside of that (and I'm not even sure that's a good idea), if Remix where to add anything else it will either need to force an i18n lib, like i18next, or build a custom one and that's a lot of work.