Pubblicato8 luglio 2026

La tua app Lovable resta in inglese con SSR

Punti chiave

I nuovi progetti Lovable vengono ora rilasciati su TanStack Start con SSR, rompendo l'approccio a widget runtime che la maggior parte delle guide insegna ancora.
Con SSR il server renderizza prima l'inglese, quindi i widget lato client mostrano un flash di inglese e i crawler indicizzano la lingua sbagliata.
I catalog PO di Lingui committati renderizzano la lingua corretta sul server e ti danno pagine indicizzabili per ogni locale.
Memorizza il locale attivo in un cookie, non in localStorage, così il server può risolverlo prima del rendering.
globalize.now estrae le stringhe, genera i catalog e li sincronizza a ogni push, così non gestisci mai i file di traduzione a mano.

Se la tua app Lovable viene renderizzata in inglese indipendentemente dalla lingua che aggiungi, la causa è il cambio di stack: da metà maggio 2026 i nuovi progetti Lovable usano TanStack Start con rendering lato server, non la vecchia app single-page con React e Vite. globalize.now è un’infrastruttura di localizzazione basata su IA che si adatta a questo nuovo stack estraendo le stringhe in cataloghi PO Lingui versionati, così il server renderizza la lingua corretta invece di sostituirla nel browser. La soluzione non è un altro widget. È spostare la traduzione nella repo, dove il server può renderizzarla e i motori di ricerca indicizzarla.

Perché localizzare la tua app Lovable è diventato improvvisamente più difficile?

Perché le fondamenta sono cambiate e i vecchi consigli non bastano più. La maggior parte delle guide su come «tradurre la tua app Lovable» presume un’app single-page renderizzata lato client, dove un widget può riscrivere il DOM dopo il caricamento senza che nessuno se ne accorga. Per i nuovi progetti, questa premessa non è più valida.

Lovable ha spostato i nuovi progetti su TanStack Start con SSR, così i crawler ricevono HTML completamente renderizzato già alla prima richiesta, senza dover eseguire JavaScript. È un vero vantaggio per la SEO, ma cambia completamente il modo in cui deve funzionare la traduzione. Quando la prima risposta è già renderizzata, tradurla dopo nel browser è troppo tardi.

Se hai creato l’app negli ultimi mesi e hai aggiunto un widget di traduzione runtime, stai vedendo il sintomo: un flash in inglese, poi la sostituzione. L’integrazione di Lovable per globalize.now esiste proprio per gestire il problema al livello corretto.

Che cosa è cambiato davvero nel passaggio di Lovable a TanStack Start?

Il modello di rendering è passato dal lato client al lato server. Prima Lovable generava app single-page basate su React e Vite, distribuite come file statici e renderizzate interamente nel browser. Ora la base è TanStack Start, un framework React full-stack con SSR, SSG e CSR per route, oltre a server function affiancate ai componenti.

Per la localizzazione contano tre aspetti. Primo: l’HTML viene prodotto sul server prima di raggiungere il browser, quindi la lingua viene decisa lato server. Secondo: il routing ora supporta veri URL per locale. Terzo: tutto ciò che dipende da API disponibili solo nel browser per scegliere la lingua viene eseguito dopo che il server ha già deciso la lingua.

È il terzo punto a causare la maggior parte delle configurazioni rotte. Un locale salvato in localStorage è invisibile al server, quindi il server renderizza la lingua predefinita e il client la corregge un attimo dopo.

Perché i widget di traduzione runtime mostrano un flash in inglese con SSR?

Perché traducono dopo che il server ha già inviato la pagina in inglese. Sul nuovo stack la sequenza è questa: il server renderizza l’HTML nella lingua predefinita, il browser lo visualizza, poi il JavaScript del widget viene caricato e riscrive il testo. L’intervallo tra la visualizzazione e la riscrittura è il flash in inglese, ed è ormai un problema strutturale, non di ottimizzazione.

Il costo per la SEO è peggiore del flash. Un crawler legge la prima risposta e passa oltre. Se il testo tradotto compare solo dopo l’esecuzione del JavaScript lato client, il crawler indicizza l’inglese per ogni locale e non ottieni pagine per lingua da posizionare. L’intero motivo per cui Lovable è passato a SSR e HTML indicizzabile viene vanificato traducendo nel browser.

I cataloghi versionati evitano il problema alla radice. Quando le stringhe di traduzione vivono nella repo, TanStack Start renderizza il locale richiesto sul server, quindi la prima risposta è già corretta. Questa è la differenza duratura tra un’infrastruttura che vive nella codebase e un widget che ci gira sopra, ed è il motivo per cui strumenti runtime come Weglot si adattano meglio al vecchio modello SPA che al nuovo. Per un approfondimento sul problema della sincronizzazione, consulta perché le traduzioni Lovable si rompono a ogni push.

Come rendo multilingue un’app Lovable con TanStack Start?

Sposta la traduzione sul server e mantieni i cataloghi nella repo. In concreto, sul nuovo stack sono quattro passaggi e nessuno richiede di modificare a mano i file dei locali.

Aggiungi la skill lovable-i18n e lascia che Lovable configuri l’i18n. Nel tuo workspace Lovable, aggiungi la skill lovable-i18n, poi chiedi a Lovable di configurare l’internazionalizzazione. Installa Lingui, estrae le stringhe UI hardcoded nei message catalog e configura il provider. Fuori dall’editor, la stessa configurazione si installa con npx skills add globalize-now/globalize-skills (aggiungi --all per installarla per tutti gli agent).
Gestisci le locale con il parametro di percorso opzionale di TanStack. TanStack Router usa {-$locale} per i parametri di percorso opzionali, quindi una route definita come /{-$locale}/about corrisponde sia a /about per la lingua predefinita sia a /es/about per lo spagnolo. Ogni lingua ha così un URL distinto e indicizzabile, invece di un unico URL il cui testo cambia nel browser.
Risolvi la locale sul server, non in localStorage. Salva la lingua attiva in un cookie, così l’handler SSR può leggerla dalla request. Con Lingui, il server chiama setupLocaleFromRequest() prima di creare il router, mentre l’hydration client chiama dynamicActivate() con la locale fornita dal server prima del rendering. Lo stesso valore su entrambi i lati significa niente hydration mismatch e niente flash.
Tieni i cataloghi nel repository e sincronizzali a ogni push. I cataloghi PO sono file versionati, non il runtime di un vendor. Mentre continui a sviluppare in Lovable e compaiono nuove stringhe, vanno estratte e tradotte di nuovo: è la parte che, se gestita a mano, finisce per marcire. È il lavoro che globalize.now svolge automaticamente, così i cataloghi restano aggiornati senza un passaggio manuale di export.

// server: resolve locale before the router exists
const locale = getLocaleFromCookie(request) ?? "en";
await setupLocaleFromRequest(locale);

// client: activate the SAME locale before first render
await dynamicActivate(serverLocale);

Poiché è una procedura reale, passo dopo passo, con output versionato, si comporta come normale codice sotto controllo versione: è revisionabile in una pull request, confrontabile con un diff e portabile se un giorno abbandoni Lovable.

Dove si colloca globalize.now nello stack i18n di TanStack Start?

Si colloca un livello sotto la libreria runtime e sopra il motore di traduzione. TanStack Start e Lingui servono le traduzioni a runtime; DeepL o un LLM producono le traduzioni vere e proprie. globalize.now è l’infrastruttura intermedia: genera le chiavi e i cataloghi PO e li mantiene sincronizzati, così il runtime ha sempre qualcosa di corretto da renderizzare.

Per chi costruisce app con Lovable, l’effetto pratico è smettere di fare da babysitter ai file delle locale. Installi la skill, chiedi una volta a Lovable di configurare tutto e, a ogni push successivo, le nuove stringhe vengono estratte, i cataloghi compilati e la modifica aperta come una normale PR. Niente avanti e indietro nella dashboard, niente nuovo export, niente disallineamento tra ciò che mostra l’app e ciò che contengono i cataloghi.

C’è un solo piano: 20 € al mese per workspace, inclusi 20 € di credito per le traduzioni — circa 200.000 parole al mese — poi utilizzo a consumo basato sui token, alla stessa tariffa per carattere. Nessun costo per seat o per lingua; all’iscrizione ricevi 5 € di credito e non serve una carta. Una tipica app Lovable con cinque locale rientra comodamente in questa quota. Per i dettagli dal lato developer, le pagine globalize.now per sviluppatori e vibe coder vanno più a fondo, mentre la panoramica del prodotto copre il resto dello stack.

La tua app Lovable è bloccata in inglese perché la traduzione avviene nel posto sbagliato: nel browser, dopo che il server ha già scelto una lingua. Spostala nel repository e il server renderizza la lingua corretta già alla prima request. globalize.now gestisce estrazione e sincronizzazione: la configuri una volta e resta aggiornata a ogni push.

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

Prova globalize.now gratis

È stato utile?

Domande frequenti

Lovable ha davvero cambiato il proprio stack, e questo rompe le traduzioni?

Sì. Da metà maggio 2026, i nuovi progetti Lovable vengono rilasciati su TanStack Start con rendering lato server invece di un'app a pagina singola in React e Vite. Questo non rompe le traduzioni di per sé, ma rompe l'approccio a widget runtime che molte guide consigliano ancora. Con SSR il server invia prima l'HTML in inglese completamente renderizzato, quindi un widget lato client sostituisce il testo dopo il caricamento, causando un flash di inglese e lasciando che i crawler indicizzino la lingua sbagliata.

Perché non aggiungere semplicemente un widget di traduzione alla mia app Lovable?

Un widget runtime traduce nel browser dopo che il server ha già renderizzato l'HTML in inglese. Sul nuovo stack SSR questo significa che i visitatori vedono brevemente l'inglese prima della sostituzione, e i motori di ricerca indicizzano la versione inglese perché il testo tradotto non esiste mai nella prima risposta. I catalog di traduzione committati renderizzano la lingua corretta sul server, quindi non c'è flash e ogni locale è una pagina reale e indicizzabile.

Come funzionano gli URL per locale in TanStack Start?

TanStack Router usa un parametro di percorso opzionale scritto come {-$locale}, quindi una rotta come /{-$locale}/about corrisponde sia a /about per la tua lingua predefinita sia a /es/about per lo spagnolo. Questo ti dà URL puliti per ogni locale che un crawler può indicizzare separatamente, che è esattamente il punto di spostare la traduzione sul server invece che su un widget client.

Dove dovrebbe la mia app Lovable memorizzare la lingua attiva in SSR?

Memorizzala in un cookie, non in localStorage. localStorage non è leggibile sul server, quindi il server non può sapere quale lingua renderizzare e ottieni un flash della lingua sbagliata a ogni caricamento. Un cookie viene inviato con la richiesta, così il handler SSR può risolvere il locale prima del rendering e passare lo stesso valore al client per l'hydration.

Cosa fa concretamente globalize.now per un'app Lovable?

globalize.now è un'infrastruttura di localizzazione basata su IA. Estrae le stringhe hardcoded della UI dalla tua codebase Lovable, genera chiavi di traduzione e catalog PO di Lingui, e li mantiene sincronizzati a ogni push su Git. Lo installi come skill di Lovable e chiedi a Lovable di configurare l'i18n una volta con un prompt; dopodiché i catalog vivono nel tuo repository e si aggiornano automaticamente man mano che la tua app cambia.

← Torna al blog