Localizzazione SaaS per rilasci continui: come tenere ogni lingua al passo con i vostri sprint
La localizzazione SaaS funziona con rilasci settimanali quando la traduzione entra a far parte della pipeline di consegna: le stringhe nuove e modificate arrivano ai traduttori non appena sono stabili, tornano attraverso lo stesso repository, vengono testate nel loro contesto e vanno in produzione insieme alla lingua di partenza. Un’unica memoria di traduzione e un unico glossario mantengono coerente ogni rilascio. DEMA Solutions localizza app, contenuti di assistenza e note di rilascio per i team software europei.
A chi è rivolta questa guida
Questa guida è pensata per chi porta avanti la localizzazione in un’azienda di prodotto che non smette mai di rilasciare: product manager che promettono nuove funzionalità in più mercati contemporaneamente, responsabili dello sviluppo che gestiscono la build e i file delle stringhe, localization manager che fanno da ponte tra loro e un fornitore di traduzioni. Dà per scontato che conosciate già le basi del processo di localizzazione del software, come l’esternalizzazione delle stringhe e i file di risorse, e si concentra su ciò che cambia quando il prodotto viene rilasciato ogni settimana o a ogni sprint.
Le domande affrontate qui sono operative: freeze o flusso, come viaggiano i file, come testare ciò che non si sa leggere e quanto dovrebbe costare un rilascio. Se il vostro prodotto è un software di macchina, come un pannello HMI o l’interfaccia di un controllore fornito con l’impianto, la nostra guida alla traduzione dell’interfaccia per HMI e software di macchina tratta quel caso, che ha vincoli propri.
Che cosa significa localizzazione SaaS quando si rilascia ogni settimana
In un progetto tradizionale, la localizzazione inizia quando il contenuto è finito. Un prodotto SaaS non è mai finito: l’interfaccia cambia a piccoli incrementi, le funzionalità vengono attivate prima per alcuni clienti, i flussi di onboarding vengono testati in più varianti e il centro assistenza cresce a ogni rilascio.
Per un SaaS, quindi, la localizzazione ha un’unità di lavoro diversa. Non è un documento, ma un insieme di modifiche: le stringhe aggiunte o modificate dall’ultima consegna, più gli articoli di assistenza, le notifiche e le note di rilascio che le descrivono. Questo cambiamento ha tre conseguenze. La velocità nasce dal flusso, non dagli sforzi eroici: le stringhe stabili inviate a ogni sprint tornano entro lo sprint, mentre un lotto trimestrale arriva sempre in ritardo. La coerenza dipende da risorse condivise, perché il traduttore di oggi potrebbe non essere quello del mese scorso. E il costo per rilascio diventa il numero che conta, perché il budget si spende in modo continuo.
String freeze o flusso continuo: scegliere un modello di rilascio
Esistono due modi fondamentali per inserire la traduzione in un ciclo di rilascio, e la maggior parte dei team maturi finisce per combinarli.
Uno string freeze fissa, prima di ogni rilascio, una data dopo la quale nessun testo visibile all’utente può cambiare. Tutto ciò che è congelato va in traduzione, torna, viene testato e viene rilasciato. Il modello è semplice, prevedibile e facile da mettere a budget. È adatto a prodotti con rilasci mensili o trimestrali, a contenuti regolamentati in cui ogni formulazione deve essere approvata e ai team che localizzano per la prima volta. Il suo punto debole è il vuoto che crea: se il freeze cade tre giorni prima del rilascio e traduzione, revisione e test ne richiedono cinque, o le lingue escono in ritardo, o il freeze viene anticipato e gli sviluppatori perdono flessibilità.
La localizzazione continua elimina il freeze come evento unico. Le stringhe vengono inviate in traduzione non appena sono contrassegnate come pronte, di solito quando un feature branch viene integrato o una pull request viene approvata, e le traduzioni rientrano con lo stesso ritmo. Il giorno del rilascio la maggior parte del testo è già stata tradotta e revisionata, e restano solo le modifiche dell’ultimo minuto. In pratica è questo che significa localizzazione agile: la traduzione procede in parallelo allo sviluppo invece che dopo.
Il flusso continuo richiede più disciplina di un freeze, non meno. Le stringhe devono essere davvero stabili prima di lasciare il repository, altrimenti la stessa frase viene tradotta tre volte mentre la formulazione si assesta. Un flag “pronto per la traduzione” o un breve periodo di attesa dopo il merge risolve gran parte del problema.
La scelta dipende da quanto spesso rilasciate, da quanto testo cambia, da quanto rapidamente qualcuno da parte vostra risponde alle domande dei traduttori e da quanto rischio comporta una traduzione mancante. Un compromesso utile è il flusso continuo per le stringhe dell’interfaccia e i contenuti di assistenza, con un breve freeze per le note di rilascio e i testi degli store, che vengono scritti per ultimi e letti per primi.
Collegare il repository al flusso di traduzione
Il collo di bottiglia più comune nella localizzazione continua non è la velocità di traduzione, ma la gestione dei file. Quando uno sviluppatore esporta le stringhe a mano, le invia per email, aspetta e ricopia il file restituito nella cartella giusta, ogni rilascio aggiunge un giorno e un’occasione per sovrascrivere qualcosa. L’obiettivo è che le stringhe viaggino tra il repository del codice e l’ambiente di traduzione senza passaggi manuali.
Nello schema più semplice, un job pianificato esporta le stringhe nuove e modificate dal branch principale verso una posizione condivisa, e i file tradotti vengono restituiti lì perché la build li prelevi. In una configurazione più stretta, l’ambiente di traduzione è collegato direttamente al repository: rileva le modifiche nei file della lingua di partenza, crea le attività di traduzione e, quando una lingua è completa, apre una pull request che i vostri sviluppatori revisionano e integrano come qualsiasi altra modifica.
Qualunque schema scegliate, tre regole lo rendono sicuro. I file delle lingue di destinazione dovrebbero essere scritti solo dal flusso di traduzione, così che le modifiche manuali non spariscano alla sincronizzazione successiva. Le chiavi devono essere stabili, perché una chiave rinominata appare come una stringa eliminata più una nuova, e la traduzione esistente va persa. La strategia dei branch va concordata in anticipo: tradurre ogni feature branch spreca lavoro su funzionalità che non verranno mai rilasciate, mentre tradurre solo il branch di rilascio lascia troppo poco tempo, per cui molti team traducono dal branch principale dopo il merge.
Chiedete al vostro fornitore esattamente come gli arrivano i file e come tornano indietro. La gestione nativa di JSON, XML e dei file di stringhe delle varie piattaforme, restituiti senza chiavi corrotte né cambi di codifica, elimina un’intera categoria di errori di build.
Memoria di traduzione e glossario da un rilascio all'altro
Un prodotto che rilascia cinquanta volte l’anno genera cinquanta piccole consegne di traduzione. Senza un’unica memoria di traduzione alle spalle, il prodotto accumula lentamente tre versioni di “workspace”, due modi diversi di rivolgersi all’utente e verbi incoerenti sui pulsanti.
È la memoria di traduzione a rendere la localizzazione continua economica e coerente. Ogni traduzione approvata viene memorizzata insieme al testo di partenza, così quando una stringa ricompare, identica o leggermente modificata, la formulazione approvata viene riutilizzata e si traduce solo la differenza. La memoria dovrebbe appartenere a voi, non al fornitore, ed essere esportabile in qualsiasi momento in un formato portabile: per questo essere proprietari della propria memoria di traduzione conta per i prodotti SaaS più che per quasi qualsiasi altro tipo di contenuto.
Il glossario svolge lo stesso compito per i termini. Un prodotto SaaS ha un vocabolario ridotto e usato in modo intensivo: nomi delle funzionalità, nomi dei piani, tipi di oggetto, azioni. Ognuno richiede una traduzione approvata per lingua, oltre alla decisione su quali nomi restano in inglese. Il product marketing rinomina spesso le funzionalità, quindi il glossario ha bisogno di un responsabile che lo aggiorni prima che le nuove stringhe partano, non dopo che gli utenti hanno visto il vecchio termine. Il nostro articolo su come mantenere la terminologia coerente tra traduttori e fornitori spiega come costruire e aggiornare un glossario di questo tipo.
Le scelte di stile vanno accanto al glossario. In tedesco, italiano e spagnolo vi rivolgete agli utenti in modo formale o informale? I pulsanti sono verbi o sostantivi? Come si formulano i messaggi di errore? Una breve guida di stile per la traduzione per ogni lingua risponde a queste domande una volta per tutte, così che ogni traduttore e revisore applichi le stesse regole rilascio dopo rilascio.
Contesto, revisione in contesto e test di localizzazione
Le stringhe dell’interfaccia sono brevi e ambigue. “Archive” può essere un verbo o un sostantivo, e “Free” può riferirsi al prezzo o alla disponibilità. Nella localizzazione continua il rischio cresce, perché i traduttori vedono una manciata di stringhe per lotto anziché l’intero prodotto. Il contesto dovrebbe accompagnare ogni insieme di modifiche: un commento su ogni chiave ambigua, una nota su che cosa contiene ciascun segnaposto, la lunghezza massima dove lo spazio è fisso e, idealmente, uno screenshot o un link all’ambiente di staging.
Il test di localizzazione è il passaggio che trasforma traduzioni corrette in un prodotto corretto. Si compone di due parti. I controlli funzionali confermano che la build localizzata funziona: nessun testo inglese inserito direttamente nel codice, nessuna etichetta troncata, nessun segnaposto corrotto, formati corretti per date, numeri e valute e nessun carattere che non viene visualizzato. Molti di questi controlli si possono automatizzare ed eseguire a ogni build. Il test linguistico, a volte chiamato revisione in contesto, è svolto da una persona che conosce la lingua: percorre i principali flussi utente in un ambiente di staging e verifica che ogni traduzione sia adatta al suo contesto, che la terminologia sia coerente da una schermata all’altra e che nulla suoni come un frammento.
Non serve un test linguistico completo di ogni lingua ogni settimana. Un ritmo pratico prevede controlli automatici a ogni build, revisione in contesto delle nuove funzionalità e un passaggio completo in occasione dei rilasci principali o del lancio di nuove lingue. Ogni correzione deve tornare nella memoria di traduzione, non solo nella build, altrimenti l’errore si ripresenta alla sincronizzazione successiva. La nostra guida su come verificare la qualità delle traduzioni di un fornitore descrive come impostare una fase di revisione che produca un feedback utilizzabile anziché preferenze personali.
Vincoli dell'interfaccia mobile: lunghezza, plurali, genere e scritture da destra a sinistra
La localizzazione delle app mobili aggiunge vincoli che le interfacce web spesso riescono ad assorbire: poco spazio sullo schermo, etichette della barra delle schede e dimensioni dinamiche del testo.
Lunghezza. Il testo tradotto è spesso più lungo dell’inglese, e sono le stringhe brevi a espandersi di più in proporzione: un pulsante di due parole può raddoppiare di lunghezza in tedesco o in finlandese. Fissate limiti di caratteri per le stringhe in spazi fissi, testate presto con la lingua più lunga e consentite ai traduttori di proporre una formulazione più breve invece di imporre un’abbreviazione che nessuno capisce.
Plurali. L’inglese richiede due forme (“1 file”, “2 files”). Molte lingue ne richiedono di più: il polacco distingue tra uno, pochi e molti; l’arabo usa fino a sei categorie. Entrambe le principali piattaforme mobili e i formati di messaggio più diffusi supportano le categorie di plurale, ma solo se gli sviluppatori le usano invece di concatenare un numero e una parola.
Genere e concordanza. Nelle lingue romanze e slave, così come in tedesco, aggettivi, participi e a volte verbi concordano con il genere del sostantivo o della persona. Una stringa come “{name} è stato invitato” può richiedere forme diverse a seconda di chi viene invitato. Dove il prodotto conosce il genere o il tipo di oggetto rilevante, stringhe separate o formati di messaggio di tipo select permettono ai traduttori di scrivere frasi corrette; dove non lo conosce, i traduttori devono saperlo per poter trovare una formulazione neutra.
Scritture da destra a sinistra. Arabo ed ebraico rispecchiano il layout: navigazione, icone con una direzione e indicatori di avanzamento si capovolgono, mentre numeri e testo latino incorporato continuano a scorrere da sinistra a destra. Il supporto delle scritture da destra a sinistra è un compito di sviluppo che va testato su dispositivi reali prima di poter giudicare la traduzione.
Schede negli app store, note di rilascio e centro assistenza
L’interfaccia è solo una parte di ciò che gli utenti leggono. Per un’app mobile, la scheda nello store è il primo testo localizzato che un cliente vede: titolo, sottotitolo, descrizione breve e lunga, parole chiave e didascalie degli screenshot. Ogni store fissa i propri limiti di caratteri, e la scheda è un testo di marketing, non un testo d’interfaccia, quindi richiede un traduttore che scriva in modo persuasivo entro quei limiti e verifichi come le persone di ogni mercato cercano app simili alla vostra. Le didascalie degli screenshot si dimenticano facilmente, perché si trovano nei file immagine anziché nei file delle stringhe.
Le note di rilascio vengono scritte all’ultimo minuto e lette dagli utenti più coinvolti. Riservate loro una breve finestra di traduzione fissa e riutilizzate la terminologia dell’interfaccia, così che la funzionalità citata nelle note sia la stessa che gli utenti trovano nell’app.
Il centro assistenza di solito cresce più in fretta dell’interfaccia. I suoi articoli sono lunghi, ripetitivi e aggiornati spesso, il che li rende buoni candidati per la traduzione automatica con post-editing da parte di un linguista qualificato, a condizione che il motore lavori con il vostro glossario e la vostra memoria approvati. La pagina dei nostri servizi di traduzione automatica con post-editing spiega come si prende questa decisione per ciascun tipo di contenuto. Le stringhe dell’interfaccia sono un caso diverso: sono brevi, ambigue e visibili in ogni schermata, quindi in genere richiedono un traduttore umano fin dall’inizio. Il vostro sito di marketing segue ancora un’altra logica, che la nostra analisi sul costo della traduzione di un sito web e sulle opzioni disponibili approfondisce.
Misurare il riutilizzo e il costo per rilascio
Nella localizzazione continua, la tariffa a parola spiega meno del budget rispetto alla composizione di ogni rilascio. Ogni insieme di modifiche contiene un po’ di testo davvero nuovo, un po’ di testo simile a qualcosa già tradotto e un po’ di testo identico a una traduzione approvata, per esempio una stringa spostata in una nuova schermata. La quota di testo riutilizzato si chiama leverage, ed è il numero più utile in assoluto per capire il costo.
Un esempio illustrativo: uno sprint modifica 1.500 parole di testo dell’interfaccia e dell’assistenza. Di queste, 700 sono nuove, 500 sono corrispondenze parziali con traduzioni esistenti e 300 sono ripetizioni esatte. Su sei lingue fanno 4.200 parole nuove da tradurre, 3.000 da adattare e 1.800 da verificare, anziché 9.000 parole tradotte da zero. Se il fornitore riporta questa suddivisione a ogni consegna, potete capire perché uno sprint è costato più di un altro e individuare presto i problemi: un calo improvviso del leverage spesso significa che le chiavi sono state rinominate o i file ristrutturati, e la memoria non riconosce più testo che già contiene.
Altri tre fattori incidono sul costo per rilascio. La dimensione del lotto: ogni consegna comporta un impegno fisso per la gestione dei file e i controlli, quindi le stringhe inviate una alla volta costano care. Le riscritture: il testo riformulato dopo la traduzione si paga due volte. L’ambito dei test: la revisione in contesto va pianificata per ogni rilascio, non scoperta dopo un reclamo. Nell’arco di qualche mese, i report per rilascio danno al product management una base affidabile per mettere a budget nuove lingue e nuove funzionalità.
Il processo di localizzazione di un'app in uno sprint, passo dopo passo
Ecco come si svolge di solito il processo di localizzazione di un’app all’interno di uno sprint di due settimane, una volta completata la configurazione.
All’inizio dello sprint, prodotto e design concordano quali funzionalità verranno rilasciate e in quali mercati. I nuovi termini, come il nome di una funzionalità, vengono aggiunti al glossario con le relative traduzioni prima che venga scritta qualsiasi stringa.
Durante lo sviluppo, gli sviluppatori creano le chiavi con commenti e limiti di caratteri. Quando un feature branch viene integrato, le stringhe di partenza nuove e modificate vengono rilevate automaticamente e la traduzione parte. Le domande dei traduttori arrivano a una persona designata del vostro team, che risponde entro un giorno.
A metà sprint, le traduzioni rientrano attraverso il repository come pull request o come file nella posizione concordata. Sulla build vengono eseguiti i controlli automatici: segnaposto, lunghezza, codifica e traduzioni mancanti.
Prima del rilascio, un revisore percorre le nuove funzionalità in ogni lingua nell’ambiente di staging. Note di rilascio, testi degli store e articoli di assistenza vengono tradotti in una breve finestra fissa. Ogni correzione viene apportata nell’ambiente di traduzione, così da essere salvata nella memoria.
Dopo il rilascio, il fornitore comunica il leverage per lingua, e i problemi ricorrenti, come la mancanza di contesto, vengono risolti per lo sprint successivo.
Errori frequenti nella localizzazione continua
Modificare a mano i file di destinazione. Uno sviluppatore corregge un refuso direttamente nel file tedesco; la sincronizzazione successiva lo sovrascrive oppure, peggio ancora, la correzione non arriva mai nella memoria e l’errore ricompare al rilascio seguente.
Rinominare le chiavi durante il refactoring. Per un sistema di traduzione, una chiave rinominata è una stringa nuova. Il leverage cala, le traduzioni vengono rifatte e la formulazione approvata può cambiare senza che nessuno l’abbia deciso.
Lasciare che ogni team o fornitore tenga la propria memoria. Quando app, centro assistenza e sito di marketing vengono tradotti separatamente, la terminologia diverge, e cambiare fornitore in seguito significa perdere anni di traduzioni approvate. Se state valutando un cambio, la nostra guida su come cambiare fornitore di traduzioni senza perdere la memoria di traduzione spiega che cosa mettere al sicuro per prima cosa.
Come scegliere un fornitore di localizzazione SaaS
Il fornitore giusto per un ciclo di rilascio continuo è quello il cui modo di lavorare si adatta alla vostra pipeline, non semplicemente il più economico a parola. Queste domande rivelano gran parte di ciò che vi serve sapere:
- Come vi arrivano i file e come tornano indietro, e potete elaborare in modo nativo i nostri formati di risorse senza corrompere chiavi o segnaposto?
- Quali tempi di consegna potete garantire per un tipico lotto di sprint, e come gestite le stringhe urgenti?
- Quali controlli automatici eseguite prima della consegna, e ogni traduzione viene rivista da un secondo linguista qualificato?
- I nostri ingegneri o product manager possono revisionare le traduzioni nel loro contesto, e le loro correzioni aggiornano la memoria?
- A chi appartengono la memoria di traduzione e il glossario, e possiamo esportarli in qualsiasi momento in un formato standard?
- Riportate il testo nuovo, con corrispondenza parziale e riutilizzato per ogni rilascio e per ogni lingua?
Le risposte contano più di qualsiasi certificato pubblicato su un sito, anche se un processo certificato come la ISO 17100 vi dice che la revisione da parte di un secondo linguista è prassi standard e non un extra opzionale.
Come DEMA Solutions supporta i team SaaS e app
I nostri servizi di localizzazione di software e app sono pensati per team di prodotto che rilasciano in modo continuo. Le stringhe nuove e modificate vengono rilevate e tradotte a ogni rilascio, seguendo la cadenza dei vostri sprint anziché essere raccolte in grandi progetti occasionali. I file JSON, XML e gli altri file di risorse vengono elaborati e restituiti nella loro struttura originale, senza un passaggio manuale di estrazione e senza chiavi corrotte. I controlli automatici cercano variabili corrotte, stringhe dell’interfaccia troncate ed errori di formattazione prima che qualcosa arrivi in una build di rilascio.
I traduttori sono linguisti tecnici madrelingua abituati alla terminologia del software e degli sviluppatori. I vostri ingegneri e product manager possono revisionare direttamente nell’ambiente di traduzione anziché in fogli di calcolo esportati, così le correzioni terminologiche finiscono subito nella memoria. Il processo è certificato ISO 17100, con un secondo linguista qualificato che rivede ogni traduzione, come descritto nella nostra pagina sulla qualità.
La memoria di traduzione, i glossari e le basi terminologiche vengono costruiti a partire dalla terminologia del vostro prodotto e restano vostri, esportabili su richiesta in qualsiasi momento in formati portabili come TMX e TBX. I report sul leverage mostrano quanta parte di ogni rilascio è stata riutilizzata. Oltre all’interfaccia, i nostri team in Italia, Serbia e Spagna traducono centri assistenza e knowledge base, documentazione API e per sviluppatori, note di rilascio e changelog, così che il prodotto e tutto ciò che lo circonda condividano un’unica terminologia.
Dove si inserisce TUBE
TUBE è la nostra soluzione per i prodotti che rilasciano in modo continuo, in cui ogni sprint significa un nuovo ciclo di localizzazione. Il vostro glossario e la vostra memoria di traduzione guidano la traduzione automatica, ogni traduzione approvata confluisce in una memoria che è vostra e che potete esportare, e i report sul riutilizzo mostrano quanta parte di ogni aggiornamento proviene da testi che avete già approvato.
Domande frequenti
La localizzazione SaaS è l'adattamento di un prodotto software in cloud, compresi interfaccia, onboarding, notifiche, centro assistenza e note di rilascio, per utenti di altre lingue e mercati. Poiché il prodotto cambia di continuo, è organizzata come un flusso ricorrente di piccoli aggiornamenti anziché come un progetto di traduzione una tantum.
La localizzazione continua invia in traduzione le stringhe nuove e modificate non appena sono stabili, invece di raccoglierle per uno string freeze prima di ogni rilascio. Le traduzioni rientrano con lo stesso ritmo, così ogni lingua può uscire insieme alla lingua di partenza anziché settimane dopo.
Non necessariamente per l'intero prodotto. Molti team lasciano scorrere in modo continuo le stringhe dell'interfaccia e i contenuti di assistenza e mantengono un breve freeze per i testi più visibili o dell'ultimo minuto, come note di rilascio, pagine dei prezzi e schede negli store.
I controlli funzionali confermano che la build localizzata funziona: nessun testo inserito direttamente nel codice, troncamento, segnaposto corrotto o formato errato. Il test linguistico verifica, su schermate reali, che ogni traduzione sia adatta al suo contesto e che la terminologia sia coerente.
Usate un'unica memoria di traduzione e un unico glossario per tutti i contenuti del prodotto, aggiornate il glossario prima che i nuovi termini compaiano nelle stringhe, apportate le correzioni nell'ambiente di traduzione anziché nei file di destinazione e mantenete stabili le chiavi delle stringhe.
Pianificate il budget per rilascio anziché per anno, in base al volume di testo nuovo, con corrispondenza parziale e riutilizzato in ciascuna lingua. I report sul leverage dei rilasci precedenti sono la base più affidabile per stimare il costo di nuove funzionalità e nuove lingue.
Spesso funziona bene per gli articoli del centro assistenza e la documentazione, quando lavora sul vostro glossario e sulla vostra memoria approvati e un linguista qualificato esegue il post-editing del risultato. Le stringhe brevi dell'interfaccia e le schede negli store di solito richiedono un traduttore umano fin dall'inizio.
Pianificate una localizzazione che tenga il passo con i vostri rilasci
Se le vostre lingue escono dopo la lingua di partenza, o se ogni rilascio porta con sé una nuova serie di incoerenze, raccontateci il vostro prodotto, la cadenza dei rilasci e le lingue di destinazione. Esamineremo i vostri file di risorse e vi proporremo un flusso di localizzazione che si inserisca nei vostri sprint.
Come possiamo aiutarvi?
Abbiamo le risposte giuste alle vostre domande.