La lib, et donc le plugin, fournit des choses tournant autour des "comportements régionaux" (c'est comme ça que traduit "locales" la doc de PHP en gros). La lib fournit les devises du monde, les locales du monde, un formateur de nombre, et un formateur de montant (c'est le précédent + une devise).
Donc on disait que le plugin devait contenir : une saisie devise, une saisie nombre, une saisie montant (et leur vue, basée sur la lib).
Oui oui, la lib c'est pour l'affichage, donc pour les vues, pour ce qui concerne les saisies (justement parce que le JS ne peut pas s'occuper de la vue). Mais donc tout ça va forcément ensemble à priori, si t'as la saisie faut la vue, et pour la vue faut la lib Intl (comme évoqué dans le ticket de saisie_nombre avec tcharlss). D'où le fait que les saisies (qui sont forcément dépendantes des comportements locaux aussi) devrait à priori être tout dans le même plugin avec la lib d'affichage, histoire de pas demander à avoir un plugin pour la vue et un plugin pour la saisie.
donc on est d'accord qu'il faudrait fusionner mon proto travail sur la partie saisie (js) avec ton travail sur la partie vue (php). Et du coup quid des réflexions qu'on avait commencé avec tcharlss sur la configuration yaml de la saisie "nombre" ?
question sur intl : c'est une librairie PHP. Quid de l'intégration avec la librairie JS AutonUmeric spip-contrib-extensions / saisie_nombre · GitLab, pour laquelle j'avais commencé à faire une saisie spécifique.
Faudrait-il pas qu'on essaie de mutualiser cela.
Je suis désolé, j'ai vraiment pas trop de temps pour SPIP en ce moment. Mais il faudrait qu'on en parle.
Maïeul
Puisqu'on parle de saisies, de formulaires, de nombres...