Discussion modèle:BUtilisateur

Modèle | Documentation | Tutoriel | Projet Boîte Utilisateur

---

Ceci montre qu'un minimum de concertation est nécessaire pour ce modèle. Il est donc grand temps d'ouvrir cette discussion.  <STyx @ 19 octobre 2006 à 21:57 (CEST)

Améliorations

• Ce modèle peut encore largement évoluer (intégration de la documentation, catégorisation, modification du paramétrage, <type>, ...) pour arriver à une situation idéale (voir Utilisateur:STyx/Création de boîte utilisateur)
• Il faudrait également le renommer en, ou créer {{Méta utilisateur}}. {{Méta utilisateur}} est en cours de création
• Il est donc recommandé de ne pas trop l'utiliser pour le moment.

Voir aussi:

• Discussion Utilisateur:STyx#Meta Utilisateur ou BUtilisateur2

  <STyx @ 19 octobre 2006 à 21:43 (CEST)

---

Le travail étant très avancé de côte de BUtilisateur, je ne vois pas trop l'intérêt de tout changer à nouveau. En particulier, je ne vois pas ce que le modèle Meta Utilisateur pourrait apporter de plus par rapport au modèle actuel.

 François Haffner ✉ 24 octobre 2006 à 17:55 (CEST)

---

Avantages : Ce qu'apporte {{Méta utilisateur}} par rapport à {{BUtilisateur}}:

• moins de paramètres
• une normalisation des BU (plus moyen de faire n'importe quoi)
• une procédure simplissime de Création de boîte utilisateur
• une documentation automatique du modèle (avec les liens nécessaires)
• une documentation automatique de la catégorie des utilisateurs de la BU (il suffit de placer la boite)
• des messages d'erreur en cas de mauvais praramètrages
• des sous-modéles permettant de réécrire proprement les sous-pages de Wikipédia:Boîte utilisateur

  <STyx @ 27 octobre 2006 à 14:26 (CEST)

Documentation

pourquoi la masquer ?   <STyx @ 19 octobre 2006 à 21:46 (CEST)

Sous-catégorisation des boites utilisateurs

La sous-catégorisation des boites utilisateurs a été entreprises (une fois de plus, sans consertation). Personnellement, je trouve cette sous-catégorisation superflue car Wikipédia:Boîte utilisateur (catégorise déjà) ; c'est un meilleur endroit pour trouver une boite. Mais s'il faut vraiment sous-catégoriser, qu'on le fasse proprement et automatiquement.

proprement

en adoptant une même nomanclature pour les sous-pages de Wikipédia:Boîte utilisateur, les sous-catégorie de Catégorie:Boîte utilisateur et Catégorie:Wikipédiens et en liant ces sous-pages les unes au autres. entre elles

automatiquement

grace à {{Méta utilisateur|type=..}} (voir Utilisateur:STyx/Création de boîte utilisateur). Je m'y met dès que possible   <STyx @ 23 octobre 2006 à 14:59 (CEST)

C'est nouveau ce modèle "méta" et ça contrevient au fonctionenment (rappel: il y a trop de modèles inclus avec les nocat dans le système actuel, alors qu'on peut faire ça directement avec la {{BUtilisateur}} sans faire appel à un autre modèle).

Verdy p 25 octobre 2006 à 20:26 (CEST)

Attention à ne pas développer dans deux directions différentes. J'ai l'impression qu'on est en train de diverger. Je voudrais qu'on explique clairement pourquoi il faudrait que les boîtes catégorisent automatiquement ou pas. Le problème actuel, c'est que {{Boîte utilisateur}} ne comprend pas les paramêtres. Dès lors, il faudrait commencer par modifier ça pour pouvoir passer des paramêtres en même temps que les noms de s boîtes. Le reste viendra ensuite tout seul.

 François Haffner ✉ 24 octobre 2006 à 17:59 (CEST)

Note: {{Boîte Utilisateur}} (avec la majuscule) comprend déjà tous les paramètres !!! Verdy p 25 octobre 2006 à 20:28 (CEST)

• il n'est pas question ici de "boîtes qui catégorisent ses utilisateurs" mais de "sous-catégorisation des boites utilisateurs" : tu as amorcer (avec Verdy p) une sous-catégorisation de Catégorie:Boîte utilisateur. S'il faut vraiment le faire, qu'on le fasse proprement et automatiquement.
• "paramètre des boîtes dans {{Boîte utilisateur}}" : à la reflexion, je pense que malheureusement il est trop tard pour entreprendre cela - le mauvais pli est pris - au moins de trouver un programmeur/bot suffisament motivé (et puissant) pour entreprendre la reforme.  <STyx @ 25 octobre 2006 à 19:57 (CEST)
• « pourquoi il faudrait que les boîtes catégorisent automatiquement ou pas » : je ne sais pas mais c'est un fait. Je pense quand même qu'il est inutile de recenser les utilisateurs qui n'aime pas les cactus, d'autant cela peut se faire grace aux pages liees.   <STyx @ 25 octobre 2006 à 19:57 (CEST)

Automatiquement? chaque modèle doit avoir sa catégorie, et on ne peut le faire que dans le modèle lui-même. D'autre part l'article mentionné dans "Wikipédia:" est non maintenable: il génère trop d'appels de sous-modèles, et fait déborder le serveur. Les "catégories" indiquées devraient plutôt mentionner de vraies catégories, dans lesquelles on pourra éventuellement faire un article principal, affichant les modèles d'un seul coup d'oeil, mais pas un article multi-niveau. Verdy p 25 octobre 2006 à 20:42 (CEST)

« D'autre part l'article mentionné dans "Wikipédia:" est non maintenable » ?   <STyx @

« vraies catégories » ?   <STyx @

Automatiquement? : oui je viens de voir ca ; c'est une nouveauté du modèle   <STyx @ 26 octobre 2006 à 20:27 (CEST)

---

J'ai commencé la sous-catégorisation uniquement pour nuifier (unifier ?   <STyx @) les anciennes boîtes construites avec le modèle {{Boîte utilisateur}} (avec minuscule) et les nouvelles avec le modèle plus complet et plus simple à créer {{Boîte Utilisateur}} (avec Majuscule, pas besoin d'inclure du code HTML pour la présentation du texte ou des icônes). C'est d'abord pour savoir où j'en suis, mais aussi parce que ces nombreuses boîtes se multiplient et la catégorie actuelle commence à être inutilisable. La catégorisation des modèles devrait en fait adopter la même classification finale que les catégories d'utilisateurs (mais là le système est encore trop complexe pour l'instant car il est multi-niveau).

Je me suis rendu compte aussi que les modèles avec ou sans "/nocat" n'avaient pas forcément le même contenu affiché, et que le système employé est à l'envers (1 modèle de plus employés sans nocat alors que c'est le plus utilisé). Cela rend la page listant tous les modèles impossible à générer (trop de modèles, trop de mémoire dans les limite des 2048 kilooctets pendant l'expansion: au delà, le logiciel MediaWiki arrête l'expansion et laisse les liens vers les modèles non étendus.)

Pour ces modèles utilisés à grande échelle, il faut encore placer leur documentation dans la page de discussion et non dans une section noinclude (c'est un bogue ou une limite actuelle du logiciel qui ne sait pas séparer rapidement dans ses caches le code inclu dans un autre article du code pour l'article lui-même). Verdy p 25 octobre 2006 à 20:15 (CEST)

• que l'on mette fin aux "/nocat"   <STyx @ 26 octobre 2006 à 20:27 (CEST)

D'autre part, nombre de modèles ne sont pas propres et utilisent très mal les espaces et les section noinclude et include. Avec le Modèle:Boîte Utilisateur actuel, il est maintenant inutile d'ajouter une section includeonly (c'est automatique), et on peut tout à fait ne pas afficher le lien vers la catégorie d'utilisateurs (il suffit de ne pas indiquer cette catégorie en paramètre, elle ne sera pas générée à l'inclusion dans les pages utilisateur). On a juste besoin d'une section noinclude pour catégoriser le modèle (et il faut que ces modèles soient catégorisés pour pouvoir les retrouver.) Verdy p 25 octobre 2006 à 20:21 (CEST)

De toute façon c'est toute la page Wikipédia:Boîte utilisateur qui est à revoir. Elle est non maintenable et les vraies catégories sont mieux adaptées pour ça: circulation fluide, pas de surcharge sur le serveur, et possibilité d'y référencer un article principal (qui présente d'un seul coup d'oeil les boites de la catégorie, à l'exclusion des autres sous-catégories. L'article principal peut évidemment être créé dans l'espace "Wikipédia:", mais catégorisé dans une catégorie homonyme (ou reprenant un préfixe commun comme "Catégorie:Boîte Utilisateur xxx" pour l'article "Wikipédia:Utilisateur xxx", et "Catégorie:Utilisateur xxx" pour les utilisateurs catégorisés).

La page par exemple des langues est une horreur pour le serveur, alors que la page du projet Babel est suffisante (avoir recréé les modèles sous un nouveau nom commençant par "Utilisateur " au lieu de "User " comme avant a été une grave erreur: on aurait du seulement créer des redirects pour assurer la compatibilité avec la {{Boîte Utilisateur}} au lieu de la boîte {{Boîte Babel}}, qui d'ailleurs ne nécessite plus non plus d'indiquer le nombre de boîtes dans son nom, les anciens noms avec le numéro pointant maintenant tous sur ce même modèle).

La page Babel avait connu ce grave désagrément que connait maintenant aussi la page "Wikipédia:" jusqu'à ce qu'on utilise le modèle éventail pour présenter toutes les boites de langues d'un seul coup d'oeil, sur des pages séparées et du coup elle est devenue fonctionnelle et rapide.

De même les boites créées avec {{Boîte utilisateur}} sont mal écrites pour la plupart, et cassent les mises en page des pages utilisateur, car elles:

* Forcent l'alignement à droite (impossibilité d'inclure la boite facilement dans le corps d'une page hors d'une {{Boite Utilisateur}}, de nombreux utilisateurs s'étant essayés pour "catégoriser" leurs préférences dans les pages, et usant des trucs HTML ignobles pour essayer de faire rentrer ces boîtes.)

* utilisent des blancs et sauts de lignes mal placés avant le début du modèle, ou pour les sections includeonly et noinclude, ceux qui les ont créés ne connaissant pas bien la syntaxe et ses effets de bord.

* Du coup des utilsiateurs ont copié-collé le code HTML dans leur page ou dans la boite juste pour leurs besoins personnels, et n'utilisent pas les modèles unifiés, ce qui rend compliqué leur recensement et crée des problèmes d'unification.

* On ne peut toujours pas créer des boîtes multicolonnes simplement sans créer un tableau immonde dans la page utilisateur. Toute modification d'une boîte casse la mise en page des pages utilisateurs.

Seul le modèle {{BUtilisateur}} est aujourd'hui complet et supporte tous les paramètres nécessaires. J'ai vérifié, et toutes les boîtes actuelles peuvent utiliser ce modèle unique (y compris les boîtes Babel qui l'utilisent maintenant via les modèles historiques {{Babel field}} et leurs spécialisations {{Babel field 0}} et suivantes. En faisant ça, j'ai rétabli la compatibilité des boites babel avec les boites utilisateur. Du coup il n'est plus nécessaire de garder les doubles (on fera des reidrections uniquement pour compatibilité, mais il FAUT garder les noms "Modèle:User xx-*" pour compatibilité avec les interwikis des autres projets Wikipédias dans d'autres langues). Verdy p 25 octobre 2006 à 21:17 (CEST)

• on est d'accord : Wikipédia:Boîte utilisateur et ses sous pages sont à revoir (en utilisant deux trois modèles internes pour simplifier l'écriture). Réécriture de Wikipédia:Modèles/Espace Utilisateur/Boîte Utilisateur/Charte graphique
• je propose que l'on écrive une Utilisateur:STyx/Recommandation pour règler la question du /nocat, de la majuscule, du nom des boites projet, la couleur, etc.
• je prévois un grand sondage "Organisation de wikipédia". ce sera l'occasion de la faire approuver   <STyx @ 26 octobre 2006 à 20:27 (CEST)
• « compatibilité des boites babel avec les boites utilisateur » : je ne pense que cela soit tres heureux, car la distinction entre "boites babel" et "boites utilisateur" est claire, et les modèles babel existent toujours.
• j'ai bien du mal à te comprendre même en réinterpretant (je suppose que « article » signifie en fait "page", « boîtes multicolonnes » signifie peut être "boîtes paramétrées", ... ?)   <STyx @ 27 octobre 2006 à 18:54 (CEST)

{{Méta utilisateur}}

La première mouture de {{Méta utilisateur}} : Utilisateur:STyx/Méta utilisateur est à peu près au point. {{Utilisateur Projet/Géopolitique}} est un premier test. Je m'attaque à la recommandation et aux sous pages de Wikipédia:Boîte utilisateur (tableau des types) dès demain.   <STyx @ 27 octobre 2006 à 03:08 (CEST)

Attention STyx ! Je crains que tu n'agisses sans concertation. Le modèle aujourd'hui admis et reconnu est le modèle BUtilisateur. On peut certainement l'améliorer, en particulier en lui intégrant passant une variable "type" qui définirait automatiquement les couleurs de fond et de bordure. Pour ce qui est de la catégorisation automatique, je n'y crois pas, mais alors pas du tout. Il n'est pas souhaitable que chacun parte dans une direction différente. Il faut travailler à l'amélioration éventuelle du modèle BUtilisateur et non à la création d'un nouveau modèle. D'autre part, il ne faut pas oublier qu'un modèle trop complexe ne sera jamais utilisé. J'aimerais que tu rejoigne plutôt le projet bien avancé par Verdy p et moi-même.  François Haffner ✉ 27 octobre 2006 à 08:27 (CEST)

« Attention STyx ! Je crains que tu n'agisses sans concertation » : je trouve cela gonflé alors que j'ai ne cessez d'envoyer des messages (auxquels tu as peut répondu) pour avertir de mon travail et appeler à la concertation.

faire évoluer {{BUtilisateur}} en {{Méta utilisateur}} était mon idée première ; mais j'y ai renoncé car {{BUtilisateur}} est trop souple, trop paramétré (je te cite « il ne faut pas oublier qu'un modèle trop complexe ne sera jamais utilisé »), et ne convient donc pas à une normalisation des boîtes.

comme je le dis dans "Utilisateur:STyx/Création de boîte utilisateur" (qui a évolué), {{BUtilisateur}} est fait pour la création de BU personnelles, {{Méta utilisateur}} est fait pour les modèles. Les rôles sont donc bien définis.   <STyx @ 27 octobre 2006 à 14:16 (CEST)

J'ai un peu peur qu'on ne comprenne bientôt plus rien. Moi-même, je ne comprends pas l'intérêt de développer deux modèles très proches avec seulement quelques différences. Les contributeurs vont utiliser tantôt l'un, tantôt l'autre et ça va être la cacophonie et au minimum source d'erreurs. Pourquoi ne pas implémenter simplement le paramêtre "type" dans BUtilisateur ?  François Haffner ✉ 27 octobre 2006 à 16:35 (CEST)

Changer le modèle voudrait dire remodifier toutes les boîtes utilisateur pour la nouvelle syntaxe (et dire que presque tout est déjà fait, il me semble). Mais on pourrait simplement mettre le paramètre type dans BUtilisateur (il me paraît intéressant) et pour la compatibilité, s'il n'est pas inclu, utiliser alors la syntaxe en vigueur maintenant (une ParserFunction de plus, il y en a déjà pas mal). C'est ce qui me parait être l'intéret majeur de Méta utilisateur. Et un peu de liberté ne fait pas de mal. Cordialement, iAlex (Discuter, E-mail), le 27 octobre 2006 à 16:42 (CEST) (Et un conflit de version, je laisse le même texte même s'il reprend un peu celui de François Haffner, avec qui je suis d'accord)

• le "type" est loin d'être l'unique avantage
• « mettre le paramètre type dans BUtilisateur » revient de toute manière à « remodifier toutes les boîtes utilisateur »
• actualiser les BU n'est nullement une nécessité ; l'essentiel est de règler les mauvaises pratiques, les disfonctionnements, les BU tordues et faire en sorte que les nouvelles BU soit proprement crées.  <STyx @ 27 octobre 2006 à 18:06 (CEST)

Ajouter le paramêtre type n'oblige pas à changer les boîtes. Il suffit de tester la présence de type : s'il est défini, on l'applique, sinon on applique les autres critères : couleur, bordure, etc. Bon, d'accord, c'est de la programmation, mais en le faisant proprement, on peut y arriver, j'en suis sûr.  François Haffner ✉ 27 octobre 2006 à 18:25 (CEST)

je repete : le "type" est loin d'être l'unique avantage. De toute maniere {{Méta utilisateur}} emploie {{BUtilisateur}}  <STyx @ 27 octobre 2006 à 18:59 (CEST)

Un exemple complet d'utilisation de {{Méta utilisateur}} (Utilisateur:STyx/Méta utilisateur pour le moment) : {{Utilisateur Projet/Catégories}}   <STyx @ 28 octobre 2006 à 20:12 (CEST)

Pourquoi ne pas implémenter simplement le paramêtre "type" dans BUtilisateur ?

• il suffit de comparer Modèle:BUtilisateur/Documentation et Utilisateur:STyx/Création de boîte utilisateur pour voir où se trouve la simplicité.
• « Seul le modèle {{BUtilisateur}} est aujourd'hui complet et supporte tous les paramètres nécessaires. » --Verdy p : oui et du coup : {{BUtilisateur}} est devenu un modèle de bas niveau ; d'où la création de {{Méta utilisateur}} qui est un simple wrapper et assure la normalisation des boites.
• le code de {{BUtilisateur}} est devenu effroyablement compliqué. Il ne faut pas le compliquer d'avantage.
• {{Méta utilisateur}} n'a qu'une seule syntaxe (et non 4)

Je ne vois pas ce que tu appelles "bas niveau" alors qu'il prend la plupart des paramètres avec des valeurs par défaut qui conviennent, sans avoir besoin d'utiliser un modèle "wrapper" qui ne ferait qu'augmenter le nombre de modèles inclus dans les page.

Je rappelle que les performances du serveur ne dépendent pas de l'aspect "compliqué" du modèle, mais surtout du nombre total de modèles inclus (c'est pour ça par exemple que j'ai renversé les sous-modèles nommés avec "/nocat" (pour gagner en nombre de modèles inclus pour le cas le plus courant, de sorte que c'est maintenant le sous-modèle /nocat qui inclut le modèle sans /nocat, en lui passant le paramètre optionnel "nocat=o"). La différence de performance (liée à la consommation mémoire sur le serveur sur les pages Utilisateur ou les pages de démonstration qui incluent de nombreuses boîtes, comme en témoignent les statistiques que fournit le serveur dans le code HTML généré) est TRES sensible (taille mémoire divisée par 2, temps de traitement divisé par 3 ou plus! C'est le facteur mémoire, 2 mégaoctets maxi par page en comptant CHACUNE des occurences de CHAQUE modèle inclus, qui est le plus limitatif)...

Bref il vaut mieux tout faire dans un seul modèle que les multiplier en utilisant des sous-modèles.

1. alors pourquoi avoir créer et utiliser {{BUtilisateur}} dans ces conditions ? Tu n'est vraiment pas cohérent.
2. J'aimerais une confirmation de ce que tu avances (plus largement j'aimerais une page aide traitant des considérations de performances du logiciel)
3. ce que tu avances est contraire à ce qui se pratique : (les pages les plus importantes utilisent abondament l'inclusion, idem pour les modèles : {{en}} par exemple)
4. ce que tu avances, ne concerne que l'évaluation du modèle (ce qui est négligeable) Voir Discussion Catégorie:Espace Modèle#Faut-il laisser nu les modèles très usuels ? (note:les BU n'ont pas de param.)
5. Note: {{Méta utilisateur}} est inspiré de {{Méta bandeau licence}}
6. en matière de développement informatique, la règle est de faire passer la clarté de la programmation avant la performance
7. ou encore : il faut faciliter la tache de wikipédienss avant celle de la machine  <STyx @ 9 novembre 2006 à 03:53 (CET)

La syntaxe n'est pas si compliquée que ça à analyser (on peut utiliser les commentaires HTML pour la rendre lisible et indentée, même s'il y a des restrictions sur les sauts de ligne, ce que j'ai fait). Verdy p 7 novembre 2006 à 20:47 (CET)

• et encore les avantages de "Méta utilisateur"

  <STyx @ 27 octobre 2006 à 19:18 (CEST)

• ps: je rédige Utilisateur:STyx/Recommandation pour rependre l'ensemble des questions. Vous êtes invités à vous prononcer.

Et regarde les exemples donnés dans la page de documentation. Ce n'est franchement pas compliqué à utiliser, les paramètres sont très clairs et il y a plein de cas qui montre le comportement avec les paraètres par défaut. Les paramètres sont là uniquement pour assurer la compatibilité et éviter de tout casser avant que les modèles existants soient simplifiés. C'est ce qui permet l'unification des présentation et rend les boites compatibles entre elles sur les pages (cela résoud les problèmes d'alignement).

"pas compliqué" pour moi, mais beaucoup trop compliqué pour le néophyte.

A propos d'exemple : regarde {{Utilisateur Projet/Catégories}} et sa catégorie.  <STyx @

En attendant, tu m'as demandé de me prononcer sur ta page de "proposition" (et tu as réitéré ta demande sur ma page utilisateur) alors qu'elle n'est franchement pas rédigée et constitue seulement un panier de titres avec différentes options sans aucune présentation des solutions. Dans l'état, je ne vois pas pourquoi je discuterais sur ta page, alors que cette page ici est faite pour ces discussions. Verdy p 7 novembre 2006 à 20:57 (CET)

"solutions" ? non ce sont des propositions. Mais puisse que visiblement cela n'intéresse personne pas même toi ; je renonce à une PdD ou un sondage et je vais appliquer la règle du "qui ne dit mot, consent".   <STyx @ 9 novembre 2006 à 03:53 (CET)

faire de ∇ un flottant

Une amélioration du modèle : cela recentre le texte et évite la place perdue. voir ici, et Utilisateur:FH/BUtilisateur/Documentation pour le résultat. (plus valable)   <STyx @ 28 octobre 2006 à 19:55 (CEST)

Je n'aime pas le résultat. Le triangle inversé se retrouve ni en haut, ni en bas, ni au milieu, mais à une hauteur bizarre. Voir par exemple {{utilisateur habite France}}. Gentil ♡ 10 novembre 2006 à 02:56 (CET)

∇ est aligné avec le titre. J'aimerais le placer en haut, mais c'est difficile. Par ailleurs, il faut bien voir ce que cela apporte. Le texte est maintenant centré dans le cadre ; et surtout, les BU ont étaient concues sans ∇, l'ajout de ∇ (qui diminuait la largeur du cadre) a fait débordé nombres d'entre en hauteur. Faire de ∇ un flottant permet de solutionner ce problème.  <STyx @ 10 novembre 2006 à 15:24 (CET)

Hauteur trop grande pour les images non carrées

Par exemple :

∇

Lausanne

J’habite à Lausanne.

Ne peut-on faire en sorte que la hauteur des images ne dépasse pas 45px de manière automatique ? C'est un problème important car les images sont susceptibles d'être remplacées par de nouvelles versions avec le temps, donc avec de nouvelles dimensions à chaque fois. On aimerait bien ne pas avoir à toucher aux paramètres des boites à chaque fois. Gentil ♡ 13 novembre 2006 à 00:48 (CET)

le plus simple est de crèer une image recadrée et redimensionnée (de 45px donc) dont l'usage sera réservé à la boîte.  <STyx @ 13 novembre 2006 à 02:12 (CET)

Je pensais plutôt à tronquer l'image par une astuce CSS du genre « max-height:45px; ». Gentil ♡ 13 novembre 2006 à 02:51 (CET)

Savez-vous que vous pouvez contraindre une image en hauteur plutôt qu'en largeur, voire aussi les deux ?

Indiquez la taille par exemple au format "60x45px" (pour contraindre les deux dimensions avec un rapport d'échelle identique dans les deux dimensions, tout en s'assurant que l'une ou l'autre des dimensions sera égale à l'une des valeurs sans dépasser le maximum imposé) ou "x45px" (pour contraindre uniquement la hauteur sans contrainte de largeur minimale ou maximale). MediaWiki fera le calcul d'échelle approprié pour ne pas dépasser cette contrainte ! Bref, pas besoin de code CSS du tout, la solution est bien plus simple ! (note: la propriété CSS max-height n'est pas supportée dans de nombreux navigateurs, donc elle n'aura aucun effet, contrairement au redimensionnement forcé de l'image par le serveur d'images de MediaWiki lui-même).

De fait, la taille par défaut utilisée par ce modèle devrait probablment être 45x45px et non simplement 45px (si on tient absolument à une image dans un carré de taille largeur fixe, voire 60x45px si on veut éventuellement admettre que des images au format portrait 4:3 puissent s'élargir un peu en conservant la hauteur souhaitable : l'image sera moins haute seulement pour les panoramas plus larges que le rapport 4:3, par exemple les images en 16:9, qui auront alors la largeur maximale de 60px mais une hauteur inférieure à 45px), voire encore x45px pour forcer toutes les images à la même hauteur et unifier la hauteur des boîtes, quitte à avoir une largeur d'icône variable et pouvant dépasser le carré dont uniquement la largeur minimale est indiquée par le paramètre width de la cellule dans laquelle elle s'affiche.

Dans cette optique, les paramètres de taille pourrait être totalement supprimés du modèle (ou ignorés par lui) et sélectionnés automatiquement par le modèle lui-même en fonction du nombre d'icônes à afficher dans le carré de gauche. Verdy p (d) 9 septembre 2009 à 03:10 (CEST)

Bonjour! Y aurait-il une contre-indication à alors modifier le modèle pour y mettre "x45px" à la place de "45px" comme défaut pour la taille de l'image? — François [Discussion] 29 février 2012 à 15:14 (CET)

Problème sur IE

C'est moi où sur IE6, la barre horizontale séparant texte de texte2 se transforme en un gros rectangle ?

Quelqu'un peut-il y remédier ? J'ai fait des tentatives avec mon modèle perso de boîte utilisateur mais je n'y parviens pas.

Moolligan 23 mars 2007 à 13:14 (CET)

ID -> Class

Bonjour, je viens de changer tous les id en classe, car un identifieur doit être unique pour toute une page HTML, hors, si on place deux boite de langue (c'est plutôt classique) ce n'est plus le cas.

Je n'ai rien trouvé dans les feuilles de style qui fasse référence à ces identifiants, mais il se peut qu'il y en ai tout de même, et qu'il faudrait corriger. N'hésitez pas à demander si vous avez un problème d'affichage. bayo 25 mai 2007 à 17:39 (CEST)

Autres langues

Il n'y a rien dans "Autres langues." J'en connais quelques-uns.

[[en:Template:Userbox]]
[[de:Vorlage:Userbox]]
[[pt:Predefinição:Userbox]]
[[hr:Predložak:Suradnički okvir]]
[[it:Template:Userbox]]

Snakesteuben (d) 15 mars 2008 à 10:04 (CET)

Correction CSS des unités de tailles

Les tailles en points (pt) ont été remplacées par des tailles en pixels : le point est une unité absolue qui ne doit pas être employée sur le media screen (où les moteurs de rendus des navigateurs le convertissent tant bien que mal en pixels). La taille par défaut des textes (passée de « 8pt » à 11px) peut nécessiter quelques adaptations selon les cas précis de BU. Nhésitez pas à signaler ici les éventuels problèmes d'affichages rencontrés. Cordialement, --Lgd (d) 30 mai 2008 à 09:31 (CEST)

Une mauvaise idée. Pour des raisons d'accessibilité, la résolution en points par pixel doit rester ajustable par l'utilisateur, pour faciliter la lecture du texte. Rassure-toi les navigateurs font un bon travail pour ajuster de façon raisonnable les tailles de texte de points en pixels.

Certains utilisateurs ont de bonnes raisons pour ne pas employer des tailles fixes en pixel à l'écran et voudront des résolutions de texte agrandies (à plus de 100%) par rapport à la résolution nominale de l'écran (celle retournée par les pilotes d'écrans, et les règles de conversion utilisant le "point logique" propre au système, puisque le point logique de Windows est différent du point physique (et ne correspond au point physique que si l'écran rapporte une résolution de 96dpi). MacOS utilise pour des raisons historique un point logique de 72 dpi (comme PostScript aussi) : les polices pour chaque environnement en tiennent compte et mentionnent leur propre ajustement en fonction du système hôte et du système pour lesquelles ces polices ont été définies nominalement... Ces utilisateurs emploient alors des écrans adaptés et suffisamment larges ou d'une résolution suffisante pour supporter des caractères agrandis.

L'affichage sur mobiles ou ultraportables (netbooks) utilise souvent des résolutions nominales d'écran différentes, souvent plus élevées (en dpi) sur les netbooks, mais plus réduites sur les mobiles plus bon marchés.

L'affichage sur téléviseur (par liaison analogique modulée, SVidéo, RVB ou YUV) utilise aussi la plupart du temps une résolution nominale réduite (nécessitant donc un agrandissement des caractères en taille physique, pour le quel le point logique est plus grand, sinon le texte est difficilement lisible et flou si on n'agrandit pas la taille en pixels des caractères (le point logique est donc plus grand en pixels comme en taille réelle)

Si le téléviseur est un modèle HD (via une connexion DVI ou le plus souvent HDMI), on garde souvent le même problème: les téléviseurs HD ne sont pas destinés à être regardés à 30-50 cm de l'écran (comme sur un moniteur de bureau ou l'écran d'un PC portable) mais de plus loin, en raison de leur taille souvent plus importante: il faut donc une résolution plus élevée (donc des tailles en pixels plus élevées pour les caractères affichés sur les grands écrans de 19 pouces et plus).

Pour ces raisons, imposer les pixels à l'écran est une mauvaise idée (même si on ne peut guère faire autrement pour dimensionner les images). toutefois le degré de variation du rapport d'échelle entre les tailles en pixels des images et en points logiques pour le texte reste limité: de 85% à 100% de la taille nominale (rarement) pour les petits écrans regardés par les personnes n'ayant pas de difficulté de vision, 100% pour les écrans de PC portable et de bureau jusqu'à 19 pouces, et de 100% à 125% pour les écrans de grande taille ou pour les personnes ayant des difficultés de vision et employant un moniteur de bureau ou de PC portable.

Quand on sait ça, il ne reste plus qu'à en tenir compte dans la mise en page pour qu'elle puisse supporter une telle adaptation. Il ne faut pas supposer que les rapports d'échelle seront conservés, de la même manière aussi qu'on ne doit pas croire que la largeur de l'écran ou de la fenêtre en pixels aura une taille minimale de plus de 800 pixels (on doit pouvoir permettre toute largeur entre 640px et 1280px sans difficultés de mise en page, grace au jeu des marges et centrages des contenus (images et texte). Personnellement je hais les sites qui imposent une largeur fixe en pixels et supposent ensuite un rapport de 100% entre le pouce logique et le pouce physique, ou une résolution fixe de 96dpi pour la conversion du pouce logique en pixels.

Note: certains navigateurs connaissent la notion aussi de pixel logique qui meur permet de conserver cette résolution fixe, quitte à jouer sur la taille de rendu des images qui seront soient agrondies, soient réduites, mais cela ne marche pas toujours avec les composants actifs comme Flash, les MediaPlayers, les applets, pour lesquels ils tentent de négocier la dimension réelle en pixels physiques avec le composant actif lors de son instanciation.

La solution pour le web est toutefois évidemment d'utiliser des polices vectorielles avec un moteur de rendu de bonne qualité permettant de lisser les contours de texte et ajuster correctement la "noirceur" des traits. De même le navigateur devrait utiliser des algorithmes d'ajustement de taille des images physique de pixels physiques en pixels logiques avec de bonnes performances et de qualité (sans artefact de pixélisation notable, même pour les bitmaps affichant des dessins au trait, à contours fins ou contrastants). De vieux navigateurs ont des rendus graphiques assez désastreux des images redimensionnées côté client: c'est surtout visible sur les images de petite taille (en pixels physiques) contenant une grande densité d'informations sur quelques pixels, comme les icônes ou les bitmaps d'émulation du texte ou du texte scanné.

En revanche le moteur de rendu graphique d'Adobe (pour les PDF ou SVG par exemple) est vraiment d'une qualité irréprochable (on ne peut pas facilement faire mieux pour le rendu des bitmaps, car le filtrage employé est dynamique et s'adapte à l'anlyse contextuelle des images pour ajuster divers paramètres de contraste). Pour le rendu du texte (en polices vectorielles), Microsoft a encore un peu d'avance (à condition d'utiliser les polices TrueType compatibles avec certaines des techniques protégées par ses brevets), mais on peut s'en passer pour le web avec des polices TrueType utilisant des techniques comparables même si différentes. Pour le rendu des couleurs (texte ou graphique), Adobe a encore un peu d'avance mais perd du terrain (il est maintenant plus facilement rattrapé car les profils de couleurs standardisés permettent un réglage idéal des niveaux de contraste et de séparation des couleurs et traits). Personnellement je ne vois plus de différence avec ce que produit Apple dans Safari, ou Google dans Chrome: le modèle sRGB est un standard de l'industrie bien respecté au moins pour l'affichage sur écran (c'est bien plus compliqué pour l'impression, où les pigments sont non normalisés, de taille et de diffusion différente et leur aspect dépend aussi du support et techniques d'impression, tout n'étant pas non plus décrit par les pilotes d'impression ni rapportés au système par l'imprimante qui effectue souvent des traitements locaux propriétaires et non documentés, uniquement pour reproduire au mieux certaines images de référence sur un nombre limité de supports, en général de qualité bien supérieure à ce qu'utilise la plupart des gens !).

Bref, évitez de mettre des tailles fixes au texte, et si vous le faites (pour un usage limité par exemple dans une petite boite), utilisez des tailles en points (logiques) et non en pixels (logiques). Retaillez les images en pixels (physiques dans le fichier bitmap transmis en ligne) qui seront rendues en pixels logiques (entre 85 et 150% selon les cas) par le navigateur selon la nature de l'écran et les préférences de l'utilisateur, et laissez les utilisateurs ajuster les autres paramètres sur leur système, en admettant un certain niveau de variation via les marges suffisantes. Et n'assumez pas un rapport donné ente les points/pouces/millimètres logiques d'une part et les pixels logiques d'autre part (cela varie, suivant les classes de périphériques supportés par les systèmes d'exploitation hôte, ou les moteurs de rendus employés, entre 72, 96 et 120 pixels logiques par point logique, une valeur fixe pour chaque hôte installé mais ne variant généralement pas selon les préférences de l'utilisateur, sauf en cas de changement drastique de la résolution en pixels de l'affichage via le panneau de configuration d'affichage ou via les paramètres de configuration du périphérique système).

Verdy p (d) 9 septembre 2009 à 04:31 (CEST)

Ajout d'un paramètre facultatif

Bonjour,
Est-ce qu'il serait possible que quelqu'un s'occupe de cette demande ? La page est protégée, donc je ne peux pas m'en occuper. Il faut en fait changer les lignes :

    -->{{#if:{{{catégorie|}}}|[[Catégorie:{{{catégorie}}}|{{PAGENAME}}]]}}<!--
    -->{{#if:{{{catégorie2|}}}|[[Catégorie:{{{catégorie2}}}|{{PAGENAME}}]]}}<!--

par

    -->{{#if:{{{catégorie|}}}|[[Catégorie:{{{catégorie}}}|{{{sort|{{PAGENAME}}}}}]]}}<!--
    -->{{#if:{{{catégorie2|}}}|[[Catégorie:{{{catégorie2}}}|{{{sort2|{{PAGENAME}}}}}]]}}<!--

Merci! --Riba-- (d) 13 décembre 2008 à 05:15 (CET)

Est-ce que quelqu'un peut passer un commentaire sur cette modification? Tout le monde est d'accord? Qui ne dit mot consent? --Riba-- (d) 2 janvier 2009 à 15:06 (CET)

Hyperliens vers les images

Bonjour, les hyperliens accessibles en cliquant sur les images du modèle ne pointant nul part, serait-il svp possible d'ajouter |nolink comme je viens de le faire sur wikt:fr:Modèle:BUtilisateur ? JackPotte (d) 16 août 2009 à 14:39 (CEST)

C'est la porte ouverte à une violation de droit d'auteur, en ce que (i) certaines images sont sous licence CC-BY, demandant une clause d'attribution et (ii) il n'y a pas d'autres pages permettant d'effectuer cette attribution (e.g. l'on pourrait imaginer un lien crédits photographiques qui apparaitrait en dessous de chaque page et donnerait les liens vers les images et leur auteur). --Dereckson (d) 5 septembre 2009 à 21:53 (CEST)

Ultra contre : violation des licences. Loreleil ^[d-c]-dio 5 septembre 2009 à 21:57 (CEST)

Nous avons le même problème pour Modèle:Utilisateur_interwikis : pourrait-on obtenir la même dérogation de l'image tout en haut à gauche du site amenant à la page d'accueil (sachant qu'il s'agit des mêmes) ? JackPotte (d) 6 septembre 2009 à 04:04 (CEST)

Incitation de <imagemap> que l'on retrouve aussi chez les plus chevronnés. JackPotte (d) 6 septembre 2009 à 04:54 (CEST)

Je ne trouve pas le tutoriel interdisant ce type de lien, quelqu'un peut-il l'écrire svp ? JackPotte (d) 6 septembre 2009 à 10:24 (CEST)

Pour des modèles comme utilisateur interwiki, oui c'est possible : suffit de vérifier que toutes les images utilisées sont bien sur la page des crédits graphiques. --Dereckson (d) 6 septembre 2009 à 11:36 (CEST)

Un peu lourd cette page de crédits graphiques (hormi pour les rares images qui sont sous copyright Wikimedia comme les logos officiels et protégés, les images de fond des thèmes, et celles affichés par les modèles appelés depuis les messages de localisation "MediaWiki:" qui apparaissent dans l'interface et non dans les articles édités eux-mêmes).

Il me semblerait plus pratique d'autoriser les liens image uniquement dans les modèles (voir plus bas pourquoi), et s'assurant que le modèle une fois inclu contiendra un appel (numéroté) de note de référence. Le lien vers la page de description sera alors dans la section références affichée en bas de page sous le numéro correspondant, sous une forme préférablement générée par un modèle donnant simplement le nom de l'image correspondante. Cela respecterait toujours le droit d'auteur, et permettrait de conserver l'aspect pratique de la navigation en cliquant sur l'image, tout en ayant la possibilité de cliquer aussi sur l'appel de note également affiché dans un endroit pratique du modèle qui utilise un tel lien sur image, pour trouver la page de description de cette image.

De plus, rien n'interdit un seul et unique appel de note (bien visible dans le modèle) de contenir dans la note plusieurs liens vers les pages de description ou un lien vers une page spécifique contenant une liste de crédits graphiques pour les images employées par le modèle et liées à une autre page. On doit bien pouvoir toujours caser un tel appel de note dans n'importe quel modèle, et cette solution permet aussi d'éviter de trop allonger de façon répétitive dans de nombreux articles employant ce modèle une longue liste de crédits graphiques (c'est à dire la liste complète des liens vers les pages de description des images employées dans un modèle: cette page de liste de crédits peut être une sous-page du modèle lui-même...). L'intéret étant que la liste des crédits graphique n'a pas nécessairement à être sur une seule très longue page difficilement exploitable où il est difficile de retrouver une image. Cette page de liste de crédits (référencée de façon explicite dans le texte de la note) peut simplement être une galerie... ne mentionnant que le nom des images pouvant être employées par le modèle, lesquelles seront toutes affichées dans une miniature permettant une identification facile et immédiate et de la lier à la page de description de chacune des images de la galerie.

Comme je l'ai dit dans la Wikidémie, le danger est d'oublier l'appel de note ou que celui-ci n'apparaisse pas de la façon prévue à cause d'un problème. De fait il faudrait pouvoir patrouiller les pages utilisant de tels liens: cela suppose l'utilisatin d'un catégorie de maintenance contenant les utilisations. Mais il faut aussi pouvoir vider cette catégorie des pages qui ont déjà été patrouillées à ce sujet: un outil comme les "pages validées" permettrait de s'assurer que ce patrouillage reste valide, et lors du patrouillage on pourrait alors changer la catégorie de suivi des emplois vers une catégorie des emplois déjà patrouillés et validés. Pour ces raisons, on devrait aussi limiter l'emploi des liens sur image uniquement à l'espace des modèles, voire à une catégorie précise de modèles génériques pour lesquels un tel emploi a été autorisé et qui reste facilement patrouillable, sans trop de pages à contrôler.

Un problème actuel (corrigeable) est que MediaWiki ne signale pas et ne renforce pas encore la présence d'une section références par défaut dans la page si celle-ci a été oubliée et non positionnée dans une section de la page, et si la page (ou un de ses modèles inclus) contient des appels de notes de références. Je pense qu'il devrait être possible de demander cela aux auteurs de MediaWiki.

(ce serait d'ailleurs bien pratique lors de la prévisualisation de l'édition d'une section seulement de la page, où de tels appels de notes de références sont présents, mais pas la section références elle-même qui se situe ailleurs que dans la section éditée: MediaWiki devrait être capable alors de générer automatiquement à l'affichage une section additionelle "Notes et références" par défaut permettant de visualiser les notes en même temps qu'on les édite dans une partie seulement de la page; de même si on édite la page entière, lors de la sauvegarde, une telle section pourrait aussi être ajoutée automatiquement en bas de page si elle a été oubliée, même si son placement n'est pas le plus idéal et cette section devrait être parfois remontée).

Verdy p (d) 9 septembre 2009 à 02:35 (CEST)

Comme ce dernier commentaire a suscité une réponse sur la wikidémie j'y réponds là-bas. JackPotte (d) 12 septembre 2009 à 10:12 (CEST)

Liste ∇

Bonjour! Pourrait-on ajouter &hideredirs=1 à la ligne ci-dessous?

[{{fullurl:Special:Pages_liées/Modèle:Utilisateur {{{lien}}}|namespace=2&hidelinks=1}} ∇]

Merci! — François [Discussion] 29 février 2012 à 15:31 (CET)

Bonjour,

Avant tout, je précise que je n'ai pas accès en écriture au modèle. Néanmoins, je fais partie du projet BU. Peut-tu expliquer en quoi consiste cette modif, pourquoi, et quel en sera le résultat ?

Wikipediennement, Epok__ Insultes, éloges ou simples discussions : ✉, le 29 février 2012 à 15:36 (CET)

Il s'agit simplement de retirer les pages de redirection de la liste lorsqu'on clique sur le ∇ (n'avoir vraiment que les pages où la boîte est incluse).

— François [Discussion] 29 février 2012 à 17:05 (CET)

Est-tu sur que c'est nécessaire ? Si je ne me trompe pas, les pages incluant la redirection sont celles qui apparaissent en utilisant un alinéa, c'est ca ?

Le clic sur "lien" permet d'afficher tous les utilisateurs utilisant la BU. Supprimer ceux qui l'utilisent via une redirection donnerait alors une liste incomplète, non ?

Cas classique : renommage d'une BU : tous les utilisateurs de la BU disparaitraient, à l'exception de ceux qui utilisent le nouveau nom ?

Epok__ Insultes, éloges ou simples discussions : ✉, le 29 février 2012 à 17:14 (CET)

Voilà, je viens de vérifier (oui je ne passe que par à-coups sur WP!): le masquage des redirections ne masque que la page de redirection elle-même; les pages incluant le modèle redirigé continuent à être affichées. — François [Discussion] 5 juin 2012 à 11:34 (CEST)

As-tu un exemple de modèle de BU sur lequel ce changement serait utile ? Epok__ Insultes, éloges ou simples discussions : ✉, le 5 juin 2012 à 12:05 (CEST)

nocat

On voit parfois apparaître le paramètre nocat (par exemple nocat = {{{nocat|}}}). Ce paramètre n'est pas décrit dans la documentation du modèle. Pourrait-on le faire en expliquant à quoi il sert ? --Berdea (discuter) 6 septembre 2013 à 16:36 (CEST)

Oui, ce paramètre doit apparaitre dès qu'il y a le param catégorie, mais par contre ne sert à rien pour le paramètre lien. Il s'agit d'une simple transmission du param au modèle (donc sous la forme que tu décris et aucune autre). Il permet à un utilisateur de la BU de ne pas apparaitre dans la catégorie si tel est son désir, en y adjoignant simplement une valeur quelconque. C'est vrai qu'il n'apparait pas dans la doc. J'essaierai de l'ajouter quand j'aurai le tps, sauf si tu veux le faire toi même, en supposant que mon explication soit claire Epok__ Insultes, éloges ou simples discussions : ✉, le 6 septembre 2013 à 22:37 (CEST)

Cette forme te convient-elle ? Epok__ Insultes, éloges ou simples discussions : ✉, le 9 septembre 2013 à 13:25 (CEST)

Amélioration graphique

Bonjour, à la 4ème ligne, pourrait-t-on remplacer white (à côté de img-couleur) par couleur ? Cela ferait en sorte qu'à chaque fois qu'img-couleur est non spécifié, il s'accorde à la couleur du reste de l'infobox.

Merci d'avance, Archi38 pour vous servir (discuter) 14 février 2016 à 16:09 (CET)

Un certain nombre de boites, dont les premières, les boites de langues, ont une couleur différente entre le fond de l'icône et le fond du texte. C'est certainement dans cette logique que les valeurs par défaut sont différentes, et non transparentes. Mais si d'autres personnes soutiennent cette demande, je ferai le changement (vers transparent plutôt que {{{couleur|}}}) — Zebulon84 (discuter) 14 février 2016 à 20:25 (CET)

 Zebulon84 : Vous n'avez pas compris l'effet. Si vous changez background-color:{{{img-couleur|white}}} en background-color:{{{img-couleur|couleur}}} cela changera la couleur du paramètre img-couleur seulement si elle est non spécifiée. Si elle est indiquée comme pour les boites langues, cela ne changera rien.

Cela va harmoniser toutes ces boites où le créateur à négligé les finitions comme celle-ci par exemple. Archi38 pour vous servir (discuter) 14 février 2016 à 20:38 (CET)

J'ai bien compris ce que vous vouliez dire. {{{img-couleur|couleur}}} ne marcherait pas car « couleur » n'est pas une valeur reconnu par les navigateurs web. Il faut donc utiliser {{{img-couleur|transparent}}} (qui laisse voir la couleur du fond de l'élément parent si img-couleur n'est pas précisé, ici la couleur de la table que l'on voit au niveau de la zone de texte) ou {{{img-couleur|{{{couleur|#eee}}} }}} (qui prend la couleur définie pour la zone de texte si img-couleur n'est pas précisé).

Personnellement je trouve cette BU Aphrodite très bien comme ça.

— Zebulon84 (discuter) 14 février 2016 à 21:55 (CET)

L'arguement couleur marche, car c'est la couleur de fond de la partie droite (je le sais, j'ai vu ça sur Wikiversité)

Si vous n'êtes pas convaincu baladez-vous sur Wikiversité et faites attention aux boite utilisateur, c'est bien plus beau ! Archi38 pour vous servir (discuter) 14 février 2016 à 22:06 (CET)

Bonsoir,

Je plussoie Zebulon84 (d · c) pour le paramètre "transparent" pour la couleur de l'image plutôt que de le fixer à la même couleur que l'arrière-plan. J'avais d'ailleurs déjà fait cette proposition il y a quelques temps maintenant, mais il m'avait été répondu que cela pouvait poser des problèmes pour de nombreux modèles. Et il faudrait bien mettre {{{couleur|[...]}}} et non juste couleur.

Le problème posé par cette modif est que de nombreuses boîtes ne renseignent pas ce paramètre, et cela pourrait "casser" l'affichage (la visibilité de l'image) de certaines boîtes.

Il faudrait au moins faire un inventaire des situations existantes pour voir les changements impliqués avant de décider de cette modif...

Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 14 février 2016 à 22:18 (CET)

En pratique mettre simplement « couleur » fonctionne car les navigateurs ne reconnaissant pas la couleur font comme si aucune couleur n'était précisée et applique la valeur par défaut : transparent. Mais mettre une fausse valeur pour qu'elle soit ignorée n'est pas propre techniquement, surtout qu'il est aussi simple de mettre « transparent ».

Quand au « c'est bien plus beau », c'est une question très subjective ; les gouts et les couleurs... c'est comme les boites et les boîtes. — Zebulon84 (discuter) 14 février 2016 à 22:38 (CET)

Description du code lien et catégorie

Bonjour .

Dans le chapitre Modèle:BUtilisateur#Lien_∇ je propose de changer le passage pour la syntaxe en ajoutant un exemple :

• pour lien ajouter : Cela donne dans le code de la boîte utilisateur le code : |lien = Wikipédia.
• pour catégorie ajouter : Cela donne dans le code de la boîte utilisateur le code : |catégorie = Utilisateur Wikipédia |nocat = {{{nocat|}}}.

cela donnerait :

• Le paramètre lien s'utilise en passant comme paramètre le nom simple de la boîte utilisateur, c'est-à-dire les caractères suivant Modèle:Utilisateur. Par exemple, pour la boîte utilisateur Modèle:Utilisateur Wikipédia, le nom de la boîte est Wikipédia. Cela donne dans le code de la boîte utilisateur le code : |lien = Wikipédia.
• Le paramètre catégorie en revanche s'utilise en fournissant le nom complet de la catégorie. Ainsi, pour une catégorie nommée Catégorie:Utilisateur Wikipédia, la valeur du paramètre catégorie devra être Utilisateur Wikipédia. Renseigner ce paramètre a pour effet de catégoriser toutes les pages utilisateurs utilisant la boîte dans cette catégorie. Pour cette raison, le paramètre catégorie doit toujours être accompagné du paramètre nocat = {{{nocat|}}} pour permettre aux utilisateurs d'ignorer la catégorie. Cela donne dans le code de la boîte utilisateur le code : |catégorie = Utilisateur Wikipédia |nocat = {{{nocat|}}}.

Je pense que cette petite modification aiderait fortement à la compréhension.
Cordialement, Ferro~frwiki (discuter) 28 juin 2023 à 13:20 (CEST)

Bonjour Ferro~frwiki. Je ne vois pas l'intérêt de ces ajouts. D'une part, « Cela donne » n'est pas très clair. D'autre part, l'emploi d'un paramètre de modèle est un élément commun à tous les modèles ; la syntaxe est décrite dans Aide:Modèle#Paramètres. Enfin, la syntaxe préconisée pour le présent modèle est visible dans divers exemples donnés plus bas dans la documentation. Une description synthétique est souvent plus efficace.

En revanche, je pense que la phrase concernant le nocat n'est pas facile à comprendre. Je propose de reformuler et préciser le passage, avec un lien interne : « Renseigner ce paramètre a pour effet de regrouper automatiquement dans cette catégorie, les pages utilisateur qui portent la boîte. Dans le code des modèles de boîtes, le paramètre catégorie doit toujours être accompagné du paramètre nocat = {{{nocat|}}}, afin de permettre aux utilisateurs de s'affranchir de la catégorisation en sollicitant le paramètre « nocat ». »

Cordialement, — Ideawipik (discuter) 28 juin 2023 à 14:41 (CEST)

Ma proposition n'est peut-être pas pertinente, mais il n'est pas simple de comprendre le fonctionnement. Moi-même, je m'y suis cassé les dents au départ, d'où ma proposition d'illustration de l'exemple donné avec le code correspondant.

Il faut peut-être revoir la formulation, je ne sais pas trop. En tout cas pour le moment, il y a de quoi se gratter la tête pour comprendre comment coder ça.

Pour expliquer le fonctionnement à un autre utilisateur je passe par cette illustration :

Pour le pointage catégorie d'une BU voici la procédure ; en gros il faut :

• pour un lien répéter le nom de la BU sans Utilisateur
• pour une catégorie répéter le nom complet de la BU (avec Utilisateur cette fois) et ajouter la ligne nocat = {{{nocat|}}}. Cela donne :

|lien = VTT

ou bien

|catégorie = Utilisateur VTT   |nocat = {{{nocat|}}}

comme dans la Discussion_Projet:Boîte_Utilisateur#VTT.

Du coup, je me suis dit que j'allais essayer de mettre le modèle à jour en ce sens, mais il y a un blocage, probablement justifié d'ailleurs.

Je ne suis pas du tout attaché à ma formulation, le but étant de faire comprendre comment coder, pas de faire une dissertation. Si vous en avez une meilleure, utilisez là.

En général les utilisateurs comprennent bien la partie nocat = {{{nocat|}}} mais moins, voir pas du tout la partie lien/catégorie. C'est le retour que je peux faire après pas mal de modifications sur de nouvelles créations de BU faites par d'autres utilisateurs.

J'ai pu constater à peu près toutes les possibilités erronées :

|lien = Utilisateur VTT

|catégorie = VTT |nocat = {{{nocat|}}}

|catégorie = VTT

|lien = VTT |nocat = {{{nocat|}}}

Voilà, voilà .

Cordialement, Ferro~frwiki (discuter) 28 juin 2023 à 15:30 (CEST)

Rien n'a changé, on reste donc avec le problème ? Ferro~frwiki (discuter) 1 juillet 2023 à 16:03 (CEST)

Conversion du tableau en div

Je propose une nouvelle version qui remplace le tableau par des div que l'on peut trouver dans la version bac à sable. J'ai deux motivations pour ce changement : être plus sémantique (il est préférable d'éviter les tableaux HTML pour de la mise en page) et empêcher un bug où l'affichage de la BU est changée qui peut arriver lorsque la BU est mise incorrectement dans une autre tableau en wikicode. Les changements sont ici : Spécial:Diff/197862472/206358480. Quelques notes : j'ai pu factoriser l'ancien table et le div englobant ; les display: table; et display: table-cell; permettent de conserver la mise en page existante ; j'ai du rajouter padding: 1px; sur le div de l'image pour reprendre le style par défaut de Firefox qui s'applique aux td mais pas aux div ; j'ai du rajouter border-collapse: separate; sur le div extérieur pour annuler un style de la version mobile qui empêchait l'arrondi et j'ai factorisé quelques propriétés margin/padding en une seule. mat.duf (discuter) 26 juillet 2023 à 05:26 (CEST)

Bonjour Mat.duf,

J'avais fait quelques essais à une époque sur mon brouillon, car je penses la même chose que toi : ce modèle devrait utiliser des div. De mémoire, j'étais parvenu à une équivalence totale avec le modèle actuel ici. Je ne l'ai pas déployé en raison du nombre d'utilisations important, j'avais peur de passer à côté de quelque chose. Je vais jeter un oeil à ta version, et comparer avec la mienne pour voir si on est raccord.

Wikipédiennement, Epok__ (✉), le 26 juillet 2023 à 11:08 (CEST)

En fait, je vois qu'il y a encore des tableaux qui traînaient dans ma version... Je dois mal me souvenir (c'était en 2019...). Ta version semble plus propre. Epok__ (✉), le 26 juillet 2023 à 11:12 (CEST)

EDIT : Ah, j'ai retrouvé les tests que j'avais conduit. En fait, ils concernaient {{BUdébut}}, {{BUséparateur}} et {{BUfin}}, et non {{BUtilisateur}}. Ils étaient ici. On pourrait en profiter pour mettre ces modèles à jour à base de div aussi. Epok__ (✉), le 26 juillet 2023 à 12:05 (CEST)

Après relecture du diff que tu proposes, je pense que c'est OK. Considérant que ce modèle est très répandu (certes pas dans l'espace encyclopédique, mais il ne faudrait pas non plus casser des PU qui n'ont rien demandé), je pense qu'il serait bon que d'autres experts modèle donnent leur avis (si ils le souhaitent) avant déploiement : je pense notamment à FDo64 et Ideawipik.

Epok__ (✉), le 26 juillet 2023 à 11:21 (CEST)

Bonjour Mat.duf et Epok . J'ai regardé la page de test et j'ai juste vu un souci avec l'option arrondi : les coins gauches haut et bas ne s'affichent pas chez moi. il y a des trous...

--FDo64 (discuter) 26 juillet 2023 à 18:07 (CEST)

Hello FDo64, et merci pour ton retour.

Chez moi (Linux, Firefox), tout semble s'afficher correctement. Quel navigateur utilises-tu ?

Il s'agit des coins côté image, c'est ça ? Peut-être un problème d'ordre dans lequel les cadres sont superposés ?

Je notifie également Od1n, qui masterise le CSS, si il souhaite y jeter un œil.

Note pour simplifier l'accès : page de test.

Wikipédiennement, Epok__ (✉), le 27 juillet 2023 à 09:15 (CEST)

Bonjour Epok

C'est bien ça. Même résultat avec Chrome (connecté) et Edge (non connecté) sous Windows 10.

--FDo64 (discuter) 27 juillet 2023 à 16:18 (CEST)

Bonsoir .

Je peux tester sur Chrome-Win10, Opéra-Win10, Edge-Win10, mêmes résultats (problèmes d'arrondis à gauche de l'image).

Sur Firefox-Win10 là par contre c'est bon. Le navigateur doit être en avance sur les autres, faut regarder la compatibilité du code sur le site W3C, normalement ils tiennent ces listes à jour.

Cordialement, Ferro~frwiki (discuter) 28 juillet 2023 à 02:58 (CEST)

Bonjour FDo64 et Ferro~frwiki , j'ai remis le paramètre CSS qui je pense devrait corriger le problème d'arrondi sur les navigateurs basés sur Chromium. Il faudra pas contre probablement vérifier aussi sur Safari qui pourrait avoir un problème similaire.

J'en profite, à partir de ce week-end je serais absent pour environ 3 semaines et même si je sais que rien ne presse, si quelqu'un veut continuer (et compléter) le sujet sans moi, n'hésitez pas. mat.duf (discuter) 28 juillet 2023 à 03:54 (CEST)

Plus aucun souci en ce qui me concerne. Merci. --FDo64 (discuter) 28 juillet 2023 à 11:10 (CEST)

Idem, plus de soucis pour Firefox-Win10, Chrome-Win10, Opéra-Win10 et Edge-Win10.

Je ne peux pas tester Safari.

Cordialement, Ferro~frwiki (discuter) 28 juillet 2023 à 16:11 (CEST)

Avis aux participants de la discussion : mat.duf, FDo64 et Ferro~frwiki .

Voyez-vous encore des corrections/améliorations à faire, ou bien peut-on passer le modèle en production ?

Wikipédiennement, Epok__ (✉), le 1 octobre 2023 à 10:01 (CEST)

P.S. : dans la foulée, je propose de passer les modèles englobants ({{BUdébut}}, {{BUséparateur}} et {{BUfin}}) en div aussi : voir Modèle:BUdébut/Test. Epok__ (✉), le 1 octobre 2023 à 10:31 (CEST)

Bon, plus de 6 mois sans opposition, on va considérer que c'est une approbation (nonnon, j'avais pas oublié du tout ). Je passe le bac à sable en production.

J'essaierai de m'occuper des autres modèles mentionnés à court (tout est relatif) terme.

Epok__ (✉), le 11 avril 2024 à 17:47 (CEST)