MediaWiki Diskussion:Gadgets-definition/Archiv 2013

Wikidata-Einträge anzeigen

Letzter Kommentar: vor 11 Jahren6 Kommentare2 Personen sind an der Diskussion beteiligt

Die ungarische Wikipedia hat das Tool Display Wikidata Info on Wikipedia in ihre Liste der Standard-Helferlein aufgenommen. Ich habe bislang durchweg positive Erfahrungen mit ihm gemacht. Da die Sprachlinks in Zukunft zentral von Wikidata gesammelt und verwaltet werden, wird das Interesse an dem Tool vermutlich groß sein. --Kolja21 (Diskussion) 01:06, 15. Jan. 2013 (CET)

Auf der ungarischen Wikipedia ist WikiData seit gestern standardmäßig aktiv, siehe WP:NEU#14. Januar. Der Umherirrende 17:28, 15. Jan. 2013 (CET)

Jup, und am 30. sollen Italienisch und Hebräisch folgen. Hilfreich ist das Tool auch für Admins, die Verschiebereste u.a. Einträge löschen. Ohne einen kurzen Blick auf Wikidata, führen diese Löschungen dort zu Fehlermeldungen. --Kolja21 (Diskussion) 03:04, 25. Jan. 2013 (CET)

Also, wenn überhaupt nur als copy des Quellcodes und nicht als „importScriptURI“ auf ein jederzeit änderbares Skript eines unbekannten Benutzers auf einem fremden Projekt, das jetzt vor allem Admins einbinden sollen.
Wobei es eigentlich nicht unser (menschliches) Problem ist, wenn durch eine Löschung ein Linkbreak auf Wikidata auftritt; das soll Wikidata gefälligst selbst per Bot herausfinden. Außerdem kann auf Wikidata der Name bis auf Weiteres registriert bleiben, auch wenn der Artikel momentan nicht aktiv ist. Vielleicht wird er wieder unter diesem Titel angelegt; er müsste nur als zurzeit nicht erreichbar markiert sein. Im Wikidata-Konzept kann ich dazu nichts finden.
Nicht aus der Doku der Wikidata geht auffindbar hervor, was passiert, wenn die Seite im Inhaltswiki verschoben wurde und noch eine WL existiert. Aktualisieren die sich dann automatisch, per turnusmäßiger Bot-Analyse? Sonst bricht jede Schreibfehlerkorrektur oder unsere beliebte Klammerzusatzkonventionsschubserei dort oder verursacht menschliche Mehrarbeit.
Offensichtlich speichert Wikidata auch nur den Titel und nicht die letzte bekannte curid im Zielprojekt. Das wäre allerdings als Rückfallposition sinnvoll, wenn ohne WL verschoben wird. Wird hingegen unter altem Titel die Seite neu angelegt, ist schon der Titel die erste Wahl. Aber das sind Probleme von Wikidata, nicht unsere.

VG --PerfektesChaos 10:30, 25. Jan. 2013 (CET)

Kein Admin wird durch das Gadget gezwungen, irgendwelche Arbeit für Wikidata zu erledigen. Es gibt aber sicherlich mehr Leser und Autoren wie mich, die es schätzen, die Verknüpfung auf einen Blick zu sehen, statt über den Umwegs eines Edit-Buttons, den es bislang nur in der ungarischen Wikipedia gibt, herauszufinden, ob ein Wikidataeintrag zu dem Thema vorliegt. --Kolja21 (Diskussion) 06:02, 26. Jan. 2013 (CET)

Du schreibst:
Hilfreich ist das Tool auch für Admins, die Verschiebereste u.a. Einträge löschen. Ohne einen kurzen Blick auf Wikidata, führen diese Löschungen dort zu Fehlermeldungen.

Daraus ergibt sich deine Erwartungshaltung, dass in Zukunft alle Admins bei Löschungen und im Zusammenhang mit Verschiebungen einen kurzen Blick auf Wikidata werfen sollen, um dort ggf. manuell Änderungen vorzunehmen und Fehlermeldungen abzuwenden.
Eine solche Arbeitstechnik ist strikt abzulehnen.
- Bislang wurde die Konsistenz der magic interlanguage durch die Interwiki-Bots und ihre menschlichen Betreiber wahrgenommen und automatisiert aktualisiert. Wir haben uns bei der Seitenverwaltung nie darum gekümmert, welche Interlanguages es in anderen Projekten geben könnte.
- In gleicher Weise hat das Wikidata-Projekt zukünftig die Wartung und Pflege zu übernehmen.
Die auf den offiziellen allgemeinen Projektseiten von Wikidata gegebenen Informationen sind äußerst mager. Es wird lediglich das Format des Eintrags beschrieben.
- Eine Darstellung, auf welche Weise in den folgenden Jahren Wartung, Pflege und zeitnahe Aktualisierung erfolgen soll, ist nicht auffindbar.
- Insbesondere fehlt eine konkrete Spezifikation der Prozesse und der ausführenden Personenkreise.
Ich erwarte von Wikidata, dass turnusmäßig (etwa täglich) alle referenzierten Seiten der Fremdprojekte analysiert werden, ob die Verweise noch aktuell sind.
- Findet sich eine Weiterleitung, so ist automatisch die neue Zielseite einzutragen.
- Wird die bezogene Seite nicht (mehr) gefunden, so ist der Eintrag automatisch als zeitweise nicht mehr verfügbar zu markieren.
  - Vielleicht handelte es sich nur um einen Schreib- oder C&P-Fehler bei der Neueintragung.
  - Vielleicht wurde die Seite gelöscht. Dann ließe sich der Seitentitel gleichwohl für eine künftige erneute Anlage unter gleichem Titel oder Wiederherstellung vormerken.
  - Dass die Seite unter diesem Titel gelöscht worden ist, lässt sich kinderleicht automatisch feststellen. Menschliche Ressourcen bei den Projekten dafür aufzuwenden wäre dreist; die Klicks der Admins lassen sich für andere Zwecke besser einsetzen.
  - Intelligent ist es, jeweils automatisch die Seitenkennnummer (curid) gefundener Seiten intern zu hinterlegen; kam es zu einer Verschiebung ohne Weiterleitung, lässt sich die Seite wiederfinden. Wurde nie eine curid gefunden, hat die Seite nie existiert und es gab einen Schreib- oder C&P-Fehler bei der Neueintragung. Die curid hat ausschließlich automatisch im Hintergrund verwaltet zu werden. Kommt es zu einer neu angelegten Seite unter dem bisher bekannten Seitentitel und damit zu einer neuen curid, ist nunmehr diese curid zu hinterlegen. Bei regulärer Verschiebung mit Weiterleitung bliebe die curid ohnehin unverändert.
Nur von sehr wenigen Experten benötigte Spezialsoftware bieten wir nicht allgemein als Gadgets an; wenn wir einbinden, dann nur entweder hier vollständig beobachtbaren Quellcode oder aber Importe aus fremden Projekten, deren Bearbeiter uns langjährig bekannt sind.

--PerfektesChaos 10:08, 26. Jan. 2013 (CET)

Es geht hier um ein Schwesterprojekt, das auf der Hauptseite verlinkt ist; kein Grund Panzerabwehrgeschütze aufzufahren. Niemand will dich angreifen oder verknechten. Und was die "wenigen Experten" angeht: Wikidata hat bereits jetzt mehr Einträge als die deutschsprachige Wikipedia und wird demnächst die Sprachlinks zentral verwaltet. Jeder, der Sprachlinks setzt, zählt in Zukunft also zu den Experten. Wenn du ein besseres Gadget für diesen Zweck kennst, können wir gerne auch das nehmen. --Kolja21 (Diskussion) 02:17, 27. Jan. 2013 (CET)

Weiterleitungs-Check

Letzter Kommentar: vor 11 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

Hallo! Analog zu "Der Begriffsklärungs-Check hebt Links auf Begriffsklärungsseiten farblich hervor." wäre es zumindest zeitweise hilfreich, wenn man einen "Weiterleitungs-Check", der Links auf Weiterleitungen hervorhebt, in den Einstellungen als Helferlein aktivieren könnte. So sieht man bei Bearbeiten/Korrigieren von Seiten sofort, wo eine Seite direkt, wo via Weiterleitung verlinks ist. Manche Weiterleitungen machen Sinn (wird künftige evtl. ein eigener Artikel), manche können aber gleich ausgebessert werden (z. B. WL von veralteten auf gültige Artnamen etc.).

Vorgeschlagene Optik (weniger "aufdringlich" als bei dem BKS-Check - wo IMHO übrigens auch ein schmaler roter Rahmen reichen und ggf. sogar die Lesbarkeit verbessern könnte!): schmaler oranger oder dunkelgelber Rahmen und ein hochgestelltes "WL". Evtl. ist es möglich, mit dem "WL" nicht die Zielseite der Weiterleitung (wie mit dem Linktext), sondern die WL-Seite selbst aufzurufen?

Um Fälle der ersten Art nicht oder anders (blauer Rahmen statt orangem) darstellen zu können, müsste im Quelltext ein entsprechender Marker als "Absichtserklärung" rein (z. B. <wlok>[[Linktext]]</wlok> für "Weiterleitung ok" oder so...). Gibt es irgendwann einen eigenen Artikel unter dem Lemma der bisherigen WL, macht dieser Marker auch nix - für ganz genaue Artikelpflege könnte man den dann wieder anders markieren (grauer Rahmen mit durchgestrichenem WL z. B.), weil der Marker ja dann auch entfernt werden kann (oder ein Bot macht das mal...). --kai.pedia (Dis.) 14:10, 25. Jan. 2013 (CET)

Gibt es schon: WP:CSS #redirect; allerdings zum Selber-in-die-common.css-Schreiben und nicht edel über ein Häkchen in den Einstellungen. In der Farbgestaltung bist du aber dadurch völlig frei.

Liebe Grüße --PerfektesChaos 14:18, 25. Jan. 2013 (CET)

Alternativ auch über importScript('Benutzer:Flominator/BklRedir.js'); in deiner monobook.js, vector.js oder common.js. Vorteil: Es werden auch doppelte Weiterleitungen, Weiterleitungen auf BKLs und Links auf Übersichtsartikel wie Weltausstellung erfasst und gleich das Ziel des Redirs angezeigt. --Flominator 12:19, 24. Feb. 2013 (CET)

Diaschau für Galerien

Letzter Kommentar: vor 11 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt

Genau so etwas hatte ich gesucht - eine Funktion, die aus statischen Galerien mit einem Klick eine Diaschau macht! Dank se4598 hat mir den entscheidenden Tipp gegeben: Auf Commons gibt es das Gadget „Slideshow", das als Helferlein für diese Funktion sorgt. Vielleicht kann man es noch ein wenig eindeutschen. Wie dem auch sei: Unbedingt in die deutsche Wikipedia aufnehmen!!! Gruß --Ökologix (Diskussion) 16:03, 1. Mär. 2013 (CET)

Gibt es jemanden, der hierzu Stellung nehmen möchte? --Ökologix (Diskussion) 19:50, 15. Mär. 2013 (CET)

Helferlein für Spezialseiten

Letzter Kommentar: vor 11 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo! Dem Hinweis in Hilfe:Helferlein folgend bringe ich meinen Vorschlag hier ein: kann man die Spezialseiten (z. B. Spezial:Verwaiste_Seiten) und/oder die Helferlein auch so gestalten, dass z. B. die Anzeige von BKL-Seiten auch in den Spezialseiten funzt? Im o. g. Beispiel der verwaisten Seiten wäre das eine große Hilfe: BKL-Seiten können durchaus verweist sein, da diese ja "nur" Sucheingaben besser zuzuordnen helfen sollen... --kai.pedia (Dis.) 13:57, 6. Mär. 2013 (CET)

Grundsätzlich wäre das möglich.
Das Wikipedia:Helferlein/Begriffsklärungs-Check müsste dazu verändert werden. Es schließt im Moment die Spezialseiten explizit aus (letzte Zeile von MediaWiki:Gadget-bkl-check.js).
Dein Wunsch müsste allerdings eine benutzerdefinierte Option werden. Es belastet die Anzeige der Seiten und Benutzer mit magerem Netzwerk-Kontingent, und auf sehr vielen Spezialseiten ist die Abfrage auch wirklich sinnlos.
Dazu müsste das ganze Helferlein einmal komplett neu programmiert werden. Es war damals auf der Höhe der Zeit und sehr fortschrittlich; heute gibt es vielerlei, was man anders machen würde (mw.libs, mehr Benutzeroptionen, Namensraum- und Seitenfilter [Disku], „Benutzerin“, mw.Api, jQuery).
Nachdem wir uns hier ausgetauscht haben, werde ich diesen Thread auf die Disku des Helferleins kopieren und auch an anderen Stellen Reklame machen.
Am Rande bemerkt, ist dies hier die Seite für den Vorschlag komplett neuer Helferlein, aber das macht nichts; wir finden uns schon durch.
Einstweilen würden mich mal andere Beispiele von Spezialseiten interessieren, bei denen du das sinnvoll findest. Spezial:Verwaiste Seiten ist ja ganz nett, aber wegen der Beschränkung auf 2000 Seiten nicht so arg im Mittelpunkt des Interesses.

Bis dann --PerfektesChaos 14:28, 6. Mär. 2013 (CET)

Hallo! Danke für die wohlwollende Prüfung/Aufnahme! - wobei neu programmiertes Helferlein ist ja fast schon neues Helferlein :-)

auf Spezial:Älteste_Seiten wäre die Anzeige der BKL auch hilfreich (da ändert sich halt manchmal nix mehr) - aber die ist ja außer Betrieb...

was wohl unabhängig von der Helferlein-Programmierung funzt sind die Markierung von Weiterleitungen 0 das geht auch auf Spzielseiten.

wenn ich Wikipedia:Helferlein/Begriffsklärungs-Check richtig lese, könnte man sich auch irgendwelche Kategorien markieren lassen (nicht nur technische wie BKL und LK) = also z. B. alle Finken (wie Buchfink usw.), d. h. eine thematische Eingrenzung/Hervorhebung vornehmen

sowas suche ich schon lange - für diverese Listen (wie die ungesichteten usw.) - leider gibt es für manchen Themenbereiche kaum suchfreundliche=übergeordnete Kategorien (wie Vogelarten, Pflanzenarten, Tierarten...), denen auch die Einzelartikel zugeordnet sind - anders isses mit "Mann", "Frau" usw. = da würde das gehen, oder? [naja muss vllt. doch in die Helferlein-Dis. gehen?...]

cu --kai.pedia (Dis.) 17:55, 6. Mär. 2013 (CET)

noch ne Seite, BKL-Anzeige gut wäre: auf Spezial:Begriffsklärungsverweise könnte man BKL, die auf BKL verweisen (oft mit siehe auch) überspringen...

was hier gut wäre: wenn man erkennen könnte, ob aus einem BKH heraus auf die BKL gesprungen wird oder aus dem Text heraus = DAS wäre doch was für ein neues Helferlein (oder einen neue Funktion des bestehenden...)? --kai.pedia (Dis.) 18:00, 6. Mär. 2013 (CET)

Naja, Spezial:Begriffsklärungsverweise ist wieder so ein Ding, das auf 2000 begrenzt ist, und damit für das praktische Arbeiten unbrauchbar (haben wir im guten sechsstelligen Bereich). Immerhin kurzfristig aktualisiert. Aber überall, wo ein BKH drinsteht, schlägt das auf dieser Spezialseite auf.
Diese Spezialseiten kommen aus den Kinderjahren der Wikipedia. Ein kleines oder ganz junges Wiki kann damit was anfangen, wir schon lange nicht mehr.
Mit der Aktivität würdest du dir meist keinen Gefallen tun. Wenn du auf Weblinksuche bist, würde das Skript immer durch 500 Ergebnisse graben und ggf. zu jeder Seite beim Server anfragen. Auch, wenn du den Namensraum etwa auf Wikipedia: eingeschränkt hast. Immerhin merkt das Skript das, und fragt den Server dann nicht.
Dass ein Link ein Redirect ist, sieht die Datenbanktabelle sofort und liefert diese Info in der HTML-Seite gleich mit. Für BKL usw. fragt das Skript erst blockweise beim Server nach, in welche Kategorien das Link eingeordnet ist.
Man könnte bei einer Neuprogrammierung eine Benutzeroption einbauen, dass man in der Werkzeugbox ein Link haben möchte, dass auf dieser normalerweise nicht dafür vorgesehenen Seite eine BKL-Analyse manuell auslöst werden kann; das ist relativ simpel.
Im Regelfall sehe ich auf keiner Spezialseite einen Anlass für BKL-Check.
Elementar einfach kannst du dir Links auf Namensräume markieren: WP:CSS #Namensräume
Kategorien gingen über das Skript; du stellst aber schon richtig fest, dass die Zielseiten nicht alle in der Kategorie „Finken“ stehen, sondern bei Buchfinken, Heftfinken, Schmutzfinken.

Schönen Abend --PerfektesChaos 21:52, 7. Mär. 2013 (CET)

Bearbeiten-Links

Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Hat jemand auf dem Schirm, dass sich laut Meta ab dem 8. Mai

die Standardposition der Bearbeiten-Links ändert (sie befinden sich dann direkt rechts neben den Überschriften) und
sich der Klassenname des beinhaltenden <span>s ändert (statt class="editsection" in Zukunft class="mw-editsection").

D.h. das Gadget Bearbeiten-Links Links muss angepasst werden und Bearbeiten-Links Rechts wird überflüssig (da Standard) sollte jedoch durch ein Gadget ersetzt werden, dass den bisherigen Standard wiederherstellt (Bearbeiten-Links rechts am Fensterrand).

Der neue CSS-Code wird dafür jedoch denkbar einfach (Beispiel zum Wiederherstellen des bisherigen Standards, kopiert von Meta):

.ltr .mw-editsection {
  float: right;
}
.rtl .mw-editsection {
  float: left;
}

P.S. Irgendwas scheint auch bereits im Gange zu sein, denn die Barbeiten-Links werden bereits direkt rechts neben den Überschriften angezeigt. Die Mediawiki-Software ist aber definitiv noch nicht aktualisiert, scheint also an anderer Stelle jemand die Finger im Spiel zu haben. --Patrick87 (Diskussion) 01:11, 3. Mai 2013 (CEST)

Hat jemand.

Trotzdem danke fürs Mitdenken und Erinnern, könnte ja auch mal untergegangen sein.

VG --PerfektesChaos 09:21, 3. Mai 2013 (CEST)

Typografie.js

Letzter Kommentar: vor 11 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

Von einem anderen Benutzer wurde mir geraten, mein Helferlein zur automatischen Umwandlung von Anführungszeichen, Gedankenstrichen, Auslassungspunkten etc. in die typografisch korrekte Version beim Eingeben hier vorzuschlagen. Das tue ich hiermit; das Skript ist zu finden unter Benutzer:Jowereit/Typografie. Jowereit (typografie.js) 21:04, 14. Jul. 2013 (CEST)

Ehrlich gesagt, wäre es mir lieber, wenn es „dein“ Benutzerskript bliebe.

In dem Moment, in dem das hier als „empfohlenes Gadget“ aufgenommen würde, übernimmt die Community gegenüber allen Benutzern die dauerhafte Verantwortung für ordnungsgemäßes Funktionieren, Wartung und Pflege. Die Community der Programmierer ist aber bereits restlos ausgelastet.
Es stammt ausweislich Kommentar und VG aus 2007. Ja, 2007 hatte man das so geschrieben.
Heute bedürfte es zunächst einer Totalsanierung. Siehe:
Sobald es in einer aktuellen Fassung vorliegt, können wir gern wieder darauf zurückkommen.
- Die Doku ist ja schon mal sehr hübsch.
Zu konkreten Einzelfragen hilft gern die WP:TW.

Liebe Grüße --PerfektesChaos 20:47, 18. Jul. 2013 (CEST)

Meiner Ansicht nach sollte das Skript in ein Eingebeschema für ULS umgewandelt und direkt in MediaWiki aufgenommen werden. Dies hätte folgende Vorteile:

Es würde wesentlich kürzer, da nur die Ersetzungsregeln definiert werden müssen, nicht die Funktionen für die Cursorposition etc.
Falls/sobald ULS mit VE kompatibel ist (was Aufgabe der entsprechenden Entwickler ist), wird es automatisch in VE funktionieren, gleiches gilt für WikEd.
Das Ein- und Ausschalten wäre konsistenter.
Es wäre noch leichter zu aktivieren als durch ein Gadget.

Nachteile sind:

Konfiguration durch globale Variablen ist nicht möglich.
Kompatibilität mit WikEd geht erst einmal verloren.
Funktionen, die mit markiertem Text arbeiten, funktionieren nicht mehr.
Solange es nicht offizieller Bestandteil von ULS ist, ist es extrem eklig zu testen.

Wie dem auch sei, hier ein schneller Versuch:

( function ( $ ) {
	'use strict';

	var de = {
		id: 'de-typographic',
		name: 'Typografie für Deutsch',
		description: 'input method for typographic characters in German',
		date: '2013-07-18',
		URL: 'https://de.wikipedia.org/wiki/Benutzer:Jowereit/Typografie',
		author: 'Benutzer:Jowereit, Benutzer:Schnark',
		license: 'CC-by-sa 3.0',
		version: '1.0',
		maxKeyLength: 1000000,
		patterns: function ( text ) {
			var lastChar = text.charAt( text.length - 1 ), nextToLastChar = text.charAt( text.length - 2 );
			switch ( lastChar ) {
			case '"':
				if ( nextToLastChar === '=' || text.lastIndexOf( '="' ) > text.lastIndexOf( '>' ) || text.lastIndexOf( '="' ) > text.lastIndexOf( '|}' ) ) {
					return text;
				} else if ( '\n ([{|'.indexOf( nextToLastChar ) > -1 ) {
					if ( text.lastIndexOf( '„' ) > text.lastIndexOf( '“' ) ) {
						return text.substring( 0, text.length - 1 ) + '‚';
					} else {
						return text.substring( 0, text.length - 1 ) + '„';
					}
				} else {
					if ( '0123456789'.indexOf( nextToLastChar ) > -1 && text.lastIndexOf( '„' ) <= text.lastIndexOf( '“' ) ) {
						return text.substring( 0, text.length - 1 ) + '″';
					} else if ( text.lastIndexOf( '‚' ) > text.lastIndexOf( '‘' ) ) {
						return text.substring( 0, text.length - 1 ) + '‘';
					} else {
						return text.substring( 0, text.length - 1 ) + '“';
					}
				}
				break;
			case '-':
				if ( nextToLastChar === '–' ) {
					return text.substring( 0, text.length - 2 ) + '---';
				} else if ( nextToLastChar === '-' && text.charAt( text.length - 3 ) !== '-' && text.charAt( text.length - 3 ) !== '!' ) {
					return text.substring( 0, text.length - 2 ) + '–';
				}
				break;
			case '.':
				if ( nextToLastChar === '.' && text.charAt( text.length - 3 ) === '.' ) {
					return text.substring( 0, text.length - 3 ) + '…';
				}
				break;
			case '\'':
				if ( nextToLastChar === '’' || nextToLastChar === '′' ) {
					return text.substring( 0, text.length - 2 ) + '\'\'';
				} else if ( '0123456789'.indexOf( nextToLastChar ) > -1 ) {
					return text.substring( 0, text.length - 1 ) + '′';
				} else if ( nextToLastChar !== '\'' ) {
					return text.substring( 0, text.length - 1 ) + '’';
				}
				break;
			case '>':
				if ( nextToLastChar === '–' ) {
					return text.substring( 0, text.length - 2 ) + '-->';
				}
			}
			return text;
		}
	};

	$.ime.register( de );

}( jQuery ) );

jQuery.ime.languages.de.inputmethods.push( 'de-typographic' );
jQuery.ime.sources['de-typographic'] = {
	name: 'Deutsch (Typografie)',
	source: 'rules/ml/ml-transliteration.js' //DUMMY
};

Zum Testen:

In den Editmodus gehen, als Sprache des Eingabefeldes Englisch auswählen (oder irgendetwas anderes als Deutsch).
Die JavaScript-Konsole des Browsers aufrufen und den obigen Code ausführen. (In Firefox Umschalt+F4, Code einfügen, Strg+R)
Als Sprache wieder Deutsch und Typographie als Eingabeschema wählen.
Testen
Eingabeschema wieder ausschalten.

--Schnark 09:34, 19. Jul. 2013 (CEST)

old-diff-style.css

Letzter Kommentar: vor 10 Jahren20 Kommentare8 Personen sind an der Diskussion beteiligt

„Stellt Versionsunterschiede in den bisherigen Farben dar“

Ich bitte darum, dass diese Beschreibung aussagekräftiger wird. Meines Erachtens gab es in den letzten sieben Jahren immer wieder mal Änderungen bezüglich der Farben, zum Teil foundationübergreifend, manchmal auch nur lokal oder skinabhängig. Ich habe mir schon vor Jahren andere Farben verpasst, so dass ich mich jedesmal frage: Welche sind eigentlich die bisherigen Farben? -- 32X 10:35, 4. Nov. 2013 (CET)

Wo ist das Problem? Zielgruppe dieses Gadgets sind genau die Benutzer, die bei der Umstellung, zu der es eingeführt wurde, laut geschrien haben: "Wir wollen die bisherigen Farben zurück!" Wer nicht weiß, was mit den alten Farben gemeint ist, der braucht das Gadget nicht.

Das ist natürlich an sich kein Grund, dass die Beschreibung tatsächlich suboptimal ist, aber die Qualität unserer Gadgets ist so miserabel, dass es auf eine schlechte Beschreibung mehr oder weniger nun wirklich nicht ankommt. --Schnark 10:39, 4. Nov. 2013 (CET)

Wo das Problem ist? Auf Spezial:Einstellungen#mw-prefsection-gadgets wird mir eine Option mit nichtssagender Beschreibung angeboten. Mit jeder unkonkreten Beschreibung mehr vermüllt die Seite und hilfreiche Gadgets werden schwieriger auffindbar. -- 32X 12:17, 4. Nov. 2013 (CET)

Hilfreiche Gadgets – sehr guter Witz. (SCNR) --Schnark 12:23, 4. Nov. 2013 (CET)

Warum ist Benutzer:Schnark eigentlich kein Administrator hier auf de? Dann könnte mal jemand ein bisschen Bewegung in die Gadget-Landschaft bringen. Auf Commons – und dort gibt es wegen mangelden Multimedia-Supports in MediaWiki wesentlich mehr Gadgets – sind beispielsweise >90% der Gadgets auf ResourceLoader umgestellt. Das erfordert jedoch ausgiebiges Testen und Anpassen "fremden" Codes. Hier hat wohl kein Admin Lust darauf. Ferner fehlt eigentlich überall ein "Try it", mit dem der Nutzer die Gadgets gleich austesten kann, Nutzungsstatistiken und Angaben, wann ein Gadget das letzte Mal aktualisiert wurde und deren Einfluss auf das Ladeverhalten der Seite, sowohl objektiv als auch durch Nutzerbewertungen, übersichtlich in einer Tabelle angeordnet und ein "Did you know?" das über hilfreiche, aber eher unbekannte Gadgets cross-wiki-wise informiert, sowie einem System, das Benutzeraktionen auswertet und darauf basierend Vorschläge macht. -- RE rillke fragen? 13:01, 4. Nov. 2013 (CET)

Dann könnte ich nicht mehr über die Gadgets meckern … --Schnark 09:13, 5. Nov. 2013 (CET)

Dafür könntest Du über Deine Kollegen herziehen und über die "kleinen" Benutzer. -- RE rillke fragen? 15:47, 6. Nov. 2013 (CET)

„Stellt Versionsunterschiede in den bisherigen Farben, Rot und Grün, dar“ -- RE rillke fragen? 13:01, 4. Nov. 2013 (CET)

Nicht, dass ich etwas gegen diesen Vorschlag hätte, aber ich sehe im Gegensatz zu 32X noch immer nicht den Grund, warum alle Benutzer alle Beschreibungen verstehen müssen. Wer eine Beschreibung nicht versteht, der wird doch wohl einfach das so beschriebene Gadget nicht aktivieren, und das ist hier genau das erwünschte Verhalten. Und wenn es wirklich Benutzer geben sollte, die bei der ersten unverständlichen Beschreibung die Seite mit den Gadgets wieder schließen, dann kommen die über „Zeigt die Beiträge von 16er und 24–32er CIDR-Ranges und Wildcardbenutzernamen wie „Splark*“ an.“ gar nicht erst hinaus. --Schnark 09:13, 5. Nov. 2013 (CET)

„Stellt Versionsunterschiede in rot und grün dar“. Wo ist das Problem, dass man da überhaupt drüber diskutieren muss? --TMg 01:18, 6. Nov. 2013 (CET)

Ich glaube, was Schnark möchte ist, dass das Gadget möglichst wenig benutzt wird um es alsbald wieder entfernen zu können. Ob ein Gadget überhaupt der richtige Weg war, wage ich zu bezweifeln. Damit haben wir den Benutzer-Frust von den MW-Entwicklern weggenommen und auf uns geladen, denn der wird sich entladen, sobald das Gadget abgeschaltet wird. -- RE rillke fragen? 15:47, 6. Nov. 2013 (CET)

Ach so, stimmt auch wieder. Die Vorgehensweise finde ich gut. Auf diese Weise wird die Community schrittweise an Neuerungen heran geführt und wir müssen nicht auf einen Schlag 100 % der Benutzer überzeugen. Der nächste Schritt wäre dann wirklich, das Gadget zu entfernen und den immer noch nicht überzeugten Benutzern zu zeigen, wie sie es auf dem Weg über ihr Benutzer-CSS trotzdem noch haben können. Ist irgendwo einsehbar, wie viele Benutzer die Gadgets benutzen? --TMg 11:40, 7. Nov. 2013 (CET)

Nutzung
- Ja, man kann einmal jährlich bei den Serveradmins eine Statistik bestellen, wer die Option in den Einstellungen hat.
- Wir haben auch eine, ich hab aber vergessen wo.
- Die Daten sind allerdings kaum brauchbar, weil auch alle verstorbenen und aus sonstigen Gründen inaktiven Benutzer erfasst sind, und so gut wie Null ist nach meiner Erinnerung kein Gadget angekreuzelt.
- Wie viele Leute etwas aktiv nutzen, ist nicht bekannt; dazu bräuchte man die Abruffrequenz des Gadget-Codes aus dem letzten Monat.
Legacy
- Nicht jeder Autor ist scharf auf die allerneuesten buntesten Super-Features, sondern möchte einfach nur in der vertrauten Arbeitsumgebung Artikel schreiben.
- So lange technisch problemlos unterstützbar, sollte man die Gewohnheiten der Altgedienten nicht umschmeißen.
- Es sind die Menschen auch unterschiedlich geistig flexibel und mit Skins und Einstellungen vertraut.
- Wer neu dazukommt, lernt nur den neuen Stil kennen und weiß nichts von den alten Gegebenheiten. Dann muss auch weder das Gadget noch seine Beschreibung verstanden werden.
- Nach mehreren Jahren sind viele von denen, die das noch von früher (vorm Krieg) kennen, aus unterschiedlichen Gründen nicht mehr dabei; die anderen sind nun schon so viele Jahre dabei, dass etwas Einrichtung in den MyPages allmählich doch zumutbar wäre. Aber gerade unter denen sind auch viele, die bei jeder Gelegenheit lautstark fordern, dass die WP zu Design, Funktionalität, Struktur von 2005 zurückzukehren habe, und monobook muss auch wieder Standard werden.
- Für das Rot-Grün-Dings ist es zurzeit noch etwas früh; es stört auch nicht, wenn das da rumsteht. So viele Gadgets bieten wir ja auch nicht an.
Namensgebung
- Jeder Name mit old, new, erweitert, Zusatz, Extra, klassisch als sinntragendem Unterscheidungsmerkmal ist Schrott.

Schönen Tag --PerfektesChaos 13:08, 7. Nov. 2013 (CET)

Zur Statistik: Es stimmt nicht, dass man nur einmal jährlich eine Statistik von Serveradmins bekommen kann. Auf dem Toolserver sind die Einstellungen anonymisiert zu finden. Ein wenig schwierig ist es durch die automatisch aktivierten Gadgets, dafür müsste man entsprechend eine Liste machen, wie oft sie deaktiviert wurden. Die Daten sehen derzeit wie folgt aus (wobei auch entfernte Gadgets da noch Datenleichen nach sich ziehen):

mysql> SELECT up_property, count(*) AS c FROM user_properties_anonym WHERE up_property LIKE 'gadget-%' AND up_value='1' GROUP BY up_property ORDER BY c DESC LIMIT 0,100;
+------------------------------------------------+-------+
| up_property                                    | c     |
+------------------------------------------------+-------+
| gadget-Rechtschreibpruefung                    | 11739 |
| gadget-Extra-Editbuttons                       | 10087 |
| gadget-toolserver-integration                  |  8020 |
| gadget-Vorlagenmeister                         |  7515 |
| gadget-bkl-check                               |  7198 |
| gadget-HotCat                                  |  6855 |
| gadget-wikEd                                   |  6699 |
| gadget-Einleitung-bearbeiten                   |  6182 |
| gadget-navigation-popups                       |  5913 |
| gadget-Suchfokus-Hauptseite                    |  4400 |
| gadget-Pfeil-hoch                              |  3805 |
| gadget-Personendaten                           |  2728 |
| gadget-WikiMiniAtlas                           |  2574 |
| gadget-PB                                      |  2207 |
| gadget-markAdmins                              |  2088 |
| gadget-revisionjumper                          |  2002 |
| gadget-revisionCounter                         |  1763 |
| gadget-contribsrange                           |  1572 |
| gadget-Rot-Gruen-Sehschwaeche                  |  1187 |
| gadget-Zeitzonenkonverter                      |  1143 |
| gadget-Doppel-s-Schreibung                     |  1010 |
| gadget-ReferenceTooltips                       |   988 |
| gadget-OpenStreetMap                           |   979 |
| gadget-editsection-right                       |   825 |
| gadget-Screenreader-Optimierung                |   801 |
| gadget-PrettyLog                               |   592 |
| gadget-imagesiblings                           |   494 |
| gadget-Persoenliche-Bekanntschaf               |   370 |
| gadget-rightsfilter                            |   364 |
| gadget-PermaPageLink                           |   290 |
| gadget-editsection-left                        |   281 |
| gadget-old-diff-style                          |   224 |
| gadget-articlefeedback                         |   213 |
| gadget-Erweiterte-Navigationsleiste-Quicklinks |   211 |
| gadget-HideVisualEditor                        |   120 |
| gadget-editsection-align-end                   |   102 |
| gadget-highlightemptysummary                   |    34 |
| gadget-TAXman-tool                             |    27 |
| gadget-InlineInterwikisInGruen                 |    15 |
| gadget-Gadgets-InlineInterwikisI               |     9 |
| gadget-Gadgets-Personendaten                   |     4 |
| gadget-InterwikisInGruen                       |     2 |
| gadget-CommonsDirekt                           |     1 |
| gadget-Quicklinks                              |     1 |
+------------------------------------------------+-------+
44 rows in set (8.56 sec)

Eine Statistik, wieviele _aktive_ Nutzer welche Gadgets aktiviert haben könnte wiederum wirklich nur ein Serveradmin erstellen. Grüße --APPER\^☺☹ 23:46, 7. Nov. 2013 (CET)

Soll ich jetzt wirklich glauben, dass ich der einzige bin, der gadget-CommonsDirekt (MediaWiki:Gadget-Direct-link-to-Commons.js) aktiviert hat? Oder stimmt was mit deiner Abfrage nicht? --Patrick87 (Diskussion) 23:57, 7. Nov. 2013 (CET)

Also ich hab da auch seit Jahr und Tag einen Haken drin :) --тнояsтеn ⇔ 08:36, 8. Nov. 2013 (CET)

Da das Gadget als Standard für alle Benutzer aktiviert ist, sollte eigentlich kein Benutzer dieses Gadget laut Datenbank aktiviert haben (so wie das auch für gadget-old-movepage der Fall ist), der eine Benutzer hat das Gadget wohl ganz am Anfang, wie es noch kein Standard war, aktiviert und seitdem nichts mehr an seinen Einstellungen verändert. Bei den beiden Gadgets wäre dagegen interessant, wie viele sie deaktiviert haben. (Ich kann versicheern, es ist jeweils mindestens ein Benutzer.) --Schnark 09:28, 8. Nov. 2013 (CET)

Wie in meiner Einleitung geschrieben funktioniert diese Abfrage nicht für standardmäßig aktivierte Gadgets. Dort muss man zählen, wieviele es deaktiviert haben. Also das noch nachgereicht. Die Werte sind sehr merkwürdig... vllt kennt sich ja jemand mit der Datenbankstruktur aus. Dass 2728 Personendaten einblenden, aber 45846 sie bewusst ausblenden, kommt mir merkwürdig vor. Es gibt aber viele im Bereich zwischen 40000 und 45000, ich tippe darauf, dass ein "0"-Eintrag gemacht wird, wenn man ein anderes Gadget an- oder ausschaltet. Und bei den Personendaten sind es die meisten, weil es eines der ältesten Gadgets ist. Zeigt aber auch, wie hoch die Anzahl derjenigen ist, die bereits jemals sich auf die Gadget-Einstellungsseite verirrt haben und etwas geändert haben.

mysql> SELECT up_property, count(*) AS c FROM user_properties_anonym WHERE up_property LIKE 'gadget-%' AND up_value!='1' GROUP BY up_property ORDER BY c DESC LIMIT 0,100;
+----------------------------------+-------+
| up_property                      | c     |
+----------------------------------+-------+
| gadget-Personendaten             | 45846 |
| gadget-Doppel-s-Schreibung       | 45399 |
| gadget-Screenreader-Optimierung  | 45048 |
| gadget-Rot-Gruen-Sehschwaeche    | 44955 |
| gadget-navigation-popups         | 44350 |
| gadget-toolserver-integration    | 44038 |
| gadget-HotCat                    | 43938 |
| gadget-Vorlagenmeister           | 43729 |
| gadget-wikEd                     | 43607 |
| gadget-Einleitung-bearbeiten     | 43406 |
| gadget-Pfeil-hoch                | 43197 |
| gadget-Extra-Editbuttons         | 43003 |
| gadget-Rechtschreibpruefung      | 42280 |
| gadget-WikiMiniAtlas             | 41310 |
| gadget-Suchfokus-Hauptseite      | 33502 |
| gadget-bkl-check                 | 31917 |
| gadget-contribsrange             | 24169 |
| gadget-Persoenliche-Bekanntschaf | 20743 |
| gadget-revisionjumper            | 10518 |
| gadget-OpenStreetMap             |  7527 |
| gadget-TAXman-tool               |  2253 |
| gadget-InlineInterwikisInGruen   |   349 |
| gadget-old-movepage              |   324 |
| gadget-CommonsDirekt             |   151 |
| gadget-Gadgets-Personendaten     |   121 |
| gadget-Gadgets-InlineInterwikisI |   116 |
| gadget-InterwikisInGruen         |    11 |
| gadget-gadgets-InlineInterwikisI |     3 |
| gadget-gadgets-Personendaten     |     3 |
| gadget-CleanDeleteReasons        |     2 |
| gadget-inlineInterwikisInGruen   |     1 |
| gadget-personendaten             |     1 |
+----------------------------------+-------+
32 rows in set (31.66 sec)

Grüße --APPER\^☺☹ 14:23, 8. Nov. 2013 (CET)

Ist denn gesichert, dass !='1' gleichbedeutend mit ='0' ist? Ich traue MediaWiki durchaus zu, dass ein aktiviertes Gadget je nach Lust und Laune als 1, true oder 42 gespeichert wird, und dann auch noch funktioniert. --Schnark 09:29, 9. Nov. 2013 (CET)

Alles was in der Datenbank ist und für php true ergibt, ist eine aktive Einstellung ("truthy"). Ein Überblick könnte man sich über:

SELECT up_property, up_value, count(*) AS c
  FROM user_properties_anonym
 WHERE up_property LIKE 'gadget-%'
 GROUP BY up_property, up_value ORDER BY c DESC

verschaffen. Früher war es so, das für jedes Gadget eine Zeile in der Datenbank gespeichert wurde, daher sind einige der alten Gadgets mit so vielen Einträgen vorhanden. Wenn ein solcher Benutzer die Einstellungen jetzt ändern und speichern würde, sollte sich das ganze selber bereinigen, da nur die Abweichungen zum Default gespeichert werden. Ob allerdings alte, nicht mehr vorhandene Gadgets auch aus dem Einstellungen fliegen, weiß ich nicht. Der Umherirrende 09:44, 9. Nov. 2013 (CET)

Gadget	Standard	= 1	≠ 1
bkl-check		7198	31917
CommonsDirekt	ja	1	151
contribsrange		1572	24169
Doppel-s-Schreibung		1010	45399
Einleitung-bearbeiten		6182	43406
Erweiterte-Navigationsleiste-Quicklinks		211
Extra-Editbuttons		10087	43003
HotCat		6855	43938
imagesiblings		494
markAdmins		2088
navigation-popups		5913	44350
old-diff-style		224
old-movepage	ja		324
PB		2207
PermaPageLink		290
Personendaten		2728	45846
Pfeil-hoch		3805	43197
PrettyLog		592
Rechtschreibpruefung		11739	42280
ReferenceTooltips		988
revisionCounter		1763
revisionjumper		2002	10518
rightsfilter		364
Rot-Gruen-Sehschwaeche		1187	44955
Screenreader-Optimierung		801	45048
Suchfokus-Hauptseite		4400	33502
toolserver-integration		8020	44038
Vorlagenmeister		7515	43729
wikEd		6699	43607
WikiMiniAtlas	ja	2574	41310
Zeitzonenkonverter		1143

Fazit:

Dreieinhalb Monate und 18 Kilobyte später hat sich *N*I*C*H*T*S* verändert. Klasse. -- 32X 20:07, 15. Feb. 2014 (CET)

Vorschlag für neues Gadget: projectNotice

Letzter Kommentar: vor 10 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Wikipedia:Technik/Baustellen/projectNotice mit der Bitte um Unterstützung. Schönes Wochenende --PerfektesChaos 17:23, 30. Nov. 2013 (CET)

Pro Hört sich super an! Ich benutze schon lange mit Bewunderung die Variante von "fliegelfagel". -- ΠЄΡΉΛΙΟ 22:18, 17. Apr. 2014 (CEST)