Benutzer Diskussion:Entlinkt/Archiv/2014

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, 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

[[Benutzer Diskussion:Entlinkt/Archiv/2014#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Benutzer_Diskussion:Entlinkt/Archiv/2014#Thema_1

„Gimmick für eine einzige Benutzerseite“

Vorlage:Beteiligen - Natürlich war es das in dem Moment, aber zum einen hat es die Anzeige ja bei niemand anderem beeinflusst, zum anderen wurde so erst eine (guckt man sich andere Vorlagen an, ziemlich standardmäßige) Möglichkeit für eigene Anpassungen anderer Benutzer geschaffen... --Quassy_.DE 09:40, 1. Apr. 2014 (CEST)

Die Parameter in Vorlage:Bausteindesign3 & Co. sind meines Wissens nicht primär für Benutzerseiten, sondern für Einbindungen innerhalb anderer Vorlagen gedacht (mit pragmatischer Begründung) und werden auch so verwendet (z. B. in Vorlage:Nur Liste). Nebenbei könnte man das Feature auch auf Benutzerseiten nutzen, habe ich aber bisher noch nicht gesehen.

Vorlage:Beteiligen ist eine simple, neutrale Layouttabelle, die m. E. eigentlich zu jedem Benutzerseitendesign passt. Zumindest sollten etwaige Parameter aber dokumentiert sein (sind sie bei Vorlage:Bausteindesign3 zwar auch nicht, das ist aber kein Grund). Außerdem gibt es sicherlich auch hunderte von Vorlagen, die keine individuelle Anpassungsmöglichkeit vorsehen.

Und statt class="toptextcells {{{class}}}" hat es dringendst class="toptextcells {{{class|}}}" zu heißen, andernfalls steht bei den ca. 500 Leuten, die die Vorlage ohne Parameter nutzen, wirklich class="toptextcells {{{class}}}" im Quelltext.

Solche individuellen Anpassungsmöglichkeiten bereiten übrigens immer gerne mal Probleme, wenn man in Zukunft das Layout einer Vorlage ändern möchte. Es gibt garantiert irgendwo irgendeinen Benutzer, der ein ganz extrem ausgefallenes Layout (mit abgerundeten Ecken und hastenichtgesehen) gewählt hat, das nicht zu den angedachten Änderungen passt und der deshalb fordert, dass die Vorlage nur im Einklang mit seinen Anpassungen geändert werden darf.

Gruß --Entlinkt (Diskussion) 12:50, 1. Apr. 2014 (CEST)

Lua in anderem Wiki

Hallo Entlinkt, vielleicht kannst du mir helfen. Im http://regiowiki.at (Version 1.20.0) habe ich vor 14 Tagen LUA installiert, das sind mir Vorlagen auf einen Scriptfehler aufgelaufen. Jetzt habe die Lua version auf ganz aktuell gestellt. Allerdings schmiert das Wiki ganz ab. Kann es sein dass Scribunto-refs/heads/mastertar.gz mit 1.22.0 nicht mehr kompatibel ist. WEnn du nichts weißt, vielleicht kannst du mir jemanden nennen, der sich da noch auskennt. --danke im Voraus K@rl 18:32, 5. Apr. 2014 (CEST)

Mit Lua kenne ich mich überhaupt nicht aus, ich habe noch nie damit gearbeitet. Nach meiner Einschätzung kennt sich Benutzer:PerfektesChaos am besten mit Lua aus, außerdem haben wir eine Lua-Werkstatt. Gruß --Entlinkt (Diskussion) 18:38, 5. Apr. 2014 (CEST)

Hmm; mit einer Installation hatte ich noch nie etwas zu tun. Wir haben ja hier das gemachte MediaWiki-Nest.

Was genau heißt „schmiert das Wiki ganz ab“? Fehlermeldungen?

Wurde irgendwas von Lua irgendwo auf einer Seite benutzt, oder klappt bereits die Installation der Erweiterung nicht?

Mit den Antworten dann am besten wie vorgenannt in der Wikipedia:Lua/Werkstatt aufschlagen, um hier die BD nicht zu fluten.

LG --PerfektesChaos 18:45, 5. Apr. 2014 (CEST)

Die Einrichtung der ersten Version hat geklappt und hat es korrekt in der Version angezeigt. Nur beim Aufruf einer Prozedur wie auf http://regiowiki.at/index.php?title=Benutzer_Diskussion:Gerold_Broser hier] ist ein Skripterror aufgetreten, egal welche Vorlage. Versucht habe ich STr sub und Str rightc Aber nicht zu finden was. Daraufhin hab ich die aktuelle Version der Lua Extension auf den Server kopiert. Darauf hin erscheint bei Aufruf jeder Seite eine ganze Menge an Fehlern und sonst nix, darauf habe ich es in der Lottalsettings wieder deaktiviert. danke K@rl 18:53, 5. Apr. 2014 (CEST)

Hm; hier ist eine BD und nicht wirklich Wikipedia:Lua/Werkstatt.

• Die jetzt aktuelle MW-Version von Lua dürfte für das regiowiki.at zu frisch und inkompatibel sein.
• Zurück auf den Zustand von vor 14 Tagen und dann die „Einrichtung der ersten Version“ wiederherstellen.
• Dass es da irgendwo „Skripterror“ gab, hat völlig andere Ursachen; im Zweifelsfall fehlende Module oder Konfigurationskram.
• Probiere dann zunächst mal nur das Modul:Hello bzw. euer Benutzer:Gerold_Broser/Modul:LuaHelloWorld. Das sollte laufen.
• Danach können wir gucken, warum was auf irgendeiner speziellen Seite nicht ging.

LG --PerfektesChaos 19:13, 5. Apr. 2014 (CEST)

bitte nicht nur 6 Stunden

Das Konto ist eine Sockenpuppe. Wille zur enz. Mitarbeit ist nicht erkennbar. Infint ist bei sowas angemessen. Danke. --Atomiccocktail (Diskussion) 20:26, 6. Apr. 2014 (CEST)

Das ist kein Account, sondern eine IPv6-Adresse. Gruß --Entlinkt (Diskussion) 20:27, 6. Apr. 2014 (CEST)

Ok, ich kenne diesen technischen Sachverhalt nicht. Der Artikel über Fraenkel ist jetzt aber gegen Attacken mit solchen Mitteln geschützt. Danke für deinen Einsatz übrigens. --Atomiccocktail (Diskussion) 20:47, 6. Apr. 2014 (CEST)

Benutzer:MerlBot

Kann es sein, dass der Bot ebenfalls spinnt: Auto-QS bei Dancing with the Storms wegen Links auf Begriffsklärungsseiten. Ich seh da keine einzige BKL, und ich habe das BKL-Helferlein eingeschaltet... --Jack User (Diskussion) 03:06, 9. Apr. 2014 (CEST)

Ich weiß nicht, was der Bot unter „viele“ versteht, aber es sind 2 BKL-Links drin (Französisch und Tornados). Das aktuelle Problem ist an sich auch nur ein Zwangslogout durch die MediaWiki-Software; die eigentliche Funktionsweise der Bots sollte davon nicht betroffen sein. Gruß --Entlinkt (Diskussion) 03:09, 9. Apr. 2014 (CEST)

Dann spinnt mein Helferlein. Oder es liegt daran, dass die Deutschwiki-Server gerade in den Fluten Hollands versinken? Vorlage:Smiley/Wartung/bekloppt  --Jack User (Diskussion) 03:14, 9. Apr. 2014 (CEST)

So, wie es jetzt ist, sollte es passen. (Ich denke, es ist vor allem wichtig, dass alle Archivierungen komplett durchgeführt oder komplett zurückgesetzt sind, damit nichts doppelt ist oder fehlt. Welches von beiden, ist aber egal.) Gruß --Entlinkt (Diskussion) 03:52, 9. Apr. 2014 (CEST)

Bezüglich meines Beitrags

Hallo, Was hat es denn mit diesem Edit auf sich? Was für eine "alte Version der Seite" habe ich angeblich "versehentlich Bearbeitet?"

So sieht die Bearbeitung aus, die du vornehmen wolltest. Tatsächlich hast du aber diese Bearbeitung vorgenommen und damit die Beiträge zweier Benutzer zurückgesetzt – nämlich genau diese beiden.

Solche Fehler sind gar nicht mal so selten und kommen vor, wenn man durch die Versionsgeschichte blättert und dann irgendwann oben „Bearbeiten“ klickt, während man eine alte Version betrachtet. Gruß --Entlinkt (Diskussion) 03:09, 10. Apr. 2014 (CEST)

OK, Leuchtet so halbwegs ein. (muss mich noch üben im Umgang diesbezüglich)--Eddgel (Diskussion) 03:36, 10. Apr. 2014 (CEST)

Mein Beitrag

bei Administratoren/Notizen war nicht unsachlich. Er hat dir nicht gefallen, das war alles. --80.187.111.3 20:50, 11. Apr. 2014 (CEST)

Allgemeine, unkonkrete Anschuldigungen gehören sich meiner Meinung nach einfach nicht und sind dazu geeignet, eine Diskussion unsachlich werden zu lassen. Gegen den neuen Beitrag mit konkreter Nennung eines bestimmten Accounts habe ich überhaupt nichts einzuwenden und hätte auch nichts einzuwenden gehabt, wenn du das gleich so gepostet hättest. Gruß --Entlinkt (Diskussion) 20:54, 11. Apr. 2014 (CEST)

Die übertriebene Sperrpraxis führt nur dazu, dass ich mich angemeldet nicht auf Metaseiten äußere. „Ist nicht seit 2004 angemeldet.“ „Gehört nicht zum Inner Circle.“ reicht inzwischen für solche willkürlichen Sperren. Mit denen sich mindestens ein Administrator (generisches Maskulinum) brüstet, wie mir berichtet wurde. Immer schön löschen, solche Beiträge, dann bleibt die Wikipedia-Welt heil. Für Manche, für Andere nicht. Überprüfe doch die Sperrpraxis des eifrigen Administrators (generisches Maskulinum). --80.187.111.3 21:00, 11. Apr. 2014 (CEST)

Hm, ich bin auch nicht seit 2004 angemeldet und würde mich auch keinem „Inner Circle“ zurechnen und wurde trotzdem nur einmal versehentlich gesperrt … Man kann Dinge auch auf verschiedene Art und Weise sagen und ich denke, das macht einen großen Unterschied. Wenn man mit bildzeitungsmäßigen Bindestrichkonstrukten wie „Itti-Opfer“ ankommt, sollte man sich echt nicht wundern.

„Mit denen sich […] brüstet, wie mir berichtet wurde“ ist auch wieder so eine Aussage. Ganz ehrlich, mir wäre es relativ egal, ob sowas irgendwo gelöscht wird. In dieser unkonkreten Form kann man den Vorwurf sowieso nicht überprüfen und wenn man es so schreibt, dass es niemand überprüfen kann, braucht man es eigentlich auch gar nicht erst zu schreiben. Gruß --Entlinkt (Diskussion) 21:09, 11. Apr. 2014 (CEST)

Du bist aber auch bald 7 Jahre dabei. Am Tag deines ersten Edits hatte auch der bekloppte Ösi Geburtstag, zum Glück war das nicht dein Anmeldedatum... Vorlage:Smiley/Wartung/bekloppt  --Jack User (Diskussion) 21:18, 11. Apr. 2014 (CEST)

Nimm dir mal zwei Stunden und prüfe die Sperren deines/deiner Kollegen/Kollegin, Entlinkt. --80.187.109.102 21:20, 11. Apr. 2014 (CEST)

RFC: Hilfe:Schriftunterstützung

Hallo, schaust du bitte gelegentlich über diesen Frischling? Danke schön und sonniges Wochenende --PerfektesChaos 12:57, 12. Apr. 2014 (CEST)

Ich habe momentan nur eher wenig Zeit und werde mir das auf jeden Fall genauer anschauen, sobald ich mehr Zeit habe.

Für den Moment stößt mir aber schon mal der Abschnitt #Vorlagen eher unangenehm auf. Ich halte den Großteil dieser Vorlagen keineswegs für erforderlich, sie sind in modernen Browsern größtenteils durch einen CSS-Hack in MediaWiki:Common.css absichtlich wirkungslos und auch das konkrete Beispiel Altgriechisch stimmt meiner Meinung nach nicht.

Beispiel Altgriechisch: In der Common.css steht

* html .polytonic {
	font-family: "Arial Unicode MS", "Palatino Linotype", Code2000, "New Athena Unicode", "Gentium Plus", Gentium, "Athena Unicode";
}

und man beachte hierbei, dass der Selektor * html absichtlich unsinnig ist: html besitzt kein Elternelement und deshalb wird die gesamte Regel nur vom fehlerhaften CSS-Parser des IE 6 ausgewertet (Star-HTML-Hack).

Das ist seit vielen, vielen Jahren so, d. h. für fast alle Benutzer wird Altgriechisch in der Standardschrift des Browsers dargestellt und es hat sich auch seit vielen Jahren niemand mehr über fehlende altgriechische Zeichen beschwert.

Ganz im Gegenteil: Wenn die Regel in modernen Browsern aktiv wäre, dann würde es wohl Beschwerden geben.

• „Arial Unicode MS“ ist mittlerweile zum Glück nicht mehr so verbreitet, aber wenn es benutzt werden würde, wäre das Ergebnis typografisch ziemlich katastrophal wegen schwerwiegender Bugs in diesem Font. Ich hatte vor Jahren mal eine Seite gelesen, auf der Microsoft selbst davon abrät, diesen Font zu benutzen, weil er typografisch minderwertig sei. Seine Stärke war, dass er um 2000 herum zu den Fonts gehörte, die die meisten Codepunkte unterstützten, man konnte ihn deshalb gut als Notlösung gebrauchen, wenn man nicht im Detail einen für das konkrete Problem passenden Font suchen wollte und die Qualität weniger wichtig war („Holzhammermethode“). Seitdem sind aber auch viele neue Codepunkte hinzugekommen, die in Arial Unicode MS fehlen.
• Der erste und einzige weit verbreitete Font in dieser Liste ist „Palatino Linotype“, eine Serifenschrift und folglich garantiert nicht passend zum Haupttext. Gerade heute erst habe ich unter en:Wikipedia:Typography gelesen, dass Serifenschriften eigentlich fast immer kleiner als serifenlose Schriften aussehen und deshalb skaliert werden müssten, wenn man sie mit serifenlosen Schriften mischt. Auf dem System, an dem ich gerade sitze (ein aktuelles Linux), stimmt das auch: Das Schriftbeispiel auf der englischen Seite ist zu klein.
• Die übrigen aus der Liste sind kaum verbreitet und dürften deshalb kaum eine Wirkung haben. Die Liste besitzt allerdings keine generische Familie als Abschluss und bei den meisten Browsern bedeutet das im Klartext serif, d. h. die Liste hätte im Endeffekt als Hauptwirkung, dass für Altgriechisch nicht die Standardschrift des Haupttextes benutzt wird, aber welche letztlich benutzt wird, weiß man nicht so genau.

Und das alles, obwohl es überhaupt nicht nötig ist: Laut einer Statistik hat der IE 6 in diesem Monat in Deutschland einen Marktanteil von 0,05 % und andere Browser brauchen diese Schriftenliste einfach nicht, sondern kommen mit der Standardschrift zu einem Ergebnis, das die meisten Leute wohl zufriedenstellt und all die Probleme vermeidet, die man aktuell anlässlich des Vector-Troubles wieder gesehen hat.

Ich spiele deshalb schon länger mit dem Gedanken, einen Löschantrag auf Vorlage:Polytonisch zu stellen, warte aber noch etwas, bis Windows XP wirklich endgültig ausgestorben ist und der IE 6 aus der Liste der durch MediaWiki unterstützten Browser gestrichen wird – das kann nicht mehr allzu lange dauern. Vorlage:Okina wirkte übrigens auch nur im IE 6 und wurde bereits gelöscht und wird nicht vermisst.

Nach meiner Erfahrung werden Lateinisch, Griechisch, Kyrillisch, Arabisch, Hebräisch, Georgisch, Armenisch, CJK, Thai auf aktuellen Systemen in der Standardkonfiguration ziemlich unproblematisch angezeigt (darunter fallen bspw. auch IPA und polytonisches Griechisch); durch den Versuch, die Konfiguration zu verbessern, verschlechtert man die Lage meistens eher.

Es mag sein, dass das bei einigen sehr „exotischen“ (Sorry für den Ausdruck) Schriftsystemen nicht so ist. Konfigurationsänderungen sollten sich dann aber auf die Fälle beschränken, in denen das wirklich nötig ist (um die Lage dort, wo sie bereits in Ordnung ist, nicht zu verschlechtern) und sich in erster Linie an den Systemen orientieren, die viele Leute benutzen (also nicht wegen einzelner Keilschriftbuchstaben im IE 6/7 etwas tun, was die Darstellung von ABC für die 99,85 % Nicht-IE-6/7-Benutzer negativ beeinflusst).

Man muss hier auch etwas vorsichtig mit den Diskussionsarchiven sein, es gibt sehr viele alte Diskussionen der Art „wegen dem IE ist dies und jenes unbedingt erforderlich“ und dabei ist es in vielen Fällen seit dem IE 8 eben gerade nicht mehr erforderlich. Andererseits gibt es wohl auch einige Probleme, die nicht nur den IE, sondern auch andere Browser unter Windows betreffen.

Gruß --Entlinkt (Diskussion) 14:34, 12. Apr. 2014 (CEST)

Danke für deine Hinweise und die Mühe für die umfangreiche Ausarbeitung.

• Ich hänge nicht an diesem altgriechischem Punkt.
  • Er resultiert aus meiner subjektiven Beobachtung der Software seit Mitte der 1990er Jahre.
  • Wenn man nun bald davon ausgehen kann, dass alle relevanten Systeme der Leser der einen oder anderen Krücke nicht mehr bedürften, dann ist das fein, und dann kann dies gern weg.
  • Ich bin kein systematischer Web-Entwickler mit -zig Browserversionen.
  • Meine persönliche Erfahrung geht allerdings dahin, dass FF der einzige ist, der mit dem font matching klarkommt und alles allein macht.
    • Ich habe es gerade eben mit der neuesten Opera-Version ausprobiert; die kann das auch nicht.
    • Der IE versagt auch gewohnheitsmäßig. Ich habe ihn allerdings nicht bewusst installiert, sondern er ist in unterschiedlichen Versionen mit drauf, weil er bei der Windows-Installation mit bei war. Insofern muss ich immer von einer Maschine zur nächsten Adresse pilgern, um einen systematischen Überblick zu gewinnen. In diesen Wochen stirbt mit XP mein IE8; er wird zum Ubuntu. IE10 habe ich grad nicht.
  • Chromium kann es nur mit style-Hilfe, ohne font matching.
• Man müsste systematischer untersuchen, was auf verbreiteten Betriebssystemen unterstützt wird. Für das kürzlich entsupportete aber weitverbreitete XP war es el(+alt) cy ar he IPA ohne CJK oder asiatisch. Bei Linux-Distributionen blicke ich nicht durch und finde nur die namhaften Angebote unproblematisch, auf Apple und mobil bin ich völlig blind und habe keinerlei Überblick aus eigenem Erleben. Die Sprachen, die man als Europäer verstehen könnte, werden durch installierte Fonts bereits unterstützt; deshalb stehe ich ULS für lateinische Anwender distanziert gegenüber.
• Ich wurde mal gebeten, im Zusammenhang mit der Vorlage:Keilschrift zu unterstützen, und habe aus der Zeit auf einer Maschine noch CuneiformComposite – ein wunderbarer Kandidat zur Erprobung auf unterschiedlichen Browsern und Maschinen mit/ohne.
• Zu der Hilfeseite kam ich wie die Jungfrau zum Kind.
  • Siehe Ende des Abschnitts WP:FR #Fraktur-Schrift-Möglichkeit.
  • Nach einem Dreivierteljahr Hilflosigkeit und zunehmenden Anfragen war es einfach unausweichlich.

Schönen Sonntag --PerfektesChaos 00:24, 13. Apr. 2014 (CEST)

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:TU23/Community-Raum
• 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)

Anpassungswunsch Infobox: Behörde

https://de.wikipedia.org/wiki/Vorlage_Diskussion:Infobox_Deutsche_Beh%C3%B6rde

Hallo, ich hatte einen Änderungshinweis an der Infobox Deutsche Behörde gepostet. Diese Infobox sei wohl von Ihnen erstellt worden. Können Sie mir da weiterhelfen? Vielen Dank FBALauf

Hier der Bezug.

Eigentlich habe ich mit der Vorlage:Infobox Behörde nicht viel zu tun, ich habe dort lediglich mal ein paar kleine formale bzw. layoutbezogene Änderungen gemacht.

Inhaltlich kenne ich mich in diesem Bereich überhaupt nicht aus. Sorry. --Entlinkt (Diskussion) 00:12, 12. Aug. 2014 (CEST)

CSS-width bei input-Element

Hi, eine Fachfrage: Auf WD:HW/VM#length="max" geht es darum, die Stellenbreite eines <input type="text"> über width zu beeinflussen.

• Das kann meinem Verständnis nach nicht funktonieren, wie dort dargestellt.
• Hinzu kommt, dass die width sich nicht auf die statische Fensterbreite minus irgendwelcher Ränder bezieht, sondern ein dynamisches <div> – jedes <input> ist mit Beschriftung eingepackt in ein <div style="float:left"> und diese laufen hintereinander weg und werden also vom linken Rand aus nebeneinander angeordnet, bis sie an den rechten Rand stoßen.

Irgendwelche Ideen? LG --PerfektesChaos 11:17, 23. Jul. 2014 (CEST)

Ich kann ehrlich gesagt nur bedingt folgen. (Im Betawiki kann ich mich wegen der Titleblacklist nicht anmelden, könntest du den Eintrag dort bitte rausnehmen?)

Ich habe jetzt mal auf Wikivoyage den Vorlagenmeister aktiviert und beim Bearbeiten von voy:Karnak beim entsprechenden <input>-Element von Hand in Chromiums Entwicklertools size="100" entfernt und stattdessen class="tm_input_max" eingefügt und sehe das Problem, dass das nicht die vermutlich gewünschte Verbreiterung des <input>-Elements bewirkt.

Der Grund ist einfach, dass width:100% die Breite eines Elements auf die Breite des Elternelements setzt und das Elternelement eine Tabellenzelle ist, die wiederum zu einer Tabelle gehört, die wiederum in einer gefloateten Box steht. Um den vermutlich gewünschten Effekt zu erreichen, könnte man folgendes tun:

1. Das übergeordnete gefloatete <div> mit folgendem versehen: box-sizing:border-box; width:inherit
2. Die darin enthaltene Tabelle mit width:100% versehen
3. Jetzt wird das width:100% beim <input>-Element Wirkung zeigen, und zwar auch ohne !important

Alles in allem ist das Markup aber ziemlich unschön (mit Layouttabellen, geht es auch ohne?) und das CSS ziemlich grässlich (an dem !important erkennt man immer ganz gut nicht funktionierenden Code: Wenn in CSS eine Deklaration keine Wirkung zeigt, fügen viele Leute !important ein und meinen, dass es dann funktionieren muss, beheben aber die eigentliche Ursache nicht und der fehlerhafte Code bleibt inklusive !important stehen).

Gruß --Entlinkt (Diskussion) 01:47, 24. Jul. 2014 (CEST)

• Ich wusste doch, dass ich jemand fragen muss, der sich mit sowas auskennt.
• Auf Beta habe ich dich und alle weiteren Benutzernamen, die sich auf der echten WP nicht erneut anmelden sollen, aus der Blacklist rausgenommen.
  • Sag hier bitte piep, wenn du der bist, der dort einen Account angelegt hat.
• Das CSS kannst du im Unterschied zu mir bitte gleich selbst verbessern.
  • MediaWiki:Gadget-Vorlagenmeister.css wirkt zentral auf alle Projekte einschließlich Beta und voy:.
  • Könnte Cache-Leerung bedürfen, weil erst nach zwei Wochen mit einer Änderung gerechnet wird.
  • div.tm_formelem ist ja wohl das, welches anzupassen wäre. (nicht Formel-EM, Form-Elem – ich bin immer wieder neu irritiert)
• Die !important kanst du nach Belieben der Übersichtlichkeit halber rauswerfen.
  • Nach meinem Verständnis hatte das bei keinem Browser je Wirkung gezeigt, wenn man nicht einen expliziten Inline-Style per Selektor wieder übertrumpfen wollte.
  • Im Vorlagenmeister gibt es meines Wissens keinerlei dekorativen Inline-Style.
• An die Layouttabellen möchte ich nicht ran, sondern nur Funktionsdefizite beheben. Ich bin nicht der Entwickler von dem Dings, und beabsichtige auch nicht den Weiterentwickler zu geben. Sonst müsste ich die Umprogrammierung auch noch testen. Was du wohl meinst, steht im JS-Code zu Beginn als XML/XSL-Zeichenkette, und die tm_table ist später mit einer programmatischen Anweisung verknüpft. Das könnte allerdings auch ein div machen; die <tr> und <td> werden vom JS nicht angefasst. Wenn du magst, kannst du nach meinem nächsten Update (vermutlich dieses Wochenende) auf Beta dieses XML/XSL-Zeugs umschreiben und ausprobieren.

LG --PerfektesChaos 10:45, 25. Jul. 2014 (CEST)

Ich habe mich jetzt im Betawiki registriert, mit dem Rest befasse ich mich irgendwann später (Zeitknappheit). --Entlinkt (Diskussion) 13:34, 25. Jul. 2014 (CEST)

Ich hatte auch zwei Wochen überwiegend hitzefrei; auf kleiner Flamme garend hatte ich langsam weitergeköchelt:

• Anders als oben beschrieben (zentrales CSS für alle Projekte; kein Bock auf Stilfragen gehabt) habe ich nunmehr ein wirksames β-CSS abgespalten. Es hat zurzeit eine Cache-Verweildauer von 0 Sekunden; die β-Server brauchen jedoch meist 10–30 Sekunden, bis sie die Änderung mitbekommen und in neue Seitenaufrufe einbauen.
• JS und CSS des Vorlagenmeister wurden in die hiesige Produktivversion kopiert und stehen zum freien Verschandeln frei: core.js mit Artikel Karnak.
• Oben httest du Layouttabellen beanstandet. Die darfst du gern eliminieren. Soweit ich das deute, ging es darum, dass <label> und <input> zusammengehalten werden sollen und offenbar zur Entstehungszeit das nowrap noch nicht in allen damals gebräuchlichen Browsern verfügbar war. Ein übergeordnetes div würde dann reichen, und floatet und bekäme die von dir oben beschriebenen Eigenschaften. Für neue Klassen-Namen tm_form-elem sowie bei Bedarf form-label, form-input statt des formel·em wäre ich dankbar.

LG --PerfektesChaos 22:32, 11. Aug. 2014 (CEST)

Bitte um Hilfe bei Tabelle

Hallo Entlinkt,

im Vorlageartikel über Tabellen bin ich auf dich gestoßen; du scheinst dich damit auszukennen. Ich möchte in meinem Baustellen-Artikel Benutzer:Danny15/Entwurf/Artikel-Verbesserungen und -ergänzungen gerne eine Tabelle über eine Buchreihe erstellen, allerdings gelingt mir aus irgendeinem Grund der Zeilenumbruch nicht. Könntest du einen kurzen Blick darauf werfen und eventuell einen Umbruch machen? Ich wäre dir sehr verbunden. Vielen Dank und schöne Grüße. --Danny15 (Diskussion) 14:29, 31. Jul. 2014 (CEST)

Sorry für die späte Antwort, ich hatte Zeitmangel und deshalb die Anfrage nicht direkt verstanden.

Ich gehe davon aus, dass das Problem mit der Tabellensyntax durch diesen Edit gelöst ist? (Oben das kaputte und unten das erwünschte Aussehen?)

Viele Grüße --Entlinkt (Diskussion) 00:18, 12. Aug. 2014 (CEST)

WP:MW/Ä

Hi, ich wende mich an dich, weil du dich neulich auf Koenraads BD einschlägig geäußert hattest; auch auf WP:A/A.

• Außerdem ist mir die Angelegenheit auf Benutzerseiten zurzeit lieber, denn auf einer offiziellen Projektseite. Es mag aber jemand auf eine Vorder-Unterseite verschieben, oder als WP:A/N-Unterseite anlegen. Das stünde mir aber nicht zu.
• Die Konzeption köchele ich seit zwei Wochen aus.
• Letztlich ist es eine freiwillige Selbstverpflichtung der Admins.
  • Allgemeine Anerkenntnis als good practice würde reichen; nur bei hartnäckigem Ignorieren würde sich der Aufwand eines MB lohnen.

Ich schlage vor, eine per Shortcut WP:MW/Ä erreichbare Forumsseite Wikipedia:Technik/Skin/MediaWiki/Änderungen einzurichten; Details nachstehend.

Aufgaben

Bündelung von Aktivitäten im MediaWiki-Namensraum.

1. Änderungswünsche durch Nicht-Admins, wie bislang auf WP:A/A mitgeteilt.
2. Rechtzeitige Ankündigung wesentlicher Änderungen durch Admins.
3. Zentrale Dokumentation.

Ziel

Alle Admins und andere technisch interessierten Benutzer sollen durch Beobachtung nur einer einzigen Seite Gelegenheit bekommen, vor der geplanten Änderung Rückfragen zu stellen.

Wesentliche Änderungen

• Alle wesentlichen Änderungen sind 24 Stunden vorher anzukündigen.
• Gibt es in diesem Zeitraum keinen Widerspruch, kann die beabsichtigte Maßnahme umgesetzt werden; andernfalls ist die Diskussion im Einzelfall maßgeblich. Bis die Fragen geklärt sind, wird die Aktivität ausgesetzt.
  • Alternativ könnte man darüber nachdenken, eine explizite Bestätigung eines zweiten Admins einzufordern. Das ist aber eine größere Bürokratisierung. Alle bisherigen Problemfälle wären bei Vorankündigung auf Diskussion und Widerspruch gestoßen, und die vorherige Ankündigung und Abwarten für einen angemessenen Zeitraum ist bewährte Praxis in ANR und Meta-Bereich. Eine explizite Zustimmungspflicht könnte die Vorgänge dagegen lähmen; oder befürchten lassen, für die inhaltliche Ausarbeitung zur Verantwortung gezogen zu werden, obwohl man daran nicht beteiligt war.
  • Bislang war die einzige Möglichkeit, nachträglich die bereits vorgenommene Änderung zu reverten oder mit dem ändernden Admin eine Privatdiskussion zu beginnen. Dieses nachträgliche overrulen wurde jedoch wohl nur selten praktiziert. Hingegen ist es leichter, vor der Änderung nach dem Sinn und Zweck genauer nachzufragen oder einen anderen Lösungsweg zu wünschen.
• Temporäre Einfügungen können auch gleich mit der Ankündigung ihrer Entfernung nach Eintreten bestimmter Umstände verbunden werden und bedürfen dann keiner zweiten Diskussion.

Ausnahmen von der Fristenregel

Keiner Ankündigungen bedarf es bei:

• Abwehr von Schadsoftware; Schließung von Sicherheitslücken
• Revert oder Reparatur einer kürzlichen Aktion
• Aktuelle völlige Unbrauchbarkeit von Seiten (Hotfix)
  • (nicht jedoch eine hübschere Optik oder alternative Features)
  • Unmittelbar anschließend ist hier eine Erläuterung dazu zu dokumentieren.
• Sitenotice in gebräuchlichen Fällen (Kandidatensuche, Wettbewerbe, überregionale Treffen, besondere Anlässe von projektweiter Bedeutung)

Unwesentliche Änderungen; keine Fristenregel

• JavaScript: Korrektur von Meldungstexten, Linkfixe, im Programmablauf unwirksame Änderungen an Kommentaren oder Whitespace.
• CSS:
  • Dekorative Eigenschaften vorhandener Elemente, etwa Vergrößerung einer Schriftgröße von 75 % auf 85 %, kontrastreicherer Farbwert, andere Längenmaße bei Rahmen oder padding.
  • Linkfix
  • Keine sichtbare Auswirkung auf Seiten; beispielsweise: Entfernung nicht mehr benutzter Selektoren, Entfernung von Regeln ohne verbleibende Selektoren, unangemessene Spezifität, Sortierung von Stilen und Attributen, Kommentare, Whitespace.
• Textliche Systemnachrichten:
  • Schreibfehler, Linkfix
  • Verständlichere Erläuterungen; Ergänzungen

Unabhängige JavaScript-Programmeinheiten

• Hierzu zählt auch MediaWiki:Gadgets-definition (hat analoge Auswirkungen und bedarf der Erprobung, wie Krinkle gerade gesetern am bkl-check lernen musste).
• Sie sollen grundsätzlich vorher auf beta.wmflabs.org zur Erprobung im Kontext bereitgestellt werden.
• Anzukündigen oder zu wünschen wäre hier nur das Update, ggf. mit Verweis auf die Dokumentation zum Gadget.
• Oft geschieht die wesentliche Veränderung jedoch an ganz anderer Stelle; beispielsweise Benutzer:PDD/markAdmins.js oder en:User:Cacycle/wikEd.js und bleibt unbemerkt.

Unabhängige JavaScript-Programmeinheiten, namentlich Gadgets, brauchen andere Mechanismen der Qualitätssicherung; insbesondere eine Pflichterprobung im Kontext. Während die Änderungen auf den großen Konfigurationsseiten meist klein sind und sich gut auf einer Diffpage darstellen lassen, können Überarbeitungen von Gadgets Hunderte von Zeilen betreffen (vorher/nachher) und die Diskussion darüber würde eine zentrale Seite sprengen. Die Auswirkungen lassen sich auch nicht auf einer Diffpage im Quellcode abschätzen, sondern bedürfen praktischer Ausführung im Zusammenhang mit anderen Seiten und Einstellungen und Browsern.

• Die ausgliederungsfähigen längeren Blöcke der großen Konfigurationsseiten sollten gemäß Wikipedia:Technik/Skin/Gadgets #hidden in Pseudo-Gadgets überführt werden; desgleichen die bisherigen JS-Unterseiten. Sie können dann per default oder konditional als Modul eingebunden werden.
  • Damit ist die Möglichkeit der separaten Erprobung im Kontext gegeben, und kein Gefummel mit dem Kopieren einzener Zeilen. Anschließend wird en bloc übernommen.
• Bereits seit 2011/2012 steht das Konzept eines eigenen Namensraums nur für Gadgets im Raum. Seit Mitte 2012 kam aber „Gadgets 2.0“ und jegliche Weiterentwicklung auf diesem Gebiet zum Erliegen.
• Siehe auch WD:HW #Qualitätsstandards für Gadgets

• Die bisherigen Einzeldiskussionsseiten der großen Konfigurationsseiten und deren Archive sollten in eine Archivstruktur der neuen Seite verschoben werden und durch Weiterleitungen ersetzt werden.

Gute Nacht --PerfektesChaos 23:57, 27. Aug. 2014 (CEST)

Vorläufige Antwort per Mail. --Entlinkt (Diskussion) 00:09, 28. Aug. 2014 (CEST)

Alles klar; kurz überfliegen und auf WP:A/N abkippen würde langen. Oder Kollegen anpieken, der übernehmen möge. LG --PerfektesChaos 00:32, 28. Aug. 2014 (CEST)

Petra Zais

Ging es in dem von dir gelöschten Artikel um die mit an Sicherheit grenzender Wahrscheinlichkeit in wenigen Stunden als Mitglied des Landtags feststehende Politikerin der Grünen, die 1957 geboren wurde? [1] (Listenplatz 7) --91.56.195.216 19:28, 31. Aug. 2014 (CEST)

Ja. --Entlinkt (Diskussion) 20:52, 31. Aug. 2014 (CEST)

Angesichts der aktuellen Hochrechnungen, die sogar 8 Sitze für die Grünen errechnen, kann mit mathematischer Sicherheit davon ausgegangen werden, dass Frau Zais durch Listenplatz 7 MdL wird und damit die RK erfüllt. Ich bitte daher um Wiederherstellung. --91.56.195.216 21:53, 31. Aug. 2014 (CEST)

Ja, mit Widerwillen. Ich sehe zwar nicht, warum das nicht warten könnte, bis hier ein Wahlergebnis verlinkt wäre (das ist eine Geduldsprobe von maximal einigen Stunden). Aber sonst gibt’s eh nur unnötige Diskussionen. --Entlinkt (Diskussion) 22:09, 31. Aug. 2014 (CEST)

Deine Änderung in Vorlage:Obsolete Schreibung

Moin, durch deine Änderung sind offenbar alle mit der Vorlage versehenen Seiten in der Kategorie:Wikipedia:Defekter Dateilink gelandet. Kannst du das bitte mal überprüfen? Danke und viele Grüße, XenonX3 – (☎) 13:14, 4. Sep. 2014 (CEST)

Ich hatte leider das Pech, die Vorlage zufällig genau in dem Moment abzuspeichern, in dem dieses Softwareproblem aufgetreten ist (Ausfall aller Commonsbilder aus mir bis jetzt unbekanntem Grund). Dadurch wurden die Seiten kategorisiert, weil das Icon in der Vorlage kurzzeitig fehlte.

Ich kann da nicht wirklich was machen. Es würde reichen, auf jeder dieser Seiten einen purge zu machen, aber um das von Hand zu machen, sind es deutlich zu viele. Falls es wichtig ist, könnte vielleicht ein Botbetreiber so nett sein … Andernfalls einfach warten, die Seiten werden sich automatisch wieder entkategorisieren. Gruß --Entlinkt (Diskussion) 14:44, 4. Sep. 2014 (CEST)

Ahh, das erklärt natürlich alles. An den Commons-Ausfall hatte ich gar nicht gedacht. Dann warten wir einfach mal, bis sich der Fehler von selbst erledigt. Grüße, XenonX3 – (☎) 14:47, 4. Sep. 2014 (CEST)

Die Kategorie ist wieder „sauber“. --Entlinkt (Diskussion) 22:08, 4. Sep. 2014 (CEST)

prettytable

Hallo, könntest du die paar unter Wikipedia:Technik/Baustellen/prettytable_und_wikitable#Verbleibende_Seiten aufgeführten Seiten erledigen? Ich habe jetzt das meiste abgearbeitet, aber die paar sind entweder gesperrt oder für mich zu schwierig zu korrigieren. 85.212.8.235 19:50, 11. Sep. 2014 (CEST)

Bei Gelegenheit, ja.

By the way: Möchtest du dich nicht anmelden? Als angemeldeter (und – wichtig – einigermaßen „etablierter“) Benutzer wird man nach meinem Gefühl weniger revertiert. --Entlinkt (Diskussion) 20:56, 11. Sep. 2014 (CEST)

Schon richtig, aber will ich trotzdem nicht. 85.212.8.235 20:58, 11. Sep. 2014 (CEST)

verschiedene Layouts trotz Verwendung von meta:global.css

Hallo Entlinkt! Trotz der Verwendung der global.css auf meta meta:user:Doc Taxon/global.css sieht mein Layout in der de:WP anders aus als in all den anderssprachigen Wikis. Ansonsten sind die Layouts jetzt in jeder Sprache exakt gleich, außer eben hier. Als Beispiel zu nennen wäre da die unterschiedliche Schriftgröße in p-cactions und p-personal und in h2, h3 usw., unterschiedlich große Zeilenabstände im Artikel, die Links in p-navigation und p-lang sind hier unterstrichen (in allen anderen Wikis nicht). Naja, und so weiter. Cache habe ich mehrfach geleert. Das ist im Firefox genauso wie im IE der Fall. Irgendwas also geht da nicht. Monobook.css und .js verwende ich hier jetzt nicht mehr. Also irgendwas stimmt da nicht. Soweit ich weiß, sollte die meta:global.css global für alle Wikis gelten. Grüße, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 08:02, 14. Sep. 2014 (CEST)

Als erstes würde ich mal meta:User:Doc Taxon/common.css leeren: Die Seite sollte unnötig sein, weil meta:User:Doc Taxon/global.css (soweit ich das verstanden habe) auch auf Meta selbst gilt. Die Leerung hätte den Vorteil, dass es weniger Verwirrung gibt. --Entlinkt (Diskussion) 20:00, 14. Sep. 2014 (CEST)

Als nächstes fällt mir auf, dass du Schriftgrößen in der Einheit pt angibst. Es sollte zwar nicht daran liegen, aber diese Einheit ist in CSS sinnlos, weil (im Gegensatz zu anderen Umgebungen, wo pt anders definiert sein kann) in CSS immer 3pt = 4px gilt. Ich würde das in px umrechnen. --Entlinkt (Diskussion) 20:07, 14. Sep. 2014 (CEST)

Was hast du unter Spezial:Einstellungen#mw-prefsection-rendering bei „Links unterstreichen“ eingestellt? Die sinnvollste Einstellung ist meiner Meinung nach „abhängig von der Benutzeroberfläche oder Browsereinstellung“. --Entlinkt (Diskussion) 20:12, 14. Sep. 2014 (CEST)

Hey super, dass prefsection-Dinx ist super, jetzt sind die Links nicht mehr unterstrichen. Wegen px und pt schau ich mal. Danke sehr, -- Doc Taxon @ Disc – ♥ BIBR ♥ – 09:08, 15. Sep. 2014 (CEST)

Die WikiEulenAcademy gratuliert zur Nominierung für die TechnikEule

Hallo Benutzer:Entlinkt,

als fleißiger Kammerjäger (Bugs) und Mitarbeiter in der Technikwerkstatt warst du für die WikiEule 2014 nominiert. Du bist daher berechtigt folgenden Babel zu führen:

Dieser Benutzer war nominiert für die TechnikEule 2014.

Selbstverständlich darfst du ihn auch in den anderen „Wikis“ führen. Auf Wikidata, wo wir gleich noch x-posten werden, ist er schon vorbereitet.

Die WikiEulenAcademy dankt dir für dein Engagement und gratuliert sehr herzlich zur Nominierung für eine WikiEule. Wir wünschen viel Freude mit dem Babel und hoffen auf weitere großartige Beiträge.

Mit lieben Grüßen,
die WikiEulenAcademy (Diskussion) 00:50, 11. Okt. 2014 (CEST)

Herzlichen Glückwunsch zur Nominierung zutr Technikeuele und Vielen Dank für deine Hilfe --ApolloWissen • bei Fragen hier 10:32, 11. Okt. 2014 (CEST)

Auch von mir herzlichen Glückwunsch zur Nominirung und vielen Dank für deine Hilfe. Funkruf ^WP:CVU 10:48, 11. Okt. 2014 (CEST)

Das ist aber eine nette Überraschung. Vielen Dank! Gruß --Entlinkt (Diskussion) 06:04, 13. Okt. 2014 (CEST)

die schöne Vergangenheit ...

nur zur Information: Auf Diskussion:Bady_Minck bzw. dem Artikel geht es wieder los, d.h. Geburtsdatum und -ort werden herausgenommen, diesmal sogar das Bild. Ich hatte revertiert, nachdem ich mir lb:WP und die Disk angesehen hatte. Mit Gruß, mir eilt's net. --Emeritus (Diskussion) 02:05, 9. Nov. 2014 (CET)

Hilfe:Textgestaltung/Zentrieren

Hallo,

es war schön, kürzlich von dir wieder einen Edit zu sehen.

Ich hoffe, alles hatte geklappt, was du dir für Oktober/November vorgenommen hattest.

Um dich wieder langsam an das Wikipedia-Alltagsgeschäft heranzuführen, hätte ich ohne jede Eile ein Waisenkind im Abschnittstitel verlinkt, mit der Bitte um Prüfung auf fachliche Richtigkeit, erforderliche Ergänzungen oder verständlichere Darlegungen. Hintergrund ist ein Eliminierungsdurst von <center> durch einige strikte HTML5-Befolger, der allerdings an äquivalenter Syntax scheitert, und so trivial und global lässt sich gerade die Zentrierung auch nicht umstellen.

LG --PerfektesChaos 23:41, 9. Dez. 2014 (CET)