Traducir es también verificar
Blupoli ya tiene español e inglés como idiomas base y hemos preparado italiano, portugués, francés y alemán. La tentación natural era activar los cuatro en cuanto las traducciones estuvieran estructuralmente completas. Decidimos hacer lo contrario.
Los nuevos idiomas viven primero como candidatos. Tienen diccionarios de interfaz, taxonomía, SEO, contenido para los 73 juegos, controles dinámicos y una primera traducción del Journal, pero no aparecen como versiones publicadas hasta superar revisión y QA.
El estado candidato como cinturón de seguridad
Separar candidateLocales de los idiomas publicados nos permite construir una versión completa sin exponerla antes de tiempo. Es una distinción pequeña en configuración y enorme en comportamiento: las rutas públicas, hreflang, sitemap y selector sólo deben prometer aquello que realmente está listo.
También evita una forma frecuente de deuda: publicar un idioma al 80 %, olvidarlo y convivir durante meses con pantallas mezcladas.
73 juegos convierten las reglas en contenido crítico
En una tienda o un blog, una traducción ligeramente torpe puede ser un problema editorial. En un puzzle, una palabra equivocada puede cambiar la regla. Por eso distinguimos dominios: la interfaz y la taxonomía admiten revisión asistida; las reglas, ayudas y onboarding sensibles requieren una revisión semántica más estricta.
El pipeline registra ese estado. Si juegos o artículos siguen como needs_review, el gate estricto debe fallar. No queremos arreglar el test: queremos arreglar el estado real que el test está señalando.
El pipeline también necesitaba ser auditado
Durante este trabajo encontramos una paradoja: el comprobador de traducciones sólo recorría idiomas ya publicados. Eso dejaba fuera precisamente a los candidatos que necesitábamos validar antes de publicarlos. Lo hemos corregido para que el modo estricto pueda auditar también italiano, portugués, francés y alemán mientras continúan fuera de producción.
También detectamos un problema en el Journal: la fase que escribía un artículo traducido podía ejecutarse después de la que inyectaba el selector de idioma y terminar sobrescribiéndolo. El resultado podía ser una página correctamente traducida pero sin el control que permite cambiar de idioma. Ahora la fase editorial conserva e inyecta ese contrato de navegación.
Los fallbacks deben ser honestos
No todos los artículos del Journal estarán traducidos simultáneamente. En lugar de fabricar páginas duplicadas o hacer creer al buscador que existe una versión localizada, los índices pueden enlazar al original español e indicar que se trata de un fallback.
Eso hace visible una idea importante de la arquitectura: cobertura parcial no debe convertirse en cobertura ficticia.
Por qué empezamos por italiano
La activación será secuencial: italiano, portugués, francés y alemán. Publicar uno cada vez reduce el radio de error y permite comprobar que el proceso funciona de extremo a extremo antes de repetirlo. Si una incidencia aparece en italiano, la corregimos una vez antes de multiplicarla por tres.
La internacionalización deja así de ser una gran entrega y se convierte en un proceso repetible.
Qué significa estar realmente listo
Para nosotros no basta con que una página cargue. El selector debe mantener el contexto, las rutas internas deben permanecer en el idioma correcto, los juegos no deben mezclar etiquetas españolas, canonical y hreflang tienen que representar las versiones existentes, el sitemap debe coincidir con lo publicado y las pantallas tienen que resistir textos más largos en móvil.
Las estadísticas añaden otro caso interesante: no sirve traducir el título «Tu actividad» si el nombre o la categoría del juego llegan desde un catálogo generado únicamente en español. La localización también tiene que llegar a los datos dinámicos que terminan en pantalla.
La IA acelera; el gate decide
La IA nos permite preparar mucho contenido, detectar huecos y mantener estructuras equivalentes entre idiomas. Pero la velocidad de generación no elimina el riesgo semántico. Por eso el flujo conserva explícitamente el origen y el estado de revisión.
Es una forma de utilizar IA sin confundir producción de texto con aprobación del producto. Cuanto más rápido podemos generar, más importante se vuelve saber qué ha sido validado.
Lo siguiente
La siguiente fase es menos espectacular y más valiosa: comparar reglas y ayudas con la fuente del juego, corregir desviaciones, ejecutar los gates técnicos y hacer QA real de italiano. Sólo entonces it pasará de candidato a publicado. Después repetiremos el mismo camino con portugués, francés y alemán.
Si funciona, el resultado no será simplemente Blupoli en seis idiomas. Tendremos algo más útil: una forma segura de añadir el séptimo.
Publicar un locale es cambiar un contrato, no mover archivos
La distinción entre candidato y publicado solo resulta útil si todas las superficies obedecen el mismo estado. El selector, las rutas generadas, hreflang, sitemap, índices, catálogos y cualquier mensaje que anuncie disponibilidad deben derivar de una fuente común. Si cada pieza mantiene su propia lista de idiomas, tarde o temprano una versión aparecerá en un sitio y desaparecerá en otro. Publicar italiano significa afirmar que navegación, reglas, datos dinámicos, SEO y accesibilidad están preparados para un recorrido real.
La experiencia debe conservar el idioma durante todo el recorrido
Una home italiana perfectamente traducida no basta si al abrir una categoría se vuelve al español, si las estadísticas recuperan nombres desde un catálogo base o si el selector devuelve siempre a la portada. El QA útil sigue viajes completos: entrar por una ruta localizada, descubrir un juego, abrirlo, consultar ayuda, mirar estadísticas, cambiar de idioma y volver. Cada transición es una oportunidad de perder contexto; la localización pertenece al grafo de navegación.
La detección automática debería ser una ayuda inicial, no una orden permanente
El idioma del navegador sirve como pista cuando la persona todavía no ha expresado una preferencia. Después de una elección manual, seguir imponiendo detección automática hace que el selector parezca inútil. El sistema necesita distinguir entre “lo que sugerimos al principio” y “lo que el usuario eligió”. Esa preferencia puede compartirse entre superficies mientras cada aplicación resuelve sus propias convenciones de ruta.
Una URL localizada tiene que ser reproducible al compartirla
Cuando alguien copia un enlace italiano y otra persona lo abre desde un navegador configurado en francés, la URL debería seguir representando la versión italiana solicitada. Depender por completo de negociación implícita convierte el lenguaje en algo que cambia al transportar un enlace. Las rutas localizadas hacen visible la representación pedida y permiten reproducir exactamente una incidencia reportada.
La caché puede fabricar errores que parecen de traducción
Un despliegue multilingüe no termina cuando el HTML se genera. Si la caché entrega una página nueva junto a scripts o catálogos de una versión anterior, el usuario puede ver un selector actualizado que usa lógica vieja o nombres españoles dentro de una superficie francesa. Versionado, invalidación y revalidación son parte del contrato de i18n aunque no aparezcan en ningún diccionario.
Los datos dinámicos obligan a seguir el texto hasta su origen
Traducir componentes visibles puede crear una falsa sensación de cobertura. Una tarjeta de estadísticas puede tener encabezados correctos y mostrar el título de un juego en español porque ese valor procede de un catálogo generado solo en el idioma base. La solución es separar identidad y presentación: IDs estables debajo, nombres y categorías localizadas encima. Esa arquitectura se desarrolla en cómo internacionalizamos Blupoli Puzzles.
Las pistas generadas deben existir como significado antes que como frase
Los puzzles que generan texto en tiempo de ejecución son una prueba especialmente dura. Si el motor produce directamente una oración española, otra capa tiene que intentar recuperar el significado para traducirla. Es más seguro que el dominio produzca una relación estructurada y que el locale decida cómo expresarla. El motor del Acertijo de Einstein muestra este principio con claridad.
Reglas, consentimiento y accesibilidad son dominios de alto riesgo
No todas las cadenas merecen el mismo tratamiento. Una frase promocional algo rígida es un problema editorial. Una regla ambigua puede cambiar el juego. Un aria-label incorrecto puede volver inaccesible un control. Un texto de consentimiento mal traducido puede impedir entender una elección de privacidad. Agrupar todo bajo un único porcentaje de cobertura oculta estas diferencias; la calidad se decide por impacto.
Los fallbacks editoriales tienen que ser explícitos y honestos
El soporte de un locale a nivel de producto no obliga a que todo el archivo histórico del Blog esté traducido de inmediato. Crear una ruta alemana con contenido español solo para completar una matriz produce una paridad ficticia. Es mejor enlazar al original, indicar el idioma real y publicar la versión localizada cuando exista de verdad. La honestidad de cobertura es una propiedad editorial y también SEO.
Hreflang y sitemap deben describir lo que existe
Hreflang no es una lista de idiomas deseados; describe equivalentes reales. El sitemap tampoco debería anunciar una ruta localizada incompleta porque un directorio esté presente en el repositorio. Ambas señales deben derivar del estado público y de la existencia de contenido genuino. Así SEO deja de mantener una verdad paralela y pasa a expresar el mismo contrato que navegación.
La accesibilidad amplía la superficie que el gate debe recordar
Alt text, aria-labels, mensajes anunciados por lectores de pantalla y nombres de controles pueden quedar invisibles durante una revisión visual, pero siguen siendo lenguaje. Una versión francesa con interfaz visible en francés y etiquetas accesibles en español está solo parcialmente localizada. Los checks automáticos pueden detectar ausencias; la revisión humana debe juzgar naturalidad y significado.
La observabilidad necesita conservar contexto de locale
Un error que ocurre únicamente en una ruta portuguesa puede parecer intermitente si la telemetría técnica no registra el locale. Conservar ese contexto junto a la ruta, versión y superficie permite reproducir problemas sin recopilar información personal innecesaria. La internacionalización pasa así a formar parte del debugging y permite distinguir una regresión global de un problema localizado.
Rollback y publicación deben ser operaciones reversibles
Que una traducción exista en el repositorio no obliga a mantenerla anunciada públicamente si aparece un problema serio. Separar existencia de publicación permite retirar un locale del selector y de ciertas señales mientras el trabajo permanece disponible para corregirse. Candidato y publicado son estados operativos que pueden cambiar cuando cambia la evidencia.
La suite debe combinar cobertura estructural con journeys representativos
No hace falta ejecutar cada test seis veces para obtener valor. Los checks estructurales pueden verificar claves, rutas y catálogos para todos los locales, mientras unos pocos recorridos completos ejercitan las zonas donde la composición suele fallar: cambio de idioma, textos largos, datos dinámicos, fallbacks y navegación contextual. Los bugs históricos deberían conservarse como regresiones.
El glosario y la documentación convierten decisiones en memoria
Términos como región, pista, borde, candidato, bucle o adyacente aparecen en reglas, onboarding y artículos. Resolver cada traducción desde cero crea deriva. Un glosario compartido ayuda a humanos y agentes, pero necesita ownership y capacidad de evolucionar. Las incidencias encontradas también deben convertirse en documentación y checks para que el séptimo idioma no dependa de memoria informal.
La UI compartida reduce lugares donde la política puede divergir
Una cabecera, selector o control de preferencia común no traduce el producto, pero evita reimplementar la misma política en varias superficies. El trabajo de UI compartida gana valor cuando locale, navegación y persistencia forman parte del contrato. Las diferencias reales se parametrizan; las accidentales dejan de multiplicarse.
El onboarding necesita revisión semántica, no solo lingüística
Un tutorial puede tener todos sus botones traducidos y explicar mal la mecánica. La escena, la acción y la frase tienen que coincidir. El sistema de onboarding por perfiles ayuda porque separa comportamiento compartido de contenido específico, localizable y verificable. El objetivo es enseñar la misma regla de manera natural, no producir frases equivalentes palabra por palabra.
Este artículo debe conservar el estado histórico correcto
Actualizar la marca a Blupoli no debe borrar que el 14 de septiembre de 2026 italiano, portugués, francés y alemán seguían siendo candidatos. Presentarlos como ya publicados haría que el archivo dejara de explicar la secuencia real. La entrada De candidatos a publicados cuenta precisamente el momento posterior.
La meta real era hacer que el séptimo idioma dejara de ser una aventura
Preparar cuatro candidatos tenía valor inmediato, pero el resultado más importante era convertir la expansión lingüística en un proceso repetible. Otra lengua seguiría necesitando traducción, revisión y QA. Lo que ya no debería exigir es inventar de nuevo rutas, SEO, catálogos, fallbacks y criterios de publicación. Una plataforma multilingüe madura puede explicar qué significa estar lista y demostrarlo.
El orden del build es parte del contrato de localización
El fallo del selector sobrescrito dejó una lección que va más allá de un bug concreto: varios scripts correctos pueden producir un resultado incorrecto si se ejecutan en el orden equivocado. Una fase editorial que reescribe HTML después de inyectar navegación puede eliminar controles, metadatos o atributos de accesibilidad sin que ninguna etapa individual “falle”. Por eso cada transformación necesita responsabilidades claras: qué puede modificar, qué debe preservar y qué invariantes se revisan al final. El pipeline deja de ser una secuencia accidental y se convierte en una composición auditable.
Los formatos regionales deben aplicarse cerca de la presentación
Fechas, números, porcentajes y plurales comparten significado aunque su forma visible cambie por locale. Guardar una fecha ya formateada en español y transformarla más tarde mezcla dominio y presentación, además de hacer frágiles los validadores. Es más seguro conservar un valor estable y aplicar formato localizado al renderizar. Así una mejora de estilo no altera identidad ni cronología. El mismo principio evita que una corrección de puntuación o pluralización rompa tests que en realidad intentaban comprobar otra propiedad del contenido.
Los assets también necesitan una política lingüística
No todo recurso visual debe duplicarse por idioma. Un diagrama semántico sin texto incrustado puede compartirse sin pérdida; una captura con instrucciones o una ilustración con copy necesita otra estrategia. Duplicar todo aumenta peso y mantenimiento. Compartir todo produce páginas visualmente bilingües. La decisión correcta depende de si el asset contiene significado lingüístico. Cuando es posible, preferimos gráficos sin texto embebido y dejamos alt, caption y explicación alrededor en cada idioma, porque esa combinación maximiza reutilización y accesibilidad sin sacrificar claridad.
Los títulos de documento, avisos y notificaciones también cuentan
Una página puede parecer completamente localizada y seguir mostrando el título de la pestaña, un mensaje de confirmación o una notificación en el idioma base. Son superficies pequeñas pero muy visibles porque aparecen justo cuando la persona cambia de contexto. La readiness de un locale debe contemplarlas cuando formen parte del producto. La regla práctica es sencilla: si el usuario puede leerlo, pertenece al sistema de i18n, aunque no viva dentro del componente principal ni aparezca en una captura habitual de QA.
La búsqueda localizada necesita vocabulario real, no solo títulos oficiales
Traducir el nombre canónico de un puzzle no garantiza que alguien lo encuentre. Algunos juegos tienen denominaciones alternativas, términos tradicionales o formas descriptivas que cambian por idioma. El índice puede incorporar sinónimos localizados manteniendo un único ID estable para el juego. Así búsqueda, estadísticas y partidas guardadas siguen hablando de la misma entidad mientras cada locale permite descubrirla con vocabulario natural. La internacionalización madura no consiste únicamente en reemplazar cadenas; también entiende cómo las personas nombran el mismo concepto.
La revisión humana debe centrarse en errores que parecen correctos
Los fallos obvios suelen detectarse rápido. Los peligrosos son traducciones gramaticalmente fluidas que alteran una restricción, usan un término plausible pero incorrecto o borran una diferencia entre “exactamente” y “al menos”. Por eso las reglas merecen revisión contra el comportamiento real del juego, no solo contra otro texto. No todas las cadenas necesitan el mismo nivel de escrutinio: el enfoque útil es identificar dónde una pequeña desviación puede cambiar la mecánica y dedicar ahí más atención editorial.
La activación secuencial reduce el coste de aprender del primer release
Italiano era el primer candidato de la secuencia histórica porque necesitábamos un recorrido completo que ejercitara todo el pipeline. Si ese primer release descubría un problema de canonical, catálogo dinámico, caché o navegación contextual, corregirlo antes de activar portugués, francés y alemán reducía el radio de impacto. Publicar en serie convierte una migración grande en varios releases controlados con criterios comunes. No establece una jerarquía entre idiomas; establece una estrategia de riesgo que permite aprender una vez antes de repetir.
La checklist final debe medir el producto, no la sensación de avance
“Está casi todo traducido” no es un criterio de publicación. Una checklist útil hace visible el contrato completo: estructura, revisión semántica, build final, rutas, canonical, hreflang, sitemap, mobile, accesibilidad, datos dinámicos, selector, errores y fallbacks. Algunas comprobaciones son automáticas y otras requieren juicio. Lo importante es que el conjunto pueda explicarse y repetirse. Así la decisión de publicar un locale deja de depender de impresiones o presión por terminar y pasa a apoyarse en evidencias verificables.
Los candidatos permiten decir “todavía no” con precisión
La infraestructura de i18n no solo sirve para publicar más rápido. También sirve para detener una publicación de forma concreta. Si una regla sigue en revisión, si un recorrido pierde locale o si un alternate apunta a una ruta inexistente, el estado candidato expresa que la versión está disponible para evaluación pero aún no merece convertirse en promesa pública. Esta capacidad se vuelve más importante cuando la IA acelera la producción: generar mucho más rápido solo es una ventaja si podemos bloquear con la misma claridad lo que todavía no cumple el contrato.
La documentación convierte incidencias en memoria operativa
El checker que ignoraba candidatos, el selector sobrescrito y los datos dinámicos en español no deberían quedar como anécdotas. Cada incidencia útil debe transformarse en una regla, una prueba o una nota de arquitectura que el siguiente cambio pueda consultar. Esto reduce dependencia de memoria personal y hace que humanos y agentes compartan el mismo contexto. Una plataforma madura no solo reutiliza código; reutiliza también las decisiones que explican por qué el código y los gates existen.
La historia del producto mejora cuando conserva sus estados intermedios
Este artículo tiene valor precisamente porque documenta el momento anterior a la publicación de los seis idiomas. Reescribirlo como si todo estuviera ya resuelto borraría la evidencia de por qué los candidatos y gates fueron necesarios. Mantener la cronología permite leer De candidatos a publicados como una consecuencia y no como un salto mágico. El archivo editorial es más útil cuando conserva los estados incómodos que explican cómo se alcanzó el resultado.
El objetivo profundo era hacer que el séptimo idioma dejara de ser una aventura
Preparar cuatro candidatos tenía valor inmediato, pero el resultado más importante era convertir la expansión lingüística en un proceso conocido. Otra lengua seguiría necesitando traducción, revisión y QA. Lo que ya no debería exigir es inventar de nuevo rutas, SEO, catálogos, assets, fallbacks y criterios de publicación. Una plataforma multilingüe madura no es la que acumula más carpetas; es la que puede explicar qué significa estar lista, demostrarlo de extremo a extremo y repetir el camino sin rebajar la calidad.