Discussion modèle:Unité

Virgule

Bonjour
Il faudrait soit régler le problème des virgules (elles ne sont pas affichées), soit signaler que ce problème existe en tête de la documentation. Merci !! (et merci pour ce modèle qui permet d'éviter les & nb sp; ) —MACROECO ^{me parler} 4 septembre 2007 à 10:45 (CEST)

C'est indiqué dans la documentation du modèle. J'ai mis en gras les termes relatifs. Daniel D {°.°} 5 septembre 2007 à 01:35 (CEST)

Pourquoi faire simple quand on peut faire compliqué :) - Wikig | talk to me | 19 octobre 2007 à 09:44 (CEST)

Wikilien

Bonjour, a t'il déjà été envisagé de faire automatiquement des wikiliens sur les unités les plus couramment utilisé? --Riba-- (d) 29 novembre 2007 à 01:43 (CET)

Problème: si on insère toujours le lien, cela ne marchera pas avec toutes les unités, ou donnera un lien non signifiant vers une page d'homonymie. Sinon il faudrait tester les valeurs de chacune des unités mentionnées, dans un switch pour chacun des paramètres contenant des unités. Ce qui serait vraiment très lourd, même si on utilisait un sous-modèle utilitaire.

Mais est-ce utile de mettre ce lien partout quand ce modèle pourrait être utilisé de façon répétitive dans une page? Si on veut un lien, autant le mettre là où c'est utile dans un des paramètres mentionnant une unité (paramètres 2, 4, 6 et/ou 8). Et pas la peine d'alourdir ce modèle très fréquent. Par exemple:

{{Unité|1001.23|[[mètre|m]]}} donnera « 1 001,23 m » ; on ferait la même chose dans un article pour créer un lien de toute façon. Il faut se méfier de la génératon automatique de liens, pas forcément pertinents ni évidents à maintenir ensuite (quand les articles liés sont renommés, fusionnés, scindés...), des liens parfois aussi ambigus pour des noms ou symboles abrégés de monnaies qu'on n'a pas vocation à citer partout de façon répétitive sous leur désignation longue complète. Verdy p (d) 15 janvier 2008 à 04:02 (CET)

Ok... --Riba-- (d) 20 janvier 2008 à 23:45 (CET)

Message d'avertissement si deuxième paramètre manquant

Est-il possible de modifier ce modèle pour qu'il affiche un message d'avertissement si le 2^e paramètre, obligatoire, manque ? Voyez plutôt : {{Nombre avec unités|2000}} unités donne « 2 000  unités ». un espace est inséré entre 2000 et unités.

▪ Sherbrooke (✎✎) 19 mai 2008 à 05:58 (CEST)

 Fait. —C.P. 19 mai 2008 à 16:30 (CEST)

Quel est le problème causé par l'absence du 2^e paramètre ? Si des gens utilisent ce modèle à la place du modèle formatnum:, ce n'est pas très grave, si ? Enfin, bon faites ce que vous voulez, mais il y a de nouveaux articles dans Catégorie:Page utilisant un modèle avec une syntaxe erronée... –MaCRoEco [oui ?] 19 mai 2008 à 16:38 (CEST)

La Catégorie:Page utilisant un modèle avec une syntaxe erronée est de nouveau (presque) vide... Utiliser « {{nombre avec unité}} » pour un nombre sans unité me parait curieux, mais si on insiste, il est possible de coder le modèle en permettant cet usage peu orthodoxe tout en évitant le problème de l'espace supplémentaire mentionné par Sherbroooke. —C.P. 19 mai 2008 à 18:57 (CEST)

À mon sens, vouloir utiliser {{nombre avec unité}} sans unité tient du non sens, ce serait incorrect au niveau sémantique (de la même façon, il serait incorrect d’utiliser « {{{1}}} » juste pour mettre des guillemets alors qu’il ne s’agirait pas d’une citation…). Il faut utiliser {{formatnum:}} si on désire formater un nombre sans unité. — MetalGearLiquid ^{[m’écrire]} 25 septembre 2008 à 19:33 (CEST)

 MetalGearLiquid et Cépey j'ai du mal m'exprimer : les modèles fonctionnent correctement mais la documentation ne le mentionne que dans les exemples et pas dans le tout-début de la doc, d'où le risque de malentendu qui m'est arrivé ... Pano38 (discuter) 11 février 2023 à 16:27 (CET)

@Pano38, la discussion de cette section date de plus de 14 ans, et elle est caduque, car le modèle a beaucoup évolué depuis. Effectivement, il n’y a aujourd’hui plus de problème technique à utiliser {{unité}} avec un nombre seul, mais sémantiquement, son synonyme {{nombre}} est plus approprié, et la doc mérite d’être améliorée. —C.P. 11 février 2023 à 20:32 (CET) — Pour être tout-à-fait clair : La discussion de cette section supposait que, lors de l’utilisation du modèle avec un seul paramètre, ce paramètre était un nombre seul. Ce n’est plus le cas aujourd’hui. —C.P. 11 février 2023 à 21:34 (CET)

English template equivalents

The similar English templates (en:Category:Unit display) should be referenced by this template.   — C M B J   19 mai 2008 à 10:21 (CEST)

Taille des chiffres en exposant

Je suis tombé sur un article bien écrit (Mont Kenya) qui utilise ce modèle et la lecture d'une unité m'a étrangement choqué. J'ai modifié mais le modèle à l'air utilisé sur le reste de l'article et surement ailleurs, du coup j'ai des doutes et me demande si c'est correct. Je trouve les chiffres en exposant du modèle bien trop grand de corps et peut-être trop « haut » (cf.km² vs. km²). Pour une unité plus complexe, il y a moins ce problème de lecture, surtout quand l'unité en elle-même est en capitale, mais les unités de surface (et volume) sont très courrantes dans les articles. Il est vrai que les chiffres 0, 1, 4 à 9 en exposant ne sont fréquement pas bien supportés par toutes les polices (cf. ⁰¹⁴⁵⁶⁷⁸⁹). Faut-il proscrire l’utilisation du carré « ² » disponible sur l'azerty français dans les articles — ou du « ³ » sur le clavier azerty belge ? Est-il possible de réduire la taille des exposants dans le modèle ? A2 (d) 8 septembre 2008 à 09:55 (CEST)

En effet, je pense souhaitable de revoir quelque peu la taille et position des exposants (il faut que ça reste lisible bien entendu), en outre cela pose également problème lorsqu’un nombre suivi d’unité avec exposant est suivi d’une note ou référence, par exemple {{unité|123456|km|2}}<ref>source / référence ou note</ref> provoque un affichage prêtant à la confusion :

123 456 km² ⇒ faut-il lire km avec note n^o 21 ou km² avec note n^o 1 ? certes km²¹ ne semblera pas très logique, et le lecteur devinera qu’il s’agit de km² + note 1 ; en revanche pour en lisant 6,02×10²³ faut-on référence au nombre d’Avogadro ou au nombre 602 ? + note 3 ?

… alors que sur la wikipédia anglophone, le problème ne se présente pas, du fait que les n^o  de réf. sont affichés entre crochets.

Ceci dit, ma préférence va à l’utilisation du modèle {{nombre avec unité}} plutôt qu’à celui des ² et ³. De plus, il existe également un caractère Unicode dédié : ㎢ = U+33A2 (probablement très très mal supporté ! Et dont l’affichage est probablement peu clair dans une bonne part des polices de caractères qui le proposent) — MetalGearLiquid ^{[m’écrire]} 25 septembre 2008 à 19:49 (CEST)

Espace fine

En principe, il faudrait utiliser une espace fine insécable et non & nbsp; entre le nombre et l’unité. Compte tenu du manque de support de l’espace fine insécable par bon nombre de logiciel, ne faudrait-il pas utiliser un & nbsp; dont la taille serait réduite de moitié environ, cf. cette référence ; et ce jusqu’à une adaptation des logiciels, dans les années et décennies qui suivront. — MetalGearLiquid ^{[m’écrire]} 25 septembre 2008 à 19:49 (CEST)

C’est déjà une espace insécable (nbsp) qui est utilisé, non ? Cdlt, VIGNERON * ^discut. 9 octobre 2008 à 17:36 (CEST)

Oui, mais… c’est une espace insécable et non une espace fine insécable… — MetalGearLiquid ^{[m’écrire]} 7 mars 2009 à 21:12 (CET)

Je ne suis pas sûr d'avoir bien compris ; tu proposes de faire un   entouré d'un span qui réduise sa taille de moitié ? — Delhovlyn » (discuter) 22 avril 2009 à 18:00 (CEST)

Oui, c'est ce qu'il propose. Mais je ne suis pas favorable à la bidouille :

• soit on utilise l'espace fine insécable (quels logiciels ne le supportent pas ?)
• soit on reste avec l'espace insécable

Gentil ♥ (d) 23 avril 2009 à 19:48 (CEST)

Je crois qu'il est obligatoire d'utiliser “XXX^YY&nbthinspU^ZZ, c'est à dire une espace fine insécable, conformément aux conventions. De plus, j'ai testé sur 5 logiciels (firefox, explorer, safari, netscape et konkeror, tous supportent le caractère !) Pic-Sou 13 août 2009 à 12:12 (CEST)

L’utilisation de l’espace fine plutôt que l’espace normale est une convention typographique, non universelle ; ce n’est pas une obligation. De plus, c’est un détail perceptible par une minorité d’utilisateurs. Quelques remarques :

• L’espace fine peut être utilisée dans « 12 m », encore que ce n’est pas une convention universelle ; elle ne doit pas être utilisée lorsque l’« unité » est en toutes lettres comme dans « Lampe très basse tension, c’est-à-dire inférieure à 50 volts », selon une utilisation assez courante de {{unité}} sur WP (j’ai repéré cet exemple dans Lampe à incandescence halogène). Il vaut donc mieux s’abstenir de mettre une espace fine entre le nombre et l’unité.
• On peut considérer de mettre une espace fine au lieu d’un point multiplicatif entre les différentes unités pour faire plus joli (ici, je ne vois pas de contre-indication).
• Il faut de toute manière rendre l’expression entière insécable, plutôt que de se limiter aux seules espaces, pour éviter une rupture de ligne au niveau du « - » dans des expressions comme : 3 m⁻¹ (phénomène que j’ai déjà rencontré). Techniquement, cela se fait facilement en entourant toute l’expression par « <span style="white-space:nowrap">...</span>  ».

—C.P. 13 août 2009 à 14:02 (CEST)

Espace étroite insécable

Bien que ce soit peu connu, même des typographes chevronnés (personnellement, après avoir parcouru le web typographique en long, en large et travers des années durant, ce n'est que par accident et tout seul que je l'ai trouvé). [Espace « fine » insécable], nommée « espace étroite » par Unicode. Son code est  

J'envisageai de modifier le modèle en conséquence, mais je préfère laisser une discussion s'établir avant. Notez que si l'espace fine insécable est acceptée, il faudra retirer la mention de l'inutilité du modèle avec le pourcentage.--
David Latapie (✒ | @) — www 27 juillet 2010 à 22:42 (CEST)

Avis défavorable, voir les objections ci-dessus. Par ailleurs, une simple observation : dans la taille par défaut et avec une police courante (sous Windows), la différence de largeur entre les espaces de 4 m (insécable) et de 4 m (fine insécable) est... nulle. Avec une taille de caractère agrandie de 20%, elle est... d'un seul et unique pixel. Il faut attendre un agrandissement de la taille de caractère de 100% pour que cette différence atteigne 2 pixels.

Avant de transposer au Web des usages historiques de l'imprimé, il faut s'interroger sur leur pertinence. Cordialement, --Lgd (d) 29 juillet 2010 à 07:00 (CEST)

Quid des ares ?

Comment utiliser ce modèle pour les surfaces en hectares et ares ? Par exemple : 62 ha 10 a. Je pense qu’il doit exister de nombreuses autres unités dans le même cas (degré-minute notamment). Cdlt, VIGNERON * ^discut. 9 octobre 2008 à 17:36 (CEST)

Apriori il faut utiliser le modèle deux fois pour le moment. Le degré et ses sous-unités sont un cas particulier, ils n'ont pas besoin d'espace, par exemple 8°32′7″. Quelqu'un peut-il s'occuper de ce modèle, il y a plusieurs points relevés sur cette page de discussion qui mériteraient d'être corrigé. A2 (d) 9 octobre 2008 à 18:16 (CEST)

Multiplication

Le modèle utilise l'opérateur puce « ∙ » (U+2219 bullet operator) comme symbole de la multiplication entre les unités, pourtant les articles « point médian » et « produit (mathématiques) » préconisent l'utilisation de l'opérateur point « ⋅ » (U+22C5 dot operator). Les deux ressemblent au point médian « · » (U+00B7 middle dot), j'ai d'ailleurs corrigé sur ces articles. Ce modèle affichant les nombres décimaux avec une virgule, l'utilisation d'un point « simple » sur la ligne et non médian semble préférable. 9,81 m.s^-2 vs 9,81 m s⁻². Au passage on remarque à nouveau que les exposants du modèle sont plus haut que ceux des balises . –A2 (d) 9 octobre 2008 à 19:09 (CEST)

Il ne faut pas utiliser <sup></sup> mais <span class="exposant"></span>.

En ce qui concerne l'utilisation du bullet operator, du dot operator ou d'un quelconque autre point, je pense qu'il faudrait voir l'atelier TeX, ou un autre lieu de discussion plus approprié. De mon côté, je ne sais quelle est la norme — Steƒ ^{(  Стеф  )} 10 octobre 2008 à 13:54 (CEST)

Je ne vois pas le rapport avec l'atelier Tex. Et pourquoi utiliserais-je des balises très longues à taper alors que le carré est disponible sur le clavier (et d'ailleurs les autres exposants aussi) ? C'est justement l'intérêt du modèle que de simplifier l'édition des articles pour les utilisateurs ! Il y a un problème avec les points qui ne devraient pas être médian, les exposants trop gros/mal placé et peut-être les espaces (fine ou pas ? à vérifier). Pour les exposants à nouveau, voir ces exemples suivis d'une référence :

• avec span : km2
• avec sup : km²
• avec ² : km²
• avec le modèle : km²

Comme l'a fait remarqué MetalGearLiquid, avec le modèle il y a une confusion possible. Le modèle n'a pas l'air bien compliqué. Si personne n'a le courage de se jeter à l'eau, j'essairais de retoucher ça, même si j'ai un peu de mal avec les parser. A2 (d) 10 octobre 2008 à 17:22 (CEST)

Hum hum, le modèle est protégé… Admins où êtes-vous ? A2 (d) 10 octobre 2008 à 17:25 (CEST)

Je suis admin, mais je ne veux pas changer la taille de l'exposant. Pour moi la taille va très bien. Et, sur un modèle aussi utilisé, il va falloir plus de deux personnes pour avoir l'accord d'une modification : fera-t-elle l'unanimité, ou, au contraire, va-t-elle être très controversé ? C'est pour ça qu'il va falloir plus d'avis pour la modification du modèle. En ce qui concerne les espaces, nous utilisons déjà &nbsp; qui, il me semble, est la norme pour l'écriture des chiffres :

• 1 500 000 kg
• 1 500 000 kg

Les deux exemples sont identiques, et on remarque très vite lequel est le plus simple au niveau de la syntaxe.

Les exposants ne sont pas présents sur mon clavier, et ce modèle m'a beaucoup aidé pour leur écriture. (D'ailleurs, je me suis trompé, le modèle utilise le <sup class="exposant"></sup> et non le span.)

Pour les points qui ne devraient pas être médians, que devraient-ils être ? Et pourquoi ? (excusez-moi, je ne connais pas la norme au niveau de ces "points".) — Steƒ ^{(  Стеф  )} 10 octobre 2008 à 17:51 (CEST)

Pour la multiplication un point suffit (le point normal !). C'est ce que j'ai appris à l'école et c'est ce qui est écrit sur wp (cf. plus haut). Je soupsonne que le modèle anglais ait été copié sans trop d'adaptation, d'où ce reliquat. En anglais on utilise un opérateur point parce que le séparateur décimal est déjà un point, je ne vois pas pourquoi ça porterait confusion mais bon ils font comme ça. En français on utilise la virgule comme séparateur décimal donc ce point médian n'a pas de raison d'être. Il faudrait demander confirmation sur l'atelier typographique. Je remarque aussi que le modèle utilise × avant les puissances de 10, il faudrait choisir (sur l'exemple on a × puis un opérateur puce…). Si le modèle est beaucoup utilisé raison de plus pour que la typo et son rendu soient corrects. Sus à l'archaïque azerty ! A2 (d) 10 octobre 2008 à 20:20 (CEST)

Franc~hement je viens de voir un ∙ pour la première fois et c'est pas très esthétique. On est d'accord. J⋅s ? ... J.s ? . Salut Tarap (d) 25 février 2009 à 03:03 (CET)

Ça m'a étonné aussi cet énorme point. Je trouve complètement logique de le remplacer par soit un point médian (⋅) soit un point normal (.) – j'aurais pensé que c'était plus correct de mettre un point médian, mais apparemment un point normal l'est tout autant, voire plus quand le séparateur décimal est la virgule (voir les articles de WP cités). Donc, au final, Pour le point normal à la place du bullet machin. — Delhovlyn » (discuter) 22 avril 2009 à 18:07 (CEST)

 Fait. Gentil ♥ (d) 23 avril 2009 à 19:56 (CEST)

C’est gentil d’y mettre du bon cœur mais il faudrait lire la discussion : Delhovlyn et moi semblons d’accord sur le choix du point normal. J’insiste car le modèle est de plus en plus utilisé. Reste encore le problème des exposants (qui traine depuis plusieurs mois… dur dur la vie d’un top modèle). A2 (d) 30 juillet 2009 à 07:56 (CEST)

Unité facultative et renommage

Je propose :

1. De rendre l'usage de l'unité facultative (il suffit de retirer l'avertissement)
2. De renommer le modèle {{Nombre avec unité}} en {{Nombre}} pour une utilisation plus facile et plus logique que {{Unité}}

Gentil ♥ (d) 23 avril 2009 à 19:56 (CEST)

Je suis pour le premier point bien que pour les nombres sans unité il suffit d'utiliser la commande {{formatnum:}}. Par contre le second me semble inutile car l'utilisation de {{Nombre}} fonctionne puisque c'est une redirection vers {{Nombre avec unité}} (idem pour {{Unité}}). Udufruduhu (d) 24 avril 2009 à 19:11 (CEST)

En rendant l'unité facultative, il n'est plus nécessaire de nommer ce modèle avec unité. C'est comme les infobox, on ne les appelle pas infobox avec illustration et infos diverses, mais infobox tout court. De plus, l'usage fait qu'une forme courte est fortement privilégiée, donc autant éviter (de passer par) toute redirection. Gentil ♥ (d) 24 avril 2009 à 19:21 (CEST)

bien sur si l'objectif est également de supprimer les redirections, la dénomination restante doit bien entendu être la plus courte et la plus cohérente, donc {{nombre}} est le choix évident. Mais je ne vois pas l'intérêt de supprimer les redirections, ce qui ne ferait qu'engendrer un travail de masse à donner aux bots. Après si c'est vraiment pour une question de cohérence entre le nom du modèle et son action, je préfère qu'on échange le contenu des pages {{nombre}} et {{Nombre avec unité}} plutôt que de supprimer les redirections. Udufruduhu (d) 24 avril 2009 à 19:31 (CEST)

Pour info, WP:AWB place actuellement des {{unité}} un peu partout. Il faut peut-être regarder quel redirect est le plus utilisé. Ou pas. — Coyau (d) 24 avril 2009 à 19:41 (CEST)

Non, il n'est pas question de supprimer des redirections, mais de favoriser un usage direct du modèle, sans passer par une redirection. Or utiliser {{Nombre avec unité|10|m|2}} au sein d'un texte est moins souhaitable qu'une forme courte telle {{Nombre|10|m|2}} ou {{unité|10|m|2}}. Gentil ♥ (d) 24 avril 2009 à 20:22 (CEST)

Coyau, {{nombre}} est nouveau : je viens de le créer. Donc l'usage n'est pas à prendre en compte. Gentil ♥ (d) 24 avril 2009 à 20:28 (CEST)

et bien dans ce cas l'échange des pages est la solution. Je ne m'y opposerai pas puisqu'il se base sur le bon sens . Ya plus qu'à... Udufruduhu (d) 24 avril 2009 à 20:29 (CEST)

J'ai l'impression que l'usage de {{formatnum:}} pour les nombres sans unité et de {{unité}} pour les nombres avec unité (même avec les éditions automatisées sous AWB) sont les plus largement répandus dans la pratique. Il me semblerait plus logique et plus simple pour les contributeurs de partir de ce postulat et de renommer en conséquence s'il faut renommer. Gemini1980 oui ? non ? 24 avril 2009 à 22:19 (CEST)

Bon, le renommage est fait. Il reste notamment à contacter les bots pour favoriser {{nombre}} plutôt que {{unité}}. Gentil ♥ (d) 25 avril 2009 à 02:52 (CEST)

Apparemment tu n'as pas compris ce que je disais : étant donné que {{unité}} est beaucoup plus naturel que {{nombre}}, quelle que soit la logique, tu aurais dû renommer de la sorte. Gemini1980 oui ? non ? 25 avril 2009 à 14:06 (CEST)

Est-il plus raisonable d'écrire {{nombre|1.23|e=6}} ou {{unité|1.23|e=6}} ? Quand on écrit 10 km, fait-on plus naturellement référence à la valeur (le nombre) ou à l'échelle de mesure (l'unité) ? Puisque ce modèle sert fondamentalement à mettre en forme une valeur numérique suivie ou pas d'une unité, il est préférable de mettre l'accent sur nombre ou valeur plutôt que unité. Gentil ♥ (d) 25 avril 2009 à 15:05 (CEST)

Pour les nombres avec unité, l'usage très répandu est d'écrire {{unité|1000|km}} qui donne 1 000 km.

Pour les nombres sans unité, l'usage très répandu est d'écrire {{formatnum:1000}} qui donne 1 000 ou 1{{x10|3}} qui donne 1 × 10³.

Tu viens de prendre une décision en catimini et en vitesse sans consulter la communauté très largement concernée. C'est dommage que ton premier usage de tes nouveaux outils se passe dans ces conditions. C'est tout ! Gemini1980 oui ? non ? 25 avril 2009 à 16:06 (CEST)

+1, avec Gemini1980. Daniel*D 25 avril 2009 à 21:27 (CEST)

J'ai hésité. Je reconnais que le délai de 24 heures de consultation était assez court pour un tel modèle, mais je n'ai pas noté de forte opposition. La fréquence d'usage précédente de {{unité}} n'a absolument aucune valeur car l'alternative {{nombre}} n'existait pas encore et ne pouvait donc s'y comparer. Et d'ici un certain temps, les scripts/bots auront probablement inversé la tendance. Gentil ♥ (d) 26 avril 2009 à 01:53 (CEST)

Consultation, où donc ? Sans compter les pages d'aides et de recommandation où {{formatnum:}} et {{unité}} sont préconisés depuis fort longtemps. Compte tenu des habitudes les robots n'ont pas fini de tourner. Encore un changement de ce qui marche. Daniel*D 26 avril 2009 à 02:48 (CEST)

Oui, d'autant que jusqu'à preuve du contraire les articles ne sont pas écrits avec des scripts ou par des bots, mais par des contributeurs qui ont des habitudes. Je ne dis pas qu'il n'y a pas de logique dans ce renommage, je dis juste qu'il aurait fallu s'assurer un peu plus sérieusement que ça auprès de la communauté que le jeu en vallait vraiment la chandelle. Gemini1980 oui ? non ? 26 avril 2009 à 03:10 (CEST)

[<] Il est un fait certain que, pour ce qui me concerne, je ne vais certainement pas changer cette habitude pour ajouter une lettre au modèle {{unité}}. Il m'arrive assez fréquemment de remplacer {{formatnum:}} par {{unité}} à chaque fois qu'un nombre est suivit de son « unité » fussent des cerises ou des km/h, {{formatnum:}} étant la plupart du temps employé de manière non pertinente (absence d'espace insécable entre le nombre et son unité). Je suis aussi de l'avis que {{unité}} est beaucoup plus intuitif que {{nombre}} pour un nombre suivit de son unité. Mais comme {{nombre}} est plus simple à écrire que {{formatnum:}} je m'en vais l'adopter pour les nombres seuls. Je pense qu'ainsi les gens en regardant mes diff trouverons cela justifié. De toutes façons je ne vois pas l'intérêt de robotiser de telles corrections de redirection. Daniel*D 26 avril 2009 à 03:48 (CEST)

Bref, à présent, il y a consensus pour renommer une nouvelle fois vers {{unité}}. — Coyau (d) 28 avril 2009 à 00:45 (CEST)

Sans moi. Faut-il vraiment changer dès qu'il y a un avis contraire ? Gentil ♥ (d) 7 mai 2009 à 01:07 (CEST)

Euh, il semble qu'il y ait plus d'un avis légèrement différent du tien. Mais en effet ne changeons rien de ce qui vient d'être changé, c'est plus simple et pas très important. On a simplement un modèle en plus et abondance de biens ne nuit pas. Daniel*D 7 mai 2009 à 01:19 (CEST)

[<] Voir mon message suite au nouveau renommage (regrettable à mon avis) du modèle par Coyau (d · c · b). — MetalGearLiquid ^{[m’écrire]} 30 août 2009 à 05:52 (CEST)

N’ayant obtenu aucune réaction, ni ici, ni sur la PdD de Coyau, je vais prochaine annuler son renommage que je juge inadapté, compte tenu des modifications opérées par Cœur en avril et des remarques ci-dessous ou similaires lues sur d’autres pages (usage jugé choquant de Unité + personnes). — MetalGearLiquid ^{[m’écrire]} 5 octobre 2009 à 15:23 (CEST)

Documentation : « Dans quel cas ne pas utiliser ce modèle ? »

Ce passage sur la documentation du modèle est complètement biaisé et j’aimerais qu’il soit modéré.

• « il n’est pas nécessaire d’ajouter manuellement cette espace insécable avant le caractère « % » : en effet, une espace normale suffit, car MediaWiki (le logiciel utilisé par Wikipédia) la transforme automatiquement en espace insécable à l’affichage de la page (on peut éditer le code HTML pour s’en convaincre) » : c'est bien vrai mais seulement à l’affichage ; la typographie de la source des articles est toujours incorrecte et si du texte est copié depuis la source il sera mal typographié. Comme avant la ponctuation haute il est donc recommandable de mettre une insécable plutôt que l’espace normale.
• « En fait, ce n’est pas seulement inutile, mais déconseillé, car cela complique l’édition et la lecture du code wiki pour un résultat identique. » : au contraire, parfois ce qui complique l’édition c’est ce modèle {{unité}} que l’on voit de plus en plus pour écrire « {{unité|20|km}} ». Comme les modèles pour les siècles, son abondance incite le contributeur néophyte à l’utiliser lui aussi (pour faire comme les autres). Il se doit alors taper au moins deux fois plus de texte pour le même résultat qui plus est des caractères peu accessibles en azerty comme {|}. Ce qui me fruste le plus est de voir des passages corrects modifiés par des gens qui, croyant bien faire, ajoutent le modèle… pour le même résultat : au final c’est une édition en plus (du temps perdu), un appel au modèle en chargeant la page (de la charge serveur en plus) et ceci juste pour être sûr que l’espace insécable est bien là (vu qu’on ne la voit pas, et c’est bien ça le problème).

Je propose d’indiquer clairement de ne pas utiliser ce modèle lorsque l’utilisateur est capable de saisir des espaces insécables lui-même. L’encyclopédie est libre de n’avoir pas de fautes de typographie lorsque qu’on réutilise son contenu, d’où que ce soit (depuis la source !). L’avertissement devrait être identique sur {{n°}}) et d’autres modèles du genre que l’on n’utilise seulement pour palier l’absence d’insécable sur la disposition azerty ou à portée de clic (l’insécable html a disparu de la barre « caractères spéciaux », il faudrait peut-être ajouter une insécable « normale » que les gens pourraient utiliser. Pour les intéressés : j’utilise depuis quelques mois un script qui vient des gadgets du mediawiki de test (préférences/gadgets/EvilUnicodeConverter) : à l’édition il affiche les caractères invisibles sous leur format html (alors visible) puis les reconvertit en sauvegardant. Je n’ai eu aucun problème avec. Il serait intéressant de l’avoir par actif par defautau moins pour les espaces insécables (tout bon éditeur de texte le fait, Open Office affiche les insécables sous la forme d’un carré gris) de manière à ce que les contributeurs n’utilisent pas ces modèles inutilement. A2 (d) 30 juillet 2009 à 07:46 (CEST)

Quand on copie du contenu depuis la source, on copie le modèle...

le problème avec ce genre de modification, c'est que tu vas de ton côté à l'encontre de l'usage actuel appuyé sur les modèles, ce qui va juste ajouter un peu de confusion. --Lgd (d) 30 juillet 2009 à 07:51 (CEST)

C’était juste pour vérifier, je ne le fais pas en règle générale. Si l’on copie vers ailleurs (hors mw) on a un modèle et non une insécable comme il faudrait. Rien n’empêche d’indiquer en premier lieu aux utilisateurs qu’ils peuvent se passer du modèle pour les cas simples, d’autant plus s’ils savent saisir des insécables. Enfin, je n’ai rien contre l’utilisation de ce modèle à bon escient mais le remplacement automatisé (par AWB comme sur le diff. précédent) de toute forme d’unité laisse complètement à désirer. A2 (d) 30 juillet 2009 à 08:08 (CEST)

Ahem :

• copier le rendu affiché de l'article vers autre chose qu'un wiki compatible est normal, signe d'un esprit sain et cohérent
• copier la source de l'article vers un wiki compatible est normal, signe d'un esprit sain et cohérent
• Mais aller éditer l'article pour copier la source vers autre chose qu'un wiki compatible en s'éttendant à ne pas avoir à traiter le problème (notamment) des modèles, des appels d'images, des titres, des liens, etc. est... curieux ?

Sinon, ce qui n'empêche pas d'indiquer aux utilisateurs qu'ils peuvent saisir des espaces insécables directement mais qui en fait une erreur qu'on évite est tout simple: rien ne différencie lors de l'édition de l'article qu'une espace présente littéralement est insécable ou non. D'où incertitudes, malentendus, erreurs, éditions inutiles, temps et ressources perdues.

Et non, on ne va pas imposer aux contributeurs de se doter d'un outil comme Utilisateur:A2/nbspfixer.js. L'idée générale est plutôt de simplifier l'accès à l'édition des articles... --Lgd (d) 30 juillet 2009 à 20:01 (CEST)

Je sais que je fais un peu l'avocat du diable mais je continue de penser que si mediawiki identifiait clairement les insécables cela simplifierait l'édition des articles (cela éviterait de rajouter ces modèles là où la typo. est correcte) ; c’est une option disponible sur tout traitement de texte, pourquoi pas ici ? Bon, je radote donc j’arrête là. A2 (d) 30 juillet 2009 à 21:09 (CEST)

Problèmes avec l’encodage des insécables : certains butineurs les transforment en des espaces normales (rien ne permet d’imposer à l’ensemble des éditeurs d’utiliser des butineurs compatibles - et je me demande si certains outils ne cause pas également de tels remplacements : AWB, WikEd, autres ? À vérifier…), les insécables ne sont pas visibles par défaut et donc ça va imposer du travail quand on voit par exemple 15 000 km (est-ce codé avec espaces sécables ou insécables ?) dans le code…
Quant à «   », soyons sérieux, ça rend le code presque illisible (ok à l’époque révolue de l’ASCII / Latin-1 & HTML 3.x, mais à l’heure du XHTML + CSS + Unicode…) ! D’autant plus que la mise à jour des données est bien moins conviviales qu’en d’usage de ce modèle.
— MetalGearLiquid ^{[m’écrire]} 30 août 2009 à 06:17 (CEST)

Unités douteuses

Juste un mot pour dire que je trouve parfois l'utilisation du modèle {{Unité|nombre|unité}} me semblre discutable dans certains cas. J'ai remarqué que c'était parfois inaproprié, mais ça m'a surtout choqué quand dans l'article shoah les Juifs deviennent une unité ({{Unité|30000|Juifs}}) et bien qu'on refuse de plus en plus l'utilisation du {{formatnum:}}, celui-ci est pplus approprié à mon sens. --HAF 932 23 septembre 2009 à 20:04 (CEST)

Ceci est juste un exemple de plus pour démontrer que le retour au nom de modèle « Unité » à la place de « Nombre » était inopportun !
« Nombre » se focalise sur le nombre et ne présume en rien de ce qui est éventuellement derrière le nombre. Formatnum est inadapté, car il impose une sacré lourdeur ! (certes le nombre doit être mis au format, mais il faut également éviter que le nombre soit séparé (passage à la ligne intempestif) de ce qu’il désigne / compte / quantifie), or placer un   ou utiliser un second modèle pour éviter un éventuel passage à la ligne rendrait la source moins lisible ! — MetalGearLiquid ^{[m’écrire]} 24 septembre 2009 à 12:53 (CEST)

{{unité/2}}

Bonjour, est-ce que vous seriez d'accord de fusionner le modèle {{unité/2}} avec ce modèle? Epop (d) 31 janvier 2010 à 13:24 (CET)

Proposition de fusion Modèle:unité et Modèle:unité/2

Les deux modèles ont la même fonction. Epop (d) 5 février 2010 à 11:23 (CET)

Pour, jamais vraiment compris pourquoi il y en avait deux. — Rhadamante 5 février 2010 à 13:45 (CET)

Pas tout à fait : le premier affiche les unités et les chiffres en exposant, le deuxième aussi mais avec affichage d'une conversion en unités standard via une infobulle, qui apparaît en passant le curseur sur le(s) chiffre(s). Ce qui fait que, le code du deuxième est bien plus long (mais pas beaucoup plus complexe) que celui du premier. Tejgad (d) 5 février 2010 à 18:11 (CET)

Ça devrait coincer au niveau de cet article (résultat ici). Le plus simple, ce serait de remplacer

{{unité|64|[[kibioctet|Kio]]}}

par

64&nbsp;[[kibioctet|Kio]]

L'article ne bénéficierait pas du modèle mais il s'afficherait correctement. Epop (d) 6 février 2010 à 13:26 (CET)

Contre, parce que j'ai l'impression que le nouveau modèle issue de la fusion créera automatiquement des liens vers l'unité, ce qui me semble être néfaste. Cordialement, Freewol (d) 7 février 2010 à 08:41 (CET)

En fait le modèle:unité/2 a un code plus long, et comme MédiaWiki limite la quantité de code par page, on peut faire appel moins de fois au modèle dans une même page. Ceci dit, ça n'arrive que dans les listes très longues (l'article Liste des microprocesseurs Intel était long parce-qu'il était dédoublé, mais ça va mieux maintenant).

On peut voir combien de place il reste pour les modèles en éditant le code source de la page et en regardant le « NewPP limit report ». Dans le cas de la liste ci-dessus on a :

Preprocessor node count: 555731/1000000
Post-expand include size: 344109/2048000 bytes
Template argument size: 32079/2048000 bytes
Expensive parser function count: 128/500

Autre différence : le modèle affiche l'unité au passage de la souris sur les lettres. Par exemple dans le cas de « Mio » il affiche « mébioctet » et crée un lien vers la page Octet. Si ce dernier point est gênant on peut se contenter d'afficher la signification de l'unité et enlever le lien. Epop (d) 7 février 2010 à 11:49 (CET)

Je vois donc deux problèmes à la fusion (modèle qui gagne en longueur, ce qui augmente le temps de chargement des pages y faisant beaucoup appel, et affichage par défaut d'un lien vers les unités). Cordialement, Freewol (d) 7 février 2010 à 18:38 (CET)

J'ai enlevé les liens : [1] Epop (d) 7 février 2010 à 23:40 (CET)

Bonjour. Ouvrir le diff fait quasiment planter mon navigateur tellement la page est grosse. Désolé mais ce modèle (Unité/2) ne me semble vraiment pas être une bonne idée. Plutôt que la fusion avec Unité, je suggèrerais même l'opposé, à savoir la scission de Unité/2 en des modèles plus spécifiques, comme UnitéPhysique, UnitéInformatique ... Je pense qu'il faut éviter d'avoir des pages (modèle ou article, peu importe, si lourdes qu'il est parfois impossible de faire un diff ou une modification dessus si on n'a pas un ordinateur surpuissant. Cordialement, Freewol (d) 8 février 2010 à 10:19 (CET)

Bonjour, j'ai fait l'édition sur un netbook qui n'a rien de surpuissant (vous pouvez le voir ici).

Je vais mesurer le temps de chargement de quelques pages avec les deux modèles pour qu'on ait des chiffres précis. Cordialement, Epop (d) 8 février 2010 à 13:20 (CET)

Bonjour, voici le temps nécessairte pour prévisualiser sur mon poste :

page	{{unité/2}}	{{unité}} + {{tmp}}
Liste de mélanges azéotropes	29s	11s
dioxyde de soufre	8s	10 s
acétone	10s	9s

Ca a l'air d'être plus long pour les listes mais il y a peu de différences dans les petits articles.

On était parti sur le principe de faire plusieurs modèles à la base ({{tmp}}, {{λ}} par exemple). Mais ça implique d'apprendre à utiliser plusieurs modèles. On se plaint souvent sur le bistrot de la complexité des modèles et une scission n'arrangerait pas les choses. Avec un seul modèles on aurait à apprendre la syntaxe d'un seul modèle. En même temps avec une scission on serait obligé de repasser dans les articles pour mettre les bons modèles.

D'un autre côté une scission éviterait de convertir des degrés d'alcool en radians. Si jamais c'est la scission qui était choisie je serais plutôt pour avoir des noms de modèles comme {{donnée}} pour les octets plutôt que {{UnitéInformatique}} ; on éviterait ainsi d'avoir plusieurs modèles qui s'occupent d'une même unité (par ex. les Hertz sont utilisés aussi bien en physique qu'en informatique).

Personellement j'ai proposé la fusion mais je n'ai pas d'avis tranché. C'est vrai qu'une fusion faciliterait la tâche au niveau de la programmation mais la décision revient à ceux qui ont l'intention d'utiliser le(s) modèles(s). Ce serait bien qu'on pèse le pour et le contre des deux options rapidement avant de continuer à ajouter d'autres fonctions au(x) modèles(s). Epop (d) 19 février 2010 à 13:20 (CET)

Bonjour. (à Freewol) Pourquoi un lien automatique vers l'unité vous paraît-il néfaste ? JPaul (d) 12 février 2010 à 17:36 (CET)

Bonjour. Désolé j'avais perdu de vue cette discussion. Le problème, c'est l'utilisation à de nombreuses reprises du modèle dans un même paragraphe, ou dans un même tableau. Si on a un lien vers l'unité automatiquement, on va se retrouver avec de très nombreux liens internes identiques et très rapprochés, ce qui est à éviter autant que possible.

D'autre part, merci à Epop d'avoir fait le test de rapidité. Je suis d'accord que lorsque le modèle est peu utilisé la différence ne sera peut-être pas mesurable, mais il faut bien tenir compte justement des articles faisant de nombreux appels au modèle.

C'est dommage que je sois le seul à m'exprimer à ce sujet, si vous voulez faire cette fusion, il faudrait d'autres avis que le mien (et le votre ). Cordialement, Freewol (d) 21 février 2010 à 11:36 (CET)

Contre, même avis que Freewol. En ajoutant que le modèle {{unité}} (ou son alias {{nombre}}) est aussi très utile pour respecter la typographie en général, en dehors des contextes déjà évoqués ci-dessus, comme dans cet exemple : {{nombre|155000|prisonniers}}, que cela est très fréquent ({{formatnum:}} devrait être proscrit, {{unité}} le remplace de manière bien plus pertinente la plupart du temps) et qu'il est donc inutile de surcharger un modèle assez simple d'emploi. Les deux modèles ont leur utilité et peuvent cohabiter, {{unité/2}} étant plus spécifique. Cdlt, Daniel*D 22 février 2010 à 13:36 (CET)

Vu les avis divergeant et le peu de compromis envisageable à court terme, je clôture la requête et transfère la discussion, ici. La clôture ne veut pas forcément dire que la fusion est irréalisable, ni le contraire... :) --Nouill (d) 5 mars 2010 à 20:10 (CET)

Confusion entre les exposants et les appels de note ou de référence

' Lorsque qu'une unité est assortie d'un appel de note (comparez 'une surface de 10 à 12 km²' 'une longueur de 12 km), il y a risque de confusion entre l'exposant et l'appel de note. Une espace ou une mise entre parenthèse de l'appel de note éviterait peut-être la confusion ? Le modèle peut-il traiter cette difficulté ? Pfrappe (d) 26 mars 2010 à 08:32 (CET)

Voir aussi :

• Discussion Wikipédia:Conventions typographiques#Problème récurrent de lecture des exposants ;
• Bistro/ Sondage express ;
• Aide:Note#Règles sur la position des notes par rapport à la ponctuation.

À titre individuel, si vous voulez, vous pouvez avoir les appels de note entre crochets, pour cela, dans votre monobook.css, ajoutez :

/* crochets dans les appels de notes */
.cite_crochet { display: inline; }

Cordialement, Daniel*D 26 mars 2010 à 11:31 (CET)

mètres cubes par seconde

Est-il possible d'utiliser le modèle unité pour écrire quelque chose comme : 3,7 m³/s ? Merci. Camster (d) 10 mai 2010 à 11:41 (CEST)

C'est même conseillé  :

{{Unité|3.7|m{{3}}/s}} → 3,7 m³/s

{{Unité|3.7|m|3|s|-1}} → 3,7 m³ s⁻¹ (version plus « scientifique »)

Cordialement, Daniel*D 10 mai 2010 à 11:54 (CEST)

Parenthèse entrante et modèle

Lorsqu'une parenthèse entrante est devant le modèle, il peut se créer une rupture de ligne entre cette parenthèse et le premier chiffre, ce qui ne se produit pas avec {{formatnum:}}. Le problème peut-il être résolu ? ---- Ikmo-ned (discuter avec) 19 juin 2010 à 11:05 (CEST)

{{formatnum:}}

Bonjour,
Je trouve quand même cela un peu bizarre et dommage d'avoir à noter les nombres sous le format anglo-saxon si on veut au final les avoir au format francophone ! C'est quand même un comble ! Je dois écrire 6.674,28 si je veux obtenir 6,674 28 !!!
Il n'y aurait pas eu moyen de nous programmer rapidement notre propre modèle {{formatnum:}} ? --81.64.104.59 (d) 20 décembre 2010 à 11:55 (CET)

Signe moins

Ne devrait-on pas profiter de cette balise bien pratique pour transformer les traits d'union (-) utilisés comme symboles moins pour les nombres négatifs, en « vrais » moins (symbole Unicode U+2212 −) ?

Exemple : {{Unité|-2.5}} donne −2,5 plutôt que −2,5 (à mon avis plus esthétique, plus lisible, et plus juste sémantiquement).

Moa18e (d) 17 juillet 2011 à 16:40 (CEST)

Demande de modification de l'article

« Dans quel cas ne pas utiliser ce modèle ? »

Écrire ceci : Ce modèle est inutile et déconseillé lorsque l'unité est le pourcent car cela complique l'édition et la lecture du code wiki pour un résultat identique.

Afin du supprimer cette phrase dans l'article « En fait, ce n’est pas seulement inutile, mais déconseillé, car cela complique l’édition et la lecture du code wiki pour un résultat identique. » . MerveillePédia dial. 9 mars 2012 à 11:52 (CET)

Il n'est jamais trop tard . Daniel*D (d) 29 décembre 2012 à 14:35 (CET)

Virgule

Quelqu'un pourrait-il régler le problème de la virgule? Skiff (d) 18 mai 2012 à 10:16 (CEST)

Le problème de la virgule ne dépend pas du modèle, mais du fonctionnement de la fonction parser {{formatnum:}} de mediawiki qui n'internationalise pas la saisie (il faut saisir le point comme séparateur des décimales quelque-soit la langue du wiki) mais uniquement le rendu (le résultat de la fonction dans fr.wp est la virgule comme séparateur décimal). Nous n'avons pas la main sur ce fonctionnement que nous ne pouvons donc pas modifier. Cordialement, --Lgd (d) 22 mai 2012 à 09:41 (CEST)

Un administrateur pourrait-il corriger une erreur dans la documentation ? Dans la dernière phrase du dernier paragraphe de l'Utilisation , il faut remplacer virgule par point pour {{formatnum:}}. Merci. Xapitoun (discuter) 16 janvier 2014 à 20:11 (CET)

Non, c'est correct car on parle de la partie décimale, voir également le paragraphe « Paramètres » et celui-ci sur les Conventions typographiques.

Pour formatnum :

• {{formatnum:12345.67890}} donne 12 345,67890 (typographie erronée) ;
• {{formatnum:12345.678,90}} donne 12 345,678,90 (typographie correcte).

Pour unité :

• {{unité|12345.67890|€}} donne 12 345,678 90 € (typographie erronée) ;
• {{unité|12345.678 90|€}} donne 12 345,678 90 € (typographie correcte).

Cordialement, Daniel*D, 19 janvier 2014 à 16:38 (CET)

Unités sexagésimales d’angle

Bonsoir,

« Le modèle {{unité}} permet d’écrire facilement et de typographier correctement un nombre suivi d’une unité. »

« Cette règle du symbole détaché ne s’applique pas aux unités sexagésimales d’angle (mesure d’angle, latitude, longitude), ni au degré d’alcool. » — Wikipédia:Conventions concernant les nombres#Pour un comptage ou une mesure

• {{unité|1|°}} devrait produire 1° — {{unité|1|°C}} produit bien 1 °C
• {{unité|1|′}} devrait produire 1′
• {{unité|1|″}} devrait produire 1″

Lacrymocéphale (d) 22 juillet 2012 à 23:00 (CEST)

Il suffit de ne pas utiliser de modèle pour ces exemples, lorsqu'il n'y a qu'une seule unité de cette catégorie ou d'utiliser {{nobr}}, s'il y en a plusieurs, exemple : {{nobr|10° 32' 28"}} donne : 10° 32' 28". Daniel*D (d) 29 décembre 2012 à 14:45 (CET)

Ajouté un §. Daniel*D (d) 29 décembre 2012 à 18:24 (CET)

---

Ajout du comte Nemoi – Ce ne me semble pas forcément une mauvaise idée de « corriger » le modèle pour ces cas particuliers, pour les personnes peu versées en typographie, et de demander à un robot (AkeronBot ? ) d’ajouter cela à ses corrections… Ce 30 décembre 2012 à 04:45 (CET).

On peut aussi écrire : {{unité|10° 32' 28"}} → 10°³² '²⁸ ", étonnant, n'est-il pas ? Daniel*D (d) 30 décembre 2012 à 18:37 (CET)

Peut-être qu’à l’époque ça donnait un joli résultat, mais maintenant ce n’est plus du tout le cas ! ({{unité|10° 32' 28"}} → 10°³² '²⁸ " ; et pour l’historique, en cas de correction du modèle, voici le rendu actuel : 10 °³² '²⁸ "). De toute façon, le résultat idéal serait plutôt 10° 32′ 28″ ! (sans « chiures de mouches » ni « gants de toilette ») 2A02:2788:22A:100D:D9CD:5B94:B54D:CA99 (discuter) 14 juillet 2020 à 04:51 (CEST)

Modèle nombre redirigé sur le modèle unité

Si je comprends bien, le Modele nombre redirigé sur le modèle unité, j’avoue ne pas comprendre l’intérêt?!

10 tr mn⁻¹: Pourquoi un nombre aurait il une unité? Bizarre! ... Pano38 (d) 7 février 2013 à 17:38 (CET)

Lire ceci, où il s'agit de typographier correctement un nombre suivi d’une unité ou d’un nom, et en particulier : « Note : dans certains cas la redirection {{nombre}} peut paraître préférable d'un point de vue sémantique, exemple : {{nombre|250000|déportés}} ».

D'ailleurs, il est aussi possible de lire les différentes discussions figurant sur cette page, où l'on peut constater que certains souhaitaient que le seul modèle pertinent conservé soit {{Nombre}} à la place d'{{Unité}}, ce qui, à la réflexion, arrangerait bien des choses.

N.B. : dans votre exemple, le nombre 10 a pour unité des tours par minute...

Cordialement, Daniel*D 7 février 2013 à 19:21 (CET)

désolé mais votre exemple ne justifier rien; pourquoi mettre un mot, a plus forte raison quand ce n'est pas une unité, attaché a un nombre; j'avoue ne pas comprendre la logique qui a conduit a cette décision; si c'en est une. Et puis pourquoi garder deux nom de modèles qui font exactement la même chose; rien de très logique dans tout cela.Pano38 (d) 7 février 2013 à 19:44 (CET)

Comme l'indique le texte de la documentation, sourcé par la ref [1], c'est-à-dire le LRTUIN, et pourvu de ce lien Wikipédia:Conventions concernant les nombres il s'agit de typographier correctement les nombres donc, entre autres, d'éviter le retour à la ligne entre un nombre et l'unité ou le nom qui le suit. Ainsi, ledit Lexique, indique-t-il, page 61 : « Un nombre en chiffres arabes ou romains ne sera jamais séparé du nom qui le précède ou qui le suit. »

Pour la différence sémantique voir : #Unités douteuses.

Personnellement je suis maintenant assez favorable au seul modèle : {{Nombre}}

Daniel*D 7 février 2013 à 20:11 (CET)

Ce que tu dis va plus loin que ce qui est fait actuellement, car si il faut que le nombre ne soit ni séparé de ce qui précède, ni de ce qui suit il faut revoir le modèle pour avoir un modèle complet. Tu es pour ne conserver que le modèle nombre, ce qui me convient et pourquoi ne pas en profiter pour supprimer le modèle « formatnum » dont la forme et la syntaxe sont trop différent des autres ... Pano38 (d) 8 février 2013 à 06:46 (CET)

Parce que formatnum n'est pas un modèle mais un « mot magique » de Mediawiki, ce qui explique cette syntaxe particulière. Il ne peut pas être supprimé. — Mirgolth 8 février 2013 à 09:21 (CET)

Désolé, mais je n'ai aucune compétence en magie et je ne souhaite pas en acquérir. Je ne savait pas que WP couvrait ce domaine ... Pano38 (d) 8 février 2013 à 09:46 (CET)

Je n'aime pas le ton que tu utilises, voir mw:Help:Magic words. — Mirgolth 8 février 2013 à 11:53 (CET)

Désolé si tu as trouvé que mon ton vous a semblé désagréable, ce n’était pas mon intension; je ne comprend simplement pas pourquoi vous avez voulu que "nombre" soit identique a "unité", alors qu'il etait si simple de les garder diffrenciés, mais vous avez surement de très bonnes raisons pour cela. Restons en là. Cordialement Pano38 (d) 8 février 2013 à 15:29 (CET)

+1, Pano 38 devrait, a minima, faire un effort de son côté pour mieux appréhender certains aspects de Wikipédia, dans le domaine « technique », où il semble avoir des lacunes, mais aussi et surtout dans sa façon de communiquer. Il devrait, par ailleurs se rendre compte des efforts que l'on fait pour répondre, gentiment et calmement, à ses interrogations parfois pas vraiment pertinentes (exemple : « Pourquoi un nombre aurait il une unité? Bizarre! ... ») et, accessoirement à la typographie douteuse, ce qui est assez limite lorsque l'on vient commenter un modèle de typo....

Sinon, concernant le fait d'éviter les coupures des noms du nombre qui les précèdent, si le modèle dont il est question ici n'est pas explicitement prévu pour — et encore, car il peut aussi fonctionner dans ce cas, exemple : {{unité|livre III}}, donne livre III —, il existe, pour ceux qui trouvent cela important, toute une panoplie de moyens de se conformer à cet usage, entre autres, le modèle {{nobr}}. Mais si Pano 38 s'était donné la peine de consulter les bons liens vers lesquels je me suis efforcé de le diriger, sans doute se rendrait-il compte de l'inutilité de certaines de ses questions, enfin, on peut l'espérer.

Daniel*D 8 février 2013 à 14:00 (CET)

Petit complément aux explications de Mirgolth sur « formatnum » : comme ce « mot magique » est utilisé dans de nombreux modèles et en particulier ici : [2], le supprimer n'arrangerait pas vraiment les choses... Daniel*D 8 février 2013 à 14:06 (CET)

Ce qu'il faudrait :

• {{nombre:}} alias pour {{formatnum:}}
• {{nombre|}} utilise juste {{formatnum:}} (pas de paramètre possible)
• {{unité|}} nombre avec un paramètre unité.

C'est logique, simple et plus performant, il y a juste une transition à faire avec l'usage {{nombre|unité}}. –Akeron (d) 8 février 2013 à 14:20 (CET)

Ou bien {{nombre|}} remplaçant tout (ce qui fonctionne déjà pour tous les cas et est bien plus simple pour le contributeur moyen), un nombre, avec ou sans unité est toujours un nombre. Il y avait eu cette discussion. Daniel*D 8 février 2013 à 15:04 (CET)

La solution proposée par Akeron me semble simple, logique et compréhensible par tout le monde ... Pano38 (d) 8 février 2013 à 16:25 (CET)

Et de tout ce qui précède cette proposition, votre curiosité a-t-elle été satisfaite ? Daniel*D 8 février 2013 à 23:39 (CET)

Je ne vois pas ce que la curiosité vient faire dans cette discussion?! ... Pano38 (d) 9 février 2013 à 08:06 (CET)

Parce que cinq « pourquoi » = curiosité, questionnements, interrogations, etc. Daniel*D 9 février 2013 à 11:56 (CET)

Pourquoi ?

Pourquoi est-il préférable d’utiliser formatnum: plutôt qu’{{unité}} pour un nombre seul ? Azoée (d) 20 mai 2013 à 11:21 (CEST)

Cela dépend... Voir aussi la section précédente. Cordialement, Daniel*D 20 mai 2013 à 12:05 (CEST)

:-) Ach, je n’avais pas lu toute la page. Azoée (d) 20 mai 2013 à 15:19 (CEST)

TemplateData

À quoi peut bien servir cette façon de présenter les paramètres du modèle [3] si c'est pour avoir une version plus complexe et redondante avec la section « Exemples d'utilisation », ne respectant pas la typographie des exposants (ce qui a déjà été corrigé plusieurs fois sur la doc de ce modèle dans un passé plus lointain, pour rectifier le point de vue personnel d'un contributeur partisan des m² plutôt que des m²) et muni de cases en anglais dont on ne saisit pas bien la finalité ? Daniel*D 7 juillet 2013 à 19:09 (CEST)

Sans les m², mais toujours en anglais [4]. Daniel*D 7 juillet 2013 à 19:12 (CEST)

[conflit] L’extension TemplateData apporte des informations utiles lors de la modification avec l’ÉditeurVisuel. Je suis d’accord pour dire que la présentation a besoin d’être améliorée, mais ça ne justifie pas à mon avis d’empêcher son utilisation. Pour le m², j’espère que ce sera corrigé, mais j’ai malheureusement l’impression que c’est voulu de ne pas pouvoir mettre autre chose que du texte brut. Hélas. Mais il doit y avoir moyen de faire bouger ça. Pour les cases en anglais, ça va venir. — Ltrl G^☎, le 7 juillet 2013 à 19:19 (CEST)

Espérons, mais en attendant, peut-être vaut-il mieux éviter de mettre la charrue avant le bœufs. Cordialement, Daniel*D 7 juillet 2013 à 19:35 (CEST)

Au contraire. Si l'on attend que l'éditeur visuel soit activé pour ajouter des TemplateData aux modèles, on va se retrouver du jour au lendemain avec des un outil de modification des modèles qui est complètement vide quand on l'ouvre. Il est donc impératif d'ajouter des TemplateData à autant de modèles que possible avant cette date. guillom 8 juillet 2013 à 16:15 (CEST)

Mais il est tout autant « impératif » de corriger ces machins :

• Exposant

La typographie recommandée pour la mise en exposant, en particulier pour les symboles, par le Lexique des règles typographiques en usage à l’Imprimerie nationale ainsi que par le Système international d'unités est « ⁿ », exemples : m² et m³.

• Nous sommes sur la Wikipédia francophone.

Daniel*D 9 juillet 2013 à 01:07 (CEST)

Il ne me semblait pas que le niveau typographique des documentations de modèles avait vocation à être meilleur que celui des articles… Si je comprend la motivation, je ne comprends pas l’acharnement. — Ltrl G^☎, le 9 juillet 2013 à 01:26 (CEST)

Il est bien sûr évident qu'une documentation se doit d'être correcte car ayant valeur d'exemple, et en particulier pour, justement, un modèle de typographie. Le « m² » avait été retiré, à juste titre, plusieurs fois de cette doc [5], [6], [7], [8], et le voilà revenu d'autorité.

Pour ce qui est de l'« acharnement » merci de supposer la bonne foi, car en l'espèce je pourrais en avoir autant à votre service.

On me déclare la chose « impérative » avec un lien, je réponds par des sources. Quoi de plus normal et classique dans l'univers wikipédien.

Daniel*D 9 juillet 2013 à 02:09 (CEST)

Désolé, le mot « acharnement » est effectivement un peu fort pour signifier ta « résistance à cette modification » (je ne trouvais/trouve pas le mot approprié). Je le retire donc, mais conserve ce sens. Je pense qu’il vaut mieux avoir une documentation légèrement fautive que pas de documentation (pour VisualEditor, s’entend)

Quant au fond : je ne dispose ni du LRTUIN, ni du Formulaire technique (mais promis, je regarde la prochaine fois que je suis à la bibliothèque). Je ne trouve pas de recommandation (qui n’est d’ailleurs en aucun cas une obligation – notamment les limitations techniques sont reconnues si ma mémoire est bonne) de cet ordre dans ton PDF ou sur dgcis.gouv.fr, seulement des exemples (qui pourraient très bien être fautifs ou au moins ne représenter qu’une partie de ce qui est autorisé).

— Ltrl G^☎, le 9 juillet 2013 à 11:55 (CEST)

« Mon » PDF et le document de dgcis.gouv.fr ne donnent pas des « exemples » puisqu'il s'agit des unités légales du Système international d'unités qui bien évidemment ne peut être « fautif ». On y voit très bien la mise en exposant correcte (comme m² et non m²), à de multiples reprises. Daniel*D 9 juillet 2013 à 23:54 (CEST)

Honnêtement, je ne pense pas que ce soit nécessaire d'entrer dans ce niveau de détail :) Je n'aurais jamais imaginé qu'une modification de présentation si légère générerait autant de résistance. Si vraiment certaines personnes ne supportent pas le format autorisé par TemplateData, il est possible de faire coexister les deux (exemple « correctement » formaté, et données TemplateData pour que le modèle fonctionne dans l'éditeur visuel), et c'est ce que j'ai fait. guillom 9 juillet 2013 à 18:57 (CEST)

Quatre contributeurs différents n'ont pas toléré l'introduction (et la réintroduction) de cette mise en exposant fautive au cours du temps (cf. les quatre liens ci-dessus), je suis donc le cinquième.

Comme cette graphie « m² » (pourquoi pas mètre cube ou puissance six) est l'exemple en « dur » (sans utiliser une mise ne forme par modèle, puisque c'est apparemment impossible) que vous avez trouvé pour illustrer la mise en exposant, cela signifie bien qu'il y a un problème, surtout si c'est voulu, comme semble le suggérer Ltrlg. Autant le prendre en compte dès le début et faire en sorte de rectifier cette anomalie, car il est très probable que d'autres cas se produirons.

Pour la traduction, souhaitons que les termes en anglais ne deviennent pas la norme...

Daniel*D 9 juillet 2013 à 23:54 (CEST)

Apparemment on devrait pouvoir mettre en forme : le bug n^o 50656 a été assigné (je ne suis pas sûr que cette traduction soit très exacte, mais elle ne m’a pas l’air trop fautive). Certes il est peu probable qu’un document officiel soit fautif, cependant je répète qu’un exemple est une partie des possibles, non le tout — Ltrl G^☎, le 10 juillet 2013 à 09:40 (CEST)

De toutes façons, il est clair qu'il n'y a pas de raison d'avoir des exposants de tailles différentes (et aucun document sérieux sur cette question ne fait cette bizarrerie, pas « un exemple », tous), au motif que sur certains claviers seul le « ² » est présent. Daniel*D 10 juillet 2013 à 11:38 (CEST)

Redirection de la documentation

Bonjour,

Le code du modèle contient {{Documentation|Modèle:Nombre/Documentation}} au lieu de {{Documentation}}, mais la page Modèle:Nombre/Documentation n'est qu'une redirection vers Modèle:Unité/Documentation. Est-ce normal/utile ? -- XoLm56 (discuter) 30 décembre 2013 à 08:51 (CET).

Oui, moi aussi je suis venu ici pour ça. Alors, on le change, siouplait? --Jérôme Potts (discuter) 12 mars 2015 à 04:18 (CET)

Documentation : « Nombres seul »

Merci de mettre un "s" à "seul" dans le titre de cette section de la doc. Pas évident de trouver où cela se passe ou si cela pourrait casser des références ? SGlad (discuter) 7 novembre 2014 à 14:49 (CET)

→ [9]. Cordialement, Daniel*D, 7 novembre 2014 à 19:38 (CET)

Un exemple à ajouter

Bonjour. Ce serait judicieux d'ajouter un exemple du type :

{{unité/2|10{{exp|−1}}|m}} qui donne 10⁻¹ m.

--Cjp24 (discuter) 8 janvier 2015 à 19:21 (CET)

Bonjour Cjp24  :

• {{unité|10{{exp|−1}}|m}} donne aussi : 10⁻¹ m ;
• de même que {{unité|10{{-1}}|m}} donne : 10⁻¹ m ;
• le modèle {{unité/2}} est indiqué à la section « Voir aussi ».

Je ne sais pas si j'ai bien répondu à cette demande.

Cordialement, Daniel*D, 10 janvier 2015 à 16:17 (CET)

En effet, ce serait judicieux d'ajouter mon exemple au modèle {{unité/2}}. Cordialement. --Cjp24 (discuter) 10 janvier 2015 à 19:46 (CET)

La sous-page de documentation du modèle unité/2, qui serait à réécrire entièrement, n'est pas protégée. Daniel*D, 10 janvier 2015 à 23:51 (CET)

Je me suis permis d'indiquer aussi votre exemple, très utile. --Cjp24 (discuter) 11 janvier 2015 à 01:56 (CET)

J'ai fait de même sur la sous-page de documentation du modèle unité. Daniel*D, 11 janvier 2015 à 03:21 (CET)

Degrés d'angle

La recommandation de l'article est : « Il est donc inutile d’utiliser le modèle. » dans le cas des degrés d'angle. Ce n'est pas « inutile », c'est interdit. En effet le modèle introduit une espace. Vincent Lextrait (discuter) 9 janvier 2015 à 06:25 (CET)

→ [10]. Cordialement, Daniel*D, 10 janvier 2015 à 16:03 (CET)

Voir aussi

Bonjour. Il faudrait ajouter un lien vers {{Dunité}} dans la section « Voir aussi ».--Rehtse (discuter) 10 janvier 2015 à 10:07 (CET)

→ [11]. Cordialement, Daniel*D, 10 janvier 2015 à 16:08 (CET)

Nouvelle version à tester

Bonjour,

J'ai programmé une version lua de ce modèle, pour apporter plus de souplesse de saisie. Cette version peut être testée avec {{Unité/Bac à sable}}

Liste des différences avec le modèle actuel :

• formate correctement les chiffres après la vigule : {{Unité/Bac à sable|0.12345678|m}} → 0,123 456 78 m
• affiche un vrai signe moins, pour les nombres et les unités : {{Unité/Bac à sable|-1500|ft||min|-1}} → −1 500 ft min⁻¹
• accepte les nombres avec une virgule : {{Unité/Bac à sable|1234,5678|m}} → 1 234,567 8 m
• détecte certains nombres qui sont manifestement écrit suivant les normes anglo-saxonnes ou germanique :
  • {{Unité/Bac à sable|12,456,223|habitants}} → 12 456 223 habitants
  • {{Unité/Bac à sable|1,234.56|m}} → 1 234,56 m
  • {{Unité/Bac à sable|1.234,56|m}} → 1,234 56 m
• permet de saisir la puissance de 10 comme une unité : {{Unité/Bac à sable|1.23|10|3}} ou {{Unité/Bac à sable|1.23|e|3}} → 1,23 10³
• n'est plus limité en nombre d'unité : {{Unité/Bac à sable|1.3|m|3|kg|2|s|2|A|2|K||cd||mol|-1}} → 1,3 m³ kg² s² A² K cd mol⁻¹
• peut-être utilisé pour formater une unité sans nombre : {{Unité/Bac à sable||10|3|m|3|s|-1}} → 10³ m³ s⁻¹
• permet dans la majorité des cas de se passer de la séparation des unités :
  • {{Unité/Bac à sable|1300 m.s-1}} → 1 300 m.s⁻¹
  • {{Unité/Bac à sable|1.3e3 m3s-1}} → 1,3 × 10³ m³ s⁻¹
  • {{Unité/Bac à sable|x10e3 m3/s}} → 10³ m³/s
  • {{Unité/Bac à sable|1300°C}} → 1 300 °C
  • {{Unité/Bac à sable|1300°}} → 1 300°

Je vous encourage à tester cette nouvelle version et à me dire si vous voyez des bugs ou des fonctionnalités qui manquent.

Zebulon84 (discuter) 18 avril 2015 à 17:18 (CEST)

Génial ! Avec les corrections dans la doc et sur les conventions typo en intégrant toutes ces améliorations, à adopter au plus vite (en profiter pour que la page de doc ne soit plus une redirection, si possible). Merci. Daniel*D, 18 avril 2015 à 19:49 (CEST)

OK, en rapport avec mes propositions de modèle. Cela dit La norme ISO 80000-partie 1 (§ 7.3.3) précise : « Le signe de la multiplication des nombres est une croix (×) ou un point à mi-hauteur (·). Un espace doit se trouver de chaque côté de la croix ou du point ». On doit donc avoir des espaces insécables de cette façon : 1,23 × 10³, et non 1,23×10³ (voir aussi la brochure du BIPM ou la norme Afnor X 02-003, § 4.3).

Cdlt, Ggal (discuter) 18 avril 2015 à 20:51 (CEST)

Bravo pour les chiffres après la virgule et la possibilité d'utilisation de la virgule et surtout d'un seul paramètre, d'accord avec Ggal pour l'espace insécable non seulement après × mais aussi avant. — Oliv☮ ^{Éppen hozzám?} 19 avril 2015 à 08:52 (CEST)

J'ai ajouté des espaces insécables autour de la croix. Faut-il aussi en mettre autour des points entre les unités ? – Zebulon84 (discuter) 19 avril 2015 à 10:39 (CEST)

Oui, par exemple selon la brochure du BIPM (p. 60 et 65). Cordialement, Daniel*D, 19 avril 2015 à 11:20 (CEST)

En effet, c'est ce que dit la norme ISO 80000. Exemple W · m/(m² · K) ou W/(m · K) ou W · m^–1 · K^–1. Ggal (discuter) 19 avril 2015 à 11:28 (CEST)

 Fait. – Zebulon84 (discuter) 19 avril 2015 à 12:01 (CEST)

 Zebulon84, Daniel*D et Ggal : Pas sûr que le point haut soit nécessaire ni habituel après un exposant, dans les cas comme m³s^–1 ou m^–1K^–1 (avec peut-être espace au milieu, à vérifier), peut-être que dans ce cas il pourrait correspondre uniquement à un point explicitement mis dans le paramètre ? — Oliv☮ ^{Éppen hozzám?} 26 avril 2015 à 14:31 (CEST)

Il s'agit du point à mi-hauteur [⋅], 22C5 en Unicode (ou opérateur point selon la norme ISO/CEI 10646). &sdot; ou &#x22c5; en HTML, et \cdot en LaTeX. La norme ISO 80000-1:2009 précise au § 7.2.2 Composition des symboles d'unités « Une unité composée, formée en multipliant deux unités ou plus, doit être indiquée d'une des manières suivantes : N ⋅ m, N m . La dernière forme peut aussi être imprimée sans espace, c'est-à-dire Nm, à condition de faire particulièrement attention quand le symbole de l'une des unités est le même que le symbole d'un préfixe. C'est le cas pour m, mètre et milli, et pour T, tesla et téra. Exemple mN signifie millinewton, et non mètre newton.

Une unité composée, formée en divisant une unité par une autre, doit être indiqué d'une des manières suivantes : ${\rm {\tfrac {m}{s}}}$ , m/s, m · s⁻¹, m s⁻¹ ». De nombreux exemples sont donnés au paragraphe 6.5.3 Unités dérivées, et c'est bien le point qui est utilisé. Voir également la brochure du BIPM, § 5.1 Symboles des unités :« La multiplication doit être indiquée par un espace ou un point à mi-hauteur centré (⋅), pour éviter que certains préfixes soient interprétés à tort comme un symbole d’unité ». Il vaut mieux ne pas prendre de risque, et de faire figurer le point à mi-hauteur centré [⋅]. Cdlt, --Ggal (discuter) 26 avril 2015 à 18:01 (CEST)

Ainsi donc selon la norme la forme sans point est possible, et pas seulement après un exposant. Comme elle est nettement plus répandue dans les sources scientifiques et techniques, mieux vaut que ce soit le comportement par défaut (plutôt avec un espace comme dit la norme dont l'exemple mN est convaincant), et réserver le point centré à une demande explicite de l'utilisateur telle qu'un point (.) dans le paramètre. — Oliv☮ ^{Éppen hozzám?} 26 avril 2015 à 18:13 (CEST)

La saisie ou non de points par les contributeurs risque d'être trop incohérentes, surtout pour les ajouts sur les articles ou il y a déjà des modèles avec unités séparées en autant de paramètre. Je met le séparateur que vous voulez, mais toujours le même. On peut par contre avoir un paramètre en option pour signaler le désir d'avoir un autre type de séparateur. Dans ce cas c'est forcément un choix assumé du contributeur. – Zebulon84 (discuter) 26 avril 2015 à 22:01 (CEST)

Alors le défaut correspondrait à la forme la plus fréquente pour la multiplication, l'espace (insécable je suppose), et le paramètre optionnel au point centré ? — Oliv☮ ^{Éppen hozzám?} 27 avril 2015 à 08:30 (CEST)

Oui, vraiment bravo ! Concernant les espaces autour de '×' ou '·', il me semble qu'il faudrait, comme pour '=', '+', '−' et ':' (de même que pour '?' et '!' mais la logique est un peu différente), mettre une espace insécable avant mais une espace ordinaire après. Dans certains cas l'accumulation d'espaces insécables donne un rendu inesthétique. — Ariel (discuter) 27 avril 2015 à 11:22 (CEST)

Il s'agit ici d'unités, donc la convention est : espaces insécables pour les symboles d'unités, et entre la valeur numérique de la grandeur et le symbole d'unité (sauf pour les unités sexagésimales et les degrés d'alcool). --Ggal (discuter) 28 avril 2015 à 08:20 (CEST)

J'ai mis en ligne une nouvelle version :

• ajout d'infobulle avec le nom complet de l'unité (dites-moi si vous trouvez des unités qui manquent, ou des textes incorrects) ;
• ajout des paramètres et, à, – (tiret demi-cadratin), ±
• suppression de la syntaxe avec e ou 10 en tant qu'unité : le modèle actuel ne l'accepte pas, et avec la syntaxe en un seul paramètre, ça perd de son intérêt ;
• espace insécable unique entre les unités (c'est un détail, on peut revenir dessus).

L'idée est d'avoir les mêmes fonctionnalités que {{Unité/2}}.

Zebulon84 (discuter) 30 avril 2015 à 17:14 (CEST)

Pour les préfixes binaires, c'est zébi (avec accent aigu, comme mébi, tébi, pébi). Contrairement au système SI, le symbole du préfixe kibi est Ki, et non ki (norme CEI). Ggal (discuter) 2 mai 2015 à 13:46 (CEST)

Merci, ce sera corrigé lors de la prochaine mise à jour. – Zebulon84 (discuter) 2 mai 2015 à 13:59 (CEST)

Les signes moins en exposant sont encore des traits d'union et pas de vrais signes moins, contrairement à ce que Utilisateur:Zebulon84 annonce ici :

« * affiche un vrai signe moins, pour les nombres et les unités : {{Unité/Bac à sable|-1500|ft||min|-1}} → −1 500 ft min⁻¹ »

Maggyero (discuter) 14 septembre 2015 à 11:23 (CEST)

Eh, Zebulon84, faudrait aussi mettre à jour la doc, car certains continuent de remplacer les virgules à la pelle, travail qui fut fort louable mais qui est devenu une perte de temps. — Ariel (discuter) 22 mai 2017 à 22:57 (CEST)

 Ariel Provost : je ne me suis pas précipité, attendant de voir s'il y avait des problèmes signalés obligeant à faire marche arrière le temps de corriger les bugs, mais il est effectivement certainement temps de s'y mettre. J'ai ajouté différentes possibilités, mais c'est certainement améliorable, je ne suis pas champion des documentations. — Zebulon84 (discuter) 23 mai 2017 à 14:04 (CEST)

Espaces insécables autour de ×

Veuillez faire en sorte que le symbole × soit entouré d'espace insécables. Merci. Ramzan (discuter) 8 août 2016 à 23:02 (CEST)

D'ailleurs, le signe « × » ne doit-il pas plutôt être un point dans ce cas ? Du moins, en notation française où nous utilisons la virgule pour marquer les décimales. Cdt. --Gkml (discuter) 9 août 2016 à 08:03 (CEST)

Conflit d’édition —  Ramzan : c'est prévu ci-dessus dans #Nouvelle version à tester,  Zebulon84 : utiliser Module:Unité est toujours prévu ? — Oliv☮ ^{Éppen hozzám?} 9 août 2016 à 08:04 (CEST)

L'usage courant serait plutôt l'espace. Le point se rencontre fréquemment aussi, mais il doit alors être centré, pas inférieur. Mais le signe de multiplication « × » est plus clair tout en restant relativement discret, je préfère. Maintenant, s'il y a une vraie norme quelque part... Ariel (discuter) 9 août 2016 à 09:11 (CEST)

En effet, il existe des textes à ce sujet :

Norme internationale ISO 80000-1:2009, Grandeurs et unités — Partie 1: Généralités

§ 7.1.3 Combinaison des symboles de grandeurs : « Des espaces doivent être placés de chaque côté de la plupart des signes pour les opérateurs dyadiques tels que +, ±, , et · (mais pas pour la barre oblique) ».

FD X 02-003 (AFNOR) Normes fondamentales — Principes de l'écriture des nombres, des grandeurs, des unités et des symboles,

§ 4.3 Multiplication « Le signe de la multiplication est la croix (×) ou le point à mi-hauteur ou point médian (⋅) [22C5] et non pas le point sur la ligne (.) ou la lettre x. Un espace doit se trouver de chaque côté de la croix ou du point. »

La brochure du BIPM ne donne pas de règle, mais respecte cette notation.

Cdlt, --Ggal (discuter) 9 août 2016 à 12:15 (CEST)

Merci pour ce rappel.

Personnellement, je préfère le point (à mi-hauteur) qui m'apparaît encore plus discret, dans le cas de la notation française des nombres. En outre, il me semble le plus utilisé dans la communauté scientifique française (du moins de ce que j'ai vu dans mes études d’ingénieur et revois ces temps-ci en aidant mes fils à la préparation des concours aux GE) : je ne serais toutefois pas affirmatif ne baignant pas en permanence dedans ; en tout cas, je ne pense pas avoir déjà vu le signe « x » utilisé avant cette exploration du modèle {{unité}} de fr.wiki.

Concernant les espaces, je présume qu'il s'agit des espaces fines insécables, l'espace de base apparaissant d’un encombrement excessif.

Cdt. --Gkml (discuter) 9 août 2016 à 13:28 (CEST)

Si vous ne pouvez pas consulter ces normes, voir la brochure du BIPM, Cdlt, --Ggal (discuter) 9 août 2016 à 13:38 (CEST)

Espace et point médian sont les plus utilisés dans la communauté scientifique francophone certes, mais le signe « × » est moins ambigu, s'adressant à un public plus général. Il a aussi le mérite d'être plus international (cf. CODATA), par exemple. Ariel (discuter) 9 août 2016 à 15:55 (CEST)

Espace insécable avant un symbole

Le guide de typographie suivant : [12] limite l'usage de l'espace insécable entre un nombre et une unité aux symboles seulement. La logique qui supporte cela — j'imagine — est que le renvoi à la ligne de l'ensemble nombre-symbole ne risque pas de créer des dents de scie disgracieuses en marge droite, car les symboles sont abréviés, donc courts. À choisir entre le sacrifice de l'esthétique et la séparation d'un nombre du mot qui le suit logiquement, le guide fait la deuxième recommandation.

A-t-on une référence de guide de typographie pour justifier d'étendre l'espace insécable aux cas autres que des symboles ? L'habitude dans Wikipédia est de ne pas inventer des règles de typographie spécifiques. Je ne trouve que le guide ci-dessus comme référence externe.

Vincent Lextrait (discuter) 2 décembre 2016 à 19:25 (CET)

C'est-à-dire « {{num|10000|km}} » mais « {{num|10000}} habitants » ? — Oliv☮ ^{Éppen hozzám?} 2 décembre 2016 à 20:10 (CET)

Exactement. Vincent Lextrait (discuter) 2 décembre 2016 à 20:37 (CET)

Bonjour,

Vincent fait sans doute allusion au chapitre ABC de la typographie, page 12, article Espace insécable, qui dit : « Par exemple, on utilise une espace insécable entre le nombre et le symbole qui le suit… ». Ce n'est donc qu'un exemple.

Dans le même ouvrage, le chapitre Coupures de l'édition 2012, page 114 (sans doute de même pour l'édition 2014) on lit : « Le nombre en chiffres doit rester avec le mot qu'il accompagne, c'est-à-dire le mot qui le suit ou celui qui le précède, selon le cas : Chapitre II, art. 3, Henri IV, page 324, 3. Coupures.

De même, le Lexique des règles typographiques, article coupure des mots, page 61 : « Un nombre en chiffres arabes ou romains ne sera jamais séparé du nom qui le précède ou qui le suit. On ne coupera pas :

10/décembre/1969 (mais on pourra admettre 10 décembre [1969)

livre/III

300/kilomètres

in-/8^o

Cdlt, Ggal (discuter) 2 décembre 2016 à 21:52 (CET)

C'est super, merci ! Vincent Lextrait (discuter) 2 décembre 2016 à 23:23 (CET)

Décimales

 Starus : j'ai ajouté à la version /Bac à sable un paramètre décimales pour déterminer le nombre de décimales affichées :

• {{Unité/Bac à sable | 123,45678 | décimales=-1}} → 120
• {{Unité/Bac à sable | 123,45678 | décimales=1}} → 123,5
• {{Unité/Bac à sable | 123,45678 | décimales=6}} → 123,456 780
• {{Unité/Bac à sable | 1,2345 e5 m3 | décimales=1}} → 1,2 × 10⁵ m³
• {{Unité/Bac à sable | 1,2345 e5 m3 | décimales=6}} → 1,234 500 × 10⁵ m³

Est-ce que cela correspond à ce que tu recherches ?

 Ariel Provost : aussi en test sur la version /Bac à sable, lorsqu'il n'y a que 4 chiffres après la virgule, il n'y a pas d'espace.

• {{Unité/Bac à sable | 0,1234}} → 0,123 4
• {{Unité/Bac à sable | 0,1234567 | décimales=4}} → 0,123 5

Je ne sais pas comment afficher 7 chiffres après la virgule, donc pour le moment c'est inchangé :

• {{Unité/Bac à sable | 0,1234567}} → 0,123 456 7

Qu'en penses-tu ?

— Zebulon84 (discuter) 17 mai 2017 à 16:29 (CEST)

Merci Zebulon84  : oui, c'est tout à fait ça. Mon impression est qu'il ne faudrait jamais laisser une décimale isolée avec une espace devant (donc plutôt 0,123 4567 que 0,123 456 7) mais j'ai peur de faire du TI (et de t'y entraîner), car je ne sais pas du tout où ça peut être codifié (ça l'est sûrement quelque part) ni si cette codification (ou mieux, des codifications contradictoires, on en voit ailleurs) nous laisse une marge de manœuvre ou pas. — Ariel (discuter) 17 mai 2017 à 16:40 (CEST)

P.S. Dans le texte une décimale isolée fait bizarre et peut être mal interprétée, mais dans une colonne de tableau c'est différent.

Le Lexique, page 124, indique : « Les nombres exprimant une quantité s'écrivent par tranches de trois chiffres (tranches de mille) séparées par une espace insécable et non dilatable, tant pour la partie entière que pour la partie décimale. Ces groupes sont constitués en allant vers la gauche pour la partie entière, vers la droite pour la partie décimale, à partir de la virgule :
    78 835,140 71 »

Donc l'impression qu'il ne faudrait « jamais laisser une décimale isolée avec une espace devant » n'existe pas. Voir ici : Wikipédia:Conventions concernant les nombres#Pour un comptage ou une mesure.

Cordialement, Daniel*D, 24 mai 2017 à 01:29 (CEST)

Moi je voulais surtout cela : 123,40, et ça marche parfaitement bien. Merci beaucoup Zebulon84 — S t a r u s – ¡Dímelo! – 25 mai 2017 à 03:48 (CEST)

Note que je répondais juste à l'interrogation sur l'histoire de la décimale isolée . Et je remercie aussi beaucoup Zebulon84 pour sa version Lua du modèle qui libère grandement la contribution. Cdlt, Daniel*D, 25 mai 2017 à 16:00 (CEST)

Espace indésirable

Il y a une différence de rendu et une faute typographique selon qu'un nombre est suivi d'une unité ou utilisé seul, quand il est suivi d'un signe de ponctuation simple (point ou virgule) :

• 1 000 m, d'une part (typo correcte, pas d'espace devant la virgule) ;
• 1 000, d'autre part (typo incorrecte, espace introduite automatiquement devant la virgule).

J'imagine que c'est lié à une certaine modification de Zebulon84 (d · c · b) sur Module:Unité, sans en avoir la certitude ni parvenir à voir laquelle ; et en même temps je n'ai pas trop cherché. S'il s'agit de forcer les contributeurs à utiliser formatnum lorsque le nombre n'est pas suivi d'une unité, il faudrait au préalable s'assurer de circonscrire le problème sur des milliers d'articles en faisant passer un bot.
Salutations. Gemini1980 oui ? non ? 24 mai 2017 à 00:33 (CEST)

Forcer les contributeurs à utiliser {{formatnum:}} (même lorsque le nombre n'est pas suivi d'une unité) serait une régression. Tant ce mot magique mal conseillé introduit de fautes de typographie dans les articles. C'est plutôt lui qui devrait être « interdit ». Cdlt, Daniel*D, 24 mai 2017 à 01:13 (CEST)

Corrigé. Loin de moi l'idée d'imposer formatnum, c'est simplement que j'ai fait mes tests avec le modèle seul, donc je n'ai pas repéré ce bug. — Zebulon84 (discuter) 24 mai 2017 à 08:25 (CEST)

Concernant formatnum, ce n'est pas ce que dit la documentation du modèle:unité ; pour le moment, c'est surtout une question d'habitude des uns et des autres. Merci à Zebulon84 pour le correctif. Gemini1980 oui ? non ? 24 mai 2017 à 12:50 (CEST)

Ce que dit la doc sur {{formatnum:}} est le fruit d'un compromis (entre Akeron et moi), ce qui ne m'empêche pas de donner mon avis perso en pdd. Sinon, je me doute bien que Zebulon84 n'a aucune envie d'en imposer l'usage et je le remercie de nouveau pour ses améliorations des modèles. Cdlt, Daniel*D, 25 mai 2017 à 16:05 (CEST)

Surinterprétation

Bizarre, le code {{unité|270000|a-l}} (a-l = années-lumière) donne 270 000 a-l, avec un trait d'union pris d'un accès de lévitation subite. — Ariel (discuter) 27 mai 2017 à 18:53 (CEST)

 Ariel Provost : j'avais effectivement repérer ce bug il y a deux jours, mais j'avais autre chose de plus urgent à faire, puis je l'ai totalement oublié. Ceci-dit Année-lumière indique que son symbole est « al », qui est correctement géré (avec une infobule indicant le nom de l'unité en toute lettre) : 270 000 al

Corrigé partiellement. Comme je ne suis pas vraiment satisfait de la solution, j'ai ajouté une catégorisation temporaire. — Zebulon84 (discuter) 27 mai 2017 à 22:44 (CEST)

problème de m/s

Le code {{unité|3|e=8|m/s}} me semble parfaitement légitime et sortait correctement, et désormais il donne 3 × 10⁸ m/s (voir historique de Longueur d'onde). Le changement a dû affecter une quantité de pages. PolBr (discuter) 29 mai 2017 à 10:07 (CEST)

• {{unité|3|e=8|m}} donne 3 × 10⁸ m
• {{unité|3|e=8|m||s|-1}} donne 3 × 10⁸ m s⁻¹
• {{unité|3 e8 m/s}} donne 3 × 10⁸ m/s

Apparemment, c'est la barre oblique qui cause le défaut, quand il y a un paramètre e=. Elle est d'usage courant, et on n'est pas obligé d'infliger au lecteur novice la notation « scientifique ». PolBr (discuter) 29 mai 2017 à 10:14 (CEST)

 PolBr : corrigé, merci de l'avoir signalé. — Zebulon84 (discuter) 29 mai 2017 à 14:15 (CEST)

Mise à jour des docs

Maintenant que le modèle {{Unité}} gère les espaces des chiffres après la décimale, il faudrait mettre à jour un certain nombre de documentations qui préconisent de gérer soi-même ces espaces. J'ai repéré Wikipédia:Conventions typographiques#Nombres et espaces et Wikipédia:Conventions concernant les nombres#Usage des espaces insécables mais il y en a peut-être d'autres. — Ariel (discuter) 8 juin 2017 à 09:19 (CEST)

Âges : « an » comme abréviation d’« année »

J’ai été très surpris en passant ma souris sur « 135 ans ». Pourquoi considérer que « an » est une abréviation d’« année » ? J’ai personnellement déjà vu « a » comme symbole pour « année », mais jamais « an ». Je peux me tromper, mais même si « an » est effectivement une abréviation correcte et utilisée, je ne pense pas que ça soit le cas pour « ans » (pluriel). – Pols12 (discuter) 22 juillet 2017 à 23:31 (CEST)

 Pols12 : le modèle ne connais pas le contexte, et suppose donc que {{unité|135 a}} signifie 135 ares, et affiche 135 a (avec « are » en infobulle).

Il ne me semble pas qu'il y ait de symbole officiel pour l'année, chaque langue utilisant plus ou moins la ou les premières lettres du mot année. Le modèle considère « an » et « ans » comme symbole de l'année, car je suis parti du modèle {{Unité/2}} pour mettre en place les conversions entre unités, et que je n'avais pas encore complètement décidé de ce que je voulais en faire. A postériori, comme je n'ai pas repris la conversion année → secondes, et que je n'utilise de toute façon pas le symbole, je pourrais sans doute supprimer ça. Je vais cependant vérifier l'impact avant de le faire. — Zebulon84 (discuter) 23 juillet 2017 à 00:53 (CEST)

An est un synonyme d'année, pas une abréviation. Le choix entre an et année varie un peu selon les régions et les générations, et selon le contexte, souvent pour des raisons d'euphonie. Notamment, on utilise an pour les âges (hommes, roches, etc.) mais on parle de milliers, millions ou milliards d'années. Le symbole « a » est ambigu (ares ou ans) mais le contexte prête difficilement à confusion. Par contre les symboles des multiples sont sans équivoque : ca et ha d'un côté (centiares et hectares), ka, Ma et Ga de l'autre (milliers, millions et milliards d'années). Je ne vois pas comment aider le modèle à lever l'ambiguïté de « a », mais pour les multiples il devrait pouvoir se débrouiller tout seul. — Ariel (discuter) 24 juillet 2017 à 09:33 (CEST)

 Pols12 : J'ai retiré an et ans de la table des unités.

 Ariel Provost : Je n'ai pas l'intention de gérer deux unités pour un symbole en fonction du préfixe, sauf si on me montre que le modèle est déjà utilisé avec ka, Ma et Ga pour multiple d'années (julienne ?) sur un certain nombre de pages. S'il s'agit de distance, le symbole al est défini comme symbole d'année-lumière (et je me demande s'il faut ajouter ly en alias). — Zebulon84 (discuter) 24 juillet 2017 à 09:58 (CEST)

235 ca, 13 ha, 153 ka, 15 Ma et 4,55 Ga : le modèle {{Unité}} fonctionne déjà correctement pour ca (centiare), ha (hectare), ka (millier d'années) et Ma (million d'années), mais pas pour Ga (gigaare ?? jamais vu !). On utilise de façon standard le Ga (milliard d'années) pour les âges des météorites et les subdivisions de l'histoire géologique (Terre, Mars, Lune), voir par exemple Histoire de la Terre. — Ariel (discuter) 24 juillet 2017 à 10:18 (CEST)

Pour moi c’est bon. Merci Zebulon84 ! – Pols12 (discuter) 25 juillet 2017 à 11:49 (CEST)

Bon, à moins que quelqu'un m'exhibe Ga utilisé comme symbole du gigaare voire, plus difficile, me montre qu'il est plus utilisé ainsi que comme symbole du milliard d'années, je m'en vais modifier le modèle {{Unité}} dans ce sens (et {{Unité/2}} aussi, pour ceux qui s'en servent encore). — Ariel (discuter) 25 juillet 2017 à 14:19 (CEST)

 Ariel Provost : sincèrement je n'avais jamais vu Ga utilisé pour Giga année avant cette discussion non plus. Vu qu'il est plus facile que je ne l'imaginais de créer cette unité (merci de m'avoir signalé ka et Ma, je ne me souvenais plus avoir fait ça), j'ai ajouté Ga de la même manière : a est toujours défini pour are, mais comme le modèle vérifie l'unité complète avant d'essayer de décomposer en multiple-unité, Ga défini en tant qu'unité est prioritaire. Si je comprends bien ces années sont des années juliennes, d'exactement 365,25 × 86 400 secondes. Pas forcément évident pour tout le monde. — Zebulon84 (discuter) 26 juillet 2017 à 05:13 (CEST)

Merci Zebulon84 . Deux remarques : (1) même les anglophones utilisent de plus en plus Ga (giga annum) au lieu de Gy (giga year), par souci d'internationalisation ; (2) quand on parle de milliards d'années, qu'il s'agisse de théorie ou de datation, peu importe en pratique qu'il s'agisse d'années juliennes, sidérales, tropiques ou autres, vu l'incertitude sur ces âges. — Ariel (discuter) 26 juillet 2017 à 06:56 (CEST)

Livre sterling et livre de poids

Bonjour,

Dans l'article Dette étudiante, section Royaume-Uni, j'ai voulu utiliser le modèle unité pour décrire un coût de 3000 livres sterling : l'unité monétaire : 3 000 £. Cependant, lorsque je passe ma souris sur le texte, j'obtiens 1360,77711 kg ce que je pense être l'équivalent en poids de de 3000 Livre (unité de masse). Je précise que j'ai pris le symbole livre de mon clavier azerty, qui correspond a priori un symbole monétaire. Du coup, je voulais savoir s'il n'était pas préférable d'afficher plutôt un équivalent en euros, dollar, dollar canadien, ou votre monnaie préférée, voire de choisir s'il doit s'agir d'une masse ou d'une monnaie ? Tpe.g5.stan (discuter) 18 août 2017 à 14:42 (CEST)

 Tpe.g5.stan : la conversion se base sur le nom de l’unité en toute lettre (affiché en infobulle), et il y a actuellement le même mot « livre » pour l'unité de masse et la monnaie, d'où la conversion erronée. Merci de l’avoir signalé. Le symbole « £ » étant surtout associé à la livre sterling, je vais probablement modifier le texte en « livre sterling » pour ne pas avoir de conversion.

Le symbole de l'unité de masse est « lb »

Il n'est pas prévu de conversion pour les monnaies, car ce n'est pas fixe dans le temps, donc ça ne serait jamais exact.

— Zebulon84 (discuter) 18 août 2017 à 15:21 (CEST)

OK, merci . Tpe.g5.stan (discuter) 18 août 2017 à 15:27 (CEST)

Dollard

Lorsque le modèle Unité est utilisé et qu'on place la souris sur le signe de $, la bulle affiche "Dollard" au lieu de "Dollar". Oopsie. Test : 200 $. InMontreal (discuter) 7 septembre 2017 à 15:53 (CEST)

@InMontreal : Corrigé, merci de l’avoir signalé. — Thibaut (discuter) 7 septembre 2017 à 16:01 (CEST)

Désolé, je ne sais pas pourquoi j'ai toujours tendance à ajouter un « d » à dollar. — Zebulon84 (discuter) 7 septembre 2017 à 16:49 (CEST)

Bonsoir Zebulon84, observation tardive : cela doit venir de « polard » comme l'on dit en CPGE, cf. l'argot scolaire, où le terme mériterait d’être cité (= « travailleur excessif », d'où le verbe « polarder » = « travailler à l’excès et sans finesse »). Cdt. --Gkml (discuter) 8 novembre 2017 à 20:18 (CET)

Petit problème avec le modèle

Bonjour, j'ai constaté un petit problème avec l'utilisation du modèle sur la page Mikoyan-Gourevitch MiG-25 : {{nombre|8|MiG-25RB}} rend 8 MiG-25RB. Y a-t-il un moyen d'éviter la mise en exposant du nombre qui se trouve dans l'unité ? Amicalement, rob1bureau (discuter) 8 novembre 2017 à 19:56 (CET)

Bonjour Rob1bureau, pour les nombres plus petits que 999, vous n’avez pas besoin d’utiliser {{nombre}}.

Donc vous écrivez {{nobr|8 MiG-25RB}} (ce qui donne : « 8 MiG-25RB »), et tout va bien, comme cela vous est conseillé dans WP:TYPO#NON CÉSURE NOMBRE NOM.

Si vous avez plus de {{unité|1000 MIG-25RB}} (soit 1 000 MIG⁻²⁵ RB), c’est une autre histoire… Vous utilisez alors le modèle {{nobr}} en lieu et place exceptionnellement, ce qui donne : {{nobr|1 000 MIG-25RB}} (soit 1 000 MIG-25RB), ceci en attendant que le bogue soit résolu, mais cela en vaut-il la peine, sachant le peu de cas similaires rencontrés ?

Cdt. --Gkml (discuter) 8 novembre 2017 à 20:08 (CET)

Merci Gkml, j'ai pu corriger la page. Pour les nombres >1000, il peut y avoir des cas sur les pages d'avions plus anciens, notamment 2ème GM. Mais bon, on fera autrement. Merci, rob1bureau (discuter) 8 novembre 2017 à 23:15 (CET)

Propositions changements redirections/aliases

Bonjour,

J'aurais quelques idées pour remanier les redirections/aliases de ce modèle :

• (–) kicker les redirections "NaU" et "Nau", dont les noms ne sont vraiment pas explicites… (pour ceux qui n'auraient pas saisi, c'est l'abréviation de « nombre avec unité »…)
• (=) "nombre" est très bien, on le garde
• (=) "num" pas terrible (anglois "number" ? "numéro" ? les deux sont mauvais), mais il est court et certains l'apprécient peut-être, on garde
• (+) éventuellement, ajout de "nb" (le nom est actuellement pris, mais je peux le libérer)

Qu'en pensez-vous Fatima ? od†n ↗^blah 24 décembre 2017 à 02:35 (CET)

D'accord sauf peut-être pour {{nb}}. Cdlt, Daniel*D, 24 décembre 2017 à 13:42 (CET)

Après quelques recherches, c'est marrant, j'ai l'impression d'être le seul à être à l'aise avec "nb" pour "nombre" (et non "numéro"), tant en français qu'en anglois. od†n ↗^blah 25 décembre 2017 à 04:17 (CET)

La redirection {{num}} est effectivement maladroite. Elle n’est utilisée que sur un peu plus de 2 000 articles. Elle serait mieux à rediriger vers {{numéro}}, comme le fait {{n°}} ; resterait à effectuer les modifications des quelque 2 000 articles concernés.

Quid de {{un}} qui serait probablement une meilleure abréviation que {{nb}} ?

Cdt. --Gkml (discuter) 25 décembre 2017 à 08:21 (CET)

Pas fan de {{un}} pour ma part… Il faudrait qu'on détermine un raccourci de modèle court, les noms actuels {{NaU}}, {{Nau}} et {{Num}} n'étant pas terribles (mais ayant au moins le mérite d'exister).

Mais je crois que je viens de trouver LA solution : ça ne vous dirait pas de libérer le raccourci {{n}} ? 😃

od†n ↗^blah 28 décembre 2017 à 09:43 (CET)

Pourquoi pas à propos de {{N}}, d’autant qu'il n'a été utilisé qu'une vingtaine de fois, c’est cent fois mois de travail que pour {{Num}}.

Cdt. --Gkml (discuter) 28 décembre 2017 à 12:39 (CET)

Contre {{un}}, qui ramène à la notion d'unité (qui était un mauvais choix de départ), alors que ce modèle s'applique pour tous les nombres, pas seulement les unités. Pourquoi pas {{nb}} (le plus parlant) ou {{N}}, {{nombre}} étant le meilleur nom en étendu pour ce modèle. Cependant, rappelons-nous qu'à la suite des renommages de modèles, les versions historisées des articles deviennent parfois illisibles.--Rehtse (échanger) 28 décembre 2017 à 14:04 (CET)

Le modèle s'applique aux nombres et principalement aux unités (ce même s'il sert souvent à « compter » autre chose que des unités) : il me semble donc que ce n'est pas tant ridicule que cela de l'avoir appelé {{unité}}, même si à la différence du sucre (en poudre ou en morceaux) des années 1990 « je n'étais pas là ! »… au moment du choix du nom de baptême.

En outre, ce n'est pas forcément mauvais d’avoir une alternative à {{nombre}} car les débutants confondent souvent ce modèle avec {{nobr}} (i. e. en anglais : no-break, ce qui permet donc d’éviter les passages à la ligne disgracieux).

En résumé, rien d’aussi simple que cela peut en avoir l’air.

Cdt. --Gkml (discuter) 28 décembre 2017 à 15:09 (CET)

P.-S. : de toute façon, personnellement je pense avoir utilisé {{unité}} des dizaines de milliers de fois (finalement je l’ai préféré à {{nombre}} en raison de la possible ambiguïté dont je viens de parler), et je n'ai jamais eu besoin d'utiliser des abréviations, ce qui évite les méprises. Je serais donc plutôt favorable à réduire ces (plus qu'accessoires) possibilités d’abréviation que l'inverse, cela permettant de rendre le code plus facilement et rapidement déchiffrable. Avec copier (une fois)-coller (« n » fois), ce n'est vraiment pas un problème d’en mettre autant que nécessaire. --Gkml (discuter) 28 décembre 2017 à 15:09 (CET)

Le modèle ne doit pas s'appliquer principalement pour les unités, il doit s'appliquer dès qu'un nombre en chiffres définit un mot et qu'il y a risque de césure entre les deux, donc unité est trop limitatif.--Rehtse (échanger) 28 décembre 2017 à 16:03 (CET)

Au risque de dire une évidence, je rappelle quand même qu'historiquement, le modèle était spécifiquement prévu pour les nombres avec unité, et par rapport à {{formatnum:}}, servait à avoir aussi l'insécabilité entre le nombre et l'unité. Pour le reste (nombres sans unité), {{formatnum:}} était indiqué. Mais maintenant, on peut considérer que {{unité}} et {{nombre}} sont équivalents, le choix d'un nom ou l'autre étant une question de préférence personnelle ou de contexte. od†n ↗^blah 28 décembre 2017 à 16:25 (CET)

Tout à fait d'accord, il faut maintenir les deux, je ne faisais que répondre à la suggestion d'un usage exclusif d'« unité ». Pour ce qui est des abréviations, la différence de nombre de caractères entre « unité », « nombre », « nb », « unit » ou « num » étant faible, il n'y a effectivement pas grande nécessité.--Rehtse (échanger) 28 décembre 2017 à 16:40 (CET)

D'accord avec cela. C'est en fait {{formatnum:}} qui devrait être fortement déconseillé. Cdlt, Daniel*D, 4 janvier 2018 à 00:13 (CET)

┌───────────────────────┘
Pour essayer de refaire avancer le sujet, pourriez-vous ajouter/confirmer vos avis concernant l'ajout de raccourci {{n}} et/ou {{nb}} ? (pour rappel, cela viendrait remplacer les infâmes {{NaU}} et {{Nau}}) – od†n ↗^blah 6 mars 2018 à 02:55 (CET)

Il me semble que {{nb}} serait utile, comme abréviation usuelle de « nombre ». Je pense qu'on pourrait libérer les actuels {{nb}} et {{nn}} en les remplaçant par {{no-bok}} et {{no-nyn}} (j'imagine que le nom de modèle {{nn}} pourra trouver un usage moins particulier que l'actuel). — Ariel (discuter) 10 mars 2018 à 17:34 (CET)

od†n : Pour l'utilisation de « n » et « nb », pour la « suppression » de « NaU » et « Nau ».--Rehtse (échanger) 10 mars 2018 à 19:02 (CET)

Pour ne pas multiplier les raccourcis, je pense qu'il faudrait prendre un seul parmi « n » et « nb ». Pour ma part je n'arrive pas à trancher… od†n ↗^blah 11 mars 2018 à 07:58 (CET)

S'il faut choisir je privilégie « nb », qui reste très court et n'est guère ambigu. Ariel (discuter) 11 mars 2018 à 08:36 (CET)

Ok pour nb.--Rehtse (échanger) 11 mars 2018 à 10:09 (CET)

Je me suis aussi décidé pour {{nb}}, car je trouve {{n}} "trop court". Ça nous donne au final {{unité}}, {{nombre}} et {{nb}} ; ça me plaît. En prime on évite la confusion (même si c'est un peu chercher loin) "mais euh il y a {{n}} pour "nombre" mais pas {{u}} pour "unité" (nom déjà pris). od†n ↗^blah 13 mars 2018 à 07:52 (CET)

J'ai avancé un peu sur cette histoire. J'ai libéré le nom de modèle "nb" et créé le raccourci. Ensuite, je viens de modifier toutes les inclusions "NaU" et "Nau" vers "unité", et toutes les inclusions "num" vers "nb". Je laisse fonctionnels ces anciens raccourcis, au moins pour l'instant, surtout par précaution et aussi pour ne pas impacter les versions historisées des articles. od†n ↗^blah 23 mars 2018 à 04:23 (CET)

Merci od†n.--Rehtse (échanger) 23 mars 2018 à 07:38 (CET)

Oui, Merci Od1n pour tout ce boulot. — Ariel (discuter) 23 mars 2018 à 07:52 (CET)

J'hésite à remettre le raccourci {{num}} dans la documentation, car certains utilisateurs semblent tenir à ce raccourci. Pour être bien clair : en supplément de {{nb}}, pas en remplacement. Votre avis ? od†n ↗^blah 3 mai 2018 à 22:10 (CEST)

À mon avis c'est surtout utilisé par habitude, pas grand monde vérifie les documentations des modèles simples à chaque utilisation. Il faut garder la redirection, ne serait-ce que pour éviter la création d'un équivalent inutile à en:template:num. Mais on est pas obligé d'en faire la pub sur la documentation. — Zebulon84 (discuter) 4 mai 2018 à 05:35 (CEST)

Nous sommes bien d'accord pour conserver la redirection {{num}}. Pour la documentation, tes arguments se tiennent. Ok pour ne pas remettre le raccourci dans la documentation, et si dans le temps il s'avère que, spontanément, il redevient significativement utilisé, on pourra toujours reconsidérer cela. od†n ↗^blah 4 mai 2018 à 23:40 (CEST)

ppm et ppb, pas dpm ni dpb !

Dommage que le modèle soit protégé, je ne peux pas corriger moi-même les fautes de frappe « dartie par million » et « dartie par milliard » (au lieu de « partie par million » et « partie par milliard »), cf. le survol de la souris sur 1 ppm et 1 ppb. — Ariel (discuter) 11 février 2018 à 11:29 (CET)

Ça se trouve dans Module:Unité/Data, que tu peux modifier Les modules de "données" sont habituellement en semi-protection étendue, pour cela justement. od†n ↗^blah 12 février 2018 à 02:21 (CET)

Ah, je le saurai la prochaine fois. Et merci d'avoir fait la modif. — Ariel (discuter) 12 février 2018 à 07:29 (CET)

Support des abréviations "env." ou "env," en plus de "env" ou "environ" avant le nombre (utile pour les infobox)

Bonjour,

En effectuant un peu de maintenance, je suis tombé sur des petits soucis de mise en page causée par des données pas très propre saisies dans des champs d'infobox, qui appellent automatiquement le modèle {{unité}}.

Exemple avec l'{{Infobox Cours d'eau}}, qui possèdent de nombreux champs "quelquechose altitude", qui appellent automatiquement le modèle Unité avec "mètres" comme unité.

Hors ce genre de champ, censé logiquement accueillir des données brutes, propres, accueillent parfois une valeur du genre "env. 2500" ou "env, 2500", parfois cela fausse carrément ce qui est affiché, en ajoutant un 0 devant.

Exemple sur cet article : Aghawagon (d · h · j · ↵), aujourd'hui le code | source principale altitude = env, 4500 donne à l'affichage env0,4500 m (le rouge est de moi), ce qui est faux (virgule après env manquante, un 0 sorti de nulle part apparaît, et séparateur de milliers absent). Il faudrait que cela affiche env, 4 500 m.

Par contre, si j'entre | source principale altitude = env 4500, cela affiche env 4 500 m, ce qui est correct.

C'est assez compliqué, et peu réaliste de chercher à ce que les utilisateurs d'infobox entrent uniquement des données numériques "propres", il faudrait donc pouvoir gérer aussi les cas relativement courants d'abréviation suivie d'un point ou d'une virgule.

Il me semble que le Module:Unité (ligne 235, à la version du jour) possède déjà un bout de code gérant partiellement ces informations parasites, mais il est limité à des données comme "environ 2500" ou "env 2500", est-ce qu'il serait possible d'ajouter le support d'un point ou d'une virgule après le mot ?

Je notifie  Zebulon84, principal contributeur et mainteneur du Module:Unité.

Merci d'avance.

--Tractopelle-jaune (discuter) 20 avril 2018 à 14:28 (CEST)

Je profite du message de Tractopelle-jaune pour signaler un petit bug résiduel : quand on utilise le modèle {{Unité}} pour spécifier une unité mais sans valeur numérique, le modèle la fait précéder d'une espace. On ne s'en rend pas compte si l'on code par exemple en {{unité||m|3}} (résultat : « en m³ ») parce que l'éditeur condense les deux espaces en une, mais le bug apparaît si l'on code ({{unité||m|3}}) (résultat : « (m³) »). — Ariel (discuter) 21 avril 2018 à 08:49 (CEST)

 Tractopelle-jaune et Ariel : normalement c'est corrigé. — Zebulon84 (discuter) 22 avril 2018 à 01:52 (CEST)

Effectivement. Merci Zebulon84 . — Ariel (discuter) 22 avril 2018 à 08:40 (CEST)

Pour moi aussi, c'est bon. Merci Zebulon84 et Od1n pour la correction du module.

--Tractopelle-jaune (discuter) 22 avril 2018 à 13:11 (CEST)

Pas insécable

Bonjour,

La documentation dit que l'utilisation du modèle permet d'« éviter un retour à la ligne automatique entre le nombre et l’unité ou le nom correspondant ». Mais en fait ça ne marche pas. Je viens de lire un article où, en bout de ligne, il y a 1 400, correctement formaté (espace entre 1 et 400) mais le m est rejeté sur la ligne suivante, alors que l'ensemble est écrit ainsi {{unité|1400|m}}. À toute fin utile c'est dans l'article Vallée des Usines. Cordialement Ypirétis (discuter) 10 mai 2018 à 09:02 (CEST)

Chez moi les trois occurrences de {{unité|1400|m}} se comportent normalement. — Ariel (discuter) 10 mai 2018 à 11:32 (CEST)

P.-S. : à propos de l'insécabilité, il me semble que le modèle rend insécables toutes les espaces de son rendu, alors qu'il me semble que seule l'espace entre la valeur numérique (y compris le « ± » le cas échéant) et l'unité (ou le groupe d'icelles) devrait l'être. L'espace après « à », « et » ou « ou » (peut-être aussi le trait-d'union « - », je ne suis pas sûr) devrait être sécable.

Pas de pb me concernant non plus dans le rendu visuel sur l'article.

N'ai pas entièrement compris le P.-S. d'Ariel car le signe d'un nombre fait effectivement partie de celui-ci (corps des nombres rationnels ou réels, anneau des entiers relatifs) et pas les prépositions citées (n'ai jno jamais rencontré de telles insécabilités). Cdt. --Gkml (discuter) 10 mai 2018 à 11:53 (CEST)

Conflit d’édition — Chez moi aussi.

 Ypirétis : pour essayer de trouver le problème, peux-tu nous préciser quel système d'exploitation et navigateur tu utilises ? Et est-ce le 1 400 m de l'infobox, de la « Situation géographique » ou des « Transports » que tu as vu coupé en deux ?

 Ariel : il faut probablement améliorer ce qui est insécable et ce qui ne l'est pas, mais ce n'est pas simple car il y a pas mal de cas possible. Par exemple dans « 2 000 ± 20 N m » tout doit être insécable, mais dans « 800 à 1 200 chrétiens orthodoxes » seule une espace doit l'être. Je regarderai ça de plus près. — Zebulon84 (discuter) 10 mai 2018 à 12:01 (CEST)

En toute rigueur dans 800 à 1 200 m, la seule espace sécable à conserver est celle après le « à » car non plus il ne faut pas laisser le 800 seul. Cdt. --Gkml (discuter) 10 mai 2018 à 12:07 (CEST)

P.-S. : avec l'exemple des « chrétiens orthodoxes », effectivement il y en a une autre, c'est celle entre « chrétiens » et « orthodoxes ».--Gkml (discuter) 10 mai 2018 à 12:09 (CEST)

Gkml, j'aurais dit l'inverse : la seule espace à ne pas conserver est celle après le « à », ainsi on ne laisse pas le 800 seul et on garde la typo habituelle pour 1 200 m.--Rehtse (échanger) 10 mai 2018 à 12:12 (CEST)

Rehtse, j'ai écrit sécable et non insécable. Cdt. --Gkml (discuter) 10 mai 2018 à 12:15 (CEST)

Ah, ok alors on dit pareil.--Rehtse (échanger) 10 mai 2018 à 12:16 (CEST)

 Gkml : Bien sûr que «  le signe d'un nombre fait effectivement partie de celui-ci », c'est pour cela que j'ai spécifié « le trait d'union ». Je faisais référence au paramètre « -= » utilisé pour noter un intervalle comme 100-300. Le signe moins « − » est différent du trait d'union.

 Zebulon84 : Quand tu dis que « dans « 2 000 ± 20 N m » tout doit être insécable » tu as parfaitement raison, c'est pour cela que je précisais « seule l'espace entre la valeur numérique (y compris le « ± » le cas échéant) et l'unité (ou le groupe d'icelles) devrait l'être ». J'aurais du être plus explicite : espaces insécables au sein de la valeur numérique (y compris donc après « ± » et après « × »), entre la valeur numérique et l'unité (ou groupe d'unités), et au sein du groupe d'unités.

 Gkml et Rehtse : D'accord avec Zebulon84 : Dans « 800 à 1 200 chrétiens orthodoxes » la seule espace obligatoirement insécable est entre « 1 200 » et « chrétiens ». Si l'on impose une espace insécable entre « chrétiens » et « orthodoxes », pourquoi pas l'imposer partout entre adjectifs et substantifs, par exemple dans « un grand nombre de chrétiens orthodoxes » ? De même, pourquoi imposer une espace insécable après « à » et pas partout dans n'importe quel texte ? Je ne sais pas quelle règle imposerait une espace insécable entre « 800 » et « à », mais je suis par contre d'accord que ce serait logique, de façon à ne pas prendre « 800 » au pied de la lettre. Problématique identique pour « et » et « ou ». — Ariel (discuter) 10 mai 2018 à 13:33 (CEST)

Ariel Provost, je constate qu'une fois de plus je n’ai pas été compris : j'ai écrit « sécable » et non « insécable ». Il faudrait que je trouve une icône pour demander à mes lecteurs de me lire plus lentement. Cdt. --Gkml (discuter) 10 mai 2018 à 14:27 (CEST)

Désolé, Gkml. Ce n'est pas la première ni la dernière fois qu'en lisant même plusieurs fois on (moi ou d'autres) lit de travers... — Ariel (discuter) 10 mai 2018 à 15:56 (CEST)

Sincèrement j'ai aussi lu « insécable » la première fois. On a si peut l'habitude de lire « espace sécable » que notre cerveau ajoute automatiquement les lettres supposées manquantes.

Merci pour ces retours, j'essaierai d'implémenter ça. — Zebulon84 (discuter) 10 mai 2018 à 16:47 (CEST)

Bonjour, c'est Chrome 66 sous Android 7 et dans le paragraphe Vallée des Usines#Géographie, Situation géographique. Cordialement Ypirétis (discuter) 10 mai 2018 à 16:54 (CEST)

Effectivement, j'arrive à reproduire ça sur Chrome : dans une certaine position il ne respecte pas le CSS white-space: nowrap;, et si j’élargis un tout petit peu la fenêtre, c'est tout d'un coup respecté. Je considèrerai ça comme un bug de Chrome. Ceci-dit, pour résoudre l'autre problème soulevé ci-dessus, je remplacerai peut-être le CSS par des caractères insécables, ce qui devrait résoudre aussi ce souci. — Zebulon84 (discuter) 10 mai 2018 à 17:10 (CEST)

 Ypirétis, Ariel Provost, Gkml et Rehtse : J'ai supprimé le nowrap total, remplacé par des espaces insécables là ou il faut (je n'en ai pas mis du tout autour de à, et, ou). Ceci résout aussi le problème initial selon mes constatations. Si j'ai raté certaines situations qui devrait être insécable, n'hésitez pas à me le signaler. — Zebulon84 (discuter) 13 mai 2018 à 01:20 (CEST)

Merci Zebulon84 . Toujours pas de labels pour les modèles ? C'est trop injuste ! — Ariel (discuter) 13 mai 2018 à 07:53 (CEST)

Pour reformuler ce que j'avais dit (à l'envers) dans mon message du 10 mai ci-dessus ==> (voir supra), dans l'exemple « 800 à 1 200 chrétiens orthodoxes », l'idéal serait de disposer de deux espaces insécables disposées comme suit (je les ai signalées à l'aide du modèle:nobr) : « {{nobr|800 à}} {{nobr|{{formatnum:1200}} chrétiens}} orthodoxes » ce qui donne : « 800 à 1 200 chrétiens orthodoxes ».

Si j'ai bien compris le message de Zebulon84, pour ne pas laisser un nombre « seul » en bout de ligne, ce serait probablement mieux (ce même si la règle typo. n'est pas aussi précise puisqu'elle parle d’un nom) d'en mettre une autre avant les conjonctions ou préposition « et », « ou », « à ».

Merci de votre point de vue.

Cdt. --Gkml (discuter) 13 mai 2018 à 09:20 (CEST)

Bonjour, c'est OK pour moi dans Vallée des usines, merci. Cordialement --Ypirétis (discuter) 13 mai 2018 à 10:38 (CEST)

Je reprends ici pour éviter la confusion de discussion : je serais également favorable à ce que propose Gkml ci-dessus, d'autant que si on ne place pas d'espace insécable avant le « à », à quoi sert cette forme du modèle ? Il serait bien préférable d'écrire 800 à {{nombre|1200 chrétiens}} qui fait exactement la même chose. Le seul intérêt serait lorsqu'on a des nombres supérieurs à 1 000, c'est-à-dire par exemple {{nombre|1100 à 1200 chrétiens}}. Tou dépend bien sûr de la complexité de la programmation nécessaire.--Rehtse (échanger) 13 mai 2018 à 15:03 (CEST)

Suivant de loin cette discussion, j'ai un doute depuis le début sur cette interprétation des règles. Or, à lire Wikipédia:Conventions concernant les nombres#Usage des espaces insécables, ce doute n'est pas levé : « Un nombre en chiffres arabes ou romains ne sera jamais séparé du nom qui le précède ou qui le suit ». J'aurais pour ma part utilisé l'espace insécable entre 1 200 et chrétien, mais uniquement là. Aucune raison, en tout cas, de lier la règle à l'existence du modèle. Cordialement, ---- Ikmo-ned (discuter avec) 13 mai 2018 à 15:59 (CEST)

C'est sûr, Ikmo-ned, tu reproduis ce que j'ai mentionné ci-dessus ==> (voir supra) ; je pense bien connaître les pbs de typo., voir cette stat. et le « camembert de droite, je puis t’affirmer que lorsque le Lexique a écrit cette règle où nous l'avons « pêchée », il n'a pas nécessairement pensé à tous les détails de rédaction ; écrire les règles de typo. n'est pas construire une centrale nucléaire et les rédacteurs du Lexique ne sont pas des équivalents de Frédéric Joliot-Curie en matière de précautions tous azimuts. Il suffit donc d'un peu de bon sens pour se rendre compte que laisser un nombre seul en fin de ligne n'est pas du meilleur effet ; c’est ce qui est décrit dans le Lexique à la p. 61 ; dans notre cas, il faut donc légèrement surinterpréter la littérature du Lexique.

En effet, le Lexique n'a tout bonnement pas pensé à écrire l'exemple « l'an dernier, j'ai peut-être mangé 150 ou 200 salades » ; parce qu'alors, il se serait demandé que doit-on faire pour que le nombre « 150 » ne se retrouve pas seul en fin de ligne (ce qu'il préconise pourtant pour le nombre « 200 ») ? Il me semble donc évident que la ligne en question doive être codée comme suit « […] mangé {{nobr|150 ou}} {{nobr|200 salades}} »… grâce au modèle:unité s'il est prêt à servir à cela.

Cdt. --Gkml (discuter) 13 mai 2018 à 18:52 (CEST)

cc : Rehtse et Zebulon84

Techniquement c'est très facile d'ajouter un espace insécable avant à-et-où. Si je ne l'ai pas fait et l'ai précisé dans mon message précédent, c'est que je ne suis pas convaincu que ce soit nécessaire, ne voyant aucune recommandation spécifique sur ce point. Ceci-dit je modifierai le modèle si j'estime qu'il y a consensus en ce sens, et je n'empêcherai personne de faire la modif. — Zebulon84 (discuter) 13 mai 2018 à 22:17 (CEST)

Faut-il que je propose la modif. des WP:CT à ce propos ? Ce qui peut prendre « un certain temps », sait-on jamais, les discussions à propos de pb typo. étant parmi les plus longues (il y a probablement eu un record battu en mars-avril de cette année… plus de 400 k-octets sur la pdd d'un article… mais cela devrait aller plus vite pour ce cas-là quad même). Comme cela relève du bon sens et d’un oubli évident du Lexique selon moi (comme je viens de le démontrer ci-dessus), si ce n'est pas compliqué, je vais modifier le modèle, sous ta supervision si nécessaire. Cdt. --Gkml (discuter) 13 mai 2018 à 23:29 (CEST)

Années-lumière

Je découvre qu'on ne peut plus changer soi-même le modèle, sinon je l'aurais fait : il faudrait avaliser l'unité « a.l. », aussi correcte que « al » pour « année-lumière », en tout cas tout aussi fréquemment utilisée. Je préconiserais bien d'avaliser aussi « a-l » (également courant), mais l'article Année-lumière ne le mentionne pas. — Ariel (discuter) 16 mai 2018 à 13:27 (CEST)

Désolé d'être méchant, mais :

• le modèle est protégé depuis 2008, 5 ans avant que tu ne t'inscrives sur Wikipédia, donc « on ne peut plus changer soi-même le modèle »...

Ah oui ? Ah d'accord, en fait c'est {{Unité/2}} que j'ai modifié (en 2016).

• par contre le module qui prépare réellement le texte à afficher depuis un an est modifiable par les autopatrolled ;

J'ai ajouté l'alias « a.l. » sur la base de donnée des unités, le module:Unité/Data (dans la liste d'alias en bas du fichier).

— Zebulon84 (discuter) 16 mai 2018 à 20:13 (CEST)

Merci Zebulon84 . — Ariel (discuter) 17 mai 2018 à 07:29 (CEST)

Pluriel dans l'infobulle ?

Bonjour, serait-il concevable (surtout du point de vue de la simplicité du code, et des performances) de mettre les infobulles au pluriel lorsque adéquat ?

Exemple : {{unité|2|€}} (rendu : 2 €), où l'infobulle afficherait « euros », au lieu de l'actuel « euro ».

Je suppose que cela impliquerait d'ajouter une propriété "pluriel" dans Module:Unité/Data.

od†n ↗^blah 22 juillet 2018 à 15:15 (CEST)

 Od1n : ma philosophie était de mettre juste le nom de l'unité. Par ailleurs je ne suis pas sur de savoir s'il faut mettre au plusiel 2,054 572(12) × 10⁻³⁴ kg m² s⁻¹ ou comment ça s'écrit au pluriel.

Mais si on veux effectivement avoir du pluriel, le module pourra effectivement difficilement deviner correctement le pluriel des unité de plusieurs mots donc il faudra probablement ajouté le pluriel (je remarque d'ailleurs que plusieurs unités sont déjà au pluriel : secondes d’arc, bits par seconde...). — Zebulon84 (discuter) 22 juillet 2018 à 18:29 (CEST)

Disons que seul le support pour les cas les plus simples (et les plus fréquents), tels que celui que j'ai indiqué en exemple, me parait valoir la peine. Si ça reste sans accord dans les cas plus complexes, tels que la chose que tu as indiquée ci-dessus, ça ne devrait pas être bien grave…

Sinon effectivement, on peut aussi considérer que l'infobulle concerne uniquement l'unité, sans tenir compte de ce à quoi elle est rattachée dans le contexte, donc toujours singulier. C'est un point de vue qui se défend tout à fait. Mais pour ma part, ça me "tique" à chaque fois que je tombe sur ce genre d'accord manquant… D'autres personnes pourraient donner leur opinion ?

od†n ↗^blah 22 juillet 2018 à 19:46 (CEST)

Je ne suis pas sûr que le jeu en vaille la chandelle, mais si un courageux veut s'y coller (au hasard, un zébulon numéroté), la règle est simple : pluriel si le nombre est supérieur ou égal à 2 (je dis bien le nombre, pas la mantisse), et ce pluriel ne s'applique qu'aux unités au numérateur (exemple : 5 kilogrammes mètres par seconde et par kelvin carré) et à leurs éventuels adjectifs (exemple : 3 mètres carrés par seconde). Mais bonjour le boulot ! Outre la prise en compte de la puissance de 10 et des adjectifs il faut se préoccuper des pluriels irréguliers : un pascal → des pascaux, un quintal → des quintaux, etc. — Ariel (discuter) 22 juillet 2018 à 22:24 (CEST)

Discussion sur la syntaxe sans "pipe"

Bonjour,
Pour information, une discussion sur la syntaxe sans "pipe" a lieu, en trois étapes :

1. Discussion Projet:Modèle/Archive 2018#Unité sans "pipe"
2. Discussion utilisateur:ContributorQ#Résumés de modifications trompeurs
3. Wikipédia:Le Bistro/13 août 2018#Mini-sondage : paramètres du modèle Unité

Cordialement --NicoScribe (discuter) 13 août 2018 à 12:16 (CEST)

@NicoScribe je te relance (et te remercie pour le sondage) concernant la syntaxe du modèle et le sondage sur le Bistro. Vas-tu faire des modification conformément aux souhaits de la communauté (ou as-tu besoin d'aide) ? Est-ce qu'un robot a été chargé de corriger le modèle ? --Niridya (discuter) 23 septembre 2018 à 15:08 (CEST)

 Niridya, je te signale que j'ai lancé la mini-consultation communautaire (l'« étape n°3 ») pour clarifier la situation suivante : pendant l'« étape n°1 » de nombreux arguments de fond ont été échangés (principalement avec  ContributorQ) et il a évoqué une consultation communautaire, puis pendant l'« étape n°2 » la discussion est devenue bloquée entre lui et moi (plus d'un mois après l'évocation d'une consultation communautaire).

Je pense que :

• {{Unité}} accepte les syntaxes de paramètres {{Unité|1234.5|m}} (syntaxe « A »), {{Unité|1234.5 m}} (syntaxe « B »), et comme séparateur soit le point (syntaxe « C ») soit la virgule (syntaxe « D ») ;
• tout contributeur a le droit d'avoir sa « préférence personnelle de syntaxe » (mais je rappelle qu'elles donnent toutes le même résultat affiché) ;
• la majorité des contributeurs sondés :
  • (question 1) préfère la syntaxe « A » plutôt que la syntaxe « B » ;
  • (question 2) préfère la syntaxe « C » plutôt que la syntaxe « D » ;
  • (question 3) considère qu'il n'est pas pertinent de remplacer la syntaxe déjà utilisée dans un article par une autre syntaxe ;
  • (question 4) considère que, si quelqu'un fait un tel remplacement, le résumé « Wikification » n'est pas acceptable ;
  • (question 5) considère qu'il ne faut pas passer un bot convertissant tous les appels d'{{Unité}} vers les syntaxes majoritairement préférées ;
• donc pour te répondre directement : je ne modifie pas des syntaxes existantes dans des articles (cf. résultat de la question 3), je pense qu'il ne faut pas « corriger le modèle » et je ne ferai pas de requête aux dresseurs de bots (cf. résultat de la question 5).
• ContributorQ, pendant l'« étape n°2 », a dit que le mini-sondage « dans la formulation de ses questions, est biaisé. Il est affirmé que l'usage de la forme d'un modèle ou d'une autre serait l'application d'une « préférence personnelle de syntaxe ». L'enjeu est tout autre. » Par ailleurs, je vois régulièrement dans ma LDS que ContributorQ continue de remplacer des syntaxes « A/C » utilisées dans des articles par des syntaxes « B/D », avec le résumé « Wikification ».

Je profite de cette relance pour faire 3 remarques à ContributorQ. 1 : tout d'abord je vous présente mes excuses pour la formulation du mini-sondage, que vous trouvez biaisée. 2 : considérez-vous que les réponses des contributeurs sondés sont invalides à cause de la formulation biaisé ? 3 : allez-vous lancer un vrai sondage (qui aurait l'avantage d'être non biaisé) ? --NicoScribe (discuter) 24 septembre 2018 à 00:00 (CEST)

Merci NicoScribe pour tes explications ! J'avais du louper la fin du sondage car il me semblait (du moins quand j'avais voté) que la communauté était en faveur d'un remplacement par bot. Personnellement, je ne sais pas si c'est utile de créer un sondage étant donné qu'une ébauche de sondage a déjà été faite et que la communauté ne demande apparemment pas de modification importante. Mais si vous pensez qu'il y a un intérêt à faire un sondage, pourquoi pas ? --Niridya (discuter) 24 septembre 2018 à 20:06 (CEST)

Ordre anarchique dans les colonnes triables

Bonjour. Le modèle:Unité pose apparemment un problème lorsqu'il est utilisé dans des colonnes triables, celles-ci étant alors classées en fonction du premier chiffre puis des suivants. Voir Wikipédia:Questions techniques/semaine 45 2018#Ordre anarchique dans les colonnes triables. Une solution peut-elle y être apportée ? Père Igor (discuter) 12 novembre 2018 à 12:06 (CET)

Par km², par an, etc.

Bonjour

Il serait bien d'ajouter un paramètre « par » pour faire un truc du genre 123/km², 321/an pour les endroits avec peu de place, comme les tableaux ou les légendes.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 22 avril 2019 à 22:41 (CEST)

Modèle « Nombre » séparé ?

Le modèle « Unité » est désormais très bien, voire parfait. Peut-être est-il en revanche trop gourmand en ressources ou temps quand il ne s'agit que de gérer les espaces insécables au sein du nombre et entre le nombre et l'objet quantifié, comme dans 315 273 habitants ({{unité|315273 habitants}}). Le modèle « Nombre » (actuellement un alias) pourrait faire ça en étant beaucoup plus simple, {{nombre|315273 habitants}} pouvant être simplement traduit en {{nobr|{{formatnum:315273}} habitants}}. De nombreux articles non scientifiques n'ont besoin que de cette fonctionnalité. — Ariel (discuter) 27 juin 2019 à 08:18 (CEST)

Tout à fait ... Pano38 (discuter) 29 juin 2019 à 10:53 (CEST)

Gestion du genre grammatical des unités

{{unité|1,5 µm/s2}} affiche 1,5 µm/s² ; par survol de la souris sur le symbole de l'unité on lit « micromètre par seconde carré » alors que ça devrait être « micromètre par seconde carrée ». — Ariel (discuter) 29 juin 2019 à 10:09 (CEST)

Oui mais cela risque d’être compliqué pour un nombre d'utilisateur(e) restreint ... Pano38 (discuter) 29 juin 2019 à 14:35 (CEST)

Je reconnais que ça risque de ne concerner que la seconde (je ne vois guère se poser le problème pour la candela ou la calorie), mais ce n'est pas une bonne raison pour laisser un bug. Et puis, même si le problème ne se pose que pour les accélérations, il s'agit tout de même d'une grandeur physique qui apparaît régulièrement. — Ariel (discuter) 29 juin 2019 à 21:43 (CEST)

k€, M€ et G€

les symboles k€, M€ et G€ sont indiqués comme kiloeuro mégaeuro et gigaeuro. "millier d'euros", "million d'euros" et "milliard d'euros" me semble être de bien meilleurs "traductions". Je pense qu'il suffit d'ajouter 3 lignes pour ces 3 abréviations (k€, M€ et G€) et faire pareille pour les autres symboles monétaires...Olyon01 (discuter) 4 juillet 2019 à 02:31 (CEST)

En distinguant le nombre (singulier, pluriel) et en l'appliquant éventuellement aux autres devises (£, $...), cela fait un peu plus de trois lignes ;-) — Vega (discuter) 3 avril 2020 à 16:40 (CEST)

Utilisation du modèle nombre vs modèle unité (cas de personnes)

Bonjour. Pour info, voir cette discussion sur le Bistrot du 9 septembre 2019. --Cjp24 (discuter) 9 septembre 2019 à 01:39 (CEST)

 Cjp24 Je suis pour garder ces 2 modèles. Qu'aujourd'hui quelqu'un^[Qui ?] ait décidé qu'une redirection était judicieuse, me semble bizarre mais c'est un choix technique qui ne devrait avoir que des raisons techniques. Par ailleurs cela ne veut pas dire que cela ne changera pas dans une semaine. Je ne comprend donc pas cette discussion qui n'est pas une sujet éditorial mais uniquement technique ... Pano38 (discuter) 9 septembre 2019 à 07:39 (CEST)

(1) Dans l'état actuel des choses la redirection ne gêne pas mais n'est pas utile non plus puisqu'elle ne concerne que la lecture du code.

(2) L'usage distinct de {{Nombre}} et de {{Unité}} se justifie surtout si l'on décide bientôt de créer un modèle {{Nombre}} indépendant, qui gèrera bien les espaces entre groupes de trois chiffres et l'espace insécable entre le nombre et le nom d'entité, mais n'analysera pas le nom de l'entité quantifiée (code plus simple).

J'ai pour ma part commencé à utiliser {{Nombre}} au lieu de {{Unité}} quand il ne s'agit pas d'une unité, mais c'est sans intérêt si {{Nombre}} reste une redirection ad vitam eternam. — Ariel (discuter) 9 septembre 2019 à 07:52 (CEST)

 Ariel Provost Tout à fait d'accord mais n'ayant pas de boule de cristal je continuerais à utiliser les deux modèles selon qu'il s'agit d'unités réelles ou pas. C'est aux spécialistes du code de décider si une redirection est judicieuse ou pas mais pas aux contributeurs lamba comme moi. Personnellement je m'étonne que la redirection soit la bonne solution pour le temps machine utilisé dans les deux cas, mais WP a peut être du temps CPU en rab, je n'en sais rien et je ne chercherais pas à le savoir! ... Pano38 (discuter) 9 septembre 2019 à 15:18 (CEST)

Notes

Besoin de raccourcir les espaces en modifiant le code des modèles

Ça serait mieux des espaces plus fines en modifiant le code des différents modèles (formatnum | unité | nombre | et peut-être d’autres modèles). Sur Wikipédia France, c’est mal car ça ne respecte pas les règles de la meilleure (soigner) typographie. J’utilise la disposition bépo qui m’aide énormément à mieux respecter les règles de typographie (azerty = mal). C’est plus agréable et mieux compréhensible des espaces plus fines.

•  Espace fine insécable : 1 000 (bien)
•  Espace insécable : 1 002 (mal)

Avant le 16 septembre 2019, les modèles : « formatnum », « unité » et « nombre », n’utilisent pas l’espace fine insécable mais l’espace insécable :

• 30 000 000 000 000 000 000 000 000 000 000 000 000 km (mal. Utilisation du modèle « unité »)
• 30 000 000 000 000 000 000 000 000 000 000 000 000 km (mal. Utilisation du mot magique formatnum:)
• 30 000 000 000 000 000 000 000 000 000 000 000 000 km (bien. Aucun modèle utilisé. Utilisation de la disposition bépo)
• 30 000 000 000 000 000 000 000 000 000 000 000 000 km (en début de ligne : correction de « 30000000000000000000000000000000000000 km » par l’extension « Grammalecte »)
• 30000000000000000000000000000000000000 km

• 1 002 1 002
• doc ; doc ;
• doc ! doc !
• doc ? doc ?
• « doc » « doc »

source : (espace insécable non fine pour « ’’’:’’’ » car c’est la règle, puis espace) Avec la modification des modèles, ça apporte une énorme évolution de la présentation (plus moderne donc mieux) de l’encyclopédie.

 Zebulon84 : MerveillePédia dial. 17 septembre 2019 à 18:12 (CEST)

L’espace fine insécable n'est pas compatible avec le navigateur Safari sur macOS ainsi qu'avec iOS (tous les navigateurs), l'espace est tout simplement invisible. Les lecteurs sous Mac ou iOS se retrouveraient donc avec le premier exemple barré ci-dessus.

En attendant, il vaut mieux rester avec l'espace insécable. — Thibaut (discuter) 14 novembre 2019 à 21:37 (CET)

 Thibaut120094 : les rapports de bugs que je trouve à ce sujet ([13], [14]) ont été marqué résolus en aout 2021. Si tu as du matériel Apple, peux-tu confirmer si l'affichage est désormais correct ? — Zebulon84 (discuter) 10 mars 2022 à 23:39 (CET)

@Zebulon84 : Le moteur de rendu de Safari gère maintenant bien ce caractère et il y a maintenant plus de problème sur iOS.

Malheureusement sur macOS, il reste encore certaines polices fournies par défaut par Apple, notamment celles pour le sérif par exemple, qui gèrent encore mal le caractère et n’affichent donc pas d’espace.

J’ai mis plus de détails et des captures d’écran dans le ticket : phab:T60529. — Thibaut (discuter) 11 mars 2022 à 02:11 (CET)

 Vu. J'ai du mal à comprendre cette négligence de caractère Unicode vu qu'Apple est la marque de référence dans le monde de l'édition ! -- Zebulon84 (discuter) 11 mars 2022 à 10:27 (CET)

Moi aussi, j’ai envoyé plusieurs messages sur https://apple.com/feedback mais j’imagine que ça doit être noyé dans la masse de messages qu’ils reçoivent chaque jour. — Thibaut (discuter) 11 mars 2022 à 11:09 (CET)

Confusion dans l'utilisation des modèles nombre et unité

Le code de ces deux modèle semblant être le mème actuellement, un certains nombre de personnes utilisent l'un à la place de l'autre, et réciproquement. Que le code de ces deux modèles soit le même actuellement ne justifie pas qu'ils faillent les confondre. Que peut on faire pour que cette confusion ne se perpétue?

Cordialement ... Pano38 (discuter) 3 avril 2020 à 13:12 (CEST)

Si l'un des noms continue éternellement à être un alias de l'autre, ce n'est pas la peine de se prendre la tête. Ce qui serait logique, en revanche, ce serait de faire du modèle Nombre une version allégée du modèle Unité (allégée de la reconnaissance et de la mise en forme des unités). — Ariel (discuter) 3 avril 2020 à 13:38 (CEST)

 Ariel Provost toute à fait d'accord avec toi, pourquoi consommer du temps CPU pour rien? Par contre avoir deux modèles différents impose 2 maintenance en parallèle. Cependant si l'on considère qu'une grandeur physique est un nombre suivi d'une unité de mesure le modèle unité pourrait, peut-être, être une combinaison de deux modèles simples. Néanmoins une unité pouvant avoir un exposant cela complique un peu les choses. Il faut aussi prendre en compte qu'une unité peut etre la combinaison de plusieurs unités "standards", ce qui doit compliquer sérieusement le code actuel. Cordialement ... Pano38 (discuter) 3 avril 2020 à 14:02 (CEST)

Ça n'est pas une mauvaise idée. Un premier modèle gèrerait la typographie du nombre (mise en forme, espaces insécables et gestion de la puissance de dix, qui peut aussi bien intervenir pour un nombre seul ou pour un nombre d'habitants ou de virions que pour un nombre suivi d'une unité) et un second gèrerait la reconnaissance et la mise en forme des unités (bien sûr j'avais aussi en tête leurs combinaisons), avec un troisième tout simple appelant les deux premiers. Ça règlerait le problème d'une maintenance parallèle. — Ariel (discuter) 3 avril 2020 à 14:26 (CEST)

 Ariel Provost Si c'est plus simple et plus efficace, cela devrait être facile de convaincre la communauté de cette modification (sais tu comment faire?) et ce qui permettrait d'avoir deux modèles relativement indépendants ... Pano38 (discuter) 3 avril 2020 à 14:43 (CEST)

Attendons d'autres avis ici-même, ensuite on pourra faire une demande sur Projet:Modèle/Demandes. — Ariel (discuter) 3 avril 2020 à 14:48 (CEST)

Bonjour Ariel Provost et Pano38. Si j'ai bien compris votre intention, cette division des tâches en {nombre≈formatnum} + {mef unité} = {unité} me semble inutile, dans la mesure où :

1. c'est sans doute déjà comme cela que fonctionne le modèle : un simple test doit avoir lieu pour reconnaître la présence d'une partie unité (recherche rapide de chiffres ou signes, qui sollicite un CPU, mais pour les avantages listés ci-après ; accessoirement, Wikipédia:Ne vous préoccupez pas de performance) ;
2. cela supposerait en effet la maintenance de trois modèles au lieu d'un (en plus de {{nobr}} et {formatnum}), avec autant de pages d'aide et surtout des milliers de pages qui y ont recours ;
3. cela compliquerait grandement la prise en main, déjà assez absconse pour les néophytes ;
4. la distinction entre nombres et unités est quasi artificieuse et trompeuse : un nombre s'applique généralement à une "fausse unité" (euros, vaches, etc.), comme souligné, donc comment distinguer formellement quand {mef unité} devrait alors s'appliquer, sans compliquer les choses ?
5. surtout, il faudrait jongler avec trois modèles au gré des reformulations de phrases, au lieu d'un unique modèle intelligent actuel. Ce serait un retour en arrière, finalement.

Enfin, la "confusion" entre unités et nombres, chère à Pano38, n'est qu'une approximation sémantique que seuls les contributeurs voient et qu'ils font en connaissance de cause. En écrivant d'une traite {{unité|1000 vaches}} ou {{nombre|1000 vaches}}, on sait pertinemment que les vaches ne font pas partie du SI, mais qu'importe ? Puisque ce sont des alias, le code ne « semble » pas être le même, il est le même. Le temps consacré par les rédacteurs et relecteurs devrait àmha aller ailleurs qu'à ces détails invisibles (et c'est un typographe amateur qui l'écrit). Salutations — Vega (discuter) 3 avril 2020 à 16:35 (CEST)

Je peux me ranger à cet avis, et je connaissais Wikipédia:Ne vous préoccupez pas de performance (avec quelque doute néanmoins : certaines pages se chargent un peu trop lentement à mon goût). On en reviendrait donc à ma première phrase, « Si l'un des noms continue éternellement à être un alias de l'autre, ce n'est pas la peine de se prendre la tête ». Il faudrait alors rappeler à d'aucuns de ne pas encombrer nos pages de suivi avec des modifs insignifiantes du genre échanger un nom de modèle contre un alias. — Ariel (discuter) 3 avril 2020 à 16:50 (CEST)

Je rajouterais aussi quelques éléments suivants :

• Bien entendu, comme mentionné, on ne doit pas se préoccuper de la performance au détriment de la facilité d'utilisation et de maintenance.
• Aucun outil de maintenance courant ne remplace les redirections {{nombre}} et {{nb}} par {{unité}}, donc pour ceux qui tiennent à cette distinction unité/nombre (et j'en fais généralement partie, même si je n'y prends pas toujours garde), on peut déjà faire cette distinction.
• On a déjà assez de modèles et de trucs bizarres à apprendre pour contribuer sur WP (pour quelqu'un qui ne connaissait que son traitement de texte Word ou LibreOffice), et que ce soit en utilisant le wikicode ou l'éditeur visuel. Alors essayons d'éviter de rajouter une distinction totalement artificielle entre deux modèles liée à l'apparence du wikicode uniquement (autrement dit, sans impact sur le rendu). Actuellement, qu'il utilise {{unité}} ou {{nombre}}, ça fonctionnera, que ce soit pour une unité ou des vaches. Il faudrait vraiment essayer de ne pas complexifier perpétuellement la manière d'écrire les articles, surtout si ça n'a aucun intérêt sur le rendu. J'essaie quand je peux dans le cadre de la maintenance de simplifier certaines choses (modèles, suppression de trucs devenus obsolètes, simplification du code), tout cela bien entendu tant que cela ne provoque pas la moindre perte de contenu ou de fonctionnalité.
• Et pour finir, qui s'occuperait de remplacer les usages inappropriés de {{nombre}} avec une unité ? Actuellement on s'en fiche, car ça n'a aucun impact, mais si demain on avait un modèle ne gérant pas tout ce que gère {{unité}} ? Et ce ne serait pas qu'une opération ponctuelle, mais à faire régulièrement...

Bref, je pense que si on peut éviter d'ajouter encore un peu de complexité à la manière d'écrire des articles, c'est déjà assez compliqué comme ça pour les nouveaux contributeurs...

--Tractopelle-jaune (discuter) 3 avril 2020 à 17:13 (CEST)

 Ariel Provost, Tractopelle-jaune et Vega Ayant travaillé longtemps dans l'informatique je sais très bien que pour le programmeur actuel avoir un code 10 fois trop long n'est pas un problème mais cela a des conséquence et sur les performances et sur le coût de l'achat et de l'entretien du matériel necessaire pour que tout cela fonctionne. Ajouter des milliers de CPU, Disques, sauvegardes qu'il faut réaliser chaque jour, est coûteux en énergie (humaine, électrique, climatique) et aussi en argent et si cela ne doit pas préoccuper l'utilisateur il est clair que cela préoccupe le gestionnaire qui doit faire des appels de fond régulièrement pour augmenter ces capacités CPU et mémoire simplement parce qu'on n'a pas réfléchi deux minutes si il était possible de faire autrement. Je suis contre ce gaspillage d'argent, d'énergie et de temps CPU pour de simple raison de simplification de programmation et de maintenance. Couper une code en trois partie distinctes n'est sûrement pas moins facile à maintenir, ni plus coûteux (temps+énergie) qu'un « code a tout faire ». Sinon il faut pousser le raisonnement à l’extrême et n'avoir plus qu'un seul modèle qui servira « à tout et à n'importe quoi », le programmeur devant se débrouiller avec ce que l'utilisateur a entré comme caractères/symboles/ponctuation (une espèce d’intelligence artificielle). Je suis tout à fait contre tout ce gaspillage qui va finir par faire regretter tout ce qui a été fait dans quelques années ... Pano38 (discuter) 3 avril 2020 à 18:15 (CEST)

 Pano38, personne ici ne nie le coût hardware. La question, bien qu'aucun de nous ne soit informaticien chez WikiMedia et qu'on s'éloigne de la "confusion", est : cela en vaut-il la peine ? Pour ajouter à toutes les réponses déjà évoquées, il y a aussi le coût des changements de modèles : Wikipedia:Tools/Navigation popups/About fixing redirects (ici dans le cas des redirections). — Vega (discuter) 3 avril 2020 à 19:28 (CEST)

PS : je réalise que le sujet a déjà été discuté il y a quelques mois, avec un début d'échange similaire : #Utilisation du modèle nombre vs modèle unité (cas de personnes) et Wikipédia:Le Bistro/9 septembre 2019#Une modification anodine de modèle qui fait couler beaucoup d'encre.

 vega Je suis tout a fait d'accord pour l’aspect sémantique : un nombre n'eat pas une grandeur physique et reciproquement d'où le titre de cette section. 3 charrues ne seront jamais changé en 3 charrue au carré multiplié par un tracteur et ce qui prouve, en tout cas, que je n'ai pas changé d'avis et que 3 fois 1/3 font toujours 1. Concrètement couper le code en 3 tranches demande un peu d'investissement mais simplifie grandement la maintenance des modèles ce qui est bénéfique pour toute la chaîne : compréhension/temps/énergie/dépense/investissement. Connais on un responsable informatique avec qui nous pourrions en discuter? ... Pano38 (discuter) 4 avril 2020 à 07:54 (CEST)

Pour faire plaisir à Pano38 on peut tout simplement intervertir les noms du modèle (Unité ↔ Nombre) : si 314 vaches ne sont pas 314 unités, 314 km sont en revanche bien un nombre de km ! — Ariel (discuter) 4 avril 2020 à 13:10 (CEST)

Ariel je ne considere pas les vaches comme des unité officielle du SI et je n'ai jamis vu de texte mentionnant des vache au carré ou au cube; je voulais donc dire que ce genre d'unité n'en est pas une au sens du SI, par contre c'est bien un nombre que chaque paysans sait compter. A l'inverse les km sont bien des unité du SI et des km² ou des km³ ont bien un sens physique reconnu comme des unités officielles ... Pano38 (discuter) 5 avril 2020 à 09:33 (CEST)

Il semble que tu ne m'aies pas compris. Ce que je dis, c'est que renommer le modèle « Nombre » résoudrait ta réticence : 375 km sont bien aussi un nombre de kilomètres, même si le kilomètre est une unité. Le modèle Nombre règle les problèmes de typographie et regarde si ce qu'on compte est une unité, qu'alors il traite. « Unité » ne serait plus qu'un alias gardé pour compatibilité. — Ariel (discuter) 5 avril 2020 à 10:31 (CEST)

J'avoue ne pas te comprendre; sachant qu'aujourd'hui le mème code est utilisé pour les deux je ne vois pas ce que cela changerais. Pour moi l’objectif était de différencier les 2 codes sachant que le paramètre exposant « après le nom de l'unité » n'a aucun sens pour des nombre de n'importe quoi alors qu'il en a un pour la plupart des unités ... Pano38 (discuter) 5 avril 2020 à 10:40 (CEST)

Je sais bien, mais on nous a expliqué pourquoi il n'était pas souhaitable de scinder le modèle. Alors on peut l'appeler « Nombre » pour que tu arrêtes de te prendre la tête et la notre avec . — Ariel (discuter) 5 avril 2020 à 14:23 (CEST)

 Ariel Provost désolé mais je n'ai vu ni débat, ni conclusion, ni vote : où sont ils? ... Pano38 (discuter) 5 avril 2020 à 14:38 (CEST)

Personnellement, j'utilise ces 2 modèles : {{nombre}} pour les nombres entiers (vaches, hab, km...), {{unité}} dès qu'il y a une décimale ou un exposant. Cordialement, Jack ma ^►discuter 19 avril 2020 à 07:53 (CEST)

 Jack ma : Je pratique comme vous mais ces deux modèle étant un alias l'un de l'autre le code exécuté est strictement le mème ce qui génère le mème temps d’exécution et le mème encombrement mémoire inutilement d'où ma proposition d'avoir 2 modèles vraiment différents afin d'améliorer le temps d’exécution ... Pano38 (discuter) 19 avril 2020 à 09:29 (CEST)

Jack ma, donc {{nombre|5 km}}, mais {{unité|5,5 km}} ?? — Vega (discuter) 23 avril 2020 à 16:54 (CEST)

• Non, Vega, je ne pense pas (le km reste une unité, et le modèle en donne le nom par survol de la souris). Par contre, pour les vaches, les habitants, les crevettes, etc.. — Ariel (discuter) 23 avril 2020 à 18:21 (CEST)
• @Vega : ni l'un ni l'autre , mais {{nombre|5|km}} et {{unité|5.5|km}}. Je m'efforcerai dorénavant de n'utiliser que le modèle unité, s'il s'agit de km. Jack ma ^►discuter 23 avril 2020 à 18:47 (CEST)

 Jack ma à mon avis, comme indiqué plus haut, seul les unité du SI devrait bénéficier du modèle unité; le reste devant faire partie des nombres (modèle nb de préférence) ... Pano38 (discuter) 26 avril 2020 à 15:49 (CEST)

Pas d'accord pour jouer les censeurs. Il n'est pas encore interdit, que je sache, de mesurer des superficies en hectares (ha), de donner une période de rotation en heures (h) ou en jours (j), un âge en milliards d'années (Ga), une pression en atmosphères (atm), une distance en années-lumière (al) ou en mégaparsecs (MPc), un angle en degrés (°) ou en secondes d'arc ('), une production d'énergie en kilowatts-heures (KWh), une température en degrés Celsius (°C), la masse d'un bijou en onces (oz), sans parler des systèmes d'unités encore en usage dans certains pays, ni des passages historiques où l'on peut citer des résultats dans les unités de l'époque. — Ariel (discuter) 26 avril 2020 à 16:16 (CEST)

 Ariel Provost : Effectivement réduire les unités au Si est trop strict mais on pourrait dire que le « modèle unité » ne devrait contenir que des valeurs d'unités de mesure et non des vaches ou des trains ... Pano38 (discuter) 26 avril 2020 à 18:26 (CEST)

Alors nous sommes d'accord. Reste que, pour résumer tout ce qui précède : d'un côté il serait plus logique d'avoir deux modèles séparés pour les unités de mesure et pour les autres items et ça serait peut-être un chouïa mieux en termes de performances ; de l'autre cette séparation présente des inconvénients (compte tenu de l'existant) qui apparemment rendent la séparation en deux peu souhaitable. Quant à garder un unique modèle mais réserver l'appel "unité" aux unités et "nombre" aux autres, chacun peut le faire si ça lui chante, mais ce serait idiot d'en faire une règle. — Ariel (discuter) 27 avril 2020 à 06:31 (CEST)

┌─────────────────────────────────────────────────┘
Voir cette très ancienne discussion. Dès lors que le modèle existe sous divers alias, il ne sert à rien de discuter sans fin — et donc d'utiliser de la ressource et de l'énergie — à vouloir résoudre un problème qui n'existe pas. Tout juste pourrait-on rappeler à une lecture attentive de ceci :
« Le modèle {{unité}} permet d’écrire facilement et de typographier correctement un nombre écrit en chiffres arabes ou romains suivi d’une unité ou d’un nom. Par rapport à une écriture directe, ses avantages sont :

• empêcher le retour à la ligne entre le nombre et l’unité ou le nom correspondant, par l’insertion d’une espace insécable, comme dans « 30 km » ou « 250 habitants » ;
• faciliter l’écriture des exposants et des unités multiples, comme dans « 10 m s⁻¹ » ;
• faciliter les traductions d’articles lors d’import de valeurs (il suffit de modifier le nom du modèle) en affichant le nombre selon le format local ;
• mettre en forme le nombre automatiquement en groupant les chiffres par groupes de trois, comme dans « 30 000 habitants ». Note : dans certains cas, la redirection {{nombre}} peut paraître préférable d’un point de vue sémantique, exemple : {{nombre|250000 déportés}}. »

Daniel*D, 27 avril 2020 à 09:31 (CEST)

Livre française

La Livre française est une monnaie d'ancien régime, jusque 1780 on pouvait distiguer la livre tournois et la livre parisis. Tous les articles qui utilisent le modèle Unité ne peuvent donner la précision et de ce fait le mot livre est converti, dans une bulle d'aide, en kg, sur la base de la livre - unité de masse - britannique!

La question est posée, dans cette même discussion, pour le symbole monétaire anglais "£", pour lequel la conversion a été supprimée, à la fois parce qu'il y avait cette confusion avec la masse, et parce que la converion varie selon les époques &c. Ici la solution est simple et appliquée, mais :

Comment faire pour les livres du temps de Louis XIV, exemple à l'article Étienne-François de Choiseul, où une somme de 112 746 200 livres est convertie en 51 140 816,066 494 kg ? Je supprime l'utilisation du modèle Unité sur cette page mais il y en a tant d'autres ? Merci. --methodood (discuter) 2 mai 2020 à 09:14 (CEST)

 Methodood : bonjour. Dans ces cas-là, je wikifie le nom de la monnaie {{nombre|112746200|[[Livre française|livres]]}}, ce qui donne 112 746 200 livres. Père Igor (discuter) 2 mai 2020 à 12:06 (CEST)

Bien joué merci Père Igor (j'avais compris à tort que nombre pointait sur Unité). --methodood (discuter) 5 mai 2020 à 18:48 (CEST)

Le modèle {{nombre}} étant une redirection du modèle {{unité}}, cela marche pareil [15]. Daniel*D, 5 mai 2020 à 19:20 (CEST)

TemplateData : Modification effectuée pour réduire les problèmes causés par l'éditeur visuel dans certains articles

Pour information, je recopie ici la discussion ayant amené à quelques modifications des données TemplateData du modèle visant à réduire les problèmes causés par l'éditeur visuel dans certains articles (retrait du statut « suggéré » pour le paramètre 2).
--Tractopelle-jaune (discuter) 2 mai 2020 à 20:21 (CEST)

Visiblement [16], les modifications de nombres faites avec l'éditeur visuel dans le modèle {{unité}} (ou ses alias) entraine un dysfonctionnement. Un effet, elles ajoutent une barre verticale avant les accolades finales ainsi : {{unité|31416 malades}} devient {{unité|31417 malades|}}. Ce qui a pour effet de détruire la fonctionnalité essentielle consistant à ne pas renvoyer à la ligne le nom suivant le nombre (essai fait sur une page de brouillon). Comme, je me lasse de corriger (presque tous les jours sur cet article [17]) et que l'on ne peut plus signaler le problème sur fr.Wikipédia [18], je lance cette bouteille à la mer. Merci d'avance à ceux qui savent. Cdlt, Daniel*D, 2 mai 2020 à 12:12 (CEST)

 Daniel*D : Je m'en occupe...

--Tractopelle-jaune (discuter) 2 mai 2020 à 12:29 (CEST)

Merci à toi. Daniel*D, 2 mai 2020 à 12:39 (CEST)

 Daniel*D :  Corrigé

J'ai rendu le paramètre 2 optionnel dans les données TemplateData.

J'ai essayé de résumer du mieux possible en 500 caractères le raisonnement justifiant de faire ainsi. Mais je vais pouvoir mieux le détailler ici :

Même si la forme avec les deux paramètres {{unité|10|kg}} (je ne vais pas évoquer les cas à 3 paramètres ou plus, qui sortent de cadre) est la plus utilisée 495 595 appels contre 471 815 (en excluant les cas ou le paramètre 2 est vide, car justement causé par le problème en question), la forme avec un seul paramètre pour la valeur et l'unité {{unité|10 kg}} est acceptée depuis plusieurs années.

Même si cette variante à un seul paramètre n'a pas ma préférence (question d'habitude), elle est quand même utilisée sur pas moins de 24 000 articles.

Mais elle pose problème avec l'éditeur visuel, qui peine à gérer les modèles avec deux syntaxes possibles. Et toute modification du modèle avec l'EV transforme automatiquement les {{unité|10 kg}} en {{unité|10 kg|}}, ce qui perturbe l'insécabilité (cela devrait sûrement se régler en modifiant le module, car ce n'est a priori pas un comportement souhaité), mais surtout elle ajoute cette barre verticale en trop. Hors, il n'y a pas de raisons que l'éditeur visuel perturbe ainsi le choix de certains contributeurs d'utiliser cette variante.

Et sachant que d'expérience, les modèles {{unité}} (et le mot magique {{formatnum:}}, même si dans le cas de ce dernier, c'est parfaitement logique que les contributeurs utlisant l'EV le fasse sauter à chaque modif du nombre, vu que ce mot magique n'est pas géré par l'EV) sont parmi les derniers modèles qu'utilisent les nouveaux contributeurs et IP utilisant l'éditeur visuel (la démarche d'insérer un modèle dans l'EV est bien plus lourde que de l'écrire en wikicode), il n'y a pratiquement aucun enjeu à ce niveau quand au choix d'une une variante ou d'une autre, vu que la quasi-totalité des modèles {{unité}} traités par l'EV sont des modifications et non des insertions.

Le fait de ne plus marquer le paramètre 2 comme « suggéré » fait qu'il n'est plus proposé automatiquement lors de l'ajout du modèle (il faut le rechercher dans la liste, comme tous les autres paramètres). Mais lors de toute modification de modèle utilisant déjà le paramètre 2 (soit la quasi-totalité), celui-ci est affiché comme paramètre présent (au même titre que le 1). C'est donc transparent dans ce cas.

La seule chose que je vais encore tester, c'est si c'est pertinent que la description des deux paramètres prenne en compte le cas ou seul 1 est utilisé (c'est ce que j'ai fait là), car j'ai un doute en terme d'utilisabilité. Je vais sûrement re-modifier ça pour essayer de simplifier ces descriptions, histoire de ne pas trop compliquer tout ça (il y a le même problème avec {{date}} et {{date-}}, pour lesquels j'ai testé à de multiples reprises dans l'EV pour trouver la meilleure formulation, même si ça reste bancal).

Mais je pense que l'on peut laisser le paramètre 2 en optionnel, comme je l'ai fait, au vu du très faible taux d'ajout de ce modèles depuis l'EV.

Ce n'est qu'un des nombreux modèles que j'ai sur ma liste sur lesquels il faut que je reprenne les données TemplateData à cause de ce genre de problèmes ou actuellement trop compliquées à utiliser (informations lacunaires dans les données TemplateData) avec l'EV.

--Tractopelle-jaune (discuter) 2 mai 2020 à 13:22 (CEST)

OK Tractopelle-jaune, ne serait-il pas judicieux de recopier cette discussion sur la page de discussion du modèle ? Daniel*D, 2 mai 2020 à 19:40 (CEST)

Cas particulier à 4 décimales ou bug ?

Bonjour, y a-t-il une exception qui exempterait d'espace (insécable) dans le cas d'un nombre à quatre décimales ? Ou est-ce un bug dans le modèle, qui ne génère pas cette espace ?

Exemples :

1,1234 et 123,1234

mais 1,123 45 et 123,123 45 et 123,123 456 7

— Vega (discuter) 14 mai 2020 à 15:29 (CEST)

Je crois me rappeler que c'est une exception introduite à mon initiative, pour des raisons de lisibilité. On doit pouvoir le retrouver un peu (ou beaucoup) plus haut sur cette page. — Ariel (discuter) 14 mai 2020 à 16:25 (CEST)

Effectivement, en cherchant mieux je trouve Discussion modèle:Unité#Décimales de mai 2017. Si une décimale seule est un peu triste, ce serait pourtant la bonne typographie. Ce que confirment par exemple un Petit Guide de typographie ou la BDL de l'OQLF dans leurs exemples. — Vega (discuter) 14 mai 2020 à 16:50 (CEST)

Et aussi le Lexique, comme je l'indiquais dans ladite discussion. Mais comme Zebulon84 est parti, j'ignore qui peut corriger. Cdlt, Daniel*D, 15 mai 2020 à 00:16 (CEST)

@Thibaut120094 ? @NicoV ? — Vega (discuter) 15 mai 2020 à 00:41 (CEST)

Je pense que c'est la ligne #161 de Module:Unité, il faudrait remplacer le if #fraction > 4 then par if #fraction > 3 then. --NicoV (discuter) 15 mai 2020 à 09:16 (CEST)

Si j'en crois l'historique du module, peut-être Od1n a-t-il le même avis ? Cdlt, Daniel*D, 15 mai 2020 à 15:03 (CEST)

Refs 137711362. Bien vu NicoV, peut-être que c'était tout simplement une erreur. od†n ↗^blah 15 mai 2020 à 17:08 (CEST)

Ah, compris en lisant Discussion modèle:Unité#Décimales. En fait ils voulaient ne pas avoir une seule décimale séparée (cas lorsque 4, 7, 10… décimales). Mais si vous dites qu'il faut bien laisser cette décimale séparée (cf. liens postés par Vega), alors ça clarifie la situation, et il y aurait effectivement le petit ajustement à faire dans le code. od†n ↗^blah 15 mai 2020 à 17:17 (CEST)

Le Lexique, page 124, dit la même chose, tout comme notre convention : Wikipédia:Conventions concernant les nombres#Pour un comptage ou une mesure. Cdlt, Daniel*D, 15 mai 2020 à 18:17 (CEST)

170918071. od†n ↗^blah 16 mai 2020 à 06:39 (CEST)

Merci. — Vega (discuter) 16 mai 2020 à 06:46 (CEST)

De même. Daniel*D, 16 mai 2020 à 10:02 (CEST)

Bonjour,

Cette exception figure explicitement dans la brochure SI du BIPM ( https://www.bipm.org/documents/20126/41483022/SI-Brochure-9.pdf/fcf090b2-04e6-88cc-1149-c3e029ad8232 page 46, 5.4.4 : "... Cependant, lorsqu’il n’y a que quatre chiffres avant ou après le séparateur décimal, il est d’usage de ne pas isoler un chiffre par une espace." (À mon avis ça se justifie par la lisibilité -et à une constante cognitive, 4 est le plus grand nombre de "choses" qu'un être humain lambda peut identifier à 4 visuellement, sans avoir à les compter). Or pour le moment, le modèle produit des nombres à 4 chiffres avec espace produisant un chiffre orphelin. Je propose de généraliser l'exception. Gribal (discuter) 21 août 2021 à 14:03 (CEST)

Largeur de l'espace

Bonsoir,

En survolant la page de discussion, je vois que le sujet a déjà été abordé il y a à peine 11 ans. Je me permets quand même de le remettre sur le tapis. Le fait d'avoir opté pour l'espace insécable & nbsp; implique que le rendu est assez disgracieux dans certains cas, l’espace entre le nombre et son unité étant franchement plus grand que l’espace entre mots. Voyez l'espace entre « 200 » et « ans » sur la capture d'écran ci-dessous :

---

---

Quelles sont les raisons objectives pour ne pas passer aujourd'hui à & thinsp; ? Je dois avouer que cela me chatouille l'œil à chaque fois que je le vois…Litlok (m'écrire) 9 juillet 2020 à 21:05 (CEST)

Bonjour. Chez moi il a la largeur d'un espace normal (le "200 ans" ci-dessus est une image). Voici ce que ça donne :

de plus de 200 ans, la nature (avec nbsp)

de plus de 200 ans, la nature (avec thinsp : largeur environ 20% plus courte qu'un espace normal, peu sensible)

Et thinsp est-il aussi insécable ? A suivre... Cordialement, Jack ma ^►discuter 10 juillet 2020 à 06:34 (CEST)

Pour moi, il y a clairement une différence entre les deux. Mais apparemment, thinsp est sécable (voir ce billet de blog). L'entité & #8239; devrait pouvoir être utilisée. Litlok (m'écrire) 13 juillet 2020 à 12:18 (CEST)

Bug ?

Pour obtenir « entre 10¹⁷ et 10¹⁹ N m » on devrait pouvoir coder entre {{unité|e17 et e19 N m}} mais ça donne « entre 10¹⁷ et e¹⁹ N m ». — Ariel (discuter) 30 août 2020 à 06:53 (CEST)

La doc dit bien :

« Il est possible d’écrire l’ensemble nombre - unité dans le premier paramètre, ce qui simplifie la saisie :
* « {{Unité|1,23 ± 0,02 e-3 m/s2}} » affiche « (1,23 ± 0,02) × 10⁻³ m/s² ». Cette possibilité ne permet pas de gérer certains cas complexes, souvent des détournements du modèle, tels que plusieurs nombres séparés par du texte dans un seul modèle, par exemple « 1,23 jusqu’à 2,32 m² », ou des nombres ou exposants contenant des lettres (des variables mathématiques), par exemple « 2,5y e²ⁱ ». »

sauf que « ou » et « et » sont des paramètres explicitement prévus, il faudrait donc qu'ils soient intégrables dans la syntaxe sans barres verticales. — Ariel (discuter) 18 septembre 2020 à 06:26 (CEST)

Syntaxe et affichage des exposants

Les deux syntaxes suivantes affichent bien le 2 en exposant

• {{Unité|10|km|2}} → 10 km²
• {{Unité|10 km2}} → 10 km²

En revanche celle qui suit affiche « km2 »

• {{Unité|10|km2}} → 10 km2

Autre exemple {{Unité|10|s-2}} → 10 s-2 affiche « s-2 »

On observe un nombre non négligeable d'insertions "problématiques" (recherche non exhaustive sur le dernier dépôt) dans l'encyclopédie. Une possibilité pourrait être de corriger dans les articles les insertions par bot. Mais modifier le modèle pourrait aussi être approprié puisqu'il s'agit d'une question de moindre surprise. Par exemple {{Unité|10|hab./km2}} (→ 10 hab./km²) donne le résultat escompté. En même temps, le m² n'est pas en soi une unité fondamentale (masse, longueur, temps), ni le m³, le s⁻² ou toute autre éventualité de combinaison. Des avis sur la méthode de correction à adopter seraient donc bienvenus. Merci d'avance. Cordialement. — Ideawipik (discuter) 17 septembre 2020 à 21:10 (CEST)

Le modèle accepte deux syntaxes différentes, celle où l'on spécifie les différents paramètres séparés par une barre verticale, et celle où l'on met un texte sans barres verticales, que le modèle décrypte intelligemment. Il faudrait juste signaler dans la documentation qu'on ne doit pas mélanger les deux syntaxes. — Ariel (discuter) 18 septembre 2020 à 06:21 (CEST)

Bonjour Ideawipik et Ariel Provost, je le comprenais comme Ariel, mais visiblement ce n'est pas le cas de tout le monde, à voir la liste (fortiche, la recherche générique sur wstat.fr, d'ailleurs !). — Vega (discuter) 25 septembre 2020 à 15:37 (CEST)

Je n'y avais pas fait très attention mais oui, chapeau ! Je mets dans ma todolist de m'initier à wstat. — Ariel (discuter) 25 septembre 2020 à 15:48 (CEST)

Paramètres inexistants

Bonjour,
Je note la présence d'un paramètre M sur un certain nombres d'appels du modèle. Celui-ci existe-t-il vraiment dans le modèle (il n'est référencé nulle part), et à défaut, doit-on le supprimer purement et simplement ou bien est-ce une erreur d'appel de paramètre, à remplacer par un autre ?
Wikipédiennement, Epok__ (✉), le 3 octobre 2020 à 19:58 (CEST)

Ajout : et quid des paramètres masseMolSoluté et masseMolSolvant, utilisés extensivement sur l'article Saccharose ? Epok__ (✉), le 3 octobre 2020 à 20:00 (CEST)

Bien vu ! Ces paramètres semblent bien n'avoir aucun effet. Question : d'où viennent-ils ? Peut-être de la traduction de modèles anglais ? — Ariel (discuter) 4 octobre 2020 à 18:10 (CEST)

Du bon usage de ce modèle. À clarifier dans la documentation ?

Bonjour à tous y compris Teffubud et plus globalement les usagers d'outils de correction. En référence aux corrections mineures suivantes ici ou là. Même si on peut se demander s'il vaut le coup d'ajouter une ligne à l'historique des articles pour de si petites corrections et même si ces dernières introduisent une légère amélioration potentielle à l'affichage de l'article, une autre solution ne serait-elle pas plus adaptée ?

• En effet, pour les petits nombres (inférieurs à dix ? à seize ?, voire vingt), beaucoup de typographes préfèrent écrire en toutes lettres, sans toutefois mélanger les deux types d'écritures dans la même phrase. Il semble que pour les âges, la pratique sur Wikipédia est d'utiliser de façon générale les chiffres.
• Par ailleurs, une simple espace insécable introduite grâce au modèle {{nobr}} ferait l'affaire, notamment lorsqu'il n'y a pas de besoin de formatage du nombre (n<1000). Ce modèle est beaucoup moins lourd techniquement que le modèle « Unité ». De là à relancer l'intérêt d'avoir un modèle « Nombre » dédié aux dénombrables (entiers), distinct du modèle « Unité »…

Sur cette autre modification, on aurait aussi pu en profiter pour ajouter les espaces insécables aux trois autres éléments de la même phrase.

La raison des ces corrections systématiques est vraisemblablement liée à un défaut d'explication des outils d'aide à la correction syntaxique. Tout ce que signale/propose WPCleaner (ou AWB) n'est pas forcément à suivre ou optimal ! Les développeurs de ces outils font confiance à la réflexion des utilisateurs lors de l'application des propositions faites. Par exemple, il est possible qu'un outil propose de remplacer « hotel » par « hôtel ». Ce qu'il ne faut pas accepter si le texte est en anglais. La liste des corrections proposées se trouve notamment dans Wikipédia:Liste de fautes d'orthographe courantes et Wikipédia:AutoWikiBrowser/Typos et plus précisément dans Wikipédia:Liste de fautes d'orthographe courantes#Unité pour ce qui concerne ce modèle. Les suggestions automatiques pourraient être améliorées, en tenant compte des conditions d'usage du présent modèle.

Peut-être est-il aussi à rappeler les points suivants.

• Il ne faut pas utiliser ce modèle pour des syntaxes comme{{unité|deux|seuls restes}}(exemple déjà rencontré) où le modèle est inutile et l'espace insécable non nécessaire pour les nombres écrits en toutes lettres. Petite recherche partielle.
• On évite de commencer une phrase par un nombre écrit en chiffres. Petite recherche interne un peu lourde.

Remarque connexe au passage, plutôt que de changer 21{{e}} commune en {{21e}} commune, il est préférable de corriger en {{21e|commune}} pour l'espace insécable.

Pour une correction syntaxique en harmonie avec le fonctionnement des modèles et les choix communautaires. — Ideawipik (discuter) 11 octobre 2020 à 22:04 (CEST)

Je souscris à ces considérations, sauf peut-être au marronnier de la création d'un modèle « Nombre » autonome (j'étais pour, mais de plusieurs discussions antérieures il ressort que le jeu n'en vaut pas la chandelle). On pourrait les indiquer dans une sous-section de la doc, ce qui permettrait d'y faire référence sur la PdD des contributeurs qui font en série des modifications contreproductives ou inutiles ne ne portant que sur ça (quand ces modifs accompagnent juste des modifs significatives on peut laisser tomber). — Ariel (discuter) 12 octobre 2020 à 09:45 (CEST)

Mio

Quand on survole « Mio » sur Octet#Multiples normalisés, il est affiché « million » dans l'infobulle au lieu de « mébioctet ».

Comment gérer ceci ? — Thibaut (discuter) 21 février 2021 à 18:53 (CET)

Le coupable est la ligne n^o 103 du module Unité/Data, qui définit explicitement Mio comme un symbole signifiant million. Supprimer cette ligne résoudrait le problème évoqué par Thibaut, mais en créerait peut-être un autre : dans l'article Million, Mio est effectivement donné comme le symbole du million « selon le code de rédaction interinstitutionnel de l’Europe « Annexe A3 Abréviations et symboles » ». Le conflit est patent, mais a-t-on dans l'encyclopédie des nombres exprimés en Mio (millions) ? — Ariel (discuter) 21 février 2021 à 20:32 (CET)

Lien interne + exposant = bug

Bonjour,

Le modèle cesse visiblement de traiter les exposants si ceux-ci sont dans un LI, voir cette diff.

Devrait-on et peut-on corriger cela ? — Vega (discuter) 31 mars 2021 à 17:59 (CEST)

Ben je ne vois pas de problème, la graphie est bien correcte (W/m²), par survol de la souris on a le début de l'article au lieu du nom de l'unité, si on clique on va à l'article. Où est le problème ? — Ariel (discuter) 31 mars 2021 à 19:03 (CEST)

Ah, peut-être as-tu d'abord voulu mettre un lien sur W/m2 ? Ça ne me choque pas que le modèle baisse les bras quand il analyse caractère par caractère les chiffres et les symboles et qu'on lui met dans les pattes des liens ou des modèles (qui pourraient même être imbriqués). Ça ne me paraît pas utile qu'il analyse une unité qui ne lui est pas proposée sous la forme standard, je trouve normal qu'il fasse comme pour une unité inconnue. — Ariel (discuter) 31 mars 2021 à 19:03 (CEST)

Oui, sans ma mise en forme "forcée", le modèle n'affichait pas l'exposant. Ce n'est pas extrêmement gênant, mais puisqu'on "nourrit" le modèle par des unités ordinaires, ici « W/m2 », il pourrait les mettre en forme en faisant abstraction du ou des LI. Ça serait plus pratique. — Vega (discuter) 31 mars 2021 à 19:17 (CEST)

Catégorie:Page incorrectement traitée par le Module:Unité

Bonsoir Od1n (dernier à avoir modifié le module), et tous ceux qui s'intéressent à ce modèle.

Je travaille sur cette catégorie de maintenance et souhaite proposer des améliorations, si elles sont pertinentes.

Je constate qu'il est parfois très difficile de trouver où se situe l'erreur, surtout quand le modèle est utilisé des dizaines de fois ou à travers une Infobox. Si l'appel problématique s'affichait en rouge ou s'il était signalé en prévisualisation, ça aiderait.

Problèmes rencontrés :

1. espace avant ou après un / séparant deux unités (pas d'infobulle et catégorie). Exemple : {{Unité|5 km / h}} donne 5 km/h au lieu de 5 km/h. En attendant, j'ai corrigé.

   La typo « km / h » est incorrecte. Le modèle fait déjà plein de trucs, ça ne me paraît pas nécessaire de lui demander de tout corriger. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

   Comme je l'indique, j'ai corrigé les cas que j'ai trouvés. Je laisse aux développeurs la décision d'adapter le module ou non. --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

2. plus de deux chiffres séparés par un / (catégorie). Exemple de Les Diablerets (village) : {{Unité|1323 / 1188 / 1145|m}} donne : 1 323 / 1 188 / 1 145 m

   Le résultat me paraît correct, je ne vois pas le problème. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

   Le problème est que même si l'affichage est correct, le module catégorise la page en erreur. --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

3. plus de deux unités séparées par des / (mauvaise infobulle et catégorie). Exemple : {{unité|17.5|kg N/ha/année}} donne 17,5 kg N/ha/année

   L'infobulle me paraît correcte (« kilogramme newton par hectare année »); conforme à ce qui est codé : que faudrait-il lire ? Quant à la catégorie, je ne comprends pas de quoi il s'agit. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

   Je suppose que l'infobulle attendue est « kilogramme newton par hectare par année » ? --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

   Non, « /ha/année » est compris comme « par hectare et par année » comme si l'on avait écrit « /(ha×année) » (règle classique des opérations de multiplication et division sans parenthèses), ce qu'on peut dire aussi, comme l'infobulle, « par hectare année ». Le libellé « par hectare par année » correspondrait à « /(ha/année) ». — Ariel (discuter) 7 novembre 2021 à 09:41 (CET)

   Personnellement, le plus clair est « kilogramme newton par hectare et par année ». C'est l'évolution que je propose dans le cas où il y a plus de deux unités. --FDo64 (discuter) 25 novembre 2021 à 22:20 (CET)

4. chiffre entouré de parenthèses (catégorie). Exemple de BMW Série 1 : {{nb|1450 / (1505)}} donne 1 450 / (1 505). Pas évident puisque c'est parfois des dates, parfois des chiffres...

   No problémo : quand il s'agit de dates on n'a aucune raison d'utiliser le modèle Unité. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

   Le problème est que même si l'affichage est correct, le module catégorise la page en erreur. --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

5. unité après le / (pas d'infobulle et catégorie). Exemple de TER Bourgogne : {{unité|43700 / jour}} donne 43 700 /jour

   Comme pour le point n^o 1, les espaces avant et après la barre de fraction sont incorrectes (contrairement sans doute au point n^o 2). — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

   Je suppose que l'infobulle attendue est « par jour » ? Sinon, quelle devrait être la syntaxe ? --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

   La syntaxe correcte est {{unité|43700 /jour}}, qui donne 43 700 /jour. On peut aussi écrire {{unité|43700 /j}}, qui donne 43 700 /j. L'infobulle indique « jour » alors qu'elle devrait dire « par jour ». — Ariel (discuter) 7 novembre 2021 à 09:41 (CET)

   Ton exemple, {{unité|43700 /j}}, est bien mieux. L'évolution proposée est bien d'afficher dans ce cas de figure « par jour ». --FDo64 (discuter) 25 novembre 2021 à 22:20 (CET)

6. signe ≃ généré par le modèle {{donnée stratigraphique}} (89 cas) qu'il faudrait traiter comme un ~ (catégorie). Exemple de Formation de Bayin-Gobi : {{unité|{{donnée stratigraphique|début|Barrémien}}}} donne 125,77
7. cas des durées : {{Unité|5:30|heures}}, {{unité|6:30|minutes}}, {{unité|2:30|min}}, {{nb|19:00 h}}, {{Unité|2:10.639|s}} qui donnent : 5:30 heures, 6:30 minutes, 2:30 min, 19:00 h, 2:10,639 s. Ou tout simplement {{Unité|4:26}}, comme dans Free as a Bird.

   Les notations avec « : » sont des dates, pas des durées, elles ne relèvent donc pas du modèle Unité mais des modèles ad hoc. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

   Il y a peu de cas donc je veux bien les remplacer par le modèle {{Heure}} ou {{Heures}} selon le cas. --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

   Finalement, j'ai corrigé la plupart des cas en supprimant simplement ce modèle. --FDo64 (discuter) 25 novembre 2021 à 22:20 (CET)

8. mise en forme des chiffres, faut-il l'accepter ? Exemple de Love, Rosie : {{unité|'''1003283'''|$}}. En attendant, j'ai corrigé. Il est nécessaire pour Tube fluorescent.

   Précision : il y a aussi le cas où la mise en forme concerne uniquement le chiffre et pas l'unité. Par exemple, {{unité|''5900''|cm|3}}. --FDo64 (discuter) 25 novembre 2021 à 22:20 (CET)

9. {{unité|½|p}} pose deux problèmes : ½ provoque une erreur (et ne donne pas le même rendu que 1/2) et p, pour penny, n'est pas reconnu. Il y a aussi d'autres fractions.
10. l'espace après (–|+|-) provoque une erreur, alors que sans l'espace c'est accepté. Exemple de Cuisine italienne : {{unité|+ 100|°C}} qui donne + 100 °C.

    L'espace après un signe est fautive, alors qu'après un opérateur (addition, soustraction) elle est obligatoire, donc no problémo, le modèle n'ayant pas pour vocation de prévoir toutes les erreurs des contributeurs. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

    Je suis d'accord, le problème est que la catégorisation en erreur n'est pas systématique. La même syntaxe génère des erreurs sur certaines pages et pas sur d'autres. --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

11. l'exposant en paramètre 2 ne fonctionne pas. Par exemple de Aaltoes : {{unité|1500 m|2}} donne 1 500 m 2

    Corriger la doc du modèle, pas le modèle lui-même. La doc dit « Une unité complexe peut être spécifiée à l’aide d’un paramètre seul ou décomposée sous la forme d’une liste symbole|exposant ». Il faudrait préciser qu'on ne doit pas mélanger les deux syntaxes. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

    Ces cas là ne vont pas être faciles à trouver mais je vais les chercher et les corriger. --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

12. bug des références nommées. Je suggère que le module restitue tel quel tout ce qui est après une balise, quelle qu'elle soit. Exemple : {{Unité|3898<ref name="Swisstopo"/>}} donne 3 898 

    Il me semble qu'un appel de réf à l'intérieur d'un modèle ne marche jamais, ça n'est pas propre au modèle Unité. La réf se met après la fin du code du modèle (« }} »). On peut le signaler dans la doc. — Ariel (discuter) 6 novembre 2021 à 06:03 (CET)

    Il n'y a que 60 cas lors d'utilisations du modèle directement dans les articles, donc corrigeable. Par contre c'est assez fréquent dans les utilisations indirectes via des infobox et c'est indécelable. Il vaut donc mieux le prévoir. Surtout que ça fonctionne déjà sauf dans l'unique cas des références nommées tel que je le signale, et qui font planter le module. --FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

    J'ai donc corrigé la plupart des utilisations de balises <ref> dans les articles. Il en reste néanmoins 22 qui me semblent légitimes : plusieurs chiffres avec des références qui leurs sont rattachées.

    Par exemple : {{Unité|1706<ref name="ICGC"/>|à=1708<ref name="IGN"/>|m}}

    Liste : Agulla del Portarró, Aiguille d'Argentière, Aiguille de Tré-la-Tête, Bataille du Bajo Palacé, Bataille du Pantano de Vargas, Coll de Manrella, Comabona, Cornebois, Cornettes de Bise, Dent de Barme, Elbourz, Kílian Jornet, L'Atrium (Douala), Mont Mazama, Petit Astazou, Pic de Sanfonts, Pic de Setut, Pic de la Portelleta, Pollegó Superior, Roca Entravessada, Tosseta de Vallcivera, Turó de l'Home

    --FDo64 (discuter) 2 décembre 2021 à 21:58 (CET)

13. J'ajoute un autre problème, celui de la non interprétation des modèles {{2}} et {{3}}. {{unité|3300|m{{2}}}} donne 3 300 m² (affichage correct sauf pour l'infobulle), alors que {{unité|3300|m|2}} donne 3 300 m². --FDo64 (discuter) 2 décembre 2021 à 21:58 (CET)

J'ai par ailleurs corrigé des bizarreries qui ne provoquaient par d'erreur. Pourquoi ?

1. {{unité|n°|1}} ou {{unité|{{n°}}|8}}
2. {{unité|{{4e}} région}}

Ainsi que des détournement du modèle du style

1. {{unité|42 rue Goya}} mis à la place d'un {{nobr}}, et il y a plein d'autres cas similaires.
2. {{nombre|1er|janvier 2015}} mis à la place de {{date-}}

Sans parler des nombreux cas d'utilisation totalement inutiles, par exemple

1. {{unité|{{Nombre|5500}}|tr/min}}
2. {{unité|{{formatnum:1500}}|V}}
3. {{unité|deux}}
4. {{unité|11}}

--FDo64 (discuter) 5 novembre 2021 à 23:00 (CET)

Bonsoir Ariel Provost et merci pour tes remarques auxquelles j'ai répondu.

Précision : lorsque j'indique (catégorie) cela signifie que les pages sont catégorisées en erreur, et à tort selon moi.

Je vais aussi me répéter : je constate que ce modèle est très souvent (une fois sur deux ?) utilisé en lieu et place d'un {{nobr}}. Même si je ne me soucie pas des performances, je pense qu'entre la simple utilisation d'une balise <span> et l'appel d'un module le gaspillage de temps cpu doit être assez monumental.

--FDo64 (discuter) 7 novembre 2021 à 01:06 (CET)

Il paraît qu'il ne faut pas se préoccuper des performances. À l'occasion d'autres modifs, je remplace {{unité|300 habitants}} par {{nobr|300 habitants}} mais c'est peut-être un gaspillage de mon temps. Ça rejoint le marronnier du remplacement de {{unité|3000 habitants}} par {{nombre|3000 habitants}} dans l'optique d'une scission des deux modèles (= sans interprétation de l'unité pour le second) : les informaticiens nous disent que le jeu n'en vaut pas la chandelle. — Ariel (discuter) 7 novembre 2021 à 09:41 (CET)

Bonsoir.

J'ai donc terminé les corrections annoncées ci-dessus. On est passé sous la barre des 1 500 articles en erreur.

Même si c'est sans rapport direct, cela m'a amené à corriger également les mauvaises utilisations du modèle {{nobr}}. En particulier quand il y avait plus d'un paramètre. Sans doute à cause de remplacement de {{unité|300|habitants}} par {{nobr|300|habitants}}.

Reste donc maintenant à corriger, au minimum, les faux positifs que j'ai signalé, c'est à dire tous les cas ou l'affichage est correct mais que la page se retrouve à tort dans la catégorie.

Merci.

--FDo64 (discuter) 25 novembre 2021 à 22:20 (CET)

 FDo64 :

1. {{Unité/Bac à sable|5 km / h}} → 5 km/h
2. {{Unité/Bac à sable|1323 / 1188 / 1145|m}} → 1 323 / 1 188 / 1 145 m
3. {{unité/Bac à sable|17.5|kg N/ha/année}} → 17,5 kg N/ha/année
4. 1 450 / (1 505) : pas encore d'amélioration
5. {{unité/Bac à sable|43700 / jour}} → 43 700 /jour
6. {{unité/Bac à sable|{{donnée stratigraphique|début|Barrémien}}}} → 125,77
7. 5:30 heures : pas prévu de gérer ça
8. {{unité/Bac à sable|'''1003283'''|$}} → 1 003 283 $
9. {{unité/Bac à sable|½|p}} → ¹⁄₂ p ; le penny n'est pas reconnu car il n'est pas dans Module:Unité/Data, et il ne me semble pas judicieux d'y mettre les sous-unité monétaire, vu les possibles homonymie. Si on veut mieux l'identifié, un lien me semble plus judicieux ({{unité/Bac à sable|½|[[penny|p]]}})
10. {{unité/Bac à sable|+ 100|°C}} → + 100 °C
11. 1500 m|2 : pas prévu de gérer ça
12. ref dans le module déjà corrigé par Od1n

Le tout sans catégorisation.

J'ai créé cette catégorie pour m'aider à repérer les cas ou le modèle n'arrive pas à découper le contenu du paramètre 1 correctement suite à la mise en place de la syntaxe simplifiée. Comme souvent l'affichage est néanmoins relativement correct et l'utilisateur moyen ne saura pas réparer l'erreur (même moi je ne sais pas toujours comment faire, notamment dans les infobox) je n'ai pas voulu faire quelque chose de visible. Résultat comme tu t'en est aperçu c'est parfois difficile de trouver d'où viens la catégorisation. Pour faciliter ça j'ai ajouté (au /Bac à sable pour le moment) un log avec le contenu des paramètres 1 et 2, visible en prévisualisation, en ouvrant « Données d’optimisation de l’analyseur : » puis « Journaux de Lua ». Le contenu est sera déjà expansé, mais ça devrait quand même aider.

Concernant les bizarreries, le module ne trouve pas de nombre dans le paramètre 1 (caché par les balise HTML d'abréviation dans le cas de 4^e). Le contenu, qui est en un seul morceau, est alors considéré comme une unité, et ça ne déclenche pas d'erreur. Je peux essayer d'ajouter des détections pour repérer ces cas, mais comme l'affichage est correct, ça ne me semble pas une priorité.

Je ne suis plus administrateur, donc je ne peux pas mettre ce code en place, mais tu peux copier le contenu de Module:Unité/Bac à sable dans Module:Unité, ça devrait déjà réduire le contenu de Catégorie:Page incorrectement traitée par le Module:Unité.

— Zebulon84 (discuter) 15 mars 2022 à 03:20 (CET)

Bonjour Zebulon84 , merci beaucoup et bon retour ! Je vais regarder et m'en occuper ce soir. --FDo64 (discuter) 15 mars 2022 à 12:10 (CET)

J'ai oublié : as-tu regardé le point 13 ? --FDo64 (discuter) 15 mars 2022 à 12:13 (CET)

Pas prévu de gérer le cas 13 non plus. Je peux catégoriser les cas où il y a chiffres ou <sup> dans le paramètre 2 pour repérer ces utilisations incorrecte, mais peut-être vaut-il mieux attendre d'avoir plus ou moins vidé le contenu actuel de la catégorie. — Zebulon84 (discuter) 15 mars 2022 à 18:20 (CET)

Bonsoir Zebulon84 . J'ai donc mis en place hier soir la nouvelle version. Cela n'a fait diminuer la catégorie que de 200 articles. J'ai aussi corrigé quelques cas, principalement des montants en $ précédés de la devise, comme font les anglosaxons.

J'ai regardé les articles classés à la lettre A et voici certaines erreurs récurrentes :

1. Abies forrestii : sans doute {{unité|1-1.5|m}} et plusieurs cas similaires. Cette notation semble très utilisée sur les articles du projet:Biologie
2. Affaire Marcel Redureau : {{Lien vidéo}} avec durée=28:28
3. Âge de l'Univers : sans doute {{Unité|67.4 ± 0,5|km||s|-1|[[Parsec|Mpc]]|-1|}}
4. Massif de l'Agly : {{Infobox Géologie régionale}} avec sismicité=Modérée – 0.15
5. AgustaWestland AW609 : {{Infobox Avion}} avec envergure= (avec les rotors) 18,29 et autonomie=(sans réserve) 1852
6. Autobus de Saint-Étienne : {{Ligne de transport en commun}} avec duree = 20 (23)
7. USS Abraham Lincoln (CVN-72) : sans doute {{unité|56+|km/h}}

Je mets ça ici sans trop savoir si c'est le module qu'il faut faire évoluer ou s'il faut corriger les articles.

Pour être totalement transparent, nous avons travaillé avec  NicoV sur la Catégorie:Page avec des arguments non numériques dans formatnum et une des solutions envisagée pour vider cette catégorie qui contient 56 740 pages est de remplacer les formatnum par le modèle Unité. Pour cela, il faudrait que ce modèle interprète correctement les arguments passés principalement par des Infobox. Sinon ça ne fait que déplacer le problème et ça ne sert à rien.

Merci encore pour ton aide ! --FDo64 (discuter) 16 mars 2022 à 22:44 (CET)

Merci. Il y a encore du travail à faire. Plus gênant il a une erreur de script avec la syntaxe {{unité|12|m||/||s}} utilisée pour contourner une limitation d'une version précédente du module. Simple à corriger en {{unité|12|m||/s}}, mais je n'aime pas les erreur de script.

Je me demande si je ne vais pas faire une version plus simple et tolérante pour les infobox ou pour tes formatnum. Je vais y réfléchir le temps d'analyser ces exemples. — Zebulon84 (discuter) 16 mars 2022 à 23:21 (CET)

┌─────────────────────────────────────────────────┘
 FDo64 : Comme il me parait difficile de normaliser le contenu des nombreuses infobox, les contributeurs voulant toujours apporter des nuances au chiffre brut attendu par le modèle, et comme normalement l'unité est dans ce cas toujours en paramètre 2, 3, 4... je propose d'ajouter un paramètre, ou de créer un modèle séparé, pour désactiver l'analyse faite pour la syntaxe simplifiée, et simplement afficher le contenu de paramètre 1 avec juste transformation de tous les nombres en typographie française (1234.56 → 1 234,56). C'est de toute façon déjà ce qui se passe lorsque la page est catégorisée.

Il faudra alors changer dans le code des infobox les {{unité|{{{param|}}}|km}} en {{unité|{{{param|}}}|km|infobox=oui}} ou {{unité strict|{{{param|}}}|km}}ou quelque-chose comme ça. Il faut juste décider du nom du paramètre .

Pour les cas hors infobox que tu présentes :

1. Le problème ne viens pas des {{unité|1-1.5|m}} correctement gérés, mais des {{unité|1-1.5(-2)|m}}et autre {{unité|1-1.5 x 2-3|m}} qui dépasse les capacité de ce que j'ai envisagé.

2. Je pense qu'il faut soit supprimer le modèle unité de ce modèle, le contenu du paramètre partant dans tout les sens : 28:28 mais aussi 28m28s, 28 min 28 s, 1 h 28, 1:28:28... soit transformé tout minutes manuellement. Mais il ne me parait pas utile de gérer ça dans {{unité}} juste pour ce modèle.

3. Le problème viens du double espace entre le ± et le 0,5. J'ai modifié le /Bac à sable pour prendre ça en compte.

7. Ça concerne un vingtaine de page dans l'espace principal. Est-ce que cette façon d'écrire est encyclopédique ? Q'en pense les typographes ? On peut remplacer par {{unité|> 56|km/h}} ou {{unité|≥ 56|km/h}} qui sont acceptés. — Zebulon84 (discuter) 22 mars 2022 à 15:49 (CET)

 FDo64 : Ce n'est sans doute pas encore parfait, mais il me semble avoir géré l'ensemble des cas simple que j'ai pu voir dans la catégorie.

J'ai retiré la catégorisation des pages hors espace encyclopédique (attention pour les tests).

J'ai ajouté un paramètre booléen basique qui permet de désactiver les analyses, pour retrouver le format de base du modèle. Exemples :

• {{unité/Bac à sable|4500, ou parfois 5000 m2/s}} catégorise et affiche mal l'unité
• {{unité/Bac à sable|4562, ou parfois 5464|m|2|/s|basique=Oui}} ne catégorise plus et affiche correctement l'unité. Il faut cependant la syntaxe complète. L'idée est que c'est surtout les infobox qui en ont besoin et que dans ce cas il est plus facile d'écrire l'unité éclatée, et hors infobox cela peut permettre de résoudre les cas où les analyses du modèle sont incorrecte (comme aurait l'être le {{Unité|10000|DC-2}} si je n'avais pas fait attention, je n'ai sans doute pas pensé à tout).

Si cela te convient, je propose de passer la version actuelle du /Bac à sable dans le Module:Unité, et de voir ce que cela donne. — Zebulon84 (discuter) 6 avril 2022 à 17:55 (CEST)

Bonsoir Zebulon84 . On voit des différences dans Modèle:Unité/Test#Exemples du modèle Unité/2. Par contre cette section est bizarre puisqu'elle compare Unité/2 avec Unité. Donc ces différences existaient peut-être avant tes modifications et certaines sont peut-être voulues.

• {{Unité/Bac à sable|2|puis=3|jours}} n'affiche pas « puis 3 »
• les deux derniers exemples de cette section n'affichent pas le point médiant.

--FDo64 (discuter) 6 avril 2022 à 23:04 (CEST)

Bonjour FDo64 Effectivement ces différences ne sont pas nouvelles :

• « puis » n'est utilisé que sur 6 pages (wstat), dont celle de la documentation et cette page de test, j'avais du estimé que ce n'était pas utile d'implémenter ce paramètre, j'ai du le mettre dans la page de test pour signaler cette différence pour pouvoir changer d'avis à postériori.
• Ma préversion d'Unité en lua en 2015 affichait initialement aussi un point médian, mais je l'ai supprimé après les remarques d'Oliv0 (cf. #Nouvelle version à tester, message du 26 avril 2015 à 14:31 et suivants).

Mon idée est de fusionner les deux modèles, d'où cette section de Unité/Test, mais je n'ai jamais pris le temps de vérifier que tout était parfaitement compatible, conversion et fonctionnalités non documentées compris.

— Zebulon84 (discuter) 7 avril 2022 à 00:47 (CEST)

Ortho : "par habitants"

Bonjour,

Il y a une faute d'ortho dans {{nombre|22.2|kg/hab}} ou {{nombre|22.2|kg/hab.}}, qui affichent « 22,2 kg/hab. » avec en infobulle « kilogramme par habitants ». Que "kilogramme" soit au singulier, soit, mais le pluriel à "habitants" est de trop. En passant, de nombreux souhaits par habitant wikipédien ;-) — Vega (discuter) 26 décembre 2021 à 16:33 (CET)

Problème réglé (facilement, dans Module:Unité/Data). — Ariel (discuter) 2 janvier 2022 à 18:38 (CET)

Merci Ariel. J'ignorais que les contributeurs lambda ont la possibilité d'éditer ce type de code. — Vega (discuter) 11 janvier 2022 à 13:36 (CET)

Pluriel des unités

(c'est un peu lié au sujet juste au dessus)

Bonjour

Je trouve un peu étrange d'avoir « kilogramme » dans l'infobulle de 47 kg.

« 47 kilogramme » est erroné, il faudrait plutôt afficher « 47 kilogrammes ».

Pour info, en français, le pluriel pour les unités commence à 2 (0,47 m ou 1,47 m : « mètre », 2,47 m : « mètres »). les Français et les Québécois semblent d'accord sur ce point : [19]/ [20] et [21].

Ne pas se laisser tromper par la manière anglo-saxonne de mettre au pluriel dès que 1 est dépassé (1.47 miles), et aussi parfois pour 0 (zero dollars).

Aussi il faut penser aux unités composées (ex: mètre par seconde). J'ai trouvé ça : [22]

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 2 janvier 2022 à 13:29 (CET)

Bonjour SyntaxTerror . Même si je n'ai rien contre cette demande, je ne suis pas sûr qu'elle soit justifiée. L'infobulle ne donne que l'unité. Si elle avait donne « 47 kilogramme », là oui il y aurait une erreur. Hors c'est juste « kilogramme » qui est affiché. --FDo64 (discuter) 2 janvier 2022 à 13:35 (CET)

m2, m3, km2, km3

Bonjour Zebulon84 et tout autre développeur qui saurait aider.

Lorsqu'elles sont mises en paramètre 2, les unités m2, m3, km2 et km3 ne sont pas interprétées. C'est probablement vrai pour tous les exposants.

Par exemple : {{unité|18|m3}} donne 18 m3 alors que {{unité|18|m³}} et {{unité|18|m|3}} donnent 18 m³.

En paramètre 1, ça fonctionne : {{unité|18 m3}} donne bien 18 m³.

C'est un problème que l'on rencontre souvent : m2 (541 inclusions), m3 (740 inclusions), km2 (1192 inclusions), km3 (39 inclusions).

Peut-être s'agit-il d'ajouter quelques lignes dans Module:Unité/Data ? Je ne saurais pas faire.

Pourrais-tu regarder ?

Merci. --FDo64 (discuter) 22 mars 2022 à 12:44 (CET)

Bonjour FDo64 et Zebulon84 . Comme il a déjà été dit sur cette page, il ne faut pas mélanger les deux syntaxes, celle avec plusieurs paramètres séparés par une barre verticale et celle avec des mots (y compris m3, etc.) séparés par une espace. Demander aux modélistes de faire en sorte que tous les mélanges syntaxiques soient pris en compte me paraît excessif. En revanche la doc devrait insister sur cette dichotomie entre syntaxes. — Ariel (discuter) 22 mars 2022 à 12:55 (CET)

Je ne comprends pas. {{unité|18|m3/h}} donne bien 18 m³/h.

De plus, écrire {{unité|18|m3}} me semble très naturel et il faudrait éviter d'avoir un modèle que seuls les experts savent utiliser.

--FDo64 (discuter) 22 mars 2022 à 13:10 (CET)

Je n'ai pas dit qu'une syntaxe mixte donnait systématiquement des résultats aberrants, je dis que c'est une mauvaise pratique. C'est la syntaxe avec des paramètres séparés qui n'est pas très naturelle pour un néophyte (il faut néanmoins la conserver par compatibilité ascendante, sauf à demander à un bot d'effectuer des centaines de milliers de mises à jour), la syntaxe {{unité|18 m3}} ou {{unité|18 m3/h}} me semble très conviviale. — Ariel (discuter) 22 mars 2022 à 13:18 (CET)

 FDo64 : {{unité|18|m3/h}} est accepté car la syntaxe type {{unité|18|m/s}} est utilisée des dizaines de milliers de fois, donc lorsqu'il y a un / dans le paramètre 2, le module essaye de parser l'unité.

Obliger le modèle à aussi parser l'unité lorsqu'il y a un chiffre dans le paramètre 2 est très simple à faire (je viens de le faire sur le /bac à sable si tu veux tester). Mais cela aura des effets de bord lorsque le modèle est utilisé avec une référence contenant des chiffres dans le paramètre 2, comme {{unité|4|DC-2}} sur la page Douglas DC-2, sans possibilité logique pour contourner le problème (on pourrait toujours écrire {{unité|4|DC}}-2 mais je déteste ça).

Donc comme Ariel je n'y suis pas vraiment favorable. Je préfèrerais même tout corriger en syntaxe simplifié ou complète y compris pour {{unité|18|km/h}}, mais je crains que faire ces milliers de modif sans changement visible ne soit mal perçu par la communauté.

— Zebulon84 (discuter) 22 mars 2022 à 14:59 (CET)

Bonjour. Ce n'est pas le fond du problème ; le dernier exemple donné gagnerait à être remplacé par {{nobr|4 DC-2}} ou « quatre DC-2 ». Mais pour {{nombre|10000|DC-2}}… Donc, je rejoins les avis d'Ariel et Zebulon84, sauf si ce type de cas (avec un chiffre dans l'"unité", comme « R5 », ou « LR6 ») est vraiment exceptionnel. Auquel cas, un exceptionnel {{nobr|{{formatnum:10000}} DC-2}} serait acceptable.

D'un autre côté, il est assez étrange pour un néophyte que {{unité|1.1|m3/kg}} (1,1 m³/kg) "fonctionne" (y compris l'infobulle) mais pas {{unité|1.1|m3}} (1,1 m³). D'où le grand risque d'insertions/affichages incorrects et mon indécision. — Ideawipik (discuter) 22 mars 2022 à 16:40 (CET)

Comme Ariel, je préfère de loin la syntaxe simplifiée aux multiples et obscurs paramètres non nommés. J'ai corrigé beaucoup d'erreurs et sans doute une infime partie d'entre elles. Par exemple du texte en paramètre 3 : que l'affichage soit délirant ne dérangeait pas celui qui avait fait l'erreur…

Je comprends bien la raison pour laquelle il n'est pas possible de traiter le cas de tous les exposants, ce que je suggérais au départ. On peut le constater sur la page de test (deux derniers exemples que j'ai ajouté).

Ne pourrait-on pas uniquement traiter le cas des m2, m3, km2 et km3 ? Seuls cas que j'ai rencontré pour l'instant.

Ne suffirait-il pas de les ajouter au Module:Unité/Data ?

--FDo64 (discuter) 22 mars 2022 à 21:40 (CET)

Je préfère garder le Module:Unité/Data propre. J'ai modifié le /Bac à sable pour prendre en compte ces quelques cas. Faut-il les mettre dans une catégorie spécifique pour les repérer et les corriger ? Si oui, y met-on aussi les 'm/s' ? — Zebulon84 (discuter) 23 mars 2022 à 08:06 (CET)

Merci @Zebulon84 pour ces dernières modifications. Je vois que tu as aussi traité le cas des {{2}} et {{3}}, merci. Fais-moi signe quand la version sera suffisament finalisée.

Pour ce qui est de la catégorie, je préfère ne pas me prononcer. Il y a 2500 articles pour le cas que je signale ici, plus presque autant pour les {{2}} et {{3}}. Plus d'autres que j'ignore pour l'instant. Beaucoup trop pour que je m'en charge. Et même si un bot le fait, elle se reremplira très vite.

Bon courage à celui qui voudra éduquer les foules. J'ai récemment tenté d'expliquer qu'une donnée numérique devait être numérique à quelqu'un qui avait annulé une de mes corrections. Je me suis fait salement accueillir et il a rageusement révoqué mes messages. Son argument : « je ne vois pas en quoi ça gênerait le lecteur ou les contributeurs, et ça facilite tout-de-même grandement l'édition pour moi. »

--FDo64 (discuter) 23 mars 2022 à 15:29 (CET)

Popup d'unité, le cas de cas

Bonjour,

Si j'écris avec Unité Il y a 100 cas de vallées embrumées, si je survole avec la souris "cas", je vois apparaitre "centisecondes d'arc", ce qui ne convient pas du tout bien sûr. Y a-t-il un moyen d'empêcher ça ?... J'ai découvert ce problème en regardant Pandémie de Covid-19 au Ghana#Chronologie.

Merci. Touam (discuter) 1 mai 2022 à 09:31 (CEST)

À mon avis, le modèle « Unité » est conçu pour... les unités et a déjà beaucoup à faire avec certains conflits d'unités (p. ex. "a" = are ou année), voir aussi le marronnier d'une éventuelle autonomisation du modèle « Nombre ». En l'occurrence l'appel au modèle est un peu idiot, il vaut mieux entrer {{nobr|100 cas}}. Et s'il y en avait mille il faudrait se résoudre à entrer {{nobr|{{formatnum:1000}} cas}}. — Ariel (discuter) 1 mai 2022 à 09:53 (CEST)

Oui, c'est un cas ou le modèle analyse trop. Peut-être faut-il retirer du module:Unité/Data les ares (sauf hectare) et les centi, déci, déca (sauf avec m et L) ou hecto (sauf avec m L et Pa) qui me semble rarement utilisés en dehors des exceptions citées ici. — Zebulon84 (discuter) 1 mai 2022 à 11:44 (CEST)

Pour reprendre l'exemple, pourquoi pas {{nobr|1 000 cas}} tout simplement ? Supprimer des préfixes, ça me semble un peu radical tout de même. — Vega (discuter) 4 mai 2022 à 18:36 (CEST)

J'approuve l'idée d'utiliser nobr, même avec formatnum ; ça se défend que l'usage d'unité quand c'est pas des unités est excessif. Merci. Touam (discuter) 4 mai 2022 à 19:35 (CEST)

« 2.8 ± 0.3 e9 » non, « 2.8 ± 0.3e9 » oui

Je ne comprends pas pourquoi la modif ici a été nécessaire ni pourquoi elle a fonctionné. — Ariel (discuter) 17 mai 2022 à 06:48 (CEST)

 Ariel Provost : TL;DR : parce que les modélistes ne prévoient pas tout. Mais je vais faire quelque chose ici.

Plus précisément, ça marchait sans doute précédemment car le modèle unité essayait de comprendre exactement ce qui était dans le paramètre. Ici il y arrivait, mais comme il y a une très grande inventivité pour détourner les paramètres d'infobox, il échouait régulièrement, catégorisait la page et affichait le résultat presque brut, avec juste les nombres formaté.

Voici quelques exemples de valeur de ce paramètre âge de l'{{Infobox Étoile}} que le modèle unité ne sait pas analyser et répartir dans ses différents paramètres :

• ?
• 284 millions d'
• Quelques centaines de<br>millions d'
• {{val|4.0|0.3|0.4}}{{x10|9}}
• 4<ref name=mnras397_2_757/> ou 5.0–7.9<ref name=apj687_2_1264/> G

Pour éviter de catégoriser ces pages, éviter que le modèle interprète et affiche mal (cas typique même si je ne l'ai pas vu sur ce paramètre de cette infobox : 12 / 15 est affiché tel quel, mais 12/15 est interprété comme une fraction et affiche 12⁄15), et ne pas passer du temps à analyser pour rien, j'ai désactivé l'analyse dans un certains nombre d'infobox, et affiche directement le résultat avec juste les nombres formatés (paramètre |basique=y du modèle unité). L'unité est traité normalement, mais doit respecté la syntaxe traditionnelle stricte si on veux une infobulle (…|m|2|/s… et non …|m2/s…).

0.3e9 est considéré comme un nombre par lua comme par formatnum:, le modèle le transforme donc en 0,3 × 10⁹. Jusqu'à présent l'espace entre le nombre et l'exposant n'est pas prévu, donc ça ne marche pas. Mais comme ce n'est effectivement pas très intuitif, j'ai fait une petite modification sur le /Bac à sable qui gère ce cas qui semble assez utilisé.

On a donc en ce moment (je subst: pour que l'affichage n’évolue pas) :

{{Unité|2.8 ± 0.3 e9|[[Année (calendrier)|a]]}} → (2,8 ± 0,3) × 10⁹ a

{{Unité|2.8 ± 0.3 e9|[[Année (calendrier)|a]]|basique=y}} → 2,8 ± 0,3 e9 a

{{Unité/Bac à sable|2.8 ± 0.3 e9|[[Année (calendrier)|a]]|basique=y}} → 2,8 ± 0,3 × 10⁹ a

 FDo64 : Pour ce soucis et quelques autres autres petites améliorations, pourrais-tu copier Module:Unité/Bac à sable dans Module:Unité ? Je vais bientôt déménager et donc probablement faire un nouveau wikibreak, mais après je ferais sans doute une nouvelle candidature admin pour pouvoir faire ce genre de chose moi-même.

— Zebulon84 (discuter) 17 mai 2022 à 12:43 (CEST)

 Fait. Merci. --FDo64 (discuter) 17 mai 2022 à 23:46 (CEST)

Merci Zebulon84 et FDo64 . — Ariel (discuter) 18 mai 2022 à 06:29 (CEST)

Espaces et sauts de ligne

Bonjour

Je pense qu'il faudrait améliorer le code, car je viens de m'apercevoir que lorsqu'on à par exemple {{Unité|26 millions|de dollars}}, 26 millions de dollars un saut de ligne peut se faire entre « 26 » et la suite (mais pas quand on utilise {{Unité|26|millions de dollars}} (comme dans le RI sur cette version de Fyre Festival : [23]).
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 2 juin 2022 à 11:34 (CEST)

Bonjour SyntaxTerror, un dicton en informatique dit "garbage in, garbage out" : si le modèle est mal utilisé, on peut s'attendre à ce qu'il donne des résultats incohérents :) En l'occurrence, aucun des exemples donnés dans la documentation ne valide cette 1re syntaxe et pour cause. Quel sens aurait-elle ? — Vega (discuter) 2 juin 2022 à 19:01 (CEST)

Le modèle met l'espace insécable entre le paramètre 1 et le paramètre 2, normalement le nombre (1) et l'unité (2).

Si j'écris 26 kilo mètres ou 26 méga watt, le kilo ou méga fait partie de l'unité (à tel point qu'on écrit kilomètre et mégawatt). Pareil pour les méga dollars ou millions de dollars. Il faut donc bien écrire {{Unité|26|millions de dollars}}.

Pour simplifier il est possible d'utiliser la syntaxe {{Unité|26 millions de dollars}} qui met l'espace insécable au bon endroit.

— Zebulon84 (discuter) 2 juin 2022 à 20:05 (CEST)

D'accord sur le principe avec Vega et Zebulon84, mais en l'occurrence je mettrais plutôt {{nobr|26 millions}} de [[dollar américain|dollars]] (inutile de convoquer le modèle « Unité » si l'on n'a pas à décrypter l'unité). — Ariel (discuter) 3 juin 2022 à 09:11 (CEST)

Merci de la réponse Vega et Zebulon84. Je sais bien que le problème vient de l'interface chaise-clavier, mais parfois on peut prévoir ça avec les modules et faire en sorte que l'affichage soit quand même correct malgré la mauvaise syntaxe (malheureusement, je n'étais déjà pas bon en lua, et j'ai tout oublié depuis...).

 Ariel Provost : je n'ai fait que corriger du code déjà écrit, ça me prend déjà pas mal de temps, alors je ne veux pas en passer encore plus à tout optimiser, surtout que je ne sais même pas ce qui est le plus économique une fois qu'on a tout pris en compte.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 3 juin 2022 à 13:38 (CEST)

Le modèle gère déjà trop de mauvaise syntaxe. Mais on peut sans doute demander aux bots de corriger ce type d'erreur lorsqu'ils la rencontrent. Je vais regarder ça. — Zebulon84 (discuter) 3 juin 2022 à 14:08 (CEST)

Les g qui ne sont pas des grammes

Bonsoir,

pour écrire "allant de 5.33 g à -2.65 g", j'ai innocemment écrit {{unité|5.33|g}}, mais bien sûr ça n'a pas été, le tooltip (l'infobulle) parle bien sûr de gramme. Avec un grand G on parle de Gauss. Je n'ai pas trouvé mieux que d'utiliser un nobr, en mettant un lien interne vers g (accélération) pour le premier, pour essayer de retrouver l'aspect tooltip quand on survole l'unité. Mais il y avait peut-être une meilleure façon de faire. Si oui, je suis preneur (et surtout curieux de la connaître).

Bonne soirée, Gaillac (discuter) 26 décembre 2022 à 23:27 (CET)

PS: il semblerait que j'aurais pu (dû ?) faire {{unité|5.33|[[g (accélération)|g]]}} => 5,33 g. Infirmation ? Confirmation ?

Bonjour Gaillac . C'est ce qui a été fait sur une centaines d'articles (rechercher accélération).

Sinon il faut créer un symbole du style « g-force ».

--FDo64 (discuter) 27 décembre 2022 à 08:41 (CET)

Bonjour Gaillac et FDo64 .

• Remarque préliminaire : il faut écrire g et non pas g, ce qui distingue justement l'accélération de référence du gramme (le premier est le symbole d'une variable — même si en l'occurrence on en considère une valeur constante —, le second celui d'une unité de mesure standard). Ne pas oublier non plus que cette Wiki emploie comme séparateur la virgule décimale et non le point décimal.
• Réponse à la question posée : pour écrire « allant de 5,33 à −2,65 g » et obtenir la même info par survol de souris qu'avec le modèle Unité, il faut coder allant de 5,33 à {{nobr|−2,65 ''{{abrd|g|g (accélération)}}''}} (ce qui donne « allant de 5,33 à −2,65 g ») ; si l'on veut un lien vers l'article, il faut coder allant de 5,33 à {{nobr|−2,65 ''[[g (accélération)|g]]''}} (ce qui donne « allant de 5,33 à −2,65 g »).

Je n'ai pas employé le modèle Unité parce qu'on n'a pas besoin de ses fonctionnalités de mise en forme des nombres (on considère rarement des accélérations supérieures à 999 g et on emploie rarement beaucoup de décimales) ni de reconnaissance des unités. S'il y avait besoin de formater les nombres il faudrait employer Unité au lieu de Nobr. — Ariel (discuter) 27 décembre 2022 à 19:08 (CET)

Merci à vous 2. Correction effectuée. --Gaillac (discuter) 28 décembre 2022 à 10:56 (CET)

Simplification syntaxe des paramètres des modèles unité et date-

J'essaye de simplifier les paramètres des modèles "unité" et "date-" en supprimant les caractères | de la syntaxe des parametres. L'aide de ce modèles indiquant qu'ils sont nécessaires, certaines de mes contribution de simplification sont annulées. Ce que je fais n'est peut être pas correct mais je n'ai jamais trouvé de cas ou cela était avéré. Si ce que je pense est correct comment peut on l'indiquer dans l'aide de ces deux modèles. Cordialement ... Pano38 (discuter) 11 février 2023 à 11:57 (CET)

Bonjour Pano38 . Je ne comprends pas : c'est déjà le cas pour ces deux modèles, qui autorisent une syntaxe avec seulement le « | » séparant le nom du modèle du paramètre synthétique, par exemple {{unité|2 à 3 e10 kg/m3}} (« 2 à 3 × 10¹⁰ kg/m³ ») ou {{date-|11 février 2023}} (« 11 février 2023 »), comme l'indiquent les deux docs. Que veux-tu changer, au juste ? — Ariel (discuter) 11 février 2023 à 13:26 (CET)

 Ariel Provost je suis bien d'accord sauf que l'aide sur le site au début (section Syntaxe) ne le mentionne pas et certains utilisateurs annulent mes modifications sous prétexte que je ne respecte pas les règles. Comment fait on les mises à jour de la documentation des modèles unité/nb/nombre et date-. . Cordialement ... Pano38 (discuter) 11 février 2023 à 16:15 (CET)

Pour modifier les docs tu peux cliquer sur « Modifer » (1^re ligne de la doc dans la page du modèle) ou afficher la page de documentation (p. ex., la page Modèle:Unité/Documentation) et l'éditer comme n'importe quelle autre page. Une seule précaution : ne pas toucher au bloc d'en-tête (lignes d'appel de modèle) ni au dernier (de <includeonly> à </includeonly>). — Ariel (discuter) 11 février 2023 à 16:27 (CET)

 Ariel Provost j'ai ajouté un petit NB au tout-début du texte. Sent toi libre de le modifier si besoin ... Pano38 (discuter) 11 février 2023 à 16:40 (CET)

Les deux syntaxes sont correctes, les contributeurs sont libres d'utiliser celle qu'ils préfèrent. — Thibaut (discuter) 12 février 2023 à 16:56 (CET)

Tout à fait, mais il importe de ne pas mélanger les deux (résultats imprévisibles mais souvent incorrects, j'en rencontre des exemples de temps à autre). — Ariel (discuter) 12 février 2023 à 17:04 (CET)

Modèles {unité} et {nobr}

Bonjour Herr Satz,

je suis d'accord avec votre résumé, mais d'autres éléments entrent en comptent :

• le modèle {unité} gère aussi des noms d'unités entiers plutôt qu'en symbole (voir Module:Unité/Data) ;
• le code {{unité|75 [[Décibel|dB]]}} est redondant puisque le LI donne déjà une infobulle et même un lien interne vers l'unité. Puisque {unité} est une vraie usine à gaz côté serveur, mieux vaut donc en limiter les appels.

Salutations — Vega (discuter) 23 juillet 2023 à 14:29 (CEST)

PS : à vrai dire, j'ai confondu le nom "bit" (qui s'accorde dans le cas présent : "bits" et n'est effectivement pas géré par {unité}) avec le symbole "bit" (qui lui est géré). Donc votre graphie était bonne ; on pourrait aussi écrire {{unité|32 bit}}. — Vega (discuter) 23 juillet 2023 à 14:35 (CEST)

Bonjour @Vega : Précisément il n'y a aucun intérêt à écrire {{unité|32 bit}} plutôt que {{nobr|32 bits}} si ce n'est consommer inutilement des ressources serveur. La subtilité sur le fait d'utiliser un symbole d'unité (invariable) plutôt qu'un nom commun (qui s'accorde) va échapper à la plupart des lecteurs, et on écrit beaucoup plus volontiers « 32 bits » que « 32 bit » (voir par exemple Architecture 32 bits). — Hr. Satz 23 juillet 2023 à 14:56 (CEST)

Herr Satz, l'intérêt est celui du modèle {unité}, qui peut/pourra avoir d'autres fonctionnalités que la seule infobulle (par ex. : conversion en octets, à l'image de la conversion d'unités sur 20 °C). Quant au choix bits/bit, vous avez sans doute raison. Salutations — Vega (discuter) 23 juillet 2023 à 15:12 (CEST)

@Vega : Cette conversion n'existe pas, et je ne suis pas franchement persuadé par sa pertinence. On en rediscutera quand elle existera. — Hr. Satz 23 juillet 2023 à 15:18 (CEST)