MediaWiki Diskussion:Common.js

Automatische Archivierung

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.

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Funktion erstellt: History-Einträge zusammenfassen

Das Tool fasst Beiträge von gleichen Autoren zusammen...

...und klappt bei Bedarf auch die Unterversionen aus

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} 13:11, 6. Okt. 2011 (CEST)

Ich würde daraus ein eigenständiges Gadget machen - dann kann sich jeder (angemeldete) Benutzer entscheiden, ob er#s möchte oder nicht... --Guandalug 13:14, 6. Okt. 2011 (CEST)

Wie geht das? :) --_{Nightfly85 | Disk} 13:26, 6. Okt. 2011 (CEST)

Ist nur was für Admins (wegen der fehlenden Schreibrechte anderer im MediaWiki-Namensraum). Ich schau mir deinen Code mal an.... --Guandalug 14:34, 6. Okt. 2011 (CEST)

Wäre das nicht sogar was, was direkt in die MediaWiki Software integriert werden könnte? --Stefan 14:47, 6. Okt. 2011 (CEST)

Jo... aber DAS macht dann wer anders ;) --Guandalug 14:58, 6. Okt. 2011 (CEST)

Aber irgendwie müssen die Entwickler ja drauf aufmerksam werden. ;) --Stefan 15:26, 6. Okt. 2011 (CEST)

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 18:47, 6. Okt. 2011 (CEST)

sehr cool, sowas wollte ich immer serverseitig haben, bin aber unerklärlicherweise nie drauf gekommen, das auf dem client zu machen. klasse! -- ∂ 22:11, 6. Okt. 2011 (CEST)

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 00:41, 7. Okt. 2011 (CEST)

Update

Screenshot

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} 01:10, 7. Okt. 2011 (CEST)

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 09:27, 7. Okt. 2011 (CEST)

Danke für die Tipps. Habe meine JS-Datei aktualisiert. --_{Nightfly85 | Disk} 10:05, 7. Okt. 2011 (CEST)

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 11:51, 7. Okt. 2011 (CEST)

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} 11:56, 7. Okt. 2011 (CEST)

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 16:39, 7. Okt. 2011 (CEST)

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} 16:52, 7. Okt. 2011 (CEST)

+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 17:06, 7. Okt. 2011 (CEST)

• 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} 17:12, 7. Okt. 2011 (CEST)

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 19:52, 7. Okt. 2011 (CEST)

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} 23:58, 7. Okt. 2011 (CEST)

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 00:14, 8. Okt. 2011 (CEST)

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} 01:49, 8. Okt. 2011 (CEST)

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} 01:49, 8. Okt. 2011 (CEST)

Irgendeine Chance, dass das "ofiziell" wird? Also für alle als autoamtisch aktives Feature? Finde das extrem nützlich. --Stefan 16:09, 7. Nov. 2011 (CET)

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, 15:53, 8. Nov. 2011 (CET)

+1 --Stefan 15:40, 8. Nov. 2011 (CET)

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 16:08, 8. Nov. 2011 (CET)

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} 02:57, 14. Nov. 2011 (CET)

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} 03:01, 14. Nov. 2011 (CET)

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, 19:41, 14. Nov. 2011 (CET)

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 17:24, 22. Nov. 2011 (CET)

Also beispielsweise alle nicht mehr aktuellen Versionen in grau darstellen oder grau hinterlegen? --Diwas 21:04, 22. Nov. 2011 (CET)

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 00:15, 23. Nov. 2011 (CET)

Ach sorum war das, da hab ich wohl was verwechselt oder einfach falsch in Erinnerung gehabt. --Diwas 02:46, 23. Nov. 2011 (CET)

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 13:56, 15. Mai 2012 (CEST)

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 17:48, 15. Mai 2012 (CEST)

Viiiiieeeelen Dank! --Nightfly85 | _Disk 18:21, 15. Mai 2012 (CEST)

Vorschlag: ordinal unsortierbare Spalte in Tabellen

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\^☺☹ 06:57, 2. Jan. 2013 (CET)

Öhm, hallo. Liest hier keine mit? Ich hätte schon gern 'nen Kommentar bevor ich mutig bin ;) --APPER\^☺☹ 08:39, 11. Jan. 2013 (CET)

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 09:52, 11. Jan. 2013 (CET)

Gibt es da einen Phabricator-Task zum Thema? --Leyo 14:24, 6. Mär. 2017 (CET)

Give search results even when page doesn't exist

Screenshot of the Earth test search, with this script adding links to Wikidata, Reasonator, Commons, and Wikipedia.

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 10:02, 12. Dez. 2013 (CET) (comments, translations and last instructions)

Siehe dazu auch Wikipedia:Fragen zur Wikipedia#Roter Interwikilink, wo ein Einbau befürwortet wird. Wenn niemand was dagegen hat, könnte es ja demnächst aktiviert werden. NNW 15:48, 9. Jul. 2015 (CEST)

@NordNordWest: Dieses Skript wir schon seit einiger Zeit in der Esperantowikipedia genutzt. Ich weiß aber nicht, welcher Admin es dort in eo:MediaWiki:Common.js eingebaut hatte. --Tlustulimu (Diskussion) 16:27, 9. Jul. 2015 (CEST)

Sörwiß. NNW 16:32, 9. Jul. 2015 (CEST)

Also, das vorgeschlagene importScriptURI schreiben wir hier ganz sicher nicht rein.

en:MediaWiki:Wdsearch.js gucke ich mir die Tage mal näher an. Ist etwas komplexer.

Wer sowas ganz dringend haben möchte, kann es sich jederzeit selbst aktivieren.

Generell bauen wir sowas ohnehin nicht mehr in diese Common.js hier ein, sondern nur noch unter Gadgets, wo es angemeldete Benutzer auch leicht deaktivieren könnten.

VG --PerfektesChaos 16:33, 9. Jul. 2015 (CEST)

@PerfektesChaos: Die Idee mit dem Gadget finde ich gut. Komisch, daß ich da nicht selbst drauf gekommen bin, obwohl in den drei Wikipedien, wo ich Admin bin, schon einige Gadgets erstellt habe. Wie sieht denn so etwas als Gadget aus? Gruß --Tlustulimu (Diskussion) 19:07, 9. Jul. 2015 (CEST)

• Eine einfache Syntaxanalyse offenbart im Ziel-Skript zunächst zehn Schlampigkeiten bzw. Kodierungsmängel; darüberhinaus einen schweren Syntaxfehler und reihenweise laienhafte Programmierpraktiken.
  • Diese Version hat noch nie jemand zu kompilieren versucht, oder irgendeine Version syntaktisch analysiert; soweit doch, wurde erfolglos versucht, die Fehlerwarnungen zu unterdrücken.
• Auf gar keinen Fall darf sowas zwangsweise und unausweichlich von unserer Common.js eingebunden werden.
  • Obendrein nehmen wir nichts größeres Neues mehr in unsere Common.js auf, sondern lagern es vielmehr perspektivisch in separate Module aus.
  • Im Idealfall ist zum Schluss unsere Common.js fast leer, oder enthält nur noch wenige Konfigurationszeilen und einen Universal-Algorithmus zur situationsabhängigen Aktivierung von ausgelagerten Einzelaufgaben gemäß einer Datentabelle.
• Ob es gewünscht und ratsam ist, dieses Werk offiziell in unseren Kanon aufzunehmen, werde ich nicht entscheiden. Das muss der Admin verantworten und anschließend weiter pflegen und betreuen, der das einfügt.
• Wenn es denn so sein soll, sind folgende Schritte auszuführen:
  1. Deutschsprachige Doku unter Wikipedia:Technik/Skin/Gadgets/wdsearch anlegen.
     • In der inhaltlichen Gliederung kann man sich weitgehend an Wikipedia:Technik/Skin/Gadgets/wikEd halten. Die macht in etwa den gleichen Vorgang, nur zu einer völlig anderen Thematik.
     • Allerdings verweist jene hinsichtlich der Funktionsbeschreibung auf Wikipedia:Technik/Text/Edit/wikEd – das müsste in diesem Fall integriert werden, so wie bei Wikipedia:Technik/Skin/Gadgets/Vorlagenmeister.
  2. Danach kann zur Aktivierung so vorgegangen werden wie unter Wikipedia:Technik/Skin/Gadgets beschrieben.
     • Dabei kann man sich wieder an wikEd anlehnen.
     • @Tlu: Das müsste alle deine Fragen beantworten können.
  3. Der JS-Code sähe, anders als anderen Stellen dargestellt, wie folgt aus:

/// w:de:MediaWiki:Gadget-wdsearch.js  2015-07-10
/*jshint curly:true, eqeqeq:true, latedef:true, laxbreak:true,
         strict:true, trailing:true, undef:true                        */
/*global window:false                                                  */

( function ( mw ) {
   "use strict";
   var env = mw.config.get( [ "wgArticleId",
                              "wgCanonicalSpecialPageName" ] );
   if ( env.wgCanonicalSpecialPageName === "Search"   ||
        ! ( env.wgArticleId  ||  env.wgCanonicalSpecialPageName ) ) {
      mw.loader.load( "https://en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.js&action=raw&bcache=1&maxage=3600&ctype=text/javascript" );
   }
   mw.loader.state( "ext.gadget.wdsearch", "ready" );
}( window.mediaWiki ) );

LG --PerfektesChaos 00:04, 13. Jul. 2015 (CEST)

Magst du den „schweren Syntaxfehler“ nicht unter en:MediaWiki talk:Wdsearch.js melden, so dass dieser behoben werden kann? --Leyo 00:33, 13. Jul. 2015 (CEST)

ProjektLinks

Ich habe hier für den Abschnitt ProjektLinks eine neue Implementierung, die auch Live preview unterstützt. --Fomafix (Diskussion) 09:02, 2. Apr. 2014 (CEST)

/*
## 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
			);
		} );
	} );
} );

Tuning und Struktur

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 09:52, 2. Apr. 2014 (CEST)

projectLinks benötigt keine globalen Variablen. Ein Anlegen von mw.libs.dewiki.projectLinks ist daher nicht notwendig. --Fomafix (Diskussion) 10:12, 2. Apr. 2014 (CEST)

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 11:05, 2. Apr. 2014 (CEST)

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) 13:23, 2. Apr. 2014 (CEST)

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) 09:40, 3. Apr. 2014 (CEST)

Zu mw.util.$content habe ich Bug 63466 aufgemacht. --Fomafix (Diskussion) 11:53, 3. Apr. 2014 (CEST)

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 20:56, 3. Apr. 2014 (CEST)

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 20:22, 3. Apr. 2014 (CEST)

en:MediaWiki:Gadgets-definition, commons:MediaWiki:Gadgets-definition und mw:MediaWiki:Gadgets-definition verwenden rights=hidden|hidden zum verstecken. --Fomafix (Diskussion) 20:40, 3. Apr. 2014 (CEST)

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 20:56, 3. Apr. 2014 (CEST)

2 Jahre später kein Ergebnis aus diesem Diskussionsstrang. Soll daraus nochmal etwas werden?

Meiner Meinung nach ist eine realistische Chance für Ergebnisse gegeben, wenn man kleine Schritte vereinbart. Ich würde deshalb vorschlagen, als Erstes die sowieso schon in separate Seiten ausgelagerten Codeteile in hidden-Gadgets umzuwandeln. Das sollte keine große Sache sein. Spielraum gibt es hier eigentlich nur bei den Namen. --Entlinkt (Diskussion) 02:46, 21. Apr. 2016 (CEST)

Sehr gern.

• MediaWiki:Onlyifuploading.js → Gadget-onUpload
  • Ist von Schnark und aktuell; nur noch kapseln.
  • hidden
• MediaWiki:Common.js/watchlist.js → Gadget-watchlistMessage
  • hidden
  • Komplettsanierung erforderlich:
    • document.cookie
    • globale dismissWatchlistMessage
    • javascript:dismissWatchlistMessage ist teilweise schon von Browsern unterbunden.
    • halb DOM, halb jQuery
    • Ein Cookie pro Watchlist-Message ist auch archaisch. Heutzutage schreibt man in persistenten lokalen sessionStorage (Web Storage), während Cookies mit jedem Seitenabruf an den Server übertragen werden.
    • Das mit dem Raufzählen von Nummern ist auch antik; ich würde eine id="watchlist-message-BeliebigesSchlagwort" setzen. Weil nur eine einzige brandaktuelle Nachricht angezeigt wird, muss man sich nicht die lokal bis zu 5 oder 10 frischesten freien Bezeichner merken, sondern nur, ob man den brandaktuellsten schon gesehen hat.
  • Es wäre heutzutage möglich, die Existenz einer ungelesenen watchlistMessage erst zu prüfen und den HTML-Code nur einzublenden, wenn es eine ungelesene Nachricht gibt. Die sehen dann allerdings die JS-Deaktivierten nicht. Hingegen gäbe es für Interessierte die Möglichkeit, das Teil standardmäßig per CSS auszublenden, bei einer ungelesenen Nachricht jedoch aktiv wieder einzublenden, indem statt id die class als Selektor genutzt würde.
  • Würde ich auf BETA völlig neu schreiben und vorstellen; aber erst in einigen Wochen.
  • Siehe auch Wikipedia:Technik/Skin/MediaWiki#Aktuelles – anscheinend die einzige Doku bislang.
• MediaWiki:Onlyifediting.js → Gadget-editsourceInsertstrings
  • Noch nicht einmal hidden, sondern ganz normal sichtbar zum opt-out, somit default.
  • Die Abfrage, ob es benötigt wird (Quelltextbearbeitung), würde ich dann in ein sichtbares Mini-Gadget voranstellen und im Erfolgsfall den jetzigen Code als in der Tat hidden im minimierten und versionierten Paket mittels ResourceLoader nachziehen. VE-Nutzer und Nur-Leser laden das Paket wie bisher nie herunter.
  • Würde ich codierungstechnisch aktualisiert auf BETA anpassen und vorstellen; aber erst in einigen Wochen.
    • Müsste zumindest gekapselt werden; stellt zurzeit eine var charinsert in den globalen Namensraum.
    • Ist komplett in DOM geschrieben; das würde ich dann als jQuery-frei auch in der Kapselung zum Ausdruck bringen.
• Die neuen Seiten wären von BETA hierzuwiki neu anzulegen; nach erfolgter erfolgreicher Umstellung die bisherigen Versionsgeschichten dranbamseln und die alten Seiten löschen.
  • Diskussionen gehen nach WD: an die Doku.

Tja, mal so eben fünf oder zehn Jahre altes Zeugs nur mit einem neuen Seitennamen versehen ist nur die halbe Miete; wenn schon ein deutlicher Umbruch, dann sollte das auch in die Gegenwart beamen.

LG --PerfektesChaos 14:47, 21. Apr. 2016 (CEST)

OK, ich sehe ein, dass das wohl nur bei MediaWiki:Onlyifuploading.js ohne größere Codeänderungen geht.

@Schnark: Was hieltest du davon, MediaWiki:Onlyifuploading.js nach MediaWiki:Gadget-onUpload.js zu verschieben und hier mittels mw.loader.load('ext.gadget.onUpload'); zu laden? Ganz ehrlich, allzu viel Ahnung habe ich davon nicht; ich gehe davon aus, dass es (hier wahrscheinlich eher marginale) Vorteile und keine (erheblichen) Nachteile hat und diese Art des Umbaus prinzipiell erwünscht ist. Ein Nachteil wäre, dass dann überhaupt kein gemeinsames Schema zwischen den drei ausgelagerten Teilen mehr besteht, aber ein Vorteil wäre, dass mit diesem Umbau zumindest begonnen ist. Ich lasse mich da aber auch gern eines Besseren belehren. Gruß --Entlinkt (Diskussion) 01:56, 24. Apr. 2016 (CEST)

Ja, minimale Vorteile (besseres Cache-Verhalten) und minimale Nachteile (ein paar Bytes zusätzlich auf jeder Seite für die Moduldefinition, Wikis ohne Gadgets können unseren Code nicht mehr so leicht kopieren). Da der Code ja ohnehin nur provisorisch hier existiert, bis phab:T4537 global gelöst wurde, spricht letzteres aber in meinen Augen auch nicht wirklich dagegen, die Änderung vorzunehmen.

Mit [ResourceLoader|dependencies=mediawiki.util,jquery.accessKeyLabel|rights=hidden] würde auch der alles umfassende Aufruf von mw.loader.using überflüssig. --Schnark 09:50, 25. Apr. 2016 (CEST)

bcache statt smaxage

Hi, der Nächste, welcher hier vorbeieditiert, mag mal das &smaxage=21600 ersetzen durch &bcache=1 – dann wird auch das Tagesalter von maxage wieder wirksam. LG --PerfektesChaos 11:41, 27. Nov. 2014 (CET)

Würde aber bedeuten einen Bug (phab:T71460) zu umgehen. Keine wirkliche Lösung, wenn ich das richtig verstehe. Der Umherirrende 18:10, 27. Nov. 2014 (CET)

Genau darum geht es.

• Ohne &bcache=1 bleibt das &maxage= wirkungslos.
  • Damit bleibt die alte JS-Version ggf. 30 Tage im Cache des Benutzers erhalten, falls nicht zufällig mal geleert würde.
• &smaxage= ist unter HTTPS Nonsens, weil es keine Proxy- oder Knotenrechner unterwegs gibt, die die URL kennen dürfen, und deshalb niemand auf halber Strecke mit einer Seitenversion antworten kann. Nur der Browser des Anwenders und der Zielserver sollen die URL über den Host hinaus kennen, und vielleicht die NSA.

LG --PerfektesChaos 20:09, 27. Nov. 2014 (CET)

smaxage wird durchaus beachtet, nämlich von den WMF-Cache-Servern selbst, zumindest wenn man den Bug per bcache=1 umgeht. Das kann aber ein zweischneidiges Schwert sein, denn die Server cachen die Ressource dann wirklich so lange wie angegeben, und lassen sich von nichts und niemandem überzeugen sie vorzeitig zu aktualisieren. --Schnark 09:23, 28. Nov. 2014 (CET)

• Ja, ist schon völlig klar; deswegen soll der ja auf jeden Fall aus der URL raus.
  • Ursprünglich hatte das mal die shared Zwischenknoten im Netz beeinflusst, was halt unter HTTPS obsolet ist.
• Wenn hingegen die durchaus sinnvolle Begrenzung per maxage greifen soll, dann muss hingegen bcache=1 erstmal rein.

LG --PerfektesChaos 09:50, 28. Nov. 2014 (CET)

Da es solche Bearbeitungen gab, sollten man dieses Thema wohl ignorieren. Der Umherirrende 09:57, 10. Aug. 2015 (CEST)

Na, da widerspricht er sich ja selbst.

• Wenn "maxage" and "bcache" don't exist, does nothing zutreffen würde, dann kann causes edits to not purge the script. (E.g. users continue to get old version) ja nicht sein.
• Das ist genau der Grund, warum ich die Parameter einsetze: Wenn ich abschätzen kann, dass eine Ressource (wie der Wiki-Ball links oben, oder ein stabiles und monatelang nicht mehr zu änderndes Skript) sich in den nächsten Tagen und die kommende Woche nicht mehr verändern wird, und wenn doch, dann wäre eine Verspätung unproblematisch. Ansonsten setze ich eine angemessene Zahl von Stunden.
• Für jedes Skript, für jede kleine Grafik vom Wiki-Ball über bis zu jahrelang ungeändertem CSS wird eine einzelne Anfrage an den Server geschickt, ob die noch frisch wären, bei jedem Seitenaufruf. Ich bin im Moment im Sommerurlaub und hänge an einem lahmen Internet; ich habe aber httpfox drauf und gucke über 20 Sekunden zu, wie er laufend 2kB-Fragen stellt und 2kB-Antworten bekommt; ja, 304, alles fein.

Ob dieser Edit in unserer Community angemessen war, wäre zu hinterfragen. Dieser Contractor scheint sich langsam zu einem Alleinentscheider über 1000 Wikis zu entwickeln, um diesen seine Sichtweisen aufzuzwingen.

LG --PerfektesChaos 10:15, 10. Aug. 2015 (CEST)

Es gab vor einiger Zeit eine Softwareänderung für JavaScript und CSS-Seiten, die nach einer Bearbeitung die action=raw-URLs aus dem Squid-Cache löschen (sofern sie "normalen" Aufbau haben, gedrehte Parameter werden nicht entfernt), damit zumindestens serverseitig die neuste Version ausgeliefert wird. Ob dies Browser-seitig Auswirkungen hat, kann ich nicht beurteilen. Der Umherirrende 10:36, 10. Aug. 2015 (CEST)

Ich bin momentan nicht in der Lage, das genauer zu untersuchen.

Der Server soll ja immer die frischesten Versionen bereithalten, auch in den slaves, keine Frage.

Zumindest bislang war es so, dass bei der oben entfernten Parameterkombination der Browser eine maxage-Direktive im HTTP-Header mitgeliefert bekam, die ihm sagte, dass bis zu dem angegebenen Alter für diese URL keine Rückfragen beim Server erforderlich wären.

Ansonsten liefert MW jeden Mist mit einem erlaubten Höchstalter von Null Sekunden aus. Was für den Text dieser Disku auch sehr sinnvoll ist; bei einem vor zehn Jahren zuletzt bearbeiteten Icon hingegen nicht – da kann man auch mal einen Tag auf eine aufgefrischte Version warten.

Ich hatte mal ein FF-Add-On, das für Ressourcen dieses Nachfragen unterband und die Browser-Cache-Version benutzte, falls vorhanden. Das Add-On ist nicht mehr am Markt, aber den Quellcode habe ich noch. Leider bin ich knapp an Programmierzeit, aber irgendwann baue ich nach dem Muster ein Add-On, das solche Zählpixel wie Powered by MediaWiki, Wikiball, WMF-Logo, Linkmarkierungen und Favicon usw. nebst frei konfigurierbarer Ressourcenliste per URL-RegExp auf den WMF-Seiten auf wenigstens 24 Stunden setzt.

LG --PerfektesChaos 11:01, 10. Aug. 2015 (CEST)

Und übrigens: Wenn man mal ganz dringend einen Hotfix unter die Leute bringen muss, dann kann bei unserem trafficsparenden Vorgehen einfach aus der 259200 eine 259201 gemacht werden. Damit ist es eine andere URL, und damit bekommen sofort alle Gadget-Nutzer mit der nächsten Seite die frischeste Version.

LG --PerfektesChaos 11:32, 11. Aug. 2015 (CEST)

Phabricator-Tasks

Hallo allerseits, mir ist aufgefallen, dass über diese Datei hier doch einiges an Performance flöten gehen kann (vor allem in Anbetracht dass man diese Funktionalität überhaupt nicht braucht). Des Weiteren sollte es für die meisten Funktionen hier einen Phab-Task geben, da sie ja wohl von allg. Nutzen sind!? Nun bemerkt nicht jeder gleich, dass es diesen gibt und daher auch nicht wenn oder überhaupt dieser gelöst bzw. in MediaWiki integriert. Daher schlage ich übersichtshalber vor, wenigstens hier als Diskussions-header, entspr. P-Tasks (mit vollem Namen) hinweisend zu verlinken. In der Art:

• T7642: Provide "add new section" link at the bottom of (discussion) pages

Erfolgreiches Neues ↔ User: Perhelion  13:11, 30. Dez. 2015 (CET)

1. Das hier sind deWP-interne Angelegenheiten, über die alle deWPler ohne sprachliche oder technische Hürden mitdiskutieren können sollen.
   • Somit scheidet Phabricator als Regelfall aus.
2. Gelegentlich mag sich eine Angelegenheit in der weltweiten Software widerspiegeln; dann kann ja tracked angegeben werden.
3. Was da als Abschnitts-Header verlinkt werden soll, habe ich nicht verstanden; und wenn ich das schon nicht kapiere, dann wird ein zufällig hier etwas anregender Wikipedianer ohnehin nicht begreifen, wie und was er in die Überschrift reinschreiben soll. Also bleibt es bei formloser Mitteilung.
4. Wer Phab-Links angeben mag, hat die Möglichkeit, Show= anzugeben; tracked sieht das nicht vor. Ob und wem der Titel, der teilweise recht lang sein mag und trotzdem wenig aussagen könnte, nun weiterhilft, ist eine andere Frage. Ich müsste in der Regel immer die Task aufmachen und mir durchlesen, worum genau es da ginge. Dass es irgendwas mit dem hiesigen Abschnitt zu tun hätte, würde ich mal annehmen.

LG --PerfektesChaos 13:26, 30. Dez. 2015 (CET)

Ja du hast wohl Recht, Phabricator als Regelfall wohl nicht. Ich meinte eben nicht Abschnitts-Header sondern hier im Kopf der ganzen Diskussionseite, da Abschnitte ja archiviert werden (was ja keinen Sinn macht wenn es sozusagen zur Dokumentation gehören soll).

Hm* tracked würde auch passen, wenn es denn nicht zu aufdringlich erscheint!? Also im Prinzip ist dies hier eher ein Anliegen für eine kleine Dokumentation zur Übersicht, natürlich kann man auch alles in den Quelltext schreiben!?

PS: Ich bin mir relativ sicher dass was für die Deutsche Wikipedia gut ist, ist auch für andere gut, und wenn nicht ist es auch nicht so gut. :-P LG ↔ User: Perhelion  15:22, 30. Dez. 2015 (CET)

Umseitig steht eine Zusammenstellung von Schnipseln.

Langfristig sollten die (auch im neuen Gadgets-Namensraum) sinnnvoll gruppiert in einzelne Seiten zerlegt werden und als hidden gadgets oder, wo ernsthafter Bedarf bestünde, die Ankreuzliste aufblähend für Angemeldete deaktivierbar sein.

Ein Schnipsel über die deutschsprachige Sortierreihenfolge ist genausowenig weltweit von Interesse wie ein deutschsprachiger Hinweis auf andere Wikipedien für die Hauptseite oder unser privates includePage wie auch Spenden-Links für DACH.

Das Zeugs ist über fünf Jahre alt und wäre vorbeugend renovierungsbedürftig.

Da es nahezu keine Admins mit soliden JS-Kenntnissen und Weitsicht mehr gibt, die auch Lust hätten, sich hier auf Experimente einzulassen, wird also einstweilen alles so bleiben wie es ist.

Wem sollen deine Wünsche denn jetzt was bringen und was erwartest du ernsthaft, dass sich ändern würde?

VG --PerfektesChaos 21:26, 30. Dez. 2015 (CET)

Links zu Schwesterprojekten

Nachdem inzwischen Schwesterprojekte-Links von Wikidata eingefügt werden, sollte – sofern möglich und nötig – für die weiteren Links (insbesondere Wiktionary) kein neuer Kasten eingefügt werden, sondern die Links an die vorhandenen angefügt werden. Ungetesteter Codevorschlag:

if( mw.config.get( 'wgNamespaceNumber' ) > 0 ) {
  mw.loader.using( [ 'mediawiki.util' ], function() { $( function() {
    var iProject = $( '#interProject' );
    if( !iProject.length ) {
        return;
    }
    var otherProjects = $( '#p-wikibase-otherprojects' );
    var otherProjectsId = 'p-wikibase-otherprojects';
    if( !otherProjects.length) {
        var sistersibling = $( '#p-lang' );
        if( !sistersibling.length ) {
            sistersibling = $( '#p-tb' );
        }
        if( !sistersibling.length ) {
            return;
        }
        //Link auf Parentnode des Portletmenues
        var sisterparent = sistersibling.parent();

        //Erzeuge neues Portletmenue
        var sisterprojectnav = $( document.createElement( 'div' ) );
        sisterprojectnav.attr( 'id', 'p-sisterprojects' );
        sisterprojectnav.attr( 'class', sistersibling.attr( 'class' ) );
        var header = $( document.createElement( 'h3' ) );
        header.text( $( '#sisterProjects:first' ).text() );
        sisterprojectnav.append( header );
        var portletDiv = $( document.createElement( 'div' ) );
        var sistersiblingsub = sistersibling.find( 'div:first' );
        if( sistersiblingsub.length ) {
            portletDiv.attr( 'class', sistersiblingsub.attr( 'class' ) );
        } else {
            portletDiv.attr( 'class', 'pBody' );
        }
        sisterprojectnav.append( portletDiv );

        //Wenn möglich vor den Interwikis einfügen
        if ( sisterparent.has( '#p-lang' ).length ) {
            sisterprojectnav.insertBefore( '#p-lang' );
        } else {
            sisterparent.append( sisterprojectnav );
        }
        otherProjectsId = 'p-sisterprojects';
    }

    //Schwesterlinks ermitteln und einfügen
    iProject.find( 'a' ).each( function() {
        $this = $( this );
        var sistername = $this.text();
        mw.util.addPortletLink(
            otherProjectsId,
            $this.attr( 'href' ) + '?uselang=' + mw.util.rawurlencode( mw.config.get( 'wgUserLanguage' ) ),
            sistername,
            'sister-' + sistername,
            sistername
        );
    });
  })});
}

--Schnark 12:02, 17. Feb. 2016 (CET)

Jetzt sogar getestet. --Schnark 12:10, 17. Feb. 2016 (CET)

Vielleicht lieber als hidden default-Gadget in gekapselt und so, von wegen zukunftsfähig, statt in dem ollen Namensraum in seinem Brei.

Vielleicht braucht ja wer ein Opt-Out.

LG --PerfektesChaos 12:36, 17. Feb. 2016 (CET)

Wenn alle Skripte an einem Ort sind, muss man nicht erst lange suchen, bis man das hat, was man sucht. Wichtiger als irgendwelche akademische Gedanken über die Zukunftsfähigkeit (so alt wie der Stil des Codes ist, sind die nämlich wirklich nur akademisch), ist es zügig etwas zu machen, weil zwei Abschnitte in der Seitenleiste für den gleichen Zweck wie etwa auf Wikipedia:Fragen zur Wikipedia einfach blöd aussehen. --Schnark 09:31, 18. Feb. 2016 (CET)

Hallo, also (wenn man hier "ungetestet" schreibt, da weiß ich nicht genau ob man da Respekt sagen kann :P) die Idee ist ja nicht schlecht, (auch wenn es nur ein vorübergehender oder doch dauerhafter Hack sein sollte). Ich habe mal getestet und es tut sich etwas anderes als beschrieben, also bei FzW sind jetzt zwei lange Kästen vorhanden. Daher verstehe ich den Code nicht, dass ein addPortletLink (in einer Schleife) verwendet wird, das sollte man bei schon vorhanden Elementen doch gar nicht benötigen bzw. auch gar kein neues Menue!? (Da wir ja alle wenig Zeit haben, habe ich mir da auch nur kurz angesehen). LG ↔ User: Perhelion 12:40, 20. Apr. 2016 (CEST)

Das lag wohl daran, dass ich nicht des ersetzenden Codes gewahr war (und somit beim Testen ein doppeltes Menue erschien). Nichtsdestotrotz bleiben die doppelten Links ja unnötig erhalten!? Daher habe ich den Code (etwas optimiert und eine var aus der Schleife genommen) um ein Feature erweitert, das doppelte Projekt-Links ausschließt, siehe Beta. VG ↔ User: Perhelion 13:39, 24. Apr. 2016 (CEST)

jquery.ui.button

Das Modul jquery.ui.button wurde vor kurzem als deprecated markiert, sodass man jetzt auf Seiten wie Wikipedia:Qualitätssicherung eine Warnung in der Browserkonsole erhält, weil durch Common.js das Modul geladen wird, wenn die entsprechende Klasse auf einer Seite verwendet wird. Aktive Seiten, die die Klasse verwenden, gibt es zum Glück nicht so viele. Hat jemand Lust, sich ein bisschen Unmut von Benutzern zuziehen, die gegen jegliche Veränderung im Aussehen sind, diese Verwendungen auf mw-ui-button umzustellen und anschließend das Modul nicht mehr zu laden? --Schnark 11:47, 23. Aug. 2016 (CEST)

I do volunteer for template:button.

• Ich muss mich da aber erstmal in den neuesten mw-Design-Stand einlesen, damit die Änderung möglichst sanft ausfällt. Die restliche Programmierung (Parameter) wäre dem vermutlich ebenfalls anzupassen. Also zunächst BETA.

Für den Rest empfehle ich dann einen Bot-/Admin, der gemäß dieser Erkenntnisse eine zarte Änderung aus neutraler Position ausführt; ggf. direkt auf die Vorlage als neutrale zentrale Hülle umstellt.

Haste mal ’ne Task # als Argumentationshilfe?

LG --PerfektesChaos 12:09, 23. Aug. 2016 (CEST)

phab:T142418 --Schnark 12:23, 23. Aug. 2016 (CEST)

Übrigens ist auch bei mediawiki.ui damit zu rechnen, dass es über kurz oder lang als deprecated markiert wird, siehe [4]. --Schnark 09:27, 25. Aug. 2016 (CEST)

Ach du heiliges Spaghettimonster.

• Ich habe mir zwischenzeitlich die ganzen Verwendungen durchgeguckt.
• Mich außerdem in die neuesten Design-Moden und OOjs eingelesen.

Ich schlage folgende Strategie vor:

1. Projektweite Seiten wie WP:QS oder WP:3M mit direkter oder indirekter Einbindung:
   • Ersatz durch Vorlage:MediaWiki-Button
   • Diese als einzige zentrale Vorlage für das hiesige Projekt unterhalten und gemeinschaftlich pflegen.
   • Hierfür C&P der weltweiten Elemente; irgendwie halten die das Design ja auch am Laufen.
2. Portale, Wikiprojekte, BNR:
   • Auf Disk informieren; anraten, ein Gleiches zu tun.
3. WP:NEU – Ankündigung der hiesigen Abschaltung zum 31. Dezember 2016.
4. Vorlage:Clickable button 2 und Vorlage:button
   • Als veraltet kennzeichnen.
   • Kein Projekt-Support von dewiki mehr.

Viel Spaß bei der Umsetzung --PerfektesChaos 00:04, 4. Okt. 2016 (CEST)

Alle Navigationsleisten ausklappen

Nur zur Dokumentation (wehe, das nutzt jemand im ANR): Durch die Nutzung globaler Variablen gibt es einen lustigen Trick, wenn man alle Navigationsleisten standardmäßig ausgeklappt zeigen will: Man muss dazu nur <div id="NavigationBarShowDefault"></div> irgendwo auf der Seite einfügen. Dadurch gibt es eine globale Variable NavigationBarShowDefault, die das div-Element enthält, beim Vergleich mit der Zahl der Navigationsleisten entscheidet sich das Skript dafür, alle ausgeklappt zu zeigen. Wer ein Argument braucht um globale Variablen zu entfernen, hat jetzt eines. --Schnark 10:20, 15. Sep. 2016 (CEST)

Bei NavigationBarShow und NavigationBarHide funktioniert es nicht, das sich etwas ändert, da typeof Object ergibt und dort auf string abgefragt wird (Wobei es für diese Variablen auch keine Möglichkeit gibt, sie als Nicht-global zu nutzen, außer man schafft es zeitlich das mw-Objekt zu verändern). Soll NavigationBarShowDefault noch auf string und number abgefragt werden? Soll man Angaben über mw.user auch entsprechend abfragen?

Die Global wird aus Kompatibilitätsgrunden wohl erhalten bleiben müssen. Der Umherirrende 18:13, 16. Sep. 2016 (CEST)

Nix tun, schade um Zeit und Mühe.

Müsste in gekapseltem modernen Gadget-Stil komplett neu gebaut werden.

Der JS-Hack in window richtet ja keinen Schaden an.

LG --PerfektesChaos 18:22, 16. Sep. 2016 (CEST)

Ich bin auch für Nichtstun, zumal das ja nicht die einzige Stelle ist, wo ein vergleichbares Problem vorkommt. MediaWiki:Gadget-markAdmins.js, MediaWiki:Gadget-Rechtschreibpruefung.js, MediaWiki:Gadget-Extra-Editbuttons.js, MediaWiki:Gadget-ReferenceTooltips.js und sicher noch ein paar Gadgets, dazu höchstwahrscheinlich einige Benutzerskripte (einschließlich welcher von mir) haben das Problem ja auch in der einen oder anderen Form.

Findet eigentlich jemand Angaben dazu, in welchen Browsern das vorkommt? Es sieht eigentlich nach einem ziemlich archaischem Feature aus, aber als mir vor ein paar Tagen ein alter Firefox (so um die Version 20) in die Hände fiel, konnte ich es dort nicht reproduzieren. --Schnark 09:38, 17. Sep. 2016 (CEST)

Auf stackoverflow wird gesagt, es kommt aus IE und wurde in die anderen übernommen und bei FF ist es buggy (bzw. der erste Zugriff erstellt sie, funktioniert aber nicht über die Konsole). Die Spec ist dort auch verlinkt (Window-Property sind alle named objects und die Ids gehören dazu). HTML-Injection ist bei den Gagdgets aber nicht möglich, da die Sachen mit Strings verwendet werden und dadurch ergibt sich ein [object HTMLDivElement] Der Umherirrende 22:16, 19. Sep. 2016 (CEST)

Aha, mal wieder ein Versuch anderer Browserhersteller bugkompatibel mit IE zu sein. Prinzipiell kann das durchaus Sicherheitslücken erzeugen, etwas

var title = 'Standardtitel';
if (typeof globaleKonfiguration !== 'undefined' && globaleKonfiguration.title) {
   title = globaleKonfiguration.title;
}
$('#firstHeading').html(title);

--Schnark 08:56, 20. Sep. 2016 (CEST)

Links zu gerenderten PNGs bei SVG-Dateien

Gemeldet in Phabricator
Task T106263

Wenn wir schon dabei sind: Braucht es heutzutage wirklich noch den Code unter „Fügt bei SVG-Grafiken Links zu gerenderten PNGs in verschiedenen Breiten hinzu“? Inzwischen gibt es solche Links (wenn auch mit anderen Größen) standardmäßig (Beispiel), sodass es keinen Grund mehr gibt, diese Links mittels JS hinzuzufügen. Klar, wir können auch warten, bis sich die Datei-URLs so ändern, dass der Code ohnehin kaputtgeht. Aber meiner Ansicht nach können wir ihn auch gleich entfernen. –Schnark 10:36, 1. Mär. 2017 (CET)

zustimmung hab mich immer schon gefragt warum es auf den dateibeschreibungsseiten 2 zeilen mit verschiedenen auflösungen gibt anstatt einer. --Wetterwolke (Diskussion) 11:23, 1. Mär. 2017 (CET)

Info: Die zugehörigen Phabricator-Tasks sind phab:T4581 und phab:T8834, siehe insbesondere auch den Kommentar unter phab:T8834#1427580. Meiner Meinung nach sollte der Code zügig entfernt werden. --Entlinkt (Diskussion) 12:50, 2. Mär. 2017 (CET)

Dann warte ich mal keine 7 Tage. Entfernt. Der Umherirrende 20:04, 3. Mär. 2017 (CET)

Leyo mag es nicht. Da ich einer der wenigen Bearbeiter der Seite bin, wurden auch alle vorherigen Änderungen zurückgesetzt. Es gibt Gründe gegen Rollback, auch wenn man es mit Kommentar verwendet. Der Umherirrende 20:50, 3. Mär. 2017 (CET)

(BK) Ich habe leider den Abschnitt hier übersehen. Da die von MediaWiki angebotenen Grössen in vielen Fällen unbrauchbar sind, habe ich die Entfernung (vorläufig) revertiert. Gerade bei komplexen/detailreichen SVGs (Beispiel) reicht eine Maximalgrösse von z.B. 1355 × 1355 Pixel keinesfalls. Zudem sind die angebotenen Auflösungen teilweise ziemlich merkwürdig: 320 × 226 Pixel | 640 × 453 Pixel | 1024 × 724 Pixel | 1280 × 905 Pixel | 1052 × 744 Pixel. (die letzten drei sind sehr ähnlich). Es fehlt für OMA eindeutig eine grosse Auflösung oder eine Maximalauflösung. Die Umsetzung sollte ja eigentlich nicht ein riesiges Problem darstellen. --Leyo 21:07, 3. Mär. 2017 (CET) PS. Den Rollback-Unfall habe ich korrigiert. Sorry!

Um hier mal einen Kreis zu schließen, die selbe Diskussion gab's auch auf Commons vor einiger Zeit. Ergebnis war demnach phab:T106263 (offen). MfG -- User: Perhelion 23:10, 3. Mär. 2017 (CET)

Kannst vielleicht du einen Patch schreiben? --Leyo 00:00, 4. Mär. 2017 (CET)

Die „OMA“ kommt überhaupt nicht auf die lokale Dateibeschreibungsseite. Die sieht das Bild im Medienbetrachter und kommt eventuell noch auf die Beschreibungsseite auf Commons. Wenn das das einzige Argument ist, den Code hier zu behalten, dann kann er wirklich entfernt werden. –Schnark 09:53, 4. Mär. 2017 (CET)

@Schnark: Nun da ist auf den ersten Blick etwas dran. Der Medienbetrachter bietet die Funktion wohl erst gar nicht, was natürlich einen weiteren Phab-Task berechtigt!?

@Leyo: Den Phab-Task kann ich nicht erl. (da wohl PHP basierend).

Allerdings könnte man tatsächlich den hier (zur Löschung gewünschten) Code dahingehend ändern, dass er entweder einen größeren Wert (an die Default-Leiste) anhängt oder ein Eingabefeld erzeugt (was jetzt für den nicht-OMA-User tatsächlich von geringerer Bedeutung wäre, allerdings machen modernere Browser wie Yandex, die URL-Manipulation auch etwas uneinsichtiger). -- User: Perhelion 15:00, 5. Mär. 2017 (CET)

Ja, PC-affine Personen können sich tatsächlich via URL-Anpassung behelfen. Für mich wäre auch ein Eingabefeld OK. --Leyo 21:28, 5. Mär. 2017 (CET)

Leyo, wenn es zu klein ist wie in deinem bsp kann man immernoch auf Originaldatei klicken, eine datei sollte in nutzbarer grösse erstellt werden (extrembeispiele wirst du immer finden, wo dann aber auch 2000px nicht ausreichen). merkwürdig ist es allerdings in der tat zu 1024 × 724 Pixel | 1280 × 905 Pixel | 1052 × 744 Pixel. auch noch 1000px hinzuzufügen, das ganze dann auch noch 2 zeilen tiefer, in ander schriftgrösse, mit px statt pixel und komma statt pipe. du verschlimmbesserst es eindeutig. auserdem ist es nicht ok, dass du zurücksetzt und dann erst die diskussion aufsuchst. bevor der code entfernt wurde, war hier die diskussion. es täte dir gut genauso vorzugehen und auf der diskussion zu schreiben, dass du es anders siehts und man es wieder herstellen sollte. auf mediawiki seiten wird äusserst vorsichtig vorgegangen, wenn du es nicht kannst lass es. gruss --Wetterwolke (Diskussion) 11:34, 4. Mär. 2017 (CET)

Es geht mir darum, dass eine SVG-Datei für OMA gegenüber einer PNG-Datei bezüglich Weiternutzung keine Nachteile hat. Wie man dies ohne die Hilfe von MediaWiki macht, ist längst nicht jedem/r bekannt. Ich gehe davon aus, dass es die Bevölkerungsmehrheit betrifft. Umherirrender hat das Feature mit guten Intentionen, aber nach nur zwei Tagen Diskussion etwas vorschnell entfernt. Dass ich die Rollbackfunktion verwendete, war ein klarer Fehler. Die Diskussion aber findet beim Status quo statt. Zuerst muss der angesprochene Mangel beseitigt werden. Wenn ich mich richtig erinnere, war die Einführung von MediaWiki:Show-big-image-preview-differ auf meine Intervention zurückzuführen. Zuvor wurde nicht erwähnt, dass die Vorschauen im PNG-Format sind. --Leyo 21:28, 5. Mär. 2017 (CET)

Ich habe nichts gegen das zurücksetzen. Ich hatte im letzten Monat auch schon den Gedanken, das man es nicht mehr braucht, durch den Abschnitt hier wurde ich darin nur bekräftigt, daher habe ich keine Woche gewartet, wie bei anderen Abschnitten. Diese bisherigen Nachrichten basieren unteranderem auf dieser Diskussion auf commons (gerrit:225682). Der Umherirrende 20:01, 6. Mär. 2017 (CET)

@Leyo: „Es geht mir darum, dass eine SVG-Datei für OMA gegenüber einer PNG-Datei bezüglich Weiternutzung keine Nachteile hat.“ Unabhängig davon, dass ich angesichts deiner Haltung vermute, dass du diesen Satz anders gemeint als geschrieben hast, stimme ich dieser Aussage, so wie sie dasteht, vollkommen zu: Während zu der Zeit, als dieser Code eingefügt wurde, die Weiternutzung von SVG noch problematisch war, gibt es heute keine Nachteile mehr gegenüber PNG, zur Weiternutzung sollte man (auch „OMA“) eigentlich immer die originale SVG-Datei herunterladen und nutzen. Wie ich [5] entnehme, werden SVGs inzwischen sogar von Microsoft Office problemlos unterstützt. Damit sehe ich wirklich keinen Grund mehr, die lokal erzeugten Links zu den PNGs zu behalten. –Schnark 10:07, 8. Mär. 2017 (CET)

Ich bezog mich auf eine SVG- bzw. eine PNG-Datei bei Wikipedia.

Meine PowerPoint-Version kann SVG-Dateien nicht importieren. Ich denke, die Beurteilung darüber, ob gerenderte PNG-Grafiken für OMA noch nützlich ist, sollte von im Grafikbereich aktiven Benutzern vorgenommen werden. Davon abgesehen, tut es wirklich weh, die MediaWiki-Funktion mit einer deutlich grösseren Auflösung oder einem Eingabefeld zu ergänzen? --Leyo 10:21, 8. Mär. 2017 (CET)

Eine solche Ergänzung innerhalb von MediaWiki wäre aus meiner Sicht kein Problem. Was ein Problem ist und worum es in diesem Abschnitt geht, ist lokaler Code, der zum einen nicht gepflegt wird (und von dem anzunehmen ist, dass er über kurz oder lang deshalb nicht mehr funktionieren wird), zum anderen die Funktion nicht ergänzt, sondern (in leicht veränderter Form) dupliziert. –Schnark 10:46, 8. Mär. 2017 (CET)

Sobald die Mängel bei MediaWiki behoben sind, kann dieser lokale Code entfernt werden, aber nicht vorher. --Leyo 11:22, 8. Mär. 2017 (CET)

Dieser „Mangel“ ist ein marginales Problem: Es tritt auf, wenn ein Benutzer es irgendwie schafft auf die lokale Dateibeschreibungsseite einer SVG-Datei zu gelangen, die eine nominale Größe kleiner als 2000px hat (Datei:Meiosis Stages.svg zeigt ja, dass größere Auflösungen von MW angeboten werden, wenn die SVG-Datei diese angibt), aber bei einer Breite von 1024px nicht gut nutzbar ist, der Benutzer sie als PNG-Datei weiternutzen will und nicht weiß, dass er die URL-Parameter so ändern kann, dass er die Breite bekommt, die er will. Jeder einzelne dieser Punkte kann auftreten, aber dass alle zusammen auftreten, ist extrem unwahrscheinlich. Daher sehe ich immer noch keinen Grund, warum der Code bleiben muss, bis das in MW behoben ist (oder, wesentlich wahrscheinlicher, bis er kaputt geht und niemand ihn reparieren kann/will). –Schnark 12:11, 8. Mär. 2017 (CET)

Es mag ja sein, daß die Verwendung von SVG in Mediawiki mittlerweile problemlos ist, das kann ich nicht einschätzen. Die gerade verlinkte Datei ist mit InDesign oder Quark überhaupt nicht zu öffnen und Photoshop braucht 12 Minuten(!) zum Rendern (bei 64GB RAM). Eine RAW-Entwicklung eines Bildes dieser Größe (ca. 12.000x3.000) ist in Sekundenbruchteilen erledigt. Das ist für Nachnutzer keine Option. In der Druckvorstufe brauche ich niemandem eine SVG schicken, damit kann keiner was anfangen. --M@rcela 17:28, 13. Mär. 2017 (CET)

Temporäre Funktion vom 12.-22.4.

Hallo allerseits, vom 12. bis 22.4. würden wir gern folgende Zeile in der common.js ergänzen:

/*  mw.loader.load( '/w/index.php?title=User:Addshore/wmdespring2017.js&action=raw&ctype=text/javascript' );

und zwar mit folgendem Hintergrund: In diesem Zeitraum läuft eine Neuautor*innenkampagne. Wir wollen am Ende der Kampagne auswerten, wie erfolgreich sie war, d.h. wie viele Registrierungen darüber erfolgt sind. Desweiteren soll zufallsgesteuert den Neuregistrierten eine geführte Tour angeboten werden. Hier soll ausgewertet werden, wie hilfreich eine solche Tour war. Die Kampagne selbst und die geführte Tour wurden bereits an den verlinkten Stellen diskutiert. Das aufgerufene Modul ist hier (Phabricator Task) einsehbar. Im Beta-Wiki wird die Funktion gerade getestet.

Sieht jemand Probleme mit der Funktion? --Verena Lindner (WMDE) 19:19, 10. Apr. 2017 (CEST)

• Das grundsätzliche Ziel soll gern erfüllt werden.
  • Ist üblicherweise binnen eines halben Tages live.
  • Einfach Bescheid geben, wenn Tests abgeschlossen sind, und die Aktion starten soll.
• Was die organisatorische Umsetzung angeht, hätte ich allerdings andere Vorstellungen.
  • Ich denke mehr an MediaWiki:Gadget-guidedTour/2017a.js
  • Benutzer:Addshore/wmdespring2017.js wie oben suggeriert gibt es ohnedies nicht. Und aus BETA würden wir erst recht nicht laden.
  • Müsste Addshore da nochmal und dauernd ran?
  • [ResourceLoader|hidden|dependencies=mediawiki.cookie,mediawiki.util|default]
• @Addshore:
  • I would prefer lazy loading of ext.guidedTour.launcher iff trigger was pulled, avoiding loading for the other 50 % and registered users.
  • You won’t need ==0, even more with two rather than three equal signs. Omitting that term results in the same statistical quota.
  • Do you expect a need for permament access to that code? Or fire and forget? Copying once into MediaWiki: would be preferred over User:.

Greetings --PerfektesChaos 20:20, 10. Apr. 2017 (CEST)

So, it looks like we will no entirely be doing this in PHP, so no JS / change to Common.js will be needed! Addshore (Diskussion) 12:58, 11. Apr. 2017 (CEST)

That’s fine. Enjoy --PerfektesChaos 13:08, 11. Apr. 2017 (CEST)

Dieser Abschnitt kann archiviert werden. Entlinkt (Diskussion) 02:26, 30. Apr. 2017 (CEST)