Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2006

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Softwareänderung nötig

Kategorien beobachten

Bislang lassen sich Kategorien nur unzureichend beobachten. D.h. wenn ich die Kategorie:Ethnologie beobachte, wird mir in der Beobachtungsliste nicht angezeigt, ob ein neuer Artikel in die [Kategorie:Ethnologie] eingeordnet wurde. Wenn sich dies ändern liesse, wären die Kategorien ein sehr nützliches Instrument. -- Napa 06:53, 18. Aug 2004 (CEST)

Und ergänzend sollten unter "Versionen" auch das Hinzufügen und Wegnehmen protokolliert werden. -- Pjacobi 01:39, 19. Aug 2004 (CEST)
Vor allem mit den von Pjakobi ergänzten Vorschlag, würde das die Arbeit sehr viel erleichtern. --K@rl 09:32, 19. Aug 2004 (CEST)
Vielleicht aber nicht gerade unter Versionen, sondern unter einer speziellen Liste.--Hannes2 Diskussion  08:30, 11. Apr 2006 (CEST)
So etwas in der Richtung geht mittlerweile mit dem Catscan --Flominator 16:11, 7. Jan. 2007 (CET)
  • Dagegen:
Nachträglicher Hinweis: Eine Übersicht zu Diskussionen zum Thema "Kategorien beobachten" im Sinne der neuesten Zu- oder Abgänge in einer Kategorie findet sich unter Benutzer:Zulu55/Wikipedia:Kategorien "beobachten". --Zulu55 (Diskussion) Unwissen 15:32, 27. Aug. 2013 (CEST)

eigenes Javascript am Ende

Über Benutzer:Benutzername/skin.js kann man ja per eigenem Javascript auf die Seitendarstellung Einfluß nehmen (was recht praktisch ist, um z.B. die Seitenleiste den eigenen Vorlieben anzupassen). Diese Seite wird jedoch schon am Anfang der Seite eingebunden, was sinnvoll ist, um Funktionen zu definieren, aber den Nachteil hat, dass die Seite noch nicht "vorhanden" ist, so dass man zu unschönen Tricks greifen muss (siehe z.B. Benutzer:Ce2/standard.js für den Aufwand, den ein simples Einfügen eines Links aufs Projektportal erfordert - wenn jemand eine Vereinfachung weiss, bin ich natürlich für jeden Hinweis dankbar).

Mein Vorschlag wäre nun, am Ende der Seite (nach </body>) eine zusätzliche JS-Datei einzubinden - z.B. skin-final.js -, die dann einfacheren Zugriff auf das Dokument erlaubt.

Ich habe da Sicherheitsbedenken. Mir kann damit jemand ein beliebiges js auf mein Benutzerprofil beamen. Solange das Profil keinen Schreibschutz gegen andere Benutzer hat bin ich gegen beide Ideen. Dr. Schorsch 10:26, 26. Jul 2005 (CEST)
zumindest im internet explorer geht window.onload = Funktion;. --joni Δ 12:32, 26. Jul 2005 (CEST)
Das Hinzufügen einer JavaScript-Handlerfunktion für das load-Ereignis ist relativ einfach, dazu bedarf es eigentlich keiner »unschönen Tricks«. http://simon.incutio.com/archive/2004/05/26/addLoadEvent bietet dazu eine einfach nutzbare Funktion. -- molily 12:58, 12. Aug 2005 (CEST)
Habe ebenfalls Sicherheitsbedenken: Seite weiterleiten, unsichtbare Werbebanner, Browser verlangsamen/abstürzen lassen, Passwortklau siehe Eba* Mokros 00:09, 25. Aug 2005 (CEST)

Ich vestehe das alles nicht. Erstens kann man alle Wünsche in monobook.js einbauen (ich habe da bei mir einige nette Sachen implementiert), zweitens sehe ich in dem o.g. standard.js überhaupt keine unschönen Tricks, sondern ganz normale Befehle, und drittens sehe ich keinen Grund für Sicherheitsbedenken, da monobook.js nur von mir editiert werden kann. Ich bin also weder dafür noch dagegen, ich halte es für unnötig. --Plenz 11:54, 8. Jan 2006 (CET)

Die Tricks habe ich wieder rausgenommen, nachdem nach einer allgemeinen Änderung der zusätzliche Eintrag (zum Projektportal) ohnehin im Menü stand (und sich ein zusätzliches Eintragen somit erübrigt hat). Der alte Code kann hier bewundert werden :-)
Ob Du nun monobook.js oder standard.js editieren musst, hängt ganz einfach davon ab, welchen Skin Du eingestellt hast (allgemein skinname.js, außer daß der Skin "Standard" inzwischen in "Klassik" umbenannt wurde (er ist ja auch nicht mehr der Standard-Skin), die zugehörigen Dateinamen aber nicht.
@molily: Danke für den Link. Ich hatte vorher auch mit onload herumexperimenteiert, hatte aber keinen Erfolg damit. Und jetzt habe ich auch den Code von der angegebenen Seite ausprobiert, und er scheint auf der Wikipedia auch nicht zu funktionieren (obwohl die Testseite auf dem Link problemlos funktioniert; dasselbe Problem hatte ich auch mit meinen eigenen onload-Experimenten). Keine Ahnung, woran das liegt, aber onload und Wikipedia scheinen irgendwie nicht ganz kompatibel zu sein ... (und bevor jemand fragt: Ja, Ctrl-Shift-R habe ich gedrückt, und in der JavaScript-Konsole werden beim Reload auch keine Fehler angezeigt) --Ce 01:00, 11. Mär 2006 (CET)
Ich habe jetzt mehr durch Zufall die bereits im MediaWiki implementierte Funktion "addOnloadHook" entdeckt (beim Suchen einer HTML-Datei im Browser-Cache bin ich auf eine Wikipedia-Javascript-Datei gestoßen, die diese Funktion definiert), die genau das gewünschte leistet (ich vermute diese Funktion bzw. die von dieser verwendete Infrastruktur ist auch dafür verantwortlich, dass die ganzen Versuche "per Hand" nicht geklappt haben). Beim Versuch, herauszufinden, ob das eine dokumentierte Funktion ist (also etwas, wo ich nicht befürchten muss, dass es beim nächsten Update sang- und klanglos wieder verschwindet), habe ich zusätzlich die äußerst informative Seite en:Wikipedia:WikiProject User scripts/Techniques gefunden. Da die gewünschte Funktionalität somit vorhanden ist, ziehe ich meinen Feature Request hiermit zurück. --Ce 18:59, 24. Apr 2006 (CEST)

Default-Button [Seite speichern] ändern

Das ist jetzt genau genommen kein Fehler, aber ich weiß grad nicht wohin ich das sonst kleben soll. Mir ist es eben passiert, dass ich im Eingabefeld für die "Zusammenfassung" versehentlich die [Enter]-Taste gedrückt habe, und schwupp-di-wupp war meine Änderung schon gespeichert, obwohl ich noch gar nicht sicher war, ob ich das auch will. Ich finde wenn schon ein Default-Button definiert sein muss, dann sollte es der [Vorschau zeigen]-Button sein. --addicted 15:57, 23. Aug 2004 (CEST)

ich bin dagegen, da es 1. nicht konform mit gängigen Webstandards ist (z.B. alle login-formulare gehen mit Enter zu bestätigen (HTML-Forms allgemein sogar, oder?)), 2. es wahrscheinlich dein einziger "Ausrutscher" in der nächsten Zeit sein wird. und 3. weil ich (und bestimmt viele andere) ihre Zusammenfassung eintippen, _nachdem_ sie den Artikel geändert haben, und dann leicht mit Enter die Änderung abspeichern können. --BLueFiSH ✉! 18:57, 7. Feb 2005 (CET)
@„nachdem“: nicht unbedingt, ich mache es auch öftzers mal zwischendurch, da es mir schon passiert ist, dass ich einige änderungen gemacht habe, und am ende wusste ich nciht mehr was das ncoh alles war, somit schreibe ich die zusammenfassung auch öfters zwischendurch. --joni Δ 10:53, 19. Mär 2005 (CET)
Obwohl der Vorschlag jetzt schon ein Jahr alt ist, bin ich noch immer dafür. Nein es war nicht mein einziger Ausrutscher, und passiert mir gelegentlich immer wieder. (parkinson?) Da ich es ähnlich wie joni mache, denke ich, dass es noch immer am besten wäre keinen, oder eben den den Vorschau-Button als Default zu haben, wobei keiner vermutlich die sicherere Variante wäre.
Login-Formulare sind meine Meinung nach nicht mit einem Bearbeitungsformular zu vergleichen. Bei anderen, z.B. Kontakt- Formularen hab ich auch schon gesehen, dass der "Zurücksetzen"- (sprich Löschen-) Button der Standard war. --the one who was addicted (#) 18:01, 11. Aug 2005 (CEST)
dagegen. besser es wird eine unvollständig änderung gespeichert die rückgängig gemacht oder erweitert werden kann, als garnicht. viele gehen davon aus das mit [Enter] der artikel gespeichert wurde und übersehen eventuell das es eine vorschau ist. -- Qopep 10:18, 25. Jul 2005 (CEST)
Ich bin gegen unnötig viele Versionen, daher möchte ich keine unvollständigen Änderung speichern. Gegen das Übersehen der Vorschau gibt es ja den Hinweis "Dies ist nur eine Vorschau, der Artikel wurde noch nicht gespeichert!". Aber um es trotzdem zu verhindern, wäre ein Lösungsvorschlag ja auch _keinen_ Defaultbutton zu definieren. Und in meinem ursprünglichen Fall (2004) war die Artikeländerung zwar vollständig, aber meine Zusammenfassung nicht, und es war etwas von dem es mir wichtig schien, dass es in der Zusammenfassung erwähnt werden sollte. daher mein Vorschlag. --the one who was addicted (#) 18:01, 11. Aug 2005 (CEST)
lol* ist mir noch nie passiert (und ich arbeite viel mit Tastatur, ähe* ja) -- Ολλίμίνατορέ Ω 10:46, 25. Mär 2006 (CET)

am besten wäre es, wenn man den default-button einstellen könnte. --joni Δ 18:04, 21. Jul 2005 (CEST)

vielleicht ein undo button ... lg, dee.lite


Ich wollte hier mal zur Diskussion stellen, dass etwa bei CTRL+S (oder ALT+S?) ein Hinweisfeld erscheint, ob man wirklich abspeichern will. Es ist mir schon einmal passiert, dass ein Artikel unvollständig gespeichert wurde. --Gruß, Constructor

Kategorie-Browsing via Sidebar

Ich lese einen Artikel der in Kat:X einsortiert ist. Nnun wäre es Klasse wenn man eine Art Kategorie-Browser in der Sidebar hätte. Stelle wir das so vor das die Kat in die der Artikel einsortiert ist angezeigt werden und man dann jeweils deren Inhalt auch in der Sidebar anzeigen kann. Hier könnte man die Kat. als Baumstruktur nutzen und dann ggf zu anderen Artikeln springen. --Flacus 23:38, 26. Jan 2005 (CET)

Gute Idee! ich bin dafür, man könnte vielleicht auch die Portale irgendwie hineinkriegen, oder auch die anderen wikis (Wiktionary wär da super zu integrien, denk ich) Natürlich muss das auch abstellbar sein, aber das is ja kein problem - glaub ich Telcontar
Ggf. wurde der Wunsch mittlerweile erfüllt, siehe CategoryTree bzw. Back-Category. Ersteres von beiden läßt sich in die Sidebar von Mozilla und Firfox integrieren. Kolossos 21:35, 20. Feb 2006 (CET)
  • Dafür :
  1. Telcontar, Flominator, FWHS
  • Dagegen:
    • Habe das gleiche Problem, allerdings eine andere Lösung: Bei den großen Linkvorkommen könnten Zusatzinformationen (Kategorien) Mit dem "Maus-Zeiger-Text" (Infobox-Stylesheet)gebrowst werden. Oder? 141.58.115.197Stefahn

URN und DOI analog zu ISBN einlinken

Bei Dissertationen finde ich immer häufiger statt Buch-ISBN lediglich eine URN für sogenannte Online-Ressourcen. Diese sind über die URL: http://bieson.ub.uni-bielefeld.de/volltexte/2004/500/ der Uni Bielefeld im Abstract und sogar oft im Volltext zugänglich. Vermutlich kein großer Arbeitsaufwand, wenn "gewusst wo" anzusetzen ist. Temistokles 20:43, 13. Feb 2005 (CET)

Es ist wichtig, dass URN und DOI möglichst bald in die Wikipedia-Engine integriert werden, da sonst schnell Wildwuchs entsteht. Die einfache Eingabe einer URN oder DOI (z.B. urn:nbn:de:hbz:361-5004) sollte je nach Namespace automatisch zum richtigen Resolver führen (z.B. urn:nbn:de:hbz:361-5004). Den Namespace nbn vergeben z.B. die Nationalbibliotheken. Deren URNs kann man z.B. über den Resolver http://nbn-resolving.de auflösen. Ich habe dazu eine Vorlage geschrieben, aber das sollte keine langfristige Lösung sein. Gleiches gilt übrigens wie Eingangs schon erwähnt unbedingt auch für DOI! --Giordano 15:26, 5. Feb 2006 (CET)

Die Vorlage kommt auch leider nicht mit allen Sonderzeichen klar (siehe Vorlage Diskussion:DOI). --Giordano 15:23, 21. Jun 2006 (CEST)
  • Dafür: FWHS
  • Dafür: Giordano
  • Dafür: Benutzer:Lode (v.A. DOI)
  • Dafür: Kann die Vorlage nicht das URL-Encoding vornehmen --Erfurth 14:39, 1. Aug 2006 (CEST)
  • Dagegen: Vorlage reicht aus (Sonderzeichen ist ein anderer bug) und ist flexibler. -- Nichtich 02:31, 22. Jun 2006 (CEST)
  • dagegen Ich finde es sollte erst einmal konsequent überall ISBN und ISSN angegeben werden, das ist bei weitem nicht der fall.--Löschfix 01:55, 24. Aug 2006 (CEST)
  • Dafür: Rattenschwanz

Rechtschreibprüfung

Wenn man nach der Bearbeitung auf Vorschau klickt, könnten doch die verwendeten Wörter auf dem Server mit einer Datenbank verglichen werden und unbekannte Wörter als Hinweis durch eine Wellenlinie markiert werden. Die zusätzliche Serverlast ist mit der im Moment durch spätere Rechtschreibänderungen entstehenden zu vergleichen. Wir dürften hier auch schon genügend richtig geschriebene Wörter haben um auch selber so eine Liste aufzubauen. Die freie Software scheint auch schon zu laufen und heißt Ispell und kann auch online getestet werden[1]. Natürlich müßte man sie noch an unsere Erfordernisse anpassen. Wenn die Server zu stark belastet sind ließe sich die Funktion auch zeitweise abschalten. Kolossos 17:44, 23. Mär 2005 (CET)

find ich ne gute Idee, und mit dem Argument bzgl. der nachträglichen Edits und der Serverlast könntest du durchaus Recht haben. --BLueFiSH ?! 18:23, 23. Mär 2005 (CET)
Ansonsten gibt es für Legastheniker wie mich die Google-Toolbar mit integrierter Rechtschreibprüfung von Webformularen. [2] Kolossos 17:30, 10. Mai 2005 (CEST)
gute idee. es könnte dann noch die einstellung geben, ob man beim speichern auf fehlerhaftes aufmerksam gemacht werden will (möglicherweise auch noch trennung zwischen artikel und diskussion, also am besten mit namensraumangabe). zur erweiteruhng der liste könnte man es so machen, dass man einfach ein wort hinzufügen kann zur rechtschreibliste, dass noch nicht vorhanden ist, er sich dieses hinzufügen-wollen speichert und bei einer bestimmten anzahl von hinzufügen-wollen das wort in die liste mit aufnimmt.
gewelltes unterstreichen ist meines erachtens in html-dokumenten nicht möglich, aber da könnte man natürlich auch anders verfahren. man könnte z. b. „… der blaue und grosse (hinzufügen) Wal ist mit …“ schreiben.
--joni Δ 20:56, 29. Jun 2005 (CEST)
ist imo nicht realisierbar, weil zu aufwendig und belastet den server zu stark. außerdem kann jeder selbst ispell installieren und den artikel prüfen lassen. Darrn 11:21, 25. Jul 2005 (CEST)
Eine weitere Alternative (für die deutsche Wikipedia) wäre die Rechtschreibprüfung von APPER, weitere Infos auf Benutzer:BLueFiSH.as/Javascripts & Stylesheets von Benutzern --M.A. (Marc-André Aßbrock) 16:08, 4. Jan 2006 (CET)

Alles unnötige Serverbelastung, die Clientseitig von anderen Programmen erledigt werden können. Wenn es Clientseitig mit der Wiki-Software gehen würde, würde ich meine Meinung revertieren und zustimmen. -- Ολλίμίνατορέ •Ω• 15:20, 7. Apr 2006 (CEST)

Mehr Textedit-Buttons für Anfänger

Es sollte bei der Edit-Seite mher Word-mäßige Knöpfe geben, wenn Wikipedia die Formatierungen Unterstützt. Ich denke da an:

  • Bullet-Points
  1. Aufzählungen
  2. r e d i r e c t

Die Bearbeitsungshilfe sollte nochmal in der Buttonzeile auftauchen, zB. als "?" rechtsbündig. --qwqch 13:56, 14. Jun 2005 (CEST)

Kleiner Zusatz: z.B. die Franzosen haben da schon mehr Buttons (siehe Bild). Und die Links auf das Bild, wo dies bei uns bereits angesprochen / diskutiert worden ist. --JuTa Talk 16:30, 21. Okt. 2006 (CEST)

Dafür:

  • qwqch
  • joni Δ Träumer (speziell den punkt mit redirects finde ich sehr gut.)
  • FWHS (Vorlagen könnten da auch mit als Auswahlliste)
  • dee.lite Der Mensch ist nun mal visuell und nicht html orientiert.  ;) Ich finde auch für die Bildformation sollte ein Standardbutton verfügbar sein (thumb, px). Und bitte tut etwas, damit ein normaler Mensch mit Tabellen in Wikipedia arbeiten kann. Diese tausend Stricherln sind für Normalos keineswegs leicht zu durchschauen.
  • --JuTa Talk 16:30, 21. Okt. 2006 (CEST) man müsste im Einzelnen noch mal sehen, was sinnvoll ist, aber prinzipiell dafür.
  • Tlustulimu wäre ja schön, wenn sich das benutzerspezifisch einstellen ließe.

Dagegen:

  • --Hannes2 Diskussion  19:43, 4. Mär 2006 (CET) Macht alles unübersichtlich. Ich würde eher vorschlagen, bei den Sonderzeichen eine Zusatzsonderzeichenliste für Anfänger zu machen.
Ich fände schon toll, wenn ich so viele Knöpfe kriegen könnte wie in fr:wikipedia. Liegt das nur an meinem style css oder js? Oder ist das eine Spezialität der Franzosen.--Löschfix 03:21, 24. Aug 2006 (CEST)

Sprachen auf der Navi-leiste (Interlanguage links)

Bitte für phab:T7231 (Bugzilla:5231) (Mouseover explanations for interlanguage
 links in native languages) stimmen(Abstimmhilfe).Danke

--:Bdk: 15:51, 11. Mär 2006 (CET)


Manchmal erscheinen auf der linken Navigationsleiste 30 o.ä.viel Sprachen und ich kann viele nicht zuordnen,z.B. eben Ban-lam-gu. Beim Aufrufen erkenne ich sie auch nicht weshalb ich es schön fände, wenn bei Cursorberührung diese in deutsch angezeigt würden.--82.82.237.157 20:53, 16. Mai 2005 (CEST) nachgetragen aus Wikipedia:Fragen zur Wikipedia von ElRakı ?! 01:14, 17. Mai 2005 (CEST)

Guter Vorschlag. Oder wenigstens eine schnelle und einfache Möglichkeit, die Sprache herauszufinden. - Martin Vogel 01:05, 18. Mai 2005 (CEST)
Schliesse mich an, das Problem habe ich auch immer wieder. ma(c|d)dog 17:02, 7. Aug 2005 (CEST)
Nette Idee. Aber was nutzt zu wissen wie eine Sprache heißt, wenn man sie sowieso nicht lesen kann? --the one who was addicted (#) 18:18, 11. Aug 2005 (CEST)
Erstens ist es gut für die Allgemeinbildung und zweitens sehr interessant. Ich frage mich auch meist, welche Sprache das ist. Um sie immer nachzugucken fehlt mir aber i.d.R. die Zeit. --M.A. (Marc-André Aßbrock) 16:17, 4. Jan 2006 (CET)
... du meinst doch auch die Sprachenleiste?, das solln sie doch, mit mouseover (oder wie das heißt) jetzt pro?--Kino 19:46, 1. Mär 2006 (CET)
Vier von 10 Personen haben sich für eine Reduktion auf 15 Sprachen ausgesprochen und das als Meinungsbild verkauft (das sind weniger als bei dieser Abstimmung). Ich hab kein Problem mit fremden Zeichen (sogar Fragezeichen kann man händeln.)++Scooterman 08:45, 2. Mär 2006 (CET)
Du meinst wohl die Links auf der Hauptseite ;-) Darum geht's hier aber doch gar nicht gezielt. --:Bdk: 14:35, 11. Mär 2006 (CET)

Checkboxen beim Wiederherstellen gelöschter Artikel

Ich fände es sinnvoll, in der Undelete-Ansicht die Features "Check all" bzw. "Uncheck all" hinzuzufügen. Im konkreten Fall hatte ich den Artikel Jena mit reichlich langer Versionsgeschichte gelöscht um eine frisch entdeckte URV-Einfügung zu entsorgen. Das manuelle Checken der einzelnen Versionen bei 350 Bearbeitungen des Artikels ist eine ziemlich unangenehme und stupide Angelegenheit. Alternativ könnte ich mir einen Button in der History vorstellen, mit dem einzelne Versionen gezielt (von Admins) gelöscht werden können. --Dundak ✍ 11:13, 15. Jun 2005 (CEST)

Siehe phab:T5098 (Bugzilla:3098). --:Bdk: 10:49, 13. Jan 2006 (CET)

Abschnittsweise Änderung:Erster Absatz

(von Wikipedia:Verbesserungsvorschläge hierher kopiert --G 12:14, 23. Jun 2005 (CEST))

Könnte man nicht die abschnittsweise Bearbeitung auch auf die Einleitung ausdehnen?--G 23:00, 2. Jun 2005 (CEST)

Dann würde der Bearbeiten-Button auch bei jedem Stub auftauchen und das Layout leidet darunter dann doch etwas unnötig. Solange das nur bei einer absoluten Minderzahl von etwas längeren Artikeln zum Problem wird, finde ich diesen Umstand noch erträglich (auch wenn es etwas aufwendiger ist sich den ganzen Artikel anzeigen zu lassen). --Saperaud ☺ 01:27, 4. Jun 2005 (CEST)
Es sollte kein großer Programmieraufwand sein den Bearbeiten-Link nur auf Artikeln mit mindestens 1 oder 2 anderen Überschriften (z.B. zusammen mit dem Erscheinen des Inhaltsverzeichnisses) erscheinen zu lassen.--G 11:16, 5. Jun 2005 (CEST)
  • Fände ich gut... --Benutzer:Rdb? 14:37, 23. Jun 2005 (CEST)
  • ich bin dafür --joni Δ, Jakov
  • ebenfalls dafür: manchmal gibt's nur in der Einleitung was zu verbessern, beschleunigt Laden, Ändern und Speichern. Feinschreiber ?+! 1. Jul 2005 07:07 (CEST)
  • Bin auf jeden Fall dafür, in manchen Browsern, denen die keine Artikel größer als 32 kB editieren können, kann mensch den ersten Abschnitt sonst ga rnicht bearbeiten. Das Layout-Argument empfinde ich als verschmerzbar. --Ixitixel 14:36, 11. Jul 2005 (CEST)
  • bin ich sehr dafür, bei den Ortsartikeln wäre beispielsweise die Combobox allein zu bearbeiten. --K@rl 09:22, 30. Jul 2005 (CEST)
  • bin auch dafür, der bearbeiten-Link für die Einleitung könnte direkt unter der Linie unter der Hauptüberschrift rechtsbündig stehen (dort wo auch "(Weitergeleitet von ..." oder "< ..." steht, auch in der Schriftgröße), so dass das Layout nicht gefährdet wird. - FWHS 13:02, 1. Aug 2005 (CEST)
  • Ich als ISDN-Nutzer bin auf jeden Fall dafür. Es ist echt übel, wenn man bei einem 10seitigen Artikel einen Typo in der Einleitung korrigieren will! --Flominator 10:38, 3. Sep 2005 (CEST)
    • Nachtrag: Mir ist neulich aufgefallen, dass das bereits geht, wenn man bei einem Bearbeiten-Link die Zahl am Ende durch eine 0 ersetzt. --Flominator 22:55, 2. Okt 2005 (CEST)
  • dto.Löschfix

Neuer Vorschlag, bei langen Seiten kommt es besonders häufig zu Bearbeitungskonflikten, wenn diese stark frequentiert ist, wie die Löschkandidatenseite z.B. Alles dauert ausserdem ewig. Wie wäre es bei abschnittsweiser Bearbeitung ein Popupfenster zu bemühen. Vorschau und Editor erscheinen in einem neuen Fenster. Man hätte weiter den Überblick auf die Gesamtseite und könnte parrallel weiterarbeiten.--Löschfix 19:45, 6. Nov 2005 (CET) Seitdem ich mit K-Meleon (1.0) arbeite (ein Mozilla-Derivat), bietet mir der Browser dieses Feature. re Maustaste - öffnen in neuem fenster, oder neuer Schicht, auch im Hintergrund etc.--Löschfix 02:45, 24. Aug 2006 (CEST)

  • Bin auch dafür. --Tlustulimu 22:21, 30. Jan 2006 (CET)
  • Dafür. Obwohl ich DSL hab. --Libro 20:36, 26. Feb 2006 (CET)

Rollback-Funktion nicht nur für Admins

Ich mache diesen Vorschlag gleichzeitig hier und bei WP:VV. Mir ist aufgefallen, daß die Rollback-Funktion keine typische Adminfunktion ist, weil sie dem Nutzer - platt gesprochen - nicht "mehr Macht" gibt, sondern nur eine Arbeitserleichterung ist. Jeder Nutzer kann jetzt schon genau das tun, was Rollback tut, mit entsprechendem Können sogar den Kommentar entsprechend imitieren, daß es aussieht, er wäre Admin. Es ist nur umständlich. Die Funktion ist eine Arbeitserleichterung, die ich auch Nutzern zugestehen würde, bei denen mir die anderen Admin-Rechte "zu heiß" wären. Deswegen schlage ich vor, die Rollback-Funktion aus dem "Admin-Paket" herauszunehmen und sie Nutzern auf andere Weise zugänglich zu machen - z.B. automatisch nach 1000 Edits.--Pangloss Diskussion 21:50, 11. Okt 2005 (CEST)

Dagegen: Die Rollback-Funktion bietet den Admins, also Benutzern, die von vielen anderen Benutzern als kompetent und vertrusnswürdig angesehen werden, einen deutlichen Vorteil, Vandalismus zu bekämpfen, da ein Rollback schneller geht als ein Vandalismusedit. Wenn man diese Funktion "freigeben" würde, wäre es nahezu unmöglich, Vandalismus schnell zu erkennen und in angemessener Zeit wieder rückgängig zu machen. 1000 Edits sind schnell gemacht, auch von Vandalen, und dann darfst du erstmal ne halbe Stunde lang Reverts reverten... Es ist ja nicht so, dass es keine Benutzer geben würde, denen diese Funktion durchaus anzuvertrauen wäre, das Problem sind die "anderen" Benutzer, die nicht vertrauenswürdig sind. --rdb? 22:26, 11. Okt 2005 (CEST)
Da bin ich völlig anderer Meinung. Wenn ein Vandale es schafft, 1000 Edits unter einer IP oder einem Nutzernamen hinzubekommen ohne gesperrt zu werden - wofür ich mal ein Beispiel einfordere - dann liefe doch etwas ganz anderes falsch. Warum es durch Freigeben dieser Funktion schwieriger oder gar "nahezu unmöglich" würde, Vandalismus zu erkennen, sehe ich auch nicht. Zu einem halbstündigen Schnell-Editwar dürfte es auch deswegen nicht kommen, weil Beteiligte immer die Möglichkeit haben, Admins zu bitten die Seite zu sperren. Ganz abgesehen davon, daß ich wie gesagt von vornherein nicht glaube, daß Vandalen zu dieser Funktion gelangen können.--Pangloss Diskussion 22:46, 11. Okt 2005 (CEST)
Siehe auch die entsprechende Diskussion auf Wikipedia-l: hier und hier (unten). --rdb? 12:07, 19. Okt 2005 (CEST)
Die Diskussion hate ich für ein Schattengefecht, da auch ein "normaler" User sich eine Rollbackfunktion über Skripte "besorgen" kann... --Badenserbub Briefkasten Bewerte mich! 20:57, 7. Nov. 2006 (CET)

Eigene Beiträge als Galerie-Seite auf Commons

Eigentlich ist das ein Vorschlag für die Commons,aber vielleicht findet sich hier jemand für die Umsetzung. Viele Leute habe in den Commons die nicht ganz unbegründete Befürchtung ihre eigenen Bilder dort nicht mehr wiederzufinden. Aus diesem Grunde wäre es gut, wenn dort der Link "Eigene Beiträge" (Seite Special:Contributions/user) nicht nur zu einer Text basierten Liste führen würde sondern es dort eine automatische Bildergalerie der eigenen Beiträge gäbe.

Eigentlich muß für die neue Specialseite nur die SpecialNewimages.php mit einem Select User gemäß der SpecialContributions.php versehen werden. Kolossos 23:36, 18. Okt 2005 (CEST)

Ist dank m:User:Duesentrieb/Gallery erledigt. Danke. Kolossos 21:15, 7. Jul 2006 (CEST)

Andere Linkfarbe für #-Links

Wenn man auf einer Seite interne links auf Abschnitte auf der gleichen Seite legt ([[Seite#Abschnitt]]), so erscheint der link in blau. Man denkt nun es handle sich um einen neuen Artikel, das ist ok wenn man direkt dorthin will, öffnet man die link aber in einem neuen Tab, so wird die ganze Seite neu geladen. Manchmal würde es helfen wenn man von vornhinhein weis wohin man gelangt. greetz vanGore 22:36, 15. Jan 2006 (CET)

Bin auch dafür. Wie wäre es mit einem grünen Link, oder gibt es den schon für irgend etwas anderes? --Tlustulimu 22:25, 30. Jan 2006 (CET)
Ich habe jetzt kein Interesse, das auszuprobieren, aber ich denke, das lässt sich auch in Javascript erledigen, das heißt, jeder kann die notwendigen Befehle in sein monobook.js einbauen. --Plenz 23:24, 30. Jan 2006 (CET)
Das lässt sich sogar schon mit CSS erledigen, wenn der Link/ Verweis korrekt gesetzt ist (also der eigene Seitenname ist notwendiger nicht enthalten).
a[href^="#"] { background-color:#EEB; font-weight:bold; } /* interner Verweis */
Ich glaube aber dies wird nur von neuen Browsern unterstützt. -- Ολλίμίνατορέ •Ω• 15:37, 26. Apr 2006 (CEST)

Das Leid mit den mehr-/einfachen Wikilinks

Aufgrund des Wikistyles hat sich (ästhetischerweise) durchgesetzt, jeweils nur das erste Auftauchen eines Fremdwortes zu verlinken. Beim Browsen größerer Artikel fällt mir ein Wort allerdings erst oft nach mehrmaligem Lesen auf, so dass ich darüber etwas erfahren möchte - ich weiß nicht, ob es vielleicht anderen ähnlich geht. Jetzt bleibt nur die Suche nach dem ersten Link oder die manuelle Eingabe, die bei längeren Wörtern auch unkomfortabel wird. Ich weiß nicht, ob es dafür überhaupt eine Lösung gibt, mein Vorschlag wäre, "stille" Links in die Software einzuführen, die ein einmal gelinktes Wort, das im gleichen Artikel mehrmals auftaucht, an allen anderen Stellen schwarz und ohne Unterschrift verlinkt (also im Textlayout). Ich weiß, dass es damit noch einige Probleme gibt (wie sieht es mit der Barrierefreiheit aus?), aber dennoch würde ich gern einmal eure Meinung zu dem Thema hören. Mich nervt es sehr, aber für wie sinnvoll würdet ihr eine solche Änderung erachten und habt ihr vielleicht andere Lösungen? Endymi0n 03:16, 25. Jan 2006 (CET) Bisher absichtlich ohne Abstimmung.

  • Ne geniale Idee. Mir geht es beim Lesen längerer Artikel oft genauso. Allerdings könnte die automatische Kontrolle auf eine evtl. vorhergehende Verlinkung desselben Wortes beim Mausklick auf nicht gelinkte Wörter eine ungeahnte Serverbelastung zur Folge haben. Eine manuelle Lösung im Edittext wie z.B. [[{Server}]] anstatt [[Server]] könnte ja einen unsichtbaren Link hervorrufen. Mir fällt da spontan nix ein, was dagegen spräche. Bundesstefan 04:37, 26. Apr 2006 (CEST)

-- Ολλίμίνατορέ •Ω• 13:44, 26. Apr 2006 (CEST)

Verwenden von HTTP-Cookies

Sollte die Wikipedia-Software nicht grundsätzlich versuchen ein HTTP-Cookie zu setzen ? Ganz besonders sind damit die nichtangemeldeten Benutzer gemeint. Vorteile:

  • wenn mehrere nichtangemeldete Benutzer eine IP-Adresse verwenden, kann man gezielt den einen Vandalen sperren
  • ein gesperrter Vandale würde auch dann erkannt werden, wenn er eine dynamische IP-Adresse benützt.

Nachteile:

  • Ein Benutzer kann das HTTP-Cookie im Browser ablehnen oder löschen, dann bleibt alles wie bisher auch.
  • die Cookies müssen in der Datenbank zumindest einige Wochen gespeichert bleiben
Kontra Damit würde man sich dann von der Wikipedia ausspioniert vorkommen, und paranoide Leute (wie ich) benutzen sowieso Firefox, um alle Cookies einfach anzeigen und gegebenenfalls löschen zu können. Ich denke, Tracking-Cookies an sich sind hart an der Grenze zum Illegalen, und die Wikipedia würde damit eher ihrem Ruf schaden, als dass es etwas bringt! --Gruß, Constructor
ack, ich lehne jedes Cooki ab, das geht auch mit IE.6. Tracking Cookis sind vor allem schlechter Stil, genau wie activeX. Allerdings, um mich als benutzer anzumelden und evtl. dauerhaft angemeldet zu sein, bedarf es ja doch eines Cookis.;-)--Löschfix 03:16, 24. Aug 2006 (CEST)

Variable CURRENTTIME (erl)

Sonntag
12
Mai
06:41 MESZ

Ich hätte gerne einer Möglichkeit mithilfe dieser oder einer anderen Variablen, die Zeit in MEZ bzw MESZ angezeigt zu bekommen. Ich habe nämlich ein ganz schlechtes Zeitgefühl und hätte gerne eine Vorlage wie {{Heute2}} (siehe rechts) in nicht verwirrender Form auf meiner Benutzerseite. Möglicherweise könnte man im selben Schritt auch für CURRENTDAY etc. etwas machen, so dass diese Variablen nicht mehr von 0 bis 2 Uhr nachts den falschen Tag anzeigen. Eine allgemeine Lösung wie {{CURRENTTIME|+2}} hätte den Vorteil auch für andere Zeitzonen anwendbar zu sein, die noch weiter von UTC entfernt sind. --schizoschaf 19:25, 22. Apr 2006 (CEST)

Mit CURRENTUSERTIME z.B. könnte die Einstellung des betrachtenden Benutzers benutzt werden. --schizoschaf 19:39, 22. Apr 2006 (CEST)
Eine alternative Lösung wäre, {{CURRENTHOUR}} und {{CURRENTMINUTE}} einzuführen. Dann kann man die neuen Parser-Funktionen zur Berechnung der korrekten Zeit und des korrekten Datums benutzen. -- sebmol ? ! 22:12, 22. Apr 2006 (CEST)
Ich habe die Vorlagen CURRENTHOUR und CURRENTMINUTE hinzugefügt. Diese geben die aktuelle Stunde und aktuelle Minute an und können zur Erzeugung einer Vorlage:LOCALHOUR und Vorlage:LOCALMINUTE benutzt werden. -- sebmol ? ! 10:24, 28. Apr 2006 (CEST)

Sortierbare Tabellen

In WP gibts viele Listen, manche als mehrdimensionale Tabellen. Meistens sind sie (sinnvollerweise) nach einer Spalte sortiert. Für unterschiedliche Sortierungen werden Tabellen oft mehrfach-redundant als zusätzliche Artikel gespeichert. Das ist schwer zu pflegen, und auch schwierig zu finden.

Lösung: in den Tabellenkopf ein Script einbauen, durch das der Leser die Tabelle per Klick auf eine Spaltenüberschrift nach dieser Spalte sortieren kann.

Dadurch könnten viele Listen/Tabellen normalisiert und Redundanz vermieden werden. Wer kann so was entwerfen und ggf. einbauen? Gruss, --Markus Bärlocher 23:08, 25. Okt. 2006 (CEST)

erledigt, Help:Sorting --Ikiwaner 21:02, 11. Jan. 2007 (CET)

includeonce-Tag

In einigen Vorlagen reichen die bisher verfügbaren Tags noinclude und includeonly nicht aus, denn sie erlauben grundsätzlich nur die Verwendung von Text und ähnlichem innerhalb bzw. außerhalb der jeweiligen Vorlage. Vorlagen, die der Wartung und/oder Bewertung von Vorlagen dienen, sollen aber nicht in Artikeln erscheinen, in denen die bewertete Vorlage eingebunden ist. Daher bedienen sich etwa die Vorlagen Vorlage:ZuKategorisieren Vorlage und Vorlage:Löschantrag Vorlage einer Verschachtelung von noinclude und includeonly. Diese ist allerdings sehr heikel und fehlerträchtig sowie weit vom Ziel eines "sauberen Codes" entfernt. Ich halte es daher für sinnvoll, ein includeonce-Tag einzuführen, dass bei der ersten Einbindung (auch per subst:) in ein noinclude überführt und somit bei Einbindungen in höhere Ebenen nicht berücksichtigt wird. --CyRoXX (?) 20:44, 7. Mai 2006 (CEST)

Alternativ könnte man die Vorlage:includeonce nehmen, die den konfus aussehenden Code verbirgt (diesmal auch durchgetestet, Bsp. Einbindung hier). -- Ολλίμίνατορέ 01:37, 17. Mai 2006 (CEST)
Ich wage dennoch zu bezweifeln, ob {{includeonce|Hier Quelltext der eigentlichen Vorlage}} eine bessere Lösung darstellt als das manuelle Einfügen in die jeweilige Vorlage. Die seltsame Verschachtelung wird zwar versteckt, aber der Quelltext bleibt ähnlich unübersichtlich. Ich schätze deine Mühe sehr; mein Hauptanliegen, das Problem der risikobehafteten noinclude- und includeonly-Verschachtelungen zu lösen, ist damit aber leider nicht vom Tisch. --CyRoXX (? ±) 15:07, 17. Mai 2006 (CEST)

Gelöschte Edits unter Spezial/Contributions mit anzeigen

Diese Funktion würde das Beurteilen eines Benutzers oder einer zur Sperrung vorgeschlagenen IP wesentlich erleichtern. Mülleinstell-Vandalen bleiben lange unendeckt, weil die Artikel sehr schnell weggelöscht werden und die IP deshalb "sauber" aussieht. --Fritz @ 12:49, 12. Mai 2006 (CEST)

  • Dagegen:


Siehe auch phab:T4699 (Bugzilla:2699), da tut sich allerdings schon länger nichts mehr. Viele Grüße Pill δ 00:08, 10. Aug 2006 (CEST)

Benutzeranmeldung endlich erschweren

Es ist ein unerträglicher Zustand, daß Vandalen im Sekundentakt Benutzeraccounts in vierstelliger Menge anlegen können (z.B. "Vandalismusaccount Nr.2123"), ohne daß dem auch nur das geringste technische Hindernis entgegensteht. Man kommt sich als Admin wirklich an der Nase herumgeführt vor, ganz davon abgesehen, daß es unnötigen Datenmüll erzeugt. Gibt es irgendeinen Grund, warum das Captcha-System, das z.B. in der sicher nicht von Vandalismus überfluteten afrikaansen Wikipedia angewendet wird [3], bei uns noch nicht im Einsatz ist? Oder warum nicht, wie bei jedem billigen Plauderforum, eine E-Mail-Adresse gefordert wird? Oder warum die IP nach einer Benutzersperrung nicht ebenflls für eine Weile gesperrt ist? Man kann es mit dem offenen System auch übertreiben. Lieber sollen IPs vandalieren als angemeldete Benutzer, das macht nämlich weniger Arbeit und fällt schneller auf. --Fritz @ 01:53, 7. Aug 2006 (CEST)

So schnell geht die Account-Anlage nun auch nicht. Das einzig probate Mittel, um so etwas effektiv zu verhindern, ist, wie von dir angesprochen, die automatische Sperrung der IP des gesperrte Benutzers. Das ist auch bereits vorgeschlagen, siehe phab:T8931 (Bugzilla:6931), ich hab heute auch einmal im Chat nachgefragt, da zeigte man sich von Seiten der Entwickler dem durchaus nicht abgeneigt. Viele Grüße Pill δ 00:05, 10. Aug 2006 (CEST)

Hat sich durch die Aktivierung von Captcha vorerst erledigt. Die fehlende IP-Sperre ist ein bekannter Bug, der hoffentlich bald behoben ist. --Fritz @ 09:15, 11. Aug 2006 (CEST)

Seitensperren auf bestimmte IP-Ranges oder Benutzer begrenzen

Ich weiß, das ist keine Kleinigkeit, aber eine solche Sperrmöglichkeit würde verhindern, daß einzelne Trolle oder Vandalen die Administratoren dazu zwingen, Artikel oder ganze Gruppen von Artikeln halbzusperren. Und wenn man schon dabei ist, könnte man auch eine Sperre für bestimmte Benutzer einbauen, denn es kommt immer wieder vor, daß ein Benutzer in einem bestimmten Bereich ein Störfaktor ist, in anderen Bereichen aber sinnvoll mitarbeitet (und/oder einen großen Unterstützerkreis hat), so daß eine Benutzersperrung ausscheidet. Auch Editwars zwischen zwei Benutzern könnten dann unterbunden werden, ohne daß eine Vollsperrung notwendig wird.

Ich habe mich mit den Details der Wikisoftware noch nicht beschäftigt, aber ich würde es (auch im Sperrdialog) als Textfeld implementieren, das z.B. folgenden Inhalt hat:

217.224.192.0/18, Troll1, Editwarrior2

--Fritz @ 15:06, 26. Okt. 2006 (CEST)

  • Dagegen:

Flags in Versionen setzen und danach Kategorisieren

Darauf gebracht hat mich ein Beitrag in dem gemutmaßt wurde, dass einige Admins erheblich kürzen, löschen und bearbeiten, nur um die Wikipedia für die Buchform geeignet zu machen. Mein Vorschlag würde aber weitaus mehr Probleme lösen.

Die Idee ist, ähnlich einer Bewertung in gut und schlecht, Flags für verschiedene Kategorien einzuführen - im genannten Fall z. B. "druckbar" o. ä. für Artikelversionen die gecheckt und passend formatiert wurden. Wenn jemand damit fertig ist, kann er den Artikel wieder zurücksetzen, wodurch der aktuelle Text automatisch das Attribut verliert, und beim Ausdrucken mit einem entsprechenden Filter erscheint die letzte "druckbare" Version. Die Attribute könnten in der Versionsliste ähnlich wie Dateiattribute unter Linux bei Bedarf angezeigt werden, und zur Maskierung genutzt werden.

Einige Buttons um die entsprechenden Flags zu setzen könnten allen zur Verfügung stehen (z. B. Bewertung), andere nur Admins o. ä.

Flags sollten auch als Kategorien genutzt werden können, um entsprechende Artikel auflisten zu können (nur "sehr gute" Artikel-Versionen z. B.). Es könnte auch für nicht-Admins normalerweise unsichtbare Flags geben, um z. B. Artikel mit umstrittenen Inhalten zu markieren ohne die Autoren sofort vor den Kopf zu stoßen.

Vorteil gegenüber momentanen Kategorien ist, dass die Flags nur Versionen betreffen und nicht direkt im Artikel stehen. Ein weiterer Vorteil ist, dass vielleicht etwas weniger gelöscht oder in anderer Weise demotiviert wird. Ein entscheidender Vorteil ist m. E., dass man die Wiki standardmäßig so einstellen kann, dass unerfahrene Gelegenheits-User nur freigegebene Versionen sehen, außer sie schalten den Filter ab (sollte mit einem Klick auf einen Button Namens "Vorselektiert an/aus" o. ä. möglich sein). Dadurch, dass Autoren je nach Ansehen (Verweildauer, Artikelzahl...) unterschiedlichen Zugriff auf die Flags haben (Anonyme User (fast) gar keinen) ließe sich sichtbarer Spam leicht auf nahezu null reduzieren, und dadurch auch der Anreiz, zu vandalisieren.

Die Änderung sollte nicht sehr aufwändig sein, betrifft aber wohl auch den Quelltext der Wiki.

Einziges größeres Problem ist m. E. eventuelles Ignorieren nicht-bewerteter Versionen durch einige Autoren, aber das lässt sich mit einem Vergleichsprogramm ähnlich dem bei Bearbeitungskonflikten lösen (vorzugsweise etwas komfortabler, und eventuell schon wenn man mit dem Editieren anfängt).

--MfG Carl_de 13:00, 8. Nov. 2006 (CET)

  • Dafür:
  • Dagegen:

Von den Admins hier realisierbar

Bei Bild-Einfüge-Button Thumbs benutzen

Eigentlich eine Kleinigkeit, wenn man beim Editieren den Bild-Einfüge-Button drückt soll statt [[Bild:Beispiel.jpg]] dieses [[Bild:Beispiel.jpg|thumb]] erscheinen ich denke mal dass macht im Zeitalter der Megapixel-Bilder Sinn. Kolossos 18:51, 4. Feb 2006 (CET)

Dafür:

Dagegen

Quellenangaben

Quellenangaben: äußere Form, Schriftsatz

Index im Text nicht hochstellen ?

Durch die manchmal notwendigen hochgestellten Quellenangaben (zB Sexueller Missbrauch von Jugendlichen#Republik Österreich oder Roland Werner) werden die Zeilen auseinandergerissen und das Schriftbild unruhig. Das Lesen des Textes fällt schwerer und einzeilige Zwischenräume (Absätze) sind auch nur mehr schwer erkennbar. Mir fällt kein Argument ein, warum es auch nicht im Textfluß stehen kann. (Ausser, dass es halt im Buchdruck so gemacht wird) --Fg68at Disk 21:05, 27. Apr 2006 (CEST)

  • Zusatz: Man könnte es ja auch nur small machen. Oder wie die alte Vorlage:Ref darstellen
  • Zusatz: Aus der Diskusssion und aus eigenen Versuchen (WinXP) ergibt sich:
  1. Das Problem ist im Opera am größten
  2. Im IE ist das Problem bemerkbar
  3. Im Firefox fällt es so gut wie nicht auf

Zusatz: Nachfolgend 4 Muster zur Anschauung


Derzeit: Der Gesetzgeber ging bei der Schaffung des § 207b davon aus, dass die sexuelle Selbstbestimmungsfähigkeit mit Vollendung des 14. Lebensjahres grundsätzlich gegeben ist und die neue Bestimmung nur Fälle erfasst, in denen diese Fähigkeit aus besonderen Gründen ausnahmsweise fehlt bzw. deutlich eingeschränkt ist.[1]Allen Fällen des § 207b ist gemeinsam, dass sie Situationen im Auge haben, in denen es dem Jugendlichen unmöglich gemacht oder erheblich erschwert wird, sein sexuelles Selbstbestimmungsrecht dahin auszuüben, daß er einen von ihm nicht gewünschten Sexualkontakt (mit Erfolg) ablehnt.



Klein: Der Gesetzgeber ging bei der Schaffung des § 207b davon aus, dass die sexuelle Selbstbestimmungsfähigkeit mit Vollendung des 14. Lebensjahres grundsätzlich gegeben ist und die neue Bestimmung nur Fälle erfasst, in denen diese Fähigkeit aus besonderen Gründen ausnahmsweise fehlt bzw. deutlich eingeschränkt ist. [1] Allen Fällen des § 207b ist gemeinsam, dass sie Situationen im Auge haben, in denen es dem Jugendlichen unmöglich gemacht oder erheblich erschwert wird, sein sexuelles Selbstbestimmungsrecht dahin auszuüben, daß er einen von ihm nicht gewünschten Sexualkontakt (mit Erfolg) ablehnt.----



Normal: Der Gesetzgeber ging bei der Schaffung des § 207b davon aus, dass die sexuelle Selbstbestimmungsfähigkeit mit Vollendung des 14. Lebensjahres grundsätzlich gegeben ist und die neue Bestimmung nur Fälle erfasst, in denen diese Fähigkeit aus besonderen Gründen ausnahmsweise fehlt bzw. deutlich eingeschränkt ist. [1] Allen Fällen des § 207b ist gemeinsam, dass sie Situationen im Auge haben, in denen es dem Jugendlichen unmöglich gemacht oder erheblich erschwert wird, sein sexuelles Selbstbestimmungsrecht dahin auszuüben, daß er einen von ihm nicht gewünschten Sexualkontakt (mit Erfolg) ablehnt.----



Altes Ref: Der Gesetzgeber ging bei der Schaffung des § 207b davon aus, dass die sexuelle Selbstbestimmungsfähigkeit mit Vollendung des 14. Lebensjahres grundsätzlich gegeben ist und die neue Bestimmung nur Fälle erfasst, in denen diese Fähigkeit aus besonderen Gründen ausnahmsweise fehlt bzw. deutlich eingeschränkt ist. Vorlage:Ref Allen Fällen des § 207b ist gemeinsam, dass sie Situationen im Auge haben, in denen es dem Jugendlichen unmöglich gemacht oder erheblich erschwert wird, sein sexuelles Selbstbestimmungsrecht dahin auszuüben, daß er einen von ihm nicht gewünschten Sexualkontakt (mit Erfolg) ablehnt.----


  1. ↑ Test
  • Für Variante 1: hochgestellte Indizes (also wie gehabt):
    • behindert (erg.v.Wikipit: nicht) den lesefluß und das ist mir wichtiger als eine zeile etwas mehr abstand der mir ehrlich gesagt nur auffällt ich ich darauf achte ...Sicherlich Post 08:20, 29. Apr 2006 (CEST)
    • Bin auch gegen eine Änderung, das heisst für Hochstellen! "Small" sieht bei mir wie runtergestellt aus. Da erkennt man gar nichts mehr. Im Schriftfluß gleich grosse Indizes gibts auch, besonders in der angloamerikanischen Literatur, nur übersieht man dann bei gezielter Suche diese Indizes. --Wikipit 09:00, 30. Apr 2006 (CEST)
    • Die angeführten Probleme sind für mich nicht nachvollziehbar. Ein Vorteil hochgestellter Indizes ist, dass sie das Auffinden der referenzierten Stellen erleichtern (z.B. auf einem sw-Ausdruck bei dem die farblliche Markierung verloren geht). Eine einfachere Möglichkeit im Falle ersteren Artikels wäre übrigens die Zusammenfassung der 4 identischen Referenzen in 4 aufeinanderfolgenden Sätzen zu einer (gemeint ist Endnote 1).--Gurgelgonzo 09:27, 30. Apr 2006 (CEST)
  • Für Variante 2: Normalgroße Indizes:
  • ist in manchen Fachzeitschriften durchaus Gepflogenheit. Pro -Hati 10:42, 30. Apr 2006 (CEST)
  • Für Variante 3: Kleine Indizes::
Zeilenabstand im Text vergrößern ?
  • Generell den Zeilenabstand so vergrößern, dass Platz für die hochgestellten Angaben da ist, ob sie vorhanden sind oder nicht. Das würde bedeuten, dass der Abstand zwischen Absätzen ebenfalls größer werden müsste.--Bhuck 08:13, 28. Apr 2006 (CEST)
Gibt es HTML-Code, der das leicht bewerkstelligen läßt, un der von allen relevanten Browsern verstanden wird? --Fg68at Disk 18:50, 28. Apr 2006 (CEST)
Wenn man sich mal ansieht was den Quellenangaben für ein Stellenwert zugewiesen wird ("braucht man nicht"; "verwenden bei Zahlenangaben zu Statistiken"), ist das Wurst. Die paar Artikel, die einem begegnen, die verschmerzt man auch mit vermurksten Zeilenabständen. Solang hier keinerlei Bewußtsein für eine saubere wenigstens annähernd wissenschaftliche Arbeit herrscht, sollte man derlei Marginalien vergessen. Das klingt nicht zynisch, das ist mein Ernst. --Henriette 06:54, 29. Apr 2006 (CEST)
Soll ich und auch so werden? :-) --Fg68at Disk 09:18, 29. Apr 2006 (CEST)
  • Ich bin auch für vergrößerten Zeilenabstand. Das lässt sich mit dem CSS-Format line-height eigentlich recht leicht einstellen. Wer in seine Benutzer:BENUTZERNAME/monobook.css 
    p { line-height:200%; margin-top:1.2em; }
    schreibt sieht, wie es aussehen könnte. Die Angaben erhöhen den Zeilen- und Absatzabstand bei mir (FF 1.5 und Konqueror 3.14 @ Suse 9.0/KDE) gerade soviel wie nötig und machen den übrigen Text nach kurzer Eingewöhnung auch angehemer zu lesen. Damit der Zeilenabstand auch bei Listen gleich ist könnte man noch 
    ol,ul,li,dl,dt,dd { line-height:200%; }
    notieren. Den CSS 1.0-Code dürfte jeder gebräuchliche Browser verstehen (selfHTML nennt IE 3.0, FF 1.0, Opera 5.12, NN 4.0, Safari 1.0 und Konquerer 3.1 als früheste Versionen), ich werd das aber zumindest im IE 5 und 6 auf Windows 98 bzw. 2000 nochmal kontrollieren. Dann müsste man das im Grunde nur in die MediaWiki:Common.css schreiben und fertig - natürlich sofern es denn erwünscht ist. @Henriette: Ja, zZ verschmerzt man die unterschiedlichen Zeilenhöhen, weil es wenige Artikel nutzen, aber es sollen ja mehr Artikel werden! Vielleicht können wir so schon ein Argument der Gegner der Quellenangabe (denkbar wäre "das vergößert aber den Zeilenabstand und das sieht nicht schön aus") ausschalten und so die Benutzung der Quellenangeben fördern? ••• ?! 13:22, 29. Apr 2006 (CEST)
Ich habe nur die erste CSS-Zeile ausprobiert. Also mit Opera v8.5 / Build 7700 / Windows XP macht er zwar den doppelten Zeilenabstand, dort wo hochgestellte Zeichen vorkommen macht er die Zeilen aber trotzdem nochmals weiter auseinander, obwohl genügend Platz wäre um dies nicht tun zu müssen. Im IE 6.0.2900 dasselbe in grün nur nicht so stark bemerkbar. Der Firefox 1.0.7 macht es von vornherein gut und auch mit den 200% macht er die Zeilenabstände gleichmäßig. (Will aber nicht umsteigen. :-( ) --Fg68at Disk 20:53, 29. Apr 2006 (CEST)
  • Fußnotenzeichen hochgestellt und trotzdem normaler Zeilenabstand. Alles andere ist typografischer Murks und sollte auch bei vernünftig gesetzten (gedruckten) Texten nicht vorkommen. Dass es geht, zeigte doch die Vorlage:Ref mit leicht verkleinerter und nach oben gerückter Ziffer, erst seit der Umstellung auf die neuen ref-tags gibt es den übergroßen Zeilenabstand (zumindest bei Opera 8.54/Win; bei IE6 kaum merklich). Also könnte man doch den Code aus der veralteten Vorlage übernehmen und eventuell anpassen. -- Arcturus 11:42, 30. Apr 2006 (CEST)
"Fußnotenzeichen hochgestellt und trotzdem normaler Zeilenabstand. Alles andere ist typografischer Murks und sollte auch bei vernünftig gesetzten (gedruckten) Texten nicht vorkommen." schreibst du. Tja und was ist nun "normaler Zeilenabstand."? Also ich hab gelernt, dass der normale Zeilenabstand im Druck klassisch bei 120% liegt (100% entspricht der Schriftgröße) und so sind die Standardeinstellungen bei Word und auch professioneller Satzsoftware. Bei Fließtext muss die Zeilenhöhe jedoch erhöht werden, um flüssiges Lesen zu erleichtern (hat was mit dem Gesetz der Nähe zu tun), was im Druck zu Zeilenabständen 130 bis 140% führt, bei Sachbüchern und wissenschaftlichen Texten liegt der Zeilenabstand bei bis zu 180%. Im Web sind generell größere Zeilenabstände üblich (verschiedene Richtlinien sagen 130 bis 140%, 140%, 160%, 130 bis 160%). Am Bildschirm ist also etwas zwischen 130 bis 160% "normal". Und am Bildschirm gilt für wissenschaftliche Texte, was auch schon beim Print galt: Ein größerer Zeilenabstand macht's leserlicher. In unserer monobook.css ist 1.5em (also 150%) notiert - ein heraufsetzen auf 180 oder 200% wäre durchaus kein "typografischer Murks" (Encarta hat z.B. 190% für den Artikeltexte) sondern nur lesefreundlich. Wer den Firefox nutzt, soll einfach mal die oben genannten CSS-Zeilen in seine CSS schreiben und es mal ein paar Stunden ausprobieren (nicht nur 5 Minuten, ein bisschen braucht man um sich dran zu gewöhnen) und am besten einen etwas längeren Artikel lesen. Ob und wie sich das in anderen Browsern erreichen lässt, kann ich zZ noch nicht sagen, aber es gibt sicher Möglichkeiten wenn sich dafür eine Mehrheit findet - unabhängig davon wie das mit den Fußnoten geregelt wird. gruß ••• ?! 15:34, 30. Apr 2006 (CEST)
Mit normalem Zeilenabstand meine ich den den Abstand zwischen den Zeilen innerhalb eines Absatzes. Ob das nun 100 oder 140 % sind, ist erstmal egal, solange es einheitlich ist. Das ref-tag erzeugt nun aber zur darüberliegenden Zeile immer einen zusätzlichen Abstand, täuscht (zumindest bei Opera) einen Absatz vor und das ist der Murks. Denn ein Fußnotenzeichen soll doch nicht den Text optisch gliedern wie ein Absatz das tut. Im Duden-pdf zur Textverarbeitung ist das nicht so und z.B. bei TeX standardmäßig auch nicht. Wäre mir auch alles egal, wenn es sich nicht gegenüber der alten Lösung (Vorlage:Ref) verschlechtert hätte. Da war es nämlich optisch noch ok. -- Arcturus 17:48, 30. Apr 2006 (CEST)
Ok, dann sind wir uns da ja zumindest einig. Denn dass die Fußnoten zu größeren Zeilenabständen als im übrigen Text finden wohl alle unschön. Es gibt generell zwei Möglichkeiten: Entweder man stellt die Fußnoten nicht hoch ([1]) bzw. zeichnet sie mit <small></small> mit kleinerer Schriftgröße aus ([1]) oder man erhöht die generelle Zeilenhöhe, so dass die hochgestellten Fußnoten die Zeilen nicht erhöhen müssen. Letzteres scheint leider nur im Firefox wie gewünscht zu funktionieren, hätte aber zwei weitere Vorteile: 1. oben ausgeführte bessere Lesbarkeit und 2. gibt es ja abgesehen von Fußnoten weitere hochgestellte Zeichen (km2 und div. TeX/<math></math>-Kram). gruß ••• ?! 21:55, 30. Apr 2006 (CEST)

Artikel kopieren

Es sollte eine Funktion geben, mit der man einen Kartikel mitsamt Versionsgeschichte kopieren kann. Es sollte so ähnlich funktionieren wie die Verschieben-Funktion, nur das der Orginalartikel dabei erhalten bleibt. Dies wäre zum Beispiel nützlich, wenn ein Artikel in mehere Artikel aufgeteilt werden soll, da so bei allen Artikel die Versionsgeschichte erhalten bleibt. -- Timo Müller 21:09, 10. Aug 2005 (CEST)

Ideal wäre es, wenn man beim kopieren gleich Teile löschen kann und dabei die Versionsgeschichte nur der erhalten gebliebenen Teile berechnet würde. Dies wäre dann auch hilfreich, um Absätze mit URV aus der Versionsgeschichte von Artikeln zu löschen.
Beim Verschieben bleibt doch der alte erstmal erhalten?!? -- Ολλίμίνατορέ •Ω• 15:57, 7. Apr 2006 (CEST)
Nö, nur als Redirect mit dem Verschiebungshinweis am Anfang der Versionsgeschichte.--Hannes2 Diskussion  09:25, 8. Apr 2006 (CEST)

Artikel in einen anderen Artikel einfügen

Ebenso sollte es eine Funktion geben, mit der man einen Artikel mitsamt Versionsgeschichte (in geeigneter Weise) in einen anderen Artikel einfügen kann. Damit wäre eine dokumentierte Versionsgeschichte beim Zusammenfassen von Artikeln gewährleistet.-- StefanL 20:45, 12. Aug 2005 (CEST)

Gibt es scheinbar schon, aber ich glaube, das können nur Admins (Siehe Wikipedia:Artikel verschieben#Kopieren&Einfügen-Änderungen reparieren). -- Timo Müller 15:34, 13. Aug 2005 (CEST)
  • Das Verschmelzen zweier Artikel kann nicht wieder rückgängig gemacht werden, mit der Funktion kann zu viel Unfug betrieben werden, daher sinnvollerweise nur Admins zugänglich. --:Bdk: 18:58, 19. Okt 2005 (CEST)

Üblicherweise werden Artikel zusammengefügt und der dann leere Restartikel/redirect behält seine Versionsgeschichte. Nur dort ist sie noch vorhanden, die Versionsgeschichte des weitergeführten Artikels bleibt unvollständig. Meiner Meinung nach ist die einzige saubere, rechtlich einwandfreie und auch nachvollziehbare und revertierbare Lösung, die Zuordnungsmöglichkeit mehrerer unabhängiger Versionsgeschichten zu einem Artikel. Idealerweise als verzweigte Versionsgeschichte dargestellt, ansonsten parallel. --Diwas 23:52, 26. Dez. 2006 (CET)

  • dafür:
  • dagegen:

Tastaturkuerzel fuer das Feld "Suche"

Hi! Bei dict.leo.org gibt es das praktische Alt+q um schnell in das Suchfeld zu gelangen. Bei der wikipedia vermisse ich sowas momentan. Waere sowas nicht vielleicht sinnvoll? -- 64.199.37.154 22:50, 17. Aug 2005 (CEST)

wieso soll alt+q besser als alt+f sein? --joni (Δisκussion) 09:34, 18. Aug 2005 (CEST)
weil alt+f in der seite sucht und nicht in das suchfeld springt. --63.255.226.114 14:43, 18. Aug 2005 (CEST)
bei mir schon. ich habe den internet explorer, bei dem strg+f für suchen auf der aktuellen seite steht. das behandelt dein browser wohl nur schlecht. --joni (Δisκussion) 14:49, 18. Aug 2005 (CEST)
wir reden aneinander vorbei? Ich meine mit Suchfeld das "Suchen nach Artikel" (also die Wikipedia-Funktionalitaet und nicht die Browser-Funktionalitaet) und nicht das "Suchen in der Seite". --64.199.37.154
das weiß ich schon, dass du das meinst. und dafür ist bereits alt+f festgelegt. wenn dein browser selbst jedoch alt+f schon vergeben hat für »suchen in dieser seite«, musst du sehen, ob du es vom browser her umstellen kannst, oder du hast mit dem browser dann einfach pech. alt+q ist im übrigen schon für »Spezial:Specialpages« vergeben. --joni (Δisκussion) 18:34, 18. Aug 2005 (CEST)
you made my day! alt+f, nicht strg+f! tut eh alles so wie es sein sollte! --64.199.37.154
Gibt es irgendwo eine Liste, wo diese Wikipedia-Hotkeys aufgelistet sind, oder muss die jeder selber durchprobieren? FWHS 15:32, 22. Aug 2005 (CEST)
Wikipedia:Tastaturkombinationen --M.A. (Marc-André Aßbrock) 17:39, 22. Mär 2006 (CET)

TEX PNGs

Hallo, ist es nicht vielleicht möglich die PNGs welche per TEX generiert werden, mit transparenten Hintergrund und bei bedarf in höherer Auflösung auszugeben? -- Stefan-Xp

Welchen Anwendungsbereich stellst du dir vor und wie könnte man sich den Syntax vorstellen? Zudem halte ich SVG für verbreiteter in den Anwendungen und kann ggf. auch browserseitig angezeigt werden. Kolossos 12:25, 28. Aug 2005 (CEST)
Ich denke, dass es auf jeden Fall auf Farbigen Untergrund wesentlich besser aussehen würde, und die Größere Auflösung wäre nützlich um bestimmte Formeln auch etwas größer ausdrucken zu können... SVG finde ich gut, das is ja vektorbasiert ;-) aber ich fürchte das wäre wesentlich aufwändiger. Was den Syntax angeht, hab ich davon leider keine Ahnung... --Stefan-Xp 13:12, 28. Aug 2005 (CEST)
Bei Syntax ist wohl die Wiki-Eingabesyntax gemeint? Da TeX-Formeln mit einem Pseudo-HTML-Tag markiert werden, würde es sich hier anbieten, Pseudo-HTML-Attribute zu verwenden, z.B. <math resolution="high">a^2+b^2=c^2</math>. SVG statt PNG könnte man als Option in den Benutzereinstellungen angeben (schließlich kann nicht jeder Browser SVG). Transparenter Hintergrund könnte m.E. standardmäßig produziert werden, wer unbedingt auf einem nicht-weißen Hintergrund eine weiß hinterlegte Formel will, kann ja <div style="background:white"> verwenden. --Ce 21:47, 19. Sep 2005 (CEST)
Das selbe „Problem“ gibt es auch mit den softwaregenerierten Hieroglyphen. Ein guter Grund, die Hintergrundfarbe festzulegen ist allerdings, dass ja auch die Vordergrundfarbe (schwarz) festgelegt ist, sonst würde es bei dunklen Hintergründen zu Problemen kommen: [4] -- Schnargel 03:21, 4. Nov 2005 (CET)
Ihr wißt das SVG jetzt halbwegs läuft?Kolossos 17:14, 4. Nov 2005 (CET)
Könnte man nicht auch diese Tabellen bei den Hieroglyphen mal überarbeiten bzw. gleich ersetzen. --ChristianErtl 15:46, 11. Nov 2005 (CET)

SVG bei TeX-Formeln wäre sinnvoll. Die Computer-Modern-Schriftarten wären dabei zu vektorisieren. Urheberrechtlich ist das unbedenklich, da die einzige Einschränkung für die Computer-Modern-Schriftarten ist, dass veränderte Versionen unter anderem Namen veröffentlicht werden. --Phrood 01:34, 7. Aug 2006 (CEST)

Vereinfachung der Löschanträge

Ich habe jetzt nicht so ganz den Überblick, ob der User, der den Vorschlag auf der Löschkandidatenseite gemacht hat, jetzt den Weg hierhergefunden hat oder nicht, aber mir scheint, dass nicht. Also: Dieser User beklagte, dass auf der Löschkandidatenseite in der Betreffzeile der Text nicht automatisch zum Link wird, sondern dass man dies immer von Hand machen muss (ist tatsächlich lästig). Noch bequemer wäre es, wenn das Einsetzen des Löschantragsbausteins in den Artikel automatisch dazu führen würde, dass der Artikel auf der Löschkandidatenseite verlinkt wird, wie das ja auch bei den SLAs der Fall ist. Allerdings müsste das wohl zwingend mit dem Verfassen einer Begründung für den LA gekoppelt werden, sonst wird die womöglich vergessen. --Xocolatl 13:00, 25. Sep 2005 (CEST)

Ist vieleicht lästig, aber lohnt meiner Meinung nach nicht den Aufwand, dafür extra die Software zu ändern. -- Timo Müller Diskussion 18:04, 25. Sep 2005 (CEST)
Also ich wäre sehr dafür. Momentan hält mich das dvon ab, überhaupt LA zu stellen, der Aufwand ist mir einfach zu groß. Bei URV gilt das ja genauso. Das hab ich einmal gemacht, und fand es ausgesprochen nervig. Ich weiß auch gar nicht wqarum das nicht konsequent umgesetzt wurde. dafür --Sarkana 21:03, 25. Sep 2005 (CEST)
Warum das nicht konsequent umgesetzt wurde: Weil man dafür extra die Software ändern müsste. -- Timo Müller Diskussion 19:06, 26. Sep 2005 (CEST)

1. dafür. 2. Wenn man dies für Löschanträge macht, sollte es auch für QS- und Redundanzeinträge geschehen. 84.162.54.117 dafür. Aber man sollte besser die edits erleichtern, als die LAs.--Löschfix 00:27, 26. Aug 2006 (CEST)

Wenn das einfach und schnell zu richten ist, dafür, ist nämlich wirklich lästig. Aber größerer Aufwand, der dann wohl nötig wäre, ist nicht gerechtfertigt. --Hannes2 Diskussion  09:13, 26. Aug 2006 (CEST)

Weitere Auswahlmöglichkein unter "Zufälliger Artikel"

Wäre es möglich, eine weitere Auswahlmöglichkeit unter den Link "Zufälliger Artikel" einzubinden, in der man auswählen kann, in welcher Kategorie der zufällig ausgewählte Artikel liegen soll (z.B. Computertechnik, Natur,... oder eben von allen Artikel)? Somit ist die Wahrscheinlichkeit höher, dass einen der zufällig ausgewählte Artikel auch wirklich interessiert. Ich dachte dabei an eine Auswahlmöglichkeit nach dem Beispiel von dieser Seite: http://de.wikipedia.org/wiki/Kategorie:%21Hauptkategorie

Also was haltet Ihr davon?

Dafür: --Pelz 23:38, 2. Dez 2005 (CET), -- Matt1971 ♪♫♪ 23:43, 27. Aug 2006 (CEST), Royd

Dagegen:

Hinweis auf gelöschte Versionen bei Neuanlage eines Artikels

Seit kurzem wird bei den gelöschten Arikeln die Versionsgeschichte nicht mehr angezeigt, ebenso die Anzahl der gelöschten Versionen (die Gründe sind einleuchtend). Damit entfällt aber auch bei einer Neuanlage eines Artikels der Hinweis an den Autor, dass dieses Lemma bereits einmal gelöscht wurde (woraufhin er sich vielleicht die Löschdiskussion angeschaut und es sich noch einmal anders überlegt hätte).

Daher schlage ich vor, dass bei der Neuanlage eines bereits früher gelöschten Artikels oben auf der Bearbeiten-Seite ein entsprechender Hinweis gegeben wird, wie etwa "Dieser Artikel wurde schon einmal gelöscht." oder ähnlich, vielleicht mit Hinweis auf das Lösch-Logbuch.

Gruß, mst 14:14, 4. Jan 2006 (CET)

Das wäre natürlich praktisch. Man könnte auch auf die Funktion Links auf diese Seite verweisen, bei gelöschten Artikeln dürfte die nicht viel mehr als die Löschdiskussion bringen. --ChristianErtl 18:42, 26. Jan 2006 (CET)
Dafür: ChristianErtl; --Pelz 22:01, 26. Jan 2006 (CET)
Dagegen:

Spoiler

Es tauchen immer mehr Artikel auf, die in einer Enzoklopädie nichts zu suchen haben, die ich aber teileise auch nicht missen möchte. Z. B. Filmbeschreibungen. Was aber besonders ärgerlich ist, ist, wenn man sich nur über den Film informieren will, bzw durch einen Querverweis draufgestoßen ist und dann das "überraschende" Ende liest. Wenn solche Artkel schon nicht mehr wegzudenken sind, kann man wenigstens in den Artikeln Spoilern?

Siehe Wikipedia:Spoilerwarnung. Betrifft außerdem wohl nicht die Software. --mst 18:01, 10. Feb 2006 (CET)
In einer Enzyklopädie ist eine vollständige Beschreibung zu erwarten, eine Warnung ist schlicht totaler Schwachsinn. --ChristianErtl 04:04, 12. Feb 2006 (CET)
Dafür: Benutzer:Currywurst Benutzer:84.58.132.80
Dagegen: ChristianErtl

Kategorien als Pfad

1. Anzeige im Artikel:
Hallo, die Kategorisierung von Wikipedia-Artikeln ist ja schon recht ordentlich, aber unübersichtlich. Kann man den Kategorie-Pfad komplett darstellen? Realisierung als zuschaltbares Feature wäre am besten. Bei Mehrfachzuordnungen müßten dann entsprechend viele Zeilen dazukommen. Die Linien und Pfeile müssten natürlich schicker werden, wenn man nicht alles mit den Kategorienamen zutexten will. Beispiel Berliner Urstromtal: 

!Hauptkategorie < Räumliche_Zuordnung < Europa < Land_in_Europa < Deutschland < Berlin
!Hauptkategorie < Geowissenschaft < Geographie < Geographie_(Europa) < Geographie_(Deutschland) < Geographie_(Brandenburg) 
                                 |                                               |< Gewässer_in_Deutschland < Gewässer_in_Berlin
                                 |< Hydrologie <---------------------- Gewässer -'  (ist hier wohl verkehrt...)
                                 '< Geologie <------------------------ Glaziologie  (Kategorie ergänzen...)

2. Als Fernziel:
Wenn jetzt der ganze Pfad zum Artikel gehört, könnte man dann auf die Tausende von Kategorie:Dings_(in_Bums) verzichten?
--Geofriese 12:49, 9. Feb 2006 (CET)

In manchen (seltenen) Fällen wäre zwar eine Pfadinformation hilfreich, aber der vollständige Pfad wäre viel zu unübersichtlich. Die Darstellung kann mehrere Seiten lang werden. Es gibt seit seit einigen Tagen ein Tool von Benutzer:Kolossos, das diese Pfade zu einem Artikel auflisten kann. Auf meiner Diskussionsseite findet sich ein Link zu einem abschreckendes Beispiel (Scan der Pfade für Baureihe 55).-- StefanL 00:10, 10. Feb 2006 (CET)
IMHO wird die Kategorisierung sowieso völlig überbewertet. --Plenz 08:54, 12. Feb 2006 (CET)
Also ich finde auch, dass der gesamte Pfad zu viel wäre. Wenn dann nur ein paar Ebenden. Ich meine das auch schon mal in irgendeiner Wikipedia gesehen zu haben, weiß aber leider nicht mehr wo. --M.A. (Marc-André Aßbrock) 16:29, 12. Feb 2006 (CET)

Mehrspaltendruck

Da dazu keien Softwareänderung nötig ist, habe ich den Vorschlag nach Wikipedia:Verbesserungsvorschläge vershcoben. Grüße, ElRakı ?! 01:48, 14. Feb 2006 (CET)

M3U-Einbau in die Software

Für das Wikipedia:WikiProjekt Gesprochene Wikipedia ist von Benutzer:Jokannes ein Skript gebastelt worden, das derzeit auf einem externen Server liegt, um die Artikel per M3U direkt anzuhören und nicht auf den ganzen Download warten zu müssen.. Der Vorschlag wäre nun, das Umwandeln in die MediaWiki einzubauen.

Informationen dazu bei Vorlage Diskussion:Playlist und Wikipedia Diskussion:WikiProjekt Gesprochene Wikipedia. Grüße, ElRakı ?! 01:48, 14. Feb 2006 (CET)

Dafür: ElRakiı Jokannes

Dagegen:


Gegen Linkspam: rel="nofollow" für externe Links (erledigt, Funktion bereits vorhanden)

Mein Vorschlag ist es, in der Wikipedia externe Links für Suchmaschinen so zu kennzeichnen, dass sie in deren Suchergebnisse keine Vorteile erhalten.

Für Spammer ist es nämlich vor allem deswegen interessant, in der WP den eigenen Link unterzubringen, weil so die Suchmaschinenergebnisse aufgebessert werden. Vereinfacht gesagt werden Links von namhaften Seiten als Pluspunkt für die verlinkte Seite gewertet (vgl. PageRank).

Um es für die Spammer weniger attraktiv zu machen, in der WP zu spammen könnte man den für die Spammer relevanten Nutzen einfach abschalten. Dazu gibt es einen Tag, der von der Wiki-Software einfach automatisch an externe Links angefügt werden könnte. [5] 

 <a href="http://www.spammerseite.com" rel="nofollow" >Weitere informationen zum Thema</a>

Diese für Leser unsichtbare Information sagt der Suchmaschine: Den externen Link bitte nicht positiv bewerten, nur weil er hier in der WP verlinkt wird. Mehr Informationen zu den prinzipiell möglichen Techniken gibt es hier: Meta-Tag, en:Link spam. Noch unkomplizierter umzusetzen wäre beispielsweise ein allgemeiner Metatag, der dann aber undifferenziert auf alle Links auf der Seite wirkt: 

 <meta name="robots" content="nofollow" />

Diese Mechanismen wurde von den Suchmaschinenbetreibern ursprünglich entwickelt, um Kommentarspam aus Blogs zu begegnen. In der Blogger-Community hat es gegen diesen Mechanismus teilweise Widerstände und Kritik gegeben. [6] Für die Wikipedia ist diese im Kontext von Blogs angebrachte Kritik aber meiner Meinung nach nicht besonders relevant (bzw. leicht korrigierbar). Die WP ist eine Enzyklopädie und hat deswegen im Gegensatz zu Blogs prinzipiell einen neutralen Standpunkt. Es kann also z.B. grundsätzlich nicht in ihrem Interesse sein, die angegebenen externen Links in irgendeiner Weise außerhalb der WP zu bewerben. Ausnahmen sind evtl. andere Projekte der Wikimedia Foundation, die deswegen gesondert behandelt werden könnten.

Das erfreuliche Ergebnis einer Implementierung wäre vor allem weniger Linkspam und damit für uns mehr Zeit für die inhaltliche Arbeit.

Viele Grüße! ISBN 11:38, 15. Feb 2006 (CET)

Da kommst du aber ein paar Monate zu spät. Auf Wikipedia-DE sind schon alle externen Links mit rel="nofollow" ausgezeichnet und wie man sieht, hat das in Sachen Linkspam überhaupt nichts geholfen. Ich finde das auch sehr kontraproduktiv und egoistisch, da Wikipedia schließlich ebenfalls von externen Links vieler Seiten profitiert und selber auch bei guten externen Links nichts davon abgeben will. -- net 13:41, 15. Feb 2006 (CET)
warum rel="nofollow" böse ist: http://nonofollow.net oder http://www.itst.org/nonofollow/ --Habakuk <>< 15:02, 15. Feb 2006 (CET)
Ups, ich bin tatsächlich etwas zu spät dran. Das ist ja schon längst umgesetzt! Hat sich erledigt. Viele Grüße, ISBN 19:40, 15. Feb 2006 (CET)

Erweiterter Vorschlag: Wie wäre es, wenn Administratoren Links "nofollow-frei" schalten könnten? Ich stelle mir eine von der Software verwaltete Liste vor, die die "no-nofollow-Links" enthält, und wann immer ein Link-Tag von der Software erzeugt wird, wird dort nachgesehen, ob das nofollow-Attribut weggelassen werden soll. Administratoren könnten dann hinter jedem externen Link ein kleines Icon angezeigt bekommen, das sagt, ob der Link nofollow-freigeschaltet ist, und per Klick auf das Icon könnte dann der Freischalt-Status geändert werden (vermutlich sollten solche Freischaltungen auch in einem Freischalt-Logbuch protokolliert werden). Eine extra Liste statt einer Auszeichnung im Text deshalb, weil

  1. auf diese Weise einfach sichergestellt werden kann, dass nur Administratoren Links freischalten können, und
  2. auf diese Weise das Interface einfacher gestaltet werden kann (man muss nicht erst den Text editieren und im Quelltext den Link suchen und ändern, sondern muss nur einmal aufs Icon klicken und dann vielleicht noch die gewünschte Freigabe bestätigen).

Allerdings weiß ich nicht, ob dieser zusätzliche Datenbank-Lookup pro externem Link eine wesentliche Zusatzbelastung für den Server wäre (allerdings könnte die Last vielleicht auch per Caching in Grenzen gehalten werden, schließlich ist es nicht allzu schlimm, wenn ein eigentlich entfernter nofollow-Tag noch eine Weile länger gesetzt ist). --Ce 19:39, 24. Apr 2006 (CEST)

Blockquote

Ich lese gerade ... ich hätte hierhin posten müssen. Seis drum, ich verweise einfach mal auf den Artikel in Verbesserungsvorschläge: [7]--Richardigel 14:36, 16. Feb 2006 (CET)

Andere Sprachen (Interwikilinks) Einklappen/Ausklappen

Da wir ja immer mehr Interwikilinks auf allen Seiten haben werden, schließlich gibt es ja auch um die 200 aktiven Wikipedias, ziehen die Interwiki-Linkleisten manche Artikel und Portale künstlich immer weiter in die Länge. Im Moment sind höchstens um die 50 Interwikilinks vorhanden, dass heißt, dass die momentane Länge erst maximal ein Viertel der zukünftigen Länge ausmacht. Aber schon jetzt ist die Anzeige, aufgrund der entstehenden Lücken sehr unschön (siehe Hauptseite oder Wikipedia:Portal). Mein Vorschlag dazu wäre, ähnlich wie bei den Navigationsleisten, ein Knopf mit "Einklappen"/"Ausklappen" zu der Box mit "Anderen Sprachen" hinzuzufügen. Natürlich müßte die Box standardmäßig eingeklappt sein. --Doit ʋ 09:51, 10. Mär 2006 (CET)

Eine festegefügte Leiste wie bisher ist mir eigentlich lieber...--Hannes2 Diskussion  15:07, 10. Mär 2006 (CET)
Und wozu standardmäßig einklappen? Damit ich dauernd noch mehr rumklicken muss? Wenn überhaupt, dann sollte es auch standardmäßig ausgeklappt sein, schon allein weil es dann weniger Aufwand wäre, einen Kompromiss für jene zu finden, die Javascript deaktiviert haben. Dabei würde aber wieder der Sinn verloren gehen, daher eine Option in den Einstellungen, wo es festgelegt werden kann. Sofern technisch realisierbar wäre es auch interessant, eine derartige Funktion nur bei mehr als x Sprachen zu integrieren, also bei mehr als 20 anderen Sprachversionen das Menü standardmäßig ausklappen, sonst nicht. Und das ganze in den Einstellungen änderbar... --mt 話し 19:54, 20. Mär 2006 (CET)

Quellenangaben in der Versionshistorie

Kopiert von Wikipedia_Diskussion:Quellenangaben (mangels Resonanz):

Ein Vorschlag, wie man Quellen in der Versionshistorie besser finden könnte, wäre es, das Feld Zusammenfassung und Quellen unter dem Artikelfenster und in der Versionshistorie zu trennen. D.h.: Es gäbe ein separates Feld für die Quellen, man könnte mit solchen Tools direkt und konkret nach Quellenangaben suchen, außerdem hätte man die Änderungen direkt dabei. Wäre dies technisch möglich? --αCentauri Haatschi! 14:23, 10. Mär 2006 (CET)


Dafür: -- Diwas 18:43, 24. Mär. 2007 (CET)

diff darstellungII

Wenn man sich denn diff zweier Artikelversionen anschaut dann ist die linke Spalte breiter als die rechte. Wegen der unterschiedlichen Umbrüche ist es schwierig Zeilenweise zu vergleichen. -- Achak ∇ 02:58, 24. Mär 2006 (CET)

Hier ein Fix für die persönliche JS: 

// DIFF WIDTH FIX:
// by User:Olliminatore, another Version en:User:Ilmari_Karonen/fixdiffwidth.js
if (document.URL.indexOf("&diff=",30)>0) addOnloadHook(function (){
 var diffT = document.getElementById("bodyContent"),
 diffTable = diffT.getElementsByTagName("table")[0];
 var diffT = diffTable.getElementsByTagName("tr")[0].getElementsByTagName("td"),
 diffo = diffT[0], diffn = diffT[1],
 diff_width = (diffo.clientWidth < diffn.clientWidth)? diffn.clientWidth: diffo.clientWidth;
 diffTable.setAttribute("width", diff_width*2);
});

oder als Modul einbindbar Benutzer:Olliminatore/fixdiffwidth.js -- Ολλίμίνατορέ •Ω• 20:09, 27. Apr 2006 (CEST)

Kommentare auf Beobachtungsliste

Wie bei den meisten WikipedianerInnen gehen bei mir editierte Artikel automatisch in die Beobachtungsliste. Was ich vermisse, wäre aber die Möglichkeit, einen kleinen Kommentar zu setzen, warum man einen Artikel beobachtet. z. B. (Wichtges Werkzeug oder interessante Diskussion)Ob das als Vorschauhinweis, oder bei Schalten des Buttons Beobachten oder nachträglich möglich ist, sollen die Hacker entscheiden. --Mäfä 15:44, 28. Mär 2006 (CEST)

Ich bezweifle, dass das einen wirklichen Sinn macht. Eigentlich sollte man das doch noch behalten können. Also ich würde so eine Funktion absolut nicht brauchen. Wie gesagt, ich nicht. --M.A. (Marc-André Aßbrock) 16:01, 28. Mär 2006 (CEST)
Also ich fände diese Idee auch nicht schlecht. Weißt Du wirklich noch in jedem Fall, warum Du vor drei Jahren den Artikel XY in Deine Beobachtungsliste aufgenommen hast? Vielleicht ging es Dir ja um einen Abschnitt, der inzwischen längst in einen anderen Artikel überführt wurde ... --Ce 15:02, 12. Mai 2006 (CEST)

ihr könnt den vorschlag sofort löschen ....

.....ich habe nicht soviel zeit mir alles durchzulesen .. ihr habt die seite spenden----warum nehmt ihr nicht einfach werbung und finanziert so die seite?

Werbung nervt und ist für ein nichtkommerzielles Projekt nicht immer ethisch verantwortbar. Außerdem gehört der Vorschlag nicht unter Feature Requests, wo es um Programmfunktionen geht--Hannes2 Diskussion  15:36, 30. Mär 2006 (CEST)

Anzeige der Kategorien in den Artikeln änderbar machen.

Ich bin beim aktuellen Fall, der hier, hier, hier und hier zu heftigen Kontroversen geführt hat auf folgende Idee gekommen:

Es müsste möglich sein den angezeigten Text in einem Artikel abändern zu können, so dass dann z.B. nicht mehr Frauenrechtler sondern Frauenrechtlerin erscheint.

Dies kann durch die Möglichkeit eines zweiten Parameters in der Kategorie-Zuweisung erfolgen.

Zum Beispiel:

Bisher steht im Artikel Emily Davison 

[[Kategorie:Frau|Davison, Emily]]
[[Kategorie:Brite|Davison, Emily]]
[[Kategorie:Frauenrechtler|Davison, Emily]]
[[Kategorie:Geboren 1872|Davison, Emily]]
[[Kategorie:Gestorben 1913|Davison, Emily]]

was zu dieser Anzeige im Artikel führt:

Kategorien: Frau | Brite | Frauenrechtler | Geboren 1872 | Gestorben 1913

Dies sollte ersetzbar sein durch: 

[[Kategorie:Frau|Davison, Emily]]
[[Kategorie:Brite|Davison, Emily|Britin]]
[[Kategorie:Frauenrechtler|Davison, Emily|Frauenrechtlerin]]
[[Kategorie:Geboren 1872|Davison, Emily]]
[[Kategorie:Gestorben 1913|Davison, Emily]]

was zu dieser Anzeige im Artikel führen würde:

Kategorien: Frau | Britin | Frauenrechtlerin | Geboren 1872 | Gestorben 1913

Damit würden die Kategorien in den Artikeln geschlechtskorrekt angezeigt und die Kategorien selbst blieben geschlechtsneutral gefüllt also z.B. alle Physiker und Physikerinnen in einer Kategorie.

Also was haltet Ihr davon? --Jutta234 Talk 18:50, 21. Apr 2006 (CEST)

dafür:

dagegen:

  • --mäfä! Noch eena ohne Fahrschein? 19:25, 21. Apr 2006 (CEST), erscheint mir in der Anwendung zu kompliziert. Ottos Weg scheint mir u. U. der einfachere nutzungsfreundlichere und effektivere Weg zu sein. Aber ich bitte zu bedenken,dass ich mich mit bots & Co. garnicht auskenne.
  • -- sebmol ? ! 19:38, 21. Apr 2006 (CEST) Das Wort "Frauenrechtler" enthält überhaupt keinen Bezug auf das biologische Geschlecht der Person. Es ist ein generisches Maskulinum. Wenn wir nun „Frauenrechtlerin“ hinzufügen, würde die WP nur die eindeutig verkehrte Verwechslung von grammatischem und biologischem Geschlecht weiter treiben. Kategorien mit künstlichen weiblichen Formen haben genauso wie solche Lemmas hier nichts zu suchen. Mir ist völlig unverständlich, warum auf der einen Seite Gleichbehandlung gefordert wird, aber andererseits eine strikte Geschlechtertrennung durchgeführt werden soll. -- sebmol ? ! 19:38, 21. Apr 2006 (CEST)
  • --Fritz @ 17:35, 30. Apr 2006 (CEST) Verträgt sich nicht mit dem wesentlich vielseitiger einsetzbaren Vorschlag #Angezeigte Bezeichnung in Kategorie.

Diskussion:

  • Mein Vorschlag, anhand des Beispiels Frauenrechtler/in, ist: In den Artikeln zu Männern "Kategorie:Frauenrechtler" und zu Frauen "Kategorie:Frauenrechtlerin" angeben. Das Resultat sollte dann sein, dass sowohl Männer als auch Frauen gemeinsam in einer "Kategorie:Frauenrechtler und Frauenrechtlerinnen" zu finden sind. Ein "Kategorien-Redirect" sozusagen. Dazu wäre wohl eine kleine Umprogrammierung notwendig, an der Umsortierarbeit sollte es dank den Bots nicht scheitern - es ist bloß eine Frage des Willens. Vorteil ist, dass eine absolut geschlechtsneutrale, da beide Geschlechter umfassende, Kategorisierung erreicht wird, und das ohne die lange, offizielle Kategorienbezeichnung, auch tatsächlich im Artikel selbst eingeben zu müssen (man wird ja von "Kategorie:Frauenrechtler" auf die "Kategorie:Frauenrechtler und Frauenrechtlerinnen" weitergeleitet - genau so wie der Artikel selbst in diese Kategorie weitergeleitet, also dort eingeordnet, wird (wie gesagt, kleine Umprogrammierung von Nöten)). Tja - eigentlich sollte keine Frage mehr offen bleiben. Zum gern genannten Sonderfall Zwitter oder Transvestit: auch die würden in einer Frauen und Männer umfassenden Kategorie ihren Platz haben :) -- Otto Normalverbraucher 19:18, 21. Apr 2006 (CEST)
Und ich dachte ich hätte auch einmal eine Gute Idee gehabt. Was aber nach den bisherigen Reaktion (2x dagegen und 1x Alternativvorschlag) wohl eher nicht so auf allgemeine Gegenliebe stößt. Naja, seis drum.
Zum Vorschlag mit dem Redirect für Kats: Prizipiell auch nicht schlecht, nur kann ich mich mit den etwas überladenen Titeln wie "Kategorie:Frauenrechtler und Frauenrechtlerinnen" nicht wirklich anfreunden.
Zum Generischen Maskulinum: Das Sprachgefühl von einigen (evtl. auch vielen) scheint ein anderes zu sein. sonst wäre dies nicht zum ersten Male hier ein Thema.
PS: Ich selbst störe mich gar nicht sehr daran. Ich dachte nur, dass dies ein möglicher Kompromis sein könnte mit dem die meisten leben können. --Jutta234 Talk 23:01, 21. Apr 2006 (CEST)

Redirekt von http://www.wikipedia.de/XYZ auf http://de.wikipedia.org/wiki/XYZ

Ich fände einen automatischen Redirect von http://www.wikipedia.de/Beispiellemma auf http://de.wikipedia.org/wiki/Beispiellemma super! Bisher kommt hier die Startseite. --JohannesPonader 22:16, 28. Apr 2006 (CEST)

Fände ich nicht so sinnvoll. Schließlich sucht wohl kaum jemand in Wikipedia per URL. Viele Grüße Pill δ 11:02, 29. Apr 2006 (CEST)
Gabs früher schonmal, wurde aber soweit ich weiß aus Performance- oder sonstigen Gründen wieder abgeschaltet (man beachte, dass die dt-sprachige WP auf de.wikipedia.org zu finden ist; wikipedia.de suggeriert eine deutsche Seite, aber keine deutschsprachige, es gibt ja noch die Schweizer, Österreicher, Liechtensteiner usw. usf.) --rdb? 15:21, 30. Jul 2006 (CEST)

Nach erfolgloser Suche andere Sprachen anbieten

Nach einer erfolglosen Artikelsuche wäre es schön wenn nach dem Suchbegriff in den anderssprachigen Wikipedias gesucht würde und diese Artikel dann angeboten würden. z.b. Suche nach Golfito führt in der deutschen Wikipedia zu keinem Ergebnis, aber in der englischen gibt es dazu ein Eintrag. Dieser könnte angezeigt, bzw. angeboten werden.

Sehe gerade einen ähnlichen Wunsch hier

Automatisches Ersetzen von ß nach ss

Ich benötige eine Vorab-Antwort einer möglichen technischen Realisierung für ein noch nicht gestartetes Meinungsbild:

Ist es möglich, die deutschsprachige WP so zu erweitern, dass der Benutzer auswählen kann (am Besten über Spezial:Preferences), dass alle "ß" in einem Artikel serverseitig nach "ss" umgewandelt werden können? Ist dieser Vorschlag (bezogen nur auf ß/ss) so oder so ähnlich realisierbar? Schönen Gruß --Heiko A 14:04, 19. Mai 2006 (CEST)

Vielleicht wie die Schriftzeichenvarianten der Chinesischen Wikipedia? Vielleicht kann man das ja auch von dem HTTP-Request-Header abhänig machen. Also das ist jetzt ein rein technischer Beitrag, ob das sinnvoll ist ist eine andere Frage. Ich denke aber schon. -- M@rkus 15:18, 19. Mai 2006 (CEST)
Hallo Markus. Ich kenne die chinesische WP nicht. Wie funktioniert das denn da? Und was heißt "Vom HTTP-Request-Header abhängig machen"? --Heiko A 15:27, 19. Mai 2006 (CEST)

Quellenerfassungssystem

Ich finde, dass es ein System zur Erfassung der Quellen geben sollte. Es sollte so angelegt sein, dass man die Elemente der Literaturangabe, einzeln eingeben kann und die Literaturangaben automatisch generiert werden. Außerdem könnte es so angelegt sein, dass der Nutzer den entsprechenden Bereich des Artikels, der auf der Quelle beruht markiert, sodass eindeutig ersichtlich ist, welche Aussagen des Artikels belegt sind und mit welchen Quellen. Bei Verweis auf andere Artikel könnte gleichzeitig auch die Stelle makriert werden, auf die sich der Verweis bezieht.

Vorteile:

  • Die Angabe von Quellen wird gefördert.
  • Die Benutzer werden zu präzisen Quellenangaben (mit Seitenzahlen, Erscheinungsjahr etc.) angeregt
  • Die Quellenangabe wird einfacher, weil man sich nicht um die Zitierweise kümmern muss.
  • Quellen können eindeutig den zugehörigen Abschniten zugeordnet werden.
  • Der Stil der Quellen- und Literaturangaben wird vereinheitlicht.


Nachteile

  • Zusätzliche Funktionalität --> Komplexität nimmt zu
  • Aufwand


Falk Lieder

Dafür weil: Zur Zeit sind die Quellenangaben nicht mit vertretbarem Aufwand (besonders Versionsgeschichte) auffindbar. -- Diwas 19:10, 24. Mär. 2007 (CET)
Hallo, das gibt es schon - siehe Wikipedia:Quellenangaben und für Deine Zwecke besonders Hilfe:Quellenangaben. Gruß --JuTa Talk 17:46, 21. Jul 2006 (CEST) Hallo, das gibt es nicht. -- Diwas 19:10, 24. Mär. 2007 (CET)
Das Quellenangaben durch Fußnoten erfolgen können ist mir bekannt. Dieses ermöglichen es direkt nachzuweisen, zu welcher Aussage im Text welche Quelle gehört. Damit bleiben allerdings ein großes Probleme ungelöst: die uneinheitliche Zitierweise. Unter anderem deshalb plädiere ich für ein Quellenerfassungsmenü. --Falk Lieder 18:18, 21. Jul 2006 (CEST)

Markierung von Botänderungen

Mir ist aufgefallen, dass die vielen Änderungen von Bots in der letzten Zeit in der Beobachtungsliste nicht mit "B" gekennzeichnet sind, wie in der Legende steht, sondern zumeist mit "K". Das ist zwar nicht erheblich, führt aber dazu, dass einige Bots, beispielsweise der KatBot, von der Funktion ausblenden von Bot-Änderungen in den Benutzereinstellungen nicht erkannt werden. --Bohr ΑΩ 11:36, 18. Jun 2006 (CEST)

Nicht alle Bots haben den Bot-Status (genauer: sind der Benutzergruppe "Bot" zugeordnet), sondern müssen vielmehr eine Probezeit (im Normalfall 7 Tage) durchlaufen. Solange sie noch als normale Benutzer geführt werden, können etwaige Mängel sowie (un)gewollter Vandalismus von einer viel größeren Zahl von Benutzern aufgedeckt werden, da alle Bearbeitungen in den "Letzten Änderungen" für jedermann einsehbar sind. KatBot hat den Bot-Status (auch engl.: "Bot-Flag") noch nicht zugewiesen bekommen und seine Bearbeitungen erscheinen daher in der Liste, selbst wenn man Bot-Änderungen ausblendet. Näheres zum Thema "Bots" auch auf Wikipedia:Bots. Dort werden unter anderem auch Bots, die auch einen Bot-Status haben, als "registrierte Bots" aufgeführt. --CyRoXX (? ±) 21:29, 18. Jun 2006 (CEST)

Mal wieder das monobook-CSS

Monobook formatiert dd-Einträge ziemlich wirr, zu allem Überfluss kann man das Zeug wird dt genauso formatiert wie h3. Das sieht so aus: [8]. Geht doch bestimmt auch geschickter, oder? igel+- 10:53, 19. Jun 2006 (CEST)

Artikel-Permanentlink

Es sollte (bzw. gibt es?) in allen Wiki-Projekten eine Möglickeit geben, (numerische oder codierte) wiki-URLs zu generieren, die unabhängig vom Titel eines Artikels immer auf den richtigen Artikel verweisen. Damit würden (irgendwo gepostete) URLs auch noch funktionieren, wenn ein Artikel verschoben wurde.

Bsp: Aus http://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschläge/Feature-Requests wird http://de.wikipedia.org/0000123456789

und der funktioniert dann auch noch wenn die Seite z.B. nach http://de.wikipedia.org/wiki/Wikimedia:Feature-Requests verschoben wird.

--the one who was addicted (#) 18:05, 19. Jun 2006 (CEST)

Bisher gibt es nur Permalinks auf eine bestimmte Version. Der funktioniert auch noch nach einer Verschiebung. Aber auf die jeweils aktuelle gibt es meines Wissens leider keine. Sollte man aber einführen. -- Timo Müller Diskussion 16:48, 21. Jun 2006 (CEST)
Klick einfach bei einem Artikel auf Permanentlink in der Hauptnavigation und schau dann in die URL-Zeile Deines Browsers ... ;-) --:Bdk: 16:53, 21. Jun 2006 (CEST)
Ich habe jetzt vor einer Artikelbearbeitung mir den derzeit verfügbaren "Permanentlink" gespeichert, und nach der Speicherung meiner Änderung wieder ausprobiert. Jetzt lande ich (leider) wieder bei der alten Version. Ich möchte jedoch einen "Artikel-Permanentlink" wie oben beschrieben, der immer auf die aktuelle Version führt. --the one who was addicted (#) 13:54, 22. Jun 2006 (CEST)
Yo, schon verstanden (ich meine auch, dass es dazu bereits einen geschlossenen Bug gibt, finde den aber gerade nicht). Problem dabei ist, dass versionsunabhängige Links, die nicht (manuell) durch Redirects abgedeckt sind, in etlichen Fällen kein eindeutiges Linkziel mehr zulassen. Mein obiger Hinweis zur jeweils aktuellen Version galt nur Timo (es ist zwischen jeweils und immer aktuellen dauerhaften Links zu unterscheiden).
Hier mal ein gar nicht so seltenes Szenario, weshalb Dein Vorschlag schwierig ist:
  • Jemand schreibt 2004 den Artikel Hans-Werner Meier.
  • Hans-Werner Meier wird 2005 verschoben nach Hans-Werner Meier (Schriftsteller), das Namenslemma wird zur BKL mit weiteren 2 roten Links
  • Jemand schreibt ergänzend Hans-Werner Meier (Fußballer), die BKL Hans-Werner Meier bleibt bestehen.
  • Der Stub Hans-Werner Meier (Fußballer) wird nun per Hand zum Namenslemma übertragen, die BKL aufgelöst, weil er bekannter ist als der Schriftsteller, das Klammerlemma gelöscht.
  • Anschließend gibt es noch mehrere Hin- und Herverschiebungen einschließlich dafür nötiger Redirectlöschungen, weil ein Literaturspezialist meint, der Schriftsteller sei bekannter.
  • Letztendlich ist unter der ehemaligen BKL Hans-Werner Meier ein (noch weitaus bekannterer) Opernsänger zu finden (Artikel wurde über den Redirect neu geschrieben), und die anderen beiden heißen (mit anderem Klammerzusatz) Hans-Werner Meier (Dichter) und Hans-Werner Meier (Sportler), daneben gibt es noch ''Hans-Werner Meier (Begriffsklärung), wo weitere 5 Hans-Werner Meiers gelistet sind ...
Jeder Permalink zeigt dabei immer (auch nach Verschiebungen) auf die jeweilige (nach gewisser Zeit zumeist veraltete) Version des richtigen Artikels. Mit nur einem Klick ist jedoch die dazugehörige aktuelle Version zu erreichen. Das funktioniert.
Aber auf welche aktuelle Version kann ein "fester" Link zeigen, der irgendwann 2004 auf das Lemma Hans-Werner Meier (also damals den Schriftsteller) gesetzt wurde bzw. wie soll MediaWiki wissen, dass der heute dort zu findende (nicht durch Verschiebungen entstandene) Text eine andere Person beschreibt? ;-) Nicht ganz unmöglich, aber kompliziert, vor allem sind etliche Fälle denkbar, wo solch eine URL versagt. Was passiert z.B. bei Löschungen und nach einem halbem Jahr komplettem Neuschreiben eines Artikels unter einem womöglich mehrdeutigen Lemma? Hoffe, nicht allzusehr verwirrt zu haben ;-) --:Bdk: 01:51, 23. Jun 2006 (CEST)

grafische Aufbereitung von Abhängigkeiten

Wäre es vielleicht möglich Abhängigkeiten von Wissen grafisch aufzubereiten?

Als Beispiel: Ich interessiere mich z. B. für den Begriff "Relativitätstheorie" um so ein komplexes Thema zu verstehen ist meistes das Lesen anderer, quasi abhängiger, Artikel nötig.

Es wäre schön wenn diese Abhängigkeiten dann in (z.B.) Pyramidenform nach dem Begriff für den ich mich interessiere(als Spitze der Pyramide) grafisch darstellbar wären.

Man könnte dann auch eine priorisierung nach "Leichtigkeit"(leichte Erlernbarkeit) der Artikel hinzufügen und so Stufen der Pyramide einteilen.

Desweiteren wäre die Option für "Unterabhängigkeiten anzeigen" auch nicht schlecht :-)

Ich denke das dies wehsentlich zu leichterem und besserem verstehen komplexer Themen beitragen könnte.

Cursor per default in Feld "Suche"

Damit nicht jedesmal bei Aufruf von Wikipedia der Cursor im Feld "Suche" platziert werden muss, bevor man mit der Suche loslegen kann, wäre es vorteilhaft, wenn der Cursor per default im Feld "Suche" platziert ist.

Ich empfinde das auch schon seit langem als nervig. Wäre schön wenn sich das einrichten liesse.--Gurgelgonzo 08:34, 7. Jul 2006 (CEST)
Siehe bitte ersten Eintrag ganz oben. --:Bdk: 08:39, 7. Jul 2006 (CEST)

Unterschrift ohne automatische Verlinkung zur Benutzerseite

(Ich hoffe, das ist ein neues Thema und nicht irgendwo schon durchdiskutiert worden) Könnte dieses Feature aus Spezial:Preferences nicht deaktiviert werden? Ein Benutzer hat doch keinen Grund, dieses Feature zu setzten, außer dass er dadurch in älteren Diskussionen nur schwer angesprochen werden kann, da man dann den Weg über die Versionsgeschichte gehen muss. Ich halte das für äußerst bedenklich, da es die Kommunikation innerhalb der Wikipedia einfach behindert. Das Schlimme: Inzwischen setzten selbst Admins diesen Haken. --schlendrian •λ• 11:45, 8. Jul 2006 (CEST)

Ist diese Option nicht nötig, um seine Signatur selbst mit extra Links gestalten zu können? -- sebmol ? ! 11:56, 8. Jul 2006 (CEST)
autsch, natürlich ist sie das... daran hatte ich garnicht gedacht, vergesst es, selbst wenn ich es blöd finde, seine Sig nicht zu verlinken --schlendrian •λ• 12:12, 8. Jul 2006 (CEST)
Find ich auch. Andererseits wäre dann auch dein "•λ•" nicht mehr möglich. -- sebmol ? ! 12:18, 8. Jul 2006 (CEST)
Früher war es mal ohne den Haken möglich, bis irgendwas umgestellt wurde und man das von da an anhaken musste. naja, was solls... Der Link auf die Disku ist dann wichtiger als einige wenige, die nichtmal ihre Seite verlinken wollen --schlendrian •λ• 12:22, 8. Jul 2006 (CEST)
Was sich ja nicht ausschließen muss...--Gunther 23:09, 13. Jul 2006 (CEST)

"Zurücksetzen-Button"

das automatische reverten mit dem "zurücksetzen-button" ist an und für sich eine nützliche sache, hat aber m.e. einige fehler:

  1. man kann keinen kommentar eingeben: ich halte es jedoch immer für sinnvoll und nützlich, eine begründung für den revert einzugeben, damit gleich klar ist, weshalb revertet wurde.
  2. der button setzt automatisch auf die letzte version eines anderen benutzers zurück: das heißt, dass meine eigenen und "sinnvollen" änderungen zuvor ebenfalls revertet werden und ich dann händisch einen erneuten revert machen muss.

daher meine folgenden fragen dazu:

  1. ob meine darstellung der situation überhaupt korrekt ist, oder ich irgendwelche einstellungen vornehmen kann, um dieses zu ändern.
  2. ob andere benutzer meiner einschätzung zustimmen können, dass der button nicht optimal ist, wenn man nur bei der "händischen" variante kommentare eingeben kann und er nicht auf die tatsächliche vorherige version revertet
  3. ob dies softwaremäßig überhaupt umsetzbar wäre.

falls diese frage(n) bereits diskutiert wurde(n), wäre ich dankbar für einen link zur disk.. gruß --ee auf ein wort... 14:47, 18. Jul 2006 (CEST)

Unter Umständen wäre für dich auch PDDs Javascript nützlich. Damit können Änderungen mit Kommentar rückgängig gemacht werden. Außerdem erlaubt es zum Beispiel das Stellen von LA, SLA, QS und VS-Anträgen aus der betroffenen Seite heraus. -- sebmol ? ! 14:53, 18. Jul 2006 (CEST)
das hört sich schwer nach einer eigenen .css- oder .js-seite an und das habe ich nicht, weil ich mich damit überhaupt nicht auskenne :-( vieleicht auch noch eine antwort zum 2. teil meiner frage bzgl. revert auf letzten anderen benutzer? --ee auf ein wort... 16:00, 18. Jul 2006 (CEST)
Es werden alle Änderungen des Benutzers rückgängig gemacht - bis zur letzten Version eines anderen Benutzers. Früher war dies anders - da wurde nur die letzte Version rückgängig gemacht, aber zuviele Admins waren fahrlässig damit umgegangen.. -- da didi | Diskussion | Bewertung 08:11, 21. Jul 2006 (CEST)

Diverses zu Spezial:Contributions

Schätze mal das gehört unter die 2. große Überschrift, aber ich bin mir nicht so sicher. Jedenfalls würde ich mir wünschen, dass bei den Spezial:Contributions (d.h. Benutzerbeiträgen) die Information, ob ein Edit aktuell ist, weiter nach links gerückt, und zwar mindestens so weit, dass alle in einer Spalte stehen. Das wäre also der Fall wenn man die Info hinter "(Unterschied)" rücken würde. Vielleicht sollte man noch dafür sogar, dass man das ebenfalls fett-gedruckte K nicht übersieht (z.B. könnte man aktuell entfetten, da es sich ja farblich von den Links abhebt (sicher, je nach Browsereinstellung, aber in der Regel)). Außerdem wünsche ich mir, dass man wie früher wieder die kleinen Edits in den Contribs ausblenden kann. Und warum wird das N für "neu angelegt" nicht mehr angezeigt ? -- Amtiss, SNAFU ? 15:07, 30. Jul 2006 (CEST)

Erweiterte Suche

Die Suchfunktion ist echt unkomfortabel ! Ich muss erst was eintippen und suchen lassen, bevor ich auswählen kann welche Namensräume ich durchsuchen möchte. Ich will ne erweiterte Suche, dass ist doch gar nicht so schwer. -- Amtiss, SNAFU ? 01:48, 31. Jul 2006 (CEST)

Schau mal unter Spezial:Preferences, Reiter „Suche“. Dort kannst du festlegen, in welchen Namensräumen standardmäßig gesucht werden soll. --Raymond Disk. 08:07, 31. Jul 2006 (CEST)
Ich weiß, aber ich such ja nicht immer im selben Namensraum. Und es wäre auch für die Server eine Entlastung, wenn es eine erweiterte Suche gäbe. -- Amtiss, SNAFU ? 14:47, 31. Jul 2006 (CEST)
Die Googlesuche über die Domäne sollte optional angeboten werden, das ist sicher leicht machbar.--Löschfix 03:51, 24. Aug 2006 (CEST)

Interwiki-Links zu Schwesterprojekten

die frage habe ich damals bei WP:VV gestellt, dann aber geshen, dass sie hier besser aufgehoben ist. -Mg ☎ ☠ ❤ 18:11, 2. Aug 2006 (CEST):

Ich habe auf der Wiktionary-Hauptseite gesehen, dass dort die Interwiki-Links zu den Schwesterprojekten in der linken Spalte über den Sprachen aufgelistet sind. Das könnte man doch bestimmt hier auch einführen. Das fände ich übersichtlicher, als alle Interwiki-Links in den Artikeln selber. --Mg ☎ Stimme abgeben! 00:40, 14. Jul 2006 (CEST)

Hallo Mg. Dazu gibt es bereits ein Feature-Request auf MediaZilla (phab:T2708 (Bugzilla:708)) Grüsse -- baumanns _____ 15:55, 14. Jul 2006 (CEST)
Und was bedeutet das was da steht jetzt in Bezug auf meine Frage? Leider reicht mein Fach-Englisch nicht aus, um die Diskussion dort eindeutig zu verstehen. --Mg ☎ Stimme abgeben! 20:36, 14. Jul 2006 (CEST)
Die Wiktionary-Sache beruht auf einer Javascript-Lösung. Die relevanten Generierungsseiten sind wikt:MediaWiki:Onlyifsystem.js und wikt:MediaWiki:Monobook.js (Die Interprojectlinks werden im Wiktionary wg. Onlyifsystem auch automatisch auf allen Spezial- und MediaWiki-Seiten angezeigt, zusätzlich können sie durch wikt:Vorlage:InterProjekt (zur anwendung hier) Seiten von anderen NRs generiert werden.). Viele Grüße Pill δ 19:35, 6. Aug 2006 (CEST)

Einzelnachweise

Ich schlage eine neue Kategorie von Einzelnachweisen vor, die über die traditionelle Verwendung von Einzelnachweisen (umstrittene Informationen, Zitatquellen u.ä.) hinausgehen. Die Idee ist, dass diese zusätzlichen Einzelnachweise standardmäßig versteckt sind und bei Bedarf per Knopfdruck angezeigt werden können. Dies verhindert, dass der Benutzer (wie z.B. hier) mit irritierenden Fußnoten überschwemmt wird und dennoch alles belegt werden kann. Diese neue Kategorie würde zusätzlich zu dem bereits vorhandenen Typ von Einzelnachweisen bestehen. Zur Zeit ist die Angabe derartiger Belege, ohne die Ästhetik zu gefährden, nur per Kommentar im Quelltext möglich (s. z.B. hier. --Phrood 01:22, 7. Aug 2006 (CEST)

Die von Dir angeführten Kommentare im Quelltext sind nicht nur absolut unüblich, sondern auch ganz und gar nicht zielführend. Sie sollten unterbleiben. --Frank Schulenburg 19:32, 17. Aug 2006 (CEST)
Zu viele Quellenverweise sind ein Qualitätsmangel, wir schreiben einen Enzyklopädieartikel, nein, eine ganze Enzyklopädie und keine Doktorarbeit.--Löschfix 03:49, 24. Aug 2006 (CEST)

Eine Alternative wäre die Einführung einer Seite wie [[Quellen:Artikel]] analog zu [[Diskussion:Artikel]]. Dieser Vorschlag wurde hier von BishkekRocks gemacht. --Phrood 11:09, 26. Aug 2006 (CEST)

Dankenswerterweise hat Benutzer:Malte Schierholz ein Skript geschrieben, das so etwas ermöglicht. Eine derartige Funktionalität sollte in die Software integriert werden. Eine separate Seite für die Nachweise wäre allerdings im Sinne einer besseren Trennung zum Artikelinhalt noch besser. --Phrood 22:39, 16. Sep 2006 (CEST)

Syntax für rahmenlose Bilder

Freigestellte Bilder sehen im thumb/framed-Rahmen hässlich aus. Auf Hilfe:Bilder#Rahmenloses Bild mit Bildunterschrift wird ein nützlicher Workaround mit Tabelle angegeben. Das Ergebnis kann man z.B. auf Linux (Betriebssystem) sehen. Es wäre wünschenswert, eine derartige Funktionalität direkt als Option in der [[Bild|...]]-Syntax angeben zu können. --Phrood 01:29, 7. Aug 2006 (CEST)

editcounter

moin moin, kolleginnen und kollegen

ich habe folgende probleme:

  1. ich benutze eigentlich den klassik-skin und habe bis vor kurzem durch die einbindung von {{Editcount|Erwin E aus U}} meinen edit-counter dort gesehen, wo ich ihn im quelltext gepostet hatte, nämlich am ende der seite. dann war er plötzlich in der ansicht weg, im quelltext aber noch eingetragen. wenn ich nun den link zu meinen beitragszahlen sehen will, muss ich den weblink selbst eingeben. die vorlage wird aus irgendwelchen gründen nicht mehr angezeigt.
  2. ich hatte schon einmal probleme, dass andere benutzer eine eigene editcounter-vorlage gebastelt haben und benutzen. dadurch werden aber, wenn ich auf deren seiten gehe, meine persönlichen links, welche sich bei mir im klassik-skin oben in der rechten ecke befinden, durch die beitragszähler von diesen benutzern überlagert. zudem reicht die überlagerung auch in die linke richtung, so dass dort weitere links betroffen sind und nicht mehr angeklickt werden können, siehe hier. gibt es möglichkeit, den klassik-skin mit dem monobook-skin in dieser hinsicht wieder kompatibel zu machen? früher gab es diese probleme nicht. und warum wird im monobook-skin die editcount-vorlage grundsätzlich rechts oben angezeigt, obwohl man sie im quelltext wo anders gepostet hat (bei mir soll sie unter meinem namen in meiner begrüßung rein)? soweit von mir, gruß --ee auf ein wort... 18:09, 10. Aug 2006 (CEST)
Schuld an der Nicht-Mehr-Anzeige ist wohl der folgende Eintrag in MediaWiki:Common.css:
/* Skinabhängige absolute Positionierungen ausblenden */
/* Bitte MediaWiki Diskussion:Common.css#Absolute_Positionierungen beachten */

#coordinates_3_ObenRechts, #issnlink, #editcount, #shortcut, #artikelstadium {
   display: none;
}
In MediaWiki:Monobook.css wird diese Angabe überschrieben durch
/* für Vorlage:Editcount: */

#editcount {
   display: inline;
   position:absolute; z-index:1; border:none; background:none; right:12px; top:0.3em; float:right; margin:0.0em;
   padding:0.0em; line-height:1.5em; text-align:right; text-indent:0; font-size:85%; text-transform:none; white-space:normal;
}
In MediaWiki:Standard.css (der css-Vorlage für den Klassik-Skin) findet sich jedoch kein Eintrag hierfür, so daß der Eintrag aus der Common.css wirksam bleibt - und der blendet eben den Link aus.
Wozu dieser Common.css-Eintrag gut sein soll, verstehe ich ja nicht (ohne ihn würde die Anzeige einfach an Ort und Stelle passieren; der Eintrag im Monobook würde dennoch funktionieren), insofern würde ich dafür plädieren, den #editcount-Eintrag aus der Common.css einfach zu entfernen. Alternativ kann auch in der Standard.css der Eintrag unschädlich gemacht werden (in diesem Fall ist aber zu befürchten, dass in anderen, noch seltener benutzten Skins dasselbe Problem bestehen bleibt.
Ein Eintrag in der benutzerspezifischen CSS-Datei ist in diesem Fall nur beschränkt nützlich: Er erlaubt einem, den Benutzerzähler-Link von Benutzern, welche die Vorlage verwenden, zu sehen, hilft aber nicht, wenn man selbst mittels dieser Vorlage anderen Nutzern den Link zur Verfügung stellen will (denn der andere Benutzer hat ja sein eigenes CSS - oder auch gar keins -, und da steht vermutlich überhaupt nichts über Editcounter drin, weil der Benutzer gar nicht wusste, dass ihm da etwas vorenthalten wird).
Nebenbei, bei den in Common.css ausgeschalteten und in Standard.css nicht wieder eingeschalteten ids gehört auch artikelstadium. Das klingt interessant: Wofür wird es verwendet? --Ce 18:28, 11. Aug 2006 (CEST)

klassik-skin

moin moin, kolleginnen und kollegen

noch eine anfrage von mir: im klassik-skin kann ich link-leiste links "mitschweben" lassen. da ich derzeit darüber nachdenke, den skin u.a. wg. der probleme in der anfrage darüber auf monobook zu wechseln, hier meine frage, ob diese funktion auch im monobook verfügbar gemacht werden kann und wenn nein, warum nicht? --ee auf ein wort... 03:18, 11. Aug 2006 (CEST)

Falls das obige Problem ausschlaggebend für den geplanten Skinwechsel ist: Wenn Du in Benutzer:Erwin E aus U/standard.css die Zeile
#editcount { display:inline }
schreibst (und dann ein Reload machst (bei Mozilla/Firefox mit Strg+Shift+R bzw. beim Klicken des "Neu laden"-Buttons Shift gedrückt halten, eine Anleitung, die auch andere Browser berücksichtigt, wird nach der Editierung auch auf der erwähnten Seite angezeigt), dann sollte für Dich der Editcounter auch im Standard-Skin angezeigt werden. Das löst zwar nicht das eigentliche Problem (weil ja die Editcounter für alle anderen Klassik-Skin-Benutzer weiterhin unsichtbar sind), aber das tut ein Skinwechsel Deinerseits ja auch nicht. --Ce 11:47, 13. Aug 2006 (CEST)

Groß-/Kleinschreibung bei der Suche

Servus,

bei der Groß-/Kleinschreibung bei der Suche kommen unterschiedliche Ergebnisse.

z.B.:

1. wp und Wp ergeben die Seite Wp - also einen konkreten Artikel

2. WP ergibt WP - also eine Auswahlliste/Abkürzungsliste für Artikel


Das ist insofen lästig wenn man faul ist und immer nur in Kleinbuchstaben dahinschreibt. Mein Vorschlag deshalb wäre, auch wenn ich wp eingebe sollte ich auf die Auswahlliste/Abkürzungsliste für Artikel kommen (WP) und dann selbst entscheiden können welches Thema ich jetzt ansehen möchte!


  • Wäre das Möglich?
  • Was sagt ihr dazu?


MfG - Spectrums 12:13, 11. Aug 2006 (CEST)


ich denke, wenn der Suchende weiss, dass er WP und nicht6 Wp sucht, reicht die BKL oben. --Mg ☎ ☠ ❤ 14:57, 11. Aug 2006 (CEST)


Das Problem sehe ich auch. Ich wäre dafür, sich nur durch Gross-/Kleinschreibung unterscheidene Lemmata ganz zu vermeiden, d.h. in diesem Fall Wp nach Wp (Maßeinheit) zu verschieben, so dass man bei Eingabe von "wp" zur BKL WP gelangt. -- memset 16:14, 11. Aug 2006 (CEST)


Da muss ich dir eindeutig zustimmen memset. Das wäre die einfachste Lösung. Denn wenn es für eine Abkürzung mehrere Varianten gibt, dann muss es einfach eine Auswahlliste geben, wo man sich entscheiden kann! MfG - Spectrums 08:49, 12. Aug 2006 (CEST)

Noch weitere Beispiele, bei denen Handlungsbedarf besteht, da die Grossbuchstaben-BKLs nicht zu finden sind:

-- memset 11:55, 12. Aug 2006 (CEST)


@memset: Wp (Maßeinheit) wurde so eben von mir erstellt und in die Begriffserklärung Wp eingefügt.
Weiters habe ich bei Tal (Begriffsklärung) einen Löschantrag gestellt und den Inhalt davon nach TAL verlegt - MfG - Spectrums 10:18, 22. Aug 2006 (CEST)

Spezielle Abschnitte

In manchen Fällen wäre es nützlich, Zwischenabschnitte einzufügen, die nicht im Inhaltsverzeichnis aufgelistet werden (z.B. weil die entsprechenden Abschnitte sehr kurz bzw. eher unwichtig sind und/oder der Artikel sehr lang ist). Ich schlage daher folgende Syntax vor: 

*=== Überschrift ===*

produziert den selben Abschnitt wie 

=== Überschrift ===

erscheint aber nicht in der TOC. --Phrood 21:17, 13. Aug 2006 (CEST)

Also einen Ersatz für {{%C3%Überschriftensimulation_2 - 5}}. Nach Hilfe:Inhaltsverzeichnis#.C3.9Cberschriften.2C_die_nicht_im_Inhaltsverzeichnis_erscheinen_sollen so nicht erwünscht (dort Alternative). -- Ολλίμίνατορέ 21:35, 13. Aug 2006 (CEST)
Danke, diese "Notlösungen" kannte ich noch nicht. Aber dass ein Wikimedia-Code unerwünscht sein soll, kann ich dort nicht entnehmen (nur "Es gibt derzeit keine Diskussion darüber"). --Phrood 22:46, 13. Aug 2006 (CEST)

Automatische Signatur

Beim Bearbeiten von Diskussionen könnten zusätzlich zu den ankreubaren Kästchen für Beobachtungsliste und Kleine Änderungen ein weiteres Kästchen erscheinen, dass für eine automatische Einfügung der Signatur zuständig ist. Wenn dieses Kästchen standardmäßig aktiviert ist (in den Einstellungen könnte man es ausschaltbar machen) könnte es ein häufiges Prblem von neuen und/oder schusseligen Benutzern, das Weglassen der Signatur nämlich, verhindern. Gleichzeitig würde aber, anders als bei einer ganz automatischen Signierung, verhindert, dass Bearbeituungshinweise signiert würden, dabei könnte man nämlich einfach das Häkchen wieder entfernen.--Hannes2 Diskussion  14:10, 22. Aug 2006 (CEST)

Finde ich nicht so gut, denn du fügst deinen Kommentar ja nicht immer hinter einen Text ein (wie jetzt). Da würde es zu viele Probleme geben. Besser ist da eine (abschaltbare aber standardmäßig aktivierte) Warnung, die einen nicht speichern läßt, wenn kein ~~~ im Text zu finden ist. Siehe auch Benutzer:Olliminatore/Unsigniert.js was ich in Benutzer:Spongo/monobook.js eingebunden habe. --Spongo ⇄ 15:45, 22. Aug 2006 (CEST)
Ich habe die Funktion um ein solches Kästchen erweitert. Ich glaube Spongo meinte dieses Script Olliminatore/signing.js (das andere ist für die Vorlage:Unsigniert). Danke für die (unterstützende) Werbung Spongo, schade aber, dass dieses bei Dir deaktiviert ist [9]. Ich würde gerne mehr Meinungen hören (gerne auch auf angegener Disku. Ps: Für's Erste ist alles machbar). -- Ολλίμίνατορέ 19:06, 22. Aug 2006 (CEST)
Ja, es war das falsche. Habe nicht genau hingeschaut. Habe es deaktiviert weil ich es nie benutzt habe, wollte aber sagen, dass sowas schon realisiert ist. --Spongo ⇄ 10:14, 23. Aug 2006 (CEST)

Linkfix und Anführungszeichen

Es wäre praktisch, wenn unter „Vorschau anzeigen“ alle über den Umweg eines Redirects oder, wichtiger, einer Begriffsklärung führenden Links sowie alle ""-Anführungszeichen rot hinterlegt erscheinen würden. So kann man, wenn man etwas anderes ändert, in einem Durchlauf auch solche Fehler, wenn sie wirklich Fehler sind, schnell erkennen und entfernen. Dadurch, dass es nur unter „Vorschau zeigen“ angezeigt wird, würde es aber den glatten Lesefluss nicht behindern.--Hannes2 Diskussion  14:10, 22. Aug 2006 (CEST)

Pro --Spongo ⇄ 15:39, 22. Aug 2006 (CEST)
Pro --Mg ☎ ☠ ❤ @ 19:16, 22. Aug 2006 (CEST)
Pro -- Matt1971 ♪♫♪ 23:49, 27. Aug 2006 (CEST)
Kontra Links auf Redirects müssen nicht falsch sein. Links auf BKLs entdeckt man mit hoher Zuverlässigkeit durch die Option "Kurze Artikel hervorheben" o.ä. und sind manchmal (aber seltener) auch angebracht. -- Amtiss, SNAFU ? 17:15, 5. Sep 2006 (CEST)
Ich habe ja auch nur vorgeschlagen, es unter „Vorschau“ zu zeigen, wo der Benutzer überprüfen kann, ob das so gehört oder nicht (und in den meisten Fällen ist wohl letzteres der Fall, insbesondere beim Redirect kann ich mir keine einzige Anwendungsmöglichkeit vorstellen). Die Hervorhebung kurzer Artikel würde dagegen auch im Lesemodus greifen, oder?--Hannes2 Diskussion  14:16, 13. Sep 2006 (CEST)

Bearbeitungskonflikt

Schön wäre es, wenn man bei einem Bearbeitungskonflikt nicht nur bei der gespeicherten Version auf „Speichern“ klicken könnte, sondern auch bei der eigenen Version. Da nämlich zumindest bei mir die meisten Bearbeitungskonflikte mit mir selbst passieren (wenn ich z. B. die Signatur oder einen gwichtigen Satz vergessen habe), würde so die arbeit wesentlich bequemer.--Hannes2 Diskussion  14:14, 22. Aug 2006 (CEST)

Dann machst du irgendwas falsch, gehst du im Browser zurück um Vergessenes anzufügen ? Mir passieren in solchen Situationen nie Bearbeitungskonflikte. Ansonsten hilft dir Strg + A, Strg + X und Strg + V (alles markieren, ausschneiden, einfügen). -- Amtiss, SNAFU ? 17:21, 5. Sep 2006 (CEST)
Ich gehe nicht im Browser zurück, sondern drücke auf Escape, meist aber zu spät, um die Speicherung zu stoppen. Copy&Paste benutze ich auch, aber die von mir vorgeschlagene Möglichekeit wäre halt bequemer.--Hannes2 Diskussion  17:28, 5. Sep 2006 (CEST)
Bearbeite einfach ordentlich, statt Bearbeitungskonflikte zu provozieren. Die Vorgehensweise mit Escape ist formal ja die Selbe wie ein Zurückgehen. Bei normalem Serverstatus schaffst du es eh nicht das Speichern zu verhindern, da die Daten recht schnell verschickt sind und höchstens die Antwort ein wenig länger dauert. -- Amtiss, SNAFU ? 18:19, 5. Sep 2006 (CEST)
Nachtrag: Eine weitere Möglichkeit mit einem positivem Nebeneffekt ist das Aktivieren der Option "Warne mich, wenn ich die Zusammenfassung beim Speichern vergesse." Das hat mir auch öfter geholfen, Vergessenes anzufügen.

Deppenleerzeichen

Namensraumbezeichnungen wie „Benutzer Diskussion“ oder „Wikipedia Diskussion“ sehen leicht nach Deppenleerzeichen aus. Könnte man diese Namensräume nicht in „Benutzer-Diskussion“ umbenennen? Es müsste sich dann eben einrichten lassen, dass die alten Bezeichnungen, ähnlich wie auch die englischen, automatisch auf die neuen weiterleiten.--Hannes2 Diskussion  21:51, 22. Aug 2006 (CEST)

Bin auch dafür. Die Reaktionen auf den Vorschlag überwältigen mich. 17:43, 19. Nov. 2006 (CET)
Dazu müsste man wahrscheinlich „nur“ den Inhalt der Namensraum-Variablen ändern, das dürfte für Admins kein Problem sein. Vielleicht mal hier anfragen. --Στέφανος (Stefan) ■ 18:01, 19. Nov. 2006 (CET)

„Weitere Sprachen“

Ich fände es gut, am Ende der Sprachbox, am Ende [besten 19:18, 23. Aug 2006 (CEST)] etwas eingerückt, einen Link auf eine der vielen Seiten zum Zhema WP-Sprachausgaben einzufügen (Linktext „Weitere“). Praktisch wäre das vor allem für die Hauptseite, wo Neulinge manchmal annehmen, die dort genannten Sprachen seien alles.--Hannes2 Diskussion  15:46, 23. Aug 2006 (CEST)

  1. Pro --Mg ☎ ☠ ❤ @

Bilder in Vorlagen

Wenn ein Bild in eine oft verwendete Vorlage (z. B. eine Navigationsleiste) eingebunden wurde, erscheinen auf derBildbeschreibungsseite Links zu all den Seiten, wo die Vorlage eingebunden ist. Wäre es nicht möglich, anstelle dieser Links nur den zur Vorlage und einen zu deren Whatlinkshere anzuzeigen (z. B. Vorlage:Spielwiese (0 Seiten)) oder die Seiten, die nur wegen der verwendeten Vorlage eingebunden werden, einzurücken (also etwa so:

--Hannes2 Diskussion  19:14, 23. Aug 2006 (CEST)

Hierzu möchte ich auch auf meinen Verbesserungsvorschlag "Links auf diese Seite" & Vorlageneinbindung hinweisen, der dieses Problem bei Vorlagen im Allgemeinen anspricht, und ebenfalls die Einrückung als Lösung vorschlägt.
--the one who was addicted (#) 18:19, 2. Okt 2006 (CEST)

Pro Verbergen von über Vorlagen verlinkte Seiten

Pro Einrückung von über Vorlagen verlinkte Seiten

  1. --the one who was addicted (#)

Kontra andere Darstellung von über Vorlagen verlinkte Seiten

Beobachten Funktion ausdiffernezieren

Es wäre schön wenn die Beobachten-Funktion so gestaltet werden könnte, dass man Artikel und dessen Diskussio getrennt beobachten könnte, also nicht immer beides. --Morray noch Fragen? 21:55, 27. Aug 2006 (CEST)

Das wäre tatsächlich schön. Standard sollte allerdings die Beobachtung von beidem bleiben. Aber die Möglichkeit, eines von beidem auszuschalten, fände ich auch hilfreich.--Hannes2 Diskussion  15:32, 5. Sep 2006 (CEST)

Relative Größenangaben bei thumbnails

Standardgröße bei Thumbs in Artikeln ist 180px Breite, die Höhe wird automagisch skaliert. Bei einem Mix von Hoch- und Querformatfotos oder -Grafiken führt das dazu, daß die Hochformatbilder im Verhältnis zu den anderen riesig groß dargestellt werden. Um die Proportionen zu wahren, werden die thumbs dann halt meist mit festen Pixelwerten eingebaut. Laut Bildertutorial soll man aber "Im Normalfall [...] die so genannten Thumbnails nicht skalieren, damit die Benutzer in ihren Einstellungen selbst festlegen können, wie groß diese angezeigt werden sollen.". Ich würde mir nun eine Funktion wünschen, die Thumbs relativ zu skalieren, so daß die Größe nicht festgenagelt ist, sondern weiterhin den Benutzereinstellungen folgen kann. Als Minimallösung könnte ich mir zwei zusätzliche Schlüsselwörter vorstellen, etwa so: 

 [[Image:Bild.jpg|thumbhalf|Beschreibung]]

bzw. 

 [[Image:Bild.jpg|thumbdouble|Beschreibung]]

Alternativ (und flexibler) könnte ich mir auch eine Prozentangabe vorstellen, also sowas wie: 

 [[Image:Bild.jpg|thumb|60%|Beschreibung]]

Wäre sowas prinzipiell machbar? Ach ja: Sorry, falls das schon mal hier thematisiert wurde, ich habe nix dazu gefunden. -- Smial 13:28, 3. Sep 2006 (CEST)

Wenn machbar, Pro. --Hannes2 Diskussion  17:45, 5. Sep 2006 (CEST)

  • starkes Pro auch von meiner Seite. (Dazu wünsche ich mir noch einstellbare Qualität des Skalers. Bei bestimmten Quellmaterialen, insbesondere bei Kontrasten ausschließlich im Chroma-Anteil (z.B. Rot-Grün-Grenzen oder Farbverläufen mit echtem Nutzinhalt wie Beschriftungen) wird wesentlich zu stark komprimiert.) --jha 01:21, 11. Sep 2006 (CEST)
lesen hier einklich irgendwelche Entwickler? Oder ist das eine WORN-Seite? -- Smial 13:35, 7. Nov. 2006 (CET)
Entwickler lesen Bugzilla, hier wird dieskuttiert, ob man es überhaupt an die Entwickler herantragen soll. Nicht ausgeschlossen, dass denoch jemand hier mitliest...--Badenserbub Briefkasten Bewerte mich! 20:58, 7. Nov. 2006 (CET)
Mh, dann habe ich die Sache hier völlig mißverstanden, sorry. Da ich nur rudimentär Englisch kann, hat sich das vermutlich erledigt? Ich jedenfalls kann das da nicht eintragen. -- Smial 21:58, 7. Nov. 2006 (CET)

Nochwas mit Bildern

Es ist manchmal eine chtes Problem, dass die felxiblen Größenangaben nur bei Thumbnails gehen und man alles andere entweder fest einstellen oder riesig groß machen muss. Schön wäre es, wenn man mit 

 [[Bild:Beispiel.png|thumbsize]]

rahmenlose Bilder einbinden könnte, deren Größe trotzdem in den Einstellungen geändert würde. --Hannes2 Diskussion  17:15, 9. Sep 2006 (CEST)

Wenn machbar, Pro ;-) -- Smial 01:09, 11. Sep 2006 (CEST)

Spezial:Emailuser

Zwei Vorschläge:

1. Es ist blöd, dass ich mit der E-Mail-Funktion nur Text versenden kann. So kann ich weder Formatierungen verschicken (die der Empfänger vielleicht lesen könnte), noch Dateien im Anhang mitschicken. Eine Adresse wie etwa emailuser.hannes2@mail.wikimedia.org wäre wesentlich vielfältiger einzusetzen als das jetzige Formular. Wäre so etwas möglich?

2. Da nicht jeder Englisch spricht und so etwas Unbedachtes tun könnte, sollte die E-Mail-Bestätigungsfunktion anders aufgebaut sein, dass nicht beim einfachen Folgen eines Links gleich die E-Mail bestätigt ist.

--Hannes2 Diskussion  17:45, 5. Sep 2006 (CEST)

Benutzerbeiträge

Die bei der Beobachtungsliste schon übliche Kennzeichnung neuer Artikel mit einem fetten Neu wäre auch dort schön. --Hannes2 Diskussion  17:48, 5. Sep 2006 (CEST)

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)

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)

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)

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:TMg/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}}, {{Unsigniert}}, 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: 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

das oben 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, 2, 3, 4, 5). Hier handelt es sich um einen Künstler, die Situation lässt sich aber natürlich auf jede x-beliebige Person mit Lemma (Politiker, Sportler, etc.) übertragen.

Problem: Weil einige der von diesem Vandalismus betroffenen Artikel eher selten besucht sind, fallen die Änderungen nicht immer auf und bleiben so über Tage, manchmal auch Monate stehen. Einer Verfolgung über die Liste der Benutzerbeiträge entzieht sich die IP meist dadurch, dass sie für jeden Edit eine neue IP vom DHCP-Server ihres Providers bezieht. Es ist also auch mit der persönlichen Beobachtungsliste eines angemeldeten Benutzers praktisch unmöglich, wirklich alle Änderungen zu finden.

Feature Request: Ich hätte gerne ein Feature ähnlich wie die persönliche Beobachtungsliste eines jeden angemeldeten Benutzers, mit dem ich alle Änderungen an Artikeln anzeigen lassen kann, die auf einen bestimmten Artikel verlinken. Im Grunde genommen also die Umkehrung des Features Recentchangeslinked, das Änderungen an Artikeln listet, die in dem Artikel verlinkt sind. Gefragt danach habe ich bereits unter Wikipedia:Fragen zur Wikipedia. --Le petit prince messagerie 03:09, 1. Okt 2006 (CEST)

Auch ich fände eine solche Funktion für sinnvoll. Es wäre auch nicht nur zur Vandalismusbekämpfung hilfreich, sondern z. B. auch wenn man Artikel, die aufeinander verlinken und mehr oder weniger gemeinsame Inhalte haben aktualisieren, ergänzen, ... will. Dann kann man Änderungen an Artikeln, die auf einen bestimmten Artikel verlinken, leichter aufspüren und übernehmen. -- ChaDDy ?! +/- 15:46, 1. Okt 2006 (CEST)

Pro Le petit prince, ChaDDy, Init, Στέφανος (Stefan) ■, Streifengrasmaus, Wiegels, Au ja!, Quilbert 問, Carolin

Kontra

suchabfrage modifizieren

moin moin,

hoffe, ich bin richtig hier. inwieweit ist es möglich, die suchabfrage für verwaiste disk.seiten dahingehend zu modifizieren, dass, ausser der endung "/Archiv XY", auch weitere endungen bei der abfrage herausgefiltert werden? viele seiten sind aktuelle baustellen/todo-listen. diese nach "/Archiv Baustelle" oder "/Archiv ToDo" zu verschieben, befriedigt aber nicht direkt, da "/Archiv Baustelle/ToDo" eher altes/abgeschlossenes impliziert, als aktuelles und somit nicht beachtet wird. bei einer letzten anfrage bzgl. einpflegung einer "ToDo"-liste in die originaldisk wurde mir bereits angeboten, wenn es um speicherplatz ginge, solle ich die archive löschen. das script der abfrage findet sich im archiv auf der disk. der o.g. wp-seite. gruß --ee auf ein wort... 11:58, 2. Okt 2006 (CEST)

Dialogue-Mapping-Tool

Wikipedia und Wikiversity brauchen in ihrer softwaretechnischen Infrastruktur ein Dialogue-Mapping-Tool wie z.B. dies oder wenigstens dies.

Die Argumentationsstruktur längerer Diskussionsprozesse, in denen eine Vielzahl von Argumenten und Gegenargumenten entwickelt werden, ist in Form eines Fließtextes mit fester zeitlicher Reihenfolge der Diskussionsbeiträge nach kurzer Zeit nicht mehr zu überblicken. Ein treffendes Beispiel ist die Diskussion über den Löschantrag der Kategorie "Pseudowissenschaft". Es entwickelt sich kein systematischer argumentbezogener Diskurs. Vielmehr wird dieser wesentlich durch die zufällige zeitliche Reihenfolge der einzelnen Beiträge strukturiert. Nach persönlicher Neigung führen die Teilnehmer in ihren jeweiligen Einzelbeiträgen die verschiedensten Argumente an. Welche davon im Verlauf der weiteren Diskussion aufgegriffen und gewürdigt werden und welche unbeachtet bleiben, hängt vorwiegend von den persönlichen Präferenzen der zufällig zeitlich nachfolgenden Diskussionsteilnehmer ab. Gerade besonders stichhaltige Argumente gehen bei dieser Anordnung oft unter - weil sie unbequem sind, werden sie nicht aufgegriffen.

Diese Diskussionsstruktur hat eine unbefriedigende Argumentationsqualität zur Folge (s. auch Argumentationstheorie). Eine argumentbezogene Anordnung eines derartigen Diskurses anstatt einer zeitlichen wäre erheblich effizienter. Liquid Threads wären bereits ein erheblicher Fortschritt. --Almeida 12:21, 3. Okt 2006 (CEST)

Wie's ausschaut, sollte man zu diesem Thema wohl besser eine eigene Diskussion anfangen, siehe oben: #Diskussionen komplett überarbeiten, #Diskussionen im Text / Bessere Nachvollziehbarkeit von Diskussionsketten, #Systematische Diskussionen (Erörterungen), #Besseres Forumssystem ... --the one who was addicted (#) 15:55, 3. Okt 2006 (CEST)

deaktivierung modifizieren

moin moin, tüftler

beim "deaktivieren auf eigenen wunsch" wäre es eine deutliche hilfe, diese zu vereinfachen. derzeit muss man die benutzerdisk. durch den deaktiviert-baustein ersetzten und anschließend schützen = zwei voneinander unabhängige arbeitsschritte. anschließend muss man die benutzerseite löschen, durch den deaktiviert-baustein neu erstellen und dann schützen = drei voneinander unabhängige arbeitsschritte. gesamt also muss man fünfmal eine seite anklicken, um einen vorgang durchzuführen. als ich letztens eine seite zurückverschoben habe, konnte man die zielseite gleichzeitig löschen und darauf zurückverschieben. etwas in dieser art sollte auch beim deaktivieren möglich sein, zumindest jeweils für die benutzer- und benutzerdisk.seite. gruß --ee auf ein wort... 14:24, 3. Okt 2006 (CEST)

Thumbnails auch bei Galerien!

Hallo, ich halte es für sinnvoll, bei einer Bildergalerie auch die Funktion „Thumb“ zuzulassen, damit der unter Einstellungen eingegebener Wert für die Vorschaubilder auch bei Galerien zum tragen kommt. Damit hätten dann alle Bilder auf einer Seite ein einheitliches Format. In Galerien bewirkt der Beschreibungstext auch meistens mehrere Zeilenumbrüche, was optisch auch nicht so schön ist. Gruß -- Rainer L 18:05, 9. Okt. 2006 (CEST)

Kategorien bei Benutzerregistrierung

  • Ich denke es wäre sehr nützlich, wenn das Profil eines Nutzers bestimmte Kategorien enthalten würde, die der Nutzer bei der Registrierung angeben kann. Diese sollten dann automatisch dazu dienen Benutzer in Kategorien wie "Benutzer aus Stadt", "???-sprachiger Benutzer", "Beruf", etc. einzuordnen. Damit hätte man dann bei zu planenden Stammtischen, QS-Maßnahmen, LA, fachspezifischen Fragen, usw. immer die entsprechenden Ansprechpartner und könnte alle relevanten Personen erreichen. Natürlich sollte der Benutzer frei wählen können, ob er diese Daten angeben will oder nicht. --Captaingrog 11:02, 20. Okt. 2006 (CEST)
Pro ich bin dafür, wenn sich die Einstellung nachträglich ändern läßt, da es manchmal ja nötig wird, wenn man umzieht oder einen neuen Beruf oder eine neue Sprache lernt. --Tlustulimu 22:26, 7. Jan. 2007 (CET)
Man müsste doch nur die entsprechenden Babels so erweitern, dass sie auch Kategorien angeben, oder? --Versusray | Diskutiere mich! 19:25, 21. Jul. 2007 (CEST)

Wikipedia-Lade-Geschwindigkeit

Hier beschreiben die Gurus, wie man Webseiten mit wenig drastischen Änderungen beschleunigen kann. Würde wohl auch WP gut tun. igel+- 17:10, 31. Okt. 2006 (CET)

Du hast den Link vergessen: [10] -- Amtiss, SNAFU ? 19:44, 31. Okt. 2006 (CET)
Genau den meinte ich. igel+- 00:32, 1. Nov. 2006 (CET)

Infokästen für Fachbegriffe

Hallo,

häufig, wenn man in ein Thema einsteigt, gibt es einige Begriffe, mit denen man nichts anzufangen weiß. In den Hauptartikeln zu diesen Begriffen ist es meist schwierig, die relevanten Informationen schnell zu finden, und im Artikel werden die Begriffe nicht erklärt (schließlich gibts ja den Hauptartikel).

Könnte man nicht über ein JavaScript eine Funktion hinzufügen, das, wenn jemand mit der Maus über ein Symbol neben einem Fachbegriff geht, ein Infokasten mit einer kurzen Erklärung einblendet? (so ungefähr wie die unterstrichenen Wörter in Foren, bei denen dann Werbung eingeblendet wird) Das würde den Lesefluss und die Verständlichkeit von Artikeln in einigen Fällen sicherlich erhöhen.

pens.ar(nicht signierter Beitrag von Pens.ar (Diskussion | Beiträge) )

Hallo! Das könntest du, nur leicht gegen die Html-Spec verstoßend, auch umsonst haben, durch das abbr-Tag. igel+- 11:52, 10. Nov. 2006 (CET)

Auf der englischen WP gibt es en:Template:H:title ohne abbr. Wikipeditor 17:10, 19. Nov. 2006 (CET)

Spezial:Disambiguations

Hallo, ich möchte vorschlagen, diese Spezialseite zu ändern oder ihr eine zweite zur Seite zu stellen mit dem folgenden Inhalt:

Aufgelistet werden nicht die einzelnen Verweise, sondern nur die BKL-Seiten selbst, und dahinter die Anzahl der Verweise auf die BKL (auch indirekte Verweise über eine Weiterleitung). Die Liste wird absteigend nach der Anzahl der Verweise geordnet.

Vorteile dieser neuen Liste:

  • die größten Problemverursacher stehen am Anfang der Liste und können direkt angegangen werden. In der jetzigen Liste sind sie nicht direkt erkennbar. Nicht immer müssen nämlich die einzelnen Verweise umgebogen werden, es kann vielleicht auch eine geeignete Verschiebung helfen.
  • bei den BKL-Modellen II und III gibt es ja immer mindestens einen Rückverweis auf die BKL. Diese erlaubten Verweise würden in der neuen Liste ganz am Ende erscheinen und dadurch nicht (wie jetzt) die Bearbeitung der echten Problemfälle behindern.
  • diejenigen, die an der Auflösung dieser Probleme arbeiten, hätten einen besseren Überblick darüber, wie groß der Bereich eigentlich ist. Ein Fortschritt wäre besser sichtbar. Momentan weiß man nämlich gar nicht, an welcher Stufe man sich befindet.

Wasseralm 17:56, 11. Nov. 2006 (CET)

Hat sich wohl vorerst erledigt, eine solche Liste gibt es bereits unter Benutzer:Redf0x/Top-BKS Wasseralm 21:36, 21. Nov. 2006 (CET)

Mit einem Klick an den Artikelanfang....

Das gibt es bereits als Code in doppelt geschweiften Klammern, ich habe es aber nur ein einziges Mal in einem sehr langen Artikel gesehen und dann auch bei intensivem Suchen in den diversen Wekzeugen nicht wieder gefunden.
Hier ein anderer Vorschlag, um das (lästige) wieder Hochwandern an den Anfang mit Hilfe der langweiligen Bildlaufleiste zu vermeiden, ohne etwas in die Artikel einbauen zu müssen:
Auf der linken Seite in der Leiste, die u. a. das Suchfeld enthält, unterhalb des jeweiigen jetzigen Inhalts in gleichmäßigen Abständen (knapp eine Bildschirmhöhe) "irgendetwas zum Anklicken" organisieren, was den Sprung zum Seitenanfang (Artikelanfang) bewirkt. Dort könnte zum Beispiel in blau stehen
Zum Seitenanfang
--Dr.cueppers 21:22, 17. Nov. 2006 (CET)

Dazu gibt es die Taste Pos 1. Wikipeditor 17:06, 19. Nov. 2006 (CET)

Kurze Artikel

"Zu Beginn der Liste werden vor allem Seiten mit den Vorlagen Gesperrtes Lemma und Falschschreibung angezeigt. Tatsächliche kurze Artikel finden sich erst am Ende der Liste." Das stimmt schon lang nicht mehr. Die Liste hat nur 1000 Einträge, und alle sind durch die Bank Vorlagen-Artikel (auch: URV etc.) Ich fände es sinnvoll, die Liste zu verlängern. Noch sinnvoller fände ich es, wenn man derlei Vorlagen ausblenden könnte. ανταίος Δ Β

Kurzfristig hilft es, wenn man die Artikel mit „Gesperrtem Lemma“ Baustein mit Augenmaß löscht. Vieles davon wird sich mittlerweile erledigt haben, so dass nicht mit einem Wiedergänger zu rechnen ist. Was wir wirklich brauchen, ist eine Funktion in der Software, mit der man auch nicht vorhandene Artikel sperren kann: Bug 2919: Protecting non-existent pages. Ob sich die Anzahl von 1000 Artikel verlängern lässt, weiß ich nicht, ich fürchte jedoch, dass dies aus Performancegründen nicht der Fall sein wird. --Raymond Disk. Bew. 17:26, 27. Dez. 2006 (CET)

Weblinks in der Zusammenfassung

Hallo!
Ich fände es schön, wenn man externe Weblinks in der Zusammenfassungszeile so formatieren könnte, wie im Artikel. Das hätte den Vorteil, dass der Bearbeitungskommentar übersichtlich bleibt, auch wenn man (mehrere) Quellen verlinkt. Siehe dazu auch Fragen zur Wikipedia. --Στέφανος (Stefan) ± ■ 16:13, 2. Dez. 2006 (CET)
Dafür: Στέφανος (Stefan) ± ■
Dagegen:

Die Zusammenfassungszeile ist viel zu kurz für mehrere solcher Links, Interwikilinks funktionieren dagegen bereits, siehe meine Antwort auf WP:FZW. Die Wikisyntax für Weblink zu nutzen heißt nochmehr des knappen Platzes wegzunehmen, auch wenn es bei einzelnen Weblinks natürlich komfortabler wäre. -- Amtiss, SNAFU ? 17:02, 3. Dez. 2006 (CET)
Naja, 200 Zeichen passen da rein. Warum sollte man dann nicht vielleicht zwei bis drei Weblinks, die die Quelle angeben, schön formatiert (und somit auch in der Versionsgeschichte übersichtlicher!) einfügen können? Ich halte an dem Vorschlag fest! --Στέφανος (Stefan) ± ■  22:37, 17. Jan. 2007 (CET)

Besser Möglichkeiten, um Unfug-Beiträge zu finden

Hallo, ich habe folgende Vorschläge für die Seiten "Spezial:Newpages" und "Spezial:Recentchanges", um schneller Unfug-Beiträge zu finden. Ich suche generell, nach neuen Beiträgen von anonymen Benutzern und gucke mir diese dann an. So habe ich auch schon einige Löschkandidaten gefunden.

-Für die Seite Spezial:Recentchanges würde ich mir wünschen, dass man nur nach anonymen Benutzer suchen kann.

-Für die Seite Spezial:Newpages würd ich mir wünschen, dass man "Neue Beiträge" und "Alte Beiträge" ein-/ausblenden kann.

Falls man sich denkt, dass die bestehenden Möglichkeiten vollkommen ausreichen, um Unfug-Beiträge zu finden, frage ich mich dann aber, warum ich damit so oft Erfolg hatte und der erste war der den Beitrag entdeckt hat. (Ist keine Kritik nur ein Hinweis)

Mokros 15:44, 9. Dez. 2006 (CET)

Hallo Mokros, für Spezial:Recentchanges gibt es Dein vorgeschlagenes Feature bereits, Du musst in der URL nur die Parameter „hideanons=1“ bzw. „hideliu=1“ übergeben: Anonyme Nutzer ausblenden und Angemeldete Benutzer ausblenden. Viele Grüße, --Le petit prince messagerie 16:20, 9. Dez. 2006 (CET) P.S.: Wo es gerade um „Unfugsbeiträge“ geht: <SCHAMLOSE WERBUNG> Vielleicht interessiert Dich ja auch mein Feature-Request einer Beobachtungsliste für Artikel, die auf einen Artikel verlinken. </SCHAMLOSE WERBUNG>. :-) --Le petit prince messagerie 16:33, 9. Dez. 2006 (CET)
---
Hallo le petit prince, diese Funktionen kenne und nutze ich auch, jedoch würde ich dann nur gern die neuen Beiträge der anonymen Benutzer sehen, also alle Beiträge filtern, welche nicht neu sind. Liebe Grüsse Mokros 16:45, 9. Dez. 2006 (CET)
Meine Aussage bezog sich wie gesagt nur auf Spezial:Recentchanges, auf der ich Deinen Vorschlag, „nur nach anonymen Benutzern suchen“ zu können, eigentlich verwirklicht sehe. Kann es sein, dass wir das Problem gerade aus zwei unterschiedlichen Blickwinkeln betrachten? - Wenn ich Dich richtig verstehe, willst Du auf Spezial:Newpages alle angemeldeten Benutzer ausblenden, was in der Tat noch nicht geht. Viele Grüße, --Le petit prince messagerie 18:15, 9. Dez. 2006 (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)
Stimme Diwas zu. SD1990 18:27, 18. Feb. 2008 (CET)

Metainfo in Sprachennamen

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

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:TMg/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)

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)

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2006&oldid=209442612“