From 144e29006b02365489cad92420b53cc3fb7069a5 Mon Sep 17 00:00:00 2001
From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>
Date: Thu, 26 Feb 2026 02:34:33 +0000
Subject: [PATCH 1/5] Initial plan


From 8e66934f947c4a17f512e2ef7256cb695da8cfe0 Mon Sep 17 00:00:00 2001
From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>
Date: Thu, 26 Feb 2026 02:43:18 +0000
Subject: [PATCH 2/5] Add German (de) translations for collections and
 concurrency patterns

Create 20 German translation YAML files covering:
- 10 collections patterns (collectors-teeing, copying-collections-immutably,
  immutable-list/map/set-creation, map-entry-factory, reverse-list-iteration,
  sequenced-collections, stream-toarray-typed, unmodifiable-collectors)
- 10 concurrency patterns (completablefuture-chaining, concurrent-http-virtual,
  executor-try-with-resources, lock-free-lazy-init, process-api, scoped-values,
  stable-values, structured-concurrency, thread-sleep-duration, virtual-threads)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../de/collections/collectors-teeing.yaml     | 19 +++++++++++++++++
 .../copying-collections-immutably.yaml        | 19 +++++++++++++++++
 .../collections/immutable-list-creation.yaml  | 19 +++++++++++++++++
 .../collections/immutable-map-creation.yaml   | 18 ++++++++++++++++
 .../collections/immutable-set-creation.yaml   | 18 ++++++++++++++++
 .../de/collections/map-entry-factory.yaml     | 19 +++++++++++++++++
 .../collections/reverse-list-iteration.yaml   | 20 ++++++++++++++++++
 .../de/collections/sequenced-collections.yaml | 19 +++++++++++++++++
 .../de/collections/stream-toarray-typed.yaml  | 19 +++++++++++++++++
 .../collections/unmodifiable-collectors.yaml  | 21 +++++++++++++++++++
 .../completablefuture-chaining.yaml           | 19 +++++++++++++++++
 .../concurrency/concurrent-http-virtual.yaml  | 19 +++++++++++++++++
 .../executor-try-with-resources.yaml          | 19 +++++++++++++++++
 .../de/concurrency/lock-free-lazy-init.yaml   | 19 +++++++++++++++++
 .../content/de/concurrency/process-api.yaml   | 19 +++++++++++++++++
 .../content/de/concurrency/scoped-values.yaml | 20 ++++++++++++++++++
 .../content/de/concurrency/stable-values.yaml | 20 ++++++++++++++++++
 .../concurrency/structured-concurrency.yaml   | 20 ++++++++++++++++++
 .../de/concurrency/thread-sleep-duration.yaml | 19 +++++++++++++++++
 .../de/concurrency/virtual-threads.yaml       | 20 ++++++++++++++++++
 20 files changed, 385 insertions(+)
 create mode 100644 translations/content/de/collections/collectors-teeing.yaml
 create mode 100644 translations/content/de/collections/copying-collections-immutably.yaml
 create mode 100644 translations/content/de/collections/immutable-list-creation.yaml
 create mode 100644 translations/content/de/collections/immutable-map-creation.yaml
 create mode 100644 translations/content/de/collections/immutable-set-creation.yaml
 create mode 100644 translations/content/de/collections/map-entry-factory.yaml
 create mode 100644 translations/content/de/collections/reverse-list-iteration.yaml
 create mode 100644 translations/content/de/collections/sequenced-collections.yaml
 create mode 100644 translations/content/de/collections/stream-toarray-typed.yaml
 create mode 100644 translations/content/de/collections/unmodifiable-collectors.yaml
 create mode 100644 translations/content/de/concurrency/completablefuture-chaining.yaml
 create mode 100644 translations/content/de/concurrency/concurrent-http-virtual.yaml
 create mode 100644 translations/content/de/concurrency/executor-try-with-resources.yaml
 create mode 100644 translations/content/de/concurrency/lock-free-lazy-init.yaml
 create mode 100644 translations/content/de/concurrency/process-api.yaml
 create mode 100644 translations/content/de/concurrency/scoped-values.yaml
 create mode 100644 translations/content/de/concurrency/stable-values.yaml
 create mode 100644 translations/content/de/concurrency/structured-concurrency.yaml
 create mode 100644 translations/content/de/concurrency/thread-sleep-duration.yaml
 create mode 100644 translations/content/de/concurrency/virtual-threads.yaml

diff --git a/translations/content/de/collections/collectors-teeing.yaml b/translations/content/de/collections/collectors-teeing.yaml
new file mode 100644
index 0000000..8d1b4f6
--- /dev/null
+++ b/translations/content/de/collections/collectors-teeing.yaml
@@ -0,0 +1,19 @@
+title: "Collectors.teeing()"
+oldApproach: Zwei Durchläufe
+modernApproach: "teeing()"
+summary: Zwei Aggregationen in einem einzigen Stream-Durchlauf berechnen.
+explanation: "Collectors.teeing() sendet jedes Element an zwei nachgelagerte Collectors\
+  \ und fasst die Ergebnisse zusammen. Dadurch wird vermieden, die Daten zweimal\
+  \ zu durchlaufen oder einen veränderbaren Akkumulator zu verwenden."
+whyModernWins:
+- icon: "⚡"
+  title: Einzelner Durchlauf
+  desc: Den Stream einmal statt zweimal verarbeiten.
+- icon: "🧩"
+  title: Kombinierbar
+  desc: Zwei beliebige Collectors mit einer Zusammenführungsfunktion verbinden.
+- icon: "🔒"
+  title: Unveränderliches Ergebnis
+  desc: Direkt in einen Record oder Value-Object zusammenführen.
+support:
+  description: Weitgehend verfügbar seit JDK 12 (März 2019)
diff --git a/translations/content/de/collections/copying-collections-immutably.yaml b/translations/content/de/collections/copying-collections-immutably.yaml
new file mode 100644
index 0000000..0ed476c
--- /dev/null
+++ b/translations/content/de/collections/copying-collections-immutably.yaml
@@ -0,0 +1,19 @@
+title: Kollektionen unveränderlich kopieren
+oldApproach: Manuelle Kopie + Wrapper
+modernApproach: "List.copyOf()"
+summary: Eine unveränderliche Kopie einer beliebigen Kollektion mit einem einzigen Aufruf erstellen.
+explanation: "List.copyOf(), Set.copyOf() und Map.copyOf() erstellen unveränderliche\
+  \ Momentaufnahmen bestehender Kollektionen. Wenn die Quelle bereits eine unveränderliche\
+  \ Kollektion ist, wird keine Kopie erstellt."
+whyModernWins:
+- icon: "⚡"
+  title: Intelligente Kopie
+  desc: Die Kopie wird übersprungen, wenn die Quelle bereits unveränderlich ist.
+- icon: "📏"
+  title: Ein einziger Aufruf
+  desc: Kein manuelles ArrayList-Erstellen und Verpacken.
+- icon: "🛡️"
+  title: Defensive Kopie
+  desc: Änderungen am Original wirken sich nicht auf die Kopie aus.
+support:
+  description: Weitgehend verfügbar seit JDK 10 (März 2018)
diff --git a/translations/content/de/collections/immutable-list-creation.yaml b/translations/content/de/collections/immutable-list-creation.yaml
new file mode 100644
index 0000000..f43117d
--- /dev/null
+++ b/translations/content/de/collections/immutable-list-creation.yaml
@@ -0,0 +1,19 @@
+title: Unveränderliche Listen erstellen
+oldApproach: Ausführliches Verpacken
+modernApproach: "List.of()"
+summary: Unveränderliche Listen in einem einzigen, sauberen Ausdruck erstellen.
+explanation: "List.of() erstellt eine wirklich unveränderliche Liste — kein Verpacken,\
+  \ keine defensive Kopie. Sie ist null-feindlich (lehnt null-Elemente ab) und strukturell\
+  \ unveränderlich. Die alte Methode erforderte drei verschachtelte Aufrufe."
+whyModernWins:
+- icon: "📏"
+  title: Ein einziger Aufruf
+  desc: Drei verschachtelte Aufrufe durch eine einzige Factory-Methode ersetzen.
+- icon: "🔒"
+  title: Wirklich unveränderlich
+  desc: Kein bloßer Wrapper — die Liste selbst ist unveränderlich.
+- icon: "🛡️"
+  title: Null-sicher
+  desc: Lehnt null-Elemente bei der Erstellung ab und schlägt sofort fehl.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/collections/immutable-map-creation.yaml b/translations/content/de/collections/immutable-map-creation.yaml
new file mode 100644
index 0000000..54e07d7
--- /dev/null
+++ b/translations/content/de/collections/immutable-map-creation.yaml
@@ -0,0 +1,18 @@
+title: Unveränderliche Maps erstellen
+oldApproach: Map-Builder-Muster
+modernApproach: "Map.of()"
+summary: Unveränderliche Maps inline ohne Builder erstellen.
+explanation: "Map.of() akzeptiert Schlüssel-Wert-Paare inline und gibt eine unveränderliche\
+  \ Map zurück. Für mehr als 10 Einträge Map.ofEntries() mit Map.entry()-Paaren verwenden."
+whyModernWins:
+- icon: "📏"
+  title: Inline-Erstellung
+  desc: Kein temporäres veränderliches Map erforderlich.
+- icon: "🔒"
+  title: Unveränderliches Ergebnis
+  desc: Die Map kann nach der Erstellung nicht mehr geändert werden.
+- icon: "🚫"
+  title: Keine null-Schlüssel/-Werte
+  desc: Null-Einträge werden sofort abgelehnt.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/collections/immutable-set-creation.yaml b/translations/content/de/collections/immutable-set-creation.yaml
new file mode 100644
index 0000000..4b42a38
--- /dev/null
+++ b/translations/content/de/collections/immutable-set-creation.yaml
@@ -0,0 +1,18 @@
+title: Unveränderliche Sets erstellen
+oldApproach: Ausführliches Verpacken
+modernApproach: "Set.of()"
+summary: Unveränderliche Sets mit einem einzigen Factory-Aufruf erstellen.
+explanation: "Set.of() erstellt ein wirklich unveränderliches Set, das null-Elemente\
+  \ und Duplikate bei der Erstellung ablehnt. Kein Verpacken von veränderbaren Sets mehr."
+whyModernWins:
+- icon: "📏"
+  title: Prägnant
+  desc: Eine Zeile statt drei verschachtelter Aufrufe.
+- icon: "🚫"
+  title: Erkennt Duplikate
+  desc: Wirft eine Ausnahme, wenn versehentlich doppelte Elemente übergeben werden.
+- icon: "🔒"
+  title: Unveränderlich
+  desc: Kein Hinzufügen oder Entfernen nach der Erstellung möglich.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/collections/map-entry-factory.yaml b/translations/content/de/collections/map-entry-factory.yaml
new file mode 100644
index 0000000..1aefd45
--- /dev/null
+++ b/translations/content/de/collections/map-entry-factory.yaml
@@ -0,0 +1,19 @@
+title: "Map.entry()-Factory"
+oldApproach: SimpleEntry
+modernApproach: "Map.entry()"
+summary: Map-Einträge mit einer sauberen Factory-Methode erstellen.
+explanation: "Map.entry() ersetzt den ausführlichen AbstractMap.SimpleEntry-Konstruktor.\
+  \ Es gibt einen unveränderlichen Eintrag zurück, der ideal für Map.ofEntries()\
+  \ und Stream-Operationen ist."
+whyModernWins:
+- icon: "📏"
+  title: Prägnant
+  desc: Eine Zeile statt drei mit klarerer Absicht.
+- icon: "🔒"
+  title: Unveränderlich
+  desc: Der zurückgegebene Eintrag kann nicht geändert werden.
+- icon: "🧩"
+  title: Kombinierbar
+  desc: "Funktioniert perfekt mit Map.ofEntries() für große Maps."
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/collections/reverse-list-iteration.yaml b/translations/content/de/collections/reverse-list-iteration.yaml
new file mode 100644
index 0000000..466d3ff
--- /dev/null
+++ b/translations/content/de/collections/reverse-list-iteration.yaml
@@ -0,0 +1,20 @@
+title: Umgekehrte Listen-Iteration
+oldApproach: Manueller ListIterator
+modernApproach: "reversed()"
+summary: Mit einer sauberen for-each-Schleife in umgekehrter Reihenfolge über eine Liste iterieren.
+explanation: "Die Methode reversed() von SequencedCollection gibt eine in umgekehrter\
+  \ Reihenfolge angeordnete Ansicht der Liste zurück. Diese Ansicht wird durch die\
+  \ ursprüngliche Liste gesichert, sodass kein Kopieren stattfindet. Die erweiterte\
+  \ for-Schleife macht die umgekehrte Iteration genauso lesbar wie die Vorwärts-Iteration."
+whyModernWins:
+- icon: "📖"
+  title: Natürliche Syntax
+  desc: Erweiterte for-Schleife statt des ausführlichen ListIterators.
+- icon: "⚡"
+  title: Kein Kopieren
+  desc: "reversed() gibt eine Ansicht zurück — kein Performance-Overhead."
+- icon: "🧩"
+  title: Konsistente API
+  desc: "Funktioniert einheitlich auf List, Deque und SortedSet."
+support:
+  description: Weitgehend verfügbar seit JDK 21 LTS (Sept. 2023)
diff --git a/translations/content/de/collections/sequenced-collections.yaml b/translations/content/de/collections/sequenced-collections.yaml
new file mode 100644
index 0000000..173116a
--- /dev/null
+++ b/translations/content/de/collections/sequenced-collections.yaml
@@ -0,0 +1,19 @@
+title: Sequenzierte Kollektionen
+oldApproach: Index-Arithmetik
+modernApproach: getFirst/getLast
+summary: "Auf das erste/letzte Element zugreifen und umgekehrte Ansichten mit sauberen API-Methoden erhalten."
+explanation: "SequencedCollection fügt getFirst(), getLast(), reversed(), addFirst()\
+  \ und addLast() zu List, Deque, SortedSet und LinkedHashSet hinzu. Keine size-1-Arithmetik\
+  \ oder manuelle umgekehrte Iteration mehr."
+whyModernWins:
+- icon: "📖"
+  title: Selbstdokumentierend
+  desc: "getLast() ist klarer als get(size()-1)."
+- icon: "🔄"
+  title: Umgekehrte Ansicht
+  desc: "reversed() gibt eine Ansicht zurück — kein Kopieren erforderlich."
+- icon: "🧩"
+  title: Einheitliche API
+  desc: "Funktioniert gleich auf List, Deque und SortedSet."
+support:
+  description: Weitgehend verfügbar seit JDK 21 LTS (Sept. 2023)
diff --git a/translations/content/de/collections/stream-toarray-typed.yaml b/translations/content/de/collections/stream-toarray-typed.yaml
new file mode 100644
index 0000000..a0a0bc8
--- /dev/null
+++ b/translations/content/de/collections/stream-toarray-typed.yaml
@@ -0,0 +1,19 @@
+title: Typisiertes Stream-toArray
+oldApproach: Manuelle Array-Kopie
+modernApproach: "toArray(generator)"
+summary: Streams mit einer Methodenreferenz in typisierte Arrays umwandeln.
+explanation: "Die Methode toArray(IntFunction) erstellt ein korrekt typisiertes Array\
+  \ aus einem Stream. Der Generator (String[]::new) teilt dem Stream mit, welchen\
+  \ Array-Typ er erstellen soll."
+whyModernWins:
+- icon: "🎯"
+  title: Typsicher
+  desc: "Kein Object[]-Cast — der Array-Typ ist korrekt."
+- icon: "🔗"
+  title: Verkettbar
+  desc: Funktioniert am Ende jeder Stream-Pipeline.
+- icon: "📏"
+  title: Prägnant
+  desc: Ein einziger Ausdruck ersetzt die manuelle Schleife.
+support:
+  description: Weitgehend verfügbar seit JDK 8 (März 2014)
diff --git a/translations/content/de/collections/unmodifiable-collectors.yaml b/translations/content/de/collections/unmodifiable-collectors.yaml
new file mode 100644
index 0000000..d1b8c72
--- /dev/null
+++ b/translations/content/de/collections/unmodifiable-collectors.yaml
@@ -0,0 +1,21 @@
+title: Nicht-modifizierbare Collectors
+oldApproach: collectingAndThen
+modernApproach: "stream.toList()"
+summary: "Direkt in eine nicht-modifizierbare Liste mit stream.toList() sammeln."
+explanation: "Java 10 fügte toUnmodifiableList(), toUnmodifiableSet() und toUnmodifiableMap()\
+  \ hinzu, um den ausführlichen collectingAndThen-Wrapper zu ersetzen. Für Listen\
+  \ bietet stream.toList() aus Java 16 eine noch einfachere Alternative — ganz ohne\
+  \ collect()-Aufruf. Für andere Kollektionstypen toUnmodifiableSet() und\
+  \ toUnmodifiableMap() verwenden."
+whyModernWins:
+- icon: "📏"
+  title: Kürzest möglich
+  desc: "stream.toList() benötigt weder collect() noch einen Collectors-Import."
+- icon: "🔒"
+  title: Unveränderlich
+  desc: "Das Ergebnis kann nicht geändert werden — keine versehentlichen Mutationen."
+- icon: "📖"
+  title: Lesbar
+  desc: Liest sich natürlich als abschließender Schritt jeder Stream-Pipeline.
+support:
+  description: Weitgehend verfügbar seit JDK 16 (März 2021)
diff --git a/translations/content/de/concurrency/completablefuture-chaining.yaml b/translations/content/de/concurrency/completablefuture-chaining.yaml
new file mode 100644
index 0000000..ca398fa
--- /dev/null
+++ b/translations/content/de/concurrency/completablefuture-chaining.yaml
@@ -0,0 +1,19 @@
+title: CompletableFuture-Verkettung
+oldApproach: "Blockierendes Future.get()"
+modernApproach: CompletableFuture
+summary: Asynchrone Operationen ohne Blockierung mit CompletableFuture verketten.
+explanation: "CompletableFuture ermöglicht nicht-blockierende asynchrone Pipelines.\
+  \ Operationen mit thenApply, thenCompose, thenAccept verketten. Fehler mit\
+  \ exceptionally() behandeln. Mehrere Futures mit allOf/anyOf kombinieren."
+whyModernWins:
+- icon: "🔗"
+  title: Verkettbar
+  desc: Asynchrone Schritte zu einer lesbaren Pipeline zusammenfügen.
+- icon: "🚫"
+  title: Nicht-blockierend
+  desc: Kein Thread wartet untätig auf Ergebnisse.
+- icon: "🛡️"
+  title: Fehlerbehandlung
+  desc: "exceptionally() und handle() für saubere Fehlerwiederherstellung."
+support:
+  description: Weitgehend verfügbar seit JDK 8 (März 2014)
diff --git a/translations/content/de/concurrency/concurrent-http-virtual.yaml b/translations/content/de/concurrency/concurrent-http-virtual.yaml
new file mode 100644
index 0000000..3421e61
--- /dev/null
+++ b/translations/content/de/concurrency/concurrent-http-virtual.yaml
@@ -0,0 +1,19 @@
+title: Parallele HTTP-Anfragen mit Virtual Threads
+oldApproach: Thread-Pool + URLConnection
+modernApproach: Virtual Threads + HttpClient
+summary: Viele URLs gleichzeitig mit Virtual Threads und HttpClient abrufen.
+explanation: "Virtual Threads machen es praktikabel, einen Thread pro HTTP-Anfrage\
+  \ zu erstellen. In Kombination mit HttpClient ersetzt dies komplexe asynchrone\
+  \ Callback-Muster durch einfachen blockierenden Code, der skaliert."
+whyModernWins:
+- icon: "♾️"
+  title: Ein Thread pro Anfrage
+  desc: "Kein Pool-Sizing — ein Virtual Thread pro URL."
+- icon: "📖"
+  title: Einfacher Code
+  desc: Unkomplizierten blockierenden Code schreiben.
+- icon: "⚡"
+  title: Hoher Durchsatz
+  desc: Tausende von gleichzeitigen Anfragen mit minimalen Ressourcen.
+support:
+  description: Weitgehend verfügbar seit JDK 21 LTS (Sept. 2023)
diff --git a/translations/content/de/concurrency/executor-try-with-resources.yaml b/translations/content/de/concurrency/executor-try-with-resources.yaml
new file mode 100644
index 0000000..7fb6a6d
--- /dev/null
+++ b/translations/content/de/concurrency/executor-try-with-resources.yaml
@@ -0,0 +1,19 @@
+title: ExecutorService automatisch schließen
+oldApproach: Manuelles Herunterfahren
+modernApproach: try-with-resources
+summary: try-with-resources für das automatische Herunterfahren des Executors verwenden.
+explanation: "Seit Java 19 implementiert ExecutorService AutoCloseable. Die Methode\
+  \ close() ruft shutdown() auf und wartet auf den Abschluss der Aufgaben. Keine\
+  \ manuellen try/finally-Shutdown-Muster mehr."
+whyModernWins:
+- icon: "🧹"
+  title: Automatische Bereinigung
+  desc: Das Herunterfahren erfolgt automatisch beim Verlassen des Blocks.
+- icon: "🛡️"
+  title: Keine Lecks
+  desc: "Der Executor wird immer heruntergefahren, auch bei Ausnahmen."
+- icon: "📖"
+  title: Bekanntes Muster
+  desc: "Dasselbe try-with-resources wie für Dateien, Verbindungen usw."
+support:
+  description: Weitgehend verfügbar seit JDK 19 (Sept. 2022)
diff --git a/translations/content/de/concurrency/lock-free-lazy-init.yaml b/translations/content/de/concurrency/lock-free-lazy-init.yaml
new file mode 100644
index 0000000..7153058
--- /dev/null
+++ b/translations/content/de/concurrency/lock-free-lazy-init.yaml
@@ -0,0 +1,19 @@
+title: Sperrenfreie Lazy-Initialisierung
+oldApproach: synchronized + volatile
+modernApproach: StableValue
+summary: Double-Checked Locking durch StableValue für Lazy-Singletons ersetzen.
+explanation: "StableValue kapselt das Lazy-Initialisierungsmuster mit korrekter\
+  \ Thread-Sicherheit. Die JVM kann den Lesepfad nach der Initialisierung optimieren\
+  \ und ihn potenziell schneller als volatile-Lesevorgänge machen."
+whyModernWins:
+- icon: "🧹"
+  title: Kein Boilerplate
+  desc: "Kein volatile, synchronized oder doppelte Null-Prüfung."
+- icon: "⚡"
+  title: Schnellere Lesevorgänge
+  desc: Die JVM kann den Wert nach der Initialisierung konstant falten.
+- icon: "✅"
+  title: Nachweislich korrekt
+  desc: "Keine subtilen Reihenfolge-Fehler — die JVM kümmert sich darum."
+support:
+  description: "Preview in JDK 25 (JEP 502, StableValue). Erfordert --enable-preview."
diff --git a/translations/content/de/concurrency/process-api.yaml b/translations/content/de/concurrency/process-api.yaml
new file mode 100644
index 0000000..f6323b9
--- /dev/null
+++ b/translations/content/de/concurrency/process-api.yaml
@@ -0,0 +1,19 @@
+title: Moderne Prozess-API
+oldApproach: "Runtime.exec()"
+modernApproach: ProcessHandle
+summary: OS-Prozesse mit ProcessHandle inspizieren und verwalten.
+explanation: "ProcessHandle stellt PIDs, Prozessinformationen (Befehl, Argumente,\
+  \ Startzeit, CPU-Nutzung), Eltern-Kind-Beziehungen und Prozessbeendigung bereit.\
+  \ Keine undokumentierten Process-Interna mehr."
+whyModernWins:
+- icon: "🔍"
+  title: Vollständige Informationen
+  desc: "Zugriff auf PID, Befehl, Argumente, Startzeit, CPU-Nutzung."
+- icon: "🌳"
+  title: Prozessbaum
+  desc: "Zwischen Eltern, Kindern und Nachkommen navigieren."
+- icon: "📊"
+  title: Überwachung
+  desc: "onExit() gibt ein CompletableFuture für asynchrone Überwachung zurück."
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/concurrency/scoped-values.yaml b/translations/content/de/concurrency/scoped-values.yaml
new file mode 100644
index 0000000..74a4f5e
--- /dev/null
+++ b/translations/content/de/concurrency/scoped-values.yaml
@@ -0,0 +1,20 @@
+title: Scoped Values
+oldApproach: ThreadLocal
+modernApproach: ScopedValue
+summary: Daten über den Aufruf-Stack sicher teilen ohne die Fallstricke von ThreadLocal.
+explanation: "ScopedValue bietet unveränderlichen, vererbbaren, bereichsbegrenzten\
+  \ Kontext. Im Gegensatz zu ThreadLocal werden Scoped Values automatisch bereinigt,\
+  \ funktionieren mit Virtual Threads und können von aufgerufenen Methoden nicht\
+  \ verändert werden."
+whyModernWins:
+- icon: "🔒"
+  title: Unveränderlich
+  desc: Aufgerufene Methoden können den Scoped Value lesen, aber nie ändern.
+- icon: "🧹"
+  title: Automatische Bereinigung
+  desc: "Kein manuelles remove() — der Wert ist auf den Block beschränkt."
+- icon: "⚡"
+  title: Virtual-Thread-sicher
+  desc: Funktioniert effizient mit Millionen von Virtual Threads.
+support:
+  description: "Finalisiert in JDK 25 LTS (JEP 506, Sept. 2025)."
diff --git a/translations/content/de/concurrency/stable-values.yaml b/translations/content/de/concurrency/stable-values.yaml
new file mode 100644
index 0000000..b1d58f5
--- /dev/null
+++ b/translations/content/de/concurrency/stable-values.yaml
@@ -0,0 +1,20 @@
+title: Stable Values
+oldApproach: Double-Checked Locking
+modernApproach: StableValue
+summary: Thread-sichere Lazy-Initialisierung ohne volatile oder synchronized.
+explanation: "StableValue bietet einen träge initialisierten, unveränderlichen Wert\
+  \ mit eingebauter Thread-Sicherheit. Kein Double-Checked Locking, keine volatile-Felder,\
+  \ keine synchronized-Blöcke. Die JVM kann den Lesepfad nach der Initialisierung\
+  \ sogar optimieren."
+whyModernWins:
+- icon: "🧹"
+  title: Null Boilerplate
+  desc: "Kein volatile, synchronized oder Null-Prüfungen."
+- icon: "⚡"
+  title: JVM-optimiert
+  desc: Die JVM kann den Wert nach der Initialisierung falten.
+- icon: "🛡️"
+  title: Garantiert einmalig
+  desc: "Der Supplier wird genau einmal ausgeführt, auch unter Contention."
+support:
+  description: "Preview in JDK 25 (JEP 502). Erfordert --enable-preview."
diff --git a/translations/content/de/concurrency/structured-concurrency.yaml b/translations/content/de/concurrency/structured-concurrency.yaml
new file mode 100644
index 0000000..a77ffce
--- /dev/null
+++ b/translations/content/de/concurrency/structured-concurrency.yaml
@@ -0,0 +1,20 @@
+title: Strukturierte Nebenläufigkeit
+oldApproach: Manueller Thread-Lebenszyklus
+modernApproach: StructuredTaskScope
+summary: Den Lebenszyklus nebenläufiger Aufgaben als eine einzige Arbeitseinheit verwalten.
+explanation: "Strukturierte Nebenläufigkeit behandelt eine Gruppe nebenläufiger\
+  \ Aufgaben als eine einzige Operation. Schlägt eine Teilaufgabe fehl, werden die\
+  \ anderen abgebrochen. Der Scope stellt sicher, dass keine Threads verloren gehen,\
+  \ und schafft klare Eltern-Kind-Beziehungen."
+whyModernWins:
+- icon: "🛡️"
+  title: Keine Thread-Lecks
+  desc: Alle verzweigten Aufgaben werden abgeschlossen, bevor der Scope geschlossen wird.
+- icon: "⚡"
+  title: Schnelles Versagen
+  desc: ShutdownOnFailure bricht Geschwister-Aufgaben ab, wenn eine fehlschlägt.
+- icon: "📐"
+  title: Klare Struktur
+  desc: Der Aufgaben-Lebenszyklus entspricht dem lexikalischen Scope im Code.
+support:
+  description: "Preview in JDK 25 (fünfte Preview, JEP 505). Erfordert --enable-preview."
diff --git a/translations/content/de/concurrency/thread-sleep-duration.yaml b/translations/content/de/concurrency/thread-sleep-duration.yaml
new file mode 100644
index 0000000..9fabecb
--- /dev/null
+++ b/translations/content/de/concurrency/thread-sleep-duration.yaml
@@ -0,0 +1,19 @@
+title: Thread.sleep mit Duration
+oldApproach: Millisekunden
+modernApproach: Duration
+summary: Duration für selbstdokumentierende Zeitangaben verwenden.
+explanation: "Thread.sleep(Duration) macht die Zeiteinheit explizit. Kein Rätselraten\
+  \ mehr, ob 5000 Millisekunden oder Mikrosekunden bedeutet. Funktioniert mit\
+  \ Duration.ofSeconds, ofMillis, ofMinutes usw."
+whyModernWins:
+- icon: "📖"
+  title: Selbstdokumentierend
+  desc: Duration.ofSeconds(5) ist eindeutig.
+- icon: "🛡️"
+  title: Einheitensicher
+  desc: Kein versehentliches Übergeben von Mikrosekunden als Millisekunden.
+- icon: "🧩"
+  title: Kombinierbar
+  desc: "Duration-Arithmetik: plus(), multipliedBy() usw."
+support:
+  description: Weitgehend verfügbar seit JDK 19 (Sept. 2022)
diff --git a/translations/content/de/concurrency/virtual-threads.yaml b/translations/content/de/concurrency/virtual-threads.yaml
new file mode 100644
index 0000000..a5e7059
--- /dev/null
+++ b/translations/content/de/concurrency/virtual-threads.yaml
@@ -0,0 +1,20 @@
+title: Virtual Threads
+oldApproach: Plattform-Threads
+modernApproach: Virtual Threads
+summary: Millionen von leichtgewichtigen Virtual Threads statt schwerer OS-Threads erstellen.
+explanation: "Virtual Threads sind leichtgewichtige Threads, die von der JVM verwaltet\
+  \ werden, nicht vom Betriebssystem. Es können Millionen davon erstellt werden,\
+  \ ohne Thread-Pools zu konfigurieren. Sie sind ideal für E/A-intensive Aufgaben\
+  \ wie HTTP-Aufrufe und Datenbankabfragen."
+whyModernWins:
+- icon: "⚡"
+  title: Leichtgewichtig
+  desc: Virtual Threads verwenden KB an Speicher, Plattform-Threads verwenden MB.
+- icon: "♾️"
+  title: Skalierbar
+  desc: "Millionen von Threads erstellen — kein Pool-Sizing erforderlich."
+- icon: "🧹"
+  title: Einfaches Modell
+  desc: Blockierenden Code schreiben, der wie asynchroner Code skaliert.
+support:
+  description: Weitgehend verfügbar seit JDK 21 LTS (Sept. 2023)

From 8b66cbb3d79e11d3a8b6cbd36a8aa9afca71821f Mon Sep 17 00:00:00 2001
From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>
Date: Thu, 26 Feb 2026 02:47:20 +0000
Subject: [PATCH 3/5] Add German (de) translations for datetime and enterprise
 patterns

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 html-generators/locales.properties            |  1 +
 .../content/de/datetime/date-formatting.yaml  | 17 ++++
 .../de/datetime/duration-and-period.yaml      | 17 ++++
 .../content/de/datetime/hex-format.yaml       | 17 ++++
 .../de/datetime/instant-precision.yaml        | 17 ++++
 .../content/de/datetime/java-time-basics.yaml | 17 ++++
 .../content/de/datetime/math-clamp.yaml       | 17 ++++
 .../ejb-timer-vs-jakarta-scheduler.yaml       | 17 ++++
 .../content/de/enterprise/ejb-vs-cdi.yaml     | 17 ++++
 .../jdbc-resultset-vs-jpa-criteria.yaml       | 17 ++++
 .../content/de/enterprise/jdbc-vs-jooq.yaml   | 17 ++++
 .../content/de/enterprise/jdbc-vs-jpa.yaml    | 17 ++++
 .../jndi-lookup-vs-cdi-injection.yaml         | 17 ++++
 .../de/enterprise/jpa-vs-jakarta-data.yaml    | 17 ++++
 .../jsf-managed-bean-vs-cdi-named.yaml        | 17 ++++
 .../manual-transaction-vs-declarative.yaml    | 17 ++++
 .../enterprise/mdb-vs-reactive-messaging.yaml | 17 ++++
 .../de/enterprise/servlet-vs-jaxrs.yaml       | 17 ++++
 ...ngleton-ejb-vs-cdi-application-scoped.yaml | 17 ++++
 .../de/enterprise/soap-vs-jakarta-rest.yaml   | 17 ++++
 .../de/enterprise/spring-api-versioning.yaml  | 17 ++++
 .../spring-null-safety-jspecify.yaml          | 17 ++++
 .../spring-xml-config-vs-annotations.yaml     | 17 ++++
 translations/strings/de.yaml                  | 82 +++++++++++++++++++
 24 files changed, 457 insertions(+)
 create mode 100644 translations/content/de/datetime/date-formatting.yaml
 create mode 100644 translations/content/de/datetime/duration-and-period.yaml
 create mode 100644 translations/content/de/datetime/hex-format.yaml
 create mode 100644 translations/content/de/datetime/instant-precision.yaml
 create mode 100644 translations/content/de/datetime/java-time-basics.yaml
 create mode 100644 translations/content/de/datetime/math-clamp.yaml
 create mode 100644 translations/content/de/enterprise/ejb-timer-vs-jakarta-scheduler.yaml
 create mode 100644 translations/content/de/enterprise/ejb-vs-cdi.yaml
 create mode 100644 translations/content/de/enterprise/jdbc-resultset-vs-jpa-criteria.yaml
 create mode 100644 translations/content/de/enterprise/jdbc-vs-jooq.yaml
 create mode 100644 translations/content/de/enterprise/jdbc-vs-jpa.yaml
 create mode 100644 translations/content/de/enterprise/jndi-lookup-vs-cdi-injection.yaml
 create mode 100644 translations/content/de/enterprise/jpa-vs-jakarta-data.yaml
 create mode 100644 translations/content/de/enterprise/jsf-managed-bean-vs-cdi-named.yaml
 create mode 100644 translations/content/de/enterprise/manual-transaction-vs-declarative.yaml
 create mode 100644 translations/content/de/enterprise/mdb-vs-reactive-messaging.yaml
 create mode 100644 translations/content/de/enterprise/servlet-vs-jaxrs.yaml
 create mode 100644 translations/content/de/enterprise/singleton-ejb-vs-cdi-application-scoped.yaml
 create mode 100644 translations/content/de/enterprise/soap-vs-jakarta-rest.yaml
 create mode 100644 translations/content/de/enterprise/spring-api-versioning.yaml
 create mode 100644 translations/content/de/enterprise/spring-null-safety-jspecify.yaml
 create mode 100644 translations/content/de/enterprise/spring-xml-config-vs-annotations.yaml
 create mode 100644 translations/strings/de.yaml

diff --git a/html-generators/locales.properties b/html-generators/locales.properties
index 947e1de..23230f6 100644
--- a/html-generators/locales.properties
+++ b/html-generators/locales.properties
@@ -1,4 +1,5 @@
 # format: locale=Display name  (first entry is the default/primary locale)
 en=English
+de=Deutsch
 es=Español
 pt-BR=Português (Brasil)
diff --git a/translations/content/de/datetime/date-formatting.yaml b/translations/content/de/datetime/date-formatting.yaml
new file mode 100644
index 0000000..7fef540
--- /dev/null
+++ b/translations/content/de/datetime/date-formatting.yaml
@@ -0,0 +1,17 @@
+title: Datumsformatierung
+oldApproach: SimpleDateFormat
+modernApproach: DateTimeFormatter
+summary: Formatiere Datumswerte mit dem thread-sicheren, unveränderlichen DateTimeFormatter.
+explanation: DateTimeFormatter ist unveränderlich und thread-sicher, im Gegensatz zu SimpleDateFormat. Er kann als Konstante gespeichert und geteilt werden. Vordefinierte Formatierer wie ISO_LOCAL_DATE stehen für gängige Formate zur Verfügung.
+whyModernWins:
+- icon: 🛡️
+  title: Thread-sicher
+  desc: Formatierer können ohne Synchronisierung zwischen Threads geteilt werden.
+- icon: 📋
+  title: Eingebaute Formate
+  desc: ISO_LOCAL_DATE, ISO_INSTANT usw. für Standardformate.
+- icon: 🔒
+  title: Unveränderlich
+  desc: Kann sicher als static-final-Konstante gespeichert werden.
+support:
+  description: Weitgehend verfügbar seit JDK 8 (März 2014)
diff --git a/translations/content/de/datetime/duration-and-period.yaml b/translations/content/de/datetime/duration-and-period.yaml
new file mode 100644
index 0000000..e7ca1a0
--- /dev/null
+++ b/translations/content/de/datetime/duration-and-period.yaml
@@ -0,0 +1,17 @@
+title: Duration und Period
+oldApproach: Millisekunden-Arithmetik
+modernApproach: Duration / Period
+summary: Berechne Zeitdifferenzen typsicher mit Duration und Period.
+explanation: Duration steht für zeitbasierte Mengen (Stunden, Minuten, Sekunden). Period steht für datumsbasierte Mengen (Jahre, Monate, Tage). ChronoUnit.between() eignet sich für einfache Differenzen. Alle Klassen behandeln Sonderfälle korrekt.
+whyModernWins:
+- icon: 🎯
+  title: Typsicher
+  desc: Duration für Zeit, Period für Datum — keine Verwechslungen.
+- icon: 🛡️
+  title: Korrekte Berechnung
+  desc: Behandelt Sommerzeitumstellungen, Schaltjahre und Schaltsekunden.
+- icon: 📖
+  title: Lesbar
+  desc: ChronoUnit.DAYS.between() liest sich wie natürliche Sprache.
+support:
+  description: Weitgehend verfügbar seit JDK 8 (März 2014)
diff --git a/translations/content/de/datetime/hex-format.yaml b/translations/content/de/datetime/hex-format.yaml
new file mode 100644
index 0000000..5fc000a
--- /dev/null
+++ b/translations/content/de/datetime/hex-format.yaml
@@ -0,0 +1,17 @@
+title: HexFormat
+oldApproach: Manuelle Hex-Konvertierung
+modernApproach: HexFormat
+summary: Konvertiere zwischen Hex-Strings und Byte-Arrays mit HexFormat.
+explanation: HexFormat bietet bidirektionale Hex-Kodierung und -Dekodierung für Bytes, Integers und Arrays. Trennzeichen, Präfix, Suffix sowie Groß- und Kleinschreibung sind konfigurierbar. Manuelles Formatieren und Parsen entfällt.
+whyModernWins:
+- icon: 📐
+  title: Bidirektional
+  desc: Konvertiere Bytes→Hex und Hex→Bytes mit einer einzigen API.
+- icon: 🔧
+  title: Konfigurierbar
+  desc: Trennzeichen, Präfix, Suffix, Groß-/Kleinschreibung.
+- icon: 📦
+  title: Array-Unterstützung
+  desc: Ganze Byte-Arrays auf einmal kodieren und dekodieren.
+support:
+  description: Weitgehend verfügbar seit JDK 17 LTS (September 2021)
diff --git a/translations/content/de/datetime/instant-precision.yaml b/translations/content/de/datetime/instant-precision.yaml
new file mode 100644
index 0000000..292f130
--- /dev/null
+++ b/translations/content/de/datetime/instant-precision.yaml
@@ -0,0 +1,17 @@
+title: Instant mit Nanosekunden-Präzision
+oldApproach: Millisekunden
+modernApproach: Nanosekunden
+summary: Zeitstempel mit Mikrosekunden- oder Nanosekunden-Präzision ermitteln.
+explanation: Java 9 verbesserte die Uhrenauflösung, sodass Instant.now() auf den meisten Plattformen Mikrosekunden-Präzision liefert (auf manchen sogar Nanosekunden). Das veraltete currentTimeMillis() liefert nur Millisekunden.
+whyModernWins:
+- icon: 🎯
+  title: Höhere Präzision
+  desc: Mikrosekunden-/Nanosekunden-Zeitstempel statt Millisekunden.
+- icon: 📐
+  title: Typsicher
+  desc: Instant trägt seine Präzision — keine mehrdeutigen long-Werte.
+- icon: 🌐
+  title: UTC-basiert
+  desc: Instant ist immer in UTC — keine Zeitzonenverwechslungen.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (September 2017)
diff --git a/translations/content/de/datetime/java-time-basics.yaml b/translations/content/de/datetime/java-time-basics.yaml
new file mode 100644
index 0000000..40d43bd
--- /dev/null
+++ b/translations/content/de/datetime/java-time-basics.yaml
@@ -0,0 +1,17 @@
+title: Grundlagen der java.time-API
+oldApproach: Date + Calendar
+modernApproach: java.time.*
+summary: Verwende unveränderliche, klare Datums-/Zeittypen statt Date und Calendar.
+explanation: java.time stellt LocalDate, LocalTime, LocalDateTime, Instant und ZonedDateTime bereit — alle unveränderlich und thread-sicher. Monate sind ab 1 indiziert. Keine Verwirrung mehr durch Calendar.JANUARY = 0.
+whyModernWins:
+- icon: 🔒
+  title: Unveränderlich
+  desc: Datums-/Zeitwerte können nicht versehentlich geändert werden.
+- icon: 📖
+  title: Klare API
+  desc: Month.JANUARY statt 0. DayOfWeek.MONDAY statt 2.
+- icon: 🛡️
+  title: Thread-sicher
+  desc: Keine Synchronisierung nötig — kann frei zwischen Threads geteilt werden.
+support:
+  description: Weitgehend verfügbar seit JDK 8 (März 2014)
diff --git a/translations/content/de/datetime/math-clamp.yaml b/translations/content/de/datetime/math-clamp.yaml
new file mode 100644
index 0000000..83b5a54
--- /dev/null
+++ b/translations/content/de/datetime/math-clamp.yaml
@@ -0,0 +1,17 @@
+title: Math.clamp()
+oldApproach: Verschachteltes min/max
+modernApproach: Math.clamp()
+summary: Einen Wert mit einem einzigen klaren Aufruf auf einen Bereich begrenzen.
+explanation: "Math.clamp(value, min, max) beschränkt einen Wert auf den Bereich [min, max]. Klarer als verschachteltes Math.min/Math.max und verfügbar für int, long, float und double."
+whyModernWins:
+- icon: 📖
+  title: Selbstdokumentierend
+  desc: clamp(value, min, max) ist eindeutig.
+- icon: 🛡️
+  title: Weniger fehleranfällig
+  desc: Kein versehentliches Vertauschen der Reihenfolge von min und max mehr.
+- icon: 🎯
+  title: Alle numerischen Typen
+  desc: Funktioniert mit int, long, float und double.
+support:
+  description: Weitgehend verfügbar seit JDK 21 LTS (September 2023)
diff --git a/translations/content/de/enterprise/ejb-timer-vs-jakarta-scheduler.yaml b/translations/content/de/enterprise/ejb-timer-vs-jakarta-scheduler.yaml
new file mode 100644
index 0000000..1b7e8d7
--- /dev/null
+++ b/translations/content/de/enterprise/ejb-timer-vs-jakarta-scheduler.yaml
@@ -0,0 +1,17 @@
+title: EJB Timer vs. Jakarta Scheduler
+oldApproach: EJB TimerService
+modernApproach: ManagedScheduledExecutorService
+summary: Ersetze schwerfällige EJB-Timer durch den ManagedScheduledExecutorService von Jakarta Concurrency für einfachere Aufgabenplanung.
+explanation: EJB-Timer benötigen einen @Stateless- oder @Singleton-Bean mit einem @Timeout-Callback und XML- oder annotationsbasierten Zeitplanausdrücken. Jakarta Concurrency stellt ManagedScheduledExecutorService bereit, der die vertraute java.util.concurrent-Planungs-API verwendet. Das Ergebnis ist weniger Boilerplate, einfachere Unit-Tests und keine EJB-Container-Abhängigkeit.
+whyModernWins:
+- icon: 🪶
+  title: Weniger Boilerplate
+  desc: "Kein @Timeout-Callback oder ScheduleExpression — verwende die Standard-API von ScheduledExecutorService."
+- icon: 🧪
+  title: Bessere Testbarkeit
+  desc: Einfache Methoden und Executor-Mocks machen Unit-Tests ohne EJB-Container unkompliziert.
+- icon: ☁️
+  title: Cloud-native-freundlich
+  desc: Verwaltete Executors integrieren sich in den Container-Lebenszyklus und funktionieren in leichtgewichtigen Laufzeiten.
+support:
+  description: "Verfügbar seit Jakarta EE 10 / Concurrency 3.0"
diff --git a/translations/content/de/enterprise/ejb-vs-cdi.yaml b/translations/content/de/enterprise/ejb-vs-cdi.yaml
new file mode 100644
index 0000000..2f00355
--- /dev/null
+++ b/translations/content/de/enterprise/ejb-vs-cdi.yaml
@@ -0,0 +1,17 @@
+title: EJB versus CDI
+oldApproach: EJB
+modernApproach: CDI-Bean
+summary: Ersetze schwerfällige EJBs durch leichtgewichtige CDI-Beans für Dependency Injection und Transaktionsverwaltung.
+explanation: CDI (Contexts and Dependency Injection) bietet dieselbe Dependency Injection und Transaktionsverwaltung wie EJBs, jedoch als einfache Java-Klassen ohne containerspezifische Interfaces oder Superklassen. Scopes wie @ApplicationScoped und @RequestScoped steuern den Lebenszyklus, und @Transactional ersetzt die obligatorische EJB-Transaktionssemantik.
+whyModernWins:
+- icon: 🪶
+  title: Leichtgewichtig
+  desc: CDI-Beans sind einfache Java-Klassen ohne EJB-spezifische Interfaces oder Deskriptoren.
+- icon: 💉
+  title: Einheitliche Injektion
+  desc: "@Inject funktioniert für jeden verwalteten Bean, JAX-RS-Ressourcen und Jakarta-EE-Komponenten gleichermaßen."
+- icon: 🧪
+  title: Einfaches Unit-Testing
+  desc: Einfache Klassen ohne EJB-Proxy-Overhead lassen sich unkompliziert instanziieren und mocken.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/jdbc-resultset-vs-jpa-criteria.yaml b/translations/content/de/enterprise/jdbc-resultset-vs-jpa-criteria.yaml
new file mode 100644
index 0000000..3b99342
--- /dev/null
+++ b/translations/content/de/enterprise/jdbc-resultset-vs-jpa-criteria.yaml
@@ -0,0 +1,17 @@
+title: JDBC-ResultSet-Mapping vs. JPA-Criteria-API
+oldApproach: JDBC ResultSet
+modernApproach: JPA Criteria API
+summary: Ersetze manuelles JDBC-ResultSet-Mapping durch die typsichere Criteria-API von JPA für dynamische Abfragen.
+explanation: Rohes JDBC erfordert das Aufbauen von SQL-Strings, das Setzen von Parametern per Index und das manuelle Mappen jeder ResultSet-Spalte — ein fehleranfälliger Prozess, der bei Spaltenänderungen stillschweigend bricht. Die JPA-Criteria-API erstellt Abfragen programmatisch mit einem typsicheren Builder-Muster. Spaltennamen werden gegen das Entity-Modell validiert, das Ergebnis-Mapping erfolgt automatisch, und komplexe dynamische Abfragen lassen sich ohne Stringverkettung sauber zusammenstellen.
+whyModernWins:
+- icon: 🔒
+  title: Typsichere Abfragen
+  desc: Der Criteria-Builder erkennt fehlerhafte Feldnamen und Typfehler zur Kompilierzeit.
+- icon: 🗺️
+  title: Automatisches Mapping
+  desc: JPA bildet Ergebniszeilen auf Entity-Objekte ab — kein manuelles Spalte-für-Spalte-Extrahieren.
+- icon: 🧩
+  title: Kombinierbare Prädikate
+  desc: Dynamische WHERE-Klauseln lassen sich sauber mit and(), or() und wiederverwendbaren Predicate-Objekten aufbauen.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/jdbc-vs-jooq.yaml b/translations/content/de/enterprise/jdbc-vs-jooq.yaml
new file mode 100644
index 0000000..04a08e9
--- /dev/null
+++ b/translations/content/de/enterprise/jdbc-vs-jooq.yaml
@@ -0,0 +1,17 @@
+title: JDBC versus jOOQ
+oldApproach: Rohes JDBC
+modernApproach: jOOQ SQL DSL
+summary: Ersetze stringbasiertes SQL mit rohem JDBC durch das typsichere, fließende SQL-DSL von jOOQ.
+explanation: "jOOQ (Java Object Oriented Querying) generiert Java-Code aus dem Datenbankschema und wandelt Tabellen- und Spaltennamen in typsichere Java-Konstanten um. Das fließende DSL spiegelt die SQL-Syntax wider, sodass Abfragen lesbar und kombinierbar sind. Alle Parameter werden automatisch gebunden, was SQL-Injection-Risiken eliminiert. Anders als JPA/JPQL unterstützt jOOQ SQL vollständig — Fensterfunktionen, CTEs, RETURNING-Klauseln und anbieterspezifische Erweiterungen sind erstklassig."
+whyModernWins:
+- icon: 🔒
+  title: Typsichere Spalten
+  desc: Spaltennamen sind generierte Java-Konstanten — Tippfehler und Typfehler werden zu Kompilierfehlern statt Laufzeitfehlern.
+- icon: 📖
+  title: SQL-Flüssigkeit
+  desc: Das jOOQ-DSL spiegelt die SQL-Syntax eng wider, sodass komplexe JOINs, Unterabfragen und CTEs lesbar bleiben.
+- icon: 🛡️
+  title: Injektionssicher per Design
+  desc: Parameter werden immer sicher gebunden — keine Stringverkettung bedeutet kein SQL-Injection-Risiko.
+support:
+  description: Die Open-Source-Edition von jOOQ unterstützt alle gängigen Open-Source-Datenbanken; ältere kommerzielle Datenbanken erfordern eine kostenpflichtige Lizenz
diff --git a/translations/content/de/enterprise/jdbc-vs-jpa.yaml b/translations/content/de/enterprise/jdbc-vs-jpa.yaml
new file mode 100644
index 0000000..25fa075
--- /dev/null
+++ b/translations/content/de/enterprise/jdbc-vs-jpa.yaml
@@ -0,0 +1,17 @@
+title: JDBC versus JPA
+oldApproach: JDBC
+modernApproach: JPA EntityManager
+summary: Ersetze ausführlichen JDBC-Boilerplate durch das objekt-relationale Mapping und den EntityManager von JPA.
+explanation: "JPA (Jakarta Persistence API) bildet Java-Objekte auf Datenbankzeilen ab und eliminiert manuelles ResultSet-Processing und SQL-Stringverkettung. EntityManager stellt find(), persist() und JPQL-Abfragen bereit, sodass du mit Domänenobjekten statt mit rohem SQL arbeitest, während der Container Connection Pooling und Transaktionen verwaltet."
+whyModernWins:
+- icon: 🗺️
+  title: Objekt-Mapping
+  desc: Entities sind einfache annotierte Klassen — keine manuelle Übersetzung von ResultSet zu Objekt.
+- icon: 🔒
+  title: Typsichere Abfragen
+  desc: JPQL arbeitet auf Entity-Typen und -Feldern statt auf rohen Tabellen- und Spaltenstrings.
+- icon: ⚡
+  title: Eingebautes Caching
+  desc: First- und Second-Level-Caches reduzieren Datenbankzugriffe automatisch.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/jndi-lookup-vs-cdi-injection.yaml b/translations/content/de/enterprise/jndi-lookup-vs-cdi-injection.yaml
new file mode 100644
index 0000000..67ab7f9
--- /dev/null
+++ b/translations/content/de/enterprise/jndi-lookup-vs-cdi-injection.yaml
@@ -0,0 +1,17 @@
+title: JNDI-Lookup vs. CDI-Injektion
+oldApproach: JNDI-Lookup
+modernApproach: CDI @Inject
+summary: Ersetze fragile JNDI-String-Lookups durch typsichere CDI-Injektion für vom Container verwaltete Ressourcen.
+explanation: Das traditionelle JNDI-Muster zwingt zur Verwendung stringbasierter Ressourcennamen, zur Behandlung von NamingException und zur Verwaltung eines InitialContext. CDI-Injektion mit @Inject (oder @Resource für Container-Ressourcen) lässt den Container Abhängigkeiten automatisch verdrahten. Tippfehler werden zu Kompilierfehlern, und Klassen sind leichter zu testen, da Abhängigkeiten direkt injiziert werden können.
+whyModernWins:
+- icon: 🔒
+  title: Typsichere Verdrahtung
+  desc: Injektionsfehler werden zur Deployment-Zeit erkannt, nicht zur Laufzeit über String-Lookups.
+- icon: 🗑️
+  title: Kein Boilerplate
+  desc: Eliminiert InitialContext-Erstellung, JNDI-Namens-Strings und NamingException-Behandlung.
+- icon: 🧪
+  title: Testbar
+  desc: Abhängigkeiten sind injizierte Felder, die in Unit-Tests leicht durch Mocks ersetzt werden können.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/jpa-vs-jakarta-data.yaml b/translations/content/de/enterprise/jpa-vs-jakarta-data.yaml
new file mode 100644
index 0000000..4cf3963
--- /dev/null
+++ b/translations/content/de/enterprise/jpa-vs-jakarta-data.yaml
@@ -0,0 +1,17 @@
+title: JPA versus Jakarta Data
+oldApproach: JPA EntityManager
+modernApproach: Jakarta-Data-Repository
+summary: Deklariere ein Repository-Interface und lass Jakarta Data die DAO-Implementierung automatisch generieren.
+explanation: Jakarta Data (Jakarta EE 11) wandelt den Datenzugriff in eine reine Interface-Deklaration um. Du annotierst ein Interface mit @Repository und erweiterst einen eingebauten Repository-Typ wie CrudRepository. Die Laufzeitumgebung generiert die Implementierung — einschließlich abgeleiteter Abfragen aus Methodennamen wie findByName — sodass kein EntityManager-Boilerplate, keine JPQL-Strings und keine handgeschriebenen save/find-Methoden nötig sind.
+whyModernWins:
+- icon: 🪄
+  title: Null Boilerplate
+  desc: Deklariere das Interface; der Container generiert die vollständige DAO-Implementierung zur Deployment-Zeit.
+- icon: 🔍
+  title: Abgeleitete Abfragen
+  desc: Methodennamen wie findByNameAndStatus werden automatisch geparst — kein JPQL oder SQL nötig.
+- icon: 🔌
+  title: Portabel
+  desc: Jede Jakarta-EE-11-konforme Laufzeitumgebung stellt die Repository-Implementierung ohne Vendor-Lock-in bereit.
+support:
+  description: "Verfügbar seit Jakarta EE 11 / Java 21 (2024)"
diff --git a/translations/content/de/enterprise/jsf-managed-bean-vs-cdi-named.yaml b/translations/content/de/enterprise/jsf-managed-bean-vs-cdi-named.yaml
new file mode 100644
index 0000000..beb9777
--- /dev/null
+++ b/translations/content/de/enterprise/jsf-managed-bean-vs-cdi-named.yaml
@@ -0,0 +1,17 @@
+title: JSF Managed Bean vs. CDI Named Bean
+oldApproach: "@ManagedBean"
+modernApproach: "@Named + CDI"
+summary: Ersetze das veraltete JSF-@ManagedBean durch CDI-@Named für ein einheitliches Dependency-Injection-Modell.
+explanation: JSFs @ManagedBean und @ManagedProperty wurden in Jakarta Faces 2.3 als veraltet markiert und in Jakarta EE 10 entfernt. Der CDI-basierte Ersatz verwendet @Named, um den Bean für EL-Ausdrücke verfügbar zu machen, und @Inject für die Abhängigkeitsverdrahtung. Dies vereinheitlicht das Bean-Modell — JSF-Seiten, JAX-RS-Ressourcen und EJBs teilen denselben CDI-Container.
+whyModernWins:
+- icon: 🔗
+  title: Einheitliches Modell
+  desc: Ein einziger CDI-Container verwaltet alle Beans — JSF, REST und Service-Schichten teilen dieselbe Injektion.
+- icon: 🗑️
+  title: Weniger Boilerplate
+  desc: "@Inject ersetzt @ManagedProperty und dessen erforderliche Setter-Methode."
+- icon: 🔮
+  title: Zukunftssicher
+  desc: "@ManagedBean wurde in Jakarta EE 10 entfernt; @Named ist der unterstützte Ersatz."
+support:
+  description: "CDI @Named verfügbar seit Java EE 6; @ManagedBean entfernt in Jakarta EE 10"
diff --git a/translations/content/de/enterprise/manual-transaction-vs-declarative.yaml b/translations/content/de/enterprise/manual-transaction-vs-declarative.yaml
new file mode 100644
index 0000000..2fde273
--- /dev/null
+++ b/translations/content/de/enterprise/manual-transaction-vs-declarative.yaml
@@ -0,0 +1,17 @@
+title: Manuelle JPA-Transaktion vs. deklaratives @Transactional
+oldApproach: Manuelle Transaktion
+modernApproach: "@Transactional"
+summary: Ersetze ausführliche begin/commit/rollback-Blöcke durch eine einzige @Transactional-Annotation.
+explanation: Manuelle Transaktionsverwaltung erfordert explizite begin()-, commit()- und rollback()-Aufrufe, die in try-catch-Blöcke eingebettet sind — jede Service-Methode wiederholt diesen Boilerplate. Die @Transactional-Annotation delegiert das Lebenszyklusmanagement an den Container — er startet vor der Methode eine Transaktion, bestätigt bei Erfolg und führt bei RuntimeException automatisch ein Rollback durch.
+whyModernWins:
+- icon: 🗑️
+  title: Kein Boilerplate
+  desc: Eine einzige Annotation ersetzt sich wiederholende begin/commit/rollback-try-catch-Blöcke.
+- icon: 🛡️
+  title: Sichereres Rollback
+  desc: Der Container garantiert Rollback bei ungeprüften Exceptions — kein Risiko, den catch-Block zu vergessen.
+- icon: 📐
+  title: Deklarative Steuerung
+  desc: Propagation, Isolation und Rollback-Regeln werden als Annotationsattribute ausgedrückt.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/mdb-vs-reactive-messaging.yaml b/translations/content/de/enterprise/mdb-vs-reactive-messaging.yaml
new file mode 100644
index 0000000..bf364c3
--- /dev/null
+++ b/translations/content/de/enterprise/mdb-vs-reactive-messaging.yaml
@@ -0,0 +1,17 @@
+title: Message-Driven Bean vs. Reactive Messaging
+oldApproach: Message-Driven Bean
+modernApproach: Reactive Messaging
+summary: Ersetze JMS-Message-Driven-Beans durch MicroProfile Reactive Messaging für einfachere Ereignisverarbeitung.
+explanation: Message-Driven Beans erfordern die Implementierung von MessageListener, die Konfiguration von Aktivierungseigenschaften und die manuelle Deserialisierung von JMS-Nachrichten. MicroProfile Reactive Messaging verwendet eine einfache @Incoming-Annotation an einer Methode, die typisierte Objekte direkt empfängt. Die Kanal-Konfiguration wird ausgelagert, was den Code broker-agnostisch und wesentlich einfacher zu testen macht.
+whyModernWins:
+- icon: 🪶
+  title: Minimaler Code
+  desc: "Eine einzige @Incoming-Methode ersetzt die MDB-Klasse, das MessageListener-Interface und die Aktivierungskonfiguration."
+- icon: 🔌
+  title: Broker-agnostisch
+  desc: Tausche Kafka-, AMQP- oder JMS-Connectoren per Konfiguration aus, ohne den Anwendungscode zu ändern.
+- icon: ☁️
+  title: Cloud-native geeignet
+  desc: Reaktive Streams-Gegendruck und leichtgewichtige Laufzeit machen es ideal für containerisierte Deployments.
+support:
+  description: "Verfügbar seit MicroProfile 4.0 / SmallRye Reactive Messaging"
diff --git a/translations/content/de/enterprise/servlet-vs-jaxrs.yaml b/translations/content/de/enterprise/servlet-vs-jaxrs.yaml
new file mode 100644
index 0000000..629d554
--- /dev/null
+++ b/translations/content/de/enterprise/servlet-vs-jaxrs.yaml
@@ -0,0 +1,17 @@
+title: Servlet versus JAX-RS
+oldApproach: HttpServlet
+modernApproach: JAX-RS-Ressource
+summary: Ersetze ausführlichen HttpServlet-Boilerplate durch deklarative JAX-RS-Ressourcenklassen.
+explanation: "JAX-RS (Jakarta RESTful Web Services) ermöglicht das Bereitstellen von REST-Endpunkten mit einfachen Annotationen wie @GET, @Path und @Produces. Kein manuelles Parsen von Request-Parametern oder Setzen von Content-Types in der Response mehr — die Laufzeitumgebung übernimmt Marshalling und Routing automatisch."
+whyModernWins:
+- icon: 📐
+  title: Deklaratives Routing
+  desc: Annotationen definieren HTTP-Methode, Pfad und Content-Type statt imperativem if/else-Dispatch.
+- icon: 🔄
+  title: Automatisches Marshalling
+  desc: "POJOs direkt zurückgeben; die Laufzeit serialisiert sie basierend auf @Produces nach JSON oder XML."
+- icon: 🧪
+  title: Einfacheres Testen
+  desc: Ressourcenklassen sind einfache Java-Objekte, testbar ohne Servlet-Container.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/singleton-ejb-vs-cdi-application-scoped.yaml b/translations/content/de/enterprise/singleton-ejb-vs-cdi-application-scoped.yaml
new file mode 100644
index 0000000..2d6f7d1
--- /dev/null
+++ b/translations/content/de/enterprise/singleton-ejb-vs-cdi-application-scoped.yaml
@@ -0,0 +1,17 @@
+title: Singleton EJB vs. CDI @ApplicationScoped
+oldApproach: "@Singleton EJB"
+modernApproach: "@ApplicationScoped CDI"
+summary: Ersetze Singleton-EJBs durch CDI-@ApplicationScoped-Beans für eine einfachere Verwaltung von gemeinsamem Zustand.
+explanation: "Singleton-EJBs bündeln Concurrency-Management (@Lock, @ConcurrencyManagement) und frühzeitige Initialisierung (@Startup) im EJB-Container. Ein CDI-@ApplicationScoped-Bean erreicht denselben Single-Instance-Lebenszyklus mit wesentlich weniger Aufwand. Wenn Concurrency-Steuerung benötigt wird, bieten Standard-java.util.concurrent-Hilfsmittel feinere Kontrolle als die EJB-Lock-Annotationen."
+whyModernWins:
+- icon: 🪶
+  title: Weniger Annotations-Rauschen
+  desc: "Kein @ConcurrencyManagement, @Lock oder @Startup — nur eine einzige @ApplicationScoped-Annotation."
+- icon: 🔧
+  title: Flexible Nebenläufigkeit
+  desc: Verwende java.util.concurrent-Locks oder volatile für genau die benötigte Thread-Sicherheit.
+- icon: 🧪
+  title: Einfaches Testen
+  desc: Einfache CDI-Beans können in Tests direkt ohne EJB-Container instanziiert werden.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/soap-vs-jakarta-rest.yaml b/translations/content/de/enterprise/soap-vs-jakarta-rest.yaml
new file mode 100644
index 0000000..ae92094
--- /dev/null
+++ b/translations/content/de/enterprise/soap-vs-jakarta-rest.yaml
@@ -0,0 +1,17 @@
+title: SOAP-Webservices vs. Jakarta REST
+oldApproach: JAX-WS / SOAP
+modernApproach: Jakarta REST / JSON
+summary: Ersetze schwerfällige SOAP/WSDL-Endpunkte durch saubere Jakarta-REST-Ressourcen, die JSON zurückgeben.
+explanation: SOAP-basierte Webservices stützen sich auf WSDL-Verträge, XML-Marshalling und JAX-WS-Annotationen, die erheblichen Overhead erzeugen. Jakarta REST (ehemals JAX-RS) verwendet intuitive Annotationen wie @GET, @Path und @Produces, um RESTful-JSON-APIs bereitzustellen. Das Programmiermodell ist einfacher, die Nutzlasten sind kleiner, und der Ansatz entspricht der Kommunikationsweise moderner Microservices.
+whyModernWins:
+- icon: 🪶
+  title: Leichtere Nutzlasten
+  desc: JSON ist kompakter als SOAP-XML-Envelopes und reduziert Bandbreite sowie Parse-Overhead.
+- icon: 📐
+  title: Einfache Annotationen
+  desc: "@GET, @Path und @Produces ersetzen den Aufwand von WSDL, @WebService und @WebMethod."
+- icon: 🔌
+  title: Microservice-bereit
+  desc: REST/JSON ist der Standard für Service-zu-Service-Kommunikation in Cloud-nativen Architekturen.
+support:
+  description: Weitgehend verfügbar seit Jakarta EE 8 / Java 11
diff --git a/translations/content/de/enterprise/spring-api-versioning.yaml b/translations/content/de/enterprise/spring-api-versioning.yaml
new file mode 100644
index 0000000..1a560ce
--- /dev/null
+++ b/translations/content/de/enterprise/spring-api-versioning.yaml
@@ -0,0 +1,17 @@
+title: API-Versionierung in Spring Framework 7
+oldApproach: Manuelle URL-Pfad-Versionierung
+modernApproach: Native API-Versionierung
+summary: Ersetze duplizierte, versionspräfixierte Controller durch die native API-Versionierungsunterstützung von Spring Framework 7.
+explanation: Vor Spring Framework 7 erforderte API-Versionierung separate Controller-Klassen pro Version (z. B. /api/v1/products, /api/v2/products), was Request-Mappings duplizierte und Versionslogik über viele Dateien verteilte. Spring Framework 7 führt native Versionierung über ein neues version-Attribut in @RequestMapping und verwandten Annotationen sowie einen configureApiVersioning-Hook in WebMvcConfigurer ein. Die Version kann aus einem Request-Header, einem URL-Pfadsegment oder einem Query-Parameter aufgelöst werden — alles zentral gesteuert.
+whyModernWins:
+- icon: 🗂️
+  title: Keine Controller-Duplizierung
+  desc: Alle Versionen leben in einer Controller-Klasse; nur die einzelnen Handler-Methoden tragen ein version-Attribut.
+- icon: ⚙️
+  title: Zentralisierte Versionsstrategie
+  desc: Wechsle von Header- zu URL- oder Query-Parameter-Versionierung in einem einzigen configureApiVersioning-Aufruf.
+- icon: 📈
+  title: Inkrementelle Weiterentwicklung
+  desc: Füge eine neue Version zu einer Methode hinzu, ohne nicht verwandte Endpunkte zu berühren oder neue Controller-Dateien zu erstellen.
+support:
+  description: "Verfügbar seit Spring Framework 7.0 (erfordert Java 17+)"
diff --git a/translations/content/de/enterprise/spring-null-safety-jspecify.yaml b/translations/content/de/enterprise/spring-null-safety-jspecify.yaml
new file mode 100644
index 0000000..f7a14be
--- /dev/null
+++ b/translations/content/de/enterprise/spring-null-safety-jspecify.yaml
@@ -0,0 +1,17 @@
+title: Spring Null-Sicherheit mit JSpecify
+oldApproach: Spring @NonNull/@Nullable
+modernApproach: JSpecify @NullMarked
+summary: Spring 7 übernimmt JSpecify-Annotationen, macht Non-Null zum Standard und reduziert Annotations-Rauschen.
+explanation: "Spring 5 und 6 führten eigene Null-Sicherheits-Annotationen im Paket `org.springframework.lang` ein. Obwohl nützlich, waren diese framework-spezifisch und erforderten die explizite Annotation jedes Non-Null-Elements. Spring 7 migriert zu JSpecify, einem ökosystemübergreifenden Standard für Null-Sicherheit. Die `@NullMarked`-Annotation auf Klassen- oder Paketebene deklariert, dass alle nicht annotierten Typen standardmäßig Non-Null sind. Nur tatsächlich nullable Typen benötigen die `@Nullable`-Annotation, was die Ausführlichkeit drastisch reduziert. JSpecify-Annotationen werden von wichtigen statischen Analysetools wie NullAway, Error Prone und IntelliJ IDEA erkannt und bieten umfangreichere Tooling-Unterstützung als Spring-spezifische Annotationen."
+whyModernWins:
+- icon: ✂️
+  title: Non-Null als Standard
+  desc: "@NullMarked macht alle nicht annotierten Typen zu Non-Null, sodass nur nullable Ausnahmen annotiert werden müssen."
+- icon: 🌐
+  title: Ökosystem-Standard
+  desc: JSpecify-Annotationen sind ein framework-übergreifender Standard, der von NullAway, Error Prone und IDEs erkannt wird.
+- icon: 🔍
+  title: Umfangreicheres Tooling
+  desc: Moderne statische Analysatoren verstehen das Null-Modell von JSpecify und melden Verstöße zur Kompilierzeit.
+support:
+  description: "Verfügbar seit Spring Framework 7.0 (erfordert Java 17+)"
diff --git a/translations/content/de/enterprise/spring-xml-config-vs-annotations.yaml b/translations/content/de/enterprise/spring-xml-config-vs-annotations.yaml
new file mode 100644
index 0000000..5cd45ac
--- /dev/null
+++ b/translations/content/de/enterprise/spring-xml-config-vs-annotations.yaml
@@ -0,0 +1,17 @@
+title: Spring XML-Bean-Konfiguration vs. annotationsbasiert
+oldApproach: XML-Bean-Definitionen
+modernApproach: Annotationsbasierte Beans
+summary: Ersetze ausführliche Spring-XML-Bean-Definitionen durch prägnante annotationsbasierte Konfiguration mit Spring Boot.
+explanation: "Traditionelle Spring-Anwendungen verdrahteten Beans über XML-Konfigurationsdateien und deklarierten jede Klasse mit ihren Abhängigkeiten als ausführliche <bean>-Elemente. Obwohl Annotationsunterstützung seit Spring 2.5 existierte, blieb XML der vorherrschende Ansatz, bis Spring Boot Auto-Konfiguration einführte. Spring Boot erkennt Beans, die mit @Component, @Service, @Repository und @Controller annotiert sind, per Classpath-Scanning, erfüllt Abhängigkeiten automatisch per Konstruktorinjektion und konfiguriert Infrastruktur wie DataSource vom Classpath — was alle XML-Verdrahtungsdateien eliminiert."
+whyModernWins:
+- icon: 🚫
+  title: Kein XML
+  desc: "@SpringBootApplication aktiviert Component-Scanning und Auto-Konfiguration und eliminiert alle XML-Verdrahtungsdateien."
+- icon: 💉
+  title: Konstruktorinjektion
+  desc: Spring injiziert Abhängigkeiten automatisch über Konstruktoren, was Beans einfacher zu testen und nachzuvollziehen macht.
+- icon: ⚡
+  title: Auto-Konfiguration
+  desc: Spring Boot konfiguriert DataSource, JPA und andere Infrastruktur vom Classpath ohne Boilerplate.
+support:
+  description: "Weitgehend verfügbar seit Spring Boot 1.0 (April 2014); Spring Boot 3 erfordert Java 17+"
diff --git a/translations/strings/de.yaml b/translations/strings/de.yaml
new file mode 100644
index 0000000..e307049
--- /dev/null
+++ b/translations/strings/de.yaml
@@ -0,0 +1,82 @@
+site:
+  title: java.evolved
+  tagline: Java hat sich weiterentwickelt. Dein Code auch.
+  tagline_line1: Java hat sich weiterentwickelt.
+  tagline_line2: Dein Code auch.
+  description: Eine Sammlung moderner Java-Code-Snippets. Jedes alte Java-Muster neben
+    seiner sauberen, modernen Entsprechung — Seite an Seite.
+  heroSnippetCount: ✦ {{snippetCount}} moderne Muster · Java 8 → Java 25
+  heroOld: Alt
+  heroModern: Modern
+  allComparisons: Alle Vergleiche
+  snippetsBadge: '{{snippetCount}} Snippets'
+nav:
+  allPatterns: ← Alle Muster
+  toggleTheme: Design wechseln
+  viewOnGitHub: Auf GitHub ansehen
+  selectLanguage: Sprache auswählen
+breadcrumb:
+  home: Startseite
+sections:
+  codeComparison: Code-Vergleich
+  whyModernWins: Warum der moderne Weg gewinnt
+  oldApproach: Alter Ansatz
+  modernApproach: Moderner Ansatz
+  sinceJdk: Seit JDK
+  difficulty: Schwierigkeitsgrad
+  jdkSupport: JDK-Unterstützung
+  howItWorks: Wie es funktioniert
+  relatedDocs: Zugehörige Dokumentation
+  relatedPatterns: Verwandte Muster
+filters:
+  show: 'Anzeigen:'
+  all: Alle
+difficulty:
+  beginner: Einsteiger
+  intermediate: Fortgeschritten
+  advanced: Experte
+search:
+  placeholder: Snippets suchen…
+  noResults: Keine Ergebnisse gefunden.
+  esc: ESC
+  searchTrigger: Suchen…
+  navigate: navigieren
+  open: öffnen
+  close: schließen
+cards:
+  old: Alt
+  modern: Modern
+  hoverHint: Hover für Modernes →
+  hoverHintRelated: Hover für Modernes ➜
+  touchHint: 👆 tippen oder wischen →
+copy:
+  copy: Kopieren
+  copied: Kopiert!
+share:
+  label: Teilen
+view:
+  expandAll: Alle ausklappen
+  collapseAll: Alle einklappen
+stats:
+  modernPatterns: Moderne Muster
+  jdkVersions: Abgedeckte JDK-Versionen
+  categories: Kategorien
+  linesOfPython: Benötigte Python-Zeilen
+footer:
+  tagline: Java hat sich weiterentwickelt. Dein Code auch.
+  madeWith: Erstellt mit ❤️ von
+  and: und
+  inspiredBy: Inspiriert von
+  viewOnGitHub: Auf GitHub ansehen
+copilot:
+  headline: Modernisiere deine Java-Codebasis mit GitHub Copilot.
+  description: Lass Copilot dir helfen, veraltete Muster zu modernem Java zu migrieren — automatisch.
+  appModernization: App-Modernisierung →
+  javaGuide: Java-Leitfaden →
+support:
+  available: Verfügbar
+  preview: Vorschau
+  experimental: Experimentell
+untranslated:
+  notice: Diese Seite wurde noch nicht ins {{localeName}} übersetzt.
+  viewInEnglish: Auf Englisch ansehen

From 58315c7e6e461bd4d8cca913d0f761a0eadee8a0 Mon Sep 17 00:00:00 2001
From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>
Date: Thu, 26 Feb 2026 02:52:29 +0000
Subject: [PATCH 4/5] Add German (de) translations for errors, io, and language
 categories

Create 39 German YAML translation files covering:
- errors: helpful-npe, multi-catch, null-in-switch, optional-chaining,
  optional-orelsethrow, record-based-errors, require-nonnull-else
- io: deserialization-filters, file-memory-mapping, files-mismatch,
  http-client, inputstream-transferto, io-class-console-io, path-of,
  reading-files, try-with-resources-effectively-final, writing-files
- language: compact-canonical-constructor, compact-source-files,
  default-interface-methods, diamond-operator, exhaustive-switch,
  flexible-constructor-bodies, guarded-patterns, markdown-javadoc-comments,
  module-import-declarations, pattern-matching-instanceof,
  pattern-matching-switch, primitive-types-in-patterns,
  private-interface-methods, record-patterns, records-for-data-classes,
  sealed-classes, static-members-in-inner-classes,
  static-methods-in-interfaces, switch-expressions,
  text-blocks-for-multiline-strings, type-inference-with-var,
  unnamed-variables

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 translations/content/de/errors/helpful-npe.yaml | 17 +++++++++++++++++
 translations/content/de/errors/multi-catch.yaml | 17 +++++++++++++++++
 .../content/de/errors/null-in-switch.yaml       | 17 +++++++++++++++++
 .../content/de/errors/optional-chaining.yaml    | 17 +++++++++++++++++
 .../content/de/errors/optional-orelsethrow.yaml | 17 +++++++++++++++++
 .../content/de/errors/record-based-errors.yaml  | 17 +++++++++++++++++
 .../content/de/errors/require-nonnull-else.yaml | 17 +++++++++++++++++
 .../content/de/io/deserialization-filters.yaml  | 17 +++++++++++++++++
 .../content/de/io/file-memory-mapping.yaml      | 17 +++++++++++++++++
 translations/content/de/io/files-mismatch.yaml  | 17 +++++++++++++++++
 translations/content/de/io/http-client.yaml     | 17 +++++++++++++++++
 .../content/de/io/inputstream-transferto.yaml   | 17 +++++++++++++++++
 .../content/de/io/io-class-console-io.yaml      | 17 +++++++++++++++++
 translations/content/de/io/path-of.yaml         | 17 +++++++++++++++++
 translations/content/de/io/reading-files.yaml   | 17 +++++++++++++++++
 .../try-with-resources-effectively-final.yaml   | 17 +++++++++++++++++
 translations/content/de/io/writing-files.yaml   | 17 +++++++++++++++++
 .../language/compact-canonical-constructor.yaml | 17 +++++++++++++++++
 .../de/language/compact-source-files.yaml       | 17 +++++++++++++++++
 .../de/language/default-interface-methods.yaml  | 17 +++++++++++++++++
 .../content/de/language/diamond-operator.yaml   | 17 +++++++++++++++++
 .../content/de/language/exhaustive-switch.yaml  | 17 +++++++++++++++++
 .../language/flexible-constructor-bodies.yaml   | 17 +++++++++++++++++
 .../content/de/language/guarded-patterns.yaml   | 17 +++++++++++++++++
 .../de/language/markdown-javadoc-comments.yaml  | 17 +++++++++++++++++
 .../de/language/module-import-declarations.yaml | 17 +++++++++++++++++
 .../language/pattern-matching-instanceof.yaml   | 17 +++++++++++++++++
 .../de/language/pattern-matching-switch.yaml    | 17 +++++++++++++++++
 .../language/primitive-types-in-patterns.yaml   | 17 +++++++++++++++++
 .../de/language/private-interface-methods.yaml  | 17 +++++++++++++++++
 .../content/de/language/record-patterns.yaml    | 17 +++++++++++++++++
 .../de/language/records-for-data-classes.yaml   | 17 +++++++++++++++++
 .../content/de/language/sealed-classes.yaml     | 17 +++++++++++++++++
 .../static-members-in-inner-classes.yaml        | 17 +++++++++++++++++
 .../language/static-methods-in-interfaces.yaml  | 17 +++++++++++++++++
 .../content/de/language/switch-expressions.yaml | 17 +++++++++++++++++
 .../text-blocks-for-multiline-strings.yaml      | 17 +++++++++++++++++
 .../de/language/type-inference-with-var.yaml    | 17 +++++++++++++++++
 .../content/de/language/unnamed-variables.yaml  | 17 +++++++++++++++++
 39 files changed, 663 insertions(+)
 create mode 100644 translations/content/de/errors/helpful-npe.yaml
 create mode 100644 translations/content/de/errors/multi-catch.yaml
 create mode 100644 translations/content/de/errors/null-in-switch.yaml
 create mode 100644 translations/content/de/errors/optional-chaining.yaml
 create mode 100644 translations/content/de/errors/optional-orelsethrow.yaml
 create mode 100644 translations/content/de/errors/record-based-errors.yaml
 create mode 100644 translations/content/de/errors/require-nonnull-else.yaml
 create mode 100644 translations/content/de/io/deserialization-filters.yaml
 create mode 100644 translations/content/de/io/file-memory-mapping.yaml
 create mode 100644 translations/content/de/io/files-mismatch.yaml
 create mode 100644 translations/content/de/io/http-client.yaml
 create mode 100644 translations/content/de/io/inputstream-transferto.yaml
 create mode 100644 translations/content/de/io/io-class-console-io.yaml
 create mode 100644 translations/content/de/io/path-of.yaml
 create mode 100644 translations/content/de/io/reading-files.yaml
 create mode 100644 translations/content/de/io/try-with-resources-effectively-final.yaml
 create mode 100644 translations/content/de/io/writing-files.yaml
 create mode 100644 translations/content/de/language/compact-canonical-constructor.yaml
 create mode 100644 translations/content/de/language/compact-source-files.yaml
 create mode 100644 translations/content/de/language/default-interface-methods.yaml
 create mode 100644 translations/content/de/language/diamond-operator.yaml
 create mode 100644 translations/content/de/language/exhaustive-switch.yaml
 create mode 100644 translations/content/de/language/flexible-constructor-bodies.yaml
 create mode 100644 translations/content/de/language/guarded-patterns.yaml
 create mode 100644 translations/content/de/language/markdown-javadoc-comments.yaml
 create mode 100644 translations/content/de/language/module-import-declarations.yaml
 create mode 100644 translations/content/de/language/pattern-matching-instanceof.yaml
 create mode 100644 translations/content/de/language/pattern-matching-switch.yaml
 create mode 100644 translations/content/de/language/primitive-types-in-patterns.yaml
 create mode 100644 translations/content/de/language/private-interface-methods.yaml
 create mode 100644 translations/content/de/language/record-patterns.yaml
 create mode 100644 translations/content/de/language/records-for-data-classes.yaml
 create mode 100644 translations/content/de/language/sealed-classes.yaml
 create mode 100644 translations/content/de/language/static-members-in-inner-classes.yaml
 create mode 100644 translations/content/de/language/static-methods-in-interfaces.yaml
 create mode 100644 translations/content/de/language/switch-expressions.yaml
 create mode 100644 translations/content/de/language/text-blocks-for-multiline-strings.yaml
 create mode 100644 translations/content/de/language/type-inference-with-var.yaml
 create mode 100644 translations/content/de/language/unnamed-variables.yaml

diff --git a/translations/content/de/errors/helpful-npe.yaml b/translations/content/de/errors/helpful-npe.yaml
new file mode 100644
index 0000000..8de32fd
--- /dev/null
+++ b/translations/content/de/errors/helpful-npe.yaml
@@ -0,0 +1,17 @@
+title: "Hilfreiche NullPointerExceptions"
+oldApproach: "Kryptische NPE"
+modernApproach: "Detaillierte NPE"
+summary: "Die JVM teilt automatisch mit, welche Variable null war."
+explanation: "Hilfreiche NPEs beschreiben, welcher Ausdruck null war und welche Operation fehlgeschlagen ist. Dies ist seit Java 14 standardmäßig aktiviert – keine Codeänderung erforderlich, nur das JDK aktualisieren."
+whyModernWins:
+- icon: "🔍"
+  title: "Exakte Variable"
+  desc: "Die Meldung nennt die null-Variable in der Aufrufkette."
+- icon: "⚡"
+  title: "Schnelleres Debuggen"
+  desc: "Kein Rätselraten mehr, welcher der fünf verketteten Aufrufe null war."
+- icon: "🆓"
+  title: "Kostenloses Upgrade"
+  desc: "Keine Codeänderungen – einfach auf JDK 14+ ausführen."
+support:
+  description: "Seit JDK 14 allgemein verfügbar (März 2020)"
diff --git a/translations/content/de/errors/multi-catch.yaml b/translations/content/de/errors/multi-catch.yaml
new file mode 100644
index 0000000..258808d
--- /dev/null
+++ b/translations/content/de/errors/multi-catch.yaml
@@ -0,0 +1,17 @@
+title: "Multi-Catch-Ausnahmebehandlung"
+oldApproach: "Separate Catch-Blöcke"
+modernApproach: "Multi-Catch"
+summary: "Mehrere Ausnahmetypen in einem einzigen catch-Block abfangen."
+explanation: "Multi-Catch behandelt mehrere Ausnahmetypen mit demselben Code. Die Ausnahmevariable ist effektiv final, sodass sie ohne Einwickeln weitergeworfen werden kann."
+whyModernWins:
+- icon: "📏"
+  title: "DRY"
+  desc: "Dieselbe Behandlungslogik wird einmal statt dreimal geschrieben."
+- icon: "🔄"
+  title: "Wiederauswerfbar"
+  desc: "Die abgefangene Ausnahme kann mit ihrem genauen Typ weitergeworfen werden."
+- icon: "📖"
+  title: "Übersichtlich"
+  desc: "Alle behandelten Typen sind an einer Stelle sichtbar."
+support:
+  description: "Seit JDK 7 allgemein verfügbar (Juli 2011)"
diff --git a/translations/content/de/errors/null-in-switch.yaml b/translations/content/de/errors/null-in-switch.yaml
new file mode 100644
index 0000000..2178f0b
--- /dev/null
+++ b/translations/content/de/errors/null-in-switch.yaml
@@ -0,0 +1,17 @@
+title: "null-Fall im switch"
+oldApproach: "Prüfung vor dem Switch"
+modernApproach: "case null"
+summary: "null direkt als switch-Fall behandeln – keine separate Absicherung nötig."
+explanation: "Pattern-Matching-Switch kann null als case-Label abgleichen. Dadurch entfällt die Null-Prüfung vor dem switch, und die Null-Behandlung wird explizit und sichtbar."
+whyModernWins:
+- icon: "🎯"
+  title: "Explizit"
+  desc: "Die null-Behandlung ist direkt im switch sichtbar."
+- icon: "🛡️"
+  title: "Kein NPE"
+  desc: "Ein Switch auf einen null-Wert wirft keine NullPointerException."
+- icon: "📐"
+  title: "Alles in einem"
+  desc: "Alle Fälle einschließlich null in einem einzigen Switch-Ausdruck."
+support:
+  description: "Seit JDK 21 LTS allgemein verfügbar (Sept. 2023)"
diff --git a/translations/content/de/errors/optional-chaining.yaml b/translations/content/de/errors/optional-chaining.yaml
new file mode 100644
index 0000000..38658b1
--- /dev/null
+++ b/translations/content/de/errors/optional-chaining.yaml
@@ -0,0 +1,17 @@
+title: "Optional-Verkettung"
+oldApproach: "Verschachtelte Null-Prüfungen"
+modernApproach: "Optional-Pipeline"
+summary: "Verschachtelte Null-Prüfungen durch eine Optional-Pipeline ersetzen."
+explanation: "Optional.map() verkettet nullable-Werte und bricht bei dem ersten null kurz. orElse() liefert den Standardwert. Dies beseitigt die Pyramide der verschachtelten Null-Prüfungen."
+whyModernWins:
+- icon: "🔗"
+  title: "Verkettbar"
+  desc: "Jeder .map()-Schritt behandelt null transparent."
+- icon: "📖"
+  title: "Linearer Fluss"
+  desc: "Von links nach rechts lesen statt verschachtelter if-Blöcke."
+- icon: "🛡️"
+  title: "NPE-sicher"
+  desc: "null wird bei jedem Schritt behandelt – kein Absturz möglich."
+support:
+  description: "Verfügbar seit JDK 8+ (verbessert in 9+)"
diff --git a/translations/content/de/errors/optional-orelsethrow.yaml b/translations/content/de/errors/optional-orelsethrow.yaml
new file mode 100644
index 0000000..f46c592
--- /dev/null
+++ b/translations/content/de/errors/optional-orelsethrow.yaml
@@ -0,0 +1,17 @@
+title: "Optional.orElseThrow() ohne Supplier"
+oldApproach: "get() oder orElseThrow(supplier)"
+modernApproach: "orElseThrow()"
+summary: "Optional.orElseThrow() als klarere, absichtsverrätende Alternative zu get() verwenden."
+explanation: "Optional.get() gilt weithin als Code-Smell, weil es die Möglichkeit des Scheiterns verbirgt. Das argumentlose orElseThrow(), das in Java 10 hinzugefügt wurde, tut genau dasselbe, macht die Absicht aber explizit: Der Entwickler erwartet einen Wert und möchte eine Ausnahme, wenn keiner vorhanden ist."
+whyModernWins:
+- icon: "📖"
+  title: "Selbst-dokumentierend"
+  desc: "orElseThrow() signalisiert klar, dass ein leeres Ergebnis nicht erwartet wird."
+- icon: "🔒"
+  title: "Kein get()"
+  desc: "Statische Analysetools markieren get() als riskant; orElseThrow() ist idiomatisch."
+- icon: "⚡"
+  title: "Weniger Boilerplate"
+  desc: "Kein Supplier für die standardmäßige NoSuchElementException erforderlich."
+support:
+  description: "Verfügbar seit JDK 10 (März 2018)."
diff --git a/translations/content/de/errors/record-based-errors.yaml b/translations/content/de/errors/record-based-errors.yaml
new file mode 100644
index 0000000..87dfe82
--- /dev/null
+++ b/translations/content/de/errors/record-based-errors.yaml
@@ -0,0 +1,17 @@
+title: "Record-basierte Fehlerantworten"
+oldApproach: "Map oder ausführliche Klasse"
+modernApproach: "Fehler-Records"
+summary: "Records für prägnante, unveränderliche Fehlerantworttypen verwenden."
+explanation: "Records eignen sich hervorragend für Fehlerantworten – sie sind unveränderlich, besitzen eingebaute equals/hashCode für Vergleiche und toString für das Logging. Benutzerdefinierte Konstruktoren ermöglichen Validierung oder Standardwerte."
+whyModernWins:
+- icon: "📏"
+  title: "Prägnant"
+  desc: "Fehlertypen in 3 Zeilen statt 30 definieren."
+- icon: "🔒"
+  title: "Unveränderlich"
+  desc: "Fehlerdaten können nach der Erstellung nicht versehentlich geändert werden."
+- icon: "📋"
+  title: "Automatisches toString"
+  desc: "Perfekt für das Logging – alle Felder werden automatisch angezeigt."
+support:
+  description: "Seit JDK 16 allgemein verfügbar (März 2021)"
diff --git a/translations/content/de/errors/require-nonnull-else.yaml b/translations/content/de/errors/require-nonnull-else.yaml
new file mode 100644
index 0000000..8522bdb
--- /dev/null
+++ b/translations/content/de/errors/require-nonnull-else.yaml
@@ -0,0 +1,17 @@
+title: "Objects.requireNonNullElse()"
+oldApproach: "Ternäre Null-Prüfung"
+modernApproach: "requireNonNullElse()"
+summary: "Einen Non-null-Wert mit einem klaren Standardwert ermitteln – kein ternärer Operator nötig."
+explanation: "requireNonNullElse gibt das erste Argument zurück, wenn es nicht null ist, andernfalls das zweite. Der Standardwert selbst darf nicht null sein – bei zwei null-Werten wird eine NPE geworfen, was Fehler frühzeitig aufdeckt."
+whyModernWins:
+- icon: "📖"
+  title: "Klare Absicht"
+  desc: "Der Methodenname beschreibt genau, was er tut."
+- icon: "🛡️"
+  title: "Null-sicherer Standardwert"
+  desc: "Auch der Standardwert wird auf null geprüft."
+- icon: "📏"
+  title: "Lesbar"
+  desc: "Besser als ein ternärer Operator für einfache Null-oder-Standard-Logik."
+support:
+  description: "Seit JDK 9 allgemein verfügbar (Sept. 2017)"
diff --git a/translations/content/de/io/deserialization-filters.yaml b/translations/content/de/io/deserialization-filters.yaml
new file mode 100644
index 0000000..9cd80d5
--- /dev/null
+++ b/translations/content/de/io/deserialization-filters.yaml
@@ -0,0 +1,17 @@
+title: "Deserialisierungsfilter"
+oldApproach: "Alles akzeptieren"
+modernApproach: "ObjectInputFilter"
+summary: "Einschränken, welche Klassen deserialisiert werden dürfen, um Angriffe zu verhindern."
+explanation: "ObjectInputFilter ermöglicht es, Klassen auf einer Zulassungs- oder Sperrliste einzutragen sowie die Tiefe des Objektgraphen, Array-Größen und Referenzzähler zu begrenzen. Dadurch werden Deserialisierungsschwachstellen ohne externe Bibliotheken abgewehrt."
+whyModernWins:
+- icon: "🛡️"
+  title: "Sicherheit"
+  desc: "Deserialisierung unerwarteter oder bösartiger Klassen verhindern."
+- icon: "📐"
+  title: "Feingranular"
+  desc: "Tiefe, Array-Größe, Referenzen und Klassenmustern kontrollieren."
+- icon: "🏗️"
+  title: "JVM-weit"
+  desc: "Einen globalen Filter für alle Deserialisierungen in der JVM setzen."
+support:
+  description: "Seit JDK 9 allgemein verfügbar (Sept. 2017)"
diff --git a/translations/content/de/io/file-memory-mapping.yaml b/translations/content/de/io/file-memory-mapping.yaml
new file mode 100644
index 0000000..027391a
--- /dev/null
+++ b/translations/content/de/io/file-memory-mapping.yaml
@@ -0,0 +1,17 @@
+title: "Datei-Memory-Mapping"
+oldApproach: "MappedByteBuffer"
+modernApproach: "MemorySegment mit Arena"
+summary: "Dateien größer als 2 GB mit deterministischer Bereinigung über MemorySegment abbilden."
+explanation: "Die Foreign Function & Memory API (JEP 454) führt MemorySegment für sicheren und effizienten Speicherzugriff ein. Im Gegensatz zu MappedByteBuffer unterstützt MemorySegment Dateien größer als 2 GB (Integer.MAX_VALUE), bietet deterministische Bereinigung über Arena und bessere Performance mit moderner Hardware."
+whyModernWins:
+- icon: "📏"
+  title: "Keine Größenbeschränkung"
+  desc: "Dateien größer als 2 GB ohne Umwege abbilden."
+- icon: "🔒"
+  title: "Deterministische Bereinigung"
+  desc: "Arena stellt sicher, dass der Speicher beim Verlassen des Gültigkeitsbereichs freigegeben wird, nicht erst beim GC."
+- icon: "⚡"
+  title: "Bessere Performance"
+  desc: "Abgestimmt auf moderne Speichermodelle und Hardware."
+support:
+  description: "Verfügbar seit JDK 22 (März 2024)"
diff --git a/translations/content/de/io/files-mismatch.yaml b/translations/content/de/io/files-mismatch.yaml
new file mode 100644
index 0000000..09983f4
--- /dev/null
+++ b/translations/content/de/io/files-mismatch.yaml
@@ -0,0 +1,17 @@
+title: "Files.mismatch()"
+oldApproach: "Manueller Byte-Vergleich"
+modernApproach: "Files.mismatch()"
+summary: "Zwei Dateien effizient vergleichen, ohne sie in den Speicher zu laden."
+explanation: "Files.mismatch() gibt die Position des ersten abweichenden Bytes zurück oder -1, wenn die Dateien identisch sind. Es liest lazy und bricht beim ersten Unterschied ab."
+whyModernWins:
+- icon: "⚡"
+  title: "Speichereffizient"
+  desc: "Lädt keine vollständigen Dateien in Byte-Arrays."
+- icon: "🎯"
+  title: "Zeigt den Unterschied genau"
+  desc: "Gibt die genaue Byte-Position des ersten Unterschieds zurück."
+- icon: "📏"
+  title: "Ein Aufruf"
+  desc: "Keine manuelle Byte-Array-Vergleichslogik."
+support:
+  description: "Seit JDK 12 allgemein verfügbar (März 2019)"
diff --git a/translations/content/de/io/http-client.yaml b/translations/content/de/io/http-client.yaml
new file mode 100644
index 0000000..16976ea
--- /dev/null
+++ b/translations/content/de/io/http-client.yaml
@@ -0,0 +1,17 @@
+title: "Moderner HTTP-Client"
+oldApproach: "HttpURLConnection"
+modernApproach: "HttpClient"
+summary: "Den eingebauten HttpClient für saubere, moderne HTTP-Anfragen verwenden."
+explanation: "HttpClient unterstützt HTTP/1.1 und HTTP/2, asynchrone Anfragen, WebSocket, benutzerdefinierte Executors und Connection-Pooling. Kein Casten von URLConnection oder manuelles Lesen von InputStreams mehr."
+whyModernWins:
+- icon: "📐"
+  title: "Builder-API"
+  desc: "Fluenter Builder für Anfragen, Header und Timeouts."
+- icon: "🔄"
+  title: "HTTP/2-Unterstützung"
+  desc: "Eingebautes HTTP/2 mit Multiplexing und Server Push."
+- icon: "⚡"
+  title: "Async-fähig"
+  desc: "sendAsync() gibt ein CompletableFuture zurück."
+support:
+  description: "Seit JDK 11 allgemein verfügbar (Sept. 2018)"
diff --git a/translations/content/de/io/inputstream-transferto.yaml b/translations/content/de/io/inputstream-transferto.yaml
new file mode 100644
index 0000000..56db75d
--- /dev/null
+++ b/translations/content/de/io/inputstream-transferto.yaml
@@ -0,0 +1,17 @@
+title: "InputStream.transferTo()"
+oldApproach: "Manuelle Kopierschleife"
+modernApproach: "transferTo()"
+summary: "Einen InputStream mit einem einzigen Aufruf in einen OutputStream kopieren."
+explanation: "transferTo() liest alle Bytes aus dem Eingabestream und schreibt sie in den Ausgabestream. Kein Puffer-Management, keine Schleife. Es wird ein optimierter interner Puffer verwendet."
+whyModernWins:
+- icon: "📏"
+  title: "Eine Zeile"
+  desc: "Die gesamte Lese-/Schreibschleife durch einen einzigen Methodenaufruf ersetzen."
+- icon: "⚡"
+  title: "Optimiert"
+  desc: "Die interne Puffergröße ist auf Performance ausgelegt."
+- icon: "🛡️"
+  title: "Keine Fehler"
+  desc: "Keine Off-by-one-Fehler beim Puffer-Management."
+support:
+  description: "Seit JDK 9 allgemein verfügbar (Sept. 2017)"
diff --git a/translations/content/de/io/io-class-console-io.yaml b/translations/content/de/io/io-class-console-io.yaml
new file mode 100644
index 0000000..c760e9a
--- /dev/null
+++ b/translations/content/de/io/io-class-console-io.yaml
@@ -0,0 +1,17 @@
+title: "IO-Klasse für Konsolen-E/A"
+oldApproach: "System.out / Scanner"
+modernApproach: "IO-Klasse"
+summary: "Die neue IO-Klasse bietet einfache, prägnante Methoden für Konsoleneingabe und -ausgabe."
+explanation: "Java 25 führt die IO-Klasse (java.io.IO) als Teil der implizit deklarierten Klassen ein. Sie stellt statische Methoden wie println(), print(), readln() und read() bereit, die die umständliche Kombination aus System.out und Scanner ersetzen. IO.readln(prompt) übernimmt Eingabeaufforderung und Lesen in einem einzigen Aufruf. Die Klasse ist in kompakten Quelldateien automatisch verfügbar und kann in herkömmlichen Klassen per Import genutzt werden."
+whyModernWins:
+- icon: "✨"
+  title: "Erheblich einfacher"
+  desc: "Zwei Methoden ersetzen sieben Zeilen für Scanner-Einrichtung, Eingabeaufforderung, Lesen und Bereinigung."
+- icon: "🔒"
+  title: "Keine Ressourcenlecks"
+  desc: "Kein Scanner zum Schließen – IO-Methoden verwalten Ressourcen intern."
+- icon: "🎓"
+  title: "Einsteigerfreundlich"
+  desc: "Neue Entwickler können Konsolen-E/A nutzen, ohne Scanner, System.out oder import-Anweisungen zu kennen."
+support:
+  description: "Vorschau in JDK 25 als Teil implizit deklarierter Klassen (JEP 495)"
diff --git a/translations/content/de/io/path-of.yaml b/translations/content/de/io/path-of.yaml
new file mode 100644
index 0000000..dbdb2da
--- /dev/null
+++ b/translations/content/de/io/path-of.yaml
@@ -0,0 +1,17 @@
+title: "Path.of()-Factory"
+oldApproach: "Paths.get()"
+modernApproach: "Path.of()"
+summary: "Path.of() verwenden – die moderne Factory-Methode des Path-Interfaces."
+explanation: "Path.of() ist eine Factory-Methode, die direkt zum Path-Interface hinzugefügt wurde und die separate Paths-Hilfsklasse ersetzt. Sie ist besser auffindbar und konsistent mit List.of(), Map.of() usw."
+whyModernWins:
+- icon: "📐"
+  title: "Konsistente API"
+  desc: "Folgt dem .of()-Factory-Muster wie List.of(), Set.of()."
+- icon: "📖"
+  title: "Auffindbar"
+  desc: "Direkt am Path-Typ zu finden, nicht in einer separaten Paths-Klasse."
+- icon: "🧹"
+  title: "Eine Klasse weniger"
+  desc: "Kein Import der Paths-Hilfsklasse erforderlich."
+support:
+  description: "Seit JDK 11 allgemein verfügbar (Sept. 2018)"
diff --git a/translations/content/de/io/reading-files.yaml b/translations/content/de/io/reading-files.yaml
new file mode 100644
index 0000000..6a0f0c2
--- /dev/null
+++ b/translations/content/de/io/reading-files.yaml
@@ -0,0 +1,17 @@
+title: "Dateien lesen"
+oldApproach: "BufferedReader"
+modernApproach: "Files.readString()"
+summary: "Eine gesamte Datei mit einer Zeile in einen String einlesen."
+explanation: "Files.readString() liest den gesamten Inhalt einer Datei in einen String. Es übernimmt die Zeichenkodierung (standardmäßig UTF-8) und die Ressourcenbereinigung. Für große Dateien empfiehlt sich Files.lines() für lazy Streaming."
+whyModernWins:
+- icon: "📏"
+  title: "Eine Zeile"
+  desc: "8 Zeilen BufferedReader-Boilerplate ersetzen."
+- icon: "🧹"
+  title: "Automatische Bereinigung"
+  desc: "Das Datei-Handle wird automatisch geschlossen."
+- icon: "🌐"
+  title: "UTF-8 als Standard"
+  desc: "Standardmäßig korrekte Kodierung – keine Zeichensatz-Verwirrung."
+support:
+  description: "Seit JDK 11 allgemein verfügbar (Sept. 2018)"
diff --git a/translations/content/de/io/try-with-resources-effectively-final.yaml b/translations/content/de/io/try-with-resources-effectively-final.yaml
new file mode 100644
index 0000000..04bd14e
--- /dev/null
+++ b/translations/content/de/io/try-with-resources-effectively-final.yaml
@@ -0,0 +1,17 @@
+title: "Verbessertes Try-with-Resources"
+oldApproach: "Variable neu deklarieren"
+modernApproach: "Effektiv finale Variable"
+summary: "Bestehende, effektiv finale Variablen direkt in try-with-resources verwenden."
+explanation: "Java 9 erlaubt die direkte Verwendung effektiv finaler Variablen in try-with-resources ohne Neudeklaration. Dies ist sauberer, wenn die Ressource außerhalb des try-Blocks erstellt wurde."
+whyModernWins:
+- icon: "🧹"
+  title: "Keine Neudeklaration"
+  desc: "Den bestehenden Variablennamen direkt verwenden."
+- icon: "📖"
+  title: "Weniger Verwirrung"
+  desc: "Kein separater Variablenname innerhalb des try-Blocks."
+- icon: "📏"
+  title: "Prägnant"
+  desc: "Weniger Zeilen bei gleicher Ressourcensicherheit."
+support:
+  description: "Seit JDK 9 allgemein verfügbar (Sept. 2017)"
diff --git a/translations/content/de/io/writing-files.yaml b/translations/content/de/io/writing-files.yaml
new file mode 100644
index 0000000..e30d738
--- /dev/null
+++ b/translations/content/de/io/writing-files.yaml
@@ -0,0 +1,17 @@
+title: "Dateien schreiben"
+oldApproach: "FileWriter + BufferedWriter"
+modernApproach: "Files.writeString()"
+summary: "Einen String mit einer Zeile in eine Datei schreiben."
+explanation: "Files.writeString() schreibt Inhalt standardmäßig mit UTF-8-Kodierung in eine Datei. Für Anhängen, Erstellen u.ä. können Optionen übergeben werden."
+whyModernWins:
+- icon: "📏"
+  title: "Eine Zeile"
+  desc: "Kein Writer-Wrapping oder try-with-resources erforderlich."
+- icon: "🛡️"
+  title: "Sichere Standardwerte"
+  desc: "UTF-8-Kodierung, korrekte Bereinigung des Datei-Handles."
+- icon: "🔧"
+  title: "Optionen"
+  desc: "OpenOption-Flags für Anhängen, Erstellen usw. übergeben."
+support:
+  description: "Seit JDK 11 allgemein verfügbar (Sept. 2018)"
diff --git a/translations/content/de/language/compact-canonical-constructor.yaml b/translations/content/de/language/compact-canonical-constructor.yaml
new file mode 100644
index 0000000..98a9876
--- /dev/null
+++ b/translations/content/de/language/compact-canonical-constructor.yaml
@@ -0,0 +1,17 @@
+title: "Kompakter kanonischer Konstruktor"
+oldApproach: "Explizite Konstruktorvalidierung"
+modernApproach: "Kompakter Konstruktor"
+summary: "Record-Felder validieren und normalisieren, ohne die Parameterliste zu wiederholen."
+explanation: "Records können einen kompakten kanonischen Konstruktor deklarieren, der die Parameterliste und Feldzuweisungen weglässt. Der Compiler weist Parameter nach der Ausführung Ihrer Validierungslogik automatisch Feldern zu. Dies ist ideal für Vorbedingungsprüfungen, defensive Kopien und Normalisierung."
+whyModernWins:
+- icon: "✂️"
+  title: "Weniger Wiederholung"
+  desc: "Parameterliste muss nicht wiederholt und jedes Feld nicht manuell zugewiesen werden."
+- icon: "🛡️"
+  title: "Validierung"
+  desc: "Perfekt für Null-Prüfungen, Bereichsvalidierung und defensive Kopien."
+- icon: "📖"
+  title: "Klarere Absicht"
+  desc: "Die kompakte Syntax betont die Validierung, nicht den Boilerplate-Code."
+support:
+  description: "Seit JDK 16 allgemein verfügbar (März 2021)"
diff --git a/translations/content/de/language/compact-source-files.yaml b/translations/content/de/language/compact-source-files.yaml
new file mode 100644
index 0000000..687ca03
--- /dev/null
+++ b/translations/content/de/language/compact-source-files.yaml
@@ -0,0 +1,17 @@
+title: "Kompakte Quelldateien"
+oldApproach: "Klassen-Zeremonie für main"
+modernApproach: "void main()"
+summary: "Ein vollständiges Programm ohne Klassendeklaration oder public static void main schreiben."
+explanation: "Kompakte Quelldateien beseitigen die Zeremonie von Klassendeklarationen und der Main-Methoden-Signatur für einfache Programme. In Kombination mit dem impliziten Import von java.io.IO steht sogar println direkt zur Verfügung."
+whyModernWins:
+- icon: "🚀"
+  title: "Null Zeremonie"
+  desc: "Keine Klasse, kein public static void main, kein String[] args."
+- icon: "🎓"
+  title: "Einsteigerfreundlich"
+  desc: "Neue Programmierer können ab der ersten Zeile nützlichen Code schreiben."
+- icon: "📝"
+  title: "Skriptähnlich"
+  desc: "Perfekt für schnelle Prototypen, Skripte und Beispiele."
+support:
+  description: "Finalisiert in JDK 25 LTS (JEP 512, Sept. 2025)."
diff --git a/translations/content/de/language/default-interface-methods.yaml b/translations/content/de/language/default-interface-methods.yaml
new file mode 100644
index 0000000..d6d082f
--- /dev/null
+++ b/translations/content/de/language/default-interface-methods.yaml
@@ -0,0 +1,17 @@
+title: "Default-Methoden in Interfaces"
+oldApproach: "Abstrakte Klassen für gemeinsames Verhalten"
+modernApproach: "Default-Methoden in Interfaces"
+summary: "Methodenimplementierungen direkt in Interfaces einfügen und so Mehrfachvererbung von Verhalten ermöglichen."
+explanation: "Vor Java 8 erforderte das Teilen von Verhalten zwischen unverwandten Klassen abstrakte Klassen, was auf Einfachvererbung beschränkte. Default-Methoden erlauben Interfaces, Methodenimplementierungen bereitzustellen, sodass Klassen Verhalten von mehreren Interfaces erben können. Dies war entscheidend für die Weiterentwicklung der Collections-API (z. B. List.forEach, Map.getOrDefault) ohne bestehende Implementierungen zu brechen."
+whyModernWins:
+- icon: "🔀"
+  title: "Mehrfachvererbung"
+  desc: "Klassen können viele Interfaces mit Default-Methoden implementieren – anders als bei einfacher abstrakter Klassenvererbung."
+- icon: "📦"
+  title: "API-Evolution"
+  desc: "Neue Methoden zu Interfaces hinzufügen, ohne bestehende Implementierungen zu brechen."
+- icon: "🧩"
+  title: "Kombinierbares Verhalten"
+  desc: "Fähigkeiten aus mehreren Interfaces frei kombinieren."
+support:
+  description: "Verfügbar seit JDK 8 (März 2014)."
diff --git a/translations/content/de/language/diamond-operator.yaml b/translations/content/de/language/diamond-operator.yaml
new file mode 100644
index 0000000..744fae5
--- /dev/null
+++ b/translations/content/de/language/diamond-operator.yaml
@@ -0,0 +1,17 @@
+title: "Diamant-Operator mit anonymen Klassen"
+oldApproach: "Typargumente wiederholen"
+modernApproach: "Diamant <>"
+summary: "Der Diamant-Operator funktioniert jetzt auch mit anonymen Klassen."
+explanation: "Java 7 führte <> ein, aber es funktionierte nicht mit anonymen inneren Klassen. Java 9 hat dies behoben, sodass Typargumente auf der rechten Seite nie wiederholt werden müssen."
+whyModernWins:
+- icon: "📏"
+  title: "Konsistente Regeln"
+  desc: "Der Diamant funktioniert überall – bei Konstruktoren und anonymen Klassen gleichermaßen."
+- icon: "🧹"
+  title: "Weniger Redundanz"
+  desc: "Typargumente werden einmal links angegeben und nie wiederholt."
+- icon: "🔧"
+  title: "DRY-Prinzip"
+  desc: "Der Compiler kennt den Typ bereits – warum ihn zweimal schreiben?"
+support:
+  description: "Diamant mit anonymen Klassen seit JDK 9 (Sept. 2017)."
diff --git a/translations/content/de/language/exhaustive-switch.yaml b/translations/content/de/language/exhaustive-switch.yaml
new file mode 100644
index 0000000..dd3b474
--- /dev/null
+++ b/translations/content/de/language/exhaustive-switch.yaml
@@ -0,0 +1,17 @@
+title: "Erschöpfender Switch ohne default"
+oldApproach: "Obligatorischer default-Zweig"
+modernApproach: "Sealed Exhaustiveness"
+summary: "Der Compiler prüft, dass alle versiegelten Untertypen abgedeckt sind – kein default erforderlich."
+explanation: "Beim Switch über einen sealed-Typ kennt der Compiler alle möglichen Untertypen und verifiziert, dass jeder Fall behandelt wird. Wird ein neuer Untertyp hinzugefügt, markiert der Compiler jeden Switch, der nun unvollständig ist."
+whyModernWins:
+- icon: "✅"
+  title: "Compile-Zeit-Sicherheit"
+  desc: "Einen neuen Untertyp hinzufügen und der Compiler zeigt jeden Ort, der aktualisiert werden muss."
+- icon: "🚫"
+  title: "Kein toter Code"
+  desc: "Kein unerreichbarer default-Zweig, der Fehler verbirgt."
+- icon: "📐"
+  title: "Algebraische Typen"
+  desc: "Sealed + Records + erschöpfendem Switch = echte ADTs in Java."
+support:
+  description: "Seit JDK 21 LTS allgemein verfügbar (Sept. 2023)"
diff --git a/translations/content/de/language/flexible-constructor-bodies.yaml b/translations/content/de/language/flexible-constructor-bodies.yaml
new file mode 100644
index 0000000..5c5e437
--- /dev/null
+++ b/translations/content/de/language/flexible-constructor-bodies.yaml
@@ -0,0 +1,17 @@
+title: "Flexible Konstruktorrümpfe"
+oldApproach: "Validierung nach super()"
+modernApproach: "Code vor super()"
+summary: "Werte validieren und berechnen, bevor super() oder this() aufgerufen wird."
+explanation: "Java 25 hebt die Einschränkung auf, dass super() die erste Anweisung sein muss. Es können nun Argumente validiert, abgeleitete Werte berechnet und Zustände eingerichtet werden, bevor an den Elternkonstruktor delegiert wird."
+whyModernWins:
+- icon: "🛡️"
+  title: "Früh scheitern"
+  desc: "Argumente validieren, bevor der Superklassen-Konstruktor ausgeführt wird."
+- icon: "🧮"
+  title: "Erst berechnen"
+  desc: "Werte ableiten und Daten vorbereiten, bevor super() aufgerufen wird."
+- icon: "🧹"
+  title: "Keine Workarounds"
+  desc: "Keine statischen Hilfsmethoden oder Factory-Muster mehr, um die Einschränkung zu umgehen."
+support:
+  description: "Finalisiert in JDK 25 LTS (JEP 513, Sept. 2025)."
diff --git a/translations/content/de/language/guarded-patterns.yaml b/translations/content/de/language/guarded-patterns.yaml
new file mode 100644
index 0000000..b67a053
--- /dev/null
+++ b/translations/content/de/language/guarded-patterns.yaml
@@ -0,0 +1,17 @@
+title: "Bewachte Muster mit when"
+oldApproach: "Verschachteltes if"
+modernApproach: "when-Klausel"
+summary: "Bedingungen zu Pattern-Fällen mit when-Wächtern hinzufügen."
+explanation: "Bewachte Muster ermöglichen es, einen Typ-Match mit einer zusätzlichen booleschen Bedingung zu verfeinern. Dadurch bleibt die gesamte Verzweigungslogik im Switch, anstatt if-Anweisungen in Fällen zu verschachteln."
+whyModernWins:
+- icon: "🎯"
+  title: "Präzises Matching"
+  desc: "Typ + Bedingung in einem einzigen case-Label kombinieren."
+- icon: "📐"
+  title: "Flache Struktur"
+  desc: "Keine verschachtelten if/else in Switch-Fällen."
+- icon: "📖"
+  title: "Lesbare Absicht"
+  desc: "Die when-Klausel liest sich wie natürliche Sprache."
+support:
+  description: "Seit JDK 21 LTS allgemein verfügbar (Sept. 2023)"
diff --git a/translations/content/de/language/markdown-javadoc-comments.yaml b/translations/content/de/language/markdown-javadoc-comments.yaml
new file mode 100644
index 0000000..bc0b5eb
--- /dev/null
+++ b/translations/content/de/language/markdown-javadoc-comments.yaml
@@ -0,0 +1,17 @@
+title: "Markdown in Javadoc-Kommentaren"
+oldApproach: "HTML-basiertes Javadoc"
+modernApproach: "Markdown-Javadoc"
+summary: "Javadoc-Kommentare in Markdown statt HTML schreiben, für bessere Lesbarkeit."
+explanation: "Java 23 führt ///Markdown-Javadoc-Kommentare als Alternative zum traditionellen /** */-HTML-Format ein. Markdown-Syntax ist natürlicher zu schreiben und zu lesen, mit Unterstützung für Codeblöcke, Betonungen, Listen und Links. Der Compiler wandelt Markdown in HTML für die Javadoc-Ausgabe um."
+whyModernWins:
+- icon: "📖"
+  title: "Natürliche Syntax"
+  desc: "Backticks für Inline-Code und ``` für Blöcke statt HTML-Tags verwenden."
+- icon: "✍️"
+  title: "Einfacher zu schreiben"
+  desc: "Kein {@code}, <pre>, <p>-Tags – einfach Markdown schreiben."
+- icon: "👁"
+  title: "Besser in Editoren"
+  desc: "Markdown wird in modernen IDEs und Texteditoren hervorragend dargestellt."
+support:
+  description: "Verfügbar seit JDK 23 (Sept. 2024)"
diff --git a/translations/content/de/language/module-import-declarations.yaml b/translations/content/de/language/module-import-declarations.yaml
new file mode 100644
index 0000000..0d3ae1b
--- /dev/null
+++ b/translations/content/de/language/module-import-declarations.yaml
@@ -0,0 +1,17 @@
+title: "Modul-Import-Deklarationen"
+oldApproach: "Viele Imports"
+modernApproach: "import module"
+summary: "Alle exportierten Pakete eines Moduls mit einer einzigen Deklaration importieren."
+explanation: "Modul-Import-Deklarationen ermöglichen es, alles, was ein Modul exportiert, mit einer Zeile zu importieren. Dies ist besonders nützlich für java.base, das Collections, I/O, Streams und mehr abdeckt."
+whyModernWins:
+- icon: "🧹"
+  title: "Eine Zeile"
+  desc: "Eine Wand von Imports durch einen einzigen Modul-Import ersetzen."
+- icon: "📦"
+  title: "Modulsystem-bewusst"
+  desc: "Nutzt das Modulsystem zum Import zusammenhängender Pakete."
+- icon: "🚀"
+  title: "Schnellstart"
+  desc: "Perfekt für Skripte und Prototypen, bei denen Import-Listen lästig sind."
+support:
+  description: "Finalisiert in JDK 25 LTS (JEP 511, Sept. 2025)."
diff --git a/translations/content/de/language/pattern-matching-instanceof.yaml b/translations/content/de/language/pattern-matching-instanceof.yaml
new file mode 100644
index 0000000..66a9b89
--- /dev/null
+++ b/translations/content/de/language/pattern-matching-instanceof.yaml
@@ -0,0 +1,17 @@
+title: "Pattern Matching für instanceof"
+oldApproach: "instanceof + Cast"
+modernApproach: "Pattern-Variable"
+summary: "Typprüfung und Cast in einem Schritt mit Pattern Matching kombinieren."
+explanation: "Pattern Matching für instanceof eliminiert den überflüssigen Cast nach einer Typprüfung. Die Variable ist automatisch auf den Gültigkeitsbereich beschränkt, in dem das Muster passt, was den Code sicherer und kürzer macht."
+whyModernWins:
+- icon: "🔄"
+  title: "Kein überflüssiger Cast"
+  desc: "Typprüfung und Variablenbindung erfolgen in einem einzigen Ausdruck."
+- icon: "📏"
+  title: "Weniger Zeilen"
+  desc: "Eine Zeile statt zwei – die Cast-Zeile entfällt vollständig."
+- icon: "🛡️"
+  title: "Gültigkeitsbereich-Sicherheit"
+  desc: "Die Pattern-Variable ist nur dort im Gültigkeitsbereich, wo der Typ garantiert ist."
+support:
+  description: "Seit JDK 16 allgemein verfügbar (März 2021)"
diff --git a/translations/content/de/language/pattern-matching-switch.yaml b/translations/content/de/language/pattern-matching-switch.yaml
new file mode 100644
index 0000000..263344e
--- /dev/null
+++ b/translations/content/de/language/pattern-matching-switch.yaml
@@ -0,0 +1,17 @@
+title: "Pattern Matching im switch"
+oldApproach: "if-else-Kette"
+modernApproach: "Typ-Muster"
+summary: "if-else-instanceof-Ketten durch saubere Switch-Typ-Muster ersetzen."
+explanation: "Pattern Matching im switch ermöglicht die direkte Typabgleichung, wobei Typtest, Cast und Bindung in einem prägnanten case-Label kombiniert werden. Der Compiler prüft die Vollständigkeit."
+whyModernWins:
+- icon: "📐"
+  title: "Strukturiertes Dispatch"
+  desc: "Switch macht die Verzweigungsstruktur explizit und übersichtlich."
+- icon: "🎯"
+  title: "Ausdrucksform"
+  desc: "Gibt einen Wert direkt zurück – keine veränderliche Variable nötig."
+- icon: "✅"
+  title: "Erschöpfungsprüfung"
+  desc: "Der Compiler stellt sicher, dass alle Typen behandelt werden."
+support:
+  description: "Seit JDK 21 LTS allgemein verfügbar (Sept. 2023)"
diff --git a/translations/content/de/language/primitive-types-in-patterns.yaml b/translations/content/de/language/primitive-types-in-patterns.yaml
new file mode 100644
index 0000000..c38797e
--- /dev/null
+++ b/translations/content/de/language/primitive-types-in-patterns.yaml
@@ -0,0 +1,17 @@
+title: "Primitive Typen in Mustern"
+oldApproach: "Manuelle Bereichsprüfungen"
+modernApproach: "Primitive Muster"
+summary: "Pattern Matching funktioniert jetzt auch mit primitiven Typen, nicht nur mit Objekten."
+explanation: "Java 25 erweitert Pattern Matching auf primitive Typen. int, long, double usw. können in Switch-Mustern mit when-Wächtern verwendet werden, wodurch Boxing oder manuelle Bereichsprüfungen entfallen."
+whyModernWins:
+- icon: "📦"
+  title: "Kein Boxing"
+  desc: "Primitive direkt abgleichen – kein Integer-Wrapper erforderlich."
+- icon: "🎯"
+  title: "Muster-Konsistenz"
+  desc: "Dieselbe Muster-Syntax für Objekte und Primitive."
+- icon: "⚡"
+  title: "Bessere Performance"
+  desc: "Autoboxing-Overhead beim Pattern Matching vermeiden."
+support:
+  description: "Vorschau in JDK 25 (dritte Vorschau, JEP 507). Erfordert --enable-preview."
diff --git a/translations/content/de/language/private-interface-methods.yaml b/translations/content/de/language/private-interface-methods.yaml
new file mode 100644
index 0000000..0ba072d
--- /dev/null
+++ b/translations/content/de/language/private-interface-methods.yaml
@@ -0,0 +1,17 @@
+title: "Private Interface-Methoden"
+oldApproach: "Duplizierte Logik"
+modernApproach: "Private Methoden"
+summary: "Gemeinsame Logik in Interfaces mithilfe privater Methoden auslagern."
+explanation: "Java 9 erlaubt private Methoden in Interfaces, sodass Code zwischen Default-Methoden geteilt werden kann, ohne Implementierungsdetails an implementierende Klassen preiszugeben."
+whyModernWins:
+- icon: "🧩"
+  title: "Code-Wiederverwendung"
+  desc: "Logik zwischen Default-Methoden ohne Duplizierung teilen."
+- icon: "🔐"
+  title: "Kapselung"
+  desc: "Implementierungsdetails bleiben vor implementierenden Klassen verborgen."
+- icon: "🧹"
+  title: "DRY-Interfaces"
+  desc: "Kein Copy-Paste mehr zwischen Default-Methoden."
+support:
+  description: "Seit JDK 9 allgemein verfügbar (Sept. 2017)"
diff --git a/translations/content/de/language/record-patterns.yaml b/translations/content/de/language/record-patterns.yaml
new file mode 100644
index 0000000..ff4ce5c
--- /dev/null
+++ b/translations/content/de/language/record-patterns.yaml
@@ -0,0 +1,17 @@
+title: "Record-Muster (Destrukturierung)"
+oldApproach: "Manueller Zugriff"
+modernApproach: "Destrukturierung"
+summary: "Records direkt in Mustern destrukturieren – Felder in einem Schritt extrahieren."
+explanation: "Record-Muster ermöglichen die Zerlegung der Komponenten eines Records direkt in instanceof und switch. Verschachtelte Muster werden ebenfalls unterstützt, was tiefes Matching ohne Zwischenvariablen ermöglicht."
+whyModernWins:
+- icon: "🎯"
+  title: "Direkter Zugriff"
+  desc: "Record-Komponenten zugreifen, ohne Accessoren manuell aufzurufen."
+- icon: "🪆"
+  title: "Verschachtelbar"
+  desc: "Muster können verschachtelt werden – innere Records in einem einzigen Ausdruck abgleichen."
+- icon: "📏"
+  title: "Kompakter Code"
+  desc: "Fünf Zeilen werden zu zwei – weniger Zeremonie, gleiche Klarheit."
+support:
+  description: "Seit JDK 21 LTS allgemein verfügbar (Sept. 2023)"
diff --git a/translations/content/de/language/records-for-data-classes.yaml b/translations/content/de/language/records-for-data-classes.yaml
new file mode 100644
index 0000000..54176cf
--- /dev/null
+++ b/translations/content/de/language/records-for-data-classes.yaml
@@ -0,0 +1,17 @@
+title: "Records für Datenklassen"
+oldApproach: "Ausführliches POJO"
+modernApproach: "record"
+summary: "Eine Zeile ersetzt mehr als 30 Zeilen Boilerplate für unveränderliche Datenträger."
+explanation: "Records generieren automatisch den Konstruktor, Accessoren (x(), y()), equals(), hashCode() und toString(). Sie sind von Natur aus unveränderlich und ideal für DTOs, Wertobjekte und Pattern Matching."
+whyModernWins:
+- icon: "⚡"
+  title: "Einzeilige Definition"
+  desc: "Eine einzige Zeile ersetzt Konstruktor, Getter, equals, hashCode, toString."
+- icon: "🔒"
+  title: "Standardmäßig unveränderlich"
+  desc: "Alle Felder sind final – keine Setter-Fallstricke."
+- icon: "🧩"
+  title: "Muster-freundlich"
+  desc: "Records funktionieren mit Destrukturierungsmustern in switch und instanceof."
+support:
+  description: "Seit JDK 16 allgemein verfügbar (März 2021)"
diff --git a/translations/content/de/language/sealed-classes.yaml b/translations/content/de/language/sealed-classes.yaml
new file mode 100644
index 0000000..b8a3da2
--- /dev/null
+++ b/translations/content/de/language/sealed-classes.yaml
@@ -0,0 +1,17 @@
+title: "Versiegelte Klassen für Typhierarchien"
+oldApproach: "Offene Hierarchie"
+modernApproach: "sealed permits"
+summary: "Einschränken, welche Klassen einen Typ erweitern dürfen – für erschöpfende Switches."
+explanation: "Versiegelte Klassen definieren eine geschlossene Menge von Untertypen. Der Compiler kennt alle möglichen Fälle und ermöglicht erschöpfendes Pattern Matching ohne default-Zweig. In Kombination mit Records modellieren sie algebraische Datentypen."
+whyModernWins:
+- icon: "🔐"
+  title: "Kontrollierte Hierarchie"
+  desc: "Nur erlaubte Untertypen dürfen erweitern – keine überraschenden Unterklassen."
+- icon: "✅"
+  title: "Erschöpfendes Matching"
+  desc: "Der Compiler prüft, dass der Switch alle Fälle abdeckt – kein default nötig."
+- icon: "📐"
+  title: "Algebraische Datentypen"
+  desc: "Summentypen natürlich modellieren – sealed + records = ADTs in Java."
+support:
+  description: "Seit JDK 17 LTS allgemein verfügbar (Sept. 2021)"
diff --git a/translations/content/de/language/static-members-in-inner-classes.yaml b/translations/content/de/language/static-members-in-inner-classes.yaml
new file mode 100644
index 0000000..3b3319c
--- /dev/null
+++ b/translations/content/de/language/static-members-in-inner-classes.yaml
@@ -0,0 +1,17 @@
+title: "Statische Mitglieder in inneren Klassen"
+oldApproach: "Statisch verschachtelte Klasse erforderlich"
+modernApproach: "Statische Mitglieder in inneren Klassen"
+summary: "Statische Mitglieder in inneren Klassen definieren, ohne statisch verschachtelte Klassen verwenden zu müssen."
+explanation: "Vor Java 16 konnten nur statisch verschachtelte Klassen statische Mitglieder enthalten. Innere (nicht-statische) Klassen durften keine Statics haben, weil sie eine umschließende Instanz erforderten. Java 16 lockert diese Einschränkung und erlaubt statische Felder, Methoden und sogar verschachtelte Typen in inneren Klassen."
+whyModernWins:
+- icon: "🔓"
+  title: "Mehr Flexibilität"
+  desc: "Innere Klassen können bei Bedarf nun statische Mitglieder haben."
+- icon: "🧩"
+  title: "Gemeinsamer Zustand"
+  desc: "Gemeinsamen Zustand über Instanzen einer inneren Klasse hinweg verfolgen."
+- icon: "📐"
+  title: "Designfreiheit"
+  desc: "Kein Hochstufen zu einer statisch verschachtelten Klasse nur wegen eines statischen Felds."
+support:
+  description: "Seit JDK 16 allgemein verfügbar (März 2021)"
diff --git a/translations/content/de/language/static-methods-in-interfaces.yaml b/translations/content/de/language/static-methods-in-interfaces.yaml
new file mode 100644
index 0000000..a3a95cb
--- /dev/null
+++ b/translations/content/de/language/static-methods-in-interfaces.yaml
@@ -0,0 +1,17 @@
+title: "Statische Methoden in Interfaces"
+oldApproach: "Hilfsklassen"
+modernApproach: "Statische Interface-Methoden"
+summary: "Statische Hilfsmethoden direkt in Interfaces hinzufügen, anstatt separate Hilfsklassen zu verwenden."
+explanation: "Vor Java 8 mussten Hilfsmethoden, die sich auf ein Interface bezogen, in einer separaten Klasse leben (z. B. Collections für Collection). Statische Methoden in Interfaces erlauben es, verwandte Hilfsfunktionen zusammenzuhalten. Gängig in modernen APIs wie Comparator.comparing(), Stream.of() und List.of()."
+whyModernWins:
+- icon: "📦"
+  title: "Bessere Organisation"
+  desc: "Verwandte Hilfsfunktionen beim Interface behalten, nicht in einer separaten Klasse."
+- icon: "🔍"
+  title: "Auffindbarkeit"
+  desc: "Factory- und Hilfsmethoden sind dort zu finden, wo man sie erwartet."
+- icon: "🧩"
+  title: "API-Kohäsion"
+  desc: "Keine separaten *Utils- oder *Helper-Klassen mehr erforderlich."
+support:
+  description: "Verfügbar seit JDK 8 (März 2014)"
diff --git a/translations/content/de/language/switch-expressions.yaml b/translations/content/de/language/switch-expressions.yaml
new file mode 100644
index 0000000..fecf8e7
--- /dev/null
+++ b/translations/content/de/language/switch-expressions.yaml
@@ -0,0 +1,17 @@
+title: "Switch-Ausdrücke"
+oldApproach: "Switch-Anweisung"
+modernApproach: "Switch-Ausdruck"
+summary: "Switch als Ausdruck, der einen Wert zurückgibt – kein break, kein Fall-Through."
+explanation: "Switch-Ausdrücke geben einen Wert direkt zurück, verwenden Pfeilsyntax zur Vermeidung von Fall-Through-Fehlern, und der Compiler prüft die Erschöpfung. Dies ersetzt die fehleranfällige Anweisungsform."
+whyModernWins:
+- icon: "🎯"
+  title: "Gibt einen Wert zurück"
+  desc: "Das Switch-Ergebnis direkt zuweisen – keine temporäre Variable nötig."
+- icon: "🛡️"
+  title: "Kein Fall-Through"
+  desc: "Pfeilsyntax eliminiert versehentliche Fall-Through-Fehler durch fehlendes break."
+- icon: "✅"
+  title: "Erschöpfungsprüfung"
+  desc: "Der Compiler stellt sicher, dass alle Fälle abgedeckt sind."
+support:
+  description: "Seit JDK 14 allgemein verfügbar (März 2020)"
diff --git a/translations/content/de/language/text-blocks-for-multiline-strings.yaml b/translations/content/de/language/text-blocks-for-multiline-strings.yaml
new file mode 100644
index 0000000..10fd866
--- /dev/null
+++ b/translations/content/de/language/text-blocks-for-multiline-strings.yaml
@@ -0,0 +1,17 @@
+title: "Textblöcke für mehrzeilige Strings"
+oldApproach: "String-Verkettung"
+modernApproach: "Textblöcke"
+summary: "Mehrzeilige Strings natürlich mit Triple-Quote-Textblöcken schreiben."
+explanation: "Textblöcke erlauben das Schreiben mehrzeiliger Strings genau so, wie sie erscheinen. Keine Escape-Sequenzen für Anführungszeichen oder \\n mehr. Der Compiler entfernt beiläufige Einrückungen automatisch."
+whyModernWins:
+- icon: "📖"
+  title: "Lesbar wie gehabt"
+  desc: "JSON, SQL und HTML sehen im Quellcode wie echtes JSON, SQL und HTML aus."
+- icon: "🚫"
+  title: "Kein Escape-Chaos"
+  desc: "Eingebettete Anführungszeichen brauchen keine Backslash-Escapes."
+- icon: "📐"
+  title: "Intelligente Einrückung"
+  desc: "Führende Leerzeichen werden automatisch anhand der Position des schließenden Trennzeichens gekürzt."
+support:
+  description: "Seit JDK 15 allgemein verfügbar (Sept. 2020)"
diff --git a/translations/content/de/language/type-inference-with-var.yaml b/translations/content/de/language/type-inference-with-var.yaml
new file mode 100644
index 0000000..87f67d2
--- /dev/null
+++ b/translations/content/de/language/type-inference-with-var.yaml
@@ -0,0 +1,17 @@
+title: "Typinferenz mit var"
+oldApproach: "Explizite Typen"
+modernApproach: "var-Schlüsselwort"
+summary: "var für lokale Variablen-Typinferenz verwenden – weniger Rauschen, gleiche Sicherheit."
+explanation: "Seit Java 10 leitet der Compiler lokale Variablentypen aus der rechten Seite ab. Dies reduziert visuelles Rauschen ohne Einbußen bei der Typsicherheit. var empfiehlt sich, wenn der Typ aus dem Kontext offensichtlich ist."
+whyModernWins:
+- icon: "⚡"
+  title: "Weniger Boilerplate"
+  desc: "Komplexe generische Typen müssen nicht auf beiden Seiten der Zuweisung wiederholt werden."
+- icon: "👁"
+  title: "Bessere Lesbarkeit"
+  desc: "Fokus auf Variablennamen und Werte, nicht auf Typdeklarationen."
+- icon: "🔒"
+  title: "Noch typsicher"
+  desc: "Der Compiler leitet den genauen Typ ab und erzwingt ihn zur Compile-Zeit."
+support:
+  description: "Seit JDK 10 allgemein verfügbar (März 2018)"
diff --git a/translations/content/de/language/unnamed-variables.yaml b/translations/content/de/language/unnamed-variables.yaml
new file mode 100644
index 0000000..6fbcb2a
--- /dev/null
+++ b/translations/content/de/language/unnamed-variables.yaml
@@ -0,0 +1,17 @@
+title: "Unbenannte Variablen mit _"
+oldApproach: "Ungenutzte Variable"
+modernApproach: "_ als Platzhalter"
+summary: "_ verwenden, um anzuzeigen, dass eine Variable absichtlich ungenutzt ist."
+explanation: "Unbenannte Variablen teilen Lesern und Werkzeugen mit, dass ein Wert bewusst ignoriert wird. Keine 'ignored'- oder 'unused'-Namenskonventionen mehr, keine IDE-Warnungen mehr."
+whyModernWins:
+- icon: "📢"
+  title: "Klare Absicht"
+  desc: "_ sagt explizit 'dieser Wert wird hier nicht benötigt'."
+- icon: "🔇"
+  title: "Keine Warnungen"
+  desc: "IDEs und Linter markieren absichtlich ungenutzte Variablen nicht mehr."
+- icon: "🧹"
+  title: "Sauberere Lambdas"
+  desc: "Mehrparametrige Lambdas sind sauberer, wenn nur einige Parameter benötigt werden."
+support:
+  description: "Finalisiert in JDK 22 (JEP 456, März 2024)."

From 750759d77cc6d92426a9aa57783f668c88f90924 Mon Sep 17 00:00:00 2001
From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com>
Date: Thu, 26 Feb 2026 02:59:53 +0000
Subject: [PATCH 5/5] Add German (de) translations for security, streams,
 strings, and tooling patterns

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../de/security/key-derivation-functions.yaml | 19 +++++++++++++
 .../content/de/security/pem-encoding.yaml     | 19 +++++++++++++
 .../content/de/security/random-generator.yaml | 22 +++++++++++++++
 .../content/de/security/strong-random.yaml    | 20 +++++++++++++
 .../content/de/security/tls-default.yaml      | 20 +++++++++++++
 .../de/streams/collectors-flatmapping.yaml    | 19 +++++++++++++
 .../de/streams/optional-ifpresentorelse.yaml  | 19 +++++++++++++
 .../content/de/streams/optional-or.yaml       | 19 +++++++++++++
 .../content/de/streams/predicate-not.yaml     | 21 ++++++++++++++
 .../content/de/streams/stream-gatherers.yaml  | 19 +++++++++++++
 .../de/streams/stream-iterate-predicate.yaml  | 20 +++++++++++++
 .../content/de/streams/stream-mapmulti.yaml   | 19 +++++++++++++
 .../de/streams/stream-of-nullable.yaml        | 19 +++++++++++++
 .../streams/stream-takewhile-dropwhile.yaml   | 20 +++++++++++++
 .../content/de/streams/stream-tolist.yaml     | 19 +++++++++++++
 .../de/streams/virtual-thread-executor.yaml   | 20 +++++++++++++
 .../de/strings/string-chars-stream.yaml       | 19 +++++++++++++
 .../content/de/strings/string-formatted.yaml  | 19 +++++++++++++
 .../de/strings/string-indent-transform.yaml   | 19 +++++++++++++
 .../content/de/strings/string-isblank.yaml    | 18 ++++++++++++
 .../content/de/strings/string-lines.yaml      | 21 ++++++++++++++
 .../content/de/strings/string-repeat.yaml     | 19 +++++++++++++
 .../content/de/strings/string-strip.yaml      | 20 +++++++++++++
 .../de/tooling/aot-class-preloading.yaml      | 21 ++++++++++++++
 .../de/tooling/built-in-http-server.yaml      | 26 +++++++++++++++++
 .../de/tooling/compact-object-headers.yaml    | 19 +++++++++++++
 .../content/de/tooling/jfr-profiling.yaml     | 20 +++++++++++++
 .../de/tooling/jshell-prototyping.yaml        | 20 +++++++++++++
 .../de/tooling/junit6-with-jspecify.yaml      | 28 +++++++++++++++++++
 .../content/de/tooling/multi-file-source.yaml | 19 +++++++++++++
 .../de/tooling/single-file-execution.yaml     | 20 +++++++++++++
 31 files changed, 622 insertions(+)
 create mode 100644 translations/content/de/security/key-derivation-functions.yaml
 create mode 100644 translations/content/de/security/pem-encoding.yaml
 create mode 100644 translations/content/de/security/random-generator.yaml
 create mode 100644 translations/content/de/security/strong-random.yaml
 create mode 100644 translations/content/de/security/tls-default.yaml
 create mode 100644 translations/content/de/streams/collectors-flatmapping.yaml
 create mode 100644 translations/content/de/streams/optional-ifpresentorelse.yaml
 create mode 100644 translations/content/de/streams/optional-or.yaml
 create mode 100644 translations/content/de/streams/predicate-not.yaml
 create mode 100644 translations/content/de/streams/stream-gatherers.yaml
 create mode 100644 translations/content/de/streams/stream-iterate-predicate.yaml
 create mode 100644 translations/content/de/streams/stream-mapmulti.yaml
 create mode 100644 translations/content/de/streams/stream-of-nullable.yaml
 create mode 100644 translations/content/de/streams/stream-takewhile-dropwhile.yaml
 create mode 100644 translations/content/de/streams/stream-tolist.yaml
 create mode 100644 translations/content/de/streams/virtual-thread-executor.yaml
 create mode 100644 translations/content/de/strings/string-chars-stream.yaml
 create mode 100644 translations/content/de/strings/string-formatted.yaml
 create mode 100644 translations/content/de/strings/string-indent-transform.yaml
 create mode 100644 translations/content/de/strings/string-isblank.yaml
 create mode 100644 translations/content/de/strings/string-lines.yaml
 create mode 100644 translations/content/de/strings/string-repeat.yaml
 create mode 100644 translations/content/de/strings/string-strip.yaml
 create mode 100644 translations/content/de/tooling/aot-class-preloading.yaml
 create mode 100644 translations/content/de/tooling/built-in-http-server.yaml
 create mode 100644 translations/content/de/tooling/compact-object-headers.yaml
 create mode 100644 translations/content/de/tooling/jfr-profiling.yaml
 create mode 100644 translations/content/de/tooling/jshell-prototyping.yaml
 create mode 100644 translations/content/de/tooling/junit6-with-jspecify.yaml
 create mode 100644 translations/content/de/tooling/multi-file-source.yaml
 create mode 100644 translations/content/de/tooling/single-file-execution.yaml

diff --git a/translations/content/de/security/key-derivation-functions.yaml b/translations/content/de/security/key-derivation-functions.yaml
new file mode 100644
index 0000000..044f677
--- /dev/null
+++ b/translations/content/de/security/key-derivation-functions.yaml
@@ -0,0 +1,19 @@
+title: Schlüsselableitungsfunktionen
+oldApproach: Manuelles PBKDF2
+modernApproach: KDF-API
+summary: Kryptografische Schlüssel mit der Standard-KDF-API ableiten.
+explanation: Die KDF-API bietet eine standardisierte Schnittstelle für Schlüsselableitungsfunktionen
+  einschließlich HKDF. Sie ersetzt das umständliche Muster aus SecretKeyFactory und
+  PBEKeySpec durch eine saubere Builder-API.
+whyModernWins:
+- icon: 📐
+  title: Saubere API
+  desc: Builder-Muster statt umständlicher KeySpec-Konstruktoren.
+- icon: 🔧
+  title: HKDF-Unterstützung
+  desc: Moderner HKDF-Algorithmus neben PBKDF2.
+- icon: 🛡️
+  title: Standard
+  desc: Einheitliche API für alle Schlüsselableitungsalgorithmen.
+support:
+  description: In JDK 25 LTS finalisiert (JEP 510, Sept. 2025).
diff --git a/translations/content/de/security/pem-encoding.yaml b/translations/content/de/security/pem-encoding.yaml
new file mode 100644
index 0000000..b3b3e03
--- /dev/null
+++ b/translations/content/de/security/pem-encoding.yaml
@@ -0,0 +1,19 @@
+title: PEM-Kodierung/Dekodierung
+oldApproach: Manuelles Base64 + Header
+modernApproach: PEM-API
+summary: Kryptografische Objekte im PEM-Format nativ kodieren und dekodieren.
+explanation: Die PEM-API bietet standardisierte Kodierung/Dekodierung für Zertifikate,
+  Schlüssel und andere kryptografische Objekte im PEM-Format. Kein manuelles Base64-Wrapping
+  mit BEGIN/END-Headern mehr.
+whyModernWins:
+- icon: 🧹
+  title: Kein manuelles Base64
+  desc: PEM-Header, Zeilenumbruch und Base64 werden automatisch behandelt.
+- icon: 🔄
+  title: Bidirektional
+  desc: Mit einer API zu PEM kodieren und von PEM dekodieren.
+- icon: 🛡️
+  title: Standardformat
+  desc: Erzeugt RFC 7468-konformes PEM-Ausgabeformat.
+support:
+  description: Vorschau in JDK 25 (JEP 470). Erfordert --enable-preview.
diff --git a/translations/content/de/security/random-generator.yaml b/translations/content/de/security/random-generator.yaml
new file mode 100644
index 0000000..da45762
--- /dev/null
+++ b/translations/content/de/security/random-generator.yaml
@@ -0,0 +1,22 @@
+title: RandomGenerator-Interface
+oldApproach: new Random() / ThreadLocalRandom
+modernApproach: RandomGenerator-Factory
+summary: Das RandomGenerator-Interface verwenden, um Zufallszahlenalgorithmen per
+  Name auszuwählen, ohne an eine bestimmte Klasse gebunden zu sein.
+explanation: JDK 17 führte RandomGenerator als gemeinsames Interface für alle RNG-Implementierungen
+  ein. Statt new Random() oder ThreadLocalRandom fest zu kodieren, können Algorithmen
+  per Name über eine Factory ausgewählt werden, was den Wechsel zwischen für unterschiedliche
+  Anwendungsfälle optimierten Algorithmen erleichtert (Geschwindigkeit, statistische
+  Qualität, Teilbarkeit).
+whyModernWins:
+- icon: 🔧
+  title: Algorithmus-agnostisch
+  desc: Den besten RNG-Algorithmus per Name wählen, ohne die Codestruktur zu ändern.
+- icon: ⚡
+  title: Bessere Algorithmen
+  desc: Zugang zu modernen LXM-Generatoren mit überlegenen statistischen Eigenschaften.
+- icon: 🔗
+  title: Einheitliche API
+  desc: Eine Schnittstelle für Random, ThreadLocalRandom, SplittableRandom und mehr.
+support:
+  description: Verfügbar seit JDK 17 (September 2021, JEP 356).
diff --git a/translations/content/de/security/strong-random.yaml b/translations/content/de/security/strong-random.yaml
new file mode 100644
index 0000000..709dda2
--- /dev/null
+++ b/translations/content/de/security/strong-random.yaml
@@ -0,0 +1,20 @@
+title: Starke Zufallszahlengenerierung
+oldApproach: new SecureRandom()
+modernApproach: getInstanceStrong()
+summary: Die stärkste SecureRandom-Implementierung der Plattform abrufen.
+explanation: getInstanceStrong() gibt die SecureRandom-Implementierung zurück, die
+  auf der Plattform als die stärkste konfiguriert ist. Dies wird durch die Sicherheitseigenschaft
+  securerandom.strongAlgorithms gesteuert.
+whyModernWins:
+- icon: 🛡️
+  title: Stärkste verfügbare
+  desc: Wählt automatisch den besten Algorithmus für die Plattform.
+- icon: 📖
+  title: Explizite Absicht
+  desc: Kommuniziert klar, dass starke Zufälligkeit erforderlich ist.
+- icon: 🔧
+  title: Konfigurierbar
+  desc: Administratoren können den starken Algorithmus über Sicherheitseigenschaften
+    ändern.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/security/tls-default.yaml b/translations/content/de/security/tls-default.yaml
new file mode 100644
index 0000000..c73c089
--- /dev/null
+++ b/translations/content/de/security/tls-default.yaml
@@ -0,0 +1,20 @@
+title: TLS 1.3 als Standard
+oldApproach: Manuelle TLS-Konfiguration
+modernApproach: TLS 1.3 als Standard
+summary: "TLS 1.3 ist standardmäßig aktiviert — keine explizite Protokollkonfiguration\
+  \ erforderlich."
+explanation: Java 11 hat TLS 1.3-Unterstützung hinzugefügt und es zum bevorzugten
+  Protokoll gemacht. Der HttpClient verwendet es automatisch. Keine manuelle Angabe
+  von Protokollversionen für sichere Verbindungen mehr.
+whyModernWins:
+- icon: 🛡️
+  title: Sicherer
+  desc: TLS 1.3 entfernt veraltete Cipher-Suites und Handshake-Muster.
+- icon: ⚡
+  title: Schnellerer Handshake
+  desc: TLS 1.3 wird in einem statt zwei Roundtrips abgeschlossen.
+- icon: 🆓
+  title: Keine Konfiguration
+  desc: "Standardmäßig sicher — keine explizite Protokollauswahl erforderlich."
+support:
+  description: Weitgehend verfügbar seit JDK 11 (Sept. 2018)
diff --git a/translations/content/de/streams/collectors-flatmapping.yaml b/translations/content/de/streams/collectors-flatmapping.yaml
new file mode 100644
index 0000000..9a57182
--- /dev/null
+++ b/translations/content/de/streams/collectors-flatmapping.yaml
@@ -0,0 +1,19 @@
+title: Collectors.flatMapping()
+oldApproach: Verschachteltes flatMap
+modernApproach: flatMapping()
+summary: flatMapping() zum Abflachen innerhalb eines Gruppierungs-Collectors verwenden.
+explanation: Collectors.flatMapping() wendet eine Eins-zu-viele-Abbildung als nachgelagerten
+  Collector an. Es ist das Collector-Äquivalent von Stream.flatMap() – nützlich innerhalb
+  von groupingBy oder partitioningBy.
+whyModernWins:
+- icon: 🧩
+  title: Kombinierbar
+  desc: Funktioniert als nachgelagerter Collector innerhalb von groupingBy.
+- icon: 📐
+  title: Einmaliger Durchlauf
+  desc: Abflachen und Gruppieren in einem einzigen Stream-Durchlauf.
+- icon: 🔗
+  title: Verschachtelbar
+  desc: Lässt sich mit anderen nachgelagerten Collectors kombinieren.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/streams/optional-ifpresentorelse.yaml b/translations/content/de/streams/optional-ifpresentorelse.yaml
new file mode 100644
index 0000000..39454b1
--- /dev/null
+++ b/translations/content/de/streams/optional-ifpresentorelse.yaml
@@ -0,0 +1,19 @@
+title: Optional.ifPresentOrElse()
+oldApproach: if/else auf Optional
+modernApproach: ifPresentOrElse()
+summary: Beide Fälle eines Optional – vorhanden und leer – in einem einzigen Aufruf
+  behandeln.
+explanation: ifPresentOrElse() nimmt einen Consumer für den vorhandenen Fall und ein
+  Runnable für den leeren Fall. Es vermeidet das isPresent/get-Antimuster.
+whyModernWins:
+- icon: 📏
+  title: Einzelner Ausdruck
+  desc: Beide Fälle werden in einem Methodenaufruf behandelt.
+- icon: 🚫
+  title: Kein get()
+  desc: Eliminiert das gefährliche isPresent() + get()-Muster.
+- icon: 🔗
+  title: Fließend
+  desc: Kettet sich natürlich nach findUser() oder jeder Optional-zurückgebenden Methode.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/streams/optional-or.yaml b/translations/content/de/streams/optional-or.yaml
new file mode 100644
index 0000000..b3b378e
--- /dev/null
+++ b/translations/content/de/streams/optional-or.yaml
@@ -0,0 +1,19 @@
+title: Optional.or() als Fallback
+oldApproach: Verschachtelter Fallback
+modernApproach: .or()-Kette
+summary: Optional-Fallbacks ohne verschachtelte Prüfungen verketten.
+explanation: Optional.or() gibt das ursprüngliche Optional zurück, wenn es einen Wert
+  hat, andernfalls wird der Supplier ausgewertet, um ein alternatives Optional zu
+  erhalten. Suppliers sind lazy – sie werden nur bei Bedarf aufgerufen.
+whyModernWins:
+- icon: 🔗
+  title: Verkettbar
+  desc: Fallbacks in einer lesbaren Pipeline stapeln.
+- icon: ⚡
+  title: Lazy-Auswertung
+  desc: Fallback-Supplier werden nur bei Bedarf ausgeführt.
+- icon: 📖
+  title: Deklarativ
+  desc: "Liest sich wie 'versuche primär, oder sekundär, oder Standard'."
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/streams/predicate-not.yaml b/translations/content/de/streams/predicate-not.yaml
new file mode 100644
index 0000000..b9baa44
--- /dev/null
+++ b/translations/content/de/streams/predicate-not.yaml
@@ -0,0 +1,21 @@
+title: Predicate.not() zur Negation
+oldApproach: Lambda-Negation
+modernApproach: Predicate.not()
+summary: Predicate.not() verwenden, um Methodenreferenzen sauber zu negieren, statt
+  Lambda-Wrapper zu schreiben.
+explanation: Vor Java 11 musste eine Methodenreferenz zur Negation in ein Lambda eingewickelt
+  werden. Predicate.not() ermöglicht die direkte Negation eines beliebigen Prädikats,
+  was den Code lesbar und konsistent mit dem Methodenreferenz-Stil im gesamten Stream-Pipeline
+  hält.
+whyModernWins:
+- icon: 👁
+  title: Sauberere Negation
+  desc: Keine Lambda-Wrapper für Methodenreferenzen nur zur Negation nötig.
+- icon: 🔗
+  title: Kombinierbar
+  desc: Funktioniert mit jedem Predicate und ermöglicht saubere Prädikat-Ketten.
+- icon: 📖
+  title: Natürlich lesbar
+  desc: Predicate.not(String::isBlank) liest sich wie natürliche Sprache.
+support:
+  description: Verfügbar seit JDK 11 (September 2018).
diff --git a/translations/content/de/streams/stream-gatherers.yaml b/translations/content/de/streams/stream-gatherers.yaml
new file mode 100644
index 0000000..77d8103
--- /dev/null
+++ b/translations/content/de/streams/stream-gatherers.yaml
@@ -0,0 +1,19 @@
+title: Stream-Gatherers
+oldApproach: Benutzerdefinierter Collector
+modernApproach: gather()
+summary: Gatherers für benutzerdefinierte Zwischen-Stream-Operationen verwenden.
+explanation: Gatherers sind eine neue Zwischen-Stream-Operation, die komplexe Transformationen
+  wie gleitende Fenster, Gruppen fester Größe und Scan-Operationen ausdrücken kann,
+  die mit Standard-Stream-Operationen nicht möglich waren.
+whyModernWins:
+- icon: 🧩
+  title: Kombinierbar
+  desc: Gatherers lassen sich mit anderen Stream-Operationen kombinieren.
+- icon: 📦
+  title: Eingebaute Operationen
+  desc: windowFixed, windowSliding, fold, scan sofort verfügbar.
+- icon: 🔧
+  title: Erweiterbar
+  desc: Eigene Gatherers für beliebige Zwischentransformationen schreiben.
+support:
+  description: In JDK 24 finalisiert (JEP 485, März 2025).
diff --git a/translations/content/de/streams/stream-iterate-predicate.yaml b/translations/content/de/streams/stream-iterate-predicate.yaml
new file mode 100644
index 0000000..70ef16f
--- /dev/null
+++ b/translations/content/de/streams/stream-iterate-predicate.yaml
@@ -0,0 +1,20 @@
+title: Stream.iterate() mit Prädikat
+oldApproach: iterate + limit
+modernApproach: iterate(seed, pred, op)
+summary: Ein Prädikat zum Beenden der Iteration verwenden – wie eine for-Schleife
+  als Stream.
+explanation: "Das dreiargumented Stream.iterate(seed, hasNext, next) funktioniert\
+  \ wie eine for-Schleife: seed ist der Startwert, hasNext bestimmt den Abbruch und\
+  \ next erzeugt den nächsten Wert."
+whyModernWins:
+- icon: 🎯
+  title: Natürlicher Abbruch
+  desc: Stopp basierend auf einer Bedingung, nicht einem willkürlichen Limit.
+- icon: 📐
+  title: For-Schleifen-Äquivalent
+  desc: Gleiche Semantik wie for(seed; hasNext; next).
+- icon: 🛡️
+  title: Kein Risiko eines unendlichen Streams
+  desc: Das Prädikat garantiert die Terminierung.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/streams/stream-mapmulti.yaml b/translations/content/de/streams/stream-mapmulti.yaml
new file mode 100644
index 0000000..ac4dd79
--- /dev/null
+++ b/translations/content/de/streams/stream-mapmulti.yaml
@@ -0,0 +1,19 @@
+title: Stream.mapMulti()
+oldApproach: flatMap + List
+modernApproach: mapMulti()
+summary: Null oder mehr Elemente pro Eingabe ausgeben, ohne Zwischen-Streams zu erstellen.
+explanation: mapMulti() ist eine imperative Alternative zu flatMap, die das Erstellen
+  von Zwischen-Stream-Objekten für jedes Element vermeidet. Es ist effizienter, wenn
+  die Abbildung eine kleine Anzahl von Elementen erzeugt.
+whyModernWins:
+- icon: ⚡
+  title: Weniger Allokationen
+  desc: Kein Zwischen-Stream pro Element erstellt.
+- icon: 🎯
+  title: Imperativer Stil
+  desc: Schleifen und Bedingungen direkt verwenden.
+- icon: 📐
+  title: Flexibel
+  desc: Null, eins oder viele Elemente mit voller Kontrolle ausgeben.
+support:
+  description: Weitgehend verfügbar seit JDK 16 (März 2021)
diff --git a/translations/content/de/streams/stream-of-nullable.yaml b/translations/content/de/streams/stream-of-nullable.yaml
new file mode 100644
index 0000000..550808c
--- /dev/null
+++ b/translations/content/de/streams/stream-of-nullable.yaml
@@ -0,0 +1,19 @@
+title: Stream.ofNullable()
+oldApproach: Null-Prüfung
+modernApproach: ofNullable()
+summary: Einen Stream mit null oder einem Element aus einem nullable Wert erstellen.
+explanation: Stream.ofNullable() gibt einen Ein-Element-Stream zurück, wenn der Wert
+  nicht null ist, oder einen leeren Stream, wenn er null ist. Eliminiert das ternäre
+  Null-Prüfungsmuster.
+whyModernWins:
+- icon: 📏
+  title: Prägnant
+  desc: Ein Aufruf ersetzt den ternären Ausdruck.
+- icon: 🔗
+  title: flatMap-freundlich
+  desc: Perfekt innerhalb von flatMap zum Überspringen von null-Werten.
+- icon: 🛡️
+  title: Null-sicher
+  desc: Kein NPE-Risiko – null wird zu einem leeren Stream.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/streams/stream-takewhile-dropwhile.yaml b/translations/content/de/streams/stream-takewhile-dropwhile.yaml
new file mode 100644
index 0000000..91c6d19
--- /dev/null
+++ b/translations/content/de/streams/stream-takewhile-dropwhile.yaml
@@ -0,0 +1,20 @@
+title: Stream takeWhile / dropWhile
+oldApproach: Manuelle Schleife
+modernApproach: takeWhile/dropWhile
+summary: Elemente aus einem Stream basierend auf einem Prädikat nehmen oder überspringen.
+explanation: takeWhile() gibt Elemente zurück, solange das Prädikat wahr ist, und
+  stoppt beim ersten Falsch-Wert. dropWhile() überspringt Elemente, solange es wahr
+  ist, und gibt den Rest zurück. Beide funktionieren am besten bei geordneten Streams.
+whyModernWins:
+- icon: 🎯
+  title: Kurzschlussauswertung
+  desc: Stoppt die Verarbeitung, sobald das Prädikat fehlschlägt.
+- icon: 🔗
+  title: Pipeline-freundlich
+  desc: Kettet sich natürlich mit anderen Stream-Operationen.
+- icon: 📖
+  title: Deklarativ
+  desc: "takeWhile liest sich wie natürliche Sprache: 'nehme, solange kleiner als\
+    \ 100'."
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/streams/stream-tolist.yaml b/translations/content/de/streams/stream-tolist.yaml
new file mode 100644
index 0000000..e8c22fb
--- /dev/null
+++ b/translations/content/de/streams/stream-tolist.yaml
@@ -0,0 +1,19 @@
+title: Stream.toList()
+oldApproach: Collectors.toList()
+modernApproach: .toList()
+summary: Das terminale toList() ersetzt das ausführliche collect(Collectors.toList()).
+explanation: "Stream.toList() gibt eine unveränderliche Liste zurück. Es entspricht\
+  \ .collect(Collectors.toUnmodifiableList()), ist aber viel kürzer. Hinweis: Das\
+  \ Ergebnis ist im Gegensatz zu Collectors.toList() unveränderlich."
+whyModernWins:
+- icon: 📏
+  title: 7 Zeichen vs. 24
+  desc: .toList() ersetzt .collect(Collectors.toList()).
+- icon: 🔒
+  title: Unveränderlich
+  desc: Die Ergebnisliste kann nicht verändert werden.
+- icon: 📖
+  title: Fließend
+  desc: Liest sich am Ende einer Pipeline natürlich.
+support:
+  description: Weitgehend verfügbar seit JDK 16 (März 2021)
diff --git a/translations/content/de/streams/virtual-thread-executor.yaml b/translations/content/de/streams/virtual-thread-executor.yaml
new file mode 100644
index 0000000..5d1b062
--- /dev/null
+++ b/translations/content/de/streams/virtual-thread-executor.yaml
@@ -0,0 +1,20 @@
+title: Virtual-Thread-Executor
+oldApproach: Fixer Thread-Pool
+modernApproach: Virtual-Thread-Executor
+summary: Virtual-Thread-Executors für unbegrenzte leichtgewichtige Nebenläufigkeit
+  verwenden.
+explanation: Der Virtual-Thread-Executor erstellt für jede Aufgabe einen neuen virtuellen
+  Thread. Keine Pool-Dimensionierung nötig – virtuelle Threads sind günstig genug,
+  um Millionen davon zu erstellen.
+whyModernWins:
+- icon: ♾️
+  title: Keine Dimensionierung
+  desc: Keine Pool-Größe festzulegen – so viele Threads erstellen wie benötigt.
+- icon: ⚡
+  title: Leichtgewichtig
+  desc: Virtuelle Threads verwenden KB statt MB Speicher.
+- icon: 🧹
+  title: Auto-closeable
+  desc: try-with-resources übernimmt das Herunterfahren automatisch.
+support:
+  description: Weitgehend verfügbar seit JDK 21 LTS (Sept. 2023)
diff --git a/translations/content/de/strings/string-chars-stream.yaml b/translations/content/de/strings/string-chars-stream.yaml
new file mode 100644
index 0000000..0b6f8ef
--- /dev/null
+++ b/translations/content/de/strings/string-chars-stream.yaml
@@ -0,0 +1,19 @@
+title: String-Zeichen als Stream
+oldApproach: Manuelle Schleife
+modernApproach: chars()-Stream
+summary: String-Zeichen als Stream-Pipeline verarbeiten.
+explanation: String.chars() gibt einen IntStream von Zeichenwerten zurück und ermöglicht
+  funktionale Verarbeitung. Für Unicode-Unterstützung behandelt codePoints() ergänzende
+  Zeichen korrekt.
+whyModernWins:
+- icon: 🔗
+  title: Verkettbar
+  desc: Filter, Map, Collect auf Zeichen-Streams anwenden.
+- icon: 📐
+  title: Deklarativ
+  desc: Beschreibt was zu tun ist, nicht wie zu iterieren.
+- icon: 🌐
+  title: Unicode-bereit
+  desc: codePoints() behandelt Emojis und ergänzende Zeichen korrekt.
+support:
+  description: Verfügbar seit JDK 8+ (verbessert in 9+)
diff --git a/translations/content/de/strings/string-formatted.yaml b/translations/content/de/strings/string-formatted.yaml
new file mode 100644
index 0000000..7704dbf
--- /dev/null
+++ b/translations/content/de/strings/string-formatted.yaml
@@ -0,0 +1,19 @@
+title: String.formatted()
+oldApproach: String.format()
+modernApproach: formatted()
+summary: formatted() direkt auf dem Template-String aufrufen.
+explanation: String.formatted() ist eine Instanzmethode, die String.format() entspricht,
+  aber auf dem Formatierungsstring aufgerufen wird. Sie liest sich natürlicher in
+  einem Links-nach-Rechts-Fluss.
+whyModernWins:
+- icon: 📖
+  title: Natürlich lesbar
+  desc: Template.formatted(args) fließt besser als String.format(template, args).
+- icon: 🔗
+  title: Verkettbar
+  desc: Kann mit anderen String-Methoden verkettet werden.
+- icon: 📏
+  title: Weniger ausführlich
+  desc: Entfällt der redundante statische Aufruf von String.format().
+support:
+  description: Weitgehend verfügbar seit JDK 15 (Sept. 2020)
diff --git a/translations/content/de/strings/string-indent-transform.yaml b/translations/content/de/strings/string-indent-transform.yaml
new file mode 100644
index 0000000..f35c2f6
--- /dev/null
+++ b/translations/content/de/strings/string-indent-transform.yaml
@@ -0,0 +1,19 @@
+title: String.indent() und transform()
+oldApproach: Manuelle Einrückung
+modernApproach: indent() / transform()
+summary: Text einrücken und String-Transformationen fließend verketten.
+explanation: indent(n) fügt jeder Zeile n Leerzeichen hinzu. transform(fn) wendet
+  eine beliebige Funktion an und gibt das Ergebnis zurück, was fließendes Verketten
+  von String-Operationen ermöglicht.
+whyModernWins:
+- icon: 📏
+  title: Eingebaut
+  desc: Einrückung ist eine häufige Operation – jetzt ein einziger Aufruf.
+- icon: 🔗
+  title: Verkettbar
+  desc: transform() ermöglicht fließende Pipelines auf Strings.
+- icon: 🧹
+  title: Sauberer Code
+  desc: Kein manuelles Aufteilen von Zeilen und StringBuilder-Schleifen.
+support:
+  description: Weitgehend verfügbar seit JDK 12 (März 2019)
diff --git a/translations/content/de/strings/string-isblank.yaml b/translations/content/de/strings/string-isblank.yaml
new file mode 100644
index 0000000..6b21000
--- /dev/null
+++ b/translations/content/de/strings/string-isblank.yaml
@@ -0,0 +1,18 @@
+title: String.isBlank()
+oldApproach: trim().isEmpty()
+modernApproach: isBlank()
+summary: Leere Strings mit einem einzigen Methodenaufruf prüfen.
+explanation: isBlank() gibt true zurück, wenn der String leer ist oder nur Leerzeichen
+  enthält, einschließlich Unicode-Leerzeichen, die trim() übersieht.
+whyModernWins:
+- icon: 📖
+  title: Selbstdokumentierend
+  desc: isBlank() sagt genau, was es prüft.
+- icon: 🌐
+  title: Unicode-bewusst
+  desc: Behandelt alle Unicode-Leerzeichen, nicht nur ASCII.
+- icon: ⚡
+  title: Keine Allokation
+  desc: Es wird kein zwischenzeitlicher gekürzter String erstellt.
+support:
+  description: Weitgehend verfügbar seit JDK 11 (Sept. 2018)
diff --git a/translations/content/de/strings/string-lines.yaml b/translations/content/de/strings/string-lines.yaml
new file mode 100644
index 0000000..30edeed
--- /dev/null
+++ b/translations/content/de/strings/string-lines.yaml
@@ -0,0 +1,21 @@
+title: String.lines() zum Aufteilen von Zeilen
+oldApproach: split("\\n")
+modernApproach: lines()
+summary: String.lines() verwenden, um Text ohne Regex-Overhead in einen Stream von
+  Zeilen aufzuteilen.
+explanation: "String.lines() gibt einen Stream<String> von Zeilen zurück, aufgeteilt\
+  \ nach \\n, \\r oder \\r\\n. Es ist träger und effizienter als split(), vermeidet\
+  \ Regex-Kompilierung und lässt sich natürlich in die Stream-API für weitere Verarbeitung\
+  \ integrieren."
+whyModernWins:
+- icon: ⚡
+  title: Lazy-Streaming
+  desc: Zeilen werden bei Bedarf erzeugt, nicht alle auf einmal wie bei split().
+- icon: 🔧
+  title: Universelle Zeilenendezeichen
+  desc: "Behandelt \\n, \\r und \\r\\n automatisch ohne Regex."
+- icon: 🔗
+  title: Stream-Integration
+  desc: Gibt einen Stream zur direkten Verwendung mit filter, map, collect zurück.
+support:
+  description: Verfügbar seit JDK 11 (September 2018).
diff --git a/translations/content/de/strings/string-repeat.yaml b/translations/content/de/strings/string-repeat.yaml
new file mode 100644
index 0000000..088e9dd
--- /dev/null
+++ b/translations/content/de/strings/string-repeat.yaml
@@ -0,0 +1,19 @@
+title: String.repeat()
+oldApproach: Schleife mit StringBuilder
+modernApproach: repeat()
+summary: Einen String n-mal ohne Schleife wiederholen.
+explanation: "String.repeat(int) gibt den String n-mal mit sich selbst verkettet\
+  \ zurück. Behandelt Randfälle: repeat(0) gibt einen leeren String zurück, repeat(1)\
+  \ gibt denselben String zurück."
+whyModernWins:
+- icon: 📏
+  title: Einzeiler
+  desc: Ersetzt 5 Zeilen StringBuilder-Code durch einen einzigen Aufruf.
+- icon: ⚡
+  title: Optimiert
+  desc: Die interne Implementierung ist für große Wiederholungen optimiert.
+- icon: 📖
+  title: Klare Absicht
+  desc: repeat(3) vermittelt den Zweck sofort.
+support:
+  description: Weitgehend verfügbar seit JDK 11 (Sept. 2018)
diff --git a/translations/content/de/strings/string-strip.yaml b/translations/content/de/strings/string-strip.yaml
new file mode 100644
index 0000000..5c30adb
--- /dev/null
+++ b/translations/content/de/strings/string-strip.yaml
@@ -0,0 +1,20 @@
+title: String.strip() vs trim()
+oldApproach: trim()
+modernApproach: strip()
+summary: Unicode-bewusstes Entfernen von Leerzeichen mit strip(), stripLeading(),
+  stripTrailing().
+explanation: trim() entfernt nur Zeichen ≤ U+0020 (ASCII-Steuerzeichen und Leerzeichen).
+  strip() verwendet Character.isWhitespace(), das Unicode-Leerzeichen wie geschütztes
+  Leerzeichen, ideografisches Leerzeichen usw. behandelt.
+whyModernWins:
+- icon: 🌐
+  title: Unicode-korrekt
+  desc: Behandelt alle Leerzeichen aus allen Schriftsystemen.
+- icon: 🎯
+  title: Direktional
+  desc: stripLeading() und stripTrailing() für einseitiges Kürzen.
+- icon: 🛡️
+  title: Weniger Fehler
+  desc: Kein unerwartetes Leerzeichen in internationalem Text.
+support:
+  description: Weitgehend verfügbar seit JDK 11 (Sept. 2018)
diff --git a/translations/content/de/tooling/aot-class-preloading.yaml b/translations/content/de/tooling/aot-class-preloading.yaml
new file mode 100644
index 0000000..96c5b00
--- /dev/null
+++ b/translations/content/de/tooling/aot-class-preloading.yaml
@@ -0,0 +1,21 @@
+title: AOT-Klassen-Vorabladen
+oldApproach: Jedes Mal Kaltstart
+modernApproach: AOT-Cache
+summary: Klassen-Laden und Kompilierung cachen für sofortigen Start.
+explanation: Das AOT-Klassen-Vorabladen speichert geladene und verknüpfte Klassen
+  aus einem Trainings-Durchlauf im Cache. Bei nachfolgenden Starts werden Klassen
+  aus dem Cache geladen, wobei Verifizierung und Verknüpfung übersprungen werden.
+  In Kombination mit AOT-Kompilierung verkürzt dies die Startzeit drastisch.
+whyModernWins:
+- icon: ⚡
+  title: Schnellerer Start
+  desc: Klassen-Laden, Verifizierung und Verknüpfung überspringen.
+- icon: 📦
+  title: Gecachter Zustand
+  desc: Der Trainings-Durchlauf erfasst den idealen Klassenzustand.
+- icon: 🔧
+  title: Keine Codeänderungen
+  desc: Funktioniert mit bestehenden Anwendungen – einfach JVM-Flags hinzufügen.
+support:
+  description: Als Standardfunktion in JDK 25 LTS verfügbar (JEPs 514/515, Sept.
+    2025).
diff --git a/translations/content/de/tooling/built-in-http-server.yaml b/translations/content/de/tooling/built-in-http-server.yaml
new file mode 100644
index 0000000..a281708
--- /dev/null
+++ b/translations/content/de/tooling/built-in-http-server.yaml
@@ -0,0 +1,26 @@
+title: Eingebauter HTTP-Server
+oldApproach: Externer Server / Framework
+modernApproach: jwebserver-CLI
+summary: Java 18 enthält einen eingebauten minimalen HTTP-Server für Prototyping und
+  Dateiauslieferung.
+explanation: JDK 18 hat einen einfachen, abhängigkeitsfreien HTTP-Dateiserver hinzugefügt,
+  der über das Befehlszeilenwerkzeug jwebserver oder die SimpleFileServer-API zugänglich
+  ist. Er liefert statische Dateien aus einem angegebenen Verzeichnis ohne Konfiguration.
+  Das CLI-Tool ist ideal für schnelles Prototyping, Tests und ad-hoc-Dateifreigabe
+  – keine externen Abhängigkeiten oder Frameworks erforderlich. Die API ermöglicht
+  die programmatische Verwendung mit anpassbaren Handlern und Ausgabeebenen.
+whyModernWins:
+- icon: 🚀
+  title: Kein Setup
+  desc: jwebserver in einem beliebigen Verzeichnis ausführen – keine Installation,
+    Konfiguration oder Abhängigkeiten erforderlich.
+- icon: 📦
+  title: Im JDK integriert
+  desc: Wird mit jeder JDK 18+-Installation geliefert, immer verfügbar auf jedem
+    Rechner mit Java.
+- icon: 🧪
+  title: Ideal für Prototyping
+  desc: Statische Dateien sofort für das Testen von HTML, APIs oder Front-End-Entwicklung
+    bereitstellen.
+support:
+  description: Verfügbar seit JDK 18 (März 2022)
diff --git a/translations/content/de/tooling/compact-object-headers.yaml b/translations/content/de/tooling/compact-object-headers.yaml
new file mode 100644
index 0000000..2ffbda9
--- /dev/null
+++ b/translations/content/de/tooling/compact-object-headers.yaml
@@ -0,0 +1,19 @@
+title: Kompakte Objekt-Header
+oldApproach: 128-Bit-Header
+modernApproach: 64-Bit-Header
+summary: Objekt-Header-Größe halbieren für bessere Speicherdichte und Cache-Nutzung.
+explanation: Kompakte Objekt-Header reduzieren den Overhead pro Objekt von 128 Bit
+  auf 64 Bit auf 64-Bit-Plattformen. Dies spart Speicher und verbessert die Cache-Nutzung,
+  insbesondere für Anwendungen mit vielen kleinen Objekten.
+whyModernWins:
+- icon: 📦
+  title: 50 % kleinere Header
+  desc: 8 Bytes statt 16 pro Objekt.
+- icon: ⚡
+  title: Bessere Cache-Nutzung
+  desc: Mehr Objekte passen in CPU-Cache-Zeilen.
+- icon: 📊
+  title: Höhere Dichte
+  desc: Mehr Objekte im gleichen Heap-Bereich.
+support:
+  description: In JDK 25 LTS finalisiert (JEP 519, Sept. 2025).
diff --git a/translations/content/de/tooling/jfr-profiling.yaml b/translations/content/de/tooling/jfr-profiling.yaml
new file mode 100644
index 0000000..c106378
--- /dev/null
+++ b/translations/content/de/tooling/jfr-profiling.yaml
@@ -0,0 +1,20 @@
+title: JFR für Profiling
+oldApproach: Externer Profiler
+modernApproach: Java Flight Recorder
+summary: Jede Java-App mit dem eingebauten Flight Recorder profilieren – ohne externe
+  Tools.
+explanation: Java Flight Recorder (JFR) ist ein in die JVM integriertes Profiling-Tool
+  mit geringem Overhead. Es erfasst Ereignisse für CPU, Speicher, GC, E/A, Threads
+  und benutzerdefinierte Ereignisse mit minimalem Leistungseinfluss (~1%).
+whyModernWins:
+- icon: 🆓
+  title: Eingebaut
+  desc: Kein externer Profiler zum Installieren oder Lizenzieren.
+- icon: ⚡
+  title: Geringer Overhead
+  desc: ~1% Leistungseinfluss – sicher für den Produktionseinsatz.
+- icon: 📊
+  title: Umfangreiche Ereignisse
+  desc: CPU, Speicher, GC, Threads, E/A, Locks und benutzerdefinierte Ereignisse.
+support:
+  description: Weitgehend verfügbar seit JDK 9/11 (Open-Source in 11)
diff --git a/translations/content/de/tooling/jshell-prototyping.yaml b/translations/content/de/tooling/jshell-prototyping.yaml
new file mode 100644
index 0000000..814cd20
--- /dev/null
+++ b/translations/content/de/tooling/jshell-prototyping.yaml
@@ -0,0 +1,20 @@
+title: JShell für Prototyping
+oldApproach: Datei erstellen + kompilieren + ausführen
+modernApproach: JShell-REPL
+summary: Java-Ausdrücke interaktiv ausprobieren, ohne Dateien zu erstellen.
+explanation: JShell ist eine Read-Eval-Print-Schleife für Java. Ausdrücke testen,
+  APIs erkunden und Code prototypen, ohne Dateien zu erstellen, zu kompilieren oder
+  eine main-Methode zu schreiben. Tab-Vervollständigung und kontextbezogene Dokumentation
+  inklusive.
+whyModernWins:
+- icon: ⚡
+  title: Sofortiges Feedback
+  desc: Einen Ausdruck eingeben und das Ergebnis sofort sehen.
+- icon: 📝
+  title: Keine Dateien benötigt
+  desc: Keine .java-Dateien, kein Kompilierungsschritt.
+- icon: 🔍
+  title: API-Erkundung
+  desc: Tab-Vervollständigung hilft beim Entdecken von Methoden und Parametern.
+support:
+  description: Weitgehend verfügbar seit JDK 9 (Sept. 2017)
diff --git a/translations/content/de/tooling/junit6-with-jspecify.yaml b/translations/content/de/tooling/junit6-with-jspecify.yaml
new file mode 100644
index 0000000..a5228cb
--- /dev/null
+++ b/translations/content/de/tooling/junit6-with-jspecify.yaml
@@ -0,0 +1,28 @@
+title: JUnit 6 mit JSpecify-Nullsicherheit
+oldApproach: Nicht annotierte API
+modernApproach: "@NullMarked-API"
+summary: "JUnit 6 übernimmt @NullMarked von JSpecify und macht Null-Verträge in der\
+  \ gesamten Assertion-API explizit."
+explanation: "JUnit 5 wurde ohne standardisierte Nullbarkeits-Annotationen ausgeliefert,\
+  \ sodass Entwickler raten mussten, ob Assertion-Parameter oder Rückgabewerte null\
+  \ sein könnten. JUnit 6 übernimmt JSpecify für sein gesamtes Modul: Die @NullMarked-Annotation\
+  \ macht alle nicht annotierten Typen standardmäßig nicht-null, und @Nullable markiert\
+  \ die Ausnahmen. Die Assertions-Klasse annotiert Parameter explizit wie assertNull(@Nullable\
+  \ Object actual) und fail(@Nullable String message), sodass IDEs und statische Analysatoren\
+  \ wie NullAway und Error Prone Null-Missbrauch zur Kompilierungszeit statt zur Laufzeit\
+  \ erkennen können."
+whyModernWins:
+- icon: 📜
+  title: Explizite Verträge
+  desc: "@NullMarked im JUnit-6-Modul dokumentiert die Null-Semantik direkt in der\
+    \ API – kein Lesen des Quellcodes erforderlich."
+- icon: 🛡️
+  title: Sicherheit zur Kompilierzeit
+  desc: IDEs und Analysatoren warnen, wenn null übergeben wird, wo Nicht-null erwartet
+    wird, und erkennen Fehler vor dem Testlauf.
+- icon: 🌐
+  title: Ökosystem-Standard
+  desc: JSpecify wird von Spring, Guava und anderen übernommen – konsistente Null-Semantik
+    im gesamten Stack.
+support:
+  description: Verfügbar seit JUnit 6.0 (Oktober 2025, erfordert Java 17+)
diff --git a/translations/content/de/tooling/multi-file-source.yaml b/translations/content/de/tooling/multi-file-source.yaml
new file mode 100644
index 0000000..24d9238
--- /dev/null
+++ b/translations/content/de/tooling/multi-file-source.yaml
@@ -0,0 +1,19 @@
+title: Multi-Datei-Quellcode-Launcher
+oldApproach: Zuerst alles kompilieren
+modernApproach: Quellcode-Launcher
+summary: Multi-Datei-Programme ohne expliziten Kompilierungsschritt starten.
+explanation: Java 22+ kann referenzierte Quelldateien beim Start aus einer .java-Datei
+  automatisch kompilieren. Dies macht kleine Multi-Datei-Programme genauso einfach
+  ausführbar wie Skripte, ohne Maven oder Gradle zu benötigen.
+whyModernWins:
+- icon: 🚀
+  title: Kein Setup
+  desc: Kein Build-Tool für kleine Multi-Datei-Programme erforderlich.
+- icon: 🔗
+  title: Automatische Auflösung
+  desc: Referenzierte Klassen werden automatisch gefunden und kompiliert.
+- icon: 📝
+  title: Skript-ähnlich
+  desc: Multi-Datei-Programme wie Skripte ausführen.
+support:
+  description: Verfügbar seit JDK 22 (März 2024)
diff --git a/translations/content/de/tooling/single-file-execution.yaml b/translations/content/de/tooling/single-file-execution.yaml
new file mode 100644
index 0000000..6ea85f5
--- /dev/null
+++ b/translations/content/de/tooling/single-file-execution.yaml
@@ -0,0 +1,20 @@
+title: Einzeldatei-Ausführung
+oldApproach: Zweistufige Kompilierung
+modernApproach: Direktstart
+summary: Einzeldatei-Java-Programme direkt ohne javac ausführen.
+explanation: Der Java-Launcher kann eine einzelne Quelldatei in einem Befehl kompilieren
+  und ausführen. In Kombination mit Shebang-Unterstützung unter Unix können Java-Dateien
+  als Skripte fungieren. Kein separater Kompilierungsschritt erforderlich.
+whyModernWins:
+- icon: ⚡
+  title: Ein einziger Befehl
+  desc: java Datei.java kompiliert und führt in einem Schritt aus.
+- icon: 📝
+  title: Skript-ähnlich
+  desc: Eine Shebang-Zeile hinzufügen, um .java-Dateien zu ausführbaren Skripten
+    zu machen.
+- icon: 🎓
+  title: Lernfreundlich
+  desc: Einsteiger führen Code sofort aus, ohne Build-Tools erlernen zu müssen.
+support:
+  description: Weitgehend verfügbar seit JDK 11 (Sept. 2018)