Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add native i18n support #3

Closed
7 tasks done
arctic-hen7 opened this issue Sep 6, 2021 · 2 comments
Closed
7 tasks done

Add native i18n support #3

arctic-hen7 opened this issue Sep 6, 2021 · 2 comments
Assignees
Labels
C-enhancement Category: enhancement
Milestone

Comments

@arctic-hen7
Copy link
Member

arctic-hen7 commented Sep 6, 2021

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
  • Integrate with Fluent
  • Make changes necessary to app definition systems
  • Implement translations caching
  • Create macros to make translation easy
  • Create locale detection systems
@arctic-hen7 arctic-hen7 self-assigned this Sep 6, 2021
@arctic-hen7 arctic-hen7 added the C-enhancement Category: enhancement label Sep 6, 2021
@arctic-hen7
Copy link
Member Author

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!

@arctic-hen7 arctic-hen7 added this to the v0.2.0 milestone Sep 12, 2021
@arctic-hen7
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: enhancement
Projects
None yet
Development

No branches or pull requests

1 participant