Benutzer:Dirk123456/Baustellenbaustelle 001/Baustelle-D/Baustelle-D.24

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Hallo @PerfektesChaos, entschuldige bitte, dass ich so spät antworte.nbsp;nbsp;↓Zum Ende des Beitrags↓

Ich denke seit Oktober 2020 (mit Unterbrechungen) über die Antwort nach. Meine erste Idee war, diese Antwort so zu gestalten, wie ich das beim Prototyp-1-Update getan habe. D. h., ich nähme Deine Stichpunkte, „verankerte“ die alle und bezöge mich dann darauf. Dann fiel mir ein, dass ich die Stichpunkte alle noch mal hinschreiben müsste, da sie im Original nicht verankert sind und Du keine Redundanz magst.

Dann hab ich mir überlegt, dass ich es trotzdem auf meine Weise machen müsste, weil ich es dann besser hinkriegen würde. Ich war ja bisher kein Techie, sondern Autor. Ich finde die Bezeichnung „Autor“ eigentlich ein wenig übertrieben, weil sie suggeriert, dass wir „Autor*innen“ Neues schreiben würden; wir sollten aber nur das wiedergeben, was belegbar ist (WP:BLG) und nichts dazu dichten (WP:TF). Ich hatte dann tatsächlich angefangen, einzeln auf Deine Punkte und Unterpunkte antworten zu wollen. Dabei fiel mir auf, dass ich vieles hinschreiben würde, was ich schon in den Feedback-Beiträgen zu den Prototypen geschrieben hatte. Mittlerweile hatten wir Dezember 2020 und „Corona“ begann langsam an meinem Gemüt zu nagen; der Winter ist auch allgemein nicht die Jahreszeit meiner höchsten Motivation. Ich habe das für mich leidige Thema, „Leichter mit Vorlagen arbeiten“, deshalb erst einmal ruhen lassen.

Jetzt antworte ich trotzdem, da es sonst so aussieht, als wolle ich Dich ignorieren und das möchte ich nicht. Da ich mittlerweile des Öfteren vom hundertsten ins tausendste komme, versuche ich mehr zusammenfassend als ausführlich zu antworten. Zwischenzeitlich habe ich gemerkt (am 23.3.’21), dass Du am 22.3.’21 eines der Anliegen Deines Beitrags, nämlich, dass ich mich an den TemplateData (H:TemplateData) der „Vorlage:Infobox Protein“ (oder genauer – an denen der „Vorlage:Infobox Protein/Doku“) versuchen sollte, bereits erledigt ist. Wenn im folgenden Text einiges so wirkt, als hätte ich das nicht bemerkt, liegt das daran, dass ich diesen Text vorher formuliert hatte.

Ich glaube, drei Kernpunkte isoliert zu haben, auf die ich eingehen möchte:

  • WikiData gibts auch noch!
  • Sind die Zahl zu groß?
  • Wer dokumentiert die Vorlagen?

„WikiData gibts auch noch!“: Vielen Dank für die Information zum WikiData-Eintrag zu Vorlage bzw. zum Template „Infobox Protein“! Das wird uns wohl künftig noch mehr beschäftigen, dass die Informationen, die man letztlich in der Normalansicht sieht, von sonstwoher kommen. Im konkreten Fall war es egal, ob der Visual Editor (WP:VE; H:VE) die Beschreibung aus der Vorlagen-Doku bezog oder aus einem WikiData-Objekt, weil sich die Texte ähnelten. Wenn man sich das WikiData-Objekt ansieht (oder ansah), muss man davon ausgehen, dass es sich um eine einzige Vorlage handelt (oder gehandelt hat), die in unterschiedlichen Sprachen beschrieben wird (oder beschrieben wurde).

Du weißt ja selbst, dass es in der englischen Wikipedia eine andere Vorlage gibt als in der deutschen und dass sich die Programmierung und Dokumentation der englischen Vorlage nicht an Regeln orientiert, die in der deutschen Wikipedia entworfen wurden.

Ob die sprachspezifischen Beschreibungen sich künftig an den sprachspezifischen Besonderheiten orientieren? Das hängt wahrscheinlich von der oder dem jeweils Editierenden/m ab, die oder der sowohl Techie als auch Autor*in sein kann, da der Zugriff nicht schwerer ist, als diesen Satz vollständig vergendert zu haben.

„Sind die Zahlen zu groß?“: Ich sehe die Zahl von ungefähr 70000 Vorlagen zusammen mit anderen Anzahlen mit den gegenwärtigen Mitteln als große Herausforderung an, was den Überblick betrifft. Deswegen war ich eher dafür, dass die Wikimedia ihr Angebot umsetzt, einen Vorlagenfinder zu bauen; vorausgesetzt, dass das geschafft werden kann. Ich denke, dass es gut wäre, wenn ein Autor oder eine Autorin weder alle Vorlagen, noch alle aus Deiner Sicht zukunftsfähigen Vorlagen für den Artikelnamensraum (WP:ANR) gleichzeitig auf dem Schirm haben müsste.

„Wer dokumentiert die Vorlagen?“: Vielen Dank, dass Du mir zugetraut hast, die Dokumentation von Vorlagen in die TemplateData zu überführen! Das mit einer guten Begründung abzulehnen, ist der schwierigste Punkt in dieser Antwort für mich. Ich glaube aber, Du überschätzt mich, wenn Du mir schreibst: „Es würde dir, als jemand der sich fachlich und in der Nutzung gut auskennt, jedoch gut zu Gesichte stehen, die untere Tabelle in das TemplateData einzuarbeiten.“

Erst einmal finde ich, dass es prinzipiell die Aufgabe von Programmierenden ist, auch zu dokumentieren. Der Grund ist ganz einfach: wer für andere etwas programmieren will, sollte einen Plan haben und über Mittel verfügen, diesen verbal zu formulieren und zu prüfen, ob das angestrebte Ziel erreicht wurde. Jede andere Person, außer derjenigen, die den Plan erstellt hat, muss raten, wie dieser Plan ausgesehen hätte. Es gäbe auch andere Konzepte, z. B. dass verschiedene Personengruppen mit verschiedenen Interessen versuchen, mit mehr oder weniger geeigneten Konzepten und Mitteln zu kommunizieren und das Gewünschte umzusetzen:

  • Wasserfallmodell, UML, Unit-Tests, Lastenhefte, Pflichtenhefte, Debug-Reporting-Tools usw.

Das ist bei Vorlagen alles viel zu kompliziert und funktioniert nach meinen (einige Zeit zurück liegenden) Praxis-Erfahrungen auch im professionellen Bereich nur dürftig.

Hinsichtlich der Enzyklopädie, der wir beide ein hohes Niveau wünschen, gibt es nach meiner Einteilung zwei Ereigniswelten, die ich „Trans-Wikipedanien“ und „Inner-Wikipedanien“ nenne.

„Inner-Wikipedanien“ ist das Fundament oder der „Backstage-Bereich“ der Enzyklopädie und „Trans-Wikipedanien“ ist der Gegenstand oder das Objekt der Enzyklopädie.

Ein Autor wie ich legt sich (hoffentlich) zum entsprechenden Thema eine „trans-wikipedianische Sachkompetenz“ zu, um das in die Enzyklopädie zu schreiben, was in „Trans-Wikipedanien“ als richtig gilt.

In meinem Fall wäre das bspw. das „trans-wikipedianische“ Thema „DNA-Methyltransferasen“. Daran hing für mich in erster Linie Wissen darüber, was dazu erforscht wurde. Das musste ich irgendwie in den Artikel bekommen. Dazu würde der Visual Editor vermutlich reichen, wenn nur einfacher Wikitext und Belege zum Einsatz kommen müssten. Ich stieß aber auf eine „Infobox Protein“, von der ich anfangs vielleicht nicht einmal wusste, dass sie so heißt. Ab da musste ich tiefer nach „Inner-Wikipedanien“ und auch in abgelegenere Bereich von „Trans-Wikipedanien“ vordringen. Ich musste mir zusätzliches Wissen über die Einteilungssysteme („Trans-Wikipedanien“) zulegen, die in der Infobox („Inner-Wikipedanien“) bemüht wurden. Die in der Infobox als relevant erachteten EC-Nummern setzen Wissen über das EC-System, die Instanzen, die das Einteilungssystem empfehlen (IUBMB und ihr Ausschuss NC-IUBMB) und den Bezug zu den DNA-Methyltransferasen voraus.

Für den Artikel DNA-Methyltransferasen und die Beschreibung dieser Gruppe von Enzymen wären die EC-Nummern aus meiner Sicht gar nicht so wichtig. Man hätte die Infobox einfach im Artikel löschen können, ohne dass Information verloren gegangen wäre, da auch etwas in einem Abschnitt zum EC-Nummern-System stand. Beiden Stellen, die Infobox und der Abschnitt zum EC-System, boten Informationen, die ich als überarbeitungswürdig einstufte. Ich habe dann erst mal eine Abbildung „gebastelt“, und diese als Ergänzung in dem Abschnitt zum EC-System des Artikels DNA-Methyltransferasen angebracht (Bild eingefügt: diff=next&oldid=193066044 – 17.10.2019; Korrekur einer EC-Nummer in der Beschreibung zum Bild: diff=prev&oldid=193718634).

Bis zur Anpassung der Infobox dauerte es viel länger (Ankündigung auf der Diskussionsseite: diff=200099948&oldid=192925296; Umsetzung im Artikel: diff=prev&oldid=193718634 – beides 19.05.2020), da ich mir vor allem das, was nicht in der Dokumentation der Vorlage stand (bzw. steht) umständlich erarbeitet habe. Mit der Dokumentation kam ich allein nicht aus und es hätte mir auch nicht geholfen, wenn das Gleiche in TemplateData gestanden hätte.

Insgesamt ist es mir leichter gefallen, mir hinsichtlich der DNA-Methyltransferasen die zusätzliche „trans-wikipedianische Sachkompetenz“ über die EC-Nummern usw. anzueignen, als dies für die „inner-wikipedianische Sachkompetenz“ zur Vorlage:Infobox_Protein und Co. (Vorlage:Infobox_Protein/MoreEC; Vorlage:Protein_Orthologe) der Fall gewesen ist.

Irgendwann drang dann noch das Thema mit den TemplateData in mein Bewusstsein; ich glaube, erst ab Prototyp 3 (oldid=201420686#Dirk123456.2020-06.j2ha-fg4d-n6ec – 29.09.2020). Eine ungefähre Vorstellung, was die TemplateDate so alles mit sich ziehen könnten, habe ich seit Prototyp-1-Update (oldid=203499098#Dirk123456.2020-09.he7bg-fsr8j-cgstr – 08.09.2020).

Nehmen wir mal an, jemand würde dass, was jetzt in einer anderen Tabelle in der Doku (Vorlage:Infobox_Protein/Doku) abgelegt ist, in die TemplateData-Tabelle „umtopfen“ (wie Du es ja mittlerweile dankenswerterweise getan hast). Irgendwann etwas später würde dann vielleicht eine programmierende Person den Wunsch verspüren, das, was sie oder er programmiert hat, zu dokumentieren. Würde sie oder er dann wirklich die TemplateData benutzen wollen, obwohl das die ganze Zeit vorher, seit dem Du die TemplateData-Tabelle erstellt hast (Spezial:Diff/175686247 – 02.04.2018), nicht passiert ist?

Es gab seit dieser Zeit vier Änderungen an der Doku und zehn auf der Vorlage-Seite selbst. Seit dem die Vorlage-Programmierung und ihre Doku getrennt sind, ist das Verhältnis Programm-Änderungen zu Doku-Änderungen ungefähr 2:1.

Gibt es jemanden, für die oder den sich die Situation grundsätzlich verbessert, weil die Tabelle in TemplateData steht? Ich glaube, nicht wirklich. Da nicht alles in TemplateData steht, sondern nur das meiste, muss man ja trotzdem auf die Vorlage-Seite bzw. die Doku gehen, auch wenn einiges im Visual Editor angezeigt wird. Man kann nie wissen, welche Besonderheiten sich ergeben.

Ich mache einen Abstecher zur „Vorlage:Anker“: die „Fragmentbezeichner“ haben den Typ „Zeile“ (Hilfe:TemplateData/Anwendung#Zeile) und sollten nicht mit einer Ziffer beginnen, da eine „Ziffer am Anfang“ in „mancher externen Nutzung zu Problemen führen“ könnte (Abschnitt „Syntaxprüfung“ unter „Nicht gern gesehen“). Nicht jeder Parameter in jeder Vorlage, der vom Typ „Zeile“ ist, hat diese Anforderung.

In der Vorlage:Infobox Protein gibt es Ähnliches, d. h. Informationen, die nicht so einheitlich sind, wie sie bspw. in einer TemplateData-Tabelle dargestellt werden (z. B. Datentyp „Inhalt“: einmal werden automatisch Klammern zu Verknüpfung gesetzt, ein anderes Mal nicht) und daher irgend separat beschrieben werden müssten.

Wie dem auch sei; ich habe mir das Ganze mit der speziellen Vorlage TemplateData (Vorlage:TemplateData) und ihrer Einbindung in den Dokumentationen so weit angesehen, dass es mich, der ich ein Autor bin, abschreckt. Falls ich nicht daran scheitern würde, die Informationen der Detail-Tabelle zur Infobox Protein, so wie sie sind, einmal in TemplateData zu überführen (was nunmehr hinfällig ist), würde das im Nachgang passieren. Es findet sich ja vermutlich niemand, der das dann weiter betreiben würde, wenn sich am Programm was ändert. So, wie es vorher war, also leere Felder im Visual Editor, sah man wenigstens, dass man dem Hinweis, der dort auftaucht, besser nachgehen sollte: »Es könnten einige zusätzliche Informationen über die Vorlage „Infobox Protein“ auf ihrer Seite vorhanden sein.«

Eingeschobene Anmerkung (für andere Lesende) zur Geschlechtergerechtigkeit im nachfolgenden Text:

  • Die Formulierungen, welche die Ausdrücke „Techie“ und „Autor“ verwenden, beziehen sich in erster Linie auf die beiden männlichen Benutzer, Benutzer:PerfektesChaos und Benutzer:Dirk123456, und werden hier von mir in der männlichen Form angegeben. Es geht aber um allgemeine Beispiele, bei denen das Geschlecht keine Rolle spielt. Nach einem gegenwärtigen, innerhalb der Gesellschaft teilweise verbreiteten Verständnis ist es diskriminierend, wenn in einem solchen Fall bei Nutzung der deutschen Sprache in Bezug auf eine Person nicht wenigstens angedeutet wird, dass prinzipiell jedes andere in Frage kommende Geschlecht in Frage käme. Das Team Technische Wünsche der Wikimedia Deutschland adressierte in „Häufigst genannte Probleme“ (oldid=194822419) zum Thema „Leichter mit Vorlagen arbeiten“ zwei „Primäre Zielgruppen“: „Personen, die an Vorlagen arbeiten“ – das entspräche aus meiner Sicht in etwa den „Techies“ – und „Nutzende von Vorlagen“ – was in diesem Kontext in etwa den „Autor*innen“ entspräche. Das im Plural geschlechtsneutral wirkende „Nutzende“ kann im Singular auch nicht ohne Weiteres verwendet werden, da es sowohl „den Nutzenden“ als auch „die Nutzende“ gibt. Der Gebrauch von: „Mensch mit ... Hintergrund“ scheint mittlerweile für solche Fälle überholt zu sein und solche Formulierungen wie: „Person, die an Vorlagen arbeitet“ sowie „Person, die Vorlagen benutzt“ sind als Satzteile für Rollen-Benennungen zu sperrig. Eines meiner Anliegen beim Schreiben von Diskussionsbeiträgen ist, dass ich meinen eigenen Text verstehe; nur so gelingt es mir, die Hoffnung aufrecht zu erhalten, dass auch meine Kommunikationspartner*innen diesen Text verstehen würden.

Du schreibst über die Überführung der Detail-Tabelle nach TemplateData: „Das geschieht per JSON-Handarbeit, ist aber nach kurzer Eingewöhnung gar nicht schwierig.“ Ja, für einen Techie wahrscheinlich schon, aber für einen Autor? Man könnte – rein theoretisch – den Visual Editor für einiges nutzen, wo Du dieses Tool eben nicht benutzt. Und daher könnte man – auch nur rein theoretisch – auch Folgendes schreiben: „Das geschieht per VE-Handarbeit, ist aber nach kurzer Eingewöhnung gar nicht schwierig.“ Aber wäre so etwas sinnvoll? An einen Autor gerichtet vielleicht schon, an einen Techie gerichtet wohl eher nicht.

Du bist innerhalb der „Techies“, also als „Person, die an Vorlagen arbeitet“, jemand, der sehr viel Wissen und Erfahrung mit Vorlagen besitzt. Insofern habe ich lange gebraucht, um mir einen Reim darauf zu machen, dass Du einerseits „jedoch keine Möglichkeit“ siehst, selbst die „Details einzuarbeiten“ und andererseits solche technischen Raffinessen, wie „JSON-Handarbeit“, als „nach kurzer Eingewöhnung gar nicht schwierig“ einstufst. Unter anderem lag das vielleicht daran, dass ich anfangs „die konventionellen Details“ als „herkömmliche Details“ verstanden habe und nicht als „Details, die Konventionen betreffen“. Konventionen könnten hier zwei Bereiche betreffen, die Programmierung und Dokumentation der Vorlage und die Inhalte in der resultierenden Infobox.

Um so etwas abzugrenzen, habe ich – weiter oben bereits angedeutet – zwei „Arbeitsbegriffe erfunden“: die „inner-wikipedianische Sachkompetenz“ und die „trans-wikipedianische Sachkompetenz“.

Ich hatte mich gefragt, warum Du mich angeschrieben hast und festgestellt, dass niemand anderes außer Dir und mir (weder Techie, noch Autorin oder Autor), einen Beitrag zum Prototyp-1-Update auf der Diskussionsseite hinterlassen hatte. Beim ersten Lesen Deines Beitrags habe ich es so verstanden, dass ich eine Art „Hilfstechie“ werden soll, der „die konventionellen Details“ (den herkömmlichen Wikitext) zu TemplateData-Details (zu angemessen kompliziertem Wikitext) umwandeln soll, weil Du keine Zeit hast (Fließbandarbeit).

Dann habe ich mich gefragt, ob jemand, der sich auskennt und deutlich mehr „inner-wikipedianische Sachkompetenz“ aufweist als ich, für eine einmalige Datenumwandlung wirklich jemanden anderes anschreiben würde und wenn ja, wieso nicht eine andere oder einen anderen Techie?

Eine andere Leseweise lässt mich denken, dass Du mich vielleicht gar nicht so sehr auf meine „inner-wikipedianische Sachkompetenz“ angesprochen hast (die ich selbst nicht für übermäßig entwickelt halte), sondern auf meine „trans-wikipedianische“. Das heißt, dass ich vielleicht doch auch über die Inhalte nachdenken sollte, welche in die TemplateData-Tabelle gelangen sollten und dass ich nicht nur den Text ungeachtet seines Inhalts abschreiben und umformatieren sollte.

Dafür, dass Du das so meintest oder meinst, spricht Deine Aussage: „Das ist Sache der Fachbenutzer aus den Themengebieten.“ Es wäre ja absurd, wenn die Techies die fachbezogenen Texte entwerfen würden und die Fachbenutzer bzw. Fachbenutzerinnen versuchen, dass irgendwie in ein anderes, besonderes Format zu verwandeln, sich also um die Technik kümmern. Das geht nur, wenn jemand beides ist, Techie und Autor in Bezug auf das Fachgebiet. Ich habe da eine Grenze erreicht; ich glaube, dass ich nicht beides gleich gut sein kann.

Es macht vielleicht den Eindruck, dass ich ganz gut zurechtkomme, wenn ich komplex formatierten Text in meinen Beiträgen anbiete, z. B. beim Prototyp-1-Update oder in „Leichter finden“ (oldid=191363832#Leichter finden – 15.08.2019).

Die Wahrheit ist aber auch, dass ich so etwas eben nicht in erster Linie in der Wikipedia mache. Ich bereite mittlerweile so ziemlich alle Beiträge, die ich in der Wikipedia anbringen möchte, auf meinem lokalen Rechner (Textverarbeitung, Tabellenkalkulation) und/ oder einer Baustelle vor. Der Hauptgrund ist, dass ich ein wenig optische Kontrolle benötige. Ich will das meiste unmittelbar sehen, gerade, wenn es Handarbeit ist. Ich finde es z. B. gut, wenn ich von mir nur wenige Rechtschreibfehler und Ähnliches sehe, wobei WYSIWIG und Rechtschreibprüfung helfen.

Das liegt vielleicht auch an meiner „trans-wikipedianischen Sachkompetenz“. Das allermeiste, was ich mir dazu angeeignet habe, stand in der Normalansicht auf Papier (vor allem, als ich vorrangig als Molekularbiologe gearbeitet hatte), auf einer Website oder in einer heruntergeladenen PDF-Datei. Auch bei meinen Ausflügen in den IT-Bereich in der Vergangenheit habe ich zwar auch PERL benutzt, aber später festgestellt, dass Programmiersprachen, die vorranging in einer darauf angepassten Entwicklungsumgebung (IDE) geschrieben werden können und strukturgebende Konzepte unterstützen (OOP), bei längerfristigen Sachen und vielen verschiedenen Beteiligten ihre Vorteile haben.

Ich habe diese Begabung nicht, bei einer „sportlichen Ausgangslage“ der Vorlagen-Dokumentation den Überblick zu behalten. Was meine ich damit? Im Sport werden mit purer Absicht Hürden eingebaut, z. B. eben tatsächlich Hürden beim Hürdenlauf oder es ist nicht erlaubt, Außenbordmotoren an Ruderbooten anzubringen. Bei der Vorlagen-Programmierung und -Dokumentation gibt es zwar keine absichtlich eingebauten Schikanen, aber es gibt Umstände, die letztlich so wirken, als wären sie dazu geeignet, das sportliche Leistungspotential von „Wikitext-Hassadeur*innen“ zu zeigen.

Besonders auffällig ist das bei der Vorlagen-Dokumentation, wo fast die gesamte Dokumentation einer Vorlage durch aufwändige Handarbeit in einen einzelnen Parameter einer anderen Vorlage „hinein gestopft“ werden soll, nur, damit man diesen Teil im VE sieht, wobei man trotzdem noch auf die Seite selbst muss, weil da immer noch etwas stehen könnte, was im VE nicht angezeigt wird, aber dennoch wichtig wäre.

Jemand, der „den sportlichen Anspruch“ gewohnt ist, sieht die Dinge wahrscheinlich auch anders als jemand, der als erstes die eingeschränkten Möglichkeiten der Vorlagenprogrammierung mit den Möglichkeiten anderer Programmiersprachen vergleicht. Als das Team Technische Wünsche eine erste Analyse zum Thema „Leichter mit Vorlagen arbeiten“ dargelegt hatte, nämlich „Häufigst genannte Probleme“ (oldid=194822419), war dort eine Aussage getroffen worden:

  • „Da es keine Variablen oder Funktionen gibt, muss Vorlagencode oft dupliziert werden.“

Richtige Programmiersprachen kennen benennbare Variablen, denen man ggf. Bool-Zustände zuweisen kann; bspw., um diesen Wert wiederholt abzufragen. In den Vorlagen sucht man so etwas häufig vergebens, stattdessen wird in solchen Fällen an mehreren Stellen im Programm eine gleiche Wenn-Dann-Sonst-Anweisung hingeschrieben. Deshalb wusste ich sofort, was das Team Technische Wünsche mit oben genannten Aussage meinte. Du hattest das Thema zeitnah aufgegriffen (Schnellschusskommentar zu ...). und unter anderem Folgendes geantwortet:

  • „Ich habe Dutzende von Hilfsfunktionen in mehreren Lua-Bibliotheken bereitgestellt.“

Ja, aber gleichen dutzende Hilfsfunktionen in mehreren Bibliotheken diese grundlegende Schwäche durch die fehlenden Variablen und Funktionen bei der praktischen Anwendung wirklich aus? Kann sein; aber ich sollte wieder zum Thema zurück kommen.

Ich stelle mal eine Frage:

  • Kann jemand, für den vieles in seinem Fachgebiet leicht ist, überhaupt wissen, was für andere schwer ist, die in diesem Gebiet nicht zu Hause sind?

Ich glaube, dass ist generell schwierig. Für mich werden z. B. Aufgaben, die ich prinzipiell für einigermaßen gut zu bewältigen halte, dann schwierig, wenn ich keine optische Unterstützung erhalten. Ein Zoologie-Professor meinte mal, an meine damalige Seminargruppe gerichtet, „Biologen sind Augentiere!“ Ganz unrecht hatte er damit nicht. Das ist jetzt nicht so, dass ich keinen Roman lesen könnte, weil dort gemeinhin keine Abbildungen auftauchen; aber bei einem guten Roman entstehen die Bilder in der Vorstellung.

In der Programmierung wird gern mit optischer Strukturierung gearbeitet, um sich im Quellcode zurechtzufinden (Codefaltung, Funktionen, Prozeduren, „sprechende Variablen-Namen“ etc.). Bei der Programmierung mit PHP in der Netbeans IDE wurde ich einmal gewarnt, als eine Funktion mehr als zwanzig Zeilen umfasste.

  • Das nur nebenbei: Ich hatte auch schon einen Programmcode von einem Kollegen vorgefunden, in dem eine geschachtelte For-Anweisung ungefähr vierhundert Zeilen enthielt, obgleich die verwendete Programmiersprache (Delphi) andere Möglichkeiten einräumte. Für denjenigen, der den Quellcode hingeschrieben hatte, ging das vermutlich relativ schnell, weil er über die Variablen-Namen genau so wenig nachdenken musste (i, j, k, ...), wie über die Benennung der Werte für die Schleifendurchläufe (0; 1; ...). Auch der Computer hat sich vermutlich gefreut; aber diejenigen, die das lesen und verstehen mussten? Immerhin befand sich die geschachtelte For-Anweisung innerhalb einer Prozedur, in einer Unit, und Code-Faltung war anwendbar.

Im IT-Bereich gibt es meist separate Dokumentationen, diejenige für den Programmcode und diejenige für die Anwendung der Software.

Bei den Vorlagen ist das anders. Es gibt jeweils eine Dokumentation, die für alles gleichzeitig da sein muss, bspw.:

  • als Anleitung für Autor*innen zur Anwendung im jeweiligen Artikel,
  • als geschichtlicher Abriss zur Entwicklung der jeweiligen Vorlage,
  • als „Nachrichtenbörse zur Selbstabholung“, entweder von Techies für andere Techies oder von Techies für Autor*innen.

Die geschichtliche Entwicklung skizziert zu bekommen, ist durchaus interessant (z. B. in oldid=209668741#„Anker_2.0“), manchmal wäre es für das Verständnis sogar hilfreich, z. B. wenn das Zustandekommen eines Ausdrucks historische Gründe hat (die Benennungen „Klammerinhalt“ und „Klammerlemma“ in der Vorlage PersonZelle lassen sich vermutlich aus der Verwendung eines Zusatzes ableiten, der in Klammern angegeben wurde; heute tauchen Klammern weder bei der Eingabe des Parameters, noch bei der Ausgabe in der Tabellenzelle auf – Link zur Vorlage: oldid=198326723. Ich vergesse gelegentlich auch, dass der Text, den ich gerade gelesen habe, zu einer Version der Doku gehört und nicht zur angeklickten Version der Vorlage (daher noch ein Link zur aktuellen Doku: oldid=210012850).

Was meine ich mit „Nachrichtenbörse zur Selbstabholung“? Es gibt solche prägnanten Beschreibungen, wie beim Parameter x1 der Vorlage:Anker: „Weiterer Fragmentbezeichner ohne Syntaxtest (nicht mehr erwünschtes Namensschema, gelegentlich durch -1 usw. ersetzen)“ (steht/ stand z. B. am 23.3.’21 so in der Doku). Für mich als „Otto Normal-Vorlagen-Einbinder“ war diese Information verwirrend, da ich davon ausgegangen war, dass mich das was anginge, weil es eben Fälle geben sollte („gelegentlich“), wo eine Angabe durch die andere ersetzt werden müsste. Dass ich da vielleicht etwas ausblenden könnte, habe ich mir dadurch zusammen gereimt, dass ich dieses für mich komplizierte „Gebilde“ (aus „normalen Ankern“, ungeprüften Ankern, einem unerwünschten und ungeprüften Anker und unendlich vielen weiteren Ankern ohne Benennung) mit einer Vorversion verglichen habe.

Die Vorversion (Doku: oldid=193382300) bietet mir ein schlichteres Bild: man kann einem Anker an einer Stelle mithilfe von sechs Parametern sechs verschiedene Namen geben, mit denen das Sprungziel verknüpft werden kann. Die Formulierung „gelegentlich“ heißt also vermutlich nicht, dass ich montags und mittwochs auch mal „-1“ hinschreiben sollte, während sonst „x1“ schon ok ist; sondern, dass andere Techies nach und nach dort, wo der Parameter „x1“ eingetragen wurde, diesen gegen „-1“ austauschen sollten.

Ein anderes Beispiel für die Nutzung einer Vorlage als „Nachrichtenbörse zur Selbstabholung“ ist der Parameter „CID“ aus der Vorlage „Infobox Protein“, der veraltet ist und dessen Funktion durch den neuen Parameter „PubChem“ übernommen wurde (seit 27.12.’19 in der Vorlage diff=195259690&oldid=183851377). In den TemplateData steht dazu beim Parameter „CID“: „veralteter Parameter bitte entfernen“ (diff=195259690&oldid=183851377). Das ist der Text, den man auf hellrotem Hintergrund in der Normalansicht sieht. Auf den ersten Blick bedeutete das für mich, dass auf der Vorlagenseite selbst ein Fehler aufgetreten ist, der entfernt werden müsste. Wer als Artikelautor*in die Vorlage einbinden oder eine eingebundene Anwendung bearbeiten möchte, denkt erst einmal, sie oder er habe selbst einen Fehler gemacht. Interessanterweise sind die Angaben, die man aus dem Quellcode selbst beziehen kann, manchmal informativer: <!--nachfolgend veraltete Parameter, sollen mindestens im ANR entfernt werden: -->CID=. Zusammen mit dem Vergleich zur Vorversion (diff=195259690&oldid=183851377) erkennt man, dass „PubChem“ das neue „CID“ ist. Aber soll sich eine Artikelautorin oder ein Artikelautor den Programmcode ansehen?

Was auch recht kompliziert ist, sind die verschiedenen Benennungen hinsichtlich der Parameter:

  • die Namen von Parametern selbst und
  • die letztlich resultierenden Schriftzüge in der Infobox Protein.

Wenn man sich die Infobox ansieht, dann kann es einfach sein: „ATC-Code“ ist

  • sowohl der resultierende Schriftzug in der Infobox,
  • als auch die Benennung im Visual Editor,
  • als auch der Name des Parameters.

Es kann aber auch sehr kompliziert werden: wenn „EC, Kategorie“ der resultierende Schriftzug in der Infobox ist, kann dieser von acht verschieden Parametern hervorgerufen werden: direkt von den Parametern „EC-Nummer“ und/ oder „Kategorie“ bzw. von den gleichnamigen Parametern innerhalb der Parameter „MoreEC1“, „MoreEC2“ sowie „MoreEC3“, welche eine sogenannte Untervorlage als ihren jeweiligen Wert beherbergen. Insgesamt kommen also elf Parameter beim Zustandekommen eines Schriftzugs „EC, Kategorie“ in Betracht. (Das war jedenfalls mal so; ich habe mir die Untervorlage aktuell nicht noch einmal angesehen.)

Wenn ich jetzt also ein Autor bin, der den Schriftzug „EC, Kategorie“ als Rubrik in der Infobox sieht und rechts daneben etwas Unstimmiges (bei mir war das „, DNA-Methyltransferase“; also keine EC-Nummer und ein Komma am Anfang), wie soll ich da jemals die richtige Stelle in der Einbindung der Vorlage im Artikel finden, an der was geändert werden muss?

Ich hatte mich Ende September 2019 dazu entschlossen, hinsichtlich der Vorlage „Infobox Protein“ etwas tiefer ins Detail zu gehen. Das ist dann immer komplizierter geworden. Zuerst wollte ich nur eine Infobox in einem Artikel ansehen, dann habe ich immer mehr Parameter einbezogen, dann mehr oder weniger alle. Ich habe Testbeispiele untersucht und auch etwas Code angeschaut. Im ersten Anlauf habe ich meine Ergebnisse in einem lokalen Dokument gespeichert.

Irgendwann habe ich angefangen, den Programm-Code, der an einem Stichtag zu einer festgelegten Referenzzeit (29.9.’19, 12:00) vorgelegen hat, möglichst vollständig in Zeichenketten zu zerlegen (aufwändig, mit recht schlichten Mitteln – Tabellenkalkulation), um zwischen Parametern und den resultierenden Schriftzügen zu unterscheiden. Der Hauptgrund dafür war, dass der Schriftzug „Eigenschaften des menschlichen Proteins“ durch den Parameter „HGNCid“ hervorgerufen wurde, obwohl er laut Doku eine andere Funktion hatte.

Ich hatte festgestellt, dass es jede Menge Schriftzüge in einer resultierenden Infobox gibt, die in der Dokumentation nicht auftauchen und dass es unmöglich ist, alle Kombinationen von Parametern zu testen und sämtliche Schriftzüge auszulösen, die durch die Parameter selbst (und nicht durch deren Werte) auftreten können.

Um selbst durchzusehen, habe ich ein eigenes „Begriffssystem“ entwickelt. In diesem System gibt es z. B. „allgemeine Schriftzüge“: das sind solche, die durch Anwendung von Parametern (unabhängig von ihren konkreten Werten) entstehen und „konkrete Schriftzüge“: das sind solche, die durch die konkreten Werte von Parametern in der jeweiligen Infobox angezeigt werden.

Außerdem habe ich „Eingabe-Elemente“ und „Anzeige-Elemente“ definiert. Die „Eingabe-Elemente“ sind die Parameter-Namen („Parameter“) und die zugeordneten Werte („Argumente“), die in Vorlage-Einbindungen verwendet werden. Die „Anzeige-Elemente“ sind Schriftzüge (und Bilder) in der resultierenden Infobox, die ich in „Überschriften“, „optische Parameter“ und „optische Argumente“ eingeteilt habe.

„Optische Parameter“ und „optische Argumente“ sind die entsprechenden Anzeige-Elemente zu den Eingabe-Elementen „Parameter“ und „Argument“; ich habe diese Ausdrücke gewählt, um das, was man am Ende sieht („optisch“, Anzeige in der Infobox), gegen das abzugrenzen, was man am Ende – also in der Normalansicht – eben nicht sieht (den Wikitext der Einbindung der jeweiligen Vorlage).

Manchmal – allerdings selten – sind Parameter und „optischer Parameter“ (also Eingabe und Anzeige) identisch (z. B. „ATC-Code“ → „ATC-Code“), manchmal ähnlich (z. B. „Precursor“ → „Präkursor“), manchmal völlig unterschiedlich (z. B. „PDB“ → „Vorhandene Strukturdaten“).

Das Problem ist der versteckte Bezug zwischen der Anzeige und der Eingabe. Eine Artikelautorin oder ein Artikelautor, die oder der bspw. in einer Infobox rechts von „Vorhandene Strukturdaten“ eine Unstimmigkeit entdeckt, wird erst einmal durch nichts und niemanden darauf hingewiesen, dass der Wert des Parameters „PDB“ editiert werden müsste.

Ich selbst habe für mich die Zuordnung zwischen den „optischen Parametern“ und den Parameter-Namen hergestellt, indem ich an Hand von Einbindungsbeispielen die Zuordnung zwischen „optischen Argumenten“ und den „Argumenten“ – also den Wert-Eingaben rechts der Parameter-Namen – ausgewertet habe.

„Überschriften“ sind zumeist „allgemeine Schriftzüge“, die konstant sind (z. B. „Arzneistoffangaben“) und innerhalb einer Tabellenzeile mit grünem Hintergrund angezeigt werden. „Überschriften“ können aber auch variieren; der prinzipiell gleiche Abschnitt für die Enzymklassifikation innerhalb verschiedener Infobox-Anzeigen kann bspw. durch drei verschiedene Texte überschrieben sein:

  • „Enzymklassifikation“, „Enzymklassifikationen“ oder „Inhibitorklassifikation“.

Auch hier kann ein(e) Autor*in nicht erkennen, was dafür den Ausschlag gibt.

Die aus meiner Sicht schwierigste „Überschrift“ in einer Infobox Protein ist die Überschrift „Eigenschaften des menschlichen Proteins“, welche als „Nebenprodukt“ des Parameters HGCNid entsteht. Eine Zuordnung über konkrete Schriftzüge in Testbeispielen – also über die „optischen Argumente“ – hilft hier nicht weiter, wenn man nicht weiß, dass HGCNid die Überschrift auslöst. Selbst wenn man als Autor*in den naheliegenden Verdacht hegen würde, dass die Anzeige-Elemente unterhalb der Überschrift „Eigenschaften des menschlichen Proteins“ zu den Eingabe-Elementen führen könnten, würde man in einer Sackgasse landen.

Der einzige Weg, herauszufinden, wo die „Überschrift“ innerhalb der Infobox herkommt, ist die Suche nach der Zeichenkette „Eigenschaften des menschlichen Proteins“ im Programmcode. Nur dort wird man auf den Zusammenhang zum Parameter HGCNid hingewiesen. Soweit ich da überblicken konnte, gibt es zwei Parameter, HGCNid und UniProt, die sich jeweils an mehreren separaten und funktionell verschiedenartigen Stellen in der Ansicht der Infobox auswirken.

So etwas lässt sich nicht gleichzeitig einfach, übersichtlich und vollständig darstellen, weder mit einer Detail-Tabelle in der Vorlagen-Doku, noch mit den TemplateData. Das meinte ich damit, als ich zum Prototyp-1-Update schrieb:

Ich habe von September 2019 bis September 2020 (unter anderem) daran gearbeitet, anhand der Vorlage:Infobox Protein herauszufinden, wie man zumindest für diese Vorlage eine Dokumentation gestalten könnte, die für diejenigen, die die Einbindungen im Artikelnamensraum bearbeiten möchten bzw. müssen, praktikabel wäre.

Das ist mir nicht wirklich gelungen; nicht, als ich von der Anwendung einfachen Wikitextes ausging und erst recht nicht, als ich die TemplateData in die Betrachtung einbezog. Wenn sich nächstens nicht allzu viel an der Programmierung der Vorlage:Infobox Protein ändert, kann ich Vorlage vermutlich wenigstens selbst noch eine Weile ohne erneute, tiefgehende Analyse meinerseits nutzen.

Gegenwärtig scheint es mir so zu sein, dass Unstimmigkeiten im Fließtext von Artikeln schneller ausgeglichen werden, als solche, die in den Vorlage-basierten Bereichen auftreten, z. B. innerhalb von Infoboxen.

Glaube mir, wenn ich eine Möglichkeit gesehen hätte, den Weg von der Betrachtung einer Vorlage-Auswirkung (z. B. Infobox) durch eine(n) Artikelautor*in innerhalb der Normalansicht bis zur Verbesserung des Quelltextes in der Vorlage-Einbindung transparenter zu machen, hätte ich mich auch selbst mit meinen Ergebnissen gemeldet.

Die ganze Sache mit den verschiedenen Taktiken „hierzuwiki“ und „dazuwiki“ (englische Wikipedia) verstehe ich nur bedingt. Das „integrierte Modell“ mag besser sein als ein anderes Modell oder auch nicht; die englische Wikipedia mag mit einem Verstoß gegen DRY gegen Regeln in der deutschen Wikipedia verstoßen haben oder auch gegen eigene Regeln. Wie dem auch sei, der wachsende Unterschied zwischen den sprachspezifischen Wikipedias stimmt mich bedenklich.

Ich habe in beiden Wikipedias Schwierigkeiten, mich von außen (Vorlage-Auswirkung im Normaltext) nach innen (Quelltext-Eingaben auf verschiedenen Seiten) „durchzuhangeln“.

Ich glaube nicht, dass die deutsche Wikipedia ein einsamer grüner Ast am Baume des Wikiversums sein kann, während die anderen Äste und sein Stamm vertrocknen. Die Wikimedia Deutschland wird vermutlich auch keine „Fachhochschule für germanowikipedianische Infrastruktur unter besonderer Berücksichtigung des Vorlagennamensraumes“ gründen.

Ich betrachte das Thema künftig weiter aus den Augenwickeln, werde mich aber erst einmal voraussichtlich mehr auf das konzentrieren (müssen), was ich ausreichend gut zu können glaube – Artikelgestalter hinsichtlich bestimmter Themenbereiche zu sein.

↑Zum Anfang des Beitrags↑ | ↑Zur Überschrift↑

MfG --~~

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Benutzer:Dirk123456/Baustellenbaustelle_001/Baustelle-D/Baustelle-D.24&oldid=210316978“