This was an experiment all along and the internal remix API's I've used are no longer available. My i18n projects don't use Remix and I don't have any plans to further invest into this approach.
✨🐬🌍
type-safe, cached-forever, split-able, non-flickering, pre-loading, persistence-agnostic internationalization made for remix ♥
...all while still using plain old json files as phrase storage.
This package uses unofficial Remix API and monkey-patches Remix data functions to make sure all lazy translation files are loaded before rendering a new page with new translation namespaces.
I hope remix will eventually provide an official way to dynamically declare route dependencies
Until then, this package is mainly meant as a case-study and to underline my opinion that an API for this is needed. The package might break with any patch release of remix - use at your own risk.
npm install remix-polyglot
# yarn add remix-polyglot
See via-url example folder for guidance on how to setup your project
There is also a cookie based example but it's not documented that well.
by running remix-polyglot a declaration file is created based on your translation files
Enabling:
Auto-Completion:
Catching Typos:
Typed Interpolation:
running remix-polyglot also minifies and content-hashes your translation files and puts
them next to the remix build artifacts.
Each route can use its own set of translations (namespaces) only the translation files used for the current routes and locale are loaded.
🚨 This behavior is achieved using internal and potential unstable Remix API
When navigating in the frontend, the transition to the next page is delayed
until all required translations are loaded.
Creating the same UX like with traditional server rendering: First page render already includes all translations.
No need for loading spinners.
Note how the home-EA5A9AB7.json takes much longer to load then the route chunk (this is not the case normally). The page transition will take 1s
🚨 This behavior is achieved using internal and potential unstable Remix API
Required translation files of target routes are loaded along with the route
chunk and loader data.
This way, the splitted-out translations are very likely
to not increase page load time at all when navigating in the frontend.
Note how loading of home-EA5A9AB7.json starts at the same moment the route chunk is loaded
I've been unhappy with the state of i18n in JS/TS for quite a while and would like to provide a sleek & modern solution here.
Please be invited to discuss about this or send me an email.