Benutzer Diskussion:Entlinkt/Archiv/2016

aus Wikipedia, der freien Enzyklopädie
< Benutzer Diskussion:Entlinkt
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 12. Januar 2017 um 13:10 Uhr durch imported>TaxonBot(1824919) (1 Abschnitt aus Benutzer Diskussion:Entlinkt archiviert).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Vorlage:INSEE-ISO 3166-2

Hallo Entlinkt, könntest Du mir bei einem kleinen Problem mit der von Dir gebauten Vorlage:INSEE-ISO 3166-2 helfen? Ich würde die gerne so anpassen, dass sie auch für die neuen INSEE-Codes für das Département Rhône und die Métropole de Lyon (69D bzw. 69M) funktioniert, aber alle Versuche das anzupassen, scheinen nur die Vorlage an anderer Stelle kaputt zu machen. Tausend Dank schon jetzt! --Pampelonne (Diskussion) 22:12, 7. Jan. 2016 (CET)

Hm? Meines Wissens haben immer noch beide Körperschaften den Code 69, und ob das je geändert wird, weiß ich wirklich nicht … Ich würde es deshalb bei 69 belassen. Was genau soll denn erreicht werden? Für die Zwecke der Gemeinde-Infobox hatte ich mal Vorlage:Infobox Gemeinde in Frankreich/Métropole de Lyon erstellt, vielleicht hilft das ja weiter? Gruß --Entlinkt (Diskussion) 22:17, 7. Jan. 2016 (CET)
Äh, Moment, ich glaube, ich habe die Frage missverstanden. Du möchtest, dass man „69D“ bzw. „69M“ eingeben kann und dann „69“ ausgegeben wird? Das sollte kein großes Problem sein, ich schaue mal. --Entlinkt (Diskussion) 22:22, 7. Jan. 2016 (CET)

Frohes Neues

Schön, dich mal wieder zu sehen.

Hilfe:Tabellen/prettytable kommt langsam voran.

LG --PerfektesChaos 18:40, 16. Jan. 2016 (CET)

Nur Mut!

Warum glaubst du, das deine Angaben eh' nichts bringen? Ich finde es im Gegenteil gut, wenn du sowas schreibst. ÅñŧóñŜûŝî (Ð) 20:21, 16. Jan. 2016 (CET)

protokollrelativ

Erst mal ein riesengroßes Dankeschön für all die Arbeit, die du in die projektweiten CSS- und JS-Seiten steckst!

Bei dieser Änderung hast du gleichzeitig die URL auf protokollrelativ umgestellt. Gibt es dafür einen wirklichen Grund? Wikipedia ist ja ohnehin nur noch über https erreichbar, sodass hier ein https:// oder // keinen Unterschied macht. Wenn man das Gadget dagegen in einem http-Wiki (z. B. http://de.wikipedia.beta.wmflabs.org) nutzt, wird die http-Anfrage an en.wikipedia entweder lokal (vermutlich dank HSTS) oder serverseitig auf https umgeschrieben; wenn der zweite Fall eintritt (gut, sollte nur bei alten Browsern passieren), dann gibt es eine unnötige Anfrage. Daher finde ich ein explizites https-Protokoll inzwischen sinnvoller als protokollrelative URLs, außer du hast einen guten Grund dafür, den ich gerade übersehe. --Schnark 10:40, 29. Mär. 2016 (CEST)

Nein, ehrlich gesagt hatte ich keinen guten Grund für die Protokolländerung außer Konsistenz mit den anderen Links, die darüber wie auch darunter stehen (deshalb auch die Änderung der Parameterreihenfolge … ich ging davon aus, dass die geänderte Zeile nur „versehentlich“ anders aussieht als der Rest, weil der Rest konsistent ist). Soll ich es ändern? Nur für den einen Link oder für andere auch? Gruß --Entlinkt (Diskussion) 14:20, 29. Mär. 2016 (CEST)
Dem Dank schließe ich mich ausdrücklich an.
Die Link-Änderung hat keine Eile; nachdem wir vor fünf Jahren angefangen hatten, den Bestand von http auf protokollrelativ umzustellen, driften wir jetzt so nach und nach auf https mit allem, was innerhalb der WMF verlinkt wird (außer Dumps und BETA). Im Wikitext greift in der Regel sowieso vorher unser JS, und halbwegs moderne Browsr schreiben selbsttätig wie von Schnark dargestellt die Anfragen um.
LG --PerfektesChaos 15:09, 29. Mär. 2016 (CEST)
Vielen Dank für die Hinweise, dann lasse ich es jetzt erst mal so, wenn es OK ist? Die Änderung hat den Vorteil, dass der nächste Bearbeiter sich nicht wundert, warum die Links verschieden sind. (Aber den Nachteil, dass dem nächsten Bearbeiter nicht auffällt, dass er vielleicht etwas tun sollte …) Gruß --Entlinkt (Diskussion) 15:26, 29. Mär. 2016 (CEST)
Das Gadget ist ja ohnehin suboptimal, um es vorsichtig auszudrücken. Aber es scheint sich ja keiner der Verwender daran zu stören, dass der Code
jQuery.getScript( "//de.wikipedia.org/w/index.php?title=Special:MyPage/toolserverhelferleinconfig.js&action=raw&ctype=text/javascript" )
	.done(function( script, textStatus ) {
	    executePersonalPreferences();
  	})
  	.fail(function( jqxhr, settings, exception ) {
		mw.util.addPortletLink('p-cactions', aboutUrl + aboutask + '") ) window.open("//de.wikipedia.org/wiki/MediaWiki:Gadget-toolserver-integration/Konfiguration", "_self")', tab_about, 'ca-about', tab_about_tooltip);
	});
erst eine uncachebare Anfrage startet und dann meistens den done-Zweig aufruft (auch wenn das geladene Skript nicht existiert).
Und meine düsteren Prognosen über die zukünftigen Bearbeiter des MW-Namensraums behalte ich besser für mich, die könnten mir sonst als PA gegen eine ganz bestimmte Person ausgelegt werden. --Schnark 10:50, 30. Mär. 2016 (CEST)
Ich bin ja gerade deswegen (natürlich nicht nur deswegen, aber durchaus auch deswegen) dabei, vorher noch ein paar (sowieso längst fällige) Verschönerungsarbeiten zu machen, damit die Hürde zum Neueinbau nicht so schöner Dinge höher ist … --Entlinkt (Diskussion) 10:55, 30. Mär. 2016 (CEST)

MediaWiki:Common.css

Moin irgendetwas stimmt nicht ganz. Das Teil steht in Kategorie:Wikipedia:Defekter Dateilink --2003:4D:2C35:70B1:FDA7:AB30:F8FD:12EA 06:11, 31. Mär. 2016 (CEST)

IMHO ein MediaWiki-Bug, aber vielen Dank für den Hinweis. --Entlinkt (Diskussion) 06:22, 31. Mär. 2016 (CEST)
Üblicherweise ist die Kategorie leer. Kannst Du noch mal schauen oder den Bug melden. --2003:4D:2C35:70B1:FDA7:AB30:F8FD:12EA 06:41, 31. Mär. 2016 (CEST)
Hm? Der Auslöser war ein <gallery>-Tag in einem Kommentar, das habe ich entfernt und jetzt ist die Kategorie wieder leer. Auf eine Bugmeldung habe ich, glaube ich, gerade keine Lust, obwohl es m. E. ein (eher unbedeutender) Bug ist. Gruß --Entlinkt (Diskussion) 07:17, 31. Mär. 2016 (CEST)
Der „Bug“ ist als phab:T34858 bekannt und größtenteils gewollt. Auch wenn CSS/JS-Seiten als Code dargestellt werden, werden sie dennoch als Wikitext geparst. --Schnark 09:14, 31. Mär. 2016 (CEST)
Etwas wacher: OK, per se kein Bug, aber ich denke, irgendwo ist da doch ein Bug, da die Kategorie zwar in der Vorschau an der gewohnten Stelle unten ist, aber nicht nach dem Abspeichern der Seite. (Falls ich es richtig in Erinnerung habe.) Gruß --Entlinkt (Diskussion) 20:00, 31. Mär. 2016 (CEST)

Spezial:Diff/153025082 – Tipp: WP:JS#nowiki analog, schafft Schreibfreiheit.

  • Ein schließendes /* Common.css dewiki </nowiki> */ am Ende jeder einschlägigen Seite macht sich hübsch beim Lesen des aneinandergeklatschten Moduls im debug-Modus.
  • Siehe etwa MediaWiki:Gadget-importUtility.js mit einem im Prinzip wirksamen Wikilink oberhalb und verdächtiger „Vorlagensyntax“ und Wikilinks innerhalb des unwirksam gemachten Bereichs. Wäre anfangs nicht ein projektunabhängiges Interwiki genutzt worden, würde der JS-Code sogar in der Linkliste der Doku erscheinen.

LG --PerfektesChaos 10:16, 31. Mär. 2016 (CEST)

OK, schaue ich mir demnächst mal näher an, momentan sind aber ziemlich viele Baustellen offen … Gruß --Entlinkt (Diskussion) 20:00, 31. Mär. 2016 (CEST)
Eilt ja nicht.
LG --PerfektesChaos 21:04, 31. Mär. 2016 (CEST)
In den CSS-Dateien ist das, soweit es um Links geht, beabsichtigt, ich nutze die Funktion auch und setze absichtlich Links, hatte aber den Zusammenhang zur Kategorisierung nicht gesehen. Gruß --Entlinkt (Diskussion) 22:36, 31. Mär. 2016 (CEST)

T132130

Zur Information: Ich habe T132130 angelegt, damit die Beobachter bei einer Vereinigung der Versionsgeschichte mit übertragen werden. --Fomafix (Diskussion) 07:59, 8. Apr. 2016 (CEST)

OK, vielen Dank für den Hinweis. Ich hatte irgendwelche Nachteile der Spezialseite im Hinterkopf, wusste aber nicht mehr welche und war davon ausgegangen, dass sie behoben sind. Für die jetzt betroffene Seite könnte ich das nur noch durch doppeltes Verschieben beheben, ich weiß nicht, ob das nicht noch mehr Verwirrung gibt … Die alte Seite hatte 8 Beobachter.
Wahrscheinlich wäre es auch gut, das Problem in Hilfe:Seiten vereinen zu dokumentieren (evtl. sogar in MediaWiki:Mergehistory-header). --Entlinkt (Diskussion) 08:09, 8. Apr. 2016 (CEST)
So, einige dieser Dinge erledigt. --Entlinkt (Diskussion) 08:42, 8. Apr. 2016 (CEST)

Vorlagenanpassung für ehemalige Gemeinden, Kantone usw in Frankreich

Hallo Entlinkt, danke für Dein Aufräumen im source code der Infoboxen frz. Gemeinden/Orte! Bei dieser Gelegenheit würde ich gerne Deine Aufmerksamkeit auch auf die Problematik der abgeschafften Verwaltungseinheiten/Gemeinden lenken, und zwar in zwei Bereichen.

1) Die aktuellen Reformen in F lassen die Zahl unserer Artikel zu aufgelösten Einheiten heftig steigen. Normalerweise spricht nichts dagegen, auch die historischen, immer noch zutreffenden Informationen mittels einer Infobox weiterzuführen. Dazu sind dann allerdings ein paar technische Probleme zu lösen, vor allem müssen der automatische Zugriff auf Vorlage:EWZ abgestellt werden und Informationen zu Auflösung/Zeitraum hinzukommen. Bei den von Dir in den letzten Jahren gepflegten Vorlagen Infobox frz. Kanton und Vorlage:Tableau GroupeComm habe ich das gelöst, indem dieselbe Infobox-Vorlage weiterbenutzt wird, aber ein neuer Parameter |disparition= intern das Verhalten steuert, ob eine aktuelle oder ehemalige Einheit beschrieben wird. Mein Gedanke dabei war: nicht besonders sauber, vermeidet aber code-duplikation und später Auseinanderdriften der Parameter. Bei den Gemeinden übernimmt das dagegen Vorlage:Infobox Ortsteil einer Gemeinde in Frankreich, die schon seit längerem existiert. Bei den Arrondissements gibt es diese Erweiterung noch nicht, wäre jedoch für die fusionierten Arrondissements in Elsaß und Lothringen hilfreich.

2) Immer mehr übergeordnete Verwaltungseinheiten (VE) benutzen die Vorlage:Verwaltungstabelle FR Inhalt (ganz unschuldig an deren Verbreitung bin ich nicht), und das führt dann zu Problemen, wenn eine aufgelöste VE Gemeinden enthält, die zu einem späteren Zeitpunkt ihrerseits aufgelöst werden. Also im Moment hauptsächlich ehemalige CCs oder Kantone von ≤2015, deren Gemeinden 2016/17 wegfusionieren. Hier soll die historische Situation beschrieben werden und wir können nicht einfach die Tabelle in der alten VE aufdatieren, so als hätte sie damals schon zukünftige communes-nouvelles enthalten. Beim alten Kanton der mit COG-2016 fusionierten Saint-Offenges die Tabelle händisch zu reparieren ergibt grauenhaften wikitext und macht das ganze Vorlagenkonzept kaputt. Eine Vorlagenvariante ohne EWZ-Zugriff oder Parameter-Erweiterung für ehemalige Gemeinden würde das besser lösen.

In beiden Fragen würde ich mich freuen, Deine Meinung zu hören, Deine tatkräftige Unterstützung ist natürlich noch mehr willkommen! Grüße --WolfgangLiebig • Disk. 13:29, 12. Apr. 2016 (CEST)

Hallo Wolfgang,
erstmal vorab: Ich hatte früher ziemlich viel Zeit für diverse Dinge in der Wikipedia, allzu viel Zeit habe ich aber mittlerweile nicht mehr, deshalb räume ich momentan die schlimmsten irgendwann von mir aufgemachten Baustellen auf und dokumentiere an diversen Stellen den Ist-Zustand, damit andere leichter die Pflege übernehmen können. Ich dokumentiere bewusst auch Dinge, die meiner Meinung nach nicht gut gelöst sind, damit andere nicht meinen, sie müssten schlechte Lösungen weiterführen.
Zu 1): Zu diesem Thema schwebt mir schon seit Ewigkeiten vor, dass man eine „Master-Infobox“ haben sollte, die die Parameter aller gegenwärtigen und ehemaligen Verwaltungseinheiten unterstützt, und dass die anderen Infoboxen in reine Wrapper-Vorlagen umgewandelt werden, die nur die Master-Vorlage aufrufen (ggf. mit Einschränkungen der Parameterauswahl, sinnvoll vorbelegten Parametern etc.). Vorbild könnte Vorlage:Infobox Verwaltungseinheit in Deutschland oder fr:Modèle:Infobox Subdivision administrative sein (jeweils für die technische Realisierung, nicht für die Optik). Um das zu realisieren, wäre es wahrscheinlich sinnvoll, in einem ersten Schritt die Optik aller vorhandenen Infoboxen anzugleichen (wurde teilweise realisiert, ist aber teilweise über die Jahre auch wieder auseinandergeraten).
Zu 2): Zu dieser Vorlage habe ich keine Idee für eine gute Lösung und muss ganz ehrlich sagen, dass ich damals auch ziemlich deutlich gegen ihre Einführung war, weil ich die Probleme teilweise bereits geahnt habe.
Ansonsten allgemein: Die Infobox-Vorlagen sind aufgrund der französischen Parameternamen nicht besonders benutzerfreundlich, was immer wieder thematisiert wird. Die Intention des ursprünglichen Autors war, dass man die Boxen direkt aus der französischen Wikipedia kopieren kann. Ich habe an dieser Intention lange festgehalten. Das hat auch viele Jahre geklappt, klappt aber mittlerweile nicht mehr, weil in der französischen Wikipedia fast alle Vorlagen grundlegend geändert wurden und wir die Änderungen nicht nachvollzogen haben. Meiner Meinung nach spräche nichts mehr dagegen, bei Neuentwicklungen deutsche Parameternamen zu verwenden, weil das Rüberkopieren aus frwiki sowieso schon seit Jahren nicht mehr funktioniert.
Viele Grüße --Entlinkt (Diskussion) 15:54, 12. Apr. 2016 (CEST)

Kantone von Mayotte

Hallo Kollege, ich hab jetzt mail im Kanton Mamoudzou-1 die Lagekarte aus dem entsprechenden fr-Artikel übernommen, sowie auch die dortige Flächenangabe. Weißt du oder kannst du erkennen, woher die fr-WP die Flächenangaben der Kantone hat? Ich habe keine Quellenangabe gesehen. Ist es in Ordnung, auch bei den übrigen Kantonen die Flächen aus fr-WP zu übernehmen, wenn sie nach dem Kartenbild plausibel scheinen, aber nicht bequellt sind? Ich meine, die WP soll ja nicht ihre eigene Quelle sein, aber man muss auch nicht päpstlicher sein als der Papst. Dazu wollte ich nur mal deine Meinung einholen, bevor ich hier weitermache, da du schon sehr viel Arbeit mit fr-bezogenen Artikeln geleistet hast. Gruß,--Ratzer (Diskussion) 09:14, 14. Apr. 2016 (CEST)

Hallo Ratzer, ich habe die Angaben in der französischen Wikipedia auch gesehen, aber aus genau diesem Grund (nicht ersichtliche Quellenangaben) bewusst nicht übernommen. Als Quellenangabe für Flächen kenne ich nur das Répertoire géographique des communes. Weil dort nur Gemeinden enthalten sind, kann man daraus natürlich nur Angaben für Kantone erhalten, die sich aus ganzen Gemeinden zusammensetzen.
Allzu stark ist meine Meinung zu dem Thema aber nicht. Ich habe auch nicht vor, die Kantonsartikel weiter zu beobachten oder auszubauen, sondern sie jetzt nur aktualisiert, weil sie veraltet waren. Meine ganz persönliche Meinung ist sogar, dass es die Kantonsartikel eigentlich nicht bräuchte, aber sie erfüllen ja bestimmt irgendein pauschales Relevanzkriterium … Gruß --Entlinkt (Diskussion) 12:41, 14. Apr. 2016 (CEST)
Jetzt habe ich auf der fr-WP mal nachgehakt, und vom Benutzer Pymouss die Quelle erfahren. Auf dieser Seite kann man rechts nacheinander die einzelnen Kantone anklicken und bekommt jeweils die Fläche angezeigt. Werde ich gelegentlich als Beleg einbauen. Kannst mir aber gern zuvorkommen, ich bin recht langsam ;-)--Ratzer (Diskussion) 08:18, 15. Apr. 2016 (CEST)
Wie gesagt: Ich halte es für ziemlich lächerlich, dass es überhaupt einen Artikel zu jedem einzelnen Kanton gibt. (Um das nachzuvollziehen, kann es hilfreich sein zu wissen, was ein Kanton tatsächlich ist; in der deutschsprachigen Wikipedia steht zum dem Thema leider ziemlich viel Falsches, was sich nicht zu korrigieren lohnt, weil dauernd jemand wieder auf das Falsche zurückändert und man dann allen Ernstes über die Richtigkeit von Falschem diskutieren müsste; halbwegs brauchbar ist fr:Canton français).
Man könnte wunderbar alle Kantone eines Departements innerhalb eines Listenartikels in Tabellenform darstellen, dann bräuchte man dort auch nur eine Karte und müsste nicht jeden einzelnen Artikel in einer Art und Weise damit vollstopfen, die den „Artikel“ überfrachtet (= Dauerzustand, da es zu einem Kanton nun mal inhärent sehr wenig zu sagen gibt).
Dasselbe gilt übrigens auch für die Karten in Gemeindeartikeln, an sich ist die gefundene Lösung nämlich natürlich absichtlich einheitlich für alle ca. 36.000 Gemeinden Frankreichs, aber es ist klar, dass die Sonderwege irgendwann wiederkommen. Das sollen aber gern die entscheiden, die in dem Bereich tatsächlich aktiv sind, also nicht mehr ich – ich bin in dem Bereich „eigentlich“ schon lange nicht mehr aktiv, weiß auch sehr genau warum und führe nur noch einige wenige Dinge zuende, die ich blöderweise irgendwann einmal angefangen habe.
Da ich die Kantonsartikel von Mayotte mit meinem jeweils letzten Edit in einen korrekten und konsistenten Zustand gebracht habe, ist das Thema damit für mich erledigt – was in weiteren Edits damit passiert, ist nicht mehr mein Ding, und ich habe sie auch nicht auf der Beobachtungsliste. Gruß --Entlinkt (Diskussion) 13:52, 15. Apr. 2016 (CEST)

CSS-Frage

Moin, du bist doch CSS-Experte, sag mal, wenn ich die mw:Template:Extension in ein eigenes Wiki exportiere, wie bekomme ich dann die CSS Klasse rüber? Weil wenn ich die nur so exportiere und dann importiere hat die Vorlage keinen Rand. Viele Grüße, Luke081515 20:10, 15. Apr. 2016 (CEST)

Ich glaube, dafür braucht man (mindestens) die Defintion der Klasse tpl-infobox aus mw:MediaWiki:Gadget-site.css. Gruß --Entlinkt (Diskussion) 20:13, 15. Apr. 2016 (CEST)
Super, das hat das Problem gelöst. Ich hatte ursprünglich in Common.css gesucht, aber die ist in mw.org leer, und auch die einzelnen Skin Css haben nicht dieselbe Definition. Vielen Dank und viele Grüße, Luke081515 20:23, 15. Apr. 2016 (CEST)
Ja, an sich sind Dateien wie Common.css nur noch Legacy-Kram und wären durch (Default-)Gadgets zu ersetzen (oder zumindest war dies für eine Zeit so gedacht; ich weiß nicht, wie der aktuelle Stand ist). Deshalb ist mediawiki.org da mit gutem Beispiel vorangegangen. Bei uns und auch in den meisten anderen Wikipedien wurde aber noch nichts in diesem Sinne umstrukturiert. Gruß --Entlinkt (Diskussion) 20:27, 15. Apr. 2016 (CEST)

Mail

Hi - ist die jetzt durchgekommen? --KarlV 09:58, 20. Apr. 2016 (CEST)

Ja. Anscheinend betraf das Problem der Mailfunktion alle Benutzer, aber es wurde alles nachträglich zugestellt. Gruß --Entlinkt (Diskussion) 10:49, 20. Apr. 2016 (CEST)

Spezial:Diff/153781165

Hallo Entlinkt. Zur Kenntnis: Dein Anpingen funktionierte da nicht. --Leyo 10:08, 26. Apr. 2016 (CEST)

Ist doch wunderbar, wenn sich nicht funktionierendes CSS und nicht funktionierende Pings zueinander gesellen. --Entlinkt (Diskussion) 19:41, 26. Apr. 2016 (CEST)

Wenn du grad Zeit hättest …

… und weil du mir just über die Beo flimmerst: HD:EN #Layout der Fußnotenreferenz bei gruppierten Einzelnachweisen. könnte deiner bedürfen.

Schönen Sonntag --PerfektesChaos 11:25, 6. Mär. 2016 (CET)

Ich hab's bemerkt und mir gerade gestern angeschaut. Die Änderung sieht OK aus und ist zum Beispiel in en:MediaWiki:Common.css vorhanden (ziemlich weit unten), ist aber meiner Meinung nach eine der Änderungen, die in MediaWiki selbst gemacht werden sollten. Das Problem besteht ja nicht nur bei uns. --Entlinkt (Diskussion) 11:28, 6. Mär. 2016 (CET)
Tjoh; leidenschaftslos. Man kann ja parallel arbeiten, als Sofortmaßnahme mit Hinweis auf Überprüfung Ende 2016 erstmal lokal einbauen, und gleichzeitig phab lostreten mit Empfehlung zum globalen Einbau, und die Tasknummer in unsere CSS schreiben. Willst du Butter von den Behörden, schicke frische Milch auf den Dienstweg. LG --PerfektesChaos 11:38, 6. Mär. 2016 (CET)
@PerfektesChaos: Ich sehe gerade, dass wenige Tage nach dieser Anfrage die zur gewünschten Regel 
sup.reference a {
	white-space: nowrap;
}
durch Vererbung äquivalente Regel 
sup.reference {
	white-space: nowrap;
}
mit gerrit:278436 in MediaWiki aufgenommen wurde. So wünscht man sich das doch, oder?
Von mir aus bitte immer am liebsten gleich auf die Aufnahme in MediaWiki hinwirken. Viele Grüße --Entlinkt (Diskussion) 20:20, 10. Mai 2016 (CEST)

Geschäftsführersuche der Wikimedia Foundation 2016 Community-Umfrage

Der Stiftungsrat der Wikimedia Foundation hat einen Lenkungskreis gebildet, der für die Suche nach dem/der neuen Geschäftsführer/in zuständig ist. Eine unserer ersten Aufgaben ist eine Tätigkeitsbeschreibung für die Position der Geschäftsführung zu verfassen und wir bitten die Wikimedia-Community um Unterstützung. Bitte nehmt euch einige Minuten Zeit, diesen Fragebogen auszufüllen, damit wir uns ein besseres Bild über die Erwartungen der Community-Mitglieder und Mitarbeiter an den/die Geschäftsführer/in der Wikimedia Foundation machen können.

Vielen Dank, Der Lenkungskreis zur Geschäftsführersuche der Wikimedia Foundation via MediaWiki message delivery (Diskussion) 23:56, 1. Jun. 2016 (CEST)

Das Verhalten von Vorlagen bei unterschiedlichen Medien und Programmen

Hallo. Kennst du eine Methode, mit der man das Verhalten einer Vorlage davon abhängig machen kann, ob eine Seite im Browser (also auf dem Screen) gezeigt wird oder ob sie gerade von der Buchfunktion "verarbeitet" wird, bzw. als PDF exportiert wird? Konktret geht es darum, die Vorlage:Panorama so zu gestalten, dass sie außerhalb der Bildschirmdarstellung keine interaktiven Elemente wie Skrollbalken etc. einzufügen versucht, den Platz aber auch füllt, um das Layout nicht zu zerschießen. Wie deaktiviere ich hier in der WP CSS-Attribute je nach Medium und Verwendung? Gruß von ÅñŧóñŜûŝî (Ð) 21:10, 5. Jun. 2016 (CEST)

Hallo Antonsusi,
meines Wissens gibt es keine solche Möglichkeit.
Prinzipiell kann man in CSS Media Queries einsetzen, um geräteabhängige Stilvorgaben zu realisieren. Das geht aber sowieso nur mit externem CSS (also in separaten .css-Dateien oder <style>-Elementen) und nicht mit eingebetteten style-Attributen, und das wird sich auch nicht ändern, da eingebettete style-Attribute als veraltetes Konzept gelten.
Davon abgesehen funktionieren Media Queries aber sowieso nur in einem vollwertigen CSS-konformen Webbrowser. Das ist die Buchfunktion nicht. Allzu gut kenne ich mich mit der Buchfunktion zwar nicht aus, aber meines Wissens ignoriert sie das meiste CSS. Konkret bei der Vorlage:Panorama sehe ich in PDF-Dateien, die mit der Buchfunktion erstellt wurden, auch keine Scrollbalken, wie sie in Anbetracht des style="overflow:auto" zu erwarten wären, sondern abgeschnittene Bilder, was klar darauf hindeutet, dass das style="overflow:auto" ignoriert wird.
Ein „Allheilmittel“ gibt es aber für solch „hoffnungslose Fälle“, und zwar class="noprint". Damit wird die Vorlage in der Buchfunktion ausgeblendet, aber auch beim normalen Ausdrucken mit dem Browser.
--Entlinkt (Diskussion) 22:45, 5. Jun. 2016 (CEST)
Ein Gegenstück zu class="noprint", also eine Klasse, welche ein Objekt nur beim Drucken sichtbar werden lässt, gibt es wohl nicht? Damit könnte man ein passendes Ersatzbild einfügen... ÅñŧóñŜûŝî (Ð) 23:33, 5. Jun. 2016 (CEST)
Meines Wissens gibt es eine solche Klasse nicht. Meiner Meinung nach ist das auch ganz gut so, weil die Existenz einer solchen Klasse dazu verleiten würde, Konstrukte doppelt in das Markup einzufügen (einmal in einer Nicht-Druck-Variante und einmal in einer Druckvariante). Das wiederum würde dazu führen, dass sie in Anwendungen, die CSS ignorieren (z. B. Suchmaschinen), doppelt angezeigt werden. Dagegen andiskutieren könnte man nach Einführung einer solchen Klasse nicht mehr, da zu erwarten wäre, dass Wikipedianer die Ursache nicht verstehen und sie auf die Suchmaschine schieben. Deshalb sollte keine solche Klasse eingeführt werden, weder global noch lokal. Lokal können wir das auch gar nicht machen, weil die Buchfunktion die Datei MediaWiki:Print.css ignoriert.
Die korrekte Lösung wäre es, dass Media Queries in der Vorlagenprogrammierung verfügbar werden. Dafür gibt es den Phabricator-Eintrag phab:T117950, der auf den allgemeineren Eintrag phab:T483 verweist. Die entsprechende Softwareerweiterung befindet sich derzeit im Sicherheitsreview, siehe phab:T133408. Gruß --Entlinkt (Diskussion) 00:56, 6. Jun. 2016 (CEST)
Was es nicht alles an Nebenwirkungen gibt... Gilt das auch für per Lua erstelltes Markup / HTML ? ÅñŧóñŜûŝî (Ð) 21:35, 7. Jun. 2016 (CEST)
Ich verstehe die Frage nicht ganz. Welche Nebenwirkungen meinst du, und was für Markup möchtest du in Lua erstellen?
Zum zweiten Punkt rate ich einfach mal: Media Queries funktionieren nicht in eingebetteten style-Attributen. Sie funktionieren aber in <style>-Elementen, die der Parser bzw. Sanitizer jedoch nicht durchlässt. Beleg:
<style>@media all { * { display: none; } }</style>
Nun beabsichtigst du, diese Einschränkung zu umgehen, indem du das Markup mit Lua erstellst.
Ausprobiert habe ich es zwar nicht, aber es würde mich sehr wundern, wenn das funktionieren würde, da der Parser bzw. Sanitizer das <style>-Element aus Sicherheitsgründen nicht durchlässt. Wenn das „funktionieren“ würde, wäre es umgehend als Sicherheitsleck zu melden.
Warum ist das sicherheitsrelevant? Bestimmt würdest du nicht wollen, dass dir jemand mit Code wie oben das gesamte Dokument unsichtbar machen kann. Vor allem aber kann man mit geeigneten CSS-Formatierungen auch Elemente der Benutzeroberfläche manipulieren, um Benutzer zu täuschen und sie zu Handlungen zu bringen, die diese eigentlich nicht wollen. Deshalb wird ja gerade an einer Softwareerweiterung gearbeitet, die nur sicheres CSS durchlässt, und aus ebendiesem Grund befindet sich diese gerade im Sicherheitsreview.
Gruß --Entlinkt (Diskussion) 22:25, 7. Jun. 2016 (CEST)
PS: Ich bin nicht sicher, ob du verstanden hast, warum Media Queries in eingebetteten style-Attributen nicht funktionieren. Das hat überhaupt nichts mit MediaWiki zu tun, sondern wird ganz einfach von keinem Browser unterstützt. Noch schlimmer: Es gibt schlicht und einfach keine Spezifikation, die auch nur die Syntax dafür definiert. Gruß --Entlinkt (Diskussion) 22:31, 7. Jun. 2016 (CEST)
Guten Morgen; mitlesende Info @Lua:
Es ist völlig egal, auf welche Weise der expandierte Wikitext zustande kommt, der dann schließlich vom Wiki-Parser verarbeitet wird – ob direkt in die gespeicherte Seite geschrieben, oder von einer klassischen Vorlage generiert, die in einer Vorstufe oder ersten Phase des Parsens expandiert wird, oder die Zeichenkette, die aus der Expansion einer Lua-Funktion resultiert. Nach Expansion aller Vorlagen und Lua ergibt sich in der ersten Phase ein einziges XML-Markup mit Apostrophen und eckigen Klammern. Wo das mal herkam, ist einerlei.
VG --PerfektesChaos 00:12, 8. Jun. 2016 (CEST)
Mit Nebenwirkungen meinte ich das mit "Suchmaschienen etc."
@Entlinkt: Ich habe dich sehr wohl verstanden. Du wolltest ausdrücken, dass man im HTML-Kopf mit media="screen" oder media="print" je nach Medientyp verschiedene Stylesheets einbinden kann, dass man in der CSS-Datei oder im HTML-Kopf mit @media print { } oder @media screen { } diese Angaben für verschiedene Medientypen machen kann und dass man sowas aber nicht als Attribut angeben kann, also sowas wie <div style="@media print { }"> nicht funktioniert, weil das im Standard vom W3C nicht festgelegt ist. ÅñŧóñŜûŝî (Ð) 01:12, 8. Jun. 2016 (CEST)
Ja, in den Grundzügen stimmt das so.
Erheblich erschwert wird das Ganze aber dadurch, dass die Buchfunktion kein Browser ist und sowieso nur wenig CSS unterstützt. Durch Testen habe ich irgendwann mal herausgefunden, dass sie ein style="display:none" im Wikitext beachtet, aber beispielsweise MediaWiki:Print.css ignoriert.
Um das Ganze also mal zusammenzufassen:
  • Es gibt meines Wissens derzeit keine einzige Möglichkeit für Vorlagenprogrammierer, die Buchfunktion und nur diese anzusprechen. Inline-CSS funktioniert teilweise, gilt dann aber für alle Ausgabemedien.
  • Es gibt die Möglichkeit class="noprint", diese wirkt aber nicht nur auf die Buchfunktion, sondern auch auf das normale Ausdrucken im Browser.
  • Es gibt meines Wissens derzeit keine einzige Möglichkeit für Admins, CSS-Definitionen für die Buchfunktion festzulegen. Die Buchfunktion scheint sämtliches CSS im MediaWiki-Namensraum zu ignorieren.
  • Es wird daran gearbeitet, Media Queries für Vorlagenprogrammierer verfügbar zu machen, und diese werden dann auch beim normalen Ausdrucken im Browser funktionieren. Ob sie auch in der Buchfunktion funktionieren werden, ist fraglich, die Einführung ist aber immerhin ein Schritt in die richtige Richtung.
Gruß --Entlinkt (Diskussion) 01:40, 8. Jun. 2016 (CEST)
Tja, im Leben ist die Auswahl immer begrenzt... Danke für die konstruktive Hilfe! ÅñŧóñŜûŝî (Ð) 21:33, 9. Jun. 2016 (CEST)

Vorlage:Unicode

Hallo Entlinkt!

Die von dir überarbeitete Seite Vorlage:Unicode wurde zum Löschen vorgeschlagen. Gemäß den Löschregeln wird über die Löschung nun bis zu sieben Tage diskutiert und danach entschieden.

Du bist herzlich eingeladen, dich an der Löschdiskussion zu beteiligen. Wenn du möchtest, dass der Artikel behalten wird, kannst du dort die Argumente, die für eine Löschung sprechen, entkräften, indem du dich beispielsweise zur enzyklopädischen Relevanz des Artikels äußerst. Du kannst auch während der Löschdiskussion Artikelverbesserungen vornehmen, die die Relevanz besser erkennen lassen und die Mindestqualität sichern.

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 der Antragsteller die Arbeit, die du in den Artikel gesteckt hast, nicht würdigt. Sei tapfer und bleibe dennoch freundlich. Der andere meint es vermutlich auch gut.

Grüße, Xqbot (Diskussion) 19:47, 15. Jul. 2016 (CEST)   (Diese Nachricht wurde automatisch durch einen Bot erstellt. Wenn du zukünftig von diesem Bot nicht mehr über Löschanträge informiert werden möchtest, trag dich hier ein.)

Abgerufen von „https://de.wikiup.org/index.php?title=Benutzer_Diskussion:Entlinkt/Archiv/2016&oldid=161563055“