Les statuts de traduction doivent répondre à la question suivante

Les systèmes de traduction produisent beaucoup d’états. Les tâches entrent en file d’attente, les fournisseurs répondent, les brouillons s’enregistrent, Contentful se met à jour, les entrées sont publiées et les nouvelles tentatives commencent.

Afficher toute cette activité ne rend pas automatiquement la progression claire.

Un statut utile doit répondre à la question suivante que se pose l’éditeur.

Une requête a plusieurs cycles de vie

Une requête multilingue passe souvent par trois phases principales :

1. traduire
2. pousser
3. publier

Chaque phase peut être inactive, en file d’attente, en cours, réussie, ignorée ou échouée. Compresser ces états en un seul mot fait perdre des informations importantes.

« Terminé » peut signifier que le brouillon de traduction est prêt pour révision, que la langue cible a été écrite dans Contentful, ou que l’entrée est en ligne. Ce sont des résultats fondamentalement différents.

L’interface doit nommer ensemble la phase et son état.

Le statut et l’action vont ensemble

Les éditeurs lisent le statut pour décider de ce qu’ils peuvent faire ensuite.

• Une traduction prête peut être révisée.
• Une traduction approuvée peut être poussée.
• Une poussée réussie peut être publiée.
• Un échec transitoire peut faire l’objet d’une nouvelle tentative.
• Un travail en cours peut éventuellement être annulé.

Si l’action disponible ne correspond pas à l’état affiché, le produit semble incohérent. Un bouton de publication à côté d’une requête qui n’a jamais été poussée n’est pas seulement déroutant ; cela affaiblit la confiance dans le workflow sous-jacent.

Le backend doit déterminer la disponibilité à partir de l’état durable et des permissions, puis l’UI doit refléter cette décision de manière cohérente.

Les compteurs de progression ont besoin d’un dénominateur stable

La progression d’un lot devient trompeuse lorsque chaque phase utilise un total différent sans l’expliquer.

Un lot de dix requêtes de traduction peut comporter dix traductions, huit poussées et six publications parce que certaines langues étaient uniquement destinées à la révision ou que l’automatisation était désactivée.

La progression doit distinguer :

• le total des requêtes
• les requêtes éligibles à la phase en cours
• les requêtes terminées, actives, échouées et ignorées

Le statut ignoré est particulièrement important. C’est une décision terminale, pas un travail inachevé.

Préserver l’historique sans encombrer l’écran

L’état actuel doit rester compact, mais les opérateurs ont tout de même besoin de l’historique lorsque quelque chose se passe mal.

Une chronologie d’événements extensible peut montrer quand la requête est entrée en file d’attente, quelle tentative a échoué, si une nouvelle tentative automatique a eu lieu et quand Contentful a accepté la mise à jour. Cela aide au débogage sans transformer chaque ligne de tableau en visualiseur de logs.

Utilisez un langage humain pour le statut principal et conservez les identifiants techniques et les horodatages dans la vue détaillée.

Les états terminaux doivent le rester

Le polling et les événements temps réel peuvent arriver dans le désordre. Un ancien événement « en cours » ne doit pas faire régresser une requête terminée. Une page actualisée ne doit pas afficher temporairement « en file d’attente » alors que la base de données enregistre déjà un succès.

Les transitions d’état ont besoin d’ordre et d’idempotence. L’interface doit fusionner les mises à jour en utilisant l’horodatage ou la version faisant autorité, et non simplement accepter le dernier message livré au navigateur.

À retenir

La conception des statuts fait partie du workflow, ce n’est pas une décoration autour de celui-ci.

Séparez les phases de traduction, de poussée et de publication. Associez chaque état à l’action qu’il permet, comptez honnêtement le travail ignoré et gardez un historique détaillé à portée de main. Le meilleur statut est celui qui rend claire la décision suivante.