Um Arquivo de Entrada, Cinco Formatos de Saída: Como Preparar Suas Traduções do WordPress para o Futuro

Você gastou três semanas traduzindo seu tema WordPress para espanhol. O arquivo .po está perfeito — cada string revisada, cada variável intacta, cada forma plural correta. Então, seu cliente decide migrar de um tema PHP clássico para uma configuração headless com React no frontend.

De repente, seu arquivo .po é inútil. O aplicativo React precisa de .json. Os widgets PHP legados ainda precisam de .mo. O freelancer que cuida do aplicativo móvel quer .xliff. E ninguém tem tempo para re-traduzir 4.000 strings para três formatos diferentes.

Este não é um caso isolado. É a realidade do desenvolvimento moderno do WordPress, onde os temas são enviados com componentes PHP e JavaScript, os plugins usam uma combinação de Gettext e i18next, e os clientes mudam de ideia sobre a arquitetura com mais frequência do que mudam suas senhas.

Por Que os Formatos de Arquivo de Tradução Importam Mais do Que Nunca

Há cinco anos, a tradução do WordPress era simples. Você tinha um arquivo .po (fonte legível por humanos) e um arquivo .mo (binário compilado). Era só isso. Cada tema, cada plugin, cada ferramenta de tradução falava a mesma língua.

Hoje, o ecossistema WordPress usa pelo menos cinco formatos de arquivo de tradução em produção:

Os Cinco Formatos Que Você Precisa Conhecer

.po (Portable Object) — O formato de origem legível por humanos usado pelo GNU Gettext. Contém strings originais (msgid) e suas traduções (msgstr). É isso que os tradutores editam.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — A versão binária compilada de um arquivo .po. O WordPress lê arquivos .mo em tempo de execução usando load_textdomain(). Mais rápido do que analisar .po em tempo de execução, mas não editável por humanos.

.json (JavaScript Object Notation) — Usado por wp_set_script_translations() para traduções baseadas em JavaScript em blocos Gutenberg, componentes React e temas modernos. O WordPress espera uma estrutura JSON específica com chaves locale_data.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — Um formato cada vez mais popular para temas e plugins que usam o carregamento de tradução no estilo Laravel. Alguns temas WordPress modernos ignoram o Gettext completamente e carregam traduções de arrays PHP para obter desempenho.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — O padrão da indústria para troca de traduções entre diferentes ferramentas e plataformas. Usado por ferramentas CAT (Computer-Assisted Translation) como memoQ, Trados e Memsource. Essencial ao trabalhar com tradutores humanos profissionais.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

O Problema: Dependência de Formato

A maioria das ferramentas de tradução produz um formato de saída. O Poedit oferece .po e .mo. O WPML armazena traduções no banco de dados (não em arquivos). O Weglot mantém as traduções em seus servidores em um formato proprietário. Até mesmo plataformas TMS como Crowdin e Lokalise exigem que você configure manualmente os formatos de exportação para cada projeto.

Isso cria dependência de formato — suas traduções ficam presas no formato que sua ferramenta atual produz. Quando seus requisitos mudam, você enfrenta duas opções:

1. Re-traduzir tudo no novo formato (caro, demorado e você perde quaisquer correções manuais)
2. Escrever scripts de conversão personalizados (propensos a erros, especialmente para formas plurais complexas e variáveis)

Nenhuma das opções é boa. Ambas desperdiçam tempo e dinheiro. Ambas introduzem risco.

Cenários Reais Onde a Dependência de Formato Prejudica

Cenário 1: Modernização do tema. O tema do seu cliente está sendo reconstruído com blocos Gutenberg. Os antigos templates PHP usavam arquivos .mo. Os novos blocos precisam de .json para wp_set_script_translations(). Suas 3.000 strings traduzidas precisam existir em ambos os formatos durante a transição.

Cenário 2: Fluxo de trabalho da agência. Você gerencia 20 sites de clientes. Alguns usam temas clássicos (.mo). Alguns usam configurações headless (.json). Um usa uma estrutura personalizada que lê arrays PHP. Você precisa das mesmas traduções em diferentes formatos para diferentes clientes.

Cenário 3: Revisão profissional. Suas traduções de IA são 95% precisas, mas você quer que um falante nativo revise os 5% restantes. Tradutores profissionais usam ferramentas CAT que importam .xliff. Você precisa exportar suas traduções para .xliff, enviá-las para revisão e mesclar as correções de volta.

Cenário 4: Migração de plataforma. Seu cliente está migrando do WordPress para um aplicativo Node.js personalizado. O novo aplicativo usa i18next e precisa de arquivos .json. Suas 5.000 strings traduzidas no formato .po precisam ser convertidas — sem perder uma única variável ou forma plural.

A Solução: Traduza Uma Vez, Obtenha Todos os Formatos

SimplePoTranslate adota uma abordagem diferente. Quando você envia um arquivo .po, .pot, .json ou .xliff e executa uma tradução, você recebe de volta um ZIP contendo todos os cinco formatos:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Este não é um "recurso premium" bloqueado atrás de um nível empresarial. Cada plano pago — Pro (US$ 19/mês) e Vitalício (US$ 399 uma única vez) — inclui todos os cinco formatos de saída em cada trabalho de tradução.

Por Que Isso Importa para a Preparação para o Futuro

Quando você tem todos os cinco formatos desde o início, você nunca precisa re-traduzir. Suas traduções são um ativo que se adapta a qualquer requisito técnico:

• Cliente migra do clássico para o Gutenberg? Implante o arquivo .json.
• Novo desenvolvedor prefere arrays PHP? Entregue a ele o arquivo .php.
• Tradutor profissional quer revisar? Envie o arquivo .xliff.
• Mudando para um CMS diferente? Os arquivos .json e .xliff são independentes de plataforma.

Você traduz uma vez. Os formatos estão prontos quando você precisar deles.

Como Cada Formato Funciona no WordPress

Saber qual arquivo vai onde é essencial para uma implantação limpa.

Implantando Arquivos .mo (Temas e Plugins PHP Clássicos)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

O WordPress os carrega automaticamente quando o idioma do site corresponde. Nenhum plugin é necessário. Zero overhead de banco de dados. Esta é a abordagem que oferece o melhor desempenho.

Implantando Arquivos .json (Blocos Gutenberg e Componentes JS)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

O nome do arquivo inclui o identificador do script e um hash MD5. O WordPress os corresponde quando você chama wp_set_script_translations() em seu plugin ou tema. Se você estiver construindo blocos Gutenberg, este é o arquivo que faz com que seus rótulos e descrições de bloco traduzidos apareçam corretamente.

Usando Arquivos .xliff (Fluxo de Trabalho de Revisão Profissional)

Arquivos .xliff não são implantados no WordPress. Eles são usados como um formato de intercâmbio quando você precisa enviar traduções para um revisor profissional ou importá-las para uma ferramenta CAT. O fluxo de trabalho se parece com isto:

1. Envie .po para SimplePoTranslate e obtenha .xliff no ZIP
2. Envie .xliff para seu tradutor ou revisor
3. Receba .xliff corrigido de volta
4. Envie .xliff corrigido para SimplePoTranslate e obtenha .mo e .json atualizados

Este fluxo de trabalho de ida e volta preserva cada variável e forma plural porque o Bloqueio de Sintaxe do SimplePoTranslate os protege em cada etapa.

O Teste de Dependência de Fornecedor

Aqui está um teste simples para determinar se seu fluxo de trabalho de tradução atual tem um problema de dependência:

1. Você pode exportar suas traduções como arquivos .po padrão agora mesmo?
2. Se você cancelar sua assinatura da ferramenta de tradução hoje, você mantém cada string traduzida?
3. Você pode importar suas traduções para uma ferramenta ou plataforma completamente diferente sem re-traduzir?

Se a resposta para qualquer uma destas for "não", você está dependente. Serviços como Weglot e GTranslate falham em todas as três perguntas — cancele a assinatura e suas traduções desaparecem. O WPML armazena as traduções no banco de dados, tornando a exportação possível, mas dolorosa. Até mesmo ferramentas de desktop como o Poedit passam no teste no papel, mas limitam você a .po e .mo apenas.

Com SimplePoTranslate, a resposta para todas as três perguntas é "sim". Você baixa arquivos padrão em cinco formatos. Eles são seus. Exclua sua conta amanhã e cada tradução que você já fez ainda funcionará.

Construindo uma Biblioteca de Tradução Independente de Formato

Para agências e desenvolvedores que gerenciam vários projetos, a abordagem mais inteligente é construir uma biblioteca de tradução — um repositório Git ou pasta compartilhada onde você armazena arquivos traduzidos para cada projeto do cliente.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Quando um cliente precisa de um novo formato, você já o tem. Quando um cliente muda de plataforma, suas traduções migram com zero esforço. Quando um novo desenvolvedor entra para a equipe, ele pode ver exatamente o que foi traduzido e em quais formatos.

Isto é o que "preparado para o futuro" realmente significa — não prever qual tecnologia seus clientes usarão no próximo ano, mas garantir que suas traduções funcionem com o que quer que eles escolham.

Pronto para parar de se preocupar com formatos de arquivo? Experimente o SimplePoTranslate gratuitamente — envie um arquivo, receba cinco formatos de volta. Sem scripts de conversão, sem re-tradução, sem dependência.