Zum Inhalt springen

Gespräch:Datumsortierung Modul AufEinWortSeiteKennung

aus AufEinWort, der freien Forschung

Über diese Seite Gespräch

Modul umgestalten Überblick
Entwurf
ChatGPT Sophos GPT-5 Thinking
16. September 2025 n. Chr. erst.  
10:04 Uhr Ausgabe 01
Ausgabe 01
unüberarbeitet ungeprüft
↓ Kategorien Hierarchiestruktur gegen Sternstruktur
2025091601 Datumsortierung Modul AufEinWortSeiteKennung

Chat-Thema: Datumsortierung

Hallo Sophos;

Ich möchte nun mit dir ein Modul:AufEinWortSeiteKennung umgestalten.

1. Lege bitte dazu als erstes den bisherigen Inhalt von Modul:AufEinWortSeiteKennung.rtf als Canvas an.

2. was das Modul tut:

2.1 das Modul berechnet aus einem Datum plus einer Kennung ED, BD, UD einen Schlüssel, der demgemäß Kategorien in die jeweilige Wikiseite setzt.

2.2 Ich lege dann die Kategorien an, die als Seitennamen nicht das Datum, sondern die Kennung haben.

2.3 Mittels Vorlage:AufEinWort KategorieDatum stelle ich dann DISPLAYTITLE:{{#invoke:AufEinWortSeiteKennung… das lesbare Datum wieder her. 3. Verschaffe dir einen Überblick wie das Modul macht. Ich erkläre dir danach das neue Vorhaben.

Hallo Nikolaos – erledigt.

Nachgedacht
Dokumente werden gelesen

Ich muss zuerst die lokale Zeit in Berlin abfragen, um mit dem richtigen Timestamp zu begrüßen. Die Zeitzone ist als "Europe/Berlin" festgelegt, aber ich werde sicherheitshalber die Zeit abfragen. Dann erstelle ich das Canvas mit dem Lua-Modulcode aus der Datei und achte darauf, keine Zitate einzubeziehen, nur den Code.

Fertig

Modul:AufEinWortSeiteKennung 1

Ich habe den bisherigen Inhalt als Canvas angelegt: „Modul:AufEinWortSeiteKennung – bisheriger Inhalt“.

Kurzüberblick (Fakten):

  1. Zweck & Schlüssel
  • erzeugt eine kompakte, chronologisch sortierbare Kennung YIDXMMDDNN
    • YIDX = 5000 ± Jahr (v. Chr. → 5000–J; n. Chr. → 5000+J), gültig für Jahre 1–4999
    • MM/DD: zweistellig oder „00“ wenn unbekannt
    • NN: zweistellige laufende Nummer
  • Kennung dient zum automatischen Setzen von Kategorien für ED/BD/UD.
  1. Eingabe → Parsing
  • erkennt Ära (n./v. Chr.) via „-…“, „v chr“, „vor christus“, „bce“, „bc“.
  • toleriert mehrere Datumsformate: dd.mm.yyyy, yyyy-mm-dd, „Tag Monat Jahr“, „Monat Jahr“, „Jahr“.
  • Monatsnamen inkl. „März/Maerz“ → Zahl.
  • fehlende Teile werden als „00“ kodiert.
  1. Ausgabe der Kennung & Warnungen
  • makeKennung(datum, nummer) liefert "YIDXMMDDNN" sowie optional warn.badMonth.
  • bei ungültigem Format/Jahr: Fehlertext.
  1. Kategorien-Logik
  • Standard CATEGORY_STYLE = "postfix" → 7020112000 ED (optional „prefix“ oder „both“).
  • optional LEGACY_NUMERIC für reine Zahl-Kategorie.
  • zusätzlich: automatische Jahrhundert-Kategorie auf Werkseiten (n./v. Chr., kurz/lang konfigurierbar).
  • für Kategorieseiten: katMeta ordnet Granularität (Tag/Monat/Jahr) passenden Meta-Kategorien zu; katJahrhundert analog für Jahrhunderte (optional ED/BD/UD-spezifisch via split=1).
  1. Öffentliche API (wesentlich)
  • anzeige(...): lesbares Datum für Listen/DISPLAYTITLE (ED→BD→UD→Datum Priorität).
  • kennungE/B/U(...): reine Kennungen pro ED/BD/UD.
  • catErstellung/Bearbeitung/Urwerk(...): versteckte Kategorien gem. Stil + Jahrhundertkat.
  • decodeKennung(...): Kennung → lesbares Datum (für Kategorieseiten).
  • decodeKennungMitSuffix(...): wie oben, ergänzt „erst./bear./hrsg.“ vor/nach dem Datum.

Auffälligkeiten/Wissenswert (keine Wertung):

  • Jahresbereich hart auf 1–4999 begrenzt; >4999 n. Chr. liefert Fehlermeldung.
  • BCE-Erkennung ist robust, aber abhängig von konkreten Strings („v chr“ ohne Punkt/Komma).
  • „monat_name“ ≠ nil mit unbekanntem Monat triggert badMonth und setzt Fehler-Kategorie.
  • Bei fehlendem Datum wird „00000000NN“ erzeugt – dadurch immer eine formale Kennung vorhanden.

Wenn du mir das neue Vorhaben schilderst, steige ich direkt in die Umgestaltung ein.

Name auf "„Modul:AufEinWortSeiteKennung" korrigiert

Danke.

Ich habe den Canvas Name auf "„Modul:AufEinWortSeiteKennung" korrigiert und den Inhalt nochmals mit dem Original-Coding ersetzt, um  Übertragungsfehler auszuschließen.

Du hast die Funktion von Modul soweit richtig erkannt.

Erst in der Arbeit damit ist mir bewußt geworden, daß ich bei Suche nach einem bestimmten Datum im Suchfeld keine Ergebnisse angezeigt bekomme.

Vergleichsweise hat "Kategorie:7025031200 ED" durch DISPLAYTITLE den angezeigten Seitenname "12. März 2025 n. Chr. erst."

Ich müßte jetzt für jedes Datum und deren ED,BD,UD Kennung eine Weiterleitung einrichten, damit die gewünschte Kategorie erscheint, so bringt es auch nichts Kategorie:12. März 2025 n. Chr. erst.

Ich meine nun der Ansatz mittels der Kennung den Seitennamen zu erzeugen und dann DISPLATITLE für dessen Lesbarkeit zu verwenden war falsch, man hätte die Kennung für "SORTIERUNG:7025031200 ED" und den Seitennamen als "12. März 2025 n. Chr. erst." setzen sollen.

Wie siehst du das?

Was schlägst du vor?

Achtung!: Wir erörtern erst nur – daher kein Coding, keine Änderung im Canvas.

DISPLAYTITLE ändert nur die Anzeige – nicht den Seitennamen

Nachgedacht
Nikolaos schlägt vor, numerische Schlüssel als Seitentitel zu verwenden und den DISPLAYTITLE für die Lesbarkeit anzupassen, was die Suche verletzen könnte. Da der tatsächliche Seitentitel numerisch ist, schlägt er vor, den menschlich-lesbaren Titel als Seitentitel zu verwenden und den Schlüssel als Sortierschlüssel zu nutzen. Kategorien namenzu erstellen ist eine weitere Idee.

Standardmäßig indexiert CirrusSearch Wikitext, Titel, Weiterleitungen und Kategorien, aber DISPLAYTITLE wird nicht als Titel oder Inhalt indexiert. Deshalb könnte eine Suche nach „12. März 2025 n. Chr. erst.“ wegen der Zeichensetzung fehlschlagen. Redirects könnten dies lösen, aber das ist für jedes Datum aufwendig. Eine bessere Lösung könnte sein, den leserfreundlichen Titel als Kategoriename und den numerischen Schlüssel zur Sortierung zu verwenden.

Die Sortierung wird normalerweise für Mitglieder innerhalb einer Kategorie verwendet, nicht für Kategorien untereinander. Der Wunsch ist jedoch, Kategorien nach Datum zu finden und eine chronologische Sortierung zu behalten. Man könnte {{DEFAULTSORT:sortkey}} verwenden, um die Sortierung der Unterkategorien zu steuern. Eine Möglichkeit ist, menschlich-lesbare Titel für Kategorien zu erstellen und diese zur Sortierung zu nutzen.

Es könnte sinnvoll sein, die bestehende Kategorietitel zu ändern und den numerischen Code als Sortierschlüssel zu verwenden. Eine Möglichkeit ist, ein Redirect-Extension zu nutzen, um Kategorien umzubenennen, ohne sie neu zu erstellen. Eine größere Herausforderung könnte die Einführung von Lesetitel für die effektive Suche durch MediaWiki sein.

Eine Möglichkeit wäre, die numerischen Kategorien zu behalten und synonyme, lesbare Texte auf den Kategorieseiten hinzuzufügen, um die Auffindbarkeit durch die Suche zu verbessern. Wir könnten auch den "DEFAULTSORT"-Schlüssel nutzen, aber ohne die Notwendigkeit, ständig Umleitungen zu erstellen. Dies scheint eine einfache Lösung zu sein, ohne dass es viele Umbenennungen oder manuelle Schritte erfordert.

Fertig

Kurz: Dein Befund ist richtig. DISPLAYTITLE ändert nur die Anzeige – nicht den Seitennamen und i. d. R. auch nicht das, worauf die Suche primär zielt. Deshalb findest du „12. März 2025 n. Chr. erst.“ nicht, wenn die Kategorie tatsächlich „7025031200 ED“ heißt.

Was folgt daraus?

Fakt (MediaWiki/CirrusSearch):

  • Titel-Suche greift auf den echten Seitennamen zu; DISPLAYTITLE wird nicht wie ein Alternativ-Titel behandelt.
  • Inhalte „im Unsichtbaren“ (z. B. display:none) oder nur implizit erzeugte Strings werden für Trefferqualität nicht zuverlässig herangezogen.

Empfehlung (sauberer Ansatz)

Drehen:

  • Kategorie-Seitennamen = lesbares Datum + Kennungswort z. B. Kategorie:12. März 2025 n. Chr. erst.
  • Sortierung (chronologisch, BCE→CE, Tag/Monat/Jahr-Lücken) über deinen 10-stelligen Schlüssel YIDXMMDDNN als Sortierschlüssel in den übergeordneten Kategorien (per [[Kategorie:…|7025031200]] bzw. {{DEFAULTSORT:7025031200}} auf der Kategorieseite).

Vorteile:

  • Suchen „wie man spricht“ funktioniert (Titel-Treffer, Autovervollständigung).
  • Chronologie bleibt exakt, weil der Sortkey lexikographisch korrekt ordnet (null-gepaded).
  • Deine ED/BD/UD-Semantik bleibt sichtbar (Teil des Titels), statt in die reine Zahl „hineingeschoben“ zu sein.

Mögliche Nebenpunkte (klar trennbar):

  • Kollisionen: Gleicher Tag mit ED/BD/UD → drei Kategorien mit unterschiedlichem Suffix im Titel; gleicher Sortkey → stabile Zweitsortierung per Titel (ok).
  • Zeichen im Titel: Punkt in „erst.“ ist legal, aber bei manueller Verlinkung manchmal tückisch. Wenn du magst, könntest du alternativ „erst“/„bear“/„hrsg“ ohne Punkt nehmen – reine Stilfrage.

Alternativen (falls du nicht umstellen willst)

A. Minimalinvasiv, sofort wirksam:

Lass die numerischen Titel bestehen, füge aber auf jeder Kategorieseite sichtbaren Text (nicht nur DISPLAYTITLE) mit allen gängigen Datumsvarianten ein („12. März 2025“, „2025-03-12“, „12.03.2025“, „März 2025“, „v. Chr./n. Chr.“).

→ Suche findet die Seiten über den Seiteninhalt.

Nachteil: Treffer sind Inhaltstreffer, nicht Titeltreffer; UX bleibt suboptimal.

B. Doppelt mit Redirects:

Erzeuge lesbare Weiterleitungen von Kategorie:12. März 2025 n. Chr. erst. → Kategorie:7025031200 ED.

Mit der CategoryRedirect-Extension würden Kategorisierungen durch Redirects sauber aufgelöst.

Nachteil: Viele zusätzliche Seiten oder Abhängigkeit von einer Extension; ohne Extension landen Einträge in der Redirect-Kategorie.

Mein Vorschlag (praktikabel + klar):

Gehe zu lesbaren Kategorie-Titeln (dein neuer Ansatz) und nutze den Schlüssel nur als Sortierlogik. Das ist semantisch sauber (Menschen lesen Titel, Maschinen sortieren mit Schlüssel) und passt zu deinem Ziel „datenlogisch robust + menschenfreundlich“.

Wenn du magst, skizziere ich als Nächstes den Migrationsplan ohne Code (Reihenfolge der Moves/ReplaceText, Umgang mit bestehenden Links, optionaler Einsatz von CategoryRedirect vs. direkter Umstellung) – und danach passen wir das Modul an.

Danke für deine Auswertung und Vorschläge.

1. zu "Kollisionen:" Gleicher Tag mit ED/BD/UD → drei Kategorien mit unterschiedlichem Suffix im Titel; gleicher Sortkey → stabile Zweitsortierung per Titel (ok).

kein gleicher Sortkey sondern die Kennung mit der Endung wie gehabt.

Sie erhalten übergeordnet eine abgestufte Kategorie Monat-Jahr, darüber Jahr, durch die diese zusammen und gemäß Kennung sortiert angezeigt werden

2. zu "A. Minimalinvasiv"

Sehe ich keinen echten Nutzen darin, dies so zu tun.

Die Kennung muß weiterhin erzeugt werden, wird nur anders genutzt.

Wenn der Seitenname nun ein Datum zeigt, muß Vorlage:AufEinWort DatumSortierung den Schlüssel per #invoke errechnen und setzen.

Alle bisherigen Seiten muß ich zum Dateum hin verschieben.

Auf der jeweiligen Wikiseite habe ich bereits das Datum, die Kennung wird dort dennoch weiterhin für mich zur Prüfung benötigt, jedoch erzeugen wir da dann die richtige Datum-Kategorie mit Kennung in der Vorlage aus dem dann errechneten Sortierschlüssel.

zu "B. Doppelt mit Redirects:"

zu hoher aufwand und verdopplung der Datensätze ohne gewinn einer Lesbarkeit und eindeutige Erkennbarkeit.

Als nächstes würde ich aus Modul:AufEinWortSeiteKennung Modul-AufEinWortDatumKennung erzeugen, also das bisherige Modul so belassen, wer weiß wozu, zumindest solange bis das neue Modul funktioniert.

Ann würde ich dieses noch gern um GD für Geburtsdatum und SD für Sterbedatum ergänzen.

Sind meine Argumente zielführend zu einer einfachen nachhaltigen Lösung der Aufgabenstellung?  

Hast du einen besseren Ansatz?

Weiter berechnen, aber nur als Sortierschlüssel nutzen

Nachgedacht
Ich muss einen Plan erstellen, der sich auf die Bewertung von Argumenten konzentriert, um einen neuen Modulansatz vorzuschlagen. Ich werde die Grundzüge der Migration und mögliche Stolpersteine ansprechen – aber ohne Code. Es ist wichtig, den Unterschied zwischen DEFAULTSORT und Sortkey zu berücksichtigen, besonders auf Kategorieseiten. Zudem werde ich einen Vorschlag für die Normierung von Titeln und den Titelstil machen.

Ich bewerte, dass die Verwendung von Punkten im Titel problematisch sein kann, aber der Nutzer scheint damit einverstanden. Ich will sicherstellen, dass der Sortkey bei der Generierung konsistent bleibt, besonders bei Geburts- und Sterbedaten, bei denen viele Personen dasselbe Datum teilen. Eventuell könnte ich eine bessere Methode für die Suche durch Seiteneigenschaften prüfen.

Ich werde sicherstellen, dass die Hierarchie für die Kategorien GD/SD konsistent ist und bei Kollisionen am gleichen Tag eine Lösung gefunden wird. Der Plan umfasst die Festlegung eines standardisierten Kategorienamens, die Nutzung von Token und die Berücksichtigung der Monat- und Jahr-Lokalisierung. Änderungen am Template wie die Berechnung des DEFAULTSORT müssen ebenfalls berücksichtigt werden.

Fertig

Kurz vorweg: Deine Argumentation ist stimmig und führt zu einer einfachen, nachhaltigen Lösung. Den Schlüssel weiter berechnen, aber nur als Sortierschlüssel nutzen, während der Seitentitel lesbar ist – das ist die saubere Trennung „Mensch liest / Maschine sortiert“.

Hier mein kondensiertes „Go/No-Go“-Review + Vorschlag:

Bewertung deiner Punkte

  1. Kein gleicher Sortkey Verstanden: Der Sortierschlüssel bleibt die volle Kennung inkl. Endung (z. B. 7025031200 ED), während die übergeordneten Kategorien (Monat–Jahr → Jahr → ggf. Jahrhundert) die Aufhängung liefern. Das ist konsistent und stabil.
  2. „A. Minimalinvasiv“ verworfen Einverstanden – keine echte Verbesserung der UX bei der Suche. Richtig, weiter mit Titel-Umstellung.
  3. Kennung weiterhin erzeugen Ja:
  • für Sortierung (DEFAULTSORT bzw. [[Kategorie:…|Sortkey]]),
  • für Prüf-/Diagnosezwecke auf der Werkseite (sichtbar/prüfbar),
  • für Fehlersignale (z. B. unbekannter Monat).
  1. Vorlage:AufEinWort DatumSortierung Richtig: Die Vorlage soll per #invoke den Sortkey (Kennung) berechnen und setzen (als DEFAULTSORT: auf der Kategorieseite bzw. als Pipetext beim Einordnen von Werkseiten in die Tages-/Monats-/Jahres-Kategorien).
  2. Massen-Move auf lesbare Datums-Titel Ja, notwendig und sinnvoll. Redirects nicht beibehalten (siehe unten).
  3. Kennung auf Werkseite weiterhin prüfen Ja, unverändert – nur die Kategorie-Einträge entstehen künftig mit lesbarem Zieltitel und dem berechneten Sortkey.
  4. Redirect-Variante verwerfen Einverstanden: zu hoher Overhead ohne Mehrwert.
  5. Neues Modul Modul:AufEinWortDatumKennung als Parallelmodul ist pragmatisch. ED/BD/UD beibehalten, GD (Geburtsdatum) und SD (Sterbedatum) ergänzen → fünf Token insgesamt.

Design-Entscheidungen (präzise, damit wir später 1:1 coden können)

  • Kanontitel der Kategorieseiten:
    • Tag bekannt: 12. März 2025 n. Chr. erst.
    • Nur Monat/Jahr: März 2025 n. Chr. erst.
    • Nur Jahr: 2025 n. Chr. erst.
    • v. Chr.: analog mit „v. Chr.“
    • Suffixe: erst. / bear. / hrsg. (und neu geb. / gest.).
    • (Wenn du Punkte vermeiden willst, sag Bescheid; ich plane aktuell mit Punkt, weil konsistent zu deinen Beispielen.)
  • Sortierschlüssel: weiterhin YIDXMMDDNN + „ “ + TOKEN (z. B. 7025031200 ED).
    • Für gleiches Datum mit mehreren Einträgen differenziert NN.
    • Für Monat-/Jahr-/Jahr-Ebene greift die gleiche Kennung mit DD=00 bzw. MM=00.
  • DEFAULTSORT auf Kategorieseiten setzen (wirken in den übergeordneten Kategorien).
    • Auf Werkseiten beim Einordnen in die Tages-/Monats-/Jahres-Kategorie Pipetext verwenden: [[Kategorie:12. März 2025 n. Chr. erst.|7025031200 ED]].
  • Hierarchie:
    • Kategorie:12. März 2025 n. Chr. erst. ∈ Kategorie:März 2025 n. Chr. erst.
    • Kategorie:März 2025 n. Chr. erst. ∈ Kategorie:2025 n. Chr. erst.
    • (Optional) Kategorie:2025 n. Chr. erst. ∈ Kategorie:21. Jh. n. Chr.
    • Gleiches Schema für BD/UD/GD/SD (separate Bäume, oder zusammen, je nach deiner bisherigen Meta-Struktur – du hast diese bereits als Meta-Kats vorgesehen, das passt.)

Migrationsplan (ohne Code, nur Ablauf)

  1. Freeze & Inventur
    • Liste aller numerischen Datumskategorien mit Token (ED/BD/UD) + verwendeter Granularität (Tag/Monat/Jahr).
    • Prüfen, ob Sonderfälle (unbekannter Monat/Tag) korrekt abbildbar sind (Titel ohne Tag/Monat).
  2. Neues Modul bereitstellen (parallel)
    • Modul:AufEinWortDatumKennung (berechnet Kennung und liefert: lesbarer Titelstring, Sortkey, Meta-Infos).
    • Bestehendes Modul nicht anfassen.
  3. Vorlagen anpassen (parallel)
    • Vorlage:AufEinWort DatumSortierung nutzt das neue Modul:
      • auf Kategorieseiten → {{DEFAULTSORT:…}} + Einordnung in Eltern (Monat/Jahr/Jh.).
      • auf Werkseiten → Erzeugung der richtigen Kategorie-Links mit lesbarem Titel und Pipetext = Sortkey.
  4. Pilot-Moves (kleine Stichprobe)
    • 20–50 Kategorien (verschiedene Granularitäten + v. Chr./n. Chr.) numerisch → lesbar ohne Redirectverschieben.
    • Backlinks (Kategorisierungen in Werkseiten) vorerst unangetastet lassen → so sehen wir rote Links bzw. fehlende Einordnungen und können die Automatik verifizieren.
  5. ReplaceText / Skript-Rollout
    • Systematische Ersetzung von [[Kategorie:####… ED]] → [[Kategorie:… erst.|####… ED]] (analog BD/UD).
    • Monat-/Jahr-Kategorien analog anpassen, falls sie bislang numerisch sind.
    • Keine Redirects stehen lassen → klarer Zustand, keine Doppelindizierung.
    • Nach Chargen jeweils: rebuildrecentchanges, Links-Tabellen/Namensraum-Cache aktualisieren, Cirrus/Reindex-Jobs durchlaufen lassen (du hast die Job-Pipeline im Griff).
  6. SMW/Cirrus-Index beobachten
    • Stresstests: Suche nach „12. März 2025“, „März 2025“, „2025 n. Chr. erst.“ → Titeltreffer sollten sitzen.
    • Stichprobe v. Chr. sicherstellen.
  7. GD/SD einführen
    • Identisches Muster (eigene Token GD/SD), eigene Meta-Kategorien (z. B. „Geburtsdatum“-/„Sterbedatum“-Stränge) oder Integration in bestehende Meta-Bäume – je nach gewünschter Trennung.

Risiken / Feinkanten (gleich adressierbar)

  • Punkte im Suffix („erst.“): technisch ok. Bei manuellem Tippen sind Punkte fehleranfällig; wenn du magst, ersetzen wir durch – erst (Gedankenstrich, ohne Punkt). Vorteil: Suchbegriffe bleiben schlank; Nachteil: optisch anders.
  • Umlaute im Titel: kein Problem. Wir behalten für Sortierung dennoch ASCII-Ziffernschlüssel → robuste Ordnung.
  • Mehrsprachigkeit (später?): Das Format „v. Chr./n. Chr.“ ist deutschfest; falls du irgendwann mehrsprachig gehst, kapseln wir die Beschriftung in eine Konfig-Lookup (ohne Logikbruch).

Antwort auf deine Kernfrage

  • Ja, deine Argumente sind zielführend und der Ansatz ist m. E. der beste: lesbarer Titel als Primärschlüssel für Mensch & Suche, Kennung als Sortierschlüssel für präzise Chronologie.
  • Einen „besseren“ Ansatz sehe ich nicht, außer man wollte Suchmaschinen-/SMW-Ebene umbauen (z. B. Custom-Analyzer, zusätzliche Indexfelder) – das wäre komplexer, ohne Mehrwert gegenüber der Titel-Umstellung.

Wenn du willst, formuliere ich als Nächstes die konkrete Schnittstelle des neuen Moduls (Funktionsnamen/Parameter/Rückgaben, inkl. GD/SD), damit wir danach nahtlos in die Implementierung gehen können – weiterhin ohne Änderungen am bestehenden Canvas.

Wozu ich im Folgenden keinen Kommentar gebe, haben wir Übereinstimmung.

zu Design-Entscheidungen:

Ja, bis "Suffixe:" soweit richtig.

Ich verwende vier Buchstaben plus punkt für die Art des Datum also gebo. anstelle von geb.,

Warum sollte ich Punkte vermeiden wollen? Stören die in der Programmierung? Das beantwortet sich nachfolgend uter "zu Risiken / Feinkanten"

Ja genau "Kategorie Pipetext verwenden". Mach ich da bei der Eingabe oder wird dies automatisch gesetzt?

Hierarchie ist stimmig.

zu Migrationsplan:

kein Kommentar alles richtig

zu Risiken / Feinkanten:

Punkte im Suffix "erst." ist sprachlich konventionell richtig daher ist "- erst" logisch unrichtig, aber man weiß gewiß, was gemeint ist. Es ist ein semantisches Wiki, also machen wir es sprachlich richtiger, wenn es technisch programmatisch nicht umständlich ist – ein vollkommen richtig gibt es nicht.

Wenn wir soweit übereinstimmen kannst du das Canvas Modul:AuFEinWortDatumKennung und das Coding durchführen.

Sehe ich das richtig, daß an sich nur die Kategorien anders gesetzt und um GD sowie SD erweitert wird, daß der Rest an sich gleich bleibt?

wir sind deckungsgleich, inkl. Punktsetzung

Nachgedacht
Der Benutzer möchte ein neues Modul namens "Modul:AufEinWortDatumKennung" erstellen. Es wird eine ähnliche Parsing- und Schlüsselgenerierungsfunktion benötigen, mit einer speziellen Handhabung von Datumsangaben, wobei vier Buchstaben plus Punkt verwendet werden sollen (z.B. "gebo."). Wir müssen auch Kategorien verlinken und DEFAULTSORT implementieren.

Ich muss sicherstellen, dass das neue Modul automatisch Links zu Kategorien mit einem Pipe-Sortierkey zurückgibt. Außerdem sollen Funktionen zur GD- und SD-Generierung hinzugefügt werden. Titel werden nicht mehr als Zahlen, sondern als lesbare Datumsangaben mit Suffixen angezeigt, und es müssen auch Elternkategorien erzeugt werden.

Ich werde nun die benötigten Funktionen implementieren, um lesbare Datumsstrings zu erzeugen und Daten in verschiedenen Formaten zurückzugeben, einschließlich Kategorien mit entsprechenden Sortierschlüsseln. Es gibt auch Funktionen für die verschiedenen Suffixe wie „erst.“, „bear.“, „hrsg.“, „gebo.“ und „gest.“.

Fertig

Modul:AufEinWortSeiteKennung 2

Super — wir sind deckungsgleich, inkl. Punktsetzung („erst.“, „bear.“, „hrsg.“, „gebo.“, „gest.“).

Ich habe ohne dein bestehendes Modul anzutasten ein neues Canvas angelegt und implementiert: „Modul:AufEinWortDatumKennung“.

Kernprinzipien darin:

  • Lesbare Kategorie-Titel werden erzeugt, z. B. [[Kategorie:12. März 2025 n. Chr. erst.|7025031200 ED]]. → Die Kennung bleibt erhalten, wird jetzt als Pipetext (Sortierschlüssel) genutzt.
  • Wrapper-Funktionen für alle fünf Arten:
    • catED, catBD, catUD, catGD (gebo.), catSD (gest.)
    • optional parents=1 (Standard) fügt Monat→Jahr-Eltern mit eigenem Sortkey hinzu; jh=1 (Standard) fügt die Jahrhundert-Kategorie hinzu.
  • Hilfsfunktionen:
    • anzeige (lesbares Datum),
    • sortkey (liefert „YIDXMMDDNN TOKEN“),
    • titel (lesbarer Kategorietitel),
    • defaultsort (falls du auf Kategorieseiten explizit {{DEFAULTSORT:…}} setzen willst).
  • Suffix-Labels: ED→erst., BD→bear., UD→hrsg., GD→gebo., SD→gest. – frei überschreibbar via Label= in Einzelfällen.

Kurz zur offenen Frage „Pipetext – manuell oder automatisch?“

→ Ab jetzt automatisch: Die cat*-Funktionen erzeugen die Kategorie-Links inkl. Pipetext. Auf Werkseiten musst du beim Einfügen nichts mehr manuell pipen.

Antwort auf deine Schlussfrage:

Ja, im Wesentlichen ändern wir nur die Art, wie Kategorien gesetzt werden (Titel = lesbar; Kennung = Sortierwert) und erweitern um GD/SD. Parsing, Kennungslogik, Ära-Behandlung etc. bleiben inhaltlich gleich (robust übernommen).

Wenn du möchtest, formuliere ich jetzt eine kurze Einbauanleitung

(wo catED/BD/UD/GD/SD in deinen Vorlagen aufzurufen sind, und wie du bei den Kategorieseiten parents/jh steuerst) – oder wir gehen direkt in die Pilot-Tests an ein paar Seiten.

Ich brauche keine Hinweise für catED/BD/UD/GD/SD in Vorlagen oder Seiten,

da das Muster gleich bleibt und ich das Muster kenne.

Wie ich wie bei den Kategorieseiten parents/jh steuer bedarf einer Erklärung, wenn es nicht eh so wie zuvor geschieht.

Derzeitiger Inhalt zu Vorlage:AufEinWort KategorieDatum:

<onlyinclude>{{DISPLAYTITLE: {{#invoke:AufEinWortSeiteKennung
  | decodeKennungMitSuffix
  | ED=&nbsp;erst.
  | BD=&nbsp;bear.
  | sep= 
}} }}
{{#invoke:AufEinWortSeiteKennung|katMeta
 |ED=Kategorie:Werk Erstellungsdatum
 |BD=Kategorie:Werk Bearbeitungsdatum
 |ED_Tag=Kategorie:Werk Erstellungskennung Tag
 |ED_Monat=Kategorie:Werk Erstellungskennung Monat
 |ED_Jahr=Kategorie:Werk Erstellungskennung Jahr
 |BD_Tag=Kategorie:Werk Bearbeitungskennung Tag
 |BD_Monat=Kategorie:Werk Bearbeitungskennung Monat
 |BD_Jahr=Kategorie:Werk Bearbeitungskennung Jahr
}}
{{#invoke:AufEinWortSeiteKennung|katJahrhundert}}</onlyinclude>
<noinclude>[[Kategorie:AufEinWort Vorlage KategorieDatum]]</noinclude>

Diese muß für "Vorlage:AuFEinWort Datum Sortierung" gewiß umgetsaltet und erweitert werden.

Steuerung auf Kategorieseiten

Nachgedacht
Die Anfrage bezieht sich darauf, wie Eltern und die jh-Kategorie auf Kategorieseiten gesteuert und das Template umgewandelt werden können. Ich schlage eine Parameterisierung der Modulfunktionen vor, um Titel, Sortierung und Elternkategorien basierend auf dem Seitentitel oder über Parameter anzupassen. In der neuen Version braucht es keine DATEI-Parameter.

Es scheint, dass unser Modul auch Funktionen zur Bestimmung von Elternkategorien und Jahrhundertkategorien beinhaltete, aber die Dokumentation für Entwickler entspricht nicht ganz—das könnte Verwirrung stiften. Wir sollten die Mechanismen besser erklären, insbesondere die Kontrolle von Eltern und jh durch Template-Parameter.

Fertig

Alles klar. Kurz & präzise:

Steuerung von parents und jh (auf Kategorieseiten)

  • parents: schaltet die Elternkategorien ein/aus (Monat→Jahr).
    • parents=1 (Standard): fügt [[Kategorie:März 2025 n. Chr. erst.|YIDXMM00 ED]] und[[Kategorie:2025 n. Chr. erst.|YIDX0000 ED]] hinzu.
    • parents=0: keine Eltern (nur die Tages-/Monats-/Jahres-Kat selbst).
  • jh: schaltet die Jahrhundert-Kategorie ein/aus.
    • jh=1 (Standard): fügt z. B. [[Kategorie:21. Jh. n. Chr.]] hinzu.
    • jh=0: kein Jahrhundert.

(Wie gehabt, nur dass jetzt lesbare Titel genutzt werden und der Sortkey = Kennung ist.)

Umstellung deiner Vorlage:AufEinWort KategorieDatum→ „Vorlage:AufEinWort DatumSortierung“

Ziel: Kein DISPLAYTITLE mehr nötig; stattdessen:

  1. DEFAULTSORT nach Kennung (YIDXMMDDNN + TOKEN).
  2. Eltern (Monat/Jahr) optional über parents.
  3. Jahrhundert optional über jh.
  4. Token-Steuerung (ED/BD/UD/GD/SD).

Parameter (schlank und eindeutig)

  • Datum= (z. B. 12. März 2025 n. Chr.; bei Monats-/Jahrsseiten entsprechend ohne Tag/Monat)
  • Token= (ED|BD|UD|GD|SD)
  • Nummer= (zweistellig, Standard 00)
  • parents= (1 Standard / 0 aus)
  • jh= (1 Standard / 0 aus)
  • form= (kurz|lang für „Jh.“ vs. „Jahrhundert“) – nur relevant, wenn jh=1

Verwendung auf Kategorieseiten

Du trägst explizit Datum & Token ein (empfehlenswert – robust, keine fragilen Titel-Parser nötig):

{{AufEinWort DatumSortierung
 | Datum   = 12. März 2025 n. Chr.
 | Token   = ED
 | Nummer  = 00
 | parents = 1
 | jh      = 1
 | form    = kurz
}}

Ergebnis:

  • {{DEFAULTSORT:7025031200 ED}}
  • [[Kategorie:März 2025 n. Chr. erst.|70250300 ED]]
  • [[Kategorie:2025 n. Chr. erst.|70250000 ED]]
  • [[Kategorie:21. Jh. n. Chr.]]

(Die konkreten Sortkeys variieren je nach Granularität; Schema bleibt gleich.)

Antworten auf deine Detailfragen

  • Punkt im Suffix („erst.“, „bear.“, „hrsg.“, „gebo.“, „gest.“): Kein technisches Problem. Es ist reine Titel- und Anzeige-Semantik; Sortierung passiert ohnehin über den numerischen Schlüssel.
  • „Kategorie-Pipetext verwenden – Eingabe oder automatisch?“ Automatisch. Die cat*-Funktionen im neuen Modul erzeugen Kategorie-Links inkl. Pipetext (Sortierschlüssel). Auf Werkseiten musst du nichts manuell pipen. Auf Kategorieseiten übernimmt die Vorlage die Eltern inkl. Pipetext.

Kurzfazit

Ja, du siehst es richtig: Nur die Art des Kategoriensetzens ändert sich (Titel lesbar, Kennung als Sortierwert) und wir erweitern um GD/SD. Die übrige Logik (Datumserkennung, v./n. Chr., YIDX, NN) bleibt inhaltlich gleich.

Wenn gewünscht, formuliere ich dir die exakte Vorlage „AufEinWort DatumSortierung“ (ohne Änderungen an deinen Modulen) als nächstes – kompakt, mit den obigen Parametern und Aufrufen.

Ich hätte lieber ein automatisches Setzen des Sortierschlüssel in Kategorieseiten gemäß des Seitennamen, also #invoke:#invoke:AufEinWortDatumKennung setzt {{SORTIERUNG:{{{SORTIERSCHLÜSSEL}}}}} und wenn nur bei Bedarf manuelle Eingabe.

Erstelle mir eine demgemäße Vorlage und im Anschluß daran dann das passende "Modul:AufEinWort KategorieDatum" erstellt – OK?

verstanden & umgesetzt.

Nachgedacht
Ich muss eine Vorlage und ein Modul namens "AufEinWort KategorieDatum" erstellen, um die Sortierung basierend auf dem Seitentitel automatisch zu setzen. Ich werde #invoke verwenden, um den Titel zu parsen und {{DEFAULTSORT:...}} zu erzeugen Der Code geht nur in die Canvas-Dokumente, um keine Wiederholungen im Chat zu haben.

Die Vorlage ruft das Modul auf, um DEFAULTSORT und Eltern/JH basierend auf dem Titel zu berechnen, mit optionalen Überschreibungen. Es muss die Datumskomponente im Titel analysieren und die Parameter berücksichtigen. Letztlich wird die Vorlage den Aufruf des Moduls enthalten, um die gewünschten Ergebnisse, wie DEFAULTSORT und Kategorien, zu liefern.

Ich plane das Setup zu erstellen, das Datum, Token und Nummer aus dem Titel oder Overrides berechnet. Die Ausgabe wird DEFAULTSORT, Elternkategorien und Jahrhundert sein. Dabei müssen wir das Suffix im Titel erkennen und den passenden Token-Code bereitstellen. Außerdem müssen wir mithilfe der Datumsparsing-Methoden das Datum korrekt extrahieren und anpassen.

Fertig 

<onlyinclude>{{#invoke:AufEinWort KategorieDatum|setup
 | Datum   = {{{Datum|}}}
 | Token   = {{{Token|}}}
 | Nummer  = {{{Nummer|00}}}
 | parents = {{{parents|1}}}
 | jh      = {{{jh|1}}}
 | form    = {{{form|kurz}}}
}}</onlyinclude>
<noinclude>
Diese Vorlage setzt auf Kategorieseiten automatisch den Sortierschlüssel (\'\'DEFAULTSORT\'\') anhand des Seitennamens (lesbares Datum + Suffix) und fügt – konfigurierbar – die passenden Elternkategorien (Monat→Jahr) sowie die Jahrhundert-Kategorie hinzu.

**Parameter**
- `Datum` (optional): überschreibt die Datumsermittlung aus dem Seitennamen.
- `Token` (optional): `ED|BD|UD|GD|SD` – überschreibt die Token-Erkennung aus dem Suffix im Seitennamen.
- `Nummer` (optional): zweistellig, Standard `00`.
- `parents` (optional): `1` (Standard) fügt Monat/Jahr-Eltern hinzu; `0` unterdrückt.
- `jh` (optional): `1` (Standard) fügt Jahrhundert hinzu; `0` unterdrückt.
- `form` (optional): `kurz|lang` für "Jh." vs. "Jahrhundert".

**Erwartetes Titelformat** (Beispiele):
- `12. März 2025 n. Chr. erst.`
- `März 2025 n. Chr. bear.`
- `2025 n. Chr. hrsg.`
- `425 v. Chr. gebo.`

**Hinweis**: Suffixe werden sprachrichtig mit Punkt geführt: `erst.`, `bear.`, `hrsg.`, `gebo.`, `gest.`

[[Kategorie:AufEinWort Vorlage KategorieDatum]]
</noinclude>

Ich habe zwei neue Canvas-Dateien erstellt:

  1. Vorlage:AufEinWort DatumSortierung
  • Zweck: auf Kategorieseiten automatisch DEFAULTSORT + Eltern (Monat→Jahr) + optional Jahrhundert setzen.
  • Standardverhalten: parents=1, jh=1, form=kurz.
  • Manuelle Overrides möglich (Datum, Token, Nummer), aber nicht nötig.
  1. Modul:AufEinWort KategorieDatum
  • Logik: ermittelt aus dem Seitennamen (lesbares Datum + Suffix „erst./bear./hrsg./gebo./gest.“) Datum + Token, berechnet Kennung (YIDXMMDDNN) mit optionaler Nummer (Default 00), setzt {{DEFAULTSORT:…}} und hängt Eltern- + Jahrhundert-Kategorien an.
  • Token-Mapping ist sprachrichtig (mit Punkt).
  • Robust für Tages-, Monats- und Jahresseiten; v. Chr./n. Chr. wird berücksichtigt.

Nutzung (auf Kategorieseiten)

Minimal (alles automatisch aus dem Titel):{{AufEinWort DatumSortierung}}

Mit gezielten Overrides (nur wenn nötig):

{{AufEinWort DatumSortierung
 | Datum   = 12. März 2025 n. Chr.
 | Token   = ED
 | Nummer  = 00
 | parents = 1
 | jh      = 1
 | form    = kurz
}}

Antworten auf deine Punkte:

  • Automatisches Setzen des Sortierschlüssels gemäß Seitennamen: ✔️ umgesetzt; DEFAULTSORT wird generiert.
  • Manuelle Eingabe nur bei Bedarf: ✔️ möglich über die Vorlage-Parameter.
  • parents/jh steuerbar wie zuvor (jetzt per Vorlage-Parameter).
  • GD/SD: vollständig integriert (Suffixe gebo./gest. erkannt; Token GD/SD verwendbar).

Wenn du möchtest, testen wir als Nächstes an 2–3 Beispielen (Tag/Monat/Jahr, v./n. Chr.) und justieren Details (z. B. Nummernvergabe, Label-Varianten).

Danke super vorbereitet.

1. Ich habe Canvas für Modul Datum in "Modul:AufEinWortDatumKennung" umbenannt.

2. in Modul:AufEinWortDatumKennung

wird in folgendem Block die Zeile "  s = mw.ustring.gsub(s, "\u00A0", " ") -- NBSP → Space" als Fehler angezeigt:

local function trim(s)
  if not s then return s end
  s = mw.ustring.gsub(s, "\u00A0", " ") -- NBSP → Space
  s = mw.ustring.gsub(s, "%s+", " ")
  s = mw.ustring.match(s, "^%s*(.-)%s*$") or s
  return s
end

Bitte korrigiere diese einzigen Fehler darin zuerst und dann machen wir weiter.

Da derartige bearbeitungen im Canvas of abbrechen, ist es einfacher du gibst mir die überarbeitete Zeiel oder den Block überarbeitet aus, denn ich dann einsetze.

korrigierte Trim-Block

Nachgedacht
Die Zeile s = mw.ustring.gsub(s, "\u00A0", " ") verursacht einen Fehler. Der Escape-Code \uXXXX ist in Lua nicht gültig. Stattdessen sollte man das NBSP-Zeichen direkt oder den Byte-Code verwenden, wie z.B. \194\160. Eine bessere Lösung ist mw.ustring.char(160).

Fertig

Gern — hier der korrigierte Trim-Block (Lua kennt kein \u00A0-Escape; wir nutzen mw.ustring.char(160)):

local function trim(s)
  if not s then return s end
  s = mw.ustring.gsub(s, mw.ustring.char(160), " ") -- NBSP → Space
  s = mw.ustring.gsub(s, "%s+", " ")
  s = mw.ustring.match(s, "^%s*(.-)%s*$") or s
  return s
end

Danke ich habe den Block ersetzt

und bei mir die Vorlage und das Modul erstellt.

Ich habe "Kategorie:23. Mai 2023 n. Chr. erst." erzeugt und darin "Vorlage:AufEinWort DatumSortierung" eingefügt.

Im Edit Mode wird richtig "DEFAULTSORT:7023052300 ED" angezeigt – da neue Modul berechnet also diesen Eintrag richtig und funktioniert somit

Was die Hierarchie betrifft werden automatisch die Kategorien

1. "Mai 2023 n. Chr. erst."

2. "2023 n. Chr. erst."

3. "21. Jh. n. Chr."

erzeugt.

Meinst du nicht auch, daß wir für eine echte Hierarchie nicht nur 1. "Mai 2023 n. Chr. erst." erzeugen sollten und wenn man diese Kategorie klickt, dann dort nur 2. "2023 n. Chr. erst." und wenn man darauf klickt zru wider höheren Kategorie als Überkategorie automatisiert eingefügt gelangt und so das was man sucht immer weiter ausweitet? oder umgekehrt einengt?

reiner Kettenaufbau sinnvoller als der bisherige „Stern“

Nachgedacht
Wir müssen auf die Frage der Benutzer hierarchischen Struktur eingehen. Der Benutzer schlägt vor, nur den direkten Elternteil hinzuzufügen, anstatt Monat und Jahr gleichzeitig auf derselben Ebene zu haben. Die Idee, die Struktur klarer zu gestalten (Tag -> Monat -> Jahr -> Jahrhundert) verbessert die Navigation, indem Duplikationen vermieden werden. Eine mögliche Lösung wäre, den Modus für Eltern auf "chain" einzustellen.

Ich sollte das Kategoriemodell verstehen: In MediaWiki können Kategorieseiten über Links elterliche Kategorien einschließen. Derzeit verlinkt jeder Tag zu Monat und Jahr, was zu Duplikationen führen kann. Ich schlage zwei Muster vor:

  • Star: Ein Tag verlinkt sowohl zum Monat als auch zum Jahr. Vorteil: Weniger Klicks, Nachteil: Inkonsequente Hierarchie.
  • Chain: Tag verlinkt nur zum Monat; Monat nur zum Jahr. Vorteil: Saubere Hierarchie, Nachteil: Mehr Klicks.

Es könnte auch eine Hybridoption geben: die Chain als Standard, aber mit Ausnahmefällen für Monate und Jahr.

Fertig

Ja — ich stimme dir zu: Für eine „echte“ Hierarchie ist ein reiner Kettenaufbau sinnvoller als der bisherige „Stern“ (Tag → Monat und Jahr). So entsteht der gewünschte Drill-down/Drill-up-Pfad:

  • Tag → nur Monat
  • Monat → nur Jahr
  • Jahr → nur Jahrhundert
  • (Jahrhundert hat i. d. R. keine Eltern mehr)

Warum „Kette“ statt „Stern“?

  • Navigationslogik bleibt klar: von spezifisch → allgemein, Schritt für Schritt.
  • Kein Doppel-Hochhängen der Tageskategorien direkt im Jahr (weniger Redundanz).
  • Wartbarkeit steigt: Jede Ebene kennt genau eine Elternbeziehung.
  • Sortierung bleibt unverändert korrekt, da innerhalb jeder Ebene weiterhin über den DEFAULTSORT (Kennung) sortiert wird.

Granularitätsregeln (ohne Code, nur Logik)

  • Wenn D≠00 und M≠00 → Seite ist Tag → Eltern: Monat.
  • Wenn D=00 und M≠00 → Seite ist Monat → Eltern: Jahr.
  • Wenn D=00 und M=00 → Seite ist Jahr → Eltern: Jahrhundert.
  • (Sonderfall M=00 bei Tages-/Monatsseiten kann es eigentlich nicht geben; falls doch, gilt die nächsthöhere sinnvolle Ebene.)

ED/BD/UD/GD/SD

Die getrennten Bäume je Token bleiben erhalten:

  • „12. März 2025 n. Chr. erst.“ ⟶ „März 2025 n. Chr. erst.“ ⟶ „2025 n. Chr. erst.“ ⟶ „21. Jh. n. Chr.“ Analog für bear., hrsg., gebo., gest.

Umsetzungsvorschlag (ohne Coding jetzt)

  • In deiner Vorlage:AufEinWort DatumSortierung (die du bereits nutzt) wechseln wir die Eltern-Logik von „alle passenden Eltern setzen“ auf „nur unmittelbaren Elternknoten setzen“.
  • Optional machen wir das per Schalter:
    • parents=chain (nur der direkte Parent)
    • parents=all (bisheriges Verhalten mit Monat und Jahr gleichzeitig)
    • Default: chain
  • jh greift dann nur auf Jahrsseiten (Granularität Jahr). Auf Tages-/Monatsseiten wird kein Jahrhundert mehr direkt gesetzt.

Wenn das für dich so stimmig ist, stelle ich im nächsten Schritt die Vorlage/Modullogik auf „chain“ als Standard um (mit dem Schalter, damit du bei Bedarf „all“ aktivieren kannst).

wenn das Coding erhalten bleibt

Ja warum nicht, wenn das Coding erhalten bleibt, können wir bei Bedarf wieder darauf zurückgreifen und ändern jetzt nur die Datumvorlage.

Ketten-Hierarchie

voll dabei. Für Ketten-Hierarchie (Tag→Monat→Jahr→Jh.) ohne Sternverzweigung brauchst du eine kleine Modul-Anpassung plus eine Mini-Änderung in der Vorlage (nur Standard-Parameter setzen). Du wolltest zuerst nur die Vorlage ändern – das alleine reicht leider nicht, weil das Eltern-Setzen im Modul steckt. Daher gebe ich dir exakte Patch-Snippets (einfügen/ersetzen), damit du sie 1:1 übernehmen kannst – ohne Canvas-Bearbeitungsabbrüche.

1) Vorlage:AufEinWort DatumSortierung (nur Standard auf „chain“ setzen)

Ersetze den onlyinclude-Block deiner Vorlage durch:

<onlyinclude>{{#invoke:AufEinWort KategorieDatum|setup
 | Datum   = {{{Datum|}}}
 | Token   = {{{Token|}}}
 | Nummer  = {{{Nummer|00}}}
 | parents = {{{parents|chain}}}   <!-- chain = nur unmittelbarer Elternknoten -->
 | jh      = {{{jh|1}}}
 | form    = {{{form|kurz}}}
}}</onlyinclude>

Damit wünscht die Vorlage standardmäßig chain. „all“ bleibt möglich: parents=all.

2) Modul:AufEinWortKategorieDatum (Kettenlogik + NBSP-Fix)

2.1 NBSP-Zeile korrigieren

Ersetze im trim-Block die NBSP-Zeile: 

s = mw.ustring.gsub(s, "\u00A0", " ") -- NBSP → Space

durch: 

s = mw.ustring.gsub(s, mw.ustring.char(160), " ") -- NBSP → Space
2.2 Granularität ermitteln

Füge oberhalb von make_defaultsort_and_parents diese Helferfunktion ein:

local function granularity_of(y, m, d)
  -- returns "day" | "month" | "year"
  if (d or 0) > 0 and (m or 0) > 0 then return "day" end
  if (m or 0) > 0 then return "month" end
  return "year"
end
2.3 Eltern-Setzen auf „chain“ umstellen

Ersetze den gesamten Block -- Eltern (Monat → Jahr) innerhalb von

make_defaultsort_and_parents durch den folgenden:

  -- Eltern (chain vs. all)
  local parentsMode = tostring(args.parents or "chain")
  local eraLabel = (era == 0) and " v. Chr." or " n. Chr."
  local suffix = LABELS[token] or token
  local g = granularity_of(y, m or 0, d or 0)

  if parentsMode ~= "0" then
    if parentsMode == "all" then
      -- bisheriges Verhalten: Tag → Monat & Jahr; Monat → Jahr
      if m and m >= 1 and m <= 12 then
        local monthTitle = string.format("%s %d%s %s", monatsNamen[m], y, eraLabel, suffix)
        local monthKey   = string.format("%s%02d00 %s", string.sub(code,1,4), m, token) -- YIDXMM00 TOKEN
        table.insert(out, string.format("[[Kategorie:%s|%s]]", monthTitle, monthKey))
      end
      local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
      local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)         -- YIDX0000 TOKEN
      table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))
    else
      -- chain (Standard): Tag → Monat; Monat → Jahr; Jahr → (kein Parent hier)
      if g == "day" then
        if m and m >= 1 and m <= 12 then
          local monthTitle = string.format("%s %d%s %s", monatsNamen[m], y, eraLabel, suffix)
          local monthKey   = string.format("%s%02d00 %s", string.sub(code,1,4), m, token) -- YIDXMM00 TOKEN
          table.insert(out, string.format("[[Kategorie:%s|%s]]", monthTitle, monthKey))
        end
      elseif g == "month" then
        local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
        local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)         -- YIDX0000 TOKEN
        table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))
      else
        -- g == "year" → kein direkter Parent hier
      end
    end
  end
2.4 Jahrhundert nur auf Jahr-Seiten setzen

Ersetze den gesamten Jahrhundert-Block:

  -- Jahrhundert
  local wantJh = tostring(args.jh or "1") ~= "0"
  if wantJh then
    local form = args.form or "kurz"
    local term = (form == "lang") and "Jahrhundert" or "Jh."
    local ce = (era ~= 0)
    local century = math.floor((y - 1) / 100) + 1
    local label = tostring(century)..". "..term.." "..(ce and "n. Chr." or "v. Chr.")
    table.insert(out, string.format("[[Kategorie:%s]]", label))
  end

durch:

  -- Jahrhundert (nur bei Granularität = Jahr)
  local wantJh = tostring(args.jh or "1") ~= "0"
  if wantJh and g == "year" then
    local form = args.form or "kurz"
    local term = (form == "lang") and "Jahrhundert" or "Jh."
    local ce = (era ~= 0)
    local century = math.floor((y - 1) / 100) + 1
    local label = tostring(century)..". "..term.." "..(ce and "n. Chr." or "v. Chr.")
    table.insert(out, string.format("[[Kategorie:%s]]", label))
  end

Ergebnis

  • Standard (ohne Parameter): parents=chain ⇒ Tag-Seite hängt nur an Monat; Monat nur an Jahr; Jahr nur an Jh.
  • Kompatibilität: parents=all aktiviert das alte Verhalten (Tag → Monat & Jahr; Monat → Jahr).
  • Jh-Kategorie erscheint nur auf Jahr-Seiten.
  • NBSP-Fehler ist behoben.

Wenn du diese Snippets eingepflegt hast, reicht ein Test an drei Seiten:

  • 23. Mai 2023 n. Chr. erst. (Tag) → Parent nur „Mai 2023 n. Chr. erst.“
  • Mai 2023 n. Chr. erst. (Monat) → Parent nur „2023 n. Chr. erst.“
  • 2023 n. Chr. erst. (Jahr) → Parent nur „21. Jh. n. Chr.“

Sag Bescheid, wenn du eine reine „Jahrhundert-Kette“ (Jh. → Jahrtausend) ergänzen willst; dafür könnten wir einen optionalen weiteren Schritt einbauen.

Änderungen im Canvas ausgeführt

Ich habe die Änderungen im Canvas Modul:AufEinWortDatumKennung ausgeführt

für Änderung "-- Eltern (chain vs. all)" hast du mir als erste Zeile keine Funktion gegeben und so habe ich die bisherige Funktion "local function make_defaultsort_and_parents(args)" belassen.

Bitte überprüfe nun einmal das Coding, ob ich alles darin richtig ersetzt habe.

Nachgedacht
Ich muss den bereitgestellten Code durchsehen und Fehler beheben. Die Modulüberschrift ist korrekt ("Modul:AufEinWort KategorieDatum"). Es gibt jedoch ein Duplikat der Definition von granularity_of, das entfernt werden muss. In der Funktion make_defaultsort_and_parents fehlen wichtige Logiken zur Variablenberechnung und der Einfügeprozess für DEFAULTSORT. Auch die Importe für table.insert fehlen.

Ich muss die Funktion make_defaultsort_and_parents neu aufbauen:

  • infer_from_title für datum, token, nummer
  • parse_pretty_date für y, m, d und era
  • Berechnen von code mit kennung_parts_from
  • Erstellen von out = {} und Einfügen der DEFAULTSORT-Zeile
  • Der Eltern-Block nutzt out, code, y, m, d, era, token
  • Bei der Jahrhundert-Berechnung wird g benötigt, also muss das vor dem Eltern-Block berechnet und benutzt werden

Außerdem wird detectEra nur für "v. Chr." verwendet, aber das sollte auch für "n. Chr." passen. Letztlich die Korrektur des Modultitels und allgemeine Anpassungen am Code.

Ich muss sicherstellen, dass in parse_pretty_date die Erkennung der Ära durch detectEra(s) auf "v. Chr." basiert. Die Prüfung für "n. Chr." sollte auch verarbeitet werden. Dazu wird der Standardwert 1 für detectEra verwendet. Die Korrekturen umfassen den Duplikat-Block von granularity_of und das vollständige Update der Funktion make_defaultsort_and_parents.

Ich muss sicherstellen, dass der Code korrekt angepasst wird:

  • Suffix und Granularität werden richtig berechnet.
  • Bei parentsMode == "all" werden Monats- und Jahreskategorien hinzugefügt.
  • Der g-Wert steuert, ob wir mit Tagen oder Monaten arbeiten.
  • Ich sorge dafür, dass die Jahrhundertbezeichnung anpasst wird und alles korrekt formatiert wird.

Fertig

gut gesehen – in deinem aktuellen Stand fehlen in make_defaultsort_and_parents mehrere lokal benötigte Variablen (era, token, y/m/d, code, out) und granularity_of ist doppelt definiert. Hier sind die präzisen Patches, die du 1:1 übernehmen kannst:

1) Doppelte Funktion entfernen

Lass nur eine Definition von granularity_of stehen. Lösche die zweite, identische Kopie.

2) make_defaultsort_and_parents komplett ersetzen

Ersetze deine gesamte Funktion durch diese Version:

local function make_defaultsort_and_parents(args)
  -- 1) Datum/Token/Nummer aus Parametern bzw. Seitentitel ermitteln
  local datum, token, nummer = infer_from_title(args)

  -- 2) Lesbares Datum parsen → y,m,d,era
  local y, m, d, era = parse_pretty_date(datum)
  if not y then
    return ""  -- Titel nicht erkennbar
  end

  -- 3) Kennung (YIDXMMDDNN) bilden
  local code = kennung_parts_from(y, m or 0, d or 0, era, nummer)
  if not code then
    return ""
  end

  -- 4) DEFAULTSORT setzen
  local out = {}
  table.insert(out, string.format("{{DEFAULTSORT:%s %s}}", code, token))

  -- 5) Eltern (chain vs. all)
  local parentsMode = tostring(args.parents or "chain")
  local eraLabel = (era == 0) and " v. Chr." or " n. Chr."
  local suffix = LABELS[token] or token
  local g = granularity_of(y, m or 0, d or 0)

  if parentsMode ~= "0" then
    if parentsMode == "all" then
      -- bisheriges Verhalten: Tag → Monat & Jahr; Monat → Jahr
      if m and m >= 1 and m <= 12 then
        local monthTitle = string.format("%s %d%s %s", monatsNamen[m], y, eraLabel, suffix)
        local monthKey   = string.format("%s%02d00 %s", string.sub(code,1,4), m, token) -- YIDXMM00 TOKEN
        table.insert(out, string.format("[[Kategorie:%s|%s]]", monthTitle, monthKey))
      end
      local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
      local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)         -- YIDX0000 TOKEN
      table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))
    else
      -- chain (Standard): Tag → Monat; Monat → Jahr; Jahr → (kein Parent hier)
      if g == "day" then
        if m and m >= 1 and m <= 12 then
          local monthTitle = string.format("%s %d%s %s", monatsNamen[m], y, eraLabel, suffix)
          local monthKey   = string.format("%s%02d00 %s", string.sub(code,1,4), m, token) -- YIDXMM00 TOKEN
          table.insert(out, string.format("[[Kategorie:%s|%s]]", monthTitle, monthKey))
        end
      elseif g == "month" then
        local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
        local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)         -- YIDX0000 TOKEN
        table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))
      else
        -- g == "year" → kein direkter Parent hier
      end
    end
  end

  -- 6) Jahrhundert nur bei Jahrgranularität
  local wantJh = tostring(args.jh or "1") ~= "0"
  if wantJh and g == "year" then
    local form = args.form or "kurz"
    local term = (form == "lang") and "Jahrhundert" or "Jh."
    local ce = (era ~= 0)
    local century = math.floor((y - 1) / 100) + 1
    local label = tostring(century)..". "..term.." "..(ce and "n. Chr." or "v. Chr.")
    table.insert(out, string.format("[[Kategorie:%s]]", label))
  end

  return table.concat(out, "\n")
end

Damit sind:

  • DEFAULTSORT gesetzt,
  • parents korrekt im Modus chain (Standard) oder all,
  • Jh nur auf Jahrsseiten,
  • und alle zuvor fehlenden Variablen sauber definiert.

Wenn du das eingespielt hast, teste bitte kurz:

  • Tag-Seite → Parent nur Monat
  • Monat-Seite → Parent nur Jahr
  • Jahr-Seite → Parent nur Jh (falls jh=1)

Melde dich, falls noch eine Warnung im Lua-Log auftaucht – dann schauen wir gezielt auf die Zeile.

Soweit scheint dies auf einer Kategorie-Datum-Seite nun zu funktionieren.

Für die Werk-Seite habe ich zuvor folgende Syntax verwendet:

{{#if:{{{Erstellungsdatum|}}} | [[hat Erstelldatum::{{{Erstellungsdatum}}}| ]] [[hat Kennung Erstelldatum::{{#invoke:AufEinWortSeiteDatum|kennungE|Erstellungsdatum={{{Erstellungsdatum|}}}|Nummer={{{Nummer|00}}}}}| ]]
{{#invoke:AufEinWortDatumKennung|catErstellung|Erstellungsdatum={{{Erstellungsdatum|}}}|Nummer=00|style=postfix}} erst. [[:Kategorie:{{#invoke:AufEinWortDatumKennung|kennungE|Erstellungsdatum={{{Erstellungsdatum|}}}|Nummer=00}} ED|{{#invoke:AufEinWortDatumKennung|anzeige|Erstellungsdatum={{{Erstellungsdatum|}}}}}]] | }}

Für Bearbeitungsdatum und Urwerkdatum ist dies entsprechend.

Ich will nach wie vor lediglich das Erstellungsdatum mittels der Vorlage erfassen und die Kategorie soll nun demgemäß Datum + v./n. Chr. + erst. /bearb./hrsg. anstelle von "Kategorie:7…" sein.

Diese ist Komplex.

Zwei kleine Korrekturen

Nachgedacht
Ich habe eine doppelte Definition der Funktion "granularity_of" bemerkt und auch, dass die Kommentare im Modul nicht ganz übereinstimmen. Der Lua-Pattern %a+ könnte mit Umlauten wie 'ä' ein Problem haben, da dieser nur ASCII-Zeichen erfasst. Die Verwendung von mw.ustring könnte hier eine Lösung bieten, um solche Unterschiede zu handhaben.

Das Muster %a+ könnte bei Monatsnamen wie "März" mit Umlauten Probleme verursachen. Eine bessere Lösung wäre %S+, um den Monatsnamen zu erfassen, ohne Probleme mit diakritischen Zeichen zu haben. Es scheint auch zu funktionieren, um Suffixe wie "n. Chr." oder "v. Chr." in Titeln zu erkennen.

Fertig

top, danke für den Status! Zwei kleine Korrekturen sehe ich in deinem aktuellen Canvas Modul:AufEinWortDatumKennung:

  1. Doppelte Funktion entfernen Lass nur eine granularity_of-Definition stehen. Lösche die zweite Kopie.
  2. UTF-8/„März“-Robustheit in parse_pretty_date Deine aktuelle Variante nutzt string:match mit %a+ → das greift nicht auf „März“ (Umlaute). Nimm mw.ustring.match und ersetze %a+ durch %S+.

Hier sind die beiden Ersatzblöcke zum 1:1 Einsetzen:

A) parse_pretty_date – kompletter Ersatz

-- parse lesbare Datumsformen aus Titel (ohne Suffix)
-- liefert y, m (0 wenn unbekannt), d (0 wenn unbekannt), era (1 n. Chr., 0 v. Chr.)
local function parse_pretty_date(s)
  s = trim(s or "")
  local era = detectEra(s)

  -- Tag. Monat Jahr  (z. B. "12. März 2025 n. Chr." / "12. Maerz 425 v. Chr.")
  local d, mname, y = mw.ustring.match(s, "^(%d%d?)%.%s*(%S+)%s+(%d+)%s+[nv]%. Chr%.$")
  if d and mname and y then
    return tonumber(y), month_to_num(mname), tonumber(d), era
  end

  -- Monat Jahr  (z. B. "März 2025 n. Chr.")
  local mname2, y2 = mw.ustring.match(s, "^(%S+)%s+(%d+)%s+[nv]%. Chr%.$")
  if mname2 and y2 then
    return tonumber(y2), month_to_num(mname2), 0, era
  end

  -- Jahr  (z. B. "2025 n. Chr." / "425 v. Chr.")
  local y3 = mw.ustring.match(s, "^(%d+)%s+[nv]%. Chr%.$")
  if y3 then
    return tonumber(y3), 0, 0, era
  end

  return nil, nil, nil, era
end

B) granularity_of – nur einmal behalten

local function granularity_of(y, m, d)
  -- returns "day" | "month" | "year"
  if (d or 0) > 0 and (m or 0) > 0 then return "day" end
  if (m or 0) > 0 then return "month" end
  return "year"
end

Damit funktionieren „März/Maerz“ zuverlässig, und die doppelte Definition ist bereinigt.

Wenn das drin ist, probier bitte kurz:

  • 12. März 2025 n. Chr. erst. (Tag) → Parent nur Monat
  • März 2025 n. Chr. erst. (Monat) → Parent nur Jahr
  • 2025 n. Chr. erst. (Jahr) → Parent nur Jh.

Sag Bescheid, dann schauen wir uns im Anschluss deine Werkseiten-Syntax an und vereinfachen sie so, dass die Kategorie automatisch mit lesbarem Titel + Sortierschlüssel gesetzt wird (ohne „Kategorie:7…“).

Ich habe die Änderungen ausgsgeführt.

auf den KategorieSeiten funktioniert es.

dennoch bitte nochmals überprüfen

Zwei kleine, sinnvolle Korrekturen/Verbesserungen

Nachgedacht
Ich prüfe den Code und stelle sicher, dass alles stimmt. Das Kommentarfeld "Modul:AufEinWort KategorieDatum" stimmt mit dem Modulnamen "Modul:AufEinWortDatumKennung" nicht überein, aber das ist nur im Kommentar. Es scheint, dass die verwendeten Methoden korrekt sind, wie regexp, match und gsub. Alles sieht gut aus, keine größeren Probleme gefunden.

Ich schaue mir die Modulvariablen an und erkenne, dass es ein paar potentielle Fehlerquellen gibt. Die Nutzung des Accents in "März" ist in Ordnung, doch bei detectEra(s) scheint ein Problem mit dem NBSP in der Zeichenkette vorzuliegen. Ebenso bei der parentsMode-Überprüfung, aber da scheint alles gut zu sein, ähnlich wie bei den anderen Funktionen.

Es gibt ein Problem bei der Jahr-Ebene im 'parents=all' Modus. Wenn die Seite Jahr-Level hat, berechnet sich der JahrTitle in diesem Modus falsch und könnte sich selbst als übergeordnete Kategorie hinzufügen, was nicht gewollt ist. Ich muss also sicherstellen, dass das korrekt gehandhabt wird, besonders im Chain-Modus.

Die aktuelle 'all'-Logik fügt immer Monat und Jahr hinzu, auch auf Jahres-Ebene, was zu einem Fehler führt. Um das zu beheben, müssen wir prüfen, ob das 'g' den Wert 'Tag', 'Monat' oder 'Jahr' hat, und die Eltern-Logik entsprechend anpassen. Außerdem klappt die Era-Erkennung in parse_pretty_date, da die Eingabe das Suffix und Era-Phasen korrekt enthält.

Fertig

Kurzprüfung deines aktuellen Canvas (Modul:AufEinWortDatumKennung) – sieht gut aus und läuft. Zwei kleine, sinnvolle Korrekturen/Verbesserungen:

1) „parents=all“: Selbst-Kategorisierung bei Jahresseiten vermeiden

Im aktuellen all-Zweig wird das Jahr immer als Elternkategorie gesetzt – auch dann, wenn die Seite bereits eine Jahrsseite ist. Dadurch würde sich eine Jahr-Kategorie selbst enthalten. Ersetze nur den if parentsMode == "all" then … end-Block wie folgt:

if parentsMode == "all" then
  -- Granularitätsabhängig:
  if g == "day" then
    -- Tag → Monat & Jahr
    if m and m >= 1 and m <= 12 then
      local monthTitle = string.format("%s %d%s %s", monatsNamen[m], y, eraLabel, suffix)
      local monthKey   = string.format("%s%02d00 %s", string.sub(code,1,4), m, token)
      table.insert(out, string.format("[[Kategorie:%s|%s]]", monthTitle, monthKey))
    end
    local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
    local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)
    table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))

  elseif g == "month" then
    -- Monat → Jahr
    local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
    local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)
    table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))

  else
    -- g == "year" → keine Eltern hier (Jh. wird unten separat gesetzt)
  end

2) Era-Erkennung literal machen (robuster)

string.find nutzt Lua-Patterns. Damit „v. Chr.“ wörtlich gesucht wird (Punkte nicht als Joker), ersetze die Funktion detectEra durch:

local function detectEra(s)
  if not s or s == "" then return 1 end
  if s:find("v. Chr.", 1, true) then return 0 end  -- literal search
  return 1
end

Beides sind Mini-Patches, keine Verhaltensänderung im Standardfall „chain“ – aber sie machen das Modul sauber/robust. Wenn du das eingespielt hast, ist die Ketten-Hierarchie logisch perfekt:

Tag → Monat → Jahr → Jh. (nur Jahr bekommt Jh.).

Möchtest du als Nächstes die Werkseiten-Einträge vereinfachen (lesbarer Kat-Titel + automatischer Pipetext) ohne deine bestehende Seitenlogik zu verbiegen? Ich kann dir dafür eine drop-in Vorlage geben, die deine bisherigen Parserfunktionen schlank ersetzt.

Ich habe die Änderungen eingefügt.

Nochmals bitte prüfen.

Gib mir ein OK, wenn keine Änderungen mehr.

Minimal-Patch

Nachgedacht
Der Benutzer hat nach einer Überprüfung des Codes gefragt. Ich sehe, dass der Name des Moduls in den Kommentaren nicht übereinstimmt, was kein großes Problem darstellt. Die wichtigsten Punkte wie LABELS, LABEL_TO_TOKEN und die Handhabung von "März" sehen korrekt aus. Es gibt keine kritischen Fehler, und die speziellen Fälle wie die Umwandlung der Monate scheinen auch in Ordnung.

Ich sehe, dass der Kommentar zu „Eltern (Monat → Jahr)“ einige zusätzliche Leerzeichen vor der Funktionsdefinition hat, aber das scheint in Ordnung zu sein. Auch die Handling-Methoden für den „jahrIndex“ und „kennung_parts_from“ passen. Es gibt keine kritischen Fehler, aber innerhalb der Funktion „make_defaultsort_and_parents“ fehlt ein „else“ Zweig für den „chain“-Modus.

Im Code fehlt tatsächlich der „else“-Zweig für den „chain“-Modus. Es gibt nur den Zweig für „all“, sodass im „chain“-Modus keine Hierarchie hinzugefügt wird. Das könnte erklären, warum es nicht funktioniert, wie erwartet. Ich muss also einen „else“-Zweig für „chain“ hinzufügen, damit er richtig funktioniert.

Das Template setzt standardmäßig „chain“, aber ohne den „else“-Zweig werden keine Eltern hinzugefügt, was mit der früheren Funktionalität von Kategorien kollidiert. Wir müssen den „else“-Zweig für „chain“ hinzufügen und sicherstellen, dass andere Bereiche wie das Ersetzen von „NBSP“ und das Parsing korrekt sind. Das Umbenennen des Moduls ist kein kritisches Problem.

Fertig

Kurzer Check deines aktuellen Canvas (Modul:AufEinWortDatumKennung):

  • NBSP-Fix ✅
  • UTF-8/„März“-Parsing ✅
  • „all“ vermeidet Selbst-Kategorie bei Jahr ✅
  • DEFAULTSORT + Token ✅

🔎 Einziger offener Punkt: Chain-Zweig fehlt derzeit. In make_defaultsort_and_parents wird nur parentsMode == "all" behandelt; bei Standard chain werden aktuell keine Eltern gesetzt.

Minimal-Patch (nur der Eltern-Block)

Ersetze nur den Teil ab -- 5) Eltern (chain vs. all) bis vor den Jahrhundert-Block durch:

  -- 5) Eltern (chain vs. all)
  local parentsMode = tostring(args.parents or "chain")
  local eraLabel = (era == 0) and " v. Chr." or " n. Chr."
  local suffix = LABELS[token] or token
  local g = granularity_of(y, m or 0, d or 0)

  if parentsMode ~= "0" then
    if parentsMode == "all" then
      -- Granularitätsabhängig:
      if g == "day" then
        -- Tag → Monat & Jahr
        if m and m >= 1 and m <= 12 then
          local monthTitle = string.format("%s %d%s %s", monatsNamen[m], y, eraLabel, suffix)
          local monthKey   = string.format("%s%02d00 %s", string.sub(code,1,4), m, token)
          table.insert(out, string.format("[[Kategorie:%s|%s]]", monthTitle, monthKey))
        end
        local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
        local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)
        table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))

      elseif g == "month" then
        -- Monat → Jahr
        local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
        local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)
        table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))
      else
        -- g == "year" → keine Eltern hier (Jh. wird unten separat gesetzt)
      end
    else
      -- chain (Standard): Tag → Monat; Monat → Jahr; Jahr → (kein Parent hier)
      if g == "day" then
        if m and m >= 1 and m <= 12 then
          local monthTitle = string.format("%s %d%s %s", monatsNamen[m], y, eraLabel, suffix)
          local monthKey   = string.format("%s%02d00 %s", string.sub(code,1,4), m, token)
          table.insert(out, string.format("[[Kategorie:%s|%s]]", monthTitle, monthKey))
        end
      elseif g == "month" then
        local yearTitle = string.format("%d%s %s", y, eraLabel, suffix)
        local yearKey   = string.format("%s0000 %s", string.sub(code,1,4), token)
        table.insert(out, string.format("[[Kategorie:%s|%s]]", yearTitle, yearKey))
      else
        -- g == "year": kein Parent (Jh. kommt unten)
      end
    end
  end

Wenn du das einsetzt: OK von meiner Seite – keine weiteren Änderungen nötig.

Ja, ich hatte es beim Test bemerkt,

da fehlten die parent und sind nun wieder da.

Du erzeugst DEFAULTSORT mit Lua.

Das führt auf der KategorieSeite derzeit nur zur Anzeige  {{DEFAULTSORT:7023000000 ED}}, jedoch nicht zum Sortierungsschlüssel.

Ich habe in meinem Modul anstelle DEFAULTSORt nun SORTIERUNG stehen, da mein WikiMedia auf "de" steht

Muß ich in der KatigorieSeite direkt sowas wie {{SORTIERUNG:{{{{{DatumSortierung}}}}} einfügen, damit die Wikiseite diese Sortierung verwenden kann?

Das Modul muß also den Wert für SORTIERUNG liefern, SORTIERUNG darf nicht mittels einer Vorlage transkludiert werden – ist das bei MagicWord's so – oder irre ich mich da?

Du hast im Modul DEFAULSORT stehen, ich habe mein WikiMEDIA auf "de" und muß daher SORTIERUNG verwenden.

Ob ich nun DEFAULTSORT oder SORTIERUNG verwende, es erscheint bei mir rot hinterlegt {{SORTIERUNG:7023000000 ED}}, was an sich nicht angezeigt sondern nur ausgeführt werden würde.

Fehler der Vorlage oder des Modul?

Minimal-Patch DEFAULTSORT-Teil

Nachgedacht
For the user's issue, the key point is that in German Wikipedia, the alias for DEFAULTSORT is {{SORTIERUNG}}. This magic word behaves differently in templates and modules, as the curly braces might not be expanded correctly when invoked from Lua. This is likely why it appears as literal text rather than executing.

It seems like the red text might happen if there are spaces in the curly braces, or if the case of "DEFAULTSORT" was incorrect. The magic word is case-sensitive, so "DEFAULTSORT" must be typed correctly. In German, it's {{SORTIERUNG:Key}}, which should be recognized as per usual. If the word displays in red, MediaWiki might treat it like an unrecognized template instead.

In MediaWiki, if a magic word is recognized, it doesn't display at all, but if unrecognized, it links to a non-existent template (like ‘SORTIERUNG:7023...’). This suggests that the magic word isn’t being parsed correctly when returned from Lua — even though it should be. Maybe it’s not re-parsed in this context?

It seems that the user might have swapped "DEFAULTSORT" with "SORTIERUNG" in the Lua string. However, MediaWiki expects "DEFAULTSORT" even in the German locale. The alias "SORTIERUNG" is only recognized on the German Wikipedia site itself, and the issue could relate to how some reserved terms are handled in templates or special contexts.

It seems that the user’s issue may be related to how the 'DEFAULTSORT' magic word is handled incategory namespace, particularly with localization and how it’s used in templates. Normally, magic words like 'DEFAULTSORT' are parsed correctly, but the red text indicates that it might be treated as an unknown template, possibly due to local language settings or incorrect syntax.

Untersuchung der Verwendung von DEFAULTSORT und SORTIERUNG

It looks like the user’s wiki might be using the 'SORTIERUNG' alias for localization, which should be fine on a German wiki. However, the red display likely means the magic word is treated as literal text, not parsed. This could happen if it's wrapped in tags or nested in a template incorrectly.

It seems that the German wiki should handle {{SORTIERUNG:...}} as a valid alias, but the red display suggests that the magic word isn’t being parsed correctly. One reason could be the language setting or how it's being used. It could be the transclusion or how content is being processed in this case.

DEFAULTSORT is a bit tricky in that it behaves like a magic word rather than a typical template. While it generally works via direct inclusion, the issue might arise when it's inside templates. The red display could be due to the curly braces not being parsed correctly when inside another template or inclusion.

It looks like the issue might come from Lua returning strings after the preprocessor stage, which doesn't always re-expand certain constructs. Since DEFAULTSORT is a magic word, it may need to be processed during the preprocessor stage. The solution seems to be invoking it via frame:callParserFunction to process it properly.

Fertig

Guter Fund. Ursache: {{DEFAULTSORT:…}} aus Lua als reiner Wikitext zurückzugeben wird in deinem Setup nicht als MagicWord, sondern als Vorlagenaufruf behandelt → deshalb siehst du den roten Link.

Lösung: In Scribunto die Parserfunktion direkt aufrufen, nicht den Wikitext ausgeben.

Minimal-Patch (nur 3 Zeilen ändern)

In Modul:AufEinWortDatumKennung ersetze in make_defaultsort_and_parents(args) den DEFAULTSORT-Teil:

Alt

-- 4) DEFAULTSORT setzen
local out = {}
table.insert(out, string.format("{{DEFAULTSORT:%s %s}}", code, token))

Neu

-- 4) DEFAULTSORT setzen (per Parserfunktion, nicht als Wikitext)
local out = {}
local frame = mw.getCurrentFrame()
table.insert(out, frame:callParserFunction('DEFAULTSORT', code .. ' ' .. token) or '')

Warum so?

  • frame:callParserFunction('DEFAULTSORT', ...) triggert die MagicWord-Logik sofort und gibt i. d. R. einen leeren String zurück (also keine Anzeige, kein Rot).
  • Der kanonische Funktionsname ist DEFAULTSORT (funktioniert unabhängig von der Wiki-Sprache). Hinweis: Das deutsche Alias {{SORTIERUNG:…}} ist für Wikitext gedacht; aus Lua heraus immer den kanonischen Namen verwenden.

Du musst nichts zusätzlich in die Kategorieseite schreiben; die Vorlage/Modul erledigt das. Bitte SORTIERUNG nicht in der Lua-Rückgabe zusammensetzen – das führt genau zu dem roten Anzeige-Effekt.

Wenn du das eingespielt hast, sollte:

  • auf der Kategorie-Seite nichts Rotes mehr erscheinen,
  • die Seite in ihren Eltern sauber nach code .. ' ' .. token einsortiert sein.

Wenn noch etwas zickt, sag mir kurz, auf welcher konkreten Kategorie-Seite du es siehst; dann prüfe ich den Pfad (Granularität/parents/jh) gezielt.

Fehler hat sich weggeschlichen

und nun sieht es richtig aus.

gehen wir als Nächstes die Werkseiten an

Perfekt — OK von meiner Seite.

Dein aktuelles Modul:AufEinWortDatumKennung arbeitet stimmig:

  • DEFAULTSORT wird korrekt per Parserfunktion gesetzt (keine rote Anzeige).
  • parents=chain als Standard: Tag→Monat, Monat→Jahr, Jahr→(nur Jh. via jh).
  • parents=all funktioniert ohne Selbst-Kategorisierung bei Jahresseiten.
  • „März“/UTF-8 & NBSP sind robust gelöst.

Mini-Hinweis (rein kosmetisch): Die erste Kommentarzeile im Modulkopf nennt noch „AufEinWort KategorieDatum“. Funktional egal—kannst du bei Gelegenheit an den Seitennamen anpassen.

Wenn du willst, gehen wir als Nächstes die Werkseiten an (lesbarer Kat-Titel + automatischer Pipetext, ohne „Kategorie:7…“).

nun heißt es -- Modul:AufEinWortDatumKennung

Danke für den Hinweis.

Nun die die Werkseiten an (lesbarer Kat-Titel + automatischer Pipetext, ohne „Kategorie:7…“) bitte.

Meine Arbeitsweise. ich setze in dr Vorlage vergleichsweise:

10. Mai 2025 als

|Erstelldatum=10. Mai 2025

lasse aber durch das Modul dieses Datum in eine Kennung wandeln und mir zurückgeben.

Dies ist mir insofern hilfreich als das mir ein versehentliches 10. Mau 2015  keine Kennung gab sondern einen Fehler meldete.

An sich brauche ich den Umweg nur um meine Dateneingabe sauber zu halten ich könnte auch weitere Eingabefelder hinzufügen und mir daraus dann ohne Lua die Kategorie zusammenstellen.

wie bekommen wir nun beide Welten einfach hin?

Deine Antwort auf diesen prompt ging in die falsche Richtung und habe diesen Prompt daher ergänzt. Warte bitte  mit deinem Vorschlag. ich lade dir meine Vorlage hoch, da ich diese einem geänderten Prompt nicht anfügen kann.

Datei: Vorlage-AufEinWort.rtf

darin siehst du, daß ich Erstellungsdatum, Bearbeitungsdatum und Urwerkdatum auf eine komplexe weise mit semantischen Property setze, die ich in LIsten verwende.

drei Datums-Blöcke (UD/ED/BD) setzen Semantik-Properties und Kategorien

Nachgedacht
Dokumente werden gelesen

Es scheint, dass die Vorlage "#invoke:AufEinWortSeiteDatum|kennungE" auf ein anderes Modul verweist, aber wir können vorschlagen, die Funktion "#invoke:AufEinWortDatumKennung|sortkey" mit Token=ED zu verwenden, um das gewünschte Format zu erhalten. Wir könnten auch eine neue Funktion implementieren, um den numerischen Teil ohne Token zu extrahieren.

Wir können "hat Kennung Erstelldatum" mit dem neuen Modul setzen. Anstelle der aktuellen Darstellung schlagen wir vor, die Verwendung von "#invoke:AufEinWortDatumKennung" für die Kennung und Kategorien zu optimieren, um nur den numerischen Code ohne Token abzurufen. Für die Kategorie Struktur sollten wir sicherstellen, dass „parents“ auf Werkseiten korrekt angewendet werden.

Wir müssen die Dateiinhalte mit dem Zitiermarker für die Dateiversuche kennzeichnen und sowohl Snippets als auch Strukturreferenzen einfügen. Die Antwort sollte prägnant bleiben und minimale vollständige Ersatzzeilen bieten. Wir sollten auch erwähnen, dass die Funktionen "cat*" automatisch die Elternkette und das Jahrhundert hinzufügen.

Im Modul AufEinWortDatumKennung nutzt die Funktion cat* parent_cats_for, um sowohl Monat als auch Jahr zurückzugeben. Für die Werkseiten könnte es sinnvoll sein, beide hinzuzufügen, aber das führt dazu, dass die Kategorien "Tag", Monat und Jahr gleichzeitig miteinander verlinkt werden. In Werkseiten dürfen jedoch beide Kategorien durch catED automatisch hinzugefügt werden.

Fertig

Alles klar – ich habe mir deine aktuelle Vorlage:AufEinWortWerk angesehen. Die drei Datums-Blöcke (UD/ED/BD) setzen Semantik-Properties und Kategorien; außerdem gibt’s zwei Tippfehler im Modulaufruf (Seite/Datunm).

Ziel:

  • Weiterhin Kennung aus Datum berechnen → Fehler-Erkennung bleibt (z. B. „Mau“).
  • Werkseiten nur in die Tages-Kategorie (lesbarer Titel) einsortieren – ohne numerische Kat, ohne Eltern (Monat/Jahr) und ohne Jh. (die Eltern gehören auf die Kategorie-Seiten, nicht auf die Werkseite).
  • Sichtbarer Link zur passenden Datumskategorie bleibt (lesbar).

Unten sind Drop-in-Ersetzungen für jeden Block. Du kannst sie 1:1 einfügen.

1) Urwerkdatum (UD) – ersetzen

Ersetze deinen gesamten UD-Block (der mit {{#if:{{{Urwerkdatum|}}} | ... }}) durch:

{{#if: {{{Urwerkdatum|}}} |
 [[hat Urwerkdatum::{{{Urwerkdatum}}}| ]]
 [[hat Kennung Urwerkdatum::{{#invoke:AufEinWortDatumKennung|kennung
   | Urwerkdatum={{{Urwerkdatum|}}}
   | Nummer={{{Nummer|00}}}
 }}| ]]

 {{#invoke:AufEinWortDatumKennung|catUD
   | Urwerkdatum={{{Urwerkdatum|}}}
   | Nummer={{{Nummer|00}}}
   | parents=0
   | jh=0
 }}

 [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel
   | Token=UD
   | Urwerkdatum={{{Urwerkdatum|}}}
 }}|{{#invoke:AufEinWortDatumKennung|titel
   | Token=UD
   | Urwerkdatum={{{Urwerkdatum|}}}
 }}]]
| }}

Hinweis: In deinem Original steht versehentlich AufEinWort**Datunm**Kennung – das ist jetzt korrigiert.

2) Erstellungsdatum (ED) – ersetzen

Ersetze den gesamten ED-Block (der mit {{#if:{{{Erstellungsdatum|}}} | ... }}) durch:

{{#if: {{{Erstellungsdatum|}}} |
 [[hat Erstelldatum::{{{Erstellungsdatum}}}| ]]
 [[hat Kennung Erstelldatum::{{#invoke:AufEinWortDatumKennung|kennung
   | Erstellungsdatum={{{Erstellungsdatum|}}}
   | Nummer={{{Nummer|00}}}
 }}| ]]

 {{#invoke:AufEinWortDatumKennung|catED
   | Erstellungsdatum={{{Erstellungsdatum|}}}
   | Nummer={{{Nummer|00}}}
   | parents=0
   | jh=0
 }}

 [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel
   | Token=ED
   | Erstellungsdatum={{{Erstellungsdatum|}}}
 }}|{{#invoke:AufEinWortDatumKennung|titel
   | Token=ED
   | Erstellungsdatum={{{Erstellungsdatum|}}}
 }}]]
| }}

In deinem bisherigen Code war ein alter Modulname AufEinWort**Seite**Datum|kennungE im Einsatz – hier verwenden wir konsistent AufEinWortDatumKennung|kennung.

3) Bearbeitungsdatum (BD) – ersetzen

Ersetze den gesamten BD-Block (der mit {{#if:{{{Bearbeitungsdatum|}}} | ... }}) durch:

{{#if: {{{Bearbeitungsdatum|}}} |
 [[hat Bearbeitungsdatum::{{{Bearbeitungsdatum}}}| ]]
 [[hat Kennung Bearbeitungsdatum::{{#invoke:AufEinWortDatumKennung|kennung
   | Bearbeitungsdatum={{{Bearbeitungsdatum|}}}
   | Nummer={{{Nummer|00}}}
 }}| ]]

 {{#invoke:AufEinWortDatumKennung|catBD
   | Bearbeitungsdatum={{{Bearbeitungsdatum|}}}
   | Nummer={{{Nummer|00}}}
   | parents=0
   | jh=0
 }}

 [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel
   | Token=BD
   | Bearbeitungsdatum={{{Bearbeitungsdatum|}}}
 }}|{{#invoke:AufEinWortDatumKennung|titel
   | Token=BD
   | Bearbeitungsdatum={{{Bearbeitungsdatum|}}}
 }}]]
| }}

Warum genau so?

  • kennung (ohne Token) füttert deine Semantik-Properties „hat Kennung …“ wie bisher – inkl. Fehlerfall, falls das Datum unplausibel ist (dein gewünschter Schutz).
  • catED/BD/UD erzeugen die Kategorien (lesbare Titel, korrekter Pipetext) und – dank parents=0, jh=0 – keinHochhängen der Werkseite in Monat/Jahr/Jh. (die Ketten-Hierarchie bauen wir nur auf den Kategorie-Seiten).
  • Der sichtbare Link zeigt die lesbare Kategorie (mit Suffix), bleibt aber nur ein Link (durch führenden Doppelpunkt) und erzeugt keine zusätzliche Kategorisierung.

Wenn du willst, ergänze ich noch die GD/SD-Varianten für Personen-/Biografie-Werkseiten – Muster ist identisch (mit catGD/catSD und Token=GD/SD).

Medical References

  1. None DOI: file-GWkFL1WkMMh3n6ureVBaxb

keine DatumKategorie und folgende Fehler

Ja die Tippfehler hatte ich bemerkt und war dabei diese zu ändern – danke für den Hinweis. Danke für die Überarbeitung.

Ich habe nun keine DatumKategorie und folgende Fehler:

1. Skriptfehler: Die Funktion „catED“ ist nicht vorhanden.

2.[:Kategorie:Skriptfehler: Die Funktion „titel“ ist nicht vorhanden.

3. Skriptfehler: Die Funktion „titel“ ist nicht vorhanden.

präzise Patch-Blöcke

Nachgedacht
Es scheint, dass durch die Änderungen im Modul die Funktionen wie „catED“ und „titel“ entfernt wurden. Früher hatten wir beim Modul „Modul:AufEinWortDatumKennung“ diese Funktionen. Jetzt gibt es einen isolierten Modus für Seitenkategorien, der nur „p.setup“ enthält. Möglicherweise wurde das ursprüngliche Modul überschrieben. Ich muss das genauer prüfen.

Es scheint, dass die Funktionen wie „catED“ in "Modul:AufEinWortDatumKennung" entfernt wurden, was zu einem Fehler führt. Um den Fehler zu beheben, könnten wir entweder diese Funktionen wieder hinzufügen oder die #invoke-Aufrufe an ein anderes Modul anpassen, das diese Funktionen enthält. Die gewünschten Funktionen wie „kennung“, „titel“, „anzeige“ und „catED“ sollten wiederhergestellt werden.

Die aktuellen Funktionen auf den Werkseiten brauchen eine flexiblere Datumserkennung. Sie verwenden nur eine Funktion, die „n. Chr.“ erfordert, aber nicht alle Eingabedaten haben diese Markierung. Wir müssen die älteren Parsingsfunktionen wie „detectEraAndClean“ und „makeKennung“ integrieren, um eine flexiblere Handhabung der Datumsformate zu ermöglichen.

Um das Problem zu beheben, sollten wir die früheren Hilfsfunktionen wie „detectEraAndClean“ und „parse_date_flexible“ zurückbringen. Außerdem brauchen wir eine Funktion, die aus rohen Datumswerten die „Kennung“ erzeugt. Alternativ können wir den Benutzer auf die alten Funktionen verweisen, aber diese wurden offenbar ersetzt.

Um das Problem zu lösen, schlagen wir vor, einen Inline-Patch zu erstellen, der minimale Versionen der Funktionen wie catED hinzufügt, basierend auf der alten Logik zum Datumsstring. Wir müssen auch sicherstellen, dass die Parsing-Funktionen flexibel genug sind, um ohne explizite Ära-Strings zu arbeiten, und die genauen Datumsformatierungen richtig zu behandeln.

Fertig

(16. Sep. 2025, 11:58)

Du bekommst die Fehler, weil dein aktuelles Modul:AufEinWortDatumKennung nur die Kategorieseiten-Logik (setup) enthält – die Werkseiten-Funktionen catED/titel fehlen dort (sie waren in der früheren Fassung drin).

Hier sind präzise Patch-Blöcke, die du am Ende des Moduls – direkt vor return p einfügst. Damit stehen wieder kennung, titel sowie catED/BD/UD/GD/SD zur Verfügung, ohne die Kategorieseiten-Logik anzutasten.

1) Zusätzliche Parser für Werkseiten (flexibles Datum ohne „n. Chr.“ im String)

-- ===== Zusätzliche Parser/Helfer für Werkseiten =====

local function replace_umlauts(s)
  if not s or s == "" then return s end
  local m = { ["Ä"]="Ae", ["ä"]="ae", ["Ö"]="Oe", ["ö"]="oe", ["Ü"]="Ue", ["ü"]="ue", ["ß"]="ss" }
  for k,v in pairs(m) do s = mw.ustring.gsub(s, k, v) end
  return s
end

-- Era erkennen (Minuszeichen vorn, v chr, vor christus, bce, bc); Rückgabe 1=n. Chr., 0=v. Chr.
local function detectEraAndCleanRaw(s)
  if not s or s == "" then return 1, s end
  local era = 1
  local sl = mw.ustring.lower(s)
  sl = mw.ustring.gsub(sl, "%.", " ")
  sl = trim(sl)
  if mw.ustring.match(sl, "^%-")
     or mw.ustring.find(sl, " v chr")
     or mw.ustring.find(sl, " vor christus")
     or mw.ustring.find(sl, " bce")
     or mw.ustring.find(sl, " bc") then
    era = 0
  end
  sl = mw.ustring.gsub(sl, "^%-", "")
  sl = mw.ustring.gsub(sl, " v chr", "")
  sl = mw.ustring.gsub(sl, " vor christus", "")
  sl = mw.ustring.gsub(sl, " bce", "")
  sl = mw.ustring.gsub(sl, " bc", "")
  sl = trim(sl)
  return era, sl
end

-- Flexibles Datums-Parsing (dd.mm.yyyy | yyyy-mm-dd | "Tag Monat Jahr" | "Monat Jahr" | "Jahr")
local function parse_date_flexible_raw(s)
  -- dd.mm.yyyy
  local d, m, y = mw.ustring.match(s, "^(%d%d?)%s*%.%s*(%d%d?)%s*%.%s*(%d+)$")
  if d and m and y then return d, m, y end
  -- yyyy-mm-dd
  local y2, m2, d2 = mw.ustring.match(s, "^(%d+)%-(%d%d?)%-(%d%d?)$")
  if y2 and m2 and d2 then return d2, m2, y2 end
  -- Tag Monat Jahr
  local dd, mname, yy = mw.ustring.match(s, "^(%d+)%s*%.?%s*(%S+)%s+(%d+)$")
  if dd and mname and yy then return dd, mname, yy end
  -- Monat Jahr
  local mname2, yy2 = mw.ustring.match(s, "^(%S+)%s+(%d+)$")
  if mname2 and yy2 then return nil, mname2, yy2 end
  -- Jahr
  local yy3 = mw.ustring.match(s, "^(%d+)$")
  if yy3 then return nil, nil, yy3 end
  return nil, nil, nil
end

-- Komponenten aus frei eingegebenem Datum gewinnen
local function parse_flexible_input(datum)
  local era, cleaned = detectEraAndCleanRaw(datum or "")
  local normalized = replace_umlauts(cleaned)
  local d, mname, y = parse_date_flexible_raw(normalized)
  if not y then return nil end
  local ynum = tonumber(y) or 0
  local mnum = 0
  if mname then
    local asNum = tonumber(mname)
    mnum = asNum or month_to_num(mname) or 0
  end
  local dnum = d and tonumber(d) or 0
  return era, ynum, mnum, dnum
end

local function prettyDate(era, y, m, d)
  local eraLabel = (era == 0) and " v. Chr." or " n. Chr."
  if (d or 0) > 0 and (m or 0) >= 1 and m <= 12 then
    return string.format("%d. %s %d%s", d, monatsNamen[m], y, eraLabel)
  elseif (m or 0) >= 1 and m <= 12 then
    return string.format("%s %d%s", monatsNamen[m], y, eraLabel)
  else
    return string.format("%d%s", y, eraLabel)
  end
end

-- Kennung aus Datumsstring (liefert code, era, y, m, d)
local function makeKennungFromDateString(datum, nummer)
  local era, y, m, d = parse_flexible_input(datum or "")
  if not era or not y or y == 0 then return "Fehler: Ungültiges Datumsformat" end
  local code = kennung_parts_from(y, m or 0, d or 0, era, nummer or "00")
  if not code then return "Fehler: Ungültige Jahreszahl" end
  return code, era, y, m, d
end

2) Öffentliche API für Werkseiten: kennung, titel, cat*

-- ===== Zusätzliche Parser/Helfer für Werkseiten =====

local function replace_umlauts(s)
  if not s or s == "" then return s end
  local m = { ["Ä"]="Ae", ["ä"]="ae", ["Ö"]="Oe", ["ö"]="oe", ["Ü"]="Ue", ["ü"]="ue", ["ß"]="ss" }
  for k,v in pairs(m) do s = mw.ustring.gsub(s, k, v) end
  return s
end

-- Era erkennen (Minuszeichen vorn, v chr, vor christus, bce, bc); Rückgabe 1=n. Chr., 0=v. Chr.
local function detectEraAndCleanRaw(s)
  if not s or s == "" then return 1, s end
  local era = 1
  local sl = mw.ustring.lower(s)
  sl = mw.ustring.gsub(sl, "%.", " ")
  sl = trim(sl)
  if mw.ustring.match(sl, "^%-")
     or mw.ustring.find(sl, " v chr")
     or mw.ustring.find(sl, " vor christus")
     or mw.ustring.find(sl, " bce")
     or mw.ustring.find(sl, " bc") then
    era = 0
  end
  sl = mw.ustring.gsub(sl, "^%-", "")
  sl = mw.ustring.gsub(sl, " v chr", "")
  sl = mw.ustring.gsub(sl, " vor christus", "")
  sl = mw.ustring.gsub(sl, " bce", "")
  sl = mw.ustring.gsub(sl, " bc", "")
  sl = trim(sl)
  return era, sl
end

-- Flexibles Datums-Parsing (dd.mm.yyyy | yyyy-mm-dd | "Tag Monat Jahr" | "Monat Jahr" | "Jahr")
local function parse_date_flexible_raw(s)
  -- dd.mm.yyyy
  local d, m, y = mw.ustring.match(s, "^(%d%d?)%s*%.%s*(%d%d?)%s*%.%s*(%d+)$")
  if d and m and y then return d, m, y end
  -- yyyy-mm-dd
  local y2, m2, d2 = mw.ustring.match(s, "^(%d+)%-(%d%d?)%-(%d%d?)$")
  if y2 and m2 and d2 then return d2, m2, y2 end
  -- Tag Monat Jahr
  local dd, mname, yy = mw.ustring.match(s, "^(%d+)%s*%.?%s*(%S+)%s+(%d+)$")
  if dd and mname and yy then return dd, mname, yy end
  -- Monat Jahr
  local mname2, yy2 = mw.ustring.match(s, "^(%S+)%s+(%d+)$")
  if mname2 and yy2 then return nil, mname2, yy2 end
  -- Jahr
  local yy3 = mw.ustring.match(s, "^(%d+)$")
  if yy3 then return nil, nil, yy3 end
  return nil, nil, nil
end

-- Komponenten aus frei eingegebenem Datum gewinnen
local function parse_flexible_input(datum)
  local era, cleaned = detectEraAndCleanRaw(datum or "")
  local normalized = replace_umlauts(cleaned)
  local d, mname, y = parse_date_flexible_raw(normalized)
  if not y then return nil end
  local ynum = tonumber(y) or 0
  local mnum = 0
  if mname then
    local asNum = tonumber(mname)
    mnum = asNum or month_to_num(mname) or 0
  end
  local dnum = d and tonumber(d) or 0
  return era, ynum, mnum, dnum
end

local function prettyDate(era, y, m, d)
  local eraLabel = (era == 0) and " v. Chr." or " n. Chr."
  if (d or 0) > 0 and (m or 0) >= 1 and m <= 12 then
    return string.format("%d. %s %d%s", d, monatsNamen[m], y, eraLabel)
  elseif (m or 0) >= 1 and m <= 12 then
    return string.format("%s %d%s", monatsNamen[m], y, eraLabel)
  else
    return string.format("%d%s", y, eraLabel)
  end
end

-- Kennung aus Datumsstring (liefert code, era, y, m, d)
local function makeKennungFromDateString(datum, nummer)
  local era, y, m, d = parse_flexible_input(datum or "")
  if not era or not y or y == 0 then return "Fehler: Ungültiges Datumsformat" end
  local code = kennung_parts_from(y, m or 0, d or 0, era, nummer or "00")
  if not code then return "Fehler: Ungültige Jahreszahl" end
  return code, era, y, m, d
end

Ergebnis

  • #invoke:AufEinWortDatumKennung|catED (bzw. catBD/catUD/catGD/catSD) erzeugt genau einen Kategorie-Eintrag mit lesbarem Titel und Pipetext = Kennung + Token – wie von dir gewünscht (keine Stern-Eltern auf Werkseiten).
  • #invoke:…|titel liefert den lesbaren Kategorietitel für sichtbare Links.
  • #invoke:…|kennung liefert weiterhin die numerische Kennung für deine Semantik-Properties, inkl. Fehlerfall bei falschen Datumsangaben.

Wichtig: Achte darauf, dass deine Werkseiten-Vorlage wirklich #invoke:AufEinWortDatumKennung|…aufruft (korrekter Modulname) – dann verschwinden die „Funktion nicht vorhanden“-Fehler.

Wenn du das eingefügt hast, sollte deine bisherige Werkseiten-Syntax sofort funktionieren:

  • Datum wird geprüft → Kennung gesetzt → Kategorie (lesbar) hinzugefügt → sichtbarer Link zeigt dieselbe Kategorie (mit führendem :).

Danke habe ich eingefügt und die Scriptfehler sind weg.

Ich habe die beiden Blöcke auch im Canvas eingefügt.

Aufgrund der Zeile " if not code or (type(code)=="string" and code:sub(1,1)=="F") then return "unbekannt" end" wird mir bei einem Werk nun nicht das Datum des Werk sondern "unbekannt" angezeigt.

Wahrscheinlich, weil ich kein Geburtsdatum oder Sterbedatuim gesetzt habe?

Diese verwende ich  nur, wenn es sich um eine Wikiseite zu einer Persönlichkeit handelt und ich dort das ModulAufEinWortDatumKennung für die Erfassung der Personendaten verwende.

Wenn nicht Sterbedatum oder Geburtsdatum der Fehler ist hier folgend wie ich Erstellungsdatum in der Wikiseite und in der Vorlage gegenwärtig setze und verwende:

Ich schreibe aber überall Erstellungsdatum – in der Vorlage und in der Wikiseite

|Erstellungsdatum=23. Mai 2023

| {{TabelleZeile.css}} | {{#if: {{{Erstellungsdatum|}}} | [[hat Erstelldatum::{{{Erstellungsdatum}}}| ]] [[hat Kennung Erstelldatum::{{#invoke:AufEinWortDatumKennung|kennung|Erstellungsdatum={{{Erstellungsdatum|}}}|Nummer={{{Nummer|00}}}}}| ]]{{#invoke:AufEinWortDatumKennung|catED|Erstellungsdatum={{{Erstellungsdatum|}}}|Nummer={{{Nummer|00}}}|parents=0|jh=0}} [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel|Token=ED|Erstellungsdatum={{{Erstellungsdatum|}}}}}|{{#invoke:AufEinWortDatumKennung|titel|Token=ED|Erstellungsdatum{{{Erstellungsdatum|}}}}}]] | }}
|-

Ich muß die Syntax so "zusammenschieben" da eine pipe "|" sonst als Feld oder Zeile von der Tabelle interpretiert wird.

Überprüfe dies bitte.

der Grund für „unbekannt“ ist in deinem Snippet ein Tippfehler

Nachgedacht
Es scheint, dass das Problem durch das Fehlen eines "="-Zeichens im zweiten Aufruf von #invoke:AufEinWortDatumKennung|titel verursacht wird. Das führt dazu, dass das Datum nicht korrekt übergeben wird und daher „unbekannt“ angezeigt wird. Ich denke auch, dass zusätzliche Leerzeichen oder NBSP vor der Pipe ein Problem verursachen könnten.

Es scheint, dass der Hauptfehler durch das fehlende "=" im letzten Aufruf verursacht wird. Das führt dazu, dass "unbekannt" angezeigt wird. Auch der Fehler tritt auf, wenn der Code mit 'F' oder "nil" startet. Ich werde dann einen korrigierten Code-Snippet entwerfen, der auf die richtige Handhabung von Pipes achtet, um Tabellenbrüche zu vermeiden.

Die Ursache für "unbekannt" war das fehlende "=" im zweiten #invoke-Aufruf. Auch die Kategorielinks funktionieren innerhalb der Tabellenzeilen, was kein Problem darstellt. Der param Namen für „kennung“ wird korrekt überprüft, und ich werde nun eine klare Antwort liefern: 1) Diagnose des Fehlers; 2) Korrigierte Zeile; 3) Kein 'n' erforderlich.

Ich muss darauf hinweisen, dass die Kategorie-Link-Syntax das "=" benötigt, um korrekt zu funktionieren. Außerdem sollten potenzielle Probleme mit NBSP berücksichtigt werden. Ich werde eine kompakte Korrektur für die Tabellenzeile vorschlagen, mit sicheren Pipes und der Empfehlung, den Kategorien-Link außerhalb der Zelle zu platzieren, falls nötig.

Fertig

Gut gesehen – der Grund für „unbekannt“ ist in deinem Snippet ein Tippfehler im zweiten titel-Aufruf (fehlendes =nach Erstellungsdatum). Damit bekommt die Funktion kein Datum und fällt auf „unbekannt“ zurück.

Ersetze in deiner Tabellenzeile nur den sichtbaren Link-Teil (die beiden titel-Aufrufe), so:

[[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel
 | Token=ED
 | Erstellungsdatum={{{Erstellungsdatum|}}}
}}|{{#invoke:AufEinWortDatumKennung|titel
 | Token=ED
 | Erstellungsdatum={{{Erstellungsdatum|}}}
}}]]

Dein kompletter ED-Block (in einer Tabellenzelle) sollte damit so aussehen und funktioniert mit „23. Mai 2023“:

{{#if: {{{Erstellungsdatum|}}} |
 [[hat Erstelldatum::{{{Erstellungsdatum}}}| ]]
 [[hat Kennung Erstelldatum::{{#invoke:AufEinWortDatumKennung|kennung
   | Erstellungsdatum={{{Erstellungsdatum|}}}
   | Nummer={{{Nummer|00}}}
 }}| ]]

 {{#invoke:AufEinWortDatumKennung|catED
   | Erstellungsdatum={{{Erstellungsdatum|}}}
   | Nummer={{{Nummer|00}}}
   | parents=0
   | jh=0
 }}

 [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel
   | Token=ED
   | Erstellungsdatum={{{Erstellungsdatum|}}}
 }}|{{#invoke:AufEinWortDatumKennung|titel
   | Token=ED
   | Erstellungsdatum={{{Erstellungsdatum|}}}
 }}]]
| }}

Kurze Checks:

  • Für Werkseiten braucht titel kein „n. Chr.“ im Eingabedatum – der Werk-Parser akzeptiert „23. Mai 2023“ direkt.
  • Die Kategoriezuweisung macht catED (kein führender Doppelpunkt), der sichtbare Link hat bewusst einen führenden :, damit er nur anzeigt, nicht kategorisiert.
  • Falls du in anderen Blöcken (BD/UD) auch „unbekannt“ siehst: prüfe dort ebenfalls auf ein fehlendes = bei Erstellungsdatum|…, Bearbeitungsdatum|…, Urwerkdatum|….

Wenn das sitzt, solltest du im Seitenrendering die lesbare Datumskategorie sehen und in den Semantik-Properties die Kennung – inkl. Fehlerschutz bei Tippfehlern wie „Mau“.

ich hab das fehlende = am Ende gefunden.

Leider kann ich eine deine klar strukturierte  Syntax nicht direkt übernehmen. Wenn ich in einer Zeile am Anfang in ein Leerzeichen haben, macht Wikitext daraus einen Codeblock und wenn ich eine pipe am Anfang habe, eine Zelle, daher muß ich das so umgestallten, daß es wie eine Zeile ohne Zeilenumbruch ist.

Das Datum wird jetzt richtig in der Tabelle angezeigt und der Vorteil, ich  kann damit nun direkt die Kategorieseite aufrufen und muß nicht unter den vielen vergebenen Kategorien diese raussuchen.

Datumskategorie bequem direkt anspringen

Nachgedacht
Es scheint, dass das Problem durch das Fehlen eines "="-Zeichens im zweiten Aufruf von #invoke:AufEinWortDatumKennung|titel verursacht wird. Das führt dazu, dass das Datum nicht korrekt übergeben wird und daher „unbekannt“ angezeigt wird. Ich denke auch, dass zusätzliche Leerzeichen oder NBSP vor der Pipe ein Problem verursachen könnten.

Es scheint, dass der Hauptfehler durch das fehlende "=" im letzten Aufruf verursacht wird. Das führt dazu, dass "unbekannt" angezeigt wird. Auch der Fehler tritt auf, wenn der Code mit 'F' oder "nil" startet. Ich werde dann einen korrigierten Code-Snippet entwerfen, der auf die richtige Handhabung von Pipes achtet, um Tabellenbrüche zu vermeiden.

Die Ursache für "unbekannt" war das fehlende "=" im zweiten #invoke-Aufruf. Auch die Kategorielinks funktionieren innerhalb der Tabellenzeilen, was kein Problem darstellt. Der param Namen für „kennung“ wird korrekt überprüft, und ich werde nun eine klare Antwort liefern: 1) Diagnose des Fehlers; 2) Korrigierte Zeile; 3) Kein 'n' erforderlich.

Ich muss darauf hinweisen, dass die Kategorie-Link-Syntax das "=" benötigt, um korrekt zu funktionieren. Außerdem sollten potenzielle Probleme mit NBSP berücksichtigt werden. Ich werde eine kompakte Korrektur für die Tabellenzeile vorschlagen, mit sicheren Pipes und der Empfehlung, den Kategorien-Link außerhalb der Zelle zu platzieren, falls nötig.

Fertig

(16. Sep. 2025, 11:52)

Klingt gut — freut mich, dass es jetzt auf den Werkseiten sauber läuft und du die Datumskategorie bequem direkt anspringen kannst. ✅

Mini-Checkliste (optional, nur zur Sicherheit):

  • catED/BD/UD auf Werkseiten stets mit parents=0 und jh=0 (damit nur die Tages-Kat gesetzt wird).
  • Nummer zweistellig (00, 01, …) – sonst stimmt der Sortierschlüssel nicht.
  • Eingaben wie „23.5.2023“, „2023-05-23“, „23. Mai 2023“ und „425 v. Chr.“ funktionieren (BCE getestet?).
  • Auf Kategorieseiten wird DEFAULTSORT per Parserfunktion gesetzt (nichts Rotes sichtbar).

Wenn du möchtest, schreibe ich dir deine drei Datumsblöcke (ED/BD/UD) als kompakte Ein-Zeiler-Varianten, die tabellenfreundlich sind (keine führenden Pipes/Spaces, kein Zeilenumbruch) – dann kannst du sie 1:1 in deine Zellen kleben. Soll ich?

"klebbare" Ein-Zeiler-Varianten

Danke soweit für deine Unterstützung.

Ich muß jetzt alles umbauen und BCE hatte ich zuvor mal getestet und werde es sobald erneut testen, wenn ich einen Fall habe oder finde.

Dann schreibe mir die "klebbaren" Ein-Zeiler-Varianten, du kannst das besser.

tabellenfeste Ein-Zeiler

Nachgedacht
Der Nutzer benötigt Ein-Zeilen-Varianten ohne führende Leerzeichen oder Pipes und ohne Zeilenumbrüche für ED/BD/UD (und ggf. GD/SD). Diese Ein-Zeiler müssen in eine Tabellezeile passen und für die Semantic MediaWiki-Formatierung genutzt werden. Also werde ich sicherstellen, dass alle Code-Snippets in einer kompakten, einzigen Zeile zusammengesetzt sind.

Ich muss sicherstellen, dass der Code-Text mit keine führenden Leerzeichen oder Pipes beginnt, da das in Wikitext zu Problemen führen würde. Der Nutzer möchte dies als Ein-Zeilen-Code verwenden, den sie dann problemlos in Zellen einfügen können. Ich werde den Code dann als Block anzeigen, ohne diese problematischen Zeichen am Anfang.

Ich werde sicherstellen, dass der Code als Einzeiler mit Hilfe von Triple-Backticks korrekt angezeigt wird. Dabei achte ich darauf, dass alle Template-Parameter wie {{{ }}} richtig sind. Zusätzlich werde ich BD, UD und optionale GD, SD ermöglichen. Es ist wichtig, dass die Parameteranpassungen richtig sind und Funktionen wie #invoke|kennung korrekt aufgerufen werden.

Fertig

(16. Sep. 2025, 11:58)

Sehr gern — hier sind tabellenfeste Ein-Zeiler (keine führenden Leerzeichen, keine Zeilenumbrüche), die du direkt in eine Tabellenzelle nach dem | kleben kannst. Jeder Ein-Zeiler setzt:

  • das Semantik-Property (Datum),
  • das Semantik-Property (Kennung),
  • die lesbare Datumskategorie (nur Tages-Kat; keine Eltern, kein Jh.),
  • einen sichtbaren Link zur Datumskategorie (mit führendem :).

ED (Erstellungsdatum)

{{#if:{{{Erstellungsdatum|}}}|[[hat Erstelldatum::{{{Erstellungsdatum}}}| ]] [[hat Kennung Erstelldatum::{{#invoke:AufEinWortDatumKennung|kennung|Erstellungsdatum={{{Erstellungsdatum|}}}|Nummer={{{Nummer|00}}}}}| ]] {{#invoke:AufEinWortDatumKennung|catED|Erstellungsdatum={{{Erstellungsdatum|}}}|Nummer={{{Nummer|00}}}|parents=0|jh=0}} [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel|Token=ED|Erstellungsdatum={{{Erstellungsdatum|}}}}}|{{#invoke:AufEinWortDatumKennung|titel|Token=ED|Erstellungsdatum={{{Erstellungsdatum|}}}}}]]|}}

BD (Bearbeitungsdatum)

{{#if:{{{Bearbeitungsdatum|}}}|[[hat Bearbeitungsdatum::{{{Bearbeitungsdatum}}}| ]] [[hat Kennung Bearbeitungsdatum::{{#invoke:AufEinWortDatumKennung|kennung|Bearbeitungsdatum={{{Bearbeitungsdatum|}}}|Nummer={{{Nummer|00}}}}}| ]] {{#invoke:AufEinWortDatumKennung|catBD|Bearbeitungsdatum={{{Bearbeitungsdatum|}}}|Nummer={{{Nummer|00}}}|parents=0|jh=0}} [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel|Token=BD|Bearbeitungsdatum={{{Bearbeitungsdatum|}}}}}|{{#invoke:AufEinWortDatumKennung|titel|Token=BD|Bearbeitungsdatum={{{Bearbeitungsdatum|}}}}}]]|}}

UD (Urwerkdatum)

{{#if:{{{Urwerkdatum|}}}|[[hat Urwerkdatum::{{{Urwerkdatum}}}| ]] [[hat Kennung Urwerkdatum::{{#invoke:AufEinWortDatumKennung|kennung|Urwerkdatum={{{Urwerkdatum|}}}|Nummer={{{Nummer|00}}}}}| ]] {{#invoke:AufEinWortDatumKennung|catUD|Urwerkdatum={{{Urwerkdatum|}}}|Nummer={{{Nummer|00}}}|parents=0|jh=0}} [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel|Token=UD|Urwerkdatum={{{Urwerkdatum|}}}}}|{{#invoke:AufEinWortDatumKennung|titel|Token=UD|Urwerkdatum={{{Urwerkdatum|}}}}}]]|}}

GD (Geburtsdatum) – falls Personenseiten

{{#if:{{{Geburtsdatum|}}}|[[hat Geburtsdatum::{{{Geburtsdatum}}}| ]] [[hat Kennung Geburtsdatum::{{#invoke:AufEinWortDatumKennung|kennung|Geburtsdatum={{{Geburtsdatum|}}}|Nummer={{{Nummer|00}}}}}| ]] {{#invoke:AufEinWortDatumKennung|catGD|Geburtsdatum={{{Geburtsdatum|}}}|Nummer={{{Nummer|00}}}|parents=0|jh=0}} [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel|Token=GD|Geburtsdatum={{{Geburtsdatum|}}}}}|{{#invoke:AufEinWortDatumKennung|titel|Token=GD|Geburtsdatum={{{Geburtsdatum|}}}}}]]|}}

SD (Sterbedatum) – falls Personenseiten

{{#if:{{{Sterbedatum|}}}|[[hat Sterbedatum::{{{Sterbedatum}}}| ]] [[hat Kennung Sterbedatum::{{#invoke:AufEinWortDatumKennung|kennung|Sterbedatum={{{Sterbedatum|}}}|Nummer={{{Nummer|00}}}}}| ]] {{#invoke:AufEinWortDatumKennung|catSD|Sterbedatum={{{Sterbedatum|}}}|Nummer={{{Nummer|00}}}|parents=0|jh=0}} [[:Kategorie:{{#invoke:AufEinWortDatumKennung|titel|Token=SD|Sterbedatum={{{Sterbedatum|}}}}}|{{#invoke:AufEinWortDatumKennung|titel|Token=SD|Sterbedatum={{{Sterbedatum|}}}}}]]|}}

Hinweise:

  • Nummer bleibt zweistellig (00, 01, …).
  • Die sichtbare Verlinkung auf die Datumskategorie hat führenden Doppelpunkt : und kategorisiert daher nichtdoppelt.
  • BCE-Eingaben wie 425 v. Chr. funktionieren in den Ein-Zeilern identisch wie CE.

Danke das was wir erreicht haben ist eine gute Arbeitsgrundlage

– Danke dafür.

Nur noch ein kleines dazu.… ( weiter mit: Kategorien Hierarchiestruktur gegen Sternstruktur)

Abgerufen von „https://aufeinwort.info/w/index.php?title=Gespräch:Datumsortierung_Modul_AufEinWortSeiteKennung&oldid=149867“