💡 RFC: Internationalization

[marlonmarcello]

Would love to start a conversation around internationalization. For us here it's a requirement and I believe that is the case for many companies as well. Every website we ship is localized to at least 3 languages.

It's a big and complex system and I guess that's why a lot of frameworks leave it to plugins and external packages to deal with that. NextJS recently implemented this feature but it lacks SSG support.

One thing it's really nice and we could probably take a lot of inspiration from is how it's set up. In a nutshell:

• Set the locales on the config
• getStaticPaths receives that list of locales and the developer pick and choose which to generate

Would love to help implement this feature but most of all would love to hear from the more experienced maintainers what are your thoughts on this. If possible maybe point me in the right direction as to where to begin.

[natemoo-re]

Thanks for opening up the conversation! We understand that i18n is a hard requirement for a lot of teams, so it's something we want Astro to have a great solution for.

To be completely honest, our focus right now is on stabilizing the core features of Astro for a public release. Internationalization won't be part of that, but we're open to starting the conversation about what it should look like. I can definitely see how i18n could influence Astro's (yet to be designed) server-side rendering API, as well.

For those who are familiar with i18n solutions, please feel free to share your insights on what you like/dislike about any other tools you've used. NextJS is definitely a great reference point!

[marlonmarcello]

Thanks @natemoo-re !
I figured it wasn't a priority right now but thought that having it on the list just keeps it in the contributors mind and people can contribute with ideas as they pop up.

As it stands, with markdown files and the ability to choose a template, we can easily have localization just by making folders, which is really cool!

layouts/
  home.jsx

pages/
  en-us/
    home.astro.md
  fr-ca/
    home.astro.md

So, something like this would already work and there would be no need for duplicated layouts. So, great step forward already.

[FredKSchott]

Had a quick chat in #live-chat room in Discord, and there's definitely a lot of interest in this for our own Docs site.

[JakubKoralewski]

we can easily have localization just by making folders

But that requires copying every single page between two folders 😕

I think it would be nice to reuse the collection API syntax to have a /pages/$lang/... folder, and then some config mechanism to get the i18n-ed strings through props. For example would be nice to have /pages/$lang/index.astro which got its strings through props like so const { title, description, a,b,c } = Astro.props, and then the localization in index.{en,pl}.{js,ts,json,ftl,toml,yaml} (ftl is for Fluent which I think has a very nice syntax, but a text with a Fluent Variable would need to be available as a function so that the app could provided the variable to the fluent template. TypeScript support for the types of which strings are functions and which are raw strings would be nice.

So pages and files containing internationalization strings would be automatically matched based by having the same prefix up to the first dot, so hello.html and hello.en.json would automatically match.

[FredKSchott]

Update: We're going to add i18n support to our docs site, which should prove a real-world example of doing i18n for Astro sites. I think we can do it without changes to Astro, in which case we can make sure that there are clear docs for how to do it. If changes are needed, then we can come back here and discuss.

[jasikpark]

You can check out the #🌐🏗-i18n channel in the Discord to keep up with the docs i18n work btw!

[codingluke]

I am very looking forward to this! I guess with getStaticPaths it is doable for "dynamic" content. However, do you also have plans to enable easy I18n for "labels"/"static-content"? It seems to be not yet implemented on your own POC.

[FredKSchott]

Hey everyone! Our current RFC process is beginning to break down at this size, with over 50 open RFCs currently in the "discussing" stage. A growing community is a great problem to have, but our ability to give you RFC feedback has suffered as a result. In an effort to improve our RFC process, we are making some changes to better organize things.

From now on, all RFCs will live in a standalone repo: https://github.com/withastro/rfcs

This allows us to do three things: 1) Use threaded discussions for high-level ideas and improvements, without necessarily requiring an implementation for every idea. 2) Improve the quality of our RFC template and the speed/quality of all feedback. 3) Support inline comments and explicit approvals on RFCs, via a new Pull Request review process.

We hope that this new process leads to better RFC weekly calls and faster feedback on your RFCs from maintainers. More detail can be found in the new RFC repo README.

---

We can't automatically convert this issue to an RFC in the new repo because new RFC template is more detailed that this one. But, you can still continue this discussion in the new repo by creating a new Discussion in the RFC repo and copy-and-pasting this post (and any relevant follow-up comments) into it. Discussions are available for high-level ideas and suggestions without the requirement of a full implementation proposal.

Then, when you are ready to propose (or re-propose) an implementation for feedback and approval, you can create a new RFC using the new RFC template. More detail about how to do this can be found in the new RFC repo README.

Thanks for your patience as we attempt to improve things for both authors and reviewers. If you have any questions, don't hesitate to reach out on Discord. https://astro.build/chat