Traduzione e localizzazione del software: processo, costi e cosa inviare al fornitore
La traduzione e localizzazione del software segue otto fasi: preparare il codice per altre lingue, estrarre le stringhe in file traducibili, fornire il contesto, concordare la terminologia, tradurre e revisionare, testare con pseudo-localizzazione e revisione nel contesto, rilasciare e ripetere a ogni aggiornamento. I costi dipendono soprattutto da testo nuovo o riutilizzato, numero di lingue e frequenza dei rilasci. DEMA Solutions localizza software e documentazione per aziende tecnologiche europee.
A chi è rivolta questa guida
Questa guida è pensata per chi deve far uscire un prodotto in più lingue senza rallentare lo sviluppo: product manager che preparano il primo rilascio multilingue, responsabili dello sviluppo che dovranno gestire i file di stringhe e localization manager che hanno ereditato un processo che funziona quasi sempre. È rivolta anche ai costruttori di macchine e impianti i cui prodotti ormai includono un software, come un configuratore, un portale clienti o un’app di supporto, e che scoprono che il software non si traduce come un manuale. Se il vostro caso riguarda soprattutto pannelli operatore, allarmi e messaggi PLC, trovate indicazioni specifiche nella guida alla traduzione software per HMI e macchine.
Le domande sono concrete: cosa deve succedere nel codice, quali file inviare, come testare il risultato e perché i preventivi sono così diversi tra loro. Le sezioni che seguono ripercorrono il processo nell’ordine in cui lo incontrerete.
Che cos'è la localizzazione del software, e che differenza c'è tra traduzione e localizzazione?
La localizzazione di software adatta i testi visibili, i formati e il comportamento di un programma perché risulti naturale agli utenti di un’altra lingua e di un altro mercato. La traduzione ne è la parte centrale, ma solo una parte. Un prodotto localizzato mostra anche date, numeri, valute e unità di misura come se li aspettano gli utenti locali, gestisce forme plurali che l’inglese non ha, fa stare testi più lunghi negli stessi pulsanti e finestre di dialogo e usa gli stessi termini nell’interfaccia, nell’help center e nella documentazione. Per questo, quando si parla di localizzazione, traduzione e adattamento tecnico vanno pianificati insieme. Un ragionamento simile vale per il sito aziendale, dove capire il costo della traduzione di un sito web significa confrontare plugin automatici, risorse interne e professionisti.
La distinzione tra localizzazione e traduzione conta perché cambia chi è coinvolto. Un documento può essere tradotto solo da linguisti. Un software no: gli sviluppatori decidono come le stringhe vengono memorizzate e composte, i designer quanto spazio ha un’etichetta, il product management quali mercati escono e quando. Se queste decisioni tengono conto delle altre lingue, la traduzione è rapida e prevedibile. Se non lo fanno, i traduttori ricevono frammenti senza contesto e i problemi emergono tardi, nella build di rilascio, in una lingua che nessuno nel team legge.
Prima viene l'internazionalizzazione
Prima della localizzazione c’è l’internazionalizzazione, il lavoro di ingegneria che rende un prodotto pronto per qualsiasi lingua. È la causa più frequente di una localizzazione lenta e costosa, ed è quasi interamente nelle mani del team di sviluppo.
Esternalizzate tutte le stringhe visibili. Il testo scritto direttamente nel codice non si può estrarre né aggiornare senza modificare il codice. Etichette, messaggi, tooltip, modelli di email e testi di errore vanno nei file di risorse, richiamati da chiavi stabili.
Non componete le frasi a pezzi. Il codice che concatena “You have ” + count + ” new messages” presuppone l’ordine delle parole inglese. Usate frasi complete con segnaposto nominati e lasciate che ogni lingua li disponga.
Gestite le regole del plurale. Inglese e italiano hanno due forme plurali, molte lingue ne hanno di più, con categorie diverse. I formati di messaggio che prevedono le categorie di plurale, come la sintassi ICU, permettono ai traduttori di fornire tutte le forme necessarie.
Lasciate spazio all’espansione del testo. Il testo tradotto è spesso più lungo dell’inglese, e le etichette brevi si allungano proporzionalmente di più. Layout flessibili e limiti di caratteri concordati dove lo spazio è davvero fisso evitano la maggior parte dei testi troncati.
Usate formati basati sulla lingua e Unicode ovunque. Date, numeri e ordinamento devono arrivare dalle impostazioni locali, e ogni livello, dal database ai font, deve gestire i caratteri delle lingue di destinazione.
Niente di tutto questo è traduzione, ma ogni lacuna diventa un problema di traduzione. Un buon fornitore vi segnalerà i problemi di internazionalizzazione che trova nei vostri file; non può però correggerli nel vostro codice.
Il processo di localizzazione del software, passo per passo
Visto da fuori, localizzare significa “mandare stringhe, ricevere stringhe”. Il processo che funziona nella pratica ha più fasi, e la maggior parte avviene prima o dopo la traduzione.
1. Definite ambito e lingue. Stabilite quali componenti (interfaccia, onboarding, notifiche, help center, documentazione) escono in quale lingua e con quale rilascio.
2. Estraete le stringhe. Esportate file di risorse che il fornitore possa elaborare senza copia manuale, con chiavi, struttura e codifica intatte.
3. Pseudo-localizzate. Testate la build con testo generato e allungato prima che inizi la traduzione vera.
4. Preparate il contesto. Screenshot, commenti alle stringhe e limiti di caratteri indicano al traduttore dove compare ogni stringa.
5. Concordate terminologia e stile. Glossario e guida di stile vengono creati o aggiornati e approvati da qualcuno che conosce il prodotto in quel mercato.
6. Traducete e revisionate. Linguisti madrelingua traducono le stringhe nuove e modificate, le traduzioni approvate vengono riutilizzate e un secondo linguista revisiona il risultato.
7. Testate nel contesto. Le stringhe tradotte vengono controllate sulle schermate reali per significato, troncamenti e coerenza.
8. Rilasciate e mantenete. Ogni correzione torna nella memoria di traduzione e nel glossario, così il rilascio successivo parte dalla versione corretta.
Le sezioni che seguono approfondiscono le fasi in cui la maggior parte dei progetti si inceppa.
File di stringhe e formati: cosa deve ricevere il fornitore
I formati di risorse cambiano a seconda della piattaforma, e ognuno ha i suoi rischi. Il fornitore non deve conoscere il vostro sistema di build, ma deve ricevere file che possa aprire, tradurre e restituire con la stessa identica struttura. I formati più comuni sono:
- XLIFF, lo standard XML di scambio per la localizzazione, che tiene insieme testo di partenza, traduzione e note;
- JSON, diffuso nei front end web e mobile, spesso annidato e senza un campo nativo per i commenti, per cui il contesto va inviato a parte;
- RESX per le applicazioni .NET, con un elemento commento per ogni stringa;
- file PO di gettext, che supportano commenti per il traduttore, contesto del messaggio e forme plurali;
- file .strings e .stringsdict per le app iOS e risorse XML di stringhe per Android, ognuno con la propria sintassi per il plurale.
Qualunque sia il formato, alcuni elementi devono tornare intatti: chiavi, segnaposto come {name} o %s, tag di markup, caratteri di escape e codifica del file. I segnaposto possono spostarsi nella frase, perché l’ordine delle parole cambia, ma non devono mai essere tradotti, eliminati o duplicati. I controlli automatici intercettano la maggior parte di questi errori prima della consegna, e chiedere a un fornitore come si accorge di un segnaposto danneggiato è un test rapido del suo processo.
Un’abitudine fa risparmiare molto tempo: inviate solo le stringhe nuove e modificate, oppure indicate chiaramente cosa è cambiato rispetto all’ultima consegna. Rimandare ogni volta i file completi senza questa informazione costringe qualcuno a ritrovare le novità, ed è proprio lì che si insinuano modifiche involontarie a stringhe già approvate.
Contesto: screenshot, commenti e limiti di caratteri
La maggior parte degli errori di localizzazione sono errori di contesto, non di lingua. “Open”, “Update” o “Save” possono essere un verbo su un pulsante o un sostantivo in un menu, e in italiano diventano “Aggiorna” in un caso e “Aggiornamento” nell’altro. Una stringa come “%d items” può indicare prodotti nel carrello o voci in un registro. Senza contesto anche un traduttore attento deve tirare a indovinare.
Tre tipi di contesto fanno la differenza. Gli screenshot mostrano dove si trova una stringa e quanto spazio ha. I commenti alle stringhe spiegano a cosa serve una chiave e cosa conterrà ogni segnaposto. I limiti di caratteri per pulsanti, intestazioni di tabella e notifiche dicono al traduttore quando serve una formulazione più breve, prima che un tester trovi l’etichetta troncata.
Non servono tutti e tre per ogni stringa. Una nota sulle chiavi ambigue, screenshot aggiornati a ogni rilascio e limiti solo dove lo spazio è davvero fisso eliminano gran parte delle ipotesi, e i team che commentano le chiavi nel momento in cui le creano ricevono pochissime domande dai traduttori.
Terminologia e stile: una sola voce in ogni lingua
Un’interfaccia è un vocabolario ridotto usato migliaia di volte. Se “workspace” viene tradotto in tre modi diversi tra app, help center ed email di onboarding, gli utenti pensano che siano tre cose diverse. Un glossario dei termini di prodotto, con la traduzione approvata per ogni lingua e l’indicazione dei termini che restano in inglese, evita questa deriva. Il nostro articolo sulla gestione terminologica centralizzata tra traduttori e fornitori spiega come costruire un glossario di questo tipo e mantenerlo aggiornato.
Lo stile conta altrettanto. L’interfaccia dà del tu o del lei all’utente? I pulsanti usano l’imperativo (“Salva”) o l’infinito (“Salvare”)? Come sono formulati i messaggi di errore? Una breve guida di stile per la traduzione per ogni lingua risponde a queste domande una volta per tutte, per ogni traduttore e revisore. Per famiglie di prodotti più ampie, un servizio strutturato di gestione terminologica trasforma il glossario in una base terminologica curata, utilizzabile da tutti i fornitori e i team interni.
Traduzione e revisione
Con file, contesto e terminologia pronti, la traduzione è la fase più prevedibile. Linguisti madrelingua esperti di convenzioni software traducono le stringhe nuove e modificate, le traduzioni approvate nella memoria vengono riutilizzate dove il testo di partenza non è cambiato e un secondo linguista confronta ogni traduzione con l’originale per significato, terminologia, segnaposto e lunghezza.
La traduzione automatica ha il suo spazio, soprattutto per help center, knowledge base e aggiornamenti della documentazione di grandi dimensioni. Funziona meglio quando lavora sul vostro glossario e sulla vostra memoria approvata, con un linguista qualificato che rivede l’output. Le stringhe di interfaccia sono brevi, ambigue e visibili in ogni schermata, quindi di solito richiedono un traduttore umano fin dall’inizio. Nella pagina sulla traduzione automatica con post-editing spieghiamo come valutiamo quali contenuti si prestano a questo approccio.
Pseudo-localizzazione e QA linguistico nel contesto
Due tipi di test proteggono un rilascio localizzato, e trovano problemi diversi.
La pseudo-localizzazione si fa prima della traduzione e testa il codice, non la lingua. Uno script sostituisce ogni stringa di partenza con una versione allungata, con caratteri accentati e racchiusa tra marcatori, così “Save changes” può diventare [Šåvé çhåñgéš !!!]. Navigando in quella build si vede subito quale testo è scritto nel codice (resta in inglese normale), quali etichette vengono troncate (il marcatore di chiusura sparisce) e quali caratteri si rompono. Costa poco, non richiede traduttori e intercetta proprio i difetti più costosi da scoprire in dieci lingue contemporaneamente.
Il QA linguistico nel contesto si fa dopo la traduzione, su una build o un ambiente di staging con le stringhe reali. Un linguista o un revisore nel mercato di destinazione percorre i principali flussi utente e verifica ciò che nessuna revisione su file può vedere: se una traduzione è adatta al contesto, se il testo è troncato, se date e numeri compaiono correttamente e se ogni termine è uguale in tutte le schermate. Le correzioni entrano nella memoria di traduzione, non solo nella build, così non ricompaiono al rilascio successivo.
Per un primo lancio conviene fare entrambi i test in ogni lingua; per i rilasci di routine bastano di solito i controlli automatici e la verifica nel contesto delle nuove funzioni.
Localizzazione continua per rilasci frequenti
I prodotti che escono ogni una o due settimane non si possono localizzare in grandi lotti occasionali: quando un lotto rientra, il testo di partenza è già cambiato. La localizzazione continua sostituisce il lotto con un flusso costante: a ogni rilascio le stringhe nuove e modificate vengono acquisite e tradotte mentre lo sprint è ancora in corso, così ogni lingua esce insieme all’originale e non settimane dopo.
Più che la velocità, conta la disciplina. Le stringhe vanno contrassegnate come stabili prima di andare in traduzione, altrimenti lo stesso testo viene tradotto tre volte mentre la formulazione si assesta. Il contesto deve accompagnare ogni lotto, perché il traduttore non ha visto la demo della funzione. Le decisioni terminologiche hanno bisogno di un responsabile che risponda in fretta, e la memoria va aggiornata a ogni consegna.
Il vantaggio è concreto: i lotti piccoli si revisionano più facilmente, gli errori vengono corretti prima di diffondersi e ogni rilascio costa solo ciò che è davvero cambiato. È qui che convergono quasi tutte le buone pratiche di localizzazione: localizzare poco e spesso, con il contesto, su una sola memoria e un solo glossario.
Interfaccia, help e documentazione coerenti
Gli utenti non distinguono tra interfaccia e documentazione. Se il pulsante dice una cosa e l’articolo di help un’altra, perdono fiducia in entrambi. Eppure questi testi nascono spesso in team, formati e tempi diversi, a volte presso fornitori diversi.
La soluzione è trattarli come un unico corpo di contenuti. Lo stesso glossario e la stessa memoria di traduzione dovrebbero servire interfaccia, help center, note di rilascio, documentazione API e, per i costruttori, il manuale d’uso. Manuali e guide di installazione che accompagnano un software seguono la stessa logica del resto della vostra traduzione tecnica: devono riprendere la terminologia dell’interfaccia, non reinventarla.
Se le traduzioni esistenti sono in vecchi file e non in una memoria, si possono comunque recuperare. L’allineamento della memoria di traduzione abbina le traduzioni precedenti ai rispettivi originali, così la formulazione approvata è riutilizzabile già dal primo rilascio con un nuovo fornitore.
Cosa determina i costi della localizzazione del software
La localizzazione del software viene di solito quotata a parola, ma la tariffa spiega meno del costo finale di quanto molti si aspettino. Questi sono i fattori che contano davvero.
Testo nuovo o ripetuto. Le stringhe già approvate nella memoria, o ripetute nel prodotto, costano molto meno del testo nuovo, con le corrispondenze parziali a metà strada. In un prodotto maturo la maggior parte di ogni rilascio è riutilizzo; al primo lancio quasi tutto è nuovo.
Riutilizzo della memoria. Un fornitore che parte dalla vostra memoria esistente fattura solo ciò che è davvero nuovo; uno che non può usarla fattura tutto da capo. Per questo la proprietà della memoria di traduzione conta quanto la tariffa.
Numero di lingue. I costi crescono in modo quasi lineare con le lingue, quindi verificate se ogni componente serve davvero in ogni lingua.
Frequenza dei rilasci e dimensione dei lotti. Ogni lotto comporta un impegno fisso per gestione dei file, controlli e project management. Lotti regolari e pianificati sono efficienti, stringhe inviate una alla volta no.
Contesto, qualità dei file e ambito dei test. File puliti, con commenti e screenshot, si traducono più in fretta e con meno domande. Il contesto mancante si paga due volte, nelle domande e poi nelle correzioni dopo i test. QA nel contesto e revisione nel mercato richiedono un impegno da pianificare, non da scoprire.
Un esempio semplice mostra perché il riutilizzo pesa così tanto. Supponiamo che un rilascio modifichi 2.000 parole di interfaccia: 1.200 nuove, 500 corrispondenze parziali e 300 già presenti nella memoria. Su dieci lingue sono 12.000 parole nuove da tradurre, 5.000 da adattare e 3.000 da verificare, non 20.000 parole tradotte da zero. Un fornitore che riporta questa suddivisione a ogni consegna rende spiegabile il costo di ogni rilascio.
Gli errori più comuni e quanto costano
Tradurre prima che le stringhe siano stabili. Il testo ancora in revisione viene tradotto, ritradotto e cambiato di nuovo, e ogni giro si paga.
Inviare stringhe senza contesto. Le etichette ambigue vengono interpretate, le ipotesi sembrano plausibili e gli errori li trovano i clienti prima dei tester.
Lasciare a ogni fornitore la propria memoria. Quando cambiate fornitore, o app e manuale vanno a fornitori diversi, la formulazione approvata si perde e la terminologia diverge.
Cosa inviare al fornitore e come sceglierlo
Un brief completo, spesso chiamato kit di localizzazione, permette al fornitore di fare un preventivo preciso e di partire senza un giro di domande. Per un rilascio software dovrebbe contenere:
- i file di risorse con le stringhe nuove e modificate evidenziate, più eventuali contenuti di help o documentazione;
- lingue e varianti locali di destinazione, e quali componenti servono in ciascuna;
- il contesto: screenshot o accesso a una build di test, commenti alle stringhe e limiti di caratteri;
- glossario, guida di stile e memoria di traduzione esistente, se li avete;
- il calendario dei rilasci, la frequenza dei lotti e il referente per le domande.
Quando confrontate i fornitori, fate domande che rivelino come lavorano. Sanno elaborare i vostri formati in modo nativo e restituirli senza chiavi o segnaposto danneggiati? Quali controlli automatici eseguono prima della consegna? Ogni traduzione è revisionata da un secondo linguista qualificato? Partono dalla vostra memoria esistente, potete esportarla in qualsiasi momento e come indicano cosa era nuovo e cosa riutilizzato? La nostra guida su come scegliere un fornitore di traduzioni tecniche aggiunge altre domande utili, e l’articolo sul controllo qualità delle traduzioni spiega quali prove chiedere prima di affidare un progetto.
Come lavora DEMA Solutions sulla localizzazione del software
I nostri servizi di localizzazione software per il settore tecnologico sono pensati per i team di prodotto che rilasciano di continuo. Le stringhe nuove e modificate vengono tradotte a ogni release, seguendo la cadenza dei vostri sprint invece di essere raggruppate in grandi progetti occasionali. File JSON, XML e altri file di risorse tornano nella loro struttura originale, senza estrazione manuale e senza chiavi danneggiate, e controlli automatici cercano variabili danneggiate, stringhe troncate ed errori di formattazione prima che arrivino in una build di rilascio.
I traduttori sono linguisti tecnici madrelingua che lavorano con la terminologia software e per sviluppatori, e il processo è certificato ISO 17100, con un secondo linguista qualificato che revisiona ogni traduzione, come descritto nella pagina sulle nostre traduzioni di qualità. I vostri ingegneri e product manager possono revisionare direttamente nell’ambiente di traduzione invece che su fogli di calcolo esportati, così le correzioni arrivano subito nella memoria. Memoria e glossari restano vostri, esportabili in qualsiasi momento in formati portabili come TMX e TBX, e i report di leverage mostrano quanta parte di ogni rilascio è riutilizzo. I nostri team in Italia, Serbia e Spagna seguono anche help, documentazione API, note di rilascio e manuali, con un team DTP interno per i formati impaginati, perché interfaccia e documenti parlino la stessa terminologia.
Dove si inserisce TUBE
Per i prodotti con rilasci continui, TUBE è la nostra soluzione per tenere ogni ciclo di localizzazione sotto il vostro controllo. Il vostro glossario e la vostra memoria di traduzione governano la traduzione automatica, ogni traduzione approvata confluisce in una memoria di vostra proprietà ed esportabile, e i report di leverage mostrano quanta parte di ogni aggiornamento proviene da testo già approvato.
Domande frequenti
Internazionalizzare il codice, estrarre le stringhe, pseudo-localizzare, preparare il contesto, concordare terminologia e stile, tradurre e revisionare, testare la build tradotta nel contesto, poi rilasciare e riportare le correzioni nella memoria di traduzione. Con rilasci frequenti il ciclo si ripete solo sulle stringhe nuove e modificate.
L'internazionalizzazione rende il prodotto pronto per qualsiasi lingua: stringhe esternalizzate, gestione dei plurali, formati basati sulla lingua e layout flessibili. La localizzazione lo adatta a una lingua e a un mercato specifici, comprese traduzione e test. La prima si fa una volta e si mantiene, la seconda si ripete per ogni lingua e ogni rilascio.
Quello che il vostro sistema di build produce in modo affidabile e che mantiene intatti chiavi, segnaposto e contesto. XLIFF è il formato di scambio più robusto; JSON, RESX, PO e i file di stringhe delle piattaforme funzionano bene se i segnaposto sono coerenti e il contesto viene fornito.
Sostituisce le stringhe di partenza con testo allungato e accentato tra marcatori visibili, così testo scritto nel codice, troncamenti e problemi di codifica emergono prima della traduzione vera. Conviene usarla prima delle prime lingue e ogni volta che si aggiungono funzioni importanti.
Dipende da quanto testo è davvero nuovo, da quanto si può riutilizzare da una memoria di traduzione, dal numero di lingue, dalla frequenza dei rilasci e dall'ambito dei test. Chiedete preventivi che indichino separatamente testo nuovo, corrispondenze parziali e testo riutilizzato, così potete confrontare i fornitori sulla stessa base.
Può aiutare per contenuti ampi e ripetitivi come help center e documentazione, se lavora su glossario e memoria approvati e un linguista qualificato rivede l'output. Le stringhe brevi dell'interfaccia sono ambigue e molto visibili, quindi in genere richiedono un traduttore umano e una revisione.
Contrassegnate le stringhe come stabili prima della traduzione, inviate solo stringhe nuove e modificate con il contesto, usate una sola memoria e un solo glossario per tutti i contenuti e concordate con il fornitore tempi fissi per ogni lotto.
Pianificate il prossimo rilascio multilingue
Se state preparando il primo rilascio localizzato, o se il vostro processo attuale fatica a stare al passo con gli sprint, raccontateci prodotto, formati di file e lingue di destinazione. Esamineremo i vostri file e vi proporremo un flusso di localizzazione adatto al vostro ciclo di rilascio.
Come possiamo aiutarvi?
Abbiamo le risposte giuste alle vostre domande.