Docs/move-english-docs-to-"en"-folder (#2268)

* Move english pages under `/en` and fix broken links hopefully

* Add meta refresh tags for `/` to `/en/` url moves + make `/index.astro` work without js

* update languageselect for new en format

Co-authored-by: Fred K. Schott <fkschott@gmail.com>

docs/package.json

@@ -12,7 +12,7 @@
     "lint:a11y:local": "pa11y-ci --sitemap 'http://localhost:3000/sitemap.xml' --sitemap-find 'https://docs.astro.build' --sitemap-replace 'http://localhost:3000'",
     "lint:a11y:remote": "pa11y-ci --sitemap 'https://docs.astro.build/sitemap.xml'",
     "lint:linkcheck": "start-test 'yarn dev --silent' 3000  'yarn lint:linkcheck:local'",
-    "lint:linkcheck:local": "blc -ro --user-agent 'broken-link-checker/0.7.8' 'http://localhost:3000'",
+    "lint:linkcheck:local": "blc -roe --user-agent 'broken-link-checker/0.7.8' 'http://localhost:3000/en/getting-started'",
     "lint:linkcheck:remote": "blc -ro --user-agent 'broken-link-checker/0.7.8' 'https://docs.astro.build/'"
   },
   "devDependencies": {

docs/src/components/Header/LanguageSelect.tsx

@@ -29,11 +29,7 @@ const LanguageSelect: FunctionalComponent<{ lang: string }> = ({ lang }) => {
 				aria-label="Select language"
 				onChange={(e) => {
 					const newLang = e.target.value;
-					if (newLang === 'en') {
-						window.location.pathname = `/getting-started`;
-					} else {
-						window.location.pathname = `/${newLang}/getting-started`;
-					}
+					window.location.pathname = `/${newLang}/getting-started`;
 					// TODO: Preserve the current page, if it exists:
 					// const oldPathname = window.location.pathname;
 					// const oldPathnameParts = oldPathname.split('/');

docs/src/config.ts

@@ -1,43 +1,43 @@
 export const SIDEBAR = {
 	en: [
 		{ text: 'Setup', header: true },
-		{ text: 'Getting Started', link: 'getting-started' },
-		{ text: 'Quickstart', link: 'quick-start' },
-		{ text: 'Installation', link: 'installation' },
-		{ text: 'Themes', link: 'themes' },
-		{ text: 'Astro vs. X', link: 'comparing-astro-vs-other-tools' },
-		{ text: 'Migrate to v0.21', link: 'migration/0.21.0' },
+		{ text: 'Getting Started', link: 'en/getting-started' },
+		{ text: 'Quickstart', link: 'en/quick-start' },
+		{ text: 'Installation', link: 'en/installation' },
+		{ text: 'Themes', link: 'en/themes' },
+		{ text: 'Astro vs. X', link: 'en/comparing-astro-vs-other-tools' },
+		{ text: 'Migrate to v0.21', link: 'en/migration/0.21.0' },
 
 		{ text: 'Basics', header: true },
-		{ text: 'Project Structure', link: 'core-concepts/project-structure' },
-		{ text: 'Component Syntax', link: 'core-concepts/astro-components' },
-		{ text: 'Pages', link: 'core-concepts/astro-pages' },
-		{ text: 'Layouts', link: 'core-concepts/layouts' },
-		{ text: 'Routing', link: 'core-concepts/routing' },
-		{ text: 'Partial Hydration', link: 'core-concepts/component-hydration' },
+		{ text: 'Project Structure', link: 'en/core-concepts/project-structure' },
+		{ text: 'Component Syntax', link: 'en/core-concepts/astro-components' },
+		{ text: 'Pages', link: 'en/core-concepts/astro-pages' },
+		{ text: 'Layouts', link: 'en/core-concepts/layouts' },
+		{ text: 'Routing', link: 'en/core-concepts/routing' },
+		{ text: 'Partial Hydration', link: 'en/core-concepts/component-hydration' },
 
 		{ text: 'Guides', header: true },
-		{ text: 'Styling & CSS', link: 'guides/styling' },
-		{ text: 'Markdown', link: 'guides/markdown-content' },
-		{ text: 'Debugging', link: 'guides/debugging' },
-		{ text: 'Data Fetching', link: 'guides/data-fetching' },
-		{ text: 'Pagination', link: 'guides/pagination' },
-		{ text: 'RSS', link: 'guides/rss' },
-		{ text: 'Supported Imports', link: 'guides/imports' },
-		{ text: 'Aliases', link: 'guides/aliases' },
-		{ text: 'Environment Variables', link: 'guides/environment-variables' },
-		{ text: 'Deploy to the web', link: 'guides/deploy' },
-		{ text: 'Publish to npm', link: 'guides/publish-to-npm' },
+		{ text: 'Styling & CSS', link: 'en/guides/styling' },
+		{ text: 'Markdown', link: 'en/guides/markdown-content' },
+		{ text: 'Debugging', link: 'en/guides/debugging' },
+		{ text: 'Data Fetching', link: 'en/guides/data-fetching' },
+		{ text: 'Pagination', link: 'en/guides/pagination' },
+		{ text: 'RSS', link: 'en/guides/rss' },
+		{ text: 'Supported Imports', link: 'en/guides/imports' },
+		{ text: 'Aliases', link: 'en/guides/aliases' },
+		{ text: 'Environment Variables', link: 'en/guides/environment-variables' },
+		{ text: 'Deploy to the web', link: 'en/guides/deploy' },
+		{ text: 'Publish to npm', link: 'en/guides/publish-to-npm' },
 
 		{ text: 'Reference', header: true },
-		{ text: 'Built-In Components', link: 'reference/builtin-components' },
-		{ text: 'API Reference', link: 'reference/api-reference' },
-		{ text: 'CLI Reference', link: 'reference/cli-reference' },
+		{ text: 'Built-In Components', link: 'en/reference/builtin-components' },
+		{ text: 'API Reference', link: 'en/reference/api-reference' },
+		{ text: 'CLI Reference', link: 'en/reference/cli-reference' },
 		{
 			text: 'Configuration Reference',
-			link: 'reference/configuration-reference',
+			link: 'en/reference/configuration-reference',
 		},
-		{ text: 'Renderer Reference', link: 'reference/renderer-reference' },
+		{ text: 'Renderer Reference', link: 'en/reference/renderer-reference' },
 	],
 	de: [
 		{ text: 'Einrichtung', header: true },

docs/src/pages/[slug].astro

@@ -0,0 +1,20 @@
+---
+export async function getStaticPaths() {
+    // get english pages that moved from `/` to `/en/`
+    const englishPages = Astro.fetchContent('./en/**.md');
+
+    // add pages that are `*.astro` files as well
+    const otherPages = [{ url: "/en/themes" }];
+
+    return [...englishPages, ...otherPages].map((page) => ({
+        params: {
+            slug: page.url.slice(4),
+        },
+        props: {
+            englishSlug: page.url,
+        }
+    }));
+}
+---
+
+<meta http-equiv="refresh" content={`0;url=${Astro.props.englishSlug}`} />

docs/src/pages/en/comparing-astro-vs-other-tools.md

@@ -22,7 +22,7 @@ Docusaurus was designed to build documentation websites and has some built-in, d
 
 ### Comparing Docusaurus vs. Astro Performance
 
-In most cases, Astro websites will load significantly faster than Docusaurus websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration).
+In most cases, Astro websites will load significantly faster than Docusaurus websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration).
 
 Docusaurus doesn't support partial hydration, and instead makes the user load and rehydrate the entire page in the browser, even if most of the page content is static. This creates a slower page load and worse performance for your website. There is no way to disable this behavior in Docusaurus.
 
@@ -41,9 +41,9 @@ One big reason behind this performance difference is Astro's smaller JavaScript
 
 Elder.js uses Svelte to render your website. Astro is more flexible: you are free to build UI with any popular component library (React, Preact, Vue, Svelte, Solid and others) or Astro's HTML-like component syntax which is similar to HTML + JSX.
 
-Elder.js is unique on this list as the only other site builder to support [partial hydration](/core-concepts/component-hydration). Both Astro and Elder.js automatically strip unnecessary JavaScript from the page, hydrating only the individual components that need it. Elder's API for partial hydration is a bit different and Astro supports a few features that Elder.js doesn't (like `client:media`). However performance-wise, both projects will build very similar sites.
+Elder.js is unique on this list as the only other site builder to support [partial hydration](/en/core-concepts/component-hydration). Both Astro and Elder.js automatically strip unnecessary JavaScript from the page, hydrating only the individual components that need it. Elder's API for partial hydration is a bit different and Astro supports a few features that Elder.js doesn't (like `client:media`). However performance-wise, both projects will build very similar sites.
 
-Elder.js uses a custom routing solution that may feel unfamiliar to new developers. Astro uses [file-based routing](/core-concepts/routing) which should feel familiar to anyone coming from Next.js, SvelteKit, and even other static site builders like Eleventy.
+Elder.js uses a custom routing solution that may feel unfamiliar to new developers. Astro uses [file-based routing](/en/core-concepts/routing) which should feel familiar to anyone coming from Next.js, SvelteKit, and even other static site builders like Eleventy.
 
 Elder.js was designed to run on large websites, and claims to build one website of ~20k pages in less than 10 minutes (on a modest VM). At the time of writing, Astro builds ~1k pages in 66 seconds but has not yet been tested on 20k+ page projects. Astro is still in early beta, and matching Elder.js build speed is a goal for Astro v1.0.
 
@@ -61,7 +61,7 @@ Conceptually, Eleventy is aligned with Astro's "minimal client-side JavaScript"
 
 Eleventy achieves this by pushing you to avoid JavaScript entirely. Eleventy sites are often written with little to no JavaScript at all. This becomes an issue when you do need client-side JavaScript. It is up to you to create your own asset build pipeline for Eleventy. This can be time consuming and forces you to set up bundling, minification, and other complex optimizations yourself.
 
-By contrast, Astro automatically builds your client-side JavaScript & CSS for you. Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration). While it is possible to achieve this yourself in Eleventy, Astro offers it built in by default.
+By contrast, Astro automatically builds your client-side JavaScript & CSS for you. Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration). While it is possible to achieve this yourself in Eleventy, Astro offers it built in by default.
 
 ## Gatsby vs. Astro
 
@@ -75,7 +75,7 @@ Gatsby requires a custom GraphQL API for working with all of your site content.
 
 ### Comparing Gastby vs. Astro Performance
 
-In most cases, Astro websites will load significantly faster than Gatsby websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration).
+In most cases, Astro websites will load significantly faster than Gatsby websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration).
 
 Gatsby doesn't support partial hydration, and instead makes the user load and rehydrate the entire page in the browser, even if most of the page content is static. This creates a slower page load and worse performance for your website. Gatsby has [a community plugin](https://www.gatsbyjs.com/plugins/gatsby-plugin-no-javascript/) for removing all JavaScript from the page, but this would break many websites. This leaves you with an all-or-nothing decision for interactivity on each page.
 
@@ -100,7 +100,7 @@ Hugo uses a custom [templating language](https://gohugo.io/templates/introductio
 
 Conceptually, Hugo is aligned with Astro's "minimal client-side JavaScript" approach to web development. Hugo and Astro both offer similar, zero-JavaScript-by-default performance baselines.
 
-Both Hugo and Astro offer built-in support for building, bundling and minifying JavaScript. Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration). While it is possible to achieve this yourself in Hugo, Astro offers it built in by default.
+Both Hugo and Astro offer built-in support for building, bundling and minifying JavaScript. Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration). While it is possible to achieve this yourself in Hugo, Astro offers it built in by default.
 
 ## Jekyll vs. Astro
 
@@ -128,7 +128,7 @@ SvelteKit supports both Static Site Generation (SSG) and Server-Side Rendering (
 
 ### Comparing SvelteKit vs. Astro Performance
 
-In most cases, Astro websites will load faster than SvelteKit websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration).
+In most cases, Astro websites will load faster than SvelteKit websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration).
 
 SvelteKit doesn't support partial hydration, and instead makes the user load and rehydrate the entire page in the browser, even if most of the page content is static. This creates a slower page load and worse performance for your website. SvelteKit does offer support for [page-level static, zero-JavaScript pages](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate). However, there is no planned support for hydrating individual components on the page. This leaves you with an all-or-nothing decision for interactivity on each page.
 
@@ -155,7 +155,7 @@ Next.js supports both Static Site Generation (SSG) and Server-Side Rendering (SS
 
 ### Comparing Next.js vs. Astro Performance
 
-In most cases, Astro websites will load significantly faster than Next.js websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration).
+In most cases, Astro websites will load significantly faster than Next.js websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration).
 
 Next.js doesn't support partial hydration, and instead makes the user load and rehydrate the entire page in the browser, even if most of the page content is static. This creates a slower page load and worse performance for your website. Next.js has [experimental support](https://piccalil.li/blog/new-year-new-website/#heading-no-client-side-react-code) for fully-static, zero-JavaScript pages. However, there is no planned support for hydrating individual components on the page. This leaves you with an all-or-nothing decision for interactivity on each page.
 
@@ -182,7 +182,7 @@ Nuxt supports both Static Site Generation (SSG) and Server-Side Rendering (SSR).
 
 ### Comparing Nuxt vs. Astro Performance
 
-In most cases, Astro websites will load significantly faster than Nuxt websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration).
+In most cases, Astro websites will load significantly faster than Nuxt websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration).
 
 Nuxt doesn't support partial hydration, and instead makes the user load and rehydrate the entire page in the browser, even if most of the page content is static. This creates a slower page load and worse performance for your website. There is no way to disable this behavior in Nuxt.
 
@@ -207,7 +207,7 @@ Evan You (creator of Vue.js) is currently working on a new version of Vuepress c
 
 ### Comparing VuePress vs. Astro Performance
 
-In most cases, Astro websites will load significantly faster than VuePress websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration).
+In most cases, Astro websites will load significantly faster than VuePress websites. This is because Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration).
 
 VuePress doesn't support partial hydration, and instead makes the user load and rehydrate the entire page in the browser, even if most of the page content is static. This creates a slower page load and worse performance for your website. There is no way to disable this behavior in VuePress.
 
@@ -230,4 +230,4 @@ Zola uses [Tera](https://tera.netlify.app/) to render your website. Astro lets y
 
 Conceptually, Zola is aligned with Astro's "minimal client-side JavaScript" approach to web development. Zola and Astro both offer similar, zero-JavaScript-by-default performance baselines.
 
-Astro offer built-in support for building, bundling and minifying JavaScript. Zola requires using another build tool like Webpack to bundle and process JavaScript. Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/core-concepts/component-hydration). While it is possible to achieve this yourself in Zola, Astro offers it built in by default.
+Astro offer built-in support for building, bundling and minifying JavaScript. Zola requires using another build tool like Webpack to bundle and process JavaScript. Astro automatically strips unnecessary JavaScript from the page, hydrating only the individual components that need it. This feature is called [partial hydration](/en/core-concepts/component-hydration). While it is possible to achieve this yourself in Zola, Astro offers it built in by default.

docs/src/pages/en/core-concepts/astro-components.md

@@ -27,7 +27,7 @@ For example, this three-line file is a valid Astro component:
 </div>
 ```
 
-An Astro component represents some snippet of HTML in your project. This can be a reusable component, or an entire page of HTML including `<html>`, `<head>` and `<body>` elements. See our guide on [Astro Pages](/core-concepts/astro-pages) to learn how to build your first full HTML page with Astro.
+An Astro component represents some snippet of HTML in your project. This can be a reusable component, or an entire page of HTML including `<html>`, `<head>` and `<body>` elements. See our guide on [Astro Pages](/en/core-concepts/astro-pages) to learn how to build your first full HTML page with Astro.
 
 **Every Astro component must include an HTML template.** While you can enhance your component in several ways (see below), at the end of the day it's the HTML template that dictates what your rendered Astro component will look like.
 
@@ -68,13 +68,13 @@ Using `<style global>` will skip automatic scoping for every CSS rule in the `<s
 
 Sass (an alternative to CSS) is also available via `<style lang="scss">`.
 
-📚 Read our full guide on [Component Styling](/guides/styling) to learn more.
+📚 Read our full guide on [Component Styling](/en/guides/styling) to learn more.
 
 ### Frontmatter Script
 
 To build dynamic components, we introduce the idea of a frontmatter component script. [Frontmatter](https://jekyllrb.com/docs/front-matter/) is a common pattern in Markdown, where some config/metadata is contained inside a code fence (`---`) at the top of the file. Astro does something similar, but with full support for JavaScript & TypeScript in your components.
 
-Remember that Astro is a server-side templating language, so your component script will run during the build but only the HTML is rendered to the browser. To send JavaScript to the browser, you can use a `<script>` tag in your HTML template or [convert your component to use a frontend framework](/core-concepts/component-hydration) like React, Svelte, Vue, etc.
+Remember that Astro is a server-side templating language, so your component script will run during the build but only the HTML is rendered to the browser. To send JavaScript to the browser, you can use a `<script>` tag in your HTML template or [convert your component to use a frontend framework](/en/core-concepts/component-hydration) like React, Svelte, Vue, etc.
 
 ```astro
 ---
@@ -109,7 +109,7 @@ import SomeComponent from './SomeComponent.astro';
 </div>
 ```
 
-📚 You can also import and use components from other frontend frameworks like React, Svelte, and Vue. Read our guide on [Component Hydration](/core-concepts/component-hydration) to learn more.
+📚 You can also import and use components from other frontend frameworks like React, Svelte, and Vue. Read our guide on [Component Hydration](/en/core-concepts/component-hydration) to learn more.
 
 ### Dynamic JSX Expressions
 

docs/src/pages/en/core-concepts/astro-pages.md

@@ -4,9 +4,9 @@ title: Pages
 description: An intro to Astro pages, components that function as full pages.
 ---
 
-**Pages** are a special type of [Astro Component](/core-concepts/astro-components) that handle routing, data loading, and templating for each page of your website. You can think of them like any other Astro component, just with extra responsibilities.
+**Pages** are a special type of [Astro Component](/en/core-concepts/astro-components) that handle routing, data loading, and templating for each page of your website. You can think of them like any other Astro component, just with extra responsibilities.
 
-Astro also supports Markdown for content-heavy pages, like blog posts and documentation. See [Markdown Content](/guides/markdown-content) for more information on writing pages with Markdown.
+Astro also supports Markdown for content-heavy pages, like blog posts and documentation. See [Markdown Content](/en/guides/markdown-content) for more information on writing pages with Markdown.
 
 ## File-based Routing
 
@@ -47,7 +47,7 @@ All Astro components are responsible for returning HTML. Astro Pages return HTML
 
 Astro pages can fetch data to help generate your pages. Astro provides two different tools to pages to help you do this: **fetch()** and **top-level await.**
 
-📚 Read our [full guide](/guides/data-fetching) on data-fetching to learn more.
+📚 Read our [full guide](/en/guides/data-fetching) on data-fetching to learn more.
 
 ```astro
 ---
@@ -62,5 +62,5 @@ console.log(data);
 
 ## Custom 404 Error Page
 
-For a custom 404 error page create a `404.astro` file in `/src/pages`. That builds to a `404.html` page. Most [deploy services](/guides/deploy) will find and use it.
+For a custom 404 error page create a `404.astro` file in `/src/pages`. That builds to a `404.html` page. Most [deploy services](/en/guides/deploy) will find and use it.
 This is special and different to the default behavior building `page.astro` (or `page/index.astro`) to `page/index.html`.

docs/src/pages/en/core-concepts/component-hydration.md

@@ -89,7 +89,7 @@ Start importing the component JS as soon as the browser matches the given media
 
 Start importing the component JS at page load and hydrate when the import completes, similar to `client:load`. The component will be **skipped** at build time, useful for components that are entirely dependent on client-side APIs. This is best avoided unless absolutely needed, in most cases it is best to render placeholder content on the server and delay any browser API calls until the component hydrates in the browser.
 
-If more than one renderer is included in the Astro [config](/reference/configuration-reference), `client:only` needs a hint to know which renderer to use for the component. For example, `client:only="react"` would make sure that the component is hydrated in the browser with the React renderer. For custom renderers not provided by `@astrojs`, use the full name of the renderer provided in your Astro config, i.e. `<client:only="my-custom-renderer" />`.
+If more than one renderer is included in the Astro [config](/en/reference/configuration-reference), `client:only` needs a hint to know which renderer to use for the component. For example, `client:only="react"` would make sure that the component is hydrated in the browser with the React renderer. For custom renderers not provided by `@astrojs`, use the full name of the renderer provided in your Astro config, i.e. `<client:only="my-custom-renderer" />`.
 
 ## Can I Hydrate Astro Components?
 

docs/src/pages/en/core-concepts/layouts.md

@@ -4,7 +4,7 @@ title: Layouts
 description: An intro to layouts, a type of Astro component that is shared between pages for common layouts.
 ---
 
-**Layouts** are a special type of [Component](/core-concepts/astro-components) that help you share and reuse common page layouts within your project.
+**Layouts** are a special type of [Component](/en/core-concepts/astro-components) that help you share and reuse common page layouts within your project.
 
 Layouts are just like any other reusable Astro component. There's no new syntax or APIs to learn. However, reusable page layouts are such a common pattern in web development that we created this guide to help you use them.
 
@@ -40,7 +40,7 @@ const {title} = Astro.props;
 </html>
 ```
 
-📚 The `<slot />` element lets Astro components define where any children elements (passed to the layout) should go. Learn more about how `<slot/>` works in our [Astro Component guide.](/core-concepts/astro-components)
+📚 The `<slot />` element lets Astro components define where any children elements (passed to the layout) should go. Learn more about how `<slot/>` works in our [Astro Component guide.](/en/core-concepts/astro-components)
 
 Once you have your first layout, you can use it like you would any other component on your page. Remember that your layout contains your page `<html>`, `<head>`, and `<body>`. You only need to provide the custom page content.
 
@@ -152,4 +152,4 @@ const { content } = Astro.props;
 </html>
 ```
 
-📚 Learn more about Astro's markdown support in our [Markdown guide](/guides/markdown-content).
+📚 Learn more about Astro's markdown support in our [Markdown guide](/en/guides/markdown-content).

docs/src/pages/en/core-concepts/project-structure.md

@@ -10,7 +10,7 @@ Astro includes an opinionated folder layout for your project. Every Astro projec
 - `public/*` - Your non-code assets (fonts, icons, etc.)
 - `package.json` - A project manifest.
 
-The easiest way to set up your new project is with `npm init astro`. Check out our [Installation Guide](/quick-start) for a walkthrough of how to set up your project automatically (with `npm init astro`) or manually.
+The easiest way to set up your new project is with `npm init astro`. Check out our [Installation Guide](/en/quick-start) for a walkthrough of how to set up your project automatically (with `npm init astro`) or manually.
 
 ## Project Structure
 
@@ -28,28 +28,28 @@ The easiest way to set up your new project is with `npm init astro`. Check out o
 
 The src folder is where most of your project source code lives. This includes:
 
-- [Astro Components](/core-concepts/astro-components)
-- [Pages](/core-concepts/astro-pages)
-- [Layouts](/core-concepts/layouts)
-- [Frontend JS Components](/core-concepts/component-hydration)
-- [Styling (CSS, Sass)](/guides/styling)
-- [Markdown](/guides/markdown-content)
+- [Astro Components](/en/core-concepts/astro-components)
+- [Pages](/en/core-concepts/astro-pages)
+- [Layouts](/en/core-concepts/layouts)
+- [Frontend JS Components](/en/core-concepts/component-hydration)
+- [Styling (CSS, Sass)](/en/guides/styling)
+- [Markdown](/en/guides/markdown-content)
 
 Astro has complete control over how these files get processed, optimized, and bundled in your final site build. Some files (like Astro components) never make it to the browser directly and are instead rendered to HTML. Other files (like CSS) are sent to the browser but may be bundled with other CSS files depending on how your site uses them.
 
 ### `src/components`
 
-[Components](/core-concepts/astro-components) are reusable units of UI for your HTML pages. It is recommended (but not required) that you put your components in this directory. How you organize them within this directory is up to you.
+[Components](/en/core-concepts/astro-components) are reusable units of UI for your HTML pages. It is recommended (but not required) that you put your components in this directory. How you organize them within this directory is up to you.
 
 Your non-Astro UI components (React, Preact, Svelte, Vue, etc.) can also live in the `src/components` directory. Astro will automatically render all components to HTML unless you've enabled a frontend component via partial hydration.
 
 ### `src/layouts`
 
-[Layouts](/core-concepts/layouts) are reusable components for HTML page layouts. It is recommended (but not required) that you put your layout components in this directory. How you organize them within this directory is up to you.
+[Layouts](/en/core-concepts/layouts) are reusable components for HTML page layouts. It is recommended (but not required) that you put your layout components in this directory. How you organize them within this directory is up to you.
 
 ### `src/pages`
 
-[Pages](/core-concepts/astro-pages) contain all pages (`.astro` and `.md` supported) for your website. It is **required** that you put your pages in this directory.
+[Pages](/en/core-concepts/astro-pages) contain all pages (`.astro` and `.md` supported) for your website. It is **required** that you put your pages in this directory.
 
 ### `public/`
 

docs/src/pages/en/core-concepts/routing.md

@@ -23,7 +23,7 @@ src/pages/posts/1.md         -> mysite.com/posts/1
 
 Sometimes, you need to generate many URLs from a single page component. Astro uses file-based routing to support **dynamic route parameters** in the filename, so that one page can match many dynamic routes based on some pattern.
 
-An important thing to keep in mind: Astro is a static site builder. There is no Astro server to run in production, which means that every page must be built ahead of time. Pages that use dynamic routes must export a `getStaticPaths()` function which will tell Astro exactly what pages to generate. Learn more by viewing the complete [API Reference](/reference/api-reference#getstaticpaths).
+An important thing to keep in mind: Astro is a static site builder. There is no Astro server to run in production, which means that every page must be built ahead of time. Pages that use dynamic routes must export a `getStaticPaths()` function which will tell Astro exactly what pages to generate. Learn more by viewing the complete [API Reference](/en/reference/api-reference#getstaticpaths).
 
 ### Named parameters
 

docs/src/pages/en/getting-started.md

@@ -10,9 +10,9 @@ Astro is a modern static site builder. Learn what Astro is all about from [our h
 
 The easiest way to try Astro is to run `npm init astro` in a new directory on your machine. Our CLI wizard will assist you in starting a new Astro project.
 
-To get started with Astro in 5 quick and easy steps, visit our [Quick-Start guide](/quick-start).
+To get started with Astro in 5 quick and easy steps, visit our [Quick-Start guide](/en/quick-start).
 
-Alternatively, read our [Installation Guide](/installation) for a full walk-through on getting set up with Astro.
+Alternatively, read our [Installation Guide](/en/installation) for a full walk-through on getting set up with Astro.
 
 ### Example Projects
 
@@ -39,7 +39,7 @@ You can try Astro in online code editors like Stackblitz, CodeSandbox, Gitpod, a
 All manner of people come to Astro from different backgrounds bringing with them different learning styles. Whether you prefer a more theoretical or a practical approach, we hope you'll find this section helpful.
 
 - If you prefer to **learn by doing**, start with our [examples library](https://github.com/withastro/astro/tree/main/examples).
-- If you prefer to **learn concepts step by step**, start with our [basic concepts and guides](/core-concepts/project-structure).
+- If you prefer to **learn concepts step by step**, start with our [basic concepts and guides](/en/core-concepts/project-structure).
 
 Like any unfamiliar technology, Astro comes with a slight learning curve. However, with practice and some patience, we know, you _will_ get the hang of it, in no time.
 
@@ -47,11 +47,11 @@ Like any unfamiliar technology, Astro comes with a slight learning curve. Howeve
 
 When you begin to learn Astro, you'll see many files using the `.astro` file extension. This is **Astro's Component Syntax**: a special HTML-like file format which Astro uses for templating. It was designed to feel familiar to anyone with HTML or JSX experience.
 
-Our helpful guide on [Astro components](/core-concepts/astro-components) introduces you to the Astro syntax, and is the best way to learn.
+Our helpful guide on [Astro components](/en/core-concepts/astro-components) introduces you to the Astro syntax, and is the best way to learn.
 
 ### API Reference
 
-This documentation section is useful when you want to learn more details about a particular Astro API. For example, [Configuration Reference](/reference/configuration-reference) lists all possible configuration options available to you. [Built-in Components Reference](/reference/builtin-components) lists all available core components, like `<Markdown />` and `<Code />`.
+This documentation section is useful when you want to learn more details about a particular Astro API. For example, [Configuration Reference](/en/reference/configuration-reference) lists all possible configuration options available to you. [Built-in Components Reference](/en/reference/builtin-components) lists all available core components, like `<Markdown />` and `<Code />`.
 
 ### Versioned Documentation
 

docs/src/pages/en/guides/debugging.md

@@ -4,4 +4,4 @@ title: Debugging
 description: Debug in Astro using the Debug component
 ---
 
-Astro runs on the server and logs directly to your terminal, so it can be difficult to debug values from Astro. Astro's built-in `<Debug>` component can help you inspect values inside your files on the clientside. Read more about the [built-in Debug Component](/reference/builtin-components#debug-).
+Astro runs on the server and logs directly to your terminal, so it can be difficult to debug values from Astro. Astro's built-in `<Debug>` component can help you inspect values inside your files on the clientside. Read more about the [built-in Debug Component](/en/reference/builtin-components#debug-).

docs/src/pages/en/guides/deploy.md

@@ -6,7 +6,7 @@ description: Multiple different methods to deploy a website with Astro.
 
 The following guides are based on some shared assumptions:
 
-- You are using the default build output location (`dist/`). This location [can be changed using the `dist` configuration option](/reference/configuration-reference).
+- You are using the default build output location (`dist/`). This location [can be changed using the `dist` configuration option](/en/reference/configuration-reference).
 - You are using npm. You can use equivalent commands to run the scripts if you are using Yarn or other package managers.
 - Astro is installed as a local dev dependency in your project, and you have set up the following npm scripts:
 

docs/src/pages/en/guides/imports.md

@@ -99,7 +99,7 @@ import txtReference from './words.txt'; // txt === '/src/words.txt'
 
 All other assets not explicitly mentioned above can be imported via ESM `import` and will return a URL reference to the final built asset. This can be useful for referencing non-JS assets by URL, like creating an image element with a `src` attribute pointing to that image.
 
-It can also be useful to place images in the `public/`-folder as explained on the [project-structure page](/core-concepts/project-structure/#public).
+It can also be useful to place images in the `public/`-folder as explained on the [project-structure page](/en/core-concepts/project-structure/#public).
 
 ## WASM
 

docs/src/pages/en/guides/markdown-content.md

@@ -28,7 +28,7 @@ Astro comes with the `@astrojs/markdown-remark` package - the default parser.
 
 ### Remark and Rehype Plugins
 
-In addition to custom components inside the [`<Markdown>` component](/guides/markdown-content#astros-markdown-component), the default parser comes with these plugins pre-enabled:
+In addition to custom components inside the [`<Markdown>` component](/en/guides/markdown-content#astros-markdown-component), the default parser comes with these plugins pre-enabled:
 
 - [GitHub-flavored Markdown](https://github.com/remarkjs/remark-gfm)
 - [remark-smartypants](https://github.com/silvenon/remark-smartypants)
@@ -91,7 +91,7 @@ Astro treats any `.md` files inside of the `/src/pages` directory as pages. Thes
 
 ### Layouts
 
-Markdown pages have a special frontmatter property for `layout`. This defines the relative path to an `.astro` component which should wrap your Markdown content, for example a [Layout](/core-concepts/layouts) component. All other frontmatter properties defined in your `.md` page will be exposed to the component as properties of the `content` prop. The rendered Markdown content is placed into the default `<slot />` element.
+Markdown pages have a special frontmatter property for `layout`. This defines the relative path to an `.astro` component which should wrap your Markdown content, for example a [Layout](/en/core-concepts/layouts) component. All other frontmatter properties defined in your `.md` page will be exposed to the component as properties of the `content` prop. The rendered Markdown content is placed into the default `<slot />` element.
 
 ```markdown
 ---
@@ -155,9 +155,9 @@ For Markdown files, the `content` prop also has an `astro` property which holds
 
 Using images or videos follows Astro's normal import rules:
 
-- Place them in the `public/` as explained on the [project-structure page](/core-concepts/project-structure/#public)
+- Place them in the `public/` as explained on the [project-structure page](/en/core-concepts/project-structure/#public)
   - Example: Image is located at `/public/assets/img/astonaut.png` → Markdown: `![Astronaut](assets/img/astronaut.png)`
-- Or use `import` as explained on the [imports page](/guides/imports#other-assets) (when using Astro's Markdown Component)
+- Or use `import` as explained on the [imports page](/en/guides/imports#other-assets) (when using Astro's Markdown Component)
 
 ## Astro's Markdown Component
 

docs/src/pages/en/guides/pagination.md

@@ -10,9 +10,9 @@ Astro supports built-in, automatic pagination for large collections of data that
 
 Pagination is only useful when you need to generate multiple, numbered pages from a larger data set.
 
-If all of your data can fit on a single page then you should consider using a static [page component](/core-concepts/astro-pages) instead.
+If all of your data can fit on a single page then you should consider using a static [page component](/en/core-concepts/astro-pages) instead.
 
-If you need to split your data into multiple pages but do not want those page URLs to be numbered, then you should use a [dynamic page](/core-concepts/routing) instead without pagination (Example: `/tag/[tag].astro`).
+If you need to split your data into multiple pages but do not want those page URLs to be numbered, then you should use a [dynamic page](/en/core-concepts/routing) instead without pagination (Example: `/tag/[tag].astro`).
 
 ## How to use pagination
 
@@ -20,7 +20,7 @@ If you need to split your data into multiple pages but do not want those page UR
 
 To automatically paginate some data, you'll first need to create your page component. This is the component `.astro` file that every page in the paginated collection will inherit from.
 
-Pagination is built on top of dynamic page routing, with the page number in the URL represented as a dynamic route param: `[page].astro` or `[...page].astro`. If you aren't familiar with routing in Astro, quickly familiarize yourself with our [Routing documentation](/core-concepts/routing) before continuing.
+Pagination is built on top of dynamic page routing, with the page number in the URL represented as a dynamic route param: `[page].astro` or `[...page].astro`. If you aren't familiar with routing in Astro, quickly familiarize yourself with our [Routing documentation](/en/core-concepts/routing) before continuing.
 
 Your first page URL will be different depending on which type of query param you use:
 
@@ -29,7 +29,7 @@ Your first page URL will be different depending on which type of query param you
 
 ### calling the `paginate()` function
 
-Once you have decided on the file name/path for your page component, you'll need to export a [`getStaticPaths()`](/reference/api-reference#getstaticpaths) function from the component. `getStaticPaths()` is where you tell Astro what pages to generate.
+Once you have decided on the file name/path for your page component, you'll need to export a [`getStaticPaths()`](/en/reference/api-reference#getstaticpaths) function from the component. `getStaticPaths()` is where you tell Astro what pages to generate.
 
 `getStaticPaths()` provides the `paginate()` function that we'll use to paginate your data. In the example below, we'll use `paginate()` to split a list of 150 Pokemon into 15 pages of 10 Pokemon each.
 
@@ -71,7 +71,7 @@ The `page` prop has several useful properties, but the most important one is `pa
 - `/3`: `page.data` would be an array of Pokemon 21-30
 - etc. etc.
 
-The `page` prop includes other helpful metadata, like `page.url.next`, `page.url.prev`, `page.total`, and more. See our [API reference](/reference/api-reference#the-pagination-page-prop) for the full `page` interface.
+The `page` prop includes other helpful metadata, like `page.url.next`, `page.url.prev`, `page.total`, and more. See our [API reference](/en/reference/api-reference#the-pagination-page-prop) for the full `page` interface.
 
 ## Nested pagination
 

docs/src/pages/en/guides/rss.md

@@ -6,9 +6,9 @@ description: An intro to RSS in Astro
 
 Astro supports fast, automatic RSS feed generation for blogs and other content websites.
 
-You can create an RSS feed from any Astro page that uses a `getStaticPaths()` function for routing. Only dynamic routes can use `getStaticPaths()` today (see [Routing](/core-concepts/routing)).
+You can create an RSS feed from any Astro page that uses a `getStaticPaths()` function for routing. Only dynamic routes can use `getStaticPaths()` today (see [Routing](/en/core-concepts/routing)).
 
-> We hope to make this feature available to all other pages before v1.0. As a workaround, you can convert a static route to a dynamic route that only generates a single page. See [Routing](/core-concepts/routing) for more information about dynamic routes.
+> We hope to make this feature available to all other pages before v1.0. As a workaround, you can convert a static route to a dynamic route that only generates a single page. See [Routing](/en/core-concepts/routing) for more information about dynamic routes.
 
 Create an RSS Feed by calling the `rss()` function that is passed as an argument to `getStaticPaths()`. This will create an `rss.xml` file in your final build based on the data that you provide using the `items` array.
 

docs/src/pages/en/guides/styling.md

@@ -280,7 +280,7 @@ _Note: be mindful when some page styles get extracted to the "common" bundle, an
 
 Too many development setups take a hands-off approach to CSS, or at most leave you with only contrived examples that don't get you very far. Telling developers "Use whatever styling solution you want!" is a nice thought that rarely works out in practice. Few styling approaches lend themselves to every setup. Astro is no different—certain styling approaches _will_ work better than others.
 
-An example to illustrate this: Astro removes runtime JS (even the core framework if possible). Thus, depending on Styled Components for all your styles would be bad, as that would require React to load on pages where it's not needed. Or at best, you'd get a "[FOUC][fouc]" as your static HTML is served but the user waits for JavaScript to download and execute. Or consider a second example at the opposite end of the spectrum: _BEM_. You _can_ use a completely-decoupled [BEM][bem] or [SMACSS][smacss] approach in Astro. But that's a lot of manual maintenance you can avoid, and it leaves out a lot of convenience of [Astro components](/core-concepts/astro-components).
+An example to illustrate this: Astro removes runtime JS (even the core framework if possible). Thus, depending on Styled Components for all your styles would be bad, as that would require React to load on pages where it's not needed. Or at best, you'd get a "[FOUC][fouc]" as your static HTML is served but the user waits for JavaScript to download and execute. Or consider a second example at the opposite end of the spectrum: _BEM_. You _can_ use a completely-decoupled [BEM][bem] or [SMACSS][smacss] approach in Astro. But that's a lot of manual maintenance you can avoid, and it leaves out a lot of convenience of [Astro components](/en/core-concepts/astro-components).
 
 We think there's a great middle ground between intuitive-but-slow CSS-in-JS and fast-but-cumbersome global CSS: **Hybrid Scoped + Utility CSS**. This approach works well in Astro, is performant for users, and will be the best styling solution in Astro _for most people_ (provided you're willing to learn a little). So as a quick recap:
 
@@ -605,8 +605,8 @@ This guide wouldn't be possible without the following blog posts, which expand o
 Also please check out the [Stylelint][stylelint] project to whip your styles into shape. You lint your JS, why not your CSS?
 
 [autoprefixer]: https://github.com/postcss/autoprefixer
-[astro-component]: /core-concepts/astro-components#css-styles
-[astro-resolve]: /reference/api-reference#astroresolve
+[astro-component]: /en/core-concepts/astro-components#css-styles
+[astro-resolve]: /en/reference/api-reference#astroresolve
 [bem]: http://getbem.com/introduction/
 [box-model]: https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model
 [browserslist]: https://github.com/browserslist/browserslist

docs/src/pages/en/installation.md

@@ -54,7 +54,7 @@ After `create-astro` scaffolds out your project, remember to install your projec
 npm install
 ```
 
-You can now [Start](#start-astro) your Astro project. Once you have completed assembling your Astro project you can then [Build](#build-astro) your project. Astro would then package up your application and have the static files ready for you to [Deploy](/guides/deploy) to your favourite hosting provider.
+You can now [Start](#start-astro) your Astro project. Once you have completed assembling your Astro project you can then [Build](#build-astro) your project. Astro would then package up your application and have the static files ready for you to [Deploy](/en/guides/deploy) to your favourite hosting provider.
 
 ## Manual Install
 
@@ -99,7 +99,7 @@ You can now replace the placeholder "scripts" section of your `package.json` fil
 }
 ```
 
-The [`dev`](#start-astro) command launches the Astro Dev Server on `http://localhost:3000`. Once your project is ready, the [`build`](#build-astro) command outputs your project to the `dist/` directory. [Read more about deploying Astro in the Deploy guide.](/guides/deploy)
+The [`dev`](#start-astro) command launches the Astro Dev Server on `http://localhost:3000`. Once your project is ready, the [`build`](#build-astro) command outputs your project to the `dist/` directory. [Read more about deploying Astro in the Deploy guide.](/en/guides/deploy)
 
 ### Create your first page
 
@@ -169,8 +169,8 @@ Success! You're now ready to start developing!
 
 We highly encourage you to get more familiar with the way Astro works. You can do so by further exploring our Docs, we suggest that you consider the following:
 
-📚 Learn more about Astro's project structure in our [Project Structure guide.](/core-concepts/project-structure)
+📚 Learn more about Astro's project structure in our [Project Structure guide.](/en/core-concepts/project-structure)
 
-📚 Learn more about Astro's component syntax in our [Astro Components guide.](/core-concepts/astro-components)
+📚 Learn more about Astro's component syntax in our [Astro Components guide.](/en/core-concepts/astro-components)
 
-📚 Learn more about Astro's file-based routing in our [Routing guide.](core-concepts/astro-pages)
+📚 Learn more about Astro's file-based routing in our [Routing guide.](/en/core-concepts/astro-pages)

docs/src/pages/en/quick-start.md

@@ -28,7 +28,7 @@ For production sites,
 npm run build
 ```
 
-To learn more about installing and using Astro for the first time, please [read our installation guide.](/installation)
+To learn more about installing and using Astro for the first time, please [read our installation guide.](/en/installation)
 
 If you prefer to learn by example, check out our [complete library of examples](https://github.com/withastro/astro/tree/main/examples) on GitHub. You can check out any of these examples locally by running `npm init astro -- --template "EXAMPLE_NAME"`.
 
@@ -62,7 +62,7 @@ Astro sites are static, so they can be deployed to your favourite host:
 - [Google Firebase](https://firebase.google.com/)
 - [Netlify](https://www.netlify.com/)
 - [Vercel](https://vercel.com/)
-- [Read more about deploying Astro in our Deploy guide.](/guides/deploy)
+- [Read more about deploying Astro in our Deploy guide.](/en/guides/deploy)
 
 ## Next Steps
 
@@ -70,8 +70,8 @@ Success! You're now ready to start developing!
 
 We recommend that you to take some time to get more familiar with the way Astro works. You can do so by further exploring our Docs, we suggest that you consider the following:
 
-📚 Learn more about Astro's project structure in our [Project Structure guide.](/core-concepts/project-structure)
+📚 Learn more about Astro's project structure in our [Project Structure guide.](/en/core-concepts/project-structure)
 
-📚 Learn more about Astro's component syntax in our [Astro Components guide.](/core-concepts/astro-components)
+📚 Learn more about Astro's component syntax in our [Astro Components guide.](/en/core-concepts/astro-components)
 
-📚 Learn more about Astro's file-based routing in our [Routing guide.](/core-concepts/astro-pages)
+📚 Learn more about Astro's file-based routing in our [Routing guide.](/en/core-concepts/astro-pages)

docs/src/pages/en/reference/builtin-components.md

@@ -34,7 +34,7 @@ import { Markdown } from 'astro/components';
 </Markdown>
 ```
 
-See our [Markdown Guide](/guides/markdown-content) for more info.
+See our [Markdown Guide](/en/guides/markdown-content) for more info.
 
 <!-- TODO: We should move some of the specific component info here. -->
 

docs/src/pages/en/reference/cli-reference.md

@@ -7,7 +7,7 @@ title: CLI Reference
 
 ### `astro dev`
 
-Runs the Astro development server. This starts an HTTP server that responds to requests for pages stored in `src/pages` (or which folder is specified in your [configuration](/reference/configuration-reference)).
+Runs the Astro development server. This starts an HTTP server that responds to requests for pages stored in `src/pages` (or which folder is specified in your [configuration](/en/reference/configuration-reference)).
 
 **Flags**
 
@@ -23,7 +23,7 @@ Builds your site for production.
 
 Start a local static file server to serve your built `dist/` directory. Useful for previewing your static build locally, before deploying it.
 
-This command is meant for local testing only, and is not designed to be run in production. For help with production hosting, check out our guide on [Deploying an Astro Website](/guides/deploy).
+This command is meant for local testing only, and is not designed to be run in production. For help with production hosting, check out our guide on [Deploying an Astro Website](/en/guides/deploy).
 
 ### `astro check`
 

docs/src/pages/en/themes.astro

@@ -1,9 +1,9 @@
 ---
-import Layout from '../layouts/MainLayout.astro';
-import Card from '../components/Card.astro';
+import Layout from '../../layouts/MainLayout.astro';
+import Card from '../../components/Card.astro';
 import { Markdown } from 'astro/components';
-import themes from '../data/themes.json';
-import components from '../data/components.json';
+import themes from '../../data/themes.json';
+import components from '../../data/components.json';
 ---
 
 <Layout content={{ title: 'Themes' }} hideRightSidebar>

docs/src/pages/es/core-concepts/astro-components.md

@@ -27,7 +27,7 @@ Por ejemplo, este archivo de tres líneas es un componente Astro válido:
 </div>
 ```
 
-Un componente Astro representa un fragmento de HTML en tu proyecto. Puede ser un componente reutilizable o una página completa de HTML que incluya elementos `<html>`, `<head>` y `<body>`. Consulta nuestra guía sobre [Páginas de Astro](/es/core-concept/astro-pages) para aprender a crear tu primera página HTML completa con Astro.
+Un componente Astro representa un fragmento de HTML en tu proyecto. Puede ser un componente reutilizable o una página completa de HTML que incluya elementos `<html>`, `<head>` y `<body>`. Consulta nuestra guía sobre [Páginas de Astro](/es/core-concepts/astro-pages) para aprender a crear tu primera página HTML completa con Astro.
 
 **Cada componente de Astro debe incluir una plantilla HTML.** Aunque puede mejorar su componente de varias maneras (ver más abajo), al fin y al cabo es la plantilla HTML la que dicta cómo se verá tu componente Astro renderizado.
 
@@ -74,7 +74,7 @@ Sass (una alternativa a CSS) está también disponible mediante `<style lang="sc
 
 Para construir componentes dinámicos, presentamos la idea de un script preliminar del componente. [Frontmatter](https://jekyllrb.com/docs/front-matter/) es un patrón común en Markdown, donde algunos config/metadata están contenidos dentro de una valla de código (`---`) en la parte superior del archivo . Astro hace algo similar, pero con soporte completo para JavaScript y TypeScript en sus componentes.
 
-Recuerda que Astro es un lenguaje de plantillas del lado del servidor, por lo que el script de su componente se ejecutará durante la compilación, pero solo el HTML se representará en el navegador. Para enviar JavaScript al navegador, puedes usar una etiqueta `<script>` en su plantilla HTML o [convertir tu componente para usar un framework de frontend](/es/core-concept/component-hydration) como React, Svelte, Vue, etc.
+Recuerda que Astro es un lenguaje de plantillas del lado del servidor, por lo que el script de su componente se ejecutará durante la compilación, pero solo el HTML se representará en el navegador. Para enviar JavaScript al navegador, puedes usar una etiqueta `<script>` en su plantilla HTML o [convertir tu componente para usar un framework de frontend](/es/core-concepts/component-hydration) como React, Svelte, Vue, etc.
 
 ```astro
 ---
@@ -109,7 +109,7 @@ import AlgunComponente from './AlgunComponente.astro';
 </div>
 ```
 
-📚 También puedes importar y usar componentes de otros frameworks frontend como React, Svelte y Vue. Lee nuestra guía sobre [Hidratación de componentes](/es/core-concept/component-hydration) para obtener más información.
+📚 También puedes importar y usar componentes de otros frameworks frontend como React, Svelte y Vue. Lee nuestra guía sobre [Hidratación de componentes](/es/core-concepts/component-hydration) para obtener más información.
 
 ### Expresiones JSX dinámicas
 

docs/src/pages/es/core-concepts/layouts.md

@@ -4,7 +4,7 @@ title: Maquetas
 lang: es
 ---
 
-**Las maquetas** son un tipo especial de [Componente](/es/core-concept/astro-components) que te ayudan a compartir y reutilizar maquetas de página comunes dentro de tu proyecto.
+**Las maquetas** son un tipo especial de [Componente](/es/core-concepts/astro-components) que te ayudan a compartir y reutilizar maquetas de página comunes dentro de tu proyecto.
 
 Las maquetas son como cualquier otro componente de Astro reutilizable. No hay una nueva sintaxis o API que aprender. Sin embargo, las maquetas de página reutilizables son un patrón tan común en el desarrollo web que creamos esta guía para ayudarte a usarlos.
 

docs/src/pages/es/core-concepts/project-structure.md

@@ -10,7 +10,7 @@ Astro incluye un diseño de carpeta dogmático para tu proyecto. Cada proyecto d
 - `public/*` - Tus activos sin código (tipografías, iconos, etc.)
 - `package.json` - Un manifiesto de proyecto.
 
-La forma más sencilla de configurar tu nuevo proyecto es con `npm init astro`. Consulta nuestra [Guía de instalación](/quick-start) para obtener un tutorial sobre cómo configurar tu proyecto automáticamente (con `npm init astro`) o manualmente.
+La forma más sencilla de configurar tu nuevo proyecto es con `npm init astro`. Consulta nuestra [Guía de instalación](/es/quick-start) para obtener un tutorial sobre cómo configurar tu proyecto automáticamente (con `npm init astro`) o manualmente.
 
 ## Estructura del proyecto
 

docs/src/pages/es/guides/data-fetching.md

@@ -56,7 +56,7 @@ const Movies: FunctionalComponent = () => {
 export default Movies;
 ```
 
-Si cargas un componente usando `node-fetch` [interactivamente](/es/core-concept/component-hydration), con `client:load`, `client:visible`, etc., necesitarás no usar `node-fetch` o cambiar a una librería [isomórfica](https://en.wikipedia.org/wiki/Isomorphic_JavaScript) que se ejecutará tanto en el momento de la compilación como en el cliente, como [`node-fetch` README.md](https://github.com/node-fetch/node-fetch#motivation) recomienda:
+Si cargas un componente usando `node-fetch` [interactivamente](/es/core-concepts/component-hydration), con `client:load`, `client:visible`, etc., necesitarás no usar `node-fetch` o cambiar a una librería [isomórfica](https://en.wikipedia.org/wiki/Isomorphic_JavaScript) que se ejecutará tanto en el momento de la compilación como en el cliente, como [`node-fetch` README.md](https://github.com/node-fetch/node-fetch#motivation) recomienda:
 
 > En lugar de implementar XMLHttpRequest en Node.js para ejecutar [Fetch polyfill] específico del navegador (https://github.com/github/fetch), ¿por qué no pasar de http nativo a buscar API directamente? Por lo tanto, node-fetch, código mínimo para una API compatible con window.fetch en tiempo de ejecución de Node.js.
 >

docs/src/pages/es/guides/imports.md

@@ -106,7 +106,7 @@ Todos los demás activos que no se mencionan explícitamente anteriormente se pu
 const wasm = await WebAssembly.instantiateStreaming(fetch('/example.wasm'));
 ```
 
-Astro admite la carga de archivos WASM directamente en tu aplicación utilizando la API [`WebAssembly`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly) del navegador. Lee nuestra [guía WASM](/es/guides/wasm) para obtener más información.
+Astro admite la carga de archivos WASM directamente en tu aplicación utilizando la API [`WebAssembly`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly) del navegador.
 
 ## Paquetes npm
 

docs/src/pages/es/guides/markdown-content.astro

@@ -1,7 +1,7 @@
 ---
 import { Markdown } from 'astro/components';
 import MainLayout from '~/layouts/MainLayout.astro';
-const [content] = Astro.fetchContent('/src/pages/guides/markdown-content.md');
+const [content] = Astro.fetchContent('/src/pages/en/guides/markdown-content.md');
 ---
 
 <MainLayout {content}>

docs/src/pages/es/guides/pagination.astro

@@ -1,7 +1,7 @@
 ---
 import { Markdown } from 'astro/components';
 import MainLayout from '~/layouts/MainLayout.astro';
-const [content] = Astro.fetchContent('/src/pages/guides/pagination.md');
+const [content] = Astro.fetchContent('/src/pages/en/guides/pagination.md');
 ---
 
 <MainLayout {content}>

docs/src/pages/es/guides/publish-to-npm.astro

@@ -1,7 +1,7 @@
 ---
 import { Markdown } from 'astro/components';
 import MainLayout from '~/layouts/MainLayout.astro';
-const [content] = Astro.fetchContent('/src/pages/guides/publish-to-npm.md');
+const [content] = Astro.fetchContent('/src/pages/en/guides/publish-to-npm.md');
 ---
 
 <MainLayout {content}>

docs/src/pages/es/guides/styling.astro

@@ -1,7 +1,7 @@
 ---
 import { Markdown } from 'astro/components';
 import MainLayout from '~/layouts/MainLayout.astro';
-const [content] = Astro.fetchContent('/src/pages/guides/styling.md');
+const [content] = Astro.fetchContent('/src/pages/en/guides/styling.md');
 ---
 
 <MainLayout {content}>

docs/src/pages/es/installation.md

@@ -26,7 +26,7 @@ npm init astro
 yarn create astro
 ```
 
-El asistente de instalación [`create-astro`](https://github.com/withastro/astro/tree/main/packages/create-astro), te permite escoger de una lista de [plantillas de inicio](/examples); por otro lado, puedes importar tus propios proyectos de Astro directamente desde GitHub.
+El asistente de instalación [`create-astro`](https://github.com/withastro/astro/tree/main/packages/create-astro), te permite escoger de una lista de [plantillas de inicio](/en/themes); por otro lado, puedes importar tus propios proyectos de Astro directamente desde GitHub.
 
 ```bash
 # Nota: Reemplaza "my-astro-project" con el nombre de tu proyecto.
@@ -162,10 +162,10 @@ Con esta instrucción Astro generará tu sitio web y lo guardará directamente e
 
 ¡Felicidades! ¡Ahora estás listo para comenzar a desarrollar!
 
-Te recomendamos fervientemente que te familiarices con la forma en que Astro funciona. Lo puedes hacer explorando nuestra [documentación](/docs/), te sugerimos que consideres las siguientes lecturas:
+Te recomendamos fervientemente que te familiarices con la forma en que Astro funciona. Lo puedes hacer explorando nuestra documentación, te sugerimos que consideres las siguientes lecturas:
 
 📚 Aprende más sobre la estructura de proyectos de Astro, en nuestra [guía de estructura de proyecto](/es/core-concepts/project-structure).
 
 📚 Aprende más sobre la sintaxis de los componentes de Astro, en nuestra [guía de componentes de Astro](/es/core-concepts/astro-components).
 
-📚 Aprende más sobre la rutas basada en archivos de Astro, en nuestra [guía de rutas](core-concepts/astro-pages).
+📚 Aprende más sobre la rutas basada en archivos de Astro, en nuestra [guía de rutas](/es/core-concepts/astro-pages).

docs/src/pages/es/reference/renderer-reference.astro

@@ -2,7 +2,7 @@
 import { Markdown } from 'astro/components';
 import MainLayout from '~/layouts/MainLayout.astro';
 const [content] = Astro.fetchContent(
-	'/src/pages/reference/renderer-reference.md'
+	'/src/pages/en/reference/renderer-reference.md'
 );
 ---
 

docs/src/pages/index.astro

@@ -2,6 +2,7 @@
 import Layout from '../layouts/MainLayout.astro';
 ---
 
+<meta http-equiv="refresh" content="5;url=/en/getting-started">
 <script>
 	// WIP: trigger a client-side redirect based on the browser language.
 	// A vercel.json redirect is enforced in production, so no user should ever see this page.
@@ -27,13 +28,11 @@ import Layout from '../layouts/MainLayout.astro';
 		'en-US'
 	).substr(0, 5);
 	let newLang = newLangWithRegion.substr(0, 2);
-	if (newLang === 'en') {
-		window.location.pathname = '/getting-started';
-	} else if (KNOWN_LANGUAGES.includes(newLangWithRegion)) {
+	if (KNOWN_LANGUAGES.includes(newLangWithRegion)) {
 		window.location.pathname = '/' + newLangWithRegion + '/getting-started';
 	} else if (KNOWN_LANGUAGES.includes(newLang)) {
 		window.location.pathname = '/' + newLang + '/getting-started';
 	} else {
-		window.location.pathname = '/getting-started';
+		window.location.pathname = '/en/getting-started';
 	}
 </script>

docs/vercel.json

@@ -1,4 +0,0 @@
-{
-  "cleanUrls": true,
-  "trailingSlash": false
-}