Synchroniser les traductions avec Revisionary dans Strapi 5

Strapi 5 possède des fonctionnalités i18n intégrées qui vous permettent de stocker du contenu dans plusieurs langues, mais garder ces langues synchronisées pendant les modifications et les publications peut être délicat. Revisionary ajoute un historique complet des versions à chaque entrée et suit les changements de traduction par locale. Cet article montre comment configurer Revisionary pour des projets multilingues, comment utiliser son interface pour détecter les écarts de traduction, et comment interroger l’historique depuis un front‑end Next.js.

1. Pourquoi le glissement de traduction est important

Lorsque les rédacteurs mettent à jour la version anglaise d’un article, les copies française, espagnole ou allemande prennent souvent du retard. Si le brouillon anglais est publié alors que les autres langues restent en brouillon, les utilisateurs finaux peuvent voir des informations incohérentes. Revisionary résout ce problème en enregistrant chaque modification de champ par locale et en affichant un indicateur visuel qui montre quelles locales sont à jour.

2. Activer les types de contenu versionnés pour i18n

1. Ouvrez Settings → Plugins → Revisionary → Content types.
2. Cochez les types de contenu que vous souhaitez versionner (par ex., article, page).
3. Enregistrez les paramètres.
4. Assurez‑vous que le plugin i18n est installé et que les locales nécessaires sont définies sous Settings → Internationalization.

Avec les deux plugins actifs, chaque locale d’une entrée versionnée reçoit sa propre ligne de version dans le panneau Revisionary.

3. Le panneau « Translations » dans le Content Manager

Lorsque vous ouvrez une entrée, la colonne de droite affiche le panneau d’historique des versions. En dessous, le sous‑panneau Translations présente :

• État de la locale – une coche verte signifie que la locale correspond à la dernière version de la locale par défaut ; un avertissement jaune indique que la locale est en retard ; une icône rouge signale que la locale est en brouillon tandis que la locale par défaut est publiée.
• Champs modifiés – survoler un champ fait apparaître une icône horloge ; cliquer dessus révèle une frise chronologique des éditions de ce champ selon les locales.

4. Workflow pour garder les locales alignées

4.1 Brouillon‑first, publication‑later

1. Modifiez la locale par défaut (généralement en).
2. Enregistrez – Revisionary crée une nouvelle version brouillon.
3. Passez à chaque locale cible, copiez ou adaptez les champs modifiés, puis Enregistrez. Le panneau « Translations » deviendra vert dès que la version de la locale correspond au brouillon par défaut.
4. Lorsque toutes les locales sont vertes, publiez la locale par défaut. Revisionary publie automatiquement les versions correspondantes des autres locales si elles sont synchronisées ; sinon, il vous avertit.

4.2 Utiliser l’espace « Review »

Si vous avez besoin d’un relecteur séparé pour les traductions, activez l’espace Review (/docs/everyday-use/review). Assignez la copie française à un relecteur ; celui‑ci peut voir les différences de version et approuver d’un seul clic. Une fois approuvé, le panneau « Translations » passe au vert.

5. Restaurer une traduction sans affecter les autres locales

Parfois, un traducteur commet une erreur qui doit être annulée sans perdre les mises à jour des autres langues.

1. Ouvrez le panneau d’historique des versions.
2. Filtrez par locale à l’aide du menu déroulant en haut.
3. Sélectionnez la version erronée et cliquez sur Restore (ou appuyez sur R).
4. Seule la locale sélectionnée est restaurée ; les autres locales conservent leurs versions actuelles.
5. Facultativement, ajoutez un nom de jalon comme « Erreur de traduction française corrigée » pour référence future.

6. Interroger l’historique des traductions depuis le front‑end

Revisionary étend l’API Content standard avec un endpoint history qui peut être filtré par locale.

// Exemple : récupérer les trois dernières versions de l’article français
import fetch from 'node-fetch';

const slug = 'my-article';
const locale = 'fr';
const url = `${process.env.STRAPI_URL}/api/articles/${slug}?locale=${locale}&populate=history&limit=3`;

const response = await fetch(url, {
  headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` },
});
const data = await response.json();
console.log(data.data.attributes.history);

Le tableau history contient des objets avec id, createdAt, updatedAt et les champs modifiés. Vous pouvez afficher un sélecteur de révision sur votre page Next.js qui permet aux rédacteurs de visualiser les anciennes versions françaises côte à côte avec la version anglaise actuelle.

7. Automatiser les vérifications de synchronisation en CI/CD

Ajoutez un petit script à votre workflow GitHub Actions qui fait échouer le build si une locale n’est plus synchronisée après un déploiement de contenu.

name: Check translation sync
on: [push]
jobs:
  verify-sync:
    runs-on: ubuntu-latest
    steps:
      - name: Install node
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Run sync check
        env:
          STRAPI_URL: ${{ secrets.STRAPI_URL }}
          STRAPI_TOKEN: ${{ secrets.STRAPI_TOKEN }}
        run: |
          node - <<'EOS'
          const fetch = require('node-fetch');
          const locales = ['en','fr','es','de'];
          const slug = 'my-article';
          async function check() {
            const results = await Promise.all(locales.map(async locale => {
              const res = await fetch(`${process.env.STRAPI_URL}/api/articles/${slug}?locale=${locale}`);
              const json = await res.json();
              return {locale, version: json.data.id};
            }));
            const base = results.find(r => r.locale === 'en').version;
            const outOfSync = results.filter(r => r.version !== base && r.locale !== 'en');
            if (outOfSync.length) {
              console.error('Translations out of sync:', outOfSync.map(r=>r.locale).join(', '));
              process.exit(1);
            }
            console.log('All translations in sync');
          }
          check();
          EOS

Si le script se termine avec le code 1, le workflow échoue, alertant l’équipe pour résoudre le glissement avant la mise en production.

8. Pièges courants et comment les éviter

9. Exploiter l’API Content à des fins d’audit

Le journal d’audit (/docs/everyday-use/audit) enregistre chaque modification de traduction, y compris l’auteur et l’adresse IP (anonymisée si la confidentialité est activée). Pour exporter un CSV de l’activité de traduction :

const url = `${process.env.STRAPI_URL}/admin/audit-logs?entity=article&action=update&locale=fr`;
const logs = await fetch(url, { headers: { Authorization: `Bearer ${process.env.ADMIN_TOKEN}` } }).then(r=>r.json());
// Convert logs to CSV (omitted for brevity)

Les auditeurs peuvent vérifier que chaque changement de locale passe par l’espace « Review », ce qui satisfait les exigences de conformité.

10. Résumé

Revisionary transforme le système i18n de Strapi 5 d’un simple magasin de locales en un flux de travail multilingue pleinement conscient des versions. En activant les types de contenu versionnés, en utilisant le panneau « Translations », en nommant les jalons et en intégrant le endpoint history à votre front‑end ou votre pipeline CI/CD, vous pouvez garantir que chaque version linguistique reste cohérente et auditable.

Pour approfondir les panneaux UI et les permissions de Revisionary, consultez les pages du guide utilisateur officiel reliées tout au long de cet article.