Wikipedia:Verbesserungsvorschläge/Feature-Requests

Auf dieser Seite sollen Feature-Requests gesammelt werden, also Vorschläge, Wünsche oder Forderungen, der Software neue Funktionen hinzuzufügen bzw. eine vorhandene Funktionalität zu ändern. Wenn sie sich durchsetzten, werden sie an die Entwickler weitergeleitet. Durch die so erreichte Zustimmung haben sinnvolle Änderungen eine größere Chance. Umsetzungen finden sich auf Wikipedia:Projektneuheiten.

• Um allgemeine, nicht softwareabhängige Verbesserungsvorschläge zu machen, nutze bitte Wikipedia:Verbesserungsvorschläge.
• Um vermutete Softwarefehler (Bugs) zu melden, wende dich bitte an die Technik-Werkstatt.
• Um einen Vorschlag tatsächlich an die Programmierer weiterzugeben, wird jedoch Phabricator (ehemals: „Bugzilla“) verwendet, wo solche Vorschläge verwaltet werden.

Bitte gebt auf dieser Seite unter »dafür« (pro) oder »dagegen« (contra) eure Stimme ab, welche Feature requests an die Entwickler weitergeleitet werden sollen.

(Mehr Kommunikationsmöglichkeiten auf der Kontaktseite.)

Neuen Beitrag erstellen

… und bitte mit --~~~~ unterschreiben.

Wenn ein Abschnitt abgearbeitet ist, kann er mit {{Erledigt|1=--~~~~}} markiert werden, wodurch er nach fünf Tagen ins Archiv verschoben wird. Anfragen, deren letzter signierter Beitrag mindestens 100 Tage zurückliegt, werden ebenfalls archiviert.
Sollen bereits archivierte Beiträge wieder diskutiert werden, erstellt hier bitte einen neuen Abschnitt mit Verweis auf den archivierten.

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 100 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 5 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Parameter Zeigen auf Nein gesetzt

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Buchfunktion: Anmerkungsseite für Benutzer vorsehen

Die Buchfunktion ist richtig gut. Mir fehlt nur eine Möglichkeit temporär und schnell eine Anmerkungs- bzw. Notizseite anzufügen. (nicht signierter Beitrag von 185.17.205.174 (Diskussion) 10:49, 11. Dez. 2016 (CET))

Vorschau der Suchergebnisse zeigt letzte ungesichtete Version

In der Vorschau der Suchergebnisse wird gegenwärtig (auch für nichtangemeldete User) der Text der letzten ungesichteten Version angezeigt - also NICHT der Text der letzten GESICHTETEN Version, wie ich eigentlich vermutet hätte. Ist das so beabsichtigt? Sollte das nicht korrigiert werden? --Bernd Bergmann (Diskussion) 18:39, 6. Jun. 2020 (CEST)

Ich wäre auch dafür. Sonst werden ja u.U. schlimmste Vandalismus-Resultate angezeigt. btw: Man müsste mal ergründen, ob das bei Hover-Seitenvorschauen auch so ist (ist aber eher eine zweitrangige Subtask) --Hlambert63 (Diskussion) 06:32, 4. Mär. 2023 (CET)

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte. Grund: Noch keine Antwort.

Edit-War Erkennung

Hallo, Wunsch und Vorschlag wäre, sofern das überhaupt softwareseitig möglich ist, eine automatische Edit-War Erkennung bei der Artikelbearbeitung zu programmieren. Da immer wieder Diskussionsbedarf besteht, wer Edit-War angefangen hat, wäre es eine große Hilfe, wenn der Artikelbearbeiter einen automatischen Hinweis erhielte z.B. "Halt, du bist gerade dabei einen Edit-War zu beginnen", oder so ähnlich, der dann aufploppen würde. Gruß--2A02:8108:473F:9FBC:E1E9:91D1:97E8:402E 18:18, 15. Jan. 2024 (CET)

Würde ich gut finden. Ein Vorschlag zur softwareseitigen Erkennung: Wenn abwechselnd (wichtig! es gibt je leider viele nacheinenander folgende Edits desselben Users...) entweder immer die selben User (oder IPs) was ändern oder die Größe der Änderung immer mal wieder die selbe ist, kann man mit 80%iger Sicherheit von einem Edit-War ausgehen.--Hlambert63 (Diskussion) 19:55, 15. Jan. 2024 (CET)

Da stellen sich mir eine Reihe von Fragen.

• Wer soll diese Information erhalten?
• Welches Ereignis soll eine derartige Analyse auslösen?
• Wie sauber und präzise ist die Analyse?

Von der Performance her:

• Wenn jeder Edit aller Konten auf jeder Seite dazu führen soll, dass diese Erkennung durchgeführt werden muss, dann wird das schon Performance-mäßig unverhältnismäßig sein.
• Wenn es ein freiwilliges Benutzerskript wird, das sich Interessierte auf eigenen Wunsch aktivieren und das dann automatisch abläuft, geht die Performance auf das Konto der Leute die es haben möchten und das sind Bruchteile eines Promille.

Analyse-Genauigkeit

• Es gibt Edits mit Null Bytes Änderung. Die können Teil eines Edit-War sein, müssen es aber nicht. An vielen Stellen kann Groß- gegen Kleinschreibung geändert oder eine URL korrigiert worden sein, oder eine Jahreszahl. Alle können, keiner muss an derselben Stelle passieren und nur das wäre Edit-War.
• Ein potenzieller Edit-War-Edit kann gleichzeitig an anderen Stellen Veränderungen vornehmen; damit können beliebige Byte-Anzahl-Differenzen herauskommen.

Wem hilft es?

• Wer einen meist Re-Revert ausführt, weiß dass es unmittelbar zuvor anderweitige Versionen gegeben hatte.
• Möglicherweise sind die Projektregeln WP:Edit-War nur ansatzweise oder überhaupt nicht bekannt; insbesondere wenn noch nicht soooo lange dabei. Erfahrene Leute wissen sehr gut um diese Problematik.
• Wenn ich es nicht kenne, werde ich den Hinweis auch nicht begreifen und verständnislos ignorieren.

VG --PerfektesChaos 15:35, 16. Jan. 2024 (CET)

Hallo PerfektesChaos. Da muss ich jetzt wirklich schmunzeln, was die erfahrenen Leute betrifft. Ist es nicht eher so, dass sich gerade die erfahrenen Benutzer die schon jahrelang hier sind, die nervigen Edit-War-Schlachten liefern? Gehen wir von dem aus, wie es Benutzer Hlambert63 oben beschreibt und annimmt. Es wird etwas in den Artikel eingefügt, andere Argusaugen sehen das und blitzschnell wird es wieder herausgenommen, der andere Bearbeiter reagiert sofort binnen Sekunden bis Minuten und fügt es wieder ein. Edit-War und zwar einer mit immer derselben Zeile bzw. Zeilen (selbe Stelle im Artikel mit Inhalt unverändert). Dieses müsste von der Software sofort erkannt werden, weil gleiche Stelle, gleiche Welle, rein, raus, rein, Alarmglocken läuten, da Ungemach zu 80% erkannt, softwareseitig erfolgt ein Hinweis (Edit-War) bei dem Benutzer, der zuerst und dann wieder zuletzt eingefügt hat und zwar bevor dieser gedenkt die Taste zum senden/abschicken zu drücken. Wie sowas programmiert wird und mit welchen Komponenten (Skript, (Spam-) Filter, Echolot (Spaß), durch automatische Analyse der Zeilenbewegungen in den Versionsgeschichten), das müssten die Technikgenies ergründen. Als möglichen Nutzen würde ich benennen, weniger VM-Meldungen wegen Edit-War, weil der mutmaßliche Edit-War-Mensch sich besinnt und eben nicht auf den Button drückt, sondern auf abbrechen. Und natürlich wäre das eine Arbeitserleichterung für die Admins, die dann hoffentlich seltener kontrollieren müssen. Gruß--2A02:8108:473F:9FBC:C91E:8729:FCBB:C914 20:16, 27. Feb. 2024 (CET)

Ein „Edit-War“ ist keine Situation, die ausschließlich Software-Regeln beträfe, sondern ein menschliches Verhalten, das unterschiedliche Wikis teils dulden, teils missbilligen, und auf jeden Fall unterschiedlich definieren.

• Es ist nicht trivial, ab wann und unter welchen Bedingungen überhaupt ein vorwerfbarer Edit-War beginnen würde.
• Eine IP fügt Müll ein, jemand vom RC revertiert, dieselbe oder eine andere IP fügt wieder ein, jemand vom RC revertiert wieder – das ist aber normale Vandalismusbekämpfung.
• Die Edits müssen nicht exakte Reverts und exakte Wiederholungen sein.
• Bei uns wird akzeptiert, wenn eine unerwünschte (etwa beleglose, unplausible oder vandalierende) Änderung mit Kommentar revertiert wird, und zur Nutzung der Diskussionsseite aufgefordert wird.
• Falls jetzt innerhalb weniger Minuten auf der Diskussionsseite Konsens über die Legitimität der Änderung hergestellt würde, wäre das nach den Vorstellungen dieses Vorschlags ein Edit-War.
• Das ist schlicht nicht in herkömmlichen Algorithmen abbildbar.

Eine vorgeschlagene Software müsste global in allen Wikis nach praktisch identischen Regeln arbeiten und reagieren; die Ansprüche sind jedoch je nach Wiki unterschiedlich. Derartige Automatismen funktionieren in der realen Welt einfach nicht. Die Reaktion wäre bestenfalls eine Meldung, dass dort viel parallel editiert wird – das wissen die an einem echten „Edit-War“ Beteiligten aber schon selbst, und wenn nur zufällig Kollisionen auftreten, dann würde niemand begreifen, was die plötzlich erscheinende Meldung bedeutet und in welcher Weise sich jetzt wer verhalten solle.

VG --PerfektesChaos 21:01, 27. Feb. 2024 (CET)

PerfektesChaos, ja das stimmt wohl, Edit-War ist menschliches Verhalten. Und ja, auch "Das ist schlicht nicht in herkömmlichen Algorithmen abbildbar." leuchtet mir ein. Dann müssen die Admins wohl weiterhin ihre kostbare Zeit aufwenden, um sich mit diesen menschlichen Verhalten auf VM zu befassen. "Eine vorgeschlagene Software müsste global in allen Wikis nach praktisch identischen Regeln arbeiten und reagieren;", ja, ich kann mir vorstellen, dass das ein Hauptanliegen ist, wenn ihr euch Gedanken über Weiterentwicklungen macht. Danke für deine umfangreichen Erklärungen. Gruß--2A02:8108:473F:9FBC:C91E:8729:FCBB:C914 21:29, 27. Feb. 2024 (CET)

Es funktioniert grundsätzlich niemals, mittels Software einen inhaltlichen oder menschlichen Konflikt zu „lösen“.

• Im Maximum soll gemäß diesem Vorschlag eine Meldung erscheinen.
• Die Beteiligten an einem echten Edit-War wissen längst, dass ein Edit-War vorliegt, und bedürfen keiner Hinweise.
• Wenn die Situation, die ja nicht trivial sein muss, fehlerhaft analysiert und bewertet wurde, dann ist die beabsichtigte Meldung nur verwirrend und störend.
• Also eine Meldung, die im günstigsten Fall überflüssig, ansonsten verkomplizierend und nicht hilfreich wäre.
• Das ist keine Verbesserung.
• Ja, alle User (nicht nur Admins) müssen auch weiterhin in jeder Situation den Hergang rekonstruieren, die Bearbeitungskommentare lesen und verstehen, auf die Diskussionsseite gucken, und die inhaltliche Begründung (Einschätzung als Vandalismus, unerwünschte Veränderung weil beleglos, nicht plausibel, nicht relevant) intellektuell nachvollziehen. Das löst diese globale Wiki-Software ganz sicher nicht.

VG --PerfektesChaos 22:16, 27. Feb. 2024 (CET)

(Neuer) Suchfilter „Größe der Änderung“

Ich habe ja verschiedene Such-Profile mit diversen Suchfiltern angelegt. Manchmal interessieren mich nur Änderungen ab einer Größe von ca. +500 Bytes (die Info gibt es ja, weil die durch unterschiedliche Zahlendarstellungen in der Änderungsgröße angezeigt wird). Könnte man einen Suchfilter "Nur Änderungen ab + / - x Bytes" schaffen, oder gibt es den schon, und ich weiß es nur nicht? Das Flag "Kleine Änderung" ist IMHO wertlos, weil das nicht konsequent benutzt wird. --Hlambert63 (Diskussion) 20:04, 29. Feb. 2024 (CET)

Wäre global vorstellbar, zumal das Kriterium ±500 seit langer Zeit in der Software hinterlegt wurde.

Alternativ wäre auch die Einführung einer Hilfe:Bearbeitungsmarkierung möglich, die aber die Beo unübersichtlicher machen würde.

Auch heute schon könnte jemand ein JavaScript basteln, welches nur die >500 in der Darstellung von Beo=RC belässt.

• Abgerufen vom Server werden alle, jedoch nur angezeigt (bzw. die anderen ausgeblendet↔eingeblendet), welche >500 sind.
• Dein obiger Edit wurde gelistet als: <strong class="mw-plusminus-pos mw-diff-bytes" title="12.274 Bytes nach der Änderung">+648</strong>
• Auf Beo=RC könnten Listeneinträge ohne ein „Kind“ strong.mw-diff-bytes „getoggled“ werden; show↔hide.

Eine geänderte Jahreszahl hat ±0, ist aber eine wesentliche inhaltliche und keine „Kleine Änderung“. Umgekehrt kann durch Konvertierung von veraltetem H:CSS die Seitengröße um mehrere kB steigen, ohne dass sich dabei Inhalte ändern. Byte-Anzahl und Inhalte haben absolut nichts miteinander zu tun.

VG --PerfektesChaos 20:49, 29. Feb. 2024 (CET)