Mitgliederversammlung 2018


Die diesjährige Mitgliederversammlung des Vereins SELFHTML e.V. findet am 8.9.2018 um 10:00 Uhr in Dortmund statt.

Die Adresse des Tagungsortes sowie die geplante Tagesordnung entnehmt ihr bitte der Seite https://forum.selfhtml.org/events/3.

Interessierte Gäste sind gern gesehen.

Hilfe Diskussion:Wikistruktur

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

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 „Wikistruktur“ besser im SELFHTML-Forum geführt werden.
  • Unter https://forum.selfhtml.org/meta/new kannst du einen entsprechenden Beitrag erstellen.
  • Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.

Information

Diese Seite ist für Diskussionen, die unmittelbar (und nur) mit der Umstellung auf die neue Struktur zu tun haben, gedacht. Ich erhoffe mir dadurch eine strukturiertere Bearbeitung von auftretenden Problemen, als das auf einzelnen Benutzer-Diskussionsseiten der Fall sein kann. Erledigte Abschnitte können durch (erl.) gekennzeichnet werden und später archiviert werden.

Information

Abgeschlossene Diskussionen finden Sie im Archiv.

Vorlage:Achtung-eingebunden[Bearbeiten]

Wie sinnvoll ist diese Vorlage?

  • Es macht sicher Sinn, diese Vorlage nur angemeldeten Benutzern zu zeigen. Dazu muss
    • die Vorlage neu gemacht werden, das heißt ich kann nicht einfach {{Achtung|...}} verwenden - das ist kein Problem
    • und für nicht angemeldete Benutzer .achtung-eingebunden {display: none} ins CSS geschrieben werden - Wo schreib ich das hin?

-- Matthias 18:26, 18. Jun. 2012 (CEST) --

Meines Wissens und nach Anschauen der Quelltexte für un- und angemeldete Nutzer kannst du sie nur über JavaScript unterscheiden (Variable wgUserName und das JS in MediaWiki:common.js). Es gibt nur ein Stylesheet, das Unterschiede enthält, aber das wird vom Skin erzeugt, ist also nicht übergreifend nutzbar. Rein als CSS-Lösung müsste ich das im Skin für unangemeldete ausblenden. Alle anderen bekommen es ständig zu sehen, auch wenn sie nicht bearbeiten wollen. Das nur beim Editieren einzublenden geht nur mit JavaScript. Neben der Variable wgAction=edit kannst du nicht viel mehr als einen (versteckten) Kategorien-Eintrag als Entscheidungskriterium heranziehen. (Versteckt, weil den im Normalfall auch keiner sehen sollte.) --dedlfix 00:11, 19. Jun. 2012 (CEST)

weitere Namensräume abschaffen[Bearbeiten]

mein Vorschlag:

  • Artikel:foo/bar --> Artikel/foo/bar mit Kategorie Artikel
  • Kurse:foo/bar --> Tutorial/foo/bar mit Kategorie Tutorial
  • Themen:foo/bar: in Artikel einordnen

Welche Meinung gibt es dazu?

-- Matthias 10:56, 25. Jun. 2012 (CEST) --

„Artikel“ braucht es als Seitentitelbestandteil gar nicht. Ob eine Kategorisierung jenseits vom Inhalt sinnvoll ist, bezweifle ich. Einsortiert werden sollten auch solche größeren Abhandlungen unter dem jeweiligen Fachbereich und auch dort nach fachlichen Gesichtspunkten. Die bisherige Trennung erfolgte aus historischen Gründen, weil die Dokumentation als fester Baustein angesehen wurde und solche Artikel in die Aktuell-Struktur eingebaut wurden. Aus Sicht des Lesers ergibt diese Aufteilung keinen gesteigerten Sinn. Früher waren die Artikel sogar noch in lange Artikel und kleine Tipps und Tricks aufgeteilt. Auch das hatte nur einen organisatorischen Hintergrund. Diese Trennung hatte ich damals schon erfolgreich bemängelt, so dass alle gleichberechtigt im Aktuell-Bereich einsortiert wurden. Das Aufsetzen des Wikis hatte ich nicht mitbekommen und dann war es schon passiert. Ich wollte auch nicht gleich zu Anfang motivationsdämpfend den Aufbau infrage stellen. Der Leser sucht jedenfalls die Lösung seines Problems nicht anhand des Aufwands von dessen Beantwortung – den kennt er in der Regel nicht. Wohl aber sucht er nach fachlichen Gesichtspunkten, falls er strukturiert vorgeht und keine Suchmaschine verwendet.
Für Kurse/Tutorials und die Themenschwerpunkte gilt das analog. Der HTML-Kurs könnte unter :HTML/Tutorial/… stehen und auf der :HTML-Seite irgendwo am Anfang verlinkt werden, da wo allgmeine Einführungen stehen. Einen Extra-Abschnitt für Tutorials auf der Startseite halte ich auch nicht für sonderlich sinnvoll. Man könnte eher statt unter Basiswissen nur einen Anstrich pro Bereich zu haben, lieber den drei Hauptbereichen HTML, CSS und JavaScript einen eigenen Abschnitt geben und deren wesentlichste Stichpunkte direkt verlinken. Ein Tutorial könnte einer davon sein.
Diese Umstellung steht auch schon auf meiner ToDo-Liste, aber wenn du eher Zeit hast, können wir ein TuDu daraus machen. --dedlfix 11:57, 25. Jun. 2012 (CEST)
die Einsortierung habe ich verstanden.
Startseite etwa so? -- Matthias 21:33, 25. Jun. 2012 (CEST) --
Fast. HTTP würde ich bei Weiterführendes Wissen einsortieren, aber das ist nicht so wichtig. Die Punkte Dokumentation und Artikel, bzw. die Unterscheidung zwischen ihnen finde ich nicht gut. Artikel sollten sich nahtlos ins Fachgebiet einordnen, so dass man nicht im Zweifel entscheiden muss, ob etwas einen Artikel-Status bekommt oder nicht. Wenn das Thema wichtig ist, bekommt es einen Ehrenplatz auf der Startseite, sonst „weiter hinten“. Tutorial ist ein wichtiges, Allgemeines/Grundlagenwissen ist eins (wie man es genau nennt, darüber kann man noch streiten) und die Beschreibung der Elemente ist mindestens ein drittes wichtiges Thema bei HTML. Es können durchaus noch mehr sein, nur nicht zu viele - oder vielleicht was ausklappbares. Irgendwie so würde ich das organisieren. --dedlfix 22:36, 25. Jun. 2012 (CEST)

"Einzelseiten statt Monsterseiten"[Bearbeiten]

gudn tach!
wenn dieser abschnitt dazu fuehrt, dass der ehemals uebersichtliche (nicht mal 23kB-grosse) artikel ueber schleifen in perl unuebersichtlich zerfleddert wird in mehrere kleine mini-artikel, dann laeuft was falsch. egal, ob man anfaenger oder fortgeschrittener oder autor ist, diese aufteilung irritiert mehr als dass sie irgendwas strukturiert. ich habe an diversen stellen hier im wiki schon gruende gegen solche aufteilungen genannt. einer, den ich noch nicht genannt habe, ist uebrigens das "mal-schnell-ausdrucken-wollen". und ganz ehrlich: wer 23kB-Seiten als monsterseiten auffasst, scheint mit netscape 2 unterwegs zu sein. heutzutage fangen monsterseiten erst bei einigen hundert kB an.
z.b. die strikte trennung von for und foreach ist ohnehin unsinnig, weil die beiden keywords in perl schon lange vollkommen aequivalent sind. als das noch ein einem artikel stand, hatte ich vor, irgendwann mal diese grenzen etwas besser zu verwischen. jetzt, wo das noch staerker separiert ist, sinkt bei mir auch die lust, da was verbessern zu wollen, weil es mehr aufwand waere als vorher bzw. weil es einfach unbequemer waere, weil ich immer mehrere seiten gleichzeitig aufhaben und bearbeiten muesste.
das argument mit den sich aendernden anchors macht uebrigens selbst der wikipedia kaum probleme. fuer zusaetzliche anchors gibt's uebrigens (seit ein paar tagen auch bei uns) die vorlage template:anchor. -- seth 23:43, 12. Sep. 2012 (CEST)

gudn tach!
uebrigens koennte man mit einem tool, das auf einem dump der db arbeiten wuerde, auch tote anchor-links finden. iow: das was der abschnitt derzeit suggeriert, stimmt so nicht. -- seth 00:48, 14. Sep. 2012 (CEST)
Vorteil Mini-Seiten
Im CSS-Bereich hat jede Eigenschaft ihre eigene Seite bekommen. Naja fast: Es gibt margin, aber margin-top nur als Weiterleitung . Das halte ich auch für sinnvoll und möchte es auch in der CSS-Referenz so machen. Wenn es jetzt mehrere Stellen gibt, in die die margin-Seite reingehört, dann kann ich dies einfach über eine Einbindung lösen und hat so keine Redundanzen. Das ist vor allem bei den Referenzen sinnvoll.
-- Matthias 09:00, 20. Sep. 2012 (CEST) --

SELFHTML:Redaktionelles[Bearbeiten]

gudn tach!
sollte SELFHTML:Wiki nicht vielleicht besser hier auf SELFHTML:Umstellung auf die neue Struktur eingebettet werden? -- seth 22:37, 19. Sep. 2012 (CEST)

redirs zu perl-funktionen[Bearbeiten]

im kontext von [1] stellte sich mir die frage, ob man redirects bzw. disambig pages wie index, rindex, split etc. anlegen soll oder besser nicht, oder nur noch nicht? die funktionsliste von perl ist zwar wesentlich kuerzer als die von php, aber sie ist trotzdem lang: [2].
vorteile waeren: 1. ajax-suche findet was. 2. smart keywords wuerden vermutlich nur so sinn machen. nachteil: arbeit. -- seth 22:48, 19. Sep. 2012 (CEST)

Konfiguration der Beobachtungsliste[Bearbeiten]

An anderer Stelle wurde als Argument gegen viele kleine Seiten ins Feld geführt, dass fehlerhafte Änderungen leicht übersehen werden können. Ich habe festgestellt, dass Änderungen an eingebundenen Seiten nicht auf Änderungen der einbindenden Seite auftauchen.

Zur Veranschaulichung: Die Seiten "margin" und "padding" seien in die Seite "Abstand" eingebunden.

Gibt es die Möglichkeit der Konfiguration der Wiki-Software, dass

  • eine Beobachtung von "Abstand" automatisch zur Beobachtung von "Abstand", "margin" und "padding" führt oder
  • Änderungen von "margin" auf "Abstand" durchschlagen, einen Hinweis bringen wie "eingebundene Seite oder Vorlage wurde geändert"?

-- Matthias 10:10, 20. Sep. 2012 (CEST) --

gudn tach!
meines wissens gibt es sowas nicht. (und in der wikipedia war ich bisher auch ganz froh, dass das nicht automatisch geschieht.)
und es sollte auch je nach umsetzung nicht automatisch erfolgen, weil dadurch z.b. unnoetig viele history-eintraege erzeugt werden koennten oder es die leute nerven wuerde, wenn sie denken, mehrere von ihnen beobachtete seiten kontrollieren muessen, obwohl sich auf einigen gar nichts veraendert hat.
es koennte dafuer wohl ein bot dressiert werden, um z.b. alle aenderungen bestimmter (unter-)kapitel auf separaten seiten aufzulisten, die man ihrerseits bei bedarf auf seine watchlist setzen kann. aber ich denke, das wird leicht unsauber und auf dauer evtl. unuebersichtlich. und wir sollten uns bei der bedienung nicht zu weit von der wikipedia entfernen, um es etwaigen interessierten autoren zu erleichtern, hier einzusteigen. -- seth 00:34, 21. Sep. 2012 (CEST)