ucfirst(strtolower($name)) zerstört Namen, und man kann es messen

Jede Namens-Pipeline trifft früher oder später auf eine Quelle, die schreit. Staatliche Register speichern Namen in Großbuchstaben — MCKENZIE, O'BRIEN, NGUYEN VAN NAM —, weil die Systeme, aus denen sie hervorgingen, keine Kleinbuchstaben kannten. Irgendwo zwischen dieser Datei und Ihrer Benutzeroberfläche muss jemand entscheiden, wohin die Großbuchstaben gehören.

Der Einzeiler, zu dem alle greifen, lautet:

$name = ucfirst(strtolower($name));       // PHP
name = name.title()                       // Python — same class of bug, different shape
name[0].toUpperCase() + name.slice(1).toLowerCase()   // JS

Er erzeugt Mckenzie, O'brien, Van Der Berg und Tôn-nữ. Alle vier sind falsch. Nicht „ungewöhnlich" — falsch, in dem Sinne, dass kein Register, kein Stilhandbuch und kein Träger sie so schreibt.

Wir wissen das, weil wir zwei davon ausgeliefert haben. Auf dieser Seite geht es darum, wie man das Artefakt in Daten aufspürt, die man bereits besitzt, warum die naheliegende Korrektur ebenfalls falsch ist und wo die ehrliche Grenze der ganzen Übung liegt.

Die Signatur: eine Grenze, die null Mal auslöst

Das verräterische Zeichen ist nicht, dass ein Name seltsam aussieht. Namen sehen seltsam aus. Das verräterische Zeichen ist ein Grenzzeichen, das in einer ganzen Datei kein einziges Mal einen Großbuchstaben erzeugt.

Hier ist unser französischer Vorname-Korpus, gebaut aus dem nationalen Geburtsnamenregister. Wir haben jeden Bindestrich und jeden Apostroph innerhalb eines Namens gezählt und gefragt, welche Art von Buchstabe darauf folgt:

2.884 Bindestriche, jeder einzelne von einem Großbuchstaben gefolgt: Jean-Pierre, Marie-Claire, Anne-Sophie. 54 Apostrophe, keiner von einem Großbuchstaben gefolgt.

Das ist keine sprachliche Tatsache über das Französische. Das ist eine Maschinensignatur. Was auch immer die Groß- und Kleinschreibung dieser Datei neu setzte, behandelte - als Wortgrenze und ' als gewöhnlichen Buchstaben. Ein menschlicher Erfasser produziert eine Mischung; eine Regel produziert eine Spalte von Nullen.

Was die Apostroph-Einträge tatsächlich enthalten:

M'hamed  M'barek  M'baye  N'guessan  N'diaye  N'deye  N'faly  R'kia      ← correct as-is
O'bryan  O'neal   O'brian  O'neil   O'neill   Jo'anna  Carol'ann  Lou'ann ← wrong

Und genau deshalb überlebt der Defekt die Durchsicht. Die Mehrheit dieser Namen — arabisch M'hamed, westafrikanisch N'diaye, N'guessan — ist nach dem Apostroph korrekt kleingeschrieben. Die kaputten verstecken sich unter ihnen. Wer die Datei nur überfliegt, sieht eine plausible Mischung aus maghrebinischen und sahelischen Namen und liest weiter.

Dem gegenüber steht eine Datei, deren Groß- und Kleinschreibung nicht maschinell neu gesetzt wurde. Über alle 64 Sprachregionen hinweg, die wir ausliefern, folgt einem Apostroph Folgendes:

en_NZ ist die interessante Zeile und diejenige, die das Argument für eine maschinelle Regel beendet. Sie enthält beide Konventionen, beide korrekt: Das irische O'Brien schreibt nach dem Apostroph groß, das samoanische Su'a, Fa'alogo, Fepulea'i, Papali'i nicht, weil der Apostroph dort ein glottaler Verschlusslaut (das ʻokina) ist, keine Wortgrenze. Eine Datei, ein Land, zwei entgegengesetzte Regeln, keine Möglichkeit, es der Zeichenkette anzusehen.

Die zwei, die wir falsch hatten

en_IE: Mckeever → McKeever. Unkompliziert, gefunden und behoben.

vi_VN: Tôn-nữ → Tôn Nữ und Tôn-thất → Tôn Thất. Behoben am 21. Juli 2026, und erklärungswürdig, weil das Argument, dass es sich um einen Fehler handelt — und nicht um eine legitime Schreibvariante —, strukturell und nicht ästhetisch ist.

Vietnamesische zusammengesetzte Nachnamen hatten genau zwei geschriebene Normen:

Die zweite Silbe eines vietnamesischen Eigennamens wird in beiden großgeschrieben. Es gab nie eine Norm, in der sie kleingeschrieben wird. Tôn-nữ ist daher kein Archaismus, keine regionale Variante und keine Quellschreibweise — es ist genau das, was ucfirst(strtolower("TÔN-NỮ")) ausgibt. Zwei bekannte Normen, und die Zeichenkette passt zu keiner: Das ist ein stärkeres Argument als „es sieht für mich falsch aus".

Wir haben die Leerzeichenform gegenüber Tôn-Nữ gewählt, weil der Rest des vietnamesischen Korpus bereits Leerzeichen für mehrsilbige Einheiten verwendet — 49 durch Leerzeichen getrennte Vornamen in der Männerdatei, 79 in der Frauendatei, und null Bindestriche irgendwo in vietnamesischen Namen. Aktueller Stand: Tôn Nữ (Rang 122, Gewicht 17) und Tôn Thất (Rang 147, Gewicht 12) von 298 Nachnamen, keine Bindestriche mehr übrig.

Wir haben dann alle 64 Sprachregionen nach demselben Muster durchsucht — Bindestrich gefolgt von einem Kleinbuchstaben — und drei Überlebende gefunden:

Drei Treffer, und die automatische Regel hätte alle drei zu Fehlern „korrigiert".

Der größere, den wir nicht behoben haben: 158 Vornamen

Nachnamen in unseren englischen Sprachregionen sind sauber. Vornamen nicht, und die Zahlen sagen genau, wo die Grenze der Bereinigung verlief:

Null auf ganzer Linie — in den Nachnamen-Dateien. In den en_US-Vornamen-Dateien gibt es 158 Einträge, die mit Mc + Kleinbuchstabe beginnen, die 148.225 von 282.696.333 Gewicht (0,052 %) tragen: Mckenzie (55.094), Mckenna (36.825), Mckayla (11.415), Mckinley (9.468).

Der Beweis, dass es sich um ein Pipeline-Artefakt handelt und nicht um zwei verschiedene Namenskonventionen, ist, dass dieselben Zeichenketten in beiden Dateien auftauchen, mit unterschiedlicher Groß- und Kleinschreibung, im selben Korpus:

Zwanzig solcher Kollisionen. Dieselbe Quellpopulation, dieselbe Organisation, zwei unterschiedliche Schreibungsentscheidungen — weil die eine Datei durch eine kuratierte Ausnahmeliste lief und die andere durch ucfirst.

Die Quelle ist in Großbuchstaben, und sie hat bereits Dinge weggeworfen

Wissenswert, bevor Sie Ihr Werkzeug zur Neusetzung der Groß- und Kleinschreibung schreiben: Das Register, dessen Schreibung Sie neu setzen, hat möglicherweise mehr zerstört als nur die Groß- und Kleinschreibung.

Beide Namensprodukte des US Census 2020 speichern Namen in Großbuchstaben, und wir haben gezählt, was in ihnen steckt:

Das Census Bureau schreibt Namen nicht nur groß; es entfernt den Apostroph vollständig. O'Brien wird als OBRIEN veröffentlicht. Das O'Brien mit Gewicht 115.547 in unserem Korpus sind also keine Quelldaten — es ist eine Rekonstruktion, erstellt von jemandem, der wusste, dass OBRIEN O'Brien ist und nicht Obrien. Diese Rekonstruktion ist Wissen, keine Transformation, und keine Funktionssignatur kann sie kodieren.

Das hat dieselbe Form wie das Entfernen von Akzenten in spanischen Registern: Das Register normalisiert für seine eigene Vergleichbarkeit, und die Normalisierung ist ohne externes Wissen unumkehrbar.

Warum ucfirst und ucwords nicht reparierbar sind

Die Versuchung, nachdem man all das gesehen hat, ist, eine bessere Funktion zu schreiben: an -, ', auftrennen, jedes Stück großschreiben. Das erzeugt M'Hamed, N'Diaye, Su'A, Papali'I, Van Der Berg, De La Cruz, Al-Ahmad. Sie haben einen einheitlichen Fehler gegen einen anderen getauscht.

Es gibt vier verschiedene Probleme, die übereinander gestapelt sind, und nur das erste betrifft Wortgrenzen.

1. Die Grenzmenge ist nicht [ -]. Mindestens brauchen Sie -, ', ’ (U+2019, das echte Daten neben U+0027 enthalten), Leerzeichen und . in Initialen. ucfirst behandelt keines davon. ucwords behandelt das Leerzeichen und nimmt in PHP genau deshalb eine explizite Trennzeichenliste, weil es keinen korrekten Standardwert gibt.

2. Nicht jedes Grenzzeichen ist eine Grenze. Durch die obigen Daten belegt: Der Apostroph ist eine Grenze in O'Brien und ein Konsonant in Su'a; der Bindestrich ist eine Grenze in Jean-Pierre und intern in Karo-karo. Dasselbe Zeichen bedeutet in derselben Datei zwei Dinge.

3. Manche Elemente müssen kleingeschrieben bleiben, und welche, ist sprachabhängig. Niederländisch van, de, van der, ten werden nach einem Vornamen kleingeschrieben und ohne einen großgeschrieben — eine Positionsregel, keine feste Schreibweise. Belgisches Niederländisch friert ein, was auch immer das Personenstandsregister erfasst hat, sodass De Smet überall De Smet ist. Arabisch bin, bint, al-; portugiesisch dos, da; französisch de, du; deutsch von, zu — jedes hat seine eigene Konvention, und die niederländische auf einen belgischen Namen oder die deutsche auf einen portugiesischen anzuwenden, erzeugt einen echten Fehler in beide Richtungen.

4. strtolower selbst ist für einige Schriften falsch. strtolower in PHP ist bytebasiert und verstümmelt UTF-8 (mb_strtolower ist das Minimum). Das Türkische hat ein i mit und ohne Punkt: İSTANBUL wird nur unter einer türkischen Sprachregion zu istanbul kleingeschrieben, sonst zu i̇stanbul. Das griechische Schluss-Sigma ändert seine Form je nach Position. Und im Georgischen — das wir ausliefern — hat Mkhedruli überhaupt keine Groß- und Kleinschreibung; ein naiver Scan nach „Namen mit kleinem Anfangsbuchstaben" markiert alle 1.036 georgischen Einträge als verdächtig, und jeder einzelne davon ist in Ordnung.

Die Ausnahmeliste ist zwingend, und sie ist sprachabhängig

Sie können eine Liste nicht vermeiden. Mc, Mac, O', Fitz, van, de, von, bin, al-, Ó, Ní, Le, D'. Gut — nur partitioniert die Liste die Daten ebenfalls nicht sauber, und unser Korpus enthält die Gegenbeispiele:

Die Liste muss also eine Liste von Namen sein, nicht von Präfixen. Was bedeutet, dass sie aus einer Quelle gebaut werden muss, die echte Schreibweisen erfasst — genau das, was Sie zu Beginn nicht hatten.

Und dann ist da noch Macdonald

Der wirklich unlösbare Fall, und wir sagen es lieber klar heraus, als Sie in dem Glauben zu lassen, es gebe eine ausreichend gute Liste.

Macdonald und MacDonald sind beide echte Nachnamen, getragen von verschiedenen Familien, und sie sind ebenso wenig Varianten voneinander wie Smith und Smyth. In unserem britischen Korpus trägt die Form mit kleinem Binnenbuchstaben 21.737 Träger; in unserem amerikanischen Korpus trägt die Form mit großem Binnenbuchstaben 45.126. Keine ist ein Tippfehler der anderen. Es gibt keine Regel — keine Sprachregion-Regel, keine Häufigkeitsregel, keine Schottisch-gegen-Irisch-Regel —, die entscheidet, welche von beiden eine bestimmte Person ist.

Dasselbe gilt für Mackenzie / MacKenzie / McKenzie und für Vandenberghe gegen Van den Berghe in belgischen Daten, wo die zusammengeschriebene und die getrennte Form eigenständige rechtliche Nachnamen sind, die zu verschiedenen Familien gehören.

Jede Normalisierung, die diese aufeinander abbildet, zerstört echte Menschen. Das ist die Obergrenze dieses ganzen Problems: nicht „schwer zu automatisieren", sondern es existiert keine korrekte Antwort als Funktion der Zeichenkette.

Was tatsächlich funktioniert

1. Setzen Sie die Groß- und Kleinschreibung gar nicht neu, wenn Sie es vermeiden können. Wenn die Quelle gemischte Schreibung liefert, behalten Sie sie Byte für Byte bei. Jede Transformation ist eine Gelegenheit, etwas zu verlieren, und keine Transformation fügt Information hinzu.

2. Wenn Sie bei einer Großbuchstaben-Quelle die Groß- und Kleinschreibung neu setzen müssen, behandeln Sie es als Rekonstruktion, nicht als Formatierung. Rekonstruktion braucht Belege: eine zweite Quelle in gemischter Schreibung, eine kuratierte Liste oder einen Menschen. Kalkulieren Sie das entsprechend ein und halten Sie fest, welche Zeilen rekonstruiert wurden.

3. Prüfen Sie mit dem Grenztest, nicht durch Lesen. Zählen Sie für jedes Grenzzeichen, wie oft ihm ein Großbuchstabe und wie oft ein Kleinbuchstabe folgt, pro Datei. Eine Spalte reiner Nullen in eine der beiden Richtungen ist eine Maschine, keine Sprache. Dieser Test fand alle drei unserer Defekte und kostete ein Dutzend Zeilen Code.

4. Setzen Sie die Groß- und Kleinschreibung niemals bei der Ausgabe neu. Wenn Ihr Template beim Rendern eines Namens einen Großschreibungs-Helfer aufruft, haben Sie den Fehler an die Stelle verschoben, an der er am wenigsten sichtbar und am schwersten zu testen ist. Normalisieren Sie einmal, beim Einlesen, bewusst, und speichern Sie das Ergebnis.

5. Validieren Sie auf Darstellbarkeit, nicht auf Form. ^[A-Z] als Namensvalidierungsregel weist dela Cruz zurück — den häufigsten Nachnamen auf den Philippinen — und da Silva, die beide als korrekt kleinbuchstabige Einträge in unserem Korpus stehen, und sie weist jeden georgischen Namen zurück, der je geschrieben wurde.

6. Trennen Sie die Anzeige-Schreibung von der gespeicherten Schreibung. Ein Nachname, der für sich allein dargestellt wird — in einem sortierten Index, einer Tabellenspalte, einer Anrede —, kann legitimerweise eine andere Groß- und Kleinschreibung benötigen als derselbe Nachname nach einem Vornamen. Das ist eine Rendering-Funktion mit einem Sprachregion-Argument, keine Eigenschaft der gespeicherten Zeichenkette.

Bekannte Einschränkungen

• Wir haben die 158 Mc*-Vornamen in en_US nicht behoben. Sie machen 0,052 % des Vornamengewichts aus, und sie zu korrigieren bedeutet, Name für Name zu entscheiden, ob Mckenzie als Vorname ein falsch geschriebenes McKenzie ist oder eine eigenständige moderne Schreibweise, die Eltern tatsächlich eintragen — und bei Vornamen ist, anders als bei Nachnamen, die zweite Lesart wirklich plausibel.
• Jo-anne in en_NZ ist ungeklärt. Sowohl Jo-anne als auch Jo-Anne sind belegt. Wir haben die Quellschreibweise belassen.
• Die fr_FR-Apostroph-Einträge sind unbehoben. Wir können O'bryan, O'neal und O'brian mit Zuversicht als Artefakte identifizieren; wir können sie nicht maschinell von den rund 40 korrekt kleingeschriebenen maghrebinischen und westafrikanischen Namen in derselben Datei trennen, und eine Entscheidung pro Name wurde nicht getroffen.
• Wir haben unseren eigenen Korpus gemessen, nicht die Welt. Die -/'-Zählungen, die Präfix-Inventare und die Vorname/Nachname-Kollisionen sind allesamt Messungen der Dateien, die wir ausliefern, vorgenommen am 21. Juli 2026. Sie sind Belege dafür, wie sich diese Fehlerklasse verhält, keine Vollerhebung davon.

Daten mit Stand 2026-07-21

64 Sprachregionen gescannt. vi_VN-Nachnamen: 298 Einträge, 99.441 Gesamtgewicht, 0 Bindestriche, Tôn Nữ und Tôn Thất in der korrigierten Form; Männer- und Frauendateien byteidentisch. en_US: 2.064 Nachnamen und 53.618 Quell-Vornamen-Zeilen. US-Census-2020-Dateien direkt gezählt. Alle Zahlen für diese Seite neu berechnet, nicht aus früheren Notizen zitiert.

Quellen

• US Census Bureau — Frequently Occurring Surnames from the 2010/2020 Census
• PHP manual — ucwords(), on why the delimiter list is explicit
• Unicode Standard Annex #21: Case Mappings
• W3C — Personal names around the world