Qué pasa realmente cuando haces tu app multilingüe en Lovable

Pides a Lovable que añada una nueva sección de precios. Lovable genera el componente, lo conecta y lo despliega. Tu UI en inglés se actualiza. Tus catálogos messages.po siguen apuntando a lo que había antes. Los usuarios en francés ven el texto antiguo. Los usuarios en alemán ven inglés. Nadie lo detecta hasta que un usuario real lo reporta.

Esto no es un bug de Lovable. Es un desajuste estructural. Lovable está optimizado para desplegar UI rápido. La i18n exige rastrear cada cadena visible para el usuario en cada catálogo de idioma, en cada cambio. Esos dos objetivos están en tensión directa entre sí.

El problema de extracción es continuo, no puntual. Cada prompt que ejecuta Lovable puede crear nuevas cadenas. Cada iteración cambia contenido existente. No hay un punto de control natural en el que puedas decir «la extracción está terminada».

Por qué las soluciones obvias no funcionan

¿Resuelve el problema una extracción puntual?

No. Puedes hacer una pasada de extracción de cadenas después de tu build inicial en Lovable y crear catálogos PO limpios. Eso funciona hasta el siguiente prompt. Después, estás comparando diffs manualmente entre potencialmente docenas de componentes y docenas de catálogos. Una sola cadena olvidada en tu catálogo messages.po en español y tus usuarios hispanohablantes ven texto en inglés en medio de una página traducida — lo que se conoce como UI de idioma mixto, una de las experiencias que más destruyen la confianza que puedes desplegar.

¿Son suficientes las herramientas de traducción en tiempo de ejecución?

Los traductores en tiempo de ejecución como Weglot o los widgets de traducción inyectados con JavaScript resuelven un problema distinto. Traducen el contenido después de que la página carga, lo que significa que los usuarios ven el idioma original durante una fracción de segundo antes de que aparezca el contenido traducido. Más allá de la mala experiencia de usuario, esto genera un Cumulative Layout Shift medible — una señal de Core Web Vitals que Google usa para posicionar páginas. Estás cambiando un problema de mantenimiento invisible por un problema de rendimiento visible.

¿Y qué tal simplemente pedirle a Lovable que actualice los archivos de locale?

Lovable puede escribir en catálogos PO si se lo pides. El problema: tienes que acordarte de pedirlo, para cada cadena, en cada prompt, en cada idioma. La carga cognitiva se multiplica con cada idioma que añades. Multiplícalo por cuatro idiomas y has convertido cada prompt de UI en un ejercicio de coordinación de cuatro pasos. Esa es exactamente la fricción que mata la velocidad que hacía que valiera la pena usar Lovable.

Cómo se rompe realmente el ciclo de i18n en Lovable

El patrón es lo bastante consistente como para tener una forma reconocible:

  1. Configuración inicial — Añades soporte multilingüe. Funciona. Todo está traducido. Te sientes bien.
  2. Primeras versiones — Te acuerdas de actualizar los catálogos PO manualmente. Es molesto pero manejable.
  3. Fase de velocidad — Empiezas a desplegar más rápido. Los catálogos PO empiezan a quedarse atrás. Te dices que te pondrás al día.
  4. Producción con idioma mixto — Los usuarios en mercados no anglófonos empiezan a ver inglés parcial. Llegan tickets de soporte. Pasas un ciclo de lanzamiento entero sin hacer otra cosa que cazar cadenas.
  5. El impuesto del refactor — Cada nueva función tiene ahora un coste oculto de i18n que no existía en la versión solo en inglés. Tu velocidad de lanzamiento cae.

El impuesto del refactor es la parte de la que nadie habla cuando escriben guías de «así se hace multilingüe una app en Lovable». Las guías muestran la configuración inicial. No muestran qué pasa en el lanzamiento número 12.

La solución: i18n conectada a tu ciclo de push en Git

La respuesta arquitectónica correcta es eliminar por completo los pasos manuales. Si las traducciones se actualizan automáticamente en cada push, el problema de mantenimiento desaparece. No puedes olvidarte de ejecutar la extracción si se ejecuta sola.

El flujo de trabajo es así:

  1. Conecta tu proyecto de Lovable a GitHub. Usa el menú + en el chat, luego GitHub, luego Conectar proyecto.
  2. Añade el Skill lovable-i18n a tu workspace. Abre Skills en tu workspace de Lovable, luego Añadir, luego Importar desde 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).
  3. Pide a Lovable que lo configure. Pega 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), hace una pregunta (idioma de origen, idiomas de destino, locale en la URL o no, añadir la GitHub Action), responde go para usar los valores por defecto. Instala Lingui, crea los catálogos PO 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, conecta el repositorio, autoriza la app de GitHub, selecciona tu repo de Lovable y la rama predeterminada, elige idiomas (más de 50, incluidos los RTL).
  6. Sigue construyendo en Lovable. Cada push activa a globalize.now para abrir un PR de traducción con catálogos PO actualizados; lo fusionas y la app se despliega traducida.

La propiedad clave: los pasos de conexión y sincronización no requieren nada de ti después de la configuración inicial. No ejecutas un comando. No revisas un dashboard. No apruebas una cola de traducción. Las nuevas cadenas en tus componentes generados por Lovable se capturan en el push, se traducen y vuelven como PR antes de que hayas fusionado la rama. La configuración paso a paso está en la página de integración con Lovable.

Qué significa esto para tu flujo de trabajo en Lovable

No necesitas dejar de usar Lovable. La arquitectura está diseñada bajo la premisa de que tu UI sigue cambiando — ese es precisamente el punto. Lovable genera la UI y ejecuta el Skill lovable-i18n; globalize.now se encarga de la sincronización.

Lovable genera componentes y aplica el Skill cuando necesitas i18n. globalize.now vigila el resultado en cada push. Tus usuarios siempre ven una UI completa y traducida, sin importar lo rápido que despliegues.

La página de Vibe Coders en globalize.now tiene más detalle sobre cómo funciona la configuración específicamente para apps generadas por IA. Si ya tienes una app en Next.js o React construida sobre Lovable, la página para desarrolladores cubre la ruta de integración técnica.

Para equipos que ya gestionan varios proyectos en Lovable, el precio por workspace de globalize.now significa que no pagas por idioma ni por extracción de cadenas — el coste de sincronización se mantiene fijo a medida que tu app crece.

El desgaste del mantenimiento es real y se acumula. Añade el Skill lovable-i18n en Lovable (Abre Skills en tu workspace, luego Añadir, luego Importar desde GitHub). 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