Un montant qui change lorsque la langue est modifiée, une date qui s’affiche au mauvais jour ou une traduction qui altère une règle commerciale révèlent souvent le même problème : l’application confond les données et les choix de présentation. L’internationalisation des dates et des devises en PHP exige de traiter séparément la langue, les paramètres régionaux, la devise et le fuseau horaire, et de définir quelle valeur le système conserve par rapport à la représentation affichée à chaque utilisateur.
Cette séparation facilite l’ajout de régions sans dupliquer les règles métier ni réinterpréter les données historiques. Elle aide également à localiser l’origine des erreurs : elles peuvent provenir de la saisie de l’utilisateur, de la persistance, d’une conversion de fuseau horaire ou uniquement du formatage en sortie.
La langue, le locale, la devise et le fuseau horaire sont des choix distincts
La langue détermine le texte de l’interface et le contenu traduisible : libellés, messages de validation et noms de produits, par exemple. Un locale, ou paramètre régional, définit les conventions de présentation, comme les séparateurs décimaux, l’ordre des éléments d’une date et les noms des mois. Il ne correspond pas toujours à une langue : deux régions qui partagent une langue peuvent utiliser des formats différents.
La devise identifie l’unité dans laquelle un montant est exprimé, comme EUR ou JPY. Elle ne peut pas être déduite de manière fiable de la langue ou du locale. Une personne peut consulter l’interface en espagnol, utiliser un format régional donné et effectuer un achat dans une autre devise. Le fuseau horaire définit quant à lui le rapport entre l’heure locale et le temps universel, ainsi que les changements d’heure d’une région.
Il est préférable de modéliser explicitement ces préférences. Par exemple, un compte peut avoir une langue et un fuseau horaire ; une session peut fixer une préférence de format ; et chaque commande doit conserver la devise effectivement utilisée. Les valeurs autorisées et leurs valeurs par défaut doivent relever de décisions produit, et non d’inférences silencieuses fondées sur la localisation réseau.
Que stocker et que calculer pour l’affichage
Enregistrez les données nécessaires pour reconstituer le fait d’origine, et pas seulement une chaîne déjà formatée. Une date de création représente un instant ; une représentation comme « 03/04/2025 » est ambiguë et ne constitue pas une bonne représentation canonique. Pour les événements mondiaux, il est souvent pratique de stocker l’instant en UTC et de conserver le fuseau horaire pertinent lorsque le contexte en dépend, comme pour un rendez-vous fixé dans une ville donnée.
Dans une application PHP, DateTimeImmutable aide à éviter les modifications accidentelles pendant les conversions. Convertissez l’instant dans le fuseau horaire choisi lors de la préparation de la réponse, sans remplacer la donnée persistée. Utilisez des identifiants de fuseau reconnus, comme Europe/Madrid, plutôt que d’enregistrer un décalage fixe comme +01:00 : celui-ci ne comprend ni les règles historiques ni les changements saisonniers.
Pour le format régional, conservez une étiquette de locale valide pour la bibliothèque et l’environnement utilisés, et gérez explicitement les préférences non prises en charge. Les fonctions de intl, comme IntlDateFormatter et NumberFormatter, permettent d’appliquer les conventions locales sans concaténer manuellement les séparateurs et les noms de mois. Vérifiez que l’extension est disponible dans les environnements où l’application s’exécute.
Dates et heures : conversions et cas ambigus
Les instants enregistrés par le système et les heures civiles ne sont pas interchangeables. Un instant comme « 2025-04-10T15:00:00Z » représente un point sans ambiguïté. En revanche, « 2025-10-26 à 02:30 dans Europe/Madrid » peut être ambigu lors du passage à l’heure d’hiver, car cette heure locale peut se produire deux fois. Lors du passage à l’heure d’été, certaines heures locales peuvent aussi ne pas exister.
Pour programmer une action à une heure locale future, ne stockez pas uniquement un timestamp calculé une seule fois si l’engagement porte sur l’heure locale d’une région. Conservez la date et l’heure demandées, le fuseau horaire et une politique de résolution des heures inexistantes ou répétées. La décision — rejeter, demander une précision ou choisir l’une des occurrences — dépend du produit. En revanche, pour un événement déjà survenu, enregistrez l’instant effectif.
Définissez également la manière dont vous interprétez les dates reçues dans les formulaires et les API. Acceptez les formats documentés, validez le fuseau horaire et rejetez les saisies ambiguës au lieu de deviner si « 04/05/2025 » signifie avril ou mai. Dans les interfaces, affichez une représentation lisible, mais conservez la donnée canonique pour le tri, la comparaison et l’audit.
Montants : précision, devise et format
Le format visible ne doit pas devenir la source de vérité financière. Évitez d’utiliser des nombres à virgule flottante binaire pour les calculs monétaires : certaines fractions décimales n’ont pas de représentation exacte et peuvent entraîner des erreurs d’arrondi. Une stratégie courante consiste à stocker les montants en unités mineures entières, avec le code de devise. Toutefois, toutes les devises n’utilisent pas deux décimales, et certains calculs nécessitent davantage de précision intermédiaire que le montant final facturé.
Définissez la précision et le moment de l’arrondi en fonction des règles métier : par ligne, par taxe ou sur le total. Maintenez la devise explicitement dans les commandes, les paiements, les remboursements et les calculs ; n’interprétez pas un nombre sans connaître la devise à laquelle il se rapporte. Si vous convertissez des devises, conservez également les données permettant d’expliquer la conversion, comme le taux appliqué et la date de référence, lorsque ces éléments sont pertinents pour l’opération.
Pour afficher le montant, transmettez la valeur numérique et le code de devise au formateur régional approprié. La représentation peut varier en fonction des symboles, de leur position et des séparateurs. L’utilisateur doit pouvoir identifier la devise sans dépendre d’un symbole susceptible d’être ambigu. N’analysez pas une chaîne localisée comme s’il s’agissait d’un nombre universel : validez la saisie et convertissez-la en une représentation numérique contrôlée avant de la traiter.
Traduire le contenu sans dupliquer les règles métier
Traduisez les textes et adaptez les formats, mais centralisez les règles qui déterminent les prix, les taxes, l’éligibilité, les autorisations ou les états. Dupliquer la logique par langue crée des comportements divergents difficiles à repérer. Le choix d’un tarif peut dépendre du marché, du contrat ou d’une politique commerciale ; il ne doit pas changer uniquement parce que le libellé de l’interface a changé.
Séparez les catalogues de traduction de la logique métier. Pour les contenus modifiables et localisés, indiquez quelles versions peuvent exister, comment gérer celles qui manquent et quel comportement de repli appliquer. Un nom traduit ne devrait pas remplacer un identifiant stable. Dans les API, indiquez si les champs contiennent des valeurs canoniques, du contenu localisé ou des formats déjà préparés pour l’affichage.
Tests et déploiement progressif de la prise en charge régionale
Testez les décisions à plusieurs niveaux. Les tests unitaires doivent vérifier les conversions de fuseau horaire, la validation des dates, l’arrondi et le formatage des montants. Incluez des cas aux limites d’un jour, les transitions liées aux changements saisonniers, les heures répétées ou inexistantes, les mois de durées différentes et les devises ayant des précisions différentes. Ne dépendez pas du locale ou du fuseau horaire par défaut de la machine de test : configurez-les explicitement.
Les tests d’intégration doivent confirmer que l’API persiste les données canoniques et que l’interface les présente selon les préférences définies. Vérifiez également les saisies mal formées, les locales inconnus, les changements de préférence et l’absence de l’extension nécessaire. En cas de mise à jour des bases de fuseaux horaires, examinez les processus qui programment des événements futurs ainsi que les résultats attendus.
Activez progressivement les régions : définissez d’abord les données et les règles, testez ensuite les formats et les parcours complets, puis activez l’expérience pour le public visé. La surveillance des erreurs de validation, des écarts d’arrondi et des tâches exécutées en dehors des horaires prévus aide à détecter des défaillances qu’une capture d’écran ne révèle pas.
Liste de vérification
- Langue : Est-elle séparée du locale et existe-t-il une politique de repli ?
- Dates : Distingue-t-on un instant d’une heure locale programmée ?
- Fuseau horaire : Les identifiants régionaux sont-ils enregistrés et les heures ambiguës sont-elles résolues ?
- Montants : Chaque montant est-il associé explicitement à une devise et à des règles de précision définies ?
- Présentation : Le formatage utilise-t-il les outils appropriés, sans jamais utiliser le texte affiché pour effectuer des calculs ?
- Tests : Les limites de jour, les changements d’heure, les saisies invalides et les différentes préférences sont-ils couverts ?
- Exploitation : La configuration de PHP est-elle vérifiée et la prise en charge régionale est-elle déployée de manière contrôlée ?
L’essentiel est de maintenir une frontière claire entre la donnée comprise par le système et la manière dont chaque personne la voit. Grâce à cette séparation, l’internationalisation des dates et des devises en PHP devient un ensemble de règles vérifiables, plutôt qu’une collection d’exceptions dispersées dans l’application.
