Les données de noms selon la locale sont le point où une conception de formulaire qui semblait neutre se révèle avoir été écrite pour une partie du monde. L’hypothèse est presque toujours la même — qu’une personne a un prénom suivi d’un nom de famille, dans cet ordre, en alphabet latin, séparés par un espace — et chaque proposition de cette phrase est fausse quelque part.
Ce guide passe en revue les différences structurelles qui comptent lorsque les données sont stockées plutôt qu’affichées, et explique ce qu’une suite de tests doit contenir avant que quiconque puisse affirmer qu’un champ de nom est internationalisé.
La composition d’un nom varie
Les éléments qui composent un nom personnel ne sont pas universels, et leur nombre ne l’est pas non plus. Les dispositions courantes incluent un prénom plus un nom de famille, un nom de famille écrit avant un prénom, un ou plusieurs prénoms sans aucun nom de famille, un prénom suivi d’un patronyme dérivé du prénom d’un parent, et des noms de famille composés écrits avec un espace ou un trait d’union entre les parties.
Aucune de ces dispositions n’est une exception à une règle ; ce sont simplement des règles différentes. Un formulaire qui raisonne en termes de « prénom » et de « nom de famille » affirme une structure qu’une part importante du monde ne suit pas, et l’affirmation échoue au moment où les données sont utilisées plutôt qu’au moment où elles sont saisies — dans une formule d’appel, dans une étiquette d’expédition, dans une liste triée, dans un algorithme de rapprochement.
Quelles langues placent le nom de famille en premier ?
Plusieurs, et ce n’est pas un petit groupe. Les conventions de dénomination d’Asie de l’Est placent traditionnellement le nom de famille en premier et le prénom en second, et le hongrois fait de même en Europe. Lorsqu’un tel nom est enregistré dans un système qui attend l’ordre inverse, les deux moitiés sont interverties, et l’interversion est invisible parce que les deux moitiés sont des noms personnels plausibles.
La défaillance devient grave lorsque le nom est rapproché d’un autre enregistrement ou imprimé sur un document. Une lettre adressée à la mauvaise moitié d’un nom est un petit embarras ; un document de contrôle frontalier ou d’identité affichant le mauvais ordre de nom relève d’une tout autre catégorie de problème, et c’est l’une des raisons pour lesquelles des normes internationales régissent les documents lisibles par machine.
La leçon pratique est que l’ordre est une propriété de l’enregistrement, et non une propriété du champ. Stockez les parties d’une manière définie, stockez la locale qui régit leur ordre, et formatez pour l’affichage au dernier moment plutôt qu’au moment de la saisie.
Les noms uniques sont-ils légitimes ?
Oui, et un formulaire qui exige deux champs de nom rejettera une personne réelle. Les mononymes existent comme noms légaux dans plusieurs pays et cultures, et les personnes qui en portent se heurtent constamment à ce problème : le formulaire insiste sur un nom de famille, alors elles saisissent quelque chose, et désormais chaque document auquel elles sont comparées est en désaccord avec l’enregistrement.
Le même schéma apparaît sous des formes plus légères. Certaines personnes ont plusieurs prénoms et aucun emplacement de deuxième prénom qui leur convienne. Certaines ont un nom de famille composé de deux mots qu’un analyseur séparant sur les espaces découpera. Certaines ont des noms d’un seul caractère, ce qui déclenche des contrôles de longueur minimale écrits pour rassurer plutôt que pour une raison.
Le correctif est structurel plutôt que cosmétique : marquez le second champ de nom comme facultatif pour les pays où il l’est, ou mieux, traitez l’ensemble du nom comme une seule valeur avec des champs de parties facultatifs qui ne sont jamais obligatoires par défaut. La validation doit rejeter ce qui est impossible, et non ce qui est simplement inhabituel.
Qu’advient-il d’un nom dans un autre alphabet ?
Deux choses se produisent, et elles sont souvent confondues l’une avec l’autre. La première est la translittération : convertir un nom écrit dans un système d’écriture en un autre, ce qui est une correspondance comportant de vrais choix et plus d’une convention admise. La seconde est la normalisation : décider si deux chaînes qui paraissent identiques sont réellement identiques, ce qui est une question de stockage et de comparaison.
Les diacritiques comptent dans les deux cas. Un nom portant un accent est une chaîne différente du même nom sans accent, et le fait qu’ils doivent être traités comme égaux dépend de ce que vous faites. Le rapprochement de deux enregistrements devrait généralement être insensible aux accents ; l’impression d’un document ne devrait jamais supprimer les accents. Le classement — l’ordre dans lequel les noms se trient — dépend aussi de la langue, si bien qu’une liste triée selon la locale par défaut du serveur ne sera pas dans l’ordre attendu par un lecteur de cette langue.
La casse est plus subtile qu’elle n’en a l’air. Convertir un nom en majuscules peut changer sa longueur dans certaines langues, et un petit nombre de paires de lettres ont des formes majuscules différentes selon la langue. Un champ de nom qui met en majuscules pour l’affichage et stocke le résultat a détruit une information qu’il ne peut pas reconstruire.
Pourquoi les problèmes d’encodage ressurgissent sans cesse
Deux chaînes peuvent s’afficher de manière identique à l’écran et ne pas être égales pour autant, car un caractère accentué peut être représenté soit par un seul caractère précomposé, soit par un caractère de base suivi d’une marque combinante. Les deux sont valides, les deux s’affichent de la même manière, et les comparer octet par octet renvoie faux.
Le même problème apparaît chaque fois que du texte circule entre des systèmes ayant des hypothèses différentes sur ce que signifie un identifiant. Le correctif durable est de normaliser à la frontière — lorsque les données entrent, lorsqu’elles sont comparées et lorsqu’elles sont exportées — en utilisant une forme convenue plutôt que celle qui est arrivée.
C’est aussi pourquoi une suite de tests a besoin de noms non latins et accentués. Une fixture entièrement composée de noms latins simples passera tous les contrôles tandis que les données de production en casseront discrètement trois. Les enregistrements du générateur d’identités et de données de test sont tirés par pays et portent les conventions de dénomination de ce pays, ce qui les rend pratiques pour ce type de couverture ; ce sont des noms synthétiques à des fins de test uniquement et ils n’appartiennent à personne.
Comment les champs de nom doivent-ils être agencés ?
Partez de l’usage qui est fait des données et remontez. La plupart des systèmes ont besoin d’afficher un nom, de trier un nom et de rechercher un nom, et aucune de ces opérations n’exige que le nom soit découpé en exactement deux parties à la saisie.
- Un champ d’affichage unique contient le nom tel qu’il doit être lu, dans l’ordre dicté par la locale de l’enregistrement.
- Les champs de parties séparés sont facultatifs et jamais tous les deux obligatoires ; un formulaire qui exige un nom de famille n’est pas international.
- Un marqueur de locale ou d’écriture sur l’enregistrement permet à la mise en forme et au tri de faire le bon choix plus tard.
- Les limites de longueur sont généreuses, car les noms réels sont plus longs que les exemples de n’importe quelle spécification.
- La recherche indexe la forme normalisée, tandis que la valeur stockée conserve ses caractères d’origine.
Cet agencement coûte une colonne supplémentaire et élimine toute une classe de défauts. Il empêche aussi le nom d’être reformaté en silence par la première couche qui le touche.
Pour les développeurs : champs, ordre et comparaison
Modélisez le nom comme une petite structure avec un propriétaire clair. Stockez les parties qui vous ont été fournies, plus l’ordre auquel elles appartiennent, et dérivez la chaîne d’affichage à la demande. Ne stockez jamais le résultat d’une conversion de casse ou d’une suppression d’accents ; stockez l’original et normalisez une copie pour la comparaison.
Pour les fixtures, couvrez les formes qui cassent les hypothèses plutôt que d’en ajouter d’ordinaires : un mononyme, un nom de famille placé en premier, un composé à trait d’union, un nom avec un accent en marque combinante, et un nom d’un seul caractère. Ces cinq cas interceptent la plupart des défauts qu’une centaine de noms ordinaires ne révéleront pas.
Vérifiez ensuite les deux opérations que l’on oublie. Le tri doit suivre la locale de l’enregistrement plutôt que celle de la machine, et la troncature doit être vérifiée par rapport au nom le plus long que les données contiennent réellement, car un agencement qui accueille chaque exemple de la spécification n’est pas une preuve qu’il accueille la base de données. Chaque nom d’une fixture de test est inventé pour les tests logiciels, et aucun enregistrement généré de cette manière n’identifie une personne réelle ni ne tient lieu de telle personne.
Étapes suivantes
Rendez le champ de nom de famille facultatif dans un formulaire cette semaine et voyez si quelque chose en aval en dépend ; si la réponse est oui, la dépendance est le bug. Générez ensuite un ensemble de noms à travers plusieurs locales dans le générateur d’identités et faites-les passer par vos chemins d’affichage, de tri et de recherche, en vérifiant que le tri change avec la locale de l’enregistrement plutôt qu’avec celle du serveur. L’article sur la cohérence des champs couvre les autres paires avec lesquelles ces noms doivent s’accorder.