Devise - commentaires

Devise

Bonjour l'hyperlien Plaztika pointe sur un site bizarre.

Ce plugin est utilisé sur le site d'arts Plaztika, pour afficher le prix lorsqu'on sélectionne un tableau.

Devise

Bon du coup c'est compat 3.2 et passé en « test », comme ça c'est fait.

Devise

Hello,

Pour info, les devises sont gérées nativement dans la v1.1 du plugin API prix (encore en dev, mais ça devrait bientôt être passé en stable). Il ne s'agit pas encore d'une gestion complète multi-devises, mais ça prend déjà en charge tout ce que fait ce plugin et même plus (multilinguisme complet, etc.).

J'avais prévu de faire quelques évolutions sur le master pour le rendre au moins compatible spip 3.2 / php 7.2 (ça c'est fait) ainsi que d'autres évolutions éventuelles, mais du coup comme tout est déjà dans Prix je vais arrêter là.

Je pense que ça pourrait au moins être reporté dans la branche 3 (et la passer en stable).

Quand au évolutions futures de ce plugin quelques réflexions ici : https://git.spip.net/spip-contrib-extensions/devise/wiki/evolutions#user-content-version-4

Devise

Fonctionne t il en spip 3 ? Je ne le trouve pas ! Merci

Devise

En effet. C'est fait dans le dernier commit. Merci de l'indice ! Je vais effacer la question dans l'article, du coup.

Devise

Au sujet de « saisies »

Par ailleurs, dans la page de préférences d'un auteur, la sélection de la devise montre juste les codes à 3 lettres. Il serait plus agréable d'avoir les noms en toutes lettres, mais je n'ai pas trouvé de moyen de trier ça proprement.

Je crois qu'il faut créer une « vue » correspondant au type de saisie (devise) dans le répertoire extra-vue...

Devise

Je ne comprends pas bien pourquoi le travail serait à refaire : le plugin Prix pourra (et devra) déclarer une dépendance sur le plugin Devise, ce qui lui permettra d'utiliser les chaînes de langues fournies par ce dernier.

Devise

Ah... J'avais pas remarqué que le formatage de l'affichage des prix ne tenais pas compte de la devise (en fait j'ai rencontré des boutiques du continent qui affichaient leur prix en euros —avec le symbole à droite— et en dollars américains —avec le symbole à gauche—) mais effectivement avec ton exemple la position devient un formatage national (donc une information liée à un pays ou une région)

Je ne savais pas qu'il y avait un plugin prix, je vais y jeter un coup d'œil. Mais intégrer la position du montant dans doit se faire dans la chaine de langue ou alors les autres plugins seront obligés de dupliquer le travailler pour pouvoir faire une bonne intégration (même si c'est logiquement au plugin prix de proposer un filtre ou une balise associant montant et nom de devise, ce qui est un autre aspect qui ne devra qu'exploiter ces chaines de langue)

Devise

Je n'avais pas vu le champ position dans ta structure de table. Attention, une devise et un pays sont deux choses différentes, et la position du symbole monétaire est fonction du pays, pas de la devise. Par exemple certains pays écrivent « € 3.25 ».

Quant aux formatages de montants, je crois vraiment que <:devise:s_EUR :> doit continuer à renvoyer « euro » tout court, et comme tu le dis ça serait le rôle d'un filtre |montant de présenter ça. Par contre, tout cela est hors du rôle du plugin Devises, d'autant plus qu'un plugin Prix existe ; il n'intègre pas encore la notion de devise (il présuppose que tout est en euros), mais ses auteurs comptent changer ça. C'est donc sur ce plugin qu'il faut travailler si tu veux intégrer tes idées (bonnes au demeurant).

Devise

C'est vrai pour le nouveau fil... En fait le sujet ayant été abordé, j'ai enchainé sans trop réfléchir... Et entre temps j'ai complété ma réponse avant de voir la tienne.

C'est vrai aussi qu'il s'agit de constantes et que je suis sceptique aussi quand au fait de mettre en base, mais on manque de recul pour savoir ce qui est mieux (utiliser plus de ram et d'accès disques ou faire plus de requêtes SQL —ceci semble très à la mode quand je vois que de plus en plus de cms mettent quasiment tout en base...) Je pense que pays et devises vont servir de cas concret pour comparer les deux approches (théoriquement ils se défendent et ont leurs faiblesses) Pour ce qui est de la maintenabilité en bdd, c'est je pense lié à la structure qui fait un peu bloc pour être simple à l'usage (ce qu'on gagne d'un côté on le perd de l'autre ?)

Devise

Le champ position que je suggère dans la table indiquerait l'emplacement du symbole monétaire par rapport au nombre (en France par exemple on 12 € et aux États-Unis on a $ 12). Il serait donc bien que l'information soit disponible si certains veulent l'utiliser pour mieux localiser leur affichage.

Par contre, quand on utilise le nom complet, la position de celle-ci dépend de la langue (en français comme en anglais on a bien 12 euros/dollars/pesos/... mais dans d'autres langues ce sera euros/dollars/pesos/... 12) Cette information, lorsqu'on utilise les fichiers de langue doit être présente... Donc il serait plus pertinent que. par exemple, <:devise:s_EUR:> revoie directement un euro en français et one euro en anglais (enfin, l'idéal quand on a des nombres inférieurs à cent et qui ne sont pas trop long en texte, ou quand il s'agit juste d'un chiffre est de l'écrire en toutes lettres...) ; tandis que <:devise:p_EUR:> sera alors dans les deux cas @nbr@ euros
Par rapport à cela, il serait bien d'avoir un filtre |montant_devise qui comme son nom l'indique recevra un nombre et un code (idéalement dans cet ordre pour correspondre à son nom) et qui en fait ferait pour cet exemple [(#NOMBRE|singulier_ou_pluriel{devise:s_EUR, devise:p_EUR, nbr})]
Ou au lieu d'un filtre, on peut envisager plutôt une balise dynamique #MONTANT_DEVISE{code_devise,montant} (il revoie directement le singulier si le montant est 1 ou 0 et le pluriel sinon) voir mieux : #MONTANT_DEVISE{code_devise,montant_facultatif} (quand le montant est omis, on renvoie juste le nom de la devise, ici comme si on avait fait <:devise:EUR:>)
Finalement, les fichiers de langue peuvent permettre des trucs intéressants ; et le plugin peut être très utile sans avoir à gérer les les liaisons avec les différents objets (ce qui en soit n'a pas de sens puisqu'il ne s'agit pas d'un objet à lier à d'autres mais juste des données à exploiter)

Devise

Je n'aime pas l'approche du plugin Pays justement, car selon moi la base de données ne doit pas servir à fournir des constantes, et par ailleurs passer par multi est tout sauf maintenable.

Pour ces raisons je préfère passer par des fichiers de langue, mais ça pose quand même la question de l'utilisation en RAM (mais il faudrait faire des tests pour voir si c'est si horrible que ça). SPIP manque d'un mécanisme pour gérer ce genre de listes (pays et devises sont deux bons exemples de ce besoin).

Par contre, tu aurais dû créer un nouveau fil pour ce point, car ça n'a rien à voir avec le sujet initial.

Devise

Pour la table en bdd, on peut (comme le fait le plugin pays) avoir simplement

spip_devises( code CHAR(3 NOT NULL), nom TEXT NOT NULL, symbole VARCHAR(10) NOT NULL, position BOOL, PRIMARY KEY(code)
)

où nom contient [fr]nom en français[en]english name[??].... Du coup on récupère le nom et/ou le symbole (qui sera l'entité HTML nommé ou en code décimal car toutes les bases et tous les sites ne sont pas forcément en Unicode —UTF8 ou autre) dans une petite boucle à laquelle on passe le code :-)

Mais l'approche par fichier de langue est intéressante aussi (et peut-être meilleure à l'usage car utilisable aussi bien dans les squelettes SPIP via <:devise:le_code: qu'en PHP avec :_T('devise/le_code')...)

Devise

Et oui, on peut avoir besoin des devises sur tous les objets : articles/produits, catégories/rubriques, auteur/(re)vendeur/fournisseur/client/acheteur, etc. Et pour l'interface, je pense qu'il faut faire pareil pour ces trois objets de base (auteurs, articles, rubriques) : ajouter un champ et le gérer via ChampsExtra2 :-) Ceci dit, il ne faut pas trop se préoccuper de l'interface car c'est à chaque plugin de proposer l'interface qui lui convient ; je vois plus ce plugin comme une brique logicielle pour avoir centraliser la traduction des noms et les proposer aux plugins qui utilisent les codes monétaires ISO, un peu comme le fait le plugin pays. :-) (qui ne gère pas de tables de liaison !)
La variable/valeur globale/méta permettra juste d'avoir une devise pour tout le site, utile pour ceux qui n'ont pas besoin d'avoir des devises différentes pour chaque auteur ou article (tous les besoins étant possibles)

Devise

Oui. Il va y avoir aussi le besoin d'avoir des devises sur les produits (voir plugin Produits en cours de développement).

Peut-être que le plus pertinent serait une table spip_devises avec des champs objet, id_objet, devise, pour généraliser à la fois :

les devises par auteur (choix somme toute très arbitraire, correspondant à mon besoin propre),
les devises sur les produits,
les devises sur les rubriques, où la devise du site reviendrait à poser une devise sur la rubrique 0,
et plus généralement sur tous types d'objets, par exemple tout bêtement par article si quelqu'un en a le besoin

Par contre en termes d'interface dans l'espace privé il faut réfléchir à comment présenter ça...

Devise

outre les auteurs, ne serait-il pas pertinent d'avoir une devise globale (pour tout le site) configurable (enregistré comme méta) qui serait la devise par défaut ? (valeur de la balise employée hors contexte ou si pas de devise spécifiée)