TranslatePress no teto do Google Translate: eu traduzi pelo banco, em planilha

Por que o painel do TranslatePress não aguenta artigo inteiro

O plugin é um dos mais usados no WordPress para idioma extra. O automático dele, no recorte da aula, é a API neural do Google — paga. Quem traduz um pedaço e fica sem o resto conhece o teto. O painel ainda parte o texto em strings. Copiar artigo por artigo, colar na caixa de 5 mil caracteres, voltar, repetir: inviável em site com milhares de URLs.

A alternativa que eu estava usando era ir direto na tabela. Vale para o TranslatePress e, com outro esquema de colunas, para plugin parecido. Não é tarefa de um clique. Eu já tinha traduzido para mais de cinco idiomas quando gravei. O Navicat era o cliente gráfico. phpMyAdmin no servidor também serve, só é mais lento para lote.

Documentação do plugin lista `wp_trp_dictionary_*` como a tabela do dicionário — original e tradução por par de idiomas. Eu falava em coluna original (o português do site), translated (o destino) e status. O número 2 no status, no meu fluxo, era o aviso: isso já foi traduzido, não dispara a API de novo. Confira o valor na sua versão antes de um UPDATE cego. O esquema muda. A ideia não: marcar o trecho para a cota parar de comer o mesmo parágrafo.

Localhost, filtro e as 11.404 linhas que cabem num XLS

Editar no servidor remoto, para mim, era punição. Umas 20 mil linhas levaram cerca de 3 horas para aplicar. Por isso eu baixava o banco, trabalhava no MySQL local, e só no fim mandava o arquivo de volta. Backup da tabela de produção com outro nome, sempre, antes de colar o lote.

Filtro na coluna original: eu queria texto que não ia quebrar no copia-e-cola. HTML torto, trecho de japonês, código, shortcode — isso eu apartava. Copiei a coluna, coloquei no editor (BBedit, no Mac), conferi a contagem de linhas. 11.404. Qualquer espaço extra no meio, do tipo linha em branco que o banco inventa no export, eu via na hora. Planilha e banco que não batem linha a linha misturam tradução no parágrafo do vizinho. Isso é o desastre da técnica.

Exportar como texto e mandar ao tradutor de documentos às vezes funcionava, quase sempre demorava ou falhava no arquivo grande. XLS foi o formato que eu preferi. O Google Translate na web, para arquivo, aceita .xlsx / .xls, .docx, .pdf, até 10 MB, segundo o suporte oficial — bem outro teto que os 5 mil caracteres da caixa. As 11 mil linhas que eu mandei com certeza passavam de 1 milhão de caracteres. Sem API. Sem artigo por artigo.

1. Exporte a tabela do TranslatePress (ou o dump inteiro) e importe num MySQL local. Não edite o remoto em lote grande.
2. Filtre a coluna original: só string que você aceita passar pelo tradutor. Tire japonês, código e HTML podre.
3. Copie a coluna para um editor de texto. Conte as linhas. Anote o número.
4. Cole numa planilha de uma coluna só. Ajuste o delimitador se o editor criar coluna extra. Exporte XLS ou XLSX.
5. Em translate.google.com, Traduzir documentos, envie o arquivo, idioma de origem e destino.
6. Abra o resultado, apague linha de cabeçalho e linha vazia que o Google inventar, e confira a mesma contagem de linhas.
7. Cole na coluna translated. Na coluna status, preencha 2 (ou o valor de “já traduzido” da sua versão) em todas as linhas do lote.
8. Renomeie a tabela de produção para backup, suba a local, abra o site no idioma novo. Se quebrar, volte o backup.

O que o Tradutor estraga: japonês, traço e o replace depois

Caractere japonês eu não mando no mesmo lote. Copio a coluna original para a translated nessas linhas, sem passar pelo Google. O tradutor inventa palavra, mete espaço no meio do kana, e isso pode bagunçar busca. A maioria dos sites em português não tem essa tabela de idioma. O Suki Desu tem. Fica o alerta.

Traço e hífen também saem errados: vira entidade, vira código, some o caractere. Eu não mostrei o SQL no vídeo para não alongar. O conserto é o de sempre: achar o padrão no phpMyAdmin, REPLACE na coluna, e uma passada no site no idioma novo. Tem bug. Tem correção manual. Não é tradução neural da API. É o Tradutor de documentos, que já era “muito bom” para o volume, no meu juízo da época, e barato o bastante para levar o site a mais de dez idiomas sem pagar a API.

A cota que eu citei — cerca de 500 mil caracteres grátis por mês — era o teto de quem usa a API do Cloud Translation no plano gratuito histórico. O TranslatePress consome isso no automático. O fluxo da planilha existe exatamente para não depender desse número quando o site já passou dele. A API neural continua melhor em frase corrida. Eu não fingi o contrário. Fingir que a cota é infinita é o que deixa o site pela metade.

Status 2, backup e o que veio depois dessa aula

No fechamento eu ainda colei o 2 na coluna de status. Sem isso, o plugin pode mandar o mesmo trecho de novo para a API na próxima visita. O trabalho da planilha vira fumaça e a fatura (ou o teto) volta. Tradução na coluna e status batendo: os dois, sempre.

Eu estava fazendo o vídeo para colocar no artigo. O método continua sujo e continua útil em WordPress que já está no TranslatePress até o pescoço. Hoje existe extensão com outro modelo, fila na Cloudflare, e até limpeza de tabela com automação — eu gravei isso anos depois. Nenhuma dessas frentes apaga o cuidado: dump local, conferência de linhas, backup com o nome antigo, olho no idioma publicado.

Se o seu problema é escolher o plugin, não furar cota, o curso e o texto de GTranslate conversam melhor. Se o problema é a tabela inchada, a limpeza com n8n é o capítulo seguinte. Este aqui é o do teto de 5 mil caracteres e da coluna que o painel não deixa copiar inteira.

Na sequência

1. Dump local da tabela do TranslatePress, nunca lote grande no MySQL remoto.
2. Filtrar original: sem kana, sem código, sem HTML que quebra linha.
3. Bater o número de linhas no editor, na planilha e no arquivo traduzido.
4. Colar em translated e marcar status 2 (ou o valor atual de “humano/já feito”).
5. Backup da tabela de produção com outro nome antes de substituir.
6. Abrir o site no idioma novo e corrigir traço, espaço e string que o Google inventou.

Onde isso quebra