Devise

Permet de gérer dans les squelettes les monnaies étrangères en fournissant des noms de monnaies en toutes lettres.

Permet également de définir une devise préférée pour les auteurs.

Sur des sites où on utilise des prix, il peut être utile de disposer de noms de monnaies. Ce plugin fournit donc les noms de toutes les monnaies du monde (y compris Bitcoin), ainsi que quelques outils pour les manipuler. Actuellement, ces noms sont disponibles en français, anglais et espagnol.

Un champ « devise » est également ajouté à la table auteurs. La valeur de ce champ est le code ISO 4217 de la monnaie choisie.

Ce plugin nécessite les plugins Champs Extras 2 et Saisies pour fonctionner.

Dans l’espace privé du site

Dans la page de préférences d’un auteur, il est possible de remplir le champ « Devise préférée » afin d’associer une devise à un auteur. La signification exacte de cette association peut varier suivant les cas ; elle est laissée à l’appréciation du ou de la webmestre.

Utilisation générale dans les squelettes

Dans tout le site, il est possible d’utiliser directement les chaînes de langues fournies. Par exemple :
-  <:devise:EUR:> renvoie le nom de la monnaie dans la langue du contexte. Par exemple : Euro
-  <:devise:s_EUR:> renvoie le nom de la monnaie au singulier pour un prix. Par exemple, 1&nbsp;<:devise:s_EUR:> affichera « 1 euro ».
-  <:devise:p_EUR:> renvoie le nom de la monnaie au pluriel pour un prix. Par exemple, 42&nbsp;<:devise:p_EUR:> affichera « 42 euros ».

Utilisation dans une boucle AUTEURS

Dans une boucle AUTEURS, il est possible d’utiliser la balise #DEVISE pour récupérer le code à 3 lettres de la monnaie choisie par cet auteur.

Dans le cas (probable) où l’on souhaite afficher le nom de la monnaie en toutes lettres (et dans la langue du contexte), les modèles suivants sont tout indiqués :
-  #MODELE{auteur_nom_devise} fournit le nom général de la devise (Euro, Dollar des États-Unis, etc.)
-  #MODELE{auteur_devise_singulier} et #MODELE{auteur_devise_pluriel} permettent d’utiliser le nom dans un prix.

Dans une boucle POUR

La balise #DEVISES renvoie un tableau contenant tous les codes à 3 lettres des monnaies disponibles. Ceci permet de l’utiliser par exemple dans une boucle POUR si jamais SPIP-Bonux est installé.

Fonctions PHP et filtres

Deux fonctions/filtres sont fournies.

formater_devise($devise, $format) ou |formater_devise{format} permet d’afficher un nom de devise de façon personnalisée. Le format peut utiliser les codes suivants :
-  %C : code ISO de la devise.
-  %N, %sN, %pN : son nom en toutes lettres : générique, singulier ou pluriel.
-  %% : signe « % ».

devises_codes([$description]) renvoie un tableau avec les codes ISO de toutes les devises connues. Si une description est fournie et contient les codes décrits plus haut, c’est un tableau associatif qui est renvoyée, avec pour clés les codes ISO et pour valeurs la description demandée.

Saisie

Le plugin fournit également une saisie devise, pour faciliter la création de formulaires. Ses paramètres sont ceux de la saisie « selection »

Améliorations possibles

Il serait fort pratique d’intégrer une fonction de conversion en temps réel (par exemple en utilisant un webservice), pour s’adapter aux variations de taux de change. Ceci permettrait de fournir des prix dans la devise choisie par le visiteur.

Exemple

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

Discussion

5 discussions

  • liberte

    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.

    Répondre à ce message

  • 1

    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

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

    Répondre à ce message

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

    Répondre à ce message

  • 1

    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...

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

    Répondre à ce message

  • 9

    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)

    • 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...

    • 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)

    • 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)
      )

      nom contient <multi>[fr]nom en français[en]english name[??]...</multi>. 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')...)

    • 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.

    • 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&nbsp;euro en français et one&nbsp;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@&nbsp;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)

    • 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 ?)

    • 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).

    • 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)

    • 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.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom