Editnotice

Ce billet fait partie de la série « Personnalisons Wikipédia« .

Mediawiki possède une fonctionnalité permettant d’afficher un message aux personnes tentant d’éditer une page donnée, appelée l’Editnotice (notice d’édition). Cela peut servir dans les articles comme pour les pages utilisateurs ou de discussion.

Mettons que j’en ai marre que les gens éditent la page de mon bot, Loveless. Il me suffit de créer User:Loveless/Editnotice et voici ce que les éditeurs potentiels verrons :

Version éditeur visuel

Version éditeur normal

Par contre, ayez pitié des visiteurs : n’en faites pas un pavé clignotant digne de la page de user:MG et évitez donc de faire ça ! :D

—-

ressources :

• https://www.mediawiki.org/wiki/Help:Edit_notice
• https://en.wikipedia.org/wiki/Wikipedia:Editnotice

 

formulation malheureuse

Cette histoire date un peu, mais ça me fait toujours autant rire.

1 114 112 IP polonaises privées d’édition sur les projets Wikimedia [par Elfix]

Surprenant, non ? C’est la décision qui a été prise par les stewards en accord avec la communauté de la Wikipédia en polonais. Ce blocage global^[1] concerne 17 plages adresses IP, chacune contenant 65 536 adresses IP^[2]. Les utilisateurs affectés par ce blocage se voient suggérer, afin d’obtenir un déblocage, de contacter… leur fournisseur d’accès à internet (FAI). Voir le message complet, traduit en anglais, sur [[pl:Wikipedia:Blokada edycji dla sieci Orange i Play/en]].

Ces blocages ont été mis en place suite aux innombrables vandalismes particulièrement offensifs commis par un utilisateur, que l’on pourra qualifier de vandale de longue durée : banni en 2010 ; revenant sans cesse à la charge grâce aux IP dynamiques (ou « flottantes ») qui lui sont attribuées dans ses quelques accès internet habituels ; s’attaquant aux autres wikis lorsque bloqué sur celui d’« origine » (pl.wikipedia.org)…

C’est une mesure très radicale, mais qui a le mérite de responsabiliser les FAI qui, dans le cas présent notamment, sont restés sourds face aux plaintes adressées par les contributeurs de la Wikipédia polonophone leur faisant part des « contributions » dudit vandale. Mesure que nous pourrions reprendre de notre côté, vu les dernières discussions relatives aux blocages locaux de plages d’IP très utilisées. Pour l’instant, après 24 heures de blocage, il n’y a pas encore eu d’écho. Wait and see…

---

1. Blocage global : blocage d’IP affectant tous les wikis de la Wikimedia Foundation.
2. Dont un nombre légèrement inférieur d’adresses attribuables à des utilisateurs.

confusion Wikipédia/Wikileaks : ça devait arriver…

En tant que wikimédien(ne)s, vous pensiez que les histoires de Wikileaks ne vous concernaient pas ou peu ? détrompez vous.

Le pauvre user:Witty lama a subit un interrogatoire en rêgle des service d’immigrations australiens sur « la relation entre Wikileaks et Wikimedia »

La  stupide confusion que font beaucoup de gens entre les deux entités (même chez les « élites » de la nation française) n’est plus seulement agaçante, elle maintenant des conséquences « dans la vraie vie »… bordel, c’est pas faute d’expliquer la différence un peu partout, pourtant.

ça sera quoi après : Une coupure forcée de l’accès internet des contributeurs ? une descente du GIGN chez les membres du CA de Wikimedia France ?

(source)

Les serveurs de recherche sont en cours de migration

Dans l’architecture de la Wikimedia Foundation, certains serveurs sont dédiés à « Lucene », le service utilisé par les wikis comme moteur de recherche interne (=le formulaire à gauche dans le menu)

« Lucene » est en train d’être déplacé sur un autre groupe de machines, et un certain nombre d’options avancée sont désactivées jusqu’à la fin de la migration.

L’opération est prévue pour terminée vers 18H heure française.

stay tuned :)

les Flagged Revisions bientôt sur la wikipédia en langue anglaise

…ou pas tout a fait.

Tout d’abord… contrairement à une idée répandue, non, les Flagged Revisions n’ont pour l’instant jamais été activées là bas.  Cette fausse news à la vie dure est  notamment due à la reprise massive/déformation (massive aussi) par les médias des propos de Jimbo Wales sur le sujet.

« Flagged Revision » est le nom un système global de validation des nouvelles modifications sur un article a priori, c’est à dire qu’elles ne sont pas visibles aux visiteurs avant validation. Ce système a été proposé mi 2008 et est actuellement utilisé sur la Wikipédia en langue allemande, plusieurs wikinews et probablement 2/3 autres wikis de la foundation. Vous en trouverez les grandes lignes sur Wikipédia:Flagged revisions.

Une variante de ce système a été codée pour faire face aux demandes (notamment) de la Wikipédia en langue anglaise, et sera installée chez eux le 14 juin prochain pour une période de test de 2 mois. Cette variante  s’appelle « Pending changes » (litt. « modifications en attente »).  Elle est activable page par page, à l’instar du système de protection/semi protection, et sera limité durant cette période à 2000 articles. Les droits de vue/validations fonctionnent comme suit :

(le tableau est une traduction de celui de la page d’aide en anglais. C’est assez moche, je sais)

niveau de protection	IP / non-autoconfirmés	autoconfirmés	vérificateurs	sysop
.	peut éditer, modifications visibles par tout le monde
Pending changes (niveau 1)	Son édit sera visible par tout compte autoconfirmé mais pas par les IP ni les comptes non autoconfirmé (tant que pas validé).	Son edit sera validé automatiquement si le précédent édit de la page l’est. sinon même conditions que non auto-confirmé. Ne peut pas valider un édit.	Son edit sera validé automatiquement si le précédent édit de la page l’est. Peut valider les modifications non validées.
Semi-protection	ne peut pas éditer	peut éditer, modifications visibles par tout le monde
Pending changes (niveau 2)	Son édit sera visible par tout compte autoconfirmé mais pas par les IP ni les comptes non autoconfirmé (tant que pas validé).		Son edit sera validé automatiquement si le précédent édit de la page l’est. Peut valider les modifications non validées.
protection	ne peut pas éditer			peut éditer, modifications visibles par tout le monde

Notes :

• le status autoconfirmé est donné automatiquement a tout compte ayant au moins 4 jours d’ancienneté et au moins 10 éditions à son actif.

• le status « vérificateurs » n’existe pour l’instant pas. Ce groupe, s’il est créé, possèdera le droit de valider des « pending changes ».

De mon point de vue, « Pending changes », du fait de son ciblage de pages précis, est beaucoup mieux que les « Flagged Revisions ». Ca donne, comment dire, moins l’impression de nettoyer une tâche d’encre avec une bombe à neutron ; Cependant

• Il faut qu’il soit utilisé avec grande parcimonie. Sinon Wikipédia va vraiment se transformer en système avec comité éditorial.

• Dans la même optique que le comité éditorial, la personne qui valide une modification prend un risque juridique réel en le faisant. S’il valide par faute d’attention une édition contenant  une connerie répréhensible selon la loi française (diffamation, etc), la plainte pourrait bien être pour sa pomme.

• ce système a besoin, pour être efficace, que toute page bloquée par ce biais ai un ou plusieurs « surveillants » actifs. Il n’y a pas de groupe de vérification sur frwiki, et pour être honnête, les sysop n’ont pas que ça a foutre  de vérifier la merde des autres en permanence. Certains d’entre nous aiment bien aussi écrire des articles parfois, sisi :)

En bref, contrairement aux Flagged Revisions, je n’y suis pas à 100% opposé, tout en restant un peu méfiant. J’attend de voir la manière dont les gens d’enwiki s’en servirons et le résultat que ça donnera.

(source, annonce sur la ML Foundation)

Commons censuré en Iran : mise à jour

Un correctif sur mon billet d’hier, « Commons censuré en Iran« .

Il s’avère que le filtre empêchant les internautes iraniens d’accéder à Commons ne se limite pas à « commons.wikimedia.org », mais bloque l’ensemble de *.wikimedia.org.

C’est à dire que le bloc affecte non seulement Commons mais aussi :

Espaces publics

• Wikispecies (wikispecies.wikimedia.org), un catalogue d’espèces destiné aux scientifiques plutôt qu’au grand public

• Meta (meta.wikimedia.org), l’espace central de discussion sur les choses affectant l’ensemble des projets de la WMF

• le site des différents chapters ayant choisi l’hébergement par la WMF
  • nz.wikimedia.org (chapter neo-zélandais)
  • nl.wikimedia.org (chapter néerlandais)
  • no.wikimedia.org (chapter norvégien)
  • pl.wikimedia.org (chapter polonais)
  • rs.wikimedia.org (chapter serbe)

• l‘incubateur (incubator.wikimedia.org) où  les nouveaux projets sont démarrés et testés, jusqu’à ce qu’ils soient jugé apte à être déplacé dans un domaine propre

• Strategic Planning (strategy.wikimedia.org), où ont lieu les discussions/proposition sur le thème « comment verriez vous la WMF dans 5 ans »

• Wikimedia Outreach (outreach.wikimedia.org), qui vise à développer des ressources pour « atteindre » et aider les personnes n’ayant encore jamais édité un wiki

• Bugzilla, (bugzilla.wikimedia.org), le système de rapport de bug de MediaWiki et des diverses extensions utilisées sur les projets WMF

• lists.wikimedia.org, ou l’on peut gérer son inscription aux diverses Mailing Lists dont s’occupe la WMF

• Le site des différentes Wikimania (2005, 2006, 2007, 2008, 2009, 2010)

• Wikimedia Downloads (dumps.wikimedia.org) ou l’on peut charger la base de données (presque) complète des différents projets

• Wikistats (stats.wikimedia.org), qui comme son nom l’indique contient tout un paquet de stats diverses sur les projets.

• Wikimedia Laboratories (en.labs.wikimedia.org), où sont pré-testées les nouvelles extensions

• le wiki de la Wikimedia Usability Initiative (usability.wikimedia.org)

• Wikimedia Surveys (survey.wikimedia.org) où sont effectués les sondages officiels de la WMF

• Wikitech (wikitech.wikimedia.org), base de ressources pour les développeurs

• Le blog général de la WMF (blog.wikimedia.org) et celui des développeurs (techblog.wikimedia.org)

• nostalgia.wikipedia.org, contenant la Wikipédia en langue anglaise telle qu’elle apparaissait fin 2001, pour les nostalgiques (euh, ça sert à rien ce truc…)

Espaces de travail privés

(je me limite a ceux auxquels des iraniens auraient une quelconque raison d’avoir accès)

• internal.wikimedia.org, espace de travail pour la Wikimedia Foundation et les chapters

• OTRSwiki (otrs-wiki.wikimedia.org), espace de travail pour ceux qui aident à répondre aux nombreux mails envoyés via le système OTRS

Personnalisons Wikipédia : enrouler/dérouler des sections v2

Ce billet fait partie de la série « Personnalisons Wikipédia ».

Vous trouverez ci dessous une mise à jour du code de mon précédent billet, Personnalisons Wikipédia : enrouler/dérouler des sections, qui vous permet de masquer ou réafficher des sections de pages de Wikipédia en cliquant sur leur titre.

Les améliorations sont les suivantes :

• Au lieu d’encoder directement un display:none/display:block , le script fait maintenant appel à la classe CSS « hidden » pour masquer les textes, afin d’éviter des problèmes d’affichage lors du dépliage (un modèle s’affichant sur toute la largeur de la page au lieu d’une largeur fixe, par exemple). 2 mini fonctions sont dédiées à cette tâche.

• le bug faisant afficher un bout de code an dessous du sommaire lors d’un dépliage a été résolu.

• lorsque vous repliez une sous-section, puis repliez/dépliez sa section parente, cette sous section restera repliée jusqu’à ce que vous cliquiez spécifiquement sur son titre (auparavant, lorsque l’on dépliait une section, tout son contenu était déplié, peu importe que des sous-sections aient été indépendamment repliées)

• La section ne se replie plus lorsque vous cliquez sur le « modifier » à droite du titre de cele-ci.

Comme d’habitude, le script a surtout été testé avec firefox 3.x et marche au moins aussi avec Safari (pas de garantie pour IE ou chrome, prévenez moi si vous rencontrez un problème dessus)

Nouveau code pour la partie JavaScript (monobook.js ou vector.js)

/* ajoute une classe à un element */
function addClass(elem,classe) {
  elem.className += " "+classe;
}

/* enlève la premiere occurence du nom d'une classe d'un element */
function removeClass(elem,classe) {
    var reg = new RegExp('(\\s|^)'+classe+'(\\s|$)');
    elem.className=elem.className.replace(reg,' '); //ne replace que la premiere occurence (comme ça les hide imbriqués restent en hide ^^)
}

/* Cette fonction ajoute un "onclick" sur chaque titre, qui lancera un appel à toogleTitle() lors d'un clic sur ceux ci */
function ImplementToogleOnclick() {
   for( var titleLevel = 1 ; titleLevel <= 6 ; titleLevel++) { //tous les h1, h2 ... h6
      var titleList = document.getElementsByTagName('h' + titleLevel)
      var nb = titleList.length
      for( var a = 0 ; a < nb ; a++) {
          titleList[a].setAttribute('onclick', "toogleTitle(this)");
      }
   }
  //pour que ça ne se replie pas quand on clique sur un bouton modifier, on annule l'event au niveau du lien
  var editLinkList = document.getElementsByClassName('editsection')
  nb = editLinkList.length
  for( a = 0 ; a < nb ; a++) {
     editLinkList[a].setAttribute('onclick', "event.cancelBubble=true;");
  }
}
addOnloadHook(ImplementToogleOnclick)

/* Cette fonction, quand invoquée, fait disparaitre ou réaparaitre le contenu placé sous un titre jusqu'au prochain titre de niveau egal ou supérieur
(= un h3 s'arrete au prochain h2 ou h3 mais continuera s'il rencontre un h4 ou h5) */
function toogleTitle(p_this) {
  var titre_niveau = p_this.nodeName.substring(1,2) //le x de hx (1 de h1, etc.)

  //construction de l'expression reguliere permettant le trouver le prochain titre de niveau égal ou supérieur
  var stopMatch = "(h1"
  for(var niveau = 2 ; niveau <= titre_niveau ; niveau++)  {
    stopMatch += "|h" + niveau
  }
  stopMatch += ")"
  regex_stopMatch = new RegExp(stopMatch, "i" )

  var nextSiblingNode = p_this.nextSibling

  if( p_this.className != "neko_toogle_cache"  ) { // il faut replier
    p_this.className = "neko_toogle_cache"  //on ajoute une classe au titre pour savoir s'il est en mode replié

    while( nextSiblingNode ) {
       if( nextSiblingNode.nodeName.match(regex_stopMatch) ) break; //on a atteint le titre "bloquant" suivant = stop
       if( nextSiblingNode.style && nextSiblingNode.nodeName != 'SCRIPT' ) addClass(nextSiblingNode, "hidden") //ne pas affecter les nodes texte ni script
       nextSiblingNode = nextSiblingNode.nextSibling //on passe au voisin suivant
    }
  } else { //il faut déplier
    p_this.className = ""

    while( nextSiblingNode ) {
       if( nextSiblingNode.nodeName.match(regex_stopMatch) ) break;
       if( nextSiblingNode.style && nextSiblingNode.nodeName != 'SCRIPT' ) removeClass(nextSiblingNode, "hidden")
       nextSiblingNode = nextSiblingNode.nextSibling
    }
  }
}

voili.

Personnalisons Wikipédia : enrouler/dérouler des sections

Ce billet fait partie de la série « Personnalisons Wikipédia ».  Avez vous déjà rêvé de pouvoir plier/déplier des sections entières du bistro ou d’un article quelconque de notre belle Wikipédia  ? Grâce à la personnalisation d’aujourd’hui, c’est maintenant possible juste en cliquant sur le titre de la section.

Exemple par l’image, prise sur le bistro du jour  :

(faites pas attention à la couleur de fond grise, c’est un de mes autres test CSS)

*clic* sur « Le bistro/7 mars 2010 » => enroulé avec toutes ses sous-sections !

un autre clic dessus pour le re-dérouler.

Si le titre est un lien,  alors cliquez à droite du texte, ça marche aussi.

Malheureusement, il se trouve que j’ai totalement la flemme d’expliquer comment fonctionne la partie javascript (en plus, il y a un bout assez compliqué) ; donc je me contenterais de vous fournir le code :)

Comme d’habitude, le code est à insérer dans votre sous page monobook ou vector selon le skin MediaWiki  que vous utilisez.

Partie à mettre dans votre monobook.css (ou vector.css)

Ce petit bout de CSS est la raison de la colorisation différente (+ mise en italique) des titres repliés dans l’image ci dessus. « neko_toogle_cache » est le nom de la classe CSS que le code javascript donne aux titres repliés, pour pouvoir savoir qu’ils sont repliés et qu’ils faut « déplier » en cas de nouveau clic sur le titre.

/* couleur des titres dont la section est cachée par la fonction toogle */
.neko_toogle_cache {
  color:#333;
  font-style:italic;
}

Partie à mettre dans votre monobook.js (ou vector.js)

Pas d’explication détaillée pour cette partie là, désolé (juste les commentaires du code). Peut être plus tard, je vous promet rien :)

/* Cette fonction ajoute un "onclick" sur chaque titre, qui lancera un appel à toogleTitle() lors d'un clic sur ceux ci */
function ImplementToogleOnclick() {

   for( var titleLevel = 1 ; titleLevel < 7 ; titleLevel++) {
      var titleList = document.getElementsByTagName('h' + titleLevel)
      var nb = titleList.length
      for( var b = 0 ; b < nb ; b++) {
          titleList[b].setAttribute('onclick', "toogleTitle(this)");
      }
   }
}
addOnloadHook(ImplementToogleOnclick)

/* Cette fonction, quand invoquée, fait disparaitre ou réaparaitre le contenu placé sous un titre jusqu'au prochain titre de niveau egal ou supérieur
(= un h3 s'arrete au prochain h2 ou h3 mais continuera s'il rencontre un h4 ou h5) */
function toogleTitle(p_this) {
  var p_niveau = p_this.nodeName.substring(1,2) //le 1 de h1 (ou 2 de h2, etc.)

  //construction de l'expression reguliere permettant le trouver le prochain titre de niveau égal ou supérieur
  var stopMatch = "(h1"
  for(var a = 2 ; a <= p_niveau ; a++)  {
    stopMatch += "|h"+a
  }
  stopMatch += ")"
  reg = new RegExp(stopMatch, "i" )

  //on ajoute une classe (neko_toogle_cache) au titre pour savoir s'il est en mode replié
  if( p_this.className != "neko_toogle_cache") { //il faut  replier
     p_this.className = "neko_toogle_cache"
     var display_to_put = "none"
  } else { //il faut faire déplier
     p_this.className = ""
     var display_to_put = "block"
  }

  var nextSiblingNode = p_this.nextSibling

  while( nextSiblingNode ) {
     if(  nextSiblingNode.nodeName.match(reg) ) break; //on a atteint le titre "bloquant" suivant = stop

     if( nextSiblingNode.style) { //certains nodes sont des nodes texte et n'ont pas de style.
        nextSiblingNode.style.display = display_to_put
        if( nextSiblingNode.className = "neko_toogle_cache") nextSiblingNode.className = "" // x
     }
     nextSiblingNode = nextSiblingNode.nextSibling //on passe au voisin suivant
  }
}

Et ses derniers mots en tant que steward furent…

…« This proposal passes, but without the « Global blocks » related rights. »

Avant que d’aucuns paniquent -ou ne se réjouissent- , je suis toujours steward :) mais expliquons :

Du 1er au 31 janvier dernier s’est tenu un vote sur l’instauration d’un groupe de global sysop (voir ici pour le détail de la proposition en français et là pour la page de vote) qui s’est terminé avec une participation record de 1802 personnes, suite à quoi la page a été protégée. 1385 d’entre elles ont voté en faveur de la proposition – soit 76.9% en nombre brut. La limite théorique de passage est 80%, même si personne ne sais vraiment d’où elle est sortie (ça ne vous rappelle pas les élections admin sur frwiki ? :)

Un mois s’est écoulé, et le traitement de la proposition est toujours en attente. Les pro-pour et pro-contre veulent la traiter dans leur sens, mais ne peuvent pas de part leur implication ; les autres n’ont (et c’est compréhensible) pas la moindre envie de s’occuper de ce merdier.

Bref. Je dois dire qu’ayant eu d’autres préoccupations que meta dernièrement, je pensais que le machin était traité et passé depuis longtemps ; mais j’en ai ré-entendu parler au hasard d’une conversation sur IRC il y a quelques heures (me suis réveillé a 3h du mat, me demandez pas pourquoi). Bon bah, je suppose qu’il faut bien qu’un gentil bouc émissaire s’en occupe…

Après une lecture fastidieuse des différents votes (la plupart n’étant pas motivé, ça n’a pas été SI long heureusement), je remarque qu’une part notable des oppositions vient de l’idée de laisser à des non-stewards la possibilité de bloquer globalement un compte. Un petit ctrl+f pour récupérer les occurrences, et c’est parti mon wiki :

The following discussion is closed: This proposal passes, but without the « Global blocks » related rights.

---

This proposal’s raw rating is : 1385 / 1802 (76.9%).

One of the main points of concern about this proposal is the ability of global sysop to globally block accounts. (supports 39, 209, 422, 520 / opposes 5, 6, 13, 25, 50, 67, 77, 82, 89, 102, 148, 171, 180, 187, 217, 231, 242, 248, 252, 327, 331, 349, 387 ; plus all the people that voted « as per » them)

The proposal should have been closed a whole month ago. The most viable compromise seems to allow the proposal while removing this litigious bit.

so.

The Global Sysop proposal is accepted, with the following rights removed from it’s original formulation :

• Bypass global blocks (globalblock-exempt)
• Disable global blocks locally (globalblock-whitelist)
• Make global blocks (globalblock)
• Remove global blocks (globalunblock)

DarkoNeko 04:11, 1 March 2010 (UTC)

Donc voila, ça c’est fait.

J’attends maintenant que les 417 votants opposés à la proposition me tombent dessus. Mais dans une note plus positive, j’attends aussi que les 1385 votants en faveur de celle ci m’envoient des fleurs ou des chocolats :)

—

J’avais déjà du trancher un nœud gordien à la con d’ordre global l’an passé (sur la présence de Jimbo Wales dans le groupe des steward). Ce genre de trucs n’est pas particulièrement agréable à faire et j’aimerais  que ça ne devienne pas trop une habitude…