Les pull requests de traduction cassent-elles la synchro GitHub de Lovable ?

Non, une pull request de traduction ne casse pas la synchro GitHub de Lovable, à condition d'être mergée sur l'unique branche que Lovable synchronise. Lovable édite une seule branche à la fois et récupère les commits mergés dans le projet : une pull request de traduction n'est donc qu'un commit de plus qui arrive sur cette branche. globalize.now est une infrastructure de localisation propulsée par l'IA qui livre les traductions sous forme de pull request sur votre dépôt ; les deux systèmes se rencontrent donc lors d'un merge Git normal, et nulle part ailleurs. Les cas qui tournent mal sont précis et documentés, et cet article les passe en revue.

Comment fonctionne réellement la synchro GitHub de Lovable ?

Elle est bidirectionnelle et limitée à une seule branche. La documentation de Lovable indique qu'il édite et synchronise une branche à la fois, par défaut la branche par défaut du dépôt, généralement main. Les modifications faites dans Lovable sont commitées sur cette branche. Les commits poussés sur cette branche côté GitHub sont récupérés par Lovable.

Deux détails comptent pour tout ce qui écrit dans votre repo depuis l'extérieur de Lovable.

La récupération repose sur une notification. Lovable reçoit une notification de push de GitHub et met à jour le projet. Selon la même documentation, si cette notification n'arrive jamais, les commits de ce push n'apparaissent pas dans Lovable. Le correctif documenté consiste à pousser un autre commit pour déclencher une nouvelle notification. Si vous mergez une pull request de traduction et que l'éditeur affiche toujours l'anglais, c'est la première chose à vérifier.

Vous pouvez changer la branche synchronisée. Les paramètres GitHub du projet incluent un sélecteur de branche. Une branche créée à cet endroit part de la branche actuellement active, pas automatiquement de main. Une fois le changement fait, Lovable édite et synchronise cette branche à la place. Tout ce qui est mergé sur main ensuite reste invisible pour l'éditeur tant que ce n'est pas mergé dans la branche sur laquelle Lovable se trouve.

Si vous ne deviez retenir qu'une phrase de cette section : la pull request de traduction doit atterrir sur la branche affichée par le sélecteur.

Que se passe-t-il quand GitHub rejette un push de Lovable ?

Lovable met la modification de côté sur une branche appelée lovable-sync plutôt que de la perdre. D'après la documentation de Lovable, cela arrive lorsque GitHub rejette un push à cause de conflits ou de règles de protection de branche ; vous mergez ensuite lovable-sync dans votre branche protégée via votre processus de revue habituel.

Un filet de sécurité voisin : si la branche que Lovable synchronise est supprimée sur GitHub, Lovable bascule le projet sur une nouvelle branche nommée lovable-fallback. Quant à la suppression du dépôt lui-même, elle rompt la connexion et arrête la synchro, alors qu'un simple renommage ne change rien.

Rien de tout cela n'est propre aux traductions. C'est le comportement attendu d'un second contributeur autour de Lovable, et une pull request de traduction est un second contributeur bien élevé : elle arrive sous forme de pull request relisible et ne pousse jamais directement sur une branche protégée.

Où se place une pull request de traduction ?

Entre les commits de Lovable et votre bouton de merge. Le flux ressemble à ceci dans un projet Lovable qui a déjà la compétence lovable-i18n installée, avec les règles d'instruction dans la base de connaissances de Lovable qui maintiennent l'encapsulation des nouvelles chaînes.

1. Lovable écrit une fonctionnalité et encapsule les nouvelles chaînes dans des macros Lingui. Il commite sur la branche synchronisée.
2. Un workflow GitHub extrait les chaînes encapsulées dans les catalogues PO sous src/locales/ et commite la synchronisation. Lovable n'a pas de terminal : l'extraction doit donc s'exécuter dans GitHub plutôt que dans l'éditeur.
3. La conversion est ponctuelle et se fait dans l'app : vous connectez le dépôt et globalize.now convertit le code une seule fois, en livrant le catalogue sous forme de pull request. Ensuite, des jobs de push traduisent les nouvelles unités du catalogue et livrent aussi les catalogues traduits sous forme de pull requests.
4. Vous mergez la pull request dans la branche synchronisée. Lovable récupère le commit de merge, et l'app affiche désormais la nouvelle langue.

Remarquez ce qui manque : pas d'étape d'import dans Lovable, pas d'export depuis un dashboard web, pas de widget qui charge les traductions au runtime. Les fichiers traduits sont de simples fichiers dans votre repo, c'est l'argument de localiser une app Lovable sans dashboard, et les étapes de connexion exactes figurent sur la page d'intégration Lovable.

Lovable et une pull request de traduction peuvent-ils entrer en conflit ?

Oui, au sens habituel de Git, et c'est rare si vos pull requests restent de courte durée. Un conflit exige que les deux contributeurs modifient les mêmes lignes du même fichier entre la création de la branche et le merge.

Le seul chevauchement réaliste concerne le catalogue PO. Quand Lovable ajoute une chaîne, il ajoute un nouveau message à chaque src/locales/*/messages.po avec une traduction vide : l'app retombe alors sur le texte source. La pull request de traduction renseigne le texte traduit des messages qui figuraient déjà dans le catalogue à son ouverture. Si Lovable ajoute de nouveaux messages en fin de fichier pendant que la pull request modifie des entrées plus haut dans le même fichier, Git fusionne les deux sans broncher. Si les deux touchent la même entrée, vous obtenez un marqueur de conflit.

Trois habitudes gardent cette fenêtre étroite.

Mergez les pull requests de traduction le jour de leur ouverture. Une pull request qui traîne une semaine pendant que Lovable livre dix fonctionnalités est le seul moyen de rendre tout cela bruyant.

Ne modifiez jamais à la main les commentaires de référence des entrées du catalogue. Le workflow d'extraction régénère les lignes #. et #: : si vous résolvez un conflit, gardez l'entrée avec le texte traduit et laissez la prochaine extraction réécrire les commentaires.

Remettez une branche en retard à jour avant de merger. Si la branche de la pull request a pris du retard, mettez-la d'abord à jour :

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

Résolvez ce que Git signale, faites un push, puis mergez. Comme les catalogues sont du texte et que chaque message est un bloc, le conflit à résoudre porte presque toujours sur une seule entrée, pas sur tout le fichier.

Qu'est-ce que la protection de branche change ?

Elle ajoute de la revue, et la revue est déjà le modèle. Une traduction livrée sous forme de pull request passe par les checks obligatoires et les approbations de votre branche. Les push de Lovable rejetés par une branche protégée arrivent sur lovable-sync, que vous mergez via la même revue. Les deux chemins sont distincts et aucun ne bloque l'autre.

Si vous protégez la branche par défaut tout en laissant Lovable l'éditer, attendez-vous à devoir merger lovable-sync régulièrement ; c'est le comportement documenté de Lovable, pas un problème de traduction. Si cela vous gêne, vous pouvez assouplir la règle de protection pour l'auteur de Lovable, ou basculer la branche synchronisée vers une branche dédiée dans les paramètres du projet. Dans les deux cas, pointez la pull request de traduction vers la branche que Lovable synchronise.

Pourquoi cette question n'existait-elle pas avec les widgets de traduction runtime ?

Parce qu'ils n'écrivaient jamais dans votre dépôt. Lovalingo, qui a fermé le 31 août 2026, traduisait la page rendue dans le navigateur : il n'y avait donc ni fichiers de locale dans le repo, ni pull requests à merger. Les équipes passées aux catalogues commités grâce au guide de migration découvrent pour la première fois la synchro GitHub de Lovable comme un système à deux contributeurs.

C'est le compromis, et c'est le bon : le texte traduit vous appartient, versionné et indexable, au lieu d'être loué au moment du rendu. Il faut en échange savoir sur quelle branche se trouve Lovable. Pour l'autre moitié du problème, quand les catalogues prennent du retard sur le code, voir pourquoi les traductions cassent à chaque livraison. Si votre app stocke aussi du contenu en base de données, cette couche vit hors du repo ; localiser le contenu d'une base de données dans une app Lovable en traite.

Gardez les deux contributeurs sur une seule branche

Vérifiez le sélecteur de branche dans les paramètres GitHub de votre projet, mergez les pull requests de traduction dans cette branche et traitez lovable-sync comme une tâche à faire plutôt que comme une erreur. Si vous développez dans Lovable et voulez que le travail de traduction soit pris en charge plutôt que maintenu par vos soins, la page vibe coders en donne la vue d'ensemble et la tarification a sa propre page.