Bei Namensdaten nach Sprachraum zeigt sich, dass ein neutral wirkender Formularentwurf für einen Teil der Welt geschrieben wurde. Die Annahme ist fast immer dieselbe — dass eine Person einen Vornamen und danach einen Familiennamen hat, in lateinischen Buchstaben, durch ein Leerzeichen getrennt — und jeder Teilsatz dieses Satzes ist irgendwo falsch.
Dieser Leitfaden geht die strukturellen Unterschiede durch, die zählen, wenn Daten gespeichert und nicht nur angezeigt werden, und erklärt, was eine Testsuite enthalten muss, bevor jemand behaupten kann, ein Namensfeld sei internationalisiert.
Woraus ein Name besteht, ist verschieden
Die Bestandteile eines Personennamens sind nicht universell, und ihre Anzahl ist es ebenso wenig. Häufige Anordnungen sind Vorname plus Familienname, ein vor dem Vornamen geschriebener Familienname, ein oder mehrere Vornamen ganz ohne Familiennamen, ein Vorname mit einem aus dem Vornamen eines Elternteils abgeleiteten Patronym und zusammengesetzte Familiennamen, die mit Leerzeichen oder Bindestrich verbunden sind.
Nichts davon ist eine Ausnahme von einer Regel; es sind einfach andere Regeln. Ein Formular, das über den Vornamen und den Nachnamen nachdenkt, behauptet eine Struktur, der ein erheblicher Teil der Welt nicht folgt, und die Behauptung scheitert dort, wo die Daten genutzt werden, nicht dort, wo sie erfasst werden — in einer Anrede, auf einem Versandetikett, in einer sortierten Liste, in einem Abgleichverfahren.
Welche Sprachen stellen den Familiennamen voran?
Mehrere, und es ist keine kleine Gruppe. Ostasiatische Namenskonventionen stellen den Familiennamen üblicherweise voran und den Vornamen dahinter, und innerhalb Europas macht das Ungarische dasselbe. Wird ein solcher Name in einem System erfasst, das die umgekehrte Reihenfolge erwartet, werden die beiden Hälften vertauscht, und der Tausch bleibt unsichtbar, weil beide Hälften plausible Personennamen sind.
Der Fehler wird gravierend, wenn der Name gegen einen anderen Datensatz abgeglichen oder auf ein Dokument gedruckt wird. Ein Brief, der an die falsche Namenshälfte adressiert ist, ist eine kleine Peinlichkeit; ein Grenzkontroll- oder Identitätsdokument mit falscher Namensreihenfolge ist eine ganz andere Kategorie von Problem, und es ist einer der Gründe, warum es internationale Standards für maschinenlesbare Dokumente gibt.
Die praktische Lehre: Die Reihenfolge ist eine Eigenschaft des Datensatzes, nicht des Feldes. Speichern Sie die Bestandteile in einer definierten Weise, speichern Sie den Sprachraum, der ihre Reihenfolge bestimmt, und formatieren Sie für die Anzeige erst im letzten Moment statt beim Erfassen.
Sind Einzelnamen zulässig?
Ja, und ein Formular, das zwei Namensfelder verlangt, weist eine echte Person ab. Mononyme existieren in mehreren Ländern und Kulturen als gesetzliche Namen, und wer sie trägt, läuft ständig dagegen: Das Formular besteht auf einem Familiennamen, also tippen die Betroffenen etwas ein, und nun widerspricht jedes Dokument, mit dem sie verglichen werden, dem Datensatz.
Dasselbe Muster erscheint in milderen Formen. Manche Menschen haben mehrere Vornamen und kein Feld für einen zweiten Vornamen, das zu ihnen passt. Manche haben einen Familiennamen aus zwei Wörtern, den ein an Leerzeichen getrennter Parser zerschneidet. Manche haben Namen aus einem einzigen Zeichen, was Mindestlängenprüfungen auslöst, die zur Beruhigung geschrieben wurden und nicht aus einem Grund.
Die Lösung ist strukturell und nicht kosmetisch: Markieren Sie das zweite Namensfeld als optional für die Länder, in denen es optional ist, oder besser, behandeln Sie den ganzen Namen als einen Wert mit optionalen Teilfeldern, die standardmäßig nie verlangt werden. Die Prüfung sollte zurückweisen, was unmöglich ist, nicht was bloß ungewohnt ist.
Was geschieht mit einem Namen in einem anderen Alphabet?
Zwei Dinge geschehen, und sie werden oft miteinander verwechselt. Das erste ist die Transliteration: das Übertragen eines in einem Schriftsystem geschriebenen Namens in ein anderes, was eine Abbildung mit echten Entscheidungen darin ist und mehr als eine anerkannte Konvention kennt. Das zweite ist die Normalisierung: die Entscheidung, ob zwei Zeichenfolgen, die identisch aussehen, tatsächlich identisch sind, was eine Frage der Speicherung und des Vergleichs ist.
Diakritische Zeichen zählen bei beidem. Ein Name mit Akzent ist eine andere Zeichenfolge als derselbe Name ohne ihn, und ob sie als gleich gelten sollen, hängt davon ab, was Sie tun. Der Abgleich zweier Datensätze sollte meist akzentunempfindlich sein; das Drucken eines Dokuments sollte Akzente nie entfernen. Auch die Sortierung — die Reihenfolge, in der Namen einsortiert werden — ist sprachabhängig, eine nach dem Standardsprachraum des Servers sortierte Liste steht also nicht in der Reihenfolge, die eine Leserin dieser Sprache erwartet.
Die Groß- und Kleinschreibung ist subtiler, als sie aussieht. Einen Namen in Großbuchstaben umzuwandeln kann seine Länge in einigen Sprachen ändern, und eine kleine Zahl von Buchstabenpaaren hat je nach Sprache verschiedene Großformen. Ein Namensfeld, das für die Anzeige in Großbuchstaben umwandelt und das Ergebnis speichert, hat Informationen zerstört, die es nicht rekonstruieren kann.
Warum Kodierungsprobleme immer wieder auftauchen
Zwei Zeichenfolgen können auf dem Bildschirm identisch dargestellt werden und trotzdem nicht gleich sein, weil ein Zeichen mit Akzent entweder als ein vorkomponiertes Zeichen oder als Grundzeichen plus kombinierendes Zeichen dargestellt werden kann. Beides ist gültig, beides sieht gleich aus, und der Vergleich Byte für Byte liefert falsch.
Dasselbe Problem erscheint, sobald Text zwischen Systemen wandert, die Verschiedenes unter einer Kennung verstehen. Die dauerhafte Lösung ist, an der Grenze zu normalisieren — beim Eintritt der Daten, beim Vergleich und beim Export —, und zwar in einer vereinbarten Form statt in der, die gerade angekommen ist.
Deshalb braucht eine Testsuite auch nicht lateinische und akzentuierte Namen. Eine Fixture, die ausschließlich aus schlichten lateinischen Namen besteht, besteht jede Kontrolle, während die Produktivdaten still drei davon brechen. Datensätze aus dem Identitätsdatensatz-Erzeuger werden je Land gezogen und tragen dessen Namenskonventionen, was sie für diese Art Abdeckung bequem macht; es sind synthetische Namen allein für Testzwecke, und sie gehören niemandem.
Wie sollten Namensfelder aufgeteilt werden?
Gehen Sie davon aus, wofür die Daten gebraucht werden, und arbeiten Sie rückwärts. Die meisten Systeme müssen einen Namen anzeigen, sortieren und suchen, und keine dieser Operationen verlangt, dass der Name beim Erfassen in genau zwei Teile zerlegt wird.
- Ein einziges Anzeigefeld hält den Namen so, wie er gelesen werden soll, in der Reihenfolge, die der Sprachraum des Datensatzes vorgibt.
- Getrennte Teilfelder sind optional und nie beide zugleich erforderlich; ein Formular, das auf einem Familiennamen besteht, ist nicht international.
- Eine Sprachraum- oder Schriftmarkierung am Datensatz lässt Formatierung und Sortierung später die richtige Wahl treffen.
- Längengrenzen sind großzügig, weil echte Namen länger sind als die Beispiele in jeder Spezifikation.
- Die Suche indiziert die normalisierte Form, während der gespeicherte Wert seine ursprünglichen Zeichen behält.
Diese Aufteilung kostet eine zusätzliche Spalte und entfernt eine ganze Klasse von Defekten. Sie verhindert außerdem, dass der Name still von der Schicht umformatiert wird, die ihn zufällig zuerst berührt.
Für Entwickler: Felder, Reihenfolge und Vergleich
Modellieren Sie den Namen als kleine Struktur mit einem klaren Eigentümer. Speichern Sie die Teile, die Sie erhalten haben, dazu die Reihenfolge, in die sie gehören, und leiten Sie die Anzeigezeichenfolge bei Bedarf ab. Speichern Sie nie das Ergebnis einer Umschreibung der Groß- und Kleinschreibung oder eines Akzententzugs; speichern Sie das Original und normalisieren Sie eine Kopie für den Vergleich.
Decken Sie in Fixtures die Formen ab, die Annahmen brechen, statt weitere gewöhnliche hinzuzufügen: ein Mononym, ein vorangestellter Familienname, eine mit Bindestrich verbundene Zusammensetzung, ein Name mit kombinierendem Akzentzeichen und ein Name aus einem einzigen Zeichen. Diese fünf fangen die meisten Defekte ab, die hundert gewöhnliche Namen nicht finden.
Prüfen Sie dann die zwei Operationen, die man vergisst. Die Sortierung sollte dem Sprachraum des Datensatzes folgen und nicht dem der Maschine, und das Abschneiden sollte gegen den längsten tatsächlich enthaltenen Namen geprüft werden, denn eine Aufteilung, in die jedes Beispiel der Spezifikation passt, ist kein Beleg dafür, dass sie in die Datenbank passt. Jeder Name in einer Test-Fixture ist für Softwaretests erfunden, und kein so erzeugter Datensatz identifiziert eine echte Person oder steht für sie.
Nächste Schritte
Machen Sie das Familiennamensfeld diese Woche in einem Formular optional und sehen Sie, ob etwas Nachgelagertes davon abhängt; ist die Antwort ja, ist die Abhängigkeit der Fehler. Erzeugen Sie dann im Identitätsdatensatz-Erzeuger eine Reihe von Namen über mehrere Sprachräume und lassen Sie sie durch Ihre Anzeige-, Sortier- und Suchpfade laufen, und prüfen Sie, ob sich die Sortierung mit dem Sprachraum des Datensatzes ändert statt mit dem des Servers. Der Artikel über Feldkonsistenz behandelt die anderen Paare, mit denen diese Namen übereinstimmen müssen.