Wikipedia:Technik/Skin/MediaWiki/Änderungen/Archiv/2021

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:Technik/Skin/MediaWiki/Änderungen/Archiv/2021#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Technik/Skin/MediaWiki/%C3%84nderungen/Archiv/2021#Thema_1

markAdmins

Hallo, markAdmins kriegt es irgendwie nicht hin, mich mit Omb und SG-A zu kennzeichnen. Andere Kombinationen wie Omb/WD-A und Omb/Com-A funktionieren hingegen. Kann das jemand reparieren? --Ameisenigel (Diskussion) ^LI 23:23, 29. Jan. 2021 (CET)

Ich habe das Skript angepasst, schau mal bitte bzgl. unerwünschter Nebeneffekte. Ich nutze es normalerweise nicht. -- hgzh 16:57, 30. Jan. 2021 (CET)

Besten Dank, schaut soweit gut aus. --Ameisenigel (Diskussion) ^LI 17:44, 30. Jan. 2021 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 12:35, 13. Feb. 2021 (CET)

Umzug Suchhilfe -> Auskunft

Bitte auf diesen Seiten "Suchhilfe" durch "Auskunft" ersetzen gemäß Wikipedia:Löschkandidaten/2._März_2021 #Wikipedia:Suchhilfe (erl.,_wird_archiviert). Gruß --FriedhelmW (Diskussion) 11:23, 10. Apr. 2021 (CEST)

Erledigt. -- hgzh 13:05, 10. Apr. 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 13:05, 10. Apr. 2021 (CEST)

About deploying StructuredCategories in German Wikipedia

Dear all,

I have recently developed a new tool that returns a structured description of a given Wikipedia Category based on the Wikidata Statements involving its direct members. This tool is called StructuredCategories and is described at d:Wikidata:Structured Categories. I ask this tool can be deployed in German Wikipedia and added to Preferences as a Gadget. The source code of this JavaScript tool is available at meta:MediaWiki:Gadget-StructuredCategories.js.

From a technical point of view, the deployment of StructedCategories includes:

• Pasting this code mw.loader.load('//meta.wikimedia.org/w/index.php?title=MediaWiki:Gadget-StructuredCategories.js&action=raw&ctype=text/javascript'); in MediaWiki:Gadget-StructuredCategories.js.
• Writing a translation of StructuredCategories: provide a structured description of a category based on Wikidata statements involving its direct members in MediaWiki:Gadget-StructuredCategories.
• Adding the tool as a Gadget.

I ask if this is possible. — Csisc (Diskussion) 23:49, 20. Apr. 2021 (CEST)

In this wiki every (registered) user is free to transclude whatever they want via mw.loader.load().

We do not maintain nor recommend any external gadget, even not those created by users within this project.

We do not take any responsibility on JavaScript written by anyone and we do not support that. As a matter of fact, the last complex gadget has been introduced in 2010.

We have absolutely no human resources to give support to external codes. We do not have sufficient staff to maintain our own business.

Therefore it is a private issue of people who like to execute your gadget to do so on their own risk.

Greetings --PerfektesChaos 00:03, 21. Apr. 2021 (CEST)

PerfektesChaos: I see. Thank you. --Csisc (Diskussion) 03:43, 21. Apr. 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 15:40, 21. Apr. 2021 (CEST)

MediaWiki:Gadget-wikidataInfoboxExport.js

Hallo allerseits. Ich bin nicht sicher, ob ich hier richtig bin: Ich bin auf die Seite MediaWiki:Gadget-wikidataInfoboxExport.js gestoßen, dabei handelt es sich um eine veraltete Version von ru:MediaWiki:Gadget-wikidataInfoboxExport.js. Da das Skript anscheinend nichtmals lokalisiert ist (die ganzen Kommentare sind auf Russisch), halte ich die Seite für ziemlich überflüssig. Genutzt wird sie anscheinend ebenfalls nicht. Mag die jemand entweder auf den aktuellen Stand bringen oder gleich direkt löschen, da ohnehin ungenutzt und ohne Mehrwert im Vergleich zur Einbindung aus einem anderen Projekt? --Ameisenigel (Diskussion) ^LI 17:00, 23. Apr. 2021 (CEST)

+1

Programmcode kann aus jeder URL jedes Wiki und jedes Webserver geladen werden; das braucht hier nicht lokal vorzuliegen.

Ein lokaler Code wäre allenfalls für eine lokale Konfiguration und Nachladen des zentral gepflegten Codes erforderlich.

Und dann müsste es dokumentiert sein und in der Definition den Benutzies angeboten werden. Isnich.

Wurde offenkundig ohne jede Absprache in der Vor-BOA-Ära von einem sysop mal eben so kopiert, ohne zu verstehen worum es geht.

Verursacht nur Wartungs- und Pflegeaufwand.

@Ameisenigel: Du bist hier so richtig wie es nicht besser geht.

VG --PerfektesChaos 18:12, 23. Apr. 2021 (CEST)

Gelöscht. -- hgzh 10:47, 26. Apr. 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Ameisenigel (Diskussion) ^LI 10:24, 29. Apr. 2021 (CEST)

Platzierung des Play-Buttons bei eingebetteten Videos

Benutzer:Peacelovedeathmetal2 wünscht sich hier eine Änderung am CSS. Ich zitiere ihn/sie einfach mal komplett: "Hallo zusammen, in der englischsprachigen Wikipedia ist der Abspielknopf auf Video-Thumbnails in der Ecke platziert sodass man das Motiv viel besser erkennen kann als in der deutschsprachigen, bei der er direkt in der Mitte platziert ist. Könnte man diese Einstellung hier übernehmen? Hier ist ein Beispiel: Veränderliche Krabbenspinne / en:Misumena vatia".

Klingt sinnvoll, und wäre technisch auch einfach machbar durch eine Erweiterung der common.css analog zu enwiki:

/* Move 'play' button of video player to bottom left corner */
.PopUpMediaTransform a .play-btn-large {
	margin: 0;
	top: auto;
	right: auto;
	bottom: 0;
	left: 0;
}

Meinungen dazu? --Tkarcher (Diskussion) 10:04, 8. Jun. 2021 (CEST)

Ist auch auf WP:VV aufgepoppt.

CSS-technisch wohl nicht riskant.

Grundsätzlich sind aber Nutzen und Nachteile abzuwägen:

• Jedes lokale CSS wird auf jeder Seite, jeder Spezialseite, in jeder Diskussion angewendet. Solche Video-Einbindungen würde ich jedoch nur in < 0,001 % der aufgerufenen Wiki-Seiten vermuten.
• Jede zusätzliche CSS-Regel verlängert die Zeit bis zum Anwenden aller Selektoren auf die möglicherweise umfangreiche Seite um eine Tausendstelsekunde oder was. Je mehr Regeln, die ins Leere gehen, desto länger dauert es bis der Seitenaufbau abgeschlossen wurde.
• Jede zusätzliche lokale Regel erhöht langjährig unseren Pflege- und Betreuungsaufwand; eigentlich geht das Ziel dahin, unser lokales CSS auf nahe Null zu bekommen.
• Was genau bringt jetzt die Änderung? Ich bin es von etlichen Mediatheken und Video-Angeboten gewohnt, dass mittendrin so ein Play-Pfeil ist.
  • Wenn der in die Ecke rutscht, kann möglicherweise mehr vom Miniatur-Standbild erkannt werden, das als Titel-Schnappschuss dient. Sofern auf dem was Sinnvolles zu sehen wäre. Will ich das erkennen müssen?
  • Benutzies, die an mittige Play-Pfeile gewohnt wären, könnten diesen und damit die Video-Eigenschaft übersehen, wenn der zu klein zu sehr in die Ecke rutscht. Der Grund, warum man einen großen Kreis mit Pfeil mittig über die halbe Bildhöhe setzt, ist, dass auch die letzten mitbekommen, dass sie hier ein Video starten können. Daher der Name btn-large.

Warum müssen wir das lokal projektweit lösen?

• Wenn das Design so gut ist, dann kann es auch in der globalen Anwendung PopUpMediaTransform definiert werden, und dann würde dieses CSS dann und nur dann in Seiten wirksam, in denen es auch eine Video-Einbindung gibt, und die anderen 99,999 % Seiten würden nicht belästigt.
• Jeder (vorrangig angemeldete) User ist frei, sich in Browser oder Wiki-Profil private CSS-Regeln zu definieren und dann damit zu leben.

VG --PerfektesChaos 10:41, 8. Jun. 2021 (CEST)

+1 Ich bin auch skeptisch gegenüber einer eigenständigen diesbezüglichen Regelung auf de-WP. --Chewbacca2205 (D) 11:09, 8. Jun. 2021 (CEST)

Beim neuen Videoplayer, der derzeit Betafunktion ist, aber wohl über kurz oder lang Standardfunktion wird, ist der Play-Button oben links. Meiner Meinung nach kann man bis dahin abwarten. -- hgzh 11:21, 8. Jun. 2021 (CEST)

Vielen Dank, das war schnell! Gibt es denn diese Regel in der englischsprachigen Wikipedia?--Peacelovedeathmetal2 (Diskussion) 12:35, 8. Jun. 2021 (CEST)

Ja, in der englischen Wikipedia wurde das so umgesetzt, in en:MediaWiki:Common.css#L-1157. Die Argumente von PerfektesChaos und Hgzh erscheinen mir aber schlüssig: Wenn das wirklich Allgemein gewünscht wäre, sollte man das am Besten projektweit umsetzen, und nicht nur in einer Sprache (wobei ich mir gerade nicht sicher bin, wo man das einkippen müsste. Phabricator?). Und wenn ohnehin bald ein anderer Player kommen wird, könnte man auch noch abwarten, wie es bei dem dann aussehen wird. --Tkarcher (Diskussion) 13:22, 8. Jun. 2021 (CEST)

Perfekt, genau den Link habe ich gebraucht. Ich gebe Dir völlig recht, so dringend ist es ja wirklich nicht. Danke für die Erklärungen allerseits.--Peacelovedeathmetal2 (Diskussion) 13:48, 8. Jun. 2021 (CEST)

@Peacelovedeathmetal2: wenn du den Play-Button nur für dich dennoch schon verschieben möchtest, kannst du den obigen Code auf Benutzer:Peacelovedeathmetal2/common.css kopieren, dann sollte er bei dir wirksam werden. -- hgzh 14:09, 8. Jun. 2021 (CEST)

Toller Tipp, danke! Eigentlich wollte ich es für alle Nutzer aber das werde ich auf jeden Fall probieren. Edit: Funktioniert! Echt ne Sache von Sekunden:)--Peacelovedeathmetal2 (Diskussion) 14:20, 8. Jun. 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Chewbacca2205 (D) 18:44, 8. Jun. 2021 (CEST)

MediaWiki:Monobook.css Hotfix Kleinschreibung

Gemeldet in Phabricator
Task T97892

Notfallreparatur der MonoBook-Beschriftungen durch BOA und Jon (WMF).

• Diese Software-Änderung kann niemals getestet worden sein; sie war freihändig nach Gefühl und Wellenschlag im Vertrauen auf die eigene Unfehlbarkeit durch den WMF-Beschäftigten ausgeführt worden.
• Memo: Hotfix entfernen nach Reparatur durch WMF.

VG --PerfektesChaos 11:12, 15. Aug. 2021 (CEST)

status quo ante.

:Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 16:47, 20. Aug. 2021 (CEST)

Link "Buch erstellen" entfernen

Liebe BOA, ausgelöst durch die Adminanfrage schlage ich vor, in der Desktop-Sidebar links den Link "Buch erstellen" zu entfernen. Der Renderer unter Spezial:Buch ist schon seit Jahren (AFAIK seit 2017) deaktiviert. Sollte es irgendwann wieder möglich werden, Bücher zu erzeugen, könnte die Änderung ja rückgängig gemacht werden. Gruss, --MBq ^Disk 13:38, 10. Sep. 2021 (CEST)

Wenn dem so ist, dann besser ausdünnen.

• Sowieso eine viel zu willkürliche Auswahl aus Tausenden vorstellbarer Direktverlinkungen, und für das breite Publikum nicht gezielt nach deren Wünschen oder unserem Aufdrängen wichtigster Projektseiten ausgewählt. Gibt die Vorstellungswelt von vor zwei Jahrzehnten wieder.

Generell ist es nicht mehr allgemeiner Bedarf, sich das Internet und die dynamische Wikipedia auf Papier auszudrucken und ins Regal zu stellen; das mag in seltenen Fällen mal aus juristischen Gründen oder als Geburtstagsgeschenk für Ururopi benötigt werden.

BOA-Rechte sind nicht erforderlich, weil einfacher Text; jedoch ist diese Seite hier ein geeignetes Forum, um derartige Absichten zu erörtern.

VG --PerfektesChaos 16:08, 10. Sep. 2021 (CEST)

Ich wüsste auf die Schnelle gar nicht, welche Seite das ist, MediaWiki:Sidebar schon mal nicht. Wenn das eh komplett nicht mehr funktioniert, wäre der Beste weg vielleicht, die komplette Collection-Erweiterung als Grundlage der Buchfunktion abzustellen. -- hgzh 16:35, 10. Sep. 2021 (CEST)

Siehe mw:Manual:Interface/Sidebar#Advanced customization, wir könnten das hier mittels CSS oder JS ausblenden lassen oder aber auf Phabricator beantragen. Die enWP hat das in phab:T241683 (Diskussion) gemacht. Würde ich so übernehmen wollen. --XanonymusX (Diskussion) 17:24, 10. Sep. 2021 (CEST)

Ah ja, CSS ausblenden wäre der einfache und kurze Dienstweg.

• Dann also doch BOA.

Die Sidebar-Liste ist dann offenkundig statisch in den Skin-PHP hinterlegt.

Es gibt eine kleine und eine große Lösung:

• #p-coll-print_export komplett und übersichtlich
• Einzeln:
  • #coll-download-as-rl
  • #coll-create_a_book

Mindestens die PDF-Generiererei, aber auch die „Buch“-Zusammenstellungen sind mir seit bald einem Jahrzehnt als ewiger Sanierungsfall bekannt.

• Es gibt keine aktiven Maintainer.
• Das Feature ist eigentlich obsolet, entsprang dem Spirit der Jahrtausendwende.
• Es gibt deshalb auch keine Ressourcen, Budgets, Prioritäten.

Perspektivisch würde ich erwarten, dass dies global aus allen Skins entfernt wird, wenn es denn eh nicht mehr funktioniert, und bis dahin etwas CSS opfern und auf Phab verzichten wollen.

VG --PerfektesChaos 17:40, 10. Sep. 2021 (CEST)

Den ganzen Block würde ich nicht entfernen wollen, immerhin wurde die PDF-Funktion mittlerweile extra erneuert (und das könnten wir ohne breitere Diskussion wohl auch nicht tun, fällt zu sehr auf). Die gesamte Sidebar ist in der Mobilversion überhaupt nicht und im neuen Vector nur ausgeklappt zu sehen, verliert also sowieso an Bedeutung; da in eine Neuordnung Energie zu investieren, ist es nicht wert.

Ich würde also vorschlagen, nur #coll-create_a_book über MediaWiki:Common.css auszublenden. Dann sehen wir auch, ob womöglich jemand den Link vermisst. Gruß --XanonymusX (Diskussion) 19:22, 10. Sep. 2021 (CEST)

Die PDF-Ausgabe wird von mw:Extension:ElectronPdfService bereitgestellt, sollte also auch ohne Buchfunktion noch gehen. Von mir aus können wir aber auch erst per CSS tätig werden. -- hgzh 15:33, 11. Sep. 2021 (CEST)

Habe den Link jetzt ausgeblendet. --XanonymusX (Diskussion) 18:07, 22. Sep. 2021 (CEST)

Vielen Dank! --MBq ^Disk 18:19, 22. Sep. 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: MBq ^Disk 18:19, 22. Sep. 2021 (CEST)

Cat-a-lot

Gibt es bisher meines Wissens nur bei Commons, siehe Commons:Help:Gadget-Cat-a-lot/de. Das Tool wäre aber auch hier nützlich beim Neuordnen/Verschieben von Artikeln zwischen unterschiedlichen Kategorien und beim Hinzufügen von Kategorien zu Suchergebnissen.
Ein aktuelles Beispiel wäre hier die noch in Arbeit befindliche Neuordnung der Mineralkategorien. Beispielsweise müssen die noch in der Kategorie:Mineral befindlichen Artikel auf die neuen Kategorien „Mineralgruppe“, „Anerkanntes Mineral“‎, „Grandfathered Mineral‎“ usw. und Cat-a-lot würde diese Arbeit wesentlich erleichtern. -- Ra'ike _Disk. ^P:MIN 10:21, 15. Nov. 2021 (CET)

Du kannst jedes Skript, das du gerne benutzen möchtest, für dich persönlich wann und wo immer du möchtest aktivieren: commons:Help:Gadget-Cat-a-lot/de #Als dein Benutzer-Helferlein

Eine Bereitstellung als Community-gepflegtes Gadget erfolgt jedoch nur, wenn Tausende von Benutzies dieses voraussichtlich benutzen würden; oder aber in Sonderfällen wie zur Verbesserung der Barrierefreiheit bei körperlichen oder geistigen Einschränkungen.

In jedem Fall bedürfte dies einer hiesigen ausgiebigen deutschsprachigen Dokumentation und Anleitung für Anwender und Maintainer, die in Teilen dann auf Commons/de verweisen mag. Damit kannst du ja schon mal anfangen.

Im weiteren Verlauf ist dann auch hierzuwiki die kompetente Betreuung von Rückfragen zur inhaltlichen Anwendung zu leisten.

Aber du kannst gern all das in deinem BNR als Service bereitstellen; eines Community-gepflegten Gadget bedarf es dazu nicht.

VG --PerfektesChaos 16:01, 15. Nov. 2021 (CET)

*seufz* Na, Du machst mir Spaß. Ich wäre wohl kaum hierher gekommen, wenn das mit dem Einbinden/Aktivieren des Tools für mich so einfach wäre. Leider fehlen mir dafür ein paar technische Kenntnisse :-(

Die Kurzbeschreibung auf Commons ist auch nur wenig hilfreich und eher unverständlich. Da steht nur, dass man es manuell in den „Benutzer-Einstellungen“ unter JavaScript mit folgendem Code installieren könne, aber in den eigenen Einstellungen findet man dazu natürlich nichts. Da sich keine weiteren Erklärungen finden, kann ich nur vermuten, dass ich die blau unterlegte Kopiervorlage in meine monobook.js übernehmen muss. Wenn ja, stellt sich aber die Frage, kann ich das wirklich 1:1 übernehmen oder muss ich da für mich noch Anpassungen vornehmen, damit es für mich in de-WP fehlerfrei funktioniert.

Ehrlich gesagt, hatte ich da schon auf ein bisschen mehr Hilfe von den hiesigen Programmierspezies gehofft. Gruß -- Ra'ike _Disk. ^P:MIN 18:57, 15. Nov. 2021 (CET)

• Du bist hier vorstellig geworden mit dem Anliegen, für alle Benutzies ein Feature bereitzustellen und durch die Community zu dokumentieren, zu pflegen und eine Anlaufstelle zu betreuen.
• Eine Frage, wie irgendwas für sich persönlich hinzubekommen wäre, ist auf WP:TWS besser aufgehoben. In diesem konkreten Fall hätten dir aber auch viele Mitleser auf WP:FZW helfen können.
• Und ja, die entsprechenden Code-Zeilen, die im von mir verlinkten Abschnitt benannt sind, wären in eine persönliche JavaScript-Seite deiner Wahl zu kopieren; etwa common.js (gibt noch weitere Möglichkeiten).
• Wikipedia:Technik/Skin/Einstellungen erklärt genauer, was alles machbar wäre. Hilfe:Einstellungen #Benutzeroberfläche verweist darauf, und auf diese wird von der von dir zitierten Spezial:Einstellungen verlinkt.
• „kann ich das wirklich 1:1 übernehmen oder muss ich da für mich noch Anpassungen vornehmen“ – wir hier können auch nur die Commons-Doku lesen, und die behauptet, dass zunächst nicht mehr erforderlich sei. Ob das stimmt kann diese Seite für die Community-gepflegte Konfiguration für alle Benutzies nicht beantworten; da müsstest du ein Forum aufmachen von Leutchen, die sich mit genau diesem Werkzeug näher auskennen.
  • commons:Help:Gadget-Cat-a-lot/de #Mehr lokale Konfiguration erzählt noch irgendwas, das aber nur Anwender des Werkzeugs und derartiger Projektorganisation beurteilen könnten.

VG --PerfektesChaos 19:30, 15. Nov. 2021 (CET)

Sorry, dann habe ich diese Seite wohl ziemlich missverstanden. Ich bin bei den Einstellungen#Helferlein über den Link Weitere Helferlein vorschlagen … hierher geleitet worden und nahm entsprechend an, es wäre die richtige Seite für genau das: Eine Seite, um weitere Helferlein vorzuschlagen. Ich war hier jedenfalls nicht vorstellig geworden, wie Du es nennst, um selbst ein Feature bereitzustellen, sondern dachte, hier mitlesende Spezies, die Spaß am Programmieren haben, würden sich den Vorschlag ansehen, um sich dann um Relevanzprüfung und ggf. Programmierung bzw. Übernahme zu kümmern.

Mein Umschwenken, das Gadget Cat-a-lot für mich persönlich zu nutzen, folgte nur, weil Deine erste Antwort für mich so klang, als wäre das nix für die Allgemeinheit, aber ich könne es ja in meinem BNR für mich nutzen. Ok, danke soweit. Ich werde dann mal versuchen, das Feature entsprechend Deiner zweiten Erklärung in meiner common.js einzubauen und sehen, wass passiert. Gruß -- Ra'ike _Disk. ^P:MIN 15:57, 20. Nov. 2021 (CET)

@Ra'ike:

• Auf diesem Weg sind seit 10, 12 Jahren keine Gadgets mehr erfolgreich vorgeschlagen worden.
• Wenn es wirklich das neue Zauberwerkzeug geben sollte, das für Tausende von Benutzies relevant ist, dann würde das auf dieser Seite tätige Personal dies über FZW oder A/A oder durch eigene Entwicklungen mitbekommen.
• Generell sind eigentlich schon seit einem Jahrzehnt praktisch keine fundamental neuen JavaScript-Gadgets mehr vorgeschlagen worden.
• Die fragliche Einstellungs-Seite fordert aber dazu auf, diese allen Benutzies angebotene Auflistung von Gadgets um weitere in der Auflistung bisher noch nicht aufgezählte Community-gepflegte Gadgets zu erweitern und diese genauso auf der Einstellungs-Seite zu präsentieren.
• Du kannst selbst diesen verwirrenden Satz rausnehmen; steht auf MediaWiki:gadgets-prefstext.
• Stammt noch aus den Nuller-Jahren; da wollte man wohl auf Teufel komm raus jedes Werkzeug anbieten, das man irgendwie bekommen könnte. Nur taugten die oft wenig, waren mangelhaft dokumentiert, und niemand konnte die pflegen. Ist wie mit der Sucht nach neuen Artikeln; früher wollte man so viele angefangene angelegte Artikel ranschaffen wie irgend möglich, damit die ersten 100.000 voll werden. Heutzutage sind wir da auch wählerischer als 2004.
• Auf WP:HX stehen die benutzergepflegten Gebilde.

Nebenbei bemerkt finde ich es erstaunlich, dass du zwar BOA bist und den Schutz von JavaScript gegen eingeschleuste Schadsoftware verantwortlich überwachen sollst, aber weder weißt was mit der Einführung eines Community-gepflegten Gadgets verbunden ist noch einige Zeilen JavaScript in deinen BNR kopieren kannst.

Hoffe, dein Camelot hat hier eine nette Tafelrunde gefunden --PerfektesChaos 18:57, 27. Nov. 2021 (CET)

@PerfektesChaos: Um letzteres mal gleich zuerst zu beantworten: Was meine BOA-Rechte angeht, unterliegst Du einem Irrglauben! Alle Oversighter haben diese Rechte, aber sie nutzen sie nur passiv, d.h. wenn sie im Rahmen der Oversight-Richtlinie tätig werden müssen. Entsprechend werden diese Rechte auch wieder abgegeben, wenn einer von uns nicht wiedergewählt wird oder freiwillig als OS zurücktritt. Ausnahme ist hier nur Doc Taxon, der sie davon unabhängig für sich beantragt und erhalten hat.

Bezüglich des Gadgets Cat-a-lot werde ich vorerst keine weiteren Versuche unternehmen, es für die Allgemeinheit vorzuschlagen. Mir reicht schon Deine negativ konnotierte, ablehnende Haltung hier, um mich intensiver mit dem offensichtlich sehr umständlichen Prozedere zu befassen, zumal mir dafür eh die Zeit fehlt.

Für Deinen Tipp, das Gadjet in meine common.js zu packen, muss ich mich allerdings bedanken. Es hat tatsächlich sehr gut funktioniert und ist mir beim Umsortieren der Minerale eine große Hilfe, siehe auch meine diesbezüglichen Beiträge. Ich habe den erfolgreichen Test auch gleich weitergemeldet und vielleicht finden ja doch noch andere Gefallen an diesem nützlichen Tool. -- Ra'ike _Disk. ^P:MIN 20:04, 27. Nov. 2021 (CET) P.S.: Deine Spitze mit "Camelot und der netten Tafelrunde" empfinde ich übrigens als geradezu abstoßend arrogant und übergriffig, zumal Du sowas bei Deinen bekannten und anerkannten Programmierfähigkeiten absolut nicht nötig hast:-(

Archivierung dieses Abschnittes wurde gewünscht von: Ra'ike _Disk. ^P:MIN 20:04, 27. Nov. 2021 (CET)

Inhaltsmodell einer Seite

Benutzer:Vollbracht/styles.css bitte mit Spezial:ChangeContentModel auf ’bereinigtes CSS’ setzen, siehe Anfrage [1]. Danke + Gruss –MBq ^Disk 10:57, 20. Dez. 2021 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 11:43, 20. Dez. 2021 (CET)

Menütext übersetzen

Hallo, ich wurde von WP:FZW hier her geschickt. Ich habe oben ein Menü (aus Wikipedia:Helferlein/Toolserver-Integration), dessen Einträge beim mouseover Englisch sind. Kann man die übersetzen? Das müßte ein (Oberflächen-)Admin machen (Screenshot hier).--Ceweran (Diskussion) 01:30, 9. Jan. 2021 (CET)

Wir können hier nichts tun, denn der Code des Gadgets liegt auf meta:MediaWiki:Gadget-MoreMenu.js – dort sind Lokalisierungen vorhanden, aber anscheinend werden sie nicht wirksam. Autor des Skripts ist meta:User:MusikAnimal. Gruß, -- hgzh 14:21, 9. Jan. 2021 (CET)

+1

Nach kursorischer Durchsicht wäre für diese Tooltips wohl jeweils ein weiteres Textfragment erforderlich, das durch Anhängen von -desc an den sichtbaren Linktext gebildet wird, und das weitere Hinweise spezifizieren mag.

Wäre eine Idee für den Gadget-Maintainer, in allen oder nicht-englischen Versionen den Tooltip noch sicherer zu defaulten als mit den bisherigen Mitteln vorgesehen; also Tooltip identisch Linktext wenn nichts genaueres weiß man nicht.

Im Übrigen könntest du den Gadget-Maintainer darauf hinweisen, dass es Sprachvarianten in gleicher Schrift mit geringer Abweichung gibt (bei uns de-at und de-ch, dazu de-formal, bei ihm vielleicht en-ca en-us en-gb en-uk en-au und ansonsten neben nl- auch pt-br). Falls Bindestrich enthalten und keine exakte Spezifikation (gäbe auch Varianten in anderen Schriften), dann Basis-Sprachcode verwenden.

VG --PerfektesChaos 14:45, 9. Jan. 2021 (CET)

Ich habe den User meta:User:MusikAnimal angeschrieben und arbeite an der Übersetzung. Für ein paar Begriffe suche ich noch auf toolforge nach dem richtigen Kontext, aber ich orientiere mich an bestehenden Übersetzungen. Ist also in Arbeit und hier erl. --Ceweran (Diskussion) 21:32, 18. Jan. 2021 (CET)

Update: Ich habe diese und andere Bausteine übersetzt und der User MusicAnimal hat sie eingefügt. Schaut bitte mal, ob das so weit passt. Vielen Dank.--Ceweran (Diskussion) 20:10, 26. Jan. 2021 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 21:46, 23. Dez. 2021 (CET)

nowiki in Benutzerskripte wegen <source>

In Kategorie:Wikipedia:Seite mit Syntaxhervorhebungsfehlern schlagen .js-Seiten auf, die vermutlich veraltetes <source> enthalten.

• Diese müssten jeweils ergänzt werden um:
  • Nach einem ggf. einleitenden Kommentarblock Zeile mit:
    // <nowiki>
  • Als letzte Zeile anfügen:
    // </nowiki>
  • Oder ggf. enger um die fragliche Stelle herum.
• Kommentare in Skripte einzufügen zählt nicht zu den funktionalen Veränderungen.

Besten Dank im Voraus --PerfektesChaos 17:54, 7. Apr. 2021 (CEST)

Stammt wohl aus einer Zeit, als Skriptseiten noch kein automatisches Syntaxhighlight hatten. insource:/\<source/ für weitere Kandidaten, wird bei Langeweile stückweise weggeputzt. -- hgzh 19:12, 7. Apr. 2021 (CEST)

Ach du Schreck. Das muss ja schon ein Jahrzehnt her sein.

• Natürlich können auch solche Kommentarzeilen ohne Beeinträchtigung der Funktionalität aus Skriptseiten eliminiert werden.
• Der Hack funktioniert schon seit Ewigkeiten nicht mehr, ist auch nicht mehr erforderlich, und löst im besten Fall die Wartungskat aus.

Das Umschließen des wirksamen Programmcodes mit // <nowiki> kann aber auch nicht schaden.

• Der JS-Code wird ja zusätzlich als Wikitext geparsed.
• Weil da öfters mal Kategorien, Vorlagensyntax usw. zum Einfügen in Quelltext drinstehen, löst das „Links auf diese Seite“ und wirre Kategorisierungen aus.
• Ich ahne schon, dass wir eines Tages dann auch noch Linter-Fehler für sowas am Hals haben werden.

VG --PerfektesChaos 17:36, 8. Apr. 2021 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 21:46, 23. Dez. 2021 (CET)

Datatable

Gemeldet in Phabricator
Task T287997

Anlässlich phab:T287997: Was machen wir mit den über 2.000 Seiten, die bei uns mw-datatable verwenden? Auch wenn uns niemand gefragt hat, wird offenbar erwartet, dass wir das Problem jetzt selbst lösen. Ich hätte die Funktionalität ganz gerne rasch wieder. Gruß --XanonymusX (Diskussion) 00:30, 15. Aug. 2021 (CEST)

Auf gar keinen Fall werden wir 2000 Artikel anfassen, egal wie.

MW muss die unangekündigte Löschung zurücknehmen, ggf. durch breiten Druck bei der WMF.

Der Bursche ist zurzeit bei einer allgemeinen Aufräumaktion, und wir werden in den kommenden Wochen und Monaten noch viel mehr Spaß mit ihm haben.

• Allein in der laufenden Woche hat er vier Böcke geschossen.
• Er schmeißt einfach alles CSS usw. raus, das er für überflüssig hält Ohne Testen, ohne über die Folgen außerhalb seines geistigen Horizonts nachzudenken, was per definitionem auch nicht möglich ist.
• Erklärtermaßen ist ihm völlig egal, was das für Auswirkungen auf die 1000 Wikis mit ihrem Seitenbestand hätte. Das ist ja dann deren Problem.
• Für ihn ist nur wichtig, nur noch ganz wenig CSS+PHP gemäß seinem Masterplan und seiner Agenda zu haben, und dass er möglichst wenig Arbeit mit seiner Löschaktion hätte.

Grundsätzlich ist es sinnvoll, das historisch immer mehr zusammengestückelte CSS nach zwei Jahrzehnten zu ordnen, zu strukturieren, effizienter an Desktop- oder Mobil-Seiten auszuliefern usw.

• Die Veränderungen müssen aber idealerweise in einer Weise erfolgen, dass die Bestandswikis davon überhaupt nichts merken.
• Wo aus technischen oder organisatorischen Gründen eine langfristige Fortführung nicht mehr sinnvoll ist, etwa weil es nur wenige Verwendungen als Dublette zu einer mittlerweile vorhandenen besseren Lösung gibt, muss das odnungsgemäß migrieren.
• Heißt: Wenn Veränderung, dann breit kommuniziert vorher ankündigen, Gründe und Notwendigkeit erklären, Alternative erklären und Wege aufzeigen, wie Projekte ohne technische Kenntnisse die Problemfälle auffinden können (ggf. Wartungskategorie durch System) und das ggf. massenhaft ändern können, ohne Botbetreiber zu haben.
• Das ist ihm aber alles viel zu anstrengend; er knallt das einfach unangekündigt weg und basta. Es hatte vorher noch nicht einmal eine Task dazu gegeben, es war niemals erörtert worden.

Wir machen hier nix, erhöhen ggf. WMF-weit den Druck zum Rollback, und auf gar keinen Fall bietet jemand auf Phab lokale Behelfslösungen für große kompetente Wikis an, während die kleinen abgehängt werden.

VG --PerfektesChaos 11:10, 15. Aug. 2021 (CEST)

Ich schätze Jons Arbeit ja im Allgemeinen sehr, aber die Änderungen der letzten Tage waren wirklich maximal mies gemanagt (die Alliteration sei mir erlaubt). Und die letzten „Vorschläge“ von Izno halte ich auch für völlig realitätsfern. Da es sich letztlich nur um eine Designfrage handelt, können wir wohl abwarten, bis die das wieder zurückändern; ansonsten bleibt immer noch Common.css. Gruß—XanonymusX (Diskussion) 12:31, 15. Aug. 2021 (CEST)

So, wie weiter? Vonseiten der WMF wird das offensichtlich bewusst ausgesessen, also bleibt uns eigentlich nur der Weg über Common.css, wenn wir die Funktion wiederhaben wollen. --XanonymusX (Diskussion) 17:27, 10. Sep. 2021 (CEST)

Die Resonanz auf die Abschaltung war ja kaum vorhanden, was meiner Meinung nach nicht dafür spricht, dass das wirklich benötigt wird. -- hgzh 15:35, 11. Sep. 2021 (CEST)

Ich brauche sie jedenfalls, aber weiß nicht, wie gewichtig das Argument ist. ;) —XanonymusX (Diskussion) 16:13, 11. Sep. 2021 (CEST)

So, ich würde dann demnächst folgende Zeilen in MediaWiki:Common.css einfügen (direkt nach der aktuellen Zebra-Definition, ab Z140):

table.wikitable.mw-datatable tr:hover td {
    background-color: #eaf3ff;
}

–XanonymusX (Diskussion) 21:49, 1. Dez. 2021 (CET)

Ich sehe die unbedingte Notwendigkeit dafür zwar nach wie vor nicht (du wirst das doch sicher in Vorlagen gekapselt nutzen), wäre aber einverstanden, wenn wir dafür zeitnah prettytable dort rauskicken ;) -- hgzh 08:22, 2. Dez. 2021 (CET)

Die erwähnten 2000 Seiten sollten keine Regel für mehrere 10 Millionen Wiki-Seiten plus dynamisch generierte nach sich ziehen, sondern per TemplateStyles gelöst werden.

• Vielleicht liest ja ein Botbetreiber mit, der das im ANR einmalig pro Artikel vor der ersten einschlägigen Tabelle einfügen könnte.

Mir schwebt eine nichtstuende Vorlage:Tabellenstile vor, die gegen ihre Einbindung protestiert und nur CSS produziert.

Und weil prettytable angesprochen wurde: Die könnte von der mitversorgt werden.

• Da habe ich, einige Jahre nach Eliminierung aus dem ANR, sowieso perspektivisch Attentate vor.

Demnächst mehr Details --PerfektesChaos 10:23, 2. Dez. 2021 (CET)

Sodele:

• Vorlage:Tabellenstile/styles
• @Admin:
  1. edit=3/4 move=sysop für Vorlage:Tabellenstile/styles.css
  2. Erstellungsdatum von Vorlage:prettytable für die Geschichtsbücher in Vorlage:Tabellenstile/styles vermerken
• @Bots:
  • ANR eintragen wer wo möcht
• @Vorlagen-Maintainer?
  • Manuell einfügen wer’s braucht
• @Hilfeseite
  • Mache ich wenn ich Zeit habe.

VG --PerfektesChaos 20:29, 2. Dez. 2021 (CET)

Also in 2028 Artikeln wäre einzufügen? Wo? Am Anfang des Artikels? Vor der ersten solchen Tabelle? Vor jeder Tabelle, also ev. mehrfach? Am Ende des Artikels? --Wurgl (Diskussion) 22:17, 2. Dez. 2021 (CET)

„der das im ANR einmalig pro Artikel vor der ersten einschlägigen Tabelle einfügen könnte“

• Weil, dann wird der Zusamenhag zwischen Tabellenstile und der betreffenden Tabelle für die Autoren deutlich, wenn das in der Quelltextzeile unmittelbar davor steht.

Bot-Start aber erst am Wochenende; Reaktionen hier abwarten.

Danke im Voraus --PerfektesChaos 22:41, 2. Dez. 2021 (CET)

War es nicht bislang Konsens, dass TemplateStyles-Definitionen nicht direkt im ANR stehen dürfen? Eigentlich dachte ich, das würde auf den Einbau von {{Tabellenstile}} hinauslaufen. --XanonymusX (Diskussion) 22:48, 2. Dez. 2021 (CET)

Das war bislang auch mein Kenntnisstand, insofern halte ich das für einen Paradigmenwechsel, den man besser nicht mal eben so übers Wochenende herbeiführt. Derartige „Importvorlagen“ sind in der en.wp üblich, hier bisher nicht.

prettytable hat keine ANR-Vorkommen mehr, ich bin dagegen, dieses tote Pferd noch im ANR mit Vorlagensupport weiterzureiten und sich neue Vorkommen einzuschleppen. Davon abgesehen fände ich als Namen Erweiterte Tabellenstile passender, denn die 0815-wikitable, die Standard sein sollte, gibt's frei Haus.

Gruß, -- hgzh 22:58, 2. Dez. 2021 (CET)

• Okay, {{Tabellenstile}} kann von mir aus nochmal das Dingens wrappen.
  • Demnächst dann mit Wrapper im ANR, ohne Wrapper in Vorlagen.
• Zur Namensgebung: Nein, das ist der auf ein Jahrzehnt geplante Container für alles, was bezogen auf Tabellen-CSS warum auch immer in welchem Namensraum auch immer an Klassen zu definieren wäre. Ob das „Erweitert“ oder nicht sein soll durchschaut niemand, und keiner weiß was wann warum „nicht-erweitert“ nun wieder ist.
• @prettytable:
  • Gemach, gemach.
  • Diese Einbindung zielt nicht auf den ANR, sondern aiuf die anderen NR, insbesondere BNR.
  • Für prettytable@ANR habe ich schon seit Jahren eine andere Sauerei in der Schublade, aber so viele Minuten pro Tag habe ich nicht, um auf allen Hochzeiten zu tanzen und alles gleichzeitig zu wuppen.
  • prettytable@Tabellenstile zielt auf BNR & Co., und auf all diejenigen, die Weltuntergang!!!!!! Zeter!!!!! Mordo!!!!!!!! Autorenvertreibung!!!!!! brüllen, sobald sich etwas gegenüber der 2006 mal gelernten Wikitechnik ändet.
• @Wurgl: Sag ich doch, Wochenende.

VG --PerfektesChaos 23:15, 2. Dez. 2021 (CET)

Ich bin da absolut stressfrei und auch nicht auf der Flucht. Und wenn es nicht Wochenende ist, dann halt später. --Wurgl (Diskussion) 23:20, 2. Dez. 2021 (CET)

Verstehe ich übrigens richtig, der Unterschied ist: Bei Mouseover ist die Zeile blau hinterlegt. Gibts noch einen Unterschied? --Wurgl (Diskussion) 23:49, 2. Dez. 2021 (CET)

Ja, hier in diesem Fall. Sonst erstmal nix.

• Deshalb war das Fehlen nicht so dramatisch wichtig gewesen. Deshalb erst jetzt angepackt; deshalb war WMF radikal.
• Ist aber bei komplexen Tabellen ein netter Service, und wurde halt in 2000 Artikeln begehrt.

@ Bot: Die einzufügende Zeile lautet jetzt: {{Tabellenstile}}

@ Glaskugel: Für Gebilde wie zebra oder sonstwas sehe ich ähnliche Migrationsprobleme voraus. Deshalb pauschal vorsorglich „Tabellenstile“.

VG --PerfektesChaos 02:25, 3. Dez. 2021 (CET)

Bist du sicher, dass es funktioniert wie zuvor?

1. es benötigt zwingend auch class="wikitable"
2. vorher war der Hintergrund fest mit weiß überdeckt, ein einfärben der Zellen (für eine Zeile) war nicht vorgesehen, sondern nur die Hervorhebung per mouseover →Hilfe:Tabellen#mw-datatable
3. werden auch eingefärbte Zellen jetzt blau wenn man mit der Maus auf der Zeile steht
4. die Kopfzeile müsste auch EAEEFF nicht EAECF0 eingefärbt sein

Beispiel	Tabelle	wikitable mw-datatable
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel

Beispiel	Tabelle	wikitable zebra mw-datatable
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel

Beispiel	Tabelle	class="mw-datatable"
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel

Beispiel Ernst Mosch Welterfolge das hatte sicher vorher eine Wirkung dort (Spezial:Diff/188165707 und ich meine die Tabellenzellen waren auch ohne wikitable gerahmt), auch wenn die Tabelle eh umgebaut werden sollte, weil sie inzwischen dann auch noch das veraltete border verwendet. --Liebe Grüße, Lómelinde Diskussion 10:00, 3. Dez. 2021 (CET)

Ja, hatte es! Siehe die archivierte Version Webarchiv vom 1. August 2019 und die zugehörige Version nebenan: en:Pakistan_Army (Version vom 30.9.2019) Die verwenden dort {| class="mw-datatable" --Wurgl (Diskussion) 12:25, 3. Dez. 2021 (CET)

Was mich übrigens wundert ist, dass die Spezial:LintErrors → Tabellen (Spezial:LintErrors/obsolete-tag) nach wie vor das mw-datatable korrekt umsetzen. --Liebe Grüße, Lómelinde Diskussion 14:44, 3. Dez. 2021 (CET)

So. Ich stehe auf Start. Bearbeitungskommentar ist Wiederherstellen der Eigenschaft mw-datatable bei Tabellen, siehe Wikipedia:Technik/Skin/MediaWiki/Änderungen#Datatable

{{Tabellenstile}} wird unmittelbar vor der Tabelle eingefügt, soweit ich gesehen habe verursacht das keinen zusätzlichen Abstand.

Es gäbe noch die Möglichkeit {{Tabellenstile}}<!-- Wird für mw-datatable benötigt --> bzw.{{Tabellenstile<!-- Wird für mw-datatable benötigt -->}} einzufügen. Eben mit Kommentar damit das nicht von einer übereifrigen Putztruppe entfernt wird. --Wurgl (Diskussion) 21:38, 3. Dez. 2021 (CET)

Hm, ich bin bei der oben vorgeschlagenen CSS-Anweisung nur den Hinweisen auf Phabricator gefolgt. Aber es würde mich nicht wundern, wenn die dort Beteiligten die genauen Features dieser Klasse überhaupt nicht kannten. Ich habe sie so oder so immer nur in Kombination mit wikitable verwendet, daher war mir nicht bewusst, dass die auch noch mehr kann. Wo die Funktionalität auf den Spezialseiten herkommt, verstehe ich gerade auch nicht ganz.

Wie dem auch sei, wenn die TemplateStyles erst einmal Anwendung finden, kann man die immer noch entsprechend ergänzen. HTML-Kommentar sollte mE nicht notwendig sein, solange auf der Vorlagendoku erklärt wird, was die Vorlage macht. --XanonymusX (Diskussion) 22:10, 3. Dez. 2021 (CET)

Soweit ich gesucht hatte war nur Ernst Mosch Welterfolge ohne wikitable aber ich habe die Suchergebnisse (ANR) auch nur überflogen

class="mw-datatable" hat auf der Spezialseite zusätzlich nur style="border: 1px solid #a2a9b1; border-collapse: collapse;" den Rest bezieht sie aus der Klasse selbst, also Zellenränder, Innenabstände, Hintergrundfärbung …. was ich dort →Hilfe:Tabellen#mw-datatable gelistet hatte, muss ich aber von irgendwoher bekommen haben. --Liebe Grüße, Lómelinde Diskussion 09:19, 4. Dez. 2021 (CET)

Beispiel Tabelle class="wikitable mw-datatable" Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel

Beispiel Tabelle class="wikitable" Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel Beispiel

Was ich sagen wollte ist, man erkennt von außen nicht mehr, dass eine so gekennzeichnete Tabelle irgendwo eine Mouseovereinfärbung verbirgt, das wäre verwirrend, weil sie optisch nicht anders aussieht als eine normale wikitable, ich halte das so nicht für brauchbar. --Liebe Grüße, Lómelinde Diskussion 09:57, 4. Dez. 2021 (CET)

Ich hab mal im Firefox-Inspektor https://web.archive.org/web/20190731100340/https://en.wikipedia.org/wiki/Pakistan_Army#Schooling,_teachings,_and_institutions angeguckt und denke, dass folgendes noch fehlt:

table.wikitable.mw-datatable {
    border: 1px solid #a2a9b1;
    border-collapse: collapse;
}
table.wikitable.mw-datatable th {
    border: 1px solid #a2a9b1;
    padding: 0.2em 0.4em;
    background-color: #eaeeff;
}
table.wikitable.mw-datatable td {
    border: 1px solid #a2a9b1;
    padding: 0.2em 0.4em;
    background-color: #fff;
}

XanonymusX magst du gucken, ob das (syntaktisch) richtig ist und so passt? Bei CSS hab ich gerade mal mein erstes Seepferdchen bekommen. --Wurgl (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von Wurgl (Diskussion | Beiträge) 16:14, 4. Dez. 2021 (CET))

Ich denk mir, das sind alles wikitable-Eigenschaften.

Das sollte aber strikt getrennt sein und bleiben:

• Normalansicht auf allen Geräten soll unabhängig spezifiziert werden.
• Hinzu kommt nur die Hover-Funktion, für diejenigen, die auf ihrem Gerät hover haben und alle Spalten sehen können und es zufällig beim Rummachen mit dem Cursor mitbekommen.

VG --PerfektesChaos 16:44, 4. Dez. 2021 (CET)

• Grundsätzlich ist bei einer Datentabelle mit vielen Spalten solch ein Feature ja ganz neckisch.
  • Wenn da überall ähnliche Zahlen drinstehn, oder mal Kreuzchen und mal ohne, dann ist in Spalte 17 nicht mehr so klar, in welcher Zeile man guckt.
  • Setzt aber voraus, dass das Endgerät überhaupt sowas wie Locator kennt, und dass alle Spalten nebeneinander auf den Bildschirm passen. Sonst Essig.
  • Aufteilen in mehrere Datentabellen mit weniger Spalten ist inhaltlich oft keine Lösung.
  • Ist aber insgesamt eher ein nachrangiges Zubrot, das mal jemand zufällig entdeckt, der auf dem Desktop mit dem Mauszeiger einer Datenzeile zu folgen versucht.
• .wikitable würde ich nicht als zwingende Anforderung spezifizieren.
  • Ist zwar sehr wahrscheinlich, dass eine anspruchsvolle Tabelle damit ausgestattet ist, aber die Netzlinien könnten auch anders generiert werden.
• Einen Standard, dass (auf dem Desktop) eine Tabelle dieses Feature bieten würde und das erkennbar wäre, womöglich manche Smartphones auf einen breiten Daumen ohne anklickbare Verlinkung auch so reagieren würden, haben wir nicht und das offiziell im Text zu erwähnen ist Mumpitz.
  • Insofern Glückssache. Nice-to-have.
• Dass „auch eingefärbte Zellen jetzt blau wenn man mit der Maus auf der Zeile steht“ ist ja völlig okay und logisch; muss das Mäuslein ja nur weiterbewegen und die Originalfarbe kommt wieder.
  • Auf das sonstige Erscheinungsbild außer hover-Effekt sollte die Klasse keinerlei Einfluss haben; das wäre explizit konventionell zu deklarieren.
  • Wer das bislang nicht gemacht hatte und sich auf irgendwelche Seiteneffekte verlassen hatte, hat Pech. Ist aber nach wie vor eine lesbare Tabelle, und ob das nun weiß oder reinweiß oder zartgrauen Hintergrund hätte, fällt niemandem auf.
• Ach ja; Spezialseiten fordern sich das bei Bedarf explizit an. Sei angeblich um 2010 auch nur für von MediaWiki generierte Spezialseiten gedacht gewesenund nur aus Versehen auf allen Seiten bereitgestellt worden. Naja.
• edit=3/4 move=sysop für Vorlage:Tabellenstile/styles.css von oben fehlt noch; und Vorlage:Tabellenstile könnte nach neuerer Lesart ja jetzt Vollschutz erhalten.

VG --PerfektesChaos 16:12, 4. Dez. 2021 (CET)

Huch! Ich hab nur auf Lómelindes Einwand reagiert, dass man die Tabellen nicht unterscheiden kann. Den Header könnte man durchaus blau hinterlegen. --Wurgl (Diskussion) 18:14, 4. Dez. 2021 (CET)

Aber wer soll denn wissen, was für eine Bedeutung es hätte, wenn die Kopfzeile blau hinterlegt ist? Und was hilft das auf dem Smartphone? Und was machen die Feuerwehrleute mit ihren roten Kopfzeilen, und die Seeleute in marineblau, und die BVB-Fans mit gelb?

VG --PerfektesChaos 18:29, 4. Dez. 2021 (CET)

Wie schon geschrieben, ich meine ein überschreiben der einzelnen Zeilen mit anderen Klassen (hintergrundfärbung) war vorher nicht vorgesehen, die datatable ließ nur reinweiß als Hintergrund und blaugrau als Kopfzeilen zu, ich kann mich natürlich auch irren. Man konnte einzelne Zellen natürlich mit style überschreiben, aber mehr nicht …, aber was weiß ich noch davon, was ich vor einer Ewigkeit getestet hatte. --Liebe Grüße, Lómelinde Diskussion 08:38, 5. Dez. 2021 (CET)

Hab mal drei Testedits gemacht. Okay so? Kann ich loslegen? --Wurgl (Diskussion) 09:36, 5. Dez. 2021 (CET)

Ich habe die datatable nie ohne wikitable gesehen oder selbst verwendet, daher weiß ich da auch nicht mehr. Aber auch egal, die Hauptfunktion der Klasse war immer die Einfärbung bei hover, wir sollten uns einfach darauf beschränken.

Testedits sehen gut aus, ja! --XanonymusX (Diskussion) 13:09, 5. Dez. 2021 (CET)

Ah ja, die Vorlage hab ich auch mal auf 3/4 gesetzt, ich bin kein Fan von Vollschutz ohne Anlassfall. Ich würde auch noch ein paar mehr erklärende Worte zum Einsatz in die Doku schreiben (Warum steht sie in einem Artikel? Wann kann sie entfernt werden?), ich hadere bloß gerade mit der Formulierung. --XanonymusX (Diskussion) 13:14, 5. Dez. 2021 (CET)

Bis auf 3 Artikel ist der Bot durch und die drei liegen noch ein paar Minuten auf Halde, 2 Stunden nach der letzten Änderung macht der Bot erst rum. --Wurgl (Diskussion) 21:53, 5. Dez. 2021 (CET)

Sorry, aber ich muss nochmal meckern. Meiner Ansicht nach ist die jetzige Lösung Mist.

Zitat von oben: Auf gar keinen Fall werden wir 2000 Artikel anfassen, egal wie. Nun sind 2000 Artikel bearbeitet, und dabei wurde:

• ein eigentlich MediaWiki-reservierter Klassenbezeichner lokal mit anderer Funktion als dem Default-Verhalten überschrieben, ohne dass das irgendwie ersichtlich würde.
  • dieser Name ist nun irreführend, weil dessen einziger Zweck das Ermöglichen von Hover-Zeilenhervorhebung ist, was aber mit einer datatable erstmal nichts zu tun hat.
  • mw-datatable war als Bezeichner eh dubios, weil der einzige Grund, dies im Wiki anzuwenden, schon immer die Hover-Hervorhebung war und nicht etwa, irgendentwas semantisch als Datentabelle zu kennzeichnen.
  • besser wäre wohl irgendetwas wie hover gewesen.
• veraltete prettytable-Definitionen ohne Not in ebenjene Artikel gepackt.
  • Vorschlag: Aufspaltung der Vorlage:Tabellenstile/styles.css, der datatable-Kram kommt nach Vorlage:Tabellenstile/datatable.css und der prettytable-Kram nach Vorlage:Tabellenstile/prettytable.css, Einbindung per Parameter wirklich nur, wenn unbedingt erforderlich.

Nach wie vor sehe ich den Grund für die plötzliche Eile nicht. -- hgzh 19:12, 6. Dez. 2021 (CET)

„Auf gar keinen Fall werden wir 2000 Artikel anfassen, egal wie“

• Ja, das war meine Ansicht vom August.
• Da ging ich aber noch davon aus, dass MediaWiki das wieder auf allen Seiten in Kraft setzt. Erwartet hätte ich auch stärkeren Druck aus der enWP, was meistens wirkt, aber die hatten sich praktisch nicht gerührt.
• Weil das nun doch nicht mehr von MediaWiki zu erwarten ist, dann besser so als in zig Millionen Seiten und unübersehbar vielen dynamisch generierten Varianten, sondern nur in erstmal 2000 ANR und irgendwann ein paar sonstige.

Die wesentliche beabsichtigte Wirkung war immer nur die Hover-Wirkung auf eine Zeile gewesen.

• Der Name dafür ist um 2010 nicht sehr schlau gewählt worden, aber so war er jetzt ein Dutzend Jahre.
• Die enWP hatte es irgendwie Anfang der 2010er spitzbekommen und dort Reklame dafür gemacht, und dann kam unser Spezi und hat es in unsere Hilfeseite reingeschrieben.
• MediaWiki hatte es wohl tatsächlich nie auf deren Anleitungen publiziert, wollte eigentlich auch nur einige Spezialseiten damit ausstatten, hat es aber in sämtlichen Seiten ein Jahrzehnt lang ausgeliefert.

Wir könnnen uns gern zusätzlich zum praktisch funktionsgleichen noch einen neuen dewiki-Bezeichner ausdenken, globale Kompatibilität möge zum Teufel gehen.

• table-row-hover oder wie auch immer.
• Autoren und Bestandsseiten sind aber auf den herkömmlichen Bezeichner geeicht, und ein Umlernprozess dauert so seine anderthalb Jahrzehnte.

Die {{Tabellenstile}} soll so simpel und einfach wie möglich sein.

• Deshalb: Keine Parameter, keine Parameterprüfung, keine Fehlermeldung und Wartungskat und Zinnober.
• Wo sie eingebunden ist, werden allerlei zusätzliche Tabellenstile bereitgestellt, die in der Grundausstattung einer Seite nicht vorhanden sind.
• Nächster Kandidat wäre zebra.
• Vielleicht fällt zukünftig noch jemand ein bunter Effekt ein.

Die letzten zehn, zwölf, fünfzehn Jahre wurde auf jeder (Desktop-)Seite immer prettytable und zebra und mw-datatable bereitgestelllt, egal ob es vorkäme oder nicht.

• Das ist perspektivisch auf Millionen Seiten nicht mehr der Fall, jedoch im ANR gibt es 2000 mit datatable, 18.000 mit zebra und in manchem BNR kommt jemand mit der Umstellung auf wikitable nicht klar und will sein altes prettytable-Design beghalten. All die können auf solch einer Seite die Sahnehäubchen-Tabellenstile anfordern, und dann ist es genau wie damals, mit allem und scharf.

Eine Aufspaltung in unterschiedliche Deklarations-Unterseiten, eine nur für hover und eine nur für prettytable, und Auslösung durch irgendwelche Parameternamen – für nur eine oder auch mehrere Funktionen – macht die Sache viel zu kompliziert und wartungsintensiv.

• Einfach irgendwo {{Tabellenstile}} reinklatschen, dann isses wieder so wie früher, als auf jeder Seite alle CSS-Deklarationen aktiv waren. Lief ja ein Jahrzehnt lang genau so.
• Der dramatische Schaden für eine Seite entsteht nicht, indem wie immer schon alle Stile definiert sind – der Vorteil liegt allein schon darin, dass die Zahl der betroffenen Seiten um den Faktor 1000 gesenkt werden kann.

„sehe ich den Grund für die plötzliche Eile nicht“

• Ich hatte auch keine und extra den Bot-Start auf bis Wochenende hinausgezögert.
• 21:49, 1. Dez. 2021 kam plötzlich auf, es solle jetzt angegangen werden.
• Ich halte das hover-highlight zwar für ein hübsches Nice-to-have, falls ein Leser mit geeignetem Endgerät das zufällig in einer Tabelle entdeckt, aber es gibt keinen einem Millionenpublikum vermittelbaren Icon, mit dem man ohne Platzverbrauch signalisieren könnte, dass auf manchen Geräten der Mauszeiger bei der Orientierung helfen würde.
• Insofern hätte ich es dieses Jahr auch nicht gebraucht, aber irgendwann muss da ja mal eine dauerhafte Lösung draus werden.

VG --PerfektesChaos 01:36, 7. Dez. 2021 (CET)

Gut, zu den Einzelheiten der Tabellenstile verständigen wir uns besser auf der dortigen Vorlagendisk, hier schweifen wir ab. Gruß, -- hgzh 15:48, 9. Dez. 2021 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 21:43, 23. Dez. 2021 (CET)

Groß- und Kleinschreibung

Die Groß- und Kleinschreibung der Links bei diskussionsbezogenen Aktionen (in eckigen Klammern) ist derzeit uneinheitlich. Es gibt:

• MediaWiki:editsection = Bearbeiten
• MediaWiki:discussiontools-replylink = Beantworten
• MediaWiki:discussiontools-topicsubscription-button-subscribe = Abonnieren
• MediaWiki:discussiontools-topicsubscription-button-unsubscribe = Abbestellen

Ich denke, wir sollten uns entweder für Groß- oder Kleinschreibung entscheiden. Ich tendiere eher zur Kleinschreibung, was meint ihr? -- hgzh 18:59, 29. Nov. 2021 (CET)

Da schließe ich mich an, denn Antworten sind etwas anderes: man ruft jedoch keine Antworten auf, sondern antwortet. Pro kleinschreibung für alle. --Holmium (d) 20:14, 29. Nov. 2021 (CET)

Einheitlichkeit: Ja, auf jeden Fall erstrebenswert.

Groß/Kleinschreibung von Verben: Mir herzlich egal.

Aber: Es gibt auch Beschriftungen mit einem Substantiv; etwa „Versionsgeschichte“ oder „Statistik“. Dann sieht es doooof aus, wenn zwischendurch Kleinschreibung auftaucht.

• Beispiel: Tabs bei Vector ganz oben: „Diskussion“ – „Lesen“ – „Bearbeiten“ – „Versionsgeschichte“ – „Einstellungen“ – „Beiträge“

VG --PerfektesChaos 20:51, 29. Nov. 2021 (CET)

MediaWiki:editsection wird soweit ich weiß nur neben Abschnittsüberschriften verwendet. Die Tabs bspw. haben eigene Systemnachrichten (etwa MediaWiki:Vector-view-edit). -- hgzh 11:25, 30. Nov. 2021 (CET)

Nach anderthalb Tagen besonderer Aufmerksamkeit:

• Praktisch alle eigenständigen Links, Buttons, Labels verwenden Großschreibung in den deutschsprachigen Wikis. Auch beim Login das [Anmelden] in Blau, oder als Link in Vector.
• MediaWiki:editsection kommt meiner Erinnerung auch in Skripten vor; ich meine Schnark hätte das irgendwo. Oder sonstwer, auch in der enWP.
• MediaWiki:editsection ist jetzt zwei Jahrzehnte so wie es ist; sowas ändert man nur wenn es einen triftigen Grund dafür gibt. Das wäre genau welcher? Gibt sonst bloß wieder Zwergenaufstand.

discussiontools ist das was auch in Hilfe:Diskussionsseiten/Hilfsmittel dargestellt wird? Warum genau müssen diese Buttons jetzt anders als alle anderen lokal oder für alle deutschsprachigen Wikis Kleinschreibung erhalten?

VG --PerfektesChaos 21:10, 30. Nov. 2021 (CET)

Nach einem weiteren Tag Beobachtung: Zustimmung zu dem vorigen Beitrag, was lange gewohnt ist, sollte nicht geändert werden. Im übrigen sieht mir wie oben geschrieben der Link 'Antworten' für unbefangene Leser (soweit ich mich in deren Situation versetzen kann) aus, als klappte man dort die 'Antworten' auf diesen Beitrag auf. 'Beantworten' in Groß- oder kleinschreibung hielte ich für eindeutiger. --Holmium (d) 21:05, 1. Dez. 2021 (CET)

In Anbetracht der üblichen Bearbeiten-Beschriftungen halte ich generelle Großschreibung tatsächlich für die bessere Lösung. Also auch Abonnieren und Abbestellen. Das Problem mit Antworten ist mir auch bewusst, eventuell könnte man auch Darauf antworten daraus machen. --XanonymusX (Diskussion) 21:36, 1. Dez. 2021 (CET)

Nach zeitlicher Begutachtung stimme ich doch der alten Schreibweise zu. Das Problem mit Antworten ist durch die Lösungsvorschläge von Holmium oder XanonymusX machbar.--Funkruf ^WP:CVU 22:42, 1. Dez. 2021 (CET)

Es ist doch weitgehend uneinheitlich, siehe etwa Versionsgeschichten und Diffseiten, die haben "rückgängig", "danken", "kommentarlos zurücksetzen", aber auch "Bearbeiten" und "Sperren". Aber da sich eine Mehrheit nun für Großschreibung ausgesprochen hat, setze ich das demnächst für die beiden topicsubscription-Links so um. Zum Antworten bin ich noch unschlüssig. -- hgzh 08:15, 2. Dez. 2021 (CET)

• Es sollte im translatewiki: umgesetzt werden.
• Irgendwo mag es vereinzelte überkommene Ausreißer geben; die sollten behutsam und unter Betrachtung des sprachlicen Kontextes angeglichen werden (es gibt auch sowas wie „angefangene Sätze“).
• „Beantworten“ statt „Antworten“ finde ich an dieser Stelle als Aktion gut.
• Die englischsprachige Oberfläche hat sehr konsequent Großschreibung. Aber Verben und auch Substantive bekanntlich klein.
• translatewiki kann ich auch machen.

VG --PerfektesChaos 10:12, 2. Dez. 2021 (CET)

Entsprechend umgesetzt. Schaun mer mal. -- hgzh 17:39, 2. Dez. 2021 (CET)

Beantworten suggeriert mE irgendwie stärker, dass auf eine Frage geantwortet wird (also mehr answer als reply). Da wäre bei unseren Diskussionen natürlich zu kurz gegriffen. Aber Reagieren o. ä. ist vermutlich eher ungewohnt. --XanonymusX (Diskussion) 18:44, 2. Dez. 2021 (CET)

Reagieren kannst du ja auch zum Beispiel durch den Danke-Button. --Funkruf ^WP:CVU 12:26, 3. Dez. 2021 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 21:41, 23. Dez. 2021 (CET)

Helferlein für Abschnittsnummerierung

Mit dem kommenden MediaWiki-Update ist geplant, die bisher optional über die Einstellungen verfügbare Abschnittsnummerierung zu entfernen, vergleiche meta:Tech/News/2021/41 bzw. den entsprechenden Phab-Task phab:T284921. Der Entwickler Krinkle hat stattdessen ein, nein zwei Snippets bereitgestellt, bestehend aus Skript und CSS, über die diese Nummerierung weiterhin möglich ist, allerdings müssen diese als Gadget/Helferlein eingebunden werden, siehe mw:Snippets/Auto-number headings. Ich bitte darum, dieses Helferlein auch in der deutschen Wikipedia zur Verfügung zu stellen. Ping @Aschmidt, Chaddy, Perrak, die sich im Phab-Task geäußert hatten. — Speravir – 01:25, 13. Okt. 2021 (CEST)

+1. Das wäre schön, wenn es bitte jemand übernehmen könnte, das Helferlein zu installieren. Danke vorab! --Viele Grüße, Aschmidt (Diskussion) 07:00, 13. Okt. 2021 (CEST)

 Kontra Ich halte ein derartiges Community-JS-Gadget für absolut überflüssig bis schädlich:

• Eine Bezugnahme auf nummerierte Abschnitte statt auf den eher robusten Text der Überschrift ist kontraproduktiv.
• Die Idee mit dem Nummerieren ist ein Relikt aus der Zeit statischer Papierwerke und mit unseren permanent wandelbaren Seiten nicht vereinbar. Es war in der Säuglingsphase der Wikis mal den gedruckten Büchern nachempfunden worden; nicht voraussehend, dass eine statische Nummerierung mit der sich dynamisch entwickelnden Seitenstruktur kollidieren würde.
• Wer sich auf einen „fünften Abschnitt“ bezieht, macht etwas falsch.

Es besteht kaum Bedarf.

• Es gibt anscheinend ein halbes oder vielleicht auch ganzes Dutzend Benutzer aus der Zeit um 2005, die diese Darstellung unbedingt haben möchten, weil sie ja schon immer da war.
• Zehntausende unserer angemeldeten Benutzies kommen jedoch wunderbar ohne die in Papieren zuweilen sichtbare Zählung in Überschriften aus, ein Millionenpublikum an Leserschaft hatte sie noch nie gesehen und nie vermisst.
• Die Verkomplizierung und nachfolgende Notwendigkeit für Wartung und Pflege, diesen Abschnitt eingeschlossen, steht dazu in keinem Verhältnis.

Es ist nicht damit getan, ein paar Code-Zeilen irgendwo abzuwerfen, sondern neue Community-Gadgets haben auch ordnungsgemäß dokumentiert zu werden; also so wie in Kategorie:Wikipedia:Technik/Skin/Gadgets.

• Es war die Wurschtelei unserer Kindergarten-Zeit, die zu einem Wust nicht mehr pflegefähiger Bastelarbeiten führte.
• Das in Rede stehende Teil wird absehbar nicht langjährig stabil sein, da es sich auf wandelnde Einzelheiten des Seitenaufbaus verlässt, sogenanntes Screengrabbing.
• Wir haben noch einen Schwung ungepflegter mangelhaft dokumentierter kurz vor dem Verrecken stehender „Helferlein“ aus der Ära der Skriptbastelei, für die sich bereits heute keinerlei BOA finden, die sie sanieren würden. Dem noch eine weitere Ruine hinzuzufügen ist kaum zu verantworten.

Es kann jeder in seinem BNR ein entsprechendes Skript usw. anlegen, es ordnungsgemäß dokumentieren, und danach auch offiziell anbieten oder privat weiterreichen.

• Damit verbleibt jedoch die Alleinverantwortung für aktuelle Dokumentation, Wartung und Pflege bei dem Nick, der zwischen Doppelpunkt und erstem Schrägstrich steht, und wird nicht ungefragt in Ewigkeit auf künftige Projektpfleger der Community abgewälzt.
• Es können sogar alle, die es haben möchten, sich jetzt gleich sofort selbst die Krinkle-Ressourcen einbinden; auf jeden Fall als statische Kopie oder sonst auch dynamisch gepflegt. Allerdings fehlt dem Dings offenbar eine Doku, die erklärt wie das ginge.

VG --PerfektesChaos 08:29, 13. Okt. 2021 (CEST)

+1 @PerfektesChaos. Bitte nicht absehbare Altlasten aktiv projektweit neu einführen. Manche Dinge ändern sich, und das hier nicht ist sicher nichts, wodurch jemand nicht mehr arbeiten könnte. --Krd 09:46, 13. Okt. 2021 (CEST)

Es wäre ein Service für die Leser gewesen, der enorm hilfreich war, um sich in länglichen Artikeln zurechtzufinden, die man liest. :( --Viele Grüße, Aschmidt (Diskussion) 19:23, 13. Okt. 2021 (CEST)

Mir geht es wie Aschmidt, dass mir die Nummerierung enorm hilft, mich bei längeren Seiten deutlich besser zurechtzufinden, was ich immer dann merke, wenn ich auf einem Wiki ohne solche unterwegs bin, aber natürlich geht es irgendwie auch ohne. Zu einigen Punkten von oben:

• Dokumentierung: Ja, davon kann es eigentlich nie zu viel geben (je länger, desto wichtiger ist die Strukturierung, wo mir wieder eine Nummeriereung helfen würde), wobei mir hier nicht ganz klar wäre, was man da groß dokumentieren soll außer dass den Abschnitten eine Nummer vorangestellt wird. Oder ist damit auch so etwas wie die Herkunft gemeint, was sicher sinnvoll wäre, oder eben die Warnung, dass die Nummerierung nie angegeben oder gar mitkopiert werden darf, weil sie sich ändern kann und für die Verlinkung unerheblich ist? Da die Doku nicht im MediaWiki-Namensraum sein soll, könnte diese sogar nicht allein von BOAs angelegt und bearbeitet werden.
• Bezugnahme auf nummerierte Abschnitte: Hab ich noch nie gemacht und habe ich bewusst auch noch nie gesehen, aber die Gefahr besteht tatsächlich – besteht sie aber schon, seit es die Einstellung gibt, die nun entfernt werden soll. Andererseits: Es gibt seit kurzem die Zeilennummerierung, und die kann man sogar verlinken, obwohl sie sich ebenso verändern kann. Da gibt es dann Wortkreationen wie „Stand heute“.
• Bedarf: Laut Phab-Task nutzten in der einzig untersuchten englischen Wikipedia 0,4 % der aktiven Autoren die Möglichkeit. Im Dewiki wären das um die 70 Nutzer (laut Spezial:Statistik waren es zuletzt rund 17.800 aktive Nutzer), aber ob die Quote stimmt, kann ich nicht überprüfen. Gibt es Statistiken über die Aktivierung von Helferlein?
• Langjährig nicht stabil/Screengrabbing: Verstehe ich nicht. Geht es dir, PC, um die Klassenselektoren, die im Zweifel tatsächlich anzupassen wären?
• „Es kann jeder in seinem BNR ein entsprechendes Skript usw. anlegen“. Jein, kann eben nicht jeder so leicht, vor allem, wenn es dann um mehr als nur eine einfache Kopie geht, im konkreten Fall müsste man sogar Javascript und CSS kombinieren. Statt einer Kopie wäre es auch deutlich besser, das Original einzubinden. Die sehr gute Doku in der deutschen Wikipedia kann dabei allerdings sehr gut behilflich sein.
• Krinkle-Ressourcen einbinden: Mir war zunächst nicht klar, was Du damit meinst, und bin mir dessen immer noch unsicher, habe aber daraufhin im Mediawiki unter den Gadgets nachgesehen und, siehe da: mw:MediaWiki:Gadget-autonum (wohl ein Beispiel, wie man es nicht machen sollte, eben weil dort ein Link zu einer Doku fehlt), mw:MediaWiki:Gadget-autonum.js und mw:MediaWiki:Gadget-autonum.css. Was für mich selbst bedeutet, dass ich genau dieses Skript und dieses Stylesheet bei mir einbinden werde. Aber um mich selbst ging es mir hier gar nicht (ich hatte Skript und Stil bereits zuvor lokal getestet, hätte also für mich selbst auf jeden Fall eine Möglichkeit gefunden).

— Speravir – 01:27, 14. Okt. 2021 (CEST)

In vollem Umfang +1 zu @Speravir. Die Nummerierung der Abschnittsüberschriften ist für mich ein Standardfeature für engagierte Autoren, die Wikipedia intensiv nutzen. --Viele Grüße, Aschmidt (Diskussion) 07:08, 14. Okt. 2021 (CEST)

@Seiten-Navigation: Also, ich springe mit einem Klick zum Seitenanfang, finde nach einem sehr kurzen Einleitungsabschnitt das Inhaltsverzeichnis und springe mit einem Klick zum genau richtigen Abschnitt. Mit der Frage nach einer Nummer habe ich mich noch niemals beschäftigt oder gar belastet.

@Bedarfsgruppe:

• Wir haben die Möglichkeit, per Anfrage eine statistische Analyse aufgeschlüsselt nach Gadget/Preference zu erhalten, passiert auch alle Jubeljahre, und die 0,4 % der enWP sind da sehr realistisch.
• Nicht jeder, der irgendwo ein Häkchen hingemacht hat, braucht das auch. Viele hatten auch einfach nur so mal dies und das angekreuzelt; wir erleben auch sehr regelmäßig, dass Aktive in ihrem JavaScript noch massenhaft Schnipsel herumzuliegen haben, die schon seit einem Dutzend Jahre dysfunktional sind, und wo sich die Verantwortlichen nicht erinnern können wozu sie sich das mal kopiert hatten und es nie gebraucht und nie vermisst haben. Es gibt auch etliche Benutzerseiten von Aktiven mit Verlinkungen im 2014 abgeschalteten Toolserver. Die Anzahl gemachter Häkchen ist also nicht notwendigerweise auch die Anzahl derjenigen Aktiver, die auf das Feature Wert legen.
• Trotz breiter Werbekampagne an mehreren Stellen sind die Protestierer an einer einzigen Hand abzuzählen. Insofern halte ich meine oben getroffene Abschätzung „halbes oder vielleicht auch ganzes Dutzend Benutzer aus der Zeit um 2005, die diese Darstellung unbedingt haben möchten“ für großzügig nach oben abgeschätzt. Das sind <0,1 % der Aktiven; >99,9 % Angemeldete vermissen nichts, und 100 % IP.

@Doku:

• Sie hat für laienhafte Anwender verständlich zu erklären, was die Funktion ist und wozu man das benötigen würde und was dann passiert und wie es zu bewerkstelligen wäre.
• Sie hat für pflegende Programmierer, die von der Angelegenheit noch niemals etwas gehört haben, alle erforderlichen Informationen bereitzustellen, insbesondere Methodik und wirksame Komponenten, damit bei allfälliger Veränderung irgendwelcher Rahmenbedingungen die Programmierungen verändert werden können und die beabsichtigte Wirkung wiederhergestellt werden kann.
• Beispiele sind in der Kat nachlesbar, etwa WP:HW/dewiki-logo; alle Dingse die in der Kat nicht unterlegt wurden sind dem Untergang geweiht.

@Screengrabbing: Alles, was sich auf den Aufbau des HTML-Dokuments verlässt und dessen momentane Struktur zur Informationsgewinnung auswertet, läuft immer Gefahr, bei einer jederzeit möglichen Veränderung der Serverprogrammierung, die davon nichts wissen kann und unangekündigt zu geschehen pflegt, vor die Wand zu fahren.

@Neue Gadgets: Von jedem Community-Gadget, das hier einmal eingerichtet wurde, wird verlangt, dass unsere Softwarebetreuer es auf Gedeih und Verderb in alle Ewigkeit bereitstellen müssen, auch wenn das kaum noch möglich ist. Einen müden Abglanz dieser Forderung, jedes Feature der letzten zwei Jahrzehnte müsse auf immer und ewig beibehalten werden, erleben wir gerade. Bloß wird Software irgendwann durch Anwender unbedienbar und für Programmierer nicht mehr robust funktionierend zu halten und nicht mehr effizient ausführbar, wenn man über Jahrzehnte alles kumuliert, obwohl es mit sich ändernden Rahmenbedingungen kollidiert. Und das Personal zur Wartung unseres Bestandes und zur Modernisierung hoffnungslos veralteter Überreste der Schnullerjahre ist bereits zu 500 % überlastet.

@Und nochmal: Jeder, der diese Dekoration unbedingt haben möchte, kann sie für sich selbst jetzt gleich und sofort einrichten, und konnte das schon vor Tagen.

VG --PerfektesChaos 18:04, 14. Okt. 2021 (CEST)

Du arbeitest auf eine Weise, andere auf eine andere. Du klingst gerade so, als ob sich alle nach dir zu richten haben (wobei ich glaube, dass Du es so nicht meinst). Und dass eben nicht jeder sich so etwas von allein einrichten kann, scheinst Du nicht verstehen zu wollen. — Speravir – 01:39, 15. Okt. 2021 (CEST)

Fürs Archiv, falls mal jemand danach sucht (ich will das aber auch noch in meinem Benutzerraum aufführen), einzufügen in die eigene common.js, wenn die Funktion nur in der deutschen Wikipedia genutzt werden soll, oder die global.js, wenn man sie für alle Wikimedia-Projekte nutzen will:

/* Nummerierung von Abschnitten, Import von Mediawiki-Gadget "Auto-number headings",
 * siehe auch https://www.mediawiki.org/wiki/Snippets/Auto-number_headings
 */
// https://www.mediawiki.org/wiki/MediaWiki:Gadget-autonum.js
mw.loader.load("https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-autonum.js&action=raw&ctype=text/javascript");
// https://www.mediawiki.org/wiki/MediaWiki:Gadget-autonum.css
mw.loader.load("https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-autonum.css&action=raw&ctype=text/css", "text/css");

— Speravir – 01:39, 15. Okt. 2021 (CEST)

„Du klingst gerade so, als ob sich alle nach dir zu richten haben“

• Hier haben vier oder fünf namentlich bekannte Benutzer einen individuellen Dekorationswunsch.
• Zigtausende registrierter und Millionen nicht angemeldeter Benutzer haben diese sehr ausgefallene Vorliebe nicht; sie war bisher auch nie irgendwo als besonders empfehlenswert thematisiert worden. Wie gezeigt, ist sie auch nicht erforderlich.
• Abschnittseröffnend wird nun gefordert, dieses sehr randständige und hinsichtlich Zitation problematische, vor Jahrzehnten unter anderen Rahmenbedingungen von einem Programmierer mal gebaute Feature solle jetzt von dieser Community zum auf ewig bereitzustellenden Angebot in der übersichtlichen Liste unserer Hilfsmittel gemacht werden.
• Es ist also eher die Handvoll, die den Zigtausenden vorgibt, wie sie sich Seitendarstellungen gestalten sollten, weil das angeblich eine wichtige und unverzichtbare Präsentation wäre, und man möge sich nach diesen vieren richten.
• Die zitierte Unterstellung ist somit eine groteske Verdrehung der Realität.

VG --PerfektesChaos 09:28, 15. Okt. 2021 (CEST)

Lieber @PerfektesChaos, das alles mag ja deine Meinung sein, ich glaube aber, @Speravir wollte dir sagen, dass du bisher in der Diskussion wenig empathisch reagiert hattest, und ich glaube auch, dass er damit Recht hat. Vielleicht könntest du an der Stelle noch etwas an dir arbeiten. Aber das ist nur ein Hinweis am Ende einer langen Woche. Ich wünsche euch allen schon einmal ein schönes Wochenende! --Viele Grüße, Aschmidt (Diskussion) 17:19, 15. Okt. 2021 (CEST)

Exakt, Aschmidt. PC, wenn ich dir meinen Eindruck schildere, dann ist das keine Unterstellung, in Klammern habe ich doch extra noch geschrieben, dass ich selbst glaube, Du meinst es anders. Zur „Handvoll, die den Zigtausenden vorgibt, wie …“: Ein standardmäßig deaktiviertes Helferlein kann doch niemandem etwas vorschreiben!? Keine Angst, ich habe den Rest auch gelesen und glaube, ihn verstanden zu haben. — Speravir – 01:23, 16. Okt. 2021 (CEST)

Jetzt, wo es die Nummerierung nicht mehr gibt, sieht man ja auch, wohin das führt: Die Unterschiede beim Schriftgrad der Überschriften ist so gering, dass man nicht mehr auf den ersten Blick sehen kann, auf welcher Gliederungsebene man sich in einem Artikel befindet. Das ist doch einfach nur Mist für engagierte Autoren. Es kommt nicht darauf an, wieviele das Feature einst aktiviert hatten, sondern wer das war. Ich brauche das für meine Arbeit, und ich gehe davon aus, dass die meisten, die es angeht, gar nicht wissen, wie man das wiedererhalten könnte. Und diejenigen von uns – @PerfektesChaos, @Krd –, die es zumindest wieder lokal für alle bereitstellen könnten, weigern sich mit wirklich abwegigen Argumenten, die in keiner Weise stichhaltig sind. Sehr, sehr traurig. Könntet ihr bitte noch einmal in euch gehen? – Ping zur Info an @Speravir. --Viele Grüße, Aschmidt (Diskussion) 12:37, 16. Okt. 2021 (CEST)

Ich fand die Nummerierung auch übersichtlicher, wie bei längeren Artikeln und speziell bei Diskussionsseiten etc. Mal sehen, wann die ersten Stimmen laut werden, die diese Änderung ändern wollen und wann das erste Meinungsbild dazu formuliert wird. Dort würde ich für die Nummerierung votieren. Die Skripte werde ich mir anschauen und ggf. einrichten. --Elrond (Diskussion) 14:54, 17. Okt. 2021 (CEST)

Ich verstehe nicht so recht, wieso hier auf einem Gadget bestanden wird. Weiter oben sind die zwei Zeilen, die in die entsprechenden Seiten einzufügen wären, bereits aufgeführt (und im Gegensatz zum Gadget funktioniert das per global.css sogar auf einen Schlag in allen Projekten). Dass Skripte auf diese Weise eingebunden werden, ist ja nun kein völlig neues Verfahren und wird bei einer Vielzahl weit häufiger genutzter Arbeitshilfen ebenso gehandhabt und auch auf entsprechenden Hilfeseiten erklärt. -- hgzh 15:30, 17. Okt. 2021 (CEST)

Für einen Nerd mag so was eine völlig simple Selbstverständlichkeit sein, aber 99+ % aller Wikipediabenutzer wissen entweder nichts von diesem Script oder wissen nicht, wie man es anwendet. Dein Einwand erinnert mich ein wenig an die Szene in 'Per Anhalter durch die Galaxis' als die Vogonen einen Einspruch von Erdlingen gegen die Sprengung der Erde mit dem Hinweis abschmettern, dass auf Alpha Centauri die Pläne drei Monate auslagen und kein Erdling Einspruch erhoben habe. --Elrond (Diskussion) 18:51, 17. Okt. 2021 (CEST)

Nebenbei, ich gehöre zu diesen 99+ %, weil ich zwar jetzt um die Existenz dieser Zeilen weiß, mir aber nicht zutraue, die ohne etwas zu zerdeppern in die oben genannte Seite einzufügen. Ich habe keinerlei Kenntnisse in HTML oder anderen Auszeichnungssprachen - und wenn jetzt jemand kommt uns schreibt Das ist kein HTML sondern... dann mag es zum Beweis genügen, wie gering meine Kenntnisse sind. --Elrond (Diskussion) 18:59, 17. Okt. 2021 (CEST)

Eine Bekannte wollte mal so ein JavaScript bei ihrem Account einbinden. Ich habe ihr am Telefon erklärt, wie man das macht. Ich habe ihr gezeigt, wie das bei meinem Account aussieht. Ich habe ihr den Quelltext und den Link per Mail geschickt, wo die richtige Seite für sie wäre, auf der sie den Text einfügen müsste. Am liebsten hätte ich es für sie gemacht, aber die Seiten sind schreibgeschützt, ich hatte keinen Schreibzugriff, deshalb musste sie es selbst machen. Sie hatte es erst im zweiten Anlauf geschafft. Und dann funktionierte das Skript doch nicht so wie bei meinem Account. Wir konnten nicht feststellen, woran es lag und haben es dann auf sich beruhen lassen. Wohlgemerkt: Sie ist Informatikerin. Aber sie fand sich hier in den Wikis (Wikipedia, Meta, Commons..., js, css, global, lokal...) nicht zurecht. – Ich habe den Snippet mittlerweile ausprobiert, er tut, was er soll, aber ich verwende mich ja hier für die Kollegen wie beispielsweise @Elrond – oder meine Bekannte. --Viele Grüße, Aschmidt (Diskussion) 19:43, 17. Okt. 2021 (CEST)

Bei einer ausreichend großen Anwenderbasis sind Gadgets natürlich sinnvoll, deshalb sind beispielsweise HotCat, Rechtschreibprüfung oder die BKL-Markierung völlig zurecht dort aufgeführt. Aber bereits jetzt gibt es dort Einträge, die nur für einen sehr kleinen Kreis, der sich auch nicht mehr vergrößern wird, überhaupt relevant sind (bspw. Typographie-Refresh- und Diff-Farben-Rückgängig oder 2006-Werkzeugleiste-Zurück). Die potenzielle Anwenderschaft der Abschnittsnummerierung ist mE nicht so groß, um einen Eintrag dort zu rechtfertigen. Gleichzeitig sind zahlreiche andere häufig genutzte Skripte schon seit jeher nur per manueller Installation verfügbar, etwa die komplette monobook.js, diverse Autoformatter oder Normdatenhelferlein, alle Schnarkskripte etc., ohne dass ein Bedarf für eine Aktivierung als Gadget gesehen worden wäre.

Im Übrigen sind Nerd und häufig strapazierte Filmzitate keine mir zuträgliche Diskussionsebene, weshalb ich hier nun raus bin. Gruß, -- hgzh 13:31, 18. Okt. 2021 (CEST)

Ich bitte darum, das Gadget zuzulassen. Die Nummerierung war für viele sehr nützlich und es ist eh schon ziemlich bescheiden, dass diese Funktion einfach abgeschafft wurde. Mit einem Gadget könnte sie auf Wunsch sehr einfach weiter genutzt werden. Wer die Funktion für überflüssig hält, muss das Gadget ja nicht nutzen, insofern sehe ich nicht, wieso hier irgendwem irgendwas vorgeschrieben werden solle. Eher wird ja wohl uns vorgeschrieben, dass wir keine Nummerierung verwenden sollten. Ich verstehe nicht, wieso sich hier so vehement gegen ein Gadget gewehrt wird. -- Chaddy · D 21:09, 7. Nov. 2021 (CET)

Die Behauptung „war für viele sehr nützlich“ bedürfte eines Beleges.

• Irgendwie kann ich die an einer Hand abzählen.
• Für solchen Nischenbedarf gibt es schon seit einem Jahrzehnt keinerlei Community-gepflegte Gadgets mehr, sondern ausschließlich Benutzerskripte.
• Ein Community-Gadget muss auf der Hand liegend, offenkundigen, in sich überzeugenden Bedarf für Tausende aktiver und ggf. sogar nicht angemeldeter Benutzer zeigen. Das wird hier aber ganz offensichtlich kilometerweit verfehlt; die Denkweise ist sogar als schädlich weil statisches Papier-Denken weiterführend einzuordnen.
• Es gibt eine Reiehe von Benutzerskripten, etwa den fliegelflagel oder die PDD-Bibliothek, die bald hundertfach häufigere Einbindungszahlen haben als für diese dynamischer Dokumententwicklung widersprechende Abschnittsnummerierung zu erwarten ist.

„aber 99+ % aller Wikipediabenutzer wissen entweder nichts“

• Und >99,9 % aller angemeldeten und 100 % aller IP benötigen keine Abschnittsüberschriftsnummerierung und vermissen auch keine.

Aus WP:CSS lassen sich Hunderttausende und Millionen Privatgeschmack-Dekorationen basteln.

• Das bedeutet aber noch lange nicht, dass die Community-Software-Betreuung dazu verpflichtet wäre, jetzt allen Benutzies jede erdenkliche Privat-Dekoration als separates offizielles Gadget anzubieten.
• Wobei dann gleich die nächsten jammern und wehklagen, es würde viel zu viele Möglichkeiten geben und sie würden sich schon heute nicht durch die ganzen Einstellungen und Extras hindurchfinden, und es wäre viel zu viel Angebot.

Hier will eine Handvoll Angemeldeter eine Privat-Dekoration, für die projektweit kein Interesse besteht, und die obendrein schädliche Nebeneffekte (Weiterleben in der Papierwelt des letzten Jahrhunderts) befördert.

• Wenn diese Handvoll Benutzies das gerne haben will, und nachweislich schon längst weiß wie sie das für sich umsetzen können, dann hätten sie schon längst verständlich im BNR eine Anleitung, Erklärung und Dokumentation schaffen können, und dieses Theater wäre lange erledigt.
• Es gibt nicht für jedes Fitzelchen für jede Handvoll Lautstarker ein individuelles Community-Gadget.
• Diese Community hat keine Kapazitäten mehr zur Software-Pflege.
• Wir hangeln uns am Abgrund vor einem Tsunami ungeklärter Altlasten an einer dünnen Wäscheleine entlang.
• Auf gar keinen Fall werden neue Pflegefälle geschaffen für randständige Privat-Dekorationen.
• Und was für ein fünfaktiges Shakespeare-Drama aufgeführt würde, wenn ein Community-Gadget für ein halbes Dutzend lautstarker Es-muss-alles-immer-so-bleiben-wie-es-immer-schon-war erstellt werden würde, und dann eines Tages nicht mehr funktioniert, das lässt sich an den in diesem Abschnitt bereits sinnlos verpulverten Ressourcen ablesen.

Also erstellt endlich euer elendes BNR-Dings, dokumentiert es verständlich, pflegt es selber, und Ende Banane.

• Oder kopiert euch jetzt gleich sofort die dämlichen zwei Zeilen.
• Wir bieten seit anderthalb Jahrzehnten BNR-Ressourcen an, und Tausende von Benutzies haben es auf die Reihe bekommen, sich gemäß Anleitung in der Wikitext-Dokumentation zumindest die Basis-Einbindung abzukopieren. Und die sind kaum pauschal alle als angebliche „Nerds“ wegzudiskutieren. Die einschlägigen BNR-JS-CSS-Seiten sind voll davon: CSS 6.693 / JS 11.992

VG --PerfektesChaos 10:47, 8. Nov. 2021 (CET)

Die Abschnittsnummerierung war, als sie noch in den Einstellungen verfügbar war, standardmäßig ausgeschaltet. 90 Prozent der Benutzer*innen dürften in ihren persönlichen Einstellungen wohl nichts oder nur das Wichtigste aktiv verändert haben. Insofern ist es nicht verwunderlich, dass die Abschnittsnummerierung selten verwendet wurde. Dieses Argument ist unfair.

Und ansonsten ist das mal wieder ein ganz typischer, hochgradig arroganter Kommentar von dir. Muss das sein? ---- Chaddy · D 19:08, 8. Nov. 2021 (CET)

Nach drei Monaten ohne Kommentare und ohne projektweite tausendfache Unterstützung nunmehr Spezial:Diff/217123952 re-revertiert.

• Kein dringender projektweiter Bedarf ersichtlich.
• Keine ewige Pflege durch die Community zu rechtfertigen.
• Auf Ebene einer durch Einzelbenutzer angebotenen, dokumentierten und gepflegten BNR-Ressource ohne Weiteres für die wenigen Interessierten umsetzbar.

VG --PerfektesChaos 17:41, 9. Feb. 2022 (CET)

Archivierung dieses Abschnittes wurde gewünscht von --MGChecker – (📞| 📝| ) 10:14, 9. Nov. 2021 (CET), Hier wurde doch jetzt wirklich genug Zeit verschwendet.

prettytable im ANR vergrämen

Seit 2012 bis vor einem guten Jahr wurde daran gearbeitet, prettytable aus dem ANR, aus allen Vorlagen und allen aktuellen offiziellen Projektseiten zu eliminieren.

• Crazy1880, eine bekannte IP und diverse andere hatten daran mitgewirkt und Zigtausende rausgeworfen.

Alle paar Monate findet sich noch jemand, der die Klasse frisch im ANR verbaut.

• Manchmal IP (offenkundig von damals), manchmal Altgediente, die alle zwei Jahre einen Edit machen, auch seeehr langjährige Admins.
• Teils Stinkstiefel von Wikifanten mit sechsstelligem Editcount.
• Um auf der jeweiligen BD aufzuschlagen, und das zu erklären, fehlt meist die Kommunikationsbasis.
• Story im Lauf der Zeit.
• prettytable hatte 2006–2008 Bestand, seit 2008 ist es wikitable, aber es hat immer noch nicht jeder gerafft. Obwohl die Umstellung viermal so lange her ist wie die ursprüngliche Lebenszeit.
• Beliebtes Argumentationsmuster ist, dass alles, was 2007 mal richtig gewesen war, bis zur Sternenzeit 23456 durch das Projekt und MediaWiki unterstützt werden muss, und umzulernen sei eine absolute Zumutung.

Ich hätte deshalb gern in MediaWiki:Common.css nach der prettytable-Spezifikation:

/* Temporäres Vergrämen aus dem ANR */
.ns-0 table.prettytable::before {
   background-color: #FFFF00;
   content: "class=prettytable ist veraltet, wikitable verwenden";
   color: #FF0000;
}
.ns-0 .prettytable {
   background-color: #FF69B4;
   border: 1em solid #FF0000;
}
.ns-0 table.prettytable > * > tr > th,
.ns-0 table.prettytable > * > tr > td {
   border: 1em solid #FF0000;
}

Serviervorschlag

Zelle	Zelle	Zelle
Zelle	Zelle	Zelle

Wenn sich dann wer beschwert, und auf FZW aufschlägt, dem wird sich das auch durch den vorangestellten Meldungstext leicht erklären lassen.

Mittelfristig müsste die Eliminierung aus anderen Bereichen angegangen werden.

• Jetzt zum Jahreswechsel steht wohl grad das Ende der JavaScript-wikibits bevor, nach zehn Jahren Migrationszeit.
• Da gibt es wieder Aufstand – prettytable besser im Frühjahr 2022.
• Ein Artikel im Kurier sollte dazu auffordern, seinen BNR, seine Redaktionsseiten und WikiProjekt und Portal entsprechend durchzusehen.
• Wer nicht auf wikitable umstellen möchte, also Kopfzellen explizit färben, kann die neue Vorlage:Tabellenstile einbinden und gut ist.
• Zum Jahreswechsel 2022/2023 mag dann die Bereitstellung in MediaWiki:Common.css wegfallen. Dann ist die Tabelle halt ohne Linien und so; ist aber immer noch eine Tabelle.
• Diesem und jenem entnehme ich dafür gewisse Sympathie.
• Im ANR mögen Regeln .ns-0 noch einige Jahre weiterwirken. Ist halt ein Lernprozess, und da lernen manche schneller als andere.

VG --PerfektesChaos 02:18, 3. Dez. 2021 (CET)

Klingt soweit gut, ich warte noch ein Weilchen und setze das dann demnächst mal um. -- hgzh 22:55, 13. Dez. 2021 (CET)

 Ok ist live. -- hgzh 21:48, 23. Dez. 2021 (CET)

Keine Reklamationen eingegangen. VG --PerfektesChaos 17:44, 9. Feb. 2022 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:44, 9. Feb. 2022 (CET)

float-right/float-left

Auf Geräten mit geringer Bildschirmbreite führt die aktuelle Definition der float-Klassen zu unschönen Ergebnissen. Insb. float-right führt in einer Vielzahl von Fällen zu Bildern die über den linken Rand hinausschauen (in diese Richtung kann man bekanntlich nicht einmal scrollen). Man sieht dies bspw. im Artikel Erster Weltkrieg oder Benton Street Bridge. Beheben lässt sich dies durch jeweils Einfügen von max-width: 100%; also Änderung des entsprechenden Teils von Mediawiki:Common.css zu

.float-left {
	clear: left;
	float: left;
	margin: 1em 1em 1em 0;
	max-width: 100%;
}
[…]
.float-right {
	clear: right;
	float: right;
	margin: 1em 0 1em 1em;
	max-width: 100%;
}

Ich habe dies in meine persönliche common.css aufgenommen und konnte noch keine negativen Auswirkungen entdecken. Liebe Grüße, KPFC 💬 23:10, 18. Jan. 2021 (CET)

Mag sein, mag nicht sein.

Die Auswirkungen können jedoch komplex sein und sind nicht trivial zu überblicken.

Intensive Recherchen bei MW und in anderen Wikis (en) sind zunächst erforderlich, um dies weiter zu analysieren. Es stellt sich auch die Frage, ob das Gesamtverhalten nicht einer Serie von Browserversionen oder einer einzelnen Engine zuzuordnen ist und nach einem Bugfix wieder verschwände.

Mir war bislang noch niemals ein Nachteil aufgefallen, und auch nicht in dem angeführten Beispiel.

Eine längere Beobachtungszeit durch individuelle Erprobung´ist zunächst erforderlich. Ich habe das in mein CSS aufgenommen und werde einige Wochen darauf achten; insbesondere auf vorstellbare Kollateralschäden. Mobilgeräte sind besonders zu untersuchen. Bislang hatte noch nie jemand von einem derartigen Problem berichtet.

Benton Street Bridge ist auch einfach schlecht gemacht. Die starren Doppelbilder sind ungeschickt, es ist keine Mindestbreite der verbleibenden Textspalte programmiert worden, und in #Baustellen­schweißungen und Betonierung sowie #Bürgersteig usw. sind zwei Einzelbilder starr nebeneinander layoutet worden. Intelligentes Design sähe anders aus; die Doppelbilder würden sich in zwei Bilder übereinander auflösen, sofern die Bildschirmbreite dies erfordert. Dafür ist allerdings teilweise zu wenig Text für zu viel Bild vorhanden. Nebenbei, warum eigentlich fest vorgegebene Auflösungen? Wir verwenden in der Regel raum- und ressourcensparende Miniaturbilder.

„führt in einer Vielzahl von Fällen zu Bildern die über den linken Rand hinausschauen“ – das weist eher auf ein anderes Problem hin, das nicht per CSS zu lösen ist: Autoren haben aus Jahrzehnten Desktop-Gewohnheit in Hunderttausenden von Artikeln überbreite und starre Datentabellen verbrochen, bzw. Layout-Tabellen für breite Bildschirme fest vorgegeben. Das lässt sich mit einer CSS-Deklaration auch nicht geradebiegen.

Danke für die Anregung jedenfalls.

VG --PerfektesChaos 01:02, 20. Jan. 2021 (CET)

In den angegebenen Beispielen sieht man es nicht mehr, weil ich die Vorlage geändert habe.

Vielleicht ist es bei erneuter Betrachtung doch leichter es in den konkreten Fällen zu beheben statt die common.css zu ändern, template-styles bieten da jetzt ja echte Möglichkeiten. Ich hatte auch in Erinnerung, dass starr eingebundene Bilder wie [[File:test.png|1000px|rechts]] zum gleichen Problem führen, aber das ist offensichtlich nicht mehr der Fall. Liebe Grüße, KPFC 💬 02:13, 20. Jan. 2021 (CET)

Statt der starren Doppelbilder in statischer Anordnung und fester Abmessungen und mit rücksichtsloser Zerquetschung der verbleibenden Textspalte wäre es in Benton Street Bridge die simple Lösung, Galerien zu zwei Bildern unterhalb des Textabsatzes anzuordnen. Die haben von Hause aus Miniaturbilder in Größe der aktuellen Benutzereinstellung, und wenn die Bildschirmbreite nicht ausreicht, dann werden sie untereinander angeordnet.

Gegen schlechtes Papier-Design mit dem Weltbild „Ich habe einen Desktop und ein breites Browserfenster und wer das nicht hat soll meinen Artikel dann halt nicht lesen“ hilft auch keine CSS-Frickelei. Das ist schon mit schmaler gezogenem Browserfenster (wie oft bei mir) katastrophal, dazu braucht das Smartphone nicht für erfunden werden.

VG --PerfektesChaos 16:11, 20. Jan. 2021 (CET)

Grundsätzlich: Ich habe in der Vergangenheit auch schon diverse Infoboxen dahingehend überarbeitet (mit max-width:100%), das Problem ist sicher nicht so selten (speziell sichtbar bei richtig schmalen Bildschirmen, die möglicherweise bald wieder mehr in Mode kommen). Die vorgeschlagene zentrale Lösung muss ich mir aber noch in Ruhe anschauen. Gruß–XanonymusX (Diskussion) 16:15, 20. Jan. 2021 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 18:23, 24. Feb. 2023 (CET)

Explizite Vordergrundfarbe für .zebra

Wie hier diskutiert, sind Tabellen mit der Klasse zebra für zeilenweise wechselnde Hintergrundfarbe im Darkmode der App (zumindest iOS) unlesbar. Daher sollte eine explizite Schriftfarbe (z.B. color: white) angegeben werden, die die Heuristik dann invertieren kann.

Alternativ könnte .zebra auch ganz gelöscht werden, da solche Formatierungen ohnehin nicht in die Hände von Artikelautoren gehören. — Christoph Päper 23:16, 8. Jul. 2021 (CEST)

TL;DR: Der Vorschlag ist abzulehnen.

Die Hinterlegung erfolgt unter Beibehaltung der schwarzen Schriftfarbe typischerweise mit sehr hellem grau, blassgelb, hellblau usw.

Eine Umsetzung des Vorschlags würde unsere Artikel für alle unlesbar machen, die nicht einen invertierenden Nachtmodus verwenden: sehr hellem grau, blassgelb, hellblau usw.

Momentan verwenden 16.758 Artikel diese Darstellung.

• Sie wurde vor über zehn Jahren eingeführt.
• Sie ist sehr beliebt, weil damit umfangreiche Datentabellen besser zeilenweise gelesen werden können.
• Die Behauptung, das würde angeblich „nicht in die Hände von Artikelautoren gehören“, ist nicht nachvollziehbar; noch weniger vor dem Hintergrund [sic!] der begehrten Vordergrundfarbe und der daraus für alle anderen resultierenden Konsequenzen.

Allgemein sind Wikiseiten für einen Nachtmodus ungeeignet, wie bereits auf FZW dargestellt.

• Erst recht, wenn ein solch strunzdummer Invertierungsalgorithmus verwendet wird wie offenbar bei iOS-App.
• Ein halbwegs intelligenter Nachtmodus erkennt die Kontraste und würde den Beispielfall dann etwa darstellen in sehr hellem grau, blassgelb, hellblau.
• Allerdings bleiben die meist nicht innerhalb der Grundfarbe, sondern spiegeln auf dem Farbkreis und reduzieren wegen Schlummer auch noch den Blau-Anteil im Spektrum, weshalb aus grün dann rot wird, und rote Zahlen grün usw.
• Im günstigsten Fall ist Österreichs Flagge dann rosa-schwarz-rosa.
• Nachtmodus ist nur dort einsetzbar, wo die Seiten nur schwarz und weiß und vielleicht noch blaue Buttons kennen, und Farben keine bedeutungstragende, sondern lediglich dekorative Funktion hätten.

VG --PerfektesChaos 03:12, 9. Jul. 2021 (CEST)

/*
 * Zebra-Tabellen. Bei Verwendung zusammen mit „rowspan“ richtet sich die Farbe
 * jeder Zelle nach der ersten Zeile, zu der die Zelle gehört.
 */
table.wikitable.zebra > tbody > :nth-child(even):not([class*="hintergrundfarbe"]) {
	background: white;
    color: black; /* diese Zeile soll hinzugefügt werden */
}

Die derzeitige Formatierung der Klasse zebra ist halt sehr naiv und zerbrechlich. Die Zugänglichkeitsempfehlungen waren schon immer, Vorder- und Hintergrundfarben stets gemeinsam festzulegen, damit ausreichender Kontrast sichergestellt ist. Hier wurde das nicht eingehalten und jetzt kracht es.

Ich habe mich gestern vertan, natürlich sollte das color: black heißen.

Ich sehe nicht, wie das zu Problemen mit anderen Hintergrundfarben führen sollte, unabhängig davon, dass die natürlich auch nur zusammen mit einer Schriftfarbe gesetzt werden sollten. — Christoph Päper 21:41, 9. Jul. 2021 (CEST)

PS: Außerdem geht es hier nicht um eine Fehldarstellung in irgendeinem obskuren Browser, sondern in der offiziellen App. 22:01, 9. Jul. 2021 (CEST) (unvollständig signierter Beitrag von Crissov (Diskussion | Beiträge) )

Nur zum letzten Satz: Die offizielle App ist allerdings doch ziemlich „obskur“ und wird so gut wie nicht verwendet, daher werden viele bekannte Fehler nicht behoben, obwohl gerade die offizielle App einfach auf WP-Eigenheiten anzupassen wäre. Beispielsweise werden bestimmte Infoboxen in der App komplett verschluckt, was auch noch nie korrigiert wurde. Ich würde die Apps nach wie vor als ein Experiment betrachten, nicht mehr.–XanonymusX (Diskussion) 18:38, 11. Jul. 2021 (CEST)

Ich finde, man könnte die Vordergrundfarbe in diesem Fall schon per default setzen. So blöd wie die App und ihr Nachtmodus hier ist, sie wird offensichtlich verwendet und eine Anpassung kostet uns nicht wirklich was, hilft aber dem Leser. -- hgzh 15:39, 11. Sep. 2021 (CEST)

Ich möchte den Vorschlag, Hintergrundfarben nur zusammen mit Vordergrundfarben zu setzen, auf die hintergrundfarbe{1…9}-Klassen ausweiten. Deren Farben (_ _ _ _ _ _ _ _ _) sind so gewählt, dass sie mit schwarzer Schrift funktionieren, daher sollten allen color: black; hinzugefügt werden. So sind sie derzeit in MW:Common.css definiert (Zeilenumbrüche in Selektoren zur Übersichtlichkeit entfernt):

/* Wie Inhaltsverzeichnis (mediawiki.skinning/content.css) */
table > * > tr.hintergrundfarbe1 > th, table > * > tr > th.hintergrundfarbe1, table.hintergrundfarbe1, .hintergrundfarbe1 {
	background-color: #f8f9fa;
}
/* „Weiß“, für Nicht-Artikel-Seiten, neutral */
table > * > tr.hintergrundfarbe2 > th, table > * > tr > th.hintergrundfarbe2, table.hintergrundfarbe2, .hintergrundfarbe2 {
	background-color: #fff;
}
/* „Gelb“, auffällig */
table > * > tr.hintergrundfarbe3 > th, table > * > tr > th.hintergrundfarbe3, table.hintergrundfarbe3, .hintergrundfarbe3 {
	background-color: #ffff40;
}
/* Sehr auffällig */
table > * > tr.hintergrundfarbe4 > th, table > * > tr > th.hintergrundfarbe4, table.hintergrundfarbe4, .hintergrundfarbe4 {
	background-color: #fa0;
}
/* Neutral, abgesetzt */
table > * > tr.hintergrundfarbe5 > th, table > * > tr > th.hintergrundfarbe5, table.hintergrundfarbe5, .hintergrundfarbe5 {
	background-color: #eaecf0;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe6 > th, table > * > tr > th.hintergrundfarbe6, table.hintergrundfarbe6, .hintergrundfarbe6 {
	background-color: #b3b7ff;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe7 > th, table > * > tr > th.hintergrundfarbe7, table.hintergrundfarbe7, .hintergrundfarbe7 {
	background-color: #ffcbcb;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe8 > th, table > * > tr > th.hintergrundfarbe8, table.hintergrundfarbe8, .hintergrundfarbe8 {
	background-color: #ffebad;
}
/* Allgemein „bunt“, für Hervorhebungen und Unterscheidungen */
table > * > tr.hintergrundfarbe9 > th, table > * > tr > th.hintergrundfarbe9, table.hintergrundfarbe9, .hintergrundfarbe9 {
	background-color: #b9ffc5;
}

Wir können auch gerne explizite Farbangaben für den Dunkelmodus einführen. Das geht mit @media (prefers-color-scheme: dark) {}. Da Safari diese Media-Query schon länger unterstützt, vermute ich, dass dies auch für iOS-Apps gilt. — Christoph Päper 09:00, 26. Okt. 2022 (CEST)

Der „Darkmode“ ist eine Gaga-Idee und erfordert keine Maßnahmen von unserer Seite.

Der „Darkmode“ gehört zu Webseiten, die nur die Farben Weiß, Schwarz und ein wenig Blau kennen, kein benutzerdefiniertes Styling und keine benutzerdefinierte Grafiken mit transparentem Hintergrund haben – also Twitter, Facebook, eBay, Google und so.

Für uns ist das prinzipiell nicht realisierbar, und wir werden auch keine Million Artikel umschreiben, und wir werden auch keine Autoren-Umschulung veranlassen, damit zu den Hunderten von Syntaxregeln und RK und WWNI und WSGA und barrierefreier Gestaltung und Typografie und WP:ZR nun auch noch „Darkmode“-gerechte Artikelgestaltung erlernt werden muss.

Auch mit der vorgeschlagenen Änderung kommt es zu Darstellungsproblemen, schon weil extrem oft statt class style gesetzt ist. Und ebenfalls oft sind Schriftfarben gesetzt.

Wer „Darkmode“ haben will, kann den Blau-Anteil dämpfen und gelber schalten, zum Schlummern. Unsere Artikel waren noch nie für Schwarz-Weiß-Denken konzipiert.

VG --PerfektesChaos 18:07, 29. Nov. 2022 (CET)

Ist inzwischen gelöst. -- hgzh 11:32, 7. Mai 2024 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: hgzh 11:32, 7. Mai 2024 (CEST)