Discussion modèle:Unité/2

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

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

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

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

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

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

par

64 [[kibioctet|Kio]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vu les avis divergeant et le peu de compromis envisageable à court terme, je clôture la requête et transfère la discussion, ici. La clôture ne veut pas forcément dire que la fusion est irréalisable, ni le contraire... :) — Le message qui précède, non signé, a été déposé par Nouill (discuter), le 5 mars 2010 à 20:10.

Dimensions

Bonjour, y a-t-il un moyen pour que ce modèle gère les dimensions, par exemple 100*100 mm, ou 100*100*100 mm pour des surfaces ou des volumes ? D'avance merci pour vos avis. Cordialement, choumix (discuter) 13 octobre 2014 à 09:42 (CEST).

bjr, {{Dunité}} donne 100 × 80 m ; répond'il au problème des surfaces ?--Dojada (discuter) 24 janvier 2017 à 22:09 (CET)

bjr, de même {{Tunité}} répond au problème des volumes--Dojada (discuter) 26 janvier 2017 à 15:09 (CET)

De même pour les intervalles, peut-on ajouter les mots « puis » et « ou » (aujourd'hui, c'est limité à « à », « et » et « - » ) ? Borvan53 (discuter) 30 mars 2015 à 20:11 (CEST)

Les deux paramètres « puis » et « ou » ont été ajoutés. Ce n'était pas bien compliqué finalement. Borvan53 (discuter) 26 janvier 2017 à 23:31 (CET)

Bug : utilisation de référence avec le paramètre –

Bonjour, je viens de remarquer que l'utilisation d'une référence en combinaison avec le paramètre – génère une erreur, comme on peut le voir ci-dessous :

• {{unité/2|10|–=11|kg}} : 10–11 kg
• {{unité/2|10<ref>ref1.</ref>|–=11|kg}} : 10–11 kg
• {{unité/2|10<ref>ref1.</ref>|–=11<ref>ref2.</ref>|kg}} : 1011 kg

À noter que les paramètres à et et ne génèrent pas cette erreur :

• {{unité/2|10<ref>ref1.</ref>|à=11<ref>ref2.</ref>|kg}} : 10 à 11 kg
• {{unité/2|10<ref>ref1.</ref>|et=11<ref>ref2.</ref>|kg}} : 10 et 11 kg

Cordialement, Wikini (discuter) 24 juin 2015 à 21:20 (CEST)

Parenthèse

Bonjour, est ce que quelqu'un pourrait ajouter au modèle la prise en charge de parenthèse lorsque les paramètres « ± », « + » et/ou « - » sont utilisés en complément du paramètre « e ». En effet, actuellement {{unité/2|2.48|an}} donne 2,48 ± 0,11×10¹⁶ an. Or il peut y avoir confusion sur le fait de savoir si c'est 0,11 qui est multiplié par 10¹⁶ ou bien si c'est l’ensemble : 2,48 ± 0,11. Ajouter des parenthèses lève l'ambiguïté. On aurait ainsi (2,48 ± 0,11)×10¹⁶. Merci d'avance. Pamputt ✉ 15 octobre 2016 à 23:00 (CEST)

Aide mélangeant des exemples avec {{unité ... et {{unité/2|

Par endroit le texte me semble confus car il utilise des exemples avec « {{unité| » alors que c'est normalement l'aide du modèle « {{unité/2| » ... Pano38 (discuter) 15 novembre 2016 à 11:16 (CET)

J'ai complètement repris la documentation du modèle. Borvan53 (discuter) 26 janvier 2017 à 21:38 (CET)

 Borvan53 la documentation cite beaucoup d'exemples avec un seul paramètre, mais quel est l’intérêt d'utilisé ce modèle dans ce cas? Par ailleurs elle dit aussi qu'il est possible de mettre aussi beaucoup de paramètres (plus que 2) mais quel est l’intérêt de cette utilisation ... Pano38 (discuter) 23 mai 2017 à 07:43 (CEST)

Bonjour Pano38. Dans le cas d'un seul paramètre, l'intéret de {{unité/2|…}} réside uniquement dans le fait qu'il affiche « des informations complémentaires complexes au passage de la souris sur la valeur », notamment une conversion d'unité.

C'est un intéret assez relatif, raison pour laquelle je réserve, personellement, l'utilisation de unité/2 exclusivement au cas où il y a 2 paramètres. Borvan53 (discuter) 23 mai 2017 à 09:24 (CEST)

 Borvan53 tout à fait d'accord avec toi. Comme toi je ne l'utilise que lorsqu'il y a 2 paramètres et j'avoue ne pas trop voir l’intérêt des infos au passage de la souris ... Pano38 (discuter) 23 mai 2017 à 11:16 (CEST)

Point ou virgule ?

Bonjour, il me semble que l'avertissement « il faut utiliser le point comme séparateur décimal  » n'est plus valable. En effet, l'exemple donné produit le même rendu que l'on utilise une virgule ou un point. --ContributorQ^(✍) 18 août 2017 à 19:03 (CEST)

 ContributorQ : L'avertissement reste valable, le code était mal écrit, j'ai corrigé. Par contre, si ce modèle pouvait bénéficier de la même amélioration que le modèle {{unité}} et admettre donc les virgules, ce serait pas un mal… Borvan53 (discuter) 18 août 2017 à 20:00 (CEST)

Ok, merci. Autant pour moi, je n'avais pas regardé le code de la documentation. Et, en effet, il serait bien que la saisie d'une virgule décimale ou d'un point soit indifférente. --ContributorQ^(✍) 19 août 2017 à 00:36 (CEST)

Deux incertitudes

Bonjour, est-il souhaitable d'ajouter la possibilité que ce modèle affiche plusieurs incertitudes ? En physique, on note parfois les incertitudes statistiques et systématiques de manière séparée (exemple : 780±60_stat±70_syst s). Est-ce facile à implémenter ? Pamputt ✉ 24 juillet 2020 à 21:03 (CEST)

Dans l’article ci-contre, on rencontre même des incertitudes asymétriques (exemple : 52.6_−8.6^+9.4(stat)^+2.7_−2.1(sys) ). Ce serait chouette d'être capable d'afficher ça avec un modèle. Pamputt ✉ 24 juillet 2020 à 21:11 (CEST)

Infobulle parfois généreuse

Bonjour.
Par exemple, {{unité/2|1000000|Pa}} donne 1 000 000 Pa avec pas moins de 14 chiffres significatifs pour les atm, dans l'infobulle. Record à battre ? Cjp24 (discuter) 15 juin 2023 à 12:34 (CEST)