Traducción de WordPress con IA satura a Polyglots

En pocas palabras: El mayor problema de la localización de WordPress en 2026 es la traducción con IA: desarrolladores que usan LLM para traducir plugins a idiomas que no hablan. Según Tobi Fjellner (14/10/2026), los pedidos de PTE se multiplicaron por al menos 10 y Polyglots no da abasto.

La traducción de WordPress con IA está saturando al equipo Polyglots. El 14/10/2026 Tobi Fjellner publicó que muchos desarrolladores traducen sus plugins con ChatGPT o Claude a idiomas que no hablan. Los voluntarios tienen que revisar esos strings, y los pedidos de PTE se multiplicaron por al menos 10.

La localización de la UI de WordPress es el proceso de traducir los textos de la interfaz (core, plugins y temas) a cada idioma o variante regional, que WordPress llama locale (por ejemplo es_MX o es_AR). Cada texto traducible es un string. Las traducciones se envían y se aprueban en translate.wordpress.org, una plataforma que corre sobre GlotPress y que mantienen editores voluntarios de cada idioma.

¿Por qué la traducción de WordPress con IA satura a los voluntarios de Polyglots?

Porque generar una traducción con un LLM lleva unos minutos y algunos tokens, y validarla lleva horas de trabajo voluntario. Según Fjellner, los desarrolladores traducen en bloque con ChatGPT, Claude y similares a idiomas que no hablan, y después esperan que los voluntarios del equipo Polyglots (el grupo de traductores que cubre plugins, temas y documentación) validen o corrijan el resultado. Esa tarea exige más esfuerzo que producirlo.

La traducción automática no es nueva. Hace unos 20 años que existen herramientas de MT para acelerar el trabajo humano, y con una buena memoria de traducción (TM) y un traductor bien afinado se consiguen resultados casi perfectos. Lo que cambió es el flujo de trabajo.

Imaginate el circuito: exportás el .pot de tu plugin, se lo pasás a un modelo, en un rato tenés 500 strings en veinte idiomas, los subís a translate.wordpress.org, pedís permisos de aprobación para todos los locales juntos y de golpe diez equipos de voluntarios tienen que decidir si el solicitante sabe español, sueco o japonés.

El backlog, para la mayoría de los locales, crece en miles de strings por semana. Pocos equipos lo vacían con regularidad, y lo logran revisando una muestra y aprobando o rechazando la entrega entera. Fjellner resume la causa así: «La razón es la IA» (traducción nuestra del original en inglés). En el trabajo de la comunidad de WordPress profundizamos sobre esto.

Ojo, no es una queja contra los modelos. Según el recap de la sesión de GTE, los equipos de es_ES y pt_PT dijeron que la calidad de la salida de IA mejoró mucho en el último año. El problema que marcan es el volumen y «el 10% equivocado». A mi criterio, ese 10% es justo lo que un muestreo rápido no garantiza encontrar.

¿Qué es un PTE y por qué explotaron las solicitudes?

Un PTE (Project Translation Editor) es una persona con permiso para aprobar strings de un proyecto concreto (BuddyPress, WooCommerce o un tema) en un único locale. Lo nombra un General Translation Editor (GTE), a pedido del autor del proyecto o de los propios contribuyentes. Es, a grandes rasgos, un «committer» de traducciones.

Fjellner cuenta que hoy reciben al menos 10 veces más solicitudes por semana que antes. Además, los desarrolladores no piden el rol para los uno o dos idiomas que hablan, sino para 10 o 20 locales.

Como el PTE es un paso de control de calidad, la mayoría de los equipos quiere comprobar que quien lo pide domina el idioma. Ahí se traba todo. Según el recap, los equipos no pueden prometer una respuesta en dos días, y algunos solicitantes piden el rol solo para que aprueben rápido su propia salida de IA.

Existe un antecedente: el CL-PTE (Cross-Locale PTE), una cuenta de un autor u organización que usa traductores profesionales y puede validar strings en varios locales a la vez.

¿Qué evidencia hay del volumen de traducciones sin revisar?

Hay dos tipos de evidencia con pesos distintos. Las estadísticas públicas de translate.wordpress.org muestran strings en espera por locale. Los números por día salen de testimonios de la sesión del 3/10/2026, donde ocho GTE de siete locales (en_GB participó con dos personas) pusieron en común sus problemas. Son relatos de equipos, no métricas oficiales consolidadas.

En la columna Waiting Plugins de las estadísticas, al 15/10/2026, figuran estos valores:

• fr_FR tiene 852.731 strings en espera, pt_BR 567.723 e it_IT 442.899.
• El español está dividido por país: es_ES con 63.082, es_AR con 53.260, es_MX con 0.
• tr_TR muestra 59.130 en plugins y 0 en temas.

¿Cuántos de esos strings vienen de un LLM? Las fuentes no lo desglosan. Con esa tabla no podés concluir que el backlog sea culpa de la IA, solo que es grande y desparejo.

Del recap salen los testimonios:

• Volumen en es_ES: entre 300 y 5.000 envíos por día, según Luis Rull.
• Volumen en nl_NL: en un solo día llegaron cinco o seis proyectos con unos 500 strings inutilizables cada uno, según Peter Smits.
• Bulk limitado: las acciones masivas de GlotPress solo operan sobre una pantalla de strings, así que rechazar 600 strings de un usuario lleva varias páginas.
• Herramienta de revisión de Emre Erkan (tr_TR): según el recap, la cola de temas bajó de unos 22.000 strings a unos 4.000, y el tiempo de revisión pasó de horas a minutos. Es el dato de un solo desarrollador mostrando su propia herramienta, tomalo con pinzas.

Al 15/10/2026, la página de estadísticas mostraba 0 en Waiting Themes para tr_TR, pero no sé desde cuándo ni si tiene relación con esa herramienta.

¿Qué propone Polyglots para ordenar las traducciones con IA?

Polyglots plantea ideas, no decisiones. El recap lo dice textual: nada se decidió y el objetivo fue juntar opciones antes de pasar a decidir. Las propuestas de Fjellner son cinco:

• Guías de estilo legibles para LLM: escritas en inglés, en markdown, optimizadas como instrucciones y más fáciles de encontrar.
• Un rol de machine translator: puede distribuir traducciones, pero no aprobar, rechazar ni editar las ya aprobadas por otros.
• Nada de MT sin verificar en la TM, para que no se reutilice desde cualquier parte del proyecto.
• Bulk más fácil: aprobar y rechazar más que una pantalla por vez.
• Formación en i18n para desarrolladores, para que preparen el código de modo que se traduzca mejor.

En la sesión de GTE aparecieron más ideas. Un formulario de PTE con casillas (hablante nativo, leyó la guía de estilo, aplicó el glosario) dentro de GlotPress. Un tope de locales por solicitante. Un rechazo masivo por usuario. Y una primera pasada de revisión con IA que sugiere aprobar o rechazar con motivo, siempre con un humano que confirma.

Mi lectura: el rol separado es la más sensata, porque divide «publicar mi traducción» de «aprobar traducciones ajenas». Ahora bien, el recap aclara que la TM es código de Meta y no de GlotPress, y que los GTE hoy no pueden editar ni borrar entradas. Falta ver si el equipo de Meta lo permite. Complementá con probar los cambios en un entorno de staging.

¿Qué está confirmado y qué sigue sin definirse?

Confirmado, según las dos publicaciones del 14/10/2026:

• El aumento de solicitudes de PTE (al menos 10 veces por semana).
• La sesión del 3/10/2026 y los testimonios de volumen.
• El acuerdo de seguir conversando, con Fjellner planeando hablar con desarrolladores de plugins y temas.

Sin definir: el rol de machine translator, el formulario de PTE, la edición de la TM, los cambios de GlotPress y dónde se construiría cada cosa (como plugins de translate.wordpress.org o en el core de GlotPress, un punto en el que los participantes discreparon). El recap menciona volver sobre el tema en aproximadamente un mes y una masterclass sobre LLM sin fecha. No hay plazo de decisión.

¿Qué cambia si traducís tu plugin o tema con ChatGPT o Claude?

Se puede traducir con ChatGPT o Claude, pero subir el resultado no equivale a tenerlo aprobado. Un editor del locale tiene que validar los strings, y los equipos quieren comprobar que quien lo pide domina el idioma. Hoy la ruta rápida está cerrada, y las propuestas en discusión apuntan a que siga cerrada para las traducciones sin revisión humana. Ampliamos el tema en comparativa de plugins de autenticación en dos pasos.

Ejemplo hipotético: un plugin de 500 strings traducido a 12 locales son 6.000 strings que alguien tiene que mirar. Con los números del recap en nl_NL (cinco o seis proyectos de 500 strings en un día), se ve cómo se acumula. Más sobre esto en elegir entre Sucuri y Cloudflare.

Si publicás en español, ojo: es_ES, es_AR y es_MX son locales distintos con equipos distintos. Según Rull, el formal contra el informal es la mayor fuente de ruido en es_ES. Si el modelo no recibe una guía de estilo, puede mezclar tuteo y voseo, así que conviene chequearlo.

Un criterio de verificación, como propuesta editorial nuestra (no viene de la fuente y no lo probamos): Cubrimos ese tema en detalle en corregir enlaces rotos en tu sitio.

1. Antes de pedir el PTE, hacé revisar una muestra de unos 100 strings a una persona nativa del locale. Si el error fuera de uno cada 40, esperarías unos 2 o 3 en esa muestra; con tasas menores puede no aparecer ninguno, así que ampliala.
2. Contá los errores por tipo (glosario, formal o informal, contexto) y definí antes de empezar qué tasa te hace frenar el envío.
3. Pedí el rol solo para los locales donde alguien que habla el idioma se haga cargo.

Errores comunes al traducir con IA

• Pedir PTE para 15 locales. La fuente describe justo ese patrón (10 a 20) como el cuello de botella. Pedilo para los idiomas que hablás.
• Dar por buena una traducción porque «suena bien». La calidad mejoró, pero el problema es el 10% malo. Mirá una muestra con un hablante nativo.
• Ignorar la guía de estilo y el glosario del locale. Los propios GTE reconocen que es difícil encontrarlas, así que buscalas en el handbook y pasáselas al modelo.
• Mandar strings cortos sin contexto. Según Toby, los strings cortos cambian de significado según el contexto, y por eso se abandonó la propagación automática en coincidencias del 100%. En PHP, usá _x() para dar contexto.
• Esperar aprobación en dos días. Los equipos dijeron que no pueden prometerla.

Preguntas Frecuentes

¿Qué es el equipo Polyglots de WordPress?

Polyglots es el grupo de traductores voluntarios que traduce plugins, temas, documentación y textos de marketing de WordPress. Se organiza por locale y publica en su página de equipos, que hoy lista 208 locales.

¿Qué es un PTE (Project Translation Editor) en WordPress?

Es una persona que puede aprobar strings de un proyecto concreto en un único locale. Lo designa un General Translation Editor tras un pedido del autor del proyecto o de los propios contribuyentes.

¿Se pueden traducir plugins de WordPress con ChatGPT o Claude?

Sí, pero las traducciones necesitan revisión de alguien que hable el idioma para quedar aprobadas. Polyglots plantea guías de estilo pensadas para LLM y un rol específico para traducciones automáticas, aunque ambas son ideas en discusión.

¿Por qué hay tantas traducciones pendientes en translate.wordpress.org?

Porque entran más strings de los que los voluntarios pueden revisar. Fjellner lo atribuye a la traducción en bloque con LLM, y para la mayoría de los locales el backlog crece en miles por semana. Las estadísticas no distinguen cuántos vienen de IA.

¿Qué es una memoria de traducción (TM) y por qué no debería recibir traducciones sin verificar?

La TM permite reutilizar traducciones previas en todo el proyecto. Si recibe traducciones automáticas sin verificar, los errores se propagan: según el recap, los GTE no pueden editar ni borrar entradas, y las sugerencias erróneas siguen apareciendo por encima de las corregidas.

Conclusión

El problema de la traducción de WordPress con IA es de trabajo asimétrico: generar cuesta casi nada y revisar cuesta tiempo voluntario. Polyglots ya describió el diagnóstico y puso ideas sobre la mesa, pero todavía no decidió nada.

Si mantenés un plugin o un tema, no mandes traducciones de LLM a un montón de locales esperando que alguien las apruebe. Hacelas revisar con un hablante nativo, seguí la guía de estilo del locale y pedí permisos solo donde puedas responder. Y mirá la discusión de Polyglots: lo que se defina sobre roles y TM va a cambiar las reglas.

Fuentes

• Make WordPress Polyglots – The largest problems in WordPress UI localization in 2026 (14/10/2026)
• Make WordPress Polyglots – Recap de la sesión de brainstorming de GTE (14/10/2026)
• translate.wordpress.org – Translation status overview
• Make WordPress Polyglots – Translation Teams