Wikipedia:WikiProjekt Vorlagen/Werkstatt

Automatische Archivierung

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

Automatische Archivierung

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.

Automatische Archivierung

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

Vorlage:Landtag Thüringen: Webarchiv- und Namens-Parameter nötig

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Hallo, nach Umstellung der URLs auf Namen laufen alle mit Zahlen codierten Vorlageneinbindungen ins Leere.

Wir bräuchten:

• eine Umstellung auf einen Namensparameter für die aktuellen und künftig ehem. Mitglieder und
• einen Archiv-Parameter für die schon ehem. Mitglieder.

Die Not wurde in gewisser Weise schon vor zwei Jahren durch Dritten erkannt und in der Disku benannt.

Gerade werden die Totlinks unter Preisgabe der Vorlage mit Mementos aufgelöst.

Auf dem Basis-URL

• https://www.thueringer-landtag.de/abgeordnete/abgeordnete-fraktionen-sitzordnung/abgeordnetendetails/abgeordneter/ wäre dann
• https://www.thueringer-landtag.de/abgeordnete/abgeordnete-fraktionen-sitzordnung/abgeordnetendetails/abgeordneter/vorname-name/ aufzusetzen.

Danke schon mal, --Wi-luc-ky (Diskussion) 23:27, 28. Jun. 2022 (CEST)

@Wi-luc-ky: Wie soll hier verfahren werden, wer pflegt die Vorlage im ANR? Grundsätzlich alle ID's ignorieren und stumpf vorerst versuchen, aus dem Seitennamen einen Link basteln, abweichende Linkziele optional? --darkking3 ^Թ 18:29, 5. Aug. 2022 (CEST)

Danke für die Rückfragen, darkking3. Der VL-Ersteller ist gesperrt, wenige haben danach verbessert. Ich könnte die VL auf meine BEO nehmen.

IDs würde ich über einen gewissen Zeitraum noch verborgen mitschleppen, da es schon VLs gab, wo die URL-Struktur wieder zurückgedreht wurde :( Zudem könnten daraus Mementos entstehen; falls nicht über Probieren mit den Namen (wie bei o. g. Ersetzung). Dafür ein Archivparameter.

Ja, aus Seitennamen Linkziel ableiten. Bei Namengleichheit müsste eine BKL resp. Klammerung möglich sein.

Bin eher zufällig darauf gestoßen, habe da keine nennenswerte Editzahl mit der VL getätigt. So wie es ist, wollte ich es aber nicht bestehen lassen.

Zum Mitlesen und -denken: @Slökmann.

Gruß, --Wi-luc-ky (Diskussion) 19:00, 5. Aug. 2022 (CEST)

Das Problem wird wohl nahezu alle Landtags-DB-Link-Vorlagen betreffen. Bis auf eine (!) von 12 solcher Vorlagen sind alle vom gesperrten Nutzer angelegt, häufig auch jeweils nur auf eine Wahlperiode angepasst. Das könnte wohl etwas mehr werden als gedacht. --darkking3 ^Թ 12:58, 6. Aug. 2022 (CEST)

Ausweislich der Diskussionsseite hatte ich mir bereits vor drei Jahren die Archiv-Parameter gewünscht. Damals war O.K. noch aktiv, es waren wohl andere Sachen wichtiger. Es ist begrüßenswert, wenn das Problem endlich angegangen wird. -- Grüße, 32X 21:34, 29. Jan. 2023 (CET)

Die Vorlage:KW16-Hessen bietet Parameter für den Aufruf von Mementos. Kundige könnten kinderleicht abkupfern. Gruß, --Wi-luc-ky (Diskussion) 11:01, 1. Apr. 2023 (CEST)

Metadaten Einwohnerzahl PT - alte Daten vor der Gebietsreform erhalten und neue Daten einbringen

Hallo, ich bin dabei die Metadaten der Einwohnerzahlen von Portugal auf den aktuellen Stand zu bringen. Dabei hänge ich an dem Problem, dass aktuell in den Vorlagen Metadaten Einwohnerzahl PT-00...30 LAU-Nr von vor und nach der Gebietsreform 2013 gemischt sind. Für die ehemaligen Aufteilungen (und entsprechende LAU-Nr.) vor der Gebietsreform gibt es keine aktuellen Daten; diese sind aber über die Vorlage Infobox Ort in Portugal noch zahlreich eingebunden (z.B. Mafamude LAU=131710 oder Santo Tirso LAU=131422). Die Einwohnerzahlen von 2021 habe ich in der Vorlage:Metadaten Einwohnerzahl PT:COMP vorbereitet. Eine mögliche Lösung hat Tschubby beschrieben: Abfrage über Vorlage:Metadaten_Einwohnerzahl_PT erst über Vorlage:Metadaten Einwohnerzahl PT:COMP zu machen, falls dort die gesuchte LAU-Nr nicht vorhanden ist, die Abfrage auf Vorlagen Metadaten Einwohnerzahl PT-00...30 weiterzuleiten. Ist so etwas umsetzbar? Grüße --Peterf (Diskussion) 20:46, 26. Jul. 2023 (CEST)

Grundsätzlich: ja.

Pfiffige Gesamtstrategie erforderlich.

Nachfrage: Soll Vorlage:Infobox Ort in Portugal die einzige Stelle sein, an der das dargestellt wird?

Nachfrage: Lassen sich alte und neue „LAU“ irgendwie unterscheiden?

Nachfrage: Wenn wir den Artikel über den Ort X haben, inwieweit ist es vorher und nachher gleiche LAU, gleiches Gebiet, gleiche Bevölkerung?

Grundsätzlich ist es ein Problem, Zahlen zu unterschiedlichen Zeitpunkten oder zugeordneten Objekten gleichartig durcheinander zu verwalten.

Wenn es geschickt gemacht wird, kann das so mit Rückfallwerten und Datierung dargestellt werden, wie du es skizziert hast.

VG --PerfektesChaos 20:57, 26. Jul. 2023 (CEST)

Die Einwohnerzahlen vor der Gebietsreform sind (vermutlich) nicht nur über die Vorlage:Infobox Ort in Portugal eingebunden. Eine Weiche alte/neue LAU-Nr. ist daher in Vorlage Metadaten_Einwohnerzahl_PT erforderlich.

Die LAUs vor/nach der Gebietsreform wurden nicht doppelt vergeben - sind also eineindeutig. So weit ich das überblicke aber nicht einfach unterscheidbar (z.B. 080101=Albufeira vor Gebietsreform / 080106=Albufeira e Olhos de Água nach Gebietsreform).

Grüße --Peterf (Diskussion) 21:26, 26. Jul. 2023 (CEST)

Dann ist dringendst die Einführung eines neuen Parameters in Vorlage:Infobox Ort in Portugal erforderlich.

• LAU=080101 (Altbestand)
• LAU2013=080106 (neu, gemäß Gebietsreform 2013)

Was ist denn diese „Gebietsreform“ eigentlich?

• Wie wirkt sie sich auf Albufeira aus? Gleiche Gemeindegrenzen, gleiches Volk, nur andere Nummer?
• Wurde der Ort übergeordneten Strukturen anders zugeordnet? „Landkreise“ neu zugeschnitten, „Provinzen“ anders gegliedert?

Vorlage:Metadaten Einwohnerzahl PT sollte nicht gemischt alte und neue Informationen enthalten.

• Ich würde Vorlage:Metadaten Einwohnerzahl PT/2013 neu anlegen und dort temporär nur die neuen Zuordnungen verwalten.
  • Nachdem es in einigen Jahren keine alten Einbindungen mehr gibt, kann die alte gelöscht und (mit WL) die temporäre an den bisherigen Platz verschoben werden.
  • Aus diffs mit vorherigen Versionen lassen sich notfalls die sortenrein zugreifenden Metadaten getrennt für alt und neu gewinnen. Auch dein PT:COMP mag dahingehend ausgewertet werden.
  • Ansonsten werdet ihr im Sumpf versinken.
  • Sobald nirgendwo der alte LAU= verwendet wird, kann LAU2013= zu dessen Alias gemacht und die temporäre Migrationslösung wieder zurückgebaut werden.
• Es gibt da so Metadaten-Geo-WikiProjekte; die sollten involviert werden.

Nachfrage: Welche anderen Verwendungen auße Infobox gäbe es noch für die Metadaten.

VG --PerfektesChaos 13:03, 28. Jul. 2023 (CEST)

Hallo PerfektesChaos, deine Fragen sind valide und im Sumpf beschreibt den Zustand; ich wollte nur die Einwohnerzahlen auf den aktuellen Stand bringen.... Ich muss hier auch Reverse Engineering betreiben - habe @Tschubby: angepingt ob er zur Diskussion etwas beitragen kann da er einige Änderungen zur Verwaltungsgliederung Portugals gemacht hat. Ich hoffe er kann hier helfen.

Am einfachsten ist deine Frage zur Gebietsreform zu beantworten: Administrative Neuordnung in Portugal 2013

Außerhalb der Infobox sind z.B. im Artikel Santo Tirso im Text die Metadaten eingebunden: ... leben {{EWZ|PT|131422}} Einwohner (Stand {{EWD|PT|131422}})...

Wenn ich in den Artikel Santo Tirso reinschaue, ist Santo Tirso sowohl der Name einer Gemeinde als auch eines Kreises. In der Infobox Ort in Portugal im Artikel ist die (alte) LAU=131422 eingefügt; anhand der Einwohnerzahl ist das wohl der Kreis. Daten zu Gemeinde Santo Tirso vor der Gebietsreform finde ich in Vorlage:Metadaten Einwohnerzahl PT-13 nicht, nach der Gemeindereform sind hier LAU=1314 für den Kreis aufgeführt und die LAU=131437 für eine Zusammenlegung von Gemeinden (União das freguesias de Santo Tirso, Couto (Santa Cristina e São Miguel) e Burgães) aufgeführt. Wobei mir hier nicht klar ist wie das Datum (2011) der Vorlage:Metadaten Einwohnerzahl PT mit den Einwohnerzahlen nach der Gebietsreform 2013 zusammenpassen kann. Hier stimme ich völlig mir dir überein, das sollte man nicht in einer Vorlage mischen.

PT:COMP beinhaltet nur die Einwohnerzahlen zu LAUs nach der Gebietsreform.

Grüße--Peterf (Diskussion) 17:34, 28. Jul. 2023 (CEST)

Da ich von euch angepingt wurde, werde ich auch noch meinen Senf dazu geben. Ich finde es in Portugal eh unglücklich gelöst, dass gleichlautende Kreise und Gemeinden im gleichen Artikel geführt werden und das zusammen in einer riesigen Infobox. Aus meiner Sicht müssten diese unterschiedlichen Gliederungen getrennt werden. Ein Artikel für den Kreis, ein anderer Artikel für die Gemeinde. In vielen anderen Ländern werden nur die aktuellen Gemeinden mit Metadaten angezeigt. Bei den alten Gemeinden werden die Einwohnerzahlen hardcodiert in der Infobox eingetragen. Falls die Logik der Metadaten umgestellt wird, ist auch zu beachten, dass die Logik der Einwohnerdichte nach dem gleichen Muster angepasst wird. Die Vorlage Vorlage:Infobox Município in Portugal müsste dann sicher auch noch angepasst werden. Gruss --Tschubby (Diskussion) 18:33, 28. Jul. 2023 (CEST)

Dann empfehle ich dringend, zu Vorlage:Metadaten Einwohnerzahl PT-13 usw. ebenfalls für die Dauer der Migration eine Untervorlage Vorlage:Metadaten Einwohnerzahl PT-13/2013 zu erstellen, und ggf. die bisherige auf den Status quo ante zurückzusetzen und in die „neue“ nur migrierte Daten aufzunehmen.

• Das unter der Voraussetzng, dass -13 (alt) identisch ist mit -13 (neu). Ansonsten wird das echt kriminell.
• Ich habe diverse Nachfragen offen, die die Auswirkung dieser Gebietsreform und deren strukturelle Änderungen betreffen. Das würde sich natürlich auch auf Datenstrukturen und Abbildung in Vorlagen auswirken.
• Durch die beschriebene Aufteilung in separate Vorlagen lässt sich zurückverfolgen, wo noch die bisherige eingebunden wird, und wo bereits die „neue“.
• Dann kann kaskadierend (mit Unterstützung hiesigen Werkstattpersonals) abgefragt werden, ob bereits unter der neuen LAU Daten vorhanden sind; wo nicht, dann aus der alten. Die Abfragen, die nur aus einer alten bedient werden können, lassen sich dann auch in einer Wartungskat registrieren. Wo dann eine alte Vorlage überhaupt nichts mehr liefert, kann sie zur WL auf die neue Technik gemacht werden. Zum Schluss kann der Migrationsmechanismus wieder eliminiert werden.

VG --PerfektesChaos 12:39, 29. Jul. 2023 (CEST)

Hallo PerfektesChaos.

Zu den strukturelle Änderungen habe ich mir die Datensätze angeschaut. Die Kreise/Gemeinden, die sich in der Aufteilung geändert haben, haben mit der Gebietsreform einen neuen Namen und eine (bisher noch nicht vergebene) LAU-Nr bekommen - zumindest habe ich kein Gegenbeispiel gefunden. Da wo sich keine Änderung ergeben hat, sind die LAU-Nr gleich geblieben (z.B. Porto LAU=1312 vor und nach Gebietsreform).

Die Vorlage:Metadaten Einwohnerzahl PT ruft die Unter-Vorlagen Metadaten Einwohnerzahl PT-01 ... -30 auf. Alle neuen/aktuellen LAU Nr. aus -01 ... -30 sind in der neuen Vorlage:Metadaten Einwohnerzahl PT:COMP vereinigt. Ich vermute daher, eine Migrationsversion der Untervorlagen Metadaten Einwohnerzahl PT-01...-30/2013 ist nicht notwendig. Müsstet du noch mal bewerten.

Ich habe jetzt gerade noch gesehen, dass in der aktuellen Vorlage:Metadaten Einwohnerzahl PT noch eine Funktion LAU1 to ISO zwischengeschaltet ist; das scheint mir ein historisch gewachsenes Relikt zu sein - ob das noch irgendwo genutzt wird kann ich nicht sagen. Leider sehr verworren das ganze. Kannst du dir das mal anschauen, ob das bei einer Umstellung mitgenommen wird oder nicht.

Die Vorlage:Infobox Município in Portugal ist innerhalb der Infobox Ort in Portugal eingebunden - Tschubbys Hinweis. Sie wird über {{padleft:|4|LAU}} aufgerufen; passt auch nach der Gebietsreform (z.B. Abrantes Gemeinde LAU=140120 und Abrantes Kreis LAU=1401).

Ist noch eine Frage von dir offen? Kann ich noch irgendwo helfen?

Danke & Grüße --Peterf (Diskussion) 11:27, 31. Jul. 2023 (CEST)

Hallo, nachdem die Diskussion etwas in stocken geraten ist - was haltet ihr von folgendem Vorgehen: Ich ersetzte hart den Aufruf in der Vorlage Infobox Ort in Portugal von Vorlage:Metadaten Einwohnerzahl PT auf die neue Vorlage:Metadaten Einwohnerzahl PT:COMP. Das wird dann für die nicht mehr aktuellen LAUs zu einem:

führen. Kann man die Suche nach dieser Fehlermeldung automatisieren, sodass man eine Liste der betroffenen Artikel bekommt? Ich vermute dir Anzahl hält sich in Grenzen (<100) und diese würde ich dann händisch (hard coded) auf den Wert aus der alten Vorlage Metadaten Einwohnerzahl PT setzen.

Alternativ sehe ich noch die Möglichkeit in der Vorlage Infobox Ort in Portugal den Paramter Einwohner über folgende Abfrage zu machen: {{#if:{{booland|{{IstZahl|{{Metadaten Einwohnerzahl PT:COMP| {{{LAU}}} }} }} }}| {{Metadaten Einwohnerzahl PT:COMP| {{{LAU}}} }} | {{Metadaten Einwohnerzahl PT| {{{LAU}}} }} }} und bei Quelle, Datum gleich zu verfahren.

Meinungen dazu? Grüße --Peterf (Diskussion) 21:58, 10. Aug. 2023 (CEST)

@Peterf:, ich habe dir hier mal eine Auswertung eingerichtet, bei der aufgelistet wird, in welchen Infoboxen ein LAU Code hinterlegt ist, der nicht in deiner neuen Liste vorkommt. Es sind weit über 500 Einträge. Vielleicht kontrollierst du gewisse Einträge. Bin der Meinung, dass es sich hier bei vielen um aktuelle Gemeinden handelt. Gruss --Tschubby (Diskussion) 21:47, 16. Aug. 2023 (CEST)

Hallo @Tschubby:, vielen Dank für die Liste. Nach dem durchschauen, sieht es so aus, als wären viele der fehlenden LAUs im Zuge der Gebietsreform zusammengelegt worden und werden jetzt unter einem Gemeindezusammenschluss União das freguesias de ... unter einer separaten LAU-Nr geführt. Damit scheint mir der Einbau einer LAU-Nr Abfrage erst über die neuen Daten und dann - falls die LAU-Nr dort nicht vorhanden ist - eine Weiterleitung der Abfrage zu den alten Daten am praktikabelsten. Grüße --Peterf (Diskussion) 22:32, 20. Aug. 2023 (CEST)

@Peterf:, ich könnte mir aber vorstellen, dass du evtl. ein mix zwischen alten und neuen Daten bekommst. Wenn die Gemeinde nicht gefunden wird, wird die alte Einwohnerzahl abgebildet, wenn aber der zugehörige Kreis gefunden wird, dann wird dort die neue Einwohnerzahl angezeigt. Wenn man nun die Einwohnerzahlen aller Gemeinden des Kreises zusammenzählt, stimmt die Summe nicht mehr überein. Gruss --Tschubby (Diskussion) 07:56, 21. Aug. 2023 (CEST)

@Tschubby: Auf Gemeindeebene passt die Einwohnerzahl bei einem Mix von alten und neuen Daten nicht - das stimmt. Städte und Kreise sind in Artikeln ja auch teilweise zusammen beschrieben; hattest du ja oben schon angemerkt, dass das in Portugal nicht konsequent und einheitlich ist. Auf den Ebenen Regionen, Subregionen und Kreisen passen die neuen Daten zusammen. Da werden (z.B. Vorlage:Verwaltungstabelle PT) die Vorlage:Metadaten Einwohnerzahl PT:NUTS mit Stand 2011 eingebunden - die hattest du mal angelegt. Die Vorlagen könnte man direkt auf die Vorlage:Metadaten Einwohnerzahl PT:COMP umstellen mit der Stand 2021. Grüße --Peterf (Diskussion) 08:38, 21. Aug. 2023 (CEST)

Ich habe mal einen Schalter in die Infobox_Ort_in_Portugal eingebaut. Im Prinzip funktioniert das; den ref-Namen müsste man noch entsprechend anpassen und dann auch die noch die Vorlage:Infobox Município in Portugal gleich behandeln. Das ganze ist aber vom Code recht unübersichtlich und ermöglicht nur die Anzeige der aktuelleren Einwohnerdaten innerhalb der Infoboxen. Daher noch mal einen Schritt zurück und die Frage, wie das ganze auf lange Sicht aussehen soll.

Hier mal meine Sichtweise:

• Einwohnerzahlen vor der Gebietsreform bleiben erhalten in der Vorlage:Metadaten Einwohnerzahl PT-01...30 - sind ja auch in über 600 Artikeln eingebunden
• Die aktuellen Einwohnerzahlen werden in der Vorlage:Metadaten Einwohnerzahl PT:COMP gepflegt und beinhalten bzw. ersetzen auch die Vorlage:Metadaten Einwohnerzahl PT:NUTS
• Der Abruf der Einwohnerzahlen bleibt unverändert über {{Metadaten Einwohnerzahl PT|NUT}} möglich (keine Spezialbehandlung innerhalb der Infoboxvorlagen)
• Ist für eine NUT ein (aktueller) Eintrag in der Vorlage:Metadaten Einwohnerzahl PT:COMP enthalten, wird dieser zurückgegeben; ist der Eintrag nicht vorhanden, wird in der Vorlage:Metadaten Einwohnerzahl PT-01...30 danach gesucht
• Entsprechend werden auch die Parameter QUELLE und STAND über die NUT Zuordnung (alt / aktuell) zurückgegeben

Damit werden wir die alten Daten und Strukturen nicht los, müssen aber in Zukunft nur noch eine Vorlage pflegen. Als Vorteil sehe ich, dass man keine Anpassungen in den Artikeln oder Infoboxvorlagen benötigt. Die Umstellung der Aufrufe von Vorlage:Metadaten Einwohnerzahl PT:NUTS nach Vorlage:Metadaten Einwohnerzahl PT müsste man einmalig angehen um dann überall auf dem gleichen Stand zu sein. Nachteil (wie von Tschubby oben beschrieben) ist bei der Lösung, dass die Summe der Gemeinden-Einwohner (alte NUTs) nicht der Einwohnerzahl des (neuen) Kreises übereinstimmt.

Für die Umsetzung habe ich folgenden Versuch gemacht: Vorlage:Metadaten Einwohnerzahl PT WEICHE - Idee ist diese Vorlage durch die Vorlage:Metadaten Einwohnerzahl PT zu ersetzen. Bitte mal checken, ob das so funktionieren kann - hab da nicht viel Erfahrung in der Syntax (aller Anfang ist schwer...).

Gibt es andere Ideen/Meinungen zum Vorgehen? Grüße--Peterf (Diskussion) 14:00, 24. Aug. 2023 (CEST)

Update: Ich habe die Weiche - wie oben beschrieben - in die Vorlage:Metadaten Einwohnerzahl PT eingebaut. Änderungen an der Vorlage:Infobox sind damit nicht nötig. Mir sind bisher keine Probleme mit der Lösung aufgefallen. Danke für die Diskussion und Inputs. Grüße --Peterf (Diskussion) 23:03, 13. Sep. 2023 (CEST)

Zwei Positionskarten in Infobox

Siehe Vorlage Diskussion:Infobox Siedlung in Grönland#Zwei Karten. Ich hätte gerne zwei Positionskarten in der Infobox, da die grönländische Geografie dafür sorgt, dass eine Karte über ganz Grönland relativ aussagelos ist (wie eine Deutschlandkarte, bei der alle Orte auf Inseln oder dem Festland an der Nord- und Ostseeküste liegen). Benutzerin:Lómelinde weiß aber nicht, wie man zwei Positionskarten in die Infobox bekommt. Kann jemand anderes aushelfen? :) --Kenneth Wehr (Diskussion) 09:49, 6. Aug. 2023 (CEST)

so wie in en:Hanover wird das nicht werden, dazu gab es meines Erachtens hier schon einmal eine Diskssion. Ich weiß aber nicht mehr genau, warum das im Sande verlaufen ist. Es kann sein, dass die allgemein notwendigen Änderungen mehr als nur die Infobox betrafen und dies nicht umgesetzt werden sollte. --darkking3 ^Թ 19:21, 7. Aug. 2023 (CEST)

Wenn man Vorlage:Infobox Ort in Russland als Vorbild für zwei Karten nimmt, sollte bedacht werden, dass allein der ISO-Code zur Einbindung der korrekten Detailkarte nicht reichen wird, wenn für Kommuneqarfik Sermersooq zwei Karten gemacht werden sollen (West- und Ostküste). Entweder man kann das händisch steuern oder es passiert über eine Lageabfrage westlich bzw. östlich von 46° W. NNW 22:56, 7. Aug. 2023 (CEST)

Wenn man zusätzlich noch den Distrikt abfragt, geht es. Wenn man Platz sparen möchte, kann man statt einer Auswahl per Anklicken wie in der enwp auch einklappbare Karten wie Lómelindes Vorschlag nehmen. --Kenneth Wehr (Diskussion) 05:54, 8. Aug. 2023 (CEST)

Im Portal Luftfahrt gibt es gerade eine ähnliche Diskussion mit einer sich abzeichnenden Lösung. Portal_Diskussion:Luftfahrt#Kartenvorschau_in_der_Flughafen-Infobox. Gruß --Grullab (Diskussion) 09:12, 12. Aug. 2023 (CEST)

Danke für den Hinweis! @Carsten Steger: Ich finde die Lösung hervorragend. Kannst du das auch hier zurechtbasteln? --Kenneth Wehr (Diskussion) 10:19, 12. Aug. 2023 (CEST)

Aasiaat (Qeqertalik) Aasiaat

Hallo Kenneth Wehr, vielen Dank für Deine Anfrage. Das, was gerade für die Vorlage:Infobox Flughafen diskutiert wird, basiert auf der Funktionalität Vorlage:Positionskarte#Karte in einer Ecke. Angewandt auf ein Beispiel aus Grönland würde das wie die Karte rechts aussehen. Da sieht man leider schon ein Problem: der rote Rahmen, der in der Grönlandkarte in der Ecke auftauchen sollte, wird leider an der falschen Stelle angezeigt. Woran das liegt, weiß ich leider nicht. Das müsste sich jemand ansehen, der sich mit der Kartenprogrammierung besser auskennt als ich. Viele Grüße --Carsten Steger (Diskussion) 18:55, 12. Aug. 2023 (CEST)

Ich würde raten, dass das daran liegt, dass die Vorlage nicht weiß, wo sich der Kartenausschnitt in Grönland befindet. Das muss ja irgendwo definiert sein. Da müsste ich aber auch erstmal suchen. --Kenneth Wehr (Diskussion) 20:18, 12. Aug. 2023 (CEST)

Ich kann sehen, dass hier andere Werte angegeben sind als beispielsweise hier. Ich glaube, dass durch das fehlende left/right zwar die Höhe den Rahmens stimmt, aber keine Breite oder Position angegeben werden kann. --Kenneth Wehr (Diskussion) 20:23, 12. Aug. 2023 (CEST)

Möglicherweise fehlt left und right bei der Vorlage:Positionskarte Grönland Qeqertalik, weil diese Karte eine längentreue Kegelprojektion verwendet. Damit ist die Projektion dieser Karte in eine übergeordnete rechtwinklige Karte kein Rechteck mehr. Ob und wie man diese Karte mit der Karte von Grönland in einer Ecke kombinieren kann, kann ich aber leider nicht beurteilen. Dazu fehlt mir die Erfahrung mit der Programmierung der Positionskarten.

Unabhängig davon ist mir anhand der Kategorie:Vorlage:Grönland aufgefallen, dass es derzeit nur für zwei der fünf Kommunen Grönlands Positionskarten gibt. Wäre damit der Ansatz mit der Karte in einer Ecke überhaupt sinnvoll? --Carsten Steger (Diskussion) 06:21, 13. Aug. 2023 (CEST)

Wie du sehen kannst ist die eine Karte vom 7. August (und ich habe sie selbst noch gar nicht gesehen :D), sprich sie sind dank Benutzer:NordNordWest gerade in der Erstellung. Und der weiß sicher auch genauer, wie das mit left und right funktioniert :) --Kenneth Wehr (Diskussion) 09:08, 13. Aug. 2023 (CEST)

Ich weiß nur, dass bei der Karte in der Ecke irgendwie der Wurm drin ist. Diese Funktionalität hat einige Macken, die alle paar Jahre wieder auffallen. Ich schätze, dass sie auch nicht mit anderen Projektionen als der Plattkarte auskommt. Hier haben weder die Grönland- noch die Gemeindekarten diese Projektion. NNW 17:06, 13. Aug. 2023 (CEST)

Da ich nicht davon ausgehe, dass die Projektion einfach so geändert werden kann, scheint Carstens Lösung hier nicht zu funktionieren. Dann müssen wohl trotzdem irgendwie zwei Karten untereinander her. --Kenneth Wehr (Diskussion) 12:35, 29. Aug. 2023 (CEST)

Mittlerweile gibt es Positionskarten für die gesamte Südhälfte der Westküste. Es fehlt noch die für Avannaata Kommunia, für die Ostküste wird wohl die Grönland-Gesamtkarte reichen, da dort praktisch keine Orte sind. NNW 08:25, 24. Aug. 2023 (CEST)

Fantastisch. Sobald eine Lösung für obiges Problem gefunden ist, werden ich anfangen, sie massenhaft einzubinden. Es ist richtig, dass an der Ostküste nicht so viele bewohnte Orte sind, aber dafür jetzt bereits 120 Artikel über geografische Objekte, die ja auch Karten benutzen. Insofern fände ich zwei Teilkarten dort auch angemessen, aber das darfst du natürlich entscheiden, ob du sie erstellen willst :) --Kenneth Wehr (Diskussion) 12:35, 29. Aug. 2023 (CEST)

Parteifarbe

Guten Abend. Modul:Partei ist ein neues Modul zum Verwalten der Parteienfarben. Das Modul:Partei/Liste enthält alle Farben, die heute in 88 Vorlagen enthalten sind. Diese Lösung wurde vor zwei Monaten besprochen, aber das Modul nur ein Entwurf war und ich hatte die Doku nicht geschrieben. Einige allgemeine Punkte wurden jedoch bestimmt: die Performance ist wesentlich besser mit Lua; die vorherigen Vorlagen sind nicht mehr vorbildlich; eine Ablösung der bisherigen Vorlagen durch performantere Nachfolger ist durchaus sinnvoll (vgl.). Zentralisierte Lösungen garantieren Einheitlichkeit und bieten einen Gesamtüberblick: dieser Grundsatz wurde auch in anderen Fällen angegeben.

Modul:Partei/Liste ist die einzige „Datenbank“, die Parteienfarben enthält. Die Liste enthält Zeilen: jede Partei ist in einer Zeile enthalten.

Das Modul hat zusätzliche Funktionalitäten. Die Funktionalitäten werden von 3 Vorlagen verwendet: Vorlage:Parteifarbe, Vorlage:Parteinamefarbe und Vorlage:Parteifarbezelle.

Vorteile.

1. Praktische Zwecke. Die Farbenliste wird automatisch generiert: wir sollten keine Doku schreiben (z. B. Vorlage:Wahldiagramm/Partei/Doku/PT), da die Liste der Farben autogenerisch ist (Farbenliste).

2. Funktionalitäten.

Alte Lösung	Neue Lösung
Quelltext	Quelltext	Ausgabe	Farbe
#{{Wahldiagramm/Partei|SPD|dunkel|DE}}	{{Parteifarbe|SPD|DE}}	#E3000F

Der Name kann in verschiedenen Formen geschrieben werden (vgl. 3.1.1).

3. Einfachere Lösungen.

Die Schaffung einer Tabelle ist einfacher. Beispiele:

3.1. Parteinamefarbe

Quelletext	Ausgabe
{{Parteinamefarbe|[[Sozialdemokratische Partei Deutschlands]]}}		Sozialdemokratische Partei Deutschlands

Der Parteiname wird nur einmal geschrieben: die Vorlage zeigt die Farbe und den Parteinamen.

3.1.1 Der Name kann in verschiedenen Formen geschrieben werden:

Quelletext	Ausgabe
{{Parteinamefarbe|Sozialdemokratische Partei Deutschlands}}		Sozialdemokratische Partei Deutschlands
{{Parteinamefarbe|[[Sozialdemokratische Partei Deutschlands]]}}		Sozialdemokratische Partei Deutschlands
{{Parteinamefarbe|[[Sozialdemokratische Partei Deutschlands|SPD]]}}		SPD

3.2. Parteifarbezelle

Alte Lösung	Neue Lösung
Quelltext	Quelltext	Ausgabe
style="background-color:#{{Wahldiagramm/Partei|SPD|dunkel|DE}}"|	{{Parteifarbezelle|SPD|DE}}|

4. Automatisierung. Die hellere Farbe wird mit einer mathematischen Berechnung bestimmt: wir sollten keinen zweiten Farbcode schreiben.

Opazität: Standard Wert (Hintergründe mit Text).

Datum	Quelltext	Ausgabe
Standard Farbe	{{Parteifarbezelle|SPD|DE}}|
Hellere farbe	{{Parteifarbezelle|SPD|DE|V=H}}|

Opazität: Optional Wert.

Farben	Beispiele
{{Parteifarbe|SPD|DE}}|	Standard Farbe
{{Parteifarbe|SPD|DE|V=H}}|	Hellere Farbe (Standard Opazität)
{{Parteifarbe|SPD|DE|V=0.5}}|	Hellere Farbe (Optional Opazität: 0.5)

5. Alternative Farbe. Wir müssen den echten Namen der Partei schreiben (ohne „konventionelle Namen“, z.B. „ÖVPab2017“).

Partei	Quelltext	Ausgabe
Alte Lösung
ÖVP (seit 2017)	style="background-color:#{{Wahldiagramm/Partei|ÖVPab2017|dunkel|AT}}"
ÖVP (bis 2017)	style="background-color:#{{Wahldiagramm/Partei|ÖVP|dunkel|AT}}"
Neue Lösung
ÖVP (seit 2017)	{{Parteifarbezelle|ÖVP|AT}}|
	{{Parteifarbezelle|Österreichische Volkspartei}}|
ÖVP (bis 2017) → Alternative Farbe	{{Parteifarbezelle|ÖVP|AT|V=A}}|
	{{Parteifarbezelle|Österreichische Volkspartei|V=A}}|

6. Fehler. Das Modul meldet alle Fehler. Die Vorlage meldet keine Fehler, sondern ein Fehler in einer Vorlage (z.B. {) bricht die Vorlage und die Artikel.

7. Nutzbarkeit. Eine Farbe, die in einer der vorherigen Vorlagen enthalten ist, kann nicht von eine Modul verwendet werden. Eine Farbe, die in einem Modul enthalten ist, kann von einem anderen Modul und von den Vorlagen verwendet werden. Dieser Punkt ist sehr wichtig.

8. Anpassungsfähigkeit. Das Modul ist mit allen Vorlagen kompatibel.

Aller Anfang ist schwer... --Zukunft99 (Diskussion) 02:29, 22. Aug. 2023 (CEST)

Für mich ist das nur der Versuch, ein etabliertes Vorlagensystem im Alleingang und ohne Abstimmung zu legitimieren. Davon zeugen bereits ausführliche Diskussionen, die dem Nutzer bekannt sind (1, 2). Davon abgesehen, kann hier in der Werkstatt nur eine technische Klärung stattfinden und nicht die notwendige inhaltliche Klärung, nämlich ob das Umstellen überhaupt erwünscht ist. Trotzdem werden Vorlagen ohne Konsens betroffener Benutzer in diesem Bereich erstellt. Und für mich ist auch unverständlich, dass keine Hinweise angenommen werden: Die unter Punkt vier dargestellte Funktionalität ist vorab mit den entsprechenden Nutzern zu klären, eine solche Funktionalität kann zudem die Einfärbung ad absurdum führen, wenn opakere Farben an eine andere Partei vergeben sind. Auch kann es vorkommen, dass die helleren Farben aktiv festzulegen sind, da es dafür eine Quelle gibt. Eine Unterscheidung nach Ländern ist aus meiner Sicht ebenso notwendig, da es mehr als wahrscheinlich ist, dass es Parteikürzel in mehreren Ländern gibt. Auch zu Punkt sieben gibt es z.B. hier keine Hinweise. (Ich könnte es zwar nachvollziehen, jedoch bin ich mir eigentlich auch sicher, dass es auch beschrieben wäre.) --darkking3 ^Թ 15:26, 22. Aug. 2023 (CEST)

i. In der ersten Diskussion (1), erhielt dieses neue „System“ positive Rückmeldungen. Vor zwei Monaten war das Modul jedoch ein Entwurf. Ohne positive Meinungen, hätte ich diese Arbeit nicht abgeschlossen!

ii. Die bisherigen Vorlagen funktionieren nur mit Akronymen. Hier können wir vollständige Namen oder alternative Namen (Akronyme oder andere Kurznamen) verwenden. Wir können auch Wikilinks verwenden: [[Sozialdemokratische Partei Deutschlands]], [[Sozialdemokratische Partei Deutschlands|SPD]].

iii. Die Farbe wird der Partei zugewiesen. SPD ist nur ein alternativer Name. Bei Homonymie wird das Problem mit „SPD (DE)“ gelöst. Akronyme können (vorübergehend) dort bleiben, wo sie sind (Vorlage:Wahldiagramm/Partei/DE/Test). Es gibt auch effizientere Lösungen, aber das ist ein anderes Kapitel.

Farbe	Beispiele
{{Parteifarbe|SPD|DE}}|	Standard Farbe
{{Parteifarbe|SPD|DE|V=H}}|	Hellere Farbe (Standard Opazität)
{{Parteifarbe|SPD|DE|V=0.5}}|	Hellere Farbe (Optional Opazität: 0.5)
{{Parteifarbe|Sozialdemokratische Partei Deutschlands}}|	Standard Farbe
{{Parteifarbe|Sozialdemokratische Partei Deutschlands|V=H}}|	Hellere Farbe (Standard Opazität)
{{Parteifarbe|Sozialdemokratische Partei Deutschlands|V=0.5}}|	Hellere Farbe (Optional Opazität: 0.5)

iii. Hellere Farbe. Das Problem wird mit „Alternativfarbe“ gelöst. Wir können jedoch keine dunklen Hintergründe haben, wenn wir Text haben.

iv. Die Farbenliste kann nach Staaten sortiert werden.

Ich möchte nichts aufdrängen. Die bisherige Lösung ist 14 Jahre alt, ist veraltet und behindert viele technische Fortschritte. --Zukunft99 (Diskussion) 16:56, 22. Aug. 2023 (CEST)

Die Vorlagendiskussion ist keine inhaltliche Diskussion und für entsprechende Rückmeldungen ungeeignet. Auch findet die inhaltliche Diskussion weiterhin nicht hier in der Werkstatt statt. Die Vorgehensweise bei Homonymie ist zu klären, ob dies so gewünscht ist. Zudem wäre dabei weiterhin zu klären, was passiert, wenn trotz notwendiger Unterscheidung diese nicht erfolgt. Auch können wir sehr wohl dunkle Hintergründe verwenden, dabei ist jedoch die Schrift umzufärben. Alles andere wäre auch eine Bevormundung des Nutzers. Auch eine Sortierung nach Farben ist unbrauchbar, da nur nach hexadezimalen Werten sortiert werden kann, die gefärbte Zelle selbst hat keinen Sortierwert. Wenn du nichts aufdrängen möchtest, wieso beachtest du dann nicht die Hinweise und stellst trotz entsprechender Hinweise Artikel auf "deine" Vorlagen um? Auch solltest du aufzeigen, welche technischen Fortschritte behindert werden. Eine reine Umstellung auf Lua ist jedenfalls keine herausstellungswürdige Verbesserung. --darkking3 ^Թ 17:09, 22. Aug. 2023 (CEST)

i. Vorgehensweise bei Homonymie. Beispiel.

Alternativer Name:

DKP (DE) = Deutsche Kommunistische Partei

DKP (DK) = Danmarks Kommunistiske Parti

Wenn ich einen Parteinamen schreibe, der nicht in die Liste eingefügt wurde → Default Farbe (#DABAD0):

Quelltext	Ausgabe (Default Farbe)
{{Parteifarbezelle|AbcDEFghi123!}}|

Diese Akronyme werden hauptsächlich in der Vorlage:Wahldiagramm und in der Vorlage:Sitzverteilung verwendet (ich hätte einige Vorschläge, aber dies ist ein weiteres Kapitel).

ii. Wenn wir eine helle Farbe verwenden möchten, aber wir wollen keine helle Standardfarbe verwenden, können wir die alternative Farbe verwenden.

iii. Die Sortierung nach Farben wurde eliminiert.

iv. Was ist der richtige Ort, um zu diskutieren? --Zukunft99 (Diskussion) 18:31, 22. Aug. 2023 (CEST)

Ich brauche keine Dokumentation der Vorlage/Modul, das hat das Objekt zu enthalten. Mit Punkt ii kann ich absolut nichts anfangen. Und ich verstehe auch langsam nicht mehr, warum auf Fragen (auch nach mehrmaligem Nachfragen) nicht geantwortet wird? Ich meine zwar, dass deutsch wohl nicht deine Muttersprache ist, aber deine unspezifischen und ausweichenden Antworten machen es mir und auch dir hier auch nicht leichter.

Inhaltlich dürfte wohl mindestens(!) Portal:Politikwissenschaft und Portal:Politik sowie vielleicht ein paar weitere aus Kategorie:Portal:Politik als Thema zu beteiligen sein. --darkking3 ^Թ 19:03, 22. Aug. 2023 (CEST)

Ich verstehe die Sprache! Ich verstehe einige Einwände nicht.

Ich habe die Vorteile beschrieben.

Funktionalität	Modul	Vorherige Vorlagen
Akronym	Ja {{Parteifarbe|SPD|DE}}	Ja #{{Wahldiagramm/Partei|SPD|dunkel|DE}}
Parteiname	Ja {{Parteifarbe|Sozialdemokratische Partei Deutschlands}}	Nein
Parteiname mit Wikilink	Ja {{Parteifarbe|[[Sozialdemokratische Partei Deutschlands]]}} {{Parteifarbe|[[Sozialdemokratische Partei Deutschlands|SPD]]}}	Nein
Parteiname + Farbe (Zwei Spalten in einer Tabelle)	Ja {{Parteinamefarbe|[[Sozialdemokratische Partei Deutschlands]]}}	Nein
Farbenliste	Automatisch	Manuelle (Manuelle Doku nach Staaten)
Hellere Farbe	Automatisch	Manuelle
Alternative Farbe	Ja {{Parteifarbe|ÖVP|AT|V=A}}	Ja nur mit konventionellen Namen, z.B. „ÖVPab2017“ #{{Wahldiagramm/Partei|ÖVPab2017|dunkel|AT}}
Gebrauchstauglichkeit von anderen Modulen	Ja	Nein⁠
Gebrauchstauglichkeit von anderen Vorlagen	Ja	Ja
Fehlerberichterstattung	Ja (in manchen Fällen: auch Ursache des Fehlers und Zeilennummer)	Nein
Teuren Funktionen	Nein	Nein

¹ 

expand Template 'Wahldiagramm/Partei/' .. staat, args = { } ({} ↔ Parameter = Parteinamen) ist realistischerweise nicht machbar (Lua reference manual)

Ich hoffe, dass die Einwände hier geäußert und diskutiert werden. --Zukunft99 (Diskussion) 23:06, 22. Aug. 2023 (CEST)

Du hast bis zu deiner letzten Antwort keine Vorteile aufgelistet, du hast nur rumgeschwurbelt, dass es welche geben soll. Das ist keine Grundlage für eine vernünftige und nachvollziehbare Kommunikation. Du musst mir zudem nicht die Vorlage erklären und die Vorteile auflisten, sondern denen, die diese Vorlage anwenden sollen! Das kann doch nicht so schwer sein? Und das gehört bei derart umfangreichen Änderungen dazu. Auch müssen alle von dir vorgeschlagenen Verbesserungen einen Konsens finden. Ich persönlich sehe bisher keinen von dir erzielten Konsens, da du dies offensichtlich sprachlich nicht verstehst und mir immer wieder irgendwelche "Vorteile" versuchst zu erklären. Deine Tabelle ist im übrigen missverständlich, den es gibt allein bei alternativfarbe kein einfaches ja und nein! Aber das habe ich vorher schon ausgeführt. Ebenso bei Parteinaname und Wikilink: Das alles muss durch die Anwender auch gewollt werden, eine Vorlagenwartung im ANR ist damit praktisch unmöglich, wenn mehrere Parameter den gleichen Output erzeugen. Das mag bei meisten Vorlagen unproblematisch sein, hier ist es allerdings essentiell. Auch können die ausgeschriebenen Parteinamen und wikilinks in die Vorlagen portiert werden, nur wer braucht das? Für die Fehlerberichterstattung muss übrigens die individuelle Konfiguration des Nutzers dazu passen. --darkking3 ^Թ 08:40, 23. Aug. 2023 (CEST)

Vereinheitlichung kann bis zu einem gewissen Grad nützlich sein, aber das scheint mir hier zu weit zu gehen. Außerdem ist es offenbar mit niemand abgesprochen. Es gibt übrigens deutlich mehr als die oben erwähnten 88 Vorlagen. -- Perrak (Disk) 17:25, 23. Aug. 2023 (CEST)

Guten Tag. Das Modul basiert auf einer technischen Prämisse: die vorherige Lösung ist veraltet und die alten Vorlagen sind nicht mehr vorbildlich. Dies wurde auch von einem sehr erfahrenen Benutzer wiederholt. Lösungen sollten effektiv und effizient sein.

Ich habe die Funktionalität des Moduls beschrieben, damit Benutzer die Details dieser Lösung bewerten und Änderungen vorschlagen können. Nichts ist unveränderlich. Was könnte geändert werden?

Das Modul hat Qualitäten, die die vorherige Vorlagen nicht haben können. Die Daten, die in dem Modul enthalten sind, können von anderen Modulen verwendet werden und das Modul zeigt einen Fehlerbericht (und der Filter könnte aktiviert werden zu verhindern „Änderungen veröffentlichen“...).

Ein kleiner Fehler in einer Vorlage, z.B. {, schädigt alle Artikel (> 5.000 Artikel).

wenn mehrere Parameter den gleichen Output erzeugen: Beispiel?

Namen mit Wikilink. Dies ist nützlich für Tabellen. z.B.: 1. Kongresswahlbezirk von Iowa#Wahlen ab 2002 oder Kabinett Scholz#Bundesregierung und Parlamentarische Staatssekretäre(en:Template:Party name with color).

Wenn eine Vorlage eine große Anzahl von Parteien enthält, gibt es eine Verschwendung von Parser-Funktionen: die Vorlage kann in „Kategorie:Wikipedia:Maximale Knotenanzahl überschritten“ enthalten sein.

Alle Daten können hier eingegeben werden. Es gibt keine Schwierigkeit: eine Partei kann leicht eingefügt werden, da es die Zeilen gibt. Meine Frage ist: das Modul hat technische Vorteile (Disk. 24., 25. Jun.) und konkrete Vorteile; was sind die Nachteile? Wenn es Nachteile gibt, welche Änderungen können vorgeschlagen werden?

Ich habe 89 Vorlagen gezählt (hier; die Vorlagen „Wahldiagramm/Partei/Doku“ sind ausgeschlossen). --Zukunft99 (Diskussion) 19:26, 23. Aug. 2023 (CEST)

Ein kleiner Fehler in einem Modul schädigt alle einbindenden Artikel. Das würde dann neben DE auch alle weitere 87 ersetzten Vorlagen betreffen. Das ist einfach haltlos. Es fehlt weiterhin der inhaltliche Konsens. Und wenn du PC so herausheben willst, dann setze doch bitte seine Vorgehensweise (wie z.B. hier) auch gleich um. Ich bin es langsam echt leid, dir gebetsmühlenartig immer wieder zu erklären, dass es nicht nur um technische Vorteile geht, sondern vor allem um die Akzeptanz der verwendenden Nutzer. Was im übrigen auch Teil der Wahrheit ist: Die Benutzer, die in Lua warten können, ist wesentlich kleiner, als derer, die das ganze in Wikicode können. D.h. auch dass wesentlich mehr Last auf einzelne verteilt wird, als das im jetzigen Vorlagensystem der Fall ist. --darkking3 ^Թ 20:13, 23. Aug. 2023 (CEST)

Ein kleiner Fehler in einem Modul wird von dem Modul hervorgehoben (❌1 in Modul:Partei/Liste); der Wikipedia:Bearbeitungsfilter kann "edit" verhindern. Wenn ein kleiner Fehler in einer Vorlage stattfindet, kein Heilmittel kann verhindern den Schäden.

Der Modul:Partei/Liste ist nicht in den Artikeln enthalten. Die Vorlage, z.b "Parteiname", invokes das Modul; das Modul returns einen Wert. Andere Lösungen können sein: Modul:Partei/ListeA (en:Module:Political party/A).

Die wahllose Verwendung von Lua ist falsch, aber Einheitlichkeit und Zentralisierung wurden als die richtigen Ziele angesehen (siehe). Dieses weitere Modul (Modul:Flagge) sollten vereinfacht werden (vgl. Modul:Flagge/Flaglist de A)...

Der Benutzer, der eine Partei einfügen möchte, sollte keine Programmiersprache ändern: Er konnte die Liste nur ändern. In der Praxis dieses Modul erfordert keine Wartungsfähigkeit: die Funktionen sind besonders einfach. Wir werden in den nächsten Jahren keine Aktualisierungsprobleme haben. Dieses Modul ist "grundlegend". --Zukunft99 (Diskussion) 21:56, 23. Aug. 2023 (CEST)

Fang doch bitte mal die inhaltliche Diskussion an, statt immer wieder "irgendwelche" Technikthemen anzuschneiden. Du musst mir Vorlagenprogrammierung und den umgang mit Modulen nicht erklären. Ein Programmierfehler in einem Modul kann auch durch Bearbeitungsfilter nicht in jedem Fall detektiert werden. Das ganze Thema hatten wir schonmal, da waren ausnahmslos alle Einbindungen einer Vorlage zerschossen. Deine Verwendung von Lua erscheint wahllos, da sie einfach mit keiner Menschenseele abgestimmt ist. Und auch PC hat es in 4 Jahren nicht geschafft, das Flagicon-Modul einzuführen. Das wird wohl auch erst nach den ganzen Coord-Zeugs passieren. Lua ist nicht das Allheilmittel, den es holt Abhängigkeiten an Bord, die nur noch eine Handvoll User in wp verstehen und v.a. warten, ändern und verbessern können. Es gibt jetzt schon zu wenig Wartungspersonal und mit solchen Vorlagen wollt ihr es noch künstlich beschneiden? Dein Beispiel hinkt zudem, ausweislich der von dir verlinkten Disk haben wir über 1000 Flaggen-Vorlagen, aber weniger Vorlagen zu Parteien. Auch ist deine Zukunftsausicht offensichtlich eine unbekümmerte, denn du kannst nicht wissen, welche Eigenheiten die Software als nächstes hat. Es scheitert bei Lua ja schon an der Serialisierung der Module, sodass einfach prüfbar wäre, wenn eines durch Änderungen in einer Sprachvariante outdated ist. Und das dass Modul für die von dir angedachte Verwendung grundlegend ist, braucht man bei einer Zentralisierung nicht erklären. Da ist jeden Modul für seinen Themenbereich "grundlegend". --darkking3 ^Թ 22:35, 23. Aug. 2023 (CEST)

@Darkking3: Meinem festen Eindruck nach ist das wieder einmal so eine sinnlose Ablehnung von Lua durch dich. Du verstehst offensichtlich nicht, dass hier niemand eine Umsetzung in Lua irgendwie "genehmigen lassen" muss, insbesondere auch nicht exklusiv von dir. Entscheidend für die Frage, ob mit Lua-Programmierung oder ohne, ist ausschließlich, ob Lua im konkreten Fall Vorteile hat. Das ist hier eindeutig der Fall. Wenn das zur Folge hat, dass ein Vorlagenautor dann nicht mehr klar kommt, weil er zwar Wiki- aber keine Luaprogrammierung kann, dann ist das ein Grund, sich in das Thema Lua einzuarbeiten. Das ist hier längst Standard. Ein Modul ist viel besser als irgendwelche "Monster-Vorlagenbündel". ÅñŧóñŜûŝî (Ð) 19:54, 25. Aug. 2023 (CEST)

Ich habe nie behauptet, dass die Verwendung von Lua "genehmigt" werden muss. Wohl aber die Umstellung der Systematik etablierter Vorlagen. Und damit bin ich ausweislich der Diskussionen nicht allein. Aber das möchtest du offensichtlich nicht wahrhaben. Es ist nunmal so, dass Vorlagen (auch mit einbindenden Modulen) denen folgten sollten, die Sie nutzen und nicht umgekehrt. --darkking3 ^Թ 10:36, 28. Aug. 2023 (CEST)

Das Modul wurde geschaffen, um zusätzliche Funktionen auszuführen. Die wichtigsten Funktionen des Moduls können von den vorherigen Vorlagen nicht ausgeführt werden, obwohl die Funktionen, die von den vorherigen Vorlagen ausgeführt werden, können von demselben Modul ausgeführt werden.

Zwei Kernpunkte gingen aus der anschließenden Diskussion hervor. 1) „Unser bisheriges Zeugs ist anderthalb Jahrzehnte alt und an vielen Stellen schon nicht mehr stabil. Jedenfalls nicht mehr vorbildlich. Die Performance hier [= mit Lua] ist wesentlich besser“. 2) Generell ist „eine perspektivische Ablösung der bisherigen Vorlagen durch zukunftsfähigere, performantere, skalierbare Nachfolger durchaus sinnvoll“. Die „Umstellung“ der bisherigen Vorlagen basiert auf diesem Argument. Und diese Behauptungen beruhten nicht auf persönlichen Vorlieben, sondern auf technischen Überlegungen.

Ein Lua-Upgrade kann Auswirkungen auf zukünftige Implementierungen haben. Das Modul wird durch zukünftige Lua-Upgrades nicht unbrauchbar werden. Das Modul enthält keine „instabilen“ Elemente. Im Übrigen nutzt dieses Modul Funktionen, die bereits von anderen Modulen umfangreich verwendet werden: z.B. mw.ustring.find und mw.ustring.sub (Modul:Str; Links auf diese Seite: > 5.000), oder einfache arithmetische Berechnungen (Modul:FormatNum; Links auf diese Seite: > 5.000).

Eine Unannehmlichkeit hat keinen Einfluss auf die Gültigkeit einer Perspektive, insbesondere in Fällen, in denen keine Unannehmlichkeit auftritt.

Fehler im Modul:Partei/Liste. Wenn ich „Labour Partei“ statt „Labour Party“ schreibe, hat der Fehler keine Auswirkungen auf die Artikel. Die einzige Konsequenz ist diese: Ich werde keine Farbe haben. Wenn ich „Hallo“ statt „#FFD800“ [Farbencode] schreibe, erhalte ich keine Farbe, aber das verursacht keine Fehler. Die einzigen Elemente, die Fehler verursachen können, sind " , { }. Diese Fehler werden jedoch immer vom Modul erkannt. --Zukunft99 (Diskussion) 01:04, 30. Aug. 2023 (CEST)

Ich weiß nicht, wie oft man dir noch sagen muss, dass auch eine inhaltliche Diskussion stattfinden muss, ob durch die Nutzer die Form der Anwendung so gewollt/gewünscht ist. Deine ständigen technischen Ausführungen brauchen nicht gebetsmühlenartig wiederholt werden. Mir scheint es, als ob du rein semantisch nicht den Unterschied zwischen einer technischen und einer inhaltlichen Diskussion verstehst. --darkking3 ^Թ 11:19, 30. Aug. 2023 (CEST)

Die Verarbeitung von Farben mit Modul ist nur eine technische Angelegenheit: Die Funktionen, die von den bisherigen Vorlagen ausgeführt wurden, werden vom Modul ausgeführt, aber das Modul hat jedoch keine Wirkung auf den Inhalt, das heißt auf die Ausgabe der alten Vorlagen. Eine inhaltliche Diskussion sollte die zusätzlichen Funktionen analysieren – d.h. die Funktionen, die vom Modul ausgeführt werden und die von der vorherigen Vorlagen nicht ausgeführt werden konnten –.

Und die zusätzlichen Funktionen sind eine Implementierung der vorhandenen Funktionen. Die Farbe wird nicht nur mit Akronymen (SPD), sondern auch mit vollständigen Namen (Sozialdemokratische Partei Deutschlands) und mit Namen mit Links ([[Sozialdemokratische Partei Deutschlands|SPD]]) aktiviert. Diese Funktion wird von der Vorlage:Parteinamefarbe verwendet. Diese Vorlage kann weiter implementiert werden, aber ihrer Zweck wurde vor mehr als zwei Monaten als gültig erachtet (vgl. en:Template:party name with color, hier).

Die Funktionalitäten des Moduls sind dokumentiert. Alle Vorschläge zur Änderung des Moduls werden sehr sorgfältig bewertet. --Zukunft99 (Diskussion) 04:58, 1. Sep. 2023 (CEST)

Eine inhaltliche Diskussion zu Vorlagen/Modulen ist i.d.R. zugleich eine technische Diskussion. Das lässt sich nicht immanent trennen. Eine (artikel)inhaltliche Diskussion hat mit den Anwendern zu erfolgen und die sehe ich bisher nicht. Deine in den Portalen hinterlassenen Hinweise sind ein Witz. Man stelle sich vor, die Bots zur Benachrichtigung würden nur Das könnte für dich wichtig sein schreiben, statt dies ausführlicher zu gestalten und Erklärungen zu geben.

Auch finden die inhaltlich-technischen Einwände bei dir keinen Eingang: Es sind abweichende opake Farben in den Vorlagen festgelegt, du gibst aber keine Möglichkeit, diese an die vorhandenen Vorgaben anzugleichen. Es kann (!) für die vorhandenen Farbwahl zu opakeren Farben eine Quelle/Vorgabe der betroffenen Partei existieren, sodass eine adäquate Übernahme nicht möglich ist. P.S.: In de. wp wird eine Vorlage dem Zweck nach nicht als "gültig" klassifiziert. Dabei erst recht nicht in im stillen Känmmerlein bzw. einer Diskussion mit "nur" zwei Benutzern. Wie soll den z.B. die Fehlererkennung erfolgen? Es kann bei ähnlichen Farben schnell übersehen werden, dass Tippfehler in Akronymen für ganz andere Länder gültig sind, wie soll dann durch den Nutzer eine einfache Prüfung zur Verifikation im Quelltext erfolgen? Aktuell einfach Möglich, wenn für Tippfehler dann ein Fehler beim aktuellen Land ausgegeben wird. --darkking3 ^Թ 10:50, 4. Sep. 2023 (CEST)

In gewisser Weise teile ich darkking3s Vorbehalte zu Lua. Weil ich es nicht verstehe und nur bedingt verändern/beeinflussen kann. Diese Vorbehalte sind aber hier völlig falsch. Die Entscheidung zugunsten von Lua ist, leider, schon vor Jahren gefallen. Und man muß zugestehen, daß ohne Lua eine vergleichbare Vorlage nicht möglich ist; das hängt mit Einschränkungen und Konfigurationen der Software zusammen, vor allem aus Performancegründen.

Tatsache ist folgendes. Ich habe vor Jahren anhand der Funktionalität wie in EN eine Vorlage speziell für US-Wahlergebnisse gebastelt, andere Benutzer haben ähnliches getan für andere Länder. Für Frankreich etwa gab es bislang keine Vorlage, die ähnliches getan hätte, wie meine ursprüngliche Vorlage für Wahlen in den USA. Vorliegendes Modul und die angelegten Vorlagen ermöglichen die Verwendung im Content Translation Tool für "Relationen" (damit meine ich Sprachpaare) in denen solche Module und Vorlage aufeinander abgestimmt sind. Ich bin bisher aber vor Artikeln zu Wahlen in Frankreich zurückgeschreckt, aus eben diesem Grund. --Matthiasb – ^{(CallMyCenter)} _{Wikinews ist nebenan!} 20:22, 3. Sep. 2023 (CEST)

Ich habe nie bestritten, dass Lua seine Vorteile und ebenso eine Daseins-Berechtigung hat. Nur sollten Inhalte (wie etwa Farben) so abgelegt werden, dass Sie durch mehr Nutzer gewartet/ergänzt werden können, als dies durch Lua weiter eingeschränkt wird. Man könnte rein theoretisch ganze Artikel(abschnitte) in Module wie in Vorlagen auslager. Ein Autor wird eine Vorlage aufgrund der für ihn verständlicheren Syntax eher bearbeiten als ein Modul. Ein Modul mit inhaltlichen Daten hat nunmal ein Zielproblem. Auch muss ich darauf hinweisen, dass im Regelfall eine Verwendung im Content Translation Tool deshalb möglich ist, da englische Vorlagen einfach nur in die entsprechenden Sprachvarianten übernommen werden und häufig keine weitere(n) Anpassung(en) erfolgen, obwohl dies ggf. im jeweiligen Einzelfall notwendig wäre. Es gibt in de.wp mehr als genug aus en.wp übernommene Vorlagen, die nicht gepflegt werden. Eine Serialisierung wäre daher einer der wenig sinnvollen Ansätze, nur auch das ist nicht passiert, ebenso auch ausweislich deiner Anfrage. --darkking3 ^Թ 15:25, 4. Sep. 2023 (CEST)

• Es gibt keine opake Farbe: Es gibt hellere Farben. Die hellere Farbe wird automatisch berechnet:

hellere Farbe = Standardfarbe + Wert der Opazität

Der Wert der Opazität ist immer von 100% (= Standardfarbe) bis 0% (= Weiß) anpassbar. Alle hellere Farben sind immer anpassbar.

Quelltext	Farbe	Ausgabe
{{#invoke:Partei|hellere|Sozialdemokratische Partei Deutschlands|w=1}}	Wert der Opazität = 1 → Hellere: 0 % (= Standardfarbe)
{{#invoke:Partei|hellere|Sozialdemokratische Partei Deutschlands|w=0.5}}	Wert der Opazität = 0.5 → Hellere: 50 %
{{#invoke:Partei|hellere|Sozialdemokratische Partei Deutschlands|w=0.2}}	Wert der Opazität = 0.2 → Hellere: 80 %
{{#invoke:Partei|hellere|Sozialdemokratische Partei Deutschlands|w=0}}	Wert der Opazität = 0 → Hellere: 100 % (= Weiß)

• Wenn eine hellere Farbe nicht auf der Standardfarbe basieren sollte, muss die alternative Farbe geschrieben werden.
• Gleiche Akronyme. Die Begriffsklärung löst das Problem. Übrigens: Auch die vorherigen Vorlagen enthalten gleiche Akronyme und das Problem ist auf die gleiche Weise gelöst. Z.B.: Vorlage:Wahldiagramm/Partei/DE:

|FW(BW) = {{#switch: {{{2|}}}|hell=a4c8eb|dunkel=63B8FF|link=[[Freie Wähler Landesverband Baden-Württemberg|FW]]}}

|FW(BY) = {{#switch: {{{2|}}}|hell=F5BE95|dunkel=FF8000|link=[[Landesvereinigung Freie Wähler Bayern|FW]]}}

Die vorherige Vorlage ist komplizierter {{#switch:, {{{2, }}, }}}) und Syntaxfehler können nicht gemeldet werden:

|DSP-1 = {{#switch: {{{2|}}}|hell=cf8563|dunkel=b35b31|link=[[Deutschsozialistische Partei|DSP]]}}

|DSP-2 = {{#switch: {{{2|}}}|hell=bd7a5a|dunkel=a85934|link=[[Deutschsoziale Partei|DSP]]}}

|DSP-3 = {{#switch: {{{2|}}}|hell=c6d198|dunkel=a1b45a|link=[[Deutsche Sportpartei|DSP]]}}

• Die Einführung einer Farbe bedeutet nicht die Modifikation des Moduls. Nur die Farbenliste muss geändert werden. Und die Syntax von Modul:Partei/Liste ist einfacher als die Syntax der vorherigen Vorlagen: Es gibt Zeilen; Die Syntaxfehler werden immer gemeldet.
• Die alten Vorlagen sind eine mittelalterliche Lösung. Das Modul macht unsere Arbeit schneller, einfacher und effizienter.

--Zukunft99 (Diskussion) 16:10, 4. Sep. 2023 (CEST)

Ungenau ausgedrückt: Opakere Farben, Beschreibung ist aus meiner Sicht nicht dokumentiert. Gleiche Akronyme auf Landesebene machen da noch ein ganz anderes Fass auf: Mit FW (BY) könnte auch eine Partei in Belarus gemeint sein, auch haben nahezu alle größeen Deutschen Parteien auch Artikel zu allen Landesverbänden, die dann auch verlinkt werden? Und die Farbliste ist ein Modul, es steht im Modul-Namensraum, der exklusiv für Lua-Module reserviert ist. Tippfehler im ANR werden bei Verwendung des Moduls eben nicht gemeldet, und fällt v.a. weniger auf, da es sicherlich irgendeine Partie mit dem dann falsch geschriebenem Akronym gibt. --darkking3 ^Թ 16:41, 4. Sep. 2023 (CEST)

Modul:Partei/Liste verwendet keine Programmiersprache (dies ist der wichtige Punkt) und kann einfacher aus mobilen Geräten geändert werden (es gibt Zeilen; es gibt keine Klammernsequenz).

Im Modul basiert die Farbe immer auf dem vollständigen Parteinamen, normalerweise auf dem Namen, der den Titel des Artikels darstellt: daher wird die Farbe immer in eindeutiger Weise definiert. Die Farbe basiert nicht auf einem Akronym, wie in den alten Vorlagen. Im Modul spielt das Akronym eine andere Rolle: Es repräsentiert nur einen Alias, wenn es als ein alternativer Name definiert ist. Das Akronym „erbt“ die Farbe, die für den vollständigen Parteinamen geschrieben wurde.

Lösung	Eingang	Ausgabe
Vorlage	Akronym	[[Vollständiger Parteiname|Akronym]], Farbe, hellere Farbe
Modul	vollständiger Parteiname	Farbe, Kurzname (Akronym), hellere Farbe

Das Modul hat eine zusätzliche Option: wenn Alternativer Parteiname → Vollständiger Parteiname, dann Farbe(Alternativer Parteiname) → Farbe(Vollständiger Parteiname). Das Akronym kann als Kurzname oder als alternativer Name definiert werden. In diesem zweiten Fall wird die Homonymie zwischen Akronymen durch Begriffsklärung gelöst.

Dies ist unvermeidlich, aber es gibt einen Unterschied. In den Vorlagen, die auf dem Modul basieren, muss die Nationalität nur im Falle der Mehrdeutigkeit geschrieben werden. In alten Vorlagen ist die Nationalität immer obligatorisch.

Neue Vorlage	Alte Vorlage	Komm.
{{Parteifarbe|AfD}}	#{{Wahldiagramm/Partei|AfD|dunkel|DE}}	Es gibt keine Homonymie
{{Parteifarbe|SPD|DE}}	#{{Wahldiagramm/Partei|SPD|dunkel|DE}}	Wenn ein mehrdeutiges Stichwort eine Hauptbedeutung hat, die deutlich geläufiger ist als die übrigen
{{Parteifarbe|DKP (DE)}}	#{{Wahldiagramm/Partei|DKP|dunkel|DE}}	Es gibt Homonymie

Die Homonymie zwischen Akronymen auch zwischen den Parteien desselben Staates stattfinden kann. FW(BY): Es gibt keine technischen Unannehmlichkeiten, denn in Belarus gibt es keine Partei namens FW. FW (Bayern) ist jedoch klarer und verständlich. Die Einstellung eines Standards beseitigt Zweifel.

Das Akronym kann nicht den Schwerpunkt des Systems darstellen: Es wird immer Unannehmlichkeiten geben. Und Lösungen wie DSP-1 =, DSP-2 = , DSP-3 = sind technisch nicht verfeinert.

Eine perspektivische Lösung ist die Verwendung der Funktion kurzname (Diese Funktion wird derzeit nicht verwendet):

{{#invoke:Partei|kurzname|Deutschsozialistische Partei}} → [[Deutschsozialistische Partei|DSP]]

Dies würde die vollständige Entfernung der 89 Vorlagen. Nicht nur die Farben, sondern alle Vorlagen würden beseitigt. Dies ist jedoch ein weiteres Kapitel. Das Modul verwaltet derzeit nur die Farben und verwendet Namen und Akronyme als Eingabe. --Zukunft99 (Diskussion) 03:40, 5. Sep. 2023 (CEST)

Ach ja... Dein Listenmodul muss einer bestimmten Lua-Syntax folgen, es steht im Modul-Namensraum und ist damit ein Lua-Modul. Auch bin ich mir nicht sicher, was du mit ohne Klammern meinst, da dein Listenmodul zwei unterschiedliche Klammern verwendet, nämlich geschweifte Klammern und eckige Klammern. Un du beschreibst selber das Problem: Wie erkennt das Modul eine Falschschreibung, also dass in einem Artikel (i.d.R. ja über ein definiertes Land) ein falsches bzw. für dieses Land nicht definiertes Akronym vorliegt? Im Übrigen verwendet die de.wp ISO 3166, sodass eine Angabe wie FW (Bayern) nicht gewollt ist. --darkking3 ^Թ 09:36, 5. Sep. 2023 (CEST)

@Zukunft99: Was m. E. nicht funktionieren kann, wäre eine erforderliche Eingabe des kompletten Parteinamens als Parameter. Das gilt besonders für fremde Länder. Man denke nur mal an Franz. Namen mit diakritischen Zeichen. Hier muss man unbedingt gut merkbare Kürzel nutzen. Anwender der Vorlage(n) wollen markante Werte eingeben. Ich empfehle hier eine Kombination aus ISO-3166-1-Kodierliste und lokal gängiger Abkürzung. Insoweit ist Modul:Partei/Liste etwas bedenklich, weil die Tabellenelemente viel zu lange Benennungen haben. Es ist viel besser, hier kurz und knapp vorzugehen. Lange Werte nur zur Wahrung der erforderlichen Abwärtskompatiblität. Gruß von ÅñŧóñŜûŝî (Ð) 12:02, 5. Sep. 2023 (CEST)

Wenn ich das richtig verstanden habe, sind die gesprochene (lange) Werte neu, Akronyme mit einer Angabe nach ISO werden derzeit verwendet. Insofern gibt es da keine Abwärtskompatibilität. Aus meiner Sicht sollte die Liste in Einheiten nach ISO aufgeteilt werden, da sich daraus Vorteile ergeben: Nutzer kennen sich i.d.R. in einem Land aus, die Listenpflege nach Land ist einfach und intuitiv nachvollziehbar. Aktuell hat die Liste über 2000 alphabetisch sortierte Einträge, das kann keiner ernsthaft pflegen wollen. --darkking3 ^Թ 15:23, 5. Sep. 2023 (CEST)

1. @Antonsusi: Komplette Namen sind nützlich für Vorlage:Parteinamefarbe. Z.B.: Wahlergebnisse (vgl. Spanische Parlamentswahlen 2023):

Quelletext	Ausgabe
{| class="wikitable" | {{Parteinamefarbe|[[Partido Popular (Spanien)|Partido Popular]]}} (PP) | 8.160.837 |- | {{Parteinamefarbe|[[Partido Socialista Obrero Español]]}} (PSOE) | 7.821.718 |- | {{Parteinamefarbe|[[Vox (Partei)|VOX]]}} | 3.057.000 |}	Partido Popular (PP) 8.160.837 Partido Socialista Obrero Español (PSOE) 7.821.718 VOX 3.057.000

2. Akronyme, die nicht definiert wurden. Wenn ich in einem Artikel ein nicht definiertes Akronym (z.B. XYZ) schreibe, wird eine default Farbe angezeigt (→ #DABAD0). Z.B:

Quelltext	Ausgabe	Beispiel	Farbe
{{Parteifarbe|XYZ}}	#DABAD0	style="background-color:{{Parteifarbe|XYZ}}"|

Der Benutzer wird sehen, dass es keine gewünschte Farbe gibt: Der Benutzer kann dann die Farbe in die Liste einfügen.

Was passiert in den alten Vorlagen?

Quelltext	Ausgabe	Beispiel	Farbe (N/A)
{{Wahldiagramm/Partei|XYZ|dunkel|DE}}	XYZ	style="background-color:#{{Wahldiagramm/Partei|XYZ|dunkel|DE}}"|	style="background-color:#XYZ"|

Die Konsequenzen, die durch das Fehlen einer vordefinierten Farbe verursacht werden, hängen nicht von der technischen Lösung (Modul/Vorlage) ab. Das Modul bietet jedoch ein akzeptables Mittel.

3. Akronym: Nationalität. Die Optionen sind im Wesentlichen zwei.
i. Wenn es keine Homonymie gibt, kann ich nur das Akronym schreiben. Ich schreibe ein weiteres Element (Nationalität → Begriffsklärung), nur wenn es eine Homonymie gibt.
ii. Ich kann auf jeden Fall Nationalität schreiben.

4. ISO-3166-1-Kodierliste: Alpha-2 oder Alpha-3? Ich bin neutral. Ich bevorzuge jedoch das Kriterium, das für Flags verwendet wird: Vorlage:DEU, aber Vorlage:DE-BY; Vorlage:ESP, aber Vorlage:ES-AN; Vorlage:USA, aber Vorlage:US-FL. Daher:

• DKP (DEU) und DKP (DNK) → Alpha-3, aber
• XXX (DE-BY) und XXX (DE-BW) → ISO 3166-2, im Falle einer Homonymie zwischen Parteien desselben Staates.

5. Abwärtskompatibilität. Die „Funktion“ Akronym → [[Parteiname|Akronym]] ist in den alten Vorlagen enthalten (vgl. Vorlage:Wahldiagramm/Partei/DE/Test). Das Modul verwaltet derzeit nur die Farben.

#{{Wahldiagramm/Partei|CDU|dunkel|DE}}" = {{Parteifarbe|CDU|DE}}

#{{Wahldiagramm/Partei|CDU|hell|DE}}" = {{Parteifarbe|CDU|DE|V=H}}

6. Alphabetische/nach ISO Sortierung. Ich bin neutral (Ich kann den Vorgang in 2 Minuten ausführen). Die Farbenliste kann jedoch nach Staaten sortiert werden.

7. Modul:Partei/Liste [""] und {""}, sind einfachere Elemente als |XXX = {{#switch: {{{2|}}}|hell=|dunkel=|link=[[Parteiname|XXX]]}}. Und das Modul meldet die Syntaxfehler! --Zukunft99 (Diskussion) 20:48, 5. Sep. 2023 (CEST)

Du gehst bei Punkt 2, wie gehabt, von "intelligenten" Nutzern aus. (@all: Nicht böse verstehen ;)) Der DAU bzw. Anwender (so wie ich auch) wüsste gar nicht, dass die Farbgebung eine defaultfarbe wäre und würde diese mit großer Wahrscheinlichkeit akzeptieren. Zu 3.: Du kannst damit weiterhin keine Schreibfehler bei Akronymen erkennen,bei denen eine Homonymie entsteht. 4.: Wikipedia, wie auch die bestehenden Vorlagen (z.B. auch ) orientieren sich an Alpha 2. Damit ließe sich auch bei subnationalen Landesverbänden einfacher umschalten. {{Parteifarbe|SPD|DE}} könnte auf etwas anders verlinken als {{Parteifarbe|SPD|DE-BY}} Zu 5. Die Abwärtskompatibilität ist nicht bei allen Farben gegeben, die derzeit festgeschriebenen opakeren Farben sind derzeit nicht Teil der Liste und bei Angabe einer Opazität weichen diese vom Ist-Stand ab. Zu 7: Konstrukte mit notwendigen Anführungszeichen sind fehleranfälliger als Wikisyntax, da es je nach verwendeter Font im Eingabefenster dazu kommen kann, dass " identisch ist zu ''. Das klingt für dich vielleicht trivial, wir (de.wp) hatten jedoch über 130.000 nicht geschlossene Endtags, bei denen nicht wenige auf genau dieser Falschschreibung beruhen. (en.wp hatte mal 3,4 Mio und jetzt immer noch 1,9 Mio) --darkking3 ^Թ 10:38, 11. Sep. 2023 (CEST)

2. Farbe hat einen grundlegenden Zweck: Sie garantiert die Verständlichkeit einer grafischen Darstellung. Eine „falsche“ Farbe kann eine Unrichtigkeit verursachen, verhindert jedoch das „Brechen“ der Tabellen und garantiert die Verständlichkeit. Die default Farbe ist in verschiedenen Fällen nützlich: kleine Parteien, die nicht klassifizierbar sind; Unbekannte Farben; Nicht existierende Farben. In diesen Fällen wird die Farbe willkürlich ausgewählt (die Farbe wird nur für grafische Erfordernisse ausgewählt).

3. und 4. Liste der Akronyme (Sortierung nach Staat): hier. Die Beziehung Akronym → Partei ist in die Doku geschrieben. Ein Akronym kann von mehr als einer Partei verwendet werden: In diesem Fall muss der Benutzer die Doku lesen (vgl. die alten Vorlagen). Es gibt eine Alternative: Ein Benutzer kann die Doku ignorieren und den kompletten Namen schreiben.

Die Relation Akronym = Partei(Akronym) ist keine Funktion. Die Relation Partei = Akronym(Partei) ist eine (injektive) Funktion. Und in diesem Fall, Akronym = {{#invoke:Partei|kurzname|Parteiname}}

5. Die hellere Farbe wird vom Modul automatisch berechnet. In den alten Vorlagen musste ein bestimmter Code eingegeben werden. Die Ausgabe ist hier im Voraus bekannt.

7. Alle Syntaxfehler werden vom Modul hervorgehoben: Wenn ich '' anstelle von " schreibe, wird der Fehler hervorgehoben.

BEISPIEL 1: "DEU'' statt "DEU":

Jeder kann lesen: Error: [1756:71] unfinished string near '"},'

1756 ist die Zeilennummer

BEISPIEL 2: "DEU statt "DEU":

Ich möchte nicht sehr vorsichtig sein: Ich ignoriere die Mitteilung und klickte auf „Änderungen veröffentlichen“. In diesem Fall werde ich eine weitere Warnung lesen:

--Zukunft99 (Diskussion) 17:39, 16. Sep. 2023 (CEST)

@Zukunft99: Ich finde die ganzen langen Parteinamen als Elementbezeichner in den Tabellen sehr schlecht. Die Umsetzung ist in dem Punkt nicht gut gelungen, auch wenn das Modul wohl funktioniert. Das schreibt man nicht "aus dem Handgelenk". Du brauchst u. A. die Schritte:

1. Eine Liste der Mindestanforderungen, was das Modul machen soll, erstellen
2. Ein schematisches Flussdiagramm (nicht jedes "if" muss da drin sein)
3. Die Schnittstelle zwischen Wiki- Und Lua-Programmierung, also die Aufrufparameter (Name und Bedeutung) festlegen.
4. Festlegen der Luafunktionen vornehmen.
5. Auf spätere Editierbarkeit des Quelltextes achten (Also keine "Monster-Elementbezeichner"). Das ist für die Akzeptanz wichtig.
6. Code minimalistisch (d. h., ohne Abfangen von Fehlern, Design etc.) schreiben.
7. Ausgiebig testen und wenn es grundlegend läuft die etwaigen Fehler in übergebenen Parametern abfangen.
8. Der Code muss immer ausbaufähig bleiben.
9. Zuletzt: Eine sorgfältige detailierte Doku zum Modul schreiben.

Das ist also recht viel und richtig Arbeit. Gruß von ÅñŧóñŜûŝî (Ð) 00:40, 17. Sep. 2023 (CEST)

Eine vordefinierte Farbe, die nicht grau sein ist, kann von keinem Nutzer bei einem Fehler einfach identifiziert werden. Selbst ein Brechen der Syntax und damit der Tabelle erscheint mir sinnvoller als irgendeine willkürliche Farbe, bei der nicht einmal du selbst auf Anhieb bei ANR-Arbeit erkennen kannst, dass keine Definition vorliegt.

Derzeit muss kein Nutzer eine Doku lesen und du "verlangst" dies? Und er soll, wenn er das Akronym nicht kennt, den vollständigen Namen einer Partei schreiben können? Du verlangst ganz schön viel von den Nutzern ab. Ich vermute mal, dass die wenigstens Nutzer dies bei fremdsprachigen Parteien hinbekommen, das dürfte schon bei inländischen Parteien schwierig werden. Und dabei besteht immer wieder das Risiko, dass selbst Schreibfehler in den vollständigen Namen vorkommen, die dann mit Default belegt sind. Für mich eine wahnwitzige Idee, die keiner pflegen oder warten kann.

Und immer wieder der Hinweis, dass eine opakere Farbe auch per Quelle vorgegeben sein kann, du also keine Opazität akzeptieren könntest.

Ich brauch von dir auch keine Hinweise zu Syntaxfehlern in Lua-Modulen, ich kenne diese. Nur scheint dir das bisher nicht bewusst zu sein, dass du mir kindsgleich eine Anleitung liefern mussst.

Antonsusi hat alle Kritikpunkte sauber zusammengefasst. Bei Punkt 5 ist wie gesagt die Nutzerbeteiligung zu ergänzen, denn das hast du immer noch nicht getan. --darkking3 ^Թ 12:35, 17. Sep. 2023 (CEST)

Ich habe eine Änderung in Vorlage:Parteifarbe, die LintErrors erzeugt, rückgängig gemacht. Bitte über Alternativen / Behebungen nachdenken. MfG, Dwain 11:52, 24. Sep. 2023 (CEST)

Danke! --Zukunft99 (Diskussion) 12:49, 24. Sep. 2023 (CEST)

1. Komplette Namen sind unerlässlich. Dieses Konzept muss klar sein. Der vollständige Name ist nicht die Folge einer technischen Unannehmlichkeit: Diese Einstellung hat einen praktischen Zweck. Die neue Funktionalität ist die Automatisierung der Tabellen. Und die Automatisierung ist immer möglich, auch wenn wir Wikilinks haben:

	Partido Popular (PP)	8.160.837
	Partido Socialista Obrero Español (PSOE)	7.821.718
	VOX	3.057.000

Der in einer Tabelle geschriebene vollständige Parteiname ist ein ausreichendes Element, um die Farbe zu aktivieren. Niemand muss den Parteinamen zweimal schreiben (einmal für die Aktivierung der Farbe und einmal als Datum/Informationen). Der Parteiname wird nur einmal geschrieben: Er wird für zwei Zwecke gleichzeitig verwendet. Der erste Zweck ist die Aktivierung der Farbe; Der zweite Zweck ist der Informationsinhalt.
2. Eine weitere Klarstellung. Ich kann den vollständigen Namen oder das Akronym schreiben:

Funktionalität	Alte Vorlage	Neue Vorlage
Akronym	#{{Wahldiagramm/Partei|CDU|dunkel|DE}}	{{Parteifarbe|CDU|DE}}
Komplette Name	N/A	{{Parteifarbe|Christlich Demokratische Union Deutschlands}}

Offensichtlich muss ich die Akronyme kennen. Dieser Aspekt wurde von den neuen Vorlagen nicht geändert. Der vollständige Name ist eine zusätzliche und weitere Funktionalität, die die vorherige Funktionalität (die Akronyme) nicht ersetzt.
3. Der komplette Name als Elementbezeichner und das Akronym als Alias, oder das Akronym als Elementbezeichner und der komplette Name als Alias. Diese Alternativen sind technisch äquivalent. Die erste Alternative ist vorzuziehen: en.wiki basiert auf dem vollständigen Namen (vgl. Module:Political party/doc). Und das Mediawiki content translation tool basiert auf dem vollständigen Namen: Dieses Bedürfnis wurde vor drei Monaten hervorgehoben.
4. Hellere Farbe. In bestimmten Fällen muss die alternative Farbe verwendet werden.
5. Default Farbe. Die Farbe kann grau sein.
6. Doku. Wikipedia:Lua/Modul/Partei/en ist eine Zusammenfassung.
7. ISO 3166 Alpha 2: Ich werde die Tabelle vervollständigen.
--Zukunft99 (Diskussion) 13:28, 24. Sep. 2023 (CEST)

Bearbeitungshinweis in biograf. Artikeln bei Einpflege der Gestorben-Kategorie bzw. Eintrag in die PD

Bei der Anlage und der Aktualisierung biografischer Artikel wird im Fall verstorbener Personen häufig versäumt, diese auch in die zugehörigen Nekrologe einzutragen. Wäre es möglich, einen Echtzeithinweis bei der Bearbeitung einzupflegen, der auf die Notwendigkeit eines Eintrags in die Nekrologe hinweist? Dieser sollte nach Möglichkeit durch die Einpflege einer Gestorben-Kategorie und durch Eintrag des Todes in die Personendaten ausgelöst werden. --Jamiri (Diskussion) 15:47, 22. Aug. 2023 (CEST)

Ein Bearbeitungshinweis wäre jeweils durch Administratoren je Seite zu setzen, ggf. über eine Vorlage in der editnotice. Das ist aber bei nicht angelegten Artikeln schwierig. Ich halte es einfach für schlicht nicht umsetzbar. Einzige Möglichkeit wäre ggf. die Verwendung eines Bearbeitungsfilters. Dafür wirst du aber aus meiner Sicht keine Mehrheit bei den Administratoren finden, die solche Filter einrichten. Die Filter sollen eigentlich vor Missbrauch schützen und nicht Nutzer bei inhaltlichen Dingen bevormunden. Auch über PD wird dies nicht klappen, da die Vorlage nicht prüfen kann, ob ein Name auf einer Liste steht. Ich persönlich finde es übrigens auch bevormundend, dass bei Anlegen von Artikeln über verstorbene Personen diese auch in Nekrologen erfasst werden sollen. --darkking3 ^Թ 16:59, 22. Aug. 2023 (CEST)

Das hat nichts mit Bevormundung zu tun. Bei der Verwendung von BKS-Links wird man ja schließlich auch in Echtzeit darauf hingewiesen, doch bitte die Verlinkung zu prüfen. Bei Verwendung geografischer Infoboxen gibt es gleichfalls Hinweise bei fehlenden Parametereinträgen. Genau in diesem Sinne soll auch die von mir angefragte Bearbeitungshinweis funktionieren. Er garantiert keinen Nekrologeintrag, doch die Zahl unvollständiger Einträge könnte damit spürbar zurückgehen. --Jamiri (Diskussion) 17:14, 22. Aug. 2023 (CEST)

So ein Hinweis könnte jemanden abschrecken, der erstmals und zum einzigen mal editiert, um in der Einleitung ein Sterbedatum zu ergänzen. Wenn dann kommt "Ändere unten die PD", "editieren den Nekrolog", "vergiss nicht Wikidata", "targs auch in die Infobox ein" ... Das könnte ein Neuling durchaus als Bevormundung empfinden und ggfls. lieber überhaupt nicht editieren. --tsor (Diskussion) 17:28, 22. Aug. 2023 (CEST)

Werden Einträge ohne Belege gemacht (was bei Neulingen überwiegend vorkommt), schwebt über den Änderungen stets das Damoklesschwert des folgerichtigen Reverts mit Hinweis auf die überaus sinnvolle Belegpflicht. Wo ist da der Unterschied? --Jamiri (Diskussion) 20:45, 22. Aug. 2023 (CEST)

Was ich sagen will: Theoretisch kann man eine Menge Hinweise einblenden, aber das dürfte abschrecken. Und um bei dem hier diskutierten Punkt zu bleiben: Wenn jemand ein Sterbedatum einträgt, dann wäre viel wichtiger, einen Beleg zu nennen. Viel wichtiger als Nekrolog, Wikidata, Infobox, PD ... Diese Dinge können wir selbst ergänzen, ggfls. dem Neuling einen Hinweis geben, sofern er angemeldet editiert. --tsor (Diskussion) 22:25, 22. Aug. 2023 (CEST)

Wie wäre es damit: Solche Bearbeitungshinweise werden auf angemeldete Bearbeiter beschränkt. Die Artikel dieser Liste zeigen, dass die Fälle fehlender Nekrologeinträge ohnehin fast ausschließlich auf angemeldete Bearbeiter zurückgehen. Was ich sagen will: Die Lücke zwischen den Einträgen in den Gestorben-Kategorien und den Eintägen in Nekrologen wird zusehends größer. Es ist ein frommer (um nicht zu sagen hoffnungsloser) Wunsch, dass sich dies durch aufmerksame Nachbereiter ändert. Mein Vorschlag ist, dies mithilfe einfacher, nicht bevormundender, Bearbeitungshinweise zu erreichen. --Jamiri (Diskussion) 05:26, 23. Aug. 2023 (CEST)

Vorlagentechnik ist grundsätzlich ungeeignet, um derartige Nachrichten zu übermitteln.

• Es gibt praktisch keine Möglichkeit, mit Vorlagensyntax herauszufinden, wo ein Parameterwert neu hinzugefügt wurde oder gar eine Kategorie, und dann auch noch sinnvoll zu reagieren. Nach dem Abspeichern ist es komplett weg weil identisch.

Oben fiel aber schon mal das Schlagwort Bearbeitungsfilter.

• Diese Technik ist sehr viel besser geeignet, um solche Ereignisse zu registrieren.
• Es ist sehr aufwändig, jeden Edit zu überwachen. Deshalb gibt es diese Methodik.
• Es war auch schon einmal ein derartiger Filter in der Diskussion; allerdings eher wegen der Belegpflicht und Abwehr von Fake-Einträgen.
• Eine Einführung sähe ich weniger pessimistisch.
• Die Wirkung sollte sein: Markierung (Tag) setzen, ggf. kleiner Hinweis auf Belegpflicht.
• Mit der Markierung können bei den RClern und theoretisch bei zufälligen Artikel-Beobachtern Hervorhebungen ausgelöst werden. Die müssten dann selbst wissen, was sie tun.
• Die PD-Projektler sollten sich mit bisherigen Erfahrungen und Lösungen besser auskennen.

Die Sache mit der Eintragung jedes Todesfalls in den Nekrolog raffe ich nicht so ganz.

• Ob ein verstorbener australischer Ruderer und Olympiasieger von 1968 bei uns im Nekrolog vermerkt werden müsste, ist mir unklar.
• Wie normale Autoren wissen können, was dann auch noch ein „zugehöriger Nekrolog“ über das aktuelle Jahr hinaus sein soll, klingt überfordernd. Jazz, Sport, Film, Musik oder was? In einem Bearbeitungshinweis mit Sicherheit überfordernd und verwirrend.
• Kategorie:Gestorben 2022 hat 5.327 Einträge. Die möchte ich nicht alle auf einer ANR-Seite mit Details und Beleg aufgelistet sehen.
• Die Idee mit dem Nekrolog ist aus den Nuller-Jahren, als wir einige 10.000 Biografie-Artikel hatten. Nachdem wir eine Dreiviertelmilillion Personen-Artikel verwalten, und da quer durch die Jahrhunderte alle möglichen Menschen aller Kontinente ansammeln, muss es zur Fokussierung für die Nekrolog-Seiten irgendwas wie Relevanzkriterien geben. Ansonsten reicht die Kategorie.
• Alle PD-Geschichten werden von PD-lern überwacht; die haben Routine damit und bereiten ggf. auch mal nach.
• Durch Software wird überwacht, dass PD-Vorlage, Kategorie und Einleitungsabschnitt synchron sind, und ansonsten erfahrenes Wartungspersonal herbeigelockt.

VG --PerfektesChaos 09:06, 23. Aug. 2023 (CEST)

Danke für die ausführliche Rückmeldung. Wenn die Umsetzung technisch nicht auf sinnvolle Weise umsetzbar ist, dann ist das Ganze sicherlich hinfällig. Vor der Rückmeldung allerdings verspürte ich vor allem einen latenten Unwillen. – Folgendes zur Grundsatzfrage der Nekrologeinträge: Ausnahmslos jede verstorbene Person, welche die Relevanzkriterien erfüllt, sollte auch in den zugehörigen Nekrolog eingetragen werden. Das gilt übrigens auch für Rotlinks. Die Forderung nach einer „Fokussierung“ ist reichlich irritierend und würde die bisherige Praxis vollkommen über den Haufen werfen. Es gäbe die RK und dann noch zusätzlich eine spezielle RK für Nekrologe? Wenn Bearbeitungshinweise vorgeblich Neulinge abschrecken, dann diese Regelung ganz gewiss. --Jamiri (Diskussion) 09:32, 23. Aug. 2023 (CEST)

Das Problem dabei umreißt du doch selber schon: Wer soll in welchen zugehörigen Nekrolog einsortiert werden? Das kann man nicht einfach beantworten, da einzelne Fachbereiche auch in ihren Jahresartikel separate Listen führen. Alleine die von dir gewählte Begrifflichkeit schreckt schon ab, ich selbst wüsste nicht, welche Person in den jeweils zugehörigen Nekrolog einzusortieren ist. Mir fällt dabei gerade auf, dass die von dir erwähnten Automatismen bei BKLs und Infoboxen seitenspezifisch sind, also im jeweiligen Artikel zu ändern sind, deine Vorstellung jedoch seitenunspezifisch ist, da ein weiterer Artikel geändert werden soll. --darkking3 ^Թ 10:18, 23. Aug. 2023 (CEST)

Hier eine Übersicht über mögliche Einträge: Kategorie:Jahresübersicht, ich zähle da mindestens 11 verschiedene Möglichkeiten (ohne Kats mit einem Jahresartikel). --darkking3 ^Թ 10:25, 23. Aug. 2023 (CEST)

Die Nekrologe findest Du in der Kategorie:Nekrolog. Es ist keine Raketenwissenschaft, sich anhand eines bekannten Sterbedatums den zugehörigen Nekrolog herauszusuchen. Wer in der Lage ist, einem biografischen Artikel eine Gestorben-Kategorie hinzuzufügen und die Personendaten zu aktualisieren, schafft das mit Links. --Jamiri (Diskussion) 11:43, 23. Aug. 2023 (CEST)

Das ist wie gesagt, nur eine Möglichkeit. Allerdings hier nur technische Klärung, inhaltlich muss das woanders erfolgen. --darkking3 ^Թ 11:49, 23. Aug. 2023 (CEST)

(BK) @Jamiri:, hm diese Behauptung schafft das mit Links irritiert mich. Für die Kategorien und die Personendaten nutze ich das Script von Schnark. Dort geht das in der Tat mit Links. Bei den Nekrologen muss ich mir die Daten für die Vorlage per Hand zusammenkopieren. Das ist für mich nicht mit Links oder ist ein nettes Helferlein oder Skript an mir vorbeigegangen? Fragt sich, --Silke (Diskussion) 11:55, 23. Aug. 2023 (CEST)

@Silewe: Jamiri meinte sicherlich die Redewendung „etw. mit links schaffen“, nicht mit Links ;-) LG, --rolf_acker (Diskussion · Beiträge) 14:28, 23. Aug. 2023 (CEST)

@Silewe: Ich bin mir gerade unsicher, ob Du noch „on track“ bist. Hier geht's darum, ob die Möglichkeit der Entwicklung eines Tools besteht, mit dessen Hilfe während der Bearbeitung eines biografischen Artikels im Fall des Hinzufügens einer Gestorben-Kategorie bzw. Ergänzung der Personendaten um das Sterbedatum in Echtzeit ein Bearbeitungshinweis erscheint, in welchem höflich und nicht bevormundend darauf hingewiesen wird, man möge doch bitte auch den Eintrag in den zeitlich zugehörigen Nekrolog vornehmen – mehr nicht. Den zeitlich zugehörigen Nekrolog findet man, in dem man sich über die Kategorie:Nekrolog manuell vorarbeitet. Konkretes Beispiel: Jemand ist am 31. März 2020 gestorben; daraus folgt ein erforderlicher Eintrag im Nekrolog März 2020. Der Pfad dorthin lautet: Kategorie:Nekrolog → Kategorie:Nekrolog 21. Jahrhundert → Kategorie:Nekrolog 2020 → Nekrolog März 2020. Das reinste Kinderspiel. Bearbeiter mit ein wenig Erfahrung würden wahrscheinlich direkt den Nekrolog März 2020 anwählen. --Jamiri (Diskussion) 13:04, 23. Aug. 2023 (CEST)

@Jamiri: okay, also kein Helferlein, Schade... Und ja, ich hatte die Ursprungsfrage sehr wohl verstanden und die Argumente dagegen sind eigentlich alle schon genannt. Ich wollte als alte Häsin nur einen weiteren/neuen Aspekt hinzufügen. Den Nekrolog zu finden ist in der Tat einfach, der Eintrag selber aber leider umständlich und aus meiner Sicht fehleranfällig. Es gibt doch bereits die Personendaten bzw. , es wäre doch nett, wenn es ein Tool/Helferlein/Skript geben würde, welches die notwendigen Datenfelder für die Nekrologe zum manuellen Einfügen zur Verfügung stellt? Wenn das aber am Wunsch vorbei führt, dann vergiss meinen Einwand :-) Viele Grüße, --Silke (Diskussion) 13:19, 23. Aug. 2023 (CEST)

@Silewe: So etwas wäre ein nettes zusätzliches Helferlein. Vielleicht ließe sich sogar beides kombinieren: Das Tool/Helferlein/Skript für den Nekrologeintrag erscheint im Ereignisfall (Eintrag des Sterbedatums) schon im biografischen Artikel und nimmt nach Vervollständigung der Daten und dem Speichervorgang im verknüpften Nekrolog den Eintrag an der richtigen Stelle vor. Hier muss allerdings berücksichtigt werden, dass der Nekrologeintrag auch schon vor der Bearbeitung des biografischen Artikels erfolgt sein kann (z. B. bei Rotlinks) und Redundanzen zu vermeiden sind. --Jamiri (Diskussion) 13:36, 23. Aug. 2023 (CEST)

@Jamiri: so etwas in der Art stelle ich mir vor. @Wurgl: Du bist doch der Herr über Personendata. Wäre so etwas für Dich umsetzbar? Es gibt die Vorlage:Nekrolog/Zeile. Könntest Du Dir vorstellen, anhand der Personendaten und der Kategorien einen Vorschlag zu erzeugen wie bei Benutzer:Wurgl/8Schwestern? Das muss nicht morgen sein, aber so etwas in der Art vermisse ich schon seit Jahren... Die 8Schwestern musste ich jedoch in meiner Commons aktivieren, da ist sicherlich im Vorfeld bis zur Umsetzung noch viel zu beachten. Über Deine Einschätzung würde ich mich dennoch freuen, --Silke (Diskussion) 14:09, 23. Aug. 2023 (CEST)

Höchstens bin ich Herrchen. Muss mich da mal beim Nekrolog einlesen … wobei März 2020 ist einfach, da gibts Jahre die quartalsweise geteilt sind und solche die gar nicht geteilt sind. Aber das ist nicht das Problem. Ich hab bissl Kopfaua mit der richtigen Referenz und irgendwie muss die Info den Seitenaufbau nach dem Abspeichern der Änderung ja überleben. Viele Ideen, viel Kopfaua. --Wurgl (Diskussion) 14:18, 23. Aug. 2023 (CEST)

Ich muss mich nochmal einklinken:

• Vorlagentechnik ist grundsätzlich ungeeignet für diese Aufgabe.
  • Sie kann nicht zumutbar feststellen, wo etwas neu eingeführt wurde, und erst recht nicht nach dem Speichern.
  • Sie kann auch keinen „Bearbeitungshinweis“ einblenden, sondern maximal bei Quelltextbearbeitung (nicht VisualEditor) am Ende des Artikels einen Hinweiskasten in der Vorschau-Ansicht.
• Etwas bei jeder Bearbeitung auszuführen, zu prüfen ob ANR und ob Kategorie oder PD-Vorlage und ob was verändert ist hoch performancekritisch.
  • Wenn überhaupt, macht das ein erwähnter Bearbeitungsfilter.
  • Der würde aber nur „markieren“, was auch eine Auswertung in den folgenden vier Wochen ermöglicht, und allenfalls eine Erinnerung an die Belegpflicht beim Töten von Lemmapersonen darstellen, weil der Chef der einen rausschnmiss, oder die Ex oder der bööse Nachbar virtuell gekillt werden solle.
  • JavaScript für alle und neue und unerfahrene Menschen schließe ich aus.
• Helferlein gäbe es nur als individuell aktivierbares Benutzerskript. Weil wegen Performance und Wartung.
• Mit solchen „Bearbeitungshinweisen“ haben wir fast zwei Jahrzehnte Erfahrung.
  • Sie verschrecken gerade unerfahrene Menschen und führen dazu, dass abgebrochen und überhaupt nicht gespeichert wird.
  • Wir gehen außer bei gravierenden und missbräuchlichen Fällen dazu über, nur zu loggen, ggf. per Bot auf die BD eine nachträgliche Info zu schicken, und keinerlei derartige Anleitungen anzuzeigen.
  • Der Wunsch nach „zugehörige Nekrologe“ ist völlig überfordernd und viel zu kompliziert und deshalb unverständlich und nicht spontan lösbar und könnte zum Abbruch der Bearbeitung führen.
• Mir fehlt innerhalb der Personen-Projektseiten eine Anleitung, wie mit Nekrologen umgegangen werden soll, als eigenständige Unterseite.
  • Ich bezweifle, dass unter heutigen Bedingungen eine Seite mit >5000 Einträgen realisierbar ist; das würde maximal 300 Bytes pro Person bedingen, einschließlich ref und aller Syntax.
  • Das ist eine Vorstellung aus den Nuller Jahren.
  • Ich sehe auch nicht, dass wir den kenianischen Finanzminister von 1983 dort auflisten müssten.
  • Sollen die Jazz-Musiker nur dort oder auch bei den Musikern und dann auch noch einmal im allgemeinen Nekrolog eingetragen werden?

VG --PerfektesChaos 14:35, 23. Aug. 2023 (CEST)

Wir sind über „Bearbeitungshinweise“ dank Silke schon hinaus. Und auch das nochmals: Der kenianische Finanzminister erfüllt die Relevanzkriterien der WP. Also gehört er auch in den Nekrolog. Punkt. --Jamiri (Diskussion) 14:53, 23. Aug. 2023 (CEST)

Dann macht es mehr Sinn, den Nekrolog automatisiert zu erstellen wie auch die Liste der Biografien, da hat es dann auch Wurgl leichter. --darkking3 ^Թ 15:17, 23. Aug. 2023 (CEST)

Potsblitz, da bist Du mir zuvorgekommen, denn genau diese Idee kam mir gerade auch in den Sinn. Wäre es dazu vorab erforderlich, die Nekrologe zu „harmonisieren“? Bislang haben wir dort sehr unterschiedliche Einteilungen. --Jamiri (Diskussion) 15:56, 23. Aug. 2023 (CEST)

da wir erstmal nur technisch klären, wäre auch bereits für den Bearbeitungshinweis ein Konsens nötig. Dies gilt auch für eine Automatisierung bei den Nekrologen. --darkking3 ^Թ 16:02, 23. Aug. 2023 (CEST)

@Bernhard Diener: zur Info. (https://de.wikipedia.org/w/index.php?title=Spezial:Beitr%C3%A4ge&end=&namespace=all&newOnly=1&start=&tagfilter=&target=Bernhard+Diener&dir=prev&offset=20230813190115) --M2k~dewiki (Diskussion) 16:04, 23. Aug. 2023 (CEST)

Bedeutet das, dass ich erstmal keine Nekrolog-Listen mehr erstellen soll? Sorry, mit dem technischen Kram hab ich das hier nicht so. --Bernhard Diener (Diskussion) 20:59, 23. Aug. 2023 (CEST)

@Bernhard Diener: Zweck des Anpingens war, Dich darüber zu informieren, dass es Überlegungen gibt, Nekrologe zukünftig automatisiert anzulegen. Von einer Umsetzung sind wir aber noch weit entfernt. Deshalb lass Dich von Deiner bisherigen Tätigkeit zur Steigerung des Mehrwerts der WP nicht abbringen. Deine Meinung zu dem Thema ist hier gleichfalls von Interesse. --Jamiri (Diskussion) 07:00, 24. Aug. 2023 (CEST)

Ich denke mal, alles, was automatisch geht, erleichtert die Arbeit in Wikipedia, aber dafür müsste wohl zunächst mal überhaupt eine Liste bestehen, um sie vervollständigen zu können? Oder nicht? Wie gesagt, technisch ist bei und mit mir kein Blumentopf zu gewinnen... --Bernhard Diener (Diskussion) 08:21, 24. Aug. 2023 (CEST)

Die Nekrologe zu automatisieren ginge schon – bis eben auf die Einzelnachweise. das ist ein bissl sehr trickreich. Diese Woche hab ich aus Wikidata einen Link als Beleg für den Tod eingebaut: Spezial:Diff/236665444 Die Position an welcher die Referenz hängt könnte Kriterium sein, beim Titel "Ушел из жизни Сергей Бабков" würde der Bot grandios scheitern. Aber ist die Position Kriterium genug? Da hab ich Bauchschmerzen. Aus Wikidata übernehmen wäre auch eine Variante, aktuell haben wir 484.097 verstorbene Personen und 463.880 davon haben ein exaktes Sterbedatum … das bedeutet 463.880 Zugriffe auf Wikidata bzw. mehrere Stunden. Jetzt mal abgesehen davon, dass Wikidata auch nicht das Gelbe vom Ei für so eine Referenz ist dauert diese Zugriffe scon eine Zeit und sind ohne schlaue Optimierung für einen täglichen Lauf nicht gerade toll geeignet.

Allerdings stellt sich die Frage ob eine Nguyễn Thị Thúy Hằng (die lebt noch und soll noch lange leben, aber als Beispiel) in den Nekrolog soll und falls nein, wie soll ein Bot das ausbaldowern?

Und dann gibts noch die Sonderfälle mit unklarem Sterbetag bzw. -jahr und die Frage ob nur gesichtete Einträge in den Nekrolog kommen sollen.

Mit Helferlein wären die Probleme deutlich geringer. Da frage ich mich aber, ob ich nicht beim Besuch/Ansehen eines Artikels zu einer verstorbenen Person den Vorschlag zum Eintrag in den Nekrolog (falls noch nicht vorhanden) machen könnte. Nicht beim Hinzufügen des Sterbetags, sondern beim Ansehen was ja auch nach dem Abspeichern passiert. Hätte den Vorteil, dass auch die Altfälle nach und nach reinkommen und den Nachteil dass es vielleicht nervt wenn es zu häufig aufblitzt.

PS: Wenn PC das hier nicht haben mag, dann gerne irgendwohin verschieben. --Wurgl (Diskussion) 11:03, 24. Aug. 2023 (CEST)

Mir ging es auch nicht darum, schon mal mit der Harmonisierung anzufangen, sondern lediglich Notwendigkeiten zu ermitteln. --Jamiri (Diskussion) 16:10, 23. Aug. 2023 (CEST)

Wenn jemand probieren mag, in die eigene common.js folgende Zeile einfügen.

mw.loader.load('//de.wikipedia.org/w/index.php?title=Benutzer:Wurgl/Nekrolog.js&action=raw&ctype=text/javascript');

Das Dings meldet beim Angucken eines Artikels mit der Vorlage Personendaten und eingetragenem exaktem(!) Sterbedatum ob die Person im entsprechenden Nekrolog zu finden ist. Nicht erkannt wird, wenn die Person im falschem Nekrolog (falsches Jahr/Monat) eingetragen ist. In so einem Fall kommt halt 'Fehlt im Nekrolog <Jahr>'

Das Dings guckt nur, es ändert nix. --Wurgl (Diskussion) 16:58, 24. Aug. 2023 (CEST)

@Wurgl: Ich habe die von Dir angegebene Zeile in meiner commons.js in die nächstfreie Zeile eingetragen und dann den Browser neu gestartet, doch beim Aufruf von Ernest Shackleton passiert da gar nichts. Was mache ich falsch? --Jamiri (Diskussion) 19:29, 24. Aug. 2023 (CEST)

Hast du eventuell die Metadaten abgestellt, also siehst du den Personendaten-Block nicht? --Wurgl (Diskussion) 20:01, 24. Aug. 2023 (CEST)

@Wurgl: Jau, daran lag es. Jetzt funktioniert es, besten Dank. --Jamiri (Diskussion) 06:37, 25. Aug. 2023 (CEST)

Inzwischen ist das gefixt. Metadaten muss man nicht (mehr) anschalten. --Wurgl (Diskussion) 08:56, 25. Aug. 2023 (CEST)

Hallo Wurgl, auf der Seite Dean Ballinger kommt bei mir Nekrolog: Fehler beim Lesen der Links vom Nekrolog auf die aktuelle Seite (TypeError: missing.length is not a function) (bei Johann Heinrich Martens (Maler) und Svetozar Ilešič kommt dagegen Fehlt im Nekrolog) --M2k~dewiki (Diskussion) 09:59, 25. Aug. 2023 (CEST)

Fixed. Sorry. --Wurgl (Diskussion) 10:05, 25. Aug. 2023 (CEST)

@M2k~dewiki, LegoFCB, Jamiri, Silewe: Bei fehlendem Eintrag im Nekrolog bzw. fehlendem Nekrolog sollte jetzt ein zusätzlicher Tab erscheinen der zum Nekrolog führt. Außerdem ist schon bissl was für die Zukunft vorbereitet. Stay tuned! --Wurgl (Diskussion) 16:54, 27. Aug. 2023 (CEST)

@Wurgl, Tab gefunden und in Funktion. Danke nochmals --LegoFCB (Diskussion) 19:13, 27. Aug. 2023 (CEST)

Nur als Hinweis an die Runde, der Tab verschwindet nach erfolgtem Eintrag in den passenden N. --LegoFCB (Diskussion) 19:26, 27. Aug. 2023 (CEST)

Analog zu den Eintragungen im Nekrolog könnte die Eintragung in der Begriffsklärungsseite für den Familiennamen erfolgen, d.h.

• einerseits eine Liste von (neuen) biografischen Artikeln mit fehlendem Nekrolog-Eintragung analog zu Benutzer:APPER/PersonenBKL2 (Beispiel), eventuell auch mittels PetScan
• andererseits ein Helferlein zur Eintragung von biografischen Artikeln in der Familiennamen-BKL analog zum "fehlenden Nekrolog-Helferlein"

--M2k~dewiki (Diskussion) 01:43, 28. Aug. 2023 (CEST)

Das ist zu komplex. Da gibt es zu viele Sonderfälle wo Namen zusammengezogen werden; unterschiedliche Klammerausdrücke; mehrfache Name+Vorname etc. Das Script welches BKL2 erzeugt besteht größtenteils aus Tabellen für Sonderfälle. --Wurgl (Diskussion) 08:20, 28. Aug. 2023 (CEST)

Möglicherweise wäre auch eine umgekehrte Funktionalität sinnvoll, die für eine bestimmte, konkrete Nekrolog-Seite die fehlenden Einträge anzeigt und ggf. an den passenden Stellen einen Text zum Einbau vorschlägt, sodass man die vorgeschlagenen Änderung(en) nur mehr kontrollieren und bestätigen muss. --M2k~dewiki (Diskussion) 01:51, 28. Aug. 2023 (CEST)

Siehe teils Benutzer:Miebner/GND, ist aber auch gedacht um in der DNB die Sterbedaten zu ergänzen. --Wurgl (Diskussion) 08:20, 28. Aug. 2023 (CEST)

• 2016 gab es mal Spezial:Missbrauchsfilter/222 für ein paar Monate, der dann auch Markierungen für Beo und RC gesetzt hatte.
• Das wurde im selben Jahr durch stille Bot-Überwachung ersetzt, Benutzer:CamelBot/maintenance list/categories of the dead, für die Bearbeitungen der letzten zwei Wochen.
  • Die wird im Hintergrund diskret von Wartungspersonal überwacht; etwa hinsichtlich Belege oder böswilliger virtueller Tötung und Formalitäten wie Tempus, PD-Vorlage, Einleitungsabschnitt abgearbeitet.
• Der Filter wäre reaktivierbar, auch zur Erkennung der PD-Vorlage, wenn Markierung und/oder sehr kurze Hinweise betreffend Belegpflicht genutzt werden sollen.

VG --PerfektesChaos 21:17, 24. Aug. 2023 (CEST)

Mir wird's leider langsam zu technisch und die eierlegende Wollmilchsau muss es vielleicht auch gar nicht sein. Frage: Ist eine Automatisierung von Einträgen von Personen zumindest mit konkretem Sterbedatum denkbar, wenn diese in den Nekrologen noch fehlen? Wenn ja, sollte dies auch ohne Meinungsbild umsetzbar sein. Das entsprechende Tool wäre als hilfreiche Ergänzung zu verstehen, und nicht als Verdrängungsmaschine für die User, welche die Nekrologe bislang beackern. Es gäbe neben Routineeinträgen noch genug zu tun, Personen mit unbekanntem Sterbedatum manuell einzutragen. --Jamiri (Diskussion) 14:34, 25. Aug. 2023 (CEST)

Dazu müsstest du zuallererst den Nachweis erbringen, dass es unter heutigen Bedingungen überhaupt (noch) wünschenswert und ob der resultierenden Größe der Nekrolog-Seiten überhaupt zukunftsfähig ist, dass alle verstorbenen Personen in irgendeine und wenn ja welche Nekrolog-Seite aufgenommen werden sollen.

Ich vermisse eine konsensuale Projektseite Wikipedia:Nekrologe, die das näher erörtert und Handreichungen gibt, wann was welche „zugehörigen Nekrologe“ sein sollen, und dies auch projektweit akzeptiert wird.

• Gibt es irgendeine Organisation und Plattform als WikiProjekt, wodurch derartige Aktivitäten koordiniert würden?

Mein Eindruck ist, dass dies ein Relikt aus den Nuller Jahren ist, als wir einige 10.000 Artikel über Menschen hatten, und diese dann händisch in Nekrolog-Seiten eingetragen wurden.

Angesichts von drei Millionen Artikeln demnächst und irgendwann einer Million Personen fehlt mir eine realistische Betrachtung über Umsetzbarkeit sowie Sinn und Zweck.

Ich weiß nicht, was man auf einem Smartphone mit einer Tabelle von 5.000 oder dann 10.000 Menschen anfangen soll. Von vorn bis hinten durchlesen kann das niemand. In Zeitungen und Zeitschriften, gerade Fachpublikationen, gab es durchaus mal zum Jahresende einen Rückblick, wo ein oder vier Dutzend bedeutende Menschen fokussiert auf eine Region oder ein thematisches Umfeld mit Kurzbios gelistet wurden. Gab es vor Jahrhunderten auch als Bücher über die deutsche Öffentlichkeit mit 1.234 Einträgen. Das hat man sich in unseren Kinderjahren offenbar als Vorbild genommen, um alle auf dem Planeten verstorbenen Menschen aller Interessengebiete aufzuzählen.

Um eine Person zu suchen, bieten wir als Werkzeug die Begrenzung auf eine Kategorie mittels incategory: an, und dann Schlagwörter wie Orte oder Disziplinen aller Art. Damit bekommt man eine flexible Auflistung aus dem gesamten Artikelbestand mit individuell eingrenzenden Filtermöglichkeiten. Solch ein Suchergebnis als statische Wikitextseite für alle Einträge einer Kategorie weiterzuführen scheint mir weder sinnvoll noch nutzbar noch ob der Sprengung von Größenbegrenzungen speicherbar oder lesbar.

Wir haben auch das von Wurgl betreute APPER-Personensuchwerkzeug.

Um auf deine Frage zurückzukommen: Ja, es gibt vielerlei Möglichkeiten, um die momentanen Einträge einer Kategorie aufzulisten und genauso Hacks, um alle in der Seite verlinkten Artikel in eine Liste zu schreiben und dann beide Listen hinsichtlich unbalancierter Elemente zu vergleichen.

VG --PerfektesChaos 15:13, 25. Aug. 2023 (CEST)

Ich kann mit Deinen (sich wiederholenden) Bedenken schlicht nichts anfangen. Die Nekrologe sind so ausgelegt, dass dort alle nach den WP-Richtlinien relevanten Personen, die verstorben sind, eingetragen werden können. Es gibt de facto keine numerische Begrenzung pro Nekrolog. Ein Nekrolog könnte auch ausschließlich aus tausenden Rotlinks bestehen. Ob der Eintrag nun manuell oder automatisch geschieht, macht keinen Unterschied. Folglich benötigen wir keinen gesonderten Konsens, weil dieser Konsens über die Relevanzkriterien bereits abgebildet ist. – Somit bleibt, eine Machbarkeit vorausgesetzt, einzig und allein die Frage, ob die „Technikabteilung“ dem Bemühen einer vollständigen Abbildung der Artikel Verstorbener in den Nekrologen Vorschub leisten will oder sich dem widersetzt. Wie lautet die Antwort? --Jamiri (Diskussion) 17:36, 25. Aug. 2023 (CEST)

• „Es gibt de facto keine numerische Begrenzung“
  • Oh doch.
  • Das Limit an Wikisyntax nach Expansion aller Vorlagen usw. liegt bei 2 MB, für ein HTML-Dokument nach dessen Expansion bei 5 MB.
  • Heißt bei > 5000 Einträgen in einer Jahreskategorie, zuzüglich auch noch Rotlinks, maximal 300 Bytes (nicht Zeichen) pro Eintrag, einschließlich Tabellensyntax, Verlinkung, Daten und Beleg.
  • Wobei Seiten dieser Größe, erst recht auf einem Smartphone und bei langsamer oder teurer Internetverbindung, eine Frechheit sind.
• Das hier ist nicht die „Technikabteilung“.
  • Wir beschäftigen uns mit der Programmierung und Organisation von Vorlagen sowie mit Wikisyntax.
  • Mit deiner Anfrage haben wir überhaupt nichts zu tun und geben nur aus Freundlichkeit technisch-organisatorische Hinweise.
• Wenn du irgendwen dafür begeistern möchtest, sich mit deinem Aufgabenfeld näher zu befassen, dann müsstest du schon Sinn und Zweck und Konzeption und Projektseite und Arbeitsplattform konkret und präzise darlegen.

VG --PerfektesChaos 18:09, 25. Aug. 2023 (CEST)

Man kann fehlende Nekrologeinträge auch mit Petscan finden, etwa für 2023 .--Masegand (Diskussion) 18:48, 25. Aug. 2023 (CEST)

Das Wort „Technikabteilung“ war bewusst in Gänsefüßchen gesetzt. – Es mag technische Beschränkungen geben, jedoch keine, die sich für Bearbeiter aus WP-Richtlinien ableiten ließe. Es klingt beinahe so, als ob durch ein fehlendes Tool die Zahl der Nekrologeinträge künstlich niedrig gehalten werden soll. Das wäre völlig absurd. Dann könnten wir auch gleich alle Nekrologe löschen. Außerdem: Wo ist denn zu befürchten, dass ein Jahresnekrolog über 5000 Einträge enthalten könnte? Und selbst wenn, dann wäre eine Angleichung an die zuletzt vorgenommene Unterteilung in Monatsnekrologe auch kein großer Akt (ich fragte bereits zuvor nach Voraussetzungen; dass die eingeforderte Konsensfindung in diesem Punkt ein Zirkelschluss ist, habe ich bereits dargelegt). Pro Monat ist auch im Worst-Case-Szenario nicht mit derart hohen Zahlen zu rechnen. Und zu guter letzt zum dritten Mal und unter Voraussetzung einer machbaren technischen Umsetzung: Ist hier jemand bereit, ein Tool für automatische Einträge in Nekrologe zu entwicklen, das der WP-Gemeinde die auch ohne ein ebensolches zu leistende Arbeit in den Nekrologen erleichtert? --Jamiri (Diskussion) 19:17, 25. Aug. 2023 (CEST)

1945: 5164 Verstorbene, 2020: 5524, 2021: 5499 und 2022: 5338. Nicht dass die alle im Nekrolog eingetragen sind, aber das ist die Gesamtzahl derer, die einen Artikel hier in deWP haben. Dazu kommen noch die Rotlinks. --Wurgl (Diskussion) 19:38, 25. Aug. 2023 (CEST)

Ergo ist die Voraussetzung (wie schon oben angemerkt): Umstellung der Jahres- und Quartalsnekrologe auf Monatsnekrologe. Korrekt? --Jamiri (Diskussion) 19:43, 25. Aug. 2023 (CEST)

Hallo Wurgl, ich habe nochmal eine Rückfrage. In den meisten Fällen funktioniert die von Dir eingerichtete Hilfe einwandfrei. Ist Dir ein Grund bekannt, warum es Ausnahmen gibt? Bspw. Wird mir bei Ian Wilmut im Artikel eingeblendet, er sei im Nekrolog 2023 eingetragen. Gleichwohl ist er im Nekrolog September 2023 enthalten, was nicht angegeben wird. Danke und Grüße --LegoFCB (Diskussion) 19:10, 11. Sep. 2023 (CEST)

Da hab ich (fast) keine Chance das festzustellen. Jedenfalls ist er im Nekrolog 2023 sichtbar und nur das kann ich per API prüfen. Für solche Fälle sollte es eine Fehlerliste geben … ich glaube, Benutzer:Wurgl/Falsche Lebensdaten/Jahresseiten deckt das ab. Kannst ja bis morgen drinnen lassen, dann sehen wir das. --Wurgl (Diskussion) 19:23, 11. Sep. 2023 (CEST)

Hab mir fast so etwas gedacht. Aber wir schauen dann mal morgen rein. Grüße und Danke --LegoFCB (Diskussion) 19:42, 11. Sep. 2023 (CEST)

Oops. Muss ich wohl nachbessern. Da wird so einiges geprüft, aber die Nekrologe offenbar nicht. --Wurgl (Diskussion) 08:16, 12. Sep. 2023 (CEST)

Kann ich nicht mitreden, sieht aber für mich nach viel Arbeit aus. Ich drück die Daumen, bei der jeweiligen Lösung. Grüße --LegoFCB (Diskussion) 14:54, 12. Sep. 2023 (CEST)

@LegoFCB: ich hab die letzten Tage ein wenig gezaubert und in Benutzer:Wurgl/Falsche Lebensdaten/Jahresseiten (am Ende) gibts wohl einiges zu tun. Die Liste ist natürlich weit länger, bei 50kB stoppe ich das ganze, wenn gewünscht kann ich das länger machen. --Wurgl (Diskussion) 17:41, 26. Sep. 2023 (CEST)

Super, ich schaue es mir an. Vielen Dank für Deine *ZaUbErEi* --LegoFCB (Diskussion) 18:12, 26. Sep. 2023 (CEST)

Hallo nochmal Wurgl, ich habe mich am Beispiel 29. Juni || Walter Santos || brasilianischer Gitarrist || 77 || versucht, und habe den Eintrag korrigiert (Nekrolog 2008). Zum einen führt Dein Link in der Fehlerliste auf den Judoka Walter Santos. Der hier beschriebene Gitarrist war im Nekrolog nicht verlinkt, wobei ich dort nun einen Rotlink ergänzte, das Alter korrigierte und eine neue funktionierende Quelle hinterlegte. Würde denn der Eintrag bei der nächsten Prüfung aus Deiner Liste verbannt? Grüße und Danke --LegoFCB (Diskussion) 20:22, 26. Sep. 2023 (CEST)

Oh! Auf die Idee dass gar kein Link da ist, bin ich gar nicht gekommen. Und ja, nach Korrektur ist der nicht mehr auf der Liste. --Wurgl (Diskussion) 21:42, 26. Sep. 2023 (CEST)

Ja, auch das gibt es. Danke nochmals. --LegoFCB (Diskussion) 23:06, 26. Sep. 2023 (CEST)

DOI mit Sonderzeichen

Hi! In der Beschreibung auf Vorlage:DOI steht in der Tabelle bei Parameter 1, dass man Entitäten für Sonderzeichen eingeben soll, jedoch bekomme ich dann Fehlermeldung "Ungültig" wie bei dieser (zugegeben fiktiven) . Was dort in der Tabelle bei Parameter 1 steht, stimmt also nicht?

Hintergrund, warum mir das aufgefallen ist, ist die durchaus funktionierende und zielführende mit dem Doppelkreuz (Hash), die ebenfalls als "Ungültig" abgefangen wird. Gebe ich in die Browseradresszeile die URL https://doi.org/10.11588/diglit.52375#0228 werde ich aber problemlos weitergeleitet. In diesem Fall spielt aber wiederum Vorlage:Literatur nicht mit, wenn ich diese Adresse beim Parameter Online eingebe. Die DOI als ungültig kann ich dort auch nicht eingeben. Und was mach ich nun, da beides nicht geht? – Doc Taxon • Disk. • 15:49, 30. Aug. 2023 (CEST)

Ein DOI bezieht sich immer nur darauf, dass in den nächsten Jahrzehnten in irgendeinem Format irgendwie was Hilfreiches zu dieser Publikation im Internet zu finden sein möge, wenn überhaupt.

Ob das ein Abstract, der vollständige Text, nur bibliografische Metadaten, kostenfrei, kostenpflichtig sei, ist völlig unvorhersagbar.

Ob das vom Format her PDF oder TIFF oder HTML oder irgendein eBook wäre, ist absolut offen.

#228 ist wohl eine Fundstelle in einem HTML-Dokument, oder was weiß ich.

Es ist in einem DOI unerlaubt, weil du überhaupt nicht wissen kannst, ob nächstes Jahr oder in einem Jahrzehnt ein HTML oder vielleicht ein PDF oder sonstwas geantwortet wird und wie in dieser Aufbereitung irgendwas wie eine Abschnittsnummer, eine Seitenzahl oder was immer 228 bedeuten mag organisiert und wenn überhaupt mit Sprungzielen versehen sind.

Die genannten Sonderzeichen beziehen sich nur auf den Bezeichner für das gesamte Dokument. Die erlauben mir ohnehin neben Ziffern und Buchstaben aller Sprachen viel zu viele verschiedene Sonderzeichen.

VG --PerfektesChaos 16:39, 30. Aug. 2023 (CEST)

Danke, ja, ich finde auch, dass die viel zu viele Sonderzeichen erlauben. Also #228 steht für die absolute Seitenzahl in dem Dokument. Damit kann ich per Link nicht nur das Dokument aufrufen, sondern bekomme dort auch gleich die richtige Seite angezeigt, probiere https://doi.org/10.11588/diglit.52375#0228

Damit, denke ich, wäre diese DOI auch zulässig, die Vorlage lässt dies jedoch leider nicht zu. – Doc Taxon • Disk. • 10:51, 31. Aug. 2023 (CEST)

@PerfektesChaos: lässt sich da was machen? Vielleicht # in DOI-Adressen erlauben, damit entweder der Parameter DOI oder Online in Vorlage:Literatur funktionieren. Dass sich beide gegenseitig blockieren, ist worst case. Online-Parameter meldet Fehler, wenn DOI-Adresse als Wert drin steht, und DOI meldet Fehler, weil # in der Adresse steckt. Zumindest eines sollte möglichst funktionieren. – Doc Taxon • Disk. • 14:36, 3. Sep. 2023 (CEST)

Ein DOI bezieht sich immer nur darauf, dass in den nächsten Jahrzehnten in irgendeinem Format irgendwie was Hilfreiches zu dieser Publikation im Internet zu finden sein möge, wenn überhaupt.

Ob das ein Abstract, der vollständige Text, nur bibliografische Metadaten, kostenfrei, kostenpflichtig sei, ist völlig unvorhersagbar.

Ob das vom Format her PDF oder TIFF oder HTML oder irgendein eBook wäre, ist absolut offen.

Du kannst überhaupt nicht wissen, in welchem technischen Format unter welcher URL auf welcher Domain was für eine Aufbereitung bereitgestellt werden wird, und ob das überhaupt mehr als grad mal die Metadaten sein werden.

Du kannst auch überhaupt nicht wissen, falls überhaupt Sprungmarken verfügbar sind, ob die als #0228 oder #p228 oder #page228 oder #S228 vorhanden sein werden.

Es sind die vollständigen bibliografischen Angaben zu machen, und die Fundstelle ist im Klartext anzugeben, etwa über eine Seitenzahl, vielleicht zusätzlich auch noch über den Namen eines Abschnitts, wodurch sie auch in einem unpaginierten eBook gefunden werden könnte.

Zu welcher URL der DOI jetzt im Moment grad aufgelöst wird, und was da technisch innerhalb des heutigen Formats passiert, ist völlig belanglos und darf nicht verwertet werden. Den DOI verwenden wir statt einer URL eben gerade deshalb, weil sich die URL und auch die technische Aufbereitung im Lauf der nächsten Jahre jederzeit ändern könnte und das Format des Nachfolgers, wenn es ihn überhaupt geben würde, absolut unvorhersagbar ist.

Der DOI bezieht sich immer nur auf die Ressource in ihrer Gesamtheit, niemals auf die inneren Geheimnisse in der momentanen Realisierung.

Aus genau demselben Grund darf der Name einer Wiki-Seite auch niemals ein # enthalten.

VG --PerfektesChaos 19:06, 3. Sep. 2023 (CEST)

Ja okay, wie bekomme ich den Fehler jetzt dann raus: Alexander Koch: Deutsche Kunst und Dekoration: Illustrierte Monatshefte… Band 69, 1931, S. 200 (Digitalisat).  – Doc Taxon • Disk. • 03:58, 4. Sep. 2023 (CEST)

Der DOI lautet: 10.11588/diglit.52375

Wenn du die momentane Fundstelle direkt verlinken möchtest, musst du zusätzlich diejenige URL angeben, als dass dies jetzt grad aufgelöst wird.

Der DOI wird benötigt, wenn in einigen Jahren die momentane URL nicht mehr funktioniert, und das dann mit Glück in einer anderen Aufbereitung ermittelt werden muss.

Wie wenig dauerhaft diese Sprungziele sind, merkst du an #0228 gegen Seiten=200 – das zeigt, dass diese Digitalisierung 28 Seiten Titelblatt, Inhaltsverzeichnis, Vorwort usw. mitzählt. Jemand anders könnte das wieder anders nummerieren, das Vorwort mit römischen Ziffern, und die Seitenzahlen wie aufgedruckt, oder nach Heftnummern der „Monatshefte“. Oder ein eBook kennt überhaupt keine Sprungziele, nur Heftnummern und Überschriften.

VG --PerfektesChaos 12:16, 4. Sep. 2023 (CEST)

Ja okay, man müsste das wahrscheinlich dann auch auf einer Hilfeseite oder der Vorlagendoku irgendwo vermerken. Wenn ein Benutzer merkt, dass Parameter Online nicht verwendet werden soll bei DOI-Adressen, der Parameter DOI aber mit # auch geht nicht, könnte er wahrscheinlich "durchdrehen". Des Weiteren müsste in der Doku zur Vorlage DOI die Tabelle bei Parameter 1 korrigiert werden. Das Escapen der dort angegebenen Zeichen funktioniert nämlich nicht, siehe hier in der Disk erster Satz ganz oben. – Doc Taxon • Disk. • 23:50, 4. Sep. 2023 (CEST)

Wann wozu DOI eingesetzt werden, was sie bedeuten, was sie überhaupt sind, ist nicht Angelegenheit dieser einzelnen Vorlage.

Das betrifft Angaben von Literatur allgemein, im Prinzip auch einer permanenten „Internetquelle“.

Die genannte Vorlage generiert nur die Verlinkung, und prüft auf Gültigkeit.

Dein Begehren wäre zentral für alle Nutzungen, egal ob mit Vorlagen oder ohne, auf WP:ZR aut idem zu klären.

Eine „Hilfeseite“ käme nicht in Frage; DOI sind keine Angelegenheit der MediaWiki-Software.

VG --PerfektesChaos 00:39, 5. Sep. 2023 (CEST)

Vorlagen FIFA.com und UEFA.com

Hallo, die Vorlage {{FIFA.com}} ist wohl schon seit Längerem ein Problemfall. Die Originaldatenbak gibt es in der seinerzeitigen Form wohl nicht mehr, inwieweit https://www.fifaindex.com/ deren Funktion übernommen hat, habe ich mir noch nicht angeschaut. Die Vorlage wurde schon vor einer Weile auf Archivlinks umgestellt, die wohl aber auch nicht mehr funktional sind. en.wp und Wikidata verlinken auf andere Webarchive, aber in den Stichproben, die ich mir angeschaut habe, auch nicht wirklich erfolgreich. Kann da jemand bitte einen Blick mit drauf werfen, ob sich da irgendwelche Rettungsversuche lohnen, oder ob das gelöscht werden kann? In {{UEFA.com}} scheint es wohl analog auszusehen, habe ich mir noch nicht angeschaut. Vielen Dank! --FordPrefect42 (Diskussion) 10:05, 31. Aug. 2023 (CEST)

Hallo in die Runde, der Auslöser für die Anfrage von FordPerfekt42 bin ich, weshalb ich mein Interesse, an einer Beantwortung der Frage, auch nochmal zum Ausdruck bringen wollte. Danke und Grüße --LegoFCB (Diskussion) 06:45, 1. Sep. 2023 (CEST)

Hm, was ist denn hier die konkrete Anfrage? Die Beurteilung, ob fifaindex.com eine geeignete Datenbank für den Ersatz der Links ist, können wir hier in dieser Werkstatt sicher nicht besser beantworten als die Fußballexperten. Gruß, -- hgzh 08:14, 7. Sep. 2023 (CEST)

Hallo @Hgzh, bekanntermaßen sind die genannten Vorlagen defekt oder auch gar nicht vorhanden. Das gilt auch für Archivsuche, die erfolglos verläuft. Dies ist Grundlage für zahlreiche Lösungen, die ich vornahm. Daraufhin wurde ich angesprochen, dass noch viele weitere Links vorhanden sein, wobei sich ein Bot besser um die Löschung kümmern könne. In weiteren Kommentaren, wurde gesagt, dass man diese nicht löschen sollte, da eine Reparatur dieser Links durchaus möglich wäre. Wenn dem so ist, sollte ich die Löschungen (bislang mehrere 100) rückgängig machen. Die Frage ist nun, ob Löschung oder Wiedereinsetzung Sinn macht. Danke und Grüße --LegoFCB (Diskussion) 08:45, 7. Sep. 2023 (CEST)

Tabelle mit mehreren Bildern in einem Spaltenfeld sicher formatieren

Hallo, ich versuche in einer Tabelle mehrere Bilder in einem Spaltenfeld so zu formatieren, dass sie zumindest auf dem Tablet auch nebeneinander! stehen wie auf dem PC (Beim Sph verstehe ich, dass sie untereinander kommen). Konkret geht es um Donatello (Werkkatalog), wo es mehr als ein halbes Dutzend mal vorkommt. In Hilfe:TBL finde ich dazu nichts und habe schon herumexperimentiert. - Und, by the way, warum erscheint eine sortierbare Tabelle auf Tablets und Sphs nicht sortierbar zu sein? Nur bei mir? MenkinAlRire (Diskussion) 21:12, 31. Aug. 2023 (CEST)

Ich fang mal mit dem für mich einfacherem an: Das Sortieren und andere Geschichten, die JavaScript benötigen, sind mobil noch nie aktiviert worden; es heißt aber schon seit vielen Jahren, dieses oder nächstes Jahr solle dies ermöglicht werden.

50 % der ANR-Abrufe kommen von Smartphones.

„Bilder nebeneinander“ ist eine Sache, die wir grundsätzlich nicht mehr haben möchten. Wenn sie größer als ein Icon sind. Die Artikel werden auf schmaleren Bildschirmen unlesbar und es ist nicht zu sehen, was rechts im Abseits passiert, und man bekommt es überhaupt nicht mit. Wenn doch, muss umständlich über die Aus-Linie gescrollt werden, und dann isses uninteressant.

Die Bilder sollen wie ein Fließtext je nach Platzverhältnissen in Zeilen angeordnet werden wie es passt.

Welche Methode empfehlenswert sei, wissen andere.

VG --PerfektesChaos 22:35, 31. Aug. 2023 (CEST)

Anmerkung: Tabellen sind auch in der Mobilversion seit etwa Jahresanfang (?) sortierbar. Wenn die Sortierpfeile nur in der Mobilversion nicht erscheinen, liegt das wahrscheinlich eher an deaktiviertem JavaScript. Die App mag sich nochmal anders verhalten. -- hgzh 23:30, 31. Aug. 2023 (CEST)

Ja, die hier angesprochene Tabelle ist auch mobil ganz normal sortierbar. Ansonsten ist sie aber schon jetzt nicht sonderlich mobilfreundlich, da sollten nicht noch Bilder nebeneinander gestellt werden. --XanonymusX (Diskussion) 00:41, 1. Sep. 2023 (CEST)

Innert kurzer Zeit drei Antworten, dafür schon mal einen herzlichen Dank.

@PerfektesChaos: Das ist doch schon mal gut zu hören, dass dran gearbeitet wird. Die sortierbare Tabelle finde ich nämlich ein super Analysetool.

ANR?/

Die anderen 50% wären dann Tablets und andere, größere? Das wäre ein Grund sie zu unterscheiden und alternativ zu programmieren.

Einzelbilder und Gallerien werden unterschiedslos in voller Breite untereinander gezeigt, was beim Tablet ggf. schon schwergängig wird und man den Überblick verlieren kann. (Dass im übrigen das Kopfbi,d automatisch das erste im Text ist und nicht definiert werden kann, führt häufig zu unschönen, bzw redundantem Aussehen.)

+ @XanonymusX: Ich würde ja erwarten, dass jeders bei so einer Tabelle darauf kommt, den Bildschirm quer zu drehen ...und meine Tabelle passt fast vollständig auf 2280x1080 . Aber gut, sehe ich mit Zaudern ein.

Meine Folgerung wäre aber dann, die Bilder in 'meiner' Tabelle untereinander zu setzen oder am besten welche wegzulassen, da der Großteil 'sehr' hochformatig und schmal ist. Sagt mal 'ja', dann wäre das für mich gegessen.

+ @hgzh: Ich lasse im Firefox für Wiki alle Skripte zu. Ich muss aber zugeben, dass ich nach einer kürzlichen Migration nicht gecheckt habe, ob die Einstellungen auch alle mitgenommen wurden. Das war nicht der Fall. Danke für den Merker. Zur App dürfen wir ja was erwarten.

Wäre also von mir aus schon erledigt. Bemerkungen höre ich noch gern oder, falls einer weiß, wo Bilder und Tabellen ggf. in Diskussion sind, gern ein Hinweis. Danke. MenkinAlRire (Diskussion) 20:45, 1. Sep. 2023 (CEST)

Breite von Infoboxen

Hallo zusammen, bin gerade im Zusammenhang von {{Infobox Flughafen}} darüber gestolpert: Viele Infoboxen haben ja (noch?) eine fixe Breite hinterlegt, in diesem konkreten Fall 250 Pixel, was bei moderner Hardware nicht mehr zeitgemäß sein dürfte. Gibt es hier moderne Lösungen, vielleicht sogar ohne Angabe einer fixen Breite? Oder welche Breitenangabe ist hier inzwischen der Standard, gibt es da etwas? Danke, Yellowcard (D.) 14:40, 4. Sep. 2023 (CEST)

Bekanntes Problem, schwierige Kiste, keine allgemeingültige Lösung möglich.

Erwägungen hängen ab von:

• Länge, Umfang der Beschriftungen (linke Spalte und der Daten (rechts; URL, Namen, Aufzählungen.
• Es sollen oft Bilder enthalten sein.
  • Bildbreiten sind explizit in Pixeln anzugeben, IB muss dan 10–20px breiter werden.
  • Bildbreite hängt ab von der Erkennbarkeit:
    • Chemische Strukturformel muss lesbar sein; Grafiken, Landkarten brauchen Breite.
    • Ein Foto als Luftbild von Dingenskirchen oder des NSG Tümpelteich zeigt wenig; käme mit wenigen px aus, ist nur Dekoration und gibt gefühligen Eindruck.
  • Bildbreiten-Pixel verhindern responsives Verhalten.
  • Wappen + Flagge nebeneinader brauchen Platz.
• Smartphone oder besser: schmaler Bildschirm will wenig Pixel bei der IB.
  • Smartphones ordnen momentan IB ggf. als eigenen Block an, ohne Text links daneben.
  • Desktops mit breitem Fenster könnten mehr Pixel vertragen.
• Individuell justieren nach typischen Inhalten im Anwendungsbereich.
  • Im Zweifelsfall belassen wie vorgefunden, sofern nicht frischere und vertiefte neue Erkenntnisse vorliegen.
• Keine projektweiten Standards, aber 300+x sind ein typisches Limit. Dürfen aber bei wenig Inhalt unterschritten werden.
• Es ist eine explizite Vorgabe erforderlich; wegen Bildbreiten und auch ohne Bilder wird der Eindruck bei 30% oder 10% und das gestaffelt nach Fensterbreite extrem kompliziert und konfus; nicht wartungsfähig.

VG --PerfektesChaos 15:05, 4. Sep. 2023 (CEST)

Danke für den Überblick, PerfektesChaos! Das hilft in jedem Fall schon einmal sehr weiter.

{{Infobox}} hat als Default-Angabe min-width:190px; max-width:300px; width:30%; im Style-Attribut stehen. Das gefiel mir vorhin, als ich es entdeckt habe, zunächst recht gut (also dynamische Angabe mit entsprechenden Grenzen, die man je nach Anwendungsfall ggf. anpassen kann), aber gemäß Deines letzten Punkts vielleicht doch gar nicht so geschickt, oder wie siehst Du das? Grüße, Yellowcard (D.) 15:14, 4. Sep. 2023 (CEST)

Eine fest vorgeschriebene (relative oder absolute) Breitenangabe gibt es nicht, es gibt weiterhin auch schmalere Infoboxen (<250px) und wesentlich breiter (~370px). . Die am häufigsten eingebundene {{Infobox Fußballspieler}} verwendet gar keine Breitendefinition. {{Infobox}} verwendet eine variable Breitendefinition mit min-width:190px; max-width:300px; width:30%;, damit ist dann bei 300px Schluss. Die mw-message-box hat bei mir mit FF 117 eine Breite von 1628px bei FullHD, sodass die Definition dazu führt, dass die IB immer 300px breit sein wird. --darkking3 ^Թ 15:22, 4. Sep. 2023 (CEST)

Geteilter Tabellenkopf

Hallo, haben wir eigentlich in de:WP ein Äquivalent für en:Template:Diagonal_split_header ? Wenn ja, macht das was Sinnvolles für Screenreader oder ist das völlig unsemantisch? Beste Grüße -- Leif Czerny 08:23, 6. Sep. 2023 (CEST)

Da wird nur mit CSS-Positionierung gearbeitet, für Screenreader unverständlich. Das sollten wir uns nicht aufbinden. Eine Alternative wäre möglicherweise, die Zelle horizontal zu trennen und dann mit scope zu arbeiten. Gruß, -- hgzh 10:01, 6. Sep. 2023 (CEST)

Hmm hättest Du ein Beispiel? Eine einzelne Zelle kann ich doch nicht spalten; ich müsste also eine leere Spalte einfügen und dann die beiden ersten Zellen in jeder Zeile mit colspan fusionieren? ---- Leif Czerny 10:11, 6. Sep. 2023 (CEST)

Ja, das schwebte mir vor. -- hgzh 11:39, 6. Sep. 2023 (CEST)

Kriegen Screenreader etc. das hin? Dan probiere ich das mal aus. Ist aber viel Quelltext. ---- Leif Czerny 15:29, 6. Sep. 2023 (CEST)

Das klingt mir alles sehr dubios.

Zunächst einmal ist in dieser Werkstatt das konkrete Problem zu schildern, mit Beispielfall.

• Danach kann für dieses Problem eine angemessene Lösung gesucht werden.
• Allgemeine Anfragen nach schlechten Hacks aus der enWP sind nicht zielführend.

Eine Datentabelle hat eine semantische Struktur und ordnet jeder Zelle die Legende (Überschriftenstruktur) zu.

• Jede Verletzung der semantischen Struktur durch Hacks mit optischen Basteleien verfälscht die Semantik.
• Damit sind Screenreader und jede andere nachfolgende Software übel angeschmiert.

Wenn Spaltenüberschriften wesentlich breiter sind als die Inhalte, und das auch mit weichem Umbruch nicht lösbar wäre, kann der Tabelle eine Legende mit Bedeutung der Abkürzungen vorangestellt werden, und die Spaltenüberschriften erhalten intuitive Kürzel.

VG --PerfektesChaos 15:53, 6. Sep. 2023 (CEST)

Hallo PerferctesChaos,

Deswegen frage ich ja, kein Grund, so ein Geschnaube zu veranstalten. Die Option "Legende" halte ich für solche Fälle durchgängig für unpassend, und wüsste auch nicht, inwiefern das semantisch robust umzusetzen wäre.-- Leif Czerny 14:35, 7. Sep. 2023 (CEST)

Andrew Higginson

Hallo zusammen,

so, ich schon wieder. Im Artikel Andrew Higginson erscheint plötzlich unten die ref-Fehlermeldung "..wird im vorausgehenden Text nicht verwendet...". Obwohl es in den letzten Wochen keine Änderungen gab, auch nicht in der Vorlage:Infobox Snookerspieler

Ist irgendetwas unpassend zu Vorlagen? Das Preisgeld im Quelltext ist anders, als im Artikel angegeben.

VG, L

Nachtrag: es sind weitere Artikel betroffen, das muss an bestimmten recht gut versteckten Datenbeständen liegen.

--Larry2718 (Diskussion) 15:52, 7. Sep. 2023 (CEST)

Es betrifft Artikel aus dieser Liste, da hier nachgepflegt wurde. --darkking3 ^Թ 15:57, 7. Sep. 2023 (CEST)

Problem der Verschachtelung bei Umwandlung {{LOCALDATE}}

Hallo Miteinander. Mein Problem ist eines der Bequemlichkeit, und marginal und sieht so aus:

Schritt 1 {{LOCALDATE}} ergibt 1. Oktober 2023

Schritt 2 {{ISO-Datum|{{LOCALDATE}}}} ergibt 2023-10-01

Dieses Format braucht es für die Vorlage von Referenzen beim Schreiben von Artikeln.

Darum habe ich mir also <ref>{{Internetquelle |autor= |url= |titel= |werk= |hrsg= |datum= |abruf=2023-09-09}}</ref> in meine Werkstatt gelegt, damit es schneller geht beim Erstellen.

Hier muss ich nun allerdings das ISO-Datum jeden Tag von Hand in meiner Kopiervorlage ändern, denn eine tiefere Verschachtelung <ref>{{Internetquelle |autor= |url= |titel= |werk= |hrsg= |datum= |abruf={{ISO-Datum|{{LOCALDATE}}}}}}</ref> funktioniert offenbar nicht.

Wenn ich also vergesse zu ändern, oder ich mich vertippt habe (das kommt vor) stimmt mein Abrufdatum in meiner Kopiervorlage nicht. Ich müßte das Ergebnis von oben also erst zwischenspeichern in einer neuen Vorlage. Bei einer Vorlage, die ich in meinem Benutzerraum erstelle komme ich aber immer noch auf zu viele Klammern, oder habe ich da einen Denkfehler.

Ich hänge fest. Kann mir da jemand helfen?

Wäre das nützlich für viele?

Danke für ein Feedback! --Merlingenial • परिचर्चा 01:31, 9. Sep. 2023 (CEST)

Ist das folgende gewünscht?

<ref>{{Internetquelle |autor= |url= |titel= |werk= |hrsg= |datum= |abruf=2023-10-01}}</ref>

Der Unterschied liegt in einer Unterbrechung der nowiki-Umgebung. --Kallichore (Diskussion) 01:40, 9. Sep. 2023 (CEST)

Super, Danke vielmals und so schnell --Merlingenial • परिचर्चा 01:46, 9. Sep. 2023 (CEST)

und so verblüffend einfach --Merlingenial • परिचर्चा 02:09, 9. Sep. 2023 (CEST)

Neue Vorlage "Infobox Entscheidung Bundesverfassungsgericht"

Hallo, liebe Vorlagenwerkstatt,

die Redaktion:Recht möchte gerne eine neue Vorlage "Infobox Entscheidung Bundesverfassungsgericht" einführen. Die Eckpunkte wurden ausführlich diskutiert, und es wurde im weiteren Verlauf ein Grundkonzept beschlossen, das nun in eine neue Vorlage umgesetzt werden soll. Die gewünschten Parameter findet ihr am Ende dieses Abschnitts.

Zur Info: Es gibt bereits zwei Vorlagen (die gewünschte neue wäre mithin die dritte). Vorlage 1, von uns im Diskurs als "alte Vorlage" bezeichnet, ist eine in Benutzung befindliche Version (7 Anwendungsfälle), die aber nicht fortgeführt werden soll. Vorlage 2 wurde vor einiger Zeit ohne Beteiligung des Portals gelöscht, diente dem Portal als Diskussionsgrundlage und wurde auf einer Portal-Unterseite vorübergehend wiederhergestellt. Diese gelöschte Vorlage könnte vielleicht eine Arbeitsgrundlage für unsere neue Vorlage 3 sein.

Wäre toll, wenn ihr uns hier helfen könntet. Für Rückfragen stehe ich euch gerne zur Verfügung. --Opihuck 23:33, 10. Sep. 2023 (CEST)

Warum eine "neue" Vorlage erstellen und nicht die vorhandene anpassen? Das ist auch zur Dokumentation wesentlich sinnvoller, als eine weitere neue Vorlage. Siehe auch Wikipedia:WikiProjekt_Vorlagen/Werkstatt/Archiv 2023/1#Vorlagen zusammenführen. --darkking3 ^Թ 10:46, 11. Sep. 2023 (CEST)

Bei einer Neukonzeption über ganze 8 Artikel würde ich dem Portal anempfehlen, den Blick zu weiten.

Ich würde für eine komplett neue Infobox plädieren, die Barrieren und optische Hacks vermeidet.

• Und zwar „Entscheidung deutsches Obergericht“ oder sowas.
• Also auch nutzbar für BGH, BSG oder sonstwas, sofern diese einmal eine relevanzstiftende Grundsatzentscheidung treffen.
• Das AG Hintertupfingen wird hier eher weniger Rechtsgeschichte schreiben.
• Aber OLG und Kammergericht mögen auch einmal eine RK-fähige Entscheidung finden.
• Heißt: Zusätzlicher neuer Pflichtparameter |Gericht= mit Werten BVG BGH BSG usw.

Ansonsten der Parametersatz, wie er fachlich zuletzt durch das Portal konsentiert wurde.

Aus den beiden Vorgängern sollten die behaltenswerten Teile kopiert werden.

• Eine ungebrochene Abstammungslinie bringt aber mehr Verwirrung, als dass sie irgendwas einspart.
• Es ist einfacher zu migrieren, auf eine komplett neue Version umzustellen, als sich mit parallelen Krücken zu helfen.

VG --PerfektesChaos 12:17, 11. Sep. 2023 (CEST)

Bei 8 Artikeln werden sicherlich keine parallelen Krücken notwendig sein. Für deine Erweiterung Du wirst sicherlich alle Artikel der Kategorie:Gerichtsentscheidung (Deutschland) meinen? Würden rein theoretisch alle Artikel eine IB erhalten, müssten derzeit auch AG's berücksichtigt werden. Sollte aber kein Problem sein und es wäre wohl soetwas wie z.B. "Infobox Entscheidung deutsches Gericht" sinnvoll. --darkking3 ^Թ 15:08, 11. Sep. 2023 (CEST)

Öh, ja, mmpf.

• Diese Kat hatte ich im Detail nicht geflöht.
• Ich ahnte aber, dass wir mindestens ein paar BGH-Entscheidungen irgendwo haben sollten.
• Zumindest würden mit der nächsten Million Artikel ein paar Fälle aufschlagen.

Zur Strategie:

• Es sollte ein sauberer Schnitt gemacht werden, und ein Neuanfang ohne VG.
• Was vom bisherigen Design zukunftsfähig ist, mag so übernommen werden.
• Und der Parametersatz gemäß Fachportal.
• Eine neue IB erstellen wir aber nach Grundsätzen der Barrierefreiheit, ohne Winzschrift und tote Zeilen oder ablenkende Grafik.

Also alle deutschen Entscheidungen bis runter zum Reichsgericht.

Der Gerichtsparameter sollte für die bekannten Fälle ein kontrolliertes Vokabular haben.

• Bekannt wäre BGH usw.
• Wenn Bundesgericht, dann Adler, aber nicht dominierend und nicht in voller Breite. Smartphone-Scrollweg.
• „Verwaltung“ und „Verfassung“ fangen beide mit „V“ an.
• Die Existenz des dekorativen Adlers ohne inhaltlichen Beitrag sollte Screenreadern verborgen werden.
• Wenn unbekanntes Gericht, dann volle Verlinkung erforderlich und keine Grafik.

VG --PerfektesChaos 16:34, 11. Sep. 2023 (CEST)

Ich habe auch nur geahnt, dass es sicherlich Urteile geben wird, die auch eine AG-Entscheidung relevant machen. Für historische Urteile können wir nachpflegen, sofern diese in den vorgegebenen Parametersatz passen. Zur Unterscheidung reicht die deutsche Behördensprache aus: Bundesverwaltungsgericht ist BVerwG, Bundesverfassungsgericht ist BVerfG, die Abkürzungen dürften der Redaktion Recht eigentlich geläufig sein. --darkking3 ^Թ 17:21, 11. Sep. 2023 (CEST)

Vielen Dank für eure Rückmeldungen.

zu 1): Ja, natürlich soll es künftig nur noch eine Vorlage geben. Die Löschung von Vorlage 2 ist leider am Portal vorbeigegangen. Dabei war das Portal fast einstimmig der Überzeugung, dass die gelöschte Vorlage 2 ausbaufähig war und die bestehende Vorlage 1 indiskutabel ist. Ich kann technisch nicht beurteilen, ob es einfacher ist, Vorlage 1 oder Vorlage 2 umzubauen oder Vorlage 3 völlig neu zu schreiben. Was ich aber für alle Diskussionsteilnehmer sagen kann, ist, dass wir an Vorlage 1 und ihrer Optik kaum festhalten wollen (siehe nur die sehr eindeutigen Äußerungen auf der Disk). Mein Vorschlag: Ihr zieht euch eine Kopie von Vorlage 2 und nutzt sie zum weiteren Ausbau. Optische Fragen haben wir noch nicht ganz abschließend geklärt, aber die Vorlage 2 erschien uns allen schon ziemlich annehmbar. Wenn das nicht geht und es einfacher wäre, eine völlig neue Vorlage zu erstellen, wäre das selbstverständlich auch willkommen. Nochmals: Nach Fertigstellung der neuen Vorlage sollen Vorlagen 1 und 2 in die ewigen Jagdgründe.

zu 2): Das Thema einer gemeinsamen Vorlage für z. B. auch für die oberen Bundesgerichte und die Obergerichte der Länder aller 5 Gerichtsbarkeiten hatten wir in der Disk angeschnitten, aber sehr schnell gemerkt, dass es wegen vieler Besonderheiten nicht sinnvoll ist, auch noch dieses Fass aufzumachen. Das ist eine eigene Großbaustelle. Wir hatten schon erhebliche Probleme, uns auf die Infobox für das BVerfG zu verständigen. BGH, BSG, BVerwG, BAG und BFH sind eigene Kisten mit anderen Parametern (das geht schon los beim BGH: die Infoboxen von Zivil- und Strafgerichtsbarkeit des BGH werden mutmaßlich voneinander abweichen). Der Anlass für die neue Infobox war übrigens ein vom Bundesverfassungsgericht entwickelter eigener Bundesadler, der die neue Box schmücken soll. Da haben wir schon den nächsten Unterschied: Die anderen Bundesgerichte nutzen den bisherigen Bundesadler und die Ländergerichte haben ihre eigenen 16 Wappen. Eine einzige Box für alle Gerichtsbarkeiten sehe ich gegenwärtig als eher utopisch an.

Ich bitte euch, die Vorgehensweise des Portals zu respektieren; den oben eingeforderten Weitblick haben wir - und darum lassen wir erst mal die Finger von einer Vorlage Infobox Entscheidung deutsches Gericht. Lasst uns mit einem Gericht einen Anfang machen; dann sehen wir weiter, was da übernommen werden kann und was nicht.

zu 3): Die Migration von Vorlage 1 zur neuen Vorlage 3 ist überschaubar, da es derzeit nur sieben Anwendungsfälle gibt. Das ist auch ohne bot in einer halben Stunde erledigt.

Nochmals vielen vielen Dank für eure Mühe, und vielleicht gibt es ja schon bald einen ersten Entwurf. Danke! --Opihuck 17:28, 11. Sep. 2023 (CEST)

Wobei am Ende die Frage offenblieb, ob Entscheidungen des BVerfG vor der Einführung des neuen Adlers nicht auch weiterhin den alten Adler bekommen müssten. --Ichigonokonoha (Diskussion) 22:56, 11. Sep. 2023 (CEST)

Wenn ihr freundlicherweise das Datum der Umstellung bekanntgeben würdet – wir kennen das Datum der Entscheidung und können vorher/nachher vergleichen und dementsprechend den richtigen Vogel abschießen. VG --PerfektesChaos 00:24, 12. Sep. 2023 (CEST)

Geht bitte im Exposé erst mal davon aus, einheitlich den neuen Adler zu verwenden. Wenn ich mich erinnere, fand der Vorschlag, den Adler je nach Entscheidungsdatum zuzuweisen, keine Mehrheit. --Opihuck 01:21, 12. Sep. 2023 (CEST)

Nun, darüber gab es, sofern ich mich richtig erinnere, eigentlich mit Ausnahme von Wortbwiträgen vom Kollegen @Aschmidt, dir und mir keine Wortmeldungen und wir haben das kaum diskutiert, bzw. gar nicht. Eigentlich gab es nur meinen Beitrag, eine Nachfrage von dir und den Beitrag von Aschmidt. Aschmidt sprach von der "jeweils aktuelle Adler", ich weiß, dass du nicht viel Zeit zurzeit hast, aber sofern du das liest, wäre es gut, wenn du kurz sagen könntest, ob du damit auch meintest, dass vor 04.2023 [1] der bisherige Adler verwendet werden sollte. --Ichigonokonoha (Diskussion) 07:06, 12. Sep. 2023 (CEST)

Danke fürs Anpingen. Bitte ein einheitliches Logo verwenden, also stets das heute aktuelle. Bitte keinen Schalter mit Änderungadatum. Es gibt auch nur eine einheitliche Rechtsprechung des Bundesverfassungsgerichts. Das ist ja durch die Umstellung des Logos (das nicht mit dem Bundesadler zu verwechseln wäre) nicht zu einem anderen Gericht geworden. Danke und --Viele Grüße, Aschmidt (Diskussion) 07:31, 12. Sep. 2023 (CEST)

Aber, wie ich in der Portal Diskussion gesagt habe, bleibt es unhistorisch einem Gericht bspw. in den 50ern einen späteren Adler überzustölpen. Während das beim Gerichtsartikel natürlich das aktuelle sein sollte, beschreibt ein urteilsartikel das Gerichr zu der Zeit der Urteilsverkündung. Also in Artikeln, die ich geschrieben hätte, würde ich diese Infobox dann aufgrund dieser Tatsache rausschmeißen. --Ichigonokonoha (Diskussion) 08:32, 12. Sep. 2023 (CEST) PS: Mit allem anderen konnte ich ja leben, aber das bleibt einfach etwas, was ich für zutiefst historisch falsch halte. Wenn Deutschland jetzt die Bundesfahne ändert, ändern wir ja auch in Artikel zu historischen Schiffen auch nicht die Flagge, denn darunter sind die Schiffe nie gefahren und genauso unter dem Adler haben die Richter damals nie entschieden.

@PerfektesChaos Du siehst, wie schwierig es ist, schon bei einem Gericht einen Konsens zu finden. Was wir mit dem Adler machen – ich glaube, dass die Unterschiede so unbedeutend sind, dass das kaum jemandem auffallen dürfte – müssen wir im Portal weiterdiskutieren. Da gibt es auch noch andere Feinheiten, die ungeklärt sind. Was wir jetzt brauchen, ist eine Vorlage. Wir kommen sonst nicht weiter. --Opihuck 09:27, 12. Sep. 2023 (CEST)

Wir kennen ja die Datumsangaben, und wenn ihr euch in der Geflügelfrage geeinigt habt, können wir jederzeit abhängig vom Datum umswitchen. VG --PerfektesChaos 09:44, 12. Sep. 2023 (CEST)

Lieber @Ichigonokonoha, das Gegenteil ist der Fall: Wie schon gesagt, gibt es nur eine einheitliche Rechtsprechung des Bundesverfassungsgerichts. Das Gericht nimmt vielfach auf seine Leitentscheidungen (und nur um die geht es hier) Bezug. „Historisierend“ ist immer falsch. Das ist so wie die nagelneuen, aber auf alt getrimmten Häuser in der Neuen Frankfurter Altstadt. Disney World ist das Gegenteil von Enzyklopädie. deshalb wäre ich hier anderer Ansicht und bleibe dabei, dass wir das heute jeweils verwendete Logo für alle Entscheidungen des BVerfG verwenden (macht das Geicht auf seiner eigenen Website übrigens auch). Wenn du das in deinen Artikeln anders handhaben möchtest, bleibt es dir überlassen. Das Logo in der Infobox würde dann besser entfallen. Deshalb, lieber @PerfektesChaos, bitte keinen Schalter für das Geflügel einbauen. Danke und --Viele Grüße, Aschmidt (Diskussion) 23:45, 12. Sep. 2023 (CEST)

Also, dann ist die allerletzte Option die folgende:

• Eine Infobox Entscheidung deutsches Gericht wird für den Fall |Gericht=BVerfG ab einem noch zu benennenden Stichtag den neuen Adler zeigen, ansonsten hierfür gar keine Dekoration.

Andernfalls ist dieser Auflauf hier für ganze 8 Artikel der Werkstatt nicht länger zumutbar, und eine Infobox für von vornherein kaum zweistellige Anzahl von Artikeln bei einem Potenzial von Hunderten ist auch nichts womit wir den Vorlagen-Namensraum bevölkern.

• Es fällt dann halt auf die Juristen zurück, wenn konzeptionelles und zielorientiertes Arbeiten nicht möglich ist.
• Adressat ist das Publikum, dem mit einer Infobox eine leicht erfassbare Übersicht über Schlüsseldaten und Schlagwörter geliefert werden soll. Dem sind die Dekorationsfragen und Adlergestaltungen dabei ziemlich egal.
• Wenn diese Dekorationsdiskussionen bei jedem Pixel Strichstärke und jedem Grauton so weitergehen sollen, dann programmiert ihr das besser untereinander; als Miteinander lässt sich das kaum bezeichnen.

VG --PerfektesChaos 12:28, 13. Sep. 2023 (CEST)

Nun, dann lieber vor dem Stichtag ohne Adler - Stichtag wäre die Einführung des Adlers durch das BVerfG, bzw. die Pressemitteilung am 3.3.2023.

Das war auch die einzige Frage, die bisher keine Klärung erfahren hatte. Für alles weitere hatten wir ja einen Konsens.

Ansonsten Aschmidt, kann ich das so nicht ganz stehen lassen, in der verfassungsrechtlichen Wissenschaft wird der Ruf nach Historisierung immer lauter (bspw. Matthias Jestaedt in Das entgrenzte Gericht, 2011) und auch ansonsten begegnet einem in der Literatur immer mehr die Einbettung einer dogmatischen Figur in die Zeitgeschichte (bspw. Stefan Lenz, Das Elfes-Urteil des Bundesverfassungsgerichts von 1957 in der RW 2016). --Ichigonokonoha (Diskussion) 13:23, 13. Sep. 2023 (CEST)

Das Personal dieser Werkstatt hat anderthalb Jahrzehnte Erfahrung und Routine im Umgang mit solchen Herausforderungen.

• Es braucht sehr viel weniger Anstrengungen und Mühen und Verständnis, um einen mittelgroßen Wurf wie skizziert umzusetzen als mit lauter fast identischen einzelnen Vorlagen herumzufrickeln.
• Das gilt bei der Pflege des ANR wie der Vorlagenseiten.
• Das Feld ist wohlweislich auf „Deutschland“ begrenzt; mitsamt Deutschem Reich aber ohne Österreich, Schweiz, USA. Dafür sind die Ähnlichkeiten überschaubar und die Fallunterscheidung wird nicht astronomisch.

@ Adler:

• Da steht nicht ohne Grund: „kontrolliertes Vokabular“.
• Das bedeutet: BVerfG ist bekannt und bekommt seinen; BGH BSG BVerwG bekommen einen anderen.
• Für BayObLG und KG gibt es Rauten und Bärchen.
• OLG Hamm usw. bekommen im Lauf des ggf. lernenden Erweiterungsprozesses Landeswappen und ebenfalls automatische Verlinkungen.
• Wer noch unbekannt ist, und mangels Bedeutung auch keines direkten Supports bedarf, bekommt eine Direktverlinkung und kein Wappen.

@ |SenatKammer= usw.

• Ein optionaler Parameter für den 2. Strafsenat und die 3. Zivilkammer ist machbar.

Wir haben das #switch, das ggf. auch noch auf einem unteren Level das kontrollierte Vokabular auswerten kann.

• Das ist wesentlich einfacher in einem konzeptionell überschaubaren Bereich „Deutschland“ umsetzbar, für alle Entscheidungen, als in lauter individuellen Einzellösungen für jedes Gericht, und erlaubt einheitliche Doku, einheitliches Parametermodell und bessere Anwendbarkeit bei minimalem Programmierungsaufwand insgesamt.
• Ein abschreckendes Beispiel sind unzählige Denkmallisten-Vorlagen für jede Sadt in NRW usw. einzeln, obwohl mindestens innerhalb eines Bundeslandes die gesetzlichen Rahmenbedingungen identisch sind und es allenfalls minimale lokale Anpassungen geben würde. Jeder baut seine eigene private Vorlage, mit eigenem Parametermodell und eigenem Design und separat zu pflegender Syntax und Programmierung.
• Vielleicht ist darkking3 so lieb und baut mal einen Prototypen für die Bundesgerichte, BayObLG und KG und akzeptabler Optik und Funktionalität. Wenn das Konzept von vornherein auf universelle Verwendung ausgelegt ist, dann lässt sich dieses Grundschema mit Leichtigkeit um einzelne OLG erweitern.

VG --PerfektesChaos 19:35, 11. Sep. 2023 (CEST)

Muss man sich angucken, wenn es fertig ist. Ich habe angesichts der Vordiskussionen ein eher ungutes Gefühl; aber ich lasse mich gerne von einer sensationellen Vorlage überraschen. Allerdings wäre mir ein Prototyp für BVerfG im Moment lieber. Wenn eine solche Vorlage mehr kann, auch gut. --Opihuck 20:19, 11. Sep. 2023 (CEST)

Ich bin da auch eher skeptisch, was eine umfassende Infobox angeht. Das liegt auch alleine an der Parameterbeschreibung, die wir jetzt explizit für das BVerfG konzipiert haben und die auf die anderen Gerichte natürlich nicht passt. --Ichigonokonoha (Diskussion) 23:00, 11. Sep. 2023 (CEST)

Na, dann bitte konkret:

• Was genau hat ein anderes Gericht extra, was hat nur das BVerfG?
• Aktenzeichen und Entscheidungsdatum haben sie ja wohl alle.
• Spruchkörper mag als |SenatKammer= verallgemeinert werden, vermute ich.
• ECLI wird dann wohl was optionales sein. Scheint mir aber nicht auf das BVerfG beschränkt zu sein.
• Für den allgemeinen Fall wäre ein zusätzlicher Parametersatz sinnvoll, URL Format kBytes zur Generierung von Weblinks.

VG --PerfektesChaos 00:24, 12. Sep. 2023 (CEST)

Lieber PerfektesChaos, wir haben es uns nicht leicht gemacht, ein Muster für das Bundesverfassungsgericht zu erarbeiten, das in vielerlei Hinsicht eine Sonderstellung genießt. "Verfahrensart" ist z. B. „BVerfG-typisch“; das gibt es bei anderen Gerichten nicht. Beim Spruchkörper gibt es nicht nur Senate oder Kammern, sondern beides. „Rechtsnorm“ ist auch eher BVerfG-typisch, in der Regel bestimmte Grundrechtsnormen, bei anderen Gerichten lässt sich oft keine bestimmte zitierfähige Norm angeben. Andere Gerichte haben dafür Parameter, die das Bundesverfassungsgericht nicht kennt.

Wir sind heilfroh, nach sehr langer Diskussion, die im Jahre 2020 ihren Ausgang genommen hat, jetzt endlich eine Lösung für das BVerfG gefunden zu haben und möchten aus guten Gründen – da sind wir uns sehr einig – keine weiteren Großbaustellen eröffnen.

Bedenke bitte auch, dass die von dir angestrebte Durchgliederung bis in den Landesbereich hinein auf keinerlei Nachfrage stoßen wird. Wenn ich das richtig sehe, sind bisher ausweislich Kategorie:Gerichtsentscheidung (Deutschland) keine BFH-Entscheidungen, nur 3 BAG-Entscheidungen, nur 3 BVerwG-Entscheidungen, aber 49 BGH-Entscheidungen und 80 BVerfG-Entscheidungen in Artikeln behandelt worden. Hinzukommen einige Entscheidungen des Reichsgerichts und des Staatsgerichtshofs für das Deutsche Reich.

Entscheidungen der oberen Landesgerichte sind bisher nicht kommentiert worden, und das ist auch kaum zu erwarten. Für solche Entscheidungen gibt es regelmäßig schon keinen eingeführten Fallnamen und es fehlt jegliche Breitenwirkung. Alles, was darunter (z. B. LG, AG) liegt... – du kannst es dir schon denken. Kurzum: Interessant sind BVerfG und BGH, der Rest ist nahe der enzyklopädischen Bedeutungslosigkeit. Viele Grüße --Opihuck 01:02, 12. Sep. 2023 (CEST)

Nun, wobei wir schon gesagt haben, dass wir mit leichten Modifikationen die Box für andere Obergerichte adaptieren könnten. Was ich eher meinte, sind die Beschreibungen. Wobei stimmt, was Opihuck sagt, wir haben darüber im Portal nicht diskutiert und da die Gerichte ihre eigenen Verfahrensordnungen haben und daher vieles anders ist, müssten wir das auch nochmal genau beleuchten, ob sich da Änderungen ergeben. Wir haben (mit Ausnahme des Adlers vor nach Einführung, wo wir nichts zu entschieden hatten) doch seht gerungen, auch um Feinheiten der Formulierungen der Parameterbeschreibungen. Nun, vielleicht könnte man die Infobox erstmal für das BVerfG erstellen und wenn wir uns im Portal (irgendwann) über die anderen Bundesgerichte geeinigt haben, bzw. diskutiert haben, würden wir wiederkommen und die Infobox könnte erweitert werden? --Ichigonokonoha (Diskussion) 07:24, 12. Sep. 2023 (CEST)

Das ist doch keine Raketenwissenschaft. Ich mach seit bald 40 Jahren Informationsmodellierung.

• @ Verfahrensart
  • Das ist dann halt ein optionaler Parameter. Wie die meisten hier.
  • Wenn er nur beim BVerfG sinnvoll belegt werden kann, dann bekommt er nur dort einen Wert zugewiesen, und wird ansonsten weggelassen.
  • Ist wie mit einem Flugzeug. Da mag es „Anzahl der Passagiere“ geben. Bei einem Frachtflugzeug, Militärflugzeug, Forschungsflugzeug erhält der dann keinen Zahlenwert zugewiesen und gut ist.
  • Wir können sogar |Gericht=BVerfG abfragen und eine Fehlermeldung anzeigen, falls das irrtümlich in ungeeigneten Situationen belegt wurde.
• @ „und die Infobox könnte erweitert werden?“
  • Das geht immer nur vom Allgemeinen in die Spezialisierung.
  • Also deduktiv.
  • Eine Induktion fährt immer vor die Wand.
  • Eine allgemeine, offene Konzeption kann dann für Spezialfälle genutzt werden.
  • Andersrum geht es nicht. Wenn man mit einem Spezialfall beginnt, dann zieht jede spätere Erweiterung nach sich, dass das Parametermodell verändert werden muss.
  • Das ist dann verwirrend, wenn sich laufend das Parametermodell ändert.
  • Der Spruch lautet dann: „Das hättet ihr euch dann mal vorher überlegen müssen.“
  • Für das „vorher überlegen“ ist diese Werkstatt zuständig.
  • Soooo schrecklich kompliziert ist die Welt nun auch wieder nicht. Pflichtparameter aind sicher Aktenzeichen, Datum hü und hott, welches Gericht. Dazu kommen allerlei optionale Parameter; auszufüllen wo sinnvoll und bekannt, sonst halt nicht. Gerichtsentschaidungen von Gericht A und B in Deutschland sind nicht fundamental inkompatibel.
  • In einem allgemeinen Konzept können hinterher leicht zusätzliche optionale Parameter ergänzt werden, wenn sich Bedarf herausstellt.

Sinn einer Infobox ist es, dass das Publikum wesentliche Schlüsseldaten übersichtlich und einheitlich immer in der gewohnten Form in möglichst allen einschlägigen Artikeln findet und sich darauf einstellt.

• Längere Texte sind ungeeignet; die passen besser in den allgemeinen Haupttext.
• Aktenzeichen, Datum, Datenbanklinks, Schlagwörter; dazu Verlinkung möglichst des Volltextes, notfalls des Tenors wären zu erwarten.
• Eine Infobox wird perspektivisch in allen wichtigen Artikeln in einheitlicher Darstellung erwartet; sonst gibt es keinen Gewöhnungseffekt.
• Eine Beschränkung auf magere 8 Artikel ist nutzlos; vor allem wenn über 100 vorhanden sind.
• Ob und wer in den nächsten Jahrzehnten Infoboxen bei Bundesgerichten oder dann OLG verbaut, ist heute nicht festzuschreiben, und diese Menschen müssen noch überhaupt nicht aktiv geworden sein.

VG --PerfektesChaos 09:44, 12. Sep. 2023 (CEST)

Danke @PerfektesChaos für deine bisherige Mühe. Ich hatte durchaus angefangen, deinen Hinweisen Verständnis entgegenzubringen und könnte mir eine "Gemeinschaftsbox" für die Bundesgerichte inzwischen ganz gut vorstellen. Das wird natürlich Feinarbeit nach sich ziehen und wahrscheinlich wieder 10 Kilometer Diskussionen im Portal. Ich bitte dich um Verständnis, dass die Erwartungshaltung eines logisch und systematisch denkenden Programmierers vielleicht nicht mit der eines Juristen, der sich täglich mit unsortierter Kasuistik herumschlagen muss, übereinstimmt. Ich denke nicht, dass eine Box an einem Adler, keinem Adler oder an einem Stichtags-Adler scheitern muss. Die vorhandenen Artikel zu Entscheidungen des BVerfG ergingen alle vor dem Stichtag. Dieses Feld mit dem Hoheitszeichen völlig leer zu lassen, erscheint mir allerdings wenig sinnvoll. Das Hoheitszeichen ist nun mal das Markenzeichen des Gerichts. Vielleicht gibt es doch noch eine Möglichkeit für dich, die Feinarbeit erstmal zurückzustellen. Zwischenzeitlich würde ich die Adlerfrage im Portal klären. Sag mir bitte Bescheid, ob das für dich annehmbar ist. --Opihuck 00:30, 14. Sep. 2023 (CEST)

Ich denke nicht, dass eine Vorlagenerstellung an einem Vogel scheitern wird. Wohl aber an einer "Vereinheitlichung". Vorlagen können mehr als ihr derzeit auf dem Schirm habt; möglich wäre auch, dass Parameter je nach eingetragenem Gericht nicht akzeptiert werden. Damit kann eine Vereinfachung für uns und auch für die Wartung erzielt werden. Wie Diskussionen im Portal ausgehen, ist uns, mit Verlaub, egal. Wir müssten nur eine Vorlage anpassen und nicht weitere erstellen, diese dokumentieren und pflegen. --darkking3 ^Թ 12:30, 19. Sep. 2023 (CEST)

Hallo darkking3, leider kann ich mit deinem vorstehenden Beitrag nicht viel anfangen (Wie Diskussionen im Portal ausgehen, ist uns, mit Verlaub, egal.). Siehst du eine Möglichkeit, deine technische Kompetenz mit inhaltlichen Gestaltungsanforderungen des Portals:Recht zu verbinden oder ist dir völlig egal, was die hier um Unterstützung Suchenden möchten? Eine so dermaßen arrogante Haltung wäre nicht das, was ich mir von einer Vorlagenwerkstatt wünschen würde. Gleicher Appell zur Besinnung geht natürlich auch an PerfektesChaos. Danke euch beiden für ein Nachdenken. --Opihuck 20:40, 22. Sep. 2023 (CEST)

Ich würde es vielleicht etwas weniger drastisch sagen, aber soviel stimmt schon: Ich bin auch etwas irritiert darüber, dass unser Ergebnis, dass man nicht sämtliche gerichtlichen Beschlüsse aller deutschen Gerichte (und dabei ginge es ja auch nur um diejenigen, die den Relevanzkriterien entsprächen) mit ähnlichen Begriffen beschreiben kann. Es gibt Unterschiede, und wir fangen jetzt erst einmal beim Bundesverfassungsgericht an. Jede Gerichtsbarkeit und jede Instanz müsste dann noch einmal einzeln betrachtet werden. Wir hatten uns vorgestellt, dass uns die Vorlagenwerkstatt dabei unterstützen würde. Das wäre doch auch schön, meint ihr nicht auch? Danke und --Viele Grüße, Aschmidt (Diskussion) 10:26, 23. Sep. 2023 (CEST)

1. Ich hatte bereits einmal versucht, dir per Induktion ./. Deduktion zu erklären, dass das nicht geht.
   • Es lässt sich nicht von einer Spezialvorlage zu einer allgemeinen „erweitern“.
   • Du kannst nicht mit einer speziellen BVerfG-Vorlage beginnen und das später irgendwie aufbohren.
   • Du kannst nur mit einem weitsichtigen Konzept beginnen und dann anfangen, das für Gericht=BVerfG zu bevölkern und dann irgendwann mit anderen Bundesgerichten usw. weitermachen.
2. „Begriffe“
   • Das sind hier rein technische Bezeichner.
   • Früher mal hatte man unbenannte, also Zahlen 1, 2, 3, 4 verwendet. Das verschiebt die Notwendigkeit auf die Dokumentationsebene, schafft aber das Problem der Unanschaulichkeit und Verwechslungsgefahr.
   • Es wäre eher schlauer, allgemeine Wörter als Parameternamen zu wählen, statt sehr spezieller mit genau definierter Sonderbedeutung, die dann mit einer anderen Situation kollidieren.
     • Deshalb auch „Entscheidung“, weil das Urteile, Beschlüsse und sonstwas umfasst, und nicht gesonderte Vorlagen erforderlich sind.
   • Die technischen Bezeichner werden geschickterweise so gewählt, dass sie an die gemeinte Bedeutung erinnern; sie müssten aber keine präzisen Spezialbegriffe sein. Wesentlich wäre vielmehr, dass sie sich von den anderen Bezeichnern und deren Bedeutung unterscheiden.
   • Az oder Aktenzeichen wird ja wohl bei allen Gerichten die gleiche Bedeutung haben.
3. Parametermodell
   • Es gibt nur Pflichtparameter und optionale Parameter.
   • Es kann ja durchaus sein, dass bestimmte optionale Parameter nur für Gericht=BVerfG anwendbar sind und sonst niemals. Dann wird dies halt bei allen anderen schlicht nicht angegeben, und wir können sogar eine Kollisionswarnung darstellen, falls das irgendwann mal irrtümlich unpassend gemacht wurde.
   • Da mag es weitere geben, die vielleicht nur bei Straf-, Zivil- oder Verwaltungsverfahren möglich sind. Die Anzahl der Jahre, zu denen jemand verknackt worden sei, wäre beim Zivilprozess nicht möglich. Na und? Dann wird dafür halt kein Wert benannt.
   • Bei bereits Zigtausenden anderer Vorlagen tritt in deren Anwendungsthema eine analoge Situation auf, und alle anderen haben das problemlos hinbekommen. Es ist nicht einsehbar, warum Juristen oder die deutschen Rechtswissenschaften einzigartig auf dem Planeten sein sollen.
   • Wir haben auch eine allgemeine Vorlage zur Gliederung von Gebietskörperschaften, die für Dörfer, Regierungsbezirke, Städte, Samtgemeinden, Landkreise, Ortsteile, kreisfreie Städte oder Bundesländer passen dürfte. Natürlich haben die unterschiedliche Ausprägungen, vielleicht gar von Bundesland zu Bundesland unterschiedlich. Das ist aber völlig wumpe, weil die nicht passenden optionalen Parameter dann nicht angegeben werden und fertig.
4. Es ließen sich sogar innerhalb derselben Vorlage sämtliche Entscheidungen aller Gerichte auf dem Planeten abbilden.
   • Nur wäre das nicht sehr weise, weil es eine große Menge optionaler Parameter nach sich ziehen würde, nebst komplexer Programmierung und schwer überschaubarer Dokumentation.
   • Der Denkfehler hier ist anscheinend, dass irrtümlich geglaubt wird, alle von der Vorlage bereitgestellten Parameter müssten bei jeder Einbindung ausgefüllt werden, und eine Vorlage dürfe ausschließlich solche Parameter anbieten, die immer sinnvoll mit einem Wert belegt werden könnten.
5. Es lässt sich mathematisch zeigen, dass die angebotene vereinigte, universelle Vorlage immer funktioniert:
   • Gericht TypA habe einen Parametersatz.
   • Gericht TypB habe einen etwas anderen Parametersatz.
   • Beide teilen sich Grundbedingungen, etwa das Aktenzeichen oder Entscheidungsdatum. Die lassen sich dann zu Pflichtparametern machen, oder als gemeinschaftliche optionale Parameter anbieten.
   • Dann mag es etwas geben, das nur bei Gericht TypA möglich und sinnvoll sei. Das wird dann optionaler Parameter.
   • Dann mag es etwas geben, das nur bei Gericht TypB möglich und sinnvoll sei. Das wird dann optionaler Parameter.
   • Dann träte Gericht TypC auf den Plan. Die kann das bisherige Angebot nutzen, insbesondere wenn die Bezeichner der Parameter allgemein genug gehalten wurden, und bringt ggf. eigene spezifische Parameter ein.
   • Kollisionen bei irrtümlich inkompatiblen Zuweisungen lassen sich detektieren und melden. Ein Bundesland= wäre bei einem Bundesgericht unzulässig.
   • Das alles geht aber nur, wenn man mit einem abstrakten beliebigen Gericht anfängt und das bedarfsweise auf Besonderheiten einengt.

VG --PerfektesChaos 12:42, 23. Sep. 2023 (CEST)

Arogant sollte die Antwort nicht sein, sondern eher der Hinweis darauf, dass später Gefordertes einfacher nachrüstbar ist als eine vollständige Neuanlage. Das Erstellen (sowie Pflege und Wartung) bindet nunmal auch bei uns Ressourcen, die sich durch die von euch angedachte Vereinzelung entsprechend vervielfältigen. --darkking3 ^Թ 19:18, 24. Sep. 2023 (CEST)

Das verstehe ich irgendwo, aber verstehe du bitte auch, dass es nicht sinnvoll ist, sich über eine aufgeblähte Vorlage, die irgendwelche Perspektiven vorsieht, Gedanken zu machen, die - Stand heute - keinerlei realistische Chance auf eine Nachfrage hat. Der Artikelbestand betrifft wie aufgezeigt hauptsächlich Entscheidungen des BVerfG und des BGH. Artikel über Gerichtsentscheidungen der Ländergerichte gibt es bislang nicht, und dass sich das demnächst ändern wird, ist nicht zu erwarten. Warum sollten wir uns über Besonderheiten, z. B. der Aktenzeichenstruktur der Ländergerichte den Kopf zerbrechen, wenn es bis jetzt keine einzige Entscheidung gibt, mit der sich ein Artikel befasst, wo das eine Relevanz hätte? Verzeihung, ich verstehe ja den Wartungsaufwand bei euch, aber versteht bitte auch den gigantischen Besprechungsaufwand bei uns - für nichts und wieder nichts! Wenn es euch möglich erscheint, eine gemeinsame Vorlage für BVerfG und BGH zu erstellen, hätten wir schon mal eine ausbaufähige Universalvorlage mit zwei Varianten. Später eine dritte Variante (z. B. BVerwG), eine vierte (z. B. BSG) und eine fünfte (z. B. BFH) hinzuzufügen, dürfte dann nicht mehr so schwierig sein. --Opihuck 19:53, 24. Sep. 2023 (CEST)

Vielleicht eine Nachfrage: ist es möglich je nach Schalter (also BVerfG, BGH, etc.) unterschiedliche Parameterbescreibungen anzuzeigen für den gleichen Parameter? Denn diese Beschreibungen waren doch eine große Streitfrage und wenn wir für jedes Gericht eigene anfertigen könnten, würde das vieles erleichtern. --Ichigonokonoha (Diskussion) 20:49, 24. Sep. 2023 (CEST)

Tatsächlich stellt sich unsere Anfrage so dar, wie von Opihuck skizziert. Andererseits überzeugen mich aber auch die Punkte, die PerfektesChaos und Darkking3 dargelegt haben, vor allem Ziffer 5. Wir denken von der juristischen Praxis her, und die Kollegen denken es theoretisch und von der Programmierung her, die auf uns viel komplizierter wirkt als für sie. Zwischen diesen beiden Welten müsste man nun eine Brücke schlagen. Und der Weg dazu führt tatsächlich über die Arbeitsweise der Vorlagenwerkstatt, der, soweit habe ich es verstanden, eine große Vorlage für alle denkbaren Fälle, die man durch optionale Parameter nach dem Wenn-dann-Muster gestaltet, einfacher zu erstellen und zu pflegen wäre als eine Vielzahl von Vorlagen für jedes Gericht einzeln. Dann machen wir es doch so? Und was die Frage von @Ichigonokonoha zu den Parameterbeschriftungen angeht: Das kann auch in die Dokumentation und die Handreichung zur Vorlage ausgelagert werden mit Kopiervorlagen für jedes Gericht, für das die Vorlage bis dahin ausgebaut wurde. Vielleicht erstmal soviel. Viele Grüße, Aschmidt (Diskussion) 21:42, 24. Sep. 2023 (CEST)

Was ist mit unterschiedlichen Parameterbeschreibungen genau gemeint? Beispielsweise sind geschlechtsspezifische Positionsbeschreibungen oder abweichende Titulierung problemlos möglich. Auch soetwas wie eine Umschaltung für Aktenzeichen ist automatisiert möglich, sodass z.B. BGH-AZ, BVerfG-AZ usw. in der IB angezeigt wird, der Parameter jedoch immer AZ/Aktenzeichen heißen könnte. Wie Aschmidt bereits schrieb, ist das über wenn-dann-sonst o.ä. problemlos möglich. --darkking3 ^Թ 13:08, 25. Sep. 2023 (CEST)

Ich meinte damit die Beschreibung, die einem bspw. beim Arbeiten mit der Vorlage angezeigt wird. Für Angewandtes Recht (was ja als Parameter bspw. für alle Gerichte anwendbar wäre) hatten wir uns geeinigt, welches Recht beim BVerfG das umfassen soll. Nun wäre die Frage, ob wir eine andere Beschreibung angeben können, also eine Handlungsanweisung, die beim Bearbeiten angezeigt wird, wenn man bei Gericht BGH angibt. --Ichigonokonoha (Diskussion) 20:28, 25. Sep. 2023 (CEST)

Das klingt für mich nach der Beschreibung, die bei der Bearbeitung der Vorlage in Artikeln z.B. mit dem Visual Editor angezeigt wird? --darkking3 ^Թ 09:06, 26. Sep. 2023 (CEST)

Formelumrandung

Hallo, in Plancksches Strahlungsgesetz werden einzelne Formeln mit Umrandung hervorgehoben. Gibt es hierzu eine Vorlage oder könnte man eine erstellen? --Mrmw (Diskussion) 11:32, 19. Sep. 2023 (CEST)

Naja, Vorlage:Kasten, aber eigentlich sind derartig dekorierte Inhalte nicht Stil des Hauses, und deshalb gibt es für diese Situation auch keine spezielle Vorlage und keine breite Anwendung. VG --PerfektesChaos 12:08, 19. Sep. 2023 (CEST)

Mit Vorlage Kasten lässt sich dies aufgrund der eigenen CSS-Definitionen nicht umsetzen. Auch lässt sich VL Kasten mit display:table-cell; nichtmal dazu zwingen, sich wie eine Tabellenzelle zu verhalten. --darkking3 ^Թ 12:34, 19. Sep. 2023 (CEST)

Ich dachte auch eher an grundlegende Definitionen mitsamt Text wie Satz des Pythagoras oder so.

Einfach nur Rahmen um beliebige unter Dutzenden Formeln malen, weil das im Schulbuch so gemacht wird, ist nicht unser Stil.

VG --PerfektesChaos 12:48, 20. Sep. 2023 (CEST)

Das war auch eher als Hinweis gemeint, dass dies nicht funktionieren wird. Mit einem separatem div als tabellen zelle definiert und die Rahmen angeschaltet, klappt es. --darkking3 ^Թ 10:00, 21. Sep. 2023 (CEST)

Vorlage:Positionskarte none

Hallo zusammen, ich wurde auf diese Seite verwiesen. Bitte siehe:

• Wikipedia:Fragen zur Wikipedia#SLA
• Hilfe Diskussion:Vorlagen#Vorlage:Positionskarte none

Irgendetwas hat ausgelöst, dass 5 ganz normale Artikel (Chipilo, Zaraza, Tarma (Stadt), Elbaue zwischen Saalemündung und Magdeburg, Leuchtturm Kiipsaare) gestern in der Kategorie:Wikipedia:Schnelllöschen waren. Auf die Vorlage:Positionskarte none, die nicht existiert und deren Seiteninhalt nur Unfug war, wurde ein SLA gestellt. Im Quelltext der 5 Artikel war die Vorlage aber gar nicht eingebunden. Und warum ist sie immer noch in zig Artikeln eingebunden? [2]

Danke und viele Grüße, -- Toni 14:40, 23. Sep. 2023 (CEST)

Die Datenbank hat primär Informationen darüber, ob bei Änderung der Seite/Vorlage/etc. X die Seite Y neu aufgebaut werden muss. Wenn also eine nicht existente Seite X mit #ifexist aus Y abgefragt wird, dann ist es fraglos so, dass bei Anlegen der Seite X dieses Y neu aufgebaut werden muss.

Dass wir User diese Abhängigkeit als "Einbindung" interpretieren ist eine (teilweise) Fehlinterpretation, quasi ein (kleiner) Missbrauch dieser Datenbankinformation. --Wurgl (Diskussion) 15:00, 23. Sep. 2023 (CEST)

Heißt für den Otto-Normal-Vorlagen-Dödel?--tsor (Diskussion) 15:32, 23. Sep. 2023 (CEST)

Heißt für Otto-Normal-Vorlagen-Dödel dass "#ifexists" durch Datenbankabfragen nicht von einem Rotlink unterschieden werden kann und auch dass eine Änderung der Datenbank nicht zu erwarten ist. --Wurgl (Diskussion) 15:44, 23. Sep. 2023 (CEST)

Sagt mir jetzt nichts, soll bedeuten dass man nichts machen braucht/kann? -- Toni 15:57, 23. Sep. 2023 (CEST)

Ja das heißt das. Das wurde auch gestern bereits auf Spezial:Permanenter_Link/237569837#c-PerfektesChaos-20230921192800-Mabschaaf-20230921151500 erklärt. Dieses „Problem“ ist aber unabhängig von dem SLA-Problem, für das bisher noch niemand eine Erklärung hat. MfG, Dwain 16:13, 23. Sep. 2023 (CEST)

Ich hab gestern bei meiner Datenbankabfrage nix gefunden, weil ich nach eingebundenen Vorlagen gesucht habe. Wenn aber die Vorlage nur eingebunden wird, falls sie existiert (daher dieses #ifexists), dann kann meine Abfrage nix finden. Falsch gedacht eben. "Positionskarte none" hingegen ist in allen 5 per Pagelink (eben als #ifexists) eingebunden. --Wurgl (Diskussion) 16:39, 23. Sep. 2023 (CEST)

Media Wiki Tabellen

Hallo, ich würde gerne eine neue Tabellenklasse erstellen. Weiß jemand wie das geht? Grüße, --109.43.241.57 12:16, 30. Sep. 2023 (CEST)