Respondo a été construit à Dubaï, et ce fait a façonné le produit plus que n’importe quelle décision de feuille de route que nous ayons prise. Une seule file de support ici peut porter un client qui écrit en arabe, un autre en anglais, un troisième en hindi et un quatrième en ourdou — souvent dans la même heure. Il n’a jamais existé de version de ce produit qui traitait une langue comme la langue par défaut et les autres comme des traductions. Plus de trente langues, y compris celles qui se lisent de droite à gauche, devaient être la fondation, et non une couche ajoutée plus tard.

Cette contrainte s’est révélée clarifiante. Quand le multilingue n’est pas optionnel, beaucoup de raccourcis qui semblent raisonnables dans un produit pensé d’abord pour l’anglais se révèlent être des impasses. Voici ce que nous avons appris en construisant pour cette réalité, à la fois côté IA et côté interface.

Traduire n’est pas comprendre

L’architecture tentante est un pipeline : prendre le message entrant, le faire passer par une API de traduction vers l’anglais, le traiter avec vos modèles anglophones, générer une réponse en anglais, puis la retraduire. C’est bon marché, rapide à construire, et ça échoue exactement dans les situations dont le service client est fait.

Les conversations clients sont denses en contexte que la traduction générique aplatit. L’argot, les expressions idiomatiques, les registres de politesse et la terminologie propre à un domaine sont tous rabotés dans l’aller-retour. L’exemple classique est un mot unique dont le sens bifurque : un client qui pose une question sur un « retour » dans un contexte de commerce de détail veut savoir comment renvoyer un produit ; le même mot dans un contexte financier concerne le rendement d’un investissement. La chaîne traduire-traiter-retraduire perd le fil, car au moment où le modèle anglophone le voit, le contexte qui désambiguïse a déjà été massacré.

Respondo utilise à la place des modèles propres à chaque langue. Un message en arabe est compris et traité en arabe, nativement, sans jamais transiter par l’anglais comme représentation intermédiaire. Les distinctions qui comptent — le ton, le registre, le bon sens d’un mot ambigu — sont saisies dans la langue où elles vivent réellement. C’est toute la différence entre une réponse techniquement correcte et une réponse qu’un locuteur natif reconnaît comme fluide.

Quand l’interface bascule

Gérer les langues dans le modèle n’est que la moitié du problème. L’autre moitié, c’est l’interface, et les langues qui se lisent de droite à gauche sont l’endroit où la plupart des systèmes de design se défont discrètement.

Prendre en charge l’arabe et l’hébreu n’est pas une affaire de traduction de chaînes. La mise en page tout entière s’inverse. Le texte s’aligne à droite. L’ordre de lecture va de droite à gauche, ce qui signifie que le flux visuel d’une conversation, la position d’un bouton retour, la direction dans laquelle une flèche doit pointer — tout cela est en miroir. Une conception bâtie avec des hypothèses de gauche à droite figées dans des positions fixes ne se traduit pas en droite-à-gauche ; elle casse.

La subtilité, c’est que tout ne s’inverse pas. C’est le piège dans lequel tombent les équipes quand elles découvrent la propriété CSS direction et croient le travail terminé.

  • La mise en page, l’alignement du texte et l’ordre de lecture passent en miroir. Une barre latérale à gauche en anglais se place à droite en arabe.
  • Les icônes directionnelles héritent de l’inversion. Une flèche « répondre » ou un chevron « suivant » doit pointer dans l’autre sens, car son sens est directionnel.
  • Le contenu intrinsèquement de gauche à droite ne s’inverse pas. Les numéros de téléphone, les noms de marque en écriture latine, les extraits de code et les URL se lisent de gauche à droite quelle que soit la langue environnante. Les mettre en miroir revient à créer un non-sens.

Réussir cela à la main, composant par composant, à l’échelle d’un produit entier est exactement le genre de tâche impossible à maintenir cohérente à mesure que le produit grandit. Nous ne l’avons donc pas fait à la main.

Fondé sur les contraintes, pas sur les positions

La décision qui a rendu le droite-à-gauche viable a été de cesser de décrire nos composants en termes de positions absolues pour commencer à les décrire en termes de relations.

Un composant fondé sur les positions dit « cette étiquette se trouve à 16 pixels du bord gauche ». Cette instruction est fausse dès l’instant où la mise en page s’inverse. Un composant fondé sur les contraintes dit « cette étiquette se trouve au début de la ligne, avec 16 pixels d’espace avant que le contenu ne commence ». Désormais, « début » se résout automatiquement en gauche en anglais et en droite en arabe, et la même définition de composant s’affiche correctement dans les deux sens sans une seule condition.

Nous nous sommes appuyés sur les propriétés logiques du navigateur lui-même pour exprimer cela — le CSS moderne qui raisonne en *start* et *end* plutôt qu’en *left* et *right*, et en *inline* et *block* plutôt qu’en horizontal et vertical. Un composant écrit de cette façon ne sait ni ne se soucie du sens dans lequel il s’affiche. Le sens est défini une seule fois, à la racine, et chaque composant en dessous s’adapte.

Le bénéfice se cumule. Ajouter la prochaine langue de droite à gauche ne coûte presque rien, parce que la logique de mise en page n’a jamais été liée à un sens particulier au départ. Un nouveau composant bâti sur les primitives partagées est correct dans les deux sens par défaut — un ingénieur devrait faire des pieds et des mains pour le casser.

De la place pour que le texte respire

La dernière leçon est la moins glamour et la plus fréquemment ignorée : la longueur du texte varie énormément d’une langue à l’autre, et une mise en page qui n’a jamais vu que de l’anglais craquera sous celles qui n’y tiennent pas.

La même phrase peut être 30 % plus longue en allemand, arriver dans un jeu de caractères complètement différent en chinois — où quelques glyphes portent ce à quoi l’anglais consacre une phrase entière — ou nécessiter plus d’espace vertical pour les signes diacritiques qui se placent au-dessus et en dessous de l’écriture arabe. Un bouton dimensionné pour le mot anglais « Send » tronque ou déborde à l’instant où une traduction plus longue vient s’y loger.

Nos composants supposent dès le départ qu’ils ne connaissent pas la longueur de leur texte. Ils grandissent avec leur contenu, passent à la ligne avec élégance, et ne dépendent jamais du fait qu’une chaîne ait une longueur particulière. C’est une petite discipline qui épargne mille correctifs de mise en page ponctuels par la suite — et, comme la gestion du sens de lecture, c’est le genre de chose presque gratuite si vous l’intégrez dès le premier jour et extrêmement coûteuse à rattraper après coup.

Le fil conducteur

Chacune de ces décisions rime avec la même idée : le multilingue ne peut pas être une fonctionnalité que l’on ajoute, parce que les hypothèses d’un produit monolingue s’immiscent dans le modèle, dans la mise en page et dans le composant individuel. Construisez d’abord pour l’anglais et vous passerez le reste de la vie du produit à rapiécer les endroits où ces hypothèses fuient. Construisez pour trente langues dès le départ et la trente-et-unième est presque gratuite. Être installés là où nos clients parlent une douzaine de langues par jour n’a pas rendu la chose plus difficile — cela l’a rendue impossible à rater discrètement, ce qui est la meilleure sorte de contrainte sous laquelle concevoir.