Ländernamen Abgleich und Aliase klingen nach einem Problem mit einer Nachschlagetabelle. In der Praxis ist die Tabelle der leichte Teil; schwierig ist die Entscheidung, mit welchem Namen alle anderen verglichen werden.
Ohne diese Entscheidung wird der Abgleich zu einer Reihe von Einzelurteilen. Eine Komponente hält zwei Schreibweisen für dieselbe, eine andere nicht, und der Unterschied zeigt sich als doppelter Datensatz oder als gescheiterte Verknüpfung. Der kanonische Name ist der Anker, der den Rest der Arbeit mechanisch macht.
Was bedeutet kanonisch hier?
Es bedeutet eine festgelegte Form für jedes Land, bewusst gewählt und überall dort verwendet, wo ein Name verglichen, sortiert oder als Schlüssel gespeichert wird.
Kanonisch heißt nicht richtig, und es heißt nicht von allen bevorzugt. Es heißt, dass eine einzige Form als Bezug festgelegt wurde, sodass jede andere Form eine definierte Beziehung zu ihr hat. Ein Land kann mehrere verbreitete Namen haben und trotzdem genau einen kanonischen Eintrag.
Die Wahl sollte mit ihrer Begründung dokumentiert werden. Ein Team kann die Form wählen, die in einer internationalen Norm verwendet wird, weil sie stabil ist, die im Hauptmarkt des Produkts vertrauteste Form, weil sie Supportanfragen verringert, oder die lokale Form, weil sie achtet, wie die dort lebenden Menschen ihr eigenes Land nennen. Jede davon ist vertretbar; eine undokumentierte Mischung aus allen dreien nicht.
Warum vor dem Vergleich normalisieren?
Weil zwei Zeichenketten, die für eine Leserin identisch aussehen, auf der Ebene der Bytes abweichen können, die ein Rechner vergleicht. Buchstaben mit Akzent haben mehr als eine gültige Kodierung, und Text, der auf dem Bildschirm gleich aussieht, kann einen Gleichheitstest gegen Rohzeichen nicht bestehen.
Beide Seiten vor dem Vergleich zu normalisieren, beseitigt diese ganze Klasse falscher Nichtübereinstimmungen. Es ist ein billiger Vorgang, er ist deterministisch, und er sollte an genau einer Stelle geschehen statt in jeder Komponente, die Namen vergleicht.
Drei weitere Schritte gehören daneben. Groß- und Kleinschreibung vereinheitlichen, damit allein die Schreibweise nie einen Unterschied erzeugt. Leerraum an den Rändern entfernen und inneren zusammenziehen, weil führende und nachgestellte Leerzeichen aus Importen und aus eingefügtem Text kommen. Und ausdrücklich entscheiden, was mit Satzzeichen geschieht, einschließlich der Zeichen, die Bestandteile eines Namens trennen, denn ihr Wegfall verändert, welche Zeichenketten übereinstimmen.
Was die Normalisierung nicht tun sollte, ist das Entfernen oder Umschreiben bedeutungstragender Zeichen. Ein Normalisierungslauf, der Akzente aus gespeicherten Daten entfernt, verändert die Daten; derselbe Lauf nur zum Zeitpunkt des Vergleichs nicht.
Wann helfen Aliase und wann führen sie in die Irre?
Ein Alias verdient seinen Platz, wenn eine echte alternative Form existiert und ohne ihn nicht übereinstimmen würde. Ein früherer offizieller Name, ein lokal verwendeter Name, eine gängige Abkürzung und eine Übersetzung in eine weit verbreitete Sprache sind alles legitime Einträge.
Das Risiko ist, dass Aliase sich vermehren. Jeder aus Bequemlichkeit hinzugefügte Alias ist die Behauptung, dass zwei Zeichenketten dasselbe Land bezeichnen, und eine falsche Behauptung ist schlimmer als eine fehlende, weil sie zwei Datensätze stillschweigend zu einem zusammenführt, der über beide falsch ist.
Zwei Leitplanken halten die Tabelle ehrlich. Erstens sollte jeder Alias einen genannten Grund und eine Quelle haben, damit die Behauptung überprüfbar bleibt und nicht für immer vererbt wird. Zweitens sollten Aliase nicht durch eine Regel erzeugt werden, die plausibel klingt, aber nicht zutrifft – eine mechanische Umformung auf den Namen eines Landes erzeugt Zeichenketten, die Namen anderer Länder ähneln.
Halten Sie die Alias-Tabelle klein und prüfbar. Eine Tabelle mit wenigen hundert Einträgen, die ein Mensch lesen kann, ist mehr wert als eine große erzeugte, die niemand kontrollieren kann.
Was geht schief, wenn unscharfes Vergleichen das erste Mittel ist?
Unscharfes Vergleichen ist attraktiv, weil es das Problem scheinbar ohne Datenarbeit löst. Es erzeugt zugleich selbstsichere, stille Fehler, und die sind am schwersten zu finden.
Zwei Mechanismen verursachen den größten Schaden. Namen verschiedener Länder, die sich nur um einen kleinen Bearbeitungsabstand unterscheiden, gleichen einander an. Und eine falsche Schreibweise, die zufällig näher an einem falschen Land liegt als am richtigen, wird in die falsche Richtung korrigiert.
| Strategie | Was sie behebt | Was sie kostet |
|---|---|---|
| Genaue Übereinstimmung mit einer kanonischen Form | Nichts über die Form selbst hinaus | Verpasst jede Variante |
| Normalisieren und dann vergleichen | Unterschiede in Kodierung, Schreibung und Abständen | Verpasst echte Varianten |
| Kanonische Form plus gepflegte Aliase | Bekannte Namensvarianten und Übersetzungen | Erfordert Pflege |
| Unscharfes Vergleichen überall | Unbekannte Falschschreibungen | Stille Zusammenführungen verschiedener Länder |
Die praktische Reihenfolge ist die der Tabelle von oben nach unten, wobei unscharfes Vergleichen zuletzt auf den Rest angewandt wird und nur dort, wo eine falsche Antwort billig rückgängig zu machen ist. Ein unscharfer Treffer, der einen Vorschlag zur Bestätigung durch einen Menschen liefert, ist eine andere Funktion als ein unscharfer Treffer, der einen Wert schreibt.
Sollten Namen überhaupt gespeichert werden?
Speichern Sie den Code und behandeln Sie den Namen als etwas, das für eine Leserin gerendert wird, statt als Identität eines Datensatzes.
Namen ändern sich; Codes werden genau deshalb gepflegt, damit die Identität die Änderung übersteht. Ein Datensatz, dessen Identität ein Name ist, wird in dem Moment mehrdeutig, in dem dieser Name überarbeitet oder übersetzt wird, und die Mehrdeutigkeit bleibt unsichtbar, bis zwei Datensätze, die einer sein sollten, nebeneinander erscheinen.
Ein Anzeigename muss trotzdem gespeichert oder erzeugt werden, und er sollte als das bezeichnet werden, was er ist. Ein Feld namens name, das zugleich als Beschriftung und als Verknüpfungsschlüssel dient, wird irgendwann als das falsche von beiden verwendet.
Für Entwickler: den Vergleich hinter eine einzige Funktion legen
Zentralisieren Sie den Vergleich, statt ihn zu wiederholen. Eine einzige Stelle, die normalisiert, die Alias-Tabelle anwendet und das Ergebnis festlegt, bedeutet, dass die Regeln einmal geprüft und einmal geändert werden können und dass jeder Aufrufer dasselbe Verhalten erbt.
Wo das Ergebnis unsicher ist, geben Sie lieber einen gereihten Vorschlag zurück als eine Entscheidung. Das Länder- und Regionenverzeichnis zeigt Namen neben ihren Codes – genau die Paarung, die einen falschen Treffer sichtbar statt plausibel macht –, und für den sprachlichen Hintergrund, wie sich Namen je Sprache verhalten, deckt der Leitfaden zu den Namensdaten je Locale die Sprachseite ab, die dieser Beitrag bewusst auslässt. Das Verhalten des Bedienelements, das diese Treffer verbraucht, behandelt der Leitfaden zum Testen von Länder-Auswahlfeldern.
Die Alias-Einträge und Schreibvarianten in den Beispielen oben sind zur Veranschaulichung erfunden. Sie sind keine reale Alias-Tabelle, sie geben keine veröffentlichte Namenskonvention wieder, und kein Beispiel in diesem Beitrag sollte als offizieller oder bevorzugter Name eines Landes behandelt werden.
Nächste Schritte
Schreiben Sie Ihre kanonische Form für ein Land auf und die Begründung, warum sie gewählt wurde, und zählen Sie dann, an wie vielen Stellen Ihr System Namen vergleicht, ohne einen gemeinsamen Schritt zu durchlaufen. Der Leitfaden zu Land und Sprache in Testdaten erklärt, warum ein übersetzter Name eine Angelegenheit der Sprachschicht ist und keine Änderung der Identität.