Données régionales Intl et formatage web portable

L’API JavaScript Intl aide une application à présenter les dates, nombres, monnaies et autres informations sensibles à la langue sous une forme familière. Elle ne décide pas ce qu’une personne voulait dire, de quel pays elle relève ni dans quel fuseau un événement a eu lieu. Un formatage portable part de données applicatives claires et d’un choix de présentation explicite. Le navigateur peut alors convertir une valeur en texte localisé sans obliger l’application à gérer toutes les conventions de ponctuation et d’ordre.

L’application doit séparer la valeur sous-jacente du texte affiché. Un nombre reste le même même si les chiffres sont groupés autrement selon la région. Un horodatage d’événement représente toujours le même instant même si deux personnes voient des heures locales différentes. Le texte formaté est destiné aux personnes. Ce n’est ni un format de stockage stable, ni une entrée fiable pour l’analyse, ni une preuve d’identité. Cette distinction prévient des erreurs qui n’apparaissent souvent qu’après l’arrivée du produit dans une autre langue ou région.

Les données régionales du navigateur peuvent évoluer avec les mises à jour du système d’exécution, et les détails de présentation peuvent varier selon l’environnement. L’objectif de compatibilité n’est pas une ponctuation identique partout. Il est que la personne comprenne la valeur, puisse choisir une langue ou une région adaptée si nécessaire et accomplisse sa tâche. Pour la question distincte de la cohérence entre langue et fuseau horaire du navigateur, consultez le guide sur les fuseaux horaires, les régions et les langues. Cette page porte sur la sortie de l’application, pas sur l’identité du navigateur.

Laisser la personne choisir la langue de présentation

Le navigateur peut fournir une préférence linguistique, mais l’application ne doit pas en faire une décision irréversible. Les personnes partagent des appareils, voyagent, travaillent dans plusieurs langues ou préfèrent des langues différentes selon la tâche. La langue du compte peut également être plus utile que la préférence actuelle du navigateur. Choisissez une présentation initiale à partir des informations disponibles, puis proposez un moyen visible de la modifier lorsque la langue compte pour la tâche.

Séparez la langue de l’interface du format régional lorsque le produit doit distinguer les deux. Une personne peut lire des instructions en anglais tout en attendant des dates et des prix au format régional. Une autre peut choisir la langue du contenu sans vouloir changer la monnaie de facturation du compte. L’application doit nommer le choix proposé. Un contrôle « Langue » ne doit pas modifier silencieusement la monnaie d’une valeur ou le fuseau horaire sous-jacent d’un événement.

Un choix explicite doit primer sur une valeur par défaut déduite. Si la personne choisit une langue prise en charge, gardez l’interface cohérente entre les pages et les visites ultérieures selon le comportement annoncé par le produit. Permettez de modifier ce choix. Si l’application le mémorise dans un compte ou un stockage du navigateur, expliquez où il s’applique. Une préférence choisie pour un espace de travail ne doit pas régir par surprise un compte sans rapport.

Le comportement de repli doit aussi être prévisible. La langue demandée peut ne pas être traduite ou une variante régionale peut manquer. Choisissez un repli documenté, gardez la langue sélectionnée visible et évitez de mélanger des langues sans lien dans une même tâche. Un repli peut préserver l’accès au service, sans prétendre que toute l’interface est traduite si seule une partie l’est.

Les étiquettes de langue identifient une langue et peuvent inclure des sous-étiquettes d’écriture ou de région. ECMA-402 définit la gestion des identifiants régionaux par ses services de formatage. L’application reste responsable du choix des langues prises en charge et de la correspondance entre préférence et contenu disponible. Transmettre un identifiant régional à Intl ne traduit pas les libellés, instructions, textes juridiques ni contenus créés par les utilisateurs.

Alignez si possible la langue du contenu sur le formatage, sans imposer une valeur unique à toutes les fins. Un message en espagnol peut contenir un montant formaté selon une région de facturation et l’heure d’une réunion dans le fuseau choisi par la personne qui la consulte. Indiquez quel choix régit chaque valeur. C’est plus clair que de traiter la préférence linguistique du navigateur comme un profil complet de la personne.

Le choix régional concerne aussi l’accessibilité, pas seulement l’apparence. Des métadonnées de langue correctes aident les technologies d’assistance à prononcer le texte. Les commandes de changement de langue doivent garder un nom reconnaissable après une modification accidentelle. La page doit conserver le focus et la tâche actuelle quand la langue de l’interface change. Exiger un redémarrage complet ou supprimer la saisie d’un formulaire peut transformer une préférence utile en obstacle.

Testez la langue par défaut à la première visite, un changement explicite, une préférence mémorisée, une variante non prise en charge et le retour à la langue précédente. Vérifiez ensemble le texte de l’interface et les valeurs formatées. Une date peut être correcte tandis que son libellé reste dans une autre langue, ou un libellé traduit peut entourer un nombre dont le format demeure codé en dur.

Pour une explication plus large des interactions entre les choix du navigateur, du compte, du site et du réseau, lisez le guide sur les surfaces de confidentialité du navigateur. Une préférence linguistique est une donnée de présentation. La combiner à d’autres signaux pour classer les personnes constitue un autre usage des données, distinct du formatage courant.

Utiliser Intl pour la présentation, pas comme source de vérité

Intl fournit aux applications JavaScript des formateurs et d’autres services sensibles à la langue. ECMA-402 définit leur comportement et le modèle des opérations régionales. MDN documente les interfaces de formatage courantes et leur utilisation. Le navigateur fournit l’implémentation et les données régionales. L’application fournit la valeur, les options pertinentes et le contexte d’affichage.

Conservez les données canoniques dans des types et des champs qui expriment leur sens. Un montant monétaire requiert une valeur numérique et un code de monnaie distinct. Un événement planifié requiert un instant ou une règle claire d’heure locale et le fuseau applicable. Une mesure requiert une valeur et une unité. Une chaîne formatée ne peut pas restituer de manière fiable tous ces champs au stockage, car ponctuation, symboles, ordre et langue peuvent varier.

Le formatage est généralement la dernière étape avant l’affichage. Un service de données peut renvoyer des valeurs structurées, puis la page appliquer les choix de présentation de la personne. Il devient possible de changer la langue de l’interface sans réécrire l’enregistrement stocké. Les règles d’export sont également explicites : un export lisible par machine conserve les valeurs structurées, tandis qu’un rapport destiné aux personnes peut contenir des libellés et un format localisés.

Ne parsez pas une chaîne localisée pour retrouver la valeur d’origine. Une virgule peut séparer les groupes dans une convention et indiquer la fraction décimale dans une autre. Un symbole monétaire peut représenter plusieurs monnaies. Une date composée uniquement de chiffres peut être ambiguë lorsque l’ordre du jour et du mois diffère. Si le produit accepte une saisie, définissez séparément son format et sa validation, et montrez le format accepté près du champ.

Choisissez les options selon le domaine. Un reçu de paiement peut nécessiter une monnaie et une règle d’arrondi propres au parcours financier. Un affichage scientifique peut nécessiter une unité et une précision qui préservent l’information utile. Une indication temporelle relative peut aider à se repérer, mais ne doit pas remplacer un horodatage exact quand il faut comparer des enregistrements. Intl exprime la présentation choisie, sans décider des règles juridiques, comptables, scientifiques ou de planification.

Gardez les protocoles machine distincts de la présentation humaine. Les API, bases de données, journaux et signatures nécessitent des contrats de données stables. Le format localisé appartient à la frontière visible par les personnes, sauf définition explicite du protocole. Une valeur copiée depuis une page localisée doit conserver assez de contexte pour rester compréhensible ailleurs, notamment dans un message, un tableur ou une demande d’assistance.

La sortie du formateur ne convient pas non plus comme identifiant durable. Son apparence exacte peut changer lorsque les données régionales, les options ou les versions d’exécution évoluent. Si l’application doit mémoriser une préférence, stockez la préférence choisie, comme la langue ou le fuseau, et non la dernière sortie formatée. Ne transformez pas les différences de présentation en profil d’appareil.

Cette séparation facilite les tests. Un test peut d’abord vérifier la valeur sous-jacente et les choix de présentation, puis vérifier que la sortie transmet le sens prévu. Il n’a pas besoin d’exiger des espaces, abréviations ou ponctuations identiques dans tous les environnements valides. Les comparaisons exactes de texte restent pertinentes pour un libellé fixe ou un affichage réglementé que le produit contrôle.

Formater nombres, monnaies et dates selon leur contexte

Les nombres nécessitent davantage de contexte qu’un identifiant régional. Un compte, un pourcentage, une distance, une température, un prix et un identifiant contiennent tous des chiffres, mais ne s’interprètent pas de la même façon. Donnez au formateur le type de valeur affiché et ajoutez un libellé clair. Sans unité ni rôle, un nombre peut rester ambigu malgré une présentation soignée.

Pour les pourcentages, distinguez la valeur stockée de la convention affichée. Si le produit stocke une fraction, formatez-la selon le modèle d’entrée attendu. S’il stocke des points de pourcentage, le choix de conversion diffère. L’application définit ce sens ; un réglage régional ne corrige pas un décalage entre quantité stockée et libellé.

Conservez le code de monnaie avec le montant. Une région influe sur l’ordre du symbole, les espaces et le groupement des chiffres, mais ne détermine pas la monnaie de la transaction. Changer la langue de la personne ne doit pas convertir le montant ou le désigner silencieusement dans une autre monnaie. Une conversion, si elle existe, est une opération distincte dont le produit doit expliquer la source du taux et sa date d’application.

L’arrondi relève également du produit. Le formateur peut afficher un nombre choisi de chiffres, mais ne doit pas être le seul endroit où réside une règle d’arrondi financier ou scientifique. Les valeurs stockées, comparées ou totalisées nécessitent un calcul défini. Un affichage arrondi pour la lisibilité ne doit pas être pris pour la valeur exacte d’une transaction ou d’une analyse.

Une date exige sa valeur et le choix du fuseau. Un instant enregistré peut s’afficher dans le fuseau de la personne, celui du lieu de l’événement ou un fuseau fixe de rapport. Ces choix ont des sens différents. Une étiquette linguistique modifie les mots et l’ordre des éléments, mais ne choisit pas le fuseau d’un rendez-vous ou d’une échéance juridique.

Les dates calendaires locales demandent aussi de l’attention. Un anniversaire, une date d’arrivée à l’hôtel et une période de rapport quotidienne peuvent désigner un jour du calendrier plutôt qu’un instant universel. Convertir cette valeur dans un fuseau arbitraire peut la déplacer au jour voisin. Clarifiez le type métier avant le formatage et affichez le fuseau pertinent lorsqu’un événement horaire risque d’être mal compris.

Les changements d’heure rendent les suppositions informelles particulièrement fragiles. Une heure locale peut se répéter ou ne pas exister le jour du changement. Une application qui planifie des événements doit résoudre ce cas selon une règle documentée ; le formatage d’un horodatage n’est que l’étape de présentation. Pour les comparaisons entre lieux, incluez le nom ou le décalage du fuseau dans l’affichage courant. Ne demandez pas à la personne de le déduire de la langue ou du lieu.

La frontière des API est précise : Intl.Locale traite les identifiants régionaux, Intl.NumberFormat présente les nombres et monnaies, et Intl.DateTimeFormat présente les valeurs de date et d’heure. Ces API ne choisissent pas la monnaie d’une transaction, ne définissent pas un jour de calendrier et ne résolvent pas la règle de planification d’une application.

La justesse des fuseaux mérite des tests applicatifs ciblés, notamment pour les voyages, événements récurrents et transitions horaires. Gardez cette logique métier distincte de la couche générale de formatage. L’article sur la cohérence de JavaScript Math traite du calcul numérique et de la portabilité ; il ne remplace pas la définition du sens d’une date, monnaie ou unité avant affichage.

Utilisez des exemples proches des tâches réelles pendant la revue. Un reçu doit afficher le bon montant et la bonne monnaie ; un calendrier, le bon jour dans le fuseau choisi ; une mesure, son unité ; un grand compte doit rester lisible. Ces vérifications détectent des erreurs de sens qu’un instantané générique de ponctuation formatée manquerait.

Tenir compte des données régionales et des différences d’exécution

Le comportement d’Intl dépend du contrat ECMA-402 et des données régionales présentes dans l’environnement. La spécification définit des algorithmes et des comportements requis, mais ne fige pas chaque mot, abréviation ou détail typographique de toutes les langues pour toutes les futures versions. Les conventions évoluent. Une mise à jour du navigateur ou du système peut apporter de nouvelles données sans changement du code applicatif.

Traitez la prise en charge régionale comme une exigence produit aux résultats observables. Énumérez les langues et variantes régionales promises, les fonctions de formatage utilisées et le repli proposé en cas d’indisponibilité. Testez ces engagements sur les navigateurs pris en charge par le produit. Ne déduisez pas la prise en charge d’un simple numéro de version ni d’un format réussi dans une autre région.

L’application doit rester résiliente si la région ou l’option préférée ne permet pas la présentation demandée. Le repli doit conserver la valeur et garder le résultat compréhensible. Une convention régionale manquante ne doit pas transformer un montant en nombre sans libellé ou une échéance en date sans fuseau. Dans les parcours à fort enjeu, expliquez le repli et permettez d’examiner le contexte sous-jacent.

Acceptez les variations typographiques sans conséquence. Espaces, séparateurs, ponctuation et abréviations peuvent différer entre implémentations valides. Des espaces qui semblent identiques peuvent avoir des représentations distinctes. Une égalité stricte des chaînes peut fragiliser un test alors que le sens visible reste correct. Comparez si possible valeurs structurées et résultats produit ; réservez les contrôles exacts au texte que le produit maîtrise réellement.

Les données régionales ne définissent pas une identité. Le choix d’une abréviation par un environnement ne prouve ni le lieu de résidence ni la langue d’une personne. L’application ne doit pas classer les utilisateurs à partir de la sortie du formateur. Utilisez les préférences explicites et les données de la tâche, et limitez les diagnostics de compatibilité au résultat produit concerné.

Examinez les polices et la mise en page avec de vrais textes localisés. Les dates et prix peuvent être plus longs que les exemples anglais d’une maquette. Un symbole de monnaie peut nécessiter une police de remplacement ; un libellé de date peut revenir à la ligne ; une langue de droite à gauche peut modifier la disposition. Le formateur ne résout pas seul ces questions d’interface. Prévoyez l’espace, autorisez les retours à la ligne et vérifiez l’ordre de lecture des langues prises en charge.

Pensez aussi au contenu copié et exporté. Un nombre clair dans un tableau légendé peut devenir ambigu une fois collé sans son titre. Ajoutez l’unité, la monnaie, le fuseau de date ou tout contexte nécessaire aux exports et partages. Les exports lisibles par machine doivent utiliser un schéma explicite et laisser la localisation à l’interface destinataire plutôt que d’exporter uniquement le texte affiché.

Lorsqu’une mise à jour du navigateur modifie une sortie, étudiez d’abord la conséquence visible avant de parler de régression. Le sens du montant a-t-il changé, le libellé est-il devenu illisible ou seul l’espacement a-t-il bougé ? L’application dépendait-elle d’une chaîne fixe que la plateforme n’a jamais garantie ? Un jeu limité d’exemples liés à de vraies tâches clarifie la différence mieux qu’un inventaire de toutes les variations.

Consignez la version de l’application, celle du navigateur, la région choisie et la valeur d’entrée à l’origine d’un problème d’affichage. Ces éléments peuvent aider à le reproduire sans recueillir de caractéristiques sans rapport du navigateur. Ne gardez les diagnostics d’assistance que pendant la durée nécessaire et ne transformez pas une plainte de formatage en inventaire général de l’environnement.

Rendre le formatage compréhensible et accessible

Une chaîne localisée doit être comprise dans son contexte. Une date courte composée de chiffres peut être compacte mais ambiguë. Un nombre avec des séparateurs de groupes et de décimales a encore besoin d’un libellé. Monnaie, unité et fuseau doivent être visibles au moment du choix, pas cachés dans une infobulle éventuellement inaccessible aux technologies d’assistance.

Utilisez des éléments sémantiques pour le texte qui entoure une valeur formatée. L’en-tête d’un tableau peut nommer le montant ou la date ; le libellé d’un champ peut préciser le format accepté ; un message d’état peut expliquer une préférence modifiée. Cette structure aide les lecteurs d’écran et outils associés à relier la valeur à son sens. Le formatage ne fournit pas les relations omises dans le balisage.

La langue du document doit refléter celle de son texte. Lorsqu’une page inclut un passage dans une autre langue, marquez-le correctement pour sa prononciation par les technologies d’assistance. Le sélecteur de langue doit rester repérable même si le choix actuel est inconnu. Ne représentez pas les langues uniquement par des drapeaux : une langue peut être utilisée dans plusieurs pays et un pays peut compter plusieurs langues.

Laissez la personne corriger une valeur par défaut automatique inadaptée. Un choix visible de langue ou de format régional est particulièrement important sur les appareils partagés, en voyage et dans les parcours multilingues. Séparez ce choix de l’autorisation de localisation et des données de compte sans rapport. Il ne faut pas divulguer une localisation précise pour lire une date ou un montant dans un format familier.

Un changement de présentation ne doit pas modifier l’enregistrement sous-jacent. Si la personne change de langue en remplissant un formulaire, conservez la valeur saisie et expliquez son nouvel affichage. Si un événement planifié apparaît dans un autre fuseau, gardez son identité et indiquez le fuseau utilisé. Ces transitions doivent être réversibles et ne doivent pas confirmer silencieusement une nouvelle transaction ou un nouveau rendez-vous.

Testez avec des technologies d’assistance et les tailles de texte utilisées par le public. Vérifiez que les valeurs localisées longues reviennent à la ligne sans masquer les commandes voisines, que l’ordre de lecture reste logique et que la valeur copiée garde son contexte hors de la page. Si une valeur est abrégée à l’écran, proposez une forme complète accessible lorsqu’elle améliore la clarté. Évitez les annonces répétées qui rendent la page bruyante.

Les messages d’erreur ont aussi besoin de localisation et de contexte. Si l’application refuse un nombre ou une date, indiquez le format accepté et donnez un exemple adapté à la langue choisie. Ne renvoyez pas simplement la saisie dans un autre format en la déclarant invalide. Distinguez une erreur d’analyse d’une valeur valide hors des limites métier.

Le meilleur test d’acceptation est une tâche réelle. La personne comprend-elle le montant et sa monnaie avant de confirmer un paiement ? Peut-elle savoir quand un événement commence et quel fuseau s’applique ? Peut-elle changer de langue sans perdre son travail ? Ces résultats importent davantage que la reproduction de chaque caractère d’un environnement donné.

Examiner le formatage comme un contrat produit

Définissez quelles valeurs le navigateur formate, lesquelles un service renvoie déjà localisées et lesquelles doivent rester lisibles par machine. Plusieurs propriétaires du formatage peuvent mélanger des langues ou convertir deux fois. Une frontière claire permet de changer la présentation sans modifier les données sous-jacentes et stabilise les contrats du service.

Gardez quelques cas de test représentatifs pour chaque parcours pris en charge. Incluez au moins une date ordinaire, une heure proche d’une transition de fuseau lorsque la planification compte, un grand nombre ou un nombre fractionnaire, et une monnaie avec code explicite si le produit gère l’argent. Chaque cas doit valider un résultat nommé pour la personne. Ajoutez un cas lorsqu’un vrai échec révèle un nouveau risque ; évitez un catalogue de chaînes régionales arbitraires sans décision produit.

Dans un jeu de données synthétiques sur la monnaie, formatez la valeur 1234.5 en EUR avec la présentation en-GB, un code de devise explicite et deux chiffres fractionnaires. La personne doit comprendre un montant équivalent à 1234.50 euros et identifier EUR ; les variations d’espacement dues aux données locales ne font pas échouer le test, contrairement à un montant modifié ou à l’absence de libellé de devise. Si l’application ne prend en charge que l’anglais et le français et reçoit une préférence espagnole, le repli déclaré en anglais doit afficher le même montant et la même devise, et indiquer la langue actuellement utilisée.

Dans un cas de planification, gardez fixe l’instant 2026-01-01T01:30:00Z : en UTC, il correspond au 1er janvier 2026 à 01:30, tandis qu’en America/New_York, il correspond au 31 décembre 2025 à 20:30. Les deux vues doivent indiquer leur fuseau horaire et désigner le même instant stocké ; la ponctuation peut varier, mais un instant modifié ou un changement de date inexpliqué fait échouer le test.

Examinez le repli avec autant de soin que le chemin préféré. Une région demandée non prise en charge, une traduction manquante ou un échec du formateur doit quand même laisser la valeur et la tâche compréhensibles. L’interface doit indiquer la langue ou le format utilisé plutôt que mélanger silencieusement les variantes. La personne doit pouvoir revenir à un choix pris en charge.

Vérifiez le flux de données et la confidentialité lors de l’ajout d’outils de localisation ou de composants tiers. Un formateur exécuté dans le navigateur n’oblige pas l’application à envoyer un inventaire détaillé du navigateur à un autre service. Si un service reçoit des préférences linguistiques ou régionales pour une tâche légitime, documentez leur nécessité et leur durée de conservation. Ne réutilisez pas des préférences de présentation comme signal de ciblage caché.

L’internationalisation reste une responsabilité permanente de l’application. Intl évite de construire à la main de nombreuses règles de formatage propres à une langue, mais ne traduit pas le contenu du produit, ne définit pas le sens des valeurs stockées, ne choisit pas l’identité d’une personne et ne garantit pas des chaînes identiques dans tous les environnements. Traitez valeurs, préférences de présentation et sortie formatée comme des couches distinctes. Les personnes peuvent ainsi lire un texte familier sans perdre le contrôle de la tâche sous-jacente.

Sources publiques

• API d’internationalisation ECMA-402
• MDN : Intl