La mejor forma de localizar una app de Lovable construida sobre el stack clásico de Vite es extraer tus cadenas codificadas a catálogos PO de Lingui versionados, no añadir un widget de traducción en runtime. Tu app de Lovable es una SPA de React renderizada en el cliente, así que no hay render de servidor al que engancharse, y la opción duradera son archivos de traducción que viven en tu propio repo y se despliegan con tu build. globalize.now es infraestructura de localización impulsada por IA que hace la extracción y mantiene esos catálogos sincronizados en cada push a Git, así que lo configuras una vez y no vuelves a gestionar archivos de traducción a mano.
¿En qué stack está tu app de Lovable, Vite clásico o TanStack Start?
Abre primero tu árbol de archivos, porque Lovable genera dos stacks distintos y cada uno necesita una configuración de i18n diferente. Si ves src/pages/Index.tsx, src/main.tsx y vite.config.ts, estás en el stack clásico de Vite más React SPA, que es el predeterminado de Lovable. Los proyectos de TanStack Start, en cambio, tienen src/routes/, src/router.tsx, src/routeTree.gen.ts y src/server.ts.
El stack se elige al crear el proyecto y no se puede cambiar después, así que esta decisión ya está tomada por ti. El stack clásico de Vite renderiza por completo en el navegador y no hace fetching de datos en el servidor por defecto. Esta guía cubre esa SPA clásica de Vite. Si tus archivos coinciden con la estructura de TanStack Start, sigue en su lugar nuestra guía de i18n de TanStack Start para Lovable, ya que el renderizado en servidor cambia cómo se cargan las traducciones.
¿Por qué las apps de Lovable con Vite SPA quedan fuera de las herramientas de i18n?
Porque la atención de las herramientas se movió hacia el nuevo stack predeterminado de Lovable, TanStack Start con SSR, y dejó desatendido al clásico Vite SPA, aunque sigue siendo el stack más común en Lovable. En los últimos meses, las herramientas de localización orientadas a Lovable, incluidas Lovalingo, Intlayer y Paraglide, reorientaron todas sus guías hacia TanStack Start con renderizado en servidor.
Eso deja un hueco. Una SPA renderizada en cliente tiene restricciones reales que las guías de SSR ignoran: no hay render de servidor donde inyectar markup traducido, todo el bundle se carga en el navegador, y cualquier script que cargue tarde pinta encima de una interfaz en inglés. La buena noticia es que el stack clásico tiene una solución limpia y bien respaldada de la que la mayoría nunca oye hablar, porque las herramientas más ruidosas están ocupadas persiguiendo el otro stack.
¿Cuál es la diferencia entre catálogos versionados y un widget de traducción en runtime?
Los catálogos versionados son archivos de traducción incluidos en tu repositorio y empaquetados en tiempo de build, mientras que un widget en runtime es un script de terceros que sustituye el texto en el navegador después de que tu interfaz en inglés ya se ha cargado. Esa diferencia decide tres cosas que importan en una SPA de Vite.
Primero, el parpadeo y el salto de layout: un widget muestra el inglés y luego lo reescribe, así que el usuario ve un cambio visible y el layout puede saltar. Los catálogos versionados renderizan el idioma correcto desde el primer pintado. Segundo, la indexabilidad: las cadenas que van incluidas en tu build forman parte de tu código fuente, mientras que el texto de un widget se inyecta tarde y es más difícil de leer para los crawlers. Tercero, la propiedad: los catálogos versionados son archivos tuyos en tu repo, así que nada externo tiene que seguir en línea para que tu app siga hablando alemán o japonés.
¿Cómo se añade i18n a una app de Lovable con Vite usando Lingui?
Añade Lingui como tu capa de i18n, envuelve tus cadenas y deja que su plugin de Vite compile los catálogos. Lingui es un framework de i18n ligero, con un plugin de Vite dedicado y un formato de catálogo basado en PO, que es justo lo que necesita una SPA renderizada en cliente.
Primero, instala los paquetes. Lingui separa su CLI, su plugin de Vite y su runtime de React:
npm install --save-dev @lingui/cli @lingui/vite-plugin @rolldown/plugin-babel
npm install @lingui/core @lingui/react
A continuación, registra el plugin en vite.config.ts y añade un lingui.config.ts que apunte a tu carpeta de código fuente y de idiomas:
// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { lingui } from "@lingui/vite-plugin";
export default defineConfig({
plugins: [react(), lingui()],
});
// lingui.config.ts
import { defineConfig } from "@lingui/cli";
export default defineConfig({
locales: ["en", "de", "fr"],
sourceLocale: "en",
catalogs: [
{
path: "src/locales/{locale}/messages",
include: ["src"],
},
],
});
Luego envuelve tu texto JSX codificado con la macro Trans en lugar de dejar cadenas sueltas:
// before
<h1>Create your account</h1>
// after
import { Trans } from "@lingui/react/macro";
<h1><Trans>Create your account</Trans></h1>
Ahora extrae. La CLI escanea tu directorio src y escribe un catálogo PO por idioma, por ejemplo src/locales/en/messages.po:
npx lingui extract
Completa los campos msgstr para cada idioma, o delega ese paso a una capa automatizada (ver la siguiente sección). No necesitas ejecutar un comando de compilación aparte, porque el @lingui/vite-plugin compila los catálogos PO al vuelo durante el desarrollo y el build.
Por último, añade un selector de idioma activando un locale en runtime:
import { i18n } from "@lingui/core";
i18n.activate("de");
Ese es todo el ciclo para el stack clásico de Vite: instalar, envolver, extraer, traducir, cambiar de idioma. Todo excepto las traducciones en sí vive en tu repo.
¿Cómo automatiza globalize.now todo esto en cada push?
globalize.now elimina los pasos manuales de extracción y relleno vigilando tu repo y haciéndolos por ti en cada push a Git. Encuentra cadenas recién codificadas en tu codebase de Lovable, genera las claves y las entradas PO que Lingui espera, produce las traducciones y confirma los catálogos actualizados de vuelta, así tu carpeta src/locales está siempre al día sin que tengas que ejecutar comandos.
Conecta el repositorio en globalize.now una vez y empieza a vigilarlo. Para configurarlo desde tu editor en su lugar, instala los Skills:
npx skills add globalize-now/globalize-skills
Dentro de Lovable en concreto, añade el Skill lovable-i18n en tu workspace y luego pide a Lovable que configure el i18n. El runtime sigue siendo Lingui, así que no cambia nada en cómo se renderiza tu app. Lo que cambia es que dejas de estar pendiente de los archivos de traducción. Es el mismo modelo de configúralo una vez, sincroniza en cada push, sobre el que se construyen nuestro flujo de trabajo para vibe coders y la configuración para desarrolladores.
El precio es sencillo para quien construye en solitario: 20 € al mes por workspace, sin cargos por asiento ni por idioma, más las traducciones que realmente uses. Los workspaces nuevos reciben un crédito de registro de 5 € sin necesidad de tarjeta, suficiente para traducir de principio a fin una app pequeña.
¿Deberías usar un widget en runtime en su lugar? La lección de Lovalingo
No, si quieres que tus traducciones sobrevivan a cualquier proveedor concreto. Un widget de traducción en runtime es cómodo al principio, pero hace que tu app dependa de que el servidor de otro siga en línea, y esa dependencia tiene un modo de fallo real.
Lovalingo, un widget en runtime popular entre quienes construyen con Lovable, anunció que cierra el 31 de agosto de 2026, sin aceptar nuevos registros y sin sucesor designado. Su propia guía de migración le dice a los usuarios que pasen a una internacionalización propiedad del proyecto, que es exactamente el enfoque de catálogos versionados de esta guía. Cuando el proveedor de un widget cierra, las traducciones inyectadas dejan de funcionar y la interfaz vuelve al inglés. Los archivos en tu repo, no. Si ya usas un widget, nuestra guía de migración por el cierre de Lovalingo explica el proceso paso a paso, y el problema más amplio de las traducciones que se rompen en cada push explica por qué los catálogos versionados ganan para apps generadas con IA.
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