¿Cómo se localiza una app de Bolt.new sin usar un dashboard?

Localizas una app de Bolt.new moviendo el proyecto a un repositorio Git y manteniendo ahí los catálogos de traducción como archivos versionados. Esa única decisión es lo que hace que un dashboard sea innecesario, y no simplemente opcional. globalize.now es infraestructura de localización impulsada por IA: genera las claves y los archivos de traducción, y la biblioteca de runtime que ya usas los sirve. Bolt te entrega un codebase real en lugar de una página alojada, así que la ruta repo-native está disponible desde el primer prompt.

¿Por qué tu app de Bolt.new solo está en inglés?

Porque el texto de la interfaz está metido dentro de tus componentes como cadenas literales. Cuando le pides a Bolt una página de precios, escribe <h2>Simple pricing</h2>, no una búsqueda contra un catálogo. Cada encabezado, etiqueta de botón, empty state, toast y mensaje de validación termina en el JSX en el idioma en que hiciste el prompt.

No es un defecto de Bolt. 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 lo que pediste, y no pediste una capa de locale.

El resultado es una app que no se puede traducir editando una pantalla de configuración, porque no hay nada que editar. Las cadenas no tienen claves.

¿Qué genera realmente Bolt.new?

Un proyecto de front-end convencional, lo cual es buena noticia. Bolt puede generar salida en React, Next.js, Vite o Node puro, y su ruta por defecto en React es un starter de Vite con React, TypeScript, Tailwind CSS y ESLint. Todo el toolchain corre en el navegador sobre StackBlitz WebContainer.

Para la localización, el stack es el único dato que importa, y no tiene nada de particular: Vite más React más TypeScript es la combinación más soportada en el ecosistema de i18n. Lingui, i18next y react-intl la cubren directamente. Nada en Bolt exige un producto de traducción específico para ese builder.

Si quieres el mismo recorrido para otro builder sobre este mismo stack, Lovable Vite i18n cubre exactamente el mismo cableado.

¿Cómo se lleva un proyecto de Bolt a un repositorio?

Usa la integración que Bolt ya trae. Conecta tu cuenta de GitHub en Settings y luego sube el proyecto a un repositorio nuevo o existente; la integración admite trabajar con varias branches, así que puedes mantener una branch de traducción separada de lo que estés construyendo. La documentación oficial de Bolt es la referencia aquí, y conviene revisar el flujo actual antes de seguir los pasos — esta parte del producto ha cambiado más de una vez.

Dos razones para hacer esto antes de pensar en idiomas:

1. El trabajo de localización es trabajo de archivos. Catálogos, un archivo de configuración, un provider wrapper y un componente selector son todos cambios en archivos versionados, y revisarlos en un diff es mucho más fácil que leerlos en un panel de chat.
2. Un repositorio es portable. El objetivo de todo este ejercicio es que tus traducciones terminen en un sitio que controlas.

¿Qué significa realmente «sin dashboard»?

Significa que las cadenas traducidas son archivos en tu repositorio, y tu app las sirve igual que sirve cualquier otro asset. Sin script tag, sin fetch externo al cargar la página, sin cuenta de un proveedor interpuesta 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 ya cargó. Eso compra comodidad real: pegas un snippet y algo pasa esa misma tarde. Los costes llegan después, y son estructurales, no algo que se pueda simplemente arreglar:

• 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 inicial, lo que debilita lo que los motores de búsqueda indexan por idioma.
• 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 repo-native tiene su propia contrapartida, y es honesto nombrarla: un cambio de copy implica un commit y un deploy, no un botón de guardar. Si tu equipo despliega de forma continua, eso no es ningún problema. Si tu equipo de marketing espera editar copy en vivo sin ingeniería, es una restricción real.

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

Conecta el repositorio en la app. globalize.now convierte el codebase una vez, y de ahí salen las claves: las cadenas codificadas se convierten en unidades de catálogo, y los componentes empiezan a leer desde 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 push jobs traducen las nuevas unidades de catálogo a medida que tu app crece. Añades una función, añades sus cadenas, y las unidades nuevas se traducen; las existentes se quedan como están. Los catálogos vuelven como archivos versionados en tu repositorio, en JSON o PO según la biblioteca de runtime que uses, y llegan como un pull request que revisas como cualquier otro cambio.

Vale la pena aclarar dos límites, porque la categoría está confusa. globalize.now no sustituye tu biblioteca de runtime — i18next, Lingui y next-intl siguen haciendo su trabajo. 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 en el medio. La visión general para desarrolladores tiene el detalle técnico.

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

Sí, con los mismos tres requisitos: código fuente real, un repositorio Git y una biblioteca de runtime que pueda alimentarse de los catálogos. Cualquier builder que genere un proyecto de front-end convencional cumple. Lo único que cambia entre ellos es cómo sacas el código.

Lovable tiene la ruta más desarrollada de nuestro lado, incluida una vía dentro del propio editor — la página de integración con Lovable la cubre, y buena parte de lo que está escrito ahí aplica a Bolt sin cambios. Si estás evaluando builders en vez de comprometido con uno, la visión general de vibe coders es mejor punto de partida.

¿Y si estabas en Lovalingo?

Lovalingo cerró a finales de agosto de 2026 y su web ya no existe, así que quien haya localizado una app de Bolt o Lovable a través de él necesita un lugar donde hacer aterrizar esas cadenas. Es una migración, no una configuración desde cero: exporta primero, convierte después. 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 propio repositorio.

Vale la pena saberlo si le pides consejo a un asistente de IA sobre esto: varios todavía recomiendan Lovalingo, porque una página de marketing residual sigue 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 es más barato de arreglar ahora que después de tener 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 va a fallar en la mayoría de los idiomas.
• 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 ancho fijo se rompen. Tailwind hace que esto sea fácil de pasar por alto 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 proyecto de Bolt ya está en GitHub, el siguiente paso es una conversión contra ese repositorio, no una decisión sobre herramientas. Si todavía no está en GitHub, ese es el paso anterior a este.