Come esporto le mie traduzioni da Lovalingo prima della chiusura?

Richiedi ora l’export di conservazione a Lovalingo, poi converti i bundle di traduzione in cataloghi PO versionati nel tuo repo. Lovalingo sta preparando gli export per i progetti attivi e l’assistenza resta disponibile tramite [email protected] fino alla chiusura del servizio, il 31 agosto 2026 alle 23:59 CEST. globalize.now è un’infrastruttura di localizzazione basata su IA: prende le stringhe che hai recuperato, genera i file di locale nel tuo repo e li mantiene sincronizzati a ogni push su Git. Sarà l’ultimo export di traduzioni che dovrai fare.

Che fine fanno le mie traduzioni quando Lovalingo chiude il 31 agosto?

Tutte le lingue tranne quella sorgente smettono di essere visualizzate, perché il testo tradotto non è mai stato dentro la tua app. Lovalingo è un layer runtime: la tua app Lovable viene rilasciata in inglese e il servizio sostituisce il testo per ogni visitatore. Quando il servizio si ferma, si ferma anche la sostituzione.

I termini della chiusura sono pubblici sulla pagina di chiusura del servizio di Lovalingo. I nuovi progetti e gli abbonamenti sono già disattivati. I progetti attivi continueranno a funzionare fino al 31 agosto 2026 alle 23:59 CEST. La riscossione dei pagamenti è sospesa e gli export di conservazione sono in preparazione per i progetti attivi.

Quella scadenza è soprattutto una scadenza per i dati. Dopo il termine non ci sarà più alcun servizio da cui esportare né una casella di supporto a cui scrivere. Se oggi la tua app riceve traffico in francese o tedesco, il lavoro che ha prodotto quelle traduzioni svanirà se non lo recuperi prima.

Come recupero i miei dati di traduzione da Lovalingo?

Richiedi l’export di conservazione e mettilo al sicuro insieme al repository sorgente. Secondo la pagina sulla chiusura, gli export contengono la configurazione disponibile del progetto, le route, i bundle di traduzione, gli override e le prove d’integrità: tutto ciò che il runtime sapeva sulle tue lingue.

1. Richiedi l’export. Gli export sono in preparazione per i progetti attivi. Se non hai ancora ricevuto il tuo, scrivi a [email protected] e chiedi la consegna dell’export per il tuo progetto.
2. Conserva insieme due elementi: il file di export e uno snapshot del repository sorgente attuale. L’export descrive le traduzioni; il repo è l’app a cui appartengono.
3. Non disinstallare ancora Lovalingo. Le indicazioni ufficiali dicono di mantenerlo installato finché il sostituto non supera i controlli in produzione. Durante il passaggio i due sistemi possono funzionare fianco a fianco.

I bundle di traduzione sono la parte più importante. Contengono le stringhe effettivamente tradotte per ogni locale, oltre agli override manuali che hai applicato nella dashboard. Gli override sono ciò che si dimentica più facilmente: quelle modifiche esistono solo in Lovalingo, non in un motore di traduzione automatica che potresti eseguire di nuovo.

Come trasformo i bundle di Lovalingo in cataloghi di proprietà del mio repo?

Trasforma i bundle in cataloghi gettext PO e fai commit. PO è testo semplice, produce diff puliti in Git ed è il formato che Lingui compila per le app React. Copre entrambi gli stack generati da Lovable: la classica SPA Vite e il nuovo default SSR basato su TanStack Start.

I bundle runtime sono in genere mappe chiave-valore per locale. La conversione richiede un piccolo script, non un progetto:

// convert.mjs — JSON bundle → PO entries
import fs from "node:fs";

const locale = process.argv[2]; // e.g. "de"
const bundle = JSON.parse(fs.readFileSync(`bundles/${locale}.json`, "utf8"));

const po = Object.entries(bundle)
  .map(([source, translated]) =>
    `msgid ${JSON.stringify(source)}\nmsgstr ${JSON.stringify(translated)}\n`)
  .join("\n");

fs.writeFileSync(`src/locales/${locale}/messages.po`, po);

I nomi esatti dei campi variano in base all’export, quindi controlla il tuo prima di eseguire qualsiasi cosa. Il principio non cambia: stringa sorgente in ingresso, coppia msgid/msgstr in uscita, un file .po per locale, versionato sotto src/locales/.

Se scrivere a mano la conversione non fa per te, la guida alla migrazione di Lovalingo descrive il percorso gestito. Inoltre, chi migra da Lovalingo ha tre mesi di utilizzo gratuito durante il periodo di chiusura.

Come collego i cataloghi recuperati alla mia app Lovable?

Aggiungi la skill lovable-i18n al tuo workspace Lovable, poi chiedi a Lovable di configurare l’i18n; la skill collega Lingui al tuo stack e usa i cataloghi PO che hai versionato. Fuori dall’editor Lovable, la stessa configurazione si installa con:

npx skills add globalize-now/globalize-skills

I dettagli del collegamento dipendono dallo stack che usi. Le app generate prima di maggio 2026 sono per lo più SPA Vite classiche; quelle più recenti usano di default TanStack Start con SSR. C’è un walkthrough dedicato per ciascuna: i18n per le app Lovable Vite e i18n sullo stack TanStack Start di Lovable. La pagina dell’integrazione Lovable spiega cosa fa la skill dall’inizio alla fine.

Da quel momento, il problema di manutenzione che Lovalingo risolveva a runtime viene risolto direttamente nel tuo repo. Le nuove stringhe che rilasci vengono estratte, tradotte e versionate come translation PR a ogni push. Il prezzo è di 20 € al mese per workspace e include 20 € di credito per le traduzioni — circa 200.000 parole al mese — poi si applica un costo basato sui token alla stessa tariffa per carattere: nessun costo per seat e nessun costo per lingua, quindi aggiungere la sesta lingua costa quanto aggiungere la seconda. Pensato per i vibe coder che non vogliono mai occuparsi dei file di locale.

Cosa devo testare prima di rimuovere Lovalingo?

Testa prima il sostituto in condizioni di produzione: la rimozione è l’ultimo passaggio, non il primo. La sequenza pre-rimozione indicata da Lovalingo è una buona checklist e si applica direttamente a una configurazione con cataloghi versionati:

• URL diretti per locale. Ogni lingua deve vivere su una route reale (/de/, /fr/) che si carica con un hard refresh, non solo tramite cambio lato client.
• Chiavi mancanti e fallback. Elimina localmente una traduzione e verifica che l’app torni alla stringa sorgente invece di mostrare campi vuoti.
• Metadati SEO per locale. Controlla titoli, descrizioni, URL canonici, coppie hreflang e sitemap per ogni lingua. Le route per locale renderizzate dal server sono visibili ai crawler senza un passaggio JavaScript; la guida per rendere multilingue la tua app Lovable illustra il processo.
• Solo a quel punto rimuovi il widget. Quando la versione con cataloghi versionati supera i controlli, rimuovi Lovalingo ed esegui di nuovo i test.

Un vantaggio silenzioso del passaggio: nessun punto di questa checklist può regredire perché un vendor cambia piano. Ora i cataloghi sono file nella cronologia Git.

Il tuo export è un recupero una tantum. globalize.now fa in modo che sia l’ultimo: configuralo una volta e i tuoi cataloghi resteranno estratti, tradotti e versionati a ogni push su Git.