Wikiup Diskussion:Projektneuheiten/Archiv/2021

aus Wikipedia, der freien Enzyklopädie

Vorschau -> Februar 2021

Hallo @Raymond: Ich denke, die Punkte aus .29 und .30 sollten von Vorschau nach Februar 2021 übertragen werden. Allerdings weiß ich nicht, wann die Änderungen hier aktiv wurden, lässt sich das irgendwo einsehen? --Count Count (Diskussion) 10:28, 17. Feb. 2021 (CET)

Hallo Count Count, danke für den Hinweis. Umseitig erledigt. Nachzulesen ist das hier: https://phabricator.wikimedia.org/source/mediawiki-config/history/master/ . Die hiesige Wikipedia fällt unter "all wikis to 1.36.0-wmf.30" usw. Hervorhebung durch mich. Du siehst dort auch "testwikis wikis ...", "group0 wikis ..." und "group1 wikis ...". Das sind neben den Testwiki vor allem kleinere Wikis und irgendwann auch Commonswiki (ich glaube group1). Es gab in den letzten Zeit (gefühlt) häufiger Rollbacks auf Grund von Bugs, daher habe ich teils verzögert umseitig vermeldet. Oder auch vergessen *hust* :-) — Raymond Disk. 10:45, 17. Feb. 2021 (CET)
Danke, auch für die Info! So kann ich das das nächste Mal selbst umtopfen, wenn es mir auffällt. --Count Count (Diskussion) 10:48, 17. Feb. 2021 (CET)

Popuptext – Einzelnachweisvorschau

Kann es sein, dass da in der Auswahl für nicht angemeldete Benutzer ein falscher Text steht?

Soweit so gut aber dieser Text spricht nur von den Seitenvorschaubilderoptionen, es scheint jedoch so zu sein, dass mit der Neuerung nun auch die Einzelnachweisvorschau gemeint ist, die von dort aus

Page preview form (en).svg

⧼popups-settings-enable⧽

gesteuert werden können. Wäre es da nicht sinnvoll diesen Text anzupassen? Und zwar ohne wieder irgendeinen Mediawikitext zu verschieben oder zu löschen wie hier ⧼popups-settings-option-simple-description⧽ ‹grmpf› Ich bin mir hundertprozentig sicher, dass ich das so nicht in die Hilfeseite gesetzt hätte.

Alternativ könnte ich mir diesen Text vorstellen:

  • Du kannst die Vorschaueinstellungen ändern, indem du einen Link im Fußbereich der Seite verwendest.

Scheinbar ist das eine zusammengehörende Funktionsreihe, ich kann aber unmöglich die Popuprefs jetzt dort mit einfügen da der Titele der Hilfeseite auch spezifisch Hilfe:Seitenvorschaubilder lautet. Was mach ich jetzt damit? --Liebe Grüße, Lómelinde Diskussion 14:40, 17. Mai 2021 (CEST)

@Lómelinde Das englische Original aus MediaWiki:Popups-settings-help/en lautet: "You can turn previews back on using a link in the footer of the page." Die Übersetzung MediaWiki:Popups-settings-help/de aus 2015 wurde da etwas überspezifisch vorgenommen: "Du kannst Vorschaubilder erneut aktivieren, indem du einen Link im Fußbereich der Seite verwendest.". (Hervorhebung durch mich). Mein Vorschlag: "Du kannst die Vorschaufunktion über einen Link in der Fußzeile der Seite wieder einschalten." Was meinst du? Wenn ich das bis heute Abend im Translatewiki ändere, geht die Änderung hierzuwiki und in allen Wikis mit deutscher Sprache vermutlich diese Woche Donnerstag live. --Raymond Disk. 15:13, 17. Mai 2021 (CEST)
Nun ja, es geht um zwei unterschiedliche Dinge und man kann beide einzeln verändern, es ist also nicht unbedingt immer ein „einschalten“ sondern eine Änderung. Man kann um-, an-, ab-, hin und her schalten, für eine einzelne Funktion (wie zuvor) wäre das ok, aber je nachdem was man gerade eingestellt hatte, kann man dort etwas aus- oder anschalten, es ist nicht gekoppelt als entweder beide Popups oder keines. Daher fände ich meinen Vorschlag sinnvoller. Einschalten ist zu einseitig, finde ich. Aber mach wie du denkst, ich verwende weder das eine noch das andere und arbeite zudem nicht unangemeldet. Ich habe eben extra den Browser gewechselt, um einen Test durchzuführen, da sich ja das Layout des Dialogfensters „total“ verändert hat. Aber wo soll ich mit der Beschreibung hin? --Liebe Grüße, Lómelinde Diskussion 15:25, 17. Mai 2021 (CEST)
@Lómelinde Ühersetzungen im Translatewiki müssen sinngemäß dem englischen Text entsprechen. Mit deinem Einwand hast du aber recht. Ich überlege mir, wie ich den englischen Text per Patch anpassen kann. Das wird dann etwas länger dauern. Eilt ja aber nicht so sehr, ich glaube nicht, dass die Funktion so sehr oft genutzt wird. --Raymond Disk. 16:15, 17. Mai 2021 (CEST)
Oh, ich dachte es gäbe einen gewissen Spielraum der Anpassung. Nein es eilt nicht es ist mir sowieso eher zufällig aufgefallen. Dankeschön. --Liebe Grüße, Lómelinde Diskussion 16:22, 17. Mai 2021 (CEST)

HILFE GESUCHT – error class bei ref-error und anderen Meldungen

Auf phab:T280766 #7283623 wird bestritten, dass ein Fehler bei Auslieferung des CSS vorliegen würde.

  • Wer das reproduzieren kann, bitte dort bestätigen (sehen hierzuwiki drei Leute bislang).
  • Wer nicht, bitte mit genauer Beschreibung der Umstände nur hier.

Im Übrigen ist der Wegfall von .error in Gadget-Fehlermeldungen hier umseitig leider untergegangen, was ziemlich doof ist, weil das die Universal-Dekoration vieler Fehlermeldungen vieler Skripte über zwei Jahrzehnte ist.

  • Generell findet bei der WMF in den letzten Wochen und Monaten ein gnadenlsose Wegputzen und Löschen von CSS und PHP statt, das lediglich berücksichtigt, was im eigenen MW/core steht, noch nicht einmal die eigenen Extensiosn und Skins korrekt migriert, und sich einen Scheißdreck um die Wikis und ihre Inhalte und Gadgets schert, noch nicht mal die geliebte enWP zur Kenntnis nimmt. Und das will was heißen.

VG --PerfektesChaos 17:51, 15. Aug. 2021 (CEST)

.error funktioniert bei mir in allen Vorschauen, die ich getestet habe in allen vier Skins, mit und ohne Werkzeugleiste (im NWE gibt's gar keine Fehlermeldung). .warning und .success funktionieren weder in der Vorschau noch abgespeichert. -- hgzh 10:39, 16. Aug. 2021 (CEST)
Danke soweit.
Die haben anscheinend irgendwas gebastelt, das den parser output belauscht, ob dort class="error" vorkäme.
  • Die Parserfunktion #iferror: macht das auch; kapiert es jedoch nur, wenn das in " eingeschlossen ist und nicht in die syntaktisch gleichwertigen '.
  • Wenn irgendwo im Wikitext das schon vorkäme, gibt es auch CSS, sonst nicht.
  • Eine Extension gehört aber nicht notwendigerweise zum parser output.
  • Möglicherweise gibt es auch eine race condition.
  • Jedenfalls müsste das Fragment in einer nackten Spielwiese getestet werden, um eine Situation zu schaffen, in der das nicht auf andere Weise ausgelöst wurde.
  • Hochdramatischer Einsparungseffekt von ein bis zwei Dutzend Bytes, mit immensem Kollateralschaden und riesigem Aufwand.
Würdest du oder sonst Mitlesende Tech News 2021-18 beim routinemäßigen Querlesen entnommen haben, dass es einen BREAKING CHANGE gibt, und alle Gadget-Maintainer und Userscripter dahingehend umstellen müssen, dass sie per mw.loader.load() genau welches Ressourcen-Modul dynamisch laden, um den global einheitlichen Stil für die diversen .error und .errorbox und .warningbox oder intelligenter gleich zukunftsfähig alternativ .mw-error und .mw-errorbox nachzuladen, und unter genau welcher Task die weiteren Einzelheiten nachzulesen wären?
  • Was nebenbei gemerkt eigentlich auch umseitig hätte vermeldet werden müssen; genau dazu haben wir das ja.
VG --PerfektesChaos 14:45, 16. Aug. 2021 (CEST)
Anscheinend war ja das Entfernen von .error im Gegensatz zu den anderen beiden nie geplant, vgl. phab:T281228. So gesehen funktioniert jedenfalls bei mir alles wie vorgesehen, wenngleich das weder in der Kommunikation noch in der Umsetzung (die Cite-Extension verwendet die warning-Klasse ja nach wie vor) gut gemacht ist. Andere Tests fallen mir momentan auch nicht ein. -- hgzh 15:32, 16. Aug. 2021 (CEST)
class="error" ist schon futsch – für alle Gadgets.
  • Das würde dann und nur dann wirksam, wenn es schon in der Seite drinsteht; ansonsten wird es nicht geladen.
  • Aber selbst dann würden Gadget-Meldungen, die nicht in den Inhalt eingebettet sind, sondern bei der Seitenüberschrift stehen, oder unter dem Footer, niemals im globalen Fehler-Stil dekoriert – wegen grundloser Einschränkung auf .mw-body-content.
VG --PerfektesChaos 15:42, 16. Aug. 2021 (CEST)

Linkformatierung kleiner Seiten

Ich finde es ziemlich unglücklich, dass diese Option nun nicht mehr existiert. Könnte man diese Funktion bitte wenigstens hier lokal wieder aktivieren? Wieso geschieht so eine grundlegende Änderung überhaupt ohne Konsultation der Community? -- Chaddy · D Datei:VfB Eichstaett Logo.png 22:40, 16. Sep. 2021 (CEST)

+1 --Atamari (Diskussion) 22:42, 16. Sep. 2021 (CEST)
Ich wusste bis heute nicht, dass es so eine Option gab. Dem Task entnehme ich, dass das Feature Performanceprobleme gebracht hat, daher wird das auch sicherlich nicht mehr aktiviert werden. Userskripte sind wohl möglich, nur habe ich noch nirgendwo einen konkreten Hinweis gefunden, wie so etwas umgesetzt werden könnte. Würde meine Fähigkeiten wohl auch übersteigen.—XanonymusX (Diskussion) 23:16, 16. Sep. 2021 (CEST)
Man müsste diese API-Abfrage durchrödeln lassen und dann die Links entsprechend anpassen. -- hgzh 00:07, 17. Sep. 2021 (CEST)
So isses.
Das kann ja ein privates Benutzerskript gern machen, und bei jeder Ansicht/Vorschau im ANR derartige Abfragen vornehmen. Dabei auch eigene kB-Grenzen definieren für klein, ganzklein, bisselgrößer oder was, und die Verlinkungen entsprechend gestuft dekorierbar machen. Zieht aber spürbaren Traffic pro Seitenaufbau nach sich.
Effizient war das innerhalb des Servers gewesen, weil dort die Bytes direkt aus den Tabellen ausgelesen werden konnten.
Wegen global geringfügiger Nutzung, zur Verbesserung der Programmierung hinsichtlich Performance, Übersichtlichkeit und Robustheit sowie des ohnehin fragwürdigen Grenzwerts für Stub oder nicht Stub wurde das eingezogen, zumal es in den 1000 Wikis nicht wirklich eine einheitliche und stringente Stub-Politik gibt.
Bei 1000 WMF-Wikis ist grundsätzlich kein MB in jedem einzelnen erforderlich.
VG --PerfektesChaos 09:19, 17. Sep. 2021 (CEST)
Fragwürdig … so wurde es ja auch im Task begründet: “The value of the feature, when working as intended, also seems dubious.” Was der Bauer nicht kennt, frisst er nicht. Und deshalb soll das auch niemand anderes tun.
Bis vor ein paar Jahren konnte sich noch jede(r) den Wert für sich selbst definieren, dann wurde er auf eine Liste von Werten beschränkt und nun gibt es diese Option gar nicht mehr. “The intent of this task has been announced to the community …. No objections were raised.” Als jemand, dessen Fokus auf dem Artikelnamensraum liegt, fühlt man sich ein wenig wie Arthur Dent. Es ist ja nicht so, dass den Entwicklern mit Zugriff auf die Datenbanktabellen grundsätzlich unbekannt ist, wer die Option aktiviert hat und man diese Leute deshalb nicht direkt informieren konnte. -- Gruß, 32X 10:28, 17. Sep. 2021 (CEST)
Ich finde es auch ein bisschen arrogant einfach zu sagen: Das hat ja fast niemand genutzt, also können wir es einfach wegstreichen. Und diejenigen, die es genutzt haben, müssen jetzt mit einer schlechteren gebastelten Lösung leben? Das finde ich nicht gut. -- Chaddy · D Datei:VfB Eichstaett Logo.png 13:43, 17. Sep. 2021 (CEST)
@ „Es ist ja nicht so, dass den Entwicklern mit Zugriff auf die Datenbanktabellen grundsätzlich unbekannt ist, wer die Option aktiviert hat und man diese Leute deshalb nicht direkt informieren konnte.“
  • Das trifft so nicht zu; die Entwickler haben primär auch keinen Zugriff auf Benutzerprofil-Tabellen, sondern es gibt nur Server-Skripte mit statistischen Auswertungen.
Wenn die von announced to the community schreiben, dann heißt das üblicherweise, dass es irgendwo in der enWP diskutiert wurde. Ein Kommunikationsprozess für Entwicklerentscheidungen mit 1000 Wikis ist nicht definiert; maximal gab es mal eine Ankündigung in den Tech News, die du dann aber abonnieren und permanent aufmerksam lesen müsstest. Die Tech News sehe ich in der Task jedoch nicht zitiert.
Das Feature war schon seit Jahren in der Diskussion; insbesondere auch wegen der obskuren Bemessung der inhaltlichen Qualität über Byte-Umfang.
  • Beanstandet wurde, dass ein oder zwei Archiv-URL einen Stub zum vollwertigen Artikel machen konnten, während eine knappe wissenschaftliche Definition mit Literaturstelle und Wikilinks und Kat kein Stub ist aber wegen fehlender Wikitext-Bytes als solcher eingestuft wurde. Nach Bezug vieler Daten aus Wikidata per Infobox usw. stehen dann noch weniger Bytes in der Statistik, während eine ganze Ortschaft lexikonmäßig beschrieben wurde.
  • Empfohlen wird vielmehr, Spezial:Kürzeste Seiten durchzuarbeiten oder QS-Bausteine zu setzen wenn unerwünscht oder mit PetScan ohne BKS-Kat usw. irgendwas auszufiltern.
Die Konsequenzen aus diesem Feature hatten jedoch zu einer spürbaren Beeinträchtigung der Serverlast geführt, weil diejenigen User, die es aktiviert hatten, keine vorgefertigten Seitenrümpfe aus dem Cache erhalten konnten, sondern für diese User jeder einzelne Seitenabruf vom Server individuell neu generiert werden musste.
VG --PerfektesChaos 17:38, 17. Sep. 2021 (CEST)
Empfohlen wird vielmehr, Spezial:Kürzeste Seiten durchzuarbeiten oder QS-Bausteine zu setzen – Schade nur, dass ich die Funktion zu diesem Zweck nicht aktiviert hatte. (Siehe oben: Was der Bauer nicht kennt….) Das Argument mit der Serverlast, die wir paar angemeldeten Autoren verursachen, ist letztlich eine Aufkündigung von Wikipedia:Sorge dich nicht um die Server. Dann kann man das aber auch offiziell so sagen. -- Gruß, 32X 20:19, 17. Sep. 2021 (CEST)
@ „Aufkündigung von Sorge dich nicht um die Server“
  • Das ist erstens ein sehr alter Spruch, der noch nie so richtig wahr war.
  • Er bezog sich auch nur auf den Wikitext und nicht auf Sonderwünsche betreffend des Abrufs von Seiten. Gemeint war, dass im Artikel der Text nicht kryptisch verbogen werden solle, um vermeintliche Effekte zu erzielen.
  • Und gemäß Hilfe:Vorlagenbeschränkungen gibt es sehr wohl kritische Seiten, bei denen sorgfältig auf effiziente Programmierung von Vorlagen usw. geachtet werden muss, bzw. Seiten einer bestimmten Größe irgendwann für alle Beteiligten unzumutbar werden.
  • Der letzte Satz des zitierten Textes lautet: „Daher ist es unsinnig, die Anfrage eines Systemadministrators mit einem Hinweis auf diese Seite zu beantworten.“
VG --PerfektesChaos 21:26, 19. Sep. 2021 (CEST)
Wenn ich das richtig verstanden habe geht es noch nicht mal um die Serverlast, sondern darum, dass die Ladezeiten der Seiten verlängert wurden bei den Leuten, die diese Option aktiviert hatten. Davon hab ich nichts mitbekommen und selbst wenn ist das ja meine freie Entscheidung, ob ich längere Ladezeiten in Kauf nehme. -- Chaddy · D Datei:VfB Eichstaett Logo.png 20:23, 17. Sep. 2021 (CEST)
Du hast es hinsichtlich Ursache und Wirkung falsch verstanden.
  • Für die fraglichen User muss bei jedem Seitenabruf der Wikitext jeder Seite komplett neu aufgearbeitet werden.
  • Damit mag der Server 10 Sekunden nur für diese individuelle Generierung beschäftigt sein.
  • Diese Ausführungszeit geht allen anderen Aufträgen desselben Servers verloren; alle anderen User müssen also zumindest in Spitzenzeiten länger auf die Bearbeitung ihrer Anliegen warten.
  • Für die User mit dem Feature „Generiere mir meine persönliche Seitendarstellung!“ dauert die Antwortzeit entsprechend länger, das ist aber eine Folge des Problems der stärkeren Serverinanspruchnahme.
  • Normalerweise wird der Inhaltsbereich einer Seite nach Abspeicherung nur ein einziges Mal generiert, im Cache gespeichert, und jeder weitere Wunsch dies zu lesen wird aus dem Cache bedient. Das geht erheblich schneller als komplett neu generieren zu müssen. Der Inhaltsbereich wird dann nur noch in die aktuelle Skin eingepasst (die für einschlägige Konstellationen als Portalrahmen ebenfalls fertig im Cache hinterlegt ist) und um die persönliche Zeile angemeldeter User ergänzt, usw.
  • Die Methode, einen Seiteninhalt individuell aus dem Wikitext generieren zu müssen, wird ansonsten nur bei der Vorschau während der Quelltextbearbeitung verwendet.
VG --PerfektesChaos 21:26, 19. Sep. 2021 (CEST)
Schade, wieder ein von mir gern und häufig genutztes Feature entsorgt. Mal sehen, wann die Möglichkeit abgeschafft wird, Artikel zu schreiben - dieser Ballast führt ja auch nur zu Performanceproblemen ... Verärgert, -- Achim Raschka (Diskussion) 19:39, 17. Sep. 2021 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup_Diskussion:Projektneuheiten/Archiv/2021&oldid=222050529“