Benutzer Diskussion:Dedlfix/Archiv

Hinweis:

Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen. Allerdings werden diese Seiten in unserem Wiki erfahrungsgemäß nur von sehr wenigen Leuten besucht.

• Deshalb sollten Diskussionen über den Artikel zum Thema „Archiv“ besser im SELFHTML-Forum geführt werden.
• Unter https://forum.selfhtml.org/self/new kannst du einen entsprechenden Beitrag erstellen.
• Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.

Diskussionsbedarf

Hallo Dedlfix,

Wie ich es irgendwo anders schon mal vermerkt hatte, bin ich in den letzten vierzehn Tagen Arbeit am Wiki, hie und da, auf Probleme gestoßen.
Mein Import 8.1.2 von JavaScript ist jetzt weitgehend abgeschlossen.
(Die vier DHTML-Seiten sind in Wirklichkeit alle rein JavaScript basierend. Daher werde ich auch diese ins JS-Inhaltsverzeichnis integrieren und übertragen.
Sind die Autorenrechte der vielen namentlich signierten JavaScript-Artikel  eigentlich auch alle, samt und sonders, fürs SELFHTML-Wiki freigegeben?)

Nein, die haben zwar der Veröffentlichung als Artikel zugestimmt, nicht jedoch automatisch einer Wikifizierung, denn das war damals noch gar nicht bekannt. Die Autoren müssten um ihr Einverständnis gebeten werden.

Genau das habe ich mir auch so gedacht. Ich habe im Moment eh keine Zeit dazu, bzw. es gibt Vordringlicheres.

Wenn ein Artikel Wiki-geeignet erscheint, könnte man ja ggf. in einigen Wochen, den einen oder anderen Autor um sein Einverständnis fragen.

Nun habe ich begonnen, die kleineren Formatierungsfehler zu beheben, sowie die internen Links einzufügen. Auf zwei Seiten^{[1] [2]} ist das schon geschehen.

Bitte Links nicht generell in Fettschrift auszeichnen. Das war zwar in der alten Doku so, im Wiki haben wir das aber nicht übernommen. Für eine Gestaltung, die nicht aus inhaltlichen Gründen vorgenommen wird, sind außerdem CSS-Regeln besser geeignet.

Fettschrift:  Da hast du Recht. Ich wollte in der Formatierung zunächst nur möglichst nahe am alten Wiki bleiben. (Für die diesbezügliche Perfektion habe ich eh keine Zeit und würde auch nicht lohnen.)

Ich werde es jetzt vorerst fett lassen und sofort nach dem Übertrag, die Fettschrift im allerersten Edit wieder raus schmeißen.

... sind außerdem CSS-Regeln besser geeignet:  Hast du prinzipiell auch Recht. Aber um auf das Common.css Einfluss nehmen zu können, bräuchte man ja das entsprechende MediaWiki Edit Recht. Dieses beanspruche ich im Moment aber gar nicht. Ich bin ja erst seit zwei Wochen dabei. Allerdings gibt es hierzu, zu CSS (gleich später) ein, zwei Vorschläge meinerseits. Die entsprechenden CSS-Änderungen kannst ja du selbst, bei Einverständnis, vornehmen.

Aktualisieren will ich die JS-Seiten, bevor sie nicht vom Benutzernamensraum ins eigentliche Wiki zu überführt worden sind, bewusst nicht. (Auf Kladde habe ich aber damit schon angefangen.)
Bevor dieser Transfer in den nächsten Tagen beginnen könnte, will ich aber noch eine ganze Reihe von Punkten mit dir diskutieren. Auch Matthias A. und andere können sich da gerne einmischen.

Wenn du dazu Zeit hast, können wir das so machen?   Mit freundlichen Grüßen, Klaus 12:14, 4. Apr. 2011 (CEST)

Ich hab da auch einige Gedanken, die ich in der Hilfe:Artikel vorangestellt habe. Allerdings weiß ich auch, dass das eine ganze Menge Arbeit ist, die Texte so umzuformatieren/-formulieren, dass allgemeine Informationen nicht im Beispiel-Erläuterungstext oder (nicht unbedingt notwenigerweise) im Beachten-Sie-Abschnitt stehen. Allerdings kann ich eine solche Umarbeitung auch nur empfehlen/mir wünschen und sie nicht verlangen.

Wenn es dir beim Diskutieren um einen breiteren Publikumskreis geht, wäre im Forum mehr Potential. --dedlfix 13:17, 4. Apr. 2011 (CEST)

Ich hab da auch einige Gedanken, ...  Dass die „allgemeine Informationen nicht im Beispiel-Erläuterungstext [...] stehen“ etc. mag langfristig auch umgearbeitet werden können.

Das allerwichtigste erscheinen mir aber zuerst mal, die dringend notwendigen Aktualisierungen zu sein. Beispiele:  Unterstützende Browser Versionen, Layers in ein Archiv zu schieben, neue Informationen hinzufügen und vieles mehr...

Wenn es dir beim Diskutieren um einen breiteren Publikumskreis geht, wäre im Forum mehr Potential.

Gerade vorher habe ich mich im Forum ein bisschen näher umgeschaut und sah mit Anerkennung und Erstaunen, wie aktiv es da zugeht!

Da es mir aber spezifisch hier ums Wiki geht, glaube ich schon, dass wir das auch genau hier im Wiki diskutieren sollten. Auf welcher Seite ganz genau, das habe ich mir auch schon überlegt. Habe aber nichts bzw. keine völlig überzeugende gefunden. Ich werde, wohl heute noch, einfach mal hier auf deiner Diskussionsseite loslegen. Vielleicht können wir es später anders wo hin verschieben bzw. kopieren. (Nur eine Section verschieben geht wohl nicht.)

Aber gerne kannst du dann, morgen oder übermorgen (und wenn es dir angemessen erscheint,) einen Hinweis dazu im Forum posten. Was dann vielleicht den Vorteil eines breiteren Meinungsbildes hätte.

Bis später,  Klaus 15:27, 4. Apr. 2011 (CEST)

Items

Im Nachstehenden will ich dir einfach nur alles was mir aufgefallen ist und/oder wozu ich auch Anregungen habe, auflisten:

Zuerst zu Bitte:

Gut, wenn du es erst zu spät gesehen hast: „Zu spät, schon alles getippt.“ Hättest aber auch erst ganz lesen und dann erst anfangen zu antworten. Nachdem du Sections eingefügt, geht es ja halbwegs. Ich schreibe es deshalb am Anfang, um dich anhand des folgenden Abschnitts auf einen wichtigen Nachteil hinzuweisen. Du hast nicht datiert und nicht signiert.

Doch, aber nur ganz unten, sonst hätte ich konsequenterweise auch alle deine durch meine Antworten entstandenen Textstücke nachsignieren müssen. Hauptsache die Einrückungstiefen werden mit jeder Antwort angepasst, damit die eine unten stehende Signatur zugeordnet werden kann.

Jaja, stimmt. Meine hättest du „konsequenterweise auch [...] nachsignieren müssen“. Aber erst nachdem du sie selbst in Sections geteilt. Aber lassen wir das. Es geht ja jetzt einigermaßen.

Ich werde es in meiner Antwort jetzt auch nicht tun. Solange nur wir beide einige Replies austauschen, bleibt es (noch) lesbar. Stell dir aber vor, (was ja auch manchmal sein kann,) ein Dritter oder Vierter will, eventuell auch Tag später, noch was einfügen. Dann hat sich's mit der Lesbarkeit. Wer hat was und wann gesagt?

Ein Wiki ist eben kein Diskussionsforum. Deswegen schlage ich vor, Dinge, die jetzt noch nicht erledigt sind und weiteren großen Diskussionsbedarf versprechen, ins Forum zu verlagern.

Da stimme ich dir nicht zu. Ich war, bin und werde auch voraussichtlich nie ein aktiver Forumsbenutzer sein. Weder in SELF noch sonst wo. Ich bin höchstens nur ein Forums-„Profiteur“ vorausgesetzt, eine Suchmaschine führt mich da hin. Der Grund dazu ist wohl der, dass ich ungeduldig bin. Wenn ich was wissen will, dann will ich das „gleich“ wissen. Und nicht erst 24-36 Stunden später. In 99% aller Fälle schaffe ich das auch, und finde meine Lösung in 3-90 Minuten Online-Recherche. Natürlich kann ich mir vorstellen, dass mit Kollegen zu fachsimpeln auch ganz nett sein kann. Aber z.B. in einem Wiki könnte die genaue Lösung dann kurz, knapp und präzise auch dargestellt werden. Das wäre für mich ein gutes Resultat. Ohne die Irr- und Abwege und sonstiges Gerede. Aber ich respektiere die aktiven Foren-Liebhaber durchaus. Jeder wie er will. Nur die Wiki-Diskussion, umgekehrt, vermehrt hier ins Wiki.

Ebenfalls kontraproduktiv ist, wenn man grad am Antwortverfassen ist und zwischenzeitlich jemand anderes die Seite verändert. Das kann man nicht verhindern, aber es macht Mehrarbeit, das dann nochman nachzueditieren.

Naja.

„Find ich nicht gut, dann muss man immer hin- und her springen...“ Stimmt nur bedingt. Mein (recht langer) Post von gestern Nacht: Auf meinem Monitor dennoch nur 1⅔ Fensterseiten. N' kleiner Scroll. Nicht „nochmal zu wiederholen oder anderweitig zu referenzieren“, sondern nur ein kleines Stichwort und jeder aufmerksamer (Nach-)Leser weiß genau auf was der Antwortende sich bezieht.

Solange es nicht ausartet, mag das gehen. Aber wenn sich das System der Zwischenantworten nicht (wenigstens als Kompromiss zu einem echten Forum) in der Wikipedia bewehrt hätte, hätte man es dort sicher anders gelöst, denke ich.

Kurz und knapp, nochmals meine Meinung dazu. Bei einer einzelnen oder ganz wenigen Fragen: Dazwischen schreiben, ok. Sonst ein/zwei Replys en-block. Später wenn nötig einzelne Punkte extra in eigenen Abteilungen auslagern. Ansonsten auch viel „Unsitten“, auch in Wikipedia. Aber lassen wir das. Ist jetzt alles dazu gesagt.

Der dem die Antwort gilt, checkt das sowieso gleich. Bei der ersten Antwort n' bisschen Scrollen, ist immerhin noch leichter, als mühselige History-Vergleiche um als Leser überhaupt etwas zu verstehen. „Einschränkungen“ und Kompromisse sind nicht so ganz meine Stärke. Da bin ich zu sehr boolean. Höchstens, dass – ja das kenne ich – dass bei und im Verlauf einer Diskussion, scheinbar unversöhnliche Widersprüche in ihrem dreifachen Wortsinn „aufgehoben“ werden. Das ist auch das beste, was bei Diskussionen herauskommen kann. Dennoch, ich arbeite tausend mal lieber in einem Wiki. Diskutieren, nur wenn es sein muss.

Server-Probleme

Schon gleich in den ersten Tagen hatte ich Error 500 Probleme. Zuerst dachte ich es läge am Quelltext. Irgendwelchen Parsing-Probleme die den Server in die Knie zwingt. Nach Tests, vor allem durch Code-Wegnahme hatte ich es bald verstanden: Bei wohl 128 kB ist Schluss. Etwas knapp konfiguriert. Aber wäre es nur das, dann gerade noch erträglich.

128k Seitengröße? Naja, das ist ja auch arg viel, vor allem beim Lesen. Es kommt ja eigentlich schon bei 32k eine Warnung. Besser ist es, die Themen auf mehr (Unter-)Seiten aufzuteilen. Das lässt sich auch einfacher verlinken als über Anker in den Seiten und rückvervolgbar sind Links auf Seiten wesentlich besser als Links auf Anker in Seiten.

Das Wiki ist ja eigentlich eine Lexikon-Software und verfolgt deswegen grundsätzlich die Philosophie: 1 Thema === 1 Seite. Für Javascript könnte man es so machen, dass die Eigenschaften und Methoden jeweils eigene Unterseiten bekommen. Wenn für den Leser eine Gesamtseite bereitgestellt werden soll, kann man diese Unterseiten wie Vorlagen-Verwendungen in die Hauptseite einbinden.

Man liest ja fast nie alles. Meistens nur quer. Und dann nur einige, jetzt interessierende Abschnitte genauer und aufmerksam. Die Methoden und Eigenschaften stets auseinander reißen ist mir unvorstellbar. Manchmal gibt es nur eine Methode und zehn Eigenschaften. Zwei Seiten??

Eigentlich 12 Seiten. Genauer: eine Unterseite für die Methode, zehn Unterseiten für jeweils die Eigenschaften und noch eine Hauptseite für das Objekt/die Klasse an sich, die durch Vorlageneinbindung den Text der Methoden und Eigenschaften inkludiert. Es ginge auch bei wenig Text für die Methoden und die Eigenschaften, nur eine Methoden- und eine Eigenschaften-Seite nebst der Hauptseite anzulegen. Aber ich denke, man sollte das lieber gleich richtig vereinzeln, dann muss man das nicht später nachholen, wenn die Textmenge ansteigt, und es ist konsequent zu den sowieso schon durch viel Text stark vereinzelten Themen.

Nö. Sehe ich völlig anders. Was zusammengehört soll auch zusammen bleiben. Die Serverleistung soll da sein.

Servezeit-Probleme

Einen nur in Paragraphen gegliederten Lorum ipsum Text liefert mir der Server auch bei knapp 128 kB in (akzeptablen) 0.7 sec. Jedoch braucht es zum Anzeigen meiner beiden, schon in zwei Teile gesplitteten, jeweils ±75 kB großen HTML-Elementobjekte-Seiten^[1] [2] jeweils geschlagene acht Sekunden oder nur ganz unwesentlich darunter. Das kann doch nicht angehen, wie du mir sicher zustimmen kannst. Die Besucher würden schnell die Lust an unserem Wiki verlieren, wenn dies so bliebe. Auf die Schnelle weiß ich keine andere Lösung als die beiden schon geteilten Teile nochmals jeweils zu halbieren, obwohl eigentlich alles zusammen auf eine einzige Seite gehört. 150 kB ist zwar etwas viel, aber nicht „wahnsinnig viel“. Nur die Hälfte, ok. Wenn es denn nu' schnell geserved würde! Bei einem Blindtext ist genau das der Fall. Daher kann ich mir letztlich nur noch vorstellen, dass die jeweils knapp vier Dutzend mal verwendeten Beispiel-Vorlagen diesen unhaltbaren Zeitverlust bewirken. Oder hättest du sonst noch eine Idee?

Ist es die Render-Zeit? Die bekommt man nur durch Verkleinerung hin. Ist nur der erste Seitenaufruf langsam und sind die weiteren schneller, dann hat nur die Cache-Füllung etwas gebraucht. Ansonsten löst sich das Problem vielleicht auch durch die unter Punkt 1 vorgeschlagene Aufteilung.

Das ist die Zeit, die im Browser-Quellcode auf allen MediaWiki-Seiten stets vermerkt wird. Ganz unten: <‍!-- Served in 1.507 secs. --></body></html>. Wahrscheinlich identisch mit der Render-Zeit: PHP+SQL. „Die bekommt man nur durch Verkleinerung hin.“ Nein!  Genau das sagte ich doch. Auf anderen Wikis, auf anderen Servern, schmeiße ich zu Testzwecken mal locker 1 MB „Lorum ipsum“ rein: Geserved in 1.254 secs. Bei dann gleich 16 MB Wartezeit, aber kein Error 500. Hab nicht abgewartet, sondern abgebrochen. Bei SELFHTML-Wiki knapp 128 kB Blindtext (Lorum ipsum): 0.7 secs. Gut die Hälfte, aber mit Vorlagen, fast 12x so lang 8 secs. Da muss es doch an was anderem liegen. Von wegen: „Die bekommt man nur durch Verkleinerung hin.“ Das ist genau die Art der „Einschränkungen“, die ich nicht ab kann. Von einem kleinen, vermutlich nicht allzu schwer lösbaren technischem Problem sich inhaltliche, beziehungsweise gestalterische Unfreiheiten auferlegen zu lassen. Ich selbst bin leider kein ausgesprochener Vorlagen-Crack. Lerne noch und kenne auch ParserFunctions zu schlecht, an denen es vielleicht liegt. Das müssen wir doch hinkriegen!

Riesige Texte bereiten nicht nur solche beobachteten technischen Probleme - die man vielleicht mit mehr zur Verfügung gestellten Ressourcen lösen kann (wenn man das dem Server zumuten will/kann) - sie sind auch mit dem kleinen Textfensterchen unhandlich zu bearbeiten, besonders in der Phase des Kontrollesens, wo man das Rendering des Wiks benötigt und nicht in einem externen Editor einfach nur schreiben kann.

Und dann gibt es technische Dinge, die man nicht einfach so beheben kann, wie beispielsweise externe Verweise auf Anker. Es ist nicht besonders clever, gegen die Philosophie eines Systems zu arbeiten. Vielleicht ist das System dann nicht geeignet, aber wer hat die Kraft, ein besseres System zu suchen und in Betrieb zu nehmen?

Schlappe 120 kB sind nicht „riesig“. Vergleich's doch mal mit einem einzigen JPG-Image Gewicht. Leistungsfähige Server sind weder rar noch teuer. Außerdem glaube ich gar nicht, dass es am NTT-Server liegt. (Gut, Japon-Telecom. Die Server aber ist hoffentlich hier in Europa.) Eher an den Vorlagen. Bei Section-Edit ist die Gesamtgröße eh egal. Aber ich gebe praktisch immer gesamt aus. Keinerlei Probleme beim Korrekturlesen. Mediawiki ist supertop, relativ wenig Schwächen und Bugs. Ich kenne nichts besseres. Ich werd mal mit meinen geringen Vorlagen-Kenntnissen Tests machen und dir dann in 'ner Woche oder so, berichten, ob ich herausgefunden habe oder nicht, woran's liegt. Wollen wir dahingehend verbleiben?

Bilder werden vom Apachen direkt ausgeliefert, Wiki-Seiten müssen immer zusammengebaut werden. Cachen geht nur in Teilen, weil stets dynamische Informationen (wie im Seitenfuß oder benutzerspezifische Ergänzungen) hinzugefügt werden. Die Server gehören auch SELFHTML selbst - wurden vor vielen Jahren mal nach einer Spendenaktion angeschaft -, stehen nur bei NTT im Rechenzentrum und der Traffic ist frei.

Danke für die Info bzgl. Server. Bzgl. Bilder, Apache, ok. Nur es sind erwiesenermaßen die vielen Vorlagen schuld. Mein Test eben mit HTML-Elemente_1, vor und nach Herausnahme von nichts anderem als der (nicht wenigen) Brackets. Servezeit vorher: 8,5 s und nachher 0,5 Sekunden. Wir werden früher oder später eine gute Lösung finden.

Eureka! Es sind die Browser-Icons. Und nicht die Beispielsvorlagen wie ich zuerst vermutete. Nach deren Ersetzung durch ihre jeweiligen Original-Divs ergab sich keinerlei Ladezeitverkürzung. Wohl aber nach der Lahmlegung der 42 Iconset-Vorlagen meiner Testseite. Plong: Von 8,4 s, auf nur noch 1,2 Sekunden. Also wahrscheinlich nicht mal "Iconset", sondern es ist höchstwahrscheinlich "Icon" selbst, das den Hemmschuh betätigt.

Vorlagen

Apropos Vorlagen. Ich habe bisher noch keine gemacht. Wenn bald doch, mal die eine oder andere Neue, mir sinnvoll erscheinende; so bitte ich dich doch gleich mit einem Purge-Tab ausgestattet. Immer ausloggen, einloggen und dann noch die F5-Taste drücken. Das ist viel zu umständlich. Die Purge-Erweiterung hingegen ist einfach und effektiv. Da man einen solchen zusätzlichen Purge-Tab nicht jedem registrierten Benutzer zumuten kann (Nicht, dass es gefährlich wäre. Es löscht ja nur den jeweils eigenen Wiki-Cache. Aber wer keine Vorlagen macht, der kann damit nichts anfangen...) müsstest du mir schon eine neue Usergroup zuweisen. „Bürokrat? Nein Danke!“ Ich weiß nicht, was sich da die anglophonen Mediawiki-Macher so denken. Aber „Bürokrat“ will doch niemand sein, oder? Ich schlage dir da die neue Usergroup:Agent vor. Von lat. agere, handeln, tun. Also: der (etwas mehr) Handeln könnende. Gegenüber „Bürokrat“ ist „Agent“ doch viel attraktiver. (Wie auch nicht zuletzt, die jüngst in die Schlagzeilen geratene Agentin 00SEX es beweißt ;-) Als das bisher einzige zusätzliches Recht dieser neuen Benutzergruppe bitte ich dich um das oben genannte, praktische Purge-Tab.

Bitte die Seite mit ?action=purge aufrufen (Ich weiß nicht, ob das auch mit wiki.selfhtml.org/wiki/NS:Seite?action=purge geht oder nur mit wiki.selfhtml.org/mediawiki?title=NS:Seite&action=purge). Ansonsten kannst du auch ein benutzerdefiniertes Javascript erstellen, das dir solch einen Link in die Seite einfügt.

Ja guter Tipp. ?action=purge als Lesezeichen. Reicht auch. „Benutzerdefiniertes Javascript“ da muss ich leider passen. Kenne ich mich nicht aus. Weiß ich nicht wie's geht. Benutzerdefinertes CSS interessiert mich sowieso nicht, sowie ich auch bewusst nie an den default-Styles im Browser herum doktere. Plugins und andere Optionen, ja. Style-Änderungen, nein. Aber zum benutzerdefinierten Javascript werde ich mich bald mal kundig machen.

Unter Spezial:Einstellungen-Aussehen gibt es zu jedem Skin einen Verweis auf benutzerdefiniertes CSS und JS. Dort einfach JS und/oder CSS einkippen.

Danke für die konkrete Hinführung. Hab's schon mal irgendwann gesehen. Aber welchen sinnvollen Script-Code soll ich da reinschreiben. Fällt mir nicht viel dazu ein. Trotzdem nochmals Danke.

Erweiterungen

Um zwei weitere, allen Benutzern offenstehende Erweiterungen bitte ich ebenfalls:

TreeAndMenu

Die Erweiterung TreeAndMenu kann uns vor allem in Inhaltsverzeichnissen nützlich sein. Man kann da frei bestimmen welche Verzeichnis-Tiefe per default offen ist und welche nur (bis hin zu Unterabschnitten der einzelnen Seiten,) dann noch manuell auf- bzw. wieder zugeklickert werden können. Das fände ich sehr praktisch.

Schau ich mir an, kann ich aber nicht sofort.

Okay.

PageCSS

Die Erweiterung PageCSS erscheint wohl auf den ersten Blick bedenklich, wenn nicht gar suspekt zu sein. Vielleicht auch nur, weil sie in Wikis im allgemeinen (noch) nicht sehr verbreitet ist. Dennoch glaube ich, dass diese Erweiterung, gerade in unserem Wiki eine wirkliche Bereicherung wäre. Sicherheitsprobleme, da nur CSS, gibt ist bei dieser Extension natürlich gar keine. Die Missbrauchsgefahren wohl. Sie liegen anderswo. Erstens, könnte ein schlecht inspirierter Benutzer z.B. auf die Idee kommen, mit vielen farblichen Veränderungen das bestehende Design zu verhunzen. Zweitens, könnte ein Vandale z.B. mit <h1>-hidden, gar den Titel der Seite verbergen! Beide diese Gefahren, die des Missbrauchs und die des Vandalismus sind bei Lichte betrachtet, auch nicht größer als die jetzt schon. Mit einer durchgängigen <div> und style="background:..." kann auch jetzt, jeder sehr leicht, eine ganze Seite in z.B. Pastellblau oder in Rosa tauchen. Macht aber Gott sei Dank niemand. Die Gefahr eines solchen „h1-hidden“ ist auch nicht größer, als ein sonstiger Seiten-Leerungs-Vandalismus oder ähnliches... Auch will ich dich ausdrücklich darauf hinweisen, dass diese Erweiterung PageCSS heißt, also nicht Wiki-übergreifend ist, sondern nur auf der jeweiligen Seite im Quelltext mit <css>...</css>-Tags geparsed wird. Weitere, andere Gefahren sehe ich nicht. Die Vorteile sind dagegen, m.b.M.n. groß. Insbesondere in den nicht allzu seltenen Fällen spezifischer Tabellenformatierungen trägt diese Erweiterung, gut genutzt, erheblich zur Vereinfachung bei. Nicht zuletzt, was doch auch sehr wichtig ist, ebenfalls zur Lesbarkeit des Codes. Vorlagen helfen dabei im konkreten Fall nichts oder nicht viel. Eine pretty-table Vorlage, schön und gut. Aber welcher Aufwand und vor allem „Code-Wust“ muss dann doch für eine wirklich schöne Tabelle betrieben bzw. entsteht. Zwar ist in der Wiki-Syntax alles möglich. Jedoch muss da in den <td>s alles, Zeile für Zeile, unnütz kopiert werden. Wie elegant und einfach ist da CSS! Ich glaube du hast verstanden was ich meine. Überlege es dir mal. Mir wäre es wichtig und gerade auf unseren Seiten könnte ich mir durchaus vorstellen, dass es auch andere Autoren auf dem Wiki hier zu schätzen wüssten.

Der Vorschlag kam schon mal (ich find's grad nicht), wurde aber abgelehnt. Es gibt Vorlagen für wiedernutzbare Formatierungen.

Bleibt weiter offen. Versuch mal die damalige Beschlussseite zu finden. Vorschläge, auch wenn einmal abgelehnt, können ggf. erneut erörtert werden. Finde bitte die Seite mit den Argumenten. „Wiedernutzbare Formatierungen“? Zweifle ich. Höchstens classes, die du mir in's common schreibst. Das wäre vielleicht halbwegs (viertelwegs?) annehmbar. CSS ist einfach elegant und einfach. Missbrachsgefahren, besonders auf SELFHTML, quasi Null. Jeder Nachbearbeiter kann ja ebenfalls den betreffenden CSS-Wert ändern, der ihm nicht passt. Kein Unterschied zu Text.

Es ist schon richtig, Dinge später nochmal neu zu beleuchten und gegebenenfalls eine Meinung oder Entscheidung zu ändern. Aber speziell beim CSS sehe ich keinen Bedarf an derartiger Individualität pro Seite. Wiederbenutzbare Formatierungen sind beispielsweise die Vorlagen für Beachten Sie oder die Beispiel- und Info-Boxen.

Wenn du irgendwo konkreten Bedarf hast, dann schreib das auf die dortige Diskussionsseite. Vielleicht lässt sich eine bessere Lösung finden, als individuelles CSS.

Es geht nicht um „individuelles“ CSS, sondern um Vermeidung von ätzendem Wiki-Syntax Code-Wust durch modernes, elegantes CSS.

Konkretes Beispiel:  Eine Tabelle, vier Spalten, 40 Reihen. Wiki-Syntax: <colgroup> funzt nicht. <col> funzt nicht. Off, OK.

Dann: erste Spalte jeweils text-align:center, zweite Spalte jeweils text-align:left, dritte Spalte jeweils (warum nicht, manchmal bei Zahlenwerten) text-align:right.

Dann: Ein nettes padding:left bzw. right rein, von knapp einem em und nicht so barbarisch, wurschtig und stillos, so häßlich auf den Rand geklebt wie allzu oft zu beobachten.

PageCSS, kein Problem. Spalte 1, 2 3 und 4. Jeweils eine Klasse: .a, .b, .c und .d. Mit Wiki-Syntax copy-past, copy-past, copy-past, copy-past... 40x den selben Schmarrn: |style="padding-left:0.8em; text-align:left; height:2em;| vier Spalten, vierzig Reihen = 160 mal den selben unnützen Krust. Wie im Irrenhaus! Und wenn ich dann sehe: height:1.8em wär doch angemessener, dann, alles auswählen, kopieren, ab in mein npp++, alles ersetzen, testen. Nein 1.6em wär noch schöner Nochmals die gleiche Prozedur. So was vorsidflutliches. Oder aber wie meist beobachtet: „Ist doch egal.“ Resultat: Unschön, wurschtig, geschlammpt...  das Net ist voll davon. Auch die Wikis.

Die Schlacht ist bereits geschlagen und zuungunsten der Wiki-Syntax ausgegangen. Wiki-Syntax ist nun mal nicht das Gelbe vom Ei. Der vorherige Ansatz für SELFHTML 9, die Inhalte in einem eigenen XML-Dialekt zu strukturieren, fand angeblich auch wegen zu kompliziert(er Handhabung) keinen Anklang. Argumente gegen die Wikisyntax haben sich nicht durchgesetzt. Ein Wiki wäre viel besser für die Mitarbeit geeignet - nur liegt leider die Mitarbeit unter den euphorischen Erwartungen der damals hitzig geführten Diskussion.

Wie auch immer, dein Formatierwunsch in Ehren, ich hab ja auch bei den einzelnen Seiten der HTML-Referenz Ansprüche an die Tabellen gestellt (inklusive ausklappbarer Teile). Aber ich habe sie (media)wikikonform und mit vielen Vorlagen gelöst - auch und vor allem weil da themabedingt viele Wiederholungen vorkommen und man sie mit Änderung einer Vorlage alle beeinflussen kann. (Ich seh da auch keine Performance-Probleme). Das selbe Prinzip der Wiederholungsvermeidung versuchst du nun mit dem seitenindividuellen CSS hinzubekommen. Eine Vorlage hätte den selben Effekt, nur dass man sie auch noch auf anderen Seiten verwendet werden kann. Du sagtest ja, dass du dich nicht gern anpassen willst, aber die Entscheidung für dieses System ist nun mal da und deswegen sollten zunächst die Möglichkeiten des Systems ausgeschöpft werden, bevor etwas neues installiert wird, das auch wieder etwas mehr Wartungsaufwand bedeutet. Wenn du bei der Vorlagenerstellung Unterstützung brauchst, kann ich dir helfen. Zettle doch dazu eine Diskussion auf (einer) der betroffenen Seite(n) an (ggf. mit Hinweis auf meiner Diskussionsseite, wenn ich das nicht selbst entdecke - ich lese nicht immer alles). --dedlfix 10:13, 6. Apr. 2011 (CEST)

Danke auch hier für den Link. Vielleicht komm ich mal dazu näher rein zuschauen.

Die Einbindung einer Extension, welcher auch immer bedeutet ja nicht, dass man danach nicht mehr „(media)wikikonform“ sei. Wenn du zum Beispiel ein Modul in deinen Firefox einfügst, (wenn du diesen benutzt,) weil es dir praktisch und nützlich erscheint, so würdest du ja auch nicht sagen, dein Browser sei jetzt nicht meht „firefoxkonform“. Alle Erweiterungen haben ja den Sinn, je nach Bedarf, unter anderem z.B. auch den Komfort zu erhöhen. Zuvor, da gebe ich dir Recht, muss man immer auch das mögliche Missbrauchsrisiko erwägen. Stellen wir's mal zurück. Mit Vorlagen kann ich nie Nachfahrenelemente ansprechen. Zum Beispiel alle TDs in einer TABLE, geschweige denn spezifisch nur die TDs einer ganz bestimmten Spalte. Das ist der Unterschied.

Struktur

Ähnlich wichtig, ja noch wichtiger wäre mir eine recht radikale Strukturänderung, die jetzt noch möglich ist, im noch recht jungen SELFHTML-Wiki. Ich spreche nicht von Layout und Stil. Diesbezüglich habe ich rein gar nichts auszusetzen, sondern im Gegenteil viel Lob und Anerkennung auszusprechen, ob der geleisteten Arbeit. (Zwar hatte ich Eingewöhnungsschwierigkeiten mit den internen Linkfarben. Das war aber auch alles.) Nein, ich meine den Baum, genauer deine „tausend“ Namespaces, die meiner Meinung nach nichts bringen. Im Gegenteil führen diese nur zur Verwirrung und zu tragen zu einer gewissen, von mir festgestellten Unübersichtlichkeit viel bei. Verschiedene Namespaces sind doch nur dann vonnöten, wenn du diese auch, von den Userrights her, verschiedlich konfigurierst. Aber genau das wirst du ja nicht gemacht haben! Verschiedene Benutzerrechte zwischen dem Namensräumen: Referenzen, Themen und Glossar? Das würde ja rein gar nichts bringen. Wenn sie nicht verschieden konfiguriert werden, dann brauchen wir auch diese ganzen, vielen Namensräume nicht. Das fängt schon beim Wort „Doku“ an. Mich, und nicht nur mich anscheinend, hat das anfangs nur verwirrt. (Schon allein der Name... Klar, Doku ist kürzer als Dokumentation. Doch ist „Doku“ nicht schön. Mir fiel dazu nur noch DokuWiki ein.) Warum denn alles umständlich, wenn es auch einfach geht! Ich schlage dir vor: Die jeweiligen Grundverzeichnisse beinhalten jeweils und prinzipiell nichts anderes als ihr jeweiliges Inhaltsverzeichnis. Eventuell auch ein oder zwei einleitende Sätze oder Verweise. Aber auch das nur sehr sparsam. Je weniger desto besser. Dann ist doch die Navigation in unserem Wiki auf nahezu ideale Weise verwirklicht. Fehlt dann nur noch eines: Root; eben unser Wurzelverzeichnis mit seinem integralen SELFHTML-Wiki Gesamtinhaltsverzeichnis. Da die Verzeichnisnamen ja alle möglichst kurz sein sollen, schlage ich hier „SELFHTML“ vor. Es ist schon klar, dass da das Wiki gemeint ist. Einen kleinen, aber gut hervorgehobenen Link zu de.selfhtml.org kann es dann dort in der ersten Zeile auch geben. Wenn sich ein Benutzer dann „weit oben in den Zweigen“ befindet, kann er, von jeder Seite aus, mit einem Klick zu allen Parent-Verzeichnissen und auch direkt zum Root kommen. Was will man denn mehr? Vielleicht eines noch: Ein paar wenige „Kategorie“-Inhaltsverzeichnisse, wo zum Beispiel: SELFHTML/HTML/Referenz, SELFHTML/CSS/Referenz, SELFHTML/JavaScript/Referenz etc. gemeinsam gelistet werden. Was meinst du zu diesem meinem Vorschlag?

Es sind nicht „meine“ Namespaces. Die waren leider schon da, als das Wiki online ging, und ich kam erst danach hinzu. Ansonsten, ja, Ja, JA!!! die Namespaces sind nicht gut. Schon die Suche klappt nicht wie vorgesehen, weil die versucht - lexikongleich - relevante Seiten sofort anzuspringen, was sie aber nur im Hauptnamensraum macht.

Das Thema ist schon eine Weile im „ja, müsste man mal anfangen“-Zustand in meinem Hinterkopf … Da das sehr umfangreich ist, wird man wohl nicht um einen ausführlichen Test in einem Paralleluniversum herumkommen und außerdem sich der Hilfe eines Bots beim Umschreiben der Seiten (inklusive Weiterleitungen) bedienen. wiki-test2.selfhtml.org existiert für allgemeine Tests. Für den Umbau werden wir aber sicherlich mehrmals Kopien von wiki.selfhtml.org ziehen müssen und daran üben. Dafür kann das vorgesehene wiki-test1.selfhtml.org verwendet werden, muss aber noch vorbereitet werden.

Ach. Da fällt mir aber ein Stein vom Herzen. T'schuldigung für fälschlich „dein“. War nicht nach-recherchiert. Hättest du mit hier eine strikt ablehnende Antwort gegeben, so wäre es wohl mein Knackpunkt gewesen. (Sicherlich der einzig mögliche.) Danke für deine Testseiten-Links. Schau ich mir mal an. Den tatsächlichen Arbeitsaufwand kannst du natürlich viel besser beurteilen als ich. Einfach deshalb weil du das SELFHTML-Wiki und seinen tatsächlichen Umfang viel besser kennst. Für den JavaScript-Teil, da bin ich mir sicher, wäre es sehr einfach. Da gibt es so ein verkapptes Inhaltsverzeichnis in [Referenz:JavaScript] Eine einzige Seite mit weiter unten von dir ein ToDo in [Kurse:JavaScript]. Und der ganze Content von [Doku:JavaScript] strotzt auch nicht gerade in einer „unübersehbaren Fülle“. Außer meiner noch aussehenden „fmt & links“-Bearbeitungen auf den noch allermeisten Seiten, warte ich dann praktisch nur noch auf dein grünes Licht zu seiner Überführung in den Mainspace. Dannach würde ich aufmerksam nachschauen, was aus den schon vorhandenen Doku:-Seiten an konstruktiven, wichtigem noch heraus geangelt werden muss.

Du kannst das alles erstmal in den Doku-Namensraum bringen. Für die generelle Namensraum- und Strukturkorrektur muss man das mal alles insgesamt sehen, denke ich. Jetzt schon einen Teil anzufangen bringt nur Verwirrung wegen der Inkonsistenz zum Rest, denn ich befürchte, dass das auch wieder ewig so bestehen bleibt, bis sich jemand dessen annimmt.

Ne. Da kannst du 100 Jahre warten. Ich verbringe die Seiten nie von meinem Benutzernamensraum in den Doku-Namensraum. Wenn du schon prinzipiell einverstanden bist, dann warte ich halt noch so lange. Zwei Wochen, vier Wochen, zwei Monate, länger...  Bis du deinerseits zur Strukturänderung bereit bist. Ist zwar schade, weil ich schon bald fertig bin mit der Wikifizierung von 8.1.2 JavaScript. Aber Pech! Ich transferiere nur und ausschließlich in den Hauptnamensraum, nie in Doku. Solange ich lebe nicht! Es steht dir natürlich frei, es selbst zu tun. Aber dann, ist ja klar, hat mich das SELF-Wiki gesehen. Das ist keine Erpressung, sondern nur meine Auffassung von meiner Deontologie. Ich arbeite nur und ausschließlich in einem Wiki mit, das Ansprûche hat, diese auch umsetzt und nicht in zweitklassigen Provisorien vor sich hin wurschtelt.

Alles andere

Weil mein Post hier inzwischen schon recht lang geworden ist: Nun, nur stichwortartig weitere Punkte.

Klickbare Beispiele

Auch hierzu habe ich konkrete Vorschläge. Selbst Alert-Boxen müssen ja „echt“ klickbar sein. Die Entwicklung dieser Vorschläge will ich aber auf später verschieben.

NEU hierzu:  Wie sieht denn ein klickbares Beispiel hier konkret aus? Ich sah dazu nur verschiedene (ältere) Vorschläge auf mindestens zwei verschiedenen Seiten. Hat irgend ein Beispiel-Administrator schon ein funktionierendes klickbares geschaffen? Mit einer Prompt oder Alert-Box zum Beispiel, das ich mal sehen könnte.

Auf alle Fälle sind auf der Dokumentationsseite zur Vorlage:Beispiel Beispiele anklickbar gestaltet. Und wenn du Apsels Änderungen verfolgst/anschaust, solltest du auch jede Menge Seiten mit anklickbaren Beispielen finden. --dedlfix 19:15, 5. Apr. 2011 (CEST)

Gut werde ich suchen.

Die Code-Color

Ich bin zwar selbst noch nicht ganz sicher... Ich fand aber diese Blau-Hervorhebung auf 8.1.2 gar nicht so schlecht. Mir ist zwar das Risiko eines unschönen, zu bunten „Papageien-Stiles“ durchaus bewusst. Doch <code> in blau: Würde dies letzteres wirklich hervorrufen? Was meinst du?

Bei Vorschlägen bitte ein möglichst konkretes Beispiel ausarbeiten und das zur allgemeinen Diskussion stellen (am besten im Forum - da gibt es auch eine Kategorie SELFHTML-WIKI).

Kategorie SELFHTML-WIKI im Forum?!  Hatte ich bisher auch noch übersehen. Werd's mal suchen und wohl auch finden. Danke für den Hinweis.

Gut, komme gerade von da. Zuerst hielt ich es für einen Scherz, weil ich da nix anderes als einen Post von einer Laura fand, die da was über „Musik in HTML“ wissen wollte und sich mit ihrem allerersten Post wohl eher in die Wiki-„Kategorie“ verirrt hatte.

Nach tieferer suche fand ich immerhin gut 500 Einträge im Archiv 2010 und etwa 90 im Archiv 2010:  Zum Beispiel was zu Kurzanleitung anklickbare Beispiele  mit vier Autoren: Matthias, dedlfix, Beat und einem Daniel S. Werde es mal lesen.

Aber im Prinzip eher umgekehrt:  Wiki-Diskussionen vermehrt ins Wiki verlagern. „Alte Forums-Hasen“ sollten, wenn sie sich wirklich (und hoffentlich zunehmend) auch für's Wiki interessieren: Wäre gut wenn sie auch öfters hier vorbei kommen. Nur „eingefleischte Gewohnheiten“?  Nein, meiner Meinung nach nicht nur. Hängt auch viel davon ab, wie Schnell wir hier das Wiki „auf Zack“ bringen und echt interessant machen. Dann werden einige auch (wieder) hier her kommen.

Im Prinzip gehören Wiki-Diskussionen ins Wiki, aber da gibt es leider einige Dinge, die dem entgegenstehen. Zum einen die Ungeeignetheit für längere Wortwechsel, und zum anderen dass anscheinend die wenigsten aktiven Forumsmitglieder dazu zu bewegen sind, dauerhaft und von selbst ins Wiki zu schauen. Man muss es ihnen immer mal wieder in Erinnerung rufen, was aber nach meiner bisherigen Erfahrung leider nur sehr mäßig erfolgreich ist.

Verstehe ich:  Ein wirklich gutes Wiki hat aber mittefristig Chancen das zu ändern.

Als ich selbst mit HTML/JS etc. am Anfang stand:  Da war mir das SELF, mindestens viele Monate lang eine wichtige Hilfe. Das war so in den ersten Jahren des Jahrtausends. Die damalige Performance  – und vielleicht sogar auch eine gewisse Hegemonie, zumindest im deutschen Sprachbereich, –  die hat das SELFHTML inzwischen aber sicher verloren. Zu obsolete Informationen, keine High-End Infos. Vielleicht im Forum. Doch das hilft nur einigen hundert sich dort austauschenden Cracks und hie und da einigen, wenigen sich einen Mut fassenden Neophyten.

Ohne ein gutes, aktuelles, breit vermitteltes Basiswissen, wird auch das Forum schnell zur Insider-Nische. Drum volle Kraft ins Wiki. Die Resultate der Forums-Diskussionen dann möglichst auch hier her. Dazu vielleicht ab Herbst auch eine Internationalisierung des Wikis. In zwei, drei Sprachen kann ich auch selbst (im Rahmen meiner Kräfte) dazu beitragen.

Erzähl das den anderen im Forum. Die Diskussion(en) würde ich aber ungern kopieren wollen, zumal dazu im Prinzip jeder für seine Beiträge zustimmen müsste, sie unter Wiki-Lizenzbedingungen zu stellen. Verweise tun es auch, denke ich.

Vielleicht mache ich mich in den nächsten Wochen auch Schritt für Schritt mit dem Forum vertraut.

Gibt es nicht jemand, der PHP hier auf SELF initialisieren könnte. Ich nicht. Kann zwar PHP lesen und modifizieren, aber nicht selbst Code schreiben oder es unterrichten. Die offiziellen PHP-Referenz-Seiten sind zwar einigermaßen lesbar. Die Benutzer-Adds, gleich drunter, sind aber recht „Kraut und Rüben“. Wie nicht richtig gesichtetet. Ein PHP-Teil wäre imho auch interessant für uns.

Du meinst eine PHP-Dokumentation/-Tutorial/-whatever hier im Wiki? Nun, wenn es jemand will, dann kann er gern auch über PHP schreiben. Aber das ist nicht das Hauptanliegen von SELFHTML. Es müssten jedoch eher mehr Mitstreiter für die bisherigen Themen gefunden werden. --dedlfix 19:15, 5. Apr. 2011 (CEST)

War auch nur so was wie Brainstorming bzw. eine nur sehr lanfristig umzusetende Idee. Nicht Hauptanliegen, aber auch nicht unwichtiger wie z.B. JavaScript.

So long, Klaus 18:12, 5. Apr. 2011 (CEST)

Schrittweise aufs Wiki

Ich kenne ja de.selfhtml.org nicht in Gänze. Dass zum Beispiel das gut funktionierende Forum dauerhaft auch dort verbleibt: Das ist für mich klar und ist auch gut so. Aber die wirklich integral hierher importierten Teile und die dann hier auch laufend aktualisiert werden, sollten wir dort auch durch manuelle, also explizite und nicht etwa automatische Redirect-Links stilllegen. Einfach um unsere Leserschaft nicht zu „verzetteln“. Die dabei zu beachtenden Einzelheiten können wir ja zu gegebener Zeit noch besprechen...

Ja, auch das hat die besten Chanchen umgesetzt zu werden, wenn es konkret ausgearbeitet ist. Die Doku sind statische Seiten, also würde eine Auflistung genügen, in welche Seite welches HTML-Schnipsel einzufügen ist.

Okay.

de.selfhtml.org als InterWiki

Manche, vielleicht auch kleine de.selfhtml.org Seiten müssen wir ja aus Tempo-Gründen noch auf absehbare Zeit noch weiter, von "wiki"- auf die "de"-SubDomain verlinken, z.B. Kleine Helferlein. Ich weiß nicht, ob mir da eine Syntax entgeht, aber wenn es keine andere Möglichkeit gibt, wäre eine (Pseudo-)InterWiki Einbindung von de.selfhtml.org mehr als wünschenswert. Einfach um die Extern-Icon zum Verschwinden zu bringen. Es ist ja kein „Extern-Link“. Für dieses InterWiki, entweder direkt die SQL-File editieren oder eine entsprechende Extension. Es gibt da mehrere, welche du willst. Aber Links von hier zur anderen Unterdomäne de. Bitte ohne Extern-Icon. Bei der Wahl entsprechenden InterWiki-Codes müsstest du die mögliche, hoffentlich nicht allzu ferne Internationalisierung unseres Wikis beachten. Aber das weißt du ja eh selbst.

Mit Interwiki hatte ich noch nicht zu tun, außer dass jemand schon mal Wikipedia-Links so gekennzeichnet hat und das dann wie interne Links aussah, was aber nicht gewünscht ist. Nun werden auch Interwiki-Links als external gekennzeichnet, was deinem Vorschlag entgegenläuft. Aber das lässt sich irgendwie regeln.

Ja gut.

Zeitzonze

Ein kleines, eher nicht so dringliches Detail-Problem ist unser derzeitiger Zeitzonen-Bug. In der signierten Unterschrift ist alles okay. Da gilt derzeit CEST, jedoch nicht in den Änderungen. Da ich weder auf Island noch in Liberia lebe, bringt mich das ein wenig (moderat) durcheinander. Mittelfristig müsste das „entkäfert“ werden. Auch im Sinne und Interesse aller zukünftigen aktiven Benutzer. Um sie nicht all zu sehr „in den Westen zu verstoßen“. In den Preferences hast du ja die persönliche Zeitzoneneinstellung raus geschmissen. OK. Auch ein ggf. auf anderen Längen lebendender Deutschsprachiger hat sich mit CEST abzufinden. Aber bitte nicht mit UTC! Bei persönlichen Einstellungen der Zeitzone kann man ja für die Browser-Einstellung optieren. Das beste. Ist das inhibiert, dann bleiben nur die entsprechenden Linien in den LocalSettings. Diese aber setzen aber eine korrekte Server-Einstellung des Providers voraus: „Schau m'r mal.“

Ich hab da nichts verboten. Der Server läuft auf UTC, soweit richtig, aber $wgLocaltimezone steht auf "Europe/Berlin". Ich dachte, das reicht. Aber jetzt wo du es sagst, fällt es mir auf, dass ich nach Ablauf der „dauerhaften Anmeldung“ immer UTC vorgesetzt bekomme. → ToDo-Liste

Was Klaus meint, ist, dass meine Unterschrift hier ca. 13:35 Uhr erscheinen wird, in den letzten Änderungen aber ca. 11:35 stehen wird. -- Matthias 13:35, 5. Apr. 2011 (CEST) --

Nicht wenn ich angemeldet bin, dann wird die in den letzten Änderungen stehende Zeit in die in meinen Einstellungen eingestellte Zeitzone umgerechnet. Man müsste also die Zeitzone für die unangemeldeten User noch irgendwie konfigurieren. --dedlfix 15:29, 5. Apr. 2011 (CEST)

Und zwar "aus dem Browser übernehmen" -- Matthias 17:07, 5. Apr. 2011 (CEST) --

Richtig Matthias. Aber erstens, selbst wenn gut in LocalSettings konfiguriert: Nur effektiv für die (zukünfigen) Neuen.

Und zweitens, manchmal verhindert auch ein schlecht voreingestelltes PHP seitens des Providers diese gute Inkraftsetzung.

-- Klaus 18:20, 5. Apr. 2011 (CEST)

Du hast es genau erfasst. Alle Alten müssen das ggf. selbst einstellen. Für die Neuen kann das auch richtig voreingestellt werden. Ich kenne das Problem, ist aber leicht verhext. Man kriegt's aber hin. -- Klaus 16:15, 5. Apr. 2011 (CEST)

Ich hab da nichts verboten.  Merke jetzt erst: War nur der Skin. In MonoBook und Vector, den beiden Skins die ich am besten kenne, gibt's da jeweils Tabs. Ich sehe die nicht, denke reduziert auf nur eines. Übersehe aber das Menü links. Muss mal meine Brille besser putzen...  Nur für die Neuen, hast du's ja jetzt auf deiner ToDo.

Nun, dies ist in möglichster Kürze vorerst alles. Es mag einige Punkte geben, wo du problemlos einverstanden bist, andere wo wir die Diskussion vertiefen müssen, wieder andere wo du dir das noch etwas überlegen willst und vielleicht auch ein oder zwei Punkte wo du gerne noch einige andere Standpunkte bzw. Argumente von anderen hören willst, bevor du dich als Admin so oder so entscheidest. All das werden wir ja gemeinsam sehen. Ich warte geduldig auf deine Antwort.

Bitte

Eine letzte Bitte: Respektiere doch meinen längeren Post-Block hier. Will heißen: Schreibe bitte nicht dazwischen. Das bereitet mir bei kürzeren Interventionen, wie oben, keine Probleme. Wenn ja nur eine Reply zu erwarten steht, dann ist das recht praktische dazwischen schreiben auch für mich annehmbar. Wenn sich aber zu dem einen oder anderen Punkt die Diskussion dann ausweitet, so ist es mir, zumindest als Leser, dann stets unmöglich eine solche Diskussion überhaupt auch nur zu lesen, oder eben, erzwungenermaßen, ein Graus.

Zu spät, schon alles getippt. Außerdem finde ich es übersichtlicher, auf genau das zu antworten, was ich beantworten möchte, ohne das nochmal zu wiederholen oder anderweitig zu referenzieren. So bleibt Thema und Antwort zusammen. Und das hat auch nichts damit zu tun, dass ich deine Ausführungen nicht respektierte - im Gegenteil. Das Wiki ist nun aber kein Diskussionsforum und wenn man es dafür verwendet, muss man mit Einschränkungen leben.

s.o.

Also, bitte deine Antwort, eingerückt, einfach en-block darunter. Bezug nehmen kannst du jeweils mit Stichwort-Nummern und/oder Erinnerungsstichworten bzw. durch kurze Zitate. Das erscheint mir die klarste, nachlesbarste Vorgehensweise zu sein.

Find ich nicht gut, dann muss man immer hin- und her springen – beim Lesen und auch beim Antworten. --dedlfix 12:27, 5. Apr. 2011 (CEST)

s.o.

Bis bald, best regards, Klaus 00:16, 5. Apr. 2011 (CEST)

Nachbemerkung zu meiner Antwort:  Habe noch einige zusätzliche Punkte gefunden. Lasse die aber vorerst. Etwa drei Viertel der Punkte sind jetzt wohl entweder schon geklärt, oder zurückgestellt oder auf ToDo-Listen. Auf einige Punkte wirst du mir wohl noch mal antworten wollen.

-- Klaus 16:15, 5. Apr. 2011 (CEST)

---

"Sicherheitsprobleme, da nur CSS, gibt ist bei dieser Extension natürlich gar keine."

"Die Kaspersky-Experten haben im Februar eine relativ neue Methode beobachtet, mit der schädlicher Code in Web-Seiten vor Antivirus-Software versteckt wird. Die Mehrzahl der Drive-by Angriffe im Web nutzt die an sich für das Layout der Seiten vorgesehenen CSS-Daten, um darin Code für Download-Scripte zu verbergen. Damit wird dann wie gehabt Exploit-Code geladen, der Sicherheitslücken auf den Rechnern der Anwender ausnutzen soll."

Gelesen in der PC-Welt 04/11 und kopiert von ng-online --Matthias 09:44, 5. Apr. 2011 (CEST)--

Guten Tag Matthias und Danke für deine neue, recht interessante Information.

Habe die verlinkte Seite gelesen. Wenn ich richtig verstanden: „Schwachstelle [...] im Hilfecenter von Windows XP sowie eine relativ neue Java-Lücke“ ausgenutzt, um mit in normalen CSS-Dateien verstecken Scripten diese anzugreifen. Ja, dann betrifft uns das ja nicht. Scripte in Mediawiki-Edit Quelltexten können ja ganz und gar nicht ausgeführt werden. Ganz gleich ob sie innerhalb oder außerhalb von PageCSS-Tags stehen.

Trotzdem Danke für deine Info. Erfreut von unserer ersten Begegnung, Klaus 11:17, 5. Apr. 2011 (CEST)

---

Neuer Vorschlag

Nach meiner letzten Antwort von vorher, habe ich einen neuen Vorschlag.

Lass uns doch bitte, Dedlfix, unsere Diskussion hier mal unterbrechen.
Ich will dir da weder ein sickiges EOD rein knallen, noch dir sonst irgendwie das Wort abschneiden.

Im Gegenteil: Ich danke dir für unseren ersten Gedankenaustausch hier.
Wenn du noch was wichtiges zu anzumerken hast: Nur zu...

Mein Anliegen ist nur: Gleichzeitig arbeiten und viel diskutieren geht schlecht.
Machen wir doch mal 10-14 Tage beiderseitige Denkpause. Ich werde versuchen,
bis dahin den JavaScript-Import zu Ende zu bringen. Du gehst deinen Beschäftigungen nach.
Wir haben uns jetzt ein bisschen kennen gelernt. In knapp zwei Wochen nehmen wir manches ausstehende,
jetzt noch nicht geklärte, wieder auf, und werden dann sehen, wie wir weiter verfahren.

Das hätte den Vorteil, dass so die Arbeit weiterginge.  Klaus 22:46, 5. Apr. 2011 (CEST)

Browsericons

Hallo Dedlfix,

da du ja auch mal wieder hier vorbeischaust: Die Browsericons sind alle! (zumindest was den Chrome betrifft) -- Matthias 17:19, 25. Mai 2011 (CEST) --

Ich schaue üblicherweise täglich vorbei, aber nur still, wenn es nichts einzugreifen gibt :-) Chromes werde mal ein paar hinzufügen. --dedlfix 17:58, 25. Mai 2011 (CEST)sind ein paar hinzugefügt. --dedlfix 19:40, 25. Mai 2011 (CEST)

neue Browsericons

Hallo dedlfix, ich wäre Dir sehr dankbar, wenn Du die folgenden Codezeilen ins MediaWiki:Common.css einfügen könntest, Vorlage:Iconset/Dokumentation und Datei:Iconset.png sind schon angpasst. Dankeschön :)
[… gekürzt …]
-- Florian Edelmann (Flo2154) - 09:40, 3. Jul. 2011 (CEST)

Erledigt. --dedlfix 14:49, 3. Jul. 2011 (CEST)

neue Icons: Java

Bitte mal wieder die MediaWiki:Common.css anpassen: [… gekürzt …]
Dankeschön :) -- Florian Edelmann (Flo2154) - 18:02, 9. Jul. 2011 (CEST)

Erledigt. --dedlfix 21:26, 9. Jul. 2011 (CEST)

Mehrzahl deutsch vs. englisch

Das Mehrschwein von entity ist entities ;-) --Beat 21:03, 28. Mär. 2010 (CEST)

Ja, wenn man englisch spricht, dann ist die Mehrzahl von hobby auch hobbies und babies für baby. Aber die deutschen Mehrzahlregeln hängen einfach ein s an's y: Babys, Hobbys. Im Falle von Entitys könnte man Entity-Referenzen sagen und wäre damit einerseits richtiger und umgeht das Mehrzahl-Problem, andererseits ist das auch sperriger. --dedlfix 21:08, 28. Mär. 2010 (CEST)

Struktur Grundlagen

Zur Info: Auf Benutzer:Beatovich/SELFHTML812_Kritik habe ich die Grundlagen-Struktur nach Selfhtml 8.1.2 analysiert und mit Vorschlägen aus Selfhtml 9 verglichen.
Ich brauche eine Idee über den Allgemeinen Konsens, und ein Ort, wo der Bestand neu gesichtet werden kann.
Grundsätzlich sind die 8.1.2 Verzeichnisse gesund. Einziges Problem habe ich mit 'Hypertext'.
Leider habe ich keinen Plan, was sich das Selfhtml 9 Team bei seinen Vorschlägen dachte.
Deine Anmerkungen darst du ruhig auf Benutzer:Beatovich/SELFHTML812_Kritik anbringen und diesen Abschnitt hier löschen. --Beat 16:01, 12. Apr. 2010 (CEST)

SELFHTML-Wiki/… (ohne Namensraum) wäre ein möglicher Ort. Ansonsten – nimm’s mir bitte nicht krumm – aber ich habe im Moment schon zu viele Baustellen offen, so dass ich mich grad nicht darum kümmern möchte. Versuch doch mal einen Aufruf im Forum diesbezüglich. --dedlfix 19:51, 12. Apr. 2010 (CEST)

Löschen beantragt

Wie kann man das Löschen von Dateien beantragen?

Die Weiterleitungen aus dem Namensraum Beispiel können gelöscht werden, weil keine Datei mehr dort hin verweist. -- Matthias 11:42, 17. Mär. 2011 (CET) --

Füg die [Vorlage:Löschen] in die entsprechende Seite ein. --dedlfix 12:03, 17. Mär. 2011 (CET)

Die Vorlage wurde nie verwendet und daher gelöscht --Matthias Scharwies (Diskussion) 05:25, 25. Dez. 2021 (CET)

Glossar:Bot

Die Datei Bot könnte auf der Seite der letzten Änderungen verlinkt werden, dort wo die Kürzel N, K und B erläutert sind. -- Matthias 19:08, 12. Apr. 2011 (CEST) --

Geht nicht (genauer: ich bekomme es nicht hin). Der Text neben dem B ändert sich nicht, dafür bekommt der Tooltip auf dem B eine ungeparste Version des Systemtextes. --dedlfix 09:18, 13. Apr. 2011 (CEST)

Vorlage cursordemo

Hallo Dedlfix,

Gibt es eine Möglichkeit, dem Parser mitzuteilen, nach }} keinen Zeilenumbruch zu generieren? (Es sah im Testwiki schon mal wunschgemäß aus mit * {{Cursordemo}}, jetzt aber dort auch nicht.) Ein Blick in den Quelltext ergibt Zeilenumbrüche

<p><span class="cursordemo" style="cursor: ns-resize"></span>
, <code>ns-resize</code>, Cursor in Form eines Doppelpfeils, der nach oben und unten zeigt<br />
<span class="cursordemo" style="cursor: ew-resize"></span>
, <code>ew-resize</code>, Cursor in Form eines Doppelpfeils, der nach links und rechts zeigt<br />
<span class="cursordemo" style="cursor: nesw-resize"></span>
, <code>nesw-resize</code>, Cursor in Form eines Doppelpfeils, der nach rechtsoben und linksunten zeigt<br />

<span class="cursordemo" style="cursor: nwse-resize"></span>
, <code>nwse-resize</code>, Cursor in Form eines Doppelpfeils, der nach linksoben und rechtsunten zeigt<br />
</p>

Das Getrickse ist weniger schön.

Die Hintergrundgrafik könnte aus dem Wiki selbst auch verschwinden und wie die für die Beispiele nach "http://src.selfhtml.org/" verschoben werden.

-- Matthias 20:08, 6. Feb. 2012 (CET) --

Wenn du keine Zeilenumbrüche haben möchtest, musst du den Code auch ohne Zeilenumbrüche schreiben, auch wenn die Vorlagen damit nahezu unlesbar werden. Nicht auszugebende Zeilenumbrüche lassen sich lediglich in HTML-Kommentaren unterbringen.

weder im relevanten Teil (?) der Vorlage selbst <includeonly><span class="cursordemo" style="cursor: {{{1}}}"></span></includeonly> noch im entsprechenden Quelltext ** {{Cursordemo|auto}}, weiterer Text ist ein Zeilenumbruch. Möglicherweise ist aber <onlyinclude><includeonly>…</includeonly></onlyinclude> das Mittel zum Zweck.

Warum brauchst du überhaupt eine Hintergrundgrafik? Das macht die Sache nicht einfacher und bringt meines Erachtens nach keinen Gewinn. --dedlfix 20:42, 6. Feb. 2012 (CET)

einfach nur ein weißes Kästchen?

-- Matthias 21:06, 6. Feb. 2012 (CET) --

PS Du könntest mal wieder archivieren ;-)

Dateien *.cur

Ich würd' gern tick.cur und cross.cur hochladen, damit das Beispiel zu cursor auch im IE funktioniert.

-- Matthias 21:15, 7. Feb. 2012 (CET) --

Genehmigt. --dedlfix 11:02, 9. Feb. 2012 (CET)

Erledigt, das Dateiformat kann ja jetzt wieder raus.

-- Matthias 13:28, 9. Feb. 2012 (CET) --

ConfirmEdit, eine einfache Antispam Captcha Extension

Außer meiner Antwort auf meiner Benutzerseite. Bezüglich einem Antispam:
Anstatt sich regelmäßig mit diesem Sch... rumzuärgern, probier' es doch einfach und impliziere ConfirmEdit.
Mit einer Konfiguration skip-it für registrierte Benutzer und ggf. nur by-url-added hat das imho schnell ein Ende.
-- Klaus Quappe 20:06, 30. Mär. 2011 (CEST)
PS. Wenn es ein Bot ist. Registrieren ohne, ist ok. Doch mit SimpleCaptcha & addurl schließt man zumindest die reinen Spam-Bots aus.

Danke für die Idee, aber: Noch ist der Leidensdruck nicht zu hoch, das Spamaufkommen sehr niedrig. Es ist deutlich mehr Aufwand für die Bearbeiter, ständig Aufgaben lösen zu müssen als der Aufwand, den Spam zu beseitigen (vielleicht würde das Captcha mehr zur Nutzung der Vorschau-Funktion führen anstatt zu vielen kleinen Änderungen, aber auch das Wegbleiben der Bearbeiter wäre eine Reaktion, allerdings eine nicht wünschenswerte). Da hier sowieso nur registrierte Nutzer bearbeiten können, müsste man für die skipcaptcha-Option eine weitere Berechtigungsgruppe einfügen und die Nutzer mit administrativem Aufwand dieser zuweisen. Auch den schätze ich derzeit höher ein als das Spamaufkommen. Die Option nur bei addurl (also wenn ein oder mehrere URLs zu einer Seite hinzugefügt werden) ein Captcha einzublenden, wäre allerdings ein guter Kompromiss zwischen Bearbeiter nerven und Spam, meine ich. Den Vorschlag werde ich aufgreifen, wenn der Spam meine Reizschwelle überschreitet. --dedlfix 09:12, 31. Mär. 2011 (CEST)

Jaja, genauso meinte ich das auch. Alle Tiggers auf false, außer urladd. Ab autoconfirmed, ebenfalls alles auf false. Betroffen sind nur ganz neue Benutzer und auch dann, nur wenn sie gleich eine URL reinhauen wollen.
Keine neue Usergroup. Neben $wgAutoConfirmAge, auch $wgAutoConfirmCount reinschreiben und das letztere beispielsweise auf ein Dutzend Edits regeln. Die reinen URL-Spambots schaffen dann nicht einen einzigen.
Ob sich der Konfigurierungsaufwand lohnt, das musst du selbst wissen. Grüße, Klaus 10:14, 1. Apr. 2011 (CEST)   (Wäre ja noch „schöner“, wenn jeder bei jedem Edit schlappe Rechenaufgaben lösen müsste ;-)

gudn tach!

als randbemerkung: in der wikipedia, wo allerdings deutlich mehr gespammt wird als bei uns, sind diese captchas fuer unangemeldete user, die links hinzufuegen, aktiviert. und da scheint's ganz ok zu funzen. ich denke, man kann bei uns die technischen anforderungen an die user sogar etwas hoeher ansetzen als in der wikipedia, weil wir ja ein webdesign-handbuch schreiben. klar, es muss trotzdem user-freundlich sein. was ich damit nur sagen will: wenn's in der wikipedia funzt, dann bei uns erst recht. -- seth 23:33, 21. Apr. 2012 (CEST)

Kleine Zwischen-Info: Heute wollte ich mal die ConfirmEdit-Extension instalieren, aber die aktuellen Serverprobleme hinderten mich daran. Also abwarten, hoffentlich kann es jemand reparieren, und weiter per Hand entspamen. --dedlfix 21:21, 15. Mai 2012 (CEST)

gudn tach!

danke fuer die info. und, ja, ich glaube auch, dass die extension etwas helfen wuerde. ausserdem koennte es vielleicht auch was bringen, mittels der TBL (die auch noch nicht installiert ist) die laenge fuer gueltige artikelnamen etwas zu reduzieren. -- seth 23:39, 15. Mai 2012 (CEST)

Die Extensions ConfirmEdit, TitleBlacklist, SpamBlacklist und auch noch User Merge and Delete (um die Spammer-Accounts mal auf einen zu reduzieren) sind im Test-Wiki installiert. Aktiv ist derzeit nur ein SimpleCaptcha beim Account-Erstellen. Da sich dorthin kein Spammer verirrt, können wir die Wirksamkeit nicht direkt prüfen. Die Variante SimpleCaptcha war zwar nicht empfohlen, aber ich habe mal ein paar Bezeichner geändert, in der Hoffnung auf unintelligente Scripte. Die TBL/SPL würde ich erstmal nur installieren wollen, ohne importierte (ressourcenfressende) Liste und ohne Live-Aktualisierung. Aktivierung bei Bedarf, wenn ConfirmEdit nicht zieht.

Nach einer kurzen Testphase werde ich die Extension auch hier installieren. --dedlfix 22:01, 22. Mai 2012 (CEST)

gudn tach!

auf der test-wiki-seite wurde ich uebrigens erst mal wieder mit unmengen an "Unable to allocate memory for pool"-meldungen begruesst.

was ist denn live-aktualisierung? und mit "import" meinst du da den dynamischen import von [meta.wikimedia.org/wiki/Spam_blacklist]? -- seth 23:35, 22. Mai 2012 (CEST)

Die Meldungen sehe ich meist auch nur dort, gehen aber nach ein paar mal aktualisieren weg. Mit Live-Aktualisierung meine ich zum Beispiel TBLSRC_URL. Das holt sich die Daten ja nicht ständig sondern hat einen Cache, der ab und an verfällt. Durch das erneute Holen aktualisiert sich die Liste. Importieren ist das händische Kopieren von irgendwoher nach MediaWiki:Titleblacklist. --dedlfix 00:02, 23. Mai 2012 (CEST)

gudn tach!

die captchas bei der anmeldung (so wie in der wikipedia[1]) werden vielleicht schon genuegen, um dem derzeitigen spam einhalt zu gebieten. danach kann man weitersehen.

bin dafuer, das bald auch im richtigen wiki zu aktivieren. es scheint nicht weniger spam zu werden. -- seth 23:44, 23. Mai 2012 (CEST)

Die Extensions ConfirmEdit, SpamBlacklist, TitleBlacklist und UserMerge sind nun auch hier vorhanden. ConfirmEdit ist beim Anmelden aktiv und das Account-Anlegen geht. Für UserMerge braucht man die Admin-Kennung beziehungswiese Bürokratenberechtigung. --dedlfix 22:21, 24. Mai 2012 (CEST)

ok, dann schauen wir erst mal, ob ConfirmEdit was bringt, ohne SBL und TBL zu benutzen. -- seth 22:51, 24. Mai 2012 (CEST)

Sieht man eigentlich die erfolglosen Anmeldeversuche? Kann man also feststellen, wie erfolgreich das Tool ist?

-- Matthias 09:32, 24. Mai 2012 (CEST) --

Nein, bisher nicht. Aber das ist eine gute Idee. Ich werde mal versuchen, da noch ein Log hinzuzufügen. Ich werde es aber heute/morgen/wannzeitist auch ohne das Log aktivieren, dann sieht man zumindest wenn es nicht wirksam ist. --dedlfix 09:59, 24. Mai 2012 (CEST)

ich weiss nicht, ob solch ein log wirklich noetig ist. es erschwert schlimmstenfalls kuenftige updates. -- seth 22:51, 24. Mai 2012 (CEST)

ich mag ConfirmEdit! :-) -- seth 23:27, 3. Jun. 2012 (CEST)

CSS Umstrukturieren

Hallo Dedlfix,

Aus meiner Sicht ist es sinnvoll, die Selektoren aus den Grundlagen zu entfernen, sodass die Struktur dann so aussieht:

• Stylesheets (CSS)
  • Grundlagen
  • Ansprechen von Elementen
  • CSS-Eigenschaften
  • Anwendung und Praxis

Was hältst du davon?

wenn irgendwann die Namensraumgeschichte gemacht wird ...

-- Matthias 18:57, 27. Apr. 2011 (CEST) --

Ich bin dafür, die Struktur bei der Seitenbenamsung flacher zu machen. Die Grundlagen können ja unter dieser Überschrift zusammengefasst werden, aber im Pfad braucht es den Abschnitt Grundlagen_von_CSS nicht. Auf der Einstiegsseite zu CSS würde ich nicht nur die drei (vier) Punkte listen sondern stattdessen Überschriften und den Inhalt der jeweiligen Seiten darunter anführen. Doku:CSS/Grundlagen_von_CSS bekäme dann nur noch eine Weiterleitung zu Doku:CSS (meinetwegen auch mit Anker). Das selbe mit den anderen Bereichen.

Da nun alles (oder vieles) flacher benannt ist, kann man es bei Bedarf auf der Einstiegsseite hin- und herschieben, ohne dass bisherige Pfadnamen falsch werden.

Ich hoffe, du kannst meine Gedankengänge nachvollziehen. --dedlfix 22:53, 27. Apr. 2011 (CEST)

find' ich sinnvoll -- Matthias 07:42, 28. Apr. 2011 (CEST) --

Suche Bereich, den ich bearbeiten kann

Ich bin wieder da - und weiß, dass es mehr als genug Arbeit gibt. Wo wäre es am dringendsten? --Vinzenz 00:03, 10. Feb. 2012 (CET)

Das Anwerben qualifizierter Autoren wäre am dringendsten ;-) Gleich gefolgt kommt aktuell das Raussuchen einer spam-erschwerenden Mediawiki-Erweiterung, die allerdings den Spagat schafft, ernsthafte Autoren nicht zu beeinträchtigen. (Schön wäre es, wenn die Erweiterung nicht nur Spam verhindert sondern auch zumindest für Administratoren sichtbar die Versuche aufzeigt, so dass man dafür verwendeten Benutzernamen sperren kann). Eine größere Aktion wäre das Auflösen der fachlichen Namensräume. Das ist aber eine Herausforderung, die man gut planen und am Modell und einer 1:1-Kopie durchspielen muss. Die Bereiche, in denen Artikel fehlen, sind ja recht schnell zu finden. Weniger offensichtlich sind die Anfänge von gut meinenden Autoren, die in Qualität und Stil Aufholbedarf zur sonst üblichen SELFHTML-Qualität haben. Außerdem könnten manche Hierarchien vereinfacht werden, so dass man weniger bis zum gewünschten Ergebnis zu klicken hat. Umsortieren der Portalseiten mehr anwenderorientiert/fachlich statt Sortierung nach organisatorischen Zusammenhängen wäre auch eine Maßnahme (zum Beispiel steht der LaTeX-Kurs bei den Kursen und nicht beispielsweise unter weiterführendem Wissen. Organisatorisch mag das richtig sein, LaTeX ist aber keine der Kernkompetenzen für Webentwicklung, eigentlich noch nicht einmal ein Randthema.) --dedlfix 11:22, 11. Feb. 2012 (CET)

Dass die ersten zwei dringend sind, hab' ich gemerkt, als ich mir die Liste der letzten Änderungen angesehen hab.

Beim Beantworten einer Forumsfrage sind mir die Beispiele zur Textausrichtung aufgefallen:

• Doctype, der den IE in den Quirksmodus schickt,
• unzureichendes CSS. Kopiert man sich das Beispiel, so sieht man im Browser keine Auswirkung.

Da fange ich an. Ich muss mich zuerst wieder mit der Wiki-Syntax vertraut machen. Die Bearbeitung vorhandener Seiten ist dazu hoffentlich das beste Mittel. --Vinzenz 23:25, 11. Feb. 2012 (CET)

gudn tach!

ich hab mir auch vorgenommen, wieder etwas haeufiger (als gar nicht) hier im wiki vorbeizuschauen.

wer hat denn eigentlich root-rechte und ist noch aktiv? imho sollte die software mal geupdatet werden, auf 1.18. als anti-spam-extensions schlage ich jene vor, die auch in der wikipedia eingesetzt werden:

• SBL (fuer link-spam)
• TBL (fuer namen von neuen usern und seiten)
• abuse filter aka edit filter (fuer alles, das man nicht anders besser loesen kann)

das edit filter bietet eine eigene kleine scriptsprache, um konkrete einschraenkungen wie "alle user, die nicht mind. 100 edits auf dem buckel haben, duerfen in artikeln, die mit 'A' anfangen, nur woerter ersetzen, die nicht mit 'Self' anfangen" zu formulieren. man kann damit edits blockieren, kann user beim ersten speicher versuch einen hinweis ausspucken, und alles was durch eine regel des filters gematcht wird, wird automatisch mitgeloggt.

die sbl und die tbl sind wesentlich primitiver und loggen auch versuche nicht mit, aber sind dafuer in der performance etwas besser. -- seth 17:53, 21. Apr. 2012 (CEST)

Christian Seiler hat bisher die Grundinstallation betreut. Allerdings muss vor dem Update erstmal geprüft werden, ob das gefahrlos gemacht werden kann, ob die Extensions laufen und/oder ob Anpasssungen vorgenommen werden müssen. Meine Möglichkeiten beschränken sich auf das Installieren von Extensions und Skins. (Eine Frage wäre auch, wie es der Third-party-DPL geht. Ist die wieder genesen und an aktuelle Versionen angepasst?)

Bei den ASEs (Anti-Spam-Extensions) bin ich mir nicht im Klaren, wie die konkret helfen können. Wobei mir die SBL noch diejenige mit dem meisten Nutzen und wenigstem Aufwand zu sein scheint. Bei den anderen wüsste ich nicht, welche Regeln für uns sinnvoll sein können. --dedlfix 20:43, 21. Apr. 2012 (CEST)

das abuse filter kann z.b. verhindern, dass jemand einen artikel erstellt, der genauso heisst, wie er selbst (das schien mir bei einigen der vandalen gerade in mode zu sein). mit dem abuse filter kann man ausserdem das loeschen grosser artikelteile durch neulinge verhindern. auch sowas wie [2] (nur fuer admins einsehbar), also das hinzufuegen eines weblinks, ohne weiteren kommentar, ohne sig und ohne vorherige edits laesst sich verhindern. ausserdem lassen sich ausnahmen definieren und durch das automatische logging geht nichts wirklich verloren. das einzige worauf man immer achten muss, sind false positives und dass man keine unschuldigen damit vergrault.

zur DPL kann ich nix sagen, kenne ich nicht, wird in der wikipedia afaics nicht verwendet. -- seth 23:25, 21. Apr. 2012 (CEST)

Beim derzeitigen Spamaufkommen und dessen Art (einmalige Änderung/Seitenanlegen) wird es nicht viel weniger Administrationsaufwand. Es fällt nur die Seitenlöschung weg, die Sperrung des Nutzeraccounts bleibt. Auch das Log prüfen bleibt, schon wegen der false positives – ist das eigentlich ein separates Log? --dedlfix 16:59, 23. Apr. 2012 (CEST)

gudn tach!

ja, derzeit wird es vermutlich nicht weniger admin-aufwand, sondern zumindest anfangs sogar etwas mehr. das AF ist sehr komplex und flexibel, aber auch kompliziert. seitenloeschung/accounterstellung und alles andere auch, was spammer gerne so machen, laesst sich eindaemmen, aber nie komplett beseitigen. false positves lassen sich bei geschickt gewaehlten parametern je nach anwendung nahezu vollstaendig vermeiden. mit der zeit bekommt man auch ein gefuehl dafuer, welche logs man hin und wieder mal ueberpruefen muss, und welche nicht. es empfiehlt sich so oder so, eine seite zu erstellen, auf der false positives gemeldet werden sollen.

was das log betrifft: es ist ein separates und man kann sich (als admin) die logeintraege auch auf regeln einschraenken lassen, siehe auch [3] und dort oben rechts im kasten die links. die transparenz ist fuer jede regel einzeln einstellbar.

das groesste problem am AF in der wikipedia ist imho, dass es technisch kompliziert genug ist, dass es fuer normal-user haeufig nur als hexenwerk verstanden wird, dem man als nicht-admin einfach ausgeliefert ist. dieses problem haben wir in selfhtml erst mal nicht, weil wir nicht ganz so offen, sondern etwas redaktioneller aufgebaut sind und eben ohnehin eigentlich nur technik-affine autoren haben (wollen), denen es leichter verstaendlich zu machen sein sollte, dass ein solches filter mehr positive als negative seiten hat.

uebrigens: die SBL (die TBL ebenfalls) kostet fast nichts (an arbeit), ausser die installation. ein tolles feature daran ist, dass man per default die meta-sbl inkludiert. und jene wird staendig geupdatet, ohne dass man sich darum zu kuemmern braucht. -- seth 00:39, 24. Apr. 2012 (CEST)

JavaScript

Hallo,

nachdem Hirnbrand angekündigt hat, sich um JS kümmern zu wollen und Klaus Quappe schon lange nichts mehr getan hat, solltest du vielleicht Klaus' Arbeit (Benutzer:Klaus_Quappe/Work_8.1.2/JavaScript) in die Doku verschieben.

-- Matthias 21:46, 31. Mai 2012 (CEST) --

Antwort siehe Benutzer_Diskussion:Hirnbrand#JavaScript --dedlfix 22:33, 1. Jun. 2012 (CEST)

Begriffsklärungsvorlagen

Hallo,

ich habe im Test-Wiki Vorlagen zur Begriffsklärung erstellt. Sie sollten uns bei der Nutzung des Hauptnamensraumes dienlich sein. Ich würde Teile des CSS-Bereiches in den HNR verschieben und dann lass uns mal schauen, wie es dann aussieht.

Meine Idee ist, dass der Namensraum Doku im HNR aufgeht und die anderen erhalten bleiben.

-- Matthias 14:59, 3. Jun. 2012 (CEST) --

Ja, deine Idee stimmt auch mit meinen überein. --dedlfix 15:46, 3. Jun. 2012 (CEST)

---

Mir fiel gerade noch eine andere Idee ein. Aus Ordnungsgesichtspunkten finde ich eine (durchdacht gewählte) hierarchische (Unter-)Seitenbenennung schon sinnvoll, zum Beispiel: „JavaScript/Objekte/windows/blur“. Ein Vorteil davon ist nämlich der automatische Brotkrumenpfad, woraus man als Leser auch sehr schön Informationen zum Kontext bekommen kann, ohne dass man sich im Seitentext großartig abmühen muss. Im Gegensatz dazu steht die Funktionalität der Suchfunktion, die lieber Hauptseiten hätte. Zu den Hauptseiten kommt auch noch das Problem der Mehrfachverwendungen von manchen Bezeichnern. Die Lösung könnte so aussehen, dass die eigentlichen Seiten einen hierarchischen Titel bekommen („JavaScript/Objekte/windows/blur“) und zusätzlich dazu Weiterleitungen oder Begriffsklärungsseiten im Hauptnamensraum existieren („blur“ => Weiterleitung zu „JavaScript/Objekte/windows/blur“, „name“ => Klärung JavaScript-window-Eigenschaft und HTML-Attribut. Konkret sähe das dann so aus:

• http://wiki-test2.selfhtml.org/wiki/JavaScript
• http://wiki-test2.selfhtml.org/wiki/JavaScript/Objekte
• http://wiki-test2.selfhtml.org/wiki/JavaScript/Objekte/window
• http://wiki-test2.selfhtml.org/wiki/JavaScript/Objekte/window/name
• http://wiki-test2.selfhtml.org/wiki/JavaScript/Objekte/window/blur

Man beachte jeweils den Brotkrumenpfad. Dazu kommen noch

• http://wiki-test2.selfhtml.org/wiki/Name
• http://wiki-test2.selfhtml.org/wiki/Blur

für die Suchfunktion und Kurz-Links.

Ich bitte um weitere Meinungen. --dedlfix 00:06, 4. Jun. 2012 (CEST)

liest sich vernuenftig. bin dafuer. -- seth 23:34, 4. Jun. 2012 (CEST)

Ich denke, damit (und damit) können wir es als beschlossene Sache ansehen. Diese „Richtlinie“ müsste jetzt nur noch als Hilfsseitentext verfasst beziehungsweise vorhandene Hilfetexte angepasst werden. (Sehe ich da gerade ein <I> auf mich zukommen?) --dedlfix 10:05, 5. Jun. 2012 (CEST)

Konkrete Aufgaben für deinen Bot

Im Zusammenhang mit der Umstrukturierung würde ich gern deinem Bot folgende Aufgaben übertragen:

• Füge an das Ende einer jeden Unterseite von Doku:CSS den Text [[Kategorie:CSS]] ein, natürlich ohne die <nowiki>-Tags
• Suche in allen Seiten nach [[Doku:CSS]] und ändere es zu [[CSS]]
• Suche in allen Seiten nach [[Doku:CSS| und ändere es zu [[CSS|

Die erste Aufgabe umfasst 127 Seiten, die zweite und dritte zusammen 20.

-- Matthias 17:25, 3. Jun. 2012 (CEST) --

Erledigt. Was der Bot übrigens schon eingebaut hat ist das Korrigieren von Verweisen auf Weiterleitungen (die Verweise werden zum eigentlichen Ziel umgeschrieben) und das Auflösen von doppelten Weiterleitungen. --dedlfix 21:51, 3. Jun. 2012 (CEST)

---

Die letzten Änderungen dokumentieren, wie ich mir das vorstelle. Sag was dazu. Was mich ein wenig stört, ist die Großschreibung des ersten Buchstabens. Die Suchfunktion arbeitet korrekt. -- Matthias 19:33, 3. Jun. 2012 (CEST) --

Das Problem der Schreibweise kennt die Wikipedia auch. Ausschließlich die Groß-/Kleinschreibung kann man mit {{SEITENTITEL:…}} anpassen. Weitere Änderungen bewirken nur, dass der Titel unverändert stehenbleibt. Zudem ist die Anpassung nicht in der Vorschau zu sehen. Ansonsten kennt die Wikipedia auch noch die Vorlage „Korrekter Titel“. Siehe http://de.wikipedia.org/wiki/Wikipedia:Namenskonventionen/Technische_Einschränkungen.

Der Suchfunktion habe ich heute ein wenig an den Parametern gedreht, so dass jetzt beim Eintippen bereits Vorschläge angezeigt werden und das Suchergebnis (falls keine Seite direkt angesprungen wird) weniger Markup zeigt.

„Liste von CSS-Eigenschaften‎“ finde ich als Seitentitel nicht so toll. Zum einen wäre ein „der“ besser, zum anderen würde ich es nur „CSS-Eigenschaften“ nennen. --dedlfix 21:51, 3. Jun. 2012 (CEST)

Nochwas: Die Seiten fangen nun relativ erklärungslos an. Der Leser weiß nun erst einmal nicht, wo er da gelandet ist, was ihm diese Seite bietet, sofern er nicht von einer Portalseite her gekommen ist und schon Kontext im Hinterkopf hat. Ich denke, es könnte besser ungefähr so aussehen: [[Doku:JavaScript/Objekte/window/name]] (siehe auch das Markup, damit wird es für Zusammenfassungsseiten einbindbar). Der Text kann dabei ruhig noch etwas gesprächiger sein, à la: „Diese Seite beschreibt eine Eigenschaft des window-Objekts von JavaScript. Hierarchie: JavaScript – Objekte – window“ --dedlfix 22:40, 3. Jun. 2012 (CEST)

gudn tach!

zum ersten buchstaben: in der wikipedia gibts zwar das magic word DISPLAYTITLE, aber z.b. im wiktionary ist diese (imho aeusserst bescheuerte) technische einschraenkung nicht gegeben, dort sind die lemmata komplett case sensitive. koennten wir bei uns ja auch so handhaben. man muss dazu afaik bloss $wgCapitalLinks auf false setzen. -- seth 23:24, 3. Jun. 2012 (CEST)

Zusammenfassung

Antworten bitte direkt an die entsprechenden Punkte

• Die Variante mit Hierarchie und im HNR Weiterleitungen scheint mir der Königsweg zu sein.

Hierzu hätte ich noch gern mindestens Seths Meinung, der hat mehr Erfahrung mit den Mediawiki/Wikipedia-Gegebenheiten.

in der wikipedia versucht man solche hierarchien im ANS moeglichst zu vermeiden. user-pages und portale/redaktionen besitzen dagegen einige solche hierarchischen unterseiten. meines wissen ist die tiefe allerdings nie besonders gross, sondern eher max. 3. bei uns wuerde ich auch versuchen, die tiefe nicht allzu hoch zu treiben. aber dadurch, dass wir nun mal von der artikelstruktur im gegensatz zur wikipedia eine viel deutlichere/ausgepraegtere artikel-hierarchie haben, waere es unsinnig, diese hierarchie zu verwerfen, zumal sie ja auch zum verstaendnis beitraegt.

als struktur finde ich also dedlfix' idee gut geeignet. die redirects und disambiguations (BKSs) im main NS halte ich fuer sehr sinnvoll, schon allein, weil man dann das wiki auch gut mittels smart bookmarks als schnelles nachschlagewerk benutzen kann, was andernfalls naemlich nicht gescheit moeglich waere.

soweit zur struktur und zur navigation von aussen. zur internen navigation: die eingebaute navi unter den lemmata bei mit slashes separierten seitennamen ist schon mal eine feine sache. zusaetzlich kann man uebrigens z.b. mittels {{Subpage}} manuell diese navi auf seiten setzen, die nicht dieses slash-merkmal aufweisen. sinnvoll koennte zudem eine indexbox sein, wie sie in der dt.-sprachigen wp-hilfe rechts oben angezeigt wird (z.b. [4]). wie das geht, kann man z.b. anhand [5] sehen. ist eine template-schlacht, aber visualisiert dem user die struktur und ist eine gute, schnelle navi-hilfe. uebrigens faend ich V-T-E links, wie in [6] ebenfalls sinnvoll. -- seth 00:24, 5. Jun. 2012 (CEST)

Wenn man dann irgendwann Zeit hat, kann man über {{Infobox}} Beispiel oder {{Navigationsleiste}} Beispiel nachdenken. -- Matthias 11:17, 5. Jun. 2012 (CEST) --

• Du kannst ja, die Weiterleitungsseiten, die ich deiner Meinung nach nicht hätte löschen sollen, wiederherstellen.
• Unabhängig davon sind mir die Bedenken zu Links, die von außen hierher verweisen, auch gekommen. Wir sollten vielleicht gar keine WLs mehr löschen (außer die, die jetzt noch entstehen, wenn man den Königsweg umsetzt).

Mindestens solche Hauptseiten wie Doku:CSS (und wichtige Unterportale) sollten als Weiterleitung stehenbleiben. Wenn Unterseiten nicht gefunden werden, steht zumindest ein Brotkrümel da, der zur Weiterleitung auf die neue Portalseite angeklickt werden kann.

ich glaube auch, dass wir uns mehr redirs erlauben sollten als die wp, aber uebertreiben sollte man es auch nicht. es macht den kram u.u. schlechter wartbar. wann allerdings eine uebertreibung anfaengt, kann ich auch nicht sagen. ;-) -- seth 00:24, 5. Jun. 2012 (CEST)

• CSS-Eigenschaften verschiebe ich auch erst dann, wenn klar ist wohin, mit der Namensgebung bin ich einverstanden
• das gleiche gilt für die Seite font, die eine WL auf font (CSS) werden sollte
• Ich hätte trotzdem gern für jede Eigenschaft eine eigene Seite (außer vielleicht border-bottom-color ...)

Dafür! Eigene Seiten sind allemal besser als Monsterseiten, auf denen man die einzelnen Punkte nur per Anker ansprechen kann. --dedlfix 19:45, 4. Jun. 2012 (CEST)

ich moechte aber auch auf den nachteil der starken aufteilung hinweisen: browser-eigene suchfunktionalitaet wie ctrl-f und dabei insb. die inkrementelle suche wird durch sowas erschwert. ich faend's z.b. ziemlich kacke, wenn diese doch recht grosse seite aufgeteilt werden wuerde, denn manchmal weiss man nicht, wie etwas heisst, aber kennt bestandteile davon; und gerade bei programmiersprachen sind das haeufig auch mal zeichen, die bei verwendung der website-eigenen suche ignoriert oder falsch interpretiert werden. (wer hat in diesem kontext noch nicht ueber google geflucht? die hatten sogar mal eine geniale explizite suche fuer programmcode, aber leider wurde das projekt aus nicht wirklich nachvollziehbaren eingestampft.) z.b. fuehrt eine suche bei uns nach "(?:" ins leere, obwohl es dick und breit in Doku:Perl/Reguläre Ausdrücke erklaert wird. -- seth 00:24, 5. Jun. 2012 (CEST)

Ja, so eine Aufteilung fand ich auch Mist, als die PHP-Dokumentation das PREG-Kapitel gesplittet hatte. Es war sicherlich groß und unwartbar geworden, danach war es undurchsuchbar geworden, gerade wenn man Zeichenfolgen und keine Begriffe suchte. Aber zu den Einzelseiten kann man ja (in den sinnvollen Fällen) noch eine Zusammenfassungsseite hinzufügen, in die dann die Einzelteile als Vorlage eingebunden werden. So hab ich das ja schon für das [[Doku:JavaScript/Objekte/window|window-Objekt von Javascript]] gemacht. Eigenschaften und Methoden sind vereinzelt, was aber auf der Seite nicht auffällt, wenn man nicht in den Quelltext schaut. Allerdings könnte der doppelte Content für Verwirrung bei Anwendern und Suchmaschinen sorgen. --dedlfix 09:51, 5. Jun. 2012 (CEST)

-- Matthias 11:19, 4. Jun. 2012 (CEST) --

Brotkrume

Was hältst du von dem CSS für die Brotkrume? http://wiki-test2.selfhtml.org/wiki/JavaScript/Objekte/window/name -- Matthias 12:53, 4. Jun. 2012 (CEST) --

Die Farbgebung gefällt mir nicht. Die suggeriert mir zu sehr eine Warnung. Ich finde die bisherige Unauffälligkeit ausreichend. Der Pfad ist ein Navigationshilfsmittel. Wenn du das unbedingt formatieren willst, würde ich eine Anlehnung an die anderen Navigationsfarben vorschlagen (die von der linken Seite, nicht die Bearbeiten-Elemente oben). --dedlfix 18:37, 4. Jun. 2012 (CEST)

einverstanden -- Matthias 18:58, 4. Jun. 2012 (CEST) --

passt jetzt ganz gut zum selfhtml-skin.

persoenlich benutze ich allerdings das vector-skin, weil es mir von der wikipedia am vertrautesten ist und weil es auf dem bildschirm viel platz spart. und dort sehen die roten links dann nicht so gut aus. gibt's da nicht vielleicht skin-unabhaengige platzhalter fuer die linkfarben? -- seth 23:37, 4. Jun. 2012 (CEST)

gilt jetzt nur für das SELFHTML-Skin -- Matthias 21:35, 5. Jun. 2012 (CEST) --

Diskussionen zur neuen Struktur

Für Diskussionen, die mit der Umstellung auf die neue Struktur zu tun haben, habe ich SELFHTML Diskussion:Umstellung_auf_die_neue_Struktur eingerichtet. -- Matthias 21:34, 5. Jun. 2012 (CEST) --

JavaScript-Tutorial

Bezüglich der Einrückung meines Beispiels beim JavaScript Tutorial/Kurs: Sowohl in der bisherigen 8.1.2 SELFHTML als auch in anderen Wiki-Texten wird _kein_ Code eingerückt, finde ich persönlich grad für Anfänger dann schwierig, v.a. wenn bei Beispielen nicht klar ersichtlich wird, was genau das wichtige/wesentliche an diesem Beispiel ist. Habe mich allerdings mit der Einrückung an den anderen Seiten orientiert und nicht eingerückt. Wäre es nicht sinnvoll da eine gewisse Konsistenz zu wahren und a) alles sinnvoll einzurücken .. da ist dann die Frage, was genau sinnvoll ist, oder b) weiterhin nichts einzurücken => wie verfahren wir beim JavaScript Tutorial? Zweite Frage von mir: Ich bin ein bisschen erschlagen und überfordert mit der Auswahl, wo ich etwas beitragen kann, ich würde gerne zu diesem Wiki beitragen, traue mir durchaus den einen oder anderen Grundlagen-Artikel im Bereich HTML, CSS, JavaScript oder jQuery zu...bloß was genau? und ich welchem Umfang? Bitte da konkrete Vorschläge, was zu tun ist. Wieweit soll das "kleine" (?) JavaScript Tutorial gehen? Es tauchen ja jetzt schon Dopplungen zur normalen Doku auf. --Krabbler 10:41, 12. Jun. 2012 (CEST)

Inkonsistenzen ergeben sich (zwangsläufig) durch die unterschiedlichen Arbeitsweisen und Vorlieben der Autoren. Einrücken von Code ist für das Lesen sehr von Vorteil. Das sollten Einsteiger von Anfang an auch so angezeigt bekommen. Wenn du irgendwo uneingerückten Code findest, kannst du ihn gern formatieren. Ich plädiere aber dafür, mit der automatischen Syntaxhervorhebung sparsam umzugehen. Die vielen Farben könnten mehr verwirren als nutzen. Gezielte Hervorhebungen können besser mit Fettschrift oder Kursiv oder händischem Farbeinsatz vorgenommen werden. Inhaltliche Dopplungen zwischen dem Dokumentationsteil, der eine Vollständigkeit zumindest anstrebt, und Kursen, die vor allem beim Einsteigen helfen sollen, sind nicht zu vermeiden. Wenn in der Doku bereits ein bestimmer Aspekt für Einsteiger geeignet beschrieben ist, kann der Kurs sich ja auf einen Verweis beschränken.

Wichtig ist erstmal, die bisherige Dokumentation zu übertragen und durchzusehen. Inwieweit das für den HTML-Teil bereits geschehen ist, hab ich nicht verfolgt. Um CSS und JavaScript kümmern sich gerade Matthias und Benutzer:Hirnbrand. Da kannst du sicher auch mitmachen, solltest dich aber mit ihnen abstimmen. Wie eine Dokumentationsseite aussehen kann und welche Unterschiede zur bisherigen Form sinnvoll sind, hab ich mal auf der Hilfe:Wiki/Artikel aufgeschrieben. Wir haben auch grad beschlossen die bisherige Struktur umzustellen. Selbst wenn du nur den HTML-Teil (oder andere Bereiche aus dem Namensraum Doku) dementsprechend umbaust, ist schon viel geholfen.

Ich habe auch einen Bot, der stupide Handarbeit abnehmen kann. Wenn du konkret formulieren kannst, was zu tun ist, kann ich das dem Bot beibringen. --dedlfix 16:08, 12. Jun. 2012 (CEST)

OK, dann werde ich einfach meine zukünftigen Beispiele einrücken. Dass die Farbe nicht immer sinnvoll ist, grad für die Grundlagen Texte hab ich schon gelesen + verstanden ;) Fett-Druck eignet sich da ja auch gut.

Für HTML ist die Doku schon so gut wie fertig übertragen, es fehlen noch ein paar Artikel zu den Formularen, die werde ich mir die nächsten Tage mal vornehmen, habe gerade mit den Versteckten Elementen angefangen, da müsste das Beispiel noch verlinkt werden. So wie ich das verstanden habe, ist es ja möglich die 8.1.2 im Wesentlichen zu übernehmen und nur anzupassen, zumindest habe ich das bei vielen Unterseiten der HTML-Doku so gesehen. -- Krabbler 17:35, 12. Jun. 2012 (CEST)

Newarticletext

Du warst etwas schneller, deshalb heißt mein Vorschlag noarticletext (im Test-Wiki). Vielleicht kann man beides vermischen. -- Matthias 22:01, 13. Jun. 2012 (CEST) --

Es sieht so aus, als ob wir beide Texte brauchen. Ich hatte beim ersten Schauen immer newarticletext bekommen. Aber nun sehe ich, kommt manchmal new und manchmal no. --dedlfix 22:24, 13. Jun. 2012 (CEST)

Unterseite oder Benutzerseite für deinen Bot

Erstell doch eine solche Seite, da wären dann seine Aufgaben schön zusammengefasst.

• Es gibt einige (neue) Links auf Weiterleitungen, weil ich endlich Seiten auch mal nur verschieben brauchte. -- Matthias 19:37, 15. Jun. 2012 (CEST) --

Eine Benutzerseite hat er ja schon, und eine Aufgabenseite darfst du ihm gern unterjubeln. --dedlfix 22:38, 15. Jun. 2012 (CEST)

Du oder Sie

Ich war der Meinung, im Wiki werden unsere Leser gesietzt. -- Matthias 20:53, 21. Jun. 2012 (CEST) --

Ja, aber die Systemtexte gibt es in beiden Formen. Da solltest du nicht mischen. Wenn für unangemeldete der Du-Text angezeigt wird, sollten wir eher die Default-Sprache auf de-formal umstellen. --dedlfix 21:29, 21. Jun. 2012 (CEST)