Vorlage Diskussion:TemplateData/Archiv
Sortable
Nur mal eine ganz dusselige Frage, ist das generell sortierbar oder kann man die Klasse abschalten. Ich finde es sieht irgendwie merkwürdig aus, wenn man eine Tabelle mit nur einer Zeile genegiert und die dann sortierbar ist. So etwas lösche ich in Artikeln gewöhnlich, wenn nicht mindestens fünf oder mehr Zeilen vorhanden sind. --Liebe Grüße, Lómelinde Diskussion 16:21, 25. Jan. 2016 (CET)
- Die Frage ist nicht dusslig.
- Die Programmierer waren nicht auf die Idee gekommen, bei genau einer Zeile die sortable-Eigenschaft nicht reinzunehmen.
- Wir können hier praktisch nix machen.
- Du kannst aber Phabricator lernen und deine Anregung selbst vortragen.
- Oder du wartest, bis ich das irgendwann mal abarbeite.
- Im Übrigen bist du hier falsch; das Dingens malt nur einen blauen Rahmen und verlinkt auf das zuständige Hilfe:TemplateData.
- LG --PerfektesChaos 17:14, 25. Jan. 2016 (CET)
- Oups, ja stimmt ich wusste aber nicht so recht wo ich hin sollte, mit meiner Frage. Du weißt aber, was ich meinte. :-) Eigentlich war ich über diesen Syntaxfehler auf die Vorlage he gekommen und dann habe ich diese Tabelle gesehen und dachte warum macht er denn so etwas?
- Ich soll, och nööö nicht Phabricator, da verstehe ich kein Wort und würde mir noch dusseliger vorkommen, wenn ich so etwas anspreche. Übrigens wollte ich erst die Kurzform nehmen die du dann eingetragen hast. --Liebe Grüße, Lómelinde Diskussion 17:30, 25. Jan. 2016 (CET)
- Du kannst ruhig hier bleiben – verschieben lohnt nicht, ich habe es ja jetzt zur Kenntnis genommen, und hätte viel wilderes über diese Tabelle zu fluchen.
- Ja, das neue Syntaxhighlight unterscheidet nicht mehr zwischen 4 und 5, während es früher mal sowohl html4 als auch html4strict gegeben hatte. Zwischenzeitlich konnnte man an jeden Sprachnamen ein strict dranhängen.
- Lass mich besser diese Kat gelegentlich aufsuchen; phab:T124638 befasst sich mit einem aktuellen Fall und Turtle (Syntax). Wenn nicht gefixt wird, kommt es halt als normaler Schreibmaschinentext.
- LG --PerfektesChaos 17:53, 25. Jan. 2016 (CET)
- Oooch, die, wo ich es durch
pre
ersetzen kann, sind meistens auf Diskussionsseiten, das andere lasse ich ja so stehen. --Liebe Grüße, Lómelinde Diskussion 18:12, 25. Jan. 2016 (CET)
- @Lómelinde:
turtle
turtelt inzwischen – Eingangsbeschwerde rechts außen; bedarf noch einiger Überzeugungsarbeit, aber ich habe noch eine glühende Zange für unwillige Entwickler im Schmiedefeuer. LG --PerfektesChaos 15:58, 10. Feb. 2016 (CET)
- @Lómelinde:
Trennung von JSON- und Wikisyntax
Diese Vorlage ist sicherlich eine tolle Idee. Leider hat der Hauptautor die Schnittstelle zum Anwender so gestaltet, dass man JSON-Kenntnisse braucht, um sie anzuwenden. Nicht jeder, der Vorlagen schreibt, hat diese jedoch. Neben mir und PerfektesChaos sind es nicht sehr viele, welche hier mit JSON arbeiten können. Zur Verdeutlichung ein Auszug aus der Dokuseite der Vorlage TemplateData selbst:
{{templateData|JSON= { "description": "Anzeige einer Legende mit farbigen Flächen", "params": { "1": { "label": "Farbe", "description": "Farbcode der Fläche", "type": "string", "suggested": true, "default": "black", "example": "#87CEFA" }, "2": { "label": "Beschriftung", "description": "Erläuterung der Bedeutung der Farbe", "type": "string", "suggested": true, "example": "Wunder" }, "3": { "label": "Farbname", "description": "Natürlichsprachlicher Name der Farbe", "type": "string", "suggested": true, "example": "himmelblau" } }, "format": "inline" } |TOC=1}}
Das ist 95 % JSON-Quelltext und nur 5 % Wikisyntax. JSON-Quelltext hat bei der Einbindung einer Vorlage nichts zu suchen, er gehört ausschließlich in die Vorlage. Ich schlage daher vor, für die Dokuseiten eine Vorlage zu verwenden, welche nur mit Wikisyntax eingebunden wird. Weil das nicht abwärtskompatibel ist, müsste es eine neue Vorlage sein, welche das bisherige Modul oder eine Kopie davon nutzt. Das sähe beim obigen Beispiel dann ungefähr so aus:
{{Vorlagenname | info =Anzeige einer Legende mit farbigen Flächen | paraname1 =1 | label1 =Farbe | descr1 =Farbcode der Fläche | type1 =string | suggest1 =true | default1 =black | example1 =#87CEFA | paraname2 =2 | label2 =Beschriftung | descr2 =Erläuterung der Bedeutung der Farbe | type2 =string | suggest2 =true | default2 = | example2 =Wunder | paraname3 =3 | label3 =Farbname | descr3 =Natürlichsprachlicher Name der Farbe | type3 =string | suggest3 =true | default3 = | example3 =himmelblau | TOC = 1 }}
Auf diese Weise könnten alle User, welche eine Vorlage einbinden können, diese einheitliche Beschreibung nutzen und nicht nur die, welche JSON-Quelltext programmieren können. ÅñŧóñŜûŝî (Ð) 12:49, 21. Mai 2017 (CEST)
- Das, was da oben steht, ist zu 100 % JSON-Syntax und 0 % Lua-Syntax, mit minimalen Anteilen klassischer Vorlagensyntax.
- Somit ist die Abschnittsüberschrift schon mal grundfalsch.
- Die JSON-Syntax ist genau diejenige, die bereits unter Hilfe:TemplateData/JSON dokumentiert ist.
- Eine noch neu erfundene Extra-Syntax würde die Angelegenheit weiter komplizieren.
- Diese JSON-Syntax ist diejenige, die von den Tools sowohl bei MediaWiki als auch diversen Benutzern produziert wird.
- Die verwendete JSON-Syntax ist genau diejenige, die von MediaWiki selbst benutzt wird.
- Nur wird sie hinsichtlich der Darstellungsmöglichkeiten in der Vorlagendokumentationsseite erweitert, nämlich indem dort Markup, Verlinkungen usw. ermöglicht werden, und das grottige Design bei nicht angegebenen default, autovalue und example unterlassen wird, und noch ein paar Farben eingesetzt werden.
- Jede TemplateData-Beschreibung jeder Vorlage aus jedem Wiki, egal auf welche Weise mit welchem Tool produziert, ist sofort mit dem realisierten Format kompatibel. Der Vorschlag ist hingegen mit nichts kompatibel.
- „so gestaltet, dass man Lua-Kenntnisse braucht, um sie anzuwenden“
- Das ist schlicht falsch; es gibt ein halbes Dutzend Werkzeuge, die auf einfachen Knopfdruck aus einer Vorlage eine derartige JSON-Struktur generieren, ohne dass man von den Innereien etwas wissen oder verstehen müsste.
- Siehe Hilfe:TemplateData #MW-Editor (was im Übrigen auf jeder einschlägigen Vorlagenseite verlinkt ist).
- Der Vorschlag sugeriert, dass alle Parameternamen nur
1
oder2
lauten würden.- Gestern hatte ich einen Parameternamen gyromagnetisches_verhaeltnis_st.
- Nach dem obigen Vorschlag soll das lauten:
- Das, was da oben steht, ist zu 100 % JSON-Syntax und 0 % Lua-Syntax, mit minimalen Anteilen klassischer Vorlagensyntax.
| paranamegyromagnetisches_verhaeltnis_st =1 | labelgyromagnetisches_verhaeltnis_st =Farbe | descrgyromagnetisches_verhaeltnis_st =Farbcode der Fläche | typegyromagnetisches_verhaeltnis_st =string | suggestgyromagnetisches_verhaeltnis_st =true | defaultgyromagnetisches_verhaeltnis_st =black | examplegyromagnetisches_verhaeltnis_st =#87CEFA
- Insgesamt ist der Vorschlag ein Rückschritt in vergangene Zeiten.
- Nebenbei danke ich für die freundlichen Worte in der Einleitung.
- VG --PerfektesChaos 13:32, 21. Mai 2017 (CEST)
- @PerfektesChaos: Ich stimme dir zu, dass es JSON ist und nicht Lua, was ich auch teilweise korrigiert hatte. Du hast aber nicht verstanden, was ich genau vorgeschlagen habe, weil ich mich oben bei der Vorlage vertan habe. Mein obiges Beispiel bezieht sich auf die Vorlage:Farblegende. Bei deinem Beispiel würde die Einbindung der von mir vorgeschlagenen Vorlage deshalb so aussehen (Abschnitt):
| paraname18 = gyromagnetisches_verhaeltnis_st | label18 = Gyromagn. Verhältnis sT | descr18 = Gyromagnetisches Verhältnis in (sT)<sup>−1</sup> | type18 = line | suggest18 = true | default18 = | example18 = 2,67522205(23)·10<sup>8</sup>
Es geht also darum, eine Wikisyntax davorzusetzen. Diese Vorlage generiert dann entweder alles, was hinter "JSON=" steht (also eine davorgesetzte 1:1-Übersetzung von Wiki- in JSON-Syntax), oder greift direkt auf das Modul zu. Ich kann mir inzwischen auch vorstellen, dass es doch abwärtskompatibel sein kann, wenn du zusätzlich zu den Parametern "1", "JSON", "TOC" und "sort" auch Parameter mit Namen wie "paranameN", "labelN", "descrN", "typeN", "suggestN", "defaultN" und "exampleN" (mit N = ganze Zahl) als Alternative zu "JSON" auswerten würdest. Das wäre also eine integrierte "Wiki-in-JSON-Übersetzung". ÅñŧóñŜûŝî (Ð) 14:22, 21. Mai 2017 (CEST)
- Ich werde ganz definitiv keine von der in MediaWiki benutzten JSON-Notation abweichende private Spezialsyntax einführen.
- Alle verfeinerten JSON-Objekte lassen sich sofort in einem beliebigen Wiki unmittelbar per C&P innerhalb genereller MediaWiki-Syntax darstellen, ohne syntaktisch etwas ändern zu müssen. Okay, man bekäme ein paar eckige Klammern und Apostrophe zuviel, und Links auf in fremden Wikis nicht existierende Seiten, wie das halt so ist. Aber selbst dafür gibt es einen Trick: Eine noch nicht dokumentierte Schnittstelle generiert auch zum C&P dasselbe Ausgabeformat, wie es auch an den VisualEditor übermittelt wird, der hier ebenfalls weder Verlinkungen noch Fettschrift kennt.
- Die angeblich von fast niemandem zu erstellenden JSON-Definitionen habe ich zufällig gerade eben aus der Programmierungsseite, in die sie von Nicht-Vorlagenkundigen kürzlich automatisiert eingefügt wurden, herausgenommen, mit C&P auf /Doku kopiert, die Vorlageneinbindung drumherumgesetzt und war damit im Prinzip fertig (allerdings war inhaltlich noch einiges zu korrigieren).
- Es gibt noch fast 500 konventionelle TemplateData-Verwendungen, die (wie am Layout auf Anhieb erkennbar) ebenfalls mit der verfeinerten Version funktionieren.
- Wir werden ganz sicher nicht alle diese TemplateData-Spezifikationen der deWP vom MediaWiki-JSON auf ein privates Antonsusi-Format umstellen, das mit nichts und niemandem kompatibel ist.
- Ich werde ganz definitiv keine von der in MediaWiki benutzten JSON-Notation abweichende private Spezialsyntax einführen.
- VG --PerfektesChaos 15:15, 21. Mai 2017 (CEST)
- P.S.: Hast du dir eigentlich bereits Gedanken gemacht, wie die Elemente
aliases
,inherits
undset
bei dir verständlich zu kodieren wären? - VG --PerfektesChaos 15:19, 21. Mai 2017 (CEST)
- P.P.S.: ach, und noch was:
- Eine Vorlage ist am Anfang mit zwei unbenannten Parametern
1
und2
programmiert, und zwei benanntenLinktext
undAbruf
. - Ergibt nach deinem Vorschlag
- Eine Vorlage ist am Anfang mit zwei unbenannten Parametern
- P.P.S.: ach, und noch was:
- P.S.: Hast du dir eigentlich bereits Gedanken gemacht, wie die Elemente
{{Vorlagenname | info =Dies und das | paraname1 =1 | label1 =ID | descr1 =Bezeichner | paraname2 =2 | label2 =Darstellung | descr2 =Format der Ausgabe | paraname3 =Linktext | label3 =Linkbeschriftung | descr3 =Angezeigter Linktext | default3 =Lemma des Wikipedia-Artikels | paraname4 =Abruf | label4 =Abrufdatum | descr4 =Tag des letzten erfolgreichen Seitenabrufs
- Nun wird ein weiterer unbenannter Parameter
3
eingeführt. Den nennst du dann
- Nun wird ein weiterer unbenannter Parameter
| paraname5 =3 | label5 =Sub-Domain | descr5 =Teilbereich des Webservers
- Sehr übersichtlich,
5=3
, überhaupt nicht verwirrend, und sehr weitsichtig.
- Sehr übersichtlich,
- VG --PerfektesChaos 15:30, 21. Mai 2017 (CEST)
- Ooh, jetzt hätte ich es ganz vergessen: Alle sichtbaren Texte in TemplateData können auch mehrsprachig sein.
- Zwar wird unsere Vorlagendokumentationsseite hier nur deutschsprachig angezeigt (wobei – man kann sich die anderen Sprachversionen per CSS sichtbar machen, wenn die Lua-Unterstützung benutzt wird;
.templatedata-maintain{display:inherit}
). - Ein Benutzer, der sich eine englische Oberfläche eingestellt hat und den VisualEditor verwendet, bekommt dort jedoch die Erläuterungen in seiner eigenen Sprache angezeigt (weil JavaScript zur Laufzeit).
- Bitte erläutere mir, wie dies hier in Antonsusi-Syntax zu schreiben wäre.
- Zwar wird unsere Vorlagendokumentationsseite hier nur deutschsprachig angezeigt (wobei – man kann sich die anderen Sprachversionen per CSS sichtbar machen, wenn die Lua-Unterstützung benutzt wird;
- VG --PerfektesChaos 16:20, 21. Mai 2017 (CEST)
- Ooh, jetzt hätte ich es ganz vergessen: Alle sichtbaren Texte in TemplateData können auch mehrsprachig sein.
An den Rand gequetscht?
@PerfektesChaos, warum hast du das TemplateData an den linken Rand gefesselt. Ich finde das sieht nicht gut aus. Es wirkt gequetscht insbesondere dort, wo es nicht 100 % der Seitenbreite ausfüllt. Ist das Absicht? --Liebe Grüße, Lómelinde Diskussion 16:56, 22. Mai 2017 (CEST)
- Bittere Notwendigkeit: Vorlage:Infobox Teilchen.
- Ich denke darüber nach, die Tabelle ggf. immer über die ganze Breite gehen zu lassen und dafür die letzte Spalte auszuweiten.
- Es wird aber keine Lösung geben, die auf jedem Smartphone und bei jedem Bildschirmfenster und bei mal winzigen Parametermengen mit sehr kurzen Erläuterungen, mal bei umfangreichen Parameterbeschreibungen alles toll machen kann.
- Ist ja grad einige Stunden alt, und eine Vorlagendoku ist ein Zweckbau.
- LG --PerfektesChaos 17:01, 22. Mai 2017 (CEST)
- O.k. ich werde mich daran gewöhnen, es sah nur gerade merkwürdig aus. --Liebe Grüße, Lómelinde Diskussion 17:11, 22. Mai 2017 (CEST)
- @Lómelinde: Es gibt nur begrenzt wenig Lösungsansätze:
- Linksbündig, Breite dynamisch (heute zur Erprobung eingebaut)
- Breite immer 100 % des Kastens, letzte Spalte ausgedehnt
Riskant, da letzte Spalte in manchen Browsern die wichtigere Beschreibung quetschen könnte. - Breite immer 100 % des Kastens, Beschreibung-Spalte ausgedehnt
Navigation zu den relativ weit entfernten hinteren beiden Spalten noch zuzuordnen. - Breite dynamisch bis zu 100 % des Kastens, aber zentriert
Sieht mickrig aus, wenn Parameternamen kurz und nur unbenannte, wenig Beschreibung, letzte Spalten auch nur kurz, und Browserfenster breit.
- Mal die nächsten Wochen an realen Fällen beobachten; ist ja nicht in Stein gemeißelt.
- LG --PerfektesChaos 17:30, 22. Mai 2017 (CEST)
- Na ja sooo schlimm ist es jetzt auch nicht. Es gibt sicherlich wichtigeres. Das Layout ist ansonsten sehr schön. --Liebe Grüße, Lómelinde Diskussion 17:36, 22. Mai 2017 (CEST)
- @Lómelinde: Es gibt nur begrenzt wenig Lösungsansätze:
Vorlage in gegenwärtigem Zustand extrem anwenderunfreundlich und fehlerhaft
In ihrem gegenwärtigem Zustand ist diese Vorlage leider extrem anwenderunfreundlich. Ich wollte (noch ohne abzuspeichern) in Vorlage:Personendaten/Doku das Format von block
auf das benutzerdefinierte Format {{_\n|_=_\n}}
ändern (das ist nämlich die gewünschte Variante, auf Beta funktioniert die auch schon, wann genau das dann auch hier vom VisualEditor korrekt behandelt wird, müsste man vorher testen, da es Parsoid betrifft, kann das unabhängig von den üblichen Updates passieren, möglicherweise geht es bereits jetzt.).
Erster Versuch: Die prominent angebotene Schaltfläche „Vorlagendaten verwalten“ angeklickt. Ergebnis: Nichts. Da die templatedata-Tags fehlen, findet das Werkzeug die JSON-Daten nicht und ist damit nutzlos. Zweiter Versuch: Das Format von Hand in den Haufen JSON eingefügt. Ergebnis: Da die templatedata-Tags fehlen, wird es als Wikitext interpretiert. Dritter Versuch: templatedata-Tags ergänzt, anschließend „Vorlagendaten verwalten“ angeklickt, dort komfortabel das Format geändert. Ergebnis in der Vorschau: INTERNAL: mw.text.jsonDecode: Syntax-Fehler.
Ich hatte vor, die wichtigsten Vorlagendokumentationen auf den aktuellen Stand zu bringen, sobald der VE mit benutzerdefinierten Formaten umgehen kann. Ernsthaft: Wenn mich diese Vorlage daran hindert, dann werde ich sie bei der Gelegenheit gnadenlos rauswerfen, egal wie viele Vorteile sie sonst haben mag. So, wie sie sich jetzt gerade verhält, verhindert sie sinnvolles Arbeiten. –Schnark 10:50, 10. Okt. 2017 (CEST)
- Das von MediaWiki angebotene Werkzeug schreibt erstmal gnadenlos in die Programmierungsseite; wir verwenden jedoch immer die Unterseite /Doku. Damit kannst du das Ding komplett vergessen; es taugt allenfallls nur für ein allererstes Setup und muss dann ohnehin wieder manuell in die Unterseite kopiert werden.
- Da eine Pipe in deinem Beispiel
{{_\n|_=_\n}}
enthalten ist, muss dieses mit{{!}}
escaped werden. - Es erstaunt schon, dass ausgerechnet du Probleme mit Vorlagensyntax und JSON hättest.
- Du kannst mir gern auf der BD: auflisten, an welchen Vorlagen du derartige Ergänzungen vornehmen mmöchtest; ich füge sie dann gern für dich ein.
- VG --PerfektesChaos 10:57, 10. Okt. 2017 (CEST)
- Das MW-Werkzeug schreibt genau auf die Seite, auf der man es anwendet. Wenn man es auf der /Doku-Seite aufruft, dann schreibt es auch dorthin.
- Ich will aber nicht einen merkwürdigen JSON-Wikitext-Mischmasch produzieren, den man noch nicht einmal vernünftig per Copy-Paste irgendwo anders hin transferieren kann (weil anderswo reines JSON verwendet wird).
- Keine unüberwindbaren Probleme, aber die Vorlage macht es schwieriger als nötig. Schon allein die Tatsache, dass man den geschweiften Klammern nicht ansieht, ob sie zur Vorlagensyntax oder zur JSON-Syntax gehören und man durch den Validierungsfehler auch in der Vorschau keinerlei sinnvolle Rückmeldung erhält, ob man alles korrekt gemacht hat oder nicht. So, wie die Vorlage sich verhält, reduziert sie die Personen, die hier Vorlagendokumentationen pflegen können/wollen auf eine sehr kleine Zahl.
- Ich würde an einer Testvorlage ausprobieren, ob bzw. wann Parsoid mit benutzerdefinierten Formaten umgehen kann, und anschließend Spezial:Meistbenutzte Vorlagen von oben bis ich keine Lust mehr habe durchgehen und überall, wo die Kopiervorlage besondere Whitespace-Konventionen vorschlägt, diese auch für den VE ergänzen.
- –Schnark 12:07, 10. Okt. 2017 (CEST)
- Da TemplateData weder Markup noch Verlinkungen akzeptiert, musste etwa diese hier und Hunderte weitere in zwei Versionen der Parameterbeschreibung vorgehalten werden.
- Das ist ein völlig unakzeptabler Zustand.
- Zum einen macht es das für die Anwender von Vorlagen völlig undurchschaubar, dass es da zwei Parametertabellen gibt (mit 60× Autowert=leer usw.), zum anderen führt das zu Inkonsistenzen zwichen den beiden parallel zu pflegenden und zu synchronisierenden Parametertabellen.
- Soviel zur Headline: „extrem anwenderunfreundlich“ und MediaWiki.
- Die aktuelle Version des verlinkten Beispiels enthält übrigens bereits die fragliche Zeilenumbruchsyntax, die vor über einem Jahr mal als unmittelbar bevorstehend angekündigt worden war.
- Fast 700 der unmittelbar mit TemplateData dokumentierten /Doku-Seiten enthalten bereits das kombinierte Format; und das belässt du frendlicherweise auch. Weniger als 100 erhaltenswürdige Vorlagen enthalten noch die klassischen Tags.
- Schon seit Jahren und lange zuvor liegt die Hauptlast der Vorlagenprogrammierung und gar ihrer Dokumentation bei einem sehr kleinen Kreis von Leuten, die das auch alle gerafft haben; Normalbenutzer programmieren weder eine akzeptable projektweit und massenhaft einbindbare Vorlage, noch kriegen sie eine verständliche /Doku hin. In der Regel bleibt das völlig undokumentiert, es hat sich durch VE und TemplateData also absolut nichts geändert.
- Spezial:Meistbenutzte Vorlagen enthält jede Menge interner Funktionen und Untervorlagen, die grundsätzlich nicht für ANR, Direkteinbau durch normale Anwender und damit auch nicht für TemplateData geeignet sind.
- Du kannst gern der WP:VWS Bescheid geben, wenn es soweit ist, dann macht sie das auch so nach und nach im Routineprogramm, und überprüft auch, ob das überhaupt eine wünschenswerte Formatierung wäre.
- Da TemplateData weder Markup noch Verlinkungen akzeptiert, musste etwa diese hier und Hunderte weitere in zwei Versionen der Parameterbeschreibung vorgehalten werden.
- VG --PerfektesChaos 12:54, 10. Okt. 2017 (CEST)
- Interessante lange Antwort, das Interessanteste ist, dass du nun mit keinem Wort auf das MW-Werkzeug zur Erzeugung und Bearbeitung der JSON-Syntax eingehst (nachdem du in der ersten Antwort dazu eine – wenn auch nicht zutreffende – Aussage gemacht hast). Dass diese Vorlage die Verwendung des Werkzeugs effektiv unmöglich macht, steht für mich auf einer Stufe mit dem Hack zur Deaktivierung des Mediaviewers.
- Das Hauptproblem scheint mir nicht zu sein, dass sich nur ein sehr kleinen Kreis um die Vorlagendokumentation kümmert, sondern dass dieser Kreis aus welchen Gründen auch immer jegliche Unterstützung dabei abwehrt – erfolgreich.
- Irgendeine möglicherweise noch vorhandene Lust daran etwas zu ändern, ist mir jetzt endgültig vergangen; wenn sich Vorlagendokumentationen nicht vernünftig bearbeiten lassen, dann bleiben sie halt so wie sie sind. –Schnark 09:19, 11. Okt. 2017 (CEST)
- @PerfektesChaos, Schnark: Falls das nicht ohnehin schon vorher klar war: Solange wir hier nichts ändern, wird sich der unbefriedigende Zustand auch in Zukunft nicht verbessern: Die Bereitschaft der VE-Entwickler, den Editor an unseren Sonderweg hier anzupassen, hält sich jedenfalls in Grenzen. --Tkarcher (Diskussion) 09:07, 19. Feb. 2018 (CET)
- Hilfe:TemplateData #MW-Editor schreibt: „Dieses von MediaWiki bereitgestellte Werkzeug ist nur bei der Ersterstellung einer TemplateData-Dokumentation verwendbar.“
- Es ist ohnehin Nacharbeit erforderlich, nämlich Einbindung in die Vorlage hier, und Nutzung diverser Extras.
- MediaWiki sind die Dokumentationsseiten grundsätzlich völlig schietegol – sie interessieren sich nur noch für den VisualEditor und das dort angezeigte Formular, und haben auch nur ein paar triviale Mini-Parameter im Kopf.
- Deshalb zeigt MediaWiki bei jedem einzelnen Parameterwert eine inhaltsfreie sechszeilige Definitionsliste, auch wenn die Problemstellung es grundsätzlich unmöglich macht, dass Vorgabewerte oder gar AutoValue-Spezifikationen jemals definiert werden können.
- phab:T125333 / phab:T137443 / phab:T160254 / phab:T52512
- VG --PerfektesChaos 17:52, 19. Feb. 2018 (CET)
- Hilfe:TemplateData #MW-Editor schreibt: „Dieses von MediaWiki bereitgestellte Werkzeug ist nur bei der Ersterstellung einer TemplateData-Dokumentation verwendbar.“