Hi!

Praktisch sollten solche Seiten nur für User mit Schreibrechten überhaupt verlinkt werden. Ich kann das leider nicht testen, da ja momentan jeder Schreibrechte hat.
Äh ... wie sieht's denn überhaupt aus? Sollen denn Seiten anonym bearbeitet werden können?

Jein. Anmelden muss sein. Unangemeldet sind keine Bearbeitungen möglich. Da bei einer Anmeldung aber keine Person überprüft wird, ist das quasi anonym.

Lo!

Hi!

Ich lad's dir drüben gleich mal hoch (mit dem derzeitigen rot)

Ich hab einen zweiten Link mit rotem Icon hinzugefügt.

Die DPL begnügt sich auch mit Kategorien.
Nicht aber die Suche. Wenn mich im Moment CSS interessiert, wäre es schon hilfreich, entsprechenden Namensraum per checkbox auszuwählen

Da gibt es noch x Anwendungsfälle, für die entweder das eine oder das andere Prinzip von Vorteil/Nachteil wäre. Ich hab mir ja die Namensräume nicht ausgedacht, aber ich verteidige sie schon aus technischen und organisatorischen Gesichtspunkten, weil mich bisher noch kein anderes Konzept dahingehend überzeugt hat, dass es den nicht unerheblichen Aufwand einer Umgestaltung lohnt. Da erscheint mit das Erstellen von zusätzlichen, für andere Verwendungszwecke sortieren/aufbereiteten Portalseiten als eine einfachere Lösung, um Ordnung und Überblick zu erzeugen.

{{#dpl:
| titlematch= = ²{PAGENAME}²
}}

und schwupps hat man links zu allen Seiten, die genau so heißen (und vermutlich das gleiche Thema behandeln), wie die gerade angezeigte ... nur in anderen Namensräumen (also wenn's nach mir ginge CSS/JS/HTML usw.).

Du stellst dir das zu einfach vor, fürchte ich. Denn das setzt voraus, dass die Seitenbenennung konsistent erfolgen kann und erfolgt sowie dass jeder das Benennungsprinzip versteht und umsetzt. Das Hinzufügen einer Kategorie geht hingegen bei jedem Namensraum und Seitentitel problemlos und man braucht zum Auflisten aller Seiten einer Kategorie noch nicht mal die DPL.

Da braucht es eine vorgeschaltete Intelligenz, die die Harmlosigkeit feststellt und anschließend eine Freigabe erteilt oder auch nicht.
Na genau das mein' ich doch ... ein admin verschiebt den Code (wenn er sauber ist) in den MediaWiki-Namensraum, und dieser wird als "echtes" HTML interpretiert (also das Ding wird nur dann per Klick ausgeführt, oder so)

Dieses Konzept ist ja auch schon als Kandidat grob skizziert worden.

Muss es MediaWiki sein? Dieser Namensraum hat doch schon eine Aufgabe. Mir wäre lieber, einen eigenen zu ertellen, wenn "abgegrenzter Namensraum" ein wesentlicher Baustein zu einer Lösung ist.

Deswegen hatte ich damit angefangen, nur die jeweiligen besprochenen Elemente durch Fettschrift hervorzuheben, statt den gesamten Code zu GeShi-sieren.
Man könnte ja per Javascript/Ajax den Code an die API senden ... und dann je nach Lust und Laune bunt anzeigen lassen (ich hab' GeShi lieb)

Ich bitte darum, zwischen den Anwendungsfällen zu unterscheiden und dabei die jeweiligen Zielgruppen zu berücksichtigen. Du bist Fortgeschrittener und kennst alle wesentlichen Code-Elemente. Für dich stellt GeSHi (irgendwann lern ich noch, wie sich das richtig schreibt) eine Hilfe in mehr oder weniger komplexen Codebeispielen dar. Aber ist es das auch für Texte der Fall, in denen Anfängern einzelne Code-Elemente in eher kleinen Beispielen erläutert werden sollen? Die Lösung wird sicher irgendwo in der Mitte liegen. Das beste Ergebnis erzielt man meiner Meinung nach immer noch, wenn man Effekte sparsam verwendet.

Apropos Lust und Laune: Es besteht ja immer noch die Möglichekeit, sich den Code in einen Editor seiner Wahl zu kopieren und dort die einem am besten gefallende Syntaxfärbung einzustellen. Außerdem kann man nun gleich auch noch Experimente mit dem Code anstellen, um so Erfahrungen im Umgang zu sammeln.

Lo!

Hi!

Weil, nicht nur nach meiner Auffassung, ein generelles "Bunt" in vielen Fällen mehr vom eigentlich Erläuterten ablenkt als es nützt.
GeSHi läßt sich in der "Normalform" dahingehend konfigurieren, daß nur bestimmte Kategorien hervorgehoben werden, das müßte doch dann auch bei der Wiki-Einbindung funktionieren?

Schon, dabei bleibt aber das Problem, dass es ein Automatismus ist, der nicht weiß, worauf der Autor eines Beitrages das Augenmerk des Lesers gelenkt haben möchte.

Man könnte das Highlighting z.b. auf Kommentare und Keywords oder nur Kommentare oder $andere_Kombination beschränken und die besprochenen Elemente weiterhin durch Fettschrift gesondert auszeichnen.

Das geht nicht, weil meines Wissens innerhalb von <source> keine Wikisyntax zugelassen ist. Da geht also gar nichts individuelles.

Gegebenenfalls noch unaufdringliche Farben wählen. Ich kann üblicherweise durch eine dezente(!) Hervorhebung die Syntax schneller/besser erfassen als bei komplett einfarbigem Text. Bei zu intensiver Syntax-Hervorhebung tritt der gegenteilige Effekt ein, da stimme ich durchaus zu.

Die Frage ist, geht es denn bei den Stellen, wo auf "gezieltes Hervorheben" statt "allgemeines Bunt" gesetzt wird darum, den gesamten Code darzustellen? Ich denke nicht. Diese Stellen sind Erläuterungen einzelner Elemente und nicht kompletter Seiten/Programme. Wir sprechen hier über solche Dinge, wie: Erklärung des HTML-Elements X - da kommt es drauf an, die X im umgebenden Code zu sehen. Oder CSS-Selektor Y und die Auswirkungen auf HTML-Elemente - da will man sehen, welcher Selektor auf welche Elemente wirkt, was mit gezieltem Einsatz von Farbe/Formatierung verdeutlicht werden kann.

Für diese Fälle stört GenSHi mehr als es nützt. Es spielt jedoch da seine Stärken aus, wo nicht Elemente des Code als solche erklärt werden sollen, sondern der Code zum Erreichen eines Ziel dient. In einem Artikel wie dem zum Terminkalender kann eine Unterstützung durch GenSHi sehr wohl von Vorteil sein.

Lo!

Bleibt noch, wie man nicht vorhandene Seiten kennzeichnet. Ein NEW-Icon fände ich unpassend, denn was noch nicht da ist, kann nicht neu sein. Ein Symbol für Nichtexistenz fällt mir auch grad nicht ein. Und Stopp- oder Verbotsschilder könnten das falsche Signal setzen.

Wie wäre es mit einer Blaufärbung? Dann hätten wir rötlich/bräunlich für normale Links und verwirren mit dem Blau die Anwender, die das als übliche Linkfarbe kennen ... :-)

Also ich finde die Farbkennzeichnung ungenügend.

mal über ein Symbol nachgedacht... Es ist fraglos, dass es hier keine starke Konvention gibt, auf die man aufbauen könnte.
Der title ist nicht genug (Verzögerung). Eine verbale Hover-Information wäre hier deutlicher.

Wenn ich eine alternative zur Punktierung vorschlagen müsste, käme mir die rote Wellenlinie aus der Rechtschreibung in den Sinn (etwas ist mit dem Link nicht in Ordnung).

mfg Beat

Hi!

Bleibt noch, wie man nicht vorhandene Seiten kennzeichnet. Ein NEW-Icon fände ich unpassend, denn was noch nicht da ist, kann nicht neu sein. Ein Symbol für Nichtexistenz fällt mir auch grad nicht ein. Und Stopp- oder Verbotsschilder könnten das falsche Signal setzen.

Die rote Farbe für nichtexistierende Links passt mMn (ein Tick rötlicher wäre vielleicht fein, evtl. sogar (255,0,0)). Ein Icon o.ä. würde ich weglassen; ich meine, Icons sollten nur für externe Links reserviert bleiben.

Wenn man das rot knalliger macht, dann kann man evtl. auch auf die Unterstreichung verzichten, was auch nicht schlecht wäre. Von Haus aus unterstrichene Links finde ich immer irgendwie unpassend.

Grüße
Bernhard