Como Traduzir Arquivos .po do Drupal com IA
A maioria das pessoas associa arquivos .po ao WordPress, mas o formato gettext é décadas mais antigo que o WordPress e impulsiona a tradução de interface em todo o mundo de código aberto. O Drupal é um de seus maiores usuários. Se você mantém um site Drupal multilíngue, cada rótulo de menu, descrição de campo, mensagem de erro e string de módulo flui por arquivos .po exatamente como no WordPress, apenas com um dialeto de placeholder diferente e um fluxo de trabalho de importação distinto. E, assim como no WordPress, no momento em que seu site excede um punhado de strings, a tradução manual desses arquivos se torna o gargalo.
Este guia é sobre como traduzir arquivos .po do Drupal com IA sem quebrar as coisas que tornam o Drupal o Drupal. Nós abordaremos o sistema de tradução do Drupal, de onde as strings realmente vêm, a sintaxe dos placeholders que difere do WordPress e que deve ser absolutamente preservada, e o ciclo completo de exportação, tradução e reimportação, incluindo os comandos drush que o tornam repetível.
Como Funciona o Sistema de Tradução do Drupal
O Drupal gerencia a tradução de interface através do módulo central locale (às vezes chamado de "Interface Translation" no Drupal moderno). Uma vez ativado, ele gerencia uma tabela de banco de dados de strings de origem e suas traduções por idioma, e pode importar e exportar essas traduções como arquivos .po padrão do gettext.
A interface de administração está em /admin/config/regional/translate. De lá, você pode pesquisar strings não traduzidas, editá-las diretamente e, crucialmente, importar um arquivo .po para carregar traduções em massa ou exportar o estado atual para um arquivo .po para edição offline. Esse ciclo de exportação/edição/importação é o fluxo de trabalho que estamos otimizando.
Diferente do WordPress, onde cada plugin e tema envia seus próprios arquivos .po e .mo em um diretório languages/, o Drupal centraliza as strings de interface em seu banco de dados e trata o .po como o formato de intercâmbio. Você exporta, trabalha no arquivo e o importa de volta. A etapa de compilação .mo que o WordPress exige é tratada internamente.
De Onde Vêm as Strings
As strings do Drupal se originam de três lugares, e uma tradução completa deve cobrir todos eles:
- Core (Núcleo) envia milhares de strings traduzíveis para a interface de administração, formulários e mensagens do sistema.
- Módulos contrib (Views, Webform, Commerce e o restante) cada um registra suas próprias strings através da função
t(). - Temas contribuem com strings de template, rótulos de região e descrições de configurações de tema.
Ao exportar de /admin/config/regional/translate, você pode delimitar a exportação para strings traduzidas, não traduzidas ou todas. Para uma nova rodada de tradução, exportar apenas strings não traduzidas fornece um arquivo .po focado com exatamente o trabalho restante.
Uma consequência prática dessa estrutura de três fontes: seu trabalho de tradução nunca está realmente "concluído". Cada vez que você adiciona um módulo contrib, habilita um novo recurso ou atualiza o Drupal core, um novo lote de entradas msgid não traduzidas aparece nas tabelas de localização. É por isso que as equipes do Drupal tratam a tradução como um pipeline recorrente, em vez de uma tarefa de lançamento única. O mesmo ciclo de exportação, tradução e reimportação ocorre em cada implantação que afeta os módulos, e quanto mais rápido esse ciclo for, menor será a dívida de tradução acumulada entre os lançamentos.
Vale a pena notar também que o Drupal pode puxar traduções contribuídas pela comunidade automaticamente de localize.drupal.org para o core e módulos contrib populares. Essas cobrem as strings comuns, mas raramente cobrem seus módulos personalizados, seu tema ou a fraseologia específica do projeto que seu site realmente usa. A lacuna entre a tradução da comunidade e um site totalmente localizado é exatamente o trabalho que uma passagem de IA fecha rapidamente.
Placeholders do Drupal Não São Placeholders do WordPress
Aqui está a coisa mais importante a entender antes de enviar qualquer arquivo .po do Drupal para um tradutor de IA: O Drupal não usa os placeholders no estilo printf %s e %1$s que dominam o WordPress. A função t() do Drupal usa três prefixos de placeholder distintos, cada um com um comportamento de escape diferente:
@variable— o valor é escapado em HTML, o padrão seguro para texto fornecido pelo usuário.%variable— o valor é escapado e envolvido em marcação de ênfase<em>.:placeholder— usado para atributos de URL, passado por sanitização de URL.
Uma string de origem típica do Drupal se parece com isto no arquivo .po exportado:
#: core/modules/node/node.module
msgid "@count comments"
msgid_plural "@count comments"
msgstr[0] ""
msgstr[1] ""
#: core/modules/user/user.module
msgid "Welcome @name, you last logged in on %date."
msgstr ""
Se um tradutor mudar @count para @cuenta, substituir @name pela palavra traduzida para "name", ou inserir um espaço transformando @count em @ count, o placeholder não corresponderá mais ao que a chamada t() passa. O Drupal então imprime o token literal @count na página em vez do número real. A tradução parece concluída, mas o site está visivelmente quebrado.
Esta é a mesma classe de bug que afeta as strings %s do WordPress, e cobrimos o princípio geral em profundidade em como traduzir arquivos PO sem quebrar variáveis de código. A peculiaridade do Drupal é simplesmente que existem três estilos de placeholder em vez de um, e uma ferramenta de tradução precisa reconhecer todos eles.
Por Que Tradutores Genéricos Falham Aqui
Cole aquela string node.module em uma caixa de tradução automática genérica e você frequentemente verá @count corrompido, o %date vinculado a <em> localizado em um token diferente, ou as formas plurais colapsadas em uma única. Nenhuma dessas ferramentas foi construída com a semântica do gettext em mente. Elas traduzem texto; elas não entendem que @count é um contrato com o código da aplicação.
Um pipeline de tradução com reconhecimento de gettext e Syntax Locking trata @variable, %variable e :placeholder como tokens imutáveis. Eles são bloqueados antes da tradução e restaurados depois, de modo que a frase circundante é traduzida enquanto os placeholders permanecem intocados. O mesmo bloqueio cobre %s e %1$s do WordPress, {{name}} do i18next, e HTML inline, razão pela qual uma única ferramenta pode atender a um projeto Drupal, Symfony ou Laravel tão facilmente quanto um de WordPress. As formas plurais do Drupal via msgid_plural são preservadas como formas plurais em vez de achatadas, o que importa porque os idiomas do Drupal podem ter de uma a seis variantes plurais.
Há também um modo de falha mais sutil que vale a pena destacar. As strings do Drupal frequentemente incorporam marcação e links inline dentro do texto traduzível, como Read the <a href=":url">documentation</a>, onde :url é um placeholder e as tags <a> devem sobreviver. Um tradutor que não entende a estrutura pode traduzir o atributo href, remover a tag de fechamento ou localizar o nome do placeholder. IA Consciente do Contexto que lê a string inteira como uma unidade, combinada com o bloqueio de tokens, mantém tanto a marcação quanto o contrato :url intactos, traduzindo apenas o texto legível por humanos "documentation" entre eles.
O Ciclo de Exportação, Tradução e Reimportação
O fluxo de trabalho repetível tem três estágios, e o drush torna a exportação e importação scriptáveis para que você não precise clicar na interface de administração toda vez.
Passo 1: Exportar o Arquivo PO
Você pode exportar da interface em /admin/config/regional/translate escolhendo um idioma e um escopo de exportação, ou fazê-lo pela linha de comando. O módulo locale expõe a exportação através dos serviços de tradução do Drupal, e a maioria das equipes o automatiza. Uma invocação típica do drush para acionar uma importação de tradução (o inverso, que usamos no passo três) se parece com isto:
# Re-import a translated PO file for Spanish, overwriting customized strings
drush locale:import es /var/www/translations/es-untranslated.po \
--type=customized --override=all
# Rebuild caches so the new strings render immediately
drush cache:rebuild
Para o lado da exportação, o formulário de exportação da administração produz o arquivo .po; muitas equipes encapsulam o serviço de exportação de localização em um pequeno comando Drush personalizado para automação completa. De qualquer forma, você termina com um arquivo .po gettext padrão contendo suas entradas msgid não traduzidas.
Passo 2: Traduzir o Arquivo
Esta é a etapa onde a IA substitui horas de edição manual. Carregue o arquivo .po exportado para um tradutor em nuvem, escolha seu idioma de destino e deixe-o processar. Como os arquivos .po do Drupal para um site grande rotineiramente ultrapassam 10MB quando o core, contrib e temas são combinados, o Smart Batching (Agrupamento Inteligente) é importante aqui: o arquivo é dividido em blocos, traduzido e remontado sem que você precise dividi-lo manualmente ou atingir limites de tamanho. A saída é um arquivo .po completo com cada msgstr preenchido e cada placeholder @count, %date e :url exatamente onde começou.
Passo 3: Reimportar para o Drupal
Importe o arquivo traduzido de volta através de /admin/config/regional/translate ou via o comando drush locale:import mostrado acima, então reconstrua o cache. O Drupal mescla as traduções em suas tabelas de localização, e as strings aparecem em todo o site imediatamente. Execute o ciclo novamente sempre que adicionar um módulo ou atualizar o core, já que cada um traz novas strings não traduzidas.
Um detalhe de importação a acertar: a flag --override controla se as traduções recebidas substituem as existentes. Use --override=all quando quiser que o arquivo traduzido por IA seja autoritativo, ou uma configuração mais conservadora se você tiver ajustado manualmente certas strings na interface do Drupal que não deseja que sejam sobrescritas. Para a maioria dos pipelines automatizados, tratar o arquivo .po como a fonte da verdade e sobrescrever tudo mantém o sistema previsível: o arquivo no controle de versão é o que o site mostra, ponto final.
Para sites multilíngues com vários idiomas de destino, o ciclo é executado uma vez por idioma. Exporte o conjunto não traduzido, traduza-o para o alemão, importe-o; exporte novamente, traduza para o espanhol, importe-o; e assim por diante. Como cada idioma é um arquivo .po independente, você pode executá-los em paralelo, e um tradutor em nuvem processando-os concomitantemente transforma o que costumava ser uma semana de trabalho de um contratado em uma tarde.
PO do Drupal É Um Formato Entre Vários
Vale a pena notar que o .po do gettext não é a única maneira de o Drupal lidar com a tradução. Entidades de configuração e conteúdo também podem ser trocadas como XLIFF, que é o padrão no qual o módulo Translation Management Tool (TMGMT) se baseia para fluxos de trabalho de fornecedores de tradução profissional. Se sua localização do Drupal funciona via XLIFF em vez de arquivos .po de interface, os princípios de preservação de placeholders são idênticos, mas a estrutura do arquivo difere, e cobrimos esse caminho em tradução de arquivos XLIFF para Drupal, Symfony e Angular.
Para a camada de tradução de interface, no entanto, o .po continua sendo a ferramenta principal. O ciclo de exportação, tradução por IA e reimportação transforma uma tarefa manual de vários dias em alguns minutos de processamento, e enquanto a ferramenta que você usa realmente entender os placeholders do gettext, seus contratos @variable sobreviverão intactos e seu site Drupal permanecerá funcional em todos os idiomas que você lançar.
Pronto para traduzir seus arquivos
.podo Drupal sem quebrar um único@variable? Experimente o SimplePoTranslate gratuitamente — não é necessário cartão de crédito. O nível gratuito lida com arquivos.poe.potgettext padrão com Syntax Locking completo, então seus placeholders do Drupal passam exatamente como o código espera.