chore: update translations and generated content (#1301)

Co-authored-by: Rany0101 <109510754+Rany0101@users.noreply.github.com>

Author: silverhand-bot

i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/one-time-token.mdx

@@ -9,7 +9,7 @@ import Availability from '@components/Availability';
 <Availability cloud oss={{ major: 1, minor: 27 }} />
 
 Ähnlich wie das Einmalpasswort (OTP) ist ein Einmal-Token eine weitere passwortlose Authentifizierungsmethode, mit der die Identität eines Benutzers verifiziert werden kann.
-Das Token ist nur für einen begrenzten Zeitraum gültig und mit einer E-Mail-Adresse des Endbenutzers verknüpft.
+Das Token ist für einen begrenzten Zeitraum gültig und mit einer E-Mail-Adresse des Endbenutzers verknüpft.
 
 Manchmal möchtest du neue Benutzer zu deiner Anwendung / Organisation einladen, ohne dass sie zuerst ein Konto erstellen müssen.
 Oder du hast dein Passwort vergessen und möchtest dich anmelden / dein Passwort zurücksetzen, indem du deine Identität schnell per E-Mail verifizierst.
@@ -29,10 +29,10 @@ sequenceDiagram
 
   U ->> C: (Optional) Benutzer fordert einen Magic Link von deiner Anwendung an
   C ->> L: Einmal-Token anfordern
-  L -->> C: Gibt Einmal-Token zurück
-  C -->> U: Erstellt einen Magic Link, der das Einmal-Token enthält, und sendet ihn an die E-Mail des Endbenutzers
-  U ->> C: Benutzer klickt auf den Magic Link und wird auf eine Landingpage deiner Anwendung weitergeleitet
-  C ->> L: Extrahiert das Einmal-Token aus dem Magic Link und startet den Authentifizierungsablauf
+  L -->> C: Einmal-Token zurückgeben
+  C -->> U: Magic Link mit Einmal-Token erstellen und an die E-Mail des Endbenutzers senden
+  U ->> C: Benutzer klickt auf Magic Link und wird auf eine Landingpage deiner Anwendung weitergeleitet
+  C ->> L: Extrahiere das Einmal-Token aus dem Magic Link und starte den Authentifizierungsablauf
   L -->> C: Logto überprüft das Einmal-Token und gibt das Ergebnis zurück
   C -->> U: Benutzer ist authentifiziert und erhält Benutzerinformationen zurück
 ```
@@ -52,7 +52,7 @@ Verwende die Logto Management API, um ein Einmal-Token zu erstellen.
 POST /api/one-time-tokens
 ```
 
-Beispiel für den Anfrage-Body:
+Beispiel für den Request-Body:
 
 ```json
 {
@@ -66,11 +66,11 @@ Beispiel für den Anfrage-Body:
 }
 ```
 
-### Schritt 2: Deinen Magic Link erstellen \{#step-2-compose-your-magic-link}
+### Schritt 2: Magic Link erstellen \{#step-2-compose-your-magic-link}
 
 Nachdem du das Einmal-Token erhalten hast, kannst du einen Magic Link erstellen und ihn an die E-Mail-Adresse des Endbenutzers senden.
-Der Magic Link sollte mindestens das Token und die Benutzer-E-Mail als Parameter enthalten und zu einer Landingpage in deiner eigenen Anwendung führen.
-Z. B. `https://yourapp.com/landing-page`.
+Der Magic Link sollte mindestens das Token und die Benutzer-E-Mail als Parameter enthalten und auf eine Landingpage in deiner eigenen Anwendung führen.
+Zum Beispiel: `https://yourapp.com/landing-page`.
 
 Hier ist ein einfaches Beispiel, wie der Magic Link aussehen könnte:
 
@@ -82,7 +82,7 @@ https://yourapp.com/landing-page?token=YHwbXSXxQfL02IoxFqr1hGvkB13uTqcd&email=us
 
 Die Parameternamen im Magic Link können vollständig angepasst werden.
 Du kannst dem Magic Link zusätzliche Informationen hinzufügen, je nach den Anforderungen deiner Anwendung,
-sowie alle URL-Parameter kodieren.
+und alle URL-Parameter kodieren.
 
 :::
 
@@ -120,25 +120,25 @@ const TokenLandingPage = () => {
     }
   }, [searchParams, signIn]);
 
-  return <>Bitte warten...</>;
+  return <>Bitte warten ...</>;
 };
 ```
 
 :::warning
 
 Wenn ein Benutzer bereits angemeldet ist, löscht der Aufruf der Funktion `signIn()` aus dem SDK automatisch alle zwischengespeicherten Tokens (ID-Token, Zugangstoken und Auffrischungstoken) aus dem Client-Speicher,
-was dazu führt, dass der Authentifizierungsstatus des aktuellen Benutzers verloren geht.
+wodurch der Authentifizierungsstatus des aktuellen Benutzers verloren geht.
 
-Daher solltest du einen zusätzlichen Anmeldeparameter `clearTokens: false` angeben, um das Löschen der bestehenden Tokens zu vermeiden.
-Wenn dies angegeben ist, musst du die Tokens auch manuell auf der Callback-Seite der Anmeldung löschen.
+Daher solltest du einen zusätzlichen sign-in Parameter `clearTokens: false` angeben, um das Löschen der bestehenden Tokens zu vermeiden.
+Wenn dies angegeben ist, musst du die Tokens auch manuell auf der sign-in Callback-Seite löschen.
 
 Ignoriere dies, wenn deine Magic Links nicht für authentifizierte Benutzer gedacht sind.
 
 :::
 
-### Schritt 4: (Optional) Zwischengespeicherte Tokens auf der Callback-Seite löschen \{#step-4-clear-cached-tokens-in-sign-in-callback-page}
+### Schritt 4: (Optional) Zwischengespeicherte Tokens auf der sign-in Callback-Seite löschen \{#step-4-clear-cached-tokens-in-sign-in-callback-page}
 
-Wenn du `clearTokens: false` in der sign-in Funktion angibst, musst du die Tokens manuell auf der Callback-Seite der Anmeldung löschen.
+Wenn du `clearTokens: false` in der sign-in Funktion angibst, musst du die Tokens manuell auf der sign-in Callback-Seite löschen.
 
 ```typescript title="Callback.tsx"
 // React-Beispiel
@@ -156,7 +156,7 @@ const Callback = () => {
     // Navigiere zu deiner Startseite
   });
 
-  return <>Bitte warten...</>;
+  return <>Bitte warten ...</>;
 };
 ```
 
@@ -171,9 +171,9 @@ const Callback = () => {
 </summary>
 
 Ja, du kannst den Magic Link verwenden, um neue Benutzer zu deiner Anwendung sowie zu Organisationen einzuladen.
-Wenn du neue Benutzer zu deiner Organisation einladen möchtest, gib einfach die `jitOrganizationIds` im Anfrage-Body an.
+Wenn du neue Benutzer zu deiner Organisation einladen möchtest, gib einfach die `jitOrganizationIds` im Request-Body an.
 
-Der Benutzer wird nach erfolgreicher Verifizierung automatisch den Organisationen beitreten, und die Standardrollen der Organisation werden zugewiesen.
+Der Benutzer wird nach erfolgreicher Verifizierung automatisch den Organisationen beitreten und Standardrollen der Organisation erhalten.
 Sieh dir den Abschnitt "Just-in-time-Bereitstellung" auf der Detailseite deiner Organisation an und konfiguriere die Standardrollen für deine Organisationen.
 
 </details>
@@ -186,7 +186,7 @@ Sieh dir den Abschnitt "Just-in-time-Bereitstellung" auf der Detailseite deiner
 
 </summary>
 
-Der Magic Link Authentifizierungsablauf unterstützt keine Rollenzuweisung an Benutzer. Du kannst jedoch jederzeit die [Webhooks](/developers/webhooks) und die [Management API](/user-management/manage-users#manage-roles-of-users) verwenden, um die Benutzerrollen nach der Registrierung zu aktualisieren.
+Der Magic Link Authentifizierungsablauf unterstützt keine direkte Zuweisung von Rollen an Benutzer. Du kannst jedoch jederzeit die [Webhooks](/developers/webhooks) und die [Management API](/user-management/manage-users#manage-roles-of-users) verwenden, um die Benutzerrollen nach der Registrierung zu aktualisieren.
 
 </details>
 
@@ -218,16 +218,16 @@ Ja, du kannst den Magic Link weiterhin zum Einladen von Benutzern verwenden, auc
 
 <summary>
 
-### Was passiert, wenn ein Benutzer bereits angemeldet ist und dann auf einen anderen Magic Link klickt? \{#what-will-happen-if-a-user-already-signed-in-and-then-click-another-magic-link}
+### Was passiert, wenn ein Benutzer bereits angemeldet ist und dann auf einen weiteren Magic Link klickt? \{#what-will-happen-if-a-user-already-signed-in-and-then-click-another-magic-link}
 
 </summary>
 
 Es gibt mehrere mögliche Szenarien:
 
 1. Der Benutzer ist bereits angemeldet und klickt dann auf einen Magic Link, der mit dem aktuellen Benutzerkonto verknüpft ist. In diesem Fall überprüft Logto trotzdem das Einmal-Token und ordnet den Benutzer bei Bedarf den angegebenen Organisationen zu.
 2. Der Benutzer ist bereits angemeldet und klickt dann auf einen Magic Link, der mit einem anderen Konto verknüpft ist. In diesem Fall fordert Logto den Benutzer auf, entweder als neues Konto fortzufahren oder mit dem aktuellen Konto zur Anwendung zurückzukehren.
-   1. Wenn der Benutzer sich entscheidet, als neues Konto fortzufahren, wechselt Logto nach erfolgreicher Token-Verifizierung zum neuen Konto.
+   1. Wenn der Benutzer sich entscheidet, als neues Konto fortzufahren, wechselt Logto nach erfolgreicher Token-Überprüfung zum neuen Konto.
    2. Wenn der Benutzer beim aktuellen Konto bleiben möchte, überprüft Logto das Token nicht und kehrt mit dem aktuellen Konto zur Anwendung zurück.
-3. Wenn dein Anmelde-Prompt auf "login" gesetzt ist oder "login" enthält, meldet Logto das mit dem Einmal-Token verknüpfte Konto automatisch an, ohne einen Wechsel abzufragen.
+3. Wenn dein sign-in Prompt auf "login" gesetzt ist oder "login" enthält, meldet Logto das mit dem Einmal-Token verknüpfte Konto automatisch an, ohne einen Wechsel abzufragen. Dies liegt daran, dass der "login"-Prompt eine explizite Authentifizierungsabsicht signalisiert, die Vorrang vor der aktuellen Sitzung hat.
 
 </details>

i18n/de/docusaurus-plugin-content-docs/current/end-user-flows/organization-experience/invite-organization-members.mdx

@@ -23,7 +23,7 @@ sequenceDiagram
   C ->> C: Einladungslink mit Einladung-ID erstellen
   C ->> L: Anfordern des Versands der Einladungsemail mit Einladungslink
   L -->> U: Einladungsemail mit Einladungslink senden
-  U ->> C: Klick auf Einladungslink und Weiterleitung zu deiner Landingpage,<br /> Einladung annehmen oder ablehnen
+  U ->> C: Einladungslink anklicken und zu deiner Landingpage navigieren,<br /> Einladung annehmen oder ablehnen
   C ->> L: Einladungsstatus mit Management API aktualisieren
 ```
 
@@ -33,7 +33,7 @@ Bevor Mitglieder eingeladen werden, erstelle Organisationsrollen. Siehe die [Org
 
 In dieser Anleitung erstellen wir zwei typische Organisationsrollen: `admin` und `member`.
 
-Die `admin`-Rolle hat vollen Zugriff auf alle Ressourcen der Organisation, während die `member`-Rolle eingeschränkten Zugriff hat. Zum Beispiel:
+Die `admin`-Rolle hat vollen Zugriff auf alle Ressourcen in der Organisation, während die `member`-Rolle eingeschränkten Zugriff hat. Zum Beispiel:
 
 - `admin`-Rolle:
   - `read:data` – Lesezugriff auf alle Organisationsdatenressourcen.
@@ -57,21 +57,15 @@ Eine Beispiel-E-Mail-Vorlage für den Verwendungstyp `OrganizationInvitation` is
 
 ```json
 {
-  "subject": "Willkommen in meiner Organisation",
-  "content": "<p>Tritt {{organization.name}} über diesen <a href=\"{{link}}\" target=\"_blank\">Link</a> bei.</p>",
+  "subject": "Du wurdest eingeladen, {{organization.name}} beizutreten",
+  "content": "<p>Hallo,</p><p>{{inviter.name}} ({{inviter.primaryEmail}}) hat dich eingeladen, <strong>{{organization.name}}</strong> beizutreten.</p><p>Klicke auf diesen <a href=\"{{link}}\" target=\"_blank\">Link</a>, um die Einladung anzunehmen und loszulegen.</p><p>Falls du diese Einladung nicht erwartet hast, kannst du diese E-Mail einfach ignorieren.</p>",
   "usageType": "OrganizationInvitation",
   "type": "text/html"
 }
 ```
 
 Der Platzhalter `{{link}}` im E-Mail-Inhalt wird beim Versand der E-Mail durch den tatsächlichen Einladungslink ersetzt.
 
-:::note
-
-Der integrierte „Logto-E-Mail-Service“ von Logto Cloud unterstützt derzeit nicht den Verwendungstyp `OrganizationInvitation`. Konfiguriere stattdessen deinen eigenen E-Mail-Connector (z. B. SendGrid) und richte die `OrganizationInvitation`-Vorlage ein.
-
-:::
-
 ## Einladungen mit Logto Management API verwalten \{#handle-invitations-with-logto-management-api}
 
 :::note

i18n/de/docusaurus-plugin-content-docs/current/security/blocklist.mdx

@@ -0,0 +1,42 @@
+---
+slug: /security/blocklist
+sidebar_label: Blocklist
+sidebar_position: 3
+---
+
+# Blocklist
+
+## E-Mail-Blocklist \{#email-blocklist}
+
+Die E-Mail-Blocklist-Richtlinie ermöglicht die Anpassung der Einstellungen zur E-Mail-Blocklist, um Missbrauch bei der Kontoerstellung zu verhindern. Sie überwacht E-Mail-Adressen, die für die Registrierung und Kontoeinstellungen verwendet werden. Wenn ein Benutzer versucht, sich zu registrieren oder eine E-Mail-Adresse zu verknüpfen, die gegen eine Blocklist-Regel verstößt, wird die Anfrage vom System abgelehnt. Dies hilft, Spam-Konten zu reduzieren und die allgemeine Kontosicherheit zu erhöhen.
+
+Besuche <CloudLink to="/security/blocklist">Konsole > Sicherheit > Blocklist</CloudLink>, um die Einstellungen der E-Mail-Blocklist zu konfigurieren.
+
+### Wegwerf-E-Mail-Adressen blockieren \{#block-disposable-email-addresses}
+
+Dies ist eine **nur-Cloud**-Funktion. Nach der Aktivierung überprüft das System automatisch die Domain der angegebenen E-Mail-Adresse anhand einer Liste bekannter Wegwerf-E-Mail-Domains. Wenn die Domain in der Liste gefunden wird, wird die Anfrage abgelehnt. Die Liste der Wegwerf-E-Mail-Domains wird regelmäßig aktualisiert, um ihre Wirksamkeit sicherzustellen.
+
+### E-Mail-Subaddressing blockieren \{#block-email-subaddressing}
+
+E-Mail-Subaddressing ermöglicht es Benutzern, Varianten ihrer E-Mail-Adressen zu erstellen, indem sie ein Pluszeichen (+) gefolgt von zusätzlichen Zeichen hinzufügen (z. B. user+tag@example.com). Diese Funktion kann von böswilligen Benutzern ausgenutzt werden, um Blocklist-Beschränkungen zu umgehen. Durch das Aktivieren der Funktion zum Blockieren von E-Mail-Subaddressing lehnt das System alle Registrierungs- oder Konto-Verknüpfungsversuche ab, die Subaddressing-Formate verwenden.
+
+### Benutzerdefinierte E-Mail-Blocklist \{#custom-email-blocklist}
+
+Du kannst eine benutzerdefinierte E-Mail-Blocklist erstellen, indem du eine Liste von E-Mail-Adressen oder Domains angibst, die blockiert werden sollen. Das System lehnt alle Registrierungs- oder Konto-Verknüpfungsversuche ab, die mit diesen Einträgen übereinstimmen. Die Blocklist unterstützt sowohl vollständige E-Mail-Adressen als auch Domain-Übereinstimmungen.
+
+Wenn du beispielsweise `@example.com` zur Blocklist hinzufügst, werden alle E-Mail-Adressen mit dieser Domain blockiert. Ebenso wird durch das Hinzufügen von `foo@example.com` genau diese E-Mail-Adresse blockiert.
+
+:::note
+
+Wegwerf-E-Mails, Subaddressing und benutzerdefinierte E-Mails sind während der [Neuregistrierung von Benutzern](/end-user-flows/sign-up-and-sign-in/sign-up), [Verknüpfung von E-Mails während der sozialen Anmeldung](/end-user-flows/sign-up-and-sign-in/social-sign-in#collect-sign-up-identifiers) und beim Aktualisieren von E-Mails über die [Account API](/end-user-flows/account-settings/by-account-api#update-or-link-new-email) eingeschränkt. Bestehende Benutzer mit diesen E-Mail-Adressen können sich weiterhin anmelden.
+
+- Admins können "Beschränkungen umgehen", indem sie Benutzer manuell in <CloudLink to="/users">Konsole > Benutzerverwaltung</CloudLink> hinzufügen oder über die [Management API](https://openapi.logto.io/operation/operation-createuser). Zum Beispiel: Erstelle einen Benutzer mit einer Subaddress-E-Mail, wenn Subaddressing blockiert ist.
+- Bestehende Konten blockieren, indem du sie in <CloudLink to="/users">Konsole > Benutzerverwaltung</CloudLink> löschst oder sperrst.
+
+:::
+
+## Verwandte Ressourcen \{#related-resources}
+
+<Url href="https://blog.logto.io/disposable-email">
+  Was ist eine Wegwerf-E-Mail? Wie gehst du in deiner App damit um?
+</Url>

i18n/de/docusaurus-plugin-content-docs/current/security/identifier-lockout.mdx

@@ -6,21 +6,21 @@ sidebar_position: 4
 
 # Identifier Lockout
 
-## Sentinel \{#sentinel}
+Die Identifier Lockout-Richtlinie ermöglicht es dir, eigene Sentinel-Richtlinieneinstellungen anzupassen, um dich vor Brute-Force-Zugriffen zu schützen. Diese Richtlinie funktioniert, indem sie Authentifizierungsversuche für jeden Identifikator (wie Benutzernamen oder E-Mail-Adressen) überwacht und Einschränkungen umsetzt, wenn verdächtige Aktivitäten erkannt werden. Überschreitet ein Benutzer die erlaubte Anzahl fehlgeschlagener Authentifizierungsversuche, wird der Identifikator vorübergehend gesperrt, sodass für eine festgelegte Dauer keine weiteren Authentifizierungsversuche möglich sind. Dies hilft, Brute-Force-Angriffe zu verhindern und die allgemeine Kontosicherheit zu erhöhen.
 
-Die Identifier Lockout-Policy ermöglicht es dir, deine eigene Sentinel-Policy anzupassen, um dich vor Missbrauch bei der Kontoanmeldung / -registrierung zu schützen. Diese Policy funktioniert, indem sie Authentifizierungsversuche für jeden Identifikator (wie Benutzernamen oder E-Mail-Adressen) überwacht und Einschränkungen umsetzt, wenn verdächtige Aktivitäten erkannt werden. Überschreitet ein Benutzer die erlaubte Anzahl fehlgeschlagener Authentifizierungsversuche, wird der Identifikator vorübergehend gesperrt, sodass für eine festgelegte Dauer keine weiteren Authentifizierungsversuche möglich sind. Dies hilft, Brute-Force-Angriffe zu verhindern und die allgemeine Kontosicherheit zu erhöhen.
-
-Besuche die <CloudLink to="/security/general">Konsole > Sicherheit > Allgemein</CloudLink>, um die Einstellungen für den Identifier Lockout zu konfigurieren.
-
-## Anwendung der Policy \{#applicaiton-of-the-policy}
-
-Die Identifier Lockout (Sentinel) Policy wird in den folgenden Benutzerinteraktionsflüssen angewendet:
+## Anwendung der Richtlinie \{#application-of-the-policy}
 
 - **Identifier-Anmeldung**: Passwort und Bestätigungscode
 - **Identifier-Registrierung**: E-Mail- / Telefon-Bestätigungscode
 - **Passwort zurücksetzen**: E-Mail- / Telefon-Bestätigungscode
 
-## Policy-Einstellungen \{#policy-settings}
+## Richtlinieneinstellungen \{#policy-settings}
+
+Standardmäßig wird ein Identifikator nach 100 fehlgeschlagenen Authentifizierungsversuchen für 60 Minuten gesperrt.
+
+Um die Richtlinieneinstellungen anzupassen oder verifizierte Benutzer manuell zu entsperren, gehe zu <CloudLink to="/security/general">Konsole > Sicherheit > Allgemein</CloudLink> und aktiviere „Lockout-Erlebnis anpassen“.
+
+Konfiguriere die folgenden Einstellungen:
 
 1. **Maximale fehlgeschlagene Versuche**:
 
@@ -29,8 +29,20 @@ Die Identifier Lockout (Sentinel) Policy wird in den folgenden Benutzerinterakti
 
 2. **Sperrdauer (Minuten)**:
 
-   - Blockiere alle Authentifizierungsversuche für den jeweiligen Identifikator für einen festgelegten Zeitraum, nachdem die maximale Anzahl fehlgeschlagener Versuche überschritten wurde.
+   - Blockiere alle Authentifizierungsversuche für den angegebenen Identifikator für einen festgelegten Zeitraum, nachdem die maximale Anzahl fehlgeschlagener Versuche überschritten wurde.
    - **Standardwert**: 60 Minuten
 
-3. **Manuelle Entsperrung**:
-   - Administratoren können Benutzer manuell entsperren, indem sie eine Liste von Identifikatoren angeben, die aus der Sperre entlassen werden sollen. Die angegebenen Identifikatoren müssen exakt mit den gesperrten Identifikatoren übereinstimmen.
+3. **Manuelles Entsperren**
+
+   - Administratoren können Benutzer manuell entsperren, indem sie eine Liste von Identifikatoren angeben, die aus der Sperre entfernt werden sollen. Die angegebenen Identifikatoren müssen exakt mit den gesperrten Identifikatoren übereinstimmen.
+
+## Lockout Webhook \{#lockout-webhook}
+
+Wenn ein Identifikator aufgrund zu vieler fehlgeschlagener Versuche gesperrt wird, löst Logto das `Identifier.Lockout` Webhook-Ereignis aus, wodurch automatisierte Reaktionen auf verdächtige Kontoaktivitäten ermöglicht werden.
+
+**Häufige Anwendungsfälle:**
+
+- Sende Sicherheitswarnungen an dein Team zur sofortigen Überprüfung
+- Benachrichtige Benutzer per SMS oder Push-Benachrichtigung über die Sperre und stelle Wiederherstellungsanweisungen bereit
+
+Navigiere zu <CloudLink to="/webhooks">Konsole > Webhooks</CloudLink>, um deinen Webhook zu konfigurieren. Für detaillierte Informationen zur Ereignisstruktur und Konfiguration siehe [Webhooks](/developers/webhooks).