Localizzazione di software grandi e agili: caso di studio Kaspersky

Guidare gli sforzi di localizzazione di una grande azienda di software è di per sé una sfida. Cosa succede quando questa azienda passa alle pratiche Agile? Beh, le sfide diventano ancora più impegnative e bisogna implementare cambiamenti drastici, in fretta. In questo caso di studio, Ekaterina Galitskaya e Darya Egorushkina del team di documentazione e localizzazione di Kaspersky si immergono nel loro percorso di miglioramento delle capacità e dell'efficienza dei loro processi con Smartcat.

Testo aggiuntivo di Ekaterina & Darya

Il nostro team è responsabile della redazione e della localizzazione dei testi dell'interfaccia utente e degli articoli del centro assistenza per le app di sicurezza mobile dell'azienda. Di seguito vi spiegheremo come abbiamo iniziato a localizzare le app di sicurezza mobile in modo più affidabile, agile e automatizzato. Inizieremo con le difficoltà che ci hanno portato alla necessità di cambiare qualcosa, per poi illustrarvi le sfide che abbiamo affrontato e le soluzioni che abbiamo trovato. Ci auguriamo che questo articolo sia interessante per tutte le aziende di software di medie e grandi dimensioni che devono affrontare la sfida di implementare l'Agile non solo nello sviluppo, ma anche in tutti gli aspetti correlati.

Come molte altre aziende, anche Kaspersky era passata alle pratiche di sviluppo Agile. Ciò ha portato naturalmente a cicli di rilascio molto più brevi. Se prima lanciavamo nuove versioni dell'app ogni pochi mesi, ora lo facevamo ogni due settimane. Certo, ora c'erano meno stringhe in ogni nuova versione, ma questo non era di grande aiuto: dovevamo comunque sottoporre queste poche stringhe all'intero processo di localizzazione e di test linguistici, con scadenze molto più strette.

C'è anche un malinteso comune secondo cui le app mobili contengono solo una piccola quantità di testo. Magari fosse così! Nel nostro caso, ad esempio, avevamo in media circa 25.000 parole per app solo nei testi dell'interfaccia utente, moltiplicate per circa 10 app e per circa 20 lingue di destinazione per ciascuna app. Il tutto con nuovi testi dell'interfaccia utente e della documentazione che arrivavano ogni settimana.

Di conseguenza, la localizzazione è diventata essenzialmente il collo di bottiglia dell'intero processo di lancio del prodotto. E se prima i product manager non conoscevano nemmeno i nomi dei membri del team di localizzazione (perché avrebbero dovuto, visto che tutte le traduzioni apparivano "magicamente da sole"?), ora erano consapevoli di tutte le questioni coinvolte a un livello molto più profondo di quanto avrebbero mai voluto.

In Kaspersky, il processo di localizzazione consiste generalmente in due fasi: traduzione e test linguistico.

Il problema generale nella fase di traduzione era che il lavoro manuale era eccessivo, sia a causa del processo utilizzato che dei limiti dello strumento CAT. Nello specifico:

• Poiché le pipeline multibranch non erano supportate, abbiamo dovuto creare manualmente i delta per la traduzione e successivamente reinserirli nei branch.

• Era impossibile garantire la coerenza tra le app e le lingue.

• Non potevamo eseguire parallelamente ulteriori traduzioni richieste, ad esempio se i testi di origine venivano modificati durante il processo. Dovevamo invece attendere che il pacchetto di traduzione di base fosse pronto e solo allora procedere con quelli aggiuntivi.

• I build falliti a causa di errori nei "non traducibili", apostrofi non escapati e altri errori umani stavano diventando sempre più un problema.

Per quanto riguarda la fase di verifica linguistica, potrebbe richiedere fino a due settimane, rispetto ai tre-cinque giorni necessari per la traduzione vera e propria. "Che cos'è la verifica linguistica?", vi chiederete.

Lo scopo principale dei test linguistici è quello di verificare l'intera traduzione nel suo contesto. Abbiamo un solido team di traduttori che conoscono bene la nostra terminologia. Tuttavia, quando si traduce un testo senza vedere ciò che lo circonda o anche solo se si tratta di un pulsante o di un'intestazione, le cose possono andare rapidamente male.

Il test linguistico comporta quindi il controllo manuale di tutte le schermate dell'app risultanti, solitamente tramite screenshot. Aiuta a identificare problemi quali

• Il testo è troppo lungo per le dimensioni dell'elemento dello schermo. A volte ciò può comportare implicazioni legali, se il testo omesso include dichiarazioni di non responsabilità o informazioni finanziarie.

• Testo non tradotto, a causa di un errore del traduttore o perché era hardcoded invece che esternalizzato come string,

• Testo tradotto in un contesto errato, ad esempio quando il testo su un pulsante, come "Scarica", è grammaticalmente un imperativo invece che un infinito.

Solo la parte relativa agli screenshot richiedeva una quantità esorbitante di tempo. Ad esempio, se una nuova funzionalità comprendeva 40 schermate dell'interfaccia utente e c'erano 20 lingue di destinazione, potevano essere necessarie fino a 70 ore di lavoro manuale e meccanico.

Tutto sommato, era una situazione accettabile quando le nuove versioni venivano rilasciate ogni tre mesi. Ma con il passaggio a rilasci bisettimanali, questo ha iniziato a pesare sul team di localizzazione. Era necessario risolvere il problema, e in fretta.

1. Assumere lavoratori con poca esperienza e ridurre il volume di lavoro di localizzazione, con un conseguente calo della qualità, OPPURE
2. Automatizzare il processo.

Abbiamo optato per la seconda soluzione.

Nella scelta della soluzione CAT/TMS, le nostre priorità principali erano:

1. Meno approvazioni interne — approvazione dei budget, generazione di chiavi seriali e tutto il resto,

2. Funzionalità di base pronte all'uso , in modo da poter iniziare a utilizzarla immediatamente senza dover attendere lo sviluppo di ulteriori funzionalità,

3. Requisiti server leggeri , sempre per evitare lunghe approvazioni,

4. Accesso al servizio conveniente, preferibilmente gratuito.

5. Supporto adeguato da parte del servizio per non dover assumere uno sviluppatore interno,

6. Requisiti di sicurezza — siamo noi a collegarci al servizio, e non il contrario,

7. Supporto multibranch — per tradurre diverse funzionalità in parallelo,

8. Traduzioni aggiuntive possibili in parallelo con il lotto originale.

Quando abbiamo stilato una lista di opzioni, alla fine sono rimasti solo due nomi: Smartcat e Zing, un server di localizzazione continua creato dai creatori di Evernote.

Zing ci è piaciuto per la sua personalizzazione, il pacchetto di installazione gratuito e l'accesso privato: potevamo ospitarlo all'interno della nostra organizzazione. Il lato negativo era che il processo di installazione era tutt'altro che facile, quindi l'inserimento di tutti i nostri traduttori e del nostro personale avrebbe reso troppo elevati i costi in termini di tempo per la gestione del servizio.

Alla fine abbiamo scelto Smartcat. Poiché non ci è consentito collegare direttamente gli strumenti CAT al nostro VCS interno, abbiamo optato per l'utilizzo di un pacchetto Smartcat–Serge. (Serge è un software open source che sincronizza le stringhe tra i sistemi di controllo delle versioni e di gestione delle traduzioni. Identifica le stringhe in file di vari formati e le converte nel formato PO standard del settore, che poi invia a Smartcat. Possiamo installarlo direttamente sui nostri server, quindi nessuna delle nostre informazioni riservate finisce all'esterno.)

Ecco cosa ci è piaciuto di più della soluzione risultante:

• Supporta tutti i nostri requisiti: pipeline multibranch, traduzioni aggiuntive, sicurezza, ecc.

• Riceviamo aggiornamenti in tempo reale, senza bisogno di scaricare o installare nulla,

• Possiamo creare i nostri schemi di analisi sintattica per le stringhe grazie al bundle Smartcat–Serge,

• Possiamo comunicare con i traduttori che lavorano sui nostri documenti senza uscire dalla piattaforma,

• Possiamo trovare liberi professionisti direttamente sul marketplace della piattaforma, se abbiamo bisogno di aumentare la produzione,

• Possiamo pagare tutte le lingue e tutti i progetti con un'unica fattura,

• Apprezziamo molto il supporto che riceviamo : il team di Smartcat ci ha aiutato a mettere in piedi il nostro flusso di lavoro e ha dato priorità ad alcune delle funzionalità che erano fondamentali per noi. — alla fine abbiamo optato per un abbonamento grazie alla funzione di ricerca testuale a livello di progetto, ma questa scelta era facoltativa.

Alcune delle sfide che abbiamo affrontato sono state:

• Inizialmente, non era possibile cercare del testo all'interno di tutti i documenti di un progetto, ma ora questo non è più un problema, poiché Smartcat ha implementato questa funzione.

• Il project manager deve inviare manualmente gli inviti ai traduttori, ma abbiamo saputo che questa procedura sarà presto automatizzata.

Considerando la nostra esperienza con Smartcat fino ad ora, siamo fiduciosi che il loro team stia già lavorando per risolvere questi problemi.

Per mettere le cose in prospettiva, ecco un confronto tra ciò che avevamo e ciò che abbiamo ora, sia in termini di processo che di numeri.

Prima

Prima delle modifiche, dovevamo seguire quasi 30 passaggi nelle fasi di traduzione e verifica linguistica:

Traduzione:

1. Recuperare i testi dai diversi rami nel repository, manualmente,

2. Creare un delta per la traduzione, manualmente,

3. Creare pacchetti per la traduzione,

4. Caricarli su un server FTP,

5. Scrivere una marea di e-mail ad agenzie, liberi professionisti o uffici locali,

6. Scaricare la traduzione dal server FTP una volta pronta,

7. Caricarla nello strumento CAT e assicurarsi che tutto sia a posto,

8. Caricare le stringhe tradotte nel repository cercando di non confondere i rami, manualmente,

9. Eseguire una compilazione, correggere gli errori, completare la compilazione,

10. Richiedere ulteriori traduzioni, ripetendo essenzialmente lo stesso processo.

Test linguistici:

1. Avviare la compilazione e attendere il completamento,

2. Riavviare la compilazione se non è andata a buon fine a causa di errori di localizzazione,

3. Configurare un ambiente di test speciale, se non è presente un menu di debug,

4. Acquisire tutti gli screenshot pertinenti per oltre 20 lingue,

5. Scoprire, insieme al team QA, come ottenere gli screenshot ancora mancanti,

6. Creare e denominare i pacchetti di screenshot,

7. Caricarli sul server FTP,

8. Assegnare i compiti alle agenzie di traduzione per controllare le traduzioni,

9. Rispondere alle domande delle agenzie,

10. Accettare i compiti e apportare le modifiche,

11. Eseguire la compilazione, che a volte richiede molto tempo,

12. Ripetere la compilazione in caso di errori,

13. Acquisire screenshot per i test regressivi,

14. Caricare nuovamente gli screenshot e assegnare i compiti alle agenzie di traduzione,

15. Discutere nuovamente tutto con le agenzie,

16. Eseguire nuovamente un altro ciclo di test regressivi se sono state apportate modifiche alla traduzione.

Dopo

Ora abbiamo solo nove passaggi in tutte le fasi:

1. Il copywriter inserisce le nuove stringhe in Git. Serge inserisce automaticamente le stringhe in Smartcat,

2. Il project manager della localizzazione assegna i traduttori,

3. I traduttori traducono nel contesto, con screenshot e commenti a portata di mano,

4. Il project manager della localizzazione revisiona e conferma la traduzione, che poi torna automaticamente su Git,

5. Il team di localizzazione esegue il bot di screenshot delle funzionalità per i testi localizzati,

6. Il team di localizzazione inserisce gli screenshot localizzati nel server FTP e li invia ai linguisti,

7. I linguisti controllano e correggono le traduzioni, se necessario, guardando gli screenshot localizzati,

8. Le modifiche vengono automaticamente trasferite a Git,

9. Il team di localizzazione chiude la richiesta di pull.

Ecco fatto: con questa riduzione della complessità di tre volte, sentiamo davvero la differenza rispetto a prima!

Tutti i numeri si riferiscono a una versione (ogni due settimane) e a un'applicazione.

Ulteriori vantaggi, alcuni dei quali non avevamo previsto, includono:

• Build più affidabili: grazie a placeholder, non dobbiamo più preoccuparci che il testo non traducibile venga tradotto o che gli apostrofi non vengano sostituiti, e così via.

• Smartcat ha identificato alcuni bug più vecchi grazie alle sue impostazioni di errore critico.

• Non sprecare il tempo e le risorse degli altri: non abbiamo bisogno di prendere i dispositivi di test dal team QA o di utilizzare il tempo del team di sviluppo per fare screenshot.

• Gli screenshot disponibili per i traduttori, che possono facilmente aprire e visualizzare direttamente dall'editor, hanno migliorato notevolmente la qualità delle traduzioni.

Potremmo continuare, e siamo certi che con il tempo troveremo altri modi per migliorare sia l'efficienza che la qualità dei nostri processi di localizzazione. Ma soprattutto, la localizzazione non è più un collo di bottiglia nel ciclo di rilascio. Riteniamo che ottenere questi risultati in un lasso di tempo così breve sia stato un risultato straordinario sia per il nostro team che per la piattaforma Smartcat.

Ecco alcuni passi concreti che abbiamo intrapreso dopo aver implementato Smartcat. Li riportiamo qui come "cheat sheet" per altre aziende e team che desiderano seguire le nostre orme. Non tutti sono facili da attuare, ma la maggior parte contribuirà a rendere il processo di localizzazione più fluido e meno soggetto a errori.

Integrazione:

• Prova l'integrazione Git–Serge–Smartcat per assicurarti che tutte le stringhe vengano trasferite ai progetti Smartcat e viceversa. È meglio evitare sorprese nella fase di produzione.

• Concordare la denominazione dei rami con gli ingegneri del software. In questo modo potrai configurare un bot che cercherà i rami specifici che devono essere localizzati, risparmiando ore di comunicazione sia a te che agli sviluppatori.

• Personalizza i parser predefiniti di Serge, se necessario. Ad esempio, abbiamo reso visibili ai traduttori gli ID delle stringhe, i commenti e i link agli screenshot di riferimento.

• Crea un cron job per trovare i rami di localizzazione in base alla maschera di nome concordata sopra.

• Valuta la possibilità di eseguire test dell'interfaccia utente e screenshot delle funzionalità utilizzando il framework Kaspresso. Ad esempio, i nostri sviluppatori inseriscono un link a uno screenshot per ogni stringa che utilizzano. Quando il file arriva su Smartcat, il link allo screenshot viene automaticamente inserito nella scheda Commenti. Per saperne di più su Kaspresso e sui motivi per cui potresti volerlo utilizzare, visita qui.

Localizzazione e test linguistici:

• Se disponi di glossari, caricali su Smartcat per garantire la coerenza delle tue localizzazioni.

• Aggiungi i tuoi linguisti interni in modo che possano esplorare la piattaforma e imparare le basi prima di ricevere incarichi effettivi da te.

• Trova e seleziona i freelance e inseriscili nei processi della tua azienda, assicurandoti che sappiano come utilizzare screenshot, commenti, glossari, ecc.

• Se necessario, trova agenzie di traduzione per ulteriori esigenze di localizzazione o test.

Speriamo che questi consigli ti siano stati utili. Facci sapere se ne hai altri da condividere!