• gestion des parenthèses ?
  • autour du nombre - incertitude (pour le moment elles sont ajoutées si param ± et e, mais pas gérées lors de la saisie)
  • autour des unités en dénominateur
• gérer les monnaies ? €, $, £, M€, Mds€, EUR, USD,... ?
• gérer m{{3}}/s ? (non, à remplacer par m3/s dans les articles ; l'affichage est correct seule l'infobulle manque)
• test unitaire ou au moins tests d'un certain nombres de possibilité (Discussion Module:Unité/Test, Modèle:Unité/Test)

Sur une discussion concernant une infobox, en relation avec Catégorie:Page avec des arguments non numériques dans formatnum et Catégorie:Page incorrectement traitée par le Module:Unité, il a été évoqué la robustesse du modèle Unité à des syntaxes sortant de l'ordinaire, notamment avec la présence d'une référence dans un paramètre du modèle. En réalité, le comportement est étonnant.

• Exemple1 basique problématique : {{unité|42673 AB<ref>REF1</ref>C}} → 42 673 AB^[1]C
• Ex.2 simple ajout d'un <br> et l’affichage devient correct : {{unité|42673 A<br>B<ref>REF2</ref>C}} → 42 673 A
  B^[2]C
• Ex.3 ajout d'une balise différente, idem : {{unité|42673 A<ref>REF3</ref>B<div>C</div>}} → 42 673 A^[3]B
  C
• Ex.4 usage d'une ref nommée, on est bon dans les mêmes conditions : définition <ref name="zz">REF4</ref>^[4] puis appel {{unité|42673 A<ref name="zz"/>B<br>C}} → 42 673 A^[4]B
  C

Références

Le même test avec des références name=… ou group=… (ou d'autres balises moins pertinentes <pre>, <poem>, etc.) donne les mêmes résultats. {{Unité}} sollicite le Module:Delink qui appelle la fonction mw.text.unstrip reposant sur mw.text.killMarkers (cf. mw:Strip marker et Spécial:Recherche/QINU).

Il n'est pas certain que solliciter le modèle avec des balises <ref> soit une bonne pratique et qu'il faille l'autoriser et la mettre en œuvre dans des modèles, mais la différence de succès de l'affichage dans les exemples donnés n'est pas naturelle pour l'utilisateur.
Bonjour et bonne année @Od1n. As-tu une idée pour remédier à ces disparités de fonctionnement ? — Ideawipik (discuter) 1 janvier 2022 à 18:10 (CET)Répondre

J'ai commencé à chercher, pour l'instant je repère une différence au niveau du p.parseUnit() :

• {{unité|42673 AB<ref>REF1</ref>C}} :

table#1 {
  "42673",
  "AB?'\"`UNIQ--ref",
  "-00000002",
  "-QINU`\"'?C",
  ["prefix"] = "",
}

• {{unité|42673 A<br>B<ref>REF2</ref>C}} :

table#1 {
  "42673",
  "A<br>B?'\"`UNIQ--ref-00000007-QINU`\"'?C",
  ["prefix"] = "",
}

Le découpage est erroné dans le premier exemple (faux positif sur la partie « -00000002 »), et les caractères ajoutés dans les autres exemples font que cela empêche le faux positif.

od†n ↗^blah 2 janvier 2022 à 03:53 (CET)Répondre

Autre observation pendant que j'y pense : l'exemple 3 exécute un p.parseUnit() supplémentaire par rapport à l'exemple 2, en raison d'un match sur le « / » du </div> (voir ligne 672 ici). Il s'agit bien entendu d'un faux positif, qui là ne semble pas avoir d'impact sur le résultat, mais bon ce n'est pas idéal non plus… od†n ↗^blah 2 janvier 2022 à 04:12 (CET)Répondre

J'ai effectué ceci, mais je n'en suis pas vraiment satisfait. Comme indiqué dans le résumé de diff, le parsage des exposants n'est pas fonctionnel :

{{unité|10 cm²}} donne 10 cm²

{{unité|10 cm²<ref>foobar</ref>}} donne 10 cm²^[1]

Dans l'absolu, le parsage complet, avec gestion des strip markers afin qu'il n'affectent pas le parsage, devrait être réalisable, mais niveau code ça risque d'être bien compliqué…

Et comme je me disais justement quand je me suis penché sur le code de ce module, et comme il a aussi été évoqué dans la discussion que tu as mentionnée, et dans d'autres discussions encore, je serais plutôt partisan d'une réduction de la variété de syntaxes gérées par le modèle…

od†n ↗^blah 2 janvier 2022 à 05:25 (CET)Répondre

Je viens d'effectuer ceci. C'était en fait en prévision de pouvoir défaire 189464615 et implémenter le support des exposants lorsqu'une référence est présente, mais en fait ce n'est encore pas possible : même si on arrive à laisser passer le strip marker sans qu'il ne provoque de faux positif, il faut bien ensuite le mettre dans la table result, accolé/mélangé aux unit et aux exp, et forcément ça affecte les parsages en aval. Plus précisément, j'arrive à faire fonctionner la correction de la mise en forme du caractère « ² », mais pas l'infobulle « centimètre carré ». Donc, vu que ce n'est pas complètement maîtrisé, je reste sur 189464615, pour l'instant la moins pire solution. od†n ↗^blah 2 janvier 2022 à 07:36 (CET)Répondre

Bonjour Od1n et Ideawipik .

Avec ces dernières modification, le bug sur les rappels de références que j'ai signalé plusieurs fois (la dernière fois ici, avec d'autres soucis sur ce module) a été corrigé. Sauf qu'il y a un espace en trop :

{{unité|42673 A<ref name="zz"/>BC}} → 42 673 A^[1]BC

C'est déjà mieux, merci ! --FDo64 (discuter) 2 janvier 2022 à 10:20 (CET)Répondre

Voir Projet:Modèle/Demandes#Gestion des minutes d'arc dans le modèle « Unité ». Şÿℵדαχ₮ɘɼɾ๏ʁ 26 mars 2025 à 14:49 (CET)Répondre

Unité
Caractéristiques
Énergie/Poids	470 (pratique) 1 370 (théorique) Wh/kg
Énergie/Volume	1 480–9 780[réf. souhaitée] Wh/ℓ
modifier

Bonjour

Je viens de m'apercevoir que les unités ne sont pas insécables.

Si l'unité est complexe, elle peut se retrouver coupée en deux par le saut de ligne automatique, par exemple dans cette infobox (« Wh/kg » dans Énergie/Poids).

Bonne journée, Şÿℵדαχ₮ɘɼɾ๏ʁ, mercredi 15 avril 2026 à 14:01 (CEST)Répondre