Réponse.

La première vague d'automatisation des tests ne concernait pratiquement pas la vérification de la localisation (i18n), car les principaux marchés étaient axés sur une interface en anglais. Cependant, avec la mondialisation des applications, les exigences de qualité de la localisation ont augmenté : l'interface doit s'afficher correctement dans toutes les langues prises en charge, et les ressources textuelles et les chaînes formatées doivent être chargées correctement en fonction de la locale choisie.

Le principal problème est que la vérification manuelle est très coûteuse, et les tests automatiques sont complexes en raison de la variabilité des formats, du contexte, des spécificités des langues (par exemple, de droite à gauche ou des caractéristiques grammaticales). Il peut y avoir une absence de traduction d'un fragment, des erreurs de formatage, des violations de mise en page.

Les solutions incluent le travail avec des données de test pour chaque locale, l'utilisation de tests de snapshot, la comparaison des éléments de l'interface utilisateur avec des références, l'implémentation d'utilitaires de vérification sur le principe "clé-valeur" pour les fichiers de ressources, l'extraction et la comparaison automatisées de chaînes via des API et l'exécution régulière de linters sur les fichiers de ressources.

Caractéristiques clés :

Vérification de la présence et de l'affichage correct de toutes les langues prises en charge.
Comparaison des traductions de référence avec l'affichage actuel dans l'interface.
Validateurs de longueur et de format des textes pour éviter les violations de mise en page.

Questions pièges.

Peut-on créer un test universel qui valide n'importe quelle locale avec un seul script ?

En partie oui, mais les nuances des langues (cas, genre, direction de saisie) nécessitent souvent des ajustements manuels ou des conditions supplémentaires dans de tels tests. Une universalité à 100 % est impossible.

Si le fichier de traduction est présent et a été chargé avec succès, cela signifie-t-il que le test i18n est réussi ?

Non. Le fichier peut être incorrectement lié du côté de l'application, l'erreur peut se trouver dans la clé, le contexte d'utilisation de la traduction peut être violé, il peut y avoir des caractères spéciaux non pris en compte, etc.

A-t-il un sens d'automatiser la vérification de la localisation pour les langues avec < 1 % d'utilisateurs ?

Oui, si la criticité commerciale même d'un seul utilisateur est élevée, par exemple, lors de l'exécution d'obligations contractuelles ou pour des marchés avec des exigences particulières. L'automatisation permet d'économiser considérablement des ressources par rapport aux vérifications manuelles.

Erreurs typiques et anti-patterns

Vérifier uniquement la présence du fichier, et non l'affichage réel dans l'UI.
Comparaison stricte des chaînes sans tenir compte des particularités grammaticales et de formatage de la langue.
Copie aveugle du test d'une locale à d'autres sans adaptation.

Exemple de la vie

Cas négatif

L'équipe a mis en œuvre des tests automatisés pour comparer les clés dans le fichier .po avec le texte anglais original, pensant que cela suffisait. Ils n'avaient pas écrit de tests UI - dans la version arabe, il s'est avéré que tout le texte était décalé au-delà des boutons, et certaines chaînes n'étaient pas traduites du tout en raison de clés incorrectes.

Avantages :

Mise en œuvre rapide de l'automatisation i18n.

Inconvénients :

Niveau de couverture faible des scénarios utilisateur réels.
Des erreurs UX significatives sont restées non détectées.

Cas positif

Un lien entre le linting des ressources et les tests automatisés a été réalisé, qui parcouraient l'interface dans toutes les langues, prenaient des captures d'écran et les comparaillaient avec le modèle de référence. En découvrant le mélange des éléments RTL/LTR, l'équipe a identifié la cause racine et l'a corrigée avant la sortie.