Pays ou langue est l’une de ces distinctions que tout le monde approuve dans l’abstrait et viole dès la première fixture. Une matrice de test est écrite avec une ligne par langue, un pays est rattaché à chaque ligne pour rendre les données réalistes, et les deux axes deviennent discrètement un seul.
Cet article les sépare. Il décrit les trois couches que le mot localisation cache habituellement, pourquoi une étiquette de langue et un code de région remplissent des rôles différents, et comment échantillonner deux axes sans prétendre qu’ils n’en forment qu’un.
Pourquoi le pays et la langue ne peuvent-ils pas être déduits l’un de l’autre ?
Une langue peut être langue officielle dans de nombreux pays, et un pays peut avoir plusieurs langues officielles. La relation est plurielle dans les deux sens, donc aucune valeur ne détermine l’autre.
La conséquence pour les tests est immédiate. Si chaque langue est appariée avec exactement un pays, la matrice a une forme diagonale : elle contient les paires que quelqu’un a trouvées naturelles et aucune des autres. Les défaillances intéressantes vivent hors de cette diagonale — la même langue produisant un format différent, et le même format apparaissant sous une autre langue.
Une seconde conséquence est plus subtile. Comme les paires diagonales tendent à être culturellement familières à celui qui a écrit la matrice, ce sont aussi les paires où les hypothèses de l’équipe sont les plus susceptibles d’être correctes. La matrice est la plus solide exactement là où elle est le moins nécessaire.
La localisation, ce sont en réalité trois couches
Traitez la localisation comme trois décisions qui se trouvent partager un mot.
| Couche | La question à laquelle elle répond | Responsable typique |
|---|---|---|
| Langue de l’interface | Dans quelle langue sont les libellés, les boutons et les messages ? | Contenu ou produit |
| Région de contenu | Les règles, les prix et les offres de quel marché s’appliquent ? | Métier |
| Format des données | Quelles conventions régissent les dates, les nombres, les noms et les adresses ? | Données ou ingénierie |
Chaque couche peut être définie indépendamment, et dans les systèmes réels elles le sont fréquemment. Un lecteur peut naviguer dans une langue, se voir servir les règles d’un marché où il voyage, et saisir une adresse qui suit les conventions d’un troisième endroit.
Une fois les trois couches séparées, la plupart des défauts de localisation deviennent descriptibles. Un défaut est un cas où deux couches étaient supposées évoluer ensemble et ne l’ont pas fait.
L’étiquette de langue et le code de région ont des rôles différents
Une étiquette de langue décrit du texte. Elle indique dans quelle langue une chaîne est écrite et, parfois, quelle écriture ou variante. Un code de région décrit les conventions que suit une valeur : comment une date est ordonnée, comment un nombre est ponctué, comment un nom est agencé.
Ils ne sont pas interchangeables, et l’un n’est pas une version plus précise de l’autre. Un système qui ne stocke qu’une étiquette de langue a jeté l’information nécessaire pour interpréter une date, et un système qui ne stocke qu’un code de région a jeté l’information nécessaire pour choisir un catalogue de messages.
Garder les deux n’est pas de la redondance ; c’est le minimum requis pour décrire une page rendue. Le bogue à surveiller est le raccourci dans l’autre sens — utiliser l’étiquette de langue comme commutateur de formatage des données, ce qui fonctionne jusqu’au premier pays qui partage une langue avec un autre.
Qu’est-ce qui casse lorsqu’un format suit la langue ?
La défaillance classique est une valeur validée contre les conventions du mauvais pays parce que les deux partagent une langue. La langue de l’utilisateur est correctement définie, la règle de format est choisie à partir de cette langue, et la valeur est rejetée alors qu’elle est bien formée pour le pays où l’utilisateur vit réellement.
Il existe des versions plus discrètes. Un champ de nom qui réordonne les parties parce que l’interface est dans une certaine langue plutôt que parce que l’enregistrement appartient à une région ayant cet ordre. Un champ numérique qui accepte un séparateur décimal issu de la mauvaise convention et stocke une valeur fausse de plusieurs ordres de grandeur. Une date interprétée jour d’abord à un endroit et mois d’abord à un autre, et qui atterrit dans un rapport comme un instant plausible mais erroné.
Aucun de ces cas n’est un problème de langue. Ce sont tous des cas où une décision de région est prise à partir d’une entrée de langue, et le correctif est structurel plutôt qu’une meilleure table de correspondance.
Comment la matrice de test doit-elle échantillonner deux axes ?
Échantillonnez chaque axe selon ses propres termes, puis croisez un petit nombre de combinaisons délibérément choisies plutôt que chaque cellule.
Commencez par l’axe des langues et choisissez des entrées qui diffèrent par ce dont l’interface a besoin : une langue dont le texte s’allonge considérablement, une qui nécessite une écriture différente, une dont les règles de tri diffèrent de la valeur latine par défaut. Prenez ensuite l’axe des régions séparément et choisissez des entrées qui diffèrent par ce dont les données ont besoin : une région où un champ n’existe pas, une où une valeur est inhabituellement longue, une dont les conventions entrent en conflit avec un voisin qui partage sa langue.
Les croisements qui comptent le plus sont ceux hors diagonale — la même langue dans deux régions, et deux langues dans une même région. Ces quatre cellules détectent la classe de défauts qu’« une langue, un pays » ne peut pas exprimer, et elles coûtent peu à ajouter une fois les axes stockés séparément.
Pour le détail linguistique du comportement des noms et du texte selon les paramètres régionaux, il existe un guide distinct sur les données de noms par locale, qui reste sur l’axe des langues ; l’axe des régions est le sujet de cet article.
Pour les développeurs : laissez la région piloter le format
Stockez les deux valeurs, et soyez explicite sur celle qui pilote quelle décision. Les règles de format doivent être sélectionnées à partir de la région ; les catalogues de messages et la mise en page du texte doivent être sélectionnés à partir de la langue ; et ni l’un ni l’autre ne doit être déduit de l’autre au moment du rendu.
Gardez les deux réglages à des endroits différents de votre configuration, avec des noms qui disent ce qu’ils sont. Un champ appelé locale qui contient une étiquette de langue est une invitation permanente pour le prochain développeur à l’utiliser comme région. Un champ qui contient un code de région ne devrait jamais être décrit comme la langue que parle un utilisateur.
Ensuite, affirmez la séparation dans les tests. Un test qui rend une langue à travers plusieurs régions, et une région à travers plusieurs langues, échoue bruyamment dès que quelqu’un réintroduit le raccourci. Le répertoire des pays et régions et une page pays telle que l’entrée du Japon montrent comment les conventions d’un seul pays sont décrites lorsqu’elles sont gardées côte à côte, ce qui est une référence plus fiable qu’un nom de langue.
Rien ici ne doit être lu comme une description d’un trafic réel. Les combinaisons de langues et de régions utilisées comme exemples dans cet article sont des choix d’échantillonnage construits, et non des observations d’une base d’utilisateurs réelle, et elles ne disent rien sur l’endroit où quiconque vit ni sur ce que quiconque parle.
Prochaines étapes
Écrivez les trois couches pour un écran que votre équipe possède, et nommez la valeur qui alimente chacune d’elles. Si deux couches sont alimentées par la même valeur, vous avez trouvé le raccourci. Le guide des tests de champs de sélection de pays descend l’axe des régions jusqu’au contrôle que l’utilisateur touche réellement, et le guide des regroupements régionaux et niveaux de marché couvre la manière dont les régions elles-mêmes sont définies.