Discussion modèle:Unité

Une page de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche
Autres discussions [liste]
  • Suppression
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives

Sommaire

Virgule[modifier le code]

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[modifier le code]

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[modifier le code]

Est-il possible de modifier ce modèle pour qu'il affiche un message d'avertissement si le 2e 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 2e 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... Clin d'œilMaCRoEco [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... Clin d'œil 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)

English template equivalents[modifier le code]

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[modifier le code]

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.km2 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 km2[1] ⇒ faut-il lire km avec note no 21 ou km2 avec note no 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 no  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)
  1. source / référence ou note

Espace fine[modifier le code]

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 &nbsp; 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 “XXXYY&nbthinspUZZ, 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−1 (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[modifier le code]

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 &#8239;

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 ?[modifier le code]

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[modifier le code]

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−2. Au passage on remarque à nouveau que les exposants du modèle sont plus haut que ceux des balises <sup></sup>. –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[1]
  • avec sup : km2[2]
  • avec ² : km²[3]
  • avec le modèle : km2[4]
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[modifier le code]

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 Clin d'œil. 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)
Fait 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×103.
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 ? »[modifier le code]

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 ? Mort de rire
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 à « &nbsp; », 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[modifier le code]

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 Flag of France.svg 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 &nbsp; 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}}[modifier le code]

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[modifier le code]

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 Clin d'œil). 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[modifier le code]

[1]' Lorsque qu'une unité est assortie d'un appel de note (comparez 'une surface de 10 à 12 km2' 'une longueur de 12 km[2]), 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)

  1. référence bidon pour illustration
  2. seconde référence bidon
Voir aussi :
À 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[modifier le code]

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

C'est même conseillé Clin d'œil :
{{Unité|3.7|m{{3}}/s}} → 3,7 m3/s
{{Unité|3.7|m|3|s|-1}} → 3,7 m3 s−1 (version plus « scientifique »)
Cordialement, Daniel*D 10 mai 2010 à 11:54 (CEST)

Parenthèse entrante et modèle[modifier le code]

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:}}[modifier le code]

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[modifier le code]

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[modifier le code]

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

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

Virgule[modifier le code]

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[modifier le code]

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)
Fait 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 ? Mort de rire) d’ajouter cela à ses corrections… Ce 30 décembre 2012 à 04:45 (CET).

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

Modèle nombre redirigé sur le modèle unité[modifier le code]

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−1: 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, interrogationsetc. Daniel*D 9 février 2013 à 11:56 (CET)

Pourquoi ?[modifier le code]

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[modifier le code]

À 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 m2) 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 , 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 « n », exemples[1],[2],[3],[4] : m2 et m3.

  1. Lexique des règles typographiques en usage à l’Imprimerie nationale, Imprimerie nationale, 2002 ; réimpressions 2007 et 2008 (ISBN 978-2-7433-0482-9), chap.  : « Chimie (compositionde la) », p. 47 ; chap.  : « Mathématiques et de la physique (composition des) », p. 108-111 ; chap.  : « Unités de mesure », p. 175-180.
  2. [PDF] Le Système international d'unité, Bureau international des poids et mesures , 8e édition, 2006. Voir : chap. « Règles d’écriture des noms et symboles d’unités et expression des valeurs des grandeurs », p. 41-46.
  3. « Le système SI d'unités de mesure – 7 unités de base », sur le site dgcis.gouv.fr.
  4. Kurt Gieck, Formulaire technique (traduit en français par G. Bendit, École d'ingénieurs de Bienne - Suisse), Gieck-Verlag, Heilbronn (RFA).
  • 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 m2 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 no 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[modifier le code]

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 »[modifier le code]

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)

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

Un exemple à ajouter[modifier le code]

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

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

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

Bonjour Cjp24 Bonjour :
  • {{unité|10{{exp|−1}}|m}} donne aussi : 10−1 m ;
  • de même que {{unité|10{{-1}}|m}} donne : 10−1 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[modifier le code]

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)

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

Voir aussi[modifier le code]

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

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

Nouvelle version à tester[modifier le code]

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−1
  • accepte les nombres avec une virgule : {{Unité/Bac à sable|1234,5678|m}} → 1 234,5678 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 103
  • 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 m3 kg2 s2 A2 K cd mol−1
  • peut-être utilisé pour formater une unité sans nombre : {{Unité/Bac à sable||10|3|m|3|s|-1}} → 103 m3 s−1
  • 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−1
    • {{Unité/Bac à sable|1.3e3 m3s-1}} → 1,3 × 103 m3 s−1
    • {{Unité/Bac à sable|x10e3 m3/s}} → 103 m3/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 × 103, et non 1,23×103 (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/(m2 · 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)
Notification 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 m3s–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 : , m/s, m · s−1, m s−1 ». 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−1 »
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)
Notification 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 ×[modifier le code]

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 Notification Ramzan : c'est prévu ci-dessus dans #Nouvelle version à tester, Notification 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[1],[2]), par exemple. Ariel (discuter) 9 août 2016 à 15:55 (CEST)
  1. (en) Peter J. Mohr, David B. Newell et Barry N. Taylor, « CODATA recommended values of the fundamental physical constants: 2014 », (consulté le 25 juillet 2016)
  2. Page interactive : (en) « The NIST Reference on Constants, Units, and Uncertainty » (consulté le 25 juillet 2016)

Espace insécable avant un symbole[modifier le code]

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-/8o
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[modifier le code]

Notification 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 × 105 m3
  • {{Unité/Bac à sable | 1,2345 e5 m3 | décimales=6}} → 1,234 500 × 105 m3

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

Notification 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,1234
  • {{Unité/Bac à sable | 0,1234567 | décimales=4}} → 0,1235

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 Clin d'œil : 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 Clin d'œilt 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 Clin d'œil. 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[modifier le code]

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)
Fait 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[modifier le code]

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)

Notification 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
Fait 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[modifier le code]

Le code {{unité|3|e=8|m/s}} me semble parfaitement légitime et sortait correctement, et désormais il donne 3 × 108 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 × 108 m
  • {{unité|3|e=8|m||s|-1}} donne 3 × 108 m s−1
  • {{unité|3 e8 m/s}} donne 3 × 108 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)

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

Mise à jour des docs[modifier le code]

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 »[modifier le code]

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)

Notification 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)
Notification Pols12 : J'ai retiré an et ans de la table des unités.
Notification 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)
Notification 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 Clin d'œil. 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[modifier le code]

Bonjour, Sourire

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)

Notification 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 Bravo !. Tpe.g5.stan (discuter) 18 août 2017 à 15:27 (CEST)

Dollard[modifier le code]

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[modifier le code]

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−25 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[modifier le code]

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 Clin d'œil 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 ![modifier le code]

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 Clin d'œil 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)[modifier le code]

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 Notification 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 m3 ») parce que l'éditeur condense les deux espaces en une, mais le bug apparaît si l'on code ({{unité||m|3}}) (résultat : « (m3) »). — Ariel (discuter) 21 avril 2018 à 08:49 (CEST)
Notification Tractopelle-jaune et Ariel : normalement c'est corrigé. — Zebulon84 (discuter) 22 avril 2018 à 01:52 (CEST)
Effectivement. Merci Zebulon84 Clin d'œil. — Ariel (discuter) 22 avril 2018 à 08:40 (CEST)
Pour moi aussi, c'est bon. Merci Zebulon84 et Od1n Clin d'œil pour la correction du module.
--Tractopelle-jaune (discuter) 22 avril 2018 à 13:11 (CEST)

Pas insécable[modifier le code]

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.
Notification 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 ?
Notification 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)
Notification 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.
Notification 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.
Notification 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)
Notification 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 Clin d'œil. 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 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[modifier le code]

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 Clin d'œil. — Ariel (discuter) 17 mai 2018 à 07:29 (CEST)

Pluriel dans l'infobulle ?[modifier le code]

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)

Notification 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−34 kg m2 s−1 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"[modifier le code]

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

  1. Discussion Projet:Modèle#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 ? Clin d'œil --Niridya (discuter) 23 septembre 2018 à 15:08 (CEST)
Notification 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 Notification 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 Clin d'œil 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)