Le multilingue est facile à cadrer comme un problème de contenu et à chiffrer comme tel. Dans un logiciel opérationnel servant une région où les documents sont bilingues, c’est un problème structurel, et le coût de le découvrir tard n’est pas linéaire.
Un logiciel d’entreprise peut arriver sur un marché avec un fichier de langue et l’assurance que la localisation est prise en charge. Prise en charge peut ne signifier rien de plus que la substitution de chaînes, en laissant de côté le sens dans lequel ces chaînes se lisent, la forme des chiffres à côté d’elles, le côté de l’écran où va une étiquette, la manière dont un tableau se trie, et le fait qu’un même document peut contenir les deux écritures à la fois et doit rester lisible dans les deux.
Pour une organisation qui opère là où les documents réglementaires sont dans une langue et la langue de travail de l’équipe dans une autre, cet écart n’est pas cosmétique. Il détermine si un registre de permis peut être lu tout court.
Ce qui casse réellement
Le miroir de la mise en page est la partie visible et la plus facile. Marges, iconographie, sens de progression, position d’un bouton retour, ordre des colonnes d’un tableau — tout cela s’inverse, et un système qui a codé en dur gauche et droite plutôt que début et fin doit être repris partout à la fois.
La partie difficile, c’est le contenu mixte. Une référence de permis, une étiquette de matériel et une date peuvent être des caractères latins et des chiffres occidentaux dans une phrase par ailleurs écrite de droite à gauche. Obtenir que cela s’affiche correctement et sans ambiguïté — pour qu’un numéro de référence ne se lise jamais à l’envers et ne bascule jamais du mauvais côté d’une cellule — n’est pas un exercice de style. Cela touche à la manière dont les données sont stockées et dont chaque champ est typé.
Et puis il y a tout ce qui n’est ni mise en page ni texte : l’ordre de tri, le comportement de la recherche, la saisie qui doit accepter l’une ou l’autre écriture dans le même champ, les exports qui doivent survivre à une ouverture dans un tableur sur l’ordinateur de quelqu’un, et l’impression qui peut être l’artefact sur lequel l’organisation s’appuie réellement.
La courbe de coût
Conçue dès le départ, la prise en charge bidirectionnelle est une contrainte sur la manière d’écrire les composants. C’est une discipline plutôt qu’une dépense : utiliser des propriétés logiques, typer les champs, ne jamais présumer d’un système de chiffres, et tester les deux sens dès le premier écran.
Ajoutée après coup, c’est une réécriture de la couche de présentation menée sous échéance, et le mode de défaillance est pire que l’effort — le produit sort avec la seconde langue prise en charge partout sauf aux endroits que personne n’a pensé à vérifier, et ces endroits sont trouvés par les utilisateurs qui en ont le plus besoin.
OPS porte trois langues, dont l’arabe de droite à gauche en entier. Cette structure est la raison pour laquelle les écrans de permis peuvent tenir un permis de travail à chaud avec sa référence et ses dates dans une écriture et son titre dans une autre, sur la même ligne, sans que l’un ou l’autre ne devienne ambigu.
Pour quiconque spécifie un système
Mettez la seconde langue dans la première version de la spécification, pas dans la deuxième phase de la feuille de route. Demandez une capture de l’écran le plus dense en données dans les deux sens avant de signer quoi que ce soit. Un fournisseur dont l’architecture la prend déjà en charge peut vous en montrer une ; un fournisseur dont la réponse est une conversation sur les délais vous dit qu’elle ne la prend pas.
Recalibre · OPS est en développement. Chaque écran montré porte des données de démonstration.