better-i18n Translation Version Control : Historique complet et Rollback

Le code de votre application vit dans Git. Chaque changement est suivi. Chaque ligne a un auteur connu. N'importe quelle version peut être restaurée en quelques secondes. Si un mauvais commit arrive en production, vous effectuez un Rollback. Si vous voulez comprendre pourquoi une fonction a été écrite d'une certaine façon, vous lisez l'historique des commits.

Vos traductions méritent le même traitement. Mais dans la plupart des plateformes de localisation, l'historique est une réflexion après coup — au mieux un simple journal des modifications, avec une recherche limitée, pas de vue diff et pas de Rollback. Quand quelque chose va mal avec une traduction en production, les équipes passent des heures à essayer de comprendre ce qui a changé, quand et pourquoi, puis encore plus d'heures à restaurer manuellement une version précédente.

better-i18n traite la Translation Version Control comme une fonctionnalité de première classe. Chaque modification de chaque string est enregistrée avec un diff complet, un horodatage et l'identité du collaborateur qui a effectué le changement. Le Rollback vers n'importe quelle version précédente est un seul clic. L'historique complet est interrogeable, consultable et disponible via l'API.

Comment ça fonctionne

Versionnage automatique à chaque sauvegarde

Chaque fois qu'un string de traduction est modifié dans better-i18n — via l'éditeur web, via l'outil CLI, via l'intégration MCP ou via l'API — une nouvelle version est automatiquement créée. Les versions sont créées pour chaque langue indépendamment, donc modifier la traduction allemande d'un string crée une nouvelle version du string allemand sans affecter la version française.

Les versions sont créées quel que soit l'auteur de la modification. Les traducteurs humains, les assistants IA opérant via la connexion MCP, les scripts de mise à jour en masse automatisés utilisant la CLI — tous produisent un historique versionné. Il n'y a aucun moyen de modifier une traduction sans laisser un enregistrement.

Ce que chaque version enregistre

Chaque enregistrement de version contient :

Horodatage : Le moment exact auquel la version a été créée, en UTC.
Auteur : L'identité de l'utilisateur ou du service qui a effectué le changement. Pour les utilisateurs humains, il s'agit de leur nom et profil. Pour les opérations API ou CLI, c'est l'identifiant du token API.
Contenu avant et après : Le texte complet de la traduction avant et après le changement, permettant une vue diff complète.
Transition de statut : Si le string est passé d'un statut à un autre (par exemple, de « en cours » à « soumis pour révision », ou de « approuvé » à « nécessite une révision »).
Note de modification : Un message optionnel attaché par l'auteur, similaire à un message de commit. Le workflow de collaboration encourage les auteurs à ajouter des notes de modification lorsqu'ils effectuent des corrections basées sur les retours du réviseur.
Résultats des vérifications QA : Le statut QA du string au moment où la version a été créée. Ceci est extrait du moteur d'assurance qualité et stocké avec la version pour référence ultérieure.

Visualiser l'historique

Le panneau d'historique pour n'importe quel string affiche toutes ses versions en ordre chronologique inversé. Chaque entrée affiche l'auteur, l'horodatage, le statut à cette version et un diff condensé du changement de contenu (mots ajoutés surlignés en vert, mots supprimés surlignés en rouge).

Cliquer sur n'importe quelle version affiche le contenu complet à ce moment-là — pas seulement le diff, mais le string complet tel qu'il existait lors de la création de cette version.

L'historique est également consultable au niveau du projet. Vous pouvez voir une chronologie de tous les changements dans tous les strings d'un projet, filtrée par langue, par auteur, par plage de temps ou par changement de statut. C'est utile pour les audits, pour les revues post-incident et pour comprendre le rythme et le schéma général de l'activité de traduction.

Rollback

Rétrograder un string à une version précédente est une seule action. Dans le panneau d'historique, cliquez sur « Restaurer cette version » sur n'importe quelle entrée. Le contenu actuel est remplacé par le contenu de la version sélectionnée. Une nouvelle version est créée enregistrant le Rollback, incluant quelle version a été restaurée et qui a effectué le Rollback.

Le Rollback est disponible pour les Éditeurs et les Admins. Les Traducteurs et les Réviseurs peuvent voir l'historique mais ne peuvent pas effectuer de Rollback, empêchant la restauration accidentelle ou non autorisée d'ancien contenu.

Vous pouvez également effectuer un Rollback d'une langue entière à son état à un horodatage spécifique. C'est utile lorsqu'une opération en masse — une mise à jour de terminologie, une traduction en masse assistée par IA — produit des résultats inattendus sur de nombreux strings. Plutôt que de revenir sur chaque string individuellement, vous restaurez toute la langue à son état pré-opération et réessayez l'opération avec des paramètres corrigés.

Comparer les versions

La vue diff dans better-i18n est au niveau du mot, pas au niveau de la ligne. Les strings de traduction sont typiquement des phrases uniques ou de courts paragraphes. Un diff au niveau de la ligne montrerait souvent l'ensemble du string comme modifié. Un diff au niveau du mot montre précisément quels mots ont été ajoutés, supprimés ou réorganisés, ce qui facilite beaucoup la compréhension de ce qui a réellement changé.

Vous pouvez comparer n'importe quelles deux versions d'un string — pas seulement les versions adjacentes. Sélectionnez deux points dans l'historique et voyez le delta entre eux, quel que soit le nombre de versions intermédiaires existantes.

Étiquetage et snapshots de Release

Lorsque vous déployez une nouvelle version de votre application, vous pouvez étiqueter l'état actuel de vos traductions avec un label de release :

bi18n tag --name v2.5.0 --message "Release 2.5.0 translations"

Cela crée un snapshot de chaque traduction dans son état approuvé actuel. Vous pouvez ensuite interroger l'état de n'importe quel string à n'importe quelle étiquette de release, comparer les traductions entre les releases et restaurer des strings individuels à leur état lors d'un release passé si nécessaire.

Les étiquettes de release sont visibles dans le tableau de bord analytics, qui affiche les métriques de couverture et de qualité liées à chaque release étiqueté.

Export d'audit

Pour les industries réglementées ou les exigences de conformité, l'historique complet des modifications pour un projet ou une plage de temps spécifique peut être exporté sous forme de fichier CSV ou JSON structuré. L'export inclut chaque enregistrement de version pour chaque string, dans chaque langue, avec le contenu complet avant et après et les données d'attribution.

Cet export convient pour être joint aux rapports de conformité, pour la révision d'audit externe ou à des fins d'archivage.

Avantages clés

Responsabilité complète

Dans un environnement de traduction en équipe, les choses se passent parfois mal. Un sous-traitant écrase un string soigneusement approuvé. Un script automatisé applique un changement de terminologie qui s'avère incorrect. Un réviseur approuve un string avec un espace réservé cassé qui a glissé à travers.

Lorsque chaque changement est enregistré avec attribution et horodatages, vous pouvez toujours répondre à la question « que s'est-il passé ? ». Vous savez exactement qui a effectué le changement, quand et quel était le contenu avant le changement. C'est la responsabilité dans le même sens que Git fournit la responsabilité pour les changements de code.

Récupération rapide des incidents

Lorsqu'un problème de traduction atteint la production — un espace réservé cassé qui cause une erreur JavaScript, un avertissement légal mal traduit, un string complètement incorrect — vous devez le corriger rapidement. Sans Version Control, corriger une mauvaise traduction signifie trouver l'ancienne version (qui peut ne pas exister quelque part), la restaurer, republier et redéployer.

Avec better-i18n Version Control, la récupération est : trouver le string, ouvrir l'historique, cliquer sur « Restaurer », publier et déclencher un déploiement. L'opération entière prend moins de deux minutes. L'outil CLI peut récupérer la traduction restaurée immédiatement pour un déploiement rapide.

Opérations en masse sécurisées

Les opérations en masse — mises à jour de terminologie, traductions en masse par IA, remplacements de strings de rebranding — sont puissantes mais risquées. Si une opération en masse produit des résultats incorrects, vous avez besoin d'un moyen de l'annuler. La Version Control de better-i18n rend les opérations en masse sûres en garantissant que chaque string touché par l'opération a son état précédent enregistré et est restaurable.

Avant d'exécuter toute grande opération en masse, vous pouvez étiqueter l'état actuel comme point de contrôle de sécurité. Si l'opération se passe mal, restaurez au point de contrôle.

Intégration avec la Version Control de code

La Translation Version Control dans better-i18n est conçue pour compléter, et non remplacer, la Version Control basée sur Git de votre codebase. Lorsque vous étiquetez un release dans better-i18n avec le même numéro de version que vous utilisez dans Git, vous créez un lien permanent entre l'état de votre code et l'état de vos traductions à ce release. Le débogage post-release devient beaucoup plus propre lorsque vous pouvez corréler les deux.

L'outil CLI prend en charge la création automatique d'étiquettes dans le cadre de votre pipeline de déploiement, de sorte que le lien entre les versions de code et de traduction est maintenu sans effort manuel.

Conformité et préparation aux audits

Pour les produits dans les industries réglementées, démontrer l'historique des modifications de contenu est souvent une exigence de conformité. Les produits logiciels de legal tech, fintech, santé et gouvernement doivent fréquemment montrer que leur texte destiné aux utilisateurs — y compris les versions traduites — a été examiné et approuvé par des rôles spécifiques à des moments spécifiques.

L'historique des versions de better-i18n fournit cette preuve dès le départ. L'export d'audit produit un enregistrement lisible par machine qui peut être soumis aux auditeurs ou incorporé dans des rapports de conformité.

Cas d'utilisation

Réponse aux incidents post-release : Un utilisateur allemand signale qu'un message de confirmation de paiement affiche un nom de variable brut au lieu du montant réel. Vous recherchez dans l'historique des versions la traduction allemande du string de confirmation de paiement, trouvez qu'il a été modifié hier par un script automatisé qui a accidentellement supprimé un espace réservé, le revenez à la dernière bonne version connue et déclenchez un redéploiement.

Révision de rebranding : Votre entreprise se rebrande et modifie un nom de produit clé dans toutes les traductions. Après la mise à jour en masse, une partie prenante remarque que le nouveau nom est utilisé de manière incohérente. Vous utilisez la vue historique pour comparer l'état actuel avec le snapshot pré-rebranding, identifiez quels strings doivent encore être mis à jour et les corrigez.

Audit de sous-traitant : Le contrat d'un traducteur externe se termine. Avant qu'il perde l'accès, vous exportez l'historique complet des modifications pour les langues qu'il a gérées. L'export montre chaque string qu'il a créé ou modifié, avec des horodatages et un statut QA, fournissant un enregistrement permanent de sa contribution.

Mise en attente légale : Votre équipe juridique demande un enregistrement de tous les changements apportés aux strings de traduction des conditions d'utilisation au cours des 12 derniers mois. Vous filtrez l'historique par catégorie de string et plage de temps et exportez le résultat sous forme de rapport prêt pour PDF.

Restauration de Translation Memory : Un nouveau traducteur écrase accidentellement 40 strings approuvés lors de l'édition en masse d'une langue. Vous restaurez toute la langue à son état d'hier après-midi, récupérant tout le travail approuvé sans avoir à tout retraduire.

Comment better-i18n implémente la Version Control

Les versions de traduction dans better-i18n sont stockées comme des enregistrements immuables. Une fois qu'une version est écrite, elle n'est jamais modifiée. Le Rollback ne modifie pas les enregistrements historiques — il crée une nouvelle version avec le contenu restauré. L'historique est un log en ajout seulement.

L'algorithme de diff est un diff au niveau du mot basé sur l'algorithme de diff de Myers, adapté pour le texte en langage naturel plutôt que pour le code. Il gère la restructuration des phrases, la réorganisation des mots et les changements partiels de mots d'une manière qui rend le diff lisible pour les utilisateurs non techniques.

Le stockage des versions est efficace. Plutôt que de stocker le contenu complet de chaque version, le système stocke le contenu complet pour la première version et les diffs pour les versions suivantes. Le contenu complet est reconstruit à la lecture en appliquant la chaîne de diff. Cette approche maintient les besoins de stockage gérables pour les projets avec de longs historiques et de nombreuses langues.

L'API d'historique des versions prend en charge la pagination et le filtrage, ce qui permet de récupérer pratiquement l'historique de grands projets de manière programmatique sans charger l'ensemble de données en une seule fois.

Comparaison avec les alternatives

Phrase Version History : Phrase stocke l'historique des versions mais avec des capacités de Rollback limitées. Le retour en arrière nécessite la resaisie manuelle du contenu précédent plutôt qu'une restauration en un clic. better-i18n fournit un vrai Rollback en un clic avec comparaison de diff complète.

Lokalise Version Control : Lokalise inclut l'historique des modifications par string, mais le Rollback en masse au niveau de la langue n'est pas disponible. better-i18n prend en charge le Rollback au niveau du string et au niveau de la langue.

Fichiers de traduction gérés avec Git : Stocker les fichiers de traduction dans Git vous donne un historique complet et un Rollback via les commandes Git, mais cela exclut les membres non techniques de l'équipe de contribuer et de réviser. Les conflits de merge dans les fichiers JSON sont sujets aux erreurs. better-i18n vous donne les avantages de la Version Control de Git avec un workflow accessible à tous.

Pas de Version Control : De nombreuses plateformes de localisation et implémentations personnalisées n'ont pas d'historique des versions significatif. Quand quelque chose va mal, la récupération est manuelle et chronophage. C'est le statu quo que better-i18n est conçu pour remplacer.

Foire aux questions

Combien de temps l'historique des versions est-il conservé ? L'historique des versions est conservé indéfiniment sur tous les plans. Il n'y a pas de suppression automatique des anciennes versions.

Puis-je restaurer une version très ancienne — vieille de plusieurs années ? Oui. N'importe quelle version dans l'historique peut être restaurée quel que soit son âge. Le contenu restauré devient la version actuelle et un nouvel enregistrement de version est créé documentant la restauration.

Le Rollback affecte-t-il les strings publiés ? Le Rollback restaure le contenu et le statut d'un string à son état dans la version sélectionnée. Si la version sélectionnée avait le statut « approuvé », le string de Rollback a le statut « approuvé » et peut être publié. Le Rollback ne publie rien automatiquement — une étape de publication est toujours requise.

L'export d'audit est-il admissible à des fins de conformité ? L'export d'audit fournit un enregistrement complet horodaté de tous les changements avec attribution. Si cela est suffisant pour un cadre de conformité spécifique dépend des exigences du cadre. Nous recommandons de consulter votre équipe de conformité sur le niveau de documentation requis.

Puis-je voir l'historique d'un string qui a depuis été supprimé ? Oui. Les strings supprimés et leur historique sont conservés dans un état archivé. Vous pouvez rechercher des strings supprimés et voir leur historique complet. Les strings supprimés ne peuvent pas être restaurés au statut actif sans recréer la clé du string.

Ne perdez plus jamais une traduction

La Version Control pour les traductions n'est pas un luxe — c'est une exigence de sécurité pour toute équipe qui prend la localisation au sérieux. better-i18n enregistre chaque changement, rend l'historique visible et consultable et permet un Rollback instantané quand les choses tournent mal.

Commencez votre essai gratuit et voyez l'historique complet de vos traductions dès le premier jour.

better-i18n Translation Version Control : Historique complet et Rollback