Como traduzir um ficheiro TXT grande: codificação, capítulos e quebras de linha

Para traduzir um ficheiro TXT grande, prepare três coisas antes de o carregar para qualquer lado. Primeiro, certifique-se de que o texto é descodificado corretamente e guarde-o como UTF-8. Segundo, coloque cada título de capítulo na sua própria linha, com uma linha em branco antes e depois. Terceiro, se o ficheiro quebra linhas a uma largura fixa, junte essas linhas para que cada parágrafo fique numa única linha, com uma linha em branco entre parágrafos. Depois, traduza o ficheiro completo e, em seguida, compare a contagem de parágrafos e de capítulos entre o original e a tradução.

Um ficheiro de texto simples não tem estilos, nem títulos, nem metadados. Tudo o que uma ferramenta de tradução sabe sobre a sua estrutura vem dos bytes e das quebras de linha. É por isso que os mesmos três problemas continuam a surgir: os bytes são lidos com a codificação errada, os capítulos não se distinguem das linhas normais, ou as quebras de linha não dizem nada sobre onde termina uma frase.

Criámos ficheiros de exemplo em quatro codificações, escrevemos um verificador gratuito e traduzimos um conto com quebras de linha forçadas para chinês simplificado nove vezes com um modelo local. O modelo lidou bem com as quebras forçadas quando viu o ficheiro completo. Partiu frases e atribuiu a ação de uma personagem a outra nas três execuções em que o ficheiro foi cortado em pedaços por contagem de linhas.

Lista de verificação rápida

O verificador analisa cada linha e corrige a codificação, a marca de ordem de bytes, os fins de linha e a quebra forçada de linhas. Os títulos dos capítulos e as linhas em branco em falta terá de os corrigir manualmente. Execute python3 check_txt.py inspect yourfile.txt para ver o relatório e python3 check_txt.py convert yourfile.txt clean.txt --unwrap para escrever uma cópia em UTF-8 com os parágrafos unidos. Só precisa de Python 3 e nunca altera o ficheiro original.

Passo 1: Acertar a codificação

Um ficheiro TXT é uma sequência de bytes. A codificação é a regra que transforma esses bytes em caracteres, e o ficheiro não indica qual foi a regra utilizada. Se um programa adivinhar mal, obtém mojibake: texto corrompido ou, pior ainda, texto que parece correto mas não é o que foi escrito.

Eis a mesma frase em chinês, 最后一班渡轮 («o último ferry»), lida com a regra errada. Gerámo-las com os codecs incorporados do Python, e pode reproduzi-las com os ficheiros de exemplo.

A última linha é a perigosa. Bytes japoneses lidos como chinês produzem caracteres chineses reais, sem erro e sem �. Uma ferramenta de tradução traduzi-los-á de bom grado, e o resultado será um disparate com boa gramática.

O nosso verificador mostra porque não pode confiar no critério «abriu sem erros». Quando o executámos na amostra Shift_JIS, duas codificações descodificaram o ficheiro inteiro sem um único erro:

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    第一話　最後のフェリー

Só a segunda linha é japonesa. A primeira é uma sequência de caracteres chineses raros que ninguém escreveu. Na amostra chinesa GB18030, cinco codificações descodificaram sem erros, e apenas uma delas, GB18030, mostrou o título do capítulo 第一章 最后一班渡轮. Portanto, a regra é simples: decida a codificação lendo as primeiras linhas, não por o programa se ter queixado.

Onde os palpites costumam falhar:

• Texto em chinês de sistemas Windows mais antigos ou de sites chineses costuma estar em GBK ou GB18030. O GB18030 abrange tudo o que o GBK abrange, e a Norma de Codificação WHATWG, seguida pelos navegadores, vai mais longe: afirma que «o descodificador do GBK é o descodificador do gb18030». Se um ficheiro estiver em GBK, abri-lo como GB18030 funciona.
• Chinês tradicional de Taiwan ou Hong Kong costuma estar em Big5.
• Japonês costuma estar em Shift_JIS, ou na versão alargada da Microsoft, que o Windows e o Python designam por cp932.
• Coreano costuma estar em EUC-KR.
• Um ficheiro cheio de bytes NUL, ou um em que todos os outros caracteres parecem vazios, é geralmente UTF-16 sem marca de ordem de bytes.

Uma marca de ordem de bytes (BOM) é um pequeno código invisível no início de um ficheiro que anuncia UTF-8, UTF-16 ou UTF-32. Quando existe, confie nela. A mesma norma afirma que «a marca de ordem de bytes tem mais autoridade do que qualquer outra coisa». O nosso verificador lê primeiro a BOM e só faz suposições quando não existe nenhuma.

Guarde o ficheiro como UTF-8

Assim que o texto for lido corretamente, guarde-o como UTF-8. A norma WHATWG chama ao UTF-8 «a codificação mais adequada para intercâmbio de Unicode», e é a escolha mais segura para qualquer ferramenta de tradução.

Há uma segunda razão que importa particularmente para a tradução. As codificações legadas só abrangem os caracteres da sua própria região. O Shift_JIS não tem código para 这, o primeiro caractere de 这是最后一班渡轮, e o Big5 também não, porque é um caractere chinês simplificado. O Windows-1252 não consegue armazenar cirílico. Se o ficheiro traduzido tiver de ser escrito de volta na codificação legada original, a língua de destino pode não caber. O tradutor de TXT do BookTranslator indica que deteta automaticamente codificações comuns e devolve o ficheiro traduzido «com a mesma codificação da entrada», pelo que começar em UTF-8 elimina completamente a questão.

Pode converter num editor de texto (abrir com a codificação correta e depois «Guardar como» UTF-8), com iconv -f GB18030 -t UTF-8 in.txt > out.txt no macOS ou Linux, ou com o verificador:

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

Se o ficheiro já contiver caracteres �, os danos ocorreram antes de o receber. Converter novamente não restaurará os caracteres em falta. Procure uma cópia melhor da fonte.

Passo 2: Torne os capítulos fáceis de encontrar

Os capítulos importam por três razões. Um ficheiro longo é traduzido em partes, e as quebras de capítulo são os locais mais limpos para cortar. Vai querer verificar cada capítulo após a tradução. E se mais tarde transformar o texto num ebook, os títulos dos capítulos tornam-se o índice.

Coloque cada título na sua própria linha, com uma linha em branco antes e depois, e use um padrão consistente ao longo de todo o livro. Estes são os padrões que o nosso verificador conta:

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• um número ou um numeral romano sozinho numa linha, como 12 ou XII.

Execute inspect e leia a lista de títulos encontrados. Se o livro tiver 40 capítulos e o verificador encontrar 37, três títulos estão escondidos: um junta-se à primeira frase, outro usa uma palavra diferente como «Cap. 7», ou outro tem texto na mesma linha. Corrija esses três manualmente. Leva menos tempo do que encontrar o problema num ficheiro traduzido.

Passo 3: Desfaça as quebras de linha forçadas, com cuidado

Alguns ficheiros TXT quebram cada linha a uma largura fixa, para que o texto caiba num terminal simples ou numa janela estreita. O texto copiado de PDFs e o resultado de OCR fazem o mesmo à largura da página impressa. Nestes ficheiros, uma quebra de linha significa «a linha estava cheia», não «a frase ou o parágrafo terminou».

As quebras forçadas são fáceis de detetar. No nosso exemplo com quebras forçadas, o verificador reportou:

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

A solução é juntar as linhas dentro de cada parágrafo e manter as linhas em branco entre parágrafos. A armadilha está no texto cujas quebras de linha são reais: poesia, letras de canções, cartas, endereços, receitas e listas. O nosso exemplo inclui uma carta de cinco linhas:

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

Uma substituição cega de «todas as quebras de linha simples por um espaço» transforma isso numa única linha corrida. O --unwrap do verificador só junta um parágrafo quando a maioria das suas linhas se aproxima da largura total, pelo que blocos de linhas curtas como esta carta ficam intactos. No nosso exemplo, reconstruiu o ficheiro original sem quebras exatamente, byte a byte, incluindo a carta. No seu próprio ficheiro, verifique alguns parágrafos unidos e todos os blocos de poesia antes de confiar no resultado.

Mais dois detalhes. Ao juntar linhas de texto chinês ou japonês, não adicione um espaço entre elas; o verificador junta linhas CJK, incluindo linhas que terminam em pontuação CJK, sem espaço. E se o seu texto veio de OCR, as palavras também podem estar divididas com hífenes no fim das linhas, o que exige decisões próprias. O nosso guia para corrigir quebras de linha e hifenização de OCR aborda esse assunto.

O que testámos: texto com quebras forçadas, inteiro vs. dividido

Queríamos saber se a quebra de linha forçada prejudica realmente a tradução ou se apenas parece desarrumada. Escrevemos um conto de 396 palavras para o teste: três capítulos, quinze parágrafos, diálogo, a carta acima e uma quebra de cena * * *. Guardámo-lo duas vezes com as mesmas palavras: sem quebras, com um parágrafo por linha, e com quebras forçadas aos 66 caracteres, que tem 43 linhas não vazias em vez de 19.

Depois pedimos a um modelo local que o traduzisse para chinês simplificado de três formas, com três execuções cada:

1. Com quebras, ficheiro completo. O ficheiro com quebras forçadas num único pedido.
2. Sem quebras, ficheiro completo. O ficheiro sem quebras num único pedido.
3. Com quebras, cortado a cada 12 linhas. O ficheiro com quebras forçadas dividido a cada 12 linhas, um pedido por parte, com as respostas reunidas novamente. É o que acontece quando um script ou ferramenta divide um ficheiro longo pelo número de linhas em vez de por parágrafos.

O modelo foi o Qwen 3.6 27B (Q4_K_M) no LM Studio, com o modo de raciocínio desativado e temperatura 0,3, num Apple M4 Max com 64 GB de memória. Todos os pedidos usaram o mesmo prompt de uma frase. Executámos o teste a 28 de outubro de 2026. O script é run_llm_txt_test.py, as nove saídas são publicadas sem edição e results.csv tem uma linha por execução.

A primeira descoberta surpreendeu-nos. Quando o modelo viu o ficheiro completo com quebras de linha forçadas, uniu as linhas por si próprio. As três saídas tinham um parágrafo por linha, as mesmas 19 linhas das execuções sem quebras forçadas, e liam-se igualmente bem. Portanto, as quebras de linha forçadas, por si só, não prejudicaram este modelo neste ficheiro curto.

Cortar o ficheiro pelo número de linhas prejudicou, nos mesmos locais todas as vezes. Três dos fragmentos de 12 linhas terminaram a meio de uma frase. O primeiro termina em «He pointed with his» e o fragmento seguinte começa com «pen at a three-storey building on the corner.» Traduzida separadamente, a segunda metade perdeu o sujeito. Em duas execuções, voltou como 她瞥了一眼街角那栋三层楼的建筑, «ela olhou de relance para o edifício de três andares na esquina». Na terceira, terminou com 随后她重新回到填字游戏上, «depois voltou às palavras cruzadas». Na história, o homem na bilheteira aponta e volta às suas palavras cruzadas. Nas três execuções, um leitor de chinês pensaria que foi a Mara que o fez.

O segundo corte, entre «the careful, slightly old-fashioned hand she had learned at a» e «convent school», deixou a frase chinesa suspensa em 那是她在, «foi ali que ela», nas três execuções (uma execução acrescentou um 一 perdido), e a palavra «learned» desapareceu. O terceiro corte dividiu a frase sobre as persianas em duas linhas, e a segunda metade transformou «painted, not well, but not long ago» em tinta a descascar: 油漆虽已斑驳 em duas execuções e 油漆剥落 na terceira. E, como os fragmentos foram unidos com uma única quebra de linha, a linha em branco antes da mudança de cena desapareceu, razão pela qual cada execução tinha 14 parágrafos em vez de 15. O nosso verificador detetou a contagem de parágrafos. Não conseguiu detetar o carácter errado; descobrimo-lo ao ler.

O que isto significa para o seu ficheiro:

• Desfazer as quebras de linha protege-o de divisores que não controla. Todo o ficheiro longo é dividido em algum ponto, quer pelo seu próprio script, pelo limite de uma janela de chat ou pela ferramenta para a qual carrega. Se os parágrafos forem linhas únicas separadas por linhas em branco, qualquer divisor razoável pode cortar entre parágrafos em vez de dentro de uma frase.
• Os piores erros eram fluentes. «Ela olhou de relance para o edifício» é bom chinês. Um leitor notaria as quebras de linha estranhas em cada corte e o 那是她在 suspenso, mas nada assinala o carácter errado ou a tinta a descascar como erros. Os erros nos pontos de divisão são primeiro erros de significado e só depois erros de formatação.
• Isto foi um modelo e um conto curto. Um ficheiro tão curto cabe num único pedido, pelo que as execuções com o ficheiro completo nunca tiveram de dividir nada. Um romance completo tem de ser dividido, e é exatamente aí que a preparação dos Passos 1 a 3 compensa. Estes ficheiros testam a preparação e a divisão, não o próprio pipeline do BookTranslator.

Uma observação menor: nas seis execuções com o ficheiro completo, o modelo escreveu o nome da Mara como 玛拉 em cinco e 马拉 numa. Cada saída era coerente consigo mesma, mas pedidos separados não concordavam entre si. Para um livro longo traduzido em muitos fragmentos, uma lista de nomes e as suas grafias acordadas mantém todos os capítulos alinhados. O nosso guia de glossários mostra como criar uma.

Passo 4: Traduzir e depois verificar as contagens

Quando o ficheiro está limpo, traduzi-lo é a parte fácil. Pode carregá-lo no tradutor de TXT do BookTranslator, que aceita ficheiros .txt, .md e .mdx, indica que processa ficheiros TXT até 300 MB e mostra o preço antes do pagamento. Não há tradução completa gratuita, mas o próprio carregamento indica-lhe o custo. Se preferir trabalhar com um modelo de chat ou um LLM local, divida o ficheiro nos limites de capítulos ou parágrafos e mantenha um glossário para os nomes. Se o seu texto for Markdown em vez de prosa simples, consulte o nosso guia de tradução de Markdown, porque a sintaxe Markdown tem regras próprias.

Depois de traduzir, compare os dois ficheiros:

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

Se algum dos ficheiros não estiver em UTF-8, acrescente --source-encoding ou --translated-encoding. A verificação de capítulos reconhece padrões de títulos em inglês e chinês/japonês; para outras línguas de destino, acrescente a palavra local para «capítulo» ao padrão no topo do script.

Este é o relatório de uma das nossas execuções com cortes:

                            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

Leia-o assim:

• Os parágrafos e os títulos de capítulos devem coincidir. Um parágrafo em falta significa frequentemente que dois foram fundidos ou um foi eliminado.
• As linhas não vazias podem diferir por uma boa razão. As nossas execuções com o ficheiro completo e quebras forçadas passaram de 43 linhas para 19 porque o modelo uniu as linhas com quebras forçadas, o que foi uma melhoria. Compare linhas apenas quando a origem já não tinha quebras forçadas.
• Os caracteres do sistema de escrita de origem remanescentes apontam para passagens que não foram traduzidas de todo. Alguns são normais para nomes, termos de produtos ou citações; uma sequência deles é uma secção omitida.
• Os caracteres de substituição na tradução indicam um problema de codificação na saída.

As contagens não lhe dizem se a tradução está correta. Leia o primeiro e o último parágrafo de cada capítulo, e os parágrafos de ambos os lados de cada local onde o ficheiro foi dividido. Foi aí que o nosso teste encontrou todos os erros graves.

Perguntas frequentes

Porque é que o meu ficheiro TXT parece estar bem num programa e ilegível noutro?

Os dois programas adivinharam codificações diferentes. Um adivinhou corretamente. Descubra a codificação que mostra o texto corretamente e, em seguida, guarde o ficheiro como UTF-8 para que todos os programas o leiam da mesma forma.

Devo converter um ficheiro TXT para EPUB ou DOCX antes de o traduzir?

Apenas se quiser o que esses formatos acrescentam. Um ficheiro TXT limpo, com capítulos bem definidos, traduz-se bem tal como está. Se pretender um índice, navegação por capítulos e um ebook que possa ler num dispositivo, o nosso guia sobre como transformar uma web novel num EPUB pronto para tradução explica tudo.

Posso traduzir um ficheiro TXT com vários idiomas?

Sim, mas indique ao tradutor o que deve deixar intacto. Citações ou termos noutro idioma, e nomes que devem manter o alfabeto original, protegem-se mais facilmente com um glossário ou uma instrução breve do que corrigindo depois.

E um ficheiro TXT que descarreguei de um site?

Verifique se tem o direito de o utilizar. Para livros do domínio público ou ficheiros que escreveu, aplicam-se os passos acima. A codificação ou o formato de um ficheiro não dizem nada sobre os direitos de autor.