Benutzer:DerHexer/Wir machen die Monobooks!
Allgemein
Zunächst wurde herausgearbeitet, dass „Monobook“ nur eine Stylevariante ist. Ein Style oder Skin ist dies, was der Leser sieht; wie die Seite farblich-strukturell gestaltet ist. Dafür wurden verschiedene Stylevarianten gezeigt: Monobook, Modern, Vector, Nostalgia, Cologneblue und andere. Zur Zeit des Vortrages war Monobook noch Standardvariante, es wurde auf die mittlerweile erfolgte Umstellung auf Vector auf commonswiki und enwiki verwiesen.
Wie funktioniert der Aufbau der Seite in der Wikipedia?
Die Grundeinstellungen der Anzeige sind in der Software MediaWiki selbst enthalten und werden über http://bits.wikimedia.org/skins-1.5/(skin)/ [wobei (skin) der jeweiligen Auswahl in den Einstellungen entspricht] geladen – eine Liste dazu befindet sich auf Wikipedia:Skin. Projektbezogene Ergänzungen sind im MediaWiki-Namensraum zu finden. Dabei gilt die Seite MediaWiki:Common.js für alle Skins, MediaWiki:Monobook.js, MediaWiki:Vector.js etc. für die einzelnen Skins. Dies gilt jedoch nicht nur für die Programmiersprache JavaScript (Dateiendung .js), sondern auch für die Formatierungssprache CSS (Cascading Style Sheets; Dateiendung .css) – diese Seiten heißen dementsprechend MediaWiki:Common.css, MediaWiki:Monobook.css, MediaWiki:Vector.css etc. Herausgearbeitet wurde im Gespräch, dass alles, was mit CSS, auch mit JavaScript geändert werden kann, zum Teil aber zu Lasten der Geschwindigkeit; die Implikation in die andere Richtung lässt dies nicht zu. Die Seiten im MediaWiki-Namensraum können nur von Administratoren und wenigen global aktiven Benutzern korrigiert werden. Andere Benutzer können Vorschläge auf den Diskussionsseiten ergänzen.
Eigene Einstellungen kann man unter Special:MyPage/monobook.js (vector.js/.css etc.) anpassen. Dort haben nur der Benutzer selbst und Administratoren Schreibrechte. Wer lange Erweiterungen geschrieben oder eingebunden hat, kann diese modularisieren (also auf einer Unterseite im Benutzernamensraum eine kleingeschriebene JavaScript- oder CSS-Datei auslagern), muss aber darauf achten, auf der monobook.js-Seite diese mit zum Beispiel importScript('Benutzer:(BENUTZERNAME)/(NAME_DER_AUSGELAGERTEN_DATEI).js'); einzubinden. Diese Modularisierung ist gewünscht, damit auch andere Benutzer die zum Teil sehr hilfreichen Funktionen nutzen können, ohne gleich das ganze Skript zu verwenden, das zum Teil inkompatibel zu anderen Erweiterungen sein kann. Sie werden zurzeit auf Wikipedia:Skin gesammelt (siehe unten).
Verschiedene Monobook-Skripte
Im Anschluss wurde im Vortrag gezeigt, wie verschiedene Monobook-Skripte aussehen. Exemplarisch wurde dies an PDDs Monobook (siehe FAQ), DerHexers Adminmonobook und Ds Monobook durchgeführt. Zugleich wurde eine zukunftsweisende Erweiterung von Revvar für PDDs Monobook vorgestellt, in der man einfach nur noch Module per Klick an- und abwählen braucht, ohne selbst sich durch die Quelltexte mit Programmierkenntnissen durchzukämpfen.
Verbreitung der Skripte
Dann wurde die Frage gestellt, wie man auf eigene sinnvolle Erweiterungen hinweisen kann. Neben separaten Anmerkungen auf wikipediainternen Funktionsseiten wie WP:AAF, WP:AN, WP:FZW etc. kann für ausgereifte, für viele Benutzer hilfreiche Erweiterungen eine Übernahme in die so genannten Gadgets (siehe Wikipedia:Gadgets; in den Einstellungen irreführend „Helferlein“ genannt) durchgeführt werden. Auch diese befinden sich im MediaWiki-Namensraum, werden auf MediaWiki Diskussion:Gadgets-definition vorgeschlagen und von Administratoren freigeschaltet. Daraufhin kann jeder Benutzer sich separat in den Einstellungen diese hinzufügen und wieder abschalten.
Exkurs – Wie programmiere ich etwas in JavaScript
Wie weiter oben geschrieben, muss man eine Programmiersprache beherrschen – hier also JavaScript; mit dieser kann man sich durch den vom Parser der einzelnen Internetseite generierten Quelltext durcharbeiten. Den Quellcode steuert man mit document. an. Um ein bestimmtes Element, dem eine Identifikation (kurz id) vom Parser übergeben wurde, zu verändern, kann man dieses in JavaScript über document.getElementById('(ID)') aufgreifen. Sollte es keine id geben, kann man auch die HTML-Tags (also zum Beispiel <body>) ermitteln, indem man alle diese mit document.getElementsByTagName('(TAGNAME)'); abfragt. Das Ergebnis liest der Programmierer in Schleifen und Bedingten Anweisungen und Verzweigungen auf und passt es dem Programmierziel an. Beim Vortrag wurde das nicht objektorientierte Programm Benutzer:DerHexer/linktoca.js und das objektorientierte Skript Benutzer:D/monobook/admin.js gezeigt. Sinnvoll sind auch Kombinationen mit Datenbankabfragen, um komplexere Aufgaben einfach zu erledigen.
DOM
PDD erklärte das DOM, Document Object Model, eine Spezifikation einer Schnittstelle für den Zugriff auf HTML- oder XML-Dokumente. Einfach gesagt, kann man aus diesem Dokument auslesen, wo auf der Seite welche Elemente zu finden sind; und diese dementsprechend ansteuern. Die Struktur ändert sich durch den Wechseln von Monobook zu Vector derartig, dass ein gewisser Teil der bestehenden Skripte angepasst werden muss.
API
Als API (“Application Programming Interface”) wird eine Datenbankschnittstelle, also eine Schnittstelle zum einfachen Zugriff auf eine Datenbank, bezeichnet. Für jedes Projekt von Wikimedia gibt es eine eigene API, in der deutschsprachigen Wikipedia befindet sich diese auf http://de.wikipedia.org/w/api.php , auf der – in englischer Sprache – alle Funktionen vorgestellt und mit Beispielen unterlegt werden. Daraus ergibt sich das Problem, dass man mit den lokal gespeicherten Skripten, für die die API primär gedacht ist, aufgrund einer Einschränkung der meisten Browser nicht in einem anderen Projekt Abfragen ausführen kann. Es ist somit nicht möglich, aus der deutschsprachigen Wikipedia heraus zum Beispiel den Status von Bildern auf Wikimedia Commons abzufragen. Dieses Problem lässt sich gegenwärtig nur durch eine Verlagerung der Skripte auf den secure-Server der Wikimedia Foundation beheben. Da auf diesem ein sicherer Zugang zu allen Wikis auf einem Server liegt, sind damit auch weltweite Abfragen möglich. Als Beispiel wurde ein Programm gezeigt, mit dem Benutzerkonten in verschiedenen Sprachen mit nur einem Klick versteckt werden können: m:MediaWiki:Gadget-hideuser.js (siehe auch bugzilla:14476).
Beispielhafte Funktionalität
Mit der API kann man nicht nur effizient und ohne Benutzerinterface Kategorien, Vorlagen, die letzte Änderungen, Verweise, Links etc. abfragen, sondern auch bei Besitz der nötigen Rechte Benutzer sperren, Artikel löschen, schützen, verschieben, zurücksetzen, importieren oder bearbeiten und E-Mails verschicken. Als Beispiel wurde http://de.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Lüneburg&rvlimit=10&rvprop=ids%7Cflags%7Ctimestamp%7Cuser%7Csize%7Ccomment%7Cflagged%7Ccontent&rvdir=older gezeigt, die letzten zehn Änderungen des Artikels „Lüneburg“. Mit dieser Funktion kann man zum Beispiel auch das Exportlimit von 1000 Versionen umgehen. http://de.wikipedia.org/w/api.php?action=query&prop=links&titles=Lüneburg&plnamespace=10&pllimit=100 zum Beispiel zeigt alle Vorlagen an, die im Artikel Lüneburg verwendet werden. Die Abfrage lässt sich auch für andere Namensräume anpassen, sowie für Interwiki- und externe Links. Nicht alle dieser Informationen sind aus MediaWiki selbst direkt abzulesen.
Die Funktionalität ist nicht nur für Artikel, sondern auch für Bilder verfügbar; so zeigt http://de.wikipedia.org/w/api.php?action=query&titles=File:Albert%20Einstein%20Head.jpg&prop=imageinfo&iilimit=50&iiend=20071231235959&iiprop=timestamp%7Cuser%7Ccomment%7Curl%7Csize%7Csha1%7Cmime%7Cmetadata%7Carchivename%7Cbitdepth übersichtlich die wichtigsten Metainformationen eines Bildes. Gleiches gilt auch für Vorlagen und Kategorien. Schließlich kann man noch diverse Statistiken abfragen; wie viele Bilder gibt es, die mit T beginnen und maximal 10 kB groß sind, wo sind die Bilder eingebunden? Gleiches gilt auch für Artikel, interne Links, Kategorien (deren Namen, aber auch die Namen der eingebundenen Artikel/Dateien), Benutzer, Links-auf-diese-Seite, (lokale und globale) Sperren, Gelöschte-Beiträge, Vorlagen (wo sie eingebunden sind), Logbücher, allgemein letzte Änderungen, die Suche, Benutzerbeiträge, die Weblink-Suche, Zufallsseiten, geschützte Seiten und Seiten mit veralteten Sichtungen. Für all diese Abfragen gibt es diverse Such- und Filtermechanismen und Parameter. Ergänzungen an der API werden auf Wikipedia:Projektneuheiten mit „Änderungen an der API“ markiert, künftige Änderungen hier vermerkt.
Kommunikation mit dem Nicht-Programmierer
How-tos, Skins
Bisher sind nur wenige Hilfeseiten/How-tos vorhanden, exemplarisch sei auf Benutzer:PDD/monobook FAQ oder Benutzer:DerHexer/revisionjumper verwiesen. Auf Wikipedia:Skin werden nur die Funktionen einzelner Skripte vorgestellt, selten wird nur angegeben, wie man das jeweilige Programm einbindet. Einen Abschnitt zum Einbinden ganzer Skripte gibt es nicht. Der Problematik wurde vom Publikum zugestimmt, Wikipedia:Skin müsste verbessert werden. Eine Arbeitsgruppe fand sich aber noch nicht direkt, um für Laien gedachte Erklärungen mit sinnvollen Screenshots unterlegt vorzubereiten. Häufig kennt nur der Ersteller des Skriptes sämtliche Möglichkeiten des Skriptes.
Modularisierung
Anliegen der Teilnehmer war es, komplette Skripte zu entzerren und Teile in Modulen zur Verfügung zu stellen. Dann könnte man Wikipedia:Skin auch dementsprechend und ähnlich Wikipedia:Helferlein anpassen. Nur sind nicht mehr alle Benutzer, die auf Wikipedia:Skin ihre Programme zur Verfügung stellten, (in diesem Bereich) aktiv oder an Wartung interessiert. Hier stellte sich das Frage, inwieweit auch externe Experten an dem Programmcode anderer Benutzer arbeiten dürften, um diesen laienverständlicher zu gestalten.
Gadgets
Für jedes Gadget sollte es eine (ausführliche, laienverständliche) Erklärung geben. Unklar war den Teilnehmern, wie die Reihenfolge der Gadgets bestimmt werde und wer sie überhaupt warte. Auch hier stellt sich dann die Frage, ob fremde Benutzer Programme anderer Programmierer korrigieren oder warten dürften. Auf dem Toolserver werden auch die sinnvollsten Programme nur aufgrund der Inaktivität der Programmierer entfernt. Dies sollte hier vermieden werden. Gadgets sollten wie auch die meisten anderen, international nützlichen Programme globalisiert werden. Dazu können die Texte in einer seperaten Datei ausgelagert und je nach Systemsprache ausgegeben werden. Daneben sollten die Skripts und Gadgets auch so geschrieben werden, dass man sie über die sichere Verbindung über secure nutzen kann.
Programmierwünsche
Für Botaufträge steht die Seite Wikipedia:Bots/Anfragen zur Verfügung, früher wurde die Seite Wikipedia:Datenbankabfragen regelmäßig bedient, dies will man nun wiederbeleben. Eine Anfrage für die Programmierung von Skripts gibt es bisher aber noch nicht. Auf WP:MBW bzw. Benutzer:DerHexer/Monobookwünsche betreibt DerHexer seit 2007 eine Seite, die zunächst der Wartung eigener Skripte diente und auflistete, was von anderen Benutzern auf ihren jeweiligen Benutzerdiskussionsseiten angeboten wird, und später auch für Auftragsarbeiten genutzt wurde. Diese soll nun in den Wikipedianamensraum verschoben werden, damit auch andere Interessierte und Fachleute sich solchen Anfragen widmen können. Dies muss dann publik und leicht zugänglich gemacht werden.
