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 76 juegos 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.
Publicar seis idiomas no obliga a fingir que cada pieza editorial ya existe seis veces.
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.