Come rendere multilingue un'app Replit senza dashboard?

Rendi multilingue un'app Replit connettendo il suo repository Git a GitHub e mantenendo i catalog di traduzione in quel repository come file committati. Replit memorizza già ogni checkpoint dell'Agent come commit Git, quindi il repository esiste prima ancora che tu pensi alle lingue; il lavoro consiste nel portarlo su GitHub e far tornare i catalog attraverso la stessa storia. globalize.now è infrastruttura di localizzazione basata su IA: produce le chiavi e i file di traduzione, e la libreria runtime che la tua app già usa li serve. Nessuna dashboard si trova nel percorso runtime, e niente traduce la pagina dopo il caricamento.

Perché chiedere all'Agent di tradurre l'app non funziona?

Perché non c'è nulla in cui tradurre. Quando chiedi a Replit Agent una dashboard, scrive <h2>Your bookings</h2> dentro un componente, non un lookup contro un catalog. Ogni titolo, bottone, stato vuoto, toast e errore di validazione finisce nel JSX come letterale nella lingua in cui hai formulato il prompt.

Quindi quando in seguito chiedi all'Agent di «tradurre l'app in afrikaans», ottieni uno di due risultati a metà: una seconda copia dei componenti con il testo sostituito, oppure un oggetto translations scritto a mano che copre le schermate che l'Agent ha ispezionato per caso. Nessuno dei due è uno strato locale. La prossima funzionalità arriva di nuovo in inglese. Abbiamo documentato la stessa ricorrenza in Cursor continua ad aggiungere stringhe hardcoded; Replit Agent non si comporta diversamente, perché risolve il prompt che ha davanti, non l'architettura che sta dietro.

La soluzione è strutturale: assegna chiavi alle stringhe, metti le traduzioni in file, e fai leggere il runtime da quei file. È questo che significa «multilingue» in una codebase, ed è una modifica una tantum.

Cosa genera realmente Replit Agent?

Un progetto web convenzionale, il che è una buona notizia. I tipi di app curati di Replit sono costruiti attorno a React con ShadCN UI sul front end, tipicamente abbinato a un server Express nello stesso progetto, tutto in TypeScript. Da settembre 2025 l'Agent lavora anche con qualsiasi framework tu porti, incluse i repository GitHub importati, quindi un progetto Next.js o Vue è possibile; il percorso predefinito resta comunque lo stack React.

Per la localizzazione, lo stack è l'unico fatto che conta, ed è terreno standard. React più Vite più TypeScript è la combinazione più supportata nell'ecosistema i18n: i18next, Lingui e react-intl la puntano tutti direttamente. Se l'Agent ti ha costruito un'app Next.js invece, la scelta è tra next-intl, react-i18next e Lingui, e quel confronto è un post separato.

Ciò che è diverso da un builder solo front-end è la seconda metà del progetto. Un'app Replit di solito ha un server, e i server hanno anche loro delle stringhe. Ne parliamo più avanti.

Dove si trova il repository Git in un'app Replit?

È già lì. Il controllo di versione di Replit è Git sotto il cofano, e i checkpoint dell'Agent sono commit in quel repository. Ogni volta che l'Agent completa una funzionalità e ti offre un punto di rollback, ha fatto un commit. La documentazione stessa di Replit consiglia di passare a normali commit Git per il tracciamento a lungo termine quando lavori con repository esterni, che è esattamente la situazione qui.

Per portarlo su GitHub:

1. Aggiungi lo strumento Git dalla sezione Tools dell'editor del progetto.
2. Connetti il tuo account GitHub sotto connected services, poi connetti il repository dal pannello Git. Se il progetto non è mai stato inizializzato, il pannello offre di farlo prima.
3. Fai push. Il pannello fa push con un clic, e resta sincronizzato con qualsiasi cosa esegui nella Shell, quindi funziona anche git push origin main.

Replit supporta anche GitLab e Bitbucket, e vale lo stesso flusso. Il punto non è il provider; è che il repository ora vive in un posto contro cui un job di localizzazione può aprire una pull request.

Fai questo prima di toccare una singola stringa. Il lavoro di localizzazione è lavoro sui file, e un diff è il posto giusto per revisionarlo.

Cosa significa «senza dashboard» per un'app Replit?

Significa che le stringhe tradotte sono file nel repository e l'app le serve come qualsiasi altro asset. Nessun tag script, nessun fetch esterno al caricamento della pagina, nessun account di terze parti tra un visitatore e il tuo testo.

L'alternativa è un widget runtime che sostituisce il testo dopo che la pagina è stata renderizzata. I suoi costi sono strutturali: il primo rendering è in inglese, il testo tradotto non è nell'HTML che i crawler leggono per primo, uno script di terze parti si trova nel tuo percorso di produzione, e le tue stringhe vivono nello storage del vendor, quindi lasciare significa un export. La versione Lovable di questo argomento si trova in Localizzare un'app Lovable senza dashboard e si applica a Replit senza modifiche.

C'è una ragione specifica di Replit per cui questo conta ancora più qui. Replit fa il deploy dell'app per te, quindi la copia in esecuzione sul tuo dominio Replit è quella che si trova nel progetto al momento del deploy. Un widget tradurrebbe quel deployment dall'esterno. Avere i catalog nel repository significa che il deployment contiene già ogni lingua, e la preview di Replit ti mostra la versione tedesca prima che tu la rilasci.

Il compromesso è reale e vale la pena dichiararlo: una modifica al testo significa un commit e un nuovo deploy, non un bottone di salvataggio. Per chi costruisce da solo e rilascia da Replit è un non-evento; per chi si aspetta di modificare il testo live senza toccare il progetto, è un vincolo.

Come funziona il setup repo-native?

Connetti il repository nell'app globalize.now. La conversione viene eseguita una sola volta sulla codebase: le stringhe hardcoded diventano unità di catalogo con le rispettive chiavi, e i componenti iniziano a leggere da una libreria runtime invece di contenere valori letterali. È un'operazione unica, non qualcosa che si ripete in seguito.

Dopo la conversione, i push job traducono le nuove unità di catalogo man mano che l'app cresce. Chiedi all'Agente di creare una nuova pagina di impostazioni, fai il push, e le nuove unità vengono tradotte; quelle esistenti restano invariate. I catalogi tornano come file committati, JSON o PO a seconda della libreria runtime, in una pull request che revisioni come qualsiasi altra modifica.

Due confini, perché la categoria è confusa. globalize.now non sostituisce la libreria runtime; i18next, Lingui e next-intl continuano a fare il loro lavoro. E non è un motore di traduzione in concorrenza con DeepL. È il livello intermedio che produce le chiavi e i file di traduzione. La panoramica per sviluppatori ne spiega i meccanismi.

Come tornano le traduzioni in Replit?

Attraverso lo stesso pannello Git, nella direzione opposta. Questo è il passaggio che differisce da Bolt o Lovable, perché Replit è anche dove l'app viene eseguita.

1. Revisiona e fai il merge della pull request su GitHub.
2. Nel pannello Git di Replit, seleziona Pull. Se tu o l'Agente avete modificato gli stessi file nel frattempo, il pannello evidenzia i conflitti e li risolvi nell'editor prima di completare il merge.
3. Rilascia di nuovo. I catalogi fanno ora parte del progetto, quindi il deployment porta con sé ogni lingua.

Un'avvertenza specifica di Replit: i checkpoint dell'Agente ripristinano lo stato completo del progetto, inclusi i file. Se torni a un checkpoint creato prima del pull del branch di traduzione, i catalogi tornano indietro con esso. Tratta il merge come una milestone, lascia che l'Agente crei un checkpoint subito dopo, e torna a quello invece che a uno precedente.

Quali stringhe risiedono sul server?

Quelle che il front end non vede mai come JSX. Un'app Replit con un back end Express ha una seconda superficie di stringhe: messaggi di errore delle API, risposte di validazione, oggetti delle email, corpi delle notifiche, header CSV, tutto ciò che il server formatta prima di inviarlo. Un catalogo front-end non le raggiunge, e un widget non può vederle affatto, perché non sono mai nel DOM.

Il pattern è lo stesso del client, applicato lato server. Dai al server una copia della libreria runtime, leggi il locale del visitatore dalla richiesta (un header Accept-Language o un campo locale nel record utente), e formatta le risposte a partire dal catalogo invece che da stringhe letterali. Il namespace delle chiavi resta condiviso, quindi errors.booking.overlap significa la stessa cosa in un toast e in una risposta 409.

Salta questo passaggio e l'app sembrerà multilingue fino al primo errore, poi parlerà in inglese.

Cosa devi verificare prima di aggiungere una seconda lingua?

Verifica questi punti prima della conversione, perché ogni elemento costa meno risolverlo ora che dopo aver già cinque lingue in produzione:

• Stringhe concatenate. "Welcome back, " + user.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.
• Date, numeri e valuta. Usa Intl, non la formattazione manuale delle stringhe, sia sul client che sul server.
• Layout. Tedesco e finlandese occupano più spazio dell'inglese. I button a larghezza fissa si rompono, e le classi Tailwind sembrano a posto finché non arriva il testo vero.
• RTL. Se arabo o ebraico sono nella roadmap, decidilo ora. Aggiungere il supporto RTL in un secondo momento è l'operazione più costosa.
• Drift dei catalogi. Una volta che i catalogi esistono, una chiave aggiunta in un locale e non negli altri è un bug silenzioso. Perché i file di traduzione perdono la sincronizzazione spiega come succede e cosa fa un push job per risolverlo.

Il prezzo è per workspace, senza costi per postazione né per lingua, quindi il numero di lingue è una decisione di prodotto e non una voce di budget. Le cifre attuali sono su la pagina prezzi. Per lo stesso percorso su altri builder, la panoramica per vibe coder è il punto di partenza.

Da dove iniziare

Se il tuo progetto Replit è già connesso a GitHub, il passo successivo è una conversione su quel repository, non una decisione sugli strumenti da usare. Se non è ancora connesso, il pannello Git è il passaggio che precede questo.