Cosa succede davvero quando rendi multilingue un’app Lovable

Chiedi a Lovable di aggiungere una nuova sezione dei prezzi. Lovable genera il componente, lo collega e lo rilascia. La UI inglese è aggiornata. I tuoi cataloghi messages.po continuano a puntare a ciò che c’era prima. Gli utenti francesi vedono il testo vecchio. Quelli tedeschi vedono l’inglese. Nessuno se ne accorge finché non lo segnala un utente reale.

Non è un bug di Lovable. È un disallineamento strutturale. Lovable ottimizza per rilasciare rapidamente la UI. L’i18n richiede di tracciare ogni stringa visibile all’utente in ogni catalogo di ogni lingua, a ogni modifica. Sono due obiettivi in tensione diretta.

Il problema dell’estrazione è continuo, non una tantum. Ogni prompt eseguito da Lovable può creare nuove stringhe. Ogni iterazione modifica contenuti esistenti. Non esiste un checkpoint naturale in cui puoi dire «l’estrazione è finita».

Perché le soluzioni più ovvie non reggono

Un’estrazione una tantum risolve il problema?

No. Puoi eseguire un pass di estrazione delle stringhe dopo la build iniziale di Lovable e creare cataloghi PO puliti. Funziona fino al prompt successivo. Da quel momento devi confrontare manualmente le differenze tra potenzialmente decine di componenti e decine di cataloghi. Basta una stringa mancante nel catalogo messages.po spagnolo e gli utenti spagnoli si ritrovano testo inglese in mezzo a una pagina tradotta: quella che viene chiamata UI in lingue miste, una delle esperienze più dannose per la fiducia che si possa offrire agli utenti.

Gli strumenti di traduzione runtime sono abbastanza validi?

I traduttori runtime come Weglot o i widget di traduzione iniettati via JavaScript risolvono un problema diverso. Traducono i contenuti dopo il caricamento della pagina, quindi per una frazione di secondo gli utenti vedono la lingua originale prima che compaia il contenuto tradotto. Oltre alla cattiva esperienza d’uso, questo crea un Cumulative Layout Shift misurabile, un segnale dei Core Web Vitals che Google usa per classificare le pagine. Stai scambiando un problema di manutenzione invisibile con un problema di performance visibile.

E se chiedessi semplicemente a Lovable di aggiornare i file delle lingue?

Lovable può scrivere nei cataloghi PO se glielo chiedi. Il problema è che devi ricordarti di farlo per ogni stringa, a ogni prompt e per ogni lingua. Il carico cognitivo cresce con ogni lingua che aggiungi. Moltiplicalo per quattro lingue e avrai trasformato ogni prompt sulla UI in un esercizio di coordinamento in quattro passaggi. È esattamente il tipo di attrito che distrugge la velocità per cui valeva la pena usare Lovable.

Come si rompe davvero il ciclo i18n di Lovable

Il pattern è abbastanza ricorrente da avere una forma riconoscibile:

  1. Configurazione iniziale — Aggiungi il supporto multilingue. Funziona. È tutto tradotto. Ti senti a posto.
  2. Prime release — Ti ricordi di aggiornare manualmente i cataloghi PO. È fastidioso, ma gestibile.
  3. Fase di velocità — Inizi a rilasciare più rapidamente. I cataloghi PO iniziano a rimanere indietro. Ti dici che recupererai.
  4. Produzione in lingue miste — Gli utenti nei mercati non anglofoni iniziano a vedere parti in inglese. Arrivano ticket al supporto. Passi un intero ciclo di release a cercare stringhe.
  5. Tassa del refactor — Ogni nuova feature ha ormai un costo i18n nascosto che non esisteva nella versione solo inglese. La velocità di rilascio diminuisce.

La tassa del refactor è la parte di cui nessuno parla quando scrive guide dal titolo «ecco come rendere multilingue un’app Lovable». Le guide mostrano la configurazione iniziale. Non mostrano cosa succede alla release 12.

La soluzione: i18n integrato nel ciclo di push Git

La risposta architetturale corretta è eliminare del tutto i passaggi manuali. Se le traduzioni si aggiornano automaticamente a ogni push, il problema di manutenzione scompare. Non puoi dimenticarti di eseguire l’estrazione se si esegue da sola.

Il workflow è questo:

  1. Collega il progetto Lovable a GitHub. Usa il menu + nel campo della chat, poi GitHub e infine Connect project.
  2. Aggiungi la skill lovable-i18n al workspace. Apri Skills nel workspace Lovable, poi Add, quindi Import from GitHub e incolla https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n. Conferma. Una volta per workspace; è richiesto il ruolo di owner o admin del workspace.
  3. Chiedi a Lovable di configurarlo. Incolla nella chat di Lovable: Set up i18n for my project using the lovable-i18n skill.. Lovable rileva il tuo stack — Vite SPA o TanStack Start — e pone una domanda: lingua sorgente, lingue target, locale nell’URL oppure no, aggiunta della GitHub Action. Rispondi go per usare i valori predefiniti. Installa Lingui, crea i cataloghi PO in src/locales/{locale}/messages.po, racchiude le stringhe nelle macro <Trans> e aggiunge un selettore della lingua.
  4. Rivedi ed esegui il merge. Lovable sincronizza con GitHub; rivedi la diff ed esegui il merge nel tuo branch predefinito.
  5. Collega il repository a globalize.now. Accedi, collega il repository, autorizza l’app GitHub, seleziona il repository Lovable e il branch predefinito, quindi scegli le lingue: oltre 50, incluse quelle RTL.
  6. Continua a costruire in Lovable. Ogni push attiva globalize.now, che apre una pull request di traduzione con i cataloghi PO aggiornati. Esegui il merge e l’app viene rilasciata tradotta.

La proprietà fondamentale è questa: dopo la configurazione, i passaggi di connessione e sincronizzazione non richiedono più nulla da parte tua. Non esegui comandi. Non controlli dashboard. Non approvi code di traduzione. Le nuove stringhe nei componenti generati da Lovable vengono rilevate al push, tradotte e restituite tramite PR prima che tu abbia eseguito il merge del branch. La configurazione passo passo è disponibile nella pagina dell’integrazione Lovable.

Cosa significa per il tuo workflow Lovable

Non devi smettere di usare Lovable. L’architettura è progettata partendo dal presupposto che la tua UI continui a cambiare: è proprio questo il punto. Lovable genera la UI ed esegue la skill lovable-i18n; globalize.now gestisce la sincronizzazione.

Lovable genera i componenti e applica la skill quando ti serve l’i18n. globalize.now controlla l’output a ogni push. I tuoi utenti vedono sempre una UI completa e tradotta, indipendentemente dalla velocità con cui rilasci.

La pagina per vibe coder di globalize.now spiega più nel dettaglio come funziona la configurazione per le app costruite con l’IA. Se stai già eseguendo un’app Next.js o React costruita con Lovable, la pagina per sviluppatori descrive il percorso d’integrazione tecnico.

Per i team che gestiscono già più progetti Lovable, il prezzo per workspace su globalize.now significa che non paghi per lingua o per estrazione delle stringhe: il costo della sincronizzazione resta fisso mentre l’app cresce.

Il peso della manutenzione è reale e cresce nel tempo. Aggiungi la skill lovable-i18n in Lovable: apri Skills nel workspace, poi Add e quindi Import from GitHub. Consulta la guida all’integrazione Lovable o globalize.now.

globalize.now trasforma il testo hardcoded dell'app in file di localizzazione pronti e li mantiene aggiornati mentre rilasci.

Prova globalize.now gratis