Localizzare siti Wordpress con Cloude Code

WordPress Multilingüe con Claude Code: Cómo Tradujimos 72 Artículos a 5 Idiomas

Tenía un sitio WordPress en italiano e inglés. Quería añadir español, francés y alemán. Setenta y dos artículos por traducir a tres idiomas, más páginas de navegación, categorías, shortcodes, redirecciones, SEO. Ante ese volumen de trabajo, la respuesta honesta era: es imposible. No con el tiempo y los recursos de un proyecto personal. Luego usé Claude Code, y en ocho sesiones de trabajo distribuidas a lo largo de unas semanas completé todo.

Este artículo cuenta cómo fue de verdad: las decisiones, los errores, las soluciones y, sobre todo, qué significa colaborar con un agente de IA en un proyecto a escala real. No es una guía técnica paso a paso — es el relato de una experiencia, con suficientes detalles prácticos para que puedas replicarla.

La Frustración Inicial

El problema con la internacionalización de un sitio WordPress no es la traducción. Es la complejidad sistémica que rodea a la traducción.

Con Polylang — el plugin que uso para gestionar los idiomas — cada idioma no es solo una etiqueta sobre el texto. Es un conjunto separado de posts, páginas, categorías con IDs distintos, URLs con prefijo diferente, shortcodes que actualizar, redirecciones que configurar. Traducir un artículo manualmente significa: crear el post en el nuevo idioma, vincularlo al original, asignarle las categorías en la versión del nuevo idioma (no las italianas — las alemanas, con IDs distintos), copiar la imagen destacada, establecer la fecha correcta, rellenar los campos SEO. Por cada artículo. Por setenta y dos artículos. Por tres idiomas.

Miré las alternativas. Los plugins de traducción automática (WPML + DeepL, TranslatePress) traducen el texto pero no entienden la estructura — los bloques de Gutenberg con IDs de categoría en el código permanecen incorrectos, los shortcodes personalizados no se tocan, la configuración técnica sigue siendo responsabilidad tuya. Una agencia de localización habría gestionado la traducción pero no la parte técnica de WordPress. Un desarrollador freelance habría gestionado la parte técnica pero no la traducción. La combinación de ambas cosas, para setenta y dos artículos en tres idiomas, era un proyecto de meses y miles de euros.

Así que el proyecto se había estancado. Como se estancan la mayoría de los proyectos ambiciosos en sitios personales: no por falta de intención, sino por falta de tiempo y recursos.

La Primera Sesión: Entender Qué Podía Hacer Claude Code

Claude Code no es un chatbot al que hacer preguntas. Es un agente con acceso a las herramientas del sistema: puede leer y escribir archivos, ejecutar comandos en el terminal, consultar bases de datos, modificar código. Cuando le describí el problema — sitio WordPress, plugin Polylang, setenta y dos artículos, tres idiomas por añadir — no respondió con una lista de instrucciones a seguir. Empezó a trabajar.

Leyó el código del mu-plugin personalizado que gestiona la navegación del sitio. Consultó la base de datos para entender cómo Polylang organiza las traducciones internamente. Identificó los siete puntos del plugin que había que actualizar para admitir un nuevo idioma. Todo esto sin que yo le explicara cómo funciona Polylang — lo dedujo leyendo el código fuente y las estructuras de la base de datos.

Mi papel en esa primera sesión fue diferente de lo que esperaba. No estaba dando instrucciones técnicas. Estaba tomando decisiones: ¿añadimos alemán o chino? ¿Empezamos por el español o el francés? ¿Prioridad a la estructura de navegación o a los artículos? Las decisiones estratégicas eran mías. La ejecución técnica era de Claude Code.

Cómo Evolucionó la Colaboración

Tras la primera sesión entendí cuál era el patrón de colaboración que funcionaba mejor:

  • Yo aportaba el contexto y las prioridades: “esta semana quiero completar el francés”, “primero las páginas de navegación y luego los artículos”, “el alemán es más importante que el portugués porque el mercado DACH es relevante”
  • Claude Code aportaba el plan y la ejecución: proponía el enfoque, lo ejecutaba, mostraba el resultado, señalaba los problemas, corregía de forma autónoma cuando algo no funcionaba
  • Yo validaba el resultado: abrir el sitio en el nuevo idioma, comprobar que un artículo tuviera la imagen correcta, las categorías adecuadas, la fecha original

No hacía falta conocimiento técnico sobre Polylang, WP-CLI o PHP. Lo que hacía falta era saber qué quería conseguir y ser capaz de reconocer si el resultado era correcto.

El Problema de las Múltiples Sesiones y la Memoria

Un proyecto de esta escala — setenta y dos artículos por idioma — no se completa en una sesión. Claude Code tiene un límite de contexto: en un momento dado la conversación se vuelve demasiado larga y hay que empezar de nuevo. El riesgo es que cada sesión nueva comience desde cero, re-explorando cosas ya descubiertas, repitiendo errores ya resueltos.

La solución es el sistema de memoria persistente integrado en Claude Code: archivos de texto guardados en un directorio específico que se cargan automáticamente al inicio de cada nueva sesión. Usamos este sistema para guardar:

  • La lista completa de pasos para añadir un idioma (en orden, con los problemas de cada uno)
  • El mapeo de todas las categorías italiano → idioma destino
  • Los errores ya encontrados y los arreglos aplicados
  • El estado del proyecto: qué lotes se habían completado, cuántos artículos faltaban

Con estos archivos de memoria, cada nueva sesión retomaba exactamente donde se había detenido. El “coste de arranque” de una sesión se reducía a unos pocos minutos en lugar de horas de re-exploración.

Este es uno de los aspectos menos obvios de Claude Code: no es solo una herramienta para hacer cosas, sino también para construir conocimiento persistente sobre un proyecto a lo largo del tiempo.

El Pipeline Técnico que Funcionó

Para quienes quieran entender el lado técnico: el núcleo del proceso era un pipeline de tres fases.

Claude Code escribía las traducciones de los artículos y los metadatos en un archivo JSON estándar. Este archivo era leído después por un script PHP ejecutado directamente en el contexto de WordPress mediante WP-CLI. El script PHP creaba cada artículo en el nuevo idioma, lo vinculaba al original italiano, le asignaba las categorías en la versión del nuevo idioma, copiaba la imagen, establecía la fecha y rellenaba los campos SEO.

Cada lote procesaba diez artículos. Para setenta y dos artículos: siete u ocho lotes. Cada lote producía una salida legible — “OK IT:123 → DE:456 | Título del artículo” — que permitía verificar de inmediato qué había ido bien y qué no.

La elección del formato JSON como puente entre la generación de IA y la ejecución en WordPress no era obvia al principio — el primer enfoque usaba un formato diferente que producía errores de análisis. Pero una vez establecido el pipeline correcto, funcionó de forma fiable para todos los lotes posteriores.

Los Errores: Qué Salió Mal y Cómo Se Resolvió

Contar solo los éxitos sería deshonesto. Estos son los errores reales que encontramos.

El Primer Enfoque de Transferencia de Datos No Funcionó

El intento inicial era generar código PHP directamente desde el código Python usado para preparar los datos. El resultado fueron errores de análisis inmediatos: los dos lenguajes tienen convenciones diferentes para representar estructuras de datos, y mezclarlos producía código inválido. Solución: separar los formatos. Python escribe JSON estándar, PHP lee con sus funciones nativas. El JSON es un formato de intercambio de datos explícito — siempre funciona entre sistemas distintos.

Las Categorías de los Artículos Estaban en el Idioma Equivocado

Polylang crea un conjunto separado de identificadores numéricos para cada idioma. La categoría “Tecnología” en italiano tiene un número. En alemán tiene un número diferente. Si asignas el número italiano a un artículo alemán, le estás asignando la categoría italiana — y las cuadrículas de artículos muestran contenido mixto o vacío. Este error no era visible en la salida del script, solo al abrir el sitio en el nuevo idioma. De ahí la regla: validar siempre tras el primer lote, no al final de todos.

Una Categoría Alemana Apuntaba a “Uncategorized”

Cuando añadimos el alemán, una de las categorías ya estaba vinculada en la base de datos de Polylang a un término genérico creado automáticamente, no a la categoría real. Claude Code encontró la anomalía consultando la base de datos, creó la categoría correcta y actualizó el vínculo. Sin la posibilidad de consultar directamente la base de datos, este tipo de problema habría sido invisible hasta mucho más tarde.

Los Posts Se Creaban Sin Imagen y con la Fecha Incorrecta

La función de Polylang que crea posts en un nuevo idioma no copia automáticamente la imagen destacada ni la fecha de publicación original. Los artículos aparecían sin imagen y fechados en el día de la creación en lugar de la fecha original. Solución: añadir explícitamente en el script PHP la copia de la imagen y la fecha para cada artículo creado.

La Calidad de las Traducciones

La pregunta más habitual: ¿qué tan buena es la traducción generada por la IA?

Para contenido técnico — artículos sobre Linux, bases de datos, herramientas de desarrollo, Raspberry Pi — la calidad es muy buena. La terminología es correcta, los comandos permanecen sin cambios, las explicaciones son coherentes. Un lector alemán que lee un artículo sobre Ansible o SQL Server no notará que fue generado por una IA.

Para contenido más editorial — reseñas de videojuegos, reflexiones personales, artículos de opinión — la calidad es buena pero con un tono ligeramente más formal del que tendría un texto escrito de forma nativa. No es traducción literal: Claude Code adapta el contenido al contexto del idioma destino. Un artículo sobre Cyberpunk 2077 escrito con un registro coloquial en italiano se convierte en alemán en algo estilísticamente apropiado para el público alemán, no en una transposición palabra por palabra.

El umbral útil a tener en mente: la calidad es más que suficiente para llevar contenido de valor a lectores en distintos idiomas. No es idéntica a una traducción profesional humana. Pero es enormemente mejor que no tener nada — que era exactamente la situación de partida.

Por Qué Este Enfoque Es Diferente a un Traductor Automático

Un traductor automático (DeepL, Google Translate) hace una sola cosa: convierte texto de un idioma a otro. No toca la estructura del sitio, no actualiza el plugin de navegación, no crea las categorías en el nuevo idioma, no configura las redirecciones, no rellena los campos SEO.

Claude Code como agente hace todo esto junto. No porque sea “más inteligente” en un sentido abstracto, sino porque tiene acceso a las herramientas del sistema y puede actuar sobre ellas. La diferencia práctica es enorme: un traductor automático te da texto traducido para pegar. Claude Code te da un sitio funcionando en un nuevo idioma.

También hay una diferencia cualitativa en la propia traducción. Un traductor automático aplica reglas lingüísticas. Claude Code entiende el contexto: sabe que un artículo es la reseña de un videojuego, que el público es aficionado a la tecnología, que el tono debe ser informal pero preciso. La traducción resultante es más coherente con la intención original del artículo.

El Balance Final

Setenta y dos artículos para cinco idiomas. Cuarenta y cinco páginas de navegación. Quinientos cuarenta campos SEO. Decenas de actualizaciones en el código del plugin. Todo completado en sesiones de trabajo distribuidas a lo largo de unas semanas, sin un equipo, sin un presupuesto significativo, sin conocimiento técnico especializado en Polylang o WP-CLI.

Pero el número que más importa es uno solo: cero. Cero artículos en español, francés y alemán que habrían existido sin este enfoque. El proyecto habría permanecido en la lista de tareas pendientes, como había permanecido durante meses.

Esta es la verdadera ventaja de trabajar con un agente de IA en proyectos a escala: no que sea más rápido (lo es), no que cueste menos (así es), sino que hace factibles proyectos que de otro modo nunca se harían. Baja el umbral de acceso a un nivel en el que un único propietario de sitio puede hacer cosas que antes requerían un equipo.

Qué Necesitas para Empezar

Si quieres replicar este enfoque en tu sitio WordPress multilingüe, el punto de partida práctico:

  • Claude Code — la CLI de Anthropic, disponible en claude.ai/code. Requiere acceso al terminal del servidor donde corre tu WordPress
  • WP-CLI — instalado en el servidor, permite a Claude Code interactuar con WordPress desde la línea de comandos
  • Polylang — el plugin gratuito funciona. Pro añade algunas comodidades pero no es necesario
  • Un documento de contexto inicial — antes de empezar, escribe (o haz que Claude Code escriba) un documento que describa la estructura de tu sitio, los plugins usados, cómo funciona la navegación. Esto reduce drásticamente el tiempo de “calentamiento” de cada sesión

Lo menos obvio: tu papel no es dar instrucciones técnicas. Es saber qué quieres conseguir, aprobar los planes propuestos y validar los resultados. Las competencias técnicas las aporta Claude Code.