¿Cómo localizas una app de Base44 sin dashboard?

Localizas una app de Base44 conectándola a GitHub con la sincronización bidireccional que ofrece Base44 y manteniendo los catálogos de traducción en ese repositorio como archivos con commit. Base44 ya refleja cada cambio entre el editor y el repositorio, así que en el momento en que los archivos de traducción llegan a la rama main pasan a formar parte de la app. globalize.now es infraestructura de localización impulsada por IA: genera las claves y los archivos de traducción, y la biblioteca de runtime de tu proyecto los sirve. Ningún dashboard se interpone en el camino de runtime, y nada traduce la página después de que carga.

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

Porque el texto de interfaz está dentro de tus componentes como cadenas literales. Cuando le pides a Base44 una página de reservas, escribe <h2>Your bookings</h2> dentro de un componente React, no una consulta contra un catálogo. Cada título, etiqueta de botón, estado vacío, toast y mensaje de validación queda en el JSX en el idioma en el que hiciste el prompt.

No es un defecto de Base44. Es lo que hace cualquier builder impulsado 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 tú no pediste una capa de locale.

Pedirle a Base44 que «traduzca la app al alemán» tampoco lo soluciona. Obtienes una copia en alemán de las pantallas que el modelo inspeccionó, o un pequeño objeto de cadenas que inventa sobre la marcha. El siguiente prompt vuelve a escribir texto nuevo en inglés, porque nada en el proyecto dice que el texto tiene que pasar por un catálogo.

¿Qué genera realmente Base44?

Un proyecto React estándar construido con Vite. La propia documentación de estructura de proyecto de Base44 muestra la organización que obtienes en la pestaña Code y en un repositorio conectado: src/pages contiene un archivo por ruta, así que Home.jsx se convierte en / y Settings.jsx se convierte en /settings; src/components contiene las piezas reutilizables con una carpeta ui/ de componentes ya construidos; src/api, src/hooks, src/lib y src/utils contienen el cliente del SDK, los hooks y las funciones auxiliares.

Dos directorios importan más que el resto para la localización. functions/ contiene tu lógica de backend, un archivo TypeScript por función, y esos archivos dan formato a texto que leen los usuarios: respuestas de error, correos, documentos generados. entities/ contiene tu modelo de datos como archivos de esquema JSON, y con la sincronización bidireccional las entidades se gestionan en Base44 en lugar de en el repositorio.

Así que una app de Base44 tiene dos superficies de cadenas que los catálogos pueden cubrir, el cliente React y las funciones de backend, y una que no pueden, los datos dentro de las entidades. Volvemos sobre esta última más abajo.

¿Cómo llevas una app de Base44 a un repositorio?

Base44 ya trae la conexión integrada. En el editor, abre el Dashboard, haz clic en el icono de GitHub y conecta. Autorizas la app Base44 Builder en tu cuenta u organización de GitHub, eliges a qué repositorios puede acceder y creas un repositorio nuevo para la app. A partir de ahí, el repositorio y el editor se mantienen alineados en ambas direcciones.

Dos reglas de la documentación de Base44 determinan todo lo que sigue. Primero, la sincronización es automática: los cambios que haces en Base44, incluidos los que hace la IA a partir de un prompt, se registran en commits en el repositorio sin un paso de push, y no hay ningún botón para hacer push manualmente. Segundo, el camino de vuelta es la rama main. Todo lo que se fusiona a main se hace visible en la app de Base44, y master o cualquier otro nombre de rama por defecto no es compatible. Después de un merge, haces clic en Publish para poner en producción la nueva versión para los usuarios.

La sincronización bidireccional requiere el plan Builder o superior, y solo quien es propietario de la app puede hacer la conexión inicial. Si tu cuenta configuró la integración anterior de exportación unidireccional a GitHub, el panel de GitHub tiene un enlace para desconectarla y reconectar con sincronización bidireccional; el camino unidireccional nunca trae nada de vuelta al editor, que es exactamente la dirección que necesita la localización.

Para trabajar en local, clona el repositorio, ejecuta npm install, instala la CLI de Base44 y luego base44 login y base44 link para apuntar el clon hacia su app. base44 dev ejecuta el frontend contra un backend local. Fusionar tu rama local con main es lo que la sincroniza de vuelta.

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

Significa que las cadenas traducidas nunca viven en un servicio alojado al que tu app tenga que llamar o del que tengas que exportar nada. Viven en src/locales/de.json junto a src/pages/Home.jsx, versionadas en los mismos commits, revisadas en los mismos pull requests y desplegadas con el mismo clic en Publish.

Las formas alternativas tienen un coste específico en Base44. Un widget de runtime que traduce la página en el navegador deja el código fuente intacto, así que el repositorio sigue diciendo que la app es en inglés, y cada visitante paga el retraso de la traducción al cargar. Una herramienta de traducción alojada con su propio editor guarda la verdad fuera del repositorio, así que la sincronización bidireccional que construyó Base44 termina sincronizando un codebase que no contiene los idiomas. Ambas ponen un segundo sistema entre tú y un texto que ya vive en archivos que son tuyos.

El enfoque repo-native usa la sincronización tal como fue diseñada. Los catálogos son archivos. Los archivos se registran en commits. Los archivos con commit llegan a main. main llega al editor. Ese es todo el pipeline, y nada de él es específico de la localización.

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

Conecta el repositorio en la app y ejecuta la conversión una vez. La conversión encuentra las cadenas literales en tus componentes y funciones de backend, les asigna claves, conecta una biblioteca de runtime como i18next o Lingui si el proyecto no tiene ninguna, y abre un pull request en tu repositorio con el catálogo de origen y los primeros idiomas de destino. Ese pull request es todo el traspaso. Revísalo en GitHub como cualquier otro cambio, fusiónalo a main, y Base44 lo refleja en el editor.

A partir de ahí, los push jobs traducen las nuevas unidades del catálogo. Cuando le pides a Base44 una función nueva y la sincronización hace commit de ella, las nuevas claves del catálogo de origen se traducen y se entregan como un pull request. Fusiónalo, haz clic en Publish, y la función queda disponible en todos los idiomas. Nada de tus hábitos de prompting tiene que cambiar, y nada en tu app llama a un servicio externo en tiempo de ejecución.

El mismo enfoque funciona en Lovable, Bolt, v0 y Replit, y la mecánica es idéntica porque los cuatro te entregan un proyecto de front-end convencional. La guía de Lovable tiene más detalle sobre la estructura de catálogos, la guía de Bolt cubre el paso de exportación para un builder sin sincronización nativa, y la guía de Vite para el stack clásico de Lovable es la más parecida al output de React y Vite de Base44 a nivel de código. Si estás comparando builders en lugar de estar ya comprometido con uno, el resumen para vibe coders es mejor punto de partida.

¿Qué cadenas viven en las funciones de backend?

Todo lo que un usuario lee y se genera del lado del servidor. Un error de validación devuelto por una función, el asunto de un correo que envía, el cuerpo de un PDF que genera, el texto de una notificación. Esas cadenas nunca aparecen como JSX, así que un catálogo de front-end no las contiene y un widget de runtime no puede verlas.

El patrón es el mismo que en el cliente. Lee el locale solicitado de la petición entrante, carga el catálogo de ese locale del lado de la función, y comparte el espacio de nombres de claves con el cliente para que un mensaje signifique lo mismo en la UI y en una respuesta de API. Como el directorio functions/ está en el repositorio, la conversión trata esos archivos como cualquier otro origen y los catálogos se sitúan junto a ellos.

¿Y el contenido dentro de las entidades?

Este es el límite específico de Base44. Las entidades son tu modelo de datos, gestionado dentro de Base44, y con la sincronización bidireccional no forman parte del repositorio. Un registro como el nombre de un producto, la descripción de un servicio o un artículo de ayuda es dato, no texto de interfaz, y ningún catálogo lo va a contener jamás.

El contenido de datos necesita una dimensión de idioma en la propia entidad: un campo de locale, o un campo por idioma, y consultas que lean el locale del visitante. La configuración es la misma que describimos para el contenido de base de datos en apps de Lovable, y es una decisión de modelo de datos que tomas en el editor de entidades de Base44, no una decisión de herramienta de localización. Planifícalo desde el principio, porque añadir a posteriori un campo de idioma a una entidad con registros existentes cuesta más trabajo que añadirlo a una entidad nueva.

¿Y si estabas en Lovalingo?

Lovalingo cerró a finales de agosto de 2026, y sus casos de uso publicados incluían Base44 junto con Lovable, v0 y Bolt. Cualquiera que haya localizado una app de Base44 a través de esa herramienta necesita un lugar donde llevar esas cadenas. Eso es una migración, no una configuración desde cero: primero exporta, después convierte. 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.

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

Confirma que la sincronización es bidireccional, no la exportación heredada. Abre el panel de GitHub en Base44 y comprueba que indica un repositorio conectado; si te ofrece el enlace «¿Buscas la configuración anterior?», estás en el camino unidireccional y necesitas reconectar.

Confirma que tu rama por defecto es main. Base44 solo refleja esa rama de vuelta, así que un pull request fusionado en cualquier otra nunca llega al editor.

Busca una biblioteca de runtime. Si en algún momento le pediste idiomas a Base44, es posible que haya añadido i18next o un contexto hecho a mano; la conversión mantiene lo que ya hay y lo alimenta.

Decide dónde va a obtener su campo de idioma el contenido de las entidades antes de añadir registros en un segundo idioma. Los catálogos no van a resolver esta parte por ti.

Revisa tu enrutamiento. Las páginas de Base44 se basan en archivos, así que un prefijo de locale en la URL es una decisión de enrutamiento que tomas una sola vez, y determina cómo ven los buscadores cada idioma. La guía de selector de idioma y hreflang cubre las opciones y se aplican directamente.

Por dónde empezar

Activa la sincronización bidireccional con GitHub en Base44 si aún no está activada, confirma que la rama es main, y conecta el repositorio en la app. El primer pull request convierte el codebase. Todo lo que viene después es un merge, un clic en Publish y los idiomas que pediste. La página de integración de Lovable describe el mismo flujo para un builder con una ruta dentro del editor, y la mayor parte de lo que se explica ahí se aplica a Base44 sin cambios.