Remove docs from monorepo (#2517)

* Remove docs from monorepo * Update PULL_REQUEST_TEMPLATE.md * Update relative doc references with links or todo
2022-02-07 13:39:53 -05:00 · 2022-02-07 13:39:53 -05:00 · a911d14eab
commit a911d14eab
parent 2bc91543ce
158 changed files with 20 additions and 15509 deletions
--- a/.changeset/pre.json
+++ b/.changeset/pre.json
@ -2,7 +2,6 @@
  "mode": "pre",
  "tag": "next",
  "initialVersions": {
-    "docs": "0.0.7",
    "@example/blog": "0.0.1",
    "@example/blog-multiple-authors": "0.0.1",
    "@example/component": "0.0.1",
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@ -11,5 +11,6 @@

 ## Docs

-<!-- Was public documentation updated? -->
-<!-- DON'T DELETE THIS SECTION! If no docs added, explain why (e.g. "bug fix only") -->
+<!-- Did you make a user-facing change? You probably need to update docs! -->
+<!-- Add a link to your docs PR here. If no docs added, explain why (e.g. "bug fix only") -->
+<!-- Link: https://github.com/withastro/docs -->
--- a/.github/labeler.yml
+++ b/.github/labeler.yml
@ -6,20 +6,9 @@ example:
 '🚨 action':
 - .github/workflows/**

-docs:
- docs/**
-
 test:
 - packages/**/*.test.js

-i18n:
- any:
-  - 'docs/src/pages/*/**'
-  - '!docs/src/pages/core-concepts/**'
-  - '!docs/src/pages/guides/**'
-  - '!docs/src/pages/migration/**'
-  - '!docs/src/pages/reference/**'
-
 core:
 - packages/astro/**

--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@ -7,7 +7,6 @@ on:
  pull_request:
    paths-ignore:
      - '.vscode/**'
-      - 'docs/**'
      - 'examples/**'

 # Automatically cancel in-progress actions on the same branch
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@ -17,7 +17,7 @@ yarn: "^1.22.10"

 ### Setting up your local repo

-Astro uses yarn workspaces, so you should **always run `yarn install` from the top-level project directory.** running `yarn install` in the top-level project root will install dependencies for `astro`, `docs`, and every package in the repo.
+Astro uses yarn workspaces, so you should **always run `yarn install` from the top-level project directory.** running `yarn install` in the top-level project root will install dependencies for `astro`, and every package in the repo.

 ```shell
 git clone && cd ...
@ -76,7 +76,7 @@ yarn lint

 ### Making a Pull Request

-When making a pull request, be sure to add a changeset when something has changed with Astro. Non-packages (`examples/*`, `docs/*`) do not need changesets.
+When making a pull request, be sure to add a changeset when something has changed with Astro. Non-packages (`examples/*`) do not need changesets.

 ```shell
 yarn changeset
@ -145,7 +145,7 @@ To release a snapshot, run the following locally:
 # 1:
 yarn changeset version --snapshot XXX
 # 2: (Manual) review the diff, and make sure that you're not releasing more than you need to.
-git checkout -- examples/ docs/
+git checkout -- examples/
 # 3:
 yarn release --tag next--XXX
 # 4: (Manual) review the publish, and if you're happy then you can throw out all local changes
@ -192,7 +192,7 @@ When in prerelease mode, the automatic PR release process will no longer release
 1. Run `yarn changeset version` to create your new release.
 1. Run `yarn release` to publish your new release.
 1. Run `git push && git push --tags` to push your new release to GitHub.
-1. Run `git push release/0.X:latest` to push your release branch to `latest`. This will trigger an update to the docs site, etc.
+1. Run `git push release/0.X:latest` to push your release branch to `latest`. 
 1. Go to https://github.com/withastro/astro/releases/new and create a new release. Copy the new changelog entry from https://github.com/withastro/astro/blob/latest/packages/astro/CHANGELOG.md.
 1. Post in Discord #announcements channel, if needed!

--- a/docs/.nvmrc
+++ b/docs/.nvmrc
@ -1 +0,0 @@
-14.18.1
--- a/docs/.prettierignore
+++ b/docs/.prettierignore
@ -1,2 +0,0 @@
-node_modules
-dist
--- a/docs/.prettierrc
+++ b/docs/.prettierrc
@ -1,7 +0,0 @@
-{
-  "singleQuote": true,
-  "tabWidth": 2,
-  "endOfLine": "auto",
-  "trailingComma": "es5",
-  "printWidth": 80
-}
--- a/docs/.stackblitzrc
+++ b/docs/.stackblitzrc
@ -1,6 +0,0 @@
-{
-  "startCommand": "npm start",
-  "env": {
-    "ENABLE_CJS_IMPORTS": true
-  }
-}
--- a/docs/CHANGELOG.md
+++ b/docs/CHANGELOG.md
@ -1,55 +0,0 @@
-# docs
-
-## 0.0.7
-
-### Patch Changes
-
- 6b8630c6: Github pages disclaimer
-
-## 0.0.6
-
-### Patch Changes
-
- 788c769d: # Hoisted scripts
-
-  This change adds support for hoisted scripts, allowing you to bundle scripts together for a page and hoist them to the top (in the head):
-
-  ```astro
-  <script hoist>
-    // Anything goes here!
-  </script>
-  ```
-
-## 0.0.5
-
-## 0.0.5-next.0
-
-### Patch Changes
-
- 78b5bde1: Adds support for Astro.resolve
-
-  `Astro.resolve()` helps with creating URLs relative to the current Astro file, allowing you to reference files within your `src/` folder.
-
-  Astro _does not_ resolve relative links within HTML, such as images:
-
-  ```html
-  <img src="../images/penguin.png" />
-  ```
-
-  The above will be sent to the browser as-is and the browser will resolve it relative to the current **page**. If you want it to be resolved relative to the .astro file you are working in, use `Astro.resolve`:
-
-  ```astro
-  <img src={Astro.resolve('../images/penguin.png')} />
-  ```
-
-## 0.0.4
-
-### Patch Changes
-
- adc767c5: change Spanish translations for Getting Started page
-
-## 0.0.3
-
-### Patch Changes
-
- 70f0a09: Added remark-slug to default plugins
--- a/docs/README.md
+++ b/docs/README.md
@ -1,24 +1,3 @@
-# Astro Docs <img width="19.2" height="25.6" src="https://raw.githubusercontent.com/withastro/astro/main/assets/brand/logo.svg" alt="Astro logo">
+# Astro Docs

-## Contributing
-
-### Pull Requests
-
-Every pull request needs to be reviewed by another contributor to the documentation to help with the overall quality of the documentation.
-
-## Running this project
-
- Clone the Project
-
-  `git clone git@github.com:withastro/astro.git`
- Run `yarn install` to install latest dependencies.
-  > This project uses yarn to manage dependencies. [Make sure that you have yarn v1 installed.](https://classic.yarnpkg.com/)
- Run `yarn workspace docs dev` to start the dev server.
- Run `yarn workspace docs build` to build the final site for production.
-  > The environment variable `SNOWPACK_PUBLIC_GITHUB_TOKEN` must be set to a personal access token with `public_repo` permissions to prevent rate-limiting.
-
-## Deploying
-
-The site is automatically deployed when commits land in `latest`, via Netlify.
-
-The "next" docs are automatically deployed when commits land in `main`, via Netlify at <https://main--astro-docs-2.netlify.app/getting-started/>.
+**⚠️ The Astro docs are now managed at https://github.com/withastro/docs ⚠️**
--- a/docs/astro.config.mjs
+++ b/docs/astro.config.mjs
@ -1,12 +0,0 @@
-// @ts-check
-export default /** @type {import('astro').AstroUserConfig} */ ({
-	buildOptions: {
-		site: 'https://docs.astro.build/',
-	},
-	renderers: [
-		// Our main renderer for frontend components
-		'@astrojs/renderer-preact',
-		// Needed for Algolia search component
-		'@astrojs/renderer-react',
-	],
-});
--- a/docs/jsconfig.json
+++ b/docs/jsconfig.json
@ -1,8 +0,0 @@
-{
-  "compilerOptions": {
-    "baseUrl": ".",
-    "paths": {
-      "~/*": ["src/*"]
-    }
-  }
-}
--- a/docs/package.json
+++ b/docs/package.json
@ -1,32 +0,0 @@
-{
-  "name": "docs",
-  "version": "0.0.7",
-  "private": true,
-  "scripts": {
-    "dev": "astro dev",
-    "start": "astro dev",
-    "build": "astro build",
-    "preview": "astro preview",
-    "lint": "run-p --aggregate-output lint:linkcheck",
-    "lint:a11y": "start-test 'yarn build && yarn preview' 3000 'yarn lint:a11y:local'",
-    "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 -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": {
-    "astro": "^0.23.0-next.0",
-    "broken-link-checker": "^0.7.8",
-    "npm-run-all": "^4.1.5",
-    "pa11y-ci": "^3.0.1",
-    "prettier": "^2.4.1",
-    "start-server-and-test": "^1.12.6"
-  },
-  "dependencies": {
-    "@docsearch/react": "^1.0.0-alpha.28"
-  },
-  "volta": {
-    "node": "14.18.1"
-  }
-}
--- a/docs/public/code.css
+++ b/docs/public/code.css
@ -1,101 +0,0 @@
-.language-css > code,
-.language-sass > code,
-.language-scss > code {
-	color: #fd9170;
-}
-
-.language-diff .token.prefix.deleted,
-.language-diff .token.prefix.inserted {
-	user-select: none;
-}
-
-[class*='language-'] .namespace {
-	opacity: 0.7;
-}
-
-.token.plain-text,
-[class*='language-bash'] span.token,
-[class*='language-shell'] span.token {
-	color: hsla(var(--color-gray-90), 1);
-}
-
-[class*='language-bash'] span.token,
-[class*='language-shell'] span.token {
-	font-style: bold;
-}
-
-.token.prolog,
-.token.comment,
-[class*='language-bash'] span.token.comment,
-[class*='language-shell'] span.token.comment {
-	color: hsla(var(--color-gray-70), 1);
-}
-
-.token.selector,
-.token.tag,
-.token.unit,
-.token.url,
-.token.variable,
-.token.entity,
-.token.deleted {
-	color: #fa5e5b;
-}
-
-.token.boolean,
-.token.constant,
-.token.doctype,
-.token.number,
-.token.regex,
-.token.builtin,
-.token.class,
-.token.hexcode,
-.token.class-name,
-.token.attr-name {
-	color: hsla(var(--color-yellow), 1);
-}
-
-.token.atrule,
-.token.attribute,
-.token.attr-value .token.punctuation,
-.token.attr-value,
-.token.pseudo-class,
-.token.pseudo-element,
-.token.string {
-	color: hsla(var(--color-green), 1);
-}
-
-.token.symbol,
-.token.function,
-.token.id,
-.token.important {
-	color: hsla(var(--color-blue), 1);
-}
-
-.token.important,
-.token.id {
-	font-weight: bold;
-}
-
-.token.cdata,
-.token.char,
-.token.property {
-	color: #23b1af;
-}
-
-.token.inserted {
-	color: hsla(var(--color-green), 1);
-}
-
-.token.keyword {
-	color: #ff657c;
-	font-style: italic;
-}
-
-.token.operator {
-	color: hsla(var(--color-gray-70), 1);
-}
-
-.token.attr-value .token.attr-equals,
-.token.punctuation {
-	color: hsla(var(--color-gray-80), 1);
-}
--- a/docs/public/default-og-image.png
+++ b/docs/public/default-og-image.png
--- a/docs/public/favicon.ico
+++ b/docs/public/favicon.ico
--- a/docs/public/favicon.svg
+++ b/docs/public/favicon.svg
@ -1,11 +0,0 @@
-<svg width="256" height="256" fill="none" xmlns="http://www.w3.org/2000/svg">
-    <style>
-        #flame { fill: #FF5D01; }
-        #a { fill: #000014; }
-        @media (prefers-color-scheme: dark) {
-            #a { fill: #fff; }
-        }
-    </style>
-    <path id="a" fill-rule="evenodd" clip-rule="evenodd" d="M163.008 18.929c1.944 2.413 2.935 5.67 4.917 12.181l43.309 142.27a180.277 180.277 0 00-51.778-17.53l-28.198-95.29a3.67 3.67 0 00-7.042.01l-27.857 95.232a180.225 180.225 0 00-52.01 17.557l43.52-142.281c1.99-6.502 2.983-9.752 4.927-12.16a15.999 15.999 0 016.484-4.798c2.872-1.154 6.271-1.154 13.07-1.154h31.085c6.807 0 10.211 0 13.086 1.157a16.004 16.004 0 016.487 4.806z" />
-    <path id="flame" fill-rule="evenodd" clip-rule="evenodd" d="M168.19 180.151c-7.139 6.105-21.39 10.268-37.804 10.268-20.147 0-37.033-6.272-41.513-14.707-1.602 4.835-1.961 10.367-1.961 13.902 0 0-1.056 17.355 11.015 29.426 0-6.268 5.081-11.349 11.349-11.349 10.743 0 10.731 9.373 10.721 16.977v.679c0 11.542 7.054 21.436 17.086 25.606a23.27 23.27 0 01-2.339-10.2c0-11.008 6.463-15.107 13.974-19.87 5.976-3.79 12.616-8.001 17.192-16.449a31.024 31.024 0 003.743-14.82c0-3.299-.513-6.479-1.463-9.463z" />
-</svg>
--- a/docs/public/index.css
+++ b/docs/public/index.css
@ -1,390 +0,0 @@
-* {
-	box-sizing: border-box;
-	margin: 0;
-}
-
-/* Global focus outline reset */
-*:focus:not(:focus-visible) {
-	outline: none;
-}
-
-:root {
-	--user-font-scale: 1rem - 16px;
-	--max-width: calc(100% - 1rem);
-}
-
-@media (min-width: 50em) {
-	:root {
-		--max-width: 46em;
-	}
-}
-
-@media (prefers-reduced-motion: no-preference) {
-	:root {
-		scroll-behavior: smooth;
-	}
-}
-
-body {
-	display: flex;
-	flex-direction: column;
-	min-height: 100vh;
-	font-family: var(--font-body);
-	font-size: 1rem;
-	font-size: clamp(0.9rem, 0.75rem + 0.375vw + var(--user-font-scale), 1rem);
-	line-height: 1.5;
-	max-width: 100vw;
-}
-
-nav ul {
-	list-style: none;
-	padding: 0;
-}
-
-.content > section > * + * {
-	margin-top: 1.25rem;
-}
-
-.content > section > :first-child {
-	margin-top: 0;
-}
-
-/* Typography */
-h1,
-h2,
-h3,
-h4,
-h5,
-h6 {
-	margin-bottom: 1rem;
-	font-weight: bold;
-	line-height: 1;
-}
-
-h1,
-h2 {
-	max-width: 40ch;
-}
-
-:is(h2, h3):not(:first-child) {
-	margin-top: 3rem;
-}
-
-:is(h4, h5, h6):not(:first-child) {
-	margin-top: 2rem;
-}
-
-h1 {
-	font-size: 3.25rem;
-	font-weight: 800;
-}
-
-h2 {
-	font-size: 2.5rem;
-}
-
-h3 {
-	font-size: 1.75rem;
-}
-
-h4 {
-	font-size: 1.3rem;
-}
-
-h5 {
-	font-size: 1rem;
-}
-
-p,
-.content ul {
-	line-height: 1.65em;
-}
-
-p,
-.content ul {
-	color: var(--theme-text-light);
-}
-
-small,
-.text_small {
-	font-size: 0.833rem;
-}
-
-a {
-	color: var(--theme-text-accent);
-	text-underline-offset: 0.08em;
-	align-items: center;
-	gap: 0.5rem;
-}
-
-article > section :is(ul, ol) > * + * {
-	margin-top: 0.25rem;
-}
-
-article > section nav :is(ul, ol) > * + * {
-	margin-top: inherit;
-}
-
-article > section li > :is(p, pre, blockquote):not(:first-child) {
-	margin-top: 1rem;
-}
-
-article > section :is(ul, ol) {
-	padding-left: 1em;
-}
-
-article > section nav :is(ul, ol) {
-	padding-left: inherit;
-}
-
-article > section nav {
-	margin-top: 1rem;
-	margin-bottom: 2rem;
-}
-
-article > section ::marker {
-	font-weight: bold;
-	color: var(--theme-text-light);
-}
-
-article > section iframe {
-	width: 100%;
-	height: auto;
-	aspect-ratio: 16 / 9;
-}
-
-a > code:not([class*='language']) {
-	position: relative;
-	color: var(--theme-text-accent);
-	background: transparent;
-	text-underline-offset: var(--padding-block);
-}
-
-a > code:not([class*='language'])::before {
-	content: '';
-	position: absolute;
-	top: 0;
-	right: 0;
-	bottom: 0;
-	left: 0;
-	display: block;
-	background: var(--theme-accent);
-	opacity: var(--theme-accent-opacity);
-	border-radius: var(--border-radius);
-}
-
-a:hover,
-a:focus {
-	text-decoration: underline;
-}
-
-a:focus {
-	outline: 2px solid currentColor;
-	outline-offset: 0.25em;
-}
-
-strong {
-	font-weight: 600;
-	color: inherit;
-}
-
-/* Supporting Content */
-code {
-	font-family: var(--font-mono);
-	font-size: 0.85em;
-}
-
-code:not([class*='language']) {
-	--border-radius: 3px;
-	--padding-block: 0.2rem;
-	--padding-inline: 0.4rem;
-	color: var(--theme-code-inline-text);
-	background-color: var(--theme-code-inline-bg);
-	padding: var(--padding-block) var(--padding-inline);
-	margin: calc(var(--padding-block) * -1) -0.125em;
-	border-radius: var(--border-radius);
-	box-shadow: 0 2px 1px 0 rgba(0, 0, 0, 0.08);
-	word-break: break-word;
-}
-
-pre > code:not([class*='language']) {
-	background-color: transparent;
-	padding: 0;
-	margin: 0;
-	border-radius: 0;
-	color: inherit;
-}
-
-pre > code {
-	font-size: 1em;
-}
-
-table,
-pre {
-	position: relative;
-	--padding-block: 1rem;
-	--padding-inline: 2rem;
-	padding: var(--padding-block) var(--padding-inline);
-	padding-right: calc(var(--padding-inline) * 2);
-	margin-left: calc(var(--padding-inline) * -1);
-	margin-right: calc(var(--padding-inline) * -1);
-	font-family: var(--font-mono);
-
-	line-height: 1.5;
-	font-size: 0.85em;
-	overflow-y: hidden;
-	overflow-x: auto;
-}
-
-table {
-	width: 100%;
-	padding: var(--padding-block) 0;
-	margin: 0;
-	border-collapse: collapse;
-}
-
-/* Zebra striping */
-tr:nth-of-type(odd) {
-	background: var(--theme-bg-hover);
-}
-th {
-	background: var(--color-black);
-	color: var(--theme-color);
-	font-weight: bold;
-}
-td,
-th {
-	padding: 6px;
-	text-align: left;
-}
-
-pre {
-	background-color: var(--theme-code-bg);
-	color: var(--theme-code-text);
-}
-
-blockquote code:not([class*='language']) {
-	background-color: var(--theme-bg);
-}
-
-@media (min-width: 37.75em) {
-	pre {
-		--padding-inline: 1.25rem;
-		border-radius: 8px;
-		margin-left: 0;
-		margin-right: 0;
-	}
-}
-
-blockquote {
-	margin: 2rem 0;
-	padding: 1.25em 1.5rem;
-	border-left: 3px solid var(--theme-text-light);
-	background-color: var(--theme-bg-offset);
-	border-radius: 0 0.25rem 0.25rem 0;
-	line-height: 1.7;
-}
-
-img {
-	max-width: 100%;
-}
-
-.flex {
-	display: flex;
-	align-items: center;
-}
-
-button {
-	display: flex;
-	align-items: center;
-	justify-items: center;
-	gap: 0.25em;
-	padding: 0.33em 0.67em;
-	border: 0;
-	background: var(--theme-bg);
-	display: flex;
-	font-size: 1rem;
-	align-items: center;
-	gap: 0.25em;
-	border-radius: 99em;
-	color: var(--theme-text);
-	background-color: var(--theme-bg);
-}
-
-h2.heading {
-	font-size: 1rem;
-	font-weight: 700;
-	padding: 0.1rem 1rem;
-	text-transform: uppercase;
-	margin-bottom: 0.5rem;
-}
-
-.header-link {
-	font-size: 1rem;
-	padding: 0.1rem 0 0.1rem 1rem;
-	border-left: 4px solid var(--theme-divider);
-}
-
-.header-link:hover,
-.header-link:focus {
-	border-left-color: var(--theme-accent);
-	color: var(--theme-accent);
-}
-.header-link:focus-within {
-	color: var(--theme-text-light);
-	border-left-color: hsla(var(--color-gray-40), 1);
-}
-.header-link svg {
-	opacity: 0.6;
-}
-.header-link:hover svg {
-	opacity: 0.8;
-}
-.header-link a {
-	display: inline-flex;
-	gap: 0.5em;
-	width: 100%;
-	padding: 0.15em 0 0.15em 0;
-}
-
-.header-link.depth-3 {
-	padding-left: 2rem;
-}
-.header-link.depth-4 {
-	padding-left: 3rem;
-}
-
-.header-link a {
-	font: inherit;
-	color: inherit;
-	text-decoration: none;
-}
-
-/* Screenreader Only Text */
-.sr-only {
-	position: absolute;
-	width: 1px;
-	height: 1px;
-	padding: 0;
-	margin: -1px;
-	overflow: hidden;
-	clip: rect(0, 0, 0, 0);
-	white-space: nowrap;
-	border-width: 0;
-}
-
-.focus\:not-sr-only:focus,
-.focus\:not-sr-only:focus-visible {
-	position: static;
-	width: auto;
-	height: auto;
-	padding: 0;
-	margin: 0;
-	overflow: visible;
-	clip: auto;
-	white-space: normal;
-}
-
-:target {
-	scroll-margin: calc(var(--theme-sidebar-offset, 5rem) + 2rem) 0 2rem;
-}
--- a/docs/public/make-scrollable-code-focusable.js
+++ b/docs/public/make-scrollable-code-focusable.js
@ -1,3 +0,0 @@
-Array.from(document.getElementsByTagName('pre')).forEach((element) => {
-	element.setAttribute('tabindex', '0');
-});
--- a/docs/public/theme.css
+++ b/docs/public/theme.css
@ -1,126 +0,0 @@
-:root {
-	--font-fallback: -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial,
-		sans-serif, Apple Color Emoji, Segoe UI Emoji;
-	--font-body: system-ui, var(--font-fallback);
-	--font-mono: 'IBM Plex Mono', Consolas, 'Andale Mono WT', 'Andale Mono',
-		'Lucida Console', 'Lucida Sans Typewriter', 'DejaVu Sans Mono',
-		'Bitstream Vera Sans Mono', 'Liberation Mono', 'Nimbus Mono L', Monaco,
-		'Courier New', Courier, monospace;
-
-	/*
-   * Variables with --color-base prefix define
-   * the hue, and saturation values to be used for
-   * hsla colors.
-   *
-   * ex:
-   *
-   * --color-base-{color}: {hue}, {saturation};
-   *
-   */
-
-	--color-base-white: 0, 0%;
-	--color-base-black: 240, 100%;
-	--color-base-gray: 215, 14%;
-	--color-base-blue: 212, 100%;
-	--color-base-blue-dark: 212, 72%;
-	--color-base-green: 158, 79%;
-	--color-base-orange: 22, 100%;
-	--color-base-purple: 269, 79%;
-	--color-base-red: 351, 100%;
-	--color-base-yellow: 41, 100%;
-
-	/*
-   * Color palettes are made using --color-base 
-   * variables, along with a lightness value to
-   * define different variants.
-   *
-   */
-
-	--color-gray-5: var(--color-base-gray), 5%;
-	--color-gray-10: var(--color-base-gray), 10%;
-	--color-gray-20: var(--color-base-gray), 20%;
-	--color-gray-30: var(--color-base-gray), 30%;
-	--color-gray-40: var(--color-base-gray), 40%;
-	--color-gray-50: var(--color-base-gray), 50%;
-	--color-gray-60: var(--color-base-gray), 60%;
-	--color-gray-70: var(--color-base-gray), 70%;
-	--color-gray-80: var(--color-base-gray), 80%;
-	--color-gray-90: var(--color-base-gray), 90%;
-	--color-gray-95: var(--color-base-gray), 95%;
-
-	--color-blue: var(--color-base-blue), 61%;
-	--color-blue-dark: var(--color-base-blue-dark), 39%;
-	--color-green: var(--color-base-green), 42%;
-	--color-orange: var(--color-base-orange), 50%;
-	--color-purple: var(--color-base-purple), 54%;
-	--color-red: var(--color-base-red), 54%;
-	--color-yellow: var(--color-base-yellow), 59%;
-}
-
-:root {
-	color-scheme: light;
-	--theme-accent: hsla(var(--color-orange), 1);
-	--theme-text-accent: hsla(var(--color-orange), 1);
-	--theme-accent-opacity: 0.1;
-	--theme-divider: hsla(var(--color-gray-95), 1);
-	--theme-text: hsla(var(--color-gray-10), 1);
-	--theme-text-light: hsla(var(--color-gray-40), 1);
-	/* @@@: not used anywhere */
-	--theme-text-lighter: hsla(var(--color-gray-80), 1);
-	--theme-bg: hsla(var(--color-base-white), 100%, 1);
-	--theme-bg-hover: hsla(var(--color-gray-95), 1);
-	--theme-bg-offset: hsla(var(--color-gray-90), 1);
-	--theme-bg-accent: hsla(var(--color-orange), var(--theme-accent-opacity));
-	--theme-code-inline-bg: hsla(var(--color-gray-95), 1);
-	--theme-code-inline-text: var(--theme-text);
-	--theme-code-bg: hsla(217, 19%, 27%, 1);
-	--theme-code-text: hsla(var(--color-gray-95), 1);
-	--theme-navbar-bg: hsla(var(--color-base-white), 100%, 1);
-	--theme-navbar-height: 6rem;
-	--theme-selection-color: hsla(var(--color-orange), 1);
-	--theme-selection-bg: hsla(var(--color-orange), var(--theme-accent-opacity));
-}
-
-body {
-	background: var(--theme-bg);
-	color: var(--theme-text);
-}
-
-:root.theme-dark {
-	color-scheme: dark;
-	--theme-accent-opacity: 0.4;
-	--theme-accent: hsla(var(--color-orange), 1);
-	--theme-text-accent: hsla(var(--color-orange), 1);
-	--theme-divider: hsla(var(--color-gray-10), 1);
-	--theme-text: hsla(var(--color-gray-90), 1);
-	--theme-text-light: hsla(var(--color-gray-80), 1);
-
-	/* @@@: not used anywhere */
-	--theme-text-lighter: hsla(var(--color-gray-40), 1);
-	--theme-bg: hsla(215, 28%, 17%, 1);
-	--theme-bg-hover: hsla(var(--color-gray-40), 1);
-	--theme-bg-offset: hsla(var(--color-gray-5), 1);
-	--theme-code-inline-bg: hsla(var(--color-gray-10), 1);
-	--theme-code-inline-text: hsla(var(--color-base-white), 100%, 1);
-	--theme-code-bg: hsla(var(--color-gray-5), 1);
-	--theme-code-text: hsla(var(--color-base-white), 100%, 1);
-	--theme-navbar-bg: hsla(215, 28%, 17%, 1);
-	--theme-selection-color: hsla(var(--color-base-white), 100%, 1);
-	--theme-selection-bg: hsla(var(--color-purple), var(--theme-accent-opacity));
-
-	/* DocSearch [Algolia] */
-	--docsearch-modal-background: var(--theme-bg);
-	--docsearch-searchbox-focus-background: var(--theme-divider);
-	--docsearch-footer-background: var(--theme-divider);
-	--docsearch-text-color: var(--theme-text);
-	--docsearch-hit-background: var(--theme-divider);
-	--docsearch-hit-shadow: none;
-	--docsearch-hit-color: var(--theme-text);
-	--docsearch-footer-shadow: inset 0 2px 10px #000;
-	--docsearch-modal-shadow: inset 0 0 8px #000;
-}
-
-::selection {
-	color: var(--theme-selection-color);
-	background-color: var(--theme-selection-bg);
-}
--- a/docs/reference/api-reference.md
+++ b/docs/reference/api-reference.md
@ -1,195 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: API Reference
---
-
-## `Astro` global
-
-The `Astro` global is available in all contexts in `.astro` files. It has the following functions:
-
-### `Astro.fetchContent()`
-
-`Astro.fetchContent()` is a way to load local `*.md` files into your static site setup. You can either use this on its own, or within [Astro Collections](/core-concepts/collections).
-
-```jsx
-// ./src/components/my-component.astro
---
-const data = Astro.fetchContent('../pages/post/*.md'); // returns an array of posts that live at ./src/pages/post/*.md
---
-
-<div>
-{data.slice(0, 3).map((post) => (
-  <article>
-    <h1>{post.title}</h1>
-    <p>{post.description}</p>
-    <a href={post.url}>Read more</a>
-  </article>
-))}
-</div>
-```
-
-`.fetchContent()` only takes one parameter: a relative URL glob of which local files you'd like to import. Currently only `*.md` files are supported. It's synchronous, and returns an array of items of type:
-
-```js
-{
-   /** frontmatter from the post.. example frontmatter:
-    title: '',
-    tag: '',
-    date: '',
-    image: '',
-    author: '',
-    description: '',
-   **/
-    astro: {
-      headers: [],  // an array of h1...h6 elements in the markdown file
-      source: '',    // raw source of the markdown file
-      html: ''      // rendered HTML of the markdown file
-    },
-    url: '' // the rendered path
-  }[]
-```
-
-### `Astro.slots`
-
-`Astro.slots` returns an object with any slotted regions passed into the current Astro file.
-
-```js
-const {
-  heading as headingSlot, // true or undefined, based on whether `<* slot="heading">` was used.
-  default as defaultSlot, // true or undefined, based on whether `<* slot>` or `<* default>` was used.
-} = Astro.slots;
-```
-
-### `Astro.request`
-
-`Astro.request` returns an object with the following properties:
-
-| Name           | Type  | Description                                     |
-| :------------- | :---- | :---------------------------------------------- |
-| `url`          | `URL` | The URL of the request being rendered.          |
-| `canonicalURL` | `URL` | [Canonical URL][canonical] of the current page. |
-
-⚠️ Temporary restriction: this is only accessible in top-level pages and not in sub-components.
-
-### `Astro.site`
-
-`Astro.site` returns a `URL` made from `buildOptions.site` in your Astro config. If undefined, this will return a URL generated from `localhost`.
-
-## Collections API
-
-### `collection` prop
-
-```jsx
-const { collection } = Astro.props;
-```
-
-When using the [Collections API](/core-concepts/collections), `collection` is a prop exposed to the page with the following shape:
-
-| Name                      |         Type          | Description                                                                                                                       |
-| :------------------------ | :-------------------: | :-------------------------------------------------------------------------------------------------------------------------------- |
-| `collection.data`         |        `Array`        | Array of data returned from `data()` for the current page.                                                                        |
-| `collection.start`        |       `number`        | Index of first item on current page, starting at `0` (e.g. if `pageSize: 25`, this would be `0` on page 1, `25` on page 2, etc.). |
-| `collection.end`          |       `number`        | Index of last item on current page.                                                                                               |
-| `collection.total`        |       `number`        | The total number of items across all pages.                                                                                       |
-| `collection.page.current` |       `number`        | The current page number, starting with `1`.                                                                                       |
-| `collection.page.size`    |       `number`        | How many items per-page.                                                                                                          |
-| `collection.page.last`    |       `number`        | The total number of pages.                                                                                                        |
-| `collection.url.current`  |       `string`        | Get the URL of the current page (useful for canonical URLs)                                                                       |
-| `collection.url.prev`     | `string \| undefined` | Get the URL of the previous page (will be `undefined` if on page 1).                                                              |
-| `collection.url.next`     | `string \| undefined` | Get the URL of the next page (will be `undefined` if no more pages).                                                              |
-| `collection.params`       |       `object`        | If page params were used, this returns a `{ key: value }` object of all values.                                                   |
-
-### `createCollection()`
-
-```jsx
-export async function createCollection() {
-  return {
-    async data({ params }) {
-      // load data
-    },
-    pageSize: 25,
-    routes: [{ tag: 'movie' }, { tag: 'television' }],
-    permalink: ({ params }) => `/tag/${params.tag}`,
-  };
-}
-```
-
-When using the [Collections API](/core-concepts/collections), `createCollection()` is an async function that returns an object of the following shape:
-
-| Name        |                   Type                   | Description                                                                                                |
-| :---------- | :--------------------------------------: | :--------------------------------------------------------------------------------------------------------- |
-| `data`      |      `async ({ params }) => any[]`       | **Required.** Load an array of data with this function to be returned.                                     |
-| `pageSize`  |                 `number`                 | Specify number of items per page (default: `25`).                                                          |
-| `routes`    |                `params[]`                | **Required for URL Params.** Return an array of all possible URL `param` values in `{ name: value }` form. |
-| `permalink` |         `({ params }) => string`         | **Required for URL Params.** Given a `param` object of `{ name: value }`, generate the final URL.\*        |
-| `rss`       | [RSS](/reference/api-reference#rss-feed) | Optional: generate an RSS 2.0 feed from this collection ([docs](/reference/api-reference#rss-feed))        |
-
-_\* Note: don't create confusing URLs with `permalink`, e.g. rearranging params conditionally based on their values._
-
-⚠️ `createCollection()` executes in its own isolated scope before page loads. Therefore you can't reference anything from its parent scope. If you need to load data you may fetch or use async `import()`s within the function body for anything you need (that's why it's `async`—to give you this ability). If it wasn't isolated, then `collection` would be undefined! Therefore, duplicating imports between `createCollection()` and your Astro component is OK.
-
-#### RSS Feed
-
-You can optionally generate an RSS 2.0 feed from `createCollection()` by adding an `rss` option. Here are all the options:
-
-```jsx
-export async function createCollection() {
-  return {
-    async data({ params }) {
-      // load data
-    },
-    pageSize: 25,
-    rss: {
-      title: 'My RSS Feed',
-      description: 'Description of the feed',
-      /** (optional) add xmlns:* properties to root element */
-      xmlns: {
-        itunes: 'http://www.itunes.com/dtds/podcast-1.0.dtd',
-        content: 'http://purl.org/rss/1.0/modules/content/',
-      },
-      /** (optional) add arbitrary XML to <channel> */
-      customData: `<language>en-us</language>
-<itunes:author>The Sunset Explorers</itunes:author>`,
-      /** Format each item from things returned in data() */
-      item: (item) => ({
-        title: item.title,
-        description: item.description,
-        pubDate: item.pubDate + 'Z', // enforce GMT timezone (otherwise it'll be different based on where it's built)
-        /** (optional) add arbitrary XML to each <item> */
-        customData: `<itunes:episodeType>${item.type}</itunes:episodeType>
-<itunes:duration>${item.duration}</itunes:duration>
-<itunes:explicit>${item.explicit || false}</itunes:explicit>`,
-      }),
-    },
-  };
-}
-```
-
-Astro will generate an RSS 2.0 feed at `/feed/[collection].xml` (for example, `/src/pages/$podcast.xml` would generate `/feed/podcast.xml`).
-
-⚠️ Even though Astro will create the RSS feed for you, you'll still need to add `<link>` tags manually in your `<head>` HTML:
-
-```html
-<link
-  rel="alternate"
-  type="application/rss+xml"
-  title="My RSS Feed"
-  href="/feed/podcast.xml"
-/>
-```
-
-## `import.meta`
-
-All ESM modules include a `import.meta` property. Astro adds `import.meta.env` through [Vite](https://vitejs.dev/guide/env-and-mode.html).
-
-**import.meta.env.SSR** can be used to know when rendering on the server. Sometimes you might want different logic, for example a component that should only be rendered in the client:
-
-```jsx
-import { h } from 'preact';
-
-export default function () {
-  return import.meta.env.SSR ? <div class="spinner"></div> : <FancyComponent />;
-}
-```
-
-[canonical]: https://en.wikipedia.org/wiki/Canonical_link_element
--- a/docs/src/components/Card.astro
+++ b/docs/src/components/Card.astro
@ -1,62 +0,0 @@
---
-const { data, index } = Astro.props;
-const hasScreenshot = !!data.demo;
-const backgroundStyle = hasScreenshot
-	? `url('https://v1.screenshot.11ty.dev/${encodeURIComponent(
-			data.demo
-	  )}/medium/9:16/')`
-	: `linear-gradient(60deg, var(--theme-bg-accent), var(--theme-accent))`;
---
-
-<article
-	class={`card ${hasScreenshot ? 'has-screenshot' : ''}`}
-	style={`background: ${backgroundStyle}; background-size: cover;`}
->
-	{hasScreenshot && <div class="background-dimmer"></div>}
-	<div class="card-body">
-		<a href={data.github} class="card-header" target="_blank">
-			{data.name}
-			<span>{` →`}</span>
-		</a>
-	</div>
-</article>
-
-<style>
-	.card {
-		position: relative;
-		display: flex;
-		flex-direction: column;
-		grid-column: span 1;
-		flex-grow: 1;
-		height: 200px;
-		justify-content: center;
-		align-items: center;
-		padding: 1rem;
-		text-align: center;
-	}
-	.card-header {
-		flex-grow: 1;
-		font-weight: bold;
-		font-size: 1.8rem;
-	}
-	.background-dimmer {
-		position: absolute;
-		top: 0;
-		left: 0;
-		height: 100%;
-		width: 100%;
-		background: linear-gradient(45deg, #0004, #000b);
-		z-index: 2;
-	}
-	.card-body,
-	.card-header {
-		color: var(--text-color);
-	}
-	.card-body {
-		z-index: 3;
-	}
-	.card.has-screenshot .card-header,
-	.card.has-screenshot .card-body {
-		color: white;
-	}
-</style>
--- a/docs/src/components/Footer/AvatarList.astro
+++ b/docs/src/components/Footer/AvatarList.astro
@ -1,176 +0,0 @@
---
-// fetch all commits for just this page's path
-
-export interface Props {
-	path: string;
-}
-
-const { path } = Astro.props as Props;
-const commitPath = 'docs/' + path;
-const url = `https://api.github.com/repos/withastro/astro/commits?path=${commitPath}`;
-const commitsURL = `https://github.com/withastro/astro/commits/main/${commitPath}`;
-
-async function getCommits(url) {
-	try {
-		const token = import.meta.env.SNOWPACK_PUBLIC_GITHUB_TOKEN;
-		if (!token) {
-			throw new Error(
-				'Cannot find "SNOWPACK_PUBLIC_GITHUB_TOKEN" used for escaping rate-limiting.'
-			);
-		}
-
-		const auth = `Basic ${Buffer.from(token, 'binary').toString('base64')}`;
-
-		const res = await fetch(url, {
-			method: 'GET',
-			headers: {
-				Authorization: auth,
-				'User-Agent': 'astro-docs/1.0',
-			},
-		});
-
-		const data = await res.json();
-
-		if (!res.ok) {
-			throw new Error(
-				`Request to fetch commits failed. Reason: ${res.statusText}
-       Message: ${data.message}`
-			);
-		}
-
-		return data;
-	} catch (e) {
-		console.warn(`[error]  /src/components/AvatarList.astro 
-    ${e?.message ?? e}`);
-		return new Array();
-	}
-}
-
-function removeDups(arr) {
-	if (!arr) {
-		return new Array();
-	}
-	let map = new Map();
-
-	for (let item of arr) {
-		let author = item.author;
-		// Deduplicate based on author.id
-		map.set(author.id, { login: author.login, id: author.id });
-	}
-
-	return Array.from(map.values());
-}
-
-const data = await getCommits(url);
-const unique = removeDups(data);
-const recentContributors = unique.slice(0, 3); // only show avatars for the 3 most recent contributors
-const additionalContributors = unique.length - recentContributors.length; // list the rest of them as # of extra contributors
---
-
-<!-- Thanks to @5t3ph for https://smolcss.dev/#smol-avatar-list! -->
-<div class="contributors">
-	<ul
-		class="avatar-list"
-		style={`--avatar-count: ${recentContributors.length}`}
-	>
-		{recentContributors.map((item) => (
-			<li>
-				<a href={`https://github.com/${item.login}`}>
-					<img
-						alt={`Contributor ${item.login}`}
-						title={`Contributor ${item.login}`}
-						width="64"
-						height="64"
-						src={`https://avatars.githubusercontent.com/u/${item.id}`}
-					/>
-				</a>
-			</li>
-		))}
-	</ul>
-	{additionalContributors > 0 && (
-		<span>
-			<a
-				href={commitsURL}
-			>{`and ${additionalContributors} additional contributor${
-				additionalContributors > 1 ? 's' : ''
-			}.`}</a>
-		</span>
-	)}
-	{unique.length === 0 && <a href={commitsURL}>Contributors</a>}
-</div>
-
-<style>
-	.avatar-list {
-		--avatar-size: 2.5rem;
-		--avatar-count: 3;
-
-		display: grid;
-		list-style: none;
-		/* Default to displaying most of the avatar to
-  enable easier access on touch devices, ensuring
-  the WCAG touch target size is met or exceeded */
-		grid-template-columns: repeat(
-			var(--avatar-count),
-			max(44px, calc(var(--avatar-size) / 1.15))
-		);
-		/* `padding` matches added visual dimensions of
-  the `box-shadow` to help create a more accurate
-  computed component size */
-		padding: 0.08em;
-		font-size: var(--avatar-size);
-	}
-
-	@media (any-hover: hover) and (any-pointer: fine) {
-		.avatar-list {
-			/* We create 1 extra cell to enable the computed 
-    width to match the final visual width */
-			grid-template-columns: repeat(
-				calc(var(--avatar-count) + 1),
-				calc(var(--avatar-size) / 1.75)
-			);
-		}
-	}
-
-	.avatar-list li {
-		width: var(--avatar-size);
-		height: var(--avatar-size);
-	}
-
-	.avatar-list li:hover ~ li a,
-	.avatar-list li:focus-within ~ li a {
-		transform: translateX(33%);
-	}
-
-	.avatar-list img,
-	.avatar-list a {
-		display: block;
-		border-radius: 50%;
-	}
-
-	.avatar-list a {
-		transition: transform 180ms ease-in-out;
-	}
-
-	.avatar-list img {
-		width: 100%;
-		height: 100%;
-		object-fit: cover;
-		background-color: #fff;
-		box-shadow: 0 0 0 0.05em #fff, 0 0 0 0.08em rgba(0, 0, 0, 0.15);
-	}
-
-	.avatar-list a:focus {
-		outline: 2px solid transparent;
-		/* Double-layer trick to work for dark and light backgrounds */
-		box-shadow: 0 0 0 0.08em var(--theme-accent), 0 0 0 0.12em white;
-	}
-
-	.contributors {
-		display: flex;
-		align-items: center;
-	}
-
-	.contributors > * + * {
-		margin-left: 0.75rem;
-	}
-</style>
--- a/docs/src/components/Footer/Footer.astro
+++ b/docs/src/components/Footer/Footer.astro
@ -1,16 +0,0 @@
---
-import AvatarList from './AvatarList.astro';
-const { path } = Astro.props;
---
-
-<footer>
-	<AvatarList {path} />
-</footer>
-
-<style>
-	footer {
-		margin-top: auto;
-		padding: 2rem 0;
-		border-top: 3px solid var(--theme-divider);
-	}
-</style>
--- a/docs/src/components/HeadCommon.astro
+++ b/docs/src/components/HeadCommon.astro
@ -1,49 +0,0 @@
-<!-- Global Metadata -->
-<meta charset="utf-8" />
-<meta name="viewport" content="width=device-width" />
-<meta name="theme-color" content="#ff5e00" />
-<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
-<link rel="alternate icon" type="image/x-icon" href="/favicon.ico" />
-<link rel="sitemap" href="/sitemap.xml" />
-
-<!-- Global CSS -->
-<link rel="stylesheet" href="/theme.css" />
-<link rel="stylesheet" href="/code.css" />
-<link rel="stylesheet" href="/index.css" />
-
-<!-- Preload Fonts -->
-<link rel="preconnect" href="https://fonts.googleapis.com" />
-<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
-<link
-	href="https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:ital@0;1&display=swap"
-	rel="stylesheet"
-/>
-
-<!-- Scrollable a11y code helper -->
-<script type="module" src="/make-scrollable-code-focusable.js"></script>
-
-<!-- This is intentionally inlined to avoid FOUC -->
-<script>
-	const root = document.documentElement;
-	const theme = localStorage.getItem('theme');
-	if (
-		theme === 'dark' ||
-		(!theme && window.matchMedia('(prefers-color-scheme: dark)').matches)
-	) {
-		root.classList.add('theme-dark');
-	} else {
-		root.classList.remove('theme-dark');
-	}
-</script>
-
-<!-- Global site tag (gtag.js) - Google Analytics -->
-<script async src="https://www.googletagmanager.com/gtag/js?id=UA-130280175-15"
-></script>
-<script>
-	window.dataLayer = window.dataLayer || [];
-	function gtag() {
-		dataLayer.push(arguments);
-	}
-	gtag('js', new Date());
-	gtag('config', 'UA-130280175-15');
-</script>
--- a/docs/src/components/HeadSEO.astro
+++ b/docs/src/components/HeadSEO.astro
@ -1,52 +0,0 @@
---
-import { SITE, OPEN_GRAPH } from '../config.ts';
-import { getLanguageFromURL } from '../util.ts';
-export interface Props {
-	content: any;
-	site: any;
-	canonicalURL: URL;
-}
-const { content = {}, canonicalURL } = Astro.props;
-const imageSrc = content?.image?.src ?? OPEN_GRAPH.image.src;
-const canonicalImageSrc = new URL(imageSrc, Astro.site);
-const imageAlt = content?.image?.alt ?? OPEN_GRAPH.image.alt;
-const lang = canonicalURL && getLanguageFromURL(canonicalURL.pathname);
---
-
-<!-- Page Metadata -->
-<link rel="canonical" href={canonicalURL} />
-
-<!-- Algolia docsearch language facet -->
-<meta name="docsearch:language" content={lang} />
-
-<!-- OpenGraph Tags -->
-<meta property="og:title" content={content.title ?? SITE.title} />
-<meta property="og:type" content="article" />
-<meta property="og:url" content={canonicalURL} />
-<meta property="og:locale" content={content.ogLocale ?? OPEN_GRAPH.locale} />
-<meta property="og:image" content={canonicalImageSrc} />
-<meta property="og:image:alt" content={imageAlt} />
-<meta
-	name="description"
-	property="og:description"
-	content={content.description ? content.description : SITE.description}
-/>
-<meta property="og:site_name" content={SITE.title} />
-
-<!-- Twitter Tags -->
-<meta name="twitter:card" content="summary_large_image" />
-<meta name="twitter:site" content={OPEN_GRAPH.twitter} />
-<meta name="twitter:title" content={content.title ?? SITE.title} />
-<meta
-	name="twitter:description"
-	content={content.description ? content.description : SITE.description}
-/>
-<meta name="twitter:image" content={canonicalImageSrc} />
-<meta name="twitter:image:alt" content={imageAlt} />
-
-<!--
-  TODO: Add json+ld data, maybe https://schema.org/APIReference makes sense?
-  Docs: https://developers.google.com/search/docs/advanced/structured-data/intro-structured-data
-  https://www.npmjs.com/package/schema-dts seems like a great resource for implementing this.
-  Even better, there's a React component that integrates with `schema-dts`: https://github.com/google/react-schemaorg
-->
--- a/docs/src/components/Header/AstroLogo.astro
+++ b/docs/src/components/Header/AstroLogo.astro
@ -1,36 +0,0 @@
---
-const { size } = Astro.props;
---
-
-<svg
-	class="logo"
-	width={size}
-	height={size}
-	viewBox="0 0 256 256"
-	fill="none"
-	xmlns="http://www.w3.org/2000/svg"
->
-	<style>
-		#flame {
-			/* fill: #ff5d01; */
-			fill: #3894ff;
-		}
-		#a {
-			/* fill: #000014; */
-			fill: #3894ff;
-		}
-	</style>
-	<title>Logo</title>
-	<path
-		id="a"
-		fill-rule="evenodd"
-		clip-rule="evenodd"
-		d="M163.008 18.929c1.944 2.413 2.935 5.67 4.917 12.181l43.309 142.27a180.277 180.277 0 00-51.778-17.53l-28.198-95.29a3.67 3.67 0 00-7.042.01l-27.857 95.232a180.225 180.225 0 00-52.01 17.557l43.52-142.281c1.99-6.502 2.983-9.752 4.927-12.16a15.999 15.999 0 016.484-4.798c2.872-1.154 6.271-1.154 13.07-1.154h31.085c6.807 0 10.211 0 13.086 1.157a16.004 16.004 0 016.487 4.806z"
-	></path>
-	<path
-		id="flame"
-		fill-rule="evenodd"
-		clip-rule="evenodd"
-		d="M168.19 180.151c-7.139 6.105-21.39 10.268-37.804 10.268-20.147 0-37.033-6.272-41.513-14.707-1.602 4.835-1.961 10.367-1.961 13.902 0 0-1.056 17.355 11.015 29.426 0-6.268 5.081-11.349 11.349-11.349 10.743 0 10.731 9.373 10.721 16.977v.679c0 11.542 7.054 21.436 17.086 25.606a23.27 23.27 0 01-2.339-10.2c0-11.008 6.463-15.107 13.974-19.87 5.976-3.79 12.616-8.001 17.192-16.449a31.024 31.024 0 003.743-14.82c0-3.299-.513-6.479-1.463-9.463z"
-	></path>
-</svg>
--- a/docs/src/components/Header/Header.astro
+++ b/docs/src/components/Header/Header.astro
@ -1,184 +0,0 @@
---
-import SkipToContent from './SkipToContent.astro';
-import SidebarToggle from './SidebarToggle.tsx';
-import LanguageSelect from './LanguageSelect.tsx';
-import Search from './Search.tsx';
-import { getLanguageFromURL } from '../../util.ts';
-const { currentPage } = Astro.props;
-const lang = currentPage && getLanguageFromURL(currentPage);
---
-
-<header>
-	<SkipToContent />
-	<nav class="nav-wrapper" title="Top Navigation">
-		<div class="menu-toggle">
-			<SidebarToggle client:idle />
-		</div>
-		<div class="logo flex">
-			<a href="https://astro.build/">
-				<h1 class="sr-only">Astro</h1>
-				<svg
-					xmlns="http://www.w3.org/2000/svg"
-					width="363"
-					height="102"
-					viewBox="0 0 363 102"
-					fill="none"
-				>
-					<style>
-						.text {
-							fill: var(--theme-text);
-						}
-						.hover {
-							fill: var(--theme-accent);
-						}
-					</style>
-					<path
-						class="text"
-						fill-rule="evenodd"
-						d="M55.07 14.216l16.81 54.865a72.6 72.6 0 00-20.765-6.984L39.808 24.135a1.475 1.475 0 00-2.827.005L25.81 62.078a72.598 72.598 0 00-20.859 6.995L21.847 14.2c.998-3.243 1.497-4.865 2.47-6.066a8 8 0 013.239-2.392c1.434-.576 3.13-.576 6.524-.576h8.751c3.398 0 5.097 0 6.532.577a8 8 0 013.241 2.397c.972 1.203 1.47 2.827 2.465 6.076z"
-						clip-rule="evenodd"></path>
-					<path
-						fill="#FF5D01"
-						fill-rule="evenodd"
-						d="M54.618 71.779c-2.863 2.432-8.578 4.091-15.161 4.091-8.08 0-14.852-2.499-16.649-5.86-.642 1.926-.786 4.13-.786 5.539 0 0-.423 6.915 4.418 11.725 0-2.498 2.037-4.522 4.551-4.522 4.309 0 4.304 3.734 4.3 6.764v.27c0 4.6 2.829 8.541 6.852 10.203a9.22 9.22 0 01-.938-4.064c0-4.386 2.592-6.02 5.604-7.917 2.396-1.51 5.06-3.188 6.894-6.554a12.297 12.297 0 001.502-5.905c0-1.314-.206-2.581-.587-3.77z"
-						clip-rule="evenodd"></path>
-					<path
-						class="text"
-						d="M126.554 69c13.115 0 21.047-3.14 25.68-9.654 0 2.904.157 5.651.55 8.163h7.774c-.706-4.082-.863-6.75-.863-14.128V43.334c0-10.831-8.403-16.56-24.424-16.56-15.47 0-25.522 5.964-26.779 14.598h8.246c1.256-5.808 7.774-8.87 18.533-8.87 10.602 0 16.885 3.69 16.885 9.969v.785l-24.502 1.413c-9.974.549-13.665 1.962-16.492 4.003-2.67 1.962-4.162 5.023-4.162 8.555C107 64.683 114.696 69 126.554 69zm2.513-5.573c-9.109 0-14.135-2.119-14.135-6.357 0-4.553 3.141-6.593 14.214-7.3l23.01-1.412v1.805c0 8.241-9.66 13.264-23.089 13.264zM196.086 69c16.256 0 22.775-5.337 22.775-13.108 0-6.436-4.006-9.732-14.215-10.596l-19.083-1.49c-5.183-.393-8.088-1.884-8.088-5.102 0-4.082 4.476-6.201 14.135-6.201 10.995 0 16.727 2.198 20.497 7.064l6.361-3.061c-3.927-6.122-12.644-9.733-26.151-9.733-13.9 0-22.224 4.631-22.224 12.244 0 6.829 4.947 10.125 14.292 10.91l18.926 1.492c6.204.47 8.089 1.726 8.089 4.944 0 4.631-4.79 6.829-14.293 6.829-11.544 0-18.847-3.14-22.381-8.87l-6.204 3.376C173.312 64.918 181.715 69 196.086 69zM234.929 34.151v18.916c0 7.77 2.67 15.54 17.198 15.54 3.691 0 8.167-.706 10.131-1.57V60.68c-2.749.628-6.047 1.1-9.267 1.1-6.832 0-10.523-2.67-10.523-9.42V34.151h19.633v-5.887h-19.633V15l-7.539 3.061v10.204h-12.33v5.886h12.33zM280.823 28.265h-6.911v39.244h7.461V52.83c0-5.65 1.099-10.439 4.24-13.735 2.749-3.061 6.283-4.788 12.487-4.788 2.12 0 3.455.157 5.262.471v-7.22c-1.65-.393-3.063-.472-5.184-.472-8.402 0-15.078 4.945-17.355 12.558v-11.38zM334.807 69C351.534 69 363 60.523 363 47.887c0-12.637-11.466-21.114-28.193-21.114-16.727 0-28.193 8.477-28.193 21.114C306.614 60.523 318.08 69 334.807 69zm0-6.2c-12.329 0-20.261-5.809-20.261-14.913 0-9.105 7.932-14.913 20.261-14.913 12.251 0 20.261 5.808 20.261 14.913 0 9.104-8.01 14.912-20.261 14.912z"
-					></path>
-				</svg>
-			</a>
-			<a href="https://docs.astro.build/">
-				<h1 class="sr-only">Docs</h1>
-				<svg
-					xmlns="http://www.w3.org/2000/svg"
-					width="226"
-					height="102"
-					viewBox="0 0 226 102"
-					fill="none"
-				>
-					<path
-						fill="currentColor"
-						d="M25.805 68c14.688 0 24.883-8.41 24.883-21.14 0-12.786-9.62-19.756-24.653-19.756H0V68h25.805zm-14.17-33.005H24.25c8.352 0 14.17 4.09 14.17 12.039 0 8.236-5.3 13.075-14.113 13.075H11.635V34.995zM82.673 69.382c16.704 0 27.418-8.582 27.418-21.83 0-13.248-10.771-21.83-27.418-21.83-16.589 0-27.418 8.582-27.418 21.83 0 13.19 10.83 21.83 27.418 21.83zm0-8.64c-9.1 0-15.149-5.299-15.149-13.19 0-7.891 6.048-13.19 15.15-13.19 9.1 0 15.205 5.299 15.205 13.19 0 7.891-6.105 13.19-15.206 13.19zM141.497 69.382c13.306 0 22.637-5.299 25.978-14.572l-11.866-2.535c-1.67 5.415-6.393 8.295-13.709 8.295-9.216 0-15.033-5.127-15.033-13.018 0-8.006 5.702-13.018 14.918-13.018 7.43 0 12.154 3.053 13.709 8.64l12.038-2.13c-2.707-9.562-12.268-15.322-25.574-15.322-16.128 0-27.302 9.043-27.302 22.003 0 13.133 10.425 21.657 26.841 21.657zM194.94 69.382c14.745 0 23.212-5.01 23.212-14.054 0-7.603-4.665-10.944-15.955-12.096l-11.289-1.094c-5.242-.576-6.97-1.556-6.97-4.09 0-2.765 3.456-4.262 9.792-4.262 7.834 0 13.709 2.476 16.762 6.508l7.315-6.163c-5.069-5.702-13.133-8.41-23.501-8.41-13.997 0-21.888 4.781-21.888 12.903 0 7.546 4.781 11.232 14.803 12.326l12.557 1.383c4.896.518 6.624 1.555 6.624 4.09 0 3.225-3.456 4.723-10.886 4.723-8.352 0-14.688-3.226-18.087-8.007l-8.294 5.818c4.205 6.451 13.709 10.425 25.805 10.425z"
-					></path>
-				</svg>
-			</a>
-		</div>
-		<div style="flex-grow: 1;"></div>
-		{lang && <LanguageSelect lang={lang} client:idle />}
-		<div class="search-item"><Search {lang} client:idle /></div>
-	</nav>
-</header>
-
-<style>
-	header {
-		z-index: 11;
-		height: var(--theme-navbar-height);
-		width: 100%;
-		background-color: var(--theme-navbar-bg);
-		display: flex;
-		align-items: center;
-		justify-content: center;
-		overflow: hidden;
-		position: sticky;
-		top: 0;
-	}
-
-	.logo {
-		direction: ltr;
-		display: flex;
-		overflow: hidden;
-		width: 30px;
-		font-size: 1rem;
-		flex-shrink: 0;
-		font-weight: 600;
-		line-height: 1;
-		color: hsla(var(--color-base-white), 100%, 1);
-		text-decoration: none;
-		gap: 0.5em;
-		z-index: -1;
-	}
-
-	.logo a {
-		padding: 0.5em 0.25em;
-		margin: -0.5em -0.25em;
-	}
-
-	.logo svg {
-		height: 40px;
-		width: auto;
-		display: block;
-		color: var(--theme-accent);
-	}
-
-	.logo .hover {
-		opacity: 0;
-	}
-	.logo a {
-		transition: transform 180ms ease-out;
-	}
-
-	.logo a:hover,
-	.logo a:focus {
-		outline: none;
-		opacity: 1;
-		transform: translateY(-2px);
-	}
-
-	.logo h1 {
-		font: inherit;
-		color: inherit;
-		margin: 0;
-	}
-
-	.nav-wrapper {
-		display: flex;
-		align-items: center;
-		justify-content: flex-end;
-		gap: 1em;
-		width: 100%;
-		max-width: 82em;
-		padding: 0 1rem;
-	}
-	@media (min-width: 50em) {
-		header {
-			position: static;
-			padding: 2rem 0rem 0 2rem;
-		}
-		.logo {
-			width: auto;
-			margin: 0;
-			z-index: 0;
-		}
-		.menu-toggle {
-			display: none;
-		}
-		.logo {
-			width: auto;
-		}
-	}
-
-	/** Style Algolia */
-	:root {
-		--docsearch-primary-color: var(--theme-accent);
-		--docsearch-logo-color: var(--theme-text);
-	}
-
-	.search-item {
-		display: none;
-		position: relative;
-		z-index: 10;
-		flex-grow: 1;
-		padding-right: 0.7rem;
-		display: flex;
-		max-width: 200px;
-	}
-	:global(.search-item > *) {
-		flex-grow: 1;
-	}
-	@media (min-width: 50em) {
-		.search-item {
-			max-width: 400px;
-		}
-	}
-</style>
--- a/docs/src/components/Header/LanguageSelect.css
+++ b/docs/src/components/Header/LanguageSelect.css
@ -1,50 +0,0 @@
-.language-select {
-	flex-grow: 1;
-	width: 48px;
-	box-sizing: border-box;
-	margin: 0;
-	padding: 0.33em 2rem;
-	overflow: visible;
-	font-weight: 500;
-	font-size: 1rem;
-	font-family: inherit;
-	line-height: inherit;
-	background-color: var(--theme-bg);
-	border-color: var(--theme-text-lighter);
-	color: var(--theme-text-light);
-	border-style: solid;
-	border-width: 1px;
-	border-radius: 0.25rem;
-	outline: 0;
-	cursor: pointer;
-	transition-timing-function: ease-out;
-	transition-duration: 0.2s;
-	transition-property: border-color, color;
-	background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' fill='none' viewBox='0 0 20 20'%3e%3cpath stroke='%236b7280' stroke-linecap='round' stroke-linejoin='round' stroke-width='1.5' d='M6 8l4 4 4-4'/%3e%3c/svg%3e");
-	background-position: 97%;
-	background-repeat: no-repeat;
-	background-size: 1.5em 1.5em;
-	-webkit-font-smoothing: antialiased;
-	-webkit-appearance: none;
-}
-.language-select-wrapper .language-select:hover,
-.language-select-wrapper .language-select:focus {
-	color: var(--theme-text);
-	border-color: var(--theme-text-light);
-}
-.language-select-wrapper {
-	color: var(--theme-text-light);
-	position: relative;
-}
-.language-select-wrapper > svg {
-	position: absolute;
-	top: 8px;
-	left: 8px;
-	pointer-events: none;
-}
-
-@media (min-width: 50em) {
-	.language-select {
-		width: 100%;
-	}
-}
--- a/docs/src/components/Header/LanguageSelect.tsx
+++ b/docs/src/components/Header/LanguageSelect.tsx
@ -1,102 +0,0 @@
-import type { FunctionalComponent } from 'preact';
-import { h } from 'preact';
-import './LanguageSelect.css';
-
-const LanguageSelect: FunctionalComponent<{ lang: string }> = ({ lang }) => {
-	return (
-		<div class="language-select-wrapper">
-			<svg
-				aria-hidden="true"
-				focusable="false"
-				role="img"
-				xmlns="http://www.w3.org/2000/svg"
-				viewBox="0 0 88.6 77.3"
-				height="1.2em"
-				width="1.2em"
-			>
-				<path
-					fill="currentColor"
-					d="M61,24.6h7.9l18.7,51.6h-7.7l-5.4-15.5H54.3l-5.6,15.5h-7.2L61,24.6z M72.6,55l-8-22.8L56.3,55H72.6z"
-				/>
-				<path
-					fill="currentColor"
-					d="M53.6,60.6c-10-4-16-9-22-14c0,0,1.3,1.3,0,0c-6,5-20,13-20,13l-4-6c8-5,10-6,19-13c-2.1-1.9-12-13-13-19h8          c4,9,10,14,10,14c10-8,10-19,10-19h8c0,0-1,13-12,24l0,0c5,5,10,9,19,13L53.6,60.6z M1.6,16.6h56v-8h-23v-7h-9v7h-24V16.6z"
-				/>
-			</svg>
-			<select
-				class="language-select"
-				value={lang}
-				aria-label="Select language"
-				onChange={(e) => {
-					const newLang = e.target.value;
-					window.location.pathname = `/${newLang}/getting-started`;
-					// TODO: Preserve the current page, if it exists:
-					// const oldPathname = window.location.pathname;
-					// const oldPathnameParts = oldPathname.split('/');
-					// oldPathnameParts.shift();
-					// if (/^[a-z]{2}$/.test(oldPathnameParts[0])) {
-					//   oldPathnameParts.shift();
-					// }
-					// if (newLang !== 'en') {
-					//   oldPathnameParts.unshift(newLang);
-					// }
-					// window.location.pathname = '/' + oldPathnameParts.join('/');
-				}}
-			>
-				<option value="en">
-					<span>English</span>
-				</option>
-				<option value="de">
-					<span>Deutsch</span>
-				</option>
-				<option value="nl">
-					<span>Nederlands</span>
-				</option>
-				<option value="pt-br">
-					<span>Português do Brasil</span>
-				</option>
-				<option value="fi">
-					<span>Suomi</span>
-				</option>
-				<option value="es">
-					<span>Español</span>
-				</option>
-				<option value="zh-CN">
-					<span>简体中文</span>
-				</option>
-				<option value="zh-TW">
-					<span>正體中文</span>
-				</option>
-				<option value="bg">
-					<span>Български</span>
-				</option>
-				<option value="fr">
-					<span>Français</span>
-				</option>
-				<option value="bn">
-					<span>বাংলা</span>
-				</option>
-				<option value="kr">
-					<span>한국어</span>
-				</option>
-				<option value="ar">
-					<span>العربية</span>
-				</option>
-				<option value="da">
-					<span>Dansk</span>
-				</option>
-				<option value="ja">
-					<span>日本語</span>
-				</option>
-				<option value="ru">
-					<span>Русский</span>
-				</option>
-				<option value="it">
-					<span>Italiano</span>
-				</option>
-			</select>
-		</div>
-	);
-};
-
-export default LanguageSelect;
--- a/docs/src/components/Header/Search.css
+++ b/docs/src/components/Header/Search.css
@ -1,75 +0,0 @@
-/** Style Algolia */
-:root {
-	--docsearch-primary-color: var(--theme-accent);
-	--docsearch-logo-color: var(--theme-text);
-}
-
-.DocSearch-Modal .DocSearch-Hit a {
-	box-shadow: none;
-	border: 1px solid var(--theme-accent);
-}
-
-/** Style Search Bar */
-.search-placeholder {
-	flex-grow: 1;
-	text-align: initial;
-}
-.search-input {
-	flex-grow: 1;
-	box-sizing: border-box;
-	width: 100%;
-	margin: 0;
-	padding: 0.33em 0.5em;
-	overflow: visible;
-	font-weight: 500;
-	font-size: 1rem;
-	font-family: inherit;
-	line-height: inherit;
-	background-color: var(--theme-divider);
-	border-color: var(--theme-divider);
-	color: var(--theme-text-light);
-	border-style: solid;
-	border-width: 1px;
-	border-radius: 0.25rem;
-	outline: 0;
-	cursor: pointer;
-	transition-timing-function: ease-out;
-	transition-duration: 0.2s;
-	transition-property: border-color, color;
-	-webkit-font-smoothing: antialiased;
-}
-.search-input:hover,
-.search-input:focus {
-	color: var(--theme-text);
-	border-color: var(--theme-text-light);
-}
-.search-input:hover::placeholder,
-.search-input:focus::placeholder {
-	color: var(--theme-text-light);
-}
-.search-input::placeholder {
-	color: var(--theme-text-light);
-}
-.search-hint {
-	padding: 3px 5px;
-	display: none;
-	display: none;
-	align-items: center;
-	justify-content: center;
-	letter-spacing: 0.125em;
-	font-size: 13px;
-	font-family: var(--font-mono);
-	pointer-events: none;
-	border-color: var(--theme-text-lighter);
-	color: var(--theme-text-light);
-	border-style: solid;
-	border-width: 1px;
-	border-radius: 0.25rem;
-	line-height: 14px;
-}
-
-@media (min-width: 50em) {
-	.search-hint {
-		display: flex;
-	}
-}
--- a/docs/src/components/Header/Search.tsx
+++ b/docs/src/components/Header/Search.tsx
@ -1,93 +0,0 @@
-/* jsxImportSource: react */
-import { useState, useCallback, useRef } from 'react';
-import { createPortal } from 'react-dom';
-import * as docsearch from '@docsearch/react';
-import '@docsearch/css/dist/style.css';
-import './Search.css';
-
-const { DocSearchModal, useDocSearchKeyboardEvents } =
-	(docsearch as unknown as { default: typeof docsearch }).default || docsearch;
-
-export default function Search(props) {
-	const [isOpen, setIsOpen] = useState(false);
-	const searchButtonRef = useRef();
-	const [initialQuery, setInitialQuery] = useState(null);
-	const { lang = 'en' } = props;
-
-	const onOpen = useCallback(() => {
-		setIsOpen(true);
-	}, [setIsOpen]);
-
-	const onClose = useCallback(() => {
-		setIsOpen(false);
-	}, [setIsOpen]);
-
-	const onInput = useCallback(
-		(e) => {
-			setIsOpen(true);
-			setInitialQuery(e.key);
-		},
-		[setIsOpen, setInitialQuery]
-	);
-
-	useDocSearchKeyboardEvents({
-		isOpen,
-		onOpen,
-		onClose,
-		onInput,
-		searchButtonRef,
-	});
-
-	return (
-		<>
-			<button
-				type="button"
-				ref={searchButtonRef}
-				onClick={onOpen}
-				className="search-input"
-			>
-				<svg width="24" height="24" fill="none">
-					<path
-						d="M21 21l-6-6m2-5a7 7 0 11-14 0 7 7 0 0114 0z"
-						stroke="currentColor"
-						strokeWidth="2"
-						strokeLinecap="round"
-						strokeLinejoin="round"
-					/>
-				</svg>
-				<span className="search-placeholder">Search</span>
-				<span className="search-hint">
-					<span className="sr-only">Press </span>
-					<kbd>/</kbd>
-					<span className="sr-only"> to search</span>
-				</span>
-			</button>
-			{isOpen &&
-				createPortal(
-					<DocSearchModal
-						initialQuery={initialQuery}
-						initialScrollY={window.scrollY}
-						onClose={onClose}
-						indexName="astro"
-						apiKey="0f387260ad74f9cbf4353facd29c919c"
-						// Set facetFilters once Astro docs have been indexed by language
-						// searchParameters={{ facetFilters: [`lang:${lang}`] }}
-						transformItems={(items) => {
-							return items.map((item) => {
-								// We transform the absolute URL into a relative URL to
-								// work better on localhost, preview URLS.
-								const a = document.createElement('a');
-								a.href = item.url;
-								const hash = a.hash === '#overview' ? '' : a.hash;
-								return {
-									...item,
-									url: `${a.pathname}${hash}`,
-								};
-							});
-						}}
-					/>,
-					document.body
-				)}
-		</>
-	);
-}
--- a/docs/src/components/Header/SidebarToggle.tsx
+++ b/docs/src/components/Header/SidebarToggle.tsx
@ -1,44 +0,0 @@
-import type { FunctionalComponent } from 'preact';
-import { h, Fragment } from 'preact';
-import { useState, useEffect } from 'preact/hooks';
-
-const MenuToggle: FunctionalComponent = () => {
-	const [sidebarShown, setSidebarShown] = useState(false);
-
-	useEffect(() => {
-		const body = document.getElementsByTagName('body')[0];
-		if (sidebarShown) {
-			body.classList.add('mobile-sidebar-toggle');
-		} else {
-			body.classList.remove('mobile-sidebar-toggle');
-		}
-	}, [sidebarShown]);
-
-	return (
-		<button
-			type="button"
-			aria-pressed={sidebarShown ? 'true' : 'false'}
-			id="menu-toggle"
-			onClick={() => setSidebarShown(!sidebarShown)}
-		>
-			<svg
-				xmlns="http://www.w3.org/2000/svg"
-				width="1em"
-				height="1em"
-				fill="none"
-				viewBox="0 0 24 24"
-				stroke="currentColor"
-			>
-				<path
-					stroke-linecap="round"
-					stroke-linejoin="round"
-					stroke-width="2"
-					d="M4 6h16M4 12h16M4 18h16"
-				/>
-			</svg>
-			<span className="sr-only">Toggle sidebar</span>
-		</button>
-	);
-};
-
-export default MenuToggle;
--- a/docs/src/components/Header/SkipToContent.astro
+++ b/docs/src/components/Header/SkipToContent.astro
@ -1,22 +0,0 @@
-<a href="#article" class="sr-only focus:not-sr-only skiplink"><span>Skip to Content</span></a>
-
-<style>
-	.skiplink,
-	.skiplink:focus,
-	.skiplink:focus-visible {
-		position: absolute;
-		padding: 0.25em;
-		font-size: larger;
-		top: 0;
-		left: 0;
-		right: 0;
-		z-index: 9;
-		display: block;
-		text-align: center;
-		background-color: var(--theme-text-accent);
-		color: var(--theme-bg);
-		border-radius: 0.25em;
-		outline: var(--theme-bg) solid 1px;
-		outline-offset: 0;
-	}
-</style>
--- a/docs/src/components/LeftSidebar/LeftSidebar.astro
+++ b/docs/src/components/LeftSidebar/LeftSidebar.astro
@ -1,186 +0,0 @@
---
-import { SIDEBAR } from '../../config.ts';
-import {
-	getLanguageFromURL,
-	removeLeadingSlash,
-	removeTrailingSlash,
-} from '../../util.ts';
-const { currentPage } = Astro.props;
-
-// Get the slug w/o a leading or trailing slash
-const currentPageMatch = removeLeadingSlash(removeTrailingSlash(currentPage));
-const langCode = getLanguageFromURL(currentPage);
-// SIDEBAR is a flat array. Group it by sections to properly render.
-const sidebarSections = SIDEBAR[langCode].reduce((col, item) => {
-	if (item.header) {
-		col.push({ ...item, children: [] });
-	} else {
-		col[col.length - 1].children.push(item);
-	}
-	return col;
-}, []);
---
-
-<nav aria-labelledby="grid-left">
-	<ul class="nav-groups">
-		<li>
-			<div class="nav-group">
-				<h2 class="sponsors-title">Sponsored by</h2>
-				<div class="sponsors">
-					<a href="https://www.netlify.com/" aria-label="Go to Netlify website">
-						<svg
-							class="sponsor-logo__netlify"
-							viewBox="0 0 147 40"
-							xmlns="http://www.w3.org/2000/svg"
-							xmlns:xlink="http://www.w3.org/1999/xlink"
-							><radialGradient
-								id="netlify-gradient"
-								cx="-779.0521"
-								cy="1839.7205"
-								gradientTransform="matrix(0 38.301 44.1228 0 -81154.2578 29839.2441)"
-								gradientUnits="userSpaceOnUse"
-								r="1.0011"
-								><stop offset="0" stop-color="#20c6b7"></stop><stop
-									offset="1"
-									stop-color="#4d9abf"></stop></radialGradient
-							><path
-								clip-rule="evenodd"
-								d="m53.37 12.98.12 2.2c1.4-1.7 3.24-2.55 5.53-2.55 3.95 0 5.96 2.27 6.03 6.8v12.57h-4.26v-12.32c0-1.21-.26-2.1-.78-2.68s-1.37-.87-2.55-.87c-1.72 0-3 .78-3.84 2.34v13.53h-4.26v-19.02zm24.38 19.37c-2.7 0-4.89-.85-6.57-2.56-1.68-1.7-2.52-3.98-2.52-6.81v-.53c0-1.9.36-3.59 1.1-5.09.73-1.49 1.76-2.66 3.08-3.49s2.79-1.25 4.42-1.25c2.58 0 4.58.83 5.99 2.48s2.11 3.99 2.11 7.01v1.72h-12.4c.13 1.57.65 2.81 1.57 3.73s2.07 1.37 3.46 1.37c1.95 0 3.54-.79 4.77-2.37l2.3 2.2c-.76 1.14-1.77 2.02-3.04 2.65s-2.69.94-4.27.94zm-.51-16.29c-1.17 0-2.11.41-2.83 1.23s-1.18 1.96-1.38 3.43h8.12v-.32c-.09-1.43-.47-2.51-1.14-3.24-.67-.74-1.59-1.1-2.77-1.1zm16.76-7.7v4.62h3.35v3.16h-3.35v10.62c0 .73.14 1.25.43 1.57s.8.48 1.54.48c.5 0 1-.06 1.49-.18v3.31c-.97.27-1.9.4-2.81.4-3.27 0-4.91-1.81-4.91-5.43v-10.77h-3.12v-3.16h3.12v-4.63zm11.14 23.64h-4.26v-27h4.26zm9.17 0h-4.26v-19.02h4.26zm-4.52-23.96c0-.65.21-1.2.62-1.63.42-.43 1.01-.65 1.78-.65s1.37.22 1.79.65.63.98.63 1.64c0 .64-.21 1.18-.63 1.61s-1.02.64-1.79.64-1.36-.21-1.78-.64c-.41-.44-.62-.98-.62-1.62zm10.66 23.96v-15.86h-2.89v-3.16h2.89v-1.74c0-2.11.58-3.74 1.75-4.89s2.81-1.72 4.91-1.72c.75 0 1.54.11 2.39.32l-.1 3.34c-.54-.1-1.08-.15-1.63-.14-2.04 0-3.05 1.05-3.05 3.15v1.69h3.86v3.16h-3.86v15.85zm17.87-6.12 3.86-12.9h4.54l-7.54 21.9c-1.16 3.2-3.12 4.8-5.89 4.8-.62 0-1.3-.11-2.05-.32v-3.31l.81.05c1.07 0 1.88-.2 2.43-.59.54-.39.97-1.05 1.29-1.98l.61-1.64-6.66-18.93h4.6z"
-								fill-rule="evenodd"></path><path
-								d="m27.89 14.14-.01-.01c-.01 0-.02-.01-.02-.01-.02-.02-.03-.06-.03-.09l.77-4.73 3.62 3.63-3.77 1.6c-.01 0-.02.01-.03.01h-.02s-.01-.01-.02-.02c-.14-.16-.31-.29-.49-.38zm5.26-.29 3.88 3.88c.81.81 1.21 1.21 1.35 1.67.02.07.04.14.05.21l-9.26-3.92s-.01 0-.01-.01c-.04-.02-.08-.03-.08-.07s.04-.06.08-.07l.01-.01zm5.12 7c-.2.38-.59.77-1.25 1.43l-4.37 4.37-5.65-1.18-.03-.01c-.05-.01-.1-.02-.1-.06-.04-.47-.28-.9-.66-1.19-.02-.02-.02-.06-.01-.09v-.01l1.06-6.53v-.02c.01-.05.01-.11.06-.11.46-.06.88-.3 1.16-.67.01-.01.01-.02.03-.03.03-.01.07 0 .1.01zm-6.62 6.8-7.19 7.19 1.23-7.56v-.01c0-.01 0-.02.01-.03.01-.02.04-.03.06-.04h.01c.27-.11.51-.29.69-.52.02-.03.05-.06.09-.06h.03zm-8.71 8.71-.81.81-8.95-12.94s-.01-.01-.01-.01c-.01-.02-.03-.04-.03-.06s.01-.03.02-.04l.01-.01c.03-.04.05-.08.07-.12l.02-.03c.01-.02.03-.05.05-.06s.05-.01.07 0l9.92 2.05c.03 0 .05.02.08.03.01.01.02.03.02.04.14.53.52.97 1.03 1.17.03.01.02.05 0 .08-.01.01-.01.03-.01.05-.12.74-1.19 7.27-1.48 9.04zm-1.69 1.69c-.6.59-.95.9-1.35 1.03-.39.12-.81.12-1.21 0-.47-.15-.87-.55-1.67-1.36l-8.99-8.99 2.35-3.64c.01-.02.02-.03.04-.05s.06-.01.09 0c.54.16 1.12.13 1.64-.08.03-.01.05-.02.07 0l.03.03zm-14.09-10.19-2.06-2.06 4.07-1.74c.01 0 .02-.01.03-.01.03 0 .05.03.07.07.04.06.08.12.13.18l.01.02c.01.02 0 .03-.01.05zm-2.98-2.97-2.61-2.61c-.44-.44-.77-.77-.99-1.04l7.94 1.65h.03c.05.01.1.02.1.06 0 .05-.06.07-.11.09l-.02.01zm-4.05-5c.01-.17.04-.33.09-.5.15-.47.55-.87 1.36-1.67l3.34-3.34c1.54 2.23 3.08 4.46 4.63 6.69.03.04.06.08.03.11-.15.16-.29.34-.4.53-.01.02-.03.05-.05.06-.01.01-.03 0-.04 0zm5.68-6.4 4.49-4.49c.42.19 1.96.83 3.33 1.41 1.04.44 1.99.84 2.29.97.03.01.06.02.07.05.01.02 0 .04 0 .06-.14.66.05 1.35.52 1.83.03.03 0 .07-.03.11l-.01.02-4.56 7.06c-.01.02-.02.04-.04.05s-.06.01-.09 0c-.18-.05-.36-.07-.54-.07-.16 0-.34.03-.52.06-.02 0-.04.01-.05 0-.02-.01-.03-.03-.05-.05zm5.4-5.4 5.81-5.81c.81-.81 1.21-1.21 1.67-1.36.39-.12.81-.12 1.21 0 .47.15.87.55 1.67 1.36l1.26 1.26-4.14 6.4c-.01.02-.02.03-.04.05s-.06.01-.09 0c-.66-.2-1.38-.06-1.92.37-.03.03-.07.01-.1 0-.53-.24-4.73-2.01-5.33-2.27zm12.5-3.67 3.82 3.82-.92 5.7v.02c0 .01 0 .03-.01.04-.01.02-.03.02-.05.03-.2.06-.38.15-.55.27-.01.01-.01.01-.02.02s-.02.02-.04.02c-.01 0-.03 0-.04-.01l-5.82-2.47-.01-.01c-.04-.02-.08-.03-.08-.07-.03-.32-.14-.64-.31-.91-.03-.05-.06-.09-.03-.14zm-3.93 8.6 5.45 2.31c.03.01.06.03.08.06.01.02.01.04 0 .06-.02.08-.03.17-.03.26v.15c0 .04-.04.05-.08.07h-.01c-.86.37-12.13 5.17-12.15 5.17s-.03 0-.05-.02c-.03-.03 0-.07.03-.11 0-.01.01-.01.01-.02l4.48-6.94.01-.01c.03-.04.06-.09.1-.09l.05.01c.1.01.19.03.28.03.68 0 1.31-.33 1.69-.9.01-.02.02-.03.03-.04.04-.01.08 0 .11.01zm-6.25 9.19 12.28-5.24s.02 0 .03.02c.07.07.12.11.18.15l.03.02c.02.01.05.03.05.06v.02l-1.05 6.46v.03c-.01.05-.01.11-.06.11-.57.04-1.08.36-1.37.85v.01c-.01.02-.03.05-.05.06s-.05.01-.07 0l-9.79-2.02c-.02-.02-.16-.53-.18-.53z"
-								fill="url(#netlify-gradient)"></path></svg
-						>
-					</a>
-				</div>
-			</div>
-		</li>
-		{sidebarSections.map((section) => (
-			<li>
-				<div class="nav-group">
-					<h2 class="nav-group-title">{section.text}</h2>
-					<ul>
-						{section.children.map((child) => (
-							<li class="nav-link">
-								<a
-									href={`${Astro.site.pathname}${child.link}`}
-									aria-current={`${
-										currentPageMatch === child.link ? 'page' : 'false'
-									}`}
-								>
-									{child.text}
-								</a>
-							</li>
-						))}
-					</ul>
-				</div>
-			</li>
-		))}
-	</ul>
-</nav>
-
-<script>
-	window.addEventListener('DOMContentLoaded', (event) => {
-		var target = document.querySelector('[aria-current="page"]');
-		if (target && target.offsetTop > window.innerHeight - 100) {
-			document.querySelector('.nav-groups').scrollTop = target.offsetTop;
-		}
-	});
-</script>
-
-<style lang="scss">
-	nav {
-		width: 100%;
-		margin-right: 1rem;
-	}
-	.nav-groups {
-		height: 100%;
-		padding: 2rem 0;
-		overflow-x: visible;
-		overflow-y: auto;
-		max-height: 100vh;
-
-		> li + li {
-			margin-top: 1.75rem;
-		}
-
-		> :first-child {
-			padding-top: var(--doc-padding);
-		}
-
-		> :last-child {
-			padding-bottom: 2rem;
-			margin-bottom: var(--theme-navbar-height);
-		}
-
-		@media (min-width: 50em) {
-			padding: 0;
-		}
-	}
-
-	.nav-group-title {
-		font-size: 1rem;
-		font-weight: 700;
-		padding: 0.1rem 1rem;
-		text-transform: uppercase;
-		margin-bottom: 0.5rem;
-	}
-
-	.nav-link a {
-		font-size: 1rem;
-		margin: 1px;
-		padding: 0.3rem 1rem;
-		font: inherit;
-		color: inherit;
-		text-decoration: none;
-		display: block;
-
-		&:hover,
-		&:focus {
-			background-color: var(--theme-bg-hover);
-		}
-
-		&[aria-current='page'] {
-			color: var(--theme-text-accent);
-			background-color: var(--theme-bg-accent);
-			font-weight: 600;
-		}
-	}
-
-	:global(:root.theme-dark) .nav-link a[aria-current='page'] {
-		color: hsla(var(--color-base-white), 100%, 1);
-	}
-
-	.sponsors {
-		display: grid;
-		padding-left: 1rem;
-		padding-top: 0.25rem;
-		margin-bottom: -0.375rem; // logo overshoot creates extra perceived space
-		grid-gap: 0.5rem;
-		grid-template-columns: repeat(auto-fit, minmax(80px, 1fr));
-
-		svg {
-			color: var(--theme-text);
-			fill: currentColor;
-		}
-	}
-
-	.sponsor-logo__netlify {
-		width: 90px;
-	}
-
-	.sponsor-logo__vercel {
-		width: 90px;
-	}
-	:global(:root.theme-dark .sponsors-title) {
-		color: hsl(var(--color-base-gray), 75%);
-	}
-	.sponsors-title {
-		color: hsl(var(--color-base-gray), 25%);
-		font-size: 0.8em;
-		font-weight: 300;
-		letter-spacing: 0.0625em;
-		margin: 0 0 0.5rem;
-		padding-left: 1rem;
-		text-transform: uppercase;
-	}
-</style>
--- a/docs/src/components/PageContent/PageContent.astro
+++ b/docs/src/components/PageContent/PageContent.astro
@ -1,78 +0,0 @@
---
-import MoreMenu from '../RightSidebar/MoreMenu.astro';
-import TableOfContents from '../RightSidebar/TableOfContents.tsx';
-import { getLanguageFromURL } from '../../util.ts';
-import { SIDEBAR } from '../../config.ts';
-const { content, githubEditUrl, currentPage } = Astro.props;
-const title = content.title;
-const headers = content.astro?.headers;
-const langCode = getLanguageFromURL(currentPage);
-const links = SIDEBAR[langCode].filter(
-	(x) => x.link && typeof x.header === 'undefined'
-);
-// handle cases with a trailing slash or not
-const index = links.findIndex(
-	(x) => `/${x.link}/` === currentPage || `/${x.link}` === currentPage
-);
-const next =
-	index !== -1 ? (index === links.length - 1 ? null : links[index + 1]) : null;
-const previous = index !== -1 ? (index === 0 ? null : links[index - 1]) : null;
---
-
-<article id="article" class="content">
-	<section class="main-section">
-		<h1 class="content-title" id="overview">{title}</h1>
-		{headers && (
-			<nav class="block sm:hidden">
-				<TableOfContents client:media="(max-width: 50em)" headers={headers} />
-			</nav>
-		)}
-		<slot />
-	</section>
-	<nav class="block sm:hidden">
-		<MoreMenu editHref={githubEditUrl} />
-	</nav>
-	{(previous || next) && (
-		<aside>
-			{previous && (
-				<div>
-					Previous Article:{' '}
-					<a rel="prev" href={new URL(previous.link, Astro.site).pathname}>
-						{previous.text}
-					</a>
-				</div>
-			)}
-			{next && (
-				<div>
-					Next Article:{' '}
-					<a rel="next" href={new URL(next.link, Astro.site).pathname}>
-						{next.text}
-					</a>
-				</div>
-			)}
-		</aside>
-	)}
-</article>
-
-<style>
-	.content {
-		padding: 0;
-		max-width: 75ch;
-		width: 100%;
-		height: 100%;
-		display: flex;
-		flex-direction: column;
-	}
-	.content > section {
-		margin-bottom: 4rem;
-	}
-	.block {
-		display: block;
-	}
-
-	@media (min-width: 50em) {
-		.sm\:hidden {
-			display: none;
-		}
-	}
-</style>
--- a/docs/src/components/RightSidebar/MoreMenu.astro
+++ b/docs/src/components/RightSidebar/MoreMenu.astro
@ -1,91 +0,0 @@
---
-import ThemeToggleButton from './ThemeToggleButton.tsx';
-const { editHref } = Astro.props;
---
-
-<h2 class="heading">More</h2>
-<ul>
-	<li class={`header-link depth-2`}>
-		<a class="edit-on-github" href={editHref} target="_blank">
-			<svg
-				aria-hidden="true"
-				focusable="false"
-				data-prefix="fas"
-				data-icon="pen"
-				class="svg-inline--fa fa-pen fa-w-16"
-				role="img"
-				xmlns="http://www.w3.org/2000/svg"
-				viewBox="0 0 512 512"
-				height="1em"
-				width="1em"
-			>
-				<path
-					fill="currentColor"
-					d="M290.74 93.24l128.02 128.02-277.99 277.99-114.14 12.6C11.35 513.54-1.56 500.62.14 485.34l12.7-114.22 277.9-277.88zm207.2-19.06l-60.11-60.11c-18.75-18.75-49.16-18.75-67.91 0l-56.55 56.55 128.02 128.02 56.55-56.55c18.75-18.76 18.75-49.16 0-67.91z"
-				></path>
-			</svg>
-			<span>Edit this page</span>
-		</a>
-	</li>
-	<li class={`header-link depth-2`}>
-		<a
-			href="https://github.com/withastro/astro/blob/main/CONTRIBUTING.md#translations"
-			target="_blank"
-		>
-			<svg
-				aria-hidden="true"
-				focusable="false"
-				role="img"
-				xmlns="http://www.w3.org/2000/svg"
-				viewBox="0 0 88.6 77.3"
-				height="1.24em"
-				width="1.24em"
-				style="margin: -2px;"
-			>
-				<path
-					fill="currentColor"
-					d="M61,24.6h7.9l18.7,51.6h-7.7l-5.4-15.5H54.3l-5.6,15.5h-7.2L61,24.6z M72.6,55l-8-22.8L56.3,55H72.6z"
-				></path>
-				<path
-					fill="currentColor"
-					d="M53.6,60.6c-10-4-16-9-22-14c0,0,1.3,1.3,0,0c-6,5-20,13-20,13l-4-6c8-5,10-6,19-13c-2.1-1.9-12-13-13-19h8          c4,9,10,14,10,14c10-8,10-19,10-19h8c0,0-1,13-12,24l0,0c5,5,10,9,19,13L53.6,60.6z M1.6,16.6h56v-8h-23v-7h-9v7h-24V16.6z"
-				></path>
-			</svg>
-			<span>Translate this page</span>
-		</a>
-	</li>
-	<li class={`header-link depth-2`}>
-		<a href="https://astro.build/chat" target="_blank">
-			<svg
-				aria-hidden="true"
-				focusable="false"
-				data-prefix="fas"
-				data-icon="comment-alt"
-				class="svg-inline--fa fa-comment-alt fa-w-16"
-				role="img"
-				xmlns="http://www.w3.org/2000/svg"
-				viewBox="0 0 512 512"
-				height="1em"
-				width="1em"
-			>
-				<path
-					fill="currentColor"
-					d="M448 0H64C28.7 0 0 28.7 0 64v288c0 35.3 28.7 64 64 64h96v84c0 9.8 11.2 15.5 19.1 9.7L304 416h144c35.3 0 64-28.7 64-64V64c0-35.3-28.7-64-64-64z"
-				></path>
-			</svg>
-			<span>Join our community</span>
-		</a>
-	</li>
-</ul>
-<div style="margin: 2rem 0; text-align: center;">
-	<ThemeToggleButton client:visible />
-</div>
-
-<style>
-	.edit-on-github {
-		text-decoration: none;
-		font: inherit;
-		color: inherit;
-		font-size: 1rem;
-	}
-</style>
--- a/docs/src/components/RightSidebar/RightSidebar.astro
+++ b/docs/src/components/RightSidebar/RightSidebar.astro
@ -1,29 +0,0 @@
---
-import TableOfContents from './TableOfContents.tsx';
-import MoreMenu from './MoreMenu.astro';
-const { content, githubEditUrl } = Astro.props;
-const headers = content.astro?.headers;
---
-
-<nav class="sidebar-nav" aria-labelledby="grid-right">
-	<div class="sidebar-nav-inner">
-		{headers && (
-			<TableOfContents client:media="(min-width: 50em)" headers={headers} />
-		)}
-		<MoreMenu editHref={githubEditUrl} />
-	</div>
-</nav>
-
-<style>
-	.sidebar-nav {
-		width: 100%;
-		position: sticky;
-		top: 0;
-	}
-	.sidebar-nav-inner {
-		height: 100%;
-		padding: 0;
-		padding-top: var(--doc-padding);
-		overflow: auto;
-	}
-</style>
--- a/docs/src/components/RightSidebar/TableOfContents.tsx
+++ b/docs/src/components/RightSidebar/TableOfContents.tsx
@ -1,55 +0,0 @@
-import type { FunctionalComponent } from 'preact';
-import { h, Fragment } from 'preact';
-import { useState, useEffect, useRef } from 'preact/hooks';
-
-const TableOfContents: FunctionalComponent<{ headers: any[] }> = ({
-	headers = [],
-}) => {
-	const itemOffsets = useRef([]);
-	const [activeId, setActiveId] = useState<string>(undefined);
-
-	useEffect(() => {
-		const getItemOffsets = () => {
-			const titles = document.querySelectorAll('article :is(h1, h2, h3, h4)');
-			itemOffsets.current = Array.from(titles).map((title) => ({
-				id: title.id,
-				topOffset: title.getBoundingClientRect().top + window.scrollY,
-			}));
-		};
-
-		getItemOffsets();
-		window.addEventListener('resize', getItemOffsets);
-
-		return () => {
-			window.removeEventListener('resize', getItemOffsets);
-		};
-	}, []);
-
-	return (
-		<>
-			<h2 class="heading">On this page</h2>
-			<ul>
-				<li
-					class={`header-link depth-2 ${
-						activeId === 'overview' ? 'active' : ''
-					}`.trim()}
-				>
-					<a href="#overview">Overview</a>
-				</li>
-				{headers
-					.filter(({ depth }) => depth > 1 && depth < 4)
-					.map((header) => (
-						<li
-							class={`header-link depth-${header.depth} ${
-								activeId === header.slug ? 'active' : ''
-							}`.trim()}
-						>
-							<a href={`#${header.slug}`}>{header.text}</a>
-						</li>
-					))}
-			</ul>
-		</>
-	);
-};
-
-export default TableOfContents;
--- a/docs/src/components/RightSidebar/ThemeToggleButton.css
+++ b/docs/src/components/RightSidebar/ThemeToggleButton.css
@ -1,38 +0,0 @@
-.theme-toggle {
-	display: inline-flex;
-	align-items: center;
-	gap: 0.25em;
-	padding: 0.33em 0.67em;
-	border-radius: 99em;
-	background-color: var(--theme-code-inline-bg);
-}
-
-.theme-toggle > label:focus-within {
-	outline: 2px solid transparent;
-	box-shadow: 0 0 0 0.08em var(--theme-accent), 0 0 0 0.12em white;
-}
-
-.theme-toggle > label {
-	color: var(--theme-code-inline-text);
-	position: relative;
-	display: flex;
-	align-items: center;
-	justify-content: center;
-	opacity: 0.5;
-	cursor: pointer;
-}
-
-.theme-toggle .checked {
-	color: var(--theme-accent);
-	opacity: 1;
-}
-
-input[name='theme-toggle'] {
-	position: absolute;
-	opacity: 0;
-	top: 0;
-	right: 0;
-	bottom: 0;
-	left: 0;
-	z-index: -1;
-}
--- a/docs/src/components/RightSidebar/ThemeToggleButton.tsx
+++ b/docs/src/components/RightSidebar/ThemeToggleButton.tsx
@ -1,83 +0,0 @@
-import type { FunctionalComponent } from 'preact';
-import { h, Fragment } from 'preact';
-import { useState, useEffect } from 'preact/hooks';
-import './ThemeToggleButton.css';
-
-const themes = ['light', 'dark'];
-
-const icons = [
-	<svg
-		xmlns="http://www.w3.org/2000/svg"
-		width="20"
-		height="20"
-		viewBox="0 0 20 20"
-		fill="currentColor"
-	>
-		<path
-			fill-rule="evenodd"
-			d="M10 2a1 1 0 011 1v1a1 1 0 11-2 0V3a1 1 0 011-1zm4 8a4 4 0 11-8 0 4 4 0 018 0zm-.464 4.95l.707.707a1 1 0 001.414-1.414l-.707-.707a1 1 0 00-1.414 1.414zm2.12-10.607a1 1 0 010 1.414l-.706.707a1 1 0 11-1.414-1.414l.707-.707a1 1 0 011.414 0zM17 11a1 1 0 100-2h-1a1 1 0 100 2h1zm-7 4a1 1 0 011 1v1a1 1 0 11-2 0v-1a1 1 0 011-1zM5.05 6.464A1 1 0 106.465 5.05l-.708-.707a1 1 0 00-1.414 1.414l.707.707zm1.414 8.486l-.707.707a1 1 0 01-1.414-1.414l.707-.707a1 1 0 011.414 1.414zM4 11a1 1 0 100-2H3a1 1 0 000 2h1z"
-			clip-rule="evenodd"
-		/>
-	</svg>,
-	<svg
-		xmlns="http://www.w3.org/2000/svg"
-		width="20"
-		height="20"
-		viewBox="0 0 20 20"
-		fill="currentColor"
-	>
-		<path d="M17.293 13.293A8 8 0 016.707 2.707a8.001 8.001 0 1010.586 10.586z" />
-	</svg>,
-];
-
-function ThemeToggle() {
-	const [theme, setTheme] = useState(() => {
-		if (import.meta.env.SSR) {
-			return undefined;
-		}
-		if (typeof localStorage !== 'undefined' && localStorage.getItem('theme')) {
-			return localStorage.getItem('theme');
-		}
-		if (window.matchMedia('(prefers-color-scheme: dark)').matches) {
-			return 'dark';
-		}
-		return 'light';
-	});
-
-	useEffect(() => {
-		const root = document.documentElement;
-		if (theme === 'light') {
-			root.classList.remove('theme-dark');
-		} else {
-			root.classList.add('theme-dark');
-		}
-	}, [theme]);
-
-	return (
-		<div class="theme-toggle">
-			{themes.map((t, i) => {
-				const icon = icons[i];
-				const checked = t === theme;
-				return (
-					<label class={checked ? 'checked' : ''}>
-						{icon}
-						<input
-							type="radio"
-							name="theme-toggle"
-							checked={checked}
-							value={t}
-							title={`Use ${t} theme`}
-							aria-label={`Use ${t} theme`}
-							onChange={() => {
-								localStorage.setItem('theme', t);
-								setTheme(t);
-							}}
-						/>
-					</label>
-				);
-			})}
-		</div>
-	);
-}
-
-export default ThemeToggle;
--- a/docs/src/config.ts
+++ b/docs/src/config.ts
@ -1,204 +0,0 @@
-export const SIDEBAR = {
-	en: [
-		{ text: 'Setup', header: true },
-		{ 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: '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: '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: 'en/reference/builtin-components' },
-		{ text: 'API Reference', link: 'en/reference/api-reference' },
-		{ text: 'CLI Reference', link: 'en/reference/cli-reference' },
-		{
-			text: 'Configuration Reference',
-			link: 'en/reference/configuration-reference',
-		},
-		{ text: 'Renderer Reference', link: 'en/reference/renderer-reference' },
-	],
-	de: [
-		{ text: 'Einrichtung', header: true },
-		{ text: 'Erste Schritte', link: 'de/getting-started' },
-		{ text: 'Schnellstart', link: 'de/quick-start' },
-		{ text: 'Installation', link: 'de/installation' },
-		{ text: 'Vorlagen', link: 'de/themes' },
-		{ text: 'Astro vs. X', link: 'de/comparing-astro-vs-other-tools' },
-		{ text: 'Umstellung auf v0.21', link: 'de/migration/0.21.0' },
-
-		{ text: 'Grundlagen', header: true },
-		{ text: 'Projektstruktur', link: 'de/core-concepts/project-structure' },
-		{ text: 'Astro-Komponenten', link: 'de/core-concepts/astro-components' },
-		{ text: 'Astro-Seiten', link: 'de/core-concepts/astro-pages' },
-		{ text: 'Layouts', link: 'de/core-concepts/layouts' },
-		{ text: 'Routing', link: 'de/core-concepts/routing' },
-		{ text: 'Partial Hydration', link: 'de/core-concepts/component-hydration' },
-
-		{ text: 'Anleitungen', header: true },
-		{ text: 'Styling & CSS', link: 'de/guides/styling' },
-
-		{ text: 'Referenz', header: true },
-	],
-	nl: [
-		{ text: 'Welkom', header: true },
-		{ text: 'Beginnen', link: 'nl/getting-started' },
-		{ text: 'Snel start', link: 'nl/quick-start' },
-	],
-	fi: [
-		{ text: 'Tervetuloa', header: true },
-		{ text: 'Aloittaminen', link: 'fi/getting-started' },
-		{ text: 'Pika-aloitus', link: 'fi/quick-start' },
-		{ text: 'Asennus', link: 'fi/installation' },
-	],
-	es: [
-		{ text: 'Configuración', header: true },
-		{ text: 'Empezando', link: 'es/getting-started' },
-		{ text: 'Comienzo rápido', link: 'es/quick-start' },
-		{ text: 'Instalación', link: 'es/installation' },
-		{ text: 'Astro vs. X', link: 'es/comparing-astro-vs-other-tools' },
-
-		{ text: 'Fundamentos', header: true },
-		{
-			text: 'Estructura del Proyecto',
-			link: 'es/core-concepts/project-structure',
-		},
-		{
-			text: 'Sintaxis del Componente',
-			link: 'es/core-concepts/astro-components',
-		},
-		{ text: 'Páginas', link: 'es/core-concepts/astro-pages' },
-		{ text: 'Maquetas', link: 'es/core-concepts/layouts' },
-		{ text: 'Enrutamiento', link: 'es/core-concepts/routing' },
-		{
-			text: 'Hidratación parcial',
-			link: 'es/core-concepts/component-hydration',
-		},
-
-		{ text: 'Guías', header: true },
-		{ text: 'Estilo y CSS', link: 'es/guides/styling' },
-		{ text: 'Markdown', link: 'es/guides/markdown-content' },
-		{ text: 'Depuración', link: 'es/guides/debugging' },
-		{ text: 'Obtención de datos', link: 'es/guides/data-fetching' },
-		{ text: 'Paginación', link: 'es/guides/pagination' },
-		{ text: 'RSS', link: 'es/guides/rss' },
-		{ text: 'Importaciones admitidas', link: 'es/guides/imports' },
-		{ text: 'Alias', link: 'es/guides/aliases' },
-		{ text: 'Desplegar en la web', link: 'es/guides/deploy' },
-		{ text: 'Publicar en npm', link: 'es/guides/publish-to-npm' },
-
-		{ text: 'Referencia', header: true },
-		{
-			text: 'Componentes incorporados',
-			link: 'es/reference/builtin-components',
-		},
-		{ text: 'Referencia de API', link: 'es/reference/api-reference' },
-		{ text: 'Referencia de CLI', link: 'es/reference/cli-reference' },
-		{
-			text: 'Referencia de configuración',
-			link: 'es/reference/configuration-reference',
-		},
-		{
-			text: 'Referencia de renderizador',
-			link: 'es/reference/renderer-reference',
-		},
-	],
-	'zh-CN': [
-		{ text: '起步', header: true },
-		{ text: '入门指南', link: 'zh-CN/getting-started' },
-		{ text: '快速入门', link: 'zh-CN/quick-start' },
-		{ text: '安装指南', link: 'zh-CN/installation' },
-		{ text: '模板样例', link: 'zh-CN/examples' },
-		{
-			text: 'Astro 对比其他框架',
-			link: 'zh-CN/comparing-astro-vs-other-tools',
-		},
-	],
-	'zh-TW': [
-		{ text: '設定', header: true },
-		{ text: '新手上路', link: 'zh-TW/getting-started' },
-		{ text: '快速開始', link: 'zh-TW/quick-start' },
-		{ text: '安裝', link: 'zh-TW/installation' },
-		{ text: '佈景主題', link: 'zh-TW/themes' },
-	],
-	bg: [
-		{ text: 'Главни', header: true },
-		{ text: 'Започваме!', link: 'bg/getting-started' },
-	],
-	fr: [
-		{ text: 'Bienvenue', header: true },
-		{ text: 'Bien démarrer', link: 'fr/getting-started' },
-		{ text: 'Démarrage rapide', link: 'fr/quick-start' },
-		{ text: 'Installation', link: 'fr/installation' },
-	],
-	bn: [
-		{ text: 'সেটআপ', header: true },
-		{ text: 'শুরু করুন', link: 'bn/getting-started' },
-	],
-	kr: [
-		{ text: '환영합니다', header: true },
-		{ text: '시작하기', link: 'kr/getting-started' },
-	],
-	ar: [
-		{ text: 'التهيئة', header: true },
-		{ text: 'باشر البدأ', link: 'ar/getting-started' },
-	],
-	da: [
-		{ text: 'Velkommen', header: true },
-		{ text: 'Introduktion', link: 'da/getting-started' },
-	],
-	ja: [
-		{ text: 'セットアップ', header: true },
-		{ text: 'はじめに', link: 'ja/getting-started' },
-		{ text: 'クイックスタート', link: 'ja/quick-start' },
-		{ text: 'インストール', link: 'ja/installation' },
-		{ text: 'テーマ', link: 'ja/themes' },
-		{ text: 'Astro vs. X', link: 'ja/comparing-astro-vs-other-tools' },
-	],
-	ru: [
-		{ text: 'Введение', header: true },
-		{ text: 'Начало работы', link: 'ru/getting-started' },
-		{ text: 'Быстрый старт', link: 'ru/quick-start' },
-	],
-	it: [
-		{ text: 'Impostare', header: true },
-		{ text: 'Come iniziare', link: 'it/getting-started' },
-	],
-};
-
-export const SITE = {
-	title: 'Astro Documentation',
-	description: 'Build faster websites with less client-side Javascript.',
-};
-
-export const OPEN_GRAPH = {
-	locale: 'en_US',
-	image: {
-		src: '/default-og-image.png?v=1',
-		alt:
-			'astro logo on a starry expanse of space,' +
-			' with a purple saturn-like planet floating in the right foreground',
-	},
-	twitter: 'astrodotbuild',
-};
--- a/docs/src/data/components.json
+++ b/docs/src/data/components.json
@ -1,32 +0,0 @@
-{
-  "official": [],
-  "community": [
-    {
-      "name": "Accessible Astro Components",
-      "description": "A set of accessible modals, buttons, toggles and more.",
-      "github": "https://www.npmjs.com/package/accessible-astro-components",
-      "demo": null
-    },
-    {
-      "name": "Astro Static Tweet",
-      "description": "A lightweight static-HTML tweet embed.",
-      "github": "https://www.npmjs.com/package/@rebelchris/astro-static-tweet",
-      "demo": null
-    },
-    {
-      "name": "Astro SEO",
-      "description": "SEO tags for your website.",
-      "github": "https://github.com/jonasmerlin/astro-seo",
-      "demo": null
-    },
-    {
-      "name": "Astro SPA",
-      "description": "A component for Astro JS that turns a website into an SPA.",
-      "github": "https://www.npmjs.com/package/astro-spa",
-      "demo": [
-        "https://ohka-bots-site-astro-ksoqn4flk7-li4hm4z1a-tc-001.vercel.app/",
-        "https://astro-spafy-component-demo.netlify.app/"
-      ]
-    }
-  ]
-}
--- a/docs/src/data/themes.json
+++ b/docs/src/data/themes.json
@ -1,80 +0,0 @@
-{
-  "featured": [
-    {
-      "name": "Ink",
-      "description": "Crisp, minimal, personal blog theme for Astro",
-      "github": "https://github.com/one-aalam/astro-ink",
-      "demo": "https://astro-ink.vercel.app/",
-      "sandbox": "https://github.dev/one-aalam/astro-ink",
-      "command": "npm init astro -- --template one-aalam/astro-ink"
-    }
-  ],
-  "official": [
-    {
-      "name": "Starter Kit",
-      "description": "A default starter project for Astro. Flexible enough to handle anything that you might want to build.",
-      "github": "https://github.com/withastro/astro/tree/main/examples/starter",
-      "demo": null,
-      "sandbox": "https://github.dev/withastro/astro/tree/main/examples/starter",
-      "command": "npm init astro"
-    },
-    {
-      "name": "Docs",
-      "description": "A documentation website theme, complete with i18n, search, dark mode and more.",
-      "github": "https://github.com/withastro/astro/tree/main/examples/docs",
-      "demo": null,
-      "sandbox": "https://github.dev/withastro/astro/tree/main/examples/docs",
-      "command": "npm init astro -- --template docs"
-    },
-    {
-      "name": "Blog",
-      "description": "A blog theme, perfect for personal and company blogs.",
-      "github": "https://github.com/withastro/astro/tree/main/examples/blog",
-      "demo": null,
-      "sandbox": "https://github.dev/withastro/astro/tree/main/examples/blog",
-      "command": "npm init astro -- --template blog"
-    },
-    {
-      "name": "Portfolio",
-      "description": "A portfolio theme, perfect for your personal or professional online portfolio.",
-      "github": "https://github.com/withastro/astro/tree/main/examples/portfolio",
-      "demo": null,
-      "sandbox": "https://github.dev/withastro/astro/tree/main/examples/portfolio",
-      "command": "npm init astro -- --template portfolio"
-    },
-    {
-      "name": "Portfolio-svelte",
-      "description": "A portfolio theme using Svelte components, perfect for your personal or professional online portfolio.",
-      "github": "https://github.com/withastro/astro/tree/main/examples/portfolio-svelte",
-      "demo": null,
-      "sandbox": "https://github.dev/withastro/astro/tree/main/examples/portfolio-svelte",
-      "command": "npm init astro -- --template portfolio-svelte"
-    },
-    {
-      "name": "Minimal",
-      "description": "A minimal theme, with just the bare minimum needed to get started.",
-      "github": "https://github.com/withastro/astro/tree/main/examples/minimal",
-      "demo": null,
-      "sandbox": "https://github.dev/withastro/astro/tree/main/examples/minimal",
-      "command": "npm init astro -- --template minimal"
-    }
-  ],
-  "community": [
-    {
-      "name": "Accessible Astro Starter",
-      "description": "A starter project with accessible features using Astro static site builder.",
-      "github": "https://github.com/markteekman/accessible-astro-starter",
-      "demo": "https://accessible-astro.markteekman.nl/",
-      "sandbox": "https://github.dev/markteekman/accessible-astro-starter",
-      "command": "npm init astro -- --template markteekman/accessible-astro-starter"
-    },
-    {
-      "name": "Astro Theme Creek",
-      "description": "Creek is an open source blog theme for Astro SSG.",
-      "github": "https://github.com/robertguss/Astro-Theme-Creek",
-      "demo": "https://astro-theme-creek.netlify.app/",
-      "sandbox": "https://github.dev/robertguss/Astro-Theme-Creek",
-      "command": "npm init astro -- --template robertguss/Astro-Theme-Creek"
-    }
-  ]
-}
--- a/docs/src/layouts/MainLayout.astro
+++ b/docs/src/layouts/MainLayout.astro
@ -1,126 +0,0 @@
---
-import HeadCommon from '../components/HeadCommon.astro';
-import HeadSEO from '../components/HeadSEO.astro';
-import Header from '../components/Header/Header.astro';
-import Footer from '../components/Footer/Footer.astro';
-import PageContent from '../components/PageContent/PageContent.astro';
-import LeftSidebar from '../components/LeftSidebar/LeftSidebar.astro';
-import RightSidebar from '../components/RightSidebar/RightSidebar.astro';
-import { SITE } from '../config.ts';
-
-const { content = {}, hideRightSidebar = false } = Astro.props;
-const currentPage = Astro.request.url.pathname;
-const currentFile = `src/pages${currentPage.replace(/\/$/, '')}.md`;
-const githubEditUrl = `https://github.com/withastro/astro/blob/main/docs/${currentFile}`;
-const formatTitle = (content, SITE) =>
-	content.title ? `${content.title} 🚀 ${SITE.title}` : SITE.title;
---
-
-<html dir={content.dir ?? 'ltr'} lang={content.lang ?? 'en-us'} class="initial">
-	<head>
-		<HeadCommon />
-		<HeadSEO {content} canonicalURL={Astro.request.canonicalURL} />
-		<title>{formatTitle(content, SITE)}</title>
-		<style>
-			body {
-				width: 100%;
-				display: grid;
-				grid-template-rows: var(--theme-navbar-height) 1fr;
-				--gutter: 0.5rem;
-				--doc-padding: 2rem;
-			}
-			.layout {
-				display: grid;
-				grid-auto-flow: column;
-				grid-template-columns:
-					minmax(var(--gutter), 1fr)
-					minmax(0, var(--max-width))
-					minmax(var(--gutter), 1fr);
-				overflow-x: hidden;
-			}
-			.layout :global(> *) {
-				width: 100%;
-				height: 100%;
-			}
-			.grid-sidebar {
-				height: 100vh;
-				position: sticky;
-				top: 0;
-				padding: 0;
-			}
-			#grid-left {
-				position: fixed;
-				background-color: var(--theme-bg);
-				z-index: 10;
-				display: none;
-			}
-			#grid-main {
-				padding: var(--doc-padding) var(--gutter);
-				grid-column: 2;
-				display: flex;
-				flex-direction: column;
-				height: 100%;
-			}
-			#grid-right {
-				display: none;
-			}
-			:global(.mobile-sidebar-toggle) {
-				overflow: hidden;
-			}
-			:global(.mobile-sidebar-toggle #grid-left) {
-				display: block;
-				top: 2rem;
-			}
-			@media (min-width: 50em) {
-				.layout {
-					overflow: initial;
-					grid-template-columns:
-						20rem
-						minmax(0, var(--max-width));
-					gap: 1em;
-				}
-				#grid-left {
-					display: flex;
-					padding-left: 2rem;
-					position: sticky;
-					grid-column: 1;
-				}
-			}
-
-			@media (min-width: 72em) {
-				.layout {
-					grid-template-columns:
-						20rem
-						minmax(0, var(--max-width))
-						18rem;
-					padding-left: 0;
-					padding-right: 0;
-					margin: 0 auto;
-				}
-				#grid-right {
-					grid-column: 3;
-					display: flex;
-				}
-			}
-		</style>
-	</head>
-
-	<body>
-		<Header {currentPage} />
-		<main class="layout">
-			<aside id="grid-left" class="grid-sidebar" title="Site Navigation">
-				<LeftSidebar {currentPage} />
-			</aside>
-			<div id="grid-main">
-				<PageContent {content} {githubEditUrl} {currentPage}>
-					<slot />
-				</PageContent>
-			</div>
-			<aside id="grid-right" class="grid-sidebar" title="Table of Contents">
-				{!hideRightSidebar && (
-					<RightSidebar content={content} githubEditUrl={githubEditUrl} />
-				)}
-			</aside>
-		</main>
-	</body>
-</html>
--- a/docs/src/layouts/SplashLayout.astro
+++ b/docs/src/layouts/SplashLayout.astro
@ -1,48 +0,0 @@
---
-import HeadCommon from '../components/HeadCommon.astro';
-import Header from '../components/Header/Header.astro';
-import { SITE } from '../config.ts';
-
-const { title } = Astro.props;
---
-
-<html dir="ltr" lang="en-us" class="initial">
-	<head>
-		<HeadCommon />
-		<title>{`${title} 🚀 ${SITE.title}`}</title>
-		<style>
-			body {
-				width: 100%;
-				display: grid;
-				grid-template-rows: var(--theme-navbar-height) 1fr;
-				--gutter: 0.5rem;
-				--doc-padding: 2rem;
-			}
-			.layout {
-				display: grid;
-				grid-auto-flow: column;
-				grid-template-columns:
-					minmax(var(--gutter), 1fr)
-					minmax(0, var(--max-width))
-					minmax(var(--gutter), 1fr);
-				overflow-x: hidden;
-			}
-			article {
-				padding: var(--doc-padding) var(--gutter);
-				grid-column: 2;
-				display: flex;
-				flex-direction: column;
-				height: 100%;
-			}
-		</style>
-	</head>
-
-	<body>
-		<Header />
-		<main class="layout splash-layout">
-			<article>
-				<slot />
-			</article>
-		</main>
-	</body>
-</html>
--- a/docs/src/pages/404.astro
+++ b/docs/src/pages/404.astro
@ -1,9 +0,0 @@
---
-import SplashLayout from '../layouts/SplashLayout.astro';
---
-
-<SplashLayout title="Not Found">
-	<h1>404</h1>
-	<p>This page isn't in our solar system.</p>
-	<a href="/">Take me home.</a>
-</SplashLayout>
--- a/docs/src/pages/[...slug].astro
+++ b/docs/src/pages/[...slug].astro
@ -1,19 +0,0 @@
---
-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}`} />
--- a/docs/src/pages/ar/getting-started.md
+++ b/docs/src/pages/ar/getting-started.md
@ -1,80 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: باشر بالبدأ
-lang: ar
-dir: rtl
---
-
-Astro هو باني موقع ثابت. تعرف أكثر حول ماهية Astro من خلال [صفحتنا الرئيسية](https://astro.build/) أو نشرة [الإصدارات](https://astro.build/blog/introducing-astro). تُعد هذه الصفحة نُبذة موجزة للتوثيق الخاص بـAstro وأيضًا لكل المصادر التي تتعلق به.
-
-إن كنت تتطلع عن ملخص سريع حول ما هو Astro بشكلٍ عام؟ [تفقد صفحتنا الرئيسية.](https://astro.build/blog/introducing-astro)
-
-## جرب Astro
-
-أبسط طريقة لتجرب Astro هي بتنفيذ أمر `npm init astro` في داخل مُجلد جديد على جهازك، وسيقوم Astro CLI بمُساعدتك على بدأ مشروع Astro جديد.
-
-لتباشر البدأ باستخدام Astro من خلال 5 خطوات سريعة وبسيطة، تفقد [دليل البدأ-بسرعة](quick-start).
-
-أو إقرأ [دليل التثبيت](/installation) إن كنت تريد الغوص في عملية تهيئة Astro.
-
-### أمثلة على بعض المشاريع
-
-أن كنت تفضل التعلم عن طريق الأمثلة، ألقي نظرةٍ على [مكتبة الأمثلة الشاملة](https://github.com/withastro/astro/tree/main/examples) المتواجدة على Github.
-
-بمقدورك الإطلاع على أي من هذه الأمثلة وتجربتها مُباشرةً على جهازك،
-فقط نفذ الأمر <code ltr="left">npm init astro</code> متبوعًا بـ
-`--template`. الإشارة `--template` أيضًا تدعم الامثلة الخارجية التي يصنعها المجتمع
-
-```bash
-# أمر تهيئة أحد القوالب الرسمية التي يوفرها استرو
-npm init astro -- --template [OFFICIAL_EXAMPLE_NAME]
-# أمر تهيئة القوالب الخارجية التي يوفرها المُجتمع
-npm init astro -- --template [GITHUB_USER]/[REPO_NAME]
-npm init astro -- --template [GITHUB_USER]/[REPO_NAME]/path/to/example
-```
-
-### جربه على المُتصفح
-
-إن كنت مهتمًا وتريد اللعب وتجربة Astro على المتصفح، بمقدورك استخدام online code playground، جرب قالب مشروعنا "Hello World" على [CodeSandbox](https://codesandbox.io/s/astro-template-hugb3).
-
-_ملحوظة: بعض المُميزات مُقتصرة على CodeSandbx (مثلاً: التحديث السريع "Fast Refresh") حاليًا._
-
-## تعلمُ Astro
-
-يأتي العديد الأشخاص من خلفياتِ تعلم مُختلفة إلى Astro، أيًا كانت طريقة التعليم التي تفضلها سواءً أكنت تفضل الطريقة النظرية أو الطريقة العملية، نتمنى أن تجد هذا القسم مفيدًا.
-
- إن كُنت تُفضل **التعلم من خلال التجربة العملية**، أبدأ من خلال [مكتبتنا للأمثلة](https://github.com/withastro/astro/tree/main/examples).
- إن كُنت تُفضل **التعلم من خلال الفهم خطوةً بخطوة**، أبدأ من خلال [دليل المفاهيم الأساسية والإرشادات](/core-concepts/project-structure).
-
-مثل أي تقنيةٍ ليست بمألوفة، Astro يأتيك بمنحنى تعليمي مختلف بعض الشيء، ولكن على أي حال، مع بعض الصبر والممارسة، نحن متأكدون بأنك _ستتأقلم معه_ في وقتٍ هين دون أن تشعر.
-
-### تعلمُ تركيب <code dir="ltr">.astro</code> النحوي (syntax)
-
-مع بدأ تعلمك لـAstro ستلاحظ العديد من الملفات التي تنتهي بصيغة <code dir="ltr">.astro</code> هي ملفات مكتوبة بـ Astro’s Component Syntax والتي تعد: طريقة كتابة مشابهة جدًا لملفات HTML يستخدمها Astro في القوالب.
-صممت هذه الصيغة لتكون قريبة ومشابهة للـ HTML و JSX، إن كنت تعرف أحدهما فستتأقلم مع <code dir="ltr">.astro</code> بسهولة.
-
-تفقد دليلنا المساعد [مكونات Astro](/core-concepts/astro-components) سيكون مدخل يساعدك على تعلم Astro syntax، ويعد أفضل طريقة للتعلم.
-
-### مرجع للـAPI
-
-يُفيدك هذا الجزء من التوثيق حينما تريد الإطلاع أكثر بشأن تفاصيل Astro API. على سبيل المثال، يتضمن [مرجع الإعداد](/reference/configuration-reference) قائمة لكل الإعدادات الممكنة المتاحة لكي تستخدمها. [المكونات المصممة مسبقًا](/reference/builtin-components) تتضمن قائمة بكل العناصر الرئيسية مثل <span dir="ltr">`<Markdown />` و `<Code />`</span>.
-
-### إصدارات التوثيق
-
-هذا التوثيق يُسلط الضوء دومًا على أخر إصدار مستقر من Astro، وريثما نصل إلى إصدار 1.0 الرئيسي سنقوم بإضافة القابلية لتصفح اللإصدارات المختلفة من التوثيق.
-
-## أبقى مُطلعًا
-
-حساب [@astrodotbuild](https://twitter.com/astrodotbuild) على تويتر هو المصدر الرسمي لأخر المُستجدات من فريق Astro.
-
-ونحن أيضًا نُعد نشرة إصدارات ونعلن عنها في [مُجتمعنا على ديسكورد](https://astro.build/chat) على قناة <span dir="ltr">#announcements</span>
-
-ليست كل إصدارات Astro تملك تدوينة نشرةٍ خاصة بها، لكن ستجد سجلًا للتغيرات في ملف [`CHANGELOG.md` في مستودع Astro](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md).
-
-## شيءٌ ما ناقص؟
-
-إن كان هناك شيءُ ما غير مُوثق أو لو كنت تشعر بالحيرة والإرتباك من جزءٍ معين في التوثيق، لا تتردد في [رفع طلب خطبٌ ما في ملف التوثيق](https://github.com/withastro/astro/issues/new/choose)، مع اقتراحك للتحسين، أو قم بتغريد تغريدةٍ إلى حسابنا على تويتر [@astrodotbuild](https://twitter.com/astrodotbuild)، نحب سماع آرائك!
-
-## التَقدِير
-
-دليل باشر بالبدأ معتمدٌ على دليل البدأ الخاص بـ[React](https://ar.reactjs.org/).
--- a/docs/src/pages/bg/getting-started.md
+++ b/docs/src/pages/bg/getting-started.md
@ -1,60 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Започваме!
---
-
-Astro е модерен builder за статични сайтове. Научете всичко за Astro от [нашата начална страница](https://astro.build/) или от [release поста](https://astro.build/blog/introducing-astro). Тази страница е оглед на документацията на Astro и всички свързани ресурси.
-
-## Пробвайте Astro
-
-Най-лесният начин да пробвате Astro е да изпълните `npm init astro` в нова локална директория. Нашият CLI Wizard ще Ви помогне да започнете нов Astro проект.
-
-За да започнете с Astro в 5 бързи и лесни стъпки, посетете нашия [Гид за бърз старт](quick-start).
-
-Алтернативно, можете да прочетете нашия [Инсталационен гид](/installation) за всичко относно настройката на Astro.
-
-### Онлайн площадки (playgrounds)
-
-Ако искате да си експериментирате с Astro в браузъра, можете да използвате онлайн площадка за код. Пробвайте нашия "Hello World!" темплейт на [CodeSandbox](https://codesandbox.io/s/astro-template-hugb3).
-
-_Бележка: някои функционалности (например: Fast Refresh) са лимитирани на CodeSandbox засега._
-
-## Научете Astro
-
-Всякакви видове хора с различни методи за обучение се ориентират към Astro. Независимо дали предпочитате по-теоретичен, или по-практически подход, ние се надяваме че ще намерите тази секция за полезна.
-
- Ако предпочитате да **учите чрез практика**, започнете с нашата [библиотека с примери](https://github.com/withastro/astro/tree/main/examples).
- Ако предпочитате да **учите концепции стъпка по стъпка**, започнете с нашите [базови концепции и гидове](/core-concepts/project-structure).
-
-Като всяка непозната технология, Astro изисква известно време, за да се научи. Но с практика и малко търпение, ние сме сигурни, че _ще го схванете_ за нула време.
-
-### Научете `.astro` синтаксис
-
-Когато започнете да учите Astro, ще видите много файлове с разширение `.astro`. Това е **Компонентният синтаксис на Astro** -
-специален файлов формат наподобяващ HTML, който Astro използва за изграждане на страници (templating). Направен е, така че да е познат на всеки с HTML или JSX опит.
-
-Нашият помощен гид за [Astro компонентите](/core-concepts/astro-components) Ви запознава със синтаксисът на Astro и е най-добрият начин да се научите.
-
-### API Справка
-
-Тази секция е полезна, когато искате да научите повече детайли относно даден Astro API. Например - [Конфигурационната справка](/reference/configuration-reference) изброява всички възможни конфигурационни опции. [Справката за вградени компоненти](/reference/builtin-components) изброява всички възможни базови (core) компоненти, като `<Markdown />` и `<Code />`.
-
-### Версия на документацията
-
-Тази документация винаги рефлектира последната стабилна версия на Astro. Когато пуснем версия 1.0, ще добавим опция за преглед на предишни или бъдещи версии.
-
-## Бъдете информирани
-
-Официалният източник за новини от екипа на Astro е Twitter акаунтът - [@astrodotbuild](https://twitter.com/astrodotbuild).
-
-Публикуваме и съобщения относно нови версии в [нашия Discord сървър](https://astro.build/chat) в #announcements канала.
-
-Не всяка нова версия на Astro заслужава собствен блог пост, но можете да намерите регистър на промените за всеки релийз в [`CHANGELOG.MD` файла, намиращ се в репото на Astro](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md).
-
-## Нещо липсва?
-
-Ако нещо липсва в документацията или намирате нещо за объркващо, моля [подайте го като issue за документацията](https://github.com/withastro/astro/issues/new/choose) с Вашите предложения за подобрение или пуснете tweet към [@astrodotbuild](https://twitter.com/astrodotbuild). Обичаме да чуваме от Вас!
-
-## Credit
-
-Първоначално този гид е базиран на документацията на [React](https://reactjs.org/).
--- a/docs/src/pages/bn/getting-started.md
+++ b/docs/src/pages/bn/getting-started.md
@ -1,59 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: শুরু করুন
---
-
-Astro হচ্ছে একটি আধুনিক স্ট্যাটিক ওয়েবসাইট বিল্ডার। Astro সম্পর্কে বিস্তারিত জানুন [আমাদের হোমপেজ](https://astro.build/) থেকে অথবা [আমাদের রিলিজ পোস্ট](https://astro.build/blog/introducing-astro) থেকে। এই পেজটি Astro-এর ডকুমেন্টেশন এবং এ সম্পর্কিত সকল বিষয়ের একটি সারাংশ।
-
-## Astro ব্যবহার করুন
-
-Astro ব্যবহার করার সবচেয়ে সহজ উপায় হচ্ছে আপনার কম্পিউটারের নতুন কোন ফোল্ডারে `npm init astro` রান করা। আমাদের সিএলআই উইজার্ড আপনাকে একটি নতুন Astro প্রোজেক্ট শুরু করতে সাহায্য করবে।
-
-মাত্র ৫টি সহজ ও ছোট ধাপে Astro নিয়ে কাজ করা শুরু করতে , আমাদের [কুইকস্টার্ট গাইডটি](quick-start) চেক করুন।
-
-অথবা, Astro সেটআপ এর উপর সম্পূর্ণ একটি ওয়াকথ্রুর জন্য আমাদের [ইন্সটলেশন গাইডটি](/installation) চেক করুন।
-
-### অনলাইন প্লেগ্রাউন্ড
-
-আপনি যদি ব্রাউজারে Astro নিয়ে কাজ করতে চান, তাহলে আপনি একটি অনলাইন কোড প্লেগ্রাউন্ড ব্যবহার করতে পারেন। এজন্য আমাদের [কোডস্যান্ডবক্স](https://codesandbox.io/s/astro-template-hugb3)-এর "Hello World!" টেমপ্লেটটি ব্যবহার করতে পারেন।
-
-_দ্রষ্টব্য: বর্তমানে কোডস্যান্ডবক্সে কিছু ফিচার (যেমন: ফাস্ট রিফ্রেশ) প্রাথমিক পর্যায়ে রয়েছে।_
-
-## Astro শিখুন
-
-বিভিন্ন ব্যাকগ্রাউন্ডের বিভিন্ন ধরণের মানুষ বিভিন্ন পদ্ধতিতে শিখার আগ্রহ নিয়ে Astro-তে আসে। আপনি ব্যবহারিক বা তাত্ত্বিক যে পদ্ধতিতেই শিখতে পছন্দ করেন, আমাদের আশা এই অংশটি আপনাকে সহায়তা করবে।
-
- যদি আপনি **করে করে** শিখতে পছন্দ করেন, তাহলে আমাদের [উদাহরণগুলো](https://github.com/withastro/astro/tree/main/examples) দিয়ে শুরু করুন।
- আর যদি আপনি **ধাপে ধাপে** বিষয়গুলো বুঝতে চান, তাহলে আমাদের [মৌলিক ধারণা এবং সহায়িকাসমূহ](/core-concepts/project-structure) দেখুন।
-
-অন্যান্য যেকোনো অপরিচিত প্রযুক্তির মতো, Astro শিখতেও কিছুটা প্রচেষ্টার প্রয়োজন রয়েছে। কিন্তু, আমরা জানি, আপনি লেগে থাকলে অতি দ্রুতই এর সাথে মানিয়ে নিতে _পারবেন_।
-
-### `.astro` সিনট্যাক্স শিখুন
-
-আপনি যখন Astro শিখা শুরু করবেন, আপনি অনেকগুলো `.astro` ফাইল খেয়াল করবেন। এটা **Astro-এর কম্পোনেন্ট সিনট্যাক্স**, একটি বিশেষ এইচটিএমএল-এর মতো ফাইল ফরম্যাট যা Astro টেমপ্লেটিং-এর জন্য ব্যবহার করে। এটাকে এইচটিএমএল এবং জেএসএক্স-এর সাথে মিল রেখে তৈরি করা হয়েছে।
-
-আমাদের [Astro কম্পোনেন্ট](/core-concepts/astro-components)-এর উপর সহায়ক গাইডটি আপনাকে Astro সিনট্যাক্স-এর সাথে পরিচিত করে তুলবে, আর এটিই শিখার সবচেয়ে ভালো উপায়।
-
-### এপিআই রেফারেন্স
-
-যদি আপনি কোনো নির্দিষ্ট Astro এপিআই-এর সম্বন্ধে বিস্তারিত জানতে চান তাহলে এই ডকুমেন্টেশনটি আপনাকে সাহায্য করবে। উদাহরণস্বরূপ, [কনফিগারেশন রেফারেন্সে](/reference/configuration-reference) সকল কনফিগারেশন অপশনের তালিকা দেয়া আছে। [বিল্ট-ইন কম্পোনেন্টস রেফারেন্সে](/reference/builtin-components) সকল বিল্ট-ইন কম্পোনেন্টের তালিকা দেয়া আছে, যেমন `<Markdown />` আর `<Prism />`।
-
-### ভার্সনকৃত ডকুমেন্টেশন
-
-এই ডকুমেন্টেশনটি সবসময় Astro-এর লেটেস্ট ভার্সনকে প্রতিফলিত করে। যখন আমরা v1.0-এর মাইলফলকটি স্পর্শ করব, তখন আমরা ভার্সনকৃত ডকুমেন্টেশন ফিচারটি সংযোজন করব।
-
-## অবগত থাকুন
-
-[@astrodotbuild](https://twitter.com/astrodotbuild) টুইটার অ্যাকাউন্টটি Astro টিম থেকে যেকোনো আপডেট পাওয়ার অফিসিয়াল মাধ্যম।
-
-আমরা আমাদের [ডিসকর্ড সার্ভারের](https://astro.build/chat) **#announcements** চ্যানেলেও যেকোনো নতুন বিজ্ঞপ্তি প্রকাশ করে থাকি।
-
-প্রতিটি Astro রিলিজের জন্য আমরা নতুন ব্লগ পোস্ট করি না, কিন্তু আপনি Astro রিপোজিটরির [`CHANGELOG.md`](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md) ফাইলে প্রতিটি রিলিজের বিস্তারিত পরিবর্তনসূচি দেখতে পারবেন।
-
-## কিছু অনুপস্থিত মনে হচ্ছে?
-
-আপনার যদি ডকুমেন্টেশনে কোনো কিছু অনুপস্থিত মনে হয় বা কোনো অংশকে বিভ্রান্তিকর মনে হয়, তাহলে দয়া করে আপনার পরামর্শসহ [একটি ইস্যু ফাইল করুন](https://github.com/withastro/astro/issues/new/choose) অথবা [@astrodotbuild](https://twitter.com/astrodotbuild) টুইটার অ্যাকাউন্টটিতে টুইট করুন। আমরা আপনাদের পরামর্শ শুনতে সর্বদা আগ্রহী!
-
-## ক্রেডিট
-
-এই গাইডটি মূলত [React-এর](https://reactjs.org/) **শুরু করুন** গাইডের উপর ভিত্তি করে লিখা হয়েছিল।
--- a/docs/src/pages/da/getting-started.md
+++ b/docs/src/pages/da/getting-started.md
@ -1,75 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Introduktion
-description: En grundlæggende introduktion til Astro.
-lang: da
---
-
-Astro er en moderne statisk side bygger. Lær hvad Astro handler om på [vores hjemmeside](https://astro.build/) eller [vores udgivelsesmeddelelser](https://astro.build/blog/introducing-astro). Denne side er et overblik over Astro-dokumentationen og alle relaterede ressourcer.
-
-## Prøv Astro
-
-Den nemmeste måde at prøve Astro på er ved at køre `npm init astro` i en ny mappe på din maskine. Vores CLI-guide vil hjælpe dig med at starte et nyt Astro projekt.
-
-Besøg vores [Hurtigstartsguide](/quick-start) for at komme i gang med Astro i 5 hurtige og nemme trin.
-
-Alternativt kan du læse vores [Installationsguide](/installation) for en fuld gennemgang af hvordan du sætter Astro op.
-
-### Eksempelprojekter
-
-Hvis du foretrækker at lære Astro ved hjælp af eksempler, kan du tjekke vores [fulde bibliotek af eksempler](https://github.com/withastro/astro/tree/main/examples) på GitHub.
-
-Du kan tjekke alle disse eksempler på din lokale maskine ved at køre `npm init astro` med CLI-flaget `--template`. Flaget `--template` understøtter også tredjeparts-skabeloner lavet af fællesskabet.
-
-```bash
-# Kør init-guiden og brug denne officielle skabelon
-npm init astro -- --template [OFFICIEL_EKSEMPEL_NAVN]
-# Kør init-guiden og brug denne skabelon lavet af fællesskabet
-npm init astro -- --template [GITHUB_BRUGER]/[REPO_NAVN]
-npm init astro -- --template [GITHUB_BRUGER]/[REPO_NAVN]/sti/til/eksempel
-```
-
-### Online Legepladser
-
-Hvis du er interesseret i at lege med Astro i browseren, kan du straks starte et nyt Astro projekt med vores brugerflade på [astro.new](https://astro.new/).
-
-Du kan prøve Astro i online kodeeditorer som Stackblitz, CodeSandbox, Gitpod eller GitHub Codespaces. Klik på "Open in Stackblitz" linket i et af eksemplerne i vores [liste af eksempler](https://github.com/withastro/astro/tree/main/examples). Eller, [klik her](https://stackblitz.com/fork/astro) for at starte et nyt projekt i [Stackblitz](https://stackblitz.com/fork/astro).
-
-## Lær Astro
-
-Alle slags mennesker kommer til Astro fra forskellige baggrunde og medbringer forskellige læringsstile. Uanset om du foretrækker en mere teoretisk eller praktisk tilgang, håber vi at du finder dette afsnit nyttigt.
-
- Hvis du foretrækker at **lære ved at gøre**, kan du starte med vores [liste af eksempler](https://github.com/withastro/astro/tree/main/examples).
- Hvis du foretrækker at **lære koncepter trin for trin**, kan du starte med vores [grundlæggende koncepter og vejledninger](/core-concepts/project-structure).
-
-Som enhver anden ukendt teknologi har Astro en lille indlæringskurve. Men med øvelse og lidt tålmodighed, ved vi at du _vil_ få styr på det på ingen tid.
-
-### Lær `.astro` Syntaks
-
-Når du begynder at lære Astro, vil du se mange filer med filtypen `.astro`. Dette er **Astros Komponent Syntaks**: et specielt HTML-lignende filformat som Astro bruger til templating. Det er designet til at føles bekendt for alle med HTML- eller JSX-erfaring
-
-Vores nyttige guide om [Astro-komponenter](/core-concepts/astro-components) introducerer dig til Astro-syntaksen, og er den bedste måde at lære på.
-
-### API Reference
-
-Dette dokumentationsafsnit er nyttigt når du vil lære flere detaljer om en bestemt Astro API. F.eks. indeholder [Konfigurationsreference](/reference/configuration-reference) en liste over alle tilgængelige konfigurationsmuligheder. [Indbyggede komponenter-reference](/reference/builtin-components) indeholder en liste over alle tilgængelige kernekomponenter, såsom `<Markdown />` og `<Code />`.
-
-### Versioneret dokumentation
-
-Denne dokumentation afspejler altid den seneste stabile version af Astro. Når vi når v1.0-milepælen, vil vi tilføje muligheden for at se versioneret dokumentation.
-
-## Hold dig orienteret
-
-Twitter-kontoen [@astrodotbuild](https://twitter.com/astrodotbuild) er den officielle kilde til opdateringer fra Astro-teamet.
-
-Vi sender også udgivelsesmeddelelser til vores [Discord-fællesskab](https://astro.build/chat) i #announcements kanalen.
-
-Ikke hver Astro udgivelse fortjener sit eget blogindlæg, men du kan finde en detaljeret ændringsliste for hver udgivelse i [`CHANGELOG.md` filen i Astro-repositoriet](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md).
-
-## Mangler der noget?
-
-Hvis der mangler noget i dokumentationen, eller hvis du synes, at en del er forvirrende, skal du [indsende et Issue om dokumentationen](https://github.com/withastro/astro/issues/new/choose) med dit forslag til forbedringer, eller tweet på [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-kontoen. Vi elsker at høre fra dig!
-
-## Kredit
-
-Denne startvejledning var oprindeligt baseret på [React's](https://reactjs.org/) startvejledning.
--- a/docs/src/pages/de/404.astro
+++ b/docs/src/pages/de/404.astro
@ -1,9 +0,0 @@
---
-import SplashLayout from '../../layouts/SplashLayout.astro';
---
-
-<SplashLayout title="Nicht gefunden">
-	<h1>404</h1>
-	<p>Diese Seite befindet sich nicht in unserem Sonnensystem.</p>
-	<a href="/">Bring mich nach Hause.</a>
-</SplashLayout>
--- a/docs/src/pages/de/comparing-astro-vs-other-tools.md
+++ b/docs/src/pages/de/comparing-astro-vs-other-tools.md
@ -1,233 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Vergleiche Astro
-description: Vergleiche Astro mit anderen statischen Site-Renderern wie Gatsby, Next.js, Nuxt, Hugo, Eleventy und weiteren.
---
-
-Wir werden oft gefragt, "Wie verhält sich Astro im Vergleich zu meinem bevorzugten Site-Renderer **\_\_\_\_**?" Diese Anleitung wurde verfasst, um diese Frage für verschiedene populäre Site-Renderer und Astro-Alternativen zu beantworten.
-
-Falls dein bevorzugter Site-Renderer hier nicht aufgeführt ist, [frag uns danach in Discord](https://astro.build/chat).
-
-## Projektstatus
-
-Eine kurze Anmerkung zum Entwicklungsstand des Projektes: **Astro ist noch im Beta-Stadium.** Viele der Werkzeuge, die hier aufgeführt werden, sind sehr viel weiter fortgeschritten. Einige sind mehr als zwölf Jahre älter als Astro!
-
-Einige Features sind noch nicht verfügbar und Teile der API noch nicht vollständig. Wie auch immer, das Projekt wird bezüglich seiner Fehleranfälligkeit als stabil angesehen und verschiedene Websites wurden schon für den produktiven Einsatz mit Astro umgesetzt. Dies ist ein wichtiger Punkt, wenn es um eine Entscheidung in Bezug auf den Einsatz von Astro geht.
-
-## Docusaurus vs. Astro
-
-[Docusaurus](https://docusaurus.io/) ist ein populärer Dokumentationssite-Renderer. Docusaurus verwendet React, um deine Website-UI zu generieren, während Astro in diesem Bereich React, Preact, Vue, Svelte, Solid und andere unterstützt - sowie auch eine an HTML angelehnte Komponenten-Syntax, die sich ähnlich verhält wie HTML + JSX.
-
-Docusaurus wurde entwickelt, um Dokumentationswebsites zu erzeugen und bietet einige dokumentationsspezifische Features, über die Astro nicht verfügt. Stattdessen kannst du in Astro auf dokumentationsspezifische Features mittels einer offiziellen [`docs`](https://github.com/withastro/astro/tree/main/examples/docs)-Vorlage zugreifen, die du für deine Site verwenden kannst. Diese Dokumentationswebsite wurde unter Verwendung dieser Vorlage erstellt!
-
-### Leistungsvergleich Docusaurus vs. Astro
-
-In den meisten Fällen werden Astro-Websites deutlich schneller laden als Docusaurus-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt.
-
-Docusaurus unterstützt Partial Hydration nicht. Stattdessen wird die gesamte Seite im Browser mit JavaScript angereichert, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und insgesamt schlechterer Leistung deiner Website. Es gibt keine Möglichkeit dieses Verhalten in Docusaurus abzuschalten.
-
-### Fallstudie: Kompilieren einer Dokumentationswebsite
-
-[docusaurus.io/docs](https://docusaurus.io/docs) ist die offizielle Docusaurus-Dokumentationswebsite - kompiliert mit Docusaurus. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
-
- **Docusaurus Leistungswert**: 61 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocusaurus.io%2Fdocs)
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [docusaurus.io/docs](https://docusaurus.io/docs) lädt **238kB** JavaScript mit dem ersten Seitenaufruf während [docs.astro.build](https://docs.astro.build) **78.7kB** (67% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
-
-## Elder.js vs. Astro
-
-[Elder.js](https://elderguide.com/tech/elderjs/) ist ein Site-Renderer für Svelte mit stark ausgeprägten eigenen Vorstellungen.
-
-Elder.js verwendet Svelte, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
-
-Elder.js hat eine besondere Stellung in dieser Auflistung, da es neben Astro der einzige Site-Renderer ist, der [Partial Hydration](/de/core-concepts/component-hydration) unterstützt. Sowohl Astro als auch Elder.js vermeiden automatisch unnötiges JavaScript auf der Seite und reichern nur die Komponenten damit an, die dies benötigen. Elders API für Partial Hydration unterscheidet sich etwas von der, die Astro verwendet. Und Astro unterstützt einige Features, über die Elder.js nicht verfügt (wie z. B. `client:media`). Wie auch immer, beide Werkzeuge erzeugen bezüglich der Leistung betrachtet sehr ähnliche Sites.
-
-Elder.js verwendet eine spezifische Routing-Lösung, die für neue Entwickler ungewohnt erscheinen kann. Astro verwendet [dateibasiertes Routing](/de/core-concepts/routing), das sich für alle vertraut anfühlen sollte, die Erfahrung mit Next.js, SvelteKit oder auch anderen Site-Renderern wie Eleventy haben.
-
-Elder.js wurde entwickelt, um große Websites zu erzeugen - und behauptet, es könne eine Website mit ca 20.000 Seiten in weniger als 10 Minuten rendern (auf einer durchschnittlichen VM). Zum Zeitpunkt der Erstellung dieses Textes rendert Astro ca 1.000 Seiten in 66 Sekunden, aber wurde noch nicht mit Projekten im Umfang von 20.000 Seiten getestet. Astro ist noch in einem frühen Beta-Stadium, und Elder.js Render-Geschwindigkeit zu erreichen ist ein Ziel für Astro v1.0.
-
-Elder.js unterstützt sowohl statische Site-Generierung (SSG) als auch Server-seitiges Rendering (SSR). Zum jetzigen Zeitpunkt unterstützt Astro nur statische Site-Generierung (SSG).
-
-## Eleventy vs. Astro
-
-[Eleventy](https://www.11ty.dev/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Node.js.
-
-Eleventy verwendet verschiedene [ältere Sprachen für HTML-Templates](https://www.11ty.dev/docs/languages/), um deine Website zu rendern: Nunjucks, Liquid, Pug, EJS und andere. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Eleventy unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
-
-### Leistungsvergleich Eleventy vs. Astro
-
-Konzeptuell ist Eleventy auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Eleventy und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
-
-Eleventy erreicht dies, indem es dich dazu anhält JavaScript gänzlich zu vermeiden. Eleventy-Sites werden oft mit sehr wenig bis hin zu gar keinem JavaScript geschrieben. Dies wird allerdings dann zum Thema, wenn du tatsächlich Client-seitig JavaScript einsetzen musst. Es bleibt dann dir überlassen eine entsprechende Build-Pipeline für deine Skripte und weitere Elemente aufzubauen. Dies kann sich sehr zeitaufwendig gestalten, und es zwingt dich das Packen der Anwendung, sowie Minifizierung und weitere komplizierte Optimierungen von Hand aufzusetzen.
-
-Im Gegensatz dazu kompiliert Astro automatisch dein Client-seitiges JavaScript & CSS für dich. Astro entfernt automatisch unnötiges JavaScript von der Seite und reichert nur die individuellen Komponenten damit an, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Eleventy von Hand einzurichten, steht es dir in Astro bereits von vornherein zur Verfügung.
-
-## Gatsby vs. Astro
-
-[Gatsby](https://www.gatsbyjs.com/) ist eine beliebte Website- und Anwendungsbibliothek für React.
-
-Gatsby verwendet React, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
-
-Gatsby v4 unterstützt statische Site-Generierung (Static Site Generation, SSG) mit inkrementellen Rebuilds sowie verzögerte statische Generierung (Deferred Static Generation, DSG), aber auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
-
-Gatsby erfordert für deine gesamte Arbeit mit Site-Inhalten eine eigene GraphQL-API. Während einige Entwicklerinnen und Entwickler an diesem Modell Gefallen finden, besteht eine häufig geäußerte Kritik an Gatsby darin, dass dieses Modell auf Dauer zu komplex und schwer aufrechtzuerhalten ist, insbesondere wenn Sites sehr umfangreich werden. Für die Arbeit mit Astro ist GraphQL nicht erforderlich, stattdessen bietet es gewohnte API (wie `fetch()` und `await` auf oberster Ebene), um Daten nah bei ihrer Anwendung zu laden.
-
-### Leistungsvergleich Gatsby vs. Astro
-
-In den meisten Fällen werden Astro-Websites deutlich schneller laden als Gatsby-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt.
-
-Gatsby unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Gatsby verfügt über ein [Community Plugin](https://www.gatsbyjs.com/plugins/gatsby-plugin-no-javascript/), das sämtliches JavaScript von einer Seite entfernt, doch dies führt auch dazu, dass viele Websites nicht mehr wie beabsichtigt funktionieren. In Bezug auf Interaktivität auf einzelnen Seiten ist entprechend nur eine Entscheidung zwischen ganz oder gar nicht möglich.
-
-Gatsby verfügt über ein großes Plugin-Ökosystem, was in Abhängigkeit von dem, was du benötigst, Gatsby zur besseren Wahl machen kann. [gatsby-plugin-image](https://www.gatsbyjs.com/plugins/gatsby-plugin-image/) z. B. ist ein beliebtes Plugin für Bildoptimierungen, das Gatsby zur besseren Wahl für bilderlastige Websites machen könnte.
-
-### Fallstudie: Kompilieren einer Dokumentationswebsite
-
-[gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) ist die offizielle Gatsby-Dokumentationswebsite - kompiliert mit Gatsby. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
-
- **Gatsby Leistungswert**: 64 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwww.gatsbyjs.com%2Fdocs%2Fquick-start%2F)
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) lädt **417kB** JavaScript mit dem ersten Seitenaufruf während [docs.astro.build](https://docs.astro.build) **78.7kB** (81% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
-
-## Hugo vs. Astro
-
-[Hugo](https://gohugo.io/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Go.
-
-Hugo verwendet eine eigene [Templating Language](https://gohugo.io/templates/introduction/), um deine Website zu rendern. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte, Solid und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Hugo unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
-
-### Leistungsvergleich Hugo vs. Astro
-
-Konzeptuell ist Hugo auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Hugo und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
-
-Sowohl Hugo als auch Astro bieten von vornherein Unterstützung beim Kompilieren, Packen und Minifizieren von JavaScript. Astro entfernt automatisch unnötiges JavaScript von der Seite und reichert nur die individuellen Komponenten damit an, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Hugo von Hand einzurichten, steht es dir in Astro ebenfalls bereits von vornherein zur Verfügung.
-
-## Jekyll vs. Astro
-
-[Jekyll](https://jekyllrb.com/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Ruby.
-
-Jekyll verwendet eine ältere [Templating Language](https://jekyllrb.com/docs/liquid/) mit dem Namen Liquid, um deine Website zu rendern. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte, Solid und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Jekyll unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
-
-### Leistungsvergleich Jekyll vs. Astro
-
-Konzeptuell ist Jekyll auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Jekyll und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
-
-Jekyll erreicht dies, indem es dich dazu anhält JavaScript gänzlich zu vermeiden. Jekyll-Sites werden oft mit sehr wenig bis hin zu gar keinem JavaScript geschrieben. Dies wird allerdings dann zum Thema, wenn du tatsächlich Client-seitig JavaScript einsetzen musst. Es bleibt dann dir überlassen eine entsprechende Build-Pipeline für deine Skripte und weitere Elemente aufzubauen. Dies kann sich sehr zeitaufwendig gestalten, und es zwingt dich das Packen der Anwendung, sowie Minifizierung und weitere komplizierte Optimierungen von Hand aufzusetzen.
-
-Im Gegensatz dazu kompiliert Astro automatisch dein Client-seitiges JavaScript für dich. Astro sendet nur die minimal notwendige Menge an JavaScript an den Browser, minifiziert, gepackt und optimiert für die Veröffentlichung. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Jekyll von Hand einzurichten, steht es dir in Astro bereits von vornherein zur Verfügung.
-
-## SvelteKit vs. Astro
-
-[SvelteKit](https://kit.svelte.dev/) ist eine beliebte Website- und Anwendungsbibliothek für Svelte.
-
-SvelteKit verwendet Svelte, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
-
-Sowohl SvelteKit als auch Astro sind Bibliotheken für die Erzeugung von Websites. SvelteKit funktioniert am besten mit hochdynamischen Websites (wie Dashboards und Nachrichteneingängen), während Astro am besten mit größtenteils statischen Websites funktioniert (wie Content- und E-Commerce-Websites).
-
-SvelteKit unterstützt sowohl statische Site-Generierung (Static Site Generation, SSG) als auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
-
-### Leistungsvergleich SvelteKit vs. Astro
-
-In den meisten Fällen werden Astro-Websites schneller laden als SvelteKit-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt.
-
-SvelteKit unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. SvelteKit unterstützt mit [Page-Level Static und Zero-JavaScript Pages](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate) das Entfernen von JavaScript per Seite oder für die gesamte Anwendung. Wie auch immer, eine Unterstützung für die Anreicherung individueller Komponenten einer Seite ist nicht geplant. In Bezug auf Interaktivität auf einzelnen Seiten ist entprechend nur eine Entscheidung zwischen ganz oder gar nicht möglich.
-
-### Fallstudie: Kompilieren einer Dokumentationswebsite
-
-[kit.svelte.dev](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate) ist die offizielle SvelteKit-Dokumentationswebsite - kompiliert mit SvelteKit. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
-
-Ein wichtiger zu beachtender Unterschied zwischen beiden Sites im Test: SveltKits Dokumentation wird als einzelne Seite ausgeliefert, während Astros Dokumentation in einzelne Seiten geteilt ausgeliefert wird. Diese höhere Content-Last dürfte einen leicht negativen Einfluss auf die Leistung haben und ist nicht auf das Werkzeug an sich zurückzuführen.
-
- **SvelteKit Leistungswert**: 92 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fkit.svelte.dev%2Fdocs)
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Der Leistungswert von SvelteKit in diesem Test ist vergleichbar mit dem von Astro.
-
-## Next.js vs. Astro
-
-[Next.js](https://nextjs.org/) ist eine beliebte Website- und Anwendungsbibliothek für React.
-
-Next.js verwendet React, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
-
-Sowohl Next.js als auch Astro sind Bibliotheken für die Erzeugung von Websites. Next.js funktioniert am besten mit hochdynamischen Websites (wie Dashboards und Nachrichteneingängen), während Astro am besten mit größtenteils statischen Websites funktioniert (wie Content- und E-Commerce-Websites).
-
-Next.js unterstützt sowohl statische Site-Generierung (Static Site Generation, SSG) als auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
-
-### Leistungsvergleich Next.js vs. Astro
-
-In den meisten Fällen werden Astro-Websites deutlich schneller laden als Next.js-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt.
-
-Next.js unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Next.js verfügt über [Experimental Support](https://piccalil.li/blog/new-year-new-website/#heading-no-client-side-react-code) für vollständig statische, Null-JavaScript-Seiten. Wie auch immer, eine Unterstützung für die Anreicherung individueller Komponenten einer Seite ist nicht geplant. In Bezug auf Interaktivität auf einzelnen Seiten ist entprechend nur eine Entscheidung zwischen ganz oder gar nicht möglich.
-
-Next.js verfügt über sehr gute integrierte Bildoptimierungen, was Next.js zur besseren Wahl für bilderlastige Websites machen könnte.
-
-### Fallstudie: Kompilieren einer Dokumentationswebsite
-
-[nextjs.org/docs](https://nextjs.org/docs/getting-started) ist die offizielle Next.js-Dokumentationswebsite - kompiliert mit Next.js. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
-
- **Next.js Leistungswert**: 59 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnextjs.org%2Fdocs%2Fgetting-started)
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [nextjs.org/docs](https://nextjs.org/docs/getting-started) lädt **463kB** JavaScript mit dem ersten Seitenaufruf, während [docs.astro.build](https://docs.astro.build) **78.7kB** (83% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
-
-## Nuxt vs. Astro
-
-[Nuxt](https://nuxtjs.org/) ist eine beliebte Website- und Anwendungsbibliothek für Vue. Es ist ähnlich aufgebaut wie Next.js.
-
-Nuxt verwendet Vue, um deine Website zu rendern. Astro ist hierin flexibler: Du kannst frei entscheiden mit welcher UI-Komponenten-Bibliothek du deine Oberfläche erzeugen willst (React, Preact, Vue, Svelte, Solid und andere), oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX.
-
-Sowohl Nuxt als auch Astro sind Bibliotheken für die Erzeugung von Websites. Nuxt funktioniert am besten mit hochdynamischen Websites (wie Dashboards und Nachrichteneingängen), während Astro am besten mit größtenteils statischen Websites funktioniert (wie Content- und E-Commerce-Websites).
-
-Nuxt unterstützt sowohl statische Site-Generierung (Static Site Generation, SSG) als auch Server-seitiges Rendering (Server-Side Rendering, SSR). Zur Zeit unterstützt Astro nur statische Site-Generierung (SSG).
-
-### Leistungsvergleich Nuxt vs. Astro
-
-In den meisten Fällen werden Astro-Websites deutlich schneller laden als Nuxt-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt.
-
-Nuxt unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Es besteht keine Möglichkeit dieses Verhalten abzuschalten.
-
-Nuxt verfügt über sehr gute integrierte Bildoptimierungen, was Nuxt zur besseren Wahl für bilderlastige Websites machen könnte.
-
-### Fallstudie: Kompilieren einer Dokumentationswebsite
-
-[nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) ist die offizielle Nuxt-Dokumentationswebsite - kompiliert mit Nuxt. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
-
- **Nuxt Leistungswert**: 48 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnuxtjs.org%2Fdocs%2F2.x%2Fget-started%2Finstallation)
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) lädt **469kb** JavaScript mit dem ersten Seitenaufruf, während [docs.astro.build](https://docs.astro.build) **78.7kB** (83% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
-
-## VuePress vs. Astro
-
-[VuePress](https://vuepress.vuejs.org/guide/) ist ein populärer Dokumentationssite-Renderer auf der Grundlage von Vue. VuePress verwendet Vue, um deine Website-UI zu generieren, während Astro in diesem Bereich React, Preact, Vue, Svelte, Solid und andere unterstützt - sowie auch eine an HTML angelehnte Komponenten-Syntax, die sich ähnlich verhält wie HTML + JSX.
-
-VuePress wurde entwickelt, um Dokumentationswebsites zu erzeugen und bietet einige dokumentationsspezifische Features, über die Astro nicht verfügt. Stattdessen verfügst du in Astro über dokumentationsspezifische Features mittels einer offiziellen [`docs`](https://github.com/withastro/astro/tree/main/examples/docs)-Vorlage, die du für deine Site verwenden kannst. Diese Website wurde unter Verwendung dieser Vorlage erstellt!
-
-Evan You (Erfinder von Vue) arbeitet zur Zeit an einer neuen Version von VuePress, genannt [VitePress](https://vitepress.vuejs.org/). Wenn du eine moderne Alternative zu VuePress suchst, [lies Evans Post](https://github.com/withastro/astro/issues/1159#issue-974035962) darüber, warum VitePress hierfür eine bessere Option darstellen kann.
-
-### Leistungsvergleich VuePress vs. Astro
-
-In den meisten Fällen werden Astro-Websites deutlich schneller laden als VuePress-Websites. Dies liegt vor allem daran, dass Astro unnötiges JavaScript vermeidet und nur diejenigen Komponenten einer Seite mit JavaScript anreichert, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt.
-
-VuePress unterstützt Partial Hydration nicht und lässt stattdessen den Browser die gesamte Seite erneut laden und mit JavaScript anreichern, selbst wenn der größte Teil der Seite statisch ist. Dies führt zu längeren Ladezeiten und schlechterer Leistung für deine Website. Es besteht keine Möglichkeit dieses Verhalten abzuschalten.
-
-### Fallstudie: Kompilieren einer Dokumentationswebsite
-
-[vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) ist die offizielle VuePress-Dokumentationswebsite - kompiliert mit VuePress. Die Website bietet ein ausreichend ähnliches Design und ausreichend ähnliche Funktionalität, um sie mit der offiziellen Astro-Dokumentationswebsite zu vergleichen. Dies ermöglicht uns einen **_grob realistischen_** Vergleich zwischen beiden Site-Renderern.
-
- **Vuepress Leistungswert**: 63 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fvuepress.vuejs.org%2Fguide%2F)
- **Astro Leistungswert**: 99 von 100 [(vollständige Prüfung)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Ein wesentlicher Grund für diesen Leistungsunterschied liegt in Astros geringerer JavaScript-Last: [vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) lädt **166kb** JavaScript mit dem ersten Seitenaufruf, während [docs.astro.build](https://docs.astro.build) **78.7kB** (53% weniger JavaScript insgesamt) _nach_ dem ersten Seitenaufruf lädt.
-
-## Zola vs. Astro
-
-[Zola](https://www.getzola.org/) ist ein beliebter statischer Site-Renderer auf der Grundlage von Rust.
-
-Zola verwendet [Tera](https://tera.netlify.app/), um deine Website zu rendern. Astro erlaubt dir deine Websites mit deiner bevorzugten UI-Komponenten-Bibliothek (React, Preact, Vue, Svelte, Solid und andere) zu erzeugen, oder du verwendest die an HTML angelehnte Komponenten-Syntax von Astro, die sich ähnlich verhält wie HTML + JSX. Zola unterstützt keine modernen UI-Bibliotheken für die Erstellung von HTML-Templates.
-
-### Leistungsvergleich Zola vs. Astro
-
-Konzeptuell ist Zola auf Augenhöhe mit Astros "minimalistischem Einsatz von Client-seitigem JavaScript" bei der Web-Entwicklung. Zola und Astro bieten somit eine ähnliche Leistungsgrundlage durch ihre jeweilige Null-JavaScript-Strategie.
-
-Sowohl Zola als auch Astro bieten Unterstützung beim Kompilieren, Packen und Minifizieren von JavaScript. Zola benötigt hierfür ein zusätzliches Werkzeug wie Webpack, um JavaScript zu packen und zu verarbeiten. Astro entfernt automatisch unnötiges JavaScript von der Seite und reichert nur die individuellen Komponenten damit an, die dies benötigen. Dieses Feature wird [Partial Hydration](/de/core-concepts/component-hydration) genannt. Während es dir natürlich möglich ist dieses Feature in Zola von Hand einzurichten, steht es dir in Astro bereits von vornherein zur Verfügung.
--- a/docs/src/pages/de/core-concepts/astro-components.md
+++ b/docs/src/pages/de/core-concepts/astro-components.md
@ -1,386 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Astro-Komponenten
-description: Einführung in die .astro-Komponenten-Syntax.
---
-
-**Astro-Komponenten** (Dateien mit der Endung `.astro`) sind die Grundlage des Server-seitigen Templating in Astro. Du kannst dir die Astro-Komponenten-Syntax als HTML - erweitert um JavaScript - vorstellen.
-
-Eine neue Syntax kann zu Beginn einschüchternd wirken, daher haben wir bei der Entwicklung der Astro-Komponenten-Syntax besonders darauf geachtet, dass sie sich für Web-Entwickler so vertraut wie möglich anfühlt. Sie lehnt sich sehr stark an Modelle an, die du wahrscheinlich schon kennst: Komponenten, Frontmatter, Props und JSX-Ausdrücke. Wir sind zuversichtlich, dass du mit Hilfe dieser Anleitung in kürzester Zeit Astro-Komponenten schreiben wirst, besonders wenn du bereits mit HTML & JavaScript vertraut bist.
-
-## Syntax-Übersicht
-
-Eine einzelne `.astro`-Datei repräsentiert eine einzelne Astro-Komponente in deinem Projekt. Dieses Modell wird als **Single-File Component (SFC)** bezeichnet. Sowohl Svelte (`.svelte`) als auch Vue (`.vue`) folgen ebenfalls diesem Modell.
-
-Im Weiteren findest du eine eingehende Beschreibung der verschiedenen Elemente und Merkmale der Astro-Komponenten-Syntax. Du kannst sie von Anfang bis Ende durchlesen oder auch zwischen den Abschnitten springen.
-
-### HTML-Template
-
-Die Astro-Komponenten-Syntax ist eine Obermenge von HTML. **Wenn du HTML kennst, weißt du bereits genug, um deine erste Komponente zu schreiben.**
-
-Zum Beispiel ist diese dreizeilige Datei eine gültige Astro-Komponente:
-
-```html
-<!-- Beispiel1.astro - statisches HTML ist eine gültige Astro-Komponente! -->
-<div class="beispiel-1">
-  <h1>Hallo Welt!</h1>
-</div>
-```
-
-Eine Astro-Komponente repräsentiert einen Schnipsel HTML in deinem Projekt. Dies kann eine mehrfach verwendbare Komponente sein, oder eine vollständige Seite HTML einschließlich `<html>`-, `<head>`- und `<body>`-Elementen. Lies auch unsere Anleitung zu [Astro-Seiten](/de/core-concepts/astro-pages), um zu lernen wie du deine erste vollständige HTML-Seite mit Astro erzeugen kannst.
-
-**Jede Astro-Komponente muss ein HTML-Template beinhalten.** Auch wenn du deine Komponente auf vielfältige Weise erweitern kannst (siehe unten), bestimmt am Ende des Tages doch das HTML-Template, wie deine gerenderte Komponente aussehen wird.
-
-### CSS-Styles
-
-CSS-Regeln innerhalb eines `<style>`-Tag werden spezifisch nur auf diese Komponente angewendet. Das bedeutet auch, dass du Klassennamen über unterschiedliche Komponenten hinweg wiederholt verwenden kannst, ohne auf mögliche Konflikte achten zu müssen. Styles werden mit jedem Build automatisch extrahiert und optimiert, so dass du dir über das Laden der passenden Styles keine Gedanken machen musst.
-
-Um dabei die besten Ergebnisse zu erzielen, solltest du nicht mehr als ein `<style>`-Tag pro Astro-Komponente verwenden. Dies ist keine zwingende Beschränkung, wird aber oftmals zu einer besseren Optimierung des CSS in einem Build führen. Wenn du mit kompletten Seiten arbeitest, kann das `<style>`-Tag innerhalb des `<head>`
-Blocks stehen. In alleinstehenden Komponenten kann ein `<style>`-Tag in der oberste Ebene eines Template gesetzt werden.
-
-```html
-<!-- Astro-Komponente CSS-Beispiel -->
-<style>
-  .kreis {
-    background-color: red;
-    border-radius: 999px;
-    height: 50px;
-    width: 50px;
-  }
-</style>
-<div class="kreis"></div>
-```
-
-```html
-<!-- Astro-Seite CSS-Beispiel -->
-<html>
-  <head>
-    <style>
-      .kreis {
-        background-color: red;
-        border-radius: 999px;
-        height: 50px;
-        width: 50px;
-      }
-    </style>
-  </head>
-  <body>
-    ...
-  </body>
-</html>
-```
-
-Die Verwendung von `<style global>` schaltet die ausschließlich spezifische Anwendung auf die enthaltende Komponente oder Seite für jede CSS-Regel im `<style>`-Block aus. Diese Umgehung sollte wann immer möglich vermieden werden, kann aber nützlich sein, wenn du zum Beispiel das Styling von HTML-Elementen aus einer externen Bibliothek ändern musst.
-
-Sass (eine Alternative zu CSS) ist ebenfalls verfügbar via `<style lang="scss">`.
-
-📚 Lies unsere vollständige Anleitung zum [Styling von Komponenten](/guides/styling), um mehr zu erfahren.
-
-### Frontmatter-Skript
-
-Um dynamische Komponenten zu erzeugen, bringen wir die Idee eines Frontmatter-Komponenten-Skripts ein. [Frontmatter](https://jekyllrb.com/docs/front-matter/) ist ein in Markdown übliches Muster, bei dem Konfigurations- und Metadaten innerhalb einer Code-Begrenzung (`---`) am Anfang der Datei stehen. Astro bietet etwas Vergleichbares, jedoch mit vollständiger Unterstützung für JavaScript & TypeScript innerhalb deiner Komponenten.
-
-Bedenke dass Astro eine Server-seitige Template-Sprache ist, also wird dein Komponenten-Skript während des Build ausgeführt, aber für den Browser wird nur das HTML gerendert. Um auch JavaScript an den Browser zu senden, kannst du ein `<script>`-Tag in deinem HTML-Template verwenden - oder du [konvertierst deine Komponente für die Verwendung einer bestimmten Frontend-Bibliothek](/de/core-concepts/component-hydration) wie React, Svelte, Vue etc.
-
-```astro
---
-// Alles innnerhalb der `---`-Code-Begrenzung ist dein Komponenten-Skript.
-// Dieser JavaScript-Code wird während des Build ausgeführt.
-// Siehe weiter unten, was du damit machen kannst.
-console.log('Dies hier wird mit dem Build ausgeführt - ist in der CLI-Ausgabe zu sehen');
-// Tipp: TypeScript wird ebenfalls direkt unterstützt!
-const thisWorks: number = 42;
---
-<div class="example-1">
-  <h1>Hallo Welt!</h1>
-</div>
-```
-
-### Komponenten-Importe
-
-Eine Astro-Komponente kann andere Astro-Komponenten innerhalb des eigenen HTML-Template wiederverwenden. Dies legt den Grundstein für unser Komponenten-System: Erzeuge neue Komponenten und verwende sie anschließend überall in deinem Projekt.
-
-Um eine Astro-Komponente in deinem Projekt zu verwenden, musst du sie zunächst im Frontmatter-Komponenten-Skript importieren. Eine Astro-Komponente ist immer der Standard-Import der Datei.
-
-Einmal importiert, kannst du sie wie jedes andere HTML-Element in deinem Template verwenden. Beachte dass eine Astro-Komponente mit einem Großbuchstaben beginnen **MUSS**. Astro nutzt dies, um zwischen nativen HTML-Elementen (`form`, `input`, etc.) und deinen eigenen Astro-Komponenten zu unterscheiden.
-
-```astro
---
-// Importiere deine Komponenten in deinem Komponenten-Skript...
-import EineKomponente from './EineKomponente.astro';
---
-<!-- ... und verwende sie dann in deinem HTML! -->
-<div>
-  <EineKomponente />
-</div>
-```
-
-📚 Du kannst auch Komponenten aus anderen Frontend-Bibliotheken wie React, Svelte, Vue und anderen importieren und verwenden. Lies unsere Anleitung zu [Partial Hydration](/de/core-concepts/component-hydration), um mehr zu erfahren.
-
-### Dynamische JSX-Ausdrücke
-
-Anstatt für dynamisches Templating unsere eigene Syntax zu entwickeln, geben wir dir den direkten Zugriff auf JavaScript innerhalb deines HTML, indem wir etwas verwenden, das sich wie [JSX](https://reactjs.org/docs/introducing-jsx.html) anfühlt.
-
-Astro-Komponenten können lokale Variablen innerhalb des Frontmatter-Skriptes definieren. Jedes Skript-Variable ist anschließend automatisch im HTML-Template darunter verfügbar.
-
-#### Dynamische Werte
-
-```astro
---
-const name = "Dein Name hier";
---
-<div>
-  <h1>Hallo {name}!</h1>
-</div>
-```
-
-#### Dynamische Attribute
-
-```astro
---
-const name = "Dein Name hier";
---
-<div>
-  <div data-name={name}>Attribut-Ausdrücke unterstützt</div>
-  <div data-hint={`Verwende Template Literals, um ${"variables"} zu mischen.`}>So gut!</div>
-</div>
-```
-
-#### Dynamisches HTML
-
-```astro
---
-const items = ["Hund", "Katze", "Schnabeltier"];
---
-<ul>
-  {items.map((item) => (
-    <li>{item}</li>
-  ))}
-</ul>
-```
-
-### Komponenten-Eigenschaften (Props)
-
-Eine Astro-Komponente kann Eigenschaften definieren und annehmen. Eigenschaften sind über die `Astro.props` global in deinem Frontmatter-Skript verfügbar.
-
-```astro
---
-// Beispiel: <EineKomponente greeting="(Optional) Hallo" name="Erforderlicher Name" />
-const { greeting = 'Hallo', name } = Astro.props;
---
-<div>
-    <h1>{greeting}, {name}!</h1>
-</div>
-```
-
-Du kannst deine Eigenschaften mit TypeScript definieren, indem du eine `Props`-Type-Schnittstelle exportierst. Astro wird automatisch jede exportierte `Props`-Type-Schnittstelle erfassen und Type-Warnungen/Errors für dein Projekt generieren und ausgeben.
-
-Stelle sicher, dass du alle `import`- und `export`-Anweisungen oben in der Komponente angibst - vor jeder weiteren JavaScript- oder TypeScript-Logik!
-
-```astro
---
-// Gib `import`- und `export`-Anweisungen zuerst
-// Beispiel: <EineKomponente />  (WARNUNG: "name"-Prop ist erforderlich)
-export interface Props {
-  name: string;
-  greeting?: string;
-}
-
-// Nachdem alle `import`- und `export`-Anweisungen gemacht sind, gib den Rest der Komponenten-Logik hier an
-const { greeting = 'Hallo', name } = Astro.props;
---
-<div>
-    <h1>{greeting}, {name}!</h1>
-</div>
-```
-
-Anschließend kannst du die Komponenten-Eigenschaften folgendermaßen weiterreichen:
-
-```astro
---
-// EineAndereKomponente.astro
-import EineKomponente from "./EineKomponente.astro";
-let firstName = "Welt!";
---
-<EineKomponente name={firstName}/>
-```
-
-### Slots
-
-`.astro`-Dateien verwenden das [`<slot>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/slot)-Tag, um Komponenten-Zusammenstellungen zu ermöglichen. Wenn du von React oder Preact kommst, entspricht dies dem Konzept der `children`. Du kannst dir das `<slot>`-Element als einen Platzhalter für Markup vorstellen, das von außerhalb der Komponente hinzugefügt wird.
-
-```astro
-<!-- Beispiel: MeineKomponente.astro -->
-<div id="meine-komponente">
-  <slot /> <!-- untergeordnete Elemente landen hier -->
-</div>
-
-<!-- Verwendung -->
-<MeineKomponente>
-  <h1>Hallo Welt!</h1>
-</MeineKomponente>
-```
-
-Beachte dass, wenn der `<slot>`-Tag in einem HTML-Template nicht verwendet wird, alle untergeordneten Elemente, die an die Komponente übergeben werden, nicht gerendert werden.
-
-Slots werden sogar noch mächtiger, wenn **benannte Slots** verwendet werden. Anders als ein einzelnes `<slot>`-Element, das _alle_ untergeordneten Elemente rendert, erlauben benannte Slots mehrere Orte zu bestimmen, an denen untergeordnete Elemente plaziert werden sollen.
-
-> **Beachte:** Das `slot`-Attribut ist nicht auf reines HTML beschränkt, Komponenten können `slot` ebenfalls verwenden!
-
-```astro
-<!-- Beispiel: MeineKomponente.astro -->
-<div id="meine-komponente">
-  <header>
-    <!-- Untergeordnete Elemente mit dem `slot="header"`-Attribut landen hier -->
-    <slot name="header" />
-  </header>
-  <main>
-    <!-- Untergeordnete Elemente ohne `slot`- oder mit dem `slot="default"`-Attribut landen hier -->
-    <slot />
-  </main>
-  <footer>
-    <!-- Untergeordnete Elemente mit dem `slot="footer"`-Attribut landen hier -->
-    <slot name="footer" />
-  </footer>
-</div>
-
-<!-- Verwendung -->
-<MeineKomponente>
-  <h1 slot="header">Hallo Welt!</h1>
-  <p>Lorem ipsum ...</p>
-  <FooterKomponente slot="footer" />
-</MeineKomponente>
-```
-
-Slots können auch **Fallback-Platzhalter** rendern. Wenn keine passenden untergeordneten Elemente an einen `<slot>` weitergereicht werden, wird dieses `<slot>`-Element seine eigenen untergeordneten Platzhalter-Elemente rendern.
-
-```astro
-<!-- MeineKomponente.astro -->
-<div id="meine-komponente">
-  <slot>
-    <h1>Ich werde gerendert, wenn dieser Slot keine untergeordneten Elemente hat!</h1>
-  </slot>
-</div>
-
-<!-- Verwendung -->
-<MeineKomponente />
-```
-
-### Fragmente & Mehrfache Elemente
-
-Ein Astro-Komponenten-Template kann so viele Elemente in der obersten Ebene rendern, wie du willst. Anders als bei anderen UI-Komponenten-Bibliotheken musst du nicht alles mit einzelnen `<div>`-Elementen umschließen, wenn du das nicht bevorzugst.
-
-```html
-<!-- Eine Astro-Komponente kann mehrere Elemente in der obersten Ebene beinhalten: -->
-<div id="a" />
-<div id="b" />
-<div id="c" />
-```
-
-Allerdings musst du innerhalb eines JSX-Ausdrucks mehrere Elemente immer mit einem **Fragment** umschließen. Fragmente lassen dich auf einmal mehrere Elementen rendern, ohne dem DOM zusätzliche Nodes hinzuzufügen. Dies wird bei JSX-Ausdrücken auf Grund einer Beschränkung in JavaScript vorausgesetzt: Du kannst niemals mehr als ein Element in einem JavaScript-Ausdruck oder einer JavaScript-Funktion `zurückgeben`. Die Verwendung eines Fragments löst dieses Problem.
-
-Ein Fragment muss mit `<>` öffnen und mit `</>` schließen. Keine Sorge, wenn du es vergisst, wird dich der Astro-Kompilierer daran erinnern.
-
-```astro
---
-const items = ["Hund", "Katze", "Schnabeltier"];
---
-<ul>
-  {items.map((item) => (
-    <>
-      <li>Rot {item}</li>
-      <li>Blau {item}</li>
-      <li>Grün {item}</li>
-    </>
-  ))}
-</ul>
-```
-
-### Priorisierte Skripte
-
-Standardmäßig macht Astro keine Annahmen dazu, wie deine Skripte bereitgestellt werden sollen. Wenn du also einer Seite oder einer Komponente ein `<script>`-Tag hinzufügst, wird es nicht angerührt.
-
-Wenn du jedoch die Skripte aus der Komponente lösen und an den Anfang der Seite verschieben und anschließend für die Veröffentlichung gebündelt haben möchtest, kannst du das mit priorisierten Skripten machen.
-
-Ein **priorisiertes Skript** sieht so aus:
-
-```astro
-<script hoist>
-  // Ein Inline-Skript
-</script>
-```
-
-Oder es kann auf eine externe Skript-Datei verweisen:
-
-```astro
-<script src={Astro.resolve('./meine-komponente.js')} hoist></script>
-```
-
-Ein priorisiertes Skript kann innerhalb einer Seite oder Komponente stehen, und unabhängig davon wie oft die Komponente verwendet wird, das Skript wird nur einmal hinzugefügt:
-
-```astro
---
-import TwitterTimeline from '../components/TwitterTimeline.astro';
---
-
-<-- Das Skript wird nur einmal in den `head`-Block eingefügt. -->
-<TwitterTimeline />
-<TwitterTimeline />
-<TwitterTimeline />
-```
-
-## Vergleich `.astro` vs. `.jsx`
-
-`.astro`-Dateien können im Laufe der Entwicklung `.jsx`-Dateien sehr ähnlich werden, aber es gibt einige wesentliche Unterschiede. Hier ein Vergleich beider Formate.
-
-| Merkmal                        | Astro                                               | JSX                                                   |
-| ------------------------------ | --------------------------------------------------- | ----------------------------------------------------- |
-| Dateiendungen                  | `.astro`                                            | `.jsx` or `.tsx`                                      |
-| Selbstdefinierte Komponenten   | `<Großschreibung>`                                  | `<Großschreibung>`                                    |
-| Syntax Ausdruck                | `{}`                                                | `{}`                                                  |
-| Spread-Attribute               | `{...props}`                                        | `{...props}`                                          |
-| Boolsche Attribute             | `autocomplete` === `autocomplete={true}`            | `autocomplete` === `autocomplete={true}`              |
-| Inline-Funktionen              | `{items.map(item => <li>{item}</li>)}`              | `{items.map(item => <li>{item}</li>)}`                |
-| IDE-Unterstützung              | WIP - [VS Code][code-ext]                           | Phänomenal                                            |
-| Benötigt JS-Import             | Nein                                                | Ja, (`React` oder `h`) müssen im Geltungsbereich sein |
-| Fragmente                      | Autom. oberste Ebene, `<>` innerhalb von Funktionen | Einfassen mit `<Fragment>` oder `<>`                  |
-| Mehrere Bibliotheken pro Datei | Ja                                                  | Nein                                                  |
-| Änderungen von `<head>`        | Einfach `<head>` verwenden                          | Je nach Bibliothek (`<Head>`, `<svelte:head>`, etc.)  |
-| Kommentarstil                  | `<!-- HTML -->`                                     | `{/* JavaScript */}`                                  |
-| Spezielle Zeichen              | `&nbsp;`                                            | `{'\xa0'}` oder `{String.fromCharCode(160)}`          |
-| Attribute                      | `dash-case`                                         | `camelCase`                                           |
-
-## URL-Auflösung
-
-Es ist wichtig zu verstehen, dass Astro HTML-Referenzen **nicht** transformiert. Zum Beispiel in einem `<img>`-Tag mit einem relativen `src`-Attribut in `src/pages/about.astro`:
-
-```html
-<!-- ❌ Inkorrekt: wird versuchen `/about/thumbnail.png` zu laden -->
-<img src="./thumbnail.png" />
-```
-
-Da `src/pages/about.astro` als `/about/index.html` gespeichert wird, wird es dich möglicherweise überraschen, dass das Bild nach `/about/thumbnail.png` gespeichert wird. Um Konflikte zu vermeiden, wähle eine der zwei folgenden Optionen:
-
-#### Option 1: Absolute URL
-
-```html
-<!-- ✅ Korrekt: referenziert public/thumbnail.png -->
-<img src="/thumbnail.png" />
-```
-
-Der empfohlene Ansatz ist Dateien innerhalb von `public/*` zu speichern. Dies referenziert eine Datei unter `public/thumbnail.png`, welche nach dem Build zu `/thumbnail.png` aufgelöst wird (da `public/` dabei unter `/` endet).
-
-#### Option 2: Asset-Import-Referenzen
-
-```astro
---
-//  ✅ Korrekt: referenziert src/thumbnail.png
-import thumbnailSrc from './thumbnail.png';
---
-
-<img src={thumbnailSrc} />
-```
-
-Falls du bevorzugst Assets gemeinsam mit Astro-Komponenten zu verwalten, kannst du die Datei mit JavaScript innerhalb des Komponenten-Skriptes importieren. Dies wird wie beabsichtigt funktionieren, erschwert jedoch die Referenzierung von `thumnail.png` an anderen Stellen innerhalb der Anwendung, da die finale URL nur schwer vorhersagbar ist (anders als mit Assets in `public/*`, wo sich die Adresse garantiert nie ändern wird).
-
-[code-ext]: https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode
--- a/docs/src/pages/de/core-concepts/astro-pages.md
+++ b/docs/src/pages/de/core-concepts/astro-pages.md
@ -1,67 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Astro-Seiten
-description: Eine Einführung in Astro-Seiten - Komponenten die wie vollständige Seiten funktionieren.
---
-
-**Seiten** sind eine spezielle Art der [Astro-Komponente](/de/core-concepts/astro-components), die das Routing, das Laden von Daten und das Templating für eine Seite deiner Website erledigt. Du kannst sie dir wie eine einfache Astro-Komponente vorstellen - jedoch mit erweiterter Zuständigkeit.
-
-Astro unterstützt Markdown für Content-lastige Seiten, wie Blog-Posts und Dokumentationen. Lies [Markdown-Inhalte](/guides/markdown-content), um mehr über das Schreiben von Seiten mit Markdown zu erfahren.
-
-## Dateibasiertes Routing
-
-Astro verwendet Seiten für etwas das **dateibasiertes Routing** genannt wird. Jede Datei in deinem `src/pages`-Verzeichnis wird eine Seite deiner Website - unter Verwendung des Dateinamens für die Festlegung der endgültigen Route.
-
-Astro-Komponenten (`.astro`) und Markdown-Dateien (`.md`) sind die einzigen Seitenformate, die in Astro unterstützt werden. Andere Seitentypen (wie z. B. `.jsx`-React-Komponenten) werden nicht unterstützt, aber du kannst andere Formate als UI-Komponenten _innerhalb_ einer `.astro`-Seite verwenden, um ein vergleichbares Ergebnis zu erhalten.
-
-```
-src/pages/index.astro       -> meinesite.com/
-src/pages/about.astro       -> meinesite.com/about
-src/pages/about/index.astro -> meinesite.com/about
-src/pages/about/me.astro    -> meinesite.com/about/me
-src/pages/posts/1.md        -> meinesite.com/posts/1
-```
-
-## Seiten-Templating
-
-Alle Astro-Komponenten geben HTML aus. Astro-Seiten geben ebenfalls HTML aus, müssen zusätzlich jedoch die besondere Aufgabe erfüllen eine vollständige _Seitenantwort_ zu liefern - einschließlich `<html>...</html>`, `<head>` ([MDN<span class="sr-only">- head</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head)) und `<body>` ([MDN<span class="sr-only">- body</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body)).
-
-`<!doctype html>` ist optional - es wird automatisch hinzugefügt.
-
-```astro
---
-// Beispiel: HTML-Seite Grundgerüst
---
-<!doctype html>
-<html>
-  <head>
-    <title>Titel des Dokuments</title>
-  </head>
-  <body>
-    <h1>Hallo, Welt!</h1>
-  </body>
-</html>
-```
-
-## Laden von Daten
-
-Astro-Seiten können Daten abrufen, die benötigt werden, um deine Seiten zu generieren. Astro stellt dir zwei verschiedene Werkzeuge dafür zur Verfügung, die dabei helfen: **fetch()** und **top-level await**.
-
-📚 Lies unsere [vollständige Anleitung](/guides/data-fetching) über das Abrufen von Daten, um mehr zu erfahren.
-
-```astro
---
-// Beispiel: Astro-Komponenten-Skripte, werden ausgeführt während des Build-Prozesses
-const response = await fetch('http://beispiel.de/filme.json');
-const data = await response.json();
-console.log(data);
---
-<!-- Ausgabe des Ergebnisses auf der Seite -->
-<div>{JSON.stringify(data)}</div>
-```
-
-## Eigene 404-Fehlerseite
-
-Um eine eigene allgemeine 404-Fehlerseite zu erhalten, erzeuge eine `404.astro`-Datei in `/src/pages`. Diese Datei kompiliert zu einer `404.html`-Seite. Die meisten [Veröffentlichungsdienste](/guides/deploy) können diese Seite aufgreifen und verwenden sie entsprechend.
-
-Dieses Verhalten unterscheidet sich von dem standardmäßigen Verhalten beim Kompilieren von `page.astro` (oder `page/index.astro`) zu `page/index.html`.
--- a/docs/src/pages/de/core-concepts/component-hydration.md
+++ b/docs/src/pages/de/core-concepts/component-hydration.md
@ -1,113 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Partial Hydration in Astro
-description: Lerne wie Partial Hydration unter Verwendung der "Islands-Architecture" in Astro funktioniert.
---
-
-**Astro generiert jede Website standardmäßig mit Null Client-seitigem JavaScript.** Verwende irgendeine Frontend-UI-Bibliothek, die dir gefällt (React, Svelte, Vue etc.), und Astro wird deine Arbeit im Build-Prozess automatisch als HTML rendern und sämtliches JavaScript entfernen. Dies führt dazu, dass jede Seite standardmäßig schnell lädt.
-
-Doch manchmal wird Client-seitiges JavaScript zwingend benötigt. Diese Anleitung zeigt, wie interaktive Komponenten in Astro funktionieren - unter Verwendung einer Technik die Partial Hydration (Partielle Anreicherung) genannt wird.
-
-```astro
---
-// Beispiel: Eine React-Komponente importieren und anschließend verwenden.
-// Standardmäßig rendert Astro die Komponente als HTML und CSS während deines Build
-// - ohne Client-seitiges JavaScript.
-// (Du brauchst Client-seitiges JavaScript? Lies weiter...)
-import MeineReactKomponente from '../components/MeineReactKomponente.jsx';
---
-<!-- 100% HTML, Null JavaScript! -->
-<MeineReactKomponente />
-```
-
-## Konzept: Partial Hydration
-
-Es gibt viele Fälle in denen du eine interaktive UI-Komponente benötigst, die im Browser ausgeführt wird:
-
- Ein Bilder-Karussel
- Eine Suche mit Auto-Vervollständigung
- Ein Toggle-Button zum Öffnen und Schließen einer Sidebar
- Ein "Jetzt kaufen"-Button
-
-In Astro ist es deine Aufgabe als Entwicklerin oder Entwickler innerhalb einer Seite die Ausführbarkeit von Komponenten im Browser ausdrücklich zu "deklarieren". Astro kann anschließend diese Information verwenden, um herauszufinden welches JavaScript benötigt wird - und die Seite um exakt das anreichern, was benötigt wird. Diese Technik wird als Partial Hydration bezeichnet.
-
-**Partial Hydration** -- das ausschließliche Anreichern der Komponenten, die JavaScript benötigen, während der Rest der Seite statisches HTML bleibt -- klingt eigentlich sehr einfach - und das sollte es auch sein! Websites wurden über Jahrzehnte so gebaut. Erst in den letzten Jahren erschienen immer mehr so genannte Single-Page-Anwendungen (SPAs), die die Idee ins Spiel brachten, dass deine gesamte Website in JavaScript geschrieben werden und das Ganze schließlich von jeder einzelnen Nutzerin und jedem einzelnen Nutzer im Browser kompiliert und ausgeführt werden könne.
-
-_Beachte: Partial Hydration (Partielle Anreicherung) wird manchmal auch als “Progressive Enhancement” oder “Progressive Hydration.” bezeichnet. Während durchaus leichte Unterschiede zwischen den Begriffen bestehen, kannst du sie für unsere Zwecke als verschiedene Synonyme des selben Konzeptes betrachten._
-
-**Partial Hydration ist das Geheimnis hinter der Geschichte von der standardmäßigen Schnelligkeit von Astro.** Next.js, Gatsby und andere JavaScript-Bibliotheken können Partial Hydration nicht unterstützen, da sie deine gesamte Website als eine einzelne JavaScript-Anwendung betrachten.
-
-## Konzept: Islands Architecture
-
-**Islands Architecture** ist die Idee Partial Hydration zu verwenden, um komplette Websites zu erzeugen. Islands Architecture ist eine Alternative zu der beliebten Idee deine gesamte Website in eine Client-seitige JavaScript-Anwendung zu packen, welche von den Nutzerinnen und Nutzern heruntergeladen werden muss.
-
-> In einem Modell aus "Inseln" ist Server-seitiges Rendering nicht die angeflanschte Optimierung, die darauf abzielt die SEO- oder UX-Werte zu verbessern. Stattdessen ist es die grundlegende Methode mit der Seiten an den Browser ausgeliefert werden. Das HTML das als Antwort auf eine Navigation zurückgegeben wird, enthält eine bedeutsame und unmittelbar gerenderte Repräsentation des Inhaltes, den die Nutzerin oder der Nutzer angefordert hat.
-> <br/> -- [Jason Miller](https://jasonformat.com/islands-architecture/)
-
-Neben den offensichtlichen Leistungsvorteilen, wenn weniger JavaScript an den Browser geschickt und dort ausgeführt wird, verfügt eine Islands Architecture über zwei wesentliche Vorteile:
-
- **Komponenten laden einzeln.** Eine leichtgewichtige Komponente (wie ein Sidebar-Toggle) wird schnell laden und rendern ohne von den schwereren Komponenten auf der Seite blockiert zu werden.
- **Komponenten laden isoliert voneinander.** Jeder Teil einer Seite ist eine isolierte Einheit, und ein Leistungsproblem einer Einheit hat keinen direkten Einfluss auf die anderen.
-
-![Diagram](https://res.cloudinary.com/wedding-website/image/upload/v1596766231/islands-architecture-1.png)
-
-## Interaktive Komponenten anreichern
-
-Astro rendert jede Komponente auf dem Server **während des Build-Prozesses**, solange nicht [client:only](#mycomponent-clientonly-) verwendet wird. Um Komponenten Client-seitig **während der Laufzeit** anzureichern, kannst du jede der folgenden `client:*`-Direktiven verwenden. Eine Direktive ist das Attribut einer Komponente (getrennt durch einen `:`), das Astro mitteilt, wie deine Komponente gerendert werden sollte.
-
-```astro
---
-// Beispiel: eine React-Komponente im Browser anreichern.
-import MeineReactKomponente from '../components/MeineReactKomponente.jsx';
---
-<!-- "client:visible" bedeutet, die Komponente lädt solange kein
-     Client-seitiges JavaScript, bis sie im Browser sichtbar wird. -->
-<MeineReactKomponente client:visible />
-```
-
-### `<MeineKomponente client:load />`
-
-Reichere die Komponente beim Laden der Seite an.
-
-### `<MeineKomponente client:idle />`
-
-Reichere die Komponente an, sobald der Haupt-Thread frei ist (verwendet [requestIdleCallback()][mdn-ric]).
-
-### `<MeineKomponente client:visible />`
-
-Reichere die Komponente an, sobald das Element im Viewport der Nutzerin bzw. des Nutzers sichtbar wird (verwendet [IntersectionObserver][mdn-io]). Nützlich für Inhalte weiter unten auf der Seite.
-
-### `<MeineKomponente client:media={QUERY} />`
-
-Reichere die Komponente an, wenn der Browser der vorgegebenen Media-Query entspricht (verwendet [matchMedia][mdn-mm]). Nützlich für Sidebar-Toggles oder andere Elemente, die nur auf Mobil- oder nur auf Desktop-Geräten angezeigt werden sollen.
-
-### `<MeineKomponente client:only />`
-
-Reichert die Komponente beim Laden der Seite an, ähnlich wie `client:load`. Die Komponente wird während des Build-Prozessses **ausgelassen**, nützlich für Komponenten die vollständig von Client-seitigen API abhängig sind. Diese Direktive sollte am besten vermieden werden, solange sie nicht unbedingt benötigt wird. In den meisten Fällen ist es am besten, Server-seitig Platzhalter-Inhalte zu rendern und etwaige API-Aufrufe im Browser solange zu verzögern, bis die Komponente im Browser angereichert wurde.
-
-Falls mehr als ein Renderer in der Astro-[Konfiguration](/reference/configuration-reference) angegeben werden, benötigt `client:only` einen Hinweis, um zu wissen, welcher Renderer für die Komponente eingesetzt werden soll. Zum Beispiel würde `client:only="react"` sicherstellen, dass die Komponente im Browser mit dem React-Renderer angereichert wird. Bei eigenen Renderern, die nicht über `@astrojs` bereitgestellt werden, verwende den vollen Namen, so wie er in der Astro-Konfiguration erscheint, z. B. `<client:only="mein-eigener-renderer" />`.
-
-## Kann ich Astro-Komponenten anreichern?
-
-[Astro-Komponenten](./astro-components) (`.astro`-Dateien) sind reine HTML-Templating-Komponenten ohne Client-seitige Laufzeit. Wenn du versuchst eine Astro-Komponente über einem `client`-Modifikator anzureichern, wird ein Fehler ausgegeben.
-
-Um deine Astro-Komponente interaktiv zu machen, musst du sie zu einer Frontend-Bibliothek deiner Wahl konvertieren: React, Svelte, Vue etc. Für den Fall, dass du keine bestimmte Bibliothek bevorzugst, empfehlen wir React oder Preact, da sie am meisten Ähnlichkeit mit Astros Syntax aufweisen.
-
-Alternativ hierzu könntest du auch ein `<script>`-Tag zu deiner Astro-Komponente hinzufügen und auf diesem Weg JavaScript an den Browser senden. Das kann bei einfachen Funktionen noch ein guter Weg sein, bei komplexeren oder interaktiven Komponenten empfehlen wir eine Frontend-Bibliothek zu verwenden.
-
-```astro
---
-// Beispiel: Astro mit script-Tags verwenden
---
-<h1>Nicht geklickt</h1>
-<button>Klicke, um die Überschrift zu ändern</button>
-<script>
-document.querySelector("button").addEventListener("click",() => {
-    document.querySelector("h1").innerText = "geklickt"
-})
-</script>
-```
-
-[mdn-io]: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
-[mdn-ric]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
-[mdn-mm]: https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia
--- a/docs/src/pages/de/core-concepts/layouts.md
+++ b/docs/src/pages/de/core-concepts/layouts.md
@ -1,155 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Layouts
-description: Einführung in Layouts, eine Art der Astro-Komponente, die für gemeinsame Layouts auf verschiedenen Seiten verwendet wird.
---
-
-**Layouts** sind eine besondere Art [Komponente](/de/core-concepts/astro-components) - sie können dir helfen gemeinsame Seiten-Layouts über dein Projekt verteilt zu nutzen.
-
-Layouts verhalten sich so, wie andere mehrfach verwendbare Astro-Komponenten auch. Es gibt keine neue Syntax oder API zu erlernen. Allerdings sind mehrfach verwendbare Layouts ein so weit verbreitetes Modell im Bereich der Web-Entwicklung, dass wir diese Anleitung verfasst haben, um dich bei der Verwendung zu unterstützen.
-
-## Anwendung
-
-Astro-Layouts unterstützen Props, Slots und alle anderen Merkmale von Astro-Komponenten. Layouts sind letztendlich einfach normale Komponenten!
-
-Anders als andere Komponenten enthalten Layouts allerdings oft auch die einfassenden Seitenelemente `<html>`, `<head>` und `<body>` (die so genannte **Page Shell**).
-
-Es ist ein allgemein übliches Verfahren alle Layout-Komponenten unter einem einzigen `src/layouts`-Verzeichnis anzulegen.
-
-## Beispiel
-
-```astro
---
-// src/layouts/BasisLayout.astro
-const {title} = Astro.props;
---
-<html>
-  <head>
-    <title>Beispiel-Layout: {title}</title>
-  </head>
-  <body>
-    <!-- Fügt jeder Seite eine Navigationsleiste hinzu. -->
-    <nav>
-      <a href="#">Home</a>
-      <a href="#">Posts</a>
-      <a href="#">Kontakt</a>
-    </nav>
-    <!-- slot: Deine Seiteninhalte werden hier eingefügt. -->
-    <slot />
-  </body>
-</html>
-```
-
-📚 Über das `<slot />`-Element lässt sich in Astro definieren, wo untergeordnete Elemente (die an das Layout übergeben werden) erscheinen sollen. Erfahre mehr darüber wie `<slot />` funktioniert in unserer [Anleitung zu Astro-Komponenten](/de/core-concepts/astro-components).
-
-Sobald du dein erstes Layout erstellt hast, kannst du es so verwenden, wie du jede andere Komponente in einer Seite verwenden würdest. Denke daran, dass dein Layout den gesamten Seitenaufbau enthält: `<html>`, `<head>`, und `<body>`. Du musst nur den Seiteninhalt hinzufügen.
-
-```astro
---
-// src/pages/index.astro
-import BasisLayout from '../layouts/BasisLayout.astro'
---
-<BasisLayout title="Homepage">
-  <h1>Hallo Welt!</h1>
-  <p>Dies ist mein Seiteninhalt, er wird innerhalb eines Layouts ausgegeben.</p>
-</BasisLayout>
-```
-
-## Verschachtelte Layouts
-
-Du kannst Layouts ineinander verschachteln, wenn du vom Basis-Layout abweichende Layout-Elemente auf einzelnen Seiten einsetzen willst, ohne dabei jedes Mal das gesamte Layout zu wiederholen. Es ist ein übliches Verfahren in Astro ein generisches `BasisLayout` zu verwenden und auf diesem weitere spezifische Layouts (`PostLayout`, `ProduktLayout` etc.) aufzusetzen, die das `BasisLayout` als Grundlage verwenden.
-
-```astro
---
-// src/layouts/PostLayout.astro
-import BasisLayout from '../layouts/BasisLayout.astro'
-const {title, author} = Astro.props;
---
-  <!-- Dieses Layout verwendet das Basis-Layout (siehe obiges Beispiel): -->
-<BasisLayout title={title}>
-  <!-- Fügt neue Post-spezifische Inhalte zu jeder Seite hinzu. -->
-  <div>Post-Autor/Autorin: {author}</div>
-  <!-- slot: Deine Seiteninhalte werden hier eingefügt. -->
-  <slot />
-</BasisLayout>
-```
-
-## Layouts zusammenstellen
-
-Manchmal benötigst du detailliertere Kontrolle über deine Seiten. Zum Beispiel willst du vielleicht SEO- oder Social-Media-`meta`-Tags auf bestimmten Seiten hinzufügen, auf anderen aber nicht. Das kannst du mit Props in deinem Layout erreichen (`<BasisLayout addMeta={true} ...`) - ab einem bestimmten Punkt ist es möglicherweise jedoch leichter deine Layouts nicht zu verschachteln.
-
-Anstatt deine gesamte `<html>`-Seite als ein einziges großes Layout zu definieren, kannst du die `head`- und `body`-Inhalte als kleinere, getrennte Komponenten definieren. Hierdurch kannst du verschiedene Layouts auf jeder Seite zusammenstellen.
-
-```astro
---
-// src/layouts/BasisHead.astro
-const {title, description} = Astro.props;
---
-<meta charset="UTF-8">
-<title>{title}</title>
-<meta name="description" content={description}>
-<link rel="preconnect" href="https://fonts.gstatic.com">
-<link href="https://fonts.googleapis.com/css2?family=Spectral:ital,wght@0,400;0,700;1,400;1,700&display=swap" rel="stylesheet">
-```
-
-Beachte dass dieses Layout deine **page shell** nicht mit einschließt und nur einige generische Elemente auflistet, die in deinem `<head>`-Block erscheinen sollen. Du hast mehr Kontrolle über die Struktur der einzelnen Seite und kannst mehrere Layout-Komponenten kombinieren.
-
-```astro
---
-// src/pages/index.astro
-import BasisHead from '../layouts/BasisHead.astro';
-import OpenGraphMeta from '../layouts/OpenGraphMeta.astro';
---
-<html>
-  <head>
-    <!-- Nun hast du volle Kontrole über `head` - pro Seite. -->
-    <BasisHead title="Title der Seite" description="Beschreibung der Seite" />
-    <OpenGraphMeta />
-    <!-- Du kannst je nach Bedarf sogar eigene einmalig benötigte Elemente hinzufügen. -->
-    <link rel="alternate" type="application/rss+xml" href="/feed/posts.xml">
-  </head>
-  <body>
-    <!-- ... -->
-  </body>
-</html>
-```
-
-Der Nachteil bei diesem Ansatz ist, dass du die `<html>`-, `<head>`- und `<body>`-Elemente dabei auf jeder Seite definieren musst. Diese werden benötigt, um die Seite vollständig zusammenzustellen, da die Layout-Komponenten nicht mehr die gesamte **Page Shell** beinhalten.
-
-## Markdown-Layouts
-
-Für Markdown-Dateien ist ein Layout unerlässlich. Markdown-Dateien können ein bestimmtes Layout im Frontmatter aufrufen. Jede Markdown-Datei wird als HTML gerendert und anschließend an der Stelle in den `<slot />` eingespeist, wo dieser im Layout definiert ist.
-
-```markdown
---
-title: Blogpost
-layout: ../layouts/PostLayout.astro
---
-
-Dieser Blogpost wird innerhalb des `<PostLayout />`-Layout **gerendert**.
-```
-
-Markdown-Seiten übergeben immer eine oder mehrere `content`-Eigenschaften an ihr Layout. Dies ist sehr hilfreich, um Informationen über die Seite, einen Titel, Metadaten, eine Index-Tabelle, Kopfzeilen und anderes für die Seite zur Verfügung zu haben.
-
-```astro
---
-// src/layouts/PostLayout.astro
-const { content } = Astro.props;
---
-<html>
-  <head>
-    <title>{content.title}</title>
-  </head>
-  <body>
-    <h1>{content.title}</h1>
-    <h2>{content.description}</h2>
-    <img src={content.image} alt="">
-    <article>
-      <!-- slot: Markdown-Inhalte erscheinen hier! -->
-      <slot />
-    </article>
-  </body>
-</html>
-```
-
-📚 Lerne mehr über die Verwendung von Markdown in Astro in unserer [Markdown-Anleitung](/guides/markdown-content).
--- a/docs/src/pages/de/core-concepts/project-structure.md
+++ b/docs/src/pages/de/core-concepts/project-structure.md
@ -1,58 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Projektstruktur
-description: Lerne wie die Projektstruktur in Astro aufgebaut ist.
---
-
-Astro verwendet eine dogmatische Verzeichnisstruktur für dein Projekt. Jedes Astro-Projekt muss die folgenden Verzeichnisse und Dateien enthalten:
-
- `src/*` - Dein Source-Code (Komponenten, Seiten etc.)
- `public/*` - Deine Nicht-Code-Assets (Schriften, Icons etc.)
- `package.json` - Ein Projekt-Manifest
-
-Der einfachste Weg dein neues Projekt aufzusetzen, ist mittels `npm init astro`. Lies unsere [Installationsanleitung](/de/quick-start), um einen vollständigen Überblick darüber zu erhalten, wie ein Projekt automatisch (mit `npm init astro`) oder manuell aufgesetzt werden kann.
-
-## Projektstruktur
-
-```
-├── src/
-│   ├── components/
-│   ├── layouts/
-│   └── pages/
-│       └── index.astro
-├── public/
-└── package.json
-```
-
-### `src/`
-
-Das `src`-Verzeichnis beinhaltet den Großteil des Source-Code zu deinem Projekt. Dazu zählen:
-
- [Astro-Komponenten](/core-concepts/astro-components)
- [Astro-Seiten](/de/core-concepts/astro-pages)
- [Layouts](/de/core-concepts/layouts)
- [JavaScript-Komponenten](/de/core-concepts/component-hydration)
- [Styling (CSS, Sass)](/guides/styling)
- [Markdown](/guides/markdown-content)
-
-Astro hat vollständige Kontrolle darüber, wie diese Dateien verarbeitet, optimiert und in deinem abschließenden Website-Build gepackt werden. Einige Dateien (wie Astro-Komponenten) kommen niemals direkt im Browser an - sie werden stattdessen als HTML gerendert und ausgegeben. Andere Dateien (wie CSS) werden an den Browser gesendet, werden möglicherweise aber gepackt - in Abhängigkeit davon, wie deine Site sie einsetzt.
-
-### `src/components`
-
-[Komponenten](/de/core-concepts/astro-components) sind mehrfach verwendbare Einheiten der UI deiner Seiten. Es wird empfohlen (aber dies ist nicht zwingend notwendig), Komponenten in diesem Verzeichnis anzulegen. Wie diese darin strukturiert sind, kannst du frei entscheiden.
-
-Deine Nicht-Astro-Komponenten (React, Preact, Svelte, Vue etc.) können ebenfalls im `src/components`-Verzeichnis abgelegt werden. Astro wird automatisch alle Komponeneten als HTML rendern, solange du nicht mittels [Partial Hydration](/de/core-concepts/component-hydration) eine bestimmte Frontend-Komponente aktiviert hast.
-
-### `src/layouts`
-
-[Layouts](/de/core-concepts/layouts) sind mehrfach verwendbare Komponenten für die Gestaltung einzelner Seiten. Es wird empfohlen (aber dies ist nicht zwingend notwendig) Layout-Komponenten in diesem Verzeichnis anzulegen. Wie diese darin strukturiert sind, kannst du frei entscheiden.
-
-### `src/pages`
-
-[`src/pages`](/de/core-concepts/astro-pages) enthält alle Seiten (`.astro` und `.md` werden unterstützt) für deine Website. Es ist **zwingend** notwendig, dass du deine Seiten in diesem Verzeichnis anlegst.
-
-### `public/`
-
-Bei den meisten Nutzerinnen und Nutzern, wird der Großteil der Dateien innerhalb des `src`-Verzeichnisses liegen, so dass Astro sie in der richtigen Art und Weise während des Build-Prozesses verarbeiten und optimieren kann. Im Gegensatz dazu ist das `public`-Verzeichnis der passende Ort für alle Dateien, die nicht von Astros Build-Prozess abhängig sind.
-
-Wenn du eine Datei im `public`-Verzeichnis ablegst, wird diese von Astro nicht bearbeitet. Stattdessen wird sie unverändert in das `build`-Verzeichnis kopiert. Dies kann nützlich sein bei Assets von Bildern und Schriften - oder wenn du spezielle Dateien wie `robots.txt` oder `manifest.webmanifest` unverändert im Build verwenden willst.
--- a/docs/src/pages/de/core-concepts/routing.md
+++ b/docs/src/pages/de/core-concepts/routing.md
@ -1,102 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Routing
-description: Einführung in das Routing in Astro.
---
-
-Astro verwendet **Datei-basiertes Routing**, um während des Build-Prozesses - entsprechend der Datei-Struktur im `src/pages`-Verzeichnis deines Projekts - die gültigen Routen und URL festzulegen. Wenn eine Datei zum `src/pages`-Verzeichnis deines Projekts hinzugefügt wird, ist sie basierend auf ihrem Dateinmanen automatisch über die entsprechende Route mit der entsprechenden URL erreichbar.
-
-## Statische Routen
-
-Astro-Komponenten (`.astro`) und Markdown-Dateien (`.md`) im `src/pages`-Verzeichnis werden zu Seiten deiner Website. Die Route zu jeder Seite wird zusammengesetzt aus den Dateinamen und dem Pfad zu den Dateien innerhalb des `src/pages`-Verzeichnisses. Das bedeutet, dass in einem Astro-Projekt keine separate Routing-Konfiguration verwaltet werden muss.
-
-```bash
-# Beispiel: Statische Routen
-src/pages/index.astro        -> meinesite.com/
-src/pages/about.astro        -> meinesite.com/about
-src/pages/about/index.astro  -> meinesite.com/about
-src/pages/about/me.astro     -> meinesite.com/about/me
-src/pages/posts/1.md         -> meinesite.com/posts/1
-```
-
-## Dynamische Routen
-
-Manchmal musst du zu einer einzelnen Page-Komponente mehrere URLs generieren. Astro verwendet Datei-basiertes Routing, um **dynamische Routing-Parameter** zu unterstützen, so dass eine Seite - basierend auf einem Filter - zu verschiedenen dynamischen Routen passt.
-
-Es ist wichtig dabei zu beachten, dass Astro statische Seiten generiert. Es gibt keinen Astro-Server, der die Seiten auf Anfrage generiert und ausliefert. Dies bedeutet, dass jede Seite vorab erzeugt werden muss. Seiten die dynamische Routen verwenden, müssen daher eine `getStaticPaths()`-Funktion exportieren, die Astro genau vorgibt, welche Seiten generiert werden müssen. Du erfährst mehr darüber in der vollständigen [API-Referenz](/reference/api-reference#getstaticpaths).
-
-### Benannte Parameter
-
-Dynamische Parameter werden im Dateinamen unter Verwendung der `[Klammer]`-Schreibweise kodiert:
-
- `pages/blog/[slug].astro` → `/blog/:slug` (`/blog/hallo-welt`, `/blog/post-2` etc.)
- `pages/[username]/einstellungen.astro` → (`/fred/einstellungen`, `/drew/einstellungen` etc.)
- `pages/[lang]-[version]/info.astro` → (`/en-v1/info`, `/fr-v2/info` etc.)
-
-#### Beispiel: Benannte Parameter
-
-Angenommen du hast eine Seite `pages/post/[pid].astro`:
-
-```astro
---
-// Beispiel: src/pages/post/[pid].astro
-const {pid} = Astro.request.params;
---
-<p>Post: {pid}</p>
-```
-
-Allen Routen mit z. B. `/post/1`, `/post/abc` etc. werden `pages/post/[pid].astro` entsprechen. Jeder passende Pfad-Parameter wird an die Page-Komponente unter `Astro.request.params` weitergegeben.
-
-Zum Beispiel wird die Route `/post/abc` das folgende `Astro.request.params`-Objekt zur Verfügung halten:
-
-```json
-{ "pid": "abc" }
-```
-
-Es können mehrere dynamische Routen-Abschnitte kombiniert werden, und sie funktionieren in der gleichen Weise. Die Seite `pages/post/[pid]/[kommentar].astro` wird der Route `/post/abc/ein-kommentar` entsprechen, und ihr `query`-Objekt wird entsprechend lauten:
-
-```json
-{ "pid": "abc", "kommentar": "ein-kommentar" }
-```
-
-### Rest-Parameter
-
-Falls du beim URL-Routing mehr Flexibilität benötigst, kannst du den Rest-Parameter als universalen Fänger verwenden. Dies erreichst du, indem du in den eckigen Klammern deinem Parameter drei Punkte (`...`) voranstellst. Zum Beispiel:
-
- `pages/post/[...slug].astro` → (`/post/a`, `/post/a/b`, `/post/a/b/c`, etc.)
-
-Passende Parameter werden als `query`-Parameter (`slug` in diesem Beispiel) an die Seite übergeben. Dem obigen Beispiel folgend heißt das dem Pfad `post/a/b/c` entsprechende `query`-Objekt:
-
-```json
-{ "slug": "a/b/c" }
-```
-
-Du kannst auch andere Benennungen als `slug` verwenden, z. B.: `[...param]` oder `[...name]`.
-
-Rest-Parameter sind standardmäßig optional, `pages/post/[...slug]` würde also auch `/post/` entsprechen.
-
-#### Beispiel: Rest-Parameter
-
-Für ein `real-world`-Beispiel würdest du den `Github File Viewer` folgendermaßen implementieren:
-
-```
-/[org]/[repo]/tree/[branch]/[...file]
-```
-
-In diesem Beispiel würde eine Abfrage von `/withastro/astro/tree/main/docs/public/favicon.svg` folgende Parameter für die Seite verfügbar machen:
-
-```js
-{
-	org: 'withastro',
-	repo: 'astro',
-	branch: 'main',
-	file: 'docs/public/favicon.svg'
-}
-```
-
-## Warnungen
-
- Statische Routen ohne Pfad-Parameter haben stets Vorrang vor allen anderen Routen, und Routen mit benannten Pfad-Parametern haben Vorrang vor Routen mit Rest-Parametern. Schau dir folgende Beispiele an:
-  - `pages/post/create.astro` - wird `/post/create` entsprechen
-  - `pages/post/[pid].astro` - wird `/post/1`, `/post/abc` etc. entsprechen, aber nicht `/post/create`
-  - `pages/post/[...slug].astro` - wird `/post/1/2`, `/post/a/b/c` etc. entsprechen, aber nicht `/post/create`, `/post/abc`
--- a/docs/src/pages/de/getting-started.md
+++ b/docs/src/pages/de/getting-started.md
@ -1,75 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Erste Schritte
-description: Eine einfache Einführung in Astro
-lang: de
---
-
-Astro ist ein moderner Static-Site-Renderer (auch SSG - Static-Site-Generator). Erfahre worum es bei Astro eigentlich geht auf [unserer Homepage](https://astro.build/), oder lies [unseren Release Blogpost](https://astro.build/blog/introducing-astro).
-
-Diese Seite dient als Übersicht für die Astro-Dokumentation und alle damit verbundenen Ressourcen.
-
-## Astro ausprobieren
-
-Der einfachste Weg Astro auszuprobieren ist `npm init astro` in einem neuen Verzeichnis auf deinem Rechner auszuführen. Der CLI-Wizard wird dir helfen ein neues Astro-Projekt aufzusetzen.
-
-Um in fünf einfachen Schritten mit Astro loszulegen, lies [unsere Schnellstart-Anleitung](/de/quick-start).
-
-Alternativ kannst du unsere [Installationsanleitung](/de/installation) lesen, um eine ausführlichere Schritt-für-Schritt-Anleitung zu erhalten.
-
-### Beispielprojekte
-
-Falls du Astro lieber anhand von Beispielen kennenlernen möchtest, sieh dir unsere [vollständige Beispiel-Bibliothek](https://github.com/withastro/astro/tree/main/examples) auf GitHub an.
-
-Du kanst jedes dieser Beispiele lokal auf deinem Rechner ausprobieren, indem du `npm init astro` mit der CLI-Kennzeichnung `--template` im Terminal aufrufst. Die Kennzeichnung `--template` unterstützt auch externe Vorlagen und Vorlagen der Community.
-
-```bash
-# Rufe den Wizard zur Initialisierung auf und verwende diese offizielle Vorlage
-npm init astro -- --template [OFFIZIELLES_BEISPIEL_NAME]
-# Rufe den Wizard zur Initialisierung auf und verwende diese Community-Vorlage
-npm init astro -- --template [GITHUB_NAME]/[REPO_NAME]
-npm init astro -- --template [GITHUB_NAME]/[REPO_NAME]/pfad/zur/vorlage
-```
-
-### Online-Playgrounds
-
-Falls du Astro gerne in deinem Browser ausprobieren willst, kannst du einen Online-Code-Editor wie z. B. Stackblitz, CodeSandbox, Gitpod oder GitHub Codespaces verwenden. Nutze den "Open in Stackblitz"-Link zu einem beliebigen Besipiel aus unserer [Beispiel-Bibliothek](https://github.com/withastro/astro/tree/main/examples), oder [klicke hier](https://stackblitz.com/fork/astro), um ein neues Projekt in [Stackblitz](https://stackblitz.com/fork/astro) aufzusetzen.
-
-## Astro lernen
-
-Verschiedene Menschen mit unterschiedlichen Hintergründen und unterschiedlichen Lernansätzen kommen zu Astro. Gleichgültig ob du einen theoretischen oder einen praktischen Ansatz bevorzugst, wir hoffen, dass dieser Abschnitt hilfreich für dich ist.
-
- Falls du **praktisches Lernen** bevorzugst, starte direkt mit ein Beispiel aus unserer [Beispiel-Liste](https://github.com/withastro/astro/tree/main/examples).
- Falls du bevorzugst **Schritt für Schritt zu lernen**, starte mit unseren [grundlegenden Konzepten und Anleitungen](/de/core-concepts/project-structure).
-
-Wie jede unbekannte Technik, bringt Astro eine gewisse Lernkurve mit sich. Wir sind jedoch sicher, dass du mit ein bisschen Übung und Geduld schnell lernen _wirst_, wie Astro funktioniert.
-
-### Lerne die `.astro`-Syntax
-
-Wenn du anfängst mit Astro zu arbeiten, wirst du viele Dateien mit der Dateiendung `.astro` sehen. Das ist **Astros Komponenten-Syntax**: ein spezielles, HTML-ähnliches Dateiformat, welches Astro für Vorlagen benutzt. Es wurde in Anlehnung an HTML und JSX entworfen und sollte allen, die mit diesen Formaten Erfahrung haben, bekannt vorkommen.
-
-Unsere unterstützende Anleitung zu [Astro-Komponenten](/de/core-concepts/astro-components) ist eine gute Einführung in die Astro-Syntax - und der beste Weg sie zu lernen.
-
-### API-Referenz
-
-Dieser Abschnitt der Dokumentation ist nützlich, wenn du weitere Details zu einer bestimmen Astro-API erhalten möchtest. Zum Besipiel listet die [Referenz zur Konfiguration](/reference/configuration-reference) alle möglichen Konfigurationseigenschaften auf, die dir zur Verfügung stehen. Die [Referenz zu integrierten Komponenten](/reference/builtin-components) listet alle verfügbaren Kernkomponenten wie z. B. `<Markdown />` und `<Code />` auf.
-
-### Versionsdokumentation
-
-Diese Dokumentation ist immer auf dem Stand der letzten _stabilen_ Version von Astro. Sobald wir den v1.0-Meilenstein erreicht haben, werden wir auch die Möglichkeit anbieten eine versionsspezifische Dokumentation einzusehen.
-
-## Auf dem Laufenden bleiben
-
-Der [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-Account ist die offizielle Quelle für Ankündigungen vom Astro-Team.
-
-Zusätzlich veröffentlichen wir alle Ankündigungen in unserer [Discord-Community](https://astro.build/chat) im `#announcements`-Channel.
-
-Nicht jedes Astro-Release verdient einen eigenen Blogpost, aber du kannst ein detailliertes Log aller Änderungen für jedes Release im [`CHANGELOG.md` des Astro Repository](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md) nachlesen.
-
-## Fehlt etwas?
-
-Falls etwas in der Dokumentation fehlt, oder falls du einen bestimmten Teil verwirrend findest, [erstelle bitte ein Issue](https://github.com/withastro/astro/issues/new/choose) mit deinen Verbesserungsvorschlägen oder tweete an den [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter-Account. Wir freuen uns, von dir zu hören!
-
-## Credit
-
-Diese Einführung basierte ursprünglich auf der Einführung zu [React](https://reactjs.org/).
--- a/docs/src/pages/de/guides/styling.md
+++ b/docs/src/pages/de/guides/styling.md
@ -1,644 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Styling & CSS
-description: Lerne Komponenten mit Astro zu gestalten.
---
-
-Astro verfügt über eine besondere Möglichkeit, um das Schreiben von CSS so einfach wie möglich zu halten: Astro-Komponenten können über das Einfügen eines `<style>`-Tags an beliebiger Stelle gestaltet werden.
-
-## Styles in Astro-Komponenten
-
-Standardmäßig werden in Astro-Komponenten alle Styles nur auf Elemente im Rahmen der Komponente (genannt **Scope**) angewandt, der sie hinzugefügt wurden. Dies kann die Arbeit mit Styles erheblich erleichtern, da du dich zu jeder Zeit nur um die Gestaltung der Komponente kümmern musst, an der du arbeitest.
-
-```html
-<!-- src/components/MeineKomponente.astro -->
-<style>
-  /* Klassen-Selektor im Scope der Komponente */
-  .text {
-    font-family: cursive;
-  }
-  /* Element-Selektor im Scope der Komponente */
-  h1 {
-    color: red;
-  }
-</style>
-
-<h1>Ich bin ein Style im Scope der Komponente, und ich bin rot!</h1>
-<p class="text">
-  Ich bin ein Style im Scope der Komponente, und ich bin kursiv!!
-</p>
-```
-
-Beachte dass der `h1`-Selektor hier nicht über die Komponente hinaus wirksam wird! Die Styles werden nicht auf andere `h1`-Tags außerhalb dieses Dokuments angewandt - auch nicht in untergeordneten Komponenten.
-
-_Tipp: Auch wenn es möglich ist hier Element-Selektoren zu verwenden, sollten doch bevorzugt Klassen-Namen verwendet werden. Das ist nicht nur ein klein wenig performanter, es ist auch leichter zu lesen, insbesondere in einem umfangreichen Dokument._
-
-### Globale Styles
-
-Natürlich besteht die tatsächliche Macht von CSS darin, Styles so häufig wie möglich wiederzuverwenden! Die bevorzugte Methode um globale Styles einzubinden, ist die Verwendung eines `<link>`-Tags im `<head>`-Block, ganz so wie du es gewohnt bist. Diese Methode kann in Astro auch im Zusammenhang mit dem `<style>`-Tag im Scope der Komponente angewandt werden:
-
-```html
-<!-- src/pages/index.astro -->
-<head>
-  <!-- Styles - geladen über src/styles/utils.css unter Verwendung von Astro.resolve() -->
-  <link rel="stylesheet" type="text/css"
-  href={Astro.resolve('../styles/utils.css')} />
-</head>
-<body>
-  <!-- Styles die nur im Scope der aktuellen Seite gelten 
-  (nicht für untergeordnete Seiten oder andere Komponenten) -->
-  <style>
-    .title {
-      font-size: 32px;
-      font-weight: bold;
-    }
-  </style>
-
-  <!-- Die Klasse ".title" ist im Scope, aber wir können auch unsere 
-  globalen Hilfsklasssen "align-center" und "margin top: 4" aus utils.css verwenden -->
-  <h1 class="title align-center mt4">Seitentitel im Scope</h1>
-</body>
-```
-
-_Beachte: `Astro.resolve()` ist ein nützliches Hilfsmittel, um Verweise auf Dateien von überall her aufzulösen ([docs][astro-resolve])_
-
-#### Styling untergeordneter Elemente
-
-Falls du Styles, die im Scope der Komponente gesetzt werden, auch auf untergeordnete Komponenten anwenden willst, kannst du auf die `:global()`-Funktion aus den [CSS-Modules][css-modules] zurückgreifen:
-
-```astro
-<!-- src/components/MeineKomponente.astro -->
---
-import PostContent from './Post.astro';
---
-<style>
-  /* Nur im Scope der aktuellen Komponente gültig */
-  h1 {
-    color: red;
-  }
-
-  /* Im Scope aller Komponenten unterhalb des Elements mit der .blogpost-Klasse gültig */
-  .blogpost :global(h1) {
-    color: blue;
-  }
-</style>
-
-<h1>Titel</h1>
-<article class="blogpost">
-  <PostContent />
-</article>
-```
-
-Dies ist eine sehr gute Methode, um Dinge zu stylen wie Blogposts oder Dokumente, die mit Inhalten aus einem CMS außerhalb von Astro gefüttert werden. Aber Vorsicht, wenn untergeordnete Elemente frei von Abhängigkeiten gestaltet werden, bricht dies auch die Verkapselung der Komponente auf. Das Arbeiten mit Komponenten die unterschiedlich aussehen, abhängig davon ob sie ein bestimmtes übergeordnetes Element haben oder nicht, kann sehr schnell unübersichtlich werden.
-
-#### Globale Styles innerhalb eines `<style>`-Tags
-
-Falls du globale Styles verwenden willst, ohne einen normalen `<link>`-Tag im `<head>`-Block zu verwenden (die empfohlene Variante), gibt es dafür mit `<style global>` eine Notlösung:
-
-```html
-<style global>
-  /* Wird auf alle h1-Tags der gesamten Site angewandt */
-  h1 {
-    font-size: 32px;
-  }
-</style>
-
-<h1>Globaler Style</h1>
-```
-
-Dasselbe kannst du erreichen, indem du einem Selektor die `:global()`-Funktion voranstellst:
-
-```html
-<style>
-  /* Wird auf alle h1-Tags deiner gesamten Site angewandt */
-  :global(h1) {
-    font-size: 32px;
-  }
-
-  /* h1-Style nur im Scope dieser Datei angewandt */
-  h1 {
-    color: blue;
-  }
-</style>
-```
-
-Es wird empfohlen diese Methoden nur dort einzusetzen, wo ein `<link>`-Tag nicht funktionieren würde. Es ist sehr schwer irrige globale Styles aufzuspüren, wenn sie verteilt auftreten und nicht in einer zentralen CSS-Datei stehen.
-
-📚 Lies unseren vollständigen Artikel über die Syntax in [Astro-Komponenten][astro-component], um mehr über die Verwendung des `<style>`-Tags zu erfahren.
-
-## Autoprefixer
-
-[Autoprefixer][autoprefixer] kümmert sich für dich um Browser-übergreifende CSS-Kompatibilität. Installiere autoprefixer (`npm install --save-dev autoprefixer`) und füge eine Datei mit dem Namen `postcss.config.cjs` deinem Hauptverzeichnis hinzu:
-
-```js
-// postcss.config.cjs
-module.exports = {
-  plugins: [require('autoprefixer')],
-};
-```
-
-_Beachte: Astro v0.21 und spätere Versionen erfordern diesen Schritt zur Einrichtung von autoprefixer. Vorherige Versionen haben dies automatisch ausgeführt._
-
-## PostCSS
-
-Du kannst jedes beliebige PostCSS-Plugin verwenden, indem du eine `postcss.config.cjs`-Datei deinem Hauptverzeichnis hinzufügst. Für das Setup und die Konfiguration des Plugins, das du installieren willst, folge der Dokumentation zu dem Plugin.
-
---
-
-## Unterstützte Styling-Optionen
-
-Styling in Astro sollte so flexibel sein, wie du es haben willst! Die folgenden Optionen werden unterstützt:
-
-| Framework        | Globales CSS | Scoped CSS | CSS-Modules |
-| :--------------- | :----------: | :--------: | :---------: |
-| `.astro`         |      ✅      |     ✅     |    N/A¹     |
-| `.jsx` \| `.tsx` |      ✅      |     ❌     |     ✅      |
-| `.vue`           |      ✅      |     ✅     |     ✅      |
-| `.svelte`        |      ✅      |     ✅     |     ❌      |
-
-¹ _`.astro`-Dateien haben keine Laufzeit, daher nimmt Scoped-CSS hier den Platz von CSS-Modules ein (Styles sind im Scope der Komponenten, benötigen aber keine dynamischen Werte)_
-
-Alle Styles in Astro werden automatisch minifiziert und gepackt, du kannst so einfach nur dein CSS schreiben - und wir machen den Rest ✨.
-
---
-
-## Frameworks und Bibliotheken
-
-### 📘 React/Preact
-
-`.jsx`-Dateien unterstützen sowohl globales CSS als auch CSS-Modules. Um letztere zu verwenden, benutze die Erweitereung `.module.css` (oder `.module.scss`/`.module.sass` wenn du Sass einsetzt).
-
-```js
-import './global.css'; // Verwende globales CSS
-import Styles from './styles.module.css'; // Verwende CSS-Modules (muss auf `.module.css`, `.module.scss`, or `.module.sass` enden!)
-```
-
-### 📗 Vue
-
-Vue unterstützt in Astro die selben Methoden wie `vue-loader`:
-
- [vue-loader - Scoped-CSS][vue-scoped]
- [vue-loader - CSS-Modules][vue-css-modules]
-
-### 📕 Svelte
-
-Svelte funktioniert in Astro ebenfalls genauso wie gewohnt: [Svelte-Styling-Docs][svelte-style].
-
-### 🎨 CSS-Präprozessoren (Sass, Stylus, etc.)
-
-Astro unterstützt als CSS-Präprozessoren [Sass][sass], [Stylus][stylus] und [Less][less] mittels [Vite][vite-preprocessors]. Der jeweils gewünschte Präprozessor kann wie folgt aufgesetzt werden:
-
- **Sass**: Führe `npm install -D sass` aus und verwende `<style lang="scss">` oder `<style lang="sass">` (eingerückt) in `.astro`-Dateien
- **Stylus**: Führe `npm install -D stylus` aus und verwende `<style lang="styl">` oder `<style lang="stylus">` in `.astro`-Dateien
- **Less**: Führe `npm install -D less` aus und verwende `<style lang="less">` in `.astro`-Dateien
-
-Alle oben genannten können auch innerhalb eines JS-Frameworks ausgeführt werden! Folge einfach den Modellen, die das jeweilige Framework hierfür empfielt:
-
- **React**/**Preact**: `import Styles from './styles.module.scss'`;
- **Vue**: `<style lang="scss">`
- **Svelte**: `<style lang="scss">`
-
-Darüber hinaus unterstützt Astro auch [PostCSS](#-postcss), aber die Einrichtung erfolgt [etwas abweichend hiervon](#-postcss).
-
-_Beachte: CSS unterhalb des `public/`-Verzeichnisses wird **nicht** verarbeitet! Platziere es stattdessen unterhalb des `src/`-Verzeichnisses._
-
-### 🍃 Tailwind
-
-Astro kann sehr einfach für die Verwendung von [Tailwind][tailwind] konfiguriert werden! Installiere die Abhängigkeiten:
-
-```
-npm install --save-dev tailwindcss
-```
-
-Und erzeuge zwei Dateien in deinem Hauptverzeichnis: `tailwind.config.cjs` und `postcss.config.cjs`:
-
-```js
-// tailwind.config.cjs
-module.exports = {
-  mode: 'jit',
-  purge: ['./public/**/*.html', './src/**/*.{astro,js,jsx,svelte,ts,tsx,vue}'],
-  // Weitere Optionen hier ...
-};
-```
-
-```js
-// postcss.config.cjs
-module.exports = {
-  plugins: [require('tailwindcss')],
-};
-```
-
-Damit bist du ausgerüstet, um Tailwind einzusetzen! Der von uns empfohlene Ansatz ist, eine Datei `src/styles/global.css` (oder wie du dein globales Stylesheet bevorzugterweise nennst) mit den [Tailwind-Utilities][tailwind-utilities] darin zu erzeugen - ungefähr in dieser Form:
-
-```css
-/* src/styles/global.css */
-@tailwind base;
-@tailwind components;
-@tailwind utilities;
-```
-
-Füge die Datei deiner Astro-Seite (oder deiner Layout-Komponente) hinzu:
-
-```astro
-<head>
-  <style global>
-			@import "../styles/global.css";
-	</style>
-</head>
-```
-
-Alternativ zu einer Datei `src/styles/global.css` kannst du Tailwind-Utilities auch in einzelnen `pages/*.astro`-Komponenten in einem `<style>`-Block hinzufügen. Aber vermeide sorgfältig etwaige Dopplungen! Falls du mehrere von Tailwind verwaltete Stylesheets verwendest, stelle sicher, dass du nicht die selben CSS-Styles mehrfach in verschiedenen CSS-Dateien an die Benutzerinnen und Benutzer schickst.
-
-#### Umziehen von v0.19
-
-Mit der [Version 0.20.0](https://github.com/withastro/astro/releases/tag/astro%400.20.0) packt, kompiliert und prozessiert Astro keine Dateien mehr, die im Verezichnis `public/` liegen. Wir haben ursprünglich empfohlen sämtliche Tailwind-Dateien im `public`-Verzeichnis zu speichern. Falls du dein Projekt diesem Modell folgend begonnen hast, solltest du alle Tailwind-Dateien in das `src`-Verzeichnis verschieben und sie in deinem Template über [Astro.resolve()][astro-resolve] importieren:
-
-```astro
-  <link
-    rel="stylesheet"
-    href={Astro.resolve("../styles/global.css")}
-  >
-```
-
-### 🎭 PostCSS
-
-PostCSS zu verwenden ist so einfach wie eine [`postcss.config.cjs`](https://github.com/postcss/postcss#usage)-Datei in deinem Hauptverzeichnis zu erzeugen.
-
-Beachte, dass dieses Plugin sämtliches CSS in deinem Projekt verarbeitet, einschließlich jeglicher Dateien die nach CSS kompiliert wurden (wie zum Beispiel `.scss`-Sass-Dateien).
-
-_Beachte: CSS unterhalb des `public/`-Verzeichnisses **wird nicht verarbeitet!** Platziere es stattdessen unterhalb des `src/`-Verzeichnisses, wenn PostCSS es vearbeiten soll._
-
-## Bündeln
-
-Sämtliches CSS wird minifiziert und automatisch gebündelt, wenn du `astro build` ausführst. Ohne zu sehr in die Tiefe zu gehen, die grundlgenden Regeln lauten wie folgt:
-
- Wenn ein Style nur innerhalb einer Route auftaucht, wird er nur für diese Route geladen (`/_astro/[page]-[hash].css`)
- Wenn ein Style innerhalb mehrerer Routen auftaucht, wird er in einem `/_astro/common-[hash].css`-Bündel zusammengefasst
- Sämtliche Styles erhalten ihre Hashes in Bezug auf die Inhalte, für die sie gelten (das bedeutet, die Hashes ändern sich nur, wenn die Inhalte sich ändern)
-
-Wir werden unsere Styling-Optimierungen im Laufe der Zeit stetig weiterentwickeln und würden gerne euer Feedback dazu hören! Falls `astro build` unerwartete Styles generiert, oder wenn du Vorschläge zur Verbesserung hast, [eröffne bitte ein Issue][issues].
-
-_Beachte: Wenn einige Seiten-Styles gemeinsam gebündelt werden und andere Seiten-Styles auf die Seite bezogen bleiben, entwickeln sich hieraus meistens keine Probleme. Aber wenn Teile deiner Styles gebündelt werden, könnten sie \_technisch_ auch in einer anderen Reihenfolge laden, als von dir in deiner Kaskade intendiert. Auch wenn dieses Problem nicht nur Astro zu eigen ist - es besteht potentiell bei so ziemlich jedem Bündelungsprozess - so kann es dich doch unerwartet treffen, wenn du diese Möglichkeit nicht von vorne herein in Betracht ziehst. Stelle sicher, dass du deinen abschließenden Build eingehend diesbezüglich inspizierst - und [melde bitte auftretende Probleme][issues], auf die du stößt.\_
-
-## Fortgeschrittene Styling-Architektur
-
-Zu viele Entwicklungsumgebungen legen die Hände in den Schoß, wen es um CSS geht - oder sie warten im besten Fall mit erfundenen Beispielen auf, die dich nicht wirklich weiter bringen. Entwicklern zu sagen "Verwende einfach die Styling-Lösung, die dir gefällt!", ist ein netter Ansatz, der sich in der Praxis nicht bewährt. Nur sehr wenige Styling-Lösungen taugen für wirklich jedes Setup. Mit Astro verhält es sich in dieser Hinsicht nicht anders - manche Ansätze _werden_ besser funktionieren als andere.
-
-Ein Beispiel, um dies zu bebildern: Astro entfernt JS welches zur Laufzeit ausgeführt wird (sogar das eigentliche Framework wenn möglich). Somit wäre es eine schlechte Idee für sämtliche Styles auf gestylte JS-Elemente zu setzen, da dann React auch auf Seiten geladen werden müsste, wo es eigentlich nicht gebraucht wird. Oder du erzeugst mit dem Laden einen "[FOUC][fouc]", wenn dein statisches HTML geladen wird, aber der Browser noch darauf wartet, dass JavaScript vollständig heruntergeladen und ausgeführt wird. Oder stelle dir ein weiteres Beispiel am anderen Ende des Spektrums vor: _BEM_. Du kannst in Astro einen vollständig entkoppelten [BEM][bem]- oder [SMACSS][smacss]-Ansatz verfolgen. Doch das bedeutet eine große Menge manueller Wartung, die du vermeiden könntest - und es lässt dich vieles von dem Komfort verpassen, den dir [Astro-Komponenten](/de/core-concepts/astro-components) bieten können.
-
-Wir denken, es gibt einen Mittelweg zwischen intuitivem, aber langsamem CSS-in-JS und schnellem, aber mühseligem globalem CSS: **Hybrides Scoped-CSS + Utility-CSS**. Dieser Ansatz funktioniert gut in Astro, ist performant für die Nutzerinnen und Nutzer und ist entsprechend die wohl beste Styling-Lösung in Astro für _die meisten Leute_ (vorausgesetzt du bist bereit dich damit auseinanderzusetzen). Eine kurze Übersicht:
-
-**Dieser Ansatz ist gut für…**
-
- Entwickler und Entwicklerinnen die etwas Neues bezüglich Styling ausprobieren wollen
- Entwickler und Entwicklerinnen die ein paar dogmatische Annahmen bezüglich der CSS-Architektur zu schätzen wissen
-
-**Dieser Ansatz ist _NICHT_ gut für…**
-
- Entwickler und Entwicklerinnen die bereits selbst starke dogmatische Annahmen bezüglich des Styling haben - und alles selbst kontrollieren wollen
-
-Lies weiter, wenn du nach ein paar dogmatischen Annahmen suchst 🙂. Wir werden den Ansatz beschreiben, indem wir ein paar Grundregeln festlegen, die dich anleiten sollen deine Styles zu definieren:
-
-### Hybrides Scoped-CSS + Utility-CSS
-
-#### Scoped Styles
-
-Du benötigst keine Erläuterung zu Komponenten-basiertem Design. Dir ist bereits klar, dass die Wiederverwendung von Komponenten eine gute Idee ist. Und es war diese Idee, die die Leute dazu brachte sich an Konzepte wie [gestylte Komponenten][styled-components] und [gestyltes JSX][styled-jsx] zu gewöhnen. Aber anstatt deine Nutzerinnen und Nutzer mit den langen Ladezeiten von CSS-in-JS zu belasten, kannst du mit Astro etwas Besseres einsetzen: **eingebaute Styles im Scope der Komponente**.
-
-```astro
---
-// src/components/Button.astro -->
---
-<style lang="scss">
-  /* ✅ Lokal im Scope! */
-  .btn {
-    padding: 0.5em 1em;
-    border-radius: 3px;
-    font-weight: 700;
-  }
-</style>
-<button type="button" class="btn">
-  <slot></slot>
-</button>
-```
-
-_Beachte: Wir verwenden hier in sämtlichen Beispielen `lang="scss"`, welches das Verschachteln und Teilen von [Farben und Variablen][sass-use] stark vereinfacht. Dies ist jedoch gänzlich optional, und du kannst ebenso gut normales CSS verwenden._
-
-Die `.btn`-Klasse ist auf die Komponente begrenzt und wird nicht über das Dokument hinaus wirksam. Dies bedeutet, du kannst dich **auf das Styling und musst dich nicht auf die Benennung konzentrieren**. Dieser Ansatz, der das Lokale an den Anfang stellt, fügt sich sehr gut in das ESM-getriebene Design von Astro, das Einkapselung und Wiederverwendbarkeit über eine globale Wirksamkeit stellt. Auch wenn es sich um ein einfaches Beispiel handelt, sollte festgehalten werden, dass dies **extrem gut skaliert**. Und für den Fall, dass du gemeinsame Werte zwischen Komponenten teilen willst, empfehlen wir das [Sass-Modulsystem][sass-use], das sehr einfach zu verwenden ist und sich perfekt in ein Design einfügt, in dem die Komponente an den Anfang gestellt wird.
-
-Im Kontrast zu diesem Ansatz erlaubt Astro auch globale Styles mittels der `:global()` und `<style global>`-Notlösungen. Es sollte jedoch soweit möglich vermieden werden sie einzusetzen. Ein einfaches Beispiel: Nehmen wir an, du hast deinen Button in einer `<Nav />`-Komponente verwendet und willst ihn dort anders gestalten. Du könntest versucht sein, das folgendermaßen zu probieren:
-
-```astro
---
-// src/components/Nav.astro
-import Button from './Button.astro';
---
-
-<style lang="scss">
-  .nav :global(.btn) {
-    /* ❌ Dies wird einen Konflikt mit <Button>-Styles erzeugen */
-  }
-</style>
-
-<nav class="nav">
-  <Button>Menü</Button>
-</nav>
-```
-
-Dies ist allerdings nicht erstrebenswert, da nun `<Nav>` und `<Button>` bei der endgültigen Gestaltung des Buttons konkurrieren. Sobald du jetzt den einen veränderst, musst du auch den anderen anpassen, und sie sind nicht mehr wirklich isoliert, so wie zuvor (sie sind nun verbunden in bidirektionaler Abhängigkeit). Es ist sehr leicht sich vorzustellen, dass dieses Modell nur ein paar mal wiederholt werden muss, bis die Befürchtung aufkommt, dass jede Veränderung von Styles _irgendwo_ das Styling in einem ganz anderem Teil der Anwendung kaputt macht.
-
-Stattdessen kannst du `<Button>` seine eigenen Styles kontrollieren lassen und es mit einer Prop versuchen:
-
-```astro
---
-// src/components/Button.astro
-const { theme } = Astro.props;
---
-<style lang="scss">
-  .btn {
-    /* ✅  <Button> hat nun wieder die Kontrolle über das Styling! */
-    [data-theme='nav'] {
-      // nav-friendly styles here…
-    }
-  }
-</style>
-
-<button type="button" data-theme={theme}>
-  <slot></slot>
-</button>
-```
-
-An anderer Stelle kannst du nun `<Button theme="nav">` verwenden, um zu bestimmen, welche Art von Button es ist. Dies bewahrt den Vertrag, in dem steht, dass _Button sich um seine Styles kümmert und Nav sich um seine_. Und du kannst den einen bearbeiten ohne den anderen zu beeinflussen. Der schlimmstmögliche Fall bei der Verwendung globaler Styles ist, dass eine Komponente kaputt und nicht mehr nutzbar ist (ihr fehlen wesentliche Teile ihrer Styles). Aber der schlimmstmögliche Fall bei der Verwendung von Props (z. B. bei einem Tippfehler) ist, dass die Komponente zurückgesetzt wird auf ihren ursprünglichen, aber immer noch nutzbaren, Zustand.
-
-💁 **Warum dies mit Astro gut funktioniert**. Astro ist im Wesentlichen von JavaScript-Modulen inspiriert: Du musst zu jeder Zeit nur wissen, was sich in deiner Datei befindet, und du musst dir niemals Gedanken darüber machen, welches Element aus einer anderen Datei Einfluss darauf hat, wie der Code ausgeführt wird. Aber wir sind damit nicht allein; Vue und Svelte haben beide die Idee vorangetrieben und popularisiert, dass Markup und Styles in ein und derselben Komponenten-Datei gut zusammenpassen. [Du kannst verschiedene Belange immer noch gut voneinander trennen][peace-on-css], sogar wenn Markup, Styles und Logik in einer Datei enthalten sind. Und tatsächlich ist es genau das, was Komponeten-Design so mächtig macht! Du kannst also einfach CSS schreiben ohne fürchten zu müssen, dass du einen Namen verwendest, der bereits von einer anderen Komponente in der App verwendet wird.
-
-#### Utility-CSS
-
-Vor Kurzem gab es eine Debatte über die ausschließliche Verwendung von Komponenten-Styles im Scope vs. die ausschließliche Verwendung von Utility-CSS. Aber wir stimmen Leuten wie Sarah Dayan zu, die fragen, [warum können wir nicht beides haben][utility-css]? Tatsache ist doch, dass während es großartig ist, Styles im Scope der Komponente zu haben, es immer noch hunderte von Male vorkommt, dass wenn die Website vollständig zusammengesetzt ist, zwei Elemente nicht _gut_ zusammenspielen und eines von beiden einen kleinen Stupser braucht. Oder es wird vielleicht eine abweichende Behandlung eines Textes in einer Komponenten-Instanz benötigt.
-
-Zwar ist die Vorstellung von perfekten, makellosen Komponenten schön, aber sie ist auch unrealistisch. Kein Design-System ist absolut perfekt, und jedes Design-System zeigt auch Ungereimtheiten. Und es passiert bei dem Versuch diese Ungereimtheiten aufzulösen, dass Komponenten ohne Utility-CSS durcheinander geraten. Utility-CSS ist großartig darin kleinere Optimierungen hinzuzufügen, um die Website fertigzustellen und ausliefern zu können. Aber es ist an sich auch unvollständig auf ganz eigene Art - wenn du z. B. jemals versuchst responsive Styles oder Fokussierungen mit Utility-CSS zu verwalten, kann das schnell zu einem großen Durcheinander werden!  
-**Utility-CSS funktioniert am besten in Partnerschaft mit Styles im Scope der Komponente**. Und um so leicht wie möglich anwendbar zu sein, sollte Utility-CSS global sein (und sollte möglicherweise auch das einzige globale CSS sein - vielleicht neben reset.css), so dass du nicht mit Importen arbeiten musst, die allesamt willkürlich sind.
-
-Einige größere Probleme, die am besten mit Utility-CSS gelöst werden, sind:
-
- [margin](https://github.com/drwpow/sass-utils#-margin--padding)
- [padding](https://github.com/drwpow/sass-utils#-margin--padding)
- [text- und background-color](https://github.com/drwpow/sass-utils#-color)
- [font-size und font-family](https://github.com/drwpow/sass-utils#%F0%9F%85%B0%EF%B8%8F-font--text)
- [Standardelement-Styling](https://github.com/kognise/water.css)
-
-In Astro empfehlen wir folgendes Setup hierfür:
-
-```html
-<head>
-  <link rel="stylesheet" href={Astro.resolve("../styles/global.css")} >
-</head>
-```
-
-Und in deinem lokalen Dateisystem kannst du natürlich auch Sass' [@use][sass-use] verwenden, um Dateien umstandslos miteinander zu kombinieren:
-
-```
-├── src/
-│   └── styles/
-│       ├── _base.scss
-│       ├── _tokens.scss
-│       ├── _typography.scss
-│       ├── _utils.scss
-│       └── global.scss
-```
-
-Was in jeder dieser Dateien stehen sollte, musst du selbst bestimmen, aber es lohnt sich, klein anzufangen. Füge Utilities immer erst hinzu, sobald du sie benötigst, und du wirst dein CSS-Gewicht unglaublich gering halten können. Und Utilities die du selbst geschrieben hast, um deinen realen Bedarf zu erfüllen, werden immer besser sein als etwas aus dem Regal.
-
-Zusammengefasst kannst du dir Styles im Scope der Komponente als das Rückgrat deiner gesamten Styles vorstellen, was etwa 80% ausmacht - und die fehlenden 20% füllen CSS-Utilities. Beide funktionieren gut im Tandem und gleichen gegenseitig ihre Schwächen aus.
-
-💁 **Warum dies in Astro gut funktioniert**: Astro wurde um die Idee von **"Scoped-CSS und globales Utility-CSS leben harmonisch zusammen** ♥️!" herum entwickelt. Nutze das so gut du kannst.
-
-### Weitere Vorschläge
-
-"Aber halt!", wirst du vielleicht sagen, nachdem du den vorherigen Abschnitt gelesen hast. "Das berücksichtigt nicht [meinen Anwendungsfall]!" Wenn du nach weiteren Ratschlägen zu einigen gängigen Styling-Problemen suchst, könnten dich die folgenden Vorschläge ineteressieren. Sie stehen alle miteinander in Verbindung und passen zu der Philosophie von **Hybrides Scoped-CSS + Utility-CSS**.
-
-1. Unterteile deine App in Layout-Komponenten und Basis-Komponenten
-2. Vermeide Flexbox- und Grid-Bibliotheken (schreibe deine eigenen!)
-3. Vermeide die Verwendung von `margin` in Wrappern für Komponenten
-4. Vermeide globale Media-Queries
-
-#### Vorschlag #1: Unterteile deine App in Layout-Komponenten und Basis-Komponenten
-
-Sicher wird diese Anleitung niemals lang genug sein, um die Frage zu beantworten _"Wie sollte eine Seite aufgebaut sein?"_ (das ist ein [Design-Problem!][cassie-evans-css]).
-Und doch liegt darin versteckt auch eine etwas spezifischere Frage, die wir beantworten _können_: _"Ein bestimmtes Layout angenommen - wie sollten Komponenten und Styles darin organisiert sein?"_ Die Antwort ist, **brenne niemals das Layout in Komponenten ein**. Erzeuge Layout-Komponenten, die das Layout bestimmen, und Basis-Komponenten (Buttons, Karten etc.) die nicht das Layout bestimmen. _Was bedeutet das?_ Gehen wir das an einem Beispiel durch, damit es klarer wird. Angenommen wir haben eine Seite, die folgendermaßen aussieht (die Zahlen stehen für unterschiedliche Komponenten):
-
-```
-|---------------|
-|       1       |
-|-------+-------|
-|   2   |   2   |
-|---+---|---+---|
-| 3 | 3 | 3 | 3 |
-|---+---+---+---|
-| 3 | 3 | 3 | 3 |
-|---+---+---+---|
-```
-
-Das Layout besteht aus einem riesig großen Post über die gesamte Breite, gefolgt von Posts mit halber Breite darunter. Und darunter wollen wir einen Haufen kleinerer Posts, die den Rest der Seite auffüllen. Der Einfachheit halber nennen wir sie `<RiesenPost>` (1), `<HalbePosts>` (2), und `<KleinePosts>` (3). Wir fügen sie wie folgt unserer Seite hinzu:
-
-```astro
---
-// src/pages/index.astro
-
-import Nav from '../components/Nav.astro';
-import RiesenPost from '../components/RiesenPost.astro';
-import Grid from '../components/Grid.astro';
-import HalbePosts from '../components/HalberPost.astro';
-import KleinePosts from '../components/KleinerPost.astro';
-import Footer from '../components/Footer.astro';
---
-<html>
-  <body>
-    <Nav />
-
-    <Grid>
-      <RiesenPost />
-      <HalbePosts />
-      <KleinePosts />
-    </Grid>
-
-    <Footer />
-  </body>
-</html>
-```
-
-Das ist _anscheinend_ sauber voneinander getrennt, aber der Schein kann trügen. Auf den ersten Blick nehmen wir vielleicht an, dass `<Grid>` das Layout kontrolliert, aber dieser Eindruck täuscht. Tatsächlich bestimmt `<RiesenPost>` seine Breite selbst, `<HalbePosts>` lädt zwei Komponenten und bestimmt die eigene Breite, und `<KleinePosts>` lädt vier oder mehr Komponenten und bestimmt seine eigene Breite. Insgesamt - `<Grid>` eingeschlossen - streiten sich **vier Komponenten** um dasselbe Layout. Entferne einen Post von `<HalbePosts>` und das Layout zerbricht. Bearbeite `<RiesenPost>`, das Layout zerbricht. Bearbeite `<Grid>`, das Layout zerbricht. Wenn du es dir genau überlegst, ist keine dieser Komponenten wirklich wiederverwendbar - sie könnten auch einfach in einer einzigen großen Datei stehen.
-
-Das ist tatsächlich das **Problem mit globalem CSS** in hübscher Verkleidung - mehrere Komponenten kämpfen darum, wie sie angeordnet werden, ohne dass es ein Layout in zentraler Verantwortung gibt (in der Art wie globales CSS)! Nun, da wir das Problem identifiziert haben, bestünde eine Möglichkeit es zu lösen darin, das gesamte Layout auf die oberste Ebene zu heben und dort ebenfalls alle Komponenten zu laden:
-
-```astro
---
-// src/pages/index.astro
-
-import Nav from '../components/Nav.astro';
-import RiesenPost from '../components/RiesenPost.astro';
-import HalbePosts from '../components/HalberPost.astro';
-import KleinePosts from '../components/KleinerPost.astro';
-import Footer from '../components/Footer.astro';
---
-
-<html>
-  <head>
-    <style lang="scss">
-      .wrapper {
-        max-width: 60rem;
-        margin-right: auto;
-        margin-left: auto;
-        padding-right: 2rem;
-        padding-left: 2rem;
-      }
-
-      .grid {
-        display: grid;
-        grid-gap: 1.5rem;
-        grid-template columns: 1fr 1fr 1fr 1fr;
-      }
-
-      .riesen-post {
-        grid-column: span 4;
-      }
-
-      .halber-post {
-        grid-column: span 2;
-      }
-
-      .kleiner-post {
-        grid-column: span 1;
-      }
-    </style>
-  </head>
-  <body>
-    <Nav />
-
-    <div class="wrapper">
-      <div class="grid">
-        <div class="riesen-post"><RiesenPost postId={12345} /></div>
-
-        <div class="halber-post"><HalberPost postId={12345} /></div>
-        <div class="halber-post"><HalberPost postId={12345} /></div>
-
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-        <div class="kleiner-post"><KleinerPost postId={12345} /></div>
-      </div>
-    </div>
-
-    <Footer />
-  </body>
-</html>
-```
-
-Einmal davon abgesehen, dass das mehr Code ist, bedeutet es tatsächlich eine viel klarere Trennung. Was zuvor ein 4-Komponenten-Layout war, wird nun zu 100% innerhalb der `index.astro`-Datei auf der obersten Ebene verwaltet (welche wir nun als **Layout-Komponente** betrachten - und wenn wir es weiterverwenden wollten, könnten wir es auch in eine eigene Datei extrahieren). Dein Layout ist jetzt zentralisiert, und die Komponenten sind nun wirklich wiederverwendbar, da es ihnen komplett egal ist, ob sie sich mit den anderen im selben Grid befinden oder nicht. Du kannst in jeder dieser Dateien die Styles bearbeiten ohne Gefahr zu laufen, dadurch Styles in anderen zu stören.
-
-Die Grundregel beim Arrangieren mehrerer Komponenten lautet, **es handelt sich um eine besondere Verantwortung**, die an einem zentralen Ort wahrgenommen werden sollte, anstatt über vier Komponenten hinweg, wie wir es angelegt hatten. Und tatsächlich sind Seiten auf der obersten Ebene sehr gut darin und sie sollten dir stets als Ausgangspunkt für deine Layout-Komponenten dienen. Probiere aus, wie weit du damit kommst, und extrahiere nur dann Layout-Komponenten hieraus, wenn es absolut notwendig ist.
-
-Zusammengefasst: **Wenn du mehrere Dateien anfassen musst, um dein Layout zu ändern, solltest du vielleicht alles gmeinsam in einer einzelnen Layout-Komponente neu organisieren.**
-
-💁 **Warum das in Astro gut funktioniert**: In Astro kann alles eine `.astro`-Komponente sein, und du bekommst niemals Performance-Probleme, gleichgültig wieviele Komponenten du hinzufügst. Aber der größte Vorteil beim Einsatz von [Layout-Isolierung][layout-isolated] besteht in den Einsparungen bei der Menge an CSS, die du benötigst.
-
-#### Vorschlag #2: Vermeide Flexbox- und Grid-Bibliotheken (schreibe deine eigenen!)
-
-Es mag sich sehr übergriffig anfühlen, wenn dir gesagt wird, du solltest deine geliebte Layout-Bibliothek, mit der du gut vertraut bist, nicht verwenden. Immerhin hat sie dich bis hierher gebracht! Aber die Zeiten von [Float-Madness](https://zellwk.com/blog/responsive-grid-system/) sind vorbei, ersetzt durch Flexbox und Grid - und um die zu verwalten brauchen wir keine Bibliotheken (Bibliotheken können die Aufgabe sogar erschweren).
-
-Viele Front-End-Entwicklerinnen und -Entwickler kennen den folgenden Gedankengang:
-
-1. Ich sollte soviel CSS wie möglich mehrfach verwenden (_gut!_)
-2. Viele Seiten verwenden dasselbe Layout (_hmm?_)
-3. Ich könnte eine bereits bestehende Lösung einsetzen, um meine gesamten Layout-Duplikate zu verwalten (_Moment mal!_)
-
-Während die Logik in sich stimmig ist, ist es in Wirklichkeit doch so, dass #2 nur selten auf ein Projekt zutrifft. Möglicherweise wurden viele Teile der Website nicht entwickelt, um in diese netten, gepflegten 12-Säulen-Raster einer Bibliothek zu passen. Sogar relativ bescheidene Websites können _hunderte_ Layouts enthalten, wenn du sämtliche Breakpoints mit einrechnest. Frage dich einmal selbst: _Wenn die Website, die ich baue, wirklich soviele unterschiedliche Layouts beinhaltet, warum verwende ich dann eine schwergewichtige Grid-Bibliothek, die mir nur generische Layouts ermöglicht?_
-
-Ein paar gut geschriebene Zeilen CSS-Grid hier und da werden sich perfekt an jede Situation anpassen; das Ganze ist höchstwahrscheinlich leichtgewichtiger und einfacher zu verwalten, als die schwergewichtige Bibliothek, mit der du doch so lange gekämpft hast. Anders herum betrachtet: Wenn du schon einige Stunden benötigst, um eine proprietäre Styling-Bibliothek zu lernen, dich mit ihr auseinanderzusetzen, Probleme zu melden etc., wäre es nicht besser diese Zeit darauf zu verwenden den Umgang mit Flexbox und Grid zu erlernen? Viele Leute brauchen nur eine Stunde, um die Grundlagen ausreichend zu verstehen - und damit kommt man schon ziemlich weit! Es gibt großartige kostenlose Lernmöglichkeiten, in die du deine Zeit investieren kannnst:
-
- [Flexbox Froggy](https://flexboxfroggy.com/)
- [CSS Grid Garden](https://cssgridgarden.com/)
-
-Kurz gesagt: Hör auf Layouts zu vereinfachen, wenn da nichts zu vereinfachen ist! Du wirst sehen, dass nicht nur deine Styles leichter zu organisieren, sondern dein CSS auch leichter und die Ladezeiten kürzer sind.
-
-💁 **Warum das in Astro gut funktioniert**: Grid-Bibliotheken sind ein einfacher und schneller Weg, um Stylesheets aufzublähen - und damit auch ein wesentlicher Beitrag zum Gebrauch von [Treeshaking][css-treeshaking], um überflüssige Styles wieder loszuwerden. Astro verwendet **kein** Treeshaking, um ungenutztes CSS für dich zu entfernen, da dies zu [Problemen][css-treeshaking] führen kann. Wir sagen nicht, dass du vollständig ohne Bibliotheken arbeiten sollst; wir sind große Fans von einigen Bibliotheken, wie zum Beispiel [Material UI][material-ui]. Aber wenn du zumindest die abertausende Layouts, die du nicht verwendest, aus deiner Bibliothek entfernen kannst, musst du später möglicherweise auch kein automatisches Treeshaking einsetzen.
-
-#### Vorschlag #3: Vermeide die Verwendung von `margin` in Wrappern für Komponenten
-
-Anders ausgedrückt, tu Folgendes nicht:
-
-```astro
-<!-- src/components/MeineKomponente.astro -->
-<style lang="scss">
-  .wrapper {
-    /* ❌ Tu das nicht! */
-    margin-top: 3rem;
-  }
-</style>
-
-<div class="wrapper"></div>
-```
-
-Wenn du dir das [CSS-Box-Model][box-model] vor Augen führst, dehnt sich darin `margin` stets über die Grenzen einer Box hinweg aus. Das bedeutet, wenn du `margin` auf das äußerste Element deiner Komponente anwendest, wird dies die Position angrenzender Komponenten beeinflussen. Selbst wenn die Styles im Scope der Komponete sind, betreffen sie _technisch_ auch Elemente um die Komponente herum - somit bricht dies mit dem [Konzept der Einschließung von Styles][layout-isolated].
-
-Wenn du Komponenten verwendest, die sich neu arrangieren oder anders dargestellt werden, sobald sie sich in der Nähe anderer Komponenten befinden, bedeutet dies einen Kampf, den du nur schwer gewinnen kannst. **Komponenten sollten sich identisch verhalten und aussehen, unabhängig davon wo sie platziert werden.** Das ist es, was sie zu Komponenten macht!
-
-💁 **Warum das in Astro gut funktioniert**: `margins` die andere Komponenten herumschubsen, unterwandern deine Styling-Architektur auf heimtückische Weise, und das kann zu wackeligen oder brüchigen Layout-Komponenten führen. Solche Dinge grundsätzlich zu vermeiden, erlaubt dir deine Layout-Komponenten einfach zu halten - und du wirst weniger Zeit mit Styling zubringen.
-
-#### Vorschlag #4: Vermeide globale Media-Queries
-
-Dieser letzte Punkt behandelt eine natürliche Beschränkung von **Styles im Scope**. Und diese bezieht sich auch auf Breakpoints! Du kennst diesen einen, seltsamen Breakpoint, bei dem deine `<Card />`-Komponente bei einer bestimmten Größe ungünstig umbricht? Du solltest dieses Problem innerhalb von `<Card />` lösen, und nicht _irgendwo_ anders.
-
-Selbst wenn du am Ende einen willkürlichen Wert wie `@media (min-width: 732px)` verwendest, wird das wahrscheinlich besser funktionieren, als es irgendwo mit einer _globalen_ [magischen Zahl][magic-number] zu probieren, die aber doch nur _in einem einzigen Kontext_ angewandt wird (eine willkürliche Zahl mag für den Rest der Anwendung "rätselhaft" sein, aber sie hat immer noch eine "konkrete" Bedeutung im Kontext einer Komponente, die diesen Wert benötigt).
-
-Zugegeben, diese Art von Konflikt vollständig zu lösen war bisher nahezu unmöglich; glücklicherweise gibt es inzwischen wachsende [Unterstützung für Container-Queries!][container-queries].
-
-Ein weiterer Anlass zur Beschwerde bei diesem Ansatz liegt in der Frage, "_Was ist aber, wenn ich zwei Komponenten habe, die dasselbe am selben Breakpoint tun?_", worauf ich antworten würde: Ein oder zwei solcher Punkte wird es immer geben; behandle sie einfach wie _Sonderfälle_. Wenn aber deine gesamte Anwendung aus Dutzenden solcher Fälle besteht, solltest du versuchen die Unterteilung deiner Komponenten so zu verändern, dass sie grundsätzlich deine [Layout-Isolierung][layout-isolated] besser unterstützen.
-
-💁 **Warum das in Astro gut funktioniert**: Dies ist wahrscheinlich der am wenigsten wichtige Punkt, weshalb er auch am Ende steht. Tatsächlich kannst du ihn auch überspringen, wenn er so für dich keine Rolle spielt. Aber es handelt sich um etwas, dem Leute versuchen in größerem Umfang Rechnung zu tragen - und dafür ein _globales_ System zu verwenden kann auch vollkommen unnötig sein. Versuche einmal _nicht_ auf globale Media-Queries ausgerichtet zu entwickeln - und schau wie weit du damit kommst!
-
-### 👓 Weitere Lektüre
-
-Diese Anleitung wäre nicht möglich ohne die folgenden Blogposts, die auf diese Themen eingehen und sie vertiefend erklären. Bitte lies sie - es lohnt sich!
-
- [**Layout-isolated Components**][layout-isolated] von Emil Sjölander
- [**In defense of utility-first CSS**][utility-css] von Sarah Dayan
-
-Wirf bitte auch einen Blick auf das [Stylelint][stylelint]-Projekt, mit dem du deine Styles in Form bringen kannst. Du bringst dein JS in Form, warum nicht auch dein CSS?
-
-[autoprefixer]: https://github.com/postcss/autoprefixer
-[astro-component]: /de/core-concepts/astro-components#css-styles
-[astro-resolve]: /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
-[browserslist-defaults]: https://github.com/browserslist/browserslist#queries
-[cassie-evans-css]: https://twitter.com/cassiecodes/status/1392756828786790400?s=20
-[container-queries]: https://ishadeed.com/article/say-hello-to-css-container-queries/
-[css-modules]: https://github.com/css-modules/css-modules
-[css-treeshaking]: https://css-tricks.com/how-do-you-remove-unused-css-from-a-site/
-[fouc]: https://en.wikipedia.org/wiki/Flash_of_unstyled_content
-[layout-isolated]: https://web.archive.org/web/20210227162315/https://visly.app/blogposts/layout-isolated-components
-[less]: https://lesscss.org/
-[issues]: https://github.com/withastro/astro/issues
-[magic-number]: https://css-tricks.com/magic-numbers-in-css/
-[material-ui]: https://material.io/components
-[peace-on-css]: https://didoo.medium.com/let-there-be-peace-on-css-8b26829f1be0
-[sass]: https://sass-lang.com/
-[sass-use]: https://sass-lang.com/documentation/at-rules/use
-[smacss]: http://smacss.com/
-[styled-components]: https://styled-components.com/
-[stylus]: https://stylus-lang.com/
-[styled-jsx]: https://github.com/vercel/styled-jsx
-[stylelint]: https://stylelint.io/
-[svelte-style]: https://svelte.dev/docs#style
-[tailwind]: https://tailwindcss.com
-[tailwind-utilities]: https://tailwindcss.com/docs/adding-new-utilities#using-css
-[utility-css]: https://frontstuff.io/in-defense-of-utility-first-css
-[vite-preprocessors]: https://vitejs.dev/guide/features.html#css-pre-processors
-[vue-css-modules]: https://vue-loader.vuejs.org/guide/css-modules.html
-[vue-scoped]: https://vue-loader.vuejs.org/guide/scoped-css.html
--- a/docs/src/pages/de/installation.md
+++ b/docs/src/pages/de/installation.md
@ -1,178 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Installation
-description: So installierst du Astro mit NPM, PNPM oder Yarn.
---
-
-Es gibt verschiedene Möglichkeiten Astro mit einem neuen Projekt zu installieren.
-
-## Vorbereitungen
-
- **Node.js** - `v14.15.0`, `v16.0.0` oder höher
- **Texteditor** - Wir empfehlen [VS Code](https://code.visualstudio.com/) mit unserer [offiziellen Astro-Erweiterung](https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode)
- **Terminal** - Astro wird im Wesentlichen über die Befehlszeile des Terminals gesteuert
-
-Zu Demonstrationszwecken verwenden wir in den folgenden Beispielen [`npm`](https://www.npmjs.com/), aber du kannst ebenso [`yarn`](https://yarnpkg.com/) oder [`pnpm`](https://pnpm.io/) verwenden, falls du eine npm-Alternative bevorzugst.
-
-## Astro-Projekt erzeugen
-
-`npm init astro` ist der einfachste Weg in einem neuen Projekt Astro zu installieren. Führe diesen Befehl in deinem Terminal aus, um unseren `create-astro`-Installationsassistenten zu starten, der dich bei der Einrichtung eines neuen Projekts unterstützt.
-
-```shell
-# Mit NPM
-npm init astro
-
-# Yarn
-yarn create astro
-
-# Pnpm
-pnpm create astro
-```
-
-Der [`create-astro`](https://github.com/withastro/astro/tree/main/packages/create-astro)-Assistent lässt dich aus einer Reihe von [Start-Vorlagen](https://github.com/withastro/astro/tree/main/examples) auswählen. Alternativ könntest du auch dein eigenes Astro-Projekt direkt aus GitHub heraus importieren.
-
-```bash
-# Hinweis: Ersetze "mein-astro-projekt" durch den Namen deines Projekts.
-
-# npm 6.x
-npm init astro mein-astro-projekt --template starter
-# npm 7+ (zusätzliche Bindestriche sind erforderlich)
-npm init astro mein-astro-projekt -- --template starter
-# yarn
-yarn create astro mein-astro-projekt --template starter
-# pnpm
-pnpm create astro mein-astro-projekt -- --template starter
-# Verwenden einer Drittanbietervorlage
-npm init astro mein-astro-projekt -- --template [GITHUB_NAME]/[REPO_NAME]
-# Verwenden einer Drittanbietervorlage innerhalb eines Repos
-npm init astro mein-astro-projekt -- --template [GITHUB_NAME]/[REPO_NAME]/pfad/zur/vorlage
-```
-
-Nachdem `create-astro` dein Projekt eingerichtet hat, denke daran die Abhängigkeiten deines Projekts mittels npm oder dem Paketmanager deiner Wahl zu installieren. In diesem Beispiel verwenden wir npm:
-
-```bash
-npm install
-```
-
-Du kannst dein Astro-Projekt nun [starten](#start-astro). Sobald du dein Astro-Projekt fertiggestellt hast, kannst du dein Projekt [kompilieren](#build-astro). Astro wird dann deine Anwendung fertig packen und dafür die statischen Seiten generieren, die du bei deinem bevorzugten Hosting-Anbieter [veröffentlichen](/guides/deploy) kannst.
-
-## Manuelle Installation
-
-Du kannst Astro auch ohne die Hilfe des `create-astro`-Assistenten einrichten. Nachfolgend findest du die wenigen zusätzlichen Schritte, die erforderlich sind, um Astro zum Laufen zu bringen.
-
-### Setze dein Projekt auf
-
-```bash
-# Verzeichnis erzeugen und in das Verzeichnis wechseln
-mkdir mein-astro-projekt
-cd mein-astro-projekt
-```
-
-Erstelle ein leeres Verzeichnis mit dem Namen deines Projekts und navigiere dann dorthin.
-
-### Erzeuge `package.json`
-
-```bash
-# Dieser Befehl erstellt eine grundlegende package.json-Datei für dich
-npm init --yes
-```
-
-Astro ist darauf ausgerichtet mit dem gesamten npm-Paket-Ökosystem zu arbeiten. Diese Arbeit wird durch ein Projektmanifest im Stammverzeichnis deines Projekts verwaltet, das als `package.json` bekannt ist. Für den Fall, dass du mit der `package.json`-Datei nicht vertraut bist, empfehlen wir dir dich kurz dazu in der [npm-Dokumentation] (https://docs.npmjs.com/creating-a-package-json-file) einzulesen.
-
-### Installiere Astro
-
-Soweit du den obigen Anweisungen gefolgt bist, solltest du ein Verzeichnis mit einer einzelnen `package.json`-Datei darin haben. Du kannst Astro jetzt in deinem Projekt aufsetzen.
-
-```bash
-npm install astro
-```
-
-Jetzt kannst du den Platzhalter im Abschnitt "scripts" deiner `package.json`-Datei, die `npm init` für dich erstellt hat, durch Folgendes ersetzen:
-
-```diff
-  "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1"
-+    "dev": "astro dev",
-+    "build": "astro build",
-+    "preview": "astro preview"
-  },
-}
-```
-
-Der Befehl [`dev`](#start-astro) startet den Astro Entwicklungsserver auf `http://localhost:3000`. Sobald dein Projekt fertig ist, gibt der Befehl [`build`](#build-astro) dein Projekt in das Verzeichnis `dist/` aus. [Lese mehr über das Veröffentlichen von Astro-Builds](/guides/deploy).
-
-### Erstelle deine erste Seite
-
-Öffne deinen bevorzugten Texteditor und erstelle eine neue Datei in deinem Projekt:
-
-1. Erstelle eine neue Datei unter `src/pages/index.astro`.
-2. Kopiere den folgenden Code-Schnipsel (einschließlich der Bindestriche `---`) und füge ihn ein.
-
-```astro
---
-// JS/TS-Code, der zwischen den (---) Bindestrichen geschrieben wurde,
-// wird ausschließlich auf dem Server ausgeführt!
-console.log('Du siehst mich im Terminal')
---
-
-<html>
-  <body>
-    <h1>Hello, World!</h1>
-  </body>
-</html>
-
-<style lang='css||scss'>
-  body{
-    h1{
-      color:orange;
-    }
-  }
-</style>
-
-<script>
- // Hier eingegebener JS-Code wird ausschließlich im Browser ausgeführt
- console.log('Du siehst mich in den devTools')
-</script>
-```
-
-Das Obige ist ein Beispiel für Astros Komponenten-Syntax, die sowohl HTML als auch JSX umfasst.
-
-Du kannst weitere Seiten im Verzeichnis `src/pages` erstellen - Astro verwendet den Dateinamen, um neue Seiten für deine Site zu erzeugen. Zum Beispiel wird Astro durch das Erzeugen einer neuen Datei unter `src/pages/about.astro` (auch unter Wiederverwendung des Code-Schnipsels) eine neue Seite unter der URL `http://localhost/about` generieren.
-
-## [Starte Astro](#start-astro)
-
-```bash
-npm run dev
-```
-
-Astro wird von nun an deine Anwendung unter `http://localhost:3000` bereitstellen. Wenn du diese URL in deinem Browser öffnest, solltest du Astros "Hello, World" sehen.
-
-Falls du deinen Entwicklungsfortschritt im lokalen Netzwerk teilen oder die Anwendung von einem Telefon aus testen möchtest, füge einfach die folgende [snowpack](https://www.snowpack.dev/reference/configuration#devoptionshostname)-Option in `astro.config.mjs` hinzu:
-
-```js
-devOptions: {
-  hostname: '0.0.0.0';
-}
-```
-
-## [Kompiliere dein Projekt](#build-astro)
-
-Führe in deinem Projektverzeichnis den folgenden Befehl im Terminal aus:
-
-```bash
-npm run build
-```
-
-Dies weist Astro an deine Site zu erstellen und direkt zu speichern. Deine Anwendung steht nun im `dist/`-Verzeichnis bereit.
-
-## Nächste Schritte
-
-Geschafft! Du kannst jetzt mit dem Entwickeln beginnen!
-
-Wir möchten dich ermutigen, dir etwas Zeit zu nehmen, um mit der Art und Weise vertraut zu werden, wie Astro funktioniert. Am besten befasst du dich weitergehend mit der Dokumentation. Hier ein paar Empfehlungen:
-
-📚 Lerne mehr über die Projektstruktur in Astro in unserem [Artikel zur Projektstruktur](/de/core-concepts/project-structure)
-
-📚 Lerne mehr über die Komponenten-Syntax in Astro in unserem [Artikel zu Astro-Komponenten](/de/core-concepts/astro-components)
-
-📚 Lerne mehr über das dateibasierte Routing in Astro in unserem [Artikel zu Astro-Seiten](/de/core-concepts/astro-pages) und unserem [Artikel über Routing](/de/core-concepts/routing).
--- a/docs/src/pages/de/migration/0.21.0.md
+++ b/docs/src/pages/de/migration/0.21.0.md
@ -1,229 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Umstellung auf v0.21
-description: Projekte von Astro v0.20 umziehen.
---
-
-## Vite
-
-Beginnend mit v0.21 werden Astro-Builds mittels [Vite](https://vitejs.dev) kompiliert.
-Bedingt hierdurch sollten Konfigurationen, die in `snowpack.config.mjs` geschrieben wurden, nach `astro.config.mjs` transferiert werden.
-
-```js
-// @ts-check
-
-/** @type {import('astro').AstroUserConfig} */
-export default {
-  renderers: [],
-  vite: {
-    plugins: [],
-  },
-};
-```
-
-Um mehr über die Konfiguration von Vite zu erfahren, lies bitte den [Vite Configuration Guide](https://vitejs.dev/config).
-
-## Aliasierung
-
-In Astro v0.21 können Aliase in `tsconfig.json` oder `jsconfig.json` hinzugefügt werden, um sie bei der Verwendung von _import_ einzusetzen.
-
-```json
-{
-  "compilerOptions": {
-    "baseUrl": ".",
-    "paths": {
-      "@/components/*": ["components/*"]
-    }
-  }
-}
-```
-
-_Diese Aliase werden automatisch in die Konfiguration von [VSCode](https://code.visualstudio.com/docs/languages/jsconfig) und anderen Editoren übernommen._
-
-## Variablen in \<script> & \<style>
-
-In Astro v0.21 können _serialisierbare_ Server-seitige Variablen innerhalb Client-seitiger `<style>`- oder `<script>`-Tags übergeben werden.
-
-```astro
---
-// tick.astro
-const foregroundColor = "rgb(221 243 228)";
-const backgroundColor = "rgb(24 121 78)";
---
-<style define:vars={{foregroundColor, backgroundColor}}>
-  h-tick {
-    background-color: var(--backgroundColor);
-    border-radius: 50%;
-    color: var(--foregroundColor);
-    height: 15px;
-    width: 15px;
-  }
-</style>
-<h-tick>✓</h-tick>
-```
-
-## Komponenten in Markdown
-
-In Astro v0.21 können Komponenten aus beliebigen Frameworks in Markdown-Dateien verwendet werden.
-
-```markdown
---
-layout: '...'
-setup: |
-  import MeineReactKomponente from '../components/MeineReactKomponente.jsx'
---
-
-# Partial Hydration wenn sichtbar
-
-<MeineReactKomponente client:visible>
-
-# Hallo Welt!
-
-</MeineReactKomponente>
-```
-
-## Komponenten in Titeln(Frontmatter)
-
-Bisher ließen sich Astro-Komponenten innerhalb des Astro-Frontmatter erzeugen, indem dort JSX-Syntax anstelle der Astro-Syntax verwendet wurde. Mit dem neuen Compiler ist das nicht mehr möglich. Wir hoffen, dass wir diese Möglichkeit in einer zukünftigen Version von Astro wieder einführen können - in der wir hierfür jedoch eine andere API an Stelle der JSX-API verwenden werden.
-
-Um auf v0.21 umzustellen, konvertiere bitte alle JSX-Astro-Komponenten (dies sind alle Astro-Komponenten, die innerhalb des Frontmatter einer anderen Komponente erzeugt werden) in eigenständige Komponenten.
-
-## Umgebungsvariablen
-
-In Astro v21.0 können Umgebungsvariablen aus .env-Dateien in deinem Projektverzeichnis geladen werden.
-
-```ini
-.env                # wird in allen Fällen geladen
-.env.local          # wird in allen Fällen geladen, ignoriert von git
-.env.[mode]         # wird nur im spezifizierten Modus geladen
-.env.[mode].local   # wird nur im spezifizierten Modus geladen, ignoriert von git
-```
-
-Aus Sicherheitsgründen sind ausschließlich Variablen mit dem Prefix `PUBLIC_` für deinen Code verfügbar.
-
-```ini
-GEHEIMES_KENNWORT=kennwort123
-PUBLIC_IRGENDWER=dieser
-```
-
-In diesem Beispiel ist `PUBLIC_IRGENDWER` verfügbar als ìmport.meta.env.PUBLIC_IRGENDWER für Server- oder Client-seitigen Code, `GEHEIMES_KENNWORT` hingegen nicht.
-
-> In früheren Versionen wurde diesen Variablen das Prefix `SNOWPACK_PUBLIC` vorangestellt, und sie erforderten darüber hinaus das Plugin `@snowpack/plugin-env`.
-
-## Dateiendungen
-
-In Astro v21.0 muss auf Dateien unter Nennung ihrer tatsächlichen Erweiterung verwiesen werden - exakt so wie sie gespeichert sind.
-
-```tsx
-// Div.tsx
-export default function Div(props) {
-  return <div />;
-}
-```
-
-In diesem Beispiel müsste auf `Div.tsx` mit `Div.tsx` verwiesen werden, nicht mit `Div.jsx`.
-
-```diff
- import Div from './Div.jsx' // Astro v0.20
-+ import Div from './Div.tsx' // Astro v0.21
-```
-
-Diese Änderung betrifft auch Style-Dateien.
-
-```scss
-// Div.scss
-div {
-  all: unset;
-}
-```
-
-```diff
- <link rel="stylesheet" href={Astro.resolve('./Div.css')}>
-+ <link rel="stylesheet" href={Astro.resolve('./Div.scss')}>
-```
-
-## Plugins
-
-In Astro v0.21 können Vite-Plugins innerhalb von `astro.config.mjs` konfiguriert werden.
-
-```js
-import { imagetools } from 'vite-imagetools';
-
-export default {
-  vite: {
-    plugins: [imagetools()],
-  },
-};
-```
-
-Um mehr über Vite-Plugins zu lernen, lies bitte den [Vite Plugin Guide](https://vitejs.dev/guide/using-plugins.html).
-
-## Benutzerdefinierte Renderer
-
-In Astro v0.21 sollten Plugins ab jetzt `viteConfig()` verwenden.
-
-```diff
-// renderer-svelte/index.js
-+ import { svelte } from '@sveltejs/vite-plugin-svelte';
-
-export default {
-  name: '@astrojs/renderer-svelte',
-  client: './client.js',
-  server: './server.js',
-  snowpackPlugin: '@snowpack/plugin-svelte',
-  snowpackPluginOptions: { compilerOptions: { hydratable: true } },
-+  viteConfig() {
-+    return {
-+      optimizeDeps: {
-+        include: ['@astrojs/renderer-svelte/client.js', 'svelte', 'svelte/internal'],
-+        exclude: ['@astrojs/renderer-svelte/server.js'],
-+      },
-+      plugins: [
-+        svelte({
-+          emitCss: true,
-+          compilerOptions: { hydratable: true },
-+        }),
-+      ],
-+    };
-+  },
-}
-```
-
-Um mehr über Vite-Plugins zu lernen, lies bitte den [Vite Plugin Guide](https://vitejs.dev/guide/using-plugins.html).
-
-> In früheren Versionen wurden diese Plugins mittels `snowpackPlugin` oder `snowpackPluginOptions` konfiguriert.
-
-## Änderungen bei der Gestaltung
-
-### Autoprefixer
-
-Autoprefixer wird nicht mehr automatisch eingebunden. Aktiviere Autoprefixer in zwei Schritten:
-
-1. Installiere zunächst die aktuelle Version (`npm i autoprefixer`)
-2. Erzeuge die Datei `postcss.config.cjs` im Hauptverzeichnis deines Projekts mit:
-   ```js
-   module.exports = {
-     plugins: {
-       autoprefixer: {},
-     },
-   };
-   ```
-   Die in Vite enthaltene Post-CSS-Konfiguration wird hierdurch ersetzt.
-
-### Tailwind-CSS
-
-Stelle sicher, dass Post-CSS installiert ist. Dies war optional in vorherigen Versionen, ist aber nun Voraussetzung:
-
-1. Intalliere die aktuelle Version von Post-CSS (`npm i -D postcss`)
-2. Erzeuge die Datei `postcss.config.cjs` im Hauptverzeichnis deines Projekts mit:
-   ```js
-   module.exports = {
-     plugins: {
-       tailwindcss: {},
-     },
-   };
-   ```
-   Für weitere Informationen lies die [Tailwind CSS Documentation](https://tailwindcss.com/docs/installation#add-tailwind-as-a-post-css-plugin)
-
-[vite]: https://vitejs.dev
-[snowpack]: https://www.snowpack.dev
--- a/docs/src/pages/de/quick-start.md
+++ b/docs/src/pages/de/quick-start.md
@ -1,78 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Schnellstart
-description: Die einfachste Weg schnell mit Astro loszulegen.
---
-
-```shell
-# Vorbereitung: Überprüfe, ob Node.js die Version 14.15.0+, oder 16+ ist
-node --version
-
-# Erstelle einen neues Projektverzeichnis und navigiere direkt dorthin
-mkdir mein-astro-projekt && cd $_
-
-# Bereite dich auf den Start vor
-npm init astro
-
-# Installiere benötigte Pakete
-npm install
-
-# Beginne mit dem Entwickeln!
-npm run dev
-```
-
-Export - fertig zum Veröffentlichen:
-
-```shell
-# Wenn du soweit bist, exportiere deine Site nach `dist/`
-npm run build
-```
-
-Um mehr über den Installationsprozess und den ersten Einsatz von Astro zu lernen [lies unsere Installationsanleitung](/de/installation).
-
-Wenn du es bevorzugst anhand eines Beispiels zu lernen, werfe einen Blick auf die [komplette Liste der Beispiele](https://github.com/withastro/astro/tree/main/examples) auf GitHub.  
-Du kannst jedes dieser Beispiele ausprobieren, indem du `npm init astro -- --template "BEISPIEL_NAME"` ausführst.
-
-## Starte dein Projekt
-
-In deinem Projektverzeichnis führe den folgenden Befehl in deinem Terminal aus:
-
-```bash
-npm run dev
-```
-
-Astro wird von nun an deine Anwendung unter [http://localhost:3000](http://localhost:3000) bereitstellen. Wenn du diese URL in deinem Browser öffnest, solltest du Astros "Hello, World" sehen.
-
-Der Server wird nun auf alle Änderungen in deinem `src/`-Verzeichnisch lauschen, sodass du deine Anwendung nicht nach jeder Änderung neu starten musst.
-
-## Kompiliere dein Projekt
-
-In deinem Projektverzeichnis führe den folgenden Befehl in deinem Terminal aus:
-
-```bash
-npm run build
-```
-
-Dies weist Astro an deine Site zu erstellen und direkt zu speichern. Deine Anwendung steht nun im `dist/`-Verzeichnis bereit.
-
-## Veröffentliche dein Projekt
-
-Astro-Sites sind statisch, sodass sie ganz einfach bei deinem bevorzugten Hoster veröffentlicht werden können:
-
- [AWS S3 bucket](https://aws.amazon.com/s3/)
- [Google Firebase](https://firebase.google.com/)
- [Netlify](https://www.netlify.com/)
- [Vercel](https://vercel.com/)
- [Erfahre mehr über das Veröffentlichen von Astro-Builds](/guides/deploy).
-
-## Nächste Schritte
-
-Geschafft! Du kannst jetzt mit dem Entwickeln beginnen!
-
-Wir möchten dich ermutigen, dir etwas Zeit zu nehmen, um mit der Art und Weise vertraut zu werden, wie Astro funktioniert. Am besten befasst du dich weitergehend mit der Dokumentation. Hier ein paar Empfehlungen:
-
-📚 Lerne mehr über die Projektstruktur in Astro in unserem [Artikel zur Projektstruktur](/de/core-concepts/project-structure)
-
-📚 Lerne mehr über die Komponenten-Syntax in Astro in unserem [Artikel zu Astro-Komponenten](/de/core-concepts/astro-components)
-
-📚 Lerne mehr über das dateibasierte Routing in Astro in unserem [Artikel zu Astro-Seiten](/de/core-concepts/astro-pages) und unserem [Artikel über Routing](/de/core-concepts/routing).
--- a/docs/src/pages/de/themes.astro
+++ b/docs/src/pages/de/themes.astro
@ -1,53 +0,0 @@
---
-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';
---
-
-<Layout content={{ title: 'Vorlagen' }} hideRightSidebar>
-	<style>
-		.card-grid {
-			display: grid;
-			grid-column-gap: 15px;
-			grid-row-gap: 15px;
-			grid-auto-flow: dense;
-			grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
-		}
-	</style>
-	<Markdown>
-		## Vorgestellte Vorlagen
-	</Markdown>
-	<div class="card-grid">
-		{themes.featured.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		## Offizielle Vorlagen
-
-		Astro pflegt verschiedene offizielle Vorlagen für Dokumentationssites, Portfolios und mehr.
-	</Markdown>
-	<div class="card-grid">
-		{themes.official.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		## Vorlagen aus der Community
-
-		Sieh dir einige von unserer Community entwickelte Vorlagen an!
-	</Markdown>
-	<div class="card-grid">
-		{themes.community.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		## Vorgestellte Packages
-
-		Unser Package-Ökosystem wächst stetig! Sieh dir die hier vorgestellten Packages unserer Community an. Durchsuche unsere vollständige Sammlung [auf npm.](https://www.npmjs.com/search?q=keywords%3Aastro-component)
-	</Markdown>
-	<div class="card-grid">
-		{components.community.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		> Möchtest du deine eigene Arbeit hier sehen? [Teile sie in Discord!](https://astro.build/chat)
-		> Wir teilen hier regelmäßig unsere Favoriten aus dem #showcase-Channel.
-	</Markdown>
-</Layout>
--- a/docs/src/pages/en/comparing-astro-vs-other-tools.md
+++ b/docs/src/pages/en/comparing-astro-vs-other-tools.md
@ -1,233 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Comparing Astro
-description: Comparing Astro with other static site generators like Gatsby, Next.js, Nuxt, Hugo, Eleventy, and more.
---
-
-We often get asked the question, "How does Astro compare to my favorite site builder, **\_\_\_\_**?" This guide was written to help answer that question for several popular site builders and Astro alternatives.
-
-If you don't see your favorite site builder listed here, [ask us in Discord.](https://astro.build/chat)
-
-## Project Status
-
-A quick note on project maturity: **Astro is still in beta.** Many of the tools listed here are much more mature. Some predate Astro by over 12 years!
-
-A few features are still missing from Astro, and several APIs are not yet finalized. However, the project is considered stable from a bug perspective and several production websites have already been built using Astro. This is an important point to consider when choosing Astro.
-
-## Docusaurus vs. Astro
-
-[Docusaurus](https://docusaurus.io/) is a popular documentation website builder. Docusaurus uses React to generate your website UI while Astro supports React, Vue.js, Svelte, and raw HTML templating.
-
-Docusaurus was designed to build documentation websites and has some built-in, documentation-specific website features that Astro does not. Instead, Astro offers documentation-specific features through an official [`docs`](https://github.com/withastro/astro/tree/main/examples/docs) theme that you can use for your site. This website was built using that template!
-
-### 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](/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.
-
-### Case Study: Building a Documentation Website
-
-[docusaurus.io/docs](https://docusaurus.io/docs) is the official Docusaurus documentation website, built with Docusaurus. The website offers a similar enough design and featureset to compare against the official Astro documentation website. This gives us a **_rough, real-world_** comparison between the two site builders.
-
- **Docusaurus performance score**: 61 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocusaurus.io%2Fdocs)
- **Astro performance score**: 99 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-One big reason behind this performance difference is Astro's smaller JavaScript payload: [docusaurus.io/docs](https://docusaurus.io/docs) loads **238kb** of JavaScript on first page load while [docs.astro.build](https://docs.astro.build) loads **78.7kb** (67% less JavaScript, overall) _after_ first load.
-
-## Elder.js vs. Astro
-
-[Elder.js](https://elderguide.com/tech/elderjs/) is an opinionated static site builder built for Svelte.
-
-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](/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](/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.
-
-Elder.js supports both Static Site Generation (SSG) and Server-Side Rendering (SSR). Today, Astro only supports Static Site Generation (SSG).
-
-## Eleventy vs. Astro
-
-[Eleventy](https://www.11ty.dev/) is a popular static site builder, powered by Node.js.
-
-Eleventy uses several [older HTML templating languages](https://www.11ty.dev/docs/languages/) to render your website: Nunjucks, Liquid, Pug, EJS, and others. Astro lets you create pages using your favorite UI component libraries (React, Preact, Vue, Svelte, and others) or a built-in component syntax which is similar to HTML + JSX. Eleventy does not support using modern UI components for HTML templating.
-
-### Comparing Eleventy vs. Astro Performance
-
-Conceptually, Eleventy is aligned with Astro's "minimal client-side JavaScript" approach to web development. Eleventy and Astro both offer similar, zero-JavaScript-by-default performance baselines.
-
-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](/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
-
-[Gatsby](https://www.gatsbyjs.com/) is a popular website & application framework for React.
-
-Gatsby uses React 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.
-
-Gatsby v4 supports both Static Site Generation (SSG) with incremental rebuilds, Deferred Static Generation (DSG), and Server-Side Rendering (SSR). Today, Astro only supports Static Site Generation (SSG).
-
-Gatsby requires a custom GraphQL API for working with all of your site content. While some developers enjoy this model, a common criticism of Gatsby is that this model becomes too complex and difficult to maintain over time, especially as sites grow. Astro has no GraphQL requirement, and instead provides familiar APIs (like `fetch()` and top-level `await`) for data loading close to where the data is needed.
-
-### 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](/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.
-
-Gatsby has a great plugin ecosystem, which could make Gatsby a better choice for your project depending on your needs. [gatsby-plugin-image](https://www.gatsbyjs.com/plugins/gatsby-plugin-image/) is a popular plugin for image optimizations, which could make Gatsby a better choice for some image-heavy websites.
-
-### Case Study: Building a Documentation Website
-
-[gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) is the official Gatsby documentation website, built with Gatsby. The website offers a similar enough design and feature-set to compare against the official Astro documentation website. This gives us a **_rough, real-world_** comparison between the two site builders for this common use-case.
-
- **Gatsby performance score**: 64 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwww.gatsbyjs.com%2Fdocs%2Fquick-start%2F)
- **Astro performance score**: 99 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-One big reason behind this performance difference is Astro's smaller JavaScript payload: [gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) loads **417kb** of JavaScript on first page load while [docs.astro.build](https://docs.astro.build) loads **78.7kb** (81% less JavaScript, overall) _after_ first load.
-
-## Hugo vs. Astro
-
-[Hugo](https://gohugo.io/) is a popular static site generator, powered by Go.
-
-Hugo uses a custom [templating language](https://gohugo.io/templates/introduction/) to render your website. Astro lets you create pages using your favorite UI component libraries (React, Preact, Vue, Svelte, and others) or a built-in component syntax which is similar to HTML + JSX. Hugo does not support using modern UI components for HTML templating.
-
-### Comparing Hugo vs. Astro Performance
-
-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](/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
-
-[Jekyll](https://jekyllrb.com/) is a popular static site generator, powered by Ruby.
-
-Jekyll uses an older [templating language](https://jekyllrb.com/docs/liquid/) to render your website called Liquid. Astro lets you create pages using your favorite UI component libraries (React, Preact, Vue, Svelte, and others) or a built-in component syntax which is similar to HTML + JSX. Jekyll does not support using modern UI components for HTML templating.
-
-### Comparing Jekyll vs. Astro Performance
-
-Conceptually, Jekyll is aligned with Astro's "minimal client-side JavaScript" approach to web development. Jekyll and Astro both offer similar, zero-JavaScript-by-default performance baselines.
-
-Jekyll achieves this by pushing you to avoid JavaScript entirely. Jekyll sites are often written with little to no JavaScript at all, and instead promote server-side HTML rendering. This becomes an issue when you do need client-side JavaScript. It is up to you to create your own build pipeline for Jekyll. This can be time-consuming and forces you to set up bundling, minification, and other optimizations yourself.
-
-By contrast, Astro automatically builds your client-side JavaScript for you. Astro only sends the bare minimum amount of JavaScript to the browser, minified, bundled and optimized for production. While it is possible to achieve this yourself in Jekyll, with Astro this is built in by default.
-
-## SvelteKit vs. Astro
-
-[SvelteKit](https://kit.svelte.dev/) is a popular website & application framework for Svelte.
-
-SvelteKit 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.
-
-Both SvelteKit and Astro are frameworks for building websites. SvelteKit does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites).
-
-SvelteKit supports both Static Site Generation (SSG) and Server-Side Rendering (SSR). Today, Astro only supports Static Site Generation (SSG).
-
-### 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](/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.
-
-### Case Study: Building a Documentation Website
-
-[kit.svelte.dev](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate) is the official SvelteKit documentation website, built with SvelteKit. The website offers a similar enough design and featureset to compare against the official Astro documentation website. This gives us a **_rough, real-world_** comparison between the two site builders for this common use-case.
-
-One notable difference between the two sites being tested: SvelteKit's documentation is served as a single page while Astro's is broken up into multiple pages. This larger content payload should have a slight negative impact on performance that is not related to the tool itself.
-
- **SvelteKit performance score**: 92 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fkit.svelte.dev%2Fdocs)
- **Astro performance score**: 99 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-SvelteKit performed comparably to Astro in this test.
-
-## Next.js vs. Astro
-
-[Next.js](https://nextjs.org/) is a popular website & application framework for React.
-
-Next.js uses React 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.
-
-Both Next.js and Astro are frameworks for building websites. Next.js does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites).
-
-Next.js supports both Static Site Generation (SSG) and Server-Side Rendering (SSR). Today, Astro only supports Static Site Generation (SSG).
-
-### 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](/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.
-
-Next.js has great built-in image optimizations, which could make Next.js a better choice for some image-heavy websites.
-
-### Case Study: Building a Documentation Website
-
-[nextjs.org/docs](https://nextjs.org/docs/getting-started) is the official Next.js documentation website, built with Next.js. The website offers a similar enough design and featureset to compare against the official Astro documentation website. This gives us a **_rough, real-world_** comparison between the two site builders for this common use-case.
-
- **Next.js performance score**: 59 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnextjs.org%2Fdocs%2Fgetting-started)
- **Astro performance score**: 99 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-One big reason behind this performance difference is Astro's smaller JavaScript payload: [nextjs.org/docs](https://nextjs.org/docs/getting-started) loads **463kb** of JavaScript on first page load while [docs.astro.build](https://docs.astro.build) loads **78.7kb** (83% less JavaScript, overall) _after_ first load.
-
-## Nuxt vs. Astro
-
-[Nuxt](https://nuxtjs.org/) is a popular website & application framework for Vue. It is similar to Next.js.
-
-Nuxt uses Vue 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.
-
-Both Nuxt and Astro are frameworks for building websites. Nuxt does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites).
-
-Nuxt supports both Static Site Generation (SSG) and Server-Side Rendering (SSR). Today, Astro only supports Static Site Generation (SSG).
-
-### 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](/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.
-
-Nuxt has great built-in image optimizations, which could make Nuxt a better choice for some image-heavy websites.
-
-### Case Study: Building a Documentation Website
-
-[nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) is the official Nuxt documentation website, built with Nuxt. The website offers a similar enough design and featureset to compare against the official Astro documentation website. This gives us a **_rough, real-world_** comparison between the two site builders for this common use-case.
-
- **Nuxt performance score**: 48 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnuxtjs.org%2Fdocs%2F2.x%2Fget-started%2Finstallation)
- **Astro performance score**: 99 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-One big reason behind this performance difference is Astro's smaller JavaScript payload: [nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) loads **469kb** of JavaScript on first page load while [docs.astro.build](https://docs.astro.build) loads **78.7kb** (83% less JavaScript), _after_ first load.
-
-## VuePress vs. Astro
-
-[VuePress](https://vuepress.vuejs.org/guide/) is a popular documentation website builder from the creators of Vue.js. VuePress uses Vue.js to generate your website UI while Astro supports React, Vue.js, Svelte, and raw HTML templating.
-
-VuePress was designed for documentation websites and has some built-in, documentation-specific website features that Astro does not support out of the box. Instead, Astro offers documentation-specific features through an official [`docs`](https://github.com/withastro/astro/tree/main/examples/docs) theme that you can use for your site. This website was built using that template!
-
-Evan You (creator of Vue.js) is currently working on a new version of Vuepress called [VitePress.](https://vitepress.vuejs.org/). If you want a modern alternative to VuePress, [check out Evan's post](https://github.com/withastro/astro/issues/1159#issue-974035962) on why VitePress may be a better option.
-
-### 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](/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.
-
-### Case Study: Building a Documentation Website
-
-[vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) is the official VuePress documentation website, built with VuePress. The website offers a similar enough design and featureset to compare against the official Astro documentation website. This gives us a **_rough, real-world_** comparison between the two site builders for this common use-case.
-
- **Vuepress performance score**: 63 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fvuepress.vuejs.org%2Fguide%2F)
- **Astro performance score**: 99 out of 100 [(full audit)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-One big reason behind this performance difference is Astro's smaller JavaScript payload: [vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) loads **166kb** of JavaScript on first page load while [docs.astro.build](https://docs.astro.build) loads **78.7kb** (53% less JavaScript, overall) _after_ first load.
-
-## Zola vs. Astro
-
-[Zola](https://www.getzola.org/) is a popular and fast static site generator, powered by Rust.
-
-Zola uses [Tera](https://tera.netlify.app/) to render your website. Astro lets you create pages using your favorite UI component libraries (React, Preact, Vue, Svelte, and others) or a built-in component syntax which is similar to HTML + JSX. Zola does not support using modern UI components for HTML templating.
-
-### Comparing Zola vs. Astro Performance
-
-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](/en/core-concepts/component-hydration). While it is possible to achieve this yourself in Zola, Astro offers it built in by default.
--- a/docs/src/pages/en/core-concepts/astro-components.md
+++ b/docs/src/pages/en/core-concepts/astro-components.md
@ -1,382 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Astro Components
-description: An intro to the .astro component syntax.
---
-
-**Astro Components** (files ending with `.astro`) are the foundation of server-side templating in Astro. Think of the Astro component syntax as HTML enhanced with JavaScript.
-
-Learning a new syntax can feel intimidating, so we carefully designed the Astro component syntax to feel as familiar to web developers as possible. It borrows heavily from patterns you likely already know: components, frontmatter, props, and JSX expressions. We're confident that this guide will have you writing Astro components in no time, especially if you are already familiar with HTML & JavaScript.
-
-## Syntax Overview
-
-A single `.astro` file represents a single Astro component in your project. This pattern is known as a **Single-File Component (SFC)**. Both Svelte (`.svelte`) and Vue (`.vue`) also follow this pattern.
-
-Below is a walk-through of the different pieces and features of the Astro component syntax. You can read it start-to-finish, or jump between sections.
-
-### HTML Template
-
-Astro component syntax is a superset of HTML. **If you know HTML, you already know enough to write your first Astro component.**
-
-For example, this three-line file is a valid Astro component:
-
-```html
-<!-- Example1.astro - Static HTML is a valid Astro component! -->
-<div class="example-1">
-  <h1>Hello world!</h1>
-</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](/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.
-
-### CSS Styles
-
-CSS rules inside of a `<style>` tag are automatically scoped to that component. That means that you can reuse class names across multiple components, without worrying about conflicts. Styles are automatically extracted and optimized in the final build so that you don't need to worry about style loading.
-
-For best results, you should only have one `<style>` tag per-Astro component. This isn't necessarily a limitation, but it will often result in better-optimized CSS in your final build. When you're working with pages, the `<style>` tag can go nested inside of your page `<head>`. For standalone components, the `<style>` tag can go at the top-level of your template.
-
-```html
-<!-- Astro Component CSS example -->
-<style>
-  .circle {
-    background-color: red;
-    border-radius: 999px;
-    height: 50px;
-    width: 50px;
-  }
-</style>
-<div class="circle"></div>
-```
-
-```html
-<!-- Astro Page CSS example -->
-<html>
-  <head>
-    <style>
-      ...;
-    </style>
-  </head>
-  <body>
-    ...
-  </body>
-</html>
-```
-
-Using `<style global>` will skip automatic scoping for every CSS rule in the `<style>` block. This escape hatch should be avoided if possible but can be useful if, for example, you need to modify styling for HTML elements added by an external library.
-
-Sass (an alternative to CSS) is also available via `<style lang="scss">`.
-
-📚 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](/en/core-concepts/component-hydration) like React, Svelte, Vue, etc.
-
-```astro
---
-// Anything inside the `---` code fence is your component script.
-// This JavaScript code runs at build-time.
-// See below to learn more about what you can do.
-// Tip: TypeScript is also supported out-of-the-box!
-const thisWorks: number = 42;
-console.log('This runs at build-time, is visible in the CLI output', thisWorks);
---
-<div class="example-1">
-  <h1>Hello world!</h1>
-</div>
-```
-
-### Component Imports
-
-An Astro component can reuse other Astro components inside of its HTML template. This becomes the foundation of our component system: build new components and then reuse them across your project.
-
-To use an Astro component in your template, you first need to import it in the frontmatter component script. An Astro component is always the file's default import.
-
-Once imported, you can use it like any other HTML element in your template. Note that an Astro component **MUST** begin with an uppercase letter. Astro will use this to distinguish between native HTML elements (`form`, `input`, etc.) and your custom Astro components.
-
-```astro
---
-// Import your components in your component script...
-import SomeComponent from './SomeComponent.astro';
---
-<!-- ... then use them in your HTML! -->
-<div>
-  <SomeComponent />
-</div>
-```
-
-📚 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
-
-Instead of inventing our own custom syntax for dynamic templating, we give you direct access to JavaScript values inside of your HTML, using something that feels just like [JSX](https://reactjs.org/docs/introducing-jsx.html).
-
-Astro components can define local variables inside of the Frontmatter script. Any script variables are then automatically available in the HTML template below.
-
-#### Dynamic Values
-
-```astro
---
-const name = "Your name here";
---
-<div>
-  <h1>Hello {name}!</h1>
-</div>
-```
-
-#### Dynamic Attributes
-
-```astro
---
-const name = "Your name here";
---
-<div>
-  <div data-name={name}>Attribute expressions supported</div>
-  <div data-hint={`Use JS template strings to mix ${"variables"}.`}>So good!</div>
-</div>
-```
-
-#### Dynamic HTML
-
-```astro
---
-const items = ["Dog", "Cat", "Platipus"];
---
-<ul>
-  {items.map((item) => (
-    <li>{item}</li>
-  ))}
-</ul>
-```
-
-### Component Props
-
-An Astro component can define and accept props. Props are available on the `Astro.props` global in your frontmatter script.
-
-```astro
---
-// Example: <SomeComponent greeting="(Optional) Hello" name="Required Name" />
-const { greeting = 'Hello', name } = Astro.props;
---
-<div>
-    <h1>{greeting}, {name}!</h1>
-</div>
-```
-
-You can define your props with TypeScript by exporting a `Props` type interface. Astro will automatically pick up any exported `Props` interface and give type warnings/errors for your project.
-
-Make sure to keep all `import` and `export` statements at the top of the component, before any other JavaScript or TypeScript logic!
-
-```astro
---
-// include any `import` and `export` statements first
-// Example: <SomeComponent />  (WARNING: "name" prop is required)
-export interface Props {
-  name: string;
-  greeting?: string;
-}
-
-// with `import`s and `export`s out of the way, include the rest of the component logic here
-const { greeting = 'Hello', name } = Astro.props;
---
-<div>
-    <h1>{greeting}, {name}!</h1>
-</div>
-```
-
-You can then pass the component props like this:
-
-```astro
---
-// SomeOtherComponent.astro
-import SomeComponent from "./SomeComponent.astro";
-let firstName = "world!";
---
-<SomeComponent name={firstName}/>
-```
-
-### Slots
-
-`.astro` files use the [`<slot>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/slot) tag to enable component composition. Coming from React or Preact, this is the same concept as `children`. You can think of the `<slot>` element as a placeholder for markup which will be passed in from outside of the component.
-
-```astro
-<!-- Example: MyComponent.astro -->
-<div id="my-component">
-  <slot /> <!-- children will go here -->
-</div>
-
-<!-- Usage -->
-<MyComponent>
-  <h1>Hello world!</h1>
-</MyComponent>
-```
-
-Note that if the `<slot>` tag is not used in the HTML template, any children passed to the component will not be rendered.
-
-Slots become even more powerful when using **named slots**. Rather than a single `<slot>` element which renders _all_ children, named slots allow you to specify multiple places where children should be placed.
-
-> **Note:** The `slot` attribute is not restricted to plain HTML, components can use `slot` as well!
-
-```astro
-<!-- Example: MyComponent.astro -->
-<div id="my-component">
-  <header>
-    <!-- children with the `slot="header"` attribute will go here -->
-    <slot name="header" />
-  </header>
-  <main>
-    <!-- children without a `slot` (or with the `slot="default"`) attribute will go here -->
-    <slot />
-  </main>
-  <footer>
-    <!-- children with the `slot="footer"` attribute will go here -->
-    <slot name="footer" />
-  </footer>
-</div>
-
-<!-- Usage -->
-<MyComponent>
-  <h1 slot="header">Hello world!</h1>
-  <p>Lorem ipsum ...</p>
-  <FooterComponent slot="footer" />
-</MyComponent>
-```
-
-Slots can also render **fallback content**. When there are no matching children passed to a `<slot>`, a `<slot>` element will render its own placeholder children.
-
-```astro
-<!-- MyComponent.astro -->
-<div id="my-component">
-  <slot>
-    <h1>I will render when this slot does not have any children!</h1>
-  </slot>
-</div>
-
-<!-- Usage -->
-<MyComponent />
-```
-
-### Fragments & Multiple Elements
-
-An Astro component template can render as many top-level elements as you'd like. Unlike other UI component frameworks, you don't need to wrap everything in a single `<div>` if you'd prefer not to.
-
-```html
-<!-- An Astro component can contain multiple top-level HTML elements: -->
-<div id="a" />
-<div id="b" />
-<div id="c" />
-```
-
-When working inside a JSX expression, however, you must wrap multiple elements inside of a **Fragment**. Fragments let you render a set of elements without adding extra nodes to the DOM. This is required in JSX expressions because of a limitation of JavaScript: You can never `return` more than one thing in a JavaScript function or expression. Using a Fragment solves this problem.
-
-A Fragment must open with `<>` and close with `</>`. Don't worry if you forget this, Astro's compiler will warn you that you need to add one.
-
-> **Note:** Astro also supports opening a fragment with `<Fragment>` and closing it with `</Fragment>` if you prefer to use that syntax.
-
-```astro
---
-const items = ["Dog", "Cat", "Platipus"];
---
-<ul>
-  {items.map((item) => (
-    <>
-      <li>Red {item}</li>
-      <li>Blue {item}</li>
-      <li>Green {item}</li>
-    </>
-  ))}
-</ul>
-```
-
-### Hoisted scripts
-
-By default Astro does not make any assumptions on how you want scripts to be served, so if you add a `<script>` tag in a page or a component it will be left alone.
-
-However if you'd like all of your scripts to be hoisted out of components and moved to the top of the page, and then later bundled together in production, you can achieve this with hoisted scripts.
-
-A **hoisted script** looks like this:
-
-```astro
-<script hoist>
-  // An inline script
-</script>
-```
-
-Or it can link to an external JavaScript file:
-
-```astro
-<script src={Astro.resolve('./my-component.js')} hoist></script>
-```
-
-A hoisted script can be within a page or a component, and no matter how many times the component is used, the script will only be added once:
-
-```astro
---
-import TwitterTimeline from '../components/TwitterTimeline.astro';
---
-
-<-- The script will only be injected into the head once. -->
-<TwitterTimeline />
-<TwitterTimeline />
-<TwitterTimeline />
-```
-
-## Comparing `.astro` versus `.jsx`
-
-`.astro` files can end up looking very similar to `.jsx` files, but there are a few key differences. Here's a comparison between the two formats.
-
-| Feature                      | Astro                                                      | JSX                                                |
-| ---------------------------- | ---------------------------------------------------------- | -------------------------------------------------- |
-| File extension               | `.astro`                                                   | `.jsx` or `.tsx`                                   |
-| User-Defined Components      | `<Capitalized>`                                            | `<Capitalized>`                                    |
-| Expression Syntax            | `{}`                                                       | `{}`                                               |
-| Spread Attributes            | `{...props}`                                               | `{...props}`                                       |
-| Boolean Attributes           | `autocomplete` === `autocomplete={true}`                   | `autocomplete` === `autocomplete={true}`           |
-| Inline Functions             | `{items.map(item => <li>{item}</li>)}`                     | `{items.map(item => <li>{item}</li>)}`             |
-| IDE Support                  | WIP - [VS Code][code-ext]                                  | Phenomenal                                         |
-| Requires JS import           | No                                                         | Yes, `jsxPragma` (`React` or `h`) must be in scope |
-| Fragments                    | Automatic top-level, `<Fragment>` or `<>` inside functions | Wrap with `<Fragment>` or `<>`                     |
-| Multiple frameworks per-file | Yes                                                        | No                                                 |
-| Modifying `<head>`           | Just use `<head>`                                          | Per-framework (`<Head>`, `<svelte:head>`, etc)     |
-| Comment Style                | `<!-- HTML -->`                                            | `{/_ JavaScript _/}                                |
-| Special Characters           | `&nbsp;`                                                   | `&nbsp;`                                           |
-| Attributes                   | `dash-case`                                                | `camelCase`                                        |
-
-## URL resolution
-
-It's important to note that Astro **won't** transform HTML references for you. For example, consider an `<img>` tag with a relative `src` attribute inside `src/pages/about.astro`:
-
-```html
-<!-- ❌ Incorrect: will try and load `/about/thumbnail.png` -->
-<img src="./thumbnail.png" />
-```
-
-Since `src/pages/about.astro` will build to `/about/index.html`, you may not have expected that image to live at `/about/thumbnail.png`. So to fix this, choose either of two options:
-
-#### Option 1: Absolute URLs
-
-```html
-<!-- ✅ Correct: references public/thumbnail.png -->
-<img src="/thumbnail.png" />
-```
-
-The recommended approach is to place files within `public/*`. This references a file at `public/thumbnail.png`, which will resolve to `/thumbnail.png` at the final build (since `public/` ends up at `/`).
-
-#### Option 2: Asset import references
-
-```astro
---
-//  ✅ Correct: references src/thumbnail.png
-import thumbnailSrc from './thumbnail.png';
---
-
-<img src={thumbnailSrc} />
-```
-
-If you'd prefer to organize assets alongside Astro components, you may import the file in JavaScript inside the component script. This works as intended but this makes `thumbnail.png` harder to reference in other parts of your app, as its final URL isn't easily-predictable (unlike assets in `public/*`, where the final URL is guaranteed to never change).
-
-[code-ext]: https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode
--- a/docs/src/pages/en/core-concepts/astro-pages.md
+++ b/docs/src/pages/en/core-concepts/astro-pages.md
@ -1,66 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Pages
-description: An intro to Astro pages, components that function as full pages.
---
-
-**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](/en/guides/markdown-content) for more information on writing pages with Markdown.
-
-## File-based Routing
-
-Astro uses Pages to do something called **file-based routing.** Every file in your `src/pages` directory becomes a page on your site, using the file name to decide the final route.
-
-Astro Components (`.astro`) and Markdown Files (`.md`) are the only supported formats for pages. Other page types (like a `.jsx` React component) are not supported, but you can use anything as a UI component inside of an `.astro` page to achieve a similar result.
-
-```
-src/pages/index.astro       -> mysite.com/
-src/pages/about.astro       -> mysite.com/about
-src/pages/about/index.astro -> mysite.com/about
-src/pages/about/me.astro    -> mysite.com/about/me
-src/pages/posts/1.md        -> mysite.com/posts/1
-```
-
-## Page Templating
-
-All Astro components are responsible for returning HTML. Astro Pages return HTML as well, but have the unique responsibility of returning a full `<html>...</html>` page response, including `<head>` ([MDN<span class="sr-only">- head</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head)) and `<body>` ([MDN<span class="sr-only">- body</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body)).
-
-`<!doctype html>` is optional, and will be added automatically.
-
-```astro
---
-// Example: HTML page skeleton
---
-<!doctype html>
-<html>
-  <head>
-    <title>Document title</title>
-  </head>
-  <body>
-    <h1>Hello, world!</h1>
-  </body>
-</html>
-```
-
-## Data Loading
-
-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](/en/guides/data-fetching) on data-fetching to learn more.
-
-```astro
---
-// Example: Astro component scripts run at build time
-const response = await fetch('http://example.com/movies.json');
-const data = await response.json();
-console.log(data);
---
-<!-- Output the result to the page -->
-<div>{JSON.stringify(data)}</div>
-```
-
-## 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](/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`.
--- a/docs/src/pages/en/core-concepts/component-hydration.md
+++ b/docs/src/pages/en/core-concepts/component-hydration.md
@ -1,116 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Partial Hydration in Astro
-description: Learn how partial hydration works using the "Islands Architecture" in Astro.
---
-
-**Astro generates every website with zero client-side JavaScript, by default.** Use any frontend UI component that you'd like (React, Svelte, Vue, etc.) and Astro will automatically render it to HTML at build-time and strip away all JavaScript. This keeps every site fast by default.
-
-But sometimes, client-side JavaScript is required. This guide shows how interactive components work in Astro using a technique called partial hydration.
-
-```astro
---
-// Example: Importing and then using a React component.
-// By default, Astro renders this to HTML and CSS during
-// your build, with no client-side JavaScript.
-// (Need client-side JavaScript? Read on...)
-import MyReactComponent from '../components/MyReactComponent.jsx';
---
-<!-- 100% HTML, Zero JavaScript! -->
-<MyReactComponent />
-```
-
-## Concept: Partial Hydration
-
-There are plenty of cases where you need an interactive UI component to run in the browser:
-
- An image carousel
- An auto-complete search bar
- A mobile sidebar open/close button
- A "Buy Now" button
-
-In Astro, it's up to you as the developer to explicitly "opt-in" any components on the page that need to run in the browser. Astro can then use this info to know exactly what JavaScript is needed, and only hydrate exactly what's needed on the page. This technique is known as partial hydration.
-
-**Partial hydration** -- the act of only hydrating the individual components that require JavaScript and leaving the rest of your site as static HTML -- may sound relatively straightforward. It should! Websites have been built this way for decades. It was only recently that Single-Page Applications (SPAs) introduced the idea that your entire website is written in JavaScript and compiled/rendered by every user in the browser.
-
-_Note: Partial hydration is sometimes called "progressive enhancement" or "progressive hydration." While there are slight nuances between the terms, for our purposes you can think of these all as synonyms of the same concept._
-
-**Partial hydration is the secret to Astro's fast-by-default performance story.** Next.js, Gatsby, and other JavaScript frameworks cannot support partial hydration because they imagine your entire website/page as a single JavaScript application.
-
-## Concept: Island Architecture
-
-**Island architecture** is the idea of using partial hydration to build entire websites. Island architecture is an alternative to the popular idea of building your website into a client-side JavaScript bundle that must be shipped to the user.
-
-> In an "islands" model, server rendering is not a bolt-on optimization aimed at improving SEO or UX. Instead, it is a fundamental part of how pages are delivered to the browser. The HTML returned in response to navigation contains a meaningful and immediately renderable representation of the content the user requested.
-> <br/> -- [Jason Miller](https://jasonformat.com/islands-architecture/)
-
-Besides the obvious performance benefits of sending less JavaScript down to the browser, there are two key benefits to island architecture:
-
- **Components load individually.** A lightweight component (like a sidebar toggle) will load and render quickly without being blocked by the heavier components on the page.
- **Components render in isolation.** Each part of the page is an isolated unit, and a performance issue in one unit won't directly affect the others.
-
-![diagram](https://res.cloudinary.com/wedding-website/image/upload/v1596766231/islands-architecture-1.png)
-
-## Hydrate Interactive Components
-
-Astro renders every component on the server **at build time**, unless [client:only](#mycomponent-clientonly-) is used. To hydrate components on the client **at runtime**, you may use any of the following `client:*` directives. A directive is a component attribute (always with a `:`) which tells Astro how your component should be rendered.
-
-```astro
---
-// Example: hydrating a React component in the browser.
-import MyReactComponent from '../components/MyReactComponent.jsx';
---
-<!-- "client:visible" means the component won't load any client-side
-     JavaScript for the component until it becomes visible in the
-     user's browser. -->
-<MyReactComponent client:visible />
-```
-
-Note that the renderer JS (e.g. React) and the component's CSS are downloaded with the page. The `client:*` directives only dictate when the component JS is imported and when the component is hydrated.
-
-### `<MyComponent client:load />`
-
-Start importing the component JS at page load. Hydrate the component when import completes.
-
-### `<MyComponent client:idle />`
-
-Start importing the component JS as soon as main thread is free (uses [requestIdleCallback()][mdn-ric]). Hydrate the component when import completes.
-
-### `<MyComponent client:visible />`
-
-Start importing the component JS as soon as the element enters the viewport (uses [IntersectionObserver][mdn-io]). Hydrate the component when import completes. Useful for content lower down on the page.
-
-### `<MyComponent client:media={QUERY} />`
-
-Start importing the component JS as soon as the browser matches the given media query (uses [matchMedia][mdn-mm]). Hydrate the component when import completes. Useful for sidebar toggles, or other elements that should only display on mobile or desktop devices.
-
-### `<MyComponent client:only />`
-
-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](/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?
-
-[Astro components](/en/core-concepts/astro-components) (`.astro` files) are HTML-only templating components with no client-side runtime. If you try to hydrate an Astro component with a `client:` modifier, you will get an error.
-
-To make your Astro component interactive, you will need to convert it to the frontend framework of your choice: React, Svelte, Vue, etc. If you have no preference, we recommend React or Preact as they are most similar to Astro's syntax.
-
-Alternatively, you could add a `<script>` tag to your Astro component HTML template and send JavaScript to the browser that way. While this is fine for the simple stuff, we recommend a frontend framework for more complex interactive components.
-
-```astro
---
-// Example: Using Astro with script tags
---
-<h1>Not clicked</h1>
-<button>Click to change heading</button>
-<script>
-document.querySelector("button").addEventListener("click",() => {
-    document.querySelector("h1").innerText = "clicked"
-})
-</script>
-```
-
-[mdn-io]: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
-[mdn-ric]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
-[mdn-mm]: https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia
--- a/docs/src/pages/en/core-concepts/layouts.md
+++ b/docs/src/pages/en/core-concepts/layouts.md
@ -1,155 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-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](/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.
-
-## Usage
-
-Astro layouts support props, slots, and all of the other features of Astro components. Layouts are just normal components, after all!
-
-Unlike other components, layouts will often contain the full page `<html>`, `<head>` and `<body>` (often referred to as the **page shell**).
-
-It's a common pattern to put all of your layout components in a single `src/layouts` directory.
-
-## Example
-
-```astro
---
-// src/layouts/BaseLayout.astro
-const {title} = Astro.props;
---
-<html>
-  <head>
-    <title>Example Layout: {title}</title>
-  </head>
-  <body>
-    <!-- Adds a navigation bar to every page. -->
-    <nav>
-      <a href="#">Home</a>
-      <a href="#">Posts</a>
-      <a href="#">Contact</a>
-    </nav>
-    <!-- slot: your page content will be injected here. -->
-    <slot />
-  </body>
-</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.](/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.
-
-```astro
---
-// src/pages/index.astro
-import BaseLayout from '../layouts/BaseLayout.astro'
---
-<BaseLayout title="Homepage">
-  <h1>Hello, world!</h1>
-  <p>This is my page content. It will be nested inside a layout.</p>
-</BaseLayout>
-```
-
-## Nesting Layouts
-
-You can nest layouts when you want to create more specific page types without copy-pasting. It is common in Astro to have one generic `BaseLayout` and then many more specific layouts (`PostLayout`, `ProductLayout`, etc.) that reuse and build on top of it.
-
-```astro
---
-// src/layouts/PostLayout.astro
-import BaseLayout from '../layouts/BaseLayout.astro'
-const {title, author} = Astro.props;
---
-  <!-- This layout reuses BaseLayout (see example above): -->
-<BaseLayout title={title}>
-  <!-- Adds new post-specific content to every page. -->
-  <div>Post author: {author}</div>
-  <!-- slot: your page content will be injected here. -->
-  <slot />
-</BaseLayout>
-```
-
-## Composing Layouts
-
-Sometimes, you need more granular control over your page. For instance, you may want to add SEO or social `meta` tags on some pages, but not others. You could implement this with a prop on your layout (`<BaseLayout addMeta={true} ...`) but at some point it may be easier to compose your layouts without nesting.
-
-Instead of defining your entire `<html>` page as one big layout, you can define the `head` and `body` contents as smaller, separate components. This lets you compose multiple layouts together in unique ways on every page.
-
-```astro
---
-// src/layouts/BaseHead.astro
-const {title, description} = Astro.props;
---
-<meta charset="UTF-8">
-<title>{title}</title>
-<meta name="description" content={description}>
-<link rel="preconnect" href="https://fonts.gstatic.com">
-<link href="https://fonts.googleapis.com/css2?family=Spectral:ital,wght@0,400;0,700;1,400;1,700&display=swap" rel="stylesheet">
-```
-
-Notice how this layout doesn't include your page shell, and only includes some generic elements that should go in your `<head>`. This lets you combine multiple layout components together with more control over the overall page structure.
-
-```astro
---
-// src/pages/index.astro
-import BaseHead from '../layouts/BaseHead.astro';
-import OpenGraphMeta from '../layouts/OpenGraphMeta.astro';
---
-<html>
-  <head>
-    <!-- Now, you have complete control over the head, per-page. -->
-    <BaseHead title="Page Title" description="Page Description" />
-    <OpenGraphMeta />
-    <!-- You can even add custom, one-off elements as needed. -->
-    <link rel="alternate" type="application/rss+xml" href="/feed/posts.xml">
-  </head>
-  <body>
-    <!-- ... -->
-  </body>
-</html>
-```
-
-The one downside to this approach is that you'll need to define the `<html>`, `<head>`, and `<body>` elements on every page yourself. This is needed to construct the page because the layout components no longer contain the full page shell.
-
-## Markdown Layouts
-
-Layouts are essential for Markdown files. Markdown files can declare a layout in the file frontmatter. Each Markdown file will be rendered to HTML and then injected into the layout's `<slot />` location.
-
-```markdown
---
-title: Blog Post
-layout: ../layouts/PostLayout.astro
---
-
-This blog post will be **rendered** inside of the `<PostLayout />` layout.
-```
-
-Markdown pages always pass a `content` prop to their layout, which is useful to grab information about the page, title, metadata, table of contents headers, and more.
-
-```astro
---
-// src/layouts/PostLayout.astro
-const { content } = Astro.props;
---
-<html>
-  <head>
-    <title>{content.title}</title>
-  </head>
-  <body>
-    <h1>{content.title}</h1>
-    <h2>{content.description}</h2>
-    <img src={content.image} alt="">
-    <article>
-      <!-- slot: Markdown content goes here! -->
-      <slot />
-    </article>
-  </body>
-</html>
-```
-
-📚 Learn more about Astro's markdown support in our [Markdown guide](/en/guides/markdown-content).
--- a/docs/src/pages/en/core-concepts/project-structure.md
+++ b/docs/src/pages/en/core-concepts/project-structure.md
@ -1,58 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Project Structure
-description: Learn how to structure a project with Astro.
---
-
-Astro includes an opinionated folder layout for your project. Every Astro project must include these directories and files:
-
- `src/*` - Your project source code (components, pages, etc.)
- `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](/en/quick-start) for a walkthrough of how to set up your project automatically (with `npm init astro`) or manually.
-
-## Project Structure
-
-```
-├── src/
-│   ├── components/
-│   ├── layouts/
-│   └── pages/
-│       └── index.astro
-├── public/
-└── package.json
-```
-
-### `src/`
-
-The src folder is where most of your project source code lives. This includes:
-
- [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](/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](/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](/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/`
-
-For most users, the majority of your files will live inside of the `src/` directory so that Astro can properly handle and optimize them in your final build. By contrast, the `public/` directory is the place for any files to live outside of the Astro build process.
-
-If you put a file into the public folder, it will not be processed by Astro. Instead it will be copied into the build folder untouched. This can be useful for assets like images and fonts, or when you need to include a specific file like `robots.txt` or `manifest.webmanifest`.
--- a/docs/src/pages/en/core-concepts/routing.md
+++ b/docs/src/pages/en/core-concepts/routing.md
@ -1,102 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Routing
-description: An intro to routing with Astro.
---
-
-Astro uses **file-based routing** to generate your build URLs based on the file layout of your project `src/pages` directory. When a file is added to the `src/pages` directory of your project, it is automatically available as a route based on its filename.
-
-## Static routes
-
-Astro Components (`.astro`) and Markdown Files (`.md`) in the `src/pages` directory become pages on your website. Each page's route is decided based on its filename and path within the `src/pages` directory. This means that there is no separate "routing config" to maintain in an Astro project.
-
-```bash
-# Example: Static routes
-src/pages/index.astro        -> mysite.com/
-src/pages/about.astro        -> mysite.com/about
-src/pages/about/index.astro  -> mysite.com/about
-src/pages/about/me.astro     -> mysite.com/about/me
-src/pages/posts/1.md         -> mysite.com/posts/1
-```
-
-## Dynamic routes
-
-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](/en/reference/api-reference#getstaticpaths).
-
-### Named parameters
-
-Dynamic parameters are encoded into the filename using `[bracket]` notation:
-
- `pages/blog/[slug].astro` → `/blog/:slug` (`/blog/hello-world`, `/blog/post-2`, etc.)
- `pages/[username]/settings.astro` → (`/fred/settings`, `/drew/settings`, etc.)
- `pages/[lang]-[version]/info.astro` → (`/en-v1/info`, `/fr-v2/info`, etc.)
-
-#### Example: Named parameters
-
-Consider the following page `pages/post/[pid].astro`:
-
-```astro
---
-// Example: src/pages/post/[pid].astro
-const {pid} = Astro.request.params;
---
-<p>Post: {pid}</p>
-```
-
-Any route like `/post/1`, `/post/abc`, etc. will be matched by `pages/post/[pid].astro`. The matched path parameter will be passed to the page component at `Astro.request.params`.
-
-For example, the route `/post/abc` will have the following `Astro.request.params` object available:
-
-```json
-{ "pid": "abc" }
-```
-
-Multiple dynamic route segments can be combined to work the same way. The page `pages/post/[pid]/[comment].astro` will match the route `/post/abc/a-comment` and its `query` object will be:
-
-```json
-{ "pid": "abc", "comment": "a-comment" }
-```
-
-### Rest parameters
-
-If you need more flexibility in your URL routing, you can use a rest parameter as a universal catch-all. You do this by adding three dots (`...`) inside your brackets. For example:
-
- `pages/post/[...slug].astro` → (`/post/a`, `/post/a/b`, `/post/a/b/c`, etc.)
-
-Matched parameters will be sent as a query parameter (`slug` in the example) to the page. In the example above, the path `/post/a/b/c` will have the following `query` object:
-
-```json
-{ "slug": "a/b/c" }
-```
-
-You can use names other than `slug`, such as: `[...param]` or `[...name]`.
-
-Rest parameters are optional by default, so `pages/post/[...slug].astro` could match `/post/` as well.
-
-#### Example: Rest parameters
-
-For a real-world example, you might implement GitHub's file viewer like so:
-
-```
-/[org]/[repo]/tree/[branch]/[...file]
-```
-
-In this example, a request for `/withastro/astro/tree/main/docs/public/favicon.svg` would result in the following parameters being available to the page:
-
-```js
-{
-	org: 'withastro',
-	repo: 'astro',
-	branch: 'main',
-	file: 'docs/public/favicon.svg'
-}
-```
-
-## Caveats
-
- Static routes without path params will take precedence over all other routes, and named path params over catch all path params. Take a look at the following examples:
-  - `pages/post/create.astro` - Will match `/post/create`
-  - `pages/post/[pid].astro` - Will match `/post/1`, `/post/abc`, etc. But not `/post/create`
-  - `pages/post/[...slug].astro` - Will match `/post/1/2`, `/post/a/b/c`, etc. But not `/post/create`, `/post/abc`
--- a/docs/src/pages/en/getting-started.md
+++ b/docs/src/pages/en/getting-started.md
@ -1,74 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Getting Started
-description: A basic intro to Astro.
---
-
-Astro is a modern static site builder. Learn what Astro is all about from [our homepage](https://astro.build/) or [our release post](https://astro.build/blog/introducing-astro). This page is an overview of the Astro documentation and all related resources.
-
-## Try Astro
-
-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](/en/quick-start).
-
-Alternatively, read our [Installation Guide](/en/installation) for a full walk-through on getting set up with Astro.
-
-### Example Projects
-
-If you prefer to learn Astro 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 on your local machine by running `npm init astro` with the `--template` CLI flag. The `--template` flag also supports third-party, community templates.
-
-```bash
-# Run the init wizard and use this official template
-npm init astro -- --template [OFFICIAL_EXAMPLE_NAME]
-# Run the init wizard and use this community template
-npm init astro -- --template [GITHUB_USER]/[REPO_NAME]
-npm init astro -- --template [GITHUB_USER]/[REPO_NAME]/path/to/example
-```
-
-### Online Playgrounds
-
-If you're interested in playing around with Astro in the browser, you can instantly spin up a new Astro project with our UI at [astro.new](https://astro.new/).
-
-You can try Astro in online code editors like Stackblitz, CodeSandbox, Gitpod, and GitHub Codespaces. Click the "Open in Stackblitz" link in any of the examples in our [examples library](https://github.com/withastro/astro/tree/main/examples). Or, [click here](https://stackblitz.com/fork/astro) to start a new project in [Stackblitz](https://stackblitz.com/fork/astro).
-
-## Learn Astro
-
-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](/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.
-
-### Learn `.astro` Syntax
-
-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](/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](/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
-
-This documentation always reflects the latest stable version of Astro. Once we hit the v1.0 milestone, we will add the ability to view versioned documentation.
-
-## Staying Informed
-
-The [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter account is the official source for the updates from the Astro team.
-
-We also post release announcements to our [Discord community](https://astro.build/chat) in the #announcements channel.
-
-Not every Astro release deserves its own blog post, but you can find a detailed changelog for every release in the [`CHANGELOG.md` file in the Astro repository](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md).
-
-## Something Missing?
-
-If something is missing in the documentation or if you found some part confusing, please [file an issue for the documentation](https://github.com/withastro/astro/issues/new/choose) with your suggestions for improvement, or tweet at the [@astrodotbuild](https://twitter.com/astrodotbuild) Twitter account. We love hearing from you!
-
-## Credit
-
-This getting started guide was originally based off of [React's](https://reactjs.org/) getting started guide.
--- a/docs/src/pages/en/guides/aliases.md
+++ b/docs/src/pages/en/guides/aliases.md
@ -1,47 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Aliases
-description: An intro to aliases with Astro.
---
-
-An **alias** is a way to create shortcuts for your imports.
-
-Aliases can help improve the development experience in codebases with many directories or relative imports.
-
-```astro
---
-// my-project/src/pages/about/company.astro
-
-import Button from '../../components/controls/Button.astro';
-import logoUrl from '../../assets/logo.png?url';
---
-```
-
-In this example, a developer would need to understand the tree relationship between `src/pages/about/company.astro`, `src/components/controls/Button.astro`, and `src/assets/logo.png`. And then, if the `company.astro` file were to be moved, these imports would also need to be updated.
-
-You can add import aliases from either `tsconfig.json` or `jsconfig.json`.
-
-```json
-{
-  "compilerOptions": {
-    "baseUrl": ".",
-    "paths": {
-      "asset:*": ["src/assets/*?url"],
-      "component:*": ["src/components/*.astro"]
-    }
-  }
-}
-```
-
-With this change, you can now import using the aliases anywhere in your project:
-
-```astro
---
-// my-project/src/pages/about/company.astro
-
-import Button from 'component:Button';
-import logoUrl from 'asset:logo.png';
---
-```
-
-These aliases are also integrated automatically into [VSCode](https://code.visualstudio.com/docs/languages/jsconfig) and other editors.
--- a/docs/src/pages/en/guides/data-fetching.md
+++ b/docs/src/pages/en/guides/data-fetching.md
@ -1,56 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Data Fetching
-description: Learn how to fetch remote data with Astro using the fetch API.
---
-
-Astro components and pages can fetch remote data to help generate your pages. Astro provides two different tools to pages to help you do this: **fetch()** and **top-level await.**
-
-## `fetch()`
-
-Astro pages have access to the global `fetch()` function in their setup script. `fetch()` is a native JavaScript API ([MDN<span class="sr-only">- fetch</span>](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch)) that lets you make HTTP requests for things like APIs and resources.
-
-Even though Astro component scripts run inside of Node.js (and not in the browser) Astro provides this native API so that you can fetch data at page build time.
-
-```astro
---
-// Movies.astro
-const response = await fetch('https://example.com/movies.json');
-const data = await response.json();
-// Remember: Astro component scripts log to the CLI
-console.log(data);
---
-<!-- Output the result to the page -->
-<div>{JSON.stringify(data)}</div>
-```
-
-## Top-level await
-
-`await` is another native JavaScript feature that lets you await the response of some asynchronous promise ([MDN<span class="sr-only">- await</span>](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await)). Astro supports `await` in the top-level of your component script.
-
-**Important:** These are not yet available inside of non-page Astro components. Instead, do all of your data loading inside of your pages, and then pass them to your components as props.
-
-## Using `fetch()` outside of Astro Components
-
-If you want to use `fetch()` in a non-astro component, it is also globally available:
-
-```tsx
-// Movies.tsx
-import type { FunctionalComponent } from 'preact';
-import { h } from 'preact';
-
-const data = fetch('https://example.com/movies.json').then((response) =>
-  response.json()
-);
-
-// Components that are build-time rendered also log to the CLI.
-// If you loaded this component with a directive, it would log to the browser console.
-console.log(data);
-
-const Movies: FunctionalComponent = () => {
-  // Output the result to the page
-  return <div>{JSON.stringify(data)}</div>;
-};
-
-export default Movies;
-```
--- a/docs/src/pages/en/guides/debugging.md
+++ b/docs/src/pages/en/guides/debugging.md
@ -1,7 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-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](/en/reference/builtin-components#debug-).
--- a/docs/src/pages/en/guides/deploy.md
+++ b/docs/src/pages/en/guides/deploy.md
@ -1,528 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Deploy a Website
-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](/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:
-
-```json
-{
-  "scripts": {
-    "start": "astro dev",
-    "build": "astro build",
-    "preview": "astro preview"
-  }
-}
-```
-
-## Building The App
-
-You may run `npm run build` command to build the app.
-
-```bash
-$ npm run build
-```
-
-By default, the build output will be placed at `dist/`. You may deploy this `dist/` folder to any of your preferred platforms.
-
-## GitHub Pages
-
-> **Warning:** By default, Github Pages will break the `_astro/` directory of your deployed website. To disable this behavior and fix this issue, make sure that you use the `deploy.sh` script below or manually add an empty `.nojekyll` file to your `public/` site directory.
-
-1. Set the correct `buildOptions.site` in `astro.config.mjs`.
-1. Inside your project, create `deploy.sh` with the following content (uncommenting the appropriate lines), and run it to deploy:
-
-   ```bash
-   #!/usr/bin/env sh
-
-   # abort on errors
-   set -e
-
-   # build
-   npm run build
-
-   # navigate into the build output directory
-   cd dist
-
-   # add .nojekyll to bypass GitHub Page's default behavior
-   touch .nojekyll
-
-   # if you are deploying to a custom domain
-   # echo 'www.example.com' > CNAME
-
-   git init
-   git add -A
-   git commit -m 'deploy'
-
-   # if you are deploying to https://<USERNAME>.github.io
-   # git push -f git@github.com:<USERNAME>/<USERNAME>.github.io.git main
-
-   # if you are deploying to https://<USERNAME>.github.io/<REPO>
-   # git push -f git@github.com:<USERNAME>/<REPO>.git main:gh-pages
-
-   cd -
-   ```
-
-   > You can also run the above script in your CI setup to enable automatic deployment on each push.
-
-### GitHub Actions
-
-1. In the astro project repo, create `gh-pages` branch then go to Settings > Pages and set to `gh-pages` branch for GitHub Pages and set directory to `/` (root).
-2. Set the correct `buildOptions.site` in `astro.config.mjs`.
-3. Create the file `.github/workflows/main.yml` and add in the yaml below. Make sure to edit in your own details.
-4. In GitHub go to Settings > Developer settings > Personal Access tokens. Generate a new token with repo permissions.
-5. In the astro project repo (not \<YOUR USERNAME\>.github.io) go to Settings > Secrets and add your new personal access token with the name `API_TOKEN_GITHUB`.
-6. When you push changes to the astro project repo CI will deploy them to \<YOUR USERNAME\>.github.io for you.
-
-```yaml
-# Workflow to build and deploy to your GitHub Pages repo.
-
-# Edit your project details here.
-# Remember to add API_TOKEN_GITHUB in repo Settings > Secrets as well!
-env:
-  githubEmail: <YOUR GITHUB EMAIL ADDRESS>
-  deployToRepo: <NAME OF REPO TO DEPLOY TO (E.G. <YOUR USERNAME>.github.io)>
-
-name: Github Pages Astro CI
-
-on:
-  # Triggers the workflow on push and pull request events but only for the main branch
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-
-  # Allows you to run this workflow manually from the Actions tab.
-  workflow_dispatch:
-
-jobs:
-  deploy:
-    runs-on: ubuntu-latest
-
-    steps:
-      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
-      - uses: actions/checkout@v2
-
-      # Install dependencies with npm
-      - name: Install dependencies
-        run: npm ci
-
-      # Build the project and add .nojekyll file to supress default behaviour
-      - name: Build
-        run: |
-          npm run build
-          touch ./dist/.nojekyll
-
-      # Push to your pages repo
-      - name: Push to pages repo
-        uses: cpina/github-action-push-to-another-repository@main
-        env:
-          API_TOKEN_GITHUB: ${{ secrets.API_TOKEN_GITHUB }}
-        with:
-          source-directory: 'dist'
-          destination-github-username: ${{ github.actor }}
-          destination-repository-name: ${{ env.deployToRepo }}
-          user-email: ${{ env.githubEmail }}
-          commit-message: Deploy ORIGIN_COMMIT
-          target-branch: gh-pages
-```
-
-### Travis CI
-
-1. Set the correct `buildOptions.site` in `astro.config.mjs`.
-2. Create a file named `.travis.yml` in the root of your project.
-3. Run `npm install` locally and commit the generated lockfile (`package-lock.json`).
-4. Use the GitHub Pages deploy provider template, and follow the [Travis CI documentation](https://docs.travis-ci.com/user/deployment/pages/).
-
-   ```yaml
-   language: node_js
-   node_js:
-     - lts/*
-   install:
-     - npm ci
-   script:
-     - npm run build
-   deploy:
-     provider: pages
-     skip_cleanup: true
-     local_dir: dist
-     # A token generated on GitHub allowing Travis to push code on you repository.
-     # Set in the Travis settings page of your repository, as a secure variable.
-     github_token: $GITHUB_TOKEN
-     keep_history: true
-     on:
-       branch: master
-   ```
-
-## GitLab Pages
-
-1. Set the correct `buildOptions.site` in `astro.config.mjs`.
-2. Set `dist` in `astro.config.mjs` to `public` and `public` in `astro.config.mjs` to a newly named folder that is holding everything currently in `public`. The reasoning is because `public` is a second source folder in astro, so if you would like to output to `public` you'll need to pull public assets from a different folder. Your `astro.config.mjs` might end up looking like this:
-
-   ```js
-   export default /** @type {import('astro').AstroUserConfig} */ ({
-     // Enable the Preact renderer to support Preact JSX components.
-     renderers: ['@astrojs/renderer-preact'],
-     // files in `static/` will be blindly copied to `public/`
-     public: 'static',
-     // `public/` is where the built website will be output to
-     dist: 'public',
-     buildOptions: {
-       sitemap: true,
-       site: 'https://astro.build/',
-     },
-   });
-   ```
-
-3. Create a file called `.gitlab-ci.yml` in the root of your project with the content below. This will build and deploy your site whenever you make changes to your content:
-
-   ```yaml
-   image: node:14
-   pages:
-     cache:
-       paths:
-         - node_modules/
-     script:
-       - npm install
-       - npm run build
-     artifacts:
-       paths:
-         - public
-     only:
-       - main
-   ```
-
-## Netlify
-
-**Note:** If you are using an older [build image](https://docs.netlify.com/configure-builds/get-started/#build-image-selection) on Netlify, make sure that you set your Node.js version in either a [`.nvmrc`](https://github.com/nvm-sh/nvm#nvmrc) file (example: `node v14.17.6`) or a `NODE_VERSION` environment variable. This step is no longer required by default.
-
-You can configure your deployment in two ways, via the Netlify website or with a local project `netlify.toml` file.
-
-### `netlify.toml` file
-
-Create a new `netlify.toml` file at the top level of your project repository with the following settings:
-
-```toml
-[build]
-  command = "npm run build"
-  publish = "dist"
-```
-
-Push the new `netlify.toml` file up to your hosted git repository. Then, set up a new project on [Netlify](https://netlify.com) for your git repository. Netlify will read this file and automatically configure your deployment.
-
-### Netlify Website UI
-
-You can skip the `netlify.toml` file and go directly to [Netlify](https://netlify.com) to configure your project. Netlify should now detect Astro projects automatically and pre-fill the configuration for you. Make sure that the following settings are entered before hitting the "Deploy" button:
-
- **Build Command:** `astro build` or `npm run build`
- **Publish directory:** `dist`
-
-## Google Cloud
-
-Different from most available deploy options here, [Google Cloud](https://cloud.google.com) requires some UI clicks to deploy projects. (Most of these actions can also be done using the gcloud CLI).
-
-### Cloud Run
-
-1. Create a new GCP project, or select one you already have.
-
-2. Make sure the Cloud Run API is enabled.
-
-3. Create a new service.
-
-4. Use a container from Docker Hub or build your own using [Cloud Build](https://cloud.google.com/build).
-
-5. Configure a port from which the files are served.
-
-6. Enable public access by adding a new permission to `allUsers` called `Cloud Run Invoker`.
-
-### Cloud Storage
-
-1. Create a new GCP project, or select one you already have.
-
-2. Create a new bucket under [Cloud Storage](https://cloud.google.com/storage).
-
-3. Give it a name and other required settings.
-
-4. Upload your `dist` folder into it or upload using [Cloud Build](https://cloud.google.com/build).
-
-5. Enable public access by adding a new permission to `allUsers` called `Storage Object Viewer`.
-
-6. Edit the website configuration and add `ìndex.html` as entrypoint and `404.html` as errorpage.
-
-## Google Firebase
-
-1. Make sure you have [firebase-tools](https://www.npmjs.com/package/firebase-tools) installed.
-
-2. Create `firebase.json` and `.firebaserc` at the root of your project with the following content:
-
-   `firebase.json`:
-
-   ```json
-   {
-     "hosting": {
-       "public": "dist",
-       "ignore": []
-     }
-   }
-   ```
-
-   `.firebaserc`:
-
-   ```json
-   {
-     "projects": {
-       "default": "<YOUR_FIREBASE_ID>"
-     }
-   }
-   ```
-
-3. After running `npm run build`, deploy using the command `firebase deploy`.
-
-## Surge
-
-1. First install [surge](https://www.npmjs.com/package/surge), if you haven't already.
-
-2. Run `npm run build`.
-
-3. Deploy to surge by typing `surge dist`.
-
-You can also deploy to a [custom domain](http://surge.sh/help/adding-a-custom-domain) by adding `surge dist yourdomain.com`.
-
-## Heroku
-
-1. Install [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli).
-
-2. Create a Heroku account by [signing up](https://signup.heroku.com).
-
-3. Run `heroku login` and fill in your Heroku credentials:
-
-   ```bash
-   $ heroku login
-   ```
-
-4. Create a file called `static.json` in the root of your project with the below content:
-
-   `static.json`:
-
-   ```json
-   {
-     "root": "./dist"
-   }
-   ```
-
-   This is the configuration of your site; read more at [heroku-buildpack-static](https://github.com/heroku/heroku-buildpack-static).
-
-5. Set up your Heroku git remote:
-
-   ```bash
-   # version change
-   $ git init
-   $ git add .
-   $ git commit -m "My site ready for deployment."
-
-   # creates a new app with a specified name
-   $ heroku apps:create example
-
-   # set buildpack for static sites
-   $ heroku buildpacks:set https://github.com/heroku/heroku-buildpack-static.git
-   ```
-
-6. Deploy your site:
-
-   ```bash
-   # publish site
-   $ git push heroku master
-
-   # opens a browser to view the Dashboard version of Heroku CI
-   $ heroku open
-   ```
-
-## Vercel
-
-You can deploy Astro to [Vercel](http://vercel.com) through the CLI or the Vercel git integrations.
-
-### CLI
-
-1. Install the [Vercel CLI](https://vercel.com/cli) and run `vercel` to deploy.
-2. When asked `Want to override the settings? [y/N]`, choose `Y`.
-3. Update `Output Directory` to `./dist`.
-4. Your application is deployed! (e.g. [astro.vercel.app](https://astro.vercel.app/))
-
-```bash
-$ npm i -g vercel
-$ vercel
-```
-
-### Git
-
-1. Push your code to your git repository (GitHub, GitLab, BitBucket).
-2. [Import your project](https://vercel.com/new) into Vercel.
-3. Update `Output Directory` to `./dist`.
-4. Your application is deployed! (e.g. [astro.vercel.app](https://astro.vercel.app/))
-
-After your project has been imported and deployed, all subsequent pushes to branches will generate [Preview Deployments](https://vercel.com/docs/concepts/deployments/environments#preview), and all changes made to the Production Branch (commonly “main”) will result in a [Production Deployment](https://vercel.com/docs/concepts/deployments/environments#production).
-
-Learn more about Vercel’s [Git Integration](https://vercel.com/docs/concepts/git).
-
-## Azure Static Web Apps
-
-You can deploy your Astro project with Microsoft Azure [Static Web Apps](https://aka.ms/staticwebapps) service. You need:
-
- An Azure account and a subscription key. You can create a [free Azure account here](https://azure.microsoft.com/free).
- Your app code pushed to [GitHub](https://github.com).
- The [SWA Extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurestaticwebapps) in [Visual Studio Code](https://code.visualstudio.com).
-
-Install the extension in VS Code and navigate to your app root. Open the Static Web Apps extension, sign in to Azure, and click the '+' sign to create a new Static Web App. You will be prompted to designate which subscription key to use.
-
-Follow the wizard started by the extension to give your app a name, choose a framework preset, and designate the app root (usually `/`) and built file location `/dist`. The wizard will run and will create a GitHub action in your repo in a `.github` folder.
-
-The action will work to deploy your app (watch its progress in your repo's Actions tab) and, when successfully completed, you can view your app in the address provided in the extension's progress window by clicking the 'Browse Website' button that appears when the GitHub action has run.
-
-## Cloudflare Pages
-
-You can deploy your Astro project on [Cloudflare Pages](https://pages.cloudflare.com). You need:
-
- A Cloudflare account. If you don’t already have one, you can create a free Cloudflare account during the process.
- Your app code pushed to a [GitHub](https://github.com) or a [GitLab](https://about.gitlab.com/) repository.
-
-Then, set up a new project on Cloudflare Pages.
-
-Use the following build settings:
-
- **Framework preset**: `Astro`
- **Build command:** `npm run build`
- **Build output directory:** `dist`
- **Environment variables (advanced)**: Currently, Cloudflare Pages supports `NODE_VERSION = 12.18.0` in the Pages build environment by default. Astro requires `14.15.0`, `v16.0.0`, or higher. You can add an environment variable with the **Variable name** of `NODE_VERSION` and a **Value** of a [Node version that’s compatible with Astro](https://docs.astro.build/installation#prerequisites) or by specifying the node version of your project in a `.nvmrc` or `.node-version` file.
-
-Then click the **Save and Deploy** button.
-
-## Render
-
-You can deploy your Astro project on [Render](https://render.com/) following these steps:
-
-1. Create a [render.com account](https://dashboard.render.com/) and sign in
-2. Click the **New +** button from your dashboard and select **Static Site**
-3. Connect your [GitHub](https://github.com/) or [GitLab](https://about.gitlab.com/) repository or alternatively enter the public URL of a public repository
-4. Give your website a name, select the branch and specify the build command and publish directory
-   - **build command:** `npm run build`
-   - **publish directory:** `dist`
-5. Click the **Create Static Site** button
-
-## Buddy
-
-You can deploy your Astro project using [Buddy](https://buddy.works). To do so you'll need to:
-
-1. Create a **Buddy** account [here](https://buddy.works/sign-up).
-2. Create a new project and connect it with a git repository (GitHub, GitLab, BitBucket, any private Git Repository or you can use Buddy Git Hosting).
-3. Add a new pipeline.
-4. In the newly created pipeline add a **[Node.js](https://buddy.works/actions/node-js)** action.
-5. In this action add:
-
-   ```bash
-   npm install
-   npm run build
-   ```
-
-6. Add a deployment action - there are many to choose from, you can browse them [here](https://buddy.works/actions). Although their can settings differ, remember to set the **Source path** to `dist`.
-7. Press the **Run** button.
-
-## Layer0
-
-You can deploy your Astro project using the steps in the following sections.
-
-### Create the Astro Site
-
-If you don't have an existing Astro site, you can create one by running:
-
-```bash
-# Make a new project directory, and navigate directly into it
-$ mkdir my-astro-project && cd $_
-
-# prepare for liftoff...
-$ npm init astro
-
-# install dependencies
-$ npm install
-
-# start developing!
-$ npm run dev
-
-# when you're ready: build your static site to `dist/`
-$ npm run build
-```
-
-### Add Layer0
-
-```bash
-# First, globally install the Layer0 CLI:
-$ npm i -g @layer0/cli
-
-# Then, add Layer0 to your Astro site:
-$ 0 init
-```
-
-### Update your Layer0 Router
-
-Paste the following into routes.ts:
-
-```js
-// routes.ts
-import { Router } from '@layer0/core';
-
-export default new Router()
-  .get(
-    '/:path*/:file.:ext(js|css|png|ico|jpg|gif|svg)',
-    ({ cache, serveStatic }) => {
-      cache({
-        browser: {
-          // cache js, css, and images in the browser for one hour...
-          maxAgeSeconds: 60 * 60,
-        },
-        edge: {
-          // ... and at the edge for one year
-          maxAgeSeconds: 60 * 60 * 24 * 365,
-        },
-      });
-      serveStatic('dist/:path*/:file.:ext');
-    }
-  )
-  .match('/:path*', ({ cache, serveStatic, setResponseHeader }) => {
-    cache({
-      // prevent the browser from caching html...
-      browser: false,
-      edge: {
-        // ...cache html at the edge for one year
-        maxAgeSeconds: 60 * 60 * 24 * 365,
-      },
-    });
-    setResponseHeader('content-type', 'text/html; charset=UTF-8');
-    serveStatic('dist/:path*');
-  });
-```
-
-You can remove the origin backend from `layer0.config.js`:
-
-```js
-module.exports = {};
-```
-
-### Deploy to Layer0
-
-To deploy your site to Layer0, run:
-
-```bash
-# Create a production build of your astro site
-$ npm run build
-
-# Deploy it to Layer0
-$ 0 deploy
-```
-
-## Credits
-
-This guide was originally based off [Vite](https://vitejs.dev/)’s well-documented static deploy guide.
--- a/docs/src/pages/en/guides/environment-variables.md
+++ b/docs/src/pages/en/guides/environment-variables.md
@ -1,48 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Using environment variables
-description: Learn how to use environment variables in an Astro project.
---
-
-Astro uses Vite for environment variables, and allows you to use any of its methods to get and set environment variables. Note that all environment variables must be prefixed with `PUBLIC_` to be accessible by client side code.
-
-The ability to access private variables on the server side is [still being discussed](https://github.com/withastro/astro/issues/1765).
-
-## Setting environment variables
-
-Vite includes `dotenv` by default, allowing you to easily set environment variables without any extra configuration in Astro projects. You can also attach a mode (either `production` or `development`) to the filename, like `.env.production` or `.env.development`, which makes the environment variables only take effect in that mode.
-
-Just create a `.env` file in the project directory and add some variables to it.
-
-```bash
-# .env
-PUBLIC_POKEAPI="https://pokeapi.co/api/v2"
-```
-
-## Getting environment variables
-
-Instead of using `process.env`, with Vite you use `import.meta.env`, which uses the `import.meta` feature added in ES2020 (don't worry about browser support though, Vite replaces all `import.meta.env` mentions with static values). For example, to get the `PUBLIC_POKEAPI` environment variable, you could use `import.meta.env.PUBLIC_POKEAPI`.
-
-```js
-fetch(`${import.meta.env.PUBLIC_POKEAPI}/pokemon/squirtle`);
-```
-
-> ⚠️WARNING⚠️:
-> Because Vite statically replaces `import.meta.env`, you cannot access it with dynamic keys like `import.meta.env[key]`.
-
-## IntelliSense for TypeScript
-
-By default, Vite provides type definition for `import.meta.env` in `vite/client.d.ts`. While you can define more custom env variables in `.env.[mode]` files, you may want to get TypeScript IntelliSense for user-defined env variables which prefixed with `PUBLIC_`.
-
-To achieve, you can create an `env.d.ts` in `src` directory, then augment `ImportMetaEnv` like this:
-
-```ts
-interface ImportMetaEnv {
-  readonly PUBLIC_POKEAPI: string;
-  // more env variables...
-}
-
-interface ImportMeta {
-  readonly env: ImportMetaEnv;
-}
-```
--- a/docs/src/pages/en/guides/imports.md
+++ b/docs/src/pages/en/guides/imports.md
@ -1,142 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Supported Imports
-description: Learn how to import different content types with Astro.
---
-
-Astro uses Vite as its internal build system. Vite provides Astro with built-in support for the following file types, with no configuration required:
-
- JavaScript (`.js`, `.mjs`)
- TypeScript (`.ts`, `.tsx`)
- JSON (`.json`)
- JSX (`.jsx`, `.tsx`)
- CSS (`.css`)
- CSS Modules (`.module.css`)
- Images & Assets (`.svg`, `.jpg`, `.png`, etc.)
- Astro Components (`.astro`)
- Markdown (`.md`)
- WASM (`.wasm`)
-
-Any files in your `public/` directory are copied into the final build, untouched by Vite or Astro. The following applies to files in your `src/` directory, which Astro is ultimately responsible for.
-
-## JavaScript & ESM
-
-Astro was designed for JavaScript's native ES Module (ESM) syntax. ESM lets you define explicit imports & exports that browsers and build tools can better understand and optimize for. If you're familiar with the `import` and `export` keywords in JavaScript, then you already know ESM!
-
-```js
-// ESM Example - src/user.js
-export function getUser() {
-  /* ... */
-}
-
-// src/index.js
-import { getUser } from './user.js';
-```
-
-All browsers now support ESM, so Astro is able to ship this code directly to the browser during development.
-
-## TypeScript
-
-Astro includes built-in support to build TypeScript files (`*.ts`) to JavaScript. Astro components also support TypeScript in the frontmatter script section.
-
-Note that this built-in support is build only. By default, Astro does not type-check your TypeScript code.
-
-<!-- To integrate type checking into your development/build workflow, add the [@snowpack/plugin-typescript](https://www.npmjs.com/package/@snowpack/plugin-typescript) plugin. -->
-
-## JSX
-
-Astro includes built-in support to build JSX files (`*.jsx` & `*.tsx`) to JavaScript.
-
-If you are using Preact, Astro will detect your Preact import and switch to use the Preact-style JSX `h()` function. This is all done automatically for you.
-
-**Note: Astro does not support JSX in `.js`/`.ts` files.**
-
-## JSON
-
-```js
-// Load the JSON object via the default export
-import json from './data.json';
-```
-
-Astro supports importing JSON files directly into your application. Imported files return the full JSON object in the default import.
-
-## CSS
-
-```js
-// Load and inject 'style.css' onto the page
-import './style.css';
-```
-
-Astro supports importing CSS files directly into your application. Imported styles expose no exports, but importing one will automatically add those styles to the page. This works for all CSS files by default, and can support compile-to-CSS languages like Sass & Less via plugins.
-
-If you prefer not to write CSS, Astro also supports all popular CSS-in-JS libraries (ex: styled-components) for styling.
-
-## CSS Modules
-
-```jsx
-// 1. Converts './style.module.css' classnames to unique, scoped values.
-// 2. Returns an object mapping the original classnames to their final, scoped value.
-import styles from './style.module.css';
-
-// This example uses JSX, but you can use CSS Modules with any framework.
-return <div className={styles.error}>Your Error Message</div>;
-```
-
-Astro supports CSS Modules using the `[name].module.css` naming convention. Like any CSS file, importing one will automatically apply that CSS to the page. However, CSS Modules export a special default `styles` object that maps your original classnames to unique identifiers.
-
-CSS Modules help you enforce component scoping & isolation on the frontend with unique-generated class names for your stylesheets.
-
-## Other Assets
-
-```jsx
-import imgReference from './image.png'; // img === '/src/image.png'
-import svgReference from './image.svg'; // svg === '/src/image.svg'
-import txtReference from './words.txt'; // txt === '/src/words.txt'
-
-// This example uses JSX, but you can use import references with any framework.
-<img src={imgReference} />;
-```
-
-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](/en/core-concepts/project-structure/#public).
-
-## WASM
-
-```js
-// Loads and intializes the requested WASM file
-const wasm = await WebAssembly.instantiateStreaming(fetch('/example.wasm'));
-```
-
-Astro supports loading WASM files directly into your application using the browser's [`WebAssembly`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly) API.
-
-## NPM Packages
-
-```js
-// Returns the React & React-DOM npm packages
-import React from 'react';
-import ReactDOM from 'react-dom';
-```
-
-Astro lets you import npm packages directly in the browser. Even if a package was published using a legacy format, Astro will up-convert the package to ESM before serving it to the browser.
-
-When you start up your dev server or run a new build, you may see a message that Vite is "installing dependencies". This means that Vite is converting your dependencies to run in the browser. This needs to run only once, or until you next change your dependency tree by adding or removing dependencies.
-
-## Node Builtins
-
-We encourage Astro users to avoid Node.js builtins (`fs`, `path`, etc) whenever possible. Astro aims to be compatible with multiple JavaScript runtimes in the future. This includes [Deno](https://deno.land/) and [Cloudflare Workers](https://workers.cloudflare.com/) which do not support Node builtin modules such as `fs`.
-
-Our aim is to provide Astro alternatives to common Node.js builtins. However, no such alternatives exist today. So, if you _really_ need to use these builtin modules we don't want to stop you. Astro supports Node.js builtins using Node's newer `node:` prefix. If you want to read a file, for example, you can do so like this:
-
-```astro
---
-// Example: import the "fs/promises" builtin from Node.js
-import fs from 'node:fs/promises';
-
-const url = new URL('../../package.json', import.meta.url);
-const json = await fs.readFile(url, 'utf-8');
-const data = JSON.parse(json);
---
-
-<span>Version: {data.version}</span>
-```
--- a/docs/src/pages/en/guides/markdown-content.md
+++ b/docs/src/pages/en/guides/markdown-content.md
@ -1,332 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Markdown
-description: An intro to Markdown with Astro.
---
-
-Astro comes with out-of-the-box Markdown support powered by the expansive [remark](https://remark.js.org/) ecosystem.
-
-## Parsers
-
-Astro lets you use any Markdown parser you want. It just needs to be a function that follows the `MarkdownParser` type declared inside [this file](https://github.com/withastro/astro/blob/main/packages/astro/src/@types/astro.ts). You can declare it inside `astro.config.mjs`:
-
-```js
-// astro.config.mjs
-export default {
-  markdownOptions: {
-    render: [
-      'parser-name', // or import('parser-name') or (contents) => {...}
-      {
-        // options
-      },
-    ],
-  },
-};
-```
-
-Astro comes with the `@astrojs/markdown-remark` package - the default parser.
-
-### Remark and Rehype Plugins
-
-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)
- [rehype-slug](https://github.com/rehypejs/rehype-slug)
-
-Also, Astro supports third-party plugins for Markdown. You can provide your plugins in `astro.config.mjs`.
-
-> **Note:** Enabling custom `remarkPlugins` or `rehypePlugins` removes Astro's built-in support for the plugins previously mentioned. You must explicitly add these plugins to your `astro.config.mjs` file, if desired.
-
-### Add a Markdown plugin in Astro
-
-If you want to add a plugin, you need to install the npm package dependency in your project and then update `remarkPlugins` or `rehypePlugins` inside the `@astrojs/markdown-remark` options depending on what plugin you want to have:
-
-```js
-// astro.config.mjs
-export default {
-  markdownOptions: {
-    render: [
-      '@astrojs/markdown-remark',
-      {
-        remarkPlugins: [
-          // Add a Remark plugin that you want to enable for your project.
-          // If you need to provide options for the plugin, you can use an array and put the options as the second item.
-          // ['remark-autolink-headings', { behavior: 'prepend'}],
-        ],
-        rehypePlugins: [
-          // Add a Rehype plugin that you want to enable for your project.
-          // If you need to provide options for the plugin, you can use an array and put the options as the second item.
-          // 'rehype-slug',
-          // ['rehype-autolink-headings', { behavior: 'prepend'}],
-        ],
-      },
-    ],
-  },
-};
-```
-
-You can provide names of the plugins as well as import them:
-
-```js
-import autolinkHeadings from 'remark-autolink-headings';
-
-// astro.config.mjs
-export default {
-  markdownOptions: {
-    render: [
-      '@astrojs/markdown-remark',
-      {
-        remarkPlugins: [[autolinkHeadings, { behavior: 'prepend' }]],
-      },
-    ],
-  },
-};
-```
-
-### Syntax Highlighting
-
-Astro comes with built-in support for [Prism](https://prismjs.com/) and [Shiki](https://shiki.matsu.io/). By default, Prism is enabled. You can modify this behavior by updating the `@astrojs/markdown-remark` options:
-
-```js
-// astro.config.mjs
-export default {
-  markdownOptions: {
-    render: [
-      '@astrojs/markdown-remark',
-      {
-        // Pick a syntax highlighter. Can be 'prism' (default), 'shiki' or false to disable any highlighting.
-        syntaxHighlight: 'prism',
-        // If you are using shiki, here you can define a global theme and
-        // add custom languages.
-        shikiConfig: {
-          theme: 'github-dark',
-          langs: [],
-          wrap: false,
-        },
-      },
-    ],
-  },
-};
-```
-
-You can read more about custom Shiki [themes](https://github.com/shikijs/shiki/blob/main/docs/themes.md#loading-theme) and [languages](https://github.com/shikijs/shiki/blob/main/docs/languages.md#supporting-your-own-languages-with-shiki).
-
-## Markdown Pages
-
-Astro treats any `.md` files inside of the `/src/pages` directory as pages. These files can contain frontmatter, but are otherwise processed as plain markdown files and do not support components. If you're looking to embed rich components in your markdown, take a look at the [Markdown Component](#astros-markdown-component) section.
-
-### 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](/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
---
-# src/pages/index.md
-layout: ../layouts/BaseLayout.astro
-title: My cool page
-draft: false
---
-
-# Hello World!
-```
-
-```astro
---
-// src/layouts/BaseLayout.astro
-const { content } = Astro.props;
---
-<html>
-  <head>
-    <title>{content.title}</title>
-  </head>
-
-  <body>
-    <slot />
-  </body>
-</html>
-```
-
-For Markdown files, the `content` prop also has an `astro` property which holds special metadata about the page such as the complete Markdown `source` and a `headers` object. An example of what a blog post `content` object might look like is as follows:
-
-```json
-{
-  /** Frontmatter from a blog post
-  "title": "Astro 0.18 Release",
-  "date": "Tuesday, July 27 2021",
-  "author": "Matthew Phillips",
-  "description": "Astro 0.18 is our biggest release since Astro launch.",
-  "draft": false,
-  **/
-  "astro": {
-    "headers": [
-      {
-        "depth": 1,
-        "text": "Astro 0.18 Release",
-        "slug": "astro-018-release"
-      },
-      {
-        "depth": 2,
-        "text": "Responsive partial hydration",
-        "slug": "responsive-partial-hydration"
-      }
-      /* ... */
-    ],
-    "source": "# Astro 0.18 Release\\nA little over a month ago, the first public beta [...]"
-  },
-  "url": ""
-}
-```
-
-> Keep in mind that the only guaranteed properties coming from the `content` prop are `astro` and `url`.
-
-### Images and videos
-
-Using images or videos follows Astro's normal import rules:
-
- 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](/en/guides/imports#other-assets) (when using Astro's Markdown Component)
-
-### Markdown draft pages
-
-Markdown pages which have the property `draft` set in their frontmatter are referred to as "draft pages". By default, Astro excludes these pages from the build when building the static version of your page (i.e `astro build`), which means that you can exclude draft/incomplete pages from the production build by setting `draft` to `true`. To enable building of draft pages, you can set `buildOptions.drafts` to `true` in the configuration file, or pass the `--drafts` flag when running `astro build`. Markdown pages which do not have the `draft` property set are not affected. An example of a markdown draft page can be:
-
-```markdown
---
-# src/pages/blog-post.md
-title: My Blog Post
-draft: true
---
-
-This is my blog post which is currently incomplete.
-```
-
-An example of a markdown post which is not a draft:
-
-```markdown
---
-# src/pages/blog-post.md
-title: My Blog Post
-draft: false
---
-
-This is my blog post...
-```
-
-> This feature only applies to local markdown pages, not the `<Markdown />` component, or remote markdown.
-
-## Astro's Markdown Component
-
-Astro has a dedicated component used to let you render your markdown as HTML components. This is a special component that is only exposed to `.astro` files. To use the `<Markdown>` component, within your frontmatter block use the following import statement:
-
-```astro
---
-import { Markdown } from 'astro/components';
---
-```
-
-You can utilize this within your `.astro` file by doing the following:
-
-```astro
---
-import { Markdown } from 'astro/components';
---
-
-<Layout>
-  <Markdown>
-    # Hello world!
-
-    The contents inside here is all in markdown.
-  </Markdown>
-</Layout>
-```
-
-`<Markdown>` components provide more flexibility and allow you to use plain HTML or custom components. For example:
-
-````astro
---
-// For now, this import _must_ be named "Markdown" and _must not_ be wrapped with a custom component
-// We're working on easing these restrictions!
-import { Markdown } from 'astro/components';
-import Layout from '../layouts/main.astro';
-import MyFancyCodePreview from '../components/MyFancyCodePreview.tsx';
-
-const expressions = 'Lorem ipsum';
---
-
-<Layout>
-  <Markdown>
-    # Hello world!
-
-    **Everything** supported in a `.md` file is also supported here!
-
-    There is _zero_ runtime overhead.
-
-    In addition, Astro supports:
-    - Astro {expressions}
-    - Automatic indentation normalization
-    - Automatic escaping of expressions inside code blocks
-
-    ```js
-      // This content is not transformed!
-      const object = { someOtherValue };
-    ```
-
-    - Rich component support like any `.astro` file!
-    - Recursive Markdown support (Component children are also processed as Markdown)
-
-    <MyFancyCodePreview client:visible>
-      ```js
-      const object = { someOtherValue };
-      ```
-    </MyFancyCodePreview client:visible>
-  </Markdown>
-</Layout>
-````
-
-## Remote Markdown
-
-If you have Markdown in a remote source, you may pass it directly to the Markdown component through the `content` attribute. For example, the example below fetches the README from Snowpack's GitHub repository and renders it as HTML.
-
-```astro
---
-import { Markdown } from 'astro/components';
-
-const content = await fetch('https://raw.githubusercontent.com/snowpackjs/snowpack/main/README.md').then(res => res.text());
---
-
-<Layout>
-  <Markdown content={content} />
-</Layout>
-```
-
-There might be times when you want to combine both dynamic, and static markdown. If that is the case, you can nest `<Markdown>` components with each other to get the best of both worlds.
-
-```astro
---
-import { Markdown } from 'astro/components';
-
-const content = await fetch('https://raw.githubusercontent.com/snowpackjs/snowpack/main/README.md').then(res => res.text());
---
-
-<Layout>
-  <Markdown>
-    ## Markdown example
-
-    Here we have some __Markdown__ code. We can also dynamically render content from remote places.
-
-    <Markdown content={content} />
-  </Markdown>
-</Layout>
-```
-
-## Security FAQs
-
-**Aren't there security concerns to rendering remote markdown directly to HTML?**
-
-Yes! Just like with regular HTML, improper use of the `Markdown` component can open you up to a [cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) attack. If you are rendering untrusted content, be sure to _sanitize your content **before** rendering it_.
-
-**Why not use a prop like React's `dangerouslySetInnerHTML={{ __html: content }}`?**
-
-Rendering a string of HTML (or Markdown) is an extremely common use case when rendering a static site and you probably don't need the extra hoops to jump through. Rendering untrusted content is always dangerous! Be sure to _sanitize your content **before** rendering it_.
--- a/docs/src/pages/en/guides/pagination.md
+++ b/docs/src/pages/en/guides/pagination.md
@ -1,108 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Pagination
-description: An intro to Astro pagination to split large amounts of data into different pages.
---
-
-Astro supports built-in, automatic pagination for large collections of data that need to be split into multiple pages. Astro also automatically includes pagination metadata for things like previous/next page URL, total number of pages, and more.
-
-## When to use pagination
-
-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](/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](/en/core-concepts/routing) instead without pagination (Example: `/tag/[tag].astro`).
-
-## How to use pagination
-
-### Create your page component
-
-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](/en/core-concepts/routing) before continuing.
-
-Your first page URL will be different depending on which type of query param you use:
-
- `/posts/[page].astro` will generate the URLs `/posts/1`, `/posts/2`, `/posts/3`, etc.
- `/posts/[...page].astro` will generate the URLs `/posts`, `/posts/2`, `/posts/3`, etc.
-
-### calling the `paginate()` function
-
-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.
-
-```js
-export async function getStaticPaths({ paginate }) {
-  // Load your data with fetch(), Astro.fetchContent(), etc.
-  const response = await fetch(`https://pokeapi.co/api/v2/pokemon?limit=150`);
-  const result = await response.json();
-  const allPokemon = result.results;
-  // Return a paginated collection of paths for all posts
-  return paginate(allPokemon, { pageSize: 10 });
-}
-// If set up correctly, The page prop now has everything that
-// you need to render a single page (see next section).
-const { page } = Astro.props;
-```
-
-`paginate()` generates the correct array of path objects for `getStaticPaths()`. This automatically tells Astro to create a new URL for every page of the collection. The page data will then be passed as a `page` prop to the `.astro` page component.
-
-### using the `page` prop
-
-Once you've set up your page component and defined your `getStaticPaths()` function, you're ready to design your page template. Each page in the paginated collection will be passed its data in the `page` prop.
-
-```astro
---
-export async function getStaticPaths { /* ... */ }
-const { page } = Astro.props;
---
-<h1>Page {page.currentPage}</h1>
-<ul>
-  {page.data.map(item => <li>{item.title}</li>)}
-</ul>
-```
-
-The `page` prop has several useful properties, but the most important one is `page.data`. This is the array containing the page's slice of data that you passed to the `paginate()` function. For example, if you called `paginate()` on an array of 150 Pokemon:
-
- `/1`: `page.data` would be an array of the first 10 Pokemon
- `/2`: `page.data` would be an array of Pokemon 11-20
- `/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](/en/reference/api-reference#the-pagination-page-prop) for the full `page` interface.
-
-## Nested pagination
-
-A more advanced use-case for pagination is **nested pagination.** This is when pagination is combined with other dynamic route params. You can use nested pagination to group your paginated collection by some property or tag.
-
-For example, if you want to group your paginated markdown posts by some tag, you would use nested pagination by creating a `/src/pages/[tag]/[page].astro` page that would match the following URLS:
-
- `/red/1` (tag=red)
- `/red/2` (tag=red)
- `/blue/1` (tag=blue)
- `/green/1` (tag=green)
-
-Nested pagination works by returning an array of `paginate()` results from `getStaticPaths()`, one for each grouping. In the following example, we will implement nested pagination to build the URLs listed above:
-
-```astro
---
-// Example: /src/pages/[tag]/[page].astro
-export function getStaticPaths({paginate}) {
-  const allTags = ['red', 'blue', 'green'];
-  const allPosts = Astro.fetchContent('../../posts/*.md');
-  // For every tag, return a paginate() result.
-  // Make sure that you pass `{params: {tag}}` to `paginate()`
-  // so that Astro knows which tag grouping the result is for.
-  return allTags.map((tag) => {
-    const filteredPosts = allPosts.filter((post) => post.tag === tag);
-    return paginate(filteredPosts, {
-      params: { tag },
-      pageSize: 10
-    });
-  });
-}
-const { page } = Astro.props;
-const { params } = Astro.request;
-```
--- a/docs/src/pages/en/guides/publish-to-npm.md
+++ b/docs/src/pages/en/guides/publish-to-npm.md
@ -1,216 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Publish to NPM
-description: Learn how to publish Astro components to NPM
---
-
-Building a new Astro component? **Publish it to [npm!](https://npmjs.com/)**
-
-Publishing a component is a great way to reuse work across your team, your company, or the entire world. Astro components can be published to and installed from npm, just like any other JavaScript package.
-
-**Astro's ability to publish and reuse popular components is one of it's most powerful features!**
-
-Even if you don't plan on publishing your components online, the patterns outlined below can help any developer design reusable components in isolation from their custom website or business logic.
-
-Looking for inspiration? Check out some of [our favorite themes & components][/themes] from the Astro community. You can also [search npm](https://www.npmjs.com/search?q=keywords:astro-component) to see the entire public catalog.
-
-## Creating a package
-
-> Before diving in, it will help have a basic understanding of:
->
-> - [Node Modules](https://docs.npmjs.com/creating-node-js-modules)
-> - [JSON Manifest (`package.json`)](https://docs.npmjs.com/creating-a-package-json-file)
-> - [Workspaces](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#workspaces)
-
-To create a new package, we recommend developing with **workspaces**. This will allow you to develop your component alongside a working copy of Astro.
-
-```
-my-project/
-   ├─ demo/
-      └─ ... for testing and demonstration
-   ├─ package.json
-   └─ packages/
-      └─ my-component/
-         ├─ index.js
-         ├─ package.json
-         └─ ... additional files used by the package
-```
-
-In this example, named `my-project`, we create a project with a single package, named `my-component`, and a `demo` directory for testing and demonstrating the component.
-
-This is configured in the project root’s `package.json` file.
-
-```json
-{
-  "name": "my-project",
-  "workspaces": ["demo", "packages/*"]
-}
-```
-
-In this example, multiple packages can be developed together from the `packages` directory. These packages can also be referenced from `demo`, where you can install a working copy of Astro.
-
-```shell
-npm init astro demo --template minimal
-```
-
-Now let’s explore the files that will make up your individual package:
-
-### `package.json`
-
-The `package.json` in the package directory includes all of the information related to your package, including its description, dependencies, and any other package metadata.
-
-```json
-{
-  "name": "my-component",
-  "description": "... description",
-  "version": "1.0.0",
-  "type": "module",
-  "exports": {
-    ".": "./index.js",
-    "./astro": "./MyAstroComponent.astro",
-    "./react": "./MyReactComponent.jsx"
-  },
-  "files": ["index.js", "MyAstroComponent.astro", "MyReactComponent.jsx"],
-  "keywords": ["astro-component", "... etc", "... etc"]
-}
-```
-
-#### `package.json#description`
-
-The short description of your component used to help others know what it does.
-
-```json
-{
-  "description": "An Astro Element Generator"
-}
-```
-
-#### `package.json#type`
-
-The module format used by Node.js and Astro to interpret your `index.js` files.
-
-```json
-{
-  "type": "module"
-}
-```
-
-We recommend using `"type": "module"` so that your `index.js` can be used as an entrypoint with `import` and `export`.
-
-#### `package.json#exports`
-
-The entry points allowed by Astro to import your component or any of its [files](#packagejsonfiles).
-
-```json
-{
-  "exports": {
-    ".": "./index.js",
-    "./astro": "./MyAstroComponent.astro",
-    "./react": "./MyReactComponent.jsx"
-  }
-}
-```
-
-In this example, importing `my-component` would use `index.js`, while importing `my-component/astro` or `my-component/react` would use `MyAstroComponent.astro` or `MyReactComponent.jsx`.
-
-#### `package.json#files`
-
-```json
-{
-  "files": ["index.js", "MyAstroComponent.astro", "MyReactComponent.jsx"]
-}
-```
-
-#### `package.json#keywords`
-
-An array of keywords relevant to your component that are used to help others [find your component on npm](https://www.npmjs.com/search?q=keywords:astro-component) and any other search catalogs.
-
-We recommend adding the `astro-component` as a special keyword to maximize its discoverability in the Astro ecosystem.
-
-```json
-{
-  "keywords": ["astro-component", "... etc", "... etc"]
-}
-```
-
---
-
-### `index.js`
-
-The main **package entrypoint** used whenever your package is imported.
-
-```js
-export { default as MyAstroComponent } from './MyAstroComponent.astro';
-
-export { default as MyReactComponent } from './MyReactComponent.jsx';
-```
-
-This allows you to package multiple components together into a single interface.
-
-#### Example: Using Named Imports
-
-```astro
---
-import { MyAstroComponent } from 'my-component';
-import { MyReactComponent } from 'my-component';
---
-<MyAstroComponent />
-<MyReactComponent />
-```
-
-#### Example: Using Namespace Imports
-
-```astro
---
-import * as Example from 'example-astro-component';
---
-<Example.MyAstroComponent />
-<Example.MyReactComponent />
-```
-
-#### Example: Using Individual Imports
-
-```astro
---
-import MyAstroComponent from 'example-astro-component/astro';
-import MyReactComponent from 'example-astro-component/react';
---
-<MyAstroComponent />
-<MyReactComponent />
-```
-
---
-
-## Developing your package
-
-Astro does not have a dedicated "package mode" for development. Instead, you should use a demo project to develop and test your package inside of your project. This can be a private website only used for development, or a public demo/documentation website for your package.
-
-If you are extracting components from an existing project, you can even continue to use that project to develop your now-extracted components.
-
-## Testing your component
-
-Astro does not currently ship a test runner. This is something that we would like to tackle before our v1.0 release. _(If you are interested in helping out, [join us on Discord!](https://astro.build/chat))_
-
-In the meantime, our current recommendation for testing is:
-
-1. Add a test `fixtures` directory to your `demo/src/pages` directory.
-2. Add a new page for every test that you'd like to run.
-3. Each page should include some different component usage that you'd like to test.
-4. Run `astro build` to build your fixtures, then compare the output of the `dist/__fixtures__/` directory to what you expected.
-
-```bash
-my-project/demo/src/pages/__fixtures__/
-  ├─ test-name-01.astro
-  ├─ test-name-02.astro
-  └─ test-name-03.astro
-```
-
-## Publishing your component
-
-Once you have your package ready, you can publish it to npm!
-
-To publish a package to npm, use the `npm publish` command. If that fails, make sure that you've logged in via `npm login` and that your package.json is correct. If it succeeds, you're done!
-
-Notice that there was no `build` step for Astro packages. Any file type that Astro supports can be published directly without a build step, because we know that Astro already supports them natively. This includes all files with extensions like `.astro`, `.ts`, `.jsx`, and `.css`.
-
-If you need some other file type that isn't natively supported by Astro, you are welcome to add a build step to your package. This advanced exercise is left up to you.
--- a/docs/src/pages/en/guides/rss.md
+++ b/docs/src/pages/en/guides/rss.md
@ -1,53 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: RSS
-description: An intro to RSS in Astro
---
-
-Astro supports fast, automatic RSS feed generation for blogs and other content websites. For more information about RSS feeds in general, see [aboutfeeds.com](https://aboutfeeds.com/).
-
-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](/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.
-
-```js
-// Example: /src/pages/posts/[...page].astro
-// Place this function inside your Astro component script.
-export async function getStaticPaths({rss}) {
-  const allPosts = Astro.fetchContent('../post/*.md');
-  const sortedPosts = allPosts.sort((a, b) => new Date(b.date) - new Date(a.date));
-  // Generate an RSS feed from this collection
-  rss({
-    // The RSS Feed title, description, and custom metadata.
-    title: 'Don\'s Blog',
-    // See "Styling" section below
-    stylesheet: true,
-    description: 'An example blog on Astro',
-    customData: `<language>en-us</language>`,
-    // The list of items for your RSS feed, sorted.
-    items: sortedPosts.map(item => ({
-      title: item.title,
-      description: item.description,
-      link: item.url,
-      pubDate: item.date,
-    })),
-    // Optional: Customize where the file is written to.
-    // Otherwise, defaults to "/rss.xml"
-    dest: "/my/custom/feed.xml",
-  });
-  // Return your paths
-  return [...];
-}
-```
-
-Note: RSS feeds will **not** be built during development. Currently, RSS feeds are only generated during your final build.
-
-### Styling
-
-RSS Feeds can be styled with an XSL stylesheet for a more pleasant user experience when they are opened directly in a browser. By default, Astro does not set a stylesheet for RSS feeds, but it can be enabled by setting the `stylesheet` option.
-
-Astro can automatically use [Pretty Feed](https://github.com/genmon/aboutfeeds/blob/main/tools/pretty-feed-v3.xsl), a popular open-source XSL stylesheet. To enable this behavior, pass `stylesheet: true`.
-
-If you'd like to use a custom XSL stylesheet, you can pass a string value like `stylesheet: '/my-custom-stylesheet.xsl'`. This file should be in your `public/` directory (in this case, `public/my-custom-stylesheet.xsl`).
--- a/docs/src/pages/en/guides/styling.md
+++ b/docs/src/pages/en/guides/styling.md
@ -1,640 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Styling & CSS
-description: Learn how to style components with Astro.
---
-
-Astro includes special handling to make writing CSS as easy as possible. Styling inside of Astro components is done by adding a `<style>` tag anywhere.
-
-## Astro component styles
-
-By default, all Astro component styles are **scoped**, meaning they only apply to the current component. This can be very easy to work with, as you only have to worry about what’s in your current document at any given time.
-
-```html
-<!-- src/components/MyComponent.astro -->
-<style>
-  /* Scoped class selector within the component */
-  .text {
-    font-family: cursive;
-  }
-  /* Scoped element selector within the component */
-  h1 {
-    color: red;
-  }
-</style>
-
-<h1>I’m a scoped style and I’m red!</h1>
-<p class="text">I'm a scoped style and I’m cursive!</p>
-```
-
-Note that the `h1` selector won’t bleed out of the current component! These styles won’t apply any other `h1` tags outside this document. Not even child components.
-
-_Tip: even though you can use element selectors, using classnames is preferred. This is not only slightly more performant, but is also easier to read, especially in a large document._
-
-### Global styles
-
-Of course, the real power of CSS is being able to reuse as much as possible! The preferred method of loading global styles is by using a standard `<link>` tag like you’re used to. It can even be used in conjunction with Astro’s scoped `<style>` tag:
-
-```html
-<!-- src/pages/index.astro -->
-<head>
-  <!-- load styles from src/styles/utils.css using Astro.resolve() -->
-  <link rel="stylesheet" type="text/css"
-  href={Astro.resolve('../styles/utils.css')} />
-</head>
-<body>
-  <!-- scoped Astro styles that apply only to the current page (not to children or other components) -->
-  <style>
-    .title {
-      font-size: 32px;
-      font-weight: bold;
-    }
-  </style>
-
-  <!-- the ".title" class is scoped, but we can also use our global "align-center" and "margin top: 4" utility classes from utils.css -->
-  <h1 class="title align-center mt4">Scoped Page Title</h1>
-</body>
-```
-
-_Note: `Astro.resolve()` is a handy utility that helps resolve files from anywhere ([docs][astro-resolve])_
-
-#### Styling children
-
-If you’d like scoped styles to apply to children, you can use the special `:global()` function borrowed from [CSS Modules][css-modules]:
-
-```astro
-<!-- src/components/MyComponent.astro -->
---
-import PostContent from './Post.astro';
---
-<style>
-  /* Scoped to current component only */
-  h1 {
-    color: red;
-  }
-
-  /* Scoped to all descendents of the scoped .blog-post class */
-  .blog-post :global(h1) {
-    color: blue;
-  }
-</style>
-
-<h1>Title</h1>
-<article class="blog-post">
-  <PostContent />
-</article>
-```
-
-This is a great way to style things like blog posts, or documents with CMS-powered content where the contents live outside of Astro. But be careful when styling children unconditionally, as it breaks component encapsulation. Components that appear different based on whether or not they have a certain parent component can become unwieldy quickly.
-
-#### Global styles within style tag
-
-If you’d like to use global styles but you don’t want to use a normal `<link>` tag (recommended), there is a `<style global>` escape hatch:
-
-```html
-<style global>
-  /* Applies to all h1 tags in your entire site */
-  h1 {
-    font-size: 32px;
-  }
-</style>
-
-<h1>Globally-styled</h1>
-```
-
-You can achieve the same by using the `:global()` function at the root of a selector:
-
-```html
-<style>
-  /* Applies to all h1 tags in your entire site */
-  :global(h1) {
-    font-size: 32px;
-  }
-
-  /* normal scoped h1 that applies to this file only */
-  h1 {
-    color: blue;
-  }
-</style>
-```
-
-It’s recommended to only use this in scenarios where a `<link>` tag won’t work. It’s harder to track down errant global styles when they’re scattered around and not in a central CSS file.
-
-📚 Read our full guide on [Astro component syntax][astro-component] to learn more about using the `<style>` tag.
-
-## Autoprefixer
-
-[Autoprefixer][autoprefixer] takes care of cross-browser CSS compatibility for you. Use it in astro by installing it (`npm install --save-dev autoprefixer`) and adding a `postcss.config.cjs` file to the root of your project:
-
-```js
-// postcss.config.cjs
-module.exports = {
-  plugins: [require('autoprefixer')],
-};
-```
-
-_Note: Astro v0.21 and later requires this manual setup for autoprefixer. Previous versions ran this automatically._
-
-## PostCSS
-
-You can use any PostCSS plugin by adding a `postcss.config.cjs` file to the root of your project. Follow the documentation for the plugin you’re trying to install for configuration and setup.
-
---
-
-## Supported Styling Options
-
-Styling in Astro is meant to be as flexible as you'd like it to be! The following options are all supported:
-
-| Framework        | Global CSS | Scoped CSS | CSS Modules |
-| :--------------- | :--------: | :--------: | :---------: |
-| `.astro`         |     ✅     |     ✅     |    N/A¹     |
-| `.jsx` \| `.tsx` |     ✅     |     ❌     |     ✅      |
-| `.vue`           |     ✅     |     ✅     |     ✅      |
-| `.svelte`        |     ✅     |     ✅     |     ❌      |
-
-¹ _`.astro` files have no runtime, therefore Scoped CSS takes the place of CSS Modules (styles are still scoped to components, but don't need dynamic values)_
-
-All styles in Astro are automatically minified and bundled, so you can just write CSS and we'll handle the rest ✨.
-
---
-
-## Frameworks and Libraries
-
-### 📘 React / Preact
-
-`.jsx` files support both global CSS and CSS Modules. To enable the latter, use the `.module.css` extension (or `.module.scss`/`.module.sass` if using Sass).
-
-```js
-import './global.css'; // include global CSS
-import Styles from './styles.module.css'; // Use CSS Modules (must end in `.module.css`, `.module.scss`, or `.module.sass`!)
-```
-
-### 📗 Vue
-
-Vue in Astro supports the same methods as `vue-loader` does:
-
- [vue-loader - Scoped CSS][vue-scoped]
- [vue-loader - CSS Modules][vue-css-modules]
-
-### 📕 Svelte
-
-Svelte in Astro also works exactly as expected: [Svelte Styling Docs][svelte-style].
-
-### 🎨 CSS Preprocessors (Sass, Stylus, etc.)
-
-Astro supports CSS preprocessors such as [Sass][sass], [Stylus][stylus], and [Less][less] through [Vite][vite-preprocessors]. It can be enabled via the following:
-
- **Sass**: Run `npm install -D sass` and use `<style lang="scss">` or `<style lang="sass">` (indented) in `.astro` files
- **Stylus**: Run `npm install -D stylus` and use `<style lang="styl">` or `<style lang="stylus">` in `.astro` files
- **Less**: Run `npm install -D less` and use `<style lang="less">` in `.astro` files.
-
-You can also use all of the above within JS frameworks as well! Simply follow the patterns each framework recommends:
-
- **React** / **Preact**: `import Styles from './styles.module.scss'`;
- **Vue**: `<style lang="scss">`
- **Svelte**: `<style lang="scss">`
-
-Additionally, [PostCSS](#-postcss) is supported, but the setup is [slightly different](#-postcss).
-
-_Note: CSS inside `public/` will **not** be transformed! Place it within `src/` instead._
-
-### 🍃 Tailwind
-
-Astro can be configured to use [Tailwind][tailwind] easily! Install the dependencies:
-
-```
-npm install --save-dev tailwindcss
-```
-
-And create 2 files in your project root: `tailwind.config.cjs` and `postcss.config.cjs`:
-
-```js
-// tailwind.config.cjs
-module.exports = {
-  content: [
-    './public/**/*.html',
-    './src/**/*.{astro,js,jsx,svelte,ts,tsx,vue}',
-  ],
-  // more options here
-};
-```
-
-```js
-// postcss.config.cjs
-module.exports = {
-  plugins: [require('tailwindcss')],
-};
-```
-
-Now you're ready to write Tailwind! Our recommended approach is to create a `src/styles/global.css` file (or whatever you‘d like to name your global stylesheet) with [Tailwind utilities][tailwind-utilities] like so:
-
-```css
-/* src/styles/global.css */
-@tailwind base;
-@tailwind components;
-@tailwind utilities;
-```
-
-Lastly, add it to your Astro page (or layout template):
-
-```astro
-<head>
-	<style global>
-			@import "../styles/global.css";
-	</style>
-</head>
-```
-
-As an alternative to `src/styles/global.css`, You may also add Tailwind utilities to individual `pages/*.astro` components in `<style>` tags, but be mindful of duplication! If you end up creating multiple Tailwind-managed stylesheets for your site, make sure you're not sending the same CSS to users over and over again in separate CSS files.
-
-#### Migrating from v0.19
-
-As of [version 0.20.0](https://github.com/withastro/astro/releases/tag/astro%400.20.0), Astro will no longer bundle, build and process `public/` files. Previously, we'd recommended putting your tailwind files in the `public/` directory. If you started a project with this pattern, you should move any Tailwind styles into the `src` directory and import them in your template using [Astro.resolve()][astro-resolve]:
-
-```astro
-  <link
-    rel="stylesheet"
-    href={Astro.resolve("../styles/global.css")}
-  >
-```
-
-### 🎭 PostCSS
-
-Using PostCSS is as simple as placing a [`postcss.config.cjs`](https://github.com/postcss/postcss#usage) file in the root of your project.
-
-Be aware that this plugin will run on all CSS in your project, including any files that compiled to CSS (like `.scss` Sass files, for example).
-
-_Note: CSS in `public/` **will not be transformed!** Instead, place it within `src/` if you’d like PostCSS to run over your styles._
-
-## Bundling
-
-All CSS is minified and bundled automatically for you in running `astro build`. Without getting too in the weeds, the general rules are:
-
- If a style only appears on one route, it's only loaded for that route (`/_astro/[page]-[hash].css`)
- If a style appears on multiple routes, it's deduplicated into a `/_astro/common-[hash].css` bundle
- All styles are hashed according to their contents (the hashes only change if the contents do!)
-
-We'll be expanding our styling optimization story over time, and would love your feedback! If `astro build` generates unexpected styles, or if you can think of improvements, [please open an issue][issues].
-
-_Note: be mindful when some page styles get extracted to the "common" bundle, and some page styles stay on-page. For most people this may not pose an issue, but when part of your styles are bundled they technically may load in a different order and your cascade may be different. While this problem isn't unique to Astro and is present in almost any CSS bundling process, it can be unexpected if you're not anticipating it. Be sure to inspect your final production build, and please [report any issues][issues] you may come across._
-
-## Advanced Styling Architecture
-
-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](/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:
-
-**This approach is good for…**
-
- Developers wanting to try out something new in regard to styling
- Developers that would appreciate some strong opinions in CSS architecture
-
-**This approach is **NOT** good for…**
-
- Developers that already have strong opinions on styling, and want to control everything themselves
-
-Read on if you're looking for some strong opinions 🙂. We'll describe the approach by enforcing a few key rules that should govern how you set your styles:
-
-### Hybrid Scoped + Utility CSS
-
-#### Scoped styles
-
-You don't need an explanation on component-based design. You already know that reusing components is a good idea. And it's this idea that got people used to concepts like [Styled Components][styled-components] and [Styled JSX][styled-jsx]. But rather than burden your users with slow load times of CSS-in-JS, Astro has something better: **built-in scoped styles.**
-
-```astro
---
-// src/components/Button.astro -->
---
-<style lang="scss">
-  /* ✅ Locally scoped! */
-  .btn {
-    padding: 0.5em 1em;
-    border-radius: 3px;
-    font-weight: 700;
-  }
-</style>
-<button type="button" class="btn">
-  <slot></slot>
-</button>
-```
-
-_Note: all the examples here use `lang="scss"` which is a great convenience for nesting, and sharing [colors and variables][sass-use], but it's entirely optional and you may use normal CSS if you wish._
-
-That `.btn` class is scoped within that component, and won't leak out. It means that you can **focus on styling and not naming.** Local-first approach fits in very well with Astro's ESM-powered design, favoring encapsulation and reusability over global scope. While this is a simple example, it should be noted that **this scales incredibly well.** And if you need to share common values between components, [Sass' module system][sass-use] also gets our recommendation for being easy to use, and a great fit with component-first design.
-
-By contrast, Astro does allow global styles via the `:global()` and `<style global>` escape hatches. However, this should be avoided if possible. To illustrate this: say you used your button in a `<Nav />` component, and you wanted to style it differently there. You might be tempted to have something like:
-
-```astro
---
-// src/components/Nav.astro
-import Button from './Button.astro';
---
-
-<style lang="scss">
-  .nav :global(.btn) {
-    /* ❌ This will fight with <Button>'s styles */
-  }
-</style>
-
-<nav class="nav">
-  <Button>Menu</Button>
-</nav>
-```
-
-This is undesirable because now `<Nav>` and `<Button>` fight over what the final button looks like. Now, whenever you edit one, you'll always have to edit the other, and they are no longer truly isolated as they once were (now coupled by a bidirectional styling dependency). It's easy to see how this pattern only has to be repeated a couple times before being afraid that touching any styles _anywhere_ may break styling in a completely different part of the app (queue `peter-griffin-css-blinds.gif`).
-
-Instead, let `<Button>` control its own styles, and try a prop:
-
-```astro
---
-// src/components/Button.astro
-const { theme } = Astro.props;
---
-<style lang="scss">
-  .btn {
-    /* ✅  <Button> is now back in control of its own styling again! */
-    &[data-theme='nav'] {
-      // nav-friendly styles here…
-    }
-  }
-</style>
-
-<button type="button" data-theme={theme}>
-  <slot></slot>
-</button>
-```
-
-Elsewhere, you can use `<Button theme="nav">` to set the type of button it is. This preserves the contract of _Button is in charge of its styles, and Nav is in charge of its styles_, and now you can edit one without affecting the other. The worst case scenario of using global styles is that the component is broken and unusable (it's missing part of its core styles). But the worst case scenario of using props (e.g. typo) is that a component will only fall back to its default, but still usable, state.
-
-💁 **Why this works well in Astro**: Astro is inspired most by JavaScript modules: you only need to know about what's in one file at a time, and you never have to worry about something in a remote file affecting how this code runs. But we're not alone in this; Vue and Svelte have both capitalized on and popularized the idea that styles and markup are natural fits in the same component file. [You can still have separation of concerns][peace-on-css] even with markup, styling, and logic contained in one file. In fact, that's what makes component design so powerful! So write CSS without fear that you picked a name that's used by some other component across your app.
-
-#### Utility CSS
-
-Recently there has been a debate of all-scoped component styles vs utility-only CSS. But we agree with people like Sarah Dayan who ask [why can't we have both][utility-css]? Truth is that while having scoped component styles are great, there are still hundreds of times when the website's coming together when two components just don't line up _quite_ right, and one needs a nudge. Or different text treatment is needed in one component instance.
-
-While the thought of having perfect, pristine components is nice, it's unrealistic. No design system is absolutely perfect, and every design system has inconsistencies. And it's in reconciling these inconsistencies where components can become a mess without utility CSS. Utility CSS is great for adding minor tweaks necessary to get the website out the door. But they also are incomplete on their own—if you've ever tried to manage responsive styles or accessible focus states with utility CSS it can quickly become a mess! **Utility CSS works best in partnership with component (scoped) CSS**. And in order to be as easy as possible to use, Utility CSS should be global (arguably should be your only global CSS, besides maybe reset.css) so you don't have to deal with imports all willy-nilly.
-
-Some great problems best handled with Utility CSS are:
-
- [margin](https://github.com/drwpow/sass-utils#-margin--padding)
- [padding](https://github.com/drwpow/sass-utils#-margin--padding)
- [text/background color](https://github.com/drwpow/sass-utils#-color)
- [font size and family](https://github.com/drwpow/sass-utils#%F0%9F%85%B0%EF%B8%8F-font--text)
- [default element styling](https://github.com/kognise/water.css)
-
-In Astro, we recommend the following setup for this:
-
-```html
-<head>
-  <link rel="stylesheet" href="/styles/global.css" />
-</head>
-```
-
-And in your local filesystem, you can even use Sass' [@use][sass-use] to combine files together effortlessly:
-
-```
-├── src/
-│   └── styles/
-│       ├── _base.scss
-│       ├── _tokens.scss
-│       ├── _typography.scss
-│       ├── _utils.scss
-│       └── global.scss
-```
-
-What's in each file is up to you to determine, but start small, add utilities as you need them, and you'll keep your CSS weight incredibly low. And utilities you wrote to meet your real needs will always be better than anything off the shelf.
-
-So to recap, think of scoped styles as the backbone of your styles that get you 80% of the way there, and utility CSS filling in the remaining 20%. They both work well in tandem, with each compensating for the other's weakness.
-
-💁 **Why this works well in Astro**: Astro was built around the idea of **Scoped CSS and Global Utility CSS living together in harmony** ♥️! Take full advantage of it.
-
-### More suggestions
-
-"But wait!" you may ask, having read the previous section. "That doesn't take care of [my usecase]!" If you‘re looking for more pointers on some common styling problems, you may be interested in the following suggestions. These all are cohesive, and fit with the **Hybrid Scoped + Utility** philosophy:
-
-1. Split your app into Layout Components and Base Components
-1. Avoid Flexbox and Grid libraries (write your own!)
-1. Avoid `margin` on a component wrapper
-1. Avoid global media queries
-
-#### Suggestion #1: Split your app into Layout Components and Base Components
-
-While this guide will never be long enough to answer the question _"How should a page be laid out?"_ (that's a [design problem!][cassie-evans-css]) there is a more specific question hiding within that we _can_ answer: _"Given a layout, how should components/styles be organized?"_ The answer is **don't bake layout into components.** Have layout components that control layout, and base components (buttons, cards, etc.) that don't control layout. _What does that mean?_ Let's walk through an example so it's more clear. Pretend we have a page that looks like this (numbers for different components):
-
-```
-|---------------|
-|       1       |
-|-------+-------|
-|   2   |   2   |
-|---+---|---+---|
-| 3 | 3 | 3 | 3 |
-|---+---+---+---|
-| 3 | 3 | 3 | 3 |
-|---+---+---+---|
-```
-
-The layout consists of a big, giant, full-width post at top, followed by two half-width posts below it. And below that, we want a bunch of smaller posts to fill out the rest of the page. For simplicity, we'll just call these `<BigPost>` (1), `<MediumPost>` (2), and `<SmallPost>` (3). We add them to our page like so:
-
-```astro
---
-// src/pages/index.astro
-
-import Nav from '../components/Nav.astro';
-import BigPost from '../components/BigPost.astro';
-import Grid from '../components/Grid.astro';
-import MediumPosts from '../components/MediumPosts.astro';
-import SmallPosts from '../components/SmallPosts.astro';
-import Footer from '../components/Footer.astro';
---
-<html>
-  <body>
-    <Nav />
-
-    <Grid>
-      <BigPost />
-      <MediumPosts />
-      <SmallPosts />
-    </Grid>
-
-    <Footer />
-  </body>
-</html>
-```
-
-This _looks_ clean, but looks can be deceiving. At first glance, we may think that `<Grid>` is controlling the layout, but that's an illusion. We actually have `<BigPost>` handling its own width, `<MediumPosts>` loading 2 components and controlling its width, and `<SmallPosts>` loading 4+ components and controlling its width. In total, including `<Grid>`, that means **4 components** are all fighting over the same layout. Remove one post from `<MediumPosts>`, the layout breaks. Edit `<BigPost>`, the layout breaks. Edit `<Grid>`, the layout breaks. If you think about it, none of these components are truly reusable—they might as well just be one big file.
-
-This is actually the **Global CSS Problem** in disguise—multiple components fight over how they all lay out together, without layout being one, central responsibility (kinda like global CSS)! Now that we identified the problem, one way to fix this is to hoist the entire layout to the top level, and load all components there, too:
-
-```astro
---
-// src/pages/index.astro
-
-import Nav from '../components/Nav.astro';
-import BigPost from '../components/BigPost.astro';
-import MediumPost from '../components/MediumPost.astro';
-import SmallPost from '../components/SmallPost.astro';
-import Footer from '../components/Footer.astro';
---
-
-<html>
-  <head>
-    <style lang="scss">
-      .wrapper {
-        max-width: 60rem;
-        margin-right: auto;
-        margin-left: auto;
-        padding-right: 2rem;
-        padding-left: 2rem;
-      }
-
-      .grid {
-        display: grid;
-        grid-gap: 1.5rem;
-        grid-template columns: 1fr 1fr 1fr 1fr;
-      }
-
-      .big-post {
-        grid-column: span 4;
-      }
-
-      .medium-post {
-        grid-column: span 2;
-      }
-
-      .small-post {
-        grid-column: span 1;
-      }
-    </style>
-  </head>
-  <body>
-    <Nav />
-
-    <div class="wrapper">
-      <div class="grid">
-        <div class="big-post"><BigPost postId={12345} /></div>
-
-        <div class="medium-post"><MediumPost postId={12345} /></div>
-        <div class="medium-post"><MediumPost postId={12345} /></div>
-
-        <div class="small-post"><SmallPost postId={12345} /></div>
-        <div class="small-post"><SmallPost postId={12345} /></div>
-        <div class="small-post"><SmallPost postId={12345} /></div>
-        <div class="small-post"><SmallPost postId={12345} /></div>
-        <div class="small-post"><SmallPost postId={12345} /></div>
-        <div class="small-post"><SmallPost postId={12345} /></div>
-        <div class="small-post"><SmallPost postId={12345} /></div>
-        <div class="small-post"><SmallPost postId={12345} /></div>
-      </div>
-    </div>
-
-    <Footer />
-  </body>
-</html>
-```
-
-Getting over that this is more code, it's actually a much cleaner separation. What was a four-component layout is now managed 100% within the top-level `index.astro` (which we can now consider a **Layout Component**, and if we wanted to reuse this we could extract this into its own file). Your layout is centralized, and now these components truly are reusable because they don't care one bit about whether they're in the same grid or not. You can edit styles in any of these files now without fear of styles breaking in another.
-
-The basic rule is that when orchestrating multiple components, **that's a unique responsibility** that should live in one central place, rather than split between 4 components as we were doing. In fact, top-level pages are great at this, and should always be the starting point of your layout components. See how far you can take it, and only extract layout components when you absolutely have to.
-
-To recap: **if you have to touch multiple files to manage one layout, you probably need to reorganize everything into a Layout Component.**
-
-💁 **Why this works well in Astro**: In Astro, anything can be a `.astro` component, and you never incur performance problems no matter how many components you add. But the main benefit to [Layout isolation][layout-isolated] is how much it cuts down on the amount of CSS you need.
-
-#### Suggestion #2: Avoid Flexbox and Grid libraries (write your own!)
-
-This may feel like a complete overreach to tell you not to use your favorite layout framework you're familiar with. After all, it's gotten you this far! But the days of [float madness](https://zellwk.com/blog/responsive-grid-system/) are gone, replaced by Flexbox and Grid. And the latter don't need libraries to manage them (often they can make it harder).
-
-Many front-end developers experience the following train of thought:
-
-1. I should reuse as much CSS as possible (_good!_)
-2. Many pages reuse the same layout, … (_hold up—_)
-3. … therefore I can find an existing solution to manage all my duplicate layouts (_wait a minute—_)
-
-While the logic is sound, the reality is that #2 isn't truth for many projects. Probably, many parts of the website weren't designed to fit into these nice, neat, 12 column grids. Even modest web apps can contain _hundreds_ of unique layouts when you factor in all the breakpoints. Ask yourself: _If the website I'm building really contains so many unique layouts, why am I using a heavy grid library that only gives me generic layouts?_
-
-A few well-written lines of CSS Grid here and there will not only be perfect in every occasion; it's likely lighter and easier to manage than that heavy library you've fought with for so long. Another way to look at it: if you have to spend a couple hours learning a proprietary styling framework, wrestling with it, filing issues, etc., why not just spend that time on Flexbox and Grid instead? For many people, learning the basics only takes an hour, and that can get you pretty far! There are great, free, learning resources that are worth your time:
-
- [Flexbox Froggy](https://flexboxfroggy.com/)
- [CSS Grid Garden](https://cssgridgarden.com/)
-
-So in short: stop trying to deduplicate layouts when there's nothing to deduplicate! You'll find your styles not only easier to manage, but your CSS payloads much lighter, and load times faster.
-
-💁 **Why this works well in Astro**: grid libraries are a quick path to stylesheet bloat, and a major contributor to people attempting to [treeshake their styles][css-treeshaking]. Astro does **not** treeshake unused CSS for you, because [that can cause problems][css-treeshaking]. We're not saying you have to be library free; we're big fans of libraries like [Material UI][material-ui]. But if you can at least shed the thousands upon thousands of layouts you're not using from your styling library, you probably don't need automatic treeshaking.
-
-#### Suggestion #3: Avoid `margin` on a component wrapper
-
-In other words, don't do this:
-
-```astro
-<!-- src/components/MyComponent.astro -->
-<style lang="scss">
-  .wrapper {
-    /* ❌ Don't do this! */
-    margin-top: 3rem;
-  }
-</style>
-
-<div class="wrapper"></div>
-```
-
-If you remember the [CSS box model][box-model], `margin` extends beyond the boundaries of the box. This means that when you place `margin` on the outermost element, now that will push other components next to it. Even though the styles are scoped, it's _technically_ affecting elements around it, so it [breaks the concept of style containment][layout-isolated].
-
-When you have components that rearrange, or appear different when they're next to other components, that's a hard battle to win. **Components should look and act the same no matter where they are placed.** That's what makes them components!
-
-💁 **Why this works well in Astro**: margins pushing other components around creeps into your styling architecture in sneaky ways, and can result in the creation of some wonky or brittle layout components. Avoiding it altogether will keep your layout components simpler, and you'll spend less time styling in general.
-
-#### Suggestion #4: Avoid global media queries
-
-The final point is a natural boundary of **Scoped Styles**. That extends to breakpoints, too! You know that one, weird breakpoint where your `<Card />` component wraps awkwardly at a certain size? You should handle that within `<Card />`, and not anywhere else.
-
-Even if you end up with some random value like `@media (min-width: 732px) {`, that'll probably work better than trying to create a global [magic number][magic-number] somewhere that only applies to one context (an arbitrary value may be "magic" to the rest of an app, but it does still have meaning within the context of a component that needs that specific value).
-
-Granted, this has been near-impossible to achieve until Container Queries; fortunately [they are finally landing!][container-queries]
-
-Also, a common complaint of this approach is when someone asks _"What if I have 2 components that need to do the same thing at the same breakpoint?"_ to which my answer is: you'll always have one or two of those; just handle those as edge cases. But if your entire app is made up of dozens of these cases, perhaps your component lines could be redrawn so that they're more [layout-isolated][layout-isolated] in general.
-
-💁 **Why this works well in Astro**: this is probably the least important point, which is why it's saved for last. In fact, you could probably skip this if it doesn't work for you. But it's something that people try to architect for at scale, and having a global system to manage this can often be unnecessary. Give _not_ architecting for global media queries a try, and see how far it takes you!
-
-### 👓 Further Reading
-
-This guide wouldn't be possible without the following blog posts, which expand on these topics and explain them in more detail. Please give them a read!
-
- [**Layout-isolated Components**][layout-isolated] by Emil Sjölander
- [**In defense of utility-first CSS**][utility-css] by Sarah Dayan
-
-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]: /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
-[browserslist-defaults]: https://github.com/browserslist/browserslist#queries
-[cassie-evans-css]: https://twitter.com/cassiecodes/status/1392756828786790400?s=20
-[container-queries]: https://ishadeed.com/article/say-hello-to-css-container-queries/
-[css-modules]: https://github.com/css-modules/css-modules
-[css-treeshaking]: https://css-tricks.com/how-do-you-remove-unused-css-from-a-site/
-[fouc]: https://en.wikipedia.org/wiki/Flash_of_unstyled_content
-[layout-isolated]: https://web.archive.org/web/20210227162315/https://visly.app/blogposts/layout-isolated-components
-[less]: https://lesscss.org/
-[issues]: https://github.com/withastro/astro/issues
-[magic-number]: https://css-tricks.com/magic-numbers-in-css/
-[material-ui]: https://material.io/components
-[peace-on-css]: https://didoo.medium.com/let-there-be-peace-on-css-8b26829f1be0
-[sass]: https://sass-lang.com/
-[sass-use]: https://sass-lang.com/documentation/at-rules/use
-[smacss]: http://smacss.com/
-[styled-components]: https://styled-components.com/
-[stylus]: https://stylus-lang.com/
-[styled-jsx]: https://github.com/vercel/styled-jsx
-[stylelint]: https://stylelint.io/
-[svelte-style]: https://svelte.dev/docs#style
-[tailwind]: https://tailwindcss.com
-[tailwind-utilities]: https://tailwindcss.com/docs/adding-new-utilities#using-css
-[utility-css]: https://frontstuff.io/in-defense-of-utility-first-css
-[vite-preprocessors]: https://vitejs.dev/guide/features.html#css-pre-processors
-[vue-css-modules]: https://vue-loader.vuejs.org/guide/css-modules.html
-[vue-scoped]: https://vue-loader.vuejs.org/guide/scoped-css.html
--- a/docs/src/pages/en/installation.md
+++ b/docs/src/pages/en/installation.md
@ -1,176 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Installation
-description: How to install Astro with NPM, PNPM, or Yarn.
---
-
-There are a few different ways to install Astro in a new project.
-
-## Prerequisites
-
- **Node.js** - `14.15.0`, `v16.0.0`, or higher.
- **Text editor** - We recommend [VS Code](https://code.visualstudio.com/) with our [Official Astro extension](https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode).
- **Terminal** - Astro is mainly accessed via the terminal's command-line.
-
-For demonstration purposes, we will be using [`npm`](https://www.npmjs.com/) in the examples below, but you could also use [`yarn`](https://yarnpkg.com/) or [`pnpm`](https://pnpm.io/) if you prefer an npm alternative.
-
-## Create Astro
-
-`npm init astro` is the easiest way to install Astro in a new project. Run this command in your terminal to start our `create-astro` install wizard to assist you with setting up a new project.
-
-```shell
-# With NPM
-npm init astro
-
-# Yarn
-yarn create astro
-
-# Pnpm
-pnpm create astro
-```
-
-[`create-astro`](https://github.com/withastro/astro/tree/main/packages/create-astro) wizard lets you choose from a set of [starter templates](https://github.com/withastro/astro/tree/main/examples) or alternatively, you could import your own Astro project directly from GitHub.
-
-```bash
-# Note: Replace "my-astro-project" with the name of your project.
-
-# npm 6.x
-npm init astro my-astro-project --template starter
-# npm 7+ (extra double-dash is needed)
-npm init astro my-astro-project -- --template starter
-# yarn
-yarn create astro my-astro-project --template starter
-# pnpm
-pnpm create astro my-astro-project -- --template starter
-# Using a third-party template
-npm init astro my-astro-project -- --template [GITHUB_USER]/[REPO_NAME]
-# Using a third-party template, inside a repo
-npm init astro my-astro-project -- --template [GITHUB_USER]/[REPO_NAME]/path/to/template
-```
-
-After `create-astro` scaffolds out your project, remember to install your projects dependencies using npm or your package manager of choice. In this example, we'll use npm:
-
-```bash
-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](/en/guides/deploy) to your favourite hosting provider.
-
-## Manual Install
-
-You can also set up Astro without the aide of the `create-astro` wizard, below are the few extra steps that are required to get Astro going.
-
-### Set up your project
-
-```bash
-# Make and enter a new directory
-mkdir my-astro-project
-cd my-astro-project
-```
-
-Create an empty directory with the name of your project, and then navigate into it:
-
-### Create `package.json`
-
-```bash
-# This command will create a basic package.json for you
-npm init --yes
-```
-
-Astro is designed to work with the entirety of the npm package ecosystem. This is managed by a project manifest at the root of your project known as `package.json` . If you're not familiar with the `package.json` file, we highly recommend you to have a quick read over it on [the npm documentation](https://docs.npmjs.com/creating-a-package-json-file).
-
-### Install Astro
-
-Following the instructions above, you should have a directory with a single `package.json` file inside of it. You can now set up Astro inside your project.
-
-```bash
-npm install astro
-```
-
-You can now replace the placeholder "scripts" section of your `package.json` file that `npm init` created for you with the following:
-
-```diff
-  "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1"
-+    "dev": "astro dev",
-+    "build": "astro build",
-+    "preview": "astro preview"
-  },
-}
-```
-
-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
-
-Astro Open up your favourite text editor, and create a new file in your project:
-
-1. Create a new file at `src/pages/index.astro`
-2. Copy-and-paste the following snippet (including `---` dashes) into it.
-
-```astro
---
-// JS/TS Code written in between the (---) code fence,
-// is ran solely on the Server!
-console.log('See me in the Terminal')
---
-
-<html>
-  <body>
-    <h1>Hello, World!</h1>
-  </body>
-</html>
-
-<style lang='css||scss'>
-  body{
-    h1{
-      color:orange;
-    }
-  }
-</style>
-
-<script>
- // JS Code entered here is ran entirely on the Browser
- console.log('See me in the devTools')
-</script>
-```
-
-Above is an example of the Astro's Component's Syntax, which comprises of both HTML & JSX.
-
-You can create more pages in the `src/pages` directory, and Astro will use the filename to create new pages on your site. For example, by creating a new file at `src/pages/about.astro` (reusing the previous snippet), Astro will generate a new page at the URL : `http://localhost/about`
-
-## [Start Astro](#start-astro)
-
-```bash
-npm run dev
-```
-
-Astro will now start serving your application on `http://localhost:3000`. By opening this URL in your browser, you should see the Astro's “Hello, World”.
-
-If you need to share your development progress on the local network or check out the app from a phone, just add the following [snowpack](https://www.snowpack.dev/reference/configuration#devoptionshostname) option to `astro.config.mjs`:
-
-```js
-devOptions: {
-  hostname: '0.0.0.0',
-}
-```
-
-## [Build Astro](#build-astro)
-
-```bash
-npm run build
-```
-
-This will instruct Astro to build your site and save it directly to disk. Your application is now ready in the `dist/` directory.
-
-## Next Steps
-
-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.](/en/core-concepts/project-structure)
-
-📚 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.](/en/core-concepts/astro-pages)
--- a/docs/src/pages/en/migration/0.21.0.md
+++ b/docs/src/pages/en/migration/0.21.0.md
@ -1,264 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Migrating to v0.21
-description: How to migrate projects from Astro v0.20.
---
-
-## Vite
-
-Starting in v0.21, Astro is built with [Vite].
-As a result, configurations written in `snowpack.config.mjs` should be moved into `astro.config.mjs`.
-
-```js
-// @ts-check
-
-/** @type {import('astro').AstroUserConfig} */
-export default {
-  renderers: [],
-  vite: {
-    plugins: [],
-  },
-};
-```
-
-To learn more about configuring Vite, please visit their [configuration guide](https://vitejs.dev/config/).
-
-## Aliasing
-
-In Astro v0.21, import aliases can be added from `tsconfig.json` or `jsconfig.json`.
-
-```json
-{
-  "compilerOptions": {
-    "baseUrl": ".",
-    "paths": {
-      "@/components/*": ["src/components/*"]
-    }
-  }
-}
-```
-
-_These aliases are integrated automatically into [VSCode](https://code.visualstudio.com/docs/languages/jsconfig) and other editors._
-
-## Variables in Scripts & Styles
-
-In Astro v0.21, _serializable_ server-side variables can be passed into client-side `<style>` or `<script>`.
-
-```astro
---
-// tick.astro
-const foregroundColor = "rgb(221 243 228)";
-const backgroundColor = "rgb(24 121 78)";
---
-<style define:vars={{foregroundColor, backgroundColor}}>
-  h-tick {
-    background-color: var(--backgroundColor);
-    border-radius: 50%;
-    color: var(--foregroundColor);
-    height: 15px;
-    width: 15px;
-  }
-</style>
-<h-tick>✓</h-tick>
-```
-
-## Imports on top bug
-
-In Astro v0.21, a bug has been introduced that requires imports inside components to be at the top of your frontmatter.
-
-```astro
---
-import Component from '../components/component.astro'
-const whereShouldIPutMyImports = "on top!"
---
-```
-
-_Note: This is a bug that will be fixed._
-
-## Components in Markdown
-
-In Astro v0.21, Components from any framework can be used within Markdown files.
-
-```markdown
---
-layout: '...'
-setup: |
-  import MyReactComponent from '../components/MyReactComponent.jsx'
---
-
-# Hydrating on visibility
-
-<MyReactComponent client:visible>
-
-# Hello world!
-
-</MyReactComponent>
-```
-
-## Components in Frontmatter
-
-Previously, you could create mini Astro Components inside of the Astro Frontmatter, using JSX syntax instead of Astro's component syntax. This was always a bit of a hack, but in the new compiler it became impossible to support. We hope to re-introduce this feature in a future release of Astro using a different, non-JSX API.
-
-To migrate to v0.21, please convert all JSX Astro components (that is, any Astro components created inside of another component's frontmatter) to standalone components.
-
-## Environment Variables
-
-In Astro v0.21, environment variables can be loaded from `.env` files in your project directory.
-
-```ini
-.env                # loaded in all cases
-.env.local          # loaded in all cases, ignored by git
-.env.[mode]         # only loaded in specified mode
-.env.[mode].local   # only loaded in specified mode, ignored by git
-```
-
-For security purposes, only variables prefixed with `PUBLIC_` are accessible to your code.
-
-```ini
-SECRET_PASSWORD=password123
-PUBLIC_ANYBODY=there
-```
-
-In this example, `PUBLIC_ANYBODY` will be available as `import.meta.env.PUBLIC_ANYBODY` in server or client code, while `SECRET_PASSWORD` will not.
-
-> In prior releases, these variables were prefixed with `SNOWPACK_PUBLIC_` and required the `@snowpack/plugin-env` plugin.
-
-## File Extensions
-
-In Astro v0.21, files need to be referenced by their actual extension, exactly as it is on disk.
-
-```tsx
-// Div.tsx
-export default function Div(props) {
-  return <div />;
-}
-```
-
-In this example, `Div.tsx` would need to be referenced as `Div.tsx`, not `Div.jsx`.
-
-```diff
- import Div from './Div.jsx' // Astro v0.20
-+ import Div from './Div.tsx' // Astro v0.21
-```
-
-This same change applies to styles.
-
-```scss
-// Div.scss
-div {
-  all: unset;
-}
-```
-
-```diff
- <link rel="stylesheet" href={Astro.resolve('./Div.css')}>
-+ <link rel="stylesheet" href={Astro.resolve('./Div.scss')}>
-```
-
-## Plugins
-
-In Astro v0.21, Vite plugins may be configured within `astro.config.mjs`.
-
-```js
-import { imagetools } from 'vite-imagetools';
-
-export default {
-  vite: {
-    plugins: [imagetools()],
-  },
-};
-```
-
-To learn more about Vite plugins, please visit their [plugin guide](https://vitejs.dev/guide/using-plugins.html).
-
-## Custom Renderers
-
-In Astro v0.21, plugins should now use `viteConfig()`.
-
-```diff
-// renderer-svelte/index.js
-+ import { svelte } from '@sveltejs/vite-plugin-svelte';
-
-export default {
-  name: '@astrojs/renderer-svelte',
-  client: './client.js',
-  server: './server.js',
-  snowpackPlugin: '@snowpack/plugin-svelte',
-  snowpackPluginOptions: { compilerOptions: { hydratable: true } },
-+  viteConfig() {
-+    return {
-+      optimizeDeps: {
-+        include: ['@astrojs/renderer-svelte/client.js', 'svelte', 'svelte/internal'],
-+        exclude: ['@astrojs/renderer-svelte/server.js'],
-+      },
-+      plugins: [
-+        svelte({
-+          emitCss: true,
-+          compilerOptions: { hydratable: true },
-+        }),
-+      ],
-+    };
-+  },
-}
-```
-
-To learn more about Vite plugins, please visit their [plugin guide](https://vitejs.dev/guide/using-plugins.html).
-
-> In prior releases, these were configured with `snowpackPlugin` or `snowpackPluginOptions`.
-
-## Markdown Options
-
-The configuration of markdown options has changed slightly in Astro v0.21. There's now a `render` property, which should include `@astrojs/markdown-remark`:
-
-```diff
-// astro.config.mjs
-export default {
-  markdownOptions: {
-+    render: [
-+      '@astrojs/markdown-remark',
-+      {
-        remarkPlugins: [
-          // Add a Remark plugin that you want to enable for your project.
-        ],
-        rehypePlugins: [
-          // Add a Rehype plugin that you want to enable for your project.
-        ],
-+      },
-+    ],
-  },
-};
-```
-
-## Styling Changes
-
-### Autoprefixer
-
-Autoprefixer is no longer run by default. To enable:
-
-1. Install the latest version (`npm i autoprefixer`)
-2. Create a `postcss.config.cjs` file at the root of your project with:
-   ```js
-   module.exports = {
-     plugins: {
-       autoprefixer: {},
-     },
-   };
-   ```
-
-### Tailwind CSS
-
-Ensure you have PostCSS installed. This was optional in previous releases, but is required now:
-
-1. Install the latest version of postcss (`npm i -D postcss`)
-2. Create a `postcss.config.cjs` file at the root of your project with:
-   ```js
-   module.exports = {
-     plugins: {
-       tailwindcss: {},
-     },
-   };
-   ```
-   For more information, read the [Tailwind CSS documentation](https://tailwindcss.com/docs/installation#add-tailwind-as-a-post-css-plugin)
-
-[snowpack]: https://www.snowpack.dev
-[vite]: https://vitejs.dev
--- a/docs/src/pages/en/quick-start.md
+++ b/docs/src/pages/en/quick-start.md
@ -1,77 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Quick Start
-description: The easiest way to get started quickly with Astro.
---
-
-```shell
-# prerequisite: check that Node.js is 14.15.0+, or 16+
-node --version
-
-# Make a new project directory, and navigate directly into it
-mkdir my-astro-project && cd $_
-
-# prepare for liftoff...
-npm init astro
-
-# install dependencies
-npm install
-
-# start developing!
-npm run dev
-```
-
-For production sites,
-
-```shell
-# when you're ready: build your static site to `dist/`
-npm run build
-```
-
-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"`.
-
-## Start your project
-
-From inside your project directory, enter the following command into your terminal:
-
-```bash
-npm run dev
-```
-
-Astro will now start serving your application on [http://localhost:3000](http://localhost:3000). Opening this URL in your browser, you should see the Astro's "Hello, World".
-
-The server will listen for live file changes in your `src/` directory, so you do not need to restart the application as you make changes during development.
-
-## Build your project
-
-To build your project, from inside your directory enter the following build command into your terminal:
-
-```bash
-npm run build
-```
-
-This will instruct Astro to build your site and save it directly to disk. Your application is now ready in the `dist/` directory.
-
-## Deploy your project
-
-Astro sites are static, so they can be deployed to your favourite host:
-
- [AWS S3 bucket](https://aws.amazon.com/s3/)
- [Google Firebase](https://firebase.google.com/)
- [Netlify](https://www.netlify.com/)
- [Vercel](https://vercel.com/)
- [Read more about deploying Astro in our Deploy guide.](/en/guides/deploy)
-
-## Next Steps
-
-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.](/en/core-concepts/project-structure)
-
-📚 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.](/en/core-concepts/astro-pages)
--- a/docs/src/pages/en/reference/api-reference.md
+++ b/docs/src/pages/en/reference/api-reference.md
@ -1,293 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: API Reference
---
-
-## `Astro` global
-
-The `Astro` global is available in all contexts in `.astro` files. It has the following functions:
-
-### `Astro.fetchContent()`
-
-`Astro.fetchContent()` is a way to load local `*.md` files into your static site setup.
-
-```astro
---
-// ./src/components/my-component.astro
-const data = Astro.fetchContent('../pages/post/*.md'); // returns an array of posts that live at ./src/pages/post/*.md
---
-
-<div>
-{data.slice(0, 3).map((post) => (
-  <article>
-    <h1>{post.title}</h1>
-    <p>{post.description}</p>
-    <a href={post.url}>Read more</a>
-  </article>
-))}
-</div>
-```
-
-`.fetchContent()` only takes one parameter: a relative URL glob of which local files you'd like to import. Currently only `*.md` files are supported. It's synchronous, and returns an array of items of type:
-
-```js
-{
-   /** frontmatter from the post.. example frontmatter:
-    title: '',
-    tag: '',
-    date: '',
-    image: '',
-    author: '',
-    description: '',
-   **/
-    astro: {
-      headers: [],  // an array of h1...h6 elements in the markdown file
-      source: '',    // raw source of the markdown file
-      html: ''      // rendered HTML of the markdown file
-    },
-    url: '' // the rendered path
-  }[]
-```
-
-### `Astro.request`
-
-`Astro.request` returns an object with the following properties:
-
-| Name           | Type  | Description                                     |
-| :------------- | :---- | :---------------------------------------------- |
-| `url`          | `URL` | The URL of the request being rendered.          |
-| `canonicalURL` | `URL` | [Canonical URL][canonical] of the current page. |
-
-### `Astro.resolve()`
-
-`Astro.resolve()` helps with creating URLs relative to the current Astro file, allowing you to reference files within your `src/` folder.
-
-Astro _does not_ resolve relative links within HTML, such as images:
-
-```html
-<img src="../images/penguin.png" />
-```
-
-The above will be sent to the browser as-is and the browser will resolve it relative to the current **page**. If you want it to be resolved relative to the .astro file you are working in, use `Astro.resolve`:
-
-```astro
-<img src={Astro.resolve('../images/penguin.png')} />
-```
-
-### `Astro.site`
-
-`Astro.site` returns a `URL` made from `buildOptions.site` in your Astro config. If undefined, this will return a URL generated from `localhost`.
-
-```astro
---
-const path = Astro.site.pathname;
---
-
-<h1>Welcome to {path}</h1>
-```
-
-### `Astro.slots`
-
-`Astro.slots` returns an object with any slotted regions passed into the current Astro file.
-
-```js
-const {
-  heading as headingSlot, // true or undefined, based on whether `<* slot="heading">` was used.
-  default as defaultSlot, // true or undefined, based on whether `<* slot>` or `<* default>` was used.
-} = Astro.slots;
-```
-
-## `getStaticPaths()`
-
-If a page uses dynamic params in the filename, that component will need to export a `getStaticPaths()` function.
-
-This function is required because Astro is a static site builder. That means that your entire site is built ahead of time. If Astro doesn't know to generate a page at build time, your users won't see it when they visit your site.
-
-```astro
---
-export async function getStaticPaths() {
-  return [
-    { params: { /* required */ }, props: { /* optional */ } },
-    { params: { ... } },
-    { params: { ... } },
-    // ...
-  ];
-}
---
-<!-- Your HTML template here. -->
-```
-
-The `getStaticPaths()` function should return an array of objects to determine which paths will be pre-rendered by Astro.
-
-⚠️ The `getStaticPaths()` function executes in its own isolated scope once, before any page loads. Therefore you can't reference anything from its parent scope, other than file imports. The compiler will warn if you break this requirement.
-
-### `params`
-
-The `params` key of every returned object tells Astro what routes to build. The returned params must map back to the dynamic parameters and rest parameters defined in your component filepath.
-
-`params` are encoded into the URL, so only strings are supported as values. The value for each `params` object must match the parameters used in the page name.
-
-For example, suppose that you have a page at `src/pages/posts/[id].astro`. If you export `getStaticPaths` from this page and return the following for paths:
-
-```astro
---
-export async function getStaticPaths() {
-  return [
-    { params: { id: '1' } },
-    { params: { id: '2' } }
-  ];
-}
-const {id} = Astro.request.params;
---
-<body><h1>{id}</h1></body>
-```
-
-Then Astro will statically generate `posts/1` and `posts/2` at build time.
-
-### Data Passing with `props`
-
-To pass additional data to each generated page, you can also set a `props` value on every returned path object. Unlike `params`, `props` are not encoded into the URL and so aren't limited to only strings.
-
-For example, suppose that you generate pages based off of data fetched from a remote API. You can pass the full data object to the page component inside of `getStaticPaths`:
-
-```astro
---
-export async function getStaticPaths() {
-  const data = await fetch('...').then(response => response.json());
-  return data.map((post) => {
-    return {
-      params: { id: post.id },
-      props: { post } };
-  });
-}
-const {id} = Astro.request.params;
-const {post} = Astro.props;
---
-<body><h1>{id}: {post.name}</h1></body>
-```
-
-Then Astro will statically generate `posts/1` and `posts/2` at build time using the page component in `pages/posts/[id].astro`. The page can reference this data using `Astro.props`:
-
-### `paginate()`
-
-Pagination is a common use-case for websites that Astro natively supports via the `paginate()` function. `paginate()` will automatically generate the array to return from `getStaticPaths()` that creates one URL for every page of the paginated collection. The page number will be passed as a param, and the page data will be passed as a `page` prop.
-
-```js
-export async function getStaticPaths({ paginate }) {
-  // Load your data with fetch(), Astro.fetchContent(), etc.
-  const response = await fetch(`https://pokeapi.co/api/v2/pokemon?limit=150`);
-  const result = await response.json();
-  const allPokemon = result.results;
-  // Return a paginated collection of paths for all posts
-  return paginate(allPokemon, { pageSize: 10 });
-}
-// If set up correctly, The page prop now has everything that
-// you need to render a single page (see next section).
-const { page } = Astro.props;
-```
-
-`paginate()` assumes a file name of `[page].astro` or `[...page].astro`. The `page` param becomes the page number in your URL:
-
- `/posts/[page].astro` would generate the URLs `/posts/1`, `/posts/2`, `/posts/3`, etc.
- `/posts/[...page].astro` would generate the URLs `/posts`, `/posts/2`, `/posts/3`, etc.
-
-#### The pagination `page` prop
-
-Pagination will pass a `page` prop to every rendered page that represents a single page of data in the paginated collection. This includes the data that you've paginated (`page.data`) as well as metadata for the page (`page.url`, `page.start`, `page.end`, `page.total`, etc). This metadata is useful for things like a "Next Page" button or a "Showing 1-10 of 100" message.
-
-| Name               |         Type          | Description                                                                                                                       |
-| :----------------- | :-------------------: | :-------------------------------------------------------------------------------------------------------------------------------- |
-| `page.data`        |        `Array`        | Array of data returned from `data()` for the current page.                                                                        |
-| `page.start`       |       `number`        | Index of first item on current page, starting at `0` (e.g. if `pageSize: 25`, this would be `0` on page 1, `25` on page 2, etc.). |
-| `page.end`         |       `number`        | Index of last item on current page.                                                                                               |
-| `page.size`        |       `number`        | How many items per-page.                                                                                                          |
-| `page.total`       |       `number`        | The total number of items across all pages.                                                                                       |
-| `page.currentPage` |       `number`        | The current page number, starting with `1`.                                                                                       |
-| `page.lastPage`    |       `number`        | The total number of pages.                                                                                                        |
-| `page.url.current` |       `string`        | Get the URL of the current page (useful for canonical URLs)                                                                       |
-| `page.url.prev`    | `string \| undefined` | Get the URL of the previous page (will be `undefined` if on page 1).                                                              |
-| `page.url.next`    | `string \| undefined` | Get the URL of the next page (will be `undefined` if no more pages).                                                              |
-
-### `rss()`
-
-RSS feeds are another common use-case that Astro supports natively. Call the `rss()` function to generate an `/rss.xml` feed for your project using the same data that you loaded for this page. This file location can be customized (see below).
-
-```js
-// Example: /src/pages/posts/[...page].astro
-// Place this function inside your Astro component script.
-export async function getStaticPaths({rss}) {
-  const allPosts = Astro.fetchContent('../post/*.md');
-  const sortedPosts = allPosts.sort((a, b) => new Date(b.date) - new Date(a.date));
-  // Generate an RSS feed from this collection
-  rss({
-    // The RSS Feed title, description, and custom metadata.
-    title: 'Don’s Blog',
-    description: 'An example blog on Astro',
-    customData: `<language>en-us</language>`,
-    // The list of items for your RSS feed, sorted.
-    items: sortedPosts.map(item => ({
-      title: item.title,
-      description: item.description,
-      link: item.url,
-      pubDate: item.date,
-    })),
-    // Optional: Customize where the file is written to.
-    // Defaults to "/rss.xml"
-    dest: "/my/custom/feed.xml",
-  });
-  // Return a paginated collection of paths for all posts
-  return [...];
-}
-```
-
-```ts
-// The full type definition for the rss() function argument:
-interface RSSArgument {
-  /** (required) Title of the RSS Feed */
-  title: string;
-  /** (required) Description of the RSS Feed */
-  description: string;
-  /** Specify arbitrary metadata on opening <xml> tag */
-  xmlns?: Record<string, string>;
-  /** Specify custom data in opening of file */
-  customData?: string;
-  /**
-   * Specify where the RSS xml file should be written.
-   * Relative to final build directory. Example: '/foo/bar.xml'
-   * Defaults to '/rss.xml'.
-   */
-  dest?: string;
-  /** Return data about each item */
-  items: {
-    /** (required) Title of item */
-    title: string;
-    /** (required) Link to item */
-    link: string;
-    /** Publication date of item */
-    pubDate?: Date;
-    /** Item description */
-    description?: string;
-    /** Append some other XML-valid data to this item */
-    customData?: string;
-  }[];
-}
-```
-
-## `import.meta`
-
-> In this section we use `[dot]` to mean `.`. This is because of a bug in our build engine that is rewriting `import[dot]meta[dot]env` if we use `.` instead of `[dot]`.
-
-All ESM modules include a `import.meta` property. Astro adds `import[dot]meta[dot]env` through [Vite](https://vitejs.dev/guide/env-and-mode.html).
-
-**`import[dot]meta[dot]env[dot]SSR`** can be used to know when rendering on the server. Sometimes you might want different logic, for example a component that should only be rendered in the client:
-
-```jsx
-import { h } from 'preact';
-
-export default function () {
-  // Note: rewrite "[dot]" to "." for this to to work in your project.
-  return import[dot]meta[dot]env[dot]SSR ? <div class="spinner"></div> : <FancyComponent />;
-}
-```
-
-[canonical]: https://en.wikipedia.org/wiki/Canonical_link_element
--- a/docs/src/pages/en/reference/builtin-components.md
+++ b/docs/src/pages/en/reference/builtin-components.md
@ -1,70 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Built-In Components
---
-
-Astro includes several builtin components for you to use in your projects. All builtin components are available via `import {} from 'astro/components';`.
-
-## `<Code />`
-
-```astro
---
-import { Code } from 'astro/components';
---
-<!-- Syntax highlight some JavaScript code. -->
-<Code code={`const foo = 'bar';`} lang="js" />
-<!-- Optional: customize your theme. -->
-<Code code={`const foo = 'bar';`} lang="js" theme="dark-plus" />
-<!-- Optional: Enable word wrapping. -->
-<Code code={`const foo = 'bar';`} lang="js" wrap />
-```
-
-This component provides syntax highlighting for code blocks at build time (no client-side JavaScript included). The component is powered internally by shiki and it supports all popular [themes](https://github.com/shikijs/shiki/blob/main/docs/themes.md) and [languages](https://github.com/shikijs/shiki/blob/main/docs/languages.md). Plus, you can add your custom themes and languages by passing them to `theme` and `lang` respectively.
-
-You can also use the `<Prism />` component for syntax highlighting powered by the [Prism](https://prismjs.com/) syntax highlighting library. This is the library that Astro's Markdown uses by default. However, we will be transitioning all usage over to `<Code>` as we move towards our v1.0 release.
-
-## `<Markdown />`
-
-```astro
---
-import { Markdown } from 'astro/components';
---
-<Markdown>
-  # Markdown syntax is now supported! **Yay!**
-</Markdown>
-```
-
-See our [Markdown Guide](/en/guides/markdown-content) for more info.
-
-<!-- TODO: We should move some of the specific component info here. -->
-
-## `<Prism />`
-
-```astro
---
-import { Prism } from 'astro/components';
---
-<Prism lang="js" code={`const foo = 'bar';`} />
-```
-
-This component provides language-specific syntax highlighting for code blocks. Since this never changes in the client it makes sense to use an Astro component (it's equally reasonable to use a framework component for this kind of thing; Astro is server-only by default for all frameworks!).
-
-See the [list of languages supported by Prism](https://prismjs.com/#supported-languages) where you can find a language's corresponding alias. And, you can also display your Astro code blocks with lang="astro"!
-
-## `<Debug />`
-
-```astro
---
-import Debug from 'astro/debug';
-const serverObject = {
-  a: 0,
-  b: "string",
-  c: {
-    nested: "object"
-  }
-}
---
-<Debug {serverObject} />
-```
-
-This component provides a way to inspect values on the clientside, without any JavaScript.
--- a/docs/src/pages/en/reference/cli-reference.md
+++ b/docs/src/pages/en/reference/cli-reference.md
@ -1,72 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: CLI Reference
---
-
-## Commands
-
-### `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](/en/reference/configuration-reference)).
-
-**Flags**
-
-#### `--port`
-
-Specifies should port to run on. Defaults to `3000`.
-
-### `astro build`
-
-Builds your site for production.
-
-### `astro preview`
-
-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](/en/guides/deploy).
-
-### `astro check`
-
-Runs diagnostics (such as type-checking) against your project and reports errors to the console. If any errors are found the process will exit with a code of **1**.
-
-This command is intended to be used in CI workflows.
-
-## Global Flags
-
-### `--config path`
-
-Specify the path to the config file. Defaults to `astro.config.mjs`. Use this if you use a different name for your configuration file or have your config file in another folder.
-
-```shell
-astro --config config/astro.config.mjs dev
-```
-
-### `--project-root path`
-
-Specify the path to the project root. If not specified the current working directory is assumed to be the root.
-
-The root is used for finding the Astro configuration file.
-
-```shell
-astro --project-root examples/snowpack dev
-```
-
-### `--reload`
-
-Clears the cache (dependencies are built within Astro apps).
-
-### `--verbose`
-
-Enables verbose logging, which is helpful when debugging an issue.
-
-### `--silent`
-
-Enables silent logging, which is helpful for when you don't want to see Astro logs.
-
-### `--version`
-
-Print the Astro version number and exit.
-
-### `--help`
-
-Print the help message and exit.
--- a/docs/src/pages/en/reference/configuration-reference.md
+++ b/docs/src/pages/en/reference/configuration-reference.md
@ -1,80 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Configuration Reference
---
-
-To configure Astro, add an `astro.config.mjs` file to the root of your project.
-
-```js
-export default /** @type {import('astro').AstroUserConfig} */ ({
-  // all options are optional; these values are the defaults
-  projectRoot: './',
-  public: './public/',
-  dist: './dist/',
-  src: './src/',
-  pages: './src/pages/',
-  renderers: [
-    '@astrojs/renderer-svelte',
-    '@astrojs/renderer-vue',
-    '@astrojs/renderer-react',
-    '@astrojs/renderer-preact',
-  ],
-  vite: {},
-});
-```
-
-#### projectRoot
-
-The `projectRoot` option sets the working directory used by Astro. Astro will resolve all other directory options from this path.
-
-**Default**: The current working directory.
-
-#### public
-
-The `public` option sets the directory used to resolve public assets. Astro does not process any files within this directory.
-
-**Default**: The `public` directory within the `projectRoot` directory.
-
-#### dist
-
-The `dist` option sets the directory used to output the final build of the project. Contents of the `public` directory are also copied into this directory.
-
-**Default**: The `dist` directory within the `projectRoot` directory.
-
-#### src
-
-The `src` option sets the directory used to resolve source files, like `pages`. Astro may process, optimize, and bundle any files in this directory.
-
-**Default**: The `src` directory within the `projectRoot` directory.
-
-#### pages
-
-The `pages` option sets the directory used to resolve pages, relative to the `projectRoot` option.
-
-**Default**: The `src/pages` directory within the `projectRoot` directory.
-
-#### renderers
-
-The `renderers` option defines the framework renderers to be used by Astro.
-
-**Default**: An array of `@astrojs/renderer-svelte`, `@astrojs/renderer-vue`, `@astrojs/renderer-react`, and `@astrojs/renderer-preact`. To assign no renderers at all, you must provide an empty array (`[]`).
-
-#### buildOptions
-
-The `buildOptions` option configures how a site is built, including its base URL (`buildOptions.site`), whether it includes a sitemap (`buildOptions.sitemap`), whether markdown draft pages should be included in the build (`buildOptions.drafts`), and whether its pages should be files (`path.html`) or directories (`path/index.html`) (`buildOptions.pageUrlFormat`).
-
-#### devOptions
-
-The `devOptions` option configures features used during development, including the server hostname (`devOptions.hostname`), the server port (`devOptions.port`), and whether urls should include a trailing slash (`devOptions.trailingSlash`).
-
-#### vite
-
-The `vite` option configures the internals of Vite. These options can be explored on [ViteJS.dev](https://vitejs.dev/config/).
-
-#### markdownOptions
-
-The `markdownOptions` option assigns options to the Markdown parser. These options can be explored on [GitHub](https://github.com/withastro/astro/blob/latest/packages/astro/src/@types/astro.ts).
-
---
-
-You can view the entire configuration API on [GitHub](https://github.com/withastro/astro/blob/latest/packages/astro/src/@types/astro.ts).
--- a/docs/src/pages/en/reference/renderer-reference.md
+++ b/docs/src/pages/en/reference/renderer-reference.md
@ -1,229 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: UI Renderer Reference
---
-
-Astro is designed to support your favorite UI frameworks. [React](https://npm.im/@astrojs/renderer-react), [Svelte](https://npm.im/@astrojs/renderer-svelte), [Vue](https://npm.im/@astrojs/renderer-vue), and [Preact](https://npm.im/@astrojs/renderer-preact) are all built-in to Astro and supported out of the box. No configuration is needed to enable these.
-
-Internally, each framework is supported via a framework **renderer.** A renderer is a type of Astro plugin that adds support for a framework. Some are built-in, but you can also provide your own third-party renderers to add Astro support for new frameworks.
-
-## What is a renderer?
-
-A renderer is an NPM package that has two responsibilities:
-
-1. _render a component to a static string of HTML_ at build time.
-2. _rehydrate that HTML to create an interactive component_ on the client.
-
-Take a look at any one of Astro's built-in [`renderers`](https://github.com/withastro/astro/tree/main/packages/renderers) to see this in action. We'll go into more detail in the following sections.
-
-## Building Your Own Renderer
-
-> **Building a renderer?** We'd love for you to contribute renderers for popular frameworks back to the Astro repo. Feel free to open an issue or pull request to discuss.
-
-A simple renderer only needs a few files:
-
-```
-/my-custom-renderer/
-├── package.json
-├── index.js
-├── server.js
-└── client.js
-```
-
-### Package Manifest (`package.json`)
-
-A renderer should include any framework dependencies as package dependencies. For example, `@astrojs/renderer-react` includes `react` & `react-dom` as dependencies in the `package.json` manifest.
-
-```js
-// package.json
-"name": "@astrojs/renderer-react",
-"dependencies": {
-  "react": "^17.0.2",
-  "react-dom": "^17.0.2"
-}
-```
-
-This means that Astro users don't need to install the UI framework packages themselves. The renderer is the only package that your users will need to install.
-
-### Renderer Entrypoint (`index.js`)
-
-The main entrypoint of a renderer is a simple JS file which exports a manifest for the renderer. The required values are `name`, `server`, and `client`.
-
-Additionally, this entrypoint can define a [Vite config object](https://vitejs.dev/config/) that should be used to load non-JavaScript files.
-
-```js
-import myVitePlugin from 'vite-plugin-myplugin';
-
-export default {
-  name: '@astrojs/renderer-xxx', // the renderer name
-  client: './client.js', // relative path to the client entrypoint
-  server: './server.js', // (optional) relative path to the server entrypoint
-  viteConfig(options = { mode: 'development', command: 'serve' }) {
-    // (optional) return config object for Vite (https://vitejs.dev/config/)
-    return {
-      plugins: [myVitePlugin()], // tip: usually this will depend on a Vite plugin
-      optimizeDeps: {
-        include: ['my-client-dep'], // tip: it’s always a good idea to specify any client-side hydration deps here
-      },
-      ssr: {
-        external: ['my-client-dep/node/server.js'], // tip: use ssr.external in case you encounter code meant only for Node
-      },
-    };
-  },
-  polyfills: ['./shadow-dom-polyfill.js'], // (optional) scripts that should be injected on the page for the component
-  hydrationPolyfills: ['./hydrate-framework.js'], // (optional) polyfills that need to run before hydration ever occurs
-  jsxImportSource: 'preact', // (optional) the name of the library from which JSX is imported ("react", "preact", "solid-js", etc.)
-  jsxTransformOptions: async (options = { mode: 'development', ssr: true }) => {
-    // (optional) a function to transform JSX files
-    const {
-      default: { default: jsx },
-    } = await import('@babel/plugin-transform-react-jsx');
-    return {
-      plugins: [jsx({}, { runtime: 'automatic', importSource: 'preact' })],
-    };
-  },
-};
-```
-
-### JSX Support
-
-Astro is unique in that it allows you to mix multiple types of JSX/TSX files in a single project. It does this by reading the `jsxImportSource` and `jsxTransformOptions` from renderers and transforming a file with [Babel](https://babeljs.io/).
-
-#### `jsxImportSource`
-
-This is the name of your library (for example `preact` or `react` or `solid-js`) which, if encountered in a file, will signal to Astro that this renderer should be used.
-
-Users may also manually define `/** @jsxImportSource preact */` in to ensure that the file is processed by this renderer (if, for example, the file has no imports).
-
-#### `jsxTransformOptions`
-
-This is an `async` function that returns information about how to transform matching JSX files with [Babel](https://babeljs.io/). It supports [`plugins`](https://babeljs.io/docs/en/plugins) or [`presets`](https://babeljs.io/docs/en/presets) to be passed directly to Babel.
-
-> Keep in mind that this transform doesn't need to handle TSX separately from JSX, Astro handles that for you!
-
-`jsxTransformOptions` receives context about whether it’s running in `development` or `production` mode, as well as whether or not it’s running in SSR or client hydration. These allow you to pass separate Babel configurations for various conditions, like if your files should be compiled differently in SSR mode.
-
-```ts
-export interface JSXTransformOptions {
-  (context: {
-    /** "development" or "production" */
-    mode: string;
-    /** True if builder is in SSR mode */
-    ssr: boolean;
-  }) => {
-    plugins?: any[];
-    presets?: any[];
-  }
-}
-```
-
-### Server Entrypoint (`server.js`)
-
-The server entrypoint of a renderer is responsible for checking if a component should use this renderer, and if so, how that component should be rendered to a string of static HTML.
-
-```js
-export default {
-  // should Component use this renderer?
-  check(Component, props, childHTML) {},
-  // Component => string of static HTML
-  renderToStaticMarkup(Component, props, childHTML) {},
-};
-```
-
-#### `check`
-
-`check` is a function that determines whether a Component should be "claimed" by this renderer.
-
-In its simplest form, it can check for the existence of a flag on Object-based components.
-
-```js
-function check(Component) {
-  return Component.isMyFrameworkComponent;
-}
-```
-
-In more complex scenarios, like when a Component is a `Function` without any flags, you may need to use `try/catch` to attempt a full render. This result is cached so that it only runs once per-component.
-
-```js
-function check(Component, props, childHTML) {
-  try {
-    const { html } = renderToStaticMarkup(Component, props, childHTML);
-    return Boolean(html);
-  } catch (e) {}
-  return false;
-}
-```
-
-#### `renderToStaticMarkup`
-
-`renderToStaticMarkup` is a function that renders a Component to a static string of HTML. There's usually a method exported by frameworks named something like `renderToString`.
-
-```js
-import { h, renderToString } from 'xxx';
-
-function renderToStaticMarkup(Component, props, childHTML) {
-  const html = renderToString(h(Component, { ...props, innerHTML: childHTML }));
-  return { html };
-}
-```
-
-Note that `childHTML` is an HTML string representing this component's children. If your framework does not support rendering HTML directly, you are welcome to use a wrapper component. By convention, Astro uses the `astro-fragment` custom element to inject `childHTML` into. Your renderer should use that, too.
-
-```js
-import { h, renderToString } from 'xxx';
-
-const Wrapper = ({ value }) =>
-  h('astro-fragment', { dangerouslySetInnerHTML: { __html: value } });
-
-function renderToStaticMarkup(Component, props, childHTML) {
-  const html = renderToString(
-    h(Component, props, h(Wrapper, { value: childHTML }))
-  );
-  return { html };
-}
-```
-
-The `renderToStaticMarkup` function also supports `async/await` for render functions that return a `Promise`.
-
-```js
-import { h, renderToString } from 'xxx';
-
-async function renderToStaticMarkup(Component, props, childHTML) {
-  const html = await renderToString(
-    h(Component, { ...props, innerHTML: childHTML })
-  );
-  return { html };
-}
-```
-
-### Client Entrypoint (`client.js`)
-
-The client entrypoint of a renderer is responsible for rehydrating static HTML (the result of `renderToStaticMarkup`) back into a fully interactive component. Its `default` export should be a `function` which accepts the host element of the Component, an `astro-root` custom element.
-
-> If your framework supports non-destructive component hydration (as opposed to a destructive `render` method), be sure to use that! Following your framework's Server Side Rendering (SSR) guide should point you in the right direction.
-
-```js
-import { h, hydrate } from 'xxx';
-
-export default (element) => {
-  return (Component, props, childHTML) => {
-    hydrate(h(Component, { ...props, innerHTML: childHTML }), element);
-  };
-};
-```
-
-Note that `childHTML` is an HTML string representing this component's children. If your framework does not support rendering HTML directly, you should use the same wrapper component you used for the server entrypoint.
-
-```js
-import { h, hydrate } from 'xxx';
-import SharedWrapper from './SharedWrapper.js';
-
-export default (element) => {
-  return (Component, props, childHTML) => {
-    hydrate(
-      h(Component, props, h(SharedWrapper, { value: childHTML })),
-      element
-    );
-  };
-};
-```
--- a/docs/src/pages/en/themes.astro
+++ b/docs/src/pages/en/themes.astro
@ -1,53 +0,0 @@
---
-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';
---
-
-<Layout content={{ title: 'Themes' }} hideRightSidebar>
-	<style>
-		.card-grid {
-			display: grid;
-			grid-column-gap: 15px;
-			grid-row-gap: 15px;
-			grid-auto-flow: dense;
-			grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
-		}
-	</style>
-	<Markdown>
-		## Featured Theme
-	</Markdown>
-	<div class="card-grid">
-		{themes.featured.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		## Official Themes
-
-		Astro maintains several official themes for documentation sites, portfolios, and more.
-	</Markdown>
-	<div class="card-grid">
-		{themes.official.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		## Community Themes
-
-		Checkout some themes developed by our community!
-	</Markdown>
-	<div class="card-grid">
-		{themes.community.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		## Featured Packages
-
-		Our package ecosystem is growing! Check out these featured community packages. Search the entire collection [on npm.](https://www.npmjs.com/search?q=keywords%3Aastro-component)
-	</Markdown>
-	<div class="card-grid">
-		{components.community.map((item) => <Card data={item} />)}
-	</div>
-	<Markdown>
-		> Want to see your own work featured? [Share it to Discord!](https://astro.build/chat)
-		> We'll often take our favorites from the `#showcase` channel and post them here.
-	</Markdown>
-</Layout>
--- a/docs/src/pages/es/comparing-astro-vs-other-tools.md
+++ b/docs/src/pages/es/comparing-astro-vs-other-tools.md
@ -1,233 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Astro versus X
-lang: es
---
-
-Con frecuencia nos preguntamos, "¿Cómo se comporta Astro en comparación a mi generador de páginas web favorito, **\_\_\_\_**?". Esta guía fue escrita para responder a esa pregunta, al comparar varios generadores de páginas web y alternativas a Astro.
-
-Si no ves tu generador de páginas web favorito en la lista, [pregúntanos en Discord.](https://astro.build/chat)
-
-## Estado del Proyecto
-
-Una nota rápida sobre la madurez del proyecto: **Astro aún se encuentra en beta.** Muchas de las herramientas listadas aquí son mucho más maduras. !Algunas tienen más de 12 años en comparación a Astro!
-
-Algunas características, aunque son pocas, aún no están disponibles en Astro y algunas APIs aún no están terminadas. Sin embargo, el proyecto se considera estable desde un punto de vista de los errores; además, ya se han construido muchas páginas web usando Astro. Esto es un punto importante a considerar al momento de escoger a Astro.
-
-## Docusaurus vs. Astro
-
-[Docusaurus](https://docusaurus.io/) es un popular generador de sitios web sobre documentación. Docusaurus desarrollado por React para generar tu UI del sitio web; mientras que Astro soporta React, Vue.js, Svelte, y plantillas HTML.
-
-Docusaurus fue diseñada para construir la documentación de las páginas web y tienen una creación propia y unas características específicas de documentación que Astro no posee. En lugar de eso, Astro ofrece características específicas de documentación mediante un tema oficial [`docs`](https://github.com/withastro/astro/tree/main/examples/docs) que puedes utilizar en tu sitio. !Este sitio web se construyó usando ese tema!
-
-#### Comparando el Rendimiento de Docusaurus vs. Astro
-
-En la mayoría de casos, los sitios web de Astro cargarán mucho más rápido que los sitios web de Docusaurus. Esto es porque Astro automáticamente quita el código JavaScript innecesario de la página, cargando sólo los componentes individuales que la página que necesita. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
-
-Docusaurus no soporta hidratación parcial, en lugar de eso, hace que el usuario cargue y rehidrata la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un peor rendimiento para tu sitio web. No hay manera de deshabilitar este comportamiento en Docusaurus.
-
-#### Caso de Estudio: Documentando un sitio web
-
-[docusaurus.io/docs](https://docusaurus.io/docs) es la documentación oficial de Docusaurus y está construida con Docusaurus. El sitio web ofrece unas características similares en su diseño y funcionalidad al compararla con documentación oficial de Astro. Esto nos da una **_vista detallada y realista_** entre los dos generadores de sitios web.
-
- **Puntaje de rendimiento de Docusaurus**: 61 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocusaurus.io%2Fdocs)
- **Puntaje de rendimiento de Astro**: 99 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Una de las más grandes razones detrás de la diferencia en los rendimientos es que la carga de Javascript en Astro es el poco tiempo de carga de Javascropt en Astro: [docusaurus.io/docs](https://docusaurus.io/docs) carga **238kb** de Javascript en la primera carga; mientras que [docs.astro.build](https://docs.astro.build/es/getting-started) carga **78.7kb** (en general, 67% menos de JavaScript) _después_ de la primera carga.
-
-## Elder.js vs. Astro
-
-[Elder.js](https://elderguide.com/tech/elderjs/) es un dogmático generador de sitios web estáticos de código abierto que desarrollado para Svelte.
-
-Elder.js utiliza Svelte para generar tu sitio web. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
-
-Elder.js es el único en esta lista, junto con Astro, que soporta [hidratación parcial](/es/core-concepts/component-hydration). Astro y Elder.js automáticamente quitan el código JavaScript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Elder.js tiene una API de hidratación parcial un poco diferente, pero Astro soporta algunas características que Elder.js no soporta (como `client:media`). Sin embargo, ambos generadores de sitios web construyen sitios web similares en temas de rendimiento.
-
-Elder.js utiliza una solución de rutas personalizadas que puede sentirse poco familiar para los nuevos desarrolladores. Astro utiliza [rutas basadas en archivos](/es/core-concepts/routing) que debería sentirse familiar a todos los desarrolladores que han visto Next.js, SvelteKit y otros generadores de sitios web estáticos como Eleventy.
-
-Elder.js fue diseñado para correr en sitios web grandes y afirma que puede construir un sitio web de 20 mil páginas en menos de 10 minutos (en una modesta máquina virtual). Al momento de escribir esto, Astro construye mil páginas en 66 segundos, pero aún no ha sido probado en proyectos de más de 20 mil páginas. Astro está aún en la fase inicial y la meta para Astro v1.0 es alcanzar la velocidad de construcción sitios web de Elder.js.
-
-Elder.js soporta tanto Static Site Generation (SSG) como Server-Side Rendering (SSR). Hoy en día, Astro tan sólo soporta Static Site Generation (SSG).
-
-## Eleventy vs. Astro
-
-[Eleventy](https://www.11ty.dev/) es un popular creador de sitios estáticos desarrollado por Node.js.
-
-Eleventy utiliza mucho [plantillas de lenguaje HTML antiguas](https://www.11ty.dev/docs/languages/) para renderizar tu sitio web: Nunjucks, Liquid, Pug, EJS, entre otros. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
-
-#### Comparando el Rendimiento de Eleventy vs. Astro
-
-Conceptualmente, Eleventy está alineado con el enfoque de Astro sobre "el uso mínimo de Javascript en el lado del cliente". Tanto Eleventy y Astro ofrecen un rendimiento similar, un uso extremadamente bajo de Javascript por defecto.
-
-Eleventy alcanza este punto al empujarte a evitar usar Javascript. Los sitios de Eleventy son escritos, con frecuencia, con poco o ninguna línea de Javascript. Esto se convierte en un problema cuando necesitas Javascript en el lado del cliente. Es tu responsabilidad crear tu propia línea de construcción de recursos para Eleventy. Esto puede ser una tarea difícil y te obliga a configurar una gran cantidad de optimizaciones, como la fusión de archivos, la minificación y otros.
-
-Por otro lado, Astro automáticamente construye el CSS y Javascript en el lado del cliente por ti. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Está funcionalidad se llama [hidratación parcial](/es/core-concepts/component-hydration). Mientras que en Eleventy lo puedes alcanzar esto por ti mismo; Astro la ofrece desde el inicio y sin configuración extra.
-
-## Gatsby vs. Astro
-
-[Gatsby](https://www.gatsbyjs.com/) es una popular página web y framework de React.
-
-Gatsby utiliza React para renderizar tu sitio web. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid, entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
-
-Gatsby v4 soporta tanto Static Site Generation (SSG) como Server-Side Rendering (SSR). Hoy en día, Astro tan sólo soporta Static Site Generation (SSG).
-
-Gatsby requiere de una API personalizada de GraphQL para trabajar con todo el contenido de tu sitio web. Aunque algunos desarrolladores disfrutan de este modelo, una crítica común a Gatsby es que este modelo se vuelve demasiado complejo y difícil de mantener en el tiempo, especialmente cuando las páginas crecen. Astro no requiere una API de GraphQL, en su lugar ofrece apoyos para API familiares (como `fetch()` y `await`) para la carga de datos cuando se necesite.
-
-#### Comparando el Rendimiento de Gatsby vs. Astro
-
-En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Gatsby. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
-
-Gatsby no soporta la hidratación parcial. En su lugar, hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido es estático. Esto hace que las páginas carguen más lentamente y que el rendimiento sea más bajo para tu sitio web. Gatsby tiene [un plugin comunitario](https://www.gatsbyjs.com/plugins/gatsby-plugin-no-javascript/) para remover todo el Javascript de la página, pero esto rompería muchos sitios web. Esto le queda a usted con una decisión de todo-o-nada para la interactividad en cada una de las páginas.
-
-Gatsby tiene un gran ecosistema de plugins, el cual podría hacer que Gatsby sea una gran opción para tu proyecto dependiendo de tus necesidades. [gatsby-plugin-image](https://www.gatsbyjs.com/plugins/gatsby-plugin-image/) es un popular plugin para optimizar imágenes, esto podría convertir a Gatsby en una mejor opción para algunas páginas con muchas imágenes.
-
-#### Caso de Estudio: Documentando un sitio web
-
-[gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) es la documentación oficial de Gatsby, construida con Gatsby. El sitio web ofrece una interfaz similar y un conjunto de características a comparar con la documentación oficial de Astro. Esto nos da una **_vista detallada y realista_** entre los dos generadores de sitios web.
-
- **Puntaje de rendimiento de Gatsby**: 64 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwww.gatsbyjs.com%2Fdocs%2Fquick-start%2F)
- **Puntaje de rendimiento de Astro**: 99 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Una de las más grandes razones detrás de la diferencia en los rendimientos es que la carga de Javascript en Astro es el poco tiempo de carga de Javascropt en Astro: [gatsbyjs.com/docs](https://www.gatsbyjs.com/docs/quick-start/) carga **417kb** de Javascript en la primera carga; mientras que [docs.astro.build](https://docs.astro.build/es/getting-started) loads **78.7kb** (en general, 81% menos de JavaScript) _después_ de la primera carga.
-
-## Hugo vs. Astro
-
-[Hugo](https://gohugo.io/) es un generador de sitios web estático desarrollado por Go.
-
-Hugo utiliza una [plantilla de lenguajes personalizados](https://gohugo.io/templates/introduction/) para renderizar tu sitio web. Astro te deja crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid, entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
-
-#### Comparando el Rendimiento de Hugo vs. Astro
-
-Conceptualmente, Hugo está alineado con el enfoque de Astro sobre "el uso mínimo de Javascript en el lado del cliente". Tanto Hugo y Astro ofrecen un rendimiento similar, un uso extremadamente bajo de Javascript por defecto.
-
-Tanto Hugo como Astro, traen incorporado soporte para la construcción, el empaquetado y la minificación de JavaScript. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration). Mientras que esto lo puedes hacer en Hugo por ti mismo, Astro lo ofrece incorporado por defecto.
-
-## Jekyll vs. Astro
-
-[Jekyll](https://jekyllrb.com/) es un popular generador de sitios estáticos, desarrollado por Ruby.
-
-Jekyll utiliza una vieja versión de [lenguaje de plantillas](https://jekyllrb.com/docs/liquid/) para renderizar tu sitio web. Astro te permite crear páginas usando una interfaz de usuario de librerías de componentes (React, Preact, Vue, Svelte, entre otros otros) o una sintaxis de componente similar a HTML + JSX. Jekyll no soporta la utilización de componentes modernos para las plantillas de HTML.
-
-#### Comparando el Rendimiento de Jekyll vs. Astro
-
-Conceptualmente, Eleventy está alineado con el enfoque de Astro sobre "el uso mínimo de Javascript en el lado del cliente". Tanto Jekyll y Astro ofrecen un rendimiento similar, un uso extremadamente bajo de Javascript por defecto.
-
-Jekyll alcanza este punto porque no permite que el usuario cargue Javascript. Los sitios Jekyll son frecuentemente escritos con poco a ningún Javascript, en su lugar promueven el renderizado de HTML en el lado del servidor. Esto se convierte en un problema cuando necesitas utilizar JavaScript en el lado del cliente. Es tu responsabilidad crear tu propia cadena de procesos de construcción para Jekyll. Esto consume mucho de tu tiempo y te obliga a configurar la empaquetación, la minificación y otras optimizaciones por ti mismo.
-
-En contraste, Astro automáticamente construye el Javascript del lado del cliente para ti. Astro sólo envía el mínimo de Javascript al navegador, minificado, empaquetado y optimizado para producción. Esto puede ser posible por ti mismo en Jekyll, pero con Astro esto se hace por defecto.
-
-## SvelteKit vs. Astro
-
-[SvelteKit](https://kit.svelte.dev/) es un popular sitio web y un marco de trabajo para Svelte.
-
-SeveltKit utiliza Svelte para renderizar tu sitio web. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid, entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
-
-Tanto SveltKit como Astro, son estructuras o frameworks para crear sitios web. SvelteKit funciona mejor con sitios web altamente dinámicos (como tableros y bandejas de entradas); mientras que Astro funciona mejor con sitios altamente estáticos (como contenido web y sitios de comercio electrónico).
-
-SvelteKit soporta tanto Static Site Generation (SSG) como Server-Side Rendering (SSR). Hoy en día, Astro tan sólo soporta Static Site Generation (SSG).
-
-#### Comparando el Rendimiento de SveltKit vs. Astro
-
-En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de SveltKit. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
-
-SveltKit no soporta la hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. SveltKit ofrece soporte para [páginas estáticas, con cero JavaScript](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate). Sin embargo, en su página no hay planificación para realizar la hidratación parcial de componentes individuales. Por lo tanto, queda a tu criterio tomar la decisión de todo-o-nada en la interactividad de cada página.
-
-#### Caso de Estudio: Documentando un sitio web
-
-[kit.svelte.dev](https://kit.svelte.dev/docs#ssr-and-javascript-hydrate) es el sitio oficial de SvelteKit, está construido con SvelteKit. El sitio web ofrece una interfaz similar y un conjunto de características a comparar con la documentación oficial de Astro. Esto nos da una **_vista detallada y realista_** entre los dos generadores de sitios web.
-
-Una notable diferencia entre los dos sitios web que se están probando: es que la documentación de SvelteKit se proporciona como una sola página, mientras que la documentación de Astro se divide en múltiples páginas. Este mayor contenido debería tener un impacto negativo en el rendimiento que no está relacionado con la herramienta en sí misma.
-
- **Puntaje de rendimiento de SveltKit**: 92 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fkit.svelte.dev%2Fdocs)
- **Puntaje de rendimiento de Astro**: 99 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-El rendimiento de SvelteKit fue muy similar al de Astro en esta prueba.
-
-## Next.js vs. Astro
-
-[Next.js](https://nextjs.org/) es una popular y un framework para React.
-
-Next.js utiliza React para renderizar tu sitio web. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid, entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
-
-Tanto Next.js como Astro, son frameworks para crear sitios web. Nesxt.js funciona mejor en sitios web altamente dinámicos (como tableros y bandejas de entradas); mientras que Astro funciona mejor con sitios altamente estáticos (como contenido web y sitios de comercio electrónico).
-
-Next.js soporta tanto Static Site Generation (SSG) como Server-Side Rendering (SSR). Hoy en día, Astro tan sólo soporta Static Site Generation (SSG).
-
-#### Comparando el Rendimiento de Gatsby vs. Astro
-
-En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Next.js. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
-
-Next.js no soporta hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. Next.js ofrece un [ soporte experimental](https://piccalil.li/blog/new-year-new-website/#heading-no-client-side-react-code) para sitios completamente estáticos con cero Javascript. Sin embargo, en su página no hay planificación para realizar la hidratación parcial de componentes individuales. Por lo tanto, queda a tu criterio tomar la decisión de todo-o-nada en la interactividad de cada página.
-
-Next.js tiene un gran soporte para optimizar imágenes, lo que podría hacer que Next.js sea una buena opción para sitios web con muchas imágenes.
-
-#### Caso de Estudio: Documentando un sitio web
-
-[nextjs.org/docs](https://nextjs.org/docs/getting-started) es la página oficial de Next.js, está construida con Next.js. El sitio web ofrece una interfaz similar y un conjunto de características a comparar con la documentación oficial de Astro. Esto nos da una **_vista detallada y realista_** entre los dos generadores de sitios web.
-
- **Puntaje de rendimiento de Next.js**: 59 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnextjs.org%2Fdocs%2Fgetting-started)
- **Puntaje de rendimiento de Astro**: 99 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Una razón de peso por lo que se produce esta diferencia de rendimiento es que Astro tiene una menor carga de JavaScript: [nextjs.org/docs](https://nextjs.org/docs/getting-started) carga **463kb** de JavaScript en la primera carga de la página, mientras que [docs.astro.build](https://docs.astro.build/es/getting-started) carga **78.7kb** (en general, 83% menos de JavaScript) _después_ de la primera carga.
-
-## Nuxt vs. Astro
-
-[Nuxt](https://nuxtjs.org/) es una popular página web y un framework para Vue. Es similar a Next.js
-
-Nuxt utiliza Vue para renderizar tu sitio web. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid, entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX.
-
-Tanto Nuxt como Astro, son frameworks para crear sitios web. Nuxt funciona mejor con sitios web altamente dinámicos (como tableros y bandejas de entradas); mientras que Astro funciona mejor con sitios altamente estáticos (como contenido web y sitios de comercio electrónico).
-
-Nuxt soporta tanto Static Site Generation (SSG) como Server-Side Rendering (SSR). Hoy en día, Astro tan sólo soporta Static Site Generation (SSG).
-
-#### Comparando el Rendimiento de Nuxt vs. Astro
-
-En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de Nuxt. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
-
-Nuxt no soporta hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. No hay forma de deshabilitar este comportamiento en Nuxt.
-
-Nuxt tiene un gran soporte para optimizar imágenes, lo que podría hacer que Nuxt sea una buena opción para sitios web con muchas imágenes.
-
-#### Caso de Estudio: Documentando un sitio web
-
-[nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) es la documentación oficial de Nuxt, construida con Gatsby. El sitio web ofrece una interfaz similar y un conjunto de características a comparar con la documentación oficial de Astro. Esto nos da una **_vista detallada y realista_** entre los dos generadores de sitios web.
-
- **Puntaje de rendimiento de Nuxt**: 48 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fnuxtjs.org%2Fdocs%2F2.x%2Fget-started%2Finstallation)
- **Puntaje de rendimiento de Astro**: 99 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Una de las más grandes razones detrás de la diferencia en los rendimientos es que la carga de Javascript en Astro es el poco tiempo de carga de Javascropt en Astro: [nuxtjs.org/docs](https://nuxtjs.org/docs/2.x/get-started/installation) carga **469kb** de Javascript en la primera carga; mientras que [docs.astro.build](https://docs.astro.build/es/getting-started) loads **78.7kb** (en general, 83% menos de JavaScript) _después_ de la primera carga.
-
-## VuePress vs. Astro
-
-[VuePress](https://vuepress.vuejs.org/guide/) es un constructor de documentación de sitios web, desarrollado por los creadores de Vue.js. VuePress utiliza Vue.js para generar la interfaz de usuario de tu sitio web, mientras que Astro soporta React, Vue.js, Svelte, y plantillas HTML.
-
-VuePress fue diseñado para documentar sitios web y tiene funcionalidades y características propias que Astro no soporta por defecto. En su lugar, Astro ofrece características específicas de documentación mediante un tema oficial [`docs`](https://github.com/withastro/astro/tree/main/examples/docs), el cual puedes usar para tu sitio web. !Este sitio web fue construido usando ese tema!
-
-Actualmente, Evan You (creador de Vue.js) está trabajando en una nueva versión de Vuepress llamado [VitePress.](https://vitepress.vuejs.org/). Si quieres conocer una moderna alternativa a VuePress, [revisa este post de Evan](https://github.com/withastro/astro/issues/1159#issue-974035962) del porqué VitePress podría ser una mejor opción.
-
-#### Comparando el VuePress de Gatsby vs. Astro
-
-En la mayoría de casos, los sitios de Astro cargarán mucho más rápido que los sitios de VuePress. Esto pasa porque Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration).
-
-VuePress no soporta hidratación parcial, en su lugar hace que el usuario cargue e hidrate la página completa en el navegador, incluso si la mayoría del contenido de la página es estático. Esto crea una carga de página más lenta y un rendimiento inferior para tu sitio web. No hay forma de deshabilitar este comportamiento en VuePress.
-
-#### Caso de Estudio: Documentando un sitio web
-
-[vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) es la documentación oficial de VuePress, construida con VuePress. El sitio web ofrece una interfaz similar y un conjunto de características a comparar con la documentación oficial de Astro. Esto nos da una **_vista detallada y realista_** entre los dos generadores de sitios web.
-
- **Puntaje de rendimiento de Vuepress**: 63 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fvuepress.vuejs.org%2Fguide%2F)
- **Puntaje de rendimiento de Astro**: 99 de 100 [(ver detalles)](https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fdocs.astro.build%2Fgetting-started)
-
-Una de las más grandes razones detrás de la diferencia en los rendimientos es que la carga de Javascript en Astro es el poco tiempo de carga de Javascropt en Astro: [vuepress.vuejs.org](https://vuepress.vuejs.org/guide/) carga **166kb** de Javascript en la primera carga; mientras que [docs.astro.build](https://docs.astro.build/es/getting-started) loads **78.7kb** (en general, 53% menos de JavaScript) _después_ de la primera carga.
-
-## Zola vs. Astro
-
-[Zola](https://www.getzola.org/) es un popular y rápido generador de sitios estáticos, desarrollado por Rust.
-
-Zola utiliza [Tera](https://tera.netlify.app/) para renderizar tu sitio web. Astro es más flexible: eres libre de crear un componente UI en cualquier librería popular (React, Preact, Vue, Svelte, Solid, entre otros) o puedes crear un componente de Astro con una sintaxis parecida a HTML, que es similar a HTML + JSX. Zola no soporta el uso de componentes modernos para plantillas HTML.
-
-#### Comparando el Rendimiento de Gatsby vs. Astro
-
-Conceptualmente, Zola está alineado con el enfoque de Astro sobre "el uso mínimo de Javascript en el lado del cliente". Tanto Zola y Astro ofrecen un rendimiento similar, un uso extremadamente bajo de Javascript por defecto.
-
-Astro ofrece soporte para construir, empaquetar y minimizar JavaScript. Zola requiere usar otra herramienta de construcción como Webpack para empaquetar y procesar JavaScript. Astro automáticamente quita el código Javascript innecesario de la página, cargando sólo los componentes individuales que se necesiten. Esta característica se llama [hidratación parcial](/es/core-concepts/component-hydration). Mientras que Zola puedes hacerlo por ti mismo, Astro lo ofrece incorporado por defecto.
--- a/docs/src/pages/es/core-concepts/astro-components.md
+++ b/docs/src/pages/es/core-concepts/astro-components.md
@ -1,379 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Componentes de Astro
-lang: es
---
-
-Los **componentes de Astro** (archivos que terminan con `.astro`) son la base de las plantillas del lado del servidor en Astro. Piensa en la sintaxis del componente Astro como HTML mejorado con JavaScript.
-
-Aprender una nueva sintaxis puede ser intimidante, por lo que cuidadosamente diseñamos la sintaxis del componente Astro para que los desarrolladores web se familizarizen lo más pronto posible. En gran medida se basa en patrones que probablemente ya conozcas: componentes, portada, propiedades y expresiones JSX. Estamos seguros de que esta guía te permitirá escribir componentes de Astro en poco tiempo, especialmente si ya estás familiarizado con HTML y JavaScript.
-
-## Visión general de la sintaxis
-
-Un único archivo `.astro` representa un solo componente Astro en tu proyecto. Este patrón se conoce como **Componente de archivo único (SFC, del inglés Single-File Component)**. Tanto Svelte (`.svelte`) como Vue (`.vue`) también siguen este patrón.
-
-A continuación se muestra un recorrido por las diferentes piezas y características de la sintaxis del componente Astro. Puedes leerlo de principio a fin o saltar entre secciones.
-
-### Plantilla HTML
-
-La sintaxis del componente Astro es un superconjunto de HTML. **Si conoces HTML, ya sabes lo suficiente como para escribir tu primer componente Astro.**
-
-Por ejemplo, este archivo de tres líneas es un componente Astro válido:
-
-```html
-<!-- Ejemplo1.astro - ¡El HTML estático es un componente Astro válido! -->
-<div class="ejemplo-1">
-  <h1>¡Hola mundo!</h1>
-</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-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.
-
-### Estilos CSS
-
-Las reglas CSS dentro de una etiqueta `<style>` se ajustan automáticamente a ese componente. Eso significa que puedes reutilizar los nombres de las clases en varios componentes, sin preocuparse por los conflictos. Los estilos se extraen y optimizan automáticamente en la compilación final para que no tengas que preocuparte por la carga de estilos.
-
-Para obtener los mejores resultados, solo debes tener una etiqueta `<style>` por componente Astro. Esto no es necesariamente una limitación, pero a menudo dará como resultado un CSS mejor optimizado en su compilación final. Cuando trabajas con páginas, la etiqueta `<style>` puede ir anidada dentro de tu página `<head>`. Para los componentes independientes, la etiqueta `<style>` puede ir al nivel superior de su plantilla.
-
-```html
-<!-- Ejemplo de CSS del componente Astro -->
-<style>
-  .circle {
-    background-color: red;
-    border-radius: 999px;
-    height: 50px;
-    width: 50px;
-  }
-</style>
-<div class="circle"></div>
-```
-
-```html
-<!-- Ejemplo de CSS de Astro Page -->
-<html>
-  <head>
-    <style>
-      ...;
-    </style>
-  </head>
-  <body>
-    ...
-  </body>
-</html>
-```
-
-El uso de `<style global>` omitirá el alcance automático para cada regla CSS en el bloque `<style>`. Esta trampilla de escape debe evitarse si es posible, pero puede ser útil si, por ejemplo, necesitas modificar el estilo de los elementos HTML agregados por una librería externa.
-
-Sass (una alternativa a CSS) está también disponible mediante `<style lang="scss">`.
-
-📚 Lee nuestra guía completa sobre [Estilo de los componentes](/es/guides/styling) para obtener más información.
-
-### Script preliminar
-
-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-concepts/component-hydration) como React, Svelte, Vue, etc.
-
-```astro
---
-// Todo lo que esté dentro de la valla de código `---` es el script de tu componente.
-// Este código JavaScript se ejecuta en tiempo de compilación.
-// Consulte a continuación para obtener más información sobre lo que puede hacer.
-console.log('Esto se ejecuta en el momento de la compilación, es visible en la salida CLI');
-// Consejo: ¡TypeScript también es compatible de forma inmediata!
-const thisWorks: number = 42;
---
-<div class="ejemplo-1">
-  <h1>¡Hola mundo!</h1>
-</div>
-```
-
-### Importaciones de componentes
-
-Un componente Astro puede reutilizar otros componentes de Astro dentro de su plantilla HTML. Esto se convierte en la base de nuestro sistema de componentes: crea nuevos componentes y luego reutilízalos en todo tu proyecto.
-
-Para utilizar un componente Astro en tu plantilla, primero debes importarlo en el script preliminar del componente. Un componente Astro es siempre la importación predeterminada del archivo.
-
-Una vez importado, puedes usarlo como cualquier otro elemento HTML en tu plantilla. Ten en cuenta que un componente de Astro **DEBE** comenzar con una letra mayúscula. Astro usará esto para distinguir entre elementos HTML nativos (`from`,` input`, etc.) y tus componentes de Astro personalizados.
-
-```astro
---
-// Importa tus componentes en tu script del componente
-import AlgunComponente from './AlgunComponente.astro';
---
-<!-- ... ¡luego utilízalos en su HTML! -->
-<div>
-  <AlgunComponente />
-</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-concepts/component-hydration) para obtener más información.
-
-### Expresiones JSX dinámicas
-
-En lugar de inventar nuestra propia sintaxis personalizada para la creación de plantillas dinámicas, te brindamos acceso directo a los valores de JavaScript dentro de su HTML, utilizando algo que se parece a [JSX](https://reactjs.org/docs/introducing-jsx.html) .
-
-Los componentes de Astro pueden definir variables locales dentro del script de Frontmatter. Todas las variables de secuencia de comandos están disponibles automáticamente en la plantilla HTML a continuación.
-
-#### Dynamic Values
-
-```astro
---
-const nombre = "Tu nombre aquí";
---
-<div>
-  <h1>¡Hola {nombre}!</h1>
-</div>
-```
-
-#### Atributos dinámicos
-
-```astro
---
-const nombre = "Tu nombre aquí";
---
-<div>
-  <div data-nombre={nombre}>Se admiten expresiones de atributo</div>
-  <div data-consejo={`Utilice cadenas de plantilla JS para mezclar ${"variables"}.`}>¡Qué bueno!</div>
-</div>
-```
-
-#### HTML Dinámico
-
-```astro
---
-const elementos = ["Perro", "Gato", "Ornitorrinco"];
---
-<ul>
-  {elementos.map((elemento) => (
-    <li>{elemento}</li>
-  ))}
-</ul>
-```
-
-### Propiedades del Componente
-
-Un componente Astro puede definir y aceptar propiedades. Las propiedades están disponibles en el global `Astro.props` en su script preliminar.
-
-```astro
---
-// Ejemplo: <AlgunComponente saludo="(Opcional) Hola" name="Nombre requerido" />
-const { saludo = 'Hola', nombre } = Astro.props;
---
-<div>
-    <h1>¡{saludo}, {nombre}!</h1>
-</div>
-```
-
-Puedes definir tus propiedades con TypeScript exportando un `Props` de tipo _interface_.
-
-> _**En el futuri**_, Astro recogerá automáticamente cualquier interfaz de `Props` exportada y dará advertencias/errores de tipo para su proyecto.
-
-```astro
---
-// Ejemplo: <AlgunComponente />  (CUIDADO: propiedad "nombre" obligatoria)
-export interface Props {
-  nombre: string;
-  saludo?: string;
-}
-const { saludo = 'Hola', nombre } = Astro.props;
---
-<div>
-    <h1>¡{saludo}, {nombre}!</h1>
-</div>
-```
-
-Luego puede pasar las propiedades del componente de esta manera:
-
-```astro
---
-// AlgunOtroCompoennte.astro
-import AlgunComponente from "./AlgunComponente.astro";
-let nombreDePila = "mundo";
---
-<AlgunComponente nombre={nombreDePila}/>
-```
-
-### Ranuras
-
-Los archivos `.astro` utilizan la etiqueta [`<slot>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/slot) para habilitar la composición de componentes. Viniendo de React o Preact, este es el mismo concepto que `hijos`. Puedes pensar en el elemento `<slot>` como un marcador de posición para el marcado que se pasará desde fuera del componente.
-
-```astro
-<!-- Example: MiComponente.astro -->
-<div id="mi-componente">
-  <slot /> <!-- los hijos irán aquí -->
-</div>
-
-<!-- Usage -->
-<MiComponente>
-  <h1>¡Hola mundo!</h1>
-</MiComponente>
-```
-
-Ten en cuenta que si la etiqueta `<slot>` no se usa en la plantilla HTML, los elementos secundarios pasados al componente no se procesarán.
-
-Las ranuras se vuelven aún más poderosas cuando se utilizan **ranuras con nombre **. En lugar de un solo elemento `<slot>` que representa a _todos_ los hijos, las ranuras con nombre te permiten especificar varios lugares donde los hijos deben ser colocados.
-
-> **Nora:** El atributo `slot` attribute no está restringido a HTML simple, ¡los componentes también pueden usar `slot`!
-
-```astro
-<!-- Ejemplo: MiComponente.astro -->
-<div id="mi-componente">
-  <header>
-    <!-- hijo con el atributo `slot="cabecera"` irá aquí -->
-    <slot name="cabecera" />
-  </header>
-  <main>
-    <!-- hijo sin atributo `slot` (or con el `slot="default"`) irá aquí -->
-    <slot />
-  </main>
-  <footer>
-    <!-- hijo con el atributo `slot="pie"` irá aquí  -->
-    <slot name="pie" />
-  </footer>
-</div>
-
-<!-- Usage -->
-<MiComponente>
-  <h1 slot="cabecera">¡Hola mundo!</h1>
-  <p>Lorem ipsum ...</p>
-  <FooterComponent slot="pie" />
-</MiComponente>
-```
-
-Las ranuras también pueden devolver **contenido de respaldo**. Cuando no hay hijos pasados a un `<slot>` que coincidan, un elemento `<slot>` renderizará sus propios hijos de marcador de posición.
-
-Slots can also render **fallback content**. When there are no matching children passed to a `<slot>`, a `<slot>` element will render its own children.
-
-```astro
-<!-- MiComponente.astro -->
-<div id="mi-componente">
-  <slot>
-    <h1>¡Me renderizaré cuando esta ranura no tenga hijos!</h1>
-  </slot>
-</div>
-
-<!-- Usage -->
-<MiComponente />
-```
-
-### Fragmentos y elementos múltiples
-
-Una plantilla de componente Astro puede representar tantos elementos de nivel superior como desees. A diferencia de otros frameworks de componentes de interfaz de usuario, no es necesario que envuelvas todo en un único `<div>` si prefieres no hacerlo.
-
-```html
-<!-- Un componente Astro puede contener varios elementos HTML de nivel superior: -->
-<div id="a" />
-<div id="b" />
-<div id="c" />
-```
-
-Sin embargo, cuando trabajes dentro de una expresión JSX, debes envolver varios elementos dentro de un **Fragmento**. Los fragmentos te permiten renderizar un conjunto de elementos sin agregar nodos adicionales al DOM. Esto es necesario en las expresiones JSX debido a una limitación de JavaScript: nunca puede "devolver" más de una cosa en una función o expresión de JavaScript. El uso de un fragmento resuelve este problema.
-
-Un Fragmento debe abrirse con `<>` y cerrarse con `</>`. No se preocupe si olvida esto, el compilador de Astro le advertirá que debe agregar uno.
-
-```astro
---
-const elementos = ["Perro", "Gato", "Ornitorrinco"];
---
-<ul>
-  {elementos.map((elemento) => (
-    <>
-      <li>{elemento} rojo</li>
-      <li>{elemento} azul</li>
-      <li>{elemento} verde</li>
-    </>
-  ))}
-</ul>
-```
-
-### Scripts izados
-
-Por defecto, Astro no hace ninguna suposición sobre cómo deseas que se sirvan los scripts, por lo que si agregas una etiqueta `<script>` en una página o un componente, se quedará sola.
-
-Sin embargo, si deseas que todos tus scripts se extraigan de los componentes y se muevan a la parte superior de la página, y luego se agrupen en producción, puedes lograrlo con scripts izados.
-
-Un **script izado** se ve así:
-
-```astro
-<script hoist>
-  // Una secuencia de comandos en línea
-</script>
-```
-
-O puede vincularse a un archivo JavaScript externo:
-
-```astro
-<script src={Astro.resolve('./mi-componente.js')} hoist></script>
-```
-
-Un script elevado puede estar dentro de una página o un componente, y no importa cuántas veces se use el componente, el script solo se agregará una vez:
-
-```astro
---
-import TwitterTimeline from '../components/TwitterTimeline.astro';
---
-
-<-- The script will only be injected into the head once. -->
-<TwitterTimeline />
-<TwitterTimeline />
-<TwitterTimeline />
-```
-
-## Comparando `.astro` versus` .jsx`
-
-Los archivos `.astro` puede terminar pareciendo muy similares a los archivos `.jsx`, pero hay algunas diferencias claves. Aquí hay una comparación entre los dos formatos.
-
-| Feature                              | Astro                                      | JSX                                                            |
-| ------------------------------------ | ------------------------------------------ | -------------------------------------------------------------- |
-| Extensión de archivo                 | `.astro`                                   | `.jsx` or `.tsx`                                               |
-| Componentes definidos por el usuario | `<Capitalized>`                            | `<Capitalized>`                                                |
-| Sintaxis de expresiones              | `{}`                                       | `{}`                                                           |
-| Difundir atributos                   | `{...props}`                               | `{...props}`                                                   |
-| Atributos booleanos                  | `autocomplete` === `autocomplete={true}`   | `autocomplete` === `autocomplete={true}`                       |
-| Funciones en línea                   | `{items.map(item => <li>{item}</li>)}`     | `{items.map(item => <li>{item}</li>)}`                         |
-| Soporte IDE                          | WIP - [VS Code][code-ext]                  | Fenomenal                                                      |
-| Requiere importación JS              | No                                         | Sí, `jsxPragma` (`React` or `h`) debe estar dentro del alcance |
-| Fragmentos                           | Automatic top-level, `<>` inside functions | Envolver con `<Fragment>` or `<>`                              |
-| Múltiples frameworks por archivo     | Yes                                        | No                                                             |
-| Modificando `<head>`                 | Just use `<head>`                          | Por-framework (`<Head>`, `<svelte:head>`, etc)                 |
-| Estilo de comentario                 | `<!-- HTML -->`                            | `{/* JavaScript */}`                                           |
-| Caracteres especiales                | `&nbsp;`                                   | `{'\xa0'}` or `{String.fromCharCode(160)}`                     |
-| Atributos                            | `dash-case`                                | `camelCase`                                                    |
-
-## Resolución de URL
-
-Es importante tener en cuenta que Astro **no** transformará las referencias HTML por ti. Por ejemplo, considera una etiqueta `<img>` con un atributo relativo `src` dentro de `src/pages/about.astro`:
-
-```html
-<!-- ❌ Incorrecto: Intentará cargar `/about/thumbnail.png` -->
-<img src="./thumbnail.png" />
-```
-
-Dado que `src/pages/about.astro` se compilará en `/about/index.html`, es posible que no haya esperado que la imagen viva en `/about/thumbnail.png`. Entonces, para solucionar este problema, elige una de las dos opciones:
-
-#### Opción 1: URL absolutas
-
-```html
-<!-- ✅ Correcto: referencia a public/thumbnail.png -->
-<img src="/thumbnail.png" />
-```
-
-El enfoque recomendado es colocar archivos dentro de `public/*`. Esto hace referencia a un archivo en `public/thumbnail.png`, que se resolverá en `/thumbnail.png` en la compilación final (ya que `public/` termina en `/`).
-
-#### Opción 2: Referencias de importación de activos
-
-```astro
---
-//  ✅ Correcto: referencia a src/thumbnail.png
-import thumbnailSrc from './thumbnail.png';
---
-
-<img src={thumbnailSrc} />
-```
-
-Si prefieres organizar los activos junto con los componentes de Astro, puedes importar el archivo en JavaScript dentro del script del componente. Esto funciona según lo previsto, pero hace que sea más difícil hacer referencia a `thumbnail.png` en otras partes de su aplicación, ya que su URL final no es fácilmente predecible (a diferencia de los recursos en ` public/*`, donde se garantiza que la URL final nunca cambia).
-
-[code-ext]: https://marketplace.visualstudio.com/items?itemName=astro-build.astro-vscode
--- a/docs/src/pages/es/core-concepts/astro-pages.md
+++ b/docs/src/pages/es/core-concepts/astro-pages.md
@ -1,67 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Páginas
-lang: es
---
-
-**Páginas** son un tipo especial de [Componente de Astro](/es/core-concepts/astro-components) que manejan el enrutamiento, la carga de datos y la creación de plantillas para cada página de su sitio web. Puedes pensar en ellos como cualquier otro componente de Astro, solo que con responsabilidades adicionales.
-
-Astro también admite Markdown para páginas con mucho contenido, como publicaciones de blogs y documentación. Consulta [Contenido de Markdown](/es/guides/markdown-content) para obtener más información sobre cómo escribir páginas con Markdown.
-
-## Enrutamiento basado en archivos
-
-Astro usa Páginas para hacer algo llamado **enrutamiento basado en archivos.** Cada archivo en tu directorio `src/pages` se convierte en una página en tu sitio, usando el nombre del archivo para decidir la ruta final.
-
-Los Componentes de Astro (`.astro`) y archivos Markdown (`.md`) son los únicos formatos admitidos para las páginas. No se admiten otros tipos de páginas (como un componente React `.jsx`), pero puedes usar cualquier cosa como componente de la interfaz de usuario dentro de una página `.astro` para lograr un resultado similar.
-
-```
-src/pages/index.astro       -> mysite.com/
-src/pages/about.astro       -> mysite.com/about
-src/pages/about/index.astro -> mysite.com/about
-src/pages/about/me.astro    -> mysite.com/about/me
-src/pages/posts/1.md        -> mysite.com/posts/1
-```
-
-## Plantillas de página
-
-Todos los componentes de Astro son responsables de devolver HTML. Las páginas de Astro también devuelven HTML, pero tienen la responsabilidad única de devolver una respuesta de página completa `<html> ... </html>`, incluyendo `<head>` ([MDN <span class = "sr-only">- head</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head)) y `<body>` ([MDN <span class = "sr-only ">- body</span>](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body)).
-
-`<! doctype html>` es opcional y se agregará automáticamente.
-
-```astro
---
-// Ejemplo: esqueleto de página HTML
---
-<!doctype html>
-<html>
-  <head>
-    <title>Título del documento</title>
-  </head>
-  <body>
-    <h1>¡Hola mundo!</h1>
-  </body>
-</html>
-```
-
-## Carga de datos
-
-Las páginas de Astro pueden obtener datos para ayudar a generar tus páginas. Astro proporciona dos herramientas diferentes a las páginas para ayudarte a hacer esto: **fetch()** y **await de alto nivel**.
-
-📚 Lee nuestra [guía completa sobre la obtención de datos](/es/guides/data-fetching) para obtener más información.
-
-```astro
---
-// Ejemplo: los scripts del componente de Astro se ejecutan en el momento de la compilación
-const response = await fetch('http://example.com/movies.json');
-const data = await response.json();
-console.log(data);
---
-<!-- Envía el resultado a la página -->
-<div>{JSON.stringify(data)}</div>
-```
-
-## Página de error 404 personalizada
-
-Para una página de error 404 personalizada, crea un archivo `404.astro` en `/src/pages`. Eso genera una página `404.html`. La mayoría de los [servicios de despliegue](/es/guides/deploy) lo encontrarán y lo utilizarán.
-
-Esto es especial y diferente al comportamiento predeterminado de construir `page.astro` (o `page/index.astro`) a `page/index.html`.
--- a/docs/src/pages/es/core-concepts/component-hydration.md
+++ b/docs/src/pages/es/core-concepts/component-hydration.md
@ -1,113 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Hidratación Parcial en Astro
-lang: es
---
-
-**Astro genera todos los sitios web sin JavaScript en el lado del cliente, de forma predeterminada.** Utiliza cualquier componente de interfaz de usuario que desee (React, Svelte, Vue, etc.) y Astro lo representará automáticamente en HTML en el momento de la compilación y elimina todo el JavaScript. Esto mantiene todos los sitios rápidos de forma predeterminada.
-
-Pero a veces, se requiere JavaScript del lado del cliente. Esta guía muestra cómo funcionan los componentes interactivos en Astro mediante una técnica llamada hidratación parcial.
-
-```astro
---
-// Ejemplo: Importar y luego usar un componente React.
-// De forma predeterminada, Astro representa esto en HTML y CSS durante
-// su compilación, sin JavaScript del lado del cliente.
-// (¿Necesitas JavaScript del lado del cliente? Sigue leyendo...)
-import MyReactComponent from '../components/MyReactComponent.jsx';
---
-<!-- 100% HTML, Zero JavaScript! -->
-<MyReactComponent />
-```
-
-## Concepto: Hidratación parcial
-
-Hay muchos casos en los que necesita un componente de UI interactivo para ejecutarse en el navegador:
-
- Un carrusel de imágenes
- Una barra de búsqueda de autocompletar
- Un botón de apertura/cierre de la barra lateral móvil
- Un botón "Comprar ahora"
-
-En Astro, depende de ti, como desarrollador, "habilitar" explícitamente cualquier componente de la página que deba ejecutarse en el navegador. Astro puede usar esta información para saber exactamente qué JavaScript se necesita y solo hidratar exactamente lo que se necesita en la página. Esta técnica se conoce como hidratación parcial.
-
-**Hidratación parcial**, el acto de solo hidratar los componentes individuales que requieren JavaScript y dejar el resto de su sitio como HTML estático, puede parecer relativamente sencillo. ¡Debería! Los sitios web se han construido de esta manera durante décadas. Recientemente, las aplicaciones de una sola página (SPA) introdujeron la idea de que todo su sitio web está escrito en JavaScript y compilado/renderizado por cada usuario en el navegador.
-
-\_Nota: La hidratación parcial a veces se denomina "mejora progresiva" o "hidratación progresiva". Si bien hay ligeros matices entre los términos, para nuestros propósitos, puede pensar en todos ellos como sinónimos del mismo concepto.
-
-**La hidratación parcial es el secreto de la historia de rendimiento rápido por defecto de Astro.** Next.js, Gatsby y otros marcos de JavaScript no pueden admitir la hidratación parcial porque imaginan todo su sitio web/página como una sola aplicación de JavaScript.
-
-## Concepto: Arquitectura de la isla
-
-**La arquitectura de la isla** es la idea de utilizar la hidratación parcial para construir sitios web completos. La arquitectura de la isla es una alternativa a la idea popular de construir su sitio web en un paquete de JavaScript del lado del cliente que debe enviarse al usuario.
-
-> En un modelo de "islas", la representación del servidor no es una optimización complementaria destinada a mejorar el SEO o la UX. En cambio, es una parte fundamental de cómo se envían las páginas al navegador. El HTML devuelto en respuesta a la navegación contiene una representación significativa e inmediatamente renderizable del contenido solicitado por el usuario.
-> <br/> -- [Jason Miller](https://jasonformat.com/islands-architecture/)
-
-Además de los obvios beneficios de rendimiento de enviar menos JavaScript al navegador, existen dos beneficios clave para la arquitectura de la isla:
-
- **Los componentes se cargan individualmente.** Un componente liviano (como una barra lateral) se cargará y renderizará rápidamente sin ser bloqueado por los componentes más pesados de la página.
- **Los componentes se procesan de forma aislada.** Cada parte de la página es una unidad aislada y un problema de rendimiento en una unidad no afectará directamente a las demás.
-
-![diagram](https://res.cloudinary.com/wedding-website/image/upload/v1596766231/islands-architecture-1.png)
-
-## Hidrata los componentes interactivos
-
-Astro procesa todos los componentes en el servidor **en el momento de la compilación**, a menos que se use [client:only](#mycomponent-clientonly-). Para hidratar componentes en el cliente **en tiempo de ejecución**, puede usar cualquiera de las siguientes directivas `client:*`. Una directiva es un atributo de componente (siempre con un `:`) que le dice a Astro cómo debe renderizarse tu componente.
-
-```astro
---
-// Ejemplo: hidratación de un componente React en el navegador.
-import MyReactComponent from '../components/MyReactComponent.jsx';
---
-<!-- "client:visible" significa que el componente no cargará ningún Javascript
-  del lado del cliente hasta que sea visible en el navegador del usuario. -->
-<MyReactComponent client:visible />
-```
-
-### `<MyComponent client:load />`
-
-Hidratar el componente al cargar la página.
-
-### `<MyComponent client:idle />`
-
-Hidrata el componente tan pronto como el hilo principal esté libre (usa [requestIdleCallback()] [mdn-ric]).
-
-### `<MyComponent client:visible />`
-
-Hidrata el componente tan pronto como el elemento entre en la ventana gráfica (usa [IntersectionObserver] [mdn-io]). Útil para el contenido que se encuentra más abajo en la página.
-
-### `<MyComponent client:media={QUERY} />`
-
-Hidrata el componente tan pronto como el navegador coincida con la consulta de medios dada (usa [matchMedia] [mdn-mm]). Útil para alternar la barra lateral u otros elementos que solo deberían mostrarse en dispositivos móviles o de escritorio.
-
-### `<MyComponent client:only />`
-
-Hidrata el componente en la carga de la página, similar a `client:load`. El componente se **omitirá** en el momento de la compilación, lo que resulta útil para los componentes que dependen por completo de las API del lado del cliente. Es mejor evitar esto a menos que sea absolutamente necesario; en la mayoría de los casos, es mejor representar el contenido del marcador de posición en el servidor y retrasar las llamadas a la API del navegador hasta que el componente se hidrate en el navegador.
-
-Si se incluye más de un renderizador en Astro [config](/es/reference/configuration-reference), `client:only` necesita una pista para saber qué renderizador usar para el componente. Por ejemplo, `client:only="react"` aseguraría que el componente esté hidratado en el navegador con el renderizador React. Para los renderizadores personalizados no proporcionados por `@astrojs`, use el nombre completo del renderizador proporcionado en su configuración de Astro, es decir,`<client: only="my-custom-renderer" />`.
-
-## ¿Puedo hidratar los componentes de Astro?
-
-Los [componentes de Astro](./astro-components)(archivos `.astro`) son componentes con plantillas de solo HTML sin ejecución del lado del cliente. Si intentas hidratar un componente Astro con un modificador `client:`, obtendrás un error.
-
-Para hacer que su componente Astro sea interactivo, necesitará convertirlo al framework de su elección: React, Svelte, Vue, etc. Si no tienes preferencias, recomendamos React o Preact ya que son más similares a la sintaxis de Astro.
-
-Alternativamente, puedes agregar una etiqueta `<script>` a tu plantilla HTML del componente de Astro y enviar JavaScript al navegador de esa manera. Aunque esto está bien para las cosas simples, recomendamos un framework de frontend para componentes interactivos más complejos.
-
-```astro
---
-// Ejemplo: uso de Astro con etiquetas de secuencia de comandos
---
-<h1>No clickeado</h1>
-<button>Haz click para cambiar el título</button>
-<script>
-document.querySelector("button").addEventListener("click",() => {
-    document.querySelector("h1").innerText = "clickeado"
-})
-</script>
-```
-
-[mdn-io]: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
-[mdn-ric]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
-[mdn-mm]: https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia
--- a/docs/src/pages/es/core-concepts/layouts.md
+++ b/docs/src/pages/es/core-concepts/layouts.md
@ -1,155 +0,0 @@
---
-layout: ~/layouts/MainLayout.astro
-title: Maquetas
-lang: es
---
-
-**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.
-
-## Uso
-
-Las maquetas de Astro soportan propiedades, slots y todas las otras características de los componentes de Astro. Las maquetas son solo componentes normales, ¡después de todo!
-
-A diferencia de otros componentes, las maquetas suelen contener la página completa `<html>`, `<head>` y `<body>` (a menudo denominado **cáscara de la página**).
-
-Es un patrón común colocar todos los componentes de su diseño en un solo directorio `src/layouts`.
-
-## Example
-
-```astro
---
-// src/layouts/BaseLayout.astro
-const {title} = Astro.props;
---
-<html>
-  <head>
-    <title>Ejemplo de maqueta: {title}</title>
-  </head>
-  <body>
-    <!-- Añade una barra de navegación a cada página. -->
-    <nav>
-      <a href="#">Inicio</a>
-      <a href="#">Artículos</a>
-      <a href="#">Contacto</a>
-    </nav>
-    <!-- ranura: el contenido de su página se inyectará aquí. -->
-    <slot />
-  </body>
-</html>
-```
-
-📚 El elemento `<slot />` permite que los componentes de Astro definan dónde deben ir los elementos secundarios (pasados a la maqueta). Obtén más información sobre cómo funciona `<slot />` en nuestra [Guía de componentes de Astro](/es/core-concepts/astro-components).
-
-Una vez que tengas tu primera maqueta, puedes usarla como lo harías con cualquier otro componente de tu página. Recuerda que tu maqueta contiene tu página `<html>`, `<head>` y `<body>`. Solo necesitas proporcionar el contenido de la página personalizada.
-
-```astro
---
-// src/pages/index.astro
-import BaseLayout from '../layouts/BaseLayout.astro'
---
-<BaseLayout title="Inicio">
-  <h1>Hola, ¡mundo!</h1>
-  <p>Este es el contenido de mi página. Estará anidado dentro de una maqueta.</p>
-</BaseLayout>
-```
-
-## Maquetas anidadas
-
-Puedes anidar maquetas cuando desees crear tipos de página más específicos sin copiar y pegar. Es común en Astro tener un `BaseLayout` genérico y luego muchos más maquetas específicas (`PostLayout`, `ProductLayout`, etc.) que se reutilizan y construyen sobre él.
-
-```astro
---
-// src/layouts/PostLayout.astro
-import BaseLayout from '../layouts/BaseLayout.astro'
-const {titulo, author} = Astro.props;
---
-<!-- Este maqueta reutiliza BaseLayout (ver el ejemplo anterior): -->
-<BaseLayout titulo={titulo}>
-  <!-- Añade contenido nuevo específico de publicación a cada página. -->
-  <div>Autor del artículo: {author}</div>
-  <!-- ranura: el contenido de su página se inyectará aquí. -->
-  <slot />
-</BaseLayout>
-```
-
-## Composición de maquetas
-
-A veces, necesitas un control más granular sobre tu página. Por ejemplo, es posible que desees agregar SEO o etiquetas `meta` sociales en algunas páginas, pero no en otras. Puedes implementar esto con un accesorio en su maqueta (`<BaseLayout addMeta={true}...`) pero en algún momento puede ser más fácil componer tus maquetas sin anidar.
-
-En lugar de definir toda la página `<html>` como un diseño grande, puedes definir los contenidos de `head` y `body` como componentes separados más pequeños. Esto te permite componer varias maquetas juntas de formas únicas en cada página.
-
-```astro
---
-// src/layouts/BaseHead.astro
-const {title, description} = Astro.props;
---
-<meta charset="UTF-8">
-<title>{title}</title>
-<meta name="description" content={description}>
-<link rel="preconnect" href="https://fonts.gstatic.com">
-<link href="https://fonts.googleapis.com/css2?family=Spectral:ital,wght@0,400;0,700;1,400;1,700&display=swap" rel="stylesheet">
-```
-
-Observa cómo esta maqueta no incluye la carcasa de su página, y solo incluye algunos elementos genéricos que deberían ir en tu `<head>`. Esto te permite combinar varios componentes de maqueta juntos con más control sobre la estructura general de la página.
-
-```astro
---
-// src/pages/index.astro
-import BaseHead from '../layouts/BaseHead.astro';
-import OpenGraphMeta from '../layouts/OpenGraphMeta.astro';
---
-<html>
-  <head>
-    <!-- Ahora, tienes control total sobre el encabezado, por página. -->
-    <BaseHead title="Page Title" description="Page Description" />
-    <OpenGraphMeta />
-    <!-- Incluso puedes agregar elementos personalizados y únicos según sea necesario. -->
-    <link rel="alternate" type="application/rss+xml" href="/feed/posts.xml">
-  </head>
-  <body>
-    <!-- ... -->
-  </body>
-</html>
-```
-
-La única desventaja de este enfoque es que deberás definir los elementos `<html>`, `<head>` y `<body>` en cada página tú mismo. Esto es necesario para construir la página porque los componentes de maqueta ya no contienen la carcasa completa de la página.
-
-## Maquetas Markdown
-
-Las maquetas son esenciales para los archivos Markdown. Los archivos de Markdown pueden declarar una maqueta en el texto preliminar del archivo. Cada archivo Markdown se procesará en HTML y luego se inyectará en la ubicación `<slot />` de la maqueta.
-
-```markdown
---
-title: Publicación del blog
-layout: ../layouts/PostLayout.astro
---
-
-Esta publicación de blog se **renderizará** dentro de la maqueta `<PostLayout />`.
-```
-
-Las páginas de Markdown siempre pasan una propiedad `content` a su maqueta, que es útil para obtener información sobre la página, el título, los metadatos, los encabezados de la tabla de contenido y más.
-
-```astro
---
-// src/layouts/PostLayout.astro
-const { content } = Astro.props;
---
-<html>
-  <head>
-    <title>{content.title}</title>
-  </head>
-  <body>
-    <h1>{content.title}</h1>
-    <h2>{content.description}</h2>
-    <img src={content.image} alt="">
-    <article>
-      <!-- slot: ¡El contenido de Markdown va aquí! -->
-      <slot />
-    </article>
-  </body>
-</html>
-```
-
-📚 Aprende más sobre el soporte de Markdown de Astro en nuestra [guía de Markdown](/es/guides/markdown-content).
--- a/Show more
+++ b/Show more