Discussion Projet:Modèle/Archive 2010

Archives

• 2006
• 2007
• 2008
• 2009
• 2010
• 2011
• 2012
• 2013
• 2014
• 2015
• 2016
• 2017
• 2018
• 2019
• 2020
• 2021 (01-06)
• 2021 (06-12)
• 2022
• 2023
• 2024

{{Cathédrale}}

Bonjour les modélistes !

J’ai un grave soucis sur un modèle que j’ai créé. Il n’est pas parfait, je comptais l’améliorer d’ici peu, mais au moins il faisait ce que je lui demandais : gérer comme il se doit les homonymies de cathédrales, par une syntaxe fort simple de type {{Cathédrale|Notre-Dame|de Paris}}. Oui, je parle de {{Cathédrale}}.

Sauf que je viens d’y trouver un gros bug incompréhensible. Il marche pour toutes ces pages, mais pas pour :

• Cathédrale de l'Archange-Saint-Michel de Moscou ;
• Cathédrale de la Dormition de Moscou ;
• Cathédrale Saint-Basile de Moscou.

Sans autre explication.

Quelqu’un est-il motivé prêt à se casser la tête là-dessus ?.. ou plus simplement, à m’expliquer comment tester le plus proprement possible si une page est un redirect ou pas, en cherchant à le deviner par un test du nombre de caractères (je soupçonne que c’est ce bout du code qui merde…).

Ce serait fort aimable à lui.

Nemoi s’est exprimé ici le 2 janvier 2010 à 01:39 (CET)

Plusieurs remarques :

1. Avec le parseur {{#lc:}} tu peux mettre un argument en bas de casse, ce qui t'évite deux tests pour « basilique ».
2. Il faut minimiser les appels à ifexists et en particulier éviter les appels répétés, en rajoutant un embranchement au besoin.
3. L'appel à PAGESIZE pour tester la page de redirection est une mauvaise idée. N'applique pas ce modèle sur les pages de redirection tout simplement. Si l'apposition du modèle est faite par un bot, c'est facile de lui donner cette restriction.
4. Il vaudrait mieux nommer l'argument basilique plutôt que de le passer en test et de devoir différencier le numéro d'appel des autres arguments.

Je suppute que le bug qui te préoccupe est lié aux commentaires, mais je ne suis pas encore arrivé à trouver où. Ambigraphe, le 4 janvier 2010 à 21:26 (CET)

Merci de tes remarques. J’ai découvert {{lc:}}, ça marche bien.

Je viens de créer une version en test qui permettra d’éviter les répétés, je l’applique demain.

Le problème du PAGESIZE est (en fait, il fallait juste tester) que la taille de la page est vide :

« {{PAGESIZE:Cathédrale de l'Archange-Saint-Michel}} »

« 62 »

ce qui en effet fait bugguer par les commentaires. Est-ce normal ? Dans quel(s) cas cela arrive-t-il ?

Pour ce qui est de basilique, je veux une syntaxe « humaine » pour les trucs de base ; les titres de l’article étant souvent du type « Cathédrale-Basilique du Christ-Roi de Reykjavik », la syntaxe {{Cathédrale|Basilique|du Christ-Roi|de Reykjavik}} s’impose d’elle-même…

Nemoi s’est exprimé ici le 5 janvier 2010 à 00:28 (CET)

Je viens de « pusher » ma nouvelle version, et elle corrige le bug (via un contournement, certes).

Nemoi s’est exprimé ici le 5 janvier 2010 à 02:17 (CET)

Pour la syntaxe humaine, je te conseille de créer un modèle {{Basilique}} qui renverra simplement au modèle {{Cathédrale}} avec l'argument basilique = oui. Ambigraphe, le 5 janvier 2010 à 14:26 (CET)

Liens externes

Bonjour,

je m'interroge sur les derniers modèles crées par Lilielletune. Ceux-ci pointent vers des liens externes qui ne sont réputés comme source. Du coupe, ça fait un peu spam pour Two Door Cinema Club

• {{MySpace}}
• {{Last.fm}}
• {{Spotify}}
• {{Facebook}}

J'aimerais consulter votre avis pour savoir si on supprime ou pas -- Xfigpower (pssst) 11 janvier 2010 à 10:21 (CET)

Mon avis est que ton objection concerne plus une question de politique de liens externes qu’une question de technique de modèle, et que l’absence de tels modèles n’empêchera malheureusement pas les abus de liens externes. (Dans le cas précis de Two Door Cinema Club#External links (sic), il s'agit clairement d'une recopie de la Wikipédia en anglais : en:Two Door Cinema Club#External links.) — D’autre part, vu que ces modèles existent sur la Wikipédia en anglais et quelques autres wikipédias (voir les interwikis pour en:Template:MySpace, en:Template:Last.fm, en:Template:Spotify et en:Template:Facebook user), il me parait nécessaire de passer par Wikipédia:Page à supprimer si tu veux les supprimer définitivement. —C.P. 11 janvier 2010 à 11:45 (CET)

Perso je suis plutôt pour la conservation de ces modèles, qui permettent de trouver rapidement des articles dont les liens externes sont à vérifier ^^. --Hercule ^Discuter 11 janvier 2010 à 11:59 (CET)

Il me semble qu’au moins le MySpace est déjà passé en PàS (ça me rajeunit pas, ça). Mais mon avis est plutôt celui d’Hercule, à savoir que tant qu’il est présent, on peut le surveiller. Nemoi s’est exprimé ici le 11 janvier 2010 à 13:53 (CET)

Non, pour ce genre d’exercice, « Rechercher > MySpace » est plus efficace (plus de 6000 pages à vérifier...), car il ne faut pas s’imaginer que tout le monde, ou même la majorité, va maintenant utiliser ce modèle pour insérer un lien indésirable vers MySpace. —C.P. 11 janvier 2010 à 14:03 (CET)

Il y encore mieux: Spécial:Recherche de lien/*.myspace.com et Spécial:Recherche de lien/*.myspace.fr... —C.P. 11 janvier 2010 à 14:15 (CET)

J'ai lancé la demande pour Last.fm -- Xfigpower (pssst) 13 janvier 2010 à 16:58 (CET)

Modèle empêchant l'évaluation wiki

Bonjour,

on trouve à présent les modèle {{£}}, {{)))}}, {{É}}, {{Ê}}, {{&}}, {{&&}} . J'ai un doute sur leur lisibilité. Faudrait penser à uniformiser tout ça -- Xfigpower (pssst) 13 janvier 2010 à 10:12 (CET)

Questions et remarques

Hello,
nous envisageons de créer un projet herpétologie (sur les reptiles, en gros). Je voulais savoir si il existait une liste des "styles" de projets / portails quelque part, avec les modèles associés. Pour mes premiers essais j'ai repris les modèles utilisés pour ce projet (projet modèle).
Justement, à propos de ces modèles une remarque : sur ma machine (linux-xubuntu, firefox 3.5.6), lorsque le titre d'une sous-partie (Modèle cadre) est trop long, il apparaît sur deux lignes, ce qui casse l'affichage de l'arrondi à droite du titre (en laissant un blanc). Si ce n'est pas clair je peux ajouter une capture d'écran.
Précision : sur mon firefox j'impose une taille minimum de fonte (14, donc toute fonte < 14 est affichée en 14). Un exemple pour voir : Utilisateur:Hexasoft/Projet Herpétologie (c'est quasi-vide, hein, je viens de commencer ). Moi ça le fait pour le premier "Projet herpétologie", "Encore du travail", et "Projets connexes".

Merci d'avance pour vos réponses. Hexasoft (discuter) 13 janvier 2010 à 12:22 (CET)

Utilise le Projet:Projet clef en main qui est moins beau mais plus accessible, facile a mettre en place et est utilisé presque partout. Tpt (d) 13 janvier 2010 à 14:20 (CET)

Ok, merci (en fait je l'ai trouvé ensuite en parcourant des catégories . Reste ce qui est probablement un bug d'affichage sur les titres (ça semble déconner quand le texte est sur deux lignes (c'est trop haut pour la zone) mais pourquoi fait-il une césure au delà d'une certaine taille ?). Hexasoft (discuter) 13 janvier 2010 à 14:38 (CET)

Modèles à subster

Bonjour,

reprenant une ancienne requête périodique faite aux bots j'ai créé catégorie « Modèle à subster » et {{Modèle à subster}}, afin d'avoir une liste plutôt exhaustive des modèles à traiter. Bien sûr les titres et textes sont améliorables

Ce modèle et cette catégorie (le modèle catégorise) sont destinées à être apposés sur les modèles qui alourdissent le code wiki. Si vous connaissez des modèles de ce type (par exemple il existait des modèles permettant d'écrire un lien pour les clubs de foot, il y en encore surement qui existent) n'hésitez pas à diffuser.

Je me chargerais régulièrement de passez sur les pages utilisant ces modèles, avec mon bot.

Cordialement,

--Hercule ^Discuter 14 janvier 2010 à 14:59 (CET)

Serait-il possible d'utiliser le mot français adéquat et transparent, en l'occurrence « substituer », au lieu de ce néologisme dont je ne vois pas la nécessité ? Ambigraphe, le 20 janvier 2010 à 10:14 (CET)

Je ne vois aucun problème à améliorer le titre. Mais je ne suis pas sûr que substituer soit le bon mot. Pour moi cela signifie à remplacer par un autre non ? --Hercule ^Discuter 20 janvier 2010 à 12:26 (CET)

Plus précisément, « substituer » signifie « mettre en remplacement d'autre chose ». En l'occurrence, si j'ai bien compris le problème, le contenu d'un tel modèle doit être substitué au modèle lui-même. Je propose alors catégorie « Modèle à remplacer par substitution » et {{Modèle à remplacer par substitution}}. Qu'en penses-tu ? Ambigraphe, le 20 janvier 2010 à 16:53 (CET)

Pas tip-top. C'est avant tout une catégorie de maintenance, et avec les noms que tu donnes je ne comprends pas directement. Subster c'est moche mais les Wikifourmis le comprennent.

En même temps je vois que le terme « susbtituer » est utilisé dans un modèle comme {{Avertissement suppression page}}. Donc Catégorie:Modèle à substituer ne devrait pas être trop choquant --Hercule ^Discuter 20 janvier 2010 à 18:22 (CET)

Modèle:Cite_book

Bonjour ; je me demandais pour quelles raisons, lorsqu'on utilise le modèle:cite_book (exemple), un "(en)" est collé en début de citation ? Je sais que le modèle est obsolète, mais j'aurais besoin de cette info pour un projet sur lequel je bosse (qui fournira quelques outils pratiques pour les contributeurs; trop long à détailler ici). Merci d'avance pour les réponses :) Pwet-pwet · (discuter) 19 janvier 2010 à 22:24 (CET)

L'anglais est défini comme langue par défaut sur le modèle. Pour le faire disparaître mettre fr dans le paramètre "language". Tpt (d) 19 janvier 2010 à 22:28 (CET)

Ok, merci pour la rapidité de la réponse ! Pwet-pwet · (discuter) 19 janvier 2010 à 22:36 (CET)

Extension StringFunctions

Voilà le sondage Wikipédia:Sondage/Extension StringFunctions est cloturé. Le résultat est 22 Pour, 1 Contre et 3 Neutre. Maintenant reste à plancher sur une possible mise en place partielle ou complète de cette extension. J'ai contacté Kropotkine_113 afin de voir ce qui pourrait être fait. Temesis m'a également apporté quelques précisions intéressantes. Je leur laisse le soin de réfléchir à ce qui pourrait fait. Si certains d'entre vous veulent également s'y intéresser, étudier la question en terme de faisabilité, d'installation, je vous laisse voir et faire au mieux. J'ai proposé de mettre en place cette extension mais partiellement, ne permettre déjà dans un premier temps que quelques fonctions qui ne posent pas de soucis comme « #len: » et « #sub: ». Pour l'installation il faut passer semble-t'il par bugzilla... Voilà je passe un peu la main dans ce domaine qui demande réflexion et concertation entre modélistes et développeurs... amicalement--Wikialine (d) 22 janvier 2010 à 16:04 (CET)

Voir la page de discussion de Wikialine à cette date. --Temesis (d) 24 janvier 2010 à 13:53 (CET)

Il vaut mieux continuer cette discussion intéressante ici, car ça doit conserner tous les modélistes en général. Je recopie ci-dessous donc la totalité de la discussion entamée sur ma page de discussion personnelle. amicalement--Wikialine (d) 24 janvier 2010 à 18:48 (CET)

Bonjour Kropotkine 113, j'ai suivi tes conseils pour la mise en place de l'Extension:StringFunctions. J'ai lancé un petit sondage Voir ici. A présent, il faudrait faire une demande sur bugzilla comme tu me l'avais précisé sur le bistrot. Je suis allé sur ce site mais vu mon anglais exécrable, je ne vois pas trop où laisser ma demande. Tu sembles plus au fait que moi dans ce domaine, peut être as-tu des contacts francophones. Si tu pouvais prendre le relais pour la finalisation de l'instalation, je serais un peu plus rassuré. Merci par avance. amicalement--Wikialine (d) 21 janvier 2010 à 03:30 (CET)

Salut. Pas beaucoup de temps maintenant, je te fais une réponse plus détaillée bientôt. Mais après avoir regardé tout ça de plus près je suis assez pessimiste sur la mise en place de cette extension (comme te le signalaient déjà un peu Xavier Combelle sur le Bistro et Temesis dans le sondage). Mais, on essaiera de faire une demande en s'appuyant sur ton sondage. Je complète plus tard. Kropotkine_113 22 janvier 2010 à 10:28 (CET)

Bonjour,

Etant passé en coup de vent sur le sondage, quelques précisions :

• L'extension proprement dite n'est pas déployable sur Wikipédia : elle comporte actuellement des défauts de performances et de sécurité
• Un développement similaire intégrant ces fonctionnalité au parseur mediawiki à l'extension Parserfunctions a été tenté pour y remédier, mais il se heurte à au moins deux objections de fond :
  • problèmes de sécurité inhérent à la possibilité donnée aux contributeurs de produire des traitements complexes
  • sur le fond : problème d'utilisabilité avec la transformation de la syntaxe wiki d'un langage de mise en forme / structuration du contenu à un pseudo-langage de programmation ou de macro-commandes. La complexité accrue de la syntaxe que cela entraîne remet en cause le principe même de la syntaxe wiki. Et le moyen est médiocre, cette syntaxe se prêtant très mal à du code complexe. Les fonctions parseurs actuelles sont elles-mêmes déjà très critiquées de ce point de vue. Certaines sont même considérées comme des erreurs à ne pas refaire.

Un troisième développement a été lancé, via une extension totalement différente, mais elle pose à son tour d'autres problèmes liés à des exigences spécifiques côté serveur, qui entraveraient la réutilisabilité des contenus ainsi produits.

Bref, ce qui peut sembler trivial et utile du côté des contributeurs est une question beaucoup plus complexe côté développement et philosophie des projets, qui n'a pas de réponse immédiate. Ce n'est pas un mal d'ailleurs : ce genre de développement des capacités de la syntaxe wiki est une porte ouverte vers beaucoup d'inconnues, à ne pas franchir sans une réflexion très complète.

Cordialement, --Temesis (d) 22 janvier 2010 à 12:46 (CET)

Dans les StringFunctions, certaines fonctions peuvent nous être utiles sans être trop compliquées à utiliser. Si déjà on pouvait installer au moins certaines de ces fonctions partiellement et laisser de coté le reste, c'est aussi envisageable. Si déjà on pouvait utiliser « #len: » et « #sub: » alors ce serait parfait. Je vais à temps perdu me renseigner et voir si cela est faisable... En tout cas tenez moi au courant si vous avez du nouveau de votre coté et étudiez mon idée d'installation partielle. amicalement--Wikialine (d) 22 janvier 2010 à 15:33 (CET)

Hmmm, je vois que Temesis a répondu en grande partie pour moi Juste pour apporter quelques précisions : la demande pour cette extension a été faite en 2006 et il y a eu effectivement plusieurs problèmes. La position actuelle de Tim Starling (un des « chefs » développeurs de MediaWiki) est que tout développement du logiciel sur la base des fonctions parseurs ou d'extensions s'en rapprochant est une mauvaise idée par défaut. Il propose de développer à la place l'extension Lua, mais celle-ci pose ses propres problèmes. Je vais continuer à voir ce qu'on peut faire du sondage ; au pire une indication que la communauté de fr.wikipedia.org veut voir ce genre de problèmes avancer ne peut pas faire de mal, mais s'il y a peu d'espoir de voir une solution rapide émerger. Kropotkine_113 23 janvier 2010 à 11:34 (CET)

Pour rebondir sur Kropotkine 113 : le besoin exprimé globalement et assez naïvement par le sondage, se heurte à un débat de fond assez complexe notamment sur la nature de la syntaxe wiki. Mais il a aussi par ailleurs la possibilité de signaler aux développeurs des « use cases », des cas très spécifiques où on rencontre un besoin, à condition de bien de le documenter.

A partir d'un besoin utilisateur précis et bien documentés, les développeurs peuvent envisager des développements adaptés, plus spécifiques, qui peuvent très bien se passer de ces stringfunctions.

Le souci immédiat d'une démarche comme ce sondage ou de la demande d'implémentation de l'une ou l'autre des fonctions de manipulations de chaînes, c'est qu'elles demandent un bombe H pour écraser un moustique, alors que les développeurs sont des gens sympas prêts à vous fabriquer une tapette sur mesure. Ou à vous dire « Non, ça, vous n'êtes pas censé le faire dans Wikipédia », ce qui résout la question tout aussi bien.

Donc, ce qui peut être fait, plutôt que de rappeler que les contributeurs aimeraient bien pouvoir faire de la programmation dans les modèles (c'est au moins pour le moment exclu), ce serait qu'ils exposent au cas par cas leurs besoins précis.

@Kropotkine 113 : cela dit, c'est un bon cas d'école sur une question de fond. Il manque à l'évidence un échelon ou des gens entre les contributeurs et les développeurs pour expliquer tout cela. Sur :en, cela se fait sans doute naturellement car suffisamment de développeurs sont aussi des contributeurs. Sur des wikis comme :fr, les quelques très rares développeurs qui sont contributeurs ne peuvent faire face. Et dans l'hypothèse d'une extension comme Lua, ou encore à la suite de réflexions comme celle de Litlok dans le sondage, il y a un besoin d'intervenants, c'est à dire des droits à prévoir spécifiquement. Et il restera à les intéresser à ce genre de contributions techniques. On retrouve la même question avec les motivations d'une candidature admin « technique » comme celle de Dr Brains, qui est plus un très (très très, j'insiste) respectable bricoleur auto-formé qu'un intervenant suffisamment compétent pour être placé à l'heure actuelle dans la position de décision qui sera la sienne une fois administrateur. Bref, quelque-chose manque entre les communautés et le support technique.

--Temesis (d) 23 janvier 2010 à 13:28 (CET)

Effectivement, on doit prendre le temps de la réflexion. Par contre, des parser fonctions du genre « #len: » et « #sub: » semble(à vérifier bien entendu) ne pas poser de problèmes et leur utilisation est relativement simple. Il existe déjà déjà sur WP des fonctions bien plus complexes qui pour autant ne posent pas de soucis majeurs. Sans tomber dans l'excès de mettre en place un système de programmation complet et complexe, on peut pour autant autoriser un certain panel de fonctions utiles et permettant d'automatiser certaines taches sur WP. Les « #if: », « #switch » et j'en passe sont devenus indispensables. Temesis tu sembles pas mal porté dans ce domaine, essais de devenir ce trait d'union entre les contributeurs et les développeurs. Il y a effectivement une faillite de ce coté là. La preuve j'ai du piocher à droite à gauche pour savoir comment s'y prendre pour mettre en place les stringsfonctions. Graces à Kropotkine, j'ai pu suivre ses conseils et lancer ce débat pour l'installation de cette extension. En tout cas, je ne souhaites pas précipiter les choses, on a tout notre temps. L'essentiel c'est que l'on commence à étudier la question pour les mises en place de tout ou partie d'une extension proche de Stringfonction, étudier la mise en place partiel de stringfonction et laissant de coté les fonctions les plus inutiles ou problématiques. Je suis franche avec vous, moi je veux vraiment c'est les fonctions « #len: » et « #sub: », car je penses que ça permettra de développer certaines applications intéressantes et bénéfiques pour WP-fr. Vous avez carte blanche pour la mise en place de telles fonctions d'une manière ou d'une autre. Cela rejoint tout à fait ce qui a été dit ici à savoir faire des développements adaptés et spécifique plutot que la mise en place complète des stringsfonctions. amicalement--Wikialine (d) 23 janvier 2010 à 15:28 (CET)

En essayant de transcrire au mieux le point de vue « développeur » (mais il est à l'évidence spontanément partagé par des contributeurs qui se plaignent de la complexité croissante de la syntaxe) :

Aucune des fonctions de manipulation de chaîne n'est plus évidente à activer qu'une autre, et proposer d'activer uniquement #len: et #sub: ne répond pas aux objections, qui sont :

• pour mémoire, des risques en matière de performance et de failles de sécurité, potentiellement corrigeables, voire corrigés dans l'implémentation actuelle.
• mais surtout, la dérive que chacune de ces fonctions entraîne quant à la syntaxe wiki, refusée par les développeurs.

Sur le second point, qui est le problème de fond, la syntaxe wiki a été conçue initialement comme un format:

1. permettant aux contributeurs de structurer (titre, paragraphes, listes etc.) et de mettre en forme (italique, taille de caractères, couleurs) le contenu saisi, rien de plus.
2. sans avoir de connaissances en informatique et avec un minimum d'apprentissage
3. en se reposant sur une capacité syntaxique du format qui est très limitée, mais suffisante pour répondre à ces deux besoins.

L'ajout, par la suite, des fonctions parseurs (#if, #switch) n'a jamais été destinée à permettre autre chose qu'un peu de souplesse dans la structuration et la mise en forme des contenus. Il ne s'agissait pas du tout de permettre de créer des modèles qui soient des « applications » réalisant des traitements plus complexes. Pour cela, il y a en particulier les extensions. Mais cela n'a pas été expliqué aux contributeurs : ceux-ci ne voient pas le problème posé par certaines utilisations des modèles, et encore moins par leurs demandes d'étendre la capacité de la syntaxe à « programmer ».

Pourquoi refuser cette évolution de la syntaxe ? La force de la syntaxe wiki dans les projets WikiMedia est sa simplicité, qui permet à tous de contribuer. Il faut bien comprendre que cette simplicité est inséparable de son incapacité à permettre des traitements plus complexes sans devenir illisible : des modèles exploitant les fonctionnalités de manipulation de chaînes, ne serait-ce que #len: et #sub: deviennent immédiatement trop complexes pour le contributeur, mais aussi trop difficilement lisibles pour le contributeur averti. La syntaxe wiki ne se prête pas à devenir, même un tout petit peu, un langage de macro-commandes ou de programmation. Elle a déjà largement atteint ou même dépassé ses limites avec les actuelles fonctions parseurs. Pour ne prendre qu'un seul exemple évident: l'impossibilité d'indenter un code de modèle sans le rendre encore moins lisible à coup de commentaires HTML (<!-- ... -->) est révélatrice.

Pour répondre malgré tout au besoin de mettre en place des modèles permettant des traitements plus complexes, les développeurs ont commencé à mettre en place un autre mécanisme : l'extension Lua, qui permet d'utiliser un autre langage, adapté à des traitements de programmation. Mais c'est un développement qui prend du temps, et dont la mise en place dans les projets MediaWiki n'est pas possible pour le moment. C'est du long terme, voir très long.

Pour conclure : la syntaxe wiki n'ira probablement pour l'instant pas plus loin que ce qu'elle permet aujourd'hui, elle a largement atteint ses limites. Certains besoins exprimés par les contributeurs ne peuvent pas être satisfaits. Tous ne sont cependant pas pertinents (l'exemple donné dans le sondage était à vrai dire maladroit : ce n'est pas avec des modèles wiki qu'il faut faire cela, même si l'intention est excellente). Pour déterminer ceux qui seraient pertinents, il faut faire le tri selon ce critère : est-ce qu'il s'agit de résoudre un problème important de structure ou de mise en forme du contenu qu'on ne peut pas obtenir dans les articles, y compris manuellement et sans passer par un modèle ? Par contre, s'il s'agit de développer des modèles « plus puissants » ou faire du traitement programmé (votre « développer des applications » ), ce n'est pas pertinent et il faut se tourner vers d'autres demandes, en particulier les extensions.

En espérant avoir éclairci les choses, --Temesis (d) 24 janvier 2010 à 12:27 (CET)

Sans entrer dans des débats trop techniques, je crois que l'on touche surtout à une conception philosophique de ce que doit être WP. Relisant les débats récents en rapport directs ou non avec le développement technique de WP, on se rend bien compte qu'il y a d'un coté des wikipédiens qui considèrent que ce site doit demeurer un wiki simple comme il fut mis en place à ses débuts et de l'autre coté des wikipédiens qui veulent que WP deviennent un wiki plus élaboré avec le développement de modèles plus complexes, avec de l'automatisation de données... Chaque vision se vaut. En attendant, pour ce qui est de l'installation des stringsfonctions, j'ignore si c'est si problématique que cela de les installer mais j'espère qu'un jour cette extension ou alors un type de programmation qui puisse permettre un équivalent comme l'extension Lua, soient un jour effectif sur WP-fr. Mais tout cela reste à débattre entre développeur, je préfère rester humble et ne pas m'entêter à vouloir l'installation coute que coute d'une de ces extensions. Je trouve plutot positif l'usage des if, switch et autre fonctions atuellement en place, je trouve que ça permett une sorte de programmation simplifiées. On n'est pas dans du php, javascript ou autre langage plus élaboré... Par ailleurs, je m'efforce de suivre progressivement certains de tes conseils en incluant de plus en plus de l'html dans certains modèles qui s'y prètent. Donc je crois qu'il y a moyen de concilier parser... et script plus traditionnel, ou plus accessible, sans compter la complémentarité des 2. Je tiens à profiter également de cette discussion pour préciser que je trouve intéressant l'usage des parsers car quelques soit les navigateurs cela permet de fonctionner partout sans trop de difficultés ce qui est moins le cas pour d'autres applications issue d'autres langages. Enfin, je préfère à présent laisser d'autres prendre le relais dans ce débat et voir ce qui doit être fait en la matière. J'apprécie ce genre de débat où l'on est pas pressé par le temps et où l'on peut faire un réel travail de réflexion technique ambitieux. Merci pour tes conseils Temesis amicalement--Wikialine (d) 24 janvier 2010 à 19:15 (CET)

« on se rend bien compte qu'il y a d'un coté des wikipédiens qui considèrent que ce site doit demeurer un wiki simple comme il fut mis en place à ses débuts et de l'autre coté des wikipédiens qui veulent que WP deviennent un wiki plus élaboré avec le développement de modèles plus complexes » : absolument pas. La question est uniquement de savoir quels sont les moyens appropriés. Le besoin, lui, est évident. Par contre, il y a beaucoup à expliquer pour éviter que des contributeurs ne se « braquent » devant des syntaxes, des modèles, des nouveautés maladroitement mis en oeuvre. --Temesis (d) 25 janvier 2010 à 07:10 (CET)

Pour moi, la simplicité peut signifier deux choses:

• Tous utilisateurs doit pouvoir utiliser simplement le langage wiki
• Tous utilisateurs doit pouvoir utiliser simplement la syntaxe wikipedia, c-à-d langage wiki & modèles

On se retrouve donc avec des méta-développeurs (ou modélistes) qui développent des modèles à base des fonctions basiques du développeur pour simplifier la méta-présentation des articles. Pour eux, j'ai envie de dire qu'ils n'ont pas peur de la complexité rien que par la manipulation des parserfunctions.

Peut-être devrions nous alors catégorisés les modèles utilisant des fonctions avancées afin de s'assurer qu'elles sont nécessaires mais ne bloquer pas l'installation pour des prédictions de mauvaise utilisation --Xfigpower (pssst) 25 janvier 2010 à 11:39 (CET)

Lorsque j'ai écrit : « on se rend bien compte qu'il y a d'un coté des wikipédiens qui considèrent que ce site doit demeurer un wiki simple comme il fut mis en place à ses débuts et de l'autre coté des wikipédiens qui veulent que WP deviennent un wiki plus élaboré avec le développement de modèles plus complexes » . Crois moi Temesis, j'ai constaté ce genre de situation. Je m'amuse parfois à relir des vieilles discussions d'il y a plusieurs années. Et on se rend compte de l'évolution de WP et de certains wikipédiens. La lutte contre des modèles doublons, la question même de savoir si l'on doit créer ou non un article pour chaque ville du monde (j'ai lu ça y a pas longtemps) où certains étaient contre la création d'un article pour chaque ville... Donc ce que je voulais souligner ici c'est l'aspect philosophique de WP. Des visions se heurtent. Par contre je suis bien d'accord avec ce qui est dit ici, on ne doit pas se précipiter. Temmesis tu as raison de prendre le temps de voir ce qui pourrais être entrepris d'une façon plus large. Par contre j'espère que les stringfonctions ou autre extension, ne tomberont pas dans l'oubli. On en a besoin actuellement, une forte majorité de modélistes y sont favorables, il serait bon qu'un développeur se penche à présent sérieusement sur la question. Je vais laisser un message sur bugzilla (si j'y comprend quelques chose... je n'ai encore hjamais eut l'occasion de m'y rendre). En tout cas je suis contente que Xfigpower, temesis, Kropotkine_113 et d'autres s'intéressent à ces questions. Plus on sera nombreux à se concerter là dessus plus on pourra faire évoluer les articles et notamment leur automatisation entre autre chose. Graces au parsers j'ai pu limiter pas mal de dérive de façon automatiques, mais à présent avec les quelques fonctions dont on dispose, on commence à atteindre une certaines limite technique, ce qui n'est pas forcément bon car on peu être tenter de trouver des solution ailleurs par le biais de js ou css... Il faut que l'on renforce le nombre de perserfonctions comme je l'ai proposé ici avec les stringsonctions ou alors on doit commencer à développer un équivalent comme discuté ici... amicalement--Wikialine (d) 25 janvier 2010 à 13:11 (CET)

hiddenStructure dans les modèles : vieux problème lourd à corriger

Voir le sujet hiddenStructure sur l'Atelier accessibilité de janvier 2010 : les contributeurs actifs sur le modèles devraient être intéressés par la correction d'un vieux défaut majeur très lourd, et sont quoi qu'il en soit les premiers concernés. Cordialement, --Temesis (d) 24 janvier 2010 à 13:53 (CET)

En résumé, n'utilisez pas une bidouille css mais préférez un affichage conditionnelle par bloc #if -- Xfigpower (pssst) 24 janvier 2010 à 17:51 (CET)

Emplacement des catégories et liens vers les équivalents étrangers

Pour les modèles visiblement deux écoles s'affrontent lorsque la documentation d'un modèle est en sous-page: mettre catégorie et liens interwiki dans un noinclude directement sur la page du modèle ou dans un includeonly dans sa page de documentation.

L'avantage de la deuxième solution en terme de séparation du code du modèle et de ses annexes me semble faible devant les problèmes que ça pose sur les points suivants:

• C'est plus compliqué et plus long pour un utilisateur (usage de l'outil hotcats impossible) de recatégoriser le modèle quand c'est nécessaire
• C'est plus compliqué de changer/ ajouter un nouveau lien interwiki
• En cas d'automatisation des tâches précédentes par un bot, il faut qu'il vérifie si le modèle a une page de documentation ou pas et si les infos sont sur la page de documentation ou sur la page du modèle et
• Le mécanisme de lien interwiki marche sur des articles qui pointent directement les uns sur les autres et le fait de déplacer ce lien sur une autre page complique le travail des bots interwiki qui doivent adopter un traitement spécifique pour le modèles peut probablement empêcher de fait la mise en place d'interwiki ou au moins la gêner.

De l'autre côté la mise en place directement dans la page du modèle revient uniquement à ajouter quelques lignes dans la section noinclude de celui ci, qui existe de toutes façons pour mettre en place le lien vers la documentation. Son seul inconvénient est de faire qu'on se retrouve à devoir éditer deux endroits différents selon qu'on veuille toucher aux pages relatives au modèle ou à sa documentation mais ce problème me parait mineur puisque l'édition de modèle se fait au cas par cas et le problème sera minoré si une convention sur l'emplacement de ces liens est clairement définie.

Je voulais donc savoir si une telleconvention existait à propos de ces liens et quelle est cette convention.

Merci.--kirikou (d) 1 février 2010 à 20:35 (CET)

L'un des avantages de mettre les liens interwiki et les catégories dans la page de documentation est que l'on peut librement les mettre à jours même lorsque un modèle est protégé contre écriture. Certains laisse tomber en désuétude des modèles car il n'y ont plus accès. amicalement--Wikialine (d) 2 février 2010 à 00:10 (CET)

Ok merci pour ta réponse--kirikou (d) 15 février 2010 à 02:33 (CET)

J'en profite pour redire que c'est pas super évident de placer ces liens dans un bloc includeonly en page de doc, le plus naturel étant de les inclure sur la page même des modèles, et en bas -- Xfigpower (pssst) 15 février 2010 à 09:21 (CET)

Effectivement, mais tant qu'il n'existera pas un moyen d'ajouter, des catégories ou des liens interwiki sur des pages protégées, par les simples péon comme kirikou ou moi, on doit adopter cette solution qui est un choix de raison. On pourrait également envisager de devoir faire des demandes en permanence aux admin pour l'ajout de catégories ou de liens interwiki, mais très vite les péons vont se lasser et laisser tomber. amicalement--Wikialine (d) 15 février 2010 à 13:05 (CET)

Mouais, je suis évidemment pour l'espace d'ajout cat/interwiki séparé sur l'espace modèle (j'avais demandé ça sur acai) mais une page demande d'intervention sur modèle protégé est pas si compliqué à suivre. Y a aussi les pages de discussions qui peuvent servent à ça. Y aurait moyen de faire qq de centralisé en utilisant mieux {{Modèle protégé}} où l'on pourrait préformater la demande. On créé un mécanisme complexe pour peut-être 5% des modèles qui sont protégés. À y réfléchir -- Xfigpower (pssst) 15 février 2010 à 13:52 (CET)

C'est pas une mauvaise idée de créer un système à partir de {{Modèle protégé}}. C'est une idée à creuser effectivement, hélas seul un admin là encore peut créer un tel système puisque pour faire des essais il faut pouvoir modifier des pages protégés. Par contre, il faut se rendre à l'évidence que le nombre de pages protégé va sans cesse augmenter. Les 5% actuel vont progressivement augmenter. amicalement--Wikialine (d) 15 février 2010 à 14:38 (CET)

Les anglais ont mis en place en:Template:Pp-template qui indique dans le cadre d'un modèle protégé que les liens sont dans la page de doc -- Xfigpower (pssst) 15 février 2010 à 17:12 (CET)

On pourrait ajouter une phrase dans le bandeau du modèle {{Protection}}, indiquant aux utilisateurs que l'ajout des catégories et des liens interwiki se font sur la page de documentation... Disons quelques chose dans ce genre. Xfigpower, je te laisse voir ce qui est le mieux. amicalement--Wikialine (d) 15 février 2010 à 19:37 (CET)

webkit border radius

Bonjour,

J'ai vu qu'il y a pas mal de modèles qui utilisent -moz-border-radius pourquoi aucun n'utilise -webkit-border-radius qui permet d'avoir un effet d'arrondi similaire sur les navigateurs utilisant webkit?--kirikou (d) 15 février 2010 à 02:33 (CET)

Avis demandé

J'aimerais avoir le plus d'avis sur la pertinance d'ajuster le drapeau d'un pays au poil de cul près : Discussion_modèle:Drapeau2#détail_de_la_date -- Xfigpower (pssst) 23 février 2010 à 12:08 (CET)

Modèle:Wikipédia sur papier

Ai-je bousillé ce modèle ? C'est la question que je me pose, vu qu'il ne semble pas marcher. Thierry Caro (d) 2 mars 2010 à 08:07 (CET)

Problèmes avec les parserfunctions

Bonjour les modéleux, cela fait un bail ; mais rien de neuf si j'en crois les annonces.

4 problèmes pour les experts :

Comment obtenir le namespace d'un paramètre ?

• pas moyen apparemment   <STyx @ (en break de long break ;) 17 mars 2010 à 23:05 (CET)

Comment tester l'existence d'une sous-page de l'utilisateur ?

• pas moyen avec special:Mypage/... apparemment . Et pas moyen d'afficher : « Vous êtes  pseudo »   <STyx @ (en break de long break ;) 17 mars 2010 à 23:05 (CET)

Comment subst:ituer avec des paramètres ?

• pas moyen apparemment . Dommage ce serait vraiment utile aux bots.   <STyx @ (en break de long break ;) 17 mars 2010 à 23:05 (CET)

Comment tester proprement les valeurs numériques ?

Pas ainsi, en tous cas :

{{#ifexpr: -0 | yes | no }} → no

{{#ifexpr: (1)*0 | yes | no }} → no

{{#ifexpr: (-1)*0 | yes | no }} → no

 17 mars : mw:Help:Extension:ParserFunctions — bug 22866 - Unexpected results of #ifexpr:.

Réponse

{{si c'est un nombre}}

 

  <STyx @ (en break de long break ;) 17 mars 2010 à 23:05 (CET)

modèle Évaluation multiprojet

Bonjour les modélistes

J'ai un petit souci avec le modèle {{Évaluation multiprojet}}. Sur demande du projet W 1.0, j'applique depuis quelques temps ce modèle sur les pages de discussion pour faire l'évaluation du projet:football.

Il se trouve que l'apposition de ce modèle sur un article ayant déjà eu une évaluation fait disparaitre l'évaluation. Je m'explique avec deux exemples : évaluation de Dragoljub Brnović et évaluation de FC Artmedia Petržalka. Dans les deux cas il y avait auparavant une évaluation en place et dans les deux cas l'apposition du modèle fait en sorte que celle-ci disparaisse sur les pages Projet:Slovaquie/Évaluation/Historique (voir au 17 mars 2010) et Projet:Monténégro/Évaluation/Historique (voir au 9 mars). La seule façon de voir réapparaitre l'éval est de replacer une éval seule (cf Dragoljub Brnović). (même souci pour la Côte d'Ivoire (Discussion:Football Club Adzopé).

D'après ce que j'ai pu observer cet phénomène ne se retrouve pas pour toutes les évaluations.

D'après Dd (d · c · b) du projet W 1.0, cela viendrait du modèle (cf ma pdd Discussion_utilisateur:Matpib#Evaluation_W1.0_Dragoljub Brnović).

Pouvez-vous résoudre ce problème ?

Avec mes remerciements. Matpib (discuter) 19 mars 2010 à 10:25 (CET)

La page du modèle {{évaluation multiprojet}} précise que la catégorisation (dont dépendent les statistiques d'évaluation) est induite par le sous-modèle {{Relatif wikiprojet}}, qui n'est effectivement pas renseigné pour les projets Slovaquie et Monténégro. Ambigraphe, le 19 mars 2010 à 11:45 (CET)

Que dois-je donc faire pour rétablir les choses? Matpib (discuter) 19 mars 2010 à 14:31 (CET)

Je viens de rajouter la Slovaquie dans le modèle {{Relatif wikiprojet}}.

Est-ce que ce sera suffisant, sachant que la Côte d'Ivoire et le Monténégro y étaient déjà ? Matpib (discuter) 19 mars 2010 à 14:36 (CET)

À partir du moment où les catégories d'évaluations sont visibles en bas de la page de discussion de l'article, c'est que c'est bon. Ambigraphe, le 19 mars 2010 à 16:20 (CET)

Modèles wikipédia avec Médiawiki

Bonjour, J'ai fais un test pas très concluant. Pour ne pas gaspiller trop de temps, voilà ma question : Si je souhaite tester un article en local (Mediawiki en localhost) avec des modèles utilisés sur Wikipédia, la simple copie des pages de modèles est-elle suffisante ? Si oui, la migration (import/export) en masse de tout ou parties des modèles est-elle possible ? Merci - --Patschw (d) 23 mars 2010 à 12:55 (CET)

Pages liées à un paramètre d'une infobox

Bonjour,

Existe-t-il un moyen de connaitre la liste des pages liées à un paramètre utilisé dans une infobox ?

Merci – Bloody-libu (o_-) 2 avril 2010 à 17:25 (CEST)

Un seul moyen, créer une catégorie pour tout ses article en insérant dans l'infobox {{#if:{{{paramètre|}}}|[[Catégorie:nom de la cat]]}}. Tpt (d) 3 avril 2010 à 10:32 (CEST)

Très bien, merci de ta réponse Tpt ! – Bloody-libu (o_-) 3 avril 2010 à 13:24 (CEST)

{{Article}}

bonjour, est ce qu'un modéliste pourrait modifier ce modèle pour ajouter un paramètre "auteurs" qui accepte la liste compléte des auteurs et soit donc une alternative à la liste détaillée des auteurs avec un paramètre pour chaque nom et prénom? Merci d'avance. --Chandres (✉) 20 avril 2010 à 12:24 (CEST)

Ce n'est pas une bonne idée, il faut absolument préférer les paramètres "prénom1", "nom1" car ils permettent l'exportation de données et l'usage du modèle "référence Harvard" et autres. Tpt (d) 20 avril 2010 à 13:46 (CEST)

Oui, c'est super, sauf que je suis pas le seul a en avoir raz le bol de devoir se taper la liste de dix auteurs différents pour les articles de biologie, donc prendre en otage les ajouts de références dans les articles pour favoriser un aspect technique me semble plus qu'une mauvaise idée. Il n'y a qu'à rajouter une catégorie de maintenance lorsque ce paramètre est utilisé, ainsi les volontaires pour "wikifier" ce genre de chose auront un outil dispo. De mon coté j'en ai marre d'avoir ce genre de réponse, donc je met la liste complète d'auteur dans le paramètre du premier auteur, pas sur que ce soit mieux que ma demande!! --Chandres (✉) 20 avril 2010 à 14:39 (CEST)

En outre c'est faux. On est pas obligé d'utiliser nom et prénom avec harv, c'est une des possibilités. Et pas la possibilité obligatoire. Vincnet G discuss 20 avril 2010 à 15:11 (CEST)

Inutile de modifier le modèle, il suffit de lister tous les auteurs dans nom1. Si vous trouvez la décomposition abusive il suffit de ne pas en tenir compte... Ce n'est pas pire que de venir ici demander une modification dont vous savez qu'elle serait refusée si elle était demandée directement sur la page de discussion de l'article.

Une autre solution : faire un modèle simplifié, sous un autre nom, et ne plus utiliser {{Article}}

--Hercule ^Discuter 20 avril 2010 à 15:31 (CEST)

Je soutiens complètement la demande de Chandres, je trouve que c'est une excellente idée. J'évite le plus possible d'utiliser ce modèle tellement il est pénible à remplir, je préfère le modèle lien web. On ne peut même pas faire un copier-coller du nom du journaliste de l'article qu'on veut mettre en référence parce que nom et prénom sont séparés. Et bonjour la corvée quand il y a plusieurs auteurs ! Je ne connais pas le modèle Harvard, il ne doit pas être dans la barre d'outils, mais ça ne me donne vraiment pas envie de l'utiliser ! Tu sais pourquoi ce serait refusé sur la page de discussion du modèle? Parce que bien souvent les modèles sont des chasses gardées de certains. Ils les modifient sans jamais demander l'avis des gens qui les utilisent. Exemple : le modèle ouvrage qui est devenu moins pratique du jour au lendemain ! Au moins ici, c'est plus lisible.--Guil2027 (d) 20 avril 2010 à 15:57 (CEST)

Hercule, si je viens faire la demande ici, c'est pour tout de même tenir compte des remarques de contributeurs comme celle de Tpt, je peux effectivement remplir "nomauteur1" avec la liste de tous les auteurs, je le fais régulièrement, en essayant de venir plus tard pour décomposer la liste. Maintenant c'est du boulot de sagouin, donc pourquoi ne pas faire un paramètre propre "auteurs", que ce soit une alternative à "nomauteur1" ET que l'usage de ce paramètre catégorise l'article dans une catégorie cachée "Article utilisant le modèle "article" sans liste détaillée des auteurs", nous avons déjà ce type de cas avec les taxobox sans nom d'auteur de taxon, donc techniquement cela est faisable. --Chandres (✉) 20 avril 2010 à 16:38 (CEST)

+1 Je rechigne à utiliser ces modèles car indiquer les sources ainsi prend plus de temps que d'écrire l'article. Et tant pis pour les labels... Toute simplification est la bienvenue. --amicalement, Salix ( converser) 20 avril 2010 à 17:32 (CEST)

Je pense qu'on pourrait satisfaire tout le monde si on utilise une syntaxe de type nom1/prénom1/nom2/prénom2. Il ne resterait plus qu'à parser la chaîne (et vu qu'on a pas les fonctions string, le choix du délimiteur est restreint au slash...) -- Xfigpower (pssst) 20 avril 2010 à 18:02 (CEST)

Ca!, ca me semble une super idée, car après un copié collé de la liste des auteurs, rajouter les slash à la place des virgules, c'est assez rapide! Par contre ce serait possible d'avoir un paramètre "noms/prénoms" et une alternative "prénoms/noms", toutes les revues n'utilisent pas le même ordre. Je sais je suis chiant, mais tant qu'à trifouiller le code, autant le faire à fond --Chandres (✉) 21 avril 2010 à 13:17 (CEST)

Bonjour,
Ayant travaillé sur le modèle {{article}}, je me sens un peu visé par ce débat. Je ne veux pas envenimer la discussion, mais seulement apporter quelques précisions :

• Je pense qu'en 2010, avec l'accroissement de la synchronisation entre les différentes moteurs de recherche bibliographiques, il n'est pas un luxe pour une encyclopédie de s'assurer que ses références bibliographiques puissent être exportées et liées par le biais des COinS. C'est ce que permet les paramètres nom1=/prénom1=/nom2=/etc.
• Ceci étant dit, l'utilité de diviser les champs nom1=/prénom1= n'est pas uniquement pour les COinS. Ayant wikifié beaucoup d'articles, notamment des références bibliographiques, c'est incroyable de voir comment les champs concernant les auteurs sont écrits tout croche, ne respectant pas les conventions bibliographiques. Quand il y a un seul champ du type "auteur=", l'ordre nom/prénom varient selon les utilisateurs, la typographies utilités est différentes, etc. Le but d'avoir un modèle c'est justement de s'assurer que les conventions bibliographiques soient respectés.

Je comprends malgré tout les critiques. Voici donc pour tenter de réconcilier les positions :

• D'abord, information importante : le paramètre |auteur= existe toujours ! Pour les utilisateurs qui ne souhaitent pas utiliser les paramètres nom1/prénom1/nom2/etc. ils peuvent continuer à l'utiliser en indiquant la liste des auteurs. Évidemment, ce paramètre ne permet pas d'utiliser les COinS, mais bon, c'est mieux de ne pas utiliser les COinS que de ne pas utiliser le modèle du tout. De plus, sur la question de l'uniformisation de la syntaxe, je soupçonne que les utilisateurs qui se plaignent ici sont assez familier avec les conventions bibliographiques pour ne pas faire d'erreurs.
• On pourrait donc ajouter l'utilisation de |auteur= à la catégorie déjà existante (Catégorie:Recension temporaire pour le modèle Article), afin que des âmes charitables s'occupent de la wikification un jour. Je ne veux toutefois pas qu'on se fasse d'illusion. Probablement personne, ne va vouloir s'occuper de ça...

Voilà donc ce que je pense pour tenter de dénouer la discussion. — Riba ^(discuter) 21 avril 2010 à 14:44 (CEST)

autant pour moi, j'avais complètement loupé la survivance du paramètre "auteur", il est pas zappé de la notice?, et je suis tout à fait d'accord avec ton analyse, mais actuellement, la notice trop compliquée de ce modèle fait plutôt perdre des références dans les articles que gagner de la cross compatibilité. Il faut trouver un équilibre.

100% pour la catégorisation, par contre c'est possible dans une sous-cat spécifique à ce cas de figure? il m'est déjà arrivé de me taper des articles entier pour wikifier les références ajoutées par d'autre contributeur, donc je sais que je serais un utilisateur de cette catégorie avec AWB. --Chandres (✉) 21 avril 2010 à 15:27 (CEST)

(P.S. Je viens de créer la catégorie pour voir l'ampleur de l'utilisation du paramètre) — Riba ^(discuter) 21 avril 2010 à 15:41 (CEST)

J'ai fait l'ébauche du parser Utilisateur:Xfigpower/Auteur. Après, y a juste à rajouter un test de if auteurs/auteur et c'est plié -- Xfigpower (pssst) 21 avril 2010 à 16:27 (CEST)

C'est génial comme solution ! Totodu74 (devesar...) 21 avril 2010 à 22:35 (CEST)

En plus de auteurs, j'aimerais également directeurs ou mieux : direction, la direction pouvant être réalisée par un groupe, pas forcément par des individus. Merci. Vincnet G discuss 25 avril 2010 à 16:51 (CEST)

{{Doute}}

Trés bien ce modèle {{Doute}} ; mais il doit catégoriser l'article pour que la maintenance intervienne ! amha   <STyx @ (en break de long break ;) 25 avril 2010 à 23:34 (CEST)

{{Cls}}

Ce modèle a un problème non ? —Clapsus Talk— 3 mai 2010 à 21:23 (CEST)

Expédition de Bowât

Gros bug d’affichage, généré par les modèles {{lang-ar}} et {{coord}}. Voyez la note 1 (selon les navigateurs, le rendu n’est pas identique) : sous midori, j’ai la succession : « arabe : »/coordonnées/globe/« truc en arabe »/reste ; sous abrowseur/firefox, j’ai : « arabe : »/longitude/globe/« truc en arabe »/lattitude/reste… alors que je devrais avoir « arabe : »/« truc en arabe »/globe/coordonnées/reste…

Où est le bug ? (non, pas là…) dans les moteurs de rendu, dans mediawiki ou dans le modèle ? Dois-je corriger dans l’article en attendant une évolution, ou est-ce corrigeable rapidement ? Si quelqu’un veut jeter un œil… Nemoi vous invite à lui laisser un message le 9 mai 2010 à 18:16 (CEST).

Ce n'est pas un bug, mais un effet de bord occasionnel de ce qu'on appelle la gestion bidirectionnelle du sens de l'écriture (le texte en arabe n'est suivi que de signes typographiques et de chiffres qui ne permettent pas de trancher l'alternative sur le sens de l'écriture). La solution la plus robuste nécessite un code un peu lourd pour Wikipédia. Une solution plus simple consiste à faire figurer un terme en français immédiatement après le texte arabe, comme dans cet exemple.

Cela dit, puisqu'il ne s'agit pas de références, le contenu de cette « note » aurait bien plus sa place dans le corps du texte. Cordialement, --Lgd (d) 15 mai 2010 à 07:22 (CEST)

Modèle:DateJV

Bonjour,
Est-ce que quelqu'un pourrait jeter un œil à cette discussion ? Ce modèle nous pose un petit problème. Par avance, merci. Kilianours (d) 15 mai 2010 à 00:35 (CEST)

Datations calendrier julien et calendrier grégorien, modèle bienvenu ?

Comme le montre cet exemple (introduction de l'article), la mention d'une double datation calendrier julien/calendrier grégorien n'est pas des plus claires et pourrait certainement être améliorée. Un modèle pourrait rendre service... Si quelqu'un se sent inspiré ? A moins qu'un modèle n'existe déjà (mais où  ?). Cordialement, --Lgd (d) 17 mai 2010 à 07:48 (CEST)

Chez nos voisins allemands, ils ont de:Vorlage:JULGREGDATUM qui insère en exposant un lien vers le calendrier -- Xfigpower (pssst) 17 mai 2010 à 12:13 (CEST)

Problème avec ENF et ENFU17

Bonjour à tous,
Voilà le problème : Modèle:ENF et Modèle:ENFU17
Je rencontre un souci avec les 2 modèles cités ci-dessus, uniquement lorsque je les associe à l'équipe nationale de l'Allemagne de l'Est : ça me donne un lien avec un espace manquant entre Est et de football, ce qui génère un lien rouge alors que l'article existe bel et bien dans les 2 cas. Si quelqu'un(e) a une solution, merci par avance. Queix (d) 25 mai 2010 à 13:28 (CEST)

[52809898=1 Réglé] par user:Clapsus -- Xfigpower (pssst) 25 mai 2010 à 15:25 (CEST)

Si c'était réglé, les liens ci-dessus seraient en bleu ... Queix (d) 25 mai 2010 à 16:36 (CEST)

Youpi [1], c'est bleu!!! -- Xfigpower (pssst) 25 mai 2010 à 18:04 (CEST)

Merci mon bon, tu m'enlèves une belle épine du pied! Bravo... Queix (d) 25 mai 2010 à 19:24 (CEST)

Modèle:Flagathlete

Bonsoir à tous. J'ai un problème avec ce modèle.

Il concerne le traitement de l'homonymie sur le mot Irlande. Le modèle fait inter-agir le IRL présent dans le modèle et le traitement des homonymies sur le mot Irlande. J'ai repéré le bug en me servant de Wikicleaner. j'en ai donc parlé à son concepteur NicoV : Discussion utilisateur:NicoV/Wikipedia Cleaner.

Pourriez-vous essayer de jeter un petit coup d'oeil ?

Merci ++ Matpib (discuter) 27 mai 2010 à 20:18 (CEST)

c'est {{Country alias Irlande}} qui pose un soucis -- Xfigpower (pssst) 28 mai 2010 à 12:30 (CEST)

Comment faire alors pour que Irlande devienne [[Irlande (pays)|Irlande]] dans ce modèle ? Matpib (discuter) 28 mai 2010 à 12:49 (CEST)

Il semble que la simple transformation dans le modèle de Irlande en [[Irlande (pays)|Irlande]] provoque des dégâts collatéraux. Matpib (discuter) 28 mai 2010 à 13:39 (CEST)

Je bricole un truc avec {{drapeau2}} et vous aurez les lien vers Sport en France -- Xfigpower (pssst) 28 mai 2010 à 13:51 (CEST)

Bon, je sais gérer la cible via {{Drapeau2/Libellé/Sport}} mais reste à gérer l'allure du lien qui ne sort pas le code IOC...--Xfigpower (pssst) 28 mai 2010 à 17:24 (CEST)

youpi->{{Drapeau2/Libellé/Sport CIO}}... J'avais fait la même manip pour {{DrapeauSportifCIO}}--Xfigpower (pssst) 28 mai 2010 à 17:55 (CEST)

Il semble que cela fonctionne. les fausses-homonymies sur wikicleaner ont disparues.

Merci +++ Matpib (discuter) 30 mai 2010 à 14:34 (CEST)

Modèle:Me

Bonjour les modélistes. Je jetais un œil sur Le Plantier de Costebelle, où je me trouve avec un « M^e » en bout de ligne — c’est l’abréviation de « Maître » en français — assez disgracieux. Suivant les modèles de ma connaissance (sic) {{Mme}}, {{M.}}, {{Mgr}}, {{Mlle}}, etc., je mettais donc un « {{Me|Hussenot-Desenonges}} ». Problème : si le modèle : gr qui servait anciennement à écrire « M^gr » a été supprimé, le modèle : me n’a pas évolué, et sert encore à faire « M^e ». Je pense qu’il est encore dans les mœurs de l’utiliser — bien malheureusement. Mais ne serait-il pas bon de le noter comme obsolète, avec l’espoir de pouvoir un jour unifier définitivement les abréviations du français ‽ Nemoi vous invite à lui laisser un message le 2 juin 2010 à 18:18 (CEST).

En l’absence de réponse du projet, je n’hésite pas. Nemoi vous invite à lui laisser un message le 3 juillet 2010 à 15:49 (CEST).

Modèle:Exp/Documentation

Ça ne se fait pas habituellement, mais je pense que — pour le cas où une personne passerait par là — préciser :

:*: Préférez cependant {{Mmes}} et {{Mlles}}.
:*: Préférez cependant {{er}}, {{nd}} et {{e}}.
:*: Préférez cependant utiliser le modèle {{unité}}.

sur les trois cas donnés en exemple ne serait pas du luxe… Qu’en pensez-vous ? Nemoi vous invite à lui laisser un message le 10 juin 2010 à 00:27 (CEST).

En l’absence de réponse du projet, je n’hésite pas. Nemoi vous invite à lui laisser un message le 17 juin 2010 à 18:01 (CEST).

Un petit réglage

Bonjour ! Je ne sais si je toque à la bonne porte mais qqn pourrait-il aller voir sur Histoire militaire du Brésil en cours de rédaction et faire un petit réglage pour que les deux « tableaux historiques »(Empire et République) aient la même dimension. C'est un peu moche ce décrochage .. Rien d'urgent ! Salut ! Thib Phil (d) 21 juin 2010 à 21:51 (CEST)

Largeur ajustée ! Peter17 (d) 23 juin 2010 à 17:27 (CEST)

merchi ! Thib Phil (d) 24 juin 2010 à 02:23 (CEST)

Désolé d'encore vous déranger avec cela mais pourriez m'indiquer sur ma PdD comment accèder à ces boîtes pour les compléter : il y manque des trucs - p.ex. Opération Condor dans la boîte républicaine ! Bonne journée ! Thib Phil (d)

Oups, désolé de vous répondre si tard ! Il suffit de modifier {{Palette Conflit Empire (Brésil)}} et {{Palette Conflit République (Brésil)}}. Ils sont listés sous la boîte de modification des pages dans lesquelles ils sont utilisés, mais c'est vrai que dans le cas de Histoire militaire du Brésil, ça fait beaucoup de modèles listés... Cordialement. Peter17 (d) 6 août 2010 à 19:21 (CEST)

{{DateJV}} (bis)

Salut à tous,
J'avais déjà posé une question il y a un peu plus d'un mois en rapport avec cette discussion et Riba (d · c · b) avait prévu de nous aider mais finalement il a du oublier. Nous souhaiterions simplement que les dates apparaissent dans l'ordre établi par le poseur du modèle afin de conserver l'ordre chronologique. J'espère que ma demande aura plus de succès cette fois-ci. Merci. Kilianours (d) 22 juin 2010 à 17:10 (CEST)

Bonjour, j'ai aussi ce problème sur un autre modèle, quelqu'un pourrais exepliquer comment faire ? (si le temps vous manque, on peut peut-être le faire). Dans l'état mes connaissances (le néant au niveau programmation), je ne sais pas quoi faire pour résoudre ce problème, Riba proposait d'utiliser d'autre modèle ou sous pages. Si ce n'est pas trop compliqué, je peux le mettre en place. --Arcade Padawan (d) 28 juin 2010 à 19:02 (CEST)

Modèle:LondonGazette

Bonjour les modélistes. Ne faudrait-il pas reprendre totalement ce modèle, en lui faisant appeler directement (ou en reprenant le code de) {{article}} ? Nemoi vous invite à lui laisser un message le 23 juin 2010 à 16:12 (CEST).

{{Commonscat}} et {{Autres projets}}

Bonjour,

J'ai besoin d'un supplément d'information à propos de remarques que m'ont adressées des contributeurs à propos de {{Commonscat}} et de {{Autres projets}}.

Le premier m'a écrit :

« J'ai révoqué tes modifications de {{commonscat}} vers {{Autres projets}}, car si elles répondent bien à la lettre de Wikipédia:Prise de décision/Lien interprojet, sont contraires à son esprit : quand il n'y a qu'un seul projet lié, cette modification aboutit à presque un doublement du volume de la boite. Ça ne va vraiment pas dans le sens de la sobriété ([2]). »

Le deuxième m'a écrit :

« [...] dans les catégories, Autres projets n'étant connu de personne d'autre que fr:, ça emmerde les bots internationaux qui tentent de répliquer le modèle Commonscat ([3]). »

Ayant analysé les textes de {{Commonscat}} et de Wikipédia:Prise de décision/Lien interprojet, je crois que la substitution doit être effectuée dans les articles, peu importe le nombre de liens interwiki. Y a-t-il des arguments supplémentaires que je dois considérer, peu importe qu'ils soient pour ou contre ma position ?

Merci,

Cantons-de-l'Est 24 juin 2010 à 15:28 (CEST)

Il me semble clair que la correction doit être faite, au vue de la PDD. Pour les bots internationaux, je ne sais pas comment ils fonctionnent, mais ce n'est pas notre soucis s'ils sont mal configurés. Normalement avec l'API ils devraient détecter le lien. Et s'ils utilisent Pywikipedia le script dans le repository a l'air correct.

--Hercule ^Discuter 25 juin 2010 à 01:05 (CEST)

Pour moi, le modèle {{Commonscat}} est obsolète, point final. S'il y a des problèmes avec {{Autres projets}}, il faut les signaler et les corriger, pas ignorer la PDD. Peter17 (d) 25 juin 2010 à 02:49 (CEST)

L'argument "ça prend plus de place" est plus un détail qu'autre chose. Si le design est à revoir, révisons-le. Mais cela ne servira pas de prétexte pour refuser ce modèle, qui a des avantages bien plus intérssants.

Par exemple, l'utilisation de {{Autres projets}} permet d'ajouter plus facilement des liens vers les autres projets, lorsqu'on ne connaît pas les modèles correspondants. C'est bien mieux pour les contributeurs présents depuis quelques mois. Á mon arrivée, j'ai beaucoup contribué sur Wikisource, et du coup j'ajoutais les liens vers Wikisource. Le truc, c'est qu'il y avait plusieurs modèles, que je me plantais toujours, et... Le temps que j'aurais gagné avec un modèle unique !

Bref. Par contre, ce serait bien de creuser l'histoire des bots internationaux, et de savoir comment on pourrait corriger le problème. Dodoïste ^{[ dring-dring ]} 25 juin 2010 à 04:37 (CEST)

Il y a quand même un truc que je comprend pas, c'est pourquoi on appose le modèle Autre projets alors qu'on pourrait le gérer comme les inter-wikis (ce qui pose alors vraiment moins de problème pour les bots)? Esby (d) 25 juin 2010 à 11:42 (CEST)

Heu, actuellement, dans les implémentations disponibles, on ne peut pas le gérer comme un inter-wiki (ou alors, ça vient tout juste de changer). Par contre, ce serait une des possibilités les plus pertinentes, en effet. Cordialement, --Lgd (d) 25 juin 2010 à 12:31 (CEST)

c'est pas tellement un sens interwiki, mais plus une autre approche d'un même sujet (le peintre et ses peinture, l'auteur et ses oeuvres, l'oiseau et ses photos). Donc, il faut laisser la possibilité d'habiller le lien. Par contre, tjs convaincu par la PDD--Xfigpower (pssst) 25 juin 2010 à 13:57 (CEST)

Je dirai que le hic est le suivant: En appliquant un modèle a tiroir comme Autres projets, on fait un boulot de formatage au niveau du modèle qui pourrait être fait au niveau de l'habillage du site, à la manière des inter-wikis. En bref, on a des informations, notamment des catégories, des inter-wikis, des autres projets, l'interface pourrait à terme les positionner selon les paramètres et faire que ceux-ci ne dépendent pas d'un modèle en terme de représentation graphique. (Cela nécessite des améliorations mediawiki par contre.) Je ne pense pas que cela pose problème si un jour cet option est implémentée: il suffira de convertir Autres projets pour qu'il ne génère que des inter-wikis (ainsi que les légendes associées), l'interface s'occupera alors de positionner les informations correctement. Je ne connais pas assez les bots pour être sur des implications réelles, mais je pense que ca complexifie la situation grandement pour la théorie des inter-wikis. Le cas normal étant l'apposition sur l'article toto issu d'un wiki XX de [[commons:titi]] se transposant sur commons sur l'article titi en [[XX:toto]] , sauf EVIDEMMENT quand XX=fr, ou il faut utiliser le modèle dont on discute, l'insérer potentiellement en deuxième lien, séparer les paramètres, faire tout un bordel alors que ca pourra être géré très simplement...

Esby (d) 26 juin 2010 à 03:15 (CEST)

Pour les bots ça ne change pas grand chose. Les interwiki links ne sont que les liens multilangue. Les liens interprojets ne sont remontés par l'API que comme des liens externes, la syntaxe . --Hercule ^Discuter 26 juin 2010 à 15:26 (CEST)

Merci pour ces informations. Ça m'enlève quelques doutes. Cantons-de-l'Est 25 juin 2010 à 16:22 (CEST)

Lien externe

Bonjour, pour réaliser un modèle créant un lien externe, je cherche à inclure dans l'adresse web l'exepression « driverinfo » à la place de « romset », si dans {{{1}}} les deux derniers caractères renseignés sont « .c » Actuellement, je n'y arrive pas, je me contente d'intervertir les deux expressions seulement si un troisième champ est (indifféremment) remplis...

[http://www.bla.com/{{#If:{{{3|}}}|driverinfo|romset}}/{{{1|}}} {{{titre|{{{2|}}}}}}]

De l'aide ?! --Arcade Padawan (d) 1 juillet 2010 à 22:41 (CEST)

Les string functions ne sont pas activés sur Wikipédia, on peut donc pas extraire de chaines -- Xfigpower (pssst) 2 juillet 2010 à 17:54 (CEST)

Oui, j'avais déjà rapidement essayé...

Ca m'arrange pas, ca oblige à renseigner un troisième champ alors que c'est totalement inutile :( --Arcade Padawan (d) 3 juillet 2010 à 15:24 (CEST)

{{Palette John Carpenter}}

Salut ! J'ai créé cette palette en m'inspirant de {{Palette Martin Scorsese}} mais j'ai dû me gourer quelque part car la palette n'apparaît pas dans Catégorie:Palette de navigation par réalisateur américain. Quelqu'un pourrait corriger ? Merci d'avance ! Ancalagon (d) 9 juillet 2010 à 11:55 (CEST)

Vu que la page du modèle : Palette Martin Scorsese indique bien la catégorie, je pense plutôt à un problème de raffraîchissement de cache. & n’hésitez bien sûr pas à parler à l’auteur du message : Nemoi, le 9 juillet 2010 à 13:14 (CEST).

Ça fait maintenant plus d'une semaine que le modèle est créé et catégorisé mais il n'apparaît toujours pas. C'est normal ? Ancalagon (d) 15 juillet 2010 à 14:34 (CEST)

Calendrier annuel

Bonjour,

Le modèle {{Calendrier annuel}} crée des liens erronés vers la page d'homonymie Mars au lieu de la page dédiée au mois Mars (mois) (exemple: Année bissextile commençant un dimanche). Le problème se produit pour les cases du calendrier qui sont avant le 1^er mars ou après le 31 mars : la case n'a pas de texte visible, mais possède quand même un lien vers la page d'homonymie. Quelqu'un saurait corriger çà ? Merci --NicoV (d) 14 juillet 2010 à 13:46 (CEST)

Les grands esprits se rencontrent ! Je venais signaler ici le même problème. Outre les problèmes d'homonymie, ces cases sans texte vide mais avec un lien posent de sérieux problèmes d'accessibilité. La solution la plus simple consiste à supprimer ces liens superflus : cela réglera tout d'un coup. Litlok (m'écrire) 16 juillet 2010 à 10:54 (CEST)

Up  ? Litlok (m'écrire) 3 août 2010 à 19:49 (CEST)

Je me permets d'insister... Litlok (m'écrire) 23 octobre 2010 à 22:39 (CEST)

NEMOI, à 1 heures 13, le 24 octobre 2010. − L’ensemble des modèles appelés est vraiment imbuvable. J’ai trouvé une solution pas trop crade, consistant à faire gérer le problème par le modèle : MoisCalendrier/3, qui s’appuie sur les redirection janvier (mois), février (mois), etc. Je pense que c’est la seule solution qui évite de doubler la taille du code. Je saurais gré à un autre modéliste de me relire, sur le modèle précédemment cité et sur le modèle : MoisCalendrier/2.

Modèles qui se mangent

Bonjour,

J'ai détecté un conflit entre les modèles {{Autres projets}} et {{Palette}}. Sur William_McKinley#Notes_et_références par exemple je vois la bande du haut de {{Palette}} qui remonte jusqu'au milieu de {{Autres projets}}. J'ai eu d'autres cas où {{Autres projets}} était carrément dans le cadre de {{Palette}} (qui était donc disproportionné). J'ai résolu le problème en utilisant {{Clr}} entre les deux, mais il y a surement une meilleure correction à apporter à l'un ou l'autre de ces modèles (ou les deux ?).

Si cela est important, je vous donne les informations que j'ai sur mon explorateur:

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729)

Cordialement,

--Hercule ^Discuter 15 juillet 2010 à 18:39 (CEST)

Cite news

Bonjour, y'aurait-il possibilité qu'on modifie le modèle:Cite news de façon à ce que quand on l'utilise, il respecte la syntaxe de Wikipédia en français ? Je sais bien qu'il est obsolète, mais c'est beaucoup plus pratique à reprendre directement les références de la version anglaise quand on traduit, sans avoir à tout ré-écrire dans le modèle:Article...

Avec Cite news, on obtient ça :

(en) (en) Richard Savill, « Student solves debt fear as website earns £56,000 in a month », The Daily Telegraph,‎ 24 septembre 2005 (lire en ligne)

Alors qu'il faudrait ça :

(en) Richard Savill, « Student solves debt fear as website earns £56,000 in a month », The Daily Telegraph,‎ 24 septembre 2005 (lire en ligne)

(Voir aussi Wikipédia:Le Bistro/22 juillet 2010#Cite news) MicroCitron ^{un souci ?} 22 juillet 2010 à 18:35 (CEST)

Problème réglé avec Modèle:Article en. MicroCitron ^{un souci ?} 30 juillet 2010 à 10:33 (CEST)

Substitution multiniveaux (safesubst ?)

Salut,

Je viens de me rendre compte que le modèle {{maladresse}}, lorsqu'il est substitué, affiche « en clair » les parsers ({{#if:blabla}}). J'ai cru comprendre que la solution serait d'utiliser safesubst:, mais je ne comprends pas comment ça marche, quelqu'un peut m'expliquer ? Merci. Skippy le Grand Gourou (d) 30 juillet 2010 à 15:17 (CEST)

Un moyen plus simple est de faire comme Modèle:RCneutralité et consorts : « {{<includeonly>subst:</includeonly>#if:blabla}} ». Dodoïste ^{[ dring-dring ]} 30 juillet 2010 à 16:29 (CEST)

Merci. Mais la doc indique que ces balises doivent être évitées… Mais en tâtonnant (en partie grâce à ton exemple), j'ai trouvé (et compris…) la syntaxe correcte :

{{{{{|safesubst:}}}#if:…}}

Si tu (ou quelqu'un d'autre) pouvais juste jeter un coup d'œil au modèle pour voir si c'est propre à part ça (il y a notamment un problème d'espaces qui ne fonctionnent qu'entourées de balises nowiki), merci.

Question subsidiaire : quelle est la procédure idéale pour faire des tests sur un modèle, le copier temporairement en sous-page ? Là je me suis permis de faire les tests en live parce qu'il n'est pas encore trop utilisé et essentiellement sur des Pdd d'IP, mais je doute que ce soit recommandé…

Merci. Skippy le Grand Gourou (d) 30 juillet 2010 à 17:07 (CEST)

Vu, j'ai mis à jour les 5 modèles que je savais utiliser cette ancienne manière de faire.

Il me semble que l'espace entouré de balises nowiki est assez courant, et que c'est dû à un problème de gestion d'espaces dans la syntaxe des modèles. Un espace insécable «   » (voir le code source) devrait avoir le même effet, mais je ne suis pas sûr que ce soit forcément un meilleur choix.

Modèle:Bac à sable. Sinon, beaucoup d'entre nous (dont moi) utilisent une sous-page personnelle pour faire des tests avant de publier, qui est en effet une pratique fortement encouragée lorsque le modèle est vraiment utilisé. Bien à toi, Dodoïste ^{[ dring-dring ]} 30 juillet 2010 à 17:45 (CEST)

Ok, merci pour tout. Je crois que je préfère encore le nowiki à l'espace insécable là où celui-ci n'est pas nécessaire. Skippy le Grand Gourou (d) 30 juillet 2010 à 17:51 (CEST)

Modèle « récursif » & bonnes manières

Resalut,

Est-ce que quelqu'un pourrait vérifier que le modèle {{Décoration}} et ses sous-modèles du type {{déco OLH}} (le seul existant pour l'instant), créés sur la base du modèle {{drapeau}}, satisfont aux bonnes pratiques ? Merci. Skippy le Grand Gourou (d) 30 juillet 2010 à 15:23 (CEST)

Les icônes dans les modèles du type {{déco OLH}} ne sont pas accessibles. Il faut soit mettre une alternative textuelle pertinente « |alt=décoration Officier de la Légion d'honneur », soit enlever le lien et mettre une alternative textuelle vide « |link= |alt= ». Pour la seconde solution, il faut créditer l'images sur Wikipédia:Crédits graphiques. Je penche plutôt pour la seconde solution. Si quelqu'un (Skippy ?) peut corriger ça sur tous les modèles ça rendrait un fier service.

Je me demande si ce modèle est bien nécessaire, puisque de toute façon il ne fait qu'appeler un modèle déjà existant. Ou alors, il faudrait l'optimiser en se débarrassant du #ifexist qui est assez lourd. Dodoïste ^{[ dring-dring ]} 30 juillet 2010 à 16:58 (CEST)

Bien vu. Pour l'instant il n'y a pas d'autres modèles équivalent à {{déco OLH}}, donc ça va pas être long (je voulais avoir des retours avant de me lancer dans la production de masse). Mais je ne suis pas certain de bien comprendre ta deuxième solution, tu peux la mettre en œuvre sur le modèle ? (Pas de panique, pour l'instant il n'est utilisé que sur sa propre page et sur une « vieille » page du bistro.)

L'idée du modèle {{décoration}} est à la fois de regrouper tous les modèles de ce type en un seul, et de gérer leur mise en page, afin de ne pas avoir à éditer 300 modèles en cas de changement, et de pouvoir indiquer des paramètres. Donc si, je pense que ce modèle est utile. Si le ifexist est vraiment lourd, on peut le supprimer, il n'est pas particulièrement utile, et à la réflexion peut-être même contreproductif. Skippy le Grand Gourou (d) 30 juillet 2010 à 17:21 (CEST)

j'opterais à titre perso pour un switch qui permet de s'affranchir de créer des multiples modèles et autres redirections à la pelle, comme j'ai lancé dans {{m[drapeau2}} -- Xfigpower (pssst) 30 juillet 2010 à 17:26 (CEST)

+1 pour le switch ala {{drapeau2}} et -10 pour les modèles à base de ifexist et de sous-modèles. Il y a quelques modèles de ce type que j'ai pour ma part définitivement renoncé à corriger ou à améliorer tant le résultat peut devenir ingérable, dont {{Drapeau}} justement. --Lgd (d) 30 juillet 2010 à 17:52 (CEST)

@Dodoïste : C'est bon, j'ai compris la deuxième solution en lisant la pdd de {{drapeau2}}.

Aux autres : ok, si tout le monde est d'accord sur le fait que c'est plus propre, je vais retravailler le modèle sur le même principe (mais pas maintenant ). Je le signalerai ici quand ce sera fait.

Merci. Skippy le Grand Gourou (d) 30 juillet 2010 à 18:02 (CEST)

OK, alors c'est bien que tu passes. C'est une bonne pratique que de s'assurer de la qualité d'un nouveau modèle avant d'en faire usage, alors que les corrections sont faciles à faire. Cela devrait se faire plus souvent, et pourrait donner un vrai sens à cet atelier. Dodoïste ^{[ dring-dring ]} 30 juillet 2010 à 20:13 (CEST)

Modèle Autres projets et Commonscats

Bonjour, je viens parler de {{Autres projets}} et {{commonscat}}; Le première d'après la prise de décision doit remplacer le second. ça c'est la théorie. En pratique {{Autres projets}} est très largement sous utilisé par rapport à {{commonscat}}. À la rigueur on peut se dire que finalement ça n'a pas beaucoup d'importance. Et bien si ça pose problème: commons:User:Multichill/Commonscat_stats basé uniquement sur commonscat se retrouve arrêté. c'est un projet qui permet à partir de l'utilisation de commonscat permet de relier les catégories commons à des articles en ajoutant les interwikis. La solution à laquelle je pense pour y remédier n'empêchera pas Multichill de revoir le code mais ça a le mérite de ne pas tout désorganiser... Il faudrait que :

1. on ajoute dans {{Autres projets}} un paramètre sans nom qui sera attribué systématiquement aux catégories Commons (on peut aussi imagine une période de transition avec à la fois un paramètre sans nom et un nommé "catcommons" pour ces liens)
2. rediriger {{commonscat}} vers {{Autres projets}} (je sais ça se fait pas trop mais il faudra bien un jour se débarrasser de {{commonscat}} pour remettre la machine de Multichill en route...)
3. sensibiliser à l'utilisation de {{Autres projets}}...

Alors pourquoi ma remarque: c'est bien simple, je suis utilisateur expérimenté de Wikipédia et Commons, d'ailleurs je suis admin sur ce dernier. Il m'arrive souvent d'importer des fichiers en masse sur commons (travaillant nouvellement dans l'Allier, la zone est plutôt pauvre en photos) et il se trouve que j'utilise encore commonscat. Il est plus simple et facile à poser. ne nécessitant parfois qu'un simple {{commonscat}} sur la page de la commune où on a pris les photos. Si je faisais ça avec {{Autres projets}} cela donnerait à l'heure actuelle {{Autres projets|commons=Category:Nom de la commune}} c'est pas sorcier certes mais c'est long à taper et à des heures tardives il est relativement facile de s'y tromper sur le second. Voilà. Otourly (d) 3 août 2010 à 19:16 (CEST)

Il ne devrait pas être difficile de construire un bot pour convertir {{commonscat}} en format du nouveau modèle; le titre de l'article plus la presense de {{commonscat}} definissent le résultat. Ceci permettrait de continuer d'utiliser commonscat et d'avoir tout de même le nouveau modèle dans l'article. Qui a suffisemment d'expérience de faire la programmation. --Havang(nl) (d) 4 août 2010 à 20:08 (CEST)

Quelqu'un voit un problème avec le fait de faire passer un bot? Quelqu'un est-il disponible pour faire les spécifications? Xavier Combelle (d) 6 août 2010 à 18:19 (CEST)

Je vois seulement que le bot doit détecter la présence de {{Autres projets}} pour ajouter seulement le paramètre et non le moèdle entier. -- Xfigpower (pssst) 6 août 2010 à 18:27 (CEST)

Pour autant que je sache, le système de Multichill sert à lier les catégories Wikipédia aux catégories Commons ; non pas les catégories Commons aux articles. Cela est utilisé pour l'outil CommonSense : l'outil regarde sur quels articles une image non-catégorisée est utilisée, suit les catégories auxquelles il appartient, suit le CommonsCat, et trouve ainsi des catégories à ajouter à l'image. CommonsCat est donc d'une importance primordiale pour le bon fonctionnement de Commons.

De mon point de vue :

• Dans les articles : {{Autres projets}}, because PDD toussa. Bot s'il le faut.
• Dans les catégories : {{CommonsCat}}, parce-qu'il n'y a rien à gagner à faire différemment des autres sinon casser le système, et que s'il est moche, c'est un modèle, on le modifie.

Jean-Fred (d) 11 août 2010 à 23:19 (CEST)

La PDD concerne les articles, pas les catégories. D'ailleurs dans les catégories c'est {{commonscat}} qui est le plus utilisé selon mon ressenti. {{Autres projets}} est l'exception, quand il y a aussi une catégorie sur Wikisource par exemple.

Le problème de commons:User:Multichill/Commonscat stats c'est que {{Commons-inline}} est aussi pas mal utilisé. Si on veut que l'outil marche (puisque visiblement son développeur ne veut pas revoir sa copie et procéder autrement...) il faut plutôt décider si {{Commons-inline}} doit être banni des catégories, au profit de {{commonscat}}. Mais cela ne concerne pas que le projet modèle. --Hercule ^Discuter 13 août 2010 à 03:32 (CEST)

Importer un modèle dans son wiki ?

Salut, bonjour à tous, question très naïve, mais je me permets de la poser malgré tout.

voilà une bonne semaine que je teste MediaWiki et que je regarde toutes les aides disponibles sur le web (pas évident lorsqu'on débute, malgré la présence de la communauté.

Il y a des modèles qui m'intéresse, et que je souhaite importer sur mon blog.

Je sélectionne donc les pages du modèle qui m'intéresse, je fais un export.

Puis j'importe sur mon wiki.

Problème, je perds toute la mise en forme.

Suis-je bon dans la démarche, ou alors malheur, ce n'est absolument pas comme ça qu'il faut procéder.

Merci pour vos retours...

Cordialement

Chritophe

Salut regarde du coté de Mediawiki:Common.css qui contient les styles appliqués sur certains modèles. Cdlt, Kyro ^{cot cot ?} le 11 août 2010 à 00:56 (CEST)

Problème sur l'infobox des états américains

Bonjour, l'infobox des états américains est cassée: suivant les niveaux de zoom et les polices utilisées l'alignement des deux colonnes des cases "superficie" et "population" change jusqu'à avoir parfois une ligne de décalage. Nakor (d) 11 août 2010 à 05:07 (CEST)

C'est infobox qui a été codée avec les pieds. J'ai jamais vu ça o0. Ce ne sont pas des cellules qui sont utilisé ici, mais des sauts de lignes -_- Cdlt, Kyro ^{cot cot ?} le 11 août 2010 à 12:15 (CEST)

En effet, beurk! 9a faisait longtemps que j'avais pas revu des hiddenStructure -- Xfigpower (pssst) 12 août 2010 à 09:07 (CEST)

Il y en a toute une liste (mais peut-être pas à jour) dans cette discussion de l'atelier accessibilité. Cordialement, --Lgd (d) 12 août 2010 à 09:15 (CEST)

Bon, ben, j'ai attaqué le chantier ->{{Infobox État des États-Unis/Refonte}} -- Xfigpower (pssst) 12 août 2010 à 18:00 (CEST)

Bandeau {{Job queue}}

Je trouve que ce bandeau prend vraiment trop de place. C'est pourquoi j'ai créé sur cette page une version du bandeau plus compacte en hauteur (environ 10 %). Qu'en pensez-vous ? od†n ^{[dead words]} 2 novembre 2010 à 02:28 (CET)

peu de différence donc vas-y franco (j'ai l'icone qu'apparait pas mais je sais pas si ça vient des problèmes upload.commons) -- Xfigpower (pssst) 4 novembre 2010 à 22:36 (CET)

J'aurais besoin d'obtenir des retours supplémentaire sur cette suggestion de modèle, qui ajoute quand même pas mal de styles CSS inline... od†n ^{[dead words]} 11 novembre 2010 à 18:51 (CET)

Modèle:Job queue est proposé à la suppression

Bonjour, L’article Modèle:Job queue (page supprimée) a été proposé à la suppression (cf. Wikipédia:Pages à supprimer). 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 Discussion modèle:Job queue/Suppression. Le meilleur moyen d’obtenir un consensus pour la conservation de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible. N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

--Hercule ^Discuter 16 décembre 2010 à 19:35 (CET)

Modèles de documentation

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

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

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

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

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

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

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

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

Modèle:Ouvrage

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

Modèle:MathSciNet

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

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

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

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

Modèle:Max

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Remplacement des modèles obsolètes

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

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

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

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

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

{{Méta palette de navigation}}

Bonjour, le Common.css contient ce style :

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

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

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

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

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

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

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

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

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

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

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

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

Modèle:Coord et infoboxes

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

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

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

Drapeaux

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

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

tandis que {{USA-d}} donne :

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

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

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

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

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

Bonjour,

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

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

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

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

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

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

modèle:infobox Col

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

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

Uniformisation des modèles IMDb

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

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

• « Chapeau melon et bottes de cuir » (présentation de l'œuvre), sur l'Internet Movie Database
• ← notez aussi le point qui serait à supprimer
• (en) Récompenses pour Chapeau melon et bottes de cuir sur l’Internet Movie Database
• (en) Lucasfilms sur l’Internet Movie Database

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

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

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

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

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

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

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

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

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

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

Cordialement,

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

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

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

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

On arriverait donc à quelque chose comme cela :

• (en) Site Web officiel
• Chapeau melon et bottes de cuir sur l’Internet Movie Database  – Version plus complète en anglais
• « Chapeau melon et bottes de cuir » (fiche série), sur Allociné

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

infobox monarque

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

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

Fusion de modèles de mise en colonnes

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