Wikiup Diskussion:Technik/Skin/Gadgets/CommonsDirekt

aus Wikipedia, der freien Enzyklopädie

{{Wikipedia:Technik/Skin/Gadgets/!WP:MW/Ä}}

Direct-link-to-Commons

Diskussion von MediaWiki Diskussion:Common.js hier her verschoben. --Fomafix (Diskussion) 16:53, 2. Jul. 2012 (CEST)

Mit großer Freude habe ich heute festgestellt, dass in der nlwiki beim Blick auf Bilder sofort nach Commons verlinkt wird, also die lokale Dateibeschreibungsseite, die zu 99,99 % überflüssig ist, übersprungen wird. In der nl:MediaWiki:Common.js steht ziemlich am Ende der zuständige Code Bewerken en overleg bij een afbeelding op Commons linken naar Commons (kopie van de Duitse Wikipedia)

Könnten wir das nicht auch hier einführen? — Raymond Disk. 21:38, 20. Jun. 2012 (CEST)

Diese Funktion ist doch bereits in dewiki und nlwiki hat diese von dewiki übernommen. --Fomafix (Diskussion) 21:44, 20. Jun. 2012 (CEST)
Funktioniert bei mir aber nicht. Weder angemeldet noch unangemeldet :-( Weder im FF noch im Chrome. Aber in der nlwiki funktioniert es. Grumpf. — Raymond Disk. 21:50, 20. Jun. 2012 (CEST)
Wenn es das hier gibt und wir alle vom selben reden, dann hat es bei mir noch nie funktioniert (üblicherweise Chrome, üblicherweise angemeldet). Allerdings führt der Bearbeiten-Link zur Bearbeitung der Commons-Bildbeschreibung und nicht zur lokalen Seite und da hat der Umherirrende (wenn ich mich richtig erinnere) auch etwas geändert. -- Gruß, aka 21:58, 20. Jun. 2012 (CEST)
(BK) (BK) Bei nlwiki kommt diese Funktion von nl:MediaWiki:Gadget-Direct-link-to-Commons.js. --Fomafix (Diskussion) 22:00, 20. Jun. 2012 (CEST)
Also bei mir hat das auch noch nie funktioniert. Und durch mittlerweile recht viele Workshops in Schulen und an VHSsen weiß ich, dass normale Leser hochgradig irritiert sind, wenn ich ihnen erkläre, dass sie noch einen Klick extra machen müssen. — Raymond Disk. 22:02, 20. Jun. 2012 (CEST)
Ahhhh, ein Gadget. Hätte ich bei uns auch gerne, für jedermann aktiviert. — Raymond Disk. 22:04, 20. Jun. 2012 (CEST)
Das wird ein Verständnisproblem sein. Die Funktion bei uns, die Fomafix wohl meinte, führt beim Klick auf Bearbeiten auf der lokalen Dateibeschreibungsseite direkt zum Bearbeiten der Commonsseite. Das man beim Klick auf das eingebundene Commonsbild auch direkt auf Commons landet, das haben wir nur irgendwo als Userskript. Der Umherirrende 21:59, 20. Jun. 2012 (CEST)
Benutzer:Schwäbin hatte mal erwähnt, dass sie das irgendwie für sich eingerichtet hat - ich tippe deshalb (ohne nachzugucken) auch auf ein Userscript. Kann das hier jemand vergadgetisieren, so dass sich das jeder per Option einschalten kann? -- Gruß, aka 22:05, 20. Jun. 2012 (CEST)
Ist am Ende meiner .js zu finden. NNW 22:07, 20. Jun. 2012 (CEST)
Jeder Admin ;-) Steht in Benutzer:Schwäbin/vector.js. Der Umherirrende 22:08, 20. Jun. 2012 (CEST)
(BK und das in diesem NR) Von der mw:Snippets/Direct imagelinks to Commons nach MediaWiki:Gadget-Direct-link-to-Commons.js her kopieren und in MediaWiki:Gadgets-definition anmelden. --Fomafix (Diskussion) 22:10, 20. Jun. 2012 (CEST)
Gern, aber bitte von allen zusammengetragenen Varianten das Beste herausarbeiten und zusammenstellen.
Pfiffig und am schnellsten scheint mir der Ansatz zu sein
  • src.indexOf('//upload.wikimedia.org/wikipedia/commons/') >= 0
  • Unser 'wgFormattedNamespaces' )['6'] würde Datei: heißen, wenn überhaupt noch.
  • Bei secure würde ich kurzerhand returnen.
  • Ansonsten protokoll-relativ.
Grüße --PerfektesChaos 22:25, 20. Jun. 2012 (CEST)
// fileDescCommons.js
// 2012-06-21
// Skip local file description page if present on Commons.
// Precondition:    Any WMF project, but not meaningful on Commons.
// ResourceLoader:  compatible; dependencies: mediawiki.util
// Inspired by:     mw:Snippets/Direct_imagelinks_to_Commons
// Note: //secure.wikimedia.org keeps https but switches to //commons.
/* jshint curly:true, undef:true, white:false                          */
/* global document: true, jQuery: true, mediaWiki: true                */
/*jslint  white: true                                                  */
/*globals document: true, jQuery: true, mediaWiki: true                */
( function ( mw, $ ) {
   "use strict";
   if ( mw.config.get( 'wgNamespaceNumber', 0 )  >=  0 ) {
      $( document ).ready( function () {
         var k,
             n,
             site,
             shift   =  '//commons.wikimedia.org/wiki/File:',
             spaces  =  mw.config.get( 'wgFormattedNamespaces' ),
             src,
             store   =  '//upload.wikimedia.org/wikipedia/commons/';
         site  =  mw.util.wikiGetlink( spaces[ '6' ] )  +  ':';
         n     =  site.length;
         $( 'a.image' ).attr( 'href',  function( i, href ) {
            src  =  $( this ).find( 'img' ).attr( 'src' );
            if ( src ) {
               if ( src.indexOf( store )  >=  0 ) {
                  k  =  href.indexOf( site );
                  if ( k >= 0 ) {
                     return  shift  +  href.substr( k + n );
                  }
               }
            }
                                                           } );// .attr()
                                       } );   // .ready()
   }
   mw.loader.state( "ext.gadget.fileDescCommons", "ready" );
}( mediaWiki, jQuery ) );

Beachte, dass die Einbindung auf MediaWiki:Gadgets-definition (in beiden Fällen) lauten muss: 

fileDescCommons[ResourceLoader|dependencies=mediawiki.util]|fileDescCommons.js

Liebe Grüße --PerfektesChaos 15:44, 21. Jun. 2012 (CEST)

MediaWiki:Gadget-Direct-link-to-Commons.js ist jetzt als Gadget vorhanden und kann von Benutzern aktiviert werden. Da ich kein JS-Experte bin, würde ich es gerne dir und anderen JS-Programmierern überlassen, den zu verwendenden Code auszuwählen und einzutragen. Mir persönlich ist nur wichtig, dass das Gadget möglichst schnell stabil läuft und standardmäßig aktiviert werden kann, damit der normale Leser auch in den Genuss kommt. Danke für eure Mithilfe. — Raymond Disk. 20:34, 21. Jun. 2012 (CEST)
Ich habe meinen obigen Code noch um das Ausgrenzen der Spezialseiten ergänzt.
Wen wundert’s – ich halte ihn für den etwas effizienteren, zukunftsfähigeren und besser als aktuelles Gadget geeigneten; deswegen hatte ich ihn gestern aus den diversen Schnipseln herausdestilliert.
Er zielt auf alle Sprachen ab; für dewiki ließe sich noch spezialisieren:
  • site = '/wiki/Datei:', n = 12,
  • spaces kann dann entfernt werden.
Weiter kann ich nichts tun; das wäre eher am Umherirrenden. --PerfektesChaos 20:52, 21. Jun. 2012 (CEST)
Ich bin nicht der einzige Admin mit JavaScript-Kenntnissen … ;-) Das state würde ich aber innerhalb des Skripts nicht selber verwalten, vorallem nicht, weil es ja eh zwei Zeilen später aufgerufen wird (wird ja durch RL dazugeneriert) Der Umherirrende 21:34, 21. Jun. 2012 (CEST)
(Du hattest dich hier halt schon tiefer eingebracht und steckst in der aktuellen Gadget-Aufarbeitung.)
Der Code ist zunächst einmal für alle WMF geschrieben und für wahlweise Einbindung per .using()+.load() oder Gadgets-definition. Mit der konkreten Einbindung in dewiki als Gadget kann .state() natürlich entfallen.
VG --PerfektesChaos 22:04, 21. Jun. 2012 (CEST)


Ich habe das Gagdet heute auf WP:FZW vorgestellt. Es gibt das Problem, dass auch nach Commons weitergeleitet wird, wenn es dennoch eine lokale Dateiseite gibt. @-PerfektesChaos: Fängt dein Script diesen Sonderfall ab? — Raymond Disk. 17:06, 26. Jun. 2012 (CEST)

  1. Bedauerlicherweise nein.
    • Um das herauszufinden, wäre wohl eine API-Abfrage erforderlich.
    • Das ist allerdings etwas zeitaufwendig. Beim Klick auf das Link wäre es etwas zu spät; vielmehr müsste diese Analyse ähnlich dem BKL-check in der Zwischenzeit per API bei jedem Link auf eine Commons-Datei erfolgen.
  2. In der Zwischenzeit habe ich bemerkt, dass es wohl nur selten gleichzeitig lokale Dateibeschreibungen gibt – viel häufiger aber lokale Diskussionen über die Dateibeschreibung. Diese müssten auch abgefangen werden, während wohl recht bald nach einem „CTB“ die lokale Dateibeschreibung gelöscht wird.
    • Eingangs dieses Abschnitts war zutreffend von „zu 99 % nicht erforderlich“ die Rede.
    • Was meinen die Bild-Experten?
  3. Sinnvoller wäre dann auf JavaScript-Ebene der weiter oben schon mal angeklungene Ansatz, mit dem normalen Besuch auf einer lokalen Dateibeschreibungsseite festzustellen, ob diese nur virtuell ist und es auch keine lokale Disku dazu gibt, und dann sofort automatisch nach Commons weiterzuklicken.
  4. Alternativ könnte man versuchen, die Links auf Dateibeschreibungen auf eine JS-Funktion zu lenken, die erst im Anklick-Fall per API prüft ob lokal oder Commons, und dann direkt dorthin springt.
  5. Eigentlich ist das aber etwas für den Server, der das vorher viel besser weiß als wir, die wir hinterher mit JS nachflicken können: Wenn es lokal zu einem Commons-Bild weder Dateibeschreibung noch -Disku gibt, dann verlinke in der Seite auch direkt auf die Commons-Dateibeschreibung.
    • Aber das wird in den letzten zehn Jahren sicher schon mehrfach jemand gebugzillat haben.
Liebe Grüße --PerfektesChaos 18:11, 26. Jun. 2012 (CEST)
Hier ein Vorschlag von mir, der per API überprüft, ob eine lokale Beschreibungsseite oder Diskussion existiert (wird bei click auf das Bild ausgeführt): - Hoo man (Diskussion) 18:00, 28. Jun. 2012 (CEST)
/**
 * Direct imagelinks to Commons, modified
 *
 * @author: [[m:User:Hoo man]], originally from [[commons:User:Krinkle]]
 */
(function ($, mw) {
	function directLinksToCommonsClick() {
		if($(this).attr( 'href' ).indexOf('?') === -1) {
			var filePage = decodeURIComponent(
				$(this).attr( 'href' ).replace( /_/g, ' ' ).substring( $(this).attr( 'href' ).lastIndexOf( '/' ) + 1 )
			);
		}else{
			var filePage = mw.util.getParamValue( 'title',  $(this).attr( 'href' ));
		}
		var fileTalk = filePage.replace( mw.config.get( 'wgFormattedNamespaces' )['6'], mw.config.get( 'wgFormattedNamespaces' )['7'] );
		$.ajax({
			url : mw.config.get( 'wgServer' ) + mw.config.get( 'wgScriptPath' ) + '/api.php',
			data : { action : 'query', format : 'json', titles : filePage + '|' + fileTalk, indexpageids : 1},
			dataType : 'jsonp',
			jsonp:'callback',
			timeout : 3500, //timeout after 3.5 seconds (we can't let the user wait longer without any visible load bar)
			success: function( data ) {
				// Must be relative without "https://secure.wikimedia.org."
				// to avoid triggering 'div#content a[href ^="https://"]' lock-icons
				var commonsBase = mw.config.get( 'wgServer' ) === "https://secure.wikimedia.org"
								? '/wikipedia/commons/wiki/File:'
								: '//commons.wikimedia.org/wiki/File:',
				localBase = mw.util.wikiGetlink( mw.config.get( 'wgFormattedNamespaces' )['6'] + ':' );
				var pageids = data.query.pageids;
				if(pageids[0] === '-1' && pageids[1] === '-2') {
					//both pages don't exist
					window.location = commonsBase + encodeURIComponent( data.query.pages['-1'].title.replace( /[^:]+:/, '' ) );
				}else{
					//at least one exists
					window.location = localBase + encodeURIComponent( data.query.pages[pageids[0]].title.replace( /[^:]+:/, '' ) );
				}
			}
		} )
		//an error occured
		.fail( ( function (origURI) { return function() { window.location = origURI; }; } )( $(this).attr( 'href' ) ) );
		return false;
	}
	//init
	if ( mw.config.get( 'wgNamespaceNumber', 0 ) >= 0 ) {
		$(document).ready( function () {
			var uploadBaseRe = new RegExp( '^' + $.escapeRE( '//upload.wikimedia.org/wikipedia/commons/' ) );

			$( 'a.image' ).attr( 'href', function( i, currVal ) {
				if ( uploadBaseRe.test( $(this).find( 'img' ).attr( 'src' ) ) ) {
					$(this).on( 'click', directLinksToCommonsClick );
				}
			} );
		} );
	}
}( jQuery, mediaWiki ) );
Wie wäre es (vllt. nur für unangemeldete User), ähnlich wie es auch bei den {{Commonscat}}-Links ist, den Parameter uselang={{INT:Lang}} zu übergeben? Dann wäre die Commonsbildseite für Besucher der deutschen WP auch Deutsch (ansonsten ist sie ja bis auf Weiteres Englisch). Das einzig blöde ist halt, dass bei angemeldeten Usern uselang die Benutzereinstellungen überschreibt, was wohl meist (außer vllt. bei Newbies, die die Einstellungsmöglichkeit noch nicht fanden) unerwünscht ist.
Achja, wieso ist die Diskussion eigentlich hier? Sollte wohl eher auf die Disk des Gadgets, oder? Viele Grüße --Saibo (Δ∇) 04:15, 30. Jun. 2012 (CEST)
Wo oder wie kann man das ausschalten? In den Einstellungen kann ich nichts finden. Mit Opera wird immer auf die commons verlinkt, auch wenn es eine Beschreibung oder Disk des Bildes auf de.wp gibt. --Knochen ﱢﻝﱢ‎ 10:14, 30. Jun. 2012 (CEST)
hier, Punkt !!TESTPHASE!! Überspringen der lokalen Dateibeschreibungsseite, um sofort nach Commons zu kommen. — Raymond Disk. 10:32, 30. Jun. 2012 (CEST)
Zu Benutzer:Hoo mans Code: Wollen wir testweise ein 2. Helferlein einrichten oder den vorhandenen einfach durch obigen Code ersetzen? — Raymond Disk. 10:32, 30. Jun. 2012 (CEST)
Ich habe den Code nochmals modifiziert und getestet, er sollte jetzt zuverlässig funktionieren (wenn ein Fehler auftritt wird sicherheitshalber die lokale Seite geöffnet). Ob es jetzt sinnvoll ist ein zweites Gadget zu erstellen, wage ich zu bezweifeln, aber gleich mit default zu testen ist vielleicht auch etwas gewagt... - Hoo man (Diskussion) 17:15, 30. Jun. 2012 (CEST)
Habe das Skript jetzt so angepasst, das maximal 3,5 Sekunden auf die API gewartet wird, damit der Nutzer bei langsamer Verbindung nicht ewig aufgehalten wird. Außerdem habe ich das Skript nun mit Firefox und Midori (sehr ähnlich zu Chrome) erfolgreich getestet, weshalb meiner Meinung nach einem größer angelegten Test nichts mehr im Wege steht! - Hoo man (Diskussion) 02:39, 2. Jul. 2012 (CEST)


Nur mal nebenbei eingeworfen: auch wenn die lokalen Vorlage {{Geschützt}} sowie {{Geschützt-Ungeklärt}} eingebunden sind, müsste die lokale Dateibeschreibungsseite aufgerufen werden. Ansonsten werden die Warnhinweise nutzlos. Eine Frage wäre noch: was ist, wenn Dateien unter gleichem Dateinamen hier und auf Commons sind? Der Dupe-Check funktioniert ja im Moment nicht wirklich. -- Quedel Disk 16:38, 2. Jul. 2012 (CEST)

Wie oben bereits gesagt, so lange eine lokale Seite oder Diskussionsseite mit dem Namen des Bildes existiert, wird diese bei meiner (im Moment nicht verwendeten) Version des Gadgets angezeigt, also auch wenn dort die Oben erwähnten Templates liegen. - Hoo man (Diskussion) 16:45, 2. Jul. 2012 (CEST)
Das überspringen der deutschen Beschreibung für nicht angemeldete Benutzer macht keinen Sinn. Diese bekommen auf Artikelseiten einen Link in der Form http://de.wikipedia.org/w/index.php?title=Datei:Beispiel.jpg&filetimestamp=20120414161207 . Angemeldete können sich das einstellen oder auch nicht. --Knochen ﱢﻝﱢ‎ 22:25, 5. Jul. 2012 (CEST)
Auch mit diesem Link kann das Skript nun umgehen - Hoo man (Diskussion) 23:08, 5. Jul. 2012 (CEST)
Nö, weder mit Opera noch mit FF oder IE8. Als IP lande ich immer auf der deutschen Beschreibung bei Bildern in Artikeln. --Knochen ﱢﻝﱢ‎ 09:53, 6. Jul. 2012 (CEST)

Ich rede von meiner Version, die hier weiter oben steht, diese wird aber im Moment nicht verwendet. - Hoo man (Diskussion) 13:46, 6. Jul. 2012 (CEST)

Plötzlich Standard?

Salvete! Heute ist mir zum ersten mal passiert, daß ich bei einem Klick auf ein Bild sofort zu Commons weitergeleitet worden bin; gestern war das noch nicht. Mir war diese Springfunktion zum Glück bekannt und habe sie deshalb für mich einfach wieder abgestellt. Viele andere werden aber vewirrt sein -- muß es wirklich sein, daß der Commonssprung jetzt Standard ist, gerade wo doch noch dick TESTPHASE dransteht? Es wäre sicherlich besser, den weiterhin als Option anzubieten, die man, wenn man mag, zuschalten kannt. --Soccus cubitalis (Diskussion) 10:23, 22. Jul. 2012 (CEST)

Das Gadget ist schon seit dem 28. Juni standardmäßig aktiviert ([1]) - Hoo man (Diskussion) 13:49, 22. Jul. 2012 (CEST)
Tatsächlich? Dann ist es mir bisher nicht aufgefallen -- danke für die Jnfo! --Soccus cubitalis (Diskussion) 15:26, 22. Jul. 2012 (CEST)

PDF

In Russian Wikipedia we tested this gadget and find that PDF, DJVU, TIFF files it ignores. Patched version from Putnik: 

 if ( mw.config.get( 'wgNamespaceNumber', 0 ) >= 0 ) {
        $( function() {
                var     commonsBase =  '//commons.wikimedia.org/wiki/File:',
                        localBase = mw.util.wikiGetlink( mw.config.get( 'wgFormattedNamespaces' )['6'] + ':' ),
                        commonsBaseBook =  '//commons.wikimedia.org/w/index.php?title=File:',
                        localBaseBook = mw.util.wikiScript() + '?title=' + mw.util.wikiUrlencode( mw.config.get( 'wgFormattedNamespaces' )['6'] + ':' ),
                        uploadBaseRe = new RegExp( '^' + $.escapeRE( '//upload.wikimedia.org/wikipedia/commons/' ) );
 
                $( 'a.image' ).attr( 'href', function( i, currVal ) {
                        if ( uploadBaseRe.test( $(this).find( 'img' ).attr( 'src' ) ) ) {
                                return currVal.replace( localBase, commonsBase ).replace( localBaseBook, commonsBaseBook );
                        }
                });
 
        });
 }

--Sasha Krotov (Diskussion) 04:58, 27. Jul. 2012 (CEST)

SVG Dateien scheinen bisher auch nicht zu funktionieren. Weiß jemand Rat? Regards, Peter Weis (Diskussion) 19:19, 30. Sep. 2012 (CEST)
PDFs funtionieren nicht, weil diese ein in der URL haben. SVGs hatten das auch mal eine Zeitlang, der Fehler ist aber behoben, so dass SVGs nicht mehr betroffen sein sollten. Der Umherirrende 17:56, 28. Nov. 2012 (CET)

Es funktioniert nicht, und eigentlich gibt es etwas Besseres

  1. Bei mir greift es nicht mehr; möglicherweise HTML5 oder MW-Version? FF.
  2. Wir haben sowieso einen viel intelligenteren Code von Hoo Man, der auf lokale Dateien/Disku Rücksicht nimmt. Warum nicht den?

Solange nicht bekannt ist, welcher Code gelten soll, werde ich auch nicht debuggen.

VG --PerfektesChaos 10:02, 1. Okt. 2012 (CEST)

Das kann ich bestätigen, funzt bei mir auch nicht mehr (FF & Chrome). Da werde ich wohl wieder auf meinen Dreizeiler umsteigen[2]. Grüße -- πϵρήλιο ℗ 18:14, 2. Okt. 2012 (CEST)
Ich habe das Script nochmal so überarbeitet, dass jetzt schon bei einem mouseover geguckt wird, ob es lokale Seiten gibt, das hat gegenüber der oben genannten Version den Vorteil, dass bei einem Klick keine zusätzlichen Wartezeiten mehr anfallen und auch beim Öffnen in einem neuen Tab (mittlere Maustaste) auch die Commonsseite geöffnet wird (wenn die Bedingungen erfüllt sind). Es wäre großartig wenn sich ein Admin das mal ansehen könnte: Benutzer:Hoo man/directLinksToCommons.js - Hoo man (Diskussion) 01:09, 3. Okt. 2012 (CEST)


Bei mir funktioniert es jetzt (leider!) auch nicht mehr, egal mit welchem Browser. Kann noch nicht lange so sein, das wäre mir aufgefallen. Wurde etwas geändert?--Berita (Diskussion) 20:14, 25. Mär. 2013 (CET)

Alle JavaScript-Funktionen waren ausgefallen, weil es eine Änderung gab, die zu einem Fehler geführt hat. Seit dieser Änderung funktioniert wieder alles. --Fomafix (Diskussion) 08:16, 26. Mär. 2013 (CET)
Danke schön.
Tja, ja … MediaWiki_Diskussion:Common.js/Archiv sub dato 20:08, 8. Feb. 2012
Weil ich dich grad sehe:
Frohe Ostern --PerfektesChaos 09:42, 26. Mär. 2013 (CET)
Na ein Glück, danke für die Info.--Berita (Diskussion) 14:22, 26. Mär. 2013 (CET)

Funktioniert nicht immer

Ist an dem Gadget gerade irgendetwas kaputt? Ich werde z.B. nicht weitergeleitet bei File:Roger Willemsen signature.svg. --Patrick87 (Diskussion) 16:14, 29. Apr. 2013 (CEST)

OK, hat sich erledigt, ist eine Limitierung des Skripts, siehe hier. --Patrick87 (Diskussion) 19:26, 29. Apr. 2013 (CEST)
Könnte man nicht zusätzlich prüfen, ob man im Namensraum "Datei" (6) ist, dann prüfen, ob die Datei von Commons kommt (=ob #commons_descr existiert?) und dann weiterleiten? --nenntmichruhigip (Diskussion) 23:17, 7. Mai 2013 (CEST)
  1. Es funktioniert momentan ordnungsgemäß.
  2. Es soll ja auch ein Bild im Artikel angeklickt werden können, und von dort direkt auf Commons gegangen. Die Dateibeschreibungsseite (NR=6) kommt dabei überhaupt nicht vor.
  3. Das Gadget wertet nur Datei-Einbindungen aus, nicht Wikilinks auf eine Dateibeschreibungsseite. Dabei entsteht in HTML ein <img src= und aus der sich anschließenden URL lässt sich entnehmen, ob die Grafik über Commons oder über das lokale Wiki bezogen wird.
LG --PerfektesChaos 23:40, 7. Mai 2013 (CEST)
Ich meinte das als Erweiterung, sodass es auch bei anderen Links einen Klick und kurze Verwirrung erspart. --nenntmichruhigip (Diskussion) 23:56, 7. Mai 2013 (CEST)
  • Das wurde diskutiert, aber es gibt nur Geflacker und nach einigen Sekunden passiert irgendwas Komisches. Ein Gadget braucht mehrere Sekunden nach dem Seitenaufbau, der sich nicht unterdrücken lässt, bis es dann vollautomatisch eine neue Seite aufrufen könnte. Man muss feststellen, dass die Seite nur virtuell ist, und per API abfragen, ob es eine lokale Disku gibt, und könnte erst danach weiter.
  • Außerdem ist es zu Verwaltungszwecken manchmal erforderlich, auch auf leere Dateibeschreibungsseiten zu verlinken und dort zu arbeiten.
  • Dein Vorschlag ist vermutlich mit einem Dutzend Zeilen zu realisieren, wenn ich die jetzt richtig durchgezählt habe.
Gute Nacht --PerfektesChaos 00:04, 8. Mai 2013 (CEST)
  • Mit MW Version 1.22wmf13 gibt es top-loaded Gadgets.
    • Man kann dann mit wgNamespaceNumber und wgArticleId (bei Nichtvorhandensein 0) prüfen, ob man weiterleiten möchte. Es entsteht kein/kaum sichtbares Geflacker für den Benutzer. Die Diskussionsseite würde weiterhin ignoriert. Evtl. noch den Referrer prüfen (ob Benutzer überhaupt von der Wikipedia kommt) und nachsehen, ob URL-Parameter, wie action=edit o.ä. angegeben wurden, in welchem Falle auch nicht weiterzuleiten ist.
  • Aus dem aktuellen Gadget kann $(document).ready( entfernt werden, da es ohnehin vom "bottom of the body" geladen wird. -- RE rillke fragen? 17:07, 20. Aug. 2013 (CEST)
Wir sind schon so oft von Änderungen in der Ladereihenfolge gefoppt worden, dass wir das document.ready besser drin lassen. Wenn das Ereignis bereits eingetreten war, kostet es nicht viel und die Funktion wird sofort ausgeführt. Dann müssen wir nicht bei jedem Umbau in der Gadget-Ausführung und Asynchron-Zeugs erneut auf Fehlersuche gehen. Liebe Grüße --PerfektesChaos 22:33, 20. Aug. 2013 (CEST)

Hallo,

ich habe den harken gesetzt, trotzdem springe ich zur Zeit nicht auf Commons--Vielen Dank und Grüße Woelle ffm (Diskussion) 10:01, 10. Aug. 2014 (CEST)

Durch Gezerre um den neuen Medienbetrachter und Konflikte mit ihm wird in diesen Tagen an dem Gadget herumgebaut; einfach abwarten und schönen Sonntag --PerfektesChaos 10:28, 10. Aug. 2014 (CEST)
+1 Richtig, dürfte momentan wieder gehen, da die WMF die generelle nachträgliche Deaktivierung durch die Community wieder rückgängig gemacht hat. Allerdings müsstest du dann trotzdem den MV eingeschaltet gehabt haben!? → User: Perhelion 11:23, 10. Aug. 2014 (CEST)
PS: Man müsste jetzt ebenfalls die zur völligen Abschaltung verendete Var prüfen. Wenn also z.B. jemand (etwas unorthodox aus welchen Gründen auch immer) diese Option in seine Skinseite haut um ihn abzuschalten. → User: Perhelion 11:30, 10. Aug. 2014 (CEST)

Verdacht auf XSS bei Klammern im Dateinamen

NoScript wertet die Veränderung einer URL zu einer anderen Domain bei src= als getarnte Einschleusung von JS, wenn die URL Paare runder Klammern enthält: WP:TW #NoScript meldet Cross-Site-Script-Versuch (noch laufend).

Abhilfe: 

return currVal.replace( localBase, commonsBase )
              .replace( /(/g, "%28" )
              .replace( /)/g, "%29" );

VG --PerfektesChaos 22:33, 20. Aug. 2013 (CEST)

Special:Permalink/121728553#NoScript meldet Cross-Site-Script-Versuch
Gibt es in der Wikipedia gar kein {{Bearbeitungswunsch}}/ {{Edit request}}?
Die andere Frage ist, ob wir unser Gadget ändern, nur weil NoScript offenbar einen Fehler hat. Solange das keine JavaScript-Links sind, wird auch kein JS ausgeführt. -- RE rillke fragen? 09:39, 21. Aug. 2013 (CEST)
Ich sehe das nicht als einen „Fehler“ an, sondern als legitime wenn auch reichlich vorsichtige Maßnahme gegen Benutzer wie unseren Benutzer:X" onclick="alert('XSS');" title="y und angesichts immer raffinierterer Angriffsversuche angemessen. Schließlich schreibt irgendwas auf eine fremde Domain um (verdächtig!) und da sind Klammerpaare drin (seeeehr verdächtig!).
Ich weiß nicht, was Edit request bei en/Commons sein mag; aber die paar aktiven Techno-Admins beobachten die relevanten Seiten sowieso. Notfalls gibt es irgendwann eine Anfrage auf der BD.
LG --PerfektesChaos 10:12, 21. Aug. 2013 (CEST)
Dürfte mit html5 zusammenhängen, das die Klammern nicht mehr urlencodet im href sind. Interessanterweise liefert MediaWiki die Url im src= noch urlencodet aus. Habe mal etwas eingebaut.
Für Bearbeitungswünsche kann man auch WP:AA nutzen, aber ich schaue ab und an auch die letzten Änderungen von MediaWiki-Namensraum samt Diskussion um das was zu finden. Der Umherirrende 20:44, 21. Aug. 2013 (CEST)
  • Klammern sind wie ' und " anerkannte Anzeichen für XSS.
  • Dies im Hinterkopf, müsste eigentlich ergänzt werden:
return currVal.replace( localBase, commonsBase )
              .replace( /\(/g, "%28" )
              .replace( /\)/g, "%29" )
              .replace( /'/g, "%39" )
              .replace( /"/g, "%34" );
  • Im Prinzip kann man dazu auch unsere schlauen Funktionen benutzen, aber dann muss ich mich erst vergewissern und notfalls warten, ob mw.util präsent ist. Das kann ich zu Fuß besser erreichen.
  • Schon mal hochgeladen: Datei:X" onclick="alert('XSS');" title="y.svg – Sind immer alle Desinfektoren wachsam? Wer kann das garantieren?
  • Ggf. bräuchte es einen Bugzilla, wenn die src ungeschützt herumstehen. Aber ich verstehe das so, dass NoScript anspringt, weil wir eine src= des ausgelieferten Dokuments umschreiben auf eine fremde Domain.

Unsere lieben Techno-Admins sind blitzefix zur Stelle; das flutscht auch so.

Schönen Abend --PerfektesChaos 21:31, 21. Aug. 2013 (CEST)

Wunsch nach Weiterleitung eines Links auf lokale Dateibeschreibungsseite

Oben und an anderen Stellen wurde die Frage aufgeworfen, ob nicht Links auf Dateibeschreibungsseiten genauso weiterleiten könnten wie der Klick auf das Bild.

  • Das Bild leitet immer auf Commons weiter, während der Magnifier usw. weiterhin lokal bleibt.
    • Und das ist auch gut so.
  • Das Problem ist die Disku ohne Dateibeschreibungsseite bzw. nach deren Löschung wegen Transfer auf Commons: Es entstünden unzugängliche unbemerkte Dateidiskus.
    • Das wurde als inakzeptabel eingestuft.
    • Die API-Nachfrage (oder: Hat auf der Seite das "#ca-talk" die class="new" – wofür man auf DOM.ready warten muss) ist daher notwendig.
    • Es bliebe also unvermeidlich, dass das lokale Bild aufflackert und auf DOM oder API wartet, um nach der Disku zu schauen.
    • Techniken, die verlangen, erst über komplizierte URL-Parameter zu erfahren, ob es eine Disku gibt, sind für ein Standard-Gadget nicht geeignet. Desgleichen das Überrennen einer vorhandenen lokalen Disku.
  • Referrer sind oft geblockt; so auch von mir. Wir fassen die üblicherweise gar nicht erst an, um nicht in Schnüffel-Verdacht zu kommen. Irgendwo gibt es auch einen MW-Talk dazu.
  • Es müsste zusätzlich in der URL einen sofort analysierbaren Verhinderungsparameter geben. Wegen Bekanntheit und Vergleichbarkeit bietet sich an: redirect=no oder =0 oder überhaupt ein [?&]redirect= in der URL.

LG --PerfektesChaos 22:33, 20. Aug. 2013 (CEST)

Bei betrachten der Dateibeschreibungsseite von Commonsbildern in de.wp wird der Tab für die Diskussionsseite bereits nach Commons umgebogen, dort ist das erkennen wirklich zu aufwendig. Der Umherirrende 20:55, 21. Aug. 2013 (CEST)
Aha; dann käme man um eine API-Abfrage nicht herum.
  • Ein grundlegend anderer Ansatz wäre, wenn per Bot sichergestellt ist, dass es keine NurCommons-Dateibeschreibungsseite gibt mit existierender Disku oder womöglich einer Unterseite oder Disku-Unterseite.
    • Bei den vermutlich wenigen Fällen mit lokaler Disku müsste dann auf der Dateibeschreibungsseite ein soft redirect angebracht werden mit einer Vorlage:Dateibeschreibungsseite lokal, die auf die Existenz der lokalen Seite(n) hinweist und das Link nach Commons zur expliziten Wahl anbietet.
    • Wenn das sichergestellt ist, kann man aus der curid=0 sofort schließen, dass weitergeleitet werden soll.
VG --PerfektesChaos 21:37, 21. Aug. 2013 (CEST)
Oder nochmals andersherum gedacht:
  • Wenn durch turnusmäßige Bot-Läufe sichergestellt ist, dass es nie dauerhaft eine verwaiste lokale Disku geben kann, sondern deren Inhalte per C&P auf die CommonsTalk geschrieben werden (und sei es manuell; viel mehr als das eine oder andere Dutzend wird das im Jahr ja wohl nicht sein) …
  • … dann kann man dem Vorschlag von Rillke folgen und aus den vor dem DOM bereits analysierbaren Parametern die sofortige Weiterleitung auslösen.
  • Das wäre dann nur durch einen redirect-Parameter in der URL aufzuhalten; oder Gadget abschalten.
VG --PerfektesChaos 20:32, 22. Aug. 2013 (CEST)

Neue Version 11

Unter mw:Snippets/Direct imagelinks to Commons#Code gibt es eine neue Version des Gadgets mit folgenden Verbesserungen:

In MediaWiki:Gadgets-definition sollte 

* CommonsDirekt[ResourceLoader|dependencies=mediawiki.util|default]|Direct-link-to-Commons.js

durch 

* CommonsDirekt[ResourceLoader|dependencies=mediawiki.util,jquery.mwExtension|default]|Direct-link-to-Commons.js

ersetzt werden, weil bereits derzeit $.escapeRE() aus dem Modul jquery.mwExtension verwendet wird. --Fomafix (Diskussion) 13:06, 27. Nov. 2013 (CET)

Da jquery.mwExtension eine Dependency von mediawiki.util ist, ist es auf jedem Fall da, ich habe es aber trotzdem mal explizit erwähnt. Keine Ahnung, ob ein Update erwünscht ist. Vielleicht kann Raymond als "Initiator" dieses Gadget da mal schauen. Es gibt auf jedem Fall lokale Anpassungen, die sich nicht im Snippet wiederfinden. Der Umherirrende 11:25, 30. Nov. 2013 (CET)
Als "Initiator" dieses Gadget war ich nur mutig und habe ein funktionierendes Skript hierher kopiert. Anpassungen/Updates überlasse ich aber extrem gerne den Leute, die besser mit JS zurechtkommen als ich. — Raymond Disk. 13:28, 30. Nov. 2013 (CET)
Ist alles Übung, es gibt aber sicher noch Leute hier, die besser damit zurechtkommen, aber nicht umbedingt die Berechtigungen haben, das auch zu ändern. Den hook für LivePreview und vielleicht auch VisualEditor habe ich eingebaut. PDFs scheinen dadurch zu unterstützt werden, das jetzt auch nach URLs mit title= gesucht wird und nicht mehr Kurzform mit /wiki/. Der Umherirrende 13:51, 1. Dez. 2013 (CET)
Wenn ich alles richtig gemacht habe, sollte es mit dieser Änderung auch Skript-URLs ersetzt werden und keine Fehler auftauchen. Der Umherirrende 14:07, 1. Dez. 2013 (CET)

Neue Version 12

Unter mw:Snippets/Direct imagelinks to Commons#Code gibt es eine neue Version des Gadgets mit folgenden Verbesserungen:

Bitte integrieren. --Fomafix (Diskussion) 11:06, 14. Jan. 2014 (CET)

Wunschgemäß umgesetzt. Bitte kontrollieren: MediaWiki:Gadget-Direct-link-to-Commons.js und MediaWiki:Gadgets-definition. — Raymond Disk. 12:09, 14. Jan. 2014 (CET)

Wurde jetzt standardmässig deaktiviert, für alle (auf deWP)

Grmpf. --Atlasowa (Diskussion) 13:04, 4. Aug. 2014 (CEST)

Admin MBq hat vorgeschlagen, wenn die benannten Probleme programmier-/technisch gelöst werden könnten, könnte das Gadget wieder auf default gesetzt werden. Da IMO der MV nichts ändern kann muss das Gadget 2 Abfragen aufnehmen, die eigentlich in einer Zeile abgehandelt werden könnten. Nämlich ob angemeldet und ob MV an, das wärs! Z.B. mit wgUserName die var ist bei IP's null. Wobei die Option für den MV diese sein sollte mw.user.options.get("multimediaviewer-enable"), da diese für IP's immer enabled zu sein scheint (auch bei deaktiviertem MV), braucht man keinen zusätzlichen User-Check. Daher müsste folgender Code ausreichen.
- if ( mw.config.get( 'wgNamespaceNumber', 0 ) >= 0 ) {
+ if ( mw.config.get( 'wgNamespaceNumber', 0 ) >= 0 && !mw.user.options.get( 'multimediaviewer-enable' )) {
Wobei diese Abfrage so oder so sinnvoll wäre, da wie die IP (in der Adminanfrage) schon erwähnte auch für Benutzer dieses nur unnötig Rechenzeit binden würde (wenn MV enabled). → User: Perhelion 00:28, 7. Aug. 2014 (CEST)
Rückfrage: das bewirkt, dass das Gadget nur arbeitet, wenn der MV disabled ist? Müsste es nicht umgekehrt sein? Das Problem ist, dass der MV bei laufendem Gadget nicht mehr enabled werden kann, weil die entsprechende Schaltfläche auf den deutschen/lokalen Bildbeschreibungsseiten liegt. --MBq Disk 10:32, 8. Aug. 2014 (CEST)
Jain, glücklicher Weise ist der MV für IP's (über diese Var) immer enabled da hier die Abschaltung über Cookie geregelt wird. Daher wird unser Gadget „ganz einfach“ nicht für IP's aktiv und nicht für Benutzer die den MV enabled haben (was gewünscht war). Ich würde einzig einen Haken sehen, wenn Benutzer den MV wie IP's über die Dateiseite anschalten wollen, daher müsste dann ein kleiner Infotipp im MV aufpoppen der auf die Benutzeroption hinweist. Allerdings wenn ich recht überlege dürfte das dann die Aufgabe des MV sein hier eine bessere Lösung zu bieten, da ja eigentlich immer eine Dateiseite vorhanden ist. → User: Perhelion 12:32, 8. Aug. 2014 (CEST)
Verstehe. Gut, ich setze es ein --MBq Disk 13:01, 8. Aug. 2014 (CEST)
Aber das mit dem default ist noch nicht ganz klar. Da mir jetzt die wirkliche Schwäche des MV klar wird. Selbst bei aktiviertem MV auf Commons wird dieser gar nicht aktiviert, daher ist das dortige Zugeständnis nicht wirklich eins. Daher offenbart IMO dieses Gadget nur eine technische Unzulänglichkeit des MV. → User: Perhelion 13:12, 8. Aug. 2014 (CEST)
Hab’s jetzt wieder auf default-on gestellt. Vielen Dank für Deine Hilfe, --MBq Disk 17:13, 9. Aug. 2014 (CEST)
Vielen Dank Euch beiden, Benutzer:Perhelion und MBq! :-) --Atlasowa (Diskussion) 18:57, 10. Aug. 2014 (CEST)

Hallo, kleines Problem: wenn man den MV und Überspringen der lokalen Dateibeschreibungsseite gleichzeitig aktiviert, funktioniert es nicht, man landet trotzdem nur auf der lokalen Seite (öffnen des Bildes in einem neuen Tab).--Sinuhe20 (Diskussion) 12:36, 17. Aug. 2014 (CEST)

Das war ja (leider) der Sinn der Sache⁈ Allerdings müsste man tatsächlich noch einen 2. MV-Parameter prüfen (wie oben erwähnt)
Hier mit zweiter Abfrage:
/**
 * Direct imagelinks to Commons
 * @source [[mw:Snippets/Direct imagelinks to Commons]]
 * @author [[commons:User:Krinkle]]
 * @version 12, with local modifications
 * required modules: jquery, jquery.mwExtension, mw, mw.util, mw.user
 */
if ( mw.config.get( 'wgNamespaceNumber', 0 ) >= 0 && ( !mw.user.options.get( 'multimediaviewer-enable' ) || !mw.config.get( 'wgMediaViewerOnClick' ) ) ) {
	mw.hook( 'wikipage.content' ).add( function ( $content ) {
		var
			commonsBasePath = '//commons.wikimedia.org/wiki/File:',
			commonsBaseScript = '//commons.wikimedia.org/w/index.php?title=File:',
			localBasePath = new RegExp('^' + $.escapeRE(mw.util.getUrl(mw.config.get('wgFormattedNamespaces')['6'] + ':'))),
			localBaseScript = new RegExp('^' + $.escapeRE(mw.util.wikiScript() + '?title=' +
						mw.util.wikiUrlencode(mw.config.get('wgFormattedNamespaces')['6'] + ':'))),
			uploadBaseRe = new RegExp('^' + $.escapeRE('//upload.wikimedia.org/wikipedia/commons/'));

		$content.find('a.image').attr('href', function (i, currVal) {
			if (uploadBaseRe.test($(this).find('img').attr('src'))) {
				return currVal
				.replace(localBasePath, commonsBasePath)
				.replace(localBaseScript, commonsBaseScript)
				// prevent false positive XSS detection in NoScript
				// https://de.wikipedia.org/?oldid=121733234#Verdacht_auf_XSS_bei_Klammern_im_Dateinamen
				.replace(/\(/g, '%28')
				.replace(/\)/g, '%29');
			}
		});
	});
}
→ User: Perhelion 14:51, 17. Aug. 2014 (CEST)
Also bei mir funktioniert es im Moment auch nicht mehr mit dem Überspringen. Hoffe Perhelions Beitrag ist die Lösung dafür. --Anselmikus (Diskussion) 00:40, 18. Aug. 2014 (CEST)
@Anselmikus: Leider nicht, es sei denn du hast unorthodox den MV per wgMediaViewerOnClick, false deaktiviert (so wie es per Gadget und common Hack schon geschehen "war") was jedoch bei dir nicht der Falls zu sein scheint.
Daher die Fragen (ggf. es liegt definitiv nicht am MV): Seit wann? Verwendest du irgendwas besonderes für Internet? Bist du dir der bewussten Einschränkung bewusst, dass die Weiterleitung nur über direkte Bildeinbindungen funktioniert (also nicht über Links)? @Zur Einschränkung könnte man eine Zusatzoption implementieren (ein Var. die man einfach in seine JS-Skin-Seite legt). → User: Perhelion 12:12, 18. Aug. 2014 (CEST)
Ok, also ich kenne mich mit personalisierten Skins und Javascript nicht aus. Habe einfach bei den Einstellungen den MV aktiviert und das Überspringen der lokalen Dateibeschreibungsseite aktiviert. Der MV funktioniert, aber wenn ich eingebundene Bilder in einem neuen Tab öffne, erscheint die lokale Seite. Ich meine das war bis vor kurzem (vielleicht eine Woche) nicht so, da kam direkt die Commons-Seite, auf die ich eigentlich will. --Anselmikus (Diskussion) 13:02, 18. Aug. 2014 (CEST)
Aja, dann ist es das Selbe was Sinuhe20 beschrieben hat. Das ist leider er momentane(?) Kompromiss-Zustand (beides geht nicht... mehr), siehe auch einen Abschnitt hier drunter. → User: Perhelion 14:05, 18. Aug. 2014 (CEST)

WMF möchte dieses Gadget überarbeitet sehen

  • Nach Antwort der WMF zum MB des MB wird („mit der deutschsprachigen Gemeinschaft“) bestrebt nach einer anderen Lösung zu suchen, bzw. dieses Gadget zu ersetzen (was ich als Integration in den MV verstehe).
    Denn folgender Punkt ist ungelöst (wenn man von dem Punkt der generellen Nichtfunktion für IPs absieht):
  • Eine De-/Aktivierung des MV über die Dateibeschreibungsseite für Benutzer, was unter anderm folgendem Punkt zur Verbesserungen des MV indirekt entgegensteht:
    • „Eine noch einfachere Möglichkeit zur Deaktivierung des Werkzeugs;“ (Da dieser dann wie gesagt nicht mehr über den selben Weg aktiviert werden kann)
  • Mögliche Lösungsansätze
    1. Der MV müsste auch über Commons rückerkennend eine Aktivierung bereitstellen - allerdings steht dies auf dem ersten Blick im Konflikt mit der gleichen Option des MV auf Commons - daher müsste eine zweite Schaltfläche her
    2. Die Schaltfläche für die De-/Aktivierung müsste woanders als auf der Dateibeschreibungsseite sein - z.B. als kleines Symbol bei den Bild-Miniaturen, bzw. Bild-Einbindungen (Thumbs) bzw. kompletten Aufruf des MV (wo die Schaltfläche ja ebenfalls wieder ist)
    Eine Integration erachte ich dann doch nicht für besonders sinnvoll, da hier ein klarer Funktionskonflikt vorliegt. Das einzige wäre eine automatische Anschaltung des Gadgets bei Abschaltung des MV.
    → User: Perhelion 23:11, 9. Aug. 2014 (CEST)

Keine Weiterleitung mehr??

hallo,

kann es sein, das die Weiterleitung nicht mehr mag?? ist mir das erste mal vor ca. einer Woche aufgefallen (Das Häkchen ist gesetzt)--Vielen Dank und Grüße Woelle ffm (Diskussion) 10:18, 13. Nov. 2014 (CET)

Bei mir wird bei aktivierter Funktion leider auch die lokale Datei-Seite nicht überprungen. Somit ist diese Funktion nutzlos. Schade! --Timmaexx (Diskussion) 12:38, 16. Nov. 2014 (CET)
Habt ihr eigentlich den Medienbetrachter aktiviert?
Ist der aktiv, so übernmmt er auch die Kontrolle über das fragliche Link und dieses Gadget schaltet sich ausdrücklich ab.
LG --PerfektesChaos 13:03, 16. Nov. 2014 (CET)
Der Harken ist und war bei mir draußen--Vielen Dank und Grüße Woelle ffm (Diskussion) 14:55, 16. Nov. 2014 (CET)
@PerfektesChaos:: Ich habe den MediaViewer und das Gadget aktiviert. Wenn ich mit der mittleren Maustaste auf das Bild klicke, geht damit die lokale Beschreibungsseite auf. Nach Commons komme ich nur mit zwei Klicks (entweder über die lokale, oder schneller den MediaViewer). Lässt sich da was dran ändern? Gerne auch per Userscript... Gruß, styko 10:58, 2. Dez. 2014 (CET)
Du darfst gern dieses Gadget und den MediaViewer gleichzeitig aktivieren.
  • Nur: Das Gadget macht dann nichts mehr und steigt tatenlos aus.
Hintergrund:
  • Ohne MediaViewer stehen die Links auf die Dateibeschreibungsseiten (alle lokal) direkt in der vom Server ausgelieferten Seite.
    • Dieses Gadget sieht sie und biegt die entsprechend geeigneten nach Commons um.
  • Mit MediaViewer haben wir diese Links nicht im Zugriff.
  • Die Geschichte mit der mittleren Maustaste lese ich hier zum ersten Mal.
    • Es steht auch nicht auf der umseitigen Hilfeseite.
    • Ich habe mit Dateien aber nicht viel zu tun; die Hilfeseite müsste schon jemand ergänzen, der das Dingens aktiviert hat und mit Dateien arbeitet.
  • Die Belegung der mittleren Maustaste nachträglich einzufangen und das Link umzubiegen ist eine fiese Nummer. Das klappt kaum, und wenn, dann nur wacklig.
  • In der normalen MediaViewer-Ansicht wird ja schon nur die Direktverlinkung nach Commons angeboten; das ist ja wohl im allgemeinen Sinn.
    • Dann wäre es der passendste Weg, an die Entwickler heranzutreten und die Funktion für die mittlere Maustaste genauso direkt verlinken zu lassen, wie es auch schon auf dem MediaViewer-Fenster passiert.
LG --PerfektesChaos 11:35, 2. Dez. 2014 (CET)
Danke für die schnelle Antwort! Dein letzter Punkt wird wohl die Lösung sein, ist aber wohl leider nur durch die MW-Entwickler umsetzbar. Wo wäre denn die richtige Stelle für einen entsprechenden Bug-Report bzw. Feature-Request? Gruß, styko 13:52, 2. Dez. 2014 (CET)
  • Du kannst dich mit Phabricator amüsieren.
  • Hier in der deutschsprachigen Wikipedia brauchst du nirgendwo weitere Hinweise zu hinterlassen; die Leute, die regelmäßiger mit den Entwicklern zu tun haben, lesen auch hier mit und werden schon tätig, falls sie Lust haben.
  • Wer eine Task aufgemacht hat, hinterlässt hier bitte eine Notiz.
LG --PerfektesChaos 15:47, 2. Dez. 2014 (CET)

Hallo. Scheinbar ist es schon wieder(?) mal so weit: keine "Weiterleitung" mehr zur Beschreibungsseite, um sofort nach Commons zu kommen. Häkchen bei "Weiterleitung" ist gesetzt, MedienBetrachter ausgeschaltet. Was kann ich tun? --Hdamm (Diskussion) 10:45, 6. Sep. 2015 (CEST)

Tschuldigung. Aber gerade eben trat dieses Problem bei einem Foto auf. Jetzt kann ich es leider gar nicht mehr reproduzieren? Hmmm … komisch. --Hdamm (Diskussion) 11:18, 6. Sep. 2015 (CEST)

Problem bei Fließtextlinks

Bei Links dieser Art [[:Datei:Beispiel.jpg]] funktioniert das Gadget nicht. Datei:Beispiel.jpg Gibt es eine Möglichkeit dieses Problem zu lösen?--CENNOXX 11:49, 14. Okt. 2015 (CEST)

Das Gadget ist aktuell nur darauf ausgelegt, Dateiverwendungen nach Commons umzubiegen. Nicht die von dir genannte Dateiverlinkungen. Einfach ist es nicht, weil der Link selber nicht weiß, wo er hinzeigt (anders bei den eingebundenen Dateien, dort kann man in der URL die Herkunft erkennen). Der Umherirrende 12:01, 14. Okt. 2015 (CEST)
@Umherirrender, verstehe deine Aussage jetzt nicht ganz. Der Link weiß nicht wo er hinführt?? So groß ist der Unterschied doch gar nicht. Das Script müsste sogar kürzer werden, da man einfach die extra image/img Abfrage rausnehmen kann (hab's grad mal nachvollzogen). ↔ User: Perhelion  15:06, 14. Okt. 2015 (CEST)
Das Link auf die Beschreibungsseite zeigt nach lokal. Das eingebundene Bild stammt von Commons, wie sich der URL entnehmen lässt. Somit ist zwar bei Bildern, nicht aber bei Links eine direkte Verknüpfung möglich. LG --PerfektesChaos 15:45, 14. Okt. 2015 (CEST)
Achso ja, jetzt. ^^ Dann einfach ein anderen Ansatz (oben wurde ja sogar eine Version wohl umständlich mit Ajax vorgeschlagen) von der Weiterleitungseite (daher wohl ein klein wenig verzögerter, wenn man so will):
/** Redirect (any file-link) to the Commons-file-description-page. Idea from [[:de:WP:TSW]] **/
if (mw.config.get("wgNamespaceNumber") === 6  && $("#commons_descr").length)
	$("head link").each(function(){if($(this).attr("rel")==="canonical")
		document.location.href=$(this).attr("href");});
Was wohl auch die Function der Bildlinks von Dateiverwendungen einschließt (also dieses Gadget ersetzt). Über kompatibilitäts-Probleme bin ich mir jetzt nicht gewahr (hatte diesen Code seit 2012 verwendet). LG ↔ User: Perhelion  15:14, 18. Okt. 2015 (CEST)
Naja, ersetzen kann dieses Konstrukt das bisherige Gadget sicher nicht; denn zurzeit werden die Verlinkungen auf die Bilder auf einen Direktabruf der Commonsseite umgestellt, was auch in der Statuszeile sichtbar würde (könnte man sogar in den Tooltip schreiben).
Der obige Trick lädt erstmal eine lokale Dateibeschreibungsseite herunter, analysiert ihren Seitenkopf, und wenn dann offenbar diese Bedingung erfüllt ist, dann wird die URL umgeschrieben, so dass die Dateibeschreibungsseite auf Commons heruntergeladen wird. Das dauert mit Sicherheit und sogar spürbar länger.
Gleichwohl kann man das sauber und ordentlich hinschreiben und dann die umseitige Codierung ergänzen; „Benutzer, die aus den Artikeln direkt nach Commons wollten, interessierten sich auch dafür, …“
Umseitig ist ohnehin noch nicht auf dem Gipfel der mw-JS-Technik.
LG --PerfektesChaos 17:07, 18. Okt. 2015 (CEST)
Mir ist grad aufgefallen das obiger Code gar nicht mehr richtig funktioniert hat (kann sein dass inzwischen etwas in der Seitenstrukter geändert wurde, jedenfalls war die Bedingung jetzt immer true und führte zu einer Endlosschleife im Seitenaufruf). Wie es auch sei, der Code könnte eine Ergänzung zum Gadget sein, da betr. Bild-Links wohl vorher vom Gadget abgefasst werden, trifft der langsamere Code eh erst in den Ausnahmefällen. ↔ User: Perhelion  03:03, 10. Dez. 2015 (CET)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup_Diskussion:Technik/Skin/Gadgets/CommonsDirekt&oldid=222637221“