i18n(de): Follow i18n guide in islands.mdx

src/content/docs/de/concepts/islands.mdx

@@ -11,7 +11,7 @@ Astro hat dazu beigetragen, ein neues Frontend-Architekturmuster namens **Island
 
 ## Eine kurze Geschichte
 
-Der Begriff „Komponenteninsel“ wurde erstmals 2019 von Etsy's Frontend-Architektin [Katie Sylor-Miller](https://sylormiller.com/) geprägt. Diese Idee wurde dann vom Preact-Erfinder Jason Miller am 11. August 2020 erweitert und in [diesem Beitrag](https://jasonformat.com/islands-architecture/) dokumentiert.
+Der Begriff „Komponenteninsel“ wurde erstmals 2019 von Etsy’s Frontend-Architektin [Katie Sylor-Miller](https://sylormiller.com/) geprägt. Diese Idee wurde dann vom Preact-Erfinder Jason Miller am 11. August 2020 erweitert und in [diesem Beitrag](https://jasonformat.com/islands-architecture/) dokumentiert.
 
 > Die allgemeine Idee einer „Insel“-Architektur ist täuschend einfach: Man rendert HTML-Seiten auf dem Server und fügt Platzhalter oder Slots um hochdynamische Bereiche herum ein [...], die dann auf dem Client in kleine, in sich geschlossene Widgets „hydratisiert“ werden können, die ihr vom Server gerendertes Ausgangs-HTML wiederverwenden.  
 > - Jason Miller, Erfinder von Preact
@@ -43,9 +43,9 @@ Stell dir ein Client-Island als ein interaktives Widget vor, das in einem Meer v
   <Fragment slot="headerApp">Header (interaktives Island)</Fragment>
   <Fragment slot="sidebarApp">Sidebar (statisches HTML)</Fragment>
   <Fragment slot="main">
-    Statische Inhalte wie Text, Bilder, etc.
+    Statische Inhalte wie Text, Bilder usw.
   </Fragment>
-  <Fragment slot="carouselApp">Bilder&shy;karussell (interaktives Island)</Fragment>
+  <Fragment slot="carouselApp">Bilderkarussell (interaktives Island)</Fragment>
   <Fragment slot="footer">Footer (statisches HTML)</Fragment>
   <Fragment slot="source">Quelle: [Islands Architecture: Jason Miller](https://jasonformat.com/islands-architecture/)</Fragment>
 </IslandsDiagram>
@@ -87,7 +87,7 @@ Und weil die Interaktion auf Komponentenebene konfiguriert wird, kannst du für
 
 <h3>Vorteile von Client-Islands</h3>
 
-Leistungsvorteile sind die offensichtlichsten Vorteile von Astro-Inseln: der Großteil deiner Website wird in schnelles, statisches HTML umgewandelt und JavaScript wird nur für die einzelnen Komponenten geladen, die es benötigen. JavaScript ist im Ladevorgang eine der langsamsten Ressourcen, daher zählt jedes Byte.
+Leistungsvorteile sind die offensichtlichsten Vorteile von Astro Islands: der Großteil deiner Website wird in schnelles, statisches HTML umgewandelt und JavaScript wird nur für die einzelnen Komponenten geladen, die es benötigen. JavaScript ist im Ladevorgang eine der langsamsten Ressourcen, daher zählt jedes Byte.
 
 Ein weiterer Vorteil ist das parallele Laden von Astro Islands. Im Beispiel-Schaubild oben muss das „Bilderkarussell“-Island mit niedriger Priorität nicht das „Header“-Island mit hoher Priorität blockieren. Beide werden parallel und isoliert geladen, was bedeutet, dass der Header sofort interaktiv wird, ohne auf das umfangreichere Bilderkarussell weiter unten auf der Seite warten zu müssen.
 
@@ -114,7 +114,7 @@ import Avatar from '../components/Avatar.astro';
 
 Dadurch wird deine Seite in kleinere Bereiche mit vom Server gerenderten Inhalten aufgeteilt, die parallel geladen werden.
 
-Der Hauptinhalt deiner Seite kann sofort mit Platzhalterinhalten, wie z. B. einem generischen Avatar, gerendert werden, bis der eigene Inhalt deines Islands verfügbar ist. Mit Server-Islands verzögert sich die Darstellung einer ansonsten statischen Seite nicht, wenn kleine Komponenten mit personalisierten Inhalten vorhanden sind.
+Der Hauptinhalt deiner Seite kann sofort mit Platzhalterinhalten, wie z. B. einem generischen Avatar, gerendert werden, bis der eigene Inhalt deines Islands verfügbar ist. Mit Server-Islands verzögert sich die Darstellung einer ansonsten statischen Seite nicht, wenn kleine Komponenten mit personalisierten Inhalten vorhanden sind.
 
 Dieses Rendering-Muster wurde entwickelt, um portabel zu sein. Es ist nicht von einer Serverinfrastruktur abhängig und funktioniert daher mit jedem Host, von einem Node.js-Server in einem Docker-Container bis hin zu einem serverlosen Anbieter deiner Wahl.
 

src/content/docs/de/concepts/why-astro.mdx

@@ -42,19 +42,19 @@ Astros Fokus auf Inhalte hat es seit seinen Anfängen als statischer Website-Bui
 
 ### Server-first
 
-**Astro setzt so weit wie möglich auf Server-Rendering statt auf clientseitiges Rendering im Browser.** Das ist derselbe Ansatz, den traditionelle serverseitige Frameworks – PHP, WordPress, Laravel, Ruby on Rails usw. – schon seit Jahrzehnten verwenden. Aber du brauchst dafür keine zweite serverseitige Sprache zu lernen. Mit Astro besteht alles nur noch aus HTML, CSS und JavaScript (oder TypeScript, wenn du willst).
+**Astro setzt so weit wie möglich auf Server-Rendering statt auf clientseitiges Rendering im Browser.** Das ist derselbe Ansatz, den traditionelle serverseitige Frameworks – PHP, WordPress, Laravel, Ruby on Rails usw. – schon seit Jahrzehnten verwenden. Aber du brauchst dafür keine zweite serverseitige Sprache zu lernen. Mit Astro besteht alles nur noch aus HTML, CSS und JavaScript (oder TypeScript, wenn du willst).
 
 Dieser Ansatz steht im Gegensatz zu anderen modernen JavaScript-Web-Frameworks wie Next.js, SvelteKit, Nuxt, Remix und weiteren. Diese Frameworks erfordern das clientseitige Rendering der gesamten Website und beinhalten das serverseitige Rendering hauptsächlich, um Leistungsprobleme zu lösen. Dieser Ansatz wird als **Single Page App (SPA)** bezeichnet, im Gegensatz zum **Multi Page App (MPA)**-Ansatz von Astro.
 
-Das SPA-Modell hat seine Vorteile. Diese gehen jedoch auf Kosten von zusätzlicher Komplexität und Leistungseinbußen. Diese Kompromisse beeinträchtigen die Seitenleistung – kritische Kennzahlen wie die [Time to Interactive (TTI)](https://web.dev/interactive/) – was für inhaltsorientierte Websites, bei denen die Leistung beim ersten Laden entscheidend ist, wenig sinnvoll ist.
+Das SPA-Modell hat seine Vorteile. Diese gehen jedoch auf Kosten von zusätzlicher Komplexität und Leistungseinbußen. Diese Kompromisse beeinträchtigen die Seitenleistung – kritische Kennzahlen wie die [Time to Interactive (TTI)](https://web.dev/interactive/) – was für inhaltsorientierte Websites, bei denen die Leistung beim ersten Laden entscheidend ist, wenig sinnvoll ist.
 
 Der Server-First-Ansatz von Astro ermöglicht es dir, nur bei Bedarf auf das clientseitige Rendering umzusteigen. Du kannst UI-Framework-Komponenten hinzufügen, die auf dem Client ausgeführt werden. Du kannst den Astro-View-Transitions-Router nutzen, um ausgewählte Seitenübergänge und Animationen genauer zu steuern. Das Server-First-Rendering von Astro, das entweder vorgerendert oder bei Bedarf ausgeführt wird, bietet leistungsfähige Standard­einstellungen, die du verbessern und erweitern kannst.
 
 ### Standardmäßig schnell
 
 Eine gute Leistung ist immer wichtig, aber sie ist *besonders* wichtig für inhaltsfokussierte Websites. Es ist erwiesen, dass eine schlechte Leistung zu einem Verlust an Engagement, Konversionen und Einnahmen führt. Ein Beispiel:
 
-- Jede 100 ms schneller → 1 % mehr Konversionen ([Mobify](https://web.dev/why-speed-matters/), Verdienst +380 000 $/Jahr)
+- Jede 100 ms schneller → 1 % mehr Konversionen ([Mobify](https://web.dev/why-speed-matters/), Verdienst +380 000 $/Jahr)
 - 50 % schneller → 12 % mehr Umsatz ([AutoAnything](https://www.digitalcommerce360.com/2010/08/19/web-accelerator-revs-conversion-and-sales-autoanything/))
 - 20 % schneller → 10 % mehr Konversionen ([Furniture Village](https://www.thinkwithgoogle.com/intl/en-gb/marketing-strategies/app-and-mobile/furniture-village-and-greenlight-slash-page-load-times-boosting-user-experience/))
 - 40 % schneller → 15 % mehr Registrierungen ([Pinterest](https://medium.com/pinterest-engineering/driving-user-growth-with-performance-improvements-cfc50dafadd7))
@@ -63,7 +63,7 @@ Eine gute Leistung ist immer wichtig, aber sie ist *besonders* wichtig für inha
 
 Bei vielen Web-Frameworks ist es leicht möglich, eine Website zu erstellen, die während der Entwicklung großartig aussieht, aber nach der Veröffentlichung schmerzhaft langsam lädt. Schuld daran ist häufig JavaScript, da Smartphones und Geräte mit geringerer Leistung selten die Geschwindigkeit des Laptops eines Entwicklers erreichen.
 
-Die Magie von Astro liegt in der Kombination der beiden oben genannten Werte – ein Fokus auf Inhalte mit einer Server-First MPA-Architektur – um Kompromisse zu machen und Funktionalitäten zu liefern, die andere Frameworks nicht bieten können. Das Ergebnis ist eine erstaunliche Web-Performance für jede Website, Out-of-the-Box. Unser Ziel: **Es sollte nahezu unmöglich sein, mit Astro eine langsame Website zu erstellen.**
+Die Magie von Astro liegt in der Kombination der beiden oben genannten Werte – ein Fokus auf Inhalte mit einer Server-First MPA-Architektur – um Kompromisse zu machen und Funktionalitäten zu liefern, die andere Frameworks nicht bieten können. Das Ergebnis ist eine erstaunliche Web-Performance für jede Website, Out-of-the-Box. Unser Ziel: **Es sollte nahezu unmöglich sein, mit Astro eine langsame Website zu erstellen.**
 
 Eine Astro-Website kann [mit 90 % weniger JavaScript 40 % schneller laden](https://twitter.com/t3dotgg/status/1437195415439360003) als die gleiche Website, die mit dem beliebten React-Webframework erstellt wurde. Aber nimm uns nicht beim Wort: Sieh dir an, wie Astros Leistung Ryan Carniato (Schöpfer von Solid.js und Marko) [sprachlos](https://youtu.be/2ZEMb_H-LYE?t=8163) macht.