i18n contro l10n: qual è la differenza?

Proprio come il famoso menu *segreto* di In-N-Out Burger, ogni nicchia di mercato ha un linguaggio segreto che, una volta padroneggiato, ti fa sentire parte di un gruppo esclusivo. Il settore della traduzione e della localizzazione non fa eccezione. Sentendosi sempre un po' inferiori rispetto ai nostri amici matematici, noi del settore abbiamo deciso di infilare dei numeri in mezzo alle nostre parole chiave: i18n e l10n.

Sembra un argomento tecnico e intimidatorio, vero?

A quanto pare, è solo un modo abbreviato per internazionalizzazione e localizzazione .

Internationalization, or i18n (pronounced “eye-eighteen-en”) refers to the engineering work that gets software ready to run in any language. Lo fa estraendo le stringhe di testo dal codice, gestendo la codifica dei caratteri e creando una formattazione flessibile per date, valute e unità. i18n è il lavoro tecnico, dietro le quinte, che viene svolto in preparazione alla localizzazione (l10n), ovvero ciò che viene fatto per ogni lingua e per ogni mercato.

La maggior parte delle pagine esplicative che vedo risultano un po' confuse perché trattano i punti i18n e l10n come due varianti dello stesso compito, per poi dedicare il resto dell'articolo a parlare di librerie di codice. Non si tratta dello stesso compito. L'internazionalizzazione è un'attività che il vostro team di ingegneri svolge, si spera una sola volta! La localizzazione, d'altro canto, è ciò che accade al tuo sito web ogni volta che aggiungi un mercato, ed è la parte che determina se un visitatore multilingue si sente benvenuto quando lo visita o se ha la sensazione di essere entrato nella "valle perturbante", ovvero che qualcosa non va ma non riesce a capire cosa.

Questa distinzione non è solo una mia pignoleria (certo, lo è, ma in questo caso è importante per i team che si occupano di localizzazione!). Un sito può essere perfettamente internazionalizzato e risultare comunque "sbagliato" nella lingua di destinazione. Il vostro team ha prestato particolare attenzione alla progettazione di pulsanti che si espandono per adattarsi al testo in tedesco, ai cartellini dei prezzi con il simbolo di valuta corretto e alle date stampate in un formato familiare al lettore. Questo è il numero i18n! Ma che dire della frase accanto al pulsante? Sembra scritto da qualcuno che conosce il mercato o è stato tradotto automaticamente con un'app di traduzione automatica e pubblicato senza ulteriori verifiche? Questo è il compito della localizzazione ed è il fattore determinante nel stabilire se il visitatore clicca sul link o decide di abbandonare la pagina.

Che cosa significa realmente i18n

L'ho già detto, ma vale la pena ribadirlo (gioco di parole voluto): internazionalizzazione è un numeronimo. Prendi la prima lettera (i), l'ultima lettera (n), conta le 18 lettere tra di esse e voilà , ottieni i18n. Si tratta di una notazione abbreviata che si è diffusa perché gli sviluppatori volevano un modo per digitare la parola senza doverla scrivere per esteso cinquanta volte durante una revisione del codice. Quindi, l10n per la localizzazione e a11y per l'accessibilità, ecc.

Ma la parte noiosa è l'abbreviazione. Ciò che conta è ciò che i18n fa concretamente.

Si tratta del processo di strutturazione di una base di codice in modo che possa supportare qualsiasi lingua o impostazione locale senza bisogno di riscriverla:

• Stringhe di testo estratte dal codice e inserite in file esterni, invece di essere codificate direttamente nel codice.
• Codifica UTF-8, quindi i caratteri accentati e gli alfabeti non latini vengono visualizzati correttamente
• Impaginazione che non presuppone che il testo si legga sempre da sinistra a destra.
• I formati di data, numero e valuta sono trattati come variabili, non come presupposti fissi.

Se fatto bene, il corso i18n è come l'acqua per un pesce rosso: invisibile e inosservato (nel senso migliore del termine).

l10n: la parte che non finisce mai

Se i18n è l'auto, allora l10n è il carburante. Quando si decide di aggiungere il francese, si procede alla localizzazione. Quando si aggiunge il giapponese, si effettua nuovamente la localizzazione. Non si tratta di una fase da completare, ma di un processo ripetitivo; ecco perché la localizzazione necessita di un proprio flusso di lavoro, di un responsabile e di un set di strumenti dedicati, tenuti separati dall'ingegneria.

Un team può lanciare un prodotto realmente internazionalizzato e comunque non riuscire a localizzarlo a dovere, perché localizzare non significa semplicemente sostituire le parole. Può includere anche espressioni idiomatiche e formalità, nonché scambi di immagini e persino sottili variazioni di colore!

Dove la differenza si manifesta in una pagina live

I problemi di formato sono il modo più semplice per vedere i moduli i18n e l10n funzionare separatamente.

Prendiamo i numeri, ad esempio. Negli Stati Uniti, mille dollari e cinquanta centesimi si scrivono come 1,000.50. In gran parte d'Europa si scrive lo stesso valore di 1.000,50, con la virgola e il punto invertiti. Il campo relativo alla valuta mostra 99.00 dollari statunitensi e 99,00 euro tedeschi, con i simboli su lati opposti. Le date sono ulteriormente distanziate. 03/04/2026 significa marzo 4th negli Stati Uniti e aprile 3rd quasi ovunque altrove, motivo per cui esiste lo standard ISO 8601 (AAAA-MM-GG), per aggirare l'ambiguità piuttosto che discuterne paese per paese. Anche i codici lingua seguono uno standard: ISO 639-1 assegna codici di due lettere come de, ja e pt, in modo che un sistema di localizzazione abbia un identificatore stabile su cui basarsi, invece di doverlo dedurre dal nome del paese.

L'espansione del testo è l'aspetto che i team di ingegneri sottovalutano maggiormente. Phrase’s own i18n documentation uses a shoe size as a clean illustration: a UK size 10 is a European size 38, and a US size 38 is a completely different EU 6. Ora, traduci un'etichetta dell'interfaccia utente allo stesso modo e otterrai lo stesso tipo di discrepanza nella lunghezza delle parole. Il testo in tedesco e in finlandese è in genere dal 20 al 35 percento più lungo del testo originale in inglese, motivo per cui un pulsante con la scritta "Submit" ci sta bene mentre "Zur Kasse gehen" no, a meno che il layout non sia stato creato con contenitori flessibili. L'arabo e l'ebraico, essendo lingue RTL (da destra a sinistra), presentano un problema completamente diverso: l'intera impaginazione è speculare, e non solo la direzione del testo.

Nessuno di questi problemi viene risolto adeguatamente in fase di traduzione. Il problema dovrebbe essere risolto nel codice, ecco perché insisto affinché la parte i18n venga svolta correttamente prima dell'inizio della parte l10n .

Il flusso di lavoro: costruisci la tua casa su solide fondamenta

In un sistema sano, l'internazionalizzazione avviene una sola volta e la localizzazione si ripete indefinitamente al di sopra di essa. Estrai le stringhe, imposti la codifica e crei layout flessibili in un'unica operazione. Dopodiché si procede alla localizzazione in francese. In seguito, si procede alla localizzazione in giapponese. Successivamente, è stata aggiunta la versione araba, senza modificare ulteriormente l'architettura di base, poiché quest'ultima era stata progettata fin dall'inizio per gestire qualsiasi lingua.

Ciò che mette in difficoltà i team è saltare il primo passaggio e cercare di inserirlo durante il secondo. È in questi casi che ci si ritrova con stringhe hardcoded annidate a tre livelli di profondità e selettori di data che comprendono solo il formato MM/GG/AAAA. Alla fine, il progetto di traduzione si trasforma in una ristrutturazione che nessuno aveva previsto.

Dobbiamo ricostruire il nostro stack?

Ho partecipato a un numero sufficiente di chiamate di vendita per sapere cosa preoccupa la maggior parte dei team: "Dobbiamo ricostruire la nostra infrastruttura per fare le cose per bene?" Il presupposto è che, se il loro sito non è stato internazionalizzato fin dall'inizio, allora localizzarlo correttamente significhi una completa riprogettazione. Nella maggior parte dei casi, la risposta è NO.

Se il livello di localizzazione viene eseguito sopra il sito esistente anziché all'interno del suo codice sorgente, non è necessaria alcuna ricostruzione. Mi sto svelando un po' le mie carte, ma è proprio così che funziona Bablic . Nella maggior parte dei casi, un piccolo snippet JavaScript viene eseguito nel browser del visitatore e sostituisce il testo tradotto con quello appropriato per la lingua corretta al momento della richiesta, senza eseguire la scansione o ricostruire il sito di origine (il server originale in cui risiede effettivamente la pagina).

La preoccupazione principale in termini di prestazioni che solitamente ne consegue è che un approccio lato browser implica il caricamento dell'intero corpus di traduzione ad ogni visualizzazione della pagina. Se questo è un problema reale per te, scegli uno strumento che offra la memorizzazione nella cache della pretraduzione, in modo che il browser non debba accedere nuovamente all'API di traduzione a ogni richiesta.

A questo punto starete pensando: "ma il mio prodotto è un'app nativa con una logica condizionale profondamente annidata e nessuna separazione tra stringhe e codice"... bla bla bla. Beh, questo sì che è un problema di ingegneria che un livello lato browser non risolverà! In questo caso, cerca una soluzione con un SDK. Ma per i siti di marketing e i negozi online, le pagine create inizialmente in una lingua e ora destinate a servire cinque mercati, l'ipotesi di una riprogettazione è generalmente errata.

Non tradurre senza contesto

A page can pass every i18n check (the currency’s right, the date format is right) and still read as obviously foreign to the person it’s supposed to be speaking to. I clienti si accorgono quando un messaggio non centra l'obiettivo o è anche solo leggermente errato, e chi se ne accorge non effettua la conversione. Quella è la "valle perturbante" di cui parlavo prima, ed è un vero e proprio ostacolo alla conversione.

Comprendere e far rispettare il contesto aiuta a risolvere questo problema. Innanzitutto, avendo il controllo su termini specifici, come il nome del tuo marchio e i nomi propri del tuo prodotto, ti assicuri che le frasi cruciali vengano sempre tradotte allo stesso modo, indipendentemente dalle impostazioni predefinite di un motore di traduzione automatica. Un glossario che ti permetta di confermare queste scelte è ciò che garantisce che una pagina tradotta rispecchi l'identità del tuo marchio, anziché essere una versione generica rivolta a nessuno in particolare.

La seconda è la capacità di guardare direttamente la pagina tradotta e correggere gli errori sul posto, senza bisogno di essere fluenti nella lingua di destinazione per individuare una frase goffa. Un editor contestuale mostra la pagina tradotta in tempo reale e consente di modificarla direttamente, il che significa che un collega di lingua spagnola può controllare a campione il risultato in pochi minuti, invece che un traduttore debba rifare tutto da capo partendo da un foglio di calcolo.

Per la maggior parte delle pagine, la traduzione automatica (MT) rappresenta un buon punto di partenza. I motori di traduzione predefiniti di Bablic sono Google Traduttore e DeepL, che gestiscono la prima bozza a una velocità ineguagliabile da qualsiasi team umano. Per la maggior parte delle aziende con cui parliamo, questi strumenti, combinati con un glossario e un controllo a campione con un editor contestuale, sono sufficienti per avere la sensazione che il proprio sito sia realmente localizzato.

FAQ