Discussion Projet:Modèle

Le salon des modélistes

Le salon des modélistes? Demande/amélioration de modèle Demande/amélioration d’Infobox Demande/amélioration de boîte utilisateur Raccourci [+] P:MQ Questions générales. On discute du projet modèle. Afin de vous assurer que vous faites votre demande au bon endroit, veuillez consulter l’encadré ci-dessous, et déterminer si vous postez au bon endroit. Le salon des modélistes concerne principalement les discussions à propos du projet, mais aussi les questions générales portant sur les modèles si les différentes rubriques d’aide n’y répondent pas. Toute demande qui aurait dû être faite dans l’une des pages mentionnées ci-dessous n’est pas faite au bon endroit, elle pourrait être ignorée. Cette page n’est pas la bonne… … si vous souhaitez modifier ou demander un nouveau modèle → Demande de modèle … si vous souhaitez faire la demande d’une Infobox → Demande d’Infobox … si vous souhaitez faire la demande d’une boîte utilisateur → Demande de boîte utilisateur Question aux modélistes Archives : 2006 • 2007 • 2008 • 2009 • 2010 Avenue des Cafés et Bistros

Modèles de documentation

Bonjour, je pense qu'il serait bien de faire du ménage dans les modèles de documentation. En effet il y a : {{Documentation modèle compliqué en sous-page}} {{Documentation modèle en sous-page}} {{Doc modèle}} {{Documentation attendue}} {{Documentation modèle}} {{Documentation modèle compliqué}} {{Documentation}} {{Info modèle}} {{Modèle utilisant les ParserFunctions}} {{Documentation modèle utilisant les ParserFunctions en sous-page}} {{documentation modèle vue directement}}... Il faudrait unifier toute cette série de modèle. C'est pourquoi je propose de simplifier cette série. On pourrait utiliser :

• {{Documentation modèle en sous-page}} avec le paramètre pour les parsers fonctions et l'aide à la création contenue dans {{Doc modèle}}. Il regroupe : {{Documentation modèle compliqué en sous-page}} {{Documentation modèle en sous-page}} {{Doc modèle}} {{Documentation attendue}} {{Documentation}} {{Info modèle}} {{Documentation modèle utilisant les ParserFunctions en sous-page}}.
• {{documentation modèle vue directement}} pour les sous-pages elles-mêmes.
• {{Documentation modèle en sous-page}} avec le paramètre pour les parsers fonctions pour les pages comportant elles mêmes la doc. Il regroupe : {{Documentation modèle}} {{Documentation modèle compliqué}} {{Modèle utilisant les ParserFunctions}}.

Avec 3 modèles, on regrouperait sans problèmes les 11 existants. Tpt (d) 16 décembre 2009 à 15:01 (CET)

Très franchement, un modèle unique (sans en faire un modèle à coulisse usine à gaz) serait suffisant, en fait. La documentation d'un modèle est rédigée dans une sous-page. On ne publie pas un modèle non documenté (étape simple d'une gestion qualité des modèles). On oublie tout ce qui concerne les parsers-functions et ses avertissements ignorés au profit d'une distinction opérationnelle entre modèle de contenu (une instance de meta palette de navigation, par exemple) et modèle de code (la meta-palette). Et on prend le temps d'un grand ménage.

L'idée suivante serait de différencier deux espaces, l'un pour les modèles et l'autre pour les pseudos-modèles de contenu. Mais chaque chose en son temps. --Temesis (d) 16 décembre 2009 à 15:48 (CET)

Attention, la création d'une sous page de modèle automatique peut être parfois lourde à gérer pour des modèles simples comme un lien externes ou de la typographie -- Xfigpower (pssst) 16 décembre 2009 à 17:15 (CET)

Je pense aussi, c'est pourquoi un modèle pour les modèles sans sous-page est à conserver. La duplication de l'espace modèle est une idée à creuser. Tpt (d) 16 décembre 2009 à 17:49 (CET)

J'appuie Xfigpower (d · c · b) pour conserver la possibilité d'inscrire la documentation d'un modèle simple en page principale. Lors de la fusion, je crois qu'on devrait en profiter pour annuler la création, par certain de ces modèles, de l'inutile encadré vert. Si on veut que la page des modèles soient vertes mettons le dans une page Mediawiki (ce qui n'est pas mon opinion.). — Riba ^(discuter) 4 janvier 2010 à 17:45 (CET)

Modèle:Ouvrage

Comment faire pour indiquer qu'un ouvrage est bilingue, en indiquant ses deux langues ? J'ai posé la question là et la re-pose ici, c'est peut-être plus animé ---- El Caro ^bla 17 août 2010 à 16:05 (CEST)

Modèle:MathSciNet

Bonjour, j'ai fait importer par Darkoneko (d · c · b) le modèle ci-dessus, dont j'avais besoin dans une de mes traductions. Hélas, il semble que bien qu'il marche bien sur (en), la version française soit buguée. Elle fait appelle au modèle:= pour introduire une url du genre http://www.ams.org/mathscinet-getitem?mr=xxxxx. Je voulais savoir comment faire pour corriger le modèle ... Et qu'il devienne fonctionnel. Il semble que le modèle = ne soit pas fonctionnel une fois inclus dans d'autres modèles (cf. ces exemples en direct [[Modèle:{{{1}}}|{{{{{1}}}}}]] ou [[Modèle:=|{{=}}]]). Merci d'avance Grimlock 17 août 2010 à 22:14 (CEST)

Sondage sur la forme des liens hypertextes dans le modèle Article

Wikipédia:Sondage/Forme des liens hypertextes dans le modèle Article jusqu'au 11 septembre 2010. Teofilo ◯ 27 août 2010 à 13:15 (CEST)

Le sondage est terminée. Demande d'aide pour modifier le modèle déplacée sur Projet:Modèle/Demandes#Mise à jour du Modèle:Article. Teofilo ◯ 12 septembre 2010 à 16:25 (CEST)

Modèle:Max

Bonjour, pour le Modèle:Max, Il y a un bug qui pose problème. Lorsque l'on écrit ceci :

{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|1|2}}|3}}|4}}|5}}|6}}|7}}|8}}|9}}|10}}|11}}|12}}|13}}|14}}

tout fonctionne. Par contre si l'on compare au delà de 14 nombres alors un message en rouge s'affiche et qui dit : « Erreur d’expression : opérateur < inattendu », comme par exemple avec le script suivant :

{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|{{max|1|2}}|3}}|4}}|5}}|6}}|7}}|8}}|9}}|10}}|11}}|12}}|13}}|14}}|15}}

Quelqu'un ici saurait résoudre ce problème pour pouvoir comparer une 40 ène de nombre. amicalement--Wikialine (d) 16 septembre 2010 à 17:15 (CEST)

Je ne vois pas l'intérêt du #expr dans la source du modèle... Et en le retirant, on passe de 13 à 19 comparaisons possibles. Faudra discuter de ça avec d'autres modélistes. Amicalement, od†n ^{[dead words]} 21 octobre 2010 à 23:34 (CEST)

Déjà répondu à la question sur la guilde il y a quelques temps. On peut passer le nombre de récursions en log. — Arkanosis ^✉ 22 octobre 2010 à 04:45 (CEST)

Lien vers le message auquel mon parrain fait allusion : Wikipédia:Questions techniques/semaine 37 2010#Modèle:Max od†n ^{[dead words]} 22 octobre 2010 à 06:13 (CEST)

Merci, ce n'était pas facile sur un téléphone mobile — Arkanosis ^✉ 22 octobre 2010 à 14:48 (CEST)

Il n'en demeure pas moins que le modèle aurait peut-être besoin d'être modifié. Il y a déjà cette question de l'utilité du #expr. D'autre part, ce modèle étant inclus dans d'autres modèles, on pourrait lui ajouter le support d'un seul paramètre (retourne ce paramètre) et même de zéro paramètre (retourne rien). Enfin, je vois que la version anglaise encadre les valeurs à comparer avec des parenthèses, je me demande si cela sert à quelque chose ? Cdlt, od†n ^{[dead words]} 24 octobre 2010 à 18:15 (CEST)

Le #expr est là pour que {{max|2+1|2}} te donne « 3 » et non « 2 + 1 » .

C'est vrai qu'il me paraitrait plus logique de découpler l'évaluation de l'expression de la recherche du maximum (il faudrait faire max(expr(x, y)) en gros… mais le modèle est utilisé partout donc c'est trop tard pour changer les specs.

On devrait effectivement mettre des parenthèses comme nos collègues anglophones, afin que {{max|2>1|1>2}} renvoie 1 et non 0 comme c'est le cas actuellement.

Pour le support de 0, 1 (et 3, 4…) paramètres, pourquoi pas, c'est une bonne idée… — Arkanosis ^✉ 25 octobre 2010 à 11:37 (CEST)

Supprimer certaines palettes : oui (ou non), mais lesquelles ?

Discussion modèle:Esclavage/Suppression a été close ; la demande de SI ; peut-être surtout la la requête aux admins concerne ce projet. Vous nous donnerez, j'espère, un avis éclairé. Bonne lecture ! Bourrichon 21 octobre 2010 à 18:23 (CEST)

{{Métadonnées personne}} et Wikipédia:Métadonnées personne

NEMOI, à 22 heures 21, le 23 octobre 2010. − Salutations à tous. Je suis assez circonspect devant ce modèle, et devant sa page d’explication. Est-ce bien utile que d’avoir un modèle presque inusité de ce type ? un recoupement n’est-il pas possible avec les infoboxes ? Qui de Chaoborus ou d’Hercule a raison ?..

Je dirais Chaoborus. Je pense que j'ai retiré la catégorisation uniquement parce qu'il aurait fallu utiliser le modèle --Hercule ^Discuter 26 octobre 2010 à 12:11 (CEST)

NEMOI, à 9 heures 59, le 27 octobre 2010. − La suite ici.

Remplacement des modèles obsolètes

Bonjour,
Je compte, avec Botsolète (d · c), remplacer les modèles obsolètes suivants :

• {{Elle}}, rendu obsolète par Xfigpower (d · c).
• {{Lle}}, rendu obsolète par Xfigpower (d · c).
• {{Me}}, rendu obsolète par Nemoi (d · c), qui a déjà demandé son avis au projet, mais n'a pas obtenu de réponse.
• {{Rs}}, rendu obsolète par MetalGearLiquid (d · c).
• {{R}}, rendu obsolète par MetalGearLiquid (d · c).
• {{Sommaire flottant}}, rendu obsolète par Lgd (d · c).
• {{Tablabonita}}/{{Prettytable}}, rendu obsolète par Amstramgrampikepikecolegram (d · c), qui est aussi l'auteur du modèle.
• {{Médaille d'or olympique}}, rendu obsolète par Orphée (d · c).
• {{Médaille d'argent olympique}}, rendu obsolète par Orphée (d · c).
• {{Médaille de bronze olympique}}, rendu obsolète par Orphée (d · c).
• {{Répondu}}, rendu obsolète par Kyro (d · c).

Est-ce que quelqu'un n'est pas d'accord ? -- Marin ^(!?) 25 octobre 2010 à 22:20

faut faire gaffe avec les civilité pour éviter de confondre P{{rs}} et D{{rs}}. Pour {{Me}}, ne remplacer que M{{me}} par {{Mme}} -- Xfigpower (pssst) 26 octobre 2010 à 12:01 (CEST)

J'ai tout prévu, pour ça . -- Marin ^(!?) 26 octobre 2010 à 12:44

{{Méta palette de navigation}}

Bonjour, le Common.css contient ce style :

table.navbox {
  ...
  margin: 1em 0 0;
  ...
}

Or celui-ci est écrasé, vu que le code de {{Méta palette de navigation}} contient :

<table class="navbox ..." style="margin:auto; {{#if:{{{style|}}}|{{{style}}};}} {{{stylecorps|}}}">

Je pense qu'il faudrait donc déplacer le style de {{Méta palette de navigation}} vers le Common.css (aussi, "margin: 0 auto;" serait préférable).

– od†n ^{[dead words]} 8 novembre 2010 à 14:54 (CET)

Bonjour,
A priori, oui. J'ai l'obscur souvenir d'un autre modèle utilisant cette classe et dont le rendu correct repose sur la marge verticale, mais c'est vraiment obscur et il s'agit sans doute d'un modèle peu utilisé. Quoi qu'il en soit, faire la modification permettra assez rapidement de l'identifier en suivant les hurlements qui retentiront alors... Cordialement, --Lgd (d) 8 novembre 2010 à 15:53 (CET)

À tout hasard, ce modèle obscur se trouverait-il dans Catégorie:Modèle déroulant voire dans Catégorie:Méta-modèle ? Mieux encore, dans ce résultat de recherche ? Hum... ne serait-ce pas {{Wikimag}} ? od†n ^{[dead words]} 8 novembre 2010 à 16:08 (CET)

Imposer à ses petits camarades, un lundi de semaine difficile et sans sploiler l'un des plus abominable détournement de modèles de l'histoire de WP, tu devrais avoir honte Ce n'était pas celui-là, mais la piste est bonne. Cordialement, --Lgd (d) 8 novembre 2010 à 16:32 (CET)

Quoiqu'il en soit, concernant ce {{Wikimag}} d'après ce que je vois il y aurait hum, 2-3 choses à arranger. od†n ^{[dead words]} 8 novembre 2010 à 16:44 (CET)

Ne le cassez pas non plus :p Otourly (d) 8 novembre 2010 à 18:21 (CET)

La classe "navbox" semble malheureusement être utilisée par de nombreux modèles en dehors des palettes de navigation, il me semble alors contre-indiqué de toucher à celle-ci...

– od†n ^{[dead words]} 11 novembre 2010 à 18:50 (CET)

Modèle:Coord et infoboxes

Bonjour, Est-ce que les modèlistes pourraient faire une solution miracle afin d'éviter l'utilisation triple du modèle coord dans certains articles à cause des infoboxes ? L'idéal serait de solutionner toutes les infoboxes qui géolocalisent. Il serait bien que l'infobox renvoie les coordonnées au dessus du titre, avant que le code OSM se fasse sur tout les articles géolocalisés. Merci de votre attention. Otourly (d) 8 novembre 2010 à 18:20 (CET)

Essayer de définir où (dans l'article) se situe l'intérêt de lire immédiatement la longitude et la latitude d'un lieu serait un premier pas. Ma conclusion à cet égard est un peu la même que la tienne: tout au plus à côté du titre (tout au plus, car elles n'ont pas besoin d'être affichées en fait, ce sont les liens vers les outils qui sont importants). --Lgd (d) 8 novembre 2010 à 18:30 (CET)

Les communes italiennes, je pense, car le modèle coord est à la fois compris dans l'infobox et dans un sous modèle pour tout les articles. Oui, c'est les outils qui sont importants, mais pour l'heure on ne sait pas encore comment les mettre ailleurs... Otourly (d) 9 novembre 2010 à 06:27 (CET)

Drapeaux

Bonjour, je vois que {{drapeau|États-Unis}} donne :

<span class="flagicon">[[Image:Flag of the United States.svg|20x18px|border|Drapeau des États-Unis]]</span>

tandis que {{USA-d}} donne :

[[Fichier:Flag of the United States.svg|20px|border|États-Unis]]

N'y aurait-il pas une uniformisation à faire à ce sujet ? Cordialement, od†n ^{[dead words]} 11 novembre 2010 à 18:47 (CET)

Moui. Je crois que la class flagicon ne sert à rien parce qu'il n'y a pas de propriété css associé.

Le fait par contre de spécifier 20x18 est bénéfique pour les drapeaux de ratio exotiques (les plus haut que large). Par exemple, en fixant seulement une dimension, cohabitent  ; avec 18 en hauteur, . Par contre, il me semblait qu'on devait utiliser une syntaxe comme 999999x18px pour bien figer une hauteur uniforme (on en avait eu besoin pour Galerie des drapeaux des pays du monde).

Quand à la différence entre les légendes, c'est géré dans un cas spécifiquement par l'attribut alt attribute des Modèle Country data.--Xfigpower (pssst) 14 novembre 2010 à 16:12 (CET)

Bonjour,

• Il serait préférable de conserver et même de systématiser la classe flagicon : elle permet d'identifier spécifiquement les drapeaux à des fins de traitement côté front. Par exemple, le gadget accessibilité pourrait s'en servir pour décliner un test plus adapté pour les drapeaux.
• Pour les alt, la version « Drapeau de... » est préférable : elle permet de dissiper l'ambiguïté sur la cible du lien, qui sinon pourrait être aussi bien par exemple l'article France que la page de l'image Fichier:Flag_of_France.svg (un cas-type de ce problème, le modèle {{FR}} qui produit  France c'est à dire grosso modo France France).

Idéalement, ces drapeaux ne devraient pas être des liens (paramètre link vide), mais cela poserait un trop gros problème d'accès aux auteurs et à la licence (j'avais envisagé ceci dans les crédits graphiques, mais ça ne passera pas).

Cordialement, --Lgd (d) 22 novembre 2010 à 06:35 (CET)

OK, on pourrait progressivement harmoniser vers les directions que tu as données. Sinon pour les crédits des drapeaux, tu es sûr que ça ne passerait pas ? C'est dans le domaine public... od†n ^{[dead words]} 22 novembre 2010 à 07:41 (CET)

Pour le domaine public, ce n'est hélas pas systématique. En outre, il faut bien avouer aussi que le petit lien permet souvent de voir à quoi ressemble en vrai un drapeau peu connu, qui est à peine déchiffrable sous forme d'icône . Cordialement, --Lgd (d) 22 novembre 2010 à 08:17 (CET)

Oui, il m'est effectivement déjà arrivé de cliquer sur un drapeau pour le voir plus en détail. petit à propos : je viens d'aller sur Discussion modèle:Drapeau, apparemment le sujet de la gestion des drapeaux est matière à moulte réflexions  – od†n ^{[dead words]} 22 novembre 2010 à 08:44 (CET)

modèle:infobox Col

Bonjour. Il y a un petit problème avec cette infobox, que j'ai reporté sur sa PDD. Merci d'avance pour tout avis là-dessus. Cordialement, Freewol (d) 18 novembre 2010 à 13:47 (CET)

Problème résolu par Nemoi plus vite que son ombre, merci à lui . Freewol (d) 18 novembre 2010 à 13:57 (CET)

Uniformisation des modèles IMDb

Bonjour, les modèles IMDb, que sont {{Imdb titre}}, {{Imdb nom}}, {{Imdb récompense}}, {{Imdb personnage}} et {{Imdb entreprise}}, auraient besoin d'un petit coup d'uniformisation. Plus précisément en ce qui concerne les indications de langue.

Constatez par vous-mêmes la disparité des modèles :

• Chapeau melon et bottes de cuir sur l’Internet Movie Database - Version plus complète en anglais
• Alfred Hitchcock sur l’Internet Movie Database - Version plus complète en anglais ← notez aussi le point qui serait à supprimer
• Récompenses pour Chapeau melon et bottes de cuir sur l’Internet Movie Database - Version plus complète en anglais
• Chewbacca sur l’Internet Movie Database - Version plus complète en anglais
• Lucasfilms sur l’Internet Movie Database - Version plus complète en anglais

Il faudrait se mettre d'accord sur le format à utiliser, je propose ceci :

• (fr) Chapeau melon et bottes de cuir sur l’Internet Movie Database  – (en) Version plus complète en anglais

Pour ma part effectivement, je trouve que les indicateurs de type "fr+en" ne sont pas terribles :

• Quand il y a d'autres liens dans la liste à puce, avec zéro ou un indicateur de langue, l'indention disparate fait que la liste est assez moche.
• C'est fort confus. Faire "un indicateur, un lien." c'est bien plus clair.

Cordialement, od†n ^{[dead words]} 19 novembre 2010 à 22:35 (CET)

Je plussoie l'idée globale. Cordialement, --Lgd (d) 20 novembre 2010 à 08:52 (CET)

Il me semble que le mélange fr+en était dû au fait que le site mélangeait un peu les deux. Maintenant ce n'est plus que du français. Donc j'approuve une reprise des icônes de langues.

Par contre, (fr) est inutile quand la source est uniquement en français. On s'en sert pour indiquer par exemple qu'un site est en français et en espagnol ((fr) (es)).

Pour l'anglais, l'icône est là pour informer de la langue du lien. Or le texte pour le site en anglais est déjà explicite sur la langue. Pour moi le lien devrait être :

• Chapeau melon et bottes de cuir sur l’Internet Movie Database  – Version plus complète en anglais

Cordialement,

--Hercule ^Discuter 20 novembre 2010 à 16:32 (CET)

• Cette observation est pertinente. Néanmoins, comme je le vois pour l'instant, il faut peut-être mettre plus en évidence le fait qu'il y a un lien en anglais, a fortiori vu qu'il se trouve sur la même ligne que des liens français... Mais la remarque est intéressante, en plus cela permettrait de raccourcir un peu ces liens IMDb qui doivent être indigestes pour certains, en l'état...
• On pourrait éventuellement permettre l'affichage ou non des indicateurs ? avec un paramètre optionnel langues=oui/non, et évidemment il faudrait que l'on décide de l'option à appliquer par défaut. Mais peut-être que c'est une très mauvaise idée que j'ai là, ça charge les rédacteurs avec des choix de configuration supplémentaires à faire, et évidemment l'homogénéisation des liens en prendrait un coup !
• Enfin, autre idée, par contre celle-ci me semble très bonne : pour la maintenance de ces modèles, je me dis qu'on pourrait faire un méta-modèle pour les liens IMDb ?

Cordialement, od†n ^{[dead words]} 20 novembre 2010 à 18:18 (CET)

Je plussoie fortement la proposition plus radicale d'Hercule, la tendance est en effet à la disparition de ces modèles d'indication de langue quand le contexte est suffisant (sinon, non : pas de paramètre optionnel langues=oui/non). --Lgd (d) 20 novembre 2010 à 18:32 (CET)

On arriverait donc à quelque chose comme cela :

• (en) Site Web officiel
• Chapeau melon et bottes de cuir sur l’Internet Movie Database  – Version plus complète en anglais
• Chapeau melon et bottes de cuir sur AlloCiné

Mmmm, moui... c'est pas trop mal ! À moins que quelqu'un ait des améliorations à apporter ? od†n ^{[dead words]} 20 novembre 2010 à 18:55 (CET)

PS : et votre avis sur l'implémentation d'un méta-modèle ?

Je ne suis non plus pour le paramètre langues.

Pour le méta-modèle, ma première impression était que c'est une bonne idée, mais en réfléchissant un peu plus je pense que cela alourdit la gestion de ces modèles pour pas grand chose (il n'y a que 5 modèles)

--Hercule ^Discuter 20 novembre 2010 à 21:44 (CET)

OK pour l'abandon de l'idée du méta-modèle, effectivement mieux vaut encore faire 5 copier-collers que de rajouter une couche de code supplémentaire. La proposition actuelle, avec les menus détails comme les 2 espaces avant le tiret, ce genre de chose, tout est OK pour vous ? Pour qu'on puisse passer ça en production od†n ^{[dead words]} 21 novembre 2010 à 03:00 (CET)

C'est Ok pour moi. Je pense que tu devrais laisser un mot au projet Cinéma avant d'appliquer la modification. Ils ont peut-être leur grain de sel à ajouter sur ce modèle qui les concerne directement.

--Hercule ^Discuter 21 novembre 2010 à 03:08 (CET)

Bien vu, j'ai réparé cet oubli ici od†n ^{[dead words]} 21 novembre 2010 à 04:39 (CET)

Très bien pour moi, bonne idée. Octave.H ^hello 21 novembre 2010 à 10:19 (CET)

Contre ! L'indication de la langue me paraît très importante. Peut-être même qu'elle améliore l’accessibilité (je n'en suis pas tout à fait sûr, mais quand même). Cela est très important pour le lecteur qui ne parle pas anglais ! — Steƒ ^๏̯͡๏ 21 novembre 2010 à 12:07 (CET)

Je suis d'accord avec Stef. Je pense que l'indication de langue permet à l'utilisateur de repérer de suite dans les liens externes ceux qui sont en français et ceux qui sont en anglais. Je trouve aussi que c'est plus harmonieux si le reste de la liste des liens externes à des indications de langues. Je suis pour l'uniformisation des modèles sur le modèle proposé

• (fr) Chapeau melon et bottes de cuir sur l’Internet Movie Database  – (en) Version plus complète en anglais

--Crazy runner (d) 21 novembre 2010 à 12:18 (CET)

Je suis d'accord avec cette proposition — Steƒ ^๏̯͡๏ 21 novembre 2010 à 12:44 (CET)

La question de l'indication de la langue n'a rien de spécifique à ces modèles. Je ne connais pas l'endroit où l'on peut trouver la recommandation sur ces modèles, mais je suis quasiment certain que cette vision est celle majoritairement admise et pratiquée. Donc pour l'utilisation de (fr) c'est clairement à proscrire. Si sur un article l'utilisation de (fr) se justifie, alors il suffit de l'ajouter devant l'appel au modèle.

Reste l'utilisation de (en), qui est plus du domaine de l'opinion personnelle. Si vous tenez absolument à le garder je n'en ferais pas une maladie, mais il me semble que le texte du lien (« Version plus complète en anglais ») est suffisamment explicite pour que l'on puisse se passer d'un petit modèle.

Si par accessibilité vous entendez une meilleure interprétation du code par des outils spécifiques (genre pour les malvoyants), je ne crois pas que ces modèles aient une quelconque utilité sur ce point. Mais je peux me tromper.

--Hercule ^Discuter 21 novembre 2010 à 16:10 (CET)

Il me semble que cette recommandation corrobore ce que j'avance sur l'utilisation de (fr). Le fait que l'on recommande, dans le cas d'un lien en une autre langue que le français (« Il est alors vivement recommandé ») implique que si c'est en français il n'est pas demandé (même si pas interdit) d'indiquer (fr). D'ailleurs des modèles comme {{Ouvrage}} ou {{Article}} n'affichent l'icône de langue que si ce n'est pas du français.

--Hercule ^Discuter 21 novembre 2010 à 16:20 (CET)

Pour commencer une petite mise au point, dans cette discussion il ne s'agit aucunement d'accessibilité, mais simplement d'ergonomie et de charte du contenu.

J'ai proposé la version avec les 2 indicateurs, mais j'ai été plus que convaincu par la nouvelle version proposée sans les indicateurs :

• Je trouve que cela rend le lien bien moins indigeste. (et ça, ça va faire plaisir à beaucoup de personnes)
• Je trouve aussi que cela permet une intégration bien plus harmonieuse dans une liste avec d'autres liens externes. (voir exemple au dessus)
• Enfin, je me suis très vite rendu compte que la version sans indicateurs est tout à fait claire et compréhensible. C'est un grand classique, on n'arrive pas à se décrotter de nos petites habitudes... Quittez l'écran, buvez un petit café, oubliez le modèle avec les indicateurs ; revenez, regardez la version sans indicateurs, vous verrez qu'elle est de toute beauté et que sa compréhension est tout aussi rapide !

Bon après, si un consensus clair ne se dégage pas, on peut toujours utiliser la version avec les 2 indicateurs séparés, ça sera déjà légèrement mieux que les modèles actuels, mais ça serait vraiment dommage de ne pas faire cette modif...

Cordialement, od†n ^{[dead words]} 21 novembre 2010 à 17:05 (CET)

« cela permet une intégration bien plus harmonieuse dans une liste avec d'autres liens externes » Très juste. Octave.H ^hello 21 novembre 2010 à 17:29 (CET)

Juste une confirmation rapide: la présence ou l'absence des (en) et autres n'a aucune incidence sur l'accessibilité. Cordialement, --Lgd (d) 21 novembre 2010 à 17:39 (CET)

Je ne suis toujours pas convaincu. Je suis d'accord que la phrase seule est très claire et ne nécessite pas de balisage. Je préfère l'imaginer dans une liste de liens externes et là, je ne suis vraiment pas convaincu.

0) J'ai quitté l'écran par contre je n'aime pas le café.

1) Je préfère les balises, je m'y retrouve plus vite. (question de point de vue)

2) Si on prend Clint Eastwood, si vous supprimez les balises langues dans les liens externes IMDB, je suis à peu près certain qu'un utilisateur positionnera un petit fr pour aligner avec le reste.

3) Lors d'une création ou ébauche, le plus souvent, le lien IMDB est le premier lien dans les liens externes. Pour les films, acteurs, blabla non français, si les balises sont mises pour ce lien externe, je pense que cela motive les utilisateurs pour les positionner dans les autres et permet une meilleure accessibilité.

Cordialement.--Crazy runner (d) 22 novembre 2010 à 10:31 (CET)

0) Cela marche aussi avec le thé. Un longjing impérial, ça vous convient ?

1, 2, 3) Je me suis penché à nouveau sur les différentes solutions possibles, et je pense qu'il n'y a pas de solution absolument meilleure que les autres sur tous les points, qui puisse satisfaire vraiment tout le monde. Comme l'idée de départ était simplement de réaliser une petite uniformisation nécessaire des modèles, je propose de s'en tenir à la version avec indicateurs, du moins dans un premier temps. Au moins on aura déjà la disparition des (fr+en) (fr/en) ! (pour rappel, avant les pages IMDb mélangeaient allégrement français et anglais, mais aujourd'hui ce n'est plus le cas) Pour ce qui est de la suppression totale des indicateurs, on pourra toujours revenir là-dessus plus tard, pourquoi pas avec un joli sondage, étayé d'exemples, etc.

– Cordialement, od†n ^{[dead words]} 22 novembre 2010 à 18:02 (CET)

Heu non, ne pas lâcher le morceau (je vais un peu sembler agresser Crazy runner dans la forme, mais ce n'est absolument pas le cas sur le fond).

1. Pour ce qui est des contributeurs qui, voyant l'absence de (fr), les remettraient : regardez du côté du projet:Communes de France qui, à sa manière certes parfois assez abrupte, a adopté depuis plusieurs mois la suppression des (fr) devant les liens dont la cible est en français, et qui ne rencontre pas de difficultés notables à cet égard. Il n'est en fait pas le seul : je n'ai pas les liens sous la main, là, mais la tendance générale est à la suppression de ces modèles quand le contexte est suffisant.
2. S'il faut vraiment motiver les contributeurs pour quelque-chose, ce sera pour rédiger leurs libellés de lien de manière explicite (un lien vers un site en français a un libellé en français, un lien vers une page en moldave a un libellé rédigé en moldave ou bien en français mais avec la mention « (en moldave) » dedans.
3. je défie solennellement quiconque trouve plus lisible les (zh) et autres (kl) de parvenir à démontrer que ce n'est pas juste, à son insu, un truc de contributeur habitué totalement indifférent malgré lui à ce qui compréhensible pour les gens

Et ne surtout jamais envisager un sondage ou pire une PDD en raison du point 3. Cordialement, --Lgd (d) 22 novembre 2010 à 18:26 (CET)

Juste une question en quoi ce que fait le projet:Communes de France est-il un bon exemple pour cette discussion ? La plupart de leurs liens externes sont français. Jusqu'à preuve du contraire, il y a plus de films et d'acteurs non francophones. Donc la liste des liens externes pour les pages du projet cinéma contient des liens vers des pages non francophone et la tendance me semble d'avoir des balises de langues sur ces pages. Je pense donc que mes points deux et trois sont tout à fait justifiés.

L'avantage de la balise, c'est que dès le début du lien, on s'est à quoi s'attendre. Je pense que les francophones ont l'habitude de lire de gauche à droite. Je n'ai pas spécialement envie de commencer ma lecture de liens externes par la droite pour voir lesquels sont écrits en français. Maintenant si des gens ont du mal à comprendre la balise, il suffit juste de passer le curseur dessus et la langue s'affiche. Bonne soirée.--Crazy runner (d) 22 novembre 2010 à 19:03 (CET)

Dans Clint_Eastwood#Liens_externes je ne vois pas pour quelle raison il faut absolument mettre l'indicateur de langue. Ce lien est pleinement justifié quand il y a pléthore de liens en langue étrangère et quelques un en français. Et quand c'est nécessaire il suffit d'écrire {{fr}} {{Imdb...

Je ne comprends vraiment pas l'intérêt de mettre l'indicateur partout parce qu'il existe des exceptions où il se justifie. Je trouve très pertinent le point 3 de Lgd.

--Hercule ^Discuter 22 novembre 2010 à 23:12 (CET)

Heureusement que le but de départ était l'harmonisation… Là, si chacun met l'indicateur quand il lui semble bien de le mettre, alors, on part du tout et du n’importe quoi. Par ailleurs, je trouve dommage que cette discussion se fasse ici et non pas sur le projet cinéma. Je sais quelqu'un les a averti, mais une réponse y a été donnée. Et personne du projet cinéma ne semble suivre celle-ci, alors que si elle avait été faite sur le projet cinéma… Bref. Quoiqu'il en soit, à chaque fois que j'écrivais un article je trouvais intéressant ces modèles {{en}}, etc. Ils permettaient rapidement et aisément de repérer quels sites étaient en français, en anglais, etc. Il existe des pages qui ont une petite dizaine de liens externes… Je ne trouve pas que ces modèles soient du luxe. S'il est question d'harmoniser, supprimer le {{fr}} mais laisser le (en) pour la version plus complète d'IMDb en anglais… ce n’est que mon avis quoiqu'il en soit. Sinon, on aurait pu faire pire en ajoutant un joli petit drapeau coloré par exemple pour les liens français ;) — Steƒ ^๏̯͡๏ 23 novembre 2010 à 07:21 (CET)

Un avis rapide (sans lire les débats car pas le temps) : je ne vois pas pourquoi on enlèverait les indications de langue pour ces modèles. Pourquoi gêneraient-ils dans ces modèles et pas ailleurs ? Je comprends que cela soit inutile de mentionner la langue lorsque le lien ou l'ouvrage cité est en français (j'ai d'ailleurs toujours trouvé inutile la mention (fr) seule). Mais lorsqu'un lien est dans une autre langue ou bilingue, il me semble nécessaire de le mentionner avec ces modèles de langue. D'ailleurs, soyons raisonnables : est-ce que cela mérite vraiment un débat si long ? Si untel trouve ces modèles inutiles, en quoi cela le gêne-t-il foncièrement et pourquoi voudrait-il leur suppression dès lors que d'autres en ressentent le besoin ? Franchement ! --TwøWiñgš ^{Boit d'bout} 24 novembre 2010 à 10:48 (CET)

Tu aurais dû lire les débats... La proposition de retirer les liens de langue est due au fait que le lien n'est justement plus bilingue ! --Hercule ^Discuter 17 décembre 2010 à 17:29 (CET)

Relance, allons-y pas à pas

Bonjour,

La proposition d'uniformisation initiale a manifestement été « tuée dans l'œuf » par les désaccords sur la suppression (ou non) des indicateurs de langue. Aussi, je propose que l'on avance pas à pas, en réglant dans un premier temps la partie du problème qui est — du moins me semble-t-il — assez consensuelle : l'uniformisation.

La question des indicateurs de langue qui, à mon humble avis, a une portée beaucoup plus large que les cinq modèles dont il est question ici pourrait se régler dans un second temps, en faisant éventuellement intervenir plus de participants puisqu'il ne s'agit plus à proprement parler d'une problématique liée uniquement aux modèles.

tl;dr On suit la première proposition d'Od1n et on discute du reste après ?

Amicalement — Arkanosis ^✉ 17 décembre 2010 à 17:23 (CET)

Ou on supprime les liens de langue, et on vois dans quelques temps s'il faut les remettre. --Hercule ^Discuter 17 décembre 2010 à 17:29 (CET)

OK pour l'uniformisation, tout le monde semble d'accord sur ce point. Les projets liés au cinéma, à la télévision, les jeux vidéo utilisent ces modèles. Plus tout les projets portant sur des personnages de fiction qui apparaissent dans des films, séries TV, ... Cordialement--Crazy runner (d) 17 décembre 2010 à 17:35 (CET)

Je précise uniformisation sur ce modèle

• (fr) Chapeau melon et bottes de cuir sur l’Internet Movie Database  – (en) Version plus complète en anglais

--Crazy runner (d) 17 décembre 2010 à 18:48 (CET)

Ben oui, mais c'est cette proposition là qui fait se hérisser les poils de certains, non ?

Le problème c'est que si on conditionne l'uniformisation à la suppression des indicateurs, il n'y a pas consensus et l'état actuel (non uniformisé) perdure. Le dernier message avant le mien date d'il y a plus de trois semaines — alors que 5 mn suffiraient à uniformiser les modèles. — Arkanosis ^✉ 17 décembre 2010 à 17:45 (CET)

Ceux qui ne sont pas chaud pour la suppression des indicateurs (plus que contre, selon ma lecture) le sont parce qu'ils croient qu'ils sont indispensables. Je suis sûr que si on supprimer ces indicateurs, et que l'on se donne un mois pour juger de l'effet, personne ne viendra demander leur retour.

Si on uniformise en mettant (fr), je suis certain qu'ensuite il sera impossible de retoucher aux modèles.

A quoi servent ces modèles ?

à faire joli ? non

à informer le lecteur sur la langue du lien ? oui. Sauf que le texte du lien en anglais est hyper explicite

faut-il mettre (fr) devant un lien en français ? non, sauf exception, notamment quand il est noyé dans des liens avec l'indicateur de langue. Le mettre par défaut est une hérésie.

Je confirme ma proposition : uniformisons en retirant les indicateurs de langue, et voyons dans 1 mois s'il convient de les remettre.

--Hercule ^Discuter 17 décembre 2010 à 18:05 (CET)

et comment comptez-vous voir s'il faut les remettre ? en suivant toute les pages une à une avec un bot pour voir si le modèle (fr) apparaît devant ?--Crazy runner (d) 17 décembre 2010 à 18:48 (CET)

Je pense toujours que le (fr) est utile lorsque l'on voit Internet Movie Database ça ne fait pas très français et version plus complète en anglais ne veut pas dire que la première est en français juste que la suivante est en anglais. Maintenant c'est mon opinion de mettre un (fr) lorsque je donne un nom de site en anglais.--Crazy runner (d) 17 décembre 2010 à 18:58 (CET)

Pire des cas prenez un film diffusé avec son titre original anglais en France, vous lisez le titre (en anglais) puis internet movie database puis version plus complète en anglais, vous pouvez penser que tout est en anglais si vous n'avez pas l'habitude. Cordialement--Crazy runner (d) 17 décembre 2010 à 19:02 (CET)

Je comprends tes craintes. Cependant je ne pense pas qu'en pratique l'absence du (fr) troublera grand monde.

Ma proposition, c'est de tenter de retirer le (fr), et de faire le point dans un mois, pour voir s'il faut le remettre. J'ai la conviction que si ce tag n'est pas là vous serez vite convaincu qu'en fait il n'est pas utile (sauf exception).

Comment voir s'il faut le remettre ? Tout simplement en se posant la question. Il n'y a pas vraiment de critère objectif pour mettre le (fr) systématiquement. C'est une histoire de goût, ou de supposition. Si après un mois la discussion revient pour le remettre, alors on remettra, puisque ce retrait est une expérimentation.

Techniquement, lancer un bot pour détecter le code {{fr}} {{Imdb et le remplacer par {{Imdb ne présente aucune difficulté.

--Hercule ^Discuter 17 décembre 2010 à 22:16 (CET)

Ce qui me gêne le plus dans cette proposition (je rappelle que pour ma part, je trouve que les deux propositions seraient acceptables, il n'y en a pas une qui soit totalement meilleure que l'autre), c'est que si un contrib rajoute le {{fr}} devant le lien, alors on aura un indicateur devant le lien Fr et pas d'indicateur devant le lien En, ce que je pense être la pire solution possible car l'emphase est trop marquée sur l'un des liens, en l'occurence le Fr. Donc c'est soit un indicateur devant chaque lien, soit aucun. Mon avis est de procéder sans plus tarder à l'uniformisation des modèles, simple opération de routine, tout ce que je souhaitais au départ. En plus, ça permettra déjà d'effectuer une modif quasi consensuelle, à savoir remplacer ces affreux « (fr/en) » par des indicateurs moins déroutants. Et pour ma part, je ne vois pas en quoi cela empêcherait, dans un second temps, de tenter de supprimer les-dits indicateurs. Au moins, on aurait déjà des modèles un minimum propres en attendant. od†n ^{[dead words]} 17 décembre 2010 à 22:29 (CET)

Est-ce que le modèle ne pourrait pas détecter les catégories films français, belge, québécois, acteurs français, etc personnage de fiction français, etc et ne pas mettre les balises dans ces cas ? Sur la plupart de ses pages, les modèles imdb vont être les seuls liens externes avec des balises, ça choque. Sur les pages sur des films étrangers, acteurs étrangers, personnages de fiction étrangers, les liens externes contiennent des balises de langues, rien que le site officiel et des sites sur les critiques sont le plus souvent dans la langue d'origine et les gens risquent de positionner le {{fr}} devant le lien imdb. De plus, certains titres ne sont pas traduits lors de la diffusion en France, cela aiderait d'avoir la balise de langue. Je pense que les modèles {{Ouvrage}} et {{Article}} n'utilisent pas de paramètre de langue française parce que dans les ouvrages français majoritairement les titres, éditeurs, auteurs vont être en français (pas de confusion). L'utilisation d'Internet Movie Database, les titres étrangers, le fait que l'on soit sur des pages où des balises de langues sont présentes va inciter les gens à en mettre. Est-ce que le modèle ne pourrait pas détecter les catégories films français, belge, québécois, acteurs français, etc personnage de fiction français, etc et ne pas mettre les balises dans ces cas ? (il restera tjs Internet Movie Database mais j'essaye d'aller vers un compromis)

Non, ce n'est pas possible techniquement. C'est pour cela que la bonne solution (à mon avis) est de ne pas mettre ces balises, et de laisser les contributeurs les ajouter devant le modèle quand c'est pertinent.

Je n'ai pas beaucoup insisté dessus, puisque je me focalise sur le (fr), mais la balise (en) est complètement inutile devant le lien menant vers le site en anglais, puisque le texte du lien hypertexte est hyper explicite sur la langue.

--Hercule ^Discuter 18 décembre 2010 à 23:19 (CET)

dommage --Crazy runner (d) 18 décembre 2010 à 23:48 (CET)

Ça serait bien de ne pas tourner en rond à nouveau. L'objet initial était une opération de maintenance élémentaire, qu'on s'en tienne à ça. od†n ^{[dead words]} 19 décembre 2010 à 01:45 (CET)

Est ce que ce sujet est suivi par quelqu'un ? — Mirgolth 4 janvier 2011 à 13:59 (CET)

Oui.--Crazy runner (d) 4 janvier 2011 à 14:22 (CET)

infobox monarque

L'infobox monarque a été déclarée "obsolète" (par qui je me le demande), est remplacée par infobox politicien. Le problème est que cette boîte là n'est pas adaptée et insère une ligne obligatoire "mandat". Qui pourrait nous débarasser de cette anomalie. Cordialement. — PurpleHz, le 21 novembre 2010 à 02:45 (CET)

Ça devrait être mieux maintenant ; j'ai répondu sur la page de discussion. Cordialement, od†n ^{[dead words]} 21 novembre 2010 à 04:04 (CET)

Modèle et lien interne

Bonjour, un lien interne contenant le modèle {{1re}} ne fonctionne pas (exemple). En expérimentant un peu :

• 1^re génération ne fonctionne pas ;
• 1^re génération fonctionne (en utilisant 1{{re}} et non {{1re}}) ;
• 1^re génération fonctionne aussi (en utilisant directement le modèle {{Abréviation discrète}}).

Auriez-vous des lumières sur le sujet ? Seudo (d) 23 novembre 2010 à 10:50 (CET)

La syntaxe actuelle de {{1ere}} est assez spécifique. Il faut voir avec Hercule, qui en est l'auteur, si elle peut être remplacée par la syntaxe plus simple {{Abréviation discrète|1{{exp|re}}|Première}} sans que cela ne provoque d'autres effets de bord. Cordialement, --Lgd (d) 23 novembre 2010 à 11:05 (CET)

Je me demande si le problème ne vient pas de l'ajout de la catégorie la nuit dernière. La page que j'ai citée apparaît correctement dans le cache de Google. J'ai créé un modèle de test sans la catégorie et il semble fonctionner : génération. Seudo (d) 23 novembre 2010 à 11:24 (CET)

Sgmbl, on ne voit jamais les choses les plus évidentes quand on les a sous les yeux . Le modèle {{1ere}} est réparé, merci d'avoir attiré l'attention sur la catégorie . Cordialement, --Lgd (d) 23 novembre 2010 à 11:29 (CET)

C'était peut-être aussi un problème de cache, puisque Hercule dit que ça fonctionne. Seudo (d) 23 novembre 2010 à 11:37 (CET)

Pour information, le modèle {{abréviation}} a depuis lors été renommé en {{abréviation discrète}} :

• {{abréviation}} crée désormais des abréviations soulignées
• il faut maintenant utiliser {{abréviation discrète}} pour créer des abréviations non soulignées

Cordialement, od†n ↗^blah 17 février 2011 à 02:58 (CET)

{{Infobox Musée}}

Bonjour, comment faire pour que le paramètre géolocalisation fasse apparaître en plus des coordonnées dans la box les coordonnées au niveau du titre (avec la carte OpenMapStreet aussi) ? Merci d'avance, Totodu74 (devesar…) 24 novembre 2010 à 14:08 (CET)

Beuh y'a quelqu'un ? Totodu74 (devesar…) 26 novembre 2010 à 15:57 (CET)

... Totodu74 (devesar…) 4 décembre 2010 à 15:11 (CET)

Sans être spécialiste, je dirai qu'en l'état, ce n'est pas possible. L'infobox en question est un « infobox avec des briques » lesquelles sont mutualisées sur différents infobox. {{Infobox/Ligne mixte latitude longitude optionnel}} est la ligne-brique gérant les coordonnées, c'est donc à priori là dedans qu'il faut modifier (rajout d'une clause « |display=inline,title » selon {{Coord}}). Mais comme dis, il faudrait que tous les infobox liés ait la même volonté. Like tears in rain ^{-_-} 4 décembre 2010 à 15:37 (CET)

Hum je vois à peu près la nature du problème, merci quand même ! (au besoin on peut rajouter un modèle en plus à la main...) Totodu74 (devesar…) 7 décembre 2010 à 23:50 (CET)

Et bien ya qu'à faire un second modèle non ? le temps d'uniformiser tout ça ? Otourly (d) 19 décembre 2010 à 11:04 (CET)

title=oui et maintenant c'est réglé -- Xfigpower (pssst) 27 janvier 2011 à 14:04 (CET)

Fusion de modèles de mise en colonnes

Bonjour, les modèles {{col-début}} et {{col-begin}} d'une part, {{col-fin}} et {{col-end}} d'autre part, sont très très proches. On pourrait envisager de les fusionner, les noms anglais devenant des redirections vers les noms français. Il faudrait étudier les différences entre les versions "anglaises" et "françaises". Je n'ai pas encore regardé, mais mon intuition me dit que les modèles "anglais" ont été importés du wiki... anglais, et que les modèles "français" sont des forks qui ont davantage évolué avec le temps. Cordialement, od†n ^{[dead words]} 20 décembre 2010 à 12:26 (CET)

Nouveau modèle à tester : arbres généalogiques et autres arbos (clagogrammes par exemple).

Bonjour,
Une chose en entraînant une autre, suite à cette discussion et à cette page de tests, j'ai enfin cessé de de procrastiner sur un vieux sujet qui est celui des différents modèles ou des techniques hors-modèles pour produire dans les articles une arborescence, typiquement un arbre généalogique (les bêbêtologues font aussi de leur côté des cladogrammes).

Bref, voici un modèle à tester en activant le gadget « Arborescences » dans vos Spécial:Préférences (section « Outils avancés » ; ce qui active la CSS nécessaire pour ce modèle) et le cas échéant en rechargeant le cache de vos navigateurs. Il permet de réaliser un arbre (« horizontal ») structuré côté HTML sous forme de listes imbriquées, et donc d'éviter les arbres en tableau de mise en forme (abomination) ou en art ASCII (l'éternité dans les flammes sans rémission). Il est sommairement documenté avec un exemple dans Modèle:Arbre début.

La solution est évidemment encore très imparfaite (la syntaxe actuelle est proprement imbittable, j'avoue) : tous vos tests et vos retours seront les bienvenus pour la finaliser.

Cordialement, --Lgd (d) 1 janvier 2011 à 15:20 (CET)

J'ai remarqué sur la page {{Arbre début}} que la classe familytree est même appliquée à la TOC ! Saurais-tu corriger cela ? od†n ^{[dead words]} 1 janvier 2011 à 15:42 (CET)

Les includeonly manquent, j'ai juste mis du NOTOC pour le moment. D'ailleurs, on devrait pouvoir regrouper {{Arbre début}} et {{*!}} et ainsi faire sauter un modèle, tiens. Cordialement, --Lgd (d) 1 janvier 2011 à 16:05 (CET)

Modèle : Infobox "Localité d'Algérie"

Bonjour.

Suite à cette discussion, j’ai développé dans mon bac à sable le modèle Localité d’Algérie, dont voici un test et pour lequel j’aimerais avoir vos avis (ou critiques).

La raison d’être de ce modèle (infobox) tient au découpage administratif des communes algériennes. Elles sont en général vastes (voire très très vaste comme celles du sud algérien) et certaines comportent de nombreux villages (ou villes) ou hameaux séparés de plusieurs kilomètres et ayant, pour nombre d'entre eux, une histoire propre ou nécessitant des articles dédiés pour les décrire séparément dans Wikipedia (en dehors de leur commune de rattachement). Alors, l'infobox Commune d'Algérie ne s'applique pas pour ces articles. Voici la liste des villages qui seraient (à priori) concernés par cet infobox.

Comme c'est mon premier modèle, je sollicite votre avis avant mise en service. --Poudou99 (d) 9 janvier 2011 à 22:27 (CET)

J'émettrait une seule remarque plutôt que "nom algérien" je mettrait "nom arabe" ce qui me semble plus général, même si l'algérien constitue un des nombreux dialectes de l'arabe standard. Cordialement. --GérardGiraud (d) 9 février 2011 à 10:45 (CET)

Modèle et contenus temporaire lors du lancement de PàS pour un modèle

Hello,
Succinctement, un peu pressé, je signale cette discussion qui montre un souci avec les infos sur les précautions particulières à prendre quand on lance une PàS sur un modèle : avertissement en trop petit, titre curieusement ferré à droite, etc. qui rendent l'information la plus utile assez peu visible pour les contributeurs, apparemment. Cordialement, --Lgd (d) 10 janvier 2011 à 11:34 (CET)

Modèle:NrE

Bonjour. Je vois deux inconvénients à ce modèle, qui peuvent tout à fait être sujet à discussions :

1. il insère inconditionnellement un lien interne, ce qui fait que dans un article comme Acétate de potassium il insère un lien interne non pertinent vers E261, page d'homonymie dont l'entrée correspondante est ... Acétate de potassium
2. l'info qui apparait lorsqu'on survole le mot avec la souris utilise la balise <span>, il faudrait peut-être utiliser le modèle {{Abréviation}} (ou la balise <abbr>) dans le but d'uniformiser ce comportement au sein de Wikipédia ?

Si les inconvénients que j'expose vous semblent des vrais inconvénients, je suis preneur d'aide pour réaliser les modifications pour les corriger, n'étant pas très à l'aise avec les modèles. Cordialement, Freewol (d) 21 janvier 2011 à 15:57 (CET)

Bonjour,
Pour le second point, ce serait un cas limite d'utilisation d'abbr (il ne s'agit pas à proprement parler d'abréviations explicitées). Cordialement, --Lgd (d) 21 janvier 2011 à 16:11 (CET)

Oui c'est vrai. La question se pose donc de savoir s'il est intéressant d'uniformiser ou non, pour avoir le petit point d'interrogation, et éventuellement les tirets en-dessous du mot.

Pour ce qui est du lien, je me rends compte que mon exemple était mauvais : dans la page du composant en lui-même, il suffit juste de ne pas utiliser le modèle {{NrE}}, qui n'apporte pas d'info supplémentaire au contenu de l'article. De même, pour un appel récurrent au numéro, il suffit de n'utiliser le modèle que sur la première occurrence ... Du coup, plutôt que la « facultativité » du lien, qui ne me semble plus indispensable, une meilleure possibilité de customisation du lien me semble intéressante. Ex : E261 lié à Acétate de potassium plutôt que E261, page d'homonymie. Cordialement, Freewol (d) 21 janvier 2011 à 17:05 (CET)

Remplacer tout le bloc de switch du span title (le span title disparaît) par un switch sur le lien, avec comme valeur par défaut le paramètre {{{1}}} et comme valeurs au cas par cas les bonnes cibles du type Acétate de potassium pour E261 ?

Pour le span title, la proposition de supprimer est peut-être un peu abrupte : est-ce qu'on pourrait plutôt utiliser le modèle pour qu'il insère la mention actuelle du title dans le fil du texte, entre parenthèses, à la suite du lien ? Ou est-ce que le résultat « E261 (Acétate de potassium, sel naturel, conservateur) » sera trop verbeux ? Du point de vue de la sémantique du code de la page et de son accessibilité, ce serait optimal. Du point de vue éditorial, je ne sais pas ? Cordialement, --Lgd (d) 21 janvier 2011 à 17:43 (CET)

Ça me semble très bien comme ça, j'en parlerai au projet correspondant pour avoir leur avis sur la question. Merci pour la proposition. Freewol (d) 23 janvier 2011 à 14:23 (CET)

modèle Séparateur sur Wikisource

Bonjour,

J'ai besoin d'un coup de main au sujet d'un modèle de Wikisource. Ce modèle affiche une barre horizontale au centre de l'écran (cf par exemple Petit volume contenant quelques aperçus des hommes et de la société). Il fonctionne bien sous Firefox, par contre sous Internet Explorer 8 et Vista, la barre est alignée à gauche. Est-ce que quelqu'un peut réparer cela ? Pyb (d) 26 janvier 2011 à 18:10 (CET)

Ce serait plutôt sous IE6 et IE7 que le problème se produit. Pour le résoudre, il faut ajouter un display:block; dans les styles du <hr>. Cordialement, --Lgd (d) 27 janvier 2011 à 08:37 (CET)

merci beaucoup. Pyb (d) 27 janvier 2011 à 13:47 (CET)

Largeur de colonne

Bonjour, je voudrais construire un tableau dont la largeur corresponde à la largeur de la page moins une longueur fixée. Concrètement, j'aimerais écrire width:100%-250px mais ça ne fonctionne pas. Quelqu'un saurait-il comment obtenir ce résultat ? Merci d'avance, Ambigraphe, le 26 janvier 2011 à 22:33 (CET)

Si la largeur du tableau est fixé à 100%, et que la premiere colonne à une largeur fixée à 250px; la largeur de la deuxième sera faite automatiquement. -- Xfigpower (pssst) 27 janvier 2011 à 10:58 (CET)

Bonjour ! Est-ce le tableau ou une colonne qui doit faire la largeur de la page moins une largeur fixée ? Si c'est le tableau, pour peu que son contenu soit assez long, c'est faisable en mettant une marge (à gauche ou à droite) de 250 px, comme ci-dessous : Cordialement. Peter17 (d) 27 janvier 2011 à 16:40 (CET)

Globalement, la réponse à la question initiale est non. Après, donner le lien vers l'article ou la page où la question semble se poser pourrait aider à aider. Cordialement, --Lgd (d) 27 janvier 2011 à 16:51 (CET)

En ce moment, je me pose la question pour ma page utilisateur, où les boites utilisateur sont en flottant à droite et où je voudrais mettre une boite déroulante qui se colle à gauche, puis faire suivre par du texte s'épanchant naturellement ensuite en dessous.

Mais je me suis déjà posé le même problème pour des pages de portail. Enfin, si ce n'est pas possible tant pis. Merci pour vos réponses. Ambigraphe, le 27 janvier 2011 à 18:02 (CET)

Tableau spécifications des couleurs

je me bats depuis 2 heures avec {{Tableau spécifications des couleurs}}.

La dernière case en bas à droite contient des lignes blanches parce que dans le modèle, des lignes sont optionnelles. Qu'un a la solution? -- Xfigpower (pssst) 8 février 2011 à 15:10 (CET)

Nouvel élément sémantique : kbd

Bonjour,
La récente mise à jour de mediawiki a apporté notamment un nouvel élément : kbd, destiné à baliser :

• un texte que doit saisir l'utilisateur ou plus généralement une entrée utilisateur quel que soit le media (cas-type, dans une page d'aide à l'utilisation de l'interface de WP, des exemples de saisie dans un champ de formulaire tel que celui des commentaires de diff ; cas plus théorique : une commande vocale dans le futur interface vocal de WP sur smartphone)
• les touches d'une frappe clavier (cas-type, le modèle {{touche}} et cet exemple d'utilisation de kbd).

Donc, si vous voyez passer un modèle du type {{touche}} ou un autre cas d'usage de cet élément, vous savez ce qu'il vous reste à faire . Cordialement, --Lgd (d) 17 février 2011 à 21:07 (CET)

Largeur de la colonne "groupe" des palettes de navigation

Bonjour,
Plutôt que de multiplier les surcharges en styles internes (stylegroupe = width:...px), si le nouveau goût du jour est d'ajuster la largeur de la colonne de gauche des palettes à son contenu, autant le gérer globalement via mediawiki:common.css en remplaçant table.navbox td.group {width: 150px} par table.navbox td.group {max-width: 150px}. Des avis ? Cordialement, --Lgd (d) 1 mars 2011 à 08:13 (CET)

Face à ce déferlement d'avis enthousiastes, je vais peut-être passer à l'acte demain. Cordialement, --Lgd (d) 5 mars 2011 à 14:36 (CET)

Moui bof. Pour ma part je trouve que c'est très bien avec le 150px, j'aime pas les colonnes trop étroites. Et quand c'est rik-rak dans une fenêtre de faible largeur, le navigateur réduit la colonne. Et si on veut forcer sur une seule ligne on a le white-space:nowrap. Sauf que nous avons un cas particulier à gérer, qui met des width et des text-align:right et réduit ainsi l'uniformité des palettes (et qui fait aussi sauter mes {{Liste éléments}}, snif...) od†n ↗^blah 5 mars 2011 à 14:59 (CET)

L'idée générale est incidemment d'évacuer le cas particulier en question, qui surcharge inutilement les modèles. Mais encore une fois, sous réserve que « le nouveau goût du jour soit d'ajuster la largeur de la colonne de gauche des palettes à son contenu » comme le fait le susdit cas. Soit c'est la tendance et on généralise, soit c'est juste un cas de contributeur et on réussit à lui expliquer pourquoi ce qu'il fait est une fausse bonne idée  ? On pourrait certes laisser courir : le 150px ne pose pas de souci majeurs comme défaut et on n'en est pas forcément à une surcharge de styles inline près dans ces modèles. Mais la question est plutôt de savoir s'il est plus important que les contributeurs aient des occasions de s'amuser avec ces modèles ou si on cherche une certaine cohérence de comportement de l'interface pour les lecteurs. Cordialement, --Lgd (d) 5 mars 2011 à 15:23 (CET)

Je pense qu'on aurait besoin d'avis supplémentaires, le projet Modèle n'étant paradoxalement pas le meilleur endroit pour cela, du fait de sa relative désertification od†n ↗^blah 5 mars 2011 à 15:34 (CET)

C'est aussi pour cela que j'essaie un peu de refertiliser le désert : discuter de ce genre de choses entre 3 pages de discussion de contributeurs spécialisés n'est pas la meilleure formule. Cordialement, --Lgd (d) 5 mars 2011 à 15:37 (CET)

Oui, effectivement. Pour ma part je ne suis pas trop motivé par ce changement, mais je ne m'y oppose pas non plus. Et comme ça on pourra voir ce que ça donne à l'usage. od†n ↗^blah 5 mars 2011 à 15:45 (CET)

Pourquoi prendre 150px d'un encadrer alors que le mot en question ne prend pas plus de 80px? Illogique, inutile.. Il faut laisser plus de place pour la liste qui suit, car certains lecteurs et utilisateurs utilisent des résolutions très médiocres... A propos, il faut savoir que ce n'est pas une innovation mon "truc".

De plus, nous sommes les seules à utiliser se procéder. Je suis pour également le fait que le texte s'affiche à droite et non au milieu comme on peut le voir -pour encore une fois grattouiller quelques pixels, mais encore une autre histoire, badaBOOM. ~Hlm Z. [@] 30 avril 2011 à 18:51 (CEST)

Lien « [dérouler] », modèle {{Tnavbar}}, couleurs et invisibilité

Bonjour,
Dans les modèles de boîtes déroulantes où des couleurs d'arrière-plan sont utilisées (malgré WP:COULEUR mais bref), le lien « [dérouler] » peut se retrouver pratiquement invisible, comme dans cet exemple. L'ajout à mediawiki:common.css de quelque-chose comme .NavToggle {color: inherit;} permettrait de garantir la lisibilité du lien (en permettant au contributeur d'agir sur sa couleur via le style de l'élément parent, comme c'est déjà le cas pour les éléments abbr). Mieux sans doute, un ajustement des modèles et une classe spécifique pourraient permettre de n'appliquer ce type qu'au cas par cas et non par défaut. Le même principe serait potentiellement applicable à {{Tnavbar}} ou encore à .navboxToggle a pour les palettes, mais c'est à approfondir. Des avis ? Cordialement, --Lgd (d) 1 mars 2011 à 08:28 (CET)

Voici quelque chose que j'attendais depuis longtemps. Il y a régulièrement des débats sur l'utilisation des couleurs dans les palettes, et la perte de lisibilité ainsi créée. Cette méthode pourrait résoudre un bonne partie de ce problème de diversité des couleurs. Dodoïste ^{[ dring-dring ]} 1 mars 2011 à 19:01 (CET)

Disons que c'est une piste plus pragmatique que l'application de la recommandation. Mais attention, ce n'est pas évident à mettre en place (il ne s'agit pas de se retrouver avec des liens noirs par défaut au lieu du bleu ). Cordialement, --Lgd (d) 1 mars 2011 à 20:33 (CET)

{{Métadonnées personne‎}}

Pour info, j'ai ouvert un sondage sur le modèle Métadonnées personne‎. — Calimo ^{[á quete]} 7 mars 2011 à 17:04 (CET)

Appel d'un modèle hébergé dans une sous-page

Bonjour,

J'aimerais alléger une page (Économie du Nigéria) en cachant l'infobox dans une sous page (habilement nommée Économie du Nigéria/Infobox économie) - tout ça pour favoriser l'accessibilité direct au texte encyclopédique sans avoir à se taper d'abord 30 lignes de code et paramètres. Je pensais qu'on pourrait l'appeler tout bêtement par {{Économie du Nigéria/Infobox économie}}, histoire de créer quelque chose dans le coin encyclopédique plutôt que l'espace modèle, mais ce n'est visiblement pas le cas. Je suis pourtant certain d'avoir déjà vu cette possibilité utilisée quelque part.

Question: ai-je rêvé, ou ai-je loupé qque chose? Popo le Chien ^ouah 15 mars 2011 à 09:59 (CET)

Modèle:Économie du Nigéria/Infobox économie

Salut - y-a rien qui marche pas ! la preuve ou alors une question de titre non conventionnel... TIGHervé 15 mars 2011 à 12:00 (CET)

En fait, non et ce n'est pas juste une question de convention de titre. Il ne faut en aucun cas créer Économie du Nigéria/Infobox économie qui en dépit des apparences ne sera pas une sous-page de Économie du Nigéria, mais sera une page à part entière de l'espace article (les sous-pages n'existent pas dans celui-ci, il n'y a que des articles). J'ai donc annulé ton renommage, Hervé.

Pour ce genre de choses, il faut créer Modèle:Économie du Nigéria/Infobox économie appelable avec {{Économie du Nigéria/Infobox économie}}, ou bien peut-être plus pratique, quelque-chose comme Modèle:Infobox économie du Nigéria appelable avec {{Infobox économie du Nigéria}}.

Cela dit, déporter ce genre d'appels de modèles dans des modèles ne se pratique que rarement et pour dire l'essentiel : cela ne simplifie pas l'édition des articles pour les contributeurs, contrairement aux apparences. Si on avait un espace de nom Annexes, ça pourrait être plus probant de ce point de vue, et encore. Cordialement, --Lgd (d) 15 mars 2011 à 12:04 (CET)

PS : aux dernières nouvelles. 1) j'ai renommé vers Modèle: 2)j'ai annulé ce renommage 3)tu as renommé comme en 1. Je suis donc bien d'accord (il y a un début de discussion sur ma page). TIGHervé 15 mars 2011 à 12:16 (CET)

Conflit d'edit Arf, j'étais allé chez Hervé avant de voir la discussion ici.

L'idée de déplacer les infobox me semble très bonne, mais je ne suis pas sûr que les mettre dans l'espace modèle soit la meilleure solution. Déjà, les modèles ne devraient pas être à usage unique mais être utilisés sur plusieurs pages. Mettre les infobox dans cet espace risque de gêner le suivi des "vrais" modèles.

Ensuite, les infobox ne sont plus rattachées directement aux articles. On pourrait peut-être créer un espace "Infobox", rattaché aux articles un peu comme le sont les pages de discussion (ajout à la liste de suivi en même temps que l'article, déplacement en cas de renommage, etc.) ?

Moyg hop 15 mars 2011 à 12:14 (CET)

Oui j'y disais que "ça ne me gênait" pas ... TIGHervé 15 mars 2011 à 12:16 (CET)

Oui, je n'étais pas très chaud pour rajouter une couche d'infoboxes dans l'espaces modèle - quoiqu'on nen soit plus à 10 ou 20'000 près-, d'où l'idée de sous-pages de main (mais il reste, effectivement, la question du suivi). La création d'un sous-espace infobox (comme discussion) me parait une bonne idée, mais j'ai l'impression que ce serait du lourd. Je me trompe? Popo le Chien ^ouah 15 mars 2011 à 12:24 (CET)

Lourd pour qui ? Pour les devs, je ne pense pas. Pour ceux qui lanceront la pdd, oui. Mais on ne pourra pas faire de déplacement massif d'infobox sans pdd/sondage. Moyg hop 15 mars 2011 à 12:40 (CET)

@Tigh: heu non, ou alors tu as fais un 2e renommage en même temps que je corrigeai le premier. Mais peu importe.

@Moyg : c'est une question pendante depuis un bout de temps et en effet la multiplication de ces modèles à usage unique ne facilite pas la maintenance de cet espace. Mais il ne s'agirait pas d'un simple espace « Infobox » : d'autres types de modèles sont concernés. Par exemple, les très nombreux modèles de dernière version stable de logiciel, ou encore les données de timeline comme Modèle:Relevé hydrologique/Mauldre (J'ai une liste de ces types de pseudos-modèles quelque-part, justement en prévision de cette question).

Si vous vous sentez à réouvrir utilement la question d'un espace de contenu annexes des articles (quel que soit son nom) et si on peut éviter les brouillage par les discussions stériles comme lors des tentatives précédentes (les trolls sur les bibliographies et autres notes qui-sont-elles-des-annexes-ou-pas), ce serait bien. Cordialement, --Lgd (d) 15 mars 2011 à 12:25 (CET)

En gros ce serait une discussion similaire à celle qui a mené à transférer les PàS vers une sous-page de l'espace discussion, ou il y aura une demande technique à la clef? Popo le Chien ^ouah 15 mars 2011 à 12:37 (CET)

Non, il y aura une demande technique pour qu'un espace de nom supplémentaire soit créé (ce qui est simple une fois que les dev constatent que la demande est consensuelle, via un sondage, une PDD etc.) Cela s'est fait dans le passé pour l'espace Portail, par exemple. --Lgd (d) 15 mars 2011 à 12:40 (CET)

Modèle:Infobox Console de jeux vidéo

Bonjour,
J'ai une requête qui ne doit pas être bien complexe mais je ne suis pas assez familier avec la syntaxe pour comprendre de moi-même. Voilà, j'aimerai que les images de flèches pointant vers la gauche et la droite (console précédente et console suivante) dans le modèle Modèle:Infobox Console de jeux vidéo pointe directement sur le lien de ladite console. Exemple : la flèche gauche en bas de Super Nintendo devrait diriger vers Nintendo Entertainment System et celle de droite vers Nintendo 64. À noter que l'on peut déjà trouver les champs « prédécesseur » et « successeur » sur le modèle et donc ne pas rajouter un champ inutile. En espérant que ça ne passe pas aux oubliette comme avec le modèle DateJV il y a quelques mois, et en vous remerciant. Cordialement, Kilianours (d) 28 mars 2011 à 20:42 (CEST).

Excellente question, que je me m'étais déjà posée. C'est lié au modèle {{Infobox/Triptyque}} sous-jacent. En fait c'est un peu délicat à mettre en œuvre (pas difficile du tout, mais y'a un peu de travail), car le modèle doit connaître le titre de la page à linker (pour le passer en link= à l'[[Image:]]), ce qui n'est pas le cas avec les liens wiki actuels [[PouetStation (console)|PouetStation]] passés à l'infobox. Il faut donc modifier les paramètres de l'infobox. Soit :

• garder les paramètres [[PouetStation (console)|PouetStation]] et ajouter deux paramètres de type lien_avant=PouetStation (console) et idem avec lien_après=
• transformer en paramètres lien_avant=PouetStation (console) et libellé_avant=PouetStation ; idem pour le lien après

Cordialement, od†n ↗^blah 4 avril 2011 à 13:39 (CEST)

J'ai un peu tâtonne sur le modèle {{Infobox/Triptyque}}, mais effectivement c'est un peu de la m*** cette mise en abîme des modèles. Kyro avait déjà essayé en février dernier de mettre en forme des liens sur les flèches, mais ça n'avait apparemment pas fonctionné... Fabrice Ferrer ^[agora] 4 avril 2011 à 13:47 (CEST)

Listes en ligne, accessibilité

ƝEMOI – Bonjour à tous. La question que je comptais poser l’a déjà été par un autre sur la page de discussion du modèle : Liste éléments. Du point de vue de l’accessibilité, il semblerait correct que le code HTML généré par ce modèle utilise une liste HTML avec un affichage CSS inline ; je crois en revanche qu’il n’est pas possible pour le moment de faire insérer le caractère séparateur de liste via le CSS, car tous les navigateurs ne le supporteraient pas. Pourrions-nous faire un point sur la chose ? ce 28 mars 2011 à 21:38 (CEST).

ƝEMOI – Quelqu’un a-t-il un problème avec ce résultat, via ce modèle ? ce 31 mars 2011 à 14:40 (CEST).

On en a parlé justement Discussion modèle:Méta palette de navigation et pour le coup, l'utilisation des balises li m'a achévé de me convaincre; Par contre, j'aime mieux le caractère – comme séparateur par défaut. -- Xfigpower (pssst) 31 mars 2011 à 15:23 (CEST)

ƝEMOI – Heu… sur la discussion modèle : méta palette de navigation, on a parlé de {{liste éléments}}, mais ce dernier n’utilise pas <li> pour le moment, c’est justement ce à quoi sert la modification que je propose ; j’avoue donc ne pas comprendre ton propos. Pour le séparateur par défaut, c’est à faire après une discussion distincte, car c’est un problème distinct. Ce 31 mars 2011 à 15:58 (CEST).

Un modèle du type {{liste éléments}} ou du type de ton essai est une possibilité, mais inutilement compliquée : la syntaxe wiki habituelle d'une liste (*) sera nettement préférable. Pour ce qui est de la gestion du séparateur, c'est faisable via CSS de manière propre (par pitié, avec un séparateur unique, pour l'ergonomie la plus élémentaire) mais avec le souci de ne pas compliquer la syntaxe wiki tout en assurant la compatibilité avec les navigateurs les moins avancés en CSS. Surtout, cette amélioration qui jouera essentiellement pour les palettes de navigation serait certes pertinente, mais elle ne résoud pas les principaux problèmes liés à ces modèles de palettes. Pour cela, il faut attendre des développements qui sont en cours du côté mediawiki.

Donc, oui sur le fond, mais pas sous la forme que tu proposes et sans se précipiter non plus : d'abord un script et une syntaxe de boîtes déroulantes propres et accessibles, ensuite les styles nécessaires à des contenus à y mettre, comme ces listes horizontales. Cordialement, --Lgd (d) 31 mars 2011 à 18:50 (CEST)

ƝEMOI – Ta réponse est très intéressante ; un peu à-côté de la question, mais très intéressante quand même. Le fait est qu’actuellement, il existe {{liste éléments}}, qui n’utilise pas une syntaxe à base de <ul><li>, et qui est de plus en plus utilisé (je ne suis pas le seul à l’appliquer couramment). Ma question concernait le fait de faire évoluer ce modèle pour qu’il utilise ladite syntaxe ; je crois qu’elle mériterait quand même réponse, en l’état actuel des choses.

Le point que tu soulèves est que {{liste éléments}} n’est pas optimal, et qu’il vaudrait mieux un {{liste éléments/débuts}} et un {{liste éléments/fin}} qui encadrent une liste à base de *. Ça réglerait je crois les problèmes de formatage dans les éléments de liste. Mon « Pourrions-nous faire un point sur la chose ? » était visiblement très adapté. Ce 31 mars 2011 à 19:08 (CEST).

Ajout : Ah, et concernant la gestion de la puce par CSS : tu penses à l’utilisation d’une image, ou au tag :before ? car le second ne me semble pas encore assez supporté pour être utilisé, et le premier, je ne suis pas fan (plus lourd). Dans tout les cas, le travail peut être fait sans attendre les évolutions de MediaWiki.

Il ne faut pas passer par des styles inline mais par common.css. Il n'y a pas besoin d'un {{liste éléments/débuts}} et {{liste éléments/fin}}. le séparateur peut être une image, en effet. Mais encore une fois, ce n'est à mon avis pas le moment de faire cette modification, sauf à faire impulsivement ce qu'on devra adapter ensuite. Mais bref. Bonne continuation, cordialement, --Lgd (d) 31 mars 2011 à 20:14 (CEST)

Modèle Infobox ou Boite déroulante (ie. images de partitions musicales)

Est-ce que tout d'abord il existe un modèle d'Infobox OU "boite déroulante" pouvant être adaptée à des parititions de musique, par exemple, pour étaler une séries d'images de partitions musicales (music sheets). Dans le cas qui m'intéresse, chaque chanson compte en général deux(2) pages de musique pour un total de 14 chansons, or 28 images au total. merci.--RaynaultM (d) 4 avril 2011 à 19:23 (CEST)

Sauf erreur ce n'est pas du contenu qui est destiné à être placé sur Wikipédia. Kyro ^{me parler} le 4 avril 2011 à 20:15 (CEST)

Modèle:Lien web et URL brute pour le paramètre éditeur

Bonjour, auriez-vous un avis sur cette question : Discussion modèle:Lien web#Correction de bug ? od†n ↗^blah 10 avril 2011 à 23:54 (CEST)

Modèle:Wikiprojet Rock progressif

Bonjour,
alors voilà: j'ai dû me tromper dans la création de ce modèle mais je ne sais absolument pas où.
Il semble que ce soit une sombre histoire de problème avec la majuscule à Rock progressif.
Un exemple sur la page de discussion de Pink Floyd: j'insère

...Wikiprojet|Pink Floyd|maximum|Rock|maximum|rock progressif

et ça marche, mais si j'insère

...Wikiprojet|Pink Floyd|maximum|Rock|maximum|Rock progressif

ça ne marche pas...
Sauf que j'aimerai bien l'avoir, moi, ma majuscule (voyez-vous ce que j'ai voulu dire ?)...
Sinon si ça peut vous aider, voilà le modèle sur lequel je me suis basé et qui fonctionne correctement: Modèle:Wikiprojet Cinéma
Dark Attsios (d) 11 avril 2011 à 19:36 (CEST)

{{Ébauche/paramètres rock progressif}} alors qu'on a {{Wikiprojet/image}} qui permet d'insérer rapidosse l'image pour l'argument Rock. Pas ultra évident le truc...Sinon, y a {{Ébauche/paramètres Musique}} qui fait une redirection. -- Xfigpower (pssst) 11 avril 2011 à 22:29 (CEST)

-- Xfigpower (pssst) 11 avril 2011 à 22:31 (CEST)

Bonjour, merci de répondre aussi rapidement mais, à moins que n'ai pas compris, il reste un problème avec les catégories: elles ont un problème de majuscule, à nouveau (si je mets "Rock", la catégorie sera "Rock" et inversement). Hors, les catégories crées sont "rock", et sachant que la catégorisation se fait de manière automatique et que j'ai cru comprendre qu'il était impossible de rediriger une catégorie vers une autre catégorie si elle se faisait de manière automatique, ça pose un problème...Dark Attsios (d) 12 avril 2011 à 14:47 (CEST)

T'es dur avec moi...Fallait chercher du coté de {{Wikiprojet/catégorisation}}

Énorme merci ! Dark Attsios (d) 12 avril 2011 à 16:13 (CEST)

Modèle de référence en source?

Bonjour,
Adepte des espaces de références, je souhaite mettre les modèles de référence constitués en source. Peut-on utiliser {{harvsp}} avec de tels modèles ; exemple :

• Bernard Dupriez, Gradus, les procédés littéraires [détail des éditions] 

Merci! Prosopee (d) 18 avril 2011 à 16:59 (CEST)

Infobox Musique (oeuvre) et brouillon

Bonjour les modélistes, je suis en train d'améliorer le modèle {{Infobox Musique (oeuvre)}} dans mon brouillon mais on m'a demandé deux choses à faire mais je n'y arrive pas. La première demande se situe ici et la seconde se situe là et consiste à mettre un if supplémentaire: avec si if compositeur non vide alors auteur=parolier sinon auteur=auteur-compositeur. N'hésitez à modifier mon brouillon et en espérant que vous pourriez m'aider. Cordialement, Ben76210 (d) 21 avril 2011 à 11:37 (CEST)

Réflexions sur le modèle : o

ƝEMOI – Le modèle : o est un modèle de formatage (qui rend « ^o »), comme l’a été le modèle : r (« ^r ») désormais obsolète. Il s’utilise couramment avec des syntaxe comme « n{{o}}2 » ou « n{{o}} 2 » selon le rédacteur, me semble non-pensé pour l’accessibilité (un lecteur vocal doit être perdu, particulièrement qu’il existe plusieurs abréviation utilisant ce modèle, comme « folio » (f^o), « recto » (r^o), etc., qui ont déjà pour certains les modèles adaptés : folio, recto…). Ne pourrait-on pas s’en débarrasser l’obsolèter ? c’est la question de ce 11 mai 2011 à 12:35 (CEST).

Il faut déjà commencer par recycler l'existant. --Lgd (d) 11 mai 2011 à 12:39 (CEST)

ƝEMOI – Je n’en doute pas. C’est une invitation à faire la demande à un bot ? ce 11 mai 2011 à 12:44 (CEST).

Non, à regarder d'abord de quoi il retourne. --Lgd (d) 11 mai 2011 à 13:00 (CEST)

Modèles d'abréviation ordinale

Bonjour, les modèles d'abréviation ordinale sont nécessaires car entre autre plus accessibles.

Faisant suite à cette discussion avec Od1n (d · c), me rendant compte que ces modèles s'arrête à {{20e}}, j'ai lancé un script le 9 mai dernier au parcours des pages du main à la recherche d’occurrences matchant cette expression régulière :

(\n|#|\*|'|(?<!\d) |\(|\|)([1-9][0-9][0-9]|[2-9][0-9]) *(<sup>|<small>|\{\{|\{\{[eE]xp\|)?(i?[éeè])(me)?(</sup>|</small>|\}\})?

Cette expression repère les occurrences pouvant être remplacées par les modèles {{21e}} à {{999e}} afin d'évaluer la nécessité de créer ces derniers.

Afin d'éviter le maximum de faux positif, cette expression est construite de manière stricte, c'est à dire que les occurrences trouvées ci-dessous sont les occurrences remplaçables automatiquement, le nombre d'occurrences réelles devrait être plus élevé.

Les modèles n'étant pas listés n'ont pas été trouvés par le script.

Le script venant de terminer son travail (bah oui c'est que notre encyclopédie n'est pas petite ), je vous publie ci-dessous le rapport d'analyse.

Bien à vous, Micthev ^(discuter), le 15 mai 2011 à 14:01 (CEST)

Je pense que ces chiffres sont polués par les modèle du style {{Palette Divisions d'infanterie de la Wehrmacht}}. Ces modèles peuvent très bien être traité par {{ordinal}}. Après, les chiffres me paraissement démesurer ( 939^e, je l'utilise pas tout les quatre matin).. Ya pas des faux positifs dans le tas? -- Xfigpower (pssst) 15 mai 2011 à 16:03 (CEST)

Comme je dis ci-haut, je n'ai pris que les résultat de main, donc {{Palette Divisions d'infanterie de la Wehrmacht}} et autre du genre n'ont pas été analysé. Et l'expression régulière étant très stricte, le taux de faux positif est extrêmement faible (j'ai passé les articles commençant par la lettre A en visuel sans en voir un seul). Pour le modèle que tu cite {{939e}} : 151 occurrences trouvées sur les 1 174 861 articles actuels, cela te semble vraiment démesuré ? Cordialement, Micthev ^(discuter), le 15 mai 2011 à 16:15 (CEST)

Bonjour. J'ai commencé à intégrer dans WPCleaner des aides à la correction d'orthographe et de typographie en se basant sur une liste de suggestions, Wikipédia:Liste de fautes d'orthographe courantes. J'ai déjà mis un certain nombre de suggestions pour les abréviations ordinales. N'hésitez pas à compléter/corriger si vous voyez des erreurs ou des manques. --NicoV (d) 19 mai 2011 à 10:20 (CEST)

J'ai créé les modèles d'abréviations jusqu'à 50^e (en fait je ne suis pas allé jusqu'à 100 parce que je me suis tâté pour la clé de tri de ce dernier ) – od†n ↗^blah 1 septembre 2011 à 00:42 (CEST)

Du coup, aujourd'hui j'ai effectué un bel arrondi, en allant jusqu'à 100^e C'est le genre de petite chose qui devrait faciliter la vie aux contributeurs. od†n ↗^blah 1 septembre 2011 à 02:21 (CEST)

Question technique : pourquoi ne pas commencer la regexp par (\D\s*) au lieu de ce truc assez compliqué : (\n|#|\*|'|(?<!\d) |\(|\|) ? Ça matcherait des cas à la marge, comme "bidule,99è exemplaire de truc". Y aurait-il des faux positifs qui apparaîtraient ? Je ne crois pas. (Je pense évidemment au remplacement par un bot, pas au rapport d'analyse qui est tout à fait convaincant...)--Juju2004 (d) 1 septembre 2011 à 08:35 (CEST)

Il y a de l'idée, mais c'est à affiner : avec ta solution, le \D matche l'espace dans « 123 456e » od†n ↗^blah 3 septembre 2011 à 03:11 (CEST)

Évidemment, je me suis fait avoir comme un bleu ! Avec ça : (^|[^\d\s])\s*, ça devrait marcher :

• soit un début de chaîne ;
• soit ni un chiffre ni un espace (lettre, ponctuation, symboles divers...).

Suivi d'espaces éventuels.

Il faudrait aussi vérifier qu'on n'a pas une lettre ou un chiffre à la fin, pour éviter de matcher les cas suivants :

• "10em" (unité de mesure em) ;
• "10e2" (abréviation pour les exposants) ;

(Il y en a sûrement d'autres...) Donc terminer la regexp avec quelque chose comme (\W|$).--Juju2004 (d) 3 septembre 2011 à 11:22 (CEST)

Générateur de code de courbe démographique

Bonjour, le modèle générateur de code de courbe démographique permet de générer automatiquement une courbe dans un système d'axes, existe-t-il un moyen ou un autre modèle permettant d'insérer deux courbes au sein du même système d'axes ? Cordialement. wikineptune (d) 18 mai 2011 à 12:44 (CEST)

Je réponds moi-même à ma question puisqu'il semble que le problème que j'ai abordé soit traité quelques lignes plus bas (!) sur cette même page. Ce modèle Modèle:Graphique polygonal peut donc être une solution pour ceux qui rencontre le même problème. wikineptune (d) 31 mai 2011 à 00:04 (CEST)

Modèle:Tableau Coupe 16 (5 sets)

Bonjour,

Je trouve que le rendu de ce modèle n'est pas très beau (1/2 finale est écrit en dessous des autres tours). Y a-t-il une raison à cela (problème de place, beaucoup de personnes trouvent ça joli...) ? Sinon, serait-il possible de le modifier un peu ?

Merci. Bibitono ^_^ 23 mai 2011 à 14:38 (CEST)

Le décalage vient probablement du fait que les colonnes se superposent à partir du quart de finale. Peut-être que ce serait plus esthétique en décalant l'encadré de finale en dessous de celui de demi-finale au lieu de le mettre au dessus ? Ambigraphe, le 30 mai 2011 à 22:52 (CEST)

Je crois que mon premier message n'était pas assez explicite. À la base, je pensais à un tableau où les colonnes ne se superposent pas, ni avant ni après les quarts de finale. Mais il est possible que l'écran de certains (petits ordinateurs portables, smartphones...) ne soit pas assez large pour afficher le tableau ainsi. Si ce n'est pas un problème de largeur, je maintiens ma proposition de départ (ne jamais superposer les colonnes). S'il y a un problème de place, ta proposition d'afficher "finale" en dessous de "demi-finale" peut en effet s'avérer plus esthétique que l'existant sans pour autant prendre plus de place. Si tu es capable de modifier le modèle sans trop de difficultés, pourrais-tu me montrer ce que ça donne ? Merci en tout cas pour ta réponse.

Le modèle utilisé en basket (par exemple ici) est à mon avis plus joli, même si la contrainte de place n'est pas la même, pour deux raisons : 1/ Dans le modèle de tennis, on veut afficher nom, prénom (et pas seulement initiale) et nationalité des joueurs, ce qui est parfois plus long qu'un nom de club ; 2/ Le modèle en question ici nécessite 5 cases pour afficher les scores (5 sets) et non pas une seule. Bibitono ^_^ 30 mai 2011 à 23:35 (CEST)

page Modèle:Ouvrage

Bonjour c'est pas facile à trouver cette page, le Modèle:Ouvrage il ne marche plus comme il faut voir Ainulindalë#Ouvrages_de_Tolkien, j'ai cru que c'était une modification récente mais elle date quand même de cinq jours [1] on l'aurait vu, est-ce que vous pouvez réparer ça? Aurmegil (d) 26 mai 2011 à 13:50 (CEST).

réparé par Totodu74 (d · c), un grand merci à lui. od†n ↗^blah 26 mai 2011 à 14:45 (CEST)

Graphique

Bonjour, je ne trouve pas de modèle permettant de faire des tracés graphiques du genre courbe avec axes x et y (pas d'histogramme). Ça existe ? --Jesmar (d) 28 mai 2011 à 14:13 (CEST)

Cela peut être fait, au moins dans une certaine mesure, avec timeline, qui n'est pas limité aux histogrammes (voir l'exemple de Modèle:Générateur de code de courbe démographique). Cordialement, --Lgd (d) 28 mai 2011 à 14:17 (CEST)

Merci. Je vais voir ça. --Jesmar (d) 28 mai 2011 à 16:49 (CEST)

J'ai réussi à l'utiliser et à obtenir le résultat que je voulais (semblable aux courbes démographique) en le faisant à la main, sans le modèle de générateur car il me fournit pas vraiment ce que je veux. Mais si je veux rajouter une nouvelle année genre 2011 puis l'année prochaine 2012, etc, je dois recalculer toutes les valeurs de tous les points en X (idem si je veux rajouter une nouvelle valeur en Y). Un peu dur à gérer. --Jesmar (d) 28 mai 2011 à 18:09 (CEST)

Oui, c'est l'un des soucis connus. Mais c'est pratiquement tout ce que l'on a en stock pour le moment. Cordialement, --Lgd (d) 28 mai 2011 à 18:13 (CEST)

Tiens Modèle:Graphique polygonal, tout neuf, peut peut-être aussi aider. Cordialement, --Lgd (d) 28 mai 2011 à 18:58 (CEST)

Je viens de le créer en effet... Il s'occupe de faire la fameuse translation valeur => pixel. C'est mon premier modèle, il se base sur EasyTimeline. Je suis ouvert à toute remarque!

Argamea (d) 28 mai 2011 à 19:01 (CEST)

Une remarque ayant trait à l'accessibilité du contenu : timeline pose un souci particulier de gestion de l'alternative textuelle du graphique (les données numériques sous forme graphique ne sont pas perceptibles pour tous les utilisateurs, ne sont pas indexables, etc.). Sans entrer dans les détails pour le moment, la solution actuellement recommandée serait que le modèle génère non seulement le graphique mais aussi un tableau des données (l'alternative). Cela a aussi un intérêt ergonomique pour tous les utilisateurs, le tableau HTML étant plus aisément exploitable que l'image pour récupérer toute ou partie des données. Ce serait envisageable ? Cordialement, --Lgd (d) 28 mai 2011 à 19:49 (CEST)

Bien mieux ce modèle, par contre le modèle formatnum n'est pas supporté pour les chiffres sur l'axe y et le fait de mettre un espace, c'est pareil, ce n'est pas supporté. En revanche, il passe sur l'axe x. --Jesmar (d) 28 mai 2011 à 22:20 (CEST)

Ah oui, si on pouvait rajouter des points, ça serait encore mieux. --Jesmar (d) 28 mai 2011 à 22:31 (CEST)

• Concernant l'alternative tableau HTML, je vais essayer de voir ce que je peux faire mais je ne garantis rien, étant donné que rien ne permet de le faire nativement dans EasyTimeline.
• Concernant l'ajout de points, je vais l'ajouter, et mettre ca en paramètre (genre points = oui).
• Concernant le non-support du formatnum sur l'axe y : c'est normal, l'axe y est géré en valeurs continues tandis que l'axe x n'est qu'un enchaînement de valeurs précises, c'est un libellé textuel. Le formatnum empêchant de faire des calculs, il n'est pas supporté... Et étant donné que ce n'est pas non plus supporté dans EasyTimeline, malheureusement il ne sera pas possible d'utiliser de formatnum sur l'axe y. Je rajouterai ce point dans la documentation.

Merci pour vos retours!

Argamea (d) 30 mai 2011 à 10:43 (CEST)

Modèle:Heure

J'ai mis un mot sur la page de discussion du modèle en question mais je préfère le dire ici aussi pour une réponse la plus rapide possible. Je copie donc mon message :

Avec le Modèle:Heure, quand on veut afficher un temps avec une précision au millième de seconde (comme dans des courses de Formule 1 par exemple), on a un problème.
Voici un exemple : {{heure||1|18|016}} donne 1 min 18 s 016 au lieu de 1 min 18 s 016. On confond alors les centièmes avec les millièmes, ce qui est gênant. Quelqu'un pourrait-il corriger ça ? Merci. Bibitono ^_^ 8 juin 2011 à 20:03 (CEST)

Il y a quelqu'un ? Bibitono ^_^ 13 juin 2011 à 18:02 (CEST)

J'ai modifié le modèle pour qu'il ne supprime pas les leading zeros (comme c'était déjà le cas pour les secondes) ; je ne pense pas que cela entraîne de problème particulier. od†n ↗^blah 14 juin 2011 à 19:38 (CEST)

Merci beaucoup de t'en être occupé ! C'est très bien comme ça ! Bibitono ^_^ 14 juin 2011 à 19:50 (CEST)

{{Bienvenue Copyvio 1}}

Bonjour, il y a un bug avec le sommaire qui se colle sur le bandeau (Illustration) mais je n’arrive pas à voir la cause du problème. Cordialement. --Superjuju10 ^{Auboisement à votre écoute} 10 juin 2011 à 18:20 (CEST)

À mon avis, il est préférable d'utiliser un tableau comme dans les autres modèles d'avertissement (voir la Catégorie:Modèle message vandale, Modèle:Bienvenue spammeur par exemple), plutôt que de réutiliser le cadre de la page principale. D'une part ce sera plus homogène avec les autres messages, d'autre part cela évitera ce bug du cadre (qui n'est pas fait pour être utilisé dans une page avec un sommaire). Cordialement. Nodulation (d) 10 juin 2011 à 19:28 (CEST)

Cadre suppriméé + autres corrections et compléments. --Superjuju10 ^{Auboisement à votre écoute} 10 juin 2011 à 21:27 (CEST)

Modèle:Homonymie (d · h · j · ↵)

Suite à une demande effectuée ici, je déplace le message initial. Désolé de ne pas recommenter plus la demande, j'ai l'impression de partir dans un parcours du combattant et que le boulot va être perdu :

Bonjour, je désire déprotéger le modèle précédemment cité dans le but d'y ajouter un paramètre optionnel.
Ce paramètre permet de classer l'article sur lequel le bandeau est apposé dans les catégories précisées par l'option:
{{Homonymie}} s'utilise actuellement sans paramètre.
{{Homonymie|Jeu vidéo}} catégorise l'article dans "Catégorie:Homonymie de jeu vidéo"
{{Homonymie|Cinéma|Jeu vidéo}} catégorise l'article dans "Catégorie:Homonymie de cinéma" et "Catégorie:Homonymie de jeu vidéo"
Etc
Le code à ajouter :{{Homonymie/Catégorisation|{{{1|}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}|{{{7|}}}}}
Pour l'instant, un seul projet est inscrit sur la sous-page Modèle:Homonymie/Catégories (d'autres projets seront surement intéressés à l'avenir), qui utilise également Modèle:Homonymie/Catégorisation.
La finalité est de regrouper les homonymies par projet (ceux qui le désire) dans une catégorie et créer une liste de suivi dans le but de surveiller ces pages où il se passe pas mal de choses plus ou moins bien. --Arcade Padawan (d) 28 juin 2011 à 14:31 (CEST)

{{Décennie}}, {{Décennie1}}

Bonjour, à titre d'information :

• Quels sont les différentes entre ces deux modèles ?
• Pourrait t-on alors modifier leurs interfaces (jaune caca doie, "◄◄"..., pas top niveau esthétique) ? ~Hlm Z. [@] 30 juin 2011 à 22:41 (CEST)

Pour le doublon, c'est ok, et le deuxième point ? ~Hlm Z. [@] 3 juillet 2011 à 20:31 (CEST)

Comment tester la présence d'un paramètre ? résolu

Bonjour,

Je viens de faire des modifications sur un modèle sur la wikipédia en breton : br:patrom:Taolenn kumun qui calcule désormais automatique la densité de population. Je voudrais ajouter une catégorie cachée pour les pages utilisant encore le vieux paramètre {{{stankter}}}. Je pensais bêtement utiliser un #if mais cela ne fonctionne pas. J’ai eu l’explication du pourquoi cela ne fonctionnait pas sur mw:Help:Extension:ParserFunctions/fr#.23if: mais pas de solution à mon problème… Vu que ledit paramètre est numérique, je pensais mettre un #iferror sur un #expr sur ledit paramètre mais cela me semble lourd (et incertain). Quelqu’un aurait une idée ?

Cdlt, Vigneron * ^discut. 15 juillet 2011 à 12:54 (CEST)

Pour moi, le #if est censé marcher mais il faut utiliser {{{paramètre|}}} (avec le |). En tout cas, c'est comme ça que j'ai fait pour {{Avertissement Homonymie}} pour tester la présence ou non d'un paramètre. --NicoV (d) 15 juillet 2011 à 13:31 (CEST)

Ben visiblement cela ne fonctionne pas et en plus la page d’aide précise bien que cela n’est pas censé fonctionner.

J’ai remplacé {{{stankter}}} par (erreur bête mais que je commets encore courrament ; merci pour ton exemple qui m’a fait comprendre mon erreur) et apparemment cela fonctionne.

Du coup, je vais allez modifier la page d’aide sur mw pour les prochaines qui s’y ferait prendre.

Cdlt, Vigneron * ^discut. 15 juillet 2011 à 13:49 (CEST)

Je pense que la page d'aide est correcte (mais vraiment pas claire) :

• l'exemple avec "En général, la condition utilisée sera la valeur d'un paramètre" est la syntaxe correcte (avec le |)
• dans les remarques, il y a en fait un exemple de mauvais syntaxe (sans le |), mais ce n'est pas très clair qu'il s'agit d'un exemple avec une autre syntaxe.

--NicoV (d) 15 juillet 2011 à 14:05 (CEST)

modèle non trouvée

Bonjour,

Y-a-t-il une solution pour trouver toutes les pages qui utilisent un appel à un modèle qui n'existe pas? -- Xfigpower (pssst) 1 août 2011 à 12:00 (CEST)

Bonjour. Pour un nom de modèle donné, il y a les pages liées. Pour la liste des modèles demandés, il y a Spécial:Modèles demandés. --NicoV (d) 1 août 2011 à 12:47 (CEST)

Bonjour - tu veux dire autrement qu'en créant le modèle, trouvant les pages liées, effaçant le modèle ! Pas beau mais si ça vaut la peine... TIGHervé 1 août 2011 à 18:38 (CEST)

Il n'est pas nécessaire de créer le modèle pour utiliser le lien « Pages liées ». --Lgd (d) 1 août 2011 à 18:56 (CEST)

... à l'instant où j'ai vu ton pseudo dans ma liste, j'ai réalisé mon erreur. TIGHervé 1 août 2011 à 19:34 (CEST)

Modèle pour "fusionner" les entêtes

Comme pour {{palette}} où {{ébauche}} ou {{portail}}, je verrais bien pour des modèles comme {{Voir homonymes}}, {{Voir paronymes}}, {{Voir homophones}} un modèle qui permette de l'enlever le paramètre "border-bottom" qui fait apparaitre un trait sous chacun de ces modèle, de telle sorte qu'il n'y ait plus qu'un seul trait sous le paquet de modèle. Qu'en pensez vous ? Kyro ^{me parler} le 11 août 2011 à 23:46 (CEST)

IMHO, je pense qu'il faut retirer cette bordure car elle nuit à la lecture. ~Hlm Z. [@] 12 août 2011 à 02:49 (CEST)

Sur Jacques par exemple je trouve au contraire qu'elle est utile. Elle sépare le contenu de l'article de l'entête d'information. Plusieurs sont inutiles, 1 seule devrait suffire je pense. Kyro ^{me parler} le 12 août 2011 à 02:52 (CEST)

Tu penses à {{Voir multiple|homonymes|paronymes|homophones}}, c'est ça ? Je pense que ça serait une bonne idée ! — Mirgolth 12 août 2011 à 12:14 (CEST)

Si je prends l'exemple de l'article lire, tu le verrais donc ainsi ? ~Hlm Z. [@] 12 août 2011 à 12:26 (CEST)

Oui, chaque ligne commençant par un icône, la bordure est un peu inesthétique. Kyro ^{me parler} le 12 août 2011 à 13:02 (CEST)

On est bien d'accord. De plus, comme tu peux le voir ici, juste en dessous de "LIRE est l'abréviation de « liasse recommandée ».", il y a le modèle homophone qui créé également la bordure, mais ici, elle est inutile. Pourquoi la garder ? ~Hlm Z. [@] 12 août 2011 à 16:44 (CEST)

Ce genre de modèle on devrait le trouver en tête des articles. Le trait est utile si il est utilisé seul, mais sinon il faudrait l'inclure dans ce modèle multiple qu'il faudrait créer. Kyro ^{me parler} le 12 août 2011 à 16:46 (CEST)

Je viens de faire des essais concluant sur une de mes sous pages user:Kyro/bas. (+ mon user:Kyro/vector.css). La question c'est quel nom le donner ? Voir multiple est effectivement pas trop mal sachant que {{Voir}} redirige vers {{article détaillé}} et que cette redirection est utilisé par plus de 2000 articles. Kyro ^{me parler} le 12 août 2011 à 21:09 (CEST)

Bonjour,
Une solution plus simple et transparente pour les contributeurs (en évitant la création d'un modèle supplémentaire) : jouer sur la marge supérieure de ces modèles (négative) et sur l'arrière-plan (blanc) pour qu'en cas de modèles successif, chacun masque le filet inférieur du précédent. Cordialement, --Lgd (d) 12 août 2011 à 21:30 (CEST)

Hum je n'y avais pas pensé, et ça me semble bien mieux ! Je vais faire des tests. Kyro ^{me parler} le 12 août 2011 à 21:38 (CEST)

Ne trouvez-vous pas qu'avec cette modification le texte du bandeau est trop collé au titre de l'article ? On pourrait ajouter un léger padding-top, quelque chose entre 0.2 et 0.4 em, je trouve que cela rend bien, qu'il y ait un ou plusieurs bandeaux. od†n ↗^blah 13 août 2011 à 06:13 (CEST)

Toutafé, j'avais oublié de préciser le rattrapage du padding (je dois bouger common.css taleur pour autre chose, je ferais les deux du coup). Cordialement, --Lgd (d) 13 août 2011 à 08:35 (CEST)

Syntaxes anciennes

Bonjour,

Suite à une discussion sur le bistrot au sujet du modèle {{étymologie}}, je me suis posé la question de l'évolution des syntaxes. Je remarque que plusieurs modèles possèdent des "syntaxes anciennes" (par ex. {{Lang}}). Je n'ai pas d'idée du nombre de modèles concernés, mais le problème se pose dès qu'on veut changer la syntaxe d'un modèle, par ex. pour nommer les paramètres.

Il me semble que le maintien de ces syntaxes anciennes alourdit pas mal la gestion des modèles (redondance de code). Peut-être existe-t-il une solution standard ? Je ne l'ai pas croisée et je me suis donc creusé les méninges. Et voici ce à quoi j'ai pensé pour pallier ce problème (rien de magique, évidemment). Il s'agit d'un genre de procédure en cas d'introduction d'une nouvelle syntaxe :

1. Le modèle avec la nouvelle syntaxe seule serait créé sous la page "Modèle:<nom du modèle>/nouvelle syntaxe".
2. Le modèle courant serait modifié pour distinguer deux cas (par ex. test sur l'existence d'un paramètre, comme "texte" dans l'exemple donné ci-dessus) :
   1. si c'est ancienne syntaxe : catégorisation dans "Catégorie:Page utilisant une syntaxe dépréciée de <nom du modèle>" puis transmission des paramètres au "Modèle:<nom du modèle>/nouvelle syntaxe" ;
   2. si c'est la nouvelle syntaxe : transmission simple des paramètres (appel de "Modèle:<nom du modèle>/nouvelle syntaxe").

Le modèle courant deviendrait alors une simple porte d'entrée vers le modèle fonctionnel ("Modèle:<nom du modèle>/nouvelle syntaxe"). Il pourrait être remplacé par une simple redirection vers ce dernier (ou renommage) dès que la catégorie serait vide. Je pense faire un test sur le modèle {{étymologie}} s'il se dégage un consensus pour le modifier. Qu'en pensez-vous ? Cordialement.--Juju2004 (d) 12 août 2011 à 11:49 (CEST)

La procédure nécessite-t-elle vraiment le détour par la création en sous-page ? Cordialement, --Lgd (d) 12 août 2011 à 14:19 (CEST)

La sous-page sert à factoriser le code. Pour répondre, je vais essayer de préciser ma pensée par un exemple, celui du modèle {{lang}} (en supposant qu'on veuille passer exclusivement à la nouvelle syntaxe, ce qui n'est pas forcément toujours le cas). On a actuellement (j'indente pour la lisibilité) :

{{#if:{{{texte|}}}
    |<span class="lang-{{{1|}}}" lang="{{{1|}}}" {{#if:{{{dir|}}}|dir="{{{dir|}}}"}}>{{{texte|}}}</span>
        {{#if:{{{trans|}}}| (<span class="lang-{{{1|}}} transcription" lang="{{{1|}}}-Latn" dir="ltr">{{{trans|}}}</span>)}}
    |{{#switch:{{{1|}}}
        |ltr
        |rtl=<span class="lang-{{{2|}}}" lang="{{{2|}}}" dir="{{{1|}}}">{{{3|}}}</span>
        |#default=<span class="lang-{{{1|}}}" lang="{{{1|}}}">{{{2|}}}</span>
    }}
}}
{{#switch:{{{1|}}}||lat|mul|und|gr|gr-Latn|gr-latn|lu|jp|dk|oci=[[Catégorie:Page avec code de langue invalide]]}}

La redondance est manifeste, donc en cas de travail de maintenance, il y a risque d'erreur. Voici ce que je propose : le modèle devient un simple aiguilleur comme ceci :

{{#if:{{{texte|}}} <!-- nouvelle syntaxe : simple transmission de params -->
    |{{Lang/nouvelle syntaxe|{{{1|}}}|texte={{{texte|}}}|dir={{{dir|}}}|trans={{{trans|}}}}}
    |<!-- ancienne syntaxe : on catégorise -->[[Catégorie:Page utilisant une syntaxe dépréciée de lang]]
    {{#switch:{{{1|}}}
        |ltr
        |rtl={{Lang/nouvelle syntaxe|{{{2|}}}|texte={{{3|}}}|dir={{{1|}}}}}
        |#default={{Lang/nouvelle syntaxe|{{{1|}}}|texte={{{2|}}}}}
    }}
}}

Et voila la page "Modèle:Lang/nouvelle syntaxe" ou on peut se concentrer sur le contenu du modèle :

<span class="lang-{{{1|}}}" lang="{{{1|}}}" {{#if:{{{dir|}}}|dir="{{{dir|}}}"}}>{{{texte|}}}</span>
    {{#if:{{{trans|}}}| (<span class="lang-{{{1|}}} transcription" lang="{{{1|}}}-Latn" dir="ltr">{{{trans|}}}</span>)}}
{{#switch:{{{1|}}}||lat|mul|und|gr|gr-Latn|gr-latn|lu|jp|dk|oci=[[Catégorie:Page avec code de langue invalide]]}}

Plus le modèle est complexe, plus l'utilisation d'une sous-page devient intéressante. C'est une manière de séparer le contenu du modèle de la gestion des syntaxes. Mais il y a peut-être une autre solution qui m'échappe...--Juju2004 (d) 12 août 2011 à 15:08 (CEST)

PS. En relisant les différents codes, je viens de trouver un bug dans le modèle actuel : le switch qui permet de catégoriser les codes langues invalides teste le paramètre {{{1}}}, même si c'est le {{{2}}} qui contient le code langue (cas ancienne syntaxe où le paramètre {{{1}}}=ltr ou rtl). La correction de ce bug nécessite de réintroduire ce switch à deux endroits supplémentaires. C'est pour éviter ce genre de problèmes qu'il est intéressant de factoriser !--Juju2004 (d) 12 août 2011 à 15:21 (CEST)

En effet, l'exemple est probant. Cordialement, --Lgd (d) 12 août 2011 à 18:36 (CEST)

Bonjour, deux petites remarques :

• Tout d'abord, je ne pense pas que l'« ancienne » syntaxe soit amenée à disparaître : la syntaxe « {{lang|en|blah blah}} », est pleinement satisfaisante, et j'imagine mal demander aux contributeurs de passer à « {{lang|en|texte=blah blah}} » juste parce que c'est la Nouvelle Syntaxe, alors que je ne vois pas de valeur ajoutée dans ce cas (à part de la longueur de wikitexte).
• Ensuite un petit détail technique sur le code, il faudrait faire « {{Lang/nouvelle syntaxe|1={{{1|}}}|…}} ». Comme ça, si par un exemple un contributeur fait « {{lang | en | blah blah}} », on ne se retrouve pas avec en résultat un « <span class="lang- en "> » évidemment erroné.

od†n ↗^blah 12 août 2011 à 21:28 (CEST)

Oui, ce qui est probant est l'idée générale concernant la manière de gérer les évolutions de syntaxe. Pour le modèle pris en exemple, ce n'est qu'un exemple (à ne pas appliquer). Cordialement, --Lgd (d) 12 août 2011 à 21:34 (CEST)

@Od1n : le cas présenté (modèle {{lang}}) n'était qu'un exemple. Néanmoins, même en conservant plusieurs syntaxes autorisées, je me rends compte que la gestion du modèle est facilitée par cette solution. Ce n'est pas une question de longueur de wikitexte, mais bien de n'écrire qu'une fois la partie fonctionnelle du modèle pour limiter les erreurs. Sur le détail technique, et dans le cas où on veut effectivement substituer une syntaxe à une autre, l'idée est justement de ne pas mettre "1=", car alors la substitution de "<modèle>/nouvelle syntaxe" à "<modèle>" (lorsque l'ancienne syntaxe aura disparu) entraînerait le type d'erreur que tu mentionnes (plus de trim automatique).--Juju2004 (d) 12 août 2011 à 21:50 (CEST)

Je suis d'accord avec l'idée, dès que le code d'un modèle est moins concentré sur ses traitements métier, la maintenance s'en retrouve considérablement compliquée. J'ai deux exemples pour étayer le propos :

• On trouve parfois des infoboxes avec du « code autodocumenté » : « {{{nomparametre|<noinclude>-</noinclude>}}} ». Le code du modèle n'est pas encadré par des <includeonly>, et donc en haut de la page du modèle apparaît une infobox complète et remplie de « - ». Le problème est que le code est affreusement difficile à lire, et j'ai l'impression générale que de telles infoboxes sont beaucoup moins maintenues.
• On a aussi le cas des copier-collers de {{Cite book}}, {{Cite web}}, etc. depuis des articles du wiki anglophone. C'est vrai que si notre wiki est capable de les reconnaître, c'est un gain de confort appréciable pour le contributeur, en attendant que le modèle soit manuellement (ou par bot, qui sait) transposé en version locale. Évidemment, la transposition n'est que rarement possible en 1 → 1, il y a toujours des différences de fonctionnement. Donc, dans le cas de {{Cite book}}, le modèle est une surcouche de compatibilité qui transmet les paramètres à {{Ouvrage}} ; dans le cas de {{Cite web}}, c'est une simple redirection vers {{Lien web}}, le code de compatibilité est donc dans {{Lien web}}. L'approche {{Cite book}} me semble bien meilleure, les codes étant clairement séparés, la seule difficulté étant qu'il faut veiller à maintenir celui-ci plus ou moins à jour (de tels modèles sont généralement assez délaissés). Enfin, on a un problème si les modèles FR et EN portent le même nom… exemple {{Allmusic}} ; et on pourrait appliquer la proposition de Juju2004 (d · c) dans un tel cas de figure.

od†n ↗^blah 12 août 2011 à 22:06 (CEST)

L'exemple de {{Cite book}} est particulièrement pertinent en ce qu'il montre que la décomposition aiguilleur de syntaxe/modèle "fonctionnel" (ou "métier") que je propose dans un cas particulier :

• existe déjà ailleurs (c'est toujours rassurant)
• est d'application beaucoup plus générale que le changement de syntaxe.

En particulier, tous les cas de syntaxes multiples pourraient être décomposés ainsi. Le problème de ce genre de solution "idéale" est qu'elle ne l'est que du point de vue des techniciens, et pas du point de vue des contributeurs non techniciens. Or tout ce qui ne favorise pas la tâche de ces derniers est à utiliser avec d'infinies précautions.

Ceci dit, pour des modèles complexes et mutlisyntaxe, il pourrait être intéressant d'envisager cette décomposition : ces modèles étant souvent impossibles à gérer pour des non techniciens, autant simplifier le travail des techniciens. Cela pourrait prendre la forme d'une sous-page "<nom du modèle>/métier" qui contiendrait le modèle métier avec tous les paramètres nommés. Tous les raccourcis de syntaxe seraient gérés en amont par un aiguilleur. Ces aiguilleurs métier seraient catégorisés et fourniraient un lien sur une page de documentation adéquate type "Aide:Modèle métier". Serait-il intéressant de faire une tentative sur un modèle particulièrement lourd et pas trop utilisé ?

A part ça, par curiosité : pour ce qui est des infoboxes autodocumentées, pourrais-tu donner un exemple précis ? je n'ai pas trouvé.--Juju2004 (d) 13 août 2011 à 12:59 (CEST)

Uniformisation des intitulés de modèles d’homonymie

ƝEMOI – Bonjour à tous. Il m’a une nouvelle fois fallu quatre essais pour retrouver le titre du modèle : homonymie édifice religieux, alors je craque. Nous avons dans la catégorie : Bandeau pour page d'homonymie quatre tendances :

• Homonymie machin ;
• Homonymie de machin ;
• Homonymie de machins ;
• Machins homonymes ;

serait-il possible de réussir à obtenir un consensus pour en supprimer, disons, au moins deux des quatre ? le dernier est préférable à mon avis. Ce 22 août 2011 à 13:43 (CEST).

Pour. Préférence pour le deuxième. La convention (notamment de catégorie) recommande le singulier. LD ^{• m'écrire •} 25 août 2011 à 16:19 (CEST)

Erreurs et avertissements

Bonjour,

Suite à cette discussion (et parce que j'ai besoin de ce genre de fonctions pour des modèles sur lesquels je travaille), j'ai créé quelques fonctions pour gérer les erreurs et les avertissements dans les modèles : voir la page {{Fonctions modèle}}. J'ai rassemblé ces fonctions dans des sous-pages car :

• cela permet de rassembler les fonctions du même domaine ;
• ces fonctions ne sont pas destinées à être utilisés directement dans le main : dans une sous-page, elles ne polluent pas l'espace "Modèle".

Je ne sais pas si la forme ou le contenu sont les bons, mais il me semble qu'il est intéressant d'essayer d'unifier la manière dont les modèles gèrent ces situations afin de faciliter les travaux de maintenance. Cordialement.--Juju2004 (d) 1 septembre 2011 à 10:45 (CEST)

Modèle : Route nationale 85

ƝEMOI – Bonjour à tous. Je n’arrive pas à me convaincre de la pertinence de ce modèle. Avez-vous des suggestions ? ce 3 septembre 2011 à 00:46 (CEST).

Lien ancré vers un titre contenant un modèle

Bonjour,

J'ai un problème avec le modèle {{sp-}} qui semble rendre impossible la création de liens ancrés.

Par exemple, l'article Provinces-Unies contient une section intitulée « Les Provinces-Unies aux XVII^e et XVIII^e siècles ». Dans le code HTML, l'id associé à la section est « Les_Provinces-Unies_aux_XVIIe+et+XVIIIe.C2.A0si.C3.A8cles ». Dans ce titre, les siècles sont écrits à l'aide de {{s2-}}, qui fait appel à {{sp-}}. L'id contient des '+' autour du mot « et » car les espaces sont écrites avec &#32; dans le modèle {{sp-}}. Or les + sont automatiquement encodés dans les liens ancrés. Et donc Provinces-Unies#Les_Provinces-Unies_aux_XVIIe+et+XVIIIe.C2.A0si.C3.A8cles ne pointe pas vers le bon paragraphe.

Est-il possible de générer l'espace autrement dans le modèle, pour que les id de titre contiennent un _ au lieu d'un + ?

Orlodrim ^[discuter] 4 septembre 2011 à 13:29 (CEST)

Refonte du projet

Bonjour ! Je suis en train de faire un refonte du projet concernant l'archivage et la méthode de traitement des requêtes, afin de savoir ce qui reste à faire et ce qu'il y a à faire. LD ^{• m'écrire •} 4 septembre 2011 à 14:14 (CEST)

Je peux mettre un archivage, mais vu qu'il y a 4 requêtes par mois, il me semble qu'on peut d'abord simplifier la mise en page, non ?

• Enlever le découpage en trois sections traité/refusé/en cours.
• Archiver une demande lorsqu'elle est marquée comme traitée et n'a pas été modifiée depuis un mois.

Ensuite, déplacer des sections vers Projet:Infobox/Demande création infobox un autre projet n'est pas une tâche de bot à mon avis (repérer en fonction d'un mot dans le titre n'est pas un critère assez précis ; de plus il ne faut pas transférer n'importe quoi, il peut y avoir simplement des erreurs de débutant).

Orlodrim ^[discuter] 4 septembre 2011 à 15:24 (CEST)

D'accord avec les deux premiers points, je déplace les demandes d'infobox. LD ^{• m'écrire •} 4 septembre 2011 à 17:51 (CEST)

Je reviens sur ce que j'ai dit : c'est plus simple pour moi de garder le format qui existe déjà en séparant requêtes traitées et refusées. Ainsi c'est quasiment identique à l'atelier graphique. Mais en l'état actuel, la plupart des requêtes n'ont pas de modèle dans le titre indiquant leur statut. Il faudrait commencer par faire un tri manuel. Orlodrim ^[discuter] 8 septembre 2011 à 20:51 (CEST)

Ligne de transport en commun

Hello, je voudrais savoir s'il existe un modèle pour détailler une ligne de transport en commun sans avoir à créer le tableau (dans un style similaire à Lignes de bus RATP de 20 à 99#Lignes 20 à 29). J'ai demandé sur le projet transport en commun et transport en idf mais sans réponse. --Jesmar (d) 7 septembre 2011 à 21:12 (CEST)

Modèles antédiluviens

Bonjour,

Je suis tombé dernièrement sur les modèles {{floor}}, {{ceil}}, {{round}} et {{div}} qui réalisent des opérations a présent directement gérées par les ParserFunctions. Je me propose de faire un peu de ménage, et de substituer (au cas par cas) les opérations des PF à ces modèles. Y a-t-il des objections ou quelque chose à quoi je n'aurais pas pensé ? Cordialement.--Juju2004 (d) 9 septembre 2011 à 14:45 (CEST)

Évidemment, le modèle {{div}} (division entière), qui ne fait pas partie des opérations directement gérées, ne peut pas être remplacé comme proposé ! C'est le modèle {{mod}} que j'avais en tête. Pour ce qui est de {{div}}, le code pourrait être simplifié comme ici : Utilisateur:Juju2004/Brouillons/Modèles/div. Le comportement est exactement le même que celui du modèle actuel, à cela près qu'il génère une erreur en cas de division par zéro (ce qui me semble tout à fait légitime). Pour les autres modèles, je travaille à partir des modèles qui les incluent, de manière à recoder ces modèles sans modification fonctionnelle. Par exemple Utilisateur:Juju2004/Brouillons/Modèles/DMS pour {{DMS}} qui utilise {{round}}. Pour ce qui est de {{ceil}}, il n'est pas utilisé, et {{floor}} n'est inclus dans {{DAYISO}} que pour gérer, au niveau des jours, les numéros... non entiers . Le seul réel problème est {{rand}}, qui fait un usage des modulo sur des nombres entiers très grands, ce que PHP gère mal (retour de nombre négatifs en cas d'overflow). Je travaille également à un nouveau codage du modèle. Des avis ou suggestions ?--Juju2004 (d) 12 septembre 2011 à 23:03 (CEST)

Pour le modèle {{rand}}, il semble que ce soit réglé : Utilisateur:Juju2004/Brouillons/Modèles/rand a (pour des raisons que je ne sais pas expliquer) une variance (VA = n |-> nombre de fois où n est sorti) entre 8 et 10 fois inférieure au modèle actuel (pour 100 000 tirages ou moins ; à partir d'1 million, ça s'inverse un peu...), et surtout les suites sont plus variées dans tous les cas testés. Remarque : j'ai utilisé une méthode de bourrin pour tester la variété des suites : envoyer les nombres dans l'ordre dans un fichier, puis le zipper. Celui qui prend le moins de place en ZIP a les suites les plus répétitives (à ma connaissance, ZIP utilise le Codage de Huffman). Si quelqu'un a mieux....--Juju2004 (d) 13 septembre 2011 à 11:25 (CEST)

Voilà, c'est presque fini. Merci en passant à Hercule et Like tears in rain pour leur assistance. Il ne reste que deux points que j'ai soulevé en passant : une proposition de simplification du modèle DMS et une demande sur le modèle Coord. A chaque fois, si les modifications proposées sont acceptées, l'intervention d'un admin serait nécessaire. Cordialement.--Juju2004 (d) 6 octobre 2011 à 19:19 (CEST)

Convention de nommage des paramètres

Bonjour,

Je vois qu'il existe deux modèles qui ont la même fonctionnalité et ont un résultat identique (ou du moins suffisamment similaires pour être considérés identiques) : {{Liste d'épisodes}} et {{Liste des épisodes}}. Le premier utilise des noms de paramètres explicites (par exemple : « autre diffusion »), le second des noms abrégés mélangeant le français et l'anglais (par exemple : « AltDate », « TopColor »). D'autres différences existent : le second modèle a davantage d'options et est mieux documenté. En terme d'utilisation, le premier est largement plus utilisé que le second.

En tant que membre du projet des séries télévisées, je crois qu'il est bon de ne garder qu'un seul des deux modèles. Dès lors je voudrais demander au projet lequel garder et comment faire pour « fusionner » les deux modèles. On fera la fusion plus tard, mais je voudrais déjà avoir quelques indications sur la marche à suivre.

En vous remerciant d'avance. — Frór ^Oook? 12 septembre 2011 à 13:12 (CEST)

{{Liste d'épisodes}} est le plus vieux mais compte 19 inclusions contre {{Liste des épisodes}} compte 44 inclusions.

Au niveau du nom, mieux vaut éviter l'apostrophe.

Après, je conseillerais d'abord de créer le modèle qu'il vous convient le mieux ; ensuite un coup de fusion d'historique et un bot pour changer les appels aux paramètres et c'est réglé -- Xfigpower (pssst) 28 septembre 2011 à 14:22 (CEST)

Ok. La réponse fut longue, mais merci . Qu'en est-il des noms des paramètres à proprement parler ? Quel type de nommage de paramètres est le meilleur ? — Frór ^Oook? 28 septembre 2011 à 15:26 (CEST)

Voilà qui règle en partie ton problème Fror. Cordialement ~Hlm Z. [@] 28 septembre 2011 à 16:35 (CEST)

Effectivement. Merci à nouveau ! — Frór ^Oook? 28 septembre 2011 à 16:46 (CEST)

Classes CSS pour Boîtes déroulantes

ƝEMOI – Il y a dans MediaWiki:Common.css, dans les « Classes pour Boîtes déroulantes », les deux entrées :

.collapseButtonHide {
background-image: url(http://upload.wikimedia.org/wikipedia/en/9/99/ArrowUpNavbox.gif);
}
 
.collapseButtonShow {
background-image: url(http://upload.wikimedia.org/wikipedia/en/7/7b/ArrowDownNavbox.gif);
}

dont les url ont mourru (transfert ailleurs (sur Commons ?), ici et là). Voyez-vous un moyen de trouver quel était l’usage de ces classes, pour savoir s’il vaut mieux retirer ou mettre à jour ? J’ai failli poser la question au projet : Charte graphique, qui m’aurait semblé le plus adapté, mais vu l’absence de réponse à ma dernière question là-bas, je me demande s’il est très utilisé… D’autres idées de lieux où poser ce genre de questions ? Ce 12 septembre 2011 à 22:15 (CEST).

P.-S. : a aussi mourru :

http://upload.wikimedia.org/wikipedia/fr/6/68/Bandeau_portail_cin%C3%A9ma.png

lien rompu suite à des transfert sur commons. -- Xfigpower (pssst) 26 septembre 2011 à 17:14 (CEST)

Comment créer un bouton signature n° d'utilisateur

Bonjour, voilà une question un peu particulière qui concerne plus mediawiki... Mais voilà, je voudrais savoir si quelqu'un ici est capable de créer un bouton qui permettent de signer non pas par notre pseudonyme mais par notre "Numéro d’utilisateur" (celui affiché dans nos "Préférences"). En effet si, c'était possible je me disait que l'on pourrait enfin avoir sur WP un système de vote anonyme. Ce qui pourrait être intéressant pour certains votes... amicalement--Wikialine (d) 29 septembre 2011 à 18:09 (CEST)

Uniquement au point de vue technique (sans entrer dans les considérations d'opportunité du vote anonyme) : en gros, c'est possible, et plutôt en JavaScript qu'avec un modèle. Mais cela pose un double problème :

• le pseudonyme sera inscrit de tout manière dans l'historique de la page ;
• comment vérifier que l'identifiant (numéro d'utilisateur) fourni n'est pas bidon tout en gardant l'anonymat ?

Ce qui se rapproche le plus de ce que tu souhaite serait de généraliser le vote sous IP, mais avec les IP dynamiques (donc partagées), on risque d'empêcher de voter des personnes qui n'ont pas encore voté ou de permettre à certains de voter plusieurs fois (après changement d'adresse). Donc, je crois, pas de solution simple à cette question, mais n'hésite pas à poser la question au Projet:Javascript.--Juju2004 (d) 29 septembre 2011 à 20:14 (CEST)

Rien n'est anonyme sur WP. A partir de là, ton idée est ptet louable pas mais réalisable. Kyro ^{me parler} le 29 septembre 2011 à 20:21 (CEST)

La solution passe plutôt par une extension Mediawiki (il me semble que les élections de l'Arbitration Committee se font avec mw:Extension:SecurePoll ; le vote est secret mais la liste des votants est rendue publique). Orlodrim ^[discuter] 29 septembre 2011 à 20:41 (CEST)

Si on pouvait voter en signant par notre "Numéro d’utilisateur", on éviterait bien des problèmes. Voter par IP j'y avait pensé mais avec les IP dynamique, ça pose soucis. Donc il reste "Numéro d’utilisateur" qui est unique par wikipédien inscrit. A la rigueur si on pouvait interdire l'accès à l'historique (sauf pour les bureaucrates...) pour certains types de pagesde votes... En tout cas, c'est une idée qui mériterait d'être creuser. Ce serait plus sain pour les rapports entre wikipédiens. Il y aurait moins d'esprits revanchards, moins de coups bas... J'en suis convaincu. Si quelqu'un pouvait déjà me créer un gadget javascript permettant l'ajout d'un bouton signature anonyme (qui ferait apparaitre le n° d'utilisateur". Comme ça je pourrai faire part à la communauté de mon idée concernant la mise en place d'un vote anonyme... Merci par avance. amicalement--Wikialine (d) 30 septembre 2011 à 22:09 (CEST)

Mise à jour automatique de données démographiques

Bonjour, au sein du projet communes de France, on a commencé à plancher sur un système de mise à jour automatique de données. Si certains modélistes pouvaient apporter leur aide pour le développement du système, n'hésitez pas à venir sur cette page : Projet:Communes de France/Mise à jour automatique des données démographiques

Amicalement--Wikialine (d) 29 septembre 2011 à 18:28 (CEST)

L'idée semble intéressante. Je vais regarder ça.--Juju2004 (d) 29 septembre 2011 à 20:15 (CEST)

Le plus urgent c'est de finir le modèle:Graphique Population Commune. Je manque de temps pour le finaliser et sans la qualité d'admin je ne peux pas faire des essais au niveau des class CSS. Au niveau du bot ça devrait aller j'ai eu des résultat intéressant. Il n'y a plus que le modèle Graphique Population Commune qui pose encore problème (ajout de la graduation derrière les colonnes, ajout des valeurs aux axes X et Y... merci par avance à tous. amicalement--Wikialine (d) 29 septembre 2011 à 23:10 (CEST)

Le plus urgent, c'est de voir si tu es dans la bonne direction. Il y a pas mal de choses à étudier avant de graver dans le marbre un système auquel plus personne n'osera toucher ensuite. Si les choix faits maintenant sont mauvais, on va traîner le problème pendant des années. Je comprends bien ton impatience, mais j'ai vu des points à discuter (le format des données par ex.). Je vais te mettre ça en page de discussion dès j'aurai le temps. Pour ce qui est de faire des tests CSS, pas besoin d'être admin (je ne le suis pas plus que toi) : Utilisateur:Wikialine/common.css.--Juju2004 (d) 30 septembre 2011 à 11:34 (CEST)

Modèle:Langname

Le Modèle:Langname est un doublon de Modèle:Langue-local et un quasi-doublon de Modèle:Nom langue. Voir aussi Wikipédia:Questions techniques/semaine 37 2011#effacer le code wiki. Visite fortuitement prolongée (d) 29 septembre 2011 à 22:37 (CEST)

Récupérer la fin d'un paramètre

Résolu.

Salut les modélistes, pour perfectionner un modèle, j'aimerais pouvoir récupérer l'année à partir de la date rentrée sous le format jj/mm/aaaa. Savez vous s'il est donc possible de récupérer les 4 derniers caractères d'un paramètre ? À bientôt. – Lucio 31/fr 3 octobre 2011 à 18:32 (CEST)

Salut. Pour ce genre d'opérations, tu as le mot clé #titleparts qui te permet de récupérer des morceaux séparés par des slashes : voir mw:Help:Extension:ParserFunctions#.23titleparts. Sinon, à ma connaissance, pas de solution pour récupérer les quatre derniers caractères d'un paramètre.--Juju2004 (d) 3 octobre 2011 à 19:41 (CEST)

Astucieux. J'avais survolé cette fonction sans y prêter plus attention (et sans tout comprendre). Je vais voir ce que ça peut donner ce soir ou demain.

Merci Juju.

– Lucio 31/fr 3 octobre 2011 à 20:45 (CEST)

Développé sur Utilisateur:Lucio_fr/M1, mis en place sur /M2 et testé sur /M3

C'est nickel. Merci – Lucio 31/fr 4 octobre 2011 à 11:25 (CEST)

Remarque du comte Ɲemoi – Je signale en passant que le Lexique des règles typographiques en usage à l’Imprimerie nationale recommande d’écrire les dates sous format jj-mm-aaaa et non pas avec des slashs. Avec sympathie, ce 3 octobre 2011 à 20:48 (CEST).

Je ne l'ai jamais vue écrite comme ça, la date. M'enfin, si tu le dis, ce doit être vrai. Cela dit, ce n'est appliqué nulle part et on ne commencera pas dans les articles de tennis. – Lucio 31/fr 3 octobre 2011 à 21:06 (CEST)

Proposition de refonte de la gestion des bandeaux de portail

Bonjour,

J'ai initialisé une discussion sur la gestion des bandeaux de portail. Pour l'instant ce n'est qu'une réflexion, et une décision passerait par un sondage. N'hésitez pas y participer, notamment pour relever des problèmes non identifiés ou pour proposer d'autres alternatives techniques.

Cordialement,

Simplification d'un modèle : utile ? Quelle procédure suivre ?

J'ai initialement posé les questions suivante sur WP:Question technique. Sans réponse et après un passage par le bistrot, Nemoi (d · c · b) et Arkanosis (d · c · b) m'ont redigé ici.

Modèle(s) concerné(s) : {{CIO-d}}

Questions : Ce modèle doit être très utilisé. J'ai remarqué en analysant le code qu'il faisait appel au parser #switch pour deux exceptions évitables :

• USA ne doit pas être utilisé car le modèle {{USA-d}} est correctement écrit,
• Northern Ireland est utilisé par le modèle {{NIR-d}}, mais celui-ci est sans doute peu utilisé et pourrait être ré-écrit pour être lié directement au fichier Ulster banner.svg ou au modèle {{drapeau}}.

Si j'ai bien compris la présence de parser augmente l'utilisation des serveurs Wikipedia et peut augmenter le temps d'affichage d'une page lorsqu'un modèle est répété un grand nombre de fois. (environ 500 fois ici par exemple, mais je suis sûr qu'il y a pire)

• Faut-il se préoccuper de simplifier le code d'un tel modèle ou est-ce un goutte d'eau ?
• Si oui, je peux modifier le modèle NIR-d. Mais avant de modifier le modèle CIO-d, il faut vérifier s'il n'y a pas d'utilisation que je n'ai pas envisagée des codes "{{CIO-d|USA..." et "{{CIO-d|Northern Ireland...". Comment faire cette recherche ? puis-je la faire moi-même ou faut-il demander sur Wikipédia:Bot/Requêtes ou ailleur ?
• Pour finalement modifier le modèle CIO-d qui est protégé, faut-il seulement mettre un commentaire dans la page de discussion (sachant que ce n'est pas urgent) ou vaut-il mieux demander sur WP:DIPP ?

Puis-qu'a priori je suis cette fois-ci au bon endroit j'ajoute :

• Connait-on le cout relatif des différentes fonctions. il semble d'après les discussions du modèle {{date}} que #ifexist est lourd pour les serveurs, mais quid des autres ?

-- Zebulon84 (d) 11 octobre 2011 à 23:14 (CEST)

Cool, finalement, je crois que j'ai réponse à toutes tes questions .

1. Sur les performances : non, tu n'as pas à te soucier des perfs des serveurs ; c'est le boulot des admin sys qui autorisent / interdisent certaines choses en fonction des perfs et déterminent les limites autorisées dans la configuration de MediaWiki.
2. Du coup, connaître le coût des fonctions n'est pas utile.
3. Tu dois par contre optimiser si on atteint les limites spécifiées dans la conf (message d'erreur).
4. Ainsi que la taille de la page envoyée aux clients.
5. Et la clarté du code pour les contributeurs.
6. Je peux m'occuper de la recherche (quand j'aurai un ordi sous la main).
7. Et de l'édition du modèle, pourvu que la demande soit précise et consensuelle (sinon, effectivement, DIPP est la bonne page).

Pour info, un modèle appelé plusieurs fois sur la même page avec les mêmes paramètres n'est calculé qu'une seule fois.

Amicalement — Arkanosis ^✉ 12 octobre 2011 à 01:15 (CEST)

Donc si je comprend bien c'est presque inutile mais tu vas t'en occuper. Merci. J'ai donc modifié {{NIR-d}} pour utilisé {{drapeau}} au lieu de {{CIO-d}}. Si la recherche ne donne aucun résultat je propose comme nouveau code ceci pour CIO-d :

<includeonly><span class="flagicon">[[Fichier:Flag of {{{1}}}.svg|{{{3|20px}}}|border|Drapeau : {{{2}}}]]</span></includeonly><noinclude>


{{/Documentation}}


</noinclude>​

Zebulon84 (d) 12 octobre 2011 à 12:14 (CEST)

Une recherche dans l'intégralité des pages de Wikipédia ne m'ayant pas permis de trouver une autre utilisation que celle que tu as remplacée, j'ai procédé à la simplification du modèle et prévenu les deux projets concernés afin de nous remonter tout problème lié à cette modification.

Amicalement — Arkanosis ^✉ 16 octobre 2011 à 18:39 (CEST)

Modèle:Infobox V3/Tableau Ligne mixte, les unités (et autres questions)

Question du comte Ɲemoi – Je suis souvent confronté à des cas de lignes mixtes avec des unités (hab., km², etc.). Or, cela impose pour le moment une syntaxe de type :

{{Infobox V3/Tableau Ligne mixte|{{{fou}}}|{{{barre}}} {{abréviation discrète|hab.|habitants}}|if={{{barre|}}}}}

ce qui est assez barbant. Je préfèrerais un :

{{Infobox V3/Tableau Ligne mixte|{{{fou}}}|{{{barre|}}}|unité=hab.}}

comme vous pouvez vous en douter (notez les subtilités de la syntaxe, sur l’absence d’appel de modèle… lisez donc la suite). Ne pourrait-on pas ajouter un champ « unité » ? si oui :

1. comment le nommer ? pourquoi d’ailleurs les paramètres des infobox V3 sont en anglais ?! dans le peu que j’ai corrigé, j’ai déjà été confronté à des utilisateurs remplaçant « legend » par « légende »…
2. doit-on attendre une valeur du genre {{abréviation discrète|hab.|habitants}}, ou doit-on demander une valeur du genre hab. et gérer automatiquement l’abréviation discrète (avec pour la maintenance une catégorie : unité inconnue) ? faire un modèle qui renvoie une unité avec l’abréviation discrète de gérée permettrait en passant de l’incorporer au modèle : unité et d’améliorer ainsi grandement l’accessibilité de nombreux articles…

Que pensez-vous de tout cela ? Ce 14 octobre 2011 à 00:53 (CEST).

Avant d'utiliser les V3 n'importe où, il serait souhaitable de fusionner les briques des V2 avec les V3. Au sein du projet infobox on avait fait un gros travail d'harmonisation à ce niveau là. Si il y a un admin modéliste ici qui veut bien se charger de ce type de fusion complexe ce serait bien. J'avais proposé en vain que lgd améliore les V2 mais bon il a préféré imposer ses modèles, Il n'y a eu aucune véritable discussion de fond et de forme sur ces infoboxes V3. Ces modèles étant plus complexes que les briques des infoboxes standards actuelles. Il serait donc vraiment souhaitable d'harmoniser les briques avant de continuer à semer les V1, V2 et V3 (bientôt V4, V5, V6...) un peu de partout. J'essaie d'expliquer l'intérêt qu'il y a à utiliser un seul type d'infobox et de si besoin est les améliorer plutôt que de créer sans cesse de nouveaux modèles, mais le message peine à passer ces derniers temps. En tout cas bon courages aux nouveaux modélistes. amicalement--Wikialine (d) 14 octobre 2011 à 20:48 (CEST)

Je tiens à préciser que la V3 n'est pas plus complexe que toutes autres (cad v1 et v2). Je plussoye Wikialine sur le fait de créer des "versions" de modèle. Un modèle d'infobox unique (pas de v1, v2, v3) serait une avancée majeure (simplification, nettoyage du Commons.css...). ~Hlm Z. [@] 14 octobre 2011 à 21:28 (CEST)

Si déjà les v1 avait été supprimée quand la v2 a été créée... --'toff ^[discut.] 6 novembre 2011 à 03:26 (CET)

Réponse du comte Ɲemoi – Dès qu’il n’y aura que des infoboîtes construites par briques, ça commencera à valoir le coup de se demander comment on jongle avec la cinquantaine de modèles au total pour obtenir un tout cohérent. Moi, l’objectif que je me donne, c’est d’éliminer les déchets, les boîtes construites à l’arrache ; ma méthode, c’est de passer par le Common.css et de repérer les classes quasi-inutilisées, pour les rendre obsolètes et les supprimer, en remplaçant par des V3 ; actuellement, je m’occupe des dernières hiddenStructures. Si vous voulez faire évoluer les infoboîtes pendant ce temps, n’hésitez pas ; en attendant, j’ai rapporté des problèmes concernant les V3, ce serait une chouette idée que j’ai votre avis sur les solutions que je propose. Avec sympathie, ce 14 octobre 2011 à 23:22 (CEST).

Renommage du modèle : Terme défini

Notification du comte Ɲemoi – Dès les discussions sur la première prise de décision, il est apparu qu’un modèle incluant la balise <dfn> serait plus acceptable sous le nom de modèle : Sujet que sous celui de modèle : Terme défini (plus court et au moins aussi clair). D’autres propositions ont également été faites par-ci–par-là. Je propose de clarifier tout ça dans cette section, à vos avis ! ce 25 octobre 2011 à 16:50 (CEST).

Problème avec Modèle:GeoGroup et Modèle:KML

Bonjour. Comme signalé avant-hier sur le bistro, le lien vers OSM de ces deux modèles ne fonctionne pas. Je suis du même avis que Gonioul, c'est-à-dire que si aucune solution pour réparer ce lien n'est envisagée rapidement, il faudrait tout simplement le supprimer (à noter que l'équivalent utilisé sur la version en anglais de Wikipédia n'a pas de lien vers OSM). Cordialement, Freewol (d) 26 octobre 2011 à 15:38 (CEST)

Petits drapeaux en hiver 1980

Message du comte Ɲemoi – Le système des petits drapeaux est buggué, et il y a un gros travail à faire pour le corriger : le modèle : Drapeau2/Image/JO1980 doit pouvoir prendre un paramètre « année= » de valeur « hiver 1980 », comme on le voit dans le dernier exemple de la documentation du modèle : ENF. Il est appelé pour cela, via le modèle : Drapeau2, par le modèle : Drapeau2/Image. Or, ce dernier appelle le modèle : Drapeau2/Image/France (par exemple, marche avec toutes les nations n’ayant pas défilé sous leur drapeaux aux JO d’été de 1980) qui fait une comparaison d’années. Oui, « hiver 1980 » se compare très mal avec « 1830 ». Une idée ? (un conseil, n’essayez pas de vous y plonger… je vous aurai prévenu). Ce 30 octobre 2011 à 22:36 (CET).

Exportation des pages de modèles

Bonjour,

Je pense avoir cherché partout mais je n'ai pas trouvé comment exporter convenablement des modèles pour les utiliser sur un Médiawiki local. J'exporte bien les pages de ma liste, mais à l'importation aucun des modèles n'est opérationnel. Un modèle est bâti avec d'autres modèles et ainsi de suite sans finalement, pouvoir identifier tous ses composants en cascade. C'est peut-être possible mais je ne sais pas comment faire. Merci pour votre aide. --PatSchW (d) 5 novembre 2011 à 12:44 (CET)

Mise à jour de {{DVDBibliographie}}, {{Extrait vidéo}} et {{harvsp}} ?

Bonjour à tous. J'ai regardé les modèles {{DVDBibliographie}} et {{Extrait vidéo}} et il me semble qu'on peut les améliorer de plusieurs manières. Ils offrent pas la possibilité de choisir plusieurs réalisateurs, producteurs et scénaristes. Ils n'affichent pas la durée du document, ne permettent pas d'afficher le libellé et pourraient contenir un lien vers l'IMDb ou AllRovi, par exemple. Pour le modèle {{harvsp}}, ça relève du détail, il serait bien d'avoir un paramètre min= pour renvoyer aux minutes dans les films et extraits vidéos. Qu'en pensez-vous ? Mëka ^Parler 16 novembre 2011 à 17:48 (CET).

Documentation des modèles, modèles de documentation

En tête de page se trouve un début intéressant de discussion au sujet de la documentation des modèles (en particulier, leur implémentation et la prolifération de modèles à cet effet). J’ai l’impression qu’il n’y a guère eu de progrès en la matière depuis cette brève conversation, entamée il y a presque deux ans.

Il n’y pas que l’implémentation qui cloche, à mon avis, mais aussi le résultat. Quand on regarde un modèle, on devrait immédiatement faire face à une documentation abordable et destinée à l’utilisateur potentiel du modèle. Dans les faits, on fait face à un étalage de messages en boite qui relègue la véritable documentation (ce que l’utilisateur veut lire) en bas de page.

Exemple classique :

La documentation de ce modèle est consignée ci-dessous, elle vous permet de l’utiliser convenablement. Pour en savoir plus, veuillez utiliser sa page de discussion. Le code effectif de la documentation se trouve sur sa sous-page de documentation [modifier]. Voir la liste des modèles. Cliquez ici pour purger le cache lorsque vos modifications n’apparaissent pas.

Ce modèle emploie des fonctionnalités nécessitant des connaissances avancées dans le domaine des modèles. Veuillez ne pas tenter de le modifier à moins que vous ne soyez certain de bien comprendre sa conception et êtes préparé à réparer tous les dommages collatéraux si les résultats sont inattendus. Toute expérimentation devrait être conduite d’abord via une copie sur le Modèle bac à sable ou dans votre espace utilisateur (voir la page Aide:Modèle).

La première phrase a un côté comique. “La documentation de ce modèle…” Tout celà va sans dire, non ?

La deuxième phrase “Pour en savoir plus…” suggère que la page de discussion est faite pour recueillir les suppléments de documentation et que ma connaissance du sujet risque d’être incomplète si je ne la lis pas. Ce qui est, on l’espère, naturellement faux. Même si ce n’était pas le cas, une section “pour en savoir plus” en début de document, c’est peu pratique.

Le reste n’est utile qu’aux rédacteurs de documentation, ou aux programmeurs de modèles. En sus, c’est bien pompeux.

Je trouve que la Wikipédia anglaise est meilleure à cet égard : le modèle en:Template:Documentation produit un titre sobre, avec une petite icône et sans rien d’autre à lire. Côté pratique, elle fournit deux liens discrets mais visibles et bien placés pour modifier la documentation et purger le cache. Pas besoin d’explications : “modifier”, c’est compréhensible par tous les utilisateurs de wiki ; “purger”, c’est pour ceux qui connaissent déjà le problème (et on peut ajouter une note flottante, alias “tooltip”, si nécessaire).

Les explications supplémentaires destinées aux rédacteurs et programmeurs se trouvent, logiquement, en fin de page (automatiquement insérées). De plus, elles sont remarquablement succintes et discrètes.

Les informations sont bien là, mais présentées avec sobriété et sans nuire au contenu primordial. Notez au passage que le développement devrait se faire dans le bac à sable individuel du modèle concerné, plutôt que dans un “bac à sable universel” (tel que Modèle:Bac à sable, qui me parait être une idée assez bizarre).

La Wikipédia anglaise souffre, par contre, du même défaut quant à l’avertissement relatif aux modèles complexes, qui est typiquement placé en tête de la documentation (exemple: en:Template:Binary).

Pour être franc, la raison d’être de cette notice m’échappe. Les utilisateurs sont ils demeurés au point de modifier un programme qu’ils ne comprennent pas ? Si tel était le cas, je douterais de l’efficacité d’une simple notice. Faut-il vraiment différencier les modèles “complexes” des autres ? Au vu de la syntaxe, on peut douter qu’il y ait des modèles “simples” ! (La blague qui court à ce sujet est la suivante : après leur mort, les mauvais programmeurs vont en enfer où ils sont condamnés à lire la totalité de l’espace “Modèle” de Wikipédia…) Dans tous les cas, cet avertissement pourrait prendre la forme d’une simple phrase supplémentaire dans la notice de bas de page.

En fin de compte, la surdose de placards en tête de page me semble inefficace et désagréable en général. Ceux-ci ne devraient être utilisés qu’avec parcimonie, peut-être même réservés aux messages temporaires qui doivent être impérativement lus à chaque visite de la page. Celà concerne aussi les modèles et leur documentation.

Wlgrin 17 novembre 2011 à 09:22 (CET), avec mes excuses pour les longueurs.

Le subst: ne marche plus ?

Bonjour,
J'ai un problème, pour un modèle: celui-ci (ex:L'aire urbaine sur www.insee.fr, Institut national de la statistique et des études économiques, consulté le oui) et sur ce modèle, le subst: semble ne plus fonctionner, est ce un problème de codage du modèle ou un problème de Mediawiki ?
Cordialement,--AM 23 (d) 19 novembre 2011 à 10:09 (CET)

J'ai changer le paramètre problématique de mon modèle, mais la question reste la même : Le subst: fonctionne-t-il encore ?--AM 23 (d) 19 novembre 2011 à 19:48 (CET)