Una fuente, varios idiomas, la misma ruta
Internacionalizar un producto parece sencillo mientras el producto todavía cabe en una pantalla. Extraes unas cadenas, añades un selector de idioma, traduces los botones y das por resuelto el problema. Esa imagen se rompe en cuanto aparecen decenas de juegos, rutas, categorías, ayudas, estadísticas, metadatos SEO, contenido generado y artículos largos. En septiembre de 2026, cuando el proyecto todavía se llamaba Blupoli, nos encontramos justo en ese punto: traducir ya no era una tarea de texto, sino una restricción de arquitectura.
Hoy la marca es Blupoli y el producto de puzzles es Blupoli Puzzles. También ha evolucionado el pipeline editorial y la forma en que construimos rutas localizadas. Pero la pregunta que abrió aquel trabajo sigue siendo la misma: ¿cómo hacer que una persona pueda usar el mismo producto en varios idiomas sin crear una copia independiente del producto por cada idioma? La respuesta empieza separando identidad, lógica y presentación.
Un juego no cambia de identidad porque cambie el idioma
Un Sudoku guardado debe seguir siendo el mismo Sudoku si el usuario pasa de español a inglés. Sus estadísticas no deberían duplicarse, sus favoritos no deberían desaparecer y su partida no debería convertirse en otra entidad. Lo mismo ocurre con una categoría, una dificultad o una configuración. El idioma cambia cómo explicamos esas cosas, no qué son internamente.
Esta regla parece obvia, pero obliga a cuidar los identificadores. Si el nombre visible se utiliza como clave, traducirlo rompe referencias. Si la categoría “Números” es literalmente la identidad del dato, “Numbers” parece otra categoría. Un sistema robusto trabaja con IDs estables y coloca las etiquetas localizadas encima. Así, la lógica puede permanecer intacta mientras la presentación cambia.
Traducir la interfaz es solo la capa más pequeña
Botones como “Nueva partida”, “Deshacer” o “Ayuda” son el caso cómodo. Son cadenas breves, reutilizadas y con un contexto relativamente estable. Pueden vivir en catálogos de traducción, validarse para detectar claves ausentes y cargarse según el locale activo. Esta parte sigue siendo importante, pero no representa la complejidad real de una plataforma.
Los problemas interesantes aparecen en textos con contexto, datos localizables, contenido generado y piezas editoriales. Una descripción de categoría no es una etiqueta. Una pista del Acertijo de Einstein no es una cadena fija. Un artículo de tres mil palabras no debería pasar por el mismo mecanismo que el texto de un botón. Internacionalizar bien significa aceptar que existen varias escalas de contenido.
Tres escalas necesitan tres estrategias
La primera escala es la UI: cadenas cortas y repetidas. La segunda son los datos de producto: nombres, resúmenes, categorías, reglas y metadatos que pertenecen a entidades estables. La tercera es editorial: Blog, Devlog, guías y textos largos con voz, intención y SEO propios. Intentar resolver las tres con un único diccionario produce un sistema incómodo para autores y desarrolladores.
La separación permite aplicar controles adecuados. La UI puede exigir cobertura de claves. Los datos pueden validar que todos los juegos tienen los campos localizables necesarios. El contenido editorial puede admitir que una traducción todavía no exista sin publicar una copia engañosa en otro idioma. Cada capa conserva un contrato claro.
Las rutas también son producto
Una web multidioma necesita decidir cómo representa cada locale en la URL. No basta con cambiar textos en el navegador: la dirección debe ser estable, enlazable y comprensible para el build, los buscadores y el propio usuario. Las rutas localizadas permiten que una página tenga una identidad pública clara en cada idioma.
El pipeline actual de Blupoli construye árboles de rutas por locale y aplica reglas específicas al contenido editorial. Esa automatización no elimina la necesidad de pensar la arquitectura; la hace repetible. Un enlace interno puede mantenerse dentro del idioma correcto y el sistema puede detectar cuando una traducción no existe en lugar de fingir que existe.
El fallback correcto no es publicar español bajo una URL inglesa
Una de las decisiones más importantes del sistema editorial es aceptar la ausencia de traducción como un estado válido. Si un artículo solo existe en español, generar automáticamente una ruta inglesa con exactamente el mismo texto crea contenido duplicado y confunde tanto a lectores como a buscadores. Parece cobertura, pero es cobertura ficticia.
La documentación actual del proyecto conserva este principio: las traducciones inglesas son archivos reales, no clones automáticos del original. Cuando faltan, la versión inglesa del índice puede señalar la disponibilidad del artículo español sin inventar una traducción. La skill de write-blog es más estricta para contenido nuevo y exige paridad ES+EN, pero la arquitectura sigue sabiendo representar correctamente contenido legado incompleto.
Canonical y hreflang cuentan la relación entre versiones
Una traducción no es una página aislada. El SEO internacional necesita declarar qué URL es canónica para cada idioma y qué alternativas corresponden al mismo contenido. Las etiquetas hreflang funcionan como una red explícita entre versiones equivalentes. El objetivo no es decorar el head, sino evitar que dos idiomas compitan como duplicados o que el buscador muestre una versión inadecuada.
Esto obliga a que fecha, autor y slug mantengan coherencia entre traducciones mientras título, descripción y cuerpo pueden ser plenamente locales. También obliga a revisar el resultado generado, porque un prefijo duplicado o una canonical incorrecta puede convertir una traducción correcta en una señal SEO contradictoria.
El título inglés merece ser un título inglés
La internacionalización editorial no termina cuando el cuerpo está traducido. Título, H1, meta description, Open Graph, Twitter card, texto alternativo y datos estructurados forman parte de la experiencia. Una portada generada con un título español sobre una página inglesa puede parecer un detalle menor, pero comunica que la localización está incompleta.
Este problema apareció de forma práctica durante la reescritura del Blog y nos llevó a generar portadas localizadas cuando el asset editorial incluye texto. Es un buen ejemplo de cómo una exigencia de idioma descubre dependencias que antes parecían invisibles. Localizar el contenido obliga a recorrer toda la cadena de publicación, no solo el HTML visible.
Los enlaces internos necesitan conocer el locale
Un artículo en inglés que enlaza constantemente a páginas españolas rompe la sensación de producto incluso si cada destino funciona. El mismo problema puede aparecer por automatización: un proceso añade el prefijo del locale a una URL que ya lo tenía y termina construyendo rutas como /en/en/.... Ese tipo de fallo no se detecta leyendo el texto, sino validando la arquitectura de enlaces.
Por eso el build incluye normalización específica para contenido localizado. El autor puede concentrarse en el destino lógico y el pipeline debe garantizar que el resultado final apunte a la ruta correcta sin duplicar prefijos ni alterar assets compartidos. Los enlaces forman parte de la localización porque mantienen al lector dentro de su contexto lingüístico.
No todos los assets deben duplicarse por idioma
Una imagen abstracta de un tablero puede compartirse entre español e inglés si no contiene texto y su significado es el mismo. Duplicarla solo crea más archivos que mantener. Una infografía con etiquetas incrustadas, en cambio, puede necesitar versiones localizadas. La decisión depende de si el idioma forma parte del contenido visual.
En Blupoli intentamos preferir gráficos que comuniquen estructura con formas, relaciones y composición, dejando el texto explicativo en el HTML mediante alt y captions localizados. Eso permite reutilizar un asset sin convertirlo en una imagen muda. Cuando el texto visual es imprescindible, el pipeline necesita saber que existen variantes por locale.
El texto alternativo también se traduce
Compartir la misma imagen no significa compartir su alt. El texto alternativo describe la función o contenido relevante de la imagen para la página concreta. Una persona que navega en inglés no debería encontrar una descripción española simplemente porque el SVG es el mismo archivo.
Lo mismo ocurre con captions, labels y nombres accesibles. La accesibilidad no es una capa paralela a la internacionalización; ambas dependen de significado. Si el contenido visible cambia de idioma y los textos de asistencia no cambian, la página queda partida en dos experiencias diferentes.
Las fechas y números revelan enseguida una localización superficial
Traducir palabras sin adaptar formatos produce interfaces extrañas. Meses, separadores, orden de día y año, decimales, porcentajes y unidades tienen convenciones distintas. Un artículo puede preservar la misma fecha de publicación y mostrarla de forma idiomática en cada versión. La identidad temporal es única; su presentación es local.
Este principio es útil en todo el producto. Las estadísticas deberían guardar números, no cadenas ya formateadas. La UI aplica el locale al presentarlos. Así cambiar idioma no obliga a recalcular datos ni a persistir representaciones específicas de una región.
Pluralizar es lógica lingüística, no concatenación
“1 partida” y “2 partidas” parecen un caso trivial hasta que añadimos idiomas con reglas de plural diferentes. Construir frases concatenando un número con una palabra traducida suele fallar en cuanto la gramática se complica. Las APIs de internacionalización existen precisamente para representar estas reglas.
La lección general es evitar que la lógica de negocio improvise lenguaje. El motor produce cantidades y estados; la capa de presentación elige la forma lingüística adecuada. La misma separación que ayuda al Acertijo de Einstein con sus pistas ayuda también a una estadística sencilla.
El contenido generado obliga a pensar en semántica
Algunos puzzles apenas muestran texto durante una partida. Otros generan frases. El motor del Acertijo de Einstein es un ejemplo claro: una pista de vecindad debe existir como relación estructurada y después renderizarse según el idioma. Si el generador produce directamente “A está junto a B”, el español queda incrustado en el motor.
Separar significado de superficie hace posible añadir otro idioma sin reescribir el algoritmo. También facilita tests: podemos comprobar que la relación es correcta independientemente de cómo se redacte. La localización se convierte así en una prueba de calidad arquitectónica.
Persistir una partida no debería persistir un idioma accidentalmente
Si una sesión guarda pistas como frases ya renderizadas, cambiar de idioma a mitad de partida deja contenido mezclado. Guardar la representación semántica permite reconstruir la UI con el locale actual. El estado sigue siendo el mismo; su presentación puede cambiar.
Este enfoque vale para cualquier dato persistido: IDs de juegos, dificultad, categorías y acciones deberían permanecer neutrales respecto al idioma. Las traducciones se aplican al recuperar el estado. Es otra consecuencia de tratar identidad y presentación como responsabilidades distintas.
Las categorías necesitan traducción editorial, no solo etiquetas equivalentes
Una categoría enriquecida puede incluir explicación de mecánicas, habilidades cognitivas y ejemplos. Traducir su nombre no basta. El texto completo debe sonar natural, conservar precisión y utilizar los términos que la comunidad del idioma espera. Una traducción literal puede ser técnicamente correcta y editorialmente torpe.
Por eso la internacionalización también exige criterio terminológico. Si decidimos cómo traducir “candidate”, “clue”, “region” o “constraint”, esa elección debería mantenerse en juegos, ayuda y artículos. La consistencia lingüística reduce el esfuerzo de aprendizaje igual que la consistencia visual.
Un glosario es infraestructura de producto
Cuando el catálogo crece, las decisiones terminológicas dejan de caber en la memoria de una persona. Un glosario o convenciones documentadas ayudan a evitar que el mismo concepto reciba tres nombres en tres juegos. También facilitan revisar traducciones generadas o asistidas por IA, porque existe una referencia concreta contra la que comparar.
La utilidad del glosario no consiste en congelar el lenguaje. Puede evolucionar. Lo importante es registrar la decisión y propagarla de forma deliberada. Sin esa memoria, cada nueva traducción vuelve a abrir debates ya resueltos.
La IA acelera traducción, pero no elimina la revisión
Los agentes pueden producir una primera versión completa muy rápido, especialmente cuando disponen de contexto, glosarios y el artículo original. Esa velocidad es valiosa, pero crea un riesgo: confundir cobertura con calidad. Una traducción puede incluir todas las frases y seguir sonando artificial, perder un matiz o traducir mal un término del puzzle.
Por eso tratamos el inglés editorial como transcreación. Conserva hechos, estructura y enlaces cuando sirven, pero se reescribe para que el ritmo sea natural. Después pasa por una revisión propia de títulos, puntuación, anchors y search intent. La paridad es de información, no de sintaxis.
La localización también puede romper layout
Un botón que cabe en inglés puede ser mucho más largo en español, alemán o francés. Un encabezado puede envolver en dos líneas. Una tabla puede dejar de caber. Si el componente solo funciona con la longitud de la cadena original, la localización descubre una deuda de diseño.
Responsive e i18n se refuerzan mutuamente: ambos prueban cuánto depende la interfaz de supuestos rígidos. Diseñar componentes que toleren variación textual mejora el producto incluso antes de añadir un nuevo idioma, porque también soporta accesibilidad, zoom y tamaños de pantalla inesperados.
El selector de idioma es casi el final del problema
El control visible para cambiar idioma es importante, pero representa una fracción pequeña del sistema. Antes hay que resolver rutas, persistencia de preferencia, estado, fallbacks, enlaces, datos, metadatos y contenido. Un selector bonito encima de páginas parcialmente traducidas solo hace más visible la incoherencia.
Por eso preferimos medir cobertura real. Saber qué superficies están localizadas y cuáles no permite avanzar de forma honesta. La interfaz puede comunicar un fallback en lugar de presentar una experiencia híbrida sin explicación.
El build puede convertir las reglas de idioma en gates
Una arquitectura declarativa permite automatizar comprobaciones: que las traducciones conserven fecha y autor, que no se publique una ruta inglesa con cuerpo español, que los alternates sean recíprocos, que las canonical apunten al locale correcto, que los assets existan y que los enlaces internos no generen prefijos duplicados.
Estas validaciones son especialmente valiosas porque los errores de i18n suelen ser silenciosos. La página carga, pero la señal SEO es incorrecta; el enlace funciona, pero cambia de idioma; el título está traducido, pero la portada no. Un quality gate convierte detalles fáciles de olvidar en requisitos repetibles.
La internacionalización obliga a pensar qué es realmente compartido
Igual que el modo claro descubre colores hardcodeados, otro idioma descubre texto hardcodeado, rutas rígidas y datos que mezclan identidad con presentación. Por eso i18n funciona como una auditoría de arquitectura. Las piezas bien separadas suelen localizarse con menos fricción; las piezas acopladas exigen excepciones.
La meta no es conseguir cero excepciones. Hay contenido cultural o mecánicas que necesitarán tratamiento específico. La meta es que esas excepciones sean deliberadas, no accidentes producidos por un sistema que asumía un único idioma.
El SEO internacional tiene que formar parte del flujo editorial
El título que funciona como búsqueda en español puede no ser la mejor consulta en inglés. La meta description debe sonar natural en cada idioma. Los anchors internos deben describir el destino para el lector local. Incluso cuando dos versiones comparten estructura, cada una necesita una revisión SEO propia.
Esto evita la tentación de traducir palabras clave mecánicamente. El objetivo no es repetir una frase exacta, sino responder a una intención de búsqueda equivalente. Un buen sistema automatiza las etiquetas técnicas y deja a la edición decidir cómo contar el contenido.
La misma historia puede tener dos ritmos distintos
Una traducción literal suele conservar la longitud de las frases, los conectores y el orden argumental del original aunque el segundo idioma pida otra cosa. Por eso la versión inglesa de nuestros artículos puede reorganizar una transición o elegir una metáfora distinta sin alterar hechos. Esa libertad editorial es compatible con la paridad.
Lo que no puede cambiar sin intención es la sustancia: fechas, estado de producto, autoría, enlaces importantes, advertencias y distinciones entre lo publicado, lo probado y lo planeado. La transcreación adapta la voz; no reescribe la historia.
Internacionalizar pronto evita que cada nueva función nazca con deuda
Posponer i18n puede parecer eficiente mientras el producto cambia deprisa. El coste aparece después, cuando cada nuevo componente, juego y artículo añade otra cadena que habrá que extraer. Introducir la restricción antes hace que lo nuevo nazca con separación entre lógica y presentación.
No significa traducir absolutamente todo el primer día. Significa que el sistema sabe que existen idiomas. Una función puede salir inicialmente con cobertura limitada y aun así utilizar IDs estables, catálogos de cadenas y rutas preparadas para crecer. La arquitectura evita que la deuda se multiplique.
La calidad gana cuando la ausencia es explícita
Hay una idea contraintuitiva que sigue siendo útil: una traducción que falta puede ser mejor que una traducción falsa. Si todavía no hemos revisado un artículo, mostrarlo claramente en su idioma original preserva confianza. Publicar una versión automática sin control puede cumplir una métrica de cobertura mientras empeora la experiencia.
La infraestructura debe soportar esa honestidad. Un contenido puede estar disponible en español, enlazarse desde el índice inglés con una indicación adecuada y ganar su ruta inglesa solo cuando existe una edición real. Esta capacidad permite que calidad y velocidad no tengan que fingir que avanzan al mismo ritmo.
QA multidioma significa probar recorridos, no solo cadenas
Una revisión de traducciones puede confirmar que cada frase existe y aun así pasar por alto un fallo de producto. Hay que recorrer navegación, cambio de idioma, vuelta atrás, enlaces desde el Blog hacia Puzzles, persistencia de una partida, estados vacíos y páginas que todavía no tienen versión equivalente. El idioma modifica caminos completos, no únicamente etiquetas aisladas.
Por eso las pruebas más útiles combinan validación automática con recorridos reales. El build puede garantizar invariantes y el QA puede observar si el cambio de contexto resulta comprensible. Esa combinación evita dos extremos: confiar solo en capturas visuales o confiar solo en que no falte ninguna clave.
De Blupoli a Blupoli: la restricción sobrevivió al cambio de marca
El nombre del producto cambió, la arquitectura pública evolucionó y el pipeline editorial se volvió mucho más exigente. Sin embargo, la decisión de fondo sigue intacta: Blupoli no debería multiplicar su lógica cada vez que añade un idioma. Los motores, IDs y estados continúan siendo una sola fuente de verdad.
Lo que se multiplica es la presentación: textos, títulos, descripciones, rutas públicas y piezas editoriales adaptadas a cada lector. Ese es el tipo de duplicación que queremos, porque añade accesibilidad cultural sin crear productos divergentes.
Un idioma nuevo debería abrir una puerta, no crear otra casa
La metáfora resume la arquitectura que perseguimos. Cada locale necesita una entrada propia, señales SEO claras y una experiencia coherente. Pero detrás de esa puerta debe seguir existiendo la misma plataforma: los mismos juegos, las mismas partidas, los mismos IDs y las mismas reglas.
Cuando esa separación funciona, añadir un idioma sigue siendo trabajo —traducción, QA, terminología, layout, SEO—, pero deja de ser una reescritura. Y ese es el objetivo real de internacionalizar bien: que la diversidad lingüística aumente el alcance del producto sin fragmentar la ingeniería que lo sostiene.