You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Perseus should be able to support i18n effortlessly and without increasing build times.
I propose this is done by not changing any part of the existing build mechanism (yet), but simply by adding a section on the server that replaces all translation IDs, indicated maybe by <-translation.id.here->, with their translation at request-time, then caching the translated HTML/JSON files for future usage for that page and locale combination. This is essentially a very specialized use-case of incremental rendering combined with the build paths strategy, that I would propose deliberately isolating from the rest of the build matrix to improve simplicity and maintainability. Caching as described would also mean that build times wouldn't increase at all, unless some particular locales need to be pre-rendered for for certain pages, which could be specified in the define_app! macro.
The problem with this find-and-replace approach is of course that any translations dynamically added on the client by the Wasm code won't be translated. So, a struct could be passed to every template that provides a method for translation and stores the translations for the current locale (the app shell would instantiate this on loading a new locale). Then, every translation is wrapped in this (as in just about every other i18n library ever), and it then works! But, we optimize even further by combining this with the previous strategy and then simply checking in the function if its parameter is properly indicated as a translation ID. If not, it's been replaced at build and so we don't need to do anything.
This would also be friendly to a future exporting system because the request-time translation process could simply be performed for every page in an exporting process, leaving the user with a purely static site if they don't need more complex request-time rendering strategies.
Add support for translators
Feature-gate translator API to prevent locking users in
Okay, HUGE changes have been made to the existing interface, and i18n is now supported! Not enough to close this issue yet though, and I'll only push to a release once the translations engine supports things like variables and plurals, as well as once server-side translations caching is implemented. That will hopefully be done by end of day!
Okay, everything is ready on the main branch, so I'm closing this. Note that there are currently a few caveats in this system to do with #8 that will be fixed with Sycamore v0.6.0.
Perseus should be able to support i18n effortlessly and without increasing build times.
I propose this is done by not changing any part of the existing build mechanism (yet), but simply by adding a section on the server that replaces all translation IDs, indicated maybe by
<-translation.id.here->
, with their translation at request-time, then caching the translated HTML/JSON files for future usage for that page and locale combination. This is essentially a very specialized use-case of incremental rendering combined with the build paths strategy, that I would propose deliberately isolating from the rest of the build matrix to improve simplicity and maintainability. Caching as described would also mean that build times wouldn't increase at all, unless some particular locales need to be pre-rendered for for certain pages, which could be specified in thedefine_app!
macro.The problem with this find-and-replace approach is of course that any translations dynamically added on the client by the Wasm code won't be translated. So, a
struct
could be passed to every template that provides a method for translation and stores the translations for the current locale (the app shell would instantiate this on loading a new locale). Then, every translation is wrapped in this (as in just about every other i18n library ever), and it then works! But, we optimize even further by combining this with the previous strategy and then simply checking in the function if its parameter is properly indicated as a translation ID. If not, it's been replaced at build and so we don't need to do anything.This would also be friendly to a future exporting system because the request-time translation process could simply be performed for every page in an exporting process, leaving the user with a purely static site if they don't need more complex request-time rendering strategies.
The text was updated successfully, but these errors were encountered: