Wikipedia:Umfragen/Technische Wünsche

Diese Umfrage ist zeitlich beschränkt: Vom 1. September 2013 bis 1. November 2013

Phase 1: Wünsche sammeln sie zu bewerten bis Anfang Oktober
Phase 2: Wünsche priorisieren/bewerten durch Unterschrift

Problemstellung

Der Großteil der Softwareentwicklung für MediaWiki geschieht heutzutage durch angestellte Programmierer der Wikimedia Foundation bzw. für Wikidata durch Mitarbeiter von Wikimedia Deutschland. Was genau gemacht wird, ist öffentlich einsehbar: mw:Wikimedia Engineering.

Bei den Autoren des Projektes zur Erstellung einer Enzyklopädie namens Wikipedia regt sich immer mehr Widerstand gegen „von oben“ verordnete neue Features, weil manches im Betastadium als Standard aktiviert wird oder einfach für unnötig erachtet wird.

Dem Autor dieser Umfrage (Raymond) ist jedoch kein gezieltes Befragen der Community nach ihren technischen Wünsche bekannt. Welche Features für MediaWiki fehlen, sind dringend nötig oder wünschenswert?

Ziel

Ziel dieser Umfrage soll eine (priorisierte?!) Liste von technischen Wünschen sein, die an die WMF und den Chaptern weitergegeben wird in der Hoffnung, dass die WMF erkennt, wo den Autoren der technische Schuh am meisten drückt. Chapter, die sich überlegen, wofür sie Spendengelder ausgeben möchten, sind herzlich eingeladen, sich ihrem Budget entsprechend Punkte herauszupicken.

Umfang

Ausdrücklich erwünscht sind hier auch die Wünsche der Schwesterprojekte und Wikimedia Commons. Falls ein Wunsch sehr projektspezifisch ist, bitte mit dem Projektnamen kennzeichnen. Hier können genannt werden (bitte jeweils mit kurzer (!) Erklärung, für welchen Autorenkreis der Bug/das Feature von Bedeutung ist):

Offene Bugs/Featurwünsche auf Bugzilla.
Tools vom Toolserver/ToolLabs, die in MediaWiki integriert werden sollten, damit Abhängigkeiten von externen Servern gelöst werden
Frei formulierte Wünsche

Nicht Bestandteil dieser Umfrage sind Wünsche in Bezug auf den Toolserver/ToolLabs.

Wünsche

Phase 1: Sammeln von Wünschen (bitte kurz fassen). Das Abgaben von Stimmen für eine Priorisierung erfolgt in Phase 2 (ungefähr ab Anfang Oktober)

(Noch) unsortiert

Optimierung der Performance der MediaWiki-Software auf Benutzerseite: Reduzierung / Optimierung von vorhandenen JavaScript-Funktionen, Implementierung neuer Funktionen soweit möglich ohne JavaScript, Einstellungsmöglichkeit für Benutzer um nicht benötigte "Ressourcenfresser" (z.B. VisualEditor, Universal Language Selector) zu deaktivieren.
Zusätzlich zu dem Absatz-Link "[Bearbeiten]" einen Link "[Inhaltsverzeichnis]", um auf langen Seiten schneller nach oben zu gelangen. - Besser einen Link "[nach oben]". (nicht immer gibt es ein Inhaltsverzeichnis)
Auf Seiten wie [1] das Löschlog nicht direkt einblenden, sondern über einen Link anzeigen, da das Löschlog oft persönlichkeitsrechtlich bedenkliche Formulierungen enthält, die dann von Suchmaschinen indiziert werden
projektübergreifend: Eine Möglichkeit, die eigenen (bzw. die eines anderen Nutzers) Edits auf einer bestimmten Seite anzeigen zu lassen. Also ein Filter nach Nutzernamen in der Versionsgeschichte.
Eine Art "Difflink-on-click", bei dem man durch gleichzeitiges Drücken von ein oder zwei Funktionstasten und einfachen Klick auf einen Diskussionsbeitrag in der Zwischenablage die Adresse eines Links (nicht notwendig eines echten Difflinks) erhält, der den Beitrag herausgehoben im Kontext (entweder dem aktuellen oder dem zum Zeitpunkt der Entstehung) darstellt.
Einrichtung einer personalisierten Startseite (z.B. Autorenportal statt Hauptseite)
Integration des GeoHacks in die Media-Wiki-Software (z. B. als Spezialseite wie in Wikivoyage (Beispiel, mw:Extension:MapSources).
Bug 39038: Halbgesperrte Seiten sollten nach kurzfristiger Vollsperre wieder zurück auf Halbsperre gehen (und nicht auf ungesperrt). Siehe auch Disk auf AN.
Eine saubere technische Lösung für Icons in der rechten oberen Ecke (also so etwas wie mw:Extension:ArticleEmblems)
Ein virtueller Assistent, der (nicht nur) neuen Benutzern kontextbezogen nützliche Tipps gibt (Beispiel, nicht ganz ernst gemeintes Beispiel
Möglichkeit den Inhalt der Zusammenfassungszeile im nachhinein (in transparenter Form) zu verändern
Möglichkeit auch für "normale" Benutzer Softwarefehler zu melden, etwa wie bei Gmail: Nach einem Klick auf "Softwarefehler melden" wird automatisch ein Screenshot erzeugt, auf dem man private Daten schwärzen und die relevanten Stellen hervorheben kann, dazu schreibt man einen kurzen Text als Erklärung und schickt das Ganze automatisch an die richtige Stelle
Eine Seite, auf der erfahrene oder mit genauen Anweisungen ausgestattete Benutzer ähnlich wie im Firefox auf about:config alles nach ihren Vorstellungen anpassen können
Versionsunterschiede sollten nicht dadurch praktisch unbrauchbar werden, dass ein Abschnitt in zwei Abschnitte aufgeteilt wurde oder umgekeht zwei Abschnitte vereinigt wurden. Zudem sollten auch "unsichtbare" Änderungen (Leerzeichen, Sonderzeichen) sichtbar sein (bugzilla:13462, bugzilla:13466)
Möglichkeit zum Duplizieren und Vereinigen von Artikeln ohne den Umweg über Export und Import
Integration der beiden Abrufstatistik-Tools (http://stats.grok.se/ und seiner "Weiterentwicklung" http://toolserver.org/~emw/wikistats/) in die Mediawikisoftware inkl. Sicherstellung der dazu nötigen Datenbasis
Zeitgemäßer Nachfolger für CAPTCHAs ([2] und weitere Threads in dem Umfeld)
Liste der von einem Benutzer angelegten Artikel ohne Notwendigkeit externer Tools
automatisches Einfügen geschützer Leerzeichen (Wikipedia:Typografie/Automatische Leerzeichen)
Tooltips der Interwikilinks sollten Sprache auf Deutsch (bzw. allgemein Sprache des Benutzers) anzeigen (bugzilla:5231)
"Links auf diese Seite": Trennung in direkt gesetzte Links und Links, die in einer Vorlage gesetzt sind. Liste sortiert nach diesen Vorlagen. (Z. B.: ein Fußballspieler hat 2 Links aus dem Artikeltext, aber 50 aus einer Navileiste). --AndreasPraefcke (Diskussion) 10:36, 4. Sep. 2013 (CEST)[Beantworten]
Löschen aller reiner InterwikiBot-Aktionen aus den Versionsgeschichten.
Neuberechnung der Byte-Änderungen in allen Versionen, damit die unsinnigen Byte-Angaben bei Versionsgeschichten von importieren Artikeln wie hier beseitigt werden und danach auch nicht mehr auftreten.
Anzeige von Weblinks in der Zusammenfassung wie im Fließtext.

Bearbeiten

Tabellen in einer Form bearbeiten können, wie man es seit einigen Jahrzehnten aus Office-Programmen kennt. Zumindest rudimentärste Dinge wie Spalten/Zeilen einfügen, löschen und umstellen. Bonuspunkte bei Beherrschung aller üblichen Wikitableformatierungen.
Syntaxhervorhebung fürs Editieren eines Artikels im Quelltext.
Möglichkeit Artikelbearbeitungen zwischenzuspeichern (mw:Extension:Drafts)

Kategorien

Neues Kategoriensystem, das die Kategorien nicht mehr im Artikeltext speichert. Kategorienänderungen könnten dann in einem eigenen Logbuch erscheinen, die Versionsgeschichte von Seiten würde bei häufiger Umkategorisierung geschont und Benutzer nicht mehr mit Kategorienänderungen auf der Benutzerseite gestört werden. Ebenso könnten Kategorien bot-unabhängig verschoben und geleert werden.
WP:CatScan in die Software integrieren (bugzilla:5244)
Kategorien sollen wie Artikel verschiebbar werden (Zusätzlich vielleicht grafisches drag&drop in einem Kategorienbaum?)
Kategorien in der Suche verwenden (sollte mit CirrusSearch funktionieren)
Kategorien nach Wikidata migrieren
Massiv ausgebautes Kategoriensystem zu einem noch freier verwendbaren Tagging-System einerseits sowie vollwertigen Subjekt-Prädikat-Objekt-Beziehungen andererseits (z. B. "Personenartikel" "ist Mitglied von" "Bandartikel").
Möglichkeit, sich auf einer Kategorieseite nicht nur die direkt in der Kategorie einsortierten Seiten zeigen zu lassen, sonder auch solche, die in den Unterkategorien stehen; also alle Seiten in einer Liste.
Kategorie-Schnittmengen-Suche
Eine Kategoriensystem mit Suche, das Anleihen von Facebooks Graph Search nimmt. Sprich: Suchanfragen a la "Alle europäischen Könige, die zwischen 960-1500 gelebt haben und an einem Kreuzzug beteiligt waren" (so ähnlich zumindest).
Explizite Schnittmengenkategorien (Kirchengebäude in Hintertupfingen, Katholische Kirche in X-Land, Barocke Kirche in Y-Land, Bonifatiuskirche in Z-Land, …) abschaffen und durch dynamische Abfragen ersetzen
Kategorienänderungen durch Nachfragen (Willst du dies wirklich?) zu Autorenwerk ändern. Automatisierte Bot-Massenbearbeitungen für Kategorien abschaffen.
Cat-a-lot für Artikel.

Beobachtungsliste

Bug 50893 (Beobachtungsliste und RC): Darstellung von Links auf Wikidata als externe Links (leicht andere Farbe)
Sprachen-/Projektübergreifende Beobachtungsliste (Bug 3525)
Flexiblere Artikelbeobachtung: Mail-Benachrichtigung bei größeren Änderungen / Definition von Filtern und Schwellwerten / Möglichkeit, Änderungen bestimmter Benutzer zu black-/whitelisten
richtig funktionierende RSS-Feed von der Beobachtungsseite:
- Mit anzeige des (gekürzten) Diffs
- Filterung der Edits wie bei Beobachtungsseite, per URL-Argument
- Link zur Versionsgeschichte und zum Diff
- Angabe Größenunterschied
Beobachtungsliste – Möglichkeit eine Kategorie auf neue Artikel hin zu beobachten (Bug 7148)
Beobachtungsliste – Möglichkeit einen User zu beobachten (dessen Änderungen) (Bug 470)
Die Möglichkeit, einzelne Abschnitte von Seiten beobachten zu können (z.B. nur eine bestimmte Lösch- oder Relevanzdiskussion)
Übersichtlichere Beobachtungsseite (z. B. Bug 20444)
Ein Prioritäts-Parameter für die Beobachtungsliste mit der Möglichkeit nach dieser Priorität sortieren zu lassen.
So eine Art von „Wiedervorlage“. Zeilen in der Beobachtungsliste nicht einfach als „gelesen“ markieren - wenn man es angeschaut hatte. In seltenen Fällen möchte man später an die Bearbeitung erinnert werden und nicht adHoc eingreifen.
Beobachtungsliste mit automatischem Reload (so wie Facebook, Twitter, und alle Webmail-dinste es auch haben) und Ton (abstellbar) bei neuen Bearbeitungen
am ende der Beobachtungsseite einen "ältere Anzeigen"-Link wie bei Blogs
G ebündelte Mailbenachrichtigung wie bei Mailman (täglich, wöchentlich, …)
Eine Beobachtungsliste für alle Wikimedia-Wikis.
Möglichkeit, (reine) Kategorisierungsbearbeitungen aus der Beobachtungsliste auszublenden
Möglichkeit die Beobachtungliste thematisch zu ordnen und die Seiten thematisch dort ablegen zu können
Filter zum Ausblenden bereits gesehener Änderungen.
Konfigurierbare Beobachtungslisten. Neben einer "Master-" auch projektbezogene Beobachtungslisten anlegbar.

Dateien

Bug 17497: Hochladen ermöglichen von OpenDocument-Dateien (OpenOffice, LibreOffice)
Technisch sauberes Verschieben von Dateien nach Commons unter Beibehaltung der Versionsgeschichte und des Benutzernamens
Ein geführter Upload-Dialog, in dem man explizit anklicken bzw. auswählen muss "das Bild wurde von mir selbst gemacht", "ich möchte mit folgendem Namen attributiert werden", "ich wähle die folgende Lizenz", "das Bild zeigt..." usw.
Dieser sollte (zumindest bei Anfängern) auch verhindern, dass Dateien komplett ohne Metaangaben (Beispiel: Datei:Logistikzentrum Vogelperspektive.jpg in der ersten Version) hochgeladen werden können
Möglichkeit größerer Uploads auf Commons, damit auch größere Filmdateien hochgeladen werden können.
Bessere Integration von Wikimedia Commons in anderen WMF Projekten: Keine separaten Dateibeschreibungsseiten, eine zentrale (internationale) Diskussionsseiten zu Dateien, Änderungen an Dateien auf Commons auch in der lokalen Beobachtungsliste, etc.
Commons: Bearbeiten von SVG-Dateien mit nahtloser Web-Oberfläche für die gängigsten Browser (bugzilla:38271)
Commons: Diff für Dateiformate, die üblicherweise lesbaren Text enthalten (Feature: mit zwei Vorschaubildchen und rot eingefärbten Änderungen in der Grafik selbst) (bugzilla:42566)
Commons/ Chemie: Strukturformeleditor mit Web-Oberfläche (da Rillke gerade privat an einem solchen Projekt arbeitet, wird er wahrscheinlich auch eine Community-Version (AGPL license) bereitstellen; diese wird mol-files auf Unterseiten der Dateiseiten abspeichern und SVGs, damit MediaWiki sie rendern kann)
Fehlerfreies (und hochqualitatives) Rendering von SVG-Grafiken in den Wikimedia Projekten – entweder durch Ablösen von librsvg oder durch Unterstützung der Entwicklung (Bug 51555 und Liste mit Fehlern beim SVG Rendering).
Die von uns jeweils geforderten Lizenzangaben bei Bildern/Dateien standardmäßig als Tooltip und/oder direkt (ohne Verlassen der Seite) am Bild (meinetwegen fakulativ) einblenden
Eine Lösung dafür (am Besten im Dialog mit dem hochladenden Benutzer), dass keine Bilder auf de.WP hochgeladen werden (können), die definitv auf die Commons gehören bei gleichzeitiger Sicherheit, dass Dateien, die dort nicht hinsollen, nur hierher hochgeladen werden.
Bilder in einer Lightbox darstellen, natürlich inklusive allen Angaben zur Lizenz, diese sollten einfach kopierbar sein zur direkten Weiternutzung (Bitte auch auf mw:Talk:Multimedia/Media Viewer ansprechen!)
ImageAnnotator wie auf commons auch auf der wikipedia (für Vorschaubilder in Artikeln, technisch analog wie auf commons) (Bitte auch auf mw:Talk:Multimedia/Media Viewer ansprechen!)
Der Hochladeassistent sollte sich den Namen des Uploaders merken.
Der Hochladeassistent sollte sich alle Eingaben und die File-Keys merken und es im Falle eines Fehlers wiederherstellen (so wie MS Word nach einem Absturz das Dokument wiederherstellt).
Der Hochladeassistent sollte automatisch erzeugte Fehlermeldungen an die Entwickler senden (z.B. so wie "Fehlerbericht senden" unter Windows), damit die Probleme schneller behoben werden können und die Community vom Fehlerweiterleiten entlastet wird.
Im Hochladeassistent an beliebiger Stelle Angaben nach unten kopieren nicht nur von der ersten Stelle an.
Commons: Bilderuploads in den Benutzernamensraum ermöglichen. Dort ist die Beschriftung und Ergänzung zum einen oft leichter, zum anderen kann man Bilder hochladen und zur Verfügung stellen, die man selbst noch nicht beschreiben/beschriften konnte, die dann aber Andere schon nutzen können, wenn sie wissen was es für ein Bildinhalt ist. Somit kann man größere Bildermengen auch gemeinsam bearbeiten, statt das nur dem Fotografen zu überlassen, der dafür womöglich lange Zeit benötigt.
Commons: frei einstellbare Zahl von angezeigten Bildern in Kategorien (sprich auch mehr oder weniger als die 200 in der derzeitigen Standardeinstellung)

Schwesterprojekte (ohne Datei-spezifisches)

Wikiquote: Eine einfache Erweiterung, die eine mehrfache Eingabe jedes Zitats und dadurch bedingte Inkonsistenzen vermeidet. Dies würde dazu führen, dass eine Mitarbeit in diesem Projekt wieder attraktiv würde, was sie derzeit klar nicht ist. Mehr dazu siehe hier.
Wiktionary: Eine Möglichkeit, die Einträge per Formular anzulegen und zu editieren. Die Inhalte sind klar strukturiert, es fehlt nur eine vernünftige Möglichkeit sie zu erfassen und zu ändern. Siehe meine Aussage dazu von vor einem Jahr, die heute noch genau so aktuell ist.
Beschleunigung der Entwicklung neuer Datentypen für Wikidata
- Beschleinigung der Entwicklung des Datentyps geographic shapes und Entwicklung einer GIS-Funktionalität

Suche

Suchfunktion: Möglichkeit zur Suche (auch exakten Suche) im Quelltext
Massiv ausgebaute Suchfunktion (plump formuliert "wie Google") incl. voll integriertem CatScan (Suche nach Kategorien incl. beliebig tiefer Verschachtelung, Querschnitten, Ein- und Ausschlüssen), Suche in alten Artikelversionen, Suche nach Bildinhalten, Farben (bugzilla:37534, bugzilla:37535), Größen, Formaten usw. bei Commons.
Ein erweitertes Suchformular, in dem diverse Parameter angegeben werden können. (Themengebiet/Kategorie, exakte Formulierung, logische Operatoren für Suchstichworte - oder/und/nicht, Autor, Zahl der Edits im letzten Monat/Jahr, Zahl der Lesebesuche im letzten Monat, Länge des Artikels) All das, wofür man im Moment den Toolserver bemühen muss.
eine Art Templatetiger, mit der man live nach Vorlagenparametern suchen kann
So etwas wie Wikipedia:WikiProjekt Vorlagenauswertung auf aktueller Basis (nicht irgendein Uralt-Dump) mit Suchmöglichkeiten und Export in gängige Tabellenformate, ohne Zeilenbeschränkung.
Zusammenfassung von Bearbeitungen soll durchsuchbar werden.
Die Weblinksuche sollte nach Namensräumen gefiltert werden können (Bug 10593)

Einzelnachweise

Einzelnachweise: Verbesserte Syntax, damit zumindest im Quelltext klarer wird, ob ein Einzelnachweis am Ende eines Abschnitts den ganzen Abschnitt, den letzten Absatz oder nur den letzten Satz belegt.
Edit-Fenster: Umschaltmöglichkeit zum Ausblenden von refs aus dem Quelltext
In der Vorschauversion Beim Bearbeiten einzelner Abschnitte auch die Refs anzeigen, auch wenn der <references />-Tag nicht im Abschnitt vorkommt. (Bug 5984)
Einzelnachweise als Quickinfo anzeigen (anstatt an den unteren Bildschirmrand zu scrollen), wie in der englischsprachigen Wikipedia zu sehen (Bug 7908)
Erweiterung der Einzelnachweise, so dass bei verschiedenen Seiten des selben Werks nicht immer das gesamte Werk angegeben werden muss
Bei Eingabe von ISBN, DOI oder PubmedID bietet die Software eine Option, daraus automatisch einen Einzelnachweis zu erstellen und fügt selbständig Angaben wie Autor, Titel usw. ein

Programmierung

Neue, lesbare, mächtigere Vorlagensyntax (echte String-Funktionen, Variablen, saubere Behandlung von White Space und Zeilenenden, Kommentare usw.)
Text-to-Speech; direkt im Wikitext einbindbares Tool, das IPA als Audiodatei ausgibt (auch wenn das bei derzeitigem Technikstand utopisch ist; siehe auch Wikipedia:Community-Projektbudget/Sprachausgabe von Lautschrift)
Bug 13953: globale common.js & common.css (für alle WMF-Projekt geltende, benutzerspezifisch)
Weiterentwicklung von Hilfe:Zeitleisten, so dass auch echte x/y-Diagramnme möglich sind; alternativ eine andere Grafikbeschreibungssprache

Autorenzuordnung

Die Möglichkeit, die AutorInnen samt der von ihnen geleisteten Beiträge direkt (ohne Verlassen der Seite) am Artikeltext (meinetwegen fakultativ) einzublenden
Eine komfortablere Möglichkeit, die Hauptautoren eines Artikels (zumindest ansatzweise) zu ermitteln / zu kontaktieren
Ein echtes Wikiblame, z.B. nach diesem Vorbild -- Autoren werden in einer zweiten Spalte eingeblendet. bugzilla:639.
Integration von Schnarks Tool zur Artikelstatistik in die Mediawikisoftware (und damit zugleich Erfüllung von Wunsch Nr. 2)
Insbesondere im Werkzeug "Seiteninformationen" müssen die Hauptautoren eines Artikels ausgewertet werden und nicht bloß Seitenersteller, letzte Bearbeiter, Anzahl unterschiedlicher Autoren und ähnliche Alibi-Infos.
Eine Spezialseite, die die von einem Benutzer neu angelegten Seiten ausgibt (filterbar nach Namensraum, Weiterleitungen ausblendbar, ...).

Diskussionen

Automatisch richtige Einrückung und Einfügung von Diskussionsbeiträgen (kommt evtl. sowieso mit Flow), aber unter Beibehaltung aller bisherigen Möglichkeiten zur händischen Veränderung
Technische Lösung des Dauerbrenners "Wo antworte ich auf Kommentare auf meiner Benutzerdiskussionsseite? (hier oder auf dessen)"

Spezialseiten

eine Spezialseite, mit der man Bearbeitungen und (lokale und globale) Sperren einer IP/IP-Range/eines Accounts auf allen WM-Projekten angezeigt bekommt (also etwas was bisher externe Tools leisten)
Neuanmeldungslogbuch soll gesperrte Accounts markieren. (Bug 22705)
- Einfache Lösung: Oben ins Neuanmeldungslogbuch (MediaWiki:Newuserlogpagetext) einen Link auf die Benutzerliste setzen (sortiert rückwärts nach Datum), dort stehen bei den Neuanmeldungen auch Gesperrt-Markierungen.
Auf der Spezialseite Verwaiste Seiten möchte ich BKL-Seiten ausblenden können. (Bug 3483)
Special/Newpages soll Seiten mit SLA-Baustein in der Liste markieren (spart Doppelarbeit in der Unsinnsentsorgung)
Favoritenliste: Ähnlich der Beobachtungsliste lassen sich Seiten durch einen Klick der Favoritenliste hinzufügen. Diese ist dann im Menü links oder oben abrufbar und lässt sich z. B. nach Namensraum filtern/sortieren.

Vandalismusbekämpfung

Setzen eines „Vandalismus-Cookies“ bei Benutzersperren. Die Cookie-Verfallszeit entspricht dabei der Sperrdauer, maximal aber 1 Tag. Beim Aufruf des Wikieditors Überprüfung, ob ein entsprechendes Cookie vorliegt. Wenn ja, dann keine Bearbeitung zulassen und entsprechende Meldung ausgeben. (/als Zombie-Cookie) (Bug 3233)

Mobile Version

BNR (speziell eigene Benutzerseite/-disk) in der Mobilen Ansicht verfügbar machen ohne manuell „Benutzerdiskussion:XYZ“ eingeben zu müssen.
Darstellungsmöglichkeit typischer Portalseiten (Pseudoregisterkarten) in der Mobilen Ansicht.
Versionsgeschichte in der Mobilen Ansicht verfügbar machen
Eine Mobil-Version, die Edits erlaubt und so gestaltet ist, dass die Beschränkungen des Mini-Bildschirms bestmöglich umschifft werden.

Zusätzliche Möglichkeiten zur Formatierung

Automatisches Nummerieren von Tabellen bei Ranglisten. Wenn es bspw. einen neuen Platz 5 von 100 Einträgen gibt, müssen alle darunter liegenden 95 Einträge von Hand einzeln angepasst werden.
Möglichkeit Abbildungen, Tabellen, etc. durchzunummerieren und auf diese Nummer im Text zu verweisen (analog zu den LaTeX-Befehlen labelund ref)
LaTeX-Export einbinden (b:Benutzer:Dirk_Huenniger/wb2pdf)
Wikisyntax um Permalinks oder Difflinks als Wikilink (also mit zwei eckigen Klammern) angeben zu können. Damit verwandt: Zulassen von Difflinks in der Zusammenfassungszeile (siehe auch).

ParserFunctions (Vorlagenprogrammierung)

Bugzilla:8446, Bug 12019: (Ist das die richtige Bugnummer?) ifexist funktioniert nicht. Verursacht massenhaft pseudo-Rotlinks, die dann bei "Links auf diese Seite" auftauchen. Praxis-Beispiel Spezial:Linkliste/Kenai_Peninsula_Borough_(Alaska) existiert als Kenai Peninsula Borough; durch eine ifexist-Abfrage wird eine fehlende Seite (Rotlink) eingetragen.

Sonstiges

Ein Vorschlag, um edit-wars zu 'kanalisieren': Administratoren sollten einem strittigen Haupt-Artikel einen oder mehrere Positions-Artikel (Ansichten) zuordnen können, auf denen sich die Vertreter der jeweiligen Position 'ungestört' ausdrücken können. Softwaretechnisch ist dazu eine Einschränkung der Schreibrechte sinnvoll: Nur der Haupt-Artikel kann wie seither frei editiert werden. Doch sobald ein User eine Positions-Seite editiert, wird er (automatisch) dieser Sub-Community zugeordnet, und kann künftig keine andere Positions-Seite dieses Themas mehr editieren. Dabei hat der Admin die letzte Verantwortung dieser Autoren-Zuordnung, und kann z.B. auch die 'Konversion' eines Autors zu einer anderen Position - auf Anfrage - durchführen (Regeln?). Damit können kontroverse Positionen als Ansichts-Strömung getrennt entwickelt und wiedergegeben werden, ohne Störungen der Gegenseite, und ohne Anspruch auf Allgemeingültigkeit.