Letzter Kommentar: vor 7 Monaten6 Kommentare3 Personen sind an der Diskussion beteiligt
Wo kommt das her? Sieht aus wie ein alter Importunfall. Die Seite erzeugt Linterfehler und mehr. Aber ich kann nicht erkennen wer sie hier erstellt hat. Schaust du dir das bitte einmal an? --Liebe Grüße, LómelindeDiskussion08:09, 12. Jan. 2024 (CET)Beantworten
Soll heißen, ich denke, dass die Seite gelöscht werden kann; wollte aber zumindest noch einen evtl. Einwand von M.ottenbruch hören, mit der Importupload-Funktion bin ich nicht vertraut. -- hgzh09:45, 12. Jan. 2024 (CET)Beantworten
Geschäftsgrundlage weggefallen, und hgzh hat sich grad als inaktiv abgemeldet. Ich hoffe, es braucht jetzt einfach nur mal einige Wochen Verschnaufpause, nach den stressigen letzten Wochen, und danach geht es mit frischer Kraft in die alten Äcker. LG --PerfektesChaos15:01, 23. Jan. 2024 (CET)Beantworten
Aber es war wirklich nützlich, weil es in der Tabelle angezeigt hat, dass in einer Seite gerade ein „In Bearbeitung“ drin ist, das sieht n ja sonst nicht. Schade. Und ich hoffe er bleibt nicht zu lange weg. Es gibt nicht mehr so viele hier denen ich voll und ganz vertraue. --Liebe Grüße, LómelindeDiskussion15:08, 23. Jan. 2024 (CET)Beantworten
Wenn du es doch noch gebrauchen kannst, dann kannst du es auch gern weiternutzen. Habe es wiederhergestellt. Auch @Lupe zur Kenntnis. Und ja, jetzt ist erstmal Zeit für eine Pause, aus on- und offwiki-Anlässen. Gruß, -- hgzh15:19, 23. Jan. 2024 (CET)Beantworten
Letzter Kommentar: vor 5 Monaten4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Hgzh, vor Jaaaaahren hast du mal ein Skript gebastelt mit dem du festgestellt hast, wenn die verlinkten Brandenburger Denkmal-IDs auf eine nicht existierende Seite führten. Kannst du das für Sachsen auch erstellen?
eine Wartungsliste mit "Liste" und aufgeführten nicht funktionierenden IDs
dass man das Skript in regelmäßigen Abständen starten kann
zukünftig könnte man in die sächsische Denkmalvorlage einen Parameter aufnehmen (ob sichtbar oder nicht ist egal), mit dem ehemalige IDs gekennzeichnet sind, so dass sie im Abschnitt "ehemalige" mit ID verbleiben können aber dein mögliches skript nicht stören.
Hallo @Z thomas, wir haben derzeit 103.090 unterschiedliche Links auf die Denkmaldatenbank. Wenn ich jede Sekunde einen Link abfrage (was wahrscheinlich nicht gehen wird, weil mich dann der Server der Denkmaldatenbank rausschmeißt), brauche ich ca. 29 Stunden, um alle Links zu prüfen. Mit 5 Sekunden Abstand zwischen zwei Abfragen dann bereits sechs Tage. Das wird, wenn, nur in Häppchen passieren können. -- hgzh12:58, 2. Mär. 2024 (CET)Beantworten
Hallo Hgzh, danke für die Info. Das ist aus meiner Sicht vollkommen okay. Wenn es häpchenweise kommt, ist man von der Masse auch nicht erschlagen, falls viel zu fixen ist. Viele Grüße --Thomas14:09, 2. Mär. 2024 (CET)Beantworten
Schaust du dir das bitte einmal an, da müssten alle fehlerhaften Einbindungen angepasst werden. = Aufzählungszeichen oder Doppelpunkte entfernen bzw, die Vorlage in die nächste Zeile setzen. --Liebe Grüße, LómelindeDiskussion07:36, 1. Mär. 2024 (CET)Beantworten
So etwas liegt i.d.R. an Zeilenumbrüchen innerhalb der eingebundenen Vorlagen, die dann neue Absätze innerhalb der Auflistungen erzeugen. Hängt also nur sekundär mit meinem Edit zusammen, weil ich keine neuen Zeilenumbrüche eingefügt habe. Vielmehr sind es die Umbrüche innerhalb der Vorlage:Hinweisbaustein, die aber m.E. teils beabsichtigt und teils erforderlich sind. Es wird also nötig sein, die Einbindungen zu korrigieren. Gruß, -- hgzh07:44, 1. Mär. 2024 (CET)Beantworten
Die Normdaten spezifizieren die Normdaten zum gesamten Artikelgegenstand, kann es also nur ein einziges Mal geben, und gehören unmittelbar vor dem Kat-Block eingebunden.
Mehrfache Normdaten in einem Artikel sind deshalb dummes Zeug, mehrere Normdaten in Auflistungen erst recht, und Mischungen von * und : sind ohnehin des Teufels.
Wenn das jetzt als unerwarteter Nebeneffekt dazu geführt hat, dass solche Spässkens nun offenbar werden, dann umso besser.
Wenn solche Aufzählungen gemacht werden, dann können nur mit Vorlage:GND usw. die unterschiedlichen Infos sichtbar dargestellt werden, während die ursprüngliche Intention der Normdaten gewesen war, unsichtbar zu sein, und das mit dieser ulkigen metadata-Klasse ja wohl immer noch irgendwie ausblendbar ist. Dann ist eine solche Auflistung erst recht Nonsens, weil die wesentlichen Inhalte dann futsch sind.
Letzter Kommentar: vor 5 Monaten10 Kommentare6 Personen sind an der Diskussion beteiligt
Zu: https://de.wikipedia.org/w/index.php?title=Wikipedia:Vandalismusmeldung&oldid=242711021
Wo wird hier übertrieben? Der PA ergibt sich aus der Unterstellung, dass kein Beleg angegeben sei. Der Artikel war mit dem Verweis auf die API und ergänzt mit dem Verweis auf die Dokumentation der API, sowie dem Programmauszug in der Diskussionsseite bereits mehrfach belegt. Auch ist keine hilfreiche Mitarbeit erkennbar. Ich würde mir mal wünschen, dass ihr alle Benutzer gleichermaßen behandelt und nicht einige Nutzer, wie scheinbar hier den Schotterebene bevorzugt, nur weil ihr den vermutlich schon länger kennt. Fakt ist, er hat einen Edit War gestartet, er hat eine PA begangen und er hat einen bereits belegten Artikel revertet. So und jetzt erwarte ich dass ihr ihn so ahndet, wie ihr es auch bei den anderen Nutzern immer macht. Das bedingt bereits der Gleichheitsgrundsatz. Eine dauerhafte Sperre des Nutzers Schotterebene wäre mehr als gerechtfertigt, andere Nutzer wurden bereits für viel geringeres gesperrt. --84.140.196.2514:29, 1. Mär. 2024 (CET)Beantworten
Hallo, deine VM von vorgestern war diese: Wikipedia:Vandalismusmeldung/Archiv/2024/02/28#Benutzer:Schotterebene_(erl.). Diese wurde nicht in deinem Sinn entschieden. Dass das ärgerlich für dich ist, kann ich verstehen, jedoch rechtfertigt dies nicht, zwei Tage später einfach eine neue auf Grundlage der selben Bearbeitungen zu eröffnen. Der Edit-War von vorgestern ist administrativ abschließend bearbeitet.
Die Feststellung, dass der Bearbeitung ein nachvollziehbarer Beleg fehlt, ist kein persönlicher Angriff und auch keine Unterstellung, wenn man sich die Versionsgeschichten von Vertex-Shader und Pixel-Shader ansieht: für deine ersten Bearbeitungen in diesen Artikeln war kein nachvollziehbarer Beleg angegeben. Inzwischen hast du dies nachgeholt, insofern ist mir umso weniger verständlich, warum nun die Geschichte von vorgestern wieder aufgewärmt werden musste, ohne dass seitens des Gemeldeten neue Bearbeitungen in den Artikeln erfolgt wären. Nahelegen zum Verständnis unserer Regularien zu Belegen möchte ich in diesem Zusammenhang noch einmal diesen Kommentar PaterMcFlys auf der Diskussionsseite. Generell ist es von Vorteil, Bearbeitungen immer begründet vorzunehmen und auf etwaige Widersprüche oder fehlende Belege im Bestehenden hinzuweisen - und eben die Belege für die geänderten Aussagen gemäß unserer Richtlinien anzugeben.
Im Übrigen ist es keineswegs Fakt, dass der Benutzer Schotterebene den Edit-War (siehe Definition dort) gestartet hätte, denn der erste Revert einer begründet zurückgesetzten Änderung erfolgte von dir.
Die Aussagen zur vermeintlichen Bevorzugung und zur Sperrwürdigkeit des Verhaltens nehme ich als in Verärgerung getroffen zur Kenntnis, kann dir aber versichern, dass eine derartige Sperrsanktion in diesem Fall nach gängiger Praxis als überzogen betrachtet werden würde und in einer Sperrprüfung keinen Bestand hätte. -- hgzh15:01, 1. Mär. 2024 (CET)Beantworten
Nein, wenn du dir die Artikelhistorie mal ganz genau ansehen würdest, dann würdest du erkennen, dass er den Edit War erst ca. 1 h später um 20:25, 28. Feb. 2024, nämlich nach dem euer anderer Admin Benutzer:Holder, schon längst auf die erste Vandalismusmeldung um 19:39, 28. Feb. 2024 reagiert und diese beendet hat, gestartet hat. Bei der ersten Vandalismusmeldung ging es auch nicht um einen Edit War, sondern um die fehlende Mitarbeit, die Störung von Artikeländerungen und seine Vorwürfe gegen mich in seinen Vandlismusmeldungen, weil ich meine erste Änderung nicht mit Belegen versehen hatte, was übrigens freiwillig und kein Zwang ist.
Wir haben hier also die Konstellation, dass Schotterebene mehrfach den Artikel revertet hat. Das erste mal Morgens um ca. 6.
Dann wurde der Artikel belegt, siehe Diskussionsbereich 12:15, 28. Feb. 2024 und meinen Revert mit angefügtem Belegt um ca. 12:11, 28. Feb. 2024 in der Artkelhistorie mit extra Verweis auf die API. Das führte dazu, dass er seine unberechtigen Vandalismusmeldungen gegen mich startete, worauf ich dann mit der ersten Vandalismusmeldung gegen ihn reagiert habe.
Und dann, als die erste Vanadlismusmeldung um ca. 19:39 Uhr vorbei und abgehakt war, hat er eine Stunde später um 20:25 Uhr, als ich schon längst die WP verlassen hatte, den bereits mehrfach belegten Artikel nochmals reverted und somit wurde damit der Tatsachenbestand des Vandalismus und der PA erfüllt, denn der Artikel war belegt, weswegen die heutige neue Vandalismusmeldung nötig war.
Die erste Vandalismusmeldung hat mit der heutigen also gar nichts zu tun. Bei der ersten ging es auch nicht um einen Edit War und da gab es auch noch keinen PA, sondern in der ersten ging es um Vandalismus eines bereits belegten Edits und das, was ich gerade eben oben bereits schon erwähnte.
Insofern, nochmal, das alte hat mit dem heutigen nichts zu tun. Bei der heutigen Vandalismusmeldung geht es um einen Edit-War, sowie im Grunde auch um Vanadlismus einer bereits mit Quellen belegten Artikeländerung und eines PA und daher erwarte ich jetzt zu Recht, dass ihr entsprechend diesen Vandalsimus des Nutzers Schotterebene ahndet, das erwarte ich übrigens immer noch. Die VM habt ihr zwar als erledigt markiert, aber wie man hier nun sehen kann, habt ihr den Sachhergang gar nicht richtig nachvollzogen.
Zu:
Die Feststellung, dass der Bearbeitung ein nachvollziehbarer Beleg fehlt, ist kein persönlicher Angriff
Doch, das ist ein PA, weil es keine Feststellung ist, sondern eine unwahre Behauptung. Der Beleg befindet sich nämlich in der Diskussionsseite https://de.wikipedia.org/wiki/Diskussion:Shader#Anderes_Thema und im Historytext der Änderung vom 12:11, 28. Feb. 2024 in deren Beschreibungstext der Satz steht "Quelle: OpenGL und DirectX API". Die Quelle war damit bereits mehrfach belegt.
Zu:
wenn man sich die Versionsgeschichten von Vertex-Shader und Pixel-Shader ansieht:
Es geht hier nicht um die Artikel Vertex- und Pixelshader, bitte bleibe beim Thema.
Zu:
insofern ist mir umso weniger verständlich, warum nun die Geschichte von vorgestern wieder aufgewärmt werden musste
Weil es zwei verschiedene Vandalismustätigkeiten sind! Siehe oben. Schau doch bitte mal ganz genau auf die History des Shader Artikels und dessen Diskussionsseite. Achte auf die Zeiten, wann was gemacht wurde. Das ist heute ein komplett neuer Fall.
Zu:
Im Übrigen ist es keineswegs Fakt, dass der Benutzer Schotterebene den Edit-War (siehe Definition dort) gestartet hätte, denn der erste Revert einer begründet zurückgesetzten Änderung erfolgte von dir.
Das stimmt nicht, denn mein Revert wurde um den Quellenbeleg ergänzt, da steht nämlich "Quelle: OpenGL und DirectX API". Es war also kein Start eines Edit-War, sondern ein Nachkommen der Belegerrei.
Und dann hat er den Edit-War mit einem weiteren Revert gestartet, obwohl schon alles belegt war.
Dass ihr die angemeldeten Benutzer besser behandelt als IPs ist allgemein bekannt, das habe ich schon öfters feststellen müssen und nein, damit meine ich jetzt nicht irgendwelche Vandlismustätigkeiten von IPs, die es natürlich auch gibt, sondern um so Fälle wie diesen hier. --84.140.196.2515:55, 1. Mär. 2024 (CET)Beantworten
Gut, da muss ich mich korrigieren, dass der zweite Revert nach der abgeschlossenen VM erfolgte, hatte ich übersehen; bitte um Entschuldigung. Es bleibt aber dabei, dass Quelle: OpenGL und DirectX API keine ausreichende Belegangabe ist – in diese Richtung stieß auch Holders VM-Entscheid – und somit die Belegpflicht, auf die in der Rücksetzung Bezug genommen wurde, nicht erfüllt ist; ebenso bleibe ich bei meiner letzten Aussage zur Sperrwürdigkeit.
Dass es IPs hier leider schwerer haben, bestreite ich im Übrigen nicht. Wenig hilfreich ist dann aber, den Vorgang mit mehreren „Begleit-VMs“ (wohlwollend gesagt), die mit dem eigentlichen Problem nichts zu tun haben, mehrfach zu eskalieren.
Ich habe die Änderungen in den drei Artikeln nun gesichtet, sodass vielleicht nun langsam die Rückkehr zur Sachebene möglich ist. -- hgzh12:50, 2. Mär. 2024 (CET)Beantworten
Da muss ich entschieden widersprechen, denn die API ist praktisch die Dokumentation. Jeder Programmierer mit Ahnung wird dir bestätigen können, dass die API die beste Form der Dokumentation ist. Die API ist standardisiert und auch dokumentiert. Alle Funktionen sind in den entsprechenden Implementationen aus den C Header Dateien ersichtlich und dort auch kommentiert. Damit ist es die beste Form des Quellenbelegs überhaupt. Bücher sind dies nicht, denn die können Fehler enthalten und sind damit eine deutlich schlechtere Form des Quellenbelegs. Damit ist auch der Edit-War von Schotterebene erfüllt. Außerdem war auch bereits auf der Diskussionsseite auf die Dokumentation der API verwiesen. Es fehlt also noch eine Sperre des Nutzers Schotterebene für den Edit-War, allein schon der Gerechtigkeit willen. IPs bekommen dafür in der Regel eine Sperre von einem ganzen Tag. --84.158.122.10418:47, 2. Mär. 2024 (CET)Beantworten
Hallo, eine Prüfung sollte theoretisch gehen, muss ich mir angucken. Zumindest für den zweiten Fall meine ich aber, eine derartige Liste schon einmal gesehen zu haben. Gruß, -- hgzh08:23, 25. Mär. 2024 (CET)Beantworten
Letzter Kommentar: vor 5 Monaten6 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo hgzh, gibt es eine Funktion, die prüft, ob eine Commonscat existiert.
Hintergrund meiner Frage ist, dass in der Vorlage:Auflösungsjahr der link zur Commonscat integriert ist und erzeugt wird, auch wenn die cat nicht existiert. Das ist natürlich blöd. Gibt es die Möglichkeit, vor erzeugen des links das Ziel zu prüfen und erst dann den link zu erzeugen?
Moin Thomas, eine eingebaute Funktion, die Existenzprüfung von Seiten auf anderen Projekten bewerkstelligt, gibt es leider nicht. Gruß, -- hgzh08:21, 25. Mär. 2024 (CET)Beantworten
Letzter Kommentar: vor 4 Monaten3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Hgzh, ich sah drei sinnlose IP-Bearbeitungen im Artikel Andrea Bocelli seit dem 3. März 2024, zwei davon gestern. Wenn das nicht reicht, um den Artikel für einige Zeit vor Unsinn zu schützen, muss es mir wohl recht sein. Trotzdem wundere ich mich wie über so vieles andere in Wikipedia. Viele Grüße -- Lothar Spurzem (Diskussion) 18:43, 9. Apr. 2024 (CEST)Beantworten
Hallo Lothar, zwei der drei Bearbeitungen stammten vom selben unangemeldeten Benutzer, den ich im Zusammenhang mit der VM auch gesperrt hatte – dies ist dann häufig zielgenauer als ein Seitenschutz, der i.d.R. erst dann vorgenommen wird, wenn über einen längeren Zeitraum gehäuft oder wirklich intensiv innerhalb weniger Tage Vandalismus auftritt. Für einen weiteren, zeitlich vorher liegenden Revert müsste man schon über ein Jahr in den Januar 2023 zurückgehen, und dazwischen gab es zwei IP-Bearbeitungen, die sinnvoll waren, gesichtet worden sind und durch einen langfristigen Schutz möglicherweise so nicht zustandegekommen wären. Standardmäßig sollte die Wikipedia ja für alle bearbeitbar sein.
Danke für die Erläuterung. Da kann ich allerdings gleich ein Weiteres anschließen, nämlich dass meiner Meinung nach nur angemeldete Benutzer aktiv sollten mitarbeiten können, deren Identität einem kleinen Kreis von Admins bekannt ist. Dem kann man freilich entgegenhalten, dass dadurch auch mancher gute Beitrag vorenthalten bliebe. Ich weiß zum Beispiel nicht, wie sich ein E-Mail-Bekannter von mir verhalten würde, der immens viel über Automobiltechnik weiß und als IP in Wikipedia beiträgt. Seit Jahren bitte ich ihn, sich als Benutzer anzumelden, doch er lässt sich nicht dazu überreden. Aber stell Dir vor, alle würden nur anonym wirken und werkeln. Wie ernst wäre dann Wikipedia noch zu nehmen und würde sie überhaupt noch existieren? Herzliche Grüße -- Lothar Spurzem (Diskussion) 23:12, 9. Apr. 2024 (CEST)Beantworten
Letzter Kommentar: vor 4 Monaten2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Hgzh,
du hast gestern scheinbar eine Anpassung bei der Auswertung durchgeführt, was zu einer leichten Reduzierung der Link-Zahlen geführt hat. Was wurde bei der Anpassung geändert? --Vfb1893 (Diskussion) 08:54, 17. Apr. 2024 (CEST)Beantworten
Hallo, ich hatte gestern eine ohnehin erforderliche Umstellung vorgenommen und dabei die Funktion eingebaut, dass Links, die von Begriffsklärungsseiten kommen, nicht gezählt werden. Diese sind dort ja in den meisten Fällen bewusst gesetzt. Gruß, -- hgzh09:00, 17. Apr. 2024 (CEST)Beantworten
Es könnte durchaus sein, dass das Gadget irgendwann wieder einen Anwendungsfall hätte. Wenn ich es aus der Definition entferne, kann es nicht einfach reaktiviert werden. Solange frisst es kein Brot. -- hgzh17:52, 20. Apr. 2024 (CEST)Beantworten
Jetzt habe ich mich erst dumm und dämlich probiert, weil mich PuTTY überhaupt nicht mehr verbinden wollte... Lösung: das olle Ding einfach aktualisieren. Hatte ich kürzlich erst beim Dongleserver-Manager auf Arbeit...
Ok, mit webservice --backend=kubernetes php8.2 shell bekomme ich eine Umgebung, in der ich die PHP-Skripte wieder aus der Shell heraus starten kann. -- hgzh22:07, 22. Apr. 2024 (CEST)Beantworten
Ja, mit "webservice --backend=kubernetes php8.2 shell" geht es, nervt halt nur ein wenig – irgendwann gibts bei längerer Untätigkeit ein Timeout und du fliegst raus. Und wenn man dann einen Job startet, muss man auch raus. Dachte du hast Ahnung und die hast du, weil du hast die Mail hervorgezaubert ;^) --Wurgl (Diskussion) 22:18, 22. Apr. 2024 (CEST)Beantworten
Die hab ich gefunden, aber sonst stolper ich in der ganzen Toolforge-Umgebung mehr oder weniger rum. Ob es jetzt Sinn hat, da im Phab um PHP-Unterstützung zu bitten, weiß ich nicht. Möglicherweise gibt's ja auch einen Grund dafür, dass es so ist, wie es ist... aber umständlich ist es jetzt allemal, da hast du Recht. -- hgzh22:50, 22. Apr. 2024 (CEST)Beantworten
Also das soll so sein und sie hoffen dass es so bleiben kann. "webservice php8.2 shell -- php <script>" <-- so kann man direkt was starten. Also ich kann mit diesen Einschränkungen leben, toll ist halt anders, ---Wurgl (Diskussion) 07:28, 23. Apr. 2024 (CEST)Beantworten
Letzter Kommentar: vor 3 Monaten19 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, bezüglich abbr in der Mobilversion: Momentan ist das mobil ziemlich sinnlos, da auf Tap ja kein Tooltip erscheint. Damit verwirrt die Unterpunktung eigentlich nur unnötig. Meinst du, es würde sich lohnen, für diesen Fall CSS-Tooltips (wie bspw. in den Charttabellen) einzuführen? Wäre aber ohne Vorlage ein ziemlicher Eingriff. Gruß --XanonymusX (Diskussion) 20:14, 24. Apr. 2024 (CEST)Beantworten
Hallo, danke für's aufpassen – hatte die mobile Website im Desktopbrowser aufgerufen, die mobilen Browser scheinen die Unterstreichung offenbar (sinnvollerweise) ganz zu unterdrücken, jedenfalls tut dies mein mobiler Firefox. Dann passt das Argument natürlich nicht mehr. Vielleicht bieten andere Browser schon ein Tooltip an? Könnte ich mir zumindest vorstellen.
Die CSS-Tooltips wären eine Überlegung wert, ich denke, das bekommt man inzwischen sogar mit reinem CSS und ohne Dopplung des Contents hin, aber da muss ich mal ein bisschen recherchieren und testen. Gruß, -- hgzh20:25, 24. Apr. 2024 (CEST)Beantworten
Ich sehe hier in Safari unter iOS die Punkte, die bei Tap jetzt sogar Farbe wechseln, aber leider ohne sonstige Wirkung. Tooltips für title-Attribute werden meines Wissens nie auf Tap angezeigt, unabhängig von Browser oder OS, da scheint sich in all den Jahren nichts getan zu haben. Aber gut, noch ein Thema zur Beobachtung! --XanonymusX (Diskussion) 21:19, 24. Apr. 2024 (CEST)Beantworten
Habe mal ein bisschen gebastelt, folgendes könnte funktionieren, CSS-only und ohne Änderungen am DOM:
Ach ja, und zum Nachtmodus: Bei den Musikvorlagen macht mir die Navigationsleiste Musik / Navbox die meisten Sorgen, da sind viel zu viele Farben vorgegeben und die momentan dargestellten Rahmen sind ziemlich hässlich. Das Zusammenspiel mit dem NavFrame ist auch noch nicht optimal. In enWP scheint Jon auch schon an der Anpassung der Navbox gescheitert zu sein (lässt sich durch die Entfernung der Navbox mobil in enWP aber auch nicht sinnvoll testen). Bin da etwas unsicher, wo ich ansetzen soll.
Und bei den Charttabellen und Nummer-eins-Listen habe ich die Schriftfarben mal alle korrigiert, allerdings sind sie für einen Nachtmodus eigentlich etwas zu farbig; aber wenn ich die Hintergrundfarben aufgebe, geht auch der Zebraeffekt verloren, das wäre wohl nicht hilfreich. Gruß --XanonymusX (Diskussion) 14:13, 27. Apr. 2024 (CEST)Beantworten
Zu den Charttabellen: die normalen Zebra-Tabellen alternieren im Nachtmodus zwischen #202122 und #000000, vielleicht ist das eine Option. Der Tabellenkopf kann ja trotzdem farbig bleiben, als Erkennungszeichen, nur etwas dunkler.
Durch die Navbox bin ich auch noch nicht durchgestiegen. Dazu kommt, dass es ja zwei Implementierungen gibt. Ich würde es erstmal bei der klassischen Variante probieren, vielleicht ergeben sich ja daraus Erkenntnisse. Die beiden Farbschemata würde ich im Nachtmodus gnadenlos überschreiben, die unterscheiden sich schon auf dem Desktop nicht wirklich.
Ja, wäre ein Luxus, wenn wir die Navbox-Umstellung schon flächendeckend hinter uns hätten, aber mir ist leider nach der Navigationsleiste Musik der Atem ausgegangen. Wenn ich dazu komme, muss ich mal schauen, was die in enWP mittlerweile bei den Stilen geändert haben, vielleicht kann auch Jon schon mal einen Blick auf die deutsche Version werfen. Deine Änderungen an der Legacy-Version behalte ich auf jeden Fall im Auge.
Schwarzton werde ich noch ändern, war mir entgangen. Für Zebra könnte ich eventuell im Nachtmodus die Graustufen-Variante (wie hier) verordnen, die wäre dann auch ohne eingefärbten Header; aber verwendet dummerweise ebenfalls nicht die Standardklasse, dann muss ich das wohl alles ein bisschen überarbeiten. Lustig wird es speziell bei den sehr farbenfrohen Listen der Nummer-eins-Hits … Ich nehme mal Liste der IPA-Zeichen als Vorbild für zebra.
Die Infobox Chartplatzierungen sieht jetzt gut aus. Datatable habe ich korrigiert. Für die Sortierpfeile ist mir auch noch nichts eingefallen, das wird schwierig bzw. nur über eine zentrale Definition zu lösen sein. -- hgzh08:56, 29. Apr. 2024 (CEST)Beantworten
Die Erweiterte Navigationsleiste sieht jetzt ganz gut aus. Aber das sollte nur ein Zwischenzustand sein mit der Perspektive, alles auf die Lua-Variante umzustellen. -- hgzh16:58, 30. Apr. 2024 (CEST)Beantworten
Fein, danke für die Mühen! Zebra für die Navbox sollte dann kein Zauber sein, nutzt aktuell ja einfach .navbox-even und .navbox-odd. Bei den Chartvorlagen macht mir der Gedanke, die relevanten knapp 60 CSS-Zeilen für den Nachtmodus verdreifachen zu müssen, mehr Sorgen. Die komplexeren Level-4-Selektoren wie hier würden das alles deutlich erleichtern, aber sind leider noch nicht funktional …
Die Sortierpfeile sind den Developern hoffentlich schon bekannt. Ich habe zuletzt auch noch die score-Extension (Notensatz) gemeldet, die sieht aktuell im Nachtmodus grottig aus (weiß nicht, ob sich da eine lokale Korrektur anbieten würde, zusammen mit dem Overflow-Problem). Was ich mich auch noch gefragt habe: Wird erwartet, dass wir Bilder und Icons mit hellem Hintergrund jetzt alle manuell mit der entsprechenden Klasse ausstatten (habe ich etwa hier gemacht)? Scheint mir doch sehr ineffizient. Gruß --XanonymusX (Diskussion) 17:57, 30. Apr. 2024 (CEST)Beantworten
Ob man die Gruppentitel noch etwas abweichend einfärbt, würde ich mir noch überlegen, vsl. Donnerstag soll es wohl auch nochmal ein codexseitiges Farbupdate geben, dann wird sich zeigen, wie es zusammenpasst.
Zu den Chartvorlagen: ich zähle etwa 30 Vorkommen von background; wenn du mit einer dunklen Farbe auf den Nachtmodus reagierst, kannst du dir die color-Attribute schon mal sparen. Bei den zebragreys lassen sich einige Blöcke zusammenfassen, dann wird es auch noch etwas kompakter. Und charts-zebra könnte eigentlich ganz entfallen, weil die normale zebra-Klasse von wikitable inzwischen auch mobil wirkt.
Es sind nicht nur die Noten, sondern etwa auch die Math-PNGs und Hieroglyphen. Bei den Bildern werden wir wohl alles per Hand machen müssen; habe auch schon in Vorlage:SportPicto eine entsprechende Umstellung vorgenommen. -- hgzh19:34, 30. Apr. 2024 (CEST)Beantworten
Nachtrag: inzwischen sind bei den Checks über 90 Prozent der Seiten ohne Kontrastprobleme im Dunkelmodus, und insgesamt sind es auch weniger als in der Standardansicht. -- hgzh16:19, 1. Mai 2024 (CEST)Beantworten
Zu skin-invert bin ich gerade über Bundesrat (Österreich) gestolpert: Hier müsste man das Logo klar invertieren, aber bei bunten Logos wäre das wieder unpassend. Wie sollte man die Klasse in solchen Fällen zuweisen? Dürfte ja speziell bei Infoboxen mit freien Logo-Parametern recht häufig sein (die Infobox Band fällt mir dazu auch noch ein). Ziemlich blöd … --XanonymusX (Diskussion) 21:36, 4. Mai 2024 (CEST)Beantworten
Da habe ich auch schon drüber nachgedacht. Meine erste Lösungsidee war, dem Bild manuell einen hellen Hintergrund zuzuweisen, aber das klappt bei inline eingebundenen Bildern nicht. Bliebe meiner Meinung nach nur, das in der Infobox zu lösen und die Zelle auf weißen Hintergrund festzulegen. -- hgzh12:02, 5. Mai 2024 (CEST)Beantworten
Ich habe in Beta mal noch ein bisschen angepasst, jetzt sollte der manuelle Tooltip nur noch auf Touch-Geräten erscheinen. -- hgzh15:35, 27. Apr. 2024 (CEST)Beantworten
Ja, schaut gut aus! Beim z-index bin ich mir unsicher, worauf wir achten müssen, bei den Charttabellen hab ich da noch deutlich zu hohe Werte, aber über den Sticky Header schiebt sich eh nichts drüber. Kann dann möglicherweise sogar auf 1 bleiben, wenn wir sonst kein Konfliktpotenzial finden (fixierte Tabellenköpfe sind auf 12, da wollen wir vermutlich nicht drüber). --XanonymusX (Diskussion) 22:49, 27. Apr. 2024 (CEST)Beantworten
Eigentlich sollte 1 passen. Der Sticky Header hat sogar nur 3, aber da bin ich mir nicht ganz im Klaren, wie da position:fixed etc. reinspielen. Eigentlich bräuchte man mal eine Übersichtsseite, auf der gängige Z-Indizes aufgeführt sind. Gruß, -- hgzh08:41, 29. Apr. 2024 (CEST)Beantworten
Hallo Maphry, wenn Infoboxen mit dieser Klasse ausgestattet werden, werden sie in der Mobilversion hinter den Einleitungsabsatz verschoben und bei schmalen Anzeigebreiten auf volle Breite ausgedehnt, um zu verhindern, dass links ein schmaler Streifen bleibt, in den sich dann auf eine Zeile je ein Wort der Einleitung quetscht. Der überwiegende Teil der Infoboxen hatte diese Klasse in den letzten Jahren bereits erhalten, aber einige (jetzt noch ca. 200 bis 250) nicht. Gruß, -- hgzh18:07, 27. Apr. 2024 (CEST)Beantworten
Liste der Kulturdenkmale in Südharz war auch am limit, danach hab ich dort auch den keinupload-parameter gesetzt --> liste wurde ohne uploadfunktion richtig dargestellt.
scheinbar braucht das umspringen doch zu viel speicher, weil jedesmal gecheckt werden muss. also vielleicht doch ein richtiger hybrid-betrieb mit zwei getrennten vorlagen ohne den verweis von liste zu liste? oder hast du noch ne coole idee? Viele Grüße --Thomas08:59, 29. Apr. 2024 (CEST)Beantworten
würde es was bringen, wenn man den upload-parameter nicht pro tabellenzeile sondern im tabellenkopf aufnimmt? damit würde man die upload-funktion aber nciht mehr einzeln pro Tabelenzeile festlegen können. Viele Grüße --Thomas11:04, 29. Apr. 2024 (CEST)Beantworten
Was meinst du mit "das"? Den upload-Link sollte man doch wirklich leicht einmalig in die Tabelle mit aufnehmen können, wenn nicht direkt in den Tabellenkopf, dann unter den Kopf oder ans Tabellenende. Und das sollte doch deutlich ressourcensparender sein, als ihn bei jedem Eintrag einzubauen. Thomas und ich hatten das schon ein paar mal diskutiert: der Upload-Link hat eine nette Funktion, ist aber ganz bestimmt nicht so wesentlich, dass er ein Aufblähen der Liste um 30 oder 50% rechtfertigt, was er aber beim Einbau bei jedem Eintrag macht. (Und selbst das sollte eigentlich lösbar sein. Es ist doch nur ein Link mit ein paar Parametern. Das sollte eigentlich nicht viel mehr kosten als ein Wikidata- oder Commonslink). Grüße, --Global Fish (Diskussion) 09:08, 30. Apr. 2024 (CEST)Beantworten
Mit das meine ich die Aufnahme des Parameters in die Kopfvorlage und dessen Auswertung in der Tabellenzeilenvorlage.
Es geht bei der ganzen Problematik um die Seitengröße, nicht um die Komplexität. Bei x-facher Wiederholung kommt da auch bei einem recht kurzen Link einiges zusammen. Gruß, -- hgzh09:12, 30. Apr. 2024 (CEST)Beantworten
Da hatten wir die Frage verschieden verstanden. Ich so, dass man den Uploadlink nur pro Tabelle einmal setzt, was natürlich deutlich Platz spart. Du so, dass ein im Kopf erzeugter Link zu jedem Eintrag hinkopiert werden würde,worin ich abgesehen von der Frage nach der technischen Machbarkeit auch inhaltlich kaum Sinn drin sehe. Zum Speicherplatz: doch es liegt auch am Link selbst. Grob gesagt, entscheidet das Produkt aus der Zahl der Einbindungen und der individuellen Länge. Andere Links (Koordinaten, Denkmaldatenbank) gibt es auch in jeder Zeile, weitere (Commons, Wikidata) in sehr vielen, ohne dass das so aus dem Ruder laufen würde. Das scheint mir ein spezielles Problem (und ich nenne es Bug) eben dieses Links zu sein. Grüße, --Global Fish (Diskussion) 18:22, 30. Apr. 2024 (CEST)Beantworten
Letzter Kommentar: vor 3 Monaten2 Kommentare1 Person ist an der Diskussion beteiligt
das sehr ernsthafte Problem, das derzeit hier und hier diskutiert wird, scheint mir seine Ursache in einer Änderung der Vorlage:Infobox Eishockeyspieler zu haben, die Du (m.E. leichtfertig) auf diese Anfrage hin vorgenommen hast. Bitte mach diese Änderung wieder rückgängig, solange die urheberrechtlichen und redaktionellen Fragen ungeklärt sind, da sonst ernsthafter Schaden insbes. durch URV angerichtet werden könnte. --Mautpreller (Diskussion) 22:05, 28. Apr. 2024 (CEST)Beantworten
Letzter Kommentar: vor 3 Monaten3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich nehm gefühlt deine Dienste an allen Ecken und Enden in Anspruch.
Ich hab vorhin diese beiden Änderungen in Vorlagen für die Schleswiger-Holsteiner Denkmallisten vorgenommen. [2] und [3].
Änderung 1 macht nen Disclaimer und Änderung 2 gibt ihn erstmal quick and dirty am Ende aus.
Könnte dein Bot bei allen schleswig-Holsteiner Denkmallisten das anmerkungestag in alle Listen setzen <references group="Anm." /> (mit entsprechender überschrift), wenn es noch nicht vorhanden ist. Danach würde ich meine Änderung 2 rücksetzen.
du erhältst diese Nachricht, weil du dich zuvor am UCoC-Prozess beteiligt hast.
Das ist eine Erinnerung daran, dass die Abstimmungsphase für das Koordinationskomitee des universellen Verhaltenskodex (U4C) am 9. Mai 2024 endet. Auf der Wahlseite im Meta-Wiki könnt ihr mehr über die Wahl und die Wahlberechtigung erfahren.
Das Koordinationskomitee des universellen Verhaltenskodex (U4C) ist eine globale Gruppe, die sich für eine gerechte und konsequente Umsetzung des UCoC einsetzt. Communitymitglieder waren eingeladen, sich für das U4C zu bewerben. Mehr Informationen über das U4C und seine Aufgaben sind in der U4C-Satzung zu finden.
Bitte teile diese Nachricht mit Mitgliedern deiner Community, sodass sie sich auch beteiligen können.
Letzter Kommentar: vor 3 Monaten13 Kommentare3 Personen sind an der Diskussion beteiligt
Ich mach mal einen neuen Abschnitt auf. :) Habe jetzt die Zebra-Stile für die Chartvorlagen für den Nachtmodus ausgearbeitet, siehe Beta. Tut auch, was es soll (Sonderfärbungen einzelner Zellen muss ich noch auf Kontrast überprüfen, da brauche ich vermutlich noch ein paar Graustufen). Sind jetzt allerdings 138 Zeilen. Die Definition für reines Zebra könnte zwar theoretisch raus (ursprünglich hatte ich die ergänzt, weil Zebra auf Beta anders definiert war als bei uns), allerdings ist das nur eine Übergangslösung, da ich diesen Teil eigentlich ebenfalls für das Überspringen von Sortbottom ausschreiben müsste. Dann sind wir freilich bei drei überlangen Stildefinitionen nur für Zebra (mal drei für den Nachtmodus). Falls du noch Ideen für eine Vereinfachung hast, lass mich gerne wissen, bevor ich das in deWP aktualisiere. Gruß --XanonymusX (Diskussion) 17:15, 4. Mai 2024 (CEST)Beantworten
Ich würde noch jeweils alle Selektoren kommagetrennt zusammenfassen, die den gleichen Wert für die Hintergrundfarbe zuweisen. Damit sparst du dir die redudante Angabe der Hintergrundfarbe. Ansonsten ist das schon sehr komplex. Gruß, -- hgzh12:12, 5. Mai 2024 (CEST)Beantworten
Hm, ja, allerdings muss ja die Reihenfolge erhalten bleiben, damit die Farben korrekt überschrieben werden. Zebra und Zebragrey sollten sich aber zusammenfassen lassen, ich versuch’s! Bei den Listen der Nummer-eins-Hits bin ich noch unschlüssig, wie ich mit der individuell vorgegebenen Hintergrundfarbe umgehen soll, da muss ich wohl mit !important überschreiben … --XanonymusX (Diskussion) 12:19, 5. Mai 2024 (CEST)Beantworten
Habe experimentiert, wie ich das ganze Konstrukt vereinfachen könnte, und habe jetzt eine zweite leere Tabellenzeile eingefügt. Damit sollte sich das ganze Überspringen von sortbottom erledigt haben. Hast du im Kopf, ob derartige leere Zeilen eventuell Nebenwirkungen haben? Über Wikitext lassen sie sich ja gar nicht erst erzeugen, daher musste ich auf HTML ausweichen. Meine Tests waren bislang sehr positiv. --XanonymusX (Diskussion) 09:00, 8. Mai 2024 (CEST)Beantworten
Das ist natürlich etwas unsauber, aber unerwünschte Auswirkungen in der Ansicht hat das soweit ich weiß nicht. Die klassische erweitere Navigationsleiste hat das bis vor Kurzem auch gemacht. Irgendeinen Tod muss man sterben.
SCNR: Das Konstrukt <tr></tr> ist eine Validitätsverletzung.
Das Verhalten ist von der Browserversion abhängig und nicht vorhersagbar und nicht zukunftsfähig; bis hin zum LINT-Fehler.
Ist nicht nur „unsauber“.
Kaputte Syntax-Hacks wurden hier vor zwei Jahrzehnten mal gebastelt, was in der Folge unschuldigen Nachfolgern Hunderte bis Zehntausende Arbeitsstunden aufbürdete, um die bereits bei der Erstellung als verboten bekannten Konstrukte wieder loszuwerden.
Um schlauen Ideen vorzubeugen:
<tr><td></td></tr> mag valide sein, schlägt aber in Screenreadern auf.
Eine ARIA-Ausblendung von Dummies, damit heutige Browser irgendwie ausgetrickst würden, ist auch die Vererbung Technischer Schuld an die Enkel.
Saubere, durchdachte inhaltliche Strukturen und Konzepte flutschen von selbst und bedürfen keiner Hacks.
aber das lehnt der Sanitizer ab. Parsoid schluckt die leeren Tabellenzeilen übrigens anders als der Legacy-Parser nicht mehr, das kann man schön an unseren Infoboxen beobachten. -- hgzh13:38, 8. Mai 2024 (CEST)Beantworten
Ja, wichtige Anmerkungen. <tr></tr> ergibt Validierungsprobleme und mit leerem td würde der rowspan sowieso nicht funktionieren. Auf konsistentes Verhalten des Parsers ist nicht zu hoffen. Ich habe noch eine alternative Idee, wenn die nicht das gewünschte Ergebnis liefert, werde ich zur bisherigen Lösung für alle Klassen zurückfallen müssen.
Zur optimalen Lösung: Ich bin mir nicht sicher, ob die schon von genügend Browsern unterstützt würde, selbst wenn der Sanitizer sie akzeptieren würde, aber habe das noch nie wirklich getestet. --XanonymusX (Diskussion) 00:52, 9. Mai 2024 (CEST)Beantworten
nth-child mit of sollte in ca. 90% aller Aufrufe funktionieren, Probleme machen da eigentlich nur noch die Exoten unter den Browsern. -- hgzh10:38, 13. Mai 2024 (CEST)Beantworten
Hm, das klingt gut. Dann sollten wir das vielleicht in phab:T217722 anregen (ist wohl leider schon länger eingeschlafen). Ich habe derweil meine Alternativlösung mit line-height:0 getestet; das ist valide und barrierefrei (bleibt für Screenreader einfach eine leere Zeile) und sollte das Stylesheet entlasten, bis die Level-4-Selektoren zulässig sind. --XanonymusX (Diskussion) 18:09, 13. Mai 2024 (CEST)Beantworten
Boah nee, den MagicWords-Parser durchschau ich heute nicht mehr. Ob das an noHashFunctions liegt, kann ich nicht wirklich nachvollziehen. -- hgzh22:13, 16. Mai 2024 (CEST)Beantworten
Letzter Kommentar: vor 3 Monaten4 Kommentare2 Personen sind an der Diskussion beteiligt
Moin Hgzh,
ich bin beim AWW-Abgleich auf den unbegrenzt gesperrten Account CommanderInDubio gestoßen. Und dabei ist mir die Sperrbegründung aufgefallen, die eigentlich auf den ersten Blick nicht verkehrt wirkt, aber beim Link zum Schiedsgericht-Entscheid hat sich ein Linkfehler eingeschlichen. Ich weiß nicht, ob du extern oder intern verlinkt hast, sieht ehr extern aus (aber eigentlich werden interne Wikiadressen verlinkt im Log angezeigt). Jedenfalls habe ich mir mal die fehlerhafte Seite mit der richtigen Verlinkungsadresse angeschaut. Und da fiel mir eine zusätzliche Eintragung auf. Normalerweise wäre VM%2BSP korrekt, bei dem Link von dir wurde aber eine 25 beigefügt, sodass der Eintrag VM%252BSP lautet. Und das hat zu einem ungültigen Seitentitel geführt. Kannst du es dir eventuell anschauen. By the way: Hier hast du die Adresse als Interwiki, der auch im Log verlinkt wird. Schönes Wochenende und Liebe Grüße, FunkrufWP:CVU15:46, 24. Mai 2024 (CEST)Beantworten
Hallo Funkruf, ich kann das Linkproblem nicht nachvollziehen, der Link wird im Logbuch korrekt aufgelöst und angesprungen, sowohl im Firefox als auch per Chromium. Ich weiß nicht, wieso bei dir das Prozentzeichen erneut kodiert wird. Gruß, -- hgzh15:57, 24. Mai 2024 (CEST)Beantworten
Hmm, scheint ein Problem von der Info-Anzeige zu sein, die mir anzeigt, weshalb, von wem und wie lange der Benutzer gesperrt wurde. Da hat sich ein Codierfehler eingeschlichen, im Logbuch ist es doch korrekt, OK, dann entschuldige die Störung. Liebe Grüße, FunkrufWP:CVU16:08, 24. Mai 2024 (CEST)Beantworten
PS: multicol bringe ich demnächst per Responsive-Gadget zurück, vielleicht auch zusätzlich unter einem verständlicheren Namen. -- hgzh07:28, 3. Jun. 2024 (CEST)Beantworten
Letzter Kommentar: vor 2 Monaten4 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo. Du hast vor vier Jahren(!) mit diesem Edit auf Toolserver umgestellt. Das aufgerufene Skript arbeitet - zumindest heute - aber inklusive "Vorlage:" als Parameter. Bei meiner Anfrage an Benutzer PerfektesChaos bekam ich den Hinweis auf die MW-Seite. Kannst du das beheben? Beachte bitte auch die Tipps von PerfektesChaos (wie z. B. ergänzen von https:), zu finden unter Benutzer_Diskussion:PerfektesChaos#NaviLinkCheck. Gruß von ÅñŧóñŜûŝî(Ð)14:45, 31. Mai 2024 (CEST)Beantworten
Hallo Nicola, vielleicht übersehe ich etwas, aber wo wurdest du in der VM angepingt oder zitiert? Ich kann es nicht entdecken. Gruß, -- hgzh16:11, 31. Mai 2024 (CEST)Beantworten
Nun, es soll ja vorkommen, dass jemand neben WP noch andere Verpflichtungen und Interessen hat (letzter Beitrag: [5]) und nicht so schnell antworten kann. Übrigens könnte man den gesamten Abschnitt [6] löschen, wie bereits vorgeschlagen [7]. Die Kritik wurde zur Kenntnis genommen und kann über die Versionsgeschichte gelesen werden. Man ist sich einig, dass man sich nicht einig ist und dreht sich im Kreis. Weitere Beiträge führen womöglich zu mehr Ärger und neuen Verletzungen ...--Gustav (Diskussion) 18:31, 31. Mai 2024 (CEST)Beantworten
Das ist mir natürlich neu, dass jemand noch andere Verpflichtungen hat. Danke für diesen notwendigen Hinweis! .... aber ich hatte versucht, zu erklären, was ich meine und inwiefern ich "beteiligt" bin, danach hat der Benutzer noch agiert ohne mir zu antworten. Und: Andere Beiträge blieben stehen. DAs ist mir unverständlich. --Nicola kölsche Europäerin18:39, 31. Mai 2024 (CEST)Beantworten
Hallo Nicola, erstmal sorry, dass ich hier nicht mehr antworten konnte - ich wollte die VM nicht so „halb-eskaliert“ liegenlassen und habe deshalb nochmal eingegriffen, als ich eigentlich schon los musste. Ich saß dann vier Stunden im Auto und schreibe jetzt nur kurz mobil.
Zur Sache: dass du an der VM beteiligt warst, sehe ich nach wie vor nicht wirklich. Ja, du hast auf der AWW-Diskussionsseite Stellung genommen und wurdest dann dort, mit dem Bezug auf deinen dortigen Kommentar, zitiert und angepingt. Eine Reaktion darauf wäre also meiner Meinung nach auf der Disk richtig aufgehoben, nicht in der VM, wo es ja um den Ausgangskommentar ging, nicht um deine Replik darauf. Der ganze Abschnitt war im Rahmen der VM ja sowieso bekannt, von daher wäre eine Antwort dort auch nicht untergegangen.
Fionas Beitrag habe ich als einmalige Gegenrede zu Juliana dann auch stehen lassen, ihre übrigen Beiträge entfernt. Gruß, -- hgzh20:54, 31. Mai 2024 (CEST)Beantworten
Ich sehe die Situation, wer sich als beteiligt oder unbeteiligt verstehen konnte, ziemlich anders. Merkwürdigerweise sind es häufig immer dieselben Benutzer, die sich offensichtlich überall beteiligt fühlen. Ich wars in diesem Falle und habs auch erklärt - es ist schon frustrierend, wenn so etwas ignoriert wird und die Stellungnahmen anderer offensichtlich mehr Gewicht haben. --21:20, 31. Mai 2024 (CEST) (unvollständig signierter Beitrag vonNicola (Diskussion | Beiträge) )
Ja, das sehen wir dann wohl unterschiedlich. Meiner Meinung nach wäre deine Klarstellung auf der AWW-Disk richtig aufgehoben, da kein direkter Zusammenhang mit der VM bestand, aber das schrieb ich ja schon. Dass die Entfernung aus deinem Standpunkt heraus frustrierend ist, kann ich nachvollziehen. Den Fiona-Beitrag ließ ich wie gesagt als Einordnung zu den Links von Juliana stehen, die ich zuvor auch nicht entfernt hatte, weil sie mir im VM-Zusammenhang als hilfreich erschienen waren). Das ist nicht personenbezogen und wäre er von dir gekommen, hätte ich ihn auch stehenlassen. Gruß, -- hgzh07:35, 3. Jun. 2024 (CEST)Beantworten
Letzter Kommentar: vor 2 Monaten9 Kommentare3 Personen sind an der Diskussion beteiligt
Hat sich da etwas geändert?
Verschiebungen werden jetzt durch einen fetten Kreis ⚫ angezeigt unter dem der vorher immer sichtbare krumme Pfeil ↪ oder ↩ verborgen ist, der erst erscheint, wenn man die Maus darauf setzt. Hat das irgendetwas mit dem Darkmode zu tun oder steckt da eine Absicht dahinter, die sich mir nicht erschließt?
Ist schon bekannt: phab:T366845. Der Kreis war schon immer da (vermutlich, damit man den Link besser trifft), hat aber wohl versehentlich seine Transparenz verloren. Gruß, -- hgzh14:43, 7. Jun. 2024 (CEST)Beantworten
Moin Moin Hgzh, ich klinke mich mal hier ein. Heute wurde ja die Farbe vom Versionsvergleich geändert, kannst du mir vllt. sagen, wie man die alten Farben wieder bekommt? mfg --Crazy188018:50, 20. Jun. 2024 (CEST)Beantworten
Letzter Kommentar: vor 2 Monaten3 Kommentare2 Personen sind an der Diskussion beteiligt
Die Änderungen dort habe ich erst einmal wieder zurückgesetzt, da das haufenweise Linterfehler (mehr als 800) erzeugt hatte. Falls du da eine Lösung hast, die ohne solche Fehler auskommen würde, dann wäre das sicher hilfreich. Ich würde nämlich ungern Ärger mit WMF bekommen --Liebe Grüße, LómelindeDiskussion10:41, 13. Jun. 2024 (CEST)Beantworten
Letzter Kommentar: vor 2 Monaten2 Kommentare2 Personen sind an der Diskussion beteiligt
Hi, soll Vorlage:Klappleiste am Ende auch für die Navis in Einsatz kommen? Seit die Klappfunktion auf Mobilgeräten verfügbar ist, habe ich auch schon darüber nachgedacht, ob wir NavFrame nicht nachziehen sollten; fände einklappbare Navis auch auf Mobilgeräten sinnvoll (gerade bei den responsiven, da sie ja gleich sehr in die Länge gehen). Hatte bei der Adaption der Navbox aber unsere NavFrame-Technik übernommen, da sonst verschiedene Navis nicht mehr zusammengepasst hätten. Gruß --XanonymusX (Diskussion) 20:24, 19. Jun. 2024 (CEST)Beantworten
Hi, ja, auf lange Sicht soll die Klappleiste auf Basis von mw-collapsible unser eigenes NavFrame-System ablösen. Irgendwann sind dabei auch die Navileisten dran, aber erst ganz zum Schluss, wenn alle Inline-Verwendungen von NavFrame ersetzt sind. Dann müssen wir höchstens noch unser Auto-Ausklapp-System bei X Navileisten lokal vorhalten, wobei ich mir nicht sicher bin, ob das überhaupt noch jemand wirklich nutzt.
Dass ich NavFrame nicht mehr effektiv auf nicht-mobil einschränken konnte, hat mich die Überarbeitung erstmal zurückstellen lassen, aber da es jetzt keine Rolle mehr spielt, denke ich auch, dass eine Aktivierung mobil sinnvoll wäre. Auf Beta liegt schon ein überarbeitetes NavFrame.js-Gadget, da fehlt nur noch etwas Feinschliff. Gruß, -- hgzh23:47, 19. Jun. 2024 (CEST)Beantworten
Letzter Kommentar: vor 2 Monaten11 Kommentare3 Personen sind an der Diskussion beteiligt
Bisher dachte ich immer, dass es nicht möglich ist einer kompletten Spalte eine Textausrichtung vorzugeben. Da ich gerade über etwas gestolpert hier meine Frage es:wp Beispiel :es:Premio Nacional de Arquitectura de Chile die Zuweisung
Du hast den Link zum ursächlichen Stylesheet ja selbst schon eingefügt; man muss die Ausrichtung dort eben für alle Spalten einzeln definieren, bei der 21. Spalte würde es dann nicht mehr gehen. Gruß, -- hgzh08:09, 24. Jun. 2024 (CEST)Beantworten
Ich dachte immer es sei „technisch“ nicht möglich. Den Code dort td:nth-of-type(1–20) verstehe ich sowieso nicht. Mir geht es auch mehr darum, zu verhindern, dass wirkungslose Syntax nach hier kopiert und durch Kopieren dann weiter verschleppt wird. Es gibt schon →plainrowheader aus der en:wp, die immer wieder hier eingeschleppt werden und selbst dort scheinbar inzwischen wirkungslos sind. en:Padmini_Kolhapure#Awards and nominations ich weiß aber, dass das bei denen zumindest mal funktioniert hatte und die Kopfzeilen nicht fett waren. --Liebe Grüße, LómelindeDiskussion09:28, 24. Jun. 2024 (CEST)Beantworten
td:nth-of-type(3) bspw. selektiert die dritte Zelle (td) innerhalb einer jeden Zeile (tr), daher kann man damit die gleiche Zelle in jeder Zeile selektieren. plainrowheaders ist dafür gedacht, auf Zeilenüberschriften angewendet zu werden, nicht auf Spaltenüberschriften, deshalb muss man den entsprechenden Zellen ein scope="row" übergeben, damit etwas passiert. In deinem Beispielartikel fehlt ohnhein ein s am Ende und es gibt auch keine Zeilenüberschriften. -- hgzh09:35, 24. Jun. 2024 (CEST)Beantworten
Da waren doch neulich einige Leutchen auf der Kurier-Disk oder so, die meinten, das sei ganz einfach und kaum Aufwand, alle unsere Artikel und Seiten für den Night-Mode umzuschreiben, zu dem die deWP-Community sich noch niemals geäußert hatte, ob sie den überhaupt haben möchte.
Bitte mal den Dark-Mode-Fanclub zusammentrommeln und die Umstellungsarbeit unter den Leuten verteilen, die das haben möchten und finden dass das ganz einfach sei.
Die LINT-Community darf mit dem Kokolores jedenfalls nicht belastet werden; die kümmern sich um richtige Fehler in der Wikisyntax.
Ló trifft wohl der Schlag, wenn diese Seuche aufschlägt und die Statistik abschießt.
Ich hatte hier schon vorgewarnt: Hilfe Diskussion:Wikisyntax/Validierung#Nur als Info; war bisher schon als hidden rule aktiv und wurde nun freigeschaltet, wieso auch immer, denn: die allermeisten dort aufgeführten Fehler sind gar keine, weil sie zentral per CSS adressiert werden. Jetzt hektisch irgendwelche Textfarben festzulegen, bringt überhaupt nichts. Besser einfach ignorieren. -- hgzh15:30, 4. Jul. 2024 (CEST)Beantworten
Na, dann kommunizier deine Erkenntnisse mal auffindbar der Welt, und füge die entsprechenden Anweisungen zum Vorgehen in die Hilfeseite ein; es wird auch in den Seiten-Infos wiedergegeben und überall aufgelistet.
„die allermeisten dort aufgeführten Fehler sind gar keine“ ist genau das was wir als LINTER-Fehlerlisten ganz dringend brauchen.
Da das auch der Titel der Spezialseite ist, passt ein Punkt nicht. Habe die Einbindung daher aus der Hilfeseite entfernt. -- hgzh10:09, 5. Jul. 2024 (CEST)Beantworten
Ich sehe gerade den Fehler, da ⧼Linter-pager-night-mode-unaware-background-color-desc⧽ offensichtlich nicht definiert ist und/oder fehlt. Zudem besteht auf Spezial:LintErrors/night-mode-unaware-background-color der Fehler, dass in der Beschreibung der Punkt fehlt: Diese Seiten haben Inline-Stilregeln für die Hintergrundfarbe, aber keine entsprechende Textfarbe; dadurch wird der Dunkelmodus unwirksam
Letzter Kommentar: vor 1 Monat3 Kommentare2 Personen sind an der Diskussion beteiligt
Moin,
du hattest hier einen fix für die VM-Seite erstellt. Ich weiß leider nicht, wie genau du das gefixt hast bzw ich hab keinen entsprechenden Diff gefunden. Jetzt sind in dem Thread noch die Redaktion Chemie und die LP genannt worden. Mir war das ganze auf der LP aufgefallen, was ich auf der entsprechenden Disk angesprochen hatte. Könntest du mir verraten, wie man das fixt oder könntest du das noch in Ordnung bringen, wenn man dafür entsprechende Rechte braucht? Vielen Dank & viele Grüße, 11:45, 8. Jul. 2024 (CEST) --Kyrunix (Diskussion) 11:45, 8. Jul. 2024 (CEST)Beantworten
Letzter Kommentar: vor 14 Tagen44 Kommentare3 Personen sind an der Diskussion beteiligt
Moin! Bin gerade über ein "klasse=skin-invert" bei einer Signatur gestolpert, um genau zu sein war das in Ingrida Šimonytė. So wie ich das kapiert hab, ist das für den Darkmode. In der Android-App bewirkt das wohl nix, wie kann ich die Auswirkungen bestaunen? Und dann noch: Es gibt so einige hundert solcher Unterschriften und da frag ich mich, ob da nicht ein Bot gucken kann, ob diese Unterschrift ein Bild in schwarz/weiß (bzw. fast-schwarz/fast-weiß) ist und dann diese Klasse hinzufügen. Diese Extension "imagick" ist in der Toolserver-Cloud in PHP enthalten, sollte also grundsätzlich möglich sein, ob ich schlau genug bin um das auch richtig zu verwenden stellt sich dann heraus ;^) --Wurgl (Diskussion) 09:16, 10. Jul. 2024 (CEST)Beantworten
Die Android-App hat ihren eigenen, etwas dümmlichen Darkmode, der hoffentlich irgendwann eingestampft wird. Der Website-Darkmode funktioniert nur in der Mobilversion bzw. im Vector-2022-Skin, also bestaunbar hier.
Zur botgestützten Bearbeitung kann ich nicht viel sagen, sinnvoll wäre es sicher, ggf. mit vorgeschalteter Arbeitsliste, in der man falsch-positive Einträge eliminieren kann. Gruß, -- hgzh09:35, 10. Jul. 2024 (CEST)Beantworten
Ich hab mal ein paar Zeilen Code geschrieben, dauert halt etwas, aber ich frage mich, ob denn dieses skin-invert nicht eine Eigenschaft der Datei selbst ist. Klar kann man das in der Einbindung angeben, aber dann muss man das in jedem Wiki extra angeben. Wenn das eine Eigenschaft der Datei selbst ist, dann würde das vor allem den kleinen Wikis helfen. --Wurgl (Diskussion) 18:57, 22. Jul. 2024 (CEST)Beantworten
Prinzipiell ja, andererseits wird es sicherlich auch Anwendungsfälle geben, in denen die Invertierung nicht erwünscht wäre. Ist nicht ganz so zufriedenstellend zu lösen, finde ich. Gruß, -- hgzh07:44, 23. Jul. 2024 (CEST)Beantworten
Naja … es gibt wahrscheinlich Grenzfälle wo beide Fälle gruselig aussehen. Wie auch immer, wenn ich nur(!) Dateien mit "Signatur" bzw. "Unterschrift" im Dateinamen ansehe, dann komm ich auf über 3000 Stück in deWP. Bei den Logos bin ich mir nicht so ganz sicher, da könnte eine Invertierung der Farbe mit dem Markenrecht kollidieren. --Wurgl (Diskussion) 08:00, 23. Jul. 2024 (CEST)Beantworten
Ja, die Logos würde ich erstmal in Ruhe lassen, das gibt wahrscheinlich zu viele Probleme. Aber a propos: kannst du vielleicht bei den Unterschriften auf MediaWiki:Pageimages-denylist gleich noch notpageimage hinzufügen? Dann können die mal aus der Liste fliegen. -- hgzh08:49, 23. Jul. 2024 (CEST)Beantworten
Diese Imagick-Extension ist ein Käse. Es gibt zwar die tolle Funktion getImageHistogram, aber die hat ein Memory-Leak. Eine Datei kann man angucken, wenn man dem Script 6 GByte erlaubt, gehen sogar 10, aber danach ist out-of-memory. Echt toll! Zu Fuß die einzelnen Pixel durchgehen ginge zwar auch, ist aber sehr langsam. Egal, ich starte für jedes Bild einen Subprozess … argh! Einmal mit Profis arbeiten!
Jedenfalls sind bei uns insgesamt 5370 Dateien mit "berschrift" bzw. "ignatur" eingebunden (ersten Buchstaben wegen groß/klein weggelassen). 17 Bilderchen mag die Extension nicht lesen, 2741 haben transparenten Hintergrund, 660 haben weißen Hintergrund. Wobei ich nur die oberen 6 Bit der Farbe betrachte. Von den nicht lesbaren ist eine *.ogg, also Audiodatei und damit verziehen, 2 *.jpg die aber dem Namen nach ein Foto sind. Es bleiben 14 svg-Dateien in denen wohl irgendeine Information fehlt. Aber erstmal sind mir die egal.
Bei den Bildern mit transparentem Hintergrund kann ich davon ausgehen, dass der Vordergrund dunkel ist weil sonst würde man ja bisher nichts sehen. Bei denen mit weißem Hintergrund sind 80% der Pixel des Bildes weiß zumindest ist das meine Definition von "Hintergrund", also diesen 3401 Bilderchen kann ich ganz sicher ein klasse=skin-invert-image verpassen. --Wurgl (Diskussion) 15:28, 26. Jul. 2024 (CEST)Beantworten
Bilder mit weißem Hintergrund braucht man denke ich nicht zwingend auszustatten, da sieht man ja immer etwas. Aber bei transparenten Bildern klingt das schon mal ganz gut, bin gespannt! -- hgzh16:32, 26. Jul. 2024 (CEST)Beantworten
Bissl Verwaltungskram noch, dann lass ich mal 10 Stück laufen.
Ja, Gallery und die Mehrere-Bilder-Vorlage können noch keine Klassen aufnehmen. Die Vorlage kann ich umbauen, für Gallery gibt's was im Phabricator. -- hgzh09:44, 27. Jul. 2024 (CEST)Beantworten
2897 Artikel wurden geändert. 271 Artikel scheinen sowas wie Mehrere Bilder, Gallery und eventuell auch eine Signatur in der Infobox per Parameter zu haben. --Wurgl (Diskussion) 08:39, 31. Jul. 2024 (CEST)Beantworten
Schande über mich. Bei den 271 Artikeln war ich wohl noch im Zustand mit zu wenig Kaffee, waren nur 29 Stück (Hab das denylist-Dings laufen lassen und da merkt sich nicht was weg ist … seufz und dann gabs noch ein anderen Fehlerchen beim Zählen) Von den 29 sind jetzt 11 weg.
Aurobindo Ghose Sowas hab ich bisher noch nicht gesehen: Eingebunden ist Sri-Aurobindo-Signature-Transparent.jpg.png … ist wohl eine Weiterleitung auf Commons, aber das sieht man nicht wenn man drauklickt. Jedenfalls okay. Weiterleitung auch bei Theodor Herzl und Charles Wilkes, auch okay. Danilo Astori war auch so ein Fall, hab ich gefixt.
Shirley (Film) netter Editfehler ist hier passiert, aber nach dem Bot.
Die Infoboxen habe ich gefixt. Bei Demi Lovato ist das Bild mit der Signatur erst kürzlich rausgeflogen, evtl. alte Datenbasis? -- hgzh16:26, 31. Jul. 2024 (CEST)Beantworten
Hmm … offenbar etwas alte Datenbasis, bzw. ich werfe aus meinen Daten gelöschte wohl nicht raus. Egal, das Ding ist gegessen und wenn irgendwann gallery geht, dann werde ich es wiederbeleben … oder nicht. --Wurgl (Diskussion) 16:42, 31. Jul. 2024 (CEST)Beantworten
Etwas offtopic, aber von den Problemfällen inspiriert: "Datei-Weiterleitung auf Commons aufgelöst" als Änderungstext. Das mit Weiterleitungen von Bildern auf Commons ist etwas verwirrend, da muss man genau gucken. Wenn du Datei:Logo of Kataeb Party.svg anklickst, dan steht in der URL-Zeile deines Browsers "Datei:Logo_of_Kataeb_Party.svg", als Überschrift auf der Seite ist aber "Datei:Kataeb Party logo.svg" zu finden und nirgendwo steht sowas wie "Weitergeleitet von Datei:Logo of Kataeb Party.svg" --Wurgl (Diskussion) 08:10, 2. Aug. 2024 (CEST)Beantworten
Es gibt auch Vorlage:SportPicto, die das Invertieren bereits kann. Dort finden sich evtl. noch weitere Piktogramme. Wenn die Piktogramme klein und inline eingebunden werden, könnte man mglw. auch die Vorlage verwenden, aber sobald Rahmen etc. dazukommen, müsste die Klasse direkt in der Bildeinbindung ergänzt werden. -- hgzh11:04, 6. Aug. 2024 (CEST)Beantworten
SportPicto wird übersprungen, das Datei:-Gedaddel ist in einer Untervorlage und daher erkenne ich das gar nicht. Aber ich hab ein paar Zeilen Code getippt und gucke ob background oder bgcolor zu finden ist, wenn ja dann mach ich nix. Damit gehen dann auch Vorlagen und so fiese Dinger wie Olympische_Sportarten --Wurgl (Diskussion) 11:17, 6. Aug. 2024 (CEST)Beantworten
Hmm … Timo Boll die Infobox hat im Darkmode schwarz auf schwarz in der Kopfzeile, im hellen Modus aber blauen Hintergrund. Hmm … fass ich jedenfalls nicht an, weil Hintergrund gesetzt ist. --Wurgl (Diskussion) 11:24, 6. Aug. 2024 (CEST)Beantworten
Ja, Infoboxen sind Sonderfälle, die kannst du auch erstmal ganz weglassen. Mein Hinweis auf SportPicto war so gemeint, dass du evtl. auch die Bildeinbindung in einigen Fällen durch die Einbindung dieser Vorlage ersetzen könntest, wenn das mit vertretbarem Aufwand machbar ist. -- hgzh11:30, 6. Aug. 2024 (CEST)Beantworten
Das ist teuflisch! Jetzt fisch ich mir Pictogramme aus 3 Kategorien, eines noch extra und außerdem ersetze ich auch noch png durch korrespondierende svg (via c:template:SupersededSVG) und es werden immer mehr, bin jetzt schon bei über 10.000 Artikeln. --Wurgl (Diskussion) 16:35, 6. Aug. 2024 (CEST)Beantworten
Ich stoppe das erstmal, siehe Fix-Diff Ich muss da einen ordentlichen Tabellenparser basteln, bei 100 Dateien wäre mir das egal (da wäre ein Artikel falsch), aber bei etwas über 10.000 muss das schon klappen. Bilderchen hab ich jetzt wohl alle gefunden, sind auf Commons über 1000 und in deWP ca. 350 verschiedene. Am Wochenende geht es weiter. --Wurgl (Diskussion) 22:15, 6. Aug. 2024 (CEST)Beantworten
Bei der Basketball-Qualifikation dreht sich der Hintergrund nicht mit um, ist ein bisschen komplizierter dort, mglw. lässt sich das durch eine Vorlage ersetzen.
Die haben wieder was gebastelt. Wenn das Bild inline (oder rahmenlos) ist, dann ist es schwarz auf schwarz, ist es aber rechts, links oder mini, dann wird der Hintergrund weiß. Hmm … soll ich das berücksichtigen und links/rechts/mini auslassen?
zu spät :-( 4000 Artikel sind schon durch und das sind die mit den größten Anzahl an Vorkommen. Dieses links/rechts/mini ist aber nicht besonders häufig. --Wurgl (Diskussion) 15:58, 11. Aug. 2024 (CEST)Beantworten
Die Infobox-Überschreibungen des Darmode wirken bislang nur auf Zellebene oder die gesamte Infobox. Möglicherweise lässt sich das auch unfallfrei auf die Zeilenebene ausdehnen, aber sicher bin ich mir nicht. Ein bisschen überarbeiten will ich es sowieso noch. Ich schau es mir mal an. -- hgzh09:51, 13. Aug. 2024 (CEST)Beantworten
Übrigens zur Info: testweise habe ich drei weitere Klassen für den Darkmode eingeführt (siehe hier): darkmode-hintergrundfarbe-basis (= hintergrundfarbe-basis), darkmode-hintergrundfarbe-passiv (= hintergrundfarbe1), darkmode-hintergrundfarbe-neutral (= hintergrundfarbe5), die jeweils nur im Darkmode wirksam werden und im hellen Modus alles so lassen, wie es ist. Die komplexe Benamsung wegen der Diskussion in Wikipedia:Technik/Skin/MediaWiki/Änderungen/Archiv/2024#hintergrundfarbe0. Gruß, -- hgzh09:56, 13. Aug. 2024 (CEST)Beantworten
Das ist zwar nett gemeint bringt aber die Fehler zurück, die es in meiner Version nicht gab, ich hatte es bewusst auf h-1 gesetzt damit color ignoriert wird. Ich weiß die Linterfehler interessieren dich da nicht, ich mag aber keine halben Sachen, daher hatte ich auch die Ringe ausgetauscht, weil schwarz nicht gut zu sehen war. Immerhin habe ich inzwischen diese Variablen so einigermaßen verstanden. --Liebe Grüße, LómelindeDiskussion10:57, 13. Aug. 2024 (CEST)Beantworten
Es geht vor allem darum, die Farbe im hellen Modus nicht zu beeinflussen. Das gibt über kurz oder lang Ärger, wenn versucht wird, alle individuellen Farben in den Graukanon zu bringen. Die Textfarbe wird außerdem explizit gesetzt, ein weiterer Fehler dieser Lintabfrage - es besteht überhaupt kein Problem, außer dass der Fehler existiert. -- hgzh11:23, 13. Aug. 2024 (CEST)Beantworten
Derzeit ist rahmenfarbe5 immer als schwarz definiert, aber du hast recht, Wechsel auf weiß würde Sinn ergeben. Ich muss mal schauen, wie diese Rahmenfarbe verwendet wird und ob es Probleme geben könnte, dann kann ich das anpassen. Gruß, -- hgzh16:54, 11. Jul. 2024 (CEST)Beantworten
Na, da würde ich mal abwarten, ob die Dialog irgendwann auch über ein dunkles Farbschema verfügen (bin mir nicht sicher, ob dies bereits so ist) - wenn ja, dann sollte sich das denke ich auch auf der Hilfeseite widerspiegeln. Gruß, -- hgzh22:34, 15. Jul. 2024 (CEST)Beantworten
Das ist alles Eigenbau, ich bin keine Programmiererin und kann nicht auf die Dialogformate oder Bausteine wie Importareas und Click- oder Switchbottons der WMF zurückgreifen. Ich weiß gar nicht wie man das machen müsste. Daher ja meine Frage, ob ich das dann alles umbauen muss. --Liebe Grüße, LómelindeDiskussion06:36, 16. Jul. 2024 (CEST)Beantworten
Letzter Kommentar: vor 1 Monat6 Kommentare3 Personen sind an der Diskussion beteiligt
In der Doku lese ich dreimal „Autowert“.
Das ist das Verhalten bei der Neu-Einfügung einer Einbindung, und wäre nur für das eingefrorene Abrufdatum brauchbar, was aber auch nicht funktioniert, weil wir keinen Bot haben, der täglich frühmorgens alle entsprechenden Vorlagenseiten purgen würde.
Unabhängig davon und viel interessanter ist das Verhalten bei nicht angegebenem Wert; das wäre default.
Ausweislich der Modul-Zeilen 207–209 ist jedoch das zweite gemeint.
Das Modul berücksichtigt die Situation der leeren Angabe offenbar nicht korrekt.
Wenn hierbei ein benannter Parameter den Wert "" hat oder not ist, dann soll der Default wirken.
Es gibt sechs ASCII-Hexen. Was soll daran zu escapen sein?
Autoren-Standard sind Großbuchstaben. Auch älter. Kleinbuchstaben brachten später die tippfaulen Handhacker, dazu die Kürzung auf drei oder eine Hex. War mal Privatmarotte von zwei SVG-Schaffern gewesen.
In der anderen Angelegenheit ist nicht nur Sachsen durch, sondern die Monuments sind auch bald manuell re-manualisiert worden.
Das hätt’s nicht gebraucht, mit diesem Lemma-Beginn hätte ich noch längere Zeit leben können.
Melde mich in Kürze per Mail, mit aktuell angepasstem Plan.
Ist mir gar nicht recht, weil wird viel zu heiß und ich will eigentlich erst im Oktober wieder was mit Nachdenken haben.
Autowert und Default verwechsel ich ständig. Manchmal nehm ich das richtige, manchmal nicht. Vielleicht lern ich es ja irgendwann...
nowiki ist ein Überbleibsel davon, als ich das Doppelkreuz noch mit ausgeben wollte. Das fliegt noch raus, wenn ich das Modul wieder anfasse. Dann kann ich auch den Mode nochmal nachschärfen.
Deine Angaben in der LD haben mich überzeugt. Ich habe den LA zurückgezogen. Ich sehe aber keinen Sinn darin, Farbwerte wie #101418 oder #202122 zu nehmen. Die sind von Schwarz nicht zu unterscheiden:
Die Farben habe ich mir nicht ausgedacht, das sind die softwareseitigen Hintergrundfarben für den Dunkelmodus. Und die kann man schon unterscheiden, insb. wenn es sich um größere Flächen handelt. Drucken spielt keine Rolle, da wohl niemand auf die Idee kommt, eine Seite im Dunkelmodus auszudrucken. -- hgzh23:43, 15. Jul. 2024 (CEST)Beantworten
Ok. Frage: Wie kann ich bei meiner CSS-Konfiguration und meinem JS die Farben modusabhängig(!) selbst festlegen? mit .hintergrundfarbeN {background-color: #RRGGBB;} lege ich die Farbe ja starr fest. ÅñŧóñŜûŝî(Ð)19:15, 17. Jul. 2024 (CEST)Beantworten
/* heller Modus */:root{--dewiki-hintergrundfarbe1:#ffffff;}/* dunkler Modus */@mediascreen{html.skin-theme-clientpref-night{--dewiki-hintergrundfarbe1:#000000;}}@mediascreenand(prefers-color-scheme:dark){html.skin-theme-clientpref-os{--dewiki-hintergrundfarbe1:#000000;}}
Letzter Kommentar: vor 1 Monat2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Hgzh,
gegen die im Betreff genannte, von dir angelegte oder erheblich bearbeitete Vorlage wurde ein Löschantrag gestellt (nicht von mir). Bitte entnimm den Grund dafür der Löschdiskussion. Ob die Vorlage tatsächlich gelöscht wird, wird sich gemäß unserer Löschregeln im Laufe der siebentägigen Löschdiskussion entscheiden.
Du bist herzlich eingeladen, dich an der Löschdiskussion zu beteiligen. Wenn du möchtest, dass die Vorlage behalten wird, kannst du dort die Argumente, die für eine Löschung sprechen, entkräften. Du kannst auch während der Löschdiskussion Verbesserungen an der Vorlage vornehmen.
Da bei Wikipedia jeder Löschanträge stellen darf, sind manche Löschanträge auch offensichtlich unbegründet; solche Anträge kannst du ignorieren.
Vielleicht fühlst du dich durch den Löschantrag vor den Kopf gestoßen, weil durch den Antrag die Arbeit, die Du in den Artikel gesteckt hast, nicht gewürdigt wird. Sei tapfer und bleibe dennoch freundlich. Der andere meint es vermutlich auch gut.
Ich bin übrigens nur ein Bot. Wenn ich nicht richtig funktioniere, sag bitte DerIch27 bescheid. Wenn du nicht mehr von mir benachrichtigt werden möchtest, kannst du dich auf dieser oder dieser Liste eintragen.
Letzter Kommentar: vor 1 Monat3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo hgzh! Du weißt bestimmt, wo wir die Formatierung der vier Tilden als Signatur in dewiki festgelegt haben, oder? Andere Wikis stellen z.B. keine zwei Striche voran, wir aber schon, deshalb denke ich, ist das was lokal Formatiertes. Weißt Du wo? Liebe Grüße, – Doc Taxon • Disk. • 17:21, 26. Jul. 2024 (CEST)Beantworten
Hallo, du nutzt den Vector-2022-Skin? Dann liegt das an den fixierten Tabellenköpfen, die leider mit dem kürzlich hinzugefügten automatischen Scroll-Overflow bei zu breiten Tabellen nicht klarkommt. Leider herrscht noch etwas Ratlosigkeit, wie man das verträglich hinbekommen könnte. Stand jetzt wird es wohl darauf hinauslaufen, dass die fixierten Tabellenköpfe abgeschaltet werden müssen. -- hgzh09:50, 27. Jul. 2024 (CEST)Beantworten
Geht eine Beschränkung der fixed auf alle außer Vector-2022 innerhalb von TemplateStyles ?
Letztlich müsste das Grundproblem bei WMF in der Skin gelöst werden.
Ja, darauf hatte ich gehofft. Leider weiß da auch niemand eine Lösung. In der Konsequenz muss ich das dann irgendwann so umsetzen, funktionieren sollte es. -- hgzh12:49, 27. Jul. 2024 (CEST)Beantworten
Das ist nicht nötig, Skin-Einschränkung geht ja per TemplateStyles und mehr kann man mit CSS ohnehin nicht machen - vielleicht irgendwann, wenn Style-Container-Querys gehen, aber das wird wohl noch dauern, das kann momentan noch kein Browser. -- hgzh13:55, 27. Jul. 2024 (CEST)Beantworten
Letzter Kommentar: vor 26 Tagen11 Kommentare4 Personen sind an der Diskussion beteiligt
Da stimmt irgendetwas nicht, wenn ich auf Verschieben klicke, dann steht unten im letzten Eintrag zu „Allgemeine Verschiebegründe“ nicht der Link Verschiebewunsch, sondern ein nowiki-Link [[Wikipedia:Verschiebewünsche|Verschiebewunsch]], gleiches gilt für andere Links dort, wie „nach Diskussion im [[Wikipedia:WikiProjekt Kategorien|WikiProjekt Kategorien]]“ --Liebe Grüße, LómelindeDiskussion11:54, 30. Jul. 2024 (CEST)Beantworten
Das ist aber schon immer so, das Dropwdown ist nichts weiter als ein Schnellzugriff auf den normalerweise in das Textfeld einzugebenden Wikitext. Ein Link würde da auch nicht gut funktionieren, denn bei Klick soll ja das Dropdown-Element ausgewählt und nicht dem Link gefolgt werden. -- hgzh12:13, 30. Jul. 2024 (CEST)Beantworten
Ich verschiebe zu selten, als dass mir das aufgefallen wäre, ich schreibe immer selbst eine Begründung, und habe da noch nie reingeschaut. Mich verwirrt so etwas aber eher und ich würde das dann nicht auswählen. Ich werde das auch nicht so kryptisch in die Seite einfügen. --Liebe Grüße, LómelindeDiskussion12:52, 30. Jul. 2024 (CEST)Beantworten
Ich finde das nicht gut, dass wir in diesem Menü "Anderer Grund" ganz oben stehen haben. Erstmal sollten wir die vorgeschlagenen Gründe anzeigen, und "Anderer Grund" dann ganz unten in den Dropdown. Besser wäre es, wenn der Dropdown von Anfang an ausgeklappt angezeigt wird. Wenn der Dropdown gleich ausgeklappt angezeigt wird, haben wir eine Barriere weniger bedient, die Auswahl-Gründe treffen häufiger zu als "Anderer Grund", und "Anderer Grund" ist dann ganz unten die letzte Wahl. – Doc Taxon • Disk. • 08:41, 31. Jul. 2024 (CEST)Beantworten
@ „Besser wäre es, wenn der Dropdown von Anfang an ausgeklappt angezeigt wird.“ Das würde aber andere Probleme hervorrufen, nämlich, dass man die zweite Eingabebox dann nicht mehr erreichen kann, weil die Auswahlliste, im ausgeklappten Zustand sie überdeckt, je nach Namensraum auch alle Auswahlboxen und die Schaltfläche zum Schieben. Man müsste sie also erst schließen, wenn man, wie ich, manuell etwas einfügen möchte, ebenso, wenn man den vorgegebenen Vorschlag ergänzen möchte, ohne einen anderen Vorschlag auszuwählen. Weiter wäre es recht schwierig zu definieren welche Auswahlbox den Vorrang bekommen soll. Diese haben ja, je nach Ursprungsnamensraum, unterschiedliche Einbindungen (Allgemeine Verschiebegründe, Diskussionsseiten, Benutzernamensraum). Also hier wäre es beispielsweise so:
Archiv nach Verschiebung der zugehörigen Diskussionsseite nachgezogen
Was mir da noch aufgefallen ist, warum macht „Allgemeine Verschiebegründe“ nach unten einen so großen Abstand? Das sieht jetzt in der →Hilfeseite irgendwie doof aus, zudem bräuchte ich noch eine kleine Hilfestellung. Wie kriege ich dort die Aufzählungszeichen weg? Diese werden ja nicht im Formular angezeigt. --Liebe Grüße, LómelindeDiskussion09:44, 31. Jul. 2024 (CEST)Beantworten
Eine Kommentarzeile (=nix), Zeilenumbruch, Leerzeile=Zeilenumbruch, nicht-leere Wikisyntax, außerhalb Diskussionsseiten zu nix zusammenfallend, aber nicht das Ende der Nachricht: resultiert in nicht-getrimmter doppelter Leerzeile = neuer Absatz.
Es ist zwar jetzt besser aber im Grunde ist da noch immer ein zu großer Abstand, denn im Hilfenamensraum wird der Abschnitt Diskussionsseiten nicht angezeigt folglich schließt der Rahmen nicht unter dem letzten Eintrag ab, sondern erst einige Leerzeilen später oder laut Inspektor
Ach ganz unten, ich hatte direkt nach Allgemeine Verschiebegründe geschaut. Theoretisch sollten sind die Zeilenumbrüche noch in den switch legen lassen. -- hgzh16:29, 31. Jul. 2024 (CEST)Beantworten
Da wo background:transparent unnötig war habe ich es entfernt, ansonsten ist meine Position zu diesem „Fehler“ bekannt. Ich investiere da keine Zeit rein. Gruß, -- hgzh18:15, 5. Aug. 2024 (CEST)Beantworten
Letzter Kommentar: vor 16 Tagen3 Kommentare2 Personen sind an der Diskussion beteiligt
Aus irgendeinem Grunde sieht das jetzt auf der einbindenden Seite Metropolitana di Roma#Linie C nicht wirklich toll aus. Da sind erstens noch weitere dieser Vorlagen (Linie A und B) und es wirkt merkwürdig, wenn eine Linie quasi aufdringlich aufgeklappt ist und die anderen sind geschlossen. Was aber der eigentliche Grund ist, durch den Wechsel von NavFrame zu mw-collapsible wird die Schaltfläche vergrößert und das C rutscht in die nächste Zeile, das sieht doof aus und ich weiß auch nicht warum das anders als auf der Vorlagenseite selbst aussieht. Im Grunde sollte man die drei Vorlagen ABC komplett überarbeiten und die zigfache Dateieinbindung eliminieren. Möglich wäre Vorlage:Farbe_ oder den Streckenverlauf auf eine ähnliche Art wie Vorlage:Routemap oder Bahnlinien? --Liebe Grüße, LómelindeDiskussion11:45, 10. Aug. 2024 (CEST)Beantworten
Ich habe grob drübergeschaut, danke erstmal. Ich würde es aber im Sinne eines Reviews auf WP:MW/Ä einstellen, auf persönliche Disk-Anfrage werde ich eher ungern in Angelegenheiten tätig, die das gesamte Projekt betreffen. Gruß, -- hgzh08:09, 13. Aug. 2024 (CEST)Beantworten
Es ist weiterhin Gemisch aus altem DOM und neuerem jQuery, so wie das cut&paste aus der ollen Common erstmal lieferte.
Der Bereich (Überschriften-Element-Struktur, DiscussionTools) lässt in näherer Zukunft immer wieder erforderliche ANpassungen erwarten. Dazu bei DOM zu bleiben und das mit jQuery zu quirlen ist unangebracht.
Ich habe das deshalb auf unseren konventionellen Stand von 2014 gebracht: