Wikipedia

Wikipedia:Umfragen/Technische Wünsche/Top 20

< Wikipedia:Umfragen | Technische Wünsche

Diese Seite gehört zum Wikipedia-Archiv.

Der Inhalt dieser Seite ist nicht mehr aktuell. Sie wird aber nicht gelöscht, damit die Geschichte der Wikipedia nicht verloren geht. Falls es sich um eine Arbeitsunterlage handelt, ist sie womöglich durch andere Seiten ersetzt worden. Bestehende Weiterleitungen auf diese Seite sollen das Wiederauffinden ermöglichen.

Wenn du meinst, diese Seite sei weiterhin von aktueller Bedeutung, solle weiter benutzt werden und ihre Funktion sei nicht besser in bestehende Seiten integriert, dann kümmere dich bitte um ihre Aktualisierung.

 Info: Vom 19.9. bis zum 26.10.2015 fand erneut eine Umfrage zum aktuellen technischen Bedarf statt. Aus den neuen Wünschen und den Wünschen auf dieser Top-20-Liste wurde eine neue Liste zusammengestellt, um den Überblick nicht zu verlieren und einen zentralen Ort zu haben: Wikipedia:Umfragen/Technische Wünsche 2015/Topwünsche

Diese Seite hier wird nicht mehr aktualisiert. Der aktuelle Stand findet sich von nun an auf der neuen Liste.

Erledigt

Bearbeiten

Warnhinweis oder automatisches Einfügen von fehlendem <references />-Tag

Bearbeiten

erledigtErledigt seit 10. Juli 2014 durch automatische Anzeige verbliebener <ref>-Tags ohne Gruppierung am Artikelende.

Bearbeiten

erledigtErledigt seit Januar 2014 mit der Einführung von Spezial:Diff, siehe Hilfe:Versionsvergleich.

Verbesserung der Verschlüsselung von https-Verbindungen mittels Perfect Forward Secrecy, um nachträgliche Entschlüsselungen zu verhindern

Bearbeiten

erledigtErledigt seit 1. Juli 2014. Kann bspw. bei Qualys überprüft werden (Protocol Details → Forward Secrecy).

Eine Spezialseite, die die von einem Benutzer neu angelegten Seiten ausgibt

Bearbeiten

erledigtErledigt seit März 2014 mit der Einführung des Schalters „Nur Seitenerstellungen anzeigen“ auf Spezial:Beiträge.

Möglichkeit zur Suche im Quelltext

Bearbeiten

erledigtErledigt seit Juni 2014 als Teil der Beta-Funktion „Neue Suche“ (CirrusSearch) und seit dem 12. November 2014 im Standardbetrieb. Es steht der Suchoperator insource: zur Verfügung, der auch reguläre Ausdrücke (in Schrägstrichen) akzeptiert.

Tabellen in einer Form bearbeiten können, wie man es seit einigen Jahrzehnten aus Office-Programmen kennt

Bearbeiten

erledigtErledigt durch die Tabellenunterstützung in VisualEditor, siehe phab:T41596.

„CatScan-Funktionalität“ in die Software integrieren

Bearbeiten

erledigtErledigt mit Entwicklung (phab:T37402,phab:T7244) der Kategorientief- und Schnittmengensuche. Die Suchanfragen können mittels Suchbegriff deepcat: im normalen Suchefeld der Wikipedia und anderen unterstützten Wikis ausgeführt werden.

  • Deutsche Wikipedia:

Auf der Deutschen Wikipedia kann das Gadget als Helferlein in den Benutzer Einstellungen aktiviert werden. Nach setzen des Hakens bei "Deepcat" und dem Speichern der Einstellungen ist das Gadget mit dem Suchbegriff verfügbar.

Um das Gadget auch auf anderen Wikis nutzen zu können, muss es über folgende Zeile in der eigenen common.js aktiviert werden: 

mw.loader.load( "https://de.wikipedia.org/w/index.php?title=MediaWiki:Gadget-DeepCat.js&action=raw&ctype=text/javascript" );

Mehr Informationen zum Installationsweg, sowie zur Funktionalität gibt es unter Hilfe:Suche/Deepcat. Fehler können hier gemeldet werden.

Eine sprachen-/projektübergreifende Beobachtungsliste für alle Wikimedia-Wikis

Bearbeiten

(erledigtErledigt) durch das Tool "crosswatch" (deutsch) von Benutzer:Sitic. Mit “Crosswatch” können zusätzlich projektübergreifend Benachrichtigungen angezeigt werden. (Echo/Notifications). Crosswatch ist auf Tool Labs verfügbar. Ort für Feedback und Fragen: meta:talk:crosswatch / Wikipedia Diskussion:LT/crosswatch. Die Integration einer projektübergreifenden Beobachtungsliste in die Software ist perspektivisch gesehen jedoch wünschenswert und sinnvoll.

In Arbeit

Bearbeiten

Möglichkeit, eine Kategorie auf neue Artikel hin zu beobachten

Bearbeiten

Aufwand und Realisierungsmöglichkeiten

  • Braucht erweitertes „Watchlist“-Konzept, Datenbank-Anpassung, GUI-Erweiterung.
  • Wahrscheinlich gar nicht als Funktion der Watchlist, sondern via Echo zu realisieren.
  • Konzeptionalisierung: 3 Sprints 50 %

Einzelne Arbeitsschritte

 Info: Das Feature wurde am 20.8. Abends revertiert. Im Live-Betrieb wurde deutlich, dass bei der Verwendung bestimmter Templates die IP-Adressen an Stelle der Benutzernamen in den "letzten Änderungen" angezeigt wurden. Dies geht aus datenschutzrechtlichen Gründen nicht. Das Feature wurde zurückgeholt, und es wird an einer Lösung gearbeitet.

Möglichkeit, dass ein Artikel nach Ablauf einer einstellbaren Zeitspanne automatisch wieder von der Beobachtungsliste gestrichen wird

Bearbeiten

Aufwand und Realisierungsmöglichkeiten

Nächste Aufgaben

Bearbeiten

Vergrößerung der Länge der Zusammenfassungszeile

Bearbeiten
  • Ergebnis Umfrage: 13 Punkte
  • Task T6714
  • Konkretisierung des Wunsches: Die derzeitige Länge beträgt 255 Byte. Bei sehr umfangreichen Quellenangaben ist nicht immer möglich, alles anzugeben. Vorschlag: Vergrößerung auf 1024 Byte (= 1 Kilo-Byte)

Aufwand und Realisierungsmöglichkeiten

  • Datenbankseitig kein Problem.
  • Beschränkung an vielen Stellen in MediaWiki hart codiert? Analyse/Auswertung nötig (ca. 20–50 Stellen).
  • Sollte konfigurierbar sein.
  • Idealerweise gleichzeitige Änderung von Byte auf Char.

 Info: Gerrit:191811 für ein Maximum von 767 Bytes. — Raymond Disk. 08:39, 20. Feb. 2015 (CET)[Beantworten]

 
Vergrößerung der Länge der Zusammenfassungszeile? Screenshot von Bearbeitungsfenster
 
Vergrößerung der Länge der Zusammenfassungszeile? Screenshot von Bearbeitungsfenster

Ist das wirklich ernstgemeint?? Der Benutzer soll in ein schwarzes Loch unklarer Länge schreiben? Obwohl nur Platz für 5 Buchstaben sichtbar ist? User Interface??   Kann mal jemand mit einer quarry Abfrage belegen, dass solche blinden Eingaben in der Zusammenfassungszeile seit März 2015 genutzt werden? --Atlasowa (Diskussion) 13:59, 28. Okt. 2015 (CET)[Beantworten]

Erweiterung der Einzelnachweise, so dass bei verschiedenen Seiten desselben Werks nicht immer das gesamte Werk angegeben werden muss

Bearbeiten

Aufwand und Realisierungsmöglichkeiten

  • Use Case 1: Referenzierung verschiedener Seiten eines Werkes in einem Artikel
    • Erweiterung der <ref>-Extension um einen „page“-Parameter
    • 3 Sprints 100 %
  • Use Case 2: Referenzierung des selben Werkes in vielen Artikeln
    • Einbindung von Informationen über Werke, die als Wikidata-Items verwaltet werden.
    • Wird möglich, sobald beliebige Wikidata-Items auf beliebigen Seiten zugänglich sind.
    • Infos – PerfektesChaos 10:28, 5. Mär. 2014 (CET):[Beantworten]
      1. Vorlage:BibRecord usw. machen dies bereits seit langer Zeit – eine Liste der verfügbaren Titel.
      2. Wikidata gilt als weniger geeignet, weil Details zu den Datenelementen sprachbezogen sind – unsere Wikipedia:ZR sind nicht kompatibel zu den angloamerikanischen Formaten; etwa Personennamen, deren Aufzählung, Verlagsangabe, komplexere Seitenzahlen, Kapitel.
  • Grundlagen werden im Rahmen von Wikidata in jedem Fall geschaffen; zusätzliche Lua-Integration denkbar
  • Gibt es schon als Vorlage: Vorlage:rp

Technisch sauberes Verschieben von Dateien nach Commons unter Beibehaltung der Versionsgeschichte und des Benutzernamens

Bearbeiten

Aufwand und Realisierungsmöglichkeiten

  • Voraussetzung: Globaler Account; Benutzer sollte dieselben Berechtigungen wie beim XML-Ex/Import haben
  • Import/Export-Funktion verwenden
  • Betrifft zwei (drei) Versionsgeschichten: Dateibeschreibungsseite, Dateiversionen, Binärdateien selbst (alle Versionen)
  • Aufwand: 6 Sprints, 100 %, 1P.
  • Möglicherweise als Teil oder auf Basis des GLAMwiki Toolsets (GWToolset) realisierbar.

Syntaxhervorhebung fürs Editieren eines Artikels im Quelltext

Bearbeiten

Langfristige Projekte

Bearbeiten

Langfristige Projekte (z. B.: „Suche verbessern“) mit z. T. sehr hohem Aufwand und z. T. keinem fixen Endpunkt („Performance der Mediawiki-Software verbessern“). Im größeren Maß Abstimmung, Kommunikations- und Schnittstellenarbeit erforderlich (WMF, WMDE, Communitys).

 Info: Am 19.9. startet die nächste Umfrage "Technische Wünsche". Die langfristigen Projekte sind zum Teil mit hohem Aufwand verbunden, sind nicht klar eingegrenzt oder haben keinen Endpunkt. Für die neue Umfrage werden daher aus den Langzeitprojekten kleinere machbare Aufgaben geformt, über die einzeln abgestimmt werden kann.

Ein erweitertes Suchformular, in dem diverse Parameter angegeben werden können

Bearbeiten
  • Ergebnis Umfrage: 12 Punkte
  • Task:https:T101087
  • Konkretisierung: 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 - alles, was momentan nur als Tool vorhanden ist

Einzelne Aufgaben und Aufwand/Realisierung

  • Exakte Formulierung → CirrusSearch (?)
  • Logische Operatoren für Suchstichworte – oder/und/nicht → CirrusSearch: UND ist Standard; NICHT/ODER existiert noch nicht
  • Autor → CirrusSearch (Indexierung ist teuer)
    • 1 Sprint, 100 % (nach Einarbeitung in Cirrus)
  • Zahl der Edits im letzten Monat/Jahr → CirrusSearch (Indexierung ist teuer)
    • 1 Sprint, 100 % (nach Einarbeitung in Cirrus)
  • Zahl der Lesebesuche im letzten Monat → CirrusSearch (Einlesen aus Squid Logs)
  • Länge des Artikels → CirrusSearch (neues Indexfeld)
    • 1 Sprint, 100 % (nach Einarbeitung in Cirrus)
  • Suche in alten Versionen
    • Zu hoher Aufwand

Vorschau von Einzelnachweisen beim Bearbeiten von Abschnitten

Bearbeiten

Aufwand und Realisierungsmöglichkeiten

  • Theoretisch einfach nur ein zu behebender Bug/Feature-Request in der <ref>-Extension + Vorschaufunktion, praktisch wahrscheinlich wesentlich komplizierter.
  • 3 Sprints, 100 %, 1 Person

 Info: In Arbeit mit Gerrit:129932. — Raymond Disk. 09:56, 27. Apr. 2014 (CEST)[Beantworten]

@Raymond: Erfüllt Benutzer:ParaDox/monobook/VirtualReferences.js diese Aufgabe nicht vollumfänglich? MediaWiki:Gadget-ReferenceTooltips.js ist dann noch doppelt hilfreich. Grüße, —Martin (WMDE) (Disk.) 17:32, 12. Okt. 2015 (CEST)[Beantworten]
Dauert aber längerm beansprucht der Ressourcen und sollte eigentlich nicht nötig sein. Nur weil ein Feature auch per JS realisiert werden kann, sollte das kein Ausschlussgrund sein. --MGChecker – (📞| 📝|  ) 20:33, 12. Okt. 2015 (CEST)[Beantworten]

@Martin Rulsch (WMDE): Von der Optik her könnte das den Wunsch erfüllen. Hab's aber nicht getestet. Aber worauf willst du hinaus mit der Frage? Das Benutzerscript wird seit 2008 nicht mehr gepflegt und ist keine Lösung für den Wunsch, außer es würde dauerhaft in MediaWiki integriert. Andererseits gibt es ja schon einen Patch in Gerrit, der leider vor sich hinrottet :-( — Raymond Disk. 09:22, 13. Okt. 2015 (CEST)[Beantworten]
Ich wollt nur sicherstellen, dass das Skript bekannt ist. Meine Erinnerung ist, dass es ganz gut funktionierte. Klar ist eine softwareseitige Lösung immer die bessere. ;-) Grüße, —Martin (WMDE) (Disk.) 10:26, 13. Okt. 2015 (CEST)[Beantworten]
Das Skript von ParaDox löst das Problem nicht vollständig, da es keine benannten Einzelnachweise aus anderen Abschnitten anzeigt. Mein Skript tut das, hat aber auch ein paar kleine Einschränkungen. --Schnark 10:31, 13. Okt. 2015 (CEST)[Beantworten]
Ah, super, danke! :-) —Martin (WMDE) (Disk.) 10:59, 13. Okt. 2015 (CEST)[Beantworten]
@Martin Rulsch (WMDE): Skripte, die nicht mindestens als Gadget zur Verfügung stehen, sind für mich keine Lösung eines TOP 20-Wunsches. — Raymond Disk. 11:02, 13. Okt. 2015 (CEST)[Beantworten]
Ist ja gut … Ich wollte ja nur wenigstens auf die Existenz dieser Skripte hinweisen, sodass man sich das anschauen, Ideen und Strukturen ggf. aufgreift. Dass schon (viel) dazu programmiert wurde, war mir aus einem Link auf Gerrit nicht unbedingt ersichtlich. —Martin (WMDE) (Disk.) 11:07, 13. Okt. 2015 (CEST)[Beantworten]

Optimierung der Performance der MediaWiki-Software auf Benutzerseite

Bearbeiten

Aufwand und Realisierungsmöglichkeiten

  • A Reduzierung/Optimierung von vorhandenen JavaScript-Funktionen:
    • Profiling, um z. B. langsame Gadgets zu finden
    • Permanenter Prozess; Überblick verschaffen: 2 Sprints, 50 %.
  • B Einstellungsmöglichkeit für Benutzer um nicht benötigte „Ressourcenfresser“ zu deaktivieren:
    • Standardfunktionen müssen vermutlich immer geladen werden, um Cache-Effizienz zu gewährleisten.
    • Unterbinden der Initialisierung unerwünschter JS-Module per Benutzereinstellung. Eventuell wie „Beta“-Feature.
    • Aufwand schwer abschätzbar, Koordination mit der WMF nötig

 Info: Siehe auch phab:T105136 ("Start a project to reduce page weight"). — --AKlapper (WMF) (Diskussion) 17:18, 9. Jul. 2015 (CEST)[Beantworten]

Breitere Community-Diskussion/-Abstimmung notwendig

Bearbeiten

Einblendung der Autoren direkt am Artikeltext

Bearbeiten
  • Ergebnis Umfrage: 9 Punkte
  • Task:T101092
  • Konkretisierung: Die Möglichkeit, die Autorinnen und Autoren samt der von ihnen geleisteten Beiträge direkt (ohne Verlassen der Seite) am Artikeltext (z. B. fakultativ) einzublenden.
  • Grundsätzliche Diskussion und Abstimmung notwendig: Bisher werden Artikel ohne Autorennamen angezeigt. Sollen diese sichtbar werden (für Angemeldete/alle?)? Soll klar sein, wer wieviel Anteil an einem Artikel hat („Hauptautoren“/„Nebenautoren“)?. Wäre eventuell nach Diskussion als lokale Opt-Out/-In Lösung und als Gadget denkbar. Als Bestandteil der Software: Noch breitere Diskussion/Abstimmung erforderlich, sowohl in allen Communitys, als auch mit der WMF.
  • Wie fehleranfällig darf die Zuordnugn von Autor*Innen sein? Wie schlimm ist eine falsche Zuordnung?

Siehe auch: Im Verhältnis zu hoher Aufwand: Einblendung der Autoren direkt am Artikeltext + #Alternative (MediaWiki-Extension)

Im Verhältnis zu hoher Aufwand

Bearbeiten

Die Möglichkeit, einzelne Abschnitte von Seiten beobachten zu können (z. B. nur eine bestimmte Lösch- oder Relevanzdiskussion)

Bearbeiten
  • Ergebnis Umfrage: 10 Punkte
  • Task:T101268
  • Erkennen,welcher Abschnitt bearbeitet wurde, ist schon schwer, Abschnitte können auch „verschwinden“.
  • Wenn, dann muss dies definitiv via Flow gemacht werden → WMF

Einblendung der Autoren direkt am Artikeltext

Bearbeiten

Siehe auch: breitere Community-Diskussion/-Abstimmung notwendig: Einblendung der Autoren direkt am Artikeltext

  • Problem: Erstellen von „blame maps“ ist rechenintensiv und braucht viele Datenbankzugriffe, um alte Versionen zu laden.
    • Einmal berechnete „blame maps“ können wiederverwendet werden. Das bedeutet allerdings, dass (ungefähr) noch einmal soviel Daten zusätzlich zum eigentlichen Wikitext gespeichert werden müssen.
  • Problem: Diffs liegen für Wikitext vor, müssen aber für HTML berechnet werden. Templates sind besonders problematisch, Lua völlig unklar.
    • Berechnung der „blame map“ direkt auf Basis des generierten HTML ist auch möglich, aber noch aufwändiger (alle alten Versionen aller Artikel müssen gerendert werden, das HTML muss als DOM-Struktur verglichen werden, das Ergebnis muss gespeichert werden).
  • Problem: Existierende „naive“ Tools sind sehr ungenau. Insbesondere können die meisten nicht gut mit dem Verschieben von Textblöcken oder dem Löschen und Wiederherstellen von Inhalten umgehen, der betroffene Text würde falsch zugeordnet. Falsche Zuordnung kann irreführend und (z. B. bei der Hauptautorennennung) rechtlich problematisch sein.
    • Blame-Werkzeuge wie sie für RCS verwendet werden, basieren auf dem Vergleich von Zeilen. Das ist für Wikitext ungeeignet, da eine „Zeile“ im Wikitext einen ganzen Absatz repräsentiert. Wir brauchen Autorenschaft pro Wort, was deutlich aufwändiger ist.
    • „Intelligentere“ Verfahren existieren, sind aber schwieriger zu programmieren und brauchen weit mehr Rechenleistung und Speicherplatz.
  • Diverse Prototypen existierten (WikiBlame, WikiHistory, aber auch akademische, z. B. von der UCSC [1] und dem KIT[2]).
    • Die „funktionierenden“ Tools sind oft sehr ungenau (ca 80% Genauigkeit), selbst die besten akademischen Verfahren liegen noch in einem von 20 Fällen daneben. Und diese brauchen deutlich mehr Rechenleistung und/oder Speicherplatz.
    • Tools wie WikiBlame und WikiHistory sind sehr nützlich für erfahrene Editoren, wenn die Ergebnisse richtig interpretiert und gegengeprüft werden. Sie können aber für unerfahrene sehr irreführende Ergebnisse liefern.

Im Ergebnis:

  • Die Bestimmung der Autorenschaft einzelner Wörter (im Wikitext oder dem resultierenden HTML) ist technisch aufwändig, und kann nur mit einem langfristigen Committment der WMF umgesetzt werden.
  • Langfristig wäre das Mitführen der Autorenschaft direkt beim Bearbeiten theoretisch mit dem VisualEditor möglich (wenn nur noch der VE benutzt und HTML direkt gespeichert würde).
  • „Naive“ Blame-Tools könnten mit relativ geringem Aufwand besser integriert werden. Allerdings ist zu befürchten, dass die negativen Auswirkungen von irreführenden Ergebnissen bei größerer Sichtbarkeit der Werkzeuge gravierend wären.

Alternative:

Bilder nach Farben/Größen/Formaten durchsuchen

Bearbeiten

Aufwand und Realisierungsmöglichkeiten

  • Bilder nach Farben → CirrusSearch, neuer Index, teuer zu berechnen
  • Bilder nach Größen, Formaten → CirrusSearch, neuer Index
  • Perspektivisch realisierbar über Strukturierte Daten auf Commons
  • Ausführliche Recherche hat ergeben, dass der anstehende Aufwand (insbesondere das Extrahieren der Farbinformation aus den Metadaten) im Verhältnis zu dem Nutzen leider unangemessen hoch wäre. Daher wurde entschieden, den Wunsch erstmal nicht umzusetzen. Im Rahmen der Recherche wurde "Demo-Code" geschrieben, das aber nicht funktional ist.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Umfragen/Technische_Wünsche/Top_20&oldid=227685074“