Comment traduire un gros fichier TXT : encodage, chapitres et sauts de ligne

Pour traduire un gros fichier TXT, préparez trois choses avant de le téléverser où que ce soit. Premièrement, assurez-vous que le texte est décodé correctement et enregistrez-le en UTF-8. Deuxièmement, placez chaque titre de chapitre sur sa propre ligne, entouré d'une ligne vide. Troisièmement, si le fichier coupe les lignes à une largeur fixe, joignez ces lignes pour que chaque paragraphe tienne sur une seule ligne, avec une ligne vide entre les paragraphes. Traduisez ensuite le fichier entier, puis comparez le nombre de paragraphes et de chapitres entre la source et la traduction.

Un fichier texte brut n'a ni styles, ni titres, ni métadonnées. Tout ce qu'un outil de traduction sait de sa structure provient des octets et des sauts de ligne. C'est pourquoi les trois mêmes problèmes reviennent sans cesse : les octets sont lus dans le mauvais encodage, les chapitres sont impossibles à distinguer des lignes ordinaires, ou les sauts de ligne n'indiquent pas où se termine une phrase.

Nous avons créé des fichiers d'exemple dans quatre encodages, écrit un vérificateur gratuit et traduit neuf fois une nouvelle à retour à la ligne forcé en chinois simplifié avec un modèle local. Le modèle a très bien géré le retour à la ligne forcé lorsqu'il voyait le fichier entier. Il a coupé des phrases et attribué l'action d'un personnage à un autre dans les trois exécutions où le fichier était découpé en morceaux selon le nombre de lignes.

Liste de vérification rapide

Le vérificateur rend compte de chaque ligne et corrige l'encodage, la marque d'ordre des octets, les fins de ligne et les retours à la ligne forcés. Les titres de chapitres et les lignes vides manquantes sont à corriger manuellement. Exécutez python3 check_txt.py inspect yourfile.txt pour voir le rapport, et python3 check_txt.py convert yourfile.txt clean.txt --unwrap pour écrire une copie UTF-8 avec les paragraphes joints. Il ne nécessite que Python 3 et ne modifie jamais le fichier d'origine.

Étape 1 : Bien déterminer l'encodage

Un fichier TXT est une suite d'octets. L'encodage est la règle qui transforme ces octets en caractères, et le fichier ne précise pas quelle règle a été utilisée. Si un programme se trompe, vous obtenez du mojibake : du texte brouillé ou, pire, du texte qui semble correct mais qui ne correspond pas à ce qui a été écrit.

Voici la même phrase chinoise, 最后一班渡轮 (« le dernier ferry »), lue avec la mauvaise règle. Nous les avons générées avec les codecs intégrés à Python, et vous pouvez les reproduire avec les fichiers d'exemple.

La dernière ligne est la plus dangereuse. Des octets japonais lus comme du chinois produisent de vrais caractères chinois, sans erreur ni �. Un outil de traduction les traduira volontiers, et le résultat sera un non-sens à la grammaire parfaite.

Notre vérificateur montre pourquoi vous ne pouvez pas vous fier à « il s'est ouvert sans erreur ». Lorsque nous l'avons exécuté sur l'échantillon Shift_JIS, deux encodages ont décodé tout le fichier sans la moindre erreur :

encoding: unknown (not UTF-8)
these legacy encodings decode without errors; read the previews,
because a wrong one can still produce real-looking characters:
  gb18030  戞堦榖丂嵟屻偺僼僃儕乕
  cp932    第一話　最後のフェリー

Seule la deuxième ligne est du japonais. La première est une suite de caractères chinois rares que personne n'a écrits. Sur l'échantillon chinois GB18030, cinq encodages ont décodé sans erreur, et un seul, GB18030, a affiché le titre de chapitre 第一章 最后一班渡轮. La règle est donc simple : déterminez l'encodage en lisant les premières lignes, pas en vous demandant si un programme a signalé une erreur.

Là où les suppositions se trompent généralement :

• Le texte chinois provenant d'anciens systèmes Windows ou de sites chinois est souvent en GBK ou GB18030. GB18030 couvre tout ce que GBK couvre, et la norme d'encodage WHATWG, que les navigateurs suivent, va plus loin : elle déclare que « le décodeur de GBK est le décodeur de gb18030 ». Si un fichier est en GBK, l'ouvrir en GB18030 fonctionne.
• Le chinois traditionnel de Taïwan ou de Hong Kong est souvent en Big5.
• Le japonais est souvent en Shift_JIS, ou dans la version étendue de Microsoft, que Windows et Python appellent cp932.
• Le coréen est souvent en EUC-KR.
• Un fichier rempli d'octets NUL, ou un fichier où un caractère sur deux semble vide, est généralement en UTF-16 sans marque d'ordre des octets.

Une marque d'ordre des octets (BOM) est un court code invisible au début d'un fichier qui annonce UTF-8, UTF-16 ou UTF-32. Lorsqu'elle est présente, faites-lui confiance. La même norme déclare que « la marque d'ordre des octets est plus fiable que tout le reste ». Notre vérificateur lit d'abord la BOM et ne devine que lorsqu'il n'y en a pas.

Enregistrez le fichier en UTF-8

Une fois que le texte se lit correctement, enregistrez-le en UTF-8. La norme WHATWG qualifie UTF-8 de « l'encodage le plus approprié pour l'échange d'Unicode », et c'est le choix le plus sûr pour tout outil de traduction.

Il y a une seconde raison qui compte particulièrement pour la traduction. Les encodages hérités ne couvrent que les caractères de leur propre région. Shift_JIS n'a pas de code pour 这, le premier caractère de 这是最后一班渡轮, et Big5 n'en a pas non plus, car il s'agit d'un caractère chinois simplifié. Windows-1252 ne peut pas stocker le cyrillique. Si le fichier traduit doit être réécrit dans l'encodage hérité d'origine, la langue cible risque de ne pas tenir. Le traducteur TXT de BookTranslator indique qu'il détecte automatiquement les encodages courants et renvoie le fichier traduit « avec le même encodage que l'entrée », donc partir de l'UTF-8 élimine complètement la question.

Vous pouvez convertir dans un éditeur de texte (ouvrez avec le bon encodage, puis « Enregistrer sous » en UTF-8), avec iconv -f GB18030 -t UTF-8 in.txt > out.txt sur macOS ou Linux, ou avec le vérificateur :

python3 check_txt.py convert book.txt book-utf8.txt --encoding gb18030

Si le fichier contient déjà des caractères �, les dégâts ont eu lieu avant que vous ne l'obteniez. Une nouvelle conversion ne restaurera pas les caractères manquants. Cherchez une meilleure copie de la source.

Étape 2 : Rendez les chapitres faciles à trouver

Les chapitres comptent pour trois raisons. Un long fichier est traduit par morceaux, et les sauts de chapitre sont les endroits les plus propres pour couper. Vous voudrez vérifier chaque chapitre après traduction. Et si vous transformez ensuite le texte en ebook, les titres de chapitre deviennent la table des matières.

Placez chaque titre sur sa propre ligne, avec une ligne vide avant et après, et utilisez un seul modèle dans tout le livre. Voici les modèles que notre vérificateur compte :

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• un nombre ou un chiffre romain seul sur une ligne, comme 12 ou XII.

Lancez inspect et lisez la liste des titres trouvés. Si le livre a 40 chapitres et que le vérificateur en trouve 37, trois titres se cachent : l'un se fond dans la première phrase, un autre utilise un mot différent comme « Ch. 7 », ou un autre a du texte sur la même ligne. Corrigez ces trois-là à la main. Cela prend moins de temps que de trouver le problème dans un fichier traduit.

Étape 3 : Défaites les sauts de ligne forcés, avec précaution

Certains fichiers TXT coupent chaque ligne à une largeur fixe, pour que le texte tienne dans un terminal simple ou une fenêtre étroite. Le texte copié depuis des PDF et les sorties d'OCR font la même chose à la largeur de la page imprimée. Dans ces fichiers, un saut de ligne signifie « la ligne était pleine », et non « la phrase ou le paragraphe se terminait ».

Le retour à la ligne forcé est facile à repérer. Dans notre échantillon à lignes forcées, le vérificateur a signalé :

non-empty lines: 43; longest line: 66 chars; 25 lines within 12 chars of the longest
line breaks inside paragraphs that do not end a sentence: 23
looks hard-wrapped: consider convert --unwrap

La solution consiste à joindre les lignes à l'intérieur de chaque paragraphe et à conserver les lignes vides entre les paragraphes. Le piège, ce sont les textes dont les sauts de ligne sont réels : vers, paroles de chansons, lettres, adresses, recettes et listes. Notre échantillon comprend une lettre de cinq lignes :

My dear Mara,
The key is under the blue pot.
Do not let your uncle sell the boat.
With love, always,
Nonna

Un « remplacer chaque saut de ligne par un espace » brutal transforme cela en une seule ligne continue. L'option --unwrap du vérificateur ne joint un paragraphe que lorsque la plupart de ses lignes approchent de la largeur totale, de sorte que les blocs à lignes courtes comme cette lettre sont laissés intacts. Sur notre échantillon, il a reconstruit exactement le fichier original non déroulé, octet pour octet, lettre incluse. Sur votre propre fichier, vérifiez quelques paragraphes joints et chaque bloc de vers avant de lui faire confiance.

Deux autres détails. Lorsque vous joignez des lignes de texte chinois ou japonais, n'ajoutez pas d'espace entre elles ; le vérificateur joint les lignes CJK, y compris celles qui se terminent par une ponctuation CJK, sans espace. Et si votre texte provient d'OCR, les mots peuvent aussi être coupés par des traits d'union en fin de ligne, ce qui demande ses propres décisions. Notre guide pour corriger les sauts de ligne et les césures d'OCR traite de ce sujet.

Ce que nous avons testé : texte à lignes forcées, entier vs découpé

Nous voulions savoir si le retour à la ligne forcé nuit réellement à la traduction, ou s'il ne fait que paraître désordonné. Nous avons écrit une nouvelle de 396 mots pour le test : trois chapitres, quinze paragraphes, des dialogues, la lettre ci-dessus et une rupture de scène * * *. Nous l'avons enregistrée deux fois avec les mêmes mots : sans retour à la ligne, avec un paragraphe par ligne, et avec retour à la ligne forcé à 66 caractères, qui compte 43 lignes non vides au lieu de 19.

Nous avons ensuite demandé à un modèle local de la traduire en chinois simplifié de trois manières, avec trois exécutions chacune :

1. Avec retour à la ligne, fichier entier. Le fichier avec retour à la ligne forcé en une seule requête.
2. Sans retour à la ligne, fichier entier. Le fichier sans retour à la ligne en une seule requête.
3. Avec retour à la ligne, découpé toutes les 12 lignes. Le fichier avec retour à la ligne forcé découpé toutes les 12 lignes, une requête par morceau, les réponses recollées ensemble. C'est ce qui se passe lorsqu'un script ou un outil découpe un long fichier par nombre de lignes plutôt que par paragraphe.

Le modèle était Qwen 3.6 27B (Q4_K_M) dans LM Studio, avec la réflexion désactivée et une température de 0,3, sur un Apple M4 Max avec 64 Go de mémoire. Chaque requête utilisait le même prompt d'une phrase. Nous l'avons exécuté le 28 octobre 2026. Le script est run_llm_txt_test.py, les neuf sorties sont publiées sans modification, et results.csv contient une ligne par exécution.

La première constatation nous a surpris. Lorsque le modèle a vu le fichier entier avec des retours à la ligne forcés, il a joint les lignes de lui-même. Les trois sorties comportaient un paragraphe par ligne, les mêmes 19 lignes que les exécutions sans retour à la ligne forcé, et se lisaient tout aussi bien. Ainsi, le retour à la ligne forcé seul n'a pas pénalisé ce modèle sur ce fichier court.

Découper le fichier selon le nombre de lignes a en revanche fait des dégâts, aux mêmes endroits à chaque fois. Trois des pièces de 12 lignes se terminaient au milieu d'une phrase. La première s'arrête à « He pointed with his » et la pièce suivante commence par « pen at a three-storey building on the corner. » Traduite séparément, la seconde moitié a perdu son sujet. Dans deux exécutions, elle est revenue sous la forme 她瞥了一眼街角那栋三层楼的建筑, « elle jeta un coup d'œil au bâtiment de trois étages au coin de la rue. » Dans la troisième, elle se terminait par 随后她重新回到填字游戏上, « puis elle retourna à ses mots croisés. » Dans l'histoire, l'homme du guichet pointe du doigt et retourne à ses mots croisés. Dans les trois exécutions, un lecteur du chinois penserait que c'est Mara qui l'a fait.

La deuxième coupure, entre « the careful, slightly old-fashioned hand she had learned at a » et « convent school, », a laissé la phrase chinoise en suspens à 那是她在, « c'était là qu'elle », dans les trois exécutions (une exécution a ajouté un 一 parasite), et le mot « learned » a disparu. La troisième coupure a scindé la phrase sur les volets sur deux lignes, et la seconde moitié a transformé « painted, not well, but not long ago » en peinture écaillée : 油漆虽已斑驳 dans deux exécutions et 油漆剥落 dans la troisième. Et comme les pièces étaient jointes par un simple saut de ligne, la ligne vide avant la rupture de scène a disparu, ce qui explique que chaque exécution comptait 14 paragraphes au lieu de 15. Notre vérificateur a détecté le nombre de paragraphes. Il n'a pas pu détecter le mauvais personnage ; nous l'avons trouvé en lisant.

Ce que cela signifie pour votre fichier :

• Le déroulement des lignes vous protège des découpeurs que vous ne contrôlez pas. Tout fichier long est découpé quelque part, que ce soit par votre propre script, la limite d'une fenêtre de chat ou l'outil vers lequel vous téléversez. Si les paragraphes sont des lignes uniques séparées par des lignes vides, tout découpeur raisonnable peut couper entre les paragraphes plutôt qu'à l'intérieur d'une phrase.
• Les pires erreurs étaient fluides. « Elle jeta un coup d'œil au bâtiment » est un bon chinois. Un lecteur remarquerait les sauts de ligne étranges à chaque coupure et le 那是她在 en suspens, mais rien ne signale le mauvais personnage ou la peinture écaillée comme des erreurs. Les erreurs aux points de coupure sont d'abord des erreurs de sens, ensuite des erreurs de formatage.
• Il s'agissait d'un seul modèle et d'une seule nouvelle courte. Un fichier aussi court tient dans une seule requête, donc les exécutions sur fichier entier n'ont jamais eu à découper quoi que ce soit. Un roman complet doit être découpé, et c'est précisément là que la préparation des étapes 1 à 3 porte ses fruits. Ces fichiers testent la préparation et le découpage, pas le pipeline propre à BookTranslator.

Une observation plus mineure : sur les six exécutions sur fichier entier, le modèle a écrit le nom de Mara sous la forme 玛拉 dans cinq cas et 马拉 dans un cas. Chaque sortie était cohérente avec elle-même, mais des requêtes séparées ne concordaient pas entre elles. Pour un long livre traduit en plusieurs morceaux, une liste de noms et de leurs graphies convenues maintient chaque chapitre en accord. Notre guide des glossaires montre comment en construire un.

Étape 4 : Traduire, puis vérifier les comptages

Lorsque le fichier est propre, le traduire est la partie facile. Vous pouvez le téléverser sur le traducteur TXT de BookTranslator, qui accepte les fichiers .txt, .md et .mdx, indique qu'il gère les fichiers TXT jusqu'à 300 Mo et affiche le prix avant le paiement. Il n'y a pas de traduction complète gratuite, mais le téléversement lui-même vous indique le coût. Si vous préférez travailler avec un modèle de chat ou un LLM local, découpez vous-même le fichier aux limites des chapitres ou des paragraphes et conservez un glossaire pour les noms. Si votre texte est du Markdown plutôt que de la prose simple, consultez notre guide de traduction Markdown, car la syntaxe Markdown nécessite ses propres règles.

Après la traduction, comparez les deux fichiers :

python3 check_txt.py compare book-utf8.txt book-translated.txt

Si l'un ou l'autre fichier n'est pas en UTF-8, ajoutez --source-encoding ou --translated-encoding. La vérification des chapitres connaît les motifs de titres en anglais et en chinois/japonais ; pour d'autres langues cibles, ajoutez le mot local pour « chapitre » au motif en haut du script.

Voici le rapport pour l'une de nos exécutions avec découpage :

                            source  translated
paragraphs                      15          14  <- differs
chapter headings                 3           3
non-empty lines                 43          24  <- differs
scene breaks (* * *)             1           1
replacement chars                0           0
source script LATIN characters left in translation: 0

Lisez-le ainsi :

• Les paragraphes et les titres de chapitres doivent correspondre. Un paragraphe manquant signifie souvent que deux ont été fusionnés ou qu'un a été supprimé.
• Les lignes non vides peuvent différer pour une bonne raison. Nos exécutions avec retour à la ligne forcé sur fichier entier sont passées de 43 lignes à 19 parce que le modèle a joint les lignes à retour forcé, ce qui était une amélioration. Ne comparez les lignes que lorsque la source était déjà déroulée.
• Les caractères de l'écriture source restants indiquent des passages qui n'ont pas été traduits du tout. Quelques-uns sont normaux pour des noms, des termes de produits ou des citations ; une série de tels caractères indique une section sautée.
• Les caractères de remplacement dans la traduction signifient un problème d'encodage à la sortie.

Les comptages ne peuvent pas vous dire si la traduction est correcte. Lisez le premier et le dernier paragraphe de chaque chapitre, ainsi que les paragraphes de part et d'autre de chaque endroit où le fichier a été découpé. C'est là que notre test a trouvé toutes les erreurs graves.

Questions fréquentes

Pourquoi mon fichier TXT semble-t-il correct dans un programme et illisible dans un autre ?

Les deux programmes ont deviné des encodages différents. L'un a deviné juste. Trouvez l'encodage qui affiche le texte correctement, puis enregistrez le fichier en UTF-8 pour que tous les programmes le lisent de la même manière.

Dois-je convertir un fichier TXT en EPUB ou DOCX avant de le traduire ?

Uniquement si vous voulez ce que ces formats apportent en plus. Un fichier TXT propre avec des chapitres clairs se traduit très bien tel quel. Si vous souhaitez une table des matières, une navigation par chapitres et un ebook lisible sur un appareil, notre guide pour transformer un roman web en EPUB prêt à la traduction vous explique comment faire.

Puis-je traduire un fichier TXT contenant plusieurs langues ?

Oui, mais indiquez au traducteur ce qu'il doit laisser intact. Les citations ou termes dans une troisième langue, ainsi que les noms qui doivent rester dans leur écriture d'origine, sont plus faciles à protéger avec un glossaire ou une courte consigne qu'à corriger après coup.

Et pour un fichier TXT téléchargé depuis un site web ?

Vérifiez que vous avez le droit de l'utiliser. Pour les livres du domaine public ou les fichiers que vous avez écrits vous-même, les étapes ci-dessus s'appliquent. L'encodage ou le format d'un fichier ne vous dit rien sur son statut de droit d'auteur.