Come Tradurre un Videogioco con l'IA

La localizzazione dei giochi inizia con un file che il tuo motore ha già scritto per te: il compito consiste nell’inviare quel file a un sistema che lo legga così com’è. Unity fornisce XLIFF o CSV. Unreal fornisce PO. Godot fornisce entrambi. Nessuno di questi deve essere rielaborato preventivamente.

Questa guida è la versione completa: cosa comporta effettivamente la localizzazione dei giochi, perché conviene, quale file fornisce ogni motore, cosa puoi e non puoi richiedere a seconda del formato di quel file, come la piattaforma gestisce un lavoro oggi e come affidare l’intero ciclo a un agente AI, così che una revisione in dieci lingue richieda una sola decisione invece di quaranta clic.

Cosa comporta effettivamente la localizzazione dei giochi

La localizzazione è composta da quattro attività distinte che spesso vengono riassunte in un’unica parola: sapere in quale fase ti trovi evita la maggior parte dei problemi.

1. Internazionalizzazione, che riguarda il codice, non la lingua. Il tuo gioco deve essere in grado di visualizzare un’altra lingua: nessun testo integrato in una texture, nessuna frase assemblata tramite concatenazione di stringhe, un font con i glifi necessari e layout che resistano all’allungamento di un’etichetta. Ogni motore ha un sistema per questo, ed è lì che risiedono le stringhe.

2. Estrazione, gestita dal motore. Unity raccoglie i testi in String Table Collections. Il Localization Dashboard di Unreal li raggruppa in un target e li esporta. Godot legge un foglio di calcolo o un catalogo gettext. Il risultato di questo passaggio è il file che andrai a tradurre.

3. Traduzione, l’argomento di questo articolo. Un file in entrata, un file in uscita, nello stesso formato.

4. Re-importazione e test. Il file torna al punto di origine, il gioco viene ricostruito e qualcuno legge il menu principale in tedesco per verificare che non ci siano testi che fuoriescono dai bordi.

L’unico passaggio che deve uscire dal tuo motore è il terzo. Qualsiasi sistema che ti chieda di ristrutturare il file prima di poterlo tradurre ha aggiunto una quinta attività superflua.

Perché localizzare

Si tratta di una questione di mercato, non di rifinitura. Un gioco pubblicato in inglese è scopribile e giocabile dalle persone che leggono l’inglese, mentre il resto del mondo rimane escluso.

L’indagine “Can’t Read, Won’t Buy” di CSA Research, condotta su 8.709 consumatori in 29 paesi, ha rilevato che il 40% dei consumatori non acquista da siti web in un’altra lingua e che il 76% preferisce acquistare prodotti con informazioni nella propria lingua. Questa ricerca riguarda l’acquisto online in generale e non specificamente i giochi, il che è esattamente il motivo per cui è utile citarla qui: questa preferenza non è una particolarità del gaming, è il modo in cui le persone acquistano qualsiasi cosa.

Altri tre effetti rilevanti per un gioco in particolare, senza numeri a supporto, poiché non ne abbiamo di pubblicabili:

• Visibilità nello store. Una pagina store in una sola lingua è ricercabile in una sola lingua. Titoli, descrizioni e tag sono tre schermate di testo a fronte di quaranta ore di contenuti.
• Recensioni e rimborsi. Un giocatore che non riesce a leggere un tutorial scriverà una recensione negativa sul tutorial.
• Portata per unità di lavoro. I sistemi, l’arte e l’audio sono già pronti. Il testo è l’elemento più economico da duplicare nel tuo progetto.

Se il tuo gioco ha poche centinaia di stringhe, si tratta di un fine settimana di lavoro accurato in ogni caso. Oltre le poche migliaia, la differenza tra un flusso di lavoro strutturato e un’abitudine improvvisata riguarda l’intero progetto.

Il rapporto con un sistema di gestione della traduzione

I grandi studi gestiscono la localizzazione tramite un TMS: memoQ, Phrase, Crowdin, Lokalise e simili. Sono piattaforme di coordinamento. Gestiscono le stringhe, la memoria di traduzione, gli account dei revisori, gli stati del flusso di lavoro e le integrazioni. Per un team di venti persone con fornitori esterni, questo coordinamento è il prodotto stesso.

Se siete da una a quindici persone, solitamente questo non è il vostro problema. Non avete bisogno di gestione account, stati o fornitori. Avete bisogno che le stringhe esportate di questa build siano tradotte bene, mantenendo intatto il vostro vocabolario inventato, prima della scadenza della milestone. Questo è un lavoro, non una piattaforma.

Per essere onesti: un TMS è dove un team numeroso organizza le persone, AI Glot è dove un file viene tradotto. Molti team mantengono l’export del motore come unica fonte di verità, lo traducono qui e caricano il risultato, senza alcun terzo sistema nel mezzo.

Cosa esporta il tuo engine e cosa leggiamo noi

AI Glot legge dodici formati: CSV, Excel, JSON e ARB, YAML, XLIFF, PO, Android XML, iOS .strings, Java .properties, .NET RESX, sottotitoli SRT e archivi ZIP contenenti uno qualsiasi di questi. I due formati effettivamente usati dai game engine, il PO di Unreal e l’XLIFF e il CSV di Unity, sono nativi. Questo è il punto centrale di questa sezione: non c’è bisogno di esportare, convertire, tradurre e poi riconvertire.

Unity

Il pacchetto Localization esporta le String Table Collections in tre modi, e ognuno di essi è compatibile qui.

L’XLIFF, nelle versioni 1.2 e 2.0, è il formato creato appositamente per questo. La documentazione di Unity descrive l’esportazione delle String Table Collections in uno o più file XLIFF, la loro modifica con uno strumento esterno e la successiva importazione con le traduzioni aggiornate: questo è esattamente il ciclo di lavoro. Invia il file al traduttore XLIFF e tornerà con le stesse unità nello stesso ordine.

Il CSV è l’altro formato di esportazione, ed è più leggibile se vuoi dargli un’occhiata rapida. Il CSV di Unity contiene una colonna Key con la chiave assegnata, una colonna Id con l’ID assegnato da Unity e una colonna per locale nella String Table. La variante “CSV with comments” aggiunge una colonna di commenti per locale, che serve come contesto per il traduttore e non deve essere tradotta. Questa distinzione richiede una sola frase nella tua istruzione, ed è esattamente il motivo per cui esiste la pagina del traduttore CSV. C’è una guida completa a entrambe le esportazioni di Unity, con l’istruzione esatta da scrivere per ciascuna.

Google Sheets è la terza opzione: il pacchetto sincronizza una String Table Collection con un foglio di calcolo. Esporta quel foglio come CSV o XLSX e ti ritroverai nei casi precedenti.

Unreal Engine

Il Localization Dashboard di Unreal utilizza un flusso di lavoro PO. La documentazione di Epic, nella pagina degli strumenti di localizzazione, raccomanda l’uso di un “strumento di traduzione esterno (come Poedit, OneSky o XLOC)” per il lavoro di traduzione effettivo, invece dell’editor integrato. AI Glot è quello strumento esterno, con la differenza che il file non richiede l’intervento manuale di un operatore.

Una voce PO ha tre parti fondamentali. La riga di contesto contiene l’identità di Unreal per quella voce, creata dal suo namespace e dalla sua chiave. La sorgente è il testo in inglese. Lo slot di traduzione rimane vuoto finché qualcuno non lo compila. Invia il file al traduttore PO e cambierà solo questa terza parte.

Ecco perché msgctxt e msgid sono trattati come struttura e non come testo. Se ne modifichi uno, Unreal non riuscirà a trovare la voce o considererà la traduzione obsoleta.

Godot e build mobile

Godot supporta entrambi i percorsi. La sua documentazione indica la presenza di un importatore che legge file CSV e il supporto per il caricamento di traduzioni scritte in formato gettext .po. Entrambi sono file che già sappiamo leggere.

Se pubblichi su smartphone, le stringhe lato store e lato piattaforma sono Android strings.xml e iOS .strings, ed entrambe hanno il proprio strumento dedicato: Android XML e iOS .strings. I sottotitoli di cutscene e trailer sono in formato SRT, che segue lo stesso flusso di lavoro della traduzione dei sottotitoli di YouTube.

Non pretendiamo di sostituire Unity, Unreal, Godot o una piattaforma di localizzazione. Noi elaboriamo ciò che questi esportano.

Una colonna per lingua o un file per lingua

Questo è l’aspetto più importante da comprendere prima di scrivere un’istruzione, perché determina cosa puoi effettivamente richiedere.

Quindi, “traduci il mio gioco in francese, tedesco, spagnolo e giapponese” è un unico lavoro se hai un CSV di Unity con quattro colonne per le lingue, ma sono quattro lavori se hai quattro file PO di Unreal. Richiedere a un formato a lingua singola di contenere due lingue non funziona, e l’errore avviene in fase di pianificazione piuttosto che silenziosamente, che è esattamente dove dovrebbe accadere.

Inviare una cartella di file locale come archivio unico

Un repository di gioco non contiene un singolo file di localizzazione. Contiene una directory per ogni cultura, ciascuna con lo stesso nome file. L’intera struttura può essere caricata come unico file ZIP, che è lo scopo del traduttore ZIP.

È utile conoscere i limiti prima di creare l’archivio: massimo 200 file, 20 MB per l’archivio e 4 MB per ogni singolo file al suo interno. I file singoli più grandi sono accettabili se caricati separatamente, dove i limiti sono molto più alti: 60 MB per i CSV, 50 MB per gli XLSX, 12 MB per XLIFF, Android XML e RESX, 8 MB per i JSON e 4 MB per PO, YAML, .properties, .strings e SRT.

Ogni file nell’archivio deve avere lo stesso formato e la stessa struttura. Per “stessa struttura” si intende qualcosa di specifico a seconda del formato:

• CSV: colonne identiche, nello stesso ordine.
• Android XML, iOS .strings, Java .properties, RESX: un set di chiavi identico. Un set di cartelle per cultura supera naturalmente questo controllo, poiché è generato da un’unica sorgente.
• XLIFF: stessa versione e struttura dell’unità. I singoli file possono dichiarare coppie linguistiche diverse, motivo per cui un export misto di più target costituisce comunque un unico archivio.
• PO: qualsiasi file PO, poiché la struttura di un catalogo coincide con il suo formato.

Un archivio che non supera il controllo della struttura viene rifiutato con l’indicazione dell’incongruenza, anziché essere elaborato solo parzialmente.

Come funziona ora una traduzione

Non c’è nessuna schermata di mappatura delle colonne né alcun passaggio di configurazione. Non esistono più modalità fisse tra cui scegliere da agosto 2026.

1. Carica il file esportato dal tuo software.
2. Spiega cosa ti serve, in inglese semplice. Una frase, o cinque.
3. Leggi il piano. Verranno mostrate le lingue, l’ambito rilevato, il numero di parole e il costo.
4. Correggilo se è sbagliato. Questo passaggio è gratuito e ripetibile.
5. Approva. Questo è il passaggio che consuma i crediti.
6. Scarica un file, nel formato originale.

L’istruzione è un testo libero che il motore compila in codice verificato. Ecco perché le indicazioni sull’ambito che nessun traduttore automatico saprebbe esprimere qui funzionano: “solo le voci la cui traduzione è ancora vuota”, “solo le righe in cui la colonna tedesca contiene ancora il testo inglese”, “traduci i dialoghi e i nomi degli oggetti, ignora i commenti degli sviluppatori”.

Tutto ciò che precede il quinto passaggio è gratuito. Un piano che ha interpretato erroneamente il file può essere corretto gratuitamente, quindi non c’è mai motivo di procedere a caso.

Testi con limiti di spazio

Un pulsante che sta bene in inglese potrebbe andare a capo in tedesco. Il testo tradotto è tipicamente più lungo del 15-30%, e un’interfaccia progettata sulla larghezza dell’inglese è un’interfaccia progettata per il caso più breve.

L’approccio sbagliato è tradurre prima e tagliare dopo, ottenendo abbreviazioni che nessuno sceglierebbe. L’approccio corretto è dichiarare il vincolo all’inizio, così che la frase venga scritta per adattarsi allo spazio:

Keep every UI label under 28 characters, including spaces. If the natural
translation is longer, choose a shorter phrasing rather than abbreviating.

Questo va inserito nelle istruzioni a livello di stringa, fornite in fase di approvazione, perché un limite di caratteri riguarda qualcosa di visibile all’interno di una singola stringa. Richiedilo una volta per file e verrà applicato mentre ogni etichetta viene scritta.

Ci sono due cose che questo non sostituisce. Testa le stringhe più lunghe all’interno della build, perché un limite di caratteri non è una misura dei pixel del tuo font. E sii onesto con i limiti: 28 caratteri per un pulsante, non 28 caratteri per la descrizione di una missione, altrimenti otterrai descrizioni che sembrano telegrammi.

Le due istruzioni che spesso vengono confuse

Questo è l’unico passaggio di tutto il workflow che può fallire silenziosamente, quindi dedicargli trenta secondi ne vale la pena.

L’istruzione del piano decide cosa viene tradotto. Viene letta una sola volta, confrontandola con la struttura dell’intero file, ed è qui che vanno indicati la lingua di destinazione e l’ambito. “Traduci in tedesco ogni voce la cui slot di traduzione è ancora vuota.”

Le istruzioni a livello di stringa vengono applicate mentre ogni stringa viene scritta. In quel momento il motore sta analizzando una singola stringa, quindi queste possono descrivere solo ciò che è visibile al suo interno: un limite di caratteri, un registro, un placeholder come {count} da mantenere esattamente così com’è, o un nome da non tradurre.

Se inserisci un limite di caratteri nel piano, non produrrà alcun effetto utile. Se inserisci “salta la prima colonna” o “traduci solo la seconda metà del file” nello slot a livello di stringa, non succederà nulla, perché in quel momento il file non è in vista. Non riceverai errori. Semplicemente otterrai un output che ha ignorato le tue istruzioni.

Nomi, oggetti e incantesimi che non devono variare

Il lore è l’aspetto che rende la traduzione dei giochi diversa da tutto il resto. Un catalogo prodotti ha cento termini che devono restare fissi. Un gioco ne ha mille, sono inventati e ricorrono in migliaia di righe e in ogni aggiornamento che rilascerai per i prossimi tre anni.

Inseriscili una volta sola in un glossario di lavoro: nomi dei personaggi, nomi di luoghi, nomi di oggetti e incantesimi, la traduzione ufficiale di una frase ricorrente e i nomi che non devono essere tradotti affatto. Un glossario è associato a una singola coppia linguistica e ne viene creato uno snapshot al momento della creazione del piano, quindi un batch già in esecuzione non verrà mai modificato e il file successivo utilizzerà i termini aggiornati.

Vale la pena controllare i limiti del piano rispetto alla tua lista di termini: un glossario con 50 termini nel piano Free, tre con 150 in Starter, glossari illimitati con 500 termini ciascuno in Pro.

E non devi digitare quella lista a mano. Il glossario è accessibile dal server MCP, con strumenti per elencare i glossari, leggerne uno, aggiungere, modificare o sostituire i termini. Quindi un agente che ha già il tuo progetto aperto può occuparsi della parte noiosa: leggere le tue String Tables o i file di dialogo, estrarre i nomi propri e i termini inventati ricorrenti, proporteli sotto forma di lista e scrivere quelli che approvi nel workspace prima di avviare qualsiasi traduzione.

Questo vale più di quanto sembri. Un glossario che nessuno compila non protegge nulla, e compilarne uno a mano per un gioco con mille termini inventati è esattamente il compito che viene rimandato all’infinito. Chiedi al tuo agente di bozzarlo, poi modifica la sua lista invece di scriverne una da zero.

Questa è anche la ragione tecnica per cui un traduttore automatico generico fatica con i videogiochi. Il suo glossario sostituisce un termine ovunque corrisponda, quindi la frase attorno alla sostituzione non viene mai riconsiderata, e un sostantivo inventato con un genere finisce in mezzo a una frase francese senza concordare grammaticalmente. Qui il glossario viene integrato come significato mentre la riga viene scritta, quindi il termine si flette all’interno della frase. La stessa differenza si applica all’ uso di un assistente chat per questo lavoro: funziona bene per dieci stringhe, ma non riesce a mantenere un’unica regola in modo affidabile alla stringa 18.000.

Lascia che un agente gestisca il ciclo di localizzazione del tuo gioco

Questa è la parte che la maggior parte degli studi non ha ancora implementato. Esistono una REST API, un tool da riga di comando e un server MCP, quindi un agente di codifica può gestire l’intero ciclo senza che un umano debba aprire un browser.

Installalo ed effettua l’accesso una sola volta:

npm install --global @ai-glot/cli
aiglot auth login

Questo apre un browser per autorizzare la macchina. Su un server di build senza browser, aiglot auth login --device attiva il flusso tramite codice dispositivo, mentre aiglot auth login --key <key> funziona in CI.

Il prompt da dare al tuo agente

Incolla questo testo, cambiando i percorsi e l’elenco delle lingue. È scritto per essere dato a un agente, non per essere eseguito manualmente.

My Unreal project is at ~/dev/starfall. The Localization Dashboard exported
PO files to Content/Localization/Game/<culture>/Game.po, and their msgstr
lines are still empty.

Translate the French, German, Spanish and Japanese files with the aiglot CLI.
Read `aiglot batches create --help` and `aiglot batches approve --help` first
so you use the real flags, and run `aiglot languages` to confirm each language
tag before you start.

A PO file holds one target language, so create ONE batch per culture, four in
total. The source language is English: say so explicitly in every instruction
rather than letting it be inferred.

The plan instruction should translate only the entries whose msgstr is still
empty, and leave msgctxt, msgid and every placeholder or rich-text tag exactly
as written.

At approval, pass this as the string-level instruction: "Keep UI labels under
28 characters. Keep placeholders exactly as written. Do not translate any name
that appears in the glossary."

Show me all four plans, the total word count and the cost BEFORE you approve
anything, then wait for me to confirm.

After I confirm, approve with the lite quality tier, poll until each batch
reaches a terminal status, and download each result next to the original as
Game.translated.po. Do not overwrite the source files. Tell me if any batch
failed.

Quattro elementi in quel prompt svolgono un lavoro concreto, e sono le parti da copiare nel tuo.

Istruisce l’agente a leggere prima l’aiuto. Un agente che indovina i nomi dei flag fallisce alla prima chiamata e poi inventa una ragione plausibile per giustificarlo. Leggere l’aiuto reale, o aiglot help --json per l’intero albero dei comandi in una volta sola, elimina questo problema.

Specifica chiaramente un batch per cultura. Un agente che presume che un unico lavoro possa avere quattro target scriverà un’istruzione che un file PO non può supportare, e passerai un intero ciclo di piano a scoprirlo.

Indica la lingua sorgente. Senza di essa, la sorgente viene dedotta dal contenuto, e tale deduzione è meno affidabile proprio dove è più critico: etichette UI brevi, file che contengono già una riga tradotta isolata e testi pieni di nomi inventati.

Inserisce un blocco prima della spesa. aiglot batches approve è l’unico comando che consuma crediti. Tutto ciò che precede è gratuito e ripetibile, quindi chiedere di vedere quattro piani prima non costa nulla. Questa proprietà rende ragionevole, anziché spaventoso, un ciclo di agenti non presidiato: un agente che ti fraintende consuma piani, non soldi.

Cosa esegue effettivamente l’agente

for pair in fr:French de:German es:Spanish ja:Japanese; do
  code=${pair%%:*}
  lang=${pair#*:}
  po=~/dev/starfall/Content/Localization/Game/${code}/Game.po

  # 1. Create the batch. Free. Returns the file and its plan.
  id=$(aiglot batches create "$po" \
        --instruction "The source language is English. Translate into ${lang} only the entries whose msgstr is still empty. Leave msgctxt and msgid exactly as they are, and keep every placeholder and rich-text tag untouched." \
        --json | jq -r '.data.id')

  # 2. Read the plan, still free.
  aiglot batches get "$id" --json | jq '.data.plan'

  # 3. Approve. The only step that spends credits.
  aiglot batches approve "$id" --quality lite \
    --instructions "Keep UI labels under 28 characters. Keep placeholders exactly as written."

  # 4. Wait for a TERMINAL status, not for a specific one.
  until status=$(aiglot batches get "$id" --json | jq -r '.data.status'); \
    [ "$status" = "completed" ] || [ "$status" = "failed" ] || [ "$status" = "cancelled" ]; do
    sleep 5
  done

  [ "$status" = "completed" ] && \
    aiglot batches download "$id" --output "${po%.po}.translated.po"
done

C’è un dettaglio che vale la pena copiare anche se non traduci mai un gioco. Il ciclo attende qualsiasi stato terminale invece di monitorare solo completed. Uno script che attende solo lo stato sperato rimarrà in attesa all’infinito in caso di errore, perché un confronto con un valore che non arriva mai non è un errore. È semplicemente sempre falso.

Se il tuo agente preferisce i tool alla shell, aiglot mcp fa da ponte con il server MCP. La CLI è il punto di partenza migliore: funziona in uno script, funziona in CI e puoi leggere esattamente cosa è stato eseguito.

L’altra metà: un agente che prepara solo i file

L’automazione completa non è l’unica forma utile e, per un primo passaggio, spesso non è quella giusta.

Un agente è altrettanto prezioso se si occupa solo della parte noiosa e poi si ferma. Chiedigli di scansionare il repository, trovare ogni file di localizzazione, segnalare quali culture esistono e quali voci sono ancora non tradotte, e assemblare un unico file ZIP con un file per cultura. Poi caricherai tu quell’archivio, leggerai il piano, lo approverai e lascerai che l’agente riposizioni i risultati nei percorsi corretti in seguito. Questa suddivisione lascia le due decisioni fondamentali alla persona che deve prenderle, ovvero per quale set di lingue stai pagando e se il piano è corretto, e affida alla macchina la gestione dei file, che è la parte genuinamente tediosa e soggetta a errori. La pagina delle soluzioni per la localizzazione dei giochi illustra lo stesso processo tramite browser, se preferisci visualizzarlo prima di automatizzarlo via script.

Dove l’essere umano è ancora indispensabile

Non ti diremo che la traduzione AI sostituisce un traduttore di videogiochi, perché per un gioco in particolare non è così.

Usalo per i volumi massivi. Stringhe della UI, descrizioni di oggetti e equipaggiamento, tooltip, nomi degli obiettivi, note della patch, l’infinità di battute e i testi descrittivi. Questo è il volume di contenuti che spinge gli studi a rimandare la localizzazione per un anno, ed è materiale che non richiede sforzi creativi al primo passaggio.

Affida la revisione umana dove porta davvero valore. L’ora di apertura, la voce dei personaggi principali, ogni battuta comica, ogni rima. Un primo passaggio seguito da un revisore è un ottimo modo di impiegare un esperto, ed è molto meglio di una settimana passata a navigare tra i file.

Assumi direttamente uno specialista per la pagina dello store e per il trailer, i due testi che decidono se qualcuno vedrà tutto il resto.

Il motivo per cui questa suddivisione funziona è che volume e importanza non sono correlati, e una volta capito questo, la decisione sul budget diventa scontata. La pagina del tuo store è composta da poche centinaia di parole che comportano la maggior parte del rischio per la tua reputazione: pagare un esperto madrelingua per questa sezione costa poco in termini assoluti ed è ovviamente vantaggioso. Le tue novemila stringhe della UI e degli oggetti in otto lingue rappresentano quasi tutte le parole, ma nessuno del rischio precedente, e nessun budget sopravvive a una tariffa a parola su di esse.

Quindi gestisci il volume qui, poi stabilisci il tuo limite. Alcuni studi inseriscono l’output direttamente nella build. Altri aggiungono una revisione professionale per i due mercati principali, o solo per i testi delle quest, e lasciano il resto così com’è. Entrambi gli approcci sono ragionevoli, e nessuno dei due è il tentativo di riparare una prima stesura scadente.

L’automazione serve affinché il tempo dell’esperto sia dedicato alla lingua e non alla gestione dei file. Questo è l’intero concetto, ed è la verità.

Parti dai file che hai già

Esporta dal tuo engine. Invia quel file. Leggi il piano. Non paghi nulla finché non approvi, quindi il costo per capire se questo sistema si adatta al tuo progetto è solo un caricamento e due minuti di tempo.

Se hai una Unity String Table, una cartella di file PO di Unreal, o un foglio di calcolo con i dialoghi che aspetti dall’ultima milestone, ecco il tuo punto di partenza. Iscriviti a AI Glot e traduci prima un singolo file, poi assegna un agente al resto.