refactor: update i18n translations

i18n/de/docusaurus-plugin-content-docs/current/authorization/api-resources/protect-your-api.mdx

@@ -4,7 +4,7 @@ sidebar_position: 1
 
 # Schütze deine API
 
-Wenn du keine flexiblen, feingranularen Zugangskontrollrichtlinien benötigst, kannst du einfach deine API direkt schützen. Wir führen dich durch ein Sequenzdiagramm und die notwendigen Schritte, um die Zugangskontrolle in deine App zu integrieren.
+Wenn du keine flexiblen, feingranularen Zugangskontrollrichtlinien benötigst, kannst du einfach deine API direkt schützen. Wir führen dich durch ein Sequenzdiagramm und die notwendigen Schritte, um zu zeigen, wie du Zugangskontrolle in deine App integrieren kannst.
 
 ```mermaid
 sequenceDiagram
@@ -21,7 +21,7 @@ sequenceDiagram
     Client->>Logto: POST /oidc/token
     Note right of Client: mit authorization_code<br/>resource=https://resource-server.com/api<br/>und optional scope=read write
     Logto-->>Client: Gibt JWT Zugangstoken zurück
-    Note left of Logto: Token enthält:<br/>- Zielgruppe eingeschränkt auf Ressource<br/>- Gewährte Berechtigungen (falls vorhanden)
+    Note left of Logto: Token enthält:<br/>- Zielgruppe auf Ressource beschränkt<br/>- Gewährte Berechtigungen (falls vorhanden)
 
     Note over Client,API: 3. API-Anfrage
     Client->>API: Anfrage mit Bearer-Token
@@ -44,7 +44,7 @@ Du solltest diese durch deine tatsächlichen Endpunkte ersetzen, wenn du impleme
 
 ## Authentifizierungsanfrage \{#authentication-request}
 
-Stelle eine Liste von Ressourcenindikator-Parametern in einer [Authentifizierungsanfrage](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) bereit. Dies wird alle geschützten Ressourcen anzeigen, die der Benutzer möglicherweise anfordert.
+Gib eine Liste von Ressourcenindikator-Parametern in einer [Authentifizierungsanfrage](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) an. Dies wird alle geschützten Ressourcen anzeigen, die der Benutzer möglicherweise anfordert.
 
 ```bash
 GET https://tenant-id.logto.app/oidc/auth?response_type=code
@@ -69,7 +69,7 @@ const config: LogtoConfig = {
 
 ## Token-Anfrage \{#token-request}
 
-Wenn der Ressourcenparameter bei einer [Token-Anfrage](https://openid.net/specs/openid-connect-core-1_0.html#TokenRequest) zusammen mit dem oben gewährten `authorization_code` vorhanden ist, wird die Ziel-API-Ressourcenzielgruppe des Zugangstokens spezifiziert.
+Wenn der Ressourcenparameter bei einer [Token-Anfrage](https://openid.net/specs/openid-connect-core-1_0.html#TokenRequest) zusammen mit dem oben gewährten `authorization_code` vorhanden ist, wird die Ziel-API-Ressourcen-Zielgruppe des Zugangstokens spezifiziert.
 
 ```bash
 POST https://tenant-id.logto.app/oidc/token HTTP/1.1
@@ -78,7 +78,7 @@ Content-Type: application/x-www-form-urlencoded
 grant_type=authorization_code&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ&resource=https%3A%2F%2Fresource-server.com%2Fapi
 ```
 
-Ein verschlüsseltes Zugangstoken mit der Zielgruppe, die auf diese angeforderte Ressource beschränkt ist, wird von Logto gewährt. Das Token enthält alle Daten, die du benötigst, um den Autorisierungsstatus der Anfrage darzustellen, z. B. die Identität und Rolle des anfragenden Benutzers, die Zielgruppe und die Ablaufzeit des Tokens.
+Ein verschlüsseltes Zugangstoken mit der auf diese angeforderte Ressource beschränkten Zielgruppe wird von Logto gewährt. Das Token enthält alle Daten, die du benötigst, um den Autorisierungsstatus der Anfrage darzustellen, z. B. die Identität und Rolle des anfragenden Benutzers, die Zielgruppe und die Ablaufzeit des Tokens.
 
 Beispielcode des Logto SDK:
 
@@ -107,19 +107,19 @@ Authorization: Bearer eyJhbGciOiJIUz...
 
 Logto folgt dem standardmäßigen tokenbasierten Autorisierungsprotokoll, um deine API-Ressourcen zu schützen. Um mehr über OAuth 2.0 zu erfahren, siehe bitte das [offizielle Dokument](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1) von OAuth 2.0.
 
-## Autorisierungstoken für API-Anfragen validieren \{#validate-authorization-tokens-for-api-requests}
+## Autorisierungstokens für API-Anfragen validieren \{#validate-authorization-tokens-for-api-requests}
 
-Logto stellt ein standardmäßiges [JWT](https://datatracker.ietf.org/doc/html/rfc7519)-Format Autorisierungstoken für jede autorisierte API-Anfrage aus. Das Token ist verschlüsselt und als [JWS](https://datatracker.ietf.org/doc/html/rfc7515)-Token signiert.
+Logto gibt ein standardmäßiges [JWT](https://datatracker.ietf.org/doc/html/rfc7519) Format Autorisierungstoken für jede autorisierte API-Anfrage aus. Das Token ist verschlüsselt und als [JWS](https://datatracker.ietf.org/doc/html/rfc7515) Token signiert.
 
-#### Verständnis des JWS-Tokens \{#understanding-jws-token}
+#### JWS-Token verstehen \{#understanding-jws-token}
 
-Ein kodiertes [JWS](https://datatracker.ietf.org/doc/html/rfc7515)-Token wird aus drei Teilen konstruiert:
+Ein kodiertes [JWS](https://datatracker.ietf.org/doc/html/rfc7515) Token wird aus drei Teilen konstruiert:
 
-- JOSE Header: Deklariert den Code-Typ und den Kodierungsalgorithmus
-- JWS Payload: Beinhaltet alle Ansprüche des Tokens
-- JWS Signature: Signatur, signiert mit [JWK](https://datatracker.ietf.org/doc/html/rfc7517)
+- JOSE Header: Deklariert den Code-Typ und das Kodierungsalgorithmus
+- JWS Payload: Enthält alle Ansprüche des Tokens
+- JWS Signatur: Signatur, die mit [JWK](https://datatracker.ietf.org/doc/html/rfc7517) signiert ist
 
-Ein Standardschema des von Logto ausgestellten JWS-Payloads: (Ansprüche können je nach deiner benutzerdefinierten OIDC-Konfiguration variieren)
+Ein Standardschema des von Logto ausgegebenen JWS Payload: (Ansprüche können variieren, basierend auf deiner benutzerdefinierten OIDC-Konfiguration)
 
 | Schlüssel | Beschreibung                                  |
 | --------- | --------------------------------------------- |
@@ -134,7 +134,7 @@ Ein Standardschema des von Logto ausgestellten JWS-Payloads: (Ansprüche können
 
 :::note
 
-Für die Entwicklung, um ein JWT-Token visuell zu inspizieren, könntest du ein [JWT Decoder Tool](https://www.jstoolset.com/jwt) besuchen, um die empfangenen Tokens zu dekodieren und zu überprüfen. Sei vorsichtig oder verwende niemals Tokens aus einer Produktionsumgebung. Da dies ein von Dritten bereitgestellter öffentlicher Online-Dienst ist, könnte dein Token exponiert werden.
+Für die Entwicklung, um ein JWT-Token visuell zu inspizieren, könntest du ein [JWT Decoder Tool](https://www.jstoolset.com/jwt) besuchen, um die erhaltenen Tokens zu dekodieren und zu überprüfen. Sei vorsichtig oder verwende niemals Tokens aus einer Produktionsumgebung. Da dies ein von Dritten bereitgestellter öffentlicher Online-Dienst ist, könnte dein Token exponiert werden.
 
 :::
 
@@ -155,4 +155,18 @@ Es gibt verschiedene Open-Source-Bibliotheken und -Pakete, die dir helfen könne
 
 ## Referenz \{#reference}
 
-Logto verwendet das codebasierte OAuth 2.0 Autorisierungsprotokoll, um deine API-Anfrage sicher zu machen. Wenn du an der dahinterstehenden Strategie interessiert bist, sieh dir die [Spezifikation](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1) von OAuth 2.0 für weitere Details an.
+Logto verwendet das codebasierte OAuth 2.0 Autorisierungsprotokoll, um deine API-Anfrage sicher zu machen. Wenn du an der dahinterstehenden Strategie interessiert bist, siehe die [Spezifikation](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1) von OAuth 2.0 für weitere Details.
+
+## FAQs \{#faqs}
+
+<details>
+
+<summary>
+
+### Wie kann man die Interaktion zwischen Client-Seite, Logto und Server-Seite testen, ohne den Client zu bauen? \{#how-to-test-the-client-side-logto-and-server-side-interaction-without-building-the-client}
+
+</summary>
+
+Du kannst diesen Prozess automatisieren, ohne den Client bauen zu müssen. Eine Option ist die Verwendung eines Personal Access Token (PAT). Ein PAT ermöglicht es dir, die Client-seitige Authentifizierung zu simulieren, indem es einen bestimmten Benutzer mit unterschiedlichen Rollen und Berechtigungen darstellt. Dies kann verwendet werden, um deine serverseitige Logik zu testen, wie z. B. die Validierung von Zugangstoken oder JWT, ohne dass ein vollständig gebauter Client erforderlich ist. Um loszulegen, siehe den [Personal Access Token](/user-management/personal-access-token).
+
+</details>

i18n/de/docusaurus-plugin-content-docs/current/authorization/role-based-access-control/configure-roles.mdx

@@ -4,14 +4,14 @@ sidebar_position: 2
 
 # Rollen konfigurieren
 
-## Konfiguration über die Logto-Konsole \{#configure-via-logto-console}
+## Über Logto-Konsole konfigurieren \{#configure-via-logto-console}
 
 ### Rollentyp definieren \{#define-role-type}
 
-In Logto gibt es zwei Arten von Rollen, basierend auf der Entität, auf die sie angewendet werden können: "Benutzerrolle" oder "Maschine-zu-Maschine-App-Rolle".
+In Logto gibt es zwei Rollentypen, basierend auf der Entität, auf die sie angewendet werden können: "Benutzerrolle" oder "Maschine-zu-Maschine-App-Rolle".
 
-1. **Benutzerrolle**: Eine Benutzerrolle ist eine Art von Rolle, die nur Benutzern zugewiesen werden kann. Sie kann Berechtigungen aus deinen eigenen API-Ressourcen enthalten.
-2. **Maschine-zu-Maschine-Rolle**: Eine M2M-Rolle ist eine Art von Rolle, die nur Maschine-zu-Maschine-Apps zugewiesen werden kann. Sie kann sowohl deine eigenen API-Berechtigungen als auch Logto Management API-Berechtigungen enthalten. Die Maschine-zu-Maschine-Rolle wird normalerweise verwendet, um deine Maschine-zu-Maschine-Authentifizierung zu schützen, wie z. B. den Zugriff auf die Logto Management API oder deine eigenen API-Ressourcen.
+1. **Benutzerrolle**: Eine Benutzerrolle ist ein Rollentyp, der nur Benutzern zugewiesen werden kann. Sie kann Berechtigungen aus deinen eigenen API-Ressourcen enthalten.
+2. **Maschine-zu-Maschine-Rolle**: Eine M2M-Rolle ist ein Rollentyp, der nur Maschine-zu-Maschine-Apps zugewiesen werden kann. Sie kann sowohl deine eigenen API-Berechtigungen als auch Logto Management API-Berechtigungen enthalten. Die Maschine-zu-Maschine-Rolle wird normalerweise verwendet, um deine Maschine-zu-Maschine-Authentifizierung zu schützen, wie z. B. den Zugriff auf die Logto Management API oder deine eigenen API-Ressourcen.
 
 Nach der Erstellung einer Rolle kannst du ihren Typ nicht mehr ändern.
 
@@ -42,7 +42,7 @@ Das Löschen der Rolle entfernt alle damit verknüpften Berechtigungen für die
 
 Abhängig vom gewählten Rollentyp kannst du Benutzer oder Maschine-zu-Maschine-Anwendungen auf der Rollendetailseite zuweisen oder entfernen.
 
-Klicke auf die Registerkarte "Benutzer" oder "Maschine-zu-Maschine-Apps", um die der Rolle zugewiesenen Benutzer oder Apps anzuzeigen. Um Benutzer oder Apps weiterhin zur Rolle hinzuzufügen, klicke auf die Schaltfläche "Benutzer zuweisen" oder "Anwendungen zuweisen" in der oberen rechten Ecke.
+Klicke auf die Registerkarte "Benutzer" oder "Maschine-zu-Maschine-Apps", um die der Rolle zugewiesenen Benutzer oder Apps anzuzeigen. Um weiterhin Benutzer oder Apps zur Rolle hinzuzufügen, klicke auf die Schaltfläche "Benutzer zuweisen" oder "Anwendungen zuweisen" in der oberen rechten Ecke.
 
 ### Berechtigungen in Rollen verwalten \{#manage-permissions-in-roles}
 
@@ -56,11 +56,11 @@ Wenn eine Berechtigung gelöscht wird, verlieren Benutzer oder Apps mit dieser R
 
 ### Rollen verwalten, die einer Maschine-zu-Maschine-App oder einem Benutzer zugewiesen sind \{#manage-roles-assigned-to-a-machine-to-machine-app-or-user}
 
-Auf der Detailseite eines Benutzers oder einer App findest du eine Registerkarte "Rollen". Klicke auf die Registerkarte, um die der Benutzer oder Maschine-zu-Maschine-Apps zugewiesenen Rollen anzuzeigen und zu verwalten.
+Du findest eine Registerkarte "Rollen" auf der Detailseite eines Benutzers oder einer App. Klicke auf die Registerkarte, um die der Benutzer oder Maschine-zu-Maschine-Apps zugewiesenen Rollen anzuzeigen und zu verwalten.
 
-Wenn die Konfiguration in Logto Cloud für dich nicht ausreicht, kannst du die Management API nutzen, um diese Verwaltungsaufgabe programmgesteuert durchzuführen.
+Wenn die Konfiguration in Logto Cloud für dich nicht ausreicht, kannst du die Management API nutzen, um diese Verwaltungsaufgabe programmatisch durchzuführen.
 
-## Konfiguration über die Logto Management API \{#configure-via-logto-management-api}
+## Über Logto Management API konfigurieren \{#configure-via-logto-management-api}
 
 Verwalte mit der Logto Management API. Führe einen Aufruf zum entsprechenden Endpunkt aus. Sieh dir diese [Referenz](https://openapi.logto.io/operation/operation-listresourcescopes) an.
 
@@ -81,6 +81,6 @@ Verwalte mit der Logto Management API. Führe einen Aufruf zum entsprechenden En
 | POST    | [/api/roles/\{Id\}/scopes](https://openapi.logto.io/operation/operation-createrolescope)                               | Eine Liste von API-Ressourcen-Berechtigungen (Scopes) mit einer Rolle verknüpfen. Die ursprünglich verknüpften Scopes bleiben erhalten. |
 | DELETE  | [/api/roles/\{Id\}/scopes/\{scopeId\}](https://openapi.logto.io/operation/operation-deleterolescope)                   | Eine API-Ressourcen-Berechtigung (Scope) von einer Rolle mit der angegebenen ID entknüpfen.                                             |
 
-# Standardrollen
+## Standardrollen \{#default-roles}
 
-Standardrollen sind die automatisch zugewiesenen Rollen, wenn die Benutzer erstellt werden, entweder für die Selbstregistrierung oder erstellt über die Management API. Du kannst diesen Schalter aktivieren, indem du zu Rollen-Rolledetail-Allgemein gehst.
+Standardrollen sind die automatisch zugewiesenen Rollen, wenn die Benutzer erstellt werden, entweder für die Selbstregistrierung oder durch die Management API. Du kannst diesen Schalter aktivieren, indem du zur Registerkarte „Allgemein“ auf der Detailseite unter <CloudLink to="/roles">Konsole > Rollen</CloudLink> gehst.