Que deviennent les tableaux lors de la traduction de documents ?

Un tableau peut conserver toutes ses lignes et colonnes tout en devenant incorrect après traduction. Un texte plus long, des retours à la ligne différents, un contenu de droite à gauche, des nombres localisés et la perte des métadonnées d’en-tête peuvent transformer une grille apparemment intacte en information trompeuse.

Que change la traduction d’un tableau ?

Un tableau de document comporte trois couches, qui doivent chacune être vérifiées séparément :

Couche	Résultat attendu	Problèmes possibles
Contenu	Les titres, libellés, notes et textes sont traduits	Du texte est omis, dupliqué, mal traduit ou laissé dans la langue source
Structure	Les lignes, colonnes, cellules fusionnées et relations d’en-tête restent liées	Une conversion divise des cellules, modifie leur portée ou perd des métadonnées structurelles
Présentation	Les bordures, remplissages, polices, largeurs et alignements restent utilisables	Le texte passe à la ligne, est tronqué, rétréci ou superposé, ou repousse le tableau sur une autre page

La traduction ne doit pas reconstruire le tableau de zéro. Un processus tenant compte du format du document peut préserver sa structure et son style, mais cela ne signifie pas que chaque cellule occupera ensuite le même espace.

Le W3C indique que la longueur d’un texte traduit est susceptible de varier et recommande des mises en page flexibles plutôt que des conteneurs étroits à largeur fixe. Ce point est particulièrement important dans les tableaux, car les titres courts sont souvent placés dans les cellules les plus exiguës. Ses exemples montrent également qu’un mot composé allemand peut offrir moins de points de césure naturels que son équivalent anglais, tandis que certaines écritures non latines nécessitent des caractères plus larges ou une hauteur de ligne supérieure.

Pour une explication plus complète de ces effets, consultez pourquoi les documents traduits deviennent plus longs.

Quels éléments d’un tableau résistent généralement à la traduction ?

Lorsqu’un fichier source modifiable est traduit avec un outil qui tient compte du format, les éléments suivants peuvent être repris dans le résultat. Aucun ne doit être considéré comme correct sans vérification.

Élément	Résultat attendu	Question à se poser
Lignes et colonnes	La même grille logique	Des lignes, colonnes ou cellules manquent-elles ou sont-elles dupliquées ?
Bordures et remplissages	Le même regroupement visuel	Les couleurs et les bordures communiquent-elles toujours les catégories prévues ?
Cellules fusionnées	La même portée sur les lignes ou colonnes	Chaque titre couvre-t-il toujours les bonnes données ?
Lignes d’en-tête	Les mêmes libellés et le même comportement de répétition	L’en-tête reste-t-il associé aux bonnes colonnes et se répète-t-il sur plusieurs pages ?
Styles de cellule	Les mêmes police, emphase, marges internes et alignement	Un remplacement de police ou un ajustement automatique a-t-il rendu une cellule illisible ?
Nombres et formules	Les mêmes valeurs et la même logique sous-jacentes	Un signe, séparateur, unité, formule ou référence a-t-il changé ?
Notes et liens	La même destination et la même association	Chaque note ou lien appartient-il toujours à la bonne cellule ?

La conversion de format constitue un risque distinct. Les recommandations du W3C sur l’accessibilité des tableaux avertissent que le balisage structurel est souvent perdu lorsque le contenu passe d’un format à un autre. Un tableau peut donc sembler correct tout en n’exposant plus aux technologies d’assistance les relations entre ses en-têtes et ses données.

Cinq problèmes courants dans les tableaux et leurs solutions

1. Le texte déborde ou rend les lignes trop hautes

Les libellés traduits peuvent être plus longs, contenir des caractères plus larges ou se couper à des endroits différents. Une hauteur de ligne fixe peut tronquer la dernière ligne ; à l’inverse, l’agrandissement automatique peut repousser le tableau au-delà d’un saut de page.

Corrigez le problème dans cet ordre : supprimez les retours à la ligne manuels, autorisez l’agrandissement des lignes, élargissez la colonne la plus contrainte, réduisez les marges internes superflues et activez la césure adaptée à la langue cible si nécessaire. Ne raccourcissez le texte qu’après confirmation par un réviseur linguistique qu’aucun sens n’est perdu. Réduisez la taille de la police en dernier recours.

Si l’écriture cible affiche des carrés, des lettres détachées ou des polices inattendues, considérez qu’il s’agit d’un problème de police plutôt que de débordement. Suivez les vérifications décrites dans pourquoi les polices ne fonctionnent plus après traduction.

2. Les cellules fusionnées ne décrivent plus les bonnes données

Dans le document source, un en-tête fusionné peut couvrir trois colonnes de produits. Si une ligne ou une colonne est insérée, supprimée ou décalée pendant la conversion, cet en-tête peut apparaître au-dessus du mauvais groupe, même si les mots sont correctement traduits.

Corrigez le problème en comparant les portées avec la source. Reliez chaque en-tête couvrant plusieurs lignes ou colonnes aux cellules qu’il gouverne. N’ajoutez pas de nouvelles cellules fusionnées simplement pour faire tenir un libellé traduit ; ajustez plutôt la largeur ou le renvoi à la ligne.

Microsoft recommande des tableaux rectangulaires simples pour des raisons d’accessibilité, car les cellules divisées ou fusionnées, les tableaux imbriqués et les lignes ou colonnes vides peuvent empêcher les lecteurs d’écran de compter et d’identifier correctement les cellules. Lorsque des portées complexes sont nécessaires, une inspection visuelle ne suffit pas.

3. Les en-têtes perdent leur relation avec les cellules de données

Pour un lecteur voyant, du texte en gras sur la première ligne ressemble à un en-tête, mais l’apparence ne définit pas la structure. Les recommandations du W3C exigent que les cellules d’en-tête et de données soient identifiées et associées afin que les technologies d’assistance puissent annoncer le contexte pertinent de ligne et de colonne.

Corrigez le problème en rétablissant des en-têtes sémantiques dans le document modifiable. Définissez la première ligne comme en-tête, vérifiez que les en-têtes se répètent dans les tableaux sur plusieurs pages et testez les tableaux complexes avec le vérificateur d’accessibilité de l’application. Dans le fichier HTML ou PDF exporté, assurez-vous que les associations d’en-têtes ont résisté à la conversion.

4. Les nombres, formules et identifiants changent discrètement

Une phrase fluide est facile à remarquer ; la modification d’un séparateur décimal, d’un signe moins, d’un pourcentage, d’un numéro de modèle ou d’une référence de feuille de calcul l’est beaucoup moins. Certaines valeurs doivent être localisées pour les lecteurs, tandis que les identifiants et la logique de calcul doivent rester strictement identiques.

Corrigez le problème avec une passe de comparaison réservée aux données. Ignorez le texte et comparez les chiffres, codes monétaires, signes de pourcentage, unités, plages, totaux, formules, appels de note et références de cellule. Recalculez les formules et les totaux des feuilles de calcul dans le fichier cible. Consignez les adaptations locales volontaires afin que les réviseurs ne les « corrigent » pas en rétablissant le format source.

5. Le texte de droite à gauche perturbe la ponctuation ou l’alignement

L’arabe et l’hébreu se lisent de droite à gauche, mais les termes latins et les chiffres qu’ils contiennent restent orientés de gauche à droite. Unicode considère donc qu’il s’agit de texte bidirectionnel. Il précise également que les cellules distinctes d’un tableau peuvent être traitées comme des paragraphes distincts, ce qui permet de définir le sens d’écriture au niveau de la cellule ou du paragraphe.

Corrigez le problème cellule par cellule. Définissez le sens de base approprié, puis examinez les codes produits, dates, pourcentages, parenthèses, barres obliques et signes de ponctuation à côté du texte latin. N’inversez jamais les chiffres manuellement. Vérifiez à la fois le document modifiable et le PDF exporté, car le sens d’écriture et l’effet miroir dépendent du rendu.

Liste de contrôle avant traduction

• Partez du fichier DOCX, PPTX ou XLSX modifiable lorsqu’il est disponible.
• Supprimez les lignes et colonnes vides qui servent uniquement à créer des espacements.
• Remplacez si possible les tableaux de mise en page par une mise en page normale du document.
• Identifiez les véritables lignes d’en-tête et conservez une structure aussi simple que les données le permettent.
• Autorisez l’agrandissement des lignes ; évitez les hauteurs fixes pour les cellules à traduire.
• Repérez les cellules fusionnées, formules, totaux, identifiants protégés et termes à ne pas traduire.
• Définissez correctement la langue source et consignez les paramètres régionaux cibles.
• Enregistrez un PDF de référence afin que les réviseurs sachent à quoi ressemblait la source approuvée.

Ces étapes réduisent les ambiguïtés avant qu’un outil ou un traducteur ne touche au fichier. Elles permettent aussi de déterminer plus facilement si un problème ultérieur provient de la traduction, de la conversion ou de la conception du tableau d’origine.

Comment vérifier le tableau traduit

Procédez par passes distinctes. Vérifier simultanément la langue, les données, la structure et la mise en page facilite l’oubli de petites erreurs.

1. Comparez la grille. Comptez les tableaux, lignes, colonnes, zones fusionnées, lignes d’en-tête et notes par rapport à la source.
2. Comparez le contenu. Vérifiez que chaque cellule a été traduite une seule fois et reste sous le bon en-tête.
3. Comparez les données. Vérifiez les nombres, signes, unités, formules, totaux, identifiants et liens sans modifier le texte.
4. Inspectez la mise en page. Recherchez les coupures, les lignes excessivement hautes, les sauts de page mal placés, le texte minuscule dû à l’ajustement automatique, les polices de secours et les alignements irréguliers.
5. Vérifiez le sens d’écriture et l’accessibilité. Contrôlez les cellules RTL, les associations d’en-têtes, l’ordre de lecture et la répétition des en-têtes.
6. Exportez et inspectez de nouveau. Ouvrez le PDF livré ou tout autre format final ; ne validez pas uniquement le fichier source modifiable.

OpenL Doc Translator prend en charge des formats de documents tels que PDF, DOCX, PPTX et XLSX. Sa page officielle indique que les polices, couleurs, tableaux et mises en page sont préservés, et que chaque tâche fournit une version traduite et une version bilingue. Utilisez si possible la source modifiable, prévisualisez le résultat, puis comparez la version bilingue avant d’effectuer la vérification structurée ci-dessus.

La préservation du format réduit le travail de reconstruction, mais ne dispense pas du contrôle qualité. La liste de contrôle pour la révision des documents bilingues couvre le reste du document une fois la vérification des tableaux terminée.

Quand une révision manuelle est indispensable

Confiez toujours le tableau à un réviseur humain lorsqu’il contient :

• Des totaux financiers, taux, prévisions ou chiffres audités
• Des obligations juridiques, seuils de conformité, dosages ou données de sécurité
• Des formules, références entre feuilles ou champs calculés
• Des en-têtes à plusieurs niveaux, zones fusionnées ou tableaux imbriqués
• Des cellules numérisées ou constituées d’images qui dépendent de l’OCR
• Du texte combinant une orientation de droite à gauche et de gauche à droite
• Une mise en page d’impression fixe sans espace d’expansion

Pour ces tableaux, « le fichier s’est ouvert » et « le tableau semble similaire » ne sont pas des critères d’acceptation. La validation exige de faire correspondre la structure source, de vérifier le sens dans la langue cible, de contrôler chaque valeur critique et de tester le format de livraison final.

Une traduction de tableau réussie préserve les relations, pas seulement les rectangles. Vérifiez séparément le contenu, la structure, les données, la mise en page, le sens d’écriture et l’accessibilité afin qu’un défaut de formatage ait beaucoup moins de risques de devenir une erreur de données.

Sources

• W3C: Text size in translation - Explains text expansion, constrained layouts, compound words, character width, and line-height differences across languages.
• W3C WAI: Tables Tutorial - Explains header-to-data relationships, complex table markup, screen-reader context, and metadata loss during format conversion.
• Microsoft Support: Make your Word documents accessible to people with disabilities - Recommends simple tables, header rows, accessibility checks, and avoiding split, merged, nested, or blank structures where possible.
• Unicode Standard Annex #9: Unicode Bidirectional Algorithm - Defines display ordering for mixed right-to-left and left-to-right text, digits, punctuation, and direction at paragraph or table-cell level.
• OpenL Doc Translator - Lists supported document formats, formatting preservation, free preview, and bilingual review output.