Una fuente, varios idiomas, la misma ruta
La internacionalización suele parecer una tarea que se hace al final: extraer cadenas, traducirlas y añadir un selector. Esa estrategia es cómoda mientras el producto es pequeño. En PuzzleHub, con más de setenta juegos y un Journal que también está creciendo, esperar significaría multiplicar la migración.
Por eso hemos decidido tratar los idiomas como una restricción arquitectónica desde ahora. El objetivo no es «tener una versión inglesa». Es poder añadir idiomas sin crear copias divergentes de PuzzleHub.
El problema apareció al crecer
Mientras PuzzleHub era pequeño, mantener textos directamente en las páginas parecía razonable. Con fichas de juegos, taxonomía, blog, navegación, estadísticas y experiencias específicas dejó de serlo. Cada texto duplicado es una futura inconsistencia.
Una cadena hardcodeada no duele hoy. Duele cuando existe en setenta páginas, cuatro idiomas y una persona intenta cambiar la terminología de una categoría.
La traducción multiplica el contenido; una buena arquitectura evita que multiplique también la lógica.
Una fuente de verdad para cada cosa
Los juegos siguen definidos por sus datos y motores. El idioma modifica cómo los presentamos, no cómo funcionan. Lo mismo ocurre con categorías: su identidad interna debe permanecer aunque el usuario lea otro nombre o descripción.
Esta separación reduce errores y también simplifica estadísticas, favoritos o partidas guardadas. Un Sudoku no debería convertirse en otra entidad porque el usuario cambie de español a inglés.
No todo texto es el mismo tipo de texto
Una etiqueta como «Nueva partida» puede vivir en un diccionario de interfaz. Una descripción de categoría necesita más contexto. Un artículo del Journal es contenido editorial completo. Intentar gestionar los tres con exactamente el mismo mecanismo suele producir un sistema incómodo.
También el blog tiene que hablar varios idiomas
El Journal añade título, descripción SEO, navegación, enlaces internos y texto largo con tono propio. Traducir literalmente no siempre será suficiente: una buena versión debe seguir sonando como un artículo, no como una tabla de cadenas.
Además, cuando actualizamos el original necesitamos saber si las versiones localizadas requieren revisión. La internacionalización editorial es un flujo continuo, no una exportación única.
SEO internacional desde el principio
Una versión traducida no sirve de mucho si los buscadores no entienden su relación con el original. La arquitectura debe contemplar URLs localizadas, canonicals adecuados, metadatos y enlaces entre idiomas.
Cada idioma debe ser una puerta de entrada real, con navegación coherente y contenido rastreable. Una capa que cambia texto con JavaScript pero mantiene todas las señales SEO ambiguas no cumple ese objetivo.
- una URL estable y predecible;
- título y descripción propios;
- relación clara con versiones equivalentes;
- enlaces internos dentro del idioma correcto;
- fallbacks que no oculten contenido faltante.
El selector de idioma es la parte visible más pequeña
La interfaz para cambiar idioma importa, pero es casi el final del problema. Antes necesitamos resolver persistencia de preferencia, detección inicial, navegación, rutas y qué ocurre cuando una página todavía no está traducida.
Un buen fallback debe mantener el producto utilizable sin crear enlaces rotos ni dar la impresión de que existe una traducción completa cuando no es así.
Los juegos tienen un reto extra: lenguaje dentro del motor
Algunos puzzles apenas necesitan texto durante la partida. Otros, como el Acertijo de Einstein, generan pistas en lenguaje natural. Ahí la separación entre regla y frase se vuelve fundamental.
Una relación «A está junto a B» debería existir como estructura de datos y renderizarse después según el idioma. Si la lógica genera directamente una frase española, internacionalizarla obliga a tocar el motor.
Por qué merece la pena hacerlo ahora
Posponerlo sería más cómodo unas semanas y mucho más caro después. Cada nuevo juego, categoría y artículo aumentaría el volumen a migrar. Hacerlo mientras consolidamos componentes y catálogo permite que lo nuevo nazca preparado.
Además, la internacionalización funciona como prueba de arquitectura igual que el modo claro: descubre texto acoplado, rutas rígidas y datos que mezclan identidad con presentación.
Calidad antes que cobertura ficticia
No queremos mostrar un selector con muchos idiomas si la mitad de la experiencia vuelve constantemente al español. Es mejor ampliar cobertura de forma medible y saber qué áreas faltan.
Eso requiere QA específico: navegación, textos que desbordan componentes, plurales, metadatos, contenido generado y coherencia terminológica.
El siguiente reto es convertirlo en hábito
La infraestructura es solo el principio. Después llega la parte difícil: conseguir que una nueva función no nazca únicamente en el idioma principal, que las traducciones evolucionen con el producto y que el Journal mantenga calidad editorial.
Internacionalizar no es completar una tarea; es añadir una restricción permanente y saludable. Nos obliga a separar mejor datos y presentación, a pensar las URLs como producto y a escribir componentes menos dependientes de una frase concreta.
Si lo hacemos bien, añadir un idioma no significará crear otra PuzzleHub. Significará abrir otra puerta a la misma plataforma.