Tre assunzioni, tre miliardi di persone
L’alfabeto latino assume lettura orizzontale, da sinistra a destra, con spazi tra le parole.
Tre assunzioni. Tre miliardi di persone per cui nessuna di esse vale.
La prima assunzione: Direzione
L’arabo si legge da destra a sinistra. L’ebraico si legge da destra a sinistra. L’urdu si legge da destra a sinistra. Il persiano si legge da destra a sinistra. Queste non sono scritture minoritarie. Il solo arabo è il sistema di scrittura per oltre 370 milioni di parlanti nativi e la scrittura liturgica per 1,8 miliardi di musulmani. L’ebraico serve 9 milioni di parlanti nativi. L’urdu serve 230 milioni.
Da destra a sinistra non è un caso speciale. Da sinistra a destra non è il default. Entrambe sono convenzioni — incidenti storici di angolo del pennello, posizione del calamo e ergonomia dello scriba che si sono solidificati in norme nel corso dei millenni. Nessuna delle due è più naturale dell’altra. Una domina l’industria tecnologica. Questa dominanza non è guadagnata. È ereditata.
Ogni interfaccia IA costruita sull’assunzione della lettura da sinistra a destra — ogni finestra di chat, ogni input testuale, ogni pannello di risposta — è costruita sulla prima assunzione. L’assunzione è codificata a livello CSS, a livello del motore di layout, a livello dei modelli di interazione. “direction: ltr” è una singola riga di codice. È anche una dichiarazione culturale: questa interfaccia è stata costruita da persone che leggono da sinistra a destra, per persone che leggono da sinistra a destra.
Il costo ingegneristico del supporto bidirezionale non è zero. Ma il costo ingegneristico di escludere oltre 600 milioni di parlanti nativi di scritture da destra a sinistra è più alto — se li consideri affatto. La maggior parte delle interfacce non lo fa.
La seconda assunzione: Continuità
I caratteri latini sono discreti. Ogni lettera occupa il proprio spazio. La forma di una “a” non cambia in base alla lettera accanto. Questa discrezione è la fondazione architettonica della tipografia digitale: tabelle di glifi fisse, coppie di kerning prevedibili, posizionamento del cursore lineare.
La scrittura araba non funziona così. I caratteri arabi sono connessi — ogni lettera si unisce alle vicine in un flusso continuo, come la scrittura corsiva che non alza mai la penna. La forma di un carattere cambia in base alla sua posizione nella parola: iniziale, mediale, finale o isolata. La lettera “ba” (ب) ha quattro forme distinte a seconda di dove appare nella parola. Questa non è un’eccezione. Questa è la regola. Ogni lettera dell’alfabeto arabo ha più forme.
Il Devanagari — la scrittura usata per hindi, sanscrito, marathi, nepalese e decine di altre lingue che servono oltre 600 milioni di persone — ha una logica strutturale completamente diversa. I caratteri pendono da una linea orizzontale superiore chiamata shirorekha. La linea superiore connette i caratteri all’interno di una parola, creando una continuità visiva che non è né la discrezione del latino né la connessione corsiva dell’arabo. È un terzo modello del tutto.
L’implicazione per le interfacce IA: rendering del testo, posizionamento del cursore, selezione del testo, interruzione di riga e sillabazione si comportano tutti diversamente in ciascun sistema di scrittura. Un chatbot IA che rende testo arabo usando logica di rendering del testo latino produce testo tecnicamente leggibile ma visivamente sbagliato — forme di lettere che non si connettono correttamente, confini di parola che si interrompono in posizioni scorrette, comportamento del cursore che confonde l’utente.
L’utente non vede “un bug di rendering”. L’utente vede un’interfaccia che non capisce la sua lingua. La fiducia viene persa non a livello semantico ma a livello tipografico — prima che una singola parola della risposta dell’IA sia stata letta.
La terza assunzione: Separazione
L’inglese separa le parole con spazi. Il tedesco separa le parole con spazi (tranne quando crea parole composte, che poi non sono separate — “Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz” è una parola). Il cinese non usa spazi tra le parole. Il giapponese non usa spazi tra le parole. Il thai non usa spazi tra le parole.
In cinese, giapponese e coreano (CJK), ogni carattere occupa una cella a larghezza fissa. I caratteri sono spaziati uniformemente non per confini di parola ma per confini di carattere. La segmentazione delle parole — sapere dove una parola finisce e un’altra inizia — è un compito eseguito dal lettore, non dalla tipografia. Il testo non fornisce nessun segnale esplicito.
Per i sistemi IA che elaborano testo CJK, la segmentazione delle parole è un compito computazionale non banale. La stessa sequenza di caratteri cinesi può essere segmentata in parole diverse a seconda del contesto. La frase “下雨天留客天留我不留” può essere letta sia come un invito a restare sia come una richiesta di andarsene, a seconda di dove i confini di parola vengono posti. L’ambiguità è risolta dal contesto, non dalla tipografia.
Quando un chatbot IA risponde in cinese, la risposta deve essere resa in celle di caratteri a larghezza fissa con spaziatura CJK corretta. Quando la stessa interfaccia gestisce anche testo latino — in una distribuzione multilingue, per esempio — i due sistemi di spaziatura devono coesistere. Caratteri CJK a larghezza piena. Caratteri latini a larghezza proporzionale. Regole di punteggiatura diverse tra i due sistemi (il cinese usa segni di punteggiatura a larghezza piena; il latino usa larghezza dimezzata). Regole di interruzione di riga che proibiscono certi caratteri dall’apparire all’inizio o alla fine di una riga (kinsoku shori nella tipografia giapponese).
Questo non è una richiesta di funzionalità. È un prerequisito. Un’interfaccia che non gestisce correttamente la tipografia mista CJK-latino è un’interfaccia che non funziona per la maggioranza degli utenti dell’Asia orientale che leggono entrambe le scritture quotidianamente.
La scala dell’esclusione
I numeri non sono ambigui.
Scrittura araba: 420 milioni di parlanti nativi. Devanagari: 600+ milioni di utenti attraverso più lingue. Caratteri cinesi: 1,4 miliardi di lettori nativi. Giapponese (misto kanji, hiragana, katakana): 125 milioni di lettori nativi. Coreano (Hangeul): 80 milioni di lettori nativi. Scrittura thai: 38 milioni di lettori nativi.
Combinati, queste scritture servono più persone dell’alfabeto latino. E quel conteggio esclude il cirillico (250 milioni), il bengali (230 milioni), il tamil (80 milioni), il telugu (83 milioni) e decine di altre scritture che servono ciascuna decine di milioni di persone.
L’alfabeto latino non è il sistema di scrittura del mondo. È uno dei sistemi di scrittura del mondo — ed è quello che controlla le assunzioni di ogni interfaccia IA principale.
Cosa significa davvero “multilingue”
Ogni modello IA principale dichiara capacità multilingue. L’affermazione è vera a livello linguistico. GPT-4, Claude, Gemini — tutti elaborano testo in decine di lingue con vari gradi di competenza. Il modello linguistico capisce cinese, arabo, hindi, giapponese, coreano, thai.
L’interfaccia no.
La capacità multilingue del modello linguistico è resa attraverso un’interfaccia costruita su assunzioni latine: layout da sinistra a destra, rendering di caratteri discreti, visualizzazione di parole separate da spazi. Il modello sa pensare in arabo. L’interfaccia non sa mostrare l’arabo correttamente. Il modello sa generare cinese. L’interfaccia non sa rendere correttamente testo misto CJK-latino.
Il divario tra la capacità linguistica del modello e la capacità tipografica dell’interfaccia è il divario tra “multilingue” e “multiculturale”. Il modello parla la lingua. L’interfaccia parla tipografia latina travestita da costume linguistico.
Questo è l’argomento di Bluewaves, ridotto alla sua forma più semplice: la lingua non è cultura. La traduzione non è adattamento. Un modello che genera arabo fluente attraverso un’interfaccia che rende l’arabo scorrettamente ha raggiunto competenza linguistica e incompetenza tipografica simultaneamente.
I requisiti ingegneristici
Cosa servirebbe per costruire un’interfaccia IA che rispetti i tre miliardi? I requisiti sono specifici, noti e ben documentati nelle specifiche del Consorzio Unicode, nelle linee guida di Internazionalizzazione del W3C e in decenni di ricerca ingegneristica tipografica.
Supporto testo bidirezionale (Bidi). L’Algoritmo Bidirezionale Unicode (UBA) definisce come il testo con direzionalità mista dovrebbe essere reso. L’algoritmo gestisce il caso comune: una frase araba che contiene un nome di prodotto inglese, o un paragrafo ebraico con un URL. L’UBA è un problema risolto — implementato in ogni motore browser principale e sistema operativo. Il requisito non è inventare il supporto bidirezionale. È usare lo standard esistente correttamente. La maggior parte delle interfacce IA non lo fa.
Shaping contestuale. Arabo, siriaco, mongolo e altre scritture connesse richiedono shaping contestuale — rendere varianti di glifi diverse in base alla posizione di un carattere nella parola. Le funzionalità di layout OpenType (specificamente le funzionalità “init”, “medi”, “fina” e “isol”) gestiscono questo a livello di font. Il requisito è usare font che includano queste funzionalità e motori di rendering che le applichino. Il requisito non è esotico. È tipografia standard. Viene frequentemente ignorato.
Spaziatura e interruzione di riga CJK. I “Requirements for Japanese Text Layout” (JLReq) e i “Requirements for Chinese Text Layout” (CLReq) del W3C definiscono le regole di spaziatura, punteggiatura e interruzione di riga per il testo CJK. Queste non sono linee guida opzionali. Sono le convenzioni tipografiche che i lettori CJK si aspettano — l’equivalente del testo allineato a sinistra nella tipografia latina. Violarle produce testo leggibile ma sbagliato, nel modo in cui un libro con testo inglese allineato a destra è leggibile ma sbagliato.
Rendering di scritture complesse. Devanagari, bengali, tamil, telugu, kannada, malayalam, thai, lao, khmer, tibetano e scritture del Myanmar richiedono tutte shaping complesso — riordinamento di caratteri, combinazione di caratteri base con segni vocalici e regole di posizionamento che dipendono dalla combinazione specifica di caratteri. HarfBuzz, il motore di shaping del testo open source, gestisce tutti questi. Il requisito è l’integrazione, non l’invenzione.
Supporto testo verticale. Cinese tradizionale, giapponese e mongolo possono essere scritti verticalmente (dall’alto verso il basso, colonne da destra a sinistra). Sebbene la scrittura orizzontale sia diventata dominante per il testo digitale in cinese e giapponese, il testo verticale rimane importante per contesti formali, editoria letteraria e certi elementi UI. Il mongolo è scritto verticalmente per default. Un’interfaccia IA che dichiara supporto CJK ma non sa rendere testo verticale sta facendo un’assunzione culturale mascherata da limitazione tecnica.
La dimensione dell’accessibilità
Le tre assunzioni non influenzano solo la competenza culturale. Influenzano l’accessibilità.
L’Organizzazione Mondiale della Sanità stima che 2,2 miliardi di persone a livello globale hanno qualche forma di disabilità visiva. Gli screen reader — la tecnologia assistiva che converte il testo in parlato per utenti con disabilità visive — dipendono dalla corretta direzionalità del testo, dalla corretta codifica dei caratteri e dalla corretta struttura semantica. Uno screen reader che elabora testo arabo in un contesto da sinistra a destra leggerà i caratteri nell’ordine sbagliato. L’utente sente parole senza senso.
Questa non è una preoccupazione di nicchia. Gli utenti internet arabofoni sono circa 237 milioni. L’intersezione tra utenti arabofoni e utenti con disabilità visive si misura in milioni. Un’interfaccia IA che rende testo arabo in un contesto da sinistra a destra ha escluso questi utenti dall’interazione — non attraverso una decisione deliberata, ma attraverso l’assunzione ereditata che tutto il testo fluisce da sinistra a destra.
La Direttiva UE sull’Accessibilità Web (Direttiva 2016/2102) richiede che i siti web e le applicazioni del settore pubblico soddisfino gli standard WCAG 2.1 AA. L’Atto Europeo sull’Accessibilità (Direttiva 2019/882), che si applica ai prodotti e servizi del settore privato da giugno 2025, estende requisiti simili ai prodotti commerciali. Entrambe le direttive richiedono gestione corretta del testo bidirezionale, markup semantico corretto per gli screen reader e identificazione corretta della lingua nell’attributo HTML lang.
Uno strumento IA che non gestisce correttamente l’arabo, l’ebraico o altre scritture RTL non è semplicemente culturalmente insensibile. È potenzialmente non conforme alla legislazione UE sull’accessibilità.
Il costo ingegneristico della conformità è lo stesso del costo ingegneristico della competenza culturale: implementare correttamente l’Algoritmo Bidirezionale Unicode, usare HTML semantico con attributi lang corretti e testare con screen reader in modalità RTL. Il costo si sostiene una volta. L’esclusione, se il costo non viene sostenuto, è permanente.
Il divario nei test
Ecco un’osservazione pratica da anni di lavoro nel design interculturale: l’assunzione che il testo sia latino persiste perché i test sono latini.
I team QA testano le interfacce IA con testo latino. Query in inglese, risposte in inglese, rendering in inglese. I test passano. Il prodotto viene consegnato. L’utente arabo, l’utente hindi, l’utente cinese, l’utente thai scopre i fallimenti di rendering dopo la distribuzione — in produzione, con query reali, con conseguenze reali per la fiducia.
Il divario nei test non è accidentale. È strutturale. I team QA sono composti da persone che leggono la lingua di sviluppo. I casi di test sono scritti nella lingua di sviluppo. I test automatizzati verificano funzionalità descritte nei documenti dei requisiti nella lingua di sviluppo. Il testing multilingue richiede tester multilingui — persone che possono valutare se il testo arabo sembra corretto, se la spaziatura CJK è corretta, se le connessioni della linea superiore del Devanagari si rendono correttamente. Questi tester esistono. Vengono raramente assunti. Sono un ripensamento, se vengono considerati affatto.
La correzione è architetturale: includere le scritture non latine nella suite di test principale, non come appendice. Ogni test automatizzato che verifica il rendering del testo dovrebbe essere eseguito contro testo arabo, cinese, Devanagari e thai oltre che inglese. Ogni passaggio QA manuale dovrebbe includere valutazione in scrittura nativa da parte di un lettore nativo. Ogni audit di accessibilità dovrebbe includere scenari RTL e scritture complesse.
Questo non è un regime di test premium. È un regime di test di base per un prodotto che dichiara di servire una base utente globale. Un prodotto che testa solo in latino e dichiara supporto globale non è un prodotto globale. È un prodotto latino con una pagina di marketing globale.
Il fallimento di design
Il fallimento non è che questi requisiti siano sconosciuti. Sono ampiamente documentati. L’Attività di Internazionalizzazione del W3C ha pubblicato specifiche complete per ogni sistema di scrittura principale. Le specifiche del Consorzio Unicode sono il riferimento canonico per l’elaborazione del testo a livello mondiale. HarfBuzz, ICU e altre librerie open source implementano la logica di rendering.
Il fallimento è che questi requisiti sono trattati come casi speciali piuttosto che requisiti fondazionali. L’interfaccia IA è progettata per testo latino. Poi il supporto arabo viene “aggiunto”. Poi il supporto CJK viene “aggiunto”. Ogni aggiunta è un retrofit — una patch applicata a un’architettura progettata per un sistema di scrittura ed estesa, imperfettamente, per accogliere gli altri.
L’alternativa è progettare per i tre miliardi fin dall’inizio. Trattare layout bidirezionale, shaping contestuale, rendering di scritture complesse e spaziatura CJK come requisiti architetturali — non funzionalità da aggiungere dopo, ma fondazioni da posare per prime.
Questo è più costoso in partenza. È meno costoso in totale. Ogni retrofit è più costoso di quanto sarebbe stata la decisione di design originale. E ogni retrofit produce imperfezioni — glitch di rendering, bug di interazione, fallimenti di accessibilità — che erodono la fiducia con gli utenti che erano un ripensamento.
Il principio
L’alfabeto latino non è il default. È una convenzione — una delle tante, adottata da una minoranza dei lettori del mondo, elevata a dominanza architettonica dall’incidente di quale cultura ha industrializzato l’informatica per prima.
Ogni interfaccia IA costruita su assunzioni latine esclude più persone di quante ne includa. Non per malizia. Per eredità. Le assunzioni non sono mai state esaminate perché non sono mai state visibili — alle persone che le condividono.
Le tre assunzioni — direzione, continuità, separazione — non sono universali. Sono provinciali. E costruire tecnologia globale su assunzioni provinciali non è ingegneria. È negligenza su scala.
Tre assunzioni. Tre miliardi di persone. Le assunzioni sono opzionali. Le persone no.
L’interfaccia IA costruita per i tre miliardi ha un aspetto diverso dall’interfaccia IA costruita per l’alfabeto latino. Inizia con il layout bidirezionale come default, non come ripensamento. Tratta lo shaping contestuale come una capacità fondazionale, non come una funzionalità avanzata. Gestisce la spaziatura CJK come un requisito di rendering di base, non come un componente aggiuntivo di localizzazione. Testa con testo arabo, Devanagari, cinese e thai come parte della suite di test standard, non come un caso speciale.
Questa interfaccia non esiste. Le specifiche per costruirla esistono. Le librerie per implementarla esistono. La domanda per essa — tre miliardi di persone — esiste.
Ciò che non esiste è la decisione di costruirla. Quella decisione non è tecnica. È attenzionale. È la decisione di notare le tre assunzioni e di trattarle come le convenzioni provinciali che sono, piuttosto che le verità universali che non sono.
Tre assunzioni. Tre miliardi di persone. La decisione è una.