Translates various checks

Signed-off-by: Sebastian Kawelke <sebastian.kawelke@l3montree.com>

src/pages/de/concepts/implemented-checks/_meta.ts

@@ -2,5 +2,12 @@
 // SPDX-License-Identifier: MIT
 
 export default {
-    index: { title: 'Overview' },
+    index: { title: 'Überblick' },
+    'bus-factor': { title: 'Bus-Faktor' },
+    'ci-pipeline': { title: 'CI-Pipeline' },
+    commits: { title: 'Commits' },
+    'elephant-factor': { title: 'Elephant-Faktor' },
+    'issue-reaction-time': { title: 'Reaktionszeit auf Issues' },
+    packages: { title: 'Pakete' },
+    'protected-branches': { title: 'Geschützte Branches' },
 }

src/pages/de/concepts/implemented-checks/bus-factor.mdx

@@ -3,14 +3,14 @@ SPDX-License-Identifier: MIT */}
 
 import { Callout } from 'nextra/components'
 
-# Bus Factor
+# Bus Faktor
 
 <Callout type="default">
-  Check type: `BUS_FACTOR`
+  Check Typ: `BUS_FACTOR`
 </Callout>
 
-This check calculates the bus factor of a project for a given time range.
-The check passes if the bus factor is greater than or equal to the minimum threshold.
+Dieser Check berechnet den Busfaktor eines Projekts für einen bestimmten Zeitraum.
+Der Check gilt als bestanden, wenn der Busfaktor größer oder gleich dem Mindestschwellenwert ist.
 
 ```yaml filename=".badge-api.yaml" copy
 - type: BUS_FACTOR
@@ -20,13 +20,13 @@ The check passes if the bus factor is greater than or equal to the minimum thres
     min: 2
 ```
 
-### Background
+### Hintergrund
 
-The bus factor is a measure of the risk resulting from information and capabilities not being shared among team members.
+Der Bus-Faktor ist ein Maß für das Risiko, das entsteht, wenn Informationen und Fähigkeiten nicht unter den Teammitgliedern geteilt werden.
 
-Imagine there is a pretty precise bus that unfortunately hits always exactly one person. The bus factor is the number of people
-that need to be hit by the bus until half of the projects commits have no living producer anymore. The higher the bus factor,
-the lower the risk of the project failing due to the loss of a single person.
+Stellen Sie sich vor, es gibt einen ziemlich präzisen Bus, der leider immer genau eine Person überfährt. Der Bus-Faktor ist die Anzahl der
+Personen, die vom Bus überfahren werden müssen, bis die Hälfte der Commits im Projekt keinen lebenden Contributor mehr hat. Je höher der
+Bus-Faktor, desto geringer ist das Risiko, dass das Projekt aufgrund des Verlusts einer einzelnen Person scheitert.
 
-For example if a project has a bus factor of 2, it means that the 2 most important contributors are responsible for 50% of the commits
-and after both are gone, the project would be in danger.
+Wenn ein Projekt beispielsweise einen Bus-Faktor von 2 hat, bedeutet dies, dass die beiden wichtigsten Beitragenden für 50 % der
+Commits verantwortlich sind und das Projekt in Gefahr wäre, wenn beide wegfallen würden.
\ No newline at end of file

src/pages/de/concepts/implemented-checks/ci-pipeline.mdx

@@ -6,14 +6,14 @@ import { Callout } from 'nextra/components'
 # CI Pipeline
 
 <Callout type="default">
-  Check type: `CI_PIPELINE`
+  Check Typ: `CI_PIPELINE`
 </Callout>
 
-This check queries the GitLab API and counts the number of CI pipeline runs (whether successfull or failed)
-in the time range.
-The check passes if the number of commits is greater than or equal to the minimum threshold.
+Dieser Check fragt die GitLab-API ab und zählt die Anzahl der CI-Pipeline-Durchläufe (erfolgreich oder fehlgeschlagen) im Betrachtungszeitraum.
+Der Check gilt als bestanden, wenn die Anzahl der Commits größer oder gleich dem Mindestschwellenwert ist.
+
+Die Anzahl der erfolgreichen CI-Pipeline-Läufe wird als Information im Nachweis der API-Antwort bereitgestellt.
 
-The number of successfull CI pipeline runs is provided as info in the evidence of the API Response.
 
 ```yaml filename=".badge-api.yaml" copy
 - type: CI_PIPELINE
@@ -23,14 +23,16 @@ The number of successfull CI pipeline runs is provided as info in the evidence o
     min: 1
 ```
 
-### Background
+### Hintergrund
 
-Measuring the number of CI pipeline runs can help gauge the stability and reliability of a project's 
-development process. A high number of successful pipeline runs indicates a well-maintained and 
-stable codebase, with regular testing and validation.
+Die Messung der Anzahl der CI-Pipeline-Durchläufe kann dabei helfen, die Stabilität und Zuverlässigkeit
+des Entwicklungsprozesses eines Projekts zu beurteilen. Eine hohe Anzahl erfolgreicher Pipeline-Durchläufe
+deutet auf eine gut gepflegte und stabile Codebasis mit regelmäßigen Tests und Validierungen hin.
 
-- Continuous Integration Health: Frequent CI pipeline runs indicates that the project is undergoing regular 
-automated testing, catching errors early, and ensuring the quality of the software.
+- Continuous Integration Ansatz: Häufige CI-Pipeline-Läufe deuten darauf hin, dass das Projekt regelmäßigen
+  automatisierten Tests unterzogen wird, wodurch Fehler frühzeitig erkannt und die Qualität der Software
+  sichergestellt werden.
 
-- Development Efficiency: A smooth CI pipeline also reflects the development team's efficiency in 
-integrating and testing new changes, improving the project's overall workflow and reducing the likelihood of issues in production.
+- Entwicklungseffizienz: Eine reibungslose CI-Pipeline spiegelt auch die Effizienz des Entwicklungsteams
+  bei der Integration und dem Testen neuer Änderungen wider, wodurch der Gesamt-Workflow des Projekts
\ No newline at end of file
+  verbessert und die Wahrscheinlichkeit von Problemen in der Produktion verringert wird.
\ No newline at end of file

src/pages/de/concepts/implemented-checks/commits.mdx

@@ -6,11 +6,11 @@ import { Callout } from 'nextra/components'
 # Commits
 
 <Callout type="default">
-  Check type: `COMMITS`
+  Check Typ: `COMMITS`
 </Callout>
 
-This check queries the GitLab API and counts the number of commits in a given time range. 
-The check passes if the number of commits is greater than or equal to the minimum threshold.
+Dieser Check fragt die GitLab-API ab und zählt die Anzahl der Commits in einem bestimmten Zeitraum. 
+Der Check gilt als bestanden, wenn die Anzahl der Commits größer oder gleich dem Mindestschwellenwert ist.
 
 ```yaml filename=".badge-api.yaml" copy
 - type: COMMITS
@@ -20,8 +20,9 @@ The check passes if the number of commits is greater than or equal to the minimu
     min: 5
 ```
 
-### Background
+### Hintergrund
 
-Counting commits within a time range can be part of measuring a project's activity and maintenance. 
-Frequent commits indicate active development, bug fixes, and ongoing improvements. A high commit 
-count can reflect engaged contributors and project evolution, while fewer commits may signal stagnation.
+Das Zählen von Commits innerhalb eines bestimmten Zeitraums kann Teil der Messung der Aktivität und Wartung eines Projekts sein. 
+Häufige Commits deuten auf eine aktive Entwicklung, Fehlerbehebungen und laufende Verbesserungen hin.
+Eine hohe Anzahl von Commits kann ferner auf engagierte Mitwirkende und eine positive Entwicklung des Projekts
\ No newline at end of file
+hinweisen, während eine geringere Anzahl von Commits auf eine Stagnation hindeuten kann.
\ No newline at end of file

src/pages/de/concepts/implemented-checks/elephant-factor.mdx

@@ -3,14 +3,14 @@ SPDX-License-Identifier: MIT */}
 
 import { Callout } from 'nextra/components'
 
-# Elephant Factor
+# Elephant Faktor
 
 <Callout type="default">
-  Check type: `ELEPHANT_FACTOR`
+  Check Typ: `ELEPHANT_FACTOR`
 </Callout>
 
-This check calculates the elephant factor of a project for a given time range.
-The check passes if the elephant factor is greater than or equal to the minimum threshold.
+Dieser Check berechnet den Elefantenfaktor eines Projekts für einen bestimmten Zeitraum.
+Der Check gilt als bestanden, wenn der Elefantenfaktor größer oder gleich dem Mindestschwellenwert ist.
 
 ```yaml filename=".badge-api.yaml" copy
 - type: ELEPHANT_FACTOR
@@ -20,12 +20,14 @@ The check passes if the elephant factor is greater than or equal to the minimum
     min: 2
 ```
 
-### Background
+### Hintergrund
 
-The elephant factor is a measure of the risk resulting from information and capabilities not being shared among organizations.
+Der Elefantenfaktor ist ein Maß für das Risiko, das sich daraus ergibt, dass Informationen und Fähigkeiten
+nicht zwischen Organisationen ausgetauscht werden.
 
-It is similar to the [bus factor](/en/concepts/implemented-checks/bus-factor) but instead of measuring the risk of losing individuals,
-it measures the risk of losing organizations.
+Er ähnelt dem [Bus-Faktor](/de/concepts/implemented-checks/bus-factor), misst jedoch nicht das Risiko,
+Einzelpersonen zu verlieren, sondern das Risiko, Organisationen zu verlieren.
 
-For example, if a project has an elephant factor of 2, it means that the 2 most important organizations are responsible for 50% of the commits
-and after both are gone, the project would be in danger. 
+Wenn ein Projekt etwa einen Elefantenfaktor von 2 hat, bedeutet dies, dass die beiden wichtigsten
+Organisationen für 50 % der Commits verantwortlich sind und das Projekt in Gefahr wäre, wenn beide
\ No newline at end of file
+wegfallen würden. 
\ No newline at end of file

src/pages/de/concepts/implemented-checks/index.mdx

 {/* Copyright 2025 Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH.
 SPDX-License-Identifier: MIT */}
 
-# Overview of Implemented Checks
+# Überblick über implementierte Checks
 
-The following checks are implemented and can be used to generate badges:
+Die folgenden Checks sind implementiert und können zur Erstellung von Badges verwendet werden:
 
-- [`BUS_FACTOR` ↗](/en/concepts/implemented-checks/bus-factor)
-- [`CI_PIPELINE` ↗](/en/concepts/implemented-checks/ci-pipeline)
-- [`COMMITS` ↗](/en/concepts/implemented-checks/commits)
-- [`ELEPHANT_FACTOR` ↗](/en/concepts/implemented-checks/elephant-factor)
-- [`ISSUE_REACTION_TIME` ↗](/en/concepts/implemented-checks/issue-reaction-time)
-- [`PACKAGES` ↗](/en/concepts/implemented-checks/packages)
-- [`PROTECTED_BRANCHES` ↗](/en/concepts/implemented-checks/protected-branches)
-- [`RELEASES` ↗](/en/concepts/implemented-checks/releases)
-- [`SUBSEQUENT_USE` ↗](/en/concepts/implemented-checks/subsequent-use)
+- [`BUS_FACTOR` ↗](/de/concepts/implemented-checks/bus-factor)
+- [`CI_PIPELINE` ↗](/de/concepts/implemented-checks/ci-pipeline)
+- [`COMMITS` ↗](/de/concepts/implemented-checks/commits)
+- [`ELEPHANT_FACTOR` ↗](/de/concepts/implemented-checks/elephant-factor)
+- [`ISSUE_REACTION_TIME` ↗](/de/concepts/implemented-checks/issue-reaction-time)
+- [`PACKAGES` ↗](/de/concepts/implemented-checks/packages)
+- [`PROTECTED_BRANCHES` ↗](/de/concepts/implemented-checks/protected-branches)
+- [`RELEASES` ↗](/de/concepts/implemented-checks/releases)
+- [`SUBSEQUENT_USE` ↗](/de/concepts/implemented-checks/subsequent-use)
\ No newline at end of file

src/pages/de/concepts/implemented-checks/issue-reaction-time.mdx

@@ -3,14 +3,14 @@ SPDX-License-Identifier: MIT */}
 
 import { Callout } from 'nextra/components'
 
-# Issue Reaction Time
+# Reaktionszeit auf Issues
 
 <Callout type="default">
-  Check type: `ISSUE_REACTION_TIME`
+  Check Typ: `ISSUE_REACTION_TIME`
 </Callout>
 
-This check queries the GitLab API for the minimum time it takes for a project member to react to an issue in the given time range.
-The check passes if the number of commits is greater than or equal to the minimum threshold.
+Dieser Check fragt die GitLab-API für den Betrachtungszeitraum nach der Mindestzeit ab, die Projektmitglieder benötigen, um auf ein Issue zu reagieren.
+Der Check gilt als bestanden, wenn die Anzahl der Commits größer oder gleich dem Mindestschwellenwert ist.
 
 ```yaml filename=".badge-api.yaml" copy
 - type: ISSUE_REACTION_TIME
@@ -19,37 +19,40 @@ The check passes if the number of commits is greater than or equal to the minimu
     timeRangeInMonths: 3
     max: 7
 ```
+Die Reaktionszeit auf ein Issue ist die Zeit zwischen der Erstellung eines Issues in einem Projekt und der ersten gültigen Reaktion.
 
-The issue response time is the time between the creation of an issue in a project and the first valid response.
+Ein **Projektmitglied** ist ein Benutzer, der eines der folgenden Kriterien erfüllt:
 
-A **project member** is a user matching one of the following criteria:
+- Ein Mitglied des Projekts (wie von der `members`-API von GitLab zurückgegeben)
+- Ein Benutzer, der mindestens 5 % (magische Zahl) aller Issues und/oder Commits im Projekt erstellt hat
 
-- A member of the project (as returned by the project member API of GitLab)
-- A user who has created at least 5% (magic number) of all issues and/or commits in the project
+**Die Bedingungen gelten gleichzeitig und nicht unabhängig voneinander:**
 
-**The conditions apply simultaneously and not independently of each other:**
+- Wenn ein Projekt keine Issue hat, gilt die Prüfung als bestanden.
+- Von Projektmitgliedern erstellte Issues werden nicht berücksichtigt.
+- Jede (automatische) Aktion im Stream eines Issues, mit Ausnahme von Kommentaren wie „In MR erwähnt“, „markiert“ oder „zugewiesen“ usw., wird als gültige Problemreaktion gewertet.
+- Ein Kommentar gilt als gültige Reaktion, wenn er von einem Projektmitglied abgesetzt wird.
+- Ein Kommentar wird nicht als gültige Reaktion betrachtet, wenn ein Nicht-Projektmitglied auf das Ticket eines Nicht-Projektmitglieds antwortet.
 
-- If a project does not have any issues, the check will pass.
-- Issues created by project members are not considered.
-- Every (automatic) action in the stream of an issue, except comments such as “Mentioned in MR” or “labeled” or “Assigned to” etc. are evaluated as a valid issue reaction.
-- A comment is considered a valid response if the comment is submitted by a project member.
-- A comment is not considered a valid response if a non-project member responds to the ticket of a non-project member.
 
-### Background
+### Hintergrund
 
-Measuring issue reaction time is a valuable metric for assessing a project's maintenance and responsiveness. 
-A quick reaction time indicates that project maintainers are actively monitoring and addressing issues, which 
-reflects good project health and responsiveness.
+Die Messung der Reaktionszeit auf Issues ist eine wertvolle Kennzahl für die Bewertung
+der Wartung und Reaktionsfähigkeit eines Projekts. Eine schnelle Reaktionszeit deutet darauf hin,
+dass die Projektmitglieder Issues aktiv überwachen und beheben, was auf einen guten Projektzustand
+und eine gute Reaktionsfähigkeit hindeutet.
 
-- Indicator of Active Maintenance: Fast issue responses signal that the project is being actively maintained, 
-with attention to bugs, feature requests, or other user concerns. Slow reactions might suggest neglect, 
-which could impact the user experience or drive away contributors.
+- Indikator für aktive Wartung: Schnelle Reaktionen auf Issues signalisieren, dass das Projekt
+  aktiv gewartet wird, wobei Fehler, Anfragen zu Funktionen oder andere Anliegen der Benutzer
+  berücksichtigt werden. Langsame Reaktionen könnten auf Vernachlässigung hindeuten, was sich auf die
+  Benutzererfahrung auswirken oder Mitwirkende abschrecken könnte.
+- Engagement der Community: Schnelle Reaktionen von Projektmitgliedern zeigen auch eine engagierte
+  und unterstützende Community. Sie zeigen, dass Maintainer oder Contributoren zur Verfügung stehen,
+  um zu helfen, und fördern so eine kollaborativere und produktivere Umgebung.
+- Vertrauen der Benutzer: Projekte mit kürzeren Reaktionszeiten auf Issues schaffen bei
+  den Benutzern mehr Vertrauen, da sie wissen, dass ihre Anliegen umgehend bearbeitet werden,
+  was das Projekt für die Übernahme und Mitwirkung attraktiver macht.
 
-- Community Engagement: Quick reactions from project members also demonstrate an engaged and supportive community.
-It shows that maintainers or contributors are available to help, fostering a more collaborative and productive environment.
-
-- User Confidence: Projects with shorter issue reaction times inspire greater confidence in users, as they know 
+Zusammenfassend lässt sich sagen, dass die Untersuchung der Reaktionszeit auf Issues dabei hilft,
+den Grad der aktiven Wartung, des Engagements der Community und der Reaktionsfähigkeit zu messen, die
+für den langfristigen Erfolg und die Nachhaltigkeit eines Projekts von entscheidender Bedeutung sind.
\ No newline at end of file
-their concerns will be addressed promptly, making the project more appealing for adoption and contribution.
-
-In summary, tracking issue reaction time helps gauge the level of active maintenance, community involvement, 
-and responsiveness, which are crucial for the long-term success and sustainability of a project.
\ No newline at end of file

src/pages/de/concepts/implemented-checks/packages.mdx

@@ -3,16 +3,16 @@ SPDX-License-Identifier: MIT */}
 
 import { Callout } from 'nextra/components'
 
-# Packages
+# Pakete
 
 <Callout type="default">
-  Check type: `PACKAGES`
+  Check Typ: `PACKAGES`
 </Callout>
 
-The check passes if the project has a packaging system in place and used it the give times during the given time range.
-It checks the container registry, the package registry and the releases. It expects either a release to 
-have assets or packages inside those two registries.
+Der Check ist erfolgreich, wenn das Projekt über ein Packaging-System verfügt und dies im betrachteten Zeitraum genutzt wurde.
 
+Der Check überprüft die Container-Registry, das Packaging-System und Releases. Es wird erwartet, dass ein Release
+entweder Assets oder Pakete in einer der Registries enthält.
 
 ```yaml filename=".badge-api.yaml" copy
 - type: PACKAGES
@@ -22,12 +22,15 @@ have assets or packages inside those two registries.
     max: 1
 ```
 
-### Background
-
-Packaging is a way to distribute software. It is important to have a packaging system in place to make it 
-easier for users to install and use the software. Packaging systems can help automate the process of 
-installing software, manage dependencies, and ensure that the software is installed correctly.
-Regularly updating these registries signals active maintenance, showing that the project is well-supported
-and evolving. Versioning helps users track updates and access stable releases, while consistent
-packaging enhances compatibility and consistency across environments. Overall, using packaging systems
-improves software accessibility, signals good project health, and fosters reliability and reuse.
+### Hintergrund
+
+Packaging ist ein Mechanismus, um Software zu verteilen und auszuliefern. Es ist wichtig, ein Paketsystem einzusetzen,
+um Benutzern die Installation und Verwendung der Software zu erleichtern. Paketsysteme können dabei helfen, den Prozess der
+Softwareinstallation zu automatisieren, Abhängigkeiten zu verwalten und sicherzustellen, dass die Software
+korrekt installiert wird.
+Regelmäßige Aktualisierungen der Paket-Register signalisieren eine aktive Wartung und zeigen, dass das Projekt
+gut unterstützt wird und sich weiterentwickelt. Die Versionierung hilft den Benutzern, Aktualisierungen zu
+verfolgen und auf stabile Versionen zuzugreifen, während eine konsistente Paketierung die Kompatibilität und
\ No newline at end of file
+Konsistenz in allen Umgebungen verbessert. Insgesamt verbessert die Verwendung von Paketierungssystemen die
+Zugänglichkeit von Software, signalisiert einen guten Projektzustand und fördert die Zuverlässigkeit und
+Wiederverwendung.
\ No newline at end of file