Wikipedia:Verbesserungsvorschläge/Archiv/2022/Februar

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Timer für SLA nach Verschiebung

Wenn ein Artikel auf ein neues Lemma verschoben wird, kann das alte oft gelöscht werden (insbesondere wenn es ein unnötiges Klammerlemma war). Das Problem daran: Die Google-Suche passt das neue Ziel nicht sofort an. Bis das erfolgt ist, landen die Leser, die auf Google nach dem Artikel suchen, im Nirvana des gelöschten Artikels. Das spricht dafür, dass man nach der Verschiebung und dem Umbiegen der Links z. B. zwei Tage mit dem SLA wartet. Aber a) wahrscheinlich findet sich ein anderer eifriger User, der den SLA stellt und b) wenn nicht, wird der Rest gern vergessen und bis St. Nimmerlein übersehen. Das würde dafür sprechen, einen Timer für einen SLA in den Rest zu setzen - nach Ablauf von z. B. 48 Stunden wird daraus ein SLA, wenn niemand Einspruch erhebt. Ließe sich das technisch umsetzen? --KnightMove (Diskussion) 13:32, 1. Feb. 2022 (CET)

Das liegt grundsätzlich im Rahmen unserer hiesigen Möglichkeiten.
  • Vorlage:Zukunft macht sowas Ähnliches in regulären Artikeln und löst eine Kategorisierung aus.
Eine Vorlage:Zeitgesteuerte Aktion wäre vorstellbar.
  • Realisierbar ist das mit sehr flexibler und trotzdem halbwegs einfacher Bedienung.
  • H:VP #time kennt Ausdrücke wie 3 days oder 1 week usw.
  • Das Modul DateTime kann auch komplexe Vergleiche ausführen (Beispiele zur Zukunft).
  • Referenzzeitpunkt, sofern nicht anders angegeben, könnte der Zeitpunkt der letzten Abspeicherung sein, und von da an zwei Tage wie vorgeschlagen.
  • ~~~~~ ist bei meiner Antwort 15:31, 1. Feb. 2022 (CET) und wird von DateTime verstanden: 2022-02-01T15:31:00+01:00
  • {{REVISIONTIMESTAMP}} dieser Seite ist 20220522043932 und DateTime versteht das: 2022-05-22T06:39:32+02:00 (geht allerdings von Londoner Tickets aus).
  • Die Aktion kann ein SLA sein, aber jeder andere Quelltext auch.
Der wirksame Auslösezeitpunkt kann Wochen und Jahre in der Zukunft liegen.
  • Die Überprüfung wird erst wirksam, wenn jemand die WL-Seite bearbeitet, oder der Server sie vergessen hatte und jemand die Verlinkung nutzen will und der Server sie neu für den Cache generiert. Was bei Weiterleitungsseiten nicht kalkulierbar ist, insbesondere weil ja alle unsere internen Verlinkungen darauf entfernt sein sollen,.
  • Vorlage:Alter in Jahren und Tagen hat das gleiche Problem. Im Sportbereich wird sowas massiv eingesetzt, und dort beschwert man sich, dass der athletische Geburtstag um Monate verpasst würde.
  • Oder die Frage, wie viele Tage die Regierung von Lampukistan bereits im Amt wäre.
  • Es gibt Überlegungen, für wenige 100 bestimmter Einbindungen eine Kategorie einzuführen, die ein Bot regelmäßig zur Aktualisierung auslöst; aber die Bot-Betreiber sind dieser Idee gegenüber sehr zurückhaltend.
Ich kann mir das auf die ToDo-Liste setzen, aber da stehen Hunderte Geschichten drauf.
Generell ist zu befürchten, dass du der einzige bist, der diese Vorgehensweise kennt und anwendet.
  • Du müsstest für was auch immer für eine Lösung erstmal eine riesige Werbekampagne machen, dass Tausende andere bei sowas Tätigen es zukünftig genauso machen sollen.
  • Werden die erfahrungsgemäß wenig Stimmung zu haben.
  • Es hat ein Dutzend Jahre gebraucht, um zu verklickern, dass das von 2006 bis 2008 gültige prettytable jetzt wikitable heißt.
VG --PerfektesChaos 15:31, 1. Feb. 2022 (CET)
Zum möglichen botgestützten Refresh der Seiten: Anders als bei Vorlage:Alter in Jahren und Tagen u.ä. müsste die Einbindung von Vorlage:Zeitgesteuerte Aktion ja nicht täglich, sondern nur einmalig aktualisiert werden. Ein Bot müsste also nur (1) bei Neueinbindungen der Vorlage das gewünschte Auslösedatum erfassen und speichern, und (2) am gespeicherten Tag einmalig einen Refresh/Purge auslösen, statt hunderte pro Tag. Wenn jemand die Vorlage bastelt, bastele ich den Bot dazu. Aber wirklich nur zum Refresh: An einen Bot, der selbst zeitgesteuert einen SLA setzt, traue ich mich nicht ran: Zu viel Fehler- und Missbrauchspotenzial... --Tkarcher (Diskussion) 16:37, 1. Feb. 2022 (CET)
Aber wie schon oben gesagt müsste hier erst einmal eine Mehrheit für ein solches Vorgehen gewonnen werden. Und nach dem Meinungsbild über dieses Problem sehe ich es so, dass solche Links durchaus gleich gelöscht werden können. Es gibt viele unterschiedliche Situationen, in manchen wäre eine sofortige Löschung sogar besser. Und ein Google-Sucher landet ja nicht im Nirgendwo, sondern ihm wird angezeigt, dass die Seite verschoben wurde und auch, wohin. -- Jesi (Diskussion) 17:03, 1. Feb. 2022 (CET)
@Tkarcher:
Das macht keiner unserer Botbetreiber.
Weder wollen die sich mit irgendeiner einzelnen Vorlage befassen, noch aus einer bunten Vielfalt von Datumsformatvarianten den entscheidenden Zeitpunkt herausfiltrieren, zu dem sie purgen sollen, und erst recht nicht wollen sie sich um konkreten Einzeldaten kümmern und Terminlisten anlegen.
Was vorstellbar und über Jahre hinweg durch unterschiedliche Bots handhabbar:
  • Kategorie:Wikipedia:Aktualisierung/täglich – kommt täglich um drei Uhr morgens
  • Kategorie:Wikipedia:Aktualisierung/wöchentlich – kommt jeden Freitag ab 02:34 Uhr morgens
  • Kategorie:Wikipedia:Aktualisierung/monatlich – kommt jeden Monatsersten ab 04:05 Uhr morgens
  • Kategorie:Wikipedia:Aktualisierung/vierteljährlich – kommt jeden Quartalsersten ab 02:13 Uhr morgens
  • Kategorie:Wikipedia:Aktualisierung/jährlich – kommt jeden Ersten Januar ab 03:45 Uhr morgens
Welche Vorlage was wann warum auslöst ist völlig uninteressant und viel zu kompliziert zu pflegen. Alles was in die Kategorie eingetragen ist wird gepurged, Ende.
  • „müsste also nur“ isnix.
  • Die Aufgabenstellung muss so trivial sein, dass sie über Jahrzehnte von unterschiedlichen Botbetreibern (auch global) simpel ausgeführt werden kann. Es könnte ja auch eine Konfiguration für einen 100-Wikis-Bot geben, mit: catDaily=Wikipedia:Aktualisierung/täglich
  • In diesem Sinn kannst du gern tätig werden.
  • Wir haben nämlich einen konkreten Fall: Wir könnten in allen TemplateData-Vorlagen, die ein Abrufdatum erwarten, per autovalue das heutige Datum sauber eintragen, falls nicht anders spezifiziert. Das scheitert bisher an der Einbindung einer tagesaktuellen Doku-Version.
VG --PerfektesChaos 17:16, 1. Feb. 2022 (CET)
(BK) Wenn ein Artikel nach Jahren verschoben wird, schadet es jedenfalls absolut nichts, wenn der Redirect noch zwei Tage stehen bleibt. Der Vorteil der sofortigen Löschung ist genau der, dass nicht darauf vergessen wird. Wenn wirklich einmal das alte Lemma so schnell wie möglich weg soll (ehrenrührig, falsch geschrieben...), kann man ja immer noch völlig legitim den normalen SLA stellen. Es tritt kein Widerspruch ein. --KnightMove (Diskussion) 17:18, 1. Feb. 2022 (CET)

Ref-Auswahl im VE

In der Kategorie der Ref-Fehler taucht ein Fehler immer häufiger auf: Referenzfehler: Ungültiges <ref>-Tag. Der Name „:1“ wurde mehrere Male mit einem unterschiedlichen Inhalt definiert. Der VE legt korrekt an <ref name=":1">Text</ref>. Wenn man die Referenz erneut angeben will, wird exakt der gleiche String erneut angelegt, was zu dem Ref-Fehler führt. Der Grund ist vermutlich der Bedienfehler des Benutzers, der bei Wiederverwendung den Reiter Weiterverwenden benutzen muss, dann wird korrekt anstatt des gesamten Strings nur <ref name=":1" />angelegt.

Anschauungsbeispiel: So sieht das entsprechende Menü im VE aus

Verbesserungsvorschlag: Wenn die Referenz mit einer vom VE gewählten Nummer (hier ":1") ohne Benutzung von Weiterverwenden erneut angelegt werden soll, kommt eine Warnung, sinngemäß "Gibt es schon, sollen wir wirklich?".
--Pankoken (Diskussion) 16:08, 6. Feb. 2022 (CET)

Möchte auch mal loben!

Seit einigen Wochen bietet mir beim Setzen von internen links ein Vorschaufenster die möglichen Verlinkungen an. Das ist super toll und hilft nicht nur die passende Verlinkung zu finden sondern erspart mühsames Zwischensuchen nach Begriffsklärungsseiten und den entsprechenden Angeboten dort. Toll, was technisch alles geht! Danke an die Erfinder! VG--Goldmull (Diskussion) 12:27, 10. Feb. 2022 (CET)