Una localizzazione fatta bene (o quasi)

La localizzazione è una di quelle cose che a prima vista sembra una semplice opzione di configurazione nel tuo IDE, ma che poi si rivela essere una discussione di sei mesi con degli sconosciuti sul genere dei sostantivi.

Per un piccolo studio, è anche uno dei migliori investimenti che possiamo fare. Un’app per imparare a digitare, un programma per progettare giardini o un’app per monitorare l’emicrania sono utili tanto a Lisbona quanto a Londra, e le persone tendono a fidarsi molto di più di un’app che si rivolge a loro nella loro lingua. Il problema è che farlo come si deve richiede molto più lavoro di quanto sembri a prima vista.

La nostra configurazione

Inizialmente rilasciamo l'app in inglese, per poi aggiungere altre lingue nel corso del suo ciclo di vita. Ogni traduzione viene verificata nel contesto, confrontandola con gli screenshot dell'interfaccia effettiva, e correggiamo eventuali errori prima del rilascio.

La fase di verifica nel contesto è quella che la maggior parte dei team tende a tralasciare, ed è proprio lì che si manifestano la maggior parte dei problemi. Una traduzione può essere perfettamente corretta in un foglio di calcolo e risultare comunque errata sullo schermo: l’etichetta di un pulsante che è accurata ma lunga il doppio dello spazio a sua disposizione, una parola che ha il significato giusto in generale ma sbagliato accanto a una determinata icona. Per questo generiamo screenshot di ogni schermata in ogni lingua e li esaminiamo uno per uno.

Scriviamo l’inglese tenendo sempre presente la traduzione. Frasi brevi, niente espressioni idiomatiche, niente battute basate su giochi di parole. Le stringhe che richiedono un contesto — “Clear” è un verbo o un aggettivo in questo caso? — vengono accompagnate da una nota per il traduttore. Questo rende l’inglese un po’ più semplice, e riteniamo che sia un vantaggio.

Gli aspetti meno evidenti

I formati di data e numero sono più importanti del testo tradotto. Le forme plurali variano a seconda della lingua in modi che chi parla inglese tende a sottovalutare sistematicamente (alcune lingue ne hanno ben sei). I layout da destra a sinistra non sono un semplice trucco CSS: influenzano il modo in cui vengono disegnati ogni freccia, ogni pulsante “Indietro” e ogni indicatore di avanzamento.

Ecco alcuni altri aspetti a cui abbiamo imparato a prestare attenzione:

• Espansione del testo. Le etichette in tedesco e finlandese possono essere molto più lunghe di quelle in inglese, quindi i layout devono prevedere spazio sufficiente per espandersi o adattarsi in modo armonioso.
• Unità di misura. Una previsione per la pesca che indica la velocità del vento in un’unità di misura sconosciuta non è solo strana, ma è anche inutile.
• Schede dei prodotti. L'app è solo metà del lavoro: anche le descrizioni, gli screenshot e le didascalie devono essere localizzati, separatamente per ogni negozio.
• Tastiere. Per un programma di apprendimento della digitazione, la localizzazione non riguarda solo le parole, ma anche le disposizioni dei tasti, i caratteri e il modo in cui le persone digitano effettivamente in quella lingua.

Cosa abbiamo sbagliato

Abbiamo commesso ognuno di questi errori almeno una volta. Quello che ci è costato di più è stato considerare la localizzazione come una fase finale: abbiamo realizzato l’intera interfaccia in inglese, per poi scoprire che metà delle schermate non funzionava correttamente nelle lingue con un numero maggiore di caratteri. Correggere i layout a posteriori ha significato riprogettare schermate che avevamo già considerato finite.

Il compromesso che ora accettiamo è quello di ritardare il rilascio delle prime versioni: una nuova funzionalità non è pronta finché non funziona in tutte le lingue supportate dall’app. La nostra lista di controllo ora inizia con le correzioni di questi errori, così li commettiamo meno spesso. “Quasi giusto, il più delle volte” è la versione onesta del titolo.