Quando eu alterava um texto original, a tradução antiga podia continuar no banco do TranslatePress. Isso é útil se você quiser reaproveitar o trabalho, mas também deixa registros que já não aparecem nas páginas atuais. Eu montei um workflow no n8n para comparar uma string de cada vez com os títulos e o conteúdo dos posts. A busca ajudava a encontrar candidatas à limpeza; sozinha, ela não provava que era seguro apagar uma tradução.
Uma tradução antiga não é automaticamente lixo
O TranslatePress guarda textos por string. Se você muda a frase original, a tradução associada à versão anterior pode ficar no banco para ser recuperada depois. O plugin também tem ferramentas próprias: hoje, a tela de tradução permite remover strings selecionadas, e as configurações avançadas oferecem otimização para duplicatas, links não traduzidos e outros dados compatíveis com essa limpeza.
Meu fluxo cuidava de outra pergunta: a string original ainda aparecia nos campos de post que eu escolhi conferir? Eu queria varrer bastante conteúdo sem abrir cada registro no painel. Usei o n8n para repetir a busca, mas passei a entender melhor o limite da resposta: não encontrar um trecho numa parte do banco não significa que ele não seja usado em outro lugar.
Escolha primeiro onde o site pode guardar esses textos
Antes de ligar o agendamento, eu definiria os tipos de conteúdo e os campos em que uma string pode estar. No meu primeiro recorte, comparei com `post_title` e `post_content` da tabela de posts do WordPress. Se o site usa campos personalizados, metadados, widgets, tabelas próprias ou outros tipos de post, inclua esses lugares na busca antes de considerar a remoção.
Também confira o nome real das tabelas e o prefixo do WordPress naquela instalação. O TranslatePress mantém strings e traduções em tabelas próprias; a estrutura e os idiomas do meu banco não devem ser tratados como esquema universal. Se as ferramentas da interface resolverem a limpeza que você quer fazer, eu começaria por elas antes de criar uma automação com consultas diretas.
Um cursor persistente deixa a varredura retomável
Eu configurei o workflow para rodar a cada 30 segundos e salvei o ID da última string examinada numa tabela MySQL chamada `variaveis`. A execução lia o cursor, buscava o próximo ID em ordem crescente e gravava o novo ponto de retomada. Se o servidor travasse ou eu precisasse reiniciar o fluxo, a próxima execução não começava do zero.
No meu site, também escolhi qual base de idioma examinar primeiro; comecei pela tabela mais antiga em inglês, que tinha mais linhas. Se a instalação tiver só uma base relevante, essa escolha entre bancos pode ser removida. O importante para retomar a tarefa é guardar o cursor num local persistente e saber exatamente qual tabela está sendo percorrida.
Pesquise a frase inteira nos campos que você incluiu
Para cada string original, meu SQL procurava correspondências em `post_title` e `post_content` com `LIKE` e curingas, porque a frase podia estar no meio do HTML ou de um parágrafo. Eu tinha tentado exigir um espaço como filtro para ignorar trechos curtos e links. Isso era uma heurística da minha consulta, não uma garantia de que o resultado estava certo.
Se a busca encontrasse o trecho, eu mantinha a string e avançava o cursor. Se não encontrasse, o primeiro workflow encaminhava a string para a remoção das traduções ligadas a ela em todos os idiomas e registrava o ID e o texto para conferência. Hoje eu separaria essas etapas: primeiro salvaria uma lista de candidatas, depois revisaria essa lista com os campos adicionais do site e só então removeria os registros confirmados.
Uma string por execução evitou cruzar resultados vazios
Minha primeira tentativa buscava dez strings de uma vez. Quando uma delas não aparecia em `wp_posts`, o nó devolvia uma resposta vazia que se misturava às respostas encontradas no Merge. Eu não consegui manter a correspondência entre cada string e seu resultado com segurança.
Reduzi para uma string por execução. Ficou mais lento, mas cada consulta tinha um resultado simples: encontrada, mantida; não encontrada, registrada para revisão. Os 30 segundos entre execuções ajudavam o servidor que eu usava a acompanhar o trabalho. Se a base for grande, prefira começar com uma amostra curta e observar a carga antes de escolher um intervalo menor.
Trate a exclusão como uma segunda etapa
No fluxo que montei, a ausência em `post_title` e `post_content` já levava à exclusão da string original e das traduções relacionadas. Mas eu ainda não tinha incluído campos personalizados, alguns tipos de post e todas as tabelas do meu próprio site. Portanto, essa condição era mais estreita que o conjunto completo de lugares onde o texto podia aparecer.
Eu faria a primeira execução sem apagar nada: salvaria ID, texto e resultado das consultas. Depois, revisaria uma amostra manualmente, incluiria campos e tabelas usados pelo projeto e conferiria se nenhum conteúdo legítimo ficou de fora. Só então rodaria uma exclusão pequena, com backup restaurável e um registro do que foi removido. O nome e a estrutura das tabelas TranslatePress podem variar com prefixo, idiomas e versão do plugin.
Esse workflow nasceu para poupar uma conferência repetitiva no meu banco, não para servir como limpador universal. Hoje eu verificaria primeiro a otimização disponível no TranslatePress e a remoção pela interface de tradução. Quando ainda precisar comparar muitas strings com dados próprios, eu usaria a automação para localizar e registrar candidatas; a etapa de apagar só viria depois de confirmar onde o site realmente usa cada texto.