Si tu app de Lovable se renderiza en inglés sin importar qué idioma añadas, la causa es el cambio de stack: desde mediados de mayo de 2026, los proyectos nuevos de Lovable se publican sobre TanStack Start con server-side rendering, no la antigua single-page app de React y Vite. globalize.now es infraestructura de localización impulsada por IA que se adapta a este nuevo stack extrayendo tus cadenas a catálogos PO de Lingui en commit, de modo que el idioma correcto se renderiza en el servidor en lugar de cambiarse en el navegador. La solución no es otro widget. Es mover la traducción a tu repo, donde el servidor puede renderizarla y los motores de búsqueda pueden indexarla.

¿Por qué se volvió de repente más difícil localizar tu app de Lovable?

Porque el terreno cambió bajo los consejos antiguos. La mayoría de las guías «traduce tu app de Lovable» asumen una single-page app renderizada en cliente, donde un widget puede reescribir el DOM después de la carga sin que nadie lo note. Esa suposición ahora es incorrecta para los proyectos nuevos.

Lovable cambió los proyectos nuevos a TanStack Start con SSR para que los crawlers reciban HTML completamente renderizado en la primera petición, sin necesidad de ejecutar JavaScript. Eso es una mejora real de SEO, pero invierte cómo tiene que funcionar la traducción. Cuando la primera respuesta ya está renderizada, traducirla después en el navegador llega demasiado tarde.

Si construiste tu app en los últimos meses y le añadiste un widget de traducción en runtime, estás viendo el síntoma: un flash de inglés, y después el cambio. La integración de Lovable con globalize.now existe precisamente para resolver esto en la capa a la que pertenece.

¿Qué cambió realmente con el paso de Lovable a TanStack Start?

El modelo de renderizado cambió de client-side a server-side. Antes, Lovable generaba single-page apps construidas con React y Vite, desplegadas como archivos estáticos y renderizadas por completo en el navegador. Ahora la base es TanStack Start, un framework full-stack de React con SSR, SSG y CSR por ruta, además de server functions ubicadas junto a los componentes.

Para la localización, importan tres cosas. Primero, el HTML se produce en el servidor antes de llegar al navegador, así que el idioma se decide en el servidor. Segundo, el routing ahora admite URLs reales por locale. Tercero, cualquier cosa que dependa de APIs exclusivas del navegador para elegir un idioma se ejecuta después de que el servidor ya se haya decidido por uno.

Ese tercer punto es donde viven la mayoría de las configuraciones rotas. Un locale guardado en localStorage es invisible para el servidor, así que el servidor renderiza el idioma por defecto y el cliente lo corrige un instante después.

¿Por qué los widgets de traducción en runtime muestran un flash de inglés en SSR?

Porque traducen después de que el servidor ya ha enviado el inglés. En el nuevo stack, la secuencia es: el servidor renderiza el HTML en el idioma por defecto, el navegador lo pinta, y luego se carga el JavaScript del widget y reescribe el texto. El intervalo entre el pintado y la reescritura es el flash de inglés, y ahora es estructural, no un problema de ajuste.

El coste en SEO es peor que el flash. Un crawler lee la primera respuesta y sigue adelante. Si el texto traducido solo aparece después de que se ejecute JavaScript en el cliente, el crawler indexa inglés para cada locale, y no obtienes páginas por idioma que puedan posicionar. Toda la razón por la que Lovable pasó a SSR, HTML indexable, se anula al traducir en el navegador.

Los catálogos en commit evitan esto por diseño. Cuando las cadenas de traducción viven en tu repo, TanStack Start renderiza el locale solicitado en el servidor, así que la primera respuesta ya es correcta. Esta es la diferencia duradera entre una infraestructura que vive en tu codebase y un widget que se ejecuta por encima de ella, y es por eso que herramientas en runtime como Weglot se ajustan mejor al modelo SPA antiguo que al nuevo. Para un análisis más extenso del problema de sincronización, consulta por qué las traducciones de Lovable se rompen en cada push.

¿Cómo haces que una app de Lovable con TanStack Start sea multilingüe?

Mueve la traducción al servidor y mantén los catálogos en tu repo. En concreto, son cuatro pasos en el nuevo stack, y ninguno requiere que edites los archivos de locale a mano.

  1. Añade el Skill lovable-i18n y deja que Lovable configure el i18n. En tu workspace de Lovable, añade el Skill lovable-i18n y luego pide a Lovable que configure la internacionalización. Instala Lingui, extrae tus cadenas codificadas a catálogos de mensajes y configura el proveedor. Fuera del editor, la misma configuración se instala con npx skills add globalize-now/globalize-skills (añade --all para instalarlo en todos los agentes).
  2. Enruta los idiomas con el parámetro de ruta opcional de TanStack. TanStack Router usa {-$locale} para parámetros de ruta opcionales, así que una ruta definida como /{-$locale}/about coincide tanto con /about para tu idioma predeterminado como con /es/about para español. Eso le da a cada idioma una URL distinta y rastreable, en lugar de una sola URL cuyo texto cambia en el navegador.
  3. Resuelve el locale en el servidor, no en localStorage. Guarda el idioma activo en una cookie para que el handler de SSR pueda leerlo de la request. Con Lingui, el servidor llama a setupLocaleFromRequest() antes de crear el router, y la hidratación del cliente llama a dynamicActivate() con el locale que proporciona el servidor antes de renderizar. Usar el mismo valor en ambos lados evita el hydration mismatch y el parpadeo.
  4. Mantén los catálogos en tu repo, sincronizados en cada push. Los catálogos PO son archivos versionados, no el runtime de un proveedor externo. A medida que sigues construyendo en Lovable y aparecen cadenas nuevas, hay que volver a extraerlas y traducirlas, y esa es la parte que se degrada cuando se hace a mano. Ese es el trabajo que globalize.now automatiza, así los catálogos se mantienen al día sin ningún paso de exportación manual.
// server: resolve locale before the router exists
const locale = getLocaleFromCookie(request) ?? "en";
await setupLocaleFromRequest(locale);

// client: activate the SAME locale before first render
await dynamicActivate(serverLocale);

Al ser un procedimiento real, paso a paso, con salida versionada, se comporta como código bajo control de versiones estándar: revisable en un pull request, comparable con diff y portable si algún día te vas de Lovable.

¿Dónde encaja globalize.now en el stack de i18n de TanStack Start?

Se sitúa una capa por debajo de la biblioteca de runtime y por encima del motor de traducción. TanStack Start y Lingui sirven las traducciones en runtime; DeepL o un LLM genera las traducciones en sí. globalize.now es la infraestructura intermedia: genera las claves y los catálogos PO y los mantiene sincronizados, así el runtime siempre tiene algo correcto que renderizar.

El efecto práctico para quien construye con Lovable es que dejas de estar pendiente de los archivos de traducción. Instalas el Skill, se lo pides a Lovable una vez, y cada push posterior extrae las cadenas nuevas, completa los catálogos y abre el cambio como un PR normal. Sin ir y volver de un dashboard, sin reexportar, sin desfase entre lo que dice tu app y lo que contienen tus catálogos.

El precio es un único plan: 20 € al mes por workspace, con 20 € de crédito de traducción incluidos (unas 200.000 palabras) al mes, y a partir de ahí uso por tokens a la misma tarifa por carácter. No hay cargos por asiento ni por idioma, y el registro incluye 5 € de crédito sin necesidad de tarjeta. Una app típica de Lovable en cinco idiomas entra sin problema en esa cuota. Si quieres el detalle desde el lado del desarrollador, las páginas de globalize.now para desarrolladores y vibe coders profundizan más, y la descripción general del producto cubre el resto del stack.

Tu app de Lovable se queda en inglés porque la traducción está ocurriendo en el lugar equivocado, el navegador, después de que el servidor ya se comprometió con un idioma. Muévela a tu repo y el servidor renderiza el idioma correcto desde la primera petición. globalize.now se encarga de la extracción y la sincronización, así que lo configuras una vez y se mantiene al día en cada push.

globalize.now convierte el texto codificado de tu app en archivos de traducción listos para localizar y los mantiene actualizados en cada despliegue.

Prueba globalize.now gratis