Come si localizza un'app Base44 senza dashboard?

Si localizza un'app Base44 connettendola a GitHub con la sincronizzazione bidirezionale che Base44 fornisce e mantenendo i catalog di traduzione in quel repository come file sottoposti a commit. Base44 riflette già ogni modifica tra editor e repository, quindi nel momento in cui i file di traduzione arrivano sul branch main diventano parte dell'app. globalize.now è infrastruttura di localizzazione basata su IA: produce le chiavi e i file di traduzione, e la libreria runtime nel tuo progetto li serve. Nessuna dashboard si trova nel percorso runtime, e niente traduce la pagina dopo il caricamento.

Perché la tua app Base44 è solo in inglese?

Perché il testo dell'interfaccia si trova dentro i tuoi componenti come stringhe letterali. Quando chiedi a Base44 una pagina di prenotazioni, scrive <h2>Your bookings</h2> dentro un componente React, non un lookup verso un catalog. Ogni titolo, etichetta di button, stato vuoto, toast e messaggio di validazione finisce nel JSX nella lingua in cui hai formulato il prompt.

Non è un difetto di Base44. È ciò che fa qualsiasi builder guidato da prompt, ed è lo stesso schema 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 tu non hai chiesto un livello locale.

Chiedere a Base44 di «tradurre l'app in tedesco» non risolve il problema. Ottieni una copia in tedesco delle schermate che il modello ha ispezionato, oppure un piccolo oggetto di stringhe inventato sul momento. Il prompt successivo scrive di nuovo testo in inglese, perché nulla nel progetto impone che il testo passi attraverso un catalog.

Cosa genera esattamente Base44?

Un progetto React standard costruito con Vite. La documentazione stessa di Base44 sulla struttura del progetto mostra il layout che trovi nella scheda Code e in un repository collegato: src/pages contiene un file per ogni route, quindi Home.jsx diventa / e Settings.jsx diventa /settings; src/components contiene gli elementi riutilizzabili con una cartella ui/ di componenti pre-costruiti; src/api, src/hooks, src/lib e src/utils contengono il client SDK, gli hook e gli helper.

Per la localizzazione contano più di tutte le altre due directory. functions/ contiene la logica backend, un file TypeScript per ogni funzione, e questi file formattano testo che gli utenti leggono: risposte di errore, email, documenti generati. entities/ contiene il modello dei dati come file di schema JSON, e con la sincronizzazione bidirezionale le entity sono gestite in Base44 piuttosto che nel repository.

Un'app Base44 ha quindi due superfici di stringhe che i catalog possono coprire, il client React e le funzioni backend, e una che non possono coprire, i dati dentro le entity. Su quest'ultima torniamo più avanti.

Come si porta un'app Base44 in un repository?

Base44 fornisce già la connessione. Nell'editor, apri la Dashboard, fai clic sull'icona GitHub e connettiti. Autorizzi l'app Base44 Builder sul tuo account o organizzazione GitHub, scegli a quali repository può accedere e crei un nuovo repository per l'app. Da quel momento repository ed editor restano allineati in entrambe le direzioni.

Due regole della documentazione di Base44 definiscono tutto ciò che segue. Primo, la sincronizzazione è automatica: le modifiche che fai in Base44, incluse quelle che l'IA fa a partire da un prompt, vengono sottoposte a commit nel repository senza un passaggio di push, e non esiste un button per il push manuale. Secondo, la via di ritorno è il branch main. Tutto ciò che viene unito con merge su main diventa visibile nell'app Base44, e master o qualsiasi altro nome di branch predefinito non è supportato. Dopo un merge, fai clic su Pubblica per rendere live la nuova versione per gli utenti.

La sincronizzazione bidirezionale richiede il piano Builder o superiore, e solo il proprietario dell'app può effettuare la connessione iniziale. Se il tuo account aveva configurato la vecchia integrazione monodirezionale Export to GitHub, il pannello GitHub ha un link per disconnetterla e riconnettersi con la sincronizzazione bidirezionale; il percorso monodirezionale non riporta mai nulla nell'editor, che è esattamente la direzione di cui la localizzazione ha bisogno.

Per il lavoro in locale, clona il repository, esegui npm install, installa la CLI di Base44, poi base44 login e base44 link per collegare il clone alla sua app. base44 dev esegue il frontend contro un backend locale. È il merge del tuo branch locale su main che lo sincronizza indietro.

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

Significa che le stringhe tradotte non vivono mai in un servizio hosted che la tua app deve chiamare o da cui devi esportarle. Vivono in src/locales/de.json accanto a src/pages/Home.jsx, versionate negli stessi commit, revisionate nelle stesse pull request e deployate con lo stesso clic su Pubblica.

Le forme alternative hanno un costo specifico su Base44. Un widget runtime che traduce la pagina nel browser lascia intatta la sorgente, quindi il repository continua a dire che l'app è in inglese, e ogni visitatore paga il ritardo della traduzione al caricamento. Uno strumento di traduzione hosted con un proprio editor mantiene la fonte di verità fuori dal repository, quindi la sincronizzazione bidirezionale che Base44 ha costruito sincronizza una codebase che non contiene le lingue. Entrambi inseriscono un secondo sistema tra te e un testo che vive già in file che possiedi.

La forma repo-native usa la sincronizzazione come è stata progettata. I catalog sono file. I file vengono sottoposti a commit. I file sottoposti a commit arrivano su main. main arriva all'editor. È tutta la pipeline, e nulla di essa è specifico della localizzazione.

Come funziona il setup repo-native?

Connetti il repository in l'app ed esegui la conversione una sola volta. La conversione individua le stringhe letterali nei tuoi componenti e nelle funzioni backend, assegna loro delle chiavi, collega una libreria runtime come i18next o Lingui se il progetto non ne ha una, e apre una pull request sul tuo repository con il catalog di origine e le prime lingue di destinazione. Quella pull request è tutto il passaggio di consegna. Revisionala su GitHub come faresti con qualsiasi altra modifica, fai il merge su main, e Base44 la rifletterà nell'editor.

Da quel punto in poi, dei job push traducono le nuove unità del catalog. Quando chiedi a Base44 una nuova funzionalità e la sincronizzazione la sottopone a commit, le nuove chiavi nel catalog di origine vengono tradotte e consegnate come pull request. Fai il merge, fai clic su Pubblica, e la funzionalità è live in ogni lingua. Non c'è nulla nelle tue abitudini di prompting che debba cambiare, e niente nella tua app chiama un servizio esterno a runtime.

Lo stesso approccio funziona su Lovable, Bolt, v0 e Replit, e la meccanica è identica perché tutti e quattro consegnano un progetto front-end convenzionale. La guida passo passo per Lovable ha il maggior dettaglio sulla struttura dei catalog, la guida per Bolt copre il passaggio di export per un builder senza sincronizzazione nativa, e la guida Vite per lo stack classico di Lovable è il riferimento più vicino all'output React e Vite di Base44 a livello di codice. Se stai confrontando i builder invece di esserti già impegnato con uno, la panoramica per i vibe coder è il punto di partenza migliore.

Quali stringhe vivono nelle funzioni backend?

Tutto ciò che un utente legge e che viene prodotto lato server. Un errore di validazione restituito da una funzione, la riga dell'oggetto di un'email che invia, il corpo di un PDF che genera, il testo di una notifica. Queste stringhe non compaiono mai come JSX, quindi un catalog front-end non le contiene e un widget runtime non può vederle.

Lo schema è lo stesso del client. Leggi il locale richiesto dalla request in arrivo, carica il catalog per quel locale sul lato funzione e condividi il namespace delle chiavi con il client, così un messaggio significa la stessa cosa nella UI e in una risposta API. Poiché la directory functions/ si trova nel repository, la conversione tratta quei file come qualsiasi altra sorgente e i catalog si posizionano accanto a essi.

E il contenuto dentro le entity?

Questo è il confine specifico di Base44. Le entity sono il tuo modello dei dati, gestite dentro Base44, e con la sincronizzazione bidirezionale non fanno parte del repository. Un record come il nome di un prodotto, la descrizione di un servizio o un articolo della guida è dato, non testo dell'interfaccia, e nessun catalog lo conterrà mai.

Il contenuto dei dati ha bisogno di una dimensione lingua sull'entity stessa: un campo locale, oppure un campo per ogni lingua, e query che leggano il locale del visitatore. La configurazione è la stessa che descriviamo per il contenuto del database nelle app Lovable, ed è una decisione di modello dei dati che prendi nell'editor delle entity di Base44, non una decisione dello strumento di localizzazione. Pianificala presto, perché aggiungere retroattivamente un campo lingua a un'entity con record già esistenti richiede più lavoro che aggiungerlo a una nuova.

E se usavi Lovalingo?

Lovalingo ha chiuso a fine agosto 2026, e i suoi casi d'uso pubblicati includevano Base44 insieme a Lovable, v0 e Bolt. Chiunque abbia localizzato un'app Base44 tramite quel servizio deve trovare un posto dove far confluire quelle stringhe. Si tratta di una migrazione, non di 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 hosted al tuo repository.

Cosa devi verificare prima di aggiungere una seconda lingua?

Verifica che la sincronizzazione sia bidirezionale, non quella legacy basata sull'export. Apri il pannello GitHub in Base44 e controlla che segnali un repository connesso; se propone il link «Looking for the old setup?», sei sul percorso monodirezionale e devi riconnetterti.

Verifica che il branch predefinito sia main. Base44 riflette indietro solo quel branch, quindi una pull request unita con merge altrove non arriva mai all'editor.

Cerca una libreria runtime. Se a un certo punto hai chiesto a Base44 delle lingue, potrebbe aver aggiunto i18next o un context scritto a mano; la conversione mantiene ciò che c'è e lo alimenta.

Decidi dove il contenuto delle entity otterrà il proprio campo lingua prima di aggiungere record in una seconda lingua. I catalog non faranno questa parte per te.

Controlla il routing. Le pagine di Base44 sono basate su file, quindi un prefisso di locale nell'URL è una decisione di routing che prendi una sola volta, e determina come i motori di ricerca vedono ogni lingua. La guida su selettore di lingua e hreflang copre le scelte disponibili e si trasferiscono direttamente.

Da dove iniziare

Attiva la sincronizzazione bidirezionale con GitHub in Base44 se non è già attiva, verifica che il branch sia main, e connetti il repository in l'app. La prima pull request converte la codebase. Tutto ciò che segue è un merge, un clic su Pubblica e le lingue che hai richiesto. La pagina di integrazione per Lovable descrive lo stesso flusso per un builder con un percorso in-editor, e gran parte di ciò che vi è scritto si trasferisce a Base44 senza modifiche.