„MediaWiki Diskussion:Common.js“ – Versionsunterschied

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter MediaWiki Diskussion:Common.js/Archiv.

Fehler bei Vorlage * Parametername unbekannt (Vorlage:Autoarchiv-Erledigt): "Modus"

Das wäre auch mit reinem CSS möglich:

div.action-submit, span.action-submit { display:none }
body.action-submit div.action-submit { display:block }
body.action-submit span.action-submit { display:inline }

Beispiel span --Fomafix MediaWiki Diskussion:Common.js#c-Fomafix-2012-02-25T11:45:00.000Z-css-Klasse für "Nur im Edit-Modus sichtbar"11Beantworten

Oder kürzer mit :not():

body:not(.action-submit) .action-submit { display:none }

Beim Internet Explorer geht das aber erst ab Version 9. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2012-05-24T21:52:00.000Z-Fomafix-2012-02-25T11:45:00.000Z11Beantworten

Hi! Ich suche eine Möglichkeit um in Artikel wo Zeitzonen angegeben sind (z.B. Städte, Länder, Zeitzonen selbst) die dort aktuelle Uhrzeit einzutragen. Wäre mMn keine "Spielerei", sondern eine große Hilfe für User, die die aktuelle Uhrzeit eines Ortes bzw. um wieviel diese dort gegenüber der ihrigen vor/nachgeht interessiert. Das ist sonst (v.a. wegen der unterschiedlichen Sommerzeiten) nur ausgesprochen schwer eruierbar. Meines Wissens nach geht das nur mittels JavaScript - siehe dazu WP:WikiProjekt Vorlagen/Werkstatt#Vorlage Zeitzone. Frage: Wer könnte mir dabei helfen? --Sebastian.Dietrich MediaWiki Diskussion:Common.js#c-Sebastian.Dietrich-2010-05-22T19:42:00.000Z-Aktuelle Client Uhrzeit mit Minuten11Beantworten

Ich schlag mal eine Vorlage {{UTC-Ticker|+2|30}} vor, die dann <span class="utcticker">+2:30 <span class="ticker">({{#time:H":"i":"s|2 hours 30 minutes}})</span></span> ausgibt. Der passende code (onload vorrausgesetzt) könnte so aussehen:

var tickers = getElementsByClassName(document.getElementById("bodyContent"), "span", "utcticker");
if (tickers && tickers.length > 0) ticktack(true);
function ticktack(start) {
   jetzt = new Date();
   if (jetzt.getSeconds() == 0 || start)
      for (i = 0; i < tickers.length; i++) {
         try {
            t = tickers[i].firstChild.data;
            hours = parseInt(t.match(/\d+/g)[0]);
            minutes = parseInt(t.match(/\d+/g)[1]);
            fb = t.match(/[+-]/)[1];
         } catch(e) { continue; }
         there = new Date(jetzt.parse() + ((fb==="+")? 1 : -1)*(hours*60+minutes)*60*1000);
         sp = tickers[i].getElementByTagName("span")[0];
         sp.data = "("+there.getUTCHours()+":"+there.getUTCMinutes()+")";
      }
   }
   window.setTimeout(function(){ticktack();},1000);
}

Könnte das funktionieren? Ich habe noch nie intensiv mit dem Date-Objekt gearbeitet.
meint -- ✓ ^Bergi MediaWiki Diskussion:Common.js#c-✓-2010-05-24T12:24:00.000Z-Sebastian.Dietrich-2010-05-22T19:42:00.000Z11Beantworten

Die Abschnitte der Form

var divs = document.getElementsByTagName("div");
for (i = 0; i < divs.length; i++) {
  if (divs[i].className !== "CSS-Klassenname") { continue; }
  …
}

können mit getElementsByClassName von http://bits.wikimedia.org/skins-1.5/common/wikibits.js für moderne Browser beschleunigt werden. --Fomafix MediaWiki Diskussion:Common.js#c-Fomafix-2010-08-07T13:29:00.000Z-getElementsByClassName11Beantworten

Hinweis: Die getElementsByClassName-Implementation aus wikibits.js hat Inkonsistenzen (Bug 16459), die sie zwar nicht unbenutzbar machen, aber zu beachten sind. Gruß --Entlinkt MediaWiki Diskussion:Common.js#c-Entlinkt-2010-08-07T16:08:00.000Z-Fomafix-2010-08-07T13:29:00.000Z11Beantworten

Dachte jetzt ist jQuery angesagt:

$j("div.CSS-Klassenname").each(

? -- Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2011-01-05T17:13:00.000Z-Entlinkt-2010-08-07T16:08:00.000Z11Beantworten

Ja, inzwischen. Ich denke wir sollten noch warten, bis MediaWiki 1.17 ausgerollt ist und dann unsere Skripte anpassen. --Fomafix MediaWiki Diskussion:Common.js#c-Fomafix-2011-01-05T17:47:00.000Z-Perhelion-2011-01-05T17:13:00.000Z11Beantworten

Auf jQuery umstellen kann man auch jetzt schon, hat man hinterher "nur noch" den ResourceLoader. Ich schreib schon mein Zeuchs auf jQuery um. --Guandalug MediaWiki Diskussion:Common.js#c-Guandalug-2011-01-05T17:54:00.000Z-Fomafix-2011-01-05T17:47:00.000Z11Beantworten

Scheint erledigt zu sein. Der Umherirrende 21:47, 13. Jun. 2012 (CEST)

Noch nicht erledigt. Es gibt weiterhin Konstrukte mit var divs = document.getElementsByTagName("div"); und anschließendem filtern auf bestimmte CSS-Klassen. Dies sollte durch jQuery ersetzt werden. Moderne Browser sollten damit schneller sein. Genaue Zeitmessungen könnten mit http://jsperf.com/ gemacht werden. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2012-06-13T20:03:00.000Z-getElementsByClassName11Beantworten

Ok, aber das bedeutet meistens noch mehr Arbeit, weil man danach ja mit jQuery-Objekten weiterarbeiten sollte. Ich hatte nach dem Wort aus der Überschrift gesucht, aber das wäre ja das Ziel und nicht das zu Änderne, daher falsch gedacht. Der Umherirrende 22:18, 13. Jun. 2012 (CEST)

Habe noch ein paar entfernt. Einige verbleiben in JavaScript was zu Vorlagen gehört, wie Vorlage:Link FA/Vorlage:Link GA, Vorlage:InterProjekt, Vorlage:Galerie und zu OSM ist erledigt Der Umherirrende 17:49, 15. Nov. 2012 (CET). Das sind jeweils Pakete, die man vermutlich generell überarbeiten/auf jquery stellen sollte. Der Umherirrende 14:12, 16. Jun. 2012 (CEST)

Hallo,

mich hat immer sehr gestört, dass aufgrund vieler Edits eines Authors die Versionsgeschichte so überfüllt war. Ich habe mit JavaScript bzw. jQuery eine Lösung entwickelt, die aufeinanderfolgende Einträge von Autoren zusammenfasst.

Aus

10.10.2011 05:10 FooBar (21.618 Bytes)
10.10.2011 04:48 Blibla (21.611 Bytes)
10.10.2011 04:47 FooBar (21.610 Bytes)
10.10.2011 04:47 FooBar (21.600 Bytes)
10.10.2011 04:46 FooBar (21.605 Bytes)
10.10.2011 04:45 FooBar (21.604 Bytes)
10.10.2011 04:42 FooBar (21.604 Bytes)
10.10.2011 04:40 FooBar (21.616 Bytes)
09.10.2011 18:00 Asdfgh (21.588 Bytes)

Mache

10.10.2011 05:10 FooBar (21.618 Bytes)
10.10.2011 04:48 Blibla (21.611 Bytes)
10.10.2011 04:47 FooBar (21.610 Bytes) (Zusammengefasst: 6 Einträge)
09.10.2011 18:00 Asdfgh (21.588 Bytes)

Ich nannte es "historyCombine", hier ist der Quelltext: Benutzer:Nightfly85/common.js

Per Klick auf den Text werden die versteckten Elemente ein- und ausgeblendet. Sinnvoll ist es zusammen mit einer angepassten common.css, in der Einträge passend formatiert werden: Benutzer:Nightfly85/common.css (Abschnitt: historyCombine)

Wäre es möglich, diesen Vorteil allen Wiki-Usern zugänglich zu machen? Gruß --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-06T11:11:00.000Z-Funktion erstellt: History-Einträge zusammenfassen11Beantworten

Ich würde daraus ein eigenständiges Gadget machen - dann kann sich jeder (angemeldete) Benutzer entscheiden, ob er#s möchte oder nicht... --Guandalug MediaWiki Diskussion:Common.js#c-Guandalug-2011-10-06T11:14:00.000Z-Nightfly85-2011-10-06T11:11:00.000Z11Beantworten

Wie geht das? :) --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-06T11:26:00.000Z-Guandalug-2011-10-06T11:14:00.000Z11Beantworten

Ist nur was für Admins (wegen der fehlenden Schreibrechte anderer im MediaWiki-Namensraum). Ich schau mir deinen Code mal an.... --Guandalug MediaWiki Diskussion:Common.js#c-Guandalug-2011-10-06T12:34:00.000Z-Nightfly85-2011-10-06T11:26:00.000Z11Beantworten

Wäre das nicht sogar was, was direkt in die MediaWiki Software integriert werden könnte? --Stefan MediaWiki Diskussion:Common.js#c-StefanPohl-2011-10-06T12:47:00.000Z-Funktion erstellt: History-Einträge zusammenfassen11Beantworten

Jo... aber DAS macht dann wer anders ;) --Guandalug MediaWiki Diskussion:Common.js#c-Guandalug-2011-10-06T12:58:00.000Z-StefanPohl-2011-10-06T12:47:00.000Z11Beantworten

Aber irgendwie müssen die Entwickler ja drauf aufmerksam werden. ;) --Stefan MediaWiki Diskussion:Common.js#c-StefanPohl-2011-10-06T13:26:00.000Z-Guandalug-2011-10-06T12:58:00.000Z11Beantworten

Getestet und folgende Bemerkungen: Den Pfeil, den ich auf den beiden Screenshots von dir erkennen kann, hab ich nicht. Außerdem wäre es imho sinnvoll, erst ab drei Beiträgen zusammenzufassen, bei zwei lohnt sich das meiner Meinung nach noch nicht. Bei einer Seite, die nur von einem einzigen Benutzer bearbeitet wurde, würde ich von einem Zusammenfassen auch eher absehen. SteMicha MediaWiki Diskussion:Common.js#c-SteMicha-2011-10-06T16:47:00.000Z-Funktion erstellt: History-Einträge zusammenfassen11Beantworten

sehr cool, sowas wollte ich immer serverseitig haben, bin aber unerklärlicherweise nie drauf gekommen, das auf dem client zu machen. klasse! -- ∂ MediaWiki Diskussion:Common.js#c-D-2011-10-06T20:11:00.000Z-Funktion erstellt: History-Einträge zusammenfassen11Beantworten

Mein Tipp: statt nach body.action-history zu suchen einfach oben if(mw.config.get('wgAction') != "history") return; einfügen. Ist deutlich schneller / resourcensparender. Ansonsten: Gerne als Gadget, aber nicht mehr. -- ✓ ^Bergi MediaWiki Diskussion:Common.js#c-✓-2011-10-06T22:41:00.000Z-Funktion erstellt: History-Einträge zusammenfassen11Beantworten

So, habe das Script nun grundlegend überarbeitet. Einhergehend habe ich das ganze nun auch etwas besser dokumentiert. Das Zusammenfassen findet nun erst bei mind. drei Beiträgen statt (kann aber bequem per Variable geändert werden). Auch Bergis Tipp habe ich befolgt. Weil es offenbar Probleme bei der Pfeil-Zeichendarstellung gibt, habe ich nun eine Wiki-eigene Pfeilgrafik verwendet. Den Link für das ein- und Ausklappen setzte ich nach hinten - ist irgendwie logischer. Ich verweise nochmal auf die Benutzer:Nightfly85/common.js und die ebenfalls aktualisierte Benutzer:Nightfly85/common.css. Für Fragen, Kritik und Anregungen bin ich offen. --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-06T23:10:00.000Z-Update11Beantworten

Ein paar Anmerkungen auf die Schnelle:

• Statt var $listItems = $('ul#pagehistory li'); ist var $listItems = $('#pagehistory').find('li'); effizienter.
• Vergleiche mit 0 sollte man immer mit drei Gleichheitszeichen schreiben, statt stack.length == 0 also stack.length === 0 (auch wenn das hier vollkommen unnötig ist).
• '&nbsp;<a href="#" class="mw-historycombine-autoBundleInfo">zeige ' + ctText + ' von ' + lastAuthorName + '</a>' ist durch lastAuthorName prinzipiell anfällig für XSS, überlass das Escapen am besten vorgefertigten Funktionen: ' ' + mw.html.element('a', {href: '#', 'class': 'mw-historycombine-autoBundleInfo'}, 'zeige ' + ctText + ' von ' + lastAuthorName)

--Schnark MediaWiki Diskussion:Common.js#c-Schnark-2011-10-07T07:27:00.000Z-Nightfly85-2011-10-06T23:10:00.000Z11Beantworten

Danke für die Tipps. Habe meine JS-Datei aktualisiert. --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-07T08:05:00.000Z-Schnark-2011-10-07T07:27:00.000Z11Beantworten

Der Pfeil wird bei immer noch nicht angezeigt. Kann das vielleicht daran liegen, dass ich meine .css nicht angepasst habe? Außerdem möchte ich nochmal vorschlagen, bei Seiten mit Bearbeitungen von nur einem einzigen Benutzer die Beiträge nicht zusammenzufassen. SteMicha MediaWiki Diskussion:Common.js#c-SteMicha-2011-10-07T09:51:00.000Z-Update11Beantworten

Ja, ohne eine angepasste CSS sind die Pfeile nicht zu sehen. Bei Seiten mit Bearbeitung nur eines Authors werde ich mir mal Gedanken machen. --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-07T09:56:00.000Z-SteMicha-2011-10-07T09:51:00.000Z11Beantworten

Bearbeitungen nur eines Autors werden doch sowieso nicht zusammengefasst? Das passiert aufgrund des Bugs, dass bei mehreren Bearbeitungen am Ende der Versionsgeschichte kein "neuer" Autor mehr gefunden wird, der das Zusammenklappen der vorigen auslöst. Löst man den Bug, muss man natürlich eine Option für nicht-Reduzieren bei mindestens x Aufeinanderfolgenden (default: Länge der History) ermöglichen.

PS: Wäre noch schön, wenn nach dem Aufklappen "verstecke" statt "zeige" angezeigt wird. Das ist aber kompliziert, weil durch die Animationsdauer mehrere Klicks trotz nur einer Klappaktion möglich sind. Zudem fände ich persönlich .slideToggle schöner als .fadeToggle:-) -- ✓ ^Bergi MediaWiki Diskussion:Common.js#c-✓-2011-10-07T14:39:00.000Z-Nightfly85-2011-10-07T09:56:00.000Z11Beantworten

Du hast nicht die neueste "Version" getestet, dort sind die beschrieben Bugs behoben. Außerdem habe ich dort bereits auch slideToggle benutzt :) Deine Idee mit "zeige"/"verstecke" werde ich bald einbauen. --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-07T14:52:00.000Z-✓-2011-10-07T14:39:00.000Z11Beantworten

+Zeitpunkt der ersten ausgeblendeten Bearbeitung wär gut: zeige weitere 8 Beiträge von Nightfly85 seit 12:59, 28. Sep. 2011. Eine wahrnehmbare Animationsdauer sollte es nicht geben. Ist da (schon) irgendwo eine Schaltfläche, um alle Bearbeitungen aller Benutzer einzublenden? Ist es möglich und will man die Zusammenfassungen der Ausgeblendeten Bearbeitungen (wenn sie denn welche haben) fließend aneinandergereiht einblenden? Ein Grund für die letzten zwei Fragen: Manchmal suche ich mit der Browser-Textsuche in der Versionsgeschichte. --Diwas MediaWiki Diskussion:Common.js#c-Diwas-2011-10-07T15:06:00.000Z-Update11Beantworten

• Das mit dem Zeitpunkt hätte ich auch gerne. Leider besitzt dieses Element / diese Elemente im Wiki-Quellcode (Markup) kein eigenes Element, es ist quasi eine rohe Text-Node. Eine Lösung, um an die Zeitinformation zu gelangen, bin ich daher leider noch nicht gekommen.
• Die Animationsdauer werde ich verkürzen
• Ich werde eine Schaltfläche einbauen, um alle Elemente auszuklappen
• Fließend aneinandergereihte Zusammenfassungen: Mhh, wie sieht sowas denn aus? Da geht die Übersicht doch erst Recht flöten?

Danke für deine Kritik! --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-07T15:12:00.000Z-Diwas-2011-10-07T15:06:00.000Z11Beantworten

Eine Alternative wegen des Zeitpunktes wäre vielleicht, die erste Bearbeitung nicht auszublenden, wie das ja bei zwei Bearbeitungen ohnehin schon ist, bei drei Bearbeitungen, wäre also nur die zweite Bearbeitung ausgeblendet. --Diwas MediaWiki Diskussion:Common.js#c-Diwas-2011-10-07T17:52:00.000Z-Nightfly85-2011-10-07T15:12:00.000Z11Beantworten

Sorry, vielleicht bin ich zu müde, aber ich verstehe nicht was du mir sagen willst :) Im Moment ist es so, dass, sofern es zu einer Zusammenfassung kommt, nur die oberste ( = neueste) Änderung gezeigt wird, während der Rest des Stacks versteckt wird. --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-07T21:58:00.000Z-Diwas-2011-10-07T17:52:00.000Z11Beantworten

Lies es morgen nochmal;-) also ich weiß nicht, ob das jetzt so ist, aber ich meine gelesen zu haben, dass erst ab drei Bearbeitungen was ausgeblendet wird, also wird bei zwei Bearbeitungen, die erste und letzte angezeigt, was auch sonst;-) Wenn man das auch bei mehr als zwei Bearbeitungen, so machen würde, was natürlich die Funktion etwas abschwächt, dann würde immer die erste und letzte Bearbeitung eines fortlaufend bearbeitenden Benutzers abgezeigt, damit auch der erste (manchmal aussagekräftigste) Kommentar und der erste Bearbeitungszeitpunkt. Ob das aber sinnvoll ist und ob das überhaupt einfach zu programmieren ist, weiß ich nicht. --Diwas MediaWiki Diskussion:Common.js#c-Diwas-2011-10-07T22:14:00.000Z-Nightfly85-2011-10-07T21:58:00.000Z11Beantworten

Ah, so ists verständlicher :) Vom programmiertechnischen Aufwand her wäre es machbar. Allerdings hätte man dann wieder eine Zeile mehr, die man ja eigentlich verhindern möchte. Nein, ich muss irgendwie an das Datum kommen, und sei es mit nem regulären Ausdruck. So ists am sinnvollsten. --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-07T23:49:00.000Z-Diwas-2011-10-07T15:06:00.000Z11Beantworten

Update Habe nun Links zum anzeigen/verstecken aller angefügt, die Animationsdauer verkürzt und die Texte der einzelnen Links angepasst (zeige/verstecke XXX Beiträge von XXX). Benutzer:Nightfly85/common.js Über weitere Kritik und vor allem Performanceberichte freue ich mich! --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-10-07T23:49:00.000Z-Update11Beantworten

Irgendeine Chance, dass das "ofiziell" wird? Also für alle als autoamtisch aktives Feature? Finde das extrem nützlich. --Stefan MediaWiki Diskussion:Common.js#c-StefanPohl-2011-11-07T15:09:00.000Z-Nightfly85-2011-10-07T23:49:00.000Z11Beantworten

Könnte neben zeige 3 weitere Beiträge von Benutzername noch ein Link auf den Versionsvergleich, der die zusammenhängenden Bearbeitungen umfasst, eingebaut werden? --Diwas 15:35, MediaWiki Diskussion:Common.js#c-Diwas-2011-11-08T14:53:00.000Z-Nightfly85-2011-10-07T23:49:00.000Z11Beantworten

+1 --Stefan MediaWiki Diskussion:Common.js#c-StefanPohl-2011-11-08T14:40:00.000Z-Diwas-2011-11-08T14:53:00.000Z11Beantworten

Allerdings stelle ich gerade fest, dass das Drücken von Enter ausreicht, wenn man vorher die richtigen Radiobuttons angeklickt hat. War mir nicht (mehr?) bewusst. Hab entweder Popups verwendet für die einzelnen Diffs oder die Schaltfläche angeklickt. Zwei Klicks und einmal Enter ist zumutbar. Ein direkter Link wäre effizienter, aber nur wenn die Performance nicht zu sehr leidet. --Diwas MediaWiki Diskussion:Common.js#c-Diwas-2011-11-08T15:08:00.000Z-Nightfly85-2011-10-07T23:49:00.000Z11Beantworten

Ich verstehe den Vorschlag nicht recht. Meint ihr damit, dass per Klick alle Versionen mit der vorherigen (oder nachfolgenden) Bearbeitung eines *anderen* Benutzers verglichen werden kann? Wenn ja - der Radiobuttons der neuesten zusammenhängenden Eintrages wird doch trotzdem mit angezeigt. Oder stehe ich auf dem Schlauch? :) --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-11-14T01:57:00.000Z-Diwas-2011-11-08T15:08:00.000Z11Beantworten

Achso! Ihr meint, dass es mit einem Klick möglich sein soll, die erste und die letzte Bearbeitung des zusammengefassten Beitrages zu vergleichen? --_{Nightfly85 | Disk} MediaWiki Diskussion:Common.js#c-Nightfly85-2011-11-14T02:01:00.000Z-Nightfly85-2011-11-14T01:57:00.000Z11Beantworten

Ja, ich denke du meinst jetzt das, was wir meinen, also den zusammengefassten Versionsvergleich der zusammengefassten Bearbeitungen. Vergleich der Version die der Bearbeiter vorgefunden hat zu Version die der Bearbeiter schlussendlich hinterlassen hat. Also das, was man jetzt erreicht mit: linker Radiobutton der Version, die unmittelbar unterhalb der Zusammenfassung steht, anklicken – rechter Radiobutton der Zusammenfassung anklicken – enter drücken. --Diwas 19:34, MediaWiki Diskussion:Common.js#c-Diwas-2011-11-14T18:41:00.000Z-Nightfly85-2011-11-14T02:01:00.000Z11Beantworten

Ich fände eine mit Obigem verwandte Funktionalität sehr nützlich: In der (einfachen) Beobachtungsliste die im ausgewählten Zeitraum mehrfach geänderten Seiten markieren. --Leyo MediaWiki Diskussion:Common.js#c-Leyo-2011-11-22T16:24:00.000Z-Update11Beantworten

Also beispielsweise alle nicht mehr aktuellen Versionen in grau darstellen oder grau hinterlegen? --Diwas MediaWiki Diskussion:Common.js#c-Diwas-2011-11-22T20:04:00.000Z-Leyo-2011-11-22T16:24:00.000Z11Beantworten

Da ich in den Einstellungen die Option Erweiterte Beobachtungsliste zur Anzeige aller Änderungen nicht angehakt habe, werden in der Beobachtungsliste keine nicht-aktuellen Edits angezeigt. Daher wäre eine Möglichkeit um anzuzeigen, wo weitere kürzlich getätigte Edits versteckt sind, praktisch. Wie viele es sind (≥2) spielt keine Rolle. --Leyo MediaWiki Diskussion:Common.js#c-Leyo-2011-11-22T23:15:00.000Z-Diwas-2011-11-22T20:04:00.000Z11Beantworten

Ach sorum war das, da hab ich wohl was verwechselt oder einfach falsch in Erinnerung gehabt. --Diwas MediaWiki Diskussion:Common.js#c-Diwas-2011-11-23T01:46:00.000Z-Leyo-2011-11-22T23:15:00.000Z11Beantworten

Ist nun an dem Script noch ein besonderer Wunsch zu erfüllen (habe etwas den Überblick verloren, ehrlich gesagt)? Wie sieht es mit der Integration in die common.js aus? --Nightfly85 | _Disk MediaWiki Diskussion:Common.js#c-Nightfly85-2012-05-15T11:56:00.000Z-Update11Beantworten

Hallo, Bergi hatte es ein gutes Stück weiter oben angedeutet. Ich fasse mal den absehbar erfolgreichen Ablauf zusammen:

1. Benutzer:Nightfly85/common.js
   • Ausgliedern als Benutzer:Nightfly85/historyCombine.js
2. Benutzer-Doku Benutzer:Nightfly85/historyCombine als Wikitext schreiben; Muster unter Benutzer:Schnark/js #Meine Skripte für jeweiliges Einzelskript, etwa Benutzer:Schnark/js/diff
3. Wikipedia:Technik/Skin/JS #Benutzerskript ./. Gadget lesen und checken.
4. Link auf Benutzer-Doku einfügen unter Wikipedia:Technik/Skin/Benutzerskripte #Versionsgeschichten und -unterschiede
5. Verbreitung abwarten; Reklame auf Benutzer:Nightfly85 machen
   • Resonanz?
   • Irgendwelche Bugs?
6. Nachdem von allerhand Benutzern eingebunden und erfolgreich:
   • Vorschlagen auf MediaWiki Diskussion:Gadgets-definition
7. In diese MediaWiki:Common.js selbst werden spezielle Werkzeuge nicht (mehr) eingebunden.

Zuvor:

• Füge mal ziemlich weit oben ein:

     /*jslint plusplus: true, sloppy: true, vars: true, white: true, maxerr: 50, indent: 4 */
     /*globals  mw: true, $: true, document: true */

• Zusätzlich Klammern { return; } bei if(mw.config.get('wgAction') ... { return; }
• Dann mal hier reinstopfen: http://jslint.com/ (Syntax-Analyse)
  • for(var i

Viel Erfolg! --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2012-05-15T15:48:00.000Z-Nightfly85-2012-05-15T11:56:00.000Z11Beantworten

Viiiiieeeelen Dank! --Nightfly85 | _Disk MediaWiki Diskussion:Common.js#c-Nightfly85-2012-05-15T16:21:00.000Z-PerfektesChaos-2012-05-15T15:48:00.000Z11Beantworten

Die Funktion openStreetMapToggle() befindet sich nicht in dem dafür vorgesehen Kontext mw.loader.using( 'mediawiki.util', function () { $( function () { … } ); } ); und ist somit als globale Funktion erreichbar. Wenn die Funktion dort nicht gebraucht wird, sollte sie in den Kontext verschoben werden. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2012-06-24T13:33:00.000Z-openStreetMapToggle()11Beantworten

Genau. Das meinte ich oben mit „anonymisiertem Toggelchen“. --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2012-06-24T14:16:00.000Z-Fomafix-2012-06-24T13:33:00.000Z11Beantworten

Oh, stimmt. Das habe ich ganz übersehen. Mir ist gerade nur aufgefallen, dass hier eine Funktion aus mw.util außerhalb von mw.loader.using( 'mediawiki.util', … ) verwendet wird. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2012-06-24T15:09:00.000Z-PerfektesChaos-2012-06-24T14:16:00.000Z11Beantworten

Nach dieser Diskussion nutzen zwei Benutzer die globale Funktion: Benutzer:PatDi/monobook.js, Benutzer:Sebastian Sooth (WMDE)/vector.js --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2012-06-24T15:09:00.000Z-openStreetMapToggle()11Beantworten

Die dortige Argumentation ist einleuchtend.

Bei einer Funktion, die nicht nur einmalig während der Seiten-Initialisierung auszuführen ist, sondern bedarfsweise später ausgelöst werden soll, kommt die Anonymisierung nicht mehr in Frage.

Dementsprechend wäre ein Anwendungsobjekt mw.libs.openStreetMap zu bauen, das eine API-Funktion mw.libs.openStreetMap.fire() bereitstellt und in Abhängigkeit einer in der common.js definierten .live=false individuell erstmal nichts macht.

Mit einem Anwendungsobjekt wäre auch alles aus dem global scope verschwunden.

Etwas freischwebend ist es, dass wir hier munter an kolossos vorbei für die weltweite OSM programmieren; aber das können wir ja dann als global gadget bereitstellen.

Nebenbei wäre das unter RL2 auch ein opt-out-Gadget-Kandidat.

Liebe Grüße --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2012-06-24T16:11:00.000Z-Fomafix-2012-06-24T15:09:00.000Z11Beantworten

Neija, der Benutzerwunsch ist, dass Karte beim Laden angezeigt ist. Die globale Funktion ist eine Möglichkeit das zu erreichen. Die meiner Meinung nach sinnvollere Möglichkeit ist, dass das Helferlein OpenStreetMap einen entsprechenden Benutzerparameter bekommt, mit dem eingestellt werden kann, ob die Funktion bereits beim Start ausgeführt werden soll, oder nicht. Oder gibt es andere Anwendungen eine globale Funktion openStreetMapToggle() benötigen? --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2012-06-24T21:26:00.000Z-PerfektesChaos-2012-06-24T16:11:00.000Z11Beantworten

Das wird schlicht und einfach zu fummlig.

Wir können nicht vorhersehen, wer rund um den Planeten später noch mit irgendwelchen Sonderwünschen und API kommt. So wie sich mir kolossos und sein OSM-Projekt darstellt, würden wir hier die Ablösung seines JS für RL2 zum weltweiten Einsatz schreiben. Dann lieber richtig.

Wer dann in welchem Moment irgendwas einschalten, ausschalten, beim Laden, hinterher nicht, oder doch ausblenden, wieder aktualisieren möchte, … kann uns dann egal sein. Wer einen Benutzerparameter in common.js haben möchte, auf den können wir auch noch Rücksicht nehmen. Wenn das aber weder seine common.js noch Skin-Standard-JS ist, dann ist .using("user") auch schon vorbei und wir kommen an anonyme Funktionen nicht mehr heran.

Also lieber eine API anbieten, und dann kann jeder glücklich werden; sofern kein benutzerdefinierter Inhibitor mit .using("user") bekannt gemacht wurde, wird beim Laden die AutoRun-Funktion ausgeführt. Danach sollen die ausblenden, toggeln, irgendwas aktualisieren oder sonstwas anstellen; das juckt dann nicht mehr. Wer weiß, was sich die Leutchen mit einer iframe noch alles einfallen lassen.

Einmal langt mir, dass dann doch noch jemand mit einem Zugriffswunsch um die Ecke kam.

Süße Träume --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2012-06-24T22:31:00.000Z-Fomafix-2012-06-24T21:26:00.000Z11Beantworten

Ein Konfigurationsparameter hat von Vorteil, dass er in Zukunft vielleicht mal als Benutzereinstellung für das Gadget gesetzt und gespeichert werden kann. Ein Funktionsaufruf hingegen wird sicherlich nur über persönliche JavaScript-Programmierung möglich sein, was nicht jedermannssache ist. Die Funktion openStreetMapToggle() kann übrigens auch über $('#coordinates a:last').click() aufgerufen werden. Daher sehe ich keine Notwendigkeit für eine global erreichbare Funktion. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2012-06-25T06:18:00.000Z-PerfektesChaos-2012-06-24T22:31:00.000Z11Beantworten

Das Problem an der globalen Funktion ist auch, das die in den beiden oben genannten Fällen eigentlich zu früh aufgerufen wird, weil das document noch nicht ready sein muss und mediawiki.util auch noch nicht geladen sein muss. Wenn man da eine globale Methode haben möchte, muss man das eigentlich sicher stellen. Der Klick von Formafix könnte auch zu früh kommen, weil man auf die ready-Queue keinen Einfluss hat. Keine Ahnung, wie man damit weiter verfährt. Der Umherirrende 17:47, 15. Nov. 2012 (CET)

Naja, das ganze veraltete Zeugs müsste man neu und zukunftssicher schreiben; auch für RL2 und künftige Benutzerwünsche weltweit. Lokales Gefrickel in dewiki mögen Behelfslösungen sein, aber etwas neu Geschriebenes sollte von kolossos dann auch für alle WMF übernommen werden können. Wikipedia:Technik/Skin/Werkstatt/Baustellen/OSM weltweit --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2012-11-15T17:23:00.000Z-Fomafix-2012-06-25T06:18:00.000Z11Beantworten

Hallo. Seit Jahren gibt es immer wieder Probleme damit, dass in Tabellen wie Liste der Großstädte in Deutschland die erste Spalte von 1 aufwärts sortiert bleiben soll, wenn der Rest mittels der tablesorter-Funktion von MediaWiki sortierbar sein soll. Da sich anscheinend niemand an den Code wagt und derzeit die ganzen Zeilen umsortiert werden, was die Änderungen wohl auch nicht ganz so trivial macht, schlage ich folgenden Workaround aus der polnischen Wikipedia vor:

$('table.sortable th.unsortable.ordinal').each(function(i, th) {
  var $th = $(th), $table = $th.closest('table');
  $table.on('sortEnd.tablesorter', function() {
    $table.find('tr td:nth-child('+ (th.column+1) +')').each(function(j, td) {
      $(td).text( (j+1) );
    });
  })
});

Nach der Sortierung wird eine Spalte, deren table header mit der Klasse "unsortable ordinal" bezeichnet ist, einfach von 1 aufsteigend mit Zahlen gefüllt. Das ist natürlich keine perfekte Lösung, aber für 99% der Fälle hier in der Wikipedia reicht das. Der dazugehörige Bug (in dem auch dieser Code auftaucht) ist bugzilla:40618. --APPER\^☺☹ 06:43, 2. Jan. 2013 (CET) Kleine Ergänzung: Live kann man sich das ganze beispielsweise unter pl:Miasta_w_Polsce_(statystyki) anschauen. --APPER\^☺☹ MediaWiki Diskussion:Common.js#c-APPER-2013-01-02T05:43:00.000Z-Vorschlag: ordinal unsortierbare Spalte in Tabellen11Beantworten

Öhm, hallo. Liest hier keine mit? Ich hätte schon gern 'nen Kommentar bevor ich mutig bin ;) --APPER\^☺☹ MediaWiki Diskussion:Common.js#c-APPER-2013-01-11T07:39:00.000Z-APPER-2013-01-02T05:43:00.000Z11Beantworten

Meiner Ansicht nach sollte das entweder direkt in MediaWiki oder gar nicht gelöst werden. Die vorgeschlagene Lösung ist auch nicht weniger Hack als die gegenwärtige, mit dem Zusatznachteil, dass sie nicht direkt in anderen Wikis funktioniert. --Schnark MediaWiki Diskussion:Common.js#c-Schnark-2013-01-11T08:52:00.000Z-APPER-2013-01-11T07:39:00.000Z11Beantworten

Hiho, nachdem die API aktualisiert wurde, habe ich nun mein Script fertiggestellt. Es zeigt oben rechts die Anzahl der Beobachter an. Ist diese Information nicht generell für jeden interessant? Hier gehts zum Script: Benutzer:Nightfly85/viewerInfo.js/Doku --Nightfly | _Disk MediaWiki Diskussion:Common.js#c-Nightfly85-2013-03-15T12:26:00.000Z-Anzahl der Beobachter anzeigen lassen11Beantworten

Ach so: Derzeit nur für den Vector-Skin. --Nightfly | _Disk MediaWiki Diskussion:Common.js#c-Nightfly85-2013-03-15T12:26:00.000Z-Nightfly85-2013-03-15T12:26:00.000Z11Beantworten

Gerade geprüft: Es funktioniert auch bestens im Monobook-Skin. --Nightfly | _Disk MediaWiki Diskussion:Common.js#c-Nightfly85-2013-03-15T12:42:00.000Z-Nightfly85-2013-03-15T12:26:00.000Z11Beantworten

Ich glaube, wenn das für jeden Seitenbesuch eingebaut wird, werden wohl die Server schmelzen. Im Hintergrund wird ja nicht einfach ein Datenbankfeld abgefragt, sondern es muss erstmal ein Aggregat (COUNT) gebildet werden. Ich werde es nicht einbauen, will es aber auch nicht blockieren. Der Umherirrende 15:42, 15. Mär. 2013 (CET)

Ah, verstehe. Dachte, der Integer wird als festes Feld abgelegt und bei Bedarf aktualisiert. --Nightfly | _Disk MediaWiki Diskussion:Common.js#c-Nightfly85-2013-03-15T15:12:00.000Z-Nightfly85-2013-03-15T12:42:00.000Z11Beantworten

Nein, in diesem Fall nicht. Gegenbeispiel ist die Anzahl der Bearbeitungen in den Einstellungen, das ist ein Feld, und die Anzahl der Seiten/Dateien/Unterkategorien auf der Kategorieseiten werden als eigene Felder gehalten, die Statistikzähler wie NUMBEROFARTICLES, NUMBEROFEDITS auch. Wobei es dabei bei den Feldern auch immer wieder Probleme mit der Aktualisierung gibt, so dass diese Zähler zu hoch oder zu niedrig sind. Da es kein eigenes Feld für die Beobachtungsanzahl gibt, lassen sich auch nicht alle unbeobachten Seiten auf einen Schlag ermitteln bzw. die entsprechende Spezialseite ist als "expensive" nur gecached verfügbar. Hat alles Vor- und Nachteile. Der Umherirrende 16:31, 15. Mär. 2013 (CET)

Hello, I propose to enable the tool created by Magnus Manske (creator of MediaWiki) to provide results from other languages and Commons (via Wikidata) when a page doesn't exist here: links are added to Special:Search and noarticletext. This helps to encourage translation and to make readers use your wiki more, because they can be sure to find something even if it's not local (rather than searching directly on the biggest wiki). The Italian and Polish Wikipedias, among others already enabled it by default.
Examples: [1] [2] [3]. More information: Magnus blog.
How to: just add the following line at the end of Common.js.

// Results from Wikidata
// [[File:Wdsearch_script_screenshot.png]]
if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Search' ||  ( mw.config.get( 'wgArticleId' ) === 0 && mw.config.get( 'wgCanonicalSpecialPageName' ) === false ) ) {
	importScriptURI("//en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.js&action=raw&ctype=text/javascript");
}

--Nemo MediaWiki Diskussion:Common.js#c-Nemo bis-2013-12-12T09:02:00.000Z-Give search results even when page doesn11 (comments, translations and last instructions)Beantworten

Ich habe hier für den Abschnitt ProjektLinks eine neue Implementierung, die auch Live preview unterstützt. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2014-04-02T07:02:00.000Z-ProjektLinks11Beantworten

/*
## ProjektLinks ##
by Skript von [[user:Merlissimo]] (Idee basierend auf http://de.wiktionary.org/wiki/MediaWiki:Common.js von [[User:Pathoschild]] und [[wikt:de:User:Melancholie]])
erzeugt Sitebar-Interwiki zu Schwesterprojekten aufgrund von Vorlage [[Vorlage:InterProjekt]]
siehe auch Feature-Request [[bugzilla:708]]
*/
mw.loader.using( [ 'mediawiki.util' ], function () {
	if ( mw.config.get( 'wgNamespaceNumber' ) <= 0 ) {
		return;
	}

	mw.hook( 'wikipage.content' ).add( function ( $content ) {
		// Entferne Sisterlinks von vorherigem Aufruf
		$( '#p-sisterprojects' ).remove();

		var iProject = $content.find( '#interProject' );
		if ( !iProject.length ) {
			return;
		}
		var sistersibling = $( '#p-lang' );
		if ( !sistersibling.length ) {
			sistersibling = $( '#p-tb' );
		}
		if ( !sistersibling.length ) {
			return;
		}
		// Link auf Parennode des Portletmenues
		var sisterparent = sistersibling.parent();

		// Erzeuge neues Portletmenue
		var sistersiblingsub = sistersibling.find( 'div:first' );
		var sisterprojectnav = $( document.createElement( 'div' ) )
		.attr( 'id', 'p-sisterprojects' )
		.attr( 'class', sistersibling.attr( 'class' ) )
		.append(
			$( document.createElement( 'h3' ) )
			.text( $content.find( '#sisterProjects:first' ).text() )
		)
		.append(
			$( document.createElement( 'div' ) )
			.attr( 'class', sistersiblingsub.length ?
				sistersiblingsub.attr( 'class' ) :
				'pBody'
			)
		);
		
		// Wenn möglich vor den Interwikis einfügen
		if ( sisterparent.has( '#p-lang' ).length ) {
			sisterprojectnav.insertBefore( '#p-lang' );
		} else {
			sisterparent.append( sisterprojectnav );
		}
		
		// Schwesterlinks ermitteln und einfügen
		iProject.find( 'a' ).each( function () {
			var $this = $( this );
			var sistername = $this.text();
			mw.util.addPortletLink(
				'p-sisterprojects',
				$this.attr( 'href' ) + '?uselang=' + mw.util.rawurlencode( mw.config.get( 'wgUserLanguage' ) ),
				sistername,
				'sister-' + sistername.replace( /[ _\-]+/g, '-' ).replace( /[^\-a-z0-9]+/ig, '' ),
				sistername
			);
		} );
	} );
} );

Weil ich grad über die letzte Änderung mit Link_FA / Link_GA guckte:

• Warum wird die ganze Geschichte nicht auf den ANR beschränkt?
• Oder gibt es außerhalb des ANR noch FA, von denen ich nichts weiß?
• Kann gleich mit dem nächsten Block zu einem beschleunigten switsch zusammengefasst werden:

switch ( mw.config.get( 'wgNamespaceNumber' ) ) {
   case -1:
      break;
   case 0:
      //   Link_FA / Link_GA
      break;
   default:
     // "Sitebar-Interwiki", aber bitte mit 'd'
     // ...
     // Link "Alle Sprachen" auf der Hauptseite?
     if( mw.config.get( 'wgIsMainPage' ) ) {
}   //   switch wgNamespaceNumber

• Weiter hinten gibt es übrigens zwei Blöcke mit der gleichen Abfrage ( 'wgNamespaceNumber' ) === 6 – das kann innerhalb einer Abfrage gebündelt werden, oder auch gleich in den vorstehenden switch mit rein als fall-through.

Und damit der erste Fall (Spezialseite) nicht so leer ist, kann dort die importScript("MediaWiki:Common.js/watchlist.js"); in Betracht gezogen werden.

Im Übrigen bin ich schon seit Jahren dafür, ein Anwendungsobjekt für Projektangelegenheiten aufzumachen:

if ( typeof mw.libs.dewiki  !==  "object" ) {
   mw.libs.dewiki = { };
}

• Innerhalb des mw.libs.dewiki können dann die ganzen größeren Einzelfunktionen benannt vereinbart werden; das verunstaltet nicht den globalen Namensraum; und der Quellcode muss sowieso geparsed werden, das lässt sich ohnehin nicht einsparen.
• Hier schlau benannte Einzelfunktionen vorab definiert, und dann im switch nach Namensraum nur noch die Funktionen ausführen, die in diesem Namensraum auch sinnvoll sind. Damit wird der switch aber übersichtlicher und das ganze Zeug schneller.
• Beispiel für gleich zwei solcher switche: Benutzer:Flominator/common.js

Der jüngste Beitrag von Fomafix kann dann auch gleich als mw.libs.dewiki.projectLinks vorab deklariert werden und wird nur im entsprechenden NR ausgeführt.

Liebe Grüße --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2014-04-02T07:52:00.000Z-Tuning und Struktur11Beantworten

projectLinks benötigt keine globalen Variablen. Ein Anlegen von mw.libs.dewiki.projectLinks ist daher nicht notwendig. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2014-04-02T08:12:00.000Z-PerfektesChaos-2014-04-02T07:52:00.000Z11Beantworten

Die Komponente mw.libs.dewiki.projectLinks würde nur der Reinhaltung des globalen Namensraums dienen.

Noch lieber wäre mir eine Kapselung, nach der ich seit langer Zeit giere, und die eine nachvollziehbare Benennung von Funktionsblöcken erlaubt, ohne als globale Variablen aufzutauchen:

/* jshint curly:true, latedef:true, laxbreak:true,
          trailing:true, undef:true, white:false                       */
/* global window:false                                                 */
( function ( mw, $ ) {
   "use strict";
   var NSN  =  mw.config.get( 'wgNamespaceNumber' );
   function link_FA_GA () {
      // ...
   }
   function projectLinks () {
      // ...
   }
   function projectLinks_onChangedContent ( $content ) {
      // ...
   }
   switch ( NSN ) {
      case -1:
         switch ( mw.config.get( 'wgCanonicalSpecialPageName' ) ) {
            case 'Upload':
               importScript("MediaWiki:Onlyifuploading.js");
               importScript("MediaWiki:Onlyifediting.js");
               break;
            case 'Watchlist':
               importScript("MediaWiki:Common.js/watchlist.js");
               break;
         }   //   switch wgCanonicalSpecialPageName
         break;
      case 0:
         link_FA_GA();
         break;
      default:
        // "Sitebar-Interwiki", aber bitte mit 'd'
        // ...
        // Link "Alle Sprachen" auf der Hauptseite?
        if( mw.config.get( 'wgIsMainPage' ) ) {
   }   //   switch wgNamespaceNumber
}( window.mediaWiki, window.jQuery ) );

Heißt:

• Am Anfang der Kapsel nur Deklarationen.
• Um die kommt man ohnehin nicht herum; nur in den Standard-Ressourcen hat man eine Aktualität von 10 Sekunden, sonst einen Monat. Importe lohnen sich nicht für Brösel.
• Daran anschließend eine reine Ausführung unter situationsabhängigen Bedingungen: Art der Seite, Modus, document.ready und sonstwas.
• Im Ausführungsteil stehen nur noch kurze, knappe, namentlich verständliche Aufrufe; auf Effizienz optimiert.
• Damit wird innerhalb eines kurzen Bereichs deutlich, was unter welchen Bedingungen auf welchen Seiten immer oder manchmal passiert.
• Weil die Namen innerhalb der Kapsel lokal sind, kann man verständliche Bezeichner für alles verwenden und muss keine unübersichtlichen Verschachtelungen anonymer Konstrukte verwenden.
• Übrigens brauchst du using( [ 'mediawiki.util' ] nicht gesondert abzufangen; ist im mw.hook()bereits mit gesichert.

Liebe Grüße --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2014-04-02T09:05:00.000Z-Tuning und Struktur11Beantworten

ProjectLinks erzeugt keine globale Variablen! Alles ist in Funktionen gekapselt. Das vergessene var habe ich korrigiert. Ein mw.libs.dewiki.projectLinks ist nicht notwendig.

Das implizite Laden von mediawiki.util ist vor mw.hook( 'wikipage.content' ).fire() kann sich mal ändern. Es ist daher sinnvoll mediawiki.util explizit anzugeben.

Meiner Meinung nach sollten die sauber gekapselten Module in separate Gadgets ausgelagert werden. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2014-04-02T11:23:00.000Z-PerfektesChaos-2014-04-02T09:05:00.000Z11Beantworten

1. Im gekapselten Teil steht überhaupt nichts mehr von mw.libs.dewiki – das wäre nur der andere Ansatz gewesen.
2. mediawiki.util wird nicht mal so eben wieder herausgenommen werden, da auch MW selbst sich darauf verlässt, und mw.hook sich auf das statische mw.util.$content beruft: resources/mediawiki.page/mediawiki.page.startup.js
   • Sollte das wider Erwarten trotzdem geschehen, werden wir das schon rechtzeitg erfahren. Dann ließen sich mit Leichtigkeit die paar mw.hook finden und nachrüsten.
   • Im Moment ist es nur Ressourcenvergeudung bei allen Lesern.
   • Warum wird eigentlich auf sämtlichen Diskussionsseiten nach projectLinks gesucht? Die kann es eigentlich nur auf SUBJECTPAGE geben; wir schreiben ja auch keine Interlanguage auf die Diskussionsseite. Hingegen könnte es außerhalb des WPNR schon mal die Vorlage:Information sein, oder ein Benutzer findet das schau.
3. Gadgets würden immer geladen werden; unabhängig vom Namensraum, und müssten eigenständig untersuchen, ob sie auf dieser Art von Seite in der momentanen Situation überhaupt sinnvoll sind. Das frisst auch wieder nur Ressourcen; und sie werden in den Zusammenstellungen für alle Benutzer sichtbar und machen diese unübersichtlich (mw:Extension:Gadgets kennt kein „Unsichtbar“, und standardmäßig aktiviertes Konfigurationszeugs, das Benutzer nicht verstehen und auch nicht wissen, ob sie es abwählen sollen oder nicht, ist auch keine Lösung); jeder Eintrag in der Benutzerkonfiguration verlängert die bei jedem einzelnen Seitenabruf übermittelte individuelle Einstellungsliste. Unterseiten werden hingegen nur einmal pro Monat aktualisiert, wenn man kein maxage dranschreibt. Es gibt keine wirklich hübsche Lösung.
   • Für link_FA/GA mag Opt-out eine für viele Benutzer nachvollziehbare Option sein; für die URL-Anpassung ist das eher nix.
   • Für kleine Schnipsel ohne Konfigurationsbedarf der Benutzer sind die Funktionsdefinitionen hier schon der übersichtlichste und schnellste Weg.

mw.util.$content ist meiner Meinung nach veraltet und sollte durch mw.hook( 'wikipage.content' ).add( function ( $content ) { … } ersetzt werden. Der Aufruf von mw.util.init() in mediawiki.page.startup.js und damit die Abhängigkeit zu mediawiki.util kann damit entfallen.

Gadgets müssen nicht immer geladen werden. Sie können per mw.loader.load( 'ext.gadget.…' ) nachgeladen werden. Das hat gegenüber importScript( … ) die Vorteile, dass der Code minimiert geladen wird und dass mehrere Anfragen zusammengefasst werden können. Außerdem werden notwendige Module automatisch mitgeladen und das Caching-Problem wird auch gelöst. Ausblenden von Gadgets steht auf der Roadmap. Gadgets werden bereits jetzt ausgeblendet, wenn Recht oder Skin nicht zutreffen. Mit CSS-Tricks kann ebenfalls ausgeblendet werden. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2014-04-03T07:40:00.000Z-Fomafix-2014-04-02T11:23:00.000Z11Beantworten

Zu mw.util.$content habe ich Bug 63466 aufgemacht. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2014-04-03T09:53:00.000Z-Fomafix-2014-04-03T07:40:00.000Z11Beantworten

Ich persönlich halte nichts von der Idee, alles in einem switch abzuhandeln. Aus meiner Sicht sollten die einzelnen Funktionen weiterhin eigenständig auf der Seite stehen. Dazu gehört dann auch das erneute Abfragen von Namensraum oder ähnliches, hat aber den Vorteil das man diese Sachen ändern kann, ohne die gesamte Seite kennen zu müssen, weil alles eigenständig ist. Außerdem lassen sich Funktionen einfacher in anderen Wikis wiederverwenden, weil man direkt sieht, was man braucht und keinerlei Bedingungen vergessen kann.

Zusätzlich ist anzumerken, das man sich normalerweise erst über Tuning Gedanken macht, wenn es notwendig ist. Generell bekannte oder potenzielle Bottlenecks kann man gerne vorher schon beseitigen, aber das generelle in Frage zu stellen, wenn es nicht umbedingt notwendig erscheint, halte ich für übertrieben. Aber das nur am Rande. Der Umherirrende MediaWiki Diskussion:Common.js#c-Umherirrender-2014-04-03T18:56:00.000Z-Fomafix-2014-04-03T09:53:00.000Z11Beantworten

Möglichst nicht zu viele Baustellen schaffen.

• Dass das dynamische function($content) dem statischen mw.util.$content für editierbare Seiten überlegen ist, steht außer Frage.
  • Ob und wann mw.util.$content dann gemäß gerrit:123559 deprecated und abgeschafft werden würde, liegt nicht in unserer Hand.
  • Wenn das so umgestellt wird und die Abhängigkeit von mw.util ebenfalls abgeschafft wird (was man auch bei Abschaffung von mw.util.$content nicht zwangsläufig tun muss), bekämen wir das Wochen vorher mit.
  • Das MW-eigene JS verlässt sich ebenfalls darauf, dass mediawiki.util geladen ist.
  • Wenn wir uns an eine Restrukturierung unserer common.js machen, dann sollte die Ausführungsfunktion per using davon abhängig gemacht werden, dass zumindest [ "mediawiki.user", "mediawiki.util", "user" ] und vielleicht noch user.options geladen sind. Dann muss nicht mehr jede Einzelfunktion sich selbst quellzeilen- und zeitaufwändig selbst darum kümmern, und alle können etwa auf Benutzereinstellungen eingehen.
• Zurück zu der Geschichte mit Gadgets. Das klingt durchaus spannend, und wenn das ohne Nachteile umsetzbar wäre, dann sehr gern.
  • Du schlägst also eine Pseudo-Skin vor; etwa dewiki oder common oder intern oder hidden.
  • Hier würden alle JS-Sequenzen geparkt, die man modularisiert auslagern möchte.
  • Weil niemand eine Skin namens common eingestellt haben kann, würde keine davon automatisch geladen.
  • Sie sollen durch geeignete CSS-Maßnahmen auf Spezial:Einstellungen#mw-prefsection-gadgets unsichtbar gemacht werden, um die Benutzer nicht zu verwirren.
    • Welches CSS übrigens? Per CSS3-Namensschema mw-input-wpgadgets-Common- für id= und for= – und die Überschrift? JS geht nicht; CSS aber vermutlich.
  • Als registierte Gadgets bekämen sie vom System eine ID und eine Zuordnung von Code zu dieser ID; und sie würden in der aktuellsten Form über //bits abgerufen und eingebunden.
  • Sie sollen dann per mw.loader.load(ID) in den Situationen dynamisch geladen werden, in denen sie sinnvoll sind.
  • Angedacht ist seit Mitte 2012 in mw:Gadgets ja vieles, aber ich sehe seit fast zwei Jahren keinerlei Bewegung mehr; weder Gadgets 2.0 noch Gadgets 3.0 noch sonstwas. Was da also irgendwo vorgeschlagen steht, interessiert mich wenig; nur was bereits als commit zum approve ansteht, akzeptiere ich als konkret absehbar. Ob eine Verstecken-Option behauptet wird oder nicht, ist für uns gegenstandslos.
  • Bau doch auf WP:BETA eine Demo auf.
  • Unabhängig davon lässt sich bereits heute überlegen, welche momentan zwangsläufigen Sequenzen man Benutzern zum Opt-Out anbieten möchte. Diese wären dann ohnehin in sich gekapselt und müssten für sich selbst sorgen. Das lohnt sich aber nur für wenige, und es muss ein konkretes Interesse von Normalbenutzern plausibel sein, eine Funktionalität nicht zu wünschen.

LG --PerfektesChaos MediaWiki Diskussion:Common.js#c-PerfektesChaos-2014-04-03T18:22:00.000Z-Tuning und Struktur11Beantworten

en:MediaWiki:Gadgets-definition, commons:MediaWiki:Gadgets-definition und mw:MediaWiki:Gadgets-definition verwenden rights=hidden|hidden zum verstecken. --Fomafix (Diskussion) MediaWiki Diskussion:Common.js#c-Fomafix-2014-04-03T18:40:00.000Z-PerfektesChaos-2014-04-03T18:22:00.000Z11Beantworten

Die Spezialseite ist schöner zu lesen: commons:Special:Gadgets. Aber es ist richtig, das man mit einer Benutzerrecht, welches keiner haben kann, die Eintrage auf der Einstellungsseite unsichtbar machen kann. mw.loader.using wird mit gerrit:75511/1.23wmf21 auch promise unterstützen, so dass mw.loader.using( 'foo' ).done( callback ); möglich ist. Keine Ahnung, ob das irgendwo bei hilft, aber es ist möglich. Der Umherirrende MediaWiki Diskussion:Common.js#c-Umherirrender-2014-04-03T18:56:00.000Z-Fomafix-2014-04-03T18:40:00.000Z11Beantworten

@DaB.: Dein generelles Abschalten des MV entspricht nicht dem MB. Das Opt-In ist damit nicht mehr wirksam. Zwar noch in den Einstellungen vorhanden, aber nicht mehr wirksam. Wenn du also unbedingt etwas basteln möchtest (ich befürworte das ausdrücklich nicht), halte dich bitte an den Text des MBs. Ich persönlich möchte den MV weiterhin nutzen. — Raymond ^Disk. MediaWiki Diskussion:Common.js#c-Raymond-2014-08-09T22:17:00.000Z-Abschalten MV11Beantworten

Das generelle Abschalten kommt dem MB-Ergebnis näher als ihn komplett anzulassen. AFAIK kann auch jeder angemeldete Benutzer den MV wieder anschalten, indem er in seinem js die Variable wieder aktiviert. --DaB. (Diskussion) MediaWiki Diskussion:Common.js#c-DaB.-2014-08-09T22:23:00.000Z-Raymond-2014-08-09T22:17:00.000Z11Beantworten

Naja, ich würde sagen das hätte man erstmal besser vorbereiten sollen, z.B. mit einer Option in den Einstellungen als Helferlein. Man könnte IP's auch erstmal(?) von der völligen Abschaltung ausschließen? Z.B. mit if (mw.config.get( 'wgUserName' )) davor. JS-Seiten benutzen doch wirklich die Allerwenigsten! (PS: Falls dieser Hack Bestand haben sollte – woran ich auch nicht glaube – müsste dann auch die entsprechende Option geändert werden. Nicht nur techn. sitzt ja die WMF am längeren Hebel...) → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-09T23:12:00.000Z-DaB.-2014-08-09T22:23:00.000Z11Beantworten

Da die Lizenz-Schwierigkeiten auch (und gerade) bei IPs auftreten, dürfen genau diese den MediaViewer in der aktuellen Form nicht sehen. Eine Möglichkeit den Viewer in den Einstellungen wieder anzuschalten wäre natürlich genial; wenn du da Code liefern kannst übernehme ich ihn gerne. Gut Nacht :-). --DaB. (Diskussion) MediaWiki Diskussion:Common.js#c-DaB.-2014-08-10T00:43:00.000Z-Perhelion-2014-08-09T23:12:00.000Z11Beantworten

Die Lizenzschwierigkeiten sind meiner Erfahrung nach schon länger ausgeräumt. — Raymond ^Disk. MediaWiki Diskussion:Common.js#c-Raymond-2014-08-10T06:26:00.000Z-DaB.-2014-08-10T00:43:00.000Z11Beantworten

Hallo @DaB.:, wir haben diese Änderung zurückgesetzt, weil sie einen nachteiligen Eingriff in die Funktionsweise des Projekts für zahlreiche Benutzer darstellt. Bitte stelle die Änderung nicht wieder her. Sonst könnten wir uns gezwungen sehen die Bearbeitbarkeit dieser MediaWiki-Seite zurückzunehmen um die volle Funktionsfähigkeit des Projekts für alle Benutzer zu erhalten. Vielen Dank und Grüße, --Jan (WMF) MediaWiki Diskussion:Common.js#c-JEissfeldt (WMF)-2014-08-10T09:17:00.000Z-Abschalten MV11Beantworten

Mit Drohungen werdet ihr nichts erreichen. Setzt den Willen der Community um und niemand hat ein Problem. --DaB. (Diskussion) MediaWiki Diskussion:Common.js#c-DaB.-2014-08-10T11:48:00.000Z-JEissfeldt (WMF)-2014-08-10T09:17:00.000Z11Beantworten

Deine Lösung bricht den Opt-in und ist damit nicht in line mit dem Meinungsbild. Wenn man das wirklich deaktivieren möchte, dann bitte ordentlich über die mediawiki-configuration. Grüße, Hoo man (Diskussion) MediaWiki Diskussion:Common.js#c-Hoo man-2014-08-10T11:54:00.000Z-DaB.-2014-08-10T11:48:00.000Z11Beantworten

+1 Wie kann ich es wieder einschalten? --elya (Diskussion) MediaWiki Diskussion:Common.js#c-Elya-2014-08-10T12:52:00.000Z-DaB.-2014-08-10T11:48:00.000Z11Beantworten

In dieser Situation nicht, da der umseitig eingefügte Code den Mediaviewer in deWP vollständig blockiert. Viele Grüße Patrick Stützel (Diskussion) MediaWiki Diskussion:Common.js#c-Patrick Stützel-2014-08-10T13:03:00.000Z-Elya-2014-08-10T12:52:00.000Z11Beantworten

Opt-in Lösung: Jemand (ein Admin mit Gadget-Erfahrung) muss einfach besagte Zeile in eine Gadget-Seite setzen und das Gadget dann auf default setzen und schon kann jeder in den Einstellungen den MV Aus-/Anschalten (hat auch jemand so auf Commons erwähnt).

PS: IMO halte ich es eh für intuitiver die Option da zu suchen. Nachträglich könnte man das Gadget noch dahin erweitern, dass es auch die "normale" Option für den MV ebenfalls manipuliert. → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-10T13:23:00.000Z-Patrick Stützel-2014-08-10T13:03:00.000Z11Beantworten

Keine Ahnung ob man die normale Einstellung per js manipulieren kann, per CSS ausblenden dürfte aber ohne Probleme gehen. Viele Grüße Patrick Stützel (Diskussion) MediaWiki Diskussion:Common.js#c-Patrick Stützel-2014-08-10T14:02:00.000Z-Perhelion-2014-08-10T13:23:00.000Z11Beantworten

Hallo Jan (WMF), wer genau ist "wir"? "Die WMF", Du persönlich in Deiner Rolle als angestellter Community Advocate (inwiefern bist Du dabei ein Advokat der Community?) oder wer sonst? Mir persönlich ist der MV ziemlich egal, und die Frage, ob und wie das Meinungsbild umzusetzen ist, kann sicher kotrovers in diesem Projekt diskutiert werden. Wenn aber die WMF meint, eingreifen zu müssen, wüsste ich schon gerne, wer da genau was auf Basis welcher Grundlage tut und wer die persönliche Verantwortung dafür trägt. Gruß --Magiers (Diskussion) MediaWiki Diskussion:Common.js#c-Magiers-2014-08-10T13:39:00.000Z-JEissfeldt (WMF)-2014-08-10T09:17:00.000Z11Beantworten

Jan, du kannst dich ja stattdessen als unser Advocat mal dafür einsetzten, dass die Foundation die Community und deren Entscheidungen respektiert. Dass dieses Ergebnis zustande kam, ist eure eigene Schuld. --Julius1990 Disk. Werbung MediaWiki Diskussion:Common.js#c-Julius1990-2014-08-10T13:49:00.000Z-Magiers-2014-08-10T13:39:00.000Z11Beantworten

Hallo Jan (WMF). Das Projekt wiki lief zweifellos jahrelang ohne den MV sehr erfolgreich. In den wenigen Wochen, die der MV in Betrieb ist, hat es bestenfalls bewiesen, das er den Erfolg (noch?) nicht gebremst hat. Einen Spruch wie "Sonst [also für den Fall das der MV abgeschaltet ist] könnten wir uns gezwungen sehen die Bearbeitbarkeit dieser MediaWiki-Seite zurückzunehmen um die volle Funktionsfähigkeit des Projekts für alle Benutzer zu erhalten" kann ich nur als dummdreist bezeichnen. Du suggerierst hier eine Gefahr im Verzug (die angeblich nicht vorhandene volle Funktionsfähigkeit ohne MV), die nachweislich nicht gegeben ist. Die WMF möge doch bitte bitte mal zur Sachlichkeit zurück kommen!!! -- Gerold (Diskussion) MediaWiki Diskussion:Common.js#c-Gerold Rosenberg-2014-08-10T14:07:00.000Z-JEissfeldt (WMF)-2014-08-10T09:17:00.000Z11Beantworten

Nicht dummdreist, diese totalitäre Phantasie wird (siehe Kurier-Disk) bereits evrfolgt. Julius1990 Disk. Werbung MediaWiki Diskussion:Common.js#c-Julius1990-2014-08-10T14:10:00.000Z-Gerold Rosenberg-2014-08-10T14:07:00.000Z11Beantworten

Add a new protection level called "superprotect" ... --Steinsplitter (Disk) MediaWiki Diskussion:Common.js#c-Steinsplitter-2014-08-10T14:10:00.000Z-Julius1990-2014-08-10T14:10:00.000Z11Beantworten

Und es kommt gleich zum Einsatz. 85.212.8.241 MediaWiki Diskussion:Common.js#c-85.212.8.241-2014-08-10T14:23:00.000Z-Steinsplitter-2014-08-10T14:10:00.000Z11Beantworten

"You might as well make the topic line ‚Declare war on local site admins‘" Das trift es, jatzt auch technische Entmachtung der Community. Jan und Eric Möller wollen tatsächlich die Eskalation. --Gleiberg (Diskussion) MediaWiki Diskussion:Common.js#c-Gleiberg-2014-08-10T14:27:00.000Z-Steinsplitter-2014-08-10T14:10:00.000Z11 PS: Man kann sich wenigstens ein bisschen wehrenBeantworten

Sind nicht für genau diese Fälle Deadmin-Verfahren vorgesehen? --Drahreg01 (Diskussion) ^3Wf MediaWiki Diskussion:Common.js#c-Drahreg01-2014-08-10T15:09:00.000Z-Gleiberg-2014-08-10T14:27:00.000Z11Beantworten

nachteiligen Eingriff in die Funktionsweise des Projekts....volle Funktionsfähigkeit blablabla. Mal wieder inhaltsleeres Geblubber seitens der WMF, genauso wie auf der Diskussionsseite des Meinungsbildes. Kann man eigentlich ignorieren. 85.212.8.241 MediaWiki Diskussion:Common.js#c-85.212.8.241-2014-08-10T14:16:00.000Z-Abschalten MV11Beantworten

Hallo, wir haben den Schreibzugriff auf diese MediaWiki-Namensraumseite zurückgenommen um die volle Funktionsfähigkeit des Projekts für alle Benutzer sicherzustellen. Vielen Dank und Grüße, --Jan (WMF) MediaWiki Diskussion:Common.js#c-JEissfeldt (WMF)-2014-08-10T14:26:00.000Z-Abschalten MV11Beantworten

Herzlichen Dank für die freundliche Serviceleistung. Wir hoffen auch zukünftig mit guten Produkten in Form von Artikel Ihnen dienstbar zu sein und die Klappe zu halten. --Gleiberg (Diskussion) MediaWiki Diskussion:Common.js#c-Gleiberg-2014-08-10T14:28:00.000Z-JEissfeldt (WMF)-2014-08-10T14:26:00.000Z11Beantworten

Ja da sieh mal einer an, wenn es schnell gehen muss dann geht es schnell. Das neue "Feature" kann wohl besser als "God mode" bezeichnet werden. Wie sieht es aus wenn das Fass hier überläuft? → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-10T14:30:00.000Z-Gleiberg-2014-08-10T14:28:00.000Z11Beantworten

Diese Serviceleistung kann mit einem Autogramm auf Wikipedia:Adminwiederwahl/Jan_eissfeldt gewürdigt werden. 85.212.8.241 MediaWiki Diskussion:Common.js#c-85.212.8.241-2014-08-10T14:31:00.000Z-Perhelion-2014-08-10T14:30:00.000Z11Beantworten

(Bk) Das nenne ich mal mit Kanonen auf Spatzen geschossen. Als ob der Mediaviewer für das Funktionieren der Wikipedia essentiell wäre. Wer den Mediaviewer angeschaltet haben will kann das, selbst wenn er hier ausgeknipst ist, immernoch über da eigene Common.js tun. Viele verdutzte Grüße Patrick Stützel (Diskussion) MediaWiki Diskussion:Common.js#c-Patrick Stützel-2014-08-10T14:39:00.000Z-JEissfeldt (WMF)-2014-08-10T14:26:00.000Z11Beantworten

Für mich wurde heute der Rubikon seitens der Foundation endgültig überschritten. Julius1990 Disk. Werbung MediaWiki Diskussion:Common.js#c-Julius1990-2014-08-10T14:33:00.000Z-Patrick Stützel-2014-08-10T14:39:00.000Z11Beantworten

@Jan (WMF): Oben habe ich dir (bzw. der WMF in dessen Auftrag du handelst) dummdreist zu argumentieren. Nun wird haargenau mit diesem dummdreisten Argument dummdreist gehandelt. Liebe WMF - das geht nicht gut! -- Gerold (Diskussion) MediaWiki Diskussion:Common.js#c-Gerold Rosenberg-2014-08-10T14:34:00.000Z-JEissfeldt (WMF)-2014-08-10T14:26:00.000Z11Beantworten

Somit hat die WMF gezeigt, dass euch die Belange derjeniger, die dafür Sorgen dass, das Projekt überhaupt funktioniert und dass die Chefetage ihr Gehalt bekommt, bestenfalls peripher tangieren. Das Overrulen eines verbindlichen Entscheides, der sich selbst verwaltenden Projekte, widerspricht dem Grundgedanken der Wikimedia-Projekte. Bis gestern hätte ich so eine Aktion eurerseits nie für möglich gehalten. Aber man lernt nie aus. Durch euer Verhalten gegenüber der aktiven Nutzer, tretet ihr alles was die letzten 10 Jahre aufgebaut wurde, die ganze Energie und Zeit die durch diverse Aktive kostenlos und ehrenamtlich eingebracht wurde mit Füßen. "Sauer" ist gar kein Ausdruck für die Gefühle die ich gerade hege. -- Jogo30 (Diskussion) MediaWiki Diskussion:Common.js#c-Jogo30-2014-08-10T14:35:00.000Z-Abschalten MV11Beantworten

Wikipedia ist keine Demokratie, das Meinungsbild eines, dass so oder so in eine Sackgasse führt. Ein zentrales Problem des MB war es ja, dass es von Gefühlen getragen wurde, und dass man Fakten wie die Weiterentwicklungen ignorierte. Frohes Schaffen — Boshomi ☕⌨☺  MediaWiki Diskussion:Common.js#c-Boshomi-2014-08-10T14:53:00.000Z-Jogo30-2014-08-10T14:35:00.000Z11Beantworten

<quetsch nach BK> :::: MIt dieser Argumentation führst du sämtliche Meinungsbilder, so wie die Selbstverwaltung der Wikimedia-Projekte, eines der Grundsätze, ad absurdum. -- Jogo30 (Diskussion) MediaWiki Diskussion:Common.js#c-Jogo30-2014-08-10T14:58:00.000Z-Jogo30-2014-08-10T14:35:00.000Z11Beantworten

Von mir gibt es keine finanzielle Unterstützung mehr. --84.226.187.197 MediaWiki Diskussion:Common.js#c-84.226.187.197-2014-08-10T14:56:00.000Z-Abschalten MV11 (ein ehemaliger Spender)Beantworten

Meinungsbilder insbesondere jene die nur einfache Mehrheit erfordern haben grundsätzlich keine Rechtskraft. Zuerst gelten die Grundprinzipien, Meinungsbilder haben sich unterzuordnen, und könne durch Einzelfallentscheidungen jederzeit overruled werden. Es sind Leitlinien, an denen man sich orientieren kann, aber nicht muss. Die fehlende Rechtskraft von Meinungsbildern ist dabei gewollt, um die Fortentwicklung sicherzustellen und übertriebene Regulierungswut abzudämpfen. Frohes Schaffen — Boshomi ☕⌨☺  MediaWiki Diskussion:Common.js#c-Boshomi-2014-08-10T15:31:00.000Z-84.226.187.197-2014-08-10T14:56:00.000Z11Beantworten

Deine Privatmeinung sei dir unbenommen, aber sie ist und bleibt nichts als deine Privatmeinung @Benutzer:Boshomi, denn es ist Konsens, dass Meinungsbilder verbindlich sind, auch der Entwickler hat sich daran zu halten. Das sind die Grundsätze unseres Projektes. Im übrigen ist trotz der im MB geforderten lediglichen einfachen Mehrheit, eine 2/3-Mehrheit locker zustande gekommen, somit ist selbst deine Privatmeinung erfüllt. --Jogo30 (Diskussion) MediaWiki Diskussion:Common.js#c-Jogo30-2014-08-10T15:55:00.000Z-Boshomi-2014-08-10T15:31:00.000Z11Beantworten

Nein, das ist falsch, Jogo30. "Meinungsbild" ist eigentlich die deutsche Übersetzung für englisch "Request for Comment", und es geht um die Stärke der Argumente, nicht um die Stärke der Stimmen !vote! (inklusive Sockenpuppen...). Erst seit ca. 2 Jahren wird auf deWP von einigen so getan, als sei ein Meinungsbild eine Volksabstimmung und Wikipedia eine Demokratie. Das ist aber nicht die ursprüngliche, und erfolgreiche Vorgehensweise, sondern ein Missverständnis. Wir haben bei Löschdiskussionen auch keine "Abstimmung" nach Stimmenzahl, sondern Abwägung der Argumente, und bei Artikeln wird ebenfalls nach sachlichen Argumenten entschieden, nicht nach Geschmack der Mehrheit. --Atlasowa (Diskussion) MediaWiki Diskussion:Common.js#c-Atlasowa-2014-08-10T16:11:00.000Z-Jogo30-2014-08-10T15:55:00.000Z11Beantworten

Wir arbeiten in der deutschen Wikipedia und sehen als solche (Konsens!) MBs für verbindlich, das können wir deshalb, weil eines der Grundsätze von Wikimedia-Projekten, die Selbstverwaltung des eigenen Projektes ist. Ein Vergleich mit Vorgehensweisen in anderen Projekten ist daher irrelevant. Die Löschdiskussion ist in der Tat keine Abstimmung, das bedeutet aber nicht, dass ein MB ebenfalls keine ist. WP:Wikipedia ist keine Demokratie bedeutet nicht, dass grundsätzlich keine demokratischen Prozesse stattfinden, sondern dass es Situationen gibt, in denen nicht demokratisch entschieden werden kann, ein MB gehört nicht dazu. -- Jogo30 (Diskussion) MediaWiki Diskussion:Common.js#c-Jogo30-2014-08-10T16:22:00.000Z-Atlasowa-2014-08-10T16:11:00.000Z11Beantworten

Jogo30, Deine Privatmeinung ist in der Sache falsch und wird auch durch Wiederholung nicht wahrer. EOD. --Atlasowa (Diskussion) MediaWiki Diskussion:Common.js#c-Atlasowa-2014-08-10T16:48:00.000Z-Jogo30-2014-08-10T16:22:00.000Z11Beantworten

Danke Benutzer:Atlasowa, exakt der Meinung bin ich auch. Das Ganze würde ich gerne noch etwas weiter ausführen, bzw. in Bezug darauf, dass die Umsetzung, die hier versucht wurde, vorzunehmen, die User quasi ins Gesicht schlägt, die den Medienbetrachter gerne Nutzern möchten (so einer bin ich auch...). Ich denke, dass keiner den MB in Frage stellt, bloß die, ich nenne es mal, voreilige Umsetzung dessen geht einfach in die falsche Richtung. Zudem (ich betrachte das mal rückblickend) wurde der Superprotect erst eingeführt, als hier auf der Seite ein Editwar entstand. Was daran dann noch sachlich sein soll, verstehe ich nicht. Daher verstehe ich aber die Schritte der WMF. Ich bin mir sicher, dass man mit einer sachlichen Diskussion vieles erreichen kann. Grüße --Florianschmidtwelzow (Diskussion) MediaWiki Diskussion:Common.js#c-Florianschmidtwelzow-2014-08-10T21:32:00.000Z-Atlasowa-2014-08-10T16:48:00.000Z11Beantworten

Was bei der unseligen Bildfilter-Geschichte damals (nach meiner Beobachtung) geholfen hat, war die konkrete Vorbereitung eines Forks. --Drahreg01 (Diskussion) ^3Wf MediaWiki Diskussion:Common.js#c-Drahreg01-2014-08-10T15:10:00.000Z-Abschalten MV11Beantworten

Was ich besonders übel finde: Abermals wird sich hinter einem "wir" versteckt: keine Übernahme persönlicher Verantwortung, keine Erklärung, wer hier auf wessen Veranlassung und auf Basis welcher Grundlage aktiv wird. Sozusagen die Funktion kommentarlos zurücksetzen mit selbst verliehenen Superrechten für die Foundation. --Magiers (Diskussion) MediaWiki Diskussion:Common.js#c-Magiers-2014-08-10T15:13:00.000Z-Drahreg01-2014-08-10T15:10:00.000Z11Beantworten

Die Supersperre (als Steigerung zur Vollsperre) sehe ich auch als heikel an, der Revert war trotzdem richtig. Das MB ist klar zugunsten eines Opt-In ausgegangen; ein komplettes Deaktivieren mit einem Bastelt-euch-doch-irgendwie-einen-JS-Hack ist aber keine Umsetzung des MB, sondern ein Vor-den-Kopf-stoßen der Abstimmenden. Entweder das MB wird so umgesetzt, wie dort im Vorschlag steht, oder eben gar nicht.

Im Übrigen kann ein MB über ein Softwarefeature nicht mehr sein als eine Bitte an die Foundation. —Morten Haan · Wikipedia ist für Leser da MediaWiki Diskussion:Common.js#c-Morten Haan-2014-08-10T16:09:00.000Z-Magiers-2014-08-10T15:13:00.000Z11Beantworten

Eine Bitte? Das sehe ich anders. Ich wiederhole mich, einer der Grundsätze von Wikimedia-Projekten ist, dass die Projekte sich selbst verwalten, das wird von Seiten WMF auch so protegiert, daher ist auch für die WMF ein Meinungsbild bindend. Mich hat niemanden vor den Kopf gestoßen, mit Ausnahme der WMF, die durch ihr Overruling nicht nur vor den Kopf stößt, sonder projektschädigend ist. -- Jogo30 (Diskussion) MediaWiki Diskussion:Common.js#c-Jogo30-2014-08-10T16:24:00.000Z-Morten Haan-2014-08-10T16:09:00.000Z11Beantworten

+1 (BK )@Morten Haan Mit welcher Begründung, mit welchen Recht kann es nur eine Bitte sein? Dazu hat es schließlich auch mal ein MB gegeben. Einzig ein Unvermögen für ein neues Feature unsererseits würde eine Bitte rechtfertigen. → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-10T16:32:00.000Z-Jogo30-2014-08-10T16:24:00.000Z11Beantworten

(BK) Die Software wird aber nunmal von der WMF verwaltet und kann somit nicht im Bereich der Selbstverwaltung der Community liegen. Zumindest diejenigen wurden vor den Kopf gestoßen, die sich klar für ein Opt-In entschieden haben.

Wäre es nicht eine Lösung, den JS-Code, welchen DaB in die Commons.js eingefügt hat, in ein Gadget einzufügen, das standardmäßig aktiviert ist? —Morten Haan · Wikipedia ist für Leser da MediaWiki Diskussion:Common.js#c-Morten Haan-2014-08-10T16:37:00.000Z-Jogo30-2014-08-10T16:24:00.000Z11Beantworten

Dieser spezielle Code nicht, da er nicht genau dem MB entspricht – ein Gadget, welches genau dieses umsetzt, wäre dagegen natürlich optimal. Die Frage ist nur, wer das basteln könnte, vielleicht könnten das ja Der Umherirrende und PerfektesChaos, sofern sie dazu bereit sind. --BHC (Disk.) MediaWiki Diskussion:Common.js#c-BeverlyHillsCop-2014-08-10T16:42:00.000Z-Morten Haan-2014-08-10T16:37:00.000Z11Beantworten

Man könnte sich jetzt die Mühe machen, gegen den Willen der WMF den MediaViewer zu deaktiveren, über Common.js, Gadgets oder andere Sachen, sofern aber auch das deaktivieren für angemeldete Benutzer nicht akzeptiert wird, bringt das nur mehr superprotect-Seiten, die Handlungsfähigkeit der WMF in dieser Hinsicht lahm zulegen, wird viel Kraft und Nerven kosten. Da halte ich mich gerne heraus. Der Umherirrende MediaWiki Diskussion:Common.js#c-Umherirrender-2014-08-10T16:49:00.000Z-BeverlyHillsCop-2014-08-10T16:42:00.000Z11Beantworten

Die Admins @MBq, Schniggendiller: sind bereits techn. in der Richtung des MV tätig geworden (PerfektesChaos ist leider, erstaunlicher Weise noch kein (Tech-) Admin, aber ich denke auch er würde sich da raushalten). → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-10T16:53:00.000Z-Umherirrender-2014-08-10T16:49:00.000Z11Beantworten

@Gadget (BHC): Um's nochmal deutlich zu sagen, man braucht hier keine besonderen JS-Kenntnisse, einfach eine Gadget-Seite erstellen, und nur diese eine Zeile genau wie hier in der Common.js einsetzen, fertig ist das Gadget!! → User: Perhelion 19:32, 10. Aug. 2014 (CEST) PS: und eine Seite für die Beschreibung: "Den Medienbetrachter deaktivieren.". Genaue Anleitung hier. → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-10T17:32:00.000Z-Umherirrender-2014-08-10T16:49:00.000Z11Beantworten

Warum sollten die Genannten das machen? Um Öl in den frisch entfachten Konflikt zu gießen? Das Meinungsbild war, wie man jetzt sehr deutlich sieht, miserabel vorbereitet, und man hatte offensichtlich keine mit der Foundation abgestimmte Vorgehensweise für den Erfolgsfall des MB ausgearbeitet. Das muss jetzt im Nachhinein per Machtkampf entschieden werden.  Frohes Schaffen — Boshomi ☕⌨☺  MediaWiki Diskussion:Common.js#c-Boshomi-2014-08-10T17:46:00.000Z-Perhelion-2014-08-10T17:32:00.000Z11Beantworten

Weil das die genaue Umsetzung des Opt-in des MB's wäre!! → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-10T17:48:00.000Z-Boshomi-2014-08-10T17:46:00.000Z11Beantworten

Dass die Mehrheit dem MB zugestimmt hat, ändert nichts an der Tatsache der miserablen Vorbereitung. Die Folge wären bloß wenig zukunftsfähige Alleingänge, ein Gang in eine erkennbare Sackgasse. Frohes Schaffen — Boshomi ☕⌨☺  MediaWiki Diskussion:Common.js#c-Boshomi-2014-08-10T17:55:00.000Z-Perhelion-2014-08-10T17:48:00.000Z11Beantworten

Die Frage ist nur wer was miserabel vorbereitet hat. Die WMF mit ihrem MV Alleingang (notfall mit dem Superprotect-Knüppel) oder diejenigen die das MB vorbereitet haben, als das Kind bereits schon in den Brunnen gefallen ist. --Alchemist-hp (Diskussion) MediaWiki Diskussion:Common.js#c-Alchemist-hp-2014-08-10T18:04:00.000Z-Boshomi-2014-08-10T17:55:00.000Z11Beantworten

Mieserabel war beispielsweise, dass man die Foundation nicht angemessen in die Vorbereitung des MB miteinbezogen hat, keine im Konsens ausgearbeiteten Umsetzungsvorschläge bereit hielt und keine Vision entwickelte wie der Mediaviewer aussehen sollte. Nun bleibt eben nichts übrig als dieser Machtkampf, denn ein leichtfertiges Einlenken der Foundation hätte weitreichende negative Auswirkungen auf das Gesamtprojekt.  Frohes Schaffen — Boshomi ☕⌨☺  MediaWiki Diskussion:Common.js#c-Boshomi-2014-08-10T18:15:00.000Z-Alchemist-hp-2014-08-10T18:04:00.000Z11Beantworten

Offensichtlich nehmen sich beide Seiten nicht viel wenn ein Zitat MB „wird als technisch unausgereift bewertet[es Feature]“ dadurch abgeschaltet werden soll in dem man eine technisch unausgereifte Lösung wählt („Das generelle Abschalten kommt dem MB-Ergebnis näher als ihn komplett anzulassen.“). Diese Ironie. --Mps、かみまみた^Disk. MediaWiki Diskussion:Common.js#c-Mps-2014-08-10T18:17:00.000Z-Alchemist-hp-2014-08-10T18:04:00.000Z11Beantworten

Vorlage:Smiley/Wartung/smile   Frohes Schaffen — Boshomi ☕⌨☺  MediaWiki Diskussion:Common.js#c-Boshomi-2014-08-10T18:29:00.000Z-Mps-2014-08-10T18:17:00.000Z11Beantworten

Gut, das es noch nicht anders probiert wurde. Vll. erst informieren bevor hier Schwachsinn verbreitet wird? Diese Ironie... --217.87.205.179 (MediaWiki Diskussion:Common.js#c-217.87.205.179-2014-08-10T19:10:00.000Z-Boshomi-2014-08-10T18:29:00.000Z11, Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)Beantworten

Gut, das mit dem Gadget ist dann auch gestrichen. → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-10T19:26:00.000Z-217.87.205.179-2014-08-10T19:10:00.000Z11Beantworten

<nach-links-rück> Das heißt dann, dass das MB nicht umsetzbar ist? —Morten Haan · Wikipedia ist für Leser da MediaWiki Diskussion:Common.js#c-Morten Haan-2014-08-10T19:35:00.000Z-Abschalten MV11Beantworten

Sagen wir mal so - die WMF tut alles damit es nicht umsetzbar ist. -- Gerold (Diskussion) MediaWiki Diskussion:Common.js#c-Gerold Rosenberg-2014-08-10T21:36:00.000Z-Morten Haan-2014-08-10T19:35:00.000Z11Beantworten

Genauer: Die WMF hindert mit ihrer Hoheit über Server und Software die örtliche Community an der Umsetzung des Meinungsbildes. Meiner Einschätzung nach steht es hier Hoheit über Technik vs. Hoheit über Inhalt. Nun, die Technik kann man austauschen … —‏הגות‎⁴¹⁴ MediaWiki Diskussion:Common.js#c-Viciarg-2014-08-11T05:25:00.000Z-Morten Haan-2014-08-10T19:35:00.000Z11Beantworten

WMF soll nochmal neu bewerten. Vielteich setzt nach dem ganzen Drama der Verstand dort ein. --Steinsplitter (Disk) MediaWiki Diskussion:Common.js#c-Steinsplitter-2014-08-11T07:16:00.000Z-Viciarg-2014-08-11T05:25:00.000Z11Beantworten

Eine Komplettbschaltung des MV ist keine Umsetzung des Meinungsbildes (aber nach dem vorstehend verlinkten Statment hätte die WMF wohl auch eine Umsetzung des MB verhindert ...) --PM3 MediaWiki Diskussion:Common.js#c-PM3-2014-08-11T16:38:00.000Z-Steinsplitter-2014-08-11T07:16:00.000Z11Beantworten

 Info: Zufälliger Weise wurde jetzt genau diese Option als Gadget-Einstellungen (auf Commons) erstellt und zudem freundlicher Weise ein Hinweisbanner.[4] (PS: allerdings ebenfalls als Hack, da sich die WMF wohl Zeit lässt und wie von Krinkle angemerkt dies eher über PHP vorgesehen ist.) → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-12T13:40:00.000Z-Steinsplitter-2014-08-11T07:16:00.000Z11Beantworten

Hallo JEissfeldt und Eloquence, wenn die Kinder nicht artig sind, dann müssen die Eltern knallhart durchgreifen, schon klar. Ihr habt einen nachteiligen Eingriff in die Funktionsweise des Projekts per Mutti-Zugriff knallhart abgewiegelt, um die volle Funktionsfähigkeit des Projekts für alle Benutzer sicherzustellen. Eine Frage gestattet ihr mir aber sicherlich: Ich nutze ein Netbook, ihr wisst schon, die Geräte für die damals eigens im Monobook die Suchzeile direkt unter das Logo gewandert ist. Wenn ich (beispielsweise) im Artikel Köln auf das schöne Panorama von der Deutzer Brücke klicke, dann wird mir zwar nach ein paar Sekunden das ganze Bild gezeigt, allerdings in der gleichen Größe. Der Rundblick vom Dortmunder Fernsehturm wird mir sogar verkleinert dargestellt. Eine Zoomfunktion fehlt. Ist das tatsächlich „die volle Funktionsfähigkeit“, die ihr mir und allen anderen Nutzern mit derart mobilen Computern zur Verfügung stellen könnt? Vorschlag zur Güte: Die WMF hört weniger auf ihre BWLer und mehr auf die Entwickler und aktiviert neue Funktionen erst dann, wenn sie keine Verschlechterung zum Ist-Zustand darstellen. Dann ist auch die Community weniger bockig. -- 32X MediaWiki Diskussion:Common.js#c-32X-2014-08-12T06:52:00.000Z-Abschalten MV11 PS: „Wikipedia ist ein Projekt zum Aufbau einer Enzyklopädie aus freien Inhalten“. Die Funktionsweise/Funktionsfähigkeit des Projekts ist nicht beeinträchtigt, wenn schlechte Software deaktiviert wird, solange die Enzyklopädie noch lesbar ist.Beantworten

+1 → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-12T13:40:00.000Z-32X-2014-08-12T06:52:00.000Z11Beantworten

Hi! I want to let you know that in near future badges will be deployed on Wikidata and the Wikipedias. They help us with displaying the good and featured article icons next to the sitelinks and will replace the javascript hack which is used at the moment together with the Link GA and Link FA templates. To avoid an overlap where the current system and the new feature conflict, I will add a minor fix to your Common.js which adds the class names to the interwiki links. This is part of my task as a global edit interface editor for the Wikidata team. Thanks, Bene* (Disk) MediaWiki Diskussion:Common.js#c-Bene*-2014-08-11T19:25:00.000Z-Announced JavaScript change for badges implementation11Beantworten

Prima. Nur zu! --Howwi (Diskussion) MediaWiki Diskussion:Common.js#c-Howwi-2014-08-11T19:30:00.000Z-Bene*-2014-08-11T19:25:00.000Z11Beantworten

Hat Bene* überhaupt das Recht unsere MediaWiki:Common.js zu bearbeiten? Ich meine, die ist ja jetzt superprotected und er gehört nicht zur Staff-Gruppe. --BHC (Disk.) MediaWiki Diskussion:Common.js#c-BeverlyHillsCop-2014-08-11T19:44:00.000Z-Howwi-2014-08-11T19:30:00.000Z11Beantworten

Dann wird er doch merken das er nichts machen kann. --Alchemist-hp (Diskussion) MediaWiki Diskussion:Common.js#c-Alchemist-hp-2014-08-11T20:07:00.000Z-BeverlyHillsCop-2014-08-11T19:44:00.000Z11Beantworten

Erstmal sorry, dass ich hier auf Englisch geschrieben habe, ich habe nur die gleiche Nachricht auf allen Projekten verteilt.

Dieses Problem sehe ich jetzt aber auch, denn auch als global edit interface editor kann ich natürlich keine super-protected Seiten bearbeiten. Allerdings finde ich, dass hier sowieso einiges aus dem Ruder gelaufen ist, sowohl bei der Foundation als auch bei der Community. -- Bene* (Disk) MediaWiki Diskussion:Common.js#c-Bene*-2014-08-11T21:45:00.000Z-Alchemist-hp-2014-08-11T20:07:00.000Z11Beantworten

Ich habe ja noch die Hoffnung, dass, wenn ein JavaScript-Code für die korrekte Opt-in-Variante gefunden und implementierbar ist, dies auch getan wird und die Seite ihren superprotect-Schutz wieder verlieren wird … Grüße, —DerHexer (Disk., Bew.) MediaWiki Diskussion:Common.js#c-DerHexer-2014-08-11T21:47:00.000Z-Bene*-2014-08-11T21:45:00.000Z11Beantworten

Nach dieser klaren Absage? Ne, das wäre eine Kapitulation und aufgeben erden Erik und co. nicht wollen. --BHC (Disk.) MediaWiki Diskussion:Common.js#c-BeverlyHillsCop-2014-08-11T21:55:00.000Z-DerHexer-2014-08-11T21:47:00.000Z11Beantworten

@Bene*: Was genau hast du denn vor zu ändern? Meiner Meinung nach sollten wir den lokalen JavaScript-Code zu diesem Feature schnellstmöglich loswerden (möglichst komplett), aber es müsste geklärt werden, welche Icons benutzt werden sollen (die Icons sind in MediaWiki:Common.css und MediaWiki:Cologneblue.css festgelegt). --Entlinkt (Diskussion) MediaWiki Diskussion:Common.js#c-Entlinkt-2014-08-11T21:52:00.000Z-Bene*-2014-08-11T21:45:00.000Z11Beantworten

Der JavaScript Code wird erstmal unabhängig vom Style so angepasst, dass sich die beiden Systeme nicht überschreiben. Dadurch vermeiden wir eine Übergangsphase, in der keine Icons sichtbar sind, oder sich die Systeme überlappen. Das ist erstmal der wichtigste Schritt, damit wir schließlich den Code ganz entfernen können, wenn die Migration der Link GA und Link FA Vorlagen abgeschlossen ist. -- Bene* (Disk) MediaWiki Diskussion:Common.js#c-Bene*-2014-08-11T22:04:00.000Z-Entlinkt-2014-08-11T21:52:00.000Z11Beantworten

Gemäß dieses Vorschlags plädiere ich unabhängig von der angeheizten Diskussion dafür, diese Lösung zu implementieren. Imho kann man auch noch darüber nachdenken, den MediaViewer für unangemeldete Benutzer anzuschalten, da er ja für genau diese Zielgruppe design wurde. Falls jemand diese Lösung implementieren will und es genug Unterstützer gibt, schlage ich folgende Schritte vor:

/**
 * Deaktivierung des MediaViewers für angemeldete Benutzer,
 * kann in den Einstellungen wieder angeschaltet werden,
 * indem das Helferlein "MediaViewer ausschalten" deaktiviert wird.
 */
( function( mw ) {
	'use strict';

	if ( mw.config.get( 'wgUserName' ) ) {
		mw.config.set( 'wgMediaViewerOnClick', false );
	}

} )( mediaWiki );

Dieser Code könnte in die Seite MediaWiki:Gadget-MediaViewer ausschalten.js kopiert werden und dann in MediaWiki:Gadgets-definition als Default-Gadget eingefügt werden. Dann könnten Leser den MediaViewer immer noch nutzen und angemeldete Benutzer ihn einfach wieder einschalten. Ich hoffe, mit dieser Lösung können wir zumindest technisch einen Kompromiss finden. Mit den besten Absichten, -- Bene* (Disk) MediaWiki Diskussion:Common.js#c-Bene*-2014-08-12T14:58:00.000Z-Lösungsvorschlag11Beantworten

War es nicht das Ergebnis des Meinungsbildes, dass der Mediaviewer für alle Benutzer abgeschaltet werden soll? --Drahreg01 (Diskussion) ^3Wf MediaWiki Diskussion:Common.js#c-Drahreg01-2014-08-12T15:57:00.000Z-Bene*-2014-08-12T14:58:00.000Z11Beantworten

Der Vorschlag von Bene* ist im Gegensatz zu der Aktion von vorgestern durch das Meinungsbild gedeckt; es wäre zumindest mal eine Teilumsetzung als erster Schritt. Für eine vollständige Umsetzung scheint es ja bislang keine technische Möglichkeit zu geben. Ja, ich weiß dass diese Möglichkeit von der WMF verhindert wird, dieses Wissen bringt uns nur praktisch nicht weiter. --PM3 MediaWiki Diskussion:Common.js#c-PM3-2014-08-12T16:04:00.000Z-Drahreg01-2014-08-12T15:57:00.000Z11Beantworten

+1 Zudem das nicht explizit im MB genannt wurde, eher im Gegenteil, „kann aber von angemeldeten Benutzern... aktiviert werden“ → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-12T16:17:00.000Z-PM3-2014-08-12T16:04:00.000Z11Beantworten

(BK) Ich halte es für unklug, jetzt der WMF ihren Willen zu geben, bevor es eine Äußerung seitens der WMF gibt, wie man in Zukunft mit dem Community-Willen umzugehen gedenkt. Just my 2c. --Drahreg01 (Diskussion) ^3Wf MediaWiki Diskussion:Common.js#c-Drahreg01-2014-08-12T16:18:00.000Z-PM3-2014-08-12T16:04:00.000Z11Beantworten

@Drahreg: Nein, im MB wurde klar auf ein Opt-In entschieden. Wo steht, dass wir damit der WMF ihren Willen geben?

@Perhelion: Durch deaktivieren des Gadgets wird der MV aktiviert. Wo ist das Problem? —Morten Haan · Wikipedia ist für Leser da MediaWiki Diskussion:Common.js#c-Morten Haan-2014-08-12T16:24:00.000Z-Drahreg01-2014-08-12T16:18:00.000Z11Beantworten

@Morten Haan: Es geht um Nichtangemeldete-Benutzer (IP's). Für mich hat der Vorschlag des MB klar impliziert dass diese nicht gemeint sind (schon alleine da ein Opt-In für diese gar nicht erwähnt wurde). → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-12T16:34:00.000Z-Morten Haan-2014-08-12T16:24:00.000Z11Beantworten

(BK) Ich fände es besser, hier bei der Sache bleiben statt ad organisationem zu argumentieren. --PM3 MediaWiki Diskussion:Common.js#c-PM3-2014-08-12T16:35:00.000Z-Drahreg01-2014-08-12T16:18:00.000Z11Beantworten

@Perhelion: Ich verstehe das MB eindeutig so, dass der MV für alle Benutzer standardmäßig abgeschaltet werden soll; die angemeldeten werden dann als Ausnahme von der Regel genannt, weil sie den MV wieder einschalten können sollen. --PM3 MediaWiki Diskussion:Common.js#c-PM3-2014-08-12T16:53:00.000Z-PM3-2014-08-12T16:35:00.000Z11Beantworten

(BK) Wenn der MV auf Opt-In gestellt wird, dann können IPs diesen nicht verwenden. Deshalb habe ich gegen den MB-Vorschlag gestimmt. —Morten Haan · Wikipedia ist für Leser da MediaWiki Diskussion:Common.js#c-Morten Haan-2014-08-12T16:55:00.000Z-PM3-2014-08-12T16:35:00.000Z11Beantworten

(BK) Ja ich ebenfalls, ähm formal... @PM3: Wenn man das Wort Benutzer alleine verwendet steht es eindeutig für angemeldete Benutzer, da IP's zwar indirekt auch Benutzer sind aber niemals alleine so bezeichnet werden. Da steht kein alle! → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-12T16:59:00.000Z-Morten Haan-2014-08-12T16:55:00.000Z11Beantworten

Siehe WP:IP. --PM3 MediaWiki Diskussion:Common.js#c-PM3-2014-08-12T17:01:00.000Z-Perhelion-2014-08-12T16:59:00.000Z11Beantworten

Vgl. Amerikaner → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-12T17:05:00.000Z-PM3-2014-08-12T17:01:00.000Z11Beantworten

Die Formulierung in dem MB ist logisch eindeutig. Da steht „Der Medienbetrachter wird standardmäßig deaktiviert“, und dann kommt eine Ausnahme für angemeldete Benutzer. Unschön ist allerdings, dass eine echte Pro/Contra-Liste fehlt, in der man nochmal explizit darauf hingewiesen hätte dass die IPs ihn dann nicht mehr nutzen können. War fies konstruiert das MB. --PM3 MediaWiki Diskussion:Common.js#c-PM3-2014-08-12T17:18:00.000Z-Perhelion-2014-08-12T17:05:00.000Z11Beantworten

Könnte für IPs nicht ein Cookieparameter gesetzt werden um den MV zu aktivieren? --Anselmikus (Diskussion) MediaWiki Diskussion:Common.js#c-Anselmikus-2014-08-12T17:06:00.000Z-Morten Haan-2014-08-12T16:55:00.000Z11Beantworten

MediaWiki:Vector.js und MediaWiki:Monobook.js verwenden anstatt common.js. --Steinsplitter (Disk) MediaWiki Diskussion:Common.js#c-Steinsplitter-2014-08-12T17:20:00.000Z-Anselmikus-2014-08-12T17:06:00.000Z11Beantworten

Dann gibt es noch MediaWiki:Group-user.js --Steinsplitter (Disk) MediaWiki Diskussion:Common.js#c-Steinsplitter-2014-08-12T17:27:00.000Z-Steinsplitter-2014-08-12T17:20:00.000Z11Beantworten

Unangemeldete Benutzer können kein Monobook einstellen und verwenden, sie bekommen immer Vector zu sehen. Die Vector.js würde also ausreichen. --Winternacht MediaWiki Diskussion:Common.js#c-Winternacht-2014-08-12T19:25:00.000Z-Steinsplitter-2014-08-12T17:27:00.000Z11Beantworten

@Steinsplitter: Und damit quasi heraufbeschwören, dass auch diese Seiten (und ggf., je nachdem was da noch so kommt der komplette MediaWiki Namensraum) für die Bearbeitung von Nutzern mit Superprotect-Recht begrenzt werden? Nur so ein Gedanke, dass weitere Eskalationen hier (von beiden Seiten!!!) mit Sicherheit keinerlei zufriedenstellende Lösung herbeiführen wird --Florianschmidtwelzow (Diskussion) MediaWiki Diskussion:Common.js#c-Florianschmidtwelzow-2014-08-12T21:05:00.000Z-Winternacht-2014-08-12T19:25:00.000Z11Beantworten

Ich denke man sollte damit erst mal zur WMF gehen und versuchen, sich zu einigen. Es wäre etwas anderes als die Komplettabschaltung vorgestern, und die müssten inzwischen auch gemerkt haben dass sie die Lage falsch eingeschätzt haben. Wenn man sich nicht einig wird kann man sich immer noch Gedanken über einen Plan B machen. --PM3 MediaWiki Diskussion:Common.js#c-PM3-2014-08-12T21:56:00.000Z-Florianschmidtwelzow-2014-08-12T21:05:00.000Z11Beantworten

Dazu bedarf es einer Softwareänderung. —Morten Haan · Wikipedia ist für Leser da MediaWiki Diskussion:Common.js#c-Morten Haan-2014-08-12T17:22:00.000Z-Anselmikus-2014-08-12T17:06:00.000Z11Beantworten

Sicher? Der daktivierungscode sollte auch in den oben genannten MediaWiki's arbeiten. --Steinsplitter (Disk) MediaWiki Diskussion:Common.js#c-Steinsplitter-2014-08-12T17:27:00.000Z-Morten Haan-2014-08-12T17:22:00.000Z11Beantworten

Im MB wurde entschieden, dass der MV deaktiviert wird und dass angemeldete diesen aktivieren können. Das ist zwar nicht meine Meinung, wurde aber nunmal so entschieden. Daher ist ein Gadget sinnvoll, welches standardmäßig für alle aktiviert ist und von Angemeldeten ausgeschaltet werden kann und das den MV deaktiviert. —Morten Haan · Wikipedia ist für Leser da MediaWiki Diskussion:Common.js#c-Morten Haan-2014-08-12T18:09:00.000Z-Steinsplitter-2014-08-12T17:27:00.000Z11Beantworten

@Code: Anhand des Bsp. auf Commons wurde jetzt (einfach) ersichtlich das Gadgets doch für IP's ausgenommen werden können[5] (steht auch hier im Ansatz in einer Anleitung. Das hatten bei der letzten [Wikipedia:Administratoren/Anfragen/Archiv/2014/Juli#MediaWiki:Gadget-Direct-link-to-Commons.js bitte für unangemeldete Benutzer deaktivieren AA] hier die beiden Admins nicht gewusst.) Also kann der ganze Code sich wieder auf die eine Zeile, wie hier in der Common.js beschränken. → User: Perhelion MediaWiki Diskussion:Common.js#c-Perhelion-2014-08-12T22:25:00.000Z-Bene*-2014-08-12T14:58:00.000Z11Beantworten