Wikipedia

Benutzer Diskussion:Dirk123456/Archiv/2020

< Benutzer Diskussion:Dirk123456
Letzter Kommentar: vor 3 Jahren von Dirk123456 in Abschnitt Deine umfangreiche Ausarbeitung zu „Technische Wünsche“ / Leichter mit Vorlagen arbeiten

Projekt Vorlagen - Ende 2019

Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Information an mich selbst:

Am 19. Nov. 2019 wurde die Projektseite zu "Leichter mit Vorlagen arbeiten" ergänzt (aktuell, Version 194191638 vom 19.11.'19: [1]). Im Abschnitt "#Recherche" kamen Recherche-Ergebnisse hinzu und es wurde auf eine Website verknüpft: "... Die meistgenannten Probleme in diesen Problembereichen finden sich hier.", wobei "hier" die Unterseite

ist. Auf der Diskussionsseite gibt es dazu von einen „Schnellschusskommentar“ ():

Hauptüberschriften in Häufigst_genannte_Probleme:

--Dirk123456 (Diskussion) 17:32, 3. Jan. 2020 (CET)

Technische Wünsche: Zusätzliche Oberfläche für Bearbeitungskonflikte auf Diskussionsseiten

Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 
So soll die Oberfläche aussehen.

Du erhältst diese Nachricht, weil du dich für den Technische-Wünsche-Newsletter eingetragen hast.

Das Team Technische Wünsche arbeitet zzt. an einer Funktion, um Bearbeitungskonflikte auf Diskussionsseiten besser zu lösen.

Diese Ansicht wird mir gezeigt, wenn ich auf einer Diskussionsseite schreibe und eine andere Person einen Diskussionsbeitrag in derselben Zeile verfasst und vor mir abspeichert. Mit dieser zusätzlichen Bearbeitungskonfliktoberfläche kann ich die parallel entstandenen Kommentare logisch ordnen und aufeinander abstimmen. Auf dieser Projektseite ist der Ansatz detaillierter beschrieben.

Es ist geplant, dass die Oberfläche in den nächsten Monaten bereitgestellt wird. Das Team Technische Wünsche freut sich über Feedback und Fragen dazu auf dieser Diskussionsseite, idealerweise bis zum 10. März 2020. -- Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 13:59, 25. Feb. 2020 (CET)

Technische Wünsche: Neue Standardoberfläche zum Lösen von Bearbeitungskonflikten (Wunscherfüllung)

Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 
Zwei-Spalten-Bearbeitungskonflikt Oberfläche

Du erhältst diese Nachricht, weil du dich für den Technische-Wünsche-Newsletter eingetragen hast.

Bearbeitungskonflikte können seit dem 25. März 2020 dank der Funktion Zwei-Spalten-Bearbeitungskonflikt einfacher gelöst werden. Diese neue Oberfläche hilft Bearbeitungskonflikte zu lösen, indem sie die Textabschnitte von mir und der anderen Person nebeneinander anzeigt (siehe Bild), ähnlich wie man es auch aus dem [[Hilfe:Versionsvergleich |Versionsvergleich]] kennt. Dadurch kann ich abschnittsweise entscheiden, welche Textbausteine in die neue Version einfließen sollen, und diese auch noch weiter bearbeiten.

Seit November 2018 stand die Funktion in dieser Form als Beta-Funktion zur Verfügung und wurde von 6250 Personen auf der deutschsprachigen Wikipedia als solche genutzt und getestet. Dadurch gab es viel Feedback, was zur Verbesserung der Funktion benutzt wurde. Es gibt in den Einstellungen die Möglichkeit, die neue Oberfläche abzuschalten, damit bestehende Arbeitsweisen zum Lösen von Bearbeitungskonflikten nicht beeinträchtigt werden. Mehr Informationen gibt es auf der Projektseite. Rückmeldungen zu der Zwei-Spalten-Bearbeitungskonflikt-Funktion sind wie immer auf der Diskussionsseite des Wunsches willkommen. Übrigens soll bald auch eine angepasste Oberfläche für Bearbeitungskonflikte speziell auf Diskussionsseiten entwickelt werden. --Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 16:15, 25. Mär. 2020 (CET)

Technische Wünsche: „Leichter mit Vorlagen arbeiten“ – Vorstellung erster Projektideen

Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 

Du erhältst diese Nachricht, weil du dich für den Newsletter Technische Wünsche eingetragen hast. Danke dafür!

In der Umfrage Technische Wünsche 2019 wurde das Themenfeld „Leichter mit Vorlagen arbeiten“ als Schwerpunkt gewählt. Das bedeutet, das Team Technische Wünsche wird sich zwei Jahre mit diesem Thema beschäftigen und verschiedene Probleme darin angehen.

Seitdem laufen die Recherchen, welche Verbesserungen umgesetzt werden könnten. In den nächsten Wochen werden auf der Projektseite regelmäßig verschiedene einfache Prototypen für mögliche Projekte veröffentlicht. Alle sind dazu eingeladen diese zu bewerten und kommentieren. Für ein ausgewogenes Bild wird Feedback von WikipedianerInnen mit unterschiedlichem Erfahrungsstand, Arbeitsweisen und Arbeitsgebieten gesucht. Auf Basis dieser Rückmeldungen wird das Team Technische Wünsche überlegen, ob wir die Ideen umsetzen, nochmal überarbeiten, oder zugunsten anderer verwerfen. Abhängig vom Ergebnis dieser Prototypen-Phase wird es möglicherweise später im Jahr noch eine zweite Runde mit neuen Ideen geben.

Wichtig: Da wir in den nächsten Wochen regelmäßig neue Prototypen vorstellen wollen und wir euch nicht mit Newslettern, Pings und Kurierbeiträgen überschwemmen möchten, bitten wir alle Interessierten, die Projektseite zu beobachten. -- Michael Schönitzer (WMDE) (Diskussion) 17:18, 26. Mär. 2020 (CET)

Technische Wünsche: Interview zur Nutzung von Vorlagen im Visual Editor

Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Hallo Dirk123456, vielen Dank für deinen Beitrag zu unserem zweiten Prototypen (verbesserte Syntaxhervorhebung). Um besser zu verstehen, welche Verbesserungen wünschenswert sind, würden wir dir gerne ein paar Fragen zu deinen Arbeitsabläufen im Visual Editor stellen und dir beim Arbeiten zuschauen. Hättest du Zeit und Interesse uns mit einem etwa einstündigen Interview zu unterstützen? Wärst du zusätzlich bereit, dabei deinen Bildschirm zu teilen?--Robin Strohmeyer (WMDE) (Diskussion) 19:12, 7. Mai 2020 (CEST)

Hallo @Robin Strohmeyer (WMDE):,
entschuldige bitte, dass ich so spät antworte (Juli 2020 statt Mai 2020). Ich hatte Sicherheits-Bedenken, war aber guter Dinge, diese ausräumen zu können und dann eine zustimmende Antwort zu geben. Ich habe es aber bisher nicht geschafft, diese Sicherheits-Bedenken auszuräumen. Einigen Wochen nach Deiner Anfrage hatte ich es aus den Augen verloren, auf diese zu antworten.
Ich sehe es schon als effektiven Weg der Kommunikation an, direkter in Kontakt zu kommen.
Was mir bei der Kommunikation ganz allgemein auch fehlt, sind Mittel, um etwas einfach kommentieren zu können: wenn ich irgendwo eine Unstimmigkeit sehe, würde ich manchmal am liebsten einen Buntstift nehmen, einen Kringel und einen Pfeil auf den Bildschirm malen, beschriften und absenden.
Das geht zwar prinzipiell:
  • Screenshot→ Zurechtschneiden→ „Ausmalen“→ Texte vorbereiten (Dateinamen, Kurzbeschreibung, Beschreibung, Lizenzen, Quellen)→ auf die Wikimedia Commons hochladen→ Texte zum Bild bereitstellen→ Diskussionsseite wählen (welches Gremium? Portal, Redaktion, Werkstatt ...)→ ...,
aber “quick & easy” ist das nicht. Ich habe auch schon überlegt, PDF-Dateien hochzuladen, die dann all die Screenshots enthielten, die das jeweilige Problem beleuchten würden. Es müsste nicht jeder Screenshot einzeln auf die Wikimedia Commons hochgeladen und bearbeitet werden, allerdings gibt es bei PDF andere Fragen:
  • »Gilt die Lizenzvergabe für die genutzten Programme?«,
  • »Habe ich alle Standort-, Personen-bezogenen und ähnliche Meta-Daten gelöscht?«
  • usw. usf.
Um zum Grundanliegen zurück zu kommen:
  • Arbeitsabläufe mit dem Visual Editor:
Ich nutze den VE (WP:VE, H:VE) für alles Mögliche: z. B. zur Vorbereitung von Artikeln, zur Vorbereitung von komplexen Feld-Einträgen des Datentyps „Inhalt“ in Vorlagen (H:TemplateData/Anwendung#Inhalt) und zum direkten Editieren von Artikeln. Beim direkten Editieren von Artikeln sprechen viele Vorlagen aus meiner Sicht bisher eher gegen den VE, bei der „Belegen“-Funktion eher dafür.
Eine wesentliche Funktion, bei der ich den VE zweckentfremde, ist die Vorbereitung von Diskussionsbeiträgen, z. B. bei dem, den Du hier siehst.
Wenn Du möchtest, kannst Du den Link zu meiner Vorbereitungs-Baustelle folgen, auf der ich meine Vorgehensweise und die Entstehung des Diskussionsbeitrags kommentiert habe:
Das ist dann quasi erst mal ein Ersatz für Interview und Bildschirm-Teilung.
MfG --Dirk123456 (Diskussion) 18:46, 10. Jul. 2020 (CEST)
Vielen Dank für die ausführliche Rückmeldung. Schade, dass es mit dem Gespräch nicht klappt, aber die Sicherheitsbedenken lassen sich bei der Technik wohl nie restlos ausschließen. Bei Rückfragen stehe ich natürlich gerne zur Verfügung.
Wir wollen in absehbarer Zukunft einen Phabricator-Kurs anbieten. Vielleicht ist das ja nochmal interessant für den detaillierteren Austausch. --Robin Strohmeyer (WMDE) (Diskussion) 15:25, 14. Jul. 2020 (CEST)

Digitaltreff Technische Wünsche - 15.06.

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 

COVID-19 bedingt musste die Tech On Tour dieses Jahr leider ausfallen. Trotzdem ist es wichtig, dass wir im Kontakt bleiben und wir möchten probieren, ob ein Technische Wünsche Digitaltreff als Ersatz funktioniert. Meldet euch bitte bis zum 10.06.2020 hier, wenn ihr Zeit und Interesse habt, euch am 15.06.2020 um 18 Uhr online mit dem Team Technische Wünsche zu treffen. Ebenso wie die Tech on Tour richtet sich der Digitaltreff an Leute aller Erfahrungs- und Kenntnisstände.

Für die Videokonferenzen möchten wir ein GoToMeeting vorschlagen. Wikimedia Österreich nutzt das Tool bereits erfolgreich und hatte gute Erfahrungen damit gemacht. Natürlich sind wir für andere Ideen und Vorschläge offen.

Thematisch möchten wir uns nicht allzu viel vornehmen, da das Format ein Experiment ist. Ein paar Punkte gibt es aber: Im Team Technische Wünsche gibt es viele neue Gesichter und es ist Zeit, dass wir “Neuen” uns einmal vorstellen. Im Anschluss würden wir - in Vorbereitung auf die Technische Wünsche Umfrage 2020 - gerne einige der Themenschwerpunkte besprechen und hören, ob ihr noch weitere Ideen habt, wo in der Wikipedia es technische Verbesserungsmöglichkeiten gibt. --Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 14:11, 3. Jun. 2020 (CEST)

Wunscherfüllung: zusätzliche Oberfläche zum Lösen von Bearbeitungskonflikten auf Diskussionsseiten ist nun Standard auf der deutschsprachiger Wikipedia

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Du erhältst diese Nachricht, weil du dich für den Technische-Wünsche-Newsletter eingetragen hast.

 
Oberfläche für Bearbeitungskonflikte auf Diskussionsseiten.

Das Team Technische Wünsche hat mit den deutschsprachigen Wikipedianerinnen und Wikipedianern eine Funktion entwickelt, um Bearbeitungskonflikte auf Diskussionsseiten besser zu lösen. Diese steht seit dem 24. Juni 2020 zur Verfügung.

Zur Funktion: Diese Ansicht wird einem angezeigt, wenn man auf einer Diskussionsseite schreibt und eine andere Person einen Diskussionsbeitrag in derselben Zeile verfasst und vor einem abspeichert. In der Bearbeitungskonfliktoberfläche für Diskussionsseiten kann man die Reihenfolge der parallel entstandenen Kommentare über die Schaltfläche links der Textfelder anpassen und den eigenen Beitrag nochmals nach editieren. Des Weiteren kann man wie gewohnt die Einschiebung der Beiträge mithilfe von Doppelpunkten (:) anpassen.

Wenn man die neue Oberfläche nicht verwenden möchten, kann man diese in den Einstellungen deaktivieren. Wenn man die abschnittsbasierte Bearbeitungskonflikten Oberfläche bereits deaktiviert hat (frühere Zwei-Spalten Bearbeitungskonflikt Oberfläche), wird die neue Funktion für einen nicht aktiviert.

Das Team Technische Wünsche freut sich über Feedback und Fragen dazu auf dieser Diskussionsseite. Dabei ist Feedback für uns besonders hilfreich, wenn ihr genau beschreiben würdet, was ihr gut an der Funktion findet oder was euch stört. Screenshots können hier auch sehr hilfreich sein. -- Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 15:07, 24. Jun. 2020 (CEST)

Vorankündigung: Umfrage Technische Wünsche kommt

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 

Vom 06. bis 19. Juli findet die fünfte Umfrage Technische Wünsche statt. Unabhängig von Erfahrung und technischem Wissen sind alle Aktiven in der deutschsprachigen Wikipedia und ihren Schwesterprojekten gefragt: In welchem Themenschwerpunkt sind technische Verbesserungen am dringendsten nötig? Mit dem Gewinnerthema wird sich das Team Technische Wünsche dann zwei Jahre beschäftigen und verschiedene Probleme angehen. Weitere Informationen folgen in Kürze. Robin Strohmeyer (WMDE) (Diskussion) 19:12, 29. Jun. 2020 (CEST)

Technische Wünsche: Jetzt abstimmen!

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 

Hallo, du hast den Newsletter Technische Wünsche abonniert, um zu erfahren, wenn eine neue Umfrage stattfindet. Jetzt ist es wieder soweit: Seit heute läuft die fünfte Umfrage Technische Wünsche auf der deutschsprachigen Wikipedia. Abgestimmt wird über die Frage, in welchem Bereich Verbesserungen am dringendsten nötig sind. 9 Themenschwerpunkte stehen zur Wahl. Wie schon 2019 soll es die Abstimmung über Themenschwerpunkte, insbesondere für Beitragende, die sich sonst von Technikthemen fernhalten, leichter machen, sich an der Diskussion um technische Verbesserungen zu beteiligen. Eingeladen sind also alle, die an Wikipedia und den Schwesterprojekten mitarbeiten.

Hier gehts zur Umfrage! Dort finden sich auch weitere Informationen und Antworten auf häufige Fragen. Gerne weitersagen – und abstimmen. -- Viele Grüße, Robin Strohmeyer (WMDE) (Diskussion) 12:29, 6. Jul. 2020 (CEST)

PS: Feedback ist wie immer willkommen. Die zentrale Stelle dafür ist die Diskussionsseite der Umfrage.

Ergebnisse der Umfrage Technische Wünsche 2020

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Du bekommst diese Nachricht, weil du an der Umfrage Technische Wünsche 2020 teilgenommen hast.

Der Sieger der diesjährigen Umfrage ist das Thema Bessere Unterstützung von Geoinformationen

Insgesamt wurden 1642 gültige Stimmen von 1008 Personen abgegeben. Davon entfielen 280 auf das Gewinnerthema Bessere Unterstützung von Geoinformationen. Damit wünschen sich 28 % aller Personen, die abgestimmt haben, Verbesserungen in diesem Bereich. Nähere Informationen zu den Ergebnissen der Umfrage und eine statistische Auswertung erscheinen in Kürze auf der Umfrageseite.

Mit dem Gewinnerthema wird sich das Team Technische Wünsche für zwei Jahre, also bis 2022, beschäftigen. Ziel ist es, technische Verbesserungen direkt in MediaWiki, der Software hinter der Wikipedia und ihren Schwesterprojekten, umzusetzen.

Wenn du zum Thema Bessere Unterstützung von Geoinformationen Ideen einbringen möchtest, für Interviews zur Verfügung stehst, Prototypen sehen und bewerten willst oder in Nutzungstests Rückmeldungen zur Entwicklung geben möchtest, kannst du der Projektseite folgen und dich für den Newsletter Technische Wünsche eintragen. Weitere Meldungen erscheinen dort in Kürze.

Ein Ziel des Projekts Technische Wünsche ist es, die Meinungen und Vorstellungen möglichst vieler unterschiedlicher Personen aus verschiedenen Bereichen und mit unterschiedlichen Arbeitsweisen zu beachten. Schließlich soll die Software so weiterentwickelt werden, dass alle davon profitieren. Es wäre klasse, wenn du dir etwa 3 Minuten Zeit nehmen könntest, um ein paar Fragen zu deiner Person zu beantworten. Bei dem Fragebogen werden alle Vorgaben des Datenschutzes berücksichtigt. Jede einzelne Frage ist optional zu beantworten. Weitere Informationen dazu gibt es im Fragebogen selbst. Vielen Dank für deine Teilnahme! Robin Strohmeyer (WMDE) (talk) 01:28, 31. Jul. 2020 (CEST)

Vorlagenfinder

Letzter Kommentar: vor 3 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

https://persondata.toolforge.org/vorlagen/params --Wurgl (Diskussion) 12:51, 8. Sep. 2020 (CEST)

Hallo @Wurgl:, du warst ja schnell beim Antworten! Ich hatte selbst noch gar nicht richtig gemerkt, dass ich meinen sülzigen Text, den ich schon seit einer Ewigkeit vorbereitet habe, heute tatsächlich unter "Zu: Prototyp 1 Update: Vorlagen-Finder" als zweites Feedback (beim Anker Dirk123456.2020-09.he7bg-fsr8j-cgstr) hinterlassen habe!
Ich war gerade auf https://persondata.toolforge.org/vorlagen --> Parameter. Bei den ganzen Techniksachen, die man als armer Wikipedia-Autor so zu Gesicht bekommt, guckt man ja oft rein wie ein Schwein ins Uhrwerk. Bei deiner Vorlagensuche brauchte nicht sehr lange, um dort halbwegs durchzusehen.
Dafür recht herzliche Dank!
--Dirk123456 (Diskussion) 14:05, 8. Sep. 2020 (CEST)
Ich hab deinen Text gesehen, hab mir gedacht: Was ein langer Text, nee, nicht jetzt alles. Hab dann die letzten paar Sätze gelesen und eben hier schnell geantwortet. Ich hoffe du findest damit, was du suchst. Für Rückfragen oder komplexere Suchanfragen wie Kombination mehrerer Parameter/Vorlagen gibts meine Diskussionsseite. So Dinger muss ich (noch) auf der Kommandozeile machen. --Wurgl (Diskussion) 15:43, 8. Sep. 2020 (CEST)

Einzel-Projekte, Syntaxhervorhebung, Klammerpaare (an mich selbst)

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Mitte September 2020 ist mit der Umsetzung des Themenschwerpunktes „Leichter mit Vorlagen arbeiten“ begonnen worden. Die Umsetzung startete mit dem „Prototyp 2: Verbesserte Syntaxhervorhebung“; dort mit dem Punkt „Prototyp 2b: Hervorhebung zusammengehöriger Klammern“. Auf der Projektseite wurde der Abschnitt „Projekte“ genannt.

--Dirk123456 (Diskussion) 13:49, 17. Sep. 2020 (CEST)

Deine umfangreiche Ausarbeitung zu „Technische Wünsche“ / Leichter mit Vorlagen arbeiten

Letzter Kommentar: vor 3 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

aus dem September habe ich mittlerweile restlos durchgearbeitet.

  • Deine Frage: zwei verschiedene Kurzbeschreibungen zur Vorlage „Anker“ gefunden:
    • Die zweite kommt aus d:Q5412976
    • Wusste ich auch noch nicht. Nie bemerkt, aber ich arbeite auch nie mit dem VE.
    • Bezieht sich auf die Verlinkung irgendeiner beliebigen Seite, egal welcher Art. Hat nichts mit der speziellen Eigenschaft als Vorlage zu tun, sondern gibt es gratis falls ein WIkidata-Objekt der Seite zugeordnet ist.
  • Es sind mittlerweile bald 7000 unserer Vorlagen mit TemplateData ausgestattet.
    • Das sind praktisch alle zukunftsfähigen und gepflegten mit Parametern, die mindestens 100 Mal im ANR eingebunden sind, und auch viele weitere und häufig verwendete aus anderen Namensräumen, dann auch ohne Parameter.
    • Über 40.000 unserer Vorlagen sind Navileisten und haben meist keine Parameter, weitere bald 20.000 haben genauso selbsterklärende Namen und keine Parameter. Hier sind auf absehbare Zeit keine TemplateData geplant; womöglich aber irgendwann automatische Generierung eines nur aus dem selbsterklärenden Namen besthenden TemplateData-Dingens. Ob das was bringen würde ist unklar.
    • Für enzyklopädische Artikel sind alle häufigeren gepflegten modernen Vorlagen mit Parametern auch bereits mit TemplateData ausgestattet; zumindest schon mal die Beschreibung. Gut 10.000, eher selten verwendete oder ungepflegte oder umstrittene oder fragwürdige Gebilde mit Parametern im ANR haben bisher kein TemplateData, bekommen auch ohne Generalsanierung eher keins.
  • Wir haben hierzuwiki eine andere Taktik als das globale TemplateData.
    • Die Original-Version erlaubt kein Markup (Fettschrift, Kuriv, Schreibmaschine) und vor allem keine Verlinkungen.
    • Deshalb braucht es, vor allem fast überall in der englischsprachigen Wikipedia, immer zwei Dokumentationen parallel; eine traditionelle mit Verlinkungen und danach noch mal das Gleiche als TemplateData.
    • Das ist ein Verstoß gegen DRY und macht doppelte Arbeit und ist Nährboden für Inkonsistenzen.
    • Wir verwenden ein integriertes Modell, das du etwa auf Vorlage:Literatur oder Vorlage:Internetquelle sehen kannst. Bis etwa 2016/2017 gab es dort zwei solche Dokumentationen gleichzeitig, die ich inzwischen integriert habe.
    • Hier steht mehr dazu.
    • Gleichzeitig geht das globale Werkzeug dann nicht mehr; schon weil das bei den Verlinkungen und Vorlageneinbindungen und bei allem Markup aussteigt.
  • Vorlage:Infobox Protein hatte wie fast alle produktiven bestandsfähigen Infoboxen von mir eine Grundausstattung erhalten.
    • Da hatte ich wegen der Fließbandarbeit jedoch keine Möglichkeit, die konventionellen Details einzuarbeiten.
    • Das ist Sache der Fachbenutzer aus den Themengebieten.
    • 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.
    • Das geschieht per JSON-Handarbeit, ist aber nach kurzer Eingewöhnung gar nicht schwierig. Nur mit unbedarften " sowie freien | gäbe es Syntaxprobleme, ansonsten geht es per C&P. Der Rest lässt sich aber auch immer lösen. Beispiele für Parameterwerte als Vorlagen mit geschweiften Klammern würde ich ggf. abschließend nachrüsten; die bedürfen einer etwas spezielleren Syntax.
    • Ab sofort würden auch VE-Bearbeiter alle Details sehen; die untere Tabelle sollte jedoch abschließend eliminiert werden.
    • Falls du damit gut klar kämest, gäbe es noch mehr davon.
  • „Leichter mit Vorlagen arbeiten“ sollte sich erstmal an die Autoren der enzyklopädischen Artikel richten.
    • Programmieren und dokumentieren von Vorlagen ist etwas für Fortgeschrittenere, die etwas mehr über Strategien, Management, Organisation wissen.
    • Die Syntaxhervorhebung in Vorlagencode ist auf der Wunschliste und beträfe Programmierung. Das ist dann aber auch schon alles.
    • Vorlagenprogrammierung mit VisualEditor geht nicht und gibt Bruch, weil das unvollständige, komplexe, aus eingebundenen Vorlagen fallweise unter manchen Bedingungen zugelieferte Syntaxkonstrukte erfordert. Das ist und bleibt Handarbeit.
    • Es ist absolut nicht Aufgabe der Autoren enzyklopädischer Artikel, mal eben zwischendurch mit der linken Hand eine TemplateData-Beschreibung zu generieren. Da kann nur Stuss rauskommen. Dazu muss man sich schon ernsthaft und intensiver mit der Vorlage selbst, mit ihrer Programmierung, mit ihrer sonstigen Anwendung beschäftigen, und nicht mitten im enzyklopädischen Artikel aufs Gratewohl irgendwelchen Quatsch zusammentippen.

VG --PerfektesChaos 16:12, 7. Okt. 2020 (CEST)

Hallo @PerfektesChaos: entschuldige bitte, dass ich so spät antworte.  ↓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 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 können.
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 nicht die Möglichkeit, 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 oder ähnliche 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 --Dirk123456 (Diskussion) 20:31, 28. Mär. 2021 (CEST)

Technische Wünsche: Freiwillige für "Vorlagen"-Nutzungstests gesucht

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 

Vorlagen können hilfreich sein beim Schreiben und Editieren von Artikeln - jedoch auch manchmal ziemlich verwirrend. Deswegen haben wir im Rahmen des Wunsches Leichter mit Vorlagen arbeiten erste Prototypen entwickelt. Um diese zu testen, suchen wir nun Freiwillige, die zu einem Nutzungstest bereit wären.

Wen genau suchen wir?
Wenn du Vorlagen verwendest oder diese sogar erstellst und pflegst, dann würden meine Kollegen und ich gerne in einem Videotelefonat von dir Feedback bekommen. Wir suchen nach Wikipedianerinnen und Wikipedianern mit einem breiten Erfahrungsspektrum. Von Wikipedianerinnen und Wikipedianern, die Vorlagen und TemplateDaten (in JSON oder mit dem TemplateData-Editor) schreiben und pflegen, bis hin zu solchen, die für ihre Bearbeitung ausschließlich den Visual Editor verwenden.

Wie wird der Test ablaufen?
Die Tests sollen in einem Videoanruf (z.B. meet.google.com) durchgeführt werden. Dabei werden wir dir Aufgaben geben und dich bitten diese zu lösen. Dies sollte zwischen 45-60 Minuten dauern. Wir möchten erfahren, wie du mit den vorgeschlagenen Verbesserungen umgehst und wie sie sich deiner Meinung nach in deine derzeitigen Arbeitsabläufe integrieren lassen. Deinerseits ist keine Vorbereitung für den Nutzungstest erforderlich. Deine Teilnahme kann im Rahmen eines Gutscheins kompensiert werden. Die Art der Kompensation hängen von dem Land ab, in dem du wohnst.

Wie kannst du dich anmelden?
Wenn du teilnehmen möchtest, fülle bitte dieses Online-Formular aus. Wir werden dich kontaktieren, um einen Termin für ein Online-Treffen zu vereinbaren. Wenn du weitere Fragen hast, stelle diese einfach auf der Diskussionsseite des Wunsches! -- Für das Team Technische Wünsche: Max Klemm (WMDE) (Diskussion) 15:02, 20. Okt. 2020 (CEST)

Community-Wunschliste 2021

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 

Du erhältst diese Nachricht, weil du dich für den Newsletter Technische Wünsche eingetragen hast. Danke dafür!

Ab heute Abend (16.11, 19 Uhr) läuft die jährliche Community-Wunschliste der Wikimedia Foundation. In dieser wird ermittelt welche technischen Verbesserungen die Wikimedia Communities sich am meisten wünschen. Basierend darauf wird das Community Tech-Team im kommendem Jahr einige der Wünsche umsetzen. Vom 16. bis 30. November können Wünsche – auch auf deutsch – im Meta-Wiki eingereicht werden. Vom 8. bis 21. Dezember läuft dann die Abstimmung. -- Michael Schönitzer (WMDE) (Diskussion) 17:58, 16. Nov. 2020 (CET)

Technische Wünsche zu Geoinformationen gesucht

Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
 

Du erhältst diese Nachricht, weil du dich für den Newsletter Technische Wünsche eingetragen hast. Danke dafür!

Der Schwerpunkt „Bessere Unterstützung von Geoinformationen“ wurde in der Umfrage „Technische Wünsche 2020“ zum Gewinner gewählt. Das bedeutet, dass das Team Technische Wünsche von Wikimedia Deutschland sich zwei Jahre mit diesem Themenfeld beschäftigen wird und verschiedene Probleme darin angehen. Als erster Schritt dafür läuft derzeit die Recherche nach Problemen und Bedarf. Dafür laden wir alle ein auf dieser Projektseite Probleme, Wünsche und Ideen zu sammeln, strukturieren, weiterentwickeln und diskutieren. Um ein noch besseres Bild für die Probleme und Arbeitsweisen rund um das Thema Geoinformationen zu haben, suchen wir Freiwillige, welche sich für ein kurzes Interview bereit erklären. Wenn du Interesse hast, trag dich auf dieser Liste ein. -- Michael Schönitzer (WMDE) (Diskussion) 19:06, 16. Dez. 2020 (CET)

Nachträge zum Archiv

Ausschnitt der Versionsgeschichte der Diskussionsseite für das Jahr 2020

Ausschnitt der Versionsgeschichte
UTC+0 Usr ./K Bytes Änd. Zusammenfassungszeile a) Zusammenfassungszeile b)
2020-12-16T18:06:20 Michael Schönitzer (WMDE) . 69.087 Bytes +1.634 Neuer Abschnitt →Technische Wünsche zu Geoinformationen gesucht
2020-11-16T16:58:22 Michael Schönitzer (WMDE) . 67.453 Bytes +981 Neuer Abschnitt →Community-Wunschliste 2021
2020-10-20T13:02:56 Max Klemm (WMDE) . 66.472 Bytes +2.299 Neuer Abschnitt →Technische Wünsche: Freiwillige für "Vorlagen"-Nutzungstests gesucht
2020-10-07T14:12:37 PerfektesChaos . 64.173 Bytes +4.983 Neuer Abschnitt →Deine umfangreiche Ausarbeitung zu „Technische Wünsche“ / Leichter mit Vorlagen arbeiten
2020-09-17T11:49:20 Dirk123456 . 59.190 Bytes +2.280 Neuer Abschnitt →Einzel-Projekte, Syntaxhervorhebung, Klammerpaare (an mich selbst)
2020-09-08T13:43:46 Wurgl K 56.910 Bytes +486 →Vorlagenfinder
2020-09-08T12:06:11 Dirk123456 . 56.424 Bytes +1.044 →Vorlagenfinder: (Antwort.)
2020-09-08T10:51:03 Wurgl . 55.380 Bytes +169 Neuer Abschnitt →Vorlagenfinder
2020-07-30T23:28:23 MediaWiki message delivery . 55.211 Bytes +2.537 Neuer Abschnitt →Ergebnisse der Umfrage Technische Wünsche 2020
2020-07-14T13:25:53 Robin Strohmeyer (WMDE) . 52.674 Bytes +547 →Technische Wünsche: Interview zur Nutzung von Vorlagen im Visual Editor (Bearbeitung.)
2020-07-10T16:46:32 Dirk123456 . 52.127 Bytes +2.935 →Technische Wünsche: Interview zur Nutzung von Vorlagen im Visual Editor: Antwort (Anker Dirk123456.2020-07.ewf-az95h-vb3i).
2020-07-06T10:29:07 Robin Strohmeyer (WMDE) . 49.192 Bytes +1.418 Neuer Abschnitt →Technische Wünsche: Jetzt abstimmen!
2020-06-29T17:12:20 Robin Strohmeyer (WMDE) . 47.774 Bytes +841 Neuer Abschnitt →Vorankündigung: Umfrage Technische Wünsche kommt
2020-06-24T13:07:47 Max Klemm (WMDE) . 46.933 Bytes +2.256 Neuer Abschnitt →Wunscherfüllung: zusätzliche Oberfläche zum Lösen von Bearbeitungskonflikten auf Diskussionsseiten ist nun Standard auf der deutschsprachiger Wikipedia
2020-06-03T12:11:41 Max Klemm (WMDE) . 44.677 Bytes +1.588 Neuer Abschnitt →Digitaltreff Technische Wünsche - 15.06.
2020-05-07T17:12:43 Robin Strohmeyer (WMDE) . 43.089 Bytes +691 Neuer Abschnitt →Technische Wünsche: Interview zur Nutzung von Vorlagen im Visual Editor
2020-03-26T16:18:58 Michael Schönitzer (WMDE) . 42.398 Bytes +1.881 Neuer Abschnitt →Technische Wünsche: „Leichter mit Vorlagen arbeiten“ – Vorstellung erster Projektideen
2020-03-25T15:15:19 Max Klemm (WMDE) . 40.517 Bytes +2.169 Neuer Abschnitt →Technische Wünsche: Neue Standardoberfläche zum Lösen von Bearbeitungskonflikten (Wunscherfüllung)
2020-02-25T12:59:33 Max Klemm (WMDE) . 38.348 Bytes +1.489 Neuer Abschnitt →Technische Wünsche: Zusätzliche Oberfläche für Bearbeitungskonflikte auf Diskussionsseiten
2020-01-03T16:33:15 Dirk123456 K 36.859 Bytes −2 →Projekt Vorlagen - Ende 2019 (Bearbeitung.)
2020-01-03T16:32:12 Dirk123456 . 36.861 Bytes +1.784 (Neuer Abschnitt) Projekt Vorlagen - Ende 2019
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Dirk123456/Archiv/2020&oldid=223478761“