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

Ceci est une version archivée de cette page, en date du 18 juillet 2014 à 15:04 et modifiée en dernier par Ltrlg (discuter | contributions). Elle peut contenir des erreurs, des inexactitudes ou des contenus vandalisés non présents dans la version actuelle.

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

Ouverture d'élections pour le comité d'arbitrage

Requête acceptée - 1 septembre 2024 à 00:02 (CEST)


Pages où apparaît ce message :Liste de suivi

Changement proposé :Les candidatures au Comité d'arbitrage sont ouvertes du 1er au 19 septembre inclus. Seuls les comptes créés depuis plus de trois mois et censés avoir effectué plus de 350 contributions dans l'espace encyclopédique à l'ouverture du scrutin le 20 à 0:00 peuvent candidater.

Merci

Michel421 (discuter) 31 août 2024 à 21:57 (CEST)[répondre]

Bonjour Michel421 Émoticône
C'est fait, bien que je me sois permis une version plus courte à l'image de cette reformulation (Mwarf) de cette annonce. LD (d) 1 septembre 2024 à 00:02 (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

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. Émoticône sourire

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 :

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 :
  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)[répondre]
  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 Émoticône
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 ! Émoticône 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, Ambigraphe, 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". Ambigraphe, 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 :

  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 (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. Émoticône 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. Ambigraphe, 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). Ambigraphe, 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. Ambigraphe, 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. Ambigraphe, 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. Ambigraphe, 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. Ambigraphe, le 25 mai 2014 à 21:59 (CEST)[répondre]
.

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±&#139;porter plainte&#155; 26 août 2013 à 11:28 (CEST)[répondre]

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)[répondre]
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)[répondre]
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±&#139;porter plainte&#155; 26 août 2013 à 16:16 (CEST)[répondre]
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)[répondre]
Je note ici le bug no 53174 qui me semble lié — Ltrlg (discuter), le 14 décembre 2013 à 13:10 (CET)[répondre]
.

Requête à traiter


Bonjour, Modifier le message qui apparaît lorsque on essaye de modifier une page protégé. Il faut ajouter un bouton pour permettre de faire une demande de modification de la page facilement. Il doit ajouter le contenu suivant dans la page WP:DIPP :


{{a-dpp|Titre de la page en question}}
{{DIPP début|statut=|date=<!--~~~~~-->}} <!-- ne pas modifier cette ligne -->

<!-- Indiquez votre requête après cette ligne -->


~~~~ <!-- ne pas modifier cette ligne -->

{{DIPP fin}} <!-- ne pas modifier cette ligne -->

Cordialement. Hunsu (discuter) 13 mars 2014 à 14:16 (CET)[répondre]

Bonjour Hunsu
Je n'ai pas compris...
Cordialement, Trizek bla 13 mars 2014 à 16:06 (CET)[répondre]
Il s'agit de modifier ce message qu'on voit ici. Ajouter un bouton pour déclencher une demande d'intervention sur la page en question. Hunsu (discuter) 13 mars 2014 à 16:16 (CET)[répondre]
Tu dois surement parler de MediaWiki:Protectedpagetext ? Cordialement, Hlm Z. (discuter) 13 mars 2014 à 18:07 (CET)[répondre]
Oui, c'est ce message là. Hunsu (discuter) 13 mars 2014 à 18:27 (CET)[répondre]
.

Requête à traiter


Pages où apparaît ce message :

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

Requête à traiter


Pages où apparaît ce message :

Changement proposé :

Bonjour,

est-il possible sur (fr) d'avoir le même système ? A savoir une créer une Editnotice avec le modèle {{match en direct}} pour — entre autres — la page Coupe du monde de football de 2014 (voir la discussion ici).

Cordialement. --Jackrs le 15 juin 2014 à 16:05 (CEST)[répondre]

oups, je viens de voir qu'il existait {{Notice d'édition}} ; si j'ai bien compris, il faut créer la "page" : MediaWiki:Editnotice-N-Coupe du monde de football de 2014, non ? --Jackrs le 15 juin 2014 à 16:21 (CEST)[répondre]
.

Requête à traiter


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

Changement proposé :

Conformément à cette discussion, remplacer le texte actuel par : « ''Quick Preview'' : prévisualiser rapidement sans devoir recharger la page (ajout d'un bouton « Aperçu ») <small>[[[Projet:JavaScript/Notices/QPreview|documentation]]]</small>. »

Merci par avance,

Bien cordialement,

— Juanes852 (me contacter) le 8 juillet 2014 à 23:18 (CEST)[répondre]

.

[[MediaWiki: ]]

Requête à traiter


Pages où apparaît ce message : Je n'arrive pas à trouver où se situe se message. Le message système est situé à la dernière ligne de Spécial:Préférences#mw-prefsection-editing, dans la section « Aperçu ».

Changement proposé : Utiliser l’''Aperçu rapide'' (expérimental) <small>[[[Aide:Fonctionnalité Aperçu rapide|documentation]]]</small>

Merci par avance,

Bien cordialement,

— Juanes852 (me contacter) le 9 juillet 2014 à 00:27 (CEST)[répondre]

P.S. si vous avez le temps, merci de m'aider à traduire « on an edit form without reloading the remaining HTML code of the form », et « sortable tables ».

Je notifie également Seb35, cela pourrait t'intéresser.

.

Requête acceptée - 18 juillet 2014 à 15:04 (CEST)


Pages où apparaît ce message : Spécial:Préférences#mw-prefsection-editing, dans la section « Éditeur ».

Changement proposé :

Afin d'être conforme à la charte de signalement de la documentation de Spécial:Préférences#mw-prefsection-gadgets

remplacer

  • ([[Aide:Barre d'outils d'édition|documentation]])

par

  • <small>[[[Aide:Barre d'outils d'édition|documentation]]]</small>

Merci par avance,

Bien cordialement,

Juanes852 (me contacter) le 9 juillet 2014 à 00:38 (CEST)[répondre]

icône « fait » Fait — Ltrlg (discuter), le 18 juillet 2014 à 15:04 (CEST)[répondre]
.

Requête à traiter


Pages où apparaît ce message : S'affiche lorsqu'un utilisateur modifie une page en étant déconnecté.

Changement proposé : Une modernisation du bandeau serait intéressant afin qu'il soit plus cohérent avec les autres intro de pages existants.

Bandeau actuel:

Ma proposition:

--SleaY (discuter) 16 juillet 2014 à 23:48 (CEST)[répondre]

Bonjour SleaY Émoticône
Plus qu'une modernisation du bandeau, je pense que le fond du message en lui même devrait être revu et corrigé. J'avais pu établir, début 2013, une proposition à ce sujet. Mais la discussion a pris fin prématurément. Je pense qu'il serait pas mal de la relancer sur le projet de l'aide et de l'accueil. Si tu as une contre proposition, n'hésite d'ailleurs pas à la partager.
Je notifie Notification Trizek pour lui demander son avis.
Bien à toi, --— Superjuju10 [Aubline à votre disposition], le 17 juillet 2014 à 14:04 / 14:07 (CEST)
Plop, et merci pour l'initiative ! Émoticône sourire
L'important est de conserver quelque chose de court et de clair. Ce que Juju proposait dans la conversation qu'il cite se rapprochait de ces buts. D'où hop :
Idées en l'air, à faire mûrir ! Trizek bla 17 juillet 2014 à 14:19 (CEST)[répondre]
Ou encore :
--SleaY (discuter) 17 juillet 2014 à 18:26 (CEST)[répondre]
Juste une remarque : le bandeau aura un aspect sensiblement différent pour les personnes utilisant l'éditeur visuel (il s'affiche dans une popup très peu large). Pensez à tester cette situation avant de faire un changement. Il est possible de le faire en mettant le bandeau comme notice d'édition d'une page utilisateur et en essayant de modifier la page utilisateur avec l'éditeur visuel. Orlodrim (discuter) 17 juillet 2014 à 19:14 (CEST)[répondre]
Bien vue Orlodrim, je viens de le tester sur ma propre pas d'utilisateur et ça semble bien s'afficher --SleaY (discuter) 17 juillet 2014 à 21:48 (CEST)[répondre]
.