Wikipedia Diskussion:Lua/Modul/Vorlage:Personendaten

Vorlagenprogrammierung	Diskussionen	Lua		Unterseiten
		Modul	Deutsch	Modul:	Dokumentation

Erkennung römischer Zahlen für Lemma und NAME von Personen (hierher verschoben von Hilfe Diskussion:Personendaten)

(Später als geplant, dafür besser und aktueller.)

Das folgende Verfahren soll für die deutschsprachige WP die Unterscheidung zwischen römischen Zahlen und ebenso aussehenden Buchstabenfolgen ermöglichen, soweit dies zur automatischen Erzeugung einer regelkonformen SORTIERUNG benötigt wird. Es ist nur für Artikel über Personen gedacht, genauer, für solche, die die Vorlage Personendaten enthalten. Das Verfahren basiert auf dem Dump der deutschsprachigen WP vom 1. Dezember 2016, auf den sich auch alle Zahlen beziehen. Überraschenderweise gelingt die Unterscheidung fast immer. Eine nach diesem Verfahren erzeugte SORTIERUNG würde in künftigen neuen Fällen zwar nicht immer regelkonform sein, wohl aber deutlich häufiger, als das bisher in den manuell erzeugten Angaben der Fall ist.

Als Basis für das Verfahren musste für die betreffenden Artikel bestimmt werden, ob entsprechende Zeichenketten römische Zahlen sind. Dabei können Fehler unterlaufen sein, etwa bei Prince Far I, wo das 'I' als Buchstabe bestimmt wurde.

Als Daten werden benötigt:

das Lemma

die Angabe NAME der Personendaten

die Angabe KURZBESCHREIBUNG der Personendaten

die Angabe GEBURTSDATUM der Personendaten

Es zeigte sich, dass die Untersuchung des Lemmas in der Regel geeigneter ist als die von NAME, da NAME häufiger als das Lemma willkürlich und oft nicht regelkonform angesetzt worden ist. (Wobei die Regeln dafür ohnehin wenig durchsichtig sind und auch nicht alle Fälle erfassen.)

Als potentielle römische Zahl ('PRZ') gelte hier eine nichtleere Folge der Zeichen 'I', 'V', 'X', 'L', die links und rechts begrenzt wird von [^A-Za-zż0-9’-] (d.h. keinem der angegebenen Zeichen), dabei sollen Anfang und Ende der Zeichenkette wie Leerzeichen behandelt werden. ('ż' wurde extra aufgeführt, da es aus mir unbekanntem Grund in meinem System nicht wie die anderen Buchstaben mit diakritischen Zeichen von 'a-z' erfasst wird.)

Die römischen Ziffern 'C', 'D', 'M' sind in NAME und zugehörigem Lemma nicht zu erwarten. Jedenfalls kommen sie bisher nicht vor. Personennummerierungen gibt es bis 'Heinrich LXXV.', in existierenden Artikeln bisher bis Heinrich LXXII.

Es gibt 8669 derartige Artikel mit PRZ, davon enthalten 3984 PRZ, die nur ein Zeichen enthalten ('PRZ-kurz'), 4698 solche mit mehreren Zeichen ('PRZ-lang').

Von den PRZ-lang haben zwei (LL Cool J, VV Brown) nicht die Form korrekter röm. Zahlen, es sind Buchstabenfolgen. Als korrekt gebildete röm. Zahlen gelten dabei auch Formen mit 'IIII' (ein Vorkommen: Charles Vilain XIIII) oder 'XXXX' (kein Vorkommen zur Zeit).

Von den 4696 PRZ-lang, welche die Form korrekter röm. Zahlen haben, sind 4692 wirklich solche Zahlen. Es gibt vier Fälle, bei denen Buchstabenfolgen vorliegen:

Chino XL

Junkie XL

Sha Money XL

LX (Rapper)

In allen diesen vier Fällen hat NAME die Form des Lemmas (bis auf die Klammer).

Derartige Buchstabenfolgen können erkannt werden durch folgende Regeln:

Eine PRZ am Anfang des Lemmas ist eine Buchstabenfolge;

Eine 'L' enthaltende PRZ-lang ohne folgenden Punkt, der nicht 'Heinrich' oder 'Günther' vorangeht, ist eine Buchstabenfolge.

(Statt der zweiten Regel würde vermutlich auch die einfachere

Eine PRZ-lang 'XL' am Ende des Lemmas (ohne folgenden Punkt) ist eine Buchstabenfolge.

das Nötige tun.)

Von den 3984 PRZ-kurz bestehen 901 aus dem Zeichen 'L'. Es handelt sich in allen Fällen um den Buchstaben. Ein eventueller späterer Artikel, in dem ein solches 'L' die Ziffer bedeutet, sollte ein Lemma der Form

Heinrich L.

oder

Heinrich L. ...Reuß...

und das entsprechende NAME-Feld ebenfalls eine dieser Formen oder aber die Form

...Reuß... Heinrich L.

haben.

'L' werde im weiteren nicht mehr berücksichtigt. Für das Zeichen ('I', 'V' oder 'X'), für welches zwischen 'Buchstabe' und 'Ziffer' zu entscheiden ist, werde im weiteren '§' verwendet.

Von den verbliebenen 3083 Fällen entscheidet die Position für '§ ist Buchstabe' in

68 Fällen - § steht vor oder hinter einer anderen Abkürzung, also '§.G.' oder '§. G.' oder 'G.§.' oder 'G. §.', wo 'G' einen beliebigen Großbuchstaben bezeichnet

18 Fällen - § steht am Anfang des Lemmas

5 Fällen - § steht am Anfang von NAME

2 Fällen - § steht in NAME direkt hinter einem Komma

In weiteren 2 Fällen liegt ein Buchstabe vor, da das Lemma eine der Angaben 'junior', 'senior', 'Jr.' oder 'Sr.' enthält.

Von den verbliebenen 2988 Fällen enthält NAME in 2427 Fällen kein Komma. In 2417 dieser Fälle ist § eine Ziffer, in folgenden 10 Fällen aber ein Buchstabe:

Florencia de la V

Marco V

Mia X

Michael X

Sadat X

Terminator X

Xindl X

Ziggy X

sowie

Prince Far I

Platon V. Kornyljak (mit regelwidriger Ansetzung von NAME identisch mit dem Lemma)

Der NAME ist in diesen zehn Fällen mit dem Lemma identisch.

Die Ausnahmen sind zunächst genau die 8 der 2427 Fälle, in denen auf 'V' oder 'X' kein Punkt folgt. Dies ist als Regel zu ihrer Erkennung geeignet. Eventuell mit der Zusatzforderung, dass dieses Zeichen am Lemmaende steht.

Hinzu kommt Platon V. Kornyljak. Das Verfahren würde hier - mit falscher Eingabeinformation versorgt - ein falsches Resultat liefern.

Hinzu kommt weiter

Prince Far I (jamaikanischer Musikproduzent; geb. 1944; gest. 1983)

Die anderen Artikel, in denen das Lemma auf 'I' (ohne Punkt) endet, sind:

American Horse I (indianischer Häuptling ...; geb. um 1830; gest. 1876)

Askia Mohammad I (Herrscher des Songhaireichs; geb. um 1443; gest. 1538)

Crooked I (US-amerikanischer Rapper; geb. 1978; gest. -)

Gruffydd Maelor I (Fürst von Powys (Wales); geb. 12. Jh.; gest. 1191)

Moorleiche von Lindow I (englische Moorleiche)

Moorleiche von Windeby I (Moorleiche)

Shukr Kuhayl I (jemenitischer Falscher Messias; geb. 1821; gest. 1865)

Kriterien zur Unterscheidung von den meisten dieser Fälle sind vorstellbar, kaum aber von Crooked I. Hier hilft wohl nur eine Einzelfallbehandlung von Prince Far I, wobei mögliche Fehlentscheidungen für künftige gleichartige Fälle in Kauf genommen werden.

Es verbleiben 561 Fälle mit einem Komma in NAME.

Es liegt ein Buchstabe vor, wenn im Lemma auf § unmittelbar einer der folgenden 'Bürgerpräfixe' folgt:

De (2 Fälle: John I. De Graff, Lorenzo I. De Leon Guerrero)

Le (1 Fall: John V. Le Moyne)

Van (1 Fall: James I. Van Alen)

du (2 Fälle: Alfred I. du Pont, Alexis I. du Pont Bayard)

(Die Regel ist zugegebenermaßen nicht ohne Willkür, vor allem bzgl. 'du'.)

Mit einer Ausnahme, für die keine Regel offensichtlich ist, bei der ein Buchstabe vorliegt:

Haskell V. Anderson III

liegt bei allen 252 restlichen Fällen, bei denen das Lemma nicht die Form

'vorname §. nachname' oder 'vorname § nachname'

d. h. formal

[^ ]* [IVX]\.* [A-Z][^ ]*

hat, eine Ziffer vor. (Für Haskell V. Anderson III ist wohl wieder eine Einzelfallbehandlung angebracht.)

Es verbleiben 302 Fälle mit der Form 'vorname §. nachname' oder 'vorname § nachname'. Es folgen jetzt Zahlen und Beispiele getrennt zu den drei Fällen §='I', 'V' und 'X'. Es zeigte sich jedoch, dass das unten angegebene Verfahren für alle diese Fälle funktioniert, es kann also unabhängig vom Wert von § verwendet werden.

In 13 Fällen ist §='X', in diesen Fällen ist das X immer ein Buchstabe.

In 145 Fällen ist §='V'. 8-mal ist V eine Ziffer, 135-mal sicher ein Buchstabe, 2-mal:

Keith V. Roberts

Paavo V. Komi

wahrscheinlich ein Buchstabe. Es werde im weiteren angenommen, dass in diesen Fällen ein Buchstabe vorliegt.

In 144 Fällen ist §='I'. 55-mal ist I eine Ziffer, 76-mal sicher ein Buchstabe, 13-mal:

Charles I. Dawson

Christopher I. Beckwith

Duncan I. Steel

Floyd I. Clarke

Froma I. Zeitlin

Harold I. Goss

Henry I. Miller

Ion I. Câmpineanu

John I. Slingerland

Lawrence I. Feinberg

Peter I. Blute

Robert I. Sutton

William I. Robinson

wahrscheinlich ein Buchstabe. Es werde im weiteren angenommen, dass in diesen Fällen ein Buchstabe vorliegt.

Weitere Entscheidungen sind hier ohne zusätzliche Information wie die KURZBESCHREIBUNG oder die Lebensdaten kaum möglich. Mit diesen gelingen sie aber. Es zeigt sich, dass mit abgekürzten Mittelnamen etwa ab Geburtsdatum 1750 zu rechnen ist. Ein frühes Beispiel ist (allerdings mit 'L') William L. Smith (1758-1812). Die Nummerierung läuft, außer für Patriarchen, im 19. Jahrhundert weitgehend aus. Es gibt also eine breite Übergangszone. Glücklicherweise sind die meisten Buchstaben-Fälle der Übergangszone an 'US-amerikanisch' in der KURZBESCHREIBUNG zu erkennen. Unter den (für §='I') 64 Fällen ohne 'US-amerikanisch' ist Ion I. Câmpineanu (1841-1888) der älteste, bei dem ein Buchstabe vorliegt. (Mit §='V' ist es George V. Wulff (1863-1925), mit §='X' William X. O’Brien (1881-1968).) Sándor I. Csajághy (1810-1860) ist der jüngste mit einer Ziffer. Die Fälle sind also durch das Geburtsdatum unterscheidbar. Es ergibt sich:

Wenn KURZBESCHREIBUNG die Zeichenkette 'US-amerikanisch' enthält (77 Fälle für §='I'), liegt ein Buchstabe vor, mit allerdings einer Ausnahme:

James I. Roosevelt (1795-1875);

diese erfordert wohl wieder eine Einzelfallbehandlung.

Wenn KURZBESCHREIBUNG die Zeichenkette 'Patriarch' enthält (3 Fälle für §='I'), liegt eine Ziffer vor.

Wenn das Geburtsdatum <= 1810 ist, liegt eine Ziffer vor, andernfalls ist es ein Buchstabe. (Dabei gelte auch die Angabe '19. Jahrhundert' als > 1810, was allerdings zur Zeit nicht benötigt wird und auch geändert werden kann.)

Damit sind alle zum 1. Dezember 2016 existierenden Fälle entschieden. Allerdings war 3-mal eine Einzelfallbehandlung notwendig. Ein Fall (Platon V. Kornyljak) führt zu einer falschen Entscheidung, da und solange die Eingabeinformation falsch ist.

Anmerkung: Der zuletzt auftretende Wert 1810 könnte herabgesetzt werden, wenn einige der jüngeren Ziffern-Fälle ebenso wie 'Patriarch' durch Test der KURZBESCHREIBUNG auf enthaltene Zeichenketten 'Bischof', 'Hofgärtner', usw. vorher abgefangen werden. Für eine eventuelle derartige Entscheidung hier die Liste aller zur Zeit vorhandenen Fälle mit 'I' (es gibt keine mit 'V' oder 'X'), deren Lebensspanne bis ins 18. oder 19. Jahrhundert reicht, alle mit Ziffer:

Sándor I. Csajághy - Bischof des Csanáder Bistums; geb. 1810; gest. 1860

Theodor I. Nietner - deutscher Hofgärtner; geb. 1790; gest. 1871

Eduard I. Nietner - Königlicher Hofgärtner ...; geb. 1769; gest. 1859

Berend I Roosen - Hamburger Reeder und Mennonit; geb. 1705; gest. 1788

Nikolaus I. Bernoulli - Schweizer Mathematiker; geb. 1687; gest. 1759

Wilhelm I. Sölner - deutscher Zisterzienserabt; geb. 1671; gest. 1741

Jakob I. Bernoulli - Schweizer Mathematiker und Physiker; geb. 1655; gest. 1705

Jean I Barraband - französischer Bildwirker; geb. um 1650; gest. 1709

Pierre I Mercier - französischer Bildwirker; geb. um 1650; gest. 1729

Der Fall des Weihbischofs Joseph V. Brennan, geb. 1954, bei dem ein Buchstabe vorliegt, spricht jedoch eher gegen einen Test auf 'Bischof' oder '...bischof' als Kriterium für eine vorliegende Ziffer. Obwohl der Test auf 'US-amerikanisch' in seinem Fall eine Fehlbestimmung verhindern würde. (nachgetragene vergessene Unterschrift: --Griot (Diskussion) 00:41, 17. Jan. 2017 (CET))

Ah, schönen Dank.

Die Auswertung würde praktisch umgesetzt werden dahingehend, dass jeweils in der einstelligen Zahl von Fällen, in denen es zu Irritationen kommt, mitttels eines einmaligen Durchgangs durch den Artikelbestand ein explizites SORTIERUNG= manuell zu setzen ist.

Für das Lua-Modul bedeutet das:

• Lua wird ausschließlich den Parameter NAME= auswerten.
• Enthält NAME= ein Komma, so wird ein bürgerlicher europäischer Name angenommen.
• Gibt es kein Komma, dann wird auf römische Zahlengruppe (aus IVXL) dann und nur dann erkannt, wenn:
  1. vor der Zahlengruppe ein Leerzeichen steht und
  2. wenn dahinter ein Punkt folgt.
• Damit sind zwei Fehlinterpretationen in Lua möglich, für die explizit SORTIERUNG= manuell zu verteilen ist:
  1. Der Name ist bürgerlich, aber statt Buchstaben soll Zahl gesetzt werden.
     • Beispiel: |NAME=Godeffroy, Johan Cesar VI. in Johan Cesar VI. Godeffroy
  2. Der Name ist nicht zentraleuropäisch/bürgerlich, aber statt Zahl soll es beim Buchstaben bleiben.
     • Beispiel: |NAME=T. I. in T.I. oder T. I. – je nachdem, ob grad mit Leerzeichen vor dem I. angesetzt oder nicht, würde das in eine 1 gewandelt werden.
• Lua selbst wird kein Lemma, keine Geburtsjahrgänge und nichts analysieren. Eine hochkomplexe automatische Analyse bei jedem von einer Dreiviertelmillion Einbindungen ist nicht zu vertreten, zumal die Programmierung eines umfangreichen Regelsatzes wie sich weiter oben andeutend permanenter Nachprogrammierung und Wartung bedürfte, um bei Auffinden eines neuen Sonderfalls neue komplexe Regeln zum Abfangen dieser einen Situation von einem Lua-Programmierer eingebaut werden müsste, und das vollgeschützte Modul dann nach erneuter Erprobungsphase durch einen Admin aufgespielt werden müsste, und eine Dreiviertelmillion Artikel neu gerendert werden müssen.

VG --PerfektesChaos 22:00, 21. Dez. 2016 (CET)

Nun, letzlich entscheidet der Programmierer. Allerdings:

1. Das angedeutete Verfahren ist in keiner Weise 'hochkomplex'. Es ist vielmehr überraschend einfach, was leicht zu sehen ist, wenn man alle Erläuterungen streicht. Dazu vielleicht noch für die nur drei Einzelfälle Fehlbestimmungen zuläßt und auf die Antizipation von 'Heinrich L.' verzichtet.
2. Da das GEBURTSDATUM ohnehin analysiert wird, ist wenig klar, warum das hier nicht benutzt werden soll. Eine Zeichenkette in der KURZBESCHREIBUNG zu suchen, ist auch keine Hürde.
3. Wie ich schon schrieb, NAME ist nicht selten verwürgt. Das Lemma hat eine wesentlich einfachere Struktur.
4. Die Anzahl der manuell nachzuarbeitenden Fälle wäre bei Deinem Ansatz nicht einstellig, sondern mindestens im hohen zweistelligen, wenn nicht im dreistelligen Bereich, wenn man annimmt, das der existierende Bestand der Personendaten bearbeitet werden würde.
5. Was 'mittels eines einmaligen Durchgangs durch den Artikelbestand ein explizites SORTIERUNG= manuell zu setzen ist' bedeuten soll, habe ich nicht verstanden.
6. Jede brauchbare Software erfordert Wartung. In diesem Fall sollte es relativ wenig sein, vielleicht wird es im Abstand von etwa zwei Jahren angebracht sein, zu überprüfen, welche neuen Fälle nicht korrekt behandelt werden. Da die Regeln auf der Erfahrung von 8669 Artikeln beruhen, dürften das wenige sein, ich würde in dieser Spanne eher weniger als ein Dutzend, denn mehr erwarten. Das ist mindestens eine Größenordnung weniger, als die zur Zeit existierenden nicht regelkonformen Fälle.
7. Falls der existierende Artikelsatz durchgearbeitet werden soll und nicht nur jeder neue Fall der Personendaten, ist es gleichgültig, ob das Programm 10 oder 50 Zeilen enthält.
8. Wieso bei einer Programmänderung alle existierenden Artikel neu bearbeitet werden sollen, erschließt sich mir nicht.

Es grüßt, --Griot (Diskussion) 00:26, 22. Dez. 2016 (CET)

• Es muss für Lua davon ausgegangen werden, dass NAME= richtig angegeben wurde.
• Relevant sind deshalb nur die Fälle, in denen NAME= korrekt ist, aber nach den simplen Regeln (Komma ja/nein) eine potentelle Zifferngruppe fälschlich als Zahl bzw. nicht als Zahl obwohl bürgerlicher Clan interpretiert würde.
• Die einstellige Anzahl je Konstellation entnehme ich deinen obigen Darlegungen, die auch überhaupt noch nicht in Betracht ziehen, was bei NAME= stünde.
• Wenn hingegen im letzten Jahrzehnt NAME= mal falsch notiert wäre, dann wäre das mit dem existierenden Wartungswerkzeug zu identifizieren und muss sowieso berichtigt werden. Alle anderen Auswertungen verlassen sich schließlich darauf, dass dieser Schlüssel richtig sei; wohl auch APPER zur Sortierung.
  • Wenn also, wie du schreibst, NAME= „nicht selten verwürgt“ sei, dann muss es das ja nicht unbedingt in den Fällen sein, in denen wir uns über richtig oder falsch erkannte römische Zahlen einen Kopf machen, und so total, dass diese beeinflusst würden. Und wenn, dann ist der momentan benutzte Standard-Sortierschlüssel mutmaßlich auch vergeigt.
  • Und im Gesamtziel geht es nur um den als geeignet befundenen Sortierschlüssel; also um die Frage, in welcher Reihenfolge der Name in der Auflistung einer Kategorie stünde, falls es in derselben Kategorie gleichzeitig sehr ähnlich beginnende andere Standard-Sortierschlüssel gäbe. Der Schaden, so es denn einmal falsch wäre und das nach außen hin bemerkt werden kann, wäre geringfügig.
  • Bislang sind in den Artikeln auch Angaben zum Standardsortierschlüssel; es geht um die Fälle, in denen diese Elemente über Jahre hinweg nach und nach entfernt würden und nur der konkurrierende Wert aus der PD-Vorlage gilt. Welcher von beiden wirkt ist ohnehin nicht robust vorhersagbar.
  • Selbst wenn einmal nicht auf angestrebte Erkennung numerischer Daten verzweigt würde, ist es mit Ausnahme der IX. für das Sortierungsergebnis unschädlich; denn I. liegt vor II. kommt vor III. und diese vor IV. und die vor V. und korrekt VI. und VII. und VIII. Auch X. folgt von selbst auf alle vorgenannten, genauso XI. bis XVIII. und wieder richtig ab XX. Selbst IX. wäre noch lexikalisch größer als I. II. III. IV.
• Zur Strategie der Lua-Programmierung:
  • Wenn man nichts weiter zu tun hätte, dann könnte man ein recht komplexes Regelwerk schreiben, das anhand der von dir angegebenen Betrachtungen über Namensbestandteile, Tätigkeitsfelder und Geburtsjahrgänge ein NAME= nur aus den sonstigen Angaben (Lemma, Kurzbescheibung) ermitteln würde; und gegenchecken, ob das NAME= stimmt.
  • Dazu muss eine Bandbreite an Testfällen entwickelt werden, an der mit jeder Veränderung im Code der Algorithmus erneut geprüft wird, ob die Prognose jetzt immer noch stimmt oder durch Seiteneffekte negativ beeinträchtigt wurde.
  • Mit der von dir skizzierten kompletten Neuauswertung zur Bestimmung von NAME= ist ein Nebenbei-Programmierer der Wikipedia einen Monat beschäftigt, bis das alles sauber funktioniert. Der macht dann aber nichts anderes mehr.
  • Ich selbst würde damit nicht vor 2018 fertig sein.
  • Angenommen, ich würde einen solchen Neubestimmungsapparat für NAME= schreiben, dann müssen die Betrachtungen und Umsetzung in Programmcode sehr ausführlich dokumentiert werden, weil ich mich dann schon selbst nach sechs Wochen nicht mehr durchfinden würde; insbesondere aber auch zukünftige Wikipedianer mit dem Nachlass umgehen können müssen.
  • Ich wüsste nicht, dass es momentan in der deutschsprachigen Wikipedia außer mir einen einzigen Programmierer geben würde, der sowas schreiben kann; oder falls mir der Himmel auf den Kopf fiele, der das dann aktuell anhand neu auftauchender Sonderfälle oder allgemeiner Notwendigkeiten pflegen und warten könnte. Wir haben rund ein Dutzend Leutchen, die Lua soweit verstehen, dass sie schlichte vorhandene Module (Ersetze A durch B, und hänge C dran wenn D) instandhalten könnten, und selbst welche schreiben. Jüngst machten wir die Erfahrung mit PD ohne APPER. Selbst wenn man den Code lesen kann, bedarf es wochenlanger Einarbeitung, bis man weiß, wo und wie man etwas in der gewünschten Weise umbauen kann, ohne dass dann gleichzeitig alles andere zusammenbricht.
  • Reden wir nur mal über sowas simples, jedem alltäglich Vertrautes wie das angegebene Datum, das in dem Kontext ja auch analysiert wird. Hier ist der Code dafür; dazu kommt noch dieses lokales Konfigurationsmodul. Und? Weisse Bescheid jezz?
  • Aus Erfahrung weiß ich, dass bei dem von dir angestrebten Weg einer Neu-Ermittlung von NAME= nur aus Lemma, Geburtsjahrgang und eingebrachtem Wissen über Adelstitel oder Bürgerprädikate, Bischof und Hofgärtner sowie Patriarchen, Jr. oder sen., Rapper oder Performance-Künstler alle paar Wochen jemand aufschlägt und einen neuen Spezialfall gefunden habe, der bislang nicht richtig abgedeckt sei. Diesen permanenten Betreuungsaufwand zeitnah und dauerhaft zu leisten kann ich nicht garantieren; ich betreue Software und Dokumentation dazu in noch zwei Dutzend weiteren Arbeitsfeldern und springe von einer offenen Baustelle zur nächsten; mit einem Rückstand von zehn bis zwanzig Monaten.
• „Wieso bei einer Programmänderung alle existierenden Artikel neu bearbeitet werden sollen, erschließt sich mir nicht“
  • Jede Veränderung an einer eingebundenen Vorlage oder einem Modul macht es notwendig, dass ausnahmslos alle einbindenden Seiten vom Server neu geparst und gerendered werden, weil nicht vorhersagbar ist, auf welche dieser Seiten die Veränderung welche Auswirkungen hätte.
• Vorschlag:
  • Ich übergebe dir mit Aufruf eines Unterprogramms die aktuellen Werte für NAME=, Lemma und GEBOREN= sowie KURZBESCHREIBUNG=.
  • Du schreibst ein Lua-Unterprogramm, das nur Entscheidungen trifft, NAME= sei vermutlich angemessen oder definitiv falsch, und außerdem ob in diesem Fall eine Ersetzung römischer Zahl durch numerischen Wert erfolgen solle oder nicht.
  • Diese beiden Werte gibst du mir zurück, und ich löse eine Wartungskat aus bei NAME= „verwürgt“ und ziehe deine Erkenntnis bei der Ersetzung durch numerischen Wert haran.
  • Du schreibst weiterhin (in Lua) eine Suite an Testfällen mit Eingabedaten und dem erwarteten daraus resultierenden richtigen Ergebnis, damit jederzeit die Funktionalität deines Algorithmus automatisiert geprüft werden kann.
  • Du dokumentierst alle aufgestellten Regeln, wie oben schon skizziert.
  • Du übernimmst dauerhaft die Wartung deines Algorithmus bei auftretenden Falschzuordnungen in der Wartungskat.

VG --PerfektesChaos 10:12, 22. Dez. 2016 (CET)

Ohne damit dem anderen zuzustimmen, gehe ich nur auf das Wesentliche ein.

• Ich habe weder vorgeschlagen, noch auch nur angedeutet, dass NAME aus dem Lemma abgeleitet werden sollte. Das dürfte tatsächlich schwer sein. Ich schrieb nur "Das Lemma hat eine wesentlich einfachere Struktur." Daher ist es geeigneter, verlässliche Informationen zu gewinnen – wie eben 'römische Zahl oder Buchstabe(nfolge?' Ich behandelte ausschließlich dieses Problem.
• Ich bin bereit, ein Unterprogramm in Lua zu schreiben, welches aus den von Dir genannten Informationen die eben genannte Entscheidung ableitet. Über die Details der Informationsrückgabe könnten wir uns absprechen, sobald ich mich mit Lua, speziell den hierfür vorhandenen Möglichkeiten, vertraut gemacht habe. (Ebenso mit den möglichen Problemfällen. Das Beispiel Haskell V. Anderson III zeigt schon, dass ein simples 'ja/nein' nicht ausreicht.)
• Dass ich Dokumentation, Testsuite und Wartung ebenso übernehme, versteht sich von selbst.
• Zur Erkennung "NAME= sei vermutlich angemessen oder definitiv falsch" verspreche ich nichts. Ohne Teilergebnisse auszuschließen.

Einverstanden? Es grüßt, --Griot (Diskussion) 19:06, 23. Dez. 2016 (CET)

Na, dann schreib mal das Lua-Unterprogramm.

• „Das Beispiel Haskell V. Anderson III zeigt schon, dass ein simples 'ja/nein' nicht ausreicht.“
  • Sehr schön; und es zeigt auch, dass es für Autoren einen simplen und schnell wirkenden Weg geben muss, nämlich ein explizites SORTIERUNG=, um von einer Minute auf die andere eine bestimmte Sortierung im konkreten Einzelfall zu erreichen.
  • Um den gleichen Effekt über die Lua-Programmierung zu erreichen, muss erst ein Lua-Programmierer gefunden werden, danach die BETA-Erprobung laufen, dann ggf. ein Admin gefunden werden, der die Änderung in die vollgeschützte Seite kopiert, anschließend bauen die Server eine Dreiviertelmillion Artikel neu auf.
• Ich werde die Fälle, in denen dein Ergebnis von der pragmatischen Komma-Annahme abweicht bzw. manuelles SORTIERUNG= benutzt wird, in Wartungskats tracken. Ich wette ein mir relativ wichtiges und mit meiner Wirbelsäule eng verbundenes Körperteil darauf, dass es allenfalls ein gutes Dutzend Sonderfälle in der einen wie anderen Richtung geben wird.
• Du bist dir hoffentlich darüber im Klaren, dass dein Lua-Unterprogramm auf dem kritischen Pfad liegt und ggf. die Gesamt-Umstellung der Sortierungsmethoden blockieren kann, die der Community in einem Rutsch und auf einen Schlag erklärt werden muss.

VG --PerfektesChaos 02:13, 24. Dez. 2016 (CET)

Ok, es grüßt --Griot (Diskussion) 02:25, 27. Dez. 2016 (CET)

@Griot: Frohes Neues.
Und damit es ein wenig vorangeht, habe ich da mal was vorbereitet:

• Deine Wirkungsstätte.
  • Enthält einen Funktionsrumpf unter dem Arbeitstitel griot(), den du nach Belieben umtaufen kannst.
• Test-Suite.
• Auswertung vor allem auch zur Vorschau.
• H:Lua
• WP:BETA

VG --PerfektesChaos 12:49, 4. Jan. 2017 (CET)

Danke, auch Dir ein schönes neues Jahr. Vielen Dank für die Vorarbeit, dann kann ich ja richtig anfangen. Nebenbei: wenn, wie ich die Seite verstehe, Lua 5.1 (mit einigen Einschränkungen und Zusätzen wie ipairs) die zur Zeit verwendete Sprachversion ist, wäre eine explizite Aussage dazu auf H:Lua und/oder Wikipedia:Lua nicht verkehrt. Es grüßt, --Griot (Diskussion) 00:31, 5. Jan. 2017 (CET)

Die genaue Sprachversion hilft wenig, weil nur 30 % der eigentlichen Sprache verwendbar sind. Ein sehr großer Teil, der sich mit dem Zugriff auf Quelldateien, Betriebssystem und eingebettete C-Programme und interne Funktionalitäten befasst, ist in MediaWiki deaktiviert. Übrig bleibt eine Rumpf-Sprache mit Basis-Syntax, und die war wohl in Version 4 schon praktisch genauso. H:Lua, nebenbei, wenn überhaupt. Dafür gibt es etliche MediaWiki-Bibliotheken über die Sprache hinaus. LG --PerfektesChaos 01:05, 5. Jan. 2017 (CET)

Nun, es geht weniger um die Abgrenzung gegen frühere, als um die gegen neuere Versionen. Die schöne neue goto-Anweisung etwa ist offenbar(?) nicht verfügbar. Es grüßt, --Griot (Diskussion) 08:43, 5. Jan. 2017 (CET)

„goto-Anweisung“? GOTO? schön und neu? Vielleicht wird absichtlich kein Upgrade zu >5.1 gemacht, um das bewusst zu verhindern. Ich möchte hier jedenfalls keine Lua-Programmierung mit goto sehen. VG --PerfektesChaos 10:40, 5. Jan. 2017 (CET)

Nanu, mit GOTO kann man doch herrlich perfektes Chaos produzieren… (Betonung auf 'kann'.) Dass es Chaos auch vermeiden hilft, wird mein Code (leider eben nur auskommentiert) zeigen. Da ich ihn offline erstelle und vorteste, wird eine erste Variante etwa am Wochenende (14.-16.1.) zu sehen sein. Die Schnittstelle wäre dann sicher noch anzupassen und die Dokumentation wird noch nicht fertig sein. Es grüßt, --Griot (Diskussion) 02:50, 9. Jan. 2017 (CET)

So, eine erste funktionsfähige und weitgehend ausgetestete Version ist da. Sie behandelt allerdings, wie oben schon erwartet, fast nur die römischen Zahlen, kaum das Problem unglücklicher NAME-Ansetzung. @PerfektesChaos: Es sind noch Details abzustimmen. Wo sollten wir das tun? Es grüßt, --Griot (Diskussion) 17:14, 16. Jan. 2017 (CET)

Schönen Dank.

• Ich habe erstmal Wikipedia Diskussion:Lua/Modul/Vorlage:Personendaten eingerichtet; diese ist auch von Beta direkt verlinkt.
• Dorthin kann nach Belieben dieser ganze Abschnitt ausgelagert, ggf. mit Zwischenüberschriften versehen und bereits teilweise dort archiviert werden. Ich vermute, die Mitleser sind nicht böse, wenn sie uns los sind.
• Einige Anmerkungene zum Code:
  • normalize() wäre durch mw.text.trim( s ) zu ersetzen.
    • Siehe Hilfe:Lua/Zeichenketten #mw.text
    • Ich vermute, in einer häuslichen Umgebung hattest du das nicht und dir schnell selbst was gebastelt.
    • Für die Pflege hier sollten allerdings Standardaufgaben von vertrauten Bibliotheksfunktionen wahrgenommen werden.
  • Eine Prüfung auf Existenz der Eingabeparameter braucht es nicht.
    • Lemma kann technisch nicht nix sein, wenn Name oder Kurz nix sind wurde schon längst die globale Wartung auf den Plan gerufen, und Geboren meiner Erinnerung an vor zwei Monaten nach wohl auch. In diesem Fall kommt es nicht einmal in die Nähe, dich aufzurufen, sondern schmeißt schon Wartungskat und schmollt.
    • Ein trotzdem ausgelöster Totalcrash ginge bereits vollautomatisch auf meinen Deckel und löst ebenalls eine Wartungskat aus.
• Alles Weitere dann nach Etablierung auf der dortigen Disku.

LG --PerfektesChaos 17:42, 16. Jan. 2017 (CET)

Resultatsübergabe

Hallo, PerfektesChaos. Danke für die Hinweise, ich berücksichtige sie bei der nächsten Änderung. Zu Deinem Vorschlag, die entsprechende Diskussion hierher zu verlagern: ok, aber wie verschiebt man einen Diskussionsabschnitt?

Abzustimmen ist noch, wie ich Dir die Ergebnisse (der Suche/Untersuchung römischer Zahlen) geeignet übergebe. Bisher ist nur ein Boolean-Wert vorgesehen. Das reicht nicht, wenn NAME mehrere potentielle r.Z. enthält. Es gibt nicht viele solche Personendaten (im Dump vom 1. Januar zähle ich 19, alle mit zwei potentiellen r.Z.), aber das Verfahren soll ja auch für diese funktionieren. Da die Künstler sehr erfindungsreich bei der Suche nach Künstlernamen sind, kann man sich auch nicht darauf verlassen, dass es bei höchstens zwei p.r.Z. in NAME bleibt.

Es gibt wohl zwei grundsätzliche Möglichkeiten:

1. Ich übergebe die Zeichenkette, in der die Ersetzungen bereits erfolgt sind, wenn gewünscht, auch mit Zusatzinformationen. In diesem Fall müsste ich wissen, ob überall - auch im Inneren von SORTIERUNG - bei einstelligen Zahlen auf eine vorangestellte Null verzichtet werden kann.
2. Ich übergebe eine Tabelle, in der minimalsten Form nur von Boolean-Werten. Im Kommentar vor der Funktion split (den Namen sollte ich noch ändern) siehst Du, was ich für jede p.r.Z. noch zur Verfügung habe, wovon ich übergeben kann, was gewünscht wird. Falls Du die p.r.Z. selbst noch einmal zwecks Ersetzung suchst, wäre es dann noch nötig, deren Definition abzustimmen.

Es grüßt, --Griot (Diskussion) 22:09, 16. Jan. 2017 (CET)

• Die erste Frage kann ich leicht beantworten: C&P, Strg-X, Bearbeitungskommentar.
• Über mehrfache r.Z. muss ich mal eine Nacht meditieren.

LG --PerfektesChaos 23:04, 16. Jan. 2017 (CET)

Gut. Den letzten Abschnitt habe ich verschoben. Den Abschnitt Fürstlichkeiten und andere unbürgerliche Personen hast Du begonnen, daher habe ich ihn noch nicht verschoben, da ich nicht weiß, ob Du ihn ganz oder teilweise verschoben haben möchtest. Es grüßt, --Griot (Diskussion) 01:00, 17. Jan. 2017 (CET)