Arquitectura multilingüe i18n — Explicación de alcance

Qué significa y por qué importa

Qué incluye SessDev

• Ruteo con prefijo de locale (p. ej. /en/* y /es/*) con un locale por defecto configurado y una política de redirect determinista para la raíz.
• Catálogos de mensajes por locale (un archivo JSON por idioma) estructurados para que un traductor edite un solo archivo sin tocar código.
• Componente selector de idioma cableado para preservar la ruta actual del usuario al cambiar de locale.
• Enlaces hreflang alternate emitidos en cada página localizada, incluido x-default apuntando al locale por defecto configurado.
• Title, description y metadatos Open Graph localizados por locale a través del mismo pipeline de archivos de mensajes.
• Política de fallback documentada para claves faltantes: qué locale sirve como fallback, y si una clave faltante rompe el build o queda en log en runtime.
• Verificación en build de que cada clave presente en el locale por defecto existe en todos los demás locales acordados; las claves faltantes rompen el build, no producción.
• Soporte para ICU MessageFormat: variables, plurales y formato rich-text básico, para que los traductores no tengan que duplicar strings por número o género.
• 1 walkthrough grabado para el equipo o el traductor cubriendo cómo editar archivos de mensajes, añadir una clave nueva y verificar una traducción antes de publicar.

Qué queda excluido

• Traducción de strings de UI o copy de páginas a cualquier idioma; el cliente provee el texto traducido por locale.
• Copywriting localizado, reescritura de titulares o adaptación de propuesta de valor por mercado.
• Adaptación cultural, reescrituras idiomáticas o ajuste de brand voice por región.
• Gestión de glosario, bases terminológicas, memorias de traducción o integraciones con TMS de vendor específicos.
• Locales más allá del set acordado en scope. Añadir un idioma nuevo post-launch es un cambio scoped separado.
• Pipelines de traducción automática (DeepL, Google Translate, basados en LLM) integrados en build o runtime.
• Estrategia de SEO por región (es-MX vs es-ES, en-US vs en-GB, keyword research regional).
• Conversión de moneda, display de precios regional, formato con impuestos incluidos o tablas de precios por mercado.
• Texto legal localizado por jurisdicción; el cliente provee el copy legal para cada locale, validado por su asesoría.
• Cumplimiento regulatorio por mercado (variantes de ley de cookies, estándares de accesibilidad más allá de WCAG AA, obligaciones de residencia de datos).
• Operaciones editoriales continuas: scheduling, revisión o corrección de traducciones después del handoff.

Riesgos si no se define correctamente

• Errores de clave faltante en runtime

  Si un traductor añade una clave nueva en un locale y olvida los demás, la página puede crashear en runtime con MISSING_MESSAGE. La validación en build captura esto en CI, pero solo si el paso de validación se mantiene activo.

• Drift entre locales

  Cuando un idioma se actualiza más rápido que los demás, el sitio queda con copy desactualizado en los locales rezagados de manera silenciosa. Los usuarios de esos mercados leen información vieja; el equipo rara vez lo nota hasta que un cliente se queja.

• Mismatch de hreflang

  Si hreflang apunta a URLs que dan 404 en el otro locale, Google ignora el cluster entero. El sitio aparenta perder visibilidad internacional sin razón obvia; la causa es una ruta traducida faltante.

• Overflow de longitud en UI

  Alemán, finés y muchas formulaciones en español latinoamericano son 30–60% más largas que el inglés. Los botones wrappean, los menús desbordan, el copy del hero rompe la grid. Diseños validados solo en inglés llegan a otros locales visualmente rotos.

• Mala configuración de fallback

  Una cadena de fallback mal configurada puede servir el idioma equivocado, hacer loop entre locales o renderizar strings vacíos. El usuario ve una página incompleta; analytics registra la visita como bounce.

• Divergencia legal entre idiomas

  Si la página legal en inglés se actualiza y la española no, el cliente queda obligado por términos distintos en distintos idiomas. Esto es exposición legal real, no un bug de UX.

• Scope bleed de locales

  'Solo añadir alemán' después del launch suena pequeño; duplica QA, multiplica el coste de traducción, expande la superficie de SEO y fuerza re-auditar cada página. Añadir locales debe ser un cambio scoped, no una petición ad-hoc.

Ítems de alcance relacionados

• content_injectionLos strings traducidos provistos por el cliente se inyectan a través del mismo pipeline de archivos de mensajes.
• cms_blog_setupEl schema del CMS puede modelarse como multilingüe, pero la traducción de los posts queda excluida igual que la traducción de UI.
• technical_seohreflang, canonical localizado y sitemaps por locale se coordinan con la capa de SEO técnico.
• legal_pages_setupLas páginas legales soportan múltiples locales estructuralmente, pero el copy legal por idioma lo provee el cliente, validado por su asesoría.
• analytics_integrationAnalytics segmenta por locale para comparar tráfico y conversión entre idiomas.
• media_infrastructureEl media localizado (imágenes específicas por región, assets localizados) es soportado por el pipeline de medios pero no es producido por SessDev.

Preguntas frecuentes

¿Qué idiomas se incluyen por defecto?

Los locales acordados en scope. SessDev no pre-empaqueta una lista de idiomas por defecto; el set se fija antes de implementación y se congela en el build.

¿Podemos añadir otro idioma después del launch?

Sí, como un cambio scoped separado. Añadir un locale requiere actualizar ruteo, reconciliar hreflang, migrar archivos de mensajes, QA por página y re-validación de SEO — nada de esto está en el alcance original.

¿SessDev traduce el contenido?

No. SessDev integra los strings traducidos provistos por el cliente. Contratar traductores, ejecutar ciclos de revisión y mantener un glosario es responsabilidad del cliente o de una agencia de traducción asociada.

¿Podemos cablear traducción automática (DeepL, Google, un LLM)?

Fuera de alcance por defecto. SessDev puede scoparlo como integración separada, pero los riesgos de calidad, legales y de marca del output automático sin revisar quedan con el cliente.

¿Qué pasa si falta una traducción al hacer deploy?

La validación en build marca las claves faltantes y rompe CI antes de que el build defectuoso llegue a producción. La política por defecto es fail-the-build; optar por fallback en runtime es una decisión documentada del cliente.