Forum:Verbindliche Richtlinien für die Vorlagen-Programmierung

Forum > Verbindliche Richtlinien für die Vorlagen-Programmierung

Hinweis: Dieser Fred wurde seit 5239 Tagen nicht bearbeitet. Dieser Fred ist offiziell versandet - die Diskussion damit Geschichte. Bitte nichts mehr hinzufügen.
Bei Bedarf dann halt einen neuen Fred starten oder diesen notfalls reanimieren.

Moin,

wie hier schonmal kurz angesprochen, wäre es vielleicht sinnvoll, die Vorlagen-Programmierung richt zu linien. Oder nicht? Senf wird erbeten.
Jedenfalls sind unsere Vorlagen das reinste Chaos, bzw. jedes Programmier-Kamel hat halt seine eigenen Methoden und seinen eigenen Stil (wo man ja nix gegen sagen kann), aber das merkt man eben. Mal ein paar Beispiele, was man vielleicht verbindlich regeln sollte (kann gerne erweitert werden):

• Ein quasi "globaler" Parameter für das Deaktivieren der Autokategorien wäre hilfreich ({{{kat = }}}, oder so.). Derzeit ist das in vielen Vorlagen (fallso überhaupt vorhanden) oft ein unbenannter (also nummerischer) Parameter, was Probleme mit sich bringt, wenn eine Vorlage um zusätzliche Funktionen erweitert wird. (fiktives) Beispiel: {{Begraben|}} kommt nicht in die Bestattungs-Kategorie, weil da ein "|" hinten dran ist. Nun kommt Kamel aber auf die Idee, einen neuen Parameter einzubauen, z.B. um den Seitentitel in der Vorlage manuell angeben zu können – geht aber nicht richtig, da dafür nur {{{2}}} in Frage käme, oder man macht möglicher Weise zig Seiten kaputt ... hoffe, das war verständlich.

• Parameter-Namen:
  • mal verbindlich klären, wann numerische und wann benamte (blödes Wort, aber mir fällt kein besseres ein) verwendet werden sollten
  • englische oder deutsche Parameter-Namen?
  • am wichtigsten: groß- oder kleingeschriebene Parameter?; oder gar {{{Parameter|{{{parameter|}}}}}} in allen Vorlagen einbauen, und das ganze damit case-insensitive machen?

• Vorlagen-Namen:
  • auch hier: Englisch oder Deutsch?
  • wie die sub-Vorlagen benennen? Ein einheitliches System wäre hilfreich, also Vorlage/dpl-Gedöhnse/Übersichtsseite oder Vorlage.dpl-Gedöhnse.Übersichtsseite, usw.
  • Bindestrich (Text-Farbe) oder nicht (Textfarbe), oder beides?

nervt jedenfalls tierisch, immer nachsehen zu müssen, wie 'ne Vorlage funktioniert ... könnte ja auch bei allen Vorlagen gleich sein

• Farb- und Größenangaben:
  • grundsätzlich: relative oder absolute Größenangaben? Und wenn ja, dann wie (.em oder %, bzw. px oder pt oder cm)?
  • hexadezimale (#XXXXXX) oder rgb (r:X g:X b:X) Angaben, oder Farbnamen, oder gar nur bestimmte Farben zulassen ("websichere" Farben, "Wüstenfarben")?

• standard-Konformität: wäre nett, wenn wenigstens unsere Vorlagen xhtml-konform wären, das heißt nicht nur <br /> statt <br> usw., sondern ich würde mir auch wünschen, dass keine deprecateden Sachen mehr verwendet werden sollten, z.B. <center>, ja, wirklich, <center>! Stattdessen: textalign = center, align = center und v.a. margin = auto.

• Quelltext und Kommentare: wie die doch immer komplizierter werdenden Vorlagen im Quelltext strukturieren und kommentieren? Html-Kommentare durchnummerieren? Zeilenweise kommentieren? Komentar-Blöcke? Verschachtelte Strukturen ({{#if: ... | {{#switch: | ... {{#dpl: | ... }} }} }} einrücken? Und wenn ja, wieviel?

• Wie die Vorlagen dokumentieren? Da bin ich gerade fleißig am arbeiten dran, 'ne entsprechende Vorlage zu bauen ... bin auch schon recht weit, mach' das aber lieber mal bei mir zuhause; kann man dann Zerreden, wenn's fertig ist ...

• usw. mir fällt bestimmt noch mehr ein; und auch ihr könnt gerne erweitern.

Das soll jetzt alles kein Vorwurf sein, wie gesagt, hat halt jedes Programmier-Kamel so seine Vorlieben, wäre aber vielleicht sinnig, sich wenigstens in groben Zügen auf irgendwas zu einigen. Oder einfach jeden machen lassen, wie er mag? Wäre auch 'ne Möglichkeit, solange alles funzt wie's soll ...? Jedenfalls, muss hier jetzt nix über's Knie gebrochen werden, und 'ne Anpassung der alten Vorlagen können wir ggf. auch nach und nach machen.

Grüße, --WiMu 11:21, 7. Jul. 2010 (NNZ)

Ich finde, da sind viele schöne Gedanken dabei; Im einzelnen:

• Ändern von Autokat in einen named parameter: Dafür, aber nur in den Boxen für die Artikel, sonst nicht. Parametername müsste noch ausdiskutiert werden. kat? nokat? keinekat? deko?
• Parameter-Namen: "Explicit is better than implicit" -> Grundsätzlich immer Text-Parameter, damit ist dann immer klar, was gemeint ist. Nur bei 1-oder-2-Parameter-Vorlagen sollten Ziffernparameter ok sein. Oder beides, also {{{wasauchimmer|{{{1|default}}} }}}.
• Englisch/Deutsch: Schwere frage, ehrlich. Deutsches Wiki, also deutsch?
• Groß/Klein: einfach konsequent immer klein? ist am einfachsten.
• Sub-Vorlagen: Wiki hat bereits ein System für Unterseiten, nämlich mit Trennung per Schrägstrich. Für die Ersatz-Vorlagen für's DPL hat sich Vorlage.dpl (bzw., falls nötig, Vorlage.irgendwasanderes) eingebürgert. Finde ich ok so.
• Farb- und Größenangaben: Sehe keine Notwendigkeit, Farben einzuschränken. Alles, was CSS kann, sollte auch erlaubt sein: Farbnahmen (white), Ziffernnotation (#FFFFFF), RGB (rgb(255,255,255)). Größen sind da schon schwieriger, da Bildbreiten nur in px angegeben werden können. Also entweder auch alles erlaubt, oder nur px.
• Standard: Jup, wäre nicht schlecht, dann aber bitte auch nicht textalign=center sondern style="text-align: center;". Wenn, dann gleich richtig.
• Kommentieren am besten mit dem Kamelopedia-Quasi-Standard:

<!--
  -- Längere Erklärung oder Abschnittsüberschrift: Als nächstes kommt
  -- bla bla bla. Das macht, dass blubb, weil.
  --
-->Wikicode bla blubb <!-- Kurzerklärung -->

• Einrückung ist manchmal problematisch weil wegen Wiki-Notation. Wenn möglich trotzdem machen, egal wieviel (1? 4?)
• Umsetzung von dem da oben: In 1 bis 2 Wochen, wenn die Prüfungen erstmal durch sind, werfe ich gerne meinen Bot wieder mal an. Da müsste man nur vorher durchdröseln, welche Sachen genau wo ersetzt werden müssen. Und gerne auch alles schön schrittweise, eins nach dem anderen.

Grüße --J* 20:01, 7. Jul. 2010 (NNZ)

Hallo, J*

Wollte dir schon länger antworten, komme aber im Moment zu garnix, da sich bei mir allem Anschein nach endlich beruflich mal was tut. Insofern werde ich wohl in nächster Zeit mehr oder weniger ausfallen …

• Autokat: hatte kürzlich die Idee, das mit einer Vorlage zu machen, die durch die Namensräume switcht und im Vorlagen-Raum die Vorlagen-Kats, in allen übrigen die Auto-Kats anzeigt. Vorteil wäre, dass Kamel nicht mer unbedingt mit <noinclude> hantieren müsste (schätze bei 50% aller Vorlagen schleicht sich da ein unnötiger und teilweise störender Zeilenumbruch ein). Außerdem ließen sich dann alle Kats per DPL auslesen und es wäre auch ein leichtes, bestimmte Kategorien auf bestimmte Namensräume zu beschränken (z.B. eben unser Lizenz-Gedöhnse auf den Datei-Namensraum).
• Parameternamen: also je weniger Parameter, desto Zahl ;-) Ja, finde ich gut, sehe ich auch so
• Englisch/Deutsch: mir egal, müsste man sich halt nur mal für was entscheiden
• Subvorlagen: präferiere ich auch das "/" … doof nur, dass DPL das per default mit ".default" macht (eigentlich ein Unding). Wäre aber dafür, die Unterseitem im Vorlagen-Namensraum auf echte Unterseiten umzustellen, so wie das auch im Kamel- und Kamel-Diskussions-Namensraum funktioniert. Gibt da irgendeine Variable in den Localsettings … finde die aber gerade nicht.
• Farben: mir wäre es schon lieb, wenn man das vereinheitlichen würde, einfach weil wegen der Kompatibilität und nicht so 'n Kuddel-Muddel. Größen: da hast du den Nagel auf den Kopf getroffen … das mit den Bild-Größen ist mir noch gar nicht aufgefallen, und ich wäre da fast versucht, bei MediaWiki einen bug einzutragen. Der neue Vector-Skin setzt mehr noch als das Monobook auf browser-Voreinstellungen und relative Angaben. "Usability" nennen DIE das dann, wenn im IE die Seiten mit 'ner riesen-Schrift daher kommen und im FF sämtliche Monospace-Schriften unlesbar winzig sind. Und dann lassen sich Grafiken nicht relativ zum umgebenden Text skalieren … super. Vielleicht sollten wir uns wirklich überlegen, das Vector-css komplett auf absolute px-Angaben umzubauen … schließlich funktionieren weltweit grob geschätzt 95% aller Internetseiten genau so und das würde vieles ganz erheblich vereinfachen und jeder halbwegs vernünftige browser kann auch px-Angaben verkleinern/vergrößern, insbesondere kann man bei Kamelen mit Sehschwäche davon ausgehen, dass deren browser das leisten.
• Standard: das style= hab ich mal stillschweigend vorausgesetzt … bin ja nicht ganz bescheuert ;-)
• Kommentieren/Einrücken: plädiere für vier Leerzeichen, wie in php üblich (bisher mach' ich das mit TABs, das aber umständlich, weil man die ja nur mit copy&paste einfügen kann)

So, das wars jetzt erstmal … Grüße, --WiMu 11:02, 15. Jul. 2010 (NNZ)

Und weiter geht's:

• Autokat: Lieber von Hand machen, bei Vorlagen wird sich der Zeilenumbruch genauso einschleichen. Und dann lieber den Include-Mechanismus nutzen.
• Subvorlagen: Lässt sich, glaub ich, nicht ändern, ohne direkt im DPL rumzupfuschen …
• Farben: Kommt doch auch immer drauf an, wie die Vorlage genau verwendet wird. Und da gibt's in der Kamelo einfach viel zu viele Möglichkeiten. Insofern lieber nicht einschränken.
• Größe: Dass man bei Bildern die Größe nur in Pixeln angeben kann, hängt einfach damit zusammen, dass das Bild ja vor der Einbindung auch auf die richtige Größe gerendert werden soll. Und woher soll der Bild-Renderer wissen, wie groß ein % ist (abhängig von der Fenstergröße) oder wie groß ein ex, en, em ist (abhängig von der verwendeten Schriftart im Browser).
• Kommentare: Ja, warum nicht.

Grüße --J* 12:38, 20. Jul. 2010 (NNZ)