Cómo traducir archivos .po de Drupal con IA

La mayoría de la gente asocia los archivos .po con WordPress, pero el formato gettext es anterior a WordPress por décadas y potencia la traducción de interfaces en todo el mundo de código abierto. Drupal es uno de sus mayores usuarios. Si tienes un sitio Drupal multilingüe, cada etiqueta de menú, descripción de campo, mensaje de error y cadena de módulo fluye a través de archivos .po exactamente como lo hace en WordPress, solo que con un dialecto de marcador de posición diferente y un flujo de trabajo de importación distinto. Y al igual que WordPress, en el momento en que tu sitio supera un puñado de cadenas, traducir esos archivos a mano se convierte en el cuello de botella.

Esta guía trata sobre cómo traducir archivos .po de Drupal con IA sin romper las cosas que hacen que Drupal sea Drupal. Recorreremos el sistema de traducción de Drupal, de dónde provienen realmente las cadenas, la sintaxis de marcador de posición que difiere de WordPress y que debe preservarse absolutamente, y el ciclo completo de exportación, traducción y reimportación, incluyendo los comandos drush que lo hacen repetible.

Cómo funciona el sistema de traducción de Drupal

Drupal gestiona la traducción de la interfaz a través del módulo central locale (a veces llamado "Interface Translation" en Drupal moderno). Una vez habilitado, gestiona una tabla de base de datos de cadenas de origen y sus traducciones por idioma, y puede importar y exportar esas traducciones como archivos .po estándar de gettext.

La interfaz de administración se encuentra en /admin/config/regional/translate. Desde allí puedes buscar cadenas sin traducir, editarlas en línea y, fundamentalmente, importar un archivo .po para cargar traducciones masivamente o exportar el estado actual a un archivo .po para edición sin conexión. Ese ciclo de exportación/edición/importación es el flujo de trabajo que estamos optimizando.

A diferencia de WordPress, donde cada plugin y tema envía sus propios archivos .po y .mo en un directorio languages/, Drupal centraliza las cadenas de interfaz en su base de datos y trata .po como el formato de intercambio. Lo exportas, trabajas en el archivo y lo vuelves a importar. El paso de compilación .mo que requiere WordPress se gestiona internamente.

De dónde vienen las cadenas

Las cadenas de Drupal provienen de tres lugares, y una traducción completa tiene que cubrirlos todos:

• Core incluye miles de cadenas traducibles para la interfaz de usuario de administración, formularios y mensajes del sistema.
• Los módulos contrib (Views, Webform, Commerce y el resto) registran cada uno sus propias cadenas a través de la función t().
• Los temas contribuyen con cadenas de plantillas, etiquetas de región y descripciones de configuración de temas.

Cuando exportas desde /admin/config/regional/translate, puedes limitar la exportación a cadenas traducidas, sin traducir o todas. Para una nueva pasada de traducción, exportar solo las cadenas sin traducir te proporciona un archivo .po enfocado con exactamente el trabajo que queda por hacer.

Una consecuencia práctica de esta estructura de tres fuentes: tu trabajo de traducción nunca está realmente "terminado". Cada vez que añades un módulo contrib, habilitas una nueva característica o actualizas el core de Drupal, aparece un nuevo lote de entradas msgid sin traducir en las tablas de localización. Es por eso que los equipos de Drupal tratan la traducción como un flujo de trabajo recurrente en lugar de una tarea de lanzamiento única. El mismo ciclo de exportación, traducción y reimportación se ejecuta en cada despliegue que afecta a los módulos, y cuanto más rápido sea ese ciclo, menos deuda de traducción se acumula entre lanzamientos.

También cabe destacar que Drupal puede obtener traducciones aportadas por la comunidad automáticamente de localize.drupal.org para el core y módulos contrib populares. Estas cubren las cadenas comunes, pero rara vez cubren tus módulos personalizados, tu tema o la fraseología específica del proyecto que tu sitio realmente utiliza. La brecha entre la traducción comunitaria y un sitio completamente localizado es exactamente el trabajo que una pasada de IA cierra rápidamente.

Los marcadores de posición de Drupal no son los de WordPress

Aquí está lo más importante que hay que entender antes de enviar cualquier archivo .po de Drupal a un traductor de IA: Drupal no utiliza los marcadores de posición de estilo printf %s y %1$s que dominan en WordPress. La función t() de Drupal utiliza tres prefijos de marcador de posición distintos, cada uno con un comportamiento de escape diferente:

• @variable — el valor se escapa a HTML, el valor predeterminado seguro para el texto proporcionado por el usuario.
• %variable — el valor se escapa y se envuelve en marcado de énfasis <em>.
• :placeholder — utilizado para atributos de URL, pasado por sanitización de URL.

Una cadena de origen típica de Drupal se ve así en el archivo .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 ""

Si un traductor cambia @count a @cuenta, reemplaza @name con la palabra traducida para "nombre", o inserta un espacio convirtiendo @count en @ count, el marcador de posición ya no coincide con lo que pasa la llamada a t(). Drupal entonces imprime el token literal @count en la página en lugar del número real. La traducción parece hecha, pero el sitio está visiblemente roto.

Esta es la misma clase de error que afecta a las cadenas %s de WordPress, y cubrimos el principio general en profundidad en cómo traducir archivos PO sin romper variables de código. El giro de Drupal es simplemente que hay tres estilos de marcadores de posición en lugar de uno, y una herramienta de traducción tiene que reconocerlos todos.

Por qué los traductores genéricos fallan aquí

Pega esa cadena de node.module en un cuadro de traducción automática de consumo y frecuentemente obtendrás @count estropeado, el %date ligado a <em> localizado en un token diferente, o las formas plurales colapsadas en una sola. Ninguna de estas herramientas fue construida teniendo en cuenta la semántica de gettext. Traducen texto; no entienden que @count es un contrato con el código de la aplicación.

Un flujo de traducción consciente de gettext con Bloqueo de Sintaxis trata @variable, %variable y :placeholder como tokens inmutables. Se bloquean antes de la traducción y se restauran después, de modo que la frase circundante se traduce mientras los marcadores de posición pasan intactos. El mismo bloqueo cubre %s y %1$s de WordPress, {{name}} de i18next y HTML en línea, por lo que una única herramienta puede servir a un proyecto Drupal, Symfony o Laravel tan fácilmente como a uno de WordPress. Las formas plurales de Drupal a través de msgid_plural se conservan como formas plurales en lugar de aplanadas, lo cual es importante porque los idiomas de Drupal pueden tener entre una y seis variantes plurales.

También hay un modo de fallo más sutil que vale la pena mencionar. Las cadenas de Drupal con frecuencia incrustan marcado y enlaces en línea dentro del texto traducible, como Read the <a href=":url">documentation</a> donde :url es un marcador de posición y las etiquetas <a> deben sobrevivir. Un traductor que no entiende la estructura puede traducir el atributo href, eliminar la etiqueta de cierre o localizar el nombre del marcador de posición. La IA consciente del contexto que lee toda la cadena como una unidad, combinada con el bloqueo de tokens, mantiene intactos tanto el marcado como el contrato :url mientras traduce solo el texto "documentation" legible por humanos que se encuentra entre ellos.

El ciclo de exportación, traducción y reimportación

El flujo de trabajo repetible tiene tres etapas, y drush hace que la exportación e importación sean programables para que no tengas que hacer clic en la interfaz de usuario de administración cada vez.

Paso 1: Exportar el archivo PO

Puedes exportar desde la interfaz de usuario en /admin/config/regional/translate eligiendo un idioma y un alcance de exportación, o hacerlo desde la línea de comandos. El módulo locale expone la exportación a través de los servicios de traducción de Drupal, y la mayoría de los equipos lo programan. Una invocación típica de drush para activar una importación de traducción (lo inverso, que usamos en el paso tres) se ve así:

# 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 el lado de la exportación, el formulario de exportación de administración produce el archivo .po; muchos equipos envuelven el servicio de exportación de localización en un pequeño comando Drush personalizado para una automatización completa. De cualquier manera, terminas con un archivo .po estándar de gettext que contiene tus entradas msgid sin traducir.

Paso 2: Traducir el archivo

Esta es la etapa donde la IA reemplaza horas de edición manual. Sube el archivo .po exportado a un traductor en la nube, elige tu idioma de destino y deja que lo procese. Debido a que los archivos .po de Drupal para un sitio grande suelen superar los 10 MB una vez que se combinan el core, los módulos contrib y los temas, el Procesamiento por Lotes Inteligente es importante aquí: el archivo se divide en fragmentos, se traduce y se vuelve a ensamblar sin que tengas que dividirlo a mano o alcanzar límites de tamaño. La salida es un archivo .po completo con cada msgstr lleno y cada marcador de posición @count, %date y :url exactamente donde empezó.

Paso 3: Reimportar a Drupal

Importa el archivo traducido de nuevo a través de /admin/config/regional/translate o mediante el comando drush locale:import mostrado anteriormente, luego reconstruye la caché. Drupal fusiona las traducciones en sus tablas de localización, y las cadenas aparecen en todo el sitio inmediatamente. Ejecuta el ciclo de nuevo cada vez que añades un módulo o actualizas el core, ya que cada uno trae nuevas cadenas sin traducir.

Un detalle de importación a tener en cuenta: el flag --override controla si las traducciones entrantes reemplazan a las existentes. Usa --override=all cuando quieras que el archivo traducido por IA sea autoritario, o una configuración más conservadora si has ajustado manualmente ciertas cadenas en la interfaz de usuario de Drupal que no quieres que se sobrescriban. Para la mayoría de los pipelines automatizados, tratar el archivo .po como la fuente de la verdad y sobrescribir todo mantiene el sistema predecible: el archivo en control de versiones es lo que muestra el sitio, punto final.

Para sitios multilingües con varios idiomas de destino, el ciclo se ejecuta una vez por idioma. Exporta el conjunto sin traducir, tradúcelo al alemán, impórtalo; exporta de nuevo, tradúcelo al español, impórtalo; y así sucesivamente. Debido a que cada idioma es un archivo .po independiente, puedes ejecutarlos en paralelo, y un traductor en la nube que los procesa simultáneamente convierte lo que solía ser una semana de tiempo de contratista en una tarde.

PO de Drupal es un formato entre varios

Vale la pena señalar que gettext .po no es la única forma en que Drupal maneja la traducción. Las entidades de configuración y contenido también pueden intercambiarse como XLIFF, que es el estándar en el que se apoya el módulo Translation Management Tool (TMGMT) para los flujos de trabajo de proveedores de traducción profesionales. Si tu localización de Drupal se ejecuta a través de XLIFF en lugar de archivos .po de interfaz, los principios de preservación de marcadores de posición son idénticos pero la estructura del archivo difiere, y cubrimos esa ruta en traducir archivos XLIFF para Drupal, Symfony y Angular.

Sin embargo, para la capa de traducción de la interfaz, .po sigue siendo el caballo de batalla. El ciclo de exportación, traducción por IA y reimportación convierte una tarea manual de varios días en unos pocos minutos de procesamiento, y siempre que la herramienta que uses entienda genuinamente los marcadores de posición de gettext, tus contratos @variable sobreviven intactos y tu sitio Drupal permanece sin errores en cada idioma que publiques.

¿Listo para traducir tus archivos .po de Drupal sin romper una sola @variable? Prueba SimplePoTranslate gratis — no se requiere tarjeta de crédito. El nivel gratuito maneja archivos .po y .pot estándar de gettext con Bloqueo de Sintaxis completo, para que tus marcadores de posición de Drupal pasen exactamente como espera el código.