Un archivo de entrada, cinco formatos de salida: Cómo preparar tus traducciones de WordPress para el futuro

Pasaste tres semanas traduciendo tu tema de WordPress al español. El archivo .po es perfecto: cada cadena revisada, cada variable intacta, cada forma plural correcta. Entonces, tu cliente decide migrar de un tema PHP clásico a una configuración headless con React en el frontend.

De repente, tu archivo .po es inútil. La aplicación React necesita .json. Los widgets PHP heredados todavía necesitan .mo. El freelancer que se encarga de la aplicación móvil quiere .xliff. Y nadie tiene tiempo para volver a traducir 4000 cadenas a tres formatos diferentes.

Este no es un caso límite. Es la realidad del desarrollo moderno de WordPress, donde los temas se envían con componentes PHP y JavaScript, los plugins usan una mezcla de Gettext e i18next, y los clientes cambian de opinión sobre la arquitectura más a menudo de lo que cambian sus contraseñas.

Por qué los formatos de archivos de traducción importan más que nunca

Hace cinco años, la traducción de WordPress era simple. Tenías un archivo .po (fuente legible por humanos) y un archivo .mo (binario compilado). Eso era todo. Cada tema, cada plugin, cada herramienta de traducción hablaba el mismo idioma.

Hoy en día, el ecosistema de WordPress utiliza al menos cinco formatos de archivos de traducción en producción:

Los cinco formatos que necesitas conocer

.po (Portable Object): el formato fuente legible por humanos utilizado por GNU Gettext. Contiene cadenas originales (msgid) y sus traducciones (msgstr). Esto es lo que editan los traductores.

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): la versión binaria compilada de un archivo .po. WordPress lee los archivos .mo en tiempo de ejecución usando load_textdomain(). Más rápido que analizar .po en tiempo de ejecución, pero no editable por humanos.

.json (JavaScript Object Notation): utilizado por wp_set_script_translations() para traducciones basadas en JavaScript en bloques de Gutenberg, componentes React y temas modernos. WordPress espera una estructura JSON específica con claves 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): un formato cada vez más popular para temas y plugins que utilizan la carga de traducción al estilo de Laravel. Algunos temas modernos de WordPress evitan Gettext por completo y cargan traducciones de arrays PHP para mejorar el rendimiento.

<?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): el estándar de la industria para el intercambio de traducciones entre diferentes herramientas y plataformas. Utilizado por herramientas CAT (Computer-Assisted Translation) como memoQ, Trados y Memsource. Esencial cuando se trabaja con traductores humanos profesionales.

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

El problema: bloqueo de formato

La mayoría de las herramientas de traducción producen un formato de salida. Poedit te da .po y .mo. WPML almacena las traducciones en la base de datos (no en archivos). Weglot mantiene las traducciones en sus servidores en un formato propietario. Incluso las plataformas TMS como Crowdin y Lokalise requieren que configures manualmente los formatos de exportación para cada proyecto.

Esto crea un bloqueo de formato: tus traducciones están atrapadas en el formato que produce tu herramienta actual. Cuando cambian tus requisitos, te enfrentas a dos opciones:

1. Volver a traducir todo en el nuevo formato (caro, lleva mucho tiempo y pierdes cualquier corrección manual).
2. Escribir scripts de conversión personalizados (propensos a errores, especialmente para formas plurales complejas y variables).

Ninguna de las dos opciones es buena. Ambas desperdician tiempo y dinero. Ambas introducen riesgo.

Escenarios reales donde el bloqueo de formato duele

Escenario 1: Modernización del tema. El tema de tu cliente se está reconstruyendo con bloques de Gutenberg. Las antiguas plantillas PHP utilizaban archivos .mo. Los nuevos bloques necesitan .json para wp_set_script_translations(). Tus 3000 cadenas traducidas deben existir en ambos formatos durante la transición.

Escenario 2: Flujo de trabajo de agencia. Administras 20 sitios de clientes. Algunos usan temas clásicos (.mo). Algunos usan configuraciones headless (.json). Uno usa un framework personalizado que lee arrays PHP. Necesitas las mismas traducciones en diferentes formatos para diferentes clientes.

Escenario 3: Revisión profesional. Tus traducciones de IA tienen una precisión del 95 %, pero quieres que un hablante nativo revise el 5 % restante. Los traductores profesionales utilizan herramientas CAT que importan .xliff. Necesitas exportar tus traducciones a .xliff, enviarlas para su revisión y fusionar las correcciones.

Escenario 4: Migración de plataforma. Tu cliente se está mudando de WordPress a una aplicación Node.js personalizada. La nueva aplicación usa i18next y necesita archivos .json. Tus 5000 cadenas traducidas en formato .po deben convertirse, sin perder una sola variable o forma plural.

La solución: Traduce una vez, obtén todos los formatos

SimplePoTranslate adopta un enfoque diferente. Cuando subes un archivo .po, .pot, .json o .xliff y ejecutas una traducción, recibes un ZIP que contiene los 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

Esta no es una "función premium" bloqueada detrás de un nivel empresarial. Cada plan de pago (Pro: 19 $/mes y Lifetime: 399 $ por única vez) incluye los cinco formatos de salida en cada trabajo de traducción.

Por qué esto importa para preparar el futuro

Cuando tienes los cinco formatos desde el principio, nunca necesitas volver a traducir. Tus traducciones son un activo que se adapta a cualquier requisito técnico:

• ¿El cliente migra de clásico a Gutenberg? Implementa el archivo .json.
• ¿El nuevo desarrollador prefiere los arrays PHP? Entrégale el archivo .php.
• ¿El traductor profesional quiere revisar? Envía el archivo .xliff.
• ¿Te mudas a un CMS diferente? Los archivos .json y .xliff son independientes de la plataforma.

Traduces una vez. Los formatos están listos cuando los necesites.

Cómo funciona cada formato en WordPress

Saber qué archivo va dónde es esencial para una implementación limpia.

Implementación de archivos .mo (temas y plugins PHP clásicos)

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

WordPress los carga automáticamente cuando el idioma del sitio coincide. No se requiere plugin. Cero sobrecarga de la base de datos. Este es el enfoque que ofrece el mejor rendimiento.

Implementación de archivos .json (bloques de Gutenberg y componentes JS)

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

El nombre del archivo incluye el identificador del script y un hash MD5. WordPress los empareja cuando llamas a wp_set_script_translations() en tu plugin o tema. Si estás construyendo bloques de Gutenberg, este es el archivo que hace que las etiquetas y descripciones traducidas de tu bloque aparezcan correctamente.

Uso de archivos .xliff (flujo de trabajo de revisión profesional)

Los archivos .xliff no se implementan en WordPress. Se utilizan como un formato de intercambio cuando necesitas enviar traducciones a un revisor profesional o importarlas a una herramienta CAT. El flujo de trabajo se ve así:

1. Sube .po a SimplePoTranslate y obtén .xliff en el ZIP
2. Envía .xliff a tu traductor o revisor
3. Recibe .xliff corregido de vuelta
4. Sube .xliff corregido a SimplePoTranslate y obtén .mo y .json actualizados

Este flujo de trabajo de ida y vuelta preserva cada variable y forma plural porque el bloqueo de sintaxis de SimplePoTranslate los protege en cada etapa.

La prueba de bloqueo de proveedor

Aquí tienes una prueba simple para determinar si tu flujo de trabajo de traducción actual tiene un problema de bloqueo:

1. ¿Puedes exportar tus traducciones como archivos .po estándar ahora mismo?
2. Si cancelas tu suscripción a la herramienta de traducción hoy, ¿conservas cada cadena traducida?
3. ¿Puedes importar tus traducciones a una herramienta o plataforma completamente diferente sin volver a traducir?

Si la respuesta a alguna de estas preguntas es "no", estás bloqueado. Servicios como Weglot y GTranslate fallan en las tres preguntas: cancela la suscripción y tus traducciones desaparecen. WPML almacena las traducciones en la base de datos, lo que hace que la exportación sea posible pero dolorosa. Incluso las herramientas de escritorio como Poedit aprueban la prueba sobre el papel, pero te limitan a .po y .mo solamente.

Con SimplePoTranslate, la respuesta a las tres preguntas es "sí". Descargas archivos estándar en cinco formatos. Son tuyos. Elimina tu cuenta mañana y cada traducción que hayas hecho seguirá funcionando.

Construyendo una biblioteca de traducción independiente del formato

Para las agencias y los desarrolladores que gestionan varios proyectos, el enfoque más inteligente es construir una biblioteca de traducción: un repositorio Git o una carpeta compartida donde almacenas los archivos traducidos para cada proyecto de 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/
│   └── ...

Cuando un cliente necesita un nuevo formato, ya lo tienes. Cuando un cliente cambia de plataforma, tus traducciones migran sin esfuerzo. Cuando un nuevo desarrollador se une al equipo, puede ver exactamente lo que se ha traducido y en qué formatos.

Esto es lo que realmente significa "preparado para el futuro": no predecir qué tecnología usarán tus clientes el año que viene, sino asegurarte de que tus traducciones funcionen con lo que elijan.

¿Listo para dejar de preocuparte por los formatos de archivo? Prueba SimplePoTranslate gratis: sube un archivo y obtén cinco formatos. Sin scripts de conversión, sin volver a traducir, sin bloqueos.