I dati sui nomi per locale sono il punto in cui un design di modulo che sembrava neutro si rivela scritto per una sola parte del mondo. L’assunzione è quasi sempre la stessa — che una persona abbia un nome proprio seguito da un cognome, in quest’ordine, nell’alfabeto latino, separati da uno spazio — e ogni clausola di quella frase è falsa da qualche parte.
Questa guida esamina le differenze strutturali che contano quando i dati vengono memorizzati anziché visualizzati, e spiega cosa deve contenere una suite di test prima che qualcuno possa affermare che un campo nome è internazionalizzato.
La composizione di un nome varia
I pezzi che compongono un nome personale non sono universali, e neppure lo è il loro numero. Le disposizioni comuni includono un nome proprio più un cognome, un cognome scritto prima del nome proprio, uno o più nomi propri senza alcun cognome, un nome proprio seguito da un patronimico derivato dal nome proprio di un genitore, e cognomi composti scritti con uno spazio o un trattino tra le parti.
Nessuna di queste è un’eccezione a una regola; sono semplicemente regole diverse. Un modulo che ragiona per “il nome” e “il cognome” afferma una struttura che una parte sostanziale del mondo non segue, e l’affermazione fallisce nel punto in cui i dati vengono usati anziché in quello in cui vengono inseriti — in un saluto, in un’etichetta di spedizione, in una lista ordinata, in un algoritmo di confronto.
Quali lingue mettono il cognome per primo?
Diverse lingue lo fanno, e non sono un piccolo gruppo. Le convenzioni di denominazione dell’Asia orientale collocano convenzionalmente il cognome per primo e il nome proprio per secondo, e l’ungherese fa lo stesso all’interno dell’Europa. Quando un simile nome viene registrato in un sistema che si aspetta l’ordine opposto, le due metà vengono scambiate, e lo scambio è invisibile perché entrambe le metà sono nomi personali plausibili.
Il guasto diventa grave quando il nome viene confrontato con un altro record o stampato su un documento. Una lettera indirizzata alla metà sbagliata di un nome è un piccolo imbarazzo; un documento di controllo alle frontiere o d’identità che mostra l’ordine sbagliato del nome è una categoria di problema del tutto diversa, ed è una delle ragioni per cui esistono standard internazionali per i documenti leggibili da macchina.
La lezione pratica è che l’ordine è una proprietà del record, non una proprietà del campo. Memorizza le parti in modo definito, memorizza la locale che ne governa l’ordine e formatta per la visualizzazione all’ultimo momento anziché al punto di inserimento.
I nomi unici sono legittimi?
Sì, e un modulo che richiede due campi nome rifiuterà una persona reale. I mononimi esistono come nomi legali in diversi paesi e culture, e chi li porta ci sbatte continuamente contro: il modulo insiste su un cognome, così digitano qualcosa, e adesso ogni documento con cui vengono confrontati discorda dal record.
Lo stesso schema appare in forme più lievi. Alcune persone hanno diversi nomi propri e nessuno slot per il secondo nome che li contenga. Alcune hanno un cognome composto da due parole che un parser basato su spazi separerà. Alcune hanno nomi di un solo carattere, che fa scattare i controlli di lunghezza minima scritti per tranquillità anziché per una ragione.
La correzione è strutturale anziché cosmetica: contrassegna il secondo campo nome come opzionale per i paesi in cui è opzionale o, meglio, tratta l’intero nome come un unico valore con campi parte opzionali che non sono mai obbligatori per impostazione predefinita. La validazione dovrebbe rifiutare ciò che è impossibile, non ciò che è semplicemente poco familiare.
Cosa succede a un nome in un altro alfabeto?
Succedono due cose, e spesso vengono confuse tra loro. La prima è la traslitterazione: convertire un nome scritto in un sistema di scrittura in un altro, che è una mappatura con scelte reali al suo interno e più di una convenzione accettata. La seconda è la normalizzazione: decidere se due stringhe che sembrano identiche lo siano davvero, che è una questione di memorizzazione e confronto.
I diacritici contano in entrambe. Un nome che porta un accento è una stringa diversa dallo stesso nome senza, e se vadano considerati uguali dipende da cosa stai facendo. Confrontare due record dovrebbe di solito essere insensibile agli accenti; stampare un documento non dovrebbe mai togliere gli accenti. Anche la collazione — l’ordine in cui i nomi si ordinano — dipende dalla lingua, quindi una lista ordinata secondo la locale predefinita del server non sarà nell’ordine che un lettore di quella lingua si aspetta.
Le maiuscole sono più sottili di quanto sembri. Convertire un nome in maiuscolo può cambiarne la lunghezza in alcune lingue, e un piccolo numero di coppie di lettere ha forme maiuscole diverse a seconda della lingua. Un campo nome che converte in maiuscolo per la visualizzazione e memorizza il risultato ha distrutto un’informazione che non può ricostruire.
Perché i problemi di codifica continuano a riemergere
Due stringhe possono essere visualizzate in modo identico sullo schermo e comunque non essere uguali, perché un carattere con accento può essere rappresentato o come un unico carattere precomposto oppure come un carattere di base seguito da un segno combinatorio. Entrambe le forme sono valide, entrambe si visualizzano allo stesso modo, e confrontarle byte per byte restituisce falso.
Lo stesso problema compare ogni volta che il testo si sposta tra sistemi con assunzioni diverse su cosa significhi un identificatore. La correzione duratura è normalizzare al confine — quando i dati entrano, quando vengono confrontati e quando vengono esportati — usando un’unica forma concordata anziché quella che è arrivata.
È anche il motivo per cui una suite di test ha bisogno di nomi non latini e accentati. Una fixture fatta interamente di nomi latini semplici supererà ogni controllo mentre i dati di produzione ne rompono tranquillamente tre. I record del generatore di identità e dati di test sono estratti paese per paese e portano le convenzioni di denominazione di quel paese, il che li rende comodi per questo tipo di copertura; sono nomi sintetici solo a fini di test e non appartengono a nessuno.
Come dovrebbero essere disposti i campi nome?
Parti da ciò a cui servono i dati e procedi a ritroso. La maggior parte dei sistemi ha bisogno di visualizzare un nome, ordinare un nome e cercare un nome, e nessuna di quelle operazioni richiede che il nome sia diviso in esattamente due parti al momento dell’inserimento.
- Un unico campo di visualizzazione contiene il nome come dovrebbe essere letto, nell’ordine dettato dalla locale del record.
- I campi parte separati sono opzionali e mai entrambi obbligatori; un modulo che insiste su un cognome non è internazionale.
- Un marcatore di locale o di scrittura sul record consente a formattazione e ordinamento di fare la scelta giusta più tardi.
- I limiti di lunghezza sono generosi, perché i nomi reali sono più lunghi degli esempi in qualunque specifica.
- La ricerca indicizza la forma normalizzata, mentre il valore memorizzato conserva i suoi caratteri originali.
Quella struttura costa una colonna in più e rimuove un’intera classe di difetti. Impedisce anche che il nome venga riformattato in silenzio da qualunque livello lo tocchi per primo.
Per gli sviluppatori: campi, ordine e confronto
Modella il nome come una piccola struttura con un proprietario chiaro. Memorizza le parti che ti sono state date, più l’ordine a cui appartengono, e deriva la stringa di visualizzazione su richiesta. Non memorizzare mai il risultato di una conversione di maiuscole o di una rimozione di accenti; memorizza l’originale e normalizza una copia per il confronto.
Per le fixture, copri le forme che rompono le assunzioni anziché aggiungerne altre ordinarie: un mononimo, un cognome collocato per primo, un composto con trattino, un nome con un accento come segno combinatorio e un nome lungo un solo carattere. Quei cinque intercettano la maggior parte dei difetti che cento nomi ordinari non intercettano.
Poi controlla le due operazioni che le persone dimenticano. L’ordinamento dovrebbe seguire la locale del record anziché quella della macchina, e il troncamento dovrebbe essere verificato contro il nome più lungo che i dati contengono effettivamente, perché una struttura che contiene ogni esempio della specifica non è prova che contenga il database. Ogni nome in una fixture di test è inventato per i test software, e nessun record generato in questo modo identifica o sostituisce una persona reale.
Passi successivi
Rendi opzionale il campo cognome in un modulo questa settimana e vedi se qualcosa a valle ne dipende; se la risposta è sì, la dipendenza è il bug. Poi genera un insieme di nomi attraverso diverse locale nel generatore di identità e falli passare attraverso i tuoi percorsi di visualizzazione, ordinamento e ricerca, verificando che l’ordinamento cambi con la locale del record anziché con quella del server. L’articolo sulla coerenza dei campi copre le altre coppie con cui quei nomi devono concordare.