La fatica di internazionalizzare una web app

Diciamolo chiaro: per tantissime startup la traduzione è l’ultimo dei problemi. È raro che fin dall'inizio una web app, soprattutto se nasce negli Stati Uniti, presenti funzionalità per l'internazionalizzazione dei contenuti generati dagli utenti.

Una web app dovrebbe curare l’internazionalizzazione a 3 livelli.

Il primo livello è quello del front end, cioè i testi che compaiono a chi visita e usa la web app. La web app può essere disponibile in una o più lingue. La decisione di offrire più lingue dipende dalla strategia di internazionalizzazione della società che ha sviluppato la web app.

Come utente italiano, apprezzo le web app che mi consentono di scegliere l’italiano come lingua dell’interfaccia. Tuttavia, poiché sono traduttore, so anche in che modo e con che cura si traduce. Dunque l’apprezzamento dura pochi secondi. Poi imposto nuovamente tutto in inglese. Scherzi a parte, questo primo livello di internazionalizzazione viene contemplato da quasi tutte le web app che conosco. Come minimo, oltre all’inglese, è presente un’altra lingua (spagnolo, cinese, russo, francese, tedesco, ecc.) a seconda dei mercati che l’azienda vuole raggiungere. Le aziende con una vocazione internazionale più accentuata offrono la loro web app in 4, 5 o anche più lingue.

Il secondo livello riguarda i contenuti generati dagli utenti. In senso stretto, i contenuti generati dagli utenti sono i commenti, le recensioni, le valutazioni, le foto (e relative didascalie), i post, gli interventi sui forum, ecc. In questo articolo mi riferisco però ai contenuti strettamente legati alla funzione principale del sito, cioè:

• se la web app serve a creare un CV, allora intendo il CV;
• se la web app serve a generare immagini, le immagini;
• se la web app serve a progettare e pubblicare un sito web, il sito web dell’utente;
• se la web app serve a pubblicare un corso online, il corso online;
• ecc.

In questi casi la web app dovrebbe considerare che i contenuti generati dall’utente non necessariamente saranno creati nella lingua dell’interfaccia. Per esempio, se sto visitando la versione inglese di un sito per creare CV, potrei voler creare il mio CV in francese, in italiano o in qualsiasi altra lingua.

Anche questo livello di internazionalizzazione quasi sempre viene contemplato da chi sviluppa la web app. Sarebbe controproducente se - continuando l’esempio precedente - al momento di creare un CV in arabo, la web app non fosse capace di mostrare i caratteri arabi o mostrasse i testi da sinistra a destra anziché da destra a sinistra.

Gli sforzi di Unicode Consortium e il ricorso allo standard Unicode da parte della quasi totalità delle web app hanno contribuito enormemente a rendere siti e app compatibili con quasi qualunque lingua.

Senza scendere nei dettagli dei set di caratteri e delle relative codifiche, un campo tanto affascinante quanto complesso di cui mi riservo di parlare in un’altra occasione, ti basti sapere che Unicode è il sistema che consente a tutti i dispositivi (computer, telefoni, tablet, ecc.) di condividere o scambiare testo scritto in qualsiasi lingua (o quasi).

Come ci riesce? Dato che i computer, in fondo, capiscono soltanto i numeri, Unicode assegna un numero univoco a ogni carattere, a prescindere dalla piattaforma, dal programma o dalla lingua.

Forse hai sentito parlare di UTF-8.

La differenza fra Unicode e UTF-8 è questa: Unicode è un set di caratteri (puoi immaginarla come un’enorme tabella in cui a ogni carattere corrisponde un numero), mentre UTF-8 è la codifica di questa tabella, cioè il modo in cui i numeri sono convertiti in codice binario per essere capiti dal computer.

Le dolenti note arrivano con il terzo livello di internazionalizzazione, quello legato alla possibilità di convertire un contenuto generato dagli utenti da una lingua all’altra, cioè alla traduzione dello user-generated content.

La maggioranza delle web app che conosco ha innumerevoli funzioni legate alla creazione dei contenuti, ma è carente dal punto di vista della traduzione dei contenuti stessi.

L’ideale sarebbe che la web app disponesse di un meccanismo per:

• esportare il contenuto traducibile;
• importare il contenuto una volta tradotto;
• tradurre automaticamente il contenuto traducibile.

Tornando all’esempio del CV, la web app mi consente di tradurre comodamente in inglese il CV che ho creato in italiano?

Nella mia esperienza ciò non succede quasi mai.

Le tendenze attuali nella localizzazione di software includono l’uso crescente della traduzione automatica basata o meno sull’intelligenza artificiale, il collegamento con strumenti di traduzione assistita per migliorare l'efficienza dei traduttori umani e lo sviluppo di soluzioni di internazionalizzazione integrate che facilitano la gestione dei contenuti multilingue all'interno delle web app.

Se è vero che alcune web app permettono di tradurre automaticamente il contenuto collegandosi a Google Translate o DeepL, è rarissimo trovare web app che abbiano pensato fin dall’inizio alla traduzione dei contenuti generati dagli utenti.

Persino programmi diffusissimi, come WordPress o Moodle non hanno funzioni native per presentare i loro contenuti in varie lingue (si badi, non l’interfaccia, quella sì che è tradotta in innumerevoli lingue).

Le ragioni di questa apparente dimenticanza sono varie e più che legittime, a ben vedere.

In primo luogo, moltissime web app nascono negli Stati Uniti e sono pensate principalmente per il vastissimo mercato interno, per cui l’opzione di rendere multilingue l’app non è una priorità strategica.

Un altro aspetto, di non poco conto, è la complessità dei meccanismi di export-import dei dati.

Qualunque sia il contenuto generato dall’utente, nel momento in cui se ne permette l’esportazione in un formato modificabile (per poter essere tradotto il contenuto deve per forza essere modificabile), si corre il rischio che venga manipolato nel modo sbagliato e non sia possibile importarlo nuovamente nel sistema. Perciò molte aziende evitano volutamente di aggiungere funzioni di questo tipo alle loro web app.

Inoltre, benché il settore della traduzione abbia da tempo concepito almeno uno standard per scambiare dati fra applicazioni, il formato XLIFF, non tutti gli sviluppatori conoscono e usano questo standard. Creare una web app seguendo le migliori prassi della localizzazione comporta uno sforzo aggiuntivo che poche aziende sono disposte a compiere.

Stando così le cose, quando un utente ha la necessità di tradurre il contenuto da lui generato, è costretto a cercare stratagemmi e vie traverse. La questione sarebbe tutto sommato poco rilevante se il problema si presentasse soltanto a livello di utente privato.

Tuttavia, moltissime web app vengono usate anche a livello aziendale. Tante imprese, soprattutto quelle familiari, preferiscono usare strumenti inizialmente pensati per i consumatori finali, sia per motivi economici, sia per praticità e abitudine.

È frequente quindi trovare opuscoli aziendali, presentazioni commerciali, brochure e cataloghi creati con Canva, oppure sondaggi per i clienti creati con Surveymonkey, siti aziendali realizzati con Squarespace o Wix, diagrammi e schemi con Diagrams.net e via dicendo.

Quando questi contenuti devono essere trasmessi a un importatore o una delegazione commerciale all’estero o devono essere adattati per un pubblico straniero, che cosa succede?

Dopo lo sconcerto iniziale, quando si scopre che non è possibile tradurre il contenuto, si aprono due scenari possibili:

1. duplicare il contenuto e tradurlo nella web app;
2. esportare il contenuto, tradurlo e poi inserire manualmente la traduzione.

➡ La soluzione più seguita è quella di duplicare il contenuto e di sovrascrivere il testo con la traduzione.

Tuttavia, affinché questo avvenga, l’utente che ha creato il contenuto deve conoscere la lingua straniera. Altrimenti bisogna dare a un traduttore esterno l’accesso alla web app. Ma non tutte le web app sono progettate per essere multiutente o per progetti in collaborazione, per cui quest’ultimo passaggio può essere difficile o impossibile.

➡ Se la prima soluzione non è percorribile, l’alternativa è esportare il contenuto per mandarlo al traduttore.

Le web app usate per creare immagini o progetti grafici hanno quasi sempre un’opzione per esportare in formato PDF. Una volta scaricato questo PDF, lo si invia al traduttore. Il traduttore a quel punto restituirà un file Word con il testo tradotto, che qualcuno dovrà infine inserire manualmente in una copia del documento originale. Oltre al formato PDF alcune web app, una sparuta minoranza, consentono anche l’esportazione in formati editabili. Un esempio è Diagrams.net che permette di salvare un diagramma in formato XML, che può essere aperto e modificato e quindi importato nuovamente nell’applicazione.

Chiaramente, se la web app serve per creare siti web o contenuti multimediali complessi, l’esportazione è pressoché impossibile e saranno necessarie tattiche alternative, come abbiamo spiegato ad esempio per Squarespace.

Quali conclusioni si possono trarre da questa breve analisi?

1. Chi progetta web app dovrebbe valutare attentamente il mercato a cui si rivolge, contemplando i 3 livelli di internazionalizzazione descritti, se funzionali ai propri scopi.
2. Chi usa una web app dovrebbe verificare prima dell’uso intensivo quali funzioni di traduzione sono disponibili, soprattutto se l’uso avviene a livello aziendale o commerciale.
3. Chi deve tradurre un contenuto generato dagli utenti proveniente da una web app dovrebbe conoscere il procedimento più adatto (nativo o alternativo) e proporlo al committente della traduzione.