Le pull request di traduzione rompono la sync GitHub di Lovable?

No, una pull request di traduzione non rompe la sync GitHub di Lovable, a patto che faccia merge sull'unico branch che Lovable sta sincronizzando. Lovable modifica un solo branch alla volta e rilegge nel progetto i commit mergiati, quindi una pull request di traduzione è semplicemente un altro commit che arriva su quel branch. globalize.now è infrastruttura di localizzazione basata su IA che consegna le traduzioni come pull request sul tuo repository: i due sistemi si incontrano in un normale merge Git e in nessun altro punto. I casi che vanno storti sono specifici e documentati, e in questo post li vediamo uno per uno.

Come funziona davvero la sync GitHub di Lovable?

È bidirezionale e single-branch. La documentazione di Lovable dice che modifica e sincronizza un branch alla volta, di default il branch predefinito del repository, di solito main. Le modifiche fatte in Lovable vengono committate su quel branch. I commit pushati su quel branch su GitHub vengono riletti da Lovable.

Due dettagli contano per qualsiasi cosa scriva sul tuo repo dall'esterno di Lovable.

Il pull dipende da una notifica. Lovable riceve una notifica di push da GitHub e aggiorna il progetto. Secondo la stessa documentazione, se quella notifica non arriva, i commit di quel push non compaiono in Lovable. Il rimedio documentato è pushare un altro commit, così parte una nuova notifica. Se fai il merge di una pull request di traduzione e l'editor mostra ancora l'inglese, controlla prima questo.

Puoi cambiare il branch sincronizzato. Le impostazioni GitHub del progetto includono un selettore di branch. Un branch creato da lì parte dal branch attualmente attivo, non automaticamente da main. Dopo il cambio, Lovable modifica e sincronizza quel branch. Tutto ciò che viene mergiato su main da quel momento è invisibile all'editor finché non viene mergiato nel branch su cui si trova Lovable.

Se di questa sezione ricordi una sola frase, che sia questa: la pull request di traduzione deve atterrare sul branch indicato dal selettore.

Cosa succede quando GitHub rifiuta un push di Lovable?

Lovable parcheggia la modifica su un branch chiamato lovable-sync invece di perderla. Secondo la documentazione di Lovable, succede quando GitHub rifiuta un push per conflitti o per regole di branch protection; a quel punto fai il merge di lovable-sync nel tuo branch protetto attraverso la normale review.

Una rete di sicurezza correlata: se il branch che Lovable sta sincronizzando viene eliminato su GitHub, Lovable sposta il progetto su un nuovo branch chiamato lovable-fallback. Eliminare il repository stesso, invece, interrompe la connessione e la sync, mentre rinominarlo no.

Niente di tutto questo riguarda solo le traduzioni. È il comportamento atteso da un secondo autore che scrive accanto a Lovable, e una pull request di traduzione è un secondo autore educato: arriva come pull request rivedibile e non pusha mai direttamente su un branch protetto.

Dove si inserisce una pull request di traduzione?

Tra i commit di Lovable e il tuo pulsante di merge. Il flusso è questo, in un progetto Lovable che ha già installato la skill lovable-i18n, con le regole di istruzione nella knowledge base di Lovable che fanno sì che le nuove stringhe vengano sempre racchiuse nelle macro.

1. Lovable scrive una feature e avvolge le nuove stringhe nelle macro di Lingui. Committa sul branch sincronizzato.
2. Un workflow GitHub estrae le stringhe avvolte nei cataloghi PO sotto src/locales/ e committa la sync. Lovable non ha un terminale, quindi l'estrazione deve girare su GitHub e non nell'editor.
3. La conversione è una tantum e avviene nell'app: connetti il repository e globalize.now converte la codebase una sola volta, consegnando il catalogo come pull request. Da lì in poi, i job di push traducono le nuove unità del catalogo e consegnano anche i cataloghi tradotti come pull request.
4. Fai il merge della pull request sul branch sincronizzato. Lovable recepisce il merge commit e l'app ora mostra la nuova lingua.

Nota cosa manca: nessun passaggio di import in Lovable, nessun export da una dashboard web, nessun widget che carica le traduzioni a runtime. I file tradotti sono semplici file nel tuo repo, ed è proprio l'argomento di localizzare un'app Lovable senza dashboard; i passaggi esatti per connetterti sono nella pagina dell'integrazione con Lovable.

Lovable e una pull request di traduzione possono andare in conflitto?

Sì, nel senso ordinario di Git, ed è raro se le pull request restano di breve durata. Per un conflitto servono due autori che cambiano le stesse righe dello stesso file tra il branching e il merge.

L'unica sovrapposizione realistica è il catalogo PO. Quando Lovable aggiunge una stringa, accoda un nuovo messaggio a ogni src/locales/*/messages.po con traduzione vuota, quindi l'app ripiega sul testo sorgente. La pull request di traduzione compila il testo tradotto per i messaggi già presenti nel catalogo quando è stata aperta. Se Lovable accoda nuovi messaggi in fondo al file mentre la pull request modifica voci più in alto nello stesso file, Git fa il merge di entrambi senza problemi. Se toccano la stessa voce, trovi un marker di conflitto.

Tre abitudini tengono piccola quella finestra.

Fai il merge delle pull request di traduzione lo stesso giorno in cui vengono aperte. Una pull request ferma per una settimana mentre Lovable rilascia dieci feature è l'unico modo in cui la situazione diventa caotica.

Non modificare mai a mano i commenti di riferimento sulle voci del catalogo. Il workflow di estrazione rigenera le righe #. e #:: se risolvi un conflitto, tieni la voce con il testo tradotto e lascia che la prossima estrazione riscriva i commenti.

Aggiorna un branch rimasto indietro prima del merge. Se il branch della pull request è rimasto indietro, aggiornalo prima:

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

Risolvi tutto ciò che Git segnala, fai push ed esegui il merge. Poiché i cataloghi sono testo e ogni messaggio è un blocco, il conflitto da risolvere è quasi sempre una voce, non l'intero file.

Cosa cambia con la branch protection?

Aggiunge una review, e la review è già il modello. Una traduzione consegnata come pull request passa attraverso gli eventuali check obbligatori e le approvazioni previsti dal tuo branch. I push di Lovable rifiutati da un branch protetto arrivano su lovable-sync, di cui fai il merge con la stessa review. I due percorsi sono separati e nessuno dei due blocca l'altro.

Se proteggi il branch predefinito e lasci che Lovable lo modifichi, metti in conto di fare il merge di lovable-sync ogni tanto: è il comportamento documentato di Lovable, non un problema delle traduzioni. Se ti dà fastidio, le opzioni sono allentare la regola di protezione per l'autore di Lovable oppure passare nelle impostazioni del progetto a un branch sincronizzato dedicato. In entrambi i casi, punta la pull request di traduzione al branch che Lovable sta sincronizzando.

Perché con i widget di traduzione a runtime questa domanda non esisteva?

Perché non scrivevano mai sul tuo repository. Lovalingo, che ha chiuso il 31 agosto 2026, traduceva la pagina renderizzata nel browser: nel repo non c'erano file di locale né pull request di cui fare il merge. I team passati ai cataloghi nel repository con la guida alla migrazione incontrano per la prima volta la sincronizzazione GitHub di Lovable come sistema a due autori.

È un compromesso, ed è quello giusto: il testo tradotto è tuo, versionato e indicizzabile, invece di essere affittato al momento del rendering. Richiede però di sapere su quale branch si trova Lovable. Per l'altra metà del problema, cioè i cataloghi che restano indietro rispetto al codice, leggi perché le traduzioni si rompono a ogni rilascio. Se la tua app salva contenuti anche in un database, quel livello vive fuori dal repo: ne parla localizzare i contenuti del database in un'app Lovable.

Tieni entrambi gli autori sullo stesso branch

Controlla il selettore di branch nelle impostazioni GitHub del progetto, fai il merge delle pull request di traduzione su quel branch e tratta lovable-sync come un'attività da svolgere, non come un errore. Se sviluppi in Lovable e vuoi che il lavoro di traduzione sia gestito al posto tuo anziché mantenerlo a mano, la pagina per i vibe coder è la panoramica e i prezzi hanno una pagina dedicata.