Come localizzi un’app Lovable senza dashboard?

Localizzi un’app Lovable mantenendo ogni parte del workflow nel repository: cataloghi dei messaggi come file committati, un file di configurazione che definisce le lingue e uno step CLI nella build che li compila. globalize.now è un’infrastruttura di localizzazione basata su IA che esegue questo loop al posto tuo: estrae le stringhe dal codebase, genera chiavi e file di traduzione e sincronizza le traduzioni a ogni push su Git. Nessun passaggio richiede un’interfaccia browser. È più importante di quanto sembri quando a scrivere il codice è un agent.

Perché una dashboard rompe un workflow costruito con l’IA?

Perché il tuo agent non può aprirla. Lovable, Cursor, Claude Code e Copilot lavorano tutti sulle stesse due superfici: file in un repository e comandi in un terminale. Una dashboard non è nessuna delle due.

Questa differenza è ormai un presupposto documentato, non una preferenza. AGENTS.md, la convenzione per spiegare ai coding agent come funziona un progetto, è stata portata alla Agentic AI Foundation della Linux Foundation nel dicembre 2025 insieme al Model Context Protocol. Secondo l’annuncio della Linux Foundation, allora il formato era già stato adottato da oltre 60.000 progetti open source e da più di venti strumenti di coding basati su IA. L’idea di fondo è che le istruzioni del progetto debbano stare in un file leggibile dall’agent.

Lo stato delle traduzioni che vive dietro un login è fuori da questo modello. Quando il tuo agent aggiunge un nuovo pulsante alla tua app Lovable, può aggiungere la stringa. Non può poi accedere a un servizio e riconciliare una griglia di traduzione. Così la stringa viene rilasciata in inglese, il disallineamento cresce e te ne accorgi da un utente in Germania.

C’è un secondo problema, più silenzioso. Quando le correzioni esistono solo nell’interfaccia di un vendor, il repository non è più la fonte di verità su ciò che dice l’app. Due fonti di verità, una delle quali i tuoi strumenti non possono ispezionare: un problema di debugging in attesa della scadenza sbagliata.

Come si presenta davvero un setup Lovable senza dashboard?

Quattro file e un comando nella build. Le app generate da Lovable vengono rilasciate come app React, sullo stack Vite classico oppure su TanStack Start con server rendering, e in entrambi i casi la struttura è la stessa.

1. Definisci le lingue nella configurazione. Un unico file, committato, contiene l’elenco che tutti gli altri layer leggono.

// lingui.config.ts
import { defineConfig } from "@lingui/conf";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "de", "es", "fr"],
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

2. Estrai i messaggi nei cataloghi. lingui extract analizza il codice sorgente e scrive un catalogo .po per ogni lingua. Esegue il merge con ciò che è già su disco, quindi le traduzioni esistenti sopravvivono a una nuova esecuzione: è questa la proprietà che rende sicuro inserirlo in un loop automatizzato.

npx lingui extract

3. Compila prima della build. lingui compile trasforma i cataloghi in moduli runtime. Il flag --strict interrompe la build quando manca una traduzione, trasformando un fallback silenzioso all’inglese in produzione in una build rossa che vedi prima.

{
  "scripts": {
    "build": "lingui compile --strict && vite build"
  }
}

4. Fai partire la sincronizzazione a ogni push. Aggiungere una lingua dovrebbe significare modificare l’array locales, non aprire un ticket al supporto. globalize.now osserva il repository, estrae le stringhe introdotte dall’agent, genera chiavi e voci di catalogo per ogni lingua e le committa di nuovo. I cataloghi arrivano come diff in una pull request, revisionabile come qualsiasi altra modifica.

Le guide complete per ogni stack sono disponibili nella guida Lovable Vite e nella guida TanStack Start.

Che fine fanno le traduzioni gestite da una dashboard quando il vendor chiude?

Se ne vanno con il vendor. Questo mese non è un’ipotesi astratta: Lovalingo, un servizio di traduzione runtime creato per Lovable e altre app generate con builder basati su IA, chiude il 31 agosto 2026 alle 23:59 CEST. I nuovi progetti e gli abbonamenti sono già stati sospesi e la pagina ufficiale di chiusura dell’azienda invita a implementare l’internazionalizzazione di proprietà del progetto insieme al servizio prima di rimuoverlo, quindi a verificare route locale, fallback, URL canonici, hreflang e output della sitemap.

È un vendor che descrive con precisione la differenza tra affittare un workflow e possederlo.

L’ultima riga ha una conseguenza SEO che va oltre la questione del vendor. Le traduzioni iniettate dopo il caricamento non finiscono in modo affidabile nell’HTML letto dai crawler. I cataloghi compilati nella build sì.

Come verifichi che la tua app Lovable non dipenda da una dashboard?

Tre controlli, e ognuno segnala chiaramente un problema.

Controlla la rete. Carica l’app con DevTools aperto, filtra gli script e cerca richieste verso il dominio di un vendor di traduzioni. Se uno script di terze parti deve caricarsi prima che la pagina tedesca venga visualizzata in tedesco, la pagina dipende dall’uptime di qualcun altro.

Controlla il repository. Per ogni lingua nella configurazione deve esistere un file di catalogo su disco, tracciato da Git. Esegui git ls-files "src/locales/**" e conta. Cataloghi vuoti o mancanti significano che le stringhe sono da qualche altra parte.

Controlla la build. Compila con --strict in CI. Una traduzione mancante dovrebbe bloccare il deploy. Se la build passa mentre una lingua è incompleta, il problema emergerà come testo inglese in una UI non inglese: è il tipo di errore che gli utenti descrivono dicendo «il sito non funziona».

Esegui tutti e tre i controlli su un deploy di anteprima prima di rimuovere qualsiasi vendor esistente, non dopo. La checklist di Lovalingo prima della rimozione sottolinea lo stesso punto: mantieni installato il vecchio servizio finché la sostituzione non è stata testata su route locale reali. La nostra comparazione con Lovalingo descrive direttamente il percorso di migrazione.

Dove si colloca globalize.now se non c’è una dashboard?

Nel layer tra il runtime i18n e il motore di traduzione. Librerie come Lingui, i18next e next-intl servono le traduzioni a runtime. Motori come DeepL e GPT producono il testo. globalize.now genera e mantiene ciò che sta in mezzo: chiavi e file di traduzione, aggiornati insieme al codice.

È proprio questo il layer che un tempo richiedeva una persona che facesse clic in un’interfaccia. Per questo rimuovere l’interfaccia cambia il workflow, non elimina una funzionalità. Il setup avviene una volta: connetti il repository a globalize.now e la conversione arriva come pull request. Nel tuo editor, lo stesso setup richiede un solo comando:

npx skills add globalize-now/globalize-skills

Dentro Lovable, la stessa funzionalità si installa come skill nell’editor, così l’agent che costruisce l’app può invocarla direttamente. Il piano Starter costa 20 € al mese per workspace e include 20 € di credito per le traduzioni — circa 200.000 parole al mese — con l’utilizzo oltre questa soglia fatturato alla stessa tariffa per carattere. Nessun costo per seat e nessun costo per lingua, più 5 € di credito alla registrazione senza carta. Lingue e progetti sono illimitati all’interno di un singolo workspace: è questo che conta quando aggiungi una quinta lingua, non un quinto seat.

Scopri di più sul workflow completo per vibe coder e sviluppatori e sul setup specifico per Lovable nella pagina dell’integrazione Lovable.

La versione breve

Le traduzioni della tua app Lovable dovrebbero essere file di tua proprietà, in un repository leggibile dal tuo agent e compilati dalla tua build. globalize.now mantiene aggiornati quei file a ogni push su Git.