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

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.

<< Décision communautaire >> (je ne sais pas où l'intervention se passe)

Requête acceptée - 12 août 2024 à 22:09 (CEST)

Bonjour, ce serait pour ajouter un court commentaire à droite de « Décision communautaire » parmi les formulations toutes faites quand les administrateurs suppriment un article après une conclusion en suppression d'un DdA (càd développer le motif de suppression).

Pages où apparaît ce message : exemple ici

Objectif : Subir moins de recréations de force, notamment de la part des personnes ne connaissant pas la procédure de DRP.

Changement proposé : Mettre quelque chose comme « Veuillez formuler une wp:DRP si vous souhaitez une recréation. » à droite de « Décision communautaire ».

Merci :) Wikipédiennement.

Slzbg (discuter) 12 août 2024 à 21:40 (CEST)[répondre]

fait. C'était sur MediaWiki:Deletereason-dropdown. Escargot (discuter) 12 août 2024 à 22:09 (CEST)[répondre]

Merci beaucoup, Escargot bleu ! J'approuve votre reformulation, le sigle DRP est trop technique. Très bonne semaine à vous ! Wikipédiennement. Slzbg (discuter) 12 août 2024 à 22:29 (CEST)[répondre]

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 en cours d'examen

MediaWiki:Common.css,

Requête en attente d'informations

Pages où apparaît ce message :

Partie de la section #Mobile.css, Common.css et Common.js (listes-horizontales) non traitée, en:MediaWiki:Common.css

Je propose l'ajout de cette classe. Elle permet de créer des listes d'éléments sans puce (ce qui peut être très utile dans certaines circonstances, évitant l'abus excessif des balises <br /> par exemple).

Changement proposé :

/* Liste simple sans puce */
.liste-simple ul {
    line-height: inherit;
    list-style: none none;
    margin: 0;
}
.liste-simple ul li {
    margin-bottom: 0;
}

Hlm Z. (discuter) 25 mai 2014 à 14:06 (CEST)[répondre]

Il faudrait que le choix singulier/pluriel soit le même que pour liste(s)-horizontale(s) — Ltrlg (discuter), le 25 mai 2014 à 15:54 (CEST)[répondre]

Hlm Z. : je suppose que c’est toujours d’actualité, peux-tu donner avis sur le nom de la classe, que ça puisse éventuellement être traité ? — Ltrlg (discuter), le 12 septembre 2014 à 18:24 (CEST)[répondre]

Pour ma part, liste-simple au singulier me semble idéal. Cordialement, Hlm Z. (discuter) 13 septembre 2014 à 01:03 (CEST)[répondre]

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

Archive : Partie 1

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)[répondre]

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

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)[répondre]

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)[répondre]

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).[répondre]

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 ?[répondre]

Du JavaScript… berk. Bon, deux questions :

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 ;
que vient faire un hack pour Firefox dans un hack pour IE ?

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

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…
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)[répondre]

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)[répondre]

Ajout du comte Nemoi – Quelques jours, j’ai dit, pas quelques heures !

Amicalement, ce 18 décembre 2012 à 21:00 (CET).[répondre]

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, Ambi graphe, le 7 janvier 2013 à 22:01 (CET)[répondre]

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". Ambi graphe, le 8 janvier 2013 à 13:42 (CET)[répondre]

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 :

plus simple d'écrire class="hlist"
hlist est le nom standard sur wp.en, il est repris dans wikisource et wikilivres, et probablement d'autres wikis
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)
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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

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)[répondre]

Ç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…[répondre]

Archive : Partie 2

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)[répondre]

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. Ambi graphe, le 9 avril 2013 à 16:18 (CEST)[répondre]

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)[répondre]

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).~~ Ambi graphe, le 26 avril 2013 à 10:20 (CEST)[répondre]

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. Ambi graphe, le 26 avril 2013 à 10:42 (CEST)[répondre]

Je résume ce que je crois avoir compris : la modification demandée consiste à ajouter une classe permettant d'afficher une liste <ul></ul> avec un point rond plutôt qu'un saut de ligne entre les éléments. Les palettes seraient ensuite transformées en listes utilisant cette classe.

Pour l'instant, je n'ai pas touché à cette requête, parce que je ne comprends pas pourquoi ce changement est une amélioration, et le fait que ça ne marchera qu'en mettant du javascript ne me donne pas vraiment envie de comprendre.

Est-ce que quelqu'un souhaite soutenir cette requête ou je l'archive ?

Orlodrim (discuter) 26 septembre 2013 à 00:17 (CEST)[répondre]

Je pense que l’avis des principaux interlocuteurs pourra être utile : Ambigraphe, Hlm Z., Nemoi, Pixeltoo (désolé de ce spam à ceux qui seraient revenus sans ; j’en oublie probablement)

Le code JavaScript est une correction pour les vieux IE, mais qu’il faut probablement revoir, étant donné qu’il contient toujours une correction pour FF qui n’y sera jamais exécutée…

Il est cependant potentiellement lourd pour les pages avec beaucoup de palettes. Doit-on le conserver ou le retirer, comme l’alternance pour les tableaux il y a quelques temps ? Je n’ai pas de quoi faire les tests, mais la mise en forme ne me semble à priori pas trop cassée sans ?

Cordialement — Ltrl G^☎, le 26 septembre 2013 à 19:03 (CEST)[répondre]

Mon avis est que l'on pourrait bien se passer de Javascript si c'est juste pour éviter qu'un point médian se trouve en début de ligne sur une version dépassée d'un navigateur. D'autant qu'en ce qui me concerne, je trouve plus agréable de voir le séparateur en début de ligne. Comme quoi, des goûts et des couleurs… Plutôt que de gérer des parenthèses, on pourrait aussi séparer les éléments de sous-listes avec autre chose que le point médian gras : un tiret par exemple, sur un sélecteur CSS de la forme .listes-horizontales ul ul li+li:before. Ainsi, plus besoin de gérer de first-child ou last-child. Enfin bon, vous faites ce que vous voulez. Ambi graphe, le 26 septembre 2013 à 19:31 (CEST)[répondre]

Cette demande commence à dater alors j'ai décider de me pencher dessus. Je considère en effet que c'est une amèlioration d'une part pour l’accessibilité (cf. bonnes pratiques#Listes), d'autre part cela n'oblige plus à contruire un modèle compliqué pour ajouter les séparateurs partout, il suffit d'appliquer une "class" et de faire une liste normale.

J'ai trouvé une méthode pour avoir les puces qui ne passe pas à la ligne, sans javascript pour ie8. C'est de manière surprenante blink (Chrome / Opera, mais pas Safari) qui m'a obligé à faire un hack pour la puce après une sous-liste.

/**
 * Listes horisontales
 */
.listes-horizontales ul,
ul.listes-horizontales {
  margin: 0;
  padding: 0;
  white-space: nowrap;
  *white-space: normal; /* be kind ie7 */
}
 
.listes-horizontales li,
.listes-horizontales li ul {
  display: inline; 
  *white-space: nowrap; /* be kind ie7 */
}
 
/* Puces et parenthèses */
.listes-horizontales li + li:before {
  content: "· ";
  font-weight: bold;
  white-space: normal;
}
 
.listes-horizontales li li:first-child:before {
  content: "(";
}
 
.listes-horizontales li ul:after {
  content: ")";
  position: relative;
  left: -0.25em;
}
 
/*  hack pour Chrome/Opera pour que le point médian ne puisse pas se retrouver à la ligne après une sous-liste */
.listes-horizontales li:after {
    content: "\FEFF";
}
 
/* autres type de puce */
.listes-horizontales.boulet li + li:before,
.listes-horizontales .boulet li + li:before {
  content: "• ";
  font-weight: normal;
}
.listes-horizontales.tiret li + li:before,
.listes-horizontales .tiret li + li:before {
  content: "\2013\20";
}

J'ai fait en sorte que l'on puisse mettre la class "listes-horizontales" soit sur le ul, soit sur l'élément encadrant. Du coup je ne suis pas sur que le pluriel soit toujours nécessaire.

Je ne sais pas comment tester ça sur la version mobile. J'ai bien essayé de créer Utilisateur:Zebulon84/common.css mais ça n'a pas l'air d'être appliqué à la page. Savez-vous comment faire ?

Enfin bien sur, si on veux des puces sur IE6/7, il faut toujours du js. Mais est-ce toujours nécessaire ?

/* listes-horisontales, hack ie7 */
if ( ( $.client.profile().name == 'msie' ) && ( Number( $.client.profile().versionBase ) < 8 ) ) {
    var listesHorizontales = $( '.listes-horizontales' );
    listesHorizontales.find( 'li + li' ).prepend( '<b>·</b> ' );
    listesHorizontales.find( 'li ul' ).prepend( '(' ).append( ') ' );
 }

Zebulon84 (discuter) 19 mai 2014 à 01:44 (CEST)[répondre]

Je vote pour. Ambi graphe, le 25 mai 2014 à 12:08 (CEST)[répondre]

Pas d'objection également sauf pour l'ajout des puces supplémentaires (pour éviter des configurations différentes, mieux vaut normaliser la mise en forme). Cordialement, Hlm Z. (discuter) 25 mai 2014 à 14:26 (CEST)[répondre]

Même chose : quel est exactement l’intérêt d’avoir plusieurs types de puces (à part les préférences visuelles de chaque contributeur) ? Actuellement à ma connaissance, le seul effet notable de l’équivalent dans {{liste éléments}} est d’avoir des palettes incohérentes entre elles, voire incohérentes entre groupes de liens au sein de la même palette. De plus, la version JavaScript ne répercute pas cette différence, ce qui est problématique. Enfin je pense que liste-horizontale serait plus logique sur l’<ul> — Ltrlg (discuter), le 25 mai 2014 à 15:51 (CEST)[répondre]

J'ai mis des classes pour changer la puce car Utilisateur:Ambigraphe l'avait demander à Nemoi, et {{Liste éléments}} est souvent utilisé avec le séparateur boulet. Mais je n'y tiens pas particulièrement. Avoir des puces différentes m'a paru moins important que la simplicité du code javascript pour des vieux navigateurs probablement sur des ordinateurs peut performant.

Je me passerai bien aussi du hack Chrome/Opera qui corrige un défaut qui me semble mineur.

Zebulon84 (discuter) 25 mai 2014 à 18:20 (CEST)[répondre]

Il me semblerait même plus logique de mettre des tirets dans une liste de premier niveau et de réserver le point médian aux listes imbriquées. Ambi graphe, le 25 mai 2014 à 21:59 (CEST)[répondre]

requête du 23 février 2013

plus simple d'écrire class="hlist"
hlist est le nom standard sur wp.en, il est repris dans wikisource et wikilivres, et probablement d'autres wikis
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)
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

Mille excuses de réitérer ma requête, mais l’usage des listes de définitions va probablement se poser avec les données wikidata, et j'aimerais bien tester les listes ordonnées… Pourquoi ne pas centraliser les contributions sur MediaWiki, de nombreux wikis utilisent cette version depuis 2 ans… Encore désolé genium ⟨✉⟩ 1 août 2014 à 19:02 (CEST)[répondre]

À noter que depuis la version 1.24wmf21, MediaWiki désactive (enfin) JavaScript sous Internet Explorer 7[1][2]. La nouvelle génération de palette de navigation n'attend plus que la fin de cette requête. Cordialement, Hlm Z. (discuter) 5 octobre 2014 à 13:54 (CEST)[répondre]

Hlm Z. : c’est gênant, car il est toujours supporté pour les styles, si j’ai bien compris ? Cependant, comme il faut avancer, je veux bien traiter le CSS si la question du pluriel trouve une réponse plus conséquente que me semble idéal (cf. ci-dessus), puisqu’il me semble indispensable d’avoir la même conventions pour les deux requêtes (que je traiterais alors simultanément) — Ltrlg (discuter), le 5 octobre 2014 à 14:30 (CEST)[répondre]

MediaWiki:Echo-pref-new-message-indicator

Requête à traiter

Pages où apparaît ce message : Spécial:Préférences#mw-prefsection-echo

Changement proposé : (Peut-être plutôt modifier translatewiki:MediaWiki:Echo-pref-new-message-indicator/fr en enlevant le message local.) La formulation actuelle « Afficher l’indicateur de message sur la page de discussion dans ma barre d’outils » n'est pas claire, cf. Bistro : afficher un indicateur sur la page de discussion ? la page de discussion dans ma barre d'outils c'est-à-dire le lien Discussion ? Ce pourrait être « Afficher dans ma barre d’outils l’indicateur d'un message sur la page de discussion » ou « … l’indication qu'il y a un message sur ma page de discussion », ou n'importe quoi d'autre qui améliore le style et la formulation en évitant toute ambiguïté.

Oliv0 : j'ai modifié sur Translate (j'ai hésité à faire plus court mais j'ai peur des confusions s'il y a transition avec Flow). Il n'y avait pas de message local (enfin, jusqu'à ce que je le crée en me trompant d'onglet...). Je laisse la requête ouverte si quelqu'un est plus inspiré. — Kvardek du ^{(laisser un message)} le 12 septembre 2014 à 14:50 (CEST)[répondre]

Parfait merci, ah oui quand on ne voit pas d'historique c'est qu'il n'y a pas de message local. — Oliv☮ ^{Éppen hozzám?} 12 septembre 2014 à 14:56 (CEST)[répondre]

Requête à traiter

Pages où apparaît ce message :

Changement proposé : Ce gadget permet de faire des remplacements en Expression rationnelle préenregistrée (« Regex prédéfini »). Seulement la liste est actuellement en dur dans le script (cf nuxsr.mem) et je ne vois pas bien comment on pourrait la personnaliser (typiquement je trouverais puissant d'avoir un regex prédéfini du type « \[\[([0-9][0-9][0-9][0-9])\]\] → [[$1 en football|$1]] ». Auriez-vous une solution à me proposer ? Merci d'avance. — H4stings ^δ 23 septembre 2014 à 09:37 (CEST)[répondre]

MediaWiki:Histlegend

Requête à traiter

Pages où apparaît ce message : tous les historiques (pages &action=history)

Changement proposé : dans le lien wikiblame (Rechercher l'auteur), remplacer ?binary_search_inverse=true?user_lang=fr& par ?binary_search_inverse=true&user_lang=fr& — pas sûr que c'est vraiment pour cette raison qu'un IP dit sur le Bistro d'aujourd'hui qu'il le voit en anglais, mais autant avoir la bonne syntaxe des paramètres php avec un seul « ? » au début puis des « & ». — Oliv☮ ^{Éppen hozzám?} 4 novembre 2014 à 10:38 (CET)[répondre]

Comme je l'ai indiqué dans la discussion d'origine, Wikiblame respecte les préférences du navigateur. Du coup, ce ne serait pas mieux de supprimer le paramètre "user_lang" que de forcer "user_lang=fr" ? Orlodrim (discuter) 4 novembre 2014 à 19:59 (CET)[répondre]

Répondu sur le Bistro : l'absence du paramètre user_lang ne règle apparemment pas mon problème 78.250.237.179 (discuter) 5 novembre 2014 à 13:20 (CET)[répondre]

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

Sommaire

Requêtes traitées

<< Décision communautaire >> (je ne sais pas où l'intervention se passe)

Requêtes refusées ou sans suite

Requêtes en cours d'examen

MediaWiki:Common.css,

Requêtes à traiter

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

Archive : Partie 1

Archive : Partie 2

MediaWiki:Echo-pref-new-message-indicator

MediaWiki:Histlegend

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

Requêtes traitées

<< Décision communautaire >> (je ne sais pas où l'intervention se passe)

Requêtes refusées ou sans suite

Requêtes en cours d'examen

MediaWiki:Common.css,

Requêtes à traiter

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

Archive : Partie 1

Archive : Partie 2

MediaWiki:Echo-pref-new-message-indicator

MediaWiki:Gadget-searchbox.js

MediaWiki:Histlegend