La correspondance des noms de pays et les alias ressemblent à un problème de table de correspondance. En pratique, la table est la partie facile ; la difficulté est de décider contre quel nom tous les autres sont comparés.
Sans cette décision, la correspondance devient une série de jugements locaux. Un composant considère deux orthographes comme identiques, un autre non, et la différence remonte comme un enregistrement en double ou une jointure échouée. Le nom canonique est l’ancre qui rend le reste du travail mécanique.
Que signifie « canonique » ici ?
Cela signifie une forme désignée pour chaque pays, choisie délibérément et utilisée partout où un nom doit être comparé, trié ou stocké comme clé.
Canonique ne signifie pas correct, et ne signifie pas préféré de tous. Cela signifie qu’une forme unique a été désignée comme référence, afin que chaque autre forme ait une relation définie avec elle. Un pays peut avoir plusieurs noms largement utilisés et pourtant avoir exactement une entrée canonique.
Le choix doit être documenté avec sa raison. Une équipe peut sélectionner la forme utilisée dans une norme internationale parce qu’elle est stable, la forme la plus familière dans le marché principal du produit parce qu’elle réduit les contacts de support, ou la forme locale parce qu’elle respecte la manière dont les habitants nomment leur propre pays. Chacune de ces options est défendable ; un mélange non documenté des trois ne l’est pas.
Pourquoi normaliser avant de comparer ?
Parce que deux chaînes qui paraissent identiques à un lecteur peuvent différer au niveau des octets qu’un ordinateur compare. Les caractères accentués ont plus d’un encodage valide, et un texte qui se lit de la même façon à l’écran peut échouer à un test d’égalité écrit sur les caractères bruts.
Normaliser les deux côtés avant la comparaison élimine toute cette classe de fausses divergences. C’est une opération peu coûteuse, elle est déterministe, et elle devrait avoir lieu à exactement un endroit plutôt que dans chaque composant qui compare des noms.
Trois étapes supplémentaires vont de pair avec elle. Ramenez la casse, pour que la capitalisation seule ne cause jamais de différence. Supprimez et compressez les espaces, car les espaces de début et de fin arrivent des imports et des saisies collées. Et décidez explicitement quoi faire de la ponctuation, y compris les caractères qui séparent les parties d’un nom, puisqu’en les supprimant on change quelles chaînes correspondent.
Ce que la normalisation ne doit pas faire, c’est supprimer ou réécrire des caractères porteurs de sens. Une passe de normalisation qui retire les accents des données stockées modifie les données ; la même passe appliquée seulement au moment de la comparaison ne les modifie pas.
Quand les alias aident-ils et quand induisent-ils en erreur ?
Un alias mérite sa place lorsqu’une véritable forme alternative existe et échouerait sinon à correspondre. Un ancien nom officiel, un nom utilisé localement, une abréviation d’usage courant et une traduction dans une langue largement parlée sont tous des entrées légitimes.
Le risque est que les alias se multiplient. Chaque alias ajouté par commodité est une affirmation selon laquelle deux chaînes désignent le même pays, et une affirmation fausse est pire qu’une affirmation absente, car elle fusionne silencieusement deux enregistrements en un seul qui est faux à propos des deux.
Deux garde-fous maintiennent la table honnête. Premièrement, chaque alias doit avoir une raison énoncée et une source, afin que l’affirmation puisse être revue plutôt qu’héritée pour toujours. Deuxièmement, les alias ne doivent pas être générés par une règle qui paraît plausible mais qui n’est pas vraie — une transformation mécanique appliquée au nom d’un pays produira des chaînes qui ressemblent à des noms d’autres pays.
Gardez la table d’alias petite et auditable. Une table de quelques centaines d’entrées qu’une personne peut lire vaut mieux qu’une grande table générée que personne ne peut vérifier.
Que va-t-il mal lorsque la correspondance approximative est le premier recours ?
La correspondance approximative est séduisante car elle semble résoudre le problème sans aucun travail sur les données. Elle produit aussi des erreurs confiantes et silencieuses, qui sont les plus difficiles à trouver.
Deux mécanismes causent la plupart des dégâts. Les noms de pays différents qui diffèrent d’une petite distance d’édition vont correspondre entre eux. Et une faute de frappe qui se trouve par hasard plus proche d’un mauvais pays que du bon sera corrigée dans la mauvaise direction.
| Stratégie | Ce qu’elle corrige | Ce qu’elle coûte |
|---|---|---|
| Correspondance exacte sur une forme canonique | Rien au-delà de la forme elle-même | Rate chaque variante |
| Normaliser puis comparer | Différences d’encodage, de casse et d’espacement | Rate les vraies variantes |
| Forme canonique plus alias curatés | Noms variantes et traductions connus | Exige de la maintenance |
| Correspondance approximative partout | Fautes de frappe inconnues | Fusionne silencieusement des pays différents |
L’ordre pratique est celui du tableau lu de haut en bas, avec la correspondance approximative utilisée en dernier, sur le résidu, et uniquement là où une mauvaise réponse est peu coûteuse à inverser. Une correspondance approximative qui produit une suggestion à confirmer par un humain est une fonctionnalité différente d’une correspondance approximative qui écrit une valeur.
Faut-il stocker les noms du tout ?
Stockez le code, et traitez le nom comme quelque chose rendu pour un lecteur plutôt que conservé comme l’identité d’un enregistrement.
Les noms changent ; les codes sont maintenus précisément pour que l’identité survive au changement. Un enregistrement dont l’identité est un nom devient ambigu dès que ce nom est révisé ou traduit, et l’ambiguïté reste invisible jusqu’à ce que deux enregistrements qui devraient n’en former qu’un apparaissent côte à côte.
Un nom d’affichage doit quand même être stocké ou généré, et il doit être étiqueté pour ce qu’il est. Un champ appelé name qui sert à la fois d’étiquette et de clé de jointure finira par être utilisé comme la mauvaise des deux.
Pour les développeurs : placez la comparaison derrière une seule fonction
Centralisez la comparaison plutôt que de la répéter. Un endroit unique qui effectue la normalisation, applique la table d’alias et décide du résultat signifie que les règles peuvent être revues une fois et modifiées une fois, et que chaque appelant hérite du même comportement.
Lorsque le résultat est incertain, préférez renvoyer une suggestion classée plutôt qu’une décision. Le répertoire des pays et régions présente les noms aux côtés de leurs codes, ce qui est l’appariement qui rend une mauvaise correspondance visible plutôt que plausible, et pour le contexte linguistique du comportement des noms selon la langue, le guide des données de noms par locale couvre le volet linguistique que cet article laisse délibérément de côté. Le comportement au niveau du contrôle d’un sélecteur qui consomme ces correspondances est couvert dans le guide des tests de champs de sélection de pays.
Les entrées d’alias et les variantes orthographiques utilisées comme exemples ci-dessus sont inventées à des fins d’illustration. Ce n’est pas une vraie table d’alias, elles ne reflètent aucune convention de nommage publiée, et aucun exemple de cet article ne doit être traité comme un nom officiel ou préféré pour un pays.
Prochaines étapes
Écrivez votre forme canonique pour un pays et la raison pour laquelle elle a été choisie, puis comptez combien d’endroits de votre système comparent des noms sans passer par une étape partagée. Le guide pays ou langue explique pourquoi un nom traduit relève de la couche linguistique plutôt que d’un changement d’identité.