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

Archives

• Archive 2010, 2011
• Archives

Requêtes traitées

• 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.

Spécial:Liste de suivi – problème

Requête acceptée - 9 mai 2024 à 18:13 (CEST)

---

Enregistré sur Phabricator
Tâche 364395

Bonjour,

Depuis quelques jours, les listes de suivi ont été changées et nous avons 4 catégories mélangées. Je pensais que vous vous en rendriez compte … mais non. Ainsi, on voit toutes les RA et les pages de discussions qui viennent saturer la liste d’articles que l’on veut voir et cette opération n’est donc plus faisable. Pouvez vous revenir à l’état initial svp. Ce changement est très récent et dysfonctionnel.

Cordialement

Sadlerhm (discuter) 5 mai 2024 à 17:25 (CEST)

Bonjour @Sadlerhm,

Je ne suis pas sûr de comprendre ce dont vous parlez. La page Spécial:Liste de suivi n'a jamais permis un suivi par catégorie et Spécial:Suivi des liens fonctionne correctement. Escargot (discuter) 5 mai 2024 à 20:15 (CEST)

Bonjour @Escargot, et merci de m’avoir répondu.

Je finissais par désespérer… Votre mail est arrivé dans les indésirables (un autre nouveau dysfonctionnement). Il semble que je n’ai pas été clair. Dans la liste de suivi figurent normalement 4 catégories : nommément « Toutes, Pages, Discussion et Autres ». Or, désormais, et depuis peu, toutes sont rassemblées sous chacun des 4 onglets. C’est comme si on avait dupliqué 4 fois la catégorie « toutes », ce qui ne présente aucun intérêt. J’ai envie de regarder « pages » sans qu’elles soient polluées par toutes les RA, par exemple. J’espère avoir été plus clair. Cordialement Sadlerhm (discuter) 7 mai 2024 à 02:27 (CEST)

Bonjour Sadlerhm , je peine aussi à comprendre : si vous ne souhaitez voir que les Articles, les modifications d'autres personnes, les modifications/créations de page, alors cette URL est faite pour vous. Pour inclure aussi les Discussions des articles : cette URL.

La liste de suivi fonctionne effectivement par « filtres actifs » (disons critères de sélection) mais aussi par « espace de noms ». Vous pouvez adapter ce qui sera affiché en activant des filtres/critères puis enregistrer la sélection des critères. Cette sélection (vos choix) s'appliquera à chaque connexion ou visite de la page spéciale, en activant le mode « par défaut ».

L'interface ressemble à cette image (bien qu'en anglais) : naviguez et explorez les choix, ou dîtes-moi ce qui vous conviendrait. Si celle-ci convient ou que vous avez exploré puis arrêté votre choix, vous pouvez l'enregistrer. Voici comment faire :

• Repérez le logo marque-page () près de la poubelle () et cliquez dessus. Donnez un nom à ce marque-page (« Liste par défaut », par exemple) et cochez « Activer par défaut » avant de cliquer sur «  Créer un filtre ». Voilà, votre liste de suivi est débarassée des RA.

A noter que cette technique fonctionne aussi pour Spécial:Modifications récentes et que vous pouvez créer différentes sélections (filtres) qui ne seront pas des choix par défaut, ce qui vous permettra de temps à autres de voir ce qui se passe ailleurs (par exemple : que les portails et leurs discussions, que les pages sous R3R, etc.). Les sélections enregistrées sont listées dans « Filtres enregistrés ».

Si cela ne règle pas votre problème, merci d'expliciter ce que vous voyez et ce que vous souhaiteriez faire / voir. LD (d) 7 mai 2024 à 03:53 (CEST)

Bonjour LD , Et tout d’abord merci de votre long message et vos exemples.

Toutefois, je ne reconnais pas du tout mon contexte, opérant presque exclusivement sur mon téléphone portable, non sur un ordi.

En fait, depuis 4 longues années, j’utilisais efficacement cette liste de suivi qui fait n’importe quoi depuis une semaine. Dans « tout » j’avais tout mais je n’utilisais que « pages » qui regroupe les articles que j’avais sélectionné. Dans « discussion » figurait les discussions de ces mêmes articles. Enfin, dans « autres » figuraient les RA etc. Tout ça pendant 4 longues années. Or, depuis une semaine chacun des 4 onglets duplique l’onglet « tout » rendant les onglets inutiles et saturés m’empêchant de consulter « pages » pour les 1e modifs.

J’espère, cette fois, m’être bien exprimé car je souhaite revenir à l’état initial dans ma liste de suivi. Il est aussi anormalement récent que je reçoive vos notifs dans les indésirables. Les corrections de pages ne sont plus rouges et vertes mais bleues et jaunes. Bref, beaucoup de changements ont récemment eu lieu dont certains -hélas- préjudiciables.

Cordialement Sadlerhm (discuter) 7 mai 2024 à 12:52 (CEST)

Ça ressemble au problème rencontré il y a quelque mois dans Wikipédia:Le Bistro/1 août 2023#Anomalie dans les couleurs des listes de suivi (discussion illisible sur mobile), même s'il est ici question d'un problème récent. Je notifie @Trizek (WMF). Escargot (discuter) 7 mai 2024 à 14:05 (CEST)

Merci pour le ping ! C'est un autre souci, que j'ai documenté sur T364395. Sans doute un problème de filtrage automatique de la liste de suivi sur Minerva, où les quatre onglets permettant de séparer les types de contenus (tout, articles, discussions, autres) ne sont plus opérants. Trizek_(WMF) (discuter) 7 mai 2024 à 16:41 (CEST)

.

MediaWiki:Gadget-C_helper_tag.js – Lien brisé dans le résumé de modif laissé par C-Helper

Requête acceptée - 10 mai 2024 à 23:12 (CEST)

---

Pages où apparaît ce message : dans les résumés de modifications laissés par C-Helper lorsque l’on place un bandeau {{Admissibilité}}, le résumé est actuellement « Ajout de {{Débat d'admissibilité}} »

Changement proposé : Soit changer la valeur de display pour correspondre au nom du modèle, soit faire évoluer le code pour décorréler la valeur d’affichage dans l’interface du nom du modèle utilisé (si vraiment on tient à ce que « Débat » soit présent dans le nom pour ne pas confondre avec {{Admissibilité à vérifier}}).

Je remarque également que :

• le modèle {{Fusion d'Historique}} présent dans la liste n’existe plus. Il faudrait soit le supprimer s’il n’est plus pertinent, soit le remplacer (mais je ne sais pas par quoi).
• le modèle {{copie de site}} présent dans la liste est à présent une redirection vers {{copie à vérifier}}, également présent. Il faudrait donc le supprimer de la liste car il n’est plus pertinent.

— Metamorforme42 (discuter) 10 mai 2024 à 22:41 (CEST)

. Mais C-helper n'est pas le gadget le plus approprié pour lancer un débat d'admissibilité. Il faut plutôt utiliser PaStec qui enlève un éventuel bandeau d'admissibilité, crée les pages nécessaires presque automatiquement et permet de déposer facilement l'avertissement aux utilisateurs potentiellement concernés. Il y a aussi le gadget Adiutor, qui crée automatiquement les pages nécessaires, mais n'avertit que le créateur de la page. Escargot (discuter) 10 mai 2024 à 23:12 (CEST)

.

MediaWiki:Sitenotice – Mois africain 2024

Requête acceptée - 14 mai 2024 à 19:26 (CEST)

---

Pages où apparaît ce message : toutes les pages.

Changement proposé : demande d'apposition de ce bandeau pour le mois africain de cette année.

Du 1^er au 31 mai, Wikipédia francophone se met aux couleurs de l'Afrique. Venez combler le fossé des cultures !

ElsaBester (discuter) 14 mai 2024 à 17:59 (CEST)

Ne serait-il pas plus pertinent de faire une bannière centrale ? Trizek ^bla 14 mai 2024 à 18:13 (CEST)

J'avoue ne pas connaître toutes les subtilités. Mais vu que le concours ne concerne que WPfr et que le bandeau de l'année passée était fait par Sitenotice (https://fr.wikipedia.org/wiki/Wikipédia:Demande_d'intervention_sur_un_message_système/Archives3#MediaWiki:Sitenotice_–_Mois_africain_2023), j'ai jugé bon de faire la demande de cette même manière. Que dois-je faire maintenant ? --ElsaBester (discuter) 14 mai 2024 à 18:28 (CEST)

Disons que les bannières centrales sont plus facile à paramétrer : on peut choisir les projets, les langues, combien de fois on affiche la bannière, etc. Sitenotice est un peu plus rustique : c'est visible et c'est tout !

Bref, c'est fait. :) Trizek ^bla 14 mai 2024 à 19:26 (CEST)

D'accord, je retiens pour une prochaine fois ! Merci beaucoup --ElsaBester (discuter) 14 mai 2024 à 20:06 (CEST)

.

Requêtes refusées ou sans suite

• 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 à traiter

• 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.

Mobile.css, Common.css et Common.js (listes-horizontales)

Requête à traiter

---

Pages où apparaît ce message : Pour la Common.css, vous êtes habitués. Hé bien pour le Common.js, ce sont les mêmes. Ah, et pour la Mobile.css, ce sont les mêmes, mais en version mobile.

Changement proposé :

---

Ajout du comte Nemoi – Les palettes de navigation devraient subir de gros changements au printemps prochain ; il me semble qu’il commence à être temps de préparer le terrain, en simplifiant dès à présent les codes. Je souhaiterais donc importer certaines parties du code CSS et javascript hlist de nos voisins anglophones, sous le nom listes-horizontales ; pour être précis, seulement les listes non ordonnées, les listes ordonnées ayant une compatibilité moindre (de ce que j’imagine), et les listes de définitions n’ayant pas à mon goût d’utilité (je suppose qu’elles servent à faire des « listes nommées », mais ça me semble assez impropre comme usage). Il faudrait pour cela ajouter :

Ajouts proposés

à la Mobile.css (qu’elle soit ou non déjà créée) :

/*\
* * LISTES HORIZONTALES
\*/

.listes-horizontales ul {
  margin: 0;
  padding: 0;
}
.listes-horizontales li {
  margin: 0;
  display: inline;
  white-space: nowrap;
}
.listes-horizontales ul ul {
  display: inline;
  white-space: normal;
  padding-right: 1.2em;
}

.listes-horizontales li:after {
  content: " ·";
  font-weight: bold;
}
.listes-horizontales li:last-child:after {
  content: none;
}
 
.listes-horizontales li li:first-child:before {
  content: "(";
  font-weight: normal;
}
.listes-horizontales li li:last-child:after {
  content: ")\0a\0a\0a\0a";
  font-weight: normal;
}
.listes-horizontales li li:last-child {
  margin-right:-1.2em;
}

à la Common.css (même code avec des aides et des déclarations spéciales pour IE 8) :

/*\
* * LISTES HORIZONTALES
* 
*  Version simplifiée des classes ‘hlist’ des anglophones. Mainteneur originel (v. 2) : Edokter.
*  Nécessite du code html sur les pages spéciales et similaires (voir aussi [[Bugzilla:39617]]).
*  Nécessite un code javascript pour gérer last-child dans IE 8, et pour tout gérer sous IE 6-7.
*
\*/

.listes-horizontales ul {
  margin: 0;
  padding: 0;
}
.listes-horizontales li {
  margin: 0;
  display: inline;
  white-space: nowrap;
}

/* Les listes incrustées doivent être sécables, pas leurs éléments */
.listes-horizontales ul ul {
  display: inline;
  white-space: normal;
  padding-right: 1.2em;         /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (1/4) */
}

/* Puces et parenthèses */
.listes-horizontales li:after {
  content: " ·";
  font-weight: bold;
}
.listes-horizontales li:last-child:after {
  content: none;
}

.listes-horizontales li li:first-child:before {
  content: "(";
  font-weight: normal;
}
.listes-horizontales li li:last-child:after {
  content: ")\0a\0a\0a\0a";     /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Webkit */
  font-weight: normal;
}
.listes-horizontales li li:last-child {
  margin-right:-1.2em;          /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (2/4) */
}

/* IE 8 : NE PAS fusionner, IE 8 oublie toute la déclaration dès qu’il voit :last-child… */
.listes-horizontales li.last-child-pour-ie8:after {
  content: none;
}
.listes-horizontales li li.last-child-pour-ie8:after {
  content: ")\0a\0a\0a\0a";     /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour IE8 */
  font-weight: normal;
}
.listes-horizontales li li.last-child-pour-ie8 {
  margin-right:-1.2em;          /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (3/4) */
}

et au Common.js :

/**
 * Code pour listes-horizontales sous IE 6-7-8
 * Modification par Nemoi du code maintenu sur la version anglophone par Edokter
 */
 
if ($.client.profile().name == 'msie') {
  var versionBase = $.client.profile().versionBase;
 
  if (versionBase == '8') {              /* IE 8 : Simili :last-child */
    $('.listes-horizontales').find('li:last-child').addClass('last-child-pour-ie8');
  } else if (versionBase < '8') {        /* IE < 8 : points et parenthèses de listes-horizontales */
    var listesHorizontales = $('.listes-horizontales');
    listesHorizontales.find('li:not(:last-child)').append('<b>·</b> ');
    listesHorizontales.find('ul ul').prepend('(').append(')').css('margin-right', "-1.2em");    /* pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste, petit hack pour Firefox (4/4) */
  }
}

 

ce qui, puisqu’il s’agit de nouvelles classes, ne devrait pas poser de soucis. Merci d’avance ! ce 15 décembre 2012 à 04:50 (CET).

Il serait préférable de simplifier le nom de la classe, àmha. ~Hlm Z. [@] 15 décembre 2012 à 14:16 (CET)

Le nom proposé par Nemoi présente l’avantage d’être clair… Cordialement --Pic-Sou 15 décembre 2012 à 14:51 (CET)

---

Ajout du comte Nemoi – Je ne veux pas de hlist car le code n’est pas aligné sur celui de la version anglophone. Je ne veux pas de liste-horizontale (singulier), car ça donne très clairement envie de le mettre sur le <ul>. C’est une classe que l’on ne devrait pas avoir à utiliser très souvent, puisqu’elle sera gérée dans des modèles de palettes ou autres. Pour moi, le nom est correct et minimal (listes-en-ligne irait aussi), tu as une suggestion en tête ?.. Avec sympathie, ce 15 décembre 2012 à 17:03 (CET).

Va pour listes-horizontales (si cette classe est intégrée directement dans le modèle des palettes). ~Hlm Z. [@] 15 décembre 2012 à 18:24 (CET)

Je regarde un peu ça, quelques observations à chaud :

• La puce suivant des sous-listes peut se trouver en début de ligne
• « pour-ie8 » ou « pour-ie-8 » plutôt que « pour-ie-huit »

od†n ↗^blah 15 décembre 2012 à 19:34 (CET)

---

Ajout du comte Nemoi – Vaut mieux -ie8 alors (j’ai corrigé) ; je regarde pour cette histoire de puce d’après-parenthèse. Amicalement, ce 15 décembre 2012 à 22:00 (CET).

---

Ajout du comte Nemoi – Est-ce que les quelques hacks ajoutés ce 16 décembre 2012 à 01:15 (CET) permettraient comme je le crois de valider partout ?

Du JavaScript… berk. Bon, deux questions :

1. le hack pour IE a-t-il été stress-testé (grosse page, petite machine) ? il y a quelques semaines, j'ai dû retirer un hack pour les tableaux qui cassait le JavaScript sur les grosses pages à cause d'un « timeout » (en fait, un nombre limite d'instructions) sous IE ;
2. que vient faire un hack pour Firefox dans un hack pour IE ?

Amicalement — Arkanosis ^✉ 17 décembre 2012 à 03:08 (CET)

1. Réflexion à propos : Si on pense sur le long terme, ce JavaScript pourra être supprimé le jour où IE8 aura disparu, en revanche les derniers hacks pour Fx et WebKit risquent d'être nécessaires longtemps…
2. C'est nécessaire à cause de la règle CSS de la partie 1 du hack Fx

D'autre part, le problème de typographie est encore présent sous Opera

Face à ces contraintes techniques non résolues (encore que, les rustines CSS c'est moins grave qu'un mauvais markup, par exemple), j'avoue mon indécision sur ce qui serait le meilleur compromis, entre accessibilité, typographie et contraintes techniques. od†n ↗^blah 17 décembre 2012 à 03:29 (CET)

---

Ajout du comte Nemoi – Ce javascript me semble plus utile qu’un nombre certain de trucs qui traînent dans notre Common.js, et il est, à l’exception de la ligne du hack (qui ne concerne que IE6 et IE7), en production sur :en:, donc bon, on devrait pouvoir se l’autoriser à mon humble avis. Le problème de typo semble plus grave, bien que sur un cas rare d’une fonction (la sous-liste) rarement employée, et pour autant qu’il ne concerne hui qu’Opera, car on ne doit pas avoir à courir après les patchs à chaque version des navigateurs ; je cherche un code plus propre (voir le bas de ma feuille de style), donnez-moi quelques jours, ce 18 décembre 2012 à 15:04 (CET).

Un petit bug chez moi. ~Hlm Z. [@] 18 décembre 2012 à 15:28 (CET)

---

Ajout du comte Nemoi – Quelques jours, j’ai dit, pas quelques heures ! Amicalement, ce 18 décembre 2012 à 21:00 (CET).

Pourquoi pas « listes-en-ligne » plutôt que « listes-horizontales » ? Par ailleurs, est-ce qu'une classe pourrait permettre de transformer le boulet séparateur en un séparateur plus traditionnel de typographie française (tiret ou point-virgule, avec une virgule pour les sous-listes) ? Merci d'avance, Ambigraphe, le 7 janvier 2013 à 22:01 (CET)

---

Ajout du comte Nemoi – (Si ça met si longtemps, c’est que je n’avais plus d’accès à un IE pour tester, j’ai un code à mettre à l’Épreuve avant de le fignoler.) Pour le nom, ça m’irait aussi, comme dit plus haut ; je changerai à la mise à jour. Concernant le séparateur, on a un problème de l’usage actuel… le code s’adresse massivement aux palettes et autres éléments de navigation du genre, et je n’en ai vu aucune pour le moment utiliser un tel séparateur (c’est principalement du boulet et du point médian, avec quelques tirets « traits d’union » ou rarement mi-cadratins). Si tu arrives entretemps à faire changer l’usage moyen (si tu obtiens consensus pour basculer le modèle : Liste éléments, par exemple…), on pourrait y songer ici. En tous cas, l’usage d’une classe de style plutôt que de plusieurs modèles permettra dès que ce sera fait et utilisé de régler le séparateur de ton choix, de le faire tester aux personnes intéressées, et peut-être donc d’obtenir plus facilement un consensus pour changer l’usage de base. Avec sympathie, ce 8 janvier 2013 à 04:02 (CET).

Ce code pourrait aussi servir aux portails et j'avais effectivement utilisé le tiret pour la refonte du portail:Accueil. Je ne sais pas pourquoi Ju gatsu mikka a décidé de mettre des boulets à la place [1].

Cela dit, je ne souhaite pas que l'utilisation du tiret comme séparateur soit la norme. Je ne demande même pas que le tiret soit le séparateur par défaut (même si je pense que cela devrait être le cas). Simplement, j'aimerais pouvoir l'utiliser comme séparateur graphique, notamment sur les portails de mathématiques.

Au passage, je confirme que le modèle {{Liste éléments}} ne me plait guère et que je préfèrerais un modèle {{Listes en ligne}} qui produise un div class="listes-en-ligne". Ambigraphe, le 8 janvier 2013 à 13:42 (CET)

---

Ajout du comte Nemoi – Le diff que tu pointes laisse penser que l’objectif de Ju était d’éviter les possibles sauts de lignes avant le séparateur, chose qui s’avère particulièrement inesthétique. Concernant ce que tu souhaites maintenant : dans un premier temps au moins, un seul type de séparateur (a priori un point médian gras), et ensuite — dans la mesure du possible — la possibilité d’autoriser d’autres séparateurs spécialisés (CSS uniquement, bien sûr) en dehors des palettes ; donc les tirets, à ce moment-là, et c’est pas pour demain. Sympathiquement, ce 8 janvier 2013 à 14:36 (CET).

Je découvre la discussion sur le tard, mille excuses :(

Mon avis : Contre pour les raisons suivantes :

1. plus simple d'écrire class="hlist"
2. hlist est le nom standard sur wp.en, il est repris dans wikisource et wikilivres, et probablement d'autres wikis
3. pour l'instant, même implémentation pour ol et ul (voir le common.css sur wp.en) (valeur par défaut dans l'implémentation d'un standard)
4. j'utilise les hlist sur wikisource (voir par exemple ici ou là (listes non ordonnées), mais j'ai besoin de l'utiliser sur Wikipédia avec avec des listes de définitions pour le résultat suivant : terme1 : definition1 · terme2 : definition2

hama, il serait plus simple de clore cette discussion et d'implémenter la classe hlist dès aujourd'hui. Voir ma proposition : Ajout de la classe hlist dans MediaWiki:Common.css ;)
Cordialement, (genium ✉) 23 février 2013 à 09:51 (CET)

Avant toute implémentation, il serait préférable d'attendre une réponse de la part de Nemoi. Pour ma part, liste-en-ligne me parle mieux que hlist. Cordialement, ~Hlm Z. [@] 23 février 2013 à 13:16 (CET)

N'y a t il pas moyen d'utiliser les deux noms ? L'un serait l'alias de l'autre.--pixeltoo (discuter) 23 février 2013 à 14:03 (CET)

---

Ajout du comte Nemoi – Le code que j’ai pondu est une correction de celui de la Wikipédia anglophone, donc il vaut mieux utiliser le mien. Concernant le nom (puisqu’il ne s’agit que d’une histoire de nom pour le point 1), j’ai déjà répondu un peu plus haut : il n’est pas souhaitable que cette classe soit utilisée manuellement (donc pas de raison de faire court…) ; et le code ne doit pas être synchronisé sur la Wikipédia anglophone (ou, disons, il doit pouvoir être corrigé en local), donc, autre nom que hlist, quelqu’il soit, et un nom clair (il me semble que listes-en-ligne était préféré jusque là dans la discussion). Et bien entendu, pas de doublon de nom, même si Pixeltoo ouvre une nouvelle demande de blocage parce que je mets ainsi en doute ses capacités techniques. Je n’ai pas vu d’usage pour les listes ordonnées. Pour les listes de définitions, le cas que tu cites est critiquable mais à mon avis acceptable sémantiquement parlant ; je crains cependant un grand nombre de détournements sur Wikipédia, pour un usage correct nul ; aussi, ce n’est pas souhaitable de l’importer, sauf démonstration qu’on en a vraiment besoin. Et sinon, comme je ne suis pas présent ces temps-ci, vous pouvez vérifier qu’il n’y a pas de régression sur les dernières versions des navigateurs et importer mon code, on corrigera au besoin par la suite (en synchronisant ou non sur la Wikipédia anglophone). Voilà voilà, ce 23 février 2013 à 23:02 (CET).

Encore une provocation... Je ne vois pas l’intérêt de mettre des bâtons dans les roues de genium. Si hlist est moins compréhensible je pense que ce serait stupide de nous fermer des possibilités techniques en utilisant un terme accessible qui n'est pas forcément visible pour l'utilisateur moyen. --pixeltoo (discuter) 24 février 2013 à 14:36 (CET)

Pas très fan de « listes-en-ligne » pour ma part, ça me fait beaucoup trop penser au sens « online, sur le réseau », par contre « listes-horizontales » me plait bien. Mais honnêtement, le nom de la classe est le dernier des soucis. od†n ↗^blah 11 mars 2013 à 23:40 (CET)

Idem... « listes-horizontales » est le plus clair, ce qui est un avantage dès lors qu'il est destiné à un usage dans des palettes et des modèles. Pour éclairer ceux qui seraient à la recherche d'une classe « hlist », la description au début du code proposé pour inclusion dans common.css me semble suffisante. Klipe (d) 13 mars 2013 à 11:03 (CET)

Ça va bientôt faire un mois que cette requête (ouverte il y a presque 4 mois), assurément utile, est inactive alors que la principale opposition repose sur le nom de la classe. Il serait bien à mon avis de prendre une décision. Je préfère pour ma part aussi listes-horizontales, mais comme il a été dit plus haut, ça n’a pas un importance telle que cette requête doive en être bloquée. Cordialement — Ltrl G^☎, le 8 avril 2013 à 19:05 (CEST) PS : je me suis permis de mettre le code en boîte, car celui-ci prenait pas mal de place, et la discussion est longue…

Bug toujours présent chez moi. Voici le code correctif que je propose (un code JavaScript serait nécessaire pour IE8 et moins) :

/* Classe pour les listes horizontales séparées par des puces.
   Adaptation de la classe 'hlist' de en:User:Edokter.
   Nécessite du code html sur les pages (cf. [[Bugzilla:39617]]).
   Pour gérer last-child dans IE8 (ainsi que tout gérer sous IE6-7),
   nécessite un code JavaScript (cf. [[MediaWiki:Common.js]]).
*/
.lh ul,
.lh li {
   margin: 0;
   padding: 0;
}
 
.lh li {
   display: inline;
   white-space: nowrap;
}
 
/* Les listes incrustées doivent être sécables, pas leurs éléments */
.lh ul ul {
   display: inline;
   white-space: normal;
}
 
.lh li:after {
   content: " ·";
   font-weight: bold;
}
 
.lh li:last-child:after {
   content: none;
}
 
/* Récursion entre parenthèses et puces */
.lh li li:first-child:before,
.lh li li:last-child:after {
   font-weight: normal;
}
 
.lh li li:first-child:before {
   content: "(";
}
 
.lh li li:last-child:after {
   content: ")";
}

Une classe listes-simples très pratique à ajouter (pour {{Méta infobox navigation}} par exemple) :

/* Listes simples sans puce */
.ls ul {
   line-height: inherit;
   list-style: none none;
   margin: 0;
}
 
.ls ul li {
   margin-bottom: 0;
}

Remplacer lh par listes-horizontales et ls par listes-simples. Cordialement, ~Hlm Z. [@] 8 avril 2013 à 21:02 (CEST)

On peut déjà s'épargner les first-child et last-child pour les parenthèses en les plaçant juste avant et juste après l'élément ul, non ?

À part ça, je n'ai pas bien compris quel bug est relevé plus haut. Ambigraphe, le 9 avril 2013 à 16:18 (CEST)

Oui, ça me semble une bonne idée (mais peut-être me trompé-je ?).

Il y a un problème d’alignement des sous-listes (les lignes commençant par une parenthèse sont en retrait)

— Ltrl G^☎, le 22 avril 2013 à 10:29 (CEST)

Vu. Il y a aussi un écrasement des espaces à la fin des sous-listes (à gauche et à droite du point médian). Je pense qu'on peut déjà simplifier le traitement avec ma suggestion (déplacement des parenthèses sur l'élément ul). Ambigraphe, le 26 avril 2013 à 10:20 (CEST)

En fait, ma proposition pose problème car l'espace avant le premier élément de liste peut occasionner une coupure juste après la parenthèse ouvrante. Ambigraphe, le 26 avril 2013 à 10:42 (CEST)

.

MediaWiki:notification-page-linked-flyout (et MediaWiki:notification-page-linked-bundle ?)

Requête à traiter

---

Pages où apparaît ce message : Messages de notification affiché dans le nouveau système 'echo' si un article qu'on a créé est lié dans un autre article.

Changement proposé : Nouill (d · c · b) proposait que les messages de notification concernant l'inclusion d'un lien d'un article dans un autre, donne ntles liens vers les 2 articles concernés, et non seulement le lien vers l'article où a été ajouté le lien.

Le changement serait donc le suivant:

- $2 a été {{GENDER:$1|référencé}} depuis [[:$3]].
+ [[:$2]] a été {{GENDER:$1|référencé}} depuis [[:$3]].

--Creasy±^{‹porter plainte›} 26 août 2013 à 11:28 (CEST)

Pour une raison que j'ignore, si je tente cette modification sur translatewiki, j'obtiens le message d'erreur suivant : « Le lien suivant pose problème : [[:$2]] ».

Je préfère ne pas tenter pour le moment ; il conviendra peut-être de faire un test en local dans un premier temps.

Amicalement — Arkanosis ^✉ 26 août 2013 à 12:11 (CEST)

Je l’ai fait il y a 3 jours sur mon wiki de tests (quand j’ai vu passer la question sur Discussion Wikipédia:Notifications) pour flyout, ça semble fonctionner. Pour TranslateWiki, je pense que c’est parce que le lien n’est pas présent dans la version en anglais. Il vaut mieux à mon avis demander la modification pour tous (c’est-à-dire la modification du message en anglais puis traduction sur TW) — Ltrl G^☎, le 26 août 2013 à 15:40 (CEST)

Trizek (d · c · b) étant parti pour remonter cette modification comme un bug sur l'extension on peut ne pas modifier les messages systèmes du coup. Désolé pour le dérangement. --Creasy±^{‹porter plainte›} 26 août 2013 à 16:16 (CEST)

Tant qu'à faire, il vaudrait voir à ajouter également le nom de l'utilisateur responsable de la notification : la variable est disponible, mais pas utilisée.

Amicalement — Arkanosis ^✉ 26 août 2013 à 20:37 (CEST)

.

MediaWiki:Gadget-newCollapsible.css

Requête à traiter

---

Pages où apparaît ce message :

• Discussion Projet:Palette#Version admissible
• Discussion Projet:Palette#Palette de nouvelle génération
• Utilisateur:Hlm Z./Palette de navigation

Changement proposé :

Pour que tout le monde test la nouvelle génération de palette en cours de développement, il faudrait :

• Déplacer dans MediaWiki:Gadget-newCollapsible.css le CSS de Lgd (d · c · b) vers sa page personnelle Utilisateur:Lgd/Palettes/palettes V2.css (archivage du CSS). Le code à déplacer commence à partir du commentaire /* Les palettes, tout un monde à elles toutes seules... */.
• Remplacer le code par le contenu de Utilisateur:Hlm Z./Palette de navigation/common.css.

Cordialement, Hlm Z. [@] 30 août 2013 à 20:59 (CEST)

.

MediaWiki:Common.css - Logo Wikivoyage + image "en travaux"

Requête acceptée - 7 septembre 2013 à 12:10 (CEST)

---

Changement proposé : Bonjour,

Il faudrait mettre à jour le logo de Wikivoyage et pour

.en-travaux { ...

l'image a été renommée sur Commons en commons:fichier:Under_construction_icon-yellow.svg.png

Merci

Cordialement, --Mattho69 ^{me joindre} 4 septembre 2013 à 23:24 (CEST)

 Fait. Linedwell ^[discuter] 7 septembre 2013 à 12:10 (CEST)

.

MediaWiki:Common.css - Logo Baseball

Requête à traiter

---

Pages où apparaît ce message : {{Infobox Équipe nationale de baseball}}

Changement proposé : J'ai mis un coup de peinture (bleue) sur l'infobox. Pourriez-vous ajouter à l'endroit ad'hoc le pictogramme.

.entete.baseball {
  background: url("//upload.wikimedia.org/wikipedia/commons/3/3c/Baseball_pictogram.svg")     no-repeat top right;
}

Cordialement - Drongou (discuter) 7 septembre 2013 à 11:43 (CEST)

Merci d'avoir traité ma demande. Bon, visiblement, j'ai un peu loupé un truc car l'image doit être en 35px. Il n'y a qu'a laisser comme ça, dès que j'ai trouvé l'image je reviens. Cordialement - Drongou (discuter) 7 septembre 2013 à 22:09 (CEST)

Bon, j'ai pompé sur le hockey-sur-gazon. La ruse prendre l'image en SVG et demander un rendu 35px en PNG. Argh

Merci donc de corriger le rendu du pictogramme du baseball avec le code suivant (attention, il n'y a pas que la fin qui change, un thumb s'est intercalé au milieu du nom de l'image) :

.entete.baseball {
  background: url("//upload.wikimedia.org/wikipedia/commons/thumb/3/3c/Baseball_pictogram.svg/35px-Baseball_pictogram.svg.png")     no-repeat top right;
}

Cordialement - Drongou (discuter) 8 septembre 2013 à 23:08 (CEST)

.