SELFHTML Diskussion:Wiki/Umstellung auf die neue Struktur/Archiv/1

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 „1“ 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

Hier finden Sie abgeschlossene Diskussionen zur Umstellung auf die neue Struktur aus dem Juni 2012.


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)