Hilfe:Verbesserungsvorschläge/Vorschläge 2011

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Robot-Indexierung[Bearbeiten]

Ich erachte es als Fehler dass Seiten im Benutzer Namensraum indexiert werden. Ich plädiere aus mehreren Gründen dafür, dass diese Seiten nicht aufgenommen werden.

  • Auf Benutzer-Seiten finden wir Testseiten oder Seiten im Entwicklungsstadium. Neulinge über Suchmaschinen könnten diese konsultieren, obwohl es bessere Exemplare in der statischen Doku gibt.
  • Ich verstehe die Benutzerseiten als Seiten für die Wiki-Community. Nicht als Info-Brett für die weite Welt.
  • Benutzerseiten werden wenig beobachtet durch die Community, viel mehr wird toleriert. Benutzerseiten sollten aber nicht dazu dienen, dass SEO-Freaks ihr Ranking durch externe Links einfach so verbessern. Das würde nur zu Missbracuh des Wiki führen, welcher zu wenig beobachtet wird.

Seiten in anderen Namensräumen bieten natürlich auch diese Möglichkeit. Sie werden aber stärker beobachtet. --Beat 23:47, 3. Mai 2010 (CEST)

Kann man so und so sehen. Auch auf Benutzerseiten kann man Hilfreiches finden. Und warum soll die Wiki-Community nicht auch öffentlichkeitswirksam sein? Neulinge und Suchmaschinen finden auch anderswo Informationen, zu denen es (möglicherweise) bessere Alternativen gibt. Auch das Forumsarchiv hat viele solche Fundstellen – nicht immer steht eine qualitativ hochwertige Antwort dabei. Und nur weil es die Möglichkeit des Missbrauchs gibt, muss man nicht gleich von vorn herein auch alles Gutmütige unterbinden. Der Link (inklusive Ranking) kann auch als eine Art Dankeschön für das Mitarbeiten angesehen werden. Missbrauch kann auf Benutzerseiten genauso geahndet werden wie im Rest des Wikis. --dedlfix 19:41, 4. Mai 2010 (CEST)

Bugtracking-System[Bearbeiten]

Besser als eine Wikiseite fände ich ein Bugtracking-System. Am besten eines, das sich mit Mediawiki koppeln lässt. -- Woodfighter 20:20, 17. Mär. 2010 (CET)

Kennt dazu jemand eine brauchbare Mediawiki-Extension? --dedlfix 21:24, 29. Apr. 2010 (CEST)
falls das noch aktuell ist, IssueTracker ist da eine Möglichkeit --Oldperl 21:52, 24. Mai 2012 (CEST)
Danke für den Tipp. Momentan ist der Bedarf nicht wirklich da. Ich versuche es im Hinterkopf zu behalten. --dedlfix 22:12, 24. Mai 2012 (CEST)
gudn tach!
eigentlich gibt es ja bereits einen bugtracker in selfhtml, naemlich in trac: [1]. -- seth 22:53, 24. Mai 2012 (CEST)

Link-Label und alles, was daraus folgt[Bearbeiten]

Eine Seite hat als h1 überschrift einen Titel, der den Namensraum:Wiki/Pfad widergibt.
Bei Doku:Grundlagen/Webprojekte/planen sieht das nicht sehr leserlich aus. Wünschbar wäre, dass zu jeder Seite eine alternative Überschrift definiert werden kann, welche dann auch in anderen Vorlagen (siehe z.B. die next/prev Verlinkung Benutzer:Waldi/Vorlage/Navigation) verarbeitet werden könnte. Jetzt ist es so dass Doku:Grundlagen/Webprojekte/planen [[Doku:Grundlagen/Webprojekte/Webprojekte planen]] ja direkt unter der Überschrift die Location-Breadcrumbs aufführt. Es gibt also keine Notwendigkeit, dass die Location im Titel der Seite 1:1 auftaucht. --Beat 23:20, 7. Apr. 2010 (CEST)

Siehe dazu [2] und [3]. Dies wird jedoch ausdrücklich nicht empfohlen, da nur die h1-Überschrift geändert wird und Verweise, die statt des korrekten Titels die geänderte Überschrift referenzieren, dann ins Leere zeigen. Deshalb dürfte dieses Feature hier momentan deaktiviert sein und sollte es meines Erachtens auch bleiben. Zu Deinem Vorschlag, in Zukunft entweder den korrekten Titel oder die geänderte h1-Überschrift als Verweisziel anzugeben: Ich denke, es würde mehr Chaos verursachen, als es tatsächlich nützen würde.
Man könnte diskutieren, ob es sinnvoll ist, den nicht unmittelbar relevanten Teil der Überschrift auszugrauen oder auf eine andere Weise in den Hintergrund zu stellen. Also beispielsweise:
Doku:Grundlagen/Webprojekte/Webprojekte planen
Vielleicht reicht das ja schon?--Waldi 01:11, 8. Apr. 2010 (CEST)
Gggf gleich ausblenden, der Pfad steht ohnehin in der Adresszeile und direkt darunter sind die Breadcrumbs --Suit 11:50, 9. Apr. 2010 (CEST)
Habe jetzt diverse betroffene Seiten verschoben. Ich finde auch, dass man den Pfadanteil im Titel ganz ausblenden kann--Beat 13:08, 9. Apr. 2010 (CEST)
----
Eine Alternative wäre noch, die Breadcrumbs in den Titel zu übernehmen: Benutzer:Waldi/Basteln. Ich muss aber zugeben, dass es rein optisch keinen Blumentopf gewinnen kann. Daher halte ich die automatisierte(!) Ausblendung der nicht relevanten Teile durch eine Extension ebenfalls für die bessere Lösung. Man sollte dann jedoch die Breadcrumbs noch ein bisschen deutlicher herausstellen.--Waldi 12:52, 11. Apr. 2010 (CEST)
Ich gebe zu bedenken, dass man auch im eigentlichen Titel einen Schrägstrich (Slash) haben kann. Wie automatisiert man sowas? Oder muss man die automatische Version händisch überschreiben? -- Florian Edelmann (Flo2154) - 17:44, 11. Apr. 2010 (CEST)

Linkformatierung noch leerer Artikel[Bearbeiten]

Hallo Leute. Links auf nicht existente Artikel werden derzeit in irgendeinem Rot mit Unterstreichung (gepunktet) dargestellt. Das ist ziemlich verwirrend, denn diese dunkle Farbe und Hervorhebung durch Unterstreichung ist prägnanter als die orangenen Links auf existierende Artikel. In den Übersichten, wo noch viele tote Links existieren, kann das schnell verwirren. Also bitte macht noch die »toten« Links weniger prägnant! Vielleicht grau oder so etwas, oder nur dunkelrot ohne Unterstreichung. Jedenfalls sollten die normalen Links mehr Kontrast zum Hintergrund besitzen als die auf noch nicht existente Artikel. -- Molily 02:09, 23. Apr. 2010 (CEST)

Ich sehe da ganz andere Fragen. Sollten nicht existierende Seiten für User ohne Schreibrechte überhaupt verlinkt werden? Gut hier hat ja vorläufig jeder Schreibrechte, auch wenn Google davon kaum Gebrauch machen wird.
Ein Linkziel, das wissentlich keine Inhalte bietet, sollte auch für User mit Schreibrechten im Link selbst gewiss anders als nur durch eine Farbe kommentiert werden.
--Beat 11:57, 23. Apr. 2010 (CEST)
Es gibt eine Forumsdiskussion (my) zum Skin für die kommende Mediawiki-Version. Der derzeitige ist defekt und das wirkt sich auch auf die Linkgestaltung für nicht vorhandene Seiten aus. Unter Einstellungen→Verschiedenes→„Links auf nicht vorhandene Seiten hervorheben“ lässt sich eigentlich eine weniger starke Formatierung einstellen. Das wird mit dem neuen Skin (gleiches Aussehen aber neuer Unterbau) auch wieder funktionieren. Die Unterpunktung werde ich rausnehmen, weil mehr Gegenstimmen als Befürworter laut wurden. Die Farbe wird allerdings rot bleiben. Wer das nicht mag, kann das Häkchen in seinen Einstellungen entfernen. Und wem das noch nicht genügt, der kann ein benutzerdefiniertes CSS erstellen, und dort nicht nur die Linkfarben individuell anzupassen.
Die Frage was verlinkt wird und was nicht und bei welchem Anmeldezustand ist nicht mit dem Skin klärbar, sondern ist irgendwo in der MediaWiki-Software verankert. Da will ich keine Änderungen vornehmen, weil sonst die Updatefähigkeit leidet.
Ansonsten bitte ich um konkrete Vorschläge, welche Farbwerte es sein sollen. --dedlfix 10:53, 28. Apr. 2010 (CEST)
gudn tach!
mir waere es sowieso am liebsten, wenn wir das aktuelle skin komplett ersetzen wuerden. zum einen gibt es hin und wieder darstellungsfehler (lustigerweise z.b. bei der skin-auswahl). zum anderen ist der urheber jemand, der in der wikipedia schon mehrfach wegen link-spamming gesperrt wurde und dessen links auch schon auf die spamlist gewandert sind. dass jetzt auf jeder unserer doku-seiten ein link zu ihm unten erscheint, finde ich naja, eben nicht gut. unter anderem wettert er unsachlich in seinem blog gegen wikipedia-admins, die ihn sperrten. nicht die feine art und imho grund genug, ihn nicht zu hypen, zumal das skin wirklich nicht toll ist.
ich nutze jedenfalls aus macht der gewohnheit monobook. dort treten die genannten probleme nicht auf. -- seth 20:41, 28. Apr. 2010 (CEST)
Monobook hat ja auch einen ordentlichen Unterbau. Die Version 0.9.2 vom DaSch-Theme, die die Grundlage des jetzigen Skins bildet, bindet CSS-und JS-Ressourcen in der falschen Reihenfolge ein. Der Fehler ist in seiner aktuellen Version nicht mehr enthalten, aber die ist nicht mehr mit MediaWiki 1.15 kompatibel.
Ich hatte auch schon die Idee, das SELFHTML-9-Layout in einen Skin zu packen, aber das recht schnell wieder aufgegeben, weil beispielsweise Grafikelemente fehlen, die für die Funktionalität hier benötigt werden. Das 9er Layout ist also in der jetzigen Form nicht richtig MediaWiki-geeignet. --dedlfix 23:00, 28. Apr. 2010 (CEST)

schmale leerzeichen[Bearbeiten]

in einigen faellen, macht es sinn, ein schmales umbruchgeschuetztes leerzeichen zu setzen, z.b. zwischen zahlen und einheiten (5m, 6kg, ...) und innerhalb von abkuerzungen (z.b., i.a.r., ...)
mittel dafuer gibt es derzeit kaum gescheite, siehe [4].
in der wikipedia wird das thema schon seit jahren diskutiert, aber es geht dort leider nur sehr langsam voran. hier in unserem kleinen wiki koennten wir einer idee nachgehen, die das editieren diesbzgl. ein wenig erleichtern wuerde. siehe [5] und [6]. durch die automatisierung wuerde es genuegen, ein gewoehnliches leerzeichen zu schreiben und es von der software in ein schmales ubruchgeschuetztes leerzeichen umwandeln zu lassen. -- seth 21:53, 23. Apr. 2010 (CEST)

Wenn U+202F,   oder   verwendet wird, hat das zum Erfolg, dass in einigen Browsern dann Kästchen zu sehen sind, beispielsweise IE 8 unter Windows XP. Mit   passiert das nicht, bricht jedoch um, wenn es zufällig am Zeilenende landet. Da ist mir doch das Umbrechen das kleinere Übel. Vom Automatismus halte ich nicht viel, weil dann wieder eine Syntax benötigt wird, die ihn gezielt ausschaltet, wenn er mal tut aber nicht soll. --dedlfix 22:22, 23. Apr. 2010 (CEST)
gudn tach!
ja, U+202F,   und   sind ungeeignet. allerdings ist auch   nicht so gut, da der standard nicht vorsieht, dass dieses zeichen umbruchgeschuetzt ist. der schutz vorm umbruch ist aber gerade fuer den lesefluss das wichtigere; zumindest wichtiger als die genaue breite. deswegen halte ich da sogar zusammenschreibung fuer sinnvoller als die verwendung von thinsp. mit dem automatismus beim prozentzeichen ist man in der wikipedia bisher schon sehr gut gefahren (mir ist kein fall bekannt, wo es damit probleme gab). und automatismen muessen nicht jetzt fuer alle zeit eingestellt, sondern koennen ja jederzeit modifiziert werden, falls man den eindruck hat, dass sie einem mehr arbeit als nutzen bereiten. -- seth 11:02, 24. Apr. 2010 (CEST)
Vorlage:Einheit, die aus {{Einheit|5|kg}} folgenden Code macht <pre class="größe">5&thinsp;kg</pre>-- Matthias 20:36, 3. Aug. 2012 (CEST) --
gudn tach!
wie gesagt: "thinsp;" ist ein schlechter ansatz. ausserdem kann das zu copy&paste-fehlern fuehren und kann die suche erschweren. es gibt einen trick, der den wiki-source-code lesbar laesst, nur den generierten html-code etwas aufblaeht und sonst meines wissens keine grossen nachteile hat. habe ich oben bereits verlinkt. -- seth 22:18, 3. Aug. 2012 (CEST)
abgesehen davon, dass es wichtigeres gibt, sollte innerhalb von pre ohnehin nicht umgebrochen werden. der aufgeblähte wiki-code wäre natürlich nachteilig. ich bin auch nur zufällig über diesen beitrag gestolpert. -- Matthias 22:26, 3. Aug. 2012 (CEST) --
der wiki-code wuerde bei der vorgeschlagenen methode nicht aufgeblaeht, sondern nur das gerenderte html. aber hohe prioritaet hat das thema bestimmt nicht, das ist richtig. da zumal in der wikipedia gerade das thema mal wieder etwas aufgekommen ist, lohnt es sich vielleicht auch einfach, erstmal abzuwarten, ob sich demnaechst dort was ergibt. ich wuerde dann wieder hier bescheid geben. -- seth 23:59, 3. Aug. 2012 (CEST)
So ist das, wenn man sich nicht exakt genug ausdrückt: Bei meinem Vorschlag {{Einheit|5|kg}} wird sowohl wiki-code als auch html aufgebläht. -- Matthias 10:25, 4. Aug. 2012 (CEST) --

Eigenes Javascript Framework für Beispiele[Bearbeiten]

Wenn wir Beispiele schaffen, die Javascript verwenden, so stellt sich manchmal die Kompatibilitätsfrage. In einem Beispiel möchte man zum Beispiel nicht das Rad jedes mal neu erfinden. Das betrifft z.B. getElementsByClassName(). Deshalb stellt sich die Frage, ob wir gleich ein Framework als eigenes JS hochladen, damit wir es in Beispielen einbinden können. Ich stelle mal zur Debatte:

  • sizzle (kann alles notwendige)
  • jQuery (eh schon verbreitet)

Beat 15:58, 24. Jan. 2011 (CET)