Discussion Projet:Modèle

Une page de Wikipédia, l'encyclopédie libre.
Sauter à la navigation Sauter à la recherche
Crochets modèle.png Le salon des modélistes

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.

Annonces (section remplie automatiquement)

Questionmark.png Modèles proposés à la suppression


Edit-inprogress.svg Nouveaux modèles

Le projet « Modèle » a 3 notification(s) (voir).

Sommaire

Modèle d'élection admin[modifier le code]

Bonjour. J'ai laissé un message sur Discussion modèle:Proposition de vote mais je constate que cette page n'est pas très éditée aussi je vous en informe ici. Bien cordialement --En passant (discuter) 5 février 2015 à 16:11 (CET)

Wikidata et catégories : quels modèle pour utiliser sujet de la catégorie ?[modifier le code]

Je cherche à lier l'élément Wikidata qui représente le sujet d'une catégorie. Il y a une propriété pour ça, qui est pas mal peuplé. L'idéal dans un premier temps serait d'insérer un modèle comme {{Lien Wikidata}} dans les modèles inclus dans de nombreuses catégories, comme {{Article principal}} et {{Méta lien catégories}} … d'autres ou de meilleures idées ? — TomT0m [bla] 9 mai 2015 à 12:13 (CEST)

Je n'ai pas tout compris.
Visiblement {{Wikidata|P301}} mis sur une page de catégorie donne correctement le nom de la page principale liée à cette catégorie. On peut faire en sorte que dans les catégories, le modèle {{Article principal}} (ou une copie uniquement pour les catégories) utilise par défaut cette valeur.
Par contre je ne vois pas le rapport avec {{Lien Wikidata}} ou {{Méta lien catégories}}. Si tu pouvais être plus précis...
Zebulon84 (discuter) 9 mai 2015 à 13:47 (CEST)
Lien Wikidata va afficher un lien vers Wikipédia:Reasonator, c'est utile en particulier dans les cas ou il n'y a pas d'article Wikipédia fr pour afficher des infos et les interwikis de manière plus sympa que sur Wikidata. Méta lien catégorie est inclu sur pleins de pages de catégories, donc insérer des liens dedans permettrait de maximiser l'efficacité de l'utilisation des données Wikidata. L'autre solution serait d'insérer article pricipal dans toutes les pages de catégoriei pour lesauelles il y a une valeur de sujet de la catégorie dans wikidata mais pas de modèle sur la page de la catégorie. Un bot de maintenance pourrait faire ça. — TomT0m [bla] 9 mai 2015 à 14:06 (CEST)

Complétude du Modèle:Traduction/Référence[modifier le code]

Bonjour,

au même titre que certains modèles (ex: Modèle:Article et Modèle:Ouvrage) lorsqu'il manque les paramètres pour les titres ou années, serait-il envisageable d'avoir un message « paramètre oldid manquant » quand le Modèle:Traduction/Référence est utilisé dans un article et que le paramètre id n'a pas été complété ? Cela permettrait peut-être aux contributeurs apposant ce modèle d'être plus rigoureux sur ce paramètre, permettant ainsi à la Catégorie:Page avec un oldid invalide d'être moins remplie.

Vous remerciant par avance. Cordialement. £e p$y £éon (discuter) 1 juin 2015 à 11:25 (CEST)

Génération de cartes depuis wikidata[modifier le code]

Bonjour,

La carte {{Mégalithes Pyrénées Orientales}} a été générée grâce à l'outil {{wikidata list}} de façon semi-automatique : j'ai fait quelques rechercher/remplacer, c'est assez facile mais demande de connaître un peu le code.

Il me semble qu'on pourrait avoir un modèle {{wikidata map}} (ou {{carte wikidata}}) qui le ferait automatiquement : on lui donnerait une zone géographique et un ou plusieurs types d'éléments géolocalisables, et il nous ferait la carte, intégrable dans les articles comme tout autre modèle. Qu'en pensez-vous ? ---- El Caro bla 19 août 2015 à 10:09 (CEST)

Bonjour,
{{Wikidata map}} serait bien pratique suppose le robot qui va avec, et ça demande je pense pas mal de savoir faire.
J'en ai profité pour modifier un peu ton modèle :
- marqueurs plus petits. ça reste trop gros, mais sur ta version c'était franchement pas présentable :\
Je suis d'accord avec toi, il nous faut trouver un meilleur moyen de représenter autant de points sur une carte. As-tu une idée de représentation? Une solution pourrait être de représenter chaque point avec un marqueur plus petit (un point par exemple), une autre pourrait être de regrouper plusieurs points en un seul (comme une grappe regroupant plusieurs points) lorsque le zoom est trop faible. Voir le ticket sur Phabricator. JGirault (WMF) (discuter) 9 janvier 2017 à 19:38 (CET)
Enregistré sur Phabricator
Tâche 136455
- liens dans les libellés (le problème c'est qu'ils se mettent en bleu même quand l'article n'existe pas, @JGirault (WMF)).
J'ai crée un ticket pour résoudre ce problème. JGirault (WMF) (discuter) 9 janvier 2017 à 19:38 (CET)
Enregistré sur Phabricator
Tâche 154918
- enlevé le masque autour du département et mis une simple ligne pour marquer le contour. Prendre un département actuel comme cadre de référence pour des mégalithes, c'est déjà douteux conceptuellement, pas la peine d'en rajouter en l'isolant complètement du reste du monde. :] -Zolo (discuter) 7 janvier 2017 à 12:27 (CET)

Vers une carte interactive ?[modifier le code]

Bonjour à tous,

Toujours à propos de cartes, mais pas à partir de wikidata, je vous soumets cette petite question concernant l'éventuel affichage de cartes interactives sur un fonds Openstreetmap par exemple dans Wikipédia.

Sur Wikibrest, ils font ça très bien (voir par exemple les patrimoines architecturaux anciens de Brest). C'est quand même mieux que nos fonds de cartes géolocalisés fixes.

Je me suis dis que d'un wiki à l'autre il n'y a qu'un pas. J'ai donc créé le modèle {{maps/Bac à sable}} dans Wikipédia par copie du modèle Maps figurant de Wikibrest.

Mais bon, étant un amateur ... cela ne marche pas (voir ce que celà donne). ( je me demande s'il ne faut pas déclarer osm en tant que layer quelque part, mais je ne vois pas) Je ne suis pas allé plus loin. Je vous pose donc la question si c'est faisable ou non. Merci par avance.Roland45 (discuter) 22 août 2015 à 11:18 (CEST)

Bonjour. Je ne sais pas si ça a un rapport, mais le Modèle:KML joint permet de représenter des points, lignes et surfaces. Hélas, ça ne marche pas avec OSM, mais lien vers Bing Map (qui accepte des flux KML). L'insertion de "fenêtres cartes" a toujours été problématique dans WP... Jack ma ►discuter 22 août 2015 à 15:45 (CEST)
Je mets ci-après la réponse qu'Orlodrim m'a faite par ailleurs :
Wikibrest utilise l'extension Maps (le #display_map dans le code du modèle), qui fait l'essentiel du travail. Mais cette extension n'est pas installée sur les projets Wikimedia.
La page la plus à jour concernant les cartes dans les wikis de la WMF est mw:Maps. D'après ce que j'ai lu, mettre des cartes directement dans Wikipédia pose des problèmes d'infrastructure, vu la consultation du site, et une équipe de la WMF y travaille (mw:Discovery#Maps).
Orlodrim (discuter) 22 août 2015 à 11:42 (CEST)
Peut-être que le projet aboutira.Roland45 (discuter) 22 août 2015 à 15:58 (CEST)

Indication de langue dans les modèles créant un lien externe[modifier le code]

Bonjour

J'ai récemment édité des articles de botanique et de zoologie et je me suis rendu compte que les modèles créant un lien externe (cf. Catégorie:Modèle créant un lien externe) de biologie affichent l'indication de langue à la fin (par exemple le Modèle:CITES genre) tandis que d'autres, de sport par exemple, l'affichent au début (par exemple le Modèle:Eurohockey), comme c'est le cas des autre modèles comprenant un paramètre « langue » (par exemple le Modèle:Ouvrage, Modèle:Article, , etc.), c'est d'ailleurs ce qui est recommandé dans l'Aide:Indication_de_langue.

Ne serait-il pas bon d'uniformiser tout ça en mettant l'indication de langue au début de tous les modèles ? Je sais qu'il y a quelques modèles qui ont plusieurs liens avec plusieurs langues, mais je ne pense pas que leur adaptation pose de gros problèmes.

En attente de vos commentaires, cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ You talkin' to me? 16 octobre 2015 à 12:59 (CEST)

Dysfonctionnement du modèle {{ExpInd}}[modifier le code]

NO-3 est un ion (comme une pomme est un fruit), mais NO-10 n'existe pas : sur mon ordinateur au moins (IE9 sous Vista), l'espace suivant le rendu du modèle est mangée. On peut s'en tirer avec une (ou des) espace(s) insécable(s) supplémentaire(s) mais il vaudrait mieux amender le modèle, si cet effet disgracieux n'est pas propre à mon ordi. Merci d'avance. — Ariel (discuter) 28 février 2016 à 11:18 (CET)
P.S. Au vu des deux exemples indiqués il apparaît que le positionnement du mot suivant se base sur la largeur de l'exposant, alors qu'il faudrait qu'il se base sur le plus large des deux, exposant et indice.

Pendant qu'on sera les mains dans le cambouis de ce modèle, ne pourrait-on pas créer aussi le modèle {{IndExp}}, dans lequel l'ordre des deux paramètres serait inversé, juste pour la commodité des contributeurs (selon le contexte il est plus naturel de citer d'abord l'exposant ou d'abord l'indice) ? — Ariel (discuter) 28 février 2016 à 11:45 (CET)
C'est parce que le texte qui suit est positionné par rapport à l'exposant, mais pas par rapport à l'indice. Donc du coup, si l'indice est plus long… Il faudrait probablement s'inspirer du modèle en:Template:Sup sub. od†n ↗blah 10 mai 2016 à 13:36 (CEST)

Modèles sans templatedata[modifier le code]

Bonjour,

J'ai actualisé la liste des 1000 modèles à paramètres les plus utilisés dans l'espace principal n'ayant pas de templatedata : Projet:Modèle/TemplateData. Il y a encore du travail ! Les 38 premiers de la liste sont utilisés dans plus de 10000 pages chacun.

Orlodrim (discuter) 4 mars 2016 à 18:21 (CET)

Siècle en chiffres arabes[modifier le code]

Bonjour, serait-il possible au modèle {{s}} d'afficher une infobulle contenant le siècle en chiffres arabes. Merci de la part des lecteurs qui ne sont pas habitués de lire les chiffres romains. --Yanik B 27 juillet 2016 à 22:11 (CEST)

Symbol support vote.svg Il faudrait que ce soit valable aussi bien sur les hyperliens {{s}} : XVIIe siècle que sur {{s-}} : XVIIe siècle. Il semble que ce soit possible (voir {{abréviation discrète}} dans {{rom}} et {{rom-maj}}). Cordialement, Jack ma ►discuter 29 juillet 2016 à 09:02 (CEST)
Génial, c'est exactement ce qu'il nous faut. --Yanik B 29 juillet 2016 à 13:51 (CEST)
Notification YanikB et Jack ma :
  • pourquoi pas en toute lettre ? Car il n'est pas vraiment possible de mettre le « e » en exposant en infobulle.
  • dans le cas de {{s}} l'infobulle va remplacer l'infobulle avec le nom de la page de destination. Est-il préférable de tout remplacer (ex XVIIe siècle) ou seulement le nombre romain (ex XVIIe siècle)
Zebulon84 (discuter) 30 juillet 2016 à 02:07 (CEST)
Personnellement je trouve :
  • la solution en chiffres arabes et où tout est remplacé plus élégante (car l'affichage reste le même qu'on soit sur les 2 parties).
  • Abréviation discrète serait préférable à abréviation (pas de soulignement).
  • D'autre part, actuellement, dans {{s-}}, aucune infobulle ne s'affiche, bien que "abréviation discrète" soit présente dans le modèle (ex: XVIIe siècle; l'idéal serait XVIIe siècle).
Jack ma ►discuter 30 juillet 2016 à 07:06 (CEST)
D'accord avec Jack. Dommage pour la typo du e mais les avantages l'emportent sur l'inconvénient. --Yanik B 30 juillet 2016 à 12:30 (CEST)
Zebulon84 Les modèles {{S}} et {{S-}} étant protégés, il faut un administrateur pour faire la modif. --Yanik B 31 juillet 2016 à 13:48 (CEST)
Notification YanikB et Jack ma : j'ai fait la modification nécessaire sur {{s-}}.
Comme il faut manuellement indiquer les correspondances romain → arabe, et qu'un switch n'est pas très efficace, j'ai mis tous les nombres jusqu'à XL (40), puis uniquement ceux qui sont nécessaire (i.e. réellement utilisé) au-delà.
Je vais attendre demain pour faire la modification sur les autres {{{s}}, {{{-s}}, {{s2}}… au cas où quelqu'un verrait un problème. — Zebulon84 (discuter) 31 juillet 2016 à 19:31 (CEST)
Merci beaucoup. Je fais quelques vérifications pour s'assurer que tout beigne. --Yanik B 31 juillet 2016 à 19:38 (CEST)
Chez moi ne marche pas avec les siècles av. J.-C. : XVIIIe siècle av. J.-C. (n'affiche que le avant J.-C.)— Salve - louis-garden pinXit (On en cause) 1 août 2016 à 11:48 (CEST)
Idem... Merci Clin d'œil Zebulon84. Jack ma ►discuter 1 août 2016 à 13:16 (CEST)
Ceci pourrait peut-être servir : Convertisseur chiffre arabe-romain ; ou plus simplement utiliser avec mw.loadData une table Lua remplie manuellement. od†n ↗blah 1 août 2016 à 15:54 (CEST)
od†n : j'y ai pensé, mais pour un switch avec 50 valeur simple, je ne pense pas qu'un module qui appelle un autre module par loadData soit plus rapide. Dans les derniers tests que j'ai fait il y a quelques mois, lancer lua (utiliser #invoque avec un module vide ou presque) prenait 0.05 s, soit certainement plus que l'exécution de ce switch. — Zebulon84 (discuter) 1 août 2016 à 21:09 (CEST)

┌─────────────────────────────────────────────────┘
Tout comme Morburre, je constate que plusieurs modèles de siècle {{Palette Liste des modèles siècle}} n'ont pas la même typo ce qui donne un rendu disparate dans les articles.--Yanik B 8 août 2016 à 17:33 (CEST)

Pourrais-tu donner un exemple ? C'est laborieux de tout éplucher Clin d'œil Un autre point pour ma part : les titles des abréviations devraient plutôt être en toutes lettres, pour les lecteurs d'écran. od†n ↗blah 8 août 2016 à 18:45 (CEST)
J'avais réduit la taille de l'exposant sur certains modèles, pas sur d'autres, me posant la question de comment centraliser le calcul de l'infobulle. Maintenant il me semble que tous les modèles utilisent la taille réduite, et tous ont une infobulle en chiffre arabe basé sur le modèle {{s mini-}} sauf pour les modèle type {{XIVe|s}} pour lesquelles l'infobulle est en toute lettres.
L'aspect n'est cependant pas toujours le même lorsque l'on change de navigateur ou d'OS :
  • avec Firefox toutes configurations (bureau ou mobile, Windows 10, ubuntu et android) et Chrome sous Windows je vois le siècle affiché de la même hauteur que les x minuscules, et l'exposant bien lisible au dessus ;
  • avec Edge, le siècle est plus haut que le x minuscule, et sur la version bureau l'exposant trop petit pour être vraiment lisible ;
  • avec Chrome sur Ubuntu ou Android 6, les siècles sont plus petit que les x minuscules, comme le signale Morburre.
Je n'ai pas d'appareil Apple pour tester ça. L'implémentation de « font-variant: small-caps; » n'est pas homogène, et on ne peut pas y faire grand-chose. — Zebulon84 (discuter) 8 août 2016 à 23:58 (CEST)

{{Source principale}} ?[modifier le code]

Bonjour. Il ne semble pas exister d'équivalent de {{Source principale de section}} pour un article complet, qui pourrait s'appeler {{Source principale d'article}} ou plus simplement {{Source principale}}. Ce serait facile à faire donc ma question est : il y a sûrement une bonne raison pour que ce modèle n'existe pas, alors qu'il me paraît potentiellement utile pour certains (courts) articles ? Merci d'avance. — Ariel (discuter) 21 décembre 2016 à 10:48 (CET)

Modèle Unité[modifier le code]

Bonjour,
Quelqu'un serait-il capable d'adapter le modèle {{unité}} pour que, dans le cas particulier où on veut uniquement une unité sans nombre devant, le modèle affiche bien uniquement l'unité et non pas "espace + unité" ? Cf. par exemple le RI de Densité surfacique de puissance, où on se retrouve avec un espace erroné entre la parenthèse et W m−2. En gros, il faudrait qu'il y ait un "si nombre, alors espace ; sinon pas d'espace". Au passage, contrairement à ce que prétend la doc, le paramètre "nombre" n'est aucunement obligatoire dans le sens où aucun message d'erreur n'apparaît quand on utilise le modèle sans nombre. Si cette "obligation" est un artefact pour occulter la faille de l'espace, ce n'est pas la bonne façon de faire.
Merci d'avance pour cette retouche.
SenseiAC (discuter) 21 janvier 2017 à 13:30 (CET)

Demande déjà formulée par Ggal le 23 avril 2014 à 08:20, ici. — Ariel (discuter) 21 janvier 2017 à 13:57 (CET)
Certes, et depuis trois ans on en est au même point. D'ailleurs, cette ancienne demande note d'autres problèmes qui sont aussi toujours là… SenseiAC (discuter) 21 janvier 2017 à 14:41 (CET)
D'ailleurs il faudra prévenir quand la modif sera faite, car d'aucuns tiennent compte du bug (p. ex. « l'unité d'énergie surfacique est leJ m−2 »). — Ariel (discuter) 21 janvier 2017 à 15:50 (CET)

Poids du modèle Refm (Références multiples)[modifier le code]

Bonjour. Dans le cadre d'une intention de proposer au label la page Richard Seaman (d · h · j · ), Matpib (d · c) m'a aimablement fait remarquer que la page était longue à charger. Celui-ci soupçonne l'utilisation intense de modèles dans la page. Au palmarès des plus utilisés, on retrouve :

J'en viens à mon tour à soupçonner le relativement peu usité {{refm}} (Modèle:Références multiples). Savez-vous s'il est connu ou non pour ralentir les pages à leur chargement ? D'avance, merci. Mëka Parler 22 janvier 2017 à 20:39 (CET).

Copie du rapport "NewPP" de la page en question :
100.00% 2768.956      1 -total
 32.80%  908.272      3 Modèle:Références
 32.54%  901.156      2 Modèle:Références_nombreuses
 15.65%  433.465    145 Modèle:Refm
 13.07%  361.805    437 Modèle:Références_multiples/Sous-modèle
 12.02%  332.910     78 Modèle:Lien_web
 10.37%  287.028    249 Modèle:Lang
  8.36%  231.441    131 Modèle:Sfn
  7.87%  217.852      3 Modèle:Infobox_Pilote
  6.46%  178.762     60 Modèle:Infobox_V3/Tableau_Ligne_mixte
  • Ne pas oublier que les coûts sont inclusifs, c'est-à-dire par exemple que les Modèle:Refm eux-mêmes coûtent 433.465 - 361.805 = 71.66 ms.
  • Sur le même principe, il faut garder à l'esprit que les modèles "englobants" (exemple : Modèle:Références_nombreuses) incluent le coût de tout ce qu'ils contiennent (exemples : Modèle:Lien_web, Modèle:Lang).
Je ne suis pas allé cerner le bottleneck pour le cas présent, mais si ces quelques indications peuvent aider… od†n ↗blah 23 janvier 2017 à 01:10 (CET)
À noter aussi que contrairement à ce qui se voit habituellement, le modèle le plus coûteux — généralement un modèle "inclusif" — est ici largement en dessous du coût total ; en l'occurrence il ne pèse qu'un tiers, là où habituellement c'est la quasi-totalité. Une bonne clé serait de trouver où passent les deux autres tiers du coût total… od†n ↗blah 23 janvier 2017 à 01:30 (CET)
Donc, il y a des coûts qui existent bel et bien, mais ne figurent pas dans le rapport. Des sortes d'overhead (mais qui là pèsent bien gros) dont le temps de traitement se situerait "en dehors" du mécanisme de transclusion des modèles. Et aussi, dont le poids serait devenu manifeste en raison d'un nombre élevé d'utilisations.
Je suis quasiment assuré que cela vient des nombreuses invocations de Lua (Modèle:Lien_web, Modèle:Lang)… Les codes Lua en eux-mêmes ne sont pas excessivement lent, ce qui pose problème c'est de les invoquer plusieurs centaines de fois.
od†n ↗blah 23 janvier 2017 à 13:39 (CET)
Notification Od1n : bonjour et merci beaucoup pour cette réponse aussi claire qu'exhaustive. Je ne nie pas l'usage assez prononcé des modèles et dois me remettre à la page après une assez longue absence (le Lua et les notifications n'existaient pas encore). Je trouverai à nuancer et alléger la page de quelques {{lang}} (pour ce qui est des {{Lien web}}, il est, amha, difficile de passer outre).
Apparemment, retirer les seuls appels aux fonctions {{Références nombreuses}} allègerait considérablement les temps de chargement. Ne recourir plus qu'à une seule infobox devrait également être bénéfique (j'ai ouvert un sujet sur le Paddock relatif à la mise à jour de l'existant et formulé des propositions qui permettraient d'élargir leur usage en privilégiant l'accessibilité).
Comment est-il possible d'extraire le rapport "NewPP" ? Il m'intéresse de pouvoir le faire par moi-même pour étudier la solution la plus viable en termes de délai de chargement, en l'occurrence, tester {{Section déroulante début}} et {{Section déroulante fin}}. Merci. Mëka Parler 23 janvier 2017 à 19:43 (CET).
  • Pour trouver ce rapport, il faut afficher le code source de la page (Firefox, Chrome : Ctrl + U) puis faire une recherche du texte "NewPP".
  • Inutile de chercher à retirer quelques modèles ci et là, le gain serait absolument insignifiant. De toute façon, tous les articles de grande taille ont le même problème, et cet article n'est pas plus impacté que les autres.
  • Le vrai problème, c'est qu'il est anormal que quelques dizaines ou centaines de {{lang}} suffisent pour impacter significativement les performances. Mais c'est un problème qui ne concerne que les modélistes, et à première vue je pense qu'il est assez facilement possible d'améliorer la situation.
od†n ↗blah 23 janvier 2017 à 20:16 (CET)
Merci beaucoup. Si je comprends bien, d'une manière ou d'une autre, on ne peut produire d'article long, sourcé et structuré via des modèles sans éviter l'écueil du temps de chargement qui augmente ? Mëka Parler 23 janvier 2017 à 20:55 (CET).
Si si, on peut. À ce jour la situation reste quand même acceptable, et il y a une belle marge de progression pour l'améliorer. od†n ↗blah 23 janvier 2017 à 21:07 (CET)
Pour info : Discussion modèle:Langue#Réduction du nombre d'invocations Lua. Pour l'article utilisé en exemple ici, le gain en temps de génération serveur est d'environ 20~25 % (soit une demi-seconde). Il y a bien d'autres paramètres qui jouent sur les performances finales (temps de transfert etc.), mais c'est quand même bon à prendre. od†n ↗blah 26 janvier 2017 à 19:50 (CET)

Modèle:Traduction/Référence[modifier le code]

J'ai fait une suggestion dans la page de discussion du modèle le 23 avril 2016 (ici). On peut donc considérer que le temps de la réflexion a été suffisant... Bon voici mon souhait :
Le modèle présente 2 présentations suivant que le type=note ou non :

  • Quand le type=note, c'est-à-dire quand on met la source dans la section "Note et références", le point disparaît, c'est il me semble la seule différence entre les deux présentations ;
  • Quand le type n'est pas spécifié, le point apparaît. C'est le cas quand le modèle est placé dans une rubrique "Sources et bibliographie"

Je souhaiterais que quand type=note, cette note apparaisse effectivement avec la même typographie qu'une note, même taille, justification à gauche, etc. On peut voir ce que cela donne en regardant la page suivante : Projet:Espagne/Modèle pour la création des communes de la province de Huesca (page que j'ai créée). J'ai volontairement ajouté une image dans l'article pour qu'on observe que la note n'est pas justifiée à gauche au contraire d'une note normale.
Ce qui serait pas mal également, c'est que quand la rubrique note est présentée en plusieurs colonnes, on puisse faire apparaître ce modèle de la même manière ; mais je suppose que cela est plus dur et on peut éventuellement s'en passer.
Berdea (discuter) 30 janvier 2017 à 02:16 (CET)

modification aves CSS[modifier le code]

Salut, et pardon pour écrire en anglais : I would like to notify you that there is currently work on an extension in order to enable CSS styling in templates. Please check the document here to discuss best storage methods and what we need to avoid with implementation. Thanks --Melamrawy (WMF) (discuter) 7 février 2017 à 09:48 (CET)

Géolocalisation variable[modifier le code]

Bonjour,

En utilisant certaines infobox comme {{Infobox Monument}} qui géolocalisent automatiquement, je crois, via wikidata, on a un problème avec le département français des Pyrénées-Orientales. La plupart de ce territoire est de tradition catalane (OK), mais la carte utilisée est celle de la Catalogne, communauté autonome d'Espagne. Il faudrait soit utiliser une carte de "Catalogne historique" (peu compatible avec nos habitudes), soit exclure d'une façon ou d'une autre les territoires de "Catalogne Nord" de la géolocalisation "Catalogne". On peut voir un exemple sur Hospici d'Illa. -- El Caro bla 7 février 2017 à 10:56 (CET)

Notification El Caro : Si on ne met pas en paramètre d'infobox quelque chose du genre « |géolocalisation = France/Pyrénées-Orientales », le choix par défaut guessmaps de Module:Carte prend la carte la mieux centrée de chaque « zone » à partir des points extrêmes nord/sud/est/ouest des cartes répertoriées dans Module:Carte/données, qui indique effectivement 3 « zones » différentes pour les cartes correspondant aux coordonnées d'Hospici d'Illa : département français pour pyrénées-orientales, communauté espagnole pour catalogne et montagne pour pyrénées.
Bref, bug bien connu et solution envisagée connue aussi avec P17 (« pays ») ou même P131 (« localisation administrative »), mais ça reste à faire. — Oliv☮ Éppen hozzám? 7 février 2017 à 14:28 (CET)
Merci pour la réponse. Plus qu'un bug, ça me parait un défaut de conception, surtout que maintenant on doit pouvoir récupérer la localisation administrative de wikidata. -- El Caro bla 7 février 2017 à 20:05 (CET)

Suggestion concernant le Modèle:Article et le Modèle:Ouvrage[modifier le code]

Bonjour à tous

Avec le {{Modèle:Article}}, j'obtiens une référence telle que celle-ci :

{{Article | lire en ligne=http://gallica.bnf.fr/ark:/12148/bpt6k571034h/f1.item.r=Baye.zoom | périodique=Le Matin | date=29 septembre 1914 | titre=L'impérial cambrioleur | page=1, colonne 4}}

Mais je voudrais faire apparaître l'url simplifié gallica.bnf.fr, comme on le fait facilement dans {{Modèle:Lien web}} avec la commande site=, de manière à indiquer au visiteur que ce lien mène vers gallica. Or, site= n'existe pas avec {{Modèle:Article}}.

J'ai bien essayé ceci avec la commande résumé= :

{{Article | lire en ligne=http://gallica.bnf.fr/ark:/12148/bpt6k571034h/f1.item.r=Baye.zoom | périodique=Le Matin | date=29 septembre 1914 | titre=L'impérial cambrioleur | page=1, colonne 4 | résumé=gallica.bnf.fr}}

mais la commande résumé donne un rendu bizarre : [sur gallica.bnf.fr résumé]. D'ailleurs, la commande résumé ne semble pas destinée à ce que je cherche.

C'est pourquoi ma question est la suivante : ne serait-il pas possible d'ajouter à {{Modèle:Article}} la commande site= ? Il en va d'ailleurs de même pour {{Modèle:Ouvrage}}. Et enfin, autre question connexe : pourquoi ces 3 modèles, finalement proches ou très proches ne sont-ils pas harmonisés ?

Pour compléter, voici la référence que j'obtiens actuellement pour les modèles Article et Ouvrage :
1. L'impérial cambrioleur, Le Matin, 29 septembre 1914, p. 1, colonne 4 (lire en ligne)
ou bien, avec la commande résumé= :
1. L'impérial cambrioleur, Le Matin, 29 septembre 1914, p. 1, colonne 4, ([gallica.bnf.fr résumé] lire en ligne)
et voici ce que je voudrais obtenir (ce qui est souligné) :
1. L'impérial cambrioleur, Le Matin, 29 septembre 1914, p. 1, colonne 4 (lire en ligne sur gallica.bnf.fr)

Qu'en dites-vous ?

Tubamirum (discuter) 29 mars 2017 à 17:32 (CEST)

Modèle country data, drapeaux et accessibilité[modifier le code]

Bonjour chers modélistes modèles ! :-)

D'un point de vue d'accessibilité, il faudrait améliorer le rendu des (nombreux !) modèles de la Catégorie:Modèle Country data, qui sont appelés par le Modèle:Pays. En effet, ils produisent une icône décorative. Cette icône n'apporte pas d'information utile pour une personne malvoyante, car elle est redondante avec le texte associé.

Le problème est que les icônes de pays sont des images avec un lien sur l'image. Donc il leur faut une alternative textuelle, faute de quoi le nom du fichier sera lu par la synthèse vocale. Dans ce cas, il faudrait retirer le lien sur l'image et mettre une alternative textuelle vide. Cela peut être fait de deux manières :

  • Soit on fait en sorte que le modèle ait la syntaxe |alt=|link= (alternative textuelle vide, et pas de lien),
  • Soit on passe l'icône en background CSS, ce qui est plus robuste mais qui alourdit le CSS général.

Les modèles étant protégés à l'édition, et de syntaxe pas toute simple (ou c'est juste moi qui ne suis plus habitué), je demande un coup de main ! ;-)

Voir aussi les explications sur Wikipédia:Atelier accessibilité/Bonnes pratiques#Images décoratives, et un exemple de modèle déjà conçu ainsi : Modèle:Message galerie. Merci de votre attention ! Dodoïste [ dring-dring ] 7 avril 2017 à 23:21 (CEST)

Quand mw:Extension:TemplateStyles sera prêt, est-ce que l’on pourra passer ce genre d’icône en background CSS sans alourdir le CSS général ? Parce que c’est ce que j’avais cru comprendre quand la nouvelle était arrivée (voir plus haut dans la page), mais je ne suis pas sûr. — Metamorforme42 (discuter) 7 avril 2017 à 23:58 (CEST)
Apparemment oui ; merci d'ailleurs je n'en avais pas connaissance. Si j'ai bien compris TemplateStyle comporte la possibilité d'appeler un média. Bon dans l'immédiat, je ne pense pas qu'il faille se attendre sur son hypothétique arrivée pour effectuer les changements que je propose. L'arrivée de cette extension n'est probablement pas pour bientôt. Dodoïste [ dring-dring ] 8 avril 2017 à 00:15 (CEST)

Aperçu de wikipédia dans les résultats google[modifier le code]

Bonjour, Pour continuer la discussion commencée ici.

Message d'origine :

Lorsque l'on effectue une recherche sur google, le moteur de recherche affiche un aperçu du texte de la page dans le résultat, seulement lorsque la page wikipédia possède un bandeau (évènement récent, à sourcer, etc), c'est ce bandeau qui est pris pour résumer la page. capture d'écran
Ce problème n’apparaît pas sur Bing (mise en forme différente), n'apparaît pas quand il y’a un aperçu créé spécifiquement capture d'écran, ni avec les articles de la wikipédia anglaise, de ce que j’ai pu remarquer.
Il y'a t il une raison particulière ? une solution pour améliorer ces résultats de recherche ?
Roumpf [Message] 13 mai 2017 à 13:08 (CEST)
Je n'ai pas de problème sur duckduckgo non plus. En dehors du seul problème Google, ces bandeaux "alourdissent" et ralentissent la lecture. Devoir donner des coups de molette de souris pour lire le RI est rédhibitoire par exemple. Quid de mettre ces bandeaux dans un encart à droite ou à gauche de l'article, par exemple ? Les mettre en bas de page serait assez malhonnête, puisque ce sont des avertissements à la lecture. Les indications bon article ou article de qualité son plutôt petits et peu gênants. On pourrait faire tenir le bandeau en une ligne, de la même façon, et le surligner en rouge ? Qu'en pensez-vous ? D'autres idées ?Tpe.g5.stan (discuter) 15 mai 2017 à 10:35 (CEST)
Sinon Google prend les premières lignes de texte pour caractériser une page, donc évidemment les premières lignes du bandeau. Et je ne vois pas de différence entre Bing et Google sur ce point : si l'aperçu spécifique est toujours correct, l'aperçu habituel prend en charge le texte du bandeau en premier lieu. De manière également assez étrange, en absence de bandeau, l'aperçu Google peut prendre les premières lignes de l'infobox en premier, ou les premières lignes de l'article - pour Adam Sandler, c'est l'infobox, pour Adam Levine, c'est l'article, alors qu'il n'y a pas de mise en forme différente sur ces deux articles. Pour Bing, dans les deux cas, c'est l'infobox qui prime - mais ce n'est pas systématique. Lorsque la prononciation est présente, l'aperçu général le prend en compte - mais pas l'aperçu spécifique. Si le problème est le résultat des recherches, on aura la prononciation ou l'infobox qui gêneront - après le bandeau. Si le problème est la mise en page en interne, ou sur la version mobile, on sort du sujet - et la discussion ne se limite plus à une question de modèle, mais de mise en page et d'avertissement.SammyDay (discuter) 15 mai 2017 à 10:44 (CEST)
Il y'a le problème de l'affichage dans les résultats qui est assez gênant, et qui je pense devrait être une priorité. Par la suite rien n'empêche de réfléchir à la mise en page interne, mais là il faut voir à plus long terme. Ne pourrait-on pas avoir une <meta name="Description"> qui reprendrait l'intro de l’article, et exculurait les bandeaux ? Je ne sais pas vraiment comment appliquer ça mais si wikipédia définie quel est le texte à afficher, ca pourrait marcher ? Nous le faisons déjà avec la fonctionnalité bêta qui affiche un aperçu au survol d'un lien interne par la souris.Roumpf [Message] 15 mai 2017 à 10:57 (CEST)
Si on savait comment les moteurs de recherche choisissent les informations à mettre en avant - j'ai l'impression vu les cas précisés ci-dessus que c'est un peu du pifomètre - on pourrait y réfléchir. SammyDay (discuter) 15 mai 2017 à 11:03 (CEST)
Faudrait regarder si enwiki utilise une balise dans les bandeaux pour les exclure des résultats ? — Thibaut (discuter) 15 mai 2017 à 11:29 (CEST)
Je ne trouve pas de balise particulière à première vue sur enwiki, ni de balise donnant un contenu. En revanche sur frwiki, je note que les modèles "homonymie" par exemple ne sont pas affichés dans les résultats, ni le bandeau ébauche, contrairement aux autres bandeaux …

Je commence à penser qu'on est effectivement entrain de se confronter à l'algorithme google et qu'une solution concrète s'avère compliquée.Roumpf [Message] 15 mai 2017 à 12:59 (CEST)

Une hypothèse serait en effet que les ingénieurs de Google ont adapté leur algorithme pour Wikipédia en anglais mais pas pour les autres Wikipédias. — Thibaut (discuter) 15 mai 2017 à 13:23 (CEST)
Je viens d'ajouter l'attribut role=presentation, comme sur les boites de en.wiki pour voir si ça fait une différence. — Zebulon84 (discuter) 17 mai 2017 à 06:24 (CEST)
Merci @Zebulon84, maintenant nous devons attendre que les pages soient réindexées pour voir c'est ca ? Roumpf [Message] 19 mai 2017 à 00:11 (CEST)
Notification Roumpf : je suppose que cette modification n'est pas efficace, car je doute que Élections législatives françaises de 2017 n'ai pas été réindexée depis hier matin (page à fort trafic, 200 modifs sur la page depuis). — Zebulon84 (discuter) 19 mai 2017 à 01:39 (CEST)
C'est un problème que j'aimerais bien aussi voir corrigé. J'ai un peu cherché, il ne semble pas exister de solution évidente, je crains que la seule possibilité soit de contacter directement Google, au moins pour savoir comment ils procèdent pour en.wiki. Bon courage… od†n ↗blah 19 mai 2017 à 18:08 (CEST)
Sur en.wiki les bandeaux sont des tables et non des div, cela joue probablement un rôle. — Zebulon84 (discuter) 19 mai 2017 à 18:45 (CEST)
Je l'avais remarqué aussi, mais ça serait dommage d'avoir à repasser sur des <table> à cause de ça (bien que la correction des SERP google serait vraiment appréciable). Mais rien n'est sûr, c'est peut-être ça, ou alors peut-être des règles manuelles pour les classes "xxbox". C'est pour ça qu'une info directement de la part de google serait utile. od†n ↗blah 19 mai 2017 à 19:16 (CEST)

Création d'un modèle ayant trois situations : avant la date, le jour J, et après.[modifier le code]

Bonjour, pour Wikisource et plus précisément le projet 100 livres - 100 jours 217, je cherche à modifier le modèle : 100j2017.

Il faudrait que le modèle varie en fonction de la date inscrite.

  • Avant la date inscrite ; il faudrait modifier le modèle pour indiquer :

Ce livre doit être traité dans le cadre du défi 100 livres en 100 jours du {{{jour}}}.

Il est cependant possible, dès aujourd'hui, de réaliser certaines tâches :

  • Création de la liste des pages, de la table des matières.
  • Création des pages blanches, des illustrations.

{{Wikisource:AccueilTitre/100jours2017}}


[[Catégorie:100 livres en 100 jours — 2017/A venir]]

  • Le jour J :

Aujourd'hui, {{{jour}}} ce livre est le livre est le livre du jour dans le cadre du défi 100 livres en 100 jours.

L'idéal serait de terminer, d'exporter et de valider ce livre, aujourd'hui.

Cependant, il est possible de poursuivre le livre durant toute la durée du défi, ainsi que les autres livres en cours.


[[Catégorie:100 livres en 100 jours — 2017]]

  • Après :

Ce livre fait l’objet du défi 100 livres en 100 jours depuis le {{{jour}}}.

Le défi ne sera pas considéré comme réussi tant que la transclusion et l'export du livre n'auront pas été réalisés. La validation est optionnelle mais fortement recommandée.

Cependant, il est possible de poursuivre le livre durant toute la durée du défi, ainsi que les autres livres en cours.


[[Catégorie:100 livres en 100 jours — 2017]]

--Newnewlaw (discuter) 8 août 2017 à 06:46 (CEST)

Carte interactive dans l'infobox ?[modifier le code]

Genève
Modèle
Administration
Pays Drapeau de la Suisse Suisse
Canton Drapeau du canton de Genève Genève
NPA 1
OFS 1
Géographie
Coordonnées 46° 12′ 00″ nord, 6° 09′ 00″ est
Localisation

Géolocalisation sur la carte : Suisse

Voir sur la carte administrative de Suisse
Genève

Géolocalisation sur la carte : canton de Genève

Voir la carte administrative du Canton de Genève
Genève

Géolocalisation sur la carte : canton de Genève

Voir la carte topographique du Canton de Genève
Genève

Bonjour,

Comment pourrait-on ajouter {{Carte interactive}} dans {{Infobox Subdivision administrative}} de faon propre ? J'ajoute à la discussion un exemple de "rendu" (si ça daigne marcher). Cdlt, Lyon-St-Clair [Hon hon hon] 2 octobre 2017 à 12:31 (CEST)

Bonsoir, le seul paramètre qui actuellement ne catégorise pas en erreur est imageloc2. Par contre, l'image est placée en haut. --FDo64 (discuter) 2 octobre 2017 à 22:04 (CEST)
Salut,
Ah cool si un tel champ existe (je MAJ mon exemple). Pourquoi le mettre en haut ? Peut-on importer automatiquement l'élément wikidata (le Qxxx) ? Cdlt, Lyon-St-Clair [Hon hon hon] 2 octobre 2017 à 22:08 (CEST)
Ce paramètre n'est utilisé que dans 5 modèles qui nécessitaient une carte en haut.
Peut-être vaudrait-il mieux créer un nouveau paramètre pour cela. --FDo64 (discuter) 2 octobre 2017 à 22:23 (CEST)
Sans doute, mais pour le moment ça dépasse un peu mes compétences. Cdlt, Lyon-St-Clair [Hon hon hon] 2 octobre 2017 à 22:32 (CEST)
Je peux le faire, mais je temporise un petit peu. Peut-être que Notification Zebulon84 aurait une autre idée ?
Il s'agirait, par exemple d'ajouter {{carte interactive|latitude={{{latitude|}}}|longitude={{{longitude|}}}|hauteur=280|largeur=280|align=center|osm=|zoom=11|frameless=oui}}
--FDo64 (discuter) 2 octobre 2017 à 22:49 (CEST)
Notification Lyon-St-Clair et FDo64 : on peut ajouter la possibilité d'avoir une carte interractive, activable par un paramètre. Je regarde ça dans les prochains jours. Le problème c'est le niveau de zoom. 11 ne sert qu'à ceux qui n'ont pas besoin de la carte pour situé la subdivision administrative en question, et est bien trop petit pour les régions. 5 serait plus réaliste pour pouvoir situer plus facilement ou on se trouve sur le globe, et encore. C'est le problème de cette carte qui ne met pas en évidence une frontière potentiellement connue. Si on a une carte à cheval sur deux pays, la frontière partielle n'est pas vraiment suffisante pour reconnaire, alors que la même taille centré sur le pays hote est bien plus parlante. — Zebulon84 (discuter) 3 octobre 2017 à 10:22 (CEST)
Pour le coup 5 est inadapté pour une commune, un zoom de 9 à 11 me paraît mieux. 5 oui pour une Région/Lander/Canton de Suisse, mais pas pour une commune. Cdlt, Lyon-St-Clair [Hon hon hon] 3 octobre 2017 à 10:26 (CEST)
Tout dépend de ce que l'on veux montrer avec la carte. Si c'est pour montrer la forme, les limites de la comunes, 5 est inadapté, mais si on veux donner d'un coup d’œil la situation géographique 9 à 11 ne donne aucune indication, sauf si on a la chance d'avoir une ville connue juste à coté. Tu peux me dire ou est situé cette ville de la carte ci-dessous sans modifier le zoom ? Avec un Zoom 5 et un marqueur il n'y a aucun problème. — Zebulon84 (discuter) 3 octobre 2017 à 11:23 (CEST)
5 serait adapté si la décision de supprimer les cartes de géoloc par pays et subdivisions "classiques" est prise et adoptée une fois les cartes interactives en place, sinon tant que ça viendra en complément il vaudra mieux utiliser un zoom + élevé. Cdlt, Lyon-St-Clair [Hon hon hon] 3 octobre 2017 à 11:30 (CEST)
OK. Je ne vois pas l'intérêt d'avoir 36 cartes. Donc mon point de départ était effectivement une seule carte interactive, remplaçant la carte actuelle. Je vais réfléchir à proposer les deux options. — Zebulon84 (discuter) 3 octobre 2017 à 13:41 (CEST)
Reste un souci : Comment récupérer automatiquement les limites communales sans avoir à connaître l'id osm/wikidata (Q71 pour Genève) de l'article ? Cdlt, Lyon-St-Clair [Hon hon hon] 7 octobre 2017 à 11:53 (CEST)
Je viens de remarquer que Modèle:Infobox Stade utilise Module:Infobox/Fonctions/Géolocalisation pour générer une carte interactive lorsque géolocalisation n'est pas indiqué. Est-ce que Module:Carte interactive ne fait pas doublon ? Une autre question - qui rejoint celle de Lyon-St-Clair - si quelqu'un sait : pourquoi est-ce qu'avec Yankee Stadium (enlever géolocalisation de l'infobox) le stade est entouré alors que ce n'est pas le cas de Stade Nemesio Camacho El Campín ? Ça a forcément un rapport avec Wikidata, puisque Yankee Stadium n'est pas entouré dans Modèle:Infobox Stade#Exemples_d.27utilisation. Serait-ce simplement Key:wikidata que j'ai ajoutée mais qui demanderait peut-être un certain temps avant d'être mise à jour (voir aussi WIWOSM) ? The RedBurn (ϕ) 12 octobre 2017 à 12:48 (CEST)
À propos de la question des limites et de l'id osm, c'est bien lié à WIWOSM : c'est ce script qui donne les limites (et le centre si nécessaire) en établissant le lien entre l'objet osm et l'article via les clés wikipedia ou wikidata, mais il n'est mis à jour que la nuit. Exemple pour Genève. Correction : c'est mw:Extension:Kartographer qui établit le lien. Mais elle aussi ne semble mettre à jour les données qu'une seul fois par jour. The RedBurn (ϕ) 17 octobre 2017 à 07:58 (CEST)
Reste la question de doublon entre Module:Carte interactive et Module:Infobox/Fonctions/Géolocalisation. The RedBurn (ϕ) 12 octobre 2017 à 18:09 (CEST)

┌─────────────────────────────┘
Bonjour, J'ai vu que Ccmpg l'ajoutait de façon à donner ça ou ça, qui a pour gros défaut d'élargir inutilement l'infobox. Vous en pensez quoi ? Cdlt, Lyon-St-Clair [Hon hon hon] 15 octobre 2017 à 12:15 (CEST)

Au moment où je consulte, dans le premier cas c'est manifestement trop large, dans le second ça paraît bon.--Rehtse (échanger) 15 octobre 2017 à 12:33 (CEST)
Le second c'est normal, j'ai corrigé pour voir. Cdlt, Lyon-St-Clair [Hon hon hon] 15 octobre 2017 à 12:35 (CEST)
J'ai élargi l'infobox des comtés de Caroline pour avoir une vision complète et, me semblait-il, plus détaillé de l'État. Si cela dépasse une largeur définie collectivement, pas de problème, un niveau ou deux de zoom en moins et c'est fini. Cela partait d'une préoccupation qui s'applique à toute carte interactive : faut-il centrer la carte sur l'objet de l’article ou le situer d'abord par rapport à son contexte (ce que j'ai fait sur les comtés)? Cela permettrait de résoudre en partie la discussion ci-dessus au sujet du niveau de zoom, car le débat tourne autour l'intérêt de prendre de la hauteur ou pas. Que pensez-vous de celui-là maintenant? Et tant qu'on y est, que pensez-vous des légendes avec différentes entités administratives surlignées? ccmpg (discuter) 15 octobre 2017 à 18:33 (CEST)
Le résultat est superbe, ça change des cartes statiques ! Reste plus qu'à créer un modèle pour faciliter l'ajout des cartes avec légendes. Pour la question du zoom, l'actuel sur Comté de Franklin (Caroline du Nord) m'a l'air idéal : il montre le sujet (le comté) et l'entièreté de son contenant (la Caroline du Nord). The RedBurn (ϕ) 17 octobre 2017 à 08:14 (CEST)

{{inflation}}[modifier le code]

Bonjour,

Suite à cette discuss sur ma pdd, L'amateur d'aéroplanes m'indique de m'adresser ici pour proposer une modif sur {{inflation}}. En effet, lorsqu'il est utilisé, il donne des valeurs "de nos jours" ou "actuel" comme sur Course transaméricaine qui sont amha absolument pas encyclopédiques car in-interprétables tel quel. Il me semble plus judicieux que le modèle ajoute directement avec les mots magiques qu'il faut, les valeurs en mois année, par ex, "en novembre 2017" ou sous forme réduite "en nov. 2017" ou même au jour près, "le 29 novembre 2017", si vous le voulez et pour qu'il n'y ait plus d’ambiguïté. Donc merci d'avance aux modélistes capables de faire la modif aussi parce que perso, j'en suis totalement incapable! -- Titou (d) 29 novembre 2017 à 10:20 (CET)

On pourrait rajouté valeur actuelle dans le corps du modèle ? L'amateur d'aéroplanes (discuter) 29 novembre 2017 à 10:25 (CET)

Modèle:Imdb personnage[modifier le code]

Je l'ai mentionné en page de discussion du modèle, mais comme elle semble peu suivie, je préfère me répéter ici : Internet Movie Database a annoncé des changements importants concernant les pages Personnages, à compter du 6 décembre prochain : l'annonce ici (en gros, retrait des pages de ce type et intégration progressive des contenus dans les pages des films). Ça risque d'avoir une incidence majeure sur ce modèle très utilisé... -- BeatrixBelibaste coin causerie 4 décembre 2017 à 20:35 (CET)

Merci pour l'info.
Il faudrait encore plus signaler cela au projet cinéma. - Eric-92 (discuter) 5 décembre 2017 à 00:48 (CET)
Je suggère d'attendre quelques semaines : l'IMDb procède effectivement à des changements assez lourds (d'après ce que Col Needham vient de confirmer, ils doivent décommissionner les anciennes plateformes au 31 décembre), donc ils ont fait une migration à marche forcée, en introduisant des régressions, y compris les pages de personnages. En revanche, leur cible sur les nouvelles plateformes sont beaucoup plus floues, et apparemment changeantes en fonction des réactions (assez outrées) sur le forum http://www.getsatisfaction/com/imdb. Ca n'engage que moi mais les pages de personnages devraient réapparaître à terme, probablement avec une nouvelle URL. Wait and See? -- Fourvin mais appelez-moi Vincent - 20 décembre 2017 à 12:00 (CET)

Carte de localisation multipoints[modifier le code]

Bonjour, Y a-t-il une raison pour que wp:fr n'utilise pas ce modèle en:Template:Location map many pourtant utilisé par plusieurs wikis ? --Yanik B 22 décembre 2017 à 14:04 (CET)

Le fait que les modèles disparaissent de la prévisualisation peut dans certains cas être un réel problème.[modifier le code]

Bonjour,

Quand un modèle est utilisé en haut d'un RI, il disparait de la prévisualisation. Existe-t-il un moyen de lui proposer un affichage alternatif comme pour les images ? car dans le cas (par exemple) d'un synonyme faisant partie d'un jargon non francisé mais d'usage très répandu, le fait qu'il soit occulté devient un réel problème. -- Camion (discuter) 2 février 2018 à 10:51 (CET)

Bon, discussion ici. -- Camion (discuter) 2 février 2018 à 15:17 (CET)

Modèle AnnCin[modifier le code]

Bonjour, il est indiqué sur le modèle {{AnnCin}} que celui-ci doit être substé, car il alourdirait le code. Pourtant, l'avantage de ce modèle est que, quand un contributeur veut modifier une date, il ne risque pas de provoquer une anomalie en créant une différence entre la date contenue dans le lien et celle qui est affichée. Est-ce que l'avertissement concernant la nécessité de subster est toujours d'actualité ?--Rehtse (échanger) 4 février 2018 à 11:12 (CET)

Suppression unilatérale des liens-dates dans {{Article}} (et autres ?) ?[modifier le code]

Bonjour, Faute de réponse hier sur le Bistrot, je me permets de réitérer ma question ici aujourd'hui : pourquoi, dans le modèle {{Article}}, la mise en forme de la date avec {{date}} ne met-elle plus en forme la date justement ? (Voir par exemple dans Yoshihide Kozai, section Bibliographie.) Dans la mesure où la mise en forme se faisait très bien jusqu'alors, je ne peux que supposer un forcing (introduit volontairement ou non) dans le code du modèle pour empêcher toute mise en forme. Quelqu'un en saurait-il plus ? Merci d'avance. SenseiAC (discuter) 18 février 2018 à 11:13 (CET)

Bonjour SenseiAC, je n'ai pas vu de changement récent dans les historiques, mais je ne suis pas un spécialiste. Peut-être en mai 2015. Le paramètre date du modèle {{Article}} est formaté par l'équivalent du modèle {{date-}}. As-tu une idée de la période au cours de laquelle tu pouvais voir une date avec des liens ?--Rehtse (échanger) 18 février 2018 à 15:27 (CET)
Notification Rehtse : le changement doit être récent : a priori les liens existaient encore dans les jours qui précèdent ma demande ; je ne pense pas avoir « rêver » des liens bleus/verts depuis plus de deux ans. Quoi qu'il en soit, que ce soit nouveau ou pas, je ne vois aucune justification du fait d'imposer l'absence de liens sur les dates. SenseiAC (discuter) 4 mars 2018 à 12:10 (CET)
Notification SenseiAC : la suppression effective des liens sur les dates des modèles Article, Ouvrage… provient de cette modification de novembre 2015, sur le modèle date, mais en toute connaissance de son effet sur les modèles biblio. L’intérêt des liens sur les dates est faible, et ne devrait être présent que sur les dates pertinente par rapport au sujet de l’article. Les dates des références ne sont pas vraiment liè au sujet de l’article puisque c’est la date à laquelle un journaliste / scientifique / historien a publié, potentiellement des siècles plus tard. Je considère donc qu’il ne devrait pas y avoir de liens sur ces dates. Cela ne me semble pas être un point de vue unique, mais ce qui se dégage des discussions récurentes sur le bistrot à propos des liens sur les dates. — Zebulon84 (discuter) 11 mars 2018 à 09:42 (CET)
Notification Zebulon84 : il y a erreur quelque part : le modèle {{date}} met bien les liens en lui-même ; c'est le modèle {{date-}} pour ne pas mettre de lien (à quoi est-ce que ça sert donc, je vous le demande : équivalent d'un {{nobr}} ?). Enfin bref, quoi qu'il en soit, il y a une différence entre laisser le choix de mettre ou non les liens et imposer l'absence de tout lien. Ici, on a interdit de fait de mettre quelque lien que ce soit, sans une quelconque décision validant cette décision, ce que je ne puis que déplorer. SenseiAC (discuter) 11 mars 2018 à 15:35 (CET)
Notification Rehtse et Zebulon84 : je remarque que si on met un lien « standard », genre « 2018 », alors on a le lien comme normalement. Le fait que seuls les liens générés par {{date}} soient supprimés constitue donc un non-sens en pratique. SenseiAC (discuter) 26 avril 2018 à 11:12 (CEST)
Notification SenseiAC : ??
{{article | titre = Blabla |périodique = Journal | date = [[2018]] }} → « Blabla », Journal,‎
Je ne vois pas de lien sur la date. Ai-je mal compris ta dernière remarque ? — Zebulon84 (discuter) 28 avril 2018 à 03:25 (CEST)
Quelle est l'utilité d'un lien sur une date qui n'a rien à voir avec le sujet de l'article ? De plus la tendance est à la suppression des liens sur les dates hormis {{date de naissance| }} et {{date de décès| }}, une seul fois dans l'article, généralement dans l'infobox, uniquement pour les robots. Cordialement --- Alaspada (d) 28 avril 2018 à 06:56 (CEST)

Évolution démographique[modifier le code]

Bonjour, Je ne sais pas si c'est le bon endroit, mais il y a un chevauchement des chiffres dans les tableaux des évolutions démographiques des unités ou aires urbaines de plus d'un million d'habitants voir par exemple Unité urbaine de Lyon. Si quelqu'un pouvait le réglé ou me dire ou m'adresser ? Ps : le problème n'est apparent pas sur tout les écrans ou PC ? --Paternel 1 (discuter) 13 mars 2018 à 09:28 (CET)

TemplateStyles : une amélioration significative pour faciliter l'utilisation des CSS[modifier le code]

Enregistré sur Phabricator
Tâche 191452

Le vote est terminé et un ticket a été ouvert sur le Phabricator, l'issue du sondage n'ayant plus aucune chance de s'inverser.

Bonjour à tous les modélistes.

L'extension TemplateStyles est passée très récemment en version stable, le 26 mars. Cette extension permet une certaine flexibilité pour gérer l'apparence des modèles. Par exemple, elle permettra une meilleure adaptabilité aux différents types d'écran : plus besoin de cacher des modèles aux lecteurs mobiles. Plus besoin d'allonger MediaWiki:Common.css qui devient lourde.

Comment cela marche ?

  1. Stocker une feuille de style (CSS) dans une page du namespace Modèle:

La feuille de style sera à insérer obligatoirement dans une page ou sous-page de ce namespace et doit finir par l'extension .css dans le titre pour que le logiciel Mediawiki puisse assainir le code CSS, permettant d'éviter de charger des propriétés cassées. Cette restriction qui est là des raisons de sécurité peut visiblement être évitée par les administrateurs grâce à la page spéciale Special:ChangeContentModel.

Il faut alors appeler la feuille de style grâce à la balise <templatestyles src="[la page.css]" />.

Utilisations possibles[modifier le code]

Au niveau des utilisations possibles, elles sont multiples :

  • alléger MediaWiki:Common.css, la feuille de style commune qui est chargée sur les toutes les pages et qui permet aujourd'hui d'afficher correctement certains éléments comme ceux de la page d'accueil, ou les infobox.
  • créer des sous-pages par fonction, il est alors plus facile de retrouver la page qui gère le visuel d'un modèle.
  • utiliser une feuille de style commune pour créer des apparences adaptatives à la taille de l'écran que les projets pourront utiliser par exemple, etc.
  • pleins d'autres modifications qui vont dans le sens de la recommandation sur l'accessibilité.

Sécurité[modifier le code]

En séparant la feuille de style sur une page spécifique, on peut protéger cette page et laisser le modèle modifiable par tout le monde si ce n'est pas un modèle à risque. En effet, laisser la feuille de style d'un modèle à risque pourrait nous amener à de nombreux problèmes visuels : des vandalismes comme en 2008 en modifiant des modèles très utilisés et non protégés à l'époque.

Les développeurs ont souligné les points ci-dessous :

  • les feuilles de style ajoutées par TemplateStyles sont encadrées pour éviter d'affecter l'interface utilisateur qui sont en dehors de la section de l'article.
  • aucune injection d'éléments non reconnue dans une feuille de style ne peut être faite sur la page générée ;
  • il n'existe aucun moyen d'exécuter du javascript avec ces feuilles de style (certaines propriétés et valeurs sont connues pour pouvoir le faire dans plusieurs navigateurs plus anciens) ;
  • il n'existe aucun moyen pour ces feuilles de style de demander au navigateur internet d'accéder à des ressources externes des projets Wikimedia (images, vidéos, etc).

Pour plus d'informations sur la sécurité, voici le message des développeurs : « TemplateStyles inclut un analyseur complet qui contrôle tout le code et supprime les règles des feuilles de style qui ne correspondent pas à une liste blanche. L'analyseur est suffisamment mature pour rejeter les ressources extérieures (telles que les images d'arrière-plan) tout en autorisant les ressources locales [Commons par exemple]. Les sélecteurs des feuilles de style sont réécrits de sorte qu'ils ne peuvent pas se référer à des éléments extérieurs au contenu de l'article ». Ce n'est donc pas si dangereux qu'il n'y paraît.

Conclusion[modifier le code]

Cet ajout de l'extension a déjà été proposé par Melamrawy (WMF) le mois dernier, mais son message est passé inaperçu. Je viens recueillir des premiers avis des personnes directement concernées par cette extension. S'il y a consensus sur cette PDD, je pourrai peut-être ouvrir un sondage ? Si ce dernier est positif, j'ouvrirai un ticket sur le Phabricator pour ajouter l'extension à frwiki.

Note : extension déjà déployée sur Wikivoyage, Mediawiki, Labswiki, Wikipédia en suédois. Demandes faites pour le Wikipédia en russe, allemand et chinois. Notif à Framawiki qui a suivi l'extension sur le Phabricator. Lofhi me contacter 28 mars 2018 à 17:58 (CEST)

Au vu de l'enthousiasme, je pense que tu peux faire la demande sur Phabricator sans plus tarder Mort de rire od†n ↗blah 3 avril 2018 à 20:06 (CEST)
Je ferai ça dans la nuit alors, Od1n, ce mini sondage n'ayant pas de durée minimum à respecter (ou demain, ça fera au moins 7 jours) ! Lofhi me contacter 3 avril 2018 à 20:24 (CEST)
Merci pour cet enthousiasme ! Trizek (WMF) (discuter) 4 avril 2018 à 17:01 (CEST)
Un ticket a été ouvert sur le Phabricator, accessible ici ! Merci à tous. Lofhi me contacter 4 avril 2018 à 19:47 (CEST)

Votes[modifier le code]

Pour[modifier le code]

  1. Pour fort Belle présentation, merci ! Aussi pour information, refs les annonces précédentes de ce système, dans les "Tech News". od†n ↗blah 28 mars 2018 à 18:46 (CEST)
  2. Pour très bien dans l'idée, mais devoir protéger manuellement chacune des sous-pages me semble contraignant, et source d'oublis. Sais tu si il y a la possibilité via la configuration de l'extension d'interdire les modifs aux non-admins/sous pages, par défaut ? Si rien de tel n'est prévu, on devrait pouvoir utiliser MediaWiki:Titleblacklist pour protéger toutes sous pages de l’espace modèle finissant par .css. --Framawiki 28 mars 2018 à 19:43 (CEST)
    Salut Framawiki ! J'ai suivi de loin l'extension et les tickets liés à l'extension, selon phab:T187729, en l'état, les développeurs ne compte pas ajouter des restrictions en fonction des groupes du contributeur si ce n'est pas considéré comme une fonctionnalité voulue par plusieurs communautés. Ils ne voient pas pourquoi ils devraient en l'état ajouter ce type de restriction puisqu'elle n'existe pas pour les modèles ou les modules. Par contre, il semblerait qu'il soit possible d'utiliser Titleblacklist selon un commentaire dans le ticket. Le ticket a été refusé, car l'extension a été le sujet d'un compte rendu sur sa sécurité, voir phab:T133408. Ils ont conclu que ces pages CSS pourront subir le même type de vandalisme comme n'importe quelle page et que donc, il faut essayer de prendre du recul sur le risque réel : un modèle peut très bien être modifié et causer un problème par exemple. Le vandalisme qui pourra être fait sur ces pages qui fonctionneront avec l'extension ne sera pas différent du vandalisme déjà possible en modifiant les attributs CSS inline, par exemple via les tableaux ? Dans le pire des cas, les développeurs de l'extension rappelle qu'il est possible de s'appuyer des filtres pour lister les changements réalisés, il semblerait qu'ils porteront un tag. Plus d'infos sur Quelles fonctionnalités anti-abus sont fournies.
    C'est une vision des choses que je soutiens, mais en effet, cela peut poser problème pour d'autres. Néanmoins, les ajouts à travers cette extension sont tellement utiles que je pense qu'on peut envisager l'activer : le wiki en suédois n'a pas rapporté de problèmes de vandalisme après plus d'un mois d'utilisation. C'est un premier pas. De toute façon, j'imagine le code CSS des modèles à risque seront automatiquement protégés. Lofhi me contacter 28 mars 2018 à 20:24 (CEST)
    Effectivement, puisque rien n’empêche la modification des css des div des modèles ou des pages... Merci pour tes précisions. --Framawiki 28 mars 2018 à 21:15 (CEST)
    On a déjà eu divers vandalismes occupant tout l'écran en page d'accueil sans avoir besoin de l'extension. Orlodrim (discuter) 28 mars 2018 à 22:45 (CEST)
  3. Inutile de proposer un sondage si personne ne vient s'y opposer ici. C'est utile et au point ou non : n'en verront quelque chose que ceux qui l'utiliseront. TigH (discuter) 28 mars 2018 à 21:27 (CEST)
  4. Pour Rien que pour les pictogrammes d'infobox, ce serait déjà pas mal. Orlodrim (discuter) 28 mars 2018 à 22:45 (CEST)
  5. Pour Si je comprend bien, c'est un système de templating semi-dynamique, ce sera super utile et bien plus modulaire! :D --Lrq3000 (discuter) 28 mars 2018 à 23:40 (CEST)
  6. Pour cela ne peut être qu'un plus. Quand à la sécurité, à partir du moment où MediaWiki parse le CSS pour le nettoyer, il n'y a pas de raison d'avoir des craintes particulières. Ce n'est pas plus "dangereux" que les autres vandalismes habituels (ça ne concerne que l'affichage). --Tractopelle-jaune (discuter) 29 mars 2018 à 08:33 (CEST)
  7. Pour Merci SourireArkanosis 29 mars 2018 à 14:06 (CEST)
  8. Pour fort Encore un incroyable travail ! Bravo et félicitations ! Sourire Menthe à l'Eau - 2 avril 2018 à 01:28 (CEST)
  9. Pour fort Merci Clin d'œil infiniment @Lofhi! proposition magnifique Sourire ! Danfarid133 (discuter) 2 avril 2018 à 10:23 (CEST)
  10. Pour En accord avec les avis précédents. Merci pour cette action ! F123 (discuter), le 2 avril 2018 à 18:03 (CEST)
  11. Pour Kropotkine 113 (discuter) 3 avril 2018 à 17:32 (CEST)
  12. Pour Ça a l’air bien. — Thibaut (discuter) 3 avril 2018 à 18:02 (CEST)
  13. Pour fort Gnii Rien à dire proposition parfaite. Tomybrz Bip Bip 3 avril 2018 à 18:15 (CEST)
  14. Pour — Like tears in rain {-_-} 3 avril 2018 à 18:27 (CEST)
  15. Pour enfin ! — 0x010C ~discuter~ 3 avril 2018 à 18:49 (CEST)
  16. Pour fort Bien sûr ! Aidera beaucoup tous les amateurs de graphismes développés et modernes ! --Niridya (discuter) 3 avril 2018 à 19:48 (CEST)
  17. Pour si on peut réduire les css inline, notamment pour les tableaux, ce sera un net avantage. — Zebulon84 (discuter) 4 avril 2018 à 04:57 (CEST)
  18. Pour R [CQ, ici W9GFO] 4 avril 2018 à 07:51 (CEST)
  19. Pour VateGV taper la discut’ 4 avril 2018 à 12:54 (CEST)
  20. Pour Facilite la maintenance et augmente la flexibilité, et malgré l'effort d'implantation (maintenance du code CSS global, protection des nouvelles pages CSS). — Cantons-de-l'Est discuter [‌opérateur] 4 avril 2018 à 13:34 (CEST)
  21. Pour Cela facilitera grandement les élaborations de modèles pour pages de portails, projets, etc. -- J. N. Squire[Discussion constructive] 4 avril 2018 à 15:15 (CEST)
  22. Pour cf. Discussion Wikipédia:Prise de décision/Unification des Portails et Projets de Wikipédia#L'unification c'est bien, mais comment ? => On ne peut qu'approuver ce que dit Lofhi ! Rendre accessible Wikipédia aux mobiles et aux tablettes, c'est essentiel. Merci à tous ceux qui travaillent sur l'extension TemplateStyles. --Marilouw (discuter) 4 avril 2018 à 19:18 (CEST)
  23. Pour --- Alaspada (d) 4 avril 2018 à 20:47 (CEST)
  24. PourShjup[ Me parler ] 4 avril 2018 à 21:25 (CEST)
  25. Pour --Achenald (discuter) 5 avril 2018 à 14:14 (CEST)

Contre[modifier le code]

Neutre[modifier le code]

Suivi du déploiement de l'extension[modifier le code]

En attente[modifier le code]

Voici le message de l'un des développeurs : « Je suis tellement content que les Wikipediens francophones s'intéressent aux TemplateStyles !

Comme indiqué ci-dessus, l'extension TemplateStyles ne peut pas être déployée tant que la migration vers RemexHtml n'est pas terminée. Si vous souhaitez accélérer les choses, je vous suggère de lire les instructions à l'intention des éditeurs pour aider à la migration. Si vous pouvez réduire le nombre d'erreurs de priorité haute, vous pouvez passer à Remex plus tôt et l'extension TemplateStyles pourra être déployée. Ne vous laissez pas intimider par le nombre d'erreurs qui s'y trouvent, car de nombreuses erreurs pourraient provenir de modèles qui, s'ils sont corrigés, pourraient résoudre des centaines d'erreurs en une seule fois.

Merci ! » Lofhi me contacter 6 avril 2018 à 15:51 (CEST)

Date du déploiement[modifier le code]

Bonjour, Od1n, Framawiki, TigH, Orlodrim, Signimu, Tractopelle-jaune, Arkanosis, Menthe 555, Danfarid133, F123, Kropotkine_113, Thibaut120094, Tomybrz, Like tears in rain, 0x010C, Niridya, Zebulon84, Reptilien.19831209BE1, VateGV et Cantons-de-l'Est, J. N. Squire, Marilouw, Alaspada, Shjup et Achenald.

Après le sondage fait en avril et la migration vers RemexHtml effectuée le 5 juillet, l'extension TemplateStyles devrait être déployée autour du 19 juillet. Il y a eu un consensus pour son activation, mais pas de discussion autour de l'encadrement de la fonctionnalité. L'idée la plus logique qui est apparue suite aux discussions sur Phabricator est de mettre en place la même protection à une feuille de style que celle du modèle à laquelle elle est liée.

En suivant de loin les autres idées des différentes communautés, certains proposaient de bloquer l'édition de ces feuilles de style à ceux qui ne sont pas dans un certain groupe. Cela ne sera pas possible, car la proposition a été déclinée (voir cette tâche sur Phabricator) pour diverses raisons non-techniques. Néanmoins, si plusieurs communautés jugent que cela est nécessaire, ils envisagent volontiers de reconsidérer leur choix.

Il y a aussi l'idée de Framawiki, également citée sur Phabricator, de passer par MediaWiki:Titleblacklist pour protéger toutes sous pages de l'espace modèle finissant par .css.

C'est donc un simple message pour vous avertir. Je ne sais pas si nous aurons le droit à un message officieux lors de l'activation de l'extension, autant s'organiser avant. Si vous avez d'autres idées... ! Lofhi me contacter 12 juillet 2018 à 09:14 (CEST)

Je ne vois aucune raison de vouloir protéger spécialement ces pages, contrairement aux autres pages .css, avec TemplateStyles le CSS est « nettoyé ».
Ensuite, là où le risque de vandalisme en tout genre est le plus élevé, c'est sur le modèle lui-même, pas sur le CSS, rappelons que l'on peux très bien mettre du CSS (localisé au modèle) à l'arrache dans un modèle avec style="". Pourtant, on ne protège bien évidement pas tous les modèles.
D'autant plus que vu le projet de la WMF de restreindre l'édition du code CSS et JS à certains admins seulement à cause des risques que cela implique potentiellement (Wikipédia:Bulletin des administrateurs/2018/Semaine 28#Création groupe administrateur pour la modification des CSS et JS globaux), il est d'autant plus pertinent d'avoir une extension comme TemplateStyles permettant d'éviter de demander à un admin autorisé d'aller mettre ou modifier du CSS dans common.js ou autre à chaque fois.
Si TemplateStyles a été créé, c'est justement de pouvoir fournir un outil plus sécurisé que l'édition directe de fichier .css, pouvant être accessible aux non-admins.
Ce serait une hérésie totale de vouloir appliquer des restrictions inverses aux motivations qui ont justement amenées à la création de cet outil, à savoir une édition du CSS non restreinte aux admins).
Donc je suis contre la protection de ces pages au-delà du niveau de protection du modèle lui-même (et l'inverse pourrait même être parfois pertinent, on a régulièrement des modèles sous protection, mais avec des sous-modèles qui sont eux sous SPE pour permettre quand même leur modification par les autopatrolled, dans certains cas, il pourrait aussi être pertinent d'appliquer une SPE au fichier .css, comme pour les sous-modèles).
--Tractopelle-jaune (discuter) 12 juillet 2018 à 09:43 (CEST)
Excellente nouvelle, merci ! Sourire
Plus qu'une protection ou la restriction de l'édition à certains groupes, ce qu'il faudrait à ce genre de pages encore plus qu'aux pages de contenu que l'on protège aujourd'hui, c'est mw:Extension:FlaggedRevs.
À défaut, je ne suis pas favorable à un niveau de protection supérieur à celui des modèles associé, d'une part parce que cela limite la possibilité de contribuer, et d'autre part parce que ça n'apporte qu'une illusion de protection dans la mesure où les possibilités du modèles restent les mêmes.
Amicalement — Arkanosis 12 juillet 2018 à 10:45 (CEST)
Je partage les deux avis ci-dessus donc je vais pas redire la même chose. En tout cas, ça sera très utile d'avoir TemplateStyle et je préfère que le CSS ne soit pas protégé, ou, s'il faut les protéger, je pense qu'il ne faut pas aller au delà des autoconfirmed. --Niridya (discuter) 12 juillet 2018 à 11:39 (CEST)
Du même avis. — Zebulon84 (discuter) 12 juillet 2018 à 18:43 (CEST)
Bien ! Cela semble coller avec l'idée que les développeurs ont de leur extension : ils ont refusé toute tentative de surprotection de ces pages, expliquant que les risques de vandalismes sont identiques au reste, pas besoin d'un traitement d'exception. Lofhi me contacter 13 juillet 2018 à 21:14 (CEST)

Carte interactive dans les infobox[modifier le code]

Bonjour, Les infobox en Lua affichent une géolocalisation avec une carte interactive si le paramètre géolocalisation n'est pas renseigné ({{Infobox Aire protégée}}). En attendant que les autres infobox soient réécrites en Lua, ne serait-il pas pertinent de modifier les infobox contenant une géolocalisation pour permettre d'utiliser une carte interactive pour la géolocalisation ? Merci de vos avis. --Yanik B c:file:Flow-ads.png 6 avril 2018 à 14:37 (CEST)

Flex Box CSS[modifier le code]

Bonjour à tous les modélistes Sourire
Avez-vous des exemples de pages utilisant des Flex Box CSS ? Plus précisément, je cherche à placer des boites sur deux colonnes, afin de remplacer le tableau qui fait office de mise en page sur ce portail : Portail:Droit français.
Merci d'avance, Cordialement, --Marilouw (discuter) 9 avril 2018 à 21:19 (CEST)

Je ne sais pas ce que c'est que des flex box CSS (je suis pas spécialiste en CSS), mais j'ai déjà eu recours aux modèles {{Début de colonnes}} et {{Fin de colonnes}} combiné à {{Début de bloc solidaire}} et {{Fin de bloc solidaire}} lors de remplacements de tableaux de mise ne page, par exemple sur l'article Liste des pays par PIB (PPA).
Après, je ne sais pas si ça peut t'aider, ou si tu parle d'autre chose.
--Tractopelle-jaune (discuter) 9 avril 2018 à 22:31 (CEST)
Conflit d’édition
Notification Marilouw : il en en a eu en page d'acceuil pendant quelques mois (octobre 2016 à mars 2017). Tu peux en voir un brouillon encore fonctionnel sur Utilisateur:Zebulon84/Brouillon7. — Zebulon84 (discuter) 9 avril 2018 à 22:55 (CEST)
Ah ça peut être une solution aussi le modèle début/fin de colonne Sourire, merci ! Sinon (au pire) je pensais utiliser des balises < div >, avec des largeurs en pourcentage (deux colonnes de 50% de largeur), est-ce une bonne façon de faire en terme d'accessibilité ?
Merci d'avance,--Marilouw (discuter) 9 avril 2018 à 23:20 (CEST)
Merci beaucoup Notification Zebulon84 : pour le brouillon, je regarde ça demain ! Sourire --Marilouw (discuter) 9 avril 2018 à 23:57 (CEST)

Bandeaux qui ne sont pas encore adaptés au site mobile[modifier le code]

Bonsoir, pour information, dans le but d'essayer gérer l'affichage des bandeaux de maintenance sur le site pour téléphones mobiles, la WMF a fait une étude sur les dix plus grands wikis phab:T189132. Des statistiques ont ainsi été produits, et montrent que 69% des bandeaux de Catégorie:Modèle_de_bandeau_d'article ont une partie de leur contenu qui peut être masquée avec la sélection CSS .bandeau-titre ~ p. Une page avec un tableau comparant modèles complets et versions simplifiées a été générée [1]. --Framawiki 11 avril 2018 à 19:07 (CEST)

Modèle:Categ incident aérien[modifier le code]

Sur une catégorie, comment faire un chaînage pour aller directement sur une autre année ? La traduction de en:Template:Cat topic in year. J'ai essayé de créer un modèle, (qui est inséré sur Catégorie:Accident ou incident aérien en 2018, mais qui est incomplet); il fonctionnerait exactement comme sur la page anglaise (de 2018 on peut aller à plusieurs années facilement). J'ai créé Modèle:Cat sujet par année ,je crois que c'est par là qu'il faut commencer, mais ensuite ? Je sèche. --Io Herodotus (discuter) 20 mai 2018 à 17:30 (CEST)

Notification Io Herodotus : voir le modèle {{Décennie}} et éventuellement les modèles {{Méta chronologie}} et {{Méta chronologie avec décennies}}Zebulon84 (discuter) 21 mai 2018 à 05:30 (CEST)

Modèle:Sommaire sur mesure[modifier le code]

J'ai l'impression que le paramètre border ne fonctionne pas. Si quelqu'un peut regarder ce qui ne va pas :

Sommaire :

Pour pouvoir mettre un signe entre les sections du sommaire, j'ai créé un modèle d'essai Modèle:Sommaire sur mesure bis

Sommaire : AB C-E X 0-9
Sommaire : A · B · C-E · X · 0-9

mais il apparaît le signe en fin de liste, ce qui n'est pas super. Si quelqu'un a une idée...

(j'ai également corrigé le paramètre align, mais je pense qu'il faut revoir ce paramètre de telle sorte que quand il n'est pas rempli on ait le paramètre = center par défaut).

Berdea (discuter) 23 mai 2018 à 01:30 (CEST)

Berdea : ça devrait être bon, j'ai mis à jour la documentation pour le paramètre borderwidth. Cordialement, Lofhi me contacter 23 mai 2018 à 07:29 (CEST)

Merci, on avance

  • Je vois que quand on ne met rien sur borderwidth et quand border contient une valeur, on a par défaut borderwidth=3px. Je pense qu'il faudrait plutôt mettre borderwidth=1px
Sommaire :
Sommaire :
Sommaire :
Sommaire :
  • Tu n'as pas regardé le paramètre align ?
  • Concernant Modèle:Sommaire sur mesure bis, tu as simplement mis le signe avant, plutôt que après. C'est d'ailleurs ce que j'avais fait en premier. Mais je me suis retrouvé sur la page Portail:Langue catalane (section introduction) avec le point en début de la 2e ligne (ce n'est plus le cas aujourd'hui), du coup j'avais mis le signe derrière, avec le problème que j'ai signalé. N'aurais-tu pas une autre solution ?
  • Une fois qu'on aura bien testé, je propose de mettre ce nouveau paramètre dans le Modèle:Sommaire sur mesure et de supprimer Modèle:Sommaire sur mesure bis. Qu'en penses-tu ? — Berdea (discuter) 23 mai 2018 à 12:21 (CEST)
Notification Berdea : j'ai mis
  • une bordure de 1px par défaut ;
  • une liste horisontale pour séparer les paramètres (et c'est probablement mieux coté accéssibilité) ;
  • aligné via une class plutôt qu'un attribut HTML obsolète. J'avais toujours le sommaire centré par défaut, mais visiblement ce n'est plus la cas pour tout le monde.
Zebulon84 (discuter) 23 mai 2018 à 12:56 (CEST)

Modèle:Instructions pAdQ[modifier le code]

1er avis[modifier le code]

A mon avis, il y a un problème avec la page documentaire du Modèle:Instructions pAdQ. Si quelqu'un peut aller voir. — Berdea (discuter) 30 mai 2018 à 13:53 (CEST)

Retouché. C'est mieux ? — Zebulon84 (discuter) 30 mai 2018 à 15:58 (CEST)
Beaucoup mieux. Mais pourquoi le sommaire est-il placé là où il est placé ? — Berdea (discuter) 30 mai 2018 à 18:29 (CEST)
Notification Berdea : Parceque le modèle imposse le placement du sommaire à droite après le cadre gris. Voir par exemple cette page où il est utilisé.
Tu peux le préciser dans la documentation du modèle si tu penses que c'est nécessaire.
Et si tu trouves que ce déplacement du sommaire sur toutes les pages où le modèle est utilisé est inutile et génant, tu peux supprimer {{sommaire à droite}} du code du modèle.
Zebulon84 (discuter) 30 mai 2018 à 19:10 (CEST)
Pour l'instant on peut laisser comme cela. Ta correction était plus importante. — Berdea (discuter) 31 mai 2018 à 03:46 (CEST)

Puis-je me permettre de te demander de jeter un oeil sur :

Berdea (discuter) 31 mai 2018 à 05:02 (CEST)

Notification Berdea : je ne vois pas le problème pour Modèle:Bons portails : le modèle a un paramètre obligatoire, s'il n'est pas saisi (ou mal saisi), le modèle affiche une erreur, la documentation met un exemple pour montrer que le modèle affiche cette erreur. Si ça ne te plais pas, modifie la documentation.
Fait pour les deux autres.
Zebulon84 (discuter) 31 mai 2018 à 12:46 (CEST)
Pour le Modèle:Bons portails, en fait j'ai lu trop vite et j'ai pensé que c'était une erreur de syntaxe. Désolé.
Pour les autres modèles, merci.
Berdea (discuter) 31 mai 2018 à 12:57 (CEST)

2e avis[modifier le code]

Je reviens ici et sans doute vers Zebulon84 qui s'est intéressé à ma question.

Berdea (discuter) 3 juin 2018 à 19:26 (CEST)

Notification Berdea :
    • La documentation contient __NOTOC__, ce qui désactive l'affichage du sommaire, et ces modèle n'utilise pas {{sommaire à droite}}. Si on veux uniformiser, je propose plustôt de supprimer ce modèle {{sommaire à droite}} sur ceux qui l'on.
    • Sur certain modèle le code du modèle est entre balises <includeonly></includeonly> et le modèle ajouté dans la documentation (ce que j'ai fait pour que le sommaire ne soit pas avant la documentation, suite à tes remarques précédentes), sur les autres le modèle n'est pas dans la documentation, mais directement affiché.
    • je serai plutôt partisant de supprimer ce message {{Modèle à subster}}.
  1. Voir mw:Help:Magic_words/fr#Espaces de noms : {{SUBJECTSPACE}} affiche « Portail » si tu es sur un portail ou une page de discussion de portail, rien dans l'espace principal ou une page de discussion d'article (et « Projet » ici). Pas vraiment d'avis sur l'intérêt de dupliquer les modèles. Peut-être qu'une simple redirection suffit si le texte est déjà bon ?
Zebulon84 (discuter) 5 juin 2018 à 21:27 (CEST)

Supprimer l'{{Infobox Commune}} utilisée nulle part (et buggée) ?[modifier le code]

Bonjour,

Est-ce qu'il vous parait judicieux de supprimer (ou rediriger ?) l'{{Infobox Commune}}, utilisée nulle part, et buggée.

Je suis tombée dessus par hasard sur le seul article où elle était utilisée, Timia (d · h · j · ) (seule l'image s'affichait).

Je l'ai remplacée par l'{{Infobox Localité}} (j'ai regardé ce qui était utilisé sur un autre article proche), qui fonctionne correctement.

Voir la différence : avant et maintenant.

Je sais pas trop d'où viennent ces bugs, ni à quoi devait servir cette infobox, mais comme elle n'est maintenant plus utilisée nulle part dans l'espace principal, et n'a jamais été corrigée depuis sa création en février 2015 par Notification Karima Rafes (qui n'a plus contribué depuis fin janvier), et qu'elle est source d'erreurs (utilisation possible dans un article d'une infobox buggée), je prose qu'elle soit supprimée, ou transformée en redirection vers l'infobox la plus appropriée (je sais pas laquelle est la plus appropriée entre les infobox localité, Infobox Subdivision administrative, et compagnie).

On a déjà assez d'infobox comme ça à maintenir à mon avis pour éviter de se traîner dans les pattes une infobox buggée et inutilisée, qui risque de se retrouver à nouveau sur des articles.

--Tractopelle-jaune (discuter) 3 juin 2018 à 14:02 (CEST)

Je préférerais qu'on la remette en état, plutôt que d'utiliser {{Infobox Localité}} pour des communes alors qu'elle doit être utilisée pour des localités et pas pour autre chose (comme des bâtiments ou des rues par fainéantise). Cdlt, Lyon-St-Clair [Hon hon hon] 3 juin 2018 à 14:07 (CEST)
J'ai supprimé le module:Infobox/Commune qui n'était qu'une ébauche, et redirigé {{Infobox Commune}} vers {{Infobox Localité}}. — Zebulon84 (discuter) 3 juin 2018 à 18:19 (CEST)

Corrections de modèles de section[modifier le code]

1er modèle : Portail:Langue catalane/Section

  • Il m'a été proposé d'arrondir légèrement les angles du cadre. Du coup, j'ai ajouté border-radius:8px;. Mais le rectangle de couleur sort du cadre arrondi. Pourriez-vous arranger les choses ?
  • J'ai mis des commentaires invisibles pour comprendre quelque chose au modèle (ou en tout cas pour en modifier facilement les paramètres). Vous pouvez compléter à votre guise.
  • Je vois le code -moz-border-radius:8px;. Savez-vous à quoi cela correspond ?

2e modèle : Portail:Reconquista/Section

Berdea (discuter) 4 juin 2018 à 01:30 (CEST)

Notification Berdea :
  • si le titre n'est pas arrondi, sa couleur dépasse des coins arrondi du cadre dans lequel il est. Il faut donc aussi ajouter des coins arrondis sur le <h2>, avec 1 pixel de moins car la bordure fait 1 pixel ; il ne faut mettre ces arrondis qu'en haut, sinon c'est pas très joli → j'ai ajouté border-radius:7px 7px 0 0;
  • -moz-border-radius permettait d'ajouter des arrondis pour firefox avant que la norme border-radius soit officielle et supportée par Firefox. Firefox ne les reconnais plus depuis Firefox 13, donc il recommender de les supprimer, c'est du code qui ne sert plus à rien.
Zebulon84 (discuter) 5 juin 2018 à 21:47 (CEST)

Création d'un diagramme[modifier le code]

Bonjour, je suis allé faire un tour sur Modèle:Graphique polygonal pour l'utiliser afin de mettre en graphique les données suivantes et avoir une présentation plus pertinente. J'avoue après quelques essais ne pas savoir quoi compléter pour la première partie de | marge_h à | coul_serie_10, pour ce qui est du reste (càd remplir les 30 données) je pense pouvoir m'en sortir. Est-ce que quelqu'un peu me conseiller éventuellement ? D'ailleurs est-ce que l'on peut imaginer un tableau présentant les deux informations fréquentation estivale (année) et hivernale (saison). --AlpYnement vôtre, B-noa (d) 4 juin 2018 à 18:12 (CEST)

Les articles Modèle:Infobox Syndicat et Modèle:Infobox Association sont proposés à la fusion[modifier le code]

Page proposée à la suppression Bonjour,

Les articles « Modèle:Infobox Syndicat et Modèle:Infobox Association » sont proposés à la fusion (cf. Wikipédia:Pages à fusionner). Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Wikipédia:Pages à fusionner#Modèle:Infobox Syndicat et Modèle:Infobox Association.

Message déposé par Berdea (discuter) le 24 juin 2018 à 16:33 (CEST)

Unité sans "pipe"[modifier le code]

Bonjour,

Que pensez-vous de cette utilisation du modèle unité [2] ? En tout cas, ça ne correspond pas à la documentation du modèle... ni à son esprit à mon avis. -- -- El Caro bla 30 juin 2018 à 15:17 (CEST)

Notification El Caro : la documentation a probablement évolué depuis la dernière fois que tu l'a lue. Grâce à la programmation Lua j'ai rendu cette syntaxe possible, car elle me semble une écriture plus naturelle. Ceci-dit s'il y a consensus contre, je retirerais cette possibilité. — Zebulon84 (discuter) 1 juillet 2018 à 02:52 (CEST)
Je ne suis pas contre, Zebulon84, mais la doc date de 2017, je l'ai lue juste avant de poster. Si on accepte une écriture "naturelle" comme {{unité|10m-1}}->10 m−1, ça me va très bien, mais il faudrait prévenir les gens, car c'est un modèle très utilisé. Je ne peux pas le faire moi-même, ne connaissant pas exactement les nouvelles possibilités. -- -- El Caro bla 1 juillet 2018 à 09:13 (CEST)
Bonjour Notification El Caro, Zebulon84 et ContributorQ : cette syntaxe de saisie est possible (merci Zebulon84), mais le résultat affiché est le même. Alors il n'y a aucune obligation d'utiliser cette nouvelle possibilité. Certains contributeurs préfèrent avec les pipes, et d'autres contributeurs préfèrent sans. Il ne faut donc pas modifier un article pour changer la syntaxe selon sa préférence. Cordialement --NicoScribe (discuter) 1 juillet 2018 à 19:38 (CEST)
Bonjour, il est en effet souhaitable que chaque modèle soit accompagné d'un documentation à jour. Hélas dans la pratique ce n'est pas le cas. Je ne vois pas pourquoi interdire l'usage d'un modèle sous prétexte que la doc. n'est pas à jour ou carrément inexistante. Et l'« esprit » d'un modèle, je ne vois pas ce que peut bien recouvrir cette expression... Notez cependant que, dans le cas du modèle « unité », la mise à jour a été documentée, le 23 mai 2017, par Zebulon84 (diff)
« Certains contributeurs préfèrent avec les pipes, et d'autres contributeurs préfèrent sans. » C'est vous qu'il dite. Il y a surtout des personnes qui ont des habitudes et qui ne sont pas au courant des évolutions des modèles (NB : annonce de mise à jour du modèlè unité, par Zebulon84, le 7 mai 2017). Mais qui peut présenter les données chiffrées qui prouvent qu'il en est bien ainsi ? Pas moi, vous non plus. Et à l'injonction « Il ne faut donc pas modifier un article pour changer la syntaxe selon sa préférence. » je réponds « N’hésitez pas à être audacieux » comme nous y encourage le cinquième principe de l'encyclopédie. Auriez-vous des arguments plus décisifs à proposer ?
Voici des considérations réfléchies qui fondent mon usage du modèle unité sans « | » au cours de mes interventions de maintenance.
Un constat : l'usage obligé du code wiki et la nécessité de celui de modèles (à minima, à des fins de normalisation typographique sur tous les articles) constituent une courbe d'apprentissage élevée pour un(e) débutant(e) qui souhaite participer. Il m'apparaît donc évident que la technique d'usage d'un modèle (objet technique qui impacte la forme du contenu éditorial mais pas le fond) doit être la plus simple possible. Une fois que l'on a saisi le concept de modèle, le modèle le plus simple d'usage est {{}} (anonyme et sans paramètre). Viennent ensuite le modèle nommé sans paramètre, le modèle nommé doté d'un unique paramètre, le modèle nommé doté de plus d'un paramètre (pour les deux derniers cas, les paramètres sont toujours nommés (1, 2, 3, etc. par défaut) mais le nom de chaque paramètre n'est pas toujours obligatoire à saisir). On voit donc bien que le passage de l'implémentation {{unité|15.2|km|2}} (ou pire {{unité|15.2|km{{2}}}}) à {{unité|15,2 km2}}, par exemple, est une simplification de l'usage du modèle unité (moins de caractères à saisir et, comme l'affirme Zebulon84, écrire, sur frWiki, « 15,2 km2 » est plus naturel que « 15.2|km|2 »), sans compter que saisir le caractère « | » au clavier est plus « compliqué » que saisir tout caractère de l'écriture ordinaire (notez aussi la virgule décimale au lieu du point anglophone). Mes modifications, exposant les possibilités de la version la plus récente du modèle, ont donc une vertu pédagogique : elles donnent à voir la version la plus simple d'usage du modèle « unité » à une personne examinant le code d'un article pour apprendre.
Je profite de cet échange pour adresser un grand merci à Zebulon84 pour ce travail de simplification, de même pour le modèle « date ».
PS : dans ma pratique de maintenance, je n'interviens pas sur une page juste pour remplacer, par exemple, un {{unité|2|km}} par un {{unité|2 km}}, je traite tout ou partie de l'article, section par section. --ContributorQ() 8 juillet 2018 à 14:39 (CEST)

┌─────────────────────────────────────────────────┘
Notification ContributorQ : je vous présente mes excuses, car je voulais vous donner non pas une « injonction », mais juste un conseil (pour vous éviter d'autres remarques de la part de contributeurs préfèrant la syntaxe avec les pipes, soit par raisonnement, soit par habitude). De même, je pense qu'El Caro ne voulait pas « interdire l'usage d'un modèle sous prétexte que la doc. n'est pas à jour », mais juste discuter de votre remplacement par rapport à la doc.
Votre remplacement était donc de la pédagogie. Alors, n'en étant pas spécialiste, je ne devrais plus intervenir dans cette discussion.
Voici quand même quelques remarques (en vrac et après peu de réflexion de ma part) :

  1. Les syntaxes avec/sans pipe aboutissent au même résultat affiché pour le lecteur (et nous contribuons principalement pour les lecteurs).
  2. If it ain't broke, don't fix it : la syntaxe avec pipe donnant un résultat affiché correct, il n'est pas utile de la remplacer (par votre syntaxe préférée ou par une autre).
  3. Les possibilités d'{{Unité}} (et la pédagogie si elle est consensuelle) doivent être dans la doc. Vous dites « la mise à jour a été documentée, le 23 mai 2017, par Zebulon84 » (diff + diff) mais ce sont des mentions discrètes dans cette longue doc (la preuve : El Caro ne les a pas vues).
  4. Vous doutez que des contributeurs préfèrent la syntaxe avec les pipes par raisonnement, moi je suis convaincu qu'il y en a. Par exemple, ils peuvent souhaiter la séparation d'arguments de natures différentes, c'est à dire mettre l'argument « valeur numérique » dans le premier paramètre d'{{Unité}} et mettre l'argument « unité » dans le second paramètre.
  5. Ne négligez pas les contributeurs qui préfèrent la syntaxe avec les pipes par habitude : c'était quand même la seule syntaxe d'{{Unité}} pendant quasiment 10 ans.
  6. Il faut bien distinguer deux choses : l'ajout d'un modèle améliorant la typographie et le remplacement d'une syntaxe de paramètres correcte par une autre syntaxe de paramètres correcte. L'ajout « 15.2 km » → « {{unité|15.2|km}} » et l'ajout « 15.2 km » → « {{unité|15.2 km}} » améliorent évidemment la typographie. La communauté préfère peut-être le second ajout par rapport au premier. Mais, même si c'est le cas, cela ne veut pas dire que la communauté est d'accord pour des remplacements « {{unité|15.2|km}} » → « {{unité|15.2 km}} ».
  7. Le 5e PF dit surtout qu'à part les 5 PF, tous les usages sont évolutifs par consensus communautaire. « N'hésitez pas à être audacieux » est une de ses conséquences, détaillée dans la recommandation Wikipédia:N'hésitez pas. D'ailleurs, cette recommandation dit aussi « Dans l'hypothèse où d'autres ne seraient pas d'accord, il vous faudra alors convaincre [...] Aussi, au lieu de tout chambouler façon « ce que vous faites depuis des années, c’est nul ; moi, je sais comment il faut faire », préférez la méthode « j’ai quelques idées pour améliorer l’organisation : les voici, qu’en pensez-vous ? ». Ainsi, si vous voulez changer l’organisation du projet, n’hésitez pas, tout en faisant preuve d’un minimum de discernement et d'un peu de diplomatie. » : elle ne dit pas « si NicoScribe est gêné par vos modifications, poursuivez vos modifications parallèlement à la discussion ».
  8. Vous dites « mon usage du modèle unité sans « | » au cours de mes interventions de maintenance ». Mais je pense que votre remplacement d'une syntaxe de paramètres correcte par une autre syntaxe de paramètres correcte, n'est pas une intervention de maintenance (ou une wikification selon votre résumé de modification). C'est, comme vous l'expliquez ici, une « modification pédagogique ».
  9. Vous dites « notez aussi la virgule décimale au lieu du point anglophone » : il est plus simple pour moi de taper un point (j'ai un clavier azerty avec pavé numérique).
  10. Modifier des articles pour conseiller indirectement « une personne examinant le code d'un article pour apprendre » est moins efficace que de discuter entre contributeurs, ou que de conseiller directement la nouvelle possibilité de syntaxe à un nouveau dans le forum des nouveaux, ou que de faire une annonce communautaire centrée sur l'aspect « sans pipe » (vous dites vous-même « des personnes [...] ne sont pas au courant des évolutions des modèles »).
  11. Vous dites « je n'interviens pas sur une page juste pour remplacer... », mais vous l'avez fait dans votre remplacement, et les remarques d'El Caro et de moi-même sont focalisées sur ce cas.
  12. La syntaxe sans pipe ne marche pas toujours (Zebulon84 a dit « permet dans la majorité des cas de se passer de la séparation des unités » dans son annonce au bistro).
  13. Je trouve qu'il y a un déséquilibre entre la plus-value estimée de vos remplacements de syntaxe et leurs impacts (historiques d'articles, listes de suivi, stockages de versions).
  14. Dans le dump du 1 juillet 2018, {{Unité}} est inclus directement quasiment 2 millions de fois, dans quasiment quatre cent mille pages distinctes. Ces utilisations couvrent quasiment 10 ans d'existence du modèle où la syntaxe avec pipe était la seule, et quasiment 1 an où les syntaxes avec/sans pipe cohabitent (mais sans grande publicité auprès de la communauté). Je ne veux pas vous vexer, mais vos « remplacements pédagogiques » me semblent être une goutte dans l'océan des exemples disponibles à « une personne examinant le code d'un article pour apprendre ». Avec ce point, je ne commente pas votre méthode en elle-même, je commente juste son efficacité.
  15. La majorité des modèles séparent leurs paramètres avec des pipes (et continueront a priori de le faire, hors Lua). Je ne dis pas que la nouvelle possibilité de syntaxe d'{{Unité}} est une mauvaise idée, mais elle reste une exception par rapport aux autres modèles. Alors je ne suis pas sûr que mettre en avant cette exception améliore la courbe d'apprentissage des débutants concernant les variantes de modèles que vous avez listées.

Avec cette liste, je conteste votre argument de « remplacements pédagogiques ». Mais je ne conteste ni la nouvelle possibilité de syntaxe d'{{Unité}}, ni les ajouts d'{{Unité}} avec cette syntaxe dans un article où il n'y avait pas de modèle, ni vos deux autres arguments (« c'est plus simple » et « c'est plus naturel »). --NicoScribe (discuter) 9 juillet 2018 à 19:10 (CEST)

J'accepte vos excuses et je vous remercie d'avoir pris la peine de présenter tous ces arguments. Je pourrais les reprendre et pour chacun exposer un contre-argument (voire plusieurs). Et, à mon avis, dans deux ou trois mois, nous aurons établi une liste de bonnes raisons plus ou moins contradictoires de faire comme ceci ou comme cela, sans obtenir d'arguments décisifs. Cela dit, nous sommes d'accord sur votre point no 3. Je ne suis pas vexé par votre point no 14, plutôt amusé. Je précise le point no 11 : vérifiez les deux entrées du 30 juin 2018 à 14:59 dans l'historique de l'article Carança (un article modifié parmi des centaines‎), je suis intervenu dans deux sections. Je répète donc que je n'interviens pas dans un article juste pour changer un {{unité|2|km}} en {{unité|2 km}}, je traite tout ou partie de l'article, section par section. --ContributorQ() 10 juillet 2018 à 00:17 (CEST)
Notification ContributorQ : aucun de mes arguments ne vous a convaincu, tant pis. Pour obtenir des arguments décisifs, vous pouvez solliciter l'avis d'autres contributeurs, cela ne me gêne pas. Au passage, j'ai 3 remarques. Je suis en désaccord avec vos « remplacements pédagogiques », mais je ne remets pas en cause vos excellentes contributions sur d'autres sujets. Mes guillemets autour de « remplacements pédagogiques » ne sont pas des guillemets ironiques : ils renvoient juste à l'argumentaire dans votre première intervention. Enfin, en reprenant l'image qui vous a amusé, je ne suis qu'une goutte dans l'océan communautaire.
Pour mon argument no 11 : j'avais vu vos remplacements cumulés. Que vous remplaciez la syntaxe avec pipe → sans pipe dans un seul appel d'{{Unité}} ou dans tous les appels dans l'article ne change rien à mes arguments. Je conteste l'intérêt de vos « remplacements pédagogiques », pas votre façon de les faire. Et si, dans une même contribution, vous faites à la fois des améliorations incontestables et vos « remplacements pédagogiques », je continuerais à contester ceux-ci.
Dans l'ensemble, je n'insiste pas : vous pouvez continuer vos « remplacements pédagogiques » malgré notre désaccord. Mais sur mon argument no 8, j'insiste : vous devez changer vos résumés de modifications car ils sont, actuellement, trompeurs. Vous pourriez écrire par exemple « modification pédagogique pour montrer un autre usage du modèle unité ». Qu'en pensez-vous ?
Pour mon argument no 9 : si je me lance dans de nombreux remplacements de virgules par des points dans tous les appels d'{{Unité}} que je vois dans des articles, je ferais finalement comme vous (c'est à dire que j'imposerais ma préférence en ignorant celles des contributeurs précédents), alors est-ce que cela vous poserait un problème ? Même si je commençais par l'article Carança Clin d'œil ?
--NicoScribe (discuter) 10 juillet 2018 à 12:01 (CEST)
J'apprécie votre souci de précision (« modification pédagogique pour montrer un autre usage du modèle unité ») pour les commentaires de diff.. Mais cela devient rapidement un casse-tête lorsque dans une même contribution des modifications de nature différentes sont effectuées, ce qui est souvent mon cas. Je constate qu'il y a beaucoup de contributions qui ne portent que sur un élément d'un article (je ne livre ici aucun nom de contributeur(rice) procédant de la sorte... Je vous invite à consulter la classement par utilisateurs de Wikiscan, par année ou toutes années confondues. A priori, les plus gros contributeurs développent les pratiques les plus systématiques ; l'examen de leur liste de contributions est pour moi une source de réflexion et d'inspiration) ; j'évite ce genre de modification, sauf en cas de vandalisme ou de mise à jour d'un bandeau, d'une catégorie ou autres.
« si je me lance dans de nombreux remplacements de virgules... est-ce que cela vous poserait un problème ? » Absolument pas : si je tombe sur une de vos modifs, je serai circonspect mais ne protesterai pas. Je prends le pari que si vous vous lancez dans une telle entreprise vous recevrez bien plus de message de désapprobation que moi faisant l'inverse. Aussi, dans l'article Carança, mon point d'entrée est {{unité|...|km{{2}}}} et {{unité|...|m{{3}}/s}} (diff), les autres modifs sont en sus. Comme déjà répété plus haut : je ne passe pas sur un article pour seulement retirer les "|" du modèle « unité ». À la réflexion, un bot pourrait très bien effectuer ce travail. La demande d'intervention d'un bot nécessiterait de soumettre préalablement à la communauté la question suivante (formulation sommaire) : considérez-vous que la mise à jour du modèle {{unité}} rend l'usage ancien (avec "|" donc) obsolète ? Il en est de même pour le modèle {{date}}. Et, à mon avis, la personne la mieux placée pour mettre en œuvre une telle démarche est l'auteur de cette mise à jour. Il peut compter sur mon avis favorable et soutien.
PS : le déploiement de votre argumentaire n'est pas vain ; je ne suis pas obtus. Vous avez semé quelques éléments de réflexion dans mon esprit, il est fort probable, qu'après un temps de gestation plus ou moins long, ceux-ci stimulent mon imagination et participent à l'enrichissement de ma pratique de maintenance. Je vous remercie de nouveau pour avoir pris la peine de présenter vos arguments de contestation de ma pratique. --ContributorQ() 10 juillet 2018 à 19:38 (CEST)
Notification ContributorQ :
Oui, c'est vrai, mon résumé de modification proposé était long ! « syntaxe du modèle unité » ou « syntaxe modèle unité » ou « syntaxe {{unité}} » seraient plus courts. Quand une de mes contributions ne contient pas trop de modifications de natures différentes, j'essaye d'avoir un résumé précis. Quand ma contribution en contient trop, j'utilise le résumé « clarification ». Il est imprécis mais il est toujours exact, dans mon cas. Déterminez votre résumé comme vous voulez, mais je trouverais inacceptable que vos « remplacements pédagogiques » continuent d'avoir le résumé « wikification », car il est inexact. Un résumé trop générique louperait l'occasion d'être une « pub pédagogique », dans votre cas. Alors : adoptez-vous le résumé « syntaxe {{unité}} » ? Je vous avais prévenu de mon insistance sur ce point Sourire.
Je ne vais pas remplacer des virgules par des points. Je voulais vous faire comprendre que si chaque contributeur fait comme vous, c'est à dire placer ses préférences (même argumentées) dans les articles, les articles subiraient des aller-retours incessants, des tensions monteraient entre contributeurs expérimentés, et ce serait une mauvaise pédagogie pour les nouveaux contributeurs (de voir leurs articles modifiés de toutes parts par des préférences non consensuelles).
Oui, dans vos remplacements, vous retirez les "|" du modèle « unité », vous remplacez les points par des virgules, vous remplacez les km{{2}} par des km2, etc. Mais cela ne change rien à mes arguments, car avec ou sans vos modifs le résultat affiché est le même, et elles servent toutes votre objectif pédagogique de diffusion de vos préférences.
Votre « formulation sommaire » de question communautaire est bonne. Mais relisez mes arguments no 6 et no 14 : il faudrait ajouter une question explicite concernant les remplacements des quasiment 2 millions d'appels, dans quasiment quatre cent mille pages distinctes, sauf pour les cas particuliers (cf. mon argument no 12). Soit l'idée de la syntaxe sans pipe est venue spontanément à Zebulon84, soit elle lui a été suggérée par des contributeurs « mystère » : je ne sais pas. Mais, actuellement, les remplacements de syntaxe avec → sans pipe ne sont faits ni par Zebulon84, ni par son bot, ni par ces contributeurs « mystère » : ils sont faits par vous. Donc, à mon avis, la personne la mieux placée pour questionner la communauté, c'est vous.
--NicoScribe (discuter) 11 juillet 2018 à 00:47 (CEST)

Absence de "|" avant le texte d'un paramètre d'un modèle[modifier le code]

Bonjour la page Projet:Liens rouges/Modèle lien vers un article inexistant en langue étrangère mets en évidence l’absence de "|" avant le texte d'un paramètre de {{lien}} trad= ; lang= ; fr=. Cela ne concerne que 5 lignes, mais un plus grand nombre lors de la 1er édition de la liste. Cette page a mis en évidence cette erreur que pour l'erreur qu'elle recherche. Il est probable que cela concerne les autres paramètre du modèle.
Est-ce que ce problème se rencontre sur d'autre modèle ?
Existe-t-il une maintenance à ce niveau ? --ParaBenT (discuter) 2 juillet 2018 à 11:19 (CEST)

Notification ParaBenT : Bonsoir ! En réalité, il ne manque pas de « | » dans l'exemple que j'ai regardé. C'est le contenu du paramètre qui est incorrect : |fr=trad=Neosaurus (dinosaure) alors qu'il aurait dû y avoir |fr=Neosaurus (dinosaure).
Il m'arrive de faire du nettoyage dans les paramètres du modèle {{lien}} à partir des statistiques des modèle. Et ce cas ne s'y trouvera jamais parce qu'il peut être normal d'avoir le signe « = » dans un paramètre.
En conclusion : on ne peut trouver cette erreur que si on la cherche...
--FDo64 (discuter) 2 juillet 2018 à 21:27 (CEST)
Merci FDo64 Clin d'œil donc traitement totalement manuel, sans perte d'information à faire remonter pour permettre une maintenance plus systématique !
question subsidiaire que défini la valeur "=" dans un paramètre ? Car même si elle n'est pas proscrite dans un titre le résultat est nulle : [3] ! --ParaBenT (discuter) 2 juillet 2018 à 22:01 (CEST)
Notification ParaBenT : Ma réponse est générale et non spécifique au modèle {{lien}}. Je parle donc du contenu d'un paramètre quelconque qui contient bien souvent autre chose que le titre d'un article. Voir plus de détails ici. --FDo64 (discuter) 2 juillet 2018 à 22:27 (CEST)

Parenthèse mal fermée d'un titre de page appelé dans un modèle[modifier le code]

Bonjour la page Projet:Liens rouges/Modèle lien vers un article inexistant en langue étrangère mets aussi en évidence des parenthèses mal fermées dans le titre de page ciblée avec un modèle {{lien}}. Dans le paramètre trad= soit le lien vers un autre wiki n'a pas de parenthèse de fin soit elle est double. Cette situation ne semble pas analysé dans statistiques des modèle. Quelque cas pour {{lien}}, après un rapide parcours de la liste Projet:Liens rouges/Modèle lien vers un article inexistant en langue étrangère :

Donc même question et remarque que pour l'erreur de syntaxe avec "|".
Est-ce que ce problème se rencontre sur d'autre modèle ?
Existe-t-il une maintenance à ce niveau ?--ParaBenT (discuter) 5 juillet 2018 à 07:51 (CEST)

Je me permets de te notifier Notification FDo64 : pour confirmer ou pas que ces cas de parenthèses mal fermées sont intégrable ou pas aux listes de maintenance que tu surveille régulièrement. Car l'affichage n'est pas exhaustif sur Projet:Liens rouges/Modèle lien vers un article inexistant en langue étrangère. --ParaBenT (discuter) 10 juillet 2018 à 09:14 (CEST)
Notification ParaBenT : Bonsoir, les statistiques des modèle ne font que recenser les paramètres utilisés dans un modèle. En aucun cas la qualité du contenu de ces paramètres n'est analysée. Cela doit être fait par des utilisateurs qui exploitent les pages du site d'Orlodrim, ou par des bots spécifiques aux maintenances visées. --FDo64 (discuter) 10 juillet 2018 à 21:29 (CEST)

Lien rouge et modèle[modifier le code]

Bonjour, le modèle:Doublage a une gestion spécifique des liens internes... Sur ce modèle:Doublage, lorsque l'acteur qui effectue le doublage n'a pas d'article et n'est pas admissible, est-il possible d'éviter le lien rouge ? le paramètre VF_lien​ semble s'appliquer à l'artiste doublé et non à l'artiste qui fait le doublage... --HenriDavel (discuter) 6 juillet 2018 à 08:41 (CEST)

Notification HenriDavel : Bonsoir, je t'invite à lire la documentation du modèle dans laquelle il y est indiqué pour VF_lien​ : « si la valeur du paramètre est non, le modèle ne crée pas de lien ». Il y est d'ailleurs bien indiqué que ce paramètre concerne bien un « Artiste ayant réalisé la version diffusée en Europe francophone ».
Peut-être que ce modèle a mal été utilisé dans l'article qui t'intéresse ? Merci d'indiquer lequel si tu as besoin d'aide.
--FDo64 (discuter) 6 juillet 2018 à 22:44 (CEST)
FDo64 Je l'avais lu la documentation. Mais, comme indiqué dans mon message, « le modèle ne créé pas de lien » , certes, mais sur quel artiste il ne créé pas de lien. Car, dans un doublage, il y en a deux, d'artistes, l'artiste doublé et l'artiste qui fait le doublage. Voir par exemple The White Queen, qui contient plein de liens rouges grâce à ce modèle, et sur lequel un lien rouge supplémentaire a été créé ce matin par la suppression, suite à une décision en PaS, de l'article sur Juliette Poissonnier. C'est bête de mettre un lien rouge, et donc d'inciter à recréer un article supprimé par décision communautaire.... --HenriDavel (discuter) 6 juillet 2018 à 22:54 (CEST)
Notification HenriDavel : C'est toujours mieux avec un exemple. Le problème venait de l'article : un caractère spécial invisible dans le nom du paramètre VF_lien​.
Sinon, je ne comprends pas ta remarque sur l'acteur doublé/doubleur. Il y a deux paramètres : VO​ et VF​ pour faire la distinction.
--FDo64 (discuter) 6 juillet 2018 à 23:17 (CEST)

{{Infobox Monument}} et {{Géolocalisation/Flandre-Orientale}}[modifier le code]

Bonjour, suite à cette discussion sur le bistro, on se demande Notification EmDee : Notification El Caro : et moi, pourquoi pour pouvoir utiliser {{Géolocalisation/Flandre-Orientale}} nous avons besoin d'entrer les données dans Wikidata et qu'il ne suffit pas de mettre l'information dans {{Infobox Monument}}. Alors que pour les autres provinces belges, cela marche ? D'avance merci, --Huguespotter (discuter) 11 juillet 2018 à 15:17 (CEST)

Notification Huguespotter : Bonjour, je me suis amusé à mettre | géolocalisation = France/Belgique/Flandre-Orientale dans l'article Cour Saint-Georges et j'ai bien les 3 cartes. Je ne vois donc pas de problème. Peux-tu citer un article où ça ne fonctionnerait pas ? --FDo64 (discuter) 11 juillet 2018 à 15:31 (CEST)
Notification FDo64 :. En effet, maintenant cela marche pour Cour Saint-Georges car nous avons lié l'article avec Wikidata. Nous ne l'avons pas encore fait sur Hôtel 't Kindt où cela ne marche toujours pas, par exemple. D'avance, merci. PS : j'ai rajouté la carte sur l'article pour montrer ce que cela donne.--Huguespotter (discuter) 11 juillet 2018 à 15:50 (CEST)
Notification Huguespotter : Ok, donc ça ne vient pas d'une mauvaise utilisation dans l'article. Dans ce cas je notifie le créateur et les dernier éditeurs du Module:Infobox/Monument : Notification Zolo, Thierry Caro et Jérémy-Günther-Heinz Jähnick. --FDo64 (discuter) 11 juillet 2018 à 16:09 (CEST)
Notification FDo64, Huguespotter, Zolo, Thierry Caro, Jérémy-Günther-Heinz Jähnick et El Caro : Voici plusieurs autres articles où la carte de Flandre-Orientale ne fonctionne pas dans l'Infobox Monument : Halle aux draps (Gand), Maison du peuple Ons Huis, Statue de Jacques van Artevelde, Monument Édouard Anseele. Merci d'avance. EmDee (discuter) 11 juillet 2018 à 17:04 (CEST)
Je vais créer des Wikidata pour que cela marche en attendant sauf pour Hôtel 't Kindt pour qu'on ait encore un article test.--Huguespotter (discuter) 11 juillet 2018 à 20:45 (CEST)
Notification Huguespotter, FDo64 et EmDee : Corrigé, il manquait Module:Carte/données/flandre-orientale que je viens de créer. — Zebulon84 (discuter) 13 juillet 2018 à 00:06 (CEST)
Notification Zebulon84 : Un tout grand merci, --Huguespotter (discuter) 13 juillet 2018 à 08:34 (CEST)

Commencer à utiliser les modules centraux[modifier le code]

Les modules actuels sont faits pour une langue et un wiki. Les petits wikis n'ont pas de Lua-coders pour les traduire et ne peuvent en profiter.
J'ai donc écrit un module capable de les traduire et plus...
Pour convertir un module en module central il faut y ajouter quelques tables d'arguments... et remplacer les textes par leurs clés de traductions et leurs arguments.
Pour une nouvelle langue, il faut ajouter 200 traductions dans une table i18n.
Je vous invite à les découvrir et à commencer à convertir ceux qui vous semblent les plus utiles.
Ici, la Library:activity est dédiée à nous coordonner et à estimer l'avancement de notre activité.
Bien sur, je suis prêt à vous soutenir et à vous guider. --Rical (discuter) 12 juillet 2018 à 08:03 (CEST)
C'est une bien belle idée, mais qui va s'en occuper ces modules centraux si tu venais à partir ? Par exemple, rien que le module pour Wikidata fait peur à certains ici... Et il est vachement plus court que les tiens.
Tu sais si les petits wiki sont au courant de ce projet ? Peut-être qu'il y a des connaisseurs de Lua qui sont trop peu nombreux pour écrire des modules là-bas, cela pourra toujours t'aider. Lofhi me contacter 13 juillet 2018 à 21:19 (CEST)
Il a raison : Wikidata se remplit de jour en jour et nous en profitons, mais les petites Wikipédias qui pourtant en ont le plus besoin ne sont pas en mesure d'en profiter. Ce problème avait pourtant été souligné. Par ricochet, ce sont des données qui sont entrées en dur dans ces petites Wikipédias et qui ne sont donc pas mises sur Wikidata, donc dans ce scénario tout le monde est perdant. Jérémy-Günther-Heinz Jähnick (discuter) 15 juillet 2018 à 09:04 (CEST)