Wikipedia Diskussion:Technik/Baustellen/prettytable und wikitable

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 3 Jahren von PerfektesChaos in Abschnitt 2021
Zur Navigation springen Zur Suche springen

2012

[Quelltext bearbeiten]

Wie oft wird prettytable überhaupt noch verwendet? Steak 12:53, 25. Aug. 2012 (CEST)Beantworten

Spezial:Suche/prettytable findet zurzeit 2277 Artikel, dazu kommen etliche Vorlagen und auch Spezialseiten wie beispielsweise Wikipedia:ISBN-Suche. --Entlinkt (Diskussion) 08:53, 1. Jun. 2013 (CEST)Beantworten

2013

[Quelltext bearbeiten]
Meilenstein/Schnappschuss Jahresende 2013:
  • 1644 im ANR
  • Benachrichtigt, auf dem Weg oder abgearbeitet: Fußball, Rassekatzen, Billard
  • Benachrichtigt, stöhnend: Radsport
  • Noch nicht angesprochen:
    • Schiffe (590 Artikel)
    • Eisenbahn (400–500 Artikel)
    • Straßenverkehr aller Art (≈400 Artikel)
--PerfektesChaos 14:46, 28. Dez. 2013 (CET)Beantworten

2014

[Quelltext bearbeiten]
Wie sehen die Zahlen aktuell aus? 129.13.72.198 13:19, 17. Mär. 2014 (CET)Beantworten
  1. Ja, ich habe auch schon mitbekommen, dass die Gesamtzahl in den letzten sieben Tagen um rund 500 gesunken war; zuletzt: 1050 Treffer.
    • Bei allen Mühen: Du musst dich hier nicht verausgaben, die Manx-Katze ginge demnächst von alleine in die Vorlage:Infobox Katzenrasse und die Vorlage:Infobox Schiff schluckt nach und nach deren prettytable; nur noch nicht gezielt.
    • Die Bahnstrecken haben kurioserweise keine geschlossene Infobox, sondern sind über 3.500–4.000 Einzeltabellen realisiert. Dafür stecken die Inhalte in Vorlage:BS-***** – Vorlage:BS hat 4000 Vorlageneinbindungen.
    • Mit Loks verhält es sich vermutlich ähnlich: Keine Infobox zu sehen.
    • Deshalb hatte ich die Bahner noch nicht angesprochen.
    • Die Radler hatten keine Kraft mehr in den Muskeln; beim sonstigen Straßenverkehr und Motorsport ist es unterschiedlich. Da kannst du dich gern schwerpunktmäßig noch austoben.
  2. Falls ihr gern mit Skripten arbeiten wollt, kann ich euch Wikipedia:Technik/Browser/Greasemonkey anbieten.
War nett, euch mal wieder zu sehen --PerfektesChaos 22:42, 18. Mär. 2014 (CET)Beantworten
Die Bahnstrecken und Loks hab ich zu nahezu 100% abgearbeitet, da musste man außer pretty -> wiki nichts ersetzen. Wie kommt da jetzt die Vorlage:BS ins Spiel? Im Vorlagennamensraum haben nur noch ein paar Infoboxen prettytable [1], jedoch nicht die Vorlage:BS-*. Der größte Posten sind die Schiffe und Schiffsklassen. Die könnte man aber mit Vorlage:Infobox Schiff/Farbzuordnungen per Bot umstellen, das geht relativ einfach [2]. 79.217.173.187 23:18, 18. Mär. 2014 (CET)Beantworten
  1. Die prettytable im Vorlagennamensraum hat sich Entlinkt vorgenommen. Die sind tückisch, da muss man anschließend auch Beispiele durchtesten; und diese Vorlagen sind teilweise so alt, dass sie ein Vollprogramm bekommen sollten. So mit /Doku-Auslagerung und allgemeiner Modernisierung und so.
  2. Was diese Eisenbahner so machen, kapiere ich auch nicht. Mir wäre das heikel; statt 4000 einzelner Tabellen hätte ich ja eine zentral anpassbare Vorlage:Infobox Bahnstrecke gebaut. Wenn sich da mal die Pixel/breite oder sonstwas ändern muss, braucht man einen gutgelaunten Botlauf.
  3. Die Schiffsleute haben ein allgemeines Artikelmodernisierungsprogramm. Die stellen ganz von alleine alte Artikel auf Infobox um; allerdings momentan nicht gezielt prettytable, sondern auch wikitable, so wie es grad kommt. Aber wenn das jetzt so hübsch überschaubar wird, dann spreche ich die demnächst mal an. Allgemein ist es günstiger, wenn das Portal-Fachleute machen, denn die machen dann gleich eine inhaltlich-formale Komplettsanierung, und stöhnen nicht über Beo-Flutung.
  4. Planziel wäre Ende 2014, und dann noch zwölf Monate Karenzzeit für Wiedergänger aus privaten Kopiervorlagen, und 2016 Entfernung aus dem Support.
Schönen Dank und schönen Abend --PerfektesChaos 23:54, 18. Mär. 2014 (CET)Beantworten

Es gibt ein Problem mit der Suchfunktion: Es werden bei weitem nicht alle Vorkommen von prettytable gefunden. Oben gibst du eine Anzahl von 1050 Treffern an, das passt zum Ergebnis der Volltextsuche. Dabei werden aber z. B. Saisonartikel wie Schachbundesliga 2013/14 oder auch Deutschland Tour 1999 überhaupt nicht aufgeführt. Die reale Anzahl von prettytable dürfte also geschätzt bei 10.000 liegen! 79.192.107.6 12:05, 20. Mär. 2014 (CET)Beantworten
  • Das ist bekannt.
    • Dem Fragesteller in der ersten Zeile deser Seite wude deshalb bewusst mit Hinweis auf die Spezalseite geantwortet.
  • Ich habe für mich WSTM geschaltet auf warnen wenn prettytable in class und damit auch hin und wieder bei zufälligen Edits aus anderen Gründen Seiten gefunden, die nicht in der Volltextsuche standen.
  • Woran es liegen mag, dass manche prettytable immer gefunden werden und manche nie, hat sich mir nicht erschlossen.
  • Für den Anfang sind wir vollauf damit beschäftigt, alle diejenigen Seiten zu aktualisieren, die in der Volltextsuche aufschlagen. Damit hätten wir noch für 2014 genug zu tun.
  • Anschließend lohnt es sich, die Dumps auszuwerten.
    • Das ist aber in der Abarbeitung und Erledigung sehr viel komplizierter. Man kann dann nur alle paar Wochen einen frischen Dump erstellen, und gucken, was in der Zwischenzeit erledigt wurde. Das Ergebnis der Volltextsuche hat man am nächsten Tag frisch.
    • Zwischendurch müsste man sich das Feld thematisch aufteilen, um nicht Doppelarbeit an schon abgearbeiteten Seiten zu haben, und man kann auch nicht alle drei Edits eine Trefferliste schrumpfen lassen. Eher einen bestimmten Bereich der Trefferliste gruppieren und reklamieren, dass man diesen Teilabschnitt im Lauf der nächsten Woche abarbeiten möchte; und löschen, wenn man glaubt, alle erwischt zu haben.
  • Erstmal die Lucene-Volltextsuche auf Null arbeiten.
  • Angemeldete Benutzer können als Beta-Tester die neue Suchmaschine Cirrus erproben.
    • Die findet aber standardmäßig wohl überhaupt keine Syntaxelemente mehr, sondern innerhalb des sichtbaren Textes (dafür auch das expandierte Resultat von Vorlagen).
    • Ob es eine Option gibt/geben wird, den Quelltext zu durchsuchen, und ob man da mehr Treffer hätte, weiß ich nicht. mw:Help:CirrusSearch schreibt da nix zu.
    • Vielleicht ist aber nur der Projekt-Index noch nicht oder nicht voll aufgebaut.
    • Angeblich solle dies ab März oder Mai auf dewiki standardmäßig eingeführt werden. Kann sein, dass danach die Volltextsuche nur noch 100 Seiten wie etwa diese hier finden wird.
    • Das ist einer der Gründe, warum ich das zurzeit nicht nach außen trage. Backups der Trefferliste halte ich auf der Festplatte.
  • Google usw. durchsuchen das HTML-Dokument; können dementsprechend keinen Wikitext finden.
  • Ärgerlich ist, wenn Schachbundesliga 2013/14 noch 2013 neu mit prettytable angelegt wird.
    • Hier ist das Flöhen von Formatvorlagen und Vorbildern, ggf. auch Direktansprache des Schachfreundes wegen Benutzerseiten/Festplatte angesagt.
  • Für die Schätzung von 10.000 gibt es keine Grundlage. Es ist aber egal; wir können an der Anzahl sowieso nichts ändern, sondern nur das Vorkommen immer weiter reduzieren.

Liebe Grüße --PerfektesChaos 20:48, 20. Mär. 2014 (CET)Beantworten

10.000 war sogar noch zu optimistisch. Es sind fast 40.000. Dieses Jahr wird das nichts mehr. Erstmal müsste jedenfalls geklärt werden, wie man die Stellen überhaupt sinnvoll auflistet, damit man sie abarbeiten kann. Die Volltextsuche hilft jedenfalls nicht weiter. 77.7.33.95 11:38, 24. Mär. 2014 (CET)Beantworten


  • Na, das ist ja eine Hausnummer. Danke für deine Bemühung.
    • Dass es eine Dunkelziffer gibt, war mir klar, weil WSTM gelegentlich anschlug und gleich automatisch ersetzte, ohne dass der Artikel in meiner gespeicherten Liste auftrat.
    • Dass die so hoch ausfällt, hatte ich nicht erwartet.
    • Hoffentlich sind es nur 30.000 Artikel, weil ja mehrfach pro Seite möglich.
    • Die Volltextsuche fiel inzwischen unter 1000.
  • Unmittelbares Vorgehen:
    • Erstmal business as usual.
    • Neue Suchmaschine abwarten. Es gibt zwei Möglichkeiten: Sie liefert Null oder 34.567 Artikel.
    • Wenn Null, dann monatlicher Dump-Vergleich.
    • Wir haben in Technik und Syntax und Bot-Betreiber eine äußerst dünne Personaldecke und dringlichere Aufgaben mit Toolserver und veraltenden Gadgets, als dass wir Aufwand in eine Geschichte stecken können, die in zwei Monaten wieder völlig anders aussehen kann. Die Bot-Betreiber müssen erstmal den Toolserver räumen; vorher starte ich da keine komplizierten Manöver.
    • 2014 ist damit natürlich hinfällig für das Ende des Supports.
  • Du fragtest nach Plan und Strategie?
    1. Priorität: Zuflüsse stoppen.
      • Dein Schachfreund hätte nicht 2013 eine neue Seite anlegen sollen können müssen.
      • Ich werde zu gegebener Zeit den Umherirrenden bitten, eine Logik zu schreiben, die einmal monatlich den Dump daraufhin auswertet, auf welchen Seiten prettytable neu auftauchte, gegenüber dem Vormonat; und nur dies als Wartungsseite zu veröffentlichen.
      • Auf deren Versionsgeschichte/Blame wären die Benutzer anzusprechen bzw. geräuschlos ersichtliche Formatvorlagen zu aktualisieren.
        • Auf Projektseiten, Redaktionen, Portalen, Benutzerseiten (aber auch privaten Festplatten) können Musterseiten liegen.
        • Man kann den Artikel vom Vorjahr nehmen und drübertippen. Einmal diese Serie bereinigt, und für dieses Thema ist der Fall erledigt.
        • Altgediente können immer noch in der Welt von 2005 stecken und jede Änderung seither an sich abprallen lassen; diese Umstellung auf Vector war ein Skandal, und durch welches MB wurde eigentlich ermächtigt, Kategorien einzuführen?
        • Einmalig kann man WPNR und Portalseiten flöhen. BNR in Ruhe lassen. Wenn jemand seit 2007 inaktiv ist, muss man nicht mit Trara Hunderte von Benutzerseiten umbauen, die sowieso keiner mehr anguckt.
        • Vorlagen sind in Allgemeinverantwortung; aber mühsam, testaufwändig und häufig reif für ein Vollprogramm.
    2. Priorität: Infoboxen fördern.
      • Ein Großteil geht auf historische Tabellen zurück, für die es heute Infoboxen gibt oder die eingeführt werden könnten.
      • Schiffe und Katzenrassen machen das von selbst. Kann dauern, kostet aber die Techies keine Arbeit.
      • Die Themenbereiche wären zu analysieren. Von ein paar verstreuten Kleinserien und Einzelartikeln abgesehen schlugen in der Volltextsuche nur Sport und Verkehrsmittel in größeren Mengen auf. Zu gegebener Zeit wäre entweder mit Cirrus oder Dump zu untersuchen, ob das auch für das bisherge Dunkelfeld zutrifft.
      • Woran es liegt, dass manche Artikel konstant immer und manche nie in der Lucene-Suche aufschlagen, ist mir rätselhaft. Ich konnte keine syntaktische Ursache finden; ist aber in ein paar Monaten Geschichte.
    3. Priorität: Bots
      • Theoretisch möglich, wenn in einer Serie keine Darstellungsprobleme im Kopfzeilenbereich auftreten. Die jüngsten Bahnstrecken-Infoboxen waren so ein Fall, weil dort keine Formatierung auftrat; Name beginnend mit Bahnstrecke und prettytable in den ersten 200 bytes oder so.
      • Diese Änderung zählt als kosmetisch. Bots dürfen das nicht nur deswegen bearbeiten. Als IP geht das leichter; vor allem wenn auf drei Provider verteilt.
      • Automatisierte Serien fluten die Beo der Fachleute. Das muss vorher abgesprochen und erwünscht sein.
      • Nur Umstellung auf Infobox möglich. Diese aber schwierig bei uneinheitlich formatierten Altbeständen.
    4. Priorität: Interaktive Skripte
      • WSTM kann auf jeden Fall interessierte Benutzer warnen; auch automatisiert ersetzen.
      • autoFormatter@TMg kann auch ersetzen.
      • Problem: Die Bearbeiter müssen willens sein und sich darauf einlassen. Sie müssen nach der Umstellung die optische Darstellung prüfen oder sich gut mit Kopfzellen-Syntax auskennen. Geht nur als Opt-In; sonst ist die Warnung unverständlich und störend und wird ignoriert.

LG --PerfektesChaos 21:35, 31. Mär. 2014 (CEST)Beantworten

Meinem persönlichen Eindruck nach werden von der Volltextsuche nur Seiten gefunden, bei denen die prettytable-Tabelle ganz am Seitenanfang steht. Z. B. wurde Deutschland Tour 2001 zunächst gefunden, seitdem ich aber die erste der beiden prettytable-Tabellen auf wikitable umgestellt habe, wird sie trotz einer weiteren prettytable-Tabelle nicht mehr gefunden. 129.13.72.198 11:16, 2. Apr. 2014 (CEST)Beantworten
Kann ich nicht bestätigen.
Auf so einen simplen Zusammenhang wäre ich auch längst gekommen.
Habe gerade drei aus der Volltext-Suche eliminiert: Spezial:diff/129153388 Spezial:diff/129154013 Spezial:diff/129153500 – da passt das nicht.
Es ist auch völlig wurscht. In ein paar Monaten werden wir sehen, was Cirrus liefert; 0, 900 oder 34.567 Seiten.
VG --PerfektesChaos 23:17, 2. Apr. 2014 (CEST)Beantworten

Nach zwei Sperren heute muss ich davon ausgehen, dass die Umstellung von prettytable auf wikitable im Allgemeinen nicht gern gesehen ist. Ich stelle deshalb meine Bemühungen in dieser Hinsicht ein. 85.212.38.87 18:27, 11. Jun. 2014 (CEST)Beantworten

Ja, danke dir dafür erstmal.
Sowas besser in kleinen Häppchen; nicht die Archive, und nicht gebündelt bei einer einzigen Thematik von oben runter, sondern von jedem Thema eine Seite und eine Woche drauf wieder von jedem Thema eine Seite.
Gut, wenn man noch eine Zweit-IP hat, notfalls eine dritte, und irgendwann gibt es ja wieder neue. Besser, du wirst für sowas gesperrt, als ich.
LG --PerfektesChaos 19:11, 11. Jun. 2014 (CEST)Beantworten

Also mit der neuen Suchmaschine Cirrus Search hat sich nach meinem Eindruck nach überhaupt nichts an den Ergebnissen verändert. Suche nach "prettytable" liefert nach wie vor irgendwas zwischen 500 und 1000 Ergebnissen. 79.217.187.50 19:25, 6. Sep. 2014 (CEST)Beantworten

Kann ich überhaupt nicht bestätigen; 38.997 Treffer. LG --PerfektesChaos 21:50, 6. Sep. 2014 (CEST)Beantworten
Bei deinem Link hab ich Null Ergebnisse, aber ich hatte mich auch verlesen, die Suchmaschine wurde vor ein paar Tagen auf Commons aktiviert, hier aber noch nicht. 79.217.164.40 12:06, 7. Sep. 2014 (CEST)Beantworten
Tja, wenn deine IP-Ehre es zulässt, müsstest du dich auf irgendeinem Späh-Account mal anmelden und WP:BETATEST aktivieren („Beta“ in der persönlichen Werkzeugleiste), dort einschalten. LG --PerfektesChaos 13:27, 7. Sep. 2014 (CEST)Beantworten
38.498 Treffer heute. Aber kannst du mir erklären, warum bei der Suche nach "wikitable" der Artikel Kondratowice gefunden wird? 85.212.17.252 21:54, 12. Nov. 2014 (CET)Beantworten
  • Kann ich, insbesondere wenn du wirklich wikitable meinst:
    • Da steht eine Infobox drin.
    • Die ist intern als wikitable formatiert.
    • Ab heute wird nicht mehr der Quelltext der Seite durchsucht, sondern der Text, der sich ergibt, nachdem alle Vorlagen expandiert wurden.
    • Wenn dir das nicht gefällt: Hilfe:Suche/Cirrus #insource
  • 500 Artikel in zwei Monaten weggeputzt, ist auch eine Leistung.
LG --PerfektesChaos 22:12, 12. Nov. 2014 (CET)Beantworten
Wenn das so wäre, wie du es sagt, müssten zehntausende Artikel gefunden, nicht nur drei. 85.212.48.122 22:15, 12. Nov. 2014 (CET)Beantworten
  • Ich seh 152.189 Treffer.
  • Es gibt aber ohne insource zwei Kalender; da scheint dann irgendwas kaputt zu sen; weil ohne insource dürfte es im ANR gar keine Treffer für wikitable geben, sondern nur Kategorie:Hilfe:Listen und Tabellen und so.
LG --PerfektesChaos 22:47, 12. Nov. 2014 (CET)Beantworten
  • "insource:wikitable" liefert bei mir auch die 152.xxx Treffer.
  • "wikitable" liefert korrekterweise zwei Kalender, dort steht ja auch im Wikitext "Wikitable".
  • Nach einem Nulledit meinerseits wird Kondratowice bei der Suche nach "wikitable" nicht mehr gefunden. Hamsterschluckauf?
85.212.48.122 23:18, 12. Nov. 2014 (CET)Beantworten
Letzteres dürfte es treffen, wobei diese Index-Strukturen noch sehr jung für dieses Wiki sind. Der Grundbaum könnte schon ein paar Monate alt sein, und hatte sich noch irgendwoher das Schlagwort eingefangen. Dein Nulledit hat es prompt aus dem Baum gesägt. Der Gesamtbaum umfasst alle Wörter aus zehn Millionen Seiten aller Namensräume, und soll sich immer aktualisieren, wenn sich eine Seite ändert. --PerfektesChaos 23:23, 12. Nov. 2014 (CET)Beantworten

2015

[Quelltext bearbeiten]

Sechs Monate sind vergangen und die Anzahl hat sich gerade mal auf 37.851 reduziert, also ca. 650 Artikel. Das ist ja gar nichts. Wenn das Schneckentempo anhält, brauchts noch 28 Jahre, bis alle prettytable umgestellt sind. 85.212.31.76 22:09, 7. Mai 2015 (CEST)Beantworten

Ich würde das als Fortschritt sehen: Es sind absolut nicht mehr geworden; falls einige verschlafene alte Häschen die alte Syntax neu eingefügt hatten (da kenne ich ein paar, die seit 2005/2007 nichts mehr dazugelernt haben), dann stehen dem deutliche Bemühungen gegenüber, davon loszukommen.
Ich werde irgendwann, wenn ich mal Zeit und Langeweile habe, WSTM für narrensichere Trivialfälle eine automatische Übersetzung beibringen. Brauche ich aber einen klaren Kopf und einige Stunden dazu.
Die Tücke ist, dass sowas nicht von Bots gemacht werden darf, zumindest nicht isoliert. Früher mal hatten Bots bei notwendigen Umstellungen immer auch gleich etwas Syntaxkosmetik miterledigt, aber die momentan aktiven Teile machen das nicht mehr.
Wenn WSTM das mal automatisch ersetzt, dann kann man auch gezielt Artikel mit prettytable ansteuern und irgendwas Sinnvolles tun; irgendein Linkfix oder Typografie oder Literaturformate finden sich eigentlich immer.
LG --PerfektesChaos 15:11, 9. Mai 2015 (CEST)Beantworten
Wäre ein Bearbeitungsfilter sinnvoll? 85.212.8.69 17:16, 20. Mai 2015 (CEST)Beantworten
Sinnvoll theoretisch schon, aber nicht durchsetzbar. Zumindest noch nicht. Gerade die Altgedienten haben die größten Schwierigkeiten, etwas dazuzulernen, und reagieren am algerischsten auf den BF. LG --PerfektesChaos 15:33, 2. Jun. 2015 (CEST)Beantworten

Wasserstandsmeldung von heute: 36.984, also 850 in vier Monaten, der Dampfer nimmt Fahrt auf. Scheinen auch Autoren mitzubekommen, dass das umgestellt wird; ob es Netto-Neuzugänge gab, lässt sich einstweilen nicht feststellen. Wenn ich mal nichts zu tun habe, werde ich WSTM beibringen, einige eindeutige Fälle zu erkennen und automatisiert umzustellen. LG --PerfektesChaos 13:45, 15. Sep. 2015 (CEST)Beantworten

Seit heute stellt WSTM triviale Fälle für alle Benutzer um; Zählerstand: 36.658 (=300 in zwei Wochen) --PerfektesChaos 00:22, 1. Okt. 2015 (CEST)Beantworten
Sehr gut, vielleicht schaffen wir es sogar innerhalb von drei Jahren, alle Vorkommen zu elimieren. 92.75.223.96 17:23, 3. Okt. 2015 (CEST)Beantworten
Zwischenstand exakt 30 Tage später: 36.323, also 661 netto abgearbeitet.
  • Ist aber nicht repräsentativ, weil Erprobung von WSTM und besonderes Augenmerk.
  • Realistisch sind 5000–6000 pro Jahr, ohne Sonderaktionen.
Wenn die Quote pretty/wiki sich weiter verschoben hat und in normalen Artikeln prettytable weitgehend eliminiert wurde, wird ein Bodensatz übrigbleiben, der sich schon abzeichnet: Sport und Geografie.
  • Hier gibt es keinen Grund, die Artikel zu bearbeiten und zu pflegen. Bei den Olympischen Spielen 1964 hatte das Sackhüpfen der Damen irgendeine Ergebnistabelle, und fertig. Nicht mal Weblinks, die irgendwer manuell fixen würde, gäben einen Anlass zur Bearbeitung. Genauso sieht es mit massenhaft angelegten geografischen Einheiten aus, deren „Metadaten“ extern zugeliefert werden.
  • Dann muss hinsichtlich des Restbestandes neu nachgedacht werden.
LG --PerfektesChaos 13:56, 15. Okt. 2015 (CEST)Beantworten
Was genau verstehst du als Bodensatz?
  • Artikel, bei denen eine automatische Ersetzung mit WTSM nicht möglich ist?
  • Oder Artikel, die schlicht nie bearbeitet werden?
Mein Greasemonkey spinnt und lädt das Skript nicht immer, sondern nur bei einigen wenigen Artikeln (so ungefähr bei jedem zweiten oder dritten). Woran kann das liegen?
129.13.72.198 15:09, 15. Okt. 2015 (CEST)Beantworten
Wie ich schrieb: Die niemand bearbeitet, und bei denen es keinen Grund dafür gibt. Siedlungen im brasilianischen Urwald, bei denen die aktuelle Einwohnerzahl von außen kommt, nebst Name des Bürgermeisters; aber kein Wikipedianer kommt vorbei und klebt sein Urlaubsfoto rein.
Andere Themengebiete mit vielen pretty und wenig Traffic sind Militär und Autos, aber da könnte gelegentlich noch was passieren. Es gibt noch Wahlergebnisse zum Parlament von Neusüdwales 1974, aber da ändert sich vielleicht mal aus systematischen Gründen etwas und die Tabellen werden ganz anders produziert.
Greasemonkey: Klingt nach
                     // @include     https://de.wikipedia.org/*
                     // @run-at      document-end
Entweder du stalkst meine edits, oder du hast einen Account mit Beo.
LG --PerfektesChaos 21:00, 15. Okt. 2015 (CEST)Beantworten
Es ist aber richtig, dass es auch noch ein Restpotential an nicht-trivial durch WSTM konvertierbarer Tabellenköpfe gibt; darunter könnten Tausende im Bereich von Ortsartikeln usw. sein – womöglich dann aber einheitliche Stubs durch einheitlich etwas anderes ersetzbar.
LG --PerfektesChaos 13:34, 16. Okt. 2015 (CEST)Beantworten
Greasemonkey funktioniert einfach nicht richtig. Vielleicht sollte man mal Benutzer:Prettytable ranlassen ;) 129.13.72.198 11:26, 3. Nov. 2015 (CET)Beantworten
  • Die psychologische Tausender-Marke wurde gleichzeitig mit dem Monatsende gerissen: 35.990.
  • Eine Rate von 650/Monat ist allerdings nicht konstant zu extrapolieren; es gab viel Aufmerksamkeit und von mir zu Testzwecken auch Extra-Edits.
  • Zum Jahreswechsel 2016/2017 wird es gut unter 30.000 liegen; und dann wird man sehen, was übrigbleibt.
  • Es ist ein Netto-Abbau; tatsächlich kamen auch hin und wieder einzelne hinzu, einmal sah ich sogar ein ganzes Dutzend Neuankömmlinge netto. Das werden serienmäßig aus irgendeiner Excel-Tabelle produzierte Stubs gewesen sein. Die kann man 2017 mal durch wöchentlichen Abgleich von pageid-Listen jagen.
  • 2017 werden massenhaft Serien-Artikel aus historischem Sport und geografischen Kleinobjekten (Narbief) übriggeblieben sein, die nie jemand bearbeitet und woran auch wenig zu machen wäre.

LG --PerfektesChaos 00:34, 30. Okt. 2015 (CET)Beantworten

Nicht so pessimistisch. Wenn estmal jedes Kaff seine von Wikidata bezogene Einwohnerentwicklungsgrafik bekommt, werden die Artikel en masse bearbeitet und im Zuge dessen die Tabellen entweder komplett durch was moderneres ersetzt oder halt nebenbei auf wikitable umgestellt. 147.142.65.109 13:20, 30. Okt. 2015 (CET)Beantworten

2016

[Quelltext bearbeiten]

Stand zum Jahreswechsel: ≈35.100

  • 2.750 netto weniger seit Mai 2015
  • Quote seit WSTM: 400–500/Monat
  • Planziel Jahreswechsel 2016/2017: <30.000
    • Realistisch, aber mehr wird ohne besondere Bot-Aktivitäten auch nicht drin sein.
    • Danach dürfte Sockel erreicht sein.

LG --PerfektesChaos 15:47, 3. Jan. 2016 (CET)Beantworten

Stand zum Quartalswechsel: ≈32.250
  • 2.850 netto weniger seit 1. Januar
  • Quote: >900/Monat
Die psychologisch interessante Schwelle von 30.000 wird dann wohl schon zur Jahresmitte unterschritten worden sein; spannend wäre, ob sich das zum Jahresende mit unter 25.000 fortsetzt.
LG --PerfektesChaos 15:44, 2. Apr. 2016 (CEST)Beantworten
Am 7. Mai 2015 gab es eine Beschwerde ob des langsamen Fortschritts und 37.851 Artikel.
Inzwischen fiel die Anzahl leicht unter 31.500, also 6.000 in zwölf Monaten, wobei das erst ab Okktober mit WSTM richtig Fahrt aufnahm. 3.600 in 4¼ Monaten sind zurzeit 850/Monat.
LG --PerfektesChaos 12:30, 8. Mai 2016 (CEST)Beantworten
Jetzt 29.999, wobei das meiste davon Benutzer:Boshomi erledigt hat. Mit WSTM hat das nix zu tun. 92.75.199.232 11:36, 14. Mai 2016 (CEST)Beantworten
Ja, aber genau sowas in zigfacher Serie ist die Sorte absolut verbotener Mini-Edits ohne Wirkung nach außen als reine Syntaxkosmetik. Das könnte ich auch.
Es hat schon seinen Grund, warum es für derartige Trivialedits keine Bot-Aufträge gibt.
Außerdem macht er nur eine plumpe Textersetzung des Klassennamens, ohne zu berücksichtigen, ob die Färbung der Kopfzeile dadurch zerstört wird; WSTM ist da wesentlich sensibler. Boshomi interessiert das einen Scheißdreck.
Boshomi rühmt sich aber auch, manuell im Browser 50 Tabs zu öffnen, dann ganz schnell 50-mal sein (TMgs) Skript über dem gesamten Wikitext auszuführen und dann ganz ganz schnell auf alle 50 Tabs auf Speichern zu klicken. Also ohne Seitenvorschau, ohne Diffpage und Beachtung der Kolleralschäden, ohne Rücksicht auf optische Veränderung der auf Hilfe:Tabellen/prettytable sorgfältig auseinanderklamüserten Tabellengestaltung.
Wenn man ohne Botflag tausendfach kosmetische Edits ausführt, dann flutet man die Beos der Autoren. Aber auch das geht Boshomi am Arsch vorbei.
VG --PerfektesChaos 01:04, 23. Mai 2016 (CEST)Beantworten
Mir stößt an der Edit-Serie aktuell auch sehr unangenehm auf, dass prettytable nicht etwa durch wikitable, sondern durch wikitable zebra ersetzt wird, ohne dass dies in der Zusammenfassungszeile auch nur erwähnt wird. Das ist eine sogar sehr stark nach außen sichtbare Änderung, zu der man durch einen Eintrag in der Zusammenfassungszeile stehen sollte.
Die Änderung ist in einigen Fällen IMHO völlig deplatziert, zum Beispiel hier: Eine Tabelle mit nur zwei Zeilen braucht kein zebra, dafür war das nie gedacht. Sehr viel dringender bräuchte diese Tabelle eine korrekte semantische Auszeichnung der Kopfzellen. In einigen Fällen sind die Edits auch mit unkommentierten Farbänderungen verknüpft (gegen die ich per se nichts habe, solange unnötig Buntes durch Neutraleres ersetzt wird), bei denen es aber zum guten Ton gehören würde, sie als solche zu kommentieren. Völliger Unfug ist es natürlich, wikitable zebra einzufügen, wenn es wegen Inline-Formatierungen unwirksam ist (Beispiel). Zuguterletzt ist wikitable zebra komplett falsch, wenn in der Tabellensyntax rowspan vorkommt, da es in diesem Fall zu Darstellungsfehlern führt. Dafür habe ich zwar kein Beispiel gefunden, es würde mich aber nicht überraschen.
Die zebra-Klasse ist aufgrund der Diskussion unter Wikipedia:Verbesserungsvorschläge/Archiv/2010/März#Alternierende Tabellen-Hintergrundfarbe bei sortierbaren Tabellen eingeführt worden. (Nebenbemerkung: Vielleicht sollte man die Projektseite mal in „Verschlechterungsvorschläge“ umbenennen, da sie zahlreichen Murks hervorgebracht hat, nicht nur die zebra-Klasse.) Schon damals sagte Fomafix: Bei einer neuen CSS-Klasse zebra habe ich etwas die Sorge, dass das dann Reihenweise in die Artikel eingebaut wird und dann darüber gestritten wird, was „schöner“ aussieht. Dieser vorhersehbare Fall ist nun eingetreten. (Nebenbei bemerkt ein schöner Beleg für die These, dass der Ansatz, projektweite Klassen zu definieren und auf einen sparsamen Einsatz zu hoffen, gescheitert ist.) Daher habe ich die zebra-Formatierung jetzt für mich persönlich abgeschaltet und ignoriere darüber hinaus vorerst die prettytable-Thematik. Gruß --Entlinkt (Diskussion) 01:37, 23. Mai 2016 (CEST)Beantworten

2017

[Quelltext bearbeiten]

Schnappschuss zum Jahresbeginn 2017: 25.066 Treffer. Ergo 10000 in einem Jahr abgearbeitet. 147.142.83.151 16:32, 8. Jan. 2017 (CET)Beantworten

Am 1. Mai:

  • 24.000 wurden unterschritten.
    • Somit netto-Abnahme um gut 1000 in vier Monaten.
    • Jahresendprognose also unter 22.000 Artikel.
    • Wobei es auch noch kontinuierlichen Zuwachs gibt, insbesondere aus dem Sport, aber auch von einigen Alteingesessenen.
  • Gesamtzahl der Tabellen mit einer der beiden Klassen beträgt rund 240.000 Artikel; somit haben jetzt 90 % rein wikitable und 4.344 beide Klassen.
  • Ich weiß von mehreren Bot-Läufen – teils über Hunderttausende von Artikeln – in den nächsten Jahren; für triviale Verwendungen besteht also Hoffnung.

VG --PerfektesChaos 13:30, 1. Mai 2017 (CEST)Beantworten

Heute 22.800. Wann werden die Botläufe durchgeführt? 129.13.72.197 15:07, 13. Okt. 2017 (CEST)Beantworten
Wie es da steht: „in den nächsten Jahren“. Die Jahresendprognose von 22.000 ist machbar. Problematisch ist, dass die Sportler permanent hundertfach frische Artikel draufpacken; sonst wären wir schon unter 20.000. Was „2017“ im Titel hat, dürfte aus diesem Jahr sein. Du kannst die Ersteller ja mal freundlichst drauf ansprechen.
VG --PerfektesChaos 19:29, 13. Okt. 2017 (CEST)Beantworten

2018

[Quelltext bearbeiten]

Prost Neujahr, und noch 22.187 prettytable-Vorkommen. Also wurden nur rund 3000 im Jahr 2017 eliminiert. 92.74.17.170 13:28, 2. Jan. 2018 (CET)Beantworten

Emili… enilimie… hicks … Prost Neujahr! … zurückgebaut wurden wesentlich mehr, aber es sind auch Hunderte in diversen Sportartikeln frisch eingebaut worden. Es gibt heute allein über zwei Dutzend Artikel mit 2017 im Lemma und dazu die ganzen Nachwuchskader und exotische neue Vereine und was weiß ich. Immerhin, für 2016 werden heute 65 Artikel gelistet; auch das alles Sportveranstaltungen. Ich glaube aber, in den Jahren mit geraden Zahlen sind immer irgendwelche Olympiaden und WM und EM; 2014 hat 95. VG --PerfektesChaos 14:03, 2. Jan. 2018 (CET)Beantworten

2019

[Quelltext bearbeiten]

10.625 am 6. Januar 2019. Die ganzen Sportwettbewerbsartikel scheinen mittlerweile bereinigt zu sein. 88.67.115.45 13:58, 6. Jan. 2019 (CET)Beantworten

Tja, und wären nicht insbesondere Anfang 2018 mit der Winterolympiererei ein halbes Tausend frisch hinzugekommen, dann wäre die psychologische Marke von 10.000 wohl inzwischen geknackt worden.
Es schälen sich ja mittlerweile ganz bestimmte einzelne Sportarten heraus, und in Absprache mit deren Portalen könnte man nur für diese Schlagwörter und für narrensichere Trivialfälle jetzt an Bot-Läufe denken.
VG --PerfektesChaos 14:25, 6. Jan. 2019 (CET)Beantworten
Fände ich sinnlos. Mittlerweile sind ja gerade die Fälle übrig, die Spezialumbauten benötigen. Die restlichen 10.000 kriegt man auch noch manuell hin. 88.67.115.45 16:54, 6. Jan. 2019 (CET)Beantworten
Zu Ostern sind noch gut 7400 übrig. 84.179.210.156 09:52, 20. Apr. 2019 (CEST)Beantworten

Jahres-Bergfest, und noch gut 6000 übrig. 94.217.96.136 15:22, 30. Jun. 2019 (CEST)Beantworten

13. September: 3422 übrig. Was passiert eigentlich, wenn alle Vorkommen getilgt sind? Wird prettytable dann aus der Programmierung entfernt? 84.57.199.71 20:28, 13. Sep. 2019 (CEST)Beantworten
Das ist der Plan.
Die CSS-Programmierung ist relativ umfangreich, und sie wird mindestens einmal jedem Leser aufgedrängt. Danach wird für jede der zehn Millionen Wikisyntax-Seiten und der zig Millionen Spezialseiten oder sonstigen generierten Seiten das HTML-Dokument nach diversen Elementen durchsucht, die es zurzeit mit ’ner Quote von gut einem Promille treffen kann.
Das CSS für alle Seiten soll möglichst stark reduziert werden und übersichtlich sein, zumindest was unser deWP-Zeugs betrifft, und wenn eine bestimmte Seite bestimmtes CSS benötigt, dann wird es nur für diese mitgeliefert.
VG --PerfektesChaos 14:26, 18. Sep. 2019 (CEST)Beantworten
Über alle Namensräume hinweg gibt es noch 9000 Vorkommen. Ich denke die sollte man nach Möglichkeit auch alle Umstellen (abgesehen vielleicht von Uralt-Archiven). 92.74.22.39 19:48, 24. Sep. 2019 (CEST)Beantworten
Es werden nur die aktiven Funktionsseiten bereinigt, und wurden nebst allen Vorlagen und Systemnachrichten schon einmal durchgeputzt.
Um BNR und Portale und WikiProjekte müssen sich die maintainer selbst kümmern.
Es gibt keine triviale Umstellung per Bot, sondern die Seite muss syntaktisch neu formatiert werden, und die beabsichtigte optische Wirkung muss festgestellt werden. Das geht nur händisch, und dafür sind die interessierten Benutzer außerhalb des ANR selbst verantwortlich.
Es wird vorher eine allgemeine Information im Kurier geben, darüber noch allerhand Geratsche und Ignoranz.
Die Klasse wurde 2008 als offiziell veraltet bekanntgemacht, aber es gibt bis heute sogar noch Admins, die das nicht mitbekommen haben und sie frisch einbauen.
Ich plane nach der ANR-Bereinigung ein JS-Gadget, das bei angemeldeten Benutzern außerhalb des ANR (in NR 1–101) und Vorhandensein der Klasse den CSS-Code noch nachliefert, ansonsten ist die Klasse für normale Leser wirkungslos. Der Seitenfuß kann mit einer Warnmeldung + Hilfe-Link ausgestattet werden, dass in dieser Seite eine veraltete Klasse vorkommt. Nach weiteren fünf Jahren kann das Gadget auch standardmäßig deaktiviert werden.
Wenn keine CSS-Definition aktiv ist, dann ist es immer noch eine Tabelle, bloß ohne die Linien. Das ist der Endzustand für verrottetes ungepflegtes HTML/CSS. So werden dann Benutzerseiten inaktiver Benutzer ohne Grabpflege aussehen.
VG --PerfektesChaos 13:48, 25. Sep. 2019 (CEST)Beantworten

Soeben fiel die Anzahl im ANR unter 2000. Dann heißt es jetzt wohl: Endspurt! 147.142.70.70 13:33, 31. Okt. 2019 (CET)Beantworten

2020

[Quelltext bearbeiten]

917 übrig am Neujahrstag 2020. 2003:C9:6F2F:7700:F8CB:BF71:97D8:956 14:24, 1. Jan. 2020 (CET)Beantworten

Moin zusammen, Tag heute, Artikel sollten jetzt keine prettytable-Einbindungen mehr haben. Bleiben aber noch Einbindungen über alles gesehen:
@PerfektesChaos: Machst du dann alles weitere hierzu oder soll ich dazu noch etwas machen? Ich behalte neue Einbindungen grundsätzlich im Auge, auch wenn da über die letzten Monate nichts mehr neu gekommen war.
mfg --Crazy1880 18:46, 8. Jun. 2020 (CEST)Beantworten
Meine Strategie sieht wie folgt aus:
  • Nächste 4–6 Wochen:
    • ANR + Vorlagen auf Neueinfügungen beobachten
    • Bei Auftreten:
      1. Bearbeiter kontaktieren
      2. Hier kurze Notiz
  • Bei günstiger Gelegenheit, wenn mal Ruhe ist: Ich schreibe einen Artikel im Kurier.
  • Vorher schreibe ich umseitig noch was zu Performance und Aufrechterhalten von Wracks.
  • Zukünftiger Schritt ist Änderung des CSS:
    • ANR bekommt fette rote Linien
    • Einige Rest-Namensräume bekommen weiterhin Linien wie bisher; wahrscheinlich irgendwie verknappt und auch mit etwas rot
    • Diskussionsseiten bekommen nix mehr; Diskussionsarchive sind dann eben blass.
  • Irgendwann fällt auch für Rest-Seiten (Portale, WP, BNR) das CSS weg; dann ist es eben eine Tabelle ohne Linien. Ab 2021 wohl erstmal ebenso wie ANR fette rote Linien.
  • 2021 Abschaltung.
VG --PerfektesChaos 20:05, 8. Jun. 2020 (CEST)Beantworten
@PerfektesChaos: Wann gibts den Kurierartikel? Oder hab ich den verpasst? 84.137.71.155 22:27, 28. Aug. 2020 (CEST)Beantworten
Gibt es irgendwann in ruhigeren Zeiten. In der Pipeline für meine Kurier-Nachrichten steht noch eine Info zur Migration von Labs-Tools auf WikiMedia Cloud; danach irgendwann. Hier gibt es das Phänomen, dass damit die Ankündigung verbunden sein wird, dass zukünftig der Einbau im ANR mit fetten roten Warnlinien verbunden sein wird, und noch später im eigenen BNR schlicht überhaupt keinerlei Linien mehr zu sehen sein werden, weil zur Verschlankung der gesamte Code aus dem CSS herausfallen wird. Das gibt aber wieder Aufschrei derjenigen, die seit 2007 nichts mehr dazugelernt haben, und bedarf ausführlicher Erläuterung, warum man nicht alles, was es in anderthalb Jahrzehnten mal gegeben hatte, jedem Leser in den Browser und von jeder Programmierung auf ewig unterstützt pflegen kann.
Einstweilen kann ja beobachtet werden, welche Bearbeiter prettytable frisch in den ANR hineinschreiben; und diese dann individuell auf der BD informiert werden. Zurzeit und sporadisch sehe ich keine Vorkommnisse, aber die mag es zwischenzeitlich gegeben haben.
VG --PerfektesChaos 17:18, 1. Sep. 2020 (CEST)Beantworten

2021

[Quelltext bearbeiten]

wie kann das passieren? Es binden immer noch Benutzer "prettytable" ein: [3] --Jmv (Diskussion) 18:56, 1. Jan. 2021 (CET)Beantworten

Höheres Lebensalter, war schon immer so gewesen.
Gemäß meiner Darlegung einen Abschnitt drüber wäre es an dir als Artikelbearbeiter, auf der BD aufzuschlagen (war bereits bei Neuanlage des Artikels enthalten), und zartfühlend das Problem zu schildern.
HNY --PerfektesChaos 19:13, 1. Jan. 2021 (CET)Beantworten