Discussion Projet:Modèle

(Redirigé depuis P:MQ)
Dernier commentaire : il y a 2 heures par Menthe 555 dans le sujet Palettes en version mobile
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
  • Commons
Le salon des modélistes

Questions générales. On discute du projet modèle.

Afin de vous assurer que vous faites votre demande au bon endroit, veuillez consulter l’encadré ci-dessous et déterminer si vous postez au bon endroit.

Le salon des modélistes concerne principalement les discussions à propos du projet, mais aussi les questions générales portant sur les modèles si les différentes rubriques d’aide n’y répondent pas. Toute demande qui aurait dû être faite dans l’une des pages mentionnées ci-dessous n’est pas faite au bon endroit, elle pourrait être ignorée.

Question aux modélistes

Annonces (section remplie automatiquement)

Modèles proposés à la suppression

Nouveaux modèles

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

Erreur Lua dans Module:Infobox à la ligne 1059 : attempt to index local 'moduledata' (a boolean value). modifier

Bonjour,

Quelqu'un peut m'aider à régler le problème ici : {{Infobox Affaire judiciaire}} ? - Simon Villeneuve 25 septembre 2023 à 17:07 (CEST)Répondre

@Simon Villeneuve C'est corrigé, le code lua ne renvoyait rien.
Vous pouvez regarder Aide:Infobox en Lua pour des indications sur la création d'infobox en lua. Escargot (discuter) 25 septembre 2023 à 17:23 (CEST)Répondre
Ok. Merci beaucoup pour ton aide. - Simon Villeneuve 25 septembre 2023 à 19:13 (CEST)Répondre
Resalut Escargot bleu,
J'ai lu la page que tu m'as conseillée. Je te dirais qu'elle ne m'aide pas beaucoup. On y décrit pas tous les types (par exemple, le type 'mixed' n'est pas décrit) et on n'indique pas, ou trop peu, comment gérer les types. On donne des liens vers des exemples, mais ceux-ci ne sont pas très explicites.
As-tu (ou avez-vous les autres) de meilleurs liens sur le sujet ? - Simon Villeneuve 27 septembre 2023 à 19:43 (CEST)Répondre
Bonjour @Simon Villeneuve,
J'ai regardé dans le code, et actuellement 'mixed' a le même effet que 'row'.
Généralement, le plus simple reste de faire des copier-coller de ce qui existe déjà. Est-ce que tu as des idées particulières de fonction plus complexe que simplement récupérer la valeur de Wikidata ? Escargot (discuter) 27 septembre 2023 à 20:35 (CEST)Répondre
Bonjour,
J'aurais, par exemple, aimé mettre sous la forme d'un tableau à 2 colonnes les parties dans l'infobox affaire judiciaire, comme il se fait pour les belligérants dans {{Infobox Conflit militaire}}. Le plus proche que j'ai trouvé est une séparation de type "succession", comme pour les lignes 166 à 180 du module:Infobox/Ouvrage, mais ce n'est pas approprié.
D'ailleurs, le type "navigator" utilisé dans ce module n'est pas décrit non plus sur la page d'aide que tu m'as pointée. - Simon Villeneuve 27 septembre 2023 à 21:06 (CEST)Répondre
Effectivement, la documentation n'est pas totalement à jour. Le type 'navigator' sert à faire des séries page d'avant / page d'après.
Il n'y a pas de fonction pour faire ce genre de tableau. Je ne sais pas si c'est le résultat d'une discussion ou simplement que personne ne s'est encore occupé d'en faire une. Escargot (discuter) 27 septembre 2023 à 22:15 (CEST)Répondre

Utilisation des bandeaux de maintenance, besoin d'adaptation pour pouvoir retrouver rapidement le poseur d'un bandeau modifier

Bonjour à toutes et à tous,

Sur la recommandation de SyntaxTerror, je reproduis ci-dessous les discussions dans le Bistro sur ce sujet :

15 octobre : accumulation de bandeaux modifier

En parcourant l'encyclopédie, je constate trop fréquemment des accumulations de bandeaux dans les articles, exemple : Revue Projet. Apparemment, certains contributeurs n'ont pas lu assez attentivement Aide:Bandeau, qui préconise de ne pas dépasser deux bandeaux en utilisant le modèle {{problèmes multiples}}. Cela rend difficile la maintenance. Pour plus de détails, voir : Aide:Bandeau#Accumulation de bandeaux.Pautard (discuter) 15 octobre 2023 à 05:46 (CEST)Répondre

Bonjour Pautard,
Il se trouve que l'article donné en exemple ne comporte que deux modèles : {{Admissibilité à vérifier}} et, précisément, {{Problèmes multiples}}. — 🦊 jilucorg converser, le 15 octobre 2023 à 09:19 (CEST)Répondre
Peut-être qu’au lieu de discuter des bandeaux nous pouvons régler le problème ? C’est ce que j’ai fait. Bonne continuation. Uchroniste 40 15 octobre 2023 à 10:20 (CEST)Répondre
Ah oui, Uchroniste 40, en effet, problèmes réglés ! Émoticône — 🦊 jilucorg converser, le 15 octobre 2023 à 11:40 (CEST)Répondre
Merci.Pautard (discuter) 15 octobre 2023 à 11:58 (CEST)Répondre

16 octobre : Accumulation de bandeaux (suite), comment apposer un bandeau ?, retrouver l'auteur d'un bandeau modifier

Suite de la discussion d'hier sur l'accumulation des bandeaux. Notification Uchroniste 40 et Pharma : Encore merci à Pharma pour le tuyau de l'outil Wikiblame qui permet de retrouver la version d'un article et l'auteur d'un bandeau. Le problème est résolu sur l'article Revue Projet, il reste juste à enlever le bandeau « admissibilité à vérifier » ; j'ai demandé à Fourmidable s'il m'autorisait à enlever ce bandeau. Mais le problème de l'accumulation des bandeaux subsiste sur beaucoup d'autres articles qui ont de multiples bandeaux, qu'il faudrait remplacer par le bandeau {{Problèmes multiples}}. Fourmidable, qui est au demeurant très sympathique (je l'ai rencontré récemment à un Wiknic), passe dans de nombreux articles en faisant un travail de maintenance certainement remarquable (je l'en remercie), en mettant en commentaire « Introduction ». Cela ne pose sans doute aucun problème, sauf lorsqu'il appose un bandeau de maintenance, car il ne met aucun commentaire précis (si ce n'est « introduction »), ni dans la barre de modification d'article, ni dans la page de discussion de l'article, contrairement aux recommandations de Aide:Bandeau#Apposer un bandeau. Il peut toucher là à des problèmes de fond de l'article, qui ne se résolvent pas sans discussion. Fourmidable a bien compris qu'il était préférable d'utiliser le modèle « Problèmes multiples ». Bref, le problème des bandeaux multiples ne concerne évidemment pas que Fourmidable. Par ailleurs, même lorsqu'il y a peu de bandeaux, retrouver l'auteur d'un bandeau n'est pas aisé, même avec la date en paramètre et l'outil Wikiblame. Si on pouvait introduire le paramètre « auteur » dans les bandeaux, en plus de la date, cela serait vraiment très utile. Faut-il en parler au projet maintenance et dans quel espace de discussion ?Pautard (discuter) 16 octobre 2023 à 06:06 (CEST)Répondre

Bonjour Pautard. Il faut en parler sur Discussion projet:Modèle.
Ajouter un paramètre auteur rempli automatiquement est facile, il suffit d'utiliser le mot magique REVISIONUSER (par exemple [[Utilisateur:{{safesubst:REVISIONUSER}}]] pour avoir un lien)
Ça semble a priori une bonne idée, mais il faut quand même en discuter avant pour voir s'il y a d'éventuels inconvénients.
Sinon, {{Problèmes multiples}} ne regroupe pas tous les bandeaux possibles [1], quant à son remplacement des autres bandeaux, il ne fait pas consensus [2].
Notification FDo64, l'auteur de la nouvelle version de {{Problèmes multiples}}.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 16 octobre 2023 à 12:53 (CEST)Répondre
Bonjour. Il est vrai qu'en 2019 j'avais proposé de remplacer plus de 80 modèles par ce modèle unique que j'avais complété. On aurait pu l'utiliser comme les modèles {{Ébauche}}, {{Portail}} ou {{Palette}}. Cela a été refusé. Pourquoi faire simple quand on peut faire compliqué ? --FDo64 (discuter) 16 octobre 2023 à 13:14 (CEST)Répondre
Je distingue pour ma part entre les bandeaux simples ou formels, qui ne prêtent guère à discussion, et les bandeaux compliqués posant des problèmes graves ou de fond. Dans le dernier cas, ces bandeaux devraient s'accompagner de motifs argumentés en PDD de l'article, ce qui se fait plutôt rarement. C'est au poseur de bandeau de faire l'effort de se faire comprendre, pas aux autres de retrouver sa trace ou de deviner sa pensée.--Pat VH (discuter) 16 octobre 2023 à 14:48 (CEST)Répondre
Bonjour et merci Notification SyntaxTerror, FDo64 et Nguyen Patrick VH : pour vos réponses. Je suis entièrement d'accord avec Nguyen Patrick VH : le poseur de bandeau doit effectivement faire des efforts pour se faire comprendre, surtout pour les bandeaux qui posent des problèmes de fond, ou sur les articles sensibles. J'ai eu le cas il y a quelques années avec l'article Antijudaïsme. Ne faudrait-il pas développer cette recommandation dans Aide:Bandeau#Apposer un bandeau ou dans la description du bandeau « travail inédit » (ou d'autres) ? Je retiens l'excellente idée d'en discuter dans Discussion projet:Modèle (merci SyntaxTerror). Je partage le point de vue de FDo64 : évitons les usines à gaz ; les contributeurs sont tous bénévoles, il n'ont pas beaucoup de temps à consacrer à WP et attendent des solutions simples ! CordialementPautard (discuter) 16 octobre 2023 à 17:07 (CEST).Répondre
Du même avis concernant les bandeaux multiples : plutôt que d'indiquer au rédacteur ou au lecteur qu'il y a, respectivement, un problème à corriger, ou une attention particulière à accorder au contenu par prudence, le bandeau dissimule en quelque sorte la poussière sous le tapis et rend bien plus difficile pour les rédacteurs l'identification des problèmes au premier coup d'œil, alors que chacun connaît désormais la forme et les attributs d'un bandeau d'admissibilité à vérifier ou de wikification.
Pour ce qui est de l'ajout automatique de l'utilisateur, je n'y suis pas opposé, mais j'ai une réticence : il ne faut pas que ça alimente une forme de harcèlement contre des contributeurs, notamment sur certains articles. DarkVador [Hello there !] 16 octobre 2023 à 18:19 (CEST)Répondre
Bonjour DarkVador79-UA Émoticône Bien d'accord avec vous : il ne faut pas que cela alimente une forme de harcèlement contre des contributeurs, qui font de leur mieux. J'ajoute que placer l'auteur (le pseudo) dans un bandeau d'un article, c'est-à-dire dans l'espace encyclopédique, peut poser des problèmes de confidentialité : je n'aimerais pas que mon pseudo apparaisse dans les bandeaux que je serais amené à apposer dans une multitude d'articles. De la même façon, j'imagine que tous les contributeurs de WP.fr seraient réticents à divulguer leur pseudo. Solution possible : placer le pseudo de l'auteur du bandeau en page de discussion de l'article. Nous avons besoin d'un cahier des charges bien ficelé. Qu'en pensez-vous ?Pautard (discuter) 16 octobre 2023 à 19:37 (CEST)Répondre
Autre piste : créer une balise qui permettrait de détecter l'ajout d'un bandeau lors d'une modification, indépendamment de ce que contient le résumé de celle-ci, à la manière des révocations par exemple.
Peu importe la manière, je pense qu'un tel changement devrait être soumis à un vote de la communauté. — Pharma 💬 16 octobre 2023 à 20:58 (CEST)Répondre
Edit : en fouillant un peu, j'ai trouvé le filtre 351 qui ajoute la balise retrait bandeau maintenance lorsque c'est fait par des utilisateurs non autopatrolled. À voir donc si on peut prendre exemple dessus.
Notification Pharma : Peut-être (je ne suis pas très technicien). Il est possible que mon idée de placer l'auteur en page de discussion ne soit pas la meilleure, car elle ne préserve pas la confidentialité en interne de WP. Quoi qu'il en soit, nous n'en sommes pas encore à l'élaboration de la solution. Lorsque nous aurons quelques solutions possibles, il faudra évidemment les soumettre à un vote de la communauté. Si vous en êtes d'accord, je propose de transférer demain matin les discussions d'hier et d'aujourd'hui dans Discussion Projet:Modèle, et de continuer la discussion dans cet espace de discussion. Bonne soirée à toutes/tous.Pautard (discuter) 16 octobre 2023 à 21:26 (CEST)Répondre
@Pautard : le problème de confidentialité ne se pose pas puisque la pose du bandeau se retrouve dans l'historique de la page. Par contre, l'afficher sur l'article est effectivement une mauvaise idée.
Sinon, j'ai dit une bêtise en parlant d'utiliser un mot magique, ça ne marcherait que si on substitue le modèle, pas en l'apposant normalement. Il faut que le mot magique ait été écrit dans la modification, soit par le contributeur directement, soit par l'intermédiaire de la substitution du modèle, qui recopie son code dans la page, comme par exemple pour {{Test 1}} où un lien vers la PdDU du déposant est créé dans le lien « me contacter » en fin de message. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 16 octobre 2023 à 23:31 (CEST)Répondre
Bonjour @SyntaxTerror. On peut très bien techniquement créer un modèle qui, substitué, donnera, dans la page, le code {{Nom de bandeau|utilisateur=nom du compte déposant}}. Il me semble, sans certitude, avoir déjà vu cette possibilité mise en œuvre directement dans le modèle concerné (sans avoir besoin de créer un modèle annexe dédié à la substitution), en jouant sur le fait que le modèle est sollicité en substitution ou non (s'inspirer du Modèle:Ifsubst). Dans tous les cas, la syntaxe pour l'utilisateur qui souhaite bénéficier de cette "signature automatique" devra porter le préfixe subst:.
Comme d'autres ici, j'estime sur le fond que, sauf cas évident du type Modèle:Sans source, la pose de bandeau devrait systématiquement être accompagnée d'une explication au travers d'un paramètre « motif » ou « raison » (Certains modèles de maintenance en intègrent déjà un ; une harmonisation serait bénéfique.) ou en page de discussion associée à l'article. Le poseur doit faire l'effort de motiver son action, pour l'amélioration de l'encyclopédie. Il comprendra peut-être qu'il est parfois plus efficace de corriger directement les erreurs plutôt que de poser un bandeau dont le sens ne sera pas saisi facilement par les autres. Par exemple, le terme « wikification » recouvre tellement de choses qu'il n'est pas évident d'identifier de façon exhaustive, les éléments à rectifier dans un article. Et, bien entendu, il est indiqué de signaler directement aux rédacteurs réguliers les points sur lesquels ils peuvent s'améliorer (habitudes à prendre). Cordialement, — Ideawipik (discuter) 17 octobre 2023 à 11:48 (CEST)Répondre
@Ideawipik : le truc avec REVISIONUSER c'est que la personne qui pose la bandeau n'a pas besoin de mettre son nom (et aussi, on ne peut pas « tricher » avec ce mot magique, à moins de revenir éditer par derrière une seconde fois).
Le problème est qu'il faut subster le modèle, ce qui n'est normalement pas fait dans le domaine principal, ni est une chose que la majorité des utilisateurs savent faire. À part pour les modèles sur les PdDU comme {{Bienvenue}} ou {{Test 1}}, cette méthode n'est quasiment jamais utilisée, et vouloir changer du jour au lendemain les habitudes pour un point de détail comme avoir le nom du poseur du bandeau n'est certainement pas une chose qui va être acceptée, ni même respectée à mon avis.
Rendre obligatoire les paramètres « raison », voire « utilisateur » (ne pas oublier l'alias « utilisatrice » pour ne pas lever encore plus de boucliers) est une chose beaucoup plus sensée je pense, avec l'affichage d'un message d'erreur à la place du bandeau au lieu d'une simple mention qu'on ne les a pas renseignés est bien mieux.
Sinon, afficher le nom du poseur du bandeau sur l'article n'est pas une bonne chose (même s'il n'y a pas de problème de confidentialité étant donné qu'on retrouve le nom d'utilisateur dans l'historique), par contre, qu'il soit recopié en PdD de l'article, idéalement dans la sous-page /À faire, pourrait très bien être fait par un bot automatiquement, comme on le fait déjà pour l'ajout des dates de pose.
Un bot pourrait aussi afficher un message dans la PdDU du poseur s'il n'a pas mis de raison/son nom, et/ou effacer après quelques jours les bandeaux sans raison/nom.
Ça pose le problème de tous les bandeaux sans raison/nom qui sont déjà présents.
À mon avis, la chose à faire en priorité est d'uniformiser les bandeaux en mettant « raison » (avec comma alias « motif ») partout où c'est souhaitable. Après on pourrait voir à trouver un bot pour remplir les PdD avec le nom du poser du bandeau.
Ce sont deux choses différentes, la première me semblant beaucoup plus importante que la seconde, mais les deux doivent au moins être discutées dans un sondage avec un nombre raisonnable de participants pour qu'elles soit implémentées sans trop de remous.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 octobre 2023 à 16:29 (CEST)Répondre
Bonjour Pautard, SyntaxTerror et Ideawipik. Je propose de recommander dès maintenant de remplir un paramètre utilisateur= dans le code des bandeaux qu'on pose, en proposant dans les pages de documentation des modèles de bandeau les codes (pour prendre l'exemple de {{À sourcer}}) :
  • {{À sourcer|date=mars 2024|utilisateur=}}
  • {{À sourcer|date=mars 2024|utilisateur=~~~}}
Le deuxième code prêt à l'emploi affiche dans le code de l'article celui de la signature, qui est parfois un peu compliqué mais contient toujours le nom de l'utilisateur.
Le nom d'utilisateur serait donc présent dans le code de l'article, et donc facile d'accès pour des éventuels bots, mais pas affiché par le modèle. La seule façon dont le modèle prendrait en compte ce paramètre serait d'afficher un petit message d'erreur si il n'est pas rempli, sur le modèle du « (indiquez la date de pose grâce au paramètre date) » affiché si on ne remplit pas la date.
Je pense que c'est un bon compromis entre mettre un peu de pression au poseur de bandeau pour qu'il indique son nom d'utilisateur (avec le message d'erreur visible sur l'article si ce n'est pas fait), ne pas risquer de dégrader l'article (ce message d'erreur reste discret), ne pas exiger du poseur du bandeau une trop grande technicité, et préserver son anonymat auprès du grand public. C'est aussi un changement plutôt en douceur (on recommande un changement d'habitude des patrouilleurs, on ne l'impose pas) et qui ne nécessite pas de bot pour être mis en place. Je ne pense pas non plus nécessaire de faire un sondage chronophage : on en discute ici, sur le BP, on essaie et on verra les réactions à l'usage. Si on obtient un consensus sur le fait qu'indiquer le nom d'utilisateur est indispensable, alors on pourra passer de la recommandation à une obligation avec des conséquences plus importantes en cas d'omission (gros message d'erreur à la place du bandeau, avertissement par bot etc.).
Qu'en pensez-vous ? l'Escogriffe (✉) 20 octobre 2023 à 23:49 (CEST)Répondre

┌─────────────────────────────────────────────────┘

Bonsoir GrandEscogriffe. D'un point de vue technique, utiliser ~~~ ne va pas marcher, ça met juste la signature sans la date.
Par exemple pour moi :
  • ~~~ donne : Şÿℵדαχ₮ɘɼɾ๏ʁ (c'est-à-dire ma signature perso : <span class="nowrap">[[User talk:SyntaxTerror|Şÿℵדαχ₮ɘɼɾ๏ʁ]]</span>)
  • {{u|~~~}} donne : [[:fr:User:{{{1}}}|{{{1}}}]] ([[:fr:User Talk:{{{1}}}|d]] · [[:fr:Special:Contributions/{{{1}}}|c]] · b)
Ce qu'il faut utiliser pour un code à recopier depuis la page de doc, c'est ce que je proposais avant : {{REVISIONUSER}}
Après, si tu connais beaucoup de gens qui vont lire la doc des modèles avant de les utiliser, chapeau. Pour info, certains utilisent encore des codes d'une infobox dont je tairais le nom avec des paramètres obsolètes depuis dix ans, et quand on va voir les erreurs dans la plupart des modèles à paramètres sur wstat.fr, on tombe des nues...
Au moins il me semble qu'avec l'éditeur visuel, on peut forcer des paramètres obligatoires (je sais pas trop, j'utilise jamais ce truc). En tout cas, il faut vraiment faire le plus « idiotproof » possible.
Sinon, je le répète, l'anonymat n'est pas en question, la pose du bandeau est dans l'historique, il suffit d'aller y regarder pour savoir. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 21 octobre 2023 à 00:28 (CEST)Répondre
Bonjour SyntaxTerror. L'utilisation du {{REVISIONUSER}} ne peut être profitable qu'en substitution, pas si le mot magique est appelé dans l'article, ni directement dans un modèle inclus (sinon, c'est toujours le nom du dernier éditeur de la page qui sera considéré par le logiciel, information trompeuse, comme on peut le constater avec certains messages préformatés déposés en page de discussion utilisateur en oubliant de les substituer). Mon idée était que l'on puisse écrire le code court {{subst:Bandeau|raison=…}} pour obtenir dans la page après enregistrement {{Bandeau|date=…|utilisateur=…|raison=…}}, c'est-à-dire un ajout automatique, dans un format correct, des date de dépôt et nom du déposant. Si le déposant écrivait sans le subst, le code ne serait pas changé (i.e. sans date/signature). Note : on est d'accord que le contenu du modèle de bandeau ne doit pas être substitué sur la page ; dans ma proposition, même si on appelle le modèle avec un subst, l'appel résultant final serait en inclusion. Limites et inconvénients de cette méthode : 1. Elle demande de complexifier un peu le code des modèles et occasionne une légère augmentation des ressources nécessaires à leur exécution. 2. Besoin de "traiter" les bandeaux de manière assez exhaustive, car la syntaxe appliquée à un modèle pour laquelle elle n'aurait pas été prévue serait problématique (substitution indue). 3. Mutualisation (avec un méta-modèle) à tester, mais ne semble pas évidente. Alternative sans ces inconvénients : créer un nouveau modèle à substituer « Dépôt bandeau » dont un des paramètres serait le nom du bandeau souhaité.
La proposition de GrandEscogriffe présente l'avantage de ne pas avoir à effectuer de "substitution". On peut la simplifier et regrouper vos souhaits respectifs par {{Bandeau|date={{subst:LOCALMONTHNAME}} {{subst:LOCALYEAR}}|utilisateur={{subst:REVISIONUSER}}|raison=…}}. D'ailleurs, on doit aussi pouvoir ajouter les valeurs automatiques ("autovalue") dans les TemplateData des documentations des modèles afin de faciliter l'insertion via l'éditeur visuel.
Passé ces éléments techniques, je ne suis pas certain qu'avoir en dur dans l'article, le nom du déposant soit indispensable. Les contributeurs changent et disparaissent ; les bandeaux restent parfois très longtemps dans les articles. Soit la présence d'un bandeau est pertinente, auquel cas peu importe qui en est à l'origine, soit elle ne l'est pas et n'importe qui peut retirer le bandeau. En revanche, l'explication de la raison de l'ajout est généralement un élément crucial pour aider les suivants. — Ideawipik (discuter) 22 octobre 2023 à 12:24 (CEST)Répondre
Bonjour Ideawipik. Tu m'apprends un truc que je ne savais pas avec REVISIONUSER. En effet, ça ne marche pas.
Sinon, je pense aussi que ce problème n'en est pas vraiment un, ou du moins il n'est pas suffisamment fréquent pour avoir à s'en soucier, surtout qu'on peut trouver l'utilisateur qui l'a déposé relativement facilement.
Sans compter qu'une nouvelle façon d'utiliser un modèle ne va pas être adoptée du jour au lendemain.
Une autre idée : on pourrait aussi demander à un bot de mettre un message sur la PdDU de ceux qui n'ont pas rempli le motif, comme le bot qui fait la même chose pour les messages non signés. Şÿℵדαχ₮ɘɼɾ๏ʁ 22 octobre 2023 à 13:16 (CEST)Répondre

Résumé du besoin modifier

Afin d'éviter la prolifération anarchique des bandeaux de maintenance dans les articles de l'encyclopédie (voir Aide:Bandeau, section « Accumulation de bandeaux »), ce qui nécessite de pouvoir enlever plus facilement les bandeaux, disposer d'une fonctionnalité permettant aux auteurs d'un article de retrouver rapidement et aisément le poseur du ou des bandeau(x). Cette fonctionnalité permettrait aux auteurs de l'article de discuter plus facilement sur le ou les problèmes à l'origine de la pose du ou des bandeaux. La méthode disponible dans l'historique (outil Wikiblame) ne permet pas de retrouver rapidement le poseur d'un bandeau avec seulement la date comme paramètre. Pour des questions de confidentialité, respecter l'anonymat des poseurs de bandeaux dans l'espace encyclopédique Pautard (discuter) 17 octobre 2023 à 07:26 (CEST)Répondre

subst: ne fonctionne pas ou plus pour certains modèles appelant un module modifier

Voir Modèle:Infobox Biographie2/Test#Substitution. Subster le modèle fait perdre l'effet du paramètre.

Je ne sais pas avec certitude quels sont les cas d'échec. Peut-être ceux où le paramètre donné au modèle appelant n'est pas injecté dans le #invoke mais récupéré par le module via frame.getParent().

Je crois qu'il y a quelque temps ça fonctionnait. l'Escogriffe (✉) 24 octobre 2023 à 00:05 (CEST)Répondre

Ça ne m'a l'air effectivement pas normal, ça sent le bug dans MediaWiki. En faisant quelques essais, j'ai aussi remarqué les points suivants :
  • Sur la page Spécial:ExpansionDesModèles (qui je crois, n'utilise pas tout à fait le même parseur), le {{subst:}} ne fonctionne pas du tout, ça retourne le code non interprété. Sans certitude, je suppose que cela devait fonctionner auparavant.
  • J'ai essayé avec {{safesubst:}}, et là ça fonctionne correctement.
od†n ↗blah 24 octobre 2023 à 00:59 (CEST)Répondre

Documentation du modèle {{WikidataOI}} modifier

Je trouve la documentation (de ce modèle) déconnectée de la réalité. Merci de bien vouloir prendre connaissance de ma requète dans la sa page de discussion.

Merci Émoticône LeFit (discuter) 25 octobre 2023 à 09:13 (CEST)Répondre

Modèle:Palette Autochtones du Québec modifier

Bonjour. Maintenant que son auteur principal Danalieth a été banni de cette encyclopédie, je voudrais demander ce qu'il faut faire à propos de la surdimensionnée Modèle:Palette Autochtones du Québec. C'était très raisonnable lorsqu'il a été créé par @Fralambert en 2020 : de taille similaire à son homologue canadien Modèle:Palette Autochtones du Canada. Ensuite, l'autre éditeur a commencé à ajouter et à ajouter et vous pouvez voir ce qui s'est passé. Apparemment, tous les articles sous le soleil et les illustrations aussi. Ce n'est pas mon domaine d'expertise, j'ai donc pensé aborder ce sujet ici. merci, Shawn à Montréal (discuter) 5 novembre 2023 à 19:07 (CET)Répondre

Je vais également alerter @Webfil, qui connaît l'éditeur et cette palette. Shawn à Montréal (discuter) 5 novembre 2023 à 19:15 (CET)Répondre
Je commencerait à fait disparaitre les sections Lois, traités et commissions, Histoire générale et mouvements sociaux, Pensionnats pour Autochtones au Canada, Éléments de culture autochtone. Ses sections ne sont pas spécifique au Québec. Fralambert (discuter) 5 novembre 2023 à 19:37 (CET)Répondre
Et dans la section précolombienne aussi, je pense ? Il ne semble pas y avoir de limite de taille recommandée dans l'Aide:Palette de navigation... Shawn à Montréal (discuter) 5 novembre 2023 à 19:46 (CET)Répondre
Salut Shawn à Montréal, Fralambert. Je n'ai pas vraiment envie de toucher à ça de nouveau, c'est rempli de mauvais souvenirs. Je vous soutiens moralement, mais ne m'impliquerai pas. Webfil (discuter) 8 novembre 2023 à 23:14 (CET)Répondre
Je comprends. Quand j'en aurai l'occasion, je commencerai à tailler des liens qui ne sont pas directement liés au Québec, Shawn à Montréal (discuter) 9 novembre 2023 à 00:18 (CET)Répondre
Je l'ai réduit et je pense que c'est mieux : plus comme une palette typique de Wikipédia. Au-delà de la question de nouvelles réductions, il nécessite un peu de réorganisation maintenant que j'ai supprimé certains titres de sections. Il y a des articles dans la section Société du bas qui devraient être consacrés à l'Histoire, par exemple. Je vais faire une pause. Shawn à Montréal (discuter) 9 novembre 2023 à 13:51 (CET)Répondre

Fusion Modèle:Palette Peuples autochtones du Canada et Modèle:Palette Autochtones du Canada? modifier

J'ai pensé que je soulèverais cela ici plutôt que sur la page des fusions car cela peut prendre un certain temps. Mais y a-t-il une raison pour laquelle nous ne pouvons pas fusionner ces deux palettes ? Ils ne sont pas très grands et s'emboîtent naturellement, me semble-t-il. Shawn à Montréal (discuter) 10 novembre 2023 à 20:09 (CET)Répondre

Il faudrait plutôt l'avis du projet:Autochtones du Canada ou au moins du  Projet:Canada, et surtout prévenir de la proposition de fusion sur les PdD des modèles, pour que ceux les ayant dans leur listes de suivi puissent réagir, ainsi que la PdD des créateurs et principaux contributeurs.
Pour info, la {{Palette Peuples autochtones du Canada}} est utilisée sur 30 articles [3], la {{Palette Autochtones du Canada}} sur 50 articles [4], et seule la dernière est présente sur wp.en, wp.ru et wp.simple.
C'est juste un avis technique, je n'ai pas d'avis sur cette fusion. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 11 novembre 2023 à 16:18 (CET)Répondre
C'est fait : Discussion_Projet:Canada#Communautés_autochtones_du_Canada. Merci! Shawn à Montréal (discuter) 11 novembre 2023 à 16:31 (CET)Répondre

Catégorisation d'une sous-page de documentation modifier

Bonjour

Je viens de fignoler le Modèle:Documentation modèle d'indication de langue, mais il reste un problème avec la catégorisation de la page de documentation qui ne devrait pas être dans la Catégorie:Modèle d'indication de langue (il n'est utilisé que par {{lang:pid}} pour l'instant).

C'est sans doute en relation avec les balises <includeonly>, mais je ne sais pas comment faire.

Je ne souhaite pas utiliser {{Méta documentation de modèle}} car certains modèles d'indication de langue sont protégés et je préférerais que n'importe qui puisse modifier la documentation si besoin.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 24 novembre 2023 à 17:29 (CET)Répondre

Notification SyntaxTerror : Bonsoir. C'est une mauvaise idée de ne pas utiliser {{Méta documentation de modèle}}. Rien n'empêche d'avoir tout de même une sous page de documentation. C'est même indiqué :
« Le contenu de la documentation est obtenu depuis la sous-page /Documentation, sauf si le paramètre contenu est renseigné. »
Donc la meilleure solution reste de remettre en place cet meta-modèle.
--FDo64 (discuter) 24 novembre 2023 à 21:38 (CET)Répondre
Bonsoir FDo64. Je vais voir ça. Si je reviens à un {{Méta documentation de modèle}}, je ne mettrai ce nouveau modèle que sur les modèles qui ne sont pas protégés s'il jamais il y a besoin de modifier les paramètres après.
Sinon, y-a-t'il moyen de bloquer l'édition du templatedata ? parce que si l'on essaye de le modifier depuis une page de modèle, ça change la valeur sur le métamodèle, et donc sur tous les modèles.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 24 novembre 2023 à 21:46 (CET)Répondre
Notification SyntaxTerror : Comme je l'indiquais précédement, rien n'empêche d'avoir les deux.
Si on prend l'exemple du modèle protégé {{Gallica}}, il contient {{Documentation de source}} tout en ayant {{Gallica/Documentation}}.
Rien ne t'empêche d'ajouter un paramètre pour désactiver le templatedata si tu veux exceptionnellement en mettre un différent dans une sous-page de documentation.
--FDo64 (discuter) 24 novembre 2023 à 23:38 (CET)Répondre
@FDo64 : je ne parle pas de désactiver le template data, je parle de quelqu'un qui va sur la page du modèle pour décider de modifier le templatedata sans savoir ce qu'il fait. (théorie de Murphy... Émoticône)
Sinon, je n'ai pas bien compris : le modèle {{Documentation de source}} se s'affiche pas si une page de doc existe ?
cf. « Si le modèle de source contient une sous-page de documentation, celle-ci est automatiquement affichée en tant que contenu de ce modèle. » (c'est pas très clair pour moi). Şÿℵדαχ₮ɘɼɾ๏ʁ 24 novembre 2023 à 23:43 (CET)Répondre
Notification SyntaxTerror : C'est vrai que ce n'est pas simple. En regardant le code de {{Documentation de source}} on voit qu'une partie de ce qui est affiché dépend de la présence de la sous-page de documentation.
Après, on fait comme on veut en fonction de ce qu'on veut faire.
--FDo64 (discuter) 25 novembre 2023 à 00:02 (CET)Répondre
OK, merci FDo64. J'essaierai plus tard.
Déjà, je vais remplacer la formule pas claire sur le Modèle:Documentation de source. Şÿℵדαχ₮ɘɼɾ๏ʁ 25 novembre 2023 à 00:08 (CET)Répondre

Encadrer un drapeau dans le modèle BadmintonBox modifier

Hello,

j'ai crée il y a quelques temps un modèle Modèle:Badmintonbox en me servant du modèle existant sur la WP anglophone. Ce modèle permet d'afficher, entre autres, des drapeaux (exemple ici : Sudirman Cup 2023). Mais le souci que je rencontre c'est que le fond est blanc et avec les drapeaux au fond blanc également (Taipei chinois, Corée du Sud), ça ne rend pas très bien. Il y a donc deux solutions : changer la couleur de fond du modèle ou ajouter un petit cadre noir autour des drapeaux.

Changer la couleur de fond, je sais faire : j'ai testé avec du gris clair, c'est moyen. J'aurais voulu voir le rendu de l'encadrement du drapeau mais je ne sais pas faire.

Quelqu'un saurait faire ça ?

Merci. Flammekueche (discuter) 2 décembre 2023 à 15:57 (CET)Répondre

Bonjour Flammekueche. Pour information, les noms des paramètres ont été mis en conformité avec les recommandations du projet (éviter les majuscules initiales, les underscore…) J'ai toutefois hésité entre match 1 et match1 (idem pour tous les paramètres avec numéro) ; en effet, dans les modèles bibliographiques l'usage est d'accoler le numéro. Ailleurs, il y a des disparités : par exemple équipe 1 ou équipe1, en fonction des modèles. La version courte me semble plus lisible (et évite des surprises d'espaces insécables que l'on rencontre parfois à tort dans les appels), donc je ne suis pas opposé à l'adopter. Notification FDo64, bjr, un avis ? Une fois les noms remplacés dans les quelques articles qui utilisent le modèle, il sera possible de simplifier le code du modèle en enlevant les alias. Les icônes de drapeaux sont désormais encadrées d'une bordure (NB : ça pourrait poser un petit souci pour le drapeau népalais ; si besoin une exception peut-être implémentée). Il reste à simplifier le tableau, qui contient au moins trois cases vides (pour quelle destination à l'origine ?), et si possible à réduire les imbrications de tableaux. Documentation (Aide:TemplateData) à rédiger. Cordialement, — Ideawipik (discuter) 2 décembre 2023 à 22:53 (CET)Répondre
Bonsoir Ideawipik Émoticône. Je suis toujours favorables aux harmonisations.
Pour ce qui est des paramètres numérotés, comme je n'ai pas vraiment d'avis, j'ai regardé le modèle le plus utilisé ayant des paramètres numérotés, {{Lien web}} : les chiffres sont collés aux paramètres.
J'ajoute qu'il m'est arrivé de rajouter un zéro pour tous les chiffres inférieurs à 10. Ça permet un meilleur tri et alignement.
--FDo64 (discuter) 2 décembre 2023 à 23:30 (CET)Répondre
Notification Ideawipik et FDo64 : heu... je n'ai pas tout compris Émoticône. Comme je l'ai indiqué, j'ai adapté un modèle déjà existant donc toues les subtilités liées aux modèles me sont inconnues...
Si j'ai tout compris, il faut que :
- je modifie le code afin d'afficher "match1" plutôt que "Match_1", idem pour "Score 1" en "score1", etc. Et je modifie de même toutes les pages où le modèle est utilisé sinon il ne trouvera pas la correspondance.
- quid de "nom équipe 1" ? Si on accole tout, ça devient beaucoup moins lisible...
Les cases vides ? Je ne vois pas de quoi il s'agit.
Visuellement, je ne vois pas de cadre autour des drapeaux. Y a-t-il une modif à faire ?
Merci, Flammekueche (discuter) 4 décembre 2023 à 10:03 (CET)Répondre
Bonjour Flammekueche. Le plus important est d'avoir une cohérence au sein des paramètres du modèle. En général, on essaie aussi d'avoir une harmonie à l'échelle de l'encyclopédie. Les modèles bibliographiques tels {{Ouvrage}}, {{Article}}, {{Lien web}} fonctionnent avec des numéros accolés dans le nom de paramètre. Des modèles comme {{Poule}}, {{Poule Coupe du monde de football}}, {{Feuille de match déroulante}}, {{Foot match}}, {{Hockeybox}} ont des paramètres équipe1. En revanche d'autres ({{Feuille de match}}, {{Tableau de matchs de cricket ligne}} et {{Médaillés pentathlon}}) emploient équipe 1. Comme FDo64, je serais plutôt favorable à tendre vers une harmonisation avec les chiffres collés. Ça ne me semble pas altérer la lecture. « Nom équipe2 » est une formulation claire puisqu'il s'agit du nom de la deuxième équipe. Par contre s'il s'agissait du deuxième nom d'une unique équipe l'espace serait, à mon avis, légèrement préférable sémantiquement. Autre exemple fictif : « nom de scène[ ]2 » (nom de la 2e scène ou 2e nom de scène ?). Techniquement, l'accolement systématique pourrait être un usage généralisé (d'autant plus si les modèles ne portent pas à confusion quant à fonction de chaque paramètre). Il est aussi possible de faire accepter au modèle les deux options, mais il vaut mieux limiter cela, pour ne pas alourdir le code et le fonctionnement et pour ne pas faire croire que les deux syntaxes sont valides quel que soit le modèle. Si cela vous va, je peux modifier le code du modèle pour que les paramètres en minuscule et sans espaces soient valides et retirer le superflu. Je me chargerai aussi de la documentation, afin que les futurs utilisateurs sachent quels paramètres utiliser.
Les cadres autour des drapeaux sont en gris, donc pas très visibles, mais normalement c'est suffisant pour identifier le bord des drapeaux sur fond clair. Voir ceux du Japon et de la Corée du Sud dans l'exemple donné.
Pense-bête. Les paramètres des modèles {{Match Hopman Cup}} et {{Match Coupe Davis}} sont à harmoniser.Ideawipik (discuter) 4 décembre 2023 à 16:16 (CET)Répondre
Notification Ideawipik : je ne dis pas non pour un coup de main. J'avais pas mal galéré pour mettre au point ce modèle, en me servant je crois de son pendant anglophone et de ceux pour la Coupe Davis. Du coup, là, pour m'y remettre il me faudra des jours avant de tout avoir à nouveau en tête.
Flammekueche (discuter) 5 décembre 2023 à 16:52 (CET)Répondre

Modèle:Carte communes limitrophes modifier

Bonsoir. Sur la page Périgueux j'ai ajouté {{Carte communes limitrophes|zoom=11}}, qui a un visiblement un problème d'affichage car la commune de Boulazac Isle Manoire située au sud-est, n'apparait pas en gris foncé. Quelqu'un pourrait-il remédier à ce problème, que j'ai remarqué sur d'autres pages (je ne sais plus lesquelles) où m'expliquer comment faire. Merci, cordialement--William Jexpire (discuter) 2 décembre 2023 à 21:58 (CET)Répondre

Bonjour William Jexpire. Je pense que le problème vient d'un des modules utilisés (Module:Carte interactive, Module:Interface Wikidata, Module:Wikidata, Module:Coordinates) et qu'il faudrait plutôt faire la demande sur le  Projet:Scribunto. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 3 décembre 2023 à 11:58 (CET)Répondre
Merci, j'y vais de ce pas. Cordialement--William Jexpire (discuter) 3 décembre 2023 à 17:20 (CET)Répondre
Bonjour William Jexpire. Je dis peut-être une bêtise, mais les éléments observables portent à croire qu'il s'agit plutôt d'un renseignement incorrect ou manquant dans Wikidata pour l'élément Boulazac Isle Manoire (ou dans ceux de ses voisins). À priori, les limites de la commune ne sont pas enregistrées. Dans la situation de l'article mentionné, le modèle {{Carte communes limitrophes}} récupère toutes les données affichées depuis Wikidata. Si on le met dans l'article d'une autre localité attenante à la commune, les territoires des voisins sont bien affichés sauf celui de « Boulazac Isle Manoire ». — Ideawipik (discuter) 3 décembre 2023 à 20:16 (CET)Répondre
Bonsoir Ideawipik. Je viens de voir que les coordonnées de Boulazac Isle Manoire semblent erronées. Je vais faire un essai en changeant les coordonnées pour voir ce que ça donne. Si ça semble correct, je laisserais, sinon j'annulerais.--William Jexpire (discuter) 3 décembre 2023 à 21:03 (CET)Répondre
Comme ça ne donne rien, et qu'elle n'est toujours pas n'y est pas indiquée en gris foncé, j'ai annulé.--William Jexpire (discuter) 3 décembre 2023 à 21:38 (CET)Répondre
Sur Luxembourg (ville) y'a un problème avec wikidata il pointe vers l'élément qui correspond à lb:Hesper et non à Hesperange. Cdlt, Lyon-St-Clair [Hon hon hon] 3 décembre 2023 à 21:43 (CET)Répondre
@William Jexpire. Remarque : si dans la page Périgueux, on clique sur le bouton d'agrandissement de la carte (plein écran, alors la surface correspondant à Boulazac Isle Manoire s'affiche bien. De même, si on clique sur « modifier » puis « prévisualiser », on voit cette surface grisée sur la carte. Étrange, donc il n'y a pas forcément un problème dans Wikidata. Peut-être que le centre géographique de l'entité « Boulazac Isle Manoire » est trop loin de Périgueux pour un affichage correct avec le niveau de zoom choisi pour la carte incluse dans l'article. Gros doute. Peut-être que c'est lié à une fusion de la commune. Dans la page Boulazac Isle Manoire#Communes limitrophes, on a en dur le code
<mapframe zoom=11 latitude=45.14 longitude =0.78 height=350 width=350 align=left text="Carte de Boulazac Isle Manoire." >
{ "type": "ExternalData",  "service": "geoline",  "ids": "Q1058558, Q1000796, Q1139067, Q576696",  "properties": { "fill": "#fc3", "stroke": "#ac6600" }}
</mapframe>
d:Q1000796 correspond à Boulazac et d:Q1139067 à Saint-Laurent-sur-Manoire. Les deux localités ont fusionné dans « Boulazac Isle Manoire » (d:Q21979644) en 2016, puis en 2017 en une nouvelle commune du même nom (d:Q30041807) en accueillant le territoire de l'ancien Sainte-Marie-de-Chignac (d:Q576696). Il y a peut-être des relations mal établies ou mal actualisées sur Wikidata, altérant le bon fonctionnement du modèle (temps maximal d'exécution dépassé ?). — Ideawipik (discuter) 3 décembre 2023 à 23:24 (CET)Répondre
Bonjour Ideawipik. J'ai ajouté sur Boulazac Isle Manoire {{Carte communes limitrophes|zoom=10}} et les communes limitrophes apparaissent bien en grisé. Le problème de Périgueux ne pourrait-il pas venir du même soucis que Luxembourg (ville) ? Ce qui est bizarre en effet c'est que l'ensemble des communes limitrophes apparaissent en grisé lorsque l'on met la carte en plein écran !?--William Jexpire (discuter) 4 décembre 2023 à 11:11 (CET)Répondre

Modèle Fstats : les sous-totaux modifier

Bonjour. Le modèle Fstats permet d’afficher un tableau destiné aux statistiques de footballeurs ou de handballeurs. La ligne des sous-totaux et du total final sont de la même couleur, et la première est peut-être trop visible par rapport à son importance. Elle peut aussi induire en erreur certains lecteurs et contributeurs car le projet football a décidé qu'une saison dans un club ne méritait pas de sous total. Je souhaitais d'abord réduire sa longueur mais cela n'est pas possible pour des raisons cosmétiques. Une relecture de la couleur a donc été faite. J'aimerais votre avis sur l'accessibilité de ce test et s'il peut être améliorer, au niveau des couleurs par exemple :

Tableau Fstats d'exemple
pour montrer le sous-total modifié
Saison Club Championnat Coupe(s) nationale(s) Compétition(s)
continentale(s)
Total
Division M. B. M. B. Comp. M. B. M. B.
2019 Drapeau de la France Sans titre FC Division 2 5 0 2 0 - - - 7 0
2020 Drapeau de la France Café Foot Division 1 1 0 1 0 - - - 2 0
2021 Drapeau de la France Wikipédia FC Division 2 2 0 1 0 - - - 3 0
2022 Drapeau de la France FC Contributeur Division 1 15 6 4 2 - - - 19 8
2023 Division 1 23 9 1 0 - 5 3 29 12
Total FC Contributeur 38 15 5 2 - 5 3 48 20
Total sur la carrière 46 15 9 2 - 5 3 60 20

Cordialement. — Nebuno (discuter) 23 décembre 2023 à 00:40 (CET)Répondre

J'aime bien la proposition de Ideawipik (cf.  Modèle:Fstats total/Bac à sable). À propos, à l'occasion de ces modifs un paramètre titre a été ajouté à {{Fstats total}}, il pourrait être judicieux de le documenter. od†n ↗blah 25 décembre 2023 à 21:23 (CET)Répondre
Juste une petite retouche : la réduction de la hauteur de la ligne est une idée intéressante (et le "line-height:1" est la valeur la plus basse possible), mais je préfèrerais l'augmenter un poil pour aérer un peu. Je suggère "line-height:1.2". Pour référence, les valeurs par défaut se situent entre 1.4 (Minerva), 1.5 (Monobook, Timeless) et 1.6 (Vector). od†n ↗blah 25 décembre 2023 à 21:35 (CET)Répondre

Ouverture du projet Wikifunctions modifier

Bonjour, je rattrape encore mon retard et je viens de découvrir Wikifunctions, un projet Wikimedia lancé en 2023. Je ne sais pas si cela a déjà été annoncé chez nous, mais personnellement je suis déjà amoureux du projet, alors je partage le plaisir à d'autres développeurs.

« Wikifonctions est un projet Wikimedia permettant à chacun de créer et maintenir collaborativement une bibliothèque de fonctions de code, dans les langues naturelles du monde et dans divers langages de programmation, afin de soutenir les projets Wikimedia et au-delà.

Une « fonction » est une séquence d’instructions de programmation faisant un calcul basé sur les données que vous renseignez. Les fonctions peuvent trouver les réponses à des questions, telles que combien de jours se sont écoulés entre deux dates, ou bien quelle est la distance séparant deux villes. »

Notons qu'il sera possible à l'avenir :

  • D'appeler des fonctions Wikifunctions d'autres projets Wikimedia et d'intégrer leurs résultats dans une page ;
  • D'utiliser des données de Wikidata dans les fonctions ;
  • D'appeler des ensembles de données de l'espace de noms Commons Data ;

Autant dire qu'une petite révolution se prépare ! Lofhi (discuter) 2 janvier 2024 à 13:51 (CET)Répondre

Bug dans le modèle {{Carte métro avec OSM}} modifier

Bjr, en cliquant sur les liens (bizarrement rouges) d'une ligne, on tombe sur la page en mode édition et pas en mode lecture Reproduction de l'erreur :

Bouzinac (discuter) 6 janvier 2024 à 09:11 (CET)Répondre

Désolé : je ne parviens plus à reproduire l'erreur. Bouzinac (discuter) 6 janvier 2024 à 09:13 (CET)Répondre

Taille de la légende des infoboxes V2 et V3 modifier

Bonjour

Je sais que ce message aurait plutôt sa place sur le projet:Infobox, mais je ne le pense pas très actif.

Je viens de remarquer que si le texte des légendes des images des infoboxes V3 (géré par {{Infobox V3/Image}}) est formaté par des balises <div class="legend">, il n'en est rien pour celui des infoboxes V2 (géré par {{Infobox/Image optionnelle}} ou {{Infobox/Image optionnelle}}).

Ne faudrait-il pas harmoniser ces modèles ?

Par contre, je ne sais pas si certaines infoboxes V2 modifient la taille du texte de la légende de leur côté.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 janvier 2024 à 10:38 (CET)Répondre

Les articles Modèle:Sommaire alphabétique et Modèle:Compact ToC sont proposés à la fusion modifier

Page proposée à la fusion
Page proposée à la fusion

Bonjour,

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

Escargot (discuter) 15 janvier 2024 à 19:27 (CET)Répondre

Modèles avec des paramètres à la typo problématique modifier

Bonjour

Pour ceux que ça intéresse, j'ai fait des listes de modèles avec des paramètres dont la typographie pourrait être améliorée : Discussion Projet:Modèle/Harmonisation#Liste des paramètres problématiques.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 janvier 2024 à 11:04 (CET)Répondre

Échec lors de la sérialisation des données modifier

Tout est dit. Depuis quelques heures, toutes les pages faisant appel à {{bases}} ou {{liens}} affichent ce gros bandeau rouge Échec lors de la sérialisation des données. Quelqu’un a-t-il une idée ? − ©éréales Kille® [Speak to me]* en ce samedi 27 janvier 2024 à 16:47 (CET)Répondre

Affichage en fonction du genre modifier

Bonjour,

Suite à la demande de Gowdu59 (d · c · b) d'inclure dans le tableau du palmarès de Benoît Saint Denis la mention, indiquée dans certains sites spécialisés, de la garde des adversaires de ce combattant professionnel, et comme cette page (comme près de 400 autres articles sur des combattants de MMA) utilise le Modèle:Palmarès MMA entrée, j'ai sollicité les avis du créateur du modèle et de Trizek pour savoir s'il était possible d'ajouter cette entrée au modèle sans avoir à réaliser une trop fastidieuse maintenance.

C'est apparemment possible puisque la colonne n'apparaîtrait juste pas si l'information n'est pas renseignée, mais cela nécessiterait d'adapter l'affichage en fonction du genre du combattant (gaucher/gauchère, droitier/droitière) pour faire au mieux, si ce n'est techniquement pas trop complexe à mettre en place et gérer.

Est-ce que quelqu'un saurait me dire si c'est possible et, si c'est le cas, comment procéder?

El Comandante (discuter) 5 février 2024 à 12:14 (CET)Répondre

Notification SyntaxTerror, Manjiro5, Gdgourou et VIGNERON : je fais appel aux anciens de ce projet qui semblent encore actifs, au cas où l'un d'entre vous ait une réponse et un peu de temps. Désolé pour le dérangement si ce n'est pas le cas. El Comandante (discuter) 7 février 2024 à 08:37 (CET)Répondre
A ce que je comprends, il faut ajouter une colonne qui mentionne la garde du combattant. Ce n'est pas très compliqué, il faut ajouter la définition technique dans la colonne dans {{Palmarès MMA début}} et l'information dans chaque appel de {{Palmarès MMA entrée}}. Il faut choisir où la mettre. Je peux modifier le code sans problème mais je n'ajouterai les 400 informations Émoticône --GdGourou - Talk to °o° 7 février 2024 à 10:29 (CET)Répondre
Gdgourou (d · c · b) si j'ai bien compris, j'ajoute juste le code :
! scope=col | Garde adverse
sous
! scope=col | Adversaire
Et inutile d'ajouter les informations sur chaque adversaire de chacun des 400 combattants, si Trizek a dit juste : la colonne ne devrait apparaître que lorsque le champ est renseigné. C'est bien ça? El Comandante (discuter) 7 février 2024 à 15:41 (CET)Répondre
Comme c'est une infobox V2, le plus simple est d'ajouter un paramètre féminin (pas forcément affiché dans l'infobox) et de modifier le code du modèle là où c'est nécessaire (par exemple droiti{{#if:{{féminin|}}|ère|er}}).
Avec ce système, il suffit d'ajouter le paramètre uniquement dans les infobox des articles de femmes. S'il est rempli (avec quoi que ce soit); les textes choisis seront mis au féminin. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 7 février 2024 à 12:12 (CET)Répondre
Merci SyntaxTerror (d · c · b). Je n'ai pas bien compris, désolé : où dois-je placer le code droiti{{#if:{{féminin|}}|ère|er}} et gauch{{#if:{{féminin|}}|ère|er}}? Juste après ! scope=col | Garde adverse?
Si j'ai bien compris, une fois ce code inséré au modèle, il suffit de renseigner le genre sur la page de chaque combattante dans Wikidata, c'est bien ça?
El Comandante (discuter) 7 février 2024 à 15:41 (CET)Répondre
Bonsoir SyntaxTerror Émoticône. Comme précisé ci-dessus pae Notification Gdgourou, cette évolution ne concerne pas une infobox, mais {{Palmarès MMA début}} et {{Palmarès MMA entrée}}.
Et c'est loin d'être élémentaire !
La modification de {{Palmarès MMA début}} a bien été comprise par Notification El Comandante.
Là ou c'est complexe, c'est pour {{Palmarès MMA entrée}} qui ne contient que des paramètres non nommés. Il faudrait, si on veut bien faire les choses, insérer la garde entre les paramètres 4 et 5. Impossible sans passer sur toutes les pages avec un bot. Une façon moins élégante, et que je déconseille donc, serait de le mettre à tout à la fin dans un nouveau paramètre 14.
Peut-être que la solution la plus simple serait de ne rien faire au niveau des modèles et d'ajouter cette information entre parenthèses juste après le nom ? Éventuellement précédé d'une balise <br>. Par exemple, le paramètre 4 pourrait contenir [[Gegard Mousasi]]<br>(droitier).
--FDo64 (discuter) 7 février 2024 à 21:35 (CET)Répondre
Notification FDo64 : ah oui, au temps pour moi, j'avais zappé la deuxième partie de l'information, celle concernant {{Palmarès MMA entrée}}.
Est-il envisageable de faire appel à un dresseur de bot pour insérer la colonne vide manquante juste après le nom de l'adversaire dans les 400 pages utilisant le modèle, si ce n'est pas trop complexe à coder? Ce serait plus propre que la solution de facilité que j'avais moi aussi proposée à Gowdu59 (d · c · b) (sans le retour à la ligne).
Et pour le genre, ce n'est pas possible d'utiliser le code proposé par SyntaxTerror (d · c · b), qui ne peut fonctionner que dans une infobox V2 (ce qui n'est pas le cas ici, ne s'agissant pas d'une infobox), c'est ça? Il n'y a donc pas de possibilité de l'automatiser, si je comprends bien?
El Comandante (discuter) 7 février 2024 à 21:55 (CET)Répondre
Pour l'automatisation, c'est peut-être possible pour un pro de Wikidata (pas mon cas), à condition que la garde y soit indiquée. Dans mon exemple, il faudrait aller chercher la garde de Gegard Mousasi dans wikidata et l'afficher. Dans ce cas, il n'y a même pas besoin d'un bot. --FDo64 (discuter) 7 février 2024 à 22:04 (CET)Répondre

Bug avec WD Q modifier

Curieusement il semble que dans certains cas {{WD Q}} ressorte un résultat avec du wikicode qui n’est pas interprété ? Q5 (« être humain ») a l’air de fonctionné (en tout cas en aperçu de l’éditeur de code 2017 sur cette page avec l’outil réponse, mais tout à l’heure avec Spécial:Diff/212288677 sur le projet interwification ça marchait pas.

(test avec le modèle pour voir si ça a un rapport : ✔️ Q5 (« être humain »)) — TomT0m [bla] 9 février 2024 à 12:25 (CET)Répondre

@TomT0m : j'ai trouvé le pourquoi du bug.
En fait, Q1052157 (« San Jiao ») n'avait « pas de libellé défini » en français, j'en ai mis un, et ça à réglé le problème.
Par exemple, sur wikidata:Q1052156, il n'y a pas de libellé en français et ça fait le même bug : {{WD Q|Q1052156}} donne [[:d:Q1052156|Q1052156 (« CdZ-Gebiet »)]]
Le problème semble en fait venir du Modèle:Intitulé, et donc du Module:Interface Wikidata. Il faudrait donc plutôt demander sur le Projet:Scribunto, ou voir si quelqu'un qui passe par ici n'est pas une bille en lua comme moi. (Smiley oups)
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 9 février 2024 à 18:18 (CET)Répondre
@SyntaxTerror C’est dans mes cordes probablement, ironiquement c’est moi qui ait créé "intitulé". Pas mal de choses ont changées au fil du temps, j’ai l’impression qu’il y a un bug dans Module:Wikidata dans la gestion des langues pour "getLabel", on devrait faire un "span" avec la langue pour indiquer l’intitulé, mais ça n’explique pas l’absence de rendu du wikitexte. Ptete une catégorie de maintenance insérée pour l’utilisation d’un élément WD sans libellé mais il y a pas de trace dans le code généré. Bon je vais pousser l’investigation.
(je me souviens d’un commentaire d’édition, pas sur ce modèle ou un autre qui remplaçait un modèle qui récupérait le label par un appel au module wikidata avec le commentaire d’édition "plus simple", je l’avais gardé pour moi mais en pensant "ça se discute" :) Enfin si j’ai meilleure mémoire que Joe Biden ce qui n’est pas garanti) — TomT0m [bla] 9 février 2024 à 18:43 (CET)Répondre
@TomT0m : aussi, il faudrait enlever l'italique pour le nom de l'élément WikiData, il n'y a aucune raison que Q1052157 soit en italique. Şÿℵדαχ₮ɘɼɾ๏ʁ 9 février 2024 à 18:51 (CET)Répondre

Ordre chronologique ou antichronologique pour les modèles ? modifier

Quand un modèle traite d'articles liés à des dates, l'ordre des dates en question doit il être chronologique ou antichronologique ? Jusque-là, j'ai surtout vu l'ordre chronologique appliqué, comme pour Modèle:Palette Chronologie en aéronautique, mais quand je vois que c'est l'inverse (ordre antichronologique) pour par exemple Modèle:Palette Événements sportifs par mois, je voulais savoir une convention sur le sujet avait été actée ou non : si oui, dans quel sens, si non : peut-on prendre une décision à ce sujet ? Je n'ai vu aucune info à ce sujet sur Aide:Modèle. Eskivor (discuter) 12 février 2024 à 12:43 (CET)Répondre

Bonjour,
Je ne vois pas pourquoi l'ordre antichronologique est préféré ; j'ai plutôt l'impression que c'est une exception. Si je prends quelques palettes de sport (Modèle:Palette Coupe du monde de rugby à XV et Modèle:Palette Tournoi des Six Nations), c'est bien sûr l'ordre chronologique qui est privilégié.
Après, il y a peut-être des cas où il est pertinent de garder un ordre antichronologique : est-ce nécessaire de "légiférer" ? Daehan [p|d|d] 12 février 2024 à 13:48 (CET)Répondre
Bonjour, là comme ailleurs, une latitude éditoriale doit être laissée au développeur premier, ensuite c'est une question de consensus au coup par coup. Pas besoin de règles à ce niveau il me semble. --Sergio1006 (observateur de l'encyclopédie, responsable, libre et indépendant) 12 février 2024 à 15:53 (CET)Répondre
Pour moi, il y a clairement un usage sur frwiki de mettre en ordre chronologique, et {{Palette Événements sportifs par mois}} serait à inverser. od†n ↗blah 12 février 2024 à 18:17 (CET)Répondre
Bonjour. Entièrement d'accord avec l'avis précédent. Il suffit d'ailleurs de consulter les membres de la Catégorie:Palette Chronologique en sport pour se convaincre de cet usage. Dans un autre domaine, les filmographies des acteurs sont présentées dans l'ordre chronologique. Toutefois, cette palette risque de vite devenir très longue si on ajoute les années récentes, postérieures à 2015. D'autre part, seule une partie des mois a une page qui lui est consacrée exclusivement, en sport ; de nombreux liens de la palette conduisent vers une section mensuelle dans une page annuelle comme 2015 en sport. Peut-être qu'il vaudrait mieux se contenter du Modèle:Palette Chronologie du sport et de la navigation via les sous-catégories annuelles de Catégorie:Sport au XXIe siècle. D'autant plus que les pages contiennent déjà un tableau de navigation en tête de page, comme dans la version actuelle de « Novembre 2005 en sport ».
On pourrait aussi se questionner sur l'admissibilité de ces pages compilant des informations, pour la majorité sans aucune source (sauf parfois pour le cyclisme) et sur l'opportunité de fusions. — Ideawipik (discuter) 13 février 2024 à 15:01 (CET)Répondre

ODS et expansion d’une section avec une ancre modifier

Le modèle {{Lien ODS}} utilise les ancres générées par {{Source ODS}} pour lier vers une section de l’observatoire des sources. Problème, relatif, les sections avec une ancre sont repliées même si on lie directement dessus. Il doit y avoir moyen de les faire apparaître dans le cas ou on lie une ancre non ? — TomT0m [bla] 22 février 2024 à 14:47 (CET)Répondre

En l'état non, @TomT0m.
@Od1n, tu sais pourquoi {{Boîte déroulante}} s'appuie sur code maison et pas mw:Manual:Collapsible elements ? C'est juste une raison d'antériorité ? La WMF n'a pas pour ambition de virer jQuery, au contraire ils prévoient même aussi tôt que possible de passer à jQuery 4. On pourrait alors ajouter la détection d'une ancre ? Lofhi (discuter) 26 février 2024 à 07:23 (CET)Répondre
Il existe actuellement deux "codes maison", celui des boîtes déroulantes et celui des palettes. Je ne pourrais pas te dire les dates là, mais le système de MediaWiki doit être plus récent. Néanmoins, le système de MediaWiki ne convient pas forcément toujours (j'ai déjà eu plusieurs fois à faire des corrections par-dessus), alors que notre code local on a bien le contrôle dessus, et de toute façon il n'est pas prêt d'être enlevé, alors il n'y a pas vraiment de problème à s'en servir. Le gros problème, c'est que les classes "NavFrame" et "collapsible" (à ne pas confondre avec "mw-collapsible") ont au fil du temps été énormément utilisées "manuellement" (c'est-à-dire en ajoutant directement la classe au lieu d'utiliser un modèle), et c'est désormais un cauchemar pour la maintenance.
Concernant la migration vers jQuery 4.0, ils vont passer un bon moment pour mettre à jour les codes des wikis… Voir la section « Deprecated APIs removed » sur l'annonce de jQuery 4.0 beta. J'avais déjà fait un peu de préparation de terrain sur frwiki, et je pense qu'on pourrait maintenant s'en sortir relativement facilement, en revanche j'avais fait des recherches sur enwiki, et c'est une folie tout ce qu'il leur reste à mettre à jour.
Pour la question de départ, ce "déroulage initial" serait effectivement appréciable pour l'ergonomie, et est théoriquement réalisable (mais faudrait quand même ajouter du code). Le problème est qu'actuellement il n'y a pas de système pour savoir quand la boîte est prête (autrement dit que le javascript a été appliqué dessus) et donc que l'on peut exécuter son déroulement. C'est justement un point qui était déjà à améliorer par ailleurs, il y avait déjà à réfléchir sur des events/hooks pour savoir quand les divers modèles repliables ont été traités, car ça décale le scroll de la page, et après il faut repositionner le scroll sur l'ancre.
od†n ↗blah 27 février 2024 à 02:53 (CET)Répondre
En même temps fonctionnellement dans le cas de l'ods on peut se demander pourquoi tout est en boîte déroulante et pas en sous-section. Sur mobile les sections sont repliées sauf celle ancrée, ça marche tout seul. Peut être modifier le modèle source ods et la structure de la page à la place. — TomT0m [bla] 29 février 2024 à 08:57 (CET)Répondre
Pour clarifier (parce que je m'étais fait avoir au début), quand tu parles des sections sur mobile qui sont repliées, il s'agit des sections habituelles des articles (i.e. un titre de section suivi de paragraphes), pas les boîtes déroulantes.
Alors effectivement, j'avais voulu parcourir le contenu de cette page par curiosité, et c'est laborieux d'avoir à dérouler les sections encore et encore… Un changement de structure pourrait être envisagé, mais du coup on se retrouverait avec une page beaucoup plus longue, et on n'aurait plus la liste des sources en survolant la page.
J'avais pensé à l'implémentation d'un système permettant de créer des liens "tout dérouler / tout enrouler", mais cela risquerait d'être plus compliqué qu'il n'y parait, et même pas sûr si c'est vraiment possible.
od†n ↗blah 6 mars 2024 à 04:38 (CET)Répondre
Avec les sources en section pour avoir la liste c'est simple, il y a le sommaire. — TomT0m [bla] 6 mars 2024 à 09:38 (CET)Répondre
Sauf que du coup le sommaire serait hyper long, donc je me disais qu'on serait obligé de le limiter aux lettres. Néanmoins, après avoir testé avec le sommaire entier et sans les boîtes déroulantes, le sommaire ainsi que la page sont effectivement très longs, mais bien que le résultat soit impressionant en longueur, il est davantage fonctionnel : le sommaire sert à "survoler la liste" (rôle actuellement rempli par la succession de boîtes déroulantes, mais c'est plus compact avec le sommaire), pour consulter une source il suffit de cliquer dessus dans le sommaire (ce qui revient au même que de faire un clic pour dérouler la boîte) ; l'avantage principal c"est qu'on peut facilement parcourir l'ensemble des sources vu qu'elle ne sont plus enroulées ; et un inconvénient mineur est que si on scrolle sans utiliser le sommaire, il y a un long sommaire avant le début du contenu. Pour moi les avantages l'emportent largement sur l'inconvénient mineur (surtout que là c'est précisément une page "d'index", il est donc normal de rencontrer une longue liste d'éléments). od†n ↗blah 7 mars 2024 à 07:39 (CET)Répondre

Recommandations pour la compatibilité du mode nuit modifier

Il va y avoir du boulot, voir mw:Recommendations for night mode compatibility on Wikimedia wikis. Il y a déjà une intervention sur MediaWiki:Common.css par la WMF pour T358387. Lofhi (discuter) 26 février 2024 à 07:00 (CET)Répondre

Pourquoi appellent-ils ça night mode alors qu'ailleurs c'est m:Extension:DarkMode, m:Manual:Dark mode, m:Category:Dark mode  ? C'est confusionnant Smiley avec la bouche ouverte et les mains sur les joues. Şÿℵדαχ₮ɘɼɾ๏ʁ 26 février 2024 à 07:13 (CET)Répondre
Je serais aussi d'avis pour le nommer "dark mode". Déjà parce qu'il existe une normalisation sur les termes "light" et "dark" (refs W3C, MDN), et aussi parce que le terme "night" n'est pas forcément correct, on peut très bien afficher en dark aussi la journée…
Le renommage de "night" vers "dark" a été volontaire, voir ici. En revanche, c'est l'action d'une seule personne et je n'ai pas trouvé de discussion à ce sujet. Peut-être qu'il est encore possible de revenir là-dessus.
od†n ↗blah 27 février 2024 à 02:27 (CET)Répondre
@Od1n : il semble qu'il y a déjà une classe HTML nommée skin-night-mode-1, je me demande le pourquoi de ce choix. Şÿℵדαχ₮ɘɼɾ๏ʁ 27 février 2024 à 02:35 (CET)Répondre
J'ai créé une discussion à ce sujet là-bas : [5]. Şÿℵדαχ₮ɘɼɾ๏ʁ 27 février 2024 à 02:51 (CET)Répondre
La WMF m'a répondu hier en me redirigeant vers mw:Reading/Web/Accessibility for reading/Frequently asked questions. Je ne vois pas de raisons de ne pas suivre leur choix de parler d'un mode nuit. Il s'agit visiblement d'un choix préventif pour éviter toutes connotations. Lofhi (discuter) 27 février 2024 à 08:11 (CET)Répondre
Dans la conversation sur MediaWiki, celui qui cite cette page est aussi celui qui l'a écrite.
J'ai de gros doute sur le fait qu'il y a eu des plaintes, ou même des discussions préalables.
Je ne vois pas pourquoi se compliquer la vie quand W3C, Firefox, Google, Microsoft, et sûrement beaucoup d'autres ont déjà choisi le nom « Dark mode ».
Il vaut d'ailleurs mieux centraliser la discussion sur ce sujet là-bas. Şÿℵדαχ₮ɘɼɾ๏ʁ 27 février 2024 à 10:28 (CET)Répondre
Tu n'as pas dû remarquer qu'il y a un ticket phabricator en référence, T351307#9353379. od†n ↗blah 27 février 2024 à 14:29 (CET)Répondre
Si, mais jusqu'à preuve du contraire, c'est une décision prise en très petit comité, et je ne vois toujours pas en quoi dark peut être offensant quand on parle d'un thème.
Est-ce qu'il y a ne serait-ce qu'un exemple ou l'expression dark mode a été trouvée offensive par qui que ce soit ?
J'ai perdu mon temps à chercher, et je n'ai trouvé que des blagues, ou des sites qui parlent de racisme mais ont comme par hasard un « dark mode »... "dark mode" racist"
Le mieux que j'aie trouvé pour prouver tout ça est une monstrueuse connerie c'est ça :

« Anti-racist language [6]
We don’t use black, white, dark, or light as metaphors.
Language that puts a positive connotation on white/light and a negative or mysterious one on black/dark reinforces anti-Black and colorist stereotypes. We choose more direct language to get our point across. We only use these words as literal visual descriptors (such as dark mode), not value judgments. »

Et ce site trouve le mot « blacklist » raciste... Songeur Şÿℵדαχ₮ɘɼɾ๏ʁ 27 février 2024 à 15:46 (CET)Répondre
J'ai aussi répondu là-bas, même si je m'étais un peu emporté sur le coup. Mais franchement, on a des problèmes beaucoup, beaucoup plus préoccupants dans ce qu'est devenu le développement logiciel (bloat de fonctionnalités superflues, code hipsters, mentalité woke omniprésente), et MediaWiki ne semble pas totalement épargné quand je vois la tournure qu'il prend (même si j'ai l'impression que c'est le fait de seulement quelques personnes, qui suffisent à pourrir le tout). Là pour cette histoire, c'est juste l'histoire de termes, sans autre conséquence, alors je pourrais facilement m'en accomoder ; s'il n'y avait que ça comme problème, vraiment je serais heureux comme tout.
Sinon j'ai trouvé un autre site avec des réglages nommés "day/night", c'est dans GitHub. C'est marrant parce qu'ils ont ajouté des descriptions pour indiquer que cela correspond aux modes "light/dark" du système d'exploitation, alors qu'ils auraient simplement pu reprendre les mêmes termes. Et juste en dessous, il y a un réglage pour configurer la couleur de peau des émojis, pour être sûr que personne ne soit offensé. Et ai-je besoin de préciser qu'on peut configurer son profil pour choisir son pronom (they, she, him, custom) ?
od†n ↗blah 2 mars 2024 à 08:03 (CET)Répondre
@Od1n le problème est juste que c'est une connerie... Qu'on soit woke OK, mais là ça dépasse les bornes. Les « modes » ne sont pas des personnes, même pas des choses physiques.
Sans compter que dans leur ferveur à ne pas offenser, ils n'ont même pas pensé aux contributeurs Esquimaux (d'Alaska, parce que ceux du Yukon c'est des Inuits) qui ont des nuits de 60 jours ! émoticône Ah Ah
Quand aux difficultés techniques, ça fait des années que Fandom (ex Wikia) ou des wikis privés comme RimWorld Wiki ont des dark modes très performants. Le problème est peut-être le choix de ces développeurs, ou leur paye, parce qu'ils ne semblent pas très motivés.
OK s'ils sont bénévoles, rien ne presse vraiment, mais s'ils sont payés, pourquoi ne consultent-ils pas mieux la communauté sur leur travail, genre choisir night à la place de dark avec des motifs spécieux ? Şÿℵדαχ₮ɘɼɾ๏ʁ 2 mars 2024 à 09:42 (CET)Répondre
J'étais tout de même venu pour discuter des problématiques techniques qui nous attendaient. Je ne pense pas qu'un changement de dénomination (ce qui arrive souvent pour tout ce qui n'est pas encore présenté au public) soit si important. À nos échelles, cela paraît peut-être ridicule puisque personne ici n'utilise ces termes pour d'autres raisons que ceux qu'ils veulent dire dans leur contexte et pas ce qu'ils pourraient évoquer, mais vu que c'est comme un renommage d'un article... Que ce ne sont que des conventions... Enfin bref, les travaux sont tout de même importants. Rien que les modèles contre le vandalisme sont problématiques. J'en suis en parti responsable lors de le réécriture en 2019. Je n'ai même pas envie de me poser la question des modèles substitués en général. Lofhi (discuter) 2 mars 2024 à 09:44 (CET)Répondre
@Lofhi : y a-t-il moyen de tester ce mode sombre sur wp.fr, pour qu'on puisse voir les endroits où ça coince et faire remonter l'info ? Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 2 mars 2024 à 09:48 (CET)Répondre
C'est toujours un lourd chantier en cours, mais les progrès actuels peuvent être constatés en ajoutant un paramètre ?vectornightmode=1 en utilisant Vector 2022 et ?minervanightmode=1 pour Minerva sur la version mobile. Plus de détails dans la FAQ : mw:Reading/Web/Accessibility for reading/Frequently asked questions. Lofhi (discuter) 2 mars 2024 à 10:22 (CET)Répondre
D'après T356344, c'est imminent. Avant de demander quelque chose de plus formel au reste de la communauté, est-ce que vous seriez prêts à vous investir sur le sujet ? Je préfère prévenir que cela risque d'être dense... mais peut-être moins compliqué que le suivi réalisé lors du poussage des nouveaux outils de discussion. Lofhi (discuter) 5 mars 2024 à 16:55 (CET)Répondre
Je suis volontaire. Pour l'instant il n'est pas encore totalement clair à mes yeux si les infoboîtes et autres modèles resteront blancs ou si skin-invert sera appliqué par défaut, et donc quelle est l'ampleur des modifications nécessaires. Escargot (discuter) 5 mars 2024 à 20:59 (CET)Répondre
Je n'ai pas pris le temps de tout rattraper, mais il me semble que notre travail va se limiter (grande approximation réductrice) à désactiver le mode nuit sur des éléments ou cela ne fait pas sens et à retravailler les feuilles de styles pour les supports de thèmes différents (et de manière automatique en fonction des préférences). Cela implique un gros nettoyage et de variables CSS à réutiliser en les définissant dans Commons.css (de préférence en reprenant ceux de Codex le nouveau système de design des projets). Seule chose que je ne comprends pas pour le moment : [phab:T26070#9603127|T26070], je pensais que les images étaient exclues par défaut, ou alors c'est juste une précision. Ce premier gros chantier permettra sûrement de faciliter un deuxième gros chantier quand Codex sera plus stable : la normalisation des modèles avec des variables CSS définies dans Commons.css. Histoire de virer pas mal de dette. Lofhi (discuter) 5 mars 2024 à 21:45 (CET)Répondre
J'ai notifié à l'équipe en charge que notre projet pourrait être intéressé de tester en premier le mode nuit. On a sûrement pas mal de dette à gérer vu que nous sommes un projet conséquent, donc le plus tôt... Lofhi (discuter) 10 mars 2024 à 22:59 (CET)Répondre
D'après phab:T359644 et Wikipédia:Questions techniques/semaine 10 2024#Use of infobox class, la forme de nos infobox risque d'être un obstacle pour le moment. Mais ça n'empêche pas de déjà faire des changements en testant avec ?minervanightmode=1. Escargot (discuter) 10 mars 2024 à 23:34 (CET)Répondre
Ah ouais, c'est bien caché ce truc. C'est justement pour cette raison que je souhaite que le projet s'engage : pour avoir plus de temps pour les corrections et avoir la visibilité de la WMF sur nos problématiques.... parce que c'est un chantier qui fait peur. Lofhi (discuter) 10 mars 2024 à 23:38 (CET)Répondre
Suppléments de pensée : peut-être qu'ils vont comprendre chez la WMF que leur activation du mode nuit annoncée comme « pour bientôt » en novembre dernier est un rêve. Il y en a facilement pour des mois. Les blocages sur frwiki sont à coup sûr ridicules en comparaison d'enwiki. Lofhi (discuter) 10 mars 2024 à 23:42 (CET)Répondre
@Od1n, je pense pouvoir dire que je suis convaincu que tu vois d'un mauvais œil tout ce que le mode nuit va impliquer comme modifications sur le projet, mais tu ne penses pas cela serait le seul moment pour tenter de remettre tout à plat ? Pas dans le sens yapluka, mais le moment pour découper MediaWiki:Common.css, penser à la version mobile comme égale à la version ordinateur, avoir enfin une infoboîte, contrôler la prolifération des templatestyles, etc. ? C'est colossal, mais de toute manière c'est nous qui avons la main. Je pense que c'est le bon moment parce que le mode nuit arrive avec Codex derrière. Il y a tout un système de règles atomiques pour le CSS à réutiliser. Nécessairement, cela impose que tu sois d'accord puisqu'on a besoin de ton recul. Et peut-être de réveiller d'autres courageux un peu moins présents. Je ne pense pas qu'on devrait avoir peur de casser des choses en y travaillant. On n'a pas des obligations de moyens ou de performances. C'est du bénévolat. Lofhi (discuter) 11 mars 2024 à 00:07 (CET)Répondre

Modèle:Légende/Début et infoboxes modifier

Bonjour

Lorsque {{Légende/Début}} (et {{Légende}}/{{Légende/Fin}} qui suivent) est utilisé dans une infobox sans paramètre, le différents items sont centrés, ce qui éparpille les carrés de couleur selon la longueur des lignes (voir ici : [7]).

On peut mettre le paramètre {{Légende/Début|centre}} qui centre le tout en alignant les carrés (par ex. sur Langues pama-nyungan), mais je trouve plus lisible d'aligner tout à gauche de l'infobox.

Jusqu'à que je découvre le paramètre centre, j'utilisais un <div style="text-align:left;"> pour faire ça (par ex. sur Langues masa du Sud).

Y a-t-il moyen de faire ça avec un paramètre, et sinon, comment pourrait-on modifier le modèle ou la classe "legende-bloc" (ou "legende" dans {{Légende}} ? je suis nul en HTML/CSS) pour avoir ce résultat, si possible sans paramètre ?

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 28 février 2024 à 21:15 (CET)Répondre

Problème de date modifier

Bonjour. J'ai travaillé récemment au modèle {{Note de programme}}. J'ai réglé presque tous les soucis, mais il y en a un qui me pose problème : la date. Pour toutes les dates, le modèle l'affiche sans problème, sauf quand il s'agit d'un premier du mois. Si, dans le paramètre date, on entre 1 janvier 2024, le modèle met 1 janvier 2024 au lieu d'afficher . Je ne sais pas trop comment résoudre ce souci (minime, certes, mais présent). Merci d'avance pour l'aide que vous pourriez m'apporter. LeCharybde (discuter) 9 mars 2024 à 22:35 (CET)Répondre

J'ai résolu le problème en appliquant le modèle {{date}} à la date. Ça permet en outre d'ajouter les balises <time> pour que la date soit correctement perçue comme telle. Escargot (discuter) 9 mars 2024 à 23:24 (CET)Répondre

Centrage modifier

Bonjour,

Quelqu’un peut m’expliquer pourquoi dans l’infobox commune de France, les blasons, logos et les cartes ne sont jamais centrées sur mobile (Minerva) ?

Est-ce que c’est voulu ? Ou personne ne l’avait remarqué auparavant ?

Amicalement. Menthe Poivrée 25 mars 2024 à 20:38 (CET)Répondre

Modèles de sources de section modifier

Bonjour à tous !

Je propose d'armoniser les bandeaux relatifs aux sourçage de section entières, qui sont les suivants :

{{Sources de section}} :

{{Source de la section}} :

{{Source principale de section}} :

{{Source Allociné}} :  Sauf indication contraire ou complémentaire, les informations mentionnées dans cette section peuvent être confirmées par la base de données Allociné.

{{Source Allociné et Imdb}} :  Sauf indication contraire ou complémentaire, les informations mentionnées dans cette section peuvent être confirmées par les bases de données Allociné et IMDb.

{{Source Imdb}} : Icône signalant une information Sauf indication contraire ou complémentaire, les informations mentionnées dans cette section peuvent être confirmées par la base de données IMDb.

Je propose d'utiliser systématiquement un {{Méta bandeau de section}}, sur le modèle suivant :

Un avis ?

Ps : Comme proposé par @Ideawipik l'an dernier (ici), il faudrait également fusionner les 3 premiers modèles qui sont quasi-similaires. Mais j'ai bien peur que mes compétences ne soit pas à la hauteur d'une fusion de modèle ^^. Thomas³ #Talk 27 mars 2024 à 10:18 (CET)Répondre

Bonjour,
Je suis également d'accord pour fusionner les trois premiers. Les trois suivants n'en ont pas besoin, je pense : la présentation est exactement la même et la différence concerne l'usage ou non de certaines sources. Daehan [p|d|d] 27 mars 2024 à 10:52 (CET)Répondre

Palettes en version mobile modifier

Pour info : Affichage des palettes en version mobile sur Le Bistro.

Dans l’attente de vos commentaires. Amicalement Menthe Poivrée 27 mars 2024 à 21:32 (CET)Répondre

J'ai lancé la discussion il y a deux jours sur le Bistro car il me semblait important d'avoir des retours concernant ce sujet : la non-présence des palettes en version mobile. Comme abordé dans la discussion consultable ci-dessus, ce sujet est revenu sur la table à plusieurs reprises et pose question pour des contributeurs. Serait-il possible, sur le Wikipédia français, de pouvoir faire apparaître ces palettes en version mobile ? N'étant moi-même pas assez calé dans les aspects techniques de la chose, je m'en remets à l'expertise de modélistes et d'autres Wikipédiens à l'aise avec la programmation ou du moins pouvant laisser un avis technique. Je me permets de notifier des contributeurs fréquents de ce projet et d'autres, peut-être pas modélistes, mais que que je pense à même de donner leur avis. Comme d'habitude avec mes sollicitations, ce ne sont que des… sollicitations. Rien ne vous oblige à répondre, mais votre retour à tous est précieux, même s'il s'agit d'un avis tenant en une phrase : FDo64, Od1n, SyntaxTerror, Manjiro5, Gdgourou, VIGNERON, Escargot bleu, Epok, Ideawipik, Lofhi, Lyon-St-Clair et TomT0m. Je notifie également les utilisateurs ayant participé ou été notifiés lors de la discussion sur le Bistrot, afin de les tenir au courant de cette demande sur le projet modèle : Pyb, SenseiAC, Nouill, Zebulon84 et Berdea. Cordialement. — Nebuno (discuter) 27 mars 2024 à 22:49 (CET)Répondre
@Pyb a déjà exposé les principaux problèmes. Ici, le dernier résumé de janvier 2024 sur la situation est disponible. Lofhi (discuter) 27 mars 2024 à 23:48 (CET)Répondre
Bonsoir Lofhi. Merci pour ce lien, je viens de le consulter. Si j’ai bien compris, il reste encore trop difficile d'envisager les palettes en version mobile, malgré la tentative récente d'un utilisateur en dernier. Voici la traduction de son dernier message : « Après avoir examiné la possibilité de manipuler le CSS pour afficher l'image sur le mobile, et examiné la source de sortie sur l'ordinateur de bureau par rapport au mobile, il semble que l'image soit chargée de manière asynchrone, ce qui rend la manipulation du CSS via TemplateStyles impossible à mettre en œuvre. Ou est-ce que j'ai raté quelque chose ? J'ai bricolé avec les paramètres de visibilité et d'affichage, mais rien ne fonctionne ».
Je repose ma question déjà posée au Bistro, et à laquelle on m'a répondu : et faire un modèle sans palette comme pour le projet tennis avec ce modèle sur les joueurs et joueuses du top 10 (voir Novak Djokovic) ? Il s'agirait d'un modèle pour remplacer certaines palettes comme celle d'effectifs actuels en sport ou de gouvernements actuels. Des palettes qui méritent selon moi une visibilité même en version mobile puisqu'elles concernent l'actualité. Je pense que c'est pour cette raison que le projet tennis a créé ce modèle, pour un classement actuel. La plupart des autres palettes concernent des choses souvent figées dans le temps, mais pour des palettes liées à l'actualité, je pense que c'est à explorer. Cela permettrait au lecteur de consulter des pages liées entre elles dans le temps présent plus facilement. Je me doute que j'aurai des retours négatifs mais je préfère reposer la question ici tout de même. — Nebuno (discuter) 28 mars 2024 à 00:11 (CET)Répondre
Je suis un peu tendu rien qu'à l'idée de voir qu'on veuille allégrement contourner des dispositions argumentées de la WMF, mais je vais supposer la bonne foi. Je t'invite à lire l'intégralité du ticket si tu le peux et à revenir avec tes questions si tu n'as pas compris certains points. Je tenterai de vulgariser les arguments techniques peu compréhensibles. Peut-être que tu pourras alors comprendre le fond des problématique soulevées. Sans divulgâcher : une grosse partie du problème vient de la communauté, même si la WMF partage une partie de la responsabilité sur certains sujets techniques (en l'occurrence ici pas tellement). Les corrections sont toutes trouvées, c'est la communauté le problème. Son poids indéfectible et parfois par dessus la raison. Une énième problématique de l'industrie du web qui dépasse les simples préférences personnelles ou communautaires. Lofhi (discuter) 28 mars 2024 à 00:22 (CET)Répondre
J'ai commencé à lire à la date retenue dans votre lien, pas en intégralité. Je vais prendre le temps de le lire en entier et de le diriger car je ne suis pas familier avec ce domaine technique. Je n'hésiterai pas à vous questionner en cas de besoin. Merci pour votre pédagogie. Je ne fais que lancer un sujet, je ne souhaite rien révolutionner, et quand bien même, je ne le ferais pas sans l'avis et la validation d'utilisateurs plus compétents sur le sujet que moi. D'où cette discussion. — Nebuno (discuter) 28 mars 2024 à 00:30 (CET)Répondre
Je viens de me rendre compte que le Wikipédia allemand a recours au NaviBlock (Thomas Müller). Il s'agit de mon avis, mais est-ce envisageable, en tout cas dans le cadre d'un projet Wikipédia comme le football ou le rugby, comme l'a fait le projet tennis ? — Nebuno (discuter) 28 mars 2024 à 00:26 (CET)Répondre
Wikipédia en allemand a fait le choix de ne pas utiliser une des classes normalisées et proposées par la WMF. C'est une forme de contournement des recommandations, puisque que la WMF désactive le rendu des palettes que MediaWiki reconnaît... grâce aux classes. Donc cela s'affiche chez eux.
Des questions dès lors : est-ce que cela s'affiche correctement sur toutes les résolutions d'écran ? Est-ce que cet affichage fait sens ? Est-ce que les articles dans régions du monde qui n'ont pas accès haut débit à Internet et où la taille brute de ces boîtes n'est pas négligeable chargent rapidement ? Est-ce que les articles complexes s'affichent de manière performante sur des appareils peu puissants ? La réponse tend au non, d'où l'absence de ces boîtes sur version mobile web (sur application mobile j'ai oublié). Lofhi (discuter) 28 mars 2024 à 00:43 (CET)Répondre
Je vois, c'est en effet complexe et il faut envisager les choses dans leur globalité. Mais ma réflexion porte sur un modèle d'un effectif actuel par exemple, et non l'ensemble des palettes comme sur le Wikipédia allemand. Cela ne devrait pas poser trop de problème de charge, mais je comprends qu'il faille prendre tous les problèmes possibles en compte. — Nebuno (discuter) 28 mars 2024 à 00:59 (CET)Répondre
Comme j'ai dit, la communauté peut contourner quasi tout ce qu'elle veut parce qu'elle affiche littéralement ce qu'elle veut dans ses articles. La solution n'a jamais été de savoir si on pouvait faire quelque chose. Le problème a toujours été de faire comprendre à la communauté qu'il y a des bonnes façons de faire et des choses à ne pas faire. Que sa volonté ne justifie pas tout.
Ici, une bonne façon de faire est de rendre ces boîtes réactives et de réduire drastiquement leur taille nette en octets. Là, on pourrait peut-être argumenter auprès de la WMF notre choix de contourner leurs décisions parce qu'un gros travail aura été réalisé pour les rendre tolérables sur la version mobile. Et encore, sur la long cela pose problème de faire sa tambouille dans son coin. Lofhi (discuter) 28 mars 2024 à 01:24 (CET)Répondre
Conflit d’édition Notification Nebuno : Bien que je regrette le problème de non-affichage des palettes sur mobile, je reste défavorable au tour de passe-passe proposé. Je ne suis par ailleurs pas convaincu de la pertinence de distinguer les palettes qui évoluent avec l'actualité (qui d'ailleurs n'existent pas que dans le domaine du sport : j'en ai connais aussi au moins dans le domaine politique) des palettes "fixes".
Notification Lofhi : Venir dire que « une grosse partie du problème vient de la communauté » ne donne aucune explication concrète et ne peut qu'ajouter de l'huile sur le feu. Ce genre de remarque me semble particulièrement peu constructive.
(À tout le monde :) Je réitère une idée que j'avais évoquée sur le Bistro : la possibilité que, sur la version mobile, il y ait ne serait-ce qu'un lien vers la palette à la place de la palette elle-même. En effet, la page des modèles, y compris des palettes, semble s'afficher correctement sur mobile (tester avec par exemple [8] ; en tout cas en affichant cette page fr.m... sur mon ordi, ça l'affiche, tandis que sans surprise la palette ne s'affiche pas en bas des articles où elle se trouve). Un tel lien, essentiellement analogue à ceux des articles connexes, ne devrait pas avoir les problèmes de résolution et je ne sais quoi d'autre invoqués pour ne pas afficher les palettes. En attendant peut-être un miracle un jour, ce serait toujours mieux que rien. SenseiAC (discuter) 28 mars 2024 à 00:59 (CET)Répondre
Bonjour SenseiAC. J'ai parlé du domaine du sport mais aussi de la politique pour cette proposition de modèle, relisez-moi. Je ne souhaite pas limiter cette proposition à ces domaines d'ailleurs mais je parle surtout pour le sportif, car c'est le domaine principal de mes contributions. À mon sens, c'est pertinent pour des projets sportifs mais pas que. — Nebuno (discuter) 28 mars 2024 à 01:06 (CET)Répondre
Edit : non, en version mobile et sur un mobile, la palette ne s'affiche pas. À l'ouverture de votre lien, le tableau n'apparaît pas. — Nebuno (discuter) 28 mars 2024 à 01:13 (CET)Répondre
La bienveillance, ce n'est pas en arriver à mentir pour faire plaisir. Ce n'est pas parce qu'une remarque paraît peu constructive qu'elle l'est. Ainsi, il est bon que de rappeler qu'afficher un lien vers la palette, bah... ça ne règle en rien le problème d'accessibilité de ces boîtes. Cela revient encore à un contournement, à une fausse solution, à un bandage sur une plaie béante. Ces boîtes sont lourdes à charger (déjà dit plus haut) pour ceux qui n'ont pas un accès haut débit à Internet et seront toujours illisibles sur petits écrans (déjà dit plus haut). Encore un truc que la communauté ne veut pas comprendre au fil des années ; même quand c'est expliqué deux fois dans le meme sujet. Lofhi (discuter) 28 mars 2024 à 01:08 (CET)Répondre
« Cela semble s'afficher correctement sur mobile (tester avec par exemple [8] ; en tout cas en affichant cette page fr.m ». C'est faux, ou alors comme d'habitude, la communauté a affiché la version mobile avec la résolution d'un écran d'ordinateur... On tourne en rond. Sur mobile, la palette est invisibilisée à partir d'une résolution jugée trop petite parce que la palette devient difforme. Et encore une fois, l'affichage ne supprime pas la problématique de la lourdeur de ces boîtes. Lofhi (discuter) 28 mars 2024 à 01:11 (CET)Répondre
Notification Lofhi : là niveau mauvaise foi tu as fait fort en tronquant la citation de mon commentaire juste avant là où je dis explicitement "sur mon ordi"... SenseiAC (discuter) 28 mars 2024 à 01:20 (CET)Répondre
Il n'y a pas de mauvaise foi. J'ai littéralement le code source de MediaWiki ouvert sous les yeux. Les palettes ne peuvent pas s'afficher dans l'espace de nom principal. Elles s'affichent à partir d'une certaine résolution sur mobile dans les autres espaces de nom. Une fois une taille critique atteinte où les palettes se difforment, elles sont invisibilisées.
Donc on en revient aux mêmes problèmes : les palettes ne sont pas affichées correctement sur petit écran et le jour où elles s'afficheront correctement, cela ne résout en rien le problème de poids en octets dans les régions où un accès Internet haut-débit est un luxe.
Sauf que je ne suis pas sûr que les arguments techniques intéressent grand monde, car tout ça a été expliqué, réexpliqué puis récité. Rien que le ticket partagé par @Pyb puis repartagé par moi, le tout avec les arguments tout à fait valables de @Trizek sur l'autre sujet font référence à 90 % des éléments que je développe. Lofhi (discuter) 28 mars 2024 à 01:30 (CET)Répondre
Ne le prend pas personnellement @SenseiAC, hein. C'est juste que toutes ces explications sont données et redonnées... C'est épuisant la pédagogie. Ce n'est pas expliquer qui est problématique. Ce qui est frustrant, c'est d'avoir l'impression de parler dans le vide même quand on tente de vulgariser le mastodonte qu'est MediaWiki. Je ne raconte pas tout cela pour faire chier les gens. Les points de vue communautaires pourraient être défendus au près de la WMF, mais ici, elle a globalement raison. Lofhi (discuter) 28 mars 2024 à 01:41 (CET)Répondre
Référence technique du comportement décrit : https://gerrit.wikimedia.org/g/mediawiki/extensions/MobileFrontend/+/53d7f6d9943fa5961f28ed69f1ae2a2f3f5b74bd/includes/MobileFormatter.php#69. Lofhi (discuter) 28 mars 2024 à 01:44 (CET)Répondre
Les palettes réactives sont une bonne idée pour résoudre le problème des palettes « lourdes ». Menthe Poivrée 28 mars 2024 à 02:00 (CET)Répondre
Je ne sais pas franchement... Certains articles sont déjà gros à cause du sujet traité, alors quand il y a trois palettes de 10 kilooctets chacune qui sont rajoutées en fin de page... Sans parler que c'est la taille brute avant expansion (appelle en cascade des modèles utilisés dans les modèles, ...). Pire si c'est par exemple une palette de pays avec drapeaux (autant de requêtes parallèles [si pas successives une par une] pour chaque image à charger depuis Commons). C'est vraiment des problématiques complexes. Et rien que la version d'HTTP supportée de l'appareil peut tout changer (multiplexage versus pipelining HTTP versus aucun des deux). Et le réseau, ce n'est pas vraiment ma plus grande compétence. Lofhi (discuter) 28 mars 2024 à 02:18 (CET)Répondre
Je suis d’accord, mais ça ne me paraît pas un facteur dirimant. Heureusement, tous nos articles ne font pas +100 000 octets.
Par contre, je te rejoins sur les images dans les palettes, c’est une pratique qu’il faudra proscrire si on adapte les palettes. Menthe Poivrée 28 mars 2024 à 02:41 (CET)Répondre
Dans un contexte d'un accès lent à Internet, si. Le problème des images dans les palettes est secondaire et n'invalide pas ma première et principale remarque : les palettes sont trop lourdes pour les informations qu'elles véhiculent et vis-à-vis de leur taux d'utilisation et de consultation. Lofhi (discuter) 28 mars 2024 à 03:02 (CET)Répondre
Bien sûr, ça ne l’invalide pas. Mais la réalité est qu’il s’agit d’un sujet récurrent chez nous, preuve d’un besoin. C’est d’ailleurs un sujet récurrent au niveau international, à tel point qu’outre-Rhin, nos voisins cherchent des solutions pour régler ce problème. Je ne dis pas que leur solution est satisfaisante, mais dire qu’elles sont trop lourdes ou pas assez consultés ne l’est pas non plus. Menthe Poivrée 28 mars 2024 à 03:49 (CET)Répondre
Non, la solution allemande n'est pas une solution qui répond à l'ensemble des problèmes que j'ai répété quatre fois, c'est-à-dire aussi la réduction drastique de la taille des palettes. Les « besoins » des uns ne valent pas plus que l'accessibilité de Wikipédia dans des régions défavorisées. J'ai assez détaillé, quatre fois, les arguments. Vous en faites maintenant ce que vous voulez... La communauté qui ignore les considérations techniques, c'est symptomatique. En voici encore l'exemple. Lofhi (discuter) 28 mars 2024 à 04:00 (CET)Répondre
En effet, un sondage peut-être nécessaire. Menthe Poivrée 28 mars 2024 à 04:19 (CET)Répondre
Faire un sondage sur un truc pas faisable ? Mieux vaut attendre la prochaine session des vœux communautaires et y aller en masse réclamer une solution technique. Trizek bla 28 mars 2024 à 09:47 (CET)Répondre
L’un n’empêche pas l’autre. Menthe Poivrée 28 mars 2024 à 12:50 (CET)Répondre
Revenir à la page « Modèle ».