Hacer que una app de Lovable sea multilingüe de forma correcta significa confirmar catálogos de traducción reales en tu repo y mantenerlos sincronizados automáticamente, no pegarle un widget de traducción encima de la interfaz. globalize.now es infraestructura de localización impulsada por IA que extrae tus cadenas codificadas, genera los catálogos PO y los actualiza en cada push a Git. Las herramientas rápidas te dan una demo multilingüe en minutos. También te dejan con traducciones que se desincronizan, un layout que se mueve al cargar y páginas que a los motores de búsqueda les cuesta leer. Esta es la configuración que sobrevive hasta la versión doce.

¿Qué significa realmente «multilingüe de forma correcta» para una app de Lovable?

Significa que tus traducciones viven en tu codebase como catálogos confirmados, se sirven en el marcado inicial y se actualizan automáticamente a medida que la app cambia.

Cualquier app multilingüe real tiene tres capas. Una biblioteca de i18n en tiempo de ejecución sirve la cadena correcta para el locale activo. Los catálogos de traducción contienen las traducciones en sí. Y algo tiene que mantener esos catálogos al día a medida que la interfaz evoluciona. La mayoría de las guías de Lovable cubren la primera capa y se saltan la tercera, que es la que falla.

Lovable está diseñado para cambiar tu interfaz rápido. Cada prompt puede añadir, renombrar o reestructurar texto de cara al usuario. Así que la pregunta multilingüe no es «cómo traduzco la app una vez». Es «cómo mantengo cada idioma completo mientras sigo escribiendo prompts». Si te equivocas, acabas lanzando una interfaz con idiomas mezclados, una de las formas más rápidas de perder confianza en un mercado no anglófono.

¿Por qué se quedan cortos los widgets de traducción para las apps de Lovable?

Traducen el contenido después de que la página carga, lo que cambia un problema de mantenimiento invisible por uno visible de rendimiento y SEO.

Los traductores en tiempo de ejecución como Weglot, Lovalingo y los widgets de traducción inyectados son la primera respuesta más habitual para Lovable, porque se instalan en minutos y no necesitan archivos de locale. El coste aparece después. El usuario ve brevemente el idioma original antes de que la traducción lo sustituya, lo que produce un destello de contenido sin traducir. Ese cambio mueve el layout, añadiendo Cumulative Layout Shift, una métrica que Google mide como parte de los Core Web Vitals.

El problema de fondo es la capacidad de indexación. Si el texto traducido solo existe después de ejecutarse JavaScript en el cliente, en la práctica tienes una única página real más una traducción del lado del navegador. Las URL por idioma son débiles o inexistentes, así que tus páginas en español y en alemán no posicionan como lo haría un sitio correctamente localizado. Un widget puede ser la opción correcta para una herramienta interna o una demo desechable. Para una app que quieres que se encuentre en otros mercados, es la base equivocada.

¿Una configuración de i18n puntual mantiene traducida una app de Lovable?

No. Una extracción limpia funciona justo hasta tu siguiente prompt, y ahí empieza el desfase.

Puedes pedirle a Lovable, Cursor o Claude Code que conecte una biblioteca de i18n como es debido y vuelque cada cadena en catálogos de traducción. Eso funciona de verdad en el build sobre el que lo ejecutas. El problema es que no hay un punto natural en el que la extracción esté «terminada». La siguiente sección de precios, el siguiente estado vacío, la siguiente etiqueta de botón llegan como nuevas cadenas codificadas, y tus catálogos se van quedando atrás en silencio.

La alternativa manual, pedirle a Lovable que actualice cada catálogo en cada cambio, suena disciplinada y se desmorona en la práctica. Tienes que acordarte, por cada cadena, en cada idioma, en cada prompt. Multiplícalo por cuatro idiomas y cada cambio de interfaz se convierte en un ejercicio de coordinación. Esa fricción es justo lo que mata la velocidad que hacía valioso usar Lovable.

¿Cómo hago mi app de Lovable multilingüe, paso a paso?

Antes de empezar: conecta tu proyecto de Lovable a GitHub (menú + en el input del chat, luego GitHub, luego Connect project), crea una cuenta en globalize.now (registro gratuito, 5 € de crédito inicial, sin tarjeta) y asegúrate de ser propietario o admin del workspace en Lovable para poder añadir el Skill una vez para todo el workspace.

Conecta el repo, añade el Skill lovable-i18n una sola vez y deja que la sincronización se ejecute en cada push. Este es el recorrido completo.

  1. Conecta tu proyecto de Lovable a GitHub. Usa el menú + en el input del chat, luego GitHub, luego Connect project. Lovable sincroniza tu proyecto con un repositorio real, y eso es lo que hace posible un i18n duradero. Todo lo que sigue opera sobre ese repo, no dentro de una caja negra.
  2. Añade el Skill lovable-i18n a tu workspace. Lovable admite Skills reutilizables. Abre Skills en tu workspace de Lovable, luego Add, luego Import from GitHub, y pega https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n. Confirma. Una vez por workspace (se requiere ser propietario o admin del workspace). Añadir un Skill es gratis y no consume créditos. ¿Construyes en Cursor o Claude Code en su lugar? Ejecuta npx skills add globalize-now/globalize-skills en el repo conectado.
  3. Pide a Lovable que lo configure. Pega esto en el chat de Lovable: Set up i18n for my project using the lovable-i18n skill. Lovable detecta tu stack (Vite SPA o TanStack Start), te hace una pregunta (idioma de origen, idiomas de destino, si el locale va en la URL o no, añadir la GitHub Action), responde go para los valores por defecto. Instala Lingui (@lingui/core, @lingui/react, el plugin de Vite), conecta el provider, crea un catálogo PO por idioma en src/locales/{locale}/messages.po, envuelve las cadenas en macros <Trans> y añade un selector de idioma.
  4. Revisa y fusiona. Lovable sincroniza con GitHub; revisa el diff, fusiona a tu rama predeterminada.
  5. Conecta el repo a globalize.now. Inicia sesión, luego Connect repository, autoriza la app de GitHub, selecciona el repo de Lovable y la rama por defecto, y elige los idiomas (más de 50, RTL incluido).
  6. Sigue construyendo en Lovable. En cada push, globalize.now abre un PR de traducción con los catálogos PO actualizados. Fusiónalo. Tu app se lanza traducida. No necesitas hacer nada más entre versiones.

Lo que importa está en los pasos tres a seis: la configuración se hace una sola vez, y la sincronización continua no necesita ningún comando, ningún panel ni ninguna cola de revisión. Para el recorrido completo de la integración, consulta la página de integración con Lovable.

¿Qué biblioteca de i18n debería usar una app de Lovable?

El Skill lovable-i18n instala Lingui, porque las apps de Lovable son proyectos de React con Vite SPA o TanStack Start, y Lingui encaja con ese stack.

El Skill conecta @lingui/core, @lingui/react y el plugin de Vite, crea catálogos PO en src/locales/{locale}/messages.po y envuelve las cadenas en macros <Trans>. react-i18next y next-intl son las opciones correctas para otras configuraciones de React y de Next.js, pero el Skill no las instala.

Evita inventar un contexto de traducción a medida o codificar a mano un mapa de idiomas. El primer día parece más ligero, y se convierte en lo que acabas arrancando el día treinta. La página de desarrolladores de globalize.now explica cómo se aplica la extracción a cada biblioteca para que no elijas a ciegas.

¿Cómo mantengo las traducciones sincronizadas mientras sigo escribiendo prompts en Lovable?

Mueve la sincronización a tu flujo de Git para que sea imposible olvidarla.

El i18n manual falla porque depende de que una persona se acuerde de una tarea en medio de un ciclo de desarrollo rápido. La infraestructura saca a la persona de la ecuación. Cuando el paso de diff y traducción se ejecuta en cada push, una cadena nueva creada por un prompt de Lovable se detecta en ese mismo push, se traduce y vuelve como PR antes de que la rama se fusione. No hay ninguna versión en la que los catálogos PO se queden atrás en silencio, porque no hay ningún paso manual que saltarse.

Esta es la diferencia entre una configuración y una infraestructura. Una configuración es un estado al que llegas una vez. La infraestructura es una propiedad que se mantiene mientras todo a su alrededor cambia. Para una app que sigues editando en Lovable, quieres la propiedad, no el estado. Más sobre el flujo de trabajo específico de apps generadas por IA en la página de Vibe Coders, y si estás valorando herramientas, la guía comparativa ubica dónde encaja cada una en el stack.

Hacer que una app de Lovable sea multilingüe es fácil de empezar y difícil de mantener. globalize.now se encarga de mantenerlo. En Lovable, añade el Skill lovable-i18n desde Open Skills, luego Add, luego Import from GitHub, apuntando a globalize-now/lovable-i18n. En Cursor o Claude Code, ejecuta npx skills add globalize-now/globalize-skills. Consulta la guía de integración con Lovable o globalize.now.

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