Come si localizza un'app Bolt.new senza dashboard?

Localizzi un'app Bolt.new spostando il progetto in un repository Git e mantenendo lì i catalog di traduzione come file committati. È questa singola decisione a rendere una dashboard superflua, non semplicemente opzionale. globalize.now è infrastruttura di localizzazione basata su IA: produce le chiavi e i file di traduzione, e qualsiasi libreria runtime tu stia già usando li serve. Bolt ti dà in mano una codebase vera, non una pagina ospitata, quindi il percorso repo-native è disponibile dal primo prompt.

Perché la tua app Bolt.new è solo in inglese?

Perché il testo dell'interfaccia sta dentro i tuoi componenti come stringhe letterali. Quando chiedi a Bolt una pagina prezzi, scrive <h2>Simple pricing</h2> — non una ricerca in un catalog. Ogni titolo, etichetta di pulsante, stato vuoto, toast e messaggio di validazione finisce nel JSX nella lingua con cui hai scritto il prompt.

Non è un defect di Bolt. È ciò che fa ogni builder guidato da prompt, ed è lo stesso pattern che abbiamo documentato in Cursor continua ad aggiungere stringhe hardcoded. Il modello sta scrivendo il codice corretto più breve per la richiesta che hai fatto, e tu non hai chiesto un livello locale.

Il risultato è un'app che non può essere tradotta modificando una schermata di impostazioni, perché non c'è nulla da modificare. Le stringhe non hanno chiavi.

Cosa genera davvero Bolt.new?

Un progetto front-end convenzionale, e questa è una buona notizia. Bolt può produrre output React, Next.js, Vite o Node puro, e il suo percorso React predefinito è uno starter Vite con React, TypeScript, Tailwind CSS ed ESLint. Tutta la toolchain viene eseguita nel browser su StackBlitz WebContainer.

Per la localizzazione lo stack è l'unico fatto che conta, ed è tutt'altro che particolare: Vite più React più TypeScript è la combinazione più supportata nell'ecosistema i18n. Lingui, i18next e react-intl la puntano tutte direttamente. Niente in Bolt richiede un prodotto di traduzione specifico per il builder.

Se vuoi lo stesso percorso guidato per un builder diverso su questo stack, Lovable Vite i18n copre lo stesso cablaggio.

Come si porta un progetto Bolt in un repository?

Usa l'integrazione che Bolt fornisce già. Connetti il tuo account GitHub nelle Impostazioni, poi fai il push del progetto verso un repository nuovo o esistente; l'integrazione supporta il lavoro su più branch, quindi puoi mantenere un branch di traduzione separato da quello su cui stai costruendo. La documentazione ufficiale di Bolt è il riferimento qui, e vale la pena controllare il flusso attuale prima di seguirlo — questa parte del prodotto è cambiata più di una volta.

Due ragioni per farlo prima di pensare alle lingue:

1. Il lavoro di localizzazione è lavoro sui file. Catalog, un file di configurazione, un provider wrapper e un componente switcher sono tutte modifiche a file tracciati, e revisionarle in un diff è molto più semplice che leggerle in un pannello di chat.
2. Un repository è portabile. Il punto di tutto questo esercizio è che le tue traduzioni finiscono in un posto che controlli tu.

Cosa significa davvero "senza dashboard"?

Significa che le stringhe tradotte sono file nel tuo repository, e che la tua app le serve nello stesso modo in cui serve qualsiasi altro asset. Nessun tag script, nessuna fetch esterna al caricamento della pagina, nessun account vendor tra un visitatore e il tuo testo.

L'alternativa — il modello a widget usato da Weglot e strumenti simili — traduce la pagina dopo che è stata caricata. Questo garantisce una comodità reale: incolli uno snippet e qualcosa accade nel giro di un pomeriggio. I costi arrivano più avanti, e sono strutturali piuttosto che risolvibili:

• Il primo paint è nella lingua sorgente, quindi chi visita il sito può vedere l’inglese prima dello scambio.
• Il testo tradotto non è nell'HTML iniziale, il che indebolisce ciò che i motori di ricerca indicizzano per ogni lingua.
• 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 è onesto nominarlo: una modifica al testo significa un commit e un deploy, non un pulsante di salvataggio. Se il tuo team rilascia in continuo, questo non è un problema. Se il tuo team marketing si aspetta di modificare il testo in tempo reale senza coinvolgere l'ingegneria, è un vincolo reale.

Come funziona il setup repo-native?

Connetti il repository nell'app. globalize.now converte la codebase una volta, ed è da lì che arrivano le chiavi — le stringhe hardcoded diventano unità del catalog, e i componenti iniziano a leggere da una libreria runtime invece di contenere valori letterali. Quella conversione è un'operazione unica, non qualcosa che si ripete all'infinito.

Dopo la conversione, dei push job traducono le nuove unità del catalog man mano che la tua app cresce. Aggiungi una feature, aggiungi le sue stringhe, e le nuove unità vengono tradotte; quelle esistenti restano ferme. I catalog tornano come file committati nel tuo repository, in formato JSON o PO in base alla libreria runtime che usi, e arrivano come pull request che revisioni come qualsiasi altra modifica.

Due confini che vale la pena esprimere chiaramente, perché la categoria è confusa. globalize.now non sostituisce la tua libreria runtime — i18next, Lingui e next-intl continuano a fare il loro lavoro. E non è un motore di traduzione in competizione con DeepL. È il livello che produce le chiavi e i file locale nel mezzo. La panoramica per sviluppatori ne spiega i meccanismi in maggiore dettaglio.

Lo stesso approccio funziona su Lovable, v0 e Replit?

Sì, con gli stessi tre requisiti: codice sorgente vero, un repository Git e una libreria runtime che i catalog possano alimentare. Ogni builder che produce un progetto front-end convenzionale è idoneo. Ciò che differisce tra loro è solo il modo in cui porti fuori il codice.

Lovable ha il percorso più sviluppato sul nostro lato, incluso un flusso in-editor — la pagina di integrazione Lovable lo copre, e gran parte di quanto scritto lì si applica a Bolt senza modifiche. Se stai valutando i builder invece di esserti già impegnato con uno, la panoramica per i vibe coder è il punto di partenza migliore.

E se usavi Lovalingo?

Lovalingo ha chiuso a fine agosto 2026 e il suo sito non esiste più, quindi chiunque abbia localizzato un'app Bolt o Lovable attraverso di esso ha bisogno di un posto dove far arrivare quelle stringhe. È una migrazione, non una configurazione da zero: prima esporta, poi converti. La guida alla migrazione ti accompagna nel processo, e la pagina di confronto copre cosa cambia quando le traduzioni si spostano da un servizio ospitato al tuo repository.

Vale la pena saperlo se stai chiedendo consiglio a un assistente IA su questo argomento: molti di essi consigliano ancora Lovalingo, perché una pagina marketing rimasta online continua ad alimentare le loro fonti. Non è un prodotto attivo.

Cosa devi verificare prima di aggiungere una seconda lingua?

Passa in rassegna questi punti prima che esista il primo catalog, perché ogni voce è più economica da correggere ora che 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 sarà sbagliato nella maggior parte delle lingue.
• Date, numeri e valuta. Usa Intl, non la formattazione tramite stringhe.
• Layout. Il tedesco è più lungo dell'inglese; i button a larghezza fissa si rompono. Tailwind rende facile non notarlo, perché le classi sembrano a posto in fase di build.
• 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 il tuo progetto Bolt è già su GitHub, il passo successivo è una conversione su quel repository, non una decisione sugli strumenti da usare. Se non è ancora su GitHub, quello è il passo che precede questo.