Las SPA complicaron innecesariamente el i18n

13 min de lectura

La internacionalización llega antes de lo que esperan los equipos

El primer error suele ser de gestión, no técnico.

Los equipos tratan el i18n como un problema de escala para más adelante, incluso cuando el mercado deja clara la necesidad desde el principio. Funciona hasta que el producto necesita un segundo idioma y alguien descubre que los textos, el enrutamiento, los metadatos, los flujos de soporte y la responsabilidad sobre el contenido se diseñaron como si el inglés fuera a seguir siendo el valor por defecto para siempre.

Para un CTO, esto no es ante todo una discusión sobre estilo frontend. Es una discusión sobre capacidad de entrega. Si el soporte multilingüe es una necesidad normal del negocio, la pregunta correcta no es «¿qué framework parece moderno?». Es «¿qué modelo de aplicación mantiene esta necesidad lo bastante aburrida como para entregarla y mantenerla?».

Por qué el i18n deja de ser opcional tan rápido

Europa es el ejemplo evidente. La UE tiene 24 lenguas oficiales y la Comisión Europea dice que sus sitios de europa.eu están disponibles en general en las 24. Los usuarios multilingües son normales en el software empresarial europeo: cambian entre el idioma local, el inglés y, a veces, el de un mercado vecino sin considerarlo excepcional. Una empresa alemana puede vender en España, contratar en Polonia, informar a una matriz neerlandesa y llevar las reuniones con proveedores en inglés. El producto puede ser local; el flujo de trabajo rara vez lo es. Política multilingüe de la UE, uso de idiomas de la Comisión.

Estados Unidos es distinto, pero no tan simple como se pretende. Los datos que el Census Bureau publicó el 3 de junio de 2025 indican que el 22 % de las personas de cinco años o más hablaba en casa una lengua distinta del inglés en el periodo 2017-2021. Muchas aplicaciones de negocio estadounidenses sobreviven con el inglés primero porque sus compradores y usuarios de oficina suelen tener fluidez suficiente y la fricción lingüística no bloquea la venta el primer día. Es un atajo de mercado, no una verdad técnica. Publicación del U.S. Census.

Luego está el espacio empresarial postsoviético, donde el cuadro vuelve a torcerse. Las lenguas estatales locales importan, pero el ruso sigue funcionando como lingua franca comercial en buena parte de la región. Una investigación destacada por la University of Colorado describe el ruso como una «significant commercial lingua franca» en países postsoviéticos. Resumen de la investigación.

El punto no es la sociolingüística por sí misma.

El punto es que muchas empresas operan en mercados donde el soporte de idiomas llega pronto y se queda. Si esa necesidad es previsible, la arquitectura debe tratarla como algo normal en vez de fingir que se puede pegar después, cuando el modelo de producto ya se ha endurecido.

Por qué las SPA parecían inteligentes al principio

El discurso de venta era seductor porque respondía a una frustración real.

Las recargas de página parecían torpes. Las aplicaciones móviles parecían más fluidas. Los motores de JavaScript se hicieron más rápidos. Los frameworks prometían una única carcasa de aplicación, transiciones inmediatas, componentes reutilizables y una experiencia de usuario que se parecía más al software y menos a un montón de documentos enlazados.

Esa parte resultaba emocionalmente convincente y, a veces, de verdad útil.

Durante un tiempo, muchos equipos concluyeron que el modelo de documentos del navegador era el viejo mundo y la SPA, el futuro. Si la página seguía viva y el cliente coordinaba todo, todo parecería más rápido, más rico y más moderno.

Entonces aparecieron necesidades de negocio normales.

El propio glosario de SPA de MDN es menos romántico que el circuito de conferencias. Define una SPA como un único documento actualizado mediante JavaScript y expone las contrapartidas: problemas de SEO, más esfuerzo para mantener el estado, implementar la navegación y hacer una monitorización del rendimiento que signifique algo. Y eso antes de que legal, finanzas o soporte al cliente pidan que alemán, español e inglés se comporten de forma coherente en el mismo flujo. Incluso MDN reconoce la contrapartida.

Ese es el primer hecho útil.

El segundo es más desagradable.

El i18n no es difícil en las SPA porque los desarrolladores sean tontos. Es difícil porque la SPA trasladó a código de aplicación responsabilidades que el navegador resolvía a nivel de documento. El soporte de idiomas cae directamente sobre esa decisión.

Por qué el trato de las SPA se vuelve en contra del i18n

Los navegadores ya saben hacer muchas cosas que la cultura de las SPA pasó una década fingiendo que eran demasiado primitivas:

• seguir enlaces
• conservar el historial
• enviar formularios
• renderizar documentos
• almacenar recursos en caché
• instalar aplicaciones
• funcionar sin conexión cuando se diseñan para ello

La History API lleva ampliamente disponible desde julio de 2015. Las PWA amplían la misma plataforma con instalación, capacidad sin conexión e integración con el dispositivo donde el navegador lo permite. No es una plataforma de juguete.

Así que cuando alguien dice que la SPA era necesaria porque «los usuarios esperan comportamiento de aplicación», la respuesta evidente es: sí, y la plataforma web aprendió esa lección hace años.

El navegador creció.

La industria frontend siguió facturando como si no lo hubiera hecho.

El navegador es más capaz de lo que admite el hábito de los frameworks. Gran parte de lo que muchos equipos todavía llaman desarrollo web moderno es solo una forma complicada de evitar confiar en la plataforma.

El resultado es predecible. En cuanto un producto necesita varios idiomas, la SPA debe coordinar semántica de rutas, detección de idioma, carga de textos, comportamiento de respaldo, metadatos y supervivencia del estado en una aplicación de cliente que nunca deja de ejecutarse. Lo que antes era entrega de documentos se convierte en coreografía de ejecución.

La documentación de los frameworks lo admite de formas distintas.

Angular proporciona una canalización completa para extraer y generar compilaciones localizadas. React suele entregarte un ecosistema de backends, detectores de idioma, espacios de nombres y comportamiento de carga. Vue añade una capa dedicada de i18n con su propia carga de migración. Next.js ayuda con el enrutamiento internacionalizado y después dice explícitamente que ese soporte complementa bibliotecas de i18n externas, no las sustituye. Los frameworks no esconden la complejidad. La documentan.

Los frameworks se delatan solos

Angular merece reconocimiento porque no finge que el i18n aparece espolvoreando polvo de hadas sobre los componentes.

Su documentación oficial te dice que añadas @angular/localize, marques cadenas con atributos i18n o $localize, ejecutes ng extract-i18n, copies el archivo de idioma de origen a archivos de traducción por idioma, traduzcas plurales y expresiones alternativas y uses la opción de compilación localize para generar una variante completa de la aplicación por configuración regional. También enumera los formatos de intercambio compatibles: XLIFF, XLIFF 2, XMB, JSON y ARB. Visión general de i18n de Angular, añadir el paquete, archivos de traducción, fusionar variantes localizadas.

Eso no es una crítica a Angular.

Angular está siendo honesto.

Si toda tu interfaz vive dentro de una aplicación de cliente que no deja de ejecutarse, la localización se convierte en una canalización de compilación, una de extracción, un ciclo de vida de archivos de traducción y un problema de despliegue. Angular no inventó esa carga. Solo la documentó con suficiente claridad para que nadie pueda fingir que es gratis.

Lo más amable que se puede decir de su modelo es que centraliza el dolor.

Lo menos amable es que el dolor sigue ahí.

Y recuerda: Angular es el framework que sí tiene soporte incorporado. Los demás prueban el mismo punto con otras decisiones de herramientas. La respuesta habitual de React es react-i18next, con carga de backend, detección de idioma del navegador, manejo de idioma de respaldo y comportamiento de carga que puede activar Suspense mientras las traducciones todavía llegan. Configuración oficial de instancia, comportamiento oficial del hook. Vue usa una capa vue-i18n dedicada y sigue arrastrando presión de migración desde la API heredada hacia la Composition API. Empezar con Vue I18n, Composition API, cambios incompatibles de v11. Next.js mejora las rutas, pero su documentación del Pages Router dice de forma explícita que el soporte de rutas i18n complementa bibliotecas existentes en lugar de reemplazarlas. i18n del Pages Router, i18n del App Router.

El impuesto oculto no es solo la traducción

La trampa es creer que i18n significa «poner cadenas en archivos».

Nunca fue toda la historia, y la arquitectura SPA agranda la historia que hay alrededor:

• Las URL necesitan semántica de idioma.
• Los enlaces profundos deben conservar el idioma.
• El historial del navegador no debe comportarse de forma extraña al cambiar de idioma.
• Los metadatos deben reflejar el idioma actual.
• Los estados de carga no deben mostrar brevemente el idioma equivocado.
• Los estados de error no deben volver al inglés por accidente.
• Los números, las fechas y los plurales necesitan tratamiento consciente de la configuración regional.
• Los motores de búsqueda y las vistas previas sociales deben asociar el idioma correcto con la ruta correcta.
• El contenido y la estructura de componentes deben sobrevivir a la expansión de las traducciones sin romper el diseño.

El último punto es donde la cultura frontend merece una bofetada.

Si tu sistema de diseño no tolera que el alemán sea más largo que el inglés, el problema no es la calidad de la traducción. El problema es que el sistema se construyó para una captura de pantalla, no para un idioma.

Pero el argumento amplio se mantiene: una aplicación centrada en documentos puede dejar que el servidor devuelva el idioma correcto como documento completo. Una SPA tiende a convertir el idioma en otro subsistema reactivo que puede cargar tarde, fallar de forma rara o exigir ceremonia de Suspense antes de que el usuario siquiera vea la página correctamente.

Eso no es progreso.

Es alquiler de framework.

Una alternativa mejor para CTOs

La alternativa no es volver a una maraña de plantillas de servidor copiadas y pegadas sin interfaz reutilizable.

La opción más tranquila es esta:

• mantener los límites de idioma en el nivel del documento y de la ruta
• dejar que el servidor entregue el idioma correcto como página completa
• usar mejora progresiva cuando una interacción más rica aporte valor
• usar componentes web para elementos de interfaz reutilizables sin convertir toda la aplicación en una ejecución permanente en el cliente

Ese modelo es más fácil de explicar hacia arriba porque alinea la responsabilidad con la necesidad de negocio. Una URL de idioma concreto devuelve un documento de idioma concreto. Un elemento de interfaz reutilizable sigue siéndolo sin obligar a toda la aplicación a adoptar comportamiento SPA. Sigues teniendo componentes. Sigues teniendo capacidades modernas del navegador. Simplemente dejas de pagar el impuesto arquitectónico completo de la SPA cuando el producto no lo necesita.

Para un CTO importa porque reduce piezas móviles justo donde suelen volverse políticas. El soporte multilingüe debería ser una cuestión de contenido y flujo de trabajo, con cierta disciplina técnica alrededor. No debería convertirse en una negociación frágil entre estrategia de rutas, paquetes de traducción, estado de ejecución y las bibliotecas frontend que estén de moda este año.

HTML5 más PWA cubre más de lo que admiten los fans de las SPA

La documentación de PWA de MDN describe el alcance sin rodeos: una PWA puede compartir una base de código entre plataformas y, cuando lo admiten navegador y dispositivo, instalarse, trabajar sin conexión o en segundo plano e integrarse con el dispositivo. La lista actual de web.dev dice que una buena PWA funciona en cualquier navegador, se adapta a cualquier pantalla, ofrece comportamiento sin conexión y es instalable. Resumen de PWA de MDN, lista de PWA de web.dev.

Eso es la mayor parte de lo que suelen querer decir los responsables de negocio cuando dicen «necesitamos comportamiento de aplicación».

Rara vez quieren decir:

• reimplementación de rutas en el cliente
• orquestación de paquetes de traducción
• desajustes de hidratación
• un plugin de localización cuya API heredada está desapareciendo
• Suspense porque la etiqueta de un botón todavía no ha cargado

Quieren decir:

• la página debe ser rápida
• el flujo debe sobrevivir a una mala conexión
• la aplicación debe poder instalarse si resulta útil
• la interfaz debe responder bien
• el idioma debe ser correcto
• los enlaces deben funcionar
• los usuarios no deben perderse

Esos son requisitos web.

No requisitos de SPA.

La industria confundió ambos durante años porque la SPA parecía modernidad y el navegador, la fontanería de ayer.

Ahora el navegador hace la mayor parte del trabajo respetable y los equipos siguen arrastrando deuda de framework como si fuera una reliquia familiar.

Los componentes web encajan bien porque preservan lo útil de pensar en componentes sin exigir todo el trato de las SPA. Un selector de fecha, una tarjeta de precios, un panel de estado de flujo o un widget de cuenta localizado puede ser un componente. Toda la aplicación de negocio no tiene que convertirse en un enorme tiempo de ejecución en el cliente porque algunas partes sean interactivas.

Cuándo una SPA está realmente justificada

Esta es la parte en la que la objeción habitual merece una respuesta justa.

Algunas aplicaciones sí quieren un tiempo de ejecución pesado en el cliente:

• herramientas locales muy interactivas
• editores colaborativos
• software rico de modelado visual
• comportamiento complejo sin conexión con mucho estado local
• casos en los que una pestaña del navegador se parece de verdad más a una herramienta de estación de trabajo que a un flujo de documentos

Bien. Construye la aplicación que de verdad necesitas.

Pero sé honesto sobre lo que has comprado.

Has comprado una superficie frontend mayor. Has comprado orquestación de estado. Has comprado lógica de rutas. Has comprado i18n como arquitectura de ejecución. Has comprado más oportunidades para desajustes de carga, más coordinación de bibliotecas, más migraciones y más trabajo para mantener alineadas las URL, los metadatos, la accesibilidad y las traducciones.

Aun así puede ser el intercambio correcto.

Simplemente no es el intercambio correcto por defecto para una aplicación web empresarial multilingüe con formularios, listas, vistas de detalle, aprobaciones, facturas y paneles.

Esos sistemas suelen ser documentos con flujo de trabajo, no sistemas operativos en miniatura.

Trátalos así y la historia multilingüe recupera la cordura de inmediato.

Deja de resolver el problema equivocado

Las SPA se vendieron a menudo como la respuesta inevitable a las «aplicaciones web modernas».

Esa afirmación ha envejecido mal.

La plataforma web se hizo más fuerte. Las capacidades PWA maduraron. Los navegadores estandarizaron más comportamiento útil. El mundo de los frameworks ha vuelto a la renderización en servidor, la conciencia de rutas y la ejecución selectiva en el cliente porque el sueño de todo en el cliente empeoraba demasiados problemas ordinarios.

El i18n es una de las pruebas más claras.

La factura multilingüe revela si la arquitectura sirve al producto o si el producto sirve silenciosamente a la arquitectura.

Si añadir alemán y español se convierte en semanas de negociación de rutas, coreografía de paquetes, depuración de respaldos y diplomacia entre frameworks y bibliotecas, el problema no es que traducir sea imposible por naturaleza.

El problema es que el modelo de aplicación trasladó demasiada responsabilidad al cliente.

La mayoría de aplicaciones web empresariales nunca necesitaron ese trato.

Necesitaban HTML sólido, URL sensatas, límites de idioma renderizados en servidor, mejora progresiva donde ayuda y capacidades PWA donde aportan valor real.

Esa pila está menos de moda.

Bien.

La moda es cómo los equipos terminan explicando Suspense para la etiqueta de un botón.