Comments (8)
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.
from astro.
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.
from astro.
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.
from astro.
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!
from astro.
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.
from astro.
You can check out the #ππ-i18n
channel in the Discord to keep up with the docs i18n work btw!
from astro.
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.
from astro.
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
from astro.
Related Issues (20)
- Dependency Dashboard
- Vitest fails because of the ImageFunction helper (with content collections)
- [Bug]: WordPress Rest Api does not optimize images - set:html HOT 2
- "Browser APIs are not available on the server" error in `client:visible` component HOT 1
- Popup works as expected in dev mode but not in the build
- "Transition was aborted because of invalid state" coming form hoisted.*.js HOT 4
- files[normalizedPath] is not a function
- `@astrojs/lit` - `Module '"astro"' has no exported member 'AstroIntegration'.` HOT 1
- @astrojs/rss uses trailing slash in urls when it shouldn't HOT 1
- Add a new `Astro.metadata` global object HOT 6
- SVG rendering error - "unsupported file type" HOT 2
- VIewTransitions break on presence of <input name="action"> HOT 2
- cannot dev or preview a page, if the page filename contain 'index', eg. e-index.astro HOT 2
- onTouchStart not being attached to DOM elements when using jsx HOT 8
- Rendering React component does not work HOT 4
- `@astrojs/mdx`: βsmart quotesβ are broken in HTML headers HOT 2
- React hydration error with react table but works fine the same example in next.js HOT 2
- ViewTransitions breaking Radix/Shadcn ui Dropdown Functionality in Astro App HOT 7
- Relative paths in css url() references get double encoded HOT 4
- @astro/node gcloud [ERROR] TypeError: Error: Unexpected end of multipart data HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from astro.