Localizzazione di app mobile: guida tecnica per chi produce macchine

Quando si parla di localizzazione di app mobile l'immagine che viene in mente è quella di un'applicazione per il grande pubblico. Nella manifattura italiana che esporta il quadro è diverso e più interessante, perché le applicazioni che finiscono in traduzione sono strumenti di lavoro.

Le tipologie ricorrenti sono poche e riconoscibili. C'è l'app di servizio per il tecnico manutentore, che guida la diagnosi, mostra gli schemi, registra gli interventi e apre le chiamate di assistenza. C'è il catalogo ricambi in versione mobile, con esplosi navigabili e ricerca per codice, usato dal distributore mentre è davanti alla macchina. C'è il configuratore commerciale che l'agente mostra al cliente in fiera, con opzioni, varianti e calcolo del prezzo. C'è il cruscotto di supervisione collegato alla macchina, che espone parametri di processo, allarmi e contatori. E c'è sempre più spesso l'applicazione che affianca l'interfaccia della macchina, replicando in mobilità comandi e messaggi che l'operatore vede sul pannello.

Queste applicazioni hanno tre caratteristiche comuni che le rendono diverse da un'app di consumo. La prima è che il loro testo non è indipendente: ogni stringa richiama un termine che esiste già nel manuale, nel catalogo o sul pannello macchina, e deve coincidere con quello. La seconda è che l'utente non è un consumatore ma un professionista che opera in un contesto normato, dove un messaggio ambiguo può avere conseguenze operative. La terza è che il ciclo di vita è lungo: un'app di servizio segue una macchina per dieci o quindici anni e viene aggiornata a ogni revisione di prodotto.

Ne discende una conseguenza pratica: la localizzazione dell'app non è un progetto isolato, ma un ramo del processo documentale dell'azienda. Chi la tratta come un lavoro a sé si ritrova con tre nomi diversi per lo stesso componente.

È il punto in cui si rompono più applicazioni, e quasi sempre per la stessa ragione: si presume che tutte le lingue si comportino come l'italiano, con una forma singolare e una plurale.

Il repertorio CLDR di Unicode, che è il riferimento usato da entrambe le piattaforme mobili, definisce sei categorie di quantità: zero, one, two, few, many, other. Nessuna lingua le usa tutte, ma molte ne usano più di due. Il polacco distingue forme diverse a seconda della cifra finale del numero; il russo si comporta in modo analogo; l'arabo utilizza l'intera gamma, duale compreso; il cinese e il giapponese non variano affatto.

La conseguenza pratica è che una stringa costruita concatenando un numero e un sostantivo — «n pezzi prodotti» — è sbagliata per costruzione. Va dichiarata come stringa plurale nel formato nativo della piattaforma, e il traduttore deve ricevere il numero di forme che la sua lingua richiede. Se l'esportazione gli manda solo singolare e plurale, l'app in polacco mostrerà una forma scorretta per la maggior parte dei valori.

Lo stesso vale per due fenomeni meno noti ma altrettanto insidiosi.

Il genere grammaticale, che in italiano è già un problema, diventa un problema strutturale in lingue in cui l'aggettivo, il participio e talvolta il verbo si accordano con un soggetto che l'interfaccia inserisce a tempo di esecuzione. Una stringa come «elemento selezionato» funziona solo se tutti i valori possibili di elemento hanno lo stesso genere, e in una lingua di arrivo questo non è mai garantito.

L'ordine degli argomenti, che cambia da lingua a lingua. I segnaposto numerati, che permettono al traduttore di riordinare gli elementi della frase, sono l'unica soluzione: i segnaposto anonimi costringono a conservare l'ordine dell'italiano, producendo frasi innaturali o incomprensibili.

La regola generale è di non comporre mai frasi per concatenazione. Ogni frase completa deve essere una sola unità di traduzione, con i suoi segnaposto dichiarati e documentati.

Questo è il capitolo che separa i progetti riusciti da quelli che si trascinano in revisioni infinite, ed è anche quello su cui il committente ha più potere.

Un traduttore che riceve un elenco di stringhe senza contesto lavora alla cieca. La parola «Uscita» può essere un comando per chiudere l'applicazione, il nome di un connettore, una grandezza di processo o il punto di scarico di una linea. Ognuna di queste letture produce una traduzione diversa e solo una è giusta. Nell'ambito industriale l'ambiguità è la norma, non l'eccezione, perché il lessico tecnico e il lessico dell'interfaccia si sovrappongono continuamente.

Gli strumenti per risolverla esistono e costano poco.

Le note per il traduttore associate a ciascuna chiave sono il mezzo più diretto: una riga che dica «etichetta del pulsante di chiusura, massimo dodici caratteri» elimina il problema alla fonte. Entrambe le piattaforme prevedono un campo apposito, e i formati di scambio lo trasportano.

Gli screenshot associati alle chiavi sono ancora più efficaci. Diverse piattaforme di gestione delle stringhe permettono di collegare un'immagine della schermata alla stringa che vi compare; il traduttore vede dove finisce il testo che sta scrivendo.

Il glossario dell'ufficio tecnico chiude il cerchio, imponendo la resa già approvata per i termini di prodotto. È lo stesso glossario che regge il manuale d'uso e il catalogo ricambi, ed è la ragione per cui la traduzione tecnica e la localizzazione dell'app vanno tenute nello stesso processo. La differenza tra i due mestieri è reale ma non giustifica due terminologie separate: la distinzione tra localizzazione e traduzione riguarda l'adattamento, non il lessico di prodotto.

Va infine deciso, e messo per iscritto, che cosa non si traduce: codici articolo, sigle di modello, nomi di segnali e variabili, riferimenti a norme, denominazioni commerciali registrate.

Verificare le traduzioni in un foglio di calcolo non dice nulla su come si comporta l'applicazione. Il collaudo linguistico si fa a software installato, percorrendo le schermate nella lingua di arrivo, e serve a trovare una classe di difetti che nessun controllo sul testo può intercettare.

Che cosa si cerca:

• Troncamenti e sovrapposizioni, in particolare sui dispositivi con schermo piccolo e con le impostazioni di testo ingrandito attive.
• Stringhe non tradotte che riemergono dall'interno del codice, tipicamente nei messaggi di errore e nelle schermate di eccezione, cioè proprio dove servirebbero di più.
• Chiavi errate, cioè testi corretti ma nel posto sbagliato.
• Segnaposto non risolti, che a schermo appaiono come simboli o come parentesi vuote.
• Formati locali applicati male: date invertite, decimali con il separatore sbagliato, valute senza simbolo.
• Coerenza con la macchina: se l'app replica messaggi che l'operatore legge anche sul pannello, i due testi devono coincidere parola per parola. Un allarme chiamato in un modo sul pannello e in un altro sull'app costringe il tecnico a un'operazione di traduzione mentale in una situazione in cui non deve farla.
• Comportamento in lingua RTL, con verifica di allineamenti, icone direzionali e testi misti.

Su questo si innesta un servizio dedicato di collaudo di localizzazione, che ha senso attivare quando le lingue sono molte e i dispositivi di riferimento eterogenei.

L'elenco che segue raccoglie i difetti che si ripresentano con maggiore frequenza nei progetti di localizzazione di applicazioni industriali.

Stringhe scritte nel codice. Emergono sempre, e sempre nei punti peggiori: messaggi di errore, schermate di configurazione, testi di notifica. Una ricerca sistematica prima di iniziare costa meno di tre cicli di correzione.

Frasi costruite per concatenazione. Producono ordini di parole innaturali e rendono impossibile l'accordo grammaticale. Vanno rifatte come unità intere con segnaposto.

Chiavi che descrivono il testo invece della funzione. Una chiave chiamata come la frase italiana che contiene diventa incomprensibile appena la frase cambia, e favorisce il riuso sbagliato della stessa stringa in contesti diversi.

Riuso indiscriminato della stessa stringa. Due schermate che mostrano la stessa parola italiana non necessariamente mostrano la stessa parola in tedesco. Condividere la chiave per risparmiare è un falso risparmio.

Traduzione senza glossario di prodotto. Produce app che chiamano i componenti diversamente dal manuale, con effetti diretti sul carico dell'assistenza.

Nessun collaudo su dispositivo reale. Le simulazioni non riproducono le impostazioni di accessibilità, le dimensioni di testo aumentate e i comportamenti dei dispositivi più vecchi che nei reparti sono ancora in uso.

Lingue attivate senza un referente locale. Se nessuno, nella filiale o presso il distributore, è in grado di leggere la lingua attivata, gli errori non vengono segnalati e restano in produzione per anni.

Il quadro operativo alle spalle di questo lavoro è quello consueto di Italtrust: sede a Roma, oltre 3.000 linguisti madrelingua, ottanta lingue di lavoro, certificazioni ISO 17100 e ISO 27001, una piattaforma CAT proprietaria che condivide memorie e glossari tra app, manuale e catalogo, cifratura AES-256 e conformità al GDPR sui materiali affidati. Per un'app che accompagna una macchina per tutta la sua vita utile, la continuità del processo conta più della singola consegna.