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

Links

Hauptseite der Umfrage: Wikipedia:Umfragen/Technische Wünsche 2020 Themenschwerpunkte

Diskussion: Wikipedia Diskussion:Umfragen/Technische Wünsche 2020 Themenschwerpunkte

Ausgewählte Permutation: https://de.wikipedia.org/w/index.php?title=Wikipedia:Umfragen/Technische_W%C3%BCnsche_2020_Themenschwerpunkte&oldid=201720271

Startpunkt für die Ausformung zum Diskussionsbeitrag: https://de.wikipedia.org/w/index.php?title=Benutzer:Dirk123456/Baustellenbaustelle_001/Baustelle-D/Baustelle-D.11&oldid=201956125

Letzte Abstimmung (Juni 2019)

A

Tools leichter entwickeln und finden (Tsp-1 ↓ )
Bessere Unterstützung von Grafik, Audio, Video & Co (Tsp-2 ↓ )
Einfach einheitliche Typografie in Artikeln erzeugen (Tsp-3 ↓ )
Zusammenarbeit on-Wiki leichter machen (Tsp-4 ↓ )
Vandalismus und destruktive Handlungen besser bekämpfen (Tsp-5 ↓ )
Fehler bei der Arbeit mit Belegen reduzieren (Tsp-6 ↓ )
Von Inhaltsänderungen erfahren, die mich interessieren (Tsp-7 ↓ )
Bessere Unterstützung von Geoinformationen (Tsp-8 ↓ )
Hilfestellung beim Bearbeiten von Artikeln (Tsp-9 ↓ )

Z

Auswahl der Themenschwerpunkte

Hallo,

um nachvollziehbar zu machen, wie ich (Dirk123456 / Disk) bei der meiner diesjährigen Planung zur Umfrage/ Abstimmung zu den Themenschwerpunkten vorgegangen bin, habe ich das sozusagen ein wenig „protokolliert“. Ich habe eine Benutzerseite (Baustelle) angelegt und dort einige Links zu den relevanten Projekt- und Diskussionsseiten gespeichert. Danach wollte ich mir die Reihenfolge der Kandidaten vergegenwärtigen, um daraus meine Favoriten-Liste zu „basteln“. Ein Blick in die Versionsgeschichte von "Wikipedia:Umfragen/Technische Wünsche 2020 Themenschwerpunkte" zeigte mir, dass die „Startnummern“ der Kandidaten aller vier Stunden ausgetauscht wurden/ werden.

Das hat Vor- und Nachteile. Der größte Vorteil besteht darin, dass man sicherlich einen objektiveren Blick entwickeln kann, wenn man die Karten unterschiedlich mischt, als wenn immer dasselbe oben steht. Der größte Nachteil ist, dass man einen Themenschwerpunkt schwer wiederfindet, wenn er immer an unterschiedlicher Stelle steht.

Ich habe mir irgendeine Permutation heraus gegriffen, um die neun Kandidaten mit „Startnummern“ zu versehen. Es ging mir vor allem darum, für mich selbst zu wissen, was ich schon ausgewertet habe und was noch nicht. Die herausgegriffene Permutation ist die vom 9. Juli 2020 um 12:02 Uhr (siehe Version: oldid=201720271). Die neun Themenschwerpunkte (Tsp) haben die „IDs“ oder eben die „Startnummern“ Tsp-1 bis Tsp-9 erhalten.

Dann habe ich eine Art „Selbstgespräch“ geführt, wobei ich zu jeden Punkt die Pros und Kontras notiert habe. Zwischenzeitlich habe ich immer mal wieder zwei Themenschwerpunkte hinsichtlich ihrer Relevanz aus meiner Sicht miteinander verglichen. Ziel war es, ungefähr eine Hälfte der Schwerpunkte zu wählen und die andere Hälfte abzuwählen. Während ich meine Auswahl letztes Jahr eher danach getroffen habe, ob ich mir eine Verbesserung wünsche, habe ich sie dieses Jahr eher danach getroffen, ob ich eine Verbesserung für wahrscheinlich halte. Wenn ich zwei Schwerpunkte als ähnlich eingeschätzt habe, habe ich denjenigen favorisiert, der meinen Vorstellungen mehr entsprach.

Finale Auswahl

Am Ende habe ich drei Schwerpunkte ausgewählt:

Zusammenarbeit on-Wiki leichter machen ←zur Abstimmung
Tools leichter entwickeln und finden ←zur Abstimmung
Fehler bei der Arbeit mit Belegen reduzieren ←zur Abstimmung

Es folgen meine Gedanken zu den Themenschwerpunkten in der Reihenfolge ihrer Kandidaten-Startnummern Tsp-1 bis Tsp-9. Die Beschreibungen, die ich kommentiert habe, findet man am besten durch den jeweiligen Link „←zur Abstimmung“.

Tools leichter entwickeln und finden (Startnummer Tsp-1) ←zur Abstimmung

Das ist ein zweischneidiges Schwert. Der Text zu „Was bedeutet das?“ spricht aus meiner Sicht etwas dagegen – vor allem wegen der Passage: „Es sollte einfacher sein, Tools zu entwickeln“. Das klingt ein wenig so, als wenn es noch mehr Tools werden sollen. Der Text zu „Kommentar Team Technische Wünsche“ spricht für den Schwerpunkt – vor allem wegen der Passage: „... geht es nicht darum ... zu reparieren, sondern um strukturelle Verbesserungen“.

Ich bin im Bereich Entwicklung für weniger Wildwuchs. Ich denke, dass Einschränkungen zwar die Motivation beeinträchtigen können, auf der anderen Seite ist die Wikipedia bereits zu komplex für ungezügelte Kreativität.

Bessere Unterstützung von Grafik, Audio, Video & Co (Startnummer Tsp-2) ←zur Abstimmung

Ich sehe dort zwei Aspekte: die eigentliche Enzyklopädie (also den Artikelnamensraum, WP:ANR) auf der einen Seite und die Kommunikation im „Backstage-Bereich“ (also auf Projekt- und Diskussionsseiten) auf der anderen Seite. Der zweite Aspekt, die Einbeziehung von verschiedenen Medien-Typen in die Kommunikation, würde vielleicht ganz gut zum Themenschwerpunkt „Zusammenarbeit on-Wiki leichter machen“ passen.

Für den ersten Aspekt, die Einbeziehung von verschiedenen Medien in Enzyklopädie-Artikel, ist vermutlich eine andere Hürde erforderlich, als für die Diskussion unter Wiki(m|p)edianerinnen und Wiki(m|p)edianern. Das „Aufmotzen“ von Enzyklopädie-Artikeln per Knopfdruck darf nicht zum Ersatz für das Schreiben von richtigem Text werden, weil es so schön bequem ist. Es besteht sonst die Gefahr, dass mehr Material im jeweiligen Artikel landet, als irgendjemand jemals überprüfen können wird.

Einfach einheitliche Typografie in Artikeln erzeugen (Startnummer Tsp-3) ←zur Abstimmung

Da halte ich nicht das allermeiste davon – glaube ich zumindest. Ich habe drei Gründe für meine Zurückhaltung ausgemacht:

Der erste Grund für meine Zurückhaltung ist der Text „einheitliche Typografie ... erzeugen“, der für mich ein bisschen so klingt, wie „einheitliche Typografie ... erzwingen“ und
der zweite Grund betrifft mein mangelndes Vertrauen in die Machbarkeit.
Der dritte Grund betrifft den von mir erwarteten Aufwand. Wenn ich mich mal gedanklich neben die ersten beiden Gründe stellen würde und davon ausginge, dass die Typografie-Unterstützung so ähnlich laufen könnte, wie eine Grammatik- und Rechtschreibungs-Überprüfung in einem Textverarbeitungs-Programm (die man gegebenenfalls ignorieren oder abschalten kann), glaube ich nicht, dass andere Themenschwerpunkte für diesen zurückgestellt werden sollten.

Es ist richtig, dass nicht jeder eine Spezialausbildung auf dem Gebiet allgemeine Typografie hat – ich auch nicht. Nun ist es so, dass die Enzyklopädie Wikipedia kein Fachwörterbuch eines bestimmten, gut abgegrenzten Themenbereichs ist, sondern sozusagen das „Weltwissen“ sammelt und im hier betrachteten Fall in deutscher Sprache verfügbar macht.

Es gibt meines Wissens keine durchgängige, „weltbeschreibende“ Typografie, sondern Regeln, Konventionen und Empfehlungen für allgemeine Themen und einzeln festgelegte Regeln für einzelne Sachgebiete.

Diese einzelnen Regeln können sehr einzeln sein; in der Biologie wird beispielsweise die Kursivschrift ziemlich unterschiedlich eingesetzt – je nachdem, welcher Aspekt den Fokus hat. Der folgende, als Aufzählung gestaltete Textblock kann gegebenenfalls übersprungen werden; er dient lediglich der Demonstration von Vielfalt bei der Anwendung von Kursivschrift in der Biologie.

Wenn es um Symbole für Gene und die zugeordneten Proteine geht,
- werden die Gene bei Bakterien meist klein und kursiv geschrieben, die Proteine aber groß (und nicht kursiv),
- während bei Säugetieren beide Formen groß geschrieben werden, die Gen-Symbole kursiv und die zugeordnete Form für die Proteine nicht kursiv.
  - Wenn es speziell um den Vergleich zwischen Mensch- und Maus-Genen bzw. -Proteinen geht, werden die Symbole beim Menschen oft durchgehend groß geschrieben, bei der Maus nur der Anfangsbuchstabe (z. B. Glycerinaldehyd-3-Phosphat-Dehydrogenase – menschliches Gen: GAPDH, menschliches Protein: GAPDH, Maus-Gen: Gapdh, Maus-Gen: Gapdh).
Wenn es um taxonomische Einheiten geht,
- werden die Gattungen und Arten häufig kursiv geschrieben, die übergeordneten Taxa aber nicht;
  - das gilt jedoch nicht immer; gerade, wenn der „vollständig qualifizierte Name“ mit Autorenschaft und dem Jahr der Beschreibung (oder der Anerkennung durch ein entsprechendes Gremium) angegeben wird, ist der eigentliche Name des Taxons meist kursiv hervorgehoben, auch wenn es einen Rang oberhalb der Gattung hat (also Familie, Klasse usw.).

Wenn mehrere Aspekte zusammen kommen, hilft es nicht viel, bei allen Kursivschrift einzusetzen, weil das dann keine Hervorhebung mehr wäre.

Welche Typografie zweckmäßig ist, hängt auch viel von den technischen Voraussetzungen ab. Bei einer Enzyklopädie, die als gedrucktes Werk erscheint, beschäftigt man sich mit dem richtigen Abstand von Seitennummern zu den Seitenrändern, in einer Online-Enzyklopädie eher nicht. Wenn nur der Schreibmaschinensatz zur Verfügung stünde, müsste die Frage, welches die „richtigen“ Anführungszeichen seien, anders beantwortet werden, als bei größerer Auswahl.

„Normalerweise“ werden im Deutschen, wenn mehrere Paare von Anführungszeichen ineinander geschachtelt werden müssen, die doppelten außen („“) und die einfachen innen (‚‘) verwendet. Ein Zitat zum Themenschwerpunkt würde auf diese Weise folgendermaßen lauten: „Und was waren nochmal die ‚richtigen‘ Anführungszeichen?“.

Wenn man diesem Satz deshalb zitieren möchte, weil es thematisch um die Anführungszeichen selbst geht, die um ein einzelnes Wort (richtigen) gesetzt worden sind, wird eine Erörterung dieses Themas schwierig, weil im Original andere Anführungszeichen verwendet wurden, als im Zitat. Nun gibt es sicher auch zu schwierigen Fällen Empfehlungen und Regeln und auch die Wikipedia selbst bietet dazu etwas an:

Enzyklopädie (Artikelnamensraum, WP:ANR; ausgewählte Artikel):

Meta-Bereich (Namensräume Wikipedia und Hilfe):

Wikipedia:Typografie

Ich habe für die Artikel-Suche die Zeichenketten typogr bzw. typograf im Visual Editor eingegeben (Menü-Punkt Link) und für die „Meta-Suche“ die gleichen Zeichenketten mit den davor platzierten Präfixen H: und WP:. Dass man sich gut mit den Namensräumen auskennen muss, um die vielen Seiten zu finden, die Kandidaten für das jeweilige Anliegen sein könnten und viel Zeit aufbringen muss, um die Information auszuwerten und zu filtern, ist ein übergeordnetes Thema und weniger eins, dass allein die Typografie betriftt. Dazu hatte ich schon mal etwas geschrieben, als es um das Schwerpunktthema „Leichter mit Vorlagen arbeiten“ aus 2019 ging (Beitrag #Leichter_finden, August 2019).

Ich denke, dass man bei verbindlichen Regeln zur Typografie in der deutschen Sprache autorisierte Stellen bemühen sollte. Der Duden beispielsweise, ist in seiner Online-Version leider mittlerweile mehr eine Werbewand, als ein Informationsportal (https://www.duden.de/). Insofern sind Seiten in der Wikipedia ein guter Anhaltspunkt, um sich zu informieren.

Allerdings sollten wir es vermeiden, richtige Typografie zu erfinden:

„Wikipedia ist keine Quelle“ (-; steht so in der Wikipedia, sogar der Namensraum, wo das steht, heißt Wikipedia, siehe WP:WPIKQ! ;-)

Die Besonderheiten zur Typografie in weiterem Sinne, die sich aus der Darstellung dieser Online-Enzyklopädie auf verschiedenen Ebenen selbst ergeben, sind natürlich von dieser Regel, dass die Wikipedia keine Quelle ist, teilweise ausgenommen.

Das betrifft solche Fragen, ob der Visual Editor (WP:VE, H:VE) in Vorlagen (H:Vorlagen) leere Parameter stehen lassen darf, ob man „wikipedianische Sonderzeichen“ in der Normal-Ansicht lieber durch HTML-Entities oder durch nowiki-Tags (H:Tags#nowiki) entschärft und Ähnliches.

Darum scheint es aber bei diesem Themenschwerpunkt nicht zu gehen; wobei die Frage: „Wie (und wo?) fügt man etwa ein geschütztes Leerzeichen ein?“ offen lässt, ob es um die technische Verwirklichung (wie) oder um Regeln geht (wo).

Ich fände es gut, wenn einige Zeichen nicht nur als HTML-Entities im Wikitext eingefügt werden könnten (z. B. das geschützte Leerzeichen:  ), sondern auch im Visual Editor (WP:VE, H:VE). Auch zwei weitere Paare öffnender und schließender Anführungszeichen: »« und ›‹ wären nützlich. Im Visual Editor werden bisher die Paare: „“, ‚‘, “”, „”, «» und ‹› angeboten.

Unter dem Strich finde ich richtige und aussagekräftige Typografie auf verschiedenen Ebenen wichtig, glaube aber, dass bei anderen Themen bessere Aussichten auf eine erfolgreiche Umsetzung bestehen, wenn sie gewählt werden.

Zusammenarbeit on-Wiki leichter machen (Startnummer Tsp-4) ←zur Abstimmung

Das entspricht am besten einem Schwerpunkt, den ich schon bei der letzten Abstimmung (2019-06) favorisiert hätte, wenn damals der Themenschwerpunkt: „Leichter und strukturiert diskutieren“ angeboten worden wäre.

Vandalismus und destruktive Handlungen besser bekämpfen (Startnummer Tsp-5) ←zur Abstimmung

Das ist mit Sicherheit ein wichtiges Thema. Allerdings kenne ich mit der jetzigen Vandalismusbekämpfung wenig aus und kann mir deshalb nicht vorstellen, wie eine bessere aussehen soll.

Fehler bei der Arbeit mit Belegen reduzieren (Startnummer Tsp-6) ←zur Abstimmung

Wenn etwas schon ziemlich gut funktioniert, dann ist dass die „Belegen“-Funktion des Visual Editors. Insofern sehe ich keinen dringenden Handlungsbedarf. Auf der anderen Seite wird im „Kommentar Team Technische Wünsche“ auf die solide Basis hingewiesen.

Von Inhaltsänderungen erfahren, die mich interessieren (Startnummer Tsp-7) ←zur Abstimmung

Es stört mich zwar, dass es so schwer ist, alles mitzubekommen, allerdings nicht so stark, wie andere Sachen, die mit den technischen Gegebenheiten zu tun haben. Das betrifft z. B. die Schwierigkeiten, die im Gewinner-Schwerpunkt „Leichter mit Vorlagen arbeiten“ unter „Häufigst genannte Probleme“ vom Team Technische Wünsche ziemlich gut herausgearbeitet wurden.

Bessere Unterstützung von Geoinformationen (Startnummer Tsp-8) ←zur Abstimmung

Damit habe ich mich noch gar nicht beschäftigt, daher habe ich dazu kaum eine Meinung.

Hilfestellung beim Bearbeiten von Artikeln (Startnummer Tsp-9) ←zur Abstimmung

Das ist zwar ein wichtiges Thema; es wird aber darauf verwiesen, dass es bereits „einige Aktivitäten“ gibt. Mir selbst fehlt da ein wenig die Vorstellung, wie man Neuautorinnen und -autoren am besten hilft. Ich denke, das es am besten über eine gut nachvollziehbare Infrastruktur geht.

MfG --~~

Weitere Antworten auf der Diskussionsseite

Bitte ein Wikipediaausschnitts-Offlineprogramm en miniature zum Artikel- oder Abschnittverfassen ==

Irgendwo hatte ich schon mal vor langer Zeit gelesen, dass sich das jemand über eine Linux-xy selbst gebastelt hatte. Leider fehlt mir die Ahnung dafür. So ein Offlineminiaturprogramm ist aus mehreren Gründen mein Wunsch. Die drei wichtigsten: Momentan schreibe ich neue Artikel im Schreibprogramm offline und gehe zwischendurch auf die Spielwiese zur Prüfung. Doch das ist umständlich und schreibend unübersichtlich, weil man ja für Referenzen nicht mit den üblichen Fußnoten arbeiten kann. Andererseits gefällt es mir aus verschiedenen Gründen überhaupt nicht, jedes Fitzel Arbeit an einem neuen Artikel und jede Minute WP-Schreibe über Unterseiten dokumentiert zu wissen. Bei bestehenden Artikeln, die man ausbauen möchte, ist dies sowieso nicht möglich. Und bei dem Gros, dass hier belegfrei oder mit zusammengepappten (Schein)Sammelbelegen als Literaturangaben unter dem Lemma daherkommt ist es noch einmal erschwert, muss man noch mehr nachdenken, wie man etwas einbaut, ohne das Nichtbelegte zu legitimieren, oder die Zusatzinfo passt nicht in das bestehende Schema. Man muss sich schlicht mehr Zeit nehmen und auch mal aufstehen können ohne online abzuspeichern. Manchmal möchte ich einfach auch vorerst Schluss machen, um die Änderung eine Nacht zu überschlafen. Über allem hängt zudem, dass man netzseitig nicht abgeschnitten werden darf oder dass die Übertragungsrate auf einmal sinkt. Ist mir schon öfter passiert. Vor allem war es ein Riesenproblem, als ich an der laaaangen Baudenkmalliste gearbeitet hatte. Da hilft nur, mangels echter Zwischenspeicherung, immer wieder Copy&Paste in eine Textdatei auf dem eigenen PC. Letztes: Dann könnte man auch im Zug o. ä. bedenkenlos schreiben. Man kann im Haus vorab mit PDF-Inhalten oder Printmaterial dort schreiben, wo es keinen Netzempfang gibt, ohne über das eigene Schreibprogramm zu gehen. Jenseits von Honeypots oder newsgehypten Artikeln sind Bearbeitungskonflikte nach meiner Erfahrung sehr selten. – Vielleicht gibt es noch mehr Interessenten? --Tozina (Diskussion) 13:17, 12. Jul. 2020 (CEST)

Es gibt mehrere Methoden, sich das der Wikipedia unterliegende Programm auf der eigenen Festplatte recht einfach zu erstellen. Ich verwende was mit EasyPHP Das zwar schon alt ist, aber immer noch den vollen Funtionalitätsumfang anbietet. Abgesehen davon schadet es überhaupt nicht, eine "eigene WP" lokal zu haben. Da kann man dann auch alles mögliche Ansammeln, wie Zeitungsberichte, Kochrezepte, Addressen, .... - und natürlich Artikel für die WP aufbauen. Je nachdem wie weit man gehen will, kann das dann auch zur Kollaboration im heimischen WiFi oder auch geschäftlich genutzt werden. Höchst empfehlenswert! Cheers, OAlexander (Diskussion) 05:36, 16. Jul. 2020 (CEST)

Der Hinweis stimmt mich hoffnungsvoll. Dankeschön, OAlexander. Es freut mich auch zu lesen, dass noch andere dieses Bedürfnis des zeitweiligen Offline-Arbeitens haben. "Eigene WP" ;-) ... auch interessant! Allein "Ich verwende was mit EasyPHP" bringt mir leider nichts. Ich hab da keine Ahnung vom grundlegenden Basteln. @Robin Strohmeyer (WMDE): Ist das wirklich so einfach? Wo gibt es eine BastelANLEITUNG? --Tozina (Diskussion) 22:27, 17. Jul. 2020 (CEST)

Antwort

Anker|Dirk123456_2020-0718.dur4m-d84j-hs8x}}Hallo Tozina,

Du bist tatsächlich nicht die Einzige, die sich ein Offline-Wikipedia-Artikel-Schreibprogramm wünscht. Sobald Du aber „Linux“ gesagt (oder geschrieben) hast, nimmst Du eine andere Abzweigung. Die Denkweise in den Unix/ Linux-, Perl-, PHP- und anderen, eher Kommando-Zeilen-lastigen Bereichen ist in einigen Punkten ähnlich, wie in der ursprünglichen Wikitext-Welt. „Easy“ kann in diesen Welten unter anderen zwei Sachen heißen:

das Tool ist Ressourcen-schonend, d. h., es ist auch für alte Computer leicht umzusetzen – oder/ und –
sehr wenig und dafür kryptischer Text hat eine weitgehende Wirkung.

In Unix/ Linux gibt es beispielsweise schon sehr lange den vi (visual interface), wo man alles über kurze Tastaturbefehle steuern kann, aber auch muss (:q beendet z. B. die Textverarbeitung).

Die Ausszeichnungssprache Wikitext wahr wohl ursprünglich so gedacht: man soll mit einfachen Sachen einfache Sachen machen – und außerdem online.

Ich helfe mir damit, dass ich einen Kompromiss eingehe. Ich bereite mehr oder weniger alles erst einmal vor.

Dazu lege ich eine Seite in meinem Benutzerbereich an, die ich als Baustelle deklariere. Dort nutze ich den VE (Visual Editor; WP:VE, H:VE), der eine grafische Benutzer-Oberfläche ist (GUI). Der VE arbeitet zwar auch nur online, ich kann aber jeden „Mist“ speichern, ohne dass dieser gleich in der „Produktiv-Umgebung“ landet.

Und da haben wir zwei völlig verschiedene Konzepte, was „einfach“ sein soll: mit dem vi aus der Linux-Welt kann man schnell „aus der Hüfte schießen“ und mit dem VE, der für die Wiki-Welt im aktuellen Jahrtausend entwickelt wurde, wird man ein wenig „betreut“.

Artikel-Inhalte lassen sich mit dem VE relativ direkt bearbeiten, bei Diskussionsbeiträgen sieht das anders aus. Auf denn Diskussionsseiten gibt es einige andere Interpretationen des Wikitextes, als z. B. auf Artikel-Seiten. Das betrifft vor allem die Einrückungen und Zeilenumbrüche. Daher ist der VE nicht direkt einsetzbar. Ich nehme in solchen Fällen zusätzlich ein „richtiges“ Textverarbeitungs-Programm und forme den zuvor kopierten Wikitext offline um.

Neulich hatte ich die zündende Idee, dass ich einen „Diskussionsbeitrags-Wikitext“ auch auf einer Diskussionsseite testen kann, statt auf einer Spielwiese, die „Artikel-Wikitext“ interpretiert; nämlich auf derjenigen Diskussionsseite, die meiner Baustelle-Benutzerseite zugeordnet werden kann.

Aber Vorsicht! Wenn Du abgespeicherten Wikitext kopierst, steht dort nicht mehr der Signatur-Code d'rin (vier Tilden: ~), sondern der konkret gespeicherte Signatur-Text. Deshalb schreibe ich meist MfG --~~ unten hin und hoffe, dass ich d'ran denke, zum Schluss noch zwei Tilden zu ergänzen.

Irgendwann möchte man Benutzer-Baustellen vielleicht auch mal löschen. Dazu kann – wie in „Wikipedanien“ üblich – ein kurzes, prägnantes Kommando im Wikitext an entsprechende Stelle untergebracht werden.

Das schreibe ich jetzt hier nicht direkt hin, sondern verweise auf die Vorlage-Seite (die ich gerade lange gesucht habe, weil ich den „Code-Namen“ nicht mehr wusste): Vorlage:Db-u1.

Also eigentlich kann ich auch nur hinschreiben: „Ich verwende da was mit Benutzerseiten, VE und einen Schreibprogramm auf meinem Computer“. Ein Tutorial gibt es dafür nicht.

Ich habe versucht, meinen prinzipiellen Arbeitsablauf einmal zu „protokollieren“ (das Beispiel betrifft eine Antwort auf einen Diskussionsbeitrag: Benutzer:Dirk123456/Baustellenbaustelle 001/Baustelle-D/Baustelle-D.10). Ob ich das selbst verstehen würde, wenn ich es nicht selbst geschrieben hätte, weiß ich nicht genau.

Ich bin also sehr interessiert, wenn Du etwas findest, was aus Deiner Sicht „easy“ ist!MfG --~~