Um manual técnico pode estar traduzido corretamente e ainda assim ser inútil. Basta um título cair no lugar errado, uma tabela perder suas colunas ou um bloco de código receber tradução automática. O problema não é apenas traduzir o texto: é descobrir a estrutura do documento antes de mexer nele.

Este guia é a evolução de um projeto que já construímos aqui: a versão mínima do fluxo de tradução, que protege comandos e marcação de um arquivo Markdown antes de traduzir. Ela resolve o caso limpo. Mas manual de verdade raramente chega limpo: chega como PDF diagramado ou digitalizado, com tabelas, colunas e páginas que só existem como imagem. Desta vez, vamos montar o pipeline completo: ler o documento, resumir seu conteúdo, traduzir apenas o que deve ser traduzido e reconstruir um arquivo utilizável. A ideia combina leitura de imagem, processamento de linguagem e regras determinísticas. Nenhum modelo isolado resolve as três partes bem.

O documento não é uma sequência de parágrafos

Um PDF parece uma página, mas tecnicamente pode ser uma coleção de caixas posicionadas em coordenadas. Uma linha de texto sabe onde começa, mas talvez não saiba que pertence a uma tabela, a uma legenda ou a um aviso lateral. Em um documento digitalizado, nem sequer existe texto: há apenas pixels, o problema que atacamos quando transformamos PDFs quebrados em dados.

Por isso, o primeiro passo é transformar a página em uma representação estruturada. O OCR extrai caracteres da imagem e devolve palavras, linhas e posições. A saída ideal não é um texto corrido, mas algo parecido com isto:

{
  "tipo": "paragrafo",
  "texto": "Instale o pacote antes de iniciar o serviço.",
  "caixa": [72, 184, 468, 216],
  "pagina": 3
}

A caixa delimita a região ocupada na página. A analogia útil é pensar em uma planta baixa: o OCR identifica o que está escrito e onde cada objeto fica. A analogia deixa de valer quando o layout depende de relações semânticas, como uma nota que se refere a uma figura distante. Nesse caso, posição sozinha não basta.

Um pipeline robusto guarda também fonte, tamanho aproximado, ordem de leitura, idioma detectado e confiança do OCR. Se uma palavra crítica tem baixa confiança, ela entra numa fila de revisão em vez de seguir silenciosamente para a tradução.

Separe texto traduzível de texto intocável

O erro mais caro acontece quando o sistema manda a página inteira para um modelo de linguagem. O modelo pode traduzir comentários de código, alterar nomes de funções, adaptar unidades ou reescrever comandos que precisavam permanecer idênticos.

A solução é classificar os blocos antes da tradução. Uma regra inicial pode separar:

  • títulos, parágrafos e legendas, que podem ser traduzidos;
  • comandos, caminhos de arquivo, identificadores e blocos de código, que devem ser preservados;
  • tabelas, listas e avisos, que precisam manter sua estrutura;
  • números, unidades e versões, que exigem validação própria.

Para reconhecer código, não use apenas pistas visuais. O chunking por sintaxe, que já detalhamos por aqui, divide o conteúdo conforme a gramática da linguagem, preservando delimitadores, indentação e tokens. O pipeline deve reconhecer um bloco identificado por uma linguagem de programação e mantê-lo separado do texto traduzível.

Quando o formato não é conhecido, uma heurística pode procurar padrões como chaves balanceadas, comandos de terminal, indentação consistente e nomes com aparência de identificador. Isso é uma aproximação. A classificação precisa marcar seus casos duvidosos para inspeção humana.

Traduza em unidades que carregam contexto

Traduzir cada linha isoladamente reduz o tamanho da solicitação, mas destrói contexto. Traduzir o documento inteiro preserva contexto, mas aumenta custo, latência e risco de o modelo misturar seções. O meio-termo é dividir o manual em blocos semânticos.

Um chunk bom contém um título e os parágrafos que dependem dele. Uma tabela permanece inteira. Um procedimento mantém seus passos juntos. Um aviso não deve ser separado da condição que o dispara.

A instrução de tradução precisa declarar invariantes, não apenas pedir fluência. Por exemplo:

Traduza somente os campos marcados como traduzíveis.
Preserve variáveis, comandos, números, unidades, URLs e nomes de arquivo.
Mantenha a quantidade e a ordem dos itens da lista.
Retorne JSON válido, sem comentários fora da estrutura.

Depois, envie um objeto com campos protegidos:

{
  "titulo": "Configuring the service",
  "passos": [
    "Run `service start --port 8080`.",
    "Open the configuration file."
  ],
  "codigo": "service start --port 8080"
}

O pipeline deve traduzir apenas os campos marcados e proteger o comando contra alterações.

Resumo e tradução são tarefas diferentes

O resumo deve vir antes da tradução quando o objetivo é produzir documentação para uso rápido. Primeiro, o sistema identifica propósito, pré-requisitos, riscos e sequência operacional. Depois, traduz o conteúdo original e usa o resumo como artefato separado.

Misturar as duas tarefas numa única solicitação dificulta a revisão. Um resumo pode omitir uma exceção importante, enquanto a tradução precisa conservar essa exceção. Separar as saídas permite comparar o documento completo com a versão condensada.

Suponha, apenas como exemplo hipotético, que cada chamada de OCR leve 300 ms, cada rodada de tradução leve 2 segundos e o manual tenha oito blocos. Se o pipeline fizer uma rodada de OCR por bloco e oito traduções em sequência, essas etapas se acumulam e aumentam a espera total. Traduções independentes podem rodar em paralelo, mas isso aumenta concorrência e exige controle de limites.

Reconstrua o arquivo a partir da estrutura

Há dois caminhos. No primeiro, você altera o texto dentro do documento original, quando o formato permite substituir conteúdo mantendo estilos e posições. No segundo, cria uma nova página usando as caixas detectadas pelo OCR.

O segundo caminho oferece mais controle, mas revela um problema inevitável: traduções podem ficar maiores que o original. Uma frase que ocupava uma linha pode ocupar duas. Reduzir a fonte resolve o encaixe e piora a leitura. O sistema deve tentar reflow, aumentar a caixa e só depois sinalizar a página para revisão.

Tabelas merecem tratamento separado. Preserve o número de linhas e colunas, traduza cada célula e meça o texto antes de desenhar novamente. Se uma célula estourar, não comprima toda a tabela automaticamente. Marque o conflito.

A saída final pode ser um PDF, um arquivo editável ou uma página HTML. HTML pode facilitar busca, links e manutenção em determinados fluxos. PDF pode ser preferível quando a prioridade é conservar a aparência do manual, desde que a reconstrução mantenha ordem de leitura e acessibilidade.

Valide o que o modelo não consegue garantir

Uma tradução com boa aparência ainda pode estar errada. A validação precisa comparar o original com a saída em camadas:

  1. conte blocos, páginas, itens de lista e células;
  2. compare números, unidades, versões, URLs e comandos;
  3. verifique se todo código continua sintaticamente válido;
  4. procure texto que transbordou ou ficou sobreposto;
  5. peça uma revisão humana para trechos de risco.

Essa última etapa não é um detalhe burocrático. Como princípio operacional, precisão depende do domínio, da terminologia e da revisão. Uma primeira versão não substitui testes no seu próprio conjunto de manuais.

Uma métrica simples ajuda a começar: quantos elementos estruturais foram preservados e quantos itens críticos mudaram indevidamente. O número não mede qualidade literária, mas detecta falhas que uma leitura rápida ignora.

O menor pipeline que já vale a pena

Para um protótipo, use quatro etapas: extração, classificação, tradução e reconstrução. Mantenha cada etapa produzindo um arquivo intermediário. Assim, você consegue descobrir se o erro nasceu no OCR, no chunking, na geração ou no layout.

Como exemplo de implementação, a HiNow poderia ser usada para encadear modelos de visão, linguagem e geração de arquivos sob uma mesma interface, caso os recursos necessários estejam disponíveis no fluxo escolhido. O ganho não está em delegar tudo a um único modelo. Está em encadear capacidades diferentes e cercar cada uma com regras que protegem o documento.

Comece com dez páginas e uma única língua de destino. Meça preservação de comandos, tabelas e hierarquia de títulos. Só depois aumente o volume ou adicione resumo automático. Documentação técnica não precisa de uma tradução que pareça inteligente. Precisa continuar funcionando quando alguém copiar o comando da página, seguir os passos e confiar no que está lendo.