Wikipedia:WikiProjekt Vorlagen/Werkstatt/Archiv 2016/2

Diese Seite bietet eine Übersicht der archivierten Diskussionen der Vorlagenwerkstatt. Die Abschnitte der einzelnen Archive sollten nicht mehr verändert werden.

• Archiv: 2006 und 2007
• Archiv: 2008/1, 2008/2, 2008/3, 2008/4
• Archiv: 2009/1, 2009/2, 2009/3, 2009/4
• Archiv: 2010/1, 2010/2, 2010/3, 2010/4
• Archiv: 2011/1, 2011/2, 2011/3, 2011/4
• Archiv: 2012/1, 2012/2, 2012/3, 2012/4
• Archiv: 2013/1, 2013/2, 2013/3, 2013/4
• Archiv: 2014/1, 2014/2, 2014/3, 2014/4
• Archiv: 2015/1, 2015/2, 2015/3, 2015/4
• Archiv: 2016/1, 2016/2, 2016/3, 2016/4
• Archiv: 2017/1, 2017/2, 2017/3, 2017/4
• Archiv: 2018/1, 2018/2, 2018/3, 2018/4
• Archiv: 2019/1, 2019/2, 2019/3, 2019/4
• Archiv: 2020/1, 2020/2, 2020/3, 2020/4
• Archiv: 2021/1, 2021/2, 2021/3, 2021/4
• Archiv: 2022/1, 2022/2, 2022/3, 2022/4
• Archiv: 2023/1, 2023/2, 2023/3, 2023/4
• Archiv: 2024/1, 2024/2, 2024/3, 2024/4

Tabellensortierung

Gestern habe ich Liste der Länder nach Kaufkraftparität 2000–2009 und Liste der Länder nach Kaufkraftparität 1990–1999 eingestellt, die Tabelle ist direkt einer Excel-Datei der Weltbank entnommen. Nun war/ist die nach den ISO 3166-Kürzeln sortiert, aus der hier die Flaggenvorlagen hervorgehen. Dadurch ist die Tabelle nach Ländernamen sortiert in der Grundeinstellung. Kann man das umstellen?--Antemister (Diskussion) 18:51, 5. Apr. 2016 (CEST)

Nur indem man die Reihenfolge im Quelltext ändert. Wenn du nach Kaufkraftparität 2009 sortieren willst, machst du das am besten in Excel und exportierst die Tabelle dann neu. --mfb (Diskussion) 19:50, 5. Apr. 2016 (CEST)

Lästig, aber wenns nicht anders geht...--Antemister (Diskussion) 21:48, 6. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Antemister (Diskussion) 21:48, 6. Apr. 2016 (CEST)

ISMN-Darstellung

Hallo, eine Frage bitte zur optimalen Darstellung der ISMN. Hier hatte ich vorgefunden: ISMN 979-0-50248-065-3, und analog zur ISSN geändert auf: ISMN 979-0-50248-065-3 (Suche im DNB-Portal). Dann muss aber auf dnb.de weitergeklickt werden. Der Datensatz wird also nicht wie bei der ISBN sofort angezeigt. Wie geht's? --Wi-luc-ky (Diskussion) 00:34, 8. Apr. 2016 (CEST)

Habe die URL in der Vorlage angepasst: [1]. Sollte jetzt gehen. --тнояsтеn ⇔ 08:11, 8. Apr. 2016 (CEST)

Vielen Dank, тнояsтеn, genauso wie gewünscht. Dass die Links auf die Bände 2–4 keine Ergebnisse zeitigen, liegt daran, dass diese Bände zwar schon eine ISMN haben, jedoch lt. Verlag noch nicht gedruckt vorliegen und bei der DNB noch gar nicht aufgenommen worden sein können (ISMN-Reservierung also). --Wi-luc-ky (Diskussion) 14:33, 8. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 14:33, 8. Apr. 2016 (CEST)

Vorlage:Mehrere Bilder

Ist es irgendwie möglich, nur einen Teil der Kopfzeile in fett zu schreiben? --Chris XC3000 (Diskussion) 21:05, 9. Apr. 2016 (CEST)

Hallo Chris XC3000, so kannst du die Fettformatierung für einen Teil der Kopfzeile aussetzen:

Strecke Paris–Roubaix 2016 (Pavé-Sektoren sind grün markiert)

Erster Teilabschnitt

Zweiter Teilabschnitt

Dritter Teilabschnitt

Vierter Teilabschnitt

--Wiegels „…“ 21:23, 9. Apr. 2016 (CEST)

Genau das wollte ich machen :)

Danke für die schnelle Antwort.

Archivierung dieses Abschnittes wurde gewünscht von: Chris XC3000 (Diskussion) 21:30, 9. Apr. 2016 (CEST)

Richtige Vorlage für geographische Positionsbestimmung?

Ich habe unter dem Lemma Point Rosee (ja, da soll noch etwas passieren) die Vorlage:Infobox Ort in Kanada verwendet, weil ich erst mal nichts anderes gefunden habe - kenne mich auch nicht so aus. Allerdings geht es lediglich darum, dem Artikel eine (geo-)graphische Positionsangabe beizufügen. Um einen Ort im Sinne einer Kommune - wie für die Vorlage vorgesehen(und von dieser als Kat mit eingefügt) - handelt es nicht.

Gibt es vielleicht noch eine andere Lösung? Danke.--Zuviele Interessen (Diskussion) 20:08, 9. Apr. 2016 (CEST)

PS: Vielleicht sehe ich es auch nur zu eng und meine Frage erübrigt sich..?--Zuviele Interessen (Diskussion) 20:15, 9. Apr. 2016 (CEST)

ich habe dir eine koordinatenbasierte Karte eingebaut. Die von dir verwendete Infobox ist, da hast du Recht, nicht für diesen Zweck vorgesehen. lg --Herzi Pinki (Diskussion) 00:01, 10. Apr. 2016 (CEST)

Interessant, {{Coordinate|article=/|map=right|maplevel=adm1st}}, Danke. –Be..anyone (talk) 11:51, 10. Apr. 2016 (CEST)

Scheint genau das zu sein, wonach ich gesucht hatte. Vielen Dank.--Zuviele Interessen (Diskussion) 16:39, 10. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Zuviele Interessen (Diskussion) 16:39, 10. Apr. 2016 (CEST)

Untertitel in Vorlage Navileiste nicht sichtbar

Hallo, könnte bitte jemand hier den erläuternden Untertitel sichtbar machen? bzw. eine Anleitung dazu geben? Dank von --Wi-luc-ky (Diskussion) 19:34, 12. Apr. 2016 (CEST)

Der Parameter UNTERTITEL existiert in der Vorlage:Navigationsleiste nicht. Mein Vorschlag: [2]. --тнояsтеn ⇔ 20:12, 12. Apr. 2016 (CEST)

Danke, тнояsтеn und Wiegels, für eure konstruktiven Vorschläge, die ich den überarbeiteten Entwurf übernommen habe. – Nun hatte ich vorher mit der erweiterten Navileiste mit dem Parameter des Untertitels experimentiert, doch müssten dann wohl zwingend Gruppen definiert werden (die hier vorerst verzichtbar scheinen), nicht wahr? So wird es bei der einfachen Navileiste ohne Untertitel bleiben müssen. Schade eigentlich, dass dieser Parameter hier fehlt. – Bei den Kategorien verlasse ich mich gern auf die Arbeit eines Erfahreneren. --Wi-luc-ky (Diskussion) 22:22, 12. Apr. 2016 (CEST)

Hallo Wi-luc-ky, willst du damit sagen, dass du mich für unerfahren im Kategorisieren von Navigationsleisten hältst, oder war die Rücksetzung ein Versehen? --Wiegels „…“ 22:34, 12. Apr. 2016 (CEST)

Lieber Wiegels, Pardon! das Rücksetzen war ein Versehen beim Hin- und Herkopieren; und Du bist der Erfahrenere und warst damit gemeint. Ich hatte den Fehler bereits bemerkt. Inzwischen habe ich Deine zwei Änderungen – hoffentlich richtig – in die Variante 3 aufgenommen und bitte um Deine Meinung, ob letztere Variante an den offiziellen Start gehen sollte. Gruß und Dank von --Wi-luc-ky (Diskussion) 00:23, 13. Apr. 2016 (CEST)

Hallo Wi-luc-ky, mir gefallen beide Varianten. Für Interessenten nur eines Bahntyps scheint mir die Variante 3 die praktischere zu sein. Viele Grüße --Wiegels „…“ 00:47, 13. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wiegels „…“ 09:28, 14. Apr. 2016 (CEST)

Zusammenspiel der Vorlage:Defekter Weblink mit Vorlage:Exzellent usw.

Seit der Umstellung der „Topicon“-Vorlagen auf das <indicator>-Tag (vgl. mw:Help:Page status indicators) tritt folgendes Problem auf: Wenn auf der Diskussionsseite eines exzellenten Artikels die Vorlage:Defekter Weblink eingebunden ist, erscheint dort auch das Exzellent-Icon von der Vorderseite. Das betrifft zum Beispiel den heutigen Artikel des Tages, Diskussion:Paprika.

Gibt es dafür eine einfache/elegante Lösung? (Als Workaround würde es wahrscheinlich funktionieren, das Icon in Vorlage:Exzellent generell für Diskussionsseiten zu unterdrücken, aber ich würde zuerst eine Lösung präferieren, die das übrige Verhalten der Vorlagen nicht ändert.) --Entlinkt (Diskussion) 17:03, 7. Apr. 2016 (CEST)

Da fragst du am besten direkt PerfektesChaos. Das zugehörige Modul bindet zur Analyse Gott und die Welt ein, mit solchen Nebeneffekten (s. auch "Ominöse Backlinks" etwas weiter oben). --mfb (Diskussion) 19:21, 7. Apr. 2016 (CEST)

Das Modul guckt in den Quelltext der Vorderseite und schaut, ob die beanstandeten URL theoretisch vorhanden sein könnten.

• Andernfalls werden komplett redundante Einbindungen in Kategorie:Wikipedia:Defekte Weblinks/Bot/Keine auffindbaren URL zwecks Bot-Eliminierung gesteckt; nur einzelne Fehlanzeigen jeweils markiert, damit die Reparierer vorgewarnt sind und sich nicht dämlich nach nicht mehr vorhandenen URL suchen.

Wenn man den Quelltext einer Seite mit <indicator> auch nur anguckt (eingebunden wird sie sowieso nicht), dann wird der Tag-Inhalt offenbar bereits beiseitegelegt und der Inhalt für die Einbindung außerhalb des content area schon vorgemerkt.

• Genauso wird mit <ref> verfahren.

Ich werde deshalb in den nächsten Tagen nach BETA-Erprobung am Wochenende die drei wesentlichen Vorlagen, die im ANR beteiligt sind, vor dem Parsen aus dem Quelltext eliminieren.

Hoffentlich hat dieser Quatsch auf Diskussionsseiten bald mal ein Ende.

LG --PerfektesChaos 23:22, 7. Apr. 2016 (CEST)

Hm, meine Hoffnung wäre gewesen, dass das ganz einfach geht (durch Umlegen eines mir nicht bekannten zentralen Schalters). Wenn es zu viele Umstände macht, geht auch der Workaround in den Topicon-Vorlagen. Gruß --Entlinkt (Diskussion) 01:40, 14. Apr. 2016 (CEST)

Die wesentlichen ANR-Vorlagen sind jetzt nicht mehr im ausgewerteten Quelltext; siehe Diskussion:Paprika. LG --PerfektesChaos 15:02, 15. Apr. 2016 (CEST)

OK, vielen Dank. Aber ist das Softwareverhalten nicht ein Bug, den man evtl. melden sollte, damit er auch zentral behoben wird? Sonst müsste man die betroffenen Vorlagen auch in Zukunft immer wieder nachziehen. Gruß --Entlinkt (Diskussion) 15:42, 15. Apr. 2016 (CEST)

Naja, ein richtiger Bug ist es nicht; eher ein Nebeneffekt der Möglichkeiten mit Lua.

• Wenn man sich einen Wikitext parsen lässt und der Parser sieht <ref> oder <indicator>, dann legt er deren Inhalt auf den externen Stapel für diese aktuelle Seite, damit die so generierten Bereiche später mit dem Inhaltsbereich zusammengeführt werden können.
• Bei klassischer Vorlagenprogrammierung war die einzige Möglichkeit, so etwas auszulösen, die Einbindung der fremden Seite in die eigene, und damit der Effekt zwangsläufig beabsichtigt und unvermeidlich.

Wenn man es als Bug oder verbessertes Feature sehen möchte, dann müsste man optional die einschlägige Lua-Funktion Hilfe:Lua/Modul im Wiki #frame:preprocess() mit einem zweiten optionalen Parameter ausstatten; true := „Vergiss alle Auswirkungen auf die umgebende Seite, gib mir einfach nur interpretierten Wikitext zurück“, und das in die Abgründe des Parser durchreichen und bei allen Aktivitäten des Parsers und der Extensionen berücksichtigen; dann auch die „Links auf diese Seite“ und scheinbaren Einbindungen ignorieren.

• Relativ großes Rad, viel zu ändern, und für die Performance ist dieser exotische Fall auch nicht förderlich.
• Ich glaube nicht, dass das umgesetzt würde.
• Vielleicht ergibt es sich eines Tages als Nebeneffekt von Parsoid.

Diese Masche mit Defekten Weblinks auf Diskussionsseiten ist sowieso eine obsolete Brückentechnologie und wird hoffentlich mit der nächsten Generation durch eine diskussionsseitenfreie stundenaktuelle Live-Auskunft ersetzt.

LG --PerfektesChaos 16:55, 15. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 23:26, 15. Apr. 2016 (CEST)

Vorlagenelement wird nicht angezeigt

Hallo, im Art. Bad Harzburg wird die einschl. Pferde-Rennbahn in der Navileiste nicht als markiert angezeigt. Was wäre zu tun? --Wi-luc-ky (Diskussion) 14:02, 14. Apr. 2016 (CEST)

Die Relevanz wäre zu klären, beim Link Bad_Harzburg#Sport gibt es keine Pferderennbahn Bad Harzburg, wie auf Vorlage {{Navigationsleiste Pferderennbahnen in Deutschland}} behauptet, und ohne vernünftigen Artikel zur Rennbahn hat das Dings auf der Vorlage nichts zu suchen (WikiSpam). In einem Halbsatz erwähnt wird die Rennbahn im Abschnitt Bad Harzburg#Geschichte, das reicht aber nicht für neugierige Leser, die den Navigations-Link sonstwo anklicken. Mit Hervorhebung meinst Du vielleicht den Effekt, dass jedes [[Wikipedia:WikiProjekt Vorlagen/Werkstatt|Beispiel]] als Beispiel dargestellt wird. Oder ich verstehe Deine Frage flasch. Vorlage:Smiley/Wartung/zunge  –Be..anyone 💩 14:25, 14. Apr. 2016 (CEST)

Du müsstest Bad Harzburg#Sport|Rennbahn Bad Harzburg in Bad Harzburg|Rennbahn Bad Harzburg ändern damit es schwarz und fett wird, aber nur wenn auch etwas dazu im Artikel steht. --Liebe Grüße, Lómelinde Diskussion 14:29, 14. Apr. 2016 (CEST)

Die Navileiste ist in einem Städte-Artikel sowieso fehl am Platze. Sie gehört nur in Rennbahn-Artikel. --тнояsтеn ⇔ 17:58, 14. Apr. 2016 (CEST)

Vielen Dank für eure zahlreichen Anregungen und Hinweise. Genau der Hervorhebungseffekt war gemeint, Be..anyone. Im Absatz Bad Harzburg#Sport wird tatsächlich (nur) der „Harzburger Rennverein e.V. von 1880“ erwähnt, die Rennbahn im gesamten Art. jedoch dreimal. Sicher bliebe ein eigener Art. wie zu anderen Pferderennbahnen auch wünschenswert, Be..anyone (die anderen Art. würde ich gleichwohl nicht als Spam klassifizieren, sondern als solide enzyklopädische Erstinformation). – Technisch verstehe ich deinen Vorschlag, Lómelinde, wohl so richtig, dass hier grundsätzlich nur auf [ [Artikel] ] selbst, nicht aber auf [ [Art.#Artikelabschnitt] ] verlinkt werden kann/darf, wenn der Hervorhebungseffekt eintreten soll. Oder gibt es da doch technisch eine Lösung? – Bleibt die Frage an die Runde, ob der Einwand von тнояsтеn gegen die Platzierung im Ortsart. allgemein geteilt wird. Wenn das der Fall wäre, würde ich die Navileiste hier löschen und nur bei den Rennbahnart. allein einstellen. Dankend grüßt --Wi-luc-ky (Diskussion) 12:31, 15. Apr. 2016 (CEST)

Ich kenne keine technische Möglichkeit wie das auf einen Abschnittslink führen sollte. Es geht soweit ich weiß immer nur auf Artikellemmata, was ja auch sinnvoll ist, wie sollte denn die Navigationsleiste nur mit einem bestimmten Abschnitt verbinden? Es würde ja nur dann sinnvoll sein, wenn dann nur dieser Abschnitt sichtbar wäre.

Zumindest ist das meine Meinung. Es ist wie bei einer Weiterleitung, die ist auch nur dann sinnvoll, wenn sie auf einen Abschnitt oder Artikel leitet, der den verlinkten Begriff näher erklärt oder weiterführende Informationen bietet. Ein Pauschallink bei dem der Leser sich dann die Informationen bruchstückhhaft aus dem gesamten Artikel erschließen muss ist, … anstrengend und es kann vorkommen, dass man alles liest und doch nichts zu dem Thema erfährt worüber man eigentlich etwas lesen wollte. --Liebe Grüße, Lómelinde Diskussion 12:41, 15. Apr. 2016 (CEST)

Du kannst direkt (oder indirekt über eine Weiterleitung) schon auf Abschnitte in einem größeren Artikel verlinken, dass dann die Hervorhebung nicht klappt, macht nichts. Aber das Ziel muss stimmen, "Rennbahn irgendwie dreimal erwähnt"  ist kein Artikel oder Abschnitt zur Rennbahn. Der Spam-Effekt tritt auf, wenn seltsame Artikel mit Navigations-Vorlage wie w:en:February 30 über 365 eintreffende Links haben. Und es gab auch w:en:February 31 + w:en:March 0. –Be..anyone 💩 14:10, 15. Apr. 2016 (CEST)

Danke für eingehende Erläuterungen! Aus euer beider Antwort, Lómelinde und Be..anyone, entnehme ich v. a., dass hier zielgenauer verlinkt werden muss. Und: Wichtiger als die Hervorhebung ist die Verlinkung. So will ich die Änderungen angehen. --Wi-luc-ky (Diskussion) 22:49, 15. Apr. 2016 (CEST)

Noch eine Frage, bitte, zur Benennung der Zeile Navileiste. Ich habe da die zwei Varianten gesehen, also nur NL usw. oder auch mit Vorlage:NL usf.:

{{NaviBlock
|Navigationsleiste Name1
|Vorlage:Navigationsleiste Name2}}

Wonach richtet sich die Verwendung des Zusatzes Vorlage:? Ist es nötig? Dankend --Wi-luc-ky (Diskussion) 12:26, 16. Apr. 2016 (CEST)

Es ist egal, ob man den Namensraumpräfix Vorlage: verwendet oder nicht. Üblicher ist es, ihn wegzulassen. Gruß --Entlinkt (Diskussion) 14:06, 16. Apr. 2016 (CEST)

Gut. Vielen Dank, Entlinkt. Was mir noch unklar ist: Wieso hier in der Navileiste zu Pferderennbahnen links ein kleines rotes (nicht blaues) „V“ steht, bei den anderen NLs aber nicht. Zudem wird in der Vorschau auf dieses „V“ auch „leere Seite“ angezeigt, obwohl diese Vorlage existiert. --Wi-luc-ky (Diskussion) 18:22, 16. Apr. 2016 (CEST)

Hallo Wi-luc-ky, der so genannte Quicklink „V“ links oben in der eingebundenen Vorlage existiert nur bei Erweiterten Navigationsleisten, nicht bei normalen. Nach diesem Linkfix ist er in der Pferderennbahnen-Vorlage auch blau. --Wiegels „…“ 18:36, 16. Apr. 2016 (CEST)

Ja, Wiegels, so klappt es: Vielen Dank dafür. Das nächste Mal weiß ich Bescheid. Ich schätze Deinen immer hilfreichen Rat. --Wi-luc-ky (Diskussion) 18:46, 16. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wiegels „…“ 18:57, 16. Apr. 2016 (CEST)

ISBN-Umrechner

Hallo, gibt es ein Tool oder eine Site zur Umrechnung von ISBNs ohne Bindestriche in solche mit Bindestrichen? Für eine Antwort dankt --Wi-luc-ky (Diskussion) 16:01, 19. Apr. 2016 (CEST)

Ja, zum einen kannst du WSTM dafür benutzen, das formatiert alle ISB-Nummern in die korrekte Form um, auch dann, wenn falsche Striche verwendet werden. Zum Anderen gibt es das Tool ISBN-Check. --Liebe Grüße, Lómelinde Diskussion 16:52, 19. Apr. 2016 (CEST)

Sehr hilfreiche Tools. Hätte schon eher mal hier fragen sollen. Mein Dank geht wieder an Dich, Lómelinde. --Wi-luc-ky (Diskussion) 22:47, 19. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 22:47, 19. Apr. 2016 (CEST)

Leerzeichen in Vorlagenparameter (URL)

Hallo,
ich habe die Vorlage:OCC gezimmert. Der Hauptparameter - der Name eines Musikalbums - kann und wird oftmals Leerzeichen enthalten, wie in „speak and spell“. Bei der Auswertung/Weiterverwendung des Parameters wird aber - mir unerklärlicherweise - nur das erste "Wort" verwendet, hier „speak“, wodurch in der Folge der Zeichenkette nur Mist entsteht. Ich will vom Anwender nicht verlangen, das Leerzeichen durch „%20“ zu ersetzen. Wie kann ich das lösen? Würde bitte jemand in die Vorlage hineinschauen? --Tommes ^✉ 15:15, 20. Apr. 2016 (CEST)

Das ginge vll. mit {{filepath: {{#titleparts: {{PAGENAME: File:Chameleon VisualEditor 'Insert Media Dialog' Z Index Issue.png}} }} }} o.ä. (geklaut aus mw Diskussion "magic words"). –Be..anyone 💩 16:22, 20. Apr. 2016 (CEST)

Ich denke, du schaust besser mal nach Hilfe:Variablen #urlencode.

{{urlencode:speak and spell|PATH}} → speak%20and%20spell.

LG --PerfektesChaos 16:28, 20. Apr. 2016 (CEST)

Ja, mein Gemurkel ist eine Art "urldecode"-Lösung. –Be..anyone 💩 16:43, 20. Apr. 2016 (CEST)

Mein Dank an Euch beide! PC, das ist es, was ich suchte. Ich habe den Verweis auf diese Seite in Hilfe:Vorlagenprogrammierung#Problem:_Leerzeichen ergänzt. --Tommes ^✉ 19:36, 20. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: –Be..anyone 💩 02:41, 22. Apr. 2016 (CEST)

Vorlage:Ratingcodes

Unter Firefox (andere Browser bisher nicht getestet) fehlt eine schließende waagerechte Linie unter der letzten Tabellenzelle rechts unten ("Zahlungsausfall"). Es fällt z. B. in Rating#Ratingskalen auf, aber auch auf der Vorlagenseite. Da ich keine Ahnung habe, wieso die Tabelle dort nicht tut was sie soll, kann sich vielleicht einer der Experten das mal anschauen? Ich habe bisher nichts weiter daran geändert. Gruß, --Druschba 4 (Diskussion) 03:59, 21. Apr. 2016 (CEST)

Die Tabelle hatte Syntaxfehler. Ich habe versucht, sie zu beheben. Gruß --Entlinkt (Diskussion) 04:06, 21. Apr. 2016 (CEST)

Wunderbar, sieht aus wie es sollte. Danke und Gruß, --Druschba 4 (Diskussion) 08:20, 21. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Druschba 4 (Diskussion) 08:20, 21. Apr. 2016 (CEST)

Vorlage:Infobox Publikation: Vorgängerin/Nachfolgerin einer Publikation

Hallo, im Art. z. B. hier hat eine Publikation eine Vorgängerin. Kann/sollte sie in der Infobox vermerkt werden? Und wie? Sehe keinen Parameter (wäre wünschenswert). Gruß und Dank von --Wi-luc-ky (Diskussion) 01:02, 20. Apr. 2016 (CEST)

Klinkt nach "kein Handlungsbedarf, Einzelschicksal", einfach im Artikel erwähnen. Wartbarkeit von Artikeln und Vorlagen (= nicht zu kompliziert, geht auch mit VE) ist wichtig. –Be..anyone 💩 02:45, 22. Apr. 2016 (CEST)

Gut, Be..anyone, lassen wir die Vorgängerin also im Fließtext. Dank für Deinen Rat sagt --Wi-luc-ky (Diskussion) 00:02, 23. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 00:02, 23. Apr. 2016 (CEST)

Vorlage Literatur bei manchen Titeln fehlerhaft

Hallo, möchte auf folgenden typographischen Fehler in der Vorlage Literatur hinweisen, siehe z. B. Wiener Schmäh#cite ref-2:

{{Literatur | Autor=Peter Wehle | Titel=Sprechen Sie Wienerisch? | Verlag=[[Verlag Carl Ueberreuter|Verlag Ueberreuter]] | Ort=Wien | Jahr=2012 | ISBN =978-3-8000-7544-7 | Seiten=265 }}

was dann so aussieht:

Peter Wehle: Sprechen Sie Wienerisch? Verlag Ueberreuter, Wien 2012, ISBN 978-3-8000-7544-7, S. 265. 

Nun steht nach dem Fragezeichen des Titels noch ein (= der gewöhnlich richtige) Punkt, was hier typographisch zuviel und falsch ist. Die Vorlage wäre bitte so zu ändern, dass nach Frage- und Ausrufezeichen im Titel(ende) kein Punkt folgen darf, vielmehr dieser entfallen muss. Gruß und Dank von --Wi-luc-ky (Diskussion) 01:11, 22. Apr. 2016 (CEST)

Test, bei Gefallen bitte Doku reaktivieren, TemplateData ergänzen auf {{Literatur/Doku}}, Test auf die Testunterseite, und die scharfe {{Literatur/sandbox}} auf {{Literatur}} einsetzen. Demo:

{{Literatur/sandbox | Autor=Peter Wehle | Titel-P=Sprechen Sie Wienerisch? | Verlag=[[Verlag Carl Ueberreuter|Verlag Ueberreuter]] | Ort=Wien | Jahr=2012 | ISBN =978-3-8000-7544-7 | Seiten=265 }}

{{Literatur/sandbox | Autor=Peter Wehle | Titel-P=Sprechen Sie Wienerisch? | Verlag=[[Verlag Carl Ueberreuter|Verlag Ueberreuter]] | Ort=Wien | Jahr=2012 | ISBN =978-3-8000-7544-7 | Seiten=265 }}

–Be..anyone 💩 03:18, 22. Apr. 2016 (CEST) Geändert wie von тнояsтеn unten vorgeschlagen. 13:36, 22. Apr. 2016 (CEST)

Das sieht jetzt sehr gut aus, Be..anyone. Vielen Dank! Nun würde ich die vorgeschlagenen nötigen Ergänzungen gern selbst vornehmen, meine aber, dabei durch Unerfahrenheit mehr Fehler einzubauen. Statt meiner zu befürchtenden Verschlimmbesserungen möchte ich Dich herzlich darum bitten und danke im Voraus. Danach wird wohl auch im Art. Wiener Schmäh#cite ref-2 eine automatische Verbesserung eintreten, oder? --Wi-luc-ky (Diskussion) 09:36, 22. Apr. 2016 (CEST)

Muss noch einmal trotz Erledigt-Vermerk nachfragen, Be..anyone, ob die Reparatur an der VL Literatur schon funktioniert. Auf der Site Wiener Schmäh selbst hat sich sichtbar noch nichts geändert – trotz einem Nulledit. Was nun? Gruß und nochmals Dank von --Wi-luc-ky (Diskussion) 11:47, 22. Apr. 2016 (CEST)

Ohne KeinPunkt ändert sich nichts, das war der von Dir abgenickte Vorschlag. Wenn Du rückwirkend vollautomatisch willst, ändert sich die Sachlage, das geht nur mit Scribunto (oder völlig unverständlicher und unwartbarer Vorlagenverwurstung): Module (Scribunto, Lua) kann ich leider nicht, allenfalls kleine Änderung in vorhandenem Modul.–Be..anyone 💩 11:57, 22. Apr. 2016 (CEST)

Bei Nichtgefallen bitte je ein Undo (zurück) auf Stand gestern für {{Literatur}}, {{Literatur/Doku}}, {{Literatur/Test}}, it's a wiki, und bei Änderungen an millionenfach benutzten Vorlagen kann nur die Wikipedia kurzfristig ausfallen.Vorlage:Smiley/Wartung/zunge  –Be..anyone 💩 12:04, 22. Apr. 2016 (CEST)

Ähm, es gibt doch schon den Parameter Titel-P, der genau dafür da ist?!? --тнояsтеn ⇔ 13:11, 22. Apr. 2016 (CEST)

Kein Kommentar, Müll aufgeräumt, Danke. –Be..anyone 💩 13:37, 22. Apr. 2016 (CEST)

Mit Shakespeare: Viel Lärm um (fast) nichts – das doch alles zum Guten verändert: „-P“ werde ich mir merken. Vielen Dank an euch beide, Be..anyone und тнояsтеn, sendet --Wi-luc-ky (Diskussion) 23:33, 22. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 23:33, 22. Apr. 2016 (CEST)

Zeitschriften-Logo in Infobox

Hallo, eine Redaktion hat mir das Logo ihrer Zeitschrift zur Verfügung gestellt. Ist es aus rechtlichen Gründen möglich, eine Datei hochzuladen zwecks Einbindung in die Infobox? Welche Inhaberrechtefragen sind zu beachten? Welche Größe wäre empfehlenswert? Dank von --Wi-luc-ky (Diskussion) 00:05, 8. Apr. 2016 (CEST)

Bei DCRaw bin ich mit einem dewiki-Logo gescheitert, auf enwiki ging es natürlich als fair use. –Be..anyone (talk) 18:52, 11. Apr. 2016 (CEST)

Die Frage wäre bei WP:UF richtig gewesen.

Das Logo muss unter einer freien Lizenz stehen. Weitergabe, Bearbeitung, kommerzielle Nutzung, Vervielfältigung usw. müssen alles erlaubt sein. Das ist eine sehr weitreichende Freigabe und ich weiß nicht, ob die ihr Logo auf diese Art freigeben möchten. Auf jeden Fall brauchen wir die Freigabe schriftlich; dort gibt es eine entsprechende Vorlage, die an das Wikipedia:Support-Team gesendet werden muss. Wichtig ist aber, dass tatsächlich der Inhaber der vollumfänglichen Rechte die Freigabe erteilt. Die Redaktion kann das also wahrscheinlich gar nicht, sondern nur der Verleger. -- Chaddy · D – DÜP – 19:00, 11. Apr. 2016 (CEST)

Vielen Dank für eure hilfreichen Antworten (trotz Addressierung an die „falsche “Werkstatt), die ich leider irgendwie übersehen haben muss, Be..anyone und Chaddy. Werde es an die Redaktion weitergeben und setze es hier mal auf „Erledigt“. --Wi-luc-ky (Diskussion) 18:52, 25. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 18:52, 25. Apr. 2016 (CEST)

Vorlage:Infobox Tennisturnierjahrgang

Hallo, ich habe ein kleines Problem bei der o.g. Vorlage, da wie hier zu sehen ist, die Vorlage in der Infobox rechts als aktuelles Jahr "1000" erkennt, vermutlich deshalb, weil es sich einfach die erste Zahl aus dem Artikelnamen nimmt. Ich habe aber leider keine Programmierkenntnisse, also wäre nett, wenn das jemand abändern könnte, sodass nur die letzte Zahl genommen wird. Danke schonmal :) --Siebenschläferchen (Diskussion) 23:29, 24. Apr. 2016 (CEST)

Die Navigation wird ohnehin nur angezeigt, wenn Jahr= definiert wurde. Also habe ich jetzt einfach dieses Jahr ausgeben lassen. --mfb (Diskussion) 23:58, 24. Apr. 2016 (CEST)

so einfach kanns gehen, danke dafür! --Siebenschläferchen (Diskussion) 00:09, 25. Apr. 2016 (CEST)

Den Erle-vermerk muss ich wieder entfernen. Wenn jetzt die Infobox in den Artikel Shanghai Rolex Masters 2010 eingefügt wird, der ja auf das Jahr 2009 mit der Navi verlinkt würde, gibt es hier das 1000 Problem. Ich habe damals dieses Extra hinzugefügt, aber da ich nur im Damentennis aktiv bin sah ich dieses Problem nicht kommen. Gibts eine Möglichkeit dieses Probleme zu lösen ohne das wir neue Parameter verwenden - gut man könnte dieses einen Artikel mit der 1000 vielleicht verschieben. Ich möchte ungern jeden Artikel ändern müssen. Gruß Mac6v3 (Diskussion) 09:48, 25. Apr. 2016 (CEST)

Wir hatten doch schon einmal so einen Fall, daher erledigt. Mac6v3 (Diskussion) 12:12, 25. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Mac6v3 (Diskussion) 12:12, 25. Apr. 2016 (CEST)

Benutzer:MerlBot - rote umrandete Kästen unsichtbar machen!?

Hallo zusammen, wie kriege ich diese störenden rot umrandeten Kästchen vom MerlBot weg? Siehe hier. Herzliche Grüße, --Arimja (Diskussion) → Wikiliebe?! 23:34, 3. Mai 2016 (CEST)

Gar nicht, die Vorlage sieht es nicht vor, den Rahmen zu entfernen. Vielleicht sieht es mit einer Leerzeile dazwischen besser aus? Sonst kannst du Benutzer:Merlissimo fragen, ob sein Bot auch unsichtbare Vorlagen findet (wahrscheinlich ja). Dann könnte man die Anzeige des Bausteins unterdrücken und ggf. einen beliebigen eigenen Baustein anzeigen, der für den Bot ohne Funktion wäre. --mfb (Diskussion) 23:54, 3. Mai 2016 (CEST)

Vielen Dank! Ich wende mich an den Botbetreiber. Herzliche Grüße, --Arimja (Diskussion) → Wikiliebe?! 00:01, 4. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Arimja (Diskussion) → Wikiliebe?! 00:03, 4. Mai 2016 (CEST)

Benutzer:MerlBot und {QS-Pflege}

Hallo zusammen, eine weitere Frage: was muss ich machen, damit MerlBot betroffene Artikel automatisch auf die Seite der Qualitätssicherung Portal Pflege mit {QS-Pflege} einträgt? Vergleichbar dazu der Eintrag von MerlBot auf die QS der Redaktion Medizin hier. Herzliche Grüße, --Arimja (Diskussion) → Wikiliebe?! 23:49, 3. Mai 2016 (CEST)

Botfragen am besten direkt an den Botbetreiber. Aber Benutzer:MerlBot/InAction hat eine Dokumentation. --mfb (Diskussion) 23:55, 3. Mai 2016 (CEST)

Vielen Dank! Ich wende mich an den Botbetreiber. Herzliche Grüße, --Arimja (Diskussion) → Wikiliebe?! 00:01, 4. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Arimja (Diskussion) → Wikiliebe?! 00:03, 4. Mai 2016 (CEST)

monument historique

Ist es möglich, die Vorlagen, die die Verbindung zu den offiziellen Daten erzeugen, auch in die DE:WP zu übernehmen? Am besten wäre es, die komplett zu kopieren zwecks direkter Übernahme der Daten aus den französischen Artikeln.

Als Beispiel: fr:Tumulus_de_Baudement.

--Benutzer:Eingangskontrolle Wikipedia:Meinungsbilder/Punktekonto für Löschanträge 18:23, 25. Apr. 2016 (CEST)

Geht es dir um die Infobox (fr:Modèle:Infobox Monument)? Oder suchst du die Vorlage:Base Mérimée? --тнояsтеn ⇔ 19:38, 25. Apr. 2016 (CEST)

die Verlinkung zu den Daten, im ersten Entwurf zu Liste_von_Megalithanlagen_im_Departement_Marne hat es nicht funktioniert --Benutzer:Eingangskontrolle Wikipedia:Meinungsbilder/Punktekonto für Löschanträge 22:06, 25. Apr. 2016 (CEST)

Die Vorlage erlaubt immer nur einen Eintrag. War es so in die Richtung gedacht: [3] ? --тнояsтеn ⇔ 22:16, 25. Apr. 2016 (CEST)

So war es gedacht

Archivierung dieses Abschnittes wurde gewünscht von: Eingangskontrolle (Diskussion) 22:00, 4. Mai 2016 (CEST)

Vorlage wird nicht eingebunden. Finde Fehler nicht.

Hallo zusammen, hier habe ich diese Vorlage eingebunden. Leider wird sie nicht angezeigt. Warum? Wo ist mein Fehler? Herzliche Grüße, --Arimja (Diskussion) → Wikiliebe?! 23:39, 6. Mai 2016 (CEST)

Keine Ahnung, aber einmal purgen hat das Problem behoben. --FordPrefect42 (Diskussion) 23:50, 6. Mai 2016 (CEST)

Vielen Dank. Herzliche Grüße, --Arimja (Diskussion) → Wikiliebe?! 23:58, 6. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Arimja (Diskussion) → Wikiliebe?! 23:58, 6. Mai 2016 (CEST)

Autoarchivhinweis wird nicht angezeigt

Hallo zuammen, ich habe eine weitere Frage: Mein Hinweis auf das Autoarchiv wird hier angezeigt. Aber wenn ich die Vorlage einbinde, wird sie auf der Zielseite nicht mehr angezeigt. Wie behebe ich das Problem? Herzliche Grüße, --Arimja (Diskussion) → Wikiliebe?! 00:04, 7. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Arimja (Diskussion) → Wikiliebe?! 00:12, 7. Mai 2016 (CEST)

Vorlage:Pointstreak

Ich habe die Vorlage nun langsam dahin, wohin sie sollte. Mit switch drei Abfragen. Bei jedem switch wird die jeweils komplette URL-Kette gebaut. Aber irgendetwas geht nicht. Nach langem Zögern muss ich mich nun doch an die Profis wenden. Die Vorlage soll schlicht so funktionieren, wie es in der Doku beschrieben ist. Dort sieht man auch am besten die Fehler. Der optische: Warum werden die %-codierten Zeichen angezeigt? Ein anderer: warum wird nach der ID, bei längeren URL umgebrochen? Sieht aus als ob da irgendwoher ein Leerzeichen kommt. --Tommes ^✉ 17:17, 8. Mai 2016 (CEST)

Hallo Tommes, sind deine Probleme hiermit erledigt? --Wiegels „…“ 20:55, 8. Mai 2016 (CEST)

Sieht gut aus! Danke!! --Tommes ^✉ 21:10, 8. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wiegels „…“ 21:14, 8. Mai 2016 (CEST)

Allgemeine Vorlage für zwei Koordinaten

Hallo, es gibt bspw. die Vorlage: Infobox Radfernweg, dort werden zwei Koordinaten verwendet, eine Start- und eine Zielkoordinate. Wäre es möglich, so etwas auf einer allgemeineren Ebene zu erstellen? Also quasi für ein beliebiges Objekt? Es wäre dann bspw. sinnvoll Koordinate_1 und Koordinate_2 eingeben zu können und Ja ob sie Start- und Zielpunkte sind (bspw. eine Rennstrecke) oder ob sie gleichwertig sind und es egal ist in welche Reihenfolge man die beiden Koordinaten bringt (bspw. ein Wanderweg der gleichermaßen von hier oder von dort gestartet werden kann). Zusammen dann noch mit einem Namensfeld, Namensfelder für die Koordinaten, Felder zur Lage (Kontinten, Staat und weitere Unterteilungen), Länge, vielleicht eine Nummer (als Ergänzung zum Namen, wie man es bspw. bei Straßen verwendet, B28 oder so), Links damit man oben eine Karte öffnen kann ggf. mit Openstreetmap-Daten und vielleicht noch andere Ergänzungen. Wäre das sinnvoll und machbar? Direkt denke ich jetzt an Kategorie:Hochspannungsleitungen, gäbe aber sicherlich noch mehr Verwendungszwecke... --Yeerge (Diskussion) 14:30, 30. Apr. 2016 (CEST)

Was genau sollte die „2-Koordinaten-Vorlage“ denn tun?

Falls sie beide Koordinaten in der Ecke oben rechts anzeigen soll, wäre ich klar dagegen. Das ist nämlich ein ganz, ganz ungünstiger Ort zum Unterbringen von viel Text.

Im Artikel Zürich ist das Koordinatenkonstrukt oben rechts bei mir gerade 377 Pixel breit (genauer Wert kann von der Schriftart abhängen). Eine 2-Koordinaten-Vorlage für zwei Orte in der Schweiz hätte also entweder mindestens 754 Pixel (!) in der Breite oder mindestens zwei Zeilen übereinander. Beides würde das Seitenlayout so ziemlich versauen.

In der Mobilversion der Wikipedia werden die oben rechts positionierten Teile übrigens gar nicht angezeigt, weil sie selbst ohne Verdopplung schon zu viel Raum greifen. (Ironischerweise hatte man mit der Positionierung oben rechts mal im Sinn, besonders stark in den Fokus des Lesers zu kommen, tatsächlich erreicht man aber, dass man von einem Teil der Leser überhaupt nicht gesehen wird.)

Falls die „2-Koordinaten-Vorlage“ nicht in der Ecke oben rechts angezeigt werden soll, sondern irgendwo anders, sehe ich zwar nicht, was dagegen spräche, aber auch wenig Vorteile gegenüber einer simplen zweifachen Einbindung der Vorlage:Coordinate. Siehe als Beispiel den Artikel Aa (Möhne) mit den beiden Koordinatenangaben (für Quelle und Mündung) in der Infobox.

Gruß --Entlinkt (Diskussion) 19:01, 30. Apr. 2016 (CEST)

PS: Für diejenigen, die noch nicht wissen, warum diese oben rechts positionierten Vorlagen so problematisch sind, habe ich mal hier eine kleine Demonstration gebaut. Viele Grüße --Entlinkt (Diskussion) 21:07, 30. Apr. 2016 (CEST)

Zu Artikelkoordinaten in der Mobilversion siehe phab:T91481. --тнояsтеn ⇔ 22:10, 1. Mai 2016 (CEST)

Der letzte Stand ist, dass die Artikelkoordinaten in skins.minerva.content.styles/hacks.less mittels

#coordinates {
	display: none !important;
}

explizit ausgeblendet werden und dass es mit gerrit:195495 einen Patch gab, die explizite Ausblendung zu entfernen, der aber abgelehnt wurde. (Ich wüsste auch beim besten Willen nicht, wohin damit.)

Für die Desktop-Version habe ich übrigens noch eine Demonstration parat, um zu zeigen, warum bitte keine Vorlage mit zwei Zeilen gebaut werden sollte. Gruß --Entlinkt (Diskussion) 02:37, 2. Mai 2016 (CEST)

Es war weniger gemeint die beiden Koordinaten oben rechts einzublenden, sondern eher so wie die angesprochene Vorlage Infobox Radfernwege es macht (Beispiel einer Verwendung: Kaiser-Route). Mein Vorschlag zielte eher auf eine Infobox ab, die eben nicht nur eine Koordinate enthalten sollte (wie bspw. die Vorlage:Infobox Bauwerk, sondern zwei. Wie die Koordinaten dann außerhalb der Infobox angezeigt werden, daran hatte ich überhaupt nicht gedacht (schätze aber so wie in der Infobox Radfernwege wäre es gut). Die Vorlage:Infobox Tunnel verwendet ebenfalls zwei Koordinaten (Bsp.: Fildertunnel). Und da wäre es mMn nach sinnvoll, nicht nur eine Infobox zu haben, die speziell Radfernwege und Tunnel behandeln, sondern auch noch eine kleine Infobox, die für andere Objekte, die quasi zwei Koordinaten haben, eingesetzt werden kann. Wäre das möglich? --Yeerge (Diskussion) 19:37, 4. Mai 2016 (CEST)

Infobox Zwei Koordinaten

Eine Koordinate	50° 0′ N, 50° 0′ O5050
Andere Koordinate	50° 0′ N, 50° 0′ O5050

Sorry, es ist für mich nicht nachvollziehbar, was du wünschst.

Die Vorlage:Infobox Radfernweg bindet manchmal Koordinaten ein (und zwar aufgrund einer recht komplizierten Logik manchmal oben rechts, manchmal in der Tabelle, manchmal in Textform und manchmal als Positionskarte). Der von dir als Verwendungsbeispiel angeführte Artikel Kaiser-Route enthält allerdings keine einzige Koordinate, sondern nur eine Einbindung von {{Karte}}, die außerhalb der Infobox erfolgt (siehe Quelltext des Artikels). Daher sehe ich leider nicht, was du mit diesem Beispiel aussagen möchtest.

Die von dir und mir angeführten Beispiele

• Vorlage:Infobox Fluss (siehe Artikel Aa (Möhne)) sowie
• Vorlage:Infobox Tunnel (siehe Artikel Fildertunnel)

binden jeweils zweimal {{Coordinate}} ein. Für diese Darstellung wird keine neue Vorlage benötigt, sondern alle anderen Infoboxen, bei denen etwas ähnliches gewünscht wird, können ebenfalls zweimal {{Coordinate}} einbinden.

Dein letzter Satz („auch noch eine kleine Infobox, die für andere Objekte, die quasi zwei Koordinaten haben, eingesetzt werden kann“) klingt allerdings für mich nach einer kleinen Infobox, die nur zwei Koordinaten und nichts anderes anzeigt. Ob das sinnvoll ist, weiß ich nicht, aber die Umsetzung wäre trivial (siehe #ZweiKoordinaten). Gruß --Entlinkt (Diskussion) 08:22, 5. Mai 2016 (CEST)

Ja klar, einfach eine Tabelle, das ist natürlich auch eine Lösung. An diese hatte ich nicht gedacht. Danke dafür. Damit ist eigentlich das erfüllt was ich meinte. :-) --Yeerge (Diskussion) 19:39, 9. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Yeerge (Diskussion) 19:39, 9. Mai 2016 (CEST)

Skript debuggen?!

Bei Aufruf dieses Art. kommt die Browser-Meldung:

Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen, im Debugger öffnen oder weiter ausführen.
Skript: https://de.wikipedia.org/w/ind…tion=raw&ctype=text/javascript:988

Die Site lädt auch außergewöhnlich langsam, bis die Meldung erscheint. Was ist zu tun? --Wi-luc-ky (Diskussion) 22:10, 10. Mai 2016 (CEST)

Interessant wäre der Teil der Skriptadresse, der hier durch Auslassungszeichen ersetzt wurde. -- hgzh 22:13, 10. Mai 2016 (CEST)

(BK) Leider ist der interessanteste Teil der Meldung (nämlich der Name des betroffenen Skripts) nicht sichtbar. In Anbetracht der Seite Benutzer:Wi-luc-ky/toolserverhelferleinconfig.js würde ich aber einfach mal vermuten, dass es um eines der mittels MediaWiki:Gadget-toolserver-integration.js geladenen Skripte geht. (Es könnte aber auch ein anderes Gadget sein.) --Entlinkt (Diskussion) 22:16, 10. Mai 2016 (CEST)

Danke an euch, hgzh und Entlinkt. Zunächst möchte ich sagen, dass ich die Meldung nicht bewusst gekürzt habe, sondern beim Kopieren vom Fehlermeldungsfenster gekürzt wurde. Wie also erhalte ich eine vollständige Meldung, die weiterhilft? Dann entnehme ich euren vorläufigen Antworten, dass es wohl nicht an der fraglichen Website liegt. Antwort erbittet --Wi-luc-ky (Diskussion) 23:06, 10. Mai 2016 (CEST)

An der Wikiseite selbst liegt es ziemlich sicher nicht. Lässt sich der Fehler denn reproduzieren, wenn du (1) eingeloggt und (2) ausgeloggt bist? (Ich bin ziemlich sicher, dass er sich in Fall (2) nicht reproduzieren lassen wird; bei Fall (1) wäre ich dir dankbar, wenn du das austesten und rückmelden könntest.)

Um die Ursache zu finden, bräuchten wir aber wirklich die vollständige Skriptadresse. Lässt sich das Fenster nicht vergrößern, so dass die Adresse vollständig angezeigt wird? Welchen Browser verwendest du überhaupt? --Entlinkt (Diskussion) 23:21, 10. Mai 2016 (CEST)

Danke, Entlinkt. Zunächst: Der Fehler tritt nicht beim bloßen Aufruf dieses Art., sondern nur bei einer Änderung desselben (auch auf der Spielwiese: hier schon nach Einfügen des Original-Quelltextes und Vorschau) auf. Es ist Firefox 46.0.1. Fehler ist dann (1) eingeloggt beliebig und ohne Ausnahme reproduzierbar und tritt (2) ausgeloggt gar nicht auf. Das Fehlermeldungsfenster kann zwar auf ganze Bildschirmgröße maximiert werden, zeigt aber leider denselben gekürzten Text mit Auslassungszeichen; nur einmal stand statt 988 die 127 am Ende.

Bei den Optionen im Fenster: Skript stoppen und (Skript) Weiter ausführen funktioniert die Site problemlos; bei Skript debuggen öffnet sich unten das einschl. Bearbeitungsfenster. Darin steht auf Zeile 998 (hier fett):

proxy: function (f) {
var that = this;
if (!this.proxyCache) {
this.proxyCache = {};
}
if (!hasOwn.call(this.proxyCache, f)) {
'''this.proxyCache[f] = function () {'''
that[f].apply(that);
};
}
return this.proxyCache[f];
},

Auf Zeile 127 steht (hier fett):

parse: function (text) {
if (text === this.oldText) {
return this.oldParse;
}
this.oldText = text;
this.oldParse = [];
var i, open = [], ret, par = text.split('\n');
for (i = 0; i < par.length; i++) {
'''ret = this.parseParagraph(par[i], open);'''
this.oldParse = this.oldParse.concat(ret[0]);
open = this.syntax.eol(ret[1]);
}
return this.oldParse;
},

Mglw. helfen diese (Umgebungs-)Zeilen. Danke und bis „morgen“! --Wi-luc-ky (Diskussion) 00:31, 11. Mai 2016 (CEST)

Die Fehlermeldungen beziehen sich auf das Skript Benutzer:Schnark/js/syntaxhighlight.js, welches du auf Umwegen (über das „Toolserver-Helferlein“) aktiviert hast.

Ich habe dasselbe Skript zu Testzwecken derzeit auch aktiviert, aber bei mir tritt kein Fehler auf (Browser: Chromium 50 + Firefox 46). Gruß --Entlinkt (Diskussion) 01:06, 11. Mai 2016 (CEST)

Gut, dann liegt's an meiner Konfiguration. Wollte nur wissen, ob im Art. etwas Problematisches steht, das von allgemeinem Interesse hätte sein können. Kann damit leben. Die Syntaxhervorhebung klappt in der Tat nicht: Nach kurzem Aufscheinen zeigt das Feld nur blasse farbige Streifen ohne Text. Aber auch hier lohnte sich ein neuer Thread wohl nicht?! Dank für Deine Antworten sagt --Wi-luc-ky (Diskussion) 10:31, 11. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 10:31, 11. Mai 2016 (CEST)

Beobachtungsliste: Zeitbegrenzung für beobachtete Seiten einrichten

Hallo, wäre es nicht wünschenswert, analog zur automatischen Archivierung auch für die zu beobachtenden Sites im Inhaltsverzeichnis Zeitbegrenzungen vorgeben zu können? Einmal global für alle, dann für die einzelnen Sites, falls sie länger oder kürzer beobachtet werden sollen. Damit könnte die manuelle Abwahl wesentlich vereinfacht werden oder entfallen. Gruß von --Wi-luc-ky (Diskussion) 16:57, 11. Mai 2016 (CEST)

Die Beobachtungsliste hat nichts mit Seiteninhalten oder Vorlagen auf den Seiten zu tun. Ein solches Feature braucht eine Änderung der Mediawiki-Software. Als Featurewunsch wurde das schon mehrfach vorgeschlagen. --mfb (Diskussion) 17:05, 11. Mai 2016 (CEST)

Die Realisierung des Wunsches ist bereits in Arbeit, siehe Möglichkeit, dass ein Artikel nach Ablauf einer einstellbaren Zeitspanne automatisch wieder von der Beobachtungsliste gestrichen wird. — Raymond ^Disk. 22:59, 11. Mai 2016 (CEST)

Bleibt zu hoffen, dass es nicht so lange in Arbeit bleibt wie gewisse andere Projekte. --mfb (Diskussion) 01:02, 12. Mai 2016 (CEST)

Hoffe mit euch, mfb und Raymond, und sage Danke! --Wi-luc-ky (Diskussion) 11:40, 13. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 11:40, 13. Mai 2016 (CEST)

Nummerierung der Tabellenelemente

Hallo, ich möchte die Ehrenbürger = Elemente beider Tabellen hier gern automatisch nummerieren lassen, da im Hauptartikel dort wiederkehrend eine händische Aktualisierung der Anzahl erfolgen muss (!?), wobei es mühsam ist, ständig an die 50 Tabellenelemente durchzuzählen. Bitte um Hilfe, wie je eine Spalte mit der Nummerierung davorgesetzt werden kann, ohne dass die alphabetische Standard-Sortierung verlorengeht. Leider wird in der Hilfe keine numerische, sondern nur eine Buchstabensortierung vorgeführt. Und die Hilfe zur Nummerierung der Zeilen ist nicht eben hilfreich, da sie den Kopf mit „ist nicht vorgesehen“ in den Sand steckt. Hie und da sieht man/frau aber nummerierte Tabellen, konnte die Codierung aber nicht erfolgreich übernehmen:

{| class="sortable wikitable"
|-
!align="center"| #<br/>
usw.

Dank von --Wi-luc-ky (Diskussion) 13:20, 5. Mai 2016 (CEST)

Ich meine auch, dass es nicht (in Content-tauglicher Art) möglich sei, abgesehen von manuell Numerieren, was aber in den Fällen auch nicht wirklich nützlich ist, da die Nummer nur Wikipedia-intern wäre. Als Lösung zum einfacheren Nachzählen (Beschreibung für Firefox, bei anderen modernen Desktop-Browsern ähnlich): Rechtsklick auf die Tabelle, "Element untersuchen", Rechtsklick auf das tbody-Element über dem Selektierten, "in Konsole verwenden", .childElementCount hintendran eingeben. --nenntmichruhigip (Diskussion) 19:15, 5. Mai 2016 (CEST)

Es lassen sich sicher Möglichkeiten finden, das auszuwerten, aber wäre es das wert? Da ändert sich nur alle paar Jahre einmal etwas. --mfb (Diskussion) 21:18, 5. Mai 2016 (CEST)

Vielen Dank für eure Antworten, Nenntmichruhigip und mfb. Meine Bitte wäre, die o. g. Lösung so zu beschreiben, dass auch nicht so erfahrene Nutzer auf der Diskussionsseite Zwickau damit umgehen können, wohin ich sie (die Lösung) als Anleitung verschieben möchte. btw: Wie und warum klappt die Nummerierung z. B. hier? Wäre das nicht übertragbar? Gruß und Dank von --Wi-luc-ky (Diskussion) 16:36, 10. Mai 2016 (CEST)

Dort erfolgt die Nummerierung auch manuell, und mit den zu erwartenden Fehlern (Lücken). Dort ist die Nummerierung jedoch (wenn sie korrekt durchgeführt wäre) sinnvoll, da die Nummerierung auch sonst eine Information hat (beachte z.B. "Frances Cleveland" als 23 und 25). Oder würde man in einem Personenartikel z.B. "ist der fünfte Ehrenbürger der Stadt Zwickau" schreiben? --nenntmichruhigip (Diskussion) 08:48, 11. Mai 2016 (CEST)

Vielen Dank, Nenntmichruhigip. Die Zählung überm großen Teich ist in der Tat etwas gewöhnungsbedürftig und durch viele Zusatzbestimmungen (s. Text) bedingt, letztlich wohl aber dann richtig. – Habe mich hier für eine sortierbare Zählung entschieden und es entsprechend geändert, das wird das Zählen von 50 Elementen ersparen. --Wi-luc-ky (Diskussion) 22:25, 15. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 22:25, 15. Mai 2016 (CEST)

Vorlage aus der es-WP übernehmen?

Nachdem ich hier die Verwaltungskarte des venezolanischen Bundesstaates Bolivár gefunden und in den deutschen Artikel gesteckt hatte, war die Beschriftung weg. In der es-WP wird dort eine Vorlage es:Plantilla:AP verwendet, um die Beschriftungen auf die Karte zu zaubern, aber ich konnte nicht ausfindig machen, wo die dazu notwendigen Informationen (Namen und Lagen) gespeichert sind, und wie. Ist es möglich, das ohne größere Probleme in die de-WP und den entsprechenden Artikel mit der Karte zu übernehmen? Ja ich weiß, mit der deutschen Vorlage:Image label kann man mit etwas Mühe ähnliches basteln, aber das sollte nicht nötig sein, wenn sich die Kollegen in der es-WP schon die Arbeit gemacht haben.--Ratzer (Diskussion) 21:56, 1. Apr. 2016 (CEST)

@Ratzer: Die spanische Vorlage es:Plantilla:AP hat mit deinem Problem gar nichts zu tun, denn ihr Interwikilink führt auf unsere Vorlage {{Hauptartikel}}. Es fehlt eine Entsprechung der spanischen Vorlage es:Plantilla:Mapa de Bolívar (Venezuela) rotulado. Allerdings ist sie im spanischen Artikel sogar noch in es:Plantilla:Cuadro imagen eingebunden, welche unserer Vorlage {{Kladogramm}} entsprechen soll. Allerdings weiß ich nicht, ob wir wirklich es:Plantilla:Mapa de Bolívar (Venezuela) rotulado portieren sollten oder nicht. --Tlustulimu (Diskussion) 21:17, 3. Apr. 2016 (CEST)

Ich habe gerade den Abschnitt "Verwaltungsgliederung" des Artikels Bolívar (Bundesstaat) etwas nach der spanischen Vorlage es:Plantilla:Mapa de Bolívar (Venezuela) rotulado ergänzt. Falls doch für weitere Artikel eine eigenständige Vorlage gebraucht wird, bitte hier kurz den Namen vorschlagen und ich ändere es noch einmal. --Tlustulimu (Diskussion) 21:38, 3. Apr. 2016 (CEST)

Danke sehr, so passt alles. Die es-WP verwendet also auch eine Entsprechung der Vorlage "Image label" (dort "Etiqueta imagen pequeña" genannt).--Ratzer (Diskussion) 08:45, 4. Apr. 2016 (CEST)

Neue Filmportal-Vorlage

Hallo! Es bestehen Überlegungen, die beiden Filmportal-Vorlagen ([1], [2]) zu einer neuen Vorlage:Filmportal zusammenzuführen. Es gibt aber den kleinen feinen Unterschied, dass Filmtitel bei uns kursiv gesetzt werden. Im Gegensatz zur IMDb-Vorlage kann man aber nicht anhand der ID erkennen, ob es eine Person oder ein Film ist. Hat jemand eine Idee, wie man das ohne weiteren Parameter abfragen könnte? Mir fällt spontan folgendes ein:

1. Abfragen über ist ein(e) (P31), ist allerdings in Wikisyntax etwas umständlich mit den Unterklassen von Film (Q11424)
2. Abfragen, ob Vorlage Persondaten oder Vorlage Infobox Film gesetzt ist, geht wohl irgendwie in Lua, hab ich bei den Schachspielern gesehen
3. Abfragen von Kategorien, weiß aber nicht, ob das geht

Vielleicht hat jemand Tipps zur Umsetzung? LG –Queryzo ?! 12:33, 5. Apr. 2016 (CEST)

Geschlecht (P21) abfragen. Wenn dort was steht, ist es eine Person und bei Personen sollte die Property gesetzt sein.--Färber (Diskussion) 12:43, 5. Apr. 2016 (CEST)

Stimmt, da sind alle Objekte mit versorgt, gute Idee! –Queryzo ?! 12:51, 5. Apr. 2016 (CEST)

Vorlage Diskussion:War Löschkandidat#Leerzeile

Bitte um Hilfe. --тнояsтеn ⇔ 12:35, 17. Mai 2016 (CEST)

Ist das Problem mit diesen Änderungen gelöst?

Ursache war ein Schlüsselwort __HIDDENCAT__, das in einer eigenen Zeile stand, die dadurch als Leerzeile galt. In der Vorlage hat das Schlüsselwort aber sowieso nichts zu suchen, es ist nur auf Kategorieseiten wirksam. Gruß --Entlinkt (Diskussion) 12:52, 17. Mai 2016 (CEST)

Sieht gut aus, danke. --тнояsтеn ⇔ 12:58, 17. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 12:58, 17. Mai 2016 (CEST)

Ominöse Backlinks

Kann sich jemand diese Backlinks erklären? –Queryzo ?! 11:28, 6. Apr. 2016 (CEST)

Ja; der Artikel wird von den „Defekte Weblinks“ ausgelesen. VG --PerfektesChaos 12:34, 6. Apr. 2016 (CEST)

Verlinkung nur für erste Vorlageneinbindung

Ich suche eine Möglichkeit (wahrscheinlich per Modul:TemplUtl), nur für die erste Vorlageneinbindung einen Link auszugeben, für alle weiteren sollte stattdessen der unverlinkte Text ausgegeben werden. Ich scheitere leider bereits daran auszulesen, ob ein Artikel überhaupt die Vorlage enthält, siehe Modul:Film. Kann jemand helfen? –Queryzo ?! 14:21, 6. Apr. 2016 (CEST)

Helfen kann ich da nicht wirklich, aber zumindest ein paar Vorlageneinbindungen suchen. insource:/"{Filmportal"/ gibt 8.102 (8.058 × Filmportal.de) Einbindungen aus. Davon 4.209 × Name und 3.812 × Titel und noch 42 × andere. Wie man so etwas in Lua abfragt weiß ich nicht. --Liebe Grüße, Lómelinde Diskussion 14:54, 6. Apr. 2016 (CEST)

Na das krieg ich auch noch hin, es geht um die Vorlagen in einem bestimmten Artikel!   –Queryzo ?! 15:21, 6. Apr. 2016 (CEST)

"Rowspan" Möglichkeit für style="background:#DDF; color:black; vertical-align:middle; text-align:center; " class="table-na" | N. N.

Hallo Liebe Wikipedianer. Ich möchte gerne die Vorlage:TBA über mehrere Zeilen (12 Stück) für den Artikel 1992 Eric Clapton World Tour nutzen, um 2x1 die Vorlage zu verwenden und nicht 2x12. Könnt ihr dies bitte einrichten? Für die Formel 1 WM's wäre dies auch hilfreich. Danke! --188.105.191.1 07:56, 5. Mai 2016 (CEST)

HABE ES HINGEKRIEGT! Danke trotzdem. Hier ist alles erledigtErledigt --188.105.191.1 12:14, 5. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Rik VII. my2cts   08:23, 18. Mai 2016 (CEST)

Liste automatisierter geschützter Leerzeichen?

Hallo, gibt es eine Liste geschützter Leerzeichen, die kein

 

benötigen, sondern automatisch geschützt sind? Durch einen Dritten wurde ich freundlich darauf hingewiesen, dass z. B. Prozentzahlen vor % der Trennung nicht (mehr) bedürften, dies aber der einzige ihm bekannte Fall sei. – Die Liste würde Zeit ersparen und den Quellcode übersichtlicher erhalten. --Wi-luc-ky (Diskussion) 15:09, 18. Mai 2016 (CEST)

Soweit ich weiß, ist dieses Verhalten bisher ausschließlich beim Prozentzeichen der Fall. Weitere Pläne (inkl. Liste) findest du unter Wikipedia:Typografie/Automatische Leerzeichen!--XanonymusX (Diskussion) 16:10, 18. Mai 2016 (CEST)

Es sind dies zurzeit:

1. Prozentzeichen nach Ziffer 0–9
2. französische «Paarungen» von Guillemets (vgl. Quelltext) – ähm, wohl nicht mehr in deutschsprachigen Wikis wegen »Verwechslung« mit »Buchdruck« oder nur « bei » Leerzeichen? Dann nur noch in ‹ französischschsprachigen › Wikis.

LG --PerfektesChaos 16:51, 18. Mai 2016 (CEST)

Vielen Dank, XanonymusX und PerfektesChaos für die weiterführenden Infos; manches ist leider noch Zukunftsmusik... --Wi-luc-ky (Diskussion) 17:12, 18. Mai 2016 (CEST)

Es gibt geschützte Leerzeichen nach « und vor » ? : ; ! %. Der Vorsichtshalber: Es gibt aber keinen Grund, nur für die Entfernung des unnötigen geschützen Leerzeichen einen Artikel zu bearbeiten. Der Umherirrende 19:38, 19. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 17:12, 18. Mai 2016 (CEST)

Vorlage:Galerie

Die genannte Vorlage wertet offenbar den Parameter „lang“ (für SVGs) nicht aus. Ich nahm an, Benutzer:Jochen2707 sei der Urheber und habe auf seiner Diskussionsseite ein Beispiel angelegt. Ich melde mich hier für den Fall, dass ich mit meiner Vermutung falsch liege oder hier jemand weiterhelfen kann. So oder so würde ich mich über eine Rückmeldung freuen.
Gruß, MagentaGreen (Diskussion) 12:00, 5. Apr. 2016 (CEST)

Beim Bearbeiten zwecks Besichtigung Deines Beispiels erhalte ich "Warning: Benutzer Diskussion:Jochen2707 is calling Vorlage:Galerie with more than one value for the "lang" parameter. Only the last value provided will be used."

Das ist richtig so, wenn mehr als ein "lang=" als Parameter in der Vorlage steht. Laut Hilfe:Galerie geht das, was Du willst, gar nicht in einer Galerie. Bastel doch einfach eine Wiki-Tabelle für Dein Beispiel. Be..anyone (Diskussion) 23:45, 6. Apr. 2016 (CEST)

Diese Duplicate-args-warning wird ja genau deshalb ausgegeben, weil das Script die Verwendung eines weiteren Parameters für das einzelne Bild nicht vorsieht, genau das möchte ich aber geändert haben. Der Text, der für jedes Bild separat festgelegt werden kann, ist quasi nur der erste und bisher einzige Parameter, der berücksichtigt wird. Außerdem unterscheiden sich die beiden Bausteine <gallery … und {{galerie … doch ganz erheblich. MagentaGreen (Diskussion) 10:14, 7. Apr. 2016 (CEST)

p.s.: Kann vielleicht helfen: Der Parameter „lang“ selbst darf nur Kleinbuchstaben und den Bindestrich enthalten.

Das ist nichts, was die Vorlage ändern kann. Dass ein (benannter) Parameter nur einmal definiert werden kann, ist tief in der Software verankert, und wird sicher nicht für die Galerie geändert. Aber ich sehe auch nicht den Bedarf dafür, solange der gleiche lang-Parameter bei allen Bildern angewandt werden kann. --mfb (Diskussion) 11:12, 7. Apr. 2016 (CEST)

Also die Meinung, der gleiche lang-Parameter würde bei allen Bildern angewandt werden können, lässt mich vermuten, dass Du das Beispiel nicht gelesen hast. Wieso sollte es nicht möglich sein, neben dem Text, das Vorhandensein eines weiteren Parameters abzufragen? Der Parameter „lang“ bestimmt, in welcher Sprache die SVG-Datei „ausgeführt“ wird - Vergleichbares gibt es in keinem anderen Grafikformat. MagentaGreen (Diskussion) 11:45, 7. Apr. 2016 (CEST)

Die gleiche Sprache für alle Bilder geht - ist derzeit nicht implementiert, kann man aber einbauen. Was du möchtest mit verschiedenen Sprachen, geht technisch nicht in der Form. Man könnte Parameter wie lang1= lang2= etc. einführen oder gar sämtliche Einbindungen der Vorlage überall an ein neues Format anpassen, aber beides wäre mehr als hässlich. --mfb (Diskussion) 14:47, 7. Apr. 2016 (CEST)

So ganz bin ich nicht überzeugt. Die einzelnen Bilder werden unter der Klasse "ImageGroupUnits" zusammengefasst und folgendermaßen abgearbeitet:

{{#if:{{{1|}}}|[[{{{1}}}… steht m. E. für Datei:BILD1.jpg|Beschreibung1 oder Datei:BILD1.jpg. Somit ist festgelegt, dass nur ein Parameter übergeben werden kann. Diese Klasse wird später im Script in ein Array umgesetzt; die einzelnen Datensätze werden dann, je nachdem, wo der Satzzeiger steht, (stark verkürzt) ein- und ausgeblendet. Aber trotzdem danke, ich werde halt die SVGs ohne SWITCH-Element als eigenständige Dateien erstellen; ist vielleicht die einfachere, wenn auch nicht elegantere Lösung. MagentaGreen (Diskussion) 15:13, 7. Apr. 2016 (CEST)

Unbenannte Parameter bekommen fortlaufende Nummern, 1 ist der erste Bildlink, 2 die erste Beschreibung, 3 der zweite Bildlink, 4 die zweite Beschreibung, ... - in dem Schema ist kein Platz dafür, jedem Bild eine eigene Sprache zuzuweisen. --mfb (Diskussion) 19:16, 7. Apr. 2016 (CEST)

Ich glaube, dass man zwischen zwei Dingen unterscheiden muss:

• den Parametern, die erhoben werden, und …
• … den Parametern, die ausgewertet werden.

(Nebenbei: innerhalb eines Arrays würde in jedem Fall der Zugriff auf einen nicht existenten Datensatz zu einem Fehler führen.)

Die Angelegenheit ist aber auch schon fast erledigt, weil ich die SVG-Dateien umgeschrieben habe. MagentaGreen (Diskussion) 22:50, 7. Apr. 2016 (CEST)

Themenartikel in der Oxford DNB

Hallo zusammen, bislang versuche ich vergeblich, die Vorlage:OxfordDNB bei einem Themenartikel zu verwenden: Justiciars of England (1154/5–1263); http://www.oxforddnb.com/view/theme/93180. Wie muss ich die ID der Themenseite (93180) in die Vorlage einbinden? Danke im Voraus! --TeleD (Diskussion) 12:39, 7. Apr. 2016 (CEST)

Für deinen Link (beachte die andere Struktur im Vergleich zu den Beispielen der Vorlage) will die Seite Logindaten, als Weblink ist sie damit ungeeignet. Als Einzelnachweis: Nicht die Vorlage verwenden. --mfb (Diskussion) 19:18, 7. Apr. 2016 (CEST)

Nummern der Einzelnachweise in Vorlage Zitat

Hallo, z. B. in diesem Art. hier werden die hochgestellten Nummern der Einzelnachweise in der Vorlage Zitat

„...“

im sichtbaren Text typographisch falsch vor die Abführungszeichen, anstatt danach gesetzt. Werden die < refs > danach gesetzt, rutschen sie uneingerückt auf die nächste Zeile. Dank für einen Reparaturhinweis sagt --Wi-luc-ky (Diskussion) 00:01, 20. Mai 2016 (CEST)

Dann sollte man den dafür vorgesehenen Parameter |ref= benutzen, siehe Kopiervorlagen Beispiel 2 --Liebe Grüße, Lómelinde Diskussion 07:17, 20. Mai 2016 (CEST)

{{Zitat | Text= | Autor= | Quelle= | ref=<ref></ref> }}

„Hör das Lied der letzten Begegnung. Völlig dunkel das Haus vor mir stand Nur im Schlafgemach, gelb, ohne Regung, haben gleichgültig Kerzen gebrannt.“

„Hör das Lied der letzten Begegnung. Völlig dunkel das Haus vor mir stand Nur im Schlafgemach, gelb, ohne Regung, haben gleichgültig Kerzen gebrannt.“ – Anna Achmatowa: Im Spiegelland – Ausgewählte Gedichte.

Sehr freundlich und immer hilfreich, Lómelinde, Danke, auch für den Link zu Bspp. und Grundlagen! Habe den Art. gleich gefixt. --Wi-luc-ky (Diskussion) 15:14, 20. Mai 2016 (CEST)

Prima, es freut mich wenn ich behilflich sein konnte. --Liebe Grüße, Lómelinde Diskussion 15:16, 20. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 15:14, 20. Mai 2016 (CEST)

Meta-Unterseiten

Da MB von dannen ist, könnte jetzt eigentlich ein Bot loslegen und die Kategorien von den Meta-Unterseiten auf die Doku-Seiten übertragen und anschließend LA stellen. Interwiki-Links räume ich zur Zeit auf. 88.65.124.55 23:45, 8. Apr. 2016 (CEST)

Aus diversen Gründen eine Schnapsidee.

• Es ist nicht Masche dieser Werkstatt, für sowas Bots zu beschäftigen; wir bauen Altfälle im Rahmen von Überarbeitungen zurück und bereinigen dabei auch Nebenprobleme und Altlasten.
• Petzerei.
• Erwartungsgemäß hatte „von dannen“ keine vier Tage gehalten.

--PerfektesChaos 09:57, 9. Apr. 2016 (CEST)

Vorlage:Grand-Tour-Platzierungen

Könnte man zu den Optionen DNF, WD, DSQ und DNS noch HD mit Legende HD = Zeitlimit überschritten einfügen? Danke!--Rik VII. my2cts   18:41, 15. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Rik VII. my2cts   14:52, 21. Mai 2016 (CEST)

Vorlage für Roller Coaster Database

Hallo zusammen,

Ich hätte gerne eine Vorlage um Links zur Roller Coaster Database (RCDB) zu generieren. So eine Vorlage gibt es schon in diversen Sprachen z.B. en:Template:RCDB. Wie geht man da vor? Lässt sich das irgendwie importieren? Vielleicht auch gleich en:Template:Cite RCDB?--Trockennasenaffe (Diskussion) 09:42, 4. Apr. 2016 (CEST)

Kann ich gern erstellen, die Vorlage:RCDB wurde allerdings schonmal (von XenonX3) gelöscht. –Queryzo ?! 12:35, 5. Apr. 2016 (CEST)

Das war mir nicht bekannt. Da die Vorlage damals ohne Löschdiskussion und mit mangelhafter Begründung gelöscht wurde, sehe ich da aber kein Problem--Trockennasenaffe (Diskussion) 13:16, 5. Apr. 2016 (CEST)

Vielleicht verrät uns Culturawiki, warum die Vorlage damals „Unsinn“ war?! –Queryzo ?! 13:48, 5. Apr. 2016 (CEST)

Du kannst doch schauen, was damals dort war, und bist nicht auf 3 Jahre alte Erinnerungen angewiesen. --mfb (Diskussion) 14:03, 5. Apr. 2016 (CEST)

Ja, klar, die Vorlage, allerdings keine Begründung, warum die Vorlage Unsinn ist/war. –Queryzo ?! 14:08, 5. Apr. 2016 (CEST)

Was stand denn in der Vorlage? --mfb (Diskussion) 15:34, 5. Apr. 2016 (CEST)

[http://www.rcdb.com/{{{1}}}.htm {{{2|{{{name|{{SEITENNAME}}}}}}}}] in der ''Roller Coaster DataBase'' –Queryzo ?! 15:40, 5. Apr. 2016 (CEST)

Es gibt jede menge solcher Datenbanklink-Vorlagen, daher verstehe ich nicht, wo das Problem mit dieser Vorlage ist. Desweiteren besteht mittlerweile die Möglichkeit die Vorlage um eine Wikidata-Anbindung zu erweitern, was die Nützlichkeit nochmals erhöhen dürfte.--Trockennasenaffe (Diskussion) 15:54, 5. Apr. 2016 (CEST)

RCDB erreicht die Kriterien nach WP:WEB wenn überhaupt nur sehr knapp, und so eine Vorlage, die eigentlich abgesehen von der Domain die ganze URL braucht, ist keine Erleichterung für normale Benutzer: Es gibt kaum was einfacheres als den Link direkt zu verwenden, bei einer Vorlage muss man immer erst nachsehen, wie die Parameter zu verwenden sind. Solange aus der URL nicht mehr herauszuholen ist, ist da kein Zusatznutzen durch eine weiterer Vorlage erkennbar. Kosten-Nutzenverhältnis für diese Vorlage sieht sehr ungünstig aus.  Frohes Schaffen — Boshomi ⌨   22:45, 5. Apr. 2016 (CEST)

Was meinst du mit abgesehen von der Domain die ganze URL? Man braucht nur die ID und das war es. Worin unterscheidet das sich von Vorlage:OFDb, Vorlage:Gleise in Serviceeinrichtungen oder vielen anderen Datenbankvorlagen? Auf den Vorteil, die ID für alle Sprachversionen automatisch von Wikidata ziehen zu lassen und so gar keinen Parameter mehr ausfüllen zu müssen bist du leider gar nicht eingegangen.--Trockennasenaffe (Diskussion) 12:34, 6. Apr. 2016 (CEST)

Mittelfristig wird es wohl darauf hinauslaufen, dass in vielen Fällen nur noch die Infobox Achterbahn in einen Artikel eingebunden werden muss und dann mit Hilfe der in Wikidata hinterlegten Informationen direkt ein Link auf den Datenbankeintrag generiert wird. Als Zwischenschritt hätte ich aber gerne erstmal die Vorlage. Wer sie nicht benutzen möchte muss das ja auch weiterhin nicht tun.--Trockennasenaffe (Diskussion) 12:39, 6. Apr. 2016 (CEST)

Dass wir Botikeln aus Wikidata zusammenbasteln ist hier sicher noch nicht konsensfähig, insbesondere da es sich dabei um Daten handelt die sich nicht ändern bzw. wenn sie sich wegen Neubaus der Anlge verändern, dann muss sowieso der Artikel von Hand angepasst werden. Wikidata eignet sich als Bot-Datensammlung ganz gut zum Faktenabgleich, der Vorteil von Wikipedia liegt in der manuellen Redaktion. Vermischt man dass erbt man die Nachteile beider Verfahren ohne wirkliche Vorteile. KISS-Prinzip  Frohes Schaffen — Boshomi ⌨   15:33, 6. Apr. 2016 (CEST)

Es geht nicht um Botikeln aus Wikidata zusammenbasteln sondern darum, dass Ausfüllen von immer gleichen Infoboxen nicht in allen Sprachversionen redundant erledigen zu müssen. Hier ist aber sicherlich nicht der Ort um eine neue Grundsatzdiskussion zu Wikidata loszutreten, aber ich will hier nur sagen, das viele das auch anders sehen als du. So wird dies z.B. schon durch Vorlage:IMDb genutzt, was prinzipiell durch das Meinungsbilder/Nutzung von Daten aus Wikidata im ANR legitimiert wurde.--Trockennasenaffe (Diskussion) 16:13, 6. Apr. 2016 (CEST)

Wobei man bei Vorlagen wie IMBb sinnvollerweise die Schlüsseln im eigenen Projekt behält, und wikidata zum Abgleich nützt. Macht man das nicht, wird das über lange Sicht sehr fehleranfällig, da hier zu viele Leute an zu vielen Stellen editieren, ohne eine Ahnung zu haben, auf welche Artikel sich da wie auswirkt (und da meine ich auch die freiwilligen Helfer auf IMDb selbst.) Frohes Schaffen — Boshomi ⌨   16:24, 6. Apr. 2016 (CEST)

Da würde ich so pauschal nicht sagen. Das steckt zwar noch alles etwas in den Kinderschuhen, aber prinzipiell bietet Wikidata sehr viel mächtigere Werkzeuge als die lokalen Wikipedias, um die Integrität von Aussagen automatisch zu prüfen. Es kann z.B. automatisch geprüft werden, ob ein Schlüssel das richtige Format hat, ob der daraus generierte Link gültig ist, und ob das Linkziel den selben Titel hat wie das zugehörige Wikidata-Item (Ist noch nicht komplett so umgesetzt, aber in Arbeit). Prinzipiell verspreche ich mir sogar eine Qualitätssteigerung dadurch, dass mehr kompetente Menschen aus anderen Ländern jetzt da drüber schauen, auch wenn das nicht jeder so sieht wie ich. Ich denke wir haben eher das Problem, dass über viele Dinge zu wenige Augen drüber schauen als umgekehrt. Das Verhältnis von Autoren zu Artikeln wird immer schlechter. Ich fürchte, wenn wir die Qualität halten wollen, können wir es uns nicht mehr ewig leisten, begrenzt verfügbare, menschliche Arbeitszeit in hohem Maße für redundante, monotone Copy & Paste und Wartungsarbeiten einzusetzen wenn sich das vermeiden lässt. Es geht mir hier jetzt auch nicht darum, momentan lokal vorhandene Daten auzulagern. Die Vorlagen sind alle so gestaltet, dass sie bei Vorhandensein von lokalen Daten diese bevorzugen. Es ist in jeder Vorlageneinbindung durch das Setzen von Parametern möglich, Wikidata lokal zu "überstimmen". Daten die aus Wikidata kommen werden immer klar als solche markiert, wie es das Meinungsbild fordert.--Trockennasenaffe (Diskussion) 17:35, 6. Apr. 2016 (CEST)

Dass Daten aus Wikidata immer so markiert werden, ist eher Wunschdenken. Ein paar wenige Vorlagen machen das, die meisten nicht. Wir hatten hier in der Vorlagenwerkstatt mal über geeignete Formate diskutiert (insbesondere für Datenbanklinks), aber ein vernünftiges Framework ist nicht entstanden. --mfb (Diskussion) 21:43, 6. Apr. 2016 (CEST)

Ihr kommt vom eigentlichen Thema ab. Auch wenn man zurzeit "alles zwischen Domain und .html" angewben muss, so ist niemasls klar, ob das so bleibt. Der Betreiber der Domain kann doch beispielsweise jederzeit alle Seiten in Unterordner verschieben, je nachdem, ob es eine Achterbahn oder eine angetriebene Bahn (gibt es auch in dieser DB) ist. Dann muss man nur die Vorlage ändern. Diese Flexiblität gegenüber URL-Änderungen ist der wichtigste Grund für derartige Datenbanklinks. Ergo ist die Vorlage sinnvoll. Der damalige SLA war pauschal und insoweit schlecht begründet. Die Datenbank ist nicht schlechter als andere in der WP. ÅñŧóñŜûŝî (Ð) 22:50, 6. Apr. 2016 (CEST)

Hier hat sich durch neuere Entwicklungen (Giftbotweblinksuche / WP:WLWBot) der Fokus aber recht deutlich verschoben, nur-URL-Änderungen lassen sich auf andere Weise flexibler und treffsicherer herstellen, wobei der Arbeitsaufwand sogar deutlich geringerer ist als bei Vorlagenänderungen. Wenn die Domain nich tausendfach eingebunden ist, und sich kein sinnvoller Linktext aus der URL generieren lässt, überwiegt der Nachteil einer Vorlage (Verkomplizierung des Quelltextes, Notwendigkeit die Doku der Vorlage zu lesen) deutlich, denn die Zeit die jeder einzelne Benutzer mit den Vorlagendokus verbringt, muss genauso berücksichtigt werden. Bei so einfachen Fällen wie hier, ist der Zeitverlust den so eine Vorlage genieriert deutlich höher als jeder denkbare Nutzen bei einer Pfadänderung. Frohes Schaffen — Boshomi ⌨   14:11, 8. Apr. 2016 (CEST)

Um Pfadänderungen geht es ja schon lange nicht mehr, in erster Linie geht um eine einheitliche Linkgestaltung. In zweiter Linie spielt der Datenabgleich mit Wikidata eine Rolle. –Queryzo ?! 14:25, 8. Apr. 2016 (CEST)

Verkomplizierung des Quelltextes? Notwendigkeit, die Doku der Vorlage zu lesen? Das sind keine unzumutbaren Verkomplizierungen. Der Umgang mit Vorlagen ist längst eine Notwendigkeit, wenn man in der WP nicht nur gelegentlich schreiben will. ÅñŧóñŜûŝî (Ð) 12:33, 10. Apr. 2016 (CEST)

Vorlage:Bot

Bei Angabe des Parameters "|Inaktiv=ja" sollte die Seite nach meinem Verständnis eigentlich in die Kategorie:Benutzer:Inaktiver Bot mit Flag einsortiert werden. Allerdings passiert das nicht, und mir ist nicht klar, welcher Mechanismus die Seiten zur Zeit in die Kategorie:Benutzer:Inaktiver Bot mit Flag einsortiert. Kann sich das jemand anschauen? 129.13.72.198 10:14, 8. Apr. 2016 (CEST)

Aktuell schaut die Vorlage:Bot/Kategorisierung unter Wikipedia:Bots/Liste der Bots/hat Flag und Wikipedia:Bots/Liste der Bots/inaktiv nach und setzt die Kategorien. --тнояsтеn ⇔ 10:32, 8. Apr. 2016 (CEST)

Die Liste wurde aber seit 2014 nicht mehr aktualisiert, entsprechend ist die Kategorie:Benutzer:Inaktiver Bot mit Flag nicht korrekt befüllt. 129.13.72.198 10:37, 8. Apr. 2016 (CEST)

Damit liegt aber kein technisches Problem vor, wofür die Werkstatt eine Lösung finden könnte, sondern ein Aktualistätsproblem der Liste. Die kannst auch Du korrigieren.--Mabschaaf 12:31, 8. Apr. 2016 (CEST)

Wie denn? 129.13.72.198 13:31, 8. Apr. 2016 (CEST)

Bei einzelnen Seiten hilft Nulledit. Generell weiss ich nicht, das kann lange dauern. –Be..anyone (talk) 14:40, 8. Apr. 2016 (CEST)

Nulledit hilft nur, wenn in der inaktiv-Liste Bots drin stehen und nicht in der Kategorie sind.

Die Liste kann man durch bearbeiten aktualisieren. Wie man aber die Liste am besten bekommt, weiß ich auch nicht. Der Umherirrende 15:00, 8. Apr. 2016 (CEST)

Dann hat aber die Kategorie:Benutzer:Inaktiver Bot mit Flag keinen Sinn, da Bots fehlen und genauso gut auch Bots falsch zugeordnet sein können. Man kann sie also auch löschen. 129.13.72.198 15:14, 8. Apr. 2016 (CEST)

Ein Abschnitt weiter oben steht, warum viele hier Wartungskategorien trotz Mängeln besser als andere Tricks finden, also kein Löschkandidat solange {{Bot}} (so wie die Vorlage z.Zt. funktioniert) benutzt wird. –Be..anyone (talk) 15:39, 8. Apr. 2016 (CEST)

Verstehst du überhaupt, um was es hier geht? Erstens funktioniert die Vorlage nicht, weil eine Untervorlage nicht korrekt ist. Zweitens ist Kategorie:Benutzer:Inaktiver Bot mit Flag keine Wartungskategorie, sondern eine Benutzerkategorie, wie man am Präfix Benutzer: erkennt. 129.13.72.198 15:56, 8. Apr. 2016 (CEST)

Bots sind Benutzer, im weitesten Sinn kategorisiert die Vorlage so wie {{Userbox}}. Ja, offenbar verstehe ich nicht, was Du willst. –Be..anyone (talk) 19:41, 8. Apr. 2016 (CEST)

It's a wiki, jeder kann die Aktualisierung übernehmen, oder den Botbetreiber fragen, ob er das wieder machen kann oder auch löschen, damit es dann irgendwann jemand anders wieder anlegt. It's a wiki. Der Umherirrende 19:49, 8. Apr. 2016 (CEST)

Siehe Kategorie-Löschantrag. –Be..anyone (talk) 07:24, 12. Apr. 2016 (CEST)

Vorlage_Diskussion:FormatDate#Jänner / Januar

Hinweis auf die dortige Diskussion. ÅñŧóñŜûŝî (Ð) 20:59, 1. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 07:51, 24. Mai 2016 (CEST)

Vorlage Infobox Militärischer Konflikt

Bürgerkrieg in Syrien
ständig aktualisierte Karte der Konfliktparteien
Von syrischer Regierung gehalten Von syrischer Opposition gehalten Von al-Nusra-Front (al-Kaida) gehalten Vom Islamischen Staat gehalten Von Kurden gehalten
Datum:	15. März 2011 - jetzt
Ort:	Syrien (mit überschwappen in die Nachbarländer)
Status:	andauernd
Text	Lokale Waffenruhe seit 27. Februar 2016
Derzeitige Situation:	(September 2015)
25 - 30 % (Land); ~ 65 % (Bevölkerung) von Regierungstruppen gehalten. 20 % (Land) von gemäßigten und islamistischen Rebellen gehalten. 35-45% (Land); 10-15% (Bevölkerung) von IS gehalten. 11,5-17% (Land) von Kurden gehalten.
Konfliktparteien

Kann mir bitte jemand erklären wie ich in einer Infobox 4 Spalten für Konfliktparteien einbauen kann? Oder ist es möglich die Vorlage "Militärischer Konflikt" so auszubauen, dass 4+ Konfliktparteien hinzugefügt werden können? Vielen Dank! (Diskussion) 23:29, 14. Apr. 2016 (CEST)

• Ich befürworte den Ausbau auf die mindestens doppelte Anzahl von Konfliktparteien.
  • Wenn hinten, weit, in der Türkei, Die Völker aufeinander schlagen.
  • Früher mal kämpfte A gegen B und fertig.
  • Heute drischt jeder auf jeden ein; es kämpft die syrische Regierung gegen den IS gegen die Regierungsgegner gegen die Kurden gegen die Türken gegen die Russen gegen die Irakis gegen die Hisbollah gegen Israel.
• Wie das mit dem Layout zu lösen ist, weiß ich nicht; es gäbe ein Breitenproblem im Design.
  • Ich verstand es bislang so, dass es zwei Spalten nebeneinander gibt, von denen die eine eine Koalition aus mehreren Parteien wäre, und die andere ebenfalls eine Koalition aus mehreren Parteien.
  • Wenn das wie im momentanen Bild oben untereinander aufgelistet wird, kann es auch zweistellig werden.

LG --PerfektesChaos 14:59, 15. Apr. 2016 (CEST)

Bitte auch die verschiedenen Diskussionen über Infoboxen auf Diskussion:Bürgerkrieg in Syrien beachten. --тнояsтеn ⇔ 15:32, 15. Apr. 2016 (CEST)

Hmmmh; da würde ich mich eher von dem Vorläufer „Militärischer Konflikt“ im Sinne einer Infobox rechts neben dem normalen Artikel lösen wollen und gemäß Krieg #Tendenzen seit 1991 zu anderen Darstellungsformen kommen.

• Die klassischen Kriege hatten zwei, vielleicht drei gegnerische Parteien; in der Infobox zwei Spalten nebeneinander.
• Die „neuzeitlichen bewaffneten Konflikte“ mit vielen unabhängigen Beteiligten müssten diese untereinander auflisten, im Sinne einer Infobox lediglich eine Zusammenfassung über Zeitraum, Beteiligte, Status, geschätzte Opferzahlen geben.
• Eine großformatige Karte wie oben kann nicht sinnvoll in eine Spalte rechts neben dem Text eingebaut werden. Das muss extra gehen, mit eigener Legende.

Es bedarf also eines neuen Typs an Infobox für Kriege neuen Typs.

• Und dann erstmal eines enzyklopädiegerechten Namens für die neue Infobox.

LG --PerfektesChaos 16:36, 15. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 07:52, 24. Mai 2016 (CEST)

Urlencode mit Bindestrich?

Hallo, für die Vorlage:Rockol.it bräuchte ich eine Möglichkeit, die Leerzeichen für die URL-Konstruktion durch Bindestriche zu ersetzen (Bsp.: Riccardo Fogli soll nach http://www.rockol.it/artista/Riccardo-Fogli oder /riccardo-fogli verlinken); bei den Urlencodes finde ich aber nur + und %20. Gibt es da eine Lösung (und ja, die Vorlage ist berechtigt, ich schreibe mittlerweile fast alle Musikerbiographien auf Basis dieser Quelle)? Gruß--XanonymusX (Diskussion) 21:41, 9. Mai 2016 (CEST)

Ist dafür wirklich eine Vorlage notwendig? Derzeit ist die Domain gerade mal 59 mal im ANR, nur die Hälfte davon wären überhaupt Vorlagentauglich. Bitte bedenke, dass jede Vorlage den Quelltext und die Wartung verkompliziert, und erst bei wirklich großen Mengen der Nutzen überwiegt. Bedenke, dass bei einer Vorlage jeder einzelne Benutzer erstmal in der Doku der Vorlage nachsehen muss, welche Parameter er benötigt, anstatt einfach intuitiv normale Links im Quelltext anzugeben. Ansonsten brauchst du LUA. Da noch andere Zeichen vorkommen die du auf sepezifische Weise umformen musst, wirst du auch einige weitere Funktionen (z.b. umformen diakritischer Zeichen) brauchen. Mein Rat, lass es derzeit einfach bleiben. Wenn mal 500 Verlinkungen zusammen sind, macht eine Vorlage Sinn. Frohes Schaffen — Boshomi ⌨   22:13, 9. Mai 2016 (CEST)

Dafür auch schon Lua? Oje. Ich setze den Weblink mittlerweile bei jedem von mir überarbeiteten IT-Artikel, aber gut, kann ich auch weiterhin als normalen Link, wenn es keine einfachere Lösung gibt.--XanonymusX (Diskussion) 00:25, 10. Mai 2016 (CEST)

Eigenlich sollte man alle neuen Vorlagen schon vom ersten Schritt an mit LUA beginnen und Wikitext-Vorlagen gleich ganz sein lassen. Davon unabhängig muss man schon versuchen nur solche Vorlagen zu erstellen, die tatsächlich einen deutlichen Vorteil für die Benutzer bringen, der die allgemeinen Nachteile jeder Vorlage (nicht intuitiv, Nachsehen in der Doku) deutlich ausgleicht. Für das Zielgenau Umstellen von URLs in großen Mengen haben wir auch Tools wie WP:WLWBot die zusammen mit WP:LT/giftbot/weblinksuche recht effizient einsetzbar sind. Für die Weblinkwartung bringt so eine Vorlage relativ wenig, verdoppelt oft sogar die Arbeit, da so eine Vorlage meist nur für den Abschnitt "Weblinks" taugt. Bei Quellenangaben sollte immer eine vollständige URL vorhanden sein, die normalerweise nicht volatil über Vorlagenänderungen ausgetauscht werden soll. Für Quellenangaben sind normale allgemeintaugliche Zitationsvorlagen (Internetquelle, Cite Web...) vorteilhafter.  Frohes Schaffen — Boshomi ⌨   21:21, 10. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 08:02, 24. Mai 2016 (CEST)

Infobox kaputt?

Hallo, ist das nur bei mir so oder ragt in Zecchino d’Oro die Vorlage:Infobox Fernsehsendung ziemlich weit über den rechten Rand hinaus? Kann grad keinen Grund entdecken.--XanonymusX (Diskussion) 20:44, 24. Mai 2016 (CEST)

Liegt an der Zeile | SEN = Programma Nazionale (jetzt [[Rai 1]]) - [[Eurovision]] - [[Mondovisione|Mondovision]], die nicht umgebrochen wird. Auch Tatort (Fernsehreihe) ist betroffen. --тнояsтеn ⇔ 21:00, 24. Mai 2016 (CEST)

(BK) Das ist nicht nur bei dir so und liegt an zwei Dingen:

1. Die Infobox besteht nicht nur aus einer Tabelle, sondern aus einer Tabelle, um die herum ein <div>-Element mit fester Breite width:300px gebaut ist. Dadurch wird das übliche flexible Layout von Tabellen deaktiviert: Bei einer Tabelle hätte width:300px die Bedeutung einer Mindestbreite, aber ein <div> mit width:300px ist wirklich immer exakt 300px groß; überbreiter Inhalt fließt rechts über.
2. Im HTML-Quelltext der allerletzten (untersten und rechtesten) Zelle der Tabelle steht folgendes:

   1959 auf Programma Nazionale (jetzt Rai 1) - Eurovision - Mondovision
   

   Durch die vielen   werden die dringend benötigten Umbruchstellen deaktiviert. Das ist seit dieser Vorlagenänderung der Fall.

Gruß --Entlinkt (Diskussion) 21:01, 24. Mai 2016 (CEST)

Wenn du das weist, dann kannst du das bestimmt auch reparieren. Genaueres klärst du m. E. am Besten mit deinem Adminkollegen Queryzo ab. Gruß von ÅñŧóñŜûŝî (Ð) 12:36, 26. Mai 2016 (CEST)

Nee, leider habe ich mir die Arbeitsweise der Vorlage {{Str replace}} niemals angesehen und kann das deshalb nicht reparieren (und will es auch gar nicht). Es ist aber klar, dass sie in der jetzigen Verwendungsweise viel mehr   einfügt, als beabsichtigt ist.

Vielleicht hilft diese Info ja jemandem weiter, der die Vorlage besser kennt und das Problem tatsächlich beheben möchte. Von mir wird es bei dieser kleinen Hilfestellung zum Debuggen bleiben. Gruß --Entlinkt (Diskussion) 12:48, 26. Mai 2016 (CEST)

@XanonymusX: Bug fixed! –Queryzo ?! 13:06, 26. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 22:00, 26. Mai 2016 (CEST)

Str replace wandelt Sonderzeichen um

Nach einer längeren Diskussion habe ich in der Vorlage {{Medienbox/Film und Fernsehen}}, die auch Grundlage für die {{Infobox Fernsehsendung}} ist, die Angabe von Sendern einer Formatierung per {{Str replace}} unterzogen: Sender mit  TV oder  Zahl erhalten ein geschütztes Leerzeichen aus Layoutgründen. Code:

{{Str replace|{{Str replace| {{sender_de}} |[%s]([0-9]+)| %1||ja}}|[%s]([Tt][Vv])| %1||ja}}

Nun kann man aber bei Tabaluga (Zeichentrickserie) sehen, dass anscheinend die Sonderzeichen in ihre HTML-Entsprechung umgewandelt werden, sodass HTML-Formatierung unwirksam werden und überlange Zeilen produzieren. Jemand eine Idee? –Queryzo ?! 11:37, 26. Mai 2016 (CEST)

Siehe auch zwei Abschnitte drüber …--XanonymusX (Diskussion) 12:22, 26. Mai 2016 (CEST)

Ah danke. Mal ein Test, das Tabaluga-Beispiel erzeugt folgendes:  ZDF<br />Folge 1–26/Staffel 1; <br />2001–2004 bei KiKA<br />Folge 27–78/Staffel 2–3  –Queryzo ?! 12:55, 26. Mai 2016 (CEST)

Bug fixed! –Queryzo ?! 13:04, 26. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: –Queryzo ?! 13:04, 26. Mai 2016 (CEST)

Störende Wirkungen von Wartungslinks in Vorlagen, insbesondere in span-Tags

Hallo,

dies ist jetzt keine unmittelbare Handlungsaufforderung, sondern mehr ein „Essay“ von mir, es würde mich aber freuen, wenn manche es auch so sehen:

Vor Jahren war es übliche Praxis, für allerhand Wartungs- und Analysezwecke versteckte Links in Vorlagen unterzubringen, nach dem folgenden Schema:

<span style="display:none">[[Vorlage:Infobox Hastenichgesehn/Wartung/megamäßig krasser Fehler]]</span>

Möglicherweise haben wir sogar noch Hilfeseiten, die dieses Vorgehen empfehlen, und ich bekenne mich schuldig, dem Vorbild damaliger Gepflogenheiten folgend einige solche Wartungslinks verbrochen zu haben.

Das Vorgehen mag gewisse Vorteile für Vorlagenprogrammierer haben, hat aber auch folgende Nachteile:

• Diese Links werden im HTML an jeden Leser ausgeliefert und kosten Bandbreite.
• Diese Links verschmutzen Spezial:Gewünschte Seiten bis zur Unbenutzbarkeit.
• style="display:none" ist eine reine Formatierungsanweisung und trägt keine Semantik. Nicht jede Anwendung wertet es aus, siehe diese schöne Liste von Google-Treffern und aktuell phab:T119702 (das sind aber bestimmt nicht alle Probleme dieser Art).
• Wenn diese Links als <span>-Elemente implementiert sind und auf einer eigenen Quelltextzeile und nicht innerhalb einer Tabelle, eines <div> oder eines anderen Block-Level-Elements stehen, erzeugt MediaWiki automatisch ein <p>-Element um den Link herum. Das ist in der Regel semantisch sinnvoll (wenn man anderer Meinung ist, ist es eben nicht zu ändern), aber leider haben <p>-Elemente standardmäßig Abstände (CSS-Eigenschaft margin), die als „Löcher“ im Artikel sichtbar werden können. Beachte, dass style="display:none" sich nur auf das <span> und nicht auf das automatisch drumherum erzeugte <p> bezieht.

Daher sollte meiner Meinung nach folgendes gelten:

• Beim Anlegen neuer Wartungslinks sollte nach Möglichkeit geschaut werden, dass diese tatsächlich abgearbeitet werden und nur für begrenzte Zeit in Artikeln verbleiben.
• Bei bestehenden, alten Wartungslinks sollte nach Möglichkeit geschaut werden, ob sie überhaupt noch jemand braucht.
• Wenn ein Wartungslink einmal wirklich gewünscht ist und nicht innerhalb eines sowieso vorhandenen Block-Level-Elements stehen kann, sollte zumindest darauf geachtet werden, dass es entgegen der alten Dokumentationen nicht in ein <span style="display:none">, sondern in ein <div style="display:none"> gewrappt wird. Dies vermeidet zwar nicht alle Probleme, aber zumindest einen Teil davon, nämlich die mit Bezug zu margin und phab:T119702.

Gruß --Entlinkt (Diskussion) 04:15, 8. Apr. 2016 (CEST)

Man kann die Probleme einfach dadurch lösen, dass man statt Wartungslinks einfach Wartungskategorien anlegt. Die sind sowieso einfacher zu warten und bieten mehr Möglichkeiten. 129.13.72.198 10:48, 8. Apr. 2016 (CEST)

+1

• Diese Praxis stammt aus den frühen Jahren.
  • Damals galten Wartungskats als teuer, waren verboten und nur für Artikel da.
• Zumindest diese Werkstatt verwendet seit längerer Zeit wohl nur noch Kategorie:Wikipedia:Vorlagenfehler für Neuentwicklungen und Überarbeitungen.
• Wartungskats können
  • auf Benutzer- und Redaktionsseiten mittels {{PAGESINCATEGORY:}} Hinweise auf kürzlich aufgetretene Fehler aufleuchten lassen;
  • eine Anleitung mitbekommen, wie dieser spezifische Fehler konkret ausgelöst wurde und was zur Behebung zu tun ist und was unterbleiben solle;
  • in Themenbereichen kategorisiert werden.

LG --PerfektesChaos 12:12, 8. Apr. 2016 (CEST)

+1 zu Wartungskategorien, allerdings werden dann einige Artikel sehr unschön untenrum. –Queryzo ?! 12:50, 8. Apr. 2016 (CEST)

Bei Wartungskategorien gab es schon des öfteren Probleme, wenn diese die meiste Zeit leer sind. Die Diskussionen um die leeren und oder roten Kategorien führte dann zur Einführung der Wartungslinks im Fehlerfall, wo es niemanden stört, wenn es dort rote Links gibt, bzw, die roten Links erst gar nicht auftreten. Exzessive Nutzung von roten Kategorien würde etwa die Kontrolle nach roten Kats im ANR (Etwa nach Import vom Artikel) unmöglich machen, da nur 2000 angezeigt werden, bei Wartungslinks gibt es solche Beschränkungen nicht.  Frohes Schaffen — Boshomi ⌨   13:41, 8. Apr. 2016 (CEST)

• Hier ist aber nicht von „roten“ (also undokumentierten, nicht beschriebenen und nicht kategorisierten) Kats die Rede, sondern von solchen, die eine Beschreibungsseite haben und auf die auch in der Vorlagendoku verlinkt wird und die kategorisiert sind.
• Wenn die ordnungsgemäß benannt und kategorisiert und beschrieben sind, dann gibt es da auch nix am diskutieren.
• Das Wesen aller Wartungskats ist es, dass sie perspektivisch leergearbeitet werden sollen. Das kann zuweilen etwas dauern, aber bei frisch angelegten und auf unmittelbare Fehler abzielenden ist das bald erreicht.
  • Dann kann sich unter einem Artikel auch nichts anhäufen, es sei denn, er steckt grad im Vollprogramm.
  • Im Übrigen sind sie für normale Leser eines enzyklopädischen Artikels nicht sichtbar.
• Die angeblich „niemanden störenden Wartungslinks“ stören aber durchaus – deshalb auch dieser Thread; und sie führen zu einem wirren und undurchschaubaren Dschungel und elendem Rumgepfusche.

VG --PerfektesChaos 13:55, 8. Apr. 2016 (CEST)

Untenrum ist unsichtbar für Leser und alle, die "hiddencat" nicht absichtlich auf sichtbar stellen. Dagegen sind display:none Tricks über zehn Jahre altes Gemurkel, CSS ist optional. –Be..anyone (talk) 14:03, 8. Apr. 2016 (CEST)

Betrifft auch die Anzeige des Ausschnitts in der Suche Beispiel. Der Umherirrende 14:58, 8. Apr. 2016 (CEST)

Also die angeblichen Nachteile kann ich im kontreten Fall nicht alle nachvollziehen:

• Das <p> mit dem folgenden halben Zeilenabstand (Löcher) konnte ich im Fließtext nicht finden, stellt sich die Frage unter welchen Bedingungen diese tatsächlich auftreten.
• Die Ausgabe von sinnlosen durch Suchmaschinen auffindbaren Text kann man durch ein "|&nbsp;" z.B.: [[Vorlage:FooBar/Wartungslink/Schwerer Fehler| ]] leicht eliminieren.
• Der Bandberitenverlust bei Kategorien ist exakt gleich groß, denn Wartungskats werden ebenfalls hidden ausgeliefert, hier ist kein Vorteil erkennbar.
• Bei Wartungskats entsteht jedenfalls ein zusätzlicher Arbeitsbedarf, da man zusätzlich noch die Kats anlegen und beschreiben muss, bei roten Wartungslinks entfällt das naturgemäß. Wartungslinks lassen sich ebenso einfach Pflegen wie Kats Beispiel siehe WP:WLWT mit der eingebunden Seite {{Spezial:Linkliste/Vorlage:Toter_Link/!...nourl}}. Die Probleme und Löschdiskussionen rund um Wartungskats, die nur im Fehlerfall befüllt werden, wurden erst vor wenigen Wochen entweder von Benutzer:Herzi Pinki oder Benutzer:Karl Gruber bei einem Wiener Treffen (Stammtisch oder WikiDienstag) erwähnt. Wartungslinks habe hier den Vorteil, dass sie keine Löschdiskussionen nach sich ziehen können. Frohes Schaffen — Boshomi ⌨   15:15, 8. Apr. 2016 (CEST)

Eine realistische Abarbeitung von größeren Wartungsfällen ist nur durch Verteilung an Portale möglich. Wie willst du Wartungslinks an Portale verteilen? Mit Wartungskategorien geht das ganz einfach. 129.13.72.198 15:19, 8. Apr. 2016 (CEST)

Eine Auslieferung an Portale ist in vielen Fällen erst gar nicht gewünscht. Wartungslinks und Wartungskats haben je nach Anwendungsfall spezielle Vorteile. Dort wo es sich um häufig auftretende und einfach behebbare Fehler handelt, sind Kats Tendenziell im Vorteil, dort wo es sich um spezifische oder schwer zu lösende Probleme handelt die schon mehr Erfahrung voraussetzen, sind versteckt Wartungslinks im Vorteil. Ich verwende je nach Anwendungsfall beide Variante, und bin froh, dass es beide Möglichkeiten gibt. Für spezielle Fälle verwende ich als zusätzliche dritte Variante noch die Vorlage {{WartungsURL}} die gerade in der Vorwoche bei der Abarbeitung der Vorlage:Tagesschau.de sich als sehr nützlich herausstellte.  Frohes Schaffen — Boshomi ⌨   15:50, 8. Apr. 2016 (CEST)

@Boshomi: Zu einigen deiner Punkte:

• Das <p> am Artikelanfang kannst du zum Beispiel im Artikel Psychologische Hochschule Berlin vorfinden und mit Tools wie Firebug auch sichtbar machen:

  <p>
  	<span style="display: none;"><a href="…">Vorlage:Infobox Hochschule/Logo fehlt</a></span>
  	<span style="display: none;"><a href="…">Vorlage:Infobox Hochschule/Mitarbeiter fehlt</a></span>
  </p>
  

  Bei solchem Code ist das <p> im theoretischen Sinne sichtbar und fällt nur deshalb in der Praxis nicht auf, weil sein margin in den jetzigen Skins zufälligerweise mit anderen kollabiert, das muss aber nicht immer so sein. Unabhängig von der Optik ist ein <p> ohne Textinhalt aber semantischer Unfug; in einem <p> erwartet man gerade sinnvollen Fließtext.
• Dir ist insoweit Recht zu geben, dass ein Leerzeichen als Linkbeschriftung auch hilft, die Nachteile etwas zu reduzieren. Bei vielen vorhandenen Wartungslinks wurde dies leider nicht verwendet (sondern stattdessen kryptische Texte oder gar keine Linkbeschriftung); möglicherweise deshalb, weil der Parser ein Leerzeichen als Linktext früher nicht akzeptiert hat.
• Der Bandbreitenverlust ist sicherlich sowieso kein weltbewegendes Problem, fällt aber komplett weg, wenn man uralte Wartungslinks, die eh kein Mensch mehr braucht, ersatzlos streicht. Er war auch nicht meine Hauptaussage, sondern meine Hauptaussage war, dass alle Leser völlig unsinniges Markup geliefert bekommen. Wartungskategorien stehen zumindest am Artikelende und sind deshalb kein völliger Unfug im Markup.

Alles in allem denke ich sowieso nicht, dass Wartungslinks so schnell völlig verschwinden werden, deshalb auch die Kennzeichnung als „Essay“ oben. Es wäre aber schon etwas gewonnen, wenn sie so erstellt werden, dass sie so wenig wie möglich stören. Dafür muss man die störenden Wirkungen aber kennen. Gruß --Entlinkt (Diskussion) 15:48, 8. Apr. 2016 (CEST)

Das Problem mit dem p-Tag fällt also dort an, wo zuvor kein Text erwarte wird, das span-Tag also außerhalb eines div-Tags erzeugt wird. Wenn der Wartungslink also an Stelle innerhalb eines Absatzes bzw befüllter Tabellenzeile erstellt wird, dann wird das Problem nicht schlagend. Üblicherweise sind davon also Infoboxen und Navi-Leisten betroffen, andere Vorlagen im Normalfall nicht.

Ich habe übrigens vor einigen Tagen darüber nachgedacht, ob man nicht eine Vorlage {{Wartungshinweis}} (plus Weiterleitung Vorlage:Error zwecks bessere Lesbarkeit in der Vorlagenprogrammierung) erstellen sollte. Mit der Abfrage nach einer Revisionsid könnte man bestimmte Fehler nur in der Vorschau sichtbar schalten (siehe die Spielerei in Spezial:Diff/153129260) , bestimmte Fehler könnte man nur für erfahren Benutzer sichtbar machen die die Option "Zeige Wartungskategorien" aktiviert haben, dazu würden noch Wartungskats oder Wartungslinks ausgegeben, je nach Wunsch. Frohes Schaffen — Boshomi ⌨   16:51, 8. Apr. 2016 (CEST)

@Boshomi: Wenn ich dich richtig verstehe, stimmt das mit dem <p> soweit. Um es nochmal anders und etwas präziser auszudrücken: MediaWiki besteht darauf, dass alle Kindelemente von #mw-content-text Block-Level-Elemente sind und erzeugt im Zweifelsfall automatisch <p>-Elemente drumherum, um dies sicherzustellen. Dieses Verhalten von MediaWiki ist meiner Meinung nach sinnvoll (und wäre selbst dann nicht zu ändern, wenn man es nicht sinnvoll fände).

Von dem <p>-Problem sind also nicht alle Wartungslinks betroffen (insbesondere nicht solche, die innerhalb eines <div>, einer Tabelle oder einer Liste stehen).

Darüber hinaus schließt die TextExtracts-Erweiterung derzeit pauschal alle <div>-Elemente und Tabellen aus (siehe hier), so dass ein <div> auch aus diesem Grund vorteilhaft ist (wobei man dazu sagen muss, dass man es als einen Bug der Erweiterung ansehen kann, dass sie display:none nicht beachtet, und sich das Verhalten der Erweiterung ändern kann).

Hierbei reden wir aber nur über ein ganz bestimmtes Problem von Wartungslinks; die Workarounds bzw. partiellen Lösungen ändern nichts daran, dass das gesamte Konzept eines Wartungslinks meiner Meinung nach broken by design ist und auch in Zukunft immer wieder neue Probleme ergeben wird, für die man immer wieder neue Workarounds suchen muss. Da es darüber aber wahrscheinlich so schnell keine Einigkeit geben wird, gibt es jetzt eben einen Thread über aktuell mehr oder weniger funktionierende Workarounds. ;-) --Entlinkt (Diskussion) 19:57, 8. Apr. 2016 (CEST)

Ich habe noch niemals etwas davon mitbekommen, dass eine ordnungsgemäß benannte und kategorisierte und beschriebene Wartungskat zur Löschung angestanden hätte, und ich halte das auch für eine frei erfundene Schutzbehauptung.

Wenn man natürlich bereits in Jammern und Wehklagen ausbricht, sobald von einer benachbarten Wartungskat die zwei Zeilen für Basis-Beschreibung und Kategorisierung mit C&P zu holen und anzupassen wären, dann sind berechtigte Beschwerden absehbar.

Die nicht-existenten Pseudo-Vorlagen-Linklisten-Hacks kann niemand daraufhin überwachen, ob sie zurzeit Treffer enthalten oder nicht. Deshalb werden sie auch nicht abgearbeitet oder nur mal durch großen Zufall, und auch deshalb hatten wir uns von diesem über ein Jahrzehnt alten Pfusch längst verabschiedet. Wir verunstalten unsere Seiten auch nicht mit lauter Phantasie-Markup nicht-existenter URL und kaputter Textelemente. Die Altvorderen hatten mal sowas veranstaltet und jede Menge Unsinn angerichtet, den zurückzubauen unendliche Mühen kostet.

Kategorien lassen sich heutzutage sogar beobachten hinsichtlich der enthaltenen Seiten; man bekommt ohne großen Aufwand auf der Beo sofort eine Mitteilung, sobald mit einer der einen interessierenden Vorlagen irgendeine Einbindung floppt.

VG --PerfektesChaos 16:26, 8. Apr. 2016 (CEST)

ich denke nicht, dass die erwähnten Personen da irgendwelchen Schutzbehauptungen aufgestellt haben, insbesondere da die Bemerkung aus einem ganz anderen Zusammenhang heraus fiel. Dass sich der Vorteil dank verbesserter Technik hin zu Kategorien verschoben hat, ist auch unbestritten. Dennoch denke ich, dass es nicht auf ungeteilte Zustimmung stößt, wenn man da große Mengen an Fehler-Kats anlegt, die die meiste Zeit leer sind. Ich erinnere mich noch recht gut, dass die leeren "Defekter Weblink Bot"-Tagesvorlagen recht schnell von anderen Benutzern gefunden und zur Löschung vorgeschlagen wurden. Das war in diesem Fall in Ordnung, mag aber an anderen Stellen nicht ganz konfliktfrei ablaufen.  Frohes Schaffen — Boshomi ⌨   17:11, 8. Apr. 2016 (CEST)

@Entlinkt: Was deinen Hinweis zum div und Boshomis Hinweis zum Leerzeichen angeht, habe ich diese nun beherzigt. Wenn ich sonst was tun kan, sagt Bescheid. –Queryzo ?! 16:56, 8. Apr. 2016 (CEST)

@Queryzo: Die Änderung sieht OK aus. Ein Style-Problem gab es in dem Fall nicht, da die Vorlage innerhalb einer Liste, also innerhalb eines Block-Level-Elements steht. (Das Style-Problem tritt nur bei Vorlagen auf, die nicht in ein Block-Level-Element gewrappt sind.) Allerdings führt die Änderung dazu, dass die Vorlage jetzt wirksam von der TextExtracts-Erweiterung ausgeschlossen, also nicht mehr von phab:T119702 betroffen ist. Gruß --Entlinkt (Diskussion) 19:17, 8. Apr. 2016 (CEST)

@Queryzo: besser wäre es hinter dem Pipe statt eines normalen Leerzeichen ein geschütztes zu setzten; Ich habe oberhalb übersehen, dass das nowiki das nbsp; dennoch in ein geschütztes Leerzeichen umwandelt. (Ich habe das jetzt für die Ansicht durch ein amp; escaped). Der Grund ist, dass ein entfernen des Leerzeichens sonst unerwartete Auswirkungen hätte, und mit &nbsp; der Quelltext besser lesbar bleibt. Frohes Schaffen — Boshomi ⌨   21:16, 8. Apr. 2016 (CEST)

Ich würde das exakt umgekehrt sehen und für ein normales (nicht geschütztes) Leerzeichen plädieren, da ein normales Leerzeichen auch dann unsichtbar bleibt, wenn display:none ausfällt (und das tut es in manchen Szenarien), während ein geschütztes Leerzeichen als zu großer Abstand sichtbar werden würde. --Entlinkt (Diskussion) 23:17, 8. Apr. 2016 (CEST)

@Entlinkt: Stimmt, bei einem normalen Leerzeichen wird ein Link erzeugt, der sich nur im a-Tag versteckt, aber es wird im Gegensatz zu einen geschützten Leerzeichen kein verlinkter Text zurückgegeben. Gut möglich, dass man diese Technik mit dieser unfallfreien Lösung |⁠]]⁠ auch an andere Stelle einsetzen kann. Das Zeichen U+2060 ist der Word-Joiner, der keine Breite hat, und keinen Zeilenumbruch verursacht. Der zweite Word-Joiner hat den Sinn, dass nicht unabsichtlich ein Link entstehen kann. Frohes Schaffen — Boshomi ⌨   00:02, 9. Apr. 2016 (CEST)

• @Schutzbehauptung: [4], [5] und [6].
• ich habe kein Problem mit einer Umstellung und kann das für ein paar Vorlagen, für die ich mich zuständig fühle, auch gerne machen. Solange die Funktionalität erhalten bleibt. Höhe, Berg, Pass, (Tal), (Gletscher), (Wasserfall), Gebirgsgruppe, See, (Insel), Schutzhütte, Tabellenzeilen im Kontext Denkmäler / Naturdenkmäler, etc.
  • ist das oben schon die komplette Anleitung oder wird das noch ausformuliert? Und die alte Empfehlung mit den Wartungslinks entfernt / relativiert. Es bräuchte auch klare Kriterien, wann Wartungslinks und wann Wartungskategorien zu verwenden sind.
• ich halte die Umstellung jetzt aber auch nicht für so dringend, dass man morgen mit der Arbeit beginnen müsste.
• die von mir angelegten Wartungskategorien (jetzt noch Wartungslinks) sind in der Regel nicht leer. Auch über einen langen Zeitraum hinweg. Sie helfen nur, immer wieder mal draufzuschauen. Es gibt etwa Falschtestfälle, die notwendigerweise einen Wartungslink/Wartungskat erzeugen müssen. Plausibilitätsprüfungen, die quasi Überprüfenswertes markieren, nicht notwendigerweise Falsches. Spezial:Linkliste/Vorlage:ISO Kat/Wartung/Autokat undefiniert etwa mosert über fehlende Kategorien im Geografiebaum (etwa Kategorie:Berg in San Marino, die Kategorien sollen aber erst angelegt werden, wenn genügend Substanz (Seiten) da ist). Manches schlägt aktuell auch im BNR und bei Infobox-Vorlagen an (lässt sich im Einzelfall ändern). Manchmal dokumentieren sie Datenfehler gegen einen externen Datenprovider, die solange bestehen, bis extern behoben. All diese Verwendungen kann man zwar inhaltlich diskutieren, aber der Fallback wäre dann in einigen Fällen der Wartungsrotlink.
• Sicher ist einiges davon aber auch obsolet (legacy) und kann ersatzlos gestrichen werden.
• Es muss klar sein, dass solche Wartungskategorien nicht nach dem übl(ich)en Verfahren gelöscht werden können, da die Einsortierung in eine gelöschte Wartungskategorie dann einen immer sichtbaren Rot-Eintrag erzeugt und die Lösung der Wartungsfälle nicht immer möglich ist. Ich habe keine Lust, die Notwenigkeit der Wartungskats in einer LD gegen gemischtes Publikum verteidigen zu müssen.
• Parameterumstellungen würde ich weiterhin mittels Wartungslinks machen, man braucht dann keine Kategorie anlegen und wieder löschen und bei ein paar Treffern ohnehin in ein paar Tagen erledigt. Dass derartige Arbeit geshared werden kann, glaube ich ohnehin nicht mehr. TMg's Auto-Formatter leistet bei so halb-automatischen Umstellungen gute Dienste.
• So oft kommt das auch nicht vor, aber ein Gutteil stammt von mir. Nehme also auch meinen Teil von Murks und Pfusch auf mich. :-( lg --Herzi Pinki (Diskussion) 21:50, 8. Apr. 2016 (CEST)

Ein paar mehr gibt es schon noch.--Mabschaaf 22:48, 8. Apr. 2016 (CEST)

Ich hatte mit dem Thread jetzt auch gar nicht die Intention, dass direkt alles umgestellt wird (was ob der schieren Masse auch sehr lange dauern würde), sondern nur die, vielleicht manche Leute ein kleines bisschen davon zu überzeugen, dass das Vorgehen grundsätzlich problematisch ist. Es scheint aktuell überhaupt keine wirklich zuverlässige Methode zu geben, dafür zu sorgen, dass etwas niemals und unter keinen Umständen sichtbar wird.

Eure Suchlinks oben sind allerdings viel zu brav. Man müsste schon auch den Fall berücksichtigen, dass zwischen dem <span> und dem style doppelte Leerzeichen, weitere Attribute usw. stehen. --Entlinkt (Diskussion) 23:17, 8. Apr. 2016 (CEST)

gut, so sind es 450.

Im Prinzip machen beide Vorgehen Gebrauch von der MediaWiki-SW, um Zustände, die nicht in Ordnung sind oder ev. nicht in Ordnung sind, mit Bordmitteln einfach zu finden. Auch eine Kat ist ein Workaround, um einen ungewünschten Zustand zu erkennen. Alternative Vorgehen könnten Bots sein (nicht sofort aktuell) oder ein Vorgehen, wie es Aka mit seinen Klammern usw. macht (auch hier nicht aktuell). Dafür braucht es dann weder Wartungskats. noch Wartungslinks. Was könnte man noch über das API machen? Das ist jedenfalls alles komplizierter und braucht mehr den Techie. Alternativ könnten wir auch mehr dafür sorgen, dass Fehlzustände in z.B. Infoboxen unmittelbar beim Editieren aufpoppen (dicke rote Meldung) und ev. sogar das Speichern unterbunden werden kann (nur echte Fehler mit leicht zu eruierenden Daten, trotzdem vermutlich aufstandsgefährdet). Wir könnten (wie der GiftBot) schiefe Zustände auch auf der zugehörigen Disk protokollieren (ginge vermtl. mit Lua) und die Disk und nicht den Artikel kategorisieren. Damit wären die Meldungen, wie auch immer sie aussehen, aus dem ANR draußen. Die Vollständigkeit und Konsistenz von Daten könnte, hüstel, auf WD sichergestellt werden, Infoboxen würden die Daten nur verwenden. Weitere? lg --Herzi Pinki (Diskussion) 23:41, 8. Apr. 2016 (CEST)

Ein erster Schritt könnte ein Fehlerzustands-Vorlagen-Interface für die Mehrzahl der Fälle sein, dann könnte man dahinter immer die Implementierung zentral austauschen und müsste nicht viele Vorlagen, die dieses Fehlerzustands-Vorlagen-Interface verwenden, angreifen. --Herzi Pinki (Diskussion) 23:46, 8. Apr. 2016 (CEST)

Egal ob Kategorie oder versteckter Link beide sind praktisch Zeitgleich mit dem Edit auffindbar, und in den Vorlagen relativ leicht umsetzbar. Da können Bots und andere Techniken kaum mithalten. Ich denke ich versuche mich im Lauf der Woche mal der oben erwähnten Error/Wartungshinweis-Vorlage. Diese Vorlage kann dann im ersten Schritt alle bisherigen Varianten plus nur in der Vorschau sichtbare Warnhinweise und Fehlermeldungen. Auch eine Variante mit span class="metadata", die nur für Personen sichtbar ist, die sich Wartungskats anzeigen lassen. Mit Hilfe so einer Vorlage kann man sich zentral entscheiden (oder nicht entscheiden), was nun die beste Lösung sei. Jedenfalls wird die von PerfektesChaos monierte mangelnde zentrale Auffindbarkeit von Wartungslinks damit repariert.  Frohes Schaffen — Boshomi ⌨   00:20, 9. Apr. 2016 (CEST)

Es braucht dann vielleicht zu der protokollierenden Vorlage eine zweite Vorlage an der Stelle der Wartungskategorie / Suche nach den Wartungsrotlinks. Die beiden Vorlagen müssen ja in ihrer Impl. zusammenpassen. lg --Herzi Pinki (Diskussion) 00:37, 9. Apr. 2016 (CEST)

Könnte man die hier gewonnenen Erkenntnisse unter WP:Vorlagenprogrammierung festhalten? M.E. ist das Vorgehen dazu ohnehin noch nirgends dokumentiert. –Queryzo ?! 10:17, 9. Apr. 2016 (CEST)

Nein; es gibt bis auf Weiteres ein grundsätzliches Problem mit dem projektgerechten Einsatz von Vorlagen, ihrer Zwecke, sachgerechten Verwendung, Namensgebung und Wartung. Dazu müsste etwas wie Richtlinien und Standards gesetzt werden, jedoch gibt es in diesem Bereich erheblich mehr Querulanten und Dummschwätzer als Leute, die Ahnung davon hätten und dann auch noch Nerven, entsprechende Seiten anzulegen und zu entwickeln. Also bleibt es beim schriftlich nicht fixierten Status quo. --PerfektesChaos 10:25, 9. Apr. 2016 (CEST)

Was es die Flutung der Liste gewünschter Seiten angeht: Hier könnte man die Zielseiten vom Typ

Vorlage:Infobox Hastenichgesehn/Wartung/megamäßig krasser Fehler einfach anlegen, z. B. als Weiterleitung auf die Oberseite Vorlage:Infobox Hastenichgesehn/Wartung oder eine zentrale Hilfeseite. Ein Baustein wäre auch denkbar. ÅñŧóñŜûŝî (Ð) 12:43, 9. Apr. 2016 (CEST)

@Antonsusi: Die zügige Anlage der Weiterleitungen

• Vorlage:Commonscat/Wartung/P 2 fehlt, P 1 ungleich Lemma
• Vorlage:Defekter Weblink Bot/Wartung/LinkGiftBot
• Vorlage:Infobox Fußballspieler/Wartung/Bild fehlt

hat nun aber den Nachteil, dass diese sehr oft vorkommenden Wartungslinks aus dem Blickfeld geraten, bevor die Diskussion zu einem klaren Ergebnis gekommen ist.

@Allgemein: Ich hätte noch eine Idee (aber bitte nicht direkt umsetzen, weil es wirklich nur eine ganz vage Idee ist und zuerst abgeklärt werden sollte, ob sie überhaupt praktikabel ist):

Man ersetzt den Einbau der „angeblich unsichtbaren“ Wartungslinks durch die Einbindung einer leeren Vorlage, d. h. das Konstrukt aus dem Startposting wird ersetzt durch

{{Infobox Hastenichgesehn/Wartung/megamäßig krasser Fehler}}

und zugleich wird die Seite „Vorlage:Infobox Hastenichgesehn/Wartung/megamäßig krasser Fehler“ als „leere“ Vorlage angelegt, d. h. als Vorlage, die bei der Einbindung nichts ausgibt (sondern beispielsweise nur einen in <noinclude> gewrappten Baustein enthält).

Auf diese Weise könnte man weiterhin (fast wie bisher) die Backlinks nutzen, aber ohne, dass das Markup der Artikel in irgendeiner Weise beeinträchtigt wird. Das wäre ein Kompromiss, mit dem auf die Argumente derjenigen eingegangen wird, die sich vor Löschanträgen auf Wartungskategorien fürchten. (Es könnte dann natürlich stattdessen Löschanträge auf die Untervorlagen geben, aber die Gefahr würde ich als eher gering einschätzen.) --Entlinkt (Diskussion) 16:30, 9. Apr. 2016 (CEST)

PS: Ein Nebeneffekt dieser Variante wäre, dass die „Fehlervorlage“ beim Bearbeiten in der Liste eingebundener Vorlagen sichtbar wird. Das kann man wahrscheinlich sowohl als Vorteil wie auch als Nachteil sehen. Außerdem wäre die „Fehlervorlage“ ein Ansatzpunkt für Vandalismus, was man aber wahrscheinlich durch Sichtungskrempel in den Griff bekommen kann. --Entlinkt (Diskussion) 16:45, 9. Apr. 2016 (CEST)

Die Geschichte mit den angeblichen Löschungen von Wartungskats, die nun zu befürchten wären, ist ein Ammen- bis Schauermärchen.

• Ich schrieb oben: „dass eine ordnungsgemäß benannte und kategorisierte und beschriebene Wartungskat“ und zuvor: „Diese Praxis stammt aus den frühen Jahren. Damals galten Wartungskats als teuer, waren verboten und nur für Artikel da.“
• Als Gegenbeweise wurden zwei Fälle aus dem Jahr 2009 vorgetragen:
  • Kategorie:Portal:Berge und Gebirge
  • Kategorie:Geographische Lage gewünscht
• Da ist das auch kein Wunder; das zweite ist enzyklopädische Kategorie für Artikelthemen und die erste hat heute wohl eine andere Verwendung.
  • Wohl erst irgendwann später hatte man die frühere Regel „Kategorien darf es nur für Artikel nach enzyklopädischen Gesichtspunkten geben“ geändert in die Stammkategorien; hier mit Titeln beginnend mit Wikipedia: und ansonsten auch Vorlage: usw.
  • Womöglich gab es die Zweige nach Namensraum sogar schon; dann hatte man erst recht die falschen Namen gewählt. Der erste Fall sagt nun überhaupt nichts über den Wartungszweck aus.
  • Alle in Rede stehenden Wartungskats haben einen Namen beginnend mit

    Kategorie:Wikipedia:Vorlagenfehler/

  • Auf derartig benannte und eindeutig als Wartungskats erkennbare Kategorien hat es noch nie einen inhaltlichen LA gegeben; selbst wenn irgendein Scherzbold ihn stellen würde, hätte er bei korrekter Zuordnung der Kat keinerlei Aussichten.

Wartungskats ermöglichen, sich jeden Neuzugang unmittelbar auf der Beo anzeigen zu lassen, und mittels {{PAGESINCATEGORY:}} Alarme auf Benutzer- und Redaktionsseiten anspringen zu lassen, und bei thematischen Interessen per CatScan etc. die Wartungskat mit dem eigenen Interessengebiet zu schneiden und gezielt abzuarbeiten.

• Diesem System das längst eingemottete Pseudo-Vorlagen-Linklisten-System als Parallelsystem zu pushen, womöglich zu einer existierenden Wartungskat außerdem eine Pseudovorlage zu basteln, macht das veraltete Gewurschtel völlig undurchschaubar, bringt niemandem etwas und kostet dann wieder etliche Jahre, bis alle diese Hacks wieder zurückgebaut wurden. Der ANR ist noch voll mit solchen Super-Ideen.

VG --PerfektesChaos 17:25, 9. Apr. 2016 (CEST)

Störende Wirkungen von Wartungslinks, Teil 2

@Entlinkt: Die Weiterleitungen waren als Test gedacht. Da aber sowieso kein Update des Caches erfolgt, kann man sie auch wieder löschen. ÅñŧóñŜûŝî (Ð) 18:12, 9. Apr. 2016 (CEST)

Ich habe die Weiterleitungen wieder gelöscht. Die Diskussion verläuft ja sehr konstruktiv, also sollten wir abwarten, ob es hier ein umfassendes Ergebnis gibt und nicht eilig neue Workarounds etablieren, die nur einen klitzekleinen Teil der Probleme abdecken. --Entlinkt (Diskussion) 18:57, 9. Apr. 2016 (CEST)

@PerfektesChaos: Die Hauptmotivation die ich für die neue Untervorlage habe, war die Anzeige von Fehlermeldungen, so dass mittlere Mängel Fehlermeldungen nur in der Vorschau sichtbar machen, bzw mit der span class="metadata" nur jener Benutzergruppe ausliefert, von denen man annehmen kann, dass sie diese auch sehen (und bearbeiten) wollen. Welches System (Wartungslinks oder Wartungskats) zukünfitig verwendet wird, sehe ich emotionslos. Ich sehe natürlich den Vorteil eines einheitlichen Systems, bin mir aber bewusst, dass das auch ein Braking-Change für eine Menge Benutzer bedeutet, und nicht alle betroffenen Benutzer warten mit Freude darauf. Es nützt uns nichts ein einheitliches System auf die Schnelle zu erzwingen, wenn dann bestimmte Arbeiten nicht mehr gemacht werden. Die Nachteile der Wartungslinks gegenüber Wartungskategorien sind dann auch nicht so groß, dass man die Probleme nicht durch Boardmitteln lösen kann, sodass keine Notwendigkeit besteht, dass man über Nacht vereinheitlicht.

Zwischen Wartungskats und Wartungslinks gibt es einen entscheidenenden Unterschied: Wartungskats müssen immer zuvor auf Vorrat angelegt werden, da sonst ein sichtbarer Rotlink oder ein unerwünschter Link auf eine WP-Kategorie im Artikel entsteht. Wartungslinks lassen sich im Gegensatz dazu auch dynamisch erstellen. Mit der API oder Quarry lässt sich das dann auch ganz gut abfragen. Diese Methode dynamischer Wartungslinks ist für Leute die mit Scripts arbeiten recht nützlich, wenn etwa Vorlagen bearbeitet werden, die vielfach in einem einzigen Artikel vorkommen, und nur ein geringer Teil tatsächlich angepasst/aktualisiert/bearbeitet werden muss. Frohes Schaffen — Boshomi ⌨   19:34, 9. Apr. 2016 (CEST)

@Boshomi: Da ich nun schon zum zweiten Mal class="metadata" im Verlauf dieser Diskussion lese:

Ich habe ehrlich gesagt völlig den Überblick verloren, wofür das momentan benutzt wird, aber gedacht war es eigentlich mal für Hilfe:Personendaten. Es scheint sich mittlerweile zu einem Selbstläufer entwickelt zu haben, dass man das für sonstwelche Zwecke benutzt. Leider muss ich ehrlicherweise zugeben, dass ich daran nicht ganz unschuldig bin, da ich einige der heutigen Verwendungen durch Edits in MediaWiki:Gadget-Personendaten.css erst möglich gemacht habe, ohne vorauszusehen, was da kommt.

Deshalb meine Meinung zu dem Plan: Ich halte es für äußerst bedenklich, ein Framework für die Vorlagenwartung auf der Grundlage des Personendaten-Gadgets aufzubauen, da es inhaltlich überhaupt nicht passt. Während die GND + sonstwelche Normdaten aus dem Bibliotheksbereich sowie Denkmallisten noch halbwegs passen, passt ein allgemeines Vorlagenfehler-Framework wirklich überhaupt nicht.

Jedem, der class="metadata" benutzt, egal wofür, sollte klar sein, dass die Ausblendung in MediaWiki:Common.css sowie MediaWiki:Mobile.css erfolgt und daher in vielen Fällen völlig unwirksam ist, weil bei Weitem nicht jede Anwendung, die Wikipedia-Artikel auswertet, diese CSS-Dateien beachtet. Ausblendungen aus diesen Dateien sind sogar noch problematischer als solche per Inline-CSS. Darüber hinaus hat sich auch herausgestellt, dass der Klassenname class="metadata" problematisch ist (Dokumentation hierzu in MediaWiki:Common.css).

Ich bin übrigens gerade in diesem Moment zufälligerweise dabei, eine unsinnige Verwendung von class="metadata" aus der Wikipedia zu entfernen, und das ist im Gegensatz zum Einfügen eine ziemlich frustrierende Arbeit. Gruß --Entlinkt (Diskussion) 20:08, 9. Apr. 2016 (CEST)

Der Use-Case der umgesetzt werden sollte: Derzeit werden viel mittelschwere Fehler beinhart mit der Klasse "error" ausgeliefert. Das sieht recht unschön aus, und ich sah schon Beispiele wo so ein fetter roter Text seeehr im Artikel stand, oft in Fällen, wo erst nachträglich die Fehlerauslösung in eine Vorlage hineingepackt wurde, die Fehler aber nicht abgearbeitet wurden.

Ziel ist es also mittelschwere Vorlagenfehler, die einen Artikel nicht komplett zerlegen nur für erfahrene Benutzer sichtbar zu machen, und zwar an der Stelle wo der Fehler entsteht. (nur anhand der Wartungskategorie zu erraten, wo der Fehler herkommt ist oft schwierig)

Wenn das Ziel erreicht wird, indem eine neue css-Klasse geschaffen wird, die man extra in den persönlichen Einstellungen aktivieren muss, wäre mir das auch recht. "verbose" wäre der erste Begriff der mir für den Namen der potentiellen neuen Klasse als erstes in den Kopf kam. class="metadata" wäre nur eine Zwischenlösung, bis besseres bereit steht. Eine Klasse die sich nur über common.js aktiviern lässt würde ich aber vom Bauchgefühl her ablehnen, da das zu wenige Benutzer aktivieren würden. Frohes Schaffen — Boshomi ⌨   20:59, 9. Apr. 2016 (CEST)

@Boshomi: Ich glaube, die „offizielle“ Linie lautet: Es gibt keinerlei, egal wie und für wen auch immer, „versteckte“ Inhalte in Artikeln. Alle Benutzer der Wikipedia sehen – zumindest in Artikeln – genau dasselbe. Alles, was davon abweicht, wäre ein lokaler Hack, der in Szenarien zu brechen droht, die schwer vorauszusehen sind. Wie vermeidet man das Brechen? Indem man mit solchen Hacks gar nicht erst anfängt.

Leider haben wir aus früheren Zeiten solche Hacks und werden die, die wir haben, auch nicht so leicht wieder los. Ich sag’s aber direkt: Mir gefällt der von dir beschriebene neue Use-Case überhaupt nicht und zumindest ich werde ihn wegen schlechter Erfahrungen mit ähnlichen Dingen in keiner Form unterstützen.

Ich sehe hier sogar ein spezifisch für die dewiki-Community virulentes Problem, das andere Communitys nicht haben – die englische Wikipedia hat zum Beispiel meines Wissens überhaupt kein Pendant zum Personendaten-Gadget und kommt trotzdem klar. Warum sollten wir das dann brauchen?

Wenn in einer Vorlage eine Änderung gemacht wurde, die zu knallroten Fehlern in Artikeln führt und dort nicht nachgearbeitet wurde, dann ist das schlecht und muss irgendwie gefixt werden. Dafür braucht man aber keine neuen Techniken für „versteckte“ Inhalte in Artikeln, sondern es ist ein wunderbarer Use-Case für eine (ggf. nur temporär vorhandene) Wartungskategorie.

Falls zufällig jemand wissen möchte, was ich gerade mache: Ich arbeite gerade in einer Infobox Fehler ab, die mittels Personendaten-Gadget ausgeblendet waren und sechs Jahre lang nicht abgearbeitet wurden. Meine persönlicher Schluss daraus lautet: Nie wieder sowas. --Entlinkt (Diskussion) 21:12, 9. Apr. 2016 (CEST)

Kann man da helfen? ÅñŧóñŜûŝî (Ð) 12:40, 10. Apr. 2016 (CEST)

Nein, bloß nicht, ist außerdem schon abgeschlossen. --Entlinkt (Diskussion) 13:18, 10. Apr. 2016 (CEST)

Nein, bloß nicht? So schlimm bin ich auch wieder nicht. Zumindest bei Anleitung durch einen erfahrenen Admin nicht... ;-) ÅñŧóñŜûŝî (Ð) 22:47, 10. Apr. 2016 (CEST)

Wenn wir hier keinen Konsens bzw. kein klares Ergebnis haben, können wir den Abschnitt auch erstmal ohne Ergebnis archivieren; ein Umbau der Wartungslinks wäre ohnehin eine längerfristige Baustelle.

Die Wartungslinks sind allerdings auch nur ein Teilaspekt eines größeren Problems im Umgang mit (vermeintlich, tatsächlich aber nicht wirklich) per display:none „versteckten“ Produkten der Vorlagenprogrammierung. Ich habe zu dem allgemeineren Problem ein paar Dinge unter Benutzer:Entlinkt/display:none aufgeschrieben; es wäre schön, wenn in Zukunft in der Vorlagenprogrammierung verstärkt darauf geachtet wird, dass man wirklich saubere Lösungen sucht und dass nicht (insbesondere nicht aus bloßer Bequemlichkeit) die Verwendung problematischer Techniken einreißt, wie es bei den Wartungslinks geschehen ist. Gruß --Entlinkt (Diskussion) 20:21, 10. Apr. 2016 (CEST)

Hm, ehrlich gesagt habe ich jetzt gerade erst entdeckt, dass wir unter Hilfe:Infoboxen#Automatische Prüfung von Infoboxen-Parametern ja sogar schon seit 9 Jahren eine „offizielle“ Dokumentation für Wartungslinks haben. Die ehemals für einen ganz anderen Zweck gedachte Seite besteht sogar überwiegend daraus. Bisher ging ich davon aus, dass Wartungslinks ein größtenteils undokumentierter Hack mit nur beiläufigen Erwähnungen in Dokumentationen seien.

Die dort gelieferte Rechtfertigung ergibt aber meiner Meinung nach wenig Sinn, da es in dem Uralt-Meinungsbild von 2007 um enzyklopädisch-inhaltliche Kategorisierungen durch Vorlagen ging und nicht um Wartungskategorien. Enzyklopädisch-inhaltliche Kategorisierungen durch Vorlagen sind in der Tat auch heute noch umstritten, allerdings haben sich größtenteils die Befürworter durchgesetzt. Das Schlüsselwort __HIDDENCAT__ existiert allerdings erst seit Februar 2008, weshalb das Meinungsbild nichts damit zu tun haben kann. Versteckte Kategorien werden vermutlich sogar fast ausschließlich durch Vorlagen befüllt.

Darüber hinaus geht der Text auf der Hilfeseite überhaupt nicht auf die Beeinträchtigung des Markups von Artikeln durch Wartungslinks ein und schlägt sogar eine besonders beeinträchtigende Variante vor:

• Falsches Tabellen-Markup, das nur durch foster parenting an irgendeiner Stelle des Parsers wieder korrigiert wird
• Dadurch ein <span>-Element auf oberster Ebene des Artikels, sogar noch vor der Infobox-Tabelle
• Offener Linktext

Da müsste man mal ordentlich aufräumen und angemessen auf die Nachteile eingehen. --Entlinkt (Diskussion) 04:49, 15. Apr. 2016 (CEST)

Poskarte durch andere Karte ersetzen (Gemeinde in Frankreich)

Im Artikel Mamoudzou würde ich gerne die aufgrund der Koordinaten und ISO 31666-2-Angabe automatisch eingebundene svg-Positionskarte ersetzen durch die Karte file:Mamoudzou.png. Ich habe in der Vorlage:Infobox Gemeinde in Frankreich aber keine Möglichkeit gefunden, die Poskarte zu unterdrücken, ebensowenig einen Parameter für die Einbindung einer alternativen Karte (der Parameter image ist schon belegt durch ein Foto, und das soll auch so bleiben). Bei einer Gemeinde mit flächenhafter Ausdehnung ist es zumindest im vorliegenden Maßstab unpassend, wenn ein roter Punkt auf die svg-Karte gepflanzt wird, und die flächenmäßige Ausdehnung der Karte auch nicht annähernd zu erkennen ist.--Ratzer (Diskussion) 09:31, 15. Apr. 2016 (CEST)

Ich bitte bei dieser recht harmlos (als simple Implementierungsaufforderung) daherkommenden Anfrage folgendes zu bedenken: Frankreich gliedert sich in über 35.000 Gemeinden. Dem roten Punkt auf der Karte liegt eine präzise Definition zugrunde, die für jede einzelne der 35.000 Gemeinden einheitlich ist, nämlich:

Longitude en degré, minute, seconde (Greenwich) du chef-lieu (avec signe – éventuellement)

(Quellenangabe, Datenfeld LONGI_DMS auf S. 4)

Diese Präzision und Einheitlichkeit würde durch die angefragte Änderung für einen relativ willkürlich ausgewählten Teil Frankreichs gebrochen werden. Die bisherige Unmöglichkeit individueller Karten ist eine bewusste Entscheidung gewesen; Karten mit Gemeindegrenzen haben wir in den Listenartikeln nach Departement. Gruß --Entlinkt (Diskussion) 15:33, 15. Apr. 2016 (CEST)

PS: Evtl. liegt der Anfrage auch bloß das Problem zugrunde, dass der Vorlage:Positionskarte Mayotte nach wie vor überhaupt keine „echte“ Positionskarte, sondern nur eine „Notlösung“ zugrundeliegt, da schlicht und einfach noch keine „echte“ Positionskarte für Mayotte erstellt wurde. Eine „echte“ Positionskarte hat laut Wikipedia:Kartenwerkstatt/Positionskarten#Arbeitsgrundlage die internen Grenzen der nächsttieferen administrativen Ebene und hätte deshalb in diesem Fall Gemeindegrenzen. Gruß --Entlinkt (Diskussion) 15:56, 15. Apr. 2016 (CEST)

PPS: Wir haben übrigens auch ein OpenStreetMap-Gadget (das grünliche Dingens an der Koordinate oben rechts, standardmäßig aktiviert für alle Benutzer). Wenn man da draufklickt, bekommt man eine Karte mit hervorgehobenem Gemeindegebiet angezeigt, und das funktioniert sogar in allen 35.000 französischen Gemeindeartikeln. --Entlinkt (Diskussion) 06:16, 16. Apr. 2016 (CEST)

Anderer Vorschlag, Galerie, guck's Dir mal an. –Be..anyone 💩 09:39, 16. Apr. 2016 (CEST)

• 
• 
• 

WikiProjekt Vorlagen/Werkstatt/Archiv 2016/2 (Mayotte)

Lage der Gemeinde Mamoudzou auf Mayotte

Da brauchen wir nicht lange rumreden bzw. rumschreiben. Mein Grundgedanke war, dass die erste Karte informativer ist als die Poskarte auf Basis der SVG- (zweiten) Karte. Und es ist schon bemerkt worden, dass letztere an fehlenden Gemeindegrenzen krankt, wie sie auf der dritten Karte zu finden wären. Auch wenn die erste Karte keinen Maßstabbalken hat. Gleiches gilt nicht nur für Mamoudzou, sondern für alle 13 Gemeinden Mayottes. Aber wenn die Einheitlichkeit der Präsentation aller 35.000 französischen Gemeinden höher wiegt, dann belassen wir die i-boxen wie sie sind. Bei den Mayotte-Gemeinden werde ich dann eben die Gemeinden-Flächenkarten im Stil der ersten Karte jeweils zusätzlich in die Gemeindeartikel stecken.--Ratzer (Diskussion) 13:46, 16. Apr. 2016 (CEST)

Es braucht in keinen einzigen der – nebenbei bemerkt nicht 13, sondern 17 (13 ist die Anzahl der Kantone) – Gemeindeartikel eine zusätzliche Karte reingesteckt zu werden, da bereits ausreichend Kartenmaterial in Mayotte#Verwaltung, Liste der Gemeinden in Mayotte, über Gadgets und sonstwo vorhanden ist. Es spricht aber auch nicht wirklich viel dagegen, da ein inhaltlicher Ausbau der Artikel (mit Text und so) realistischerweise eh kaum zu erwarten ist und die Artikel über die Zeit erfahrungsgemäß sowieso der Überbebilderung (+ wahlweise noch Auffüllung mit statistischen Tabellen) anheimfallen würden.

Tatsächlich sinnvoll (und nicht nur „zu tolerieren, weil eh unvermeidbar“) wäre es aber meiner Meinung nach, für Vorlage:Positionskarte Mayotte eine Karte zu erstellen, die den unter Wikipedia:Kartenwerkstatt/Positionskarten#Arbeitsgrundlage dargelegten Qualitätsstandards entspricht. Ich werde das allerdings nicht machen, da die Doppelbekartung der Artikel bereits angekündigt und in Vollzug ist. Gruß --Entlinkt (Diskussion) 14:03, 16. Apr. 2016 (CEST)

Bitte um Prüfung

Kann bitte mal jemand schauen, ob ich das so richtig angepasst habe. Das hat über die Einbindung von kabardinisch Тэрч einen indirekten Fehler in Artikel Terek erzeugt. Daran schließt sich die Frage an, ob jemand irgendie den defekten Link im Artikel anpassen kann, der dort wohl über die Vorlage:GSE eingebunden wird. Ich weiß nicht einmal wie man da einen Totlink korrekt markieren könnte. --Liebe Grüße, Lómelinde Diskussion 15:54, 27. Mai 2016 (CEST)

Du hast es in der Wirkung erstmal genau richtig gemacht; ich habe die includerei noch ein wenig funktioneller gestaltet. LG --PerfektesChaos 16:18, 27. Mai 2016 (CEST)

Dankeschön. --Liebe Grüße, Lómelinde Diskussion 16:21, 27. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 08:47, 28. Mai 2016 (CEST)

Einbindung von Weiterleitungen als Elemente in Navileisten

Hallo, bei einer kürzlich erstellten Navileiste werden die ersten drei Elemente verdeckt mit Lemmas verbunden, die zu Weiterleitungen führen. Das führt zum Problem, dass diese Elemente in den jeweiligen Artikeln, wo die Navileiste eingestellt worden ist, nicht schwarz hervorgehoben werden. Nun gäbe es zwar die schnelle Lösung, die verdeckten Lemmas auf die direkten Zielartikel umzuschreiben, doch soll hier wenn möglich aus Gründen der Einheitlichkeit und Erkennbarkeit eben die jetzige Notation bevorzugt werden. Die Frage ist nun, a) warum die Vorlage diese Weiterleitungen in den Elemente-Artikeln nicht anzeigt und b) ob die Vorlage so geändert werden könnte, dass auch bei Weiterleitungen der gewünschte Effekt eintritt? Gruß und Dank von --Wi-luc-ky (Diskussion) 23:44, 27. Mai 2016 (CEST)

Nicht sinnvoll. Es werden nur direkte Links schwarz und fett gemacht, und die Seiten haben keine Ahnung, dass die Links zu Weiterleitungen zu sich selbst führen (Wikipedia:VWS). Man könnte da einen riesigen Overhead einbauen mit neuen Parametern und viel Vorlagenlogik, aber das ist hier nicht sinnvoll. Wo liegt das Problem bei einer direkten Verlinkung? --mfb (Diskussion) 13:20, 28. Mai 2016 (CEST)

Danke für die Erläuterungen, mfb, die auf einen derzeit nicht zu rechtfertigenden Aufwand für eine Änderung der Vorlage hindeuten. Die Direktverlinkung würde beim Herüberfahren mit der Mouse ein Pop-up der durch die historische Entwicklung bedingt veränderten Namen der Elemente anzeigen, z. B. statt Gnadenkirche Zur Heiligen Dreifaltigkeit heute Maria Rosenkranz (Kamienna Góra); statt Gnadenkirche (Hirschberg) heute Kreuzerhöhungskirche (Jelenia Góra) usw. Der Gesamtzusammenhang, dass es sich um Gnadenkirchen handelt, sollte also noch einmal im Pop-up erscheinen; andernfalls schien es mir undeutlicher zu sein. Aber vielleicht hat es ja auch einen Vorzug, wenn gleich der heutige Name resp. Artikelname erscheint. Klar ist mir jedenfalls – auch für künftige Navileisten –, dass bis auf Weiteres nur direkt verlinkt werden kann, und ich werde es in meinem Bsp. auf die entsprechenden Lemmata ändern. Vielen Dank! --Wi-luc-ky (Diskussion) 14:49, 28. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 14:49, 28. Mai 2016 (CEST)

Infobox Hochschule

In der Seitenvorschau (Hovercard beta, beim hovern über Artikellink) zum Artikel Pädagogische Hochschule Luzern sehe ich eine Fehlermeldung der Infobox anstatt die Einleitung des Artikels. Kann mit jemand geschwind den Grund für diesen Fehler erklären? --grim (Diskussion) 13:19, 1. Apr. 2016 (CEST)

Tritt der Fehler noch auf? --Leyo 16:50, 27. Mai 2016 (CEST)

Ja, kann man auch sehr leicht reproduzieren. Es reicht, das Beta-Feature „Hovercards“ zu aktivieren und den Mauszeiger über den Link Pädagogische Hochschule Luzern zu halten.

Ursache: #Störende Wirkungen von Wartungslinks in Vorlagen, insbesondere in span-Tags. Gruß --Entlinkt (Diskussion) 16:57, 27. Mai 2016 (CEST)

Ich habe jetzt mal einen Workaround in die Vorlage eingebaut, so dass das Problem der Wartungslinks zwar leider vorerst weiterhin besteht, aber etwas weniger sichtbar sein sollte.

Speziell für diese Vorlage hat das Problem es übrigens sogar bis in den Phabricator geschafft, siehe phab:T109867. Das Problem liegt wirklich in der Tatsache begründet, dass man immer noch unbedingt „unsichtbare“ Links in den Vorlagen haben will, deren „Unsichtbarkeit“ aber nicht zu gewährleisten ist. Wir sollten endlich davon wegkommen. --Entlinkt (Diskussion) 01:14, 30. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Entlinkt (Diskussion) 01:14, 30. Mai 2016 (CEST)

Navigationsleiste Deklination

Hallo, ich stellte gerade fest, daß die Vorlage:Navigationsleiste Deklination in verschiedenen Artikel ein unterschiedliches Aussehen hat. In einigen Artikeln sind die Aufzählungspunkte linksbündig während der Rest zentriert ist, in anderen Artikeln ist alles zentriert. Purgen half nicht, ein Nulledit auch nicht, ein richtiger Edit auch nicht. Kann bitte mal jemand schauen, was da los ist? Gruß --Schniggendiller Diskussion 23:14, 26. Mai 2016 (CEST)

In Chromium tritt das Problem nicht auf, dort sind die Aufzählungspunkte in allen Artikeln konsistent linksbündig. Daher nehme ich mal an, dass du Firefox benutzt. Dort kann ich das Problem reproduzieren.

Das ist schon sehr merkwürdig. Wie auf dieser Seite dargestellt, ist laut CSS 2.1 die linksbündige Darstellung standardkonform. Deshalb, und weil die Darstellung in Firefox inkonsistent ist, würde ich mal sagen, dass das ein Firefox-Bug ist. (Auf der Seite ist von einem IE-Bug die Rede, aber das schließt ja nicht aus, dass Firefox den Bug auch hat.)

Gruß --Entlinkt (Diskussion) 02:38, 27. Mai 2016 (CEST)

PS: https://bugzilla.mozilla.org/show_bug.cgi?id=25291. --Entlinkt (Diskussion) 03:01, 27. Mai 2016 (CEST)

In Safari stehen sie auch konsistent links (was schon irgendwie schräg aussieht).--XanonymusX (Diskussion) 10:32, 27. Mai 2016 (CEST)

Ja, das sieht sehr schräg aus, ist aber wohl standardkonform für den jetzigen Code. Ich denke, dass der Firefox-Bug deshalb seit 16 Jahren nicht gefixt wird, weil die Konstellation wegen des schrägen Aussehens sehr selten vorkommt. Wahrscheinlich sollte die Leiste umgestaltet werden.

Möglichkeit 1: Die Aufzählungspunkte an den Text kleben.

Deklination der deutschen Sprache (deutsche Deklination)

Kasus (Fall):  Nominativ | Genitiv | Dativ | Akkusativ

Numerus (Zahl):  Singular (Einzahl) | Plural (Mehrzahl)

• Pluralis Auctoris (Autorenplural, Autorenmehrzahl) | Pluralis Majestatis | Pluralis Modestiae (Pluralis Modestatis, Bescheidenheitsplural, Bescheidenheitsmehrzahl) | Sortenplural (Artenplural)
• Kollektivum (Sammelname, Sammelbegriff, Sammelbezeichnung) | Singularetantum (Singularwort) | Pluraletantum (Pluralwort)

Genus (Geschlecht)

• Epikoinon (Epicönum)

Möglichkeit 2: Den Text linksbündig ausrichten.

Deklination der deutschen Sprache (deutsche Deklination)

Kasus (Fall):  Nominativ | Genitiv | Dativ | Akkusativ

Numerus (Zahl):  Singular (Einzahl) | Plural (Mehrzahl)

• Pluralis Auctoris (Autorenplural, Autorenmehrzahl) | Pluralis Majestatis | Pluralis Modestiae (Pluralis Modestatis, Bescheidenheitsplural, Bescheidenheitsmehrzahl) | Sortenplural (Artenplural)
• Kollektivum (Sammelname, Sammelbegriff, Sammelbezeichnung) | Singularetantum (Singularwort) | Pluraletantum (Pluralwort)

Genus (Geschlecht)

• Epikoinon (Epicönum)

Gruß --Entlinkt (Diskussion) 11:58, 27. Mai 2016 (CEST)

Ich verstehen auch noch gar nicht, was die Aufzählungsliste da überhaupt soll. Die Listenpunkte sind doch eigentlich das, was jeweils zwischen | steht, oder? --nenntmichruhigip (Diskussion) 13:57, 27. Mai 2016 (CEST)

Ich ehrlich gesagt auch nicht. Ich würde mal vermuten, dass damit irgendeine Hierarchie ausgedrückt werden soll. Zum Beispiel beim Numerus sind Singular und Plural wohl sowas wie die „Hauptkategorien“ (die jeder kennt), und die anderen Einträge sollen irgendwie untergeordnet erscheinen. Intuitiv verständlich finde ich das Ganze allerdings nicht. --Entlinkt (Diskussion) 14:01, 27. Mai 2016 (CEST)

Ich glaube, das ist ein IE-Fehler/Besonderheit, da ich auch an anderen Stellen schon Aufzählungszeichen linksbünding mit mittigem Text gesehen habe. Der Umherirrende 14:25, 27. Mai 2016 (CEST)

Ich nehme an, dass du eine einigermaßen aktuelle IE-Version verwendest?

Die linksbündige Darstellung tritt in aktuellen IE-Versionen und wohl allen Versionen von Chrome und Safari auf und ist standardkonform (wenn auch hässlich). Die (falsche) nicht-linksbündige Darstellung trat laut dieser Seite im IE 8 noch auf, tritt im Firefox auch heute noch auf und ist laut dieser Seite schon zu Netscape-Zeiten so gewesen. Der Fehler liegt hier also wirklich bei Firefox (ist aber wohl eher esoterischer Natur, weil die standardkonforme Darstellung so hässlich ist, dass Autoren wahrscheinlich fast nie absichtlich solchen Code schreiben). Gruß --Entlinkt (Diskussion) 14:39, 27. Mai 2016 (CEST)

Ja, IE11 ist der aktuellste. Interessant, dass das optisch bessere Ergebnis (subjektiv) nicht standardkonform und daher ein Bug ist. Der Umherirrende 17:51, 27. Mai 2016 (CEST)

Das ist schon ein ziemlicher Grenzfall in der Spezifikation, da ein Autor wahrscheinlich nur selten auf die Idee kommt, den Text einer Liste absichtlich zu zentrieren, weil IMHO beide Darstellungen nicht wirklich gut aussehen. Bei uns tritt die Konstellation ja auch nicht absichtlich auf, sondern nur deshalb, weil Navileisten eben standardmäßig zentriert sind. Außerhalb unseres Navileisten-Kontextes würde man wahrscheinlich einfach sagen, dass eine Liste nicht zentriert sein soll.
In CSS 2.1 ist die Spezifikation allerdings ziemlich eindeutig: “The marker box is outside the principal block box.”
In CSS 3 ist das Ganze übrigens sehr viel komplizierter, vor allem wegen der Schreibrichtung. --Entlinkt (Diskussion) 18:17, 27. Mai 2016 (CEST)

Ich habe die Aufzählungspunkte entfernt und versucht, die drei Bereiche anders optisch voneinander abzugrenzen. --84.130.138.117 19:41, 27. Mai 2016 (CEST)

Daß ich mal so einen Uralt-Fehler finde … (Ich hatte ja vermutet, daß es ein simpler Syntax-Fehler ist.)
Ich denke, die Darstellung ohne Aufzählungspunkte ist die beste. Ich danke euch! Gruß --Schniggendiller Diskussion 00:13, 31. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Schniggendiller Diskussion 00:13, 31. Mai 2016 (CEST)

Vorlage:Mehrere Bilder

Hallo, gibt man bei der Vorlage:Mehrere Bilder bei „Fußzeile“ keinen Wert ein, öffnet sich neuerdings nicht der Hintergrundrahmen, der sonst die Bilder umschließt. So wie beim Artikel Frankfurt am Main sieht das nicht schön aus. Ist hier eine Störung o.ä. aufgetreten? Denn bisher war der Hintergrundrahmen auch ohne Nennung einer Fußzeile vorhanden. Gruß--Kramer96 (Diskussion) 17:11, 17. Apr. 2016 (CEST)

Die Vorlage verwendet MediaWiki-interne CSS-Klassen, um das Aussehen bestimmter „Standard-Elemente“ mit „Nicht-Standard-Mitteln“ zu simulieren. Das ist grundsätzlich nicht die schlaueste Idee, weil man Softwareänderungen immer nachziehen muss (und natürlich wird bei Softwareänderungen nicht damit gerechnet, dass es solche Verwendungen gibt).

Meiner Meinung nach ist das hier beschriebene Problem durch die Softwareänderung phab:rMW2964c2799f0c19ac4c765f025a2998a0f3baeff0 zustande gekommen, konkret durch die weggefallene Regel div.thumbinner { overflow: hidden; }. Hintergrundinfo: Die Anweisung overflow: hidden erzeugte einen Blockformatierungskontext, der dafür sorgte, dass Floats automatisch umschlossen wurden und jetzt weggefallen ist. Gruß --Entlinkt (Diskussion) 18:09, 17. Apr. 2016 (CEST)

Die Vorlage ist seit 2012 unverändert, kann es was mit den Müll-Galerien zu tun haben? Chrome ist früher mal ungepflegt ausgerastet, wenn Vollpfosten mit mehr als 100% Breite rum-vandalierenbasteln, vielleicht spinnt Chrome bei sowas immer noch. –Be..anyone 💩 18:16, 17. Apr. 2016 (CEST)

Hallo,Problem ist auch bei FF45.0.2, als abhlfe habe ich erst mal {{Absat}} eingefügt--Vielen Dank und Grüße Woelle ffm (Diskussion) 19:13, 17. Apr. 2016 (CEST)

Das Problem liegt nicht am Browser, sondern wahlweise am MediaWiki-CSS oder an dem CSS der Vorlage. Die (derzeit unerwünschte) Darstellung in Browsern ist absolut standardkonform. Gruß --Entlinkt (Diskussion) 19:17, 17. Apr. 2016 (CEST)

Sollte man die Vorlage nicht eher als Tabelle realisieren und dabei alle Attribute explizit angeben? ÅñŧóñŜûŝî (Ð) 22:39, 17. Apr. 2016 (CEST)

Es ist keine Tabelle, also sollte man es nicht als Tabelle realisieren. --nenntmichruhigip (Diskussion) 11:22, 19. Apr. 2016 (CEST)

Umwandlung wissenschaftlicher Namen in den des Artikellemmas

Für eine Liste der Gehölzer im Botanischen Garten der Universität Wien suche ich eine Vorlage, die den wissenschaftlichen Namen von Pflanzen in den im deutschsprachigen Raum verwendeten Namen umwandelt, der dann dem Artikellemma entsprechen sollte. Beispielsweise würde die Vorlage Quercus robur erhalten und Stieleiche zurückgeben. Theoretisch sollte das auch über Wikidata gehen, da das Label dort für Pflanzen immer dem wissenschaftlichen Namen entspricht und der de-wp-Artikel verlinkt ist. Versteh nur noch nicht ganz, wie die Interwikilinks in das Wikidata-Item eingebunden sind. LG, --Braveheart ^{Welcome to Project Mayhem} 22:35, 19. Apr. 2016 (CEST)

Gute Frage, ich kann nur sagen, dass {{commonscat}} dabei eine Rolle spielen könnte, was aber bei Deinem Problem nicht direkt hilft. –Be..anyone 💩 23:02, 19. Apr. 2016 (CEST)

Vorlage:Taxobox

Gibt es hier die Möglichkeit ein noinclude für andere Namensräume insbesondere den BNR zu setzen? Konkret um
{{DISPLAYTITLE:{{#invoke:Vorlage:Taxobox|createItalicDisplayTitle|{{{Taxon_WissName|}}}|{{PAGENAME}}}}}}
für Artikelentwürfe unwirksam zu machen? Oder müsste man das an einer anderen Stelle tun? --Liebe Grüße, Lómelinde Diskussion 17:25, 27. Mai 2016 (CEST)

Genau das fiel mir heute auch schon auf.

Ja, sollte einer der Werkstattmechaniker umsetzen.

Bislang waren die Fehlwürfe im BNR usw. stumm gewesen, aber seit heute landen die alle in der Kategorie:Wikipedia:Seite mit ungültigem SEITENTITEL‎, was die damaligen Vorlagenschreiber nicht wissen konnten.

Der SEITENTITEL‎ kann nur im ANR funktionieren, weil ihm überall anders der Namensraum fehlt.

LG --PerfektesChaos 17:30, 27. Mai 2016 (CEST)

Wie sieht es aus, kann das jemand anpassen oder geht das nicht? --Liebe Grüße, Lómelinde Diskussion 07:25, 30. Mai 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Lómelinde 21:04, 1. Jun. 2016 (CEST)

Merkwürdiges Verhalten

Ein Merkwürdiges Verhalten beobachte ich unter Wuppertal#Religionen (Difflink). Dort hatte ich die Tortengrafik (Vorlage:Graph:Chart) ersetzt, in der Vorschau sieht alles gut aus. Nach dem Speichern ist die Grafik komplett schwarz. Wer weis Rat? --Atamari (Diskussion) 16:05, 1. Jun. 2016 (CEST)

ohne	mit Purple,Yellow,Green,Aqua,Gray	mit Hexfarbwerten
Hier fehlt eine Grafik, die leider im Moment aus technischen Gründen nicht angezeigt werden kann. Wir arbeiten daran!	Hier fehlt eine Grafik, die leider im Moment aus technischen Gründen nicht angezeigt werden kann. Wir arbeiten daran!	Hier fehlt eine Grafik, die leider im Moment aus technischen Gründen nicht angezeigt werden kann. Wir arbeiten daran!

Hast du es mal ohne Farben versucht? Das gelb blendet, habe mal gold genommen, mal schauen wie es nach dem Speichern aussieht. --Liebe Grüße, Lómelinde Diskussion 18:32, 1. Jun. 2016 (CEST)

@Atamari, blau ist auch zu grell und grau zu dunkel. So? --Liebe Grüße, Lómelinde Diskussion 18:37, 1. Jun. 2016 (CEST)

Primär wollte ich die gleichen Farben nehmen wie das Vorbild, wollte keinen Regenbogen daraus machen. In der Vorschau sieht alles gut aus, beim speichern wurde alles schwarz (genauso hier). Wenn das klappt, kann man die Zahlen aktualisieren oder anderes schöne machen. --Atamari (Diskussion) 18:54, 1. Jun. 2016 (CEST)

Wir stellen aber schon mal fest: die CSS-Farbnamen funktionieren nicht, man muss (irgendwie) die Hexfarbwerte nehmen. --Atamari (Diskussion) 18:56, 1. Jun. 2016 (CEST)

Weiß ich, nicht da musst du mal Mps fragen. Der kennt sich damit besser aus als ich, ich kann immer nur probieren. Möglicherweise hängt es ja auch mit dem als defekt kategorisierten Modul:Graph/WorldMap-iso2.json zusammen. --Liebe Grüße, Lómelinde Diskussion 19:13, 1. Jun. 2016 (CEST)

Hallo, CSS-Farbnamen funktionieren, allerdings hätten sie klein geschrieben werden müssen. Ich habe den Code dahingehend abgeändert, dass er das jetzt automatisch macht. --Mps、かみまみた^Disk. 23:41, 1. Jun. 2016 (CEST)

Aha, daran lag es. Ich habe die Namen per C&P aus der Tabelle entnommen. Aber jetzt macht nun die Tortengrafik das gleiche wie die statische Grafik. Wer will (und die Daten hat) kann die Werte nun aktualisieren. --Atamari (Diskussion) 00:01, 2. Jun. 2016 (CEST)

erl. --Atamari (Diskussion) 00:01, 2. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Wiegels „…“ 00:53, 2. Jun. 2016 (CEST)

Vorlage aus en Wikipedia übernehmen

In der englischen Wikipedia gibt es eine Vorlage, die ich hier vermisse, und zwar en:Template:Interlanguage_link. Meine Fragen:

• Kann man Vorlagen von dort verwenden bzw. einfach kopieren?
• Durch den Syntax blicke ich überhaupt nicht durch, d.h. ich müsste da wohl erstmal viel herumprobieren (Oder mag mir jemand helfen? :), Kann man Vorlagen irgendwo in seinem Benutzerraum testen?
• Braucht man eine Erlaubnis/Meinungsbild etc. Bevor man eine Vorlage anlegt.

Danke. arved (Diskussion) 15:48, 2. Jun. 2016 (CEST)

1. Es ist klug und weise von dir, hier erstmal nachzufragen.
2. Zu der genannten Vorlage im speziellen: Deren Wirkung entspricht nicht hiesigen Standards; siehe WP:V#Verlinkung auf Seiten außerhalb des Artikelnamensraums. Deshalb gibt es sie hier nicht.
3. In seinem Benutzerraum testen: Geht jederzeit, einfach den vollständigen Namen zwischen die Klammern setzen. Siehe Hilfe:Seiten einbinden.
4. Zu „Erlaubnis/Meinungsbild etc. Bevor man eine Vorlage anlegt“, „Kann man Vorlagen von dort verwenden bzw. einfach kopieren“.
   • Ginge theoretisch alles, wenn man sich auskennt und die richtigen Sachen richtig macht.
   • Projektweit einzusetzende allgemeine Vorlagen:
     • Wir sind seit 15 Jahren im Geschäft.
     • Du kannst davon ausgehen, dass alles, was wirklich gebraucht wird, auch schon vorhanden ist und du es bloß noch nicht gefunden hast.
     • Wenn es das wirklich noch nicht gibt, dann haben wir da entweder eine offene Baustelle oder diese Art von Programmierung ist ausdrücklich unerwünscht.
     • Auch wie man die neue Vorlage sinnvoll nennen sollte, wäre ggf. zu erfragen.
   • Fachspezifische Vorlagen:
     • Kann sein, dass du die unbürokratisch mal eben anlegen kannst.
     • Wenn es schon 15 Navigationsleisten zu Sportwagenherstellern gibt, aber du hast 5 Autos ohne Navigationsleiste, dann ist es wahrscheinlich okay, das genauso wie bei den vorhandenen zu machen.
     • Vorsicht mit Infoboxen; wenn es zu Personen, Büchern oder Kirchen keine Infobox gibt, hat das möglicherweise einen Grund.
   • Einfach hier nachfragen.

LG --PerfektesChaos 16:27, 2. Jun. 2016 (CEST)

Erstmal Danke für Deine Antwort. Ich hatte mir schon gedacht dass es einen Grund gibt, warum es diese Vorlage nicht gibt. Schade, ich finde es sehr praktisch, wenn ich besonders bei Listen neben einem Rotlink schnell auf die Englische Version klicken kann. Eine Idee waere die Vorlage:Wikidata stattdessen zu verwenden. Leider hat diese keinen Parameter mit dem man den Linknamen überschreibt, Die defaultanzeige ist doch sehr lang. Übersehe ich da etwas? arved (Diskussion) 17:15, 2. Jun. 2016 (CEST)

Auch diese gehört nicht in unsere Artikel, zumindest nicht direkt und mittendrin.

Sie hat im Übrigen eine völlig mangelhafte Dokumentation, über die du dich bei ihren Hauptautoren beschweren kannst.

LG --PerfektesChaos 17:18, 2. Jun. 2016 (CEST)

Danke für Deine Antwort. Damit ist diese Anfrage, wenn auch leider nur negativ beantwortet. arved (Diskussion) 13:05, 3. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arved (Diskussion) 13:05, 3. Jun. 2016 (CEST)

Vorlage:Infobox Ort in Portugal

Hallo, kann bitte jemand die Box so ändern, das wenn keine Subregion angegeben ist die Region PT ausgegeben wird. Beispiel: Bei União das Freguesias de Santa Ovaia e Vila Pouca da Beira ist kein LAU eingetragen daher wird Region PT- ausgegeben. Also wenn kein LAU angegeben wird dann nur Region PT Danke --2003:4D:2C35:7090:2CD1:A688:A39A:39D3 00:20, 1. Jun. 2016 (CEST)

In der Annahme es geht um den Geohack-Link habe ich es mit dieser Bearbeitung behoben. Die leere Tabellenzeile bei Concelho habe ich mit dieser Bearbeitung behoben. Der Umherirrende 19:44, 6. Jun. 2016 (CEST)

@Umherirrender: Ich weiß nicht was hier was bewirkt sieht aber gut aus. Es gibt eine Fehlerliste in der falsche Koordinaten (Regionen) gelistet werden, die im Moment leider down ist. Habe aber einige Dörfer kontrolliert, ich denke es passt. Danke --2003:4D:2C66:D682:9D61:EA47:C8BE:B62E 20:39, 6. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:44, 6. Jun. 2016 (CEST)

Tracking categories for base modules

Sorry for writing in English, feel free to translate. I'm toying around with a project (m:Help/Spec) and need some stats on use of modules on various projects. To do so I would like to create three templates that adds modules to three categories. Those should be spellchecked! :)

The templates are without documentation, it is probably easiest to translate the English ones. I'm not familiar with how you want the documentation on this project.

The templates

• Vorlage:Kategorisieren Basismodul (en)
• Vorlage:Kategorisieren Basismodul mit Dokumentation (en)
• Vorlage:Kategorisieren Basismodul mit Testfällen (en)

I could not find the correct parent categories, perhaps someone could add them? The ones I used on other projects are on the pages and commented out.

The categories

• Kategorie:Basismodule
• Kategorie:Basismodule mit Dokumentation
• Kategorie:Basismodule mit Testfällen

The templates should be appended to the system messages MediaWiki:Scribunto-doc-page-show and MediaWiki:Scribunto-doc-page-does-not-exist, but it is probably best to wait until any sprelling errors are weeded out. Jeblad (Diskussion) 14:45, 1. Jun. 2016 (CEST)

aus WP:Café hierher übertragen von --Schniggendiller Diskussion 17:50, 1. Jun. 2016 (CEST)

Thanks for moving my note to the correct place! :) Jeblad (Diskussion) 18:24, 1. Jun. 2016 (CEST)

@Jeblad: That doesn’t work here.

• Modules:
  • You may take all pages in module: namespace without slash as base.
  • Dependant Lua sub-modules (with slash) usually have no documentation for its own.
  • All other pages are /Doku and just redirects into project namespace.
  • Your templates wouldn’t work.
  • No /Doku “documentation” page is supposed to bear content. There might be an exception somewhere, but I don’t know any, and it might be no mature code.
  • Note that there are also user sandbox modules, starting with Benutzer: – those shouldn’t be counted.
• Documentation:
  • Join Category:Wikipedia:Lua/Modul/Dokumentation.
  • All reliable codes have an exhausting doc there.
  • Some modules may have several documentation pages, but only one main page with the same name.
  • Beware of translations in your statistics.
• Test:
  • Join Category:Wikipedia:Lua/Modul/Testseite.
  • All exhaustive tests are categorized there.
  • In some minor cases, a few lines of test application might be integrated into documentation page.
  • Some modules are directly supporting a single template, and the test cases are part of that template documentation.
• Please do not try to modify our system messages.
• Please ask for deletion of your templates by {{delete}} yourself as creator, and you might point to this section.

Greetings --PerfektesChaos 19:27, 1. Jun. 2016 (CEST)

Oh, and please put a creator {{delete}} into the categories.

• They are conflicting with our naming policy.
• Category police will take action. Maintenance bot will show up soon.
• They won’t survive this week anyway.

All reliable modules are linked from WP:MOD.

Tusen takk --PerfektesChaos 20:46, 1. Jun. 2016 (CEST)

Ah, I see. Interesting how you have organized the tests, you don't follow the common pattern from other projects. Spec-style tests will not work with this. It could work with step-style tests but that is only at the sketchboard. It will probably be too much work to try to use modules from this project as indicators on rate of pick up of proper tests. I'll keep links to the categories, but I will probably not try to track them. Jeblad (Diskussion) 21:27, 1. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:30, 6. Jun. 2016 (CEST)

Parameter in HTML-Code unterbringen

Ich möchte gerne so etwas hier machen:

<div style="border: 1px {{{1}}} solid; padding: 10px;">{{{2}}}</div>

und dann das hier nutzen (Vorlage:Seitenname):

{{Seitenname|green|Text}}

und dann sehen:

Text

Bei mir klappt das aber nicht, kann mir jemand helfen? Ich nutze ein lokales MediaWiki und experimentiere damit dort gerade. --91.53.2.252 23:29, 4. Jun. 2016 (CEST)

Was klappt nicht? --mfb (Diskussion) 23:40, 4. Jun. 2016 (CEST)

Bei mir im lokalen Wiki sehe ich dann nur {{{2}}} und nicht, was ich eigentlich erwarte!? Ich hatte erwartet, dass ihr mir nun sagt, dass ich einen Parameter nicht in HTML-Code packen darf!? --91.53.2.252 23:46, 4. Jun. 2016 (CEST)

• Nö, du darfst das ziemlich überall hin packen.
• Dein Code sieht okay aus und müsste funktionieren; täte er bei uns.
• Deine Wiki-Installation kennt irgendeine Einstellung nicht oder es fehlt gar eine Komponente.
• Guck mal bei uns auf Spezial:Version und dann bei dir. Wetten, dass bei uns mehr los ist.
• Die hier erforderliche Template-Funktionalität ist aber so elementar, dass sie eigentlich immer mit dabei sein müsste.
• Vielleicht gibt es noch irgendwo einen Schalter; ich weiß aber nicht welcher. Private Installationen sind nicht meine Baustelle.
• Viel Spaß.

LG --PerfektesChaos 00:23, 5. Jun. 2016 (CEST)

Danke, läuft jetzt! --91.53.22.244 16:57, 5. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 09:33, 6. Jun. 2016 (CEST)

KiB/MiB: Dateigrößenangaben durch Vorlage:Infobox Ort in Polen und Vorlage:Infobox Ort in Tschechien

Hallo, in den Artikeln Cieszyn und Český Těšín werden durch die o. g. Vorlagen automatische Einzelnachweise erzeugt, in denen die Dateigrößen mit KiB oder MiB angegeben werden. Ist das richtig oder eine polnich/tschechische Notation? Leider sehe ich keine Möglichkeit, selbst an den entsprechenden Quellcode zu kommen – bei der zweiten Vorlage wäre noch ein Leerzeichen nach dem Datum zu streichen. Für Hilfe dankt --Wi-luc-ky (Diskussion) 10:08, 6. Jun. 2016 (CEST)

Siehe Kibibyte. 1kB = 1000B, aber oft ist damit 1024B gemeint, also 1kiB. Andersrum (also wenn man mit 1kB tatsächlich 1000B meint) gibt es keine Möglichkeit, das klarzustellen, abgesehen davon, es explizit dazuzuschreiben. --nenntmichruhigip (Diskussion) 10:18, 6. Jun. 2016 (CEST)

Danke für die Erläuterungen, michruhigip, lassen wir das also so. War nur Stolpern über Ungewohntes. Und wie kann der typo entfernt werden? --Wi-luc-ky (Diskussion) 11:39, 6. Jun. 2016 (CEST)

Hatte ich vorhin überlesen, auch wenn ich bei dem Leerzeichen vermutlich nicht weiterhelfen könnte :-) Aber da's etwas schwer zu finden ist: Meinst du das Leerzeichen in der Zeile "Einwohner" hinter der schliessenden Klammer des Datums? --nenntmichruhigip (Diskussion) 18:44, 6. Jun. 2016 (CEST)

Ist entfernt. Der Umherirrende 19:21, 6. Jun. 2016 (CEST)

Vielen Dank an nenntmichruhigip (ja, in Z. „Ew.“) und an Den Umherirrenden (ebenda genau getroffen) sagt --Wi-luc-ky (Diskussion) 19:00, 7. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:21, 6. Jun. 2016 (CEST)

Portale

Vielleicht weis ja einer von euch hier Rat?--JTCEPB (Diskussion) 23:24, 10. Jun. 2016 (CEST)

Hallo, ein Blick in den Validator verrät, dass die Seite Layouttabellen mit Strukturfehlern aufweist.

Layottabellen sind per se nicht besonders günstig für die Mobildarstellung. Strukturfehler der Art “Table cell spans past the end of its row group established by a tbody element; clipped to the end of the row group.” sind allerdings tödlich.

Die Pillepalle-Fehlermeldungen zu veralteten Elementen und Attributen (<center>, align, bgcolor, cellspacing, cellpadding, border) kannst du wohl ignorieren, an denen liegt es ziemlich sicher nicht.

Gruß --Entlinkt (Diskussion) 23:32, 10. Jun. 2016 (CEST)

Und das heißt jetzt? Vorlage:Smiley/Wartung/??? --JTCEPB (Diskussion) 23:53, 10. Jun. 2016 (CEST)

Das heißt, dass irgendeine Tabelle falsch erstellt wurde. --mfb (Diskussion) 00:25, 11. Jun. 2016 (CEST)

Ich habe die Tabellenfehler mit diesem Edit repariert. Ist es jetzt besser?

Die Korrektur ist zwar trivial, aber letztens beim FzW-Intro hat so eine triviale Korrektur auch schon geholfen. Gruß --Entlinkt (Diskussion) 00:44, 11. Jun. 2016 (CEST)

Stopp, stopp, stopp. Die Tabellenkorrektur war zwar sinnvoll, aber daran liegt es nicht, sondern es liegt an zigfachem class="nomobile" im Quelltext. Das wurde bestimmt irgendwoher per Copy & Paste verschleppt. Mit dieser Klasse werden die Inhalte explizit aus der Mobilversion ausgeschlossen. Weg damit. --Entlinkt (Diskussion) 01:06, 11. Jun. 2016 (CEST)

Klappt jetzt, danke.--JTCEPB (Diskussion) 05:00, 11. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --JTCEPB (Diskussion) 05:00, 11. Jun. 2016 (CEST)

Vorlage:Infobox Gemeindeteil in Österreich

Hab gesehen, dass sich durch die Änderung des Standes (Datum) für die Einwohnerzahl auch automatisch der Stand für die Gebäudezahl mitgeändert hat (Artikel Viechtwang). Das sollte nicht sein. Einwohnerzahl und Gebäudezahl können, entsprechend der Quelle, verschiedene Stände (Datumsangaben) haben. Grüße, -- Hans Koberger 09:32, 28. Mai 2016 (CEST)

Hab ich was falsch gemacht? -- Hans Koberger 11:58, 6. Jun. 2016 (CEST)

Seit 14 Tage unbeantwortet... Forget it! -- Hans Koberger 08:22, 11. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Hans Koberger 08:22, 11. Jun. 2016 (CEST)

Doppelte automatische Nummerierung von Überschriften

Hallo, ist schon jemandem aufgefallen, dass bei Aktivierung der erweiterten Funktion „Überschriften automatisch nummerieren“ in „Einstellungen/Aussehen“ jetzt in den Inhaltsverzeichnissen alle Gliederungspunkte doppelt angezeigt werden? Z. B.: 6.2.3 6.2.3. Wer kann bitte helfen? --Wi-luc-ky (Diskussion) 11:28, 4. Jun. 2016 (CEST)

Das ist erstens kein Vorlagenproblem und liegt zweitens an dem folgenden Code in Benutzer:Wi-luc-ky/common.js:

$('#toc li a').each(function() {
    $(this).find('.toctext').html(
        $('#mw-content-text').find($(this).attr('href').replace(/([.:])/g, '\\$1')).html()
    );
});

Viele Grüße --Entlinkt (Diskussion) 12:17, 4. Jun. 2016 (CEST)

Vielen Dank, Entlinkt, jetzt sehe ich nicht mehr „doppelt“;-) Du hast den Fehler wohl gleich bei mir repariert (was aus Deiner Antwort nicht so eindeutig hervorging)? Wieso eigentlich nur „bei mir“? Um Antwort bittet --Wi-luc-ky (Diskussion) 15:59, 4. Jun. 2016 (CEST)

Zu früh gefreut: Nach Anmeldung the same old problem. Wie/wo kann ich bitte mein js ändern, Entlinkt? --Wi-luc-ky (Diskussion) 16:11, 4. Jun. 2016 (CEST)

Hallo Wi-luc-ky, ich habe den Fehler nicht repariert (und werde das auch nicht tun), sondern habe nur die Ursache benannt, damit jemand anderes das tun kann. Vielleicht nochmal etwas verständlicher: Das Inhaltsverzeichnis hat standardmäßig Nummern, und dein Skript kopiert die Überschriften aus dem Artikelinhalt in das Inhaltsverzeichnis. Wenn du nun die Einstellung „Überschriften automatisch nummerieren“ aktivierst, erscheinen die Überschriften im Inhaltsverzeichnis doppelt, nämlich jeweils einmal die standardmäßig sowieso vorhandene Nummer und zusätzlich noch die aus dem Artikelinhalt kopierte Nummer.

Das Skript ist in seiner jetzigen Form offenbar nicht dafür gemacht, zusammen mit der Einstellung „Überschriften automatisch nummerieren“ benutzt zu werden. Falls du das Skript selbst geschrieben hast, müsstest du es auch selbst anpassen; falls du es übernommen hast, kannst du dich vielleicht an die Quelle wenden. Möglicherweise kann dir auch jemand in der Technik-Werkstatt helfen, dorthin würde die Frage etwas besser passen. Viele Grüße --Entlinkt (Diskussion) 16:23, 4. Jun. 2016 (CEST)

PS: Ich sehe gerade, dass du das Skript aufgrund einer Anfrage in der Vorlagenwerkstatt erhalten hast, nämlich Wikipedia:WikiProjekt Vorlagen/Werkstatt/Archiv 2016/1#Technische Frage zum Vermerk »done« an VL-Werkstatt. Unter diesen Umständen ist die erneute Anfrage hier schon OK.

Vielleicht kann Wiegels weiterhelfen, der dir das Skript damals gegeben hatte? Ich persönlich würde allerdings vorschlagen, das Skript nicht zu reparieren, sondern einfach wieder zu entfernen, da es dazu führt, dass Überschriften bei dir anders aussehen als bei allen anderen Benutzern der Wikipedia, was dich dazu verleiten könnte, Formatierungen einzubauen, die bei anderen Benutzern nicht funktionieren. Viele Grüße --Entlinkt (Diskussion) 16:36, 4. Jun. 2016 (CEST)

Gut, Entlinkt. An meinen bescheidenen Fragen siehst Du schon, dass ich das Skript nicht geschrieben habe. Werde die Frage also vorerst nicht an die Technik-WS, sodern an Wiegels überweisen und danke Dir vielmals. --Wi-luc-ky (Diskussion) 16:54, 4. Jun. 2016 (CEST)

Hallo Wiegels, was rätst Du? Und ganz praktisch: Wie würde ich ggf. den js-Zusatz wieder löschen können? Dank vorab von --Wi-luc-ky (Diskussion) 16:54, 4. Jun. 2016 (CEST)

Wenn ich mich doch nochmal einmischen darf: Falls du das Skript nicht benötigst (und ich denke, dass es wirklich nicht nötig sein sollte), dann kannst du es ganz einfach selbst (ohne Mithilfe von Wiegels) entfernen. Es genügt, die Seite Benutzer:Wi-luc-ky/common.js leer abzuspeichern. Viele Grüße --Entlinkt (Diskussion) 17:09, 4. Jun. 2016 (CEST)

Dank Deiner praktischen Anleitung, Entlinkt, ist die doppelte Anzeige nun entfernt. Dein ehemals hilfreiches Skript, Wiegels, habe ich wegen der technischen Konflikte leider löschen müssen. Ein Dankeschön an euch beide sagt --Wi-luc-ky (Diskussion) 19:45, 5. Jun. 2016 (CEST)

Hallo Wi-luc-ky, durch Anpassung der dritten Zeile funktioniert das Skript unabhängig von der Einstellung bei „Überschriften automatisch nummerieren“ wie ursprünglich erwartet.

$('#toc li a').each(function() {
    $(this).find('.toctext').html(
        $('#mw-content-text').find($(this).attr('href').replace(/([.:])/g, '\\$1')).html().replace(/<span class="mw-headline-number">\d+<\/span> /, '')
    );
});

Danke an Entlinkt für die Erklärungen! --Wiegels „…“ 21:46, 5. Jun. 2016 (CEST)

Vielen Dank, Wiegels, für den fix. Klappt bestens. Wollte Dich deswegen nicht noch einmal bemühen, aber so kann ich beide Features nutzen. Darf ich Deine Aufmerksamkeit noch auf die weiter oben thematisierte fehlerhafte Vorlage:DicEncFreg mit meinen Überlegungen lenken? Vllt. sehen wir uns dort?! --Wi-luc-ky (Diskussion) 23:13, 5. Jun. 2016 (CEST)

Hallo Wiegels, nochmals: Dein fix klappt bestens – bei Inhaltsverzeichnissen, die nur Nr. 1, 2, 3 usw. haben, nicht aber aber bei 1.1, 1.2, 2.1.1, 2.1.2 usw., wobei die Untergliederungspunkte doppelt angezeigt werden. Kann das Inhaltsverzeichnis irgendwie ganz ausgenommen werden? --Wi-luc-ky (Diskussion) 12:52, 6. Jun. 2016 (CEST)

Hallo Wi-luc-ky, da habe ich wohl nicht zu Ende gedacht und nur oberflächlich getestet. Mit

$('#toc li a').each(function() {
    $(this).find('.toctext').html(
        $('#mw-content-text').find($(this).attr('href').replace(/([.:])/g, '\\$1')).html().replace(/<span class="mw-headline-number">\d(\.\d+)*<\/span> /, '')
    );
});

werden die Nummern auch bei mehrstufigen Inhaltsverzeichnissen nicht wiederholt. --Wiegels „…“ 03:49, 12. Jun. 2016 (CEST)

Ja, Wiegels, jetzt klappt es auch bei mir. Besten Dank! – Inzwischen ist die Arbeit an Vorlage:DicEncFreg fehlerhaft etwas vorangeschritten. Könntest Du da etwas für meine Korrektur-/Ergänzungsfragen dort tun? Danke sagt Dir --Wi-luc-ky (Diskussion) 12:17, 12. Jun. 2016 (CEST)

Muss mich leider korrigieren, Wiegels, da bei zweistelligen Nummern, also ab 10, die Nummerierung im Inhaltsverzeichnis immer noch doppelt ist, was ich erst jetzt bei einem langen InhVz gesehen habe. Seltsam... --Wi-luc-ky (Diskussion) 22:07, 12. Jun. 2016 (CEST)

Hallo Wi-luc-ky, das passiert mir schonmal, wenn ich im letzten Moment etwas umbaue. Mit

$('#toc li a').each(function() {
    $(this).find('.toctext').html(
        $('#mw-content-text').find($(this).attr('href').replace(/([.:])/g, '\\$1')).html().replace(/<span class="mw-headline-number">\d+(\.\d+)*<\/span> /, '')
    );
});

sollte es jetzt aber endgültig funktionieren. --Wiegels „…“ 22:42, 12. Jun. 2016 (CEST)

Mit aller Vorsicht: Ja, jetzt sollte es endgültig ;-) funktionieren. Ein großes Dankeschön sendet Dir --Wi-luc-ky (Diskussion) 23:14, 12. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 23:14, 12. Jun. 2016 (CEST)

Vorlage:Infobox Tournee - "Cover"-Größe nicht veränderbar

Hallo meine Damen und Herren, bei der Vorlage:Infobox Tournee wollte ich auf dem Artikel Clapton World Tour (Bitte Sichten) das Bild File:EC Berlin Plakat.jpg von Commons einfügen. Dies kann ich auch, nur sprengt die Größe des Bildes den gesamten Artikel. Ich möchte gerne in der Lage sein das Bild auf 250px zu verkleinern wie es auch bei Vorlage:Infobox Stadion möglich ist. Lässt sich da was machen? Gruß und Dank! --Cdcoverdude (Diskussion) 13:33, 12. Jun. 2016 (CEST)

Mal abgesehen davon dass das Bild eh gelöscht wird, sprengt es nicht den Artikel. Standardgröße ist 250px und die wird auch angezeigt. Gesichtet habe ich den Artikel auch. Da kein Handlungsbedarf, erledigt.--JTCEPB (Diskussion) 15:37, 12. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --JTCEPB (Diskussion) 15:37, 12. Jun. 2016 (CEST)

Einbindung von Bildern

Ist es vielleicht irgendwann möglich den Wildwuchs zu beschneiden?

Es gibt wohl alle Möglichkeiten:

• Dateiname.jpg
• File:Dateiname.jpg
• File:Dateiname.jpg|thumb

und das Ganze dann auch noch mit und ohne die eckigen Klammern.

Jede Vorlage nach eigenem Geschmack und überhaupt nicht Abweichungs- (ich sage bewußt nicht Fehler- ) tolerant. Entweder erscheint nichts oder ein einsames "File" irgendwo in der Landschaft oder das Bild wird seitenfüllend. Ein reines Ratespiel. --Eingangskontrolle (Diskussion) 21:55, 4. Mai 2016 (CEST)

Zu den Varianten:

• Diese Werkstatt würde definitiv den ersten Fall bevorzugen und empfehlen.
  • Damit lassen sich auch sinnvolle Parametertests machen.
• Bei den Varianten 2 und 3 ist die Angabe des Namensraums redundant; der sollte immer innerhalb der Vorlage vorangestellt werden.
• Der Bildparameter im 3. Beispiel ist unerwünscht. Das soll erstens immer einheitlich innerhalb der Vorlage hinzugefügt werden; sollte ausnahmsweise die Möglichkeit für Optionen wie „hochkant“ oder eine Pixelbreite gegeben werden, so gehören diese in einen gesonderten Parameter, oder gar mehrere.
• Klammern werden innerhalb der Vorlage gesetzt.
• Simple Merkregel: Alles, was konstant ist, geschieht innerhalb der Vorlage; lediglich der veränderliche Dateititel, die Bildlegende und ggf. besondere Bildoptionen kommen in jeweils eigene Parameter.

Die Vorlagen wurden über mehr als ein Jahrzehnt von wohl über einem Tausend Erstellern gebastelt und mehr oder weniger weise oder auch sehr ungeschickt parametrisiert oder benannt.

• Wir haben keinen Einfluss darauf, zumal wir auch nicht gefragt werden; selbst wenn diese Werkstatt irgendwann zu Hilfe gerufen wird, sind die Beteiligten immer wieder mal beratungsresistent und wenig einsichtig.
• Wenn du eine bestimmte Vorlage im Auge hast, kannst du sie anhand der vorstehenden Maßgaben umbauen, einen Botlauf in Auftrag geben, um alle vorhandenen Einbindungen umzustellen, und dir etwas ausdenken, wie in der Zwischenzeit die teilweise schon umgestellten und die noch nicht umgestellten Einbindungen alle das richtige Ergebnis liefern.

VG --PerfektesChaos 23:35, 4. Mai 2016 (CEST)

Doku auch einfügen

Ich möchte im Wiktionary mittels Inputbox neue Vorlagen erstellen, auf welcher ebenfalls eine Doku vorhanden ist (,welche wieder zur verlinkten Seite leitet). Ich habe ein bisschen rumprobiert, aber keinen Weg gefunden, die Doku in den neuen Einträgen zu erhalten. Kann mir jemand erklären, wie man das Problem löst? --Impériale (Diskussion) 22:43, 4. Mai 2016 (CEST) PS: Auf der Doku-Seite funktioniert der Präfix der Inputbox, bei der eigentlichen Vorlage nicht. Woran liegt das? --Impériale (Diskussion) 22:45, 4. Mai 2016 (CEST)

Es wäre günstig, wenn du das unter WP:BETA beschriebene Projekt aufsuchen und dort eine Spielumgebung mit deinen Seiten einrichten würdest. Dort kann man dann auch Seiten anlegen, was im echten Wiki nicht so gut wäre. Verstanden habe ich dein Problem „mit der Doku welche wieder“ und „Doku in den neuen Einträgen“ ohnehin nicht; vielleicht geht es um Hilfe:Preload? LG --PerfektesChaos 23:12, 4. Mai 2016 (CEST)

Vorlage:DicEncFreg fehlerhaft

Hallo, genannte Vorlage ist sowohl bibliographisch als auch typographisch mehrfach fehlerhaft (Gedankenstrich usw.). Schon die (fehlerhafte) Beschreibungsseite (Komma nach Titel, fehlendes Komma am Ende) stimmt nicht mit dem sichtbaren Text der Vorlage überein, z. B. mit/im Art. Coja. Zudem fehlt der Parameter Autor. Die einleitende Angabe „Art.“ wäre wünschenswert und ein Abgleich mit den jüngst etablierten Parametern der Literaturvorlagen erforderlich. Mein Vorschlag zum sichtbaren Text:

Autor: Art. Xyz. In: Isabel Silva (Hrsg.): Dicionário Enciclopédico das Freguesias. 2. Auflage. Band Z. Freixieiro, Minhaterra 1997, S. XX–YY.

Da diese Enzyklopädie bei WorldCat fehlt (!) und bei Google Book nur sekundäre Treffer erzielt werden, ist mE nicht deutlich, ob alle vier Bände 1997 erschienen sind. Außerdem findet man als Ausgabeort auch Lisboa, siehe dort, mglw. eine Verschreibung. Auf der Beschreibungsseite wäre auch die Angabe hilfreich, aus welcher Datenbank die Angaben erzeugt werden. Wer könnte den Code bitte entsprechend korrigieren, da die „Erfinder“ auf meine Fragen auf der Diskussionsseite nicht geantwortet haben? --Wi-luc-ky (Diskussion) 11:53, 2. Jun. 2016 (CEST)

Habe einen Korrekturentwurf erstellt, wobei ich nur den Anleitungstext, nicht aber die Vorlage selbst auf Richtigkeit/Funktionalität überprüfen kann (da ich die Vorlage nicht gleich ändern wollte, weil vielfach eingebunden). Ich bitte um Durchsicht und die zwei benannten Ergänzungen. Falls noch eine ISBN bekannt wird, bitte diese auch ergänzen bzw. eine Vorratscodierung hidden anbringen. Danke sagt --Wi-luc-ky (Diskussion) 18:15, 9. Jun. 2016 (CEST)

Dankenswerterweise hat Lómelinde die ISBNs aller vier Bände in Erfahrung gebracht, siehe auch meine Diskussionseite und den Dicionário enciclopédico das freguesias auf aleph20.letras.up.pt:

* Band 1: Braga, Porto, Viana do Castelo. 1996, ISBN 972-96087-2-3 (formal falsch).

* Band 2: Titel ??? 1997, ISBN 972-96087-5-X.

* Band 3: Bragança, Guarda, Vila Real. 1997, ISBN 972-96087-7-6.

* Band 4: Beja, Castelo Branco, Évora, Faro, Lisboa, Portalegre, Setúbal, Açores, Madeira. 1998, ISBN 972-97885-0-2.

Nun wäre mein Wunsch, den Code so zu gestalten, dass bei Eintrag der Band-Nr. automatisch das jeweilige Erscheinungsjahr (nicht nur 1997), die ISBN und wenn möglich der Band-Titel ausgeworfen werden. Könnte bitte jemand die Klammerei so gestalten? Vielleicht zunächst in meinem Korrekturentwurf, den ich um das andere Fehlende noch ergänzen möchte. --Wi-luc-ky (Diskussion) 19:35, 11. Jun. 2016 (CEST)

@Lómelinde: Ich denke, du bist reif dafür, sowas auf BETA zu programmieren.

• Vorlage:HambBio und Vorlage:Zedler Online machen irgendwie sowas Ähnliches.
• Dabei Vorlage:Literatur für die Ausgabe zu versorgen hätte den Vorteil, dass deine neuen Einbindungen gleich mal mit COinS versorgt würden.

Viel Spaß --PerfektesChaos 15:15, 13. Jun. 2016 (CEST)

Oha, du hast ja sehr viel Zuversicht, was meine Fähigkeiten im Vorlagenbereich angeht. O.k. ich schaue mal, ob ich das irgendwie gebacken kriege. Some little coins I do know, aber COinS sagt mir nichts. --Liebe Grüße, Lómelinde Diskussion 15:24, 13. Jun. 2016 (CEST)

Habe mal meinen Entwurf in der Beschreibung angepasst, Lómelinde. Sehe gerade, dass der jetzige Code fälschlicherweise für alle Bände immer nur das Jahr 1997 ausgibt, was sich durch alle Einbindungen hindurchzieht. Nun ja... Der Ermunterung meines Vorredners PerfektesChaos schließe ich mich gern an. – Linkreparatur: Dicionário enciclopédico das freguesias. In: aleph20.letras.up.pt funktioniert. --Wi-luc-ky (Diskussion) 01:20, 14. Jun. 2016 (CEST)

Warte einfach mal bis heute. Lómelinde hat schon längst eine Lösung, die vielleicht noch ein Sahnehäubchen bekommt. Gute Nacht --PerfektesChaos 01:24, 14. Jun. 2016 (CEST)

So, ich weiß nicht, ob das jetzt so ganz deinen Wünschen entspricht, da ich auf den Parameter |Autor= verzichtet habe, der sich aber durchaus noch einrichten ließe, wenn das erforderlich ist. Du kannst es dir gern einmal →hier ansehen. Was ich noch nicht so genau weiß ist, was passiert, wenn ich es hier übernehme, da die Vorlage ja in einigen Artikeln (35) bereits mit den bisherigen Parameterwerten in der Reihenfolge Band, SeiteX, SeiteY, Artikeloriginaltitel

• {{DicEncFreg|Band|SeiteX|SeiteY|Artikeloriginaltitel}}

eingebunden ist, da ich diese Reihenfolge zu Artikel, Band, von Seite, bis Seite geändert habe. Da wird dann vermutlich zunächst so etwas passieren.

• Band. In: Isabel Silva (Hrsg.): Dicionário Enciclopédico das Freguesias. *Bandnummer ist falsch oder fehlt*. Minha Terra, Matosinhos, S. SeiteY–Artikeloriginaltitel (portugiesisch).

Die Artikel sollten dann in der Kategorie:Wikipedia:Vorlagenfehler/Vorlage:DicEncFreg erscheinen, wenn die Angabe des Bandes fehlt oder wie hier mit einem anderen Wert als 1–4 belegt wurde. Und wie ist das mit der „2. Auflage“? Gilt das für alle Bände? Dann würde ich das noch ergänzen, ich habe aber dazu leider keine Angaben gefunden. --Liebe Grüße, Lómelinde Diskussion 08:37, 14. Jun. 2016 (CEST)

Das sieht schon sehr, sehr gut aus, Lómelinde, vielen Dank für Deine umfangreiche, bereits vieles berücksichtigende Arbeit! Was mir noch aufgefallen ist:

• m. E. liegt bei allen vier Bänden die 2. Auflage vor; diese Angabe könnte also als Standardangabe nach dem Titel aufgenommen werden;
• in der Beschreibung wären die portugiesischen Akzente im Titel mit zu setzen, also:
• Dicionário Enciclopédico das Freguesias (wäre in zweimaliger Erwähnung zu korrigieren);
• die Weglassung des Artikelnamens bei gleichem WP-Artikel ist natürlich die „hohe Schule“ der Programmierung; aus verschiedenen Gründen würde ich aber davon abraten: Einheitlichkeit, Identifizierbarkeit, bibliographische Vollständigkeit (besser für's Kopieren), alles auf einen Blick (auch in den refs kein langes Überlegen: Wo bin ich?);
• da ich die Bände leider noch nicht selbst gesehen habe, ist mir nicht klar, ob die Artikel zu den Gemeinden, freguesias, überhaupt den jeweiligen Autor am Ende führen, weshalb ich derzeit einen Parameter „Autor“ eher als Parameter auf Vorrat, wenn überhaupt für sinnvoll erachte;
• an den Reparaturarbeiten an den Einzelartikeln mit Vorlagefehlern könnte ich mich nach Abschluss der Vorlagenkorrektur nach Absprache beteiligen.

Die verwaiste Vorlage hat damit in euch beiden, Lómelinde und PerfektesChaos, wahrhafte Pflegeeltern gefunden (wobei der Anteil der Mutter wie gewöhnlich „ein wenig“ höher liegt). Prima. Haltet mich bitte auf dem Laufenden; soweit in meinen bescheidenen Kräften stehend, beteilige ich mich gern weiter. --Wi-luc-ky (Diskussion) 16:55, 14. Jun. 2016 (CEST)

Den einen Satz verstehe ich leider nicht

• „Dicionário Enciclopédico das Freguesias (wäre in zweimaliger Erwähnung zu korrigieren)“

wo wird das zweimal erwähnt? Ein Eintrag sieht jetzt beispielsweise so aus.

• Miranda do Douro. In: Isabel Silva (Hrsg.): Dicionário Enciclopédico das Freguesias. 2. Auflage. Band 3: Bragança, Guarda, Vila Real. Minha Terra, Matosinhos 1997, ISBN 972-96087-7-6, S. 94 (portugiesisch). 

Das ist doch so wie es soll, oder nicht? Ich habe die Seiten schon alle angepasst, ich mag nämlich keine halben Sachen.

O.k. Die 2. Auflage dürfte kein Problem sein.

Und das „wo bin ich“ verstehe ich auch nicht wirklich, das Ganze hat einen Pflichtparameter nämlich Bandnummer, Artikel kann es weitgehend selbst finden und die Seitenzahlen kann nur der Ersteller einfügen.

Wenn du in der Kopiervorlage gern diese Angaben hättest, kann ich dir auch noch alternativ eine Variante einfügen. Du kannst aber gern die Artikel noch mal durchgehen. Einfach in meine Beiträge schauen. --Liebe Grüße, Lómelinde Diskussion 17:12, 14. Jun. 2016 (CEST)

Hallo Lómelinde, das Beispiel „Miranda do Douro“ ist völlig korrekt. Meine Akzent-Anmerkung bezog sich auf den ersten Satz (noch vor dem Inhaltsverzeichnis) der Dokumentation, wo ... jetzt die Akzente zu sehen sind, ebenso im ersten Satz des Kastens bei „TemplateData“. Also alles O.K. – Das „Wo bin ich?“ bezog sich nur darauf, dass ich persönlich auch in den Fußnoten alle Infos, auch den Titel, gern kompakt sehen möchte; gerade bei langen refs mit mehreren Bezugnahmen auf dieses Nachschlagewerk wäre/ist das m. E. übersichtlicher. (Wahrscheinlich habe ich es nicht richtig verstanden: Ist es so, dass bei gleichem Artikel der DicEncFreg-Name automatisch ergänzt wird? Dann wäre das in meinem Sinne. Hatte es anders verstanden: dass der Artikelname dann im ref weggelassen würde.) Ansonsten vielen Dank für die vielen, schon vollzogenen Anpassungen der Einzelartikel; das Ergebnis kann sich wirklich sehen lassen!! Gruß und nochmals Dank von --Wi-luc-ky (Diskussion) 17:56, 14. Jun. 2016 (CEST)

Ja die Doku habe ich angepasst, das war ein Kopierfehler meinerseits.

Genau, vorher stand in der Vorlage so etwas wie Seitentitel also konkret {{ #if:{{{4|}}}|{{{4}}}|{{PAGENAME}} }}, daher dachte ich, es war vorher so, dass der Seitentitel (Lemma) erkannt wurde und das sollte so bleiben.

Neu ist, dass es durch eine etwas andere Einbindung, die ich mithilfe von PerfektesChaos nutzen konnte, nun egal ist, ob die Seite einen Klammerzusatz hat oder nicht. Es wird automatisch nur der Anteil des Lemmas vor der Klammer als Artikelname in die Vorlage eingebunden.

Wenn ich die Vorlage also hier ohne Angabe eines Ortsnamens einfügen würde dann stünde dort

• WikiProjekt Vorlagen/Werkstatt/Archiv 2016/2. In: Isabel Silva (Hrsg.): Dicionário Enciclopédico das Freguesias. 2. Auflage. Band 3: Bragança, Guarda, Vila Real. Minha Terra, Matosinhos 1997, ISBN 972-96087-7-6, S. 94 (portugiesisch). 

Auflage habe ich ergänzt. Falls du noch etwas benötigen solltest, sag einfach Bescheid. Auch wenn ich recht viel Zeit benötigt habe und andere so etwas aus dem Zylinder zaubern könnten, war es doch eine sehr gute Übung für mich. Genau als solche war es wohl auch gedacht. Ohne den kleinen Schubs („@Lómelinde: Ich denke, du bist reif dafür, sowas auf BETA zu programmieren.“) hätte ich so etwas nie versucht selbst umzusetzen.

Es freut mich, wenn es dir soweit gefällt, ich habe es gern getan. Wenn das hier für dich soweit o.k. ist, kannst du hier einen Erledigtbaustein einfügen. --Liebe Grüße, Lómelinde Diskussion 18:15, 14. Jun. 2016 (CEST)

Fast erledigt, Lómelinde. Bitte hinsichtlich des Einleitungssatzes der Beschreibung noch einmal den Art. Freguesia konsultieren, woraus sich ergibt, dass es sich um aktuelle, staatliche bzw. öffentlich-rechtliche kommunale (und nur historisch gesehen: kirchliche) Verwaltungseinheiten handelt. Vielleicht wäre eine geschickte Verlinkung auf diesen Art. in der Anleitung hilfreich? (Nur) In etwa kann ich nachvollziehen, wieviel Arbeit Du schon investiert hast. Mit britischem Understatement – ich bin nicht unzufrieden mit dem, was aus Deinem Zylinder kam; und das nächste Mal schüttelst Du die Vorlage einfach aus dem Ärmel;-) Chapeau! (PS: Meine Akzent-Anmerkung bezog sich noch auf die Beta-Version, wie ich gerade sah.) Den Erledigtbaustein füge ich dann zu gegebener Zeit ein. --Wi-luc-ky (Diskussion) 20:04, 14. Jun. 2016 (CEST)

Guten Morgen Wi-luc-ky, dann ändere doch bitte einfach die Einleitung auf der Dokumentationsseite so ab, wie du denkst dass es sein sollte. Das ist einfacher als es über drei Ecken zu machen.   --Liebe Grüße, Lómelinde Diskussion 06:29, 15. Jun. 2016 (CEST)

Gut, gut, Lómelinde. Getan. Habe es analog zu einer kurzen BKL gestaltet. Möge die Vorlage nun ihren guten, besseren Dienst tun. Also: Meinen Dank für alles hast Du. Sollten wir die Vorlage nicht mindestens im Art. Freguesias, ggf. in Município (Portugal), Kommunale Selbstverwaltung in Portugal, Kommunale Selbstverwaltung in Portugal usf. erwähnen?! Dort wäre auch (überall) dieses Nachschlagewerk in „Literatur“ nachzutragen, was ich demnächst angehen werde. --Wi-luc-ky (Diskussion) 11:28, 15. Jun. 2016 (CEST)

Hallo Wi-luc-ky, du kannst gern Literaturangaben in den Artikeln ergänzen.

Nein, bitte keine Hinweise/Links auf andere Namensräume (Vorlagennamensraum) innerhalb der Artikel, du kannst aber gern einen Hinweis auf die Vorlage auf die Diskussionsseiten der Artikel setzen, so wie es beispielsweise beim →BBL gemacht wurde. Artikel sind Artikel da gehören solche Dinge nicht in den Text hinein, denke ich. --Liebe Grüße, Lómelinde Diskussion 11:42, 15. Jun. 2016 (CEST)

Denke nach Lektüre der Verlinkungshinweise auch so, Lómelinde. Wie vorgeschlagen werden in den Diskussionsseiten mögliche Interessenten hingewiesen werden. Schaue mir das mal an, wo es sinnvoll wäre. Nun meine ich, dass dieser Thread erledigt ist und schließe dankend, --Wi-luc-ky (Diskussion) 13:33, 15. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Wi-luc-ky (Diskussion) 13:33, 15. Jun. 2016 (CEST)

Oderverknüpfung

Servus,
Wo finde ich ein eingängiges Beispiel für die OR-Verknüpfung? Hilfe:Vorlagenprogrammierung lässt mich ratlos zurück.
Danke voraus!
Gruß, Ciciban (Diskussion) 18:49, 16. Jun. 2016 (CEST)

Wenn du ein einschließendes Oder meinst (1, 2, oder beides), dann:

{{#if: {{{1|}}}{{{2|}}} | 1 oder 2 oder beide | weder 1 noch 2 }}

LG --PerfektesChaos 20:14, 16. Jun. 2016 (CEST)

Danke, bin damit auch nicht grün geworden. Das was ich wollte habe ich inzwischen in den Rückfallwerten für switch gefunden: Hilfe:Vorlagenprogrammierung#Funktion_switch — eine Anweisung, die für mehrere bestimmte Werte derselben Variable gilt. {{#switch:{{{Wochentag}}}|Samstag|Sonntag=Lenzen|#default=Hakeln gehen}}
Gruß, Ciciban (Diskussion) 20:45, 16. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Ciciban (Diskussion) 08:11, 17. Jun. 2016 (CEST)

Infobox Ort

Im Artikel Fagatogo wird durch die Vorlage:Infobox Ort eine falsche Positionskarte verwendet. Warum wird bei "ISO-CODE = AS" die Karte der USA verwendet? Wie trägt man da die bessere Karte (Datei:Samoa_location_map.svg ein? --Jmv (Diskussion) 10:21, 17. Jun. 2016 (CEST)

Vorlage:Info ISO-3166-2:AS leitet auf Vorlage:Info ISO-3166-2:US-AS weiter, da für Samoa beide Codes gelten. Nun holt sich die Infobox-Vorlage dort die oberste Administrationseinheit ab (= US) und bindet die passende Karte Vorlage:Positionskarte USA ein. Für solche Sonderfälle kann die Karte explizit geändert werden: [7]. --тнояsтеn ⇔ 12:31, 17. Jun. 2016 (CEST)

Danke

Archivierung dieses Abschnittes wurde gewünscht von: Jmv (Diskussion) 22:18, 17. Jun. 2016 (CEST)

Vorlage:Infobox Rennfahrer/WRC

In der Vorlage wird der eingegeben Text zur letzten Rallye in einen Link umgewandelt. Besteht die Möglichkeit einen vom Link abweichenden anzuzeigenden Text dort einzufügen?Vfb1893 (Diskussion) 11:22, 28. Apr. 2016 (CEST)

@Vfb1893: Das ist erstmal nicht vorgesehen. Es soll dort die letzte Rallye und die letzte Saison verlinkt werden, Selbst wenn es dazu keinen Artikel gibt. Was hast du denn vor? Wenn es etwas ist, was man an mehreren Stellen gebrauchen können, bauen wir es in die Vorlage ein. Gruß, -- Emfau (Diskussion) 14:27, 9. Mai 2016 (CEST)

@Emfau: Ich habe versucht das Weiterleitungschaos bei der Rallye Griechenland bzw. Akropolis-Rallye zu beseitigen. Das ist mir auch zu Großteil gelungen. Nur in der Infobox von Walter Röhrl ist noch die Akropolis-Rallye aufgeführt und damit auf eine Weiterleitung verlinkt. Da zur damaligen Zeit die Rallye nur als Akroplolis-Rallye bekannt war, habe ich diese Weiterleitung nicht aufgelöst und daher die Anfrage gestellt. Vfb1893 (Diskussion) 15:01, 9. Mai 2016 (CEST)

Vorlage:National football squad start (goals) & Co.

Mithilfe dieser Vorlagen wird in etlichen Nationalmannschafts-Artikeln eine Tabelle des aktuellen Kaders zusammengebastelt, mit dem Effekt, dass der komplette Rest des Artikels (inklusive Navi am Schluss) nicht mehr auf ganzer Bildschirmbreite dargestellt wird (Beispiele: Walisische Fußballnationalmannschaft#Aktueller_Kader, Mauretanische Fußballnationalmannschaft#Aktueller_Kader, Neukaledonische Fußballnationalmannschaft#Kader_der_Fu.C3.9Fballnationalmannschaft_von_Neukaledonien, Marokkanische Fußballnationalmannschaft#Kader). Offenbar wird die Tabelle nicht richtig zugemacht; in der en.WP, von wo das anscheinend 1:1 und ohne zu verstehen, wie es funktioniert, abgekupfert wurde, gibt es auch noch ein Template:National football squad end, auf das bei uns verzichtet wird. — ^PDD — 17:50, 16. Jun. 2016 (CEST)

Mittlerweile mittels FzW zumindest aufgeklärt. Danke fürs Engagement. — ^PDD — 01:24, 22. Jun. 2016 (CEST)

Man könnte auf solche wenig sinnvolle Vorlagen auch einfach ganz verzichten... -- Chaddy · D – DÜP – 02:18, 22. Jun. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: — ^PDD — 01:24, 22. Jun. 2016 (CEST)

Vorlage:Infobox Fußballnationalmannschaft

Gibt es eine Möglichkeit 2 Flaggen hintereinander zu stellen? Zum Beispiel bei "Trainer" die 2 Staatsbürgerschaften besitzen? lg --Enzolo412 (Diskussion) 18:45, 11. Mai 2016 (CEST)

Hinter/vor den Trainernamen? Was du in das Feld einträgst, ist der Vorlage egal, auch beliebig viele Flaggenvorlagen können dort verwendet werden. Ich weiß nicht ob es üblich ist, dort überhaupt Flaggen zu verwenden, aber das ist eine inhaltliche Frage. --mfb (Diskussion) 22:24, 11. Mai 2016 (CEST)

siehe z.b hier das syntax ist wohl "NOR|Ziel". ich schaffs aber nicht ein GER einzubauen lg --Enzolo412 (Diskussion) 10:45, 12. Mai 2016 (CEST)

Abschließende Leerzeichen beim Substen erhalten

Hallo, {{ers:Kinostarts3|Q21213457}} ergibt A man can make a difference (Regie: Ullabritt Horn, Deutschland 2015, Dokumentarfilm). Zur Gewährleistung von Leerzeichen finden sich im Quelltext allerdings  . Diese sind notwendig, damit bei den einzelnen Lua-Abrufen nicht die abschließenden Leerzeichen verschwinden, siehe {{Kinostarts3}}. Gibt es eine Möglichkeit, die Vorlage mit handelsüblichen Leerzeichen zu substen? –Queryzo ?! 11:17, 12. Mai 2016 (CEST)

Das Leerzeichen als normales Zeichen in Zeile 5 vor das safesubst setzen, das die Klammer erzeugt? Falls die Klammer nicht vorkommt kann man dann nicht ohne Leerzeichen danach weiterschreiben, ich weiß nicht ob das relevant ist. --mfb (Diskussion) 17:44, 13. Mai 2016 (CEST)

@Mfb: Kann ich grad nicht nachvollziehen, kannst du das mal reineditieren? –Queryzo ?! 09:58, 17. Mai 2016 (CEST)

Wenn ich mich hier mal reindrängeln darf: In Vorlage:Redundanz besteht seit vielen Jahren ein ähnliches Problem, das suboptimalerweise so gelöst wurde, dass beim Substituieren eine Einbindung der Vorlage:NULL zurückbleibt. Vielleicht kann eine Lösung für beide Fälle gefunden werden? --Entlinkt (Diskussion) 10:04, 17. Mai 2016 (CEST)

A Man Can Make A Difference (Regie: Ullabritt Horn, Deutschland 2015, Dokumentarfilm) - reineditiert. Bei der Vorlage:Redundanz gibt es keine geeignete Stelle dafür. Man könnte &nbsp; verwenden. --mfb (Diskussion) 00:41, 18. Mai 2016 (CEST)

R☉

R_☉ (Sonnenradien) ist für Laien nicht selbsterklärend. Könnte man nicht eine Vorlage wie >>1 m<< erstellen?--Harald321 (Diskussion) 22:35, 14. Mai 2016 (CEST)

Ich würde da ggf. einfach einen Link auf Sonnenradius setzen. Das muss man ja nicht bei jedem Auftauchen auf einer Seite machen. Das ergibt dann [[Sonnenradius|R<sub>☉</sub>]], also R_☉. ÅñŧóñŜûŝî (Ð) 23:16, 17. Mai 2016 (CEST)

Vorlage:Infobox Schiff und andere

Hallo!

Mir ist das Folgende schon seit längerem aufgefallen. In der genannten IB (und so manch anderer) werden Aufzählungszeichen nicht richtig verarbeitet. Hier ist das beim Feld "Antrieb" zu sehen. Ohne vorherigen Text wird der Stern aus dem Quelltext auch als Stern ausgegeben, steht da irgendetwas (hier habe ich die Wörter "ab 1950:" davorgesetzt) davor, wird das Aufzählungszeichen wie gewünscht angezeigt. Kann man dieser mangelhaften Anzeige abhelfen? Grüße, Grand-Duc (Diskussion) 03:03, 15. Mai 2016 (CEST)

Kann man, setze bitte ein <nowiki /> vor die Aufzählung. --Liebe Grüße, Lómelinde Diskussion 09:05, 18. Mai 2016 (CEST)

Vorlage:Hauptartikel

Hallo! Gibt es einen Grund, warum die Vorlage:Hauptartikel auf drei Einträge beschränkt ist? Viele Grüße, Knurrikowski (Diskussion) 12:30, 19. Mai 2016 (CEST)

Sicherlich, die Vorlage ist ja kein Ersatz für eine Navigationsleiste oder sonstige Linklisten.

Gegenfrage: Gibt es einen Grund dafür, dass man mehr als drei Hauptartikel zu einem Thema verlinken sollte, die man nicht auch schon normal in Quelltext über Wikilinks verlinken könnte? --Liebe Grüße, Lómelinde Diskussion 13:16, 19. Mai 2016 (CEST)

Es geht um die Programmiersprache BASIC in einem Heimcomputerartikel. Da gibt es manchmal mehr als nur 3 verschiedene BASIC-Versionen, die alle gleich wichtig sind - diese haben auch alle ihren eigenen Artikel. Deiner Gegenfragen-Logik nach dürfte es überhaupt keine solche Vorlage geben, denn man kann schließlich alles im Fließtext verlinken. Oder habe ich was übersehen? Viele Grüße, Knurrikowski (Diskussion) 13:47, 19. Mai 2016 (CEST)

Der dritte Hauptartikel wurde auf diese Diskussion hin eingebaut: Vorlage Diskussion:Hauptartikel#Drei Hauptartikel. --тнояsтеn ⇔ 14:22, 19. Mai 2016 (CEST)

Man könnte da auch einfach einen Abschnitt „siehe auch“ aufmachen, der kann mehr als drei Einträge haben. Nein ich habe nichts gegen diese Vorlage, ich benutze sie auch ganz gern. Man kann das ja auch etwas verteilen. Sag doch mal wo genau, dann schaue ich mal, wie ich es machen würde. So ist das etwas aus der Luft gegriffen. Was meine „Logik“ betrifft stimmt die mag etwas eigentümlich sein, ich bin halt eine Frau. --Liebe Grüße, Lómelinde Diskussion 14:38, 19. Mai 2016 (CEST)

Noch bei mir im Namensraum: https://de.wikipedia.org/wiki/Benutzer:Knurrikowski/600XL#Programmiersprachen_und_Anwendungsprogramme (dort Hochsprachen). Viele Grüße, Knurrikowski (Diskussion) 14:43, 19. Mai 2016 (CEST)

So als zweite Info müsste ich noch wissen zu welchen Artikeln du in diesem Abschnitt verlinken möchtest, dann kann ich mir eventuell etwas einfallen lassen. Atari (ST) mag ich übrigens. --Liebe Grüße, Lómelinde Diskussion 15:08, 19. Mai 2016 (CEST)

Ich hätte gern sowas:

Hauptartikel| Atari BASIC|titel1=Atari BASIC | BASIC A+|titel2=BASIC A+ | Atari Microsoft BASIC|titel3=Microsoft BASIC | Turbo-BASIC XL|titel4=Turbo-BASIC XL

Verlinkt wird auf Atari BASIC, BASIC A+, Atari Microsoft BASIC und Turbo-BASIC XL. Viele Grüße, Knurrikowski (Diskussion) 15:21, 19. Mai 2016 (CEST)

O.k. ich schau mal. --Liebe Grüße, Lómelinde Diskussion 15:32, 19. Mai 2016 (CEST)

Vorlage:Infobox Sendeanlage

Vielleicht kann bei dem Detailpunkt ein kundiger Vorlagenersteller weiterhelfen: In der Vorlage:Infobox Sendeanlage funktionieren manche REGION-ISO Einträge nach ISO 3166-2 nicht, beispielsweise der ISO-Code "FR-RE" liefert die Positionskarte für Frankreich (Europa) statt für Réunion im indischen Ozean. Anwendung der Vorlage beispielsweise in Artikel OMEGA-Sender Saint-Paul (siehe auch Versionsverlauf). Ähnliche Vorlagen wie Vorlage:Infobox Kraftwerk liefern hingegen bei selben REGION-ISO-Code die korrekte Positionskarte von Réunion, wie beispielsweise im Artikel Kraftwerk Port-Est. Offensichtlicher Fehler in der Vorlage:Infobox Sendeanlage ist nicht einfach zu erkennen. - Die Karten-Basisvorlagen wie die Vorlage:Info ISO-3166-2:FR-RE die dabei referenziert wird, dürften passen und hat die korrekte Positionskarte eingetragen.--wdwd (Diskussion) 22:07, 27. Jun. 2016 (CEST)

Die Vorlage bindet über Vorlage:Infobox Sendeanlage/POSKARTE die Positionskarte des übergeordneten Staates ein (außer für US, DE, CH), hier also die von Vorlage:Info ISO-3166-2:FR.

Es gibt den Parameter KEINE POSKARTE, der aber entgegen der Doku nicht nur die Positionskarte ausblendet, sondern auch die Artikelkoordinate. --тнояsтеn ⇔ 22:38, 27. Jun. 2016 (CEST)

Wozu soll diese Einschränkung denn gut sein? Sollte dringend entfernt werden. ÅñŧóñŜûŝî (Ð) 23:08, 27. Jun. 2016 (CEST)

Welche Einschränkung? Dass die Karte des übergeordneten Staates eingebunden wird? Dazu siehe Wikipedia:Fragen zur Wikipedia/Archiv/2016/Woche 24#sinnlose Karten. Die allerwenigsten erkennen Bundesstaaten oder Provinzen anhand ihrer Umrisse. Für die USA mit ihren teils eckigen Bundesstaaten ist die Sinnhaftigkeit schon zu bezweifeln.

• 
  Wer…
• 
  …kennt…
• 
  …diese…
• 
  …Gebilde?

Hilfreich wäre sicher ein Parameter zum Einbinden einer abweichenden Positionskarte, wie z. B. POSKARTE in Vorlage:Infobox Berg. --тнояsтеn ⇔ 08:19, 28. Jun. 2016 (CEST)

Ein derartiges Problem löst man meistens mit einer zweiteiligen Karte: über die Detailkarte wird in einer Ecke eine (einfache) kleine Übersichtskarte gelegt. Bei den hier gezeigten annähernd quadratischen Gebieten zwei, einmal die Ecke oben-links und einmal die Ecke unten-rechts. ÅñŧóñŜûŝî (Ð) 21:07, 28. Jun. 2016 (CEST)

Hmm, leider werde ich als Unwissender da nun auch nicht viel schlauer. Es geht mir nicht darum, ob man diese Kartengebilde erkennen kann, das sei mal vorrausgesetzt. Frage anders gestellt: Was muss ich in dieser (in der Struktur offensichtlich verbauten) Vorlage:Infobox Sendeanlage und/oder deren Unterseiten umstellen, dass nicht wie hier eine falsche Positionskarte (Karte von Frankreich) eingeblendet wird, sondern die Positionskarte aus Vorlage:Info ISO-3166-2:FR-RE (Karte von Réunion) genommen wird? Der Parameter REGION-ISO=FR-RE ist in der Artikelversion gesetzt, das sollte so passen.--wdwd (Diskussion) 21:45, 28. Jun. 2016 (CEST)

Dazu muss man dafür sorgen, dass die Positionskarte nicht mehr nach ISO-3166-1, also dem Staat, ausgewählt wird. ÅñŧóñŜûŝî (Ð) 23:42, 28. Jun. 2016 (CEST)

Aha, ich glaube die Intention zu verstehen. ok, danke.--wdwd (Diskussion) 09:19, 29. Jun. 2016 (CEST)

wdwd, bitte auch noch die Doku um die neuen Parameter [8] ergänzen. --тнояsтеn ⇔ 18:20, 1. Jul. 2016 (CEST)

Ist in Arbeit, bitte um etwas Geduld :-) --wdwd (Diskussion) 18:23, 1. Jul. 2016 (CEST)

OK. OMEGA-Sender Saint-Paul meckert jetzt übrigens: Warnung: Vorlage:Infobox Sendeanlage/POSKARTE ruft Vorlage:Positionskarte mit mehr als einem Wert für den Parameter „maptype“ auf. Nur der letzte angegebene Wert wird verwendet. --тнояsтеn ⇔ 18:25, 1. Jul. 2016 (CEST)

Erledigt, danke. --тнояsтеn ⇔ 19:06, 1. Jul. 2016 (CEST)

Den Parameter KEINE POSKARTE, der nur ein Mal benutzt wird ([9]), könnte man auch entfernen. Stattdessen POSKARTE=keine einbauen. --тнояsтеn ⇔ 18:29, 1. Jul. 2016 (CEST)

In den Kopiervorlagen würde ich die neuen Parameter nicht unbedingt listen. In der Mehrzahl der Verwendungen ist man mit der automatisch eingebundenen Positionskarte gut bedient. --тнояsтеn ⇔ 19:05, 1. Jul. 2016 (CEST)

Ist im Hinblick auf die vielfache Einbindung minimal-invasiv umgestellt.--wdwd (Diskussion) 19:38, 1. Jul. 2016 (CEST)

Danke für deine Arbeit! --тнояsтеn ⇔ 19:49, 1. Jul. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: wdwd (Diskussion) 19:38, 1. Jul. 2016 (CEST)

cellpadding und cellspacing in den Vorlagen Bausteindesign

Mag jemand die in HTML5 obsoleten Attribute cellspacing und cellpadding in den Vorlagen {{Bausteindesign}}, {{Bausteindesign1}} usw. durch die entsprechenden CSS-Eigenschaften ersetzen? Das erzeugt im Moment auf tausenden Seiten fehlerhaftes Markup. --schulhofpassage 15:34, 19. Mai 2016 (CEST)

Sehr gern, aber dann bitte auch gleich:

• TemplateData für alle; wenn VE mal in den WPNR kommt
• per Kategorie:Vorlage:Metadokumentation geteilt und einheitlich
  • in Vorlage:Bausteindesign1/core die einheitliche Programmierung mit Design-spezifischem style plus individuellem Einbindungs-style und class
  • in Vorlage:Bausteindesign1/doku die einheitliche Doku mit #tag: für TemplateData und textlich übermitteltem spezifischem Merkmal/Zweck
• ohne die bisherigen /Doku und /Meta

LG --PerfektesChaos 16:21, 19. Mai 2016 (CEST)

TemplateData für eine Vorlage, die nur für die Verwendung in Vorlagen gedacht war, halte ich für übertrieben. Der Umherirrende 19:26, 19. Mai 2016 (CEST)

So wie ich es verstanden habe, kann man das nicht so einfach ersetzen, weil es eine eigene Klasse bräuchte, die aber wieder andere Dinge mit sich bringt.

Das cellpadding kann man nur loswerden, in dem man ein padding für jede Zelle der Tabelle macht, dies würde einiges an Änderungsaufwand in Vorlagen erzeugen.

Das cellspacing lässt sich noch im Inline-Style lösen: Bei altem Wert 0 wird es border-collapse: collapse; border-spacing: 0;, bei Werten ungleich 0 wohl border-collapse: separate; border-spacing: ?px;. Aber bevor man das ändert, sollten noch ein paar Meinungen eingeholt werden. Der Umherirrende 19:26, 19. Mai 2016 (CEST)

Das stimmt im Wesentlichen:

1. Der 1:1-Ersatz für cellpadding="?" wäre style="padding: ?px" an jeder einzelnen Zelle der Tabelle. Mit einem einfachen Edit in der Vorlage ist das nicht erreichbar, da die Vorlage nur einmal im Tabellenkopf eingebunden ist.
2. Laut HTML5-Stylesheet gilt für Tabellenzellen standardmäßig padding: 1px. Daher hätte das ersatzlose Entfernen von cellpadding="0" nur geringfügige sichtbare Auswirkungen, die bei den angesprochenen Vorlagen wohl akzeptabel wären.
3. Der 1:1-Ersatz für cellspacing="?" wäre style="border-spacing: ?px" für die gesamte Tabelle, in Verbindung mit style="border-collapse: separate" (was aber sowieso der Initialwert ist und deshalb nicht explizit eingefügt werden sollte). Damit ginge aber die Unterstützung für IE 6 und IE 7 verloren, da border-spacing als CSS-Eigenschaft im IE erst ab Version 8 unterstützt wird. Für mich kein Problem, aber es schadet nicht, das zu wissen.
4. In Spezialfällen kann man den visuellen Effekt von cellspacing="0" auch durch style="border-collapse: collapse" erreichen (und dies funktioniert auch in IE 6 und IE 7), es ist aber nicht genau dasselbe, sondern hat weitere Wirkungen. Unter anderem deaktiviert es auch das padding der gesamten Tabelle und wird auf Untertabellen vererbt.

Gruß --Entlinkt (Diskussion) 20:03, 19. Mai 2016 (CEST)

PS: Vielleicht sollte man auch hier mal wieder sagen, dass der tatsächliche praktische Nutzen solcher Änderungen wahnsinnig gering ist und sich im Wesentlichen auf den psychologischen Effekt beschränkt, dass ein HTML5-Validator keine Fehlermeldungen ausgibt. Die HTML5-Spezifikation sagt zwar nämlich einerseits, dass Autoren diese veralteten Attribute nicht mehr verwenden dürfen, legt andererseits aber auch fest, dass jeder Browser sie weiter unterstützen muss (ein Browser, der das nicht täte, wäre nicht HTML5-konform). Durch solche Änderungen kann sogar ein Schaden entstehen, indem sich bei mangelnder Vorsicht das Aussehen von Objekten in unerwünschter Art und Weise verändert.

In Vorlage:Vorlage ist übrigens erst kürzlich aus rein optischen Gründen das HTML5-konforme <code>-Element durch das nicht HTML5-konforme <tt> ersetzt worden. Daher bin ich noch nicht einmal sicher, ob formale HTML5-Konformität überhaupt Konsens ist. --Entlinkt (Diskussion) 22:25, 19. Mai 2016 (CEST)

Mal eine andere Frage: Von den 13 Vorlagen {{Bausteindesign1}} bis {{Bausteindesign13}} haben manche einen Parameter class, der in manchen Fällen sogar dokumentiert ist. Darüber hinaus haben manche einen Parameter style, der ebenfalls in manchen Fällen dokumentiert ist. Zusätzlich haben manche aber auch noch einen unbenannten Parameter 1, der ein Synonym für style und in keinem einzigen Fall dokumentiert ist.

Wäre es nicht sinnvoll, den nirgends dokumentierten Parameter 1 überall durch style zu ersetzen? Mir erscheinen benannte Parameter hier sinnvoller. Gruß --Entlinkt (Diskussion) 23:49, 19. Mai 2016 (CEST)

Ich habe die Parametervereinheitlichung durchgezogen (statt dem undokumentierten 1 und dem manchmal dokumentierten style gibt es jetzt nur noch style) und die Parameter auch auf den Dokumentationsseiten nachgetragen, wo dies nicht der Fall war.

Das Thema der veralteten Attribute wurde übrigens bereits unter Wikipedia:WikiProjekt Vorlagen/Werkstatt/Archiv 2012/3#Vorlage:Bausteindesign ff und HTML5 diskutiert, damals ohne Ergebnis. --Entlinkt (Diskussion) 18:18, 20. Mai 2016 (CEST)

Kann man das nicht eleganter mit Hilfe von CSS-Klassen realisieren? Wenn die Tabelle z. B. eine Klasse namens "paddingcells" bekommt, dann könnte man doch in den WP-eigenen Dateien passende Angaben einstellen. ÅñŧóñŜûŝî (Ð) 23:47, 20. Mai 2016 (CEST)

Ja, eine sehr gute Idee, auf der Zielgeraden zur Implementierung von phab:T483 noch einmal das tote Pferd „Definition neuer Klassen in MediaWiki:Common.css“ zu reiten. Auf die Idee ist natürlich noch niemand gekommen. Garantiert nur vorläufiger Endausbauzustand sähe vielleicht so aus:

table.paddingcells-0 > * > tr > td,
table.paddingcells-0 > * > tr > th {
	padding: 0;
}
table.paddingcells-1px > * > tr > td,
table.paddingcells-1px > * > tr > th {
	padding: 1px;
}
table.paddingcells-2px > * > tr > td,
table.paddingcells-2px > * > tr > th {
	padding: 2px;
}
table.paddingcells-3px > * > tr > td,
table.paddingcells-3px > * > tr > th {
	padding: 3px;
}
table.paddingcells-4px > * > tr > td,
table.paddingcells-4px > * > tr > th {
	padding: 4px;
}
table.paddingcells-5px > * > tr > td,
table.paddingcells-5px > * > tr > th {
	padding: 5px;
}

Natürlich nur, bis sich jemand beschwert, dass px nicht mit der Schrift skaliert. Dann gibt es dasselbe nochmal in em. Und sicher wird auch irgendwann jemand verlangen, dass das Ganze nach horizontalem und vertikalem Padding aufgeteilt wird.

Ne, ne, das lassen wir mal schön bleiben. Im Vergleich dazu ist es besser, es noch eine Weile mit ein paar veralteten Attributen auszuhalten, bis eine Lösung möglich wird, die tatsächlich besser ist. Die veralteten Attribute tun nämlich überhaupt niemandem weh, man bemerkt sie nur, wenn man einen Validator benutzt. Das muss man aber gar nicht. --Entlinkt (Diskussion) 00:08, 21. Mai 2016 (CEST)

Wenn es so unwichtig ist, warum dann überhaupt diese Diskussion? Nebenbei: Für diese HTML4-Attribute sind nach meiner Kenntnis nur Pixel und Prozent als Länge zulässig. Ein Ersatz würde also gar kein em oder en benötigen. Aber es ist hier wohl besser, alles zu belassen. ÅñŧóñŜûŝî (Ð) 14:05, 21. Mai 2016 (CEST)

Diese Diskussion gibt es deshalb, weil die Vorlagen derzeit nicht-valides Markup erzeugen und dies manche Leute stört (ohne dass genauer gesagt wird, warum es stört). Solange die Vorlagen nicht-valides Markup erzeugen, wird es die Diskussion auch immer wieder geben. Daraus kann man aber nicht schließen, dass etwas geändert werden muss, sondern es sollte nur geändert werden, wenn der dadurch hergestellte neue Zustand besser als der bisherige ist. Für die Bewertung, was besser ist, zählt unter anderem auch die Validität des Markups, aber nicht ausschließlich.

Meiner Meinung nach liegt das Problem dieser Vorlagen übrigens wesentlich tiefer und fängt schon damit an, dass sie Attribute für einen Tabellenkopf vorgeben, ohne die Tabelle selbst zu erzeugen. Das ist eine IMHO sehr schlechte Designentscheidung, die dazu führt, dass man an jeder Stelle, wo man diese Vorlagen verwenden will, eine eigene Tabelle erzeugen muss; das wiederum führt dazu, dass die Attribute der Tabelle vom Grundgerüst der Tabelle getrennt sind; dadurch erst kommt es zustande, dass man cellpadding nicht zentral ersetzen kann.

Dieses Problem sollte nicht dadurch umgangen werden, dass man cellpadding durch eine gleichwertige CSS-Klasse ersetzt (das wäre nur alter Wein in neuen Schläuchen), sondern tatsächlich gelöst werden, zum Beispiel durch einen Vorlagenaufbau nach dem Vorbild von en:Template:Mbox. Wenn wir so eine Metavorlage hätten, hätten wir überhaupt kein Problem mit cellpadding. Dafür müsste man aber alle Orte umarbeiten, an denen unsere jetzigen Vorlagen eingebunden sind. Das ist ziemlich viel Arbeit. --Entlinkt (Diskussion) 14:33, 21. Mai 2016 (CEST)

⇐⇐ In dem Punkt sind wir uns einig. Daraus kann man eigentlich nur folgern, die Bausteindesign-Vorlagen in den Tabellenköpfen (der Vorlagen, welche sie einbinden) durch passende individuelle CSS-Angaben zu ersetzen. in den allermeisten Fällen sind Bausteine einzeilige Tabellen mit ein- oder zwei Zellen. Da sehe ich sowieso keinen Sinn darin, ein cellspacing="8px" einzufügen. Die wenigen Zellen kann man auch direkt mit CSS versehen. Du kannst ja mal schauen, ob du ein paar wichtige vollgeschützte Bausteine umgestaltest. beispielsweise Vorlage:Dieser Artikel, Vorlage:Begriffsklärungshinweis, Vorlage:Lizenzdesign1 bis 4, Vorlage:Weiterleitungshinweis u. a. Gruß von ÅñŧóñŜûŝî (Ð) 22:51, 21. Mai 2016 (CEST)

Antonsusi ist gerade dabei, die Bausteindesign-Vorlagen zu substituieren – mit leerer Kommentarzeile (einzige Ausnahme: Kommentar „HTML5“), als „kleine Änderung“ markiert und gespickt mit weiteren Veränderungen. Ich halte dies unter keinen Umständen für das Ergebnis dieser Diskussion und widerspreche sehr deutlich der Äußerung, mir in diesem Punkt mit Antonsusi einig zu sein.

Mein letzter Vorschlag lautete, wahlweise entweder überhaupt gar nichts zu tun oder aber die Vorlagen durch einen Aufbau vergleichbar mit en:Template:Mbox abzulösen. Die Substitution der Vorlagen bewirkt so ziemlich genau das Gegenteil meiner Intentionen, daher distanziere ich mich davon. --Entlinkt (Diskussion) 23:16, 21. Mai 2016 (CEST)

Dann habe ich dich wohl falsch verstanden. Du hast geschrieben: "Meiner Meinung nach liegt das Problem dieser Vorlagen übrigens wesentlich tiefer und fängt schon damit an, dass sie Attribute für einen Tabellenkopf vorgeben, ohne die Tabelle selbst zu erzeugen." Darauf habe ich mich mit "in diesem Punkt einig" bezogen und die logische Folge ist es, die Attribute in die Vorlage zu schreiben, welche die Tabelle erzeugt. Genau das habe ich getan. Die Bausteinvorlagen enthalten eine feste Pixelangabe für cellpadding und cellspacing. Wenn man das ohne den ganz großen Umbruch weghaben will, dann muss man es durch individuellen Ersatz so machen, wie ich. Die große Lösung mit einem Bündel an Lua-Modulen erscheint mir hier nur schwer umsetzbar. ÅñŧóñŜûŝî (Ð) 23:42, 21. Mai 2016 (CEST)

@Antonsusi: Diskussionsbeiträge von mir stellen grundsätzlich niemals eine auch nur irgendwie geartete Aufforderung an dich dar, Edits – egal welche – vorzunehmen. Ich dachte, das hätten wir schon mal geklärt, aber das Muster scheint sich endlos zu wiederholen.

Also nochmal von vorn: An den Vorlagen ist durch HTML5 keinerlei Änderungszwang entstanden. Vielmehr ist durch HTML5 vorgeschrieben, dass die Attribute cellpadding und cellspacing durch Browser weiterhin unterstützt werden müssen. Es ist natürlich keinesfalls die Intention der HTML5-Spezifikation, dass unter Berufung auf diese Spezifikation Vorlagen in der Wikipedia substituiert werden! Vielmehr ist es die Intention der HTML5-Spezifikation, dass Darstellungsfragen in Zukunft durch CSS (und zwar in erster Linie „echtes“ CSS, nicht Inline-style-Attribute) auf der Grundlage von semantischem Markup geregelt werden.

Leider haben wir durch MediaWiki keine Unterstützung für „echtes“ CSS in Vorlagen (noch nicht – siehe phab:T483), und Inline-style-Attribute bieten keinen gleichwertigen Ersatz für cellpadding. HTML5 geht aber davon aus, dass „echtes“ CSS verfügbar ist. Also sind bereits die Voraussetzungen, von denen die HTML5-Spezifikation ausgeht, bei uns nicht erfüllt. Daher geht es schon in Richtung einer Perversion, unter Berufung auf HTML5 die Vorlagen zu substituieren!

Es sollte eine Selbstverständlichkeit sein, dass die Vorlagen nicht substituiert werden. Sie wurden vor 11 Jahren geschaffen, um für ein einheitliches Erscheinungsbild der Bausteine zu sorgen und sollten deshalb natürlich als Vorlagen erhalten bleiben. Sie funktionieren einwandfrei und würden auch die nächsten 11 Jahre ohne grundsätzliche Änderung einwandfrei funktionieren. Durch die Substitution wird die Einheitlichkeit konterkariert, daher stellt sie eine gravierende Verschlechterung dar.

Meinen Umgestaltungsvorschlag hast du anscheinend nicht verstanden – mir geht es in keinster Weise um Lua oder sonstwelche Implementierungsdetails von en:Template:Mbox, sondern ausschließlich um den grundsätzlichen Aufbau, dass die Vorlagen ihr Tabellengerüst selbst erzeugen. Dies hat eine ganze Reihe von Vorteilen, unter anderem könnte man das cellpadding leicht ersetzen (was nicht wirklich notwendig ist, aber dann leicht möglich wäre); vor allem aber könnte man zu einem späteren Zeitpunkt leicht die Tabellen durch ein <div>-Gerüst ersetzen.

Noch genauer werde ich dir die Umgestaltungsidee nicht erklären, da dies darauf hinausliefe, dass ich die Idee komplett implementiere, wofür ich aber keine Zeit habe. Ich denke, dass die meisten Leute auch so verstehen werden, was ich meine.

Dies wäre allerdings ein längerfristiges Projekt. Das kannst du auf keinen Fall mal so nebenbei schnell-schnell erledigen, nur weil sich gerade mal wieder jemand über die Attribute beschwert hat. Diese Beschwerden über Attribute muss man einfach aushalten, ohne sie zum Anlass für Verschlechterungen zu nehmen. HTML5 soll ein Anlass für Verbesserungen sein! --Entlinkt (Diskussion) 00:40, 22. Mai 2016 (CEST)

Ein paar Leckerbissen dieser Editaktion:

• Verdoppelte Rahmenstärke, 99% Breite
• 99% Breite
• 99% Breite
• Horizontale Linie über die gesamte Breite, aber Hintergrund viel schmaler
• 99% Breite
• Plötzlich doch 100% Breite, woher der Sinneswandel?
• Verschütt gegangenes Padding, Text klebt am Rand
• Dito
• usw. usf.
• Krönender Abschluss: 3 Pixel pechschwarzer Rahmen für wikitable in der eigenen monobook.css

Wie soll man mit solchen Editaktionen umgehen? Das Phänomen ist ja nicht neu. Durchaus ernst gemeinte Frage. --Entlinkt (Diskussion) 04:34, 22. Mai 2016 (CEST)

Ich habe einen Pauschalrevert der Substitutionen vorgenommen: [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28].

Die Substitutionen betrafen 19 Vorlagen, die ihrerseits wiederum {{Bausteindesign1}} und {{Bausteindesign2}} einbinden und gemeinsam etwas über 30.000 Einbindungen aufweisen. Reine Substitionen waren das auch gar nicht in allen Fällen, sondern es wurden in vielen Fällen unkommentierte Änderungen des Aussehens beigemischt. Besonders populär waren Vergrößerungen der Schrift und Verringerungen der Breite von 100% auf 99% (kein Scherz).

Dieser Ansatz ist aus den folgenden Gründen falsch gewesen: Erstens löste er das Problem des Vorkommens von cellpadding und cellspacing nicht, da die Vorlagen {{Bausteindesign1}} und {{Bausteindesign2}} gemeinsam über 300.000 Einbindungen haben (d. h. das Ziel wurde ca. um den Faktor 10 verfehlt). Zweitens konterkarierte er den Zweck der Vorlagen, für ein einheitliches Design der Bausteine zu sorgen, und zwar nicht nur passiv (wie es bei reinen Substitutionen der Fall gewesen wäre), sondern aktiv (indem das Aussehen der Vorlagen gezielt und absichtlich verändert wurde).

Ich mache auch an dieser Stelle wieder einmal keinen Hehl daraus, dass das grundsätzliche Problem mit solchen Aktionen meiner Meinung nach durch eine Benutzersperre zu lösen wäre und immer wieder auftreten wird, falls sich niemand für diesen Schritt entscheidet. --Entlinkt (Diskussion) 16:15, 22. Mai 2016 (CEST)

Poskarte mit Relief

Wie bekomme ich bei Fort McMurray eine Poskarte mit Reliefdarstellung hinein? In der Vorlagenbeschreibung habe ich dazu nix gefunden. Dass es die Karte auch mit Relief gibt, sieht man im entsprechenden französischen Artikel.--Ratzer (Diskussion) 10:29, 6. Mai 2016 (CEST)

Dazu müsste die Vorlage:Infobox Ort in Kanada geändert werden. Sinn und Zweck von Infoboxen ist aber ja eben gerade das einheitliche Erscheinungsbild. Unter Vorlage Diskussion:Infobox Ort in Kanada#Unterdrücken/Ersetzen der Positionskarte? gabs schonmal eine Anfrage in eine ähnliche Richtung. --тнояsтеn ⇔ 08:02, 24. Mai 2016 (CEST)

Wikipedia:Bücher/Tests

Ich habe zu dieser Arbeitsliste zwei Fragen: Ich würde gern die Tabelle nach Nachname sortieren und dann auch so abspeichern (sie soll also beim Aufruf der Seite direkt nach Nachname sortiert sein). Zweitens sollen die Geburt- und Sterbedaten mit der Vorlage:FormatDate in die übliche Form gebracht werden, wie kann ich diese Vorlage am einfachsten einbauen? 92.75.220.203 20:25, 7. Jun. 2016 (CEST)

Eine Vorlage kann das nicht. Am einfachsten ist es wohl, die sortierte Tabelle zu exportieren und dann wieder in Wikipedia-Syntax umzuwandeln, FormatDate mit Suchen&Ersetzen einbauen. --mfb (Diskussion) 20:43, 7. Jun. 2016 (CEST)

Du meinst, die ganze HTML-Ausgabe kopieren? Und wie wandle ich das wieder in Wikisyntax um? 92.75.220.203 20:48, 7. Jun. 2016 (CEST)

Ich würde die im Browser angezeigte Tabelle (die normale HTML-Ausgabe ist nicht sortiert, da das in JavaScript sortiert wird) in eine Tabellenkalkulation kopieren. Von dort aus gibt es Konvertierungstools, oder alternativ dort den Code wieder mit Textfunktionen zusammensetzen. --mfb (Diskussion) 20:56, 7. Jun. 2016 (CEST)

Auch hier mal wieder Werbung für den VisualEditor: Dieser unterstützt Manipulationen von Tabellen, die in Wikitext kompliziert wären, auf recht einfache Weise. Insbesondere kann man über die Zwischenablage des Betriebssystems einfach Tabellen aus anderen Quellen reinkopieren und erhält direkt eine (auf wikitable basierende) Tabelle. Gruß --Entlinkt (Diskussion) 23:28, 7. Jun. 2016 (CEST)

Das löst aber nicht das Problem, dass ich ja zur Zeit gar nicht nach Familienname sortieren kann. 129.13.72.198 08:53, 8. Jun. 2016 (CEST)

Dazu sollte man die Namen in eine Vorlage packen (gibt eine für diesen Zweck, weiß nicht auswendig wie sie heißt). Hier Werbung für den normalen Editor, denn mit dem VisualEditor müsste man das bei jedem Namen einzeln machen statt Suchen&Ersetzen zu verwenden. --mfb (Diskussion) 23:21, 8. Jun. 2016 (CEST)

Textzentrierung der Überschriften bei erweiterten Navileisten different

Hallo, mir fällt immer wieder auf, z. B. hier, das bei (allen?!) Navi-Blöcken diejenigen Überschriften von Navileisten anders zentriert werden, die ein V (V – D) für die schnelle Bearbeitung im Titel führen. Offensichtlich wird die Überschrift nach Abzug des notwendigen Platzes für V (V – D) neu eingemittelt, was eine unschöne optische Verschiebung im Vergleich zu den anderen Überschriften bewirkt. Wünschenswert wäre eine absolute Zentrierung über die ganze Breite ohne Rücksicht auf V (V – D), oder? --Wi-luc-ky (Diskussion) 11:26, 30. Mai 2016 (CEST)

Ebenso bei den "Ausklappen"-Links, wobei es da nicht so auffällt. --nenntmichruhigip (Diskussion) 11:51, 30. Mai 2016 (CEST)

Der Effekt ist im Prinzip seit vielen Jahren bekannt, siehe:

1. Vorlage Diskussion:Navigationsleiste/Archiv/1#Zentrierung Titel funktioniert nicht vollständig (2007)
2. Vorlage Diskussion:Navigationsleiste/Archiv/1#Padding (2012)

Zunächst mal betrifft er durch den „Ausklappen“-Link auf der rechten Seite alle Navileisten, aber einheitlich. Diejenigen Navileisten, die mittels der Vorlage {{Erweiterte Navigationsleiste}} erstellt wurden, haben aber auch auf der linken Seite Buttons, die standardmäßig ausgeblendet sind (insbesondere für alle unangemeldeten Leser) und durch das Gadget MediaWiki:Gadget-Erweiterte-Navigationsleiste-Quicklinks bzw. MediaWiki:Gadget-Erweiterte-Navigationsleiste-Quicklinks.css eingeblendet werden können. Dadurch erst entsteht die Uneinheitlichkeit.

Ich würde hier nichts ändern, da das Problem der uneinheitlichen Darstellung nur die wenigen Benutzer des Gadgets betrifft (laut Special:GadgetUsage sind das momentan läppische 162 aktive Benutzer). Im Übrigen wusste derjenige Mitarbeiter, der damals die Vorlage {{Erweiterte Navigationsleiste}} und das Gadget gepusht hat, dass seine Werke inkonsistent zur sehr viel älteren und etablierteren Vorlage {{Navigationsleiste}} sind. Anstatt behutsam an der Verbesserung der bestehenden Vorlage zu arbeiten, hat er es damals vorgezogen, ein Konkurrenzprodukt zu erstellen und massiven Druck auf Admins auszuüben, die bestehende Vorlage an das neue Konkurrenzprodukt anzupassen. Diese Strategie ist natürlich nicht aufgegangen, mit dem vorhersehbaren Ergebnis einer uneinheitlichen Darstellung.

Für das grundlegendere Problem, das ja auch die klassische Vorlage {{Navigationsleiste}} betrifft, gibt es verschiedene Lösungsansätze, die aber alle irgendwelche Nachteile haben. Zudem besteht die derzeitige Darstellung seit über 10 Jahren und ist auch nicht wirklich falsch. Denjenigen, die sich an der uneinheitlichen Darstellung stören, würde ich einfach empfehlen, das Gadget abzuschalten. --Entlinkt (Diskussion) 12:28, 30. Mai 2016 (CEST)

Den billigen Klappkasten „behutsam verbessern“ ist mal ein schöner Euphemismus für „in der Entwicklung stehenbleiben“! Sorry, aber ich habe null Verständnis dafür, dass wir hierzuwiki noch immer keine 100%ig funktionierende Entsprechung zur international etablierten Navbox haben; klar kriegt dann der einzige, der das einigermaßen hingekriegt hat, die Schuld an allem Möglichen zugeschoben. Ich finde das unmöglich, aber gehört wohl zu den vielen Dingen, die ich leider nicht ändern kann.--XanonymusX (Diskussion) 13:43, 30. Mai 2016 (CEST)

Mit dieser Reaktion habe ich ehrlich gesagt gerechnet. Sie passt wunderbar ins Bild, das die Befürworter der Vorlage {{Erweiterte Navigationsleiste}} seit jeher von sich abgeben: Nur Gebashe, dass die sehr viel ältere und sehr viel öfter benutzte Vorlage {{Navigationsleiste}} nicht mit der Neuentwicklung kompatibel sei und an die Neuentwicklung angepasst werden müsse, plus Gebashe, dass die Admins dabei nicht helfen, aber keine konkreten, funktionierenden Lösungsvorschläge.

Vielleicht noch etwas Info, falls jemand tatsächlich versuchen möchte, an dem Thema zu arbeiten. Es sind Konstellationen zu berücksichtigen, die sich in mindestens drei Dimensionen unterscheiden:

1. {{Erweiterte Navigationsleiste}} vs. {{Navigationsleiste}} (erstere hat auch Buttons auf der linken Seite, letztere nicht)
2. JavaScript aktiviert vs. JavaScript nicht aktiviert (die Buttons auf der rechten Seite werden durch JavaScript erzeugt)
3. Quicklinks-Gadget aktiviert vs. Quicklinks-Gadget nicht aktiviert (die Buttons auf der linken Seite werden nur durch das Gadget sichtbar)

Das ergibt nach Adam Riese mindestens $2^{3}=8$ verschiedene Konstellationen, die jeder Verbesserungsversuch berücksichtigen müsste. Obwohl das Thema schon einige Male auf der Tagesordnung war, habe ich bis jetzt noch keinen Vorschlag gesehen, der in allen 8 Konstellationen eine Verbesserung darstellt oder diese auch nur berücksichtigt.

Meiner ganz persönlichen, höchst subjektiven Meinung nach sollte man die Situation einfach so hinnehmen, wie sie ist und für die Zukunft daraus lernen, dass so etwas wie die Einführung der Vorlage {{Erweiterte Navigationsleiste}} nicht mehr passieren darf. Durch ihre Einführung ist ein ursprünglich ziemlich simples Problem heftig potenziert worden und eine einfache Lösung in weite Ferne gerückt, weshalb ich die Einführung bis heute rundweg ablehne. --Entlinkt (Diskussion) 13:54, 30. Mai 2016 (CEST)

Die Lösung ist mE ganz einfach: en:Template:Navbox unverändert nach deWP übernehmen, natürlich inklusive notwendiger Anpassungen der CSS. Das wäre ein Ansatz, die zurzeit konkurrierenden Vorlagen zusammenzuführen und auf ein zeitgemäßes technisches Level zu heben. Bloßes „Bashen“ liegt mir fern, aber manche Kommentare finde ich einfach frustrierend.--XanonymusX (Diskussion) 14:04, 30. Mai 2016 (CEST)

Der sogenannte „billige Klappkasten“ Vorlage:Navigationsleiste hat ca. eine halbe Million Einbindungen und funktioniert perfekt. Die Neuentwicklung Vorlage:Erweiterte Navigationsleiste hat dagegen nur ca. 50.000 Einbindungen und unzählige Bugs (Beispiel). Den Quellcode versteht kein Mensch. Deshalb arbeitet auch niemand ernsthaft daran.

Der sogenannte „billige Klappkasten“ hat den unschätzbaren strukturellen Vorteil, dass er nur einen Rahmen vorgibt, der beliebigen Inhalt haben kann. Daher hätte man die meisten Effekte der Vorlage {{Erweiterte Navigationsleiste}} auch erreichen können, indem man den „billigen Klappkasten“ verwendet und nur den Inhalt ausbaut. Stattdessen hat man aber eine Vorlage erstellt, die auch den Rahmen ersetzt. Dadurch erst sind die Inkonsistenzen entstanden.

Der Vorschlag, die englische Vorlage zu übernehmen, hat sich um einige Jahre überlebt. Diese Option wurde durch die „eigenmächtige“ Einführung der Vorlage {{Erweiterte Navigationsleiste}} verballert. Hätte man damals die englische Vorlage übernommen, hätte man zwei inkompatible Systeme parallel gehabt. Würde man die englische Vorlage allerdings jetzt übernehmen, hätte man drei inkompatible Systeme parallel. Daher ist die Übernahme der englischen Vorlage durch die Einführung der Vorlage {{Erweiterte Navigationsleiste}} auf viele Jahre hinaus extrem unwahrscheinlich geworden.

Ich habe bis zum heutigen Tage von keinem Befürworter irgendwelcher struktureller Änderungen – sei es die Einführung der Vorlage {{Erweiterte Navigationsleiste}} oder die Übernahme der englischen Vorlage – ein Konzept gesehen, was mit der halben Million Einbindungen der Vorlage {{Navigationsleiste}} passieren soll. Offensichtlich wurde noch nicht einmal eruiert, ob strukturelle Änderungen überhaupt konsensmäßig erwünscht sind. Stattdessen will man weiterhin mit unpraktikablen Vorschlägen mit dem Kopf durch die Wand. Ist dir überhaupt bekannt, dass die englische Vorlage auch ein eigenes JavaScript besitzt, das nicht mit unserer jetzigen Lösung zusammenarbeitet? --Entlinkt (Diskussion) 14:28, 30. Mai 2016 (CEST)

Zum letzten Punkt: Ja, ist mir bekannt. Wie gesagt, konnte sich international etablieren, und wir bleiben auf dem billigen Klappkasten (verwenden wir das ruhig weiter) sitzen. Ich verstehe, dass eine Weiterentwicklung der einen Vorlage für die Einheitlichkeit besser gewesen wäre, aber wenn bei einer vollgesperrten Vorlage der Änderungsunwille so groß wie hier ist, wären manche Navis noch immer ein unüberschaubarer Haufen von halbherzigen Überschriftskonstrukten, hätte nicht jemand die Initiative ergriffen. Und ja, er hatte ursprünglich die englische Vorlage übernommen, musste dann aber für die fehlenden CSS- und JS-Stützen Workarounds basteln, die durchaus unbefriedigend sind. Na ja, besser als nix. Was das Nach-und-Nach-Umstellen angeht: Wäre wie alles in WP langwierig, aber mE nicht unmöglich.--XanonymusX (Diskussion) 15:12, 30. Mai 2016 (CEST)

Da die etablierte Vorlage {{Navigationsleiste}} weiterhin als „billiger Klappkasten“ diffamiert wird und weiterhin mit dem Täuschungsargument gearbeitet wird, dass die Einführung der {{Erweiterte Navigationsleiste}} notwendig gewesen sei, um bestimmte Effekte zu erzielen, habe ich als Gegenbeweis mal auf der Grundlage des unveränderten „billigen Klappkastens“ eine Navileiste erstellt, die eine beliebige Infobox und die Letzten Änderungen enthält:

Beweis der Tatsache, dass die unveränderte „herkömmliche“ Vorlage:Navigationsleiste beliebigen Inhalt haben kann

Beispielhausen EksemplecyVorlage:Infobox Ortsteil einer Gemeinde in Deutschland/Wartung/Alternativname Ortsgemeinde Enkenbach-Alsenborn
Das tolle Wappen mit dem Wellenband
Koordinaten:	49° 29′ N, 7° 54′ O49.4866666666677.9033333333333345
Höhe:	345 (292–500) m ü. NHN
Fläche:	11,6 km²
Einwohner:	2500 (31. Dez. 2006)
Bevölkerungsdichte:	216 Einwohner/km²
Eingemeindung:	7. Juni 1969
Eingemeindet nach:	Fürth
Postleitzahlen:	67677, 67678
Vorwahlen:	06303, 06304
Karte Beispielhausen im hellroten Fleck
Beispielhausen Beispielhausen

Liste von Abkürzungen:

D

Wikidata-Bearbeitung

N

Neue Seite (siehe auch die Liste neuer Seiten)

K

Kleine Änderung

B

Änderung durch einen Bot

!

Nicht-kontrollierte Änderung

(+543)/(−792)

Änderung der Seitengröße in Bytes

17. November 2024

• UnterschiedVersionen Wikipedia Diskussion:Persönliche Bekanntschaften/neue Anfragen 19:57 +349 Euku Diskussion Beiträge (→Bot: Antwort) Markierung: Antwort
• UnterschiedVersionen Wikipedia Diskussion:WikiProjekt KI und Wikipedia/KI-generierte Artikel 19:57 +268 Lantina Diskussion Beiträge (→Erfahrungen von WMCH: Antwort) Markierung: Antwort
• UnterschiedVersionen Jazz-Nekrolog 2016 19:57 +164 Mö1997 Diskussion Beiträge (→September: + |- | 24. September || Helmut Plattner || österreichischer Jazzmusiker (Trompete, auch Sopransaxophon, Komposition) || 76 ||)
• UnterschiedVersionen Alfred Gruber 19:57 +216 EinDao Diskussion Beiträge (Ergänzung) Markierung: Visuelle Bearbeitung
• UnterschiedVersionen K Bangerten 19:57 0 Wiegels Diskussion Beiträge (Minuszeichen durch Streckenstrich ersetzt)
• UnterschiedVersionen K The Taste/Staffel 13 19:57 +13 Yodas yodas yodas Diskussion Beiträge (→Die Teams und Platzierungen im Team)
• UnterschiedVersionen Wikipedia:Vandalismusmeldung 19:57 +195 Carol.Christiansen Diskussion Beiträge (→Benutzer:2A02:810B:48E:5D00:C807:EA4B:D906:43AC)
• UnterschiedVersionen Drachenvariante 19:57 +3 Versuchmachtklug Diskussion Beiträge (→Namensherkunft: typo) Markierung: Visuelle Bearbeitung
• UnterschiedVersionen K Dippach (Maroldsweisach) 19:57 −5 Mateus2019 Diskussion Beiträge (HC: Entferne Kategorie:Dorf in Deutschland; Ergänze Kategorie:Dorf in Bayern)
• UnterschiedVersionen Wikipedia:Vandalismusmeldung 19:57 +296 Lustiger seth Diskussion Beiträge (→Benutzer:Luckywiki1234: Antwort @Alabasterstein) Markierung: Antwort
• UnterschiedVersionen K Musée de la Résistance de Bondues 19:57 +72 Prüm Diskussion Beiträge (→Weblinks)
• UnterschiedVersionen Benutzer:Zieglhar/Johann Caspar Marget 19:57 +458 Zieglhar Diskussion Beiträge (→Leben)
• UnterschiedVersionen Wikipedia:WikiProjekt Kategorien/Diskussionen/2024/November/17 19:57 +1 Über-Blick Diskussion Beiträge (→Kategorie:Beruflicher Status)
• UnterschiedVersionen Helen Ware 19:57 −48 Senechthon Diskussion Beiträge (AllMovie)
• UnterschiedVersionen Maccabi Tel Aviv (Fußball) 19:57 +465 Rustikal Diskussion Beiträge (→Fans: Zitat ergänzt, Text angepasst)
• UnterschiedVersionen Diskussion:Schnellfahrstrecke 19:57 +337 Frank Althaus 1975 Diskussion Beiträge (→Aufräumen: Antwort) Markierungen: Mobile Bearbeitung Mobile Web-Bearbeitung Antwort
• UnterschiedVersionen K Dippersreuth 19:57 −5 Mateus2019 Diskussion Beiträge (HC: Entferne Kategorie:Dorf in Deutschland; Ergänze Kategorie:Dorf in Bayern)
• UnterschiedVersionen K ÖBB 5047 19:57 +276 RealKaiserschmarren Diskussion Beiträge (→Einsatz) Markierung: Visuelle Bearbeitung
• UnterschiedVersionen K Käfigturm 19:57 +132 Jed Diskussion Beiträge
• UnterschiedVersionen Nicola Tuthill 19:57 +252 Loper12321 Diskussion Beiträge
• UnterschiedVersionen Wahlen 2024 19:57 +20 Zukunft99 Diskussion Beiträge (Fix)
• UnterschiedVersionen K Märta Helena Reenstierna 19:57 −14 Mukeber Diskussion Beiträge (Änderungen von 95.29.152.108 (Diskussion) auf die letzte Version von Invisigoth67 zurückgesetzt) Markierung: Zurücksetzung
• UnterschiedVersionen Leoniden (Meteorstrom) 19:56 +433 Phrontis Diskussion Beiträge (+== Geschichte ==)
• UnterschiedVersionen Wikipedia:WikiProjekt Kategorien/Diskussionen/2024/November/17 19:56 +321 Über-Blick Diskussion Beiträge (Neuer Abschnitt ) Markierung: Neuer Abschnitt
• UnterschiedVersionen Bahnhof Biblis 19:56 +211 Bigbug21 Diskussion Beiträge (→Leit- und Sicherungstechnik: erg.)
• UnterschiedVersionen Furesø 19:56 +14 Uwe1959 Diskussion Beiträge (Volumen korrigiert)
• UnterschiedVersionen Wikipedia:Redaktion Film und Fernsehen 19:56 +222 Louis Wu Diskussion Beiträge (→Episoden Titel in Tabellen: Antwort) Markierung: Antwort
• UnterschiedVersionen Dicy 19:56 +4 Alraunenstern Diskussion Beiträge (→Sehenswürdigkeiten)
• UnterschiedVersionen The Very End 19:56 −17 KlausHeide Diskussion Beiträge (unbegründet/unbelegt...) Markierung: Manuelle Zurücksetzung
• UnterschiedVersionen Wikipedia:Fragen zur Wikipedia 19:56 +1 80.71.142.166 Diskussion (→Kategorie:Argentinischer Emigrant in Deutschland)
• UnterschiedVersionen Pasithea (Nereide) 19:56 +167 Der gut zu tanzen weiß Diskussion Beiträge (→Verwechslungsgefahr mit der Charis Pasithea: Belege fehlen)
• UnterschiedVersionen Bahnhof Hagen-Oberhagen 19:56 −3 Bernd Rohlfs Diskussion Beiträge
• UnterschiedVersionen Drachenvariante 19:56 +362 Versuchmachtklug Diskussion Beiträge (→Namensherkunft: Louis Paulsen 1880)
• UnterschiedVersionen Hjalmar Linder 19:56 +261 Aholtman Diskussion Beiträge (→Der erste Autobesitzer Finnlands?)
• UnterschiedVersionen K Battle Creek (Michigan) 19:56 0 Wiegels Diskussion Beiträge (Minuszeichen durch Bindestriche ersetzt)
• UnterschiedVersionen Portal:Spanien/Fehlende Artikel 19:56 +374 Atamari Diskussion Beiträge (→Medaillengewinner aus Spanien (Liste))
• UnterschiedVersionen Wikipedia:Fragen zur Wikipedia 19:56 +346 80.71.142.166 Diskussion (Neuer Abschnitt ) Markierung: Neuer Abschnitt
• UnterschiedVersionen Alexa Vega 19:56 +22 Karbohut Diskussion Beiträge (→Filmografie (Auswahl): + 1) Markierung: Visuelle Bearbeitung
• UnterschiedVersionen Marie Jakobowicz 19:56 +7 Alraunenstern Diskussion Beiträge (→Ausstellungen und Sammlungen (Auswahl))
• UnterschiedVersionen Bahnhof Hagen-Oberhagen 19:56 −4 Bernd Rohlfs Diskussion Beiträge
• UnterschiedVersionen Nekrolog 2004 19:56 +110 Mommpie Diskussion Beiträge (→Datum unbekannt)
• UnterschiedVersionen Appendix Sallustiana 19:56 +102 Brun Candidus Diskussion Beiträge (Link zum Digitalisat von Vat.lat. 3864 erg.)
• UnterschiedVersionen Nekrolog September 2016 19:56 +164 Mö1997 Diskussion Beiträge (→September: Helmut Plattner mit Helferlein hinzugefügt)
• UnterschiedVersionen Liste bekannter deutschsprachiger Emigranten und Exilanten (1933–1945) 19:56 +27 F. Peter Müller Diskussion Beiträge (→Bildende Kunst und Architektur) Markierung: Visuelle Bearbeitung
• UnterschiedVersionen K Holany 19:56 −6 AHZ Diskussion Beiträge
• UnterschiedVersionen K Wikipedia:Freiburg im Breisgau 19:55 +96 Gfis Diskussion Beiträge (Gfis)
• UnterschiedVersionen Stephanie Ratcliffe 19:55 +231 Loper12321 Diskussion Beiträge
• UnterschiedVersionen The Taste/Staffel 13 19:55 +758 Yodas yodas yodas Diskussion Beiträge Markierung: Visuelle Bearbeitung: Gewechselt
• UnterschiedVersionen K Bistum Basel 19:55 −57 Wiegels Diskussion Beiträge (Minuszeichen durch Bindestrich ersetzt)
• UnterschiedVersionen Nina Chuba 19:55 −572 Marabubalu Diskussion Beiträge (Die letzte Textänderung von Carlos23423 wurde verworfen und die Version 250386123 von Marabubalu wiederhergestellt. Revert, da keine valide Quelle.) Markierung: Manuelle Zurücksetzung

Die Vorschläge von Intforce/Weltforce sind unter anderem deshalb nicht umgesetzt worden, weil er andauernd mit Täuschungsargumenten Änderungen an geschützten Seiten verlangt hat, die in Wahrheit überhaupt nicht notwendig sind, um die gewünschten Effekte zu erzielen. Andauernd hieß es „die Admins blockieren“, dabei ging es ihm nur um das Pushen eines ganz bestimmten Vorlagenaufbaus, von dem man wusste, dass er zu den Problemen führen wird, die wir jetzt haben.

Wir sollten endlich mal aufhören, auch Jahre später noch auf diese Täuschungen hereinzufallen. Mit den Konsequenzen, die durch den völlig unnötigen Vorlagensplit entstanden sind, müssen wir nun allerdings leben. Gruß --Entlinkt (Diskussion) 15:24, 30. Mai 2016 (CEST)

PS: In die Täuschungsargumente reiht sich übrigens auch die ständig wiederholte Quatsch-Aussage ein, dass die „herkömmliche“ Vorlage {{Navigationsleiste}} aufgrund ihres Alters überarbeitungsbedürftig sei und {{Erweiterte Navigationsleiste}} einen technischen Fortschritt darstelle.

Das ist glatt gelogen. Die „herkömmliche“ Vorlage {{Navigationsleiste}} erlaubt zwar beliebigen Inhalt, wird aber meistens mit einer schlichten Aufzählung von Links gefüllt und hat daher kein Problem mit schmalen Bildschrimauflösungen. Beispiel:

Städte und Gemeinden im Alb-Donau-Kreis

Die angeblich „weiter entwickelte“ Vorlage {{Erweiterte Navigationsleiste}} arbeitet dagegen mit fest verdrahteten und ineinander verschachtelten Tabellen, einem hoffnungslos veralteten Design-Pattern aus den 1990er-Jahren, das zu massiven Problemen bei schmalen Bildschrimauflösungen führt. Beispiel:

• v
• d
• b

Rihanna

Studioalben	Music of the Sun A Girl like Me Good Girl Gone Bad Rated R Loud Talk That Talk Unapologetic Anti
Remixalben	Good Girl Gone Bad: The Remixes Rated R: Remixed Vinyl-Box-Set
Videoalben	Good Girl Gone Bad Live Good Girl Gone Bad – The Videos Loud Tour Live at the O₂ Rihanna 777 Documentary … 7Countries7Days7Shows
Singles	Music of the Sun Pon de Replay If It’s Lovin’ That You Want A Girl like Me SOS Unfaithful We Ride Break It Off Good Girl Gone Bad Umbrella Shut Up and Drive Hate That I Love You Don’t Stop the Music Take a Bow Disturbia Rehab Rated R Russian Roulette Hard Wait Your Turn Rude Boy Rockstar 101 Te amo Loud Only Girl (In the World) What’s My Name? Raining Men S&M Man Down California King Bed Cheers (Drink to That) Talk That Talk We Found Love You da One Talk That Talk Birthday Cake Where Have You Been Cockiness (Love It) Remix Unapologetic Diamonds Stay Pour It Up Loveeeeeee Song Right Now What Now Jump Anti Work Needed Me Kiss It Better Love on the Brain Sex with Me Weitere Singles Redemption Song FourFiveSeconds Towards the Sun Bitch Better Have My Money American Oxygen Sledgehammer Lift Me Up Weitere Lieder Breakin’ Dishes Complicated Fading Love the Way You Lie (Part II)
Featurings	Roll It If I Never See Your Face Again Just Stand Up! Live Your Life Run This Town Stranded (Haiti Mon Amour) Love the Way You Lie Who’s That Chick? All of the Lights Fly Princess of China Take Care Bad (Remix) The Monster Can’t Remember to Forget You Famous This Is What You Came For Nothing Is Promised Too Good Selfish Wild Thoughts LOYALTY. Lemon Believe It
Tourneen	Rihanna: Live in Concert Tour Good Girl Gone Bad Tour Last Girl on Earth Tour Loud Tour Diamonds World Tour The Monster Tour Anti World Tour
Diskografie Auszeichnungen für Musikverkäufe Lieder Künstlerauszeichnungen Tourneen

Viele Grüße --Entlinkt (Diskussion) 16:08, 30. Mai 2016 (CEST)

Die Diskussion ist oben etwas in Richtung der Frage abgeglitten, ob die Vorlage {{Erweiterte Navigationsleiste}} überhaupt existieren sollte. Ich bin nach wie vor der Meinung, dass die Einführung in der Form, in der sie stattgefunden hat, ein sehr übler Sündenfall war, der unser Projekt noch sehr lange beschäftigen und jegliche „Modernisierung“ der Navigationsleisten auf Jahre hinaus behindern wird. Diese allgemeine Frage werden wir aber mangels Konsens so schnell nicht klären können.

Ich hätte daher den folgenden, ganz konkreten Vorschlag: Ersatzlose Löschung des „Quicklinks“-Gadgets MediaWiki:Gadget-Erweiterte-Navigationsleiste-Quicklinks.css und Löschung des zugehörigen Codes aus der Vorlage.

Begründung:

1. Das Gadget funktioniert nur bei solchen Navileisten, die mit der Vorlage {{Erweiterte Navigationsleiste}} erstellt wurden. Das sind nur ca. 10 Prozent der Navileisten (Verhältnis der Seiten, in denen {{Erweiterte Navigationsleiste}} und {{Navigationsleiste}} jeweils eingebunden sind: ca. 50.000 zu 500.000). Dies schränkt den Nutzen des Gadgets stark ein.
2. Darüber hinaus ist das Gadget opt-in und funktioniert daher nur bei Benutzern, die es explizit aktiviert haben. Laut Special:GadgetUsage sind das nur 162 aktive Benutzer, aber laut Spezial:Statistik haben wir ca. 18.000 aktive Benutzer. Das heißt, es haben nur 1 Prozent der aktiven Nutzer das Gadget aktiviert.
3. Alles in allem liegt der „Wirkungsgrad“ des Gadgets also bei 10 Prozent von 1 Prozent, also bei 1 Promille.
4. Andererseits führt das Gadget bei den wenigen Leuten, die es aktiviert haben, zu einem inkonsistenten Layout der Titelzeilen von Navileisten. Dies wiederum führt zu Anfragen in der Vorlagenwerkstatt und bindet dort Zeit, ohne dass eine gute Lösung in Sicht wäre. Durch die Löschung wird ein weitgehend konsistentes Aussehen der Titelzeilen für alle Benutzer sichergestellt, so dass diese sich besser auf Inhalte konzentrieren können.
5. Der Nutzen des Gadgets ist auch ohne Beachtung der statistischen Überlegungen eher gering, da man die Liste der eingebundenen Vorlagen auch unter dem Bearbeitungsfenster findet. Derartige „Quicklinks“ sind in anderen Wikipedien zum Beispiel auch in Infoboxen zu finden, bei uns aber in Infoboxen völlig unüblich. Daher ist es nur konsequent, auch in allen Navileisten darauf zu verzichten.
6. Zuguterletzt ist das Gadget auf sehr „unbürokratischem“ Wege aufgrund der Anfrage Wikipedia:Administratoren/Anfragen/Archiv/2012/September#Quicklinks bezüglich Erweiterte Navigationsleiste eingeführt worden. Zwischen der Anfrage und der Umsetzung sind ganze 13 Minuten (!) vergangen. Also sollte man das Gadget auch genauso unbürokratisch wieder entfernen können, wie es eingeführt wurde. Man kann der Diskussion übrigens auch entnehmen, dass das Gadget explizit deswegen eingeführt wurde, weil die standardmäßige Anzeige der „Quicklinks“ nicht konsensfähig war.

Gibt es Meinungen zu diesem Vorschlag? --Entlinkt (Diskussion) 18:24, 30. Mai 2016 (CEST)

(BK)Hätte jetzt nicht so ausufern müssen (ich sehe übrigens grad das Problem bei der schmalen Navi+ oben nicht, die Proportionen sind doch völlig okay), aber danke trotzdem für deine Ausführungen. Wenn du mir jetzt noch zeigst, wie man den erstaunlich vielfältig verwendbaren alten Klappkasten elegant mit den hierarchischen Gliederungselementen der NavBox füllt, hätten wir ja schon ein neues, brauchbareres Modell für die Navi+ … Ansonsten: Ein Gadget für 162 Benutzer einfach mal so abdrehen, obwohl die einzigen „Probleme“ ohnehin nur diese 162 betreffen, ist unbürokratisch sicher nicht zu haben; mich nervt es ungemein, erst im Bearbeitungsmodus den Namen der Vorlage herauszufinden, und offenbar geht es den 161 Kollegen ähnlich (wie wohl auch all den anderen nicht-deutschen Wikipedianern). Die heillose (vorgeschobene?) Angst vor zunehmendem Vorlagenvandalismus, die auch nach Entfernung des direkten Edit-Links nicht kleinzukriegen war, verstehe ich sowieso nicht.--XanonymusX (Diskussion) 19:40, 30. Mai 2016 (CEST)

Bedauerlicherweise ist dem Löschvorschlag zu diesem Gadget, dessen Einführung 13 Minuten lang „ausdiskutiert“ wurde, deutlich mehr als 13 Minuten lang nicht widersprochen worden. Darum, und weil es zu zeitraubenden Beschwerden über Layoutprobleme führt, deren Ursache das Gadget selbst ist, habe ich mich mit dem allergrößten Bedauern für die Löschung entschieden (und vorerst in der Vorlagendokumentation auf Benutzer-CSS verwiesen).

Natürlich kann das Gadget ganz unbürokratisch durch jeden Admin wiederhergestellt werden. Es wäre aber nett, wenn der Admin, der es wiederherstellt, sich auch um die Layoutprobleme kümmert. --Entlinkt (Diskussion) 19:33, 30. Mai 2016 (CEST)

Du kannst von den 162 Benutzern einen abziehen ;-) *zustimm*, auch wenn ich die 13-Minuten-Aktion nicht so gut (und in Richtung Adminrechte-Missbrauch gehend) finde. --nenntmichruhigip (Diskussion) 20:23, 30. Mai 2016 (CEST)

Dem Vorwurf würde ich nicht mal widersprechen. Trotzdem halte ich es für einen Fehler, dass das in der Form überhaupt jemals eingeführt wurde. Das führt (auch wenn es um etwas ziemlich unwichtiges geht) nur zu einer kleinen Wikipedia in der Wikipedia. So etwas sollte normalerweise nie eingeführt werden.

Der VisualEditor bekommt diese Funktionalität übrigens für alle Navigationsleisten hin (und sogar nicht nur für alle Navigationsleisten, sondern auch für alle Infoboxen, …). --Entlinkt (Diskussion) 20:39, 30. Mai 2016 (CEST)

Das mit VE ist natürlich super, erstaunlich, dass hier offenbar der große Aufschrei der de-Community ausbleibt.--XanonymusX (Diskussion) 20:51, 30. Mai 2016 (CEST)

Hinweis auf die Wiederherstellung. In der Sache ist meine Position aber unverändert, dass es meiner Meinung nach nicht der richtige Weg ist, das Gadget in dieser Form anzubieten. Gruß --Entlinkt (Diskussion) 22:20, 30. Mai 2016 (CEST)

@XanonymusX: Dich mag es ungemein nerven, dass die allermeisten Navileisten keine Quicklinks haben, aber das Gadget ändert daran in der vorliegenden (jetzt wiederhergestellten) Form nichts, da die allermeisten Navileisten auch mit dem Gadget keine Quicklinks haben. Die eigentliche Intention ist ja wohl, dass alle Navileisten Quicklinks haben sollen. Der Weg über ein Gadget, das nur bei wenigen Navileisten und nur auf Opt-in-Basis funktioniert und dann auch noch Darstellungsprobleme hat, die in der Vorlagenwerkstatt aufschlagen, führt nicht zum Ziel.

Genau das war bei der Einführung der gesamten Vorlage die Strategie, erstmal einen „Fuß in die Tür“ zu bekommen und auf diesem Wege irgendwie die gesamte Navileisten-Infrastruktur zu „übernehmen“. Diese Strategie halte ich aber für grundsätzlich falsch, sie funktioniert nicht und führt nur zu einer „Spaltung“, und zwar momentan im ernüchternden Verhältnis 50.000 zu 500.000 (nach 4 Jahren wohlgemerkt).

Man kann ganz allgemein nicht erwarten, dass Änderungen wie etwa der als eigentliches Ziel verfolgte Import der englischen Vorlage en:Template:Navbox (mitsamt daran hängendem CSS + JS) einfach mal so vorgenommen werden, da dies einen heftigen Bruch mit den hier gewachsenen Strukturen darstellen würde. Da hilft es auch nicht, wenn auf einer Benutzerunterseite wie Benutzer:Intforce/Projekt Erweiterte Navigationsleiste mit fadenscheinigen Argumenten versucht wird, es so aussehen zu lassen, als würde alle Welt dies wollen und als würde es nur an den bösen Admins scheitern, die nicht mitziehen. Dieser Bruch mit den gewachsenen Strukturen wäre m. E. so heftig, dass man an einem Meinungsbild nicht vorbeikommt, und Admins sind an dieser Stelle IMHO gerade dafür da, dass das nicht passiert.

Und mal ganz ehrlich: Die gesamte „Projektseite“ Benutzer:Intforce/Projekt Erweiterte Navigationsleiste liest sich IMHO wie ein Werbeflyer und macht den Eindruck, als müsse die dewiki-Community „zwangsbeglückt“ werden. Wenn ein Meinungsbild in dieser Form daherkäme, wäre ein Scheitern wohl keine Überraschung, da die meisten Leute hier m. E. ganz zufrieden damit sind, wie 90 % der Navileisten aussehen.

Ein guter Grund für die Löschung des Gadgets wäre m. E. die Tatsache, dass es die Titelzeilen der Leisten modifiziert. Solange diese uneinheitlich sind, ist eine Angleichung der beiden Vorlagen nicht möglich, da die Quicklinks in der Standardvorlage nicht konsensfähig sind. Dann bleibt es eben bei dem fragwürdigen „Etappensieg“, dass ca. 10 % der Leisten für ca. 1 % der Benutzer Quicklinks haben, und der Preis dafür ist die Spaltung der Vorlagen. Dass sich um den Darstellungsfehler jemals jemand kümmern wird, halte ich unter diesen Umständen aber für wahnsinnig unwahrscheinlich, da der Aufwand in keinem vernünftigen Verhältnis zum Nutzen steht. --Entlinkt (Diskussion) 23:10, 30. Mai 2016 (CEST)

Ist der letzte Satz nicht eine befriedigende Antwort auf meine kleine Eingangsfrage und ein wunderbares Schlusswort?! Nachdem ich die von euch dankenswerterweise diskutierten Hintergründe gelesen habe, sage ich mir: Ich kann mit der verschobenen Leiste leben. Vielen Dank an alle. Für mich wäre die Frage erledigt. --Wi-luc-ky (Diskussion) 23:37, 30. Mai 2016 (CEST)

Schön, ich werde mich jetzt auch aus der Diskussion zurückziehen, zu tun hab ich auch so genug. Was jetzt der „heftige[] Bruch mit den hier gewachsenen Strukturen“ genau sein soll – ich versteh’s nicht. Muss ich wohl damit leben, dass die deWP im Punkt Navileisten zurückbleibt, und mich damit trösten, dass wir hier im Gegensatz zu den anderen WPs wenigstens korrekte Typographie verwenden (mein großer Aufreger, wenn ich in anderen Sprachversionen arbeite), neben diversen anderen Vorteilen. Man kann wohl nicht alles haben. Was den Vorteil der Quicklinks für mich angeht: Nun ja, die Navis, die ich öfter brauche, stelle ich eben bei Bedarf auf die Navi+ um, ganz einfach. Hab jetzt auf jeden Fall auch meine common.css angelegt. Gruß in die Runde--XanonymusX (Diskussion) 09:16, 31. Mai 2016 (CEST)

OT: Naja, wenn teilweise in den WP-Empfehlungen was anderes steht als im ANR beschrieben ist, ist's wohl eher nur halbwegs korrekte… ;-) --nenntmichruhigip (Diskussion) 09:52, 31. Mai 2016 (CEST)

@Wi-luc-ky: Da du wohl einer der verbleibenden 160 Nutzer des Gadgets bist: Was meinst du zu einer (ordentlichen) Entfernung des Gadgets, also der Quicklinks? Die Gründe hat Entlinkt oben ja dargelegt. --nenntmichruhigip (Diskussion) 09:52, 31. Mai 2016 (CEST)

Zu Nr. 5: Wann wurde die Liste auf der Bearbeitungsseite eingeführt? Ich meine, dass es sie nicht immer gab, und wenn es nach Einführung des Gadgets war, würde das imo diesem Punkt noch mehr Bedeutung verleihen. --nenntmichruhigip (Diskussion) 09:52, 31. Mai 2016 (CEST)

• Seit immer und ewig sicher nicht.
• Vorlage:Erweiterte Navigationsleiste wurde 2012-05-23 angelegt, ging wohl nicht vor Mitte des Jahres in den ANR.
• Wikipedia:Projektneuheiten/Archiv liefert:
  • 11. März 2013 – Commons – Die Liste „Auf dieser Seite eingebundene Vorlagen anzeigen“ wurde eingeklappt, um die Seitenlänge ein wenig zu begrenzen.
  • 26. September 2012 – Im Bearbeitungsmodus können die Abschnitte „Folgende Vorlagen werden auf dieser Seite verwendet:“ … eingeklappt werden
  • Also hatte es das im Herbst 2012 schon gegeben. Außerdem gab es schon einen Beschwerdestau, dass die Listen zu umfangreich wären.
  • 25. Oktober 2008 – Die Liste der verwendeten Vorlagen, die im Bearbeitungsmodus unterhalb des Bearbeitungsfensters angezeigt wird, wurde um einen Bearbeiten-Link pro Vorlage ergänzt
  • Die Liste hatte es also schon vor 2008 gegeben, aber erst seit Herbst 2008 mit dem hier geforderten Bearbeiten-Link.

VG --PerfektesChaos 10:31, 31. Mai 2016 (CEST)

@XanonymusX: Wenn du nach so vielen Jahren immer noch nicht verstehst, warum der Import der englischen Vorlage (mitsamt zugehörigem CSS + JS) ein heftiger Bruch wäre, dann lies das CSS + JS doch bitte einfach mal (→ MediaWiki:Common.css, MediaWiki:Common.js, en:MediaWiki:Common.css, en:MediaWiki:Common.js) und stelle fest, dass das englische System mit unserer jetzigen Lösung noch sehr viel schlechter zusammenarbeitet, als {{Navigationsleiste}} und {{Erweiterte Navigationsleiste}} es untereinander tun. Die CSS-Formatierungen sehen komplett anders aus. Die JS-Ausklapp-Funktion verhält sich komplett anders: Beispielsweise kann bei unserer Lösung jeder Benutzer für sich einstellen, wieviele Leisten initial ausgeklappt erscheinen und ab wann alle Leisten initial eingeklappt erscheinen, bei der englischen Lösung geht das nicht.

Es ist eindeutig zuviel verlangt, dass irgendein Admin einfach so die englische Lösung importiert, nur weil eine sehr überschaubare Anzahl von Benutzern die These vom „Zurückbleiben bei Navileisten“ glaubt. Darauf wird sich ohne Meinungsbild keiner einlassen, weshalb man bis zum Sanktnimmerleinstag darauf warten wird. Admins sind an dieser Stelle genau dazu da, um einen solchen „wilden“ Import (der allerdings auch von vielen anderen Benutzern abgelehnt wurde, siehe MediaWiki Diskussion:Common.css/Archiv/2#Navbox) zu verhindern. Von einem Meinungsbild in Vorbereitung habe ich aber bis zum heutigen Tage nichts gesehen.

Mit der Aussage, dass du wegen der Quicklinks Navileisten auf {{Erweiterte Navigationsleiste}} umstellst, lieferst du allerdings einen weiteren erstklassigen Grund für das Entfernen der Quicklinks, da es einfach nur Blödsinn ist, dass die Quicklinks einen Anreiz für diese Umstellung schaffen. Die Einführung der Quicklinks hätte darüber zu laufen, dass man einen Konsens für die Einführung herstellt, und nicht durch ein „subversives“ Umstellen der zugrundeliegenden Vorlage. Genau deshalb, um solche Umstellungen zu vermeiden, sollten Vorlagen keine solchen „versteckten“ Features aufweisen.

@Nenntmichruhigip: Ich denke, dass die Liste unter dem Bearbeitungsfenster schon sehr lange vorhanden ist. Die zugehörigen Systemnachrichten MediaWiki:Templatesused und MediaWiki:Templatesusedpreview existieren seit mindestens 10 Jahren. Gruß --Entlinkt (Diskussion) 10:47, 31. Mai 2016 (CEST)

Leider habe ich mit meiner kleinen Zentrierungsfrage eine lange Diskussion ausgelöst, Nenntmichruhigip, die jetzt grundsätzliche Fragen berührt. Es lag nicht in meinem Interesse, eine Löschdiskussion anzustoßen. Bis auf Weiteres werden wir wohl mit diesem und anderen „Hinkebein-Gadgets“ leben müssen oder es abschalten, bitte nicht löschen. Es war leichter, die DNS so hinzubiegen, dass unsere Nasen in der Gesichtsmitte angeordnet werden, als jetzt den Code dieses Gadgets so umzubiegen, dass die Überschrift zentriert wird. ;-) (Hat auch ein paar Jährchen gedauert. Also, wie die Franzosen sagen: Patience! Geduld!) --Wi-luc-ky (Diskussion) 11:21, 31. Mai 2016 (CEST)

Ich seh schon: Dieses von mir in der jetzigen Form für – ich sag’s ganz offen – Anwenderveräppelung gehaltene Gadget hat einige Fans und wird deshalb wohl bleiben. (Anwenderveräppelung deshalb, weil es nur bei einem sehr kleinen Teil der Leisten funktioniert und daher für Anwender nutzlos ist, da diese für 90 % der Leisten den Weg über die Liste unter dem Bearbeitungsfenster gehen müssen, sie diesen Weg daher sowieso in ihren Workflow einbauen müssen und deshalb die Quicklinks nicht brauchen.)

Warum hat das Gadget Fans? Weil man meint, die Quicklinks, die man auf offenem Wege nicht durchsetzen konnte, so auf einem Umweg vielleicht doch noch irgendwie durchsetzen zu können. Relativ typischer Wikipedia-interner Vorgang, für Anwender komplett uninteressant. Und warum gibt es das Gadget überhaupt? Weil vor 4 Jahren mal ein Admin über das Stöckchen gesprungen ist und es keine funktionierende Möglichkeit gibt, das zu revidieren. (Die faktische Nicht-Revidierbarkeit gilt übrigens nicht nur für dieses Gadget, sondern für fast alles im MediaWiki-Namensraum.)

Ich erlaube mir zu prognostizieren: Solange die „Spaltung“ zwischen {{Navigationsleiste}} und {{Erweiterte Navigationsleiste}} betrieben wird (und die Quicklinks mitsamt Gadget leisten einen Beitrag dazu), wird es keine wie auch immer geartete grundlegende „Modernisierung“ der Infrastruktur für Navileisten geben, da sich niemand an das Thema herantrauen wird. Die Tatsache, dass die IMHO ziemlich offensichtliche Fehlentscheidung, das Gadget einzuführen, anscheinend nicht revidierbar ist, liefert sogar noch einen weiteren Grund, keine „Modernisierungen“ anzugehen, weil dabei passierende Fehler wahrscheinlich ebenfalls nicht revidierbar wären. Gruß --Entlinkt (Diskussion) 11:54, 31. Mai 2016 (CEST)

Sehe ich auch so, und ich meine, dass der jetzige Text zum Gadget um einen entsprechenden Hinweis ergänzt werden sollte, wenn es schon bestehen bleibt. Einige der 160 anderen Nutzer werden das wahrscheinlich auch nur als "klingt so, als könnte es vielleicht irgendwann mal praktisch sein" aktiviert haben. Vorschlag: "Dies funktioniert nicht bei der normalen Navigationsleiste und führt zu verschobener Zentrierung der Überschrift." --nenntmichruhigip (Diskussion) 13:20, 31. Mai 2016 (CEST)

Ganz ehrlich: Auch wenn es bei der ganzen Angelegenheit um etwas letztlich völlig bedeutungsloses geht, finde ich sie fürchterlich frustrierend und meine, dass man dabei sehr unerfreuliche, aber leider wahre Dinge darüber lernen kann, was für ein Saftladen diese Wikipedia eigentlich ist.

Halten wir mal fest: Es gibt Leute, die gern Quicklinks an allen Navileisten hätten und es gibt Leute, die an keiner Navileiste Quicklinks wollen. Bis hierher ist das schon mal unerfreulich, aber nicht zu ändern. Quicklinks an 10 % der Navileisten will allerdings vermutlich kein einziger Mensch auf dieser Welt. Das Gadget setzt Quicklinks an 10 % der Navileisten und leistet also etwas, das (vermutlich) kein einziger Mensch auf dieser Welt will. Dennoch war das Einführen kein Problem, weil ein Admin so gutgläubig war, den offensichtlich komplett ungeprüften Code in den MediaWiki-Namensraum zu nehmen. Dabei wurden sogar zwei (mittlerweile behobene) Todsünden begangen, nämlich (1) die Verwendung von JS, obwohl es nicht benötigt wird, und (2) das Laden aus dem Benutzernamensraum eines Benutzers ohne jegliche Reputation.

Einführen: Easy, ganz ohne Prüfung auf Codequalität, inhaltliche Sinnhaftigkeit und ähnlich lästige Dinge. Das Entfernen soll nun allerdings sehr viel schwerer sein, weil manche Benutzer das Gadget als Etappensieg in der Quicklinks-Einführung ansehen, den sie nicht mehr hergeben wollen und sogar öffentlich ankündigen, weiterhin die eine Vorlage durch die andere zu ersetzen, um Quicklinks zu erhalten. Wohlgemerkt solche Quicklinks, die fast niemand außer ihnen selbst jemals zu Gesicht bekommen wird. Super: Wenn das in dem bisherigen Tempo weitergeht, ist in 40 Jahren das Ziel erreicht, dass alle Navileisten Quicklinks haben, die fast niemand sieht!

Wir haben momentan 35 Gadgets im Angebot, davon haben 3 Stück einen Totalschaden (funktionieren überhaupt nicht mehr); das Quicklinks-Teil ist jetzt also das vierte Gaga-Gadget. Eingeführt wurde es vor 4 Jahren. Ohne es jetzt nachgeprüft zu haben, habe ich den Eindruck, dass seitdem kaum noch neue Gadgets eingeführt wurden. Auch „normale“, tatsächlich nützliche CSS/JS-Ergänzungen bekommt man mittlerweile nur noch sehr schwer in den MediaWiki-Namensraum. Das hat Gründe, nämlich genau diesen Schindluder, der immer wieder damit getrieben wird.

Die Formulierung für die Gadget-Beschreibung werde ich mir überlegen, bin aber noch nicht sicher. Einen solchen Hinweis könnte man auch als offizielle Aufforderung missverstehen, überall die eine Vorlage durch die andere zu ersetzen. --Entlinkt (Diskussion) 16:29, 31. Mai 2016 (CEST)

Letzteres befürchte ich auch, deshalb wäre mir eine Formulierung lieber, bei der das klar wird. Hatte ich eigentlich beim Vorschlag dazuschreiben wollen :-) --nenntmichruhigip (Diskussion) 20:21, 31. Mai 2016 (CEST)

Kleiner Off-Topic-Zwischenruf: Auch wenn Navileisten allgemein eher wenig mit dem Kerngeschäft der Enzyklopädieerstellung haben, beschäftigt es mich tatsächlich, wie groß der Schaden wirklich ist, der der Wikipedia durch die Etablierung der „modernen“ Vorlage {{Erweiterte Navigationsleiste}} entstanden ist. Ich habe deshalb mal ein wenig im Umfeld der Vorlage herumgelesen und dabei gesehen, dass die Vorlage erst kürzlich von 20 auf 32 (zweiunddreißig) Gruppen aufgestockt wurde. Neugierig wie ich bin, habe ich mal nachgesehen, warum das gemacht wurde. Warum? Weil man vorhat, Vorlage:Navigationsleiste Unicode durch Benutzer:Morten Haan/Unicode zu ersetzen.

Ist diese Ersetzung eine Verbesserung der Wikipedia? Wie sieht denn das Ganze auf kleineren Displays aus? Darstellung auf kleinen Displays sollte für eine „moderne“ Vorlage doch kein Problem sein, während von einer „veralteten“ Vorlage Probleme zu erwarten sind. Sollte man meinen, wenn die kreischende Werbung denn stimmen würde.

Die Realität sieht so aus. „Veraltete“ Vorlage:

Unicode – Übersicht: Unicodeblöcke – Portal:Unicode

Codierte Reihenfolge

Ebene 0

Basis-Lateinisch • Lateinisch-1, Ergänzung • Lateinisch, erw.-A • Lateinisch, erw.-B • IPA-Erweiterungen • Spacing Modifier Letters • Kombinierende diakritische Zeichen • Griechisch und Koptisch • Kyrillisch • Kyrillisch, Ergänzung • Armenisch • Hebräisch • Arabisch • Syrisch • Arabisch, Ergänzung • Thaana • N’Ko • Samaritanisch • Mandäisch • Syrisch, Ergänzung • Arabisch, erw.-B • Arabisch, erw.-A • Devanagari • Bengalisch • Gurmukhi • Gujarati • Oriya • Tamilisch • Telugu • Kannada • Malayalam • Singhalesisch • Thailändisch • Laotisch • Tibetisch • Birmanisch • Georgisch • Hangeul-Jamo • Äthiopisch • Äthiopisch, Zusatz • Cherokee • Vereinh. Silbenz. kanad. Ureinw. • Ogam • Runen • Tagalog • Hanunóo • Buid • Tagbanuwa • Khmer • Mongolisch • Vereinh. Silbenz. kanad. Ureinw., erw. • Limbu • Tai Le • Neu-Tai-Lue • Khmer-Symbole • Buginesisch • Lanna • Kombinierende diakritische Zeichen, erw. • Balinesisch • Sundanesisch • Batak • Lepcha • Ol Chiki • Kyrillisch, erw.-C • Georgisch, erweitert • Sundanesisch, Ergänzung • Vedische Erweiterungen • Phonetische Erweiterungen • Phonetische Erweiterungen, Ergänzung • Kombinierende diakritische Zeichen, Ergänzung • Lateinisch, weiterer Zusatz • Griechisch, Zusatz • Allgemeine Interpunktion • Hoch- und tiefgestellte Zeichen • Währungszeichen • Kombinierende diakritische Zeichen für Symbole • Buchstabenähnliche Symbole • Zahlzeichen • Pfeile • Mathematische Operatoren • Verschiedene technische Zeichen • Symbole für Steuerzeichen • Optische Zeichenerkennung • Umschlossene alphanum. Zeichen • Rahmenzeichnung • Blockelemente • Geometrische Formen • Verschiedene Symbole • Dingbats • Verschiedene mathem. Symbole-A • Zusätzliche Pfeile-A • Braille-Zeichen • Zusätzliche Pfeile-B • Verschiedene mathem. Symbole-B • Zusätzliche mathem. Operatoren • Verschiedene Symbole und Pfeile • Glagolitisch • Lateinisch, erw.-C • Koptisch • Georgisch, Ergänzung • Tifinagh • Äthiopisch, erweitert • Kyrillisch, erw.-A • Zusätzliche Interpunktion • CJK-Radikale, Ergänzung • Kangxi-Radikale • Ideographische Beschreibungszeichen • CJK-Symbole und -Interpunktion • Hiragana • Katakana • Bopomofo • Hangeul-Jamo, Kompatibilität • Kanbun • Bopomofo, erweitert • CJK-Striche • Katakana, Phonetische Erweiterungen • Umschlossene CJK-Zeichen und -Monate • CJK-Kompatibilität • Vereinh. CJK-Ideogramme, Erw. A • I-Ging-Hexagramme • Vereinh. CJK-Ideogramme • Yi-Silbenzeichen • Yi-Radikale • Lisu • Vai • Kyrillisch, erw.-B • Bamum • Modifizierende Tonzeichen • Lateinisch, erw.-D • Syloti Nagri • Allgemeine indische Ziffern • Phagspa • Saurashtra • Devanagari, erw. • Kayah Li • Rejang • Hangeul-Jamo, erw.-A • Javanisch • Birmanisch, erw.-B • Cham • Birmanisch, erw.-A • Tai Viet • Meitei-Mayek, Erw. • Äthiopisch, erw.-A • Lateinisch, erw.-E • Cherokee, Zusatz • Meitei-Mayek • Hangeul-Silbenzeichen • Hangeul-Jamo, erw.-B • Private Use Zone • CJK-Ideogramme, Kompatibilität • Alphabetische Präsentationsformen • Arabische Präsentationsformen-A • Variantenselektoren • Vertikale Formen • Kombinierende halbe diakritische Zeichen • CJK-Kompatibilitätsformen • Kleine Formvarianten • Arabische Präsentationsformen-B • Halbbreite und vollbreite Formen • Spezielles

Ebene 1

Linear-B-Silbenzeichen • Linear-B-Ideogramme • Ägäische Zahlzeichen • Altgriechische Zahlzeichen • Alte Symbole • Diskos von Phaistos • Lykisch • Karisch • Koptische Zahlzeichen • Altitalisch • Gotisch • Altpermisch • Ugaritisch • Altpersisch • Mormonen-Alphabet • Shaw-Alphabet • Osmaniya • Osage • Albanisch • Alwanisch • Vithkuq-Alphabet • Todhri • Linear A • Lateinisch, erw.-F • Kyprisch • Aramäisch • Palmyrenisch • Nabatäisch • Hatra-Schrift • Phönizisch • Lydisch • Meroitische Hieroglyphen • Meroitisch-demotisch • Kharoshthi • Altsüdarabisch • Altnordarabisch • Manichäisch • Avestisch • Parthisch • Inschriften-Pahlavi • Psalter-Pahlavi • Alttürkisch • Altungarisch • Hanifi Rohingya • Garay • Rumi-Ziffern • Jesidisch • Arabisch, erw.-C • Altsogdisch • Sogdisch • Altuigurisch • Choresmisch • Elymäisch • Brahmi • Kaithi • Sorang-Sompeng • Chakma • Mahajani • Sharada • Singhalesische Zahlzeichen • Khojki • Multanisch • Khudabadi • Grantha • Tulu-Tigalari • Newa • Tirhuta • Siddham • Modi • Mongolisch, Ergänzung • Takri • Birmanisch, erw.-C • Ahom • Dogra • Varang Kshiti • Dives Akuru • Nandinagari • Dsanabadsar-Quadratschrift • Sojombo • Vereinh. Silbenz. kanad. Ureinw., erw.-A • Pau Cin Hau • Devanagari, erw.-A • Sunwar • Bhaiksuki • Marchen • Masaram Gondi • Gunjala Gondi • Makassar • Kawi • Lisu, Ergänzung • Tamilisch, Ergänzung • Keilschrift • Keilschrift-Zahlzeichen und -Interpunktion • Frühe Keilschrift • Kypro-minoisch • Ägyptische Hieroglyphen • Ägypt. Hieroglyphen-Steuerzeichen • Ägyptische Hieroglyphen, erw.-A • Anatolische Hieroglyphen • Gurung Khema • Bamum, Ergänzung • Mro • Tangsa • Bassa Vah • Pahawh Hmong • Kirat Rai • Medefaidrin • Pollard-Schrift • Ideographische Symbole und Interpunktion • Xixia • Xixia-Komponenten • Kleine Kitan-Schrift • Xixia, Ergänzung • Kana, erw.-B • Kana, Ergänzung • Kana, erw.-A • Kleine Kana, erweitert • Frauenschrift • Duployé-Kurzschrift • Kurzschrift-Steuerzeichen • Symbole für Retrocomputer, Ergänzung • Snamennyj-Notenschrift • Byzantinische Noten • Notenschrift • Altgriechische Noten • Kaktovik-Zahlzeichen • Maya-Zahlzeichen • Tai-Xuan-Jing-Symbole • Zählstabziffern • Mathem. alphanum. Symbole • SignWriting • Lateinisch, erw.-G • Glagolitisch, Ergänzung • Kyrillisch, erw.-D • Nyiakeng Puachue Hmong • Toto • Wancho • Nag Mundari • Ol Onal • Äthiopisch, erw.-B • Mende-Schrift • Adlam • Indische Siyaq-Zahlzeichen • Osmanische Siyaq-Zahlzeichen • Arab. mathem. alphanum. Symbole • Mahjonggsteine • Dominosteine • Spielkarten • Zusätzliche umschlossene alphanum. Zeichen • Zusätzliche umschlossene CJK-Zeichen • Verschiedene piktografische Symbole • Smileys • Ziersymbole • Verkehrs- und Kartensymbole • Alchemistische Symbole • Geometrische Formen, erw. • Zusätzliche Pfeile-C • Zusätzliche piktografische Symbole • Schachsymbole • Piktografische Symbole, erw.-A • Symbole für Retrocomputer

Ebenen 2 und 3

Vereinh. CJK-Ideogramme, Erw. B • Vereinh. CJK-Ideogramme, Erw. C • Vereinh. CJK-Ideogramme, Erw. D • Vereinh. CJK-Ideogramme, Erw. E • Vereinh. CJK-Ideogramme, Erw. F • Vereinh. CJK-Ideogramme, Erw. I • CJK-Ideogramme, Kompatibilität, Ergänzung • Vereinh. CJK-Ideogramme, Erw. G • Vereinh. CJK-Ideogramme, Erw. H

Ebenen 14 bis 16

Tags • Variantenselektoren, Ergänzung • Zusätzlicher Privatnutzungsbereich–A • Zusätzlicher Privatnutzungsbereich–B

---

Alphabetische Reihenfolge

Adlam • Ägäische Zahlzeichen • Ägyptische Hieroglyphen • Ägyptische Hieroglyphen, erw.-A • Ägypt. Hieroglyphen-Steuerzeichen • Ahom • Albanisch • Alchemistische Symbole • Allgemeine indische Ziffern • Allgemeine Interpunktion • Alphabetische Präsentationsformen • Alte Symbole • Altgriechische Noten • Altgriechische Zahlzeichen • Altitalisch • Altnordarabisch • Altpermisch • Altpersisch • Altsogdisch • Altsüdarabisch • Alttürkisch • Altuigurisch • Altungarisch • Alwanisch • Anatolische Hieroglyphen • Arabisch • Arabisch, Ergänzung • Arabisch, erw.-A • Arabisch, erw.-B • Arabisch, erw.-C • Arab. mathem. alphanum. Symbole • Arabische Präsentationsformen-A • Arabische Präsentationsformen-B • Aramäisch • Armenisch • Äthiopisch • Äthiopisch, erweitert • Äthiopisch, erw.-A • Äthiopisch, erw.-B • Äthiopisch, Zusatz • Avestisch • Balinesisch • Bamum • Bamum, Ergänzung • Basis-Lateinisch • Bassa Vah • Batak • Bengalisch • Bhaiksuki • Birmanisch • Birmanisch, erw.-A • Birmanisch, erw.-B • Birmanisch, erw.-C • Blockelemente • Bopomofo • Bopomofo, erweitert • Brahmi • Braille-Zeichen • Buchstabenähnliche Symbole • Buginesisch • Buid • Byzantinische Noten • Chakma • Cham • Cherokee • Cherokee, Zusatz • Choresmisch • CJK-Ideogramme, Kompatibilität • CJK-Ideogramme, Kompatibilität, Ergänzung • CJK-Kompatibilität • CJK-Kompatibilitätsformen • CJK-Radikale, Ergänzung • CJK-Striche • CJK-Symbole und -Interpunktion • Devanagari • Devanagari, erw. • Devanagari, erw.-A • Dingbats • Diskos von Phaistos • Dives Akuru • Dogra • Dominosteine • Dsanabadsar-Quadratschrift • Duployé-Kurzschrift • Elymäisch • Frauenschrift • Frühe Keilschrift • Garay • Geometrische Formen • Geometrische Formen, erw. • Georgisch • Georgisch, Ergänzung • Georgisch, erweitert • Glagolitisch • Glagolitisch, Ergänzung • Gotisch • Grantha • Griechisch und Koptisch • Griechisch, Zusatz • Gujarati • Gunjala Gondi • Gurmukhi • Gurung Khema • Halbbreite und vollbreite Formen • Hangeul-Jamo • Hangeul-Jamo, erw.-A • Hangeul-Jamo, erw.-B • Hangeul-Jamo, Kompatibilität • Hangeul-Silbenzeichen • Hanifi Rohingya • Hanunóo • Hatra-Schrift • Hebräisch • Hiragana • Hoch- und tiefgestellte Zeichen • Ideographische Beschreibungszeichen • Ideographische Symbole und Interpunktion • I-Ging-Hexagramme • Indische Siyaq-Zahlzeichen • Inschriften-Pahlavi • IPA-Erweiterungen • Javanisch • Jesidisch • Kaithi • Kaktovik-Zahlzeichen • Kana, Ergänzung • Kana, erw.-A • Kana, erw.-B • Kanbun • Kangxi-Radikale • Kannada • Karisch • Katakana • Katakana, Phonetische Erweiterungen • Kawi • Kayah Li • Keilschrift • Keilschrift-Zahlzeichen und -Interpunktion • Kharoshthi • Khmer • Khmer-Symbole • Khojki • Khudabadi • Kirat Rai • Kleine Formvarianten • Kleine Kana, erweitert • Kleine Kitan-Schrift • Kombinierende diakritische Zeichen für Symbole • Kombinierende diakritische Zeichen • Kombinierende diakritische Zeichen, Ergänzung • Kombinierende diakritische Zeichen, erw. • Kombinierende halbe diakritische Zeichen • Koptisch • Koptische Zahlzeichen • Kurzschrift-Steuerzeichen • Kyprisch • Kypro-minoisch • Kyrillisch • Kyrillisch, Ergänzung • Kyrillisch, erw.-A • Kyrillisch, erw.-B • Kyrillisch, erw.-C • Kyrillisch, erw.-D • Lanna • Laotisch • Lateinisch, erw.-A • Lateinisch, erw.-B • Lateinisch, erw.-C • Lateinisch, erw.-D • Lateinisch, erw.-E • Lateinisch, erw.-F • Lateinisch, erw.-G • Lateinisch, weiterer Zusatz • Lateinisch-1, Ergänzung • Lepcha • Limbu • Linear A • Linear-B-Ideogramme • Linear-B-Silbenzeichen • Lisu • Lisu, Ergänzung • Lydisch • Lykisch • Mahajani • Mahjonggsteine • Makassar • Malayalam • Mandäisch • Manichäisch • Marchen • Masaram Gondi • Mathem. alphanum. Symbole • Mathematische Operatoren • Maya-Zahlzeichen • Medefaidrin • Meitei-Mayek • Meitei-Mayek, Erw. • Mende-Schrift • Meroitisch-demotisch • Meroitische Hieroglyphen • Modi • Modifizierende Tonzeichen • Mongolisch • Mongolisch, Ergänzung • Mormonen-Alphabet • Mro • Multanisch • Nabatäisch • Nag Mundari • Nandinagari • Neu-Tai-Lue • Newa • N’Ko • Notenschrift • Nyiakeng Puachue Hmong • Ogam • Ol Chiki • Ol Onal • Optische Zeichenerkennung • Oriya • Osage • Osmanische Siyaq-Zahlzeichen • Osmaniya • Pahawh Hmong • Palmyrenisch • Parthisch • Pau Cin Hau • Pfeile • Phagspa • Phonetische Erweiterungen • Phonetische Erweiterungen, Ergänzung • Phönizisch • Piktografische Symbole, erw.-A • Pollard-Schrift • Privatnutzungsbereich • Zusätzlicher Privatnutzungsbereich-A • Zusätzlicher Privatnutzungsbereich-B • Psalter-Pahlavi • Rahmenzeichnung • Rejang • Rumi-Ziffern • Runen • Samaritanisch • Saurashtra • Schachsymbole • Sharada • Shaw-Alphabet • Siddham • Singhalesisch • Singhalesische Zahlzeichen • Smileys • Snamennyj-Notenschrift • Sogdisch • Sojombo • Sorang-Sompeng • Spacing Modifier Letters • Spezielles • Spielkarten • Sundanesisch • Sundanesisch, Ergänzung • Sunwar • SignWriting • Syloti Nagri • Symbole für Retrocomputer • Symbole für Retrocomputer, Ergänzung • Symbole für Steuerzeichen • Syrisch • Syrisch, Ergänzung • Tagalog • Tagbanuwa • Tags • Tai Le • Tai Viet • Tai-Xuan-Jing-Symbole • Takri • Tamilisch • Tamilisch, Ergänzung • Tangsa • Telugu • Thaana • Thailändisch • Tibetisch • Tifinagh • Tirhuta • Todhri • Toto • Tulu-Tigalari • Ugaritisch • Umschlossene alphanum. Zeichen • Umschlossene CJK-Zeichen und -Monate • Vai • Varang Kshiti • Variantenselektoren • Variantenselektoren, Ergänzung • Vedische Erweiterungen • Vereinh. CJK-Ideogramme • Vereinh. CJK-Ideogramme, Erw. A • Vereinh. CJK-Ideogramme, Erw. B • Vereinh. CJK-Ideogramme, Erw. C • Vereinh. CJK-Ideogramme, Erw. D • Vereinh. CJK-Ideogramme, Erw. E • Vereinh. CJK-Ideogramme, Erw. F • Vereinh. CJK-Ideogramme, Erw. G • Vereinh. CJK-Ideogramme, Erw. H • Vereinh. CJK-Ideogramme, Erw. I • Vereinh. Silbenz. kanad. Ureinw. • Vereinh. Silbenz. kanad. Ureinw., erw. • Vereinh. Silbenz. kanad. Ureinw., erw.-A • Verkehrs- und Kartensymbole • Verschiedene mathem. Symbole-A • Verschiedene mathem. Symbole-B • Verschiedene piktografische Symbole • Verschiedene Symbole und Pfeile • Verschiedene Symbole • Verschiedene technische Zeichen • Vertikale Formen • Vithkuq-Alphabet • Währungszeichen • Wancho • Xixia • Xixia, Ergänzung • Xixia-Komponenten • Yi-Radikale • Yi-Silbenzeichen • Zählstabziffern • Zahlzeichen • Ziersymbole • Zusätzliche Interpunktion • Zusätzliche mathem. Operatoren • Zusätzliche Pfeile-A • Zusätzliche Pfeile-B • Zusätzliche Pfeile-C • Zusätzliche piktografische Symbole • Zusätzliche umschlossene alphanum. Zeichen • Zusätzliche umschlossene CJK-Zeichen

„Modernisierte“ Vorlage:

{{Benutzer:Morten Haan/Unicode}}

Soso. Horizontale Scrollbalken konnte man also nicht vorausahnen, als man auf die „modernen“ festverdrahteten Layouttabellen setzte. Im Zweifelsfall erklärt man wohl einfach die horizontalen Scrollbalken für „modern“.

Auch wenn viele es wahrscheinlich nicht mehr hören können: Ich bin der Meinung, dass man den Schaden, der durch die Etablierung dieser Vorlage für Navigationsleisten entstanden ist, eigentlich gar nicht zu hoch einschätzen kann. Es wurde und wird andauernd einfandfrei Funktionierendes durch Murks ersetzt. Für Wikipedia ist der Schaden nur deshalb noch erträglich, weil Navileisten eh nur wenig mit Enzyklopädie zu tun haben. --Entlinkt (Diskussion) 00:10, 1. Jun. 2016 (CEST)

PS: Sorry, ich kann’s mir nicht verkneifen. Vielleicht interessieren sich die Befürworter eines Imports der fortschrittlich-hochentwickelt-internationalen navbox-Klasse ja auch dafür, dass diese in der Mobilversion der Wikipedia komplett unsichtbar ist, denn in einem zentralen Stylesheet steht folgendes:

.navbox {
	display: none !important;
}

Das wäre doch mal ein wirklich gutes Argument für den Import. Gruß --Entlinkt (Diskussion) 01:47, 1. Jun. 2016 (CEST)

PPS: Sorry, ich muss leider noch ein bisschen weiter gegen diese hypermoderne „erweiterte“ Navigationsleiste sticheln, da das Modernitätsargument ja sicherlich noch einige Male angeführt werden wird.

Unter en:Template talk:Navbox/Archive 20#Inline CSS findet man eine Diskussion mit unter anderem der folgenden Äußerung: “Basically, it's time for another rewrite/restyle, avoiding inline CSS alltogether. I have some ideas floating around in my head, but making them work with all the current navbox implementations is daunting.” Dort findet man auch einen Link auf die Seite wikia:w:w:c:camtest:Navbox, wo ein Entwurf für eine tabellenfreie Implementierung der hypermodernen navbox-Klasse zu finden ist. Ich zitiere:

“Navboxes are undeniably used for navigating between pages, yet they are commonly implemented as tables. Unfortunately, this causes issues with performance and accessibility which is unacceptable(?) for a template found on over 2.4m pages. They also don't render very well for mobile views. This is most likely a side-effect of what was supported in browsers at the time of their inception, but now it is time to move to something more inline with modern web standards.”

Tja, so überzeugt sind die enwiki-Leute also von der „Modernität“ ihrer eigenen Lösung, vielleicht sollten die sich mal was von Benutzer:Intforce/Projekt Erweiterte Navigationsleiste abschauen, insbesondere das Selbstbewusstsein.

Der Entwurf zeigt übrigens, dass es wohl sehr schwer ist, von dem Tabellenmarkup wieder wegzukommen. Dasselbe Problem hat unsere Vorlage {{Erweiterte Navigationsleiste}} natürlich auch, weil vor 4 Jahren mal ein paar Leute an dessen „Modernität“ geglaubt haben. Der „billige Klappkasten“ {{Navigationsleiste}} hat es natürlich nicht. --Entlinkt (Diskussion) 07:42, 1. Jun. 2016 (CEST)

Ich habe die Layoutprobleme jetzt mal im Quelltext des Gadgets dokumentiert, dort ist das zwar nur wenig sichtbar, aber es geht nicht verloren und man kann in Zukunft darauf verweisen. Mit problematischem Code in MediaWiki:Common.css, an dem aus welchen Gründen auch immer festgehalten wird, verfahre ich genauso.

An dem für Anwender sichtbaren Beschreibungstext werde ich nach einiger Überlegung aber nichts ändern, da dies zu leicht als Aufforderung verstanden werden könnte, die Probleme durch den Austausch der Vorlage zu „lösen“, egal wie man es formuliert. Außerdem ist das nun einmal der damals durchgesetzte Beschreibungstext; analog zur Vorlage selbst sehe ich auch beim Beschreibungstext keine wirklich gute Lösung und deshalb sollte man das gar nicht erst versuchen.

Ich bin übrigens nach wie vor der Meinung, dass das Gadget entfernt werden sollte, die oben genannten Gründe gelten weiter, nur fehlt es an Verfahrensweisen dafür. Insbesondere blockiert das Gadget zumindest für mich jeden Versuch, die Titelzeilen konsistent zu bekommen. Da sie aber von Anfang an inkonsistent waren, ist sowieso niemand in der Pflicht, für Konsistenz zu sorgen. --Entlinkt (Diskussion) 16:29, 1. Jun. 2016 (CEST)

Mit dem Vorbehalt, dass ich diese "Monsterdiskussion mit den vielen Scrollmetern" nicht ganz durchgelesen habe, scheint das Hauptproblem die linke Spalte mit den Untertiteln zu sein. Ich würde diese einfach wie Kapitelüberschriften (Buchstil) platzieren. Das erspart gewiss jede Menge Probleme bei wenig Bildschirmpixeln. Die Vorlage:Navigationsleiste Unicode ist ein Musterbeispiel dafür, dass die bisherige Navi völlig ausreicht und keinerlei Probleme bereitet. Als einer der Hauptautoren (oder besser: Hauptpfleger) dieser Navi sehe ich keinen Grund zum Umkrempeln. Ich habe Benutzer Morten Haan zwar mal bei seiner Navi geholfen, aber seit ich die WP mal mit einem Smartphone (Ich bin kein Freund dieser "Permanent-Im-Web-Sein-müssen-Geräte") benutzt habe, sehe ich das nicht mehr als zielführend. Zumindest im von mir genutzten Monobook-Skin regelt der Browser die Umbrüche beim Buchstil ganz automatisch fast optimal. ÅñŧóñŜûŝî (Ð) 00:29, 11. Jun. 2016 (CEST)

Infoboxen für Meer und Ozean

Warum gibt es keine Infoboxen für Meere und Ozeane, bzw. könnten bitte welche erstellt werden?--Cedrichoyer (Diskussion) 14:44, 11. Jun. 2016 (CEST)

Es gibt die Anleitung: Erstellen einer Infobox, da kannst du dich informieren und eine basteln.--JTCEPB (Diskussion) 21:13, 11. Jun. 2016 (CEST)

Jetzt als Vorlage:Infobox Meer vorhanden. Die Syntax für Positionskarte und Geolinks funktionieren aber nicht richtig. Zumindest sind eiige der verwendeten Werte sinnlos. Es gibt keine Seebreite und auch keine Höhenangabe. Außerdem sind es nur fünf Ozeane mit fünf möglichen Region-ISO-Werten. Wer weiß, wie man das in diese Box richtig einbaut, der möge so nett sein, und das tun. ÅñŧóñŜûŝî (Ð) 20:22, 14. Jun. 2016 (CEST)

Vorlage TOC

in dem Artikel :als:Wort:Schwäbische Vokabeln habe ich das Problem, dass in der Vorschau die gewünschte Funktion ausgeführt wird: Sprung aus Teiltabellenkopf in die Teiltabelle. Nach dem Speichern geht es nicht mehr. In der Vorlage TOC Artikel wird dieser Fall angesprochen, aber die angegebene Lösung funktioniert nicht. eingefügt sind die Änderungen im Abschnitt 'Verben' versuchsweise. Mit der Spielwiese komme ich auch nicht weiter. MfG bkb (Diskussion) 18:25, 26. Jun. 2016 (CEST)

Die Vorlage verlinkt einfach auf die Sprungmarken #A bis #Z. MediaWiki erstellt automatisch Sprungmarken für die Überschriften, damit das überhaupt funktioniert. Eine Sprungmarke darf pro Dokument nur einmal vorkommen. Deshalb macht MediaWiki das so, dass bei zwei gleichlautenden Überschriften z.B. die zweite als #A_2 bezeichnet wird. Prinzipiell könnte man die Vorlage so umbauen, dass man über einen Parameter etwas an das Linkziel anhängen kann. --nenntmichruhigip (Diskussion) 18:40, 26. Jun. 2016 (CEST)

Zu Vorlage:TOC Artikel: Die gibt es im alswiki (noch) nicht, also kann man natürlich als:Template:TOC Artikel nicht einbinden ;-) Wenn die im alswiki übernommen werden würde sollte die Lösung mit dem Prefix wie in ihrer Dokumentation beschrieben funktionieren. --nenntmichruhigip (Diskussion) 18:46, 26. Jun. 2016 (CEST)

Danke, auch für die Schnelligkeit der Antwort. Auf der Spielwiese habe ich es inzwischen auch (mit viel Raten) geschafft. Die als:WP (Holder) ich schon angeschrieben. bkb (Diskussion) 21:30, 26. Jun. 2016 (CEST)

Vorlage:Denkmalliste Brandenburg Tabellenzeile

Mit der oben genannten Vorlage gibt es ein Problem, siehe Diskussion:Liste der Baudenkmale in Brandenburg an der Havel#Verlinkungen. Es gibt einige Einträge die etwas länger sind. Beispiel: Vereinigte Brandenburger Mühlenwerke (ehem. Burg-, Mittel-, Krakauer Mühle), bestehend aus Hauptgebäude (Krakauer Straße 1), Mehlspeicher (Krakauer Straße 2), Rieselspeicher mit Schiffsentladeanlage (Krakauer Straße 4-7), Kornspeicher (neben Domlinden 23), Transformatorenstation (neben Grillendamm 19) und Pferdestall (Grillendamm 19). Hypothetisch, es gibt nur zum Hauptgebäude eine Artikel, und/oder auch zum Rieselspeicher. Falsch ist die gesamte Verlinkung des Eintrages, richtig wäre beispielsweise: Vereinigte Brandenburger Mühlenwerke (ehem. Burg-, Mittel-, Krakauer Mühle), bestehend aus Hauptgebäude (Krakauer Straße 1), Mehlspeicher (Krakauer Straße 2), Rieselspeicher mit Schiffsentladeanlage (Krakauer Straße 4-7), Kornspeicher (neben Domlinden 23), Transformatorenstation (neben Grillendamm 19) und Pferdestall (Grillendamm 19). Besteht jetzt die Möglichkeit eine zusätzlichen Parameter (Sonderverlinkung) einzuführen, der das Problem löst? Folgende Bedingungen sollte dieser erfüllen:

• Wenn dieser Parameter (Sonderverlinkung) leer ist, bleibt alles wie gehabt.
• Falls dieser Parameter (Sonderverlinkung) nicht leer ist, wird dieser Parameter in der Spalte Offizielle Bezeichnung dargestellt, für die Vorlage Coordinate wird der Text des Parameter Artikel verwendet. Falls der Parameter Artikel leer ist, soll ebenfalls alles so bleiben wie gehabt.

Den Namen des Parameters kann frei gewählt werden, mir fiel nichts besseres ein. Zum Testen kann die Liste der Baudenkmale in Brandenburg an der Havel verwendet werden. Bitte nach dem Denkmal mit der Nummer 09145220 suchen und statt Domklausur mit Spiegelburg und Hauptgebäude der Ritterakademie sowie Friedgarten dieser Eintrag Domklausur mit Spiegelburg und Hauptgebäude der Ritterakademie sowie Friedgarten darstellen werden. Mit OSM sollte dann alles richtig dargestellt werden. Das wäre meine Wunsch. -- Clemens Franz (Diskussion) 21:49, 31. Mai 2016 (CEST)

Spricht was dagegen im Feld "Offizielle Bezeichnung" einfach die offizielle Bezeichnung einzutragen. Und unter "Beschreibung" ein, zwei Sätze _mit_ den richtigen Verlinkungen? --Atamari (Diskussion) 21:55, 31. Mai 2016 (CEST)

M.E.: nein. Im Gegenteil, so sollte es sein. In der Spalte "offizielle Bezeichnung" sollte die offizielle Bezeichnung stehen, und nichts anderes.
Wenn der Parameter Artikel nicht leer ist, sollte in der Spalte "Beschreibung" ein passender (wäre noch zu diskutieren) Text mit dem Link auf den Artikel stehen. Was das Koordinatenproblem angeht, bin ich noch unentschlossen. Entweder: wenn Artikel nicht leer ist, das Artikellemma übergeben und wenn Artikel leer ist, die offizielle Bezeichnung. Oder: immer die offizielle Bezeichnung. Oder: einen extra optionalen Parameter für den OSM-Text einführen. Wäre m.E. sinnvoll, wenn die offizielle Bezeichnung in den Denkmallisten einfach nur "Wohnhaus" etc. lautet. --Global Fish (Diskussion) 15:44, 28. Jun. 2016 (CEST)

Dynamisch auf VE verlinken

Ist es möglich in einer Vorlage dynamisch auf den VE zu verlinken, wenn er in den Benutzereinstellungen aktiviert ist? -- Freddy2001 ^DISK 20:08, 29. Jun. 2016 (CEST)

Ich kenne keine einfache Methode, das zu erreichen. -- hgzh 20:17, 29. Jun. 2016 (CEST)

Nur wenn du einen Link findest, bei dem die Software diese Einstellung ausliest und den entsprechenden Editor bereitstellt. Die Vorlage kann nur auf Links verweisen. --mfb (Diskussion) 23:51, 29. Jun. 2016 (CEST)

Vorlage:SVG

Unter Wikipedia:Redaktion Bilder#Benutzer:Fleshgrinder/Vorlagen/Valides SVG wird auch die Neufassung der Vorlage:SVG diskutiert. Gibt es allenfalls Kommentare zu den Kürzestparametern? Am besten dort weiterdiskutieren. --Leyo 00:02, 28. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 16:53, 11. Aug. 2016 (CEST)

Positionskarte in der Vorlage:Infobox Fernsehturm

Hi,

die o.g. Vorlage verwendet für Großbritannien als Positionskarte stets die gesamte Inselkarte (siehe als Beispiel: Watkin’s Tower, BT Tower wohingegen z.B. die Schweiz oder Deutschland regionale Karten verwendet werden (Fernsehturm St. Chrischona, Berliner Fernsehturm), was auch grundsätzlich sinnvoller ist. Wie kann man das steuern oder ändern? Liegt es vlt. daran, dass es nicht genügend Regionenkarten zu GB gibt? Grüße --Alabasterstein (Diskussion) 10:06, 26. Mai 2016 (CEST)

Diese Vorlage ist veraltet. Warum also soll da noch was verbessert werden? Besser gleich auf Vorlage:Infobox Sendeanlage umstellen. ÅñŧóñŜûŝî (Ð) 19:49, 27. Mai 2016 (CEST)

Antonsusi: Jetzt hast du die Formatvorlage gewechselt, danke dafür. Das Problem ist mit dem Wechsel jedoch nicht beseitigt worden. --Alabasterstein (Diskussion) 20:51, 28. Mai 2016 (CEST)

Ja Alabasterstein, daran liegt es, es gibt schlicht noch keine Regionalkarten vom VK (sh.: https://de.wikipedia.org/wiki/Wikipedia:Kartenwerkstatt/Positionskarten/Europa) J. K. H. Friedgé (Diskussion) 11:41, 29. Mai 2016 (CEST)

Karten muss man ggf. erstellen. Es gibt genug Quellen mit passender Lizenz. ÅñŧóñŜûŝî (Ð) 12:42, 29. Mai 2016 (CEST)

Es gibt Karten zu genüge: Kategorie:Vorlage:Vereinigtes Königreich --тнояsтеn ⇔ 14:38, 29. Mai 2016 (CEST)

Ich bin allerdings überfordert, diese einzubinden. Für einen entsprechenden Auftragswunsch: bin ich hier richtig oder ist das eher eine Sache der Kartenwerkstatt? --Alabasterstein (Diskussion) 08:24, 31. Mai 2016 (CEST)

Die Sendeanlagen-Vorlage kann jetzt alternative Positionskarten einbinden: [29], [30]. --тнояsтеn ⇔ 19:04, 1. Jul. 2016 (CEST)

Vorlage:HLS (Historisches Lexikon der Schweiz)

Hallo, die hilfreiche Vorlage:HLS scheint mir in verschiedener Hinsicht überarbeitungsbedürftig:

A. Ausgangslage:

z. Bsp.: {{HLS|10878|Travers, Johann|Autor= Constant Wieser}}

ergibt z. Z.:

• Constant Wieser: Travers, Johann im Historischen Lexikon der Schweiz

B. Zu bearbeiten:

B.1. Die Zitierrichtlinien des HLS – im Blick auf WP:LIT hin angepasst – bedeuteten, dass in den drei Fällen das Folgende zu sehen sein sollte:

B.1.1. Artikel in Originalsprache

• Stefan Hächler: Krebsliga Schweiz. In: Historisches Lexikon der Schweiz (HLS), Version vom 04. November 2008.

B.1.2. Übersetzter Artikel

was daran erkennbar ist, dass bei „Autor“ ein Zusatz, hier z. B.: „/ GL“ steht; im französischen Art. nichts, da Original; im italienischen Art.: „/ mku“; vllt. könnte die Vorlage den Artikel daraufhin autom. untersuchen

• Béatrice Veyrassat: Industrialisierung. In: Historisches Lexikon der Schweiz (HLS), Version vom 22. Januar 2008, übersetzt aus dem Französischen.
• Es fehlt also bisher (Checkliste):
  • Kursivschreibung des Artikels im HLS
  • Punkt nach Art. und „In:“
  • Kursivschreibung des HLS selbst
  • danach: , Version vom DATUM (für Identifizierung unerlässlich, da Aktualisierungen!)
  • ggf.: , übersetzt aus dem Französischen
  • Punkt am Ende

B.1.3. Kapitel aus Artikeln

B.1.3.1. Beim Zitieren einzelner Kapitel aus großen, von mehreren Autoren verfassten Artikeln, müsste der entsprechende Autor explizit genannt werden.

• Hans Stadler: Schulwesen, Kap. 1: Das Schulwesen im Mittelalter und in der frühen Neuzeit. In: Historisches Lexikon der Schweiz (HLS), Version vom 5. Februar 2007.

B.1.3.2. Wird ein Artikel, der von mehr als zwei Autoren verfasst wurde, als Ganzes zitiert, wird ein allgemeiner Hinweis ohne Nennung der Autoren empfohlen:

• Schulwesen. In: Historisches Lexikon der Schweiz (HLS), Version vom 5. Februar 2007.

nicht so; erledigt, s. u. (Wi-luc-ky)

B.1.4. Die Kombination der Fälle B.1.–3. wäre in die Codierung einzubeziehen.

B.2. Bei Mehrfachzitaten aus dem HLS in einem WP-Art. wäre die Mehrfachverlinkung des Historischen Lexikons der Schweiz (HLS) codeseitig auszuschließen bzw. durch eine Fehlermeldung auszuweisen; Bsp. mit vielen Linkdubletten:

• Constant Wieser: Travers, Johann. In: Historisches Lexikon der Schweiz (HLS), Version vom 7. Januar 2014. korr.: Johann Travers, Erläuterg. s. u. (Wi-luc-ky)

B.3. In der Vorlage:HLS und ihrer Dokumentation wäre der Absatz „Wartung“, hier: „Fehlerhafte Einbindungen“ genannt, mit einem ergänzten Eintrag wünschenswert, so dass die Angabe der Fehleranzahl (zurzeit + ZAHL) immer und auch bei Wert (zurzeit 0) erfolgt, ohne dass dem Link gefolgt werden muss, etwa so:

• Fehlerhafte Einbindungen werden in [[:Kategorie:Wikipedia:Vorlagenfehler/Vorlage:HLS]] kategorisiert (zurzeit <code>{{PAGESINCAT:Wikipedia:Vorlagenfehler/Vorlage:Vorlage:HLS}}</code>).

Könnte sich bitte eine Expertin oder ein Experte dieser Vorlage annehmen? Ich selbst kann leider die Probleme nur so genau wie möglich beschreiben. --Wi-luc-ky (Diskussion) 11:28, 22. Jun. 2016 (CEST)

@Wi-luc-ky: Um Dir mal eine Rückmeldung zukommen zu lassen:

• Üblicherweise sollte (zumindest bei so weitreichenden Änderungen wie Du sie vorschlägst) vorab andernorts ein Konsens hergestellt worden sein, also z.B. auf der Vorlagendisku
• Vorlage:HLS existiert seit etwas mehr als 10 Jahren und ist heute knapp 14.000× im ANR eingebunden, davon etwa 1250× als Einzelnachweis (in <ref>-Tags)
• Die Zitierrichtlinien externer Webseiten sind für WP nicht maßgeblich. Dort können bestenfalls Wünsche geäußert werden, maßgeblich sind diese nicht - zumal sie sich dort jederzeit ändern können und wir dem bestimmt nicht hinterherhecheln.
• Unterscheidung Originalsprache/Übersetzter Artikel: Die aktuell in den 14.000 Einbindungen vorhandenen Parameterwerte geben das nicht her, wir haben keinerlei Information darüber, ob im HLS irgendein Zusatz hinter dem Autor steht. Für „automatische Untersuchungen“ einer externen Webseite müsstest Du Dich an WP:B/A wenden.
• Kursivschreibung, Punkte: Ist bei Konsens problemlos technisch umsetzbar.
• Abrufdatum: Wäre nur bei den Verwendungen als Einzelnachweis sinnvoll, bei Weblinks dagegen unerwünscht. Ist technisch leicht umsetzbar - allerdings bekommen die vorhandenen Einbindungen dadurch noch kein Datum. Das müsste in jedem Artikel einzeln nachgetragen werden.
• Kapitelzitation: mE völlig entbehrlich
• ohne Autoren: Benutzer:Horgner hat mal in einer Sisyphos-Aktion alle fehlenden Autoren nachgetragen, jetzt schlägst Du vor, sie wieder wegzulassen...?
• Mehrfachzitierung: Verstehe ich nicht, warum sollte der mehrfache Aufruf der Vorlage aus einem Artikel verhindert werden? (Mal ganz abgesehen davon, dass das technisch nahezu unmöglich sein dürfte)
• Kat mit Anzahl: machbar, aber eher unüblich.

Bleibt in Summa nicht viel übrig.--Mabschaaf 20:42, 23. Jun. 2016 (CEST)

@Mabschaaf:Vielen Dank, für Deine detaillierte Rückmeldung. Auf Deine Punkte möchte ich so antworten:

1. Im Konsens, natürlich, deshalb meine Fragen hier.
2. Ausgangspunkt meiner Überlegungen war, dass die Vorlage – auch wenn sie schon zehn Jahre besteht und unbestreitbar gute Dienste geleistet hat – mit WP:LIT nicht im Einklang steht. Nun sollten aber gerade die Vorlagen mit gutem bibliographischen Beispiel vorangehen, schon weil viele Nutzer nicht aus WP:LIT, sondern aus Beispielen lernen, und vermeidbaren Fehler hinterherrepariert werden muss.
3. Sicher ist die sog. „Zitierrichtlinie“ für WP nicht verbindlich, aber ein Anhaltspunkt, verfasst von Autoren, die mit dem Thema nicht unvertraut sind. Es sind Wünsche der Autoren für eine einheitliche Gestaltung, die sich wenigstens seit dem 11. September 2012 nicht verändert haben: also eher eine Website in gemächlichem Trab...
4. Um das geflügelte Wort zu bemühen: Ein Blick in das Gesetzbuch schärft die Rechtskenntnis. Heißt hier: Ein Blick in das HLS würde Aufschluss darüber geben, ob eine Übersetzung vorliegt. Ich selbst bin von der Online-Version ausgegangen, wo die erwähnten Hinweise stehen. – WP:B/A einzubinden, ist ein guter Vorschlag.
5. Kursivschreibung, Punkte: ja bitte, siehe WP:LIT, könnte als erstes bearbeitet werden.
6. Nicht das Abrufdatum, sondern das vom HLS selbst bei jedem Artikel angegebene Versionsdatum halte ich – bei den Aktualisierungen des HLS – für eine valide Referenz unabdingbar, was eine Selbstverständlichkeit sein sollte. Das Abrufdatum wäre analog zu anderen Web-refs anzugeben. Tja, die bereits bestehenden Artikel – wären nach und nach bei Edits mit zu bearbeiten, was im übrigen auch in anderen Fällen geschieht, vgl. die jüngste Umstellung der WP:LIT (wo wir bei jeder Bearbeitung auf Inkongruenzen hingewiesen werden, um sie abzuarbeiten) oder die Leiden der Vorlage:BBKL.
7. Kapitelzitation: entspricht dem state of the art in der wissenschaftlichen Literatur.
8. Die von Horgner dankenswerterweise nachgetragenen die Autoren würde ich keinesfalls streichen, sondern stets weiter nennen; die von den Richtlinien vorgeschlagene Weglassung ist ausdrücklich nicht mehr mein Vorschlag – erledigt!
9. Mehrfachzitierung: Klarstellung, da mein Bsp. leider falsch war (sorry!): gemeint war der WP-Art. Johann Travers selbst, wo 6× hintereinander Blaulinks in der Angabe „im Historischen Lexikon der Schweiz“ stehen. Hintergrund ist, dass Blaulinkdubletten vermieden werden sollen. Aber wenn das technisch zu schwierig ist, muss es wohl so bleiben.
10. Kat mit Anzahl: siehe Vorlage:DicEncFreg#Wartung, praktischer Zähler, der weiteres Klicken erspart.

Bleibt also einiges, was leicht umzusetzen wäre, anderes, was intensiverer technischer Arbeit bedarf. Soweit meine zweiten Überlegungen, die eine gute Vorlage besser zu machen suchen. Dankend --Wi-luc-ky (Diskussion) 23:26, 23. Jun. 2016 (CEST)

Irgendwie scheine ich mich daran zu erinnern, dass wir die HLS Zitierregeln im Wikipedia:WikiProjekt Schweiz mal an-/oder besprochen haben auch wenn ich es jetzt nicht finde. Generell sehe ich es sehr ähnlich wie Mabschaaf, echten Verbesserungen mit Mehrwert für den Benutzer. Bei Angleichungen an allgemeinen Regeln der Wikitypographie, da sehe ich absolut keinen Grund warum wir das nicht umsetzen sollten. --Horgner (Diskussion) 07:47, 25. Jun. 2016 (CEST)

Dann schon mal ganz formal die Frage an Benutzer:Wahrerwattwurm: Du hast die Vorlage mal vollgeschützt, würdest Du auf 3/4 reduzieren?--Mabschaaf 09:00, 25. Jun. 2016 (CEST)

Moin. No prob, ist soeben erfolgt. Ich wusste nicht mal mehr, dass und weshalb ich diese Vorlage vor 5 Jahren gevollschützt hatte. Gruß von --Wwwurm 11:37, 25. Jun. 2016 (CEST)

Einfach alle Titel über die Vorlage kursiv zu setzen funktioniert nicht, weil oft der zweite Parameter kursiv an die Vorlage übergeben wird (wahlloses Beispiel: Sonvico). --тнояsтеn ⇔ 22:15, 25. Jun. 2016 (CEST)

Stimmt. Das ist bei diesen 835 Einbindungen der Fall. Das könnte man zwar evtl. noch mit komplexer Programmierung in der Vorlage abfangen, aber Fälle wie in Neue Zürcher Zeitung, ...|''Neue Zürcher Zeitung'' (NZZ)|..., also teilkursiv, gehen gar nicht.--Mabschaaf 15:22, 26. Jun. 2016 (CEST)

Ha noi, „Neue Zürcher Zeitung (NZZ)“ geht auch teilkursiv. VG --PerfektesChaos 16:13, 26. Jun. 2016 (CEST)

Dass man das mit LUA irgendwie gebügelt bekommt, war mir schon klar. Die Frage ist doch: Wie sinnvoll ist es, liebevoll (teil-)kursiv gesetzte Parameterinhalte in der Vorlage "platt" zu machen? Und wenn es hier auf höhere LUA-Künste hinausläuft, bin ich sowieso raus. ;-) --Mabschaaf 16:45, 26. Jun. 2016 (CEST)

Hallo, wird das nun umgesetzt? Ich würde mich freuen, denn dann kann man den HLS-Link endlich auch im Kapitel Literatur verwenden – dort wo er auch hingehört. --= (Diskussion) 14:51, 7. Jul. 2016 (CEST)

Ich sehe keinen Grund, weshalb man die Vorlage nicht schon jetzt im Kapitel Literatur verwenden können sollte. Wie eingangs schon geschrieben, wird sie fast 13.000× außerhalb von ref-Tags verwendet - möglicherweise unter "Weblinks", sicher aber auch unter "Literatur".

Innerhalb der Vorlage eine generelle Kursivschreibung umzusetzen "vernichtet" die in den Artikeln verwendete Teilkursivschreibung.

Versionsdatum wäre mM unkritisch machbar, allerdings kann ich gerade nicht erkennen, wo dann noch der Gewinn durch ein zusätzliches Abrufdatum wäre.--Mabschaaf 17:16, 7. Jul. 2016 (CEST)

Die Vorlage wird fast immer unter Weblinks verwendet, nur sehr selten unter Literatur. Grund dafür ist, dass die Formatierung nicht WP:LIT entsprach (inklusive des fehlenden Artikeldatums). Die manuelle Kursivierung des zweiten Parameters müssen wir halt anpassen, das würde doch über einen Bot gut gehen. Ggf. würde ich einen Teil auch manuell übernehmen. --= (Diskussion) 17:59, 7. Jul. 2016 (CEST)

PS. Die Teilkursivierung ist überflüssig, gar falsch, im HLS-Lemma selbst existiert sie nicht. --= (Diskussion) 18:03, 7. Jul. 2016 (CEST)

Vorlage "erl": Formatierung/Syntax (der Erledigungsgrund)

Nicht erledigt: Das ist das Muster für das im nachfolgenden Abschnitt geschilderte Problem! --Zopp (Diskussion) 14:46, 31. Mai 2016 (CEST)

Vorlage "erl": Formatierung/Syntax (der Erledigungsgrund)

Der Baustein {{erl}} fügt an eine Überschrift etwas an, das in der gleichen, fest definierten Formatierung angezeigt wird, wie die Überschrift selbst. Schon für sich genommen etwas ungünstig (verglichen mit etwas wie {{Erl.}}: erledigtErledigt) Noch problematischer finde ich das aber angesichts der Tatsache, daß man statt des Standards "erl." auch andere Erledigungsvermerke benutzen kann. Da sind Mißverständnisse vorprogrammiert für den Fall, daß eine Abschnittsüberschrift mit einem Text in () Klammern endet, siehe dieser Abschnitt hier verglichen mit dem "Beispielabschnitt" direkt darüber (die Überschrift des Abschnitts hier ist Vorlage "erl": Formatierung/Syntax (der Erledigungsgrund), die 100% identisch angezeigte des Musterabschnitts darüber ist {{erl|Vorlage "erl": Formatierung/Syntax|der Erledigungsgrund}}). Falls die Formatierung nicht angefaßt werden soll, würde ich vorschlagen, daß in Fällen, in denen der zweite Parameter mit angegeben wird, der Standardstring "erl." trotzdem mit angezeigt wird. Entweder vorangestellt, gefolgt von einem ": ", oder besser am Ende, mit einem vorangestellten ", ". Dann würde die Überschrift meines Beispielabschnitts oben so aussehen Vorlage "erl": Formatierung/Syntax (erl.: der Erledigungsgrund) bzw. Vorlage "erl": Formatierung/Syntax (der Erledigungsgrund, erl.). Dann hätten die User wenigstens den immer identisch lautenden und immer identisch positionierten String "erl.", an dem sich ableiten läßt, daß der Erledingungsbaustein dahinter steckt.

P.S.: Ich wollte für dieses Thema nicht drei Abschnitte anlegen, die Diskussion plus die beiden Muster - darum hat auch der Abschnitt hier den eigentlich unpassenden String in Klammern dahinter, um auch gleichzeitig als Muster dienen zu können... --Zopp (Diskussion) 14:46, 31. Mai 2016 (CEST)

Frage in FzW

In Wikipedia:Fragen zur Wikipedia#Legende unter Tabelle es geht da wohl um Vorlage:NaturGeoTabelle DE oder deren Untervorlagen. Vielleicht kann da ja mal jemand vorbei schauen. --Mauerquadrant (Diskussion) 14:37, 4. Jun. 2016 (CEST)

Vorlage:SWB Online-Katalog

Hallo, muss nicht die Vorlage:SWB Online-Katalog (auch) in die Kategorie:Vorlage:Datenbanklink Normdaten einsortiert werden? Danke. --91.1.222.26 19:12, 4. Jun. 2016 (CEST)