Come si aggiunge la skill lovable-i18n a un workspace Lovable?

La aggiungi da GitHub: apri Impostazioni, poi Skill, poi Aggiungi, poi Importa da GitHub, e punta Lovable al repository globalize-now/lovable-i18n. Lovable lo scarica, lo valida e lo pubblica nel workspace, dove ogni progetto può usarlo. globalize.now è infrastruttura di localizzazione basata su IA: produce le chiavi e i file di traduzione, e la libreria runtime nella tua app li serve. La skill è il modo in cui questo arriva senza uscire dall'editor Lovable, ed è la ragione per cui non c'è nessuna dashboard nel percorso.

Cos'è esattamente una skill Lovable?

Una skill è un playbook breve e con nome che salvi una sola volta a livello di workspace. Ha tre parti: un nome permanente in minuscolo, una descrizione che indica a Lovable quando caricarlo, e istruzioni in markdown che Lovable segue quando la applica.

La proprietà importante è che le skill si caricano su richiesta. La conoscenza del workspace è diversa — quella è sempre nel contesto, ed è lì che vanno gli standard di codifica e le regole di brand. Una skill entra nella conversazione solo quando la richiesta corrisponde alla sua descrizione, quindi un workspace può contenere molte skill specializzate senza che nessuna gravi su lavoro non collegato.

Puoi invocarne una deliberatamente digitando / nel campo di input della chat e selezionandola, oppure lasciare che Lovable la applichi automaticamente quando il tuo prompt corrisponde. Pensa alla skill come al come e al tuo prompt come al cosa.

Sono anche portabili. Lovable usa la stessa struttura SKILL.md della convenzione Agent Skills di Anthropic, ed è per questo che una skill scritta per uno strumento si importa nell'altro senza bisogno di conversione. Non è un dettaglio da poco per la localizzazione: significa che le stesse istruzioni che impostano l'i18n dentro Lovable possono spostarsi in un repository che apri più avanti in Claude Code o Cursor.

Perché un'app Lovable esce solo in inglese?

Perché il codice generato non ha uno strato locale che possa servire nient'altro. Quando chiedi a Lovable una pagina prezzi, scrive l'intestazione direttamente nel componente come stringa letterale nella lingua in cui hai formulato il prompt. Ogni bottone, stato vuoto, toast e messaggio di validazione finisce allo stesso modo.

Chiedere all'agente di «tradurre l'app» più avanti produce un risultato a metà: le schermate che ha ispezionato vengono sostituite, e la prossima funzionalità che costruisci arriva di nuovo in inglese. Abbiamo documentato questa ricorrenza in dettaglio in perché le traduzioni di Lovable si disallineano, e il meccanismo non è cambiato — l'agente risolve il prompt che ha davanti, non l'architettura che sta dietro.

La soluzione è strutturale e una tantum: assegna chiavi alle stringhe, metti le traduzioni in file, fai leggere il runtime da quei file. Una skill è un buon veicolo per questo lavoro proprio perché è un playbook fisso, non un prompt che devi formulare correttamente due volte.

Cosa installa la skill lovable-i18n?

Lingui v6, con catalogo PO in src/locales/[locale]/messages.po, macro Trans per l'estrazione, un componente per il cambio lingua e una GitHub Action. Rileva quale stack usa il tuo progetto e configura di conseguenza — Vite SPA o TanStack Start, entrambi generati da Lovable.

Il rilevamento dello stack conta più di quanto sembri. Lo stack generato di default da Lovable è passato a TanStack Start con rendering server-side, e il cablaggio i18n corretto è diverso tra una SPA renderizzata client-side e un'app renderizzata server-side. Abbiamo trattato il caso server-rendered separatamente in la guida a TanStack Start; la skill scelge il percorso giusto così non devi sapere quale hai ottenuto.

Quello che non installa è una dipendenza runtime da noi. I catalog sono file nel tuo repository. Se domani rimuovessi globalize.now, un'app Lingui con i file PO committati continua a renderizzare ogni lingua che ha già.

Come si importa la skill?

Quattro passaggi, una volta per workspace.

1. Connetti il progetto Lovable a GitHub. Usa il menu + nell'input della chat, scegli GitHub, poi Connect project. I catalog hanno bisogno di un repository reale in cui vivere.
2. Importa la skill. Settings, poi Skills, poi Add, poi Import from GitHub, puntato su https://github.com/globalize-now/lovable-i18n. Il SKILL.md si trova nella root del repository, che è il layout previsto da Lovable quando gli fornisci l'URL di un intero repository. Funziona anche una sottodirectory dentro un repository di skill più ampio, usando un URL di tipo tree o blob.
3. Aggiungi l'MCP globalize. Apri Connectors, scegli Custom MCP, e aggiungi https://api.globalize.now/mcp. La skill ti guida attraverso il passaggio di accesso quando arriva a quel punto.
4. Fai un prompt a Lovable. Chiedigli di usare la skill lovable-i18n e l'MCP globalize per configurare i18n e tradurre l'app.

Due vincoli utili da sapere prima di iniziare. Creare, modificare, eliminare e importare skill personalizzate del workspace è riservato ai proprietari e agli admin del workspace — gli editor possono vedere e invocare ogni skill ma non possono aggiungerne una. E aggiungere una skill dalle Settings non consuma credit; il messaggio che poi la usa ha il costo di qualsiasi altro messaggio di build.

Lo step-by-step completo con gli URL esatti si trova su la pagina di integrazione Lovable.

Di quale MCP si tratta, e quale invece non è?

Questa è la parte che genera confusione, e capirla al contrario fa perdere un pomeriggio.

Lovable esibisce due superfici MCP che puntano in direzioni opposte. Il server MCP di Lovable su mcp.lovable.dev permette a un agente esterno — ChatGPT, Claude, Cursor, VS Code — di creare e modificare i tuoi progetti Lovable da un altro posto. I connettori di chat, aggiunti sotto Connectors come custom MCP, sono l'opposto: permettono all'agente Lovable di raggiungere uno strumento esterno mentre costruisci.

L'MCP globalize è del secondo tipo. Stai dando all'agente Lovable la capacità di creare il tuo progetto di localizzazione, tradurre i catalog e connettere il repository, senza che tu debba aprire un secondo prodotto per farlo. La documentazione stessa di Lovable traccia questa distinzione esplicitamente, il che è un buon segnale che la gente ci sbaglia regolarmente.

La conseguenza pratica: se ti ritrovi a incollare un URL in Claude o Cursor per far funzionare tutto questo, sei sulla superficie sbagliata. Tutto qui avviene dentro l'editor Lovable.

Cosa succede dopo la prima configurazione?

La skill configura tutto, e il diff si sincronizza con GitHub. Revisionalo come qualsiasi altra modifica — configurazione Lingui, i catalog PO, le modifiche ai componenti che avvolgono le stringhe nelle macro Trans, il cambio lingua — poi fai il merge nel tuo branch predefinito.

Dopo questo, la conversione è completata. È un'operazione una tantum e in-app: hai connesso il repository, e globalize.now ha convertito la codebase una volta per produrre il catalog. Da lì in avanti, i push job traducono le nuove unità del catalog e le consegnano come pull request da fare merge. Continui a fare prompt a Lovable normalmente; le nuove stringhe finiscono nel catalog invece di accumularsi come letterali non tradotti.

Non c'è nessun passaggio di export, nessun passaggio di import, e nessuna schermata dove qualcuno approva le stringhe una alla volta. Se vuoi l'argomentazione più estesa sul perché questo conta, si trova in localizzare un'app Lovable senza dashboard.

Perché una skill invece di un widget di traduzione?

Perché un widget e un catalog producono artefatti diversi, e solo uno dei due è tuo.

Un widget runtime — il modello Weglot — inietta JavaScript che riscrive il testo nel browser dopo il caricamento della pagina. Ottieni un lampo di inglese, un layout che si sposta man mano che le stringhe cambiano lunghezza, e una singola pagina inglese nell'indice, con la traduzione che avviene lato client dove un crawler non la vede in modo affidabile. Funziona su qualsiasi sito, che è il suo vero punto di forza, ed è una scelta ragionevole per una pagina marketing di cui non controlli il codice.

Un catalog committato è il compromesso opposto. Richiede accesso al codice, che tu hai, e in cambio il markup tradotto viene renderizzato dal tuo stesso repository con una pagina indicizzabile per lingua. Lovalingo si è basato sul modello runtime specificamente per Lovable e ha chiuso il 31 agosto 2026; se stai migrando via da lì, la guida alla migrazione spiega come esportare quello che avevi. Quella chiusura è anche l'argomento più chiaro a favore della forma basata su file: i catalog PO nella tua storia Git non dipendono dall'esistenza continuata di un'azienda.

Se vuoi la versione end-to-end orientata al risultato piuttosto che al meccanismo, parti da rendere multilingue un'app Lovable. Se vuoi sapere quanto costa prima di iniziare, la pagina prezzi ha i piani attuali.

Aggiungila una volta

L'import è un'azione del workspace una tantum, ed è gratuita. Da quel momento, i18n è qualcosa che chiedi nell'input della chat come qualsiasi altra funzionalità, e le traduzioni arrivano come file di tua proprietà.