¿Cómo se hace multilingüe una app de Replit sin dashboard?

Haces multilingüe una app de Replit conectando su repositorio Git a GitHub y manteniendo los catálogos de traducción en ese repositorio como archivos confirmados. Replit ya guarda cada checkpoint del Agent como un commit de Git, así que el repositorio existe antes de que pienses siquiera en idiomas; el trabajo consiste en llevarlo a GitHub y dejar que los catálogos vuelvan a través de ese mismo historial. globalize.now es infraestructura de localización impulsada por IA: genera las claves y los archivos de idioma, y la biblioteca de runtime que tu app ya usa los sirve. Ningún dashboard se sitúa en la ruta de ejecución, y nada traduce la página después de que carga.

¿Por qué no funciona pedirle al Agent que traduzca la app?

Porque no hay nada a lo que traducir. Cuando le pides a Replit Agent un dashboard, escribe <h2>Your bookings</h2> dentro de un componente, no una búsqueda en un catálogo. Cada encabezado, botón, estado vacío, toast y error de validación se genera en JSX como un literal en el idioma en el que se lo pediste.

Así que cuando más tarde le pides al Agent que «traduzca la app al afrikáans», obtienes uno de dos resultados a medias: una segunda copia de los componentes con el texto cambiado, o un objeto translations hecho a mano que cubre las pantallas que el Agent revisó por casualidad. Ninguno de los dos es una capa de locale. La siguiente funcionalidad vuelve a salir en inglés. Documentamos la misma recurrencia en Cursor sigue añadiendo cadenas codificadas; Replit Agent no se comporta de forma distinta, porque resuelve el prompt que tiene delante, no la arquitectura que hay detrás.

La solución es estructural: dar claves a las cadenas, poner las traducciones en archivos y hacer que el runtime las lea desde ahí. Eso es lo que significa «multilingüe» en un codebase, y es un cambio que se hace una sola vez.

¿Qué genera realmente Replit Agent?

Un proyecto web convencional, que es la buena noticia. Los tipos de app predefinidos de Replit se construyen alrededor de React con ShadCN UI en el front end, normalmente combinado con un servidor Express en el mismo proyecto, todo en TypeScript. Desde septiembre de 2025, el Agent también funciona con cualquier framework que tú aportes, incluidos repositorios de GitHub importados, así que un proyecto en Next.js o Vue es posible; la ruta por defecto sigue siendo el stack de React.

Para la localización, el stack es el único dato que importa, y es terreno estándar. React más Vite más TypeScript es la combinación más soportada en el ecosistema de i18n: i18next, Lingui y react-intl la tienen como objetivo directo. Si el Agent te construyó una app en Next.js en su lugar, la elección está entre next-intl, react-i18next y Lingui, y esa comparación es un post aparte.

Lo que cambia respecto a un builder solo de front-end es la segunda mitad del proyecto. Una app de Replit suele tener un servidor, y los servidores también tienen cadenas. Más sobre esto a continuación.

¿Dónde está el repositorio Git en una app de Replit?

Ya está ahí. El control de versiones de Replit es Git por debajo, y los checkpoints del Agent son commits en ese repositorio. Cada vez que el Agent termina una funcionalidad y te ofrece un punto de rollback, ha hecho un commit. La propia documentación de Replit recomienda pasar a commits de Git normales para el seguimiento a largo plazo cuando trabajas con repositorios externos, que es exactamente esta situación.

Para llevarlo a GitHub:

1. Añade la herramienta Git desde la sección Tools del editor del proyecto.
2. Conecta tu cuenta de GitHub en servicios conectados, y luego conecta el repositorio desde el panel de Git. Si el proyecto nunca se ha inicializado, el panel te ofrece hacerlo primero.
3. Haz push. El panel hace push con un clic, y se mantiene sincronizado con cualquier cosa que ejecutes en el Shell, así que git push origin main también funciona.

Replit también admite GitLab y Bitbucket, y aplica el mismo flujo. Lo importante no es el proveedor; es que el repositorio ahora vive en algún sitio contra el que un job de localización puede abrir un pull request.

Haz esto antes de tocar una sola cadena. El trabajo de localización es trabajo con archivos, y un diff es el lugar correcto para revisarlo.

¿Qué significa «sin dashboard» para una app de Replit?

Significa que las cadenas traducidas son archivos en el repositorio y la app las sirve como cualquier otro asset. Sin script tag, sin fetch externo al cargar la página, sin cuenta de proveedor situada entre un visitante y tu copy.

La alternativa es un widget en tiempo de ejecución que cambia el texto después de que la página ya se pintó. Sus costes son estructurales: el primer pintado es en inglés, la copy traducida no está en el HTML que los crawlers leen primero, un script de terceros se sitúa en tu ruta de producción, y tus cadenas viven en el almacén del proveedor, así que dejarlo implica una exportación. La versión de este argumento para Lovable está en Localizar una app de Lovable sin dashboard y se traslada a Replit sin cambios.

Hay una razón específica de Replit por la que esto importa aún más aquí. Replit despliega la app por ti, así que la copia en ejecución en tu dominio de Replit es lo que sea que esté en el proyecto en el momento del deploy. Un widget traduciría ese despliegue desde fuera. Los catálogos en el repositorio significan que el despliegue ya contiene todos los idiomas, y la vista previa de Replit te muestra la versión en alemán antes de que la publiques.

El compromiso es real y merece decirse: un cambio de copy implica un commit y un redeploy, no un botón de guardar. Para alguien que trabaja solo y publica desde Replit, eso no es un problema; para alguien que espera editar la copy en vivo sin tocar el proyecto, es una limitación.

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

Conecta el repositorio en la app de globalize.now. La conversión se ejecuta una vez contra el codebase: las cadenas codificadas se convierten en unidades de catálogo con claves, y los componentes empiezan a leer de una biblioteca runtime en lugar de contener literales. Es una operación única, no algo que se repita más adelante.

Tras la conversión, los push jobs traducen las nuevas unidades de catálogo a medida que la app crece. Le pides al Agente una nueva página de configuración, haces push, y las unidades nuevas se traducen; las existentes se quedan como están. Los catálogos vuelven como archivos confirmados, JSON o PO según la biblioteca runtime, en una pull request que revisas como cualquier otro cambio.

Dos límites, porque la categoría está confusa. globalize.now no sustituye la biblioteca 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 intermedia que produce las claves y los archivos de idioma. La visión general para desarrolladores explica la mecánica.

¿Cómo vuelven las traducciones a Replit?

A través del mismo panel de Git, en la dirección contraria. Este es el paso que difiere de Bolt o Lovable, porque Replit es también donde se ejecuta la app.

1. Revisa y haz merge de la pull request en GitHub.
2. En el panel de Git de Replit, selecciona Pull. Si tú o el Agente habéis cambiado los mismos archivos mientras tanto, el panel resalta los conflictos y los resuelves en el editor antes de completar el merge.
3. Vuelve a desplegar. Los catálogos ya forman parte del proyecto, así que el deploy incluye todos los idiomas.

Una advertencia específica de Replit: los checkpoints del Agente restauran todo el estado del proyecto, incluidos los archivos. Si vuelves a un checkpoint creado antes de hacer pull de la rama de traducción, los catálogos desaparecen con él. Trata el merge como un hito, deja que el Agente cree un checkpoint después y, si necesitas volver atrás, hazlo a ese checkpoint y no a uno anterior.

¿Qué cadenas viven en el servidor?

Las que el front end nunca ve como JSX. Una app de Replit con un back end de Express tiene una segunda superficie de cadenas: mensajes de error de la API, respuestas de validación, asuntos de email, cuerpos de notificaciones, cabeceras de CSV, cualquier cosa que el servidor formatea antes de enviarla. Un catálogo de front end no llega a ellas, y un widget no puede verlas en absoluto, porque nunca están en el DOM.

El patrón es el mismo que en el cliente, aplicado en el lado del servidor. Dale al servidor una copia de la biblioteca runtime, lee el locale del visitante desde la request (una cabecera Accept-Language o un campo locale en el registro de usuario) y formatea las respuestas desde el catálogo en lugar de a partir de literales de cadena. El namespace de claves se comparte, así que errors.booking.overlap significa lo mismo en un toast y en una respuesta 409.

Sáltate esto y la app parece multilingüe hasta el primer error, momento en el que habla en inglés.

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

Repasa esto antes de la conversión, porque cada punto es más barato de arreglar ahora que cuando ya hay cinco idiomas en marcha:

• Cadenas concatenadas. "Welcome back, " + user.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 está mal en la mayoría de los idiomas.
• Fechas, números y moneda. Usa Intl, no formato de cadenas, tanto en el cliente como en el servidor.
• Diseño. El alemán y el finés ocupan más espacio que el inglés. Los botones de ancho fijo se rompen, y las clases de Tailwind parecen correctas hasta que llega el texto real.
• De derecha a izquierda. Si el árabe o el hebreo están en la hoja de ruta, decídelo ahora. Añadir RTL a posteriori es lo caro.
• Desincronización de catálogos. Una vez existen los catálogos, una clave añadida en un idioma y no en los demás es un bug silencioso. Por qué los archivos de traducción se desincronizan explica cómo sucede y qué hace un push job al respecto.

El precio es por workspace, sin cargo por asiento ni por idioma, así que el número de idiomas es una decisión de producto y no una línea de presupuesto. Las cifras actuales están en la página de precios. Para el mismo recorrido en otros builders, la visión general para vibe coders es el punto de partida.

Por dónde empezar

Si tu proyecto de Replit ya está conectado a GitHub, el siguiente paso es una conversión contra ese repositorio, no una decisión sobre herramientas. Si aún no está conectado, el panel de Git es el paso previo a este.