I18n de temas y plugins de WordPress: haga que el código sea traducible

Haga que un tema o plugin de WordPress sea traducible: dominio de texto, __() y _n(), un archivo POT con WP-CLI y, a continuación, cargue los archivos .mo, .json y .l10n.php.

Localiza esta aplicación al alemán y al español con PTC.

Prepare su tema o plugin de WordPress para la traducción. Esta guía cubre los dominios de texto, las funciones gettext, la generación de POT y el mecanismo de carga que pone las traducciones a disposición de los usuarios. A continuación, PTC (Private Translation Cloud) traduce los archivos de recursos y revisa visualmente el tema o plugin renderizado en cada idioma.

¿Desea traducir un sitio de WordPress que administra, no el código que escribió? Utilice WPML.

Esta guía es para los desarrolladores que escriben el código. Si ya tiene un archivo POT o PO y solo necesita traducirlo, diríjase a la página de archivos PO para ver el flujo de trabajo de 3 pasos.

Al final de esta guía, su tema o plugin estará:

• Internacionalizado correctamente según los estándares de codificación de WordPress.
• Listo para que PTC lo traduzca a 40 o más idiomas.
• Listo para distribuir mediante los paquetes de idiomas de WordPress.org.
• Verificable en cada lanzamiento con la revisión visual de la traducción de PTC.

¿Qué es la internacionalización de WordPress?

La internacionalización (i18n) es el trabajo de preparar su código para que pueda ser traducido. La localización (l10n) es el siguiente paso. Produce las cadenas traducidas reales para idiomas específicos.

Para los temas y plugins de WordPress, la i18n significa tres cosas:

• Envolver cada cadena orientada al usuario en funciones gettext para que WordPress pueda intercambiarlas en tiempo de ejecución.
• Definir un dominio de texto que vincule sus traducciones a su proyecto.
• Generar un archivo POT a partir del cual trabajen los traductores (o PTC).

Una vez realizado ese trabajo, tiene todo lo que necesita para producir archivos PO, MO, JSON y .l10n.php traducidos para cualquier idioma.

PTC traduce archivos POT a MO, JSON y .l10n.php para WordPress

En cualquier flujo de trabajo de traducción de WordPress aparecen cinco extensiones de archivo. PTC traduce desde .pot (su origen) a .po, .mo, .json y .l10n.php para cada idioma de destino. Cada formato tiene una función específica:

• POT (Portable Object Template). El archivo de origen generado a partir de su código. Enumera cada cadena traducible sin traducciones adjuntas. Usted entrega esto a PTC.
• PO (Portable Object). Una copia del POT con traducciones añadidas para un idioma específico. Texto sin formato, legible por humanos. PTC devuelve un PO por idioma de destino.
• MO (Machine Object). La versión binaria compilada de un PO. WordPress lee los archivos MO en tiempo de ejecución porque se cargan más rápido que el texto PO.
• JSON. El equivalente en JavaScript de MO. WordPress no puede leer MO desde JavaScript, por lo que el pipeline de compilación produce archivos JSON para las cadenas del lado del navegador.
• .l10n.php. Una alternativa más reciente a MO, introducida en WordPress 6.5. Se carga más rápido y utiliza menos memoria. WordPress lo elige automáticamente cuando existe uno junto al archivo MO.

Active .l10n.php para los proyectos nuevos. Es estrictamente mejor que MO en las versiones compatibles de WordPress.

Por qué la traducción de la comunidad no es suficiente

WordPress.org ofrece traducción de la comunidad a través de GlotPress. En la práctica, cubre una pequeña fracción de lo que necesitan la mayoría de los plugins y temas. Un análisis de más de 60.000 plugins y temas de WordPress descubrió que la traducción de la comunidad cubre menos del 5 % de las necesidades de traducción en 40 idiomas.

Dos problemas estructurales explican la brecha:

• Los voluntarios son escasos en la mayoría de las configuraciones regionales. Un puñado de plugins con bases de usuarios masivas atraen a los traductores. La mayoría no lo hace.
• Las traducciones pueden tardar meses o años en aparecer, si es que aparecen. Si desea que los usuarios vean su plugin o tema en su idioma desde el primer día, no puede depender de la comunidad.

Esta guía asume que desea una cobertura de traducción completa y coherente en un calendario de lanzamientos que usted controle. Eso es lo que ofrece PTC.

Cómo preparar su tema o plugin de WordPress para la traducción

Un dominio de texto que no coincide o una cadena sin envolver significa que el texto nunca aparecerá en su resultado traducido. Los detalles importan.

Paso 1: Defina su dominio de texto y la ruta del dominio

Cada tema o plugin necesita un dominio de texto. El dominio de texto es un identificador único que indica a WordPress qué archivos de traducción pertenecen a su proyecto. Debe coincidir exactamente con el slug de su plugin o tema.

Declárelo en el encabezado del archivo principal de su plugin:

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

O en el archivo style.css de su tema:

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

La ruta del dominio indica a WordPress dónde residen sus archivos de traducción en relación con la raíz del plugin o tema. /languages es el estándar.

Paso 2: Envuelva sus cadenas PHP en funciones gettext

Cualquier cadena que desee que sea traducible debe estar envuelta en una de las funciones gettext de WordPress. En tiempo de ejecución, esas funciones buscan la traducción correcta. Si no se encuentra ninguna, recurren a la cadena original.

Cadenas básicas. Utilice __() cuando necesite devolver una cadena. Para la salida HTML, utilice las variantes escapadas. Los estándares de codificación de WordPress recomiendan echo esc_html__() en lugar de _e(). La forma escapada hace que el escape de salida sea explícito y evita el XSS en el punto de salida:

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

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

Cadenas con variables. No concatene variables en las cadenas. Los traductores solo ven fragmentos y no pueden reordenar las palabras para idiomas con sintaxis diferente. Utilice printf() o sprintf() con un marcador de posición. Añada un comentario para el traductor para que los traductores sepan qué representa %s:

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

Formas plurales. Los plurales en inglés son sencillos (un comentario, dos comentarios). En otros idiomas no lo son. Utilice _n() para procesar todas las reglas de plurales que conoce WordPress:

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

Cadenas que necesitan contexto. Algunas palabras significan cosas diferentes dependiendo de dónde aparezcan. Utilice _x() para dar a los traductores el contexto que necesitan:

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

Paso 3: Internacionalice sus cadenas de JavaScript

WordPress proporciona el paquete wp-i18n para que pueda utilizar en JavaScript las mismas funciones gettext que utiliza en PHP. Al registrar su script, declare wp-i18n como dependencia:

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

Luego, en su archivo JavaScript:

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

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

Si utiliza un bundler como Webpack, instale @wordpress/babel-plugin-makepot. Extrae las cadenas traducibles de su bundle como parte de su compilación.

Paso 4: Genere su archivo POT

Una vez que sus cadenas estén envueltas, genere un archivo POT. El POT es el archivo de origen a partir del cual trabaja PTC (o cualquier traductor). Contiene todas las cadenas traducibles, pero ninguna traducción.

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

WP-CLI escanea sus archivos PHP, JavaScript y block.json en busca de llamadas gettext. Los compila en un único POT. Si su equipo utiliza Composer, añada este comando como un script de Composer. Eso mantiene el uso de WP-CLI de forma coherente en todo el equipo sin una instalación global.

El conjunto completo de comandos wp i18n cubre el resto del pipeline:

No necesita Poedit. Todo en este flujo de trabajo se ejecuta a través de WP-CLI y PTC. WP-CLI procesa la generación de POT y la compilación de MO/JSON. PTC procesa la traducción y devuelve todos los formatos de archivo que WordPress necesita. Poedit es un editor de escritorio útil para la traducción manual, pero no forma parte de este flujo de trabajo.

Cómo traducir archivos POT con PTC

PTC está creado pensando en los desarrolladores de WordPress. Comience con un archivo POT y reciba archivos de traducción listos para producción. La prueba de 30 días cubre hasta 20.000 palabras en dos idiomas.

Configure su primer proyecto de traducción

Suba su archivo POT. Elija qué formatos de salida necesita. PTC devuelve cualquier combinación de:

• Archivos .po para cada idioma de destino.
• Archivos .mo, compilados y listos para publicar.
• Archivos .json para sus cadenas de JavaScript.
• Archivos .l10n.php para una carga más rápida en WordPress 6.5+.

El asistente de configuración le pide que describa su tema o plugin. PTC utiliza la descripción para generar traducciones con el tono y el contexto adecuados. Añada términos específicos de la marca al glosario en esta etapa. El glosario mantiene los nombres, las etiquetas de funciones y cualquier otra terminología de forma coherente en todos los idiomas.

PTC analiza la estructura gettext al subir el archivo. Reconoce los marcadores de posición (%s, %1$s, %d), las formas plurales (entradas extraídas con _n() con su encabezado Plural-Forms) y los contextos (entradas _x() con msgctxt). A continuación, genera las categorías de plural correctas por idioma. El polaco obtiene one / few / many / other. El japonés obtiene solo other. El árabe obtiene seis formas.

Pase a la localización continua

Una vez que sus primeros archivos estén traducidos, cambie al pago al consumo. Conecte PTC a su repositorio de GitHub, GitLab o Bitbucket. A partir de ese momento, no subirá archivos manualmente.

Haga un commit de un .ptc-config.yml nombrando su archivo de origen y a dónde pertenecen las traducciones:

# .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

A continuación, añada la acción PTC Translate a su flujo de trabajo. Lleva una versión fijada de la CLI de PTC en su interior, por lo que su compilación no descarga nada en tiempo de ejecución:

# .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

Tiene dos formas de automatizar esto. Con la integración con Git, PTC vigila su repositorio y abre un merge request con las traducciones actualizadas cada vez que cambia el archivo de origen. Para ejecutar la traducción dentro de su propio trabajo de CI en su lugar, utilice la CLI de PTC: sube el archivo modificado, espera a que termine la traducción y descarga los archivos traducidos. Las plantillas de flujo de trabajo listas para usar para GitHub Actions, GitLab CI y Bitbucket Pipelines se encuentran en la guía de configuración del pipeline de CI/CD.

Cualquiera de los dos flujos entrega un merge request o una descarga con los archivos .po, .mo, .json y .l10n.php actualizados. Consulte la referencia de la API de PTC para ver el webhook completo y la API REST.

El hecho de hacer commit de los archivos .mo en su repositorio depende de la política del equipo. En su lugar, muchos plugins los generan en el momento del lanzamiento. La integración de CI de PTC los produce en cada ejecución de traducción. Regístrelos en el control de versiones solo si desea archivos traducidos en el historial de versiones.

Cómo cargar traducciones en WordPress

Con los archivos traducidos en la mano, colóquelos correctamente e indique a WordPress dónde encontrarlos. El nombre del archivo es lo primero. WordPress busca archivos de traducción utilizando un patrón de nomenclatura específico. Un nombre de archivo que no coincida significa que el archivo no se cargará.

Cómo usar los nombres de archivo correctos

Los códigos de locale siguen el formato language_COUNTRY. de_DE es alemán (Alemania). fr_FR es francés (Francia). pt_BR es portugués (Brasil). zh_CN es chino (simplificado). El portal de traducción de WordPress enumera cada locale compatible.

El nombre de archivo esperado depende de dónde coloque el archivo:

Los temas utilizan una convención de nomenclatura más corta cuando los archivos se incluyen en el paquete del tema. En el directorio de idiomas global, tanto los plugins como los temas utilizan el patrón {text-domain}-{locale}.

Cómo cargar traducciones para plugins (PHP)

Registre las traducciones en WordPress en el hook init. No utilice plugins_loaded. Desencadena una advertencia de obsolescencia en las versiones actuales de WordPress:

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

Cómo cargar traducciones para temas (PHP)

Utilice load_theme_textdomain() enganchado a after_setup_theme:

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

Cómo cargar traducciones de JavaScript

Después de registrar su script (Paso 3 anterior), llame a wp_set_script_translations(). A continuación, WordPress carga las traducciones JSON para ese identificador de script:

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

Verifique la carga

1. Establezca el idioma de su sitio de WordPress en un locale de destino. El ajuste se encuentra en Ajustes > Generales > Idioma del sitio.
2. Vuelva a cargar el front end y las páginas de administración que renderiza su plugin o tema.
3. Las cadenas envueltas en __() o esc_html__() deberían aparecer en el nuevo idioma.

Si falta algo, consulte ¿No se muestran las traducciones del plugin de WordPress? Solucione las traducciones que faltan para ver las causas más comunes.

Cómo hacer llegar sus traducciones a los usuarios: dos vías

Una vez que PTC ha traducido sus archivos, usted los publica de una de estas dos maneras.

Vía 1: Publique las traducciones a través de los paquetes de idiomas de WordPress.org (CLPTE)

Tiempo total: 4-6 días.

Paso 1: Cree una cuenta CLPTE

El rol CLPTE permite enviar traducciones en nombre de su tema o plugin en todos los idiomas de destino desde una sola cuenta. Una cuenta normal de editor de traducciones es por idioma; CLPTE no lo es.

Si ya tiene una cuenta en WordPress.org, es posible que se encuentre con un problema en el que su nueva cuenta CLPTE esté desactivada. WordPress no permite tener varias cuentas. Para resolverlo, envíe un correo electrónico a forum-password-resets@wordpress.org y explique que está intentando crear una cuenta CLPTE. Compartir la documentación pertinente del equipo Polyglots con el moderador y avisar al equipo Polyglots en Slack también ayuda.

Tiempo estimado: ~3-5 días (incluye el tiempo de espera si su nueva cuenta está desactivada).

Paso 2: Solicite acceso CLPTE en el blog del equipo Polyglots

Con su cuenta activada, publique una solicitud en el blog del equipo Polyglots de WordPress.org. Siga su plantilla:

PTE/CLPTE Request

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

Recibirá una notificación cuando se apruebe su solicitud.

Tiempo estimado: ~1 día (el equipo global de Polyglots revisa las solicitudes por lotes).

Paso 3: Importe los archivos .po traducidos

1. Inicie sesión en https://translate.wordpress.org/ utilizando su cuenta CLPTE.
2. Vaya a la página del proyecto de traducción de su plugin o tema (por ejemplo, translate.wordpress.org/projects/wp-plugins/{your-plugin-slug}/).
3. Abra el proyecto local para cada idioma que haya traducido.
4. Desplácese hacia abajo y haga clic en Importar traducciones.
5. Suba su archivo .po (o .mo).
6. Marque las cadenas importadas como «actual» en el editor de traducciones. Las cadenas aprobadas se unen a la siguiente generación de paquetes de idiomas (normalmente diaria).
7. Repita el proceso para cada idioma de destino. Cada locale tiene su propia página de traducción.

Tiempo estimado: ~10-30 minutos por idioma.

Tras un periodo de 24-48 horas para los paquetes de idiomas, los sitios que ejecutan su plugin comienzan a recibir las nuevas traducciones a través de las actualizaciones automáticas de los paquetes de idiomas de WordPress. Los usuarios no ven ningún aviso de actualización. Las traducciones simplemente aparecen.

Qué hará y qué no hará CLPTE por usted

• No puede reemplazar las traducciones preexistentes de la comunidad. Solo se importan las cadenas sin traducir. Actualizar una traducción de la comunidad existente requiere el proceso estándar y esperar la revisión del equipo del locale.
• Las actualizaciones requieren subidas manuales para cada lanzamiento. Cada nuevo lanzamiento significa una nueva ronda de subidas.
• La creación y aprobación de la cuenta suelen tardar entre 4 y 6 días en total.

Vía 2: Incluya los archivos .mo en el paquete de su plugin o tema

Si necesita que las traducciones estén publicadas más rápido de lo que permite CLPTE, o si prefiere no depender del pipeline de distribución de WordPress.org, incluya los archivos .mo directamente en el paquete de lanzamiento de su plugin o tema. Tiempo total: 15-30 minutos.

Paso 1: Añada los archivos .mo al directorio /languages/

Coloque sus archivos .mo compilados dentro del directorio /languages/ de su plugin o tema para que WordPress los encuentre al cargar su dominio de texto:

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

Utilice el mismo dominio de texto en los nombres de sus archivos de traducción y en sus llamadas load_plugin_textdomain() o load_theme_textdomain().

Paso 2: Dé preferencia a sus archivos empaquetados sobre las traducciones de la comunidad

De forma predeterminada, WordPress prioriza las traducciones de la comunidad de WordPress.org sobre las incluidas en el paquete. Para asegurarse de que su plugin o tema utilice en su lugar los archivos .mo empaquetados, añada el filtro load_textdomain_mofile.

Para los plugins, añada esto a su archivo principal del plugin (por ejemplo, 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 los temas, añada esto al archivo functions.php de su 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 también que su plugin o tema carga el dominio de texto en el hook correcto:

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

Paso 3: Verifique que las traducciones del paquete se cargan en un sitio de prueba

Instale su plugin o tema en un sitio de prueba y cambie WordPress a uno de los idiomas que ha proporcionado:

1. Vaya a Ajustes > Generales > Idioma del sitio y seleccione un idioma cuyo archivo .mo se encuentre en su carpeta /languages/.
2. Cargue una página o pantalla que contenga cadenas que sepa que están traducidas.
3. Confirme que las cadenas aparecen en el idioma correcto y coinciden con las traducciones que añadió.

Si sigue viendo traducciones antiguas de la comunidad, revise el fragmento de código del Paso 2. Debe dirigir correctamente a WordPress hacia sus archivos .mo incluidos en el paquete.

Haga un commit de los archivos .mo, etiquete un lanzamiento y haga un push a wordpress.org a través de SVN como lo hace normalmente.

El equilibrio entre la velocidad y la distribución canónica

• Pro: instantáneo. Las nuevas traducciones están disponibles en el momento en que los usuarios actualizan su plugin (o lo instalan por primera vez). No hay que esperar varios días para CLPTE. No hay ciclo de aprobación del equipo Polyglots.
• Pro: usted controla el flujo de trabajo. La frecuencia de lanzamientos de traducción coincide exactamente con su frecuencia de lanzamientos.
• Pro: no hay dependencia de la insignia del plugin. Las traducciones funcionan independientemente de si su plugin tiene permisos CLPTE o no.
• Contra: el tamaño del archivo del plugin aumenta. Cada .mo es pequeño (normalmente 5-50 KB), pero 20 idiomas añaden ~500 KB a la descarga.
• Contra: no hay actualización automática de las traducciones entre los lanzamientos del plugin. Con CLPTE, las traducciones actualizadas en wordpress.org se propagan a los usuarios en un plazo de 48 horas, incluso si no publica un nuevo lanzamiento. Al incluirlas en el paquete, las traducciones solo se actualizan cuando publica un nuevo lanzamiento.
• Contra: no hay insignia de «traducido». WordPress.org muestra una insignia de finalización de la traducción en las fichas de los plugins basándose en la cobertura del paquete de idiomas, no en los archivos .mo empaquetados. La inclusión en el paquete por sí sola no permite obtener la insignia.

¿Qué vía se adapta a su frecuencia de lanzamientos?

El enfoque dual es común: incluir los archivos MO en el paquete para que estén disponibles de inmediato y enviarlos a CLPTE para su distribución canónica. Los usuarios obtienen las traducciones empaquetadas al actualizar; la superposición del paquete de idiomas las actualiza entre lanzamientos.

Idiomas de derecha a izquierda y diseños bidireccionales

El flujo de trabajo de traducción es el mismo para los idiomas de derecha a izquierda (RTL). El árabe, el hebreo, el persa y el urdu utilizan el mismo pipeline POT/PO/MO.

El paso adicional es asegurarse de que su tema admita estilos RTL. WordPress carga automáticamente un archivo rtl.css si existe uno en el directorio de su tema. Utilice la función is_rtl() para aplicar condicionalmente estilos o scripts específicos de RTL.

Cómo localizar fechas, números y monedas

Una cadena traducida no es toda la historia. Las fechas, los números y las monedas también deben seguir el locale del usuario. Utilice las funciones de formato integradas de WordPress en lugar de las nativas de PHP:

• date_i18n() formatea las fechas según el locale activo.
• number_format_i18n() formatea los números con separadores de miles y decimales adaptados al locale.

Estas funciones no forman parte del flujo de trabajo de los archivos de traducción. Son importantes para una experiencia completamente localizada.

Cómo internacionalizar bloques del editor de bloques (Gutenberg)

Los bloques añaden dos pasos adicionales al pipeline estándar:

• Las traducciones de JavaScript necesitan un archivo .json por locale. Genérelo a partir del .po con wp i18n make-json.
• El script del editor del bloque necesita wp_set_script_translations() en PHP. Eso indica a WordPress que sirva el JSON al bloque.

La salida renderizada por el bloque en el front end utiliza las mismas llamadas __() que el resto de su código PHP. No hay trabajo adicional allí.

Cómo traducir su README y su ficha de WordPress.org

Su readme.txt no es un archivo de recursos. WP-CLI no lo recogerá al generar un POT. Para traducirlo, utilice la función Paste to Translate de PTC. Pegue el contenido, elija sus idiomas de destino y descargue el resultado. Los correos electrónicos orientados al cliente enviados desde el plugin y la descripción de la página del plugin de WordPress.org se traducen de la misma manera, todo en el mismo proyecto para que la terminología se mantenga coherente.

Si su plugin o tema aparece en WordPress.org, la descripción traducida aparece en la pestaña Detalles del plugin en el idioma del usuario. Para que las traducciones se publiquen allí, siga el proceso de importación de WordPress.org.

Traduzca el contenido del usuario del plugin con la API de PTC

Los plugins que almacenan datos generados por los usuarios (plugins de foros, plugins de reseñas, plugins de comentarios) pueden traducir ese contenido a medida que llega. La API REST de PTC traduce las publicaciones de los usuarios, los comentarios y las reseñas a petición con la autenticación Bearer, utilizando el mismo glosario y voz de marca que sus archivos .po.

Revisión visual de la traducción de su tema o plugin renderizado: publique sin control de calidad manual por idioma

Un archivo .po traducido es necesario, pero no es suficiente. El tema o plugin traducido aún necesita verificación:

• Una etiqueta traducida puede desbordar un botón de la página de ajustes en alemán.
• “Submit” puede traducirse como un sustantivo en francés cuando la acción de administración necesitaba un verbo.
• Una cadena en inglés incrustada en el código fuera de __() se renderizará sin traducir independientemente de cuántos idiomas publique.

La revisión visual de la traducción de PTC sustituye a la pasada de control de calidad manual. Los temas y plugins de WordPress se renderizan en el navegador (tanto wp-admin como el front end). La variante adecuada es la extensión de navegador.

Instálela una vez. Grabe un recorrido de su tema o plugin en un sitio de prueba. Cubra las páginas de ajustes, las acciones de administración y la salida del front end. PTC vuelve a ejecutar la grabación en cada idioma de destino después de cada actualización de la traducción. Captura cada pantalla y notifica dos tipos de correcciones:

• Correcciones en los archivos .po cuando PTC los controla. PTC vuelve a traducir una acepción incorrecta, elige un sinónimo más corto que encaje en un botón o regenera una forma plural.
• Prompts de Cursor o Claude Code cuando el problema reside en su código PHP o JavaScript. Algunos ejemplos son un wrapper __() que falta, una cadena en inglés incrustada en el código o una oración construida por concatenación que debería usar sprintf( __( ... ) ).

Usted publica un plugin multilingüe verificado en cada lanzamiento. El trabajo residual de control de calidad manual desaparece.

Precios: prueba de 30 días, luego pago al consumo

La prueba cubre 20.000 palabras en 2 idiomas sin tarjeta de crédito. Cuando termina la prueba, PTC ofrece el pago al consumo. Sin suscripción. Sin compromiso mínimo. Las primeras 500 palabras de cada mes son gratuitas. Solo paga por el resto. La página de precios dispone de una calculadora de costes. Regístrese con un correo electrónico de empresa para obtener una prueba ampliada para empresas.

¿Listo para publicar un plugin o tema verificado?

PTC genera las traducciones y revisa el plugin renderizado. Usted confirma el resultado y lo publica. El ciclo completo se ejecuta sin control de calidad manual:

1. Genere su archivo .pot con wp i18n make-pot.
2. Súbalo a PTC y reciba los archivos .po, .mo, .l10n.php y .json en cuestión de minutos.
3. Instale la extensión de navegador para verificar el plugin en ejecución en cada idioma de destino.

Comience su prueba de 30 días: 20.000 palabras por nuestra cuenta, no se requiere tarjeta de crédito.

Relacionado:

• Traduzca archivos PO online con IA: la página canónica de traducción de PO/POT.
• GlotPress frente a PTC para la traducción de plugins y temas de WordPress: cuándo elegir la traducción de la comunidad frente a PTC.
• ¿No se muestran las traducciones del plugin de WordPress? Solucione las traducciones que faltan: guía de solución de problemas.
• Cómo importar traducciones de temas y plugins a WordPress.org: el proceso CLPTE y una alternativa más rápida.
• Referencia de la API de PTC: endpoints REST para la integración de CI.

Última actualización: 11 de noviembre de 2026