Vorlage Diskussion:Doku

Beschreibung:	Diese Vorlage dient der Dokumentation von Vorlagen
Parameter:	Beschreibung = Beschreibungstext Parameter = verwendete Parameter
Namensräume:	Vorlage_Diskussion, Vorlage

Brainstorming vom WiMu

Also ich stelle mir das so vor: jede (ja, wirklich jede) Vorlage kriegt auf die Diskussionsseite das Ding da vorne verpasst, und zwar als aller ersten Abschnitt. Die Vorlage funzt je nach Namensraum anners: hier auf der Vorlagen-Diskussionsseite wird die Doku mit den enstprechenden Parametern befüllt, ungefähr so:

{{Doku
| Beschreibung = blahblah-Text
| Kategorie    = z.B. siehe-auch Vorlagen
| Autokats     = z.B. Hat was
| Parameter    = 
parameter1 = macht dieses
parameter2 = macht jenes
| Namensräume  = Liste der Namensräume, in denen die Vorlage verwendet werden sollte
| Beispiel     = irgendein per DPL zuällig ausgewähltes Beispiel
| usw.
}}

In allen anderen Namensräumen lässt sich mit {{Doku|Titel}} per DPL die Dokumentation der Vorlage:Titel anzeigen und im Namensraum Vorlage ohne Angabe des Titels die Doku dieser Vorlage (schlicht {{Doku}}).
Angezeigt soll – bis auf einige obligatorische Parameter – nur das werden, was auch ausgefüllt wurde, bzw. so viel wie möglich per DPL automatisieren (z.B. eben das Anzeigebeispiel); also in etwa so wie bei unserem Kamelionary.
Anwendungsbeispiele der Dokus neben der eigentlichen Dokumentation auf jeder Vorlagenseite

• Fehlerbehebung: zum Beispiel ließen sich die Vorlagen-Kategorien über diese Doku erzeugen, und wenn eben die Angabe der Kat fehlt, erscheint eine Fehlermeldung mit Liste aler Vorlagen-Kategorien (nur ein Beispiel)
• Qualitätssicherung:
  • auf einer zentralen Vorlagen-Qualitätssicherungs-Seite per DPL nach Vorlagen suchen, die sich nicht im angegebenen Namensraum befinden (z.B. Vorlage:Bild auf einer Bild-Diskussionsseite, vermointe Kamelbauten, etc.)
  • man könnte in einem Parameter alle parser-Funktionen angeben, die für die jeweilige Vorlage benötigt werden, und dann nach einem update gezielt nach bugs suchen
• Zentrale Vorlagen-Seite: alle Dokus auf einer zentralen Seite per DPL sammeln, nach Vorlagen-Kategorien sortiert. Allerdings wegen der Übersichtlichkeit und Performance wegen zunächst nur den Vorlagen-Namen und den Parameter Beschreibung. Das restliche Gedöhnse würde ich nicht (wie bisher, glaube ich) mit unserem einklapp- ausklapp- Dingens verstecken, sondern nach klick auf einen butten per ajax von der MediaWiki-API holen. Dann dürften auch 1000 Vorlagen ganz fix geladen werden, und dennoch können wir in die Dokus jede noch so belanglose Info stopfen und DPLqueries machen, wie viele wir wollen.

Beschreibungs-Parameter

kann gerne ergänzt werden:

• Hinweis: verschiedene Hinweis-Texte, durch die durchgeswitcht wird; z.B.: inuse (an der Vorlage wird noch gebaut), veraltet (Vorlage wurde durch eine neuere Vorlage ersetzt), begraben (Vorlage soll begraben werden), etc.
• Beschreibung: eine Beschreibung dessen, was die Vorlage tut
• Kategorie: Kategorie, in die die Vorlage gehört
• Autokats: Kategorien, die mit dieser Vorlage eingebunden werden
• Parameter: Parameter eben, und was die tun
• Namensräume: Liste der Namensräume, in der die Vorlage verwendet wedren sollte
• Beispiel: ein Beispiel eben
• Versionsinfo: Entstehungsdatum, Erstautor, Letzte Bearbeitung, Anzahl der Bearbeitungen, Autorenliste, Größe der Vorlage (in Bytes)
• Seiteninfo: Anzahl der Seiten, die diese Vorlage verwenden (evtl. zufällig zusammengewürfelte Liste mit 10 Beispielseiten)
• Verwendete Dateien: Liste der Bilder, die von der Vorlage verwendet werden
• Verwendete Vorlagen: Liste der Vorlagen, die von der Vorlage verwendet werden.
• Verwendete Funktionen: Liste der Parser-Funktione und Extensions, die verwendet werden.
• Seitenschutzstatus: wer darf editieren?

• Weiterführende Dokumentation: Wo finde ich weitere Informationen

• Bemerkungen: Ist etwas speziell bei der Verwendung zu beachten?

... mir fällt bestimmt bald noch mehr ein.

Alles in allem, würde ich bei der Gelegenheit mal ganz gerne unsere gesamten Vorlagen-Namensraum entmüllen; z.B. braucht die ollen uralt Quellen&Lizenz-Vorlagen kein Schwein mehr; teilweise haben sich die Vorlagen überholt (z.B. link-Bild); teilweise sind die Dinger mangels unserer tollen, neuen extensions ziemlich gruselig zusammengeschustert, etc. Auch hätte ich mal gerne ein paar verbindliche Programmier-Richtlinien, etwa, dass sich jede Autokat mit jeweils dem gleichen Parameter (z.B.: Kat) deaktivieren lassen muss, usw. So, man sieht: Sommerloch ... mir ist langweilig! Vorschläge und Sempf bitte jetzt. --WiMu 22:52, 4. Jul. 2010 (NNZ)

P.S.: merke gerade, dass DPL ziemlich schlampig programmiert ist. Bei include = {Doku} wird anscheinend per regulärem Ausdruck nach dem Text {{Doku|...}} gesucht, und es wird gar nicht weiter geprüft, ob damit wirklich auch die Vorlage aufgerufen wird, oder ob da – wie hier an einigen Stellen – ein <nowiki> oder <pre> drumrum ist. Das macht die Sache natürlich kompliziert (und wenn nun vorne plötzlich 5-10 so Tabellen zu sehen sind, lieg's genau daran). Evtl. dann doch die Dokus auf 'ne Unterseite verfrachten (fände ich aber sehr, sehr doof) --WiMu 23:01, 4. Jul. 2010 (NNZ)
P.P.S.: diesen DPL-bug könnte aber sogar ich mit meinen bescheidenen PHP-Kentnissen beheben ... vielleicht mal Teule fragen, ob ich darf ...

Ich werde heute (bei uns) und heute (bei euch) leider keine Zeit dazu haben mich tiefer damit zu beschäftigen, muss morgen (bei uns) zuerst mal Strafanzeige gegen meinen Nachbarn einreichen, der hat sich nämlich unverschämter weise an meine Stromleitung geklemmt... aber so beim Durchfliegen möchte ich mal (ohne deinen Enthusiasmus bremsen zu wollen) fragen: Bist du sicher, dass wir da nicht ein bisschen übers Ziel hinausschiessen?

PS: ajax bedingt java, hat aber nicht jedes Kamel.

PS: Programmier-Richtlinien, etwa, dass sich jede Autokat mit jeweils dem gleichen Parameter (z.B.: Kat) deaktivieren lassen muss, usw. Ja, würde ich unterstützen, aber diverse Vorlagen brauchen das nicht, weil sie nicht frei einfügbar sind (zB. subvorlagen) und deshalb nur Memory versauen würden. Damit hätten wir dann schon Ausnahmen geschaffen, was automatisch zur Anarchie führt. Da sehe ich eher die Devise; was die Vorlage selbst nicht unbedingt braucht, entfernen (Katdeaktivierung für Normalkamelvorlagen ausgenommen).

PS: Verwendete xxxxx, Versionsinfo, Seiteninfo & Seitenschutzstatus bist du sicher, dass das irgend ein Kamel interessiert? Kameloid 01:26, 5. Jul. 2010 (NNZ)

Hi, Kameloid ... das ist ja ein starkes Stück mit deinem Nachbarn, da wünsche ich dir ertsmal viel Glück und 'nen Batzen Schadensersatz.

Zu deiner Frage: nö, ich bin mir im Gegenteil sicher, dass wir damit übers Ziel hinaus schießen, aber das tun wir meiner Meinung nach z.B. auch mit unserer Bild-Vorlage, die weit mehr Info enthält als sein müsste, aber trotzdem gerade deshalb um Längen besser ist, als entsprechendes Gedöhnse in der Wikipedia. Es ist ja so, dass es viel viel leichter ist, bestimmtes Zeug im nachhinein wieder zu entfernen (einfach entsprechenden Parameter aus der Vorlage nehmen), als umgekehrt neue Parameter im nachhinein hinzuzufügen (dann müsste man ja alle Seiten anpassen). Nicht kleckern, sondern klotzen ...

Wegen ajax: ja, das ist sicher ein Problem, aber wirklich andere Alternativen sehe ich da nicht. Man könnte natürlich die komplette Doku anzeigen lassen und per klipp/klapp verstecken (wie bisher), aber dann kriegt man Latenzen von 'ner Minute und mehr ... von den verschleuderten server-ressourcen ganz zu schweigen. Oder aber man zeigt auf der Übersichtsseite nur eine Auswahl der Vorlagen an ... finde ich inkonsequent und suboptimal. Eine Lösung könnte sein, komplette Dokus auch über {{#arg:}}-Parameter "ausklappen" zu lassen für die Kamele, die javascript nicht aktiviert haben. Dann müsste allerdings bei klick auf irgendeinen button die komplette Seite neu geladen werden ... dürfte aber trotdem nutzerfreundlicher sein als 1000 Vorlagen vollständig laden zu müssen. Einfach mal ausprobieren ...

Autokatz: gerade bei subvorlagen sollte man so 'ne Doku haben, in der dann drinne steht: nicht verwenden, sondern Vorlage xy ... – hat jetzt mit den Katz nix zu tun, aber trotzdem. Sinnvoll ist das bei subvorlagen nur dann, wenn die Kategorisierung von der übergeordneten Vorlage aus deaktiviert werden kann ... sollte machbar sein, aber dazu braucht es eben auch bei subvorlagen einen solchen Parameter. Also so ungefähr: {{Bild|blahblah|Kat=}} ... und die leere Variable "Kat" dann an sämtliche Vorlagen weiterreichen. Der Aufwand an Memory dürfte verschwindend gering sein.

Verwendete xxx: also irgend ein Kamel interessiert es ganz sicher, nämlich mich *g*. Im ernst: wenn man mal versucht, eine etwas kompliziertere Vorlage mit 100 Unter- und 100 Über-Vorlagen aus der Wikipedia hierherzukopieren, und feststellt, dass man den Quellcode von zig Seiten durchforsten muss, um genau an diese Info zu kommen ... ja ich halte das für sehr sinnvoll. Nehmen wir mal z.B. die verwendeten Dateien ... gibt hunderte Möglichkeiten, wie Wiki nicht mehr mitkriegt, welche Bilder geladen werden; vom choose-Zeug über css und imagemap, usw. und teilweise (z.B. bei Zufalls-Zeug oder if-Konstruktionen) sieht man diese Dateien auch nicht zwangsläufig. Da wäre es doch besser, sie notfalls manuell in 'nem Parameter anzugeben (und am besten auch gelistet anzeigen zu lassen), um diesen bug zu beheben. Oder eben die Fehlersuche ... Kamel merkt irgendwo irgend ein Problem und will die Vorlage fixen ... da ist es schon praktisch, auf einen Blck zu sehen, dass der Fehler evtl. an irgendeiner der 20 Unter-Vorlagen hängt, usw. Auch die Anzahl der Vorlagen-Verwendung, ist sicher für die Pflege hilfreich, z.B. wenn eine Vorlage 5 Jahre alt, aber nur 2mal benutzt wird ... dann kann sie wohl weg, usw. Das mit den Autoren und so ... naja, braucht wirklich niemand, aber hübsch fände ich's trotzdem ... Grüße, --WiMu 11:04, 5. Jul. 2010 (NNZ)

P.S.: *koppklatsch* Bilder-Kats ... man hätte ja auch den Namensraum prüfen und nur die Bild-Seiten in entsprechende Kategorien stopfen können ... schön, dass mir das jetzt zwei Jahre später einfällt ...