# General Translation Knowledge Base: Come si migra da Lokalise a General Translation? URL: https://generaltranslation.com/it/kb/migrate-from-lokalise.mdx Docs index: https://generaltranslation.com/llms.txt Description: Mantieni i file di risorse, la libreria i18n e le traduzioni già revisionate. Esporta da Lokalise escludendo le traduzioni vuote, disattiva la sincronizzazione con GitHub e importa i file con npx gt upload prima di eseguire per la prima volta npx gt translate. Da quel momento General Translation traduce le stringhe nuove e modificate durante la build, usando il tuo glossario in un gruppo di contesto e le descrizioni delle chiavi come contesto per singola chiave. Category: Strumenti per il flusso di lavoro Last updated: 2026-11-12 Authors: Kevin Wu Published: 2026-11-12 Lokalise memorizza le stringhe come chiavi all'interno di un progetto, genera i file di risorse per ciascuna piattaforma in fase di esportazione e li sincronizza con il tuo repository. Passando a General Translation conservi i file di risorse che la tua app già legge: la CLI `gt` li importa insieme alle traduzioni esistenti, poi traduce le stringhe nuove e modificate durante la build o in CI. La libreria i18n e le chiavi restano invariate; spostare i testi inline è un passaggio separato e facoltativo (vedi [migrare da react-i18next](/kb/migrate-from-react-i18next) o [da next-intl](/kb/migrate-from-next-intl)). Il glossario diventa un gruppo di contesto condivisibile tra la tua app, la documentazione e altri progetti. ## Cosa si porta con sé da Lokalise? | In Lokalise | In General Translation | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Chiavi esportate come file per ciascuna piattaforma | Gli stessi file, elencati in `files` in `gt.config.json` | | Traduzioni | Importate con [`npx gt upload`](/docs/cli/reference/commands/upload) e mantenute finché la relativa sorgente non cambia | | Glossario | Il Glossario di un [gruppo di contesto](/docs/platform/dashboard/guides/defining-context-for-translations), importato da CSV | | Guide di stile per Pro AI | [Prompt Personalizzati](/docs/platform/dashboard/guides/defining-context-for-translations), a livello globale o per singola impostazione regionale | | Descrizioni delle chiavi e limiti di caratteri | Commenti nei file iOS e Android, che General Translation interpreta come contesto, oppure un file di [metadati associati alle chiavi](/docs/cli/reference/keyed-metadata) per JSON e YAML | | Memoria di traduzione | Le traduzioni caricate: le stringhe invariate le conservano e vengono tradotte solo le stringhe nuove o modificate. I file TMX non vengono importati | | GitHub App, auto-pull e GitHub Actions | [`npx gt translate`](/docs/cli/reference/commands/translate) in CI, oppure pull request di [Locadex](/docs/platform/locadex/quickstart) | | Attività di revisione | Modifica nella [dashboard](/docs/platform/dashboard/guides/reviewing-translations), con approvazione disponibile nel Piano Enterprise | | SDK over-the-air per iOS, Android e Flutter | Le traduzioni vengono distribuite nei file di risorse a ogni rilascio dell'app | La CLI legge JSON, YAML, `.pot` e `.po`, i file iOS `.strings`, `.stringsdict` e `.xcstrings`, i file Android `strings.xml`, `.resx`, HTML, Markdown e MDX, e altro ancora (consulta i [formati supportati](/docs/cli/reference/config#files)). Non legge invece XLIFF, ARB, Java `.properties` né le esportazioni CSV e XLSX: al momento del download, scegli quindi un formato supportato. ## Passaggio 1: esporta un file per lingua Lokalise non conserva i file originali: li ricostruisce a partire dalle chiavi a ogni esportazione. Se il tuo repository contiene già file sincronizzati da Lokalise, esporta con le stesse impostazioni in modo che l'output coincida, quindi confrontalo con il repository tramite un diff prima di importarlo. Con la [CLI `lokalise2`](https://github.com/lokalise/lokalise-cli-2-go/blob/master/docs/lokalise2_file_download.md), l'esportazione JSON di un'app web è la seguente: ```bash lokalise2 --token "$LOKALISE_TOKEN" --project-id "$LOKALISE_PROJECT_ID" file download \ --format json \ --original-filenames=false \ --bundle-structure "locales/%LANG_ISO%/common.json" \ --unzip-to . \ --export-empty-as skip \ --filter-data nonhidden \ --async ``` Per un'importazione pulita sono importanti quattro impostazioni: * **`--export-empty-as skip`.** Per impostazione predefinita, Lokalise esporta le chiavi non tradotte come stringhe vuote, mentre `base` le riempie con il testo di origine. In entrambi i casi verrebbero importate come traduzioni. Con `skip` vengono escluse. * **Formati di plurali e segnaposto.** Usa i formati letti dalla tua libreria: `--plural-format i18next_v4` per le chiavi `_one` e `_other` di i18next, oppure `--plural-format icu --placeholder-format icu` per next-intl. (Consulta i [formati di plurali e segnaposto](https://developers.lokalise.com/reference/api-plurals-and-placeholders) di Lokalise.) * **Piattaforme.** Ogni chiave appartiene a una o più piattaforme e un'esportazione include solo le chiavi della piattaforma corrispondente al suo formato. Esegui un'esportazione per ciascuna piattaforma: `--format strings` e `stringsdict` per iOS, e `--format xml` per Android. * **`--async`.** Il download sincrono di Lokalise è disponibile solo per progetti con meno di 10.000 coppie chiave-lingua; per i progetti più grandi serve quello asincrono. Se non usi la CLI, apri la pagina **Download** del progetto, scegli il formato, imposta **Empty translations** su skip e fai clic su **Build and download**. Per scaricare serve il permesso da contributor **Download files**. Controlla i codici locale nei nomi delle cartelle. Lokalise usa codici lingua propri, come `en_GB`, che la CLI confronta in modo esatto con l'elenco `locales`. Puoi sovrascrivere un codice facendo clic su di esso nella pagina **Download** o con `--language-mapping`, oppure elencare in `gt.config.json` i codici così come vengono esportati. ## Passaggio 2: interrompi la sincronizzazione di Lokalise Prima che General Translation scriva qualsiasi file, disattiva tutti i meccanismi che scrivono traduzioni nel tuo repository: * Elimina il webhook di auto-pull di Lokalise dalle impostazioni del tuo repository GitHub. * Smetti di usare il trigger GitHub per i download, che apre pull request da un nuovo branch. * Rimuovi o disattiva i flussi di lavoro che utilizzano le GitHub Actions di push e pull di Lokalise. Le app per GitLab, Bitbucket e Azure DevOps funzionano allo stesso modo. Se due strumenti scrivono gli stessi file, prevale quello che scrive per ultimo. ## Passaggio 3: indirizza la CLI verso i file Installa la CLI `gt` e descrivi i file esportati in `gt.config.json`: ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "fr", "pt-BR"], "files": { "json": { "include": ["locales/[locale]/*.json"] } } } ``` La CLI legge la sintassi dei messaggi di i18next e next-intl dai file JSON quando trova `i18next` o `next-intl` nel tuo `package.json`, mentre tratta gli altri valori JSON come semplici stringhe. (Vedi [File JSON](/docs/cli/reference/formats/json-files).) Accedi con [`npx gt login`](/docs/cli/reference/commands/login) e imposta `GT_PROJECT_ID`, oppure imposta `projectId` nella config. In CI, usa `GT_API_KEY` con una chiave API di progetto che disponga delle autorizzazioni **Files > Write**, **Translation queue > Enabled** e **Context > Write**. ## Passaggio 4: Importa il glossario e il contesto delle chiavi Nella pagina [Glossario](https://docs.lokalise.com/en/articles/1400629-glossary) di Lokalise, usa **More > Download CSV** per esportare tutti i termini con le relative traduzioni. Il file usa il punto e virgola come separatore e contiene una colonna per ogni lingua, ad esempio `de_DE`. Mantieni `term`, rinomina `description` in `definition` e ogni colonna di lingua in `translation_` (ad esempio `translation_de`), elimina le altre colonne e salva il file con la virgola come separatore. L'importatore di General Translation legge direttamente questo layout e interpreta gli altri tramite l'IA. Nella dashboard, crea un [gruppo di contesto](/docs/platform/dashboard/guides/defining-context-for-translations), fai clic su **Import**, scegli il file e assegna il gruppo al tuo progetto prima della prima esecuzione della traduzione, così le nuove traduzioni useranno la tua terminologia fin dall'inizio. Le descrizioni delle chiavi spiegano al traduttore il significato di una stringa. Le esportazioni iOS `.strings` e Android `strings.xml` le includono come commenti per impostazione predefinita e General Translation invia questi commenti come contesto. Per JSON, ricava la descrizione e il limite di caratteri di ogni chiave da `lokalise2 key list` oppure da un'esportazione [`json_structured`](https://docs.lokalise.com/en/articles/3229161-structured-json) della lingua di origine, salvata al di fuori delle cartelle indicate in `gt.config.json`, e riportali in un file di [metadati associati alle chiavi](/docs/cli/reference/keyed-metadata) accanto al file sorgente: ```json title="locales/en/common.metadata.json" { "checkout": { "save": { "context": "Button that saves the shipping address", "maxChars": 12 } } } ``` Ricrea le tue guide di stile di Pro AI come [Prompt Personalizzati](/docs/platform/dashboard/guides/defining-context-for-translations). Se il tuo piano include la gestione della memoria di traduzione, un amministratore del team può conservarne un archivio con **Download as TMX file** in **Team settings > Translation memory**. ## Passaggio 5: esegui il caricamento prima di tradurre Esegui prima [`npx gt upload`](/docs/cli/reference/commands/upload). Questo comando invia ogni file sorgente insieme al file tradotto corrispondente per ciascuna impostazione regionale e registra le traduzioni come completate: ```bash npx gt upload npx gt translate ``` [`npx gt translate`](/docs/cli/reference/commands/translate) traduce quindi solo ciò che manca, ad esempio una nuova impostazione regionale o un file senza traduzione, e scrive i risultati negli stessi percorsi. Se esegui [`npx gt translate`](/docs/cli/reference/commands/translate) prima di [`npx gt upload`](/docs/cli/reference/commands/upload), vengono generate nuove traduzioni che sovrascrivono i file esportati. General Translation traduce le chiavi rimaste senza traduzione in Lokalise alla successiva modifica del relativo file sorgente. Per distribuirle prima, completale in Lokalise prima dell'esportazione. ## Passaggio 6: Traduci automaticamente i nuovi testi D'ora in poi, esegui [`npx gt translate`](/docs/cli/reference/commands/translate) nella tua [build o CI](/kb/translations-in-ci), oppure lascia che sia [Locadex](/docs/platform/locadex/quickstart) ad aprire pull request con le traduzioni. Esegui il commit di `gt-lock.json`, che tiene traccia delle traduzioni già scritte dalla CLI per evitare di scaricarle di nuovo. Se il tuo team modifica i file tradotti nel repository, esegui [`npx gt save-local`](/docs/cli/reference/commands/save-local) prima della traduzione successiva, così da non perdere quelle modifiche. ## Quando conviene restare su Lokalise? Conviene restare quando le app mobile native si basano sugli aggiornamenti over-the-air delle stringhe, quando i designer lavorano con il plugin per Figma e gli screenshot, quando ordini traduzioni professionali direttamente all'interno dello stesso strumento o quando la tua pipeline scambia file XLIFF o ARB. (Vedi [General Translation vs. Lokalise](/kb/general-translation-vs-lokalise).) ## Domande frequenti ### Perderò le traduzioni già revisionate? No, a patto di escludere le traduzioni vuote durante l'esportazione e di eseguire [`npx gt upload`](/docs/cli/reference/commands/upload) prima di [`npx gt translate`](/docs/cli/reference/commands/translate). Le traduzioni caricate restano invariate finché il relativo testo di origine non cambia, e il tuo team può correggere qualsiasi traduzione nella [Dashboard](/docs/platform/dashboard/guides/reviewing-translations). ### Cosa succede agli screenshot? Restano in Lokalise. Per non perdere le informazioni che fornivano ai traduttori, descrivi dove compare ciascuna stringa nel contesto della rispettiva chiave (Passaggio 4). ## Punti chiave * Esporta un file per ogni lingua e piattaforma con `--export-empty-as skip`, mantenendo il formato dei plurali che la tua app legge già. * Rimuovi il webhook, i trigger e le Actions di Lokalise prima che General Translation scriva sugli stessi file. * Prima di tradurre, importa il glossario in un gruppo di contesto e riporta le descrizioni delle chiavi come contesto della singola chiave. * Esegui [`npx gt upload`](/docs/cli/reference/commands/upload) prima del primo [`npx gt translate`](/docs/cli/reference/commands/translate), poi traduci i nuovi testi durante la build o con Locadex. ## Related questions - [Alternative a Lokalise: General Translation vs. Lokalise](https://generaltranslation.com/it/kb/general-translation-vs-lokalise.mdx): General Translation è un'ottima alternativa a Lokalise per i team che vogliono testi leggibili nel JSX e una traduzione integrata nello sviluppo. Lokalise ruota attorno a chiavi condivise, integrazioni con strumenti di design e consegna over-the-air per le app mobile. General Translation genera le traduzioni a partire dai contenuti contrassegnati nell'app e consente la revisione nella propria Dashboard o nelle pull request di GitHub. - [Come si migra da Crowdin a General Translation?](https://generaltranslation.com/it/kb/migrate-from-crowdin.mdx): Mantieni i file di risorse, la libreria i18n e le traduzioni già revisionate. Attiva Skip untranslated strings, scarica le traduzioni, impedisci all'integrazione Git di Crowdin di inviare traduzioni e importa i file con npx gt upload prima del primo npx gt translate. Da quel momento General Translation traduce le stringhe nuove e modificate durante la build, usando il glossario di un gruppo di contesto. - [Come si migra da Phrase a General Translation?](https://generaltranslation.com/it/kb/migrate-from-phrase.mdx): Mantieni i file delle impostazioni regionali, la libreria i18n e le traduzioni verificate. Esegui il pull da Phrase Strings escludendo le chiavi non tradotte e i fallback, disattiva Repo Sync e importa i file con npx gt upload prima di eseguire per la prima volta npx gt translate. A quel punto General Translation traduce le stringhe nuove e modificate durante la build, usando la tua term base in un gruppo di contesto e le descrizioni delle chiavi come contesto per ciascuna chiave. - [Come mantengo le traduzioni aggiornate a ogni distribuzione?](https://generaltranslation.com/it/kb/translations-in-ci.mdx): Esegui la traduzione come passaggio della pipeline prima di ogni build di produzione, così i nuovi testi vengono rilasciati già tradotti insieme alla distribuzione che li introduce. La CLI gt di General Translation lo fa con npx gt translate, usando una chiave API e un ID progetto archiviati come segreti CI. - [Che cos'è la memoria di traduzione e serve ancora con l'IA?](https://generaltranslation.com/it/kb/what-is-translation-memory.mdx): La memoria di traduzione (TM) è un database di coppie di segmenti sorgente e di destinazione già tradotti, in cui uno strumento di traduzione cerca corrispondenze esatte, in contesto e fuzzy. Anche con l'IA conviene riutilizzare le formulazioni approvate e avere a disposizione le traduzioni precedenti come contesto. General Translation riutilizza le traduzioni corrispondenti delle versioni precedenti dei file e conserva le modifiche del team, senza dover gestire una TM separata. ## Previous and next questions - Previous question: [Come si migra da Crowdin a General Translation?](https://generaltranslation.com/it/kb/migrate-from-crowdin.mdx) - Next question: [Come si migra da Phrase a General Translation?](https://generaltranslation.com/it/kb/migrate-from-phrase.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.