Traducción de plugins WordPress con dialectos

En pocas palabras: WordPress trata cada dialecto como un locale independiente: de_DE (alemán estándar), de_CH (suizo formal) y de_CH_informal son tres traducciones separadas. Cada una necesita sus propios archivos .po y .mo en /languages/ y se traduce por separado en GlotPress (translate.wordpress.org).

Si tenés un plugin en el repositorio oficial y querés que hable el idioma de tu público, la traducción de plugins wordpress se hace con archivos .pot, .po y .mo dentro de una carpeta /languages/, y se valida en GlotPress (translate.wordpress.org). El punto fino aparece cuando un mismo idioma tiene dialectos, como el alemán suizo.

La traducción de plugins WordPress es el proceso de internacionalizar el código (envolver los textos en funciones como __() y _e()) y después proveer los archivos de idioma que WordPress carga según el locale del sitio. Es responsabilidad del autor del plugin y de la comunidad de traductores voluntarios (Polyglots), y define a cuántos usuarios podés llegar sin que tengan que leer en inglés.

¿Por qué conviene traducir tu plugin a varios idiomas?

Porque un plugin traducido llega a gente que, de otra forma, lo descarta en la primera pantalla. Si tu público no lee inglés con comodidad, cada string sin traducir es una fricción.

El caso que disparó esta nota lo cuenta un autor en el foro de Polyglots: su plugin es Fliegerlogin, un SSO (inicio de sesión único) para gestionar comunidades de aviadores, y necesitaba soporte para dos variantes del alemán suizo a la vez. No es un capricho. Una comunidad suiza espera que el software le hable en su registro, y ahí es donde la traducción deja de ser cosmética y pasa a ser parte de la experiencia. Relacionado: comunidad WordPress oficial.

Pensalo así: subís tu plugin, funciona bárbaro en inglés, lo instala alguien en Zúrich, ve la mitad de los botones en un idioma que no es el suyo y la sensación es de producto a medio hacer, aunque el código esté impecable. La traducción es lo que cierra esa brecha entre «funciona» y «se siente propio».

¿Cómo funcionan los idiomas y dialectos en WordPress?

WordPress trata cada dialecto como un locale independiente, con su propio código. No hay un «alemán» genérico que después se ajuste solo: de_DE y de_CH son dos idiomas distintos a los ojos del sistema, con archivos de traducción separados.

Acá viene lo bueno: eso te da precisión, pero también te obliga a mantener cada variante por su cuenta. La diferencia entre de_CH y de_CH_informal es el tratamiento. Uno usa «Sie» (el usted formal) y el otro «du» (el trato informal). En un plugin de gestión comunitaria, elegir mal el registro cambia por completo cómo suena la interfaz.

Código de locale	Idioma	Registro
de_DE	Alemán (Alemania)	Estándar
de_DE_formal	Alemán (Alemania)	Formal (Sie)
de_CH	Alemán suizo	Formal (Sie)
de_CH_informal	Alemán suizo	Informal (du)
de_AT	Alemán (Austria)	Estándar

Ojo con esto: respetar el dialecto correcto no es purismo lingüístico. Es lo que hace que un traductor profesional o un usuario nativo sienta que el producto lo entiende. Más contexto en crear landing pages efectivas.

¿Qué archivos necesita la traducción de plugins WordPress?

La traducción vive en tres tipos de archivo dentro de una carpeta /languages/ en la raíz del plugin. Cada uno cumple una función distinta.

• .pot (Portable Object Template): la plantilla con todos los strings originales extraídos del código. No tiene traducciones, es el molde del que parten los traductores.
• .po (Portable Object): el archivo editable, uno por idioma. Ahí cada string tiene su traducción. Se abre con un editor de texto o con Poedit.
• .mo (Machine Object): la versión compilada del .po, en binario. Es la que WordPress lee en tiempo de ejecución porque es más rápida de procesar.

El nombre de archivo importa. Para un plugin con text domain fliegerlogin, la traducción al alemán suizo informal sería fliegerlogin-de_CH_informal.po y su .mo correspondiente. Y en el código, cargás todo con load_plugin_textdomain() apuntando a esa carpeta. Desde WordPress 4.6, los plugins del repositorio oficial cargan sus traducciones de translate.wordpress.org sin que tengas que empaquetar los .mo vos mismo. Si además tenés strings en JavaScript, esos van aparte con wp_set_script_translations() y archivos .json generados con WP-CLI.

Un detalle práctico si estás probando en local antes de subir: cuando lo pases a producción, un hosting WordPress como el de Donweb ya te trae el core y los idiomas del sitio listos, así que la carga de traducciones no depende de configurarlo a mano.

¿Cómo subís las traducciones al repositorio oficial?

Las traducciones oficiales no van adentro del ZIP: se cargan y validan en GlotPress, la plataforma de traducción de WordPress.org. El flujo es más o menos este.

• Registrate en Make WordPress: con tu cuenta de WordPress.org accedés a translate.wordpress.org y buscás tu plugin.
• Sugerí traducciones: cualquiera puede proponer strings. Aparecen como «waiting» hasta que alguien con permisos las aprueba.
• Pedí ser PTE: el rol de Project Translation Editor te deja aprobar traducciones de tu propio plugin para un idioma. Se solicita en el foro de Polyglots del locale que corresponda.
• Enfocate en la rama Stable: GlotPress separa «Development» y «Stable». Lo que se sirve a los usuarios reales sale de Stable, así que asegurate de completar esa.

¿Y si tu plugin no aparece en el listado? Suele ser porque todavía no tiene ningún string traducible detectado o porque la última versión no se procesó. Revisá que el código tenga los textos envueltos en las funciones de traducción y que el header del plugin declare bien el Text Domain. Esto se conecta con lo que analizamos en ambiente de staging antes de publicar.

El caso Fliegerlogin: dos dialectos en el mismo plugin

El autor de Fliegerlogin planteó en Polyglots una duda concreta: quería mantener de_CH (formal) y de_CH_informal al mismo tiempo, sin que una pisara a la otra. La respuesta de la comunidad apunta a lo obvio pero fácil de olvidar: son proyectos de traducción separados en GlotPress, y cada uno se completa por su lado.

La lección que sirve para cualquier plugin: si tu público mezcla registros (algunos esperan trato formal, otros informal), no elijas por ellos metiendo todo en un solo locale. WordPress ya te da la infraestructura para ofrecer las dos variantes, y el usuario termina viendo la que coincide con la configuración de su sitio. Lo que te toca a vos es tener paciencia para mantener las dos ramas al día, porque cada string nuevo que agregues al plugin va a aparecer sin traducir en ambas.

Qué está confirmado y qué queda pendiente

• Confirmado: WordPress soporta de_CH y de_CH_informal como locales distintos, y ambos se pueden traducir en GlotPress de forma independiente.
• Confirmado: los plugins del repositorio oficial cargan traducciones de translate.wordpress.org de forma automática desde WordPress 4.6, sin empaquetar los .mo.
• Pendiente/variable: el estado exacto de traducción de Fliegerlogin depende de que se aprueben las sugerencias y de que el autor consiga el rol PTE para cada dialecto.

Herramientas para traducir plugins

No hay una sola herramienta correcta. Depende de si trabajás solo o con una comunidad de traductores.

• Poedit: app de escritorio para editar .po y compilar .mo. Ideal para trabajo individual y para arrancar el .pot.
• GlotPress: integrado en WordPress.org, colaborativo y con glosario. Es el destino final de las traducciones oficiales.
• WP-CLI (comando i18n): genera el .pot desde la terminal y los archivos .json para las traducciones de JavaScript. Útil para automatizar.
• Crowdin y similares: plataformas de crowdsourcing para proyectos grandes con muchos idiomas y colaboradores externos.

Para un plugin chico, Poedit más GlotPress alcanza y sobra. Para algo con comunidad activa, conviene apoyarse en la plataforma oficial y sumar traductores voluntarios. Para más detalles técnicos, mirá cómo reparar enlaces rotos.

Errores comunes al traducir plugins

• Confundir de_CH con de_CH_informal: son dos locales. Si cargás el trato informal en el proyecto formal, la interfaz suena rara para quien espera «Sie».
• Traducir solo la rama Development: si no completás Stable, los usuarios en producción siguen viendo inglés.
• Ignorar el glosario del locale: cada idioma tiene términos consensuados en Polyglots. Traducir «settings» de diez formas distintas rompe la consistencia.
• Olvidar los strings en JavaScript: los textos de bloques y de la interfaz React de Gutenberg necesitan wp_set_script_translations() y sus .json, aparte de los .mo.
• No declarar bien el Text Domain: si el header del plugin no coincide con el usado en las funciones, WordPress no encuentra las traducciones.

Preguntas Frecuentes

¿Cómo traducir un plugin de WordPress?

Se envuelven los textos del código en funciones como __() y _e(), se genera un archivo .pot con las cadenas, y desde ahí se crean los .po/.mo por idioma en la carpeta /languages/. Para plugins del repositorio oficial, la traducción se valida en translate.wordpress.org.

¿Cuál es la diferencia entre de_DE y de_CH en WordPress?

de_DE es el alemán de Alemania y de_CH es el alemán suizo, y WordPress los trata como locales separados con archivos de traducción propios. No comparten strings: si querés soportar ambos, mantenés cada uno por su lado.

¿Cómo agregar soporte para varios dialectos en un plugin?

Se crea un archivo de traducción por cada locale (por ejemplo plugin-de_CH.po y plugin-de_CH_informal.po) y se completa cada proyecto en GlotPress de forma independiente. WordPress carga la variante que coincida con la configuración de idioma del sitio.

¿Dónde se cargan las traducciones de un plugin?

En la carpeta /languages/ del plugin, referenciada con load_plugin_textdomain(). Para plugins alojados en WordPress.org, las traducciones aprobadas se sirven desde translate.wordpress.org de forma automática desde la versión 4.6.

¿Qué es SSO y cómo se implementa en WordPress?

SSO (Single Sign-On) es un inicio de sesión único que deja acceder a varios servicios con una sola credencial, como hace el plugin Fliegerlogin para comunidades de aviadores. En WordPress se implementa con plugins que conectan la autenticación a un proveedor de identidad externo (OAuth, SAML o similar).

Conclusión

Traducir un plugin no termina en el archivo .po. Cuando hay dialectos de por medio, como el alemán suizo formal e informal, cada variante es un proyecto aparte que tenés que mantener al día en GlotPress. El caso de Fliegerlogin lo deja claro: la infraestructura ya está, lo que falta es la disciplina de completar la rama Stable de cada locale y de sumar traductores con permisos PTE. Si estás por internacionalizar tu plugin, arrancá envolviendo bien los strings, generá el .pot con WP-CLI y revisá el glosario del idioma antes de empezar. El alcance que ganás cuando el usuario ve el producto en su registro justifica el trabajo extra.

Fuentes

• Make WordPress Polyglots – consulta original sobre de_CH y de_CH_informal (Fliegerlogin)
• Developer WordPress – Localization: guía oficial de i18n para plugins
• Make WordPress Polyglots – equipo de traducción y flujo en GlotPress