Wikipedia:WikiProjekt Vorlagen/Werkstatt

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 45 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit einem Tag mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Vorlage:Autoarchiv-Erledigt/Wartung/Parameter Zeigen auf Nein gesetzt

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Meta-Unterseiten für Vorlagendoku nach Etablierung von Wikidata

Ein aktuell gewordenes Problem sollte gelöst werden:

• Seit Anfang 2013 verwenden wir eigentlich keine zusätzlichen /Meta-Unterseiten zur Vorlagendokumentation mehr, weil mit Verlagerung der Interlanguages auf Wikidata ihr wesentlicher Anlass und die Besuche der Interwiki-Bots wegefallen sind.
  • Dazu gab es Ende 2012 oder Anfang 2013 auch mal beiläufige Diskussionen, bei denen sich die Beteiligten einig waren, dass das jetzt obsolet geworden ist. Ich kann dies nicht mehr wiederfinden, war wohl auch nicht selbst aktiv beteiligt, sondern hatte nur mitgelesen.
• Nun hat in den Mittagsstunden des 19. November 2014 der Benutzer Ich-hab-immer-Recht einen turnusmäßigen Rappel bekommen und ohne vorherige Kommunikation das entsprechende Umfeld revertiert:
  • Hilfeseite, Vorlage:Dokumentation/Doku, Vorlage:Dokumentation/Metaseite, Vorlage:Dokumentation [sic!].
  • Gipfel: dieser LA.
  • Vorlage Diskussion:Dokumentation#Meta entfernt ab 12:59, 19. Nov. 2014; mit freundlichem Gruß an die Admins.
  • Ich bemerkte das erst, als ich abends onwiki ging.
• Die Einführung der /Meta-Unterseiten 2007 durch Revolus erfolgte im Paket mit den Doku-Vorlagen ohne großartige Diskussion oder gar ein MB. Ich glaube nicht, dass ein MB zur allmählichen Abschaffung der /Meta-Unterseiten erforderlich ist; es sollte dann aber halt hier auf dieser Seite mal in der Fachwelt definitiv geklärt werden.
• Ich selbst hatte dies übrigens nicht eigenmächtig gehandhabt, sondern die Festschreibung vor der Verlinkung und Entwaisung der dazu neu geschaffenen Hilfeseite unter einschlägigen Fachleuten kommuniziert: a), b), c), d), e), f).
  • Dort auch ausdrücklich /Meta thematisiert.
• Ich hatte abgewartet, bis der angedrohte Arbeitseifer weitgehend verklungen war (insgesamt wurden ein paar Dutzend /Meta-Seiten [erneut] angelegt, das bringt uns nicht um; es sind noch über 50.000 bzw. 1.500 übrig), zumal gleichzeitig mehrere andere Schlachten tobten (wie diese mit einem krachenden Eigentor) und ich auch nicht in die Weihnachts- und Urlaubszeit geraten wollte. Ich meine, es ist an der Zeit, hier eine dauerhafte Lösung zu finden.
  • Es ist absehbar, dass das erwartbare Ergebnis administrativen Flankenschutzes bedürfen wird.@Rax:@Hephaion, Inkowik, Leyo, Mabschaaf, Mfb:
  • Ich denke dabei auch an eine Mustersperrung der Neuanlage Vorlage:.*/Meta.
  • Die Angelegenheit ist ein reines Machtspiel; alles, wo irgendwo auf einer Seite „Kategorie“ draufsteht, bedürfe der persönlichen Erlaubnis des Zwei-Mann-Projektes „Kategorien“. Die Kategoriesystematik, für die sich dieses Projekt als entscheidungsbefugt erklärt hat, ist hier aber überhaupt nicht tangiert.
• In der Sache: Die vorgetragene Argumentation ist haltlos.
  • Der einzige Unterschied beträfe halbgeschützte Seiten. Interwiki-Bots von fremden Projekten waren teils neu hier und hatten nicht den Status autoconfirmed.
    • Deshalb hatte man zum Bearbeiten der Interlanguages die Meta-Seite ungeschützt gelassen, während einige Doku-Seiten halbgeschützt waren.
    • Für die nur noch menschlichen Bearbeiter wäre das, wenn überhaupt, heute genau umgekehrt anzuwenden: Eher hätte eine IP an einer Beschreibung einen Tippfehler zu korrigieren, denn an der Kategorisierung zu experimentieren. Wobei es auch sehr erfahrene IP gibt, selbst in Kategoriefragen.
    • Wir stellen aber keine unterschiedlichen Zugriffsebenen für menschliche Bearbeiter bei Beschreibung und Kategorien mehr her; höchstens zwischen der wirksam eingebundenen Programmierung und dem begleitenden sonstigen Material.
  • Das name-dropping mit AWB ist nur ein dünnflüssiger Versuch, Ahnung vorzutäuschen. Ob mit AWB oder manuell bearbeitet ist einerlei; wie die Seite heißt und was für Rechte dann gleichfalls.
  • Der Name „Meta“ und das Konzept ausgelagerte Extra-Doku-Seite für includeonly war zu seiner Zeit und unter den damaligen Umständen sinnvoll gewesen; heute gilt das nicht mehr.
  • Es war auch noch niemals verpflichtend gewesen, eine separate Meta-Seite zu haben; mehr als die Hälfte der Doku-Unterseiten hatte immer schon die Kategorien und Interlanguages auf /Doku selbst oder vermischt mit der Programmierung gehabt, und eine /Meta hatte noch nie existiert.
  • Dass der Betreffende weder von Vorlagenprogrammierung noch von Vorlagendokumentation irgendeinen Schimmer hat, hat er selbst vielfach öffentlich dargestellt; zuletzt eindringlich hier.
• Die separaten Meta-Unterseiten für eine einzelne Kategorie sind einfach nur lästig und für Newcomer irritierend; auch für Erfahrene bedarf es zusätzlichen Rumsuchens auf der Programmierungsseite, ansonsten jetzt sinnbefreit.
• Den auslösenden Benutzer auf dieser Seite hier mit einzubeziehen, halte ich nicht für zielführend.
  • Er hatte bereits ausreichend Gelegenheit gehabt, seine private Sichtweise darzulegen.
  • Außerdem kann er sowieso grad nicht, weil wieder mal drei Tage wegen einer ähnlichen eigenmächtigen Aktion absitzend.

Beste Grüße --PerfektesChaos 09:43, 6. Jan. 2015 (CET) (kl. Datenkorrektur) --PerfektesChaos 10:21, 6. Jan. 2015 (CET)

Die eingangs angesprochene vorausgegangene Diskussion war wohl diese. Ansonsten klar Zustimmung: /Meta-Unterseiten sind (inzwischen) überflüssig. Wegen meist nur einer oder zwei Kats eine eigene Unterseite aufzumachen, ist sinnlos. --Mabschaaf 10:23, 6. Jan. 2015 (CET)

Du hast mich erheblich verwirrt mit dem versteckten Ping. Ja, gerne zu den Dokuseiten dazu, sind weniger Seiten die man erstellen und beachten muss. --mfb (Diskussion) 11:11, 6. Jan. 2015 (CET)

+1 --Leyo 20:28, 6. Jan. 2015 (CET)

+1. Meta-Unterseiten sind mittlerweile überflüssig. Kategorien können in Doku oder direkt in die Vorlage integriert werden. --тнояsтеn ⇔ 10:16, 8. Jan. 2015 (CET)

+ 1 Für die allmähliche Abschaffung der Meta-Unterseiten von Vorlagen --Wiegels „…“ 20:14, 8. Jan. 2015 (CET)

+1, eigentlich ein klarer Fall. Besonders schön fand ich, dass das Katprojekt zu fragen sei, wo denn nun die Kategorien in den Vorlagen stehen... -- ɦeph 11:11, 10. Jan. 2015 (CET)

+1, auf de.wikivoyage gibt es keine /Meta-Unterseiten. -- FriedhelmW (Diskussion) 11:21, 15. Jan. 2015 (CET)

Nein, Metakram gehört auf Metaunterseiten und hat nix auf der Domuentationsseite verloren. Und daß er in der Vorlage nix zu suchen hat, ist schon wegen der Problematik gesperrter Vorlagen klar. Gerade was das umkategorisieren will, ist der gegenwärtige Zustand äußerst unbefriedigend, statt einfachen Abarbeitens einer Arbeitsliste, muß man jeweils die Vorlage anwählen, ob die Kategorie direkt eingebunden oder transkludiert ist. Das ist nervig, interessiert euch aber wohl nicht. Wer die Meta-Unterseiten abschaffen will, soll ein MB machen. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 15:03, 9. Jan. 2015 (CET)

PS: ich empfinde das maskierte Verlinken übrigens hinterfotzig und böswillig, da es offensichtlich dazu diente, zu verhindern, daß ich angepingt werde. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 15:09, 9. Jan. 2015 (CET)

@PerfektesChaos:: Gewöhne dir doch mal bitte die Verwendung der Spezialseite Permanenter Link endlich ab, es nervt und ist nicht gerade benutzerfreundlich, daß man nicht weiß, auf welche Seite hinverlinkt wird und das Popups nicht funktioniert. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 15:13, 9. Jan. 2015 (CET)

"Nein, Metakram gehört auf Metaunterseiten und hat nix auf der Domuentationsseite verloren." - sagt wer (außer dir)? Niemand will die Kategorien in die Vorlage setzen, insbesondere bei gesperrten Vorlagen sollte es immer eine Dokuseite geben. Falls es die nicht gibt, kann man sie anlegen. Inwiefern das Arbeitslisten stören soll, wenn man die Dokuseite statt der Metaseite bearbeitet, verstehe ich nicht. --mfb (Diskussion) 15:16, 9. Jan. 2015 (CET)

Das ist ganz logisch. Es gibt u.a. Vorlagen mit Kategorisierung, und ich halte es für zielführend, daß nur dann Kategorien im Vorlagenquelltext enthalten sind, wenn sie in Bezug auf deren Transkludierung eine Auswirkung haben (bspw. Ortskategorisierung), nicht aber, daß im eigentlichen Vorlagenquelltext Kategorien oder eventuelle andere Metadaten vorhanden sind, die eben nicht auf den einbindenden Artikel angewendet werden, sondern nur auf die Vorlage selbst. Auch trägt das zu einem besseren Verständnis des Quelltextes und zur Übersichtlichkeit bei. Desweiteren gilt das Argument, weswegen die Metaunterseiten einst eingebunden wurden, auch fortwährend. Ein Teil der Vorlagen ist vollgeschützt, und es ist nicht unbedingt sinnvoll, daß wegen Änderungen einer Kategorie einer Vorlage hunderttausende von Artikeln neugerendert werden. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 15:22, 9. Jan. 2015 (CET)

(BK) zu ob die Kategorie direkt eingebunden oder transkludiert ist - korrekt. Jetzt musst Du ggf. auf drei Seiten suchen, wo die Kat steht: In der Vorlage selbst, in der Doku-Seite oder in der Meta-Seite. Wenn es keine Meta-Seiten mehr gäbe, wird die Sache klarer. Und wenn sich irgendwann mal rumspricht, dass zu jeder Vorlage eine Doku-Seite gehört, dann ist es ganz klar. Das erleichtert das Umkategorisieren übrigens erheblich, wenn die Vorlagen selbst vollgesperrt sind...--Mabschaaf 15:21, 9. Jan. 2015 (CET)

Das ist nur vorübergehend; sobald alle Vorlagen eine Meta-Unterseite haben, mußt du nicht nehr suchen. Zur Dokumentation gehören Kategorien jedenfalls nicht. Es wird nix dokumentiert. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 15:24, 9. Jan. 2015 (CET)

Deine Argumentation zeigt deutlich, wieso Dokuseiten sinnvoll sind - da sind wir uns alle einig. Ich sehe aber keinen Grund, für Kategorien nochmal eine eigene Unterseite aufzumachen. Das einzige Argument von dir dazu ist offenbar "weil ich Meta als Name besser finde als Dokumentation". Das ist Ansichtssache. --mfb (Diskussion) 15:42, 9. Jan. 2015 (CET)

Der Name ist mir völlig egal, kann meinetwegen in /Null815-4711 umbenannt werden. Für mich ist es wesentlich, daß Kategorien (und ggf. weitere Metainformationen), die nicht in den einbindenden Artikel transkludiert werden, nicht im Quelltext der eigentlichen Vorlage landen und daß auf der Dokumentationsseite nur die Dokumentation steht – schon wegen der bereits zitierten "Neulinge", damit diese nicht verwirrt werden. /Ganz abgesehen davon rechne ich damit, daß früher oder später jede Seite in Wikipedia eine Metaseite erhält; spätestens, wenn man endlich ein sinnvolleres System der Referenzierung (vulgo: Fußnoten) schafft, aber das nur nebenbei. Die Spezialseite mit den Seiteninformationen dürfte der erste Schritt dorthin gewesen sein./ Es ist jedenfalls ein Vorteil, wenn in einem Vorlagenquelltext nur solche Kategorien stehen, die sich auf den einbindenden Artikel auswirken, auf der Dokumentationsseite nur das, was die Vorlagenverwendung dokumentiert, und aller Kram, was die Vorlage selbst angeht, auf einer eigenen Seite. Schon der vielen Neulinge wegen, die Vorlagen bearbeiten. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 15:54, 9. Jan. 2015 (CET)

• Nachdem deine ursprüngliche Argumentation durchsichtig-heiße Luft war, schiebst du nun immer dünnere und immer untauglichere Begründungen, bzw. reine Nebelkerzen hinterher:
  • In Sachen einfacherem Zugang für Einsteiger lieferst du eine groteske Tatsachenverdrehung, wie dir weiter oben schon entgegnet wurde. Natürlich ist die separate Bearbeitung einer Seite nur für eine Zeile mit Kategorie und nur bei Vorlagen sehr viel unverständlicher und komplizierter, und deshalb gerade nicht für erste Schritte als neuer Vorlagenprogrammierer empfehlenswert.
  • Auch bei der Spezalseiten-ähnlichen Seiteninformation offenbarst du eine schon Mitleid erregende Verwechslung von Ursache und Wirkung. Sie ist einfach nur der Datenbankauszug einiger aggregierter Meta-Informationen über eine Seite; somit immer nur das Resultat der zusammengeführten Bestandteile, und wird nie ein Eingabeformat sein.
  • Deine Theorien über zukünftige Seitenorganisation kennt niemand sonst auf der Welt; es gibt auch keinerlei Pläne der WMF in dieser Richtung. Das hast du dir just ausgedacht und an den Haaren herbeigezogen. Es gibt auch für Artikel nirgendwo Absichten, Kategorien zukünftig nicht mehr in den Artikelseiten, sondern auf gesonderten Unterseiten abzulegen. Das würdest du uns aber auch noch als Erleichterung für Newbies auftischen, bloß um auf deinem Planeten Recht zu behalten.
  • Im Übrigen widersprichst du dir damit auch noch selbst: Gerade wenn und weil es dann im nächsten Jahrtausend ein separates System zur Verwaltung der Metainformationen zu einer Seite geben würde, wären separate Meta-Seiten mit einer lumpigen Zeile drauf erst recht obsolet. Deine Argumentation ist von vorn bis hinten eine reine Luftnummer.
  • Auch ein praktikableres System für Endnoten konnte bisher noch niemand vorschlagen und realisierbar spezifizieren; auch hier nur Nebelgranate und Rauchbombe. Davon irgendetwas für den St.-Nimmerleins-Tag abhängig zu machen, wäre grob unvernünftig.
  • Zitat „Das ist nur vorübergehend; sobald alle Vorlagen eine Meta-Unterseite haben, mußt du nicht nehr suchen.“ – das ist Nonsens. Dazu ist es in den letzten sieben Jahren weder bei den über 50.000 Vorlagen jemals gekommen noch allein bei den 3.800 mit /Doku-Unterseite auch nur zur Hälfte. Die gesonderte /Meta-Unterseite war immer schon ein Sahnehäubchen gewesen, als die Bots noch aktiv waren, und zukünftig wird noch weniger jemand bereit sein, sie anzulegen, bloß um sich von deinen unausgegorenen Phantastereien knechten zu lassen.
• Auch die enWP, die du uns so oft als leuchtendes Beispiel aufs Brot schmierst, verschweigst du diesmal schamhaft.
  • Kein Zufall: en:Help:Template #Documentation and categories – kennt zwar Doku-Seiten, aber nix mit /Meta.
  • Die wagen es übrigens sogar, eine eigene Seite nur zur Vorlagendoku zu haben: en:Wikipedia:Template documentation – ich erwarte nun unverzüglich dort deinen Löschantrag analog zu diesem Meisterwerk mit gleicher Begründung.
  • Der bisherige Weg der deWP dürfte einmalig auf der Welt gewesen sein.
• Kurz zusammengefasst: Du versuchst regelmäßig, allen anderen Menschen deinen privaten Willen und deine Albernheiten aufzunötigen; um nichts anderes geht es. Gelingt es dir mal ein paar Tage nicht, andere Benutzer unter deine Knute zu bringen, fühlst du dich offenbar nicht mehr wohl. Welcher Sachverhalt gerade ansteht, scheint ziemlich egal zu sein – Hauptsache andere Menschen mit deinen Machtgelüsten tyrannisieren.

--PerfektesChaos 10:35, 10. Jan. 2015 (CET)

Es gibt für und gegen Meta-Unterseiten jeweils gute Argumente. Ich bin dafür Meta-Unterseiten vorerst beizubehalten. --Fomafix (Diskussion) 11:50, 10. Jan. 2015 (CET)

(nach BK) Volle Zustimmung zu PerfektesChaos beim Thema Metaseiten. Da die Interwikis auf Wikidata liegen, braucht es jetzt ganz sicher wegen der zwei oder drei Kats keine Metaseiten mehr. Zum einen ist es für Neulinge schon verwirrend genug, dass sie, wenn sie auf einer Vorlagenseite auf bearbeiten klicken, im Editfenster statt des auf der Seite angezeigten Textes die Vorlagensyntax sehen. Wenn man dann auch noch die Kategorien auf eine separate Seite packt, blick ein Neuling doch überhaupt nichtmehr durchund auch für die Ersteller der Vorlagen hat einen größeren Aufwand, der keinen Sinn macht, da die Kats auch schließlich der Dokumentation dienen, weil sie das auffinden ähnlicher Vorlagen erleichtern. Dokuseiten halte ich, auch wenn sie natürlich Neulinge zunächst verwirren könnten, dennoch für sinnvoll, da so die Überisichtlichkeit verbessert wird und man die eigentliche Vorlage unabhängig von der Doku bearbeiten beziehungsweise vor Bearbeitungen schützen kann.
Beim Thema Metaseiten zu Artikeln kann ich auch nur den Kopf schütteln, da diese auch nichts zur Übersichtlichkeit beitragen würden und darüberhinaus die so oft genannten Neulinge vermutlich eher verwirren würden, wie ihnen zu helfen. Ähnliches geschieht teilweise schon bei Vorlagen in Artikeln, wie man an Anfragen auf der FZW oder FVN erkennen kann, da die Neulinge zurecht davon ausgehen, dass das was im Artikel zu sehen ist auch über den Beabeiten-Knopf erreichbar ist. Viele Grüße Patrick Stützel (Diskussion) 11:55, 10. Jan. 2015 (CET)

Meta-Unterseiten sind insofern unpraktisch, als dass Umkategorisierungen verkompliziert werden. Letztens wurde Kategorie:Vorlage:Vom Druck ausgeschlossen nach Kategorie:Vorlage:vom Druck ausgeschlossen verschoben, verbunden mit sehr viel Handarbeit, da der Umkategorisierungs-Sebbot nicht nach Kategorien in eingebundenen Seiten sucht. Auf der Dokumentationsseite würde dies zwar auch nicht funktionieren, dort kann man aber wenigstens mit Hotcat arbeiten. Auf Metaseiten muss man aufgrund der Vorformatierung alle Kategorien per Hand ändern.
Langfristig wäre für Kategorien eher ein System nach Vorbild des Seitenschutzes sinnvoll: Die Kategorien einer Seite werden nicht mehr im Artikeltext gespeichert, sondern automatisch aus der categorylinks-Datenbanktabelle generiert. Bearbeitet werden sie über eine Art Spezial:EditCategories (die dennoch die derzeitige Hotcat-Leiste am Seitenende imitieren könnte), Änderungen dokumentiert über Spezial:Log/category. Hätte noch einige positive Nebeneffekte. Aber das ist hier ja nur ein kleines Gedankenexperiment. IW — 12:30, 10. Jan. 2015 (CET)

Ich befürchte eher, daß uns irgendwann von der Foundation die Kategorien via Wikidata aufoktroyiert werden und wir hierzupedia gar keine Möglichkeiten mehr haben werden, das Kategoriensystem zu beeinflussen, aber das führt in eine andere Diskussion, lassen wir das also. — Schön, daß du auf die Kategorienverschieung Kategorie:Vorlage:Vom Druck ausgeschlossen nach Kategorie:Vorlage:vom Druck ausgeschlossen hingewiesen hast, die der unmittelbare Auslöser war dafür, daß ich die Metaseiten wieder hergestellt habe. Es wäre in vergleichbaren Fällen weitaus weniger aufwendig, anhand der Kategorisierung eine Arbeitsliste zu erstellen und in dieser Arbeitsliste den vorhandenen Lemmata ein /Meta hintanzustellen und dann diese Arbeitsliste automatisch abzuarbeiten, etwa mit AWB, als händisch zu kucken, wo die Einbindung erfolgt.

Generell könnte man darüber nachdenken, ob es nicht sinnvoller wäre, die Kategorien gar nicht mehr in includeonly zu setzen, sodaß die Metaseite selbst kategorisiert wird und nicht mehr die Vorlage, wenn's nicht einen zusätzlichen Klick erfordern würde, um zur eigentlichen Vorlage zu gelangen.

@PerfektesChaos/Patrick Stützel: Ihr solltet euch einig werden, ob ihr nun das Argument der Neulinge (das initial durch PC in die Diskussion eingeführt wurde) nun anerkennt oder nicht, bevor ihr euch gegenseitig zustimmt. Generell ist es aber so, daß Neulinge Vorlagen eher gar nicht bearbeiten. Worum es mMn geht, das ist die Vielzahl von Benutzern, die als Portalbetreuer und dergleichen "ihre" (im Sinne sowohl von selbstgebastelt als auch von relevant im betreuten Portal) Vorlagen bearbeiten. Diese werden weitaus mehr durch Lua ausgebremst, als dadurch, daß Vorlagenkategorien und Vorlagendokumentation auf gesonderten Unterseiten liegen.

Daß man hier EN nicht als Beispiel bringen kann, wüßtest du, wenn du nur einen Blick auf die dortige Kategorisierung von Vorlagen geworfen hättest – dort werden Vorlagen bedenkenlos mit Artikeln zusammen kategorisiert. Das Kategoriensystem der EN:WP ist von A bis Z Schrott, mit Ausnahme des Quality-Assessment-Systems, daß dort vorbildlich organisiert ist (Beispiel), wobei die Kategorisierung dieser Einstufungen ausschließlich anhand der Diskussionsseite erfolgt, etwa Stubs des WikiProjektes Freedom of speech. Jeglicher Ansatz, ein solches Qualitätsmanagement auch hierzupedia einzuführen, wurde jedoch von Anfang an sabotiert, etwa mit der Abschaffung der Stubvorlage und mit der nahezu konsequenten Löschung der Portalhinweisvorlagen. Um zurück zum Thema zu kommen: du wirst nicht erleben, daß ich das Kategoriensystem von EN als Beispiel dafür nehme, wie man etwas machen sollte, sondern nur dafür, wie man es nicht machen sollte.

Daß Informatiker und insbesondere Entwickler nicht daür prädestiniert sind, benutzerfreundliche Funktionsweisen zu erdenken, ist nichts neues, mit Natürlich ist die separate Bearbeitung einer Seite nur für eine Zeile mit Kategorie und nur bei Vorlagen sehr viel unverständlicher und komplizierter, und deshalb gerade nicht für erste Schritte als neuer Vorlagenprogrammierer empfehlenswert. unterstreichst du diese Problematik erneut. Im Gegensatz zu deiner Meinung ist es für den Laien selbstverständlich viel einfacher, in dem Bapperl unten, in dem steht, daß die Dokumentation von einer eigenen Unterseite eingebunden wird und daß die Kategorien von einer eigenen Unterseite eingebunden werden, auf "bearbeiten" zu klicken, wo sich dann außer der Kategorisierung der Vorlage kaum noch etwas befindt, als im Quelltext der Vorlage selbst irgendwo zu suchen, wo sich eine in noinclude gewrappte Kategorisierung findet. Ganz abgesehen davon, zu verstehen, warum es andere Kategorien im Quelltext der Vorlage geben kann, die in onlyinclude gewrappt sind. Ganz geschweige denn zu verstehen, was der Unterschied zwischen beiden ist. Der Laie (ich schreibe bewußt nicht Neuling, weil das auch Benutzer betrifft, die jahrelang in WP tätig sind und nur alle Jubeljahre gezwungen sind, an "ihrer" (siehe oben) Vorlage etwas zu verändern, genauso davon betroffen sind) liefe stets Gefahr, die Vorlagenkategorisierung einfach zu den bereits vorhandenen Kategorien im Vorlagenquelltext hinzuzuschreiben, ohne die Wirkung von onlyinclude/includeonly/noinclude zu bedenken. Eine eigene Metaseite beseitigt diese Stolperstelle und ist folglich benutzerfreundlich. Aus ähnlichem Grund ist es übrigens sinnvoll, daß nicht jeder x-beliebige Redaktor einer Dokumentationsseite versucht ist, Schreibweise der Kategorien oder gar deren Benennung zu verändern. Warum das so ist, braucht man nicht zu erläutern, ein Blick auf das Chaos unter Wikipedia:Löschkandidaten/9. Januar_2015#Schutzgebiete in Österreich verdeutlicht, warum das Anlegen von neuen Kategorien eigentlich einer eigenen Benutzergruppe mit besonderen Rechten vorbehalten bleiben sollte. Benutzerfreundlichkeit ist zwar gut, aber manchmal ist es besser, wenn eine Änderung nicht zu prominent zugänglich ist. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 13:23, 10. Jan. 2015 (CET)

„Es wäre in vergleichbaren Fällen weitaus weniger aufwendig, anhand der Kategorisierung eine Arbeitsliste zu erstellen und in dieser Arbeitsliste den vorhandenen Lemmata ein /Meta hintanzustellen und dann diese Arbeitsliste automatisch abzuarbeiten“ – na ja, das würde aber genauso mit /Doku gehen. Kategorien ließen sich auch leichter bearbeiten, wenn Hotcat (in optimierter Form) zur Extension und standardmäßig aktiviert werden würde. Dann kann man Kategorien ändern, ohne sie lange suchen zu müssen. Neue Benutzer ändern selten etwas an Vorlagen, und noch hundertmal seltener etwas an Kategorien von Vorlagen. Allgemein sind da maximal fünf Personen systematischer dran beteiligt. Und für den normalen Vorlagenersteller ist es denke ich einfacher, die Kategorien unten an die Vorlage oder besser deren Dokumentationsseite zu hängen. IW — 18:22, 10. Jan. 2015 (CET)

Früher waren die Meta-Unterseiten durchaus sinnvoll, um Benutzern ohne erweitere Rechte die Bearbeitung von Kategorie und Interwikis bei vollgesperrten Vorlagen zu ermöglichen. Nach der Migration der Interwikis nach Wikidata überwiegen jedoch meiner Meinung nach die Nachteile einer solchen Aufteilung. Sinnvoller und zukunftsweisender wäre meiner Meinung nach die Integration mehrerer separater Unterseiten in die Vorlage:Dokumentation. Dazu zählt neben Meta auch Test und Wartung. Aus Sicht eines Vorlagenentwicklers ist dies aus mehreren Gründen sinnvoll. Der wichtigste aber ist, dass Vorlagenentwickler, die nach einer Änderung an einer Vorlage die zugehörige Dokuseite anpassen, derzeit nicht darauf gestoßen werden, dass etwaige Tests anzupassen oder Wartungslinks zu ergänzen wären. Dies würde durch eine Integration der o.g. Unterseiten verbessert werden. Selbstverständlich können die Unterseiten auch bestehen bleiben. Dies wäre aber meiner Meinung eher das Festhalten an einer bestehenden, aber inzwischen überholten Lösung. Daher würde ich die Integration der o.g. Unterseiten in die Vorlage:Dokumentation befürworten. Gruß --W_I^KImaniac 13:39, 10. Jan. 2015 (CET)

+1 Ganz klar zur Entfernung von /Meta. Und das nicht nur weil ich hauptsächlich auf Commons aktiv bin, wo es 1. ebenfalls keine solche /Meta-Seite gibt und 2. dort die Vorlagen, entgegen einem Pro-Argument, wesentlich komplizierter und ausgiebiger kategorisiert sind als hier (Projekt bedingt). Ich meine alle wesentlichen Argumente wurden jetzt vorgetragen und eine weiter Aufblähung, geschweige denn ein MB (wie von jemanden vorgeschlagen) sind hier vollkommen unnötig. ↔ User: Perhelion  21:19, 11. Jan. 2015 (CET)

Dann sind wir uns mit einer Ausnahme alle einig, Formafix Beitrag interpretiere ich als "beides möglich". --mfb (Diskussion) 21:59, 11. Jan. 2015 (CET)

Wikipedia ist keine Demokratie, sondern hier gehet es um Sachargumente. Bislang kann ich hier kein stichhaltiges Argument für die Entfernung der Metaseiten erkennen. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 23:34, 11. Jan. 2015 (CET)

Alle anderen können die Argumente erkennen. --mfb (Diskussion) 00:38, 12. Jan. 2015 (CET)

Welche Argumente: Metaseiten abschaffen (weil wir schon mal drüber diskutiert haben), Metaseiten abschaffen (weil Matthiasb keine Ahnung von Vorlagenprogrammierung hat), Metaseiten abschaffen (weil Interwikis jetzt auf Wikidata sind), Metaseiten abschaffen (weil Entwickler leider zu dumm sind, Metaunterseiten als solche zu erkennen). Vier völlig nutzlose Argumente gegen das Argument "Benutzerfreundlichkeit". Danke, keine weiteren Fragen. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 01:02, 12. Jan. 2015 (CET)

@mfb: Sicherlich ist beides möglich, aber bitte meinen Beitrag nicht uminterpretieren. Ich bin vorerst für das Behalten der bisherigen Metaseiten. --Fomafix (Diskussion) 09:45, 12. Jan. 2015 (CET)

@Fomafix:

• Ich möchte deine Position gern verstehen.
• Du schriebst oben von guten Pro-Argumenten.
  • Würdest du uns freundlicherweise mal ein gutes und zukunftsweisendes Pro-Argument benennen?
  • Welchen praktischen Nutzen versprichst du dir davon?
  • Aus welchen Gründen sollten Meta-Unterseiten neu angelegt werden?
• Wie deute ich deine Handlungsempfehlung „vorerst beizubehalten“ für die kommenden Jahre – da 2013 die Interlaguages weitgehend auf Wikidata gingen, wie lange soll aus der Perspektive von 2015 dieses „vorerst“ noch dauern, und von welchen konkreten Umständen würde es abhängen, dass das „vorerst“ nunmehr beendet würde?

VG --PerfektesChaos 13:24, 12. Jan. 2015 (CET)

Kategorien auf separaten Seiten zu haben hat folgende Vorteile:

• Die Änderungen an den Kategorien werden in einer separaten Versionsgeschichte geführt.
• Gleichzeitige Änderung von Inhalt und Kategorien ist im Gegensatz zu Artikeln nicht notwendig.
• Die Seite mit den Metadaten kann mit separaten Berechtigungen versehen werden, getrennt von der Vorlage und getrennt von der Dokumentation.
• Das System ist seit Jahren etabliert.

--Fomafix (Diskussion) 13:57, 12. Jan. 2015 (CET)

Wo ist der Vorteil einer separaten Versionsgeschichte für Doku und Kategorien?

Gleichzeitige Änderungen sind nie notwendig. Wenn Doku und Kategorie auf der gleichen Seite sind, sind sie aber möglich.

An welcher Stelle werden separate Berechtigungen für Doku und Kategorien benötigt? Nicht alles, was technisch möglich ist, ist automatisch ein Vorteil. Nachteil: Man muss bei mehr Seiten die Rechte einstellen.

Das System ist etabliert, wird aber im Wesentlichen nur bei Infoboxen verwendet. --mfb (Diskussion) 14:09, 12. Jan. 2015 (CET)

Der Vorteil einer separaten Versionsgeschichte liegt darin, daß einfacher überwacht werden kann; Diff-Links werden übersichtlicher, gerade bei Verwendung von Pop-Ups. Und, hey, vielleicht kommen wir ja irgendwann auf die Idee, Dokumentationsseiten in eine andere Systematik einzusortieren als die eigentliche Vorlage. ;-) --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 16:58, 12. Jan. 2015 (CET)

Ich sehe diese separate "Überwachung" eher als Nachteil, zum einen muss man zig zusätzliche Seiten in die Beobachtungsliste aufnehmen, zum anderen finden sich Neulinge schlecht zurecht, so dass ab und an eine Diskussion auf den Unterseiten gestartet wird. Bei Pop-ups mag die Unterseite einen Vorteil haben, in der normalen DIFF-Ansicht ist das egal. Über kommende Ideen zu philosophieren ist auch unnütz Aber das weiß Matthiasb ja selbst. Fazit: Die Meta-Unterseiten haben mit der Auslagerung der Inter-Wikilinks an Bedeutung verloren, der Bedarf und auch die Nutzung hält sich doch arg in Grenzen oder? Wie viele Vorlagen mit Dokumentationsseite haben denn überhaupt eine Meta-Seite und was steht da wirklich noch drin? Können wir die Vor- und Nachteile mal übersichtlich gegenüberstellen? Die aktuelle Diskussion ist bereits sehr unübersichtlich. --Cepheiden (Diskussion) 15:38, 25. Jan. 2015 (CET)

Infoboxen haben, sofern sie eine Dokuseite haben, in der Regel auch eine Metaseite. Bei nicht-Infoboxen sind beide Unterseiten selten, kommen aber auch meistens zusammen soweit ich das sehe. --mfb (Diskussion) 10:45, 26. Jan. 2015 (CET)

Statistik:

• /Doku-Seiten solo gibt es: um 1.900
  • Bei 362 davon stehen die Kat auf /Doku, bei über 1.500 in der Programmierungsseite.
• /Meta-Seiten gibt es zurzeit: 1696
  • Im November waren das noch 1620 gewesen; über 50 hat ein einzelner Benutzer Ende November 2014 angelegt; ein Dutzend weitere kam aus alter Tradition von verschiedensten Benutzern im Rahmen von völligen Neuanlagen hinzu.
• Über 50.000 haben nur die Programmierungsseite, was für eine simple Navileiste auch erstmal ausreicht.

VG --PerfektesChaos 10:41, 27. Jan. 2015 (CET)

Wie sind die 1500 zu interpretieren? 1500 Vorlagen haben Dokuseite, aber Kategorien stehen auf der Hauptseite? Ich würde erwarten, dass Kategorien mit Metaseiten nahezu immer auch eine Dokuseite haben, was nur wenige Dokuseiten ohne Metaseite ergibt. Haben dann Vorlagen eine Metaseite und trotzdem Kategorien auf der Hauptseite? Das wäre ein deutliches Beispiel für Nutzerverwirrung. --mfb (Diskussion) 10:47, 27. Jan. 2015 (CET)

Also nochmals:

• ≈1.500 nur /Doku, keine /Meta, Kat in der Programmierungsseite.
• 362 nur /Doku, keine /Meta, Kat in der /Doku.
• 1696 /Doku und /Meta, Kat dann mutmaßlich auf /Meta.
• >50.000 keine /Doku, Kat in der Programmierungsseite.

LG --PerfektesChaos 12:03, 27. Jan. 2015 (CET)

Ich habe mir die Fettschreibung angemaßt. Wenn schon die Vorlagen bei vorhandenen /Dokus (ohne /Meta) meist (1.500/1.862) auf der Programmierseite stehen, wie kommst Du darauf, daß sie bei vorhendener /Meta-Seite nicht trotzdem auch auf der Programmierseite stehen. Kannst Du das auch auszählen? --Tommes ^✉ 20:29, 31. Jan. 2015 (CET)

Es könnte sich theoretisch so verhalten: /Meta-Seite existiert, Kat stehen jedoch auf /Doku oder Programmierung.

Dann wäre aber die /Meta völlig leer oder enthielte nur ein versprengtes Interlanguage.

Da ich langjährig in den Vorlagen unterwegs bin, kann ich dir sagen, dass mir ein solcher Fall nie unterkam, ich aber nicht ausschließen kann, dass dies bei ein oder zwei Vorlagen der Fall sei. Insofern das von mir verwendete Wort „mutmaßlich“. Über ein oder zwei Irrläufer hinaus aber mit Sicherheit keine zahlenmäßig relevante Größe.

Schicke Sig übrigens.

LG --PerfektesChaos 20:40, 31. Jan. 2015 (CET)

Nicht berücksichtigt wurden hier Fälle, wo Kategorien sowohl auf der Programmierseite als auch auf der Meta-Seite stehen. Was spricht eigentlich dagegen, die Meta-Seiten per Bot aufzulösen, d. h. die Kategorien per Bot in die Programmierseite zu übernehmen? 129.13.72.197 15:52, 12. Feb. 2015 (CET)

• Na, auf die Programmierseite ganz sicher nicht.
• Längere Dokumentationen sollen überhaupt nie auf der Seite mit der Programmierung stehen.
  • Grund: In ihrer Versionsgeschichte sollen ausschließlich die bei der Einbindung wirksamen Änderungen erscheinen und sich zurückverfolgen lassen. Wenn aber auf eine Änderung der Programmierung ein Dutzend Formulierungsverbesserungen in TemplateData und Kategoriesortierschlüssel und Anwendungsbeispiele kommen, sind die nach außen wirksamen Edits nicht mehr nachvollziehbar.
• Kat auf der Programmierseite haben auch wieder das alte Problem: Wegen 100.000-facher Einbindung mag die Programmierung vollgeschützt sein.

LG --PerfektesChaos 10:40, 15. Feb. 2015 (CET)

Zum Thema Dann wäre aber die /Meta völlig leer oder enthielte nur ein versprengtes Interlanguage.: Vorlage:Infobox Meerenge/Meta. 85.212.17.126 03:20, 15. Feb. 2015 (CET)

Tja, wie oben, solche Skurrilitäten mögen irgendwo vorkommen. LG --PerfektesChaos 10:40, 15. Feb. 2015 (CET)

Entarchiviert; mitnichten erledigt. --PerfektesChaos 15:44, 19. Apr. 2015 (CEST)

Daher aus Archiv gelöscht: [1]. (Vermeidung von Dubletten). --тнояsтеn ⇔ 10:07, 20. Apr. 2015 (CEST)

In dem Zusammenhang... --mfb (Diskussion) 15:53, 19. Apr. 2015 (CEST)

Viel Diskussionsbedarf herrscht offenbar nicht mehr. Es gibt Argumente für beide Seiten, aber es sind sich fast alle einig. Es kann umgesetzt werden. Man muss sich nur auf den Editwar einlassen, da ein kleines gallisches Dorf.. ach ne, falscher Comic. --mfb (Diskussion) 16:41, 6. Mai 2015 (CEST)

still pending … --PerfektesChaos 14:39, 4. Jun. 2015 (CEST)

Neue erweiterte Wahldiagramm-Vorlage

Guten Morgen. Unter Portal Diskussion:Politik#Fehlende Vorlage für Kreistage entstand eine Diskussion über die bestehenden Vorlagen Wahldiagramm und Sitzverteilung. In der Diskussion habe ich moniert, dass manche Landkreis-Artikel im Politik-Abschnitt überladen wirken. Zudem besteht bislang keine eigene Vorlage für die selbst gestrickte Tabelle (siehe z. B. Hochtaunuskreis#Kreistag), wobei die Inhalte dieser Tabelle in den eben genannten Vorlagen quasi wiederholt werden. Problem bei der selbst erstellten Tabelle ist, dass die Abkürzungen der Parteien nach Belieben geschrieben werden und der Tabellencode teilweise unnötig mit veralteten Codes aufgebläht wird. Nun wäre es nicht verkehrt, um die Lesbarkeit, Übersichtlichkeit und Einheitlichkeit zu gewährleisten, alle drei Elemente in einem zu vereinen. Negativbeispiele für überladene Politik-Abschnitte sind z. B. Bodenseekreis#Kreistag und Landkreis Altenkirchen (Westerwald)#Kreistag. Die selbst erstellte Tabelle könnte obsolet werden, da die Inhalte (zumindest der jüngsten Wahl) im Balkendiagramm nochmals aufgeführt werden (für die Daten der Wahlen, die weiter in die Vergangenheit reichen, könnte z. B. eine Auslagerung stattfinden, z. B. unter Wahlen im Hochtaunuskreis). Die Zahlen aus der Vorlage Sitzverteilung könnten einfach im Balkendiagramm eingepflegt werden. Das Balkendiagramm an sich könnte komprimiert werden und dabei informativer und moderner gestaltet werden. Schön wäre es außerdem, wenn das bisher eingesetzte Bindestrich-Minus, das im Balkendiagramm als Minuszeichen fungiert, ersetzt würde. In der Diskussion habe ich darüber hinaus die teilweise fehlerhafte Darstellung auf aktuellen Smartphones thematisiert. So schneiden manche Inhalte im Balkendiagramm jeweils andere Zeichen.
Ob nun eine neue Vorlage erstellt oder die bisherige Wahldiagramm-Vorlage erweitert werden sollte, ist nun die Frage. Am einfachsten wäre sicherlich eine Überarbeitung bzw. Erweiterung der bestehenden Vorlage. Kurz zusammengefasst: Es geht nun um das Hinzufügen der Sitzverteilung im Wahldiagramm und die komprimiertere bzw. zeitgemäßere Darstellung des Balkendiagramms. – PsY.cHo, 06:11, 2. Mai 2015 (CEST)

Das Minuszeichen kommt aus den Rechnungen, das extra zu ersetzen wäre wohl aufwendig.

Was verstehst du unter einer "komprimiertere bzw. zeitgemäßere Darstellung des Balkendiagramms"?

Eine Sitzverteilung hinzuzufügen, ist wohl möglich. Der Vorlagencode ist recht kompliziert (und keiner weiß wie sich die gelegentlichen Fehler beheben lassen), am leichtesten hätten es wohl die ursprünglichen Schreiber der Vorlage.

Die eigenen Tabellen sind nicht ganz redundant, sie sind bei der Verlinkung der Parteien teilweise gezielter. --mfb (Diskussion) 18:09, 3. Mai 2015 (CEST)

Die Vorlagen "Wahldiagramm" und "Sitzverteilung" sind m.E. weitgehend untauglich, weil sie bei vielen HW-Konfigurationen überlappende Texte erzeugen und man einen monströsen Untervorlagenbaum hat, nur um die Farben aller möglichen Parteien abzurufen. Von anderen Macken wie die oft nicht passende Größe mal abgesehen. Diese Vorlagen sollten nicht weiter forciert und erst recht nicht ausgebaut werden. Viel nützlicher wäre ein Tool zur Erstellung der Diagramme als SVGs. Konzentrieren wir uns auf die Erstellung von SVGs. ÅñŧóñŜûŝî (Ð) 18:28, 3. Mai 2015 (CEST)

An mfb: Ich persönlich empfinde das Balkendiagramm an sich von der Aufmachung her nicht zeitgemäß, kann es nicht genau erklären. Wie Antonsusi geschrieben hat, haben die Vorlagen Macken. Sofern die selbst erstellten Tabellen mit den beiden Vorlagen verglichen werden, wird klar, dass die Inhalte quasi nur wiederholt werden. Der Prozentanteil spiegelt sich nämlich im Balkendiagramm und die Anzahl der Sitze in der Sitzverteilung-Vorlage wider. Ansonsten findet sich kein nennenswerter Unterschied, sodass die extra Tabelle keine besondere Daseinsberechtigung meiner Meinung nach hat.
An Antonsusi: SVG-Diagramme sind auch eine Möglichkeit, ist mir bis dato nicht eingefallen ist. Meinst du hiermit die Erstellung von SVG-Grafiken oder die Erstellung mittels Vorlagen? Für jede beliebige Kommunalwahl eine extra SVG-Datei zu erstellen ist relativ aufwändig. Ich meine nicht, dass derzeit eine SVG-Vorlage für ein Balkendiagramm besteht, oder? Kennst du passende Vorlagen? Wie gesagt: Eine einzige Vorlage wäre klasse, die die Prozentanteile, Sitzanzahl und Wahlbeteiligung enthält, sodass die Darstellung auf sämtlichen Endgeräten optimal ohne Überlappungen erfolgt und der Leser nicht durch drei Elemente gleichzeitig regelrecht erschlagen wird. Bei der Vorlage Sitzverteilung besteht leider das Problem, dass die Zahlen auf dem Smartphone nicht oder nur teilweise dargestellt werden. – PsY.cHo, 07:25, 4. Mai 2015 (CEST)

• Die zusätzliche Tabelle ist schon sinnvoll, da man dort:
  • auch nach Parteinamen alphabetisch sortieren kann
  • alle Spalten dynamisch beliebig umsortieren kann
  • auch Parteien aufgelistet werden können, die dieses Mal keine Sitze erhalten hatten
  • auch zahlenmäßig minimale jedoch politisch interessante Ergebnisse sowie die Sonstigen gut dargestellt werden können.
• Was an der momentanen Methodik Mist ist, das ist die Praxis, die Prozentzahlen für die Ergebnisse doppelt anzugeben, einmal im Diagramm und dieselbe Zahl noch einmal in der Tabelle, und dann für dieselbe Partei die Anzahl der Sitze für das Diagramm und dann dieselbe Anzahl der Sitze für die Tabelle.
  • Das hatte ich erst kürzlich knapp drüber unter #Sind die Anzahl Vorlagen pro Artikel begrenzt? schon angemerkt.
  • Jeder Zahlenwert sollte nur einmal angegeben werden müssen, und bei Bedarf doppelt in Diagramm und Tabelle ausgewertet werden; dafür bedürfte es einer alle drei Elemente umfassender Mega-Vorlage (Lua).
• Mit externen Grafiken zu arbeiten ist Käse, weil das die Wartung und Korrektur erschwert und man sich bei jeder neuen Wahl bei einem Grafiker anstellen muss, damit er ein frisches Bildchen hochlädt.
• Es ist im Prinzip möglich, aus dem Wikitext heraus inline-SVG-Grafiken zu erzeugen.
  • Das braucht halbwegs moderne Browser, die SVG innerhalb eines HTML-Dokuments darstellen können.
  • Es gibt eine veraltete Programmierung dafür auf MediaWiki, die nicht für die Wikis zugelassen wurde, weil die sicherheitsgefährdenden Möglichkeiten nicht ausgefiltert werden.
• Die momentane CSS-basierte Erzeugung der Grafiken ist eine Notlösung, aber Murks.

VG --PerfektesChaos 01:24, 5. Mai 2015 (CEST)

Nichts ist hier Käse außer den bisherigen Vorlagen. Das Argument mit "bei jeder Wahl neu" zieht hier auch nicht als Gegenargument, im Gegenteil: Gerade deshalb ist eine SVG besser, denn so können alte Ergebnisdiagramme einfach aufgehoben werden. Und was es die Erstellung angeht, gibt es eine halbautomatische Möglichkeit: Es wäre kein Problem, eine SVG zu erstellen, indem man mittels Spezial:Vorlagen expandieren eine Vorlage "aufruft", welche mittels Lua-Modul den Quelltext der SVG erzeugt und ausgibt. Den muss man dann nur noch in eine Datei kopieren und hochladen. Ich habe das offline schon gemacht (mit Lua eine SVG erstellen) und mit dieser Spezialseite funktioniert das auch. Einziger wesentlicher Unterschied: Man muss per C&P offline speichern und kann nicht direkt in eine Datei schreiben. ÅñŧóñŜûŝî (Ð) 18:45, 5. Mai 2015 (CEST)

Ein externes Tool mit JS könnte auch eine Datei daraus machen. Sind natürlich mehr Schritte, aber SVG wird wohl schöner als das aktuelle CSS-Gebastel. --mfb (Diskussion) 18:53, 5. Mai 2015 (CEST)

Sierra Leone Parlamentssitze

APC: 70 Sitze

SLPP: 42 Sitze

Chiefs: 12 Sitze

Bei Verteilung der Sitze finde ich das https://tools.wmflabs.org/parliamentdiagram/parliamentinputform.html sehr praktisch. Und in Zukunft: Wikipedia:Fragen_zur_Wikipedia#Graphen, mw:Extension:Graph/Demo. --Atlasowa (Diskussion) 14:46, 13. Mai 2015 (CEST)

Das ist ein schönes Tool. Damit kann man doch schon was machen. ÅñŧóñŜûŝî (Ð) 17:14, 2. Jun. 2015 (CEST)

Umrechnungen von Koordinaten durchführen

Koordinatentransformationen werden momentan von einem externen Tool (http://alexrk4.appspot.com/geolink) vorgenommen. Die Konfiguration steht auf Vorlage:GeoTemplate/GeolinkConfig. Da das Java-Servlet seit geraumer Zeit down ist, habe ich den Toolbetreiber Benutzer:Alexrk2 gefragt, ob man das auch auf Tool Labs laufen lassen könnte. Er hat nichts dagegen, würde auch den Code bereitstellen, sich aber nicht selbst drum kümmern ([2]).
Daher meine Frage an die technikaffinen Kollegen hier: Würde sich jemand dessen annehmen? Oder kann die Funktionalität sogar ohne Toolserver bereitgestellt werden? (ParserFunctions? Lua?) --тнояsтеn ⇔ 14:39, 7. Mai 2015 (CEST)

Ich weiß nicht, was unter einer „Koordinatentransformation“ alles zu verstehen sein soll; aber sphärische Geometrie und Umrechnungen von Dezimal- in Sexagesimalsystem gehen mit Lua.

Müsste man mir aufschreiben, von was für einem Format genau in welches andere was alles transformiert werden soll.

Dann würde ich recht kurzfristig Modul:Expr um entsprechende Funktionen erweitern.

LG --PerfektesChaos 14:50, 7. Mai 2015 (CEST)

Die Transformationen sind tw. recht kompliziert und es gibt zudem viele verschiedene davon. Daher verwende ich der Einfachheit halber die Proj4-Bibliothek (die gibt's mW. in verschiedenen Programmiersprachen). Wenn man's schafft, diese Lib in irgendeiner Form auf Labs zum Laufen zu bringen, ist denke ich das Gröbste schon geschafft. --alexrk (Diskussion) 18:27, 7. Mai 2015 (CEST)

Auf der anderen Seite könnte man mit einem Lua-Modul Werte direkt "im Artikeltext" umrechnen. ÅñŧóñŜûŝî (Ð) 19:54, 28. Mai 2015 (CEST)

Vorlage für Verweis auf Biographielexikon

Hallo, in würde mich ungerne in die Vorlagenprogrammierung einarbeiten aber ich hätte gerne eine Vorlage nach Vorbild von {{ADB}}.

Unter wikisource finden sich die 4 Bücher des Biographisches Lexikon aller Helden und Militairpersonen. Viele der Personen dort sind bereits in der wikipedia beschrieben. Es liegt auf der Hand auf die zugehörtige Seite in Wikisource zu verweisen (statt auf google, wie im Moment).. Interessant wird die Sache das in Band 4, Ergänzungen und Korrekturen angegeben sind, es sollte in der Vorlage daher auch möglich sein, darauf zu verweisen.

Ansehen sollte es etwas wie im Artikel Henning Otto von Dewitz (Siehe Literatur:könig) Wer das macht hat ansonsten freie Hand

Wikisource: s:Index:Band1-Biographisches_Lexikon_aller_Helden_und_Militairpersonen.pdf -- A1000 (Diskussion) 18:10, 8. Mai 2015 (CEST)

Bei Wikisource sehe ich derzeit nur eine Seite, und Henning Otto von Dewitz verlinkt nicht darauf. Ist kein Problem das umzusetzen, wenn es Ziele in Wikisource gibt und mit Beispielen, wie auf Ergänzungen und Korrekturen verwiesen wird. Rund 600 Seiten verweisen auf "Biographisches Lexikon aller Helden und Militairpersonen". --mfb (Diskussion) 11:04, 9. Mai 2015 (CEST)

• Jep es war ein Beispiel wie es bisher aussieht, die 600+ Seiten verweisen alle auf books.Google, nun stehen die Buecher auch in wikisource und es waere halt praktisch, eine vorlage zu haben, so das man die 600+ verweise recht simpel mittels s&r vereinheitlichen kann. Dazu reicht es auf das PDF (bzw. die entsprechende Seite im PDF) zu verweisen. -- A1000 (Diskussion) 12:04, 9. Mai 2015 (CEST)

ADB. Vorlage:Lexikon Helden und Militairpersonen? Wäre eindeutig, aber relativ lang. Vorlage:Biographisches Lexikon König? Das Ersetzen ließe sich wohl sogar durch einen Bot erledigen, aber ich sehe derzeit den Mehrwert nicht (Wikisource bindet ja nur die Inhalte von Google Books ein). --mfb (Diskussion) 12:35, 9. Mai 2015 (CEST)

Wie steht es mit BL-Koenig fuer Biographisches Lexikon König (mit oe dann koennen es auch andere Tastaturen schreiben)?

Der Mehrwert liegt im Speicherort, Wikisource hat diese Dateien, die werden genau so auch weiter zugaenglich bleiben. Der zweite Punkt ist natuerlich die Vereinheitlichung der Verweise, statt wie bisher mehr oder weniger frei zu verlinken hat man eine einheitliche Vorlage und wie du schon gezaehlt hat bei 600+ ist das schon was. -- A1000 (Diskussion) 15:32, 10. Mai 2015 (CEST)

Fast vergessen, wenn du auch gleich den Bot machen moechtest bis du herzlich eingeladen ....

Kein oe, das wäre völlig unüblich. Für Umlaute gibt es ggf. die Sonderzeichenleiste. Vorlage:BL-König ist als Entwurf angelegt. Offene Fragen:

1. Soll "Band" als I, II, III, IV eingegeben werden oder als 1, 2, 3, 4? Ist ziemlich egal, aber es sollte einheitlich sein.

Ich mag roemische Zeichen, aber ich habe auch gelernt, das viele juengere sie nicht mehr richtig lesen koennen --> freie Wahl

1. Der Seitenlink braucht eine einzige Nummer als Seitenangabe. Ist das "f." bei der Seitenangabe nötig? Es sind soweit ich sehe maximal 1-2 Seiten. Falls ja, sind andere Formate als "234" und "234 f." vorstellbar bzw. soll mehr unterstützt werden?

Es gibt auch lange Artikel, Jetzt ist in der Regel nur die Startseite abgegeben

1. Bei Henning Otto von Dewitz wird König als Herausgeber bezeichnet, bei Wikisource als Autor. Was stimmt?

Es wird keiner protestieren wenn er in Zukunft immer Autor ist.

Ich habe keinen Bot, könnte aber den Boteinsatz beantragen. --mfb (Diskussion) 17:16, 10. Mai 2015 (CEST)

ich denke wir sollten das hier erst zu Ende bringen, aber ich habe sonst keine Bedenken -- A1000 (Diskussion) 18:36, 10. Mai 2015 (CEST)

Wie sind Hinweise auf Ergänzungen geplant ? -- A1000 (Diskussion) 18:39, 10. Mai 2015 (CEST)

Ich habe es jetzt mit 1-4 umgesetzt weil das praktischer ist (Wikisource-Link nutzt auch die arabischen Ziffern). Kein "f." vorgesehen, kann aber nachgerüstet werden. König ist nun Autor. Beispiel. Bitte in ein paar Artikeln ersetzen und schauen ob alles wie gewünscht klappt. Wenn ja, geschieht der Rest dann per Botauftrag. --mfb (Diskussion) 19:00, 10. Mai 2015 (CEST)

Fühlt sich schon mal gut, Band/Seite sollte klappen, nur eines: kann man den link auf das PDF [3] machen ? Da die OCR Seiten noch nicht da sind, ist es weniger verwirrend als eine z.Z. leere Seite -- A1000 (Diskussion) 17:45, 11. Mai 2015 (CEST)

Kein Problem, geändert. --mfb (Diskussion) 22:01, 11. Mai 2015 (CEST)

Fast Gut :), Er link kommt nur auf der falschen Seite des PDF's raus, da die Einleitung als Offset fehlt, man kann den Offset hier sehen [4] -- A1000 (Diskussion) 15:10, 12. Mai 2015 (CEST)

Tja, das ist aber schon ein Problem bei Wikisource. Siehe den Link 357 in Band 1, womit man bei 359 landet. Vielleicht fehlen zwischendurch Seiten. Vielleicht kann Joergens.mi mehr dazu sagen. Ich habe erstmal Offsets so eingebaut, dass die jeweils erste Seite funktioniert. --mfb (Diskussion) 20:28, 12. Mai 2015 (CEST)

Ich habe mal gesucht und 334/335 fehlen, aergerlich, mal sehen was sich machen laesst -- A1000 (Diskussion) 10:40, 14. Mai 2015 (CEST)

3+4 sind wohl Ok, aber bei 2 fehlen 358/359/360 dafuer gibt es 460 doppelt, für 334/335 habe bereits ersatz gefunden :) -- A1000 (Diskussion) 11:15, 14. Mai 2015 (CEST)

Was meinst du mit Ersatz gefunden? Wenn die Fehlstellen und Duplikate bekannt sind, kann die Vorlage das berücksichtigen. Noch einfacher wäre es natürlich, wenn die Wikisource-Nummerierung immer zur Seitenzahl passt (mit konstantem Unterschied zwischen beiden). --mfb (Diskussion) 12:48, 14. Mai 2015 (CEST)

Ich meine: für Teil 1 habe ich einen anderen Scan gefunden wo die fehlenden Seiten vorhanden sind, für Teil 2 ist es komplizierter da dort die Nummerierung nicht stimmt -- A1000 (Diskussion) 13:10, 14. Mai 2015 (CEST)

Ich kenne mich bei Wikisource nicht aus, kannst du die Scans an der richtigen Stelle einbinden sodass die Nummern fortlaufend sind?

Linkschema bei Band 2 ist dann: Seite 1 bis 357: (Seite+11), Seite 361-Ende: (Seite+9), 460: 369 (459 fehlt auch?) --mfb (Diskussion) 13:47, 14. Mai 2015 (CEST)

Da bin ich wieder, der Band 1 sollte ersetzt sein, ich hoffe ich habe es nicht schlimmer gemacht.

Band 2, sind die Seitenzahlen vermurkst, der Text ist aber ok, (pdf/angegebene Seite),

368/357 - 369/460 - 370/361 Ich bin etwas ratlos wie man das in den Griff bekommt, glücklicher weise endet das Buch bei 458, so das 460 nicht doppelt sein kann. Eine Idee waere die Zweiteilung und 460 als Spezialfall auf 369 mappen -- A1000 (Diskussion) 18:44, 19. Mai 2015 (CEST)

Ich hab die Übersicht bei Wikisource für Band 1 repariert. Sieht jetzt korrekt aus. Für Band 2 habe ich die 3 Fälle (1-357, 361-459, 460, sonst) als getrennte Fälle definiert (Diff). "sonst" zielt auf irgendwas, den Link in dem Fall zu Google umzubiegen wäre möglich, aber dort auf die Vorlage zu verzichten ist wohl einfacher (betrifft ja höchstens ein paar wenige Artikel).

• Anton Balthasar König: WikiProjekt Vorlagen/Werkstatt. In: Biographisches Lexikon aller Helden und Militairpersonen, welche sich in Preußischen Diensten berühmt gemacht haben. Band 2. Arnold Wever, Berlin 1789, S. 200 (WikiProjekt Vorlagen/Werkstatt bei Wikisource [PDF]). 
• Anton Balthasar König: WikiProjekt Vorlagen/Werkstatt. In: Biographisches Lexikon aller Helden und Militairpersonen, welche sich in Preußischen Diensten berühmt gemacht haben. Band 2. Arnold Wever, Berlin 1789, S. 380 (WikiProjekt Vorlagen/Werkstatt bei Wikisource [PDF]). 
• Anton Balthasar König: WikiProjekt Vorlagen/Werkstatt. In: Biographisches Lexikon aller Helden und Militairpersonen, welche sich in Preußischen Diensten berühmt gemacht haben. Band 2. Arnold Wever, Berlin 1789, S. 460 (WikiProjekt Vorlagen/Werkstatt bei Wikisource [PDF]). 
• Anton Balthasar König: WikiProjekt Vorlagen/Werkstatt. In: Biographisches Lexikon aller Helden und Militairpersonen, welche sich in Preußischen Diensten berühmt gemacht haben. Band 2. Arnold Wever, Berlin 1789, S. 1000 (WikiProjekt Vorlagen/Werkstatt bei Wikisource [PDF]). 

Funktioniert jetzt alles richtig? --mfb (Diskussion) 23:26, 19. Mai 2015 (CEST)

Sieht gut aus, ich habe zum Test aus jedem Band mal einen Eintrag umgewandelt, passt alles, jetzt koennen wir uns einem Bot widmen der die restlichen Referenzen umbaut, ich werde noch mal Dinge wie Erscheinungsjahr etc checken die wird man aber auch nach Einsatz des Bots korrigieren koennen -- A1000 (Diskussion) 18:21, 21. Mai 2015 (CEST)

BTW, man sollte das Problem mit den falschen Seitennummer in der Doku bemerken, es wird so schnell keine darauf verlinken, aber Murphy sieht was kommen. ich werde etwas schreiben eventuell kannst du etwas ergaenzen -- A1000 (Diskussion)

Wieso schreibst du "der Text ist vollständig"? Wo sind 358 bis 360? --mfb (Diskussion) 23:00, 21. Mai 2015 (CEST)

ok, offensichtlich war die Beschreibung nicht hilfreich. Was ist sagen will ist das *keine* Seiten fehlen sondern der Setzer Sich beim Setzen der Seitenzahlen versehen hat. Man kann anhand des letzten Wortes erkennen, ich hatte wegen der Seiten bereits bei der Bibliothek nachgefragt, dort hat man mir aber selbiges erklaert. -- A1000 (Diskussion) 16:34, 22. Mai 2015 (CEST)

Ach so, das Buch hat schon keine 358. Gut, dann dürfte alles vorbereitet sein, Botauftrag kann ich schreiben wenn ich Zeit dafür finde. --mfb (Diskussion) 16:42, 22. Mai 2015 (CEST)

Wenn dir etwas einfällt, die Dokumentation bitte entsprechend konkretisieren, ich wuesste es jetzt nicht besser zu beschrieben -- A1000 (Diskussion) 19:17, 22. Mai 2015 (CEST)

Botanfrage ist gestellt. --mfb (Diskussion) 20:35, 24. Mai 2015 (CEST)

Geht wohl auf der Bot-Anfrageseite weiter. Hier also erledigt. ÅñŧóñŜûŝî (Ð) 23:43, 30. Jun. 2015 (CEST)

Dieser Abschnitt kann archiviert werden. ÅñŧóñŜûŝî (Ð) 23:43, 30. Jun. 2015 (CEST)

Vorlage:Infobox Frankfurter U-Bahnhof

Könnte jemand diese Vorlage auf die allgemeine Vorlage:Infobox U-Bahnhof umstellen (die Artikel-Einbindungen kann man ja bis auf weiteres so lassen)? Soweit ich das sehe, ist diese Vorlage die einzige Extrawurst, alle anderen U-Bahnhöfe werden bereits durch die allgemeine Vorlage abgedeckt. 85.212.45.88 00:32, 15. Mai 2015 (CEST)

Was soll denn umgestellt werden, wenn die Artikeleinbindungen beibehalten werden? Das Layout? Die Parameter lassen sich nicht anpassen ohne an die Artikel zu gehen. Wenn die Vorlage wegfallen soll, müsste man sogar nur die Artikel ändern. --mfb (Diskussion) 00:59, 15. Mai 2015 (CEST)

So wie z. B. bei Vorlage:Infobox Frankfurter Stadtteil die allgemeinere Vorlage:Infobox Ortsgliederung als Zwischenebene verwenden und perspektivisch dann die Einbindungen in den Artikeln einfach substen. 129.13.72.197 11:50, 15. Mai 2015 (CEST)

Damit würden Daten verloren gehen, beispielsweise der Architekt oder die verschiedenen Ebenen. --mfb (Diskussion) 15:18, 15. Mai 2015 (CEST)

Da gibt es zwei Möglichkeiten: Entweder man ergänzt diese Parameter in der allgemeinen Vorlage, oder man lässt diese Informationen in der Infobox einfach weg. Stichwort Einheitlichkeit und so. 129.13.72.197 15:34, 15. Mai 2015 (CEST)

Was sagt denn das Portal:Frankfurt Rhein-Main dazu? --mfb (Diskussion) 15:43, 15. Mai 2015 (CEST)

Hab dort nachgefragt, aber vermutlich kommt eh keine Antwort. 85.212.17.168 17:59, 15. Mai 2015 (CEST)

Zwischenzeitlich kam dort eine Antwort. Also Weglassen der Infos ist keine Option. Kann jemand die allgemeine Vorlage so modifizieren, dass sie kompatibel wird zur Frankfurter Vorlage? 85.212.22.136 19:18, 26. Mai 2015 (CEST)

Ich sehe den Nutzen nicht. Solange andere Städte das System nicht übernehmen wollen wäre es Mehraufwand, ohne dass sich etwas verbessern würde. --mfb (Diskussion) 19:23, 26. Mai 2015 (CEST)

Wieso denn? Wenn die neuen Parameter als if-Parameter eingebaut werden, ändert sich an anderen Artikeln überhaupt nichts, und die Frankfurter Artikel werden in den Wartungsbereich der allgemeinen Box verlegt, anstatt separat berücksichtigt werden zu müssen. 85.212.22.136 19:25, 26. Mai 2015 (CEST)

Wenn es nur um Wartungslinks geht, lässt sich das einfacher lösen. Wo wäre der Vorteil einer solchen Anpassung? --mfb (Diskussion) 19:41, 26. Mai 2015 (CEST)

Perspektivisch gesehen lässt sich Wikidata einfacher einbinden. Und im Allgemeinen ist es immer einfacher, nur eine Vorlage zu haben, also zig verschiedene für den gleichen Objekttyp. 85.212.17.69 20:43, 26. Mai 2015 (CEST)

Ich fange mal wieder links an. Ob oder wie Wikidata eingebunden werden kann/soll, wird das Meinungsbild (hoffentlich) demnächst zeigen. Falls das in größerem Umfang in der Infobox geschieht, kann man immer noch darüber nachdenken, die zusammenzulegen. Aber wahrscheinlich ist das mehr Aufwand. --mfb (Diskussion) 20:56, 26. Mai 2015 (CEST)

Dieser Abschnitt kann archiviert werden. mfb (Diskussion) 00:01, 1. Jul. 2015 (CEST): derzeit nichts zu tun

Folgenleisten und deren Ableger

Ich möchte hier gerne ein Thema ansprechen, bei dem zurzeit wohl recht viel Wildwuchs zu finden ist. Es geht dabei um die ehem. Vorlage Folgenleiste (jetzt: Vorlage:Personenleiste) und davon abgeleitete Vorlagen und deren Gebrauch für alle möglichen Artikelreihen. Es gibt Verwendungen für Fernsehserien (die ursprüngliche Verwendung, daher der Name), für die Inhaber eines Amtes (Vorlage:Personenleiste) für zeitlich aufeinanderfolgende Ereignisse eines bestimmten Typs (Beispiel: Vorlage:Zeitleiste Sonnenfinsternisse) und für räumliche Reihenfolgen (Beispiel: Vorlage:Folgenleiste Flussquerungen der Themse). Ich halte es für sinnvoll, hier Regeln einzuführen. Dazu zähle ich (allgemein nenne ich diese Vorlagen mal "Linkleiste", "XY" steht für eine beliebige Zeichenkette):

1. Regeln über die Zulässigkeit:
   1. Es gilt WP:TR. Eine Linkleiste darf nur angelelegt werden, wenn sie - wie Navileisten - eine eindeutig begrenzte und definierbare Menge an Artikeln umfasst.
   2. Eine Linkleiste darf nur angelelegt werden, wenn eine entsprechende Navileiste nicht sinnvoll ist, z.B. wegen der Vielzahl der Artikel.
   3. Es muss eine Ordnungsrelation, also eine zeitlich oder räumlich eindeutige Reihenfolge, existieren.
2. Eine bessere Nomenklatur. "Folgenleiste XY" ist, die ursprüngliche Verwendung ausgenommen, nicht mehr zeitgemäß. Mein Vorschlag dazu:
   1. Konsequente Verwendung der Vorlage:Personenleiste für alle zeitlich sortierbare Personengruppen, also "Ämter", Titel etc. Ggf. als Aufruf aus einer anderen Vorlage heraus, welche Besonderheiten berücksichtigt.
   2. Andere Artikelmengen mit zeitlicher Sortierung sollten entweder auf eine zentrale, noch zu erstellende Vorlage:Zeitleiste oder auf eine Variation davon mit der Bezeichnung "Zeitleiste XY" zugreifen.
   3. Andere Artikelmengen mit räumlicher Sortierung sollten "Linkleiste XY" lauten.
3. Der Aufbau der Linkleisten sollten möglichst einheitlich sein. Dazu sollten wir klären, ob
   1. Die Artikel, welche eine derartige Leiste erfasst, nicht besser im Vorlagen-NR abgelegt werden, statt wie bisher in jedem Artikel den Vorgänger und Nachfolger einzutragen.
   2. Icons die Regel oder die ausnahme sein sollen.
   3. Alles, was hier sonst noch zum Thema auf den Tisch kommt...

Mit Gruß ÅñŧóñŜûŝî (Ð) 12:55, 15. Mai 2015 (CEST)

61 Folgenleistungen haben wir laut Kategorie. 1+2 klingen schonmal gut. Vorlage:Folgenleiste Flussquerungen der Themse ist in der aktuellen Form Unsinn. Das einzige Themse-spezifische in der Vorlage ist die einmalige Nennung des Flussnamens. Bei nahezu 100 Einbindungen sollten Änderungen ggf. von einem Bot gemacht werden. Ich sehe spontan aber keine elegante Lösung, Vorgänger/Nachfolger als eine einzige Liste im Vorlagenraum zu halten und auszuwerten. --mfb (Diskussion) 15:52, 15. Mai 2015 (CEST)

Was es den Aspekt der zentralen Verwaltung angeht: Es gäbe die Möglichkeit, eine im VNR abgelegte Liste mittels Lua-Modul zu verarbeiten und das Modul die zwei Linkziele zurückgeben zu lassen. Die Pflege der Liste und die Gestalt der Leiste wäre dann Wikisyntax, die Linkzielermittlung wäre Lua. ÅñŧóñŜûŝî (Ð) 16:55, 15. Mai 2015 (CEST)

Ginge mit Lua, ja. Wobei man dann noch Artikelname und Anzeigename trennen sollte. --mfb (Diskussion) 17:34, 15. Mai 2015 (CEST)

Na klar. Übergeben muss man ja die Liste, welche beides als Paar enthalten kann. ÅñŧóñŜûŝî (Ð) 17:45, 15. Mai 2015 (CEST)

Nachdem ich das Thema Radsportteam erledigt habe, kann es hier weitergehen. Ich überlege mir mal ein Format für die Datenseite (eigentlich eine Tabelle):

Für Personenleisten

• Kopfdaten:
  • Titel (Amt o.Ä.)
  • Untertitel
• Attribute:
  • Position in der Folge: Zeilennummer (Primärschlüssel)
  • Linkziel
  • Linktext (auch, wenn identisch)
  • Anfangsjahr - Endjahr
  • Geschlecht

Für sonstige Zeitleisten

Es sollte Platz für Icons sein (siehe SoFi-Leiste).

• Kopfdaten:
  • Titel
  • Untertitel
• Attribute:
  • Position in der Folge: Zeilennummer (Primärschlüssel)
  • Linkziel
  • Linktext (auch, wenn identisch)
  • Zeitangabe
  • Eigenschaft 1 (Könnte z. B. bei der SoFi-Leiste den Typ der Finsternis enthalten)
  • Eigenschaft 2
  • Eigenschaft 3 (drei müssten reichen)

Fehlt was? ÅñŧóñŜûŝî (Ð) 20:38, 26. Mai 2015 (CEST)

Wenn es keine Widersprüche gibt, dann werde ich es nach meinen hier geäußerten Vorstellungen umsetzen. ÅñŧóñŜûŝî (Ð) 22:24, 30. Mai 2015 (CEST)

2. Parameter z.T. überflüssig in Commonscat?

Siehe hier. –Queryzo ?! 13:46, 20. Mai 2015 (CEST)

Dieser Abschnitt kann archiviert werden. mfb (Diskussion) 00:02, 1. Jul. 2015 (CEST): Knappe 100 000 (!) Einbindungen im Aussehen zu ändern war wohl zu abschreckend, eingeschlafen.

Ausrichtung der Überschrift in Navgationsleisten

Gibt es eine Richtlinie wie die Überschrift der Navigationsleisten ausgerichtet werden soll? Mittig ist klar, aber mit welchem Bezug? Im Artikel Zond sind die Überschriften der ersten beiden Leisten mittig zwischen dem linken Rand und dem „Ausklappen“ ausgerichtet, die untere dagegen steht mittig zwischen den beiden Rändern. Das sieht in dieser Kombination recht merkwürdig aus. --Hadibe (Diskussion) 12:00, 27. Mai 2015 (CEST)

Das liegt an den Bildern. Um es einheitlich zu machen, müsste man die Bildbreite bei der mittigen Ausrichtung ignorieren. Das hat soweit ich mich erinnern kann schonmal jemand versucht, aber ohne brauchbares Ergebnis. --mfb (Diskussion) 13:44, 27. Mai 2015 (CEST)

Das liegt im eingeklappten Zustand nicht an den Bildern. Hadibe beschreibt das schon richtig, das bei den beiden ersteren die auf {{Navigationsleiste}} zurückgreifen, die Mitte zwischen dem linken Element (Rand) und dem rechten Element (Ausklappen-Link) genutzt wird, während die dritte Navileiste die auf {{Erweiterte Navigationsleiste}} zurückgreift links ein unsichtbarer span-Block (mit einer zuvor falschen Größe) ist um die Breite des rechten Elementes zu kompensieren. --Mps、かみまみた^Disk. 14:12, 27. Mai 2015 (CEST)

Bei mir ist da ohnehin nichts klappbar, aber richtig zentriert sind die Überschriften weiterhin nicht. --mfb (Diskussion) 15:11, 27. Mai 2015 (CEST)

Die Zentrierung hatte ich auch nicht angeglichen, sondern erstmal nur die irrige Annahme korrigiert der Text "Ausklappen" sei 5em breit. Die Frage des Themenerstellers ist ja gerade, was als Zentrierung bevorzugt wird: a) zwischen beiden Rändern und zu versuchen den Linktext rechts zu kompensieren oder b) zwischen etwaigem Bild links und Linktext rechts zu zentrieren. In beiden Fällen funken im ausgeklappten Zustand die Bilder dazwischen, da man deren Breite nicht kennt und man es bei a) somit nicht kompensieren kann und bei b) einem egal ist. Erst wenn geklärt ist ob man a) oder b) bevorzugt kann man das Verhalten beider Leisten aneinander anpassen. --Mps、かみまみた^Disk. 18:10, 27. Mai 2015 (CEST)

Das Bild zu ignorieren dürfte die sinnvollste Lösung sein, nur so lässt sich bei mehreren Navileisten eine einheitliche Position erreichen, außerdem springt die Überschrift dann nicht beim Klappen. --mfb (Diskussion) 21:50, 27. Mai 2015 (CEST)

In der englischen Wikipedia gibt es das en:Module:Navbox; dort bleibt mit local function renderNavBar(titleCell) der Titel mittig erhalten, selbst wenn sich die Textlänge des Ein-/Ausklappen-Links ändert, was sie sowohl im deutschen als auch im englischen tut. Deshalb springt der Titel auch ohne das Bild. Könnte man das nicht in die deutsche Navigationsleiste einbauen und analog dazu dies auch auf ein eventuell vorhandenes Bild übertragen? --Hadibe (Diskussion) 12:13, 29. Mai 2015 (CEST)

Hilfe bei Tabellensyntax in Infoboxen

Hallo,
ich bin gerade dabei die Vorlage:Infobox Studentenverbindung im Punkt "Farben" umzugestalten.
Was soll sich ändern? Momentan erlaubt das Feld eine simple Texteingabe im Sinne von "rot-weiß-rot" oder der Einbindung einer commons-Bilddatei. Da dies aber zu einem sehr heterogenen Aussehen der Infoboxen bei den verschiedenen Verbindungen geführt hat, würde ich das Feld "Farben" gerne vereinheitlichen. Eine seit neuem beliebte Art die Farben darzustellen, ist in der Liste der Studentenverbindungen in Regensburg ersichtlich.
Was habe ich vor? Ich möchte genau diese Art der Darstellung in die Box übertragen und bei der Parametereingabe die Möglichkeit geben die Farben in der gewünschten Reihenfolge einzutragen. Wie bei Infoboxen üblich, kann ich ja mit einer "if-Abfrage" überprüfen, ob ein Feld benötigt wird und dieses bei fehlender Eingabe einfach ausblenden.
Wo liegt genau das Problem? Ein großer Teil, aber nicht alle Bänder von Studentenverbindungen bestehen aus 3 Farben und einem Vorstoß/Percussion. Es gibt auch zweifarbige, und vierfarbige. Ebenso auch dreifarbige mit vier Balken oder sogar fünftfarbige Bänder. Ich will deshalb für jede Möglichkeit ein eigenes Feld einführen, welche ohne Eingabe standardmäßig alle ausgeblendet werden können. Sobald die Farben bei einem der Felder eingetragen werden, erscheint dieses Feld samt zugehörigen Farben in der Infobox.
Ich habe soweit schon eine Testumgebung aufgebaut in meinem BNR. Der Quelltext der Infobox ist zu finden unter Benutzer:K4210/test farben quelle und die Infobox wird eingebunden auf Benutzer:K4210/test farben. Dort seht ihr auch die offensichtlichen Syntaxfehler.
Was will ich von euch? Ich hätte gerne eine Fehlerkorrektur der Syntax und eine Hilfe, dass die Darstellung, welche ich mir wünsche, auch wieder klappt. Wenn es nicht funktioniert wegen der Verletzung irgendwelcher Programmierregeln, dann ist das halt so und ich muss mir was anderes überlegen. Vielen Dank schon mal für die Hilfe!
--K4210 (Diskussion) 16:08, 29. Mai 2015 (CEST)

Fehler gefunden und korrigiert, siehe meine Änderung. Ich würde die Parameter aber anders anlegen. Einfach Percussion1, Farbe1, Farbe2, Farbe3, Farbe4, Farbe5, Percussion2, die Vorlage prüft dann ob Farbe 5 gesetzt ist (wenn ja, 5 Farben), sonst, ob Farbe 4 gesetzt ist usw. Zum Fuxenband sehe ich kein Beispiel, daher keine Ahnung wie sich das integrieren lässt. --mfb (Diskussion) 16:40, 29. Mai 2015 (CEST)

Sehr cool, vielen Dank! Dass das schon mal funktioniert, ist ja topp. Ich glaube ich weiß, was Du meinst mit dem anders anlegen. Ich frage immer nur ein Feld ab und setze dann die entsprechende Farbentabelle. Das werde ich mal die Tage probieren. Das Fuxenband soll einfach genauso angelegt werden, aber das ist ja dann bloß eine einfache Übertragung, sobald die Syntax steht. Vielen Dank schon mal! LG --K4210 (Diskussion) 16:52, 29. Mai 2015 (CEST)

Wo liegt der Unterschied zwischen Fuxenband und anderem Band? --mfb (Diskussion) 16:54, 29. Mai 2015 (CEST)

Das normale Band ist das sogenannte Burschenband der Vollmitglieder einer Studentenverbindung. Probemitglieder, sogenannte Füxe (oder auch Füchse), tragen meist ein Fuxenband, welches sie als Probemitglieder kennzeichnet und meistens aus nur 2 der 3 Farben des Burschenbandes bestehen. Wie beispielsweise diese Gegenüberstellung hier zeigt: (links Burschenband, rechts Fuxenband)

--K4210 (Diskussion) 17:03, 29. Mai 2015 (CEST)

Ach so, also einfach eine zweite Farbgebung, die genau wie die erste funktioniert. Eine eigene Vorlage dafür wäre interessant - selbst wenn sie nur von Studentenverbindungen genutzt wird müsste man den Code dann nicht verdoppeln. --mfb (Diskussion) 17:47, 29. Mai 2015 (CEST)

Stimmt, da hast Du Recht. Man könnte es dann auch in die verschiedenen Listen (z.B. Liste der Mitgliedsverbindungen des CV und Liste der Studentenverbindungen in Regensburg) einarbeiten. --K4210 (Diskussion) 11:27, 1. Jun. 2015 (CEST)

Ich habe mir das mit deinem Vorschlag nochmal überlegt, dass die Vorlage prüfen soll, ob Farbe 5 belegt ist usw. Wie meinst Du das genau? Soll das eher ineinander verschachtelt sein, oder indem ich die einzelnen Zeilen bei Nicht-Zutreffen ausblende? Also ein "if farbe5 vorhanden, dann nimm Tabelle für 5 Farben, elseif Farbe4 vorhanden, dann nimm Tabelle für 4 Farben, elseif Farbe3 vorhanden, dann nimm Tabelle für 3 Farben, elseif Farbe2 vorhanden, dann nimm Tabelle für 2 Farben."? Weil wenn ich bloß Abfragen starte, dann habe ich ja bei 5 angegebenen Farben die Tabellen für 2, 3, 4 und 5 Farben gleichzeitig. Außer ich baue noch sowas ein wie "if farbe5 vorhanden, dann nimm Tabelle für 5 Farben und überspringe alle anderen." Wie hast Du das genau gemeint? Ich denke die geschachtelte Version wäre am Besten. Bekomme ich das mit der Wikisyntax hin? LG --K4210 (Diskussion) 14:52, 1. Jun. 2015 (CEST)

{{#if:{{{Bandbild|}}}
  |Bild einbinden
  |{{#if:{{{Farbe5|}}}
    |Tabelle für 5 Farben
    |{{#if:{{{Farbe4|}}}
      |Tabelle für 4 Farben
      |{{#if:{{{Farbe3|}}}
        |Tabelle für 3 Farben
        |Tabelle für 2 Farben
      }}
    }}
  }}
}}

Ausblenden klappt nicht, da die Höhen von der Zahl der Farben abhängen. Eine Untervorlage enthält dann alles von {{#if:{{{Farbe5|}}} bis zum zugehörigen }} . --mfb (Diskussion) 15:07, 1. Jun. 2015 (CEST)

Ich habe es jetzt mal unter Benutzer:K4210/test farben quelle eingebunden und die Infobox in Benutzer:K4210/test farben aufgerufen. Die Fuxenfarben zeigt er mir korrekt an, bei den anderen Farben zeigt er komischerweise nur 2 Farben und nicht wie angegeben und gefordert 4 Farben. Vielleicht findest Du ja den Fehler, ansonsten versuche ich nachher nochmal genauer hinzuschauen. LG --K4210 (Diskussion) 16:38, 1. Jun. 2015 (CEST)

Die Parameternamen hießen nicht richtig. --mfb (Diskussion) 17:45, 1. Jun. 2015 (CEST)

Super, hab ich wohl vor lauter Wald die Bäume nicht mehr gesehen. ^^ Einen kleinen Fehler hab ich wohl noch gefunden. Wenn ich (ein zweifarbiges Band eingebe und) keine Farbe für das Fuxenband eingebe, erscheint das Feld trotzdem im TEst und bleibt weiß. -.- --K4210 (Diskussion) 22:43, 1. Jun. 2015 (CEST)

War das gleiche Problem. --mfb (Diskussion) 23:07, 1. Jun. 2015 (CEST)

Vielen lieben Dank an mfb für das Erstellen und Einfügen der Farben-Vorlage. Ich bin bisher einfach noch nicht dazugekommen. Allerdings werde ich versuchen noch eine Sache einzuarbeiten, die ergänzend vom Portal:Studentenverbindung angebracht wurde. dazu würde ich diesen Teil noch gerne aktiv halten und hierzu auch Fragen stellen, falls nötig. LG --K4210 (Diskussion) 13:02, 8. Jun. 2015 (CEST)

Aus der Community gab es noch den Wunsch in die Farbentabelle die Breite zusätzlich einzubinden, da es unterschiedliche Zusammensetzungen gibt. Der Wunsch wäre eine optionale Eingabemöglichkeit, wie viel Pixel die Farbenbalken breit sein sollen und bei Nichteingabe (durch IF-Abfrage) einen Standardwert zu nehmen. Ist das möglich, oder wäre nur eine generelle Eingabe der Breiten möglich (also ohne IF-Abfrage der Felder)? Die aktuelle Version wäre hier, die neuen Parameter sind noch nicht eingebunden: Benutzer:K4210/test_farben_quelle/band --K4210 (Diskussion) 17:00, 22. Jun. 2015 (CEST)

Ist etwas gewöhnungsbedürftig, die Höhe Breite zu nennen. Umgesetzt. Allerdings habe ich die Parameternamen erst danach gesehen, kannst du ja umbiegen, wenn dir B-Farbe1Breite etc. nicht gefallen. --mfb (Diskussion) 20:18, 22. Jun. 2015 (CEST)

Wilhelm II. im Couleur des Corps Borussia Bonn

Vielen Dank mfb :) Ja wenn man die Farben nur als Block auf dem Rechner sieht, erscheint Höhe logisch. Ich habe es mir als Band um die Brust vorgestellt und ich denke die meisten anderen, die das Tool benutzen wollen, werden es sich ebenfalls als Band vorstellen, da spricht man ja eigentlich eher von Breite. Das mit den Parametern ist gar kein Problem, ich hab die alle eingetragen und die Tabelle auch schon in die Vorlage übertragen: Vorlage:Farben Studentenverbindung‎. Allerdings finde ich es irgendwie komisch, dass der schwarze Rand um die Farben willkürlich. Gut zu sehen in den Boxen rechts auf der Seite Benutzer:K4210/test farben. Weißt Du, wie ich sowas beseitige? :) LG --K4210 (Diskussion) 10:50, 26. Jun. 2015 (CEST)

Der Rand ist hier festgelegt: style="border: 0.5pt black solid" - einfach ändern in style="border: 0pt" und der Rand ist weg. Bitte das übliche Format für Vorlagen nutzen, also Vorlagencode zuerst, darunter dann Vorlage:Dokumentation einbinden und die Dokumentation auf die Unterseite setzen.

Ich würde es begrüßen, wenn du die Beiträge anderer (hier: meine) nicht als die eigenen ausgibst wie hier geschehen. Du hättest die Entwurfsseite verschieben können oder zumindest auf die Entstehungsgeschichte hinweisen können. --mfb (Diskussion) 21:49, 26. Jun. 2015 (CEST)

Hallo mfb, ich hatte da nicht drüber nachgedacht und möchte um Entschuldigung bitten. Ich habe nun dafür gesorgt, dass der Text aus meinem BNR inklusive Versionsgeschichte in der Vorlage ist. Vielen Dank für deine Hilfe, ohne Dich hätte ich noch ewig in der Syntax rumgedoktert. --K4210 (Diskussion) 16:36, 30. Jun. 2015 (CEST)

Ich würde ganz gerne den dünnen schwarzen Rand beibehalten und ihn ganz um die Farben gehen lassen. Ist das nur ein Anzeigeproblem bei mir, oder geht's er nicht bei allen Farben komplett rum in der Infobox? Wenn ich die Farbenvorlage außerhalb der Infobox aufrufe, zeigt es den Rahmen komplett an. --K4210 (Diskussion) 17:57, 1. Jul. 2015 (CEST)

Graph zur Wahl

Ich ärgere mich seit längerer Zeit darüber, dass für Wahlen dieselben Daten mehrfach in unseren Artikeln stehen, einmal für die Tabelle und nochmals für die Diagramme.

• Ich möchte, dass irgendwer (möglichst nicht ich) dies mittels der neuen Hilfe:Graph mittelfristig umbaut; zumindest für neuere Standard-Artikel.

Ich möchte aus denselben (einmaligen) Anwendungsdaten unterschiedliche Darstellungen generiert sehen:

1. Sortierbare Tabelle, mit errechneten ableitbaren Infos (Gewinne/Verluste)
2. Balkendiagramm für Prozente
3. Tortendiagramm für Sitze
4. Balkendiagramm für Gewinne/Verluste
5. Mehr …

Als Syntax stelle ich mir vor:

|1=[[Unionsparteien|Union]]
   Farbe=000
   Prozente=2005:35,2 2009:33,8 2013:41,5 \ Sitze=2009:239 2013:311
   Erststimmen=2009:13.856.674 \ Zweitstimmen=2009:11.828.277
   AnmSitze=CDU/CSU-Fraktion
|2=[[Sozialdemokratische Partei Deutschlands|SPD]]
   Farbe=#FF0000
|Name=Deutscher Bundestag
|Wahlen=1949 1953 ... 2005 2009 2013

Zur Syntax:

• Jeder (unbenannte) Vorlagenparameter beschreibt eine Partei.
• Jeder Partei-Vorlagenparameter ist in Unter-Felder aufgeteilt, was Lua kinderleicht splitten kann. Mit einem Zeilenumbruch oder Backslash werden die Unter-Felder voneinander getrennt. Backslash vor Zeilenumbruch (am Zeilenende, Leerzeichen ignorierend) markiert eine Fortsetzungszeile, die Fortsetzung desselben Feldes.
• Die Unterfelder haben interne „Parameternamen“ und können in beliebiger Reihenfolge angeordnet werden.
• Oben ist 1=Parteilink – könnte auch besser lauten:
  Artikel=Unionsparteien \ Name=Union \ Farbe=#000
• Farben können mit ohne # und drei oder sechs Hexen angegeben werden; Hauptsache keine Namen.

Dieselbe Dateneinbindungen aus einem externen „Artikel“ (lieber nicht im Vorlagen-NR) kann man in verschiedene Bundestagswahlen mehrfach im Artikel einbauen, für verschiedene Tabellen, Diagramme und Auswertungen nach Gewinnen und Verlusten. Die Daten stehen in einem onlyinclude, während der scheinbare Artikel dem Leser nur eine nummerierte Liste der einzelnen Wahl-Artikel anzeigt.

• Auch eine Darstellung aller Wahlergebnisse jeder Partei seit 1949 wäre möglich, wenn man eine enzyklopädische Datenseite zu allen Bundestagswahlen hätte. Alles aus denselben Basisdaten, an zentraler Stelle gepflegt und fortentwickelt.
• Schwierig sind Partei-Umbenennungen (PDS); da müsste noch über eine Syntax getüftelt werden; auch potentielle Zusammenschlüsse (G+B90) oder Aufspaltungen (Kreuth, FPÖ/BZÖ). Vielleicht Einführung von ID für Sonderfälle, die dann zu bestimmten Wahlen in unterschiedliche Partei-Namen und -Links aufgelöst werden können.
• Der zentrale Einbindungsartikel kann genauso mit Parametern aufgerufen werden, die die momentan gewünschten Ausgabeformen als Tabellen und/oder Diagramme spezifizieren, und welches Wahljahr. Deren Parameter werden einfach an die eigentliche Vorlage durchgereicht.
• Das alles natürlich auch auf alle Länder, Gemeinden und Kantone anwendbar.
• Altbestände mögen so bleiben oder automatisiert fehlerfrei konvertiert werden.

Viel Spaß --PerfektesChaos 12:43, 2. Jun. 2015 (CEST)

wenn man eine enzyklopädische Datenseite zu allen Bundestagswahlen hätte: Hat man doch, sogar zwei: Ergebnisse der Bundestagswahlen und Übersicht der Bundestagswahlergebnisse. 85.212.12.134 01:01, 3. Jun. 2015 (CEST)

Ja doch – aber die enthalten nicht die auswertbaren Daten. Umgekehrt wird ein Schuh draus: Wenn man eine Seite im ANR hat, auf der zu 98 % die auslesbaren Einzelwerte strukturiert angegeben sind, und pro forma nach außen 2 % sichtbarer Text gezeigt würden, dann lassen sich die von dir genannten Seiten ebenfalls aus dieser zentralen Datenstruktur befüllen. LG --PerfektesChaos 14:39, 4. Jun. 2015 (CEST)

Nummer-eins-Vorlage

Hallo! (@Darkking3, Mfb: zur Kenntnisnahme) Es geht um die Vorlage:Nummer-eins-Hits. Ich habe aktuell von einem Review ausgehend einigen Änderungsbedarf festgestellt, den ich zum Teil auch schon selbst abarbeiten konnte; bei ein paar Kleinigkeiten hakt’s aber noch. Ich hab unter Benutzer:XanonymusX/Arbeitsplatz#NR1 neu ein Beispiel erstellt, konkret geht es darum, die Wochenangabe, die bis jetzt in der ersten Spalte mitaufgeführt wird, fallweise in die zweite Spalte zu versetzen; die vier möglichen Fälle (allerdings jeweils nur mit Wochenangaben, mit Datumsangaben sollte es natürlich analog funktionieren) habe ich im Beispiel aufgeführt: Zwei funktionieren ordnungsgemäß, an den anderen beiden bin ich gescheitert. An der Berechnung, die den komplexesten Teil der Vorlage darstellt, braucht nichts mehr geändert zu werden, ich möchte es aber auch vermeiden, sie im Quelltext verdoppeln zu müssen (damit hätte ich alle Fälle bereits gelöst gehabt). Vielleicht fällt euch ja was ein, die Vorlage:Plural hat mich ausgebremst … Ansonsten auch noch was Einfacheres (wäre direkt in der Vorlage zu ändern, da bereits live): Die Sortierung der ersten Spalte klappt bei Datumsangaben (ISO-Format) noch nicht, was muss dafür umgebaut werden? Gruß, XanonymusX (Diskussion) 20:21, 8. Jun. 2015 (CEST)

Welche Fälle sind falsch, und wann genau soll was verschoben werden? Welche Berechnung soll nicht kopiert werden? Wie gesagt, Hellsehen ist schwierig. --mfb (Diskussion) 22:31, 8. Jun. 2015 (CEST)

Sicher, dass deine Kristallkugel richtig funktioniert? Ich fand das eigentlich leicht verständlich … Vorlage:Smiley/Wartung/:p  Ich wäre auch schon mal froh, wenn in der Live-Vorlage die Sortierbarkeit der ersten Spalte repariert werden könnte. Ansonsten: Die vier möglichen Fälle habe ich im Beispiel jeweils in der letzten Spalte benannt. Das Problem ist: Die Angabe der Wochen (sei es aus der Berechnung stammend, die den Kern der Vorlage bildet, oder durch den Wochen-Parameter manuell eingegeben) wird aufgrund der Vorlage:Plural, in die die Zahlenangabe zwangsläufig verpackt wird, immer als x Woche(n) ausgegeben. Das ist im ersten und im vierten Fall, wo sie klein unterhalb der Datumsangaben in der ersten Spalte steht, auch so gewollt. In den beiden mittleren Fällen (das Kriterium ist das Fehlen einer Angabe für den Parameter Insges) hingegen ist die Wochenanzahl gleichzeitig die Gesamtwochenanzahl und wird daher in die zweite Spalte gesetzt; hier ist das „Wochen“ nun aber fehl am Platz! Meine Versuche, dem beizukommen, scheiterten allesamt. Irgendwelche Ideen, wie man diese Plural-Vorlage umgehen kann? Gruß und Dank --XanonymusX (Diskussion) 08:20, 9. Jun. 2015 (CEST)

Du willst also einfach die Worte "Wochen" dort loswerden, alles andere (außer der Sortierung) funktioniert wie gewollt? Das war der Teil des Hellsehens, der mir gefehlt hat. Angesichts der Komplexität der Berechnungen und der mehrfachen Nutzung der gleichen Ergebnisse würde ich hier eine Untervorlage erstellen. Die "Hauptvorlage" berechnet Dinge wie (({{{Chartein}}})>1857) OR ((({{{Chartein}}})*100 mod 100)>0), ob ein Jahresübertrag nötig ist und so weiter, und die Untervorlage nutzt die Berechnungsergebnisse für die Darstellung und ihre Logik. --mfb (Diskussion) 15:54, 9. Jun. 2015 (CEST)

Ja, den Rest hat darkking in langer Arbeit perfektioniert. Meine Anpassungen waren im Grunde trivial. Okay, kann man gerne machen, auch wenn ich weiß, dass darkking das vermehrte Auslagern nicht immer so gern gesehen hat. Aber solange es funktioniert (und den Server nicht stärker belastet), gerne! Setzt freilich Eingriffe in die Berechnung selbst voraus, wozu mir ehrlich gesagt der Durchblick fehlt.--XanonymusX (Diskussion) 19:08, 9. Jun. 2015 (CEST)

Benutzer:darkking3 ist aktiv, vielleicht fällt dem eine bessere Lösung ein. --mfb (Diskussion) 21:04, 9. Jun. 2015 (CEST)

Fallweise der {{Plural}} ein zweites Pipe erzeugen, sodass der dritte Parameter (Mehrzahl) Leer ist, dann hängt die Vorlage nur noch ein geschütztes Leerzeichen an. --darkking3 ^Թ 09:56, 10. Jun. 2015 (CEST)

Hatte ich probiert, damit lässt sich die Zahl leider nicht zentrieren (Leerzeichen) – und bei 1 kommt dann ja doch der Singular!--XanonymusX (Diskussion) 10:15, 10. Jun. 2015 (CEST)

Außerdem wäre das Verhalten dann in beiden Fällen gleich, was ja nicht gewünscht ist. --mfb (Diskussion) 11:32, 10. Jun. 2015 (CEST)

„Fallweise“ wäre schön möglich, aber eben nicht mit dem nbsp! Alternativvorschläge? Die Sortierbarkeit des Datums wäre immer noch ein Thema.--XanonymusX (Diskussion) 11:24, 13. Jun. 2015 (CEST)

Siehe mein Entwurf, der jetzt das gleiche machen sollte wie deine Vorlage, aber (meiner Meinung nach) wesentlich übersichtlicher. Ich hatte zwischendurch den interessanten Fall, dass die Vorschau etwas korrekt angezeigt hat aber der Artikel danach nicht. Das kann man absichtlich herbeiführen, aber dass es auch sonst geschehen kann war mir neu.

Nach was soll sortiert werden? Chartein? --mfb (Diskussion) 13:35, 13. Jun. 2015 (CEST)

Danke! Ist die Wochenzahl jetzt absichtlich linksbündig oder ließe sich das noch anpassen? Ist aber zweitrangig, solang alle gleich sind. Ja, Sortierung macht wohl nur nach Chartein Sinn (wenn überhaupt, aber zumindest zum Rückführen in die Ausgangsreihenfolge nach einer anderen Sortierung). Leider bringt die Sortierung Layoutschwächen mit sich; wenn Zebra nicht machbar ist (wovon bei der mangelnden Änderungsbereitschaft an manchen Stellen auszugehen ist), müssen wohl oder übel wieder Zellbegrenzungen eingeführt werden.

Ja, liegt vielleicht am BNR, bei meinen letzten Änderungen musste ich danach oft mehrmals aktualisieren, Cache leeren oder sogar Browser neustarten, bis die Änderungen endlich Wirkung zeigten.--XanonymusX (Diskussion) 14:09, 13. Jun. 2015 (CEST)

?action=purge an die URL hängen sollte dazu führen, dass der Servercache geleert und alles neu gelesen wird. Ist linksbündig weil ich mich nicht um Ausrichtung gekümmert habe, ist natürlich leicht anpassbar. Kann man sich für die Ausgangsreihenfolge auf den Parameter 1 verlassen? Der wäre wesentlich leichter zum Sortieren zu verwenden als Chartein, was als Kalenderwoche oder als Datum eingegeben werden kann. Wieso geht Zebra nicht? Ich habe es nicht probiert. --mfb (Diskussion) 14:48, 13. Jun. 2015 (CEST)

Okay, an Parameter 1 hatte ich auch gedacht, ja, aber da ich noch Hoffnung habe, das Layout auf Zebra umzustellen (dazu muss aber zuerst wikitable eingeführt werden), würde der entfallen (erfüllt bislang ja nur den Zweck der abwechselnden Einfärbung).--XanonymusX (Diskussion) 14:53, 13. Jun. 2015 (CEST)

Ja, der Parameter gehört jetzt der Vergangenheit an! Das Layout ist mehr oder weniger umgestellt, ich müsste nur noch die Ränder der Zeilen wegkriegen und evtl. Farbe1 und Farbe2 tauschen; Zebra ist endlich brauchbar! Damit muss das Sortieren wohl oder übel über Chartein erfolgen.--XanonymusX (Diskussion) 03:18, 14. Jun. 2015 (CEST)

Hab mal versucht, data-sort-type einzubauen, aber zeigt keine Wirkung. Bei den Wochen stimmt auch was nicht. Sonst sollte die Vorlage jetzt stabil sein!--XanonymusX (Diskussion) 14:11, 14. Jun. 2015 (CEST)

Ich fürchte Wochen und Tage sind fundamental inkompatibel. Wie soll die 3. Woche ohne Jahresangabe mit dem 16. Januar 2012 verglichen werden? Man könnte alles in Wochen umrechnen und als Zahlen sortieren (damit 5 vor 10 kommt und nicht danach (5>1)). --mfb (Diskussion) 20:02, 18. Jun. 2015 (CEST)

Eigentlich sollte das kein Problem darstellen? Man berechne aus dem Datum die kalenderwoche und sortiere dann nach Wochen. Sortierung nach dem Schema JJJJ/WW garantiert die Sortierbarkeit. --darkking3 ^Թ 20:31, 18. Jun. 2015 (CEST)

YYYY ist oft nicht vorhanden. Und Woche (ggf. als "5" eingegeben) muss dann noch in WW umgewandelt werden. Ja, wie gesagt, man kann alles in Wochen umrechnen. --mfb (Diskussion) 21:01, 18. Jun. 2015 (CEST)

YYYY habe ich häufig aus dem Seitennamen extrahiert, da der schematische Aufbau der Listenartikel meist gleich ist. --darkking3 ^Թ 21:40, 18. Jun. 2015 (CEST)

Hallo @Mfb, Darkking3: bin wieder da! Wie sieht’s aus? Wenn ich das einwerfen darf: Kombination von Wochen und Datumsangaben ist nicht notwendig, pro Verwendung in einer Tabelle wird nur entweder das eine oder das andere verwendet werden. Und Zusatzfrage: Wie kommt es, dass selbst die zweite Spalte mit einfachen Zahlenangaben falsch sortiert wird (11 vor 7)?--XanonymusX (Diskussion) 02:46, 25. Jun. 2015 (CEST)

Sind überall ausschließlich Zahlen drin? Ist im Tabellenheader definiert worden, dass nach Zahlen sortiert werden soll? Alphabetisch kommt 11 vor 7 (1 vor 7), deswegen ist das nicht ganz so einfach. Ich bin derzeit froh wenn ich bei der Beobachtungsliste nicht total den Überblick verliere, für Entwicklungen hier habe ich erstmal keine Zeit. --mfb (Diskussion) 19:27, 25. Jun. 2015 (CEST)

@Mfb: Ja, hab das Format auch im Header definiert, obwohl es sich ja ausschließlich um Zahlen handelt. Seltsamerweise wird 33 richtig sortiert, 11 hingegen nicht.--XanonymusX (Diskussion) 23:45, 28. Jun. 2015 (CEST)

Da passt was im Kopf nicht: Klicke ich auf die Bezeichnung im Kopf, wird richtig sortiert, die Pfeile gehören irgendwie zur falschen Spalte... --darkking3 ^Թ 15:34, 29. Jun. 2015 (CEST)

Danke für den Hinweis. Ich versteh’s zwar nicht, aber Harro hatte schon gemeldet, dass bei ihm auch die letzte Spalte sortierbar sei. Ich werde nachforschen.--XanonymusX (Diskussion) 23:24, 29. Jun. 2015 (CEST)

Vorlage:Hall of Fame des deutschen Sports

Die Redaktion der HOFdS hat ihre Dateistruktur umgestellt. Die Vorlage kann daher derzeit nicht verwendet werden. Für Gedanken zur Lösung des Problems bitte ich darum, auf der Diskussionsseite der Vorlage reinzuschauen. [PS: @Boshomi:] MfG --Tommes ^✉ 13:24, 9. Jun. 2015 (CEST)

Vorlage:Fußballspiel

Wäre es niht sinnvoll, die Vorlage:Fußballspiel, die Vorlage:Fußball Gruppenspiel und die Vorlage:Fußballspiel national zu einer einzigen Vorlage zu vereinen? --Yoda1893 (Diskussion) 12:19, 14. Jun. 2015 (CEST)

Offenbar wurde darüber schon abgestimmt: Vorlage Diskussion:Fußballspiel national#Zentrale Vorlage für ein Fußballspiel (Vorlage:Fußballspiel)? - Aus einem Grund, der sich mir nicht erschließt, wurde es aber noch nicht umgesetzt. --Yoda1893 (Diskussion) 12:25, 14. Jun. 2015 (CEST)

Wäre sinnvoll! Kann das jemand machen? --Rogi (Diskussion) 12:36, 14. Jun. 2015 (CEST)

Die sehen sogar halbwegs kompatibel aus. 35, 1393 und 632 Einbindungen. Welches Layout wird bevorzugt? Nicht das erste, das sehe ich. "Fußball Gruppenspiel" sieht am umfangreichsten aus, dort sehe ich aber kein Elfmeterschießen - das ist sicher ein relevanter Teil, wo soll das eingebaut werden? Die Stadt des Schiedsrichters könnte man optional machen. Logo statt Flagge zeigen, wenn es ein nationales Fußballspiel ist? Der Platz für die Trikots bleibt bei vorhandenen Einbindungen ohnehin leer, da "Fußballspiel national" das nicht hat. --mfb (Diskussion) 14:41, 14. Jun. 2015 (CEST)

Ich finde die Gruppenspielvorlage am ordentlichsten, da man aus ihr auch das meiste rausholen kann. Logos statt Flagge bei Nicht-Länderspielen, okay, könnte man machen. Man könnte aber auch die Flaggen komplett weglassen und stattdessen die Verbandslogos einbinden bei Länderspielen. Man könnte eine spezielle Variable "Land" einbauen, dann könnte man die Vorlage auch für Clubwettbewerbe nutzen und darstellen, aus welchem Land der Verein kommt (manchmal ja gar nicht so uninteressant, wie bspw. beim Europa-League-Finale in diesem Jahr) usw. Die Aufstellung sollte auf jeden Fall optional werden, genauso wie von dir angmerkt die Herkunft des Schiris. Wegen dem Elfmeterschießen, der könnte optional unten über die Karten. --Wikijunkie ^{Disk. (+/-)} 23:54, 14. Jun. 2015 (CEST)

Verbandslogos statt Flaggen: Wenn du in 1400 Artikeln (mit weit mehr Einbindungen, da meistens Artikel die Vorlage mehrfach nutzen) die Parameter umstellen willst? Man kann viel, aber Pflichtparameter die nicht schon bislang in den zwei häufig genutzten Vorlagen Pflicht waren sind unpraktisch. Am einfachsten ist es, die Vorlage:Fußball Gruppenspiel etwas umzubauen, Vorlage:Fußballspiel national ruft dann Vorlage:Fußball Gruppenspiel auf und bleibt aus historischen Gründen erhalten (Botlauf um die Vorlage loszuwerden ist aber auch möglich). Vorlage:Fußballspiel wird am besten komplett ersetzt. --mfb (Diskussion) 00:49, 15. Jun. 2015 (CEST)

Also umleiten würde ich auf keinen Fall, wenn dann die anderen beiden ersetzen und entsorgen. Bezgl. der Logos... War am Ende nur ein Vorschlag meinerseits... Ich bin aber gerne Kompromissbereit... --Wikijunkie ^{Disk. (+/-)} 11:21, 15. Jun. 2015 (CEST)

Vorlage:ISMN

Wäre es wohl möglich, analog der Wikipedia:ISBN-Suche eine Vorlage für die International Standard Music Number anzulegen? Diese wäre hilfreich z.B. in biographischen Artikeln zu Komponisten oder bei Artikeln zu Musikstücken, um Ausgaben zu fnden. Die ISMN selbst ist schon vielfach verwendet. Darauf gestossen bei Daniel Magnus Gronau. --Concord (Diskussion) 15:39, 15. Jun. 2015 (CEST)

Dazu muss eine Spezialseite analog zu Spezial:ISBN-Suche erstellt werden. Ich weiß nicht, ob das so ohne Weiteres geht (WP:Technikwerkstatt). Workarounds, die ich sehe, funktionieren nicht so gut. --mfb (Diskussion) 16:04, 15. Jun. 2015 (CEST)

Muss es denn gleich eine Spezialsuche sein? Bei {{ISSN}} tuts doch auch eine einfache Vorlage. --FordPrefect42 (Diskussion) 20:46, 15. Jun. 2015 (CEST)

Ein solcher Link als Vorlage ist sehr einfach (vorausgesetzt es gibt eine geeignete Ziel-URL), aber gefragt wurde ja nach einem Äquivalent zur ISBN-Suche. --mfb (Diskussion) 21:12, 15. Jun. 2015 (CEST)

Gefragt wurde aber auch nach einer Vorlage, und die ISBN-Suche ist ja eben keine. – Ob es für die International Standard Music Number eine international übergreifende Suchadresse gibt, ist mir nicht bekannt. In erster Näherung wäre das DNB-Portal, über das das Deutsche Musikarchiv recherchierbar ist, wohl ein sinnvolles Linkziel. --FordPrefect42 (Diskussion) 12:52, 16. Jun. 2015 (CEST)

Wikipedia:ISBN-Suche ist technisch keine Vorlage, wird aber ähnlich wie eine verwendet. Aber statt hier weiter über die Interpretation zu spekulieren, können wir einfach warten bis Concord sich dazu äußert. --mfb (Diskussion) 15:00, 16. Jun. 2015 (CEST)

Sorry - was ich meine, ist eine Möglichkeit, anhand der ISMN eine Katalogabfrage zu starten. Wenn es eine einfache Vorlage tut, dann gern. Und ich glaube wie FordPrefect42, dass vermutlich der DNB-Katalog für uns ein sinnvolles Linkziel wäre. --Concord (Diskussion) 17:13, 16. Jun. 2015 (CEST)

Also etwas im Stil von {{ISMN|M-006-49713-3}} --> ISMN M-006-49713-3, Suche im DNB-Portal?

Huch, Signatur vergessen. @Concord: In dem Stil? Die Seite hat gerade Probleme aber im Allgemeinen funktioniert der Suchlink. --mfb (Diskussion) 17:09, 20. Jun. 2015 (CEST)

Ja, genau! (auch wenn es im moment bei der DNB wg. deren Problem nicht klappt). --Concord (Diskussion) 17:11, 20. Jun. 2015 (CEST)

Ist angelegt. Vielleicht ist ein Abgleich mit Wikidata möglich, das sehe ich wenn sie ein paar Verwendungen gefunden hat und der entsprechende Diskussionsabschnitt zu Wikidata hier Ergebnisse bringt. --mfb (Diskussion) 15:20, 21. Jun. 2015 (CEST)

Vorlage zur Wikidata-Einbindung

Habe gerade schnell eine Vorlage Vorlage:WDClaim vorbereitet:

<span class="Wikidata-Data">
{{#invoke:Wikidata|claim|{{{1|}}}|qualifier={{{qualifier|}}}|parameter={{{parameter|}}}|list={{{list|}}}|references={{{references|ja}}}|{{{showerrors|}}}}}
</span>

Ist die so in Ordnung oder habe ich etwas vergessen? --MGChecker – (📞| 📝| ) – HDR 13:48, 16. Jun. 2015 (CEST)

Gut wäre, wenn wir uns initial auf zukunftsträchtige Benennungen einigen könnten. Es gibt schon Vorlage:Wikidata image (mit Leerzeichen, engl.), Vorlage:Wikidata-Eigenschaft (mit Bindestrich, deutsch). Vorlage:WDClaim (zusammengeschrieben, deutsch) wäre die dritte Variante. Auch für die Bezeichnung der HTML-Klasse wären weitere Meinungen erwünscht, ich hätte jetzt spontan "wd-content" vorgeschlagen.--Mabschaaf 10:44, 20. Jun. 2015 (CEST)

Man könnte die einfach Vorlage:aus Wikidata nennen, was zwar zugegeben nicht sehr elegant klingt, aber man kann zumindest leichter ersehen was die Vorlage genau macht. --Mps、かみまみた^Disk. 14:25, 20. Jun. 2015 (CEST)

Hm. Wie wäre es mit Vorlage:Aussage von Wikidata oder Vorlage:Inhalt von Wikidata? --Mabschaaf 14:35, 20. Jun. 2015 (CEST)

Halte ich alles für ziemlich unpraktikabel im Quelltext. Man könnte die Vorlage auch einfach Claim oder Property nennen. (Denn invoke wird hier als erweittertes Property verwendet.) Die anderen Vorlagen erfülen ja andere Zwecke. --MGChecker – (📞| 📝| ) – HDR 16:16, 20. Jun. 2015 (CEST)

Gerade mit den Bezeichnungen "Claim" und "Property" kann doch (fast) keiner hier etwas anfangen. Das hat man doch schon beim MB gemerkt, wo eigentlich noch ein Glossar nötig gewesen wäre. Ist das jetzt eine "Aussage", ein "Wert", ein "Datum" ein "Inhalt" oder was? Mut zur Übersetzung! --Mabschaaf 16:23, 20. Jun. 2015 (CEST)

Du hast Vorlage:Wikidata list und Vorlage:Wikidata list end sowie Vorlage:WikiData-de übersehen. 129.13.72.196 16:53, 20. Jun. 2015 (CEST)

Ich sehe den Versuch einer Übersetzung skeptisch. Lieber bei einer einheitlichen englischen Terminologie bleiben, das erleichtert letztlich das Verständnis in der Kommunikation zu Wikidata über die Sprachgrenzen hinweg - was "Claim" und "Property" zu bedeuten haben, muss man sich natürlich erstmal aneignen, aber das wäre bei einer Übersetzung genauso, denn die spezifische Wikidata-Bedeutung lässt sich nun mal nicht selbsterklärend in einzelne Wörter verpacken. Im deutschen Wikidata-Glossar wird zwar z.B. "property" mit "Eigenschaft" und "claim" mit "Behauptung" übersetzt, aber für einen Wikidata-Neuling ist eine "Behauptung" erstmal nicht weniger Bahnhof als ein "claim". Das ganze doppelspurig zu führen, mit Original-Bezeichnung (die man in der Kommunikation mit anderen dann doch ständig benötigt) und Übersetzung, scheint mir eher verwirrlich. Gestumblindi 17:07, 20. Jun. 2015 (CEST)

+1, für solche Metavorlagen lieber die englischen Bezeichnungen verwenden. Der durchschnittliche Artikelschreiber kommt damit ohnehin nie in Kontakt, da die Vorlage nur von anderen Vorlagen eingebunden werden sollte (-> MB). Wie wäre die geplante Vorlage aufzurufen, um z. B. {{#property:P434}} zu bekommen? Auf der MB-Disk wurde außerdem angeregt, gleich das #if:lokalerWert... in die Vorlage zusetzen. Vorlagen würden also {{Wikidata-Wert|{{{Lokaler Wert|}}}|property:P434|WartungskategorieBeiKonflikt}} (willkürlicher Name, Parameter wären zu diskutieren) aufrufen, die Vorlage nutzt (falls gesetzt) den lokalen Wert, ansonsten holt sie den Wikidata-Wert. Außerdem überprüft die Vorlage, ob ein Konflikt besteht, und sortiert den Artikel ggf. ein. Das funktioniert nicht in URLs und Zahlenwerten die noch formatiert werden, für die muss ggf. eine Sonderlösung gefunden werden. --mfb (Diskussion) 17:33, 20. Jun. 2015 (CEST)

Bzgl. dem lokalerWert möchte ich noch darauf hinweisen, dass das Wikidata-Modul neben der claim-Funktion noch eine getValue-Funktion besitzt, deren Funktion fast identisch ist, aber einen opt-in-Ansatz verfolgt (der aus enWP übernommen wurde). Bei dieser wird zusätzlich noch ein lokaler Wert übergeben, der üblicherweise zurückgegeben wird und auf Wikidata wird nur zurückgegriffen wenn explizit das Schlüsselwort FETCH_WIKIDATA übergeben wird. Anwendungszweck sind hauptsächlich Infoboxen beispielsweise {{Infobox Ort|Name=Musterstadt|Einwohner=FETCH_WIKIDATA|Fläche=30}}, so dass man einerseits den Wikidata-Zugriff unterbinden kann und anderseits transparent im Quellcode sehen kann, wann und wofür Wikidata verwendet wird, statt das Werte scheinbar wie von Zauberhand aus dem Nichts (= Wikidata) kommen. --Mps、かみまみた^Disk. 17:56, 20. Jun. 2015 (CEST)

(BK, @Mfb)Ich kann Dir gerade nicht ganz folgen. Gehen wir mal von einer Infobox aus - dort steht dann irgendwo (beispielsweise):

• | Lokaler Wert = 12345

oder

• | Lokaler Wert = <leer>

In der Boxprogrammierung sollte dann etwas wie {{Vergleich mit Wikidata-Wert|{{{Lokaler Wert|}}}|property:P434|{{Anzeige von Wikidata-Wert|P434}}|Anzeige von lokalem Wert + WartungskategorieBeiKonflikt}} stehen. So weit, so gut. Damit erfüllt die Vorlage aber nicht die angenommene Bedingung D des MB, nämlich ein <span class="Wikidata-Wert"> hinzuzufügen.

Die Ausgangsfrage geht aber zunächst mal dahin, wie die Vorlage {{Anzeige von Wikidata-Wert|P434}} benannt/gestaltet sein soll. Diese muss aber auch ohne eine sie klammernde Programmierung verwendbar sein, beispielsweise als Fließtexteinbindung: Der Wert beträgt {{Anzeige von Wikidata-Wert|P434}}. - was von MB weder explizit erlaubt noch verboten wurde.--Mabschaaf 18:02, 20. Jun. 2015 (CEST)

@Mps:Das kann man optional machen, dass ein bestimmtes Schlüsselwort ignoriert wird ("VON WIKIDATA"?). Die ganzen Weblinkvorlagen sollten aber auch ohne das funktionieren denke ich.

@Mabschaaf: {{Anzeige von Wikidata-Wert|P434}} soll dann das span-Element hinzufügen? Das könnte auch Vorlage:Vergleich mit Wikidata-Wert übernehmen. Einen einzelnen Parameter durch eine Vorlage zu schicken bevor man ihn übergibt hat keinen Vorteil, das kann auch die übergeordnete Vorlage machen und man braucht die Infoboxen etc. nicht mit so langem und größtenteils redundantem Code zu erschlagen. Das URL/Zahl-Problem löst man damit auch nicht. --mfb (Diskussion) 18:14, 20. Jun. 2015 (CEST)

Alle WD-Werte für die Ausgabe durch eine einzige Vorlage zu schicken hätte mM den Vorteil, dass man in dieser zentral deWP-weit die HTML-Klasse (und ggf. weiteres) festlegen und auch ändern könnte. Und eine ganz einfache Wert-Ausgabe-Vorlage brauchen wir sowieso, die die {{#property:…}}-Funktion ersetzen kann.

Alle weiteren Funktionen wie Wertevergleich etc. findet innerhalb einer komplexeren Vorlagenprogrammierung (bspw. in Infoboxen) statt. Was dort passieren soll, ist definitiv erst der zweite Schritt.--Mabschaaf 18:23, 20. Jun. 2015 (CEST)

Die Infoboxen sollen den Wertevergleich machen meinst du? Der ganze Vergleichskram braucht gerne mal zwei Zeilen, das macht die Infobox unübersichtlich. Das würde ich gerade mit dieser Vorlage "Anzeige von Wikidata-Wert" verhindern wollen, damit es für Infoboxenentwickler einfacher bleibt: Die binden diese Vorlage mit möglichst wenigen Parametern ein, die Vorlage (=eben diese zentrale Vorlage durch die alles läuft) erledigt den Rest. --mfb (Diskussion) 18:27, 20. Jun. 2015 (CEST)

Ich habe ja gar nichts gegen eine Vergleichsvorlage, die, wie von Dir beschrieben, drei oder vier Parameter bekommt und den Rest erledigt. Aber dadurch kann doch die Fließtext-Vorlage nicht eingespart werden. Oder reden wir völlig aneinander vorbei?--Mabschaaf 19:01, 20. Jun. 2015 (CEST)

Die Fließtext-Vorlage macht doch letztlich das gleiche wie die Infobox. Sie ruft diese zentrale Wikidata-Vorlage auf und gibt den Wert aus. --Chewbacca2205 (D) 20:42, 20. Jun. 2015 (CEST)

Ja. Gleiche Idee: Der Artikelschreiber soll sich nicht um P434 kümmern müssen. Er bekommt eine Vorlage {{Liegt in Verwaltungseinheit}}. Die macht das gleiche wie die Infobox, und in diesem Fall kann sie vielleicht sogar von der Infobox eingebunden werden (womit auch der Alternativwert sinnvoll ist). --mfb (Diskussion) 20:51, 20. Jun. 2015 (CEST)

Wir reden schon aneinander vorbei. Aktuell kann jedes Property mit {{#property:…}} in den Fließtext eingebunden werden. Das soll bzw. muss auch weiterhin möglich sein. Klar kann man für P434 eine spezielle Vorlage {{Liegt in Verwaltungseinheit}} erstellen, aber erstellen wir dann auch Vorlagen für P435, P436, P437...?? Wohl kaum. Daher benötigen wir eine ganz allgemeine Basisvorlage, die es ermöglicht, jedes beliebige Property in den Fließtext einzubinden, ohne sich um die Festlegungen aus dem MB hinsichtlich der HTML-Klasse kümmern zu müssen.

Ob diese Vorlage {{Anzeige von Wikidata-Wert|Pxyz}} dann auch innerhalb von komplexeren Vorlagen (wie Infoboxen) als Untervorlage verwendet wird, ist doch erst mal völlig egal. Und natürlich kann es zusätzlich Vorlagen geben, die weitere Funktionen erfüllen (also bspw. Datenvergleich mit lokalen Daten).--Mabschaaf 21:01, 20. Jun. 2015 (CEST)

Ja, das stimmt. Wobei ich tatsächlich eher für alle für den Fließtext interessanten Properties eigene Vorlagen erstellen würde. Mit dieser WD-Hilfsvorlage ginge das unkompliziert und würde sich bei häufiger genutzten Properties auch anbieten. Das ganze soll ja in der Anwendung möglichst einfach sein. Aber ja, diese Basisvorlage ist der erste Schritt. --Chewbacca2205 (D) 21:41, 20. Jun. 2015 (CEST)

Mal zusammenfassen (gerne hier ändern, wenn etwas falsch ist oder fehlt):

Anwendungsfälle:

• Im Fließtext: Aktuelle Bevölkerung, Elo oder was auch immer. Herauskommen soll ein Wert der von einem span umschlossen wird. Für größere ganze Zahlen und Fließkommazahlen sollte die Formatierung sinnvoll sein, insbesondere sollte eine Rundung auf x Stellen möglich sein.
• In Infoboxen/Weblinks: Sofern nicht lokal ein Wert angegeben wird, die Daten von Wikidata beziehen. Auch hier muss die Zahlenformatierung berücksichtigt werden. Zusätzlich haben wir den Fall von Weblinks, bei denen das span-Element mehr als die Wikidata-Einbindung umfassen muss. Der Vorlagenprogrammierer muss also etwas im Stil von {{Wikidata-Weblink|[http://example.com/?id=HIERWIKIDATA Text]}} erstellen können. Ebenso muss die Überprüfung auf Kollisionen außerhalb eines solchen Weblinks geschehen, aber die beiden Probleme sind direkt verbunden. Für Infoboxen soll eine Möglichkeit bestehen, in Artikeln "VON WIKIDATA" zu nutzen, um die Datenquelle deutlich zu machen.

Vorschlag:

• Eine Vorlage, die nichts anderes macht als ihren einzigen Pflichtparameter mit span-Element zu umgeben. Alle anderen Vorlagen greifen darauf zu. Auch im Fließtext kann direkt darauf zugegriffen werden, sofern keine speziellere Vorlage verfügbar ist (als Parameter {{#property:…}}). Ggf. eine zusätzliche Vorlage die diese Properties handhabt, um die Syntax schöner zu machen.
• Für besondere Formatierungen mehrere Extra-Vorlagen, die den Wert erst formatieren. Diese Vorlagen geben Parameter an die vorhandenen Formatierungsfunktionen weiter und umgeben deren Output dann mit dem span-Element mithilfe der oben genannten Vorlage.
• Für Infoboxen eine komplexere Vorlage, die die Abfragen handhabt, eine Wartungskategorie auslösen kann und so weiter. Auch hier muss ggf. auf Formatierungen zurückgegriffen werden, was eine etwas längere Vorlagenkette ergeben wird.

Meinungen? --mfb (Diskussion) 23:36, 20. Jun. 2015 (CEST)

Für Roskilde Kommune hätte ich jetzt eigentlich gedacht, dass irgendwer eine Vorlage:Postleitzahl statt kryptischem P281 verzapft. Irgendwelche Vorlagen, wo ich die P- oder Q-Nummern brauche, fände ich Panne… –Be..anyone (Diskussion) 07:53, 21. Jun. 2015 (CEST)

+1 volle Zustimmung zu mfb; @Be..anyone: Es sollte den Vorlagen egal sein, ob die die (kryptische) Pxxx-Bezeichnung oder den zugehörigen Wikidata-Bezeichner verwendest. {{#property:…}} kann auch mit beidem umgehen.--Mabschaaf 11:56, 21. Jun. 2015 (CEST)

Unter der Decke vielleicht. Aber wenn die dubiose "Vorlagenpflicht" laut Meinungsbild Sinn machen soll, wird für Roskilde Kommune ein {{Postleitzahl|4000}} gebraucht, das in jedem Fall brav 4000 anzeigt, und bei abweichender Wikidata-Meinung noch eine versteckte Tracking-Kategorie beschickt. Für so eine sehr einfache Property geht das hoffentlich sogar ohne Lua, ideal zum Ausprobieren.

Das ist auch der einzige Grund, warum ich den schon von Itti bemängelten IP-Vandalismus nicht einfach zurücksetze, denn ein unbelegtes 4000 hier ist kein Stück besser als ein unbelegtes Wikidata 4000 (claim = Behauptung, nicht claim = Aussage, s.o.). Ob es zu 4000 bei Wikidata eine vernünftige Quelle besser als "IP hier sagt das so" gibt, habe ich noch nicht überprüft, aber schlechter geht kaum. –Be..anyone (Diskussion) 13:38, 21. Jun. 2015 (CEST)

In den Artikel trägt da gar keiner eine Vorlage ein. Da wird 4000 eingetragen, den Abgleich mit Wikidata macht ggf. die vorhandene Infobox. Für den Fließtext ist eine Vorlage:Postleitzahl vorstellbar, aber wenn man die als {{Postleitzahl|4000}} eingeben will kann man auch einfach 4000 schreiben - den Abgleich mit Wikidata hat man ggf. noch über die Infobox. --mfb (Diskussion) 14:26, 21. Jun. 2015 (CEST)

Ich bin dafür, #property: völlig in die Tonne zu kloppen, und nur noch #invoke zu verwenden, denn invoke kann alles was Property kann. Property hat jedoch erhebliche Mängel hinsichtlich Belegen und Konfigurierbarkeit, so können keine Belege, Quualifikatoren, Einheitenumrechnungen usw. dargestellt werden. Darum sollte man sich aus Invoke eine Vorlage basteln, die ohne Spezialparameter das macht, was Property macht und zusätzlich standradmäßig ENs einbindet.

Allerdings denke ich, dass man Invoke nicht mit nur einer Vorlage abbilden kann, da sich die weiteren Paramter unterscheiden, wenn unterschiedliche erste Paramter genommen werden. Darum wäre wohl für Claim, GetValue (auch wenn diese beiden sehr ähnlich sind) usw. jeweils eine eigene Vorlage erforderlich. Eventuell könnte man diese beiden Invoke-Untermodule allerdings in einer Vorlage abbilden. Wenn ich das gerade richtig verstehe, kann getVslue nämlich alles was Claim kann, + die Option eines Opt-In über den zweiten Parmeter, dessen Standardwert dann am besten FETCH_WIKIDATA sein sollte. --MGChecker – (📞| 📝| ) – HDR 17:35, 21. Jun. 2015 (CEST)

"#invoke" heißt einfach nur "Lua verwenden" (analog zu {{ = andere Seite einbinden), das ist kein Vergleich zu #property, was einen spezifischen Aufruf von Wikidata-Inhalten ergibt. "Invoke-Untermodule" ergibt keinen Sinn, und den Rest des Beitrags verstehe ich nicht. --mfb (Diskussion) 17:45, 21. Jun. 2015 (CEST)

Sorry, mit #invoke meinte ich natürlich {{#invoke:Wikidata|…}}. Mit Untermodulen meine ich {{#invoke:Wikidata|claim|…}}, {{#invoke:Wikidata|getValue|…}} usw. Und daiese beiden "untermodule von #invoke:Wikidata machen wirklich das gleiche wie property, nur besser, da es mehr Optionen gibt wie

• Einzelnachweise anzeigen
• Einfache Listen generieren
• Qualifikatoren (Genauere Eigenschaften zu Behauptungen) einbinden
• Verlinken (auch in automatisch generierten Listen)
• Modifikation von Genauigkeit der Einbindung und Format.

Je nach erstem Parameter von #invoke:Wikidata unterscheiden sich die des Witeren möglichen Parameter. --MGChecker – (📞| 📝| ) – HDR 18:30, 21. Jun. 2015 (CEST)

#property statt #invoke:Wikidata halte ich für unsinnig, weil so vorhandene Enizelnachweise auf Wikidata nicht angezeigt werden können. --MGChecker – (📞| 📝| ) – HDR 22:03, 21. Jun. 2015 (CEST)

Korrekt, getValue ruft claim auf wenn FETCH_WIKIDATA übergeben wird. Wenn eine Vorlage/Infobox getValue verwendet kann der Vorlagen/Infobox-Ausfüller bestimmen, ob Wikidata verwendet werden soll, wenn claim verwendet wird kann nur der Vorlagen/Infobox-Autor bestimmen ob Wikidata verwendet werden soll. Letzteres scheint mir wegen der geringen Transparenz/Nachvollziehbarkeit im einbindenden Artikel weniger wünschenswert, so dass getValue wohl hauptsächlich für Vorlagen/Infoboxen geeignet ist, claim wenn man direkt im Artikelfließtext auf Wikidata zugreifen will. --Mps、かみまみた^Disk. 22:58, 22. Jun. 2015 (CEST)

Ich bin für eine vorlage, die nur auf getValue basiert, und für {{{2}}} den Standardwert FETCH_WIKIDATA hat. So käme man mit einer Vorlage aus. --MGChecker – (📞| 📝| ) – HDR 23:43, 22. Jun. 2015 (CEST)

Zur Veranschaulichung

Als bessere Diskussionsgrundlage und zur Veranschaulichung habe ich nun einfach mal zu Testzwecken Vorlage:Anzeige von Wikidata-Wert angelegt und diese (ebenfalls testweise) in den Artikel Folgosa (Maia) eingebunden. Wer seine common.css (bzw. vector.css / monobook.css) mit der Zeile

.wikidata-content {background-color: #AACCFF;}

ergänzt, kann Wikidata-Daten anschließend in Artikeln anhand des blauen Hintergrunds erkennen. Bitte die Vorlage noch nicht in großer Stückzahl einbinden, Name der Vorlage und der HTML-Klasse können sich noch ändern, ggf. wird die Vorlage auch wieder gelöscht. Das hängt alles von der weiteren Diskussion hier ab.--Mabschaaf 15:55, 21. Jun. 2015 (CEST)

Wir sollten bei Wikidata-Werten noch danach unterscheiden, ob ein reiner Zahlwert geholt wird oder ein beliebiges anderes Objekt, bei dem sich ein Wikilink anbietet. --Chewbacca2205 (D) 20:16, 21. Jun. 2015 (CEST)

Wikilink worauf? Auf den Typ der geholten Informationen? -> unabhängig davon einfügen. Auf das Ziel selbst? Sehr problematisch mit Verschiebungen, Klammerlemmata etc., außer wir holen direkt das Lemma aus Wikidata mit dem neuen Zugriffssystem. --mfb (Diskussion) 21:46, 21. Jun. 2015 (CEST)

Im Beispiel auf Kreis Maia. Ansonsten bliebe das unverlinkt, wenn die Infobox dieselbe Vorlage nutzt. --Chewbacca2205 (D) 21:53, 21. Jun. 2015 (CEST)

@Mabschaaf: Die Funktionsfülle der Vorlage prädestiniert sie für eine Löschung. --MGChecker – (📞| 📝| ) – HDR 21:58, 21. Jun. 2015 (CEST)

Die Vorlage ersetzt zunächst mal einfach nur {{#property: }}, dient zur Veranschaulichung und als Proof-of-Concept. Wenn am Ende dieser Diskussionen hier steht, dass sie überflüssig ist, lösche ich sie gerne selbst. Andererseits: Wenn tatsächlich alle(!) angezeigten WD-Aussagen durch diese Vorlage gereicht werden, ergäbe sich über die Vorlagenverwendung eine Rückverfolgbarkeit des WD-Einsatzes.--Mabschaaf 22:19, 21. Jun. 2015 (CEST)

Das schon, aber Propertry ist im Vergleich zu invoke:Wikidata schlichtweg unbrauchbar. --MGChecker – (📞| 📝| ) – HDR 22:49, 21. Jun. 2015 (CEST)

Gemäß obigem Vorschlag sollte ohnehin eine andere Vorlage den Wert holen, die verlinkte Vorlage setzt nur die Klasse ein für die Darstellung. Maia zu verlinken ist nicht so einfach, da wir dann von Wikidata auch wieder das deutsche Lemma holen müssen, was in einem anderen Datenobjekt liegt. --mfb (Diskussion) 23:03, 21. Jun. 2015 (CEST)

Das ginge mit invoke:Wikidata und parameter=link. --Chewbacca2205 (D) 21:46, 22. Jun. 2015 (CEST)

Funktioniert auf Roskilde Kommune, um 4000 zu bekommen. Aber der Plan oben war anders, da war von Prüfung, ob 4000 mit Wikidata übereinstimmt, die Rede. –Be..anyone (Diskussion) 01:21, 22. Jun. 2015 (CEST)

Das ist ja auch nicht Ziel/Aufgabe dieser Vorlage. --mfb (Diskussion) 11:09, 22. Jun. 2015 (CEST)

Name der HTML-Klasse

Wie soll die zukünftige HTML-Klasse heißen? Vielleicht können wir hier einfach Vorschläge sammeln und hoffentlich einen Konsens finden.--Mabschaaf 21:47, 20. Jun. 2015 (CEST)

• "Wikidata-Data" (von MGChecker, oben)
• "wd-content" (von Mabschaaf, oben) selbst gestrichen, lieber keine Abkürzung --Mabschaaf 11:56, 21. Jun. 2015 (CEST)
• "wikidata-einbindung" (von F-scn, MB-Disku)

+1 --Chewbacca2205 (D) 21:57, 20. Jun. 2015 (CEST)

• "wikidata-content" (von 85.212.3.151 21:48, 20. Jun. 2015 (CEST))

+1 --Mabschaaf 11:56, 21. Jun. 2015 (CEST)

+1; Meinung zum Rest kommt gleich, ich glaube hier wurden einige Denkfehler gemacht. --MGChecker – (📞| 📝| ) – HDR 17:23, 21. Jun. 2015 (CEST)

Ich würde bei Kleinschreibung bleiben, nach einer schnellen durchsicht scheinen alle CSS-Klassen in der Wikipedia kleingeschrieben zu werden. -- F-scn (Diskussion) 21:55, 20. Jun. 2015 (CEST) Okay, die Durchsicht war wohl doch zu schnell. Im Gegenteil: Man scheint dort wohl eher CamelCase zu verwenden, also WikidataContent. Vielleicht kann das aber noch mal jemand nachschauen, ob ich mich da nicht gerade was verwechsele. -- F-scn (Diskussion) 21:59, 20. Jun. 2015 (CEST)

<div-Anweisung in Lua einbauen

Ich schiebe mal gleich einen anderen Vorschlag hinterher: Wie wäre es, die CSS-Klasse in das Lua-Modul "claim" einzubauen? Wenn es möglich ist, vielleicht auch in das #property-Komando, aber das wird vermutlich etwas aufwendiger, weil dort vermutlich Wikimedia mitarbeiten müsste. -- F-scn (Diskussion) 21:55, 20. Jun. 2015 (CEST)

Lua-Modul: Klar, das ist logische Folge des MB.

zu #property: Es wäre natürlich lokal viel weniger Aufwand, wenn WD direkt eine HTML-Klasse setzen würde. Ziel bei der Konzeption des MB war aber, eine Lösung vorzuschlagen, die lokal umgesetzt werden kann, die also nicht auf Mitarbeit der WD/Mediawiki-Programmierer angewiesen ist. Aber vielleicht mag ja jemand via Phab nachfragen...--Mabschaaf 22:05, 20. Jun. 2015 (CEST)

Siehe auch d:Wikidata_talk:Arbitrary_access#Where / how can i see "usage tracking"? mit phab links. --Atlasowa (Diskussion) 22:18, 20. Jun. 2015 (CEST)

Klasse, vielen Dank!--Mabschaaf 22:22, 20. Jun. 2015 (CEST)

Halte ich nicht für sinnvoll, da dass Modul nur die puren Werte zurückgeben sollte damit Vorlagen mit den Werten weiterarbeiten bzw. weiterrechnen können (z.B. wenn man Bevölkerungszahlen und/oder Flächen aus Wikidata holt und daraus die Bevölkerungsdichte berechnen wollte), was unterbunden würde (bzw. man müsste Hacks anwenden die Tags im Nachhinein wieder zu entfernen) wenn die in einem div-Container zurückgegeben würden. Das gleiche gälte für #property – das würde den Nutzen extrem einschränken. So ein div-Container müsste also auf einer höheren Ebene hinzugefügt werden, eben dort wo das Modul von der Vorlage gekapselt wird. Auch semantisch bzw. nach dem Single-Responsibility-Prinzip sollte man beide Dinge – eigentliche Funktionalität und Auszeichnung/Metafunktionalität – trennen. --Mps、かみまみた^Disk. 00:17, 21. Jun. 2015 (CEST)

Übertrag von Wikidata in deutsche Wikipedia?

Ich wäre grundsätzlich dafür die Wikidata-Vorlagen von Anfang an botfreundlich zu gestalten. Sobald Werte aus Wikidata eingebunden werden, sollte ein Bot loslaufen, und die Daten direkt bei uns lokal eintragen. Für die Anzeigen werden dann die lokalen Daten verwendet, Wikidata befüllt eine Wartungskat, die befüllt wird, sobald sich die Werte auseinander Bewegen.

* Damit wäre dann z.B sichergestellt, dass in der Versionsgeschichte aus 2005 die Einwohnerzahl des Jahres 2005 steht und nicht der Wikidatawert aus dem Jahr 2015.

* Wenn sich die Wartungskat aufgrund einer Differenz befüllt, kann man entscheiden, ob unsere Daten aktueller sind, oder jene auf wikidata, und kann dann an der passenden Stelle ausbessern. Ich wette mal, dass in 95% der Fälle Wikidata ausgebessert werden müsste.

 Frohes Schaffen — Boshomi ☕⌨☺   10:25, 21. Jun. 2015 (CEST)

Boshomi, das ist weit ab von allem bisher diskutiertem. Richtig ist, dass durch Verwendung von Wikidata-Variablen (in welcher Form auch immer) Mementos über die Versionsgeschichte nicht mehr verfügbar sind. Aber das sind sie auch jetzt schon nicht, wenn zwischenzeitlich die Programmierung einer klassischen Vorlage geändert wurde. Ein Bot, der alle Daten von WD in den lokalen Quelltext holt, müsste sicherlich per weitreichendem Konsens (ich vermute: Meinungsbild) legitimiert werden. Ich bitte Dich aber, diese Diskussion an einem anderen Ort zu führen, um das hier nicht zu zerfleddern.--Mabschaaf 11:56, 21. Jun. 2015 (CEST)

Der Bot müsste nur dann Daten aus wikidata holen, wenn der Benutzer diese nicht lokal angibt. Man kann mit AGF davon ausgehen, dass zu dem Moment in dem lokal eine wikidata-Vorlage eingebunden wird, der User mit den angezeigten Daten zufrieden ist. Der Bot würde somit nur eine Datensicherung, und die Korrektheit der Versionsgeschichte sicherstellen. Somit sollte das lokale Abspeichern per Bot kein Problem sein. Der Bot sollte aber per default keine lokalen Daten überschreiben, sondern erst dann, wenn manuell festgestellt wurde, dass die wikidata überprüfbar stimmen. Genauso braucht es einen Bot der korrekte lokale Daten nach Wikidata überträgt, natürlich zusammen mit externen Beleg.

Zentrale Datenhaltung ohne Redundanz erfordert eine erhebliches theoretisches Wissen über Datenhaltung, Wissen das großflächig nicht vorhanden ist. Mit Hilfe technischer Redundanz vereinfachen sich die Verfahren gewaltig, und wir bekommen langfristig sogar sowas wie ein Stück Lernfähigkeit in das System. Ich würde die technische Redundanz als Normalfall vorsehen, und die direkte Einbindung nur im Ausnahmefall (z.B. bei täglich/wöchentlich veränderten Daten) verwenden.  Frohes Schaffen — Boshomi ☕⌨☺   13:11, 21. Jun. 2015 (CEST)

Boshomi, das ist Deine Privatmeinung. Auch wenn ich ihr ein Stück weit zustimme, halte ich sie nicht für konsensfähig. Nochmal: Du wirst eine Mehrheit dafür finden müssen - und Du killst gerade diese Diskussion.--Mabschaaf 13:28, 21. Jun. 2015 (CEST)

Ich habe die Diskussion als eigenen Abschnitt herausgetrennt. --mfb (Diskussion) 14:26, 21. Jun. 2015 (CEST)

@Boshomi: Bitte versuche nciht, dass MB im Nachhinein außer Kraft zu setzen. Die Einbindung außerhalb von Wartungslisten ist zweifelsfrei erlaubt. --MGChecker – (📞| 📝| ) – HDR 17:35, 21. Jun. 2015 (CEST)

Mir geht es überhaupt nicht um eine Außerkraftsetzung von wikidata. Ich würde sogar Daten aus wikidata direkt per Bot entsprechend AGF hierher übertragen lassen. Durch die vorgeschlagene Redundanz wird die Verwendung von wikidata für normale Benutzer deutlich vereinfacht, weil sich normale Benutzer über die Art der Datenhaltung und Datenpflege kaum Gedanken machen müssten. Ich glaube nicht, dass ohne Redundanz gröbere Fehler die sich in zentrale System im Lauf der Zeit zwingend einschleichen durch lokale Benutzer auflösbar wären. Wenn so ein Fehler passiert, und länger nicht bemerkt wird, (tote Weblinks bleiben eine halbe Ewigkeit unentdeckt!) dann artet das in einer gewaltigen Menge Handarbeit aus, die nochdazu von sehr erfahrenen Benutzern zu erledigen wäre. Die in Frage kommenden Benutzer sind aber mit anderen Tätigkeiten schon auf Jahre hinaus ausgelastet. Führt man Redundanz gleich zu Beginn ein, dann wäre auch die längerfristige Wartung zum allergrößten Teil automatisierbar. Mir geht es also darum wikidata auf einfache Weise für alle nutzbar zu machen, und dabei gleichzeitig die Qualität der Daten zu sowohl hierzupedia als auch auf wikidata zu verbesseren.  Frohes Schaffen — Boshomi ☕⌨☺   18:02, 21. Jun. 2015 (CEST)

Testsystem

Mir werden die obigen Abschnitte zu unübersichtlich. Ich habe meine Idee von oben mal ansatzweise umgesetzt. Kann derzeit nur Properties, lässt sich aber leicht erweitern:

• Vorlage:Wikidata-Einbindung kümmert sich um die Klasse. Jeglicher Anzeigewert von Wikidata muss über diese Vorlage laufen.
• Vorlage:Wikidata-Wert holt den Wert von Wikidata und stellt diesen mithilfe obiger Vorlage und ggf. weiterer Formatierung dar.
• Vorlage:Wikidata-Check bietet zusätzlich die Abfrage eines lokalen Werts an, stellt fest was angezeigt werden soll und bindet ggf. eine einstellbare Wartungskategorie ein bei Abweichungen.
• Kategorie:Wikipedia:Abweichende Daten auf Wikidata ist die Standardkategorie, falls oben keine andere Kategorie eingegeben wird, und kann übergeordnete Kategorie für all diese Wartungskategorien werden. Die Einordnung hat sich an den Schachspielern orientiert, sollte aber wohl geändert werden, siehe auch die Kategoriediskussion.

Alles noch nicht getestet, dazu komme ich vielleicht später oder morgen. --mfb (Diskussion) 20:32, 25. Jun. 2015 (CEST)

Ich weiß nicht ob die erste Vorlage nötig ist, oder nur die Server durch das Transkludieren belasten wurde. --MGChecker – (📞| 📝| ) – HDR 23:02, 26. Jun. 2015 (CEST)

Bei den Vorlagen selbst muss ich mal gucken, sind ein bisschen verwirrend für mich ^^ --MGChecker – (📞| 📝| ) – HDR 23:06, 26. Jun. 2015 (CEST)

Die erste Vorlage soll eben sicherstellen, dass wikipediaweit die gleiche Klasse genutzt wird, und dass sich diese ggf. ändern lässt. --mfb (Diskussion) 23:08, 26. Jun. 2015 (CEST)

Ich sehe um ehrlich zu sein keinen Grund, den Namen der CSS-Klasse nachträglich zu ändern, es belastet jedoch strenggenommen die Ressourecen unnötig. Zu deinen Vorlagen muss ich leider sagen: Die Präfix-Suffix-Sache wird wegen der Architektur des Lua-Moduls leider kaum klappen, wenn man sie nicht direkt ins Lua-Modul einbaut. Property ist einfach nicht zu gebrauchen, wie schon mehrmals gesagt. Einzelnachweise und viel geringere Möglichkeiten. Mps kann dazu vielleicht etwas sagen und die Möglichkeit direkt ins Modul einbauen, damit das problemlos klappt. --MGChecker – (📞| 📝| ) – HDR 19:06, 29. Jun. 2015 (CEST)

Das Lua-Modul kann gerne mehr "fertigen" Code ausliefern (z. B. mit Link und Einzelnachweis), in dem Fall sind Präfix und Suffix unnötig. Wenn das Modul das nicht kann, sondern z. B. nur eine ID liefert, können die beiden Parameter verwendet werden. Property durch das Lua-Modul zu ersetzen sollte kein Problem sein.

Vielleicht will man den Klassennamen nie ändern - wer weiß. Wenn die Vorlagen sinnvoll im Cache gespeichert werden sollte die zusätzliche Einbindung kein Problem sein (kann ja statisch eingesetzt werden). Andernfalls müssten mehrere Vorlagen diese Klasse haben, und man müsste bei mehreren Vorlagen schauen, dass die das alles richtig machen. --mfb (Diskussion) 23:22, 29. Jun. 2015 (CEST)

Farbliche Hervorhebung eines mit Nowiki eingerahmten Texts

Ich beiße mir da die Zähne aus... Frage ich mal die Fachleute. Ziel ist, in dieser Liste die Darstellung der Ref-Tag-Inhalte mit einer Hilfsvorlage zu erledigen (das was mit Nowiki jeweils eingerahmt wurde). Zusätzlich zu bisher sollten Teile des dargestellten Inhalts gelb hervorgehoben werden. Mein Gedanke war eine Vorlage zu machen, die als ersten Parameter den Inhalt, als (optinalen) 2. den hervorzuhebenden Teil des Inhalts übergeben bekommt. Der gesamte Inhalt ist wie bisher mit Nowiki einzurahmen, was die Vorlage erledigen sollte.

Also bei

• {{Vorlage:Wirkungsloser Inhalt für ref-Tag/Inhalt|Dies ist ein Test|ist}}

sollte das Ergebnis dieses sein:

• Dies [[ist]] ein [[Test]]

Ich wollte {{Str replace}} nutzen, um das Span-Tag für die Hervorhebung einzufügen. Dazu muss ich den Nowiki-Modus temporär "unterbrechen". Natürlich könnte ich die ganze Sequenz recht le3icht per Bot erzeugen, ich hätte diesen aber gerne von Formatierungsdetails der Diagnose-Seite möglichst freigehalten. Gibt es da einen vernünftigen Weg?--Cactus26 (Diskussion) 17:59, 17. Jun. 2015 (CEST)

Mit str find kannst du den String in drei Teile teilen und die einzeln behandeln (ihnen einzeln ihr nowiki geben). Ist aber ziemlich kompliziert. Kannst du nicht drei Parameter übergeben?

• {{Vorlage:Wirkungsloser Inhalt für ref-Tag/Inhalt|Dies|ist|ein Test}}

Nachteil: Whitespace wird ggf. falsch dargestellt. --mfb (Diskussion) 20:23, 17. Jun. 2015 (CEST)

Kann man nicht statt nowiki die Numeric character reference für Wiki-Zeichen (eckige Klammern etc.) nehmen? Erst den String ohne Rücksicht auf Wikisyntax ändern, dann in NCR tauschen? ÅñŧóñŜûŝî (Ð) 21:04, 17. Jun. 2015 (CEST)

Hmm.. für Links könnte {{urlencode}} ganz gut funktionieren. Aber was passiert mit Vorlagen? Die würden direkt ausgewertet, wenn man sie als Parameter auf die Seite setzt. Müsste man direkt in der Vorlageneinbindung abfangen, nicht erst in der Vorlage. Gut, müsste man beim nowiki auch.

• {{tl|Vorlage:Wirkungsloser Inhalt für ref-Tag/Inhalt|{{urlencode:Dies [[ist]] ein [[Test]]}}|{{urlencode:[[ein]]}}}}
• {{Vorlage:Wirkungsloser Inhalt für ref-Tag/Inhalt|Dies+%5B%5Bist%5D%5D+ein+%5B%5BTest%5D%5D|%5B%5Bein%5D%5D}}

Das dürfte klappen, aber dann muss das für den Anwender wieder zurückverwandelt werden. --mfb (Diskussion) 21:17, 17. Jun. 2015 (CEST)

@Cactus26:

Schlachte Benutzer:Aka/Linkfehler/Artikel aus:

• Benutzer:Aka/Linkfehler/Link
• Benutzer:Aka/Linkfehler/Weblink

in Benutzer:Aka/Linkfehler/001.

VG --PerfektesChaos 21:34, 17. Jun. 2015 (CEST)

Danke schon mal für die Anregungen. Werde mir das heute Abend genauer ansehen.--Cactus26 (Diskussion) 07:54, 18. Jun. 2015 (CEST)

Die Variante mit den 3 Parametern gefällt mir ganz gut, hätte auch den Vorteil, dass kein Teil redundant ist. @Mfb: In welcher Situation gibt es da Probleme mit Whitespaces, habe gerade ein bisschen experimentiert, konnte bisher keine entdecken.--Cactus26 (Diskussion)

Whitespace am Parameteranfang und -ende wird generell entfernt, wenn der richtig dargestellt werden soll wird es schwieriger. Beispiel:

Commons: foo – Sammlung von Bildern, Videos und Audiodateien

--mfb (Diskussion) 19:06, 18. Jun. 2015 (CEST)

Das scheint nur der Fall, wenn der Parameter mittels 1= etc. angegeben wird. Wären wir beim nächsten Problem: = oder Pipe im Inhalt...--Cactus26 (Diskussion) 19:32, 18. Jun. 2015 (CEST)

Wegen der = ist eine Benennung der Parameter sehr sinnvoll. Pipes als {{!}} schreiben. Ist aber nicht auf benannte Parameter beschränkt:

Commons: foo – Sammlung von Bildern, Videos und Audiodateien

--mfb (Diskussion) 10:53, 19. Jun. 2015 (CEST)

Vorlage:DBCS: optionaler Parameter

Hallo, ich versteh nicht so viel von Vorlagenprogrammierung. Ich hätte gern einen zusätzlichen (optionalen) Parameter in der Vorlage:DBCS, mit dem man den Autor angeben kann. Das Ganze sollte ohne Autorenangabe weiterhin so aussehen:

• {{DBCS|1|NAME=Frank Frost Abbott}}
• Vorlage:DBCS/Wartung/Keine ID ermittelbar

Und mit Autorenangabe:

• {{DBCS|1|NAME=Frank Frost Abbott|AUTOR=Ward W. Briggs}}
• Eintrag zu Frank Frost Abbott in der Database of Classical Scholars, verfasst von Ward W. Briggs (englisch)

Viele Grüße und vielen Dank, [ˈjonatan] (ad fontes) 10:21, 19. Jun. 2015 (CEST)

Ist eingebaut, ich habe aber zwei Fragen dazu: Ist das gewollt, dass die Bestimmung des Anzeigenamens davon abhängt, ob die ID von Wikidata bezogen wird oder nicht? Und muss das sein, dass der Name als unbenannter Parameter oder als NAME= eingegeben werden kann? Solche Alternativen ergeben bei alten Vorlagen Sinn wenn man bei Änderungen alte Einbindungen kompatibel halten will, aber bei neuen Vorlagen sollte man das Format so weit wie möglich einheitlich halten, das erleichtert später die Wartung oder andere Änderungen. --mfb (Diskussion) 10:47, 19. Jun. 2015 (CEST)

Danke dir. Zur ersten Frage: Spricht was dagegen? Immerhin kann man so vermeiden, dass die Klammern von Klammerlemmata im Weblinks-Bereich auftauchen. Zweitens: Muss nicht sein, ich habe nur ahnungslos C&P von Vorlage:BBF Personaldaten gemacht. [ˈjonatan] (ad fontes) 11:12, 19. Jun. 2015 (CEST)

Zum Titel ohne Klammerzusatz: {{#invoke:WLink|getArticleBase}} gibt diesen aus. Wieso man einmal auf Wikidata zurückgreift und einmal nicht sehe ich aber nicht, bei Wikidata steht vielleicht nichts.

Zu den Parametern: Da die Einbindungen wohl alle von dir sind, haben sie vermutlich ein einheitliches Format? Ich finde nur parameterlose Einbindungen, hast du den zweiten Parameter irgendwo benötigt? --mfb (Diskussion) 14:05, 19. Jun. 2015 (CEST)

Nein, bisher habe ich den zweiten Parameter nirgends eingesetzt. Aber er hat folgenden Sinn: Wenn man im Artikel XYZ einen Verweis auf den DBCS-Eintrag zu Person ASD hinterlassen will, kann man so den Namen des angeben. Er weicht ja dann vom PAGENAME ab. Natürlich muss man dafür den 2. Parameter nicht benennen.

Was den Artikeltitel ohne Klammerzusatz angeht: Den können wir gern auch aus Wikidata einbinden. [ˈjonatan] (ad fontes) 15:16, 19. Jun. 2015 (CEST)

Ja, die Möglichkeit, einen Namen optional einzugeben, sollte auf jeden Fall vorhanden sein - aber eben nur auf eine Art. Vorlagen mit alternativen Parametern zu warten ist immer viel umständlicher. Wir können uns auf das Wikidata-Label nicht verlassen, es ist nicht überall gesetzt und es ist auch gerne mal Ziel von Vandalismus (der dort nicht gesichtet werden muss um angezeigt zu werden). Den Artikelnamen ohne Klammerzusatz zu verwenden (sofern kein abweichender Name angegeben) ist sinnvoller. Vorschlag für die Logik:

ID: Falls Parameter 1 gesetzt, diesen nutzen, sonst von Wikidata nehmen, falls beides nicht vorhanden ist Fehlermeldung. Name: Falls Parameter 2 gesetzt, diesen nehmen, sonst Lemma ohne Klammer. Autor: Falls Parameter 3 gesetzt, diesen nehmen, sonst keiner. Falls du auch Parameter 1 noch nicht verwendet hast, fände ich Parameter Id=, Name=, Autor= noch besser. --mfb (Diskussion) 15:46, 19. Jun. 2015 (CEST)

Können wir gern so machen. Würdest du die Vorlage entsprechend umbauen und einen Bot die 160 Einbindungen korrigieren lassen? [ˈjonatan] (ad fontes) 18:35, 19. Jun. 2015 (CEST)

Ist geändert. Ist fraglich ob Einbindungen geändert werden müssen. Falls ja, werden sie in den nächsten Tagen auf der Wartungsseite auftauchen. --mfb (Diskussion) 20:45, 19. Jun. 2015 (CEST)

Dieser Abschnitt kann archiviert werden. mfb (Diskussion) 20:26, 30. Jun. 2015 (CEST)

Vorlage:IMDb

Hallo, manche Artikel enthalten mehrere IMDb Einträge, z.B.

{{IMDb|tt0015772|Der Adler}}

{{IMDb|tt0027554|Dubrowskij}} ==>

Der Adler bei IMDb

Dubrowskij bei IMDb

Da wäre doch vielleicht ein Parameter nützlich, mit dem sich das Verlinken von IMDb ab dem 2. Eintrag unterdrücken läßt. Gruß --Hedwig Storch (Diskussion) 14:14, 20. Jun. 2015 (CEST)

"in der [[Internet Movie Database]]" ändern in "in der {{#if:{{{nolink|}}}|Internet Movie Database|[[Internet Movie Database]]}}" (an allen drei Stellen) - muss aber ein Admin machen, die Vorlage ist vollgeschützt. --mfb (Diskussion) 14:19, 20. Jun. 2015 (CEST)

Ehrlich gesagt: wozu? Ist doch überhaupt kein Problem, wenn der Artikel dazu zweimal verlinkt wird. Würde IMO sogar komisch aussehen, wenn es einmal verlinkt und einmal unverlinkt bleibt. Verstößt AFAIK auch gegen keine Regel. Und wenn einer der Links später wieder entfernt werden würde - aus welchem Grund auch immer - müsste man zusätzlich auch wieder die Parameter entfernen, damit der Artikel dann doch wieder verlinkt wird. Sehe da nicht viel Nutzen. --95.90.33.121 18:49, 20. Jun. 2015 (CEST)

Ich verstehe ebenfalls das Problem nicht. Was soll damit erreicht werden? –Queryzo ?! 19:02, 20. Jun. 2015 (CEST)

Dass obiges Beispiel so im Artikel dargestellt wird (hier jetzt durch Quelltextakrobatik gefakt):

Der Adler bei IMDb

Dubrowskij in der Internet Movie Database (englisch)

Ich stimme der 95er-IP aber zu, die doppelte Verlinkung halte ich für deutlich weniger "schlimm" als den nötigen Pflegeaufwand, wenn die Reihenfolge der Vorlagen vertauscht oder die erste (die mit aktivem Link) entfernt wird.--Mabschaaf 19:08, 20. Jun. 2015 (CEST)

Plus zusätzlicher Kram auf der Dokuseite, der fast nie genutzt wird. Ja, stimmt wohl, Nutzen ist zu gering. --mfb (Diskussion) 20:45, 20. Jun. 2015 (CEST)

Hallo, danke für Eure Antworten. Einerseits habt Ihr recht, es handelt sich bei dem von mir aufgeworfenen Problem um eine Bagatelle. Andererseits wurde mir vor Jahren einmaliges Verlinken im kürzeren Artikel - um den es sich hier handelt - empfohlen, wenn ich mich recht entsinne. Das viermalige Verlinken in dem Artikelentwurf Dubrowskij sieht nach meinem ästhetischen Empfinden bißchen albern aus, aber ich habe mich damit abgefunden. Fall erledigt. Grüße --Hedwig Storch (Diskussion) 09:44, 21. Jun. 2015 (CEST)

@Hedwig Storch: Bitte die Vorlage {{IMDb}} nicht als Einzelnachweis verwenden, dafür ist sie nicht gedacht und durch das Fehlen eines Zugriffsdatums auch nicht zulässig. Derartige Einbindungen werden in einer Wartungskategorie gelistet und perspektivisch durch meinen Bot in {{Internetquelle}} umgewandelt. Ohne IMDb-Vorlage kannst du auch die Links entsprechend setzen!  

Zur Frage (für die Verwendung unter „Weblinks“), man könnte den Artikelinhalt auswerten und prüfen, ob die Vorlage an erster Stelle steht und nur dann die IMDb verlinken, allerdings erzeugt das eine Vorlagenschleife. Ein Teil der Einbindungen könnte man abdecken, indem man prüft, ob der Artikel in Wikidata eine IMDb-ID besitzt und wenn ja, nur bei dieser die IMDb verlinken. Dies setzt allerdings voraus, dass die übereinstimmende ID in der ersten Vorlageneinbindung verwendet wird. –Queryzo ?! 11:08, 21. Jun. 2015 (CEST)

Queryzo, Du kannst den Abgleich einer lokalen ID mit der WD-ID aber nur für eines verwenden: Entweder den Check auf Konsistenz zwischen lokalem Wert und WD-Wert oder dem Setzen/Nicht-Setzen des Links auf den Artikel zur IMDb. Ich hielte es für deutlich sinnvoller, über den Vergleich lokal/WD (zumindest noch für eins, zwei Jahre) einen zusätzlichen Vandalismusschutz in der Hand zu haben, bis eben die dahingehenden Prozesse auf WD weiterentwickelt wurden und das nicht mehr nötig scheint. Der Beschluss der RFF, die lokalen IDs weiter vorzuhalten geht ja auch in diese Richtung.--Mabschaaf 11:46, 21. Jun. 2015 (CEST)

Warum entweder oder? –Queryzo ?! 12:57, 21. Jun. 2015 (CEST)

Wenn eine mehfache Einbindung von IMBd wie in Dubrowskij gewollt ist, finden natürlich verschiedene IDs im gleichen Artikel Verwendung. Nun hat aber das Artikellemma bzw. der zugehörige WD-Datensatz nur genau eine ID. Alle anderen müssen folglich auf einer Wartungsliste landen (Mismatch zwischen lokaler und WD-ID). Diese Mismatch-Fälle sollen aber geklärt und ggf. korrigiert werden, damit die Wartungsliste sauber bleibt - dann kann das aber nicht gleichzeitig das Kriterium dafür sein, ob der Link zur Internet Movie Database nun gesetzt wird oder ob es beim Plain Text "Internet Movie Database" bleibt.--Mabschaaf 13:36, 21. Jun. 2015 (CEST)

Verstehe, allerdings weiß ich nicht, wie man diese Wartungsliste abarbeiten soll. Bisher beschränke ich es auf gelegentliche Botläufe zur Auffindung von Einbindungen im Fließtext. Für mehrere Einbindungen unter „Weblinks“ bin ich bisher ratlos. –Queryzo ?! 13:50, 21. Jun. 2015 (CEST)

Eine Whitelist, und ein Bot der die Liste damit abgleicht? Sind einige hundert Einträge in der Linkliste, ich weiß nicht wie viele davon in welche Wartungskategorie gehören. --mfb (Diskussion) 14:30, 21. Jun. 2015 (CEST)

Ah, per Bot, nur leider bin ich da überfragt. Wie würde man sowas technisch umsetzen? –Queryzo ?! 15:11, 21. Jun. 2015 (CEST)

(BK)Sehe ich das richtig, das genau bei diesen Fällen das oben beschriebene Problem auftritt? Also die IMDb-Vorlage wird in anderen Artikeln v.a. als Einzelnachweis genutzt, um bestimmte Sachverhalte zu belegen? Dann könnte man der Vorlage noch einen zusätzlichen Parameter (wie nocheck=ja) spendieren, der den Abgleich mit der WD-ID unterdrückt und daher auch keine/n Wartungskat/-link wirft. Ganz nebenbei sollte dann auch geprüft werden, ob in diesen Fällen in der Vorlage ein Titel angegeben ist, der ist dann nämlich auf alle Fälle ebenfalls abweichend vom Lemma, in dem die Vorlage verwendet wird.--Mabschaaf 15:17, 21. Jun. 2015 (CEST)

@Queryzo: Der Bot würde gelegentlich (sagen wir 1mal/Woche) die Linkliste (oder Wartungskategorie) einlesen, alle Artikel streichen die auf einer bestimmten Seite ("Whitelist") stehen, und den Rest auf eine weitere Seite schreiben. Idealerweise gleich mit zusätzlichen Infos, z. B. der angegebene Titel, ob die Vorlage in einem Einzelnachweis verwendet wurde oder nicht, oder was das Wikidata-Item dazu ist, oder so etwas. --mfb (Diskussion) 11:08, 22. Jun. 2015 (CEST)

User Info

Hallo liebe Vorlagenbastler,
wie sieht das mit der oben genannten Vorlage aus? Wird die auch ins Deutsche übersetzt? Ist doch eigentlich obligatorisch, oder? Was denkt ihr? --Rogi (Diskussion) 17:45, 22. Jun. 2015 (CEST)

Wäre einfach zu übernehmen, aber ich sehe den Bedarf nicht. Die meisten Nutzer, die ihre Benutzerseite gestalten, legen meistens Wert auf ein eigenes Layout. --mfb (Diskussion) 20:02, 22. Jun. 2015 (CEST)

Das ist eine einheitliche Vorlage für die direkten Angestellten der WMF oder die in Vertragsunternehmen beschäftigten Accounts; sie agieren unter Klarnamen full name und sind immer bei einer organization / company beschäftigt, haben dort einen job title und haben immer einen disclaimer, dass die Postings ihre persönliche Ansicht wäre und nicht die offizielle Meinung der WMF sein müsse, und veröffentlichen als contact E-Mail-Adressen, Telefonnummern und IRC-Nicks.

Für uns sind alle diese Felder ziemlicher Nonsens.

VG --PerfektesChaos 10:25, 26. Jun. 2015 (CEST)

Dieser Abschnitt kann archiviert werden. mfb (Diskussion) 20:24, 30. Jun. 2015 (CEST)

Ist es möglich eine Vorlage zu bauen die den Lesbarkeitsindex eines Wikipediaartikels bewertet und ausgibt bzw. dies in die Seite zu integrieren?

Der Lesbarkeitsindex ist ein Maß für die Einfachheit des Verständnis zu einem Text. Da die WP bestrebt ist WP:Allgemeinverständlichkeit einzuhalten, wäre so eine Indexzahl ganz nett für Leser, aber auch schreiber. Es gibt einige Onlineseite die solche Textprüfungen anbieten bspw. [5].

Wäre das interessant? Beziehungsweise wenn ich mit dem Vorschlag hier an der falschen Stelle bin, dann einfach weiterverweisen --Airwave2k2 (Diskussion) 20:11, 24. Jun. 2015 (CEST)

Hallo Airwave2k2, ich habe dazu eine kleine Sammlung unter Benutzer:Atlasowa/Verständlichkeit. Benutzer:Dietzel hatte mal ein nettes user script Benutzer:Dietzel/lix.js geschrieben, dass Du Dir in die common.js laden kannst um jeweils den WP-Artikel benoten zu lassen, siehe auch die durchwachsenene Ergebnisse bei Benutzer:Atlasowa/Verständlichkeit#Wikipedia_Tooltest_Beispiele: Interessantes Thema! :-) --Atlasowa (Diskussion) 20:47, 24. Jun. 2015 (CEST)

Hallo Atlasowa Danke für den Lesestoff. Ich hangel mich mal durch. --Airwave2k2 (Diskussion) 03:07, 25. Jun. 2015 (CEST)

Artikel können sich generell nicht selbst bewerten, da sie dann auch die Anzeige des eigenen Bewertungsbausteins bewerten müssten - die Rekursion funktioniert nicht. Man könnte mit Tricks nur den restlichen Quelltext analysieren, allerdings sind Vorlagen dazu nicht in der Lage und auch mit Modulen wäre das Aufwand. Dazu wäre das eine Änderung, die ein Meinungsbild braucht. Und wenn man schon so etwas einführen will, wird man eher an eine softwareseitige Lösung denken, anstatt mit Modulen herumzubasteln. Wenn es dir nur um eine Anzeige für dich geht, ist benutzerspezifisches Javascript (siehe oben) viel sinnvoller. --mfb (Diskussion) 19:33, 25. Jun. 2015 (CEST)

Belege fehlen

Hallo! Bei einem kleineren Konflikt heute um Bausteinschubserei stieß ich auf ein Problem, was vieleicht die Ursache für viele dieser Streitigkeiten ist. Der Text der Vorlage lautet:

• "Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Die fraglichen Angaben werden daher möglicherweise demnächst entfernt. Bitte hilf der Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst. Näheres ist eventuell auf der Diskussionsseite oder in der Versionsgeschichte angegeben. Bitte entferne zuletzt diese Warnmarkierung."

Die Regelung für den Einsatz dieser Vorlage lautet dagegen:

• ""Diese Vorlage ist dazu gedacht, alle Benutzer freundlich darauf hinzuweisen, dass zumindest für erhebliche Teile des Artikels Belege bisher fehlen und nachgetragen werden müssen. Damit der Baustein für die Recherchearbeit anderer Wikipedianer hilfreich sein kann, ist es wichtig, auf der Diskussionsseite des Artikels näher zu erläutern, für welche Aussagen des Artikels Belege besonders wichtig wären. Der Erstautor sollte möglichst über das Einstellen des Bausteins informiert werden."

Für mich besteht da ein Widerspruch. So ist das Ziel offenkundig die freundliche Lösungssuche zwischen Mitarbeitern, aber der Text wurde so formuliert, das er einerseits bedrohlich wirkt, anderseits die Kommunikation auf den Artikeldiskussionen als Option, und nicht wie vorgesehen als Standard darstellt. Man könnte viel an dieser Vorlage ändern, ich würde aber als ersten Schritt der Deeskalation vorschlagen, das "eventuell" und das mit der Versionsgeschicht zu entfernen. Das dient nicht der Lösungssuche, und mancher "Bausteinschubser" kennt vieleicht gar nicht das Ziel dieser Vorlage.Oliver S.Y. (Diskussion) 22:59, 25. Jun. 2015 (CEST)

Dann würde der Baustein aber nicht die Realität widerspiegeln. Selbst wenn in Zukunft auf magische Weise jeder den Diskussionsabschnitt erstellen würde (was nicht passiert), haben wir viele Artikel die den Baustein aber keinen Diskussionsabschnitt haben. Gerade neue Autoren verwirrt es dann, wenn der Baustein fest behauptet, man würde auf der Diskussionsseite etwas finden. Teilweise reicht der Text im Baustein auch aus (siehe die Beispiele in der Dokumentation).

Man könnte der Vorlage einen "Eintragen"-Link geben, ähnlich wie bei Vorlage:Löschantrag und Vorlage:QS. Allerdings wäre dann der Eintragen-Link zu oft bzw. zu lange da. Die anderen beiden Vorlagen werden substituiert, Vorlage:Belege nicht. --mfb (Diskussion) 23:12, 25. Jun. 2015 (CEST)

Wie gesagt, ich sehe da ein Konfliktpotential. Benutzer wie ich betrachten den Einsatz dieser Vorlage unter der geltenden Verwendungsbeschreibung für gut. Nur wenn die Praxis dadurch bestimmt, daß Benutzer sich an den Text der Vorlage halten, kommt es oft genug zum Streit, der bis zu WP:VM geht, wie heute mal wieder.Oliver S.Y. (Diskussion) 23:18, 25. Jun. 2015 (CEST)

Wer beim Setzen des Bausteins keinen D-Abchnitt anglegt und dort nicht darstellt, was (angeblich) fehlt, der setzt sich der Vermutung aus, willkürlich zu handeln. Derartige Einbindungen des Bausteins gehören m. E. kurzerhand entfernt. ÅñŧóñŜûŝî (Ð) 17:51, 26. Jun. 2015 (CEST)

Bilder in Infobox einfügen

Hallo, Ich möchte gerne ein Bild in eine Infobox einfügen, so wie es bei jeder üblich ist. Im Quelltext lese ich immer, wie diese heißen. Beispiel: "AZO-GROUP-Balken-RGB-20.09.2013.png|180px". Müssen diese Bilder hochgeladen werden? Das verstehe ich nicht so ganz. Die Hilfeseiten bringen mich dazu leider auch nicht weiter. Danke schon mal. --195.243.52.140 10:54, 26. Jun. 2015 (CEST)

Wenn das von dir gewünschte Bild noch nicht auf →Commons oder hier in der →deutschsprachigen Wikipedia vorhanden ist müsste es zunächst hochgeladen werden. →Hilfe:Bildertutorial oder →Spezial:Hochladen. Bitte beachten, dass nicht jedes Logo/Bild/Foto frei benutzt werden darf. →Wikipedia:Bildrechte#Logos. Hilft dir das weiter? --Liebe Grüße, Lómelinde Diskussion 11:39, 26. Jun. 2015 (CEST)

Auf jeden Fall, danke. Ich möchte eine Infobox zu meinem Unternehmen erstellen, da sollte das mit den Rechten ja kein Problem sein. --195.243.52.140 11:48, 26. Jun. 2015 (CEST)

Dieser Abschnitt kann archiviert werden. mfb (Diskussion) 20:24, 30. Jun. 2015 (CEST)

Infobox Sportliga

Hallo, wäre es nicht sinnvoll den Organisator zu nennen? Bsp: League of Legends Championship Series--Motte001 (Diskussion) 13:46, 26. Jun. 2015 (CEST)

Vielleicht, aber inhaltliche Diskussionen bitte auf der Vorlagendiskussion oder bei der zuständigen Redaktion führen. --mfb (Diskussion) 21:41, 26. Jun. 2015 (CEST)

Vorlage {{WartungsURL}}

Mit der {{WartungsURL}} steht eine Vorlage zur Verfügung, die WartungsURLs mit urlencodeten Text erzeugt, die mit Hilfe von Spezial:Weblinksuche auffindbar sind. Die Vorlage ist als Untervorlage gedacht, und kann analog zu WP:Templatetiger Wartungslisten erstellen, die Sekunden-aktuell funktionieren, und genau an der Stelle im Quelltext auffindbar sind, wo der Link generiert wird. Diese Methode habe ich heute etwa verwendet um diese Liste für einen Botauftrag zu generieren: Vorlage:Infobox Schutzgebiet/Botanfrage Frohes Schaffen — Boshomi ☕⌨☺   19:50, 26. Jun. 2015 (CEST)

Interessantes Konzept, wobei urlencode viele Zeichen unleserlich macht und es irgendwie nicht im Sinne der Weblinksuche ist. --mfb (Diskussion) 21:58, 26. Jun. 2015 (CEST)

Das URL-encode ist notwendig um alle Zeichen durchzuschleppen. Man kann das ja leicht wieder decoden, allerdings derzeit nicht mit einfachen Boardmitteln. Vielleicht sollten wir noch eine LUA-Vorlage erstellen, mit der der Output von Spezial:Weblinksuche URL-decodet wird. Dann hätten wir die Parameterwerte direkt angezeigt. Auch ein User-Script für diesen Zweck wäre denkbar. Frohes Schaffen — Boshomi ☕⌨☺   22:03, 26. Jun. 2015 (CEST)

Anmerkung: Besonders nützlich ist dieses Konzept für Vorlagen, die mehrfach in einem Artikel vorkommen können, da man damit genau die Einbindung im Artikel ermitteln kann, die das Problem verursacht, und man nicht x Vorlageneinbindungen im Artikel durchsuchen muss bis man die Stelle findet. Frohes Schaffen — Boshomi ☕⌨☺   22:10, 26. Jun. 2015 (CEST)

Ja, dass man manche Sonderzeichen kodieren muss ist klar, aber vielleicht kann man das etwas sparsamer gestalten. Kann Lua auf Spezialseiten-Ergebnisse zugreifen? Das wäre toll. Mehrere Probleme findet man mit den sonstigen Wartungslinks auch, nur zusätzlichen Text kann man dort nicht anhängen. Wobei das Durchsuchen des Quelltextes nicht die benutzerfreundlichste Methode ist. Hier wäre eine css-Klasse, die man sich auf Wunsch anzeigen lassen kann, sinnvoller. --mfb (Diskussion) 22:48, 26. Jun. 2015 (CEST)

Vorlage:GraphChart

Könnte die Vorlage so erweitert werden, dass sie als x-Werte auch Datumsangaben wie 01-04-2014 oder 01.04.2014 frisst und verdauen kann? 85.212.60.110 20:04, 30. Jun. 2015 (CEST)