-
Notifications
You must be signed in to change notification settings - Fork 1k
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
i18n Setup : Simpler configuration + examples #1847
Conversation
Hey @simoncrypta, thank you for this! Do you think we can get this out of draft soon? To help you with your outstanding points:
|
Hey @dac09 , Thank you for your help! I currently search for the best way to do internalization with RedwoodJS, and I have more research to do. That's why I didn't get this out of draft yet. I plan to make internalization easy with Redwood with a good convention because they have so many ways to do it with i18n.
I running |
@simoncrypta possibly helpful reference article from the Forums: https://community.redwoodjs.com/t/article-about-i18n-and-l10n/1477 And thanks for working on this. Huge help! |
@dac09 I think you could maybe help me to make it work with prerendering. i18next have a doc for SSR, but don't understand where they put their code for Passing initial translations / initial language down to client 😅 |
@clairefro curious if you have availability to help review this one, specifically about high-level setup and if this includes enough foundational elements to get a project started. |
Cool! I will take a closer look at this tonight
In the meantime @simoncrypta , Gatsby might be an interesting reference for how a framework handles i18n |
packages/cli/src/commands/setup/i18n/templates/fr.json.template
Outdated
Show resolved
Hide resolved
Thank you, @thedavidprice, to fix my mistakes. Very interesting i18n RFC @clairefro ! Sub-path routing is definitely something essential that I didn't completely convert with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a couple things I wanted to test locally (e.g. if the "sync Yarn" step was necessary as it was for Tailwind; in this case it was not). And also was generally curious about how React i18n works. I found a path bug I fixed and also updated some vars to match the switch to App.js. Overall was in great shape and works really well. See my simple changes in the commits for reference.
I have one comment about where to place the i18n.js file import in App.js. Not a dealbreaker but please check it out.
Thanks for the review and suggestions @clairefro Helpful indeed! And great work here @simoncrypta This is a really helpful foundational, first step to get people up and running (and not just because it fixes the current bug). I'll hand off to @dac09 for merge timing, but this has my approval. Per Claire's suggestion:
SEO is an important addition to this initial setup and does not require prerender to get started. Using something like React Helmet, we might be able to add a few pieces to this foundation that addresses both HTML lang and hreflang attributes. Might you be interested in exploring this as a next step here via a PR, @simoncrypta ? |
Even with React Helmet, won't prerender be necessary in order to support web crawlers for search engines and social shares? |
There's a lot of misconceptions here, so it's more complicated/confusing than it needs to be (which is partly intentional by Google). Crawlers render JS just fine and have for a while, so that's not really an issue. BUT site performance (alas, Lighthouse...) plays a role in the search ranking performance of a website. Meaning that even if your SEO is getting indexed just fine, your site might have terrible (or amazing) end-user performance — Google will adjust where you site displays in search results accordingly. There's a lot of tricks to get sites to perform. One of them is serving static, i.e. cached, content. Social Shares depend on OG data in the page meta, which does require being rendered server-side. Messy mess. tl;dr: |
Great work on all this @simoncrypta 🚀 Would you be interested in opening a new Issue to discuss possible improvements regarding React Helmet + SEO? |
This is to make internalization easy with Redwood
what's next
I think we should make a cookbook for translation at scale with RedwoodJS; I will try to work on it soon.
We could make it work with Prerender, It's currently don't work because the useTranslate hook I guess.
We will need to make a way with Redwood Router to add the language inside the URL.