10 comuni errori i18n e come evitarli
Scopri gli errori di internazionalizzazione più comuni che gli sviluppatori commettono e come risolverli. Migliora la qualità della localizzazione della tua app con queste best practice.
L'internazionalizzazione (i18n) sembra semplice — finché non scopri che i tuoi utenti tedeschi vedono pulsanti tagliati, i tuoi utenti giapponesi ricevono frammenti di frasi distorti e i tuoi utenti di lingua araba hanno layout completamente rovinati. Non sono casi isolati. Sono le conseguenze prevedibili degli errori comuni che la maggior parte dei team di sviluppo commettono quando affrontano per la prima volta la localizzazione. In questa guida esamineremo i 10 errori i18n più comuni, spiegheremo esattamente perché accadono e ti mostreremo, passo dopo passo, come risolverli. Che tu stia costruendo una nuova app o aggiornando una esistente — evitare queste insidie ti farà risparmiare settimane di debugging e offrirà un'esperienza rifinita agli utenti in tutto il mondo.
Errore #1: Stringhe codificate
L'errore i18n più basilare è l'hardcoding delle stringhe. Succede perché gli sviluppatori si concentrano prima sul far funzionare le funzionalità e pianificano di sistemarlo 'più tardi'. Ma il 'più tardi' non arriva mai, e all'improvviso hai migliaia di stringhe distribuite tra centinaia di file.
['Configura il framework i18n prima di scrivere la prima riga di codice UI', 'Usa un plugin di lint per rilevare stringhe hardcodate in template e componenti', 'Mantieni le chiavi di traduzione descrittive e organizza le per funzione o pagina']
Configura il tuo framework i18n prima di scrivere la prima riga di codice UI.
Usa un plugin di lint per rilevare stringhe codificate nei template e nei componenti.
Mantieni le chiavi di traduzione descrittive e organizza le in base alla funzionalità o alla pagina.
Uno scenario tipico
Uno sviluppatore scrive un'etichetta del pulsante direttamente in JSX: <button>Submit Order</button>.
L'app viene rilasciata in inglese e funziona correttamente. Sei mesi dopo l'azienda si espande in Germania.
Il team di localizzazione scopre 2.000+ stringhe hardcodate. Il refactoring richiede 3 settimane e provoca 47 bug.
Perché questo è un problema
In una codebase matura, i testi hardcodati possono arrivare a migliaia. Rimuoverli in seguito richiede di toccare ogni file, testare ogni componente nuovamente e rischiare regressioni ovunque.
Le stringhe hardcodate sono incorporate direttamente nel codice sorgente, nei template o nei componenti. Non possono essere estratte, tradotte o sostituite a runtime senza modificare il codice stesso.
Gli utenti in località non inglesi vedono elementi dell'interfaccia non tradotti mescolati a contenuti tradotti — un'impressione caotica e poco professionale.
Come risolverlo
Sposta tutti i testi visibili all'utente fin dall'inizio in file delle risorse.
Configura un framework i18n (ad es. next-intl, react-i18next, vue-i18n) prima di scrivere la prima componente.
Crea una struttura di file delle risorse (es. messages/de.json) e riferisci tutti i testi tramite chiavi di traduzione come t('checkout.submitButton').
Aggiungi una regola di linting o un hook di pre-commit che contrassegni i literal di stringhe nelle componenti UI.
Errore #10: Tradurre tutto letteralmente
Non tutti i contenuti dovrebbero essere tradotti. I nomi di marchi, i nomi di persone giuridiche, termini tecnici e alcuni nomi di prodotti devono rimanere nella loro lingua originale. Una traduzione eccessiva può causare problemi legali, incoerenza del marchio e confusione per l'utente.
["Mantieni un glossario 'Non tradurre' e condividilo con tutti i traduttori", 'Usa segmenti 'bloccati' o namespace separati per termini di marca e di diritto', 'Fornisci sempre note contestuali per stringhe ambigue per evitare traduzioni errate']
Mantieni un glossario di 'non tradurre' e condividilo con tutti i traduttori
Usa segmenti bloccati o namespace separati per termini di marca e termini legali
Fornisci sempre note contestuali per stringhe ambigue per evitare traduzioni errate
Uno scenario tipico
Un file di traduzione contiene il nome dell'azienda 'CloudForge Inc.' e il termine tecnico 'OAuth 2.0 Token' come stringhe traducibili.
Il traduttore spagnolo traduce 'CloudForge' in 'ForjaNube' e 'OAuth 2.0 Token' in 'ficha OAuth 2.0'.
Risultato: gli utenti non trovano l'azienda con il suo nome reale, e gli sviluppatori che leggono la documentazione in spagnolo sono confusi dai termini tecnici tradotti non noti.
Perché questo è un problema
Un singolo nome di marchio tradotto erroneamente in un documento legale può rendere contratti nulli. Correggere traduzioni eccessive richiede la revisione di ogni stringa in ogni lingua — un impegno di diverse settimane.
Se tutti i stringhe vengono inviati alla traduzione senza contesto, i traduttori potrebbero tradurre nomi di marchi ('Apple' → 'Apfel'), termini giuridici ('GmbH' → 'LLC') o identificatori tecnici che devono rimanere in inglese.
Gli utenti non trovano i prodotti con il nome di marchio conosciuto, i documenti legali fanno riferimento alla società sbagliata e la documentazione tecnica diventa incomprensibile se termini come 'API Endpoint' vengono tradotti.
Come risolverlo
Etichettare chiaramente i contenuti non traducibili e fornire note contestuali ai traduttori.
Crea un glossario 'Non tradurre', che elenchi tutti i nomi di marchi, nomi di prodotti, persone giuridiche e termini tecnici che devono rimanere inalterati.
Usa un namespace separato o chiavi speciali per contenuti non traducibili. Molti strumenti i18n supportano segmenti 'bloccati' che i traduttori non possono modificare.
Aggiungi commenti/descrizioni ai file di traduzione che spiegano il contesto: 'Questo è un marchio — non tradurlo' o 'Termine tecnico — lasciare in inglese'.
Errore #2: concatenazione di stringhe
Unire frasi da frammenti può funzionare in inglese, ma non in altre lingue. L'ordine delle parole, la grammatica e la struttura delle frasi variano notevolmente tra le lingue, rendendo le stringhe concatenate non traducibili.
['Non concatenare frasi traducendo frammenti', 'Usa segnaposto nominati ('{name}') invece di posizionali ({0}) per chiarezza', 'Fornisci commenti contestuali ai traduttori che spiegano cosa contiene ogni segnaposto']
Non costruire frasi concatenando frammenti di traduzione.
Usa segnaposto nominati ('{name}') invece di posizionali ({0}) per chiarezza
Fornisci commenti contestuali per i traduttori che spiegano cosa contiene ogni segnaposto
Un tipico scenario.
Lo sviluppatore scrive: 'You have ' + count + ' items in your ' + cartType + ' cart' — funziona perfettamente in inglese.
Il traduttore tedesco riceve tre frammenti separati e non può formare una frase grammaticalmente corretta perché l'ordine delle parole deve cambiare.
Risultato: gli utenti tedeschi vedono 'Sie haben 5 Artikel in Ihrem Warenkorb Standard' — goffo e poco professionale.
Perché questo è un problema
Ogni string concatenato è una bomba a orologeria. Con 20 lingue e 50 string concatenate hai 1.000 potenziali errori grammaticali che devono essere corretti manualmente.
La concatenazione di stringhe come 'Willkommen ' + userName + ', du hast ' + count + ' neue Nachrichten' presuppone una determinata posizione delle parole. I traduttori ricevono frammenti senza contesto e non possono riordinare.
Gli utenti vedono frasi grammaticalmente scorrette. In tedesco spesso il verbo si trova alla fine. In arabo l'intera struttura è invertita. Il risultato suona come una stupidaggine.
Ecco come risolverlo
Usa messaggi parametrici con placeholder nominativi, in modo che i traduttori possano riordinare l'intera frase.
Sostituisci la concatenazione con una singola chiave di messaggio con segnaposto: 'cart.summary': 'Hai {count} articoli nel tuo '{cartType}' carrello'.
Passa le variabili come parametri alla tua funzione di traduzione: t('cart.summary', { count: 5, cartType: 'Premium' }).
I traduttori possono ora riorganizzare liberamente: 'Nel tuo '{cartType}' ci sono {count} articoli' — tedesco grammaticalmente corretto.
Errore #3: Ignorare la pluralizzazione
L'inglese ha due forme plurali: singolare e plurale. Gli sviluppatori spesso presumono che tutte le lingue funzionino nello stesso modo. Non è così. Il polacco ha 4 forme, l'arabo ne ha 6, e persino lingue come il francese trattano lo zero in modo diverso dall'inglese.
['Usa sempre ICU MessageFormat o una libreria equivalente per contenuti con plurali', 'Non scrivere mai logica di pluralizzazione personalizzata — fidati delle regole CLDR', 'Testa i plurali con valori come 0, 1, 2, 5, 21 e 100 per coprire tutte le categorie']
Usa sempre ICU MessageFormat o una libreria equivalente per contenuti conteggiabili
Non scrivere mai logica plurale da solo — affida tutto alle regole CLDR
Testa i plurali con valori come 0, 1, 2, 5, 21 e 100 per coprire tutte le categorie
Uno scenario tipico.
Lo sviluppatore scrive: count + (count === 1 ? 'Datei' : 'Dateien') — tratta correttamente il tedesco.
Il traduttore polacco ha bisogno di 4 forme: 1 plik, 2-4 pliki, 5-21 plików, 22-24 pliki. L'operatore ternario semplice non può esprimerlo.
Risultato: gli utenti polacchi vedono '5 pliki' (forma errata) anziché '5 plików' (forma corretta), e l'app sembra rotta.
Perché è un problema
Ogni sostantivo numerabile nella tua app richiede una gestione plurale. Con 50 stringhe di questo tipo e 20 lingue, si hanno 1.000 regole di plurale — impossibili da gestire manualmente.
Verifiche semplici con if/else (count === 1 ? 'Datei' : 'Dateien') gestiscono solo tedesco/inglese. CLDR definisce fino a 6 categorie di plurale: zero, one, two, few, many e other. Ogni lingua utilizza una sottoinsieme diversa.
Gli utenti vedono testi grammaticalmente scorretti come '1 Nachrichten' o forme plurali completamente errate. In contesti formali, ciò compromette la credibilità.
Ecco come risolverlo
Usa ICU MessageFormat, che supporta tutte le regole di plurale CLDR out of the box.
Definisci i messaggi con la sintassi ICU: 'fileCount': '{count, plural, one {# Datei} other {# Dateien}}'.
I traduttori forniscono tutte le forme di plurale necessarie per la loro lingua. Polacco: '{count, plural, one {# plik} few {# pliki} many {# plików} other {# pliku}}'.
La tua libreria i18n seleziona automaticamente la forma corretta in fase di esecuzione in base alle regole CLDR della locale attiva.
Errore #4: Larghezze fisse degli elementi UI
I designer creano layout pixel-perfect in inglese e gli sviluppatori li implementano con larghezze fisse. Ma il testo tradotto può essere notevolmente più lungo o più corto. Il testo tedesco è circa il 30% più lungo rispetto all'inglese, mentre il testo cinese può essere circa il 50% più corto.
['Non utilizzare mai larghezze fisse in pixel sugli elementi con testo traducibile', 'Pianifica un aumento del testo del 40% come baseline — alcune lingue si espandono ancora di più', 'Usa CSS Flexbox o Grid per layout che si adattano a lunghezze di contenuto variabili']
Non utilizzare mai larghezze in pixel fisse per elementi con testo traducibile
Pianifica un aumento del testo del 40% come baseline — alcune lingue si espandono ancora di più
Usa CSS Flexbox o Grid per layout che si adattano a contenuti di lunghezza variabile
Un tipico scenario
Il designer crea una barra di navigazione con 5 pulsanti, ognuno largo esattamente 100px — sembra perfetta in inglese.
Traduzione tedesca: 'Settings' diventa 'Einstellungen' (13 contro 8 caratteri), 'Submit' diventa 'Absenden' (8 contro 6). La navbar va oltre i limiti.
Risultato: sui dispositivi mobili i pulsanti si impilano uno sull'altro o il testo viene tagliato, rendendo la navigazione inutilizzabile per gli utenti tedeschi.
Perché questo è un problema
Ogni elemento con larghezza fissa è un potenziale punto di rottura. Un'app tipica ha centinaia di pulsanti, etichette e schede che devono supportare l'espansione del testo.
Contenitore con larghezza fissa (width: 120px) e pulsanti di dimensioni fisse si tagliano o traboccano quando il testo si espande. CSS overflow: hidden nasconde il contenuto silenziosamente, mentre overflow: visible distrugge il layout.
Gli utenti vedono etichette tagliate come 'Impostaz...' anziché 'Impostazioni', oppure pulsanti che si sovrappongono agli elementi vicini. Le azioni critiche diventano illeggibili o non cliccabili.
Ecco come risolverlo
Progetta e implementa layout flessibili che si adattano alla lunghezza dei contenuti di tutte le località.
Sostituisci le larghezze fisse con min-width, max-width e layout Flex. Usa CSS Grid o Flexbox per distribuire lo spazio in modo dinamico.
Imposta il contenitore del testo per l'interruzione di riga: usa overflow-wrap: break-word e evita white-space: nowrap per contenuti traducibili.
Prova l'interfaccia utente con una pseudo-localizzazione che allunga tutte le stringhe del 40% per simulare il peggior caso — prima ancora di inviare le stringhe ai traduttori.
Errore #5: Formattazione di date e numeri
Dati e numeri sembrano universali a prima vista. Ma 01/02/2025 indica il 2 gennaio negli USA e il 1 febbraio in Europa. La virgola e il punto cambiano significato: 1,000.50 (USA) vs 1.000,50 (Germania). Farlo male provoca confusione, errori sui dati e perdita di fiducia.
['Non formattare mai dati o numeri manualmente con template di stringhe — usa sempre le API Intl', 'Salva tutti i dati in ISO 8601 e le valute nella più piccola unità (centesimi) internamente', 'Testa con Locales che utilizzano separatori decimali differenti, ordini di data e sistemi di calendario differenti']
Non formattare mai dati o numeri manualmente con template di stringhe — usa sempre le API Intl
Archivia tutti i dati in ISO 8601 e le valute nell'unità più piccola (centesimi) internamente
Testa con locali che utilizzano separatori decimali, ordini di data e sistemi di calendario differenti
Uno scenario tipico
Lo sviluppatore formatta una data come MM/DD/YYYY e un prezzo come $1,234.50 — corretto per gli utenti statunitensi.
Un utente tedesco vede la data 03/04/2025 e la legge come 3 aprile (convenzione DD/MM/YYYY). Il prezzo $1,234.50 sembra dovrebbe essere 1.234,50.
Risultato: l'utente prenota un volo per la data sbagliata e mette in dubbio il formato dei prezzi. I ticket di supporto aumentano nel mercato tedesco del 15%.
Perché questo è un problema
La formattazione di date e numeri riguarda ogni visualizzazione dati nella tua app: tabelle, grafici, form, fatture, report. Una correzione globale copre centinaia di istanze.
Stringhe di formato codificate, come toLocaleDateString('en-US') o la formattazione manuale con template literals, ignorano la locale effettiva dell'utente. Anche se la locale è corretta, ma il calendario sbagliato (gregoriano vs hijri) provoca problemi.
Gli utenti leggono i dati in modo errato e inseriscono i dati nel formato sbagliato. Un utente europeo che vede 03/04/2025 potrebbe interpretarlo come 3 aprile anziché 4 marzo — appuntamenti persi o prenotazioni errate.
Ecco come risolverlo
Usa l'API Intl integrata o una libreria di formattazione che tenga conto della localizzazione per tutte le date, orari, numeri e valute.
Sostituisci la formattazione manuale con Intl.DateTimeFormat(locale) per le date e Intl.NumberFormat(locale, { style: 'currency', currency }) per i prezzi.
Frame internamente i dati nel formato ISO 8601 (YYYY-MM-DD) e formatali solo per la visualizzazione con la locale dell'utente.
Testa visualizzazioni di date e numeri critiche con almeno 5 localizzazioni diverse: en-US, de-DE, ja-JP, ar-SA e zh-CN, per coprire le varianti di formattazione più importanti.
Errore #6: Dimenticare le lingue RTL
Descrizione dell'errore: Le lingue RTL come arabo, ebraico e persiano sono parlate da oltre 500 milioni di persone. Tuttavia la maggior parte delle app è progettata solo per layout da destra a sinistra (LTR). Il supporto RTL non significa solo capovolgere il testo: l'intera interfaccia utente deve essere riflessa.
['Usa esclusivamente proprietà CSS logiche fin dall'inizio (inline-start/end, block-start/end)', "Testa la tua app con dir='rtl' sull'elemento HTML in ogni Sprint-Review", 'Crea una checklist di test RTL per navigazione, icone, moduli e indicatori di avanzamento']
Usa fin dall'inizio solo proprietà CSS logiche (inline-start/end, block-start/end)
Testa la tua app con dir='rtl' sull'elemento HTML ad ogni revisione dello sprint
Crea una checklist di test RTL per navigazione, icone, moduli e indicatori di avanzamento
Uno scenario tipico
Lo sviluppatore usa margin-left: 16px e text-align: left in tutta l'app — pratica standard LTR.
L'applicazione si avvia in Arabia Saudita. I tasti Indietro puntano in avanti, le barre laterali appaiono sul lato sbagliato e i dati numerici non sono allineati correttamente.
Risultato: gli utenti arabi abbandonano l'app dopo 30 secondi. Il team ha bisogno di 4 settimane di refactoring CSS di emergenza per risolvere il problema.
Perché questo è un problema
Il supporto RTL riguarda ogni singolo componente della tua app. Introdurre RTL in un secondo momento di solito richiede la riscrittura del 30-50% di tutte le regole CSS e la verifica di ogni icona e layout.
Proprietà CSS come margin-left, padding-right, text-align: left e float: left codificano rigidamente la direzione. Le icone con significato di direzione ( frecce, indicatori di avanzamento ) puntano nella direzione sbagliata. Anche i valori border-radius devono essere riflessi.
Gli utenti arabi vedono la navigazione nell'angolo sbagliato, la barra di avanzamento che procede al contrario e testo che entra in collisione con gli elementi dell'interfaccia. L'app sembra estranea e inutilizzabile.
Ecco come risolverlo
Usa proprietà CSS logiche e testa con layout RTL fin dall'inizio.
Sostituisci tutte le proprietà CSS fisiche con equivalenti logici: margin-left → margin-inline-start, padding-right → padding-inline-end, text-align: left → text-align: start.
Imposta l'attributo dir sull'elemento radice HTML in base alla locale attiva. Usa la pseudo-classe CSS :dir(rtl) per i override RTL-specifici.
Controlla tutte le icone per il significato di direzione. Sostituisci le icone dipendenti dalla direzione con versioni specchiate o usa CSS transform: scaleX(-1) per i contesti RTL.
Errore #7: Immagini con testo
Incorporare testo nelle immagini — sia in banner hero, pulsanti, infografiche o screenshot — è un incubo di localizzazione. Ogni immagine con testo deve essere rifatta per ogni lingua, aumentando i costi di design e ritardando le versioni.
['Non inserire mai testo traducibile direttamente nelle immagini raster (PNG, JPG)', 'Usa overlay di testo CSS su immagini di sfondo per hero banner e CTA', 'Automatizza la generazione di screenshot per le schede App Store e le pagine di marketing']
Non inserire mai testo traducibile direttamente in immagini raster (PNG, JPG)
Usa overlay di testo CSS su sfondi per hero banner e CTA
Automatizza la generazione di screenshot per gli elenchi dell'App Store e le pagine di marketing
Un tipico scenario
Un designer crea un banner promozionale con il testo 'Start Your Free Trial' inserito direttamente nell'immagine.
Il team di localizzazione traduce tutte le stringhe UI, ma nello stesso banner sulla pagina tedesca viene ancora mostrato il testo in inglese.
Risultato: la landing page tedesca ha un banner in inglese che irrita. Creare banner localizzati per 15 lingue richiede 3 giorni di lavoro di design e ritarda il lancio.
Perché questo è un problema
Una tipica pagina di marketing ha 5-10 immagini con testo. In 15 lingue sono 75-150 varianti di immagini da creare, mantenere e aggiornare ad ogni modifica del design.
Il testo inserito nelle immagini (PNG, JPG, SVG con testo incorporato) non può essere estratto da strumenti di traduzione. Ogni versione localizzata richiede che un designer modifichi manualmente il file sorgente, lo esporti e lo carichi.
Gli utenti vedono immagini con testo in una lingua straniera, oppure peggio, una combinazione di interfaccia localizzata e immagini non tradotte. Questo appare incoerente e mina la fiducia nel marchio.
Ecco come risolverlo
Separa il testo dall'immagine utilizzando overlay CSS, SVG con elementi di testo traducibili o generazione dinamica delle immagini.
Usa CSS per posizionare il testo traducibile sopra le immagini di sfondo: posiziona lo strato di testo con posizionamento assoluto sopra il contenitore dell'immagine.
Per le infografiche o diagrammi, usa SVG con elementi <text> che fanno riferimento alle chiavi di traduzione, invece di incorporare stringhe grezze.
Per gli screenshot delle app nei materiali di marketing, automatizza la generazione degli screenshot con strumenti come Fastlane (Mobile) o Playwright (Web), che acquisiscono gli schermi in ogni locale.
Errore #8: Mancanza di gestione delle traduzioni mancanti
Le traduzioni sono sempre incomplete durante lo sviluppo. Le nuove funzionalità aggiungono stringhe più rapidamente di quanto i traduttori possano tradurle. Senza una corretta gestione del fallback, le traduzioni mancanti causano arresti, interfacce utente vuote o chiavi di traduzione grezze che vengono visualizzate agli utenti.
['Configura sempre almeno una lingua di fallback nel tuo setup i18n', 'Registra le chiavi di traduzione mancanti nel tuo sistema di monitoraggio per il tracciamento', 'Stabilisci un livello minimo di copertura delle traduzioni prima che una locale possa andare live']
Configura sempre almeno una lingua di fallback nel tuo setup i18n
Registra le chiavi di traduzione mancanti nel tuo sistema di monitoraggio per la tracciabilità
Imposta una soglia minima di copertura della traduzione prima che una locale possa andare live
Un tipico scenario
Lo sviluppatore aggiunge una nuova sezione 'Premium Features' con 15 nuove chiavi di traduzione. La versione in inglese viene rilasciata immediatamente.
Le traduzioni in francese non sono ancora pronte. La pagina francese mostra chiavi grezze: 'premium.feature1.title', 'premium.feature1.description'.
Risultato: gli utenti francesi vedono una pagina rotta piena di nomi di chiavi lato sviluppatore. Il team di supporto riceve decine di segnalazioni di bug.
Perché questo è un problema
Più l'app cresce, maggiore sarà il divario tra le stringhe in inglese e le traduzioni in altre lingue. Un'app con 100 lingue e 2.000 string potrebbe avere in ogni momento oltre 10.000 traduzioni mancanti.
Senza logica di fallback, una chiave di traduzione mancante restituisce undefined, null o la stringa chiave grezza (ad es. 'checkout.confirmButton'). I motori di template possono generare errori, la pagina può bloccarsi o non rendere nulla.
Gli utenti vedono un'interfaccia utente danneggiata: pulsanti vuoti, etichette mancanti o stringhe criptiche come 'nav.settings.title' invece del testo reale. È confuso e poco professionale.
Soluzione
Configura una robusta catena di fallback e monitora la copertura delle traduzioni in tutte le località.
Configura una catena di fallback della lingua nella configurazione i18n: le chiavi in francese mancanti (fr) verranno automaticamente reindirizzate all'inglese (en).
Aggiungi un gestore di chiavi mancanti che registra le chiavi non tradotte nel tuo sistema di monitoraggio (ad esempio Sentry, Datadog), senza compromettere l'esperienza dell'utente.
Crea una dashboard di copertura delle traduzioni che monitori il livello di completamento per locale e blocchi le release se la copertura scende al di sotto di una soglia (ad es. 95%).
Errore #9: Problemi di codifica dei caratteri
I problemi di codifica dei caratteri sono il killer silenzioso della localizzazione. Tutto sembra corretto in inglese e nelle lingue europee, ma non appena aggiungi cinese, giapponese, coreano, arabo o emoji compaiono caratteri distorti (Mojibake). Questi bug sono noti per essere difficili da individuare.
['Utilizza la codifica UTF-8 ovunque — file di origine, database, risposte API e tag HTML meta', 'Usa utf8mb4 in MySQL (non utf8) per supportare l'intero intervallo Unicode incluso emoji', 'Testa con contenuti reali in CJK, arabo e emoji per individuare i problemi di codifica in anticipo']
Usa UTF-8 ovunque — file sorgente, database, risposte API e tag meta HTML
Usa utf8mb4 in MySQL (non utf8) per supportare l'intero intervallo Unicode incluso emoji
Testa con contenuti reali in CJK, arabo e emoji per individuare i problemi di codifica in anticipo
Uno scenario tipico
Gli sviluppatori configurano un database MySQL con collation latin1 (lo standard vecchio). Il codice sorgente dell'applicazione utilizza UTF-8.
Gli utenti giapponesi si registrano con il loro vero nome. Il database memorizza '田中太郎' come byte danneggiati.
Risultato: Il profilo utente mostra testo corrotto. Peggiore: la ricerca e l'ordinamento per tutti i nomi CJK si rompono, coinvolgendo migliaia di utenti.
Perché questo è un problema
I problemi di codifica si diffondono attraverso l'intera stack. Una collation del database configurata in modo errato può danneggiare milioni di record — la riparazione richiede migrazioni dati costose.
Codifica non coerente lungo lo stack — UTF-8 nei file sorgente, Latin-1 nel database e Windows-1252 nella risposta API — distrugge i caratteri multibyte. Un singolo livello configurato in modo errato trasforma '日本語' in '????' o in '日本èª'.
Gli utenti vedono testi mutilati, punti interrogativi o quadratini vuoti dove dovrebbe comparire la loro lingua. Nel peggiore dei casi, gli input dei moduli possono essere permanentemente danneggiati nel database.
Ecco come risolverlo
Forza la codifica UTF-8 in modo coerente su ogni livello del tuo stack di applicazioni.
Imposta tutti i file sorgente su UTF-8 (configura il tuo editor e .editorconfig). Aggiungi <meta charset='UTF-8'> nel tuo HTML e 'Content-Type: application/json; charset=utf-8' nelle risposte API.
Configura il database su utf8mb4 (non solo utf8, che in MySQL è un sottoinsieme a 3 byte). Imposta la collation di connessione su utf8mb4_unicode_ci.
Scegli i font che coprono i tuoi sistemi di scrittura target: latino, cirillico, CJK, arabo, devanagari. Usa stack di font di sistema o Google Fonts con sottoscritti di lingua per caricamento ottimale.
Testare l'implementazione i18n
Test di estensione della lunghezza
Espandi tutti i testi tradotti del 30-40% per simulare l'aumento di testo che si verifica in lingue verbose come il tedesco, il finlandese o il greco. Copre contenitori a larghezza fissa, etichette tagliate e pulsanti che traboccano prima di iniziare la traduzione. Molti strumenti di pseudo-localizzazione offrono questa funzione come opzione integrata.
"Invia" → "Ṡééééñðéñ_éxpáñðéð" (40% più lungo)
Pseudo-localizzazione
La pseudo-localizzazione sostituisce ogni carattere con un equivalente accentato (es. 'a' → 'á') e avvolge le stringhe con marcature come [!! e !!]. In questo modo è subito visibile quali stringhe sono hard-coded e quali provengono dal sistema di traduzione. Esegui la pseudo-localizzazione come parte della pipeline CI per catturare automaticamente le regressioni.
Ogni testo sullo schermo che non è racchiuso tra [!! !!] è hard-coded e deve essere esternalizzato.Questo test intercetta circa il 95% delle stringhe trascurate in meno di un minuto.
"Invia messaggio" → "[!! Ñáçḥŕíçḥṫ ṡéñðéñ !!]"
Test del layout RTL
Anche senza traduzioni in arabo o ebraico, puoi testare il layout RTL aggiungendo dir='rtl' all'elemento radice HTML. Questo rileva immediatamente bug di CSS direzionali: icone allineate in modo errato, margini sul lato sbagliato, navigazione rotta e elementi Flex ordinati in modo errato. Rendine questo un controllo standard in ogni sprint di review — richiede circa 10 secondi per cambiare e individuare problemi che altrimenti richiederebbero settimane per essere risolti in produzione.
La lista di controllo i18n
['Tutti i testi visibili all''utente devono essere spostati nei file delle risorse', 'Nessuna concatenazione di stringhe per creare frasi', 'Regole di plurale implementate con ICU MessageFormat o equivalente', 'La formattazione di date, orari e numeri utilizza API locali', 'Layout RTL testato con contenuti arabi o ebraici', 'Interfaccia flessibile senza larghezze fisse sugli elementi testuali', 'È configurata una lingua di fallback e testata in caso di chiavi mancanti', 'Codifica UTF-8 coerente su tutti i file e i database', 'Metadati dell''App Store e del Google Play Store localizzati per ogni mercato', 'Screenshot e asset di marketing per ogni lingua aggiornati']