Hilfe:Verbesserungsvorschläge/Umstellung auf die neue Struktur

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

weitere Namensräume abschaffen

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)

Weiterleitungsseiten von falsch angelegter CSS-Eigenschaftsreferenz (erledigt)

Es gibt einige Seiten, die offenbar falsch einsortiert wurden und die jetzt Weiterleitungen darstellen. Sie verweisen auf seiteninterne Anker von Doku:CSS/Eigenschaften/Textformatierung (für alle siehe Spezial:Linkliste/Doku:CSS/Eigenschaften/Textformatierung).

MMn sollten diese WL gelöscht werden, sie könnten aber auch auf die neuen Seiten verweisen. -- Matthias 21:26, 5. Jun. 2012 (CEST) --

Kann das dein Bot erledigen? Lösche alle Unterseiten von Doku:CSS/CSS-Eigenschaftenreferenz, die eine Weiterleitung sind. -- Matthias 18:15, 9. Jun. 2012 (CEST) --
Hat er gemacht. --dedlfix 00:31, 10. Jun. 2012 (CEST)

Doku:CSS/Eigenschaften/Textformatierung (erl. --> gelöscht)

soll mMn gelöscht werden, weil die einzig sinnvolle Weiterleitung die auf [CSS/Eigenschaften/Textformatierung] wäre und diese Seiten sich aber sehr stark voneinander unterscheiden. Allerdings wäre das vielleicht auch eine Seite, auf die sehr viele externe Links gesetzt wurden. Dies spräche für weiterleiten. -- Matthias 21:30, 5. Jun. 2012 (CEST) --

Doku:CSS/Eigenschaften/Textausrichtung (erl. --> gelöscht)

soll mMn gelöscht werden, Begründung s. Textformatierung, Bedenken siehe ebenda -- Matthias 13:45, 6. Jun. 2012 (CEST) --

Singular (erl.)

Was ist die Intention hinter dem Singular? Ich hatte darüber bisher nicht nachgedacht. Hier meine Vermutungen, was deine Überlegungen dahinter sein könnten: Für allgemeine erläuternde Texte zum Thema sollte der Singular verwendet werden (JavaScript/Variable beschreibt, was Variablen sind.) Für eine Aufzählung kann der Plural herhalten (JavaScript/Variablen listet alle Variablen auf (falls es vordefinierte Variablen in Javascript gibt)). Allerdings scheitert dieses Konzept gelegentlich an der deutschen Sprache, weil der Plural mitunter dem Singular entspricht (z.B. der Hersteller und die Hersteller), so dass man wohl eher eine Benennung wie „Liste der …“ oder „Lemma (Auflistung)“ ins Auge fassen sollte. --dedlfix 09:41, 8. Jun. 2012 (CEST)

In jedem Lexikon stehen die Lemmata im Singular. Deshalb Javascript/Variable (wobei bei der Pluralbildung das n nicht zwingend ist, vergl. wiktionary oder Duden) und Liste von Variablen, da es nicht gut wäre, wenn Variable und Variablen völlig unterschiedliche Seiten wären. Solche Aufzählungsseiten sollten aber in den Namensraum Referenzen: eingeordnet werden (der auch im Plural bleiben kann ;-)). -- Matthias 11:11, 8. Jun. 2012 (CEST) --
O.K., der Singular ist also einfach nur eine Vereinheitlichung der Schreibweise. Dass der NR Referenzen im Plural steht, stört mich eigentlich schon lange. Ich habe auch schon eine technische Lösung in der Tasche, die beide Schreibweisen zulässt. Das heißt, wenn ich den NR umbenenne und ggf. Seiten verschiebe(n lasse mit dem Bot), bleiben alte Verweise von außerhalb intakt. Da wir sowieso gerade an einem Wendepunkt sind, werde ich das mal in den nächsten Tagen angehen. Gleichzeitig werde ich die Namensräume Extras, Verein und Community schleifen. da steht sowieso nichts drin und SELFHTML hat zumindest für die letzten beiden Themen genug Platz. Ansonsten stimme ich dir zu, Aufzählungen gehören in die Referenz, und da das deren Hauptaufgabe ist, braucht es dort auch kein „Liste von“. --dedlfix 16:02, 8. Jun. 2012 (CEST)
Das ist gut. Ich bitte noch um deine Meinung zu den ersten Punkten dieser Seite. --Matthias 16:09, 8. Jun. 2012 (CEST)
Ich habe keine Einwände hervorzubringen. --dedlfix 17:58, 9. Jun. 2012 (CEST)

Sidebar (erl.)

Ich finde den Link auf die Dokumentation im Startmenü wichtig! Jetzt muss ich erst auf der Startseite nach unten scrollen um in Doku zu kommen. -- Matthias 17:16, 9. Jun. 2012 (CEST) --

so besser?
deutlich. Auf dieser Seite würde ich sogar auf h1 verzichten. mediawiki-faq (requires setting $wgRestrictDisplayTitle to false) -- Matthias 18:06, 9. Jun. 2012 (CEST) --
Das ganze Wiki ist eine Dokumentation (oder soll es werden) und nicht nur der eine Teil. Bei den Namensräumen und der Menüstruktur auf der linken Seite ist das letzte Wort noch nicht gesprochen. Eine Aufteilung nach Art der Artikel ist für den Leser nicht sinnvoll. Da sollten eher Links zu den wichtigsten fachlichen Einstiegsseiten zu finden sein. --dedlfix 17:48, 9. Jun. 2012 (CEST)
ja beispielsweise können Fachartikel und Themenschwerpunkte zusammengefasst werden und Kurse sollte Tutorials heißen. -- Matthias 18:06, 9. Jun. 2012 (CEST) --

Methoden im Seitentitel mit Klammern (erl. --> keine Klammern)

Ich bin der Meinung, dass die Klammern bei Methoden und Funktionen zur Unterscheidung von Eigenschaften wichtig sind und deshalb im Seitentitel erscheinen sollten. -- Matthias 14:12, 10. Jun. 2012 (CEST) --

Jein. Syntaktisch sind die Klammern in einigen Sprachen notwendig, in anderen aber auch optional. Mitunter werden sie zur Verdeutlichung, dass es eine Funktion ist, in Fließtexten geschrieben (mach ich ja auch). Zum Namen gehören sie aber nicht, nur zur Verwendung (oder auch nicht). Ich bin für das Weglassen im Seitentitel. Die korrekte Anwendung ergibt sich (hoffentlich) aus der Beschreibung und den Beispielen. Dass z.B. eine Klasse denselben Bezeichner für eine Funktion und gleichzeitig für eine Eigenschaft und/oder eine Unterklasse verwendet, ist zwar technisch mitunter möglich, aber in offiziellen Sprachen/Frameworks wohl eher selten bis nicht anzutreffen. Und auch wenn ich eine Funktion suche, gebe ich keine Klammern ein, Google zum Beispiel ignoriert die sowieso. (Ich nehme an, k(aum )einer macht das.) Wenn du die Klammernschreibweise auch bei Stichwortseitentiteln (ich hab mal die Begriffe Stichwortseiten und Artikelseiten zur Unterscheidung eingeführt) verwenden möchtest, bekommst du nur unnötig Verwechslungs- und Dopplungsprobleme mit Stichwörtern ohne Klammern. --dedlfix 15:38, 10. Jun. 2012 (CEST)
Methoden haben Namen und in der Klammer stehen die Parameter. Eine leere Klammer suggeriert zum einen ein Aufruf der Methode und zum anderen, dass die Methode keine Parameter hat. Aus "die slice()-Methode" sollte meiner Meinung nach besser "die slice-Methode" werden. Vergleiche dazu
--Hirnbrand 18:38, 10. Jun. 2012 (CEST)
Hmm, jetzt hast du dich doch zur Klammernsetzung im Titel hinreißen lassen, dabei stand es doch gerade 2:1 gegen sie und Matthias hat unseren Argumenten bisher nicht widersprochen. --dedlfix 21:22, 11. Jun. 2012 (CEST)
Vor allem Hirnbrands Argumente haben mich überzeugt (Aufruf, keine Argumente)
Es steht somit 2,75:0,25 gegen die Klammern
-- Matthias 21:33, 11. Jun. 2012 (CEST) --
Och ungeachtet meiner Meinung arbeite ich immer nach Vorgabe. Ich bin da flexibel. Und wenn's mit historisch und was auch immer begründet wird, dann ist es auch gut. Also wir müssen nicht gleich sofort eine Entscheidung treffen aber innerhalb dieser Woche sollten wir uns festlegen.
--Hirnbrand 21:52, 11. Jun. 2012 (CEST)
Ich denke, damit können wir es als entschieden ansehen: nur Namen in den Titel, Syntaxelemente vermeiden. --dedlfix 09:40, 12. Jun. 2012 (CEST)

Sortierung in den Kategorien (erl.)

Vorlage heißt Kategorie -- Matthias 13:07, 18. Jun. 2012 (CEST) --

Wenn man sich die Kategorien z.B. Kategorie:CSS so anschaut, fällt die unglückliche Sortierung ins Auge. Besser wäre eine Sortierung nach dem Eigenschaftsnamen. Dafür gibt es zwei Lösungsmöglichkeiten

1. Erstellen einer Vorlage {{Kategorie}} mit dem Inhalt [[Kategorie:{{{1}}}]]{{SORTIERUNG:{{SUBPAGENAMEE}}}} und das Ändern vom [[Kategorie:#name#]] in {{Kategorie|#name#}}

Vielleicht auch ein besserer Kategorienname, etwa {{sortkat}}

Das Erstellen der Dokumentation der Vorlage würde ich übernehmen

2. Einfügen von {{SORTIERUNG:{{SUBPAGENAMEE}}}} in alle Unterseiten von CSS

Ich halte gegenwärtig 1 für sinnvoller.

Beides macht [Referenz:CSS/Eigenschaftenreferenz_(alphabetisch)] überflüssig und das ist gut so, denn sie (die Referenz) braucht nicht gepflegt werden.

-- Matthias 21:05, 15. Jun. 2012 (CEST) --

Klingt sinnvoll, ich hab nichts dagegen. --dedlfix 22:49, 15. Jun. 2012 (CEST)
gudn tach!
warum so kompliziert? warum nicht einfach [[category:CSS|border-width]]? das funzt ohne extra template bereits von haus aus. -- seth 17:06, 25. Jun. 2012 (CEST)
weil ichs nicht wusste
weils jetzt weniger Schreibarbeit ist
weil die Möglichkeit des anderen Sortierschlüssels trotzdem besteht
Schade, dass du das nicht eher gelesen hast. -- Matthias 20:11, 25. Jun. 2012 (CEST) --

Vorschlag für den CSS-Bereich (erl.)

Ich habe auf CSS meine Vorstellungen von der Struktur dargestellt. Bitte auch in den Quelltext schauen, als Kommentar habe ich die Bezeichnungen für den physischen Ort der jeweiligen "Hauptkapitel" hinterlegt. Wenn nichts gegenteiliges bis heute abend kommt, fang ich so an. Die bisherige Unterteilung (z.B. Längenmaße) wird dann (in CSS/Wertetypen) einsortiert) -- Matthias 13:04, 18. Jun. 2012 (CEST) --

Blöder Absatz mit br drin (erl.)

Wer produziert auf der Startseite unter Rechtsfragen den blöden Absatz? -- Matthias 18:58, 18. Jun. 2012 (CEST) --

Das war ein }} am Ende von Grundlagen. Da muss nochmal grundlegend aufgeräumt werden, denn wenn man manchen Links von der Startseite aus folgt, bekommt man die für die Leser uninteressante Achtung-eingebunden-Box. So ein Hinweis muss eigentlich nur im Quelltext sichtbar sein. --dedlfix 22:05, 18. Jun. 2012 (CEST)
Danke. Die Box ist zu sehen, weil mehrfach eingebunden wird, was eventuell Sinn macht um Redundanzen zu vermeiden (die man mit Programmieraufwand erkauft). Die Box könnte oberhalb des Bearbeiten-Feldes angezeigt werden, im #editpage-copywarn, aber wie das geht, weiß ich nicht. -- Matthias 22:18, 18. Jun. 2012 (CEST) --

Quellenangaben (erl.)

Bin der Meinung, dass ich sowas hier im Wiki schon irgendwo gelesen oder gesehen habe. Würde gerne auf Seiten wie JavaScript-Array (Nur auf Hauptseite) auf MSDN, MSN oder Dokus anderer Browserhersteller verlinken. Gibts dazu schon eine Festlegung? --Hirnbrand 19:31, 18. Jun. 2012 (CEST)

Das geht mit einfachem Link ohne Erläuterungstext, wobei dann nur ein [1] erscheint, mit einfacher Nennung der URL ohne weitere Klammern http://example.com (zum Beispiel in einer ganz normalen Auflistung) oder als Fußnote. --dedlfix 22:05, 18. Jun. 2012 (CEST)

Ich denke, es geht nicht um die technische Umsetzung.

  • direkte Quellenangaben wie im Artikel @font-face
  • weblinks als zusätzliche Quellenangaben wie im Artikel Border-radius
  • mit beidem (im Gegensatz zur Wikipedia) sparsam umgehen

so lautet der Vorschlag einer Festlegung -- Matthias 22:29, 18. Jun. 2012 (CEST) --

Also Quellen, bei Nennung oder Referenzierung im Text und Weblinks als lose Sammlung finde ich gut. Genau das habe ich gesucht. --Hirnbrand 18:35, 19. Jun. 2012 (CEST)

Vorlage:Achtung-eingebunden

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)
Ich habe diese Vorlage heute gelöscht. --Matthias Scharwies (Diskussion) 14:39, 24. Dez. 2021 (CET)

"Einzelseiten statt Monsterseiten"

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

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

im kontext von [2] 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: [3].
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

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)
Abgerufen von „http://wiki.selfhtml.org/index.php?title=Hilfe:Verbesserungsvorschläge/Umstellung_auf_die_neue_Struktur&oldid=85617“