chore: update translations and generated content (#1334)

Co-authored-by: wangsijie <5717882+wangsijie@users.noreply.github.com>

Author: silverhand-bot

i18n/de/docusaurus-plugin-content-docs/current/quick-starts/framework/next-app-router/README.mdx

@@ -25,8 +25,8 @@ import FetchOrganizationTokenForUser from './api-resources/_fetch-organization-t
 
 ## Voraussetzungen \{#prerequisites}
 
-- Ein [Logto Cloud](https://cloud.logto.io)-Konto oder eine [selbst gehostete Logto](/introduction/set-up-logto-oss).
-- Eine erstellte traditionelle Logto-Anwendung.
+- Ein [Logto Cloud](https://cloud.logto.io) Konto oder ein [selbst gehostetes Logto](/introduction/set-up-logto-oss).
+- Eine erstellte Logto-Traditionelle Anwendung.
 
 ## Installation \{#installation}
 
@@ -52,9 +52,10 @@ import FetchOrganizationTokenForUser from './api-resources/_fetch-organization-t
 
 <FetchAccessTokenForApiResources />
 
-Wenn du ein Zugangstoken im Server-Component abrufen musst, kannst du die Funktion `getAccessTokenRSC` verwenden:
+Wenn du ein Zugangstoken in der Server-Komponente abrufen musst, kannst du die Funktion `getAccessTokenRSC` verwenden:
 
 ```tsx title="app/page.tsx"
+// Beispiel: Zugangstoken im Server abrufen
 import { getAccessTokenRSC } from '@logto/next/server-actions';
 import { logtoConfig } from './logto';
 
@@ -69,19 +70,25 @@ export default async function Home() {
 }
 ```
 
-:::tip
+:::tip[RSC-Token-Caching-Einschränkung]
+
+React Server Components können keine Cookies schreiben (Next.js-Einschränkung). Während `getAccessTokenRSC` abgelaufene Tokens weiterhin mit dem Auffrischungstoken aktualisiert, wird das neue Zugangstoken nicht im Sitzungs-Cookie gespeichert. Das bedeutet, dass jede RSC-Anfrage eine Token-Aktualisierung auslösen kann, wenn das zwischengespeicherte Token abgelaufen ist.
 
-HTTP erlaubt das Setzen von Cookies nach Beginn des Streamings nicht, daher kann `getAccessTokenRSC` den Cookie-Wert nicht aktualisieren. Wenn das Zugangstoken also aktualisiert wird, bleibt es nicht in der Sitzung erhalten. Es wird empfohlen, die Funktion `getAccessToken` auf der Client-Seite oder in Route-Handlern zu verwenden.
+**Lösungen:**
+
+1. **Client-Komponenten mit Server Actions verwenden** – Rufe `getAccessToken` aus einer Client-Komponente über Server Actions auf, die Cookies aktualisieren können.
+2. **Externen Sitzungs-Speicher verwenden** – Konfiguriere einen `sessionWrapper` mit Redis/KV-Speicher. Das Cookie speichert nur eine feste Sitzungs-ID, während die Token-Daten im externen Speicher liegen, sodass RSC aktualisierte Tokens speichern kann. Siehe [Externen Sitzungs-Speicher verwenden](#use-external-session-storage) unten.
 
 :::
 
 ### Organisationstokens abrufen \{#fetch-organization-tokens}
 
 <FetchOrganizationTokenForUser />
 
-Wenn du ein Organisationstoken im Server-Component abrufen musst, kannst du die Funktion `getOrganizationTokenRSC` verwenden:
+Wenn du ein Organisationstoken in der Server-Komponente abrufen musst, kannst du die Funktion `getOrganizationTokenRSC` verwenden:
 
 ```tsx title="app/page.tsx"
+// Beispiel: Organisationstoken im Server abrufen
 import { getOrganizationTokenRSC } from '@logto/next/server-actions';
 import { logtoConfig } from './logto';
 
@@ -96,23 +103,24 @@ export default async function Home() {
 }
 ```
 
-:::tip
+:::tip[RSC-Token-Caching-Einschränkung]
 
-HTTP erlaubt das Setzen von Cookies nach Beginn des Streamings nicht, daher kann `getOrganizationTokenRSC` den Cookie-Wert nicht aktualisieren. Wenn das Zugangstoken also aktualisiert wird, bleibt es nicht in der Sitzung erhalten. Es wird empfohlen, die Funktion `getOrganizationToken` auf der Client-Seite oder in Route-Handlern zu verwenden.
+Wie bei `getAccessTokenRSC` wird das aktualisierte Organisationstoken nicht in RSC gespeichert. Siehe [Lösungen oben](#fetch-access-token-for-the-api-resource).
 
 :::
 
-## Externen Sitzungspeicher verwenden \{#use-external-session-storage}
+## Externen Sitzungs-Speicher verwenden \{#use-external-session-storage}
 
 <ExternalStorage />
 
-## Automatische Weiterleitung zur Anmeldung bei fehlender Berechtigung \{#automatic-sign-in-redirect\}
+## Automatische Weiterleitung zur Anmeldung bei nicht autorisierten Zugriffen \{#automatic-sign-in-redirect\}
 
 :::tip
-Der `signIn`-Helper ändert Cookies, um die Anmeldesitzung zu erstellen, daher kann er nicht direkt in einer React Server Component (RSC) aufgerufen werden. Um die Anmeldung automatisch auszulösen, wenn eine RSC einen nicht autorisierten Benutzer erkennt, rufe `signIn` in einem dedizierten Route-Handler auf und leite zu dieser Route weiter.
+Der `signIn`-Helper verändert Cookies, um die Anmeldesitzung zu erstellen, daher kann er nicht direkt in einer React Server Component (RSC) aufgerufen werden. Um die Anmeldung automatisch auszulösen, wenn eine RSC einen nicht autorisierten Benutzer erkennt, rufe `signIn` in einem dedizierten Route-Handler auf und leite zu dieser Route weiter.
 :::
 
 ```ts title="app/sign-in/route.ts"
+// Beispiel: Anmeldung über Route-Handler auslösen
 import { signIn } from '@logto/next/server-actions';
 import { logtoConfig } from '../../logto';
 
@@ -122,6 +130,7 @@ export async function GET() {
 ```
 
 ```tsx title="app/protected/page.tsx"
+// Beispiel: Automatische Weiterleitung bei nicht authentifiziertem Benutzer
 import { getLogtoContext } from '@logto/next/server-actions';
 import { redirect } from 'next/navigation';
 import { logtoConfig } from '../logto';
@@ -137,6 +146,6 @@ export default async function ProtectedPage() {
 }
 ```
 
-## Weiterführende Literatur \{#further-readings}
+## Weitere Informationen \{#further-readings}
 
 <FurtherReadings />

i18n/de/docusaurus-plugin-content-docs/current/quick-starts/framework/next/_external-storage.mdx

@@ -1,6 +1,6 @@
 Das SDK verwendet standardmäßig Cookies, um verschlüsselte Sitzungsdaten zu speichern. Dieser Ansatz ist sicher, erfordert keine zusätzliche Infrastruktur und funktioniert besonders gut in serverlosen Umgebungen wie Vercel.
 
-Es gibt jedoch Zeiten, in denen du Sitzungsdaten extern speichern musst. Zum Beispiel, wenn deine Sitzungsdaten zu groß für Cookies werden, insbesondere wenn du mehrere aktive Organisation-Sitzungen gleichzeitig aufrechterhalten musst. In diesen Fällen kannst du eine externe Sitzungspeicherung mit der Option `sessionWrapper` implementieren:
+Es gibt jedoch Situationen, in denen du Sitzungsdaten extern speichern musst. Zum Beispiel, wenn deine Sitzungsdaten zu groß für Cookies werden, insbesondere wenn du mehrere aktive Organisationstoken (Organization tokens) gleichzeitig verwalten musst. In diesen Fällen kannst du eine externe Sitzungspeicherung mit der Option `sessionWrapper` implementieren:
 
 ```ts
 import { MemorySessionWrapper } from './storage';
@@ -18,9 +18,14 @@ import { type SessionWrapper, type SessionData } from '@logto/next';
 
 export class MemorySessionWrapper implements SessionWrapper {
   private readonly storage = new Map<string, unknown>();
+  private currentSessionId?: string;
 
   async wrap(data: unknown, _key: string): Promise<string> {
-    const sessionId = randomUUID();
+    // Vorhandene Sitzungs-ID wiederverwenden, falls verfügbar; nur für Erstbenutzer eine neue generieren.
+    // Dies ist wichtig für Umgebungen, in denen Cookies nicht aktualisiert werden können (z. B. React Server Components),
+    // da die Sitzungs-ID im Cookie stabil bleiben muss, während die Daten im externen Speicher aktualisiert werden können.
+    const sessionId = this.currentSessionId ?? randomUUID();
+    this.currentSessionId = sessionId;
     this.storage.set(sessionId, data);
     return sessionId;
   }
@@ -30,10 +35,12 @@ export class MemorySessionWrapper implements SessionWrapper {
       return {};
     }
 
+    // Die Sitzungs-ID für eine mögliche Wiederverwendung in wrap() speichern
+    this.currentSessionId = value;
     const data = this.storage.get(value);
     return data ?? {};
   }
 }
 ```
 
-Die obige Implementierung verwendet einen einfachen In-Memory-Speicher. In einer Produktionsumgebung möchtest du möglicherweise eine beständigere Speicherlösung verwenden, wie Redis oder eine Datenbank.
+Die obige Implementierung verwendet einen einfachen In-Memory-Speicher. In einer Produktionsumgebung solltest du eine beständigere Speicherlösung wie Redis oder eine Datenbank verwenden.

i18n/es/docusaurus-plugin-content-docs/current/quick-starts/framework/next-app-router/README.mdx

@@ -69,9 +69,14 @@ export default async function Home() {
 }
 ```
 
-:::tip
+:::tip[Limitación de almacenamiento en caché de token en RSC]
+
+Los React Server Components no pueden escribir cookies (limitación de Next.js). Aunque `getAccessTokenRSC` seguirá renovando los tokens expirados usando el token de actualización, el nuevo token de acceso no se guardará en la cookie de sesión. Esto significa que cada solicitud RSC puede desencadenar una renovación de token si el token en caché ha expirado.
 
-HTTP no permite establecer cookies después de que comienza el streaming, `getAccessTokenRSC` no puede actualizar el valor de la cookie, por lo que si el token de acceso se actualiza, no se persistirá en la sesión. Se recomienda usar la función `getAccessToken` en el lado del cliente o en los manejadores de rutas.
+**Soluciones:**
+
+1. **Usar componentes cliente con Server Actions** - Llama a `getAccessToken` desde un componente cliente mediante Server Actions, lo que puede actualizar las cookies.
+2. **Usar almacenamiento de sesión externo** - Configura un `sessionWrapper` con almacenamiento Redis/KV. La cookie almacena solo un ID de sesión fijo mientras que los datos del token viven en el almacenamiento externo, permitiendo que RSC persista los tokens renovados. Consulta [Usar almacenamiento de sesión externo](#use-external-session-storage) abajo.
 
 :::
 
@@ -96,9 +101,9 @@ export default async function Home() {
 }
 ```
 
-:::tip
+:::tip[Limitación de almacenamiento en caché de token en RSC]
 
-HTTP no permite establecer cookies después de que comienza el streaming, `getOrganizationTokenRSC` no puede actualizar el valor de la cookie, por lo que si el token de acceso se actualiza, no se persistirá en la sesión. Se recomienda usar la función `getOrganizationToken` en el lado del cliente o en los manejadores de rutas.
+Al igual que `getAccessTokenRSC`, el token de organización renovado no se guardará en RSC. Consulta [las soluciones anteriores](#fetch-access-token-for-the-api-resource).
 
 :::
 
@@ -109,7 +114,7 @@ HTTP no permite establecer cookies después de que comienza el streaming, `getOr
 ## Redirección automática al inicio de sesión en caso de no autorizado \{#automatic-sign-in-redirect\}
 
 :::tip
-El helper `signIn` modifica las cookies para establecer la sesión de inicio de sesión, por lo que no puede ser invocado directamente en un React Server Component (RSC). Para activar el inicio de sesión automáticamente cuando un RSC detecta un usuario no autorizado, llama a `signIn` en un manejador de ruta dedicado y redirige a esa ruta.
+El helper `signIn` modifica las cookies para establecer la sesión de inicio de sesión, por lo que no puede invocarse directamente en un React Server Component (RSC). Para activar el inicio de sesión automáticamente cuando un RSC detecta un usuario no autorizado, llama a `signIn` en un manejador de ruta dedicado y redirige a esa ruta.
 :::
 
 ```ts title="app/sign-in/route.ts"

i18n/es/docusaurus-plugin-content-docs/current/quick-starts/framework/next/_external-storage.mdx

@@ -1,6 +1,6 @@
-El SDK utiliza cookies para almacenar datos de sesión cifrados por defecto. Este enfoque es seguro, no requiere infraestructura adicional y funciona especialmente bien en entornos sin servidor como Vercel.
+El SDK utiliza cookies para almacenar datos de sesión cifrados de forma predeterminada. Este enfoque es seguro, no requiere infraestructura adicional y funciona especialmente bien en entornos sin servidor como Vercel.
 
-Sin embargo, hay ocasiones en las que podrías necesitar almacenar los datos de sesión externamente. Por ejemplo, cuando tus datos de sesión crecen demasiado para las cookies, especialmente cuando necesitas mantener múltiples sesiones activas de organización simultáneamente. En estos casos, puedes implementar un almacenamiento de sesión externo utilizando la opción `sessionWrapper`:
+Sin embargo, hay ocasiones en las que podrías necesitar almacenar los datos de sesión externamente. Por ejemplo, cuando tus datos de sesión crecen demasiado para las cookies, especialmente cuando necesitas mantener varias sesiones activas de organización simultáneamente. En estos casos, puedes implementar almacenamiento externo de sesión utilizando la opción `sessionWrapper`:
 
 ```ts
 import { MemorySessionWrapper } from './storage';
@@ -18,9 +18,14 @@ import { type SessionWrapper, type SessionData } from '@logto/next';
 
 export class MemorySessionWrapper implements SessionWrapper {
   private readonly storage = new Map<string, unknown>();
+  private currentSessionId?: string;
 
   async wrap(data: unknown, _key: string): Promise<string> {
-    const sessionId = randomUUID();
+    // Reutiliza el ID de sesión existente si está disponible, solo genera uno nuevo para usuarios por primera vez.
+    // Esto es importante para entornos donde las cookies no pueden actualizarse (por ejemplo, React Server Components),
+    // ya que el ID de sesión en la cookie debe permanecer estable mientras que los datos en el almacenamiento externo pueden actualizarse.
+    const sessionId = this.currentSessionId ?? randomUUID();
+    this.currentSessionId = sessionId;
     this.storage.set(sessionId, data);
     return sessionId;
   }
@@ -30,10 +35,12 @@ export class MemorySessionWrapper implements SessionWrapper {
       return {};
     }
 
+    // Almacena el ID de sesión para posible reutilización en wrap()
+    this.currentSessionId = value;
     const data = this.storage.get(value);
     return data ?? {};
   }
 }
 ```
 
-La implementación anterior utiliza un almacenamiento en memoria simple. En un entorno de producción, podrías querer usar una solución de almacenamiento más persistente, como Redis o una base de datos.
+La implementación anterior utiliza un almacenamiento simple en memoria. En un entorno de producción, podrías querer utilizar una solución de almacenamiento más persistente, como Redis o una base de datos.

i18n/fr/docusaurus-plugin-content-docs/current/quick-starts/framework/next-app-router/README.mdx

@@ -52,10 +52,10 @@ import FetchOrganizationTokenForUser from './api-resources/_fetch-organization-t
 
 <FetchAccessTokenForApiResources />
 
-Si vous avez besoin de récupérer un jeton d’accès dans le composant serveur, vous pouvez utiliser la fonction `getAccessTokenRSC` :
+Si vous devez récupérer un jeton d’accès dans le composant serveur, vous pouvez utiliser la fonction `getAccessTokenRSC` :
 
 ```tsx title="app/page.tsx"
-// Importations et configuration identiques à l'exemple original
+// Importation des fonctions nécessaires
 import { getAccessTokenRSC } from '@logto/next/server-actions';
 import { logtoConfig } from './logto';
 
@@ -70,20 +70,25 @@ export default async function Home() {
 }
 ```
 
-:::tip
+:::tip[Limitation du cache des jetons RSC]
+
+Les React Server Components ne peuvent pas écrire de cookies (limitation Next.js). Bien que `getAccessTokenRSC` rafraîchisse toujours les jetons expirés à l’aide du jeton de rafraîchissement, le nouveau jeton d’accès ne sera pas conservé dans le cookie de session. Cela signifie que chaque requête RSC peut déclencher un rafraîchissement du jeton si le jeton mis en cache a expiré.
 
-HTTP n’autorise pas la définition de cookies après le début du streaming, `getAccessTokenRSC` ne peut donc pas mettre à jour la valeur du cookie. Ainsi, si le jeton d’accès est rafraîchi, il ne sera pas conservé dans la session. Il est recommandé d’utiliser la fonction `getAccessToken` côté client ou dans les gestionnaires de routes.
+**Solutions :**
+
+1. **Utiliser des composants client avec Server Actions** – Appelez `getAccessToken` depuis un composant client via Server Actions, ce qui permet de mettre à jour les cookies.
+2. **Utiliser un stockage de session externe** – Configurez un `sessionWrapper` avec un stockage Redis/KV. Le cookie ne stocke qu’un identifiant de session fixe tandis que les données de jeton résident dans le stockage externe, permettant à RSC de conserver les jetons rafraîchis. Voir [Utiliser un stockage de session externe](#use-external-session-storage) ci-dessous.
 
 :::
 
 ### Récupérer des jetons d’organisation \{#fetch-organization-tokens}
 
 <FetchOrganizationTokenForUser />
 
-Si vous avez besoin de récupérer un jeton d’organisation dans le composant serveur, vous pouvez utiliser la fonction `getOrganizationTokenRSC` :
+Si vous devez récupérer un jeton d’organisation dans le composant serveur, vous pouvez utiliser la fonction `getOrganizationTokenRSC` :
 
 ```tsx title="app/page.tsx"
-// Importations et configuration identiques à l'exemple original
+// Importation des fonctions nécessaires
 import { getOrganizationTokenRSC } from '@logto/next/server-actions';
 import { logtoConfig } from './logto';
 
@@ -98,24 +103,24 @@ export default async function Home() {
 }
 ```
 
-:::tip
+:::tip[Limitation du cache des jetons RSC]
 
-HTTP n’autorise pas la définition de cookies après le début du streaming, `getOrganizationTokenRSC` ne peut donc pas mettre à jour la valeur du cookie. Ainsi, si le jeton d’accès est rafraîchi, il ne sera pas conservé dans la session. Il est recommandé d’utiliser la fonction `getOrganizationToken` côté client ou dans les gestionnaires de routes.
+Comme pour `getAccessTokenRSC`, le jeton d’organisation rafraîchi ne sera pas conservé dans RSC. Voir [solutions ci-dessus](#fetch-access-token-for-the-api-resource).
 
 :::
 
 ## Utiliser un stockage de session externe \{#use-external-session-storage}
 
 <ExternalStorage />
 
-## Redirection automatique vers la connexion en cas d’accès non autorisé \{#automatic-sign-in-redirect\}
+## Redirection automatique vers la connexion en cas d’utilisateur non autorisé \{#automatic-sign-in-redirect\}
 
 :::tip
 Le helper `signIn` modifie les cookies pour établir la session de connexion, il ne peut donc pas être invoqué directement dans un React Server Component (RSC). Pour déclencher automatiquement la connexion lorsqu’un RSC détecte un utilisateur non autorisé, appelez `signIn` dans un gestionnaire de route dédié et redirigez vers cette route.
 :::
 
 ```ts title="app/sign-in/route.ts"
-// Importations et configuration identiques à l'exemple original
+// Importation des fonctions nécessaires
 import { signIn } from '@logto/next/server-actions';
 import { logtoConfig } from '../../logto';
 
@@ -125,7 +130,7 @@ export async function GET() {
 ```
 
 ```tsx title="app/protected/page.tsx"
-// Importations et configuration identiques à l'exemple original
+// Importation des fonctions nécessaires
 import { getLogtoContext } from '@logto/next/server-actions';
 import { redirect } from 'next/navigation';
 import { logtoConfig } from '../logto';