ADR 0037 – Internationalisation native : Intl et catalogues JSON

Statut : Décidée. Date : 30/09/2026. Applique les exigences EX-070 à EX-076 (lot 0).

Contexte

L’interface, les messages et les documents existent en français et en anglais (EX-070), la langue se choisit par utilisateur puis par entreprise (EX-072), et une troisième langue doit s’ajouter sans modifier le code (EX-076). Les formats (nombres, dates JJ/MM/AAAA, unités, montants en unités mineures) doivent être identiques dans le back-office, le terrain et l’API, sans flottant dans les calculs (ADR 0010).

Décision

packages/i18n, sans dépendance : Intl pour les nombres, dates, montants et pluriels ; un catalogue JSON par langue, à clés plates, dans src/catalogues/. Le français est la référence (type des clés, repli). Un script enregistre tout fichier {langue}.json : ajouter une langue se fait en déposant son fichier. Les fonctions sont pures : la date et le fuseau sont des paramètres, rien n’est mémorisé.

Alternatives écartées

• i18next + react-i18next : deux dépendances d’exécution, clés non typées, branchement React que les applications sans écran n’utilisent pas encore.
• Lingui, FormatJS : extraction et format ICU, au prix d’un outil de compilation de plus pour un catalogue de quelques dizaines de clés.

Conséquences

Pas de syntaxe ICU : pluriels par catégories CLDR (one, other…), paramètres {nom}. Les clés sont vérifiées à la compilation pour le français, et par des tests de parité pour les autres langues. L’API répond par codes ; les clients les traduisent.

Stratégie de sortie

Les catalogues sont des JSON à clés plates, lisibles par i18next ou par un outil de traduction ; seules les fonctions de traduire et de formatage sont à remplacer.