Pourquoi les captures d’écran comptent : le contexte visuel pour les traducteurs

Donnez cette liste à un traducteur et demandez de l’allemand :

buttons.open
status.open
hours.open

Les trois chaînes source sont le mot Open. En allemand, ce sont Öffnen, Offen et Geöffnet — un verbe, un adjectif et un participe. Rien dans la chaîne n’indique au traducteur laquelle est laquelle. Il devinera, et se trompera environ un tiers du temps.

C’est la cause la plus fréquente de mauvaises traductions dans les logiciels, et ce n’est pas un problème de traduction. C’est un problème de fourniture de contexte, et il est entièrement résoluble.

À quoi ressemble réellement l’ambiguïté#

Au-delà de la nature grammaticale, les cas récurrents :

Des contraintes de longueur invisibles. Un traducteur n’a aucun moyen de savoir qu’une chaîne se trouve dans un bouton de 120 pixels. L’allemand est 20 à 30 % plus long que l’anglais, si bien que la traduction honnête dépasse et se retrouve tronquée.

Des placeholders dont le contenu est inconnu. %{name} — le prénom d’une personne, un nom complet, le nom d’un projet, une entreprise ? Dans les langues avec un genre grammatical ou des cas, la réponse change les mots qui l’entourent.

Savoir s’il s’agit d’un titre, d’un libellé ou d’une phrase. Les conventions de majuscules diffèrent selon la langue, et la bonne convention dépend du rôle du texte.

La formalité. Les langues avec une adresse formelle et informelle imposent un choix à chaque phrase. Sans instruction au niveau du projet, les traducteurs choisissent individuellement, et l’interface se lit comme si plusieurs personnes l’avaient écrite.

Quel nom de produit est utilisé. Est-ce que « workspace » désigne votre fonctionnalité, ou le mot anglais ordinaire ? Une base terminologique répond à cette question ; rien d’autre ne le fait.

Pourquoi les captures d’écran surpassent les explications écrites#

Vous pouvez traiter tout ce qui précède avec des commentaires de développeur, et vous devriez le faire. Mais une capture d’écran fait quelque chose qu’un commentaire ne peut pas faire : elle répond à des questions que le traducteur ne savait pas qu’il devait poser.

Voir la chaîne en place leur indique la nature grammaticale, la largeur disponible, le texte environnant, la hiérarchie visuelle, s’il s’agit d’un bouton ou d’un titre, et ce que disent les chaînes adjacentes — tout cela en même temps, sans que personne ne l’ait écrit. Le contexte qui se révèle important n’est généralement pas celui que vous aviez prévu.

Cela raccourcit aussi la boucle de feedback dans l’autre sens. Un traducteur qui regarde une capture d’écran remarque que deux libellés adjacents utilisent une terminologie incohérente — un bug du texte source que vous auriez sinon livré dans chaque langue.

Le rendre praticable#

L’objection est toujours l’effort, et historiquement c’était une objection légitime : annoter des captures d’écran à la main, en reliant chaque zone à un segment, est suffisamment fastidieux pour que la pratique s’arrête après le premier sprint.

Deux choses rendent cela viable.

La détection automatique par OCR. Plutôt que de dessiner une boîte autour de chaque chaîne, lancez une détection de texte sur toute la capture d’écran et laissez-la proposer des annotations. Dans WebTranslateIt, cela fonctionne sur l’image entière ou sur une région que vous sélectionnez ; le texte détecté apparaît comme des annotations provisoires, et cliquer sur l’une d’elles ouvre une recherche de segment pré-remplie avec le texte détecté. Confirmez les correspondances, écartez le reste. Ce qui prenait autrefois un après-midi devient quelques minutes par écran.

Capturer au bon moment. Les captures d’écran prises au moment où la fonctionnalité est construite sont peu coûteuses. Les captures d’écran prises six mois plus tard demandent à quelqu’un de reconstruire l’état qui produit cet écran, ce qui explique que cela n’arrive jamais. Si votre suite de tests affiche déjà les écrans, elle peut en sauvegarder les images.

Que prioriser#

Vous n’avez pas besoin de capturer chaque écran. Classé par valeur :

1. L’onboarding et l’inscription. Trafic le plus élevé, enjeux les plus élevés, le plus susceptible d’être vu par un utilisateur qui décide de rester ou non.
2. Les écrans denses en chaînes courtes. Navigation, réglages, barres d’outils — là où l’ambiguïté se concentre.
3. Tout ce qui a une mise en page contrainte. Boutons à largeur fixe, écrans mobiles, tableaux.
4. Les états d’erreur et les états vides. Fréquemment oubliés, vus au pire moment, et souvent écrits à la hâte.
5. Tout le reste, éventuellement, si cela le justifie.

Le contenu long a le moins besoin de captures d’écran — il porte son propre contexte.

Les commentaires de développeur : la moitié économique#

Les captures d’écran sont l’option à forte valeur ; les commentaires sont l’option économique, et les deux sont complémentaires. Un bon commentaire répond à ce que la capture d’écran ne peut pas :

✗ "Texte du bouton"
✓ "Verbe. Bouton de validation dans le dialogue d’invitation. Max 18 caractères."

✗ "Placeholder %{name}"
✓ "%{name} est uniquement le prénom de la personne invitée."

✗ "Erreur"
✓ "Affiché quand une carte est refusée. Reste non culpabilisant — l’utilisateur n’a peut-être rien fait de mal."

Le principe : dites ce que le traducteur ne peut pas voir. Nature grammaticale, ce qu’un placeholder contient à l’exécution, limites de longueur, ton.

L’économie de la chose est particulièrement claire. Un commentaire coûte à un développeur environ quinze secondes au moment où il crée la chaîne, quand le contexte est déjà dans sa tête. Le reconstruire plus tard coûte une question à un traducteur, un changement de contexte à un manager, une interruption à un développeur, et à tout le monde plusieurs jours de latence — multipliés par chaque langue, car sans un endroit partagé pour la réponse, chaque traducteur pose la question indépendamment.

Cette multiplication est le vrai argument en faveur de mettre le contexte dans l’outil plutôt que dans un fil de réponses : une réponse écrite une fois est visible par chaque traducteur, pour chaque langue, et aussi par les moteurs de traduction IA, qui lisent les commentaires de développeur comme du contexte.

Les captures d’écran comme relecture, pas seulement comme briefing#

Il existe un second usage que les équipes découvrent tard : montrer l’interface traduite au traducteur en retour.

Un traducteur qui n’a jamais vu que des chaînes dans une liste n’a aucun moyen de savoir que son libellé allemand a dépassé son bouton, que deux de ses choix se retrouvent côte à côte et se lisent de façon incohérente, ou qu’une phrase qu’il a traduite comme un fragment est en fait un titre. Afficher les écrans localisés et les mettre devant la personne qui les a écrits détecte ces trois problèmes, et les détecte par la seule personne qualifiée pour juger de la correction.

C’est peu coûteux si votre suite de tests affiche déjà les écrans — capturez-les par locale et joignez-les. C’est l’équivalent, en localisation, de relire le diff de sa propre pull request avant de demander une review, et cela révèle la même catégorie de problèmes gênants et évidents.

Le principe général derrière ces deux usages : plus un traducteur est éloigné du produit en fonctionnement, plus il devine. Chaque étape qui réduit cette distance se rembourse elle-même, et les captures d’écran sont l’étape la moins coûteuse disponible.

Une politique qui fonctionne#

• Les commentaires font partie de l’écriture de la chaîne, pas d’une tâche de suivi. Imposez-le en code review de la même façon qu’un test manquant.
• Les captures d’écran sont mises en ligne quand la fonctionnalité est construite, depuis la suite de tests si possible.
• Les questions sont répondues dans l’outil, jamais en messages directs, afin que la réponse soit visible par tout le monde et survive à la personne qui l’a posée.
• Les instructions au niveau du projet couvrent les décisions qui s’appliquent partout — formalité, ton, voix de marque — afin qu’elles ne soient pas rediscutées à chaque chaîne.

Rien de tout cela ne rend la traduction plus rapide dans l’instant. Cela la rend correcte du premier coup, ce qui est la seule version de la rapidité qui compte.

Une mesure vaut la peine d’être prise si vous voulez justifier l’effort : comptez les questions que posent vos traducteurs, et combien d’entre elles trouveraient leur réponse dans une capture d’écran. Dans la plupart des équipes qui n’ont jamais fourni de contexte, c’est la majorité — est-ce un bouton ou un titre, combien de place y a-t-il, que contient ce placeholder. Chacune est un aller-retour qui coûte des jours de latence dans chaque langue, et chacune est une question que le traducteur n’aurait jamais dû avoir besoin de poser.