Vorlage Diskussion:DatumZelle

Diese Diskussionsseite dient dazu, Verbesserungen an der Vorlage „DatumZelle“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Abgrenzung zu SortDate?

Wie soll diese Vorlage in Abgrenzung zu Vorlage:SortDate verwendet werden? 80.135.60.91 11:09, 16. Apr. 2020 (CEST)

Steht auf Vorlage:Navigationsleiste Vorlagen zur Tabellensortierung – „fügen in den Inhalt des Dokuments keine unsichtbaren Täusch-Daten ein“.

SortDate ist Technologie von 2008; spätestens ab 2012 gab es jedoch data-sort-value – was bei Vorlage:SortKey #Beschreibung schon genauer angedeutet wird.

Die ganze Serie von vor 2010 ist obsolet; teilweise können sie inzwischen ganz wegfallen, teilweise haben die …Zelle eine für den VisualEditor möglichst gut geeignete Parameterstruktur.

Die gesamte Story gibt es irgendwann auf einer komplett erneuerten Hlfeseite.

TL;DR: SortDate ist mittelfristig auszurangieren; aber das muss vorher über die Hlfeseite kommuniziert werden. Einstweilen keine öffentlichkeitswirksamen Aktionen.

VG --PerfektesChaos 12:21, 16. Apr. 2020 (CEST)

Warum steht das nicht irgendwo bei der Vorlage:SortDate? Ich habe in den letzten Monaten ein paar Dutzend neue Artikelentwürfe angelegt und diese Vorlage verwendet, da sie das tut, was ich wollte. Jetzt zu lesen, dass sie eigentlich seit Jahren obsolet ist, pisst mich offen gestanden etwas an. Hätte ich das vorher gewusst, hätte ich gleich die aktuellere Vorlage verwendet. Warum sollte "keine öffentlichkeitswirksamen Aktionen" diesbezüglich geben? Entweder ist die Vorlage verlatet, dann sollte das in der Dokumentation stehen, oder man sollte sie verwenden. -- -- Perrak (Disk) 20:40, 14. Jul. 2020 (CEST)

Persönliche Eitelkeiten diverser Beteiligter.

Das ist schon immer so gewesen, das haben wir noch nie anders gemacht, das muss immer so bleiben wie wir das mal gelernt hatten.

Die alte Technik ist spätestens mit 2012 obsolet geworden, die neue Serie hatte ich mangels zeitlicher Kapazitäten erst im Frühjahr 2020 komplettieren können.

Dazu gehörte auch eine inzwischen komplett neu geschriebene Hilfeseite, die die Hintergründe erläutert.

Wer hat das beschlossen? Wo wurde das diskutiert? Wer hat dir das erlaubt? Was fällt dir ein? Da musst du erstmal ein MB machen.

Vorlage:dts wird dir da schon eher gefallen. Wir haben allerdings drei obsolete Vorlagen für den gleichen Zweck; auch das so ein historisches Erbe der ersten Generation.

VG --PerfektesChaos 21:21, 14. Jul. 2020 (CEST)

Ja, das ist besser. Nur weil man etwas immer so gemacht hat, ist das doch kein Grund, etwas besseres neues zu tun. Okay, ich gehöre manchmal auch zu der "haben wir immer schon so gemacht"-Fraktion ;-), aber Deine Argumente für die neue und gegen die alte Vorlage sind doch nachvollziehbar. Okay, dass Du mit der neuen Serie gerade erst fertig geworden warst hate ich nicht gewusst, dann nehme ich den Rant bedauernd zurück ;-) -- -- Perrak (Disk) 22:31, 14. Jul. 2020 (CEST)

Schon okay.

Musste erst H:TSORT#Obsolet bauen (seit Mai 2020 produktiv verlinkt) und die wiederum benötigte den vollständigen Satz neuer Vorlagen. Ist damit ein Henne-und-Ei-Problem.

Mittlerweile gibt es aber auch schon 1.200 Einbindungen der neuen umseitigen Vorlage, und damit den Nachweis, dass das auch funktioniert, und das Baby spielt in der gleichen vierstelligen Liga mit wie die ein Jahrzehnt aktiven Vorlage:SortDate und Vorlage:dts.

Zu „warum wurde das geändert?“ frisch von heute morgen. Das wird noch einige Jahre dauern.

VG --PerfektesChaos 15:50, 15. Jul. 2020 (CEST)

einstellige Tage

Hallo,
diese Vorlage benutzt als Standard die abgekürzten Monatsnamen. Das wäre sinnvoll, wenn dadurch ein Flattern durch die unterschiedlichen Längen der Monatsnamen verhindert würde. Das wird es aber nicht, da es keinen Ausgleich bei einstelligen Tagen gibt, 14. Juli 2020 ist immer noch länger als 6. Jan. 2020. Kann man das ändern? -- -- Perrak (Disk) 20:37, 14. Jul. 2020 (CEST)

Nicht trivial, und es würde auch Probleme mit der mobilen Welt geben.

Du kannst jedoch individuell pad=1 setzen.

Die alte Welt hat immer Desktop gehabt.

Die neue Welt muss auch probieren, eine Tabelle mit fünf Spalten auf einem Smartphone darzustellen, und da wäre es doof, für alle einstelligen Tagesnummern, und nur diese mag es geben, wenn lediglich der 1. Januar und 1. Juli vorkämen, unnötig und standardmäßig Platz zu vergeuden.

VG --PerfektesChaos 21:21, 14. Jul. 2020 (CEST)

Stimmt, stelle ich in letzter Zeit, seit ich ein modernes Mobiltelefon besitze, auch imemr wieder fest. Deinen tipp probiere ich demnächst aus, danke. -- -- Perrak (Disk) 22:31, 14. Jul. 2020 (CEST)

Es gibt auch welche, die richten das Datum rechtsbündig aus, weil zu manchen Ereignissen nur die Jahreszahl angegeben werden kann, manchmal ist nur der Monat oder die Jahreszeit bekannt, und manchmal gibt es ein tagesgenaues Datum. Dann stehen zumindest die Jahreszahlen brav untereinander.

VG --PerfektesChaos 15:50, 15. Jul. 2020 (CEST)

Wäre auch eine Möglichkeit. Geht das spaltenweise oder muss die Ausrichtung dann in jeder Zelle wiederholt werden? Letzteres wäre mir im Quelltext wahrscheinlich zu unschön ;-) -- -- Perrak (Disk) 17:03, 15. Jul. 2020 (CEST)

Es gibt seit zwanzig Jahren eine unwillige vage ablehnende Absichtserklärung der Browser-Anbieter, irgendwann in HTML mal Eigenschaften für ganze Spalten vermehrt zu unterstützen.

Spalten widersprechen aber dem HTML-Eltern-Kind-Konzept, und sind wegen irregulärer (nicht trivial gitterförmig strukturierter) Tabellen auch nicht so ohne Weiteres dazu zu bekommen, für die achtzehnte Spalte Eigenschaften zu übernehmen.

In HTML können Eigenschaften von Eltern auf die Kinder vererbt werden. Stammvater/mutter ist die Tabelle, deren Nachfahren sind die Zeilen, deren Kinder die einzelnen Zellen. Es kann also die ganze Tabelle etwa an alle Zeilen und jede Zeile etwas an die einzelnen Zellen vererben, die ihre Kinder sind.

Die Spalten sind aber keine Kinder von irgendwas und ergeben sich nur rechnerisch, nicht aber logisch.

VG --PerfektesChaos 19:06, 10. Aug. 2020 (CEST)

Stimmt, Du hast recht, da hätte ich selbst drauf kommen können. Zu meiner Entschuldigung: HTML habe ich vor etwa 25 Jahren gelernt, da waren sogar Layout-Tabellen noch üblich ;-) -- Perrak (Disk) 20:44, 10. Aug. 2020 (CEST)

Könnte pad=1 statt nur eines Leerzeichens die Vorlage {{0}} oder Entsprechendes einfügen, um die Zahlenabstände auszugleichen?
In dieser Tabelle musste ich ziemlich tricksen, um {{Dts}} zu ersetzen, häufig mit "von…bis"-Daten. Bitte gerne nachbessern… Gruß --Chiananda (Diskussion) 03:23, 14. Feb. 2021 (CET)

Problem mit dem Jahr 17 n. Chr.

Hallo, ich habe die Vorlage in Liste von Erdbeben in der Türkei verwendet, wo teilweise nur Jahreszahlen bekannt sind. Leider funktioniert die Sortierung für einen Eintrag nicht: das Jahr 17 interpretiert die Vorlage anscheinend als 2017, jedenfall scheint der Eintrag bei der Sortierung nach Jahren zwischen zwei Einträgen von 2011 und 2019 auf. Wäre dankbar für Tipps, wie ich das Problem umgehen kann. --IllCom (Diskussion) 11:04, 20. Jul. 2020 (CEST)

@IllCom: Sorry, gerade erst gesehen.

Du hattest es genau richtig gemacht: 0017

Wird sich in den nächsten Tagen unaufgefordert unbemerkt verbessern.

Ist eine PHP-Regel zur Kompatibilität mit historischen Millenium-Bug-Angaben.

Ich sichere jetzt grad mal die Darstellung mit einem n.Chr. aber das hatte noch keinen durchschlagenden Erfolg.

Problem ist, dass zurzeit an der entscheidenden Stelle der numerische Wert genommen wird und damit die führenden Nullen vergessen werden. Sollte nicht sein.

Nebenbei, falls du was damit zu tun hättest: DOI sind robuster und können gern zusätzlich zu URL-Verlinkungen angegeben wrden, auch wenn jetzt im Moment das gleiche PDF dabei rauskommt. Aber in ein paar Jahren ist die heutige PDF-Website vielleicht offline, und der DOI verlinkt auf eine Seite wo sich zwischen E-Book, HTML und PDF wählen lässt.

LG --PerfektesChaos 18:14, 10. Aug. 2020 (CEST)

Danke für die Rückmeldung und die guten Aussichten :) --IllCom (Diskussion) 18:24, 10. Aug. 2020 (CEST)

• Schlechte Nachricht: Meine Antwort eben war inhaltlich teilweise falsch.
• Gute Nachricht: Jetzt ordnungsgemäß; das n.Chr. habe ich mal drangebamselt damit die 17 nicht so nackt und ungewohnt da steht.
• Ursache ist eine andere gewesen: Hilfe:Tabellen/Sortierung #Datum „vor dem Jahr 100 n.Chr.“
• Hintergrund ist der gleiche: Wegen Millenium Bug und historischer zweistelliger Angaben werden die Zahlen 0–99 zwischen 1938 und 2037 verortet, oder irgendwie sowas.
• Wenn es in die Antike und vorchristlich werden soll, muss die gesamte Spalte nach ISO sortiert werden.

LG --PerfektesChaos 18:58, 10. Aug. 2020 (CEST)

Aha, dass das mit dem Schlüsselwort "date" zusammenhängt war mir nicht bewusst, bzw. hab ich offenbar überlesen. Freut mich jedenfall riesig, dass sich die Tabelle jetzt korrekt sortieren lässt. Vielen Dank für Deine Hilfe! LG --IllCom (Diskussion) 19:04, 10. Aug. 2020 (CEST)

Die Sortierung stimmt immer noch nicht. Wenn ich einmal auf "Datum (Ortszeit)" sortiere, steht "8. März 2010" ganz oben, gefolgt von "17 n. Chr." (was jetzt unschönerweise als einziges Datum "n. Chr." hat). Form follows function, nicht umgekehrt! 80.135.62.156 22:08, 10. Aug. 2020 (CEST)

Sollte jetzt passen. Ich hab vorhin das Beben vom 8. März 2010 ergänzt, und dabei noch auf die vorherige Formatierung ohne type=i zurückgegriffen. Ist jetzt nachgetragen und sortiert korrekt. --IllCom (Diskussion) 22:15, 10. Aug. 2020 (CEST)

style-Parameter in Anführungszeichen

Hallo, eine Detailfrage bzw. Anmerkung zum style-Parameter. Ist dieser gesetzt, wirkt er offensichtlich unabhängig davon, ob Anführungszeichen verwendet werden oder nicht. Ich bin aber der Meinung, dass zumindest per Konvention immer Anführungszeichen zu verwenden sind. Drauf gestoßen bin ich anhand des Quelltextes von Hertha_BSC#Trainer_seit_1963. Insbesondere die derzeit letzte Tabellenzeile

| [[Bruno Labbadia]] || {{DatumZelle|2020-04-13|style=text-align:right}} || style="text-align:right;" |

zeigt aus meiner Sicht recht gut, warum fehlende Anführungszeichen ziemlich verwirrend sein können. Sehe ich das richtig? --rolf_acker (Diskussion • Beiträge) 21:08, 24. Aug. 2020 (CEST)

Nein; das Begrenzerzeichen in der Markup-Language wäre " oder ' – dort wird geguckt, ob das erste nicht-weiße Zeichen nach dem Gleichheitszeichen eines von diesen beiden wäre, und falls ein solches vorhanden wäre, so ist das zusammen mit dem paarig schließenden das Begrenzerzeichen. Einfache Ausdrücke ohne Leerzeichen usw. innendrin würden aber auch ganz ohne Begrenzerzeichen in den meisten Markup-Sprachen funktionieen, auch wenn das nicht das beste XML wäre. Weil aber zu leicht Edit-Unfälle passieren könne, etwa weil irgendwo eine Klasse hinzukommt, die dann ignoriert würde, setzen wir hier in der deutschsprachigen Wikipedia immer " beim Markup.

Bei Vorlagenparametern liegt die Sache aber völlig anders: Hier gibt es schon ein Begrenzerzeichen, nämlich das | bzw. } je nachdem, und ein doppeltes Begrenzerzeichen ist überflüssig. Es gibt eine Reihe von Vorlagenparametern, bei denen überflüssige " oder ' sogar die darin programmierte Syntax ruinieren würden. Deshalb setzen wir in Vorlagenparametern grundsätzlich keine solchen.

• Innendrin könnte stehen:
  • class="sortable {{{class|}}}"
  • style="font-size:larger; {{{style|}}}"
• Wenn du hier mit Begrenzerzeichen für die optionalen Parameter ankommst, dann schießt du die Wirkung ab.

Nun ist dieses Dingens hier ne Runde schlauer; es bemerkt eigentlich überflüssige Begrenzerzeichen und entfernt sie wieder. Es kann ja sein, dass die beim C&P nur reingeraten waren. Erwünscht sind sie trotzdem nicht.

Ganz grundsätzlich würde das aber nur die Quelltexte aufblähen, bei anderen Vorlagen auch was ruinieren, und deshalb sollen sie eigentlich nicht gesetzt werden; wo sie angetroffen würden könnten sie gelegentlich wieder eliminiert werden.

VG --PerfektesChaos 22:24, 24. Aug. 2020 (CEST)

Alles klar – Danke! --rolf_acker (Diskussion • Beiträge) 22:28, 24. Aug. 2020 (CEST)

Vermischen von Zellattribut und Zellinhalt

Das Hauptproblem dieser neuen Vorlage ist, dass sie eine Vermischung von Zellattribut und Zellinhalt vornimmt: Die Trennung dazwischen erfolgt in der Tabellensyntax durch ein (weiteres) Pipe, welches jetzt innerhalb der Rückgabe dieser Vorlage liegt. Das ist für den Anwender absolut nicht mehr nachvollziehbar. Ein erheblicher Teil der Parameter dient daher jetzt auch dazu, bisher im Quelltext der Tabelle stehende Zellattribute in die Vorlage hineinzuverschieben, was eine für den Autor noch schlechter nachvollziehbare Vermischung ist. Wer am Zeilenanfang | {{DatumZelle|...}} eingibt, der erwartet, dass, so wie in den letzten Jahrzehnten, die Vorlage einen Zellinhalt liefert und nicht, dass sie Änderungen an den Attributen bewirkt.

Natürlich ist Dtsx ein Hilfskonstrukt, dass man eigentlich auch nicht mehr bräuchte, aber ein Ersatz, welcher "data-sort-value" im Seitenquelltext nutzt, nimmt unweigerlich in Kauf, dass die Trennung zw. Zellattribut und Zellinhalt noch mehr verschwimmt, als dies bei der Wikisyntax ohnehin der Fall ist. Da ist es doch besser, die alte Vorlage erzeugt versteckten Code, als dass hier die Syntax vermischt wird.

Die einzige vernünftige Lösung wäre die seit Jahren angemahnte Formatierung duch den Parser, ohne dass man im Seitenquelltext herummengen muss. Es ist schlicht die Tatenlosigkeit diverser für die Programmierung des Parsers zuständiger Mitglieder der Foundation, dass "31. Mai 2020" nicht automatisch als Datum erkannt wird und beim Sortieren entsprechend berücksichtigt wird.

ÅñŧóñŜûŝî (Ð) 11:44, 29. Aug. 2020 (CEST)

Das ist keine „neue“ Technik, sondern die gibt es schon seit 2011/2012, als data-sort-value in die Sortierfunktion eingefügt wurde, die es ohnehin erst seit ca. 2008/2009 gegeben hatte.

• Zu den damaligen wie heutigen Gründen siehe Hilfe:Tabellen/Sortierung #Veraltet.
• Wenn hier überhaupt etwas ein Problem ist, dann dass die Verbesserung von 2011/12 bis heute noch nicht in den Schädeln angekommen zu sein scheint und ich schließlich erst dieses Frühjahr selbst die umseitige Vorlage bereitstellen musste. Würde das hier gut laufen, dann wäre das bereits 2013/14 allgemein im Projekt umgesetzt worden; statt dessen jammert man bis heute der Welt von 2010 hinterher.

Alles, was rechts von der Pipe steht, ist Inhalt der Zelle, gehört inhaltlich zum Text, wird von Cirrus genauso wie von externen Suchmaschinen als Inhalt betrachtet, erscheint in den Vorschau-Skripten (PopUp) von MediaWiki. Es ist Bestandteil des Inhalts des HTML-Dokuments.

• Dass es eine absolute Scheiß-Idee ist, nur optisch versteckte Inhalte zum Bestandteil des Zelleninhalts zu machen, hatte man bereits 2010 gewusst und deshalb um 2011 die data-sort-value entwickelt, damit die Sortierschlüssel gerade nicht mehr Teil des Inhalts sind, was wohl spätestens 2012 produktiv auf allen Wikis wurde.

Die „neue“ Vorlage generiert aus einer einzigen Angabe (hier das Datum, woanders Ruf- und Familienname einer Person) zwei Repräsentationen; die eine ist Attribut und kann vom Sortieralgorithmus ausgewertet werden, gehört aber nicht zum Inhalt; die andere ist die optisch dargestellte Repräsentation. Beide können hinsichtlich der Formatierung voneinander abweichen.

• Das war „früher“ auch nicht anders gewesen. Nur hatte man zwei Zellen-Inhalte generiert; der eine, der genauso wirksamer Inhalt der Zelle ist, sollte zum Sortieren benutzt werden, und danach kam nochmal einer, der sichtbar bleib. Und der erste, genau gleich wirksame Bestandteil des Inhalts wurde dann nur für die optische Darstellung im Browser ausgeblendet, gehört aber zum Inhalt des Textes mit dazu. Weshalb ihn auch die PopUps, Suchmaschinen und was auch immer als normalen enzyklopädischen Inhalt betrachten. Diese gepfuschte Krücke des „versteckten Code“ als Inhalt des HTML-Dokuments ist bereits seit 2011/2012 obsolet.
• Was ich nur befremdlich finde, ist dass man nach einem Jahrzehnt immer noch über den von 2009–2011 hierzuwiki mal praktizierten Holzweg debattieren muss und sich offenbar die „gute, alte Zeit“ zurückgesehnt wird.
• Der Parser kann hierdran überhaupt nichts machen, weil wenn etwas Inhalt ist, also rechts von der Pipe steht, dann muss der Parser es als Inhalt betrachten, schon aus Kompatibilität mit in anderthalb Jahrzehnten erstellter Seiten in Tausenden von Wikis innerhalb und außerhalb der WMF.
• Woran es vielmehr offenbar fehlt, ist die geistige Flexibilität im Vergessen der Methodik von 2010 und die kognitive Umstellung auf das Jahr 2012. Natürlich und schon seit 2011 müssen diejenigen, die sich mit der Programmierung beschäftigen, sich über den Unterschied zwischen Attribuierung und Inhalt klar sein. Das sind aber nur wenige. Autoren, die einschlägige Vorlagen verwenden, müssen sich hingegen relativ wenig Kopp machen; sie schreiben das Datum hin, ggf. auch nur Jahr bzw. mit Monat, und in Spezialfällen auch mal eine besondere gewünschte Formatierung. Wobei im Zeitalter der Eignung für Smartphones das Standardformat in aller Regel völlig ausreicht und Extra-Fummeleien meist überflüssig sind.
• Ach, übrigens: In seiner momentanen Ausgestaltung bietet der VisualEditor keinerlei Zugriff auf beliebige Attribute der einzelnen Zelle; die umseitigen Parameter schon.
• Und was das bejubelte dts/dtsx angeht: Das 78197280125♠ im versteckten Inhalt <span style="display:none" class="sortkey">78197280125♠</span> ist mit keinem anderen Format kompatibel, und damit diese Sortierung funktioniert, müssen ausnahmslos alle Zellen nur mit dieser Vorlage ausgestattet werden (nicht mal Vorlage:SortDate ist damit kompatibel, die verwendet heute: 50200829♠). Die Vorlage:DatumZelle generiert hingegen als Sortier-Attribut ggf. ein ganz normales Tagesdatum, und das kann mit anderen Zellen der Spalte gemischt werden, die ohne eine Vorlage ein ganz normales Tagesdatum in einem erkennbaren Format enthalten, und wenn man Monatsnamen ausschreiben mag oder sowieso 29.8.2020 schrieb kann man die nach Belieben genauso verwenden.

VG --PerfektesChaos 15:00, 29. Aug. 2020 (CEST)

Ich stelle nicht in Abrede, dass data-sort-value=irgendwas eine Verbesserung gegenüber den alten Workarrounds darstellt, aber das Problem bei deiner Umsetzung ist, dass genau jenes Pipe, welches Zellattribut und Zellinhalt trennt, jetzt innerhalb der Vorlage zu finden ist. Wir brauchen eine Lösung, bei der dieses data-sort-value=irgendwas im Artikelquelltext landet oder auch nur im HTML der Seite, weil der Parser den Inhalt als Datum erkennt und dann automatisch ein data-sort-value=irgendwas generiert. ÅñŧóñŜûŝî (Ð) 16:29, 29. Aug. 2020 (CEST)

Nein, man braucht da überhaupt nichts.

Und noch mal für dich wiederholt, von bereits oben:

• Die „neue“ Vorlage generiert aus einer einzigen Angabe (hier das Datum, woanders Ruf- und Familienname einer Person) zwei Repräsentationen …
• … die eine ist Attribut und kann vom Sortieralgorithmus ausgewertet werden, gehört aber nicht zum Inhalt; die andere ist die optisch dargestellte Repräsentation. Beide können hinsichtlich der Formatierung voneinander abweichen.
• … Das war „früher“ auch nicht anders gewesen.

Die in Rede stehende Pipe | steht zwischen der ersten und der zweiten Repräsentation, die aus dem einen und einzigen Parameterwert generiert wird.

• Da gibt es nichts anderes als „genau jenes Pipe, welches Zellattribut und Zellinhalt trennt, jetzt innerhalb der Vorlage zu finden ist“.
• Weil nur genau einmalig das Datum, der Name der Person als Parameterwert angegeben wird, daraus jedoch zwei Repräsentationen generiert werden, die eine als Sortierschlüssel, die zweite als optisch dargestellter Inhalt, steht das Pipe-Symbol genau zwischen der ersten und der zweiten Repräsentation, und kann auch nirgendwo anders stehen, und trennt die inhaltlich unwirksamen Attribute vom inhaltlichen Teil des HTML-Dokuments.

Es braucht eigentlich nichts anderes als den Entwicklungssprung von 2011 auf 2012 nachzuvollziehen und diesen schlichten Sachverhalt zu begreifen.

Ansonsten ist es auch nicht erforderlich, sich weiter mit dieser Vorlage zu befassen, sofern du sie als Autor in den Tabellen der von dir geschriebenen Artikel anwenden kannst. Wenn nicht, dann lasse es; sofern du ein taggenaues Datum hast, brauchst du schon seit einem Jahrzehnt überhaupt keinerlei Vorlagen mehr, weil die MediaWiki-Software sowieso nach Tagesdatum oder alternativ nach Jahreszahlen ganz von alleine sortieren kann. Was man hingegen nicht mehr machen sollte, wäre absichtlich bereits zur Eliminierung vorgesehene Vorlagen noch neu in Seiten einzubinden.

VG --PerfektesChaos 17:00, 29. Aug. 2020 (CEST)

Eingabeformate

Einige wichtige Eingabeformate funktionieren nicht:

Nummer	Parameter	Ergebnis	Info
1	30. Mai 2019	30. Mai 2019	Der Normalfall funktioniert...
1	30. Sep. 2019	30. Sep. 2019	Der Normalfall funktioniert...
1	30. Jun. 2019	30. Juni 2019	Der Normalfall funktioniert...
2	04/06/2018		US-Datum funktioniert nicht... weil es in Großbritannien und Frankreich der 4. Juni und in den USA der 6. April ist. Voraussetzung ist jedoch eine eindeutige Notierung.
2	2018-04-06	6. Apr. 2018	ISO-Datum funktioniert auch...
3	2018-4-7		fehlen die führenden Nullen, ist es trotz Eindeutigkeit schon vorbei.
4	5.8.1930	5. Aug. 1930	Numerisches Datum ohne Leerzeichen funktioniert
5	5. 8. 1930		Oha! Macht ein Anwender korrekter Weise brav Leerzeichen hinein, so versagt die Vorlage bereits.
6	03-09-2020		TT-MM-JJJJ sollte die Vorlage auch können, denn das ist auch eindeutig.
7	3-9-2020		Ist T-M-JJJJ zuviel verlangt?

Von wegen (Zitat): "Format beliebig (deutsch/englisch), sofern eindeutig interpretierbar. Einzelner Tag, auch unspezifischer Monat oder Tag im Monat ohne Jahr usw.."

ÅñŧóñŜûŝî (Ð) 11:44, 29. Aug. 2020 (CEST)

• Es gilt einheitlich für alle unsere Vorlagenparameter bei Bindestrichen das Format nach ISO 8601.
  • Damit ist die Spezifikation eindeutig für alle Wikis und alle Vorlagen und globale Module und das Kopieren zwischen Wikis und Wikidata nutzbar.
  • Damit ist für Tages- und Monatsangaben die zweistellige Angabe größer/gleich Null vorgeschrieben.
  • Eine Abwandlung davon würde die eindeutige Interpretation verhindern, und für Bots und Skripte und Wiederverwendung in anderen Wikis die Angabe uninterpretierbar machen.
  • Ist T-M-JJJJ zuviel verlangt?
    • Nach dem 11. September 2001 gab es einen interessanten Datenaustausch zwischen Scotland Yard und dem FBI: Ein Geburtsdatum eines Attentäters wurde aus Europa vielleicht als 04-05-1988 übermittelt. Für den Briten hieß das der 4. Mai. Ein US-Amerikaner liest dies als den 5. April und findet die Person nicht in der Datenbank.
    • Es gibt nirgendwo in Kontinentaleuropa ein Format T-M-JJJJ.
    • Ja, es ist zuviel verlangt, weil jedes neu von Wikipedianern hinzuerfundene private Extraformat die Eindeutigkeit und Interpretierbarkeit von Datumsangaben erschwert, sie für Auswertungen in der Cirrus-Suche und Bots und Skripte unzugänglich und unauffindbar macht, und den Autoren zusätzlichen Lernaufwand aufbürdet.
    • 03-09-2020 ist eine überflüssige und verwirrende Konkurrenzveranstaltung zur ISO 8601.
  • Der Sinn der maschinenlesbaren Bindestrich-Angaben ist, dass die Datumsangaben auch per Cirrus ausgewertet werden (und gleich einfach sortiert) werden können. |abruf=2010-04 ergibt alle Fälle die im April 2010 abgerufen wurden, |abruf=2010 alles aus 2010 und |abruf=201 alles aus den 2010er Jahren. Genauso wenn über |Datum=19 alles aus im 20. Jahrhundert Geschriebene gesucht werden soll, wobei hier noch |Datum=19. Mai in die Suppe spucken kann.
• Es gibt in der deutschen Rechtschreibung und Typografie keinerlei 5. 8. 1930 – das ist schlicht und einfach falsch, und es ist weder für menschliche Leser noch für Suchausdrücke überhaupt erkennbar, dass dieses konfuse Gebrabbel ein einziges zusammenhängendes Datum sein solle. Diese „braven Leerzeichen“ in voller Breite gibt es nirgendwo und sind schlicht und einfach ein Schreibfehler; siehe auch DIN 5008 und jeden Rechtschreibduden der letzten 50 Jahre.
• Es gibt in der deutschsprachigen Wikipedia nur noch vier gültige Formate für ein Datum; und dies sowohl direkt im sichtbaren Text wie auch als Vorlagenparameter, und in Übereinstimmung mit nationalen und internationalen Standards außerhalb der Wiki-Welt:

26. Dezember 2019	Standardformat für alle Direktangaben
26. Dez. 2019	Sonderformate für Tabellenspalten wegen Platzmangel, insbesondere auch auf Mobilgeräten
26.12.2019
2019-12-26	Parameterformat bei Vorlagen; erlaubt eine direkte Sortierung nach den Werten, kann auch um den Tag und die Monatsnummer gekürzt werden, und ermöglicht auch eine Cirrus-Suche nach Einträgen, die in einem bestimmten Jahr oder Monat eines Jahres liegen würden.

• Es war eine absolute Scheiß-Idee der Kindergartenjahre dieser Wikipedia, dass sich mehrere Vorlagenprogrammierer jeder seine privaten Formate für Datumsangaben ausgedacht hatten, die dann immer nur in der eigenen Vorlage funktionierten, und inkompatibel mit anderen Vorlagen waren (und erst recht mit Bots und Skripten). Das zwang die Autoren dazu, sich alle möglichen Zuordnungen zwischen Vorlage und dort gültigen privaten Formatierungsregeln zu merken und im Zweifelsfall beim Einfügen jeder Vorlageneinbindung vorher erst in der Doku nachgucken zu müssen, wie das jetzt grad hier wieder gemacht werden müsse.

Ich würde hier noch eins weiter gehen. Vorlagen (templates) gehören in keine nationale Wikipedia. Sie machen die Übertragung von Inhalten zwischen verschiedenen Wikipedias ohne komplette Neugestaltung unmöglich, rücken das automatische oder halbautomatische Übersetzen von Artikel in astronomische Ferne. Die Übersetzung eines Artikels aus Sprache A in die Sprache B ist mittlerweile die einfachste Aufgabe, aber den ganzen template-Kram zu übertragen führt dazu, dass man es nicht macht. Die Nationalisierung des Syntax ist eine Seuche. Es ist hier wesentlich schlimmer als bei Excel, weil die Funktionen nicht nur übersetzt sind, sondern es sie meistens nicht gibt und wenn es sie gibt, haben sie immer einen (manchmal nur subtil) anderen Syntax (float-Attribute von Tabellen z.B.).--2003:C3:6727:DB00:F9BC:E40B:A8CD:3DAD 11:43, 30. Apr. 2022 (CEST)

Du hast dich grad ebenüber das Nicht-Funktionieren eines US-Datumsformats echauffiert.

• Aber wie du oben und per Suche nach „Datenaustausch zwischen Scotland Yard und dem FBI“ sehen kannst, funktioniert dein englischsprachiges Zeugs noch nicht einmal innerhalb der englischsprachigen Kultur, weil die Interpretation in UK, US, Kanada, Australien oder Indien völlig unklar ist.
• Wir hier schreiben deutsche Formate (wobei die hier beschriebene Vorlage ISO 8601 nahelegt); umseitig versteht aber auch problemlos englischsprachige Monatsnamen.
• Aber wir stellen hier keine englischsprachigen Monatsnamen in Artikeln dar, damit du es irgendwie einfacher hättest.
• Du müsstest mir aber mal die von dir heißgeliebten globalen englischsprachigen Vorlagen zeigen, die auch deutsch-französisch-portugiesisch-russisch-arabisch-spanischsprachige Monatsnamen verstehen würden.
• Selbstverständlich geben die Vorlagen einer jeweiligen „nationale Wikipedia“ (naja, nicht die Nation Deutschland ist gemeint, sondern die deutsche Sprache, weil wir kennen mindestens noch AT CH FL) die Notwendigkeiten im jeweiligen Kulturkreis wieder, was deine globalen Träumereien nicht können.
• Du hingegen glaubst ja, die englischsprachige Welt würde nur aus den USA bestehen, und dein 04/06/2018 wäre das universelle alleinseligmachende. Es ist aber ein US-Format, und Briten und Franzosen und Quebec-Kanadier verstehen darunter etwas anderes. Das ist Kultur-Imperialisus der USA; der gesamte Globus hat alles genau so zu machen, wie die USA etwas schreiben oder formatieren, und die „nationalen“ (DACH, IT, FR) Sonderwege fordern dir nunmal ab, dass Übersetzer nicht einfach nur den Google Translator füttern, sondern Übersetzungen in die Kultur des Ziel-Wikis übertragen werden.
• Wenn du echte Globalisierung möchtest, dann müsste dein Ausgangs-Wiki nicht in der nationalen USA-spezifischen Notation 04/06/2018 das Datum angeben, sondern so wie umseitig nahegelegt 2018-04-06 und dann ist es auch das von über eine Milliarde Chinesen im Alltag verwendete Format. Der nationale Sonderweg deiner USA ist das Problem.
• Eben um den Austausch zwischen Wikis zu erleichtern, verwenden wir bevorzugt ISO-Codes für Datumsangaben und die Namen von Sprachen.

VG --PerfektesChaos 21:10, 30. Apr. 2022 (CEST)

• Die umseitige Vorlage akzeptiert alle eindeutigen nach einer deutschen oder englischen Rechtschreibung bzw. Standard zulässigen Formate, wie sie hier demonstriert werden. Was in keiner Rechtschreibung oder Standard erlaubt ist, das ist auch nicht als Vorlagenparameter erlaubt. Nicht umseitig erwähnt ist das schon mehr mögliche Vielfalt unterstützende Spektrum weiterer eindeutiger Formate, wie etwa Englisch.
• Im Übrigen gelten für Artikeltexte wie auch Vorlagenbenutzung die Wikipedia:Datumskonventionen und sind für die Wikipedianer maßgeblich.

VG --PerfektesChaos 14:05, 29. Aug. 2020 (CEST)

(BK) Unabhängig davon, was in der Vorlagendoku steht, sind die Ausgaben – wie oben in der Tabelle dargestellt – nach meinem Verständnis weitgehend ok. Insbesondere alle Fälle, in denen die Vorlage angeblich nicht funktioniert. Bitte nicht vergessen, dass in der deWP gewisse Datumskonventionen gelten. Bei ungültigen Formaten wie 2020-8-29 liegt das Problem nicht in der Vorlage, sondern bei dem, der die Vorlage damit zu füttern versucht. Insofern mögen manche der o. g. Angaben möglicherweise eindeutig sein, sie entsprechen aber nicht den hiesigen Regelungen. Wir fahren m. E. am besten, wenn wir – ähnlich wie im Fließtext (29. August 2020) – bei Datumsparametern von Vorlagen nur wenige, gültige Formate zulassen. Ich würde da sogar noch restriktiver vorgehen und lediglich das ISO-Format (2020-08-29) vorbehaltlos akzeptieren. Ergo: Wenn hier etwas geändert werden sollte, dann die Beschreibung der Vorlagendoku. Grüße, --rolf_acker (Diskussion • Beiträge) 14:08, 29. Aug. 2020 (CEST)

Auf eine derartige Verbesserung kannst du vermutlich lange warten, denn der Hauptautor hält sich - Nomen est Omen - meinem Eindruck nach "für aus dem Stand heraus perfekt". Wenn es mal kritisch wird - bespielsweise mein berechtigter Hinweis, dass Zellattribute und Zellinhalt vermischt werden, dann schweigt er schlichtweg. ÅñŧóñŜûŝî (Ð) 14:36, 29. Aug. 2020 (CEST)

@Antonsusi: Zielführender wäre vermutlich, sich auf sachliche und konstruktive Beiträge zu beschränken. Und ob man wirklich nach nicht einmal drei Stunden bereits eine ausstehende Antwort auf ein nicht-triviales Thema bemängeln sollte ?! Ich weiß nicht... --rolf_acker (Diskussion • Beiträge) 14:45, 29. Aug. 2020 (CEST)

Das wäre gewiss zielführend. Die Erfahrung von mir und anderen Usern mit PerfektesChaos zeigt aber, dass er nur sehr selten auf Vorschläge eingeht, auch dann, wenn sie nach mehrfacher anderer Meinung gut sind. Seine gute Kompetenz in diesem Gebiet wird durch seine Resistenz gegenüber Feature- und Dokuwünschen erheblich konterkariert. Die Doku - oder auch eine Hilfeseite - verbessern birgt für ihn das Risiko eines Machtverlusts. Wenn dadurch auch andere die Funktionalität verstehen und er sein Verständnismonopol auf seine Werke verliert, dann könnte es dazu kommen, dass auch ein anderer etwas programmiert, zum Beispiel eine Ergänzung ohne Eingriff in den Bestand. Es fehlt ganz einfach am Verständnis für andere Perspektiven:

Es ist nicht die Aufgabe von Vorlagen- und Modulschreibern, Artikelautoren in Sachen DIN und ISO zu belehren, indem wir sie per Vorlage zur Einhaltung einer expliziten Schreibweise zwingen. Die allermeisten Autoren hier scheren sich keinen Deut um ISO oder DIN. Entweder wir kommen denen entgegegen, indem wir zum Beispiel hier bei dieser Vorlage dafür sorgen, dass auch Leerzeichen - wurde früher mal in der Schule gelehrt(!) - und TT-MM-JJJJ (inkl. fehlender führender Nullen) akzeptiert wird (weil eindeutig), oder wir werden diese Autoren schlichtweg vertreiben. Der Autorenmangel ist auch durch Gängeleien wie dieses "nur drei bestimmte Eingabeformate werden verarbeitet" verursacht. Das schließt nicht aus, sich darauf zu verständigen, dass eine Vorlage alle nach DIN/ISO erlaubten Formate beherschen soll (als notwendige Bedingung). Darüber hinaus ist die oben erwähnte Vermischung von Zellattribut und Zellinhalt durch diese Vorlage hier ein viel ernsthafteres Problem. Gruß von ÅñŧóñŜûŝî (Ð) 16:16, 29. Aug. 2020 (CEST)

Für die Autoren gibt es eine ganz simple Regel:

1. Beachte Wikipedia:Datumskonventionen – überall; und was dort angegeben ist, funktioniert auch mit umseitiger Vorlage.
2. Es gibt vier gültige Formate, die bei Datumsangaben in Vorlagen mit etwas Glück unterstützt werden:
   • 26. Dezember 2019
   • 26. Dez. 2019
   • 26.12.2019
   • 2019-12-26
3. Was darüber ist, das ist von Übel – nach Mt 5,37
4. Jede zusätzliche private Variante macht es Bots, Skripten, dem Inter-Wiki-Austausch, der Cirrus-Suche, dem Transfer von einer Vorlage in den analogen Parameter einer anderen Vorlage ggf. unmöglich, diese ungültige Angabe zu verarbeiten.
5. Wenn ich die Wartungskatterei richtig deute, sind im Moment alle über 100.000 angegeben Zeitpunkte korrekt formatiert. Es besteht keinerlei Bedarf, ungültige Formatierungen zuzulassen. Autoren mögen sich an die erwähnte goldene Regel halten und bevorzugt 26. Dezember 2019 oder 2019-12-26 verwenden; Verkomplizierungen darüber hinaus braucht kein Mensch.

Die mit 2011 von MediaWiki eingeführte „Vermischung von Zellattribut und Zellinhalt durch diese Vorlage hier ein viel ernsthafteres Problem“ – ist keines, weil weder hatte es bisher einen Autor kümmern müssen, dass heute dtsx ein 78197280125♠ generiert und SortDate heute 50200829♠ noch braucht es die Autoren zukünftig zu interessieren, wie genau intern die umseitige Vorlage wann welche korrekte Sortierung herbeizaubert.

• Die einzigen, die das dieses Jahr und in den kommenden Jahren was anginge, wären Leutchen im Umkreis der VWS, die irgendwie mit der Pflege der Programmierung, der Beratung von Autoren oder der Pflege von Anleitungen etwas zu schaffen hätte.
• Und die eine Handvoll hat damit auch kein geistiges Problem.
• Nur wer immer noch dem von 2009 bis 2011 mal erforderlichen behelfsmäßigen üblen Hack mit dem „versteckten Code“ nachtrauert mag ein solches haben.

VG --PerfektesChaos 16:39, 29. Aug. 2020 (CEST)

Zu viele Features

Aufgabe einer derartigen Vorlage sollte es sein, bei einem Zellinhalt vom Typ Datum einen HTML5-kompatiblen Sortierschlüssel zu erzeugen. Dazu muss die Zelle mit dem Attribut data-sort-value="s<Sortierwert>" versehen werden. Beispiel:

| {{DatumZelle|5. Januar 2019}} erzeugt | data-sort-value="5 Jan. 2019"| 5. Jan. 2019 (generierter Quellcode in rot).

Soweit so gut. Darüber hinaus gibt es noch die Option, das dargestellte Datum zu verlinken. Auch das ist sinnvoll. Bedauerlicherweise wurden auch Parameter eingeführt, welche neben data-sort-value auch noch weitere Zellattribute einbauen. Das sind rowspan, colspan,class und, besonders bedenklich, das Style-Attribut. Alle Zellattribute außer data-sort-value gehören aber nicht in den von der Vorlage generierten Quellcode, sondern direkt in die Tabellenzelle, wo sie auch von weniger geübten Autoren besser zu handhaben sind. Wird der Parameter style mit einem Wert belegt, so werden außerhalb der Vorlage, also unmittelbar davor angegebene Stilangaben, ignoriert:

{|
| style="font-family:monospace" {{DatumZelle|2020-05-05|rowspan=2|style="font-size:40px;"}}
|}

bewirkt

5. Mai 2020

Das font-family-Attribut hat keine Wirkung. Während man das bei direkter Verwendung von DatumZelle noch sofort erkennen und korrigieren kann, indem man die Stilangaben entweder innerhalb oder außerhalb zusammenzieht, ist das bei Verwendung als Untervorlage schon schwieriger. Ähnliches gilt für rowspan und colspan.

Eine Klassenangabe wie class="hintergrundfarbe8" gehört, wenn sie die ganze Zelle betreffen soll, ebenfalls vor die Vorlageneinbindung, zumal sie dort besser kombiniert werden kann.

Grundsätzlich ist also die Codierung

| colspan="2" class="hintergrundfarbe8" style="font-size:50px;" {{DatumZelle|2020-05-05}}

mit dem Ergebnis:

| colspan="2" class="hintergrundfarbe8" style="font-size:50px;" data-sort-value="5 Mai 2020"| 5. Mai 2020

einer Angabe wie

| {{DatumZelle|2020-05-05|colspan="2"|class="hintergrundfarbe8"| style="font-size:50px;"}}

mit dem Ergebnis:

| class="hintergrundfarbe8" style="font-size:50px" data-sort-value="5 Mai 2020" colspan="2"| 5. Mai 2020

(Vorlagenrückgabe hier in rot) vorzuziehen.

Die Option, diese Attribute in die Vorlage zu verlagern, ist eine unnötige Fehlerquelle. Hier gilt der Grundsatz: Nur so viel Funktionalität wie nötig. Das bedeutet:

• Die Vorlage sollte als einziges Attribut ein data-sort-value erzeugen und sonst keines. Daher sollten die Parameter colspan, rowspan und class entfernt werden. Um das Style-Attribut beizubehalten, müsste es in ein dann zum Zellinhalt gehörendes Span-Tag verlagert werden, was aber mit dem Ziel der Vorlage, die Auswertung zu verbessern, kollidieren kann.
• Die Vorlage generiert beim Zellinhalt ausschließlich Code, welcher das Datum einschließt, also Fett- und Kursivschrift, Wikilink etc. Diese Regel wird zurzeit eingehalten.

Gruß von ÅñŧóñŜûŝî (Ð) 14:07, 30. Aug. 2020 (CEST)

Möglicherweise steigert sich Deine Empörung noch, wenn ich darauf hinweise, dass Dein obiges Beispiel nicht ganz den Konventionen entspricht. Vorlagenparameter werden üblicherweise nicht in Anführungszeichen eingeschlossen. Daher so:

| {{DatumZelle|2020-05-05|colspan=2|class=hintergrundfarbe8| style=font-size:50px}}

Grüße, --rolf_acker (Diskussion • Beiträge) 15:13, 30. Aug. 2020 (CEST)

@Antonsusi:

Du musst sie ja nicht verwenden.

Alle Vorlagen der modernen Zelle-Serie halten die gleichen Parameter bereit, um alle derzeitigen und zukünftigen Attribuierungen eines darzustellenden Datums-Textes zu unterstützen. Das geschieht konzeptionell für alle einschlägigen Vorlagen nach gleichem Schema, völlig egal ob es hier und jetzt eine Einbindung geben würde, die mal diesen mal jenen benutzt.

Die Vorlagenparameter machen die Attribute auch den Benutzern des VisualEditor zugänglich und dokumentieren sie. Damit werden diese auch von den „weniger geübten Autoren besser zu handhaben“, weil diese erstens heutzutage den VisualEditor benutzen und zweitens jeder Name umseitig auch eine dokumentierte Erklärung erhält. Nochmals: Es zwingt dich niemand, diese Attribute in den von dir erstellten Artikeln zu verwenden.

Deine Behauptung, da wären zu viele Features, ist schlicht falsch; erst kürlich wurden auf eine Anfrage hin Fett- und Kursivschrift noch als Boolesche Schalter nachgerüstet.

Diese Auswertung zeigt, dass bereits nach weniger als einem halben Jahr fast alle Parameter schon einmal irgendwo benötigt wurden.

Du bist schlicht und einfach neidisch, dass deine seit 2011 überholte behelfsmäßige „Workaround“ -Programmierung mit inkompatiblen privaten Sortierschlüsseln und inkompatiblen privaten Datumsformaten jetzt durch eine zukunftsweisende und für den VisualEditor geeignete global austauschfähige projektweite Technologie abgelöst wird, und du versuchst jetzt ums Verrecken mir krampfhaft irgendwie am Zeug zu flicken. Lass endlich diese Diskussionsseite in Ruhe und kümmere dich um was anderes; du hattest neun Jahre Zeit gehabt, die Behelfskonstruktionen von 2008 bis 2011 durch die 2010 global eingeführte saubere Lösung zu ersetzen. Das hattest du nicht gemacht, jetzt habe ich das umgesetzt, und nun stiehl mir nicht noch länger Zeit und Nerven. Mittlerweile hast du 28 kB für Beschwerden darüber verbraten, dass 2010 Vergangenheit ist.

--PerfektesChaos 16:42, 30. Aug. 2020 (CEST)

Ok, der Visual Editor mag ein Argument für diese Doppelung sein. Dass du alles, was rechts vom Pipe stehen soll und das die Ausgabe tagartig einschließt, also Fett- und Kursivschrift sowie Wikiverlinkung in die Vorlage hinein baust, sollte selbstverständlich sein. Ebenso die Parameter "pre" und "post", damit auch weitere Zeichen in die Zelle können. Das ist logisch und von mir auch oben bereits erwähnt.

Nein, ich bin nicht neidisch. Ich hatte nur keine Lust, das nochmal anzufassen. data-sort-value ist mir längst bekannt aber von dieser Verschiebung des Pipe in die Vorlage hatte ich Abstand genommen, weil das auch bei guter Umsetzung sehr schnell viel Gemotze generiert hätte. Ich glaube auch nicht, dass ich der Einzige bin, der da vorsichtshalber die Finger weggelassen hat. Du hast gegenüber anderen Usern den Vorteil, dass deine "Umbauten" viel eher akzeptiert werden. Jeder andere hätte sich da, egal wie gut er es umsetzt, die Finger verbrannt. Meine gelegentliche Kritik und mein Nachhaken sind da geradezu harmlos dagegen.

Weiteres Beispiel: Was glaubst du, weshalb der Geohack (Vorlage:Coordinate und ihre "Kinder") bis auf den heutigen Tag so ein grausliges, im Laufe der Zeit gewuchertes Vorlagen-Monster-Bündel ist, das man kaum durchschauen kann? Wer da herangeht, ohne sofort alle exotischen Features fehlerfrei umzusetzen, der kann sich auf einen gewaltigen Shitstorm einstellen. Ergo macht das (bisher) keiner, obwohl ein Modul hier sehr nützlich wäre. Gruß von ÅñŧóñŜûŝî (Ð) 20:33, 30. Aug. 2020 (CEST)

Sortierung kaputt?

Vgl. Diff: Zumindest bei mir wurde zuvor nummerisch nach dem Tag im Monat sortiert (3. August, 6. Oktober, 7. August, am Ende 31. Januar), mit type=i wird richtig sortiert. Mir ist die Vorlage zu hoch, glaub aber nicht, dass die standardmäßige Sortierung so funktionieren soll, wie sie es in meinem Beispiel tat. … «« Man77 »» Alle Angaben ohne Gewehr. 23:05, 20. Sep. 2020 (CEST)

Möglicherweise hab ich das grad ohne mich zu sehr damit auszukennen mit data-sort-type="isoDate" gefixt, falls nicht, bitte einfach zurücksetzen. Ich hab nur kopiert, was PerfektesChaos bei der meiner türkischen Erdbebenliste als data-sort-type voreingestellt hat und es scheint mir jetzt richtig zu sortieren. MfG --IllCom (Diskussion) 23:14, 20. Sep. 2020 (CEST)

Ich hab da zwischenzeitlich auch nochmal durchgewischt.

Das data-sort-type="isoDate" braucht es nicht; es sind normale taggenaue Datumsangaben.

Die könnte man auch ohne Vorlage direkt in die Zellen reinschreiben, dann darf da aber nichts anderes mehr stehen.

Wenn in den Zellen nichts anderes vorkommt als überall taggenaues Datum oder überall ISO-Datum, dann kann man auch ohne Vorlagen arbeiten.

Hier steht aber jeweils das Alter mit bei, und dann muss das anders gehandhabt werden.

Das Parameterformat, hier zufällig ISO, hat nichts mit dem Sortiermodus zu tun. Die Parameterangabe lässt sich in einem Dutzend eindeutiger Formate machen.

Irgendeine türkischen Erdbebenliste könnte Jahreszahlen vor 100 n. Chr. oder gar v. Cht. enthalten haben; dann ist das ein anderes Spiel und ISO wird zwingend.

VG --PerfektesChaos 23:23, 20. Sep. 2020 (CEST)

Eingabeformat

Der Parameter Datum/Zeit kann laut Beschreibung das Format beliebig haben. Bedeutet das, ich könnte das Datum im Quelltext auch als 7.10.2020 angeben statt 2020-10-07? Und wie sieht es mit führenden Nullen aus, müssen die bei einstelligen Monats- und Tagnummern unbedingt angegeben werden?--Stegosaurus (Diskussion) 17:40, 7. Okt. 2020 (CEST)

Siehe Benutzer:Perrak/Test1 (Permanentlink): Format ist egal, führende Nullen sind nicht erforderlich, außer beim Normformat, da verwschluckt er sich, wenn man sie weglässt. -- Perrak (Disk) 17:45, 7. Okt. 2020 (CEST)

Danke. Ich schlage vor, diese Beispiele in der Doku zu nennen oder zu verlinken.--Stegosaurus (Diskussion) 18:00, 7. Okt. 2020 (CEST)

Von mir aus darf das gerne jemand kopieren. Verlinken ist weniger gut, ich überschreibe die Datei immer mal wieder, gelegentlich nutze ich die Seite auch für Löschtests, sie ist also nicht immer für alle lesbar. -- Perrak (Disk) 18:02, 7. Okt. 2020 (CEST)

Richtig@Perrak.

Das „Normformat“ heißt Normformat, weil es kompatibel mit allen globalen Software-Werkzeugen sein soll, also auch für den Austausch mit anderen Wikis, für Bots, für Auswertungswerkzeuge; außerdem erlaubt es eine Sortierung des Quelltextes direkt mit externen Werkzeugen, vielleicht in einer Excel-Tabelle. Deshalb ist hier ISO 8601 einzuhalten.

Es ist jedoch nicht erwünscht, beliebig viele Formate anzugeben. Tatsächlich werden technisch noch viel viel mehr verstanden, nämlich praktisch alles von hier – die sollen aber nicht alle kunterbunt im Artikelquelltext auftauchen, sondern tatsächlich möglichst nur das Normalformat 7. Oktober 2020 oder aber 2020-10-07 und nicht noch mehr Durcheinander, sofern vermeidbar.

VG --PerfektesChaos 18:07, 7. Okt. 2020 (CEST)

Klar, innerhalb eines Quelltextes oder zumindest in einer Tabelle sollte man ein Format verwenden, nicht mehrere - alles andere macht den Quelltext nur unnötig schwer zu lesen. Mein Beispiel oben habe ich nur des Beispiels halber so geändert, im Original verwende ich Normdaten ;-) -- Perrak (Disk) 18:50, 7. Okt. 2020 (CEST)

April

Spricht abgesehen vom zusätzlichen Programmieraufwand etwas dagegen, den April im Standard-Datenformat auszuschreiben? Er ist in der Darstellung kürzer als der März, der ebenfalls ausgeschrieben wird. --PM3 18:55, 5. Jan. 2021 (CET)

Naja, der Programmieraufwand wäre zu verschmerzen.

Aber es wird irgendwann schwer zu erklären, was wann wie gehandhabt wird.

Die vorgenommene Regel lautet: „nicht mehr als vier Zeichen“.

• März
• Juni
• Juli

Heißt: statt als viertes Zeichen einen Punkt zu machen, wird der letzte Buchstabe geschrieben.

• März
• April
• Juni
• Juli
• Mär.
• Jun.
• Jul.

So ganz ohne und bei nicht-proportionalen und serifen-Schriften ist das nicht; könnte auch zu Darstellungseffekten führen.

VG --PerfektesChaos 19:32, 5. Jan. 2021 (CET)

Habe noch keine einzige Tabelle gesehen, in der das Datum in Monospace-Font dargestellt würde. Ergäbe ohnehin kein sauberes Ergebnis, wenn man den Mai hinzufügt:

• Feb.
• März
• Apr.
• Mai
• Juni
• Juli
• Aug.

Der Sinn der Abkürzungen kann nur (a) Platzersparnis und eine (b) möglichst tabellarische Darstellung innerhalb der Datumsspalte sein. Unter diesen Voraussetzungen erreicht man m.E. durch Ausschreiben von "April" eine etwas bessere Lesbarkeit, ohne dass es zu Nachteilten führt. Egal ob mit oder ohne Serifen.

• Jan.
• Feb.
• März
• April
• Mai
• Juni
• Juli
• Aug.
• Sep.
• Okt.
• Nov.
• Dez.

Ein weiterer Charme dieser Lösung ist, dass jeweils ein Block aus sechs aufeinanderfolgenden Monaten abgekürzt wird und ein ebensolcher Block nicht; das macht manche Datumslisten etwas weniger flatterhaft (ist aber nicht entscheidend ...).

Ich vermeide wegen dieser Problematik bislang die Vorlage DatumZelle und bevorzuge Handformatierung. --PM3 21:48, 5. Jan. 2021 (CET)

Codierung von Zeiträumen; Schlüsselwörterproblem

Hallo, nach Reparatur des Artikels Hofastronom bleiben zur VL div. Fragen:

1. in der dortigen Tabelle werden in zwei Spalten Zeiträume (von – bis) erfasst. Aufgrund historischer Unsicherheiten wurde von Vorbearbeitern versucht, eine Anfangszeit bspw. mit {{DatumZelle|zwischen 1418 und 1450}} anzugeben, was natürlich nicht ging. Wie wären solche Zeitspannen zu codieren? Hilfsweise wurde {{DatumZelle|zwischen 1740}} und 1747 geschrieben.
2. die Eingabe der Schlüsselwörter „frühestens“ und „spätestens“ erzeugt Fehlermeldungen, weshalb auf die Angabe „nach“ und „vor“ (jeweils mit Differenz von ±1 Jahr) ausgewichen werden musste, hier statt „spätestens 840“ nun „vor 841“.

Dank für Hilfe sagt --Wi-luc-ky (Diskussion) 13:06, 16. Mai 2021 (CEST)

PS:

1. In der Doku steht zum Parameter Format: Standard: T._Mon4 JJJJ.
   Was ist mit der 4 gemeint? Vierstellige Ausgabe? Ob diese Vermischung von Monatsbuchstaben und Zahl verständlich ist?
2. In #Beispiele wird der Mai zur Demonstration der Aufhebung der 4-Zeichen-Ausgabe mit |kurz=0 verwendet. Ist das ein geeignetes Beispiel?
3. Der Jänner könnte bei AT vllt. auch noch explizit in Klammern erwähnt werden.

Gruß, --Wi-luc-ky (Diskussion) 19:09, 17. Mai 2021 (CEST)

1. Zeitspannen: Es muss nach Belieben eine Jahreszahl (ein Zeitpunkt) herausgegriffen werden, vielleicht ca. in der Mitte, vielleicht ein Jahr nach Spannenbeginn, vielleicht ein Jahr vor Spannenende. Je nachdem wie wahrscheinlich so ein Zeitpunkt wäre entsprechend rangerutscht.
   • Beispiel: „18. Jh.“ → 1750
   • Dann Anzeige in Format 2= mit - unterdrücken, und beliebigen Text dahinter schreiben.
2. „frühestens“ und „spätestens“ – seltsam, muss ich erproben, kann dauern, aber eigentlich sind diese Schlüsselwörter alle irgendwie ähnlich. Wobei ich zu „frühestens“ ein mögliches Problem identifiziert habe, weil es mit „f“ anfängt, aber dann müsste „spätestens“ gehen.
   • Methode zu #1 würde auch hier gehen.

PS

1. „Was ist mit der 4 gemeint?“
   • rechts oben: „Monatsname bis 4 Buchstaben nicht abkürzen“
2. „wird der Mai zur Demonstration“
   • Warte zwei Wochen, dann ist es der Juni. Warte drei Monate, dann ist es Aug..
   • Demonstriert werden soll da nix; zumindest nicht wie man einen langen Monatsnamen nicht abkürzen würde. Das kann man sich oben bei „Monatsnamen auf maximal vier Zeichen kürzen“ selbst denken. Vielmehr ginge es um die Quelltext-Notation, wie man |kurz=0 schreibt. Und was da an Syntax bei rauskäme, nämlich data-sort-value=".
3. „Jänner“ ist eigentlich relativ bekannt, und die Ösis wissen es sowieso, aber von mir aus.

VG --PerfektesChaos 21:07, 17. Mai 2021 (CEST)

Ich klink mich hier einmal ein, da ich das gleiche Problem habe. Die Schlüsselwörter 'frühestens' und 'nach dem' werden leider nicht erkannt. Da ich beide mehr oder weniger synonym verwenden könnte, fällt diese Möglichkeit praktisch ganz weg (nach 1.1.1900 geht zwar, liest sich bei tagesgenauen Angaben aber unschöner als mit Artikel). -- Platte ^{∪∩∨∃∪} 20:29, 15. Sep. 2022 (CEST)

Link

Ich habe in der Doku ein Beispiel für die Angabe v.Chr. ergänz und wollte eigentlich auch den Parameter |link=1 darstellen. Dabei ist mir aufgefallen, dass

{{DatumZelle|0044-03-15 v.Chr.|link=1|type=i}}

data-sort-value="-0044-03-15T00:53:28+00:53"| 15. Mär. 44
nicht das gewünschte bzw. über die Parameter beschriebene Ergebnis erzeugt. Das Jahr 44 v. Chr. ist dabei als Artikel vorhanden. Ich muss zugeben, dass es bei weiter absteigenden Jahreszahlen mit Artikeln schwieriger werden wird, allerdings sollte die Vorlage (bzw. wohl eher das Modul?) damit umgehen können und keine fehlerhaften Angaben erzeugen. --darkking3 ^Թ 22:45, 24. Jun. 2022 (CEST)

Nö, da hört der Service dann auf.

Wer sowas verlinken möchte, der mag sich selbst drum bemühen.

Erstmal ist diese ganze Verlinkerei für die Neuzeit gedacht.

• Es gab eine Kalenderrreform im Jahr 1582; tagesgenaue Daten vor 1582 sind ohnehin dubios weil sie damals niemand kennen konnte.
• Mit „44 v. Chr.“ bist du zwar wenigstens knapp bei Julianischer Kalender per „45 v. Chr.“ gelandet, weil vorher wäre der „September“ auch der siebte Monat gewesen, aber das ist alles Kappes.

Das Modul ist global und sprach- wie projektunabhängig; wie in der deWP und auf deutsch und in einem deutschen Wiki irgendwelche Jahresartikel heißen mögen ist ihm egal. v. Chr. ist out of scope und nicht sinnvoll konfigurierbar.

Es gibt auch kaum reale Anwendungsfälle für das Problem, wo dann aus sortierbarer Tabelle heraus jetzt ganz ganz wichtig wäre mit irgendwas zu verlinken. Wo doch mag man sich selbst helfen.

VG --PerfektesChaos 23:18, 24. Jun. 2022 (CEST)

Hallo PerfektesChaos, die ganzen Hinweise mögen ja alle richtig sein. Nur warum erlaubt das Modul dann überhaupt die Verlinkung von Angaben und erzeugt dabei einen Fehler? Macht man dies automatisiert, fällt das dann auch leider nicht sofort auf. Ein Nicht-Verlinken erscheint mir dann sinnvoller als eine fehlerhafte Ausgabe, da die Anzeige dann richtig ist und der Sortierwert weiterhin passt. Davon abgesehen gebe ich dir recht, dass genaue Datumsangaben bei niedrigen Jahreszahlen mehr Schätzung als genaue Wissenschaft ist. Ich will mir gar nicht ausmalen, wenn noch einer auf die Idee kommt, noch Wochentage haben zu wollen. Allerdings sind die Iden des März eine exaktere Angabe als manch andere. --darkking3 ^Թ 17:38, 27. Jun. 2022 (CEST)

Sowas ist grundsätzlich die Verantwortung der Autoren, die Vorlagen anwenden.

Die Modul-Programmierung macht das, was man ihr sagt, und zwar in allen Projekten des Planeten von Maya-Kalender bis sonstwie, und wenn Autoren von Vorlagen Unsinn verlangen kann es sein dass sie in manchen Sprachen und Kalendern dann Murks erhalten, während der jüdische Kalender in der angegebenen Situation kein Problem hätte. Sofern man nicht vor Sintflut oder gar Genesis 1,1,1 gerät.

Wer „Verlinken“ ankreuzt, bekommt halt das was technisch dafür vorgesehen ist. Inhaltliche Betrachtungen, ob die Autoren intelligent sind, fallen nicht in den Aufgabenbereich von Modulen.

VG --PerfektesChaos 21:37, 27. Jun. 2022 (CEST)

Das ist ja genau der Punkt, dass das Modul eben nicht das macht, was man ihm vorgibt. Der Fehler muss einem Autoren in der Ausgabe auch dabei nicht zwingend auffallen, da die Eingabe ja korrekt ist. Ob sinnvoll oder nicht: das Modul sollte sich neutral verhalten und Vorgaben umsetzen, alternativ einen zu prüfenden Fehler liefern. Mir ist es am Ende egal, wie das Ergebnis aussieht, nur sollte die Darstellung passen. Code wie data-sort-value="-0044-03-15T00:53:28+00:53"| 15. Mär. 44 v. Chr. oder data-sort-value="15.3.0044"| 15. Mär. 44 v. Chr. ist aus meiner Sicht auch nur ein "Hack", den du eigentlich vermeiden willst und der durch einen Fehler im Modul notwendig ist. Mit

{{DatumZelle|0044-03-15 BC|link=1|type=i}}

data-sort-value="-0044-03-15T00:53:28+00:53"| 15. Mär. 44
verstehe ich zwar das Sprachproblem, aber dann wäre es nur konsequent, das Jahr oder vollständig nicht zu verlinken. --darkking3 ^Թ 11:23, 28. Jun. 2022 (CEST)

Es gibt genau einen Artikel, in dem dieses Angebot dann 8× genutzt wird, und das ist Temperaturextrema, und in dem liegen alle Jahreszahlen nach 2000.

Es gibt ansonsten sehr wenig Veranlassung, innerhalb von Tabellen Jahreszahlen zu verlinken. Und wenn, dann das Datum einer neuzeitlichen Erfindung oder sowas. An antiken Daten in Tabellen als Backlink besteht offenkundig kein Bedarf.

Mittlerweile habe ich in die Vorlagenprogrammierung geguckt. Anders als von dir oben suggeriert kommt das auch überhaupt nicht im global einsetzbaren Modul vor, sondern ist allein Angelegenheit der lokalen Vorlagenprogrammierung.

Du kannst dich also jetzt selbst auf den Hosenboden setzen und die von dir als ach so dringlich eingestufte Programmierung selbst vornehmen; natürlich schön übersichtlich und verständlich und effizient.

Ich habe jetzt genug Zeit und Nerven mit dieser absolut unwichtigen und überflüssigen Petitesse vergeudet, die vielen anderen dringlicheren Angelegenheiten verlorenging.

VG --PerfektesChaos 23:47, 5. Jul. 2022 (CEST)

Mir geht es hier nicht um einen speziellen Artikel, sondern darum, dass die Vorlage respektive das Modul nicht das macht, was man ihm vorgibt. Ob daran Bedarf besteht oder nicht, muss dabei auch nicht erörtert werden. Vorstellbar wäre soetwas wie
{{#switch: {{#invoke:Str|find|{{lc:{{{1|}}}}}|chr}} | -1 =[[Y]]| #default= [[Y \v. \C\h\r.]] }}
statt [[Y]]
Da es mir zu heiß ist, die Vorlage "mal eben" zu ändern (bei über 400k Einbindungen in mehr als 8,5k Artikeln), bitte mal auf den Code schauen, so wirklich zufrieden bin ich damit nicht. --darkking3 ^Թ 14:47, 14. Jul. 2022 (CEST)

Diese Doku sagt explizit, dass eine solche Verlinkung eines (eigentlich) Tagesdatums erst ab 1582 zulässig ist.

Es gibt keinen Bedarf, in Tabellen viele Jahreszahlen zu verlinken; grad mal einen armseligen Artikel. Wozu auch?

Erst recht keine dubiosen Daten aus der Jungsteinzeit oder Antike.

Wir haben Hunderte offener Baustellen, und einen riesigen Berg aufzuarbeiten an Defiziten aus den Nuller Jahren. Das liegenzulassen zugunsten eines Features, das niemand braucht, wäre schlicht dumm.

Der vergangene Tag brachte Temperaturen von 40 Grad, und der kommende wird auch nicht denkfördernder.

Diese sinnfreie Diskussion hat mittlerweile unverantwortlich viele nicht vorhandene Ressourcen verbrannt.

Es ist über schlichte Vorlagenprogrammierung realisiert, es mag jeder auch ohne Lua das auf vorchristliche Jahrgänge erweitern. Vieeeel Spaß dabei.

VG --PerfektesChaos 02:57, 20. Jul. 2022 (CEST)