Paese e lingua è una di quelle distinzioni su cui tutti concordano in astratto e che tutti violano nella prima fixture. Una matrice di test viene scritta come una riga per lingua, a ogni riga viene attaccato un paese per far sembrare realistici i dati, e i due assi diventano silenziosamente uno solo.
Questo articolo li separa. Descrive i tre livelli che la parola localizzazione di solito nasconde, perché un tag di lingua e un codice di regione svolgono compiti diversi, e come campionare due assi senza fingere che siano lo stesso asse.
Perché paese e lingua non possono essere derivati l’uno dall’altro?
Una lingua può essere lingua ufficiale in molti paesi, e un paese può avere diverse lingue ufficiali. Entrambe le direzioni della relazione sono molteplici, quindi nessuno dei due valori determina l’altro.
La conseguenza per il testing è immediata. Se ogni lingua è accoppiata con esattamente un paese, la matrice ha una forma diagonale: contiene le coppie che qualcuno ha trovato naturali e nessuna delle altre. I guasti interessanti vivono fuori da quella diagonale: la stessa lingua che rende un formato diverso, e lo stesso formato che appare sotto una lingua diversa.
Una seconda conseguenza è più sottile. Poiché le coppie diagonali tendono a essere culturalmente familiari a chi ha scritto la matrice, sono anche le coppie in cui i presupposti del team hanno più probabilità di essere corretti. La matrice è più forte esattamente dove serve meno.
La localizzazione è in realtà tre livelli
Tratta la localizzazione come tre decisioni che per caso condividono una parola.
| Livello | La domanda a cui risponde | Proprietario tipico |
|---|---|---|
| Lingua dell’interfaccia | In quale lingua sono le etichette, i pulsanti e i messaggi? | Contenuti o prodotto |
| Regione dei contenuti | Le regole, i prezzi e le offerte di quale mercato si applicano? | Business |
| Formato dei dati | Quali convenzioni governano date, numeri, nomi e indirizzi? | Dati o ingegneria |
Ogni livello può essere impostato in modo indipendente, e nei sistemi reali spesso lo è. Un lettore può navigare in una lingua, ricevere le regole di un mercato in cui si trova in viaggio e inserire un indirizzo che segue le convenzioni di un terzo luogo.
Una volta separati i tre livelli, la maggior parte dei difetti di localizzazione diventa descrivibile. Un difetto è un caso in cui due livelli si presumeva si muovessero insieme e non l’hanno fatto.
Il tag di lingua e il codice di regione svolgono compiti diversi
Un tag di lingua descrive il testo. Dice in quale lingua è scritta una stringa e, a volte, quale scrittura o variante. Un codice di regione descrive le convenzioni che un valore segue: come è ordinata una data, come è punteggiato un numero, come è disposto un nome.
Non sono intercambiabili, e uno non è una versione più precisa dell’altro. Un sistema che memorizza solo un tag di lingua ha buttato via le informazioni necessarie a interpretare una data, e un sistema che memorizza solo un codice di regione ha buttato via le informazioni necessarie a scegliere un catalogo di messaggi.
Mantenere entrambi non è ridondanza; è il minimo richiesto per descrivere una pagina renderizzata. Il bug da tenere d’occhio è la scorciatoia nella direzione opposta: usare il tag di lingua come interruttore per la formattazione dei dati, cosa che funziona finché non arriva il primo paese che condivide una lingua con un altro.
Cosa si rompe quando un formato segue la lingua?
Il guasto classico è un valore convalidato secondo le convenzioni del paese sbagliato perché i due condividono una lingua. La lingua dell’utente è impostata correttamente, la regola di formato è scelta da quella lingua, e il valore viene rifiutato anche se è ben formato per il paese in cui l’utente vive davvero.
Ci sono versioni più silenziose. Un campo nome che riordina le parti perché l’interfaccia è in una lingua invece che perché il record appartiene a una regione con quell’ordine. Un campo numerico che accetta un separatore decimale dalla convenzione sbagliata e memorizza un valore sbagliato di ordini di grandezza. Una data interpretata giorno-prima in un punto e mese-prima in un altro, che finisce in un report come un istante plausibile ma errato.
Nessuno di questi è un problema di lingua. Sono tutti casi in cui una decisione di regione viene presa da un input di lingua, e la correzione è strutturale, non una tabella di ricerca migliore.
Come dovrebbe campionare due assi la matrice di test?
Campiona ciascun asse nei suoi termini, poi incrocia un piccolo numero di combinazioni scelte deliberatamente invece di ogni cella.
Inizia con l’asse della lingua e scegli voci che differiscono per ciò di cui l’interfaccia ha bisogno: una lingua che espande notevolmente il testo, una che richiede una scrittura diversa, una le cui regole di ordinamento differiscono dall’impostazione predefinita latina. Poi prendi l’asse della regione separatamente e scegli voci che differiscono per ciò di cui i dati hanno bisogno: una regione in cui un campo non esiste, una in cui un valore è insolitamente lungo, una le cui convenzioni entrano in conflitto con un vicino che condivide la sua lingua.
Gli incroci che contano di più sono quelli fuori diagonale: la stessa lingua in due regioni, e due lingue in una regione. Quelle quattro celle catturano la classe di difetto che “una lingua, un paese” non può esprimere, e sono economiche da aggiungere una volta che gli assi sono memorizzati separatamente.
Per il dettaglio linguistico di come nomi e testo si comportano per locale, c’è una guida separata sui dati sui nomi per locale, che resta sull’asse della lingua; l’asse della regione è ciò di cui tratta questo articolo.
Per gli sviluppatori: lasciare che la regione guidi il formato
Memorizza entrambi i valori, e sii esplicito su quale guida quale decisione. Le regole di formato dovrebbero essere selezionate dalla regione; i cataloghi di messaggi e il layout del testo dovrebbero essere selezionati dalla lingua; e nessuno dei due dovrebbe essere dedotto dall’altro al momento del rendering.
Tieni le due impostazioni in posti diversi della tua configurazione, con nomi che dicano cosa sono. Un campo chiamato locale che contiene un tag di lingua è un invito permanente per il prossimo sviluppatore a usarlo come regione. Un campo che contiene un codice di regione non dovrebbe mai essere descritto come la lingua che un utente parla.
Poi afferma la separazione nei test. Un test che rende una lingua attraverso diverse regioni, e una regione attraverso diverse lingue, fallisce rumorosamente nel momento in cui qualcuno reintroduce la scorciatoia. La directory dei paesi e delle regioni e una pagina di paese come la voce del Giappone mostrano come sono descritte le convenzioni di un singolo paese quando sono tenute una accanto all’altra, che è un riferimento più affidabile di un nome di lingua.
Nulla qui dovrebbe essere letto come una descrizione di traffico reale. Le combinazioni di lingua e regione usate come esempi in questo articolo sono scelte di campionamento costruite, non osservazioni di alcuna base di utenti reale, e non dicono nulla su dove viva qualcuno o su cosa parli.
Passi successivi
Annota i tre livelli per una schermata di cui il tuo team è responsabile, e nomina il valore che alimenta ciascuno di essi. Se due livelli sono alimentati dallo stesso valore, hai trovato la scorciatoia. La guida al test dei campi di selezione del paese porta l’asse della regione fino al controllo che l’utente tocca davvero, e la guida ai raggruppamenti regionali e livelli di mercato copre come vengono definite le regioni stesse.