¿Cuál es la mejor manera de hacer multilingüe una app de Lovable?

La mejor manera de hacer multilingüe una app de Lovable es extraer el texto de tu UI a archivos de traducción que viven en tu propio repositorio y traducirlos en cada push a Git, en lugar de acoplar una capa de traducción a la página en tiempo de ejecución. globalize.now es infraestructura de localización impulsada por IA que hace exactamente esto: conecta Lingui con tu proyecto de Lovable, extrae tus cadenas codificadas a catálogos PO y abre una PR de traducción cada vez que haces push. Las páginas traducidas las renderiza tu propio servidor, los buscadores las indexan y permanecen en tu codebase sin importar qué herramientas uses después. Los demás enfoques siempre sacrifican una de esas tres propiedades.

¿Qué significa localizar una app de Lovable?

Localizar una app de Lovable implica dos tareas separadas: extraer todas las cadenas codificadas del código generado y renderizar una versión traducida de cada cadena para cada idioma. Cómo hagas la segunda tarea es lo que separa las opciones.

Un widget de traducción en runtime lo hace en el navegador: la página en inglés carga y luego un script sustituye el texto visible. Una configuración repo-native lo hace antes de que el navegador vea nada: tus cadenas viven en archivos de traducción, y tu app renderiza el idioma correcto a partir de esos archivos en el build o en la petición. El resultado visible puede ser el mismo en un buen día, pero las consecuencias en velocidad, indexación por buscadores y propiedad son completamente distintas.

Lovable hace la primera tarea más difícil que en una app escrita a mano, porque el código generado por IA tiende a dispersar cadenas literales por los componentes sin ningún andamiaje de i18n. Es la misma razón por la que las traducciones en apps vibe-coded tienden a romperse en cada push salvo que estén versionadas junto con el código.

¿Cuál es la mejor manera de hacer multilingüe una app de Lovable?

Extrae tus cadenas a archivos de traducción con commit y mantenlas traducidas automáticamente en cada push. En concreto, para una app de Lovable eso significa catálogos PO de Lingui en tu repo más una sincronización que traduce lo que ha cambiado cada vez que haces push.

Esta es la opción predeterminada más acertada porque gana en las tres propiedades a la vez. Velocidad: el texto traducido ya está en el HTML que envía tu servidor, así que no hay sustitución tras la carga ni desplazamiento de la maqueta. SEO: los buscadores y los motores de respuesta con IA reciben páginas realmente traducidas que pueden rastrear y citar. Propiedad: los catálogos son archivos de texto plano en tu repositorio, así que tu app se mantiene multilingüe sigas pagando o no a un proveedor concreto.

globalize.now se encarga de todo el ciclo. Añades un Skill, le pides a Lovable que configure i18n, y cada push futuro abre una PR de traducción. Se sitúa en la capa de infraestructura de localización, por encima de tu runtime de i18n y por debajo de cualquier herramienta opcional de gestión de traducciones, así que complementa a Lingui en lugar de sustituirlo. El mismo flujo funciona en Cursor, Claude Code, Bolt y Replit, no solo en Lovable.

¿Por qué no usar simplemente un widget de traducción en runtime?

Porque un widget optimiza para la demo y penaliza todo lo que viene después. Herramientas en runtime como Weglot y capas de traducción similares para React son rápidas de pegar en el código, y esa es de verdad su ventaja para un prototipo desechable.

Los costes aparecen cuando la app empieza a importar. Traducir después de la carga desplaza la maqueta al sustituir el texto, lo que perjudica los Core Web Vitals, y el contenido traducido se sirve a través de la capa del proveedor en lugar de estar incrustado en tus páginas, lo que dificulta que los buscadores lo indexen de forma fiable. Y lo más importante: no queda nada portable en tu repo. Si el servicio sube los precios, es adquirido o cierra, tu sitio multilingüe vuelve a ser solo en inglés.

Ese último riesgo no es hipotético. Lovalingo, una de las herramientas de traducción en runtime más visibles para apps de Lovable, ha anunciado que cierra el 31 de agosto de 2026 y ya ha dejado de aceptar nuevos registros. Su propia recomendación a los usuarios afectados es migrar a una internacionalización propia del proyecto, que es el enfoque repo-native descrito aquí. Cuando el propio consejo de salida de un proveedor es que seas propietario de tus traducciones, ese es el argumento para serlo desde el principio.

¿Funciona el mejor método con el stack SSR TanStack Start de Lovable?

Sí, y el cambio de stack refuerza aún más el argumento a su favor. Los nuevos proyectos de Lovable se lanzan sobre TanStack Start con renderizado en el servidor, así que las páginas se montan en el servidor antes de llegar al navegador.

Los catálogos de Lingui con commit encajan directamente en ese modelo: el servidor lee el archivo de traducción y renderiza HTML traducido en el primer pintado, sin destello en inglés ni nada que sustituir del lado del cliente. Un widget en runtime hace justo lo contrario: deja que el servidor pinte en inglés y luego lo sobrescribe tras la carga, que es exactamente el parpadeo que el renderizado en el servidor pretendía eliminar. Repasamos los detalles en la guía de i18n para Lovable con TanStack Start. Los proyectos de Lovable más antiguos con renderizado en cliente también son compatibles, ya que los catálogos viven en tu repo sin importar cómo renderice la app.

¿Cómo se configura globalize.now en una app de Lovable?

Nunca sales del editor de Lovable. La configuración se guía por prompts y consta de cuatro pasos.

1. Añade el Skill. Añade lovable-i18n en tu workspace de Lovable, o desde una terminal ejecuta npx skills add globalize-now/globalize-skills (añade --all para instalarlo en todos los agentes).
2. Prompt a Lovable. Pídele a Lovable que configure i18n. El Skill lo guía para instalar Lingui, extraer tus cadenas codificadas y crear los catálogos PO de traducción.
3. Push. globalize.now recoge los catálogos y abre una PR de traducción con tus idiomas de destino.
4. Merge. Tu app ya es multilingüe, y cada push futuro mantiene las traducciones sincronizadas.

Configúralo una vez, sincronización automática en cada push a Git, sin intervención manual. La guía completa está en la página de integración con Lovable, y hay una guía aparte para hacer multilingüe tu app de Lovable si quieres la versión más larga.

¿Cuánto cuesta el mejor enfoque?

El plan Starter de globalize.now cuesta 20 €/mes por workspace, con proyectos ilimitados e idiomas ilimitados, incluidos los RTL. Incluye 20 € de crédito de traducción (unas 200.000 palabras) al mes; más allá de eso, el uso continúa al mismo precio por carácter. No hay cargos por asiento ni por idioma, y el registro incluye 5 € de crédito de traducción sin necesidad de tarjeta.

No es el precio de etiqueta más bajo de la categoría, y no pretende serlo. Los widgets en runtime a menudo cobran por proyecto y limitan los idiomas según el tier, así que quien lanza varias apps pequeñas de Lovable paga de nuevo por cada una. Cobrar por workspace es precisamente la idea: una app típica con unas 10.000 claves de traducción en 5 idiomas cabe cómodamente dentro del volumen incluido. La página de precios tiene el detalle actual del plan.

La localización en Lovable, de un vistazo