Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2020

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2020#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests/Archiv/2020#Thema_1

Benutzerverzeichnis

Hallo Leute! Aus dem Neuanmeldungslogbuch werden ja ständig diverse unanständige Namen blockiert, solche Sachen wie "Benutzer XY ist ..." oder "... gehört ..." usw. Nun tauchen aber all diese Namen unter Spezial:Beiträge per Dropdown auf, so wie ich nur einen Benutzernamen eintippe, insb. natürlich bei solchen Benutzern, die offenbar Opfer eines Cyberstalkers geworden sind (Stichwort Otto Braun usw.). Ich rege an, derartige Namen grundsätzlich aus dem Dropdown zu nehmen, da die Stalker und Störer hier sonst einen dauerhaften Erfolg zu verzeichnen haben! Grüße, --178.112.116.69 13:16, 5. Feb. 2020 (CET)

Das mit den Dropdowns ist mir auch schon aufgefallen – gebt unter Spezial:Beiträge einfach mal Anfangsstücke des Namens „Schniggendiller“ ein. (Sorry, brauche halt ein Beispiel, und dein Fall ist leider extrem.) Mir kommt es etwas inkonsistent vor, dass Benutzernamen, die versteckt werden, damit zwar automatisch nicht mehr im Neuanmeldungslogbuch und offenbar (auch automatisch?) nicht mehr bei ihren Edits angezeigt werden, in der Benutzerliste und den Dropdowns aber verbleiben. Zumindest was die Benutzerliste betrifft, gab es letztes Jahr eine Diskussion auf Wikipedia:Administratoren/Anfragen zum Thema technische Machbarkeit und Abdeckung durch das Regelwerk. Ich fände es übrigens nicht richtig, Benutzernamen (auch grob ungeeignete) völlig unauffindbar zu machen – im Sinne der Transparenz wäre das nicht wünschenswert. Nur müssen sie nicht unbedingt so leicht bzw. unabsichtlich zu finden sein. Ein bisschen Aufwand sollte schon betrieben werden müssen. Gegebenenfalls fände ich technische Änderungen an der Wiki-Software, die das ermöglichen, sinnig, für harassment-Bekämpfung hat die Foundation doch immer recht viel übrig. --77.3.24.176 10:44, 9. Feb. 2020 (CET)

Technisch wäre das ein "Pipikram". Die betreffenden Benutzernamen kriegen ein Flag in einer zusätzlichen Spalte der Datenbanktabelle und werden fortan nicht mehr angezeigt. Wenn man Seitenversionen verstecken kann, geht das logischer Weise mit Benutzernamen auch. --178.112.116.69 17:27, 9. Feb. 2020 (CET)

Ja, klar, wobei ich ehrlich nicht weiß, wie das mit der Datenbank tatsächlich gehandhabt wird, denn Klone davon sind ja frei zum Runterladen verfügbar. Da das Verstecken (oder gar Oversighten) von Seitenversionen auch zum Verbergen von Inhalten dient, die nicht jeder zu Gesicht bekommen soll, wäre es wohl kontraproduktiv, wenn die im Klartext und einfach nur mit einem Flag versehen in der (frei herunterladenbaren) Datenbank stehen würden…? --77.3.24.176 19:10, 9. Feb. 2020 (CET)

Naja, man könnte für die betreffenden Namen auch einfach andere Leserechte zuordnen, z.B. Oversighter only. Vermutlich wäre das sogar die einfachere Variante. Letztlich geht es aber darum, der allzu vordergründigen Sichtbarkeit für Otto-Normal-Benutzer abzuhelfen. --178.112.116.69 19:20, 9. Feb. 2020 (CET)

So oder so dürfte die technische Infrastruktur fürs Verbergen jedenfalls vorhanden sein (Oversighter only wäre – wegen der Transparenz – aus meiner Sicht beim gewöhnlichen Avoided-„XY holt sich einen runter“-Benutzernamenvandalismus ein Overkill, aber es gibt sicher auch Namen, die etwa wegen persönlicher Informationen mit höherem Zugriffsschutz belegt sein sollten), insofern dürfte da eher die Frage nach dem genauen „Geschäftsprozess“ (wer wann wie genau mit welchem Endresultat) in den Vordergrund rücken. --77.3.24.176 23:04, 9. Feb. 2020 (CET)

Versionsgeschichte für einzelne Abschnitte/Textpassagen

Derzeit kann die Versionsgeschichte nur für ein komplettes Lemma angezeigt werden. Ich fände es wünschenswert, ein Feature zu implementieren, sodass dies für einzelne Abschnitte möglich wäre bzw. für bestimmte Textpassagen, die man vorher markiert hat. Sollten Einzelnachweise für bestimmte Passagen fehlen, kann man so zum Beispiel nachvollziehen, wenn jemand in seinen Änderungskommentar eine Quelle angegeben hat. Außerdem ist so die Autorenschaft für einzelne Teile eines Lemmas leichter nachvollziehbar.--Asperatus (Diskussion) 09:35, 23. Mär. 2020 (CET)

Vorschau des Artikelabschnitts bei Links auf Artikelabschnitte, statt des Anfangs des Artikels

Ist zwar nur eine Kleinigkeit aber: Wäre es nicht möglich (und besser), bei Verlinkungen, die zu einem Abschnitt eines Artikels führen (also nicht zum Anfang, dem „oberen Rand“, des Artikels), diesen Abschnitt in der Linkvorschau auch zu zeigen. Denn wenn es einen Grund gibt, dass direkt auf den Abschnitt verlinkt wird, sollte die Vorschau auch die Information dieses Abschnitts enthalten und nicht – wie bislang noch – den in diesem Fall scheinbar zu allgemeinen oder inhaltlich nicht dazu passenden Artikelanfang. --DJNevage (Diskussion)--DJNevage (Diskussion) 22:55, 15. Apr. 2020 (CEST)

Beobachtungsliste

In der Beobachtungsliste sollte nicht nur die letzte Änderung mit der Anzahl der veränderten Zeichen und dem letzten ändernden Benutzer angezeigt werden. Dieses hat wenig Aussagekraft. Stattdessen sollte angezeigt werden können, wie viele Änderungen (mit entsprechenden Zeichen) seit dem letzten Besuch der Seite erfolgt sind. Wenn ein Benutzer beispielsweise eine größe Änderung (mehr als 1000 Zeichen) vornimmt und infolgedessen ein anderer Nutzer einen Tippfehler korrigiert (weniger als 10 Zeichen Änderung), so wird aus der Beobachtungsliste nicht ersichtlich, dass die große Änderung stattgefunden hat. Will man wissen, ob es eine große Änderung gab, muss jede Seite in der Beobachtungsliste einzeln aufgerufen und dann die Versionsgeschichte geöffnet werden.--Asperatus (Diskussion) 17:25, 19. Apr. 2020 (CEST)

Das geht mittels

• Einstellungen / Beobachtungsliste > Alle Änderungen in der Beobachtungsliste anzeigen, nicht nur die letzten
• Einstellungen / Letzte Änderungen > Änderungen auf „Letzte Änderungen“ und der Beobachtungsliste nach Seite gruppieren

Gruß --FriedhelmW (Diskussion) 19:00, 19. Apr. 2020 (CEST)

Interne Links nach Verschiebung automatisch ersetzen

Wenn innerhalb von der deutschsprachigen Wikipedia eine Seite verschoben wird, müssen meines Wissens nach alle Wikilinks, die auf die Seite verwiesen haben, angepasst werden, sofern man nicht mit einer Weiterleitung leben möchte. Verschiebt man eine Datei bei Wikicommons, können die entsprechenden Links meines Wissens automatisch angepasst werden. Könnte man für die deutschsprachige Wikipedia eine automatische Anpassung einfügen oder besteht schon irgendwie die Möglichkeit?--Asperatus (Diskussion) 10:12, 29. Apr. 2020 (CEST)

Das wurde schon diskutiert. Ein solcher Automatismus ist nicht sinnvoll, weil in vielen Fällen erst durch das händische Fixen der Links Fehler aufgedeckt werden. Das trifft insbesondere beim Verschieben von bisher klammerfreien Lemmata auf beklammerte zu, da findet man haufenweise bis dahin falsch verlinkte Stellen. Auch wenn man (z.B.) "(Fußballspieler)" auf "(Fußballspieler, 19xx)" verschiebt, findet man solche Fehlverlinkungen, deren Auflösung teilweise sehr mühsam ist, aber auf jeden Fall angebracht. -- Jesi (Diskussion) 15:17, 29. Apr. 2020 (CEST)

Das leuchtet mir nicht ganz an. Wann hat die Diskussion stattgefunden? Ich würde sie gerne nachlesen. Bestimmt könnte man einen Bot fehlervermeidend programmieren. Werden die Fehler aufgedeckt, die ohnehin schon vorhanden waren, oder wären sie durch die automatische Verschiebung entstanden? Was spräche zum Beispiel dagegen, die Links zu Urteil (Rechtswissenschaft) auf Urteil (Recht) automatisch zu verschieben?--Asperatus (Diskussion) 23:51, 1. Mai 2020 (CEST)

Ich geb dir ein anderes Beispiel (willkürlich aus meinen Notizen genommen): Ich hab Fritz Stein zur Anlage einer BKL auf Fritz Stein (Musikwissenschaftler) verschoben. Beim Fixen der Links hab ich gemerkt, dass in Die Emmingers auf Fritz Stein verlinkt war, aber eben nicht auf diesen, sondern einen Schauspieler. Oder bei Erich Moser war in Landtag Nordrhein-Westfalen der dort gemeinte Architekt auf den (vorher klammerfreien) Politiker verlinkt. So etwas kannst du keinem Bot (sinnvoll und allgemeingültig) erklären. Solche Beispiele kann ich dir noch hunderte nennen. Und das betrifft nicht nur Personen. Du könntest zwar versuchen, so etwas in Wikipedia:Bots/Anfragen einzutragen, höchstwahrscheinlich würde aber deine Anfrage mit Verweis auf Intro Punkt 7 abgelehnt. -- Jesi (Diskussion) 12:15, 3. Mai 2020 (CEST)

Dennoch dürfte es ja Anwendungsfälle geben, wo sowas problemlos möglich ist, beispielsweise wenn durch die Verschiebung nur ein Orthographie-Fehler behoben wird.--Asperatus (Diskussion) 15:15, 4. Mai 2020 (CEST)

Wenn ein „Orthographie-Fehler behoben wird“, also eine definitive und in jedem Kontext falsche Schreibung aus den Bestandsverlinkungen zu eliminieren ist (sowie im Fall unerwünschter Klammerlemma-Konstrukte) ist bei größerer Menge ein individueller Bot-Auftrag möglich. Aber nur dann.

Dein Begehren ging jedoch dahin, dass nach jeder Verschiebung die globale Software immer automatisch in allen verlinkenden Seiten den Quelltext dahingehend ändern soll, dass nunmehr das neue WL-Ziel dort stünde. Das wird aus vielerlei Gründen niemand machen.

VG --PerfektesChaos 15:48, 4. Mai 2020 (CEST)

Wie wäre so ein Bot-Auftrag zu veranlassen?--Asperatus (Diskussion) 15:50, 4. Mai 2020 (CEST)

Ist das nicht aus der verlinkten Seite Wikipedia:Bots/Anfragen ersichtlich? --Diwas (Diskussion) 01:59, 5. Mai 2020 (CEST)

Historische Interwikilink-Bot-Aktionen ausblenden

Hallo, ein beträchtlicher Teil der Versionsgeschichten unserer Artikel sind Änderungen durch Interwikilinks setzende Bots.. Es wäre schön, wenn der individuelle Nutzer diese in Versionsgeschichten dauerhaft ausblenden könnte (ohne gleich sämtliche Aktionen von Konten mit Bot-Flag auszublenden) zur besseren Übersicht. Grüße, --Polarlys (Diskussion) 21:10, 7. Mai 2020 (CEST)

Ich fürchte, das lässt sich technisch nicht so einfach realisieren, da - soweit ich weiß - diese Bot-Edits damals nicht gesondert markiert wurden und es eben bloß die Vermerke in der Zusammenfassungszeile gibt. -- Chaddy · D 21:17, 7. Mai 2020 (CEST)

Sortierung in Spezial:Linkliste

Derzeit werden die Suchtreffer in Spezial:Linkliste nach Erstelldatum der Seiten angezeigt. Vielleicht könnte man ein neues Feature implementieren, dass verschiedene Sortierungen zulässt. Ich würde mir insbesondere eine Sortierung nach Zahl der Seitenaufrufe wünschen, sodass "wichtigere" Artikel zuerst erscheinen.--Asperatus (Diskussion) 10:03, 29. Apr. 2020 (CEST)

Dieser Wunsch ist schon sehr alt (phab:T4306), aber mit der derzeitigen Datenbankstruktur relativ schwer zu machen. Gruß, -- hgzh 12:22, 3. Mai 2020 (CEST)

Doppel-posting ist bööööse. Ich hatte hier bereits am 29. April geantwortet.

VG --PerfektesChaos 16:44, 12. Mai 2020 (CEST)

Bild Vorschau in Versionsunterschied

Wenn jemand ein Bild hinzufügt, ändert oder löscht sollte beim Anzeigen des Versionsunterschieds auch das Bild angezeigt werden. Es ist oft mühsam das geänderte Bild im Artikel rauszusuchen. --Uranus95 (Diskussion) 16:22, 13. Mai 2020 (CEST)

Dieses Skript wandelt Linksyntax in Versionsunterschieden und in JavaScript-/CSS-Seiten in echte Links um. Gruß --FriedhelmW (Diskussion) 16:34, 13. Mai 2020 (CEST)

Und die Idee, eine Bildvorschau einzublenden, ist im Prinzip ganz gut, aber nicht Aufgabe eines Diff.

Der Diff ist lediglich ein textlicher Vergleich, und auch die klitzekleine Veränderung eines Vorlagenparameters kann riesige Auswirkungen haben.

Es mag also gern jemand ein Benutzerskript schreiben, das veränderte Dateibezeichner im Diff erkennt und dazu anbietet, auf Klick das gelöschte bzw. ersetzte Bild anzuzeigen, wenn sich jemand dafür interessieren würde.

Für alle Bearbeiter und die globale Software ist das eher nicht im Beuteschema. Je mehr so Zeugs desto komplizierter, alle Funktionen zu verstehen und desto schwierieger, desto langsamer wird alles, und die globale Programmierung muss auch noch robust bleiben. Immer alle Bilder anzuzeigen würde den Diff noch langsamer machen, zumal es bereits drei verschiedene Darstellungsmethoden des Diff gibt, und noch eine vierte von Schnark.

VG --PerfektesChaos 16:51, 13. Mai 2020 (CEST)

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 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)

Dark Mode

Als Webentwickler bemerke ich immer mehr, dass Kunden explizit nach einem Dark Mode für ihre Webseiten fragen, da dieser energiesparender gerade auf Mobile Devices ist (was ja auch Sinn ergibt, müssen nicht alle Pixel erhellt werden). Gibt es diesbezüglich schon Entwicklungen in den Standard-Skins (theoretisch könnte das ja in die bestehenden CSS-Dateien mittels einer media query ( @media (prefers-color-scheme: dark) {} ) mit eingepflegt werden.)? Und wenn nicht, an wen müsste man sich wenden wegen feature request? --Odeesi _{talk to me} ^{rate me} 11:39, 16. Jun. 2020 (CEST)

Das wird häufiger gefragt, vermutlich gibt es schon ausführlichere Antworten hier im Archiv.

Kurz gesagt: Das geht nicht mal so locker eben.

Twitter, Facebook, Google hat nur zwei oder drei Seitengestaltungen und ein zentrales Management darüber.

• Wir hier haben Millionen von Designs auf Seiten, die voraussetzen, dass es einen hellen Hintergrund geben würde.
• Beispielsweise Grafiken aller Art mit transparentem Hintergrund, die sich darauf verlassen, dass der Hintergrund irgendwie hell wäre.
• Beispielsweise Schriften aller Art in mittelgrau, mittelblau, die nur gegen einen hellen Hintergrund kontrastieren.
• Hier darf jeder Autor eines Artikels die Farben für seine verwendeten Elemente selbst festlegen. Eine globale Kontrolle wie bei Twitter, Facebook, Google, die steuern könnte, dass die Farben im Dark Mode sich entsprechend anpassen würden, existiert nicht.

Heißt: Wenn man das machen würden, sähen sehr viele Seiten miserabel aus und wären unlesbar.

Es gibt technische Lösungen, die nicht das ausgelieferte HTML/CSS verändern, sondern die nachträglich bei jeder beliebigen Seite aller Domains die Farben umschreiben könnten. Die haben aber auch das Problem mindestens mit Pixelgrafiken mit transparentem Hintergrund, und selbst bei SVG darf man nicht einfach die Farben der polnischen oder bayerischen Flagge von weiß-rot oder blau-weiß umschreiben auf grau-grün. Das müsste aber sowieso eine App auf dem persönlichen Browser auf deine eigene Verantwortung regeln. Geht auch um Augenschonung und Einschlafphase.

In jedem Fall würde sich nicht die deutschsprachige Wikipedia für sich allein um diese Angelegenheit kümmern, sondern die globale MediaWiki-Software müsste das für 1000 Wikis regeln. Die strecken aber auch alle viere von sich, weil sie keine Möglichkeit sehen, Milliarden individuell gestalteter Seiten umzuschreiben.

VG --PerfektesChaos 12:37, 16. Jun. 2020 (CEST)

Die Wikipedia-App für Android hat unter Einstellungen den Punkt Farbschema der App mit zwei hellen und zwei dunklen Modes. Gruß --FriedhelmW (Diskussion) 12:45, 16. Jun. 2020 (CEST)

Ja, danke für den Hinweis.

Wobei die App-Darstellung aus anderen Gründen schon in der Normaldarstellung nicht so gut und funktional wie in einem Browser sein soll.

@FriedhelmW: Magst du mal berichten, wie stark deren Modes eingreifen? Eigentlicher Dark Mode ist Invertierung, also weiße Schrift auf schwarzem Untergrund, und das geht schief wenn wir explizit dunkelgraue Schrift vereinbart haben.

„Heller Modus“ ist einfach nur „Helligkeit am Bildschirm runterdrehen“, üblicherweise. Das können Geräte hardwaremäßig von sich aus umschalten, für alle Domains.

VG --PerfektesChaos 13:22, 16. Jun. 2020 (CEST)

Die App ändert die Farben von Links nicht, wobei dunkelblau auf dunkelgrauem Grund schwer lesbar ist. --FriedhelmW (Diskussion) 13:38, 16. Jun. 2020 (CEST)

Als erfahrener Webentwickler solltest du aber wissen, dass es dazu mehrere Windows-Schemata gibt, welche die Seiten austomatisch invertieren und umstellen, inklusive Programmen, die die Farbrotation können, damit selbige wieder stimmen, z.B. für Bilder. Das könntest du den Kunden ja empfehlen, falls sie es nicht schon wissen. 80.138.170.193 04:07, 29. Jul. 2020 (CEST)

Non-existing page: Check for missing closing bracket

Problem: Sending a Wikipedia Link via chat (e.g. WhatsApp) leads to broken links if the link contains a closing bracket at the end because it is difficult for the chat app to decide if a closing bracket at the end is part of the link or should be text only.

Example: From the Wikipedia Link: https://de.m.wikipedia.org/wiki/Edit_(Zeitschrift) e.g. WhatsApp hyperlinks only: (missing trailing bracket) https://de.m.wikipedia.org/wiki/Edit_(Zeitschrift

Proposal: Instead of just showing "this page does not exist" (German: "Diese Seite existiert nicht") at least the existing page with the closing bracket should be proposed to the user as top result. An automatic forward to the existing page could also be considered, e.g. depending on the number of existing Wikipedia articles with only an opening bracket (but no closing bracket).

BTW: The existing workaround to use the proposed search for the remaining information in other articles (German according to the example from above: "Suche nach „Edit (Zeitschrift“ in anderen Artikeln.") is IMO one click/touch too much and not intuitive enough to be sufficient. (nicht signierter Beitrag von 89.14.58.163 (Diskussion) 11:37, 7. Dez. 2020 (CET))

Thank you for this proposal.

You may bypass the problem by appending an underscore _ to the URL. That will be ignored by wiki, and WhatsApp will not cut the bracket which is taken for interpunction rather than part of URL. Just try: https://de.m.wikipedia.org/wiki/Edit_(Zeitschrift)_

The same goes for various interpunction characters, like dot which terminates an URL and would be swallowed on text systems. We know about such problems.

I am afraid the global software developers will not consider to guess other URL than requested. At least this is nothing which could be solved at German Wikipedia.

Anyway, I will start a local process and ask to offer a forwarding link to a page terminated by bracket or dot if that one would exist. There was already an approach on our test wiki:

• https://de.wikipedia.beta.wmflabs.org/wiki/Berlin_(Schiff
• https://de.wikipedia.beta.wmflabs.org/wiki/Artikelname_endend_mit_Punkt

The general offer to search in other articles will not be suppressed since the global software is not smart enough to read from crystal bowl what someone is really looking for. It needs to be present as fallback always.

Greetings --PerfektesChaos 15:31, 7. Dez. 2020 (CET)

Meanwhile productive. HNY --PerfektesChaos 17:46, 30. Dez. 2020 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:46, 30. Dez. 2020 (CET)

Einbindung von Bildern mit Mindestmaß in em

Wäre es umsetzbar, bei der Einbindung von Bildern ein Mindestmaß an Breite in em anzugeben? Dies ermöglichte eine saubere Darstellung unabgängig von den, bzw. angepasst an die Browsereinstellungen des Nutzers. Vermieden wird etwa das Abschneiden von Wörtern in der Bildunterschrift. --Diwas (Diskussion) 05:05, 18. Okt. 2020 (CEST)

Zwei Teile:

1. em – Nein, der Server kann Bilder immer nur in Pixeln px bereitstellen.
   • Die Umrechnung, wie viele em wie viele px bedeuten würden, hängt von den Schriftarteinstellungen jedes einzelnen Lesers ab; da kann jeder x-beliebige Wert herauskommen, wenn jemand schlechte Augen hat oder auf seinem Smartphone irgendwas eingedreht hätte.
   • Für jede Pixelbreite generiert der Server ein umgerechnetes Bild und merkt es sich im Cache. Weil das Bild in verschiedenen Seiten in verschiedenen Wikis mit einer explizit angegebenen Bildbreite eingebunden ist, kommen genau diese Werte zustande. Außerdem je nach Einstellungen angemeldeter Benutzer für Miniaturbilder oder auch als IP ein kleines Sortiment ganz bestimmter Bildbreiten, die immer wieder nachgefragt werden.
   • Eine Orientierung an em würde zu stufenlos sehr vielen abgeforderten Bildbreiten führen, die sich nicht mehr cachen lassen und für jede Seitendarstellung immer komplett neu generiert werden müssten.
2. Mindestmaß an Breite – Im Prinzip ja.
   • Die vorhandene Möglichkeit, gleichzeitig thumbnail und px anzugeben, legt explizit auf die Pixel fest, und das seit anderthalb Jahrzehnten; das kann aus Kompatibilitätsgründen nicht verändert werden.
   • Es bedürfte also eines neuen Parameters min-size bzw. nur noch min-width und dieser wäre mit dem von der Benutzereinstellung bedingten Breitenwert abzugleichen.

VG --PerfektesChaos 14:27, 18. Okt. 2020 (CEST)

Danke. Ein Mindestmaß in px könnte vielleicht in manchen Fällen etwas hilfreich sein, aber ob das den Aufwand lohnt? Dann ist es eben so, dass Benutzer die sehr kleine Bildbreiten einstellen, ab und zu ein abgeschnittenes Wort oder vielzeilige Bildunterschriften inkauf nehmen müssen. Benutzer mit groß eingestellter Schrift, müssen sich halt anmelden und die Bildgröße entsprechend anpassen, wenn sie so etwas vermeinden möchten. Oder den Browserzoom benutzen statt der Schriftgröße. Aber ein neuer Parameter min-width vermiede gegenüber dem Parameter hochkantimmerhin übergroße Bilder bei der Kombination mit großer Standardbildgröße in den Benutzeinstellungen. Das wird von hier wohl kaum auf die Agenda der Entwickler kommen. --Diwas (Diskussion) 21:53, 18. Okt. 2020 (CEST)

Ein- und Austräge bei einer Kategorie gebündelt auf einer Seite anzeigen lassen

Hallo, mittlerweile werden Ein- und Austräge bei einer Kategorie so gespeichert, dass man sich diese in der Beobachtungsliste anzeigen lassen kann. Ich vermisse eine Funktion je Kategorie, mit der ich mir gezielt alle Ein- und Austräge kompakt anzeigen lassen kann. Auf Kategorie-Seiten könnte dafür im Menü Werkzeuge ein Knopf Ein- und Austräge oder so stehen. --Zulu55 (Diskussion) 09:53, 26. Okt. 2020 (CET)

Hallo @Zulu55: Hatte Deine Frage noch im Hinterkopf und zufällig diesen alten Stammtischbericht in den Fingern. Dort geht es um Kategorie-Beobachtung. Viell. hilft Dir das ein Stück weiter. Gruß --DB111 (Diskussion) 00:40, 9. Nov. 2020 (CET)

Links in Benachrichtigungen zeigen nicht zum Ziel

Bei einer Benachrichtigung (bitte beachten: Link soll(te) auf eigene Benachrichtigungsseite führen, die auch leer sein kann) wird jeweils ein Link eingefügt, wo sich das Gemeldete befindet. Wird nun jener Abschnitt, in dem sich das Gemeldete befindet, archiviert (wie dies z.B. in WP:VM täglich mehrfach passiert), so führt der Link, der entsteht, wenn man einen anderen Benutzer erwähnt, dann zwar schon auf eine existierenden Seite - dort ist aber nichts davon zu finden - da eben jener Abschnitt schon archiviert wurde. Was dann zusätzlich noch ärgerlich ist: die Benachrichtigungen werden zwar unter dem Datum geführt, aber nur mit relativem Zeitstempel versehen, der nicht genauer als in Stunden auflöst - aber auch nur am laufenden Tag; später nur noch in Tagen, Wochen, Monaten, Jahren - ohne Uhrzeit, so dass daraus nicht mehr eruiert werden kann, in welcher Bearbeitung (und somit in welchem Zusammenhang) das war. Hätten diese Datum und Uhrzeit, so könnte zumindest in der History jener Zeitpunkt herausgefunden werden. Fazit: bei sämtlichen Arten von Meldungen sollte IMMER auch der Diff-Link enthalten sein, mit dem der betroffene Textabschnitt erstellt worden war (wie das auch bei den meisten Benachrichtigungstypen der Fall ist - z.B. wenn jemand etwas auf der eigenen Disk.-Seite anfügt - aber eben nicht bei allen). --ProloSozz (Diskussion) 09:27, 23. Dez. 2020 (CET)

Mir wird folgender Link aufs Diff serviert: Änderungen ansehen --Diwas (Diskussion) 01:02, 26. Dez. 2020 (CET)

Personen, die im Internet Kommentare etc. abgeben, werden als reale Menschen erkennbar

Ziele:

Reale Menschen im Internet erkennbar machen um sie von Robotern, gefälschten oder anonymen Personen zu unterscheiden.
Damit könnten Bewertungen, Kommentare etc. dieser Menschen leichter von Fälschungen oder automatisierten Texten unterschieden werden.
Die Aussage-Qualität von Bewertungen steigt. Manipulation wird schwerer.

Weg:

Jede interessierte Person registriert sich bei einer Datenbank, z.B. „WikiHumans“ und hinterlegt diese Daten:

• Adresse: Name, Land, PLZ, Straße, Hausnummer. Diese Daten werden angezeigt, wenn jemand die Person verifizieren möchte.
• E-Mail-Adresse, die für Bewertungen etc. genutzt wird. Diese wird nicht angezeigt bzw. veröffentlicht.
• Anschließend erhält die Person ein eindeutiges IdentifikationsMerkmal, z. B.: Max Mustermann aus München erhält „DE81547MaxMustermann“ (Land, PLZ, Name).
  

Das IdentifikationsMerkmal wird bei Bewertungen etc. als „Name“ genutzt.
Man kann das IdentifikationsMerkmal dann bei WikiHumans eingeben und erhält zusätzlich den Ort (also München, Straße, Hausnummer).
Damit können Menschen von Menschen verifiziert werden (und nicht nur von Facebook ...) und man kann sogar persönlich Kontakt aufnehmen.

Firmen (Gaststätten etc.), die eine Mail von DE81547MaxMustermann mit einer Bewertung erhalten, können an WikiHumans eine Kurz-Mail senden nur mit Betreff:
„DE81547MaxMustermann, max.mustermann@e--mail.de“

• Dann erhalten sie als Antwort: OK oder Nicht OK, also Mail-Absender ist so registriert oder nicht.
• Nur bei OK veröffentlicht die Gaststätte die Bewertung mit dem IdentifikationsMerkmal DE81547MaxMustermann.

Details:

Auch „normale“ Menschen können Bewertungen real existierender Menschen erkennen und nicht nur Daten-Sammler wie Facebook, Google usw.
Anmeldung und Verifikation:

• Jeder kann sich bei WikiHumans registrieren, hinterlegt die obigen Daten und erhält das IdentifikationsMerkmal.
• Jedoch erst wenn eine bereits bei WikiHumans verifizierte Person die neue Person bestätigt hat, werden die Daten öffentlich zugänglich = Verified Person
• Als Adresse kann man zuhause nehmen, aber auch z.B. den eigenen Laden oder sein Büro (Bäcker, Steuerberater ...). Es muß ein Ort sein, wo man persönlich getroffen werden kann und wo Brief-Post für die Person ankommt.
  

Gefälschte Bewertungen, Hass-Kommentare usw. von nicht verifizierten Personen könnten ignoriert bzw. vom Leser entsprechend eingeordnet werden.
Fälschung von IdentifikationsMerkmalen:

• Veröffentlicht z.B. ein Hotel eine Bewertung mit dem IdentifikationsMerkmal einer anderen Person, riskiert das Hotel, juristisch belangt zu werden.
• Und es werden sich Menschen mit Kommentaren melden, die mitteilen, dass dieses Hotel gefälschte Bewertungen veröffentlicht.
  

Datenschutz:

• Eine automatisierte, massenhafte Daten-Abfrage ist nicht möglich (Zeit-Verzögerungen ...)
• E-Mail-Adressen werden nicht veröffentlicht, sondern nur bestätigt, wenn Gaststätten etc. sie an WikiHumans zum Verifizieren senden.
• Man könnte (später) die Abfrage auf nur bei WikiHumans registrierte Personen und Firmen begrenzen.
  

Aufwand und Kosten:

• Die Datenmenge je Person ist extrem klein und damit wahrscheinlich auch der Programmier- bzw. Server-Aufwand.
• Den Nutzen haben Firmen, die nachprüfbare Bewertungen veröffentlichen, also höhere Qualität. Hier könnte man z.B. 0,01 €/Abfrage verlangen.
  

Warum bei Wikimedia: Weil Wikimedia unabhängig von Regierungen und Firmen (Facebook, Google ...), sowie global anerkannt ist.
Weitere Anwendungs-Möglichkeiten mit dem IdentifikationsMerkmal gibt es sicherlich.
Bei obigem Thema haben sicherlich schon viele über eine derartige Vorgehensweisen nachgedacht.
Bisher habe ich hier jedoch noch keinen Ansprechpartner und wäre an Kontakten sehr interessiert.
Vielleicht ist das Thema gut bei Wikimedia / Projekte einzuordnen.

(nicht signierter Beitrag von NorbertStralka (Diskussion | Beiträge) 30. Nov. 2020 (CET))

Ohne signatur gepostet und automatisch nachgetragene Signatur entfernt

Dies mag bei "institutionellen" Personen und schon bekannten Personen des öffentlichen Lebens eine Idee sein - aber eine ganz schlechte. In der vorgeschlagenen Form läuft das aber auf den gläsernen WP-User hinaus - und das widerspricht den Grundzügen der WP! Gegen Mensch-/Maschine-Prüfung ist grundsätzlich nichts einzuwenden; dass dazu aber die Adresse angegeben werden soll, öffnet Stalking Tür und Tor (und das kann dann wirklich kriminell und tödlich werden). Schon allein Name und Wohnort (auch nur als PLZ) immer öffentlich einsehbar zu machen, geht zu weit. Derzeit darf im Normalfall ja nicht mal die IP-Adresse eines angemeldeten Benutzers herausgefunden werden (das dürfen nur WP:CU - aus guten Gründen) ... und wenn das dann noch von jemandem gepostet wird, der nicht nur keine Signatur einträgt, sondern die automatisch generierte noch entfernt, stellen sich viele Fragezeichen ... (nicht signierter Beitrag von ProloSozz (Diskussion | Beiträge) 10:02, 23. Dez. 2020 (CET))

Danke dem namenlosen Schreiber (oben) für das klare Statement und die Hinweise zum Datenschutz. Meine Idee mag schlecht sein, allerdings habe ich mich bisher kaum mit Diskussions-Partnern darüber austauschen können und bessere Ideen gesehen. Die Gefahr vor kriminellen Handlungen (Stalking etc.) sehe ich auch. Ich habe jedoch mehr Angst vor kriminellen, anonymen Menschen (Hass- & Falschmeldungen) als vor realen Menschen, die sich mir persönlich gegenüber stellen müssen. PS.: Bei der Signatur (vermute sie meinen mich) habe ich wohl etwas falsch gemacht – sorry. Aber mein Name steht ja da. --NorbertStralka (Diskussion) 09:36, 7. Jan. 2021 (CET)

Ja, NorbertStralka, weil die Signatur zunächst durch einen Bot, dann durch einen User nachgetragen wurde. Siehe Hilfe:Signatur. Gruß, --Wi-luc-ky (Diskussion) 19:14, 7. Jan. 2021 (CET)