Naamgegevens per locale zijn waar een formulierontwerp dat neutraal leek, geschreven blijkt te zijn voor één deel van de wereld. De aanname is bijna altijd dezelfde — dat iemand een voornaam heeft gevolgd door een achternaam, in die volgorde, in het Latijnse alfabet, gescheiden door een spatie — en elke clausule van die zin is ergens onwaar.
Deze gids loopt de structurele verschillen door die ertoe doen wanneer gegevens worden opgeslagen in plaats van weergegeven, en legt uit wat een testsuite moet bevatten voordat iemand kan claimen dat een naamveld geïnternationaliseerd is.
Waaruit een naam bestaat, varieert
De stukken waaruit een persoonsnaam bestaat zijn niet universeel, en hun aantal evenmin. Gangbare arrangementen zijn een voornaam plus een achternaam, een achternaam geschreven vóór een voornaam, een of meer voornamen zonder achternaam, een voornaam gevolgd door een patroniem afgeleid van de voornaam van een ouder, en samengestelde achternamen geschreven met een spatie of een koppelteken tussen de delen.
Geen van deze is een uitzondering op een regel; het zijn simpelweg andere regels. Een formulier dat redeneert over “de voornaam” en “de achternaam” stelt een structuur die een substantieel deel van de wereld niet volgt, en de bewering faalt op het punt waar de gegevens worden gebruikt in plaats van waar ze worden ingevoerd — in een begroeting, op een verzendlabel, in een gesorteerde lijst, in een matchingalgoritme.
Welke talen zetten de achternaam vooraan?
Verschillende, en het is geen kleine groep. Oost-Aziatische naamconventies plaatsen de achternaam conventioneel vooraan en de voornaam tweede, en het Hongaars doet hetzelfde binnen Europa. Wanneer zo’n naam wordt vastgelegd in een systeem dat de tegenovergestelde volgorde verwacht, raken de twee helften verwisseld, en de verwisseling is onzichtbaar omdat beide helften plausibele persoonsnamen zijn.
De fout wordt ernstig wanneer de naam wordt gematcht tegen een ander record of op een document wordt afgedrukt. Een brief gericht aan de verkeerde helft van een naam is een kleine gêne; een grenscontrole- of identiteitsdocument met de verkeerde naamvolgorde is een heel andere categorie probleem, en het is een van de redenen waarom internationale standaarden voor machinaal leesbare documenten bestaan.
De praktische les is dat de volgorde een eigenschap van het record is, niet een eigenschap van het veld. Sla de delen op een gedefinieerde manier op, sla de locale op die hun volgorde bepaalt, en formatteer voor weergave op het laatste moment in plaats van op het punt van invoer.
Zijn enkele namen legitiem?
Ja, en een formulier dat twee naamvelden vereist, wijst een echt persoon af. Mononiemen bestaan als wettelijke namen in verschillende landen en culturen, en mensen die ze dragen lopen hier voortdurend tegenaan: het formulier staat erop dat er een achternaam is, dus typen ze iets, en nu spreekt elk document waarmee ze worden vergeleken het record tegen.
Hetzelfde patroon verschijnt in mildere vormen. Sommige mensen hebben meerdere voornamen en geen middelste-naamslot dat bij hen past. Sommige hebben een achternaam die uit twee woorden bestaat die een op spaties gesplitste parser zal splitsen. Sommige hebben namen die één teken zijn, wat controles op minimale lengte doet struikelen die zijn geschreven voor geruststelling in plaats van met een reden.
De oplossing is structureel in plaats van cosmetisch: markeer het tweede naamveld als optioneel voor de landen waar het optioneel is, of beter nog, behandel de hele naam als één waarde met optionele deelvelden die nooit standaard vereist zijn. Validatie moet afwijzen wat onmogelijk is, niet wat slechts onbekend is.
Wat gebeurt er met een naam in een ander alfabet?
Twee dingen gebeuren, en ze worden vaak met elkaar verward. Het eerste is transliteratie: een naam geschreven in het ene schriftsysteem omzetten naar een ander, wat een mapping is met echte keuzes erin en meer dan één geaccepteerde conventie. Het tweede is normalisatie: beslissen of twee tekenreeksen die identiek lijken werkelijk identiek zijn, wat een opslag- en vergelijkingsvraag is.
Diakritische tekens doen in beide ertoe. Een naam met een accent is een andere tekenreeks dan dezelfde naam zonder, en of ze als gelijk moeten worden behandeld hangt af van wat u doet. Twee records matchen zou meestal accentongevoelig moeten zijn; een document afdrukken mag nooit accenten strippen. Collatie — de volgorde waarin namen sorteren — is ook taalspecifiek, dus een lijst gesorteerd op de standaard-locale van de server staat niet in de volgorde die een lezer van die taal verwacht.
Hoofdlettergebruik is subtieler dan het lijkt. Een naam omzetten naar hoofdletters kan de lengte ervan in sommige talen veranderen, en een klein aantal letterparen heeft verschillende hoofdlettervormen afhankelijk van de taal. Een naamveld dat voor weergave naar hoofdletters omzet en het resultaat opslaat, heeft informatie vernietigd die het niet kan reconstrueren.
Waarom coderingsproblemen blijven opduiken
Twee tekenreeksen kunnen identiek op het scherm verschijnen en toch niet gelijk zijn, omdat een teken met een accent kan worden weergegeven als één vooraf samengesteld teken of als een basisteken gevolgd door een combinerend teken. Beide zijn geldig, beide worden hetzelfde weergegeven, en ze byte voor byte vergelijken levert onwaar op.
Hetzelfde probleem verschijnt wanneer tekst beweegt tussen systemen met verschillende aannames over wat een identificator betekent. De duurzame oplossing is normaliseren op de grens — wanneer gegevens binnenkomen, wanneer ze worden vergeleken, en wanneer ze worden geëxporteerd — met één overeengekomen vorm in plaats van degene die toevallig aankwam.
Dit is ook waarom een testsuite niet-Latijnse en geaccentueerde namen nodig heeft. Een fixture die volledig uit gewone Latijnse namen bestaat, doorstaat elke controle terwijl de productiegegevens er stilletjes drie breken. Records van de generator voor identiteits- en testgegevens worden per land getrokken en dragen de naamconventies van dat land, wat ze handig maakt voor dit soort dekking; het zijn synthetische namen uitsluitend voor testdoeleinden en ze zijn van niemand.
Hoe moeten naamvelden worden ingedeeld?
Begin bij waarvoor de gegevens worden gebruikt en werk terug. De meeste systemen moeten een naam weergeven, sorteren en doorzoeken, en geen van die bewerkingen vereist dat de naam bij invoer in precies twee delen wordt gesplitst.
- Een enkel weergaveveld bevat de naam zoals die gelezen moet worden, in de volgorde die de locale van het record voorschrijft.
- Afzonderlijke deelvelden zijn optioneel en nooit beide vereist; een formulier dat op een achternaam staat, is niet internationaal.
- Een locale- of schriftmarkering op het record laat opmaak en sortering later de juiste keuze maken.
- Lengtelimieten zijn ruim, want echte namen zijn langer dan de voorbeelden in welke specificatie dan ook.
- Zoeken indexeert de genormaliseerde vorm, terwijl de opgeslagen waarde zijn oorspronkelijke tekens behoudt.
Die indeling kost één extra kolom en verwijdert een hele klasse defecten. Ze voorkomt ook dat de naam stilletjes opnieuw wordt geformatteerd door welke laag hem ook als eerste aanraakt.
Voor ontwikkelaars: velden, volgorde en vergelijking
Modelleer de naam als een kleine structuur met een duidelijke eigenaar. Sla de delen op die u heeft gekregen, plus de volgorde waarin ze horen, en leid de weergavetekst op aanvraag af. Sla nooit het resultaat op van een omzetting naar hoofdletters of een accentverwijdering; sla het origineel op en normaliseer een kopie voor vergelijking.
Dek voor fixtures de vormen die aannames breken in plaats van er meer gewone toe te voegen: een mononiem, een achternaam vooraan geplaatst, een samengestelde naam met koppelteken, een naam met een combinerend accent, en een naam van één teken lang. Die vijf vangen de meeste defecten die honderd gewone namen niet vangen.
Controleer dan de twee bewerkingen die mensen vergeten. Sorteren moet de locale van het record volgen in plaats van die van de machine, en afkappen moet worden geverifieerd tegen de langste naam die de gegevens werkelijk bevatten, want een lay-out die elk voorbeeld in de specificatie past, is geen bewijs dat hij in de database past. Elke naam in een testfixture is verzonnen voor softwaretesten, en geen op deze manier gegenereerd record identificeert of vertegenwoordigt een echt persoon.
Volgende stappen
Maak het achternaamveld deze week optioneel in één formulier en kijk of iets stroomafwaarts erop vertrouwt; als het antwoord ja is, is die afhankelijkheid de bug. Genereer dan een set namen over meerdere locales in de identiteitsgenerator en voer ze door uw weergave-, sorteer- en zoekpaden, en controleer dat de sortering verandert met de locale van het record in plaats van die van de server. Het artikel over veldconsistentie behandelt de andere paren waarmee die namen moeten overeenstemmen.