¿Los pull requests de traducción rompen la sincronización de Lovable con GitHub?

No, un pull request de traducción no rompe la sincronización de Lovable con GitHub, siempre que se fusione en la única branch que Lovable está sincronizando. Lovable edita una sola branch a la vez y trae de vuelta al proyecto los commits fusionados, así que un pull request de traducción es un commit más que llega a esa branch. globalize.now es infraestructura de localización impulsada por IA que entrega las traducciones como pull request contra tu repositorio, de modo que ambos sistemas se encuentran en un merge normal de Git y en ningún otro punto. Los casos que fallan son concretos y están documentados; este post los repasa.

¿Cómo funciona realmente la sincronización de Lovable con GitHub?

Es bidireccional y de una sola branch. La documentación de Lovable indica que edita y sincroniza una branch a la vez, por defecto la branch por defecto del repositorio, normalmente main. Los cambios que haces en Lovable se commitean en esa branch. Los commits que se pushean a esa branch en GitHub se traen de vuelta a Lovable.

Dos detalles importan para cualquier cosa que escriba en tu repo desde fuera de Lovable.

El pull depende de una notificación. Lovable recibe de GitHub una notificación de push y actualiza el proyecto. Según la misma documentación, si esa notificación no llega, los commits de ese push no aparecen en Lovable. La solución documentada es hacer push de otro commit para que se dispare una notificación nueva. Si fusionas un pull request de traducción y el editor sigue en inglés, esto es lo primero que debes comprobar.

Puedes cambiar la branch sincronizada. Los ajustes de GitHub del proyecto incluyen un selector de branch. Una branch creada ahí parte de la branch que esté activa en ese momento, no automáticamente de main. Una vez que cambias, Lovable edita y sincroniza esa branch. Todo lo que se fusione en main a partir de entonces es invisible para el editor hasta que se fusione en la branch en la que está Lovable.

Si te quedas con una sola frase de esta sección: el pull request de traducción tiene que llegar a la branch que muestra el selector.

¿Qué pasa cuando GitHub rechaza un push de Lovable?

Lovable aparca el cambio en una branch llamada lovable-sync en lugar de perderlo. Según la documentación de Lovable, esto ocurre cuando GitHub rechaza un push por conflictos o por reglas de protección de branch, y después fusionas lovable-sync en tu branch protegida mediante tu proceso de revisión habitual.

Una red de seguridad relacionada: si la branch que Lovable sincroniza se elimina en GitHub, Lovable cambia el proyecto a una branch nueva llamada lovable-fallback. Y eliminar el repositorio en sí rompe la conexión y detiene la sincronización, mientras que renombrarlo no.

Nada de esto es específico de las traducciones. Así se espera que se comporte un segundo escritor alrededor de Lovable, y un pull request de traducción es un segundo escritor respetuoso: llega como pull request revisable y nunca hace push directo a una branch protegida.

¿Dónde encaja un pull request de traducción?

Entre los commits de Lovable y tu botón de merge. El flujo es así en un proyecto de Lovable que ya tiene instalado el Skill lovable-i18n, con las reglas de instrucciones en el knowledge de Lovable para que las cadenas nuevas sigan envueltas.

1. Lovable escribe una feature y envuelve las cadenas nuevas en macros de Lingui. Hace commit en la branch sincronizada.
2. Un workflow de GitHub extrae las cadenas envueltas a los catálogos PO bajo src/locales/ y hace commit de la sincronización. Lovable no tiene terminal, así que la extracción tiene que ejecutarse en GitHub y no en el editor.
3. La conversión se hace una sola vez y desde la app: conectas el repositorio y globalize.now convierte el codebase una vez, entregando el catálogo como pull request. Después, los jobs de push traducen las unidades nuevas del catálogo y entregan también los catálogos traducidos como pull requests.
4. Fusionas el pull request en la branch sincronizada. Lovable trae el merge commit y la app ya muestra el idioma nuevo.

Fíjate en lo que falta: ningún paso de importación en Lovable, ninguna exportación desde un dashboard web y ningún widget que cargue traducciones en runtime. Los archivos traducidos son archivos normales en tu repo, que es el argumento detrás de localizar una app de Lovable sin dashboard, y los pasos exactos de conexión están en la página de la integración con Lovable.

¿Pueden chocar Lovable y un pull request de traducción?

Sí, en el sentido habitual de Git, y es poco frecuente si mantienes los pull requests de corta duración. Un conflicto requiere que ambos escritores cambien las mismas líneas del mismo archivo entre que se crea la branch y se fusiona.

El único solapamiento realista es el catálogo PO. Cuando Lovable añade una cadena, agrega un mensaje nuevo a cada src/locales/*/messages.po con la traducción vacía, así que la app recurre al texto de origen. El pull request de traducción rellena el texto traducido de los mensajes que ya estaban en el catálogo cuando se abrió. Si Lovable añade mensajes nuevos al final de un archivo mientras el pull request edita entradas anteriores del mismo archivo, Git fusiona ambos sin quejarse. Si los dos tocan la misma entrada, aparece un marcador de conflicto.

Tres hábitos mantienen pequeña esa ventana.

Fusiona los pull requests de traducción el mismo día que se abren. Un pull request que lleva una semana parado mientras Lovable lanza diez features es la única forma de que esto se vuelva ruidoso.

Nunca edites a mano los comentarios de referencia de las entradas del catálogo. El workflow de extracción regenera las líneas #. y #:, así que, si resuelves un conflicto, conserva la entrada con el texto traducido y deja que la siguiente extracción reescriba los comentarios.

Pon al día una branch desfasada antes de fusionar. Si la branch del pull request se ha quedado atrás, actualízala primero:

git fetch origin
git checkout <translation-branch>
git merge origin/<synced-branch>

Resuelve lo que marque Git, haz push y fusiona. Como los catálogos son texto y cada mensaje es un bloque, el conflicto que resuelves casi siempre es una entrada, no el archivo entero.

¿Qué cambia la protección de branches?

Añade revisión, y la revisión ya es el modelo. Una traducción entregada como pull request pasa por los checks obligatorios y las aprobaciones que tenga tu branch. Los push de Lovable que una branch protegida rechaza llegan a lovable-sync, que fusionas con la misma revisión. Los dos caminos son independientes y ninguno bloquea al otro.

Si proteges la branch por defecto y además dejas que Lovable la edite, cuenta con fusionar lovable-sync de vez en cuando; es el comportamiento documentado de Lovable, no un problema de las traducciones. Si te molesta, las opciones son relajar la regla de protección para el autor de Lovable o cambiar la branch sincronizada a una dedicada en los ajustes del proyecto. En ambos casos, apunta el pull request de traducción a la branch que Lovable esté sincronizando.

¿Por qué esta pregunta no existía con los widgets de traducción en runtime?

Porque nunca escribían en tu repositorio. Lovalingo, que cerró el 31 de agosto de 2026, traducía la página renderizada en el navegador, así que no había archivos de locale en el repo ni pull requests que fusionar. Los equipos que pasaron a catálogos versionados en el repo con la guía de migración se encuentran por primera vez con la sincronización de Lovable con GitHub como un sistema de dos escritores.

Ese es el intercambio, y es el correcto: el texto traducido es tuyo, versionado e indexable, en lugar de alquilado en el momento del render. Eso sí, exige saber en qué branch está Lovable. Para la otra mitad de mantener traducida una app de Lovable, cuando los catálogos van por detrás del código, consulta por qué las traducciones se rompen cada vez que lanzas. Si tu app también guarda contenido en una base de datos, esa capa vive fuera del repo; localizar el contenido de la base de datos en una app de Lovable lo cubre.

Mantén a los dos escritores en una sola branch

Revisa el selector de branch en los ajustes de GitHub de tu proyecto, fusiona los pull requests de traducción en esa branch y trata lovable-sync como una tarea pendiente, no como un error. Si desarrollas con Lovable y prefieres que te resuelvan la traducción en lugar de mantenerla tú, la página de vibe coders ofrece la visión general y los precios están en su propia página.