Entlinkt

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 90 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

Archiv

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2020 2021 2024

Wie wird ein Archiv angelegt?

Obsolete CSS-Klassen

Hallo. Kannst du die Listen auf Benutzer:Entlinkt/CSS-Klassen nochmal neu auslesen (lassen)? Es ist durchaus möglich, dass beim Abarbeiten Seiten durch die Lappen gegangen und doch noch übrig sind. Gruß von ÅñŧóñŜûŝî (Ð) 21:36, 12. Jun. 2014 (CEST)

Die Liste war, zumindest zum jetzigen Zeitpunkt und was den gerade von mir wiederhergestellten Teil angeht, überhaupt nicht zum Abarbeiten gedacht. Da standen nur noch Fälle drin, bei denen man die jeweiligen Klasse entfernen kann, aber nicht muss.

Eine entsprechende Anfrage kannst du jederzeit selbst stellen; ich persönlich habe ich das in unmittelbarer Zukunft eigentlich nicht vor, sondern sammle erst noch weitere Dinge, die man dann gleich mit erledigen kann. --Entlinkt (Diskussion) 22:55, 12. Jun. 2014 (CEST)

Ok, dann lasse ich das bis auf Weiteres liegen. ÅñŧóñŜûŝî (Ð) 14:48, 14. Jun. 2014 (CEST)

Ja, tu das bitte. --Entlinkt (Diskussion) 01:54, 15. Jun. 2014 (CEST)

Dankeschön

Hallo Entlinkt, danke für die kleine Änderung, ich hatte zwar gesehen, dass da jemand etwas verändert hatte, aber irgendwie bin ich dann gestern darüber weggekommen zu schauen wer das war und was geändert wurde. Daher hier noch mal ein herzliches Dankeschön von mir. --Liebe Grüße, Lómelinde Diskussion 11:14, 13. Jun. 2014 (CEST)

Shortcut der Vorlagen-Werkstatt sichtbar machen?

Hi,

ich weiß und respektiere, dass du aus guten Gründen die MediaWiki:Common.css schlank und effizient hältst, und jeder Sonderregelung abhold bist.

Aber würdest du es verschmerzen, wenn alle angeblichen Koordinaten der Vorlagen-Werkstatt unterdrückt werden, sodass ihr Shortcut wieder sichtbar wird? Jetzt glauben die Leute schon, wir hätten gar keinen, und denken sich neue Buchstabenkombinationen für uns aus. Die unterschiedlichsten Vorlagen, die die Fragesteller mit ihren Infoboxen usw. anschleppen, überpinseln sich alle gegenseitig. Und da ist die Werkstatt als Service-Einrichtung schon in einer anderen Rolle als eine gestaltete inhaltliche Seite; und als Kundenservice sollten die Kunden dann auch den Shortcut sehen können.

LG --PerfektesChaos 17:18, 19. Jun. 2014 (CEST)

Natürlich ist der jetzige Zustand mit Überlappungen totaler Murks (schon vom Grundansatz her, deswegen gibt es die Kategorie:Vorlage:mit absoluter Positionierung, um den Murks unter Kontrolle zu halten). Aber an den Überlappungen sind alle diese Vorlagen gemeinsam schuld: Wenn die Shortcut-Vorlage sich nicht absolut positionieren würde, könnte sie nicht von etwas anderem überlappt werden.

Bei der Koordinatenvorlage habe ich halbwegs Verständnis dafür, dass sie sich absolut positioniert, weil die Koordinaten (durchaus sinnvoll) oft über Infoboxen erfasst werden und irgendwer mal meinte, dass die Koordinaten außerhalb der Infoboxen stehen sollen – anders als durch absolute Positionierung (oder JavaScript) bekommt man es nicht hin, etwas von innerhalb einer Box nach außerhalb zu beamen.

Aber bei den Shortcuts sehe ich eigentlich gar keinen richtigen Grund, weshalb sie absolut positioniert sein müssten – en:Template:Shortcut ist auch nur eine ganz normale gefloatete Box. Eine Ausnahmeregel für die Vorlagenwerkstatt kann man durchaus machen, das könnte aber durchaus auch in der Koordinatenvorlage passieren (falls PAGENAME = Vorlagenwerkstatt, dann keine Artikelkoordinate ausgeben). --Entlinkt (Diskussion) 02:07, 20. Jun. 2014 (CEST)

• Es ist völlig klar, dass vor zehn Jahren Mist gebaut wurde, als man ein zufällig freibleibendes Fitzelchen da rechts oben neben der ja meist nicht so langen Seitenüberschrift ganz schlau für Bapperl & Co. ausgenutzt hatte.
• Ich kenne mich mit den Koordinaten nicht aus und mache seit Jahren einen Bogen um das ganze Geo-Zeugs.
  • Wenn das alles auf eine von allen beteiligten Vorlagen genutzte Stelle in einem einzgen core hinauslaufen sollte, dann wäre Vorlagenprogrammierung der optimale Weg.
  • Das würde die Arbeit dem Server aufbürden und nicht dem Browser des Lesers; und die Geo-Vorlagen sind so umfangreich, dass es auf ein if mehr oder weniger auch nicht mehr ankommt.
  • Bergi hatte das alles für uns mal programmiert; Benutzer:Tlustulimu kennt sich sehr gut in den Geo-Konzepten verschiedenster Sprachversionen aus.
• Zufällig und ohne Bezug zum Werkstatt-Fall wühle ich mich schon den ganzen Juni durch die Shortcuts.
  • Dabei ergibt sich, dass auf den Projektseiten und in den /Intro die Vorlage an den unterschiedlichsten Stellen eingebunden ist.
  • Ich habe Schwiergkeiten, meine Fehlermeldungen in den Projektseiten wiederzufinden. Teils stehen die am Ende der /Intro und landen auf der Seite im Innern dreier div-Schachtelungen unterhalb der Navi-Tableiste.
  • Ich begreife es nicht. Auch wenn es der Software egal ist, wo Kategorien, Schalter und Shortcuts im Quelltext stehen, gehören die Kategorien an das Ende und Schalter wie auch Shortcuts in die ersten Zeilen, damit dämliche Menschen wie ich das auf Anhieb sehen.
• Weil die {{Shortcut}} nunmal sehr häufig nicht in der ersten Zeile steht, kann man die absolute Positionierung auf absehbare Zeit nicht verlassen; sondern die Einbindungen verlassen sich darauf, dass die absolute Positionierung es schon richten wird.
• Damit scheidet ein banales float bis in weite Zukunft aus.
  • Ein weiteres Schmankerl: Vorlage:Portal/Projekt
• Es gibt im Seitenkopf allerhand div – aber möglicherweise nur in vector und nicht auf mobil und nicht sehr dauerhaft verlässlich.
  • Bei aktiviertem JavaScript könnte man irgendwas weiter nach oben schieben. Das gibt aber vermutlich Ruckler an einer besonders unglücklichen Stelle und belastet wieder den Browser.
  • .subpages machen sowas Ähnliches, #siteNotice müsste immer vorhanden sein und stünde oberhalb der Seitenüberschrift? Ist aber möglicherweise ausgeblendet.

Baldiges Wochenende --PerfektesChaos 10:40, 20. Jun. 2014 (CEST)

PS: Schnapsidee beim Drüberlesen:

• z-Koordinate für den Shortcut; diesen immer auf weißem Hintergrund mit padding-left?
• Die Koordinatenvorlagen kommen zwar später auf der Seite; bekommen aber nur ein halbes z und werden deshalb überdeckt?

Nur so eine Spontanidee; flexibel für alle anderen, die auch irgendwie gleichzeitig shortcut und Koordinate sehen.

VG --PerfektesChaos 10:46, 20. Jun. 2014 (CEST)

Also erstmal der Status quo:

• In Vector, Monobook und Modern werden die Textelemente durch absolute Positionierung in die Ecke oben rechts gepackt; in Colognelue und Mobile sind sie unsichtbar. Dabei stehen in Vector und Monobook alle Elemente an derselben Stelle, in Modern gibt es zwei Stellen (eine für Koordinaten und eine für alles andere). Weil je nach Skin das Platzangebot äußerst unterschiedlich ist, kann aber m. E. maximal ein solches Element pro Seite erlaubt sein – bei Vector und Monobook bereitet selbst dies schon Probleme.
• In Monobook und Modern werden auch die Icons durch absolute Positionierung in die Ecke gepackt, und zwar – mit zwei Ausnahmen – an dieselbe Stelle, so dass sie sich überdecken. Das funktioniert aber nur dann sauber, wenn die Icons alle quadratisch und gleich groß sind und lässt sich nicht ohne Weiteres auf Textelemente übertragen.
• In Vector werden die Icons durch JavaScript positioniert, was ziemlich gut und ruckelfrei funktioniert, weil die Icons so klein sind, dass meistens kein sichtbarer Reflow auftritt. Textelemente sind aber leider zu groß und es würde sicherlich zahlreiche Reflows geben. In der französischen Wikipedia werden auch die Koordinaten mit JavaScript positioniert und ich finde das dortige Geruckel durchaus störend.
• Es sind skinspezifische Unterschiede zu beachten:
  • Monobook und Cologneblue haben namensraumabhängig wechselnde Hintergrundfarben.
  • Modern hat im Seitenkopf einen dunklen Hintergrund und benötigt besondere Maßnahmen, damit die Schrift lesbar bleibt.
  • Vector verträgt in der rechten oberen Ecke zurzeit keinen z-index, weil sonst das ausklappbare „Mehr“-Menü zerstört wird. (Dafür wäre ein Workaround möglich.)
  • Bei Vector und Monobook stehen die Textelemente teilweise auf dem padding der #content-Box und teilweise bereits auf der Box der Hauptüberschrift oder der SiteNotice. Dort ist so verdammt wenig Platz, dass ein opaker Hintergrund bereits die SiteNotice überlappen würde, die sehr gerne selbst mit Rahmen und Hintergrund formatiert ist.
• Die gesamte Situation ist ziemlich komplex und selbst für technisch versierte Benutzer nicht leicht zu verstehen; diejenigen Benutzer, die inhaltlich mit den Vorlagen arbeiten, verstehen die technischen Probleme meist nicht und reagieren mit Ablehnung, wenn man darauf zu sprechen kommt.
• Viele Benutzer argumentieren auch gerne mal, dass es ja in den meisten Fällen halbwegs akzeptabel aussieht und dass es deshalb doch möglich sein müsse, es hinzubekommen, dass es immer akzeptabel aussieht – ihnen die Gründe zu erklären, warum das nicht so ist, ist ziemlich aussichtslos.
• Manche Benutzer stellen auch ziemlich ungeniert neue Problemvorlagen ein, wobei sie die eingerichteten IDs zweckentfremden und ihre Vorlagen so gestalten, dass sie die für diese Elemente vorgesehenen Dimensionen um ein Vielfaches überschreiten. Als Beispiel sei die Vorlage:All Coordinates in Kategorie:Ort in Mecklenburg-Vorpommern genannt, die sowohl viel zu breit als auch – dank des tollen Icons – viel zu hoch ist. (Als ich vor ein paar Jahren die Situation mal aufgeräumt habe, gab es diese Vorlage noch nicht und ich hatte damals ernsthaft überlegt, mittels overflow:hidden dafür zu sorgen, dass keine neuen Vorlagen angelegt werden können, die größer als die damals existierenden Vorlagen sind. Ich habe es nicht gemacht und bereue das jetzt.)
• Aus diesen Gründen habe ich nur eine sehr gering ausgeprägte Motivation, mich mit dem Thema überhaupt zu befassen – im Zweifelsfall eckt man überall an und stößt auf Leute, die, ohne die Probleme zu verstehen, argumentieren, dass an genau ihrer Vorlage natürlich auf keinen Fall irgendetwas geändert werden dürfe, weil sie ja schon immer funktioniert habe.
• Ohne eine grundsätzliche Änderung wäre jede Änderung, die man machen kann, ohnehin nur Flickwerk (vorhandenen Murks durch Hinzufügen von noch mehr Murks so aussehen lassen, als wäre er ein nicht ganz so schlimmer Murks). Eine grundsätzliche Änderung sollte meiner Meinung nach so aussehen, dass es eine Parserfunktion und eine Softwareerweiterung gibt, die alle Elemente mit der Parserfunktion einsammelt und genau eines davon im HTML nach oben schaufelt und alle anderen in den Orkus schickt. Es gibt auch einen Bug dafür, aber zurzeit wird meines Wissens nicht daran gearbeitet.
• Das Problem an sich ist international (speziell was die Koordinaten angeht), aber sein Ausmaß spezifisch deutschsprachig – Shortcuts zum Beispiel sind meines Wissens wirklich nur bei uns absolut positioniert und müssten es nicht sein. Natürlich verlassen sich die Einbindungen darauf, dass es „egal“ sei, wo auf der Seite die Elemente stehen (und bei den Koordinaten ist das so schlimm, dass man es m. E. nicht mehr beheben kann). Aber bei den Shortcuts halte ich es ehrlich gesagt durchaus für realistisch, die Einbindungen umzuarbeiten, so dass die Vorlage immer oben eingebunden ist.

Gruß --Entlinkt (Diskussion) 20:16, 20. Jun. 2014 (CEST)

• Naja, dann arbeiten wir mal konstruktiv am letzten Punkt.
• Für die ersten Juliwochen plane ich sowieso einen Botlauf, bei dem auf rund 2000 Seiten die Einbindung der Shortcut-Vorlage angefasst werden soll. Das werden etwa 80 % der Einbindungen sein.
• Also sollte durch den Bot nicht nur der irritierende Parameter entfernt werden, sondern die Einbindung sollte von woher auch immer in die allererste Zeile der Seite gescheucht werden.
• Danach käme eine weitere Phase, was mit den verbleibenden Einbindungen los ist und wozu die gut sind. Da wird man dann sehen.
• Ich halte es also für realistisch, alle Einbindungen in der ersten Zeile unterzubringen; auch wenn das bei den relativ häufigen /Intro etwas manueller Nacharbeit bedürfen könnte.
• Hilft dir das was für einen schlauen Skin-abhängigen style; womöglich sogar inline?

LG --PerfektesChaos 21:45, 20. Jun. 2014 (CEST)

Ich würde in Vorlage:CoordinateMain um die Artikelausgabe eine Namensraumabfrage machen, sowie es bei der Parserfunktion auch ist. Mann könnte überlegen, das Benutzerseiten und Vorlagen selber vielleicht auch noch erlaubt werden, aber ansonsten braucht man keine Koordinaten-Darstellung aus Infoboxen (oder generell) auf einer Seite. Der Umherirrende 09:16, 21. Jun. 2014 (CEST)

Feine Idee; aber vorher muss man noch einige aktuelle Projektseiten dafür vorbereiten:

• Wikipedia:AdminConvention 2014.I/Veranstaltungsort
• Wikipedia:Berlin/Communityspace
• Wikipedia:Lokal K/Adresse und Anfahrt
• Auf dieser Fresstour taucht sie aber nicht oben auf.
• Muss dann halt in den laufenden Text eingearbeitet werden.
• Bei Geschichten von 2008 und archivierten Seiten lohnt sich das nicht mehr.
• Mehr.

Unbeschadet dessen sollte im Juli ein Botlauf maximal ausgenutzt werden.

Schönes Wochenende --PerfektesChaos 10:24, 21. Jun. 2014 (CEST)