Das Kefk Network Wiki befindet sich im Testbetrieb.

Wikipedia:Verbesserungsvorschläge/Feature-Requests

Aus Kefk.

Wechseln zu: Navigation, Suche

Abkürzung: WP:FR !!! Bitte zuerst lesen, da nicht alle Verbesserungswünsche hierher gehören !!!

Auf dieser Seite sollen Feature-Requests gesammelt werden, also Vorschläge, Wünsche oder Forderungen, der Software neue Funktionen hinzuzufügen bzw. eine vorhandene Funktionalität zu ändern. Wenn sie sich durchsetzten, werden sie an die Entwickler weitergeleitet. Durch die so erreichte Zustimmung haben sinnvolle Änderungen eine größere Chance.

  • Um allgemeine, nicht softwareabhängige Verbesserungsvorschläge zu machen, nutze bitte Wikipedia:Verbesserungsvorschläge.
  • Um Softwarefehler (Bugfix) zu melden, nutze bitte Hilfe:MediaZilla.
  • Um einen Vorschlag tatsächlich an die Programmierer weiterzugeben, wird jedoch MediaZilla verwendet, wo solche Vorschläge verwaltet werden. Wer des Englischen nicht mächtig ist, wende sich bitte – auf deren Benutzerdiskussionsseite – an folgende Leute (bitte eintragen, wer Lust hat, sich um Bug-Reports und Feature-Requests zu kümmern): Elian Φ, :Bdk: (tatsächliche fehler/bugs)

Bitte gebt auf dieser Seite mit drei Tilden (nein, nicht vier Bild:Smile.png) unter »dafür« oder »dagegen« eure Stimme ab, welche Feature requests an die Entwickler weitergeleitet werden sollen.


Neuen Abschnitt hinzufügen
Beiträge bitte mit -- ~~~~ unterschreiben.

Inhaltsverzeichnis

Erledigtes/Archiviertes 11. April 2005

zur Umsetzung weitergeleitet oder bereits umgesetzt

abgelehnt

  • Hervorhebung des beschriebenen Begriffs im Text: div. contra-stimmen
  • Alphabetischer Index in Oberfläche aufnehmen: div. contra-stimmen
  • Funktion Artikel ignorieren: viele contras
  • Weiterleitung zur zuletzt benutzte Seite abstellen: div. contras
  • REDIRECT auf Überschriften: von den Entwicklern als nicht sinnvoll ungefähr schon hundertmal abgelehnt

 ?

Wenn jemand weiß (nicht nur vermutet), was mit folgenden Vorschlägen passiert ist, dann bitte auch einsortieren und mit einem Link zum weiteren Verlauf versehen, danke. FWHS 14:02, 22. Aug 2005 (CEST)

  • Alternatives Menü für den Bearbeitungsmodus: kein Mediawiki Feature request, sondern eine Sache der Konfiguration
  • Skin Nostalgie: Suchformular oben: 2:1
  • Case-insensitive Suchfunktion: Jaaaaaaaa (mal sehen, was mit Lucene-Search kommt, siehe meta:Fulltext search engines)
  • Warnung wenn ein Artikel bereits bearbeitet wird: viele Pros, aber wahrscheinlich nicht sinnvoll realisierbar

Softwareänderung nötig

Formelerklärungen in Standardsprache

Auf den Seiten, die mathematische oder physikalische Dinge erklären, gibt es viele komplexe mathematische Formeln. Nur um diese zu verstehen muss man (fast) schon studieren. Wäre es da nicht toll, wenn beim bewegen des Mauszeigers über so eine Formel das ganze kurz in einfachen Worten erklärt wird? Am besten so, dass die Software das automatisch umwandeln kann. --84.56.177.19 09:37, 7. Okt 2006 (CEST)

Eine von Seiten der Software generierte Kurzerklärung halte ich für technisch unmöglich, schon allein wegen der Mehrfachbelegungen einzelner Formelzeichen (siehe z. B. D (Begriffsklärung)). Lieber sollten die, die Ahnung von den Formeln haben, in althergebrachter Weise dazu angehalten werden, selbst eine verständliche Erklärung dazuzuschreiben. --CyRoXX (? ±) 17:56, 2. Jan. 2007 (CET)

Links auf Stubseiten

Ich fände es gut, wenn Links auf Stubs oder sehr kurzen Artikeln (keine Begriffserkläungsseiten etc.) durch eine gesonderte Farbe z.B. orange kenntlich gemacht werden könnte. Das würde nämlich die Argumente gegen Stubs außer Kraft setzen. Technisch sollte sich das relativ einfach realisieren lassen. -- Netzize 05:23, 15. Aug 2005 (CEST)

Gute Idee. Aber nur für angemeldete Benutzer und nur wenn sie dieses Feature haben wollen. Man sollte es also auch jederzeit abstellen können. --Träumer 11:17, 15. Aug 2005 (CEST)
Wieso nur für angemeldete Benutzer? -- Netzize 02:29, 16. Aug 2005 (CEST)

Präzisierung des Feature Requests:

Weil nicht jeder Benutzer der Wikipedia auch ein Schreiber ist. Der fühlt sich doch durch solche Links eher gestört (meine Meinung) --141.53.194.251 10:44, 31. Aug 2005 (CEST)

Es ist, wie ich nun erfahren habe, wohl möglich durch entsprechende Einstellungen in der Benutzerseite und Verwendung eines entsprechenden CSS-Syle Links auf kurze Seite in anderer Farbe erscheinen zu lassen. Allerdings werden dadurch nicht alle Links auf Stubs erfasst, der Stubbaustein wird also nicht erkannt. -- Netzize 05:13, 16. Aug 2005 (CEST)

beim Firefox sehe ich Links auf eine Seite unter einer bestimmten Zeichenanzahl in einer rötlichen Farbe (anders als unverlinkt.) habe aber keine speziellen Einstellungen getroffen. Es ist ganz praktisch, weil man auch sieht, ob der Link auf eine Bgkl geht. --K@rl 09:14, 17. Aug 2005 (CEST)
Kürze allein ist nicht immer ein wichtiges Merkmal. Es gibt sicherlich gültige Lemmata, die mit drei Sätzen erschöpfend behandelt werden können. Aber die Kennzeichnung von Stubs würde mir gefallen und sicherlich auch vielen anderen bei der Arbeit in der Wikipedia helfen. Ich persönlich würde allerdings die Farbe grün (=noch im Wachstum befindlich) bevorzugen. :-) Diese Kennzeichnung sollte nur bei angemeldeten Benutzer wirken und von diesen einstellbar sein. --Birger (Diskussion) 17:39, 26. Aug 2005 (CEST)

Vielleicht ein Vorschlag: Das mit der Linkfarbe halte ich auch für nicht so sinnvoll, ich könnte mit aber vorstellen, dass hinter dem Link auf einen Stub ein Icon kommt (ähnlich wie bei den externen Links), das dann z.B. über den Tooltip des Browsers noch einen kleinen Hinweis gibt (im HTML-Tag des Icons z.B. mit <img src="stubicon.gif" alt="Platzhalterartikel">). --Merkosh O=O 15:19, 20. Sep 2005 (CEST)

{{Rot|Farandole}} erzeugt Vorlage:Rot: Ich habe vor kurzem – ohne von dieser Diskussion gewusst zu haben – die Vorlagen Vorlage:Rot und Vorlage:Rot2 für das Portal:Tanz erstellt, die auf primitive Art und Weise genau diese Aufgabe erfüllen: {{Rot|Aattetur}} erzeugt den markierten Link Vorlage:Rot, der auf einen Stub oder mangelhaften Artikel zeigt. In Farbgebung und Syntax habe ich mich so nah wie möglich an die bisherigen Links gehalten, so dass selbst Neulinge ohne zusätzlichen Lernaufwand ein intuitives Verständnis für die Bedeutung und Verwendung entwickeln. Der entstehende Effekt ist enorm und auf der [[Diskussion Vorlage:Rot|Diskussionsseite}} haben sich bereits einige Pro-Stimmen für diese Art der Markierung gemeldet. Der große Nachteil bei der Realisierung als Vorlage ist: Ist der Artikel überarbeitet, müssen alle Links auf ihn von Hand geändert werden - das ist ein gigantischer Verwaltungsaufwand, der nur bei sehr selten referenzierten Artikeln von Hand zu bewältigen ist. Genau deshalb ist die „Möglichkeit individueller Anpassung mit duzenden Farben für zig Linktypen“ (Zitat), keineswegs „völlig ausreichend“, wie das einige Contra-Stimmer sehen; die Wahl der Farbe für die Markierung müsste als Software-Feature automatisiert werden. Ob weiterhin Stub-Bausteine verwendet werden sollen, wird derzeit heftig diskutiert – diese Art der Markierung könnte Stub-Bausteine überflüssig machen. --Thetawave 11:05, 10. Dez 2005 (CET)

Widerspricht dem gesamten MediaWiki-Linkkonzept (einfach, konsequent logisch) und stellt dieses auf den Kopf. Keine Unterstützung von Entwicklerseite. --:Bdk: 01:15, 12. Dez 2005 (CET)
Da es auch sehr kurze Artikel gibt, die vollständig sind, halte ich die Länge des Artikels als alleiniges Kriterium für unzureichend, sofern man nicht gute Artikel gezielt mit Kommentarzeilen (werden diese mitgezählt?) über die Längenschwelle hebt. Dies gilt zumindest für den allgemeinen Benutzer und sofern die Linkfarbe eine Verwandschaft zu den roten Links nahelegt. Schon für gute Stubs würde ich einen rot-ähnlichen Link ablehnen.-- StefanL 15:28, 10. Dez 2005 (CET)
Weiterhin gibt es natürlich auch schlechte Artikel, die die Längenschwelle überschreiten und eine rot-ähnliche Linkkennzeichnung verdient haben. Man sollte einen neuen Namensraum Entwurf anlegen, in den schlechte Artikel einfach verschoben werden. Damit könnte man sich viele Löschdiskussionen sparen. Bei Links könnten dann z.B. folgenden Farben verwendet werden:
  • rot: Artikel ist weder im Artikel- noch im Entwurfsnamensraum vorhanden.
  • orange: Artikel ist nur im Entwurfsnamensraum vorhanden. Link wird automatisch dorthin weitergeleitet.
  • blau: Artikel ist im Artikelnamensraum vorhanden.
  • grün (optional): Wie blau, aber Artikel mit geringem Umfang. Längenschwelle sollte aber deutlich oberhalb des Stubniveaus liegen. Die Unterscheidung grün/blau würde es dann dem Benutzer ermöglichen, schnell zu erkennen, welche Artikel umfangreiche Informationen enthalten. Die Kennzeichnung grün wäre dabei uch nicht als Kennzeichnung mangelhafter Artikel anzusehen.-- StefanL 15:28, 10. Dez 2005 (CET)
Es gibt keinen Entwurfsnamensraum, dafür bitte gesonderte feature request starten, bitte nicht verschiedene Anfragen durchmischen. --:Bdk: 01:15, 12. Dez 2005 (CET)
Halte ich persönlich für zu kompliziert: Zu viele Farben, das stiftet bloß Verwirrung und erzeugt einen furchtbar unprofessionellen optischen Eindruck. Wenn schon verschiedene Farben, dann würde ich einen fließenden Übergang zwischen Rot und Blau verwenden. Aber mal was anderes: Warum das Ganze nicht über die Benutzereinstellungen optional machen und jeden Nutzer selbst entscheiden lassen, ob er (a) zu kurze, (b) schlechte, (c) lesenswerte oder (d) exzellente Artikel – oder beliebige Kombinationen davon – speziell hervorgehoben haben möchte? Immerhin existiert das für kurze Seiten bereits und wem es nicht gefällt, der kann die Funktion deaktiviert lassen. --Thetawave 00:51, 12. Dez 2005 (CET)
Es wird für nicht mal 1.000 exzellente und ein paar andere Artikel keine neue Softwarefunktion geben. Abfragen nach jeweils aktuellem Baustein-/Vorlagengehalt sind sehr aufwändig zu realisieren. Und kurze Artikel, mithin nach der herkömmlichen Definition Stubs, sind bereits "über die Benutzereinstellungen optional" markierbar (wie oft muss man das noch schreiben?). --:Bdk: 01:15, 12. Dez 2005 (CET)
  • Dafür: Träumer, Netzize, Daniel, Birger (Diskussion), Merkosh, FWHS (Die Erkennung von Bausteinen des verlinkten Artikels am Link sollte möglich sein.), Prolineserver, Thetawave Begründung siehe oben.
  • Dagegen: :Bdk: (Begründung), Frank Schulenburg (schließe mich Bdk an: die momentane Funktionalität reicht aus), Schlurcher ??? , Löschfix, Es gibt nur eine Methode, wie mit unvollkommenen Artikeln umgegangen werden muss, - sie verbessern. Und das gilt eigentlich für alle Artikel, - immer. Sie dem Namensraum zu entziehen, ist da eher kontraproduktiv. Auch Stubs erfüllen einen Mindestzweck für den Nur-User. In dem man ihn bunt macht, wird er nicht besser. Ein schwacher Artikel der sich lange nicht verbessert, wird vermutlich nicht sehr gebraucht. (Was ihn deswegen aber nicht disqualifiziert.)--Löschfix 04:19, 24. Aug 2006 (CEST) 
Über  Special:Preferences/Verschiedenes realisierbar/kein Stubbaustein mehr da :) --Flominator 16:08, 7. Jan. 2007 (CET)

Kleinere Bilder auch kleiner

Vor allem bei PNGs passiert es immer wieder, dass man sich vor dem Hochladen bemüht hat, durch Farbreduktion auch die Dateigröße zu reduzieren. Es wäre positiv, wenn diese Einstellungen auch beim Verkleinern der Bilder durch MediaWiki erhalten bleiben, weil ansonsten solche Dinge passieren, dass bei (komprimierten) PNG-Grafiken (Beispiel: Bild:Flagge Baden Wuerttemberg.png, rund 7kB) das Original kleiner ist als das (über MediaWiki) verkleinerte Bild (hier auf Baden-Württemberg, ca. 30kB). --hedavid 16:47, 20. Apr 2004 (CEST)

das bild auf Baden-Württemberg wurde aus inhaltlichen gründen ausgetauscht, das problem ist auf einer alten version zu sehen. -- plasmagunman 13:29, 31. Aug 2004 (CEST)
Ich denke das hat gute Gründe, vermutlich würden viele Grafiken dann in der Verkleinerung hässlich aussehen, weil es keine Mischfarben gibt und sich daher Harte Kanten ergeben. --Stefan-Xp 11:18, 31. Aug 2005 (CEST)
Richtig, eine qualitativ bessere Bildskalierung (durch Interpolation) halte ich für wichtiger als ein paar KB mehr oder weniger bei der Übertragung. -- Memset 12:01, 2. Aug 2006 (CEST)

Wenn die Software auf die Vorschaubilder pngrewrite und OptiPNG anwenden würde, könnte man da noch einiges (ca. 1/3) an Größe einsparen. --Phrood 01:06, 7. Aug 2006 (CEST)

Besucher Reviews

Ich kam gerade auf die Idee, dass viele Leute die Wikipedia nur "besuchen" und leider nicht teilhaben und mitschreiben wollen. Diese Menschen könnten doch auch eine Art Review über den Artikel geben (geholfen, gefallen, nicht geholfen, nicht gefunden? ...). Ich gebe zu dass auch hier ein großes Missbrauchspotenzial aufgemacht werden würde, aber ein Feedback von den "Kunden" fände ich nicht schlecht. --Telcontar 02:22, 21. Feb 2005 (CET)

Geholfen und gefallen wären zwar nett, sind aber nicht weiter hilfreich. Was wirklich helfen würde wäre korrekt oder fehlerhaft. Ein fehlerhaft ohne Angabe der Fehler bringt uns aber auch nicht weiter. Siehe Benutzer:Mijobe/Geprüfte_Versionen -- mijobe 20:19, 7. Mai 2005 (CEST)
das wäre tatsächlich eine überlegung wert, das mit der bewertung mit „korrekt“ und „fehlerhaft“. mfg --joni Δ 21:07, 29. Jun 2005 (CEST)
Dann lieber einen Verweis auf existierende Diskussionsseiten, wo man Derartiges hinterlassen kann. --Flominator 17:39, 11. Jul 2005 (CEST)
Einem Fisch das Tauchen beibringen? Wer sich beteiligen will kann das bei Wikipedia ganz leicht: editieren oder Diskussionsseite. Wer sich nicht beteiligen will, kann auch nicht helfen. Ein Klick hilft nicht wirklich. -- Diwas 15:50, 24. Mär. 2007 (CET)

Zeile xyz

Bei langen Seiten ist es oft schwierig den letzten Eintrag zu finden obschon die Zeile dabei steht. z.B. Zeile 776. Könnte man an die Bearbeiten- Buttons rechts eine Zeilenzahl mit einflechten?--82.82.235.136 14:15, 10. Jun 2005 (CEST)

Im KLassic-Skin mit 'Einstellungen'->Verschiedenes->Inhaltsverzeichnis nummerieren..
werden die Überschriften nummeriert - das ist eine Vereinfachung-trotzdem wäre es schön wenn die Zeilenanzahl angezeigt würde.--Kino 12:56, 13. Jan 2006 (CET)

dafür: Guter Vorschlag.--G 14:53, 10. Jun 2005 (CEST)

Finde ich auch: guter Vorschlag --Pelz 18:24, 10. Jun 2005 (CEST)
Die Zeilenzahl ist doch bei jeder Browsergröße unterschiedlich. Man könnte höchstens die nächstliegende Überschriften mit einblenden. -- sk 21:06, 10. Jun 2005 (CEST)
Es geht ja mehr um die Zeilenumbrüche, die absolut im Quelltext vorhanden sind, als um die, die der Browser anzeigt. Von daher könnte das schon sinnvoll sein, um sich zu orientieren, aber wie genau das funktionieren soll, kann ich mir nicht so recht vorstellen. --BLueFiSH ?! 21:23, 10. Jun 2005 (CEST)
Wenn man sich den Versionsunterschied anzeigen lässt werden auch die Zeilenzahlen angezeigt, es müsste also, wenn auch mit Aufwand, möglich sein.--G 22:02, 10. Jun 2005 (CEST)

(von Verbesserungsvorschläge hierher kopiert 82.82...)

dafür. --joni Δ 20:29, 29. Jun 2005 (CEST)
dafür, das ließe sich vll auch mit Kapitelnummern und -Überschriften verbinden. -FWHS 12:52, 1. Aug 2005 (CEST)
dafür, hab's mir nicht genau durchgelesen, klingt aber interessant. Wikipeditor

Ich nehm das Theme mal wieder auf: Ich bin auch dafür die Zeilennummer mit anzuzeigen. Bei Versionsunterschieden steht ja auch die Zeilennummer dabei, ist aber bei einer größeren Zeilennummer aber bisher kaum nachzuvollziehen. Ich hatte diese auch schon mal angeregt, ist aber nicht viel nach gekommen. Vielleicht klappt es ja diesmal. -- Petflo2000 17:29, 7. Feb 2006 (CET)

Zeilennummern aber bitte nur beim Versionsvergleich und nicht bei normalen Edits, sonst sieht das aus aus als müßte man hier programmieren statt schreiben. Und das schreckt ab. Kolossos 21:04, 7. Feb 2006 (CET)

so wars gedacht, die Zeilen die in der Versionsgeschichte angezeigt werden,z.B. Zeile-1244, möchte ich beim scrollen wiederfinden können; das kommt oft vor bei den LAs, Diskussionen, hier und sonst wo --Kino 23:41, 7. Feb 2006 (CET)
Andererseits könnt man ganz oben bei den Unterschieden auch die nächsthöhere Überschrift neben der Zeilennummer auflisten, dass klingt dann nicht so mathematisch. Kolossos 21:42, 20. Feb 2006 (CET)
Alternativ-Vorschlag: Die vorhandene Zeilenangabe im Versionsvergleich wird als Link ausgestaltet, der genau an die entsprechende Stelle im darunter angezeigten Text springt. --Ce 00:14, 11. Mär 2006 (CET)
@Ce, das wäre optimal,--Kino 17:44, 11. Mär 2006 (CET)
Prozu Ces Vorschlag--Hannes2 Diskussion  14:42, 23. Aug 2006 (CEST)
Falls eingestellt ist, nur die Änderungen anzuzeigen, sollte der Link dann den Text anzeigen und an die Stelle springen. --Diwas 04:48, 18. Feb. 2007 (CET)

Vorschlag zur Reduzierung des Speicherverbrauchs

teilweise werden artikel vom selben benutzer mehrmals geändert, weil dieser die vorschau nicht benutzt. da wär es doch sinnvoll wenn die software diese ganzen änderungen (vom selben benutzer ) zu einer zusammenfasst, damit nicht jede änderung extra gespeichert werden muss. dazu sollte man vielleicht ein zeitlimit einbauen, d.h. alle änderungen des benutzers innerhalb von 6 stunden werden wieder extra gespeichert. damit werden sukzessive änderungen zusammengefasst, falls der benutzer den artikel aber mehrmals komplett ändert, sind die änderungen trotzdem noch nachvollziehbar. und der vandalismus schutz ist trotzdem noch gegeben, da sich kein benutzer seinen eigenen artikel vernichten wird. alternativ zu dem zeitlimit wäre noch möglich, dass anschliessende "kleine änderungen" des benutzers, zusammengefasst werden. Darrn 18:23, 16. Jun 2005 (CEST)

das ist, finde ich, ein gradioser einfall, für den ich bin. über das zeitlimit müsste man sich nur noch unterhalten; sechs stunden finde ich ein bisschen zu lang. mfg --joni Δ 20:23, 29. Jun 2005 (CEST)
das finde ich auch klasse. Wäre ein Bild im Artikel hätte ich dir jetzt einen Wikipedia-Nobelpreis dafür verliehen! Aber: eine Stunde reicht m.E. --Flominator 17:48, 11. Jul 2005 (CEST)
Gute Idee. Aber geringeres Zeitlimit (1h?). Vielleicht könnte man die Bearbeitungsseite auch so gestalten, dass der Speichernbutton überhaupt erst nach der ersten Vorschau aktiv wird? --the one who was addicted (#) 18:22, 11. Aug 2005 (CEST)
Dann wird man aber mehr den "Seite speichern"-Button benutzen; die Benutzung des "Vorschau-zeigen" Buttons wird zurückgehen. Dadurch wird der Server noch mehr strapaziert. Zweitens: Ein paar Änderungen aus dem Speicher zu nehmen reduziert ihn zwar, aber ein Link auf diese Änderung funktion dann nicht mehr. Ich halte das letzte Argument für eher unwichtig. Um das erste Argument auch zu entkräften habe ich einen Kompromißvorschlag: Statt die Änderungen sofort zusammenzufassen geschieht das erst nach mindestens 24h. Der Wikipediaserver kann das dann auch in einer "ruhigen Stunde" tun und nicht wenn er eh gerade überlastet ist. --Träumer 13:16, 15. Aug 2005 (CEST)
Mir ist eben ein noch zu bedenkender Punkt ein-/aufgefallen: Was soll mit den Änderungskommentaren passieren, wenn zb. ein Editor Änderungen in fünf Abschnitten eines Artikels jeweils vorbildlich mit Zusammenfassung vornimmt? Denn ein einfaches Zusammenhängen der Kommentare wird aufgrund der Platzbeschränkung (?) im Feld Zusammenfassung und Quellen: vermutlich nicht (immer) funktionieren. --the one who was addicted (#) 16:55, 16. Aug 2005 (CEST)
Ich wäre dafür, nur den letzten Änderungskommentar zu speichern und den Schreiber dabei eventuell auf diesen Umstand hinzuweisen. -- Royd 20:44, 26. Aug 2005 (CEST)
Die beste Möglichkeit wäre vielleicht, dass der Server nur jede x-te Version vollkommen abspeichert (immer die aktuelle) und ansonsten nur die Änderungen speichert. Ich vermute aber, dass eine Umstellung nicht möglich ist, außerdem weiß ich nicht, wo der Flaschenhals ist, wenn das der Prozessor ist wird es noch langsamer.--G 00:08, 29. Sep 2005 (CEST)
Es gibt Sachen, die KANN man einfach nicht per Vorschau testen. Von meiner Seite Benutzer:Plenz/monobook.js gibt es inzwischen ca. 80 Versionen. Ich wünschte, ich könnte 79 davon einfach löschen. --Plenz 08:53, 15. Jan 2006 (CET)
Bild:Symbol support vote.svg Pro In der Hoffnung, dass es technisch machbar ist. Wenn es die Software nicht aut. macht dann wenigstens die Möglichkeit dies selber zu tun (innerhalb 1h). Was wäre wenn jemand seinen Edit revertiert? Ich bin mir auch nicht sicher, ob dies zu einer Sichheitslücke führen könnte. -- Ολλίμίνατορέ •Ω• 14:49, 7. Apr 2006 (CEST)

Vorschlag: Mir ist auch immer nicht ganz wohl, bei dem Gedanken wieder mal eine Version mit marginalem Input geschaffen zu haben. Wie wäre es, wenn man Bearbeitungen, bei denen nur hinzugefügt wird einfach statt der alten speichert, und nur bei Löschungen auch die Alte? 141.58.115.197Stefahn (mach ich was falsch mit der Sign?)

Jetzt produziere ich also wieder Speicherverbrauch, nur um mitzuteilen, dass mir schon auf einigen Seiten der Button Veränderungen sind nur kleine Korrekturen positiv aufgefallen ist, hier bei Pedia allerdings leider noch nicht begegnete. S

Ich bin mit Einschränkung dafür, Abschnittsweise Änderung bitte getrennt lassen.--Löschfix 16:56, 15. Sep 2005 (CEST)

Man könnte die Änderngen von einem einzelnen Benutzern über Javascript zusammenfassen und dann nach Bedarf ausklappeen. Wenns eingeklapt ist steht da 6 Bearbeitungen beispielsweise. -- M@rkus 00:06, 14. Jan 2006 (CET)

Das hat wohl eher keinen technischen Nutzen, und wäre vieleicht per JS-Unterseite zu realisieren. -- Ολλίμίνατορέ •Ω• 15:38, 7. Apr 2006 (CEST)

Wäre ein Anfang.
- Wie wäre es, da die Beschriftung in Zusammfassung ja offenbar ein Problem darstellt, wenn nur solche Edits zusammengefasst werden, die man als solche kennzeichnet, also der User hat es selbst in der Hand. Z.B. ein mit "typo" gekennzeichneter edit kann ohne weiteres dem vorhergehenden Edit hinzugefügt werden, ohne ein extra Zusammenfassung zu benötigen. Natürlich könnte man dazu einen knopf/shortcut oder ein Codewort erfinden.--Löschfix 02:27, 24. Aug 2006 (CEST)

Das halte ich für einen guten Vorschlag, denn oft will man grad nur einen Tippfehler ausbessern und aus - und dann ergeben sich doch noch einige tippos. Oder auch Tippos bei verschiedenen Absätzen, da hilft eine Vorschau gar nichts. Das würde nicht nur Speicherplatz sparen, sondern allein die Versionsübersichten wesentlich übersichtlicher machen. Die Zeitspanne 1 Stunde wäre meiner Meinung voll ausreichend, wenn nicht auch noch zu lang. --K@rl 22:46, 22. Jan. 2007 (CET)
Serverentlastung-Vorschau-Clientseitig

Verbundenes Problem. Der Server ist wegen Überlastug eine Katastrophe. Ich hab eine sehr schnelle Verbindung und einen mittelschnellen Rechner, dennoch ist es katastrophal wie lange man oft auf den Request warten muß, dann noch der eigene Rechner die Daten verarbeiten muß. Deshalb große bitte an die Entwickler, aber schwer zu machen denke ich: Muß denn für die Vorschaufunktion der Server involviert werden? Kann denn die Vorschau-emulation nicht vollständig offline, d.h. im Browser-Cache erfolgen? Javascript oder ähnliches? Klar, das geht wahrscheinlich nicht allein via html. Dazu müßte man vermutlich ein Programm schreiben. Aber das wäre der Segen. Denn so bringt mir persönlich die Vorschau überhaupt keinen Gewinn, und entllastet auch nicht den Server, sie ist nur zur Reduzierung der Versionsgeschichte da. Und WPro ist ja leider auch nicht in der Lage die Vorschau zu emulieren. Sehr schlecht.--Löschfix 16:56, 15. Sep 2005 (CEST)

Ich denke, dass es nicht möglich ist, die Vorschau durch einen Client erstellen zu lassen. Dieser Client müsste dafür den gesamten vorliegenden Text des Artikels parsen. Es gibt natürlich etliche einfache Sachen wie die Link-Umwandlung. Aber was ist zum Beispiel mit den ganzen Funktionen zur Darstellung mathematischer Rechnungen? Ich weiß nicht, ob Java-Script das umsetzen könnte (ich bin JS-Laie...), aber selbst wenn Java-Script das könnte, müssten die ganzen Anweisungen, wie das gemacht werden müsste, an den Client übertragen werden. Damit würden wir zwar jede Vorschau sparen (und bei kurzen Abschnitten hat der Server da wirklich so gut wie nichts zu tun), allerdings müsste beim Aufruf der Bearbeitungsseite der ganze Code übertragen werden, der nötig ist, um den Wiki-Code in XHTML umzuwandeln. Und ich denke, dass die Server damit nicht gerade unterfordert wären. (Die Modem- und ISDN-Nutzer würden sich wahrscheinlich auch bei dir bedanken.) Ohhja, jetzt habt ihr beim Lesen wahrscheinlich den Aspekt, ob Java-Script das alles kann, schon wieder vergessen ;-) Schreib eben zu viel... --MaKoLine 00:29, 8. Jan 2006 (CET)
Außerdem kann die korrekte Darstellung von Bausteinen sowie von Links auf vorhandene und nicht vorhandene Artikel nicht lokal bewerkstelligt werden. --Plenz 08:53, 15. Jan 2006 (CET)
Bild:Symbol support vote.svg Pro Ich würde sagen; das ist ein völlig eigenständiges Problem/ Vorschlag. Ich würde auch sagen das es technisch machbar ist. -- Ολλίμίνατορέ •Ω• 15:38, 7. Apr 2006 (CEST)
ACK - Eigenes Problem. Dass die Lösung nicht trivial ist und möglicherweise mit JS nicht zu bewerkstelligen, ahnte ich ja schon vorher. Nur, clientseitige Emulation, evtl. eingeschrängt sollte eine Überlegung wert sein. Vielleicht gibt es ja einen Weg.--Löschfix 02:27, 24. Aug 2006 (CEST)
Nächstes Problem der Serverentlastung

Bei Großen Diskussionsseiten. Klickt man auf das Inhaltsverzeichnis, dann springt die Seite nicht etwa zu der Stelle im Text via javascript oder html, sondern die Seite wird neu geladen und dann gesprungen. Was die Sache manchmal ewig verlängert und den Server belastet. Hängt das mit Cacheon chachoff zusammen oder ist das ein Programmierfehler? Das Zurückspringen von der bearbeitungsseite direkt an die Textstelle geht auch häufig schief, wenn die Seite groß ist.--Löschfix 19:11, 15. Sep 2005 (CEST)

Das sollte eigentlich nicht auftreten. Du meinst doch, dass dein Browser beim Springen innerhalb einer Seite, die er bereits vollständig aufgebaut hat, diese vollkommen neu lädt? Die Verweise in den Inhaltsverzeichnissen werden durch sogenannte Anker erzeugt. Damit kann man innerhalb eines Dokumentes navigieren. Ich hab das Verhalten gerade an dieser Seite (die ja nicht gerade klein ist) mit dem Opera, Firefox und Internet Explorer getestet und keine Probleme feststellen können. Bei mir wurde immer innerhalb des bereits geladenen Dokumentes (das bei FF und IE zumindestens nicht im Cache lag) ohne sichtbare Server-Anfrage navigiert. Weitere Informationen zu den Ankern findest du hier in SELFHTML. --MaKoLine 00:29, 8. Jan 2006 (CET)
Ich glaube das war einen Schwäche in meinem monobook.js oder css, dieser Effekt tritt nach neuer Version nicht mehr auf.--Löschfix 02:27, 24. Aug 2006 (CEST)


Hilfreichere Redirects

Wenn man über einen Redirect auf eine Seite kommt, kann es vorkommen, dass einem der Grund dafür nicht gleich ersichtlich ist. Wenn ich zum Beispiel nach "Bremuki" suche, weil ich nicht weiß, was das ist, werde ich auf die Seite "Revensteinen" weitergeleitet. Nun hilft mir die Seite über die Stadt Revensteinen nicht zu klären, was "Bremuki" ist. Erst mit der Suchfunktion meines Browsers gelange ich dann zu einen Abschnitt, der mir erklärt, dass Bremuki eine Revensteinener Backspezialität ist. Diese Möglichkeit hätte ich nicht, wenn

  • ich die Suchfunktion meines Browsers nicht kennte.
  • das Wort Bremuki gar nicht vorkommt, z.B. weil es im Artikel mit einem Synonym bezeichnet ist.

Daher schlage ich vor, dass bei erfolgtem Redirect statt (Weitergeleitet von Bremuki) eine kurze Erklärung angezeigt wird: (Bremuki ist eine Revensteinener Spezialität, siehe unten). Dies kann mittels erweiterter Redirect-Notation geschehen, etwa: 

 #REDIRECT [[Revensteinen|ist eine ...]]

--Duende 23:35, 10. Sep 2005 (CEST)

Die Kenntnis grundlegender Brwoserfunktionen dürfen wir wohl schon voraussetzen. Sollte allerdings der Redirect-Begriff im Zielartikel tatsächlich einmal nicht auftauchen, dann wäre der Redirect auch konsequenterweise zu löschen. --Zinnmann d 21:49, 11. Sep 2005 (CEST)
Löschtroll. nein nicht löschen, sondern den Begriff in den Artikel ergänzen.--Löschfix 03:32, 24. Aug 2006 (CEST)
Auch wenn man die gesuchte Stelle per Browserfunktion finden kann, halte ich es für sinnvoll, begründete Redirects einzuführen. Schließlich schlägt man im Lexikon etwas nach, was man nicht kennt. Daher kann es (besonders für Anfänger) verwirrend sein, plötzlich von einem zum anderen Begriff zu kommen, ohne den Zusammenhang zu kennen. --Duende 16:38, 14. Sep 2005 (CEST)
Grundsätzlich wäre eine derartige Funktion hilfreich. Allerdings sollte sie anders implementiert werden: Der Rest des Quellcodes der Redirectseite nach der Redirektzeile sollte einfach am Anfang der Zielseite eingefügt werden.-- StefanL 22:02, 14. Sep 2005 (CEST)
Ich habe die Diskussion von WP:VV hierher verschoben. --Duende 21:22, 16. Sep 2005 (CEST)

Eigentlich erübrigt sich die Diskussion, da eine Umleitung bei der Backspezialität falsch ist. Umleitungen sollen nur bei Synonymen verwendet werden, also etwa "Apfelsine → Orange" oder "Vicco von Bülow → Loriot". Falsch hingegen sind Teilbegriffe (Geschichte Chiles → Chile) oder weitere Umleitungen (Bremuki → Revensteinen). Sowas ist deshalb ungünstig, weil man zum einen im Artikel erst suchen muss, die Artikel auch länger (und damit unübersichtlich werden) und letztlich die Wikipedia um einen vielleicht ja spannenden Artikel über Bremuki gebracht wird. Meine Empfehlung: Umleitung einfach löschen lassen oder zu einem Kurzartikel umbauen. Stern 21:21, 24. Feb 2006 (CET)

Ich finde das ist eine zu strenge Auslegung, es macht in Einzelfällen durchaus Sinn, auch Teilredirects zu erlauben. Wie wäre es wenn der redir nicht von "Geschichte von Chile" auf "Chile" verweist, sondern auf "Chile#Geschichte".--Löschfix 03:32, 24. Aug 2006 (CEST)
Das Feature ist weniger notwendig, als den Begriff, im Artikel selbst zu erklären. Viel schlechter finde ich, wenn redirects aufgelöst werden - dann weiß man nämlich noch weniger, warum man daher kommt. Deshalb siehe Anfrage unten. --K@rl 20:05, 24. Jan. 2007 (CET)

Bearbeitungskonflikt beim Editieren eines Absatzes

Eben ist es mir passiert, dass ich einen Bearbeitungskonflikt bei der Bearbeitung eines Absatzes auf Diskussion:Hauptseite hatte. Daraufhin wurden die üblichen zwei Textboxen angezeigt, die aber jeweils den Quelltext der gesamten Seite angezeigt haben. Das Suchen des entsprechenden Abschnitts war mir zu kompliziert, daher habe ich meinen zusätzlichen Text einfach herauskopiert, die Bearbeitung abgebrochen, bin den Abschnitt über das Inhaltsvezeichnis erneut angesprungen und habe den Absatz neu editiert. Daher meine Vorschläge:

  1. Wenn beim Bearbeiten eines Absatzes ein Bearbeitungskonflikt auftritt, sollten die beiden Bearbeitungsboxen auch nur den entsprechenden Absatz anzeigen.
  2. Beim Bearbeiten eines Abschnittes sollte auch der Abbrechen-Link auf den entsprechenden Abschnitt verlinken (so ähnlich, wie dies beim Speichern-Button auch geschieht). --Ce 22:49, 30. Apr 2006 (CEST)

Bearbeitungskonflikt reduzieren gelegentlich kommt es vor, das wärend eines längern Edits, ein Bearbeitungskonflikt entsteht. Es wäre hilfreich, wenn beim simulieren (also betätigen der Vorschau) automatisch die Emulation des Originalartikels aktualisiert werden würde und erst dann der Edit hinzugefügt, so ist man weistesgehend auf dem neuesten Stand und kann durch die Simulation noch reagieren, falls etwas durcheinander gerät.--Löschfix 02:13, 24. Aug 2006 (CEST)

Bin für alle drei Punkte. Das Erscheinen des gesamten Artikels im "Bearbeitungskonflikt" erweckte bei mir den Eindruck auch fremde Änderungen anderer Abschnitte würde ich beim Speichern überschreiben/revertieren. --Diwas 04:56, 22. Feb. 2007 (CET)

Diskussionen komplett überarbeiten

Ich denke, der Diskussionmechanismus sollte grundlegend überarbeitet werden: Genauso wie "Versionen/Autoren" darf die Diskussion nicht nach Belieben von jedermann editiert werden können. Wenn ich meine Meinung äussere, möchte ich nicht, dass sie beliebig verfälscht werden kann, noch dazu wenn solche Manipulationen erst beim Durchsehen aller Versionen auffallen.

  1. Gegenvorschlag: Man kann auf der Diskussionsseite neue Threads erstellen oder in einem bestehendem Thread antworten. Die Seite ist nichtmehr direkt editierbar. Unterschrift/Zeit werden von der Software automatisch gesetzt. Auf die Weise klappt das dann auch mal mit dem Threading.
  2. Nachteil: Erledigte Threads/lange Diskussionen sind nichtmehr archivierbar, dafür müsste es dann eine Admin-Funktion geben.

--84.56.234.63 14:58, 1. Mai 2006 (CEST)

Wenn die Diskussionsseiten mit richtigem Foren-Code laufen (Diskussionsbeiträge also in sich abgeschlossene Einheiten bilden), könnte man das Archivierungsproblem automatisieren. Man könnte z.B. standardmäßig alle seit mehr als zwei Wochen inaktiven Threads automatisch ausblenden (natürlich mit einer Option, auch in alten Threads zu blättern). Wenn dann doch noch ein Beitrag kommt, dann wird der Thread automatisch wieder eingeblendet. Man könnte sogar den Zeitraum für die Anzeige in den Benutzereinstellungen wählbar machen.
Lange Threads könnte man durch "Einklappen" behandeln: Sobald der Thread eine bestimmte Länge überschreitet, werden die meisten Beiträge nur noch über ihre Titelzeile angezeigt, und erst "aufgeklappt", wenn man sie anwählt (eventuell auch bei Anwahl von direkten Antworten auf den Beitrag und bei Antworten bei Anwahl des beantworteten Beitrags). Das könnte sogar gleichzeitig die Server entlasten, da dann von vielen Beiträgen der Inhalt gar nicht geholt und aufbereitet werden muß.
Bei einem solchen Diskussionssystem wäre es sogar denkbar, eine Diskussion gleichzeitig mehreren Artikeln zuzuordnen (das wäre etwa praktisch bei Diskussionen, die Überschneidungen oder Widersprüche zwischen Artikeln betreffen).
Hauptnachteil des Vorschlags ist vermutlich der hohe Entwicklungsaufwand :-) --Ce 17:38, 6. Mai 2006 (CEST)
Entsprechende Teile irgendeiner brauchbaren Forumssoftware mit Code und geeigneter Lizenz zu kopieren und ins Diskussionstemplate einzubauen sollte eigentlich kein sonderlicher Aufwand sein. Nebenbei könnte mann dann auch eventuell das Forumstemplate für andere Bereiche nutzen. --MfG Carl_de 12:11, 7. Nov. 2006 (CET)
Etwas in der Richtung ist überfällig. Allein schon um sowas Wikipedia:Meinungsbilder/Beitragslöschungen gar nicht erst entstehen zu lassen. --Diwas 10:01, 18. Feb. 2007 (CET)

Beobachtungsliste: Namensraum und Diskussionsseite zusammenfassen

In der Beobachtrungslicte gibt es ja die praktische Option, die angezeigten Änderungen auf einzelne Namensräume einzuschränken. Allerdings werden dabei die Diskussionsseiten zu den Namensräumen als eigene Namensräume geführt, so daß es nicht möglich ist, sich z.B. gleichzeitig die Änderungen an beobachteten Artikeln und den zugehörigen Diskussionsseiten anzusehen (außer natürlich, wenn man auf die Einschränkung vollständig verzichtet). Meines Erachtens gehören aber Artikel und Diskussionsseite zusammen (wenn ich etwas über neue Änderungen an einem beobachteten Artikel wissen will, dann interessiert mich auch, was auf der zugehörigen Diskussionsseite passiert ist). Genauso natürlich auch in anderen Namensräumen (z.B. Wikipedia: und Wikipedia Diskussion:). Mein Vorschlag wäre daher, für die Einschränkung der Beobachtungsliste Namensräume und dazugehörige Diskussionsnamensräume als Einheit zu behandeln. --Ce 20:07, 10. Jul 2006 (CEST)

Ideal wäre (auch bei vielen anderen Abfragen im Netz) wenn man über STRG-linkeMaustaste mehrere Einträge aus der Auswahlliste wählen könnte. Eine Checkbox "Diskussionen jeweils mitanzeigen" wär auch i.O. Wäre sinnvoll, obwohl ich selbst momentan auch gut ohne auskomme --Diwas 06:07, 22. Feb. 2007 (CET)

Änderungen von IPs überprüfen

Hallo! Wäre es nicht sinnvoll einen Knopf für die Admins zu schaffen, mit dem sie hinter Änderungen von IPs einen automatischen "Überprüft"-Vermerk machen können? Ich denke dabei an sowas in der Beobachtungsliste:

(Unterschied) (Versionen) . . Adana‎; 17:16 . . (+2 Bytes) . . 89.49.70.230 (Diskussion) Überprüft. Admin-Name

Dann müssten wir uns nicht mehr alle gleichzeitig auf die Änderungen von IPs stürzen, sondern würden auf Anhieb sehen, dass da schon ein Admin drüber geguckt hat. --Enricopedia ⇄ 17:41, 21. Jan. 2007 (CET)

Erstens glaube ich ist es der falsche Ansatz nur Admins sowas zu erlauben (viel zuviel Aufwand alle zu überprüfen; Überprüfung ist auch normalen Benutzern möglich). Zweitens wird das allgemein schon praktiziert, und zwar bei den Tools, die einem die Letzten Änderungen anzeigen. Zu guter Letzt gibt es noch Wikipedia:Geprüfte Versionen und Wikipedia:Gesichtete Versionen. -- Amtiss, SNAFU ? 19:23, 21. Jan. 2007 (CET)
  • Die Tools die einem die letzten Änderungen anzeigen und wo dies praktiziert wird, kenne ich nicht.
  • Die Beschränkung nur Admins zuzulassen, muss natürlich nicht sein aber es sollte auch nicht jeder angemeldete Benutzer die Möglichkeit haben, weil man sich dann wieder nicht darauf verlassen kann, dass da nicht zwei Spinner am Werk sind.
  • Wikipedia:Geprüfte Versionen ist ein ganz anderes Thema
  • Wikipedia:Gesichtete Versionen würde, wenn es so umgesetzt wird, meinen Vorschlag überflüssig machen, weil nicht gleich jeder Mist sofort im Artikel steht und man mehr Zeit zum überprüfen hat.
Letztendlich sollte mein Vorschlag eine Verbesserung für Jeden und für jedermanns Beobachtungsliste sein, weil die ja wohl von den meisten Leuten regelmäßig genutzt wird − im Gegensatz zu den angesprochenen tools. Gruß --Enricopedia ⇄ 21:16, 21. Jan. 2007 (CET)

Anzeige von Herkunftslink

Es wäre oft hilfreich, wenn unter einem Artikel, ähnlich dem redirect Link angezeigt wäre, was in dem angeklickten Link hinter dem | steht. Oft ist dann klarer, warum man hierher kommt. Denn manchmal sind ja die Links mit einem ganz anderen Text als den eigentlichen verlinkten Artikel überblendet. Das würde die Handhabung meiner Meinung für den Leser wesentlich erleichtern. --K@rl 22:53, 22. Jan. 2007 (CET)

Von den Admins hier realisierbar

Textgröße in der Fußnote

Auch wenn die ursprüngliche Absicht war, mit der neuen Ref-Technik die Referenzierung zu vereinfachen, so ergibt sich aus der kleinen Schrift des Referenz-Textes (also nicht der Fußnoten-Nummer!) eine "unziemliche" Unleserlickeit, besonders bei kursiver Schrift (die sollte doch für den Buchtitel verwendet werden, gibts da nicht auch eine Vorschrift dazu?). In manchen heftig umstrittenen Artikeln sind die Quellenangaben von besonderer Bedeutung. Auch werden Fußnoten in komplizierten Texten (auch "draußen" in der wissenschaftlichen Literatur) für weitergehende und erklärende Anmerkungen genutzt. Es wäre also gut, wie in den Beispielen im Handbuch der englischen Wikipedia, die Fußnoten in Normalschrift zu gestalten. -Hati 10:52, 30. Apr 2006 (CEST)

Quellenangaben: Mehrfachindizieren mittels <ref name=".."/> unzweckmäßig

Mir fällt auf, daß <ref name=""/> im Zusammenspiel mit <references/> bei wiederholten Verweisen auf gleiche Quelle zwar mehrfache Fußnoten (Zahlenindex mit Buchstaben) vergibt, aber an der Absprungstelle des Mehrfachverweises nur der Zahlenindex ohne Buchstabe steht. Das bedeutet, daß man nicht weiß, auf welche Weise man wohin, also mit welchem Buchstabenindex man an seine Absprungstelle zurückkommt!
Warum produziert dieser verflixte tag an der Absprungstelle keinen Zahlen-Buchstaben-Index wie nach references/> ? --Wikipit 11:59, 1. Mai 2006 (CEST)

Quellenangaben erneut aufgegriffen

Inzwischen haben Quellenangaben einen größeren Stellenwert als noch von einem halben Jahr und immer häufiger werden Einzelnachweise auch bei nicht umstrittenen Themen verwendet. Ich denke daher, dass es lohnenswert ist, erneut über eine Änderung der derzeitigen Darstellung nachzudenken. Die derzeitige Lösung führt - je nach verwendetem Browser - zu einem mehr oder weniger vergrößertem Zeilenabstand, der mit einem Absatz verwechselt werden kann und den Lesefluss etwas stört. Der Vorschlag, den Zeilenabstand zu vergrößern, funktioniert leider nicht mit allen Browsern und "verlängert" darüberhinaus den Text. Gibt es eine Möglichkeit, das von Benutzer:Arcturus vorgeschlagene Verhalten zu erzeugen, nämlich, dass ein hochgestelltes Fußnotenzeichen (oder auch eine Hochstellung generell) den Zeilenabstand nicht vergrößert, so wie es in gedruckten Schriften ja auch der Fall ist? Funktionierte das in der "alten Vorlage Ref" (die ich nicht mehr einsehen kann)? Wenn das geschilderte Verhalten erzeugbar wäre würde sich eine Diskussion über Variante 2 oder 3 erübrigen. --Hei_ber 16:06, 7. Okt 2006 (CEST)

Ok, hier der Worktheotherwayaround: 
sup.reference { font-size:0.6em; }
in die monobook.css. Die Referenz-Zahl ist beim Wert 0.6em bei mir noch lesbar, erhöht den Zeilenabstand aber nur noch um ein Minimum, bei anderen Einstellungen (Auflösung/Browser/Schrift/Schriftgröße...) kann der optimale Wert aber auch etwas höher oder niedriger liegen (0.5em-0.7em). Mir gefällt die Lösung mit dem erhöhten Zeilenabstand dennoch besser, weil es längere Texte wesentlich angenehmer zu lesen macht. gruß ••• ?! 15:10, 8. Okt 2006 (CEST)


IP-Unterschrift

Ich hatte grad mal so meine Betrachtungen. Wenn IPs mit ~~~~ unterschreiben, was ja sehr vorbildlich ist, dann kommt da, wie bei allen anderen auch, der Link zur Seite Benutzer:000.000.000.000 . Und das ist völliger Schwachsinn. Weil die Seiten gibt's nicht und wird's auch nie geben weil das Letzte was IP's tun ist für ihre IP die vielleicht schon in einer halben Stunde nicht mehr gilt eine Benutzerseite anzulegen. Also wäre es doch imho sinnvoller (so es denn machbar ist) IP-Unterschriften so hinzubiegen das dort ein Link zu den Benutzerbeiträgen auftaucht, so wie das in den Versionsgeschichten auch gemacht wird. Nur mal so als Vorschlag zum drüber nachdenken, Gruß, Lennert B blablubb 23:58, 19. Feb 2006 (CET)

Dafür Hannes2 Diskussion 

Ihr vergesst, daß es IP Seiten gibt, die hinweisen auf wen die IP registriert ist. --chrislb 问题 11:56, 19. Apr 2006 (CEST)

Metainfo in Sprachennamen

Auch ich merke gerade, daß ich hierher hätte posten sollen und verweise auf Wikipedia:Verbesserungsvorschläge#Kleine kosmetische Änderung. Wikipeditor

Wunsch nach Spezialseite:Weiterleitung

siehe bitte Hilfe_Diskussion:Weiterleitung#Spezialseite --Emgo 12:39, 1. Mär 2006 (CET)

Kategorieanzeige im Artikel: K:Kategorie

Wenn vor jeder Kategorie, welche im Artikel unten angezeigt wird zB ein K: steht, dann könnte man über Google schon leichter eine Suche mit verknüpften Kategorieeinträgen machen. zB: K:Mann | K:Schriftsteller | K:geboren 1900 - dann kann man in Google suchen nach " K:Mann K:Schriftsteller "K:geboren 1900" ". Eine jetzt schon mögliche, kompliziertere, verknüpfte Abfrage wäre diese hier: mann Österreicher komponist -Gregorianischen -Kalender site:de.wikipedia.org. --Fg68at Disk 20:39, 2. Mär 2006 (CET)

Wenn's nur um Google-Suchbarkeit geht, sollte man m.E. nicht das visuelle Erscheinungsbild dafür verkrüppeln, sondern die Google-Hilfskonstrukte dorthin stellen, wo sie zwar von Google, aber nicht vom Auge gefunden werden. Falls Google Meta-Tags im Header auswertet, wäre das ein vernünftiger Ort; zur Not täte es aber auch ein unsichtbarer Block im HTML. --Ce 12:38, 26. Apr 2006 (CEST)
Google wertet meiner Erfahrung nach Meta-Tags (zumindest "Content") aus. --FGodard ✉ Bewertung 15:45, 13. Apr. 2007 (CEST)
  • dafür:
  • dagegen:

AFK Meldung

Ist es möglich, ähnlich wie die Links nach dem User Namen, ein kleines AFK menue einzubauen. Durch die Information ob ein user „away from keyboard“ ist, ließe sich sicher auch Platz auf den Servern sparen, da Antworten auf Beiträge zeitversetzt erfolgen könten: AFK bis 22.03.2007 (CEST) auf der Benutzerseite. Könnte auch in Form eines Babels geschehen. Gruß --Elnolde 12:04, 6. Sep 2006 (CEST)

Eine solche Spielerei sieht man oft in Foren. Die Aktivität eines Benutzers lässt sich aber mMn leicht genug über die Benutzerbeiträge (etwa Spezial:Beiträge/Elnolde) festgestellt werden. Die Signaturen sind schon so lang genug. Einen Hinweis, das man wegen Urlaub oder aus anderen Gründen nicht verfügbar sein wird, kann man auch selbst auf seiner Benutzerseite anbringen, wie es auch bereits gehandhabt wird; meinetwegen verfasst man das Ganze auch als Babel. Aber nicht als zentrale Softwareänderung, bitte. Es wäre mit einer stark angepassten Version von Lupins Popups über Javascript jedoch sicher möglich, beim Überfahren eines Links auf eine Benutzerseite den Zeitpunkt der letzten Bearbeitung dieses Benutzers festzustellen. --CyRoXX (? ±) 16:12, 13. Apr. 2007 (CEST)

Spezial:Log

Im Logbuch wird immer sofort ein Link auf die Beiträge des entsprechenden Benutzers gegeben. Wäre es nciht gut, wenn man die Beitragsliste in diesem Fall bei dem letzten Beitrag vor der Sperre beginnen ließe? Besonders bei kurzzeitigen Sperren von sehr aktiven Benutzern ist es richtig Arbeit, wenn man sich ein Urteil bilden will, ob sie wirklich etwa die Wikiquette verletzten. Möglich wäre eine solche Funktion ja wohl. --Hannes2 Diskussion  22:02, 7. Sep 2006 (CEST)

Auch unter Werkzeuge

Ein Verlinkung von jedem Artikel auf das Logbuch. Das wäre auch für die Vorlage bei nicht vorhandenen Artikeln sinnvoll, siehe Benutzer:Thiemo Mättig/Vorlage:MediaWiki Newarticletext NS (bzw. die Diskussion). Andererseits ist das Logbuch in anderen Vorlagen überhaupt nicht verlinkt (wahrscheinlich in jedem anderen Namespace). -- Amtiss, SNAFU ? 13:20, 8. Sep 2006 (CEST)

Zwangs-Subst-Parameter für Vorlagen

Einige Vorlagen sind strukturell für den 'Subst:-Einsatz' gemacht (z.B. {{Hallo}}, {{Unsigned}}, etc.). Nur wird dies regelmäßig vergessen oder ist sogar bei manchen Teilnehmern gar nicht bekannt, wodurch u.a. eine ständige Serverlast erzeugt wird. Wäre es nicht sinnvoll, einer Vorlage eine Anweisung hinzuzufügen, dass diese bei jedem Einsatz auch ohne {{Sunbst:Vorlage}} 'zwangsweise' ersetzt wird? Habe auf Bugzilla keinen derartigen Vorschlag finden können, er macht jedoch hinsichtlich Benutzbarkeit und Ressourcenschonung IMHO Sinn... --NB > ?! > +/- 12:44, 8. Sep 2006 (CEST)

Zum Thema Ressourcenschonung: Brion hat sich schon mehrfach dahingehend geäußert, dass sich die Projekte um so etwas nicht kümmern sollen. Die Entwickler sehen es als ihre Aufgabe, die Software und Hardware den Bedürfnissen der Projekte anzupassen, nicht umgekehrt.
Zum Thema Benutzbarkeit: Es ist möglich Vorlagen so zu programmieren, dass sie eine Fehlermeldung ausgeben, wenn sie nicht mit subst: eingebunden werden. -- sebmol ? ! 12:54, 8. Sep 2006 (CEST)
Hallo Sebmol, danke für die schnelle Antwort!
Aber die Entwickler haben doch noch keine Gedanken lesende Software in der Mache, oder? ;-) - Irgendeinen Hinweis werden auch zukünftige Versionen benötigen, um die Benutzer-Intention bei Vorlagen zu erkennen, damit die Entwickler die Software entsprechend auslegen können...
Hast Du mal ein Beispiel (bevor ich hier erst noch durch alle Handbücher fräse)? Wobei die Fehlermeldung ja auch nur dann hilft, wenn alle Benutzer immer brav die Vorschau benutzen - und dafür willst Du bestimmt nicht deinen Kopf hinhalten, oder? ;-)
--NB > ?! > +/- 13:19, 8. Sep 2006 (CEST)
Tatsächlich ist die Überprüfung ein ekliger Hack. Also, schau mal auf Benutzer:Sebmol/Vorlagenspielwiese. Wenn das mit subst: eingebunden wird, steht da "SUBST BENUTZT", wenn nicht dann "SUBST NICHT BENUTZT". Damit kann also zwischen den Einbindungsmöglichkeiten unterschieden und ggf. eine Warnung ausgegeben werden. Das ist vielleicht nicht ideal, sollte aber ausreichen. Zum Thema Vorschau: selbst wenn sie die Vorschau nicht benutzt haben, sehen sie ja danach, dass subst: vergessen wurde, können es also nachträglich noch ändern. -- sebmol ? ! 11:59, 12. Sep 2006 (CEST)
Danke! Wobei meine Definition von 'eklig' eindeutig eine andere ist, das ist doch noch 'elegant'... ;-) --NB > ?! > +/- 12:56, 12. Sep 2006 (CEST)
  • Tja, so 'einfach' klappt es leider bei Parameter-Vorlagen nicht - was also spricht genau gegen einen Vorlagenmarker, der ohne programmtechnische Klimmzüge jedem die Zwangssubstituierung von Vorlagen erlaubt. Bedarf besteht dafür jedenfalls, wenn ich mir die Kategorie:nur Subst anschaue (zumal dieses Problem sicher nicht nur in der de:wp existiert) - und die Programmierer doch dem Volk auf die Tastatur schauen wollen... --NB > ?! > +/- 13:26, 12. Sep 2006 (CEST)
Wo hat das nicht geklappt? -- sebmol ? ! 13:28, 12. Sep 2006 (CEST)
Schau mal hier... --NB > ?! > +/- 15:43, 12. Sep 2006 (CEST)
  • Wenn man diese Diskussion liest, erscheint mir mein Vorschlag sogar sehr begründet... ;-) --NB > ?! > +/- 11:41, 13. Sep 2006 (CEST)

Vorschlagserweiterung

Nach weiteren Diskussionen würde ich den Vorschlag wie folgt erweitern:

Jeder Vorlage sollte ein Typ-Flag zugeordnet werden, welches die vom Autoren gewünschte Einbindungsart angibt: Subst, Nosubst oder Mixed. Bei 'Subst' bzw. 'Nosubst' würde die Software bei der Einbindung der Vorlgae in anderen Seiten diese entsprechend vornehmen, bei 'Mixed' wäre es weiterhin optional. Dies könnte über den Parser-Check nach Vorlagen-Edit erfolgen (als Fehlermeldung in der Art „Sie haben noch keinen Vorlagentyp festgelegt, bitte tragen Sie das entsprechende Flag vor dem Speichern ein: Subst/Nosubst/Mixed/'Ich weiß nicht'“), so dass mit der Zeit jede (aktive) Vorlage ein entsprechendes Flag erhält. Dadurch würden dann bei 'Subst'-Vorlagen auch die ungesubsten Einbindungen mit der Zeit (beim nächsten Parsen nach Edits) gesubst, so dass auch hier die Aktualisierungen weitgehend automatisch erfolgen würde... --NB > ?! > +/- 09:09, 14. Sep 2006 (CEST)

Vermisse LaTeX Befehl "\ominus"

Hallo! Ich habe bemerkt das Wiki-LaTeX \ominus nicht kennt. Dagegen ist ihm \oplus sehr wohl bekannt. Ich fände es toll wenn das Pendant \ominus auch eingeführt wird. Zur Zeit behefle ich mir mit einem Bild: Bild:Ominus.png Aber orginel ist das nicht. Danke im Voraus!--Akribix 16:46, 9. Sep 2006 (CEST)

Besseres Forumssystem

Auf/in der Wikipedida wird viel Diskutiert. Unser System könnte da etwas unterstützender sein. Diskussionen werden zu schnell unübersichtlich und recht umständlich ist es dazu auch, eine ganze Reihe von "::" zu machen. Den Diskussionstext in Absätze zu gliedern fällt schwer und diese Ansicht baut die Diskussion zu linear auf. Kla, wer sich an dieses mMn umständliche System gewöhnt wird es nicht interessieren. Aber ich finde es zB im Vergleich zum Rest der Forenstruktur im Internet unübersichtlich und umständlich.

Die Umgestaltung sollte wünschenswert dahin gehen:

  • Dass die Baumstruktur der Beiträge besser erkennbar ist (Auf- und zuklappen)
  • Das man wenigstens die einzelnen Beiträge gut von einander unterscheiden kann (ist manchmal garnicht so einfach).
    • so dass Benutzer (wie hier) auch mitten in einer Diskussion zB so eine Aufzählung machen können, ohne dass sie an den Rand geschoben wird.
  • Direkte Antowrt auf einzelne Beiträge (Baumstruktur), so dass man in den Diskussionen besser Haupt- und Nebendiskussion unterscheiden kann.

Kurz gesagt, das man auf den Diskussionsseiten so kompfortabel und praktisch diskutieren kann wie in allen anderen Foren im Internet auch. Ich glaub jeder weiß, welche Elemente ich meine. - Metoc ☺ 17:00, 13. Sep 2006 (CEST)

Siehe oben unter #Diskussionen komplett überarbeiten. --Ce 21:36, 13. Sep 2006 (CEST)

Benutzerbeiträge als übersichtliche Tabelle

Die eigenen Beiträge, werden zwar bisher platzsparend, untereinander in einer Liste geführt, aber es ist mühsam, nach einer Woche mal drüber zu schauen, ob die eigenen Ergänzungen nochmal von anderen verbessert wurden. Besser wäre eine Tabelle (border=1 valign=top)

Spalte 1: Uhrzeit / Datum Spalte 2: Link ´Versionen´ + ´Unterschied´ (evtl. als Symbol) Spalte 3: Titel des Artikels Spalte 4: Anzeige ´Aktuell´ + ´K´ Spalte 5: Was wurde geändert / Quellen

Also vom Prinzip wie bisher, nur tabellarisch. -- Jackcwtr 17:56, 16. Sep 2006 (CEST)

Was die Problematik angeht kann ich nur zustimmen. Vor allem wenn viele Bearbeitungen noch aktuell sind, wird eine Suche schwierig. Eine Tabelle ist meiner Meinung nach gar nicht nötig, einzig das "Tag" (aktuell) müsste eine Position rüberrücken, und eventuell noch farblich vom K bzw. N abgehoben werden. @Jackcwtr: Du hast noch den Autor vergessen. -- Amtiss, SNAFU ? 13:42, 17. Sep 2006 (CEST)

SVG wird von der Software zu PNG konvertiert

Bild:Pfeil oben.svg ist ja gut, aber kann mans nicht so machen, dass bei Browsern, die SVG unterstützen, direkt das SVG angezeigt wird (und nicht nach PNG konvertiert wird)? Bei manchen Bildern (Beispiel) sieht das, wenn man in den Einstellungen die Maximalgröße auf 10000x10000px gestellt hat, enorm pixelig aus. TZM Alles ist relevant! 18:21, 17. Sep 2006 (CEST)

In der offenbar irrigen Annahme, das sei bereits der Fall, habe ich mich immer über die .png-Endungen gewundert. Schließe mich dem Vorschlag an. W. 2006-09-17
Ich schließe mich dem Vorschlag ebenfalls an, zumal damit dann wenigstens auch der Bug mit dem Ersetzen der Alphakanäle mit schwarz (bei PNG durch Firefox, XnView usw.) behoben/umgangen wird. Ein nachteil hat das ganze allerdings, und zwar unterschiedne sich die SVG-Viewer immer noch leicht in ihrer Darstellung, so dass es ab und an vorkommt, dass Text leicht untershciedlich positioniert ist. --Cepheiden 10:32, 12. Jan. 2007 (CET)

Seiten-Löschungen auf die Beobachtungsliste

Ich fände es sehr praktisch, wenn ich auf meiner Watchlist darüber informiert werden könnte, wenn eine Seite, die ich beobachte gelöscht wurde. --Ich bin nicht die Signatur, ich putz hier nur 23:18, 23. Sep 2006 (CEST)

M.E. funktioniert das doch darüber, dass eine gelöschte Seite in der Beobachtungsliste (beim Bearbeiten der Einträge) in Rot statt blau angezeigt??_ wird. Oder irre ich da? --Ebcdic 15:38, 6. Jan. 2007 (CET)

Visueller Hinweis auf Stabilität eines Artikels

Über die Editwars habe ich schon einiges gelesen, und sie sind ärgerlich für jeden, der etwas recherchieren will. Ich schlage vor, einen visuellen Hinweis in jedem Artikel von der Software erstellen zu lassen, etwa in Form eines Pegelstandes zwischen grün (seit längerem stabil) und rot (viele Änderungen in letzter Zeit). Große Änderungen wie auch Rückgängigmachungen der Änderungen eines anderen Benutzers sollten sich stärker auf diesen Pegel auswirken als kleine Änderungen. Im Laufe der Zeit sollte der Pegel sich normalisieren. Dadurch hätte jeder Leser eines Artikels direkt einen Hinweis darauf, ob dem Artikelinhalt möglicherweise zu misstrauen ist. -- 87.78.179.223 17:07, 29. Sep 2006 (CEST)

Special::Random erweitern

Ich stöbere öfters in der Wikipedia einfach über die Random-Seite. Dabei finde ich die unzähligen Artikel über Lokalpolitiker oder Gemeinden extrem störend. Es wäre schön, wenn man eine Random-Suchseite hätte, wo man einzelne Kategorien (z.B. Personen und Geographie) unterdrücken könnte. 84.147.142.214 17:51, 30. Sep 2006 (CEST) Robert

Beobachtungsliste für Artikel, die auf einen Artikel verlinken

Situation: Ich habe es in einigen Artikeln, die ich bearbeite, gerade mit einem besonderen Fall von Vandalismus zu tun, in dem jemand persönliche Aversionen gegen einen Künstler in Artikeln auslebt, die nur sehr entfernt oder gar nicht mit der Person in Verbindung stehen (Beispiele: 1

Wikipedia
 Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.

, 2

Wikipedia
 Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.

, 3

Wikipedia
 Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.

, 4

Wikipedia
 Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.

, 5