-
Notifications
You must be signed in to change notification settings - Fork 145
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
Internationalisation support #546
Comments
This sounds great, but I think it would be optimal to try to maintain continuity with Perseus as much as possible, otherwise we'll end up with two completely different systems. Unfortunately, the Perseus i18n system is very closely tied to the framework's internals.... I reckon you could break out the |
That sounds ideal, it would make for a good base to build a standalone version on, and would prevent fragmentation. I'll have a look at how Perseus's i18n system works, and see what I can break out. |
Great! Let me know if you need any pointers! (Note especially that translators are managed with feature flags, not traits, due to internal constraints.) Also maybe open a tracking issue for this in Perseus as well @lizclipse? |
Alt tags (because searching for this is a PITA sometimes): internationalization, i18n, translation, t9n, localization, localisation, l10n, globalization, globalisation, g11n
I can't find any mention of how to do i18n within this library, and I think it's worth having a proper system that taps into the reactivity.
SolidJS has a pretty simple one that uses key-value translations and ties into the reactivity system, which might be a good example to base on.
Perseus uses Fluent, which out of the i18n crates in arewewebyet seems to be one of the best options. Making a crate based on that in the style of SolidJS's/Perseus's might work quite well, I'd be willing to make a POC if that sounds reasonable.
The text was updated successfully, but these errors were encountered: