ajouter 2 microdata: itemprop="price" et itemprop="priceCurrency" directement dans le retour de montant_formater(),
https://git.spip.net/spip-contrib-extensions/intl/src/branch/master/intl_fonctions.php#L152
Dans l'exemple de la doc de schemas.org:
```
<span itemprop="price" content="1000.00">1,000.00</span>
<span itemprop="priceCurrency" content="USD">$</span>
```
dans la propriété itemprop="price" mettre un nombre flottant à 2 decimal dans un content pour ne pas toucher au prix de l'affichage
dans la propriété itemprop="priceCurrency" dans un content afficher l'abréviation de la devise,
avec la balise` <meta> `ça donne ça:
```
#PRIX
<meta itemprop="price" content="[(#PRIX*|number_format{2})]" />
<meta itemprop="priceCurrency" content="[(#REM|intl_devise_defaut)]" />
```
Merci pour la suggestion.
Bonne idée de mettre ça part défaut, ça éviterait d'avoir à ajouter ces microdatas à chaque fois.
Pour ma part je ne vois pas de contre-indication, à part un doute pour certains cas particuliers.
Dans l'exemple de schema.org, le montant et la devise sont dans des spans séparés.
La plupart du temps dans notre markup c'est pareil, sauf certains cas particuliers où le span de la devise est encapsulé dans celui du montant.
Par exemple, dans certaines langues les nombres négatifs en format comptable sont affichés ainsi : (CAD123,456.78)
Est-ce que ça ces cas poseront problème ? @rastapopoulos tu en dis quoi ?
Glop,
Merci pour la suggestion.
Bonne idée de mettre ça part défaut, ça éviterait d'avoir à ajouter ces microdatas à chaque fois.
Pour ma part je ne vois pas de contre-indication, à part un doute pour certains cas particuliers.
Dans [l'exemple de schema.org](https://schema.org/price), le montant et la devise sont dans des spans séparés.
La plupart du temps dans notre markup c'est pareil, sauf certains cas particuliers où le span de la devise est encapsulé dans celui du montant.
Par exemple, dans certaines langues les nombres négatifs en format comptable sont affichés ainsi : `(CAD123,456.78)`
Et le HTML :
```html
<span class="montant" data-montant-nombre="-123456.78" data-montant-devise="CRC">(<span class="montant__devise">CRC</span>123,456.78)</span>
```
Est-ce que ça ces cas poseront problème ?
@rastapopoulos tu en dis quoi ?
Quand on n'est pas sûr du HTML, qu'il peut bouger, il y a la balise meta comme @laeta le signale déjà. Donc si on veut pas se faire chier, on met juste les balises meta à l'intérieur et basta :)
Quand on n'est pas sûr du HTML, qu'il peut bouger, il y a la balise meta comme @laeta le signale déjà. Donc si on veut pas se faire chier, on met juste les balises meta à l'intérieur et basta :)
ajouter 2 microdata: itemprop="price" et itemprop="priceCurrency" directement dans le retour de montant_formater(),
https://git.spip.net/spip-contrib-extensions/intl/src/branch/master/intl_fonctions.php#L152
Dans l'exemple de la doc de schemas.org:
dans la propriété itemprop="price" mettre un nombre flottant à 2 decimal dans un content pour ne pas toucher au prix de l'affichage
dans la propriété itemprop="priceCurrency" dans un content afficher l'abréviation de la devise,
avec la balise
<meta>ça donne ça:Glop,
Merci pour la suggestion.
Bonne idée de mettre ça part défaut, ça éviterait d'avoir à ajouter ces microdatas à chaque fois.
Pour ma part je ne vois pas de contre-indication, à part un doute pour certains cas particuliers.
Dans l'exemple de schema.org, le montant et la devise sont dans des spans séparés.
La plupart du temps dans notre markup c'est pareil, sauf certains cas particuliers où le span de la devise est encapsulé dans celui du montant.
Par exemple, dans certaines langues les nombres négatifs en format comptable sont affichés ainsi :
(CAD123,456.78)Et le HTML :
Est-ce que ça ces cas poseront problème ?
@rastapopoulos tu en dis quoi ?
Quand on n'est pas sûr du HTML, qu'il peut bouger, il y a la balise meta comme @laeta le signale déjà. Donc si on veut pas se faire chier, on met juste les balises meta à l'intérieur et basta :)
Alors va pour les meta.
Ça sera dans la prochaine release @laeta
Du coup PR !3
C'est intégré dans la v1.0.4 @laeta
7 mois de délai, bonne moyenne :)