Wikipédia:Demande d'intervention sur un message système

(Redirigé depuis Wikipédia:DIMS)

Cette page a pour but de demander une intervention aux administrateurs d'interface sur un message système (dans l'espace MediaWiki) de l'interface de Wikipédia.

Pour effectuer une requête aux administrateurs, veuillez employer les liens dans l’encadré ci-contre. Pour effectuer votre demande sur un message système, cliquez sur le lien ci-dessous et rédigez votre demande. Elle se retrouvera tout en bas de cette page.

Notes :

  • N'hésitez pas à consulter le projet Scripts et gadgets si vous avez besoin d'aide pour votre requête ;
  • si vous ne connaissez pas le nom du message système, vous pouvez le trouver en suivant les instructions de la page Aide:Message système (explication de l'utilisation de &uselang=qqx), ou en recherchant dans Spécial:Messages système. À défaut écrivez tout de même votre demande de la façon la plus précise possible ;
  • si la modification proposée est assez générale pour s'appliquer aux autres wikis fonctionnant sous MediaWiki (c'est-à-dire non spécifique à Wikipédia ni à Wikimedia), il est préférable de modifier le message correspondant sur translatewiki.net (demander les droits de traducteur, ou demander à un utilisateur les possédant) ; la modification se répercutera ici dans les jours/semaines qui suivront ;
  • penser à l'accessibilité.

Demander une intervention sur un message système

Requêtes traitéesModifier

  • Les requêtes classées ci-dessous ont été traitées par un administrateur.
  • Les requêtes traitées depuis plus de 7 jours sont archivées.

Requêtes refusées ou sans suiteModifier

  • Les requêtes classées ci-dessous ont été refusées ou n'ont pas eu de suite.
  • Les requêtes traitées depuis plus de 15 jours sont archivées.

Requêtes en cours d'examenModifier

Requêtes à traiterModifier

  • Pour effectuer une nouvelle requête, ajouter une nouvelle section ci-dessous. Un administrateur se chargera d'y répondre.
  • Les requêtes traitées ou refusées sont déplacées dans la section correspondante puis gardées pendant une semaine.

MediaWiki:Imagemap-Highlight.js et MediaWiki:Gadget-imgToggle.js – chargement global sur wikifrModifier

Requête à traiter


Pages où apparaît ce message : Modèle:Image interactive

Changement proposé : Après avoir importé localement les deux scripts pour faire fonctionner le modèle Image interactive, j'obtiens une différence de fonctionnement avec le modèle source russe. J'ai prévenu le développeur qui est l'auteur du modèle et qui a travaillé sur les scripts, mais il ne peut voir le résultat tant que ces scripts ne sont pas globalement accessibles. Donc serait-il possible de les rendre accessibles sur wikifr depuis n'importe quel poste pour analyse?

Liens :

  Akhmadjan :
Bonjour,
Je ne sais pas si j'aurai vraiment le temps de m'impliquer dans cette requête, mais pour avoir une chance que ça avance, voici quelques conseils :
  1. (passage réécrit, maintenant que j'ai trouvé toutes vos sous-pages) Les scripts sont chargés dans Utilisateur:Akhmadjan/vector.js donc ça devrait marcher pour vous. Si ce n'est pas le cas, le développeur initial devrait pouvoir tester lui-même en les important depuis son propre vector.js (ou common.js). En fait, ce serait bien que tous les utilisateurs qui le veulent puissent d'abord tester le script par cette méthode. Ça marche pour moi... au bug près, d'où l'objet de cette requête. Mais vous avez raison : si Igor importe ses scripts depuis son compte utilisateur wikifr il aura aussi l'anomalie.
  2. Indiquez quelques exemples d'articles où le modèle pourrait être utilisé, pour qu'on puisse estimer dans combien d'articles le modèle serait utile. La finalité du modèle Image interactive est son utilisation par le modèle Plan interactif du métro de Moscou. Ce dernier sera lui-même inséré dans les modèles Infobox Ligne de transport en commun (testé ici) et Infobox Station de métro (testé ). Ça impacte 15 pages pour les 15 lignes du métro moscovite et environ 204 pages pour les stations (sur a priori 3326 pages qui font appel à l'infobox Station de métro). Le modèle peut aussi être mis directement dans les pages Métro de Moscou et Liste des stations du métro de Moscou.
  3. Postez un lien vers cette demande sur Discussion Projet:Scripts et gadgets.
Les modèles qui nécessitent des scripts pour fonctionner ont un coût de maintenance plus élevé qu'un simple modèle, donc on ne les active pas à la légère. Il faudrait obtenir un consensus sur l'utilité du modèle et s'assurer que le code est fonctionnel et stable avant d'envisager de le copier dans l'espace MediaWiki. Si maintenance il y a, je pense que ce sera plus sur le modèle Plan interactif du métro de Moscou, ses sous-pages et la carte elle-même, que sur les scripts.
Si vous avez des difficultés techniques pour le réaliser le point [1], vous pouvez demander de l'aide directement sur Discussion Projet:Scripts et gadgets.
Orlodrim (discuter) 4 mars 2020 à 21:05 (CET)
  Orlodrim :
Bonsoir, les réponses sont en bleu ci-dessus. Akhmadjan (discuter) 5 mars 2020 à 21:56 (CET)
J'ai testé les scripts sur la page Modèle:Plan interactif du métro de Moscou et il est vrai que le résultat est vraiment chouette. Cependant, cela m'embête de rajouter du code au moins dans le Common.js, éventuellement aussi dans le Gadgets-definition, deux fichiers qui sont à alourdir le moins possible, cela pour des scripts qui actuellement serviraient uniquement pour cette carte. Et cela irait aussi quand même ajouter des efforts de maintenance au niveau des scripts.
Je pense que le meilleur compromis serait de ne pas ajouter ces scripts pour tout le monde, mais de permettre aux utilisateurs désirant cette carte interactive de charger les scripts dans leur common.js.
J'ai élaboré sur 187178240 un code de chargement optimal, mais ce code est un peu long. Un meilleur compromis peut être 187178209, qui est moins complexe et fonctionne aussi bien, il est seulement marginalement moins performant en cas de rechargement ajax du contenu. Il faudrait simplement éviter la version 167368849, dont le code est très simple, mais qui a pour inconvénient de charger les scripts sur toutes les pages.
od†n ↗blah 27 octobre 2021 à 06:58 (CEST)
Tu m'excuseras je suis revenu sur tes modifications car ça ne fonctionnait plus du tout chez moi : j'ai réinitialisé vector.js (chargement local) ainsi que les scripts Imagemap-Highlight.js et ImgToggle.js. J'en ai profité pour résoudre le problème qui m'embêtait, assez simple, je n'avais pas chargé le fichier .css qui définissait la classe imgtoggleboxTitle à display: none (vector.css). Le script d'Igor était parfait donc, il n'y avait rien à débugger. Si le chargement des scripts est trop compliqué tant pis, les charger uniquement pour soi, si on ne peut pas y accéder depuis n'importe quelle page d'une station du métro de Moscou, ne présente par contre pas un grand intérêt... Merci pour ton aide en tout cas! La carte russe a déjà évolué depuis tout ce temps, la ligne 15 a rejoint la ligne 3 en empruntant le tracé de la ligne 11. 😂 Autrement qu'est-ce qui distinguait les classes img_toggle {overflow: auto; overflow-y: hidden; max-width: ($('#bodyContent').width() - 38)px;} ? --Akhmadjan (discuter) 31 octobre 2021 à 01:51 (CEST)
J'avais pourtant bien testé, et chez moi ça fonctionnait correctement. Comme je l'avais indiqué, le problème est que le nom de classe img_toggle est déjà utilisé sur le wiki fr (plus exactement, depuis que j'ai corrigé le nom mal écrit img_toogle en img_toggle). Du coup, cela cause au moins ces problèmes :
Du coup, si tu pouvais rétablir le changement vers imgtoggle_bis, ça serait vraiment bien. (à propos, la différence d'underscore « img_toggle / imgtoggle » est volontaire, ça fait que les noms ne se chevauchent pas)
Autrement, pas compris la dernière phrase de ton message à propos du CSS. (ce que je peux dire par contre, c'est que le 'max-width:' + $('#bodyContent').width() - 38) + 'px' pose problème si on redimensionne la fenêtre du navigateur, parce que la valeur est fixe)
od†n ↗blah 31 octobre 2021 à 02:53 (CEST)
Ah jai vu ton travail de maintenance, correction syntaxique. À l'origine ta recherche sur img_toggle ne retournait que ImgToggle.js et Questions techniques/semaine 8 2020. Bonne correction puisqu'elle m'a orienté sur la solution à mon problème, le chargement de Gadget-imgToggle.css. Le renommage de la classe présente-t-il un intérêt si les scripts ne sont pas utilisés? Connecté, div.img_toggle que j'ai chargé localement donne le même résultat que déconnecté div.img_toggle non défini dans Common.css... 🤔 (lorsque j'inspecte Rennes ou Vystavotchnaïa) --Akhmadjan (discuter) 31 octobre 2021 à 11:32 (CET)
« La carte russe a déjà évolué depuis tout ce temps, la ligne 15 a rejoint la ligne 3 en empruntant le tracé de la ligne 11. 😂 » : je m'en étais douté de ce coup-là… Les lignes évoluent immanquablement avec le temps, nécessitant un effort de mise à jour assez conséquent au niveau de la carte dynamique. Il faut vraiment être passionné. Généralement, ce genre de mise à jour est pas mal délaissé.
Je propose de rétablir mes changements vers « imgtoggle_bis », pour les raisons de maintenance évoquées plus haut, et de clore cette requête qui est quand même là depuis plus d'un an et demi.
od†n ↗blah 16 novembre 2021 à 12:48 (CET)
Vous êtes grand clerc! En même temps c'était déjà indiqué il y a plus d'un an et demi, le 5 mars 2020 : «Si maintenance il y a, je pense que ce sera plus sur le modèle Plan interactif du métro de Moscou, ses sous-pages et la carte elle-même, que sur les scripts Le principe c'est bien d'avoir un script qui ne bouge pas, ou peu, la carte devant elle nécessairement évoluer vu que des lignes sont en construction (leur tracé est pointillé).
Je vais renommer la classe « imgtoggle » (le bis suppose qu'imgtoggle existe déjà, ce qui n'est pas le cas, à moins que vous ayiez prévu de renommer une variable ainsi dans le futur?!?). La recherche de maintenance ne retourne que le sujet qui nous intéresse. imgToggle aurait été pas mal aussi, qui retourne davantage de résultats. --Akhmadjan (discuter) 17 novembre 2021 à 10:07 (CET)
La modification est faite. --Akhmadjan (discuter) 19 novembre 2021 à 17:35 (CET)

MediaWiki:Gadget-StructuredCategories.js – Création d'un outil qui génère une description structurée des catégories Wikipédia.Modifier

Requête à traiter


Pages où apparaît ce message : Catégories Wikipédia

Changement proposé : Je veux créer un outil Gadget dans l'espace MediaWiki et l'ajouter aux préférences. Le code source de l'outil est disponible sur meta:MediaWiki:Gadget-StructuredCategories.js. L'outil permet d'insérer un lien qui génère la liste des déclarations Wikidata les plus utilisées pour définir les membres directs d'une catégorie. Cet outil a émergé suite à une discussion avec la communauté sur Discussion modèle:Catégories structurées.

De point de vue technique, je demande d'insérer:

  • mw.loader.load('//meta.wikimedia.org/w/index.php?title=MediaWiki:Gadget-StructuredCategories.js&action=raw&ctype=text/javascript'); dans MediaWiki:Gadget-StructuredCategories.js.
  • StructuredCategories : fournir une description structurée d'une catégorie en se basant sur des déclarations Wikidata impliquant ses membres directs. dans MediaWiki:Gadget-StructuredCategories.
  • Ajouter l'outil en tant qu'un outil gadget.

Une description de l'outil est disponible sur d:Wikidata:Structured Categories. --Csisc (discuter) 20 avril 2021 à 21:08 (CEST)

  Csisc :
Bonjour,
Sur Wikipédia en français, une boîte avec des liens vers divers outils est affichée sur chaque catégorie via MediaWiki:Category-subcat-count. Il me semblerait logique de mettre le lien là avec les autres, d'autant que je n'aime pas trop allonger la liste des gadgets.
Mais j'hésite car le lien généré par le gadget est très long. En fait, il contient toute la requête. Si j'ajoute ce lien dans la boîte comme ceci, les mises à jour du gadget devront être manuellement répercutées ici.
Du coup, je me demande :
  • Est-ce qu'il y aurait une possibilité d'utiliser une sorte de requête préenregistrée avec cet outil (quelque chose du genre query.wikidata.org/<page pour traiter les requêtes préenregistrées>#prepopulated_request_id=123456&field_wiki=fr.wikipedia.org&field_category=Naissance_en_janvier_1950) ?
  • Sinon, est-ce qu'il y a des chances qu'il y ait des modifications du gadget à l'avenir, ou est-ce que ça peut être considéré comme stable ?
Orlodrim (discuter) 22 juin 2021 à 23:57 (CEST)

[[MediaWiki: ]] – Gadget ArchiveLinks && ExtendedCacheModifier

Requête à traiter


Ensemble des articles : Tous les articles de wikipedia francophone.

Changement proposé : Concerne des demandes sur le gadget ArchiveLinks et ExtendedCache gestion des liens archives :

  • Retirer l'archivage des liens vers mediawiki.org

https://fr.wikipedia.org/wiki/Discussion_utilisateur:Patafisik_(WMF)#q:Wikiquote:Le_Salon/avril_2021 suite à cette demande formulée par @Malik2Mars MediaWiki:Gadget-ArchiveLinks.js une règle est à implémenter à la ligne 20.

'ArchiveLinks [ResourceLoader|default|dependencies=user,user.options] | ArchiveLinks.js' remplacer par 'ArchiveLinks [ResourceLoader|targets=desktop,mobile|default|dependencies=user,user.options] | ArchiveLinks.js' dans MediaWiki:Gadgets-definition

'* ExtendedCache [ResourceLoader|dependencies=ext.gadget.ArchiveLinks] | ExtendedArchiveLinks.js' remplacer par '* ExtendedCache [ResourceLoader|targets=desktop,mobile|dependencies=ext.gadget.ArchiveLinks] | ExtendedArchiveLinks.js' dans MediaWiki:Gadgets-definition Pmartin (discuter) 23 juillet 2021 à 00:55 (CEST)

Pour le premier point : je viens d'effectuer ceci pour traiter le problème. C'est un peu dommage d'avoir à alourdir (légèrement) le script pour des cas particuliers qui devraient être rarissimes, mais bon, quand il faut… od†n ↗blah 24 juillet 2021 à 19:15 (CEST)
Concernant l'activation sur mobile, en fait même les gadgets marqués en targets=mobile ne sont actuellement pas chargés sur mobile. Je ne sais pas pourquoi ça a été conçu comme cela… Refs gerrit:60954, mw:Topic:W7xf7fg0ggnn4qo8. od†n ↗blah 26 juillet 2021 à 21:57 (CEST)
Contrairement à ce que j'avais cru au départ, le target=mobile serait en fait bien fonctionnel. En revanche, je ne suis pas vraiment chaud pour activer le script sur mobile :
  • L'impact performances de ce script n'est pas négligeable, et les développeurs de MediaWiki insistent beaucoup au sujet des performances sur mobile ; il serait préférable de favoriser les performances quitte à ne pas disposer de fonctionnalités non essentielles.
  • Cette problématique existe depuis la création de ce gadget, maintenant il y a probablement du ménage à faire dans la liste étendue des archiveurs. Cela reste que du paramétrage, il sera facile de faire un rollback en cas de remontée communautaire. Pmartin (discuter) 3 août 2021 à 20:09 (CEST)
  • La configuration des préférences est très limitée sur mobile, pour désactiver le script ce n'est pas du tout évident : il faut aller sur la version desktop, en étant connecté avec son compte, pour pouvoir aller ensuite désactiver le gadget…
  • De mon point de vue la gêne occasionnée représente un pourcentage minoritaire sur l'utilisation de wikipedia, les comptes actifs sont essentiellement ceux des contributeurs et majoritairement par desktop, et quand bien même il reste toujours la solution de Version pour ordinateur.Pmartin (discuter) 3 août 2021 à 20:09 (CEST)
od†n ↗blah 30 juillet 2021 à 14:50 (CEST)
Je me permets de relancer le sujet sur les deux derniers points Pmartin (discuter) 8 septembre 2021 à 10:42 (CEST)
Je rajoute une tâche à la todo , les archives Wikiwix sont maintenant compatible via https, pour éviter une redirection consommatrice ça serait bien de remplacer dans ces gadget le http par https. 5 novembre 2021 à 11:16 (CET)
Fait pour le https. od†n ↗blah 8 novembre 2021 à 02:01 (CET)
Merci pour le https, pour les deux autres points "Un administrateur utilise ses outils au nom de la communauté, pour exécuter les décisions que la communauté a prises." il y a eu décision de la communauté que faut - il faire pour son application. Je pense que la source du problème date de cette époque entre @Od1n et moi Discussion_MediaWiki:Gadget-ArchiveLinks.js mais que depuis le temps cette page s'est construite Wikipédia:Contributions_rémunérées qui va bien au delà du poste que je proposais. Il y a t'il un autre admin neutre pour réaliser ces prises de décision Wikipédia:Sondage/Affichage_du_lien_archive_Wikiwix Wikipédia:Prise_de_décision/Système_de_cache sur la version mobile ? Pmartin (discuter) 9 novembre 2021 à 14:33 (CET)
Depuis le temps, j'ai un peu revu ma position sur l'outil Wikiwix. J'ai le sentiment qu'il fonctionne mieux qu'auparavant, et à plusieurs reprises j'ai pu constater qu'une grande quantité de pages est archivée, et qu'il permettait effectivement de récupérer des informations n'étant plus disponibles autrement. Donc je me dis pourquoi pas, et je ne suis plus opposé à son activation par défaut (sous réserves qu'il soit possible de le désactiver, et que l'impact sur les performances soit limité).
Néanmoins, le ratio utilité/lourdeur me parait plus défavorable sur mobile, comme j'ai détaillé un peu plus haut. Je suis donc pour ma part défavorable à l'activation sur mobile, et je ne suis pas certain que la PDD de 2008 soit automatiquement applicable (et ça me gêne qu'elle soit à chaque fois ressortie comme un joker « regardez il y a une PDD il faut l'appliquer »), elle remonte à une époque où on n'avait même pas le web sur nos mobiles…
Enfin, un administrateur a effectivement pour rôle d'appliquer les choix de la communauté, mais il est également libre de s'abstenir en cas de désaccord. Il n'y a pas de souci.
od†n ↗blah 11 novembre 2021 à 23:44 (CET)
Depuis le temps, j'ai également renouvelé le matériel et réécris le code afin de rendre l'archivage de wikiwix plus stable, j'apprécie le fait que les efforts soient visibles.
Je justifie cette demande suite à ce sondage qui date de 2016 ( pas que de 2008 ) pour lequel le ratio utilité/lourdeur avait été évalué par la communauté Wikipédia:Sondage/Affichage_du_lien_archive_Wikiwix à une époque où la version mobile existait déjà et c'était lors de la mise en application de ce sondage que nous nous sommes "frictionnés" https://fr.wikipedia.org/w/index.php?title=Discussion_MediaWiki:Gadget-ArchiveLinks.js&diff=132347966&oldid=132341265 et qui n'a pas été mise en application sur mobile.
Je ne remets ni en cause le travail bénévole, ni le point de vue personnel de @Od1n que je respecte et salue, mais dans le cas présent il s'agit de la mise en place de décision prise par la communauté, l'avis personnel est à exprimer lors des PDDs ou des sondages comme tout membre de la communauté je suppose.Pmartin (discuter) 12 novembre 2021 à 12:27 (CET)
Je pense que le mieux serait que tu lances un sondage sur cette question de l'activation sur mobile. Ce changement justifie un sondage de toute façon, et cela permettra d'obtenir des avis supplémentaires (enfin… d'autres avis tout court quoi…), et de divers horizons. Comme cela nous devrions être fixés. od†n ↗blah 16 novembre 2021 à 12:37 (CET)

┌──────────────────┘
Cela n'a pas plus que çà déchaîner les foules mais 8 votes pour quand mêmeWikipédia:Sondage/Gadget-ArchiveLinks-Mobile.Mais on était dans un sondage sur les Boomer des archives Wikipédia:Le_Bistro/15_décembre_2021#Sondage_en_cours à espérer ne pas avoir un nouveau format plus tard. On peut se caler une date début Janvier j'aimerai bien surveiller les métriques du serveur.Pmartin (discuter) 30 décembre 2021 à 23:08 (CET)

@Od1nLa procédure de la clôture du sondage a été finalisée.Pmartin (discuter) 7 janvier 2022 à 09:54 (CET)
Je n'avais pas vu passer ce sondage, mais vu les résultats je n'ai pas d'objection pour l'activation sur mobile. Tu aurais une préférence pour la date/heure d'activation, ou on peut activer maintenant ? od†n ↗blah 10 janvier 2022 à 06:33 (CET)
@Od1nC'est bon pour moi je n'ai pas plus que çà de préférence je suis disponible en cas de soucis, compte tenu de la situation sanitaire.Pmartin (discuter) 10 janvier 2022 à 09:17 (CET)
  Activé : 189749119 ainsi que 189749331. od†n ↗blah 10 janvier 2022 à 10:24 (CET)
@Od1n Merci pour avoir activé le gadget, en testant je me suis rendu compte qu'il était activé uniquement pour les utilisateurs authentifiés, contrairement à la version PC. Soit il y a un paramètre qui manque lors de l'appel au gadget soit c'est un problème fonctionnel, tu as une piste ?
Chez moi, j'ai bien les liens archive quand je ne suis pas authentifié. Testé sur deux appareils différents. od†n ↗blah 11 janvier 2022 à 14:17 (CET)
Oui c'est bon également pour moi, merci du retour.Pmartin (discuter) 11 janvier 2022 à 16:00 (CET)
Au niveau de la charge sur tes serveurs, ça donne quoi ? od†n ↗blah 21 janvier 2022 à 14:49 (CET)

MediaWiki:Sharedupload-desc-here – simplificationModifier

Requête à traiter


Pages où apparaît ce message : Les pages de l'espace Fichier:
Changement proposé : Je souhaiterais une simplification de ce message système. En effet, je trouve (et d'autres personnes le trouvent aussi) que ce message système n'est pas suffisamment simple et lisible. Avec Koreller, nous avons exploré les possibilités de changement, qui se trouvent ici. Voici un rendu de la proposition 1, que je préfère :

Accéder au fichier sur Commons

Ce fichier et sa description proviennent de Wikimedia Commons.


Merci d'avoir regardé cette demande. Manjiro91 15 janvier 2022 à 18:39 (CET)

Bonjour Manjiro et Koreller. Je pense comme vous que cette présentation gagnerait à évoluer. Cependant, je me pose juste deux questions.
Dans les insertions du « bouton cliquable 2 », ce dernier correspond souvent, quand il est bleu (class=mw-ui-progressive), à un bouton d'édition (« Ajouter un sujet », « Écrire », « Nouveau sujet », etc.) ou à une action (« Inscription », invitation à s'exprimer dans un débat). Ce bouton est aussi très ressemblant à celui de validation des publications de l'outil d'édition et peut donc effrayer légèrement les nouveaux. Donc je me demandais si la couleur bleue n'était pas destinée à ce type d'actions et la grise aux liens informatifs, plus neutres. Mais on a aussi quelques exceptions, bien sûr. Donc ? La documentation du modèle {{Bouton cliquable}} indique des nuances d'incitation à cliquer et de type d'actions. Quel degré d'incitation à cliquer doit-on avoir sur ce type de bandeau ? Le gris pourrait convenir pour cette action basique consistant à ouvrir une page sur Commons. Cette question est peut-être de l'ordre du détail.
Par ailleurs, si cette discussion est encore d'actualité, il semblerait que le maintien de la présence du logo de WikiCommons soit préférable. Sur ou à gauche du bouton ? Cordialement. — Ideawipik (discuter) 16 janvier 2022 à 00:49 (CET)
  Ideawipik : Bonjour, j'ai mis en bleu car plus lisible mais aussi car lorsque l'on clique sur une image, elle se zoome et il y a un bouton bleu avec écrit « Accéder au fichier ».
Manjiro91 16 janvier 2022 à 00:53 (CET)
Tout à fait @Ideawipik. Tu as raison les principes de la Wikimedia Foundation distinguent clairement le bouton bleu du bouton gris. Je me suis posé ce genre de question et à mon avis la couleur du bouton devrait être débattu, mais je pense que les personnes qui vont jusqu’à la page de description veulent aller plus loin et que le bouton bleu est plus pertinent, surtout que le bouton gris est peu visible rapidement.
Pour l'icône effectivement c'est pertinent de le garder, j'ai préparé les propositions 4 et 5Koreller (d) 16 janvier 2022 à 01:53 (CET)
Bonjour Koreller et Manjiro. Le bouton « Plus de détails » (lien vers Commons de l'extension Media Viewer), apparaissant quand on clique sur une image, est déjà bleu (une idée pour le logo ?). Il est vrai aussi qu'il n'y a pas grand chose à faire sur la page Wikipédia de ce genre de fichiers (mis à part « Ajouter une description locale (wikicode) » opération pas très claire pour un novice et même pour ancien, késako ?). Donc ton raisonnement peut s'entendre. Il serait intéressant de savoir si les utilisateurs passent plus souvent par le lien concerné par votre demande, placé en milieu de page, ou par celui plus discret situé en haut, parmi les "onglets d'action" (Lire, Créer, Modifier, Modifier en wikicode, Voir sur Wikimedia Commons, etc.). Je n'ai plus d'objections. — Ideawipik (discuter) 16 janvier 2022 à 19:04 (CET)

Rebonjour ou bonsoir Koreller et Ideawipik j'ai préparé les propositions propositions 6 et 7 où, à la place du logo bicolore, le logo est soit noir soit progressive. Bien à vous. Manjiro91 16 janvier 2022 à 21:51 (CET)