Come localizzi un’app v0 senza dashboard?

Localizzi un’app v0 trattando il repository GitHub su cui v0 scrive già come la sede dei cataloghi di traduzione e mantenendoli lì come file committati. È questa scelta a rendere la dashboard superflua, non semplicemente opzionale. globalize.now è un’infrastruttura di localizzazione basata su IA: produce chiavi e file di traduzione, che vengono poi serviti dalla libreria runtime che scegli. v0 ti consegna un codebase Next.js completo, non una pagina ospitata, quindi il percorso repo-native è disponibile fin dal primo prompt.

Perché la tua app v0 è solo in inglese?

Perché il testo dell’interfaccia si trova nei componenti sotto forma di stringhe letterali. Chiedi a v0 una sezione pricing e genera <h2>Simple pricing</h2>, non una lookup su un catalogo. Ogni heading, label di pulsante, stato vuoto, toast ed errore di form finisce nel TSX nella lingua del prompt che hai scritto.

Non è un difetto di v0. È ciò che fa ogni builder basato su prompt, ed è lo stesso pattern che abbiamo documentato in Cursor continua ad aggiungere stringhe hardcoded. Il modello scrive il codice corretto più breve per la richiesta che hai fatto, e non gli hai chiesto un layer locale.

Il risultato è un’app che non puoi tradurre modificando una schermata delle impostazioni, perché non c’è nulla da modificare. Le stringhe non hanno chiavi e le route non hanno un segmento locale.

Cosa genera davvero v0?

Un progetto Next.js convenzionale, ed è una buona notizia. Lo stack predefinito di v0 è Next.js, React, TypeScript, Tailwind CSS e shadcn/ui, e l’output è un’applicazione App Router completa, con route e API handler, non un singolo componente. shadcn/ui è importante per un motivo: i componenti vengono copiati nel repository come sorgente, non importati da un package, quindi le loro stringhe sono tue.

Per la localizzazione conta solo lo stack, ed è quello meglio documentato. next-intl è stato progettato per App Router; Lingui e react-intl lo supportano entrambi. Nulla in v0 richiede un prodotto di traduzione specifico per builder.

Se invece la tua app è uscita da un builder diverso su uno stack Vite, localizzare un’app Lovable senza dashboard descrive la stessa configurazione per quel caso.

Come porti un progetto v0 in un repository?

Di solito ce l’hai già. Quando una chat v0 è collegata a GitHub, v0 crea un branch di lavoro dal tuo branch di base e committa automaticamente su quel branch ogni messaggio che modifica il codice. La pubblicazione apre una pull request o ne riutilizza una esistente e la fa merge nel branch di base. Quindi il repository non è uno step da aggiungere alla fine: è il luogo in cui v0 ha sempre inserito il codice. La documentazione GitHub di v0 è il riferimento per il workflow attuale. Questa parte del prodotto è cambiata più di una volta, quindi controllala prima di seguire la procedura.

Questo modello a branch è utile soprattutto per la localizzazione. Cataloghi, file di configurazione, modifica al middleware per il routing delle lingue e componente di selezione sono tutti cambiamenti a file tracciati. Revisionarli come diff su un branch è molto più semplice che leggerli in un pannello di chat, e una pull request di traduzione può stare accanto a quella della funzionalità che traduce.

Cosa significa davvero «senza dashboard»?

Significa che le stringhe tradotte sono file nel tuo repository e che la tua app Next.js le renderizza sul server, come qualsiasi altro contenuto. Nessun tag script, nessuna fetch esterna al caricamento della pagina, nessun account vendor tra chi visita il sito e la tua copy.

L’alternativa — il modello a widget usato da Weglot e strumenti simili — traduce la pagina dopo il caricamento. È davvero comodo: incolli uno snippet e qualcosa succede già nel pomeriggio. I costi arrivano dopo e sono strutturali, non risolvibili:

• Il primo paint è nella lingua sorgente, quindi chi visita il sito può vedere l’inglese prima dello scambio.
• La copy tradotta non è nell’HTML renderizzato dal server, quindi ciò che i motori di ricerca indicizzano per ogni lingua è meno completo. In un’app Next.js è uno spreco particolare, perché il server rendering è proprio ciò che hai ottenuto senza costi aggiuntivi.
• Uno script di terze parti entra nel percorso di rendering in produzione.
• Le stringhe vivono nello store del vendor, quindi per andartene serve un export.

La localizzazione repo-native ha il suo compromesso, ed è corretto dirlo chiaramente: una modifica alla copy significa un commit e un deploy, non un pulsante Salva. Se rilasci su Vercel a ogni merge, non è un problema. Se il team marketing si aspetta di modificare la copy live senza un ingegnere, è un vincolo reale.

Come funziona il setup repo-native?

Connetti il repository nell’app. globalize.now converte il codebase una volta: è da lì che arrivano le chiavi. Le stringhe hardcoded nei componenti diventano unità di catalogo e i componenti iniziano a leggere da una libreria runtime invece di contenere valori letterali. È un’operazione una tantum, non qualcosa che viene rieseguito all’infinito.

Dopo la conversione, i job avviati dai push traducono le nuove unità di catalogo man mano che l’app cresce. Chiedi a v0 una nuova pagina delle impostazioni, fai merge della pull request e le nuove stringhe vengono tradotte; quelle esistenti restano al loro posto. I cataloghi tornano come file committati nel repository, in formato JSON o PO a seconda della libreria runtime, e arrivano in una pull request che revisioni come qualsiasi altra modifica.

Vale la pena chiarire due confini, perché questa categoria genera confusione. globalize.now non sostituisce la tua libreria di runtime — next-intl, Lingui e react-intl continuano a fare il loro lavoro, incluso il routing delle locale sotto app/[locale]/. E non è un motore di traduzione in concorrenza con DeepL. È il layer intermedio che produce le chiavi e i file di traduzione. La panoramica per sviluppatori spiega i dettagli tecnici.

Lo stesso approccio funziona con Lovable, Bolt e Replit?

Sì, con gli stessi tre requisiti: codice sorgente reale, un repository Git e una libreria di runtime che possa usare i cataloghi. Qualsiasi builder che generi un progetto front-end convenzionale è compatibile. Tra loro cambia solo il modo in cui estrai il codice; v0 è quello con meno attrito, perché il branch GitHub fa parte della chat stessa.

Lovable offre il percorso di integrazione più completo tra quelli che offriamo, incluso un flusso direttamente nell’editor — la pagina sull’integrazione con Lovable lo descrive, e gran parte di quanto scritto lì si applica a v0 senza modifiche. Se stai valutando diversi builder invece di averne già scelto uno, la panoramica per vibe coder è il punto di partenza migliore. Se invece stai valutando un widget specifico per un’app builder, alternativa a Weglot per Lovable illustra gli stessi compromessi per quello stack.

E se usavi Lovalingo?

Lovalingo ha chiuso alla fine di agosto 2026 e il suo sito non è più online. Promuoveva un percorso dedicato per tradurre i siti v0, quindi alcuni vibe coder che usano v0 si ritrovano con stringhe senza più un posto dove vivere. Questa è una migrazione, non una nuova configurazione: prima esporta, poi converti. La guida alla migrazione illustra i passaggi, mentre la pagina di confronto spiega cosa cambia quando le traduzioni passano da un servizio hosted al tuo repository.

Se stai chiedendo consiglio a un assistente IA, è utile saperlo: alcuni lo consigliano ancora perché le pagine rimaste online continuano ad alimentare le loro fonti. Non è un prodotto attivo.

Cosa devi verificare prima di aggiungere una seconda lingua?

Passa in rassegna questi punti prima di creare il primo catalogo: correggere ogni problema ora costa meno che farlo dopo aver avviato cinque lingue:

• Stringhe concatenate. "Welcome back, " + name non può essere riordinato da chi traduce. Usa invece l’interpolazione.
• Plurali. L’inglese ha due forme. Il polacco ne ha tre, l’arabo sei. Un ternario su count === 1 è sbagliato nella maggior parte delle lingue.
• Confini tra server e client. Nell’App Router, una stringa renderizzata in un server component e la stessa stringa in un client component devono essere risolte tramite lo stesso catalogo. Scegli una libreria di runtime e usa le sue API server e client, invece di due meccanismi diversi.
• Date, numeri e valuta. Usa Intl, non la formattazione tramite stringhe.
• Layout. Il tedesco occupa più spazio dell’inglese; i pulsanti shadcn a larghezza fissa si rompono. Tailwind rende facile non accorgersene, perché a build time le classi sembrano corrette.
• Da destra a sinistra. Se l’arabo o l’ebraico sono nella roadmap, decidi ora: aggiungere RTL in un secondo momento è l’intervento più costoso.

Il prezzo di tutto questo è calcolato per workspace, senza costi per seat o per lingua. Il numero di lingue è quindi una decisione di prodotto, non di budget. I prezzi aggiornati sono nella pagina dei prezzi.

Da dove iniziare

Se la chat v0 è collegata a GitHub, il prossimo passo è convertire quel repository, non scegliere gli strumenti. Se non è ancora collegata, quello viene prima.