chore: update translations and generated content (#1320)

* chore: update translations and generated content

* fix: lint errors

---------

Co-authored-by: gao-sun <14722250+gao-sun@users.noreply.github.com>
Co-authored-by: Charles Zhao <charleszhao@silverhand.io>

Author: 3 people

docs/authorization/fragments/_handle-user-permission-change.mdx

@@ -8,7 +8,7 @@ Even if a user gains new permissions, the token issued later can only contain a
 To access newly granted scopes that were not part of the initial request, the client must run a new authorization flow.
 :::
 
-#### Downscoped permissions
+#### Downscoped permissions \{#downscoped-permissions}
 
 When a user loses permissions:
 
@@ -18,13 +18,13 @@ When a user loses permissions:
 
 If you need faster reactions, implement your own signal that tells clients to refresh their tokens.
 
-#### Enlarged permissions
+#### Enlarged permissions \{#enlarged-permissions}
 
 {props.type === "global" && <p>For global API resources, when a user gains permissions, enlarged permissions will NOT show up through refresh. The client must perform a new OAuth authorization flow to obtain a token that includes the new scopes. This can happen silently if the user has an active Logto session.</p>}
 
 {props.type === "organization" && <p>For organization tokens, when a user gains permissions, enlarged permissions will show up on the next issuance (refresh or token request). A new token is still required, but no full re-auth is needed unless the new scopes exceed the original request set.</p>}
 
-#### Recommendations
+#### Recommendations \{#recommendations}
 
 - Validate scopes in your API on every call.
 - Keep token expiration short.

i18n/de/docusaurus-plugin-content-docs/current/authorization/fragments/_handle-user-permission-change.mdx

@@ -0,0 +1,31 @@
+### Optional: Benutzerberechtigungsänderungen behandeln \{#optional-handle-user-permission-change}
+
+Benutzerberechtigungen können sich jederzeit ändern. Da Logto JWTs für rollenbasierte Zugangskontrolle (RBAC) ausstellt, erscheinen Berechtigungsänderungen nur in neu ausgestellten Tokens und ändern niemals bestehende JWTs.
+
+:::info Berechtigungs-Subset-Regel
+Ein Zugangstoken (Access token) kann nur Berechtigungen (Scopes) enthalten, die im ursprünglichen OAuth-Autorisierungsablauf angefordert wurden.
+Selbst wenn ein Benutzer neue Berechtigungen erhält, kann das später ausgestellte Token nur eine Teilmenge der ursprünglich angeforderten Berechtigungen enthalten.
+Um auf neu gewährte Berechtigungen zuzugreifen, die nicht Teil der ursprünglichen Anfrage waren, muss der Client einen neuen Autorisierungsablauf durchführen.
+:::
+
+#### Reduzierte Berechtigungen \{#downscoped-permissions}
+
+Wenn ein Benutzer Berechtigungen verliert:
+
+- Neu ausgestellte Tokens spiegeln die reduzierten Berechtigungen sofort wider.
+- Bestehende JWTs behalten die alten Berechtigungen, bis sie ablaufen.
+- Deine API sollte immer die Berechtigungen validieren und sich auf kurze Token-Laufzeiten verlassen.
+
+Wenn du schnellere Reaktionen benötigst, implementiere ein eigenes Signal, das den Clients mitteilt, ihre Tokens zu aktualisieren.
+
+#### Erweiterte Berechtigungen \{#enlarged-permissions}
+
+{props.type === "global" && <p>Für globale API-Ressourcen werden erweiterte Berechtigungen, wenn ein Benutzer neue Berechtigungen erhält, NICHT durch Aktualisierung (Refresh) sichtbar. Der Client muss einen neuen OAuth-Autorisierungsablauf durchführen, um ein Token zu erhalten, das die neuen Berechtigungen enthält. Dies kann still erfolgen, wenn der Benutzer eine aktive Logto-Sitzung hat.</p>}
+
+{props.type === "organization" && <p>Für Organisationstokens werden erweiterte Berechtigungen, wenn ein Benutzer neue Berechtigungen erhält, bei der nächsten Ausstellung (Refresh oder Token-Anfrage) sichtbar. Ein neues Token ist weiterhin erforderlich, aber eine vollständige erneute Authentifizierung ist nicht nötig, es sei denn, die neuen Berechtigungen überschreiten die ursprünglich angeforderte Menge.</p>}
+
+#### Empfehlungen \{#recommendations}
+
+- Validiere die Berechtigungen bei jedem API-Aufruf.
+- Halte die Token-Gültigkeit kurz.
+- Füge optionale Benachrichtigungen hinzu, wenn du eine sofortige Verbreitung von Berechtigungsänderungen benötigst.

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

@@ -6,6 +6,7 @@ import illustration from '@site/docs/authorization/assets/rbac-global-api-resour
 import AuthorizationRequestExample from '@site/docs/authorization/fragments/AuthorizationRequestExample';
 import ClientCredentialsRequestExample from '@site/docs/authorization/fragments/ClientCredentialsRequestExample';
 import TokenRequestExample from '@site/docs/authorization/fragments/TokenRequestExample';
+import HandleUserPermissionChange from '@site/docs/authorization/fragments/_handle-user-permission-change.mdx';
 import TabItem from '@theme/TabItem';
 import Tabs from '@theme/Tabs';
 
@@ -30,8 +31,8 @@ Logto ermöglicht es dir, diese APIs mit OAuth 2.1 in Kombination mit flexibler,
 ## So funktioniert es in Logto \{#how-it-works-in-logto}
 
 - **API-Ressourcen und Berechtigungen werden global registriert:** Jede API, die du schützen möchtest, wird mit einem eindeutigen Ressourcenindikator (URI) und einem Satz von Berechtigungen (Scopes) definiert, die den Zugriff steuern.
-- **Der Zugriff wird durch globale Rollen gesteuert:** Du kannst Berechtigungen Rollen zuweisen, die dann Benutzern oder Clients zugeordnet werden.
-- **Getrennt von organisationsbezogenen Berechtigungen:** Globale API-Ressourcen haben keinen Organisationskontext. Sie können jedoch zusammen mit Organisationsrollen verwendet werden, um bei Bedarf eine zusätzliche Kontextebene bereitzustellen. Um organisationsbezogene APIs zu schützen, siehe [Organisationsbezogene API-Ressourcen schützen](/authorization/organization-level-api-resources).
+- **Der Zugriff wird durch globale Rollen gesteuert:** Du kannst Berechtigungen Rollen zuweisen, die dann Benutzern oder Clients zugewiesen werden.
+- **Getrennt von organisationsbezogenen Berechtigungen:** Globale API-Ressourcen haben keinen Organisationskontext. Sie können jedoch in Verbindung mit Organisationsrollen verwendet werden, um bei Bedarf eine zusätzliche Kontextebene bereitzustellen. Um organisationsbezogene APIs zu schützen, siehe [Organisationsbezogene API-Ressourcen schützen](/authorization/organization-level-api-resources).
 
 <img src={illustration} alt="Globale API-Ressourcen RBAC" style={{ maxWidth: '100%' }} />
 
@@ -50,7 +51,7 @@ Logto modelliert API-Ressourcen gemäß [RFC 8707: Resource Indicators for OAuth
 **Wichtige Punkte**
 
 - Ressourcenindikatoren müssen absolute URIs sein (z. B. `https://api.example.com`)
-- Kein Fragmentbestandteil; vermeide nach Möglichkeit Query-Strings.
+- Kein Fragmentbestandteil; vermeide nach Möglichkeit die Verwendung von Query-Strings.
 - Ressourcenindikatoren ermöglichen zielgruppenbeschränkte Tokens und unterstützen Multi-API-Architekturen.
 
 **Beispiel**
@@ -60,9 +61,9 @@ Logto modelliert API-Ressourcen gemäß [RFC 8707: Resource Indicators for OAuth
 
 ### Autorisierungsfluss: Authentifizierung und Absicherung deiner API \{#authorization-flow-authenticating-and-securing-your-api}
 
-Der folgende Ablauf gilt sowohl für interaktive Benutzer-Authentifizierung (Browser/App) als auch für Backend-Maschine-zu-Maschine (M2M)-Szenarien.
+Der folgende Ablauf gilt sowohl für interaktive Benutzer-Authentifizierung (Browser / App) als auch für Backend-Maschine-zu-Maschine (M2M)-Szenarien.
 
-Beachte, dass der Ablauf nicht alle Details zu erforderlichen Parametern oder Headern enthält, sondern sich auf die wichtigsten Schritte konzentriert. Lies weiter, um zu sehen, wie der Ablauf in der Praxis funktioniert.
+Beachte, dass der Ablauf nicht alle erforderlichen Parameter oder Header im Detail enthält, sondern sich auf die wichtigsten Schritte konzentriert. Lies weiter, um zu sehen, wie der Ablauf in der Praxis funktioniert.
 
 ```mermaid
 sequenceDiagram
@@ -96,13 +97,13 @@ sequenceDiagram
     end
 ```
 
-_Benutzer-Authentifizierung = Browser/App. M2M = Backend-Dienst oder Skript mit Client-Credentials._
+_Benutzer-Authentifizierung = Browser / App. M2M = Backend-Dienst oder Skript mit Client-Credentials._
 
 :::note
 Der `resource`-Parameter muss exakt mit dem in Logto registrierten API-Identifier (Ressourcenindikator) übereinstimmen.
 :::
 
-## Implementierungsschritte \{#implementation-steps}
+## Umsetzungsschritte \{#implementation-steps}
 
 ### Registriere deine API-Ressourcen \{#register-your-api-resources}
 
@@ -139,23 +140,23 @@ Details zu jedem SDK findest du in den [Schnellstarts](/quick-starts).
 </TabItem>
 <TabItem value="oauth-client" label="OAuth 2.0 / OIDC client library">
 
-Beim Konfigurieren deines OAuth 2.0-Clients oder beim Initialisieren des Authorization Code Flows stelle sicher, dass du den `resource`-Parameter und die gewünschten Scopes in der Autorisierungsanfrage einfügst.
+Beim Konfigurieren deines OAuth 2.0-Clients oder beim Initialisieren des Authorization Code Flows stelle sicher, dass du den `resource`-Parameter und die gewünschten Scopes in der Autorisierungsanfrage einschließt.
 
-Einige Bibliotheken unterstützen den `resource`-Parameter nicht nativ, erlauben aber in der Regel das Hinzufügen zusätzlicher Parameter zur Autorisierungsanfrage. Prüfe die Dokumentation deiner Bibliothek für Details.
+Einige Bibliotheken unterstützen den `resource`-Parameter nicht nativ, erlauben aber in der Regel das Übergeben zusätzlicher Parameter in der Autorisierungsanfrage. Prüfe die Dokumentation deiner Bibliothek für Details.
 
 Hier ein nicht-normatives Beispiel für die Autorisierungsanfrage mit den Parametern `resource` und `scope`:
 
 <AuthorizationRequestExample resource={resource} scope="read:products write:products" />
 
-Nach erfolgreicher Authentifizierung erhältst du einen Authorization Code. Tausche diesen Code gegen ein Zugangstoken, indem du eine POST-Anfrage an Logtos `/oidc/token`-Endpunkt stellst und den `resource`-Parameter im Anfragekörper angibst.
+Nach erfolgreicher Authentifizierung erhältst du einen Authorization Code. Tausche diesen Code gegen ein Zugangstoken aus, indem du eine POST-Anfrage an Logtos `/oidc/token`-Endpunkt stellst und den `resource`-Parameter im Request-Body einschließt.
 
-Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ authorization_code:
+Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ Authorization Code:
 
 <TokenRequestExample grantType="authorization_code" resource={resource} />
 
-Du kannst auch den Grant-Typ `refresh_token` verwenden, um ohne Benutzerinteraktion ein neues Zugangstoken zu erhalten, solange der `resource`-Parameter in der Anfrage enthalten ist.
+Du kannst auch den Grant-Typ `refresh_token` verwenden, um ein neues Zugangstoken ohne Benutzerinteraktion zu erhalten, solange der `resource`-Parameter in der Anfrage enthalten ist.
 
-Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ refresh_token:
+Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ Auffrischungstoken:
 
 <TokenRequestExample grantType="refresh_token" resource={resource} />
 
@@ -171,7 +172,7 @@ Es gibt zwei wichtige Parameter, die in der Anfrage enthalten sein müssen:
 - `resource`: Die URI des Ressourcenindikators der API, auf die du zugreifen möchtest (z. B. `https://api.yourapp.com`).
 - `scope`: Die Berechtigungen, die du für die API anfordern möchtest (z. B. `read:products write:products`).
 
-Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ client_credentials:
+Hier ein nicht-normatives Beispiel für die Token-Anfrage mit dem Grant-Typ Client-Credentials:
 
 <ClientCredentialsRequestExample
   resource="https://api.yourapp.com"
@@ -192,16 +193,12 @@ Wenn deine API eine Anfrage mit einem von Logto ausgestellten Zugangstoken erhä
 
 Für Schritt-für-Schritt- und sprachspezifische Anleitungen siehe [Zugangstokens validieren](/authorization/validate-access-tokens).
 
-### Optional: Benutzerberechtigungsänderung behandeln \{#optional-handle-user-permission-change}
-
-:::info
-👷 In Arbeit. 🚧
-:::
+<HandleUserPermissionChange type="global" />
 
 ## Best Practices und Sicherheitstipps \{#best-practices-and-security-tips}
 
 - **Berechtigungen geschäftsorientiert halten:** Verwende klare Namen, die echten Aktionen entsprechen.
-- **Token-Ablauf kurz halten:** Reduziert das Risiko bei Token-Leakage.
+- **Token-Ablauf kurz halten:** Reduziert das Risiko bei einem Token-Leak.
 - **Vergebene Scopes begrenzen:** Gib Tokens nur die Berechtigungen, die sie tatsächlich benötigen.
 - **Zielgruppenbeschränkung nutzen:** Überprüfe immer den `aud`-Anspruch, um Missbrauch zu verhindern.
 
@@ -227,9 +224,9 @@ Lege eine Standard-API-Ressource in der Logto-Konsole fest. Tokens verwenden die
 
 Überprüfe die folgenden häufigen Probleme:
 
-- **Token-Signatur**: Stelle sicher, dass dein Backend die korrekten JWKs von Logto abruft
+- **Token-Signatur**: Stelle sicher, dass dein Backend die richtigen JWKs von Logto abruft
 - **Token-Ablauf**: Stelle sicher, dass das Token nicht abgelaufen ist (`exp`-Anspruch)
-- **Zielgruppe**: Prüfe, ob der `aud`-Anspruch mit deinem registrierten API-Ressourcenindikator übereinstimmt
+- **Zielgruppe**: Prüfe, dass der `aud`-Anspruch mit deinem registrierten API-Ressourcenindikator übereinstimmt
 - **Erforderliche Scopes**: Stelle sicher, dass das Token die notwendigen Berechtigungen im `scope`-Anspruch enthält
 
 </details>
@@ -270,12 +267,12 @@ scopes: ["read:elections", "write:elections"]
 Das funktioniert **NICHT**:
 
 ```swift
-scopes: ["read", "write"]  // ❌ Stimmt nicht mit den Berechtigungsnamen überein
+scopes: ["read", "write"]  // ❌ Entspricht nicht den Berechtigungsnamen
 ```
 
 </details>
 
-## Weiterführende Literatur \{#further-reading}
+## Weiterführende Informationen \{#further-reading}
 
 <Url href="/authorization/validate-access-tokens">Zugangstokens validieren</Url>
 <Url href="/use-cases/authorization/rbac-in-practice">