Les mises à jour de traduction en temps réel doivent être utiles, pas obligatoires

Voir une traduction passer de en file d’attente à en cours puis prête est utile. Les équipes peuvent suivre la progression sans actualiser, ouvrir rapidement le travail terminé et remarquer une requête échouée pendant que la publication est encore active.

Mais les mises à jour en direct sont une capacité de présentation. Elles ne doivent pas être le mécanisme qui rend le flux de travail correct.

L’état durable passe avant tout

La base de données et le système de tâches doivent être responsables de l’état de traduction. Chaque transition de phase doit être enregistrée, qu’un navigateur soit connecté ou non :

• requête mise en file d’attente
• traduction démarrée et terminée
• envoi démarré et terminé
• publication démarrée et terminée
• événements d’échec et de nouvelle tentative

Un événement temps réel peut annoncer ce changement durable. Il ne doit pas être l’unique trace du fait que le changement a eu lieu.

Cette distinction protège les utilisateurs qui ferment l’onglet, perdent l’accès au réseau ou travaillent dans un environnement où l’infrastructure websocket est désactivée.

Le temps réel a un coût opérationnel

La diffusion ajoute davantage d’éléments mobiles : un service websocket, l’autorisation des connexions, la configuration des canaux, la prise en charge des proxys et le comportement de reconnexion du navigateur.

Pour les équipes qui ont besoin de coordination en direct, ce coût peut en valoir la peine. Pour un déploiement plus modeste, un sondage périodique ordinaire peut être plus simple et tout à fait suffisant.

Rendre le temps réel optionnel permet à chaque environnement de choisir le profil opérationnel qu’il peut prendre en charge sans perdre le comportement de traduction de base.

Concevoir un repli élégant

L’interface utilisateur doit atteindre le même état final via des événements temps réel ou un rafraîchissement périodique.

Une approche pratique consiste à :

1. charger l’état durable actuel
2. s’abonner aux événements pertinents lorsque le temps réel est activé
3. fusionner les mises à jour entrantes par ID de requête et version
4. interroger à intervalle modéré tant qu’il reste du travail actif
5. arrêter l’interrogation fréquente lorsque le lot atteint un état terminal

Le temps réel donne à l’écran une impression d’immédiateté. Le sondage comble les lacunes après les reconnexions et fournit une solution de repli.

Les deux chemins ne doivent pas créer de règles d’état concurrentes.

Éviter de transformer les mises à jour en bruit

Tous les événements internes n’ont pas leur place dans l’interface. Diffuser chaque jeton, heartbeat de worker ou sauvegarde intermédiaire peut rendre la page instable et augmenter la charge de l’infrastructure.

Les utilisateurs ont généralement besoin de transitions de phase significatives et de comptages mis à jour. Regrouper les changements rapides de bas niveau en un ensemble plus réduit d’étapes durables garde l’expérience calme et facile à parcourir.

Le même principe s’applique aux notifications. Un lot terminé peut mériter de l’attention. Chaque langue terminée, probablement pas.

Tester le chemin silencieux

Il est facile de tester avec le temps réel activé et de supposer que la solution de repli fonctionne. La fiabilité exige l’exercice inverse :

• désactiver la diffusion
• démarrer un lot multilingue
• quitter puis revenir sur la page
• confirmer que la progression se met à jour
• relancer une requête échouée
• vérifier les décomptes finaux et les actions disponibles

Si ce chemin fonctionne, le temps réel devient une amélioration au lieu d’une dépendance cachée.

À retenir

Les mises à jour en direct améliorent les opérations de traduction lorsqu’elles reposent sur un état durable.

Enregistrez d’abord chaque transition, rendez la diffusion configurable et conservez une solution de repli par sondage mesuré. Le flux de travail doit rester fiable même lorsque le canal de livraison le plus immédiat est indisponible.