Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 42 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten.

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

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

WikiProjekt Vorlagen

• Vorlagen-Werkstatt
• Kategorisierung der Vorlagen
• Bugs mit Vorlagenbezug

Hilfeseiten

• Vorlagen
• Vorlagen­programmierung
• Vorlagen­spielwiese
• Vorlagen­dokumentation
• Vorlagen­beschränkungen

Vorlagen-Entwicklung

• Entwicklungsumgebung
• Testumgebung
• Vorlagen expandieren^?
• Wikipedia:Lua/Werkstatt

Hallo, gibt es eine Idee wie man einen Paragraph in der Infobox:Bauwerke einbinden kann? Ich denke, gerade bei einem denkmalgeschützte Gebäude ist ein Paragraph unabdinglich. Und eine Vorlage für denkmalgeschützte Gebäude habe ich nicht gefunden. lg --^¿! ‏.א.מ.א‎ 12:47, 31. Aug. 2020 (CEST)Beantworten

Möglich ist vieles. Ich frage mich nur, was du damit bezwecken möchtest? Für mich vorstellbar wäre z.B. ein eigener Parameter zu Denkmälern an sich (wenn nicht schon vorhanden). Rechtsthemen in Infoboxen ohne entsprechenden Bezug eines Artikels zum Gesetz erachte ich thematisch für falsch. --darkking3 ^Թ 12:21, 18. Sep. 2020 (CEST)Beantworten

Hallo, nach Umstellung der URLs wurde die Vorlage:GAMEO wohl nur unvollständig umgestellt. Fehlerbeispiele auf der dortigen Disku. Was die geneigte Leserschaft mit den alten und neuen Parametern eigentlich machen soll, bleibt in der Doku für mich letztlich schleierhaft. Dank schon mal von --Wi-luc-ky (Diskussion) 01:15, 4. Sep. 2020 (CEST)Beantworten

Würde gerne die Vorlage aus en:biodatabase in der deutschen Wikipedia sehen. Müssen die Begriffe da wirklich übersetzt werden? Wäre eine Vereinheitlichung. Gebrauch z.B in https://en.wikipedia.org/wiki/UCSC_Genome_Browser

Vorlage:Infobox biodatabase --Tieger (Diskussion) 22:49, 7. Sep. 2020 (CEST)Beantworten

en:Template:hlist gibt es in 99 Sprachen. Möchte die deutschsprachige Wikipedia vielleicht die 100. werden? Ich bin in der Skriptsprache nicht so bewandert, würde aber eine Übernahme versuchen, schöner wäre es aber, jemand könnte mir unter die Arme greifen. Sinnvoll ist die Vorlage etwa bei Titellisten wie etwa bei S&M2. Das erleichtert die Arbeit ganz enorm, wenn man das direkt aus en: übernehmen kann.--Iconicos (Diskussion) 18:47, 8. Sep. 2020 (CEST)Beantworten

Also, mindest unter einem solchen kryptischen Namen sicher nicht.

Weiterhin merkst du an dem Umstand, dass wir anderthalb Jahrzehnte ohne sowas ausgekommen sind, dass wir es eigentlich überhaupt nicht brauchen.

Wir haben eine etwas andere Strategie in Syntaxfragen: Wir schreiben die Syntax wo immer möglich direkt und explizit, und verbasteln die nicht erst noch wieder in andere Konstrukte, und am Ende ist es komplizierter und für die nachfolgenden Bearbeiter sehr viel unverständlicher als es direkt anzugeben und nicht immer neue Sprachelemente für die Bearbeitung erlernen zu müssen – „erleichtert die Arbeit ganz enorm“ gilt immer nur für den der es eingebaut hatte und die Handvoll Leute die sich damit auskennen; für alle anderen wird es hingegen massiv erschwert bis unmöglich gemacht.

Was „Titellisten“ und die Formatierung von Musik-Artikeln und dein Beispiel S&M2 angeht so haben wir für diesen Bereich eigene Standards, die sowas nicht verwenden, und zigtausende „Titellisten“ in KISS – keep it simple and stupid. Reicht.

Ob es 99 oder 999 andere Wikis geben würde ist absolut unerheblich.

Vorsorglich weise ich darauf hin, dass weder du noch irgend jemand der das irgendwo dann doch verbaut haben sollte mit Unterstützung aus den Werkstätten und Support für die damit erstellten Artikel rechnen kann.

VG --PerfektesChaos 19:43, 8. Sep. 2020 (CEST)Beantworten

Oh danke. Hier erledigt. Und ciao.--Iconicos (Diskussion) 20:00, 8. Sep. 2020 (CEST)Beantworten

Ist das peinlich. Die en-WP hat die Vorlage auf 161.000 Seiten eingebunden, und hier schreiben Ahnungsloseunbeschreiblich Hilfsbereite, das könne man nicht brauchen, offenbar ohne Kenntnis der entsprechenden Artikelerstellung. Ich schäme mich manchmal für dieses Projekt.--Iconicos (Diskussion) 20:11, 8. Sep. 2020 (CEST)Beantworten

Ich habe die jetzt angelegt, und sie muss genauso heißen, wie sie in allen anderen Sprachen heißt, damit Übernahmen einheitlich möglich sind, ähnlich wie bei Template:cite web. Und stell ruhig einen LA, ich fechte das durch bis zum letzten.--Iconicos (Diskussion) 20:20, 8. Sep. 2020 (CEST)Beantworten

Gibts wahrscheinlich noch css-Styles zu, schaue ich mir an.--Iconicos (Diskussion) 20:23, 8. Sep. 2020 (CEST)Beantworten

Wahrscheinlich möchte mir auch niemand erzählen, wie die Styles wirksam werden, aber gut, kommt Zeit, kommt Rat. Vorerst reicht mir das so, damit ich die Listen nicht jedesmal in aufwendiger Kleinarbeit umarbeiten muss.--Iconicos (Diskussion) 20:56, 8. Sep. 2020 (CEST)Beantworten

Deutsch ist immer etwas anders und nicht immer besser, auch wenn es einige Aktivisten so darstellen. Also überträgt man Vorlagen unter selben Namen, verändert aber Funktionen und Parameter oder man bastelt fix was Anderes zusammen, was nicht mehr kompatibel ist. Das macht Freude, wenn man Artikel ins Deutsche übersetzt. Den Text übersetzen ist ein Klacks. Mit den Links auf passende Lemas in deWP geht das auch noch gut. Aber die Arbeit beginnt richtig, wenn es an die Vorlagen geht. Da passt es nur selten, wie z.B. beim o.g. Cite web (wundert mich, das das noch keinen Verschlimmbesserer gefunden hat.). Doch Vorlage:Hlist

Mit den richtigen Styles wird sie dann schon horizontal, display:inline ist gefragt. Verwenden hierzupedia auch schon so einige Vorlagen (siehe zB Vorlage:Subpage/styles).–XanonymusX (Diskussion) 17:51, 11. Sep. 2020 (CEST)Beantworten

Mit der Aussage "die Vorlage muss genauso heißen, wie sie in allen anderen Sprachen heißt, damit Übernahmen einheitlich möglich sind", wirst du hier nicht weit kommen, denn es gibt hier nunmal gewisse Regeln zur Benennung von Vorlagen und die legen Wert darauf, dass die Benennung möglichst Allgemeinverständlich ist, damit User die hier einen Artikel bearbeiten, der die Vorlage nutzt, möglichst schnell Wissen, welchem Zweck die Vorlage und ihre einzelnen Parameter dienen. Das mag beim Übertragen von Artikeln hinderlich sein, allerdings geschieht das in der Regel einmalig, sodass eine Anpassung der Vorlagen währenddessen ja durchaus zumutbar ist (zumal sie anders als die Anpassung von Links sehr oft halbautomatisch über "Suchen & Ersetzen" durchgeführt werden kann, oder man legt einfach ne Weiterleitung an), während das Bearbeiten von Artikeln deutlich häufiger und vor allem durch verschiedene User geschieht.

Ganz abgesehen davon ist es sowieso nicht immer möglich/sinnvoll Artikel 1:1 übertragen, denn grundsätzlich ist jede WP erstmal eigenständig und hat folglich ihre eigenen Vorstellungen wie Artikel in bestimmten Themengebieten aufgebaut sein sollen, eventuell auch andere Relevanzkriterien und ggf. bereits andere Artikel die das Thema schon zum Teil abdecken. Und zudem sollte man die Artikel beim Übersetzen ja auch inhaltlich prüfen.

Jetzt mal zum eigentlichen Thema des Abschnitts:

• Ausgangspunkt scheint (soweit ich das gesehen habe) zu sein, dass Iconicos den Artikel S&M2 aus der enWP zu übernehmen möchte und dieser die Vorlage hlist verwendet, um in der Track Liste eine Abfolge von Namen horizontal aufzulisten. Da die Vorlage bislang in der deWP nicht existiert, hatte er die Idee, die Vorlage aus en zu übernehmen. Das ist auch grundsätzlich nachvollziehbar, denn die Existenz gleichnamiger und funktional identischer Vorlagen erleichtert das Übernehmen von Artikeln enorm (insbesondere wenn die Vorlage entsprechend häufig genutzt wird und folglich die Wahrscheinlichkeit, dass ein zu übernehmender Artikel die Vorlage enthält, sehr hoch ist).
• Was in dieser Argumentation jedoch nicht beachtet wird, ist dass sich die Notwendigkeit einer Vorlage nicht alleine aus der Anzahl der Einbindung in anderen Sprachversionen ergibt, sondern dabei auch die Frage, welche Funktionalität die Vorlage insgesamt hat und was davon im konkreten Anwendungskontext genutzt wird, eine wesentliche Rolle spielt. Handelt es sich dabei um komplexere Formatierungsaufgaben, wie z.B. bei der Vorlage:Literatur, der Vorlage:Titelliste, der Vorlage:Infobox Musikalbum oder der Vorlage:Navigationsleiste Metallica, ist die Nutzung einer Vorlage durchaus sinnvoll; handelt es sich dabei aber um eher triviale Formatierungen, wie das setzten eines Refs oder das Darstellen von mehreren Namen in eine Zeile (wie bei der Vorlage hlist), ist die Frage, ob dafür eine Vorlage (insbesondere wenn sie im Hintergrund ein Lua-Modul nutzt) unbedingt notwendig ist, durchaus berechtigt, denn so etwas lässt sich ohne weiteres in normaler Wikisyntax darstellen, die im übrigen (abgesehen von ein paar übersetzten Schlüsselworten, wie z.B. "Datei" für "File", die nur in der entsprechenden Sprachversionen funktionieren) auf allen Wikis exakt gleich funktioniert und im übrigen auch den Parser schont, denn Vorlagen Expandieren kostet Rechenzeit und der übermäßige Einsatz von Vorlagen kann auch dazu führen, dass der Parser irgendwann aufhört Vorlagen zu expandieren, da es (wie unter dem Bearbeitungsfenster bei "Profilingdaten des Parsers" angegeben) Begrenzungen gibt.
• Anstelle von | Writer2 = {{hlist|[[Cliff Burton]]|[[Dave Mustaine]]|[[James Hetfield]]|[[Lars Ulrich]]}} würde ich bei dem Artikel also (wie in der Doku von Vorlage:Titelliste angegeben und vermutlich in den übrigen 500+ Einbindungen der Vorlage umgesetzt) | Writer2 = [[Cliff Burton]], [[Dave Mustaine]], [[James Hetfield]], [[Lars Ulrich]] schreiben (umwandeln is da übrigens sehr einfach: "{{hlist|" → "", "}}<Zeilenumbruch>| Länge" → "<Zeilenumbruch>| Länge" und "|" → ", " wobei man bei letzterem leider selektiv arbeiten muss und nicht wie bei den beiden anderen einfach auf "Alle Ersetzten" gehen kann kann). Das liefert zwar ein optisch minimal anderes Ergebnis (Cliff Burton, Dave Mustaine, James Hetfield, Lars Ulrich statt Cliff Burton • Dave Mustaine • James Hetfield • Lars Ulrich), spart aber die Vorlageneinbindungen (die an einigen Stellen ohnehin nicht notwendig ist, da dort nur ein Name steht) und damit auch Ressourcen.

Zusammengefasst besteht meines Erachtens der einzige Grund für die Nutzung der Vorlage darin, dass man sich damit bei der Übernahme von entsprechenden Artikeln minimal weniger Aufwand hat. Gegen die Nutzung spricht meines Erachtens, dass die Vorlage (zumindest in diesem Kontext) für völlig triviale Formatierung genutzt wird, die ohne Probleme und wesentlich übersichtlicher per Hand gelöst werden können (wie das übrigens auch in der Doku zu Vorlage:Titelliste angegeben ist). Viele Grüße Patrick Stützel (Diskussion) 17:44, 15. Sep. 2020 (CEST)Beantworten

Der deutlich geringere Aufwand ist Grund und Anwendungsziel, genau wie bei der Vorlage:cite web. Der Aufwand ist nämlich nicht "minimal", sondern aufgrund der häufigen Verwendung in en: ganz beachtlich. Titellisten sind oft lang und verwenden die Vorlage Dutzende Male. So summiert sich ein vermeintlich kleiner Aufwand zu einem großen. Das kann ich sagen, da ich schon häufig Titellisten umgearbeitet habe, was meistens eine nervige Fummelarbeit ist, bei der jede kleine Unterstützung hilft. Auch hier bietet sich der Vergleich zu den anderen Sprachen an, die die Vorlage auch in beinahe allen Fällen unter genau diesem Namen anbieten. Ein Service für die dort offenbar mehr geschätzten Artikelautoren, von denen es in diesem Bereich in de: eh viel zu wenige gibt. Für die styles hatte ich analog zu en: Vorlage:hlist/styles.css angelegt. Ich müsste nur wissen, wie diese korrekt eingebunden und "in Betrieb" gesetzt wird.--Iconicos (Diskussion) 19:15, 15. Sep. 2020 (CEST)Beantworten

Ich habe gestern mal testweise die Vorlage mit dem von mir beschriebenen Vorgehen aus dem Artikel S&M2 rausgeworfen und dabei war meine Erfahrung, dass das mit 3 Suchen & Ersetzen Operationen erledigt ist, wovon 2 (nämlich den Anfang und das Ende der Vorlage zu entfernen) einen Null-Aufwand haben, da das je mit einem Knopfdruck ("Alle ersetzen") erledigt ist, und eine (das Ersetzten der Pipes) etwas lästig ist, da das manuell erfolgen muss. Alles in allem habe ich dafür höchstens 2 Minuten gebraucht und das mit einem Hilfsmittel, dass eigentlich jeder Computernutzer bedienen kann. Mit nem Regulären Ausdruck (auch RegEx genannt) ginge das vermutlich noch schneller, allerdings ist das Schreiben eines RegEx ohne entsprechende Vorkenntnisse ziemlich kompliziert und abgesehen davon funktioniert das nur, wenn das Suchen & Ersetzen des Editors RegEx unterstützt oder man den in ein Skript packt, was aber natürlich Kenntnisse in einer entsprechenden Programmiersprache voraussetzt.

Würde man stattdessen "nur" den Vorlagennamen durch einen etwas Aussagekräftigeren ersetzen, wäre das (komplett ohne RegEx) sogar noch schneller gelöst, denn dafür braucht es (wie beim Umschreiben der einzelnen Parameter von der enWp-Vorlage Track listing auf die deW-Vorlage Titelliste) lediglich eine Suchen & Ersetzen Operation (bzw. eine pro Parameter-Art, die Zahlen können ja bestehen bleiben), die einen Null-Aufwand hat, da das mit einem Knopfdruck ("Alle ersetzen") erledigt ist.

Die (Nicht-)Existenz bestimmter Vorlagen hat übrigens nichts damit zu tun, ob man Artikel-Autoren schätzt, sondern ob man der Ansicht ist, dass aus technischer Sicht für diesen Zweck eine Vorlage notwendig ist. Und rein aus technischer Sicht ist das, was die Vorlage hlist erledigt, so trivial, dass man hier der Ansicht ist, dass dafür keine Vorlage notwendig ist, die ja letztlich für andere Autoren den Quelltext schwerer verständlich macht. Sogesehen ist es übrigens eher ein Zeichen von Wertschätzung für Autoren, wenn man darauf verzichtet den Quelltext mit Vorlagen für Trivial-Syntax aufzublähen, denn grundlegende Syntaxelemente und deren Verwendung kennt ein Autor oftmals sowieso schon (bzw. bekommt vom Visual Editor entsprechende Hilfestellungen) und selbst wenn nicht ist es deutlich einfacher sich grundlegende Syntaxelemente und deren Verwendung zu merken, als Name und Bedienung verschiedener Vorlagen, die nur dazu dienen verschiedene triviale Kombinationen aus grundlegenden Syntaxelementen zu kapseln. Die Vorlage Cite Web ist da übrigens etwas anders gelagert, denn

1. erfordert das, was die aus technischer Sicht macht, definitiv eine Vorlage und
2. ist sie eigentlich Redundant zu Vorlage Internetquelle, weshalb es in der Vergangenheit heftige Debatten gab, die damit endeten, dass cite web (allerdings vermutlich ohne Support aus dieser Werkstatt) bestehen bleiben darf.

Und bezüglich der Styles kann ich dir nicht wirklich weiterhelfen, denn nach einem kurzen Überfliegen des Codes kann ich keine Unterschiede feststellen, die erklären würden, warum die Styles.css nicht wie in enWP automatisch eingebunden wird. Abgesehen davon, gilt: du hast hier entgegen der Vorbehalte von PerfektesChaos bezüglich der Vorlage einfach blind Code aus einem anderen Wiki übernommen, also bist du letztlich derjenige, der dafür verantwortlich ist, dass das ganze funktioniert und wenn es nicht der Fall ist, eine Lösung finden muss. Viele Grüße Patrick Stützel (Diskussion) 13:19, 16. Sep. 2020 (CEST)Beantworten

Man kann es sich noch einfacher machen: Einfach eine Unterseite im BNR erstellen, bei der jeder Parameter entsprechend der Vorlage gefüllt werden kann und diese Seite gleich mit subst: einbinden. Dann reicht ein Durchlauf mit Suchen & Ersetzen, beim Speichern wird ja die Vorlage passend gesubstet. Code müsste ähnlich {{{1|}}}, {{{2|}}}{{#if:{{{3|}}}|, {{{3}}}}} usw. lauten, trivialer geht es nicht. Iconicos hat direkt auch den Grund erkannt, warum es solche Trivialvorlagen in der de.wp nicht gibt: Die Anzahl der Autoren ist hier wesentlich geringer, warum soll man diesen dann noch kryptische Vorlagen aufzwingen? Neue Autoren gewinnt man mit so etwas nämlich nicht, wenn der Quelltext nicht mehr trivial lesbar ist und die Vorlagen dann nur noch durch eine handvoll User wartbar sind. --darkking3 ^Թ 14:24, 16. Sep. 2020 (CEST)Beantworten

Das mit der BNR-Unterseite ist auf jeden Fall ne gute Idee darkking3 und eigentlich universal auf jede Vorlage anwendbar. Noch einfacher wäre es natürlich wenn man einfach die entsprechenden Vorlagen als Dummy anlegen könnte, der sich selbst Substet, allerdings ist das glaube ich technisch nicht möglich. Und mit dem Rest hast du definitiv recht. Einfacher machen es Vorlagen für Trivial-Syntax nur für denjenigen der Artikel überträgt, die diese Vorlage verwenden, für den Rest machen solche Vorlagen nur den Quelltext schlechter lesbar und auch schlechter bearbeitbar, besonders wenn der VE verwendet wird (und insbesondere dann, wenn die Vorlage (wie diese) komplett undokumentiert ist). Viele Grüße Patrick Stützel (Diskussion) 15:50, 16. Sep. 2020 (CEST)Beantworten

Ich brauche keine BNR-Unterseiten, subst-Getippsel etc. sondern möchte die Liste straight away übertragen. Wie bei der Vorlage cite web geht es darum, dass direkte Übernahmen möglich sind. Mit trivial oder nicht trivial hat das nichts zu tun. Die Vorlage frisst kein Brot, wird niemandem aufgezwungen, aber hilft denen, die lange Listen aus en: oder von anderswo übernehmen. Und ich glaube nicht, dass man in der de:WP schlauer ist als überall woanders. Tipp: wenn einem alle Lichter entgegenkommen, ist man selbst der Geisterfahrer. ;) Die Hilfsbereitschaft überschlägt sich hier ja auch wieder, immerhin wissen auch die Keksperten nicht, warum der Code nicht funzt, das beruhigt mich. ;)--Iconicos (Diskussion) 00:30, 17. Sep. 2020 (CEST)Beantworten

Das ist in dieser Angelegenheit genauso wie in verschiedenen anderen:

• Einmalig hat derjenige Spaß und spart vielleicht einige Sekunden, der das in den Artikel einfügt oder erstmals generiert.
• Das nächste Jahrzehnt hindurch und länger bekommen alle anderen Zeck damit und müssen viele Minuten und Stunden aufwenden, damit Dutzende andere Bearbeiter jetzt jeder einzeln erlernen müssen, was hier für eine noch nie gesehene Besonderheit vorliegt, und das danach wegen Unüblichkeit auch sofort wieder vergessen können.
• Gilt genauso wie mit der Einführung kryptischer und vieldeutiger Abkürzungen und Weiterleitungen für Seiten und Parameter. Es hat seinen Grund, warum wir auf längere und selbsterklärende Namen umsteuern – weil sie sich von selbst verstehen und man keine Doku und Kenntnisse des Einzelfalls benötigt, sondern ohne Doku und Programmierung nachvollziehbar wäre, was da passiert. Nebenbei ist das auch robuster und vermeidet offenkundige Fehler, die in kryptischen Notationen unauffällig bleiben.
• Außer der Person, die das mal eingefügt hatte, und oft noch nicht einmal diese selbst, begreift niemand die exotischen, bei uns nicht verwendeten Fremd-Konstruktionen. Es ist aber niemand anders dauerhaft verantwortlich für die korrekte Programmierung und Dokumentation und Beantwortung von Fragen zur Anwendung als der Vorlagen-Ersteller selbst.
• Die fragliche Vorlage soll hier erkennbar nichts anderes generieren als A, B, C, D oder sowas.
  • Das schreiben wir in diesem Wiki direkt in den Artikelquelltext hinein und damit ist der Fall erledigt. Dazu bedarf es keiner Spezialtechnologie und jeder spätere Bearbeiter kann auch mit dem VisualEditor den Text ganz simpel bearbeiten.
  • Anders würde es aussehen, falls die Ergebnisse irgendeines Algorithmus automatisiert formatiert werden sollen und man nicht vorhersagen kann, was und wie viele Elemente aufzuzählen wären.
  • Oder wenn zur Benutzerführung und Barrierefreiheit Benutzeroberflächen besonders gestaltet werden sollen.
• Selbstsubstend die Original-Vorlage einzubinden ist nicht möglich; allerdings kann beim C&P des fremden Quelltextes ein subst: eingefügt werden. Das könnte jedoch gigantischen Syntaxmüll produzieren, wenn da alle möglichen <span> hinzukommen, und das würde wegen der hier erfolgenden CSS-Einbindung zweifellos der Fall sein. Alles das hinterlässt dann nämlich einen riesigen HTML-Syntax-Klumpen in unserem Artikel. Diese Programmierung ist nicht zum substen gedacht.
• Was irgendwelche anderen Wikis machen ist uns insoweit scheißegal; die anderen Wikipedien leben oft davon, dass sie 1:1 Programmierungen von Vorlagen und ganze Artikeltexte aus der enWP übernehmen und keine andere Chance haben als denen blind hinterherzutrotten.

VG --PerfektesChaos 16:13, 16. Sep. 2020 (CEST)Beantworten

Dass Vorlagen allgemein nicht einfach gesubstet werden sollten ist mir durchaus klar. Mir ging es eher darum, dass man den von darkking3 vorgeschlagenen Weg noch etwas abkürzt indem man unter dem eigentlichen Vorlagen-Namen einen Dummy anlegt, der sich von selbst zu A, B, C, D substet, sodass die Vorlageneinbindung beim Übertragen des Artikels quasi automatisch eliminiert wird. Aber das ist ja leider nicht möglich. Und das Thema selbsterklärende Namen kenne ich aus dem Informatikstudium, denn dort wird in Vorlesungen regelmäßig erklärt, dass man jegliche Art von Bezeichnern im Code (also Variablen, Klassen, Methoden, Parameter, ...) möglichst selbsterklärend benannt sein soll, weil das auch einem selbst die Arbeit enorm erleichtert, wenn man mal einige Wochen nicht am entsprechenden Code gearbeitet hatte. Viele Grüße Patrick Stützel (Diskussion) 17:08, 16. Sep. 2020 (CEST)Beantworten

Was irgendwelche anderen Wikis machen, ist vielen nicht *****egal, naja gut, dem harten Kern der de:-Nerds, aber ganz ehrlich, ich gehe lieber mit 99 anderen Sprachversionen als mit dieser arroganten de-Tour. Und wenn die Vorlage niemand begreifen würde, wäre sie nicht in en: 161.000 Mal verwendet, oder haben die schlauere User? (Ich denke, hier sind die ganz Schlauen? ;)) Hier wird auch niemand gezwungen, sie zu verwenden, aber wenn sie nur einem halben Dutzend Leuten mal hilft, hat sie den Sinn erfüllt.--Iconicos (Diskussion) 00:30, 17. Sep. 2020 (CEST)Beantworten

Dann habe ich mal 2 Fragen an dich zu deinen beiden Antworten vom 17. September um 00:30 Uhr:

1. Nehmen wir mal an, es laufen 99 Leute auf eine Klippe zu. Würdest du ihnen dann folgen?
2. Dürfte jemand, der in einem Artikel hier in der deWP auf diese Vorlage trifft, die Vorlage entsprechend ersetzen?

Viele Grüße Patrick Stützel (Diskussion) 11:26, 17. Sep. 2020 (CEST)Beantworten

Suizid wegen Hlist? Da wird doch die Bedeutung dieser Minivorlage überschätzt... ;) Und wie gesagt, niemand wird gezwungen, sie zu verwenden. Wenn irgendwann noch jemand die Styles fixt, fällt die Verwendung nicht auf, und wenn sie irgendeinen Puristen tatsächlich im Code stört und er begründet eine andere Lösung bevorzugt, bitte. Ganz ehrlich aber glaube ich nicht, dass das passiert, cite web bleibt auch meistens im übersetzten Artikel (Stand heute genau 81.562 Mal) und keiner merkts.--Iconicos (Diskussion) 19:13, 17. Sep. 2020 (CEST)Beantworten

(Nach BK) Was ich an dieser Stelle gezogen habe, war ein Vergleich um dich auf die Absurdität deiner Argumentation für die Vorlage hinzuweisen, denn dieser Argumentation nach muss man etwas, dass 99 andere machen, unbedingt selbst auch machen. Und genau das ist eben (anders als von dir behauptet) nicht sinnvoll.

Und Cite Web ist eine ganz andere Baustelle, denn

1. erfordert das, was die aus technischer Sicht macht, definitiv eine Vorlage (anders als hier, wo die Vorlage (wie bereist mehrfach ausgeführt) rein technisch völlig überflüssig ist und ausschließlich der Bequemlichkeit des Übernehmenden dient)
2. ist sie (soweit ich das weis) die einzige Vorlage der Cite-Familie (ja z.B. in en gibts da noch ein paar mehr), die hier Bestand hatte. Alle anderen wurden entweder gelöscht oder nach Debatten um andere Vorlagen dieser Art schlicht nicht übernommen.

Viele Grüße Patrick Stützel (Diskussion) 09:37, 19. Sep. 2020 (CEST)Beantworten

Absurd ist nur das Vorgehen gegen eine simple Hilfsvorlage, die bei bestimmten Zwecken nützlich ist. Ein Service für Autoren (und natürlich zugleich Leser) ist keine Bequemlichkeit sondern Sinn und Zweck von Vorlagen im Allgemeinen, ebenso wie übrigens dieser Seite. Ideologie und Purismus sind überflüssig. Und dass es die anderen Cite-Vorlagen nicht gibt, ist nichts womit man sich rühmen kann sondern fällt mir immer wieder bei Übernahmen störend auf.--Iconicos (Diskussion) 17:23, 19. Sep. 2020 (CEST)Beantworten

Für welchen Zweck (abgesehen von der Vermeidung der ach so anstrengenden und unmöglich zu vereinfachenden Arbeit, die Vorlage bei der Übernahme eines entsprechenden Artikels zu ersetzen) ist die Vorlage denn konkret nützlich? Und warum sollte man eine Vorlage einsetzen, wenn es schlicht nur darum geht, eine beliebige Menge an Eingaben nacheinander in eine Zeile zu schreiben (was mit reiner Wikisyntax definitiv nicht länger dauert, als mit der Vorlage)?

Für Autoren die Artikel, die diese Vorlage nutzen, aus anderen Wikis übernehmen mag das vielleicht ein Service sein, für alle anderen ist das eher ein Nachteil, da sie erstmal lernen müssen, was denn diese kryptische undokumentierte Vorlage bewirkt. Dem Leser dagegen ist es ziemlich egal, wie die Aneinanderreihung von Namen in der Titelliste entsteht.

Und bezüglich cite: das hat nichts mit rühmen zu tun, sondern war schlicht ein Hinweis darauf, dass dein Verweis auf cite web hier nicht unbedingt besonders hilfreich ist. Und zudem hast du da offenbar den ersten Teil übersehen, der erklärt, worin der Unterschied zwischen cite web und dieser Vorlage liegt. Viele Grüße Patrick Stützel (Diskussion) 18:31, 19. Sep. 2020 (CEST)Beantworten

Diese Vorlage ist völlig überflüssig. Genaueres kann man im von mir gestellten Löschantrag nachlesen. Weitere Diskussionen also bitte dort als LD. ÅñŧóñŜûŝî (Ð) 00:04, 19. Sep. 2020 (CEST)Beantworten

Weil sie überflüssig ist, gibt es sie auch weltweit. Alle anderen Wikis sind dumm, nur de: hat den Stein der Weisen. Geisterfahrer, überall Geisterfahrer! LOL.--Iconicos (Diskussion) 17:23, 19. Sep. 2020 (CEST)Beantworten

Jedes Wiki ist erstmal eigenständig und hat daher seine eigenen Regeln. Und in der deWP hat man (wie von PerfektesChaos weiter oben ausgeführt) eben festgelegt, dass Vorlagen für triviale Formatierungen (wie in diesem Fall) schlicht unerwünscht sind, weil sie die Bearbeitbarkeit erschweren (insbesondere wenn es absolut keine Doku gibt, wie in diesem Fall) ohne dem Bearbeiter eine komplexe Aufgabe (z.B. die korrekte Formatierung einer Literaturangabe oder einer Internetquelle, bzw. die einheitliche Formatierung einer Infobox oder Navileiste bzw. die Sicherstellung einer Barrierefreien Navigation) abzunehmen. Wenn dir das nicht passt, kannst du gerne eine Grundsatzdiskussion anstoßen, allerdings musst du dabei damit Rechnen, dass dir ein ziemlich rauer Wind entgegenwehen wird.

Ach ja, es wäre übrigens mal sehr interessant zu wissen, seit wann es die Vorlage in den verschiedenen Wikis außerhalb der enWP gibt, warum sie dort erstellt wurde und in welchem Kontext sie dort genutzt wird. Viele Grüße Patrick Stützel (Diskussion) 18:31, 19. Sep. 2020 (CEST)Beantworten

Ich weise auch darauf hin, dass hlist in enWP nach wie vor hauptsächlich über die Common.css gestylt wird (siehe en:MediaWiki:Common.css, „.hlist“ kommt da stolze 62-mal vor). Sinnvoll und voll-funktionell eingesetzt wird das System hierzupedia wie gesagt in Vorlage:Subpage/styles, ich werde es vermutlich auf längere Sicht auch in der Vorlage:Erweiterte Navigationsleiste einbauen.

Aber wie schon angedeutet wurde, gibt es absolut keinen Grund, diese Vorlage im konkreten Fall einzusetzen, auch wenn sie funktionieren würde, denn die Einträge sollen durch Kommata getrennt werden. Und selbst wenn aus irgendeinem Grund Bulletpoints in Einzelfällen sinnvoller wären (vielleicht, wenn mal ein „XY, jr.“ vorkommt, und man die Namensabgrenzungen verdeutlichen will), würde man diese in den Text schreiben (•), dann kann man das auch schön aus dem Artikeltext kopieren, wenn man es weiterverwenden möchte. Welchen Vorteil hingegen reine CSS-Trenner hier haben sollten, wurde bislang nicht erklärt.–XanonymusX (Diskussion) 19:13, 19. Sep. 2020 (CEST)Beantworten

Ich möchte darauf hinweisen, dass die Diskussion wegen des LAs auf der LD-Seite geführt werden sollte, damit es für Administratoren übersichtlich bleibt. ÅñŧóñŜûŝî (Ð) 14:42, 27. Sep. 2020 (CEST)Beantworten

Diese Vorlage funktioniert zumindest für Spielerprofile nicht mehr, da der Kicker seine Website umgestellt hat. Das System der Kicker-Datenbank wurde offenbar stark verändert wurde: Statt einer zahlenbasierten ID wird jetzt Vor- und Nachname verwendet. Beispiel Jürgen Klinsmann: Dort wird aktuell im Weblinks-Abschnitt das Format {{Kicker|377}} verwendet. Das führt zur Seite https://www.kicker.de/profil-377/spieler. Sein Profil liegt inzwischen aber tatsächlich auf dieser Seite: https://www.kicker.de/juergen-klinsmann/laufbahn. Gibt es eine Möglichkeit, das anzupassen? -- Chaddy · D 15:19, 12. Sep. 2020 (CEST)Beantworten

das sollte ohne Probleme möglich sein. Stellt sich nur die Frage, wer die ganzen Einbindungen kontrolliert und ggf. ändert? GGf. deshalb, weil man aus dem Seitennamen sicherlich auch einen passenden Link erzeugen kann. --darkking3 ^Թ 10:40, 15. Sep. 2020 (CEST)Beantworten

M-B hat sich bereits an einer Reparatur versucht ([1]). Evtl. geht es aber ja auch noch besser.

Das ist das Problem. Man kommt wohl nicht umhin, alle Einbindungen manuell zu korrigieren. Und wenn der Kicker mal wieder seine Datenbank umstellt, muss das wohl erneut getan werden.

Siehe auch die Diskussion im Fußball-Portal. -- Chaddy · D 14:36, 15. Sep. 2020 (CEST)Beantworten

naja, gesprochene Namen statt ID's haben ja zuerstmal den Vorteil, dass man den Seitennamen bei uns für eine Verlinkung nutzen kann. Mit {{PAGENAME}} und enstprechender Stringbehandlung lässt sich da sicherlich vieles an Aufwand sparen. Lasst das Abarbeiten bitte einen Bot machen, der ggf. euch die Fehlerfälle für eine händische Prüfung auflisten kann. Dann wäre eine Einbindung ala {{Kicker}} möglich. Am besten Benutzer:Hadibe als Ersteller der gesamten Vorlagensystematik ansprechen, wie damit umzugehen ist. Ggf. hat er ja schon etwas Passendes dazu in der Systematik in petto. --darkking3 ^Թ 16:07, 15. Sep. 2020 (CEST)Beantworten

Wenn das ein Bot übernehmen kann wäre das natürlich super! -- Chaddy · D 20:10, 15. Sep. 2020 (CEST)Beantworten

Auf mich wirkt die Vorlage ziemlich aufgebläht. Ich habe mir das jetzt nicht im Detail angeschaut, aber Wikidata sollte man nicht einmal von 12 bis Mittag über den Weg trauen. Besser, man arbeitet ausschließlich mit direkt angegebenen Parameterwerten. ÅñŧóñŜûŝî (Ð) 00:25, 16. Sep. 2020 (CEST)Beantworten

@Hadibe: Danke für die Anpassung. Ich habe noch einen Bindestrich entfernt, jetzt funktioniert es mit Eingabe {{Kicker}} in fast allen Artikeln. In allen Artikeln ist jedoch noch die Einbindung {{Kicker|Zahl}}. Am besten entfernt ein Bot alle diese Zahlen, für den Moment könnte man die Vorlage aber bestimmt auch noch so anpassen, dass die Eingabe der Zahl keinen Einfluss auf den Output hat, da müsste dann nochmal jemand ran. -- M-B (Diskussion) 12:29, 16. Sep. 2020 (CEST)Beantworten

Deine Zurücksetzung wundert mich, wieso ist der Bindestrich erforderlich? Die Anwendung von {{Kicker}} bei Robert Lewandowski führt jetzt zum fehlerhaften Link kicker.de/robert-lewandowski-/spieler. Richtig wäre kicker.de/robert-lewandowski/spieler, so wie es vor deinem Revert erzeugt wurde. -- M-B (Diskussion) 12:45, 16. Sep. 2020 (CEST)Beantworten

@M-B: Jetzt funktioniert die Vorlage auch in reiner Textform wie von Dir getestet. Vorhin das war nur der Notbehelf für Verwendungen mit einer Zahl. Die wenigen Text-IDs fielen somit durch das Raster. Die Weltfussball- oder Fussballdaten-IDs könnten durchaus zur Ersetzung verwendet werden. Die Frage ist wie doppelte Namen behandelt werden. Des Weiteren werden aktuell keine Namen mit Umlauten unterstützt. --Hadibe (Diskussion) 14:57, 16. Sep. 2020 (CEST)Beantworten

• @Umlaute:
  • Darf ich mal Vorlage:cducsu.de anempfehlen? Die machen auch irgendwie sowas.
• @Altes Format
  • Bot-Lauf kann man machen, muss man nicht.
  • Ich kann WSTM gern beibiegen, Altbestäde zu bereinigen.
  • Ich würde anempfehlen, statt bisher 1=ID= einen neuen Parameternamen einzuführen, etwa Code=, und in diesen neuen Parameter die Fälle hineinzuschreiben, in denen sich nicht aus dem Lemma die URL herleiten lässt; etwa bei komplizierteren Namen, oder wenn mehrere Einbindungen in einem Artikel stehen, in dem es nicht nur um den einen Spieler ginge. Mit einem separaten Parameter lässt sich ein Migrationsprozess robuster steuern als wenn alles auf denselben und auch noch zwei Namen liegt.
  • Alte Einbindungen stören nicht dramatisch, werden dann halt ignoriert.

Viel Spaß --PerfektesChaos 15:21, 16. Sep. 2020 (CEST)Beantworten

@Hadibe: Die Vorlage funktioniert aktuell nur, wenn man manuell {{Kicker|robert-lewandowski}} eintippt und genau das wollten wir ja umgehen. -- M-B (Diskussion) 19:05, 16. Sep. 2020 (CEST)Beantworten

@M-B: Soweit korrekt. Was hast du denn vor? Oben klang es so als ob aus dem Lemma eine ID generiert werden soll, die ein Bot dann einsetzt. Damit die Links überhaupt erstmal funktionieren, habe ich diese automatische Erzeugung mit in die Vorlage eingebaut, aber das würde ich nicht zum Dauerzustand werden lassen. Dann lieber die Übernahme der IDs aus Wikidata – sofern die dann irgendwann mal aktualisiert wurden, denn dort stehen auch noch die Zahlen-IDs. --Hadibe (Diskussion) 23:22, 16. Sep. 2020 (CEST)Beantworten

Mir hat diese Version gut gefallen, denn da hat die Einbindung {{Kicker}} in Artikeln funktioniert. Sicher gibt es Spieler, bei denen das nicht klappt, aber damit wären schon mal sehr viele Probleme gelöst. Wünschenswert wäre noch, dass die Vorlage aktuell eine ID einfach ignoriert, der erste Parameter also gar nicht beachtet wird. Dann würden 95% aller Einbindungen nämlich wieder funktionieren. Die IDs könnte man dann noch sukzessive entfernen. -- M-B (Diskussion) 00:39, 17. Sep. 2020 (CEST)Beantworten

Diese Version war unvollständig, die gibt es nicht mehr zurück. Soll die Vorlage denn gar keine Pflichtparameter mehr haben? Das wäre die erste Fußballvorlage, die so funktioniert. Ich bin mir nicht sicher ob die Linkherstellung allein aus dem Lemma dauerhaft funktioniert, deshalb würde ich lieber auf Wikidata zurückgreifen. Wenn das aber so gewünscht wird, kann man das auch schnell einbauen. --Hadibe (Diskussion) 06:35, 17. Sep. 2020 (CEST)Beantworten

Meine persönliche Vorstellung wäre, dass ein Parameter nur gesetzt wird, wenn der Link vom Lemma abweicht. Bei Robert Lewandowski würde {{Kicker}} also zu kicker.de/robert-lewandowski/spieler führen, das kriegen wir ja hin. Einen Parameter soll man nur dann setzen müssen, wenn das nicht zum richtigen Ziel führt. Wir haben beispielsweise in den deutschen Bundesligen zwei Spieler namens Patrick Herrmann. Beim 1988 geborenen würde {{Kicker}} funktionieren, beim anderen sollte man meiner Vorstellung nach {{Kicker|patrick-herrmann-2}} eintragen, um nach kicker.de/patrick-herrmann-2/spieler zu gelangen. Aber das ist wie gesagt meine Vorstellung, ich mache nochmal im Fußballportal auf diese Diskussion aufmerksam und dann bekommen wir hoffentlich noch ein paar Meinungen. -- M-B (Diskussion) 11:41, 17. Sep. 2020 (CEST)Beantworten

Ist denn die Vorlage schon geändert? Hab heute zufällig den Artikel Niklas Dorsch aufgerufen und weil dort die Vorlage Kicker drinsteht, wollte ich sie aufgrund der bekannten Problematik ändern. Aber obwohl in der Vorlage noch die ID steht, wird man bei Nutzung auf die richtige neue Kickerseite mit https://www.kicker.de/niklas-dorsch/spieler weitergeleitet. --Nordprinz (Diskussion) 15:36, 21. Sep. 2020 (CEST)Beantworten

Ja, wurde heute umgesetzt. Eine ID aus Zahlen hat nun keinen Einfluss mehr auf den Output. Wird als Parameter jedoch Text gesetzt, so wird der Link entsprechend angepasst, so wie beispielweise beim 1991 geborenen Patrick Herrmann, bei dem {{Kicker|patrick-herrmann-2}} zum gewünschten https://www.kicker.de/patrick-herrmann-2/spieler führt. -- M-B (Diskussion) 00:33, 22. Sep. 2020 (CEST)Beantworten

Und genau wegen des angeführten Beispiels Patrick Herrmann würde ich auch zukünftig gern die Parameter wieder gefüllt sehen, damit man weiß ob der Link nur zufällig richtig kontruiert, oder ob die verlinkte Seite auch schon getestet wurde. Für sofort haben wir zumindest erstmal wieder funktionierende Links, daher habe ich auch die Vorlagendoku so belassen. Einen neuen Parameter würde ich eben nicht einführen, es war ja der Zweck der Metavorlage einen einheitlichen Aufbau bei allen Fußballvorlagen zu schaffen. Man könnte höchstens noch eine generelle Abfrage für alte ID-Formate einbauen, denn es betrifft ja nicht nur {{Kicker}}, sonder auch {{Fussballdaten}}, {{Svenskfotboll.se}} oder {{Mackolik}}. --Hadibe (Diskussion) 11:42, 22. Sep. 2020 (CEST)Beantworten

Ich denke nicht, dass es zwingend einen Parameters bedarf. {{Commons}} kommt bspw. auch ohne aus, man kann trotzdem einen setzen. Nur sollte das immer der Vorlagensetzende prüfen. Und genau da vermute ich mal euer Problem. Es muss von Hand einmalig geprüft werden, ob das Linkziel der "Eingabe" (oder eben {{PAGENAME}}) entspricht. Vielleicht findet sich ja jemand mit einem Bot, der dies durchführen kann und z.B. mindestens das Geburtsjahr abgleicht und euch dann eine Liste anlegt. --darkking3 ^Թ 16:10, 22. Sep. 2020 (CEST)Beantworten

Ich bin dabei, im Tischtennisbereich die veraltete Vorlage dts zu eliminieren. Nun habe ich auch in Julianisches Datum die Beispiele überarbeitet. Im letzten Beispiel, welche die aktuelle Zeit anzeigt, müsste die Vorlage DatumZelle verwendet werden. Was mir nicht gelingt. Kann das jemand übernehmen? Gruß --tsor (Diskussion) 20:00, 13. Sep. 2020 (CEST)Beantworten

inzwischen erledigt. -- hgzh 13:47, 14. Okt. 2020 (CEST)Beantworten

Hallo, in der Vorlage:Infobox Bahnhof werden die Weblinklabels nicht richtig dargestellt (URL-encode), bspw. bei Bahnhof Berlin Südkreuz. Weitere Bspp. werden in der Disku von anderen Nutzern genannt. Der Vorlagenersteller hat auf Anfrage hin nichts unternommen. Danke fürs Drüberschauen und Fixen, --Wi-luc-ky (Diskussion) 22:41, 14. Sep. 2020 (CEST)Beantworten

Schau mal on es so besser ist. --Liebe Grüße, Lómelinde Diskussion 10:36, 15. Sep. 2020 (CEST)Beantworten

Noch eine Anmerkung:

• die IDs für Orte mit Klammerangaben funktionieren anders da ist die ID = komplette URL anders zusammengesetzt und hinten ohne .html
• Die URL erwartet da eher etwas wie Blankenburg-Ziffernfolge Das lässt sich nicht über einen Kamm scheren.

Vergleiche

• https://www.bahnhof.de/bahnhof-de/Berlin-S-C3-BCdkreuz.html Berlin Südkreuz
• https://www.bahnhof.de/bahnhof-de/bahnhof/Blankenburg-28Harz-29-1027376 Blankenburg (Harz) auch erreichbar über https://www.bahnhof.de/bahnhof-de/bahnhof/Blankenburg-1027376
• oder https://www.bahnhof.de/bahnhof-de/bahnhof/Goslar-1020908  Ok Goslar mit Ziffernfolge auch https://www.bahnhof.de/bahnhof-de/bahnhof/Goslar.html  Ok wäre möglich, aber nicht https://www.bahnhof.de/bahnhof-de/bahnhof/Goslar-1020908.html N

Das kann ich also nicht für dich lösen. Das sind zwei unterschiedliche Formate. Und die Klammerlemmata dürfen auch kein Leerzeichen vor der Klammer haben ID=Blankenburg(Harz) würde derzeit zu https://www.bahnhof.de/bahnhof-de/bahnhof/Blankenburg-28Harz-29.html N denn es hat ein ungültiges .html und es fehlt zudem die Ziffernfolge -1027376 --Liebe Grüße, Lómelinde Diskussion 13:51, 15. Sep. 2020 (CEST)Beantworten

Vielen Dank für die gelungene Reparatur in Bahnhof Berlin Südkreuz, Lómelinde (versuchsweise mal ohne Ping; ist es auch so recht?).

Irgendeine URL-Weiche, die sich das richtige Format greift, ist wohl nicht möglich? Dann könnte wohl nur der Webseitenanbieter die URL-Strukturen vereinheitlichen und wäre anzuschreiben, oder? Bei Bahnhof Blankenberg (Meckl) (gerade geändert) hätte das mit den Klammern auch nicht funktioniert.

Was wäre nun als Nächstes zu tun? Gruß, --Wi-luc-ky (Diskussion) 15:06, 15. Sep. 2020 (CEST)Beantworten

Ich weiß es nicht. Wie gesagt, die Klammerlemmata haben eine gesonderte ID mit Ziffernfolge. Man könnte sicherlich über eine komplizierte Abfrage erkennen, dass in der ID Klammern angegeben wurden. Mein Problem dabei ist das dort zu löschende Leerzeichen und der Anhang .html der dann durch die Ziffernfolge ersetzt werden müsste, die wiederum zur Pflichtangabe würde. Sie würde dann aber auch mit in dem Linktext auftauchen.

Hamburg Airport (Flughafen)-1029964 HH-Airport wäre schon recht lang und man müsste das Leerzeichen in diesen Linktext dann gesondert einfügen oder das + aus der erzeugten URL entfernen (wenn man es mit Abstand einfügt), wiederum (Str replace). Das ist mir gerade irgendwie zu kompliziert und ich weiß auch nicht ob es eventuell nach andere Komplikationen gibt. --Liebe Grüße, Lómelinde Diskussion 15:37, 15. Sep. 2020 (CEST)Beantworten

Mit »Hamburg-Airport(Flughafen)« funktioniert es.

Viele Grüße

Altſprachenfreund; 16:37, 17. Sep. 2020 (CEST)Beantworten

Seitens der Deutschen Bahn ist keine Änderung bzw. Angleichung der URL-Strukturen zu erwarten: „Hinsichtlich der einheitlichen Linkstruktur können wir Ihnen mitteilen, dass wir einer stringenten Logik in unserem System folgen. Änderungen sind diesbezüglich nicht geplant.“ (Mail vom 17. September 2020)

Heißt: Entweder wird die Vorlage für diese sehr diversen URL-Strukturen ertüchtigt oder der Parameter muss frei bleiben, ggf. durch schlichte URL-Verlinkung gefüllt werden.

Gruß, --Wi-luc-ky (Diskussion) 11:19, 21. Sep. 2020 (CEST)Beantworten

Hallo, ich habe da eine neue Vorlage:Researchgate gemacht. Ich bin mir unsicher, ob das erwünscht ist. Ich habe sie mal beispielsweise bei Paul Goldberg eingebaut. Ich finde die Publikationslisten bei Researchgate sehr ausführlich (ausführlicher als worldcat), außerdem sind oft die Möglichkeiten zum PDF-Download gegeben. Deshalb fand ich das wünschenswert, obwohl Researchgate natürlich nicht ganz vollständig unkommerziell ist. Wenn es nicht erwünscht ist, bitte mir mitteilen und einfach die Vorlage wieder löschen. --Allexkoch (Diskussion) 11:37, 16. Sep. 2020 (CEST)Beantworten

• Erstmal sehr gut, dass du dich hier gemeldet hast.
• Kommerziell: Egal.
  • Das ist für die Verlinkung und Nutzung als Beleg nicht relevant; egal ob mit oder ohne Vorlage.
  • Bücher kosten auch Geld.
  • Frei zugänglich müssen zumindest eine Zusammenfassung oder Basisdaten sein.
  • Die Inhalte müssen solide sein, woran bei Researchgate kein vernünftiger Zweifel besteht.
  • Überwiegen von Werbung gegenüber Nutzinhalt könnte Ausschlusskriterium sein.
• Programmierung und Dokumentation sind auf den ersten Blick einwandfrei.

LG --PerfektesChaos 12:17, 16. Sep. 2020 (CEST)Beantworten

Es fehlt eine Wartungskategorie zum Vergleich mit P2038 auf Wikidata. Und der Vorlagenname sollte zeigen, dass es um Personen geht und nicht um Organisationen oder Publikationen, die gibts nämlich auf Researchgate auch. Außerdem kann man {{Str replace|{{#invoke:WLink|getArticleBase}} verwenden, dann kann man sich den Parameter "Name" bei Klammerlemmata sparen. 84.137.70.194 19:36, 16. Sep. 2020 (CEST)Beantworten

Vielen Dank für eure Bemerkungen und Hilfe. Leider bin ich technisch fast völlig unbeleckt, so dass ich die Bedeutung der Bemerkungen der IP nicht verstehe, ist für mich wie chinesisch, tut mir leid, ist kein böser Wille von mir, sondern einfach nur Unkenntnis, ich weiß einfach überhaupt nicht was Wartungskategorien sind usw. Zum Parameter Name, den finde ich ganz praktisch, wenn man die Vorlage mal auf einer anderen Seite benutzt, z.B. auf der eigenen Testseite.--Allexkoch (Diskussion) 21:11, 16. Sep. 2020 (CEST)Beantworten

Guten Tag,
ich hatte die Frage vor einiger Zeit schon auf der Diskussionsseite der Vorlage gestellt, scheinbar wird diese aber nicht allzu oft angesteuert. Die Frage stellte bereits vor ein paar Jahren ein anderer User (vgl. Archiv), damals ging auch niemand darauf ein und ist im Sande verlaufen.

In der Vorlage Navigationsleiste wird als Trennzeichen zwischen den einzelnen Verweisen sowohl der Punkt „•“ als auch der senkrechte Strich „|“ aufgeführt. Steht unter Vorlagenparameter noch, dass meist der Punkt „•“ als Trennzeichen Verwendung findet, so ist in der Kopiervorlage der senkrechte Strich (als Parameterwert) eingebettet, wodurch über die Jahre dieser deutlich mehr Verwendung findet als das, meiner Meinung nach, eigentliche Aufzählungszeichen „•“ (vgl. [2], [3] und [4] --- rund 36.500 mal „|“ gegenüber rund 3.800 mal „•“).

In der Vorlage der erweiterten Navigationsleiste, wird unter dem Punkt Kopiervorlagen explizit darauf hingewiesen, dass Listenpunkte mit „•“ (bzw. dem entsprechenden Parameterwert) zu trennen sind. Ich habe jedoch schon des Öfteren erweiterte Navigationsleisten gesehen, in denen ebenfalls der senkrechte Strich Verwendung findet.
Auch wenn die deutsch- und englischsprachige Wikipedien unabhängig voneinander geführt werden, so ist doch anzumerken, dass dort als Trennzeichen in Navigationsleisten automatisch das Aufzählungszeichen „•“ erzeugt wird.

Meine Frage ist nun, ist die Verwendung des senkrechten Striches, wenngleich mehrheitlich verwendet, als fehlerhaft zu betrachten?

Ich persönlich fände diesbezüglich eine einheitliche Gestaltung der Navigationsleisten für erstrebenswert. Weiterhin bin ich der Meinung, dass in Navigationsleisten, in denen Text in Form von Namen, Ländern, Filmtitel oder ähnlichem aufgezählt werden, der Aufzählungspunkt „•“ zum Lesen angenehmer und eine deutlichere Trennung der einzelnen Aufzählungspunkte darstellt, als der senkrechte Strich.

Gibt es eine Möglichkeit dies einmal einheitlich zu gestalten? - Wo und mit wem müsste das abgestimmt werden?

Gruß
JausH (Diskussion) 10:59, 19. Sep. 2020 (CEST)Beantworten

Tatsächlich gibt es einen höheren Sinn, • statt | zu verwenden. Da | mit dem Trennzeichen der Patameter im Konflikt ist, muss statt | stets | eingegeben werden. Schon da ist • deutlich bequemer und übersichtlicher. --Klaus-Peter (^aufund_davon) 13:29, 19. Sep. 2020 (CEST)Beantworten

Ich finde den | besser, weil man den • leichter mit einem Bindestrich verwechseln kann. Beispiel Hamburg-Mitte • Hamburg-Nord. Bei der Version Hamburg-Mitte | Hamburg-Nord ist der Trenner eindeutiger erkennbar.

In der Doku werden beide Varianten als zulässig genannt. Da macht es keinen Sinn, nach eigenem Geschmack von einer zulässigen Version in eine andere zulässige Version zu ändern. --Buch-t (Diskussion) 14:25, 19. Sep. 2020 (CEST)Beantworten

Da muss man schon eine ausgeprägte Sehschwäche haben, um • mit – zu verwechseln. Das ist eher ein Fall für die Ophthalmologie. | und l oder ! wären kritischer und|kann ich bei den „Aufzählungszeichen“ nicht finden, aber da darf man sich mal Lemma „Senkrechter Strich“ oder Pipezeichen genüsslich 'reinziehen und ganz vorsichtig nachdenken. --Klaus-Peter (^aufund_davon) 15:58, 19. Sep. 2020 (CEST)Beantworten

@JausH: Ach herrje, da hast du dir aber fein säuberlich den richtigen Tag für deine Anfrage ausgesucht.

Erstmal die Grundproblematik:

• Wir haben über 40.000 Navileisten.
• Betreut und gepflegt werden diese von den Themengebieten, also von deren Autoren.
• Da gibt es erfahrungsgemäß immer einen gewissen Prozentsatz, der ansagt, in MEINEN Artikeln hat die Navileiste aber so und so auszusehen.
• Wir als Werkstatt sind da machtlos.

Es gibt Grundregeln für das Trennzeichen:

• Es muss von jedem Leser gut als Trennzeichen wahrnehmbar sein.
• Es darf nicht mit dem sonstigen Text und Buchstaben zu verwechseln sein.
• Nicht alle unserer Leser haben Adleraugen, nicht alle sind mit dem Vokabular so vertraut. Die Autoren unserer Artikel wissen sofort, wie die einzelnen Gemeinden, Bands, Automodelle heißen und verfallen leicht dem schweren Irrtum, das wäre für alle anderen Menschen genauso offensichtlich, denen das in unserem Artikel zum allerersten Mal im Leben begegnet.
• Alle Zeichensätze bei unseren Lesern müssen ein verwendetes Schriftzeichen kennen.
• Geeigneter Abstand zum Text, also der Verlinkung davor und dahinter; sollte größer sein als der Abstand zwischen den Wörtern innerhalb einer Verlinkung.
• Was gibt es zur Auswahl?
  • Kuller • ● und eckiger Kuller • erfüllen das erstmal ganz gut.
  • Pipe-Symbol bei normalem Abstand ist eigentlich völlig ungeeignet; beachte die Flüsse: Iller | Ill | Ilz
  • Horizontaler Strich geht verloren zwischen: Frankfurt am Main – Frankfurt an der Oder

Eine alternative Methode wäre auch von wegen Barrierefreiheit interessant:

• Vorlage:Navigationsleiste Vorlagen zur Tabellensortierung
• Arbeitet nicht mit Schriftzeichen.
• Ist auch in der im Juli neugestalten Hauptseite verbaut; es gab drei Bildschirmkilometer um die Frage, welches Trennzeichen in welcher Gestalt in welcher Größe in welcher vertikalen Position verwendet werden solle.

Kurzum: Schwierig, weil es niemanden gibt, der das als Mufti für alle 40.000 Navileisten vorschreiben kann. Es gibt nur gut gestaltete Navileisten und schlechte, aber dafür sind die Autoren in den Themengebieten verantwortlich. Was mit Pipe und normalem Abstand ist immer Murks, egal was zurzeit noch auf irgendwelchen Meta-Seiten rumsteht.

• Totale Einheitlichkeit wird sich nicht herstellen lassen.

VG --PerfektesChaos 17:16, 19. Sep. 2020 (CEST)Beantworten

Zumindest die Vorlage:Erweiterte Navigationsleiste hat sich, bei all ihren aktuellen Unzulänglichkeiten, schon länger auf die Bullets festgelegt. In meinem geplanten Neuschrieb der Vorlage wird sie, nach Vorbild der originalen Navbox, die Bullets auch selbst via CSS erzeugen, sie stehen dann also nicht mehr im eigentlichen Text und werden von Screenreadern nicht mehr vorgelesen (siehe hier die oberen Beispiele). Dauert aber noch, bis das kommt. Gruß–XanonymusX (Diskussion) 13:34, 23. Sep. 2020 (CEST)Beantworten

Mir ist durchaus bewusst, das die Anzahl der bereits existierenden Navi-Leisten den Arbeitsaufwand nicht geraded gering machen. Wäre, da | als Trennzeichen von Auflistungspunkten im Quelltext durch | dargetellt werden muss, ein Ersetzen mittels Bot von | durch • bzw. • nicht eine einfachere Möglichkeit (ich habe von Programmierung leider nicht wirklich Ahnung), wenn man diese austauschen würde.
Mir ist aber auch klar, dass es hierzu mehrere Meinungen und mindestends genau so viele Möglichkeiten diese umzusetzen gibt. Das normale Pipe Symbol, wie es derzeit in den allermeisten Navileisten Verwendung findet, ist in meinen Augen jedoch die ungünstigste Alternative von denen, die zur Auswahl stehen.

@XanonymusX: Das finde ich persönlich eine sehr gute Idee.

Gruß--JausH (Diskussion) 10:27, 27. Sep. 2020 (CEST)Beantworten

Hallo, da die Diskussionsseite zu der Vorlage {{Erledigt|1=~~~~}} sehr gering besucht ist, stelle ich die Frage/Bitte hier in der Kartenwerkstatt. In diese Vorlage kann man eigenen Text reinschreiben (z. B. {{Erledigt|1=Nicht mehr auf der Hauptseite. ~~~~}}). Ich wünsche mir, dass dieser eigene Text besser deutlich wird. Dieser steht direkt hinter dem ersten Satz dieser Vorlage (im Ergebnis) und ist nicht schnell und gut erkennbar. Welche Möglichkeiten fallen euch ein, wie man den eigenen Text in der Vorlage besser hervorheben könnte – ohne, dass jeder Benutzer dies manuell tun muss. Z. B. Fett, kursiv, farbig hervorgehoben oder unterstrichen? --TheAmerikaner (Diskussion) 20:04, 21. Sep. 2020 (CEST)Beantworten

Die Vorlage:Erledigt bietet noch den Parameter |2= an. Dieser wird direkt hinter der Signatur dargestellt, was aus meiner Sicht es auch ganz gut deutlich macht. Die Frage ist natürlich auch, was du damit bezwecken möchtest? Entweder ist ein Thema erledigt oder nicht, mit weiteren Anmerkungen im Baustein löst du ggf. nur noch weitere Diskussionen aus.

P.S.: Du bist in der Vorlagenwerkstatt und nicht in der Kartenwerkstatt. :) --darkking3 ^Թ 08:25, 22. Sep. 2020 (CEST)Beantworten

Unsere Jahresartikel haben am Anfang eine eingeklappte Navigationsleiste (erzeugt durch Vorlage:Jahreskalender) mit der Kalenderübersicht des jeweiligen Jahres (Bsp.: 1974). Während Navis in der Mobilversion (m-Domain) normalerweise standardmäßig ausgeklappt angezeigt werden, wird bei den Kalenderübersichten mobil einfach nur ein Kasten mit der Überschrift angezeigt. So sollte es nicht bleiben. Entweder man bekommt die Navi auch mobil ausklappbar oder gleich ganz ausgeklappt (wobei dann auch das Tabellenlayout aufgebrochen werden muss) oder man blendet den Bereich mittels nomobile aus. Ideen? Gruß–XanonymusX (Diskussion) 20:24, 30. Sep. 2020 (CEST)Beantworten

Ich denke, es wäre besser, die Vorlage von Navileistensyntax (die eigentlich nur für Navileisten gedacht ist) auf Tabellensyntax umzustellen (class="mw-collapsible mw-collapsed"). Ob das die Probleme mit der Mobilversion behebt weiß ich aber nicht. -- Chaddy · D 20:35, 30. Sep. 2020 (CEST)Beantworten

Mobilgeräte haben derzeit einiges an JS-Unterstützung nicht, insbesondere nicht mw-collapsible und Tabellensortierung.

Seit Jahren heißt es, die letzten Hindernisse für beides wären bald ausgeräumt, aber irgendwie ist es noch nicht durchgebrochen.

Persönlich empfehle ich Nichtstun und Abwarten.

Diese Werkstatt kann in dieser Angelegenheit nicht tätig werden.

Mit den Jahreskalender-Betreuern müsste abgestimmt werden, wie es weitergehen soll; ob die sich generell umstellen, die Übersicht für alle immer ausgeklappt zeigen, in anderem Layout woanders oder was.

Sehr viele Bereiche und Köpfe im Projekt sind weiterhin auf nur-Desktop ausgerichtet. Pech. Planlos an Einzelteilen rumzuzotteln bringt auch nichts.

VG --PerfektesChaos 20:55, 30. Sep. 2020 (CEST)Beantworten

Das Problem scheint das display:none im NavContent zu sein. Das wird auf dem Desktop durch die JS-Funktionen überschrieben, mobil stehen diese nicht zur Verfügung und damit bleibt es bei der bloßen Überschrift. Hintergrund dürfte sein, das automatische Ausklappen bei nur einer Navileiste zu verhindern, wobei das eigentlich auch durch den leeren NavFrame davor geblockt wird, oder?

Jedenfalls gibt es Klappereien mobil (noch) nicht – ein weiterer guter Grund, soweit wie möglich darauf zu verzichten – und ein immer ausgeklappter Jahreskalender wäre mobil wohl overkill – da hat jeder ein Kalenderprogramm, das das besser kann. Mein Vorschlag wäre also: mobil entfernen. -- hgzh 10:37, 2. Okt. 2020 (CEST)Beantworten

Ja, da es über 2000 Seiten betrifft, halte ich einen Eingriff „an Einzelteilen“ in diesem Fall schon für gerechtfertigt; die Infoboxen am Anfang der Jahresartikel habe ich jetzt ja auch schon korrigiert, fehlt nur noch der Kalender. @Antonsusi: Du hattest daran mal gewerkelt, hättest du noch eine alternative Idee? Sonst spendiere ich dem Element schlicht ein nomobile. Gruß–XanonymusX (Diskussion) 14:09, 2. Okt. 2020 (CEST)Beantworten

Ich habe keine Ahnung, wie ich diese Tabelle so gestalten könnte, dass es auf dem Smartphone gut aussieht. Es wäre aber wohl möglich, eine stark vereinfachte Version für Smartphone zu erzeugen, wenn es eine Möglichkeit gibt, nach der Client-Hardware zu unterscheiden. ÅñŧóñŜûŝî (Ð) 17:05, 2. Okt. 2020 (CEST) Man könnteBeantworten

Mir ist aufgefallen, dass ich die Infobox Tunnel nicht speichern konnte, weil TemplateData einen Fehler verursachte, der nicht an den Nutzer ausgegeben wird. Ich konnte das in der Vorlage auf die Doku-Unterseite eingrenzen, indem ich die Dokumentation temporär entfernt habe. Am Ende war es in der eigentlichen Doku zwar "nur" ein kleiner Edit, der den Fehler behob. Aber für für Parameter mit gesetztem Standardwert erwartet templatedata offensichtlich eine gesetzte die Typ-Definition. Rückblickend klingt das zwar für mich logisch, aber das sollte auf jeden Fall zu einem für den Nutzer sichtbaren Fehler erzeugen. Würde mich freuen, wenn ihr da mal schaut, ob und wie man da was machen kann. Schließlich wird das sicher nicht das letzte Mal sein, dass soetwas auftreten wird. --darkking3 ^Թ 13:48, 2. Okt. 2020 (CEST)Beantworten

Ich schau mal.

Das sollte eigentlich auf unknown umgefrickelt werden, aber ein leerer String ist „etwas“ und nicht „nichts“, und irgendwie hat es die Fehlerbehandlung nicht ausgelöst.

In der Darstellungsoptik hingegen wird es als „Unbekannt“ ausgewiesen; so sollte es dann auch in die produktive Nutzung eingehen.

Ganz weggelassen hätte es vermutlich geklappt.

VG --PerfektesChaos 13:57, 2. Okt. 2020 (CEST)Beantworten

Habe mittlerweile Gegenmaßnahmen umgesetzt.

• Es gibt eine sichtbare Fehlermeldung für default bei mit ohne type.
• Es wird dann auch kein default mehr nach draußen kommuniziert.

Die Fehlersituatiuon war mir bislang nicht bekannt gewesen.

• Wir schreiben meist gültiges JSON.
• Es scheint mir eher der Umstand gewesen zu sein, dass type als "" angegeben wurde; also nicht ganz weggelassen und auch nicht gültig oder so.
• Die bisherige Logik hatte diese Konstellation nur in der präsentierten Doku verarbeitet, jedoch nichts an dem an die Software übermittelten Wert gemacht.

VG --PerfektesChaos 16:56, 4. Okt. 2020 (CEST)Beantworten

Gerade mal geprüft, Fehlermeldung ist jetzt sichtbar. Das Weglassen von "type": "" erzeugt trotzdem eine Fehlermeldung, somit wäre das weglassen keine wirkliche Option? --darkking3 ^Թ 20:54, 4. Okt. 2020 (CEST)Beantworten

type weglassen geht schon, aber dann auch default weglassen.

Die von dir genannte „Fehlermeldung“ dürfte sich nur auf die optische Darstellung beziehen, wirksam ist dann aber keins von beiden.

VG --PerfektesChaos 17:13, 9. Okt. 2020 (CEST)Beantworten

Die Links zu ICD10-Diagnosen sollten direkt auf die entsprechende Seite fuehren. Dazu habe ich unter Vorlage Diskussion:Infobox ICD#Deeplink nach DIMDI.de ein Beispiel fomuliert. Es waere schoen, wenn sich ein Kundiger der Sache annehmen wuerde. Danke, -- Juergen 217.61.192.41 13:46, 3. Okt. 2020 (CEST)Beantworten

Technisch kann diese Werkstatt hier gerne mithelfen.

Zuvor müssten aber einige andere Geschichten geklärt werden:

• Wikipedia:Redaktion Medizin müsste per WD:RM inhaltlich zu der Verlinkung Stellung nehmen.
• Der charakteristische Namensbestandteil der Vorlage ICD ist eine nicht allgemein verständliche Abkürzung.
  • Sowas fassen wir heutzutage nicht mehr an.
  • Die Vorlage müsste verschoben werden auf einen selbsterklärenden oder entschlüsselbareren Namen.
  • Für den Artikelbestand ändert sich dadurch erstmal überhaupt nichts; das kommt dann nach und nach hinterher.
• Es gibt inzwischen eine neuere Versionsnummer, wenn ich das richtig verstanden habe.
  • Irgendwas wie ICD10 und ICD11.
  • Also müssten vermutlich alle Bestandsartikel auf die neue Version aktualisiert werden, wobei sich ja durchaus inhalltlich was geändert haben könnte. Dass ICD11=ICD10 für alle Diagnosen gäbe irgendwie keinen Sinn, denn wenn alles identisch ist bräuchte man keine neue Version.
  • Es könnte über eine generische Vorlagenprogrammierung nachgedacht werden, die bei grundsätzlich gleichem Design jedoch auffallender optischer Abweichung zwischen 10 und 11 beide Versionen mit derselben Programmierung darstellt.
  • Sowas könnte dann auch gleich mit dem neuen Namen der Vorlage verbunden werden und in den Bestandsartikeln korrekt dargestellt werden.

VG --PerfektesChaos 14:44, 3. Okt. 2020 (CEST)Beantworten

Im Bereich Nürnberg-Fischbach habe ich festgestellt, dass alle Denkmäler auch in Wikidata erfasst sind. Daher stellt sich die Frage, ob es nicht sinnvoll wäre, eine Tabellenspalte zu ergänzen, in der man zu Wikidata verlinken kann.--Hfst (Diskussion) 18:41, 3. Okt. 2020 (CEST)Beantworten

Es gibt andere Denkmallisten-Vorlagen, die eine derartige Verlinkung anbieten.

Das ist aber nicht unsere Entscheidung hier, sondern müsste von den Bayern-Denkmal-Pflegern ausgekaschpert werden.

Und dann halt genauso wie bei den anderen; wenn es dabei Probleme geben sollte, dann gern nochmal wiederkommen.

VG --PerfektesChaos 19:00, 3. Okt. 2020 (CEST)Beantworten

Ok, und wo finde ich die Bayern-Denkmal-Pfleger?--Hfst (Diskussion) 22:19, 3. Okt. 2020 (CEST)Beantworten

Im Wikipedia:WikiProjekt Denkmalpflege, schätze ich. Gruß–XanonymusX (Diskussion) 22:43, 3. Okt. 2020 (CEST)Beantworten

Oder in der Bayern-Redaktion. Hessen haben sowas. VG --PerfektesChaos 16:57, 4. Okt. 2020 (CEST)Beantworten

Gibt es eine Vorlage für Infoboxen Musiker, Komponist oder Künstler im Allgemeinen? Oder wenigstens eine allgemeine Person? Wie konvertiert man am Besten die Infoboxen aus der englischen WP?Tonstudio96 (Diskussion) 01:31, 4. Okt. 2020 (CEST)Beantworten

In diesem Wiki sind Infoboxen für Personen im Allgemeinen unerwünscht; wenn es das bisher nicht gibt dann bringe deine Infos bitte im normalen Artikeltext unter.

Ausnahmen sind lediglich einige Sportler, die nach Gewicht und Körpergröße Technische Daten usw. erhalten haben.

Wir wollen jedoch keine Reduktion von Musikern, Komponisten oder Künstler im Allgemeinen auf Technische Daten. Anders als Sportler, die üblicherweise in einer einzigen Sportart relevant sind und bei denen seltener noch was anderes im Leben passiert, können Musiker, Komponist oder „Künstler im Allgemeinen“ auch gleichzeitig noch Dichter und Politiker und Maler und Schauspieler und Dichterjurist sein. Dann müssten wir pro Person ein halbes Dutzend Infoboxen auflisten, überall würde das Geburtsdatum drinstehen, und wir würden das Lebenswerk nach Art von Viertelwissen in Schlagworten auf Genres klassifizieren und reduzieren. Das ist Menschen nicht angemessen; wir stellen das differenziert im Artikeltext dar. Wikidata und die enWP mögen Menschen so auffassen; wir nicht. Biografische Basisdaten stehen standardisiert im allerersten Satz des Einleitungsabschnitts.

VG --PerfektesChaos 17:06, 4. Okt. 2020 (CEST)Beantworten

In der Vorlage hatte ich hierdurch versucht, alternativ zur Möglichkeit der Angabe des Parameters Zugriff= den Parameter Abruf= einzuführen. Leider habe ich diesen nur zusätzlich zusätzlich einfügen können. Das wurde zurückgesetzt, da man beide gleichzeitig hätte angeben können… Was war falsch?
Ich möchte gern: WENN Parameter ‚Abruf‘ angegeben wurde, DANN verwende diesen, SONST (WENN Parameter ‚Zugriff‘ angegeben ist) verwende den Parameter ‚Zugriff‘. Danke. --Tommes ^✉ 10:19, 5. Okt. 2020 (CEST)Beantworten

Einspruch, siehe Vorlage Diskussion:HLS#Parameter Abruf. --Leyo 10:51, 5. Okt. 2020 (CEST)Beantworten

Kann man nicht die Vorlage so programmieren, dass es nur einen Parameter gibt, sie aber für diesen 2 Parameternamen akzeptiert? --Alpöhi (Diskussion) 12:44, 5. Okt. 2020 (CEST)Beantworten

Kann man, jedoch bleibt aus meiner Sicht Leyo's Einspruch dabei bestehen: Zwei Parameter(namen) für ein und dasselbe. Wenn das für Leyo ok ist, kann ich das auch eben umsetzen. Die Frage ist dann eher, welchem Parameter Vorrang gegeben wird?--darkking3 ^Թ 12:52, 5. Okt. 2020 (CEST)Beantworten

Ich meine sowas wie hier, d.h. mittels #ifexist nur einen (der beiden) Parameternamen akzeptieren, vielleicht kann man das noch besser mit gegenseitigem Ausschluss programmieren, so dass ein Exclisiv-Oder (EXOR) daraus wird und eventuell den Wert des alternativen Parameters ggfl. dem Originalparameter zuweist, so dass am Ende tatsächlich nur einen Parameter(namen) gibt und allenfalls ein Fehler ausgegeben wird, wenn beide Parameternamen benutzt werden. --Alpöhi (Diskussion) 13:00, 5. Okt. 2020 (CEST)Beantworten

darkking3 hat Recht, mein Einspruch aus Gründen der einfachen Wartbarkeit bezieht sich auf diesen Vorschlag. --Leyo 13:40, 5. Okt. 2020 (CEST)Beantworten

Es braucht kein {{#ifexist:. Man könnte auch einfacher {{{abruf|{{{zugriff|}}}}}} schreiben. Nachteil dabei ist allerdings, dass ein gesetzter, nicht-leerer Parameter zugriff bei gesetzten und leerem Parameter abruf ignoriert wird. Das kann man machen, wenn ein Parameter gegen eine neue Bezeichnung ersetzt werden soll. 15.000+ Einbindungen ist dabei jetzt kein Hemmschuh, die {{Infobox Film}} mit entsprechend damals schon mehr Einbindungen wurde auch auf einen anderen Parametersatz umgestellt. Aber mal als Anregung @Leyo: Der Parameter Abruf wurde hier von PerfektesChaos ohne weitere Diskussion eingefügt. Und meine persönliche Meinung hierzu: Die Vorlage selber schreibt abgerufen am xx.xx.xxxx, daher macht der Parameter Abruf für mich mit Bezug auf gesprochene Parameternamen mehr Sinn als zugriff. --darkking3 ^Թ 14:22, 5. Okt. 2020 (CEST)Beantworten

Ich habe nichts gegen eine Änderung des Parameternamens, begleitet von einem Botlauf. --Leyo 14:57, 5. Okt. 2020 (CEST)Beantworten

Ich verstehe weder die Kontroverse hier noch auf der Vorlagendisku.

• Diese Werkstatt wird sich nicht an der Umsetzung beteiligen.
• Die Beteiligten mögen selbst zu einer Lösung finden und wären dann auch ohne diese Werkstatt in der Lage, diese einzuarbeiten.

Generell vereinheitlichen wir die Namen typischer Parameter und schematisieren auch die Namen der Vorlagen selbst.

• Das macht es allen nachfolgenden Bearbeitern und auch den Suchenden und Managern erheblich leichter, als wenn jede Vorlage ihr individuelles Süppchen kocht.
• Abruf= bzw. abruf= ist der für das Abrufdatum zu empfehlende Name.
  • Es hat nur fünf Buchstaben, wenn es mal getippt werden solle. Zugriff wären sieben.
  • Es produziert abgerufen am und ist deshalb intuitiv.
  • „abgerufen am“ ist das gemäß ZR empfohlene Schlüsselwort, das auch den Lesern damit eingängig ist.
  • „abgerufen am“ wird in einer Dreiviertelmillion Artikel im Kontext von Weblinks dargestellt. Es kommt mehr als 100 Mal häufiger vor als jede ganz früher mal benutzte oder spontan ausgedachte Variante. „Zugriff“ gibt es in rund 7.000 Artikeln als „Abrufdatum“ und wird deshalb allmählich angepasst, auch um nicht den Eindruck zu erregen, das hätte eine völlig andere Bedeutung. Leser müssten erstmal vermuten, dahinter würde sich ein geheimnisvoller anderer Sinn verbergen.
• Unter den mit TemplateData ausgestatteten und deshalb frischer gepflegten Vorlagen gibt es
  • 129 mit Parameter Abruf / abruf
    • davon 61 in Migration mit Alias Zugriff / zugriff
  • 14 mit Parameter Zugriff / zugriff (korr von 20; waren noch XML in den Treffern)
• @Alpöhi: „Kann man nicht die Vorlage so programmieren, dass es nur einen Parameter gibt, sie aber für diesen 2 Parameternamen akzeptiert?“
  • Ja, kann man; ist gängige Praxis, und bei 61 Vorlagen zurzeit in Migration.
  • Geht auch sehr einfach; zweiten Namen in die Parameter-Referenz als Rückfallwert reinhängen, und als Alias dokumentieren.
  • Wer ganz toll drauf ist, löst eine Fehlersituation aus, falls beide gleichzeitig mit einem Wert belegt wurden.
  • Es ist auch nicht schädlich, wenn eine Vorlage noch über längere Zeit beide Varianten versteht und nur allmählich migriert.
    • Wer den alten Namen noch im Kopf hat, verursacht kein Problem.
    • Wer den neuen standardmäßigen benutzt, kommt zum Erfolg.
    • In persönlichen Kopiervorlagen, Benutzer-Textdateien, alten Diskussionen können noch alte Notationen vorkommen; letzteres muss erst rückstandsfrei eliminiert werden bevor der bisherige Name ganz abgeschafft werden kann. Idealerweise gibt es übergangsweise eine Fehlermeldung, wenn der veraltete Name neu eingebracht würde.
• Ein Botlauf für einen derartigen nachrangigen Migrationsprozess wird von vielen Autoren nicht gern gesehen, weil letzlich überflüssig – einige beobachten auch alle Bot-Aktivitäten und überprüfen sie im Artikel; in jedem Fall wird die Versionsgeschichte belastet. In den meisten Fällen migrieren wir geruhsam nebenbei ohne Staub aufzuwirbeln.

VG --PerfektesChaos 15:19, 5. Okt. 2020 (CEST) korr 15:26, 5. Okt. 2020 (CEST)Beantworten

Das war wieder ein einleuchtender Beitrag von PC, der x gute Argumente und Beispiele für genau das liefert, was hier beabsichtigt ist: Warum beginnt und endet das Statement dann mit „Diese Werkstatt wird sich nicht an der Umsetzung beteiligen.“ – sprichst Du für alle hier? – und „letztlich überflüssig“? Daß Du keinen Staub aufwirbelst, glaube ich. [Bin gerade wieder auf so ein Ding gestoßen … WP:timeline soll nicht verwendet und durch WP:Graph ersetzt werden. Dort aber steht seit deinem Beitrag, daß man es sein lassen soll. Vorlage:Smiley/Wartung/facepalm ] --13:00, 6. Okt. 2020 (CEST) (unvollständig signierter Beitrag von Tommes (Diskussion | Beiträge) )

Das ist eine themenbezogene Vorlage, im Unterschied zu projektweit verwendeten.

• Ihre Ausgestaltung ist umstritten.
• Da wird sich diese Werkstatt nicht einmischen, insbesondere nichts entscheiden.
• Das müssen die Beteiligten schon selbst hinbekommen, und sie können das dann auch gleich selbst umsetzen.
• Als „letzlich überflüssig“ bezeichnete ich den Botlauf, der wiederum nichts mit der Programmierung der Vorlage zu tun hat.

VG --PerfektesChaos 15:58, 6. Okt. 2020 (CEST)Beantworten

Also wenn hier umgemodelt werden soll, dann bitte richtig. Wenn es neue Parameter geben soll, dann kann man auch hingehen und den nichtssagenden Vorlagennamen durch einen besseren oder zumindest längeren ersetzen. Denkbar wäre "HistLexSchweiz" oder ähnliches. Damit könnte man auch die alten und neuen Parameter händeln:

1. Die Vorlage wird verschoben
2. Sie wird ganz und exklusiv auf den neuen Parametersatz umgestellt
3. Die entstandene Weiterleitung wird in einen Aufruf der neuen Version umgewandelt und die alten Parameter dabei auf die neuen gepatcht.

Damit läuft der Aufruf der alten Vorlage mit den alten, ein aufruf der neuen mit den neuen Parametern.

Danach kann dann ein Bot die bestehenden Einbindungen umbiegen. ÅñŧóñŜûŝî (Ð) 19:38, 6. Okt. 2020 (CEST)Beantworten

In die Infobox soll beim Parameter "höchste Elo-Zahl" eine zusätzliche Abfrage eingebaut werden, ob der angegebene Parameterwert und der höchste Wert im Wikidata-Item identisch sind. Es könnte ja sein dass hierzuwiki eine Eintragung der höchsten Elo-Zahl vergessen wurde oder schlicht falsch ist. Da in Wikidata die Elo-Zahlen weitgehend vollständig sind, wäre das ein sinnvoller Abgleich. Im Falle von Nicht-Übereinstimmen soll eine Wartungskategorie geworfen werden. Kann das bitte jemand umsetzen der sich damit auskennt? 84.137.74.13 18:00, 5. Okt. 2020 (CEST)Beantworten

Gibt es ein Wikidata-Property für den höchsten Elo-Wert? -- hgzh 15:19, 7. Okt. 2020 (CEST)Beantworten

Hat die Vorlage die Möglichkeit, die Elo-Zahlen in Wikidata durch zu schauen, um die höchste zu ermitteln? Wäre wohl etwas zeitaufwändig, aber wäre es rein technisch möglich? --tsor (Diskussion) 16:08, 7. Okt. 2020 (CEST)Beantworten

Rein technisch wäre es möglich, allerdings bedürfte es eines spezifischen Lua-Moduls. VG --PerfektesChaos 17:29, 7. Okt. 2020 (CEST)Beantworten

Moin Moin hgzh, ja, gibt es, schau mal Elo-Zahl (P1087). mfg --Crazy1880 17:49, 7. Okt. 2020 (CEST)Beantworten

Die kannte ich, aber danke; aus Tsors Antwort lese ich heraus, dass es keine spezifische für den Maximalwert gibt und eine Iteration über P1087 erforderlich wird. Das ist dann keine triviale Vorlagenaufgabe mehr. Gruß, -- hgzh 17:52, 7. Okt. 2020 (CEST)Beantworten

Genau deswegen weil es nicht trivial ist, habe ich die Anfrage hier gestellt ;) 84.137.71.18 18:54, 7. Okt. 2020 (CEST)Beantworten

Mir ist aufgefallen, dass es ein Problem mit der Vorlage Vorlage:Auflagen-Vergleich kompakt gibt. Zuerst habe ich es im Artikel Deutsch perfekt gesehen, später aber dann auch bei den Beispielen auf der Vorlagenseite selbst. Und zwar werden hier Fehlermeldungen auf den Artikelseiten ausgegeben, hier ein Screenshot aus dem genannten Artikel.

Vielleicht kann sich das jemand, der mehr Ahnung als ich hat, mal angucken.

Schöne Grüße, --KommX (Diskussion) 22:47, 8. Okt. 2020 (CEST)Beantworten

Damit kenne ich mich auch nicht aus aber es scheint etwas mit er Zahl im Parameter 2 zu tun zu haben. Wenn ich da 7000 anstelle von 7196 einsetze dann sieht die Rechnung ok aus. Keine Ahnung wo genau die Zuordnung erfolgt. Ich verstehe nicht einmal genau was die Parameter erwarten.

Irgendwie muss man wohl immer mal diese Untervorlagen Vorlage:Metadaten Auflagen Zeitschriften DE Vorlage:Metadaten Auflagen Zeitungen DE aktualisieren. Benutzer:Schreibkraft, der sich da bisher wohl drum gekümmert hat, ist aber seit Monaten inaktiv. Vielleicht könnte mfb helfen. --Liebe Grüße, Lómelinde Diskussion 18:04, 9. Okt. 2020 (CEST)Beantworten

Vorlage:Metadaten Auflagen Zeitschriften DE hat keine Daten für 7196 (2. Parameter im Artikel). Also entweder die Vorlage nicht verwenden oder die Daten nachtragen. Könnte ein vorübergehendes Problem sein: [5]. Ohne Daten kann die Vorlage nichts machen, bestenfalls können wir die Fehlermeldung verbessern. --mfb (Diskussion) 19:21, 9. Okt. 2020 (CEST)Beantworten

Sorry I write in English, I have also earlier explained this see Vorlage_Diskussion:Nobel-ph

We have had problem linking nobelprize.org as they move around pages. We have now a more stable approach where we always link a number and then nobelprize.org redirect to the correct page

• we have this id in Wikidata P8024 Nobel Laureate API ID
• we have in 8 languages created templates using this Wikidata property see Q91652187
  • eg. 26 in Wikidata is generating link https://www.nobelprize.org/laureate/26
• TODO if you think this is a good idea:
  • create a german "vorlage" as en:Template:Nobelprize has been created

If you have questions dont hesitate to contact me. More about the process T248939 - Salgo60 (Diskussion) 23:03, 8. Okt. 2020 (CEST)Beantworten

Im Rahmen des Projekts Leichter mit Vorlagen arbeiten plant das Team Technische Wünsche (WMDE) Erleichterungen bei der Arbeit mit Vorlagen im Visual Editor, einschließlich der Erweiterung von TemplateData und Verbesserungen in dem dazugehörigen Editor. Zusätzlich plant das Team Änderungen an der Syntaxhervorhebung (syntax highlighting), um die Arbeit mit in Wikitext geschriebenen Vorlagen zu erleichtern.

Um sicherzustellen, dass diese vorgeschlagenen Funktionen zu Verbesserungen führen, würden wir gerne Feedback durch die Durchführung von Nutzungstests erhalten. Wir möchten insbesondere Tests mit erfahrenen Editierenden durchführen, die Vorlagen, einschließlich TemplateData, erstellen und pflegen.

Wenn diese Beschreibung auf dich zutrifft und du daran interessiert bist zur Entwicklung von Wikipedia beizutragen, fülle bitte dieses Formular aus! Hinweis: Der Nutzungstest wird voraussichtlich 45-60 Minuten dauern. -- Für das Team für Technische Wünsche: Max Klemm (WMDE) (Diskussion) 11:25, 13. Okt. 2020 (CEST)Beantworten

Hallo! Die Vorlage:Infobox Langstrecken-Weltmeisterschaft benötigt Hilfe. Im Jahr 2021 wird die Serie im Kalenderjahr ausgetragen und nicht wie in den letzten Jahren über zwei Kalenderjahre. Damit hat die Vorlage ein Problem und spuckt im Moment FIA-Langstrecken-Weltmeisterschaft 2020/-1 und FIA-Langstrecken-Weltmeisterschaft 2022/-1 aus. Außerdem generiert sie 2012 einen Link auf die Saison 2011, obwohl die Serie erst 2012 startete. Da ich selbst keine Ahnung davon habe, bitte ich jemanden, das Problem zu lösen. Danke schon mal! Beste Grüße --Pessottino (Diskussion) 15:01, 13. Okt. 2020 (CEST)Beantworten

Ist angepasst. Das Problem mit 2011/2012 kann ich aber nicht nachvollziehen, ich sehe keinen Link. -- hgzh 13:45, 14. Okt. 2020 (CEST)Beantworten

Hallo ihr Lieben,

könnt ihr mal schauen, warum in der Vorlage unter Moorflagengraben eine BKL auftaucht, obwohl die Syntax korrekt erscheint? Gruß, --Kurator71 (D) 16:29, 13. Okt. 2020 (CEST)Beantworten

Dank Lomelinde erledigt. Gruß, --Kurator71 (D) 19:11, 13. Okt. 2020 (CEST)Beantworten

Die in der Vorlagenwerkstatt ungeliebte Vorlagenfamilie Cite web et al. verwendet im Original seit einiger Zeit einige neue Parameter, und diese kommen in EN in freier Wildbahn inzwischen häufiger vor, wie die ursprünglichen. Allerdings sind die bisherigen auch in EN zigtausendach in Verwendung, müssen alsonoch eine Weile parallel laufen. Das betrifft z.B. url-status=live statt bisher deadurl=no.

Funktioniert:

{{#ifeq: {{{url-status}}} | live | {{{archiveurl}}} | {{#ifeq: {{{deadurl}}} | yes | {{{archiveurl}}} | }} }}

Oder geht das einfacher?

Und wie kann ich abfangen, falls archiveurl abweichend archive-url geschrieben wurde? --2003:E5:1F0F:110A:D8BE:2F3A:B5DB:9A22 22:44, 14. Okt. 2020 (CEST) (Matthiasb, auf Fremd-PC)Beantworten