Wikipedia:Verbesserungsvorschläge

Diese Seite ist zur Diskussion von Verbesserungsvorschlägen technischer Art an der deutschsprachigen Wikipedia gedacht;
sie ersetzt nicht die Diskussionsseiten der Artikel- oder anderer Wikipedia-Seiten.

---

Es gibt immer was zu tun …

Artikel-Inhalte werden direkt beim/im Artikel verbessert, Änderungen an Seiten der anderen Namensräume auf den entsprechenden Diskussionsseiten verhandelt, siehe Wikipedia:Diskussionsseiten. Vermutete Softwarefehler (Bugs) bitte gemäß Hilfe:Fehler und Probleme melden; am einfachsten in der Werkstatt. Softwareverbesserungen bitte auf der Unterseite Wikipedia:Verbesserungsvorschläge/Feature-Requests vorschlagen bzw. bewertend kommentieren, damit man sehen kann, welche Vorschläge an die Entwickler weitergeleitet werden sollten. Projektanregungen nichttechnischer Art, auch Anregungen auf Basis von Erfahrungen aus anderen Wikimedia-Projekten, können auf Wikipedia:Projektdiskussion besprochen werden. Allgemeine Fragen zur Wikipedia und zur Artikelbearbeitung werden bei Wikipedia:Fragen zur Wikipedia diskutiert. Administratives: Falls es sich um eine Angelegenheit handelt, die durch einen Administrator erledigt werden kann, stelle eine Anfrage bei Wikipedia:Administratoren/Anfragen.

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 (aktuelles 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

Oft Gefragtes (FAQ)

• Besucherzähler/Statistiken je Artikel: Der in MediaWiki vorhandene Zähler ist wegen zu hoher Serverbelastung ausgeschaltet. In der seitlichen Werkzeuge-Box erreicht man über den Link Seiteninformationen ganz unten oder am Ende jeder Seite unter dem Link "Abrufstatistik" dieses externe Tool, mit dem Zugriffszahlen für jeden Artikel ermittelt werden können.
• Rechtschreibprüfung: Ist meist als Funktion im Webbrowser sowie für angemeldete Benutzer in den Einstellungen, Karteireiter „Helferlein“, Abschnitt „Bearbeitungswerkzeuge“ verfügbar.
• Alte oder neue Rechtschreibung: Siehe Wikipedia Diskussion:Rechtschreibung.
• Farbenblindheit: Linkfarben lassen sich in den Einstellungen des Webbrowsers oder benutzerspezifisch auf besser unterscheidbare Farben umstellen, siehe WP:CSS und Benutzer:Wolfgangbeyer/monobook.css. Weiterhin existiert ein Helferlein für Benutzer mit Rot-Grün-Sehschwäche, siehe Wikipedia:BIENE/Farbenfehlsichtigkeit.
• Artikel bewerten: Unter dem Namen Artikel-Feedback wurde ein Bewertungssystem aktiv getestet, jedoch wieder verworfen.
• Weiterleitungen auf Artikelabschnitte sind technisch möglich. Vorzuziehen ist jedoch eine Verlinkung auf Artikelabschnitte durch die Vorlage:Anker. Dadurch bleibt der Link auch bei Änderung der Abschnittsüberschrift aktuell.
• Javascript einbinden: Ist ein Sicherheitsproblem und deshalb in Artikeln ausgeschlossen. Siehe auch WP:JS.
• Externe Links prinzipiell in einem separaten Fenster öffnen: Wird es nicht geben, da von vielen Benutzern als bevormundend empfunden. Wo ein Link geöffnet wird, kann üblicherweise durch die Art des Anklickens entschieden werden.
• Mindestgröße für neue Artikel: Umstritten, siehe Wikipedia:Wie schreibe ich gute Artikel.
• Allgemeinen Zugriff auf gelöschte Artikel: Gibt es indirekt via Marjorie-Wiki und weiterer externer Projekte.
• Beim Bearbeiten anzeigen, zu welchen Begriffen Artikel existieren: Sehr aufwendig zu realisieren. Einfachere Lösung: Vorschau nutzen.
• Artikelvorschau beim Überfahren von Links: Ist für angemeldete Benutzer in den Einstellungen, Karteireiter „Aussehen“, Abschnitt „Leseeinstellungen“ verfügbar. Alternativ gibt es die Funktion Navigations-Popups im Karteireiter „Helferlein“, mit der ebenfalls ein Ausschnitt des Artikels dargestellt wird.
• Metadaten, welche die Richtigkeit belegen: Interessant, aber aufwendig, vgl. auch das Projekt Wikidata.
• Essays: Eventuell, und wenn, dann nur was für Wikibooks.
• RSS-Feed: Ist verbesserungswürdig, hat aber eine niedrige Priorität.
• Versionsgeschichte erweitern um Grund für Löschung/Sperrung/Wiederherstellung und welcher Admin ausführte: Interessant, zum Teil umgesetzt über „Ansicht gelöschter Versionen“.
• Expertenabschnitte: Kontrovers diskutiert, kein Ergebnis.

Feature-Requests und Bugreports auf Phabricator

Explizite Feature-Requests sollten auf der Unterseite Wikipedia:Verbesserungsvorschläge/Feature-Requests diskutiert werden. Zugehörige Phabricator-Einträge bitte hier auflisten:

• phab:T2674 (Bugzilla:674) Artikel für einzelne Benutzer sperren
• phab:T2708 (Bugzilla:708) Links zu den Schwesterprojekten (Wiktionary, Wikibooks etc.) in das Interface integrieren
• phab:T32673 (Bugzilla:30673) Sprachspezifische Sortierreihenfolge (also Ä unter A, z. B. auf Spezial:Alle Seiten)
• … und viele weitere.

Seite nach Sichten aktualisieren

Hallo, ungesichtete Seiten werden als solche mittels einer Einblendung oben gekennzeichnet. Klickt man auf "Sichten", so sichtet man zwar die Seite/Version, aber die Einblendung bleibt bestehen. So könnte man glauben, das Sichten habe nicht funktioniert. Vermutlich würde es reichen, wenn der Klick auf "Sichten" nicht nur das Sichten, sondern danach eine Seitenaktualisierung auslösen würde. Grüße --Okmijnuhb 18:10, 13. Apr. 2024 (CEST)

Naja, aber die Seite könnte sehr groß sein und dein Internet langsam und teuer.

Wenn du das Sichten anklickst, bekommst du sofort eine Bestätigung, dass das offenbar geklappt hat, und die Sache ist binnen einer halben Sekunde erledigt.

Der Inhalt der Box ändert sich, und ich meine mich erinnern zu können dass sogar kurz ein Info-Popup aufscheint.

Würde man deinen Vorschlag umsetzen, kann es 10–20 Sekunden dauern, bis die Seite wieder aufgebaut wurde.

Wird mit voller Absicht so gehandhabt.

VG --PerfektesChaos 19:10, 13. Apr. 2024 (CEST)

Es gibt ja auch eine Einstellung, ob bei ungesichteten Seiten, die man aufruft, die letzte gesichtete Version oder die aktuellste ungesichtete Version angezeigt wird: Einstellungen --> letzte Änderungen --> Seitenanzeige: Bei den Sachen dort findest Du bestimmt was, was für Dich passt. Ich habe eingestellt „Detaillierte Übersicht“, „Stets die neuste Version anzeigen“ und hab den Haken an bei „Zeige einen Versionsvergleich zur stabilen Version...“, und das klappt alles wunderbar. --Hlambert63 (Diskussion) 19:34, 13. Apr. 2024 (CEST)

OK verste, Danke an alle! Grüße --Okmijnuhb 11:22, 14. Apr. 2024 (CEST)

Ich halte diesen Vorschlag für abgearbeitet. Wenn du anderer Meinung bist, kannst du diesen Baustein wieder entfernen. Sonst wird der Abschnitt in fünf Tagen ins Archiv verschoben. Okmijnuhb

Schalter für Kleinigkeiten

Die vom PC bekannte Checkbox habe ich beim Bearbeiten mit dem Smartie nicht gefunden.

Wenn's an NoScript liegt: Welchen Server muss ich noch erlauben? Oder in welche „Ecke“ muss ich schauen, um die Funktionalität zu finden?

Ansonsten (ich vermute, dieser Fall trifft zu) wünsche ich mir das Merkmal auch für Mobilgeräte.

--Helmut w.k. (Diskussion) 03:43, 14. Aug. 2025 (CEST)

Kategorien in der mobilen Ansicht

Wenn ich mit meinem Handy die Kategorien eines Artikel sehen möchte, muss ich auf klassische Ansicht gehen. Dann ganz nach unten scrollen und kann dann erst die Kategorien sehen. Wenn ich dann einen Artikel anschauen möchte, muss ich dann bei denm neuen Artikel wieder ganz nach und scrollen, um wieder die mobile Ansicht zu sehen. Es wäre besser, wenn bei der mobilen Ansicht man durch ein einfaches Klicken auf eine bestimmte Stelle die Kategorien sichtbar machen kann, so wie es jetzt bei den Abschnitten eines Artikels breits gemacht wird. --Raubsaurier (Diskussion) 18:58, 3. Sep. 2025 (CEST)

@Raubsaurier auf Spezial:Mobile Optionen den erweiterten Modus aktivieren, dann siehst du eingeloggt auch mobil alle Kategorien. --Johannnes89 (Diskussion) 20:56, 3. Sep. 2025 (CEST)

Abgesehen davon, dass ich unter Spezial:Mobile_Optionen keine Einstellungen für irgendwas mit Kategorien finde, möchte ich mich nicht mit dem Handy mit meinem Konto anmelden. Für Leute, die kein Konto haben, ist der Weg auch nicht gangbar. --Raubsaurier (Diskussion) 21:38, 3. Sep. 2025 (CEST)

Die Spezialseite zeigt nur mobil alles an (https://de.m.wikipedia.org/wiki/Spezial:Mobile_Optionen). Wenn man dort den erweiterten Modus auswählt (mw:Reading/Web/Advanced mobile contributions), erhält man Funktionen, die für mobile Lesende verborgen sind, um sie nicht mit zu vielen Optionen zu überfordern (darunter auch Kategorien).

Es gibt Tickets dafür, Kategorien standardmäßig für alle eingeloggten User (phab:T152199) oder auch für Lesende (phab:T24660) zu zeigen, aber das zuständige WMF Web-Team sieht daran keine Prio, weil laut deren Erkenntnissen den allermeisten Lesenden Kategorien egal sind. --Johannnes89 (Diskussion) 08:28, 4. Sep. 2025 (CEST)

Zusammenfassen von Edits

Es kommt immer wieder vor, dass man nach einem Edit draufkommt, dass man einen Tippfehler eingebaut hat und den in einem weiteren Edit richtigstellen muss. Man macht manchmal auch mehrere kleine Edits im gleichen Bereich. Manche machen auch hunderte Kleinstedits, was dann zu Irritationen wegen der aufgedunsenen Versionsgeschichte führt.
Wäre es möglich, optional das Zusammenfassen von Edits anzubieten? Also zB in Situationen, in denen die unmittelbar vorhergehende Bearbeitung vom gleichen Benutzer stammt, beim Abspeichern anzubieten, die neue und die vorangegangene Bearbeitung zusammenzuführen, sodass sie als eine Bearbeitung gelten? Oder auch das nachträgliche Zusammenfassen anbieten?
Analog zu „Squash Commits" bzw. dem „Interactive Rebase“ in Git? --Troubled @sset   ^{[ Talk ]}   19:23, 9. Sep. 2025 (CEST)

siehe phab:T9904 und phab:T21247. Bis in der Hinsicht was umgesetzt wird, könntest du en:User:Alex Smotrov/histcomb.js ausprobieren. Einbindung in deiner common.js/global.js: mw.loader.load('https://en.wikipedia.org/w/index.php?title=User:Alex Smotrov/histcomb.js&action=raw&ctype=text/javascript') --Johannnes89 (Diskussion) 11:39, 10. Sep. 2025 (CEST)

Vielen Dank für den Tipp, werde ich ausprobieren.
Beide phabs haben nach meinem Verständnis ebenfalls eine Manipulation der Anzeige als Inhalt. Mein Vorschlag ging aber weiter – warum können wir nicht mehrere Edits so mergen, dass sie tatsächlich nur als ein Edit gespeichert sind? Wenn ich in einem 100 kB großen Artikel einen externen Link ergänze, dann draufkomme, dass ich einen Tippfehler gemacht habe und in einem weiteren Edit ein Zeichen korrigiere, muss das permanent dokumentiert sein und mit jeweils 100 kB abgespeichert werden? Warum kann ich nicht die Korrektur so einbauen, dass die Version mit dem ursprünglichen Tippfehler gar nicht mehr als separate Version gespeichert bleibt?
Mir ist klar, dass das ziemlich tief eingreift, aber wenn im Einzelfall nichts dagegenspricht, könnte man mehrere konsekutive Edits doch schon auf DB-Ebene konsolidieren? Man könnte auch die Einzel-Edits für eine begrenzte Zeit separat speichern, wenn man das wirklich für nötig hält, aber der HEAD wäre dann immer die konsolidierte Version … Troubled @sset   ^{[ Talk ]}   11:12, 11. Sep. 2025 (CEST)

Es spricht dagegen, dass irgendwo auf dem Planeten jemand (RC) die Versionsnummer des ersten Edits auf Festplatte gespeichert oder in einem offenen Tab den Diff zu stehen haben kann.

• Vielleicht möchte man dich revertieren, womöglich erst in einigen Stunden nach Bedenkzeit oder bei Edit-Gelegenheit.
• Vielleicht standen da auch böse Wörter drin, oder du hast gegen WP:ANON verstoßen, was für mehrere Minuten offen sichtbar war. Deshalb sollte der Edit bei OS gemeldet und VM gegen dich gestellt werden.

Jetzt lässt du mit deinem zweiten Edit den ersten verschwinden, und es gibt nur noch die Versionsnummer vom zweiten Edit.

• Was du beim ersten Edit geschrieben hattest, welche ANON-Verletzung weltweit sichtbar wurde, ist in der Datenbank nicht mehr sichtbar, auch nicht für OS.
• Bei der VM macht sich der Meldende zum Horst.
• Alle, die deine Ersteditverschwindenlass-Methode praktiziert haben, können auf VM beschuldigt werden, sie hätten ganz ganz schlimme Beleidigungen geschrieben und gegen ANON verstoßen; mangels Diff können die Beschuldigten nicht nachweisen, dass das nicht stimmt, und alle die es tatsächlich gemacht hatten können behaupten der Meldende würde sie verleumden.

Das Transparenzgebot fordert, dass alle Logbucheinträge und Bearbeitungen mindestens für OS lesbar bleiben, und für den Rest mindestens die Existenz eines durch OS inhaltlich unsichtbar gemachten Vorgangs erkennbar ist.

• Wenn du einmal mit nachträglichen Manipulationen der Datenbank anfängst, ist für die Welt nicht mehr durchschaubar, was alles über welche Hintertüren verändert wurde.
• XML-Importeure und Server-Administratoren könnten beliebige scheinbare Bearbeitungen zu beliebiger Zeit durch irgendwen in die Datenbank einschmuggeln, aber ersteres wird in der VG der Seite geloggt und zweites wird auf dem Server geloggt und könnte durch anderes Server-Personal als unbefugt enttarnt werden.
• Alle logid und oldid eines Wiki müssten eigentlich lückenlos aufeinander folgen; durch Hamsterhusten soll es jedoch gelegentlich zu Aussetzern kommen.

Die beiden zitierten Phab-Tasks wünschen nur eine visuelle Zusammenfassung der separaten Versionen in der VG-Darstellung.

• Du begehrst jedoch, „beim Abspeichern anzubieten, […] zusammenzuführen, sodass sie als eine Bearbeitung gelten“.
• Tools und Methoden, die VG kompakter darzustellen, gibt es seit Jahrzehnten; teils MW-seitig.
• Du willst jedoch de facto aus der Datenbank spurenlos die erste Version mitsamt ihrem Bearbeitungskommentar löschen, und nur noch die zweite (, 3., 4., … 400.) gespeichert belassen.

VG --PerfektesChaos 15:06, 11. Sep. 2025 (CEST)

@PerfektesChaos: Danke für deine ausführliche Antwort, die ich leider erst jetzt mitbekommen habe.

• Ich hatte nicht vorgeschlagen, dass die Versionsnummer der ersten Bearbeitung beim nächsten, konsolidierten Edit getilgt und eine neue Version mit neuer Versionsnummer angelegt wird, sondern dass der nachfolgende Edit auf Wunsch mit dem vorherigen Edit zusammengeführt wird, also unter der bereits bestehenden Versionsnummer in die Source gemergt wird, so wie wenn beide Änderungen gleichzeitig erfolgt wären. Dadurch würde nie eine Versionsnummer „ungültig“, es würde gar keine neue vergeben (weil auch aus DB-Sicht keine neue Version angelegt wurde).
• Man könnte die maximale Zeit, innerhalb derer eine solche Zusammenführung möglich wäre, auf einen relativ kurzen Zeitraum begrenzen (zB 5 Minuten). Der Time Stamp bleibt dabei unverändert der Time Stamp des ersten Edits. 400 Edits wird man so nicht zusammenfassen können.
• Schon jetzt ist es oft nicht möglich, noch nach Stunden zu revertieren, weil mittlerweile eine weitere Bearbeitung im gleichen Abschnitt erfolgt ist. Wenn man eine Ergänzung revertieren möchte, in der mit einem zweiten Edit noch ein Tippfehler beseitigt worden war, muss man ohnehin „händisch“ beide Edits zusammenfassen oder beide einzeln in umgekehrter Reihenfolge revertieren. Bei meinem Vorschlag wäre es nur ein Edit, der dann eben revertiert würde. Und ja, wenn jemand zwei getrennte Ergänzungen durchführt, können die einzeln revertiert werden. Wenn man beide Ergänzungen in einem Edit einbaut, „riskiert“ man, dass alles revertiert wird. Das könnte man aber auch in Zukunft steuern, es gibt ja keinen Zwang, mehrere Edits zusammenzufassen, und das geschieht auch nicht automatisch. Wenn man das nicht möchte, damit man eben gegebenenfalls „einzeln“ revertiert werden kann, darf man das gerne so lassen. In der Praxis würde das ja nicht genutzt werden, um ein Dutzend größerer Edits zusammenzufassen, die man niemals als einen einzigen Edit gespeichert hätte, sondern kleine nachträgliche Korrekturen vorzunehmen, etwa einen Tippfehler auszubessern oder eine bessere Formulierung zu verwenden, was man sonst im gleichen Edit bereits gemacht hätte, wenn es einem nicht zu spät aufgefallen wäre.
• ZuQ des ersten Edits können beim Zusammenfassen als ZuQ des kombinierten Edits vorgeschlagen werden (dass ich noch einen Tippfehler korrigiert habe, muss ich nicht separat beschreiben). Man kann gegebenenfalls die ZuQ des kombinierten Edits auch geeignet ergänzen, wenn der zweite Edit das sinnvoll erscheinen lässt. Wenn man so viel ergänzt mit dem zweiten Edit, dass die ZuQ-Zeile nicht ausreicht, sollte man ohnehin wohl nicht kombinieren. Für solche Fälle ist das aber auch nicht gedacht – niemand stört sich daran, wenn zwei größere Änderungen bzw. Ergänzungen in zwei separaten Edits durchgeführt werden (der zweite Edit erfordert dann auch typischerweise ein paar Minuten). Es geht um Tippfehler und Formulierungsdetails.
• Man könnte auch für eine begrenzte Zeit (zB ein Jahr) die Einzel-Edits separat in einer eigenen Tabelle(nstruktur)/weiteren DB speichern (worauf dann Oversighter und gerne auch Admins Zugriff hätten). Dadurch könnten während dieses Zeitraums problematische Edits weiterhin identifiziert werden. Aber ja, nach mehr als einem Jahr wäre es dann nicht mehr möglich, festzustellen, dass damals für maximal 5 Minuten ein problematischer Inhalt online war. Es stellt sich auch die Frage, ob jemand nach über einem Jahr noch sanktioniert werden sollte, weil die Person vor mehr als einem Jahr vielleicht etwas Inakzeptables geschrieben, aber innerhalb von 5 Minuten selbst wieder entfernt hatte, ohne dass das damals aufgefallen wäre.
• Zu den technischen und organisatorischen Möglichkeiten von DB-Admins (und deren Grenzen) könnte ich auch noch einiges schreiben, das würde hier aber zu weit führen.

Ich bin mir bewusst, dass das eine riesige Änderung wäre, und rechne nicht damit, dass das in absehbarer Zeit ernsthaft in Angriff genommen wird, wenn überhaupt jemals. Dauerhaft Informationen zu speichern, die nie mehr jemand braucht, ist allerdings schon grundsätzlich nicht sinnvoll, und verursacht permanent einen nicht zu vernachlässigenden Mehraufwand bei der Analyse von Versionsgeschichten, in denen jede Tippfehlerkorrektur einzeln verzeichnet ist, was man für die inhaltliche Arbeit nicht braucht.
Trotzdem noch einmal danke für deine Zeit. Beste Grüße, Troubled @sset   ^{[ Talk ]}   15:02, 22. Sep. 2025 (CEST)

@ „sondern dass der nachfolgende Edit auf Wunsch mit dem vorherigen Edit zusammengeführt wird, also unter der bereits bestehenden Versionsnummer in die Source gemergt wird“

• Es ist völlig wumpe, ob die neue Versionsnummer auf die bestehende gelegt wird, oder die alte und deren Bearbeitungsinhalt eliminiert werden würde.
• Es würde dann dazu führen, dass ein um 11:29 ausgeführter Diff zu einem anderen Ergebnis führen würde als der um 11:41 mit derselben URL.
• Man wüsste noch nicht einmal, um wie viel Uhr an welchem Tag der allererste Edit dieser Serie ausgeführt wurde, und ohnehin nicht was da alles zwischendurch mal sichtbar war.
• Damit kann ich da trotzdem alle möglichen PA und ANON reinschreiben, und wenn ich auf VM gemeldet werde, hänge ich einfach einen Lösch-Edit hinten dran. Dann kann mir niemand mehr nachweisen, was da drei Tage lang im Internet zu sehen war, weil es physisch aus der Datenbank gelöscht wurde.
• Genauso kann ich jetzt jeden, den ich nicht mag, auf VM verpetzen, da wären ganz ganz böse Beleidigungen über mich dringestanden, bloß wären die nicht mehr nachweisbar, weil es mit der Troubled-asset-Methode wieder gelöscht wurde. Die Gemeldeten können nicht nachweisen, dass sie das nicht getan hatten, weil es physisch aus der Datenbank entfernt wurde.

Es ist ein absolutes Grundprinzip der Wikis, dass Logbuch-Einträge und Seitenbearbeitungen niemals aus der Datenbank gelöscht werden können.

• Maximal können sysop/OS den Textinhalt für andere unsichtbar machen. Die Existenz bleibt für alle sichtbar.
• Andere mit denselben Rechten können es aber jederzeit nachlesen und Auskunft geben.
• Selbst die Missbrauchsfilter-Meldungen, die wegen Fehlprogrammierung schon längst nicht mehr existierender Filter mal ausgelöst wurden, werden unerbittlich auch nach zwei Jahrzehnten den Unschuldigen zur Last gelegt.

Dein Begehren würde zu gravierenden juristischen Schäden der Projekt-Integrität führen, und das Transparenzgebot und die Nachvollziehbarkeit von Bearbeitungen unwiederbringlich zerstören.

• Der Vorteil ist hingegen extrem mickrig; kürzer angezeigte VG, sonst nix.
• Es gibt zahlreiche und dir bereits dargestellte Lösungsmöglichkeiten für die VG, die teilweise bereits in Tools oder MW-Einstellungen realisiert wurden: „11 folgende Bearbeitungen desselben Kontos“ – und die kannst du dir dann alle auf einen Schlag oder jede einzeln anzeigen lassen.
• Deshalb wird nie nie nie jemand eine solche „Verbesserung“ in >1000 Wikis anfassen.

VG --PerfektesChaos 17:04, 22. Sep. 2025 (CEST)

Ja, es gibt durchaus Gründe, meinen Vorschlag kritisch zu sehen, teilweise kann ich deinen Überlegungen aber nicht folgen.

• Weder sollte „die neue Versionsnummer auf die bestehende gelegt“ noch „die alte und deren Bearbeitungsinhalt eliminiert“ werden. Und die Zeitstempel vom ersten bis zum letzten enthaltenen Edit samt der Zahl der gemergten Einzeledits sollen zumindest in der parallelen Behaltephase sichtbar sein.
• Dass Fake-Missbrauchsfiltermeldungen auch nach zwei Jahrzehnten Unschuldigen unerbittlich zur Last gelegt werden, finde ich nicht beruhigend und kein Qualitätsmerkmal, sondern eine unerfreuliche Konsequenz des Prinzips, nie etwas zu löschen. Im Übrigen geht es mir nicht um nachträgliches Löschen von nicht mehr relevanten oder sogar falschen Einträgen (darüber könnte man separat nachdenken), sondern um das Vermeiden des Entstehens von Beginn an von unzähligen Einträgen, die nicht separat dauerhaft erhalten bleiben müssen.
• Ich hatte eine Zeitspanne von fünf Minuten vorgeschlagen, innerhalb derer ein Zusammenfügen maximal möglich sein soll. Wenn etwas drei Tage dort stand, kann man es nicht mehr „verschwinden“ lassen.
• Ich hatte vorgeschlagen, die Einzeledits für ein Jahr separat zu speichern und das für Admins etc. sichtbar zu machen. Wenn also jemand einen VM-würdigen Verstoß innerhalb von fünf Minuten entdeckt, sich den Diff speichert und eine VM einreicht, und dann der Diff den Verstoß nicht mehr zeigt, weil er vor Ablauf der fünf Minuten noch korrigiert wurde, können Admins etc. das noch ein Jahr lang jederzeit prüfen und den Verfasser sanktionieren, wenn das – trotz Eigenreverts innerhalb von fünf Minuten – sanktionierbar ist, und andererseite gegebenenfalls Maßnahmen gegen den VM-Steller ergreifen, wenn sich die Vorwürfe als erfunden herausstellen sollten. Man kann also weder alles hineinschreiben, was kurz danach nicht mehr nachvollziehbar wäre, noch kann man andere verpetzen, die sich nicht dagegen wehren können.
  Ja, nach mehr als einem Jahr (oder nach welchem definierten Zeitraum auch immer) wäre gegebenenfalls nicht mehr nachvollziehbar, dass damals ein bestimmter Inhalt für weniger als fünf Minuten (oder für wie lange auch immer) online war. Dass dies „zu gravierenden juristischen Schäden der Projekt-Integrität führen“ und „das Transparenzgebot und die Nachvollziehbarkeit von Bearbeitungen unwiederbringlich zerstören“ würde, sehe ich nicht. Wenn es ernsthafte Bedenken in dieser Hinsicht geben sollte, könnte man die Einzeledits auch länger speichern, ein separates „Merge-Recht“ einrichten, das man bei Missbrauch entziehen kann, und Ähnliches.

Mir ist klar, dass das eine große Änderung wäre. Es gäbe aber auch noch ein paar andere Vorteile außer der übersichtlicheren Versionsgeschichte. Ich finde ich es zB hinterfragenswert, dass eine Verurteilung wegen eines Verbrechens früher aus dem Strafregister getilgt ist als ein Tippfehler aus der WP.

Danke für deine Zeit, du kannst das gerne schließen. Troubled @sset   ^{[ Talk ]}   15:11, 23. Sep. 2025 (CEST)

Kaputte Ansicht VisualEditor mobil

Hat noch jemand seit Einführung der Temporären Konten das Problem, das der VisualEditor am Handy total verbuggt ist? Bei jeder Bearbeitung hängen ganze Textblöcke übereinander bzw. über Bildern, man sieht nichts mehr. --~2025-67180-6 (Diskussion) 15:57, 20. Sep. 2025 (CEST)

Wikidata-Link eines Artikels automatisch in neuem Tab öffnen?

Der Titel sagt eigentlich alles. Ist das möglich bzw. könnte es möglich gemacht werden? --~2025-67210-9 (Diskussion) 17:09, 20. Sep. 2025 (CEST)

Meinst Du Desktop-Browser? Dafür gibt es schon diverse Mittel (entweder Rechtsklick-Menü, oder aufs Mausrad drücken, ist für mich tägliche Praxis).--Hlambert63 (Diskussion) 20:35, 20. Sep. 2025 (CEST)

Genau, Desktop. Das stimmt zwar, ich meine aber, dass beim einfachen Linksklick Wikidata automatisch in einem neuen Tab geöffnet wird. --~2025-67453-9 (Diskussion) 13:45, 21. Sep. 2025 (CEST)

@~2025-67453-9 In Wikipedia:Technische Wünsche/Wunschparkplatz, Kapitel Wenn ich auf einen Link gehe bei Wikipedia, öffnet sich kein neuer Tab. hatten wir die Diskussion um neue Tabs schon mal. Neue Tabs werden von vielen als störend empfunden. Vielleicht kann man das anders lösen

• entweder gibt es dafür diverse Browser-Addons

• dort wird auf ein Helferlein Benutzer:PerfektesChaos/js/clickDivertimento verwiesen. Ich weiß aber nicht, ob das Helferlein Deinen Fall auch abhandeln kann. Setzt natürlich voraus, dass man angemeldet ist. --Hlambert63 (Diskussion) 17:50, 21. Sep. 2025 (CEST)

Button "Umschalten zum bisherigen Aussehen"

Die Umstellung des Standard-Designs ist mittlerweile einige Monate her. Sollte man obgenannten Button nicht langsam mal umbenennen, z.B. in "Umschalten zum alten Aussehen"? --~2025-67453-9 (Diskussion) 13:46, 21. Sep. 2025 (CEST)

Der wird eher irgendwann verschwinden. Die russische Wikipedia ist noch nicht umgestellt, solange (+ Zeitraum X) wird der Link noch so benannt und verfügbar sein. -- hgzh 08:30, 23. Sep. 2025 (CEST)

Warnung bei nicht ausgefüllter ZQ standardmäßig aktivieren

Ich fände es sinnvoll, wenn in den Einstellungen die Option „Warnen, sofern beim Speichern die Zusammenfassung fehlt (oder es sich um die Standardzusammenfassung beim Zurücksetzen handelt)“ standardmäßig aktiviert wäre. Bei Neulingen ließen sich so Missverständnisse und daraus resultierende unnötige Reverts vermeiden und erfahrene Benutzer wissen ja, wo sie die Einstellung notfalls ändern bzw. deaktivieren können. --Brettchenweber (Diskussion) 14:24, 23. Sep. 2025 (CEST)

Du kannst das gern sinnvoll finden; wäre es vermutlich.

Das wird schon zwei Jahrzehnte lang diskutiert, oder seit es dieses Feature gibt.

• Dabei vertreten einige sehr lautstarke und schon sehr lang Dabeiseiende, dass es ein Menschenrecht geben würde, ohne BK zu editieren; dass es für sie geistig überfordernd oder viel zu viel Arbeit wäre, sich einen BK ausdenken zu müssen; dass Newbies damit überfordert sei könnten, einen geeigneten BK anzugeben, und sie deshalb durch die abschreckende Fehlermeldung daran gehindert würden, einen sinnvollen Edit zu speichern.
• Es ist auch unklar, wie sich die Neueinführung eines solchen Features auf Bestandskonten auswirken würde, insbesondere solche, die noch niemals eine solche Einstellung vorgenommen hätten, also nicht ein- und wieder ausgeschaltet haben. Die Wiki-Datenbank behandelt sowas wie Neukunden. Das empfinden wiederum die Lautstarken als bevormundend und unerträglich und eine inakzeptable Belästigung.
• Wenn der BK von Anfang an verpflichtend gewesen wäre, würde sich die Frage nicht stellen. Weil es aber erst später kam, ist es erstmal so wie es ist.
• Du würdest ein MB benötigen, um zu dokumentieren, dass eine überwältigende Mehrheit der deWP-Community sowas haben möchte, und brauchst dies, um gegenüber der WMF eine solche Entwicklung begründen zu können.

Man hätte wohl wenig Lust, daraus ein nur für die deWP konfigurierbar zu gestalten; stellt sich die Frage, wie die 1000 anderen Wikis das sehen und wie die Migration ausgestaltet werden soll, und ob da jedes Wiki nunmehr eine individuelle Konfiguration vornehmen solle.

VG (nicht signierter Beitrag von PerfektesChaos (Diskussion | Beiträge) 16:06, 23. Sep. 2025 (CEST))

Ich kann das gern sinnvoll finden? Vielen Dank. ;-) --Brettchenweber (Diskussion) 22:42, 23. Sep. 2025 (CEST)

Separate E-Mail-Adresse für das Zurücksetzen des Passworts

Ich habe eine E-Mail-Adresse hinterlegt (und verifiziert). Diese Adresse wird im „täglichen Betrieb“ verwendet (meine Absender-Adresse bei Wiki-Mails, diverse Hinweis-Mails von WP an mich, …). Ich verwende sie auch bei Anmeldungen für Veranstaltungen und andere Kommunikation mit WP-Instanzen. Diese E-Mail-Adresse ist nicht wirklich geheim oder auch nur vertraulich. Gleichzeitig ist dies aber auch die Passwortrücksetzungsadresse für den „Notfall“.
Ich schlage vor, die Möglichkeit anzubieten, für die Passwortrücksetzung auf Wunsch eine separate, sonst für nichts verwendete alternative E-Mail-Adresse angeben zu können. Dies würde mMn die Sicherheit des Rücksetzungsvorgangs via E-Mail verbessern (insbesondere natürlich dann, wenn für diese Adresse auch ein separates, speziell abgesichertes Postfach verwendet wird).
Wer das nicht will, kann für beides gerne die gleiche Adresse angeben (oder man muss die zweite Adresse erst aktivieren – „Möchtest du für die Passwortrücksetzung eine andere Adresse verwenden?“). Default bei einer allfälligen Einführung dieser Option wäre natürlich „keine andere Adresse“, weshalb sich für Bestandskonten nichts ändern würde und niemand gezwungen wäre, irgendetwas tun zu müssen. --Troubled @sset   ^{[ Talk ]}   16:04, 27. Okt. 2025 (CET)

Spende

Ich würde gern spenden. Das Procedere ist mir aber viel zu kompliziert. Außerdem muss ich alle meine persönlichen Daten angeben, bevor ich eine Spende auslösen kann. Genau das möchte ich aber nicht. Daher mein Vorschlag:

Sie ermöglichen eine Spende, indem Sie Ihre Kontonummer und den Code für die richtige Zuordnung bei Ihnen angeben. Mehr brauche ich nicht. Das sollte doch möglich sein. Dann würde ich überweisen und das war's dann. Kriegen Sie das hin ?

Mit freundlichem Gruß

G. Kreuzer --~2025-31172-98 (Diskussion) 11:13, 4. Nov. 2025 (CET)

Spendenkonten findet man unter:

Spenden – WIKIMEDIA Österreich

Spenden - Wikimedia Deutschland --Ailura (Diskussion) 11:15, 4. Nov. 2025 (CET)

Bearbeitung wieder herstellen oder verwerfen

dieser Pop-up, so sehr ich mir den gewünscht habe (ohne, dass er auch in der App installiert wurde, die wohl endgültig nur für Leser gestaltet ist), weist einige Bugs auf. So taucht er bei einer erneuten Bearbeitung gleich zu Anfang auf, auch wenn die Änderungsvorschau keine Änderungen anzeigt. Wenn man dann allerdings ohne Edit abbricht, heißt es in einem neuen Pop-up "wollen Sie wirklich abbrechen?" Der Auslöser dieser Anzeige sollte vorher schauen, ob etwas am Artikel verändert wurde oder nicht. Ansonsten schaut man erstmal irritiert und verunsichert auf den Bildschirm und fängt an, alle möglichen Szenarien durchzugehen, was man anrichten könnte, wo doch überhaupt nichts passiert ist. File:WP pop-ups contradicticting e.o. (Screenshot 20251107 Firefox).jpg --MenkinAlRire (Diskussion) 11:26, 7. Nov. 2025 (CET)