Wikipedia:Verbesserungsvorschläge/Archiv/2020/Mai

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/Archiv/2020/Mai#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Tabelle: fixierte Kopfzeile

Bei langen Listen in Tabellenform fehlt eine Darstellungshilfe, da dort viele Einträge oft nicht mehr dem Kopfbezeicher zuzuordnen sind, insb. bei Zahlenwerten. Häufig findet mal Listen, die außerordentlich lang und umfangreich sind. Günstig wäre sie mit CSS-style="overflow ...in einer überschaubaren, scrollbaren Tabelle anzubieten. Versuche habe ich bereits durchgeführt (siehe Scrollbare Tabellen, doch WP funkt so sehr dazwischen, dass mir bisher keine 100 % funktionierende Lösung eingefallen ist.
Anmerkungen: Mit sortierbaren Tabellen ist es simpel, da WP die Tabelle ordentlich mit <thead> ... <th> anlegt.

Als kleine Lösung bietet sich position:sticky; an, die Tabellenkopfzeilen werden beim Scrollen über die Tabelle an oberen Fensterrand fixiert. Beim Verlassen der Tabelle oberhalb oder unterhalb verschwindet der Kopf automatisch.

Beispiel:{| class="wikitable sortable kopf" Die zentrale css-Datei (elements.css ?) um die class="kopf" mit 2 Zeilen ergänzen (statt ‚kopf‘ wäre anderer Klassenbezeichner denkbar:

table.kopf thead th {position:-webkit-sticky; position:sticky; top:0;}/* -webkit-sticky für Safari */

Bei WP-Tabellen ohne Sortierung gibt es<thead>nicht, die Kopfzeile wird mit<tbody> ... <th>realisiert, was nicht ganz der Idee des Erfinders entspricht, aber funktioniert.. --Klaus-Peter (ex und hopp) 08:09, 3. Mai 2020 (CEST)

Das wird derzeit nicht prioritär behandelt: phab:T42763. Es ist besser, hier eine softwareseitige Lösung anzustreben, als Insellösungen zu entwickeln, die dann später für Probleme sorgen. -- hgzh 12:07, 3. Mai 2020 (CEST)

So wie ich es verstanden habe, beschäftigt sich phab:T42763 mit der overflow-Variante, die zwar deutlich eleganter ist, aber da stellt sich WP selbst ein Bein mit der Sortierfunktion bzw. JS, sowie einiger kleinerer "Vereinfachungen" bei der Anlage/Umsetzung von Tabellen (thead fehlt mitunter). Das wäre ein enormer Aufriss, so etwas softwareseitig zu realisieren. mein Vorschlag ist etliche Nummern kleiner, denn dazu sind in der css-Datei NUR 1 Anweisung nachzutragen, die sonst keinerlei Auswirkungen auf irgendwelche andern css-Einträge bzw. andere Funktionen haben. OK, die globale css-Datei schwillt um ca. 150 bytes an, wird also den Server enorm mehr belasten. Das es perfekt auf der Insel funktioniert, lässt sich fix beweisen:

1. Eintrag oben genannter Zeilen in die global.css
2. Anlage einer längeren BNR-Tabelle mit class="wikitable sortable kopf" -- class=kopf wurde ja in css angelegt
3. Testen und sich wundern, wie simpel es ist -- und alles was die Tabelle kann, geht auch bei fixierter Kopfzeile! Notfalls zu testen bei Benutzer:Gadacz/Regierungsformen_in_Europa#Liste_europäischer_Staaten

Sollte dieser ‚kopf‘-Eintrag zufällig auf einen historischen Browser stoßen, passsiert überhaupt nichts, da die ollen Klamotten sticky nicht kennen und somit schnöde ignorieren (da ist css sehr eigen). Vermutlich wird es auch erst mal nicht auf Mobilgeräten funktionieren, da die sicherlich andere, angepasste css-Dateien haben. Auch damit kann man leben.

Das so etwas über den großen diplomatischen Weg laufen muss, ist schon ein Armutszeugnis oder Hinweis, dass die Entscheidungsträger wenig Ahnung von css haben.--Klaus-Peter (ex und hopp) 18:57, 9. Mai 2020 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: kein echtes Interesse erkennbar--Klaus-Peter (auf und davon) 07:04, 15. Mai 2020 (CEST)

Infokasten bei Suizid-Artikeln

Hallo, im Zuge der SG?-Diskussion um Evelyn McHale (siehe SG?:Evelyn McHale) ist eine leichte Diskussion entstanden, ob Suizid-Artikel nun bei SG? erscheinen sollten oder nicht, da das Thema ja auch medial mittlerweile sehr sensibel und vorsichtig angegangen wird, um keine Glorifizierung von Suiziden zu schaffen und damit für Nachahmungen zu sorgen. Der verlinkte Artikel ist ein Paradebeispiel hierfür („Most Beautiful Suicide“, „Picture of the Week“ etc). Mir kam daher die Idee, dass man solche Artikel, ähnlich wie Medienartikel, vielleicht mit einem gesonderten Suizid-Infokasten versehen könnte, in dem Hilfe angeboten wird. Etwas klares, unmissverständliches und schnell sichtbares wie die „Laufendes Ereignis“-Box, nur eben mit dem Hinweis dass der Artikel nicht zur Nachahmung aufruft und man sich über diverse (ebenfalls angebildete) Nummern schnell Hilfe holen kann. Eure Meinungen? --wuppertaler _Briefkasten um 12:06, 18. Mai 2020 (CEST) PS: Sollte der Vorschlag woanders besser aufgehoben sein, bitte ich um einen kurzen Hinweis und würde es dann dort erneut ausführen.--wuppertaler _Briefkasten um 12:07, 18. Mai 2020 (CEST)

@Der-wuppertaler: Es gibt diesen Kasten schon, der in vielen Artikeln zum Thema genutzt wird; vgl. Suizid, Suizid durch Sprung aus der Höhe, etc. Ob er auch im McHale-Artikel platziert werden sollte bzw. muss, kann man ggf. im Einzelfall besser beim Artikel diskutieren. Gruß, --NiTen ^(Discworld) 12:15, 18. Mai 2020 (CEST)

War mir nicht bewusst, danke. Hatte ein paar Artikel aufgerufen und dort keinen derartigen Kasten gesehen. --wuppertaler _Briefkasten um 12:17, 18. Mai 2020 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --wuppertaler _Briefkasten um 12:17, 18. Mai 2020 (CEST)

Dynamische Bilder bzw. Grafiken und statische BU

In WP ist es ja schön, dass Bilder und Grafiken regelmäßig aktualisiert werden. Das führt aber leider auch regelmäßig dazu, dass zwischen Bild und Bildunterschied eine Diskrepanz entsteht. Im konkretes Beispiel COVID-19-Pandemie in Deutschland, erste Grafik, steht in der Grafik das Datum des Datenstands, ind der Bildunterschrift auch. Die Grafik wird etwa alle 2 Tage aktualisiert, die Bildunterschrift alle 5 Tage. Die meiste Zeit ist die BU also falsch. Das Problem kann aber auch bei Fotos oder anderen Dateien auftauchen. Technische Lösungen sind denkbar, wie z.B. ein Dynamisches Datum im Fall der COVID-Grafik, oder zumindest ein Hinweis, dass die Grafik ein Update hatte, daher die BU zu ggf zu prüfen ist. Aber vielleicht sind diese kleinen Probleme ja auch nicht so wichtig und machen eher den Charme der WP aus. Ich habe aber nichts zum Thema gefunden, und wollte es daher hier vorstellen. --Falky 05:36, 12. Mai 2020 (CEST)

Covid-19 ist ja fast vorbei -- oder? Dennoch eine interessante Frage! Ach Ansicht des Experten bin ich zwar nur ein ahnungsloser Stümper, aber ich sehe, was ich sehe

1. in File:COVID-19 outbreak Germany per capita cases map.svg gibt es ja Dateiinformationen incl. Datum und Beschreibung, die man auswerten könnte.
2. Auch aus der Bilddatei (SVG) kann man das Modifikationsdatum auslesen.
3. Denkbar wäre eine kleine Vorlage, die den Bildaufruf komplett automatisiert und dabei Datum und Beschreibung übernimmt. Ich werde mich dabei aber heraushalten, denn das gäbe Ärger mit der obersten Vorlagen-/Modulverwaltung.
4. Es gibt ja bereits ein Modul:FileMedia, das allerlei Informationen zu Dateien ermittelt. Möglicherweise kann der Chefautor darüber Auskunft geben, ob Interesse und Möglichkeit besteht, das Modul entsprechend zu erweitern. Ich wünsche viel Erfolg!

• Echte Zukunftsmusik wäre eine vollautomatische Abfrage nach der aktuellsten Datei beim Seitenaufruf und automatischer Generierung der Bildeinträge. Die Frage ist eher, wie viele Pandemien wir uns noch leisten wollen, das der Aufriss lohnt.--Klaus-Peter (auf und davon) 07:54, 15. Mai 2020 (CEST)

• Eine globale Softwarefunktion wird sowas sicher nicht.
• Es ist ein Einzelfall, jetzt mal hier mit diesem einzelnen Artikel aufgetreten. Ich wüsste keinen Präzedenzfall mit Datei-Metadaten in zweieinhalb Millionen Artikeln; gerade bei Artikeln eher weniger.
• Richtig ist, wie schon angedeutet, dass man in diesem einzelnen Artikel irgendwelche Abfragen einbauen könnte, wodurch nur für angemeldete erfahrenene Autoren irgendein Wartungshinweis betreffend Aktualisierung sichtbar gemacht würde.
• Ähnliche Analysen sind mannigfach hinter Seiten programmiert worden, die auch in Abhängigkeit vom heutigen Datum die Existenz irgendwelcher anderer Seiten oder Bearbeitungsstände überprüfen und ggf. Wartungshinweise geben; etwa im Zusammenhang mit dem „Artikel des Tages“, der auf der WP:Hauptseite eingeblendet wird und im Turnus einer Woche im Voraus bereitgestellt und mehr oder weniger täglich durch den Nachfolger abgelöst wird.
• Voraussetzung ist in der beschriebenen Situation, dass es ein einheitliches Kriterium geben würde, und das ist beim global chaotisch angelegten und benannten Seiten- und Dateisystem nicht verallgemeinerbar, sondern immer nur auf dieses eine Bild zu beziehen.
• FileMedia kennt nur Größe und Seitenanzahl eines Bildes/Dokuments, aber keinen Hochladezeitpunkt und würde inhaltlich maximal jedoch ebenfalls nicht den Zeitstempel einer Digitalkamera kennen.
• SVG kann theoretisch ausgelesen werden, jedoch nur mittels JavaScript und dieses Werkzeug müsste bei allen Lesern installiert werden und würde zunächst einmal auf jeder Seite wirksam werden müssen, um dann festzustellen, dass hier nichts zu tun ist. Wir haben zehn Millionen Seiten, dazu -zig Millionen weitere zu bildende URL weiterer Seiten, und auf allen müsste erstmal ein Gadget gestartet werden, um mit einer Chance von 1:100000000 festzustellen, dass nachträglich eine Bildunterschrift zu aktualisieren und für erfahrene Benutzer ggf. ein Hinweis einzublenden sei.
• Voraussetzung wäre, dass alle beteiligten Grafiken standardisiert den aktuellen Text, etwa ein Tagesdatum, an einer immer gleichen Stelle wiederfindbar enthalten, und alle fraglichen Textseiten einen markierten Bereich, in dem der momentane statische Standardtext nachträglich von einem anderen überschrieben werden würde.
• Im konkreten Einzelfall wäre es eine bessere Lösung, dass die täglich mehrfach daran rumeditierenden Menschen und Sichter und Beobachter regelmäßig einen Routineblick auf die fragliche Stelle werfen und betreuende Routiniers das bei passender Gelegenheit aktualisieren.
• Oder, generelle Strategie: Das SVG stellt das Datum, das es ja kennt, gut sichtbar in der Grafik dar, wie bereits jetzt, und die Bildlegende lässt das genaue Datum einfach weg und erwähnt nur grob ein „Frühjahr“.
• WP:Bots würde man bei einem großflächigen und langfristigen Problem beauftragen, irgendeinen beliebigen Sachverhalt im Internet festzustellen und unseren Artikel bedarfsweise automatisch zu aktualisieren. Das lohnt hier nicht.

VG --PerfektesChaos 12:21, 15. Mai 2020 (CEST)