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

Para traduzir um arquivo TXT grande, prepare três coisas antes de enviá-lo a qualquer lugar. Primeiro, certifique-se de que o texto foi decodificado corretamente e salve-o como UTF-8. Segundo, coloque cada título de capítulo em sua própria linha, com uma linha em branco antes e depois. Terceiro, se o arquivo quebra linhas em uma largura fixa, junte essas linhas para que cada parágrafo fique em uma única linha, com uma linha em branco entre os parágrafos. Depois, traduza o arquivo inteiro e, em seguida, compare a contagem de parágrafos e capítulos entre o original e a tradução.

Um arquivo de texto simples não tem estilos, títulos nem metadados. Tudo o que uma ferramenta de tradução sabe sobre sua estrutura vem dos bytes e das quebras de linha. É por isso que os mesmos três problemas sempre voltam: os bytes são lidos na codificação errada, os capítulos não podem ser distinguidos das linhas comuns, ou as quebras de linha não dizem nada sobre onde uma frase termina.

Criamos arquivos 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 arquivo inteiro. Ele quebrou frases e atribuiu a ação de um personagem a outro nas três execuções em que o arquivo foi cortado em pedaços por contagem de linhas.

Lista de verificação rápida

O verificador reporta cada linha e corrige a codificação, a marca de ordem de bytes, os finais de linha e a quebra forçada. Os títulos de capítulo e as linhas em branco ausentes são sua responsabilidade de 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 gravar uma cópia em UTF-8 com os parágrafos unidos. Ele precisa apenas do Python 3 e nunca altera o arquivo original.

Passo 1: Acerte a codificação

Um arquivo TXT é uma sequência de bytes. A codificação é a regra que transforma esses bytes em caracteres, e o arquivo não informa qual regra foi usada. Se um programa adivinhar errado, você obtém mojibake: texto embaralhado ou, pior, texto que parece correto mas não é o que foi escrito.

Aqui está a mesma frase em chinês, 最后一班渡轮 ("a última balsa"), lida com a regra errada. Geramos estes exemplos com os codecs nativos do Python, e você pode reproduzi-los com os arquivos 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 os traduzirá alegremente, e o resultado será um absurdo com boa gramática.

Nosso verificador mostra por que você não pode confiar em "abriu sem erros". Quando o executamos no exemplo Shift_JIS, duas codificações decodificaram o arquivo 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    第一話　最後のフェリー

Apenas a segunda linha é japonês. A primeira é uma sequência de caracteres chineses raros que ninguém escreveu. No exemplo chinês GB18030, cinco codificações decodificaram sem erros, e apenas uma delas, GB18030, mostrou o título do capítulo 第一章 最后一班渡轮. Então a regra é simples: decida a codificação lendo as primeiras linhas, não pelo fato de um programa ter reclamado.

Onde as suposições costumam falhar:

• Textos em chinês de sistemas Windows mais antigos ou de sites chineses geralmente estão em GBK ou GB18030. O GB18030 cobre tudo o que o GBK cobre, e o Padrão de Codificação WHATWG, seguido pelos navegadores, vai além: ele afirma que "o decodificador do GBK é o decodificador do gb18030". Se um arquivo estiver em GBK, abri-lo como GB18030 funciona.
• Chinês tradicional de Taiwan ou Hong Kong geralmente está em Big5.
• Japonês geralmente está em Shift_JIS, ou na versão estendida da Microsoft, que o Windows e o Python chamam de cp932.
• Coreano geralmente está em EUC-KR.
• Um arquivo cheio de bytes NUL, ou um em que todos os outros caracteres parecem vazios, geralmente está em UTF-16 sem marca de ordem de bytes.

Uma marca de ordem de bytes (BOM) é um código curto e invisível no início de um arquivo que anuncia UTF-8, UTF-16 ou UTF-32. Quando ela está presente, confie nela. O mesmo padrão diz que "a marca de ordem de bytes é mais autoritativa do que qualquer outra coisa". Nosso verificador lê a BOM primeiro e só faz suposições quando não há nenhuma.

Salve o arquivo como UTF-8

Depois que o texto estiver legível corretamente, salve-o como UTF-8. O padrão WHATWG chama o UTF-8 de "a codificação mais apropriada para intercâmbio de Unicode", e é a escolha mais segura para qualquer ferramenta de tradução.

Há um segundo motivo que importa particularmente para tradução. Codificações legadas cobrem apenas os caracteres de 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 tem, porque é um caractere chinês simplificado. O Windows-1252 não consegue armazenar cirílico. Se o arquivo traduzido tiver que ser gravado de volta na codificação legada original, o idioma de destino pode não caber. O tradutor de TXT do BookTranslator diz que detecta automaticamente codificações comuns e retorna o arquivo traduzido "com a mesma codificação da entrada", então começar com UTF-8 elimina a questão por completo.

Você pode converter em um editor de texto (abrir com a codificação correta e depois "Salvar 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 arquivo já contém caracteres �, o dano aconteceu antes de você recebê-lo. Converter novamente não restaurará os caracteres ausentes. Procure uma cópia melhor da fonte.

Passo 2: Facilite a localização dos capítulos

Capítulos importam por três razões. Um arquivo longo é traduzido em partes, e as quebras de capítulo são os melhores lugares para cortar. Você vai querer verificar cada capítulo após a tradução. E se mais tarde transformar o texto em um ebook, os títulos dos capítulos se tornam o sumário.

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

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

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

Passo 3: Desfaça quebras de linha rígidas, com cuidado

Alguns arquivos TXT quebram cada linha em uma largura fixa, para que o texto caiba em um terminal simples ou em uma janela estreita. Textos copiados de PDFs e saídas de OCR fazem o mesmo na largura da página impressa. Nesses arquivos, uma quebra de linha significa "a linha estava cheia", não "a frase ou o parágrafo terminou".

Quebras rígidas são fáceis de identificar. Em nossa amostra com quebras rígidas, o verificador relatou:

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 correção é juntar as linhas dentro de cada parágrafo e manter as linhas em branco entre os parágrafos. A armadilha são textos cujas quebras de linha são reais: versos, letras de música, cartas, endereços, receitas e listas. Nossa amostra 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

Um "substitua todas as quebras de linha simples por um espaço" sem critério transforma isso em uma única linha corrida. O --unwrap do verificador só junta um parágrafo quando a maioria de suas linhas se aproxima da largura total, então blocos de linhas curtas como esta carta são deixados intactos. Em nossa amostra, ele reconstruiu o arquivo original sem quebras exatamente, byte a byte, incluindo a carta. No seu próprio arquivo, verifique alguns parágrafos unidos e cada bloco de versos antes de confiar.

Mais dois detalhes. Ao juntar linhas de texto em chinês ou japonês, não adicione um espaço entre elas; o verificador une 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ífens no final das linhas, o que exige decisões próprias. Nosso guia para corrigir quebras de linha e hifenização de OCR cobre isso.

O que testamos: texto com quebras rígidas, inteiro vs. dividido

Queríamos saber se a quebra de linha forçada realmente prejudica a tradução ou apenas deixa o texto desorganizado. 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 * * *. Salvamos duas vezes com as mesmas palavras: sem quebras, com um parágrafo por linha, e com quebras forçadas em 66 caracteres, que tem 43 linhas não vazias em vez de 19.

Em seguida, pedimos a um modelo local para traduzi-lo para o chinês simplificado de três maneiras, três execuções cada:

1. Com quebras, arquivo inteiro. O arquivo com quebras forçadas em uma única requisição.
2. Sem quebras, arquivo inteiro. O arquivo sem quebras em uma única requisição.
3. Com quebras, cortado a cada 12 linhas. O arquivo com quebras forçadas dividido a cada 12 linhas, uma requisição por parte, as respostas reunidas novamente. É o que acontece quando um script ou ferramenta divide um arquivo longo por contagem de linhas em vez de por parágrafo.

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, em um Apple M4 Max com 64 GB de memória. Todas as requisições usaram o mesmo prompt de uma frase. Executamos em 28 de outubro de 2026. O script é run_llm_txt_test.py, todas as nove saídas são publicadas sem edição, e results.csv tem uma linha por execução.

A primeira descoberta nos surpreendeu. Quando o modelo viu o arquivo inteiro com quebras de linha forçadas, ele mesmo uniu as linhas. As três saídas tinham um parágrafo por linha, as mesmas 19 linhas das execuções sem quebra forçada, e liam igualmente bem. Portanto, a quebra forçada sozinha não prejudicou este modelo neste arquivo curto.

Cortar o arquivo por contagem de linhas prejudicou, nos mesmos lugares todas as vezes. Três dos pedaços de 12 linhas terminaram no meio de uma frase. O primeiro termina em "He pointed with his" e o pedaço 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 prédio de três andares na esquina." Na terceira, terminou com 随后她重新回到填字游戏上, "depois ela voltou às palavras cruzadas." Na história, o homem na bilheteria aponta e volta às suas palavras cruzadas. Em todas as três execuções, um leitor do chinês pensaria que foi Mara quem fez isso.

O segundo corte, entre "the careful, slightly old-fashioned hand she had learned at a" e "convent school," deixou a frase em chinês suspensa em 那是她在, "foi ali que ela," em todas as três execuções (uma execução acrescentou um 一 extraviado), e a palavra "learned" desapareceu. O terceiro corte dividiu a frase sobre as venezianas em duas linhas, e a segunda metade transformou "painted, not well, but not long ago" em tinta descascando: 油漆虽已斑驳 em duas execuções e 油漆剥落 na terceira. E como os pedaços foram unidos com uma única quebra de linha, a linha em branco antes da quebra de cena desapareceu, e é por isso que cada execução teve 14 parágrafos em vez de 15. Nosso verificador detectou a contagem de parágrafos. Não conseguiu detectar o caractere errado; descobrimos isso lendo.

O que isso significa para o seu arquivo:

• Desfazer a quebra forçada protege você de divisores que não controla. Todo arquivo longo é dividido em algum lugar, seja pelo seu próprio script, pelo limite de uma janela de chat ou pela ferramenta para a qual você faz upload. 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 prédio" é um bom chinês. Um leitor notaria as quebras de linha estranhas em cada corte e o 那是她在 pendurado, mas nada marca o caractere errado ou a tinta descascando como erros. Erros em pontos de divisão são erros de significado em primeiro lugar, erros de formatação em segundo.
• Este foi um modelo e um conto curto. Um arquivo tão curto cabe em uma única requisição, então as execuções com o arquivo inteiro nunca precisaram dividir nada. Um romance completo precisa ser dividido, e é exatamente aí que a preparação dos Passos 1 a 3 compensa. Esses arquivos testam a preparação e a divisão, não o pipeline do próprio BookTranslator.

Uma observação menor: nas seis execuções com o arquivo inteiro, o modelo escreveu o nome de Mara como 玛拉 em cinco e 马拉 em uma. Cada saída era consistente consigo mesma, mas requisições separadas não concordavam entre si. Para um livro longo traduzido em muitos pedaços, uma lista de nomes e suas grafias acordadas mantém todos os capítulos alinhados. Nosso guia de glossário mostra como criar uma.

Passo 4: Traduza e depois verifique as contagens

Quando o arquivo está limpo, traduzi-lo é a parte fácil. Você pode enviá-lo ao tradutor de TXT do BookTranslator, que aceita arquivos .txt, .md e .mdx, informa que processa arquivos TXT de até 300 MB e mostra o preço antes do checkout. Não há tradução completa gratuita, mas o próprio upload informa o custo. Se preferir trabalhar com um modelo de chat ou um LLM local, divida o arquivo nos limites de capítulo ou parágrafo e mantenha um glossário para nomes. Se o seu texto for Markdown em vez de prosa simples, consulte nosso guia de tradução de Markdown, porque a sintaxe Markdown precisa de regras próprias.

Após a tradução, compare os dois arquivos:

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

Se algum dos arquivos não estiver em UTF-8, adicione --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 outros idiomas de destino, adicione 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 assim:

• Parágrafos e títulos de capítulo devem coincidir. Um parágrafo ausente geralmente significa que dois foram mesclados ou um foi descartado.
• Linhas não vazias podem diferir por um bom motivo. Nossas execuções com o arquivo inteiro e quebra forçada passaram de 43 linhas para 19 porque o modelo uniu as linhas com quebra forçada, o que foi uma melhoria. Compare linhas apenas quando a origem já estava sem quebra forçada.
• Caracteres do alfabeto de origem remanescentes apontam para trechos que não foram traduzidos de forma alguma. Alguns são normais para nomes, termos de produtos ou citações; uma sequência deles é uma seção pulada.
• Caracteres de substituição na tradução indicam um problema de codificação na saída.

As contagens não podem dizer 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 ponto em que o arquivo foi dividido. Foi aí que nosso teste encontrou todos os erros graves.

Perguntas frequentes

Por que meu arquivo TXT parece bom em um programa e ilegível em outro?

Os dois programas adivinharam codificações diferentes. Um acertou. Descubra a codificação que mostra o texto corretamente e depois salve o arquivo como UTF-8 para que todos os programas o leiam da mesma forma.

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

Somente se você quiser o que esses formatos acrescentam. Um arquivo TXT limpo, com capítulos bem definidos, já se traduz bem como está. Se você quiser um sumário, navegação por capítulos e um ebook que possa ler em um dispositivo, nosso guia sobre transformar uma web novel em um EPUB pronto para tradução explica o processo.

Posso traduzir um arquivo TXT com idiomas misturados?

Sim, mas diga ao tradutor o que deve ser deixado intacto. Citações ou termos em um terceiro idioma, e nomes que devem permanecer no alfabeto original, são mais fáceis de proteger com um glossário ou uma instrução curta do que de corrigir depois.

E um arquivo TXT que baixei de um site?

Verifique se você tem o direito de usá-lo. Para livros em domínio público ou arquivos que você mesmo escreveu, os passos acima se aplicam. A codificação ou o formato de um arquivo não dizem nada sobre seus direitos autorais.