La internacionalización suele enseñarse con un ejemplo muy cómodo: sustituir una cadena por una clave y cargar otro diccionario. Ese problema existe, pero en una plataforma con el catálogo anunciado es solo el principio. También hay nombres de juegos, categorías, reglas, onboarding, estadísticas, rutas, metadatos, artículos, canonical, hreflang y contenido que no se traduce al mismo ritmo.
Por eso durante la primera fase mantuvimos cuatro idiomas como candidatos. Podíamos construirlos, medir su cobertura y corregir el pipeline sin prometer todavía una versión pública completa. Hoy la configuración ha cambiado: locales contiene los seis idiomas soportados y candidateLocales ha quedado vacío.
Publicar un idioma no es encender un selector
El selector es la parte visible. El contrato real está debajo. Si alguien cambia a alemán desde el catálogo, el nombre de los juegos y las categorías deben seguir en alemán. Si entra en estadísticas, los datos dinámicos no pueden volver silenciosamente al español. Si comparte una ruta, el canonical y los alternates deben describir las versiones que realmente existen.
Esta fase nos obligó a mirar la localización como una propiedad transversal del producto. No basta con que una pantalla principal esté traducida si una fuente de datos secundaria sigue generándose en el idioma base.
El catálogo localizado era una pieza más importante de lo que parecía
Una de las correcciones de esta última etapa fue generar catálogos localizados y hacer que superficies como estadísticas consumieran esos catálogos. Antes era posible traducir la interfaz que rodeaba un dato y seguir mostrando dentro un nombre o una categoría procedente de la fuente española.
Es un fallo fácil de pasar por alto porque el componente «parece traducido». La prueba correcta no es contar cadenas localizadas, sino recorrer el camino completo que termina produciendo texto en pantalla.
Las fechas nos recordaron que presentar y validar son responsabilidades distintas
El Journal añadió otro caso útil. Una fecha puede almacenarse y validarse con una representación estable, pero mostrarse de forma distinta según el idioma. Cuando esas dos responsabilidades se mezclan, un cambio de formato local puede hacer fallar una comprobación que en realidad no debería depender de cómo ve la fecha el lector.
La solución fue desacoplar la validación editorial del formato localizado. Es un detalle pequeño, pero representa bien el tipo de problemas que aparecen cuando i18n deja de ser una capa de texto y entra en el pipeline de publicación.
Seis idiomas no significan que todo el Journal tenga seis traducciones
Esta distinción sigue siendo deliberada. La plataforma puede estar publicada en seis idiomas y un artículo concreto continuar disponible solo en español. El sistema del Journal admite esa cobertura parcial: si no existe una traducción real, no debe inventarse una URL localizada equivalente ni anunciar un hreflang que apunte a contenido duplicado.
Preferimos una ausencia honesta a una paridad ficticia. Los artículos traducidos se publican como versiones reales; los demás pueden seguir siendo descubribles desde otros idiomas enlazando al original y dejando claro cuál es su lengua.
El mismo principio se aplica a las reglas de los juegos
En un artículo, una traducción torpe puede afectar a la claridad. En una regla puede cambiar la mecánica. Por eso reglas, ayudas y onboarding requieren más cuidado que una etiqueta de navegación. En el sprint reciente hemos seguido incorporando traducciones junto a motores nuevos como Kropki y Ball Sort, en lugar de tratarlas como una tarea posterior desconectada.
Esto también cambia la definición de terminado de un juego. Entrar en el catálogo global significa encajar en el sistema de localización, no solo funcionar en el idioma en el que se programó primero.
El SEO también tiene que conocer la verdad del producto
Rutas localizadas, canonical, hreflang, sitemap y metadatos sociales se generan dentro del mismo build. Si la lista de idiomas publicados cambia, esas superficies deben cambiar con ella. No queremos seis copias indexables que compitan entre sí ni alternates que apunten a páginas inexistentes.
El objetivo no es añadir más etiquetas por cumplir un checklist. Es que buscadores y lectores reciban el mismo mapa del sitio: qué idiomas existen, cuál es la URL canónica de cada versión y dónde no hay todavía traducción.
Los gates sirvieron precisamente porque encontraron problemas
Un gate que nunca falla puede ser tranquilizador y poco útil. Durante la preparación de los idiomas candidatos encontramos rutas, catálogo dinámico, selector del Journal y validaciones que necesitaban ajustes. Eso era exactamente lo que queríamos que ocurriera antes de convertir la cobertura en una promesa pública.
La publicación no demuestra que la internacionalización esté terminada para siempre. Demuestra algo más operativo: existe un proceso capaz de hacer visibles los huecos, corregirlos y volver a verificar el conjunto.
La arquitectura empieza a pagar su coste
Construir perfiles de locale, catálogos localizados, reglas de publicación parcial y comprobaciones adicionales añade complejidad. La recompensa aparece ahora: activar cuatro idiomas más no ha requerido clonar rutas, motores, Home, estadísticas y Journal cuatro veces.
Seguimos teniendo una plataforma y múltiples representaciones lingüísticas. Esa diferencia reduce mantenimiento, pero también evita divergencias de producto: una mejora del motor o de la navegación no debería convertirse en seis proyectos que avanzan a velocidades distintas.
Lo siguiente ya no es «añadir i18n»
Con los seis idiomas publicados, el trabajo cambia de naturaleza. Ahora toca vigilar calidad continua: nuevos juegos, nuevas categorías, nuevos artículos, cambios en onboarding y nuevas superficies deben entrar ya pensando en localización. La internacionalización deja de ser una migración y se convierte en una condición normal del desarrollo.
También podremos decidir dónde merece la pena invertir más traducción editorial. No todos los artículos necesitan la misma prioridad ni todos los idiomas tendrán el mismo ritmo. La infraestructura nos permite tomar esas decisiones sin romper la coherencia básica del producto.
La mejor señal es que el séptimo idioma sería un problema conocido
Hace unos días, añadir otro idioma significaba abrir una lista de incertidumbres: qué rutas duplicar, qué catálogo modificar, qué ocurre con el Journal y cómo evitar fallbacks engañosos. Hoy esas preguntas tienen lugares concretos dentro del sistema.
No significa que el séptimo idioma sea gratis. Significa que ya sabemos qué contrato debe cumplir. Y en una plataforma que sigue creciendo tan rápido, convertir una expansión futura en un proceso repetible es probablemente más valioso que la traducción concreta que acabamos de publicar.
La publicación convirtió el locale en una condición normal del desarrollo
Antes de este momento todavía podíamos describir i18n como una migración: preparar diccionarios, rutas y contenido para una plataforma que ya existía. Después de publicar seis idiomas, cada nueva feature tenía que nacer dentro de esa realidad. Un juego, una categoría o una pantalla ya no podían asumir que el español era el único estado “real” y que el resto llegaría después. La cobertura lingüística pasó a formar parte de la definición de terminado, igual que responsive, accesibilidad o persistencia.
Una misma partida tenía que sobrevivir al cambio de idioma
Cambiar de español a alemán no debía crear otra entidad de juego. El identificador, el progreso, la dificultad, las estadísticas y cualquier estado persistido tenían que seguir siendo los mismos. Solo cambiaba la presentación: nombre visible, categoría, reglas, ayuda y textos de la interfaz. Esta frontera protege el dominio. IDs estables permiten que un único motor y una única sesión soporten varias presentaciones sin clonar el producto.
El selector pasó a ser navegación contextual
Una persona que cambia idioma desde una categoría o una partida espera permanecer en el mismo contexto. Volver siempre a la home pierde información y hace que la localización parezca añadida a posteriori. Por eso las rutas tienen que conocer sus equivalentes y el selector deja de ser una preferencia aislada. Los enlaces internos siguen la misma lógica y deberían preservar el locale cuando existe destino equivalente.
Los datos dinámicos revelaron dónde terminaba de verdad la localización
El problema del catálogo localizado mostró que una interfaz puede estar traducida y seguir siendo bilingüe. Los nombres y categorías que llegan desde manifests o catálogos generados forman parte de la experiencia tanto como los labels escritos en el componente. La lección fue seguir cada fragmento de texto hasta su origen. El dato necesita una identidad estable y una representación localizable.
Las pistas generadas necesitaban significado antes que lenguaje
Los motores que producen texto en tiempo de ejecución obligan a separar lógica y presentación. Una relación como “A está inmediatamente a la izquierda de B” debería existir primero como datos semánticos y solo después convertirse en frase. El enfoque descrito en el motor del Acertijo de Einstein evita que el español quede incrustado en el dominio y permite expresar la misma verdad de manera natural en varios idiomas.
El SEO internacional se volvió otro consumidor del estado público
Canonical, hreflang, sitemap y metadatos sociales tenían que reaccionar al cambio de candidatos a publicados. No bastaba con que el selector mostrase seis opciones si el mapa técnico seguía describiendo dos o anunciaba rutas que no existían. El objetivo era que buscadores y personas recibieran la misma historia sobre disponibilidad, URL canónica y cobertura editorial.
La cobertura editorial podía seguir siendo parcial
Publicar seis idiomas a nivel de producto no obligaba a que cada artículo histórico del Journal tuviera seis traducciones instantáneamente. Mezclar esas dos decisiones habría convertido una mejora de producto en una deuda editorial inmanejable. Preferimos representar la cobertura parcial de forma honesta. Una ruta localizada solo debe existir cuando contiene contenido localizado de verdad.
Los textos largos convirtieron el lanzamiento en una prueba responsive
Alemán, francés, italiano y portugués no ocupan el mismo espacio que español o inglés. Botones, tarjetas y encabezados cambian de longitud. El release obligó a probar layouts reales en móvil y escritorio, no únicamente archivos de traducción. La meta no era obtener geometría idéntica, sino mantener jerarquía, legibilidad y objetivos táctiles aunque el copy creciera.
La accesibilidad tenía que seguir el mismo locale
Alt text, aria-labels y mensajes anunciados por tecnologías de asistencia forman parte de la experiencia aunque no sean visibles. Una pantalla alemana con etiquetas accesibles en español no está completamente localizada. La publicación de los seis idiomas reforzó la idea de que accesibilidad e i18n comparten una responsabilidad: ambas obligan a pensar más allá de lo que aparece en una captura.
Los errores y estados vacíos dejaron de ser secundarios
Una experiencia localizada debe sobrevivir también cuando algo sale mal. Mensajes de validación, contenido ausente, fallbacks y estados sin datos suelen aparecer precisamente cuando la persona necesita instrucciones claras. QA empezó a recorrer esos caminos en lugar de limitarse a home y catálogo. La calidad lingüística se mide en el journey completo.
La caché podía mezclar generaciones y crear falsos bugs de idioma
Un despliegue nuevo con scripts o catálogos antiguos puede producir combinaciones extrañas: una ruta localizada con datos de la versión anterior o un selector actualizado usando lógica vieja. El síntoma parece i18n; la causa puede estar en la entrega. Versionado, invalidación y revalidación se convierten así en parte de la publicación multilingüe.
La observabilidad necesitaba contexto lingüístico
Si un error aparece únicamente en una ruta italiana, registrar el locale junto a la versión y la ruta ayuda a reproducirlo. No es necesario recopilar más información personal; basta con conservar contexto técnico relevante. Esto hace que i18n deje de ser solo responsabilidad editorial y afecte también a debugging, alertas y capacidad de distinguir un fallo global de una regresión localizada.
La analítica por idioma necesitaba interpretación prudente
Con seis locales públicos aparecen nuevos datos: qué idiomas se usan, dónde se cambia, qué rutas presentan más abandonos. Es tentador convertir esos porcentajes en conclusiones sobre mercados o preferencias culturales. Sin embargo, idioma del navegador, enlaces compartidos y elecciones manuales pueden influir. Los datos describen comportamiento dentro del producto; las conclusiones estratégicas requieren contexto adicional.
El glosario pasó de ayuda editorial a memoria de plataforma
Región, borde, pista, bucle, candidato, adyacente o consecutivo aparecen en reglas, onboarding y artículos. Una traducción inconsistente entre superficies puede hacer que el producto parezca construido por piezas. Un glosario compartido ayuda a humanos y agentes a mantener terminología. No reemplaza la revisión contextual, pero evita resolver desde cero decisiones ya tomadas.
La IA aceleró el trabajo, pero no recibió autoridad de publicación
Los agentes podían detectar claves faltantes, producir borradores y comparar estructuras a gran velocidad. Eso hizo viable preparar varios idiomas en paralelo. La arquitectura conservó estados distintos: generado, revisado y publicado. Cuanto más barata se vuelve la generación, más importante es que la aprobación siga siendo una decisión explícita respaldada por gates.
La UI compartida redujo el número de lugares donde divergir
Una cabecera o selector compartido no localiza por sí solo el producto, pero permite aplicar la misma política de preferencia y navegación en varias superficies. El trabajo descrito en nuestro sistema de UI compartido gana valor cuando locale forma parte de esos contratos. Las diferencias reales pueden configurarse; las accidentales dejan de multiplicarse.
El onboarding se convirtió en otro consumidor de la arquitectura
Enseñar un puzzle no consiste únicamente en traducir “Siguiente”. La escena, la acción y la regla deben mantenerse coherentes en cada idioma. El sistema de onboarding por perfiles permite compartir estructura mientras el contenido específico sigue siendo localizable. Esto evita una explosión de tutoriales independientes por juego y por idioma.
Publicado no significaba congelado
Una traducción podía mejorar después. Podía aparecer un problema de wrapping, una formulación más natural o una terminología mejor. El estado publicado no declaraba perfección eterna. Declaraba una línea base suficientemente coherente y una infraestructura capaz de detectar regresiones. La calidad multilingüe se convertía en mantenimiento continuo.
El rollback seguía siendo posible
Separar “existe en el repositorio” de “está anunciado como público” también hacía posible retirar temporalmente un locale si aparecía un problema serio. Las traducciones podían permanecer disponibles mientras se corregía la incidencia. La reversibilidad reduce riesgo y refuerza la idea de que publicación es un estado operacional, no una carpeta irreversible.
La cifra histórica de el catálogo anunciado debía seguir siendo histórica
La entrada original registraba el catálogo anunciado en aquel momento. Esa cifra pertenece al 15 de septiembre de 2026 y no debe usarse como contador actual. Su valor aquí es mostrar escala: multiplicar manualmente nombres, reglas y metadatos por seis habría creado cientos de oportunidades para la divergencia. Centralizar identidad y localizar presentación permitió que catálogo e idiomas crecieran de forma mucho más independiente.
El artículo anterior explica por qué este cambio era seguro
La publicación no empieza en esta entrada. El día anterior documentamos cómo funcionaban los candidatos y los gates de calidad. Conservar ambas piezas evita presentar el resultado como un interruptor mágico. Primero construimos la capacidad de decir “todavía no” con evidencia. Después pudimos decir “sí” sin bajar el criterio.
El séptimo idioma dejó de ser un problema desconocido
Antes de esta fase, otra lengua abría preguntas sobre rutas, catálogos, SEO, selector, fallbacks y estadísticas. Después del lanzamiento, esas preguntas tenían lugares concretos en la arquitectura. Un séptimo idioma seguiría necesitando traducción y QA. La diferencia es que ya no requeriría inventar otra teoría de publicación. Esa capacidad repetible era más importante que la cifra seis.
Las rutas equivalentes necesitaban una identidad estable
Una página localizada no es una copia independiente, sino otra representación del mismo destino conceptual. Mantener una relación explícita entre versiones permite que el selector conserve contexto, que los enlaces internos elijan la edición correcta y que canonical y hreflang describan el conjunto sin contradicciones. Sin esa identidad compartida, cada locale termina pareciendo un sitio distinto y cualquier reorganización obliga a sincronizar rutas manualmente. La publicación de seis idiomas convirtió esa equivalencia en infraestructura, no en una comodidad del selector.
Los formatos regionales debían permanecer cerca de la presentación
Fechas, números, porcentajes y plurales no deberían almacenarse ya “traducidos”. Conservar valores estables y aplicar formato al final reduce errores y evita que una mejora visual rompa validadores. El lanzamiento puso este principio a prueba en muchas superficies a la vez: artículos, estadísticas, fechas de actividad y textos generados. El dominio guarda significado; la capa de presentación decide cómo expresarlo en cada locale. Esa separación hace que la misma información pueda representarse de manera natural sin convertir el formato visible en identidad.
Los assets necesitaban distinguir significado lingüístico de decoración
Un diagrama sin texto puede compartirse entre locales; una captura con instrucciones o una ilustración con copy incrustado puede necesitar variantes. Duplicar todos los assets por idioma crea deuda innecesaria, pero reutilizar imágenes que contienen lenguaje produce páginas mezcladas. La regla útil es semántica: si el recurso transmite información lingüística, debe localizarse o rediseñarse para separar texto y visual. Por eso las infografías text-free acompañadas de alt y captions localizados son especialmente valiosas en una plataforma multilingüe.
La búsqueda localizada debía aceptar cómo la gente nombra realmente los juegos
Traducir el título oficial de un puzzle no cubre todas las formas en que una persona puede buscarlo. Algunos juegos tienen nombres alternativos, términos tradicionales o descripciones populares distintas según el idioma. El índice puede incorporar sinónimos localizados manteniendo un único ID estable. Así búsqueda, estadísticas, recomendaciones y partidas guardadas siguen refiriéndose a la misma entidad mientras cada locale permite descubrirla con vocabulario natural. Localizar bien también significa reconocer cómo cambia el lenguaje de descubrimiento.
El orden del build dejó de ser un detalle invisible
Con seis locales, varias fases del pipeline localizan páginas, normalizan enlaces, generan SEO y finalizan assets. El orden de esas transformaciones importa. Una etapa tardía puede borrar un selector, restaurar un enlace no localizado o sustituir metadatos que otra fase acababa de corregir. Por eso el artefacto final necesita su propia validación. Los archivos fuente explican la intención; solo la página construida demuestra que todas las capas compusieron correctamente esa intención.
La preferencia lingüística y la ruta no son exactamente lo mismo
La preferencia del usuario puede ser compartida entre superficies de Blupoli, pero cada aplicación puede tener su propia convención de URLs. Guardar “prefiero alemán” y resolver “qué ruta alemana corresponde a esta pantalla” son responsabilidades diferentes. Separarlas evita que una aplicación imponga sus reglas de routing a otra. También permite que una URL explícita conserve el idioma solicitado aunque el navegador tenga otra preferencia, algo importante para enlaces compartidos y para reproducir incidencias.
Privacidad y consentimiento también entraron en el contrato multilingüe
Cuando una superficie pide aceptar, rechazar o configurar una opción de privacidad, el significado del control debe ser comprensible en el idioma activo. Ese copy no puede tratarse como texto secundario que “ya traduciremos”. Una localización parcial en este contexto afecta a la capacidad de tomar una decisión informada. La expansión a seis idiomas hizo más evidente que i18n atraviesa también las capas de producto que rodean al juego, no solo aquello que aparece dentro del tablero.
La checklist de release se convirtió en una pieza durable del producto
Después de este lanzamiento, “publicado” significaba algo verificable: cobertura, semántica, build final, rutas, SEO, mobile, accesibilidad, datos dinámicos, selector, errores y fallbacks habían sido revisados. La checklist no es burocracia; es una memoria operativa que permite repetir el proceso. El séptimo idioma puede apoyarse en ella, pero también cada juego nuevo: cualquier superficie que introduzca copy debe decidir desde el principio cómo participa en el contrato multilingüe.
La corrección posterior también necesitaba un flujo claro
Publicar no inmoviliza el lenguaje. Si aparece una traducción mejor o un problema semántico, la corrección debe poder pasar por el mismo pipeline que cualquier otro cambio: edición, review, build y verificación. Esto evita “arreglos rápidos” directamente sobre una versión generada que después se pierden en el siguiente deploy. La localización sostenible necesita que las mejoras normales sean tan fáciles de integrar como la primera publicación.
La lección final no era tener seis idiomas, sino una sola plataforma
El éxito de esta fase no se mide únicamente por seis opciones visibles en el selector. Se mide por lo que no tuvimos que crear: seis motores, seis modelos de estado, seis catálogos independientes y seis versiones de cada componente. La arquitectura permitió multiplicar representación sin multiplicar identidad. Esa es la base que hace posible seguir ampliando Blupoli Puzzles sin convertir cada idioma en otro producto que mantener.