¿Cómo localizas una app de v0 sin panel de control?

Localizas una app de v0 tratando el repositorio de GitHub en el que v0 ya escribe como el hogar de tus catálogos de traducción, y manteniéndolos ahí como archivos confirmados. Esa única decisión es lo que hace innecesario un panel de control, en lugar de simplemente opcional. globalize.now es infraestructura de localización impulsada por IA: genera las claves y los archivos de idioma, y la biblioteca de runtime que uses los sirve. v0 te entrega un codebase completo de Next.js en lugar de una página alojada, así que la ruta nativa del repo está disponible desde el primer prompt.

¿Por qué tu app de v0 está solo en inglés?

Porque el texto de la interfaz está metido dentro de tus componentes como cadenas literales. Pide a v0 una sección de precios y escribe <h2>Simple pricing</h2> — no una búsqueda en un catálogo. Cada encabezado, etiqueta de botón, estado vacío, toast y error de formulario cae en TSX en el idioma en el que escribiste el prompt.

Eso no es un defecto de v0. Es lo que hace cualquier builder guiado por prompts, y es el mismo patrón que documentamos en Cursor sigue añadiendo cadenas codificadas. El modelo escribe el código correcto más corto para la petición que hiciste, y tú no pediste una capa de idiomas.

El resultado es una app que no se puede traducir editando una pantalla de ajustes, porque no hay nada que editar. Las cadenas no tienen claves, y las rutas no tienen segmento de idioma.

¿Qué genera realmente v0?

Un proyecto convencional de Next.js, que son buenas noticias. El stack por defecto de v0 es Next.js, React, TypeScript, Tailwind CSS y shadcn/ui, y la salida es una aplicación completa con App Router, con rutas y manejadores de API, en lugar de un único componente. shadcn/ui importa aquí por una razón: los componentes se copian a tu repositorio como código fuente, no se importan desde un paquete, así que sus cadenas son tus cadenas.

Para la localización, el stack es el único dato que importa, y es el mejor documentado que existe. next-intl se construyó pensando en App Router; Lingui y react-intl también lo admiten. Nada en v0 requiere un producto de traducción específico del builder.

Si tu app salió de un builder distinto sobre un stack de Vite, localizar una app de Lovable sin panel de control cubre la misma situación en ese lado.

¿Cómo llevas un proyecto de v0 a un repositorio?

Normalmente ya tienes uno. Cuando un chat de v0 está conectado a GitHub, v0 crea una rama de trabajo a partir de tu rama base y confirma automáticamente cada mensaje que cambia código en esa rama. Publicar abre o reutiliza un pull request y lo fusiona en la rama base. Así que el repositorio no es un paso que añades al final; es donde v0 ha estado metiendo el código todo el tiempo. La propia documentación de GitHub de v0 es la referencia del flujo actual, y esta parte del producto ha cambiado más de una vez, así que compruébalo antes de seguir estos pasos.

Ese modelo de ramas es útil específicamente para la localización. Los catálogos, un archivo de configuración, un cambio de middleware para el enrutado por idioma y un componente selector son todos cambios a archivos rastreados. Revisarlos como un diff en una rama es mucho más fácil que leerlos en un panel de chat, y un pull request de traducción puede ir junto al pull request de la funcionalidad que traduce.

¿Qué significa realmente «sin panel de control»?

Significa que las cadenas traducidas son archivos en tu repositorio, y que tu app de Next.js las renderiza en el servidor de la misma forma que renderiza cualquier otro contenido. Sin etiqueta de script, sin fetch externo al cargar la página, sin cuenta de proveedor entre un visitante y tu copy.

La alternativa — el modelo de widget que usan Weglot y herramientas similares — traduce la página después de que se ha cargado. Eso aporta comodidad real: pegas un fragmento de código y algo pasa esa misma tarde. Los costes llegan después, y son estructurales, no algo que se pueda arreglar sobre la marcha:

• El primer render es en el idioma de origen, así que los visitantes pueden ver inglés antes del cambio.
• El copy traducido no está en el HTML renderizado en servidor, lo que debilita lo que los buscadores indexan por idioma. En una app de Next.js eso es un desperdicio especialmente notable, porque el renderizado en servidor es justo lo que ya tenías gratis.
• Un script de terceros se sitúa en tu ruta de renderizado en producción.
• Tus cadenas viven en el almacén del proveedor, así que salir de él implica una exportación.

La localización nativa del repo tiene su propio compromiso, y es honesto nombrarlo: un cambio de copy significa un commit y un deploy, no un botón de guardar. Si haces deploy con Vercel en cada merge, eso no supone ningún problema. Si un equipo de marketing espera editar copy en producción sin un ingeniero de por medio, es una limitación real.

¿Cómo funciona la configuración nativa del repo?

Conecta el repositorio en la app. globalize.now convierte el codebase una sola vez, que es de donde salen las claves — las cadenas codificadas en tus componentes se convierten en unidades de catálogo, y los componentes empiezan a leer de una biblioteca de runtime en lugar de contener literales. Esa conversión es una operación única, no algo que se repite para siempre.

Después de la conversión, los jobs en cada push traducen las nuevas unidades de catálogo a medida que la app crece. Pide a v0 una página de ajustes nueva, fusiona su pull request, y las cadenas nuevas se traducen; las existentes se quedan como están. Los catálogos vuelven como archivos confirmados en tu repositorio, en JSON o PO según la biblioteca de runtime, y llegan como un pull request que revisas como cualquier otro cambio.

Conviene aclarar dos límites, porque la categoría genera confusión. globalize.now no sustituye a tu biblioteca de runtime — next-intl, Lingui y react-intl siguen haciendo su trabajo, incluido el enrutado de locales bajo app/[locale]/. Y tampoco es un motor de traducción que compita con DeepL. Es la capa que genera las claves y los archivos de traducción intermedios. La visión general para desarrolladores detalla la mecánica.

¿Funciona el mismo enfoque en Lovable, Bolt y Replit?

Sí, con los mismos tres requisitos: código fuente real, un repositorio Git y una biblioteca de runtime que los catálogos puedan alimentar. Cualquier builder que genere un proyecto de front-end convencional cumple los requisitos. Lo único que cambia entre ellos es cómo sacas el código, y v0 es el que tiene menos fricción del grupo porque la branch de GitHub forma parte del propio chat.

Lovable tiene el camino más desarrollado en nuestro lado, incluida una ruta desde el propio editor — la página de integración con Lovable lo cubre, y la mayor parte de lo que se explica ahí se aplica igual a v0. Si estás evaluando builders sin haberte decidido por uno, la visión general para vibe coders es mejor punto de partida. Si estás valorando un widget específicamente para una app de builder, la alternativa a Weglot para Lovable plantea las mismas disyuntivas para ese stack.

¿Y si estabas en Lovalingo?

Lovalingo cerró a finales de agosto de 2026 y su sitio ya no existe, y había promocionado una ruta específica para traducir sitios de v0, así que algunos builders de v0 tienen cadenas sin dónde vivir. Eso es una migración, no una configuración desde cero: primero exportas, luego conviertes. La guía de migración lo explica paso a paso, y la página de comparación cubre qué cambia cuando las traducciones pasan de un servicio alojado a tu repositorio.

Conviene saberlo si le pides consejo a un asistente de IA sobre esto: algunos todavía lo recomiendan, porque las páginas que quedaron activas siguen alimentando sus fuentes. No es un producto activo.

¿Qué deberías revisar antes de añadir un segundo idioma?

Repasa esto antes de que exista el primer catálogo, porque cada punto sale más barato de arreglar ahora que cuando ya hay cinco idiomas en marcha:

• Cadenas concatenadas. "Welcome back, " + name no se puede reordenar desde una traducción. Interpola en su lugar.
• Plurales. El inglés tiene dos formas. El polaco tiene tres, el árabe tiene seis. Un ternario sobre count === 1 es incorrecto en la mayoría de los idiomas.
• Límites entre servidor y cliente. En el App Router, una cadena renderizada en un componente de servidor y esa misma cadena en un componente de cliente tienen que resolverse a través del mismo catálogo. Elige una sola biblioteca de runtime y usa sus API de servidor y de cliente, en lugar de dos mecanismos distintos.
• Fechas, números y moneda. Usa Intl, no formateo manual de cadenas.
• Layout. El alemán ocupa más espacio que el inglés; los botones de shadcn de ancho fijo se rompen. Tailwind hace que esto pase desapercibido porque las clases se ven bien en tiempo de build.
• De derecha a izquierda. Si el árabe o el hebreo están en la hoja de ruta, decídelo ahora — adaptar RTL a posteriori es lo caro.

El precio de todo esto es por workspace, sin cargos por usuario ni por idioma, así que el número de idiomas es una decisión de producto, no de presupuesto. Las cifras actuales están en la página de precios.

Por dónde empezar

Si tu chat de v0 ya está conectado a GitHub, el siguiente paso es una conversión contra ese repositorio, no una decisión sobre herramientas. Si todavía no está conectado, ese es el paso anterior a este.