Wikipedia:Redaktion Film und Fernsehen/Episodenlisten

Diese Seite dient der Koordination beim Umbau der bisherigen Vorlagen für Episodenlisten in ein neues besser zusammenpassendes Vorlagenset.

Bestand

Zuerst sollten hier die bestehenden Vorlagen mit Parametern und Features gelistet werden.

Vorlage:Episodenlistentabelle

Soll einen Tabellenkopf und den Tabellenfuß für die Liste erzeugen

Parameter	Pflichtfeld	Beschreibung	Standardwert	Hinweis
ANZAHL_STAFFELN		Wie viele Staffeln wurden produziert?		Wenn der übergebene Wert „1“ ist, entfällt die Spalte „Nr (gesamt)“, die in diesem Fall unnötig ist. (Entsprechend ist der Eintrag NR_GES leer zu lassen.) Bei mehr als einer produzierten Staffel erfüllt dieser Parameter keine Funktion und sollte weggelassen werden.
BREITE		Gibt die Breite der Tabelle vor.		Funktioniert genau so wie bei normalen Tabellen. Genaueres lässt sich der entsprechenden Hilfeseite entnehmen.
ERSTAUSSTRAHLUNG_LAND		Das Land/Die Länder, in dem die Folgen erstausgestrahlt wurden.
TV		War die Erstveröffentlichung der Episoden im Fernsehen?	ja	Wenn der Wert „nein“ übergeben wird, dann wird die Überschrift der Spalte „Erstausstrahlung“ ersetzt durch „Erstveröffentlichung“. Dies ist relevant etwa bei VoD-Serien oder Serien, die auf DVD/Blu-Ray erstmals veröffentlicht wurden.
ERSTAUSSTRAHLUNG		Wenn der Wert „nein“ übergeben wird, wird die Spalte „Erstausstrahlung“ ausgeblendet.	ja	Relevant bei VOD-Serien, bei denen alle Folgen am selben Tag veröffentlicht wurden.
INHALT		Der Inhalt der Tabelle muss in diesem Parameter stehen.
ZUSAMMENFASSUNG		Mithilfe dieses Wertes kann man die Spalte Zusammenfassung ausblenden.	ja	Der Wert darf nicht auf ja stehen, damit die Spalte ausgeblendet wird. In Kombination mit der Vorlage {{Episodenlisteneintrag2}} muss die Spalte ausgeblendet werden, da die ZF in diesem Fall in einer extra Zeile steht. Daher darf der Wert nicht „ja“ sein, selbst wenn es eine Zusammenfassung gibt.
ERSTAUSSTRAHLUNG_DE		Gibt an, in welchem Land die deutschsprachige Version der Serie ausgestrahlt wurde. Wird der Wert „nein“ übergeben, wird diese Spalte ausgeblendet.	D	Der Wert dieses Parameters steht in Klammern hinter Deutschsprachige Erstausstrahlung.
TV_DEUTSCH		War die deutschsprachige Premiere der Serie im TV?	ja	Wenn der Wert „nein“ übergeben wird, dann wird die Überschrift der Spalte „Deutschsprachige Erstausstrahlung“ ersetzt durch „Deutschsprachige Erstveröffentlichung“. Dies ist relevant etwa bei VoD-Serien oder Serien, die auf DVD/Blu-Ray erstmals veröffentlicht wurden.
SORTIERBAR		Bestimmt, ob die Liste sortierbar ist.	nein
DEUTSCHE_PRODUKTION		In diesem Parameter darf nicht „ja“ stehen, damit in der Spaltenüberschrift für die Erstausstrahlung Erstausstrahlung D steht. Außerdem wird dann eine Spalte „Deutscher Titel“ hinzugefügt.	ja	Wenn die deutschsprachige Erstausstrahlung gemeint ist, darf zusätzlich in ERSTAUSSTRAHLUNG_DE nicht D stehen.
DEUTSCHER_TITEL		Wird dieser Parameter auf "nein" gesetzt, wird die Spalte „Deutscher Titel“ ausgeblendet.	ja	Kann verwendet werden, wenn die Deutschen Titel mit den Originaltiteln übereinstimmen.
REGISSEUR		Mithilfe dieses Wertes kann man die Spalte Regisseur einblenden.	nein	Der Wert muss auf ja stehen, damit die Spalte eingeblendet wird.
DREHBUCH		Mithilfe dieses Wertes kann man die Spalte Drehbuchautor einblenden.	nein	Der Wert muss auf ja stehen, damit die Spalte eingeblendet wird.
ZUSCHAUER		Mithilfe dieses Wertes kann man die Spalte Zuschauer einblenden.	nein	Der Wert muss auf ja stehen, damit die Spalte eingeblendet wird.
ZUSCHAUER_LAND		Land, aus dem die Zuschauerzahlen stammen.		z. B. USA
ZUSCHAUER_REF		Quelle für die Zuschauerzahlen.		Format: <ref>{{Internetquelle |url= |titel= |werk= |datum= |abruf=}}</ref>
Feld1		Freie Vergabemöglichkeit einer Spalte in der Tabelle.		Wenn ein Wert angegeben wird, so wird dieser im Tabellenkopf als Titel gesetzt.
Feld2		Freie Vergabemöglichkeit einer Spalte in der Tabelle.		Wenn ein Wert angegeben wird, so wird dieser im Tabellenkopf als Titel gesetzt.
FUSSNOTE		Fügt eine Fußzeile am Boden der Tabelle ein.

Vorlage:Episodenlisteneintrag

TemplateData

Tabellenzellenvorlage für Seriendaten, einzeilig

Parameter		Beschreibung	Typ	Status
Nr. der Gesamtfolge	NR_GES	Nummer der Episode in der Gesamtzählung. Handelt es sich um eine Miniserie mit nur einer Staffel, kann die Angabe entfallen.	Zahlenwert	optional
Nr. der Staffelfolge	NR_ST	Nummer der Episode in der Staffel.	Zahlenwert	erforderlich
Originaltitel	OT	Dieser Parameter beinhaltet den Originaltitel der Episode.	Mehrzeiliger Text	erforderlich
Deutscher Titel	DT	Deutscher Titel der Serie.	Mehrzeiliger Text	optional
Zusammenfassung	ZF	Kurze Inhaltsübersicht als Zusammenfassung der Episode.	Einzeiliger Text	optional
Erstausstrahlung	EA	Datum der Erstausstrahlung der Episode. Eine bisher nicht ausgestrahlte Episode sollte mit einem Geviertstrich (— oder —) gekennzeichnet sein Beispiel 2024-11-16	Datum	optional
Erscheinungsjahr deutsch	EAD	Deutsche Erstausstrahlung der Episode in deutscher Sprache. Beispiel 2024-11-16	Datum	optional
Regie	REG	Der Regisseur der Episode.	Mehrzeiliger Text	optional
Drehbuch	DRB	Der Autor des Drehbuchs.	Mehrzeiliger Text	optional
Zuschauer	ZUS	Die Zuschauerzahlen der Episode.	Mehrzeiliger Text	optional
1. Freitextfeld	Feld1	Erstes freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
2. Freitextfeld	Feld2	Zweites freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
Farbumschaltung	1	Manuelle Umschaltung der Hintergrundfarbe, sollte im Normalfall nie eingesetzt werden. Standard 0 ☐ Beispiel 1 ☑	Wahrheitswert	optional

Format: block

Tabellenzellenvorlage für Seriendaten, einzeilig

Vorlagenparameter

Diese Vorlage bevorzugt Blockformatierung von Parametern.

Parameter		Beschreibung	Typ	Status
Nr. der Gesamtfolge	NR_GES	Nummer der Episode in der Gesamtzählung.	Zahlenwert	optional
Nr. der Staffelfolge	NR_ST	Nummer der Episode in der Staffel.	Zahlenwert	erforderlich
Originaltitel	OT	Dieser Parameter beinhaltet den Originaltitel der Episode.	Mehrzeiliger Text	erforderlich
Deutscher Titel	DT	Deutscher Titel der Serie.	Mehrzeiliger Text	optional
Zusammenfassung	ZF	Kurze Inhaltsübersicht als Zusammenfassung der Episode.	Einzeiliger Text	optional
Erstausstrahlung	EA	Datum der Erstausstrahlung der Episode. Eine bisher nicht ausgestrahlte Episode sollte mit einem Geviertstrich (— oder —) gekennzeichnet sein Beispiel 2024-11-16	Datum	optional
Erscheinungsjahr deutsch	EAD	Deutsche Erstausstrahlung der Episode in deutscher Sprache. Beispiel 2024-11-16	Datum	optional
Regie	REG	Der Regisseur der Episode.	Mehrzeiliger Text	optional
Drehbuch	DRB	Der Autor des Drehbuchs.	Mehrzeiliger Text	optional
Zuschauer	ZUS	Die Zuschauerzahlen der Episode.	Mehrzeiliger Text	optional
1. Freitextfeld	Feld1	Erstes freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
2. Freitextfeld	Feld2	Zweites freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
Farbumschaltung	1	Manuelle Umschaltung der Hintergrundfarbe, sollte im Normalfall nie eingesetzt werden. Standard 0 Beispiel 1	Wahrheitswert	optional

Vorlage:Episodenlisteneintrag2

TemplateData

Tabellenzellenvorlage für Seriendaten mit einem Extrafeld für die ausführlichere Zusammenfassung in einer zweiten Zeile

Parameter		Beschreibung	Typ	Status
Nr. der Gesamtfolge	NR_GES	Nummer der Episode in der Gesamtzählung. Handelt es sich um eine Miniserie mit nur einer Staffel, kann die Angabe entfallen.	Zahlenwert	optional
Nr. der Staffelfolge	NR_ST	Nummer der Episode in der Staffel.	Zahlenwert	erforderlich
Originaltitel	OT	Dieser Parameter beinhaltet den Originaltitel der Episode.	Mehrzeiliger Text	erforderlich
Deutscher Titel	DT	Deutscher Titel der Serie.	Mehrzeiliger Text	optional
Zusammenfassung	ZF	Kurze Inhaltsübersicht als Zusammenfassung der Episode.	Einzeiliger Text	optional
Erstausstrahlung	EA	Datum der Erstausstrahlung der Episode.	Mehrzeiliger Text	optional
Erscheinungsjahr deutsch	EAD	Deutsche Erstausstrahlung der Episode in deutscher Sprache.	Mehrzeiliger Text	optional
Regie	REG	Der Regisseur der Episode.	Mehrzeiliger Text	optional
Drehbuch	DRB	Der Autor des Drehbuchs.	Mehrzeiliger Text	optional
Zuschauer	ZUS	Die Zuschauerzahlen der Episode.	Mehrzeiliger Text	optional
1. Freitextfeld	Feld1	Erstes freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
2. Freitextfeld	Feld2	Zweites freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
Anker	ANKER	Jede Episode enthält einen Anker, über den sie mit dem deutschen Titel, dem Originaltitel oder Episode_<NUMMER> verlinkt werden kann (Als NUMMER wird NR_GES verwendet, wenn angegeben, ansonsten wird NR_ST verwendet). Der Parameter ANKER erzeugt einen zusätzlichen Alternativnamen, mit dem die Episode ebenfalls verlinkt werden kann.	Mehrzeiliger Text	optional
Farbumschaltung	1	Manuelle Umschaltung der Hintergrundfarbe, sollte im Normalfall nie eingesetzt werden. Standard 0 ☐ Beispiel 1 ☑	Wahrheitswert	optional

Format: block

Tabellenzellenvorlage für Seriendaten mit einem Extrafeld für die ausführlichere Zusammenfassung in einer zweiten Zeile

Vorlagenparameter

Diese Vorlage bevorzugt Blockformatierung von Parametern.

Parameter		Beschreibung	Typ	Status
Nr. der Gesamtfolge	NR_GES	Nummer der Episode in der Gesamtzählung.	Zahlenwert	optional
Nr. der Staffelfolge	NR_ST	Nummer der Episode in der Staffel.	Zahlenwert	erforderlich
Originaltitel	OT	Dieser Parameter beinhaltet den Originaltitel der Episode.	Mehrzeiliger Text	erforderlich
Deutscher Titel	DT	Deutscher Titel der Serie.	Mehrzeiliger Text	optional
Zusammenfassung	ZF	Kurze Inhaltsübersicht als Zusammenfassung der Episode.	Einzeiliger Text	optional
Erstausstrahlung	EA	Datum der Erstausstrahlung der Episode.	Mehrzeiliger Text	optional
Erscheinungsjahr deutsch	EAD	Deutsche Erstausstrahlung der Episode in deutscher Sprache.	Mehrzeiliger Text	optional
Regie	REG	Der Regisseur der Episode.	Mehrzeiliger Text	optional
Drehbuch	DRB	Der Autor des Drehbuchs.	Mehrzeiliger Text	optional
Zuschauer	ZUS	Die Zuschauerzahlen der Episode.	Mehrzeiliger Text	optional
1. Freitextfeld	Feld1	Erstes freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
2. Freitextfeld	Feld2	Zweites freies Informationsfeld, welches in der Vorlage:Episodenlistentabelle extra angegeben werden muss.	Einzeiliger Text	optional
Anker	ANKER	Jede Episode enthält einen Anker, über den sie mit dem deutschen Titel, dem Originaltitel oder Episode_<NUMMER> verlinkt werden kann (Als NUMMER wird NR_GES verwendet, wenn angegeben, ansonsten wird NR_ST verwendet). Der Parameter ANKER erzeugt einen zusätzlichen Alternativnamen, mit dem die Episode ebenfalls verlinkt werden kann.	Mehrzeiliger Text	optional
Farbumschaltung	1	Manuelle Umschaltung der Hintergrundfarbe, sollte im Normalfall nie eingesetzt werden. Standard 0 Beispiel 1	Wahrheitswert	optional

Vorlage:Episodenlistentabelle/Teil

Parameter		Beschreibung	Typ	Status
Text	Text	Der Text der Zeile.	Text	erforderlich
Spalten	Spaltenanzahl	Die Spaltenanzahl der Episodenlistentabelle.	Nummer	erforderlich
Farbe	Hintergrundfarbe	Die Hintergrundfarbe der Zeile. (Mögliche Farben)	Nummer	optional
Ref	Referenz	Fügt einen Beleg hinzu.	Text	optional

Vorlage:EpisodenlistentabelleShow

Parameter	Pflichtfeld	Beschreibung	Standardwert	Hinweis
ANZAHL_STAFFELN		Wie viele Staffeln wurden produziert?		Wenn der übergebene Wert „1“ ist, entfällt die Spalte „Nr (gesamt)“, die in diesem Fall unnötig ist. (Entsprechend ist der Eintrag NR_GES leer zu lassen.) Bei mehr als einer produzierten Staffel erfüllt dieser Parameter keine Funktion und sollte weggelassen werden.
BREITE		Gibt die Breite der Tabelle vor.		Funktioniert genau so wie bei normalen Tabellen. Genaueres lässt sich der entsprechenden Hilfeseite entnehmen.
Feld1		Freie Vergabemöglichkeit einer Spalte in der Tabelle		Wenn ein Wert angegeben wird, so wird dieser im Tabellenkopf als Titel gesetzt.
Feld2		Freie Vergabemöglichkeit einer Spalte in der Tabelle		Wenn ein Wert angegeben wird, so wird dieser im Tabellenkopf als Titel gesetzt.
ERSTAUSSTRAHLUNG_LAND		Das Land/Die Länder, in dem die Folgen erstausgestrahlt wurden.
INHALT		Der Inhalt der Tabelle muss in diesem Parameter stehen.
ZUSAMMENFASSUNG		Mithilfe dieses Wertes kann man die Spalte Zusammenfassung ausblenden.	ja	Der Wert darf nicht auf ja stehen, damit die Spalte ausgeblendet wird. In Kombination mit der Vorlage {{Episodenlisteneintrag2}} muss die Spalte ausgeblendet werden, da die ZF in diesem Fall in einer extra Zeile steht. Daher darf der Wert nicht „ja“ sein, selbst wenn es eine Zusammenfassung gibt.
ERSTAUSSTRAHLUNG_DE		Gibt an, in welchen Land die deutschsprachige Version der Serie ausgestrahlt wurde.	D	Der Wert dieses Parameters steht in Klammern hinter Deutschsprachige Erstausstrahlung.
SORTIERBAR		Bestimmt, ob die Liste sortierbar ist.	nein
Feld1A		Freie Vergabemöglichkeit einer Spalte in der Tabelle		Wenn ein Wert angegeben wird, so wird dieser im Tabellenkopf als Titel gesetzt.
Feld2A		Freie Vergabemöglichkeit einer Spalte in der Tabelle		Wenn ein Wert angegeben wird, so wird dieser im Tabellenkopf als Titel gesetzt.

Analyse

1) Insgesamt sehr viel Redundanz. Besonders Episodenlistentabelle mit EpisodenlistentabelleShow und Episodenlisteneintrag mit Episodenlisteneintrag2. Der Sinn von Episodenlistentabelle/Teil ist trotz Kurzinfo unklar. Jedenfalls sind es zu viel separate Vorlagen.

2) Die bisherigen Einbindungen der Zeilen werden als Parameter in die Kopfvorlage eingefügt.

3) Kryptische Parameternamen und diese in Blockschrift

4) Der Sinn diverser Angaben ist zweifelhaft

Zielsetzung

• Nur eine Kopfvorlage
• Nur eine Zeilenvorlage
• Evtl. eine End- bzw. Fußvorlage
• Wünschenswert: Umstellung per Bot ermöglichen

Diskussion

Kopfvorlage

• Benötigt alle Infos, welche erforderlich sind, um die richtigen Spaltenköpfe zu erzeugen
• Die Spaltenköpfe brauchen viel kürzere Texte. Die Breite der Datumsspalten muss z. B. vom Datumseintrag bestimmt werden.
• Unbedingt entfernen würde ich die Angabe zur Gesamtbreite. Das schränkt den Browser ein, welcher Leserseitig arbeitet. Nur die Spaltenköpfe für die Nummern und Datumsspalten sollten eine parameterlose(!) Breitenangabe haben.
• Extraspalten: Brauchen wir die wirklich? Wäre gut, wenn das wegbleiben könnte.
• Parameter Zuschauer: Wozu ist das gut? wird das gebraucht?
• Texte ans Ende der Zeile. Von mir favorisiert:
  Nr (ges) • Nr (St.) • Datum Original • Datum (dt.) • Folgentitel (Or) • Folgentitel (dt.) • Beschreibung
• Ganz wichtig für die Einbindung: Die Zeilenvorlagen sollte nicht mehr als Parameterwert übergeben werden. Die Vorlage endet, wenn der Tabellenkopf erstellt ist. Dadurch wird zwar eine Endvorlage nötig, aber die kann notfalls nur aus |} bestehen.

Je weniger Spalten, desto besser.

Endvorlage

Um die Zeilen von der Kopfvorlage zu trennen, braucht die Tabelle nach den Zeilen noch das Tabellenende. Dafür empfehle ich eine Endvorlage. Das ermöglicht die Ergänzung um Anmerkungen etc.

Zeilenvorlage

• Datumsangaben: Datum im Format "1. Jan. 1912", damit die Textlänge annähernd gleich ist. Das ermöglicht es, in der Kopfvorlage eine passende Sollbreite fest anzugeben. Ausrichtung rechts, denn rechte Ausrichtung erspart die Vorlage:0.
• Nummern: ausrichtung rechts.
• Titel: Ausrichtung links
• Infospalte: ganz nach rechts. Hier sollte der Text möglichst kurz sein. Wenn es mehr zu schreiben gibt, dann ist das besser unter der Tabelle als Anmerkung platziert.

Meinungen dazu? ÅñŧóñŜûŝî (Ð) 16:32, 28. Jan. 2023 (CET)

Hier ist meine recht ausführliche Meinung zu deinen Punkten, bzw. Fragen nach Klarstellung:

Zum Abschnitt „Analyse“:

zu 1) Zu EpisodenlistentabelleShow kann ich nicht viel sagen, erfahre gerade zum ersten Mal davon. Aber ich denke, es macht schon Sinn da eine extra Vorlage zu haben, da für eine Liveshow nun mal andere Informationen wichtig sind als für eine klassische Fernsehserie. Bei Episodenlisteneintrag vs Episodenlisteneintrag2 bin ich aber bei dir. Ich denke, Episodenlisteneintrag kann gestrichen werden und komplett durch Episodenlisteneintrag2 ersetzt werden (bzw. die neue Vorlage sollte sich an Episodenlisteneintrag2 orientieren). Der einzige Unterschied ist, dass in einem Fall die Zusammenfassungen eine Spalte ausfüllen, während sie im anderen Fall unter den anderen Infos zur Episode stehen und die gesamte Breite der Tabelle einnehmen. Von Episodenlistentabelle/Teil höre ich auch zum ersten Mal, aber sie wird offenbar eingesetzt um eine Staffel nochmal zu unterteilen, bei Serien bei denen die Staffel in mehrere Teile aufgespaltet ist. Siehe z.B. Breaking Bad/Episodenliste, Staffel 5 oder Lucifer (Fernsehserie)/Episodenliste, auch Staffel 5.

zu 2&3) keine Kommentare

zu 4) Kannst du da genauer ausführen was du meinst?

Zum Abschnitt Zielsetzung:

Ich bin nicht ganz sicher was du mit "Nur eine Zeilenvorlage" meinst. Meinst du, mann soll den gesamten Tabellenkörper mit nur einer einzigen Vorlageneinbindung einfügen? Oder einfach, dass man nicht mehrere verschiedene Vorlagen a la Episodenlisteneintrag und Episodenlisteneintrag2 haben sollte? Bei ersterem wäre ich skeptisch, bei zweiteren würde ich zustimmen.

Der Sinn einer Endvorlage erschließt sich mir nicht wirklich. Was ist falsch daran, die Zeilen als Parameter in die Kopfvorlage einzufügen, so wie das bisher gemacht wird? Eine extra Vorlage hinzuzufügen, die nur |} erzeugt, kommt mir etwas umständlich vor.

Umstellung per Bot ist mMn nicht nur wünschenswert, sondern absolut erforderlich! Es gibt knapp 1000 Episodenlisten, und das sind nur die, die ein eigene Seite haben. Es gibt zusätzlich noch viele, die in den Serienartikeln stehen. Das kann man nicht per Hand umstellen.

Zur eigentlichen Diskussion:

• Du sagst, Spaltenköpfe brauchen kürzere Texte. Hast du da Vorschläge, wie das in der Praxis funktionieren soll? "Erstausstrahlung" ist nunmal ein langes Wort. Und ich weiß auch nicht wie man das Sinnvoll kürzen könnte. "Erstauss." vielleicht? Oder "E.A." und dann mit einem Hovertext das gesamte Wort einblenden, wie das bei der Nummerierung gemacht wird? Fänd ich beides nicht so super, ehrlich gesagt.

• Meinst du mit "Extraspalten" Feld1 und Feld2? Das brauchen wir natürlich, da gibt es viele Beispiele wo das verwendet wird. z.B. Bones – Die Knochenjägerin/Episodenliste, Raumschiff Enterprise – Das nächste Jahrhundert/Episodenliste, Pokémon (Anime)/Episodenliste. Nicht alle Serien sind gleich, es gibt immer mal etwas, das bei einer Serie eine relevante Info ist, das nicht ins normale Schema fällt. Da ist es wichtig, flexibel zu bleiben.

• Parameter Zuschauer wird gebraucht um die Zuschauerzahlen anzugeben ... Natürlich wird das gebraucht ...
• Bei der Reihenfolge der Spalten würde ich auf jeden Fall die Titel ganz links lassen (nach den Nummern). Das ist letztlich wodurch die Folge identifiziert wird, also sollte es auch als erstes gelesen werden. Was meinst du hier mit "Beschreibung"? Die Zusammenfassungen? Die sollte auf jeden Fall eine eigene Zeile bekommen, wie bei Episodenlistenentrag2. Das ist was üblich ist, und ist auch viel übersichtlicher.
• Nochmal, warum sollen die Zeilenvorlagen nicht als Parameterwert übergeben werden?
• "Je weniger Spalten, desto besser". Bin ich anderer Meinung. Meine Philosophie ist, dass sich Vorlagen an den Inhalt zu halten haben und nicht andersherum. Mag sein, dass sie Tabellen breit werden, aber aus ästhetischen Gründen Informationen zu streichen ist Unsinn.

• Endvorlage: Kannst du das mit den Anmerkungen etwas mehr erklären?

• Datumsangaben: So ist es ja jetzt auch schon, oder?

• Was meinst du mit "Infospalte"? Wenn du die Zusammenfassungen meinst, die sollte auf keinen Fall in einer einzigen Spalte stehen!

--RookJameson (Diskussion) 18:39, 28. Jan. 2023 (CET)

Kurze Stellungnahme meinerseits: Dass die Breite der Episodenlistentabellen nicht für Mobilgeräte geeignet ist, ist klar. Dieses Problem lässt sich aber durch eine responsive Tabelle ganz gut lösen, braucht bloß ein wenig CSS-Bastelei. Dann stehen die Spalteninhalte schlicht untereinander, eventuell mit erklärendem Label, und es müssen für die Version auf normalbreiten Bildschirmen keine weiteren Änderungen vorgenommen werden.

Zum Rest habe ich keine Meinung, ich bin aber kein Fan von schließenden Fußvorlagen wie in enWP, unbalanced wikitext sollte vermieden werden. Was soll denn der Vorteil davon sein?

Gruß --XanonymusX (Diskussion) 21:10, 28. Jan. 2023 (CET)

Mit "Nur eine Zeilenvorlage" meine ich, dass man die Vorlagen, welche eine Tabellenzeile generieren, zu einer einzigen zusammenfassen sollte. Mit Infospalte meine ich die Zusammenfassung. In Episodenlisteneintrag ist - weitgehend undokumentiert - ebenfalls der Parameter ZF drin. Der setzt die Zusammenfassung in eine Spalte, und das mittendrin,was extreme Zeilenhöhen generiert. Hier sollte man auf diese Version verzichten und Zusammenfassungen grundsätzlich so wie in der "2-Version" in eine Zeile setzen. Die Zebrafärbung ist dann allerdings vermutlich hinfällig. Darüber hinaus sollten die unbenannten Parameter verschwinden. Fehlt die Episodennummer oder ist sie keine Zahl, dann gibt es Murks. ÅñŧóñŜûŝî (Ð) 00:54, 29. Jan. 2023 (CET)

Zu Analyse:

1. Redundanz sehe ich da auch. Nur sehe ich keine Möglichkeit in Wikisyntax, dies besser zu gestalten, um nur eine Vorlage zu erhalten und trotzdem alle Anforderungen zu ermöglichen. Im übrigen ist es deine Meinung, dass es zu viele Vorlagen sind. Man könnte ggf. auf Vorlage:Episodenlisteneintrag2 verzichten, da die ZF in der Zeile mit allen Angaben oftmals einfach die Tabelle optisch sprengt. Auch ist und bleibt Lua für mich keine Lösung, da nur noch einzelne Benutzer das Modul dann anpassen können und dabei auch verstehen, was sie machen. Als aktuelles Beispiel sei hier Vorlage:Bibel genannt (1).
2. Das ist halt eine Möglichkeit, Tabellen zu erzeugen, ohne, dass man eine Ende-Vorlage benötigt. Wenn es der post-expand-include size zugute kommt, dann kann dies auch mit einer abschließenden Vorlage umgesetzt werden.
3. Kryptisch sind diese nur, wenn man noch nie damit gearbeitet hat. Ich habe bei dieser Vorlage bisher keinen Fall gesehen, wo es Probleme gab. Zu beachten gilt auch, dass längere Parameternamen ebenso die post-expand include size aufblähen.
4. Wenn ich das richtig verstehe, fallen für dich darunter Angaben zu Anker, Zusammenfassung, Regie, Drehbuch, Zuschauer, Feld1 und Feld2, da du diese nicht auflistest. Diese sind z.T. wie bei IB Film auch Angaben zu einem (Gesamt-)Kunstwerk, wofür regelmäßig diverse Preise verliehen werden. Auch die zusätzlichen Spalten helfen dem Leser mit Angaben, die sich nicht in das bereits vorgegebene starre Muster pressen lassen.

Zur Zielsetzung:

• Ich denke nicht, dass nur eine Kopfvorlage ausreichen wird.
• Themenübergreifend nein, Einzelne ja. (siehe oben) Auf Vorlage:Episodenlisteneintrag2 kann ich verzichten, unter der Voraussetzung, dass Vorlage:Episodenlisteneintrag diese Aufgabe übernimmt.
• Siehe Vorlage:Episodenlistentabelle/Teil, ist aus meiner Sicht bereits vorhanden.
• Ich wüsste nicht, warum ein Botlauf nicht möglich sein sollte, kann allerdings aktuell auch nicht nachvollziehen, warum das ein Ziel sein sollte? Dass keiner alle aktuell 3485 Einbindungen händisch durchsehen möchte, sollte jedem klar sein. Nur sollten die vorhandenen Informationen nicht im Nirvana verschwinden.

Zur Diskussion:

• Du bist herzlich eingeladen, kürzere Spaltenbezeichner zu finden.
• Breitenangabe für Nummern wird interessant, es geht aktuell bis 4stellig. Eine Breitenangabe beim Datum funktioniert nur, wenn alle Einbindungen das gleiche Format haben. Außerdem sind diese spalten schon rechts ausgerichtet, daher kann ich den Verweis auf Vorlage:0 nicht nachvollziehen.
• Titel sind absichtlich zentriert, um die Größe einzusparen
• Info unter die Tabelle ist nicht machbar, außer jemand schreibt die 3k Einbindungen um.
• Zebra muss funktionieren, sonst wirst du Probleme mit der Lesbarkeit der Tabellen bekommen. --darkking3 ^Թ 01:09, 29. Jan. 2023 (CET)

• Kurze Paranamen: Ok, aber kurze Parameter sollten nur in der Zeilenvorlage stehen.
• Die Kopfvorlage für Shows unterscheidet sich stark von den anderen Verwendungen. Die muss man wohl besonders handhaben. Nur hier machen z. B. Zuschauerzahlen Sinn.
• Wenn wir keine kürzeren Worte für die Spaltenköpfe haben, dann brauchen wir halt fleißig Soft Hyphen oder feste Umbrüche. Die Datumsspalten sollten nicht durch den Kopftext unnötig breit werden.
• Bisher gibt es hier ein "Pseudo-Zebra", dass mit der Zahl in NR_ST generiert wird. Fehlt dort sowas wie eine Zahl, dann wird die Zeile kurzerhand mit class="error" versehen. Auch nicht optimal. Da muss man mal die CSS-Klasse testen oder wir bekommen eine Idee, wie das ohne die unbezeichneten Parameter geht.
• Jeder Eintrag wird mit einer langen ID versehen. Darauf zu verzichten, wäre ein großer Schritt in Richtung Einhaltung der Grenzen. Ich plädiere dafür.
• Eine Fußvorlage könnte die Anmerkungen übernehmen, also Ref-Tags mit Gruppierung.

ÅñŧóñŜûŝî (Ð) 02:23, 29. Jan. 2023 (CET)

• Pseudozebra ist so bisher notwendig, da durch Episodenlisteneintrag2 mit 2 Zeilen nicht anders möglich (bei z.B. gemischter Verwendung).
• Wenn du sichergehen kannst, dass kein Link auf eine ID verweist, können die von mir aus raus.
• Als Fußvorlage steht immer noch Vorlage:Episodenlistentabelle/Teil zur Verfügung.

darkking3 ^Թ 12:03, 29. Jan. 2023 (CET)

• Beim Pseudozebra brauchen wir dann etwas für den Fall, dass dort keine Zahl stehen soll, also z. B. nur der Halbgeviertstrich. Besonders einfach wären negative Zahlen (-1, -2). Die funktionieren im Modul genauso nach gerade / ungerade wie positive Zahlen, man kann aber festlegen, dass statt der Zahl der Halbgeviertstrich gezeigt wird. Liest sich kompoliziert, ist aber einfach zu händeln
• Link auf ID: Das muss man untersuchen. Es dürften Einzelfälle sein.
• Vorlage:Episodenlistentabelle/Teil + |} + References (mit "group = Anm" o. ä.) = Fußvorlage. die bisherigen Vorlagen sind älter als das Ref-Feature der WP-Software. Kann man also neu nutzen.
• Ich Teste mal, was mit einer Fußvorlage an Includesize eingespart wird. ÅñŧóñŜûŝî (Ð) 12:56, 29. Jan. 2023 (CET)

Ergebnis: Der Vergleich Benutzer:Antonsusi/Episoden1 mit Benutzer:Antonsusi/Episoden2 (Statt Fußvorlage nur |}) ergibt Post‐expand include size: 137315 zu 95678. Wenn man eine kleine Fußvorlage dazunimmt, dann ist das in diesem Fall eine Ersparnis von ca. 30 %. Das ist schon sehr viel. ÅñŧóñŜûŝî (Ð) 13:30, 29. Jan. 2023 (CET)

Hm, das Bearbeiten von nicht ausgeglichenem Wikitext im VE wurde ja deutlich verbessert, sehe ich, dann wäre es wohl doch nicht so schlimm. Ist trotzdem nicht optimal, da fehleranfälliger als Verschachtelung, aber wenn das die einzige Möglichkeit zur Verkleinerung ist … --XanonymusX (Diskussion) 13:40, 29. Jan. 2023 (CET)

⇐Es wäre nicht die erste Tabelle mit diesem Schema. Und wenn's mal einer zerhaut: Das Gute an einem Wiki ist doch, dass sich immer jemand findet, der weis, wie es geht und dann korrigiert... Dürfte nur am Anfang etwas häufiger vorkommen. Das packen wir schon. Eine gute Doku ist hier entscheidend. Mir gefällt halt auch die Option, gleich die Anmerkungen zu platzieren. Bisher "kleben" die notgedrungen an den Tabellen, was nicht so schön aussieht. Das sind aber Feinheiten, um die wir uns später kümmern können. ÅñŧóñŜûŝî (Ð) 14:12, 29. Jan. 2023 (CET)

Wenn die Endvorlage hilft, Resourcen zu schonen, dann wäre ich auch dafür das so umzusetzen. War erst skeptisch, aber das ist schon ein gutes Argument.

Zum Pseudozebra: Eine einfache Möglichkeit wäre vielleicht, bei ungeraden Zahlen grau, bei allem anderen (gerade Zahlen, aber auch "–" oder einfach leer) weiß. Ich dachte eigentlich eh, dass das so implementiert war, aber vielleicht wurde das irgendwann mal geändert ...

Mit der ID meint ihr den Anker, oder? Ich meine mich an einige Fälle zu erinnern, wo das verwendet wurde, konnte jetzt aber nichts finden. Im Prinzip ist es schon irgendwie "nice to have" aber ich sehe ein, dass die Kosten nicht im Verhältnis zum Nutzen stehen, also kann das von meiner Seite her auch weg. Aber es wäre gut wenn man irgendwie herausfinden könnte wo das tatsächlich genutzt wird.--RookJameson (Diskussion) 20:36, 29. Jan. 2023 (CET)

Als aktuelles Beispiel, warum ich mir keine Umsetzung der Vorlage in Lua vorstellen kann: Klick. Der Ersteller der Vorlage/Modul kann es nicht warten/verbessern. Auch wenn das Modul hiesig erstellt wird, so ist der Nutzerkreis, welcher Lua warten kann, deutlich kleiner als der für Wikisyntax. P.S.: Wenn ein Anker in einer Tabelle notwendig ist, dann kann dieser direkt bei DT oder OT übergeben werden. Dies hält die Vorlage schlank für die verschwindend geringe Nutzung. --darkking3 ^Թ 09:47, 30. Jan. 2023 (CET)

Dann auch von mir mal eine längliche Einschätzung: Ja, eine Überarbeitung ist dringend nötig. Ich habe hunderte Serienartikel gewartet, aber bei dieser Vorlage halte ich es wie Reich-Ranicki: Sie ist so schlecht, dass ich sie nie benutzt habe. Hier also meine konkreten Änderungsvorschläge, aufgeteilt in drei verschiedene Problembereiche:

Technik

Die Programmierung ist ineffizient, sodass immer wieder Episodenlisten die Hilfe:Vorlagenbeschränkungen reissen. Das Fass zum Überlaufen bringt hier die Verschachtelung der einzelnen Teilvorlagen. Wenn man z.B. in Pokémon (Anime)/Episodenliste alle {{Episodenlistentabelle}} durch normale Wiki-Tabellen {| … |} ersetzt, fällt die Serverbelastung sofort auf Normalmaß zurück. Zur Lösung fallen mir zwei verschiedene Ansätze mit balanciertem Code ein:

Version 1	Version 2
{{Episodenliste/Kopf}} {{Episodenliste/Eintrag}} … {{Episodenliste/Fuß}}	{| {{Episodenliste/Kopf}} {{Episodenliste/Eintrag}} … |}

Antonsusi hat Version 1 vorgeschlagen. Ich bevorzuge Version zwei, denn die ist kürzer und benötigt weniger Vorlagen. Dieses Format nutzt z.B. auch bereits die {{Kopfzeile Synchronisation}}.

Eine Neuprogrammierung mit Lua ist imho mit Kanonen auf Spatzen geschossen. Es handelt sich nur um eine ganz einfache, statische Tabelle, die sich vollständig innerhalb der normalen Tabellen/Vorlagensyntax realisieren lässt. Eine Lua-Fassung bräuchte deutlich mehr Code und kann nur von den wenigsten hier gewartet werden.

Die Umstellung mittels Bot ist schnell und einfach. Es genügt eine Übersetzervorlage, die die alte Syntax entgegennimmt und die neue produziert. Das wird dann einfach automatisch ge-subst-tet. Ich könnte übernehmen, denn bei Fernsehserien gibt es noch ein paar weitere Schönheitskorrekturen, die ich dann im selben Zug erledigen könnte.

Verwaltung & Usability

Die alten, kryptischen Parameternamen entsprechen definitiv nicht mehr den Projektstandard. Eine Umstellung auf selbsterklärende, "sprechende" Parameternamen ist eigentlich zwingend. Am Besten sollte man mit denen aus den Infoboxen vereinheitlichen.

Ich bin zwar auch immer für die Vereinfachung. Die ZUSCHAUER sowie die beiden Zusatzspalten werden aber flächendeckend eingesetzt, z.B. für Episodenlängen, Gaststars, Cutter, Kamera oder Simpson-Tafelgags. Da kann nichts wegfallen. Hier die eine Übersicht über den Ist-Zustand der Vorlagenverwendungen: Episodenlisteneintrag, Episodenlisteneintrag2, Episodenlistentabelle. Viele der Schalter-Parameter lassen sich aber schon geschickter einbinden und in vielen Fällen automatisieren.

Die Direktlinks auf einzelne Episoden werden in 99% der Artikel nicht verwendet ([1] sowie [2]) und können deshalb zurückgebaut werden.

Die Eintragsvorlagen sind weitestgehend deckungsgleich und lassen sich in einer zusammenführen. {{Episodenlistentabelle/Teil}} ist imho überflüssig. Sie wird kaum eingesetzt und die abgebildete Eigenschaft ist beileibe nichts Bemerkenswertes: Ausstrahlungen wurden schon immer unterbrochen, z.B. über Weihnachten. Die Angabe ist deshalb auch redundant zu den vorhandenen Ausstrahlungsdaten. Dazu kommt, dass die Gestaltung innerhalb der Tabelle kaum auffällt und so die gewünschte Struktur ohnehin nicht vermittelt. Falls die Angabe erhalten werden sollte, würde ich sie mit normaler Wiki-Tabellensyntax direkt in die betreffenden Artikel schreiben.

Gestaltung

Datumsangaben werden bereits gekürzt formatiert. Feste Breitenangaben sollten überall weg, der Browser bekommt das eigentlich immer bestmöglich hin.

Inhaltsangaben sind idR länger als die übrigen Angaben. In eine Spalte gequetscht macht das die Gestaltung dann sehr unausgewogen. Deshalb sollte die Zusammenfassung immer in einer eigenen Zeile mit voller Tabellenbreite stehen, so wie es in Episodenlisteneintrag2 gehandhabt wird. Soweit ich das überblicke, herrscht in diesem Punkt hier ja bereits Einigkeit. In diesem Zusammenhang würde ich auch das Pseudo-Zebra umstellen: Die Basisdaten werden etwas dunkler abgesetzt und die Zusammenfassung dann als Erweiterung einer Zeile etwas heller.

Wie Kienny bereits in der RFF vorgeschlagen hat, wäre eine Umstellung "Erstausstrahlung" -> "Premiere" sinnvoll. Das macht den Begriff unabhängig von verschiedenen VÖ-Kanälen wie Streaming und ist zugleich kürzer. Wenn man noch weitere Spaltennamen verkürzen möchte, könnte man auch "Deutsch" mit "Dt." abkürzen.

XamonymusX hat es ja bereits gesagt: Eine responsive Darstellung für Mobilgeräte lässt sich jederzeit mit CSS ergänzen. Dafür muss nur ein geeignetes Wikipedia:TemplateStyles in die Vorlagen eingebunden werden. Die Umsetzung wäre deshalb ganz unabhängig von den anderen hier besprochenen Punkten…
Eiragorn ^{Let's talk about... Flachkräcker} 23:29, 30. Jan. 2023 (CET)

Das deckt sich großteils mit dem Gesagtem. Nur bei Zebra muss ich dir widersprechen: Hat man nur Basisdaten ohne Zusammenfassung, dann wird dein Vorschlag nicht funktionieren und du hast einfach alle Zeilen dunkel gestaltet und damit keinen Mehrwert generiert. Das betrifft den wesentlichen Teil aller Episodenlisten, da aktuell rund 18.7% der Einträge einen ausgefüllten Parameter ZF haben (dabei: 40.8% aller ~eintrag2 und nur 4.5% aller~eintrag). Für diese Umstellung bei den Zeilenvorlagen bedarf es nicht mal eines Bots, wenn man dies mit einem redirect löst. Wird die weitere Syntax angepasst sollte dies natürlich mit angepasst werden. Variante 2 halte ich übrigens für nicht sinnvoll, da {{Kopfzeile Synchronisation}} wirklich nur die Kopzeile erzeugt, dies bei Episodenlisten allerdings nicht so umgesetzt wird. Daher sollte auch die Endvorlage Fußzeilen etc. pp. unterstützen, um eine Art Zwangssführung der Nutzer zu erhalten und damit undisclosed wikitext zu vermeiden. --darkking3 ^Թ 10:16, 31. Jan. 2023 (CET)

Was ich vergessen habe: Einer meiner wenigen Wünsche wäre die Verwendung des ISO-Datumsformat, sodass die Angaben besser verarbeitbar und damit auch nahezu beliebig formatierbar sind. Zudem gäbe es dann auch eine durchgehend identische Formatierung. --darkking3 ^Թ 10:33, 31. Jan. 2023 (CET)

Zum Thema Zebra: Das kann doch auch per TemplateStyles gelöst werden oder verstehe ich das falsch? --XanonymusX (Diskussion) 10:46, 1. Feb. 2023 (CET)

normalerweise geht das über nodecount, also das Zählen der logischen Knoten. Das ist hier aber unbrauchbar, weil ein Eintrag wahlweise eine oder zwei Zeilen sein können. Es ist daher schon sinnvoll, die sowieso anzugebenden Nummern zu nutzen. Genaueres unten am Ende des Abschnitts.

Diskussion -Einfügemarke 1

ISO-Format ist grundsätzlich jetzt schon möglich, allerding steht in den meisten Einbindungen das Datum direkt in der Form "29. Feb. 2020" drin... Eine Fußvorlage ist gewiss besser, weil man das in die Doku schreiben kann und dann wird es auch genutzt und alles ist "in Balance". Die Anmerkungen gehören da ja auch hin. Das Zehlengesteuerte Zebra ist gewiss am Besten für diue Darstellung. Ebenso sollte auch bei gemischtem Gebrauch von ein- und doppelzeiligem Eintrag die Grenze gut erkennbar sein. Das geht meiner Erfahrung nach durch geschickte Anwendung der horiz. Linien am Besten. die Zwischenlinie bei doppelzeile muss halt dezenter sein als die zw. Einträgen. Zum Thema Lua: Wenn ein User ein Modul abkopiert, ohne es durchzudenken, dann ist es normal, wenn er nichts ändern kann. Davon solltet ihr euch nicht einschüchtern lassen. Wer irgendwann mal BASIC gelernt hat, der kann auch Lua lernen. Der Übergang von Wikisyntax zu Lua ist etwas schwieriger, aber da finden sich immer genug User. Bisher wird Lua für das Pseudozebra genutzt und das Modul:TemplUtl genutzt. Das stammt von einem User, der grundsätzlich so aufwändig programmiert, dass nur er voll durchblickt. Eine derartige, von mir schon öfters kritisierte Monopolisierung wird es mit mir nicht geben. Von mir geschriebene Module dienen hauptsächlich dazu, Variablen und Schleifen zu nutzen und sind leichtverständlich. Mit einem angepassten Modul ist TemplUtl nicht mehr erforderlich, denn letzteres wird nur benutzt, im übergebenen String das erste Auftreten von mind. einer Ziffer zu finden und dann die Zahl zu liefern. Darüber hinaus kann man mit einem Modul auch direkt XHTML-Tabellensyntax erstellen. Die wäre vom Zeilenumbruch unabhängig, das Pipe muss nicht maskiert werden, die Rückgabe braucht nur noch wenig Parser (nur für die Wikilinks) und der Quelltext des Moduls setzt die Zeilen zuverlässig zusammen. Ob diese Option genutzt werden sollte, hängt davon ab, ob man viel hineinpacken will. Direktes HTML ergibt mit Abstand den kleinsten Wert für die Seitengröße. Die Vermischung der vielen geschweiften Klammern für verschiedene Zwecke und die doppelte Bedeutung der Pipes sowohl für Tabellensyntax als auch für Parametersyntax ist neben fehlenden Variablen der Hauptgrund dafür, dass Wikivorlagen so aufgebläht sind. ÅñŧóñŜûŝî (Ð) 23:20, 31. Jan. 2023 (CET)

Kommentar zum Datumsformat: Das Datum wird von der Vorlage automatisch formatiert. Also auch wenn du 2023-01-31 reinschreibst, zeigt die Vorlage 31. Jan. 2023 an. Ich denke, dieses Verhalten sollte auch bei der neuen Vorlage beibehalten werden, damit alles schön einheitlich ist. Man müsste sich also schon darauf einigen, welches Datumsformat man letztlich haben will. (Persönlich würde ich aber dafür stimmen, es so zu lassen wie es jetzt ist.)

Ich habe auch grundsätzlich nichts gegen Lua, solange der Quelltext vernünftig nachvollziehbar bleibt. --RookJameson (Diskussion) 23:25, 31. Jan. 2023 (CET)

Fein. Es gibt übrigens auch Einbindungen mit einer einzigen Tabelle für mehrere Staffeln. Damit dort die Zebrafärbung funktioniert, braucht es einen optionalen Parameter für die Staffelnummer. Ich versuche mal, ohne Sortierung zusammenzufassen. Die Listen für Shows sind hier noch nicht dabei:

• Kopfvorlage mit Parametern für folgende Spalten:
  • Gesamtnummer (ja/nein, ersetzt "ANZAHL_STAFFELN"')
  • Staffelnummer (ja/nein, neu)
  • Folgennummer (immer nötig)
  • Originalsprache (Kürzel, leer = dt.)
  • Originaltitel (immer nötig)
  • Original Premiere (immer nötig)
  • Dt. Titel (ja/nein, es gibt auch Listen ohne dt. Titel)
  • Dt. Premiere (ja/nein, es gibt auch Listen ohne dt. Premiere)
  • Regisseur ja/nein?
  • Drehbuchautor ja/nein?
  • Extrafeld 1 ja/nein?
  • Extrafeld 2 ja/nein?
  • fehlt hier noch was?
• Zeilenvorlage:
  • Parameter passend zum Kopf, leer=Zelle weglassen
  • Datum ISO-tauglich
  • Zusammenfassung generell in 2. Zeile
  • Noch was?

Bleibt noch eine Version für Shows. Diese Tabellen sind von den anderen und untereinander sehr verschieden. Da würde ich jetzt in der Tat eine eigene Kopfvorlage und wohl doch eine eigene Zeilenvorlage nehmen. Nur hier machen m. E. Zuschauerzahlen Sinn.

Allgemein: Sortierbarkeit sollte generell aktiviert sein. Wenn das mal nicht passt, dann merkt man das beim Klick... Der Zweck von "TV" und "DEUTSCHE_PRODUKTION" erschließt sich mir nicht. Unbenannte Parameter sind überflüssig. Bei guter Programmierung braucht es generell keinen Parameter für "Farbumschaltung". Das geht auch mit dem Parameter Folgennummer.

Ich schlage vor, wir konkretisieren zuerst diesen Bereich und kümmern uns anschließend um die Vorlagen für Shows. ÅñŧóñŜûŝî (Ð) 20:09, 1. Feb. 2023 (CET)

Was ist der Unterschied zwischen Gesamtnummer und Staffelnummer? Zuschauerzahlen werden auch für Fernsehserien benötigt. TV wird genutzt, wenn die Ausstrahlung nicht im TV erfolgte, sondern bei einem Streaminganbieter. Aus Erstausstrahlung wird dann Erstveröffentlichung. --Kienny (Diskussion) 21:01, 1. Feb. 2023 (CET)

Kienny, Staffelnummer ist wohl die Nummer der Staffel, wenn mehrere Staffeln in einer Tabelle kombiniert werden. AntonSusi, könntest du da Beispiele verlinken? Sowas hab ich noch nicht gesehen, und ich bin mir nicht sicher wie sinnvoll das ist.

Kienny, wenn wir jetzt sowieso Erstausstrahlung durch Premiere ersetzen, dann braucht es die TV Parameter nicht mehr. Premiere kann sich auf alle Medien beziehen.

Den Parameter "Original Premiere" würde ich optional machen. Bei Netflix Serien, bei denen alle Folgen auf einmal veröffentlicht wurden, werden die Daten in den Zeilen oft weggelassen, und Stattdessen einmal in eine Fußzeile geschrieben; Beispiel. Momentan wird die Fußzeile mit FUSSNOTE in Episodenlistentabelle erzeugt, aber bei der neuen Vorlage wäre das ja perfekt was für die Endvorlage.

Die Zuschauerzahlen sollten drinnenbleiben. Wir brauchen da gar nicht über die Sinnhaftigkeit der Angaben diskutieren. Das wird massiv verwendet und sollte daher bleiben.

Der Sinn von "Deutsche Produktion" ist, die Spalten „Deutscher Titel“ und „Deutsche Erstausstrahlung“ gleichzeitig auszublenden (weil in dem Fall redundant zum Originaltitel, bzw. Original Erstausstrahlung.) Aber ich glaub, das braucht es nicht unbedingt. So wie du das Vorgeschlagen hast ist es, glaub ich, besser.

Zustimmung dazu, die Shows später separat zu handhaben. --RookJameson (Diskussion) 23:10, 1. Feb. 2023 (CET)

Gut. Die Seite mit mehreren Staffeln in einer Tabelle ist Der Kommissar/Episodenliste. Es gibt mehrere davon. Bei Folge steht sowas wie 1/1 1/2 u.s.w. Das bewirkt aber alle Zeilen einer Staffel in gleicher H-Farbe, weil das TemplUtl-Modul die Ziffer vor dem Punkt als Zehl extrahiert. Insgesamt also noch:

• Zuschauer kommt rein
• TV brauchen wir nicht mehr, weil der Kopftext verbessert wird.
• Original Premiere wird optional
• "Deutsche Produktion" ist redundant, weil man die Spalten individuell steuert, was einfacher ist.

Wenn wir Parameter durch geschickte Handhabung anderer ersetzen können, dann ist das einfacher und besser. ÅñŧóñŜûŝî (Ð) 23:59, 1. Feb. 2023 (CET)

Nein, es braucht keine separate Show-Vorlage. Das betrifft nur 16 verschiedene Sendungen, alle sind mit den vorhandenen zwei Freifeldern auch uneingeschränkt innerhalb der normalen Ep-Listen-Vorlagen umsetzbar.

Nein, es brauch keinen zusätzlichen Parameter "Staffelnummer" im Tabellenkopf. Wenn alle Staffeln zusammen in einer Tabelle stehen, ist das eine missbräuchliche Verwendung der Vorlage. Diesen Fall sollte man dringend bei der Umstellung beseitigen, anstatt die Programmierung darum herum zu bauen. Hier eine Liste potentieller Fälle.

@Antonsusi: Ja, man kann da so manche Konstellation noch automatisieren. Ich würde zuerst aus der Vorlagenauswertung den häufigsten Anwendungsfall identifizieren. Den kann man dann als Standardfall vorsehen, der in Zukunft ohne irgendwelche händischen Einstellungen auskommt. So bestehen z.B. die meisten Episodenlisten bei uns mehr als einer Staffel. Also ist es am komfortabelsten, wenn man nur bei Serien mit einer Staffeln einen zusätzlichen Schaltparameter benötigt. Auf diese Weise lassen sich alle jetzigen Parameter abklopfen und es fallen direkt ERSTAUSSTRAHLUNG, DEUTSCHE_PRODUKTION und ZUSCHAUER weg, die sich mittelbar aus div. Belegungen der anderen Parameter ergeben. Die geschickteste Parameterkonstellation lässt sich deshalb nur schwer im Vorhinein konstruieren, sondern ist vielmehr das Ergebnis bei der Programmierung entlang der Bestandsdaten sowie der inhaltlichen Vorgaben.

Den Mehrwert eines Fußnoten-Parameters stelle ich infrage: Unter den vorhandenen Verwendungen gibt es nur genau eine – WandaVision –, die auch nur annähernd einer klassischen Fußnote bzw. Anmerkung entspricht. Überall sonst steht nur ein Satz zur Veröffentlichung genauso, wie er üblicherweise oberhalb der Episodenliste in der Abschnittseinleitung gehört. Einen echten Bedarf gab es also bislang noch gar nicht. Außerdem hat sich für Anmerkungen von Tabellen bereits der Vorlagenkomplex {{FN}} etabliert. Ein redundanter Sonderweg für eine einzelne Vorlage ist deshalb ohnehin nicht mehr sinnvoll.

Es wäre sehr ratsam, nicht das Kind mit dem Bade auszuschütten und die Änderungen Schritt für Schritt umzusetzen. Bei zu vielen Änderungen gleichzeitig sind mögliche Fehler umso schwerer einzugrenzen und zu beheben. Das gilt insbesondere, wenn man eine komplett neue VL baut und die dann nur an ein paar Demo-Artikeln testen will. Aus diesem Grund hatte ich heute Nacht schonmal den aktuellen Diskussionsstand umgesetzt: Aus Erstausstrahlung/-Veröffentlichung wird Premiere und die Zusammenfassung wandert immer in eine neue Zeile. Offenbar hatten aber @Darkking3, RookJameson: damit ein Problem. Wäre vielleicht ganz gut, wenn ihr mich aufklären könntet. Der Parsingaufwand ist mit meiner Änderung jedenfalls gesunken, dass hatte ich selbstverständlich im Vorhinein kontrolliert. Die Pokemonliste reisst bereits seit Monaten die Seitenbeschränkungen, wie viel im Moment gerendert wird hängt ganz an der Tagesform der Server. Stichwort Hamsterhusten.

Nichtsdestoweniger habe ich {{Episodenliste/Zeile}} erstellt mit neuen Parameternamen entsprechend der anderen VLs dieses Themenbereichs. Die neue Vorlage bleibt voll kompatibel zu den anderen Vorlagen und kann deshalb bei Interesse auch in Artikeln getestet werden. Der Code ist ist auch effizienter und übersichtlicher geworden, aber falls jemand noch weitere Code-Optimierungen hinkriegt, gerne her damit…
Eiragorn ^{Let's talk about... Flachkräcker} 20:33, 2. Feb. 2023 (CET)

Zu den Fußnoten: Ich bin nicht sicher, ob ich dein Argument richtig verstehe, aber mir geht es hier in erster Linie nicht darum eine "Fussnote" zu haben, sondern ich wil die Möglichkeit, in eine Zeile am Ende der Tabelle schreiben zu können: "alle Folgen wurdem am DATUM auf PLATTFORM veröffentlicht". Das wird oft verwendet und ist sinnvoll, also sollte es auch bleiben.--RookJameson (Diskussion) 23:32, 2. Feb. 2023 (CET)

Genau diese Angabe steht überwiegend im Parameter FUSSNOTE, obwohl es keine Fußnote im eigentlichen Sinne ist. Der Satz "Staffel abc wurde <Premierendaten> veröffentlicht" befindet sich im Normalfall im Textabsatz über der Tabelle (Bsp. 1, Bsp. 2). Und gerade wenn die Premierendaten nicht für jede Folge einzeln eingetragen sind, wird diese Information noch wichtiger und gehört noch eher nach vorne…
Eiragorn ^{Let's talk about... Flachkräcker} 21:49, 3. Feb. 2023 (CET)

Ja, wie gesagt: Wenn du dich am Namen "Fussnote" störst, dann nennen wir den Parameter halt anders. Aber die Funktion mit dem Datum in einer Zeile würde ich schon gerne behalten. Ja, diese info steht auch oft schon im Fließtext vor der Tabelle, aber im Prinzip ist es doch so, dass die Leute ein Datum in der Tabelle erwarten (AntonSusi wollte das Premieredatum ja sogar zum Pflichtparameter machen), deswegen fände ich es gut, wenn das weiterhin so bleibt. In der Tabelle ist es letztlich auch sichtbarer als im Fließtext. Und man kann die Info ja trotzdem zusätzlich auch im Fließtext haben. --RookJameson (Diskussion) 23:25, 3. Feb. 2023 (CET)

Bei Der Kommissar/Episodenliste fehlt es nicht an einem Staffelschalter, vielmehr ist unklar, was diese Aufteilung wirklich sein soll? Weder entspricht sie den Angaben im Hauptartikel noch gibt es dazu weitere Quellen. Was mit Folgen mit 0/0 sein soll, weiß keiner. Und genau an diesem Beispiel sieht man ganz gut das Problem bei Episodenlisten: Es kann sich durch veränderte Veröffentlichungen eine andere Sortierung ergeben. Ihr versucht euch am aktuellen Bestand zu orientieren, was ein guter Ansatz ist. Die Vorlage wird in ~1,5k Artikeln verwendet, wir haben aktuell allein 8,7k Artikel über Fernsehserien.

@Eiragon: Du kennst den Diskussionsstand hier und auf WP:RFF, dann halte dich auch an diesen (erst testen, dann umsetzen). Wenn du dies nicht kannst, die Tür findest du hier. Zum Testen gibt es Beta, du kannst dich da gerne ausprobieren. Der "Vorteil" an Beta ist im übrigen auch, dass die Hamster da nicht ganz so gut im Futter stehen… --darkking3 ^Թ 21:13, 2. Feb. 2023 (CET)

Diskussion -Einfügemarke 2

Ich habe mich hier extra mit konkreten Entwürfen zurückgehalten, bis hier ein Konzept steht. Wer meine bisherige Teilnahme hier in der WP kennt, der weis, dass mir das nicht ganz leicht fällt. Wenn Eiragon der Meinung ist, da vorzupreschen, dann überfährt er mich und die Diskussion hier. Sowas schüttelt man nicht aus dem Ärmel, denn das bisherige Konstrukt ist ja schon recht umfangreich. Selbstverständlich muss genau(!) klar sein, was das neue Vorlagenset können soll und welche Verwendungen als unüblich gelten sollen und daher nicht unbedingt unterstützt werden müssen. Für Exotisches gibt es ja immer noch die Möglichkeit der direkten Tabelle. Wenn wir hier 90% aller EL abdecken, dann ist das schon ein guter Wert. Es gibt ja auch kleine Serien mit drei Folgen etc. Zurück zum Inhalt: Sollen wir die Staffelnummer weglassen? Kann man m. E. machen.

Zur Einführung: Es ist völlig klar, dass wir parallel arbeiten müssen: Die neuen Vorlagen werden erstellt, bekommen das Baustellenschild und werden mit mehreren (Kopien aus(?)) Artikeln getestet. Währenddessen müssen die bisherigen Vorlagen unangetastet bleiben, damit die vielen Artikel nicht "bei jedem Syntaxfehler" zerschossen werden.

Fehlt noch etwas an Festlegung? ÅñŧóñŜûŝî (Ð) 21:39, 2. Feb. 2023 (CET)

Ich bin nicht sicher, ob es in dieser Disk schon erwähnt wurde, also nur "for the record", die Zusammenfassungen sollten so wie jetzt nicht mit der Sortierung in Konflikt treten, und das Datum sollte auch weiter automatisch formatiert werden, sodass es einheitlich ist, egal was für ein Format eingetragen wird. An dieser Stelle sollten wir vielleicht auch nochmal kurz besprechen, welches Format das dann sein sollte. Ich bin jetzt nicht so überzeugt von ISO ...--RookJameson (Diskussion) 23:40, 2. Feb. 2023 (CET)

ISO ist super, weil bei YYYY-MM-DDdie alphanumerische Sortierung mit der logischen übereinstimmt und man das ISO-atum deshalb als Wert für data-sort-value nehmen kann. Es ist evtl. sogar empfehlenswert, wenn der Bot bei einem Edit eine Konvertierung der direkten Texte in ISO vornimmt. Erzeugen muss er das für data-sort-value sowieso. ÅñŧóñŜûŝî (Ð) 00:26, 3. Feb. 2023 (CET)

Ich verstehe die Vorteile schon, aber es ist halt einfach nicht was normalerweise verwendet wird ... Ich würde die Daten so angeben, wie es im normalen Sprachgebrauch gemacht wird, nicht "rückwärts". Aber gut, wenn ich der einzige bin, der sich daran stört, soll mir ISO auch recht sein. Wollte es nur mal gesagt haben.--RookJameson (Diskussion) 08:08, 3. Feb. 2023 (CET)

Nein, auch ich teile deine Vorbehalte gegenüber dem ISO-Format. Die Angabe ist nicht intuitiv und erfahrungsgemäß provoziert das öfters Zahlendreher. Und bei den umfassenden Datenmengen innerhalb dieser Vorlagen lassen die sich im Nachhinein nahezu nicht mehr aufspüren. Umgehen kann man das auch nicht: Bei laufenden Serien werden die Premierendaten idR nachgereicht, was bis auf weiteres ausschließlich in der Quelltext-Bearbeitung funktioniert. Und das Argument mit der Sortierung ist überholt: sortable erkennt Datumsangaben inzwischen automatisch.

Nichtsdestoweniger versteht die Vorlage bereits seit längerem auch das ISO-Format, mit der korrekten Formatangabe in der WP:TemplateData der Doku produziert auch der Visual Editor von sich aus ISO und bei der Umstellung per Bot werden auch alle vorhandenen Daten in das Format umgeschrieben werden. Das ist aber nicht für alle Datumsangaben möglich, z.B. bei Fußnoten oder anderen Anmerkungen ([3] [4]).

Deswegen: ISO sicherlich als Möglichkeit beibehalten, aber eine Einschränkung nur darauf bietet weder Extranutzen noch ist es mit dem Bestand kompatibel…
Eiragorn ^{Let's talk about... Flachkräcker} 21:49, 3. Feb. 2023 (CET)

Wenn die ZF in eine weitere Zeile kommt, dann ist es grundsätzlich so, dass es Konflikte mit der Sortierung gibt. Die Zeile mit der ZF hat nur eine, spaltenübergreifende Zelle, welche der ersten Spalte zugeordnet ist. Diese bekommt einen eindeutigen Sortierwert. Wenn die Tabelle nach einer anderen als der ersten Spalte sortiert werden soll, dann gibt es in dieser Spalte bei allen ZF-Zeilen gar keinen Wert. Es wird also der leere String als Wert genommen. Der Wert der ersten Spalte (Nr Ges oder Nr_st) passt sowieso nicht. Es muss allen hier klar sein: Doppelzeilen im Stil von Vorlage Episodenlisteneintrag2 sprengen die Sortierung. Das ist der Preis für (bessere) Lesbarkeit der Tabellen. Die Sortierfunktion bietet keine Option, beim Sortiervorgang einer ZF-Zeile dynamisch einen passenden Wert zuzuweisen. ÅñŧóñŜûŝî (Ð) 17:11, 4. Feb. 2023 (CET)

Nein, die Zeile mit der Zusammenfassung erhält per Hilfe:Tabellen/Sortierung#Anhangzeilen gar keinen Sortierwert, dann gibt es auch keine Probleme (hat zumindest bis jetzt immer funktioniert). --XanonymusX (Diskussion) 17:16, 4. Feb. 2023 (CET)

Umso besser. Das wäre also kein Problem mehr. Fehlt noch etwas an Festlegungen? ÅñŧóñŜûŝî (Ð) 13:33, 5. Feb. 2023 (CET)

Diskussion -Einfügemarke 3

Wenn es keine großen Änderungswünsche mehr gibt, dann werde ich die Umsetzung starten. Es wird sukzessiv aufgebaut und es wird auch etwas dauern. Ich plane das mal am Wochenende ein. ÅñŧóñŜûŝî (Ð) 19:41, 9. Feb. 2023 (CET)

Nur als kurze Zwischenfrage: Umsetzung meint Musterumsetzung, kein produktiver Einsatz? --darkking3 ^Թ 09:58, 10. Feb. 2023 (CET)

@Darkking3: Ich stelle mir das so vor, dass die Vorlagen im VNR erstellt werden, die Doku das Baustellenschild bekommt und das auf einer oder auch mehreren Testseite(n) Einbindungen ausprobiert werden. Solange niemand die bisherigen Vorlagen patchen will, kann nicht viel passieren. Es funzt garantiert nicht auf Anhieb komplett richtig. Wichtig ist aber, dass wir es durchziehen, denn es ist durchaus Arbeit für mich. ÅñŧóñŜûŝî (Ð) 22:02, 10. Feb. 2023 (CET)

@Darkking3: Wäre ganz nett, wenn du mir antworten würdest. Gruß von ÅñŧóñŜûŝî (Ð) 21:35, 13. Feb. 2023 (CET)

Mehr als ein Passt für mich habe ich nicht. Um vorab darauf hinzuweisen: Die Umsetzung ist nicht garantiert, das ist allerdings nicht auf meinem Mist gewachsen ;) Bei Problemen (mit den Vorlagen) helfe ich dir gerne. --darkking3 ^Թ 21:46, 13. Feb. 2023 (CET)

Zwischenmeldung: Ich bin hier noch dran. Hatte zuletzt aber nicht so viel Zeit. ÅñŧóñŜûŝî (Ð) 22:25, 15. Mär. 2023 (CET)

Zwischenmeldung: eine rudimentäre Version ist im Test. ÅñŧóñŜûŝî (Ð) 23:19, 25. Mär. 2023 (CET)

Zwischeninformation: Ich habe das nicht vergessen und bin noch dran. Bin jetzt erst mal für drei Wochen in Urlaub und dann geht es weiter... ÅñŧóñŜûŝî (Ð) 10:55, 6. Mai 2023 (CEST)

Weitere Vorschläge

Unabhängig davon, ob das in der langen Diskussion oben schon thematisiert wurde, schlage ich als Feature für die neue(n) Vorlage(n) vor, dass sie auch eine Möglichkeit bieten sollte, die nichtdeutschsprachigen und deutschsprachigen Erstausstrahlungsdaten, sofern sie identisch sind, in ein- und derselben Spalte darzustellen statt in zwei separaten Spalten. Das gibt es jetzt im Streaming-Zeitalter häufig, Beispiel siehe Silo (Fernsehserie).--Stegosaurus (Diskussion) 07:47, 10. Jun. 2023 (CEST)

Das ist so vorgesehen. ÅñŧóñŜûŝî (Ð) 19:51, 10. Jun. 2023 (CEST)