I18n de tema e plugin do WordPress: torne o código traduzível

Torne um tema ou plugin do WordPress traduzível: text domain, __() e _n(), um arquivo POT com WP-CLI, e então carregue os arquivos .mo, .json e .l10n.php.

Localize este aplicativo para alemão e espanhol com a PTC.

Deixe seu tema ou plugin do WordPress pronto para tradução. Este guia cobre text domains, funções gettext, geração de POT e o mecanismo de carregamento que coloca as traduções diante dos usuários. A PTC (Private Translation Cloud) então traduz os arquivos de recursos e faz a revisão visual do tema ou plugin renderizado em cada idioma.

Quer traduzir um site WordPress que você gerencia, e não o código que você escreveu? Use o WPML.

Este guia é para desenvolvedores que escrevem o código. Se você já tem um arquivo POT ou PO e só precisa traduzi-lo, vá para a página de arquivos PO para o fluxo de trabalho de 3 etapas.

Ao final deste guia, seu tema ou plugin estará:

• Internacionalizado corretamente de acordo com os padrões de codificação do WordPress.
• Traduzível pela PTC para mais de 40 idiomas.
• Distribuível via pacotes de idioma do WordPress.org.
• Verificável em cada lançamento com a revisão visual de tradução da PTC.

O que é a internacionalização do WordPress?

A internacionalização (i18n) é o trabalho de preparar seu código para que ele possa ser traduzido. A localização (l10n) é a próxima etapa. Ela produz as strings traduzidas reais para idiomas específicos.

Para temas e plugins do WordPress, i18n significa três coisas:

• Envolver cada string voltada para o usuário em funções gettext para que o WordPress possa trocá-las em tempo de execução.
• Definir um text domain que vincula suas traduções ao seu projeto.
• Gerar um arquivo POT a partir do qual os tradutores (ou a PTC) trabalham.

Uma vez que esse trabalho esteja concluído, você tem tudo o que precisa para produzir arquivos PO, MO, JSON e .l10n.php traduzidos para qualquer idioma.

A PTC traduz arquivos POT para MO, JSON e .l10n.php para o WordPress

Cinco extensões de arquivo aparecem em qualquer fluxo de trabalho de tradução do WordPress. A PTC traduz de .pot (sua origem) para .po, .mo, .json e .l10n.php para cada idioma de destino. Cada formato tem um papel específico:

• POT (Portable Object Template). O arquivo de origem gerado a partir do seu código. Ele lista cada string traduzível sem traduções anexadas. Você entrega isso à PTC.
• PO (Portable Object). Uma cópia do POT com traduções adicionadas para um idioma específico. Texto simples, legível por humanos. A PTC retorna um PO por idioma de destino.
• MO (Machine Object). A versão binária compilada de um PO. O WordPress lê arquivos MO em tempo de execução porque eles carregam mais rápido que o texto PO.
• JSON. O equivalente em JavaScript do MO. O WordPress não consegue ler MO a partir do JavaScript, então o pipeline de build produz arquivos JSON para as strings do lado do navegador.
• .l10n.php. Uma alternativa mais recente ao MO, introduzida no WordPress 6.5. Ele carrega mais rápido e usa menos memória. O WordPress o escolhe automaticamente quando um existe ao lado do arquivo MO.

Ative .l10n.php para novos projetos. Ele é estritamente melhor que o MO nas versões suportadas do WordPress.

Por que a tradução da comunidade não é suficiente

O WordPress.org oferece tradução da comunidade através do GlotPress. Na prática, isso cobre uma pequena fração do que a maioria dos plugins e temas precisa. Uma análise de mais de 60.000 plugins e temas do WordPress descobriu que a tradução da comunidade cobre menos de 5% das necessidades de tradução em 40 idiomas.

Dois problemas estruturais explicam a lacuna:

• Voluntários são escassos na maioria dos locales. Um punhado de plugins com bases de usuários massivas atrai tradutores. A maioria, não.
• As traduções podem levar meses ou anos para aparecer, se é que aparecem. Se você quer que os usuários vejam seu plugin ou tema no idioma deles desde o primeiro dia, você não pode depender da comunidade.

Este guia pressupõe que você deseja uma cobertura de tradução completa e consistente em um cronograma de lançamentos que você controla. É isso que a PTC oferece.

Preparando seu tema ou plugin do WordPress para tradução

Um text domain incompatível ou uma string não envolvida significa que o texto nunca aparecerá na sua saída traduzida. Os detalhes importam.

Etapa 1: Defina seu text domain e caminho do domínio

Todo tema ou plugin precisa de um text domain. O text domain é um identificador exclusivo que diz ao WordPress quais arquivos de tradução pertencem ao seu projeto. Ele deve corresponder exatamente ao slug do seu plugin ou tema.

Declare-o no cabeçalho do arquivo principal do seu plugin:

<?php
/**
 * Plugin Name: My Plugin
 * Description: An example plugin.
 * Version: 1.0.0
 * Text Domain: my-plugin
 * Domain Path: /languages
 */

Ou no style.css do seu tema:

/*
Theme Name: My Theme
Text Domain: my-theme
Domain Path: /languages
*/

O caminho do domínio diz ao WordPress onde seus arquivos de tradução residem em relação à raiz do plugin ou tema. /languages é o padrão.

Etapa 2: Envolva suas strings PHP em funções gettext

Qualquer string que você queira que seja traduzível precisa ser envolvida em uma das funções gettext do WordPress. Em tempo de execução, essas funções buscam a tradução correta. Se nenhuma for encontrada, elas fazem o fallback para a string original.

Strings básicas. Use __() quando precisar retornar uma string. Para saída HTML, use as variantes escapadas. Os padrões de codificação do WordPress recomendam echo esc_html__() em vez de _e(). A forma escapada torna o escape de saída explícito e previne XSS no ponto de saída:

// Return a translated string
$label = __( 'Settings', 'my-plugin' );

// Echo a translated string, escaped for HTML
echo esc_html__( 'Settings saved.', 'my-plugin' );

Strings com variáveis. Não concatene variáveis em strings. Os tradutores veem apenas fragmentos e não conseguem reordenar as palavras para idiomas com sintaxe diferente. Use printf() ou sprintf() com um placeholder. Adicione um comentário de tradutor para que os tradutores saibam o que %s representa:

printf(
    /* translators: %s: the user's display name */
    esc_html__( 'Welcome back, %s.', 'my-plugin' ),
    esc_html( $display_name )
);

Formas plurais. Os plurais em inglês são simples (one comment, two comments). Outros idiomas não são. Use _n() para lidar com todas as regras de plural que o WordPress conhece:

printf(
    esc_html( _n( '%s comment', '%s comments', $count, 'my-plugin' ) ),
    number_format_i18n( $count )
);

Strings que precisam de contexto. Algumas palavras significam coisas diferentes dependendo de onde aparecem. Use _x() para dar aos tradutores o contexto de que precisam:

// "Export" as a noun (the file) vs. a verb (the action)
echo esc_html_x( 'Export', 'button label', 'my-plugin' );

Etapa 3: Internacionalize suas strings JavaScript

O WordPress fornece o pacote wp-i18n para que você possa usar as mesmas funções gettext em JavaScript que você usa em PHP. Ao registrar seu script, declare wp-i18n como uma dependência:

wp_register_script(
    'my-plugin-script',
    plugins_url( 'js/app.js', __FILE__ ),
    array( 'wp-i18n' ),
    '1.0.0',
    true
);

Então, no seu arquivo JavaScript:

const { __, _n, sprintf } = wp.i18n;

const message = __( 'Settings saved.', 'my-plugin' );

Se você usa um empacotador como o Webpack, instale o @wordpress/babel-plugin-makepot. Ele extrai as strings traduzíveis do seu bundle como parte do seu build.

Etapa 4: Gere seu arquivo POT

Uma vez que suas strings estejam envolvidas, gere um arquivo POT. O POT é o arquivo de origem a partir do qual a PTC (ou qualquer tradutor) trabalha. Ele contém cada string traduzível, mas nenhuma tradução.

wp i18n make-pot . languages/my-plugin.pot

O WP-CLI verifica seus arquivos PHP, JavaScript e block.json em busca de chamadas gettext. Ele as compila em um único POT. Se sua equipe usa o Composer, adicione este comando como um script do Composer. Isso mantém o uso do WP-CLI consistente em toda a equipe sem uma instalação global.

O conjunto completo de comandos wp i18n cobre o restante do pipeline:

Você não precisa do Poedit. Tudo neste fluxo de trabalho é executado através do WP-CLI e da PTC. O WP-CLI lida com a geração do POT e a compilação de MO/JSON. A PTC lida com a tradução e retorna todos os formatos de arquivo de que o WordPress precisa. O Poedit é um editor de desktop útil para tradução manual, mas não faz parte deste fluxo de trabalho.

Traduzindo arquivos POT com a PTC

A PTC foi criada pensando nos desenvolvedores do WordPress. Comece com um arquivo POT e receba de volta arquivos de tradução prontos para produção. O teste de 30 dias cobre até 20.000 palavras em dois idiomas.

Configure seu primeiro projeto de tradução

Faça o upload do seu arquivo POT. Escolha quais formatos de saída você precisa. A PTC retorna qualquer combinação de:

• Arquivos .po para cada idioma de destino.
• Arquivos .mo, compilados e prontos para envio.
• Arquivos .json para suas strings JavaScript.
• Arquivos .l10n.php para um carregamento mais rápido no WordPress 6.5+.

O assistente de configuração pede que você descreva seu tema ou plugin. A PTC usa a descrição para gerar traduções com o tom e contexto certos. Adicione termos específicos da marca ao glossário nesta etapa. O glossário mantém nomes, rótulos de recursos e qualquer outra terminologia consistentes em todos os idiomas.

A PTC analisa a estrutura gettext no upload. Ela reconhece placeholders (%s, %1$s, %d), formas plurais (entradas extraídas com _n() com seu cabeçalho Plural-Forms) e contextos (entradas _x() com msgctxt). Ela então gera as categorias de plural corretas por idioma. O polonês recebe one / few / many / other. O japonês recebe apenas other. O árabe recebe seis formas.

Mude para a localização contínua

Assim que seus primeiros arquivos forem traduzidos, faça o upgrade para o Pay-As-You-Go. Conecte a PTC ao seu repositório do GitHub, GitLab ou Bitbucket. A partir desse ponto, você não faz upload de arquivos manualmente.

Faça o commit de um .ptc-config.yml nomeando seu arquivo de origem e a qual lugar as traduções pertencem:

# .ptc-config.yml
source_locale: en
files:
  - file: languages/my-plugin.pot
    output: languages/my-plugin-{{lang}}.po
    additional_translation_files:
      - type: mo
        path: languages/my-plugin-{{lang}}.mo

Em seguida, adicione a ação PTC Translate ao seu fluxo de trabalho. Ela carrega uma versão fixada da PTC CLI dentro de si, para que seu build não baixe nada em tempo de execução:

# .github/workflows/translate.yml
name: Regenerate POT for PTC
on:
  push:
    branches: [main]
    paths:
      - 'languages/my-plugin.pot'
  workflow_dispatch: {}

jobs:
  translate:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - name: Generate POT
        run: |
          wp i18n make-pot . languages/my-plugin.pot --domain=my-plugin
      - uses: OnTheGoSystems/ptc-action@v1
        with:
          api-token: ${{ secrets.PTC_API_TOKEN }}
          create-pr: true

Você tem duas maneiras de automatizar isso. Com a integração com Git, a PTC monitora seu repositório e abre um merge request com as traduções atualizadas sempre que o arquivo de origem muda. Para executar a tradução dentro do seu próprio job de CI, use a PTC CLI - ela faz o upload do arquivo alterado, espera a tradução terminar e baixa os arquivos traduzidos. Modelos de fluxo de trabalho prontos para GitHub Actions, GitLab CI e Bitbucket Pipelines estão no guia de configuração do pipeline de CI/CD.

Qualquer um dos fluxos entrega um merge request ou um download com os arquivos .po, .mo, .json e .l10n.php atualizados. Consulte a referência da API da PTC para ver o webhook completo e a API REST.

Fazer ou não o commit de arquivos .mo no seu repositório depende da política da equipe. Muitos plugins os geram no momento do lançamento. A integração de CI da PTC os produz a cada execução de tradução. Faça o check-in deles apenas se quiser os arquivos traduzidos no histórico de versões.

Carregando traduções no WordPress

Com os arquivos traduzidos em mãos, coloque-os corretamente e diga ao WordPress onde encontrá-los. O nome do arquivo vem primeiro. O WordPress procura arquivos de tradução usando um padrão de nomenclatura específico. Um nome de arquivo que não corresponda significa que o arquivo não será carregado.

Acertando os nomes dos seus arquivos

Os códigos de locale seguem o formato language_COUNTRY. de_DE é alemão (Alemanha). fr_FR é francês (França). pt_BR é português (Brasil). zh_CN é chinês simplificado. O portal de tradução do WordPress lista todos os locales suportados.

O nome de arquivo esperado depende de onde você coloca o arquivo:

Os temas usam uma convenção de nomenclatura mais curta quando os arquivos são empacotados dentro do tema. No diretório global de idiomas, tanto plugins quanto temas usam o padrão {text-domain}-{locale}.

Carregando traduções para plugins (PHP)

Registre as traduções com o WordPress no hook init. Não use plugins_loaded. Ele aciona um aviso de descontinuação nas versões atuais do WordPress:

add_action( 'init', function () {
    load_plugin_textdomain(
        'my-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages/'
    );
} );

Carregando traduções para temas (PHP)

Use load_theme_textdomain() conectado a after_setup_theme:

add_action( 'after_setup_theme', function () {
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );
} );

Carregando traduções em JavaScript

Depois de registrar seu script (Etapa 3 acima), chame wp_set_script_translations(). O WordPress então carrega as traduções em JSON para esse handle de script:

add_action( 'init', function () {
    wp_set_script_translations(
        'my-plugin-script',
        'my-plugin',
        plugin_dir_path( __FILE__ ) . 'languages'
    );
} );

Verifique o carregamento

1. Defina o idioma do seu site WordPress para um locale de destino. A configuração está em Configurações > Geral > Idioma do site.
2. Recarregue o front-end e as páginas de administração que seu plugin ou tema renderiza.
3. As strings envolvidas em __() ou esc_html__() devem aparecer no novo idioma.

Se algo estiver faltando, veja Traduções de plugin do WordPress não aparecem? Corrija traduções ausentes para as causas mais comuns.

Levando suas traduções aos usuários: dois caminhos

Uma vez que a PTC tenha traduzido seus arquivos, você os envia de uma de duas maneiras.

Caminho 1: Publique as traduções através dos pacotes de idioma do WordPress.org (CLPTE)

Tempo total: 4-6 dias.

Etapa 1: Crie uma conta CLPTE

A função CLPTE (Cross-Locale Project Translation Editor) permite que você envie traduções em nome do seu tema ou plugin em todos os idiomas de destino a partir de uma única conta. Uma conta normal de Editor de Tradução é por idioma; a CLPTE não é.

Se você já tem uma conta no WordPress.org, pode encontrar um problema em que sua nova conta CLPTE é desativada. O WordPress não permite múltiplas contas. Para resolver, envie um e-mail para forum-password-resets@wordpress.org e explique que você está tentando criar uma conta CLPTE. Compartilhar a documentação relevante dos Polyglots com o moderador e notificar a equipe dos Polyglots no Slack ajudam.

Tempo estimado: ~3-5 dias (inclui o tempo de espera se sua nova conta for desativada).

Etapa 2: Solicite acesso CLPTE no blog dos Polyglots

Com sua conta ativada, publique uma solicitação no blog dos Polyglots do WordPress.org. Siga o modelo deles:

PTE/CLPTE Request

Plugin URL: https://wordpress.org/plugins/my-plugin/
Authors / Editors: @your-wp-username
Type of request: CLPTE

Você recebe uma notificação quando sua solicitação for aprovada.

Tempo estimado: ~1 dia (a Equipe Global dos Polyglots analisa as solicitações em lotes).

Etapa 3: Importe os arquivos .po traduzidos

1. Faça login em https://translate.wordpress.org/ usando sua conta CLPTE.
2. Vá para a página do projeto de tradução do seu plugin ou tema (por exemplo, translate.wordpress.org/projects/wp-plugins/{your-plugin-slug}/).
3. Abra o projeto local para cada idioma que você traduziu.
4. Role para baixo e clique em Importar traduções.
5. Faça o upload do seu arquivo .po (ou .mo).
6. Marque as strings importadas como “current” no editor de tradução. As strings aprovadas entram na próxima geração do pacote de idioma (geralmente diária).
7. Repita para cada idioma de destino. Cada locale tem sua própria página de tradução.

Tempo estimado: ~10-30 minutos por idioma.

Após uma janela de 24-48 horas do pacote de idioma, os sites que executam seu plugin começam a receber as novas traduções através das atualizações automáticas de pacotes de idioma do WordPress. Os usuários não veem nenhum aviso de atualização. As traduções simplesmente aparecem.

O que a CLPTE fará e não fará por você

• Você não pode substituir as traduções da comunidade existentes. Apenas strings não traduzidas são importadas. Atualizar uma tradução da comunidade existente requer o processo padrão e aguardar a revisão da equipe do locale.
• As atualizações exigem uploads manuais para cada lançamento. Cada novo lançamento significa uma nova rodada de uploads.
• A criação e aprovação da conta geralmente levam de 4 a 6 dias no total.

Caminho 2: Empacote os arquivos .mo dentro do seu plugin ou tema

Se você precisa que as traduções entrem no ar mais rápido do que a CLPTE permite, ou se prefere não depender do pipeline de distribuição do WordPress.org, empacote os arquivos .mo diretamente no lançamento do seu plugin ou tema. Tempo total: 15-30 minutos.

Etapa 1: Adicione os arquivos .mo ao diretório /languages/

Coloque seus arquivos .mo compilados dentro do diretório /languages/ do seu plugin ou tema para que o WordPress os encontre ao carregar seu text domain:

my-plugin/
├─ my-plugin.php
├─ readme.txt
├─ languages/
│  ├─ my-plugin-es_ES.mo
│  ├─ my-plugin-es_ES.po
│  ├─ my-plugin-fr_FR.mo
│  ├─ my-plugin-fr_FR.po
│  ├─ my-plugin-de_DE.mo
│  └─ my-plugin-de_DE.po

Use o mesmo text domain nos nomes dos seus arquivos de tradução e nas suas chamadas load_plugin_textdomain() ou load_theme_textdomain().

Etapa 2: Dê preferência aos seus arquivos empacotados em vez das traduções da comunidade

Por padrão, o WordPress prioriza as traduções da comunidade do WordPress.org sobre as empacotadas. Para garantir que seu plugin ou tema use os arquivos .mo empacotados, adicione o filtro load_textdomain_mofile.

Para plugins, adicione ao arquivo principal do seu plugin (por exemplo, my-plugin.php):

function my_plugin_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/plugins/' ) ) {
        $locale = apply_filters( 'plugin_locale', determine_locale(), $domain );
        $local_mofile = WP_PLUGIN_DIR . '/' . dirname( plugin_basename( __FILE__ ) ) .
                        '/languages/' . $domain . '-' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_plugin_load_embedded_translation_file', 10, 2 );

Para temas, adicione ao functions.php do seu tema:

function my_theme_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/themes/' ) ) {
        $locale = apply_filters( 'theme_locale', determine_locale(), $domain );
        $local_mofile = get_template_directory() . '/languages/' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_theme_load_embedded_translation_file', 10, 2 );

Confirme também que seu plugin ou tema carrega o text domain no hook certo:

add_action( 'init', function() {
    load_plugin_textdomain(
        'my-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages'
    );
} );

Etapa 3: Verifique se as traduções empacotadas carregam em um site de teste

Instale seu plugin ou tema em um site de teste e mude o WordPress para um dos idiomas que você forneceu:

1. Vá para Configurações > Geral > Idioma do site e selecione um idioma cujo arquivo .mo esteja na sua pasta /languages/.
2. Carregue uma página ou tela que contenha strings que você sabe que estão traduzidas.
3. Confirme se as strings aparecem no idioma correto e correspondem às traduções que você adicionou.

Se você ainda vir traduções da comunidade antigas, revise o trecho na Etapa 2. Ele precisa apontar o WordPress corretamente para seus arquivos .mo empacotados.

Faça o commit dos arquivos .mo, crie a tag de um lançamento e faça o push para o wordpress.org via SVN como você normalmente faz.

O compromisso entre velocidade e distribuição canônica

• Pró: instantâneo. As novas traduções entram no ar no momento em que os usuários atualizam seu plugin (ou o instalam pela primeira vez). Sem espera de vários dias pela CLPTE. Sem ciclo de aprovação da equipe Polyglots.
• Pró: você controla o fluxo de trabalho. A cadência de tradução corresponde exatamente à sua cadência de lançamentos.
• Pró: sem dependência do selo do plugin. As traduções funcionam independentemente de o seu plugin ter ou não permissões CLPTE.
• Contra: o tamanho do arquivo do plugin cresce. Cada .mo é pequeno (geralmente 5-50 KB), mas 20 idiomas adicionam ~500 KB ao download.
• Contra: sem atualização automática de traduções entre lançamentos de plugins. Com a CLPTE, as traduções atualizadas no wordpress.org se propagam para os usuários em 48 horas, mesmo se você não enviar um novo lançamento. Com o empacotamento, as traduções só são atualizadas quando você envia um novo lançamento.
• Contra: sem selo “traduzido”. O WordPress.org exibe um selo de conclusão de tradução nas listagens de plugins com base na cobertura do pacote de idioma, não nos arquivos .mo empacotados. O empacotamento por si só não rende o selo.

Qual caminho corresponde à sua cadência de lançamentos?

A abordagem dupla é comum: empacote os arquivos MO para disponibilidade imediata e envie para a CLPTE para distribuição canônica. Os usuários recebem as traduções empacotadas na atualização; a sobreposição do pacote de idioma as atualiza entre os lançamentos.

Idiomas da direita para a esquerda e layouts bidirecionais

O fluxo de trabalho de tradução é o mesmo para idiomas da direita para a esquerda (RTL). Árabe, hebraico, persa e urdu usam o mesmo pipeline POT/PO/MO.

A etapa extra é garantir que seu tema suporte estilos RTL. O WordPress carrega automaticamente um arquivo rtl.css se houver um no diretório do seu tema. Use a função is_rtl() para aplicar condicionalmente estilos ou scripts específicos para RTL.

Localizando datas, números e moedas

Uma string traduzida não é toda a história. Datas, números e moedas também devem seguir o locale do usuário. Use as funções de formatação integradas do WordPress em vez das nativas do PHP:

• date_i18n() formata datas de acordo com o locale ativo.
• number_format_i18n() formata números com separadores decimais e de milhares sensíveis ao locale.

Essas funções não fazem parte do fluxo de trabalho do arquivo de tradução. Elas são importantes para uma experiência totalmente localizada.

Internacionalizando blocos do Editor de blocos (Gutenberg)

Os blocos adicionam duas etapas extras ao pipeline padrão:

• As traduções em JavaScript precisam de um arquivo .json por locale. Gere-o a partir do .po com wp i18n make-json.
• O script do editor do bloco precisa de wp_set_script_translations() em PHP. Isso diz ao WordPress para servir o JSON ao bloco.

A saída renderizada pelo bloco no front-end usa as mesmas chamadas __() que o restante do seu PHP. Nenhum trabalho extra aí.

Traduzindo seu README e a página do WordPress.org

Seu readme.txt não é um arquivo de recursos. O WP-CLI não o pegará ao gerar um POT. Para traduzi-lo, use o recurso Paste to Translate da PTC. Cole o conteúdo, escolha seus idiomas de destino e faça o download do resultado. Os e-mails voltados para o cliente enviados pelo plugin e a descrição da página do plugin no WordPress.org são traduzidos da mesma forma, tudo no mesmo projeto para que a terminologia permaneça consistente.

Se seu plugin ou tema estiver listado no WordPress.org, a descrição traduzida aparece na aba Detalhes do plugin no idioma do usuário. Para que as traduções entrem no ar lá, siga o processo de importação do WordPress.org.

Traduza o conteúdo do usuário do plugin com a API da PTC

Os plugins que armazenam dados gerados por usuários (plugins de fórum, plugins de avaliação, plugins de comentários) podem traduzir esse conteúdo à medida que ele chega. A API REST da PTC traduz postagens, comentários e avaliações de usuários sob demanda com autenticação por token Bearer, usando o mesmo glossário e voz da marca que seus arquivos .po.

Revisão visual de tradução do seu tema ou plugin renderizado - lance sem QA manual por idioma

Um arquivo .po traduzido é necessário, mas não é suficiente. O tema ou plugin traduzido ainda precisa de verificação:

• Um rótulo traduzido pode causar um estouro em um botão da página de configurações em alemão.
• “Submit” (Enviar) pode ser traduzido como um substantivo em francês quando a ação de administração precisava de um verbo.
• Uma string em inglês hardcoded fora de __() será renderizada sem tradução, independentemente de quantos idiomas você lance.

A revisão visual de tradução da PTC substitui a execução do QA manual. Temas e plugins do WordPress são renderizados no navegador (tanto o wp-admin quanto o front-end). A variante certa é a extensão do navegador.

Instale-a uma vez. Faça um percurso gravado do seu tema ou plugin em um site de teste. Cubra páginas de configurações, ações de administração e a saída do front-end. A PTC repete a gravação em cada idioma de destino após cada atualização de tradução. Ela captura cada tela e relata dois tipos de correções:

• Correções nos arquivos .po quando a PTC os controla. A PTC retraduz uma acepção incorreta, escolhe um sinônimo mais curto que caiba em um botão ou regenera uma forma plural.
• Prompts do Cursor ou Claude Code quando o problema reside no seu código PHP ou JavaScript. Exemplos incluem um wrapper __() ausente, uma string hardcoded em inglês ou uma frase construída por concatenação que deveria usar sprintf( __( ... ) ).

Você lança um plugin multilíngue verificado por lançamento. O trabalho residual de QA manual desaparece.

Preços: teste de 30 dias, depois Pay-As-You-Go

O teste cobre 20.000 palavras em 2 idiomas sem cartão de crédito. Quando o teste termina, a PTC oferece o Pay-As-You-Go. Sem assinatura. Sem compromisso mínimo. As primeiras 500 palavras de cada mês são gratuitas. Você só paga pelo resto. A página de preços tem uma calculadora de custos. Cadastre-se com um e-mail corporativo para um teste comercial estendido.

Pronto para lançar um plugin ou tema verificado?

A PTC gera as traduções e revisa o plugin renderizado. Você confirma o resultado e lança. O ciclo completo é executado sem QA manual:

1. Gere seu arquivo .pot com wp i18n make-pot.
2. Faça o upload dele para a PTC e receba de volta os arquivos .po, .mo, .l10n.php e .json em minutos.
3. Instale a extensão do navegador para verificar o plugin em execução em cada idioma de destino.

Comece seu teste de 30 dias - 20.000 palavras por nossa conta, sem necessidade de cartão de crédito.

Relacionados:

• Traduza arquivos PO online com IA - a página canônica de tradução de PO/POT.
• GlotPress vs PTC para tradução de plugin/tema do WordPress - quando escolher a tradução da comunidade vs PTC.
• Traduções de plugin do WordPress não aparecem? Corrija traduções ausentes - guia de solução de problemas.
• Como importar traduções de temas e plugins para o WordPress.org - processo CLPTE e uma alternativa mais rápida.
• Referência da API da PTC - endpoints REST para integração de CI.

Última atualização: 11 de novembro de 2026