Un formulaire multilingue ne se traduit pas champ par champ

Dates, lieux, heures et sens de lecture : une interface peut changer de langue tout en préservant le sens des données. Une méthode concrète pour organiser cette continuité.

Une personne remplit une date de naissance sur une page française, puis passe en anglais pour montrer le formulaire à un proche. Les libellés changent. Mais le 4 mars devient-il le 3 avril ? La ville sélectionnée reste-t-elle la même ? Une heure inconnue se transforme-t-elle discrètement en midi ? Ces questions relèvent du produit autant que de la traduction.

Pour une petite équipe qui propose un service en plusieurs langues, le risque est de traiter chaque version comme un formulaire autonome. Il vaut mieux définir d'abord ce que chaque réponse signifie, puis décider comment la rendre lisible dans chaque langue. La traduction devient alors une présentation de données communes, au lieu de créer plusieurs vérités concurrentes.

Décrire la réponse avant de traduire la question

Prenons un exemple fictif : une date grégorienne au 4 mars 1992, une heure locale de 08 h 30 et une ville choisie dans une liste. Ce dossier contient au moins trois objets distincts. La date identifie un jour du calendrier. L'heure décrit ce que marquait une horloge locale. La ville désigne un lieu. Aucun de ces objets ne devrait changer parce que le visiteur sélectionne une autre langue.

Une fiche de cadrage peut préciser, pour chaque champ : son sens, son caractère obligatoire ou facultatif, les états autorisés et les informations à conserver. Pour l'heure, les états "connue", "approximative" et "inconnue" ne sont pas interchangeables. Pour un lieu, le nom affiché ne suffit pas à garantir que deux réponses désignent la même commune. Ce petit travail évite de demander à la traduction de résoudre une ambiguïté du modèle.

Faire relire la date, pas seulement ses chiffres

La chaîne 04/03/1992 est courte, mais son ordre peut prêter à confusion. Le W3C recommande notamment des mois explicites et des années sur quatre chiffres lorsque la lecture risque d'être ambiguë. Une confirmation telle que "4 mars 1992" donne au visiteur une information plus facile à contrôler. Une représentation stable destinée au traitement peut rester distincte de cette présentation.

Le calendrier mérite lui aussi une indication si le service n'en accepte qu'un. La langue arabe, par exemple, ne permet pas à elle seule de déduire le calendrier attendu. Une instruction brève près du champ vaut mieux qu'une supposition. Dans la recette fonctionnelle proposée, la même date doit produire le même jour, le même mois et la même année après chaque changement de langue.

Dissocier le nom du lieu et son identité

Paris peut désigner plusieurs communes. Un nom traduit peut également avoir plusieurs orthographes usuelles. La liste de résultats devrait donner assez de contexte pour choisir : ville, pays et, si nécessaire, région. Après sélection, l'application doit conserver la référence au lieu choisi, plutôt que de retrouver un nouveau lieu à partir du seul texte traduit.

Dans un service fondé sur une date et un lieu de naissance, le fuseau horaire apporte une autre dimension. La documentation IANA décrit des règles dont les décalages peuvent évoluer dans le temps. Le décalage observé aujourd'hui n'est donc pas une règle historique suffisante. La même documentation signale aussi les limites de couverture des heures anciennes, notamment avant 1970.

Un calculateur de thème astral constitue un cas concret de ces besoins : le formulaire de thème astral en français de Fardous TAROT, notre projet, réunit une date, une heure et un lieu de naissance. Ce type de parcours permet de poser les bonnes questions de recette : quelle donnée a été saisie, laquelle manque et laquelle sera utilisée ? Ces critères peuvent guider l'évaluation d'un service avant toute conclusion sur son traitement interne.

Changer le sens de lecture sans réécrire les valeurs

Une interface arabe peut contenir un nom français, des coordonnées et un identifiant de fuseau comme Africa/Cairo. Le W3C distingue la langue du document de sa direction de lecture. Une page déclarée en arabe ne devient pas automatiquement une page correctement organisée de droite à gauche.

Pour la recette, il est utile de construire une ligne de test mêlant plusieurs types de contenus, puis de relire les signes, parenthèses et séparateurs. L'objectif n'est pas de retourner chaque chaîne de caractères. C'est de garder une lecture compréhensible de l'ensemble, tout en préservant l'ordre interne des valeurs qui le demandent. Une vérification visuelle doit compléter celle des valeurs enregistrées.

Ne pas perdre le travail au changement de langue

Voici une règle produit simple à proposer : basculer la langue ne doit ni soumettre le formulaire ni effacer une réponse sans avertissement. Le champ choisi, son état et son éventuelle incertitude doivent être transportés ensemble. Une erreur déjà signalée doit conserver son sens, avec un message adapté à la nouvelle langue.

Les instructions doivent rester disponibles quand la personne commence à saisir. Le tutoriel du W3C sur les formulaires rappelle que le texte indicatif à l'intérieur d'un champ ne remplace pas son libellé. Pour une équipe de traduction, cela implique de prévoir séparément le nom du champ, son aide et son message d'erreur, au lieu de concentrer toutes les explications dans un seul exemple qui disparaît.

Une recette courte, avec des résultats attendus

Un premier scénario saisit le 4 mars, change de langue, puis vérifie la date confirmée. Un deuxième choisit une ville dont le nom existe dans plusieurs pays et contrôle la sélection conservée. Un troisième renseigne une heure inconnue : aucune valeur précise ne doit apparaître comme si elle avait été fournie. Un quatrième mélange arabe et caractères latins, puis vérifie la lecture et les données. Un dernier retourne à la première langue pour contrôler l'aller-retour.

Ces scénarios sont des propositions de test, pas des résultats mesurés sur un produit. Ils peuvent néanmoins servir de base commune à la rédaction, à la traduction et au développement. Chaque anomalie devient alors une question précise : le texte est-il mal traduit, la valeur a-t-elle changé, ou la présentation rend-elle la bonne valeur difficile à comprendre ?

Une équipe n'a pas besoin de traduire davantage pour répondre à ces questions. Elle a besoin de rendre visible le contrat entre la réponse donnée et celle qui sera traitée. C'est cette continuité, vérifiable par un utilisateur comme par l'équipe, qui donne de la cohérence à un formulaire multilingue.