Die Prüfung, die genau dort blind wird, wo Sie sie brauchen

Wir haben schon früher über Tests geschrieben, die nicht scheitern können — Zusicherungen, die durch bloße Arithmetik erfüllt sind, Fixtures, die genau jene Variation auslöschten, zu deren Erkennung sie existierten. Diese sind gleichmäßig tot. Sie sind grün bei korrektem Code und grün bei kaputtem Code, und sobald man einen davon bemerkt, weiß man genau, wie viel er wert war: nichts, und das durchgängig.

In diesem Artikel geht es um eine schlimmere Form. Eine Prüfung, die selektiv scheitert — die bei gewöhnlichen Defekten funktioniert und beim extremen verstummt. Sie meldet Grün, und dieses Grün ist nicht bedeutungslos; es ist aktiv irreführend, weil es mit der Schwere des Problems in die falsche Richtung korreliert.

Wir haben eine solche Prüfung dreimal hintereinander gebaut, während wir eine einzige Prüfung schrieben, und jede Version war auf andere Weise kaputt. Dann, zweimal an einem Tag, trafen wir auf denselben Fehlermodus an einem Ort ganz ohne Tests: eine Textsuche, die „nicht gefunden" für eine Zeichenkette zurückgab, die in der Datei stand.

Drei Versionen einer Prüfung, alle falsch

Wir wollten verifizieren, dass die Übersetzungen der Oberfläche vollständig waren. Die Karten des Generators tragen Werte, die selbst Daten sind — Sternzeichen, Augenfarben, Haartypen, Sportarten —, und diese Werte müssen je Sprache übersetzt werden. Es gibt 84 davon, und sie liegen in JSON-Dateien pro Sprache.

Die Prüfung ist set/ng_check_i18n.php. Sie durchlief drei Versionen, bevor sie irgendetwas Nützliches tat.

Version 1: Sie sah die Datei nie an

Die erste Version durchsuchte den PHP-Quellcode nach den dynamischen Schlüsseln mit einem regulären Ausdruck und las dazu phpadd/ng_extra.php.

Diese Datei existiert nicht. Der echte Pfad lautet phpadd/name_gen/ng_extra.php.

PHPs Dateifunktionen werfen bei einem fehlenden Pfad standardmäßig keine Ausnahme; sie geben eine Warnung aus und liefern false zurück. Der reguläre Ausdruck lief dann gegen keinen Inhalt, traf auf nichts, und die Prüfung schloss, es gebe null dynamische Schlüssel zu verifizieren. Null Schlüssel, null davon fehlend, 100 % vollständig. Grün.

Beachten Sie, was mit dem Fehler geschah. Er wurde nicht von einem try/catch oder einem @ verschluckt. Er wurde umgewandelt, still und durch ganz gewöhnliche Sprachsemantik, von „ich kann die Datei nicht finden" zu „die Datei enthält nichts von Interesse" — und diese beiden Zustände sind in der Ausgabe nicht unterscheidbar. Die Prüfung hätte für keine Eingabe scheitern können, weil sie gar keine Eingabe las.

Hier steckt noch eine zweite Lehre begraben, die wir erst später sahen. Der Pfad war nicht bloß falsch; der gesamte Ansatz war falsch. Die Schlüssel sind überhaupt keine Literale im Quellcode — sie werden innerhalb von Funktionskörpern gebaut, in ng_extra_sports(), in ng_extra_zodiac(), in Arrays, die zur Laufzeit zusammengesetzt werden. Kein regulärer Ausdruck über diese Datei hätte sie gefunden, selbst am korrekten Pfad. Den Pfad zu korrigieren hätte eine Prüfung ergeben, die immer noch nahezu blind war, jetzt aber aus einem subtileren Grund blind — und sie hätte repariert ausgesehen. Die schließliche Version leitet die Schlüsselliste stattdessen empirisch aus den JSON-Dateien ab.

Eine Prüfung, die Erfolg meldet, ohne ihre Eingabe zu lesen, ist keine schwache Prüfung. Sie ist ein erfundenes Ergebnis.

Version 2: Sie wurde genau beim maximalen Defekt blind

Die zweite Version hatte die richtige Schlüsselliste. Um Rauschen von Schlüsseln zu vermeiden, die berechtigterweise nur in einer Sprache vorkommen, verlangte sie, dass ein Schlüssel in mindestens zwei Sprachen vorhanden sei, bevor sie forderte, dass er in allen vorhanden sein müsse.

Die Seite hat drei aktive Sprachen: en als Referenz sowie uk und de. Die Lage auf der Festplatte war, dass uk alle 84 Wertübersetzungen hatte und de keine.

Für jeden einzelnen der 84 Schlüssel betrug die Zahl der Sprachen, die ihn enthielten, also eins. Die Schwelle von zwei wurde nie erreicht. Nicht ein einziger Schlüssel wurde geprüft. Grün.

Lesen Sie den Mechanismus noch einmal, denn seine Form ist der springende Punkt. Die Prüfung hätte einwandfrei funktioniert, wenn de etwa vierzig Schlüssel gefehlt hätten — dann wären sechzig in zwei Sprachen aufgetaucht, wären geprüft worden, und vierzig Fehlschläge wären gemeldet worden. Sie verstummte vollständig, weil das Loch total war. Die Bedingung schlug genau aus demselben Grund nicht an, der das Anschlagen dringlich machte.

Das ist die Eigenschaft, die selektive Blindheit schlimmer macht als gleichmäßige Totheit. Eine Prüfung, die nie funktioniert, lehrt einen nichts Falsches; man findet heraus, dass sie tot ist, sobald man sie zum ersten Mal testet. Eine Prüfung, deren Empfindlichkeit umgekehrt proportional zur Größe des Defekts ist, gibt ihr zuversichtlichstes Grün im schlimmsten Moment. Sie ist ein Rauchmelder, der sich oberhalb einer bestimmten Temperatur abschaltet.

Die Schwelle ist nun 1, mit einem Kommentar darüber, der festhält, warum:

Die Schwelle ist 1, nicht 2. Die erste Version verlangte „der Schlüssel existiert in mindestens zwei Sprachen" — und blieb genau im schlimmsten Fall stumm: nur uk hatte Wertübersetzungen, de keine. Die Bedingung „in zwei Sprachen" hielt nicht, weil das Loch vollständig war. Eine Prüfung, die beim maximalen Defekt blind wird, ist schlimmer als keine Prüfung: sie liefert falsche Beruhigung.

Version 3: Sie schlug bei der Referenz selbst falschen Alarm

Mit korrigierter Schwelle begann die Prüfung zu melden. Ihre erste Ausgabe war eine Warnung gegen en.

Die dynamischen Schlüssel sind Übersetzungen englischer Datenwerte — Sagittarius, Very curly, Ski Jumping. In der englischen Sprachregion ist der Wert die Übersetzung. Es gibt nichts zu tun. Aber die Prüfung wandte eine einheitliche Regel auf jede Sprache an, und en fiel durch, weil en keine Übersetzung des Englischen ins Englische enthielt.

Das ist der entgegengesetzte Fehlschlag, und er ist nicht harmlos. Eine Prüfung, die vor einem korrekten Zustand warnt, trainiert ihren Leser darauf, die Warnungen zu überspringen. Jede künftige echte Warnung muss nun mit einer bekannt-falschen um Aufmerksamkeit konkurrieren, und die falsche ist immer da. Der Endzustand ist eine Prüfung, die technisch läuft und funktional ignoriert wird — derselbe Wert wie Version 1, nur erreicht über den Leser statt über den Code.

Die Korrektur nimmt die Referenz-Sprachregion ausdrücklich aus, mit festgehaltener Begründung:

en ist von der Dynamik-Schlüssel-Prüfung absichtlich ausgenommen: dies sind Übersetzungen von Daten*werten* (Sagittarius, Very curly, Ski Jumping), und die Werte sind bereits Englisch — es gibt nichts zu übersetzen. Ohne diese Ausnahme warnte die Prüfung gegen ihre eigene Referenz, und Rauschen trainiert einen darauf, sie zu ignorieren.

Was die drei gemeinsam haben

Jede von ihnen lief bis zum Ende durch, druckte ein plausibles Ergebnis und beendete sich mit null. Keine von ihnen kündigte ein Problem mit sich selbst an. Die einzige Art, wie irgendeine der drei erwischt wurde, war, dass jemand unabhängig wusste, wie die Antwort lauten sollte, und bemerkte, dass die Prüfung widersprach — was genau das Wissen ist, dessen Notwendigkeit eine Prüfung beseitigen soll.

Der Defekt, den zu finden sie gebaut wurde, war übrigens real: de hatte 0 von 84 Wertübersetzungen, sodass ein deutscher Besucher Sagittarius, Hazel, Very curly und Ski Jumping in ansonsten deutschen Seiten sitzen sah. Diese Lücke ist inzwischen geschlossen; de trägt nun alle 84. Drei kaputte Versionen einer Prüfung standen zwischen einem realen, sichtbaren, den Nutzer betreffenden Defekt und irgendjemandem, der davon erfuhr.

Derselbe Fehlschlag ganz ohne Code: Diakritika

Zweimal an einem Tag meldete eine Suche nach einer Zeichenkette, dass die Zeichenkette in einer Datei fehle, die sie enthielt.

Vietnamesisch. Wir entfernten eine Zeile aus dem vietnamesischen Vornamen-Korpus. Thị ist kein Vorname — es ist der traditionelle weibliche Mittelnamen-Marker, und es war aufgenommen worden, als wäre es ein Name. Dem Entfernungsskript wurde die zu löschende Zeichenkette übergeben, entnommen aus einem Bericht statt aus der Datei.

Der Bericht hatte sie als Thi geschrieben. Die Datei enthielt Thị, wobei ị das Zeichen U+1ECB ist, latin small letter i with dot below. In Bytes:

Thi   ->  54 68 69
Thị   ->  54 68 E1 BB 8B

Drei Bytes gegen fünf. Kein Treffer, nichts gelöscht — und das Skript meldete Erfolg, denn aus seiner Sicht hatte es ein Suchen-und-Entfernen mit null Fehlern abgeschlossen. Die schlechte Zeile überlebte eine Korrektur, die ausdrücklich geschrieben wurde, um sie zu entfernen, und wurde als korrigiert verbucht.

Französisch. Die entgegengesetzte Richtung, derselbe Mechanismus. Wir prüften, ob der französische Nachnamen-Korpus die migrationsbedingte Schicht enthielt — die malischen, senegalesischen, portugiesischen und vietnamesischen Nachnamen, die jeder ehrliche französische Datensatz haben muss. Wir suchten nach TRAORE.

Nicht gefunden. Der gezogene Schluss war, dass eine ganze demografische Schicht im Korpus fehle, was ein schwerwiegender Datendefekt ist und einen erheblichen Neuaufbau gerechtfertigt hätte.

Der Korpus enthält Traoré, mit Gewicht 6.674. Daneben Da Silva mit 29.515, Dos Santos mit 17.661, Gonçalves mit 16.448 und Nguyen mit 11.922. Die Schicht war vollständig vorhanden. Gesucht wurde nach der akzentlosen Form, und é ist nicht e.

Es lohnt sich, die beiden Vorfälle nebeneinanderzustellen, weil sie entgegengesetzte Vorzeichen haben:

Die eine Suche verbarg einen Fehler. Die andere fabrizierte einen. Keine löste einen Fehler aus, keine gab eine leere Ergebnismenge auf eine Weise zurück, die falsch aussah, und beide produzierten die einzige plausibelste Ausgabe, die eine Suche produzieren kann: nichts gefunden.

Warum „nichts gefunden" das gefährlichste Ergebnis der Informatik ist

Eine Ausnahme ist ein gutes Ergebnis. Ein Absturz ist ein gutes Ergebnis. Beide sind eindeutig, beide halten einen an, beide nennen sich selbst.

„Nichts gefunden" ist keines davon. Es ist die korrekte Ausgabe für mindestens vier völlig verschiedene Situationen:

1. Die Zeichenkette ist tatsächlich nicht da.
2. Die Zeichenkette ist da, in einer anderen Normalisierung — Akzente, Groß-/Kleinschreibung, Unicode-Komposition, unsichtbare Bidi- oder Breitenzeichen.
3. Die Suche las die Eingabe nie: falscher Pfad, falsche Kodierung, leerer Puffer, Zugriff verweigert.
4. Die Eingabe wurde gelesen, ist aber unbrauchbar — ein PDF, das als Binärdaten extrahiert wurde, eine UTF-16-Datei, die als UTF-8 gelesen wurde, eine Datei mit einer Byte-Order-Mark, die am ersten Feld klebt.

Nur die erste ist Information. Die anderen drei sind Fehlschläge der Suche, und alle vier stellen sich identisch als leeres Ergebnis und Exit-Code null dar.

Wir trafen in derselben Woche auf Fall 4, in einer nicht verwandten Untersuchung. Als wir prüften, ob Südafrikas Regulierungsbehörde irgendwelche Telefonnummern für fiktive Zwecke reserviert, durchsuchten wir eine extrahierte Kopie des einschlägigen Government Gazette nach „reserved", „drama", „film" und „test". Alle vier gaben null zurück. Das wurde kurzzeitig als bestätigte Erkenntnis verbucht, dass Südafrika nichts reserviert.

Der Extrakt war verstümmelte Binärdaten. Er hätte auch für „the" null Treffer zurückgegeben. Wir hatten eine Schlussfolgerung auf eine Suche gebucht, die strukturell unfähig war, erfolgreich zu sein — der identische Fehler wie in Version 1 der Übersetzungsprüfung, in einem anderen Medium, fünf Tage später. Diese Geschichte, und die reservierten Bereiche, die sehr wohl bestätigbar waren, wird in Falsche Telefonnummern, die nicht existieren können erzählt.

Die Regel, die alles verhindert hätte

Es gibt eine Gewohnheit, die jeden der obigen Vorfälle adressiert, und sie ist fast beleidigend einfach:

Kopieren Sie die Zeichenkette, nach der Sie suchen, aus der Datei heraus. Niemals aus einem Bericht, einer Chat-Nachricht, einer Commit-Nachricht oder Ihrem Gedächtnis.

Jeder dieser Fehlschläge kam von einer Zeichenkette, die durch eine menschenlesbare Zwischenstufe gegangen war. Thi hatte sein Diakritikum irgendwo zwischen der Datei und dem Bericht verloren. TRAORE war aus dem Gedächtnis getippt worden, in der Form, die eine Suchmaschine akzeptieren würde. Beide sahen auf dem Bildschirm völlig korrekt aus. Diakritika sind die ideale Falle dafür, weil die verfälschte Form kein Müll ist — sie ist ein lesbares, plausibles, professionell aussehendes Wort, das zufällig eine andere Zeichenkette ist.

Drei Praktiken folgen daraus, in aufsteigender Reihenfolge dessen, wie sehr sie Sie nerven werden und wie viel sie wert sind:

Beweisen Sie, dass die Suche erfolgreich sein kann, bevor Sie glauben, sie sei gescheitert. Grep nach etwas, von dem Sie wissen, dass es in der Datei ist. Wenn grep . nichts zurückgibt, ist die Datei nicht das, wofür Sie sie halten. Das ist ein einziger Befehl, und er unterscheidet Fall 1 vollständig von den Fällen 3 und 4.

Verifizieren Sie nach einer Löschung mit einem Hex-Dump. Nicht „das Skript sagte OK" — das Skript sagte OK im vietnamesischen Vorfall. Drucken Sie die Bytes der verbleibenden Zeilen und sehen Sie sie an. Fünf Bytes, wo Sie drei erwarteten, ist im Hex sichtbar und im Terminal unsichtbar.

Suchen Sie normalisiert, wenn Sie normalisiert meinen. Wenn Sie wissen wollen, ob ein Name unabhängig von Akzenten vorhanden ist, streichen Sie die Akzente auf beiden Seiten vor dem Vergleich, absichtlich, als dokumentierten Schritt. Was bei TRAORE schiefging, war nicht, dass akzentunabhängige Suche schlecht ist — es war, dass die Suche versehentlich akzentabhängig war, während die ausführende Person glaubte, sie sei es nicht.

Prüfungen entwerfen, die an den Extremen laut scheitern

Für die Code-Seite liefert die Übersetzungsprüfung eine Reihe von Eigenschaften, die man von jeder Prüfung fordern sollte, bevor man ihrem Grün vertraut.

Testen Sie die Prüfung an beiden Grenzen, nicht in der Mitte. Ein partieller Defekt ist der einfache Fall; jede Version unserer Prüfung hätte de mit vierzig fehlenden Schlüsseln erwischt. Füttern Sie sie mit dem leeren Fall und dem totalen Fall. Version 2 überlebte ein Jahr plausibel aussehender Ausgabe und starb in dem Moment, als jemand fragte, was sie tut, wenn eine Sprache null Übersetzungen hat.

Machen Sie „keine Eingabe" zu einem Fehlschlag, nicht zu einem Bestehen. Wenn eine Prüfung eine Datei liest, nichts findet und Erfolg meldet, ist der Erfolg von einer Erfindung nicht zu unterscheiden. Stellen Sie sicher, dass die Eingabe nicht leer ist, als eigene, vorgelagerte Prüfung. count($keys) === 0 sollte ein rotes Ergebnis sein, kein 100-%-Wert.

Misstrauen Sie Schwellen, die von der Gesundheit der Daten abhängen. „In mindestens zwei Sprachen vorhanden", „mindestens zehn Zeilen", „wenn die Datei größer als N ist" — jede davon ist ein Schalter, den der Defekt selbst umlegen kann. Wenn ein Wächter existiert, um Rauschen zu reduzieren, fragen Sie ausdrücklich, was eine katastrophale Eingabe mit ihm macht. Unserer schaltete die Prüfung komplett aus.

Nehmen Sie bekannt-gute Fälle ausdrücklich aus und schreiben Sie auf, warum. Version 3s Warnung gegen en hatte mit den Daten nicht unrecht; sie hatte mit der Regel unrecht. Die Korrektur ist eine Ausnahme mit einem Kommentar, keine gelockerte Regel, denn eine gelockerte Regel hört auch auf, das Echte zu erwischen.

Behandeln Sie eine rauschende Prüfung als eine kaputte Prüfung. Eine Warnung, die immer da ist, ist eine Warnung, die nie gelesen wird. Es gibt nur zwei akzeptable Zustände für eine wiederkehrende Warnung: die Bedingung beheben oder sie ausdrücklich ausnehmen. Sie geistig herauszufiltern ist der dritte Zustand, und so wird aus einer laufenden Prüfung eine dekorative.

Bevorzugen Sie empirische Ableitung gegenüber Musterabgleich über dem Quellcode. Version 1 versuchte, eine Schlüsselliste per regulärem Ausdruck aus PHP wiederzugewinnen, das die Schlüssel zur Laufzeit konstruiert. Sie aus dem Artefakt zu lesen, in dem die Schlüssel tatsächlich landen, kann nicht auf dieselbe Weise still unter-melden; fehlt das Artefakt, bekommt man null Schlüssel und — gemäß der obigen Regel — das muss rot sein.

Zwei Arten toter Prüfung

Es lohnt sich, ausdrücklich zu machen, wie sich das vom Mutationstest-Artikel unterscheidet, denn die Abhilfen sind verschieden.

Der Mutationstest findet die erste Art zuverlässig, weil eine Mutation ein kleiner absichtlicher Defekt ist und ein gleichmäßig toter Test durch ihn hindurch grün bleibt. Er wird die zweite Art nicht zuverlässig finden — eine bescheidene Mutation ist genau die Eingabe, die eine selektiv blinde Prüfung korrekt behandelt. Unsere Version 2 hätte einen Mutationstest mit Bravour bestanden. Vierzig Übersetzungen zu löschen bringt sie zum Rotwerden, pünktlich, gesund aussehend.

Die zusätzliche Praxis ist also nicht mehr Mutationen, sondern extremere: nicht „entferne eine Übersetzung", sondern „entferne alle Übersetzungen aus einer Sprache, dann entferne die Sprache, dann leere die Datei, dann lösche die Datei". Eine Prüfung sollte lauter werden, je schlimmer die Eingabe wird, monoton. Wenn es irgendeine Eingabe gibt, die schlimm genug ist, um sie zu beruhigen, dann ist genau diese Eingabe diejenige, die eintreffen wird.

Die Checkliste

1. Kopieren Sie Suchzeichenketten aus der Datei, niemals aus einem Bericht, Chat oder Gedächtnis. Diakritika überstehen die Reise visuell, nicht byteweise.
2. Bevor Sie einem Negativergebnis glauben, beweisen Sie, dass die Suche etwas hätte finden können. Grep nach einer Zeichenkette, von der Sie wissen, dass sie vorhanden ist.
3. Verifizieren Sie nach einer Löschung im Hex. „Das Skript meldete Erfolg" ist, was das Skript sagte, als es nichts löschte.
4. Machen Sie eine leere Eingabe zu einem roten Ergebnis. Null gefundene Schlüssel dürfen niemals auf 100 % vollständig runden.
5. Füttern Sie jede Prüfung mit dem Totalausfall-Fall, nicht mit einem partiellen. Partielle Defekte sind die einfache Eingabe; im Extrem lebt die Blindheit.
6. Prüfen Sie jede Schwelle und jeden Wächter darauf, ob der Defekt sie ausschalten kann. „In mindestens zwei Sprachen" wurde dadurch außer Kraft gesetzt, dass die Lücke vollständig war.
7. Nehmen Sie den Referenzfall ausdrücklich aus, mit einer geschriebenen Begründung. Lockern Sie nicht die Regel, um eine Warnung über einen korrekten Zustand zum Schweigen zu bringen.
8. Behandeln Sie eine dauerhaft präsente Warnung als einen Defekt in der Prüfung. Rauschen im Normalfall ist der Weg, auf dem aus einer laufenden Prüfung eine ignorierte wird.
9. Unterscheiden Sie „bestätigt abwesend" von „nicht gefunden". Sie sind dieselbe Ausgabe und völlig verschiedene Aussagen.

Keine der drei Versionen jener Prüfung kündigte je ein Problem an. Ebenso wenig das Skript, das nichts löschte, noch die Suche, die eine fehlende Migrationsschicht erfand, noch der Grep gegen einen korrupten Gazette. Jede einzelne von ihnen war erfolgreich, druckte ein vernünftig aussehendes Ergebnis und beendete sich mit null.

Das ist die ganze Schwierigkeit. Kaputter Code kündigt sich selbst an; kaputte Verifikation tut es nicht, denn der Fehlermodus einer Verifikation besteht darin, Ihnen zuzustimmen.

Für die andere Hälfte dieses Themas — Zusicherungen, die durch Algebra erfüllt sind, und wie wir feststellten, welche unserer Tests scheitern konnten — siehe Ein Test, der nicht scheitern kann. Für den Telefonnummern-Audit, in dem dasselbe blinde Negativergebnis in einem Regulierungsdokument auftauchte, siehe Falsche Telefonnummern, die nicht existieren können. Für die Datendefekte, denen diese Suchen nachjagten, siehe Was wir falsch gemacht haben und Fallstricke in Namensdaten (Begleitartikel, noch nicht veröffentlicht).

Daten mit Stand 2026-07-18

Alle Zahlen wurden am 18. Juli 2026 gegen die Dateien auf der Festplatte verifiziert.

Quellen und Anmerkungen:

• Die Übersetzungsprüfung — set/ng_check_i18n.php, 125 Zeilen, ein eigenständiges Skript in set/. Alle drei kaputten Versionen sind als Warnkommentare an der genauen Stelle jeder Korrektur festgehalten: der Pfadfehler in den Zeilen 52–53, die Zwei-Sprachen-Schwelle in den Zeilen 70–76, die Ausnahme für die Referenz-Sprachregion in den Zeilen 100–107. Die früheren Versionen selbst überleben nicht — das Verzeichnis steht nicht unter Versionskontrolle, sodass die regex-scannende Implementierung nur durch den rückblickenden Kommentar bezeugt ist, der sie beschreibt.
• ⚠ Nicht in der Regressions-Suite. Diese Prüfung ist ein eigenständiges Skript und nicht Teil von ng_regression_tests.php, das überhaupt keinen i18n-Code enthält. Sie ist auch noch nicht in die Nach-Deploy-Prüfung eingebunden; das bleibt eine Empfehlung. Eine Prüfung, die man sich merken und von Hand ausführen muss, ist eine vierte Art, blind zu sein, und sie ist der aktuelle Zustand.
• Die Zahl 84 — auf zwei unabhängige Arten verifiziert. Durch Zusammensetzung von phpadd/name_gen/ng_extra.php: 56 Sportarten + 12 Sternzeichen + 6 Augenfarben + 5 Haartypen + 6 Haarfarben = 85, minus ein Duplikat (Brown erscheint sowohl als Augenfarbe als auch als Haarfarbe) = 84 eindeutige. Durch Schlüssel-Diff gegen das Live-JSON in phpadd/i18n/: en hat 86 Schlüssel mit 0 außerhalb der Referenzmenge, uk und de haben je 170, von denen 84 außerhalb liegen.
• ⚠ Eine widersprüchliche Zahl in der Quelle. Der Kommentar bei ng_check_i18n.php:72 besagt, dass uk 69 Wertübersetzungen hatte. Sowohl der Audit-Datensatz als auch die aktuellen Dateien geben 84. 69 wird von nichts bestätigt und ließ sich nicht rekonstruieren; 84 ist die gemessene Zahl und wird hier verwendet.
• „0 von 84" ist historisch. Die de-Lücke war zum Audit-Zeitpunkt real und ist als de: 0/84 gegen uk: 84/84 festgehalten. Sie ist inzwischen geschlossen — de misst nun 84 von 84 auf der Festplatte. Die drei beteiligten Sprachen sind en (Referenz), uk und de, die die vollständige aktive Menge für die dynamischen Wertschlüssel bilden.
• Der vietnamesische Vorfall — festgehalten in name_dev/NEVER-DO.md in den Zeilen 409–417. Die Zeichenkette wurde einem Bericht entnommen, wo sie als Thi erschien; die Datei enthielt Thị, mit ị bei U+1ECB. Byte-Folgen 54 68 69 gegen 54 68 E1 BB 8B — drei Bytes gegen fünf. Die Entfernung traf auf nichts und meldete Erfolg. Die Zeile ist nun weg; der Korpus behält nur Thịnh (Gewicht 18) und Đức Thịnh (Gewicht 5).
• Der französische Vorfall — festgehalten in NEVER-DO.md in den Zeilen 488–492 und dort als derselbe Mechanismus wie der vietnamesische Fall mit entgegengesetztem Vorzeichen gerahmt: der eine verbarg einen Defekt, der andere erfand einen. Traoré ist sowohl in names/fr_FR/lastname_male.tsv als auch in lastname_female.tsv in Zeile 1006 vorhanden, Gewicht 6.674, genau einmal pro Datei. Die umgebende migrationsbedingte Schicht, die die Suche erkennen sollte: Da Silva 29.515, Dos Santos 17.661, Gonçalves 16.448, Nguyen 11.922.
• Der südafrikanische Gazette — ein extrahiertes ICASA Government Gazette, das sich zu weitgehend verstümmelten Binärdaten auflöste und null Treffer für „reserved", „drama", „film" und „test" zurückgab. Hier als Instanz von Fall 4 festgehalten, nicht als Erkenntnis über die südafrikanische Nummerierung.