Wikipedia:Verbesserungsvorschläge/Feature-Requests
aus Wikipedia, der freien Enzyklopädie
Abkürzung: WP:FR !!! Bitte zuerst lesen, da nicht alle Verbesserungswünsche hierher gehören !!! Auf dieser Seite sollen Feature-Requests gesammelt werden, also Vorschläge, Wünsche oder Forderungen, der Software neue Funktionen hinzuzufügen bzw. eine vorhandene Funktionalität zu ändern. Wenn sie sich durchsetzten, werden sie an die Entwickler weitergeleitet. Durch die so erreichte Zustimmung haben sinnvolle Änderungen eine größere Chance.
Bitte gebt auf dieser Seite mit drei Tilden (nein, nicht vier ) unter »dafür« oder »dagegen« eure Stimme ab, welche Feature requests an die Entwickler weitergeleitet werden sollen.
|
[Bearbeiten] Erledigtes/Archiviertes 11. April
[Bearbeiten] zur Umsetzung weitergeleitet oder bereits umgesetzt
- Cursor im Suchfeld: Bugzilla:1864
- Trennung von Artikel und Meta-Daten: Magnus Manske sitzt da dran
- Wikipedia Lernkartei: Schöne Wünsche, siehe meta:Wikiquiz, Bugzilla:1625
- Diagramme/Auswertung: Hilfe:Zeitleisten Graphviz-Erweiterung existiert
- Fußnoten: erledigt. siehe Patch für Fussnoten, div. contra-stimmen
- Versionen-Liste durchsuchen!: Request auf Sourceforge, viel Pro, wenig contra, vermutlich verdammt teuer
- Artikel-Größe in Versionsgeschichte: Bugzilla:1865
- Button - Artikel per email versenden: siehe Bug 227: "mail this article"-button.
- einfachere Kontrolle mehrerer Änderungen eines Nutzers: Problem ist den Entwicklern bekannt
- Alphabetische Navigation in "Alle eingetragenen Benutzer": viel pro, kein contra -> Bugzilla:1866
- Interwiki-Selbst-Link nicht anzeigen: -> Bugzilla:1868
- Diff für Benutzerbeiträge: erledigt mit Mediawiki 1.4
- Einloggen in mehrere Wikipedias zugleich: daran wird gearbeitet, siehe meta:Single login
- Einbindung von World-Wind-Hotspot-Links: Funktion wurde umgesetzt, siehe Wikipedia:WikiProjekt Georeferenzierung
- Verschieben mit Kommentar: Bugzilla:1867
- Seiten nur für anonyme Benutzer sperren-> Bugzilla:675
- Seiten nur für bestimmte Benutzer sperren-> Bugzilla:674
- Kategorie auch in Redirects zulassen: -> Bugzilla:1476 und Hilfe:Weiterleitung#Kategorisierung
[Bearbeiten] abgelehnt
- Hervorhebung des beschriebenen Begriffs im Text: div. contra-stimmen
- Alphabetischer Index in Oberfläche aufnehmen: div. contra-stimmen
- Funktion Artikel ignorieren: viele contras
- Weiterleitung zur zuletzt benutzte Seite abstellen: div. contras
- REDIRECT auf Überschriften: von den Entwicklern als nicht sinnvoll ungefähr schon hundertmal abgelehnt
[Bearbeiten] ?
Wenn jemand weiß (nicht nur vermutet), was mit folgenden Vorschlägen passiert ist, dann bitte auch einsortieren und mit einem Link zum weiteren Verlauf versehen, danke. FWHS 14:02, 22. Aug 2005 (CEST)
- Alternatives Menü für den Bearbeitungsmodus: kein Mediawiki Feature request, sondern eine Sache der Konfiguration
- Skin Nostalgie: Suchformular oben: 2:1
- Case-insensitive Suchfunktion: Jaaaaaaaa (mal sehen, was mit Lucene-Search kommt, siehe meta:Fulltext search engines)
- Warnung wenn ein Artikel bereits bearbeitet wird: viele Pros, aber wahrscheinlich nicht sinnvoll realisierbar
[Bearbeiten] Softwareänderung nötig
[Bearbeiten] 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)
[Bearbeiten] Links auf Stubseiten
Ich fände es gut, wenn Links auf Stubs oder sehr kurzen Artikeln (keine Begriffserkläungsseiten etc.) durch eine gesonderte Farbe z.B. orange kenntlich gemacht werden könnte. Das würde nämlich die Argumente gegen Stubs außer Kraft setzen. Technisch sollte sich das relativ einfach realisieren lassen. -- Netzize 05:23, 15. Aug 2005 (CEST)
- Gute Idee. Aber nur für angemeldete Benutzer und nur wenn sie dieses Feature haben wollen. Man sollte es also auch jederzeit abstellen können. --Träumer 11:17, 15. Aug 2005 (CEST)
- Wieso nur für angemeldete Benutzer? -- Netzize 02:29, 16. Aug 2005 (CEST)
Präzisierung des Feature Requests:
-
- Weil nicht jeder Benutzer der Wikipedia auch ein Schreiber ist. Der fühlt sich doch durch solche Links eher gestört (meine Meinung) --141.53.194.251 10:44, 31. Aug 2005 (CEST)
Es ist, wie ich nun erfahren habe, wohl möglich durch entsprechende Einstellungen in der Benutzerseite und Verwendung eines entsprechenden CSS-Syle Links auf kurze Seite in anderer Farbe erscheinen zu lassen. Allerdings werden dadurch nicht alle Links auf Stubs erfasst, der Stubbaustein wird also nicht erkannt. -- Netzize 05:13, 16. Aug 2005 (CEST)
-
- beim Firefox sehe ich Links auf eine Seite unter einer bestimmten Zeichenanzahl in einer rötlichen Farbe (anders als unverlinkt.) habe aber keine speziellen Einstellungen getroffen. Es ist ganz praktisch, weil man auch sieht, ob der Link auf eine Bgkl geht. --K@rl 09:14, 17. Aug 2005 (CEST)
- Kürze allein ist nicht immer ein wichtiges Merkmal. Es gibt sicherlich gültige Lemmata, die mit drei Sätzen erschöpfend behandelt werden können. Aber die Kennzeichnung von Stubs würde mir gefallen und sicherlich auch vielen anderen bei der Arbeit in der Wikipedia helfen. Ich persönlich würde allerdings die Farbe grün (=noch im Wachstum befindlich) bevorzugen. :-) Diese Kennzeichnung sollte nur bei angemeldeten Benutzer wirken und von diesen einstellbar sein. --Birger (Diskussion) 17:39, 26. Aug 2005 (CEST)
Vielleicht ein Vorschlag: Das mit der Linkfarbe halte ich auch für nicht so sinnvoll, ich könnte mit aber vorstellen, dass hinter dem Link auf einen Stub ein Icon kommt (ähnlich wie bei den externen Links), das dann z.B. über den Tooltip des Browsers noch einen kleinen Hinweis gibt (im HTML-Tag des Icons z.B. mit <img src="stubicon.gif" alt="Platzhalterartikel">). --Merkosh O=O 15:19, 20. Sep 2005 (CEST)
{{Rot|Farandole}} erzeugt Vorlage:Rot: Ich habe vor kurzem – ohne von dieser Diskussion gewusst zu haben – die Vorlagen Vorlage:Rot und Vorlage:Rot2 für das Portal:Tanz erstellt, die auf primitive Art und Weise genau diese Aufgabe erfüllen: {{Rot|Aattetur}} erzeugt den markierten Link Vorlage:Rot, der auf einen Stub oder mangelhaften Artikel zeigt. In Farbgebung und Syntax habe ich mich so nah wie möglich an die bisherigen Links gehalten, so dass selbst Neulinge ohne zusätzlichen Lernaufwand ein intuitives Verständnis für die Bedeutung und Verwendung entwickeln. Der entstehende Effekt ist enorm und auf der [[Diskussion Vorlage:Rot|Diskussionsseite}} haben sich bereits einige Pro-Stimmen für diese Art der Markierung gemeldet. Der große Nachteil bei der Realisierung als Vorlage ist: Ist der Artikel überarbeitet, müssen alle Links auf ihn von Hand geändert werden - das ist ein gigantischer Verwaltungsaufwand, der nur bei sehr selten referenzierten Artikeln von Hand zu bewältigen ist. Genau deshalb ist die „Möglichkeit individueller Anpassung mit duzenden Farben für zig Linktypen“ (Zitat), keineswegs „völlig ausreichend“, wie das einige Contra-Stimmer sehen; die Wahl der Farbe für die Markierung müsste als Software-Feature automatisiert werden. Ob weiterhin Stub-Bausteine verwendet werden sollen, wird derzeit heftig diskutiert – diese Art der Markierung könnte Stub-Bausteine überflüssig machen. --Thetawave 11:05, 10. Dez 2005 (CET)
-
-
- Widerspricht dem gesamten MediaWiki-Linkkonzept (einfach, konsequent logisch) und stellt dieses auf den Kopf. Keine Unterstützung von Entwicklerseite. --:Bdk: 01:15, 12. Dez 2005 (CET)
-
- Da es auch sehr kurze Artikel gibt, die vollständig sind, halte ich die Länge des Artikels als alleiniges Kriterium für unzureichend, sofern man nicht gute Artikel gezielt mit Kommentarzeilen (werden diese mitgezählt?) über die Längenschwelle hebt. Dies gilt zumindest für den allgemeinen Benutzer und sofern die Linkfarbe eine Verwandschaft zu den roten Links nahelegt. Schon für gute Stubs würde ich einen rot-ähnlichen Link ablehnen.-- StefanL 15:28, 10. Dez 2005 (CET)
- Weiterhin gibt es natürlich auch schlechte Artikel, die die Längenschwelle überschreiten und eine rot-ähnliche Linkkennzeichnung verdient haben. Man sollte einen neuen Namensraum Entwurf anlegen, in den schlechte Artikel einfach verschoben werden. Damit könnte man sich viele Löschdiskussionen sparen. Bei Links könnten dann z.B. folgenden Farben verwendet werden:
- rot: Artikel ist weder im Artikel- noch im Entwurfsnamensraum vorhanden.
- orange: Artikel ist nur im Entwurfsnamensraum vorhanden. Link wird automatisch dorthin weitergeleitet.
- blau: Artikel ist im Artikelnamensraum vorhanden.
- grün (optional): Wie blau, aber Artikel mit geringem Umfang. Längenschwelle sollte aber deutlich oberhalb des Stubniveaus liegen. Die Unterscheidung grün/blau würde es dann dem Benutzer ermöglichen, schnell zu erkennen, welche Artikel umfangreiche Informationen enthalten. Die Kennzeichnung grün wäre dabei uch nicht als Kennzeichnung mangelhafter Artikel anzusehen.-- StefanL 15:28, 10. Dez 2005 (CET)
-
- Es gibt keinen Entwurfsnamensraum, dafür bitte gesonderte feature request starten, bitte nicht verschiedene Anfragen durchmischen. --:Bdk: 01:15, 12. Dez 2005 (CET)
-
- Halte ich persönlich für zu kompliziert: Zu viele Farben, das stiftet bloß Verwirrung und erzeugt einen furchtbar unprofessionellen optischen Eindruck. Wenn schon verschiedene Farben, dann würde ich einen fließenden Übergang zwischen Rot und Blau verwenden. Aber mal was anderes: Warum das Ganze nicht über die Benutzereinstellungen optional machen und jeden Nutzer selbst entscheiden lassen, ob er (a) zu kurze, (b) schlechte, (c) lesenswerte oder (d) exzellente Artikel – oder beliebige Kombinationen davon – speziell hervorgehoben haben möchte? Immerhin existiert das für kurze Seiten bereits und wem es nicht gefällt, der kann die Funktion deaktiviert lassen. --Thetawave 00:51, 12. Dez 2005 (CET)
- Es wird für nicht mal 1.000 exzellente und ein paar andere Artikel keine neue Softwarefunktion geben. Abfragen nach jeweils aktuellem Baustein-/Vorlagengehalt sind sehr aufwändig zu realisieren. Und kurze Artikel, mithin nach der herkömmlichen Definition Stubs, sind bereits "über die Benutzereinstellungen optional" markierbar (wie oft muss man das noch schreiben?). --:Bdk: 01:15, 12. Dez 2005 (CET)
- Halte ich persönlich für zu kompliziert: Zu viele Farben, das stiftet bloß Verwirrung und erzeugt einen furchtbar unprofessionellen optischen Eindruck. Wenn schon verschiedene Farben, dann würde ich einen fließenden Übergang zwischen Rot und Blau verwenden. Aber mal was anderes: Warum das Ganze nicht über die Benutzereinstellungen optional machen und jeden Nutzer selbst entscheiden lassen, ob er (a) zu kurze, (b) schlechte, (c) lesenswerte oder (d) exzellente Artikel – oder beliebige Kombinationen davon – speziell hervorgehoben haben möchte? Immerhin existiert das für kurze Seiten bereits und wem es nicht gefällt, der kann die Funktion deaktiviert lassen. --Thetawave 00:51, 12. Dez 2005 (CET)
- Dafür: Träumer, Netzize, Daniel, Birger (Diskussion), Merkosh, FWHS (Die Erkennung von Bausteinen des verlinkten Artikels am Link sollte möglich sein.), Prolineserver, Thetawave Begründung siehe oben.
- Dagegen: :Bdk: (Begründung), Frank Schulenburg (schließe mich Bdk an: die momentane Funktionalität reicht aus), Schlurcher ??? , Löschfix, Es gibt nur eine Methode, wie mit unvollkommenen Artikeln umgegangen werden muss, - sie verbessern. Und das gilt eigentlich für alle Artikel, - immer. Sie dem Namensraum zu entziehen, ist da eher kontraproduktiv. Auch Stubs erfüllen einen Mindestzweck für den Nur-User. In dem man ihn bunt macht, wird er nicht besser. Ein schwacher Artikel der sich lange nicht verbessert, wird vermutlich nicht sehr gebraucht. (Was ihn deswegen aber nicht disqualifiziert.)--Löschfix 04:19, 24. Aug 2006 (CEST)
Über Special:Preferences/Verschiedenes realisierbar/kein Stubbaustein mehr da :) --Flominator 16:08, 7. Jan. 2007 (CET)
[Bearbeiten] Kleinere Bilder auch kleiner
Vor allem bei PNGs passiert es immer wieder, dass man sich vor dem Hochladen bemüht hat, durch Farbreduktion auch die Dateigröße zu reduzieren. Es wäre positiv, wenn diese Einstellungen auch beim Verkleinern der Bilder durch MediaWiki erhalten bleiben, weil ansonsten solche Dinge passieren, dass bei (komprimierten) PNG-Grafiken (Beispiel: Bild:Flagge Baden Wuerttemberg.png, rund 7kB) das Original kleiner ist als das (über MediaWiki) verkleinerte Bild (hier auf Baden-Württemberg, ca. 30kB). --hedavid 16:47, 20. Apr 2004 (CEST)
- das bild auf Baden-Württemberg wurde aus inhaltlichen gründen ausgetauscht, das problem ist auf einer alten version zu sehen. -- plasmagunman 13:29, 31. Aug 2004 (CEST)
- Ich denke das hat gute Gründe, vermutlich würden viele Grafiken dann in der Verkleinerung hässlich aussehen, weil es keine Mischfarben gibt und sich daher Harte Kanten ergeben. --Stefan-Xp 11:18, 31. Aug 2005 (CEST)
- Richtig, eine qualitativ bessere Bildskalierung (durch Interpolation) halte ich für wichtiger als ein paar KB mehr oder weniger bei der Übertragung. -- Memset 12:01, 2. Aug 2006 (CEST)
- Ich denke das hat gute Gründe, vermutlich würden viele Grafiken dann in der Verkleinerung hässlich aussehen, weil es keine Mischfarben gibt und sich daher Harte Kanten ergeben. --Stefan-Xp 11:18, 31. Aug 2005 (CEST)
Wenn die Software auf die Vorschaubilder pngrewrite und OptiPNG anwenden würde, könnte man da noch einiges (ca. 1/3) an Größe einsparen. --Phrood 01:06, 7. Aug 2006 (CEST)
- Dafür: Wikinator (Diskussion), Matthäus Wander, plasmagunman, ¶eerBr Þ, APPER, Langec, zeno, FWHS
- Dagegen: Simi, Memset
[Bearbeiten] Manuelle Formelformatierung
Mir ist aufgefallen, dass der Wikipedia-Formelparser, anders als LaTeX 2ε, vorangestellte Abstandsmarken wie \hspace, \quad, \qquad konsequent ignoriert, und zwar selbst dann, wenn man eine leere Textbox voranstellt. Auf diese Weise ist es unmöglich, untereinander stehende Formeln zueinander horizontal auszurichten. Dies ist erforderlich, um die bei der – für mehrzeilige Formeln vorgeschlagene – \matrix-Umgebung entstehende Schriftverkleinerung und Zentrierung (die bei unterschiedlich langen Formelzeilen zu unansehnlichem Erscheinungsbild führt) zu umgehen. Da LaTeX Horizontalräume auch am Zeilenanfang berücksichtigt und der Wiki-Formelparser innerhalb der Formel diese Befehle auch brav ausführt, vermute ich, dass das Überspringen dieser Befehle am Formelbeginn ein beabsichtigtes Feature ist, dessen Sinn sich mir jedoch komplett entzieht.
Meine Bitte daher: Wäre es möglich, dieses zusätzliche "Feature" wieder zu entfernen, um manuelles Ausrichten zu ermöglichen?--SiriusB 20:09, 12. Aug 2004 (CEST)
[Bearbeiten] Spezialseite: Artikel eines Benutzers
Ich wuerde gerne eine Seite haben, wo man alle Artikel sehen kann, an denen ein Benutzer mitgearbeitet hat, praktisch sowas wie Special:Contributions, aber eben jeden Artikel nur einmal gelistet, und moeglicherweise eine Filtermoeglichkeit, um kleine Aenderungen auszublenden oder um nur Artikel anzuzeigen, die er angelegt hat. Michael 20:48, 17. Feb 2004 (CET)
- So etwas gibt es doch schon: Rufe mal eine Benutzerseite auf, z.B. Benutzer:tsor. Dort gibt es links den Punkt "Benutzerbeiträge". -- tsor 15:51, 21. Feb 2004 (CET)
- Nein, nicht ganz. Ich sagte ja schon, sowas wie Special:Contributions (das ist ja die Seite auf die du mich hinweisst), aber eben zumindest mal soweit gefiltert, dass jeder Arikel nur einmal drauf steht. Das aktuelle Special:Contributions listet alle Beiträge, also z.B. bei mir einige Aenderungen an Wikipedia:Löschkandidaten. Das soll eben nur einmal vorkommen. Und sollte es noch einfach zu realisieren sein, dann eben noch mit Filtermoeglichkeit um Artikel auszufiltern, an denen der Benutzer nur kleine Aenderungen beigetragen hat, und um nur Arikel anzuzeigen, die der Benutzer angelegt hat -- Michael 16:30, 21. Feb 2004 (CET)
- Besser fände ich die Filterung auf bestimmte Seiten: z.B. "wie sehr beteiligt sich ein Benutzer bei den Löschkandidaten, wie sehr bei Ich brauche Hilfe", also Anzeige aller Änderungen auf einer bestimmten Seite. Könnte man wahrscheinlich relativ einfach von Spezial:Log übernehmen sowas. Und dann von mir aus ein Häkchen "jede Seite nur einmal anzeigen" davorschalten für den ursprünglichen Vorschlag. --BLueFiSH ?! 16:12, 23. Mär 2005 (CET)
- Dafür: tsor, Napa, Elian Φ, Wikinator (Diskussion), stw ⊗, stefan (?!), addicted, [[Benutzer:PeerBr|¶eerBr Þ]] Benutzer:Rdb? Spauli, Schusch, Langec, Friese, Habakuk <><, Wolfgang1018, BLueFiSH ?!, FWHS, Sarkana
- Dagegen:
- Kommentar:
- In diesem Zuge wär's auch noch gleich nicht schlecht wenn jene Artikel gekennzeichnet würden, welche erstens von "mir" angelegt wurden, und zweitens jene die von "mir" zuletzt bearbeitet wurden gekennzeichnet würden. --addicted 10:10, 31. Aug 2004 (CEST)
-
- Das wird (teilweise ?) bei dem Ersatztool für Kate angezeigt. Schaut mal unter Wikipedia:Stimmberechtigung, da müsste ein Link auf das Tool zu finden sein. -- 212.144.200.101 01:43, 31. Dez 2005 (CET) aka Benutzer:Amtiss
[Bearbeiten] Zeiteinstellung
Könnte man die Zeiteinstellung auf Spezial:Preferences so programmieren, dass man statt des Unterschieds zur Serverzeit eine Zeitzone einstellen kann (z.B. "CEST"), die sich dann bei Beginn und Ende der Sommerzeit automatisch anpasst? Falls der Zeitpunkt der Umstellung national unterschiedlich sein sollte, könnte man auch das Land eingeben, in dem man sich üblicherweise aufhält. Alternative: Jeweils zu Beginn/Ende der Sommerzeit irgendwo einen Hinweis für Neulinge hinterlassen, dass die Zeitzone auf Spezial:Preferences eingestellt werden kann - das könnte die Zeit des Rätselns und Suchens ersparen, die ich gerade hatte :-) --Tebdi 18:34, 21. Nov 2003 (CET)
- Dafür: TG, Wikinator (Diskussion), addicted, ¶eerBr Þ, APPER, Baikonur, Atamari, BLueFiSH ?!, FWHS, Prolineserver, --Pelz 23:27, 2. Dez 2005 (CET)
- Dagegen:
[Bearbeiten] Neue Features
Ich wollte auch hier nochmal ein paar neue Features anregen. Es geht derzeit um folgende Dinge, die ich (auf englisch) im Meta-Wiki beschrieben habe:
- Vielleicht fällt das auch unter "neue Features"; mir fehlt so etwas wie Breadcrumbs bzw. ein Trail, wie das in manchen Wikis implementiert ist; gemeint ist damit eine dynamisch aktualisierte Liste der zuvor besuchten Seiten (z.B. "Hauptseite" - "Letzte Änderungen" - "Neue Seite" - "Verlinkte Seite").
- Gerade beim Editieren finde ich es extrem lästig (und riskant), mit der Browser- Navigation durch "fertige" Seiten und solchen mit Editbox zu blättern. Geht das nur mir so? --asb 01:04, 27. Nov 2003 (CET)
- Ich glaube es ist der Reviewers Mode gemeint, nicht [[w:Rewievers Mode]] ...wenn dem so ist bin ích dafür ;) Telcontar
- Dafür:Wikinator (Diskussion), [[Benutzer:PeerBr|¶eerBr Þ]], Telcontar
- Dagegen:
[Bearbeiten] Beobachtungsliste und gelöschte Artikel
Hallo, ich würde es sehr praktisch finden, dass wenn ein beobachteter Artikel gelöscht wird, dieses auch in der Beobachtungsliste aufgeführt wird. RobbyBer 14:20, 21. Mär 2004 (CET)
- Klarstellung: gelöschte Artikel bleiben derzeit in der Beobachtungsliste, legt also jemand den Artikel wieder an und ändert, taucht er wieder auf. Bei dem feature request geht es darum, die Löschung in der Liste genau wie Änderungen anzuzeigen. --Elian Φ 02:36, 27. Aug 2004 (CEST)
- Dafür: tsor, Napa, mijobe, Sikilai, G, Elian Φ, Hoch auf einem Baum, Wikinator (Diskussion), Melancholie, stw ⊗, Hubi, Berni Benutzer:Rdb?, addicted, D. Düsentrieb (?!), APPER, Langec, Okrumnow, zeno, Jcornelius , Baikonur, BLueFiSH ?!, Flominator, joni Δ 21:34, 11. Jul 2005 (CEST), FWHS, Royd, Schlurcher ??? , Atamari …, Gunter Krebs Δ, Birger (Diskussion), Ce, Prolineserver, Sloyment (Ich habe mich gerade wieder darüber ärgern müssen!), --Pelz 23:28, 2. Dez 2005 (CET), 212.144.200.101 aka Benutzer:Amtiss, M@rkus, M.A. (Marc-André Aßbrock), Libro, Hannes2 Diskussion , Der Umschattige talk to me, Daniel73480
- Dagegen:
- Kommentar: Da das ganze ja in der Software angepasst wird, dürfte sich das auch auf die Spezialseite "Änderungen an verlinkten Seiten" auswirken. Wenn nicht, dann könnte dieses Feature da auch ermöglicht werden. 212.144.200.101 01:49, 31. Dez 2005 (CET)
[Bearbeiten] Suchseite
Wenn die Seite Spezial:Search aufgerufen wird, erscheint eine Seite mit dem Titel Suchergebnisse für die Suche von "". Das ist natürlich nicht glücklich. Wie bei der Diskussion auf Diskussion:Hauptseite#An_Herrn_Fuchs festgestellt, mag dieses für den sehenden Menschen ehr ein optisches Problem. Für die Barrierefreiheit der Wikipedia hingegen noch ungünstiger. Daher die Frage, in wie weit gibt es dort möglichkeiten diese Seite zu verändern? RobbyBer 21:40, 1. Jun 2004 (CEST)
[Bearbeiten] Sidebar
Wäre es möglich, eine Wikipedia-Browser-Sidebar einzurichten? Im Prinzip bräuchte man dafür einen speziellen Skin und eine Spezialseite, auf der die relevanten Daten schön "knapp" formatiert sind. Ich weiß jetzt nicht, wie die Seiten programmiert sind und wie aufwändig das wäre, aber das wäre ein wirklich sinnvolles Feature um schnell Zugriff auf alle wichtigen Funktionen und bspw. auch auf die Beobachtungsliste zu haben. Ich stelle mir das ganze etwa so vor :-) --Drumknott 22:27, 18. Apr 2004 (CEST)
- Dafür: Jorges, Aineias, MikeKrueger, Wikinator (Diskussion), oknieps, Kinley, Jakov, FWHS, Kolossos, dee.lite
- Dagegen: Elian Φ
Prinzipiell ein cooles Feature, aber wir haben schon eine Sidebar. Außerdem fürchte ich, dass das zuviel Resourcen verbraucht. --Elian Φ 01:45, 27. Aug 2004 (CEST)
Leider ist der gegebene Link nicht mehr sichtbar und mir vollkommen unklar, was gemeint ist. Auf den Wikipedia-Seiten gibt es ja alles verlinkt, also ist etwas gemeint, dass in den Browser integriert wird und auf allen Seiten leichten Zugriff ermöglicht? Das wird es nicht geben, da browserabhängig. In Opera kann man beliebige HTML-Seiten als Sidebar einrichten und sich so halt selber Links zusammenstellen, die man jederzeit leicht einblenden kann. Also ohne die Beispielseite ist unklar, was gemeint ist. --APPER\☺☹ 21:37, 6. Nov 2004 (CET)
- Als Beispiel kann ich dir die Sidebar der Tagesschau anbieten.
Dort dann zB die Spezial:Recentchanges eintragen wäre ziemlich praktisch --Kinley 20:30, 29. Jan 2005 (CET)
- Auch ich kenn mich leider gerade nicht ganz aus was Elian mit "haben wir schon" meint. Hab bisher keine gefunden. -- Jakov 14:21, 14. Jul 2005 (CEST)
-
- Anmerkung: Die linke Seite unter dem WP-Logo wird auch gerne Sidebar genannt. Zum Nachschlagen könnte die "echte" Sidebar so aussehen dann natürlich mit der kompletten Wikipedia-DB und etwas mehr Design. Auch ist die Kategorienstruktur der kompletten Wikipedia als Sidebar denkbar. Alles relativ unabhängig vom WP-Erscheinungsbild so das es eigentlich keine negativen Stimmen geben dürfte. Kolossos 14:19, 4. Dez 2005 (CET)
[Bearbeiten] Beobachtungsliste (erl)
In der Beobachtungsliste hätte ich gerne analog zu Spezial:Recentchanges die Anzahl Änderungen an dem beobachteten Artikel am Tag. Das würde mir vor allem als kleine Änderung gekennzeichnete Änderung ersparen in der History nachzusehen, ob nicht vorher noch jemand eine große Änderung vorgenommen hat. -- Mijobe 17:45, 8. Jul 2004 (CEST)
- Bei mehreren Bearbeitungen am besten den Bearbeitungskommentar weglassen und stattdessen eine Liste aller Bearbeiter (des Tages bzw. nach der letzten eigenen Bearbeitung) einfügen.-- StefanL 23:17, 14. Aug 2005 (CEST)
- Dafür: tsor, Napa, Wikinator (Diskussion), PeerBr, Rdb, Simi, Flominator, FWHS, StefanL
- Dagegen:
Variante: Dieses Problem wird angesichts der vielen Bots immer dringender: Man muss bei jedem Eintrag in der Beobachtungsliste die Versionsgeschichte öffnen - nervig. Kann man nicht einfach einen Modus bieten z. B. über "Einstellungen", der alle Änderungen anzeigt und nicht nur die letzte? Super wäre, wenn in diesem Fall bei den älteren Änderungen der Unterschied-Button dann die Diffenz zwischen vorheriger und aktueller(!) Version anzeigen würde, denn das ist genau das, was letztlich interessiert. Richte hier einfach mal frech einen zweiten Abstimmungsplatz dazu ein ;-). --Wolfgangbeyer 21:09, 27. Aug 2004 (CEST)
- Dafür: Wolfgangbeyer, mijobe, ¶eerBr Þ Spauli, Schusch, Ce, D. Düsentrieb (?!), APPER, Langec, BLueFiSH ?!, G, StangL0r, Flominator, FWHS, StefanL, Wegner8, PaulePanter, --Pelz 23:31, 2. Dez 2005 (CET), M@rkus, Libro, Royd
- Dagegen:
Das per Benutzreinstellungen machen zu können, würde vieles erschlagen. Gute Idee. Mijobe 11:45, 2. Sep 2004 (CEST)
- Dies sollte am besten Artikelweise wählbar sein, sonst würde ein einziger Artikel mit hoher Änderungsfrequenz in der Beobachtungsliste die Nutzung praktisch unmöglich machen.-- StefanL 23:17, 14. Aug 2005 (CEST)
- Erledigt Bots-Filter und Beobachtungsliste ist seit ein paar Tagen unter Spezial:Preferences/einstellbar. -- Ολλίμίνατορέ •Ω• 09:23, 1. Mai 2006 (CEST)
[Bearbeiten] 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)
- 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)
-
-
-
- So etwas in der Richtung geht mittlerweile mit dem Catscan --Flominator 16:11, 7. Jan. 2007 (CET)
-
-
- Dafür: Napa, Melancholie, ¶eerBr Þ, Benutzer:Rdb?, Simi, addicted, mijobe, Langec, Okrumnow, FloSch, Redoute, Jcornelius, , Wolfgang1018, Atamari, BLueFiSH ?!, Flominator, StefanL, FWHS, Träumer, NiTen (Discworld), Stefan ■, M@rkus 23:59, 7. Jan 2006 (CET), M.A. (Marc-André Aßbrock), --Tlustulimu 22:08, 30. Jan 2006 (CET), BlueCücü, Libro, Nicor 01:44, 11. Apr 2006 (CEST), Fg68at -- Matt1971 ♫♪ 15:09, 10. Apr 2006 (CEST) Jutta234 --Pelz 07:50, 11. Apr 2006 (CEST), Hannes2 Diskussion , , Staro1
- Dagegen:
[Bearbeiten] 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)
- 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)
- Dafür:
- Dagegen: Dr. Schorsch, Mokros
[Bearbeiten] Benutzerbenachrichtigung 1: Bilderlöschungen
Es gibt ja den Löschen-Baustein, der alle Seiten, die diesen Beitrag enthalten automatisch auf einer Spezialseite erscheinen lässt. Wegen der umständlichen Löschprozedur für Bilder, müllt leider langsam die Datenbank mit Bildern zu. Ich habe folgenden Vorschlag:
Könnte man nicht einen Baustein erfinden, den man auf die Bildseite setzt und die Software automatisch den Benutzer darüber informiert (z. B. auf seiner Diskussionsseite), damit er ggf. die Lizenz nachtragen kann etc. und gleichzeitig nach Ablauf einer Frist von meinetwegen zehn Tagen das Bild auf einer Spezialseite erscheinen lässt. Durch die 10 Tage ist gewährleistet, dass der Benutzer ausreichend Zeit hatte, das Bild erneut zu sichten und ggf. fehlende Lizenzangaben nachzutragen. Auf diese Weise hätten die Admins ein verlässliches Mittel, Bilder zu löschen und die Benutzer hätten ein sehr einfaches Mittel, Bilder zum Löschen vorzuschlagen, ohne eine komplizierte und abschreckende Prozedur durchzuführen (Löschkandidatenseite aufsuchen, Bildnamen hinkopieren, Benutzer informieren, Aufpassen, dass der Benutzer genug Zeit zur Reaktion hatte, ...). Würde also sicher die Datenbank rasch entrümpeln. Stern !? 10:26, 22. Aug 2004 (CEST)
- Prima Idee das derjenige der das Bild hochgeladen hat automatisch eine Nachricht bekommt. Hilft aber ja nur bei Benutzern die registriert sind. --devil Diskussion 11:25, 13. Jun 2005 (CEST)
- Ist kein Problem denn nur registrierte Benutzer können auch bilder hochladen.
- Dafür: Philipendula, Baikonur, Devil_m25, Raymond, FWHS, Flominator, Matt314, M@rkus
- Dagegen:
[Bearbeiten] Benutzerbenachrichtigung 2: Sie haben neue Nachrichten
Noch einmal von einer früheren Version hereingestellt, nachdem es erst 3 Tage da stand: -- K@rl 22:01, 21. Aug 2004 (CEST) Praktisch wäre ein Feature, das man auf Diskussionsseiten für einen Benutzer setzen könnte, sodass auch der andere Benutzer die o.a. Nachricht erhält. So könnte man Diskussionen auf einer Seite zusammenhalten und nicht von der eigenen auf die fremde Diskusionsseite springen muss. (das wäre auch für andere, die die Diskussion verfolgen wesentlich einfacher) Vorstellen könnte ich mir am Ende eines Disk.beitrages auf der eigenen Seite [[@Benutzer:XYZ]] so bekommt der Benutzer XYZ die Mitteilung "Sie haben eine neu Nachricht". --K@rl 13:56, 18. Aug 2004 (CEST)
- gute Idee. Und noch eine: die Meldung sollte - insbesondere bei IPs - so groß sein, dass man gar nicht weiterarbeiten kann, ohne sie zu beachten. TheK(?!) 14:24, 18. Aug 2004 (CEST)
- die meisten machen das so, dass sie die Diskussionsseite des anderen auf die Beobachtungsliste setzen und dass man eine Diskussion entweder auf der eigenen oder der Diskussionsseite des anderen führt. Ich wüßte jetzt nicht, wie man den Vorschlag realisieren könnte (außer für den Benutzernamensraum eine Ausnahme zu machen und dort zur Edit-Box noch ein Feld zu plazieren "Benachrichtige diesen Benutzer"). Auf jeden Fall kompliziert. --Elian Φ 22:43, 21. Aug 2004 (CEST)
- Ich weiß dass es nicht leicht und schnell zu realisieren ist. Ich weiß schon dass man die Diskusion nur auf einer der beiden Seiten führen sollte. Das Problem ist aber, wenn die Zeit zu lange zwischen den Antworten ist, dann verliert man sie aus der Beobachtungsliste. Ich weiß nicht wie die derzeitigen Nachrichten arbeiten, vielleicht findet sich da ein Ansatz. -- K@rl 23:15, 21. Aug 2004 (CEST)
- Ich hatte einen ähnlichen Vorschlagschon mal für die Portale gemacht. Da dort oft Artikel diskutiert werden, wäre es hilfreich, wenn die Diskussion auf der Artikelseite gespiegelt würde, da nicht jeder sich das Beobachten einer stark frequentierten Portalseite antun möchte. Mijobe 15:28, 23. Aug 2004 (CEST)
- Ich weiß dass es nicht leicht und schnell zu realisieren ist. Ich weiß schon dass man die Diskusion nur auf einer der beiden Seiten führen sollte. Das Problem ist aber, wenn die Zeit zu lange zwischen den Antworten ist, dann verliert man sie aus der Beobachtungsliste. Ich weiß nicht wie die derzeitigen Nachrichten arbeiten, vielleicht findet sich da ein Ansatz. -- K@rl 23:15, 21. Aug 2004 (CEST)
- die meisten machen das so, dass sie die Diskussionsseite des anderen auf die Beobachtungsliste setzen und dass man eine Diskussion entweder auf der eigenen oder der Diskussionsseite des anderen führt. Ich wüßte jetzt nicht, wie man den Vorschlag realisieren könnte (außer für den Benutzernamensraum eine Ausnahme zu machen und dort zur Edit-Box noch ein Feld zu plazieren "Benachrichtige diesen Benutzer"). Auf jeden Fall kompliziert. --Elian Φ 22:43, 21. Aug 2004 (CEST)
- Dafür:Simi, Temistokles, FWHS, Sarkana, --Pelz 23:33, 2. Dez 2005 (CET)
- Dagegen:
[Bearbeiten] 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)
- 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.
- 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. -- Darrn 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)
- Dafür: Mijobe, marilyn.hanson, Wolfgang1018, ¶eerBr Þ Raymond Spauli, Ce, Okrumnow, FloSch, Baikonur, thomas g graf ~ diskussion, Jondor ✉, the one who was addicted (#), StefanL
- Dagegen:BLueFiSH ✉!, Darrn, Schlurcher ??? , Ολλίμίνατορέ Ω
am besten wäre es, wenn man den default-button einstellen könnte. --joni Δ 18:04, 21. Jul 2005 (CEST)
- dafür: joni Δ, Darrn, FWHS, the one who was addicted (#), Sarkana, Three Of Twelve
- dagegen:
- 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
[Bearbeiten] Link bei Ergebnismeldung von "Seite verschieben"
Wenn ich eine Seite verschiebe, dann erhalte ich eine Meldung (sinngemäß) : "Artikel A nach B verschoben." A und B sind dabei Links. Wenn ich allerdings auf A klicke, lande ich auf B, da A ja automatisch eine Redirect-Seite wird. Ich fände es schön wenn hier die Redirect-Seite und nicht die Seite, auf die verwiesen wird angezeigt wird, weil man doch oftmals auf der alten Seite was ändern will (z.B. Löschwarnung anbringen, bei Tippfehler im Namen).--Berni 22:36, 31. Aug 2004 (CEST)
- Hier fehlt eigentlich nur der Zusatz "&redirect=no" --addicted 21:08, 8. Sep 2004 (CEST)
- Dafür: mijobe, marilyn.hanson, Benutzer:Rdb?, addicted, Schusch, Baikonur, BLueFiSH ?!, NB > +, Flominator, FWHS, Schlurcher ??? , Libro
- Dagegen:
Und wann wird so etwas umgesetzt bzw. wie? --NB > + 22:06, 4. Mai 2005 (CEST)
[Bearbeiten] Upload
[Bearbeiten] Upload-Lizenz
Da die deutsche Wikipedia nur PD und GFDL für Bilder zulässt, sollten dafür Häkchen vorgesehen werden von denen eines gesetzt sein muss. Ist keines gesetzt, wird der Upload verweigert. An den Text des Benutzers wird automatisch die gewählte Lizenz angehängt. --Mijobe 12:41, 1. Sep 2004 (CEST)
- Dafür: marilyn.hanson, Stern !?, Conny, Temistokles, dee.lite
- Dagegen:
- Für extended Version (siehe Diskussionspunkt contra): addicted Huebi Benutzer:Rdb? 07:37, 8. Sep 2004 (CEST) Raymond, Schusch, D. Düsentrieb (?!), Baikonur, Jakov, FWHS
- Kommentar: Auf der Mailingliste gabs schon mal eine Diskussion wegen des Uploadformulars, dabei ist folgendes Formular rausgekommen: [1]. Ob das in der nächsten Version verwendet wird, weiß ich nicht, aber es würde immerhin die Bilder ohne Lizenzangabe rausfiltern: Bleibt der Uploader dann bei "unbekannt/weiß nicht", wird das hochgeladene Bild automatisch in die [[Kategorie:Bilder ohne Lizenzangabe]] einsortiert. Benutzer:Rdb? 11:19, 6. Sep 2004 (CEST)
- contra Das geht mir nicht weit genug. Es sollten auch Felder zur Quelle und evtl weitere Eingabemöglichkeiten vorhanden sein. Ob man nun ein PD und ein GNUFDL Haeckchen hat statt eines GNUFDL Haekchens wird nicht die Leute hindern, die das jetzt schon standardmaessig per se anklicken, Bilder upzuloaden. Die Felder solltenauch dann gleich in die Beschreibungsseite kopiert werden, damit man dort die Lizenz und Quelle nicht mehr haendisch nachtragen muss. Ein Texteingabefeld, indem man bewusst PD oder GNU FDL eintragen muss finde ich eine staerkere psychologische Hemmschwelle als so ein Haekchen. --Huebi 14:12, 6. Sep 2004 (CEST)
- Ich möchte da eigentlich keine Hemmschwelle aufbauen, sondern lediglich für Klarheit sorgen. Hemmschwellen sollten bei der Mitarbeit an der Wikipedia möglichst wenige vorhanden sein. --Mijobe 15:02, 6. Sep 2004 (CEST)
-
- Keine Hemmschwelle zieht aber auf der Adminseite und "Kontrolleurseite" wieder maechtig Arbeit nach, denn es kostet einfach viel Zeit Bilder ohne Lizenz/Mit falscher Lizent zu finden und zu elimineren. Und grade bei Bildern ist der Wildwuchs recht gross und es wird sehr schlampig gearbeitet an dieser Stelle. Die Hemmschwelle, etwas in ein Forumalr einzutragen und nicht nur ein Haekchen zu setzen ist IMHO gering genug, das sich engagierte Leute dies auch antun, zudem wenn die Abreitserpsarnis lockt, nicht noch mal explizit auf die bearbeiten Seite zu muessen und dort alles nachtragen muessen. Es gibt jedoch viele Benutzer, die mal eben nur ein Boild hochladen und einbauen und sonst nicht viel, da ist der Verlust wirklich nicht gross. --Huebi 15:26, 6. Sep 2004 (CEST)
-
- Ich stimme Huebi zu. Die Quelle und die genaue Lizenzart sollte angegeben werden, das würde bedeuten, daß sich die Leute wenigstens Gedanken gemacht haben. Und ein paar kleinere Hemmschwellen tun der wikipedia mal ganz gut. --[[Benutzer:Spacecaptain|Spacecaptain Bild:Signatur Spacecaptain.jpg]] 15:05, 6. Sep 2004 (CEST)
-
- Auch ich stimme Huebi zu. Wenn da nur zwei Checkboxen sind, ist das zu verlockend einfach irgendwas anzuwählen, was anstatt zu fehlender zu falscher Lizenzinformation führt, was widerum in meinen Augen noch schlimmer ist als ersteres. --addicted 16:14, 7. Sep 2004 (CEST)
-
- Für Hubis Vorschlag mit so einer Listenauswahl wie auf [2]. Ich denke man könnte die Lizenzen ruhig etwas feiner Gliedern wie in: Wikipedia:Lizenzvorlagen für Bilder, dann hat man alles gleich richtig in der Bildvorlage. Ein Feld für den Namen des Urhebers etc. ist nicht schlecht, aber mir nicht so wichtig. Tabacha 17:08, 7. Sep 2004 (CEST)
-
-
- Wikipedia:Lizenzvorlagen für Bilder ist mir zu duenn, ich haette gern noch optionale Felder für Quelle, beschreibung (jeztzt schon vorhanden), Forogtaf/Zeichner. Das ganz wird dann fein saeuberlich gleich eingetragen, so daß ich nicht nochmal auf die bearbeiten Seite muss. Das ist am Anfang etwas mehr Arbeit, aber im Endeffekt dann doch weniger --Huebi 20:55, 7. Sep 2004 (CEST)
- Du kannst gerne die Vorlagen erweitern, Vorlagen akzeptieren mittlerweile Parameter, so dass dies notfalls sogar ohne eine weitere Edit-Operation von der Upload-Seite aus machbar wäre ... --zeno 13:34, 8. Sep 2004 (CEST)
- Wikipedia:Lizenzvorlagen für Bilder ist mir zu duenn, ich haette gern noch optionale Felder für Quelle, beschreibung (jeztzt schon vorhanden), Forogtaf/Zeichner. Das ganz wird dann fein saeuberlich gleich eingetragen, so daß ich nicht nochmal auf die bearbeiten Seite muss. Das ist am Anfang etwas mehr Arbeit, aber im Endeffekt dann doch weniger --Huebi 20:55, 7. Sep 2004 (CEST)
-
-
- Ich bin unbedingt für Huebis Vorschlag. Ein Hemmschwelle gerade bei Bildern ist leider wichtig, so wenig sinnvoll Hemmschwellen in der WP ansonsten sind. --Raymond 10:24, 8. Sep 2004 (CEST)
Ich finde, dass der Vorschlag zur Beschreibung von Bildern in ein Formular zu Beschreibung von Bildern mutieren sollte, welches dann die Daten sinnvoll und standardisert zusammenfasst. Die Lizenz sollte dann kein Eingabefeld sondern ein dropdown sein. Und das feld Quelle darf nicht leer sein. -- Jakov 20:05, 18. Jul 2005 (CEST)
- ich finde, eine hemmschwelle ist nicht nötig, wenn es den leuten leicht gemacht wird sich wirklich auszukennen. ich sehe nämlich das fehlverhalten als folge der unübersichtlichkeit.
vorschlag für eine art checkbox zum uploaden der bilder (oder gar einen uploadmanager) ... (ergänzungen erwünscht)
- user, schriftliches feld, pflicht
- Description: Was stellt das Bild dar?
- Source: Woher stammt das Bild? (ggf. URL oder "selbst fotografiert") [-> Klickbox für "selbst fotografiert"]
- Upload von User: [-> wenn eingeloggt, automatisch ausgefüllt] [Autor finde ich mißverständlich]
- Datum der Entstehung/Erstveröffentlichung: [Kalender zum auswählen]
- user, multiple choice, pflicht
- lizenzbausteine [modifizierbar. private/kommerzielle nutzung. mit/ohne bedingung. usw.]
- verwendbar für wikiprojekte: [metawiki, wikibooks, wikipedia, ...]
- user, klickbox
- dieses bild darf durch ein besseres ersetzt werden
- other_versions: [-> suche in allen von user hochgeladenen bildern]
- user, schriftliches feld, bei bedarf
- Notes
- wikipedia, automatisches feld
- datum bild eingestellt
- exif
ebay beispielsweise macht es doch schön vor mit diesen formularen ...
[Bearbeiten] Upload-Weiterleitung
Bisher wird immer die Uploadseite für den nächsten Upload angezeigt. Da ich aber jedes hochgeladene Bild kontrolliere, muss ich immer erst zur Bildseite wechseln. Ein guter Kompromiss wäre einen Thumb des gerade hochgeladenen Bildes mit anzuzeigen. --Mijobe 12:47, 1. Sep 2004 (CEST)
- Dafür: marilyn.hanson Benutzer:Rdb?, FWHS
- Dagegen:
[Bearbeiten] ISSNs als Magig Link
Es wäre schön wenn ISSN Nummern in Literaturangaben genaus wie ISBN Numern automatisch als Link dagestellt werden können. Ziel dieses Links könnte z.B. die Zeitschriftendatenbank sein. --PatrickD 13:53, 8. Sep 2004 (CEST)
- Dafür:Simi, marilyn.hanson, Flominator, FWHS, Libro
- Dagegen:
[Bearbeiten] Tooltips
Bei vielen Kleinigkeiten wäre es hilfreich Tooltips mit einschliessen zu können. Zum Beispiel der Begriff Laden beim Pferd rechtfertigt keinen eigenen Artikel, es stört aber auch, jedesmal wenn man den Begriff benutzt dranzuschreiben nicht mit Zähnen besetzter Raum zwischen Schneidezähnen und Backenzähnen im Unterkiefer. Um so etwas zu vermeiden (erzeugt lediglich Satzungetüme) wäre es hilfreich Tooltips zu haben (die kleine Kästchen die zB angezeigt werden, wenn die Maus im Navigationsblock über Wikipedia Portal steht). Wer den Begriff nicht kennt, findet ihn erklärt indem er einfach die Maus draufstellt, wer ihn kennt, wird nicht mit einem Zusatz belästigt, den er nicht braucht. --Mijobe 17:16, 20. Sep 2004 (CEST)
- Da ein solcher Tooltip meines Wissens nur an einen Link zu binden ist, muss auf jeden Fall ein Artikel dahinter stehen (im Fall Laden wäre das zB Anatomie des Pferdes), der dann aber wesentlich mehr enthalten kann, als das Stichwort vermuten läßt. --Mijobe 21:24, 20. Sep 2004 (CEST)
-
- Mein Wissen war mal wieder unvollständig. Man kann Tooltips auch ohne Links implementieren. Momentan wird der Tooltip bei Links schon genutzt, zeigt aber unsinnigerweise nur das Ziel an (zeigt mir der Browser in der Statuszeile auch schon). --Mijobe 16:53, 28. Sep 2004 (CEST)
-
-
- Auch und gerade bei Links auf Artikel wären Tooltips gut. Oftmals ist es lästig einem Link folgen zu müssen weil man mit dem Begriff auf den er verweist nichts anfangen kann. Hier wäre eine kurze Definition im Tooltip sinnvoll. Klever wäre wenn automatisch der erste Satz des verlinkten Artikels als Tooltip angezeigt werden würde. Dies würde verhindern, dass Definitionen doppelt gepflegt werden müssten. --Lars Mengel 09:36, 27. Okt 2004 (CEST)
-
-
-
-
- in gewissem maße ist das auch schon jetzt möglich, per vorlage.
- so:
- code:
Laden {{Tooltip|nicht mit Zähnen besetzter Raum zwischen Schneidezähnen und Backenzähnen im Unterkiefer}}
- vorlagencode:
<small title="{{{1}}}">(?)</small>
- resultat: Laden (?)
- code:
- so:
- direkt für das wort oder die wörter den tooltip zu setzen, halte ich für höchst ungünstig, da es sonst sehr unwahrscheinlich ist, wenn man einen artikel liest, dass man dann auch ein wort mit tooltip abbekommt, wenn man seine maus auf eines hält, das man so nicht kennt.
- „Klever wäre wenn automatisch der erste Satz des verlinkten Artikels als Tooltip angezeigt werden würde.“
- das finde ich auch; und dazu bräuchte man dann auch eine softwareänderung. wie könnte das system aussehen?
- mfg --joni Δ 21:48, 29. Jun 2005 (CEST)
- in gewissem maße ist das auch schon jetzt möglich, per vorlage.
-
-
[Bearbeiten] Siehe auch Eintrag ähnlich wie Kategorie
Ich halte es für sinnvoll, ein Feature wie für Kategorien, die irgendwo im Text stehen können und dann zusammengefasst am Ende des Textes auftauchen, auch eine Eintragmöglichkeit für Siehe auch in der Art [[siehe:Anderer Artikel]] einzuführen. Damit könnte man solche Verweise auch z.B. in Vorlagen einbauen und die Verweise erscheinen zusammen mit Verweisen aus dem Text in einer einheitlichen Form am Ende des Textes. Die Form [[siehe:Name der Seite|angezeigter Text]] sollte auch unterstützt werden. --Okrumnow 10:23, 28. Sep 2004 (CEST)
- Dafür:
- Dagegen: Oracle of truth (ich denke es ist im Moment manuell so ganz gut gelöst), zeno, Libro
[Bearbeiten] Liste Neuer Artikel und Artikelfuss
In der Liste der neuen Artikel sollte auch die Anzahl bisheriger Edits angezeigt werden. Habe gerade mal wieder einen Fall gehabt, wo der Inhalt eines Artikels durch ein nachfolgendes Edit zerstört und der zerstörte Artikel prompt zur Schnelllöschung markiert wurde. Außerdem wäre es schön, wenn die Bemerkung unter dem Artikel Diese Seite wurde zuletzt geändert um geändert werden könnte in Diese Seite wurde xxx mal geändert zuletzt um. --Mijobe 16:37, 28. Sep 2004 (CEST)
- Dafür: marilyn.hanson, Temistokles, Flominator, FWHS
- Dagegen:
[Bearbeiten] Liste Artikelverschiebungen
Eine Artikelverschiebung ist mitunter nur schwer nachvollziehbar. Es wäre schön, wenn jede Verschiebung analog zu Löschungen, auf einer separaten Seite protokolliert würden. Insbesondere bei Vandalismus erleichtert das das Leben sehr. --Mijobe 21:01, 12. Okt 2004 (CEST)
- Dafür: zeno, Nina, Schusch, Temistokles, Habakuk <><, Gunter Krebs Δ, FWHS
- Dagegen:
[Bearbeiten] 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 :
- 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
[Bearbeiten] Begrenzte Sperrfunktion / "Lock-Tag"
Meiner Meinung nach wäre es sinnvoll, einen "Sperr-tag" in der Wikipedia einzubauen, um dem häufigen Kritikpunkt "subtiler Vandalismus" etwas entgegenzusetzten. So könnte man mit einem Sperr-Befehl feststehende Daten schützen, beispielweise der Beginn des zweiten Weltkrieges, Sterbedaten, etc.. Dies würde verhindern, dass dieser schwer zu erkennende Vandalismus die Glaubwürdigkeit der Wikipedia schmälert. Der Sperrbefehl sollte natürlich eine ausschließlich den Admins zur Verfügung stehendes Werkzeug sein, ansonsten ist es wirkungslos. (Ich bin übrigens KEIN Admin, bevor es Protest gibt). ---Man-u 15:07, 13. Feb 2005 (CET)
- Das ist leider ziemlich unpraktikabel. Du müsstest den Quelltext mit hunderten Tags vollpumpen, um alles zu sichern. Und wie soll man bestimmte Bereiche einer Textarea von Änderungen ausschließen? Alle Möglichkeiten, das technisch zu realisieren, würden das Bearbeiten derart erschweren, das keiner mehr Lust hätte, irgendwas zu machen. Und die angeführte Änderung des Beginns des Zweiten Weltkriegs sollte auch so als Vandalismus erkannt werden. Ich möchte behaupten, dass dieser Vorschlag unmöglich in praktikabler Weise realisierbar ist. --::Slomox:: >< 21:27, 13. Feb 2005 (CET)
-
- Ich hatte mir das so vorgestellt:
Albert Einstein (* /S/14. März 1879\S\ in Ulm; † /S/18. April 1955\s\ in Princeton, USA), usw.
Hätte meiner Meinung nach keine einschränkende Wirkung, da bei einem ausgereiften Personenartikel der erste Satz wohl nie bearbeitet wird, aber Dinge wie Geburtsdaten von Schiller, Goethe oder Einstein, deren genaue Geburtsdaten nicht zur normalen Allgemeinbildung zählen und (absichtlich eingebaute) Fehler daher schwer zu erkennen sind. Ganz zu schweigen von den Daten weniger bedeutender Persönlichkeiten wie irgendwelcher Bundestagsabgeordneten. In dieser begrenzten Form wäre es meiner Meinung nach ein durchaus sinnvolles Werkzeug um den Vandalismus einzuschränken.
- Es wäre aber auch ein ideales Werkzeug für Vandalen, um ihren Vandalismus zu konservieren und damit ihren Schaden zu vergrößern: Stell Dir mal vor, ein Vandale schreibt an den Anfang eines Artikels: /S/Dieser Artikel erzählt nur Schwachsinn.\S\ Dann könnte ein normaler Nutzer das nicht mehr entfernen; die einzige Möglichkeit, das loszuwerden, wäre, wenn ein Admin dies entdeckt oder von einem normalen Nutzer aufmerksam gemacht wird.
- Neben dem Missbrauch durch Vandalen besteht auch die Missbrauchsgefahr bei Edit-Wars: Wenn jemand seine Version partout durchsetzen will, dann kann er einfach seine Version als unveränderlich markieren.
- Ein Ausweg wäre vielleicht, wenn nur Admins solche "Teilsperrungen" vornehmen können. Dann bleibt aber immer noch die Frage der Implementierung. Da man nicht verhindern kann, dass etwas, was sich in der Edit-Box befindet, auch editiert wird, müsste man die Ursprungsversion nachträglich wieder einfügen. Wie das zuverlässig passieren soll, ist mir nicht klar (immerhin könnte der Text drumherum geändert worden sein).
- Sinnvoller wären wohl erweiterte Beobachtungsfunktionen (z.B., dass man einen eigenen Beobachtungseintrag für einen bestimmten Absatz eines Artikels einrichten kann). Allerdings befürchte ich, dass das wiederum Probleme mit der Server-Last bringen würde. --Ce 10:18, 29. Sep 2005 (CEST)
- Dafür:
- Dagegen: Libro
[Bearbeiten] 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
[Bearbeiten] Schaltfläche für Serienänderungen einbauen
Nach Verschiebe-Aktionen z.B. wird es oft nötig, gleich etliche abhängige Verweise zu korrigieren. Das geht zu langsam, wenn man den "Go back" Button des Browsers benutzt. Eine Schaltfläche "Zurück zum Artikel" ohne Anzeigen der erfolgten Bearbeitung wäre ein großer Anreiz, diese zeitraubenden "seriellen Änderungen" auch tatsächlich zu machen. Temistokles 21:11, 13. Feb 2005 (CET)
- Dafür:
- Dagegen:
- Kommentar:
[Bearbeiten] Autmoatisches Einfügen der gängigen Abkürzung, z.B. Video Home System = VHS
moin, ich würde gerne sehen, das man innerhalb des artikels (per tag oder wie auch immer) bestimmen könnte, ob man bei einer einordnung der kategorie hinter dem richtigen namen die gängige abkürzung zu sehen ist und man nicht den artikel verschieben muss (also kein Video Home System nach Video Home System (VHS) sonst würden die lniks zu elendig lang, vor allem wenn man dahinter noch eine andere kennung hat. ich frage nur nach,w eil ich es für sinnvoll halte die abkürzung nachgestellt zuhaben, falls mannicht weiss wofür der lange name steht. bei vhs ist das noch irgendwie erratbar, aber bei desoxiriobnukleinsäure weiss einnormaler nutzer nicht sofort, dass ses sich um dns handelt und dns hat seit den ganzen krimi und gerichtsshows wirklich jeder schon gehört und kann das zuordnen. also wer findet das ausser mir noch sinnvoll zu haben und lässt sich das einbauen? Benutzer:Andreas -horn- Hornig 16:47, 17. Feb 2005 (CET)
- Wäre ganz praktisch zur besseren Übersicht; ich habe das mal mit [[Kategorie:Genetik|Desoxyribonukleinsäure (DNS)]] probiert, funktioniert aber so nicht. -- FWHS 14:54, 20. Sep 2005 (CEST)
[Bearbeiten] Meistgewünschte Artikel
Ich fände sie sollten nicht nur nach den meistverlinkten Artikel geordnet werden --- wie wäre es mit einer List, wo die meist gesuchten (aber nicht gefundenen) Artikel gezeigt werden. (ist vielleicht eh von Admins machbar - ich weiß es nicht) --Telcontar 02:22, 21. Feb 2005 (CET)
- Da der Server durch das Protokoll der Leseoperationen überlastet wurde, gibt es derzeit kein Protokoll das hierfür verwendet werden könnte. Solange die Wikipedia im aktuellen Maß wächst, wird das nichts. Die Idee ist gut. -- mijobe 20:14, 7. Mai 2005 (CEST)
[Bearbeiten] Besucher Reviews
Ich kam gerade auf die Idee, dass viele Leute die Wikipedia nur "besuchen" und leider nicht teilhaben und mitschreiben wollen. Diese Menschen könnten doch auch eine Art Review über den Artikel geben (geholfen, gefallen, nicht geholfen, nicht gefunden? ...). Ich gebe zu dass auch hier ein großes Missbrauchspotenzial aufgemacht werden würde, aber ein Feedback von den "Kunden" fände ich nicht schlecht. --Telcontar 02:22, 21. Feb 2005 (CET)
- Geholfen und gefallen wären zwar nett, sind aber nicht weiter hilfreich. Was wirklich helfen würde wäre korrekt oder fehlerhaft. Ein fehlerhaft ohne Angabe der Fehler bringt uns aber auch nicht weiter. Siehe Benutzer:Mijobe/Geprüfte_Versionen -- mijobe 20:19, 7. Mai 2005 (CEST)
-
-
- Dann lieber einen Verweis auf existierende Diskussionsseiten, wo man Derartiges hinterlassen kann. --Flominator 17:39, 11. Jul 2005 (CEST)
-
- Einem Fisch das Tauchen beibringen? Wer sich beteiligen will kann das bei Wikipedia ganz leicht: editieren oder Diskussionsseite. Wer sich nicht beteiligen will, kann auch nicht helfen. Ein Klick hilft nicht wirklich. -- Diwas 15:50, 24. Mär. 2007 (CET)
[Bearbeiten] Seitensperrungen/-entsperrungen in der Versionshistorie
Es waere nett, wenn Seitensperrungen und -entsperrungen in der Versionshistorie mit Datum, Benutzernamen des (ent-)sperrenden Admins und kurzer Begruendung angegeben waeren. Damit wuerden sie aehnlich wie regulaere Benutzerbeitraege behandelt werden und solche Sperrungen sind dann immer nachvollziehbar. – Sebari ☢ 19:18, 23. Feb 2005 (CET)
- Ich wär für eine dicke (z.B. Gelbe) Meldung am Anfang der Entsprechenden Seite, in der Steht wer wann warum gesperrt hat. Könnte man ja einfach aus dem Sperr-Logbuch automatisieren. --qwqch 13:47, 14. Jun 2005 (CEST)
-
-
- die Dicke meldung am anfang ist denke ich (auf der artikelseite) überflüssig (und für nicht-wikipedianer die infos suchen unangenehm) da man sooderso merkt, dass man nur den quellcode ansehen kann. Falls das nicht eh so gemeint war wäre ich für diesen erwähnte Meldung, der dann zum vorschein kommt, wenn man den quellcode ansieht. -- Jakov
-
-
- Ja Natürlich eine Dicke gelbe Meldung, dass man unsere Hauptseite nicht editieren darf ;) --Träumer 10:12, 31. Aug 2005 (CEST)
- Dafür: Habakuk <>< (Versionslöschungen sollten auch in der Historie aufgeführt werden), Benutzer:Rdb?, mijobe, qwqch, joni Δ, Jakov, G, FWHS, the one who was addicted (#), optional in den Optionen einstellbar M@rkus, Libro
- Dagegen:
[Bearbeiten] Eigene Artikel löschen
Ich finde es sinnvoll, wenn man eigene Artikel (sprich: Artikel mit Benutzer:xyz/... und Artikel, in deren Historie ausschließlich man selbst vorkommt) wieder löschen könnte. Das sollte eigentlich software-technisch kein Problem darstellen:
if( !mySQL-ergebnis("SELECT User FROM History WHERE User ungleich angemeldeter User") ) zeige Button: "Löschen" an.
- Mit verschieben nach Benutzer:xyz/Artikel kann ich dann alles löschen -- mijobe 20:22, 7. Mai 2005 (CEST)
-
- Wenn ich dann bockig werde und es mir nicht gefällt, was mit meinen Artikeln geschieht, lösche ich sie einfach ... tolle Idee ;) --Flominator 17:41, 11. Jul 2005 (CEST)
-
-
- Da steht doch ausdrücklich in deren Historie ausschließlich man selbst vorkommt... Stefan 01:33, 20. Jul 2005 (CEST)
-
- Mit angemessener Begründung ist das per SLA problemlos möglich; ohne Begründung gehört das in das Umfeld der Frage, ob die GFDL kündbar ist, die hier ein wenig erörtert wurde.--Gunther 19:12, 19. Dez 2005 (CET)
- Das beste wäre wenn man da eine Protection einbauen würde, die auf verschiebungen prüft und sperrt, wenn das ding in einem anderen namensraum als BENUTZER stationiert war...Dark Lord Klever BattleGemeinsam gegen Vandalismus! 13:05, 4. Jan 2006 (CET)
- Dafür: Manuel, joni Δ, FWHS,Dark Lord Klever Battle, ISBN
- Dagegen: mijobe, Flominator, Atamari … Träumer, :Bdk:, Libro, Hannes2 Diskussion
[Bearbeiten] 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[4]. 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. [5] 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)
[Bearbeiten] 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
- Aufzählungen
- 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)
[Bearbeiten] Sprachen auf der Navi-leiste (Interlanguage links)
Bitte für bug 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)
- dafür: Darrn, ElRakı, MilesTeg, joni Δ, Flominator, ma(c|d)dog, Trickstar, FWHS, M.A. (Marc-André Aßbrock), Στέφανος (Stefan) ■, Wikipeditor, thorsten, ulim, Libro, Perconte, Löschfix
- dagegen: Wichtiger ist mir das die Leiste erhalten bleibt.++Scooterman 19:26, 1. Mär 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)
- 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)
-
[Bearbeiten] Zeile xyz
Bei langen Seiten ist es oft schwierig den letzten Eintrag zu finden obschon die Zeile dabei steht. z.B. Zeile 776. Könnte man an die Bearbeiten- Buttons rechts eine Zeilenzahl mit einflechten?--82.82.235.136 14:15, 10. Jun 2005 (CEST)
Im KLassic-Skin mit 'Einstellungen'->Verschiedenes->Inhaltsverzeichnis nummerieren..
werden die Überschriften nummeriert - das ist eine Vereinfachung-trotzdem wäre es schön wenn die Zeilenanzahl angezeigt würde.--Kino 12:56, 13. Jan 2006 (CET)
dafür: Guter Vorschlag.--G 14:53, 10. Jun 2005 (CEST)
- Finde ich auch: guter Vorschlag --Pelz 18:24, 10. Jun 2005 (CEST)
-
- Die Zeilenzahl ist doch bei jeder Browsergröße unterschiedlich. Man könnte höchstens die nächstliegende Überschriften mit einblenden. -- sk 21:06, 10. Jun 2005 (CEST)
-
-
- Es geht ja mehr um die Zeilenumbrüche, die absolut im Quelltext vorhanden sind, als um die, die der Browser anzeigt. Von daher könnte das schon sinnvoll sein, um sich zu orientieren, aber wie genau das funktionieren soll, kann ich mir nicht so recht vorstellen. --BLueFiSH ?! 21:23, 10. Jun 2005 (CEST)
-
-
-
-
- Wenn man sich den Versionsunterschied anzeigen lässt werden auch die Zeilenzahlen angezeigt, es müsste also, wenn auch mit Aufwand, möglich sein.--G 22:02, 10. Jun 2005 (CEST)
-
-
(von Verbesserungsvorschläge hierher kopiert 82.82...)
- dafür, das ließe sich vll auch mit Kapitelnummern und -Überschriften verbinden. -FWHS 12:52, 1. Aug 2005 (CEST)
- dafür, hab's mir nicht genau durchgelesen, klingt aber interessant. Wikipeditor
Ich nehm das Theme mal wieder auf: Ich bin auch dafür die Zeilennummer mit anzuzeigen. Bei Versionsunterschieden steht ja auch die Zeilennummer dabei, ist aber bei einer größeren Zeilennummer aber bisher kaum nachzuvollziehen. Ich hatte diese auch schon mal angeregt, ist aber nicht viel nach gekommen. Vielleicht klappt es ja diesmal. -- Petflo2000 17:29, 7. Feb 2006 (CET)
Zeilennummern aber bitte nur beim Versionsvergleich und nicht bei normalen Edits, sonst sieht das aus aus als müßte man hier programmieren statt schreiben. Und das schreckt ab. Kolossos 21:04, 7. Feb 2006 (CET)
- so wars gedacht, die Zeilen die in der Versionsgeschichte angezeigt werden,z.B. Zeile-1244, möchte ich beim scrollen wiederfinden können; das kommt oft vor bei den LAs, Diskussionen, hier und sonst wo --Kino 23:41, 7. Feb 2006 (CET)
-
- Andererseits könnt man ganz oben bei den Unterschieden auch die nächsthöhere Überschrift neben der Zeilennummer auflisten, dass klingt dann nicht so mathematisch. Kolossos 21:42, 20. Feb 2006 (CET)
-
-
- Alternativ-Vorschlag: Die vorhandene Zeilenangabe im Versionsvergleich wird als Link ausgestaltet, der genau an die entsprechende Stelle im darunter angezeigten Text springt. --Ce 00:14, 11. Mär 2006 (CET)
-
-
-
-
- @Ce, das wäre optimal,--Kino 17:44, 11. Mär 2006 (CET)
- Prozu Ces Vorschlag--Hannes2 Diskussion 14:42, 23. Aug 2006 (CEST)
-
-
-
-
-
- Falls eingestellt ist, nur die Änderungen anzuzeigen, sollte der Link dann den Text anzeigen und an die Stelle springen. --Diwas 04:48, 18. Feb. 2007 (CET)
-
-
[Bearbeiten] 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)
[Bearbeiten] Vorschlag zur Reduzierung des Speicherverbrauchs
teilweise werden artikel vom selben benutzer mehrmals geändert, weil dieser die vorschau nicht benutzt. da wär es doch sinnvoll wenn die software diese ganzen änderungen (vom selben benutzer ) zu einer zusammenfasst, damit nicht jede änderung extra gespeichert werden muss. dazu sollte man vielleicht ein zeitlimit einbauen, d.h. alle änderungen des benutzers innerhalb von 6 stunden werden wieder extra gespeichert. damit werden sukzessive änderungen zusammengefasst, falls der benutzer den artikel aber mehrmals komplett ändert, sind die änderungen trotzdem noch nachvollziehbar. und der vandalismus schutz ist trotzdem noch gegeben, da sich kein benutzer seinen eigenen artikel vernichten wird. alternativ zu dem zeitlimit wäre noch möglich, dass anschliessende "kleine änderungen" des benutzers, zusammengefasst werden. Darrn 18:23, 16. Jun 2005 (CEST)
- das ist, finde ich, ein gradioser einfall, für den ich bin. über das zeitlimit müsste man sich nur noch unterhalten; sechs stunden finde ich ein bisschen zu lang. mfg --joni Δ 20:23, 29. Jun 2005 (CEST)
-
- das finde ich auch klasse. Wäre ein Bild im Artikel hätte ich dir jetzt einen Wikipedia-Nobelpreis dafür verliehen! Aber: eine Stunde reicht m.E. --Flominator 17:48, 11. Jul 2005 (CEST)
- Gute Idee. Aber geringeres Zeitlimit (1h?). Vielleicht könnte man die Bearbeitungsseite auch so gestalten, dass der Speichernbutton überhaupt erst nach der ersten Vorschau aktiv wird? --the one who was addicted (#) 18:22, 11. Aug 2005 (CEST)
- Dann wird man aber mehr den "Seite speichern"-Button benutzen; die Benutzung des "Vorschau-zeigen" Buttons wird zurückgehen. Dadurch wird der Server noch mehr strapaziert. Zweitens: Ein paar Änderungen aus dem Speicher zu nehmen reduziert ihn zwar, aber ein Link auf diese Änderung funktion dann nicht mehr. Ich halte das letzte Argument für eher unwichtig. Um das erste Argument auch zu entkräften habe ich einen Kompromißvorschlag: Statt die Änderungen sofort zusammenzufassen geschieht das erst nach mindestens 24h. Der Wikipediaserver kann das dann auch in einer "ruhigen Stunde" tun und nicht wenn er eh gerade überlastet ist. --Träumer 13:16, 15. Aug 2005 (CEST)
- Mir ist eben ein noch zu bedenkender Punkt ein-/aufgefallen: Was soll mit den Änderungskommentaren passieren, wenn zb. ein Editor Änderungen in fünf Abschnitten eines Artikels jeweils vorbildlich mit Zusammenfassung vornimmt? Denn ein einfaches Zusammenhängen der Kommentare wird aufgrund der Platzbeschränkung (?) im Feld Zusammenfassung und Quellen: vermutlich nicht (immer) funktionieren. --the one who was addicted (#) 16:55, 16. Aug 2005 (CEST)
- Ich wäre dafür, nur den letzten Änderungskommentar zu speichern und den Schreiber dabei eventuell auf diesen Umstand hinzuweisen. -- Royd 20:44, 26. Aug 2005 (CEST)
- Die beste Möglichkeit wäre vielleicht, dass der Server nur jede x-te Version vollkommen abspeichert (immer die aktuelle) und ansonsten nur die Änderungen speichert. Ich vermute aber, dass eine Umstellung nicht möglich ist, außerdem weiß ich nicht, wo der Flaschenhals ist, wenn das der Prozessor ist wird es noch langsamer.--G 00:08, 29. Sep 2005 (CEST)
-
- Es gibt Sachen, die KANN man einfach nicht per Vorschau testen. Von meiner Seite Benutzer:Plenz/monobook.js gibt es inzwischen ca. 80 Versionen. Ich wünschte, ich könnte 79 davon einfach löschen. --Plenz 08:53, 15. Jan 2006 (CET)
- Pro In der Hoffnung, dass es technisch machbar ist. Wenn es die Software nicht aut. macht dann wenigstens die Möglichkeit dies selber zu tun (innerhalb 1h). Was wäre wenn jemand seinen Edit revertiert? Ich bin mir auch nicht sicher, ob dies zu einer Sichheitslücke führen könnte. -- Ολλίμίνατορέ •Ω• 14:49, 7. Apr 2006 (CEST)
Vorschlag: Mir ist auch immer nicht ganz wohl, bei dem Gedanken wieder mal eine Version mit marginalem Input geschaffen zu haben. Wie wäre es, wenn man Bearbeitungen, bei denen nur hinzugefügt wird einfach statt der alten speichert, und nur bei Löschungen auch die Alte? 141.58.115.197Stefahn (mach ich was falsch mit der Sign?)
Jetzt produziere ich also wieder Speicherverbrauch, nur um mitzuteilen, dass mir schon auf einigen Seiten der Button Veränderungen sind nur kleine Korrekturen positiv aufgefallen ist, hier bei Pedia allerdings leider noch nicht begegnete. S
- Dafür: Darrn, joni Δ, Flominator, Jakov, Stefan, FWHS, mGla, the one who was addicted (#), Royd, Prolineserver, M@rkus, rdb?, Plenz, Ολλίμίνατορέ •Ω•
- Dagegen:, Staro1
Ich bin mit Einschränkung dafür, Abschnittsweise Änderung bitte getrennt lassen.--Löschfix 16:56, 15. Sep 2005 (CEST)
Man könnte die Änderngen von einem einzelnen Benutzern über Javascript zusammenfassen und dann nach Bedarf ausklappeen. Wenns eingeklapt ist steht da 6 Bearbeitungen beispielsweise. -- M@rkus 00:06, 14. Jan 2006 (CET)
- Das hat wohl eher keinen technischen Nutzen, und wäre vieleicht per JS-Unterseite zu realisieren. -- Ολλίμίνατορέ •Ω• 15:38, 7. Apr 2006 (CEST)
Wäre ein Anfang.
- Wie wäre es, da die Beschriftung in Zusammfassung ja offenbar ein Problem darstellt, wenn nur solche Edits zusammengefasst werden, die man als solche kennzeichnet, also der User hat es selbst in der Hand. Z.B. ein mit "typo" gekennzeichneter edit kann ohne weiteres dem vorhergehenden Edit hinzugefügt werden, ohne ein extra Zusammenfassung zu benötigen. Natürlich könnte man dazu einen knopf/shortcut oder ein Codewort erfinden.--Löschfix 02:27, 24. Aug 2006 (CEST)
-
- Das halte ich für einen guten Vorschlag, denn oft will man grad nur einen Tippfehler ausbessern und aus - und dann ergeben sich doch noch einige tippos. Oder auch Tippos bei verschiedenen Absätzen, da hilft eine Vorschau gar nichts. Das würde nicht nur Speicherplatz sparen, sondern allein die Versionsübersichten wesentlich übersichtlicher machen. Die Zeitspanne 1 Stunde wäre meiner Meinung voll ausreichend, wenn nicht auch noch zu lang. --K@rl 22:46, 22. Jan. 2007 (CET)
- Serverentlastung-Vorschau-Clientseitig
Verbundenes Problem. Der Server ist wegen Überlastug eine Katastrophe. Ich hab eine sehr schnelle Verbindung und einen mittelschnellen Rechner, dennoch ist es katastrophal wie lange man oft auf den Request warten muß, dann noch der eigene Rechner die Daten verarbeiten muß. Deshalb große bitte an die Entwickler, aber schwer zu machen denke ich: Muß denn für die Vorschaufunktion der Server involviert werden? Kann denn die Vorschau-emulation nicht vollständig offline, d.h. im Browser-Cache erfolgen? Javascript oder ähnliches? Klar, das geht wahrscheinlich nicht allein via html. Dazu müßte man vermutlich ein Programm schreiben. Aber das wäre der Segen. Denn so bringt mir persönlich die Vorschau überhaupt keinen Gewinn, und entllastet auch nicht den Server, sie ist nur zur Reduzierung der Versionsgeschichte da. Und WPro ist ja leider auch nicht in der Lage die Vorschau zu emulieren. Sehr schlecht.--Löschfix 16:56, 15. Sep 2005 (CEST)
- Ich denke, dass es nicht möglich ist, die Vorschau durch einen Client erstellen zu lassen. Dieser Client müsste dafür den gesamten vorliegenden Text des Artikels parsen. Es gibt natürlich etliche einfache Sachen wie die Link-Umwandlung. Aber was ist zum Beispiel mit den ganzen Funktionen zur Darstellung mathematischer Rechnungen? Ich weiß nicht, ob Java-Script das umsetzen könnte (ich bin JS-Laie...), aber selbst wenn Java-Script das könnte, müssten die ganzen Anweisungen, wie das gemacht werden müsste, an den Client übertragen werden. Damit würden wir zwar jede Vorschau sparen (und bei kurzen Abschnitten hat der Server da wirklich so gut wie nichts zu tun), allerdings müsste beim Aufruf der Bearbeitungsseite der ganze Code übertragen werden, der nötig ist, um den Wiki-Code in XHTML umzuwandeln. Und ich denke, dass die Server damit nicht gerade unterfordert wären. (Die Modem- und ISDN-Nutzer würden sich wahrscheinlich auch bei dir bedanken.) Ohhja, jetzt habt ihr beim Lesen wahrscheinlich den Aspekt, ob Java-Script das alles kann, schon wieder vergessen ;-) Schreib eben zu viel... --MaKoLine 00:29, 8. Jan 2006 (CET)
-
- Außerdem kann die korrekte Darstellung von Bausteinen sowie von Links auf vorhandene und nicht vorhandene Artikel nicht lokal bewerkstelligt werden. --Plenz 08:53, 15. Jan 2006 (CET)
-
-
- Pro Ich würde sagen; das ist ein völlig eigenständiges Problem/ Vorschlag. Ich würde auch sagen das es technisch machbar ist. -- Ολλίμίνατορέ •Ω• 15:38, 7. Apr 2006 (CEST)
-
-
-
-
- ACK - Eigenes Problem. Dass die Lösung nicht trivial ist und möglicherweise mit JS nicht zu bewerkstelligen, ahnte ich ja schon vorher. Nur, clientseitige Emulation, evtl. eingeschrängt sollte eine Überlegung wert sein. Vielleicht gibt es ja einen Weg.--Löschfix 02:27, 24. Aug 2006 (CEST)
-
-
- Nächstes Problem der Serverentlastung
Bei Großen Diskussionsseiten. Klickt man auf das Inhaltsverzeichnis, dann springt die Seite nicht etwa zu der Stelle im Text via javascript oder html, sondern die Seite wird neu geladen und dann gesprungen. Was die Sache manchmal ewig verlängert und den Server belastet. Hängt das mit Cacheon chachoff zusammen oder ist das ein Programmierfehler? Das Zurückspringen von der bearbeitungsseite direkt an die Textstelle geht auch häufig schief, wenn die Seite groß ist.--Löschfix 19:11, 15. Sep 2005 (CEST)
- Das sollte eigentlich nicht auftreten. Du meinst doch, dass dein Browser beim Springen innerhalb einer Seite, die er bereits vollständig aufgebaut hat, diese vollkommen neu lädt? Die Verweise in den Inhaltsverzeichnissen werden durch sogenannte Anker erzeugt. Damit kann man innerhalb eines Dokumentes navigieren. Ich hab das Verhalten gerade an dieser Seite (die ja nicht gerade klein ist) mit dem Opera, Firefox und Internet Explorer getestet und keine Probleme feststellen können. Bei mir wurde immer innerhalb des bereits geladenen Dokumentes (das bei FF und IE zumindestens nicht im Cache lag) ohne sichtbare Server-Anfrage navigiert. Weitere Informationen zu den Ankern findest du hier in SELFHTML. --MaKoLine 00:29, 8. Jan 2006 (CET)
- Ich glaube das war einen Schwäche in meinem monobook.js oder css, dieser Effekt tritt nach neuer Version nicht mehr auf.--Löschfix 02:27, 24. Aug 2006 (CEST)
[Bearbeiten] 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)
[Bearbeiten] löschen von sektionen
von Wikipedia:Verbesserungsvorschläge hierher kopiert. --joni Δ 11:13, 28. Jun 2005 (CEST)
das löschen von sektionen ist recht einfach durch bearbeiten selbiger und löschen ihres inhalts. jedoch erzeugt dies einen nicht so ästhetischen unnötigen zeilenumbruch an ihrer stelle. es sollte somit automatisch erkannt werden, ob der ganze inhalt gelöscht wurde und der gesamtquelltext entsprechend angepasst werden – ohne leerzeile. mfg --joni Δ 18:41, 30. Mai 2005 (CEST)
[Bearbeiten] sektion hinzufügen nicht nur für die ganze seite
beim bearbeiten von diskussionsseiten kann man ja oben bei "seite bearbeiten" auch bei klick auf das pluszeichen eine sektion hinzufügen. wenn man jedoch keine überschrift zweiter ordnung erstellen, sondern eine noch geringerer ordnung, sollte man dort, wo man auch auf [Bearbeiten] klicken kann, die möglichkeit haben, eine sektion hinzuzufügen. so könnte es aussehen: [Bearbeiten] [+]
außerdem wäre es meines erachtens ebenfalls sehr hilfreich, wenn diese möglichkeit dann auch nicht nur für diskussionsseiten bestünde, sondern auch für normale artikel und so.
mfg --joni Δ 11:39, 28. Jun 2005 (CEST)
- Ich möchte deine Idee aufgreifen und erweitern: [Bearbeiten] [+] [?] ... Beim ARtikel selbst könnte noch zb ein Fragezeichen angefügt werden, sodass man in der Diskussion einen neuen Absatz mit dem Namen des Absatzes im Artikel bearbeitet oder erstellt.
- Außerdem ist das anfügen sehr hilfreich, um nicht den quelltext des vorhergehenden bearbeiten zu müssen.
- -- Jakov 16:44, 17. Jul 2005 (CEST)
- Vielleicht sollte das "kleinmenü" auch um [-] erweitert werden (siehe "löschen von sektionen").
- Dann aber unbedingt mit Sicherheitsnachfrage, denn dass man versehentlich ein Stückchen zu weit rechts klickt, kann leicht einmal passieren.
- Ist es eigentlich auch möglich, per HTML Einträge ans Kontext-Menü anzufügen? Das wäre m.E. hier die ideale Lösung. --Ce 10:49, 29. Sep 2005 (CEST)
- Kontextmenü ist Sache des Browsers, oder des Betriebssystems.
- Vielleicht sollte das "kleinmenü" auch um [-] erweitert werden (siehe "löschen von sektionen").
In Diskussionsseiten sollte so ein Minimenü in jeder Zeile die eine Signatur enthält stehen. Bei Klick auf + wird ein Bearbeitungsfenster geöffnet und beim Speichern entsprechende Doppelpunkte (TAB) und die Signatur eingefügt. (Oder gleich was richtiges) --Diwas 06:39, 25. Feb. 2007 (CET)
- dafür: Diwas
- dagegen:
[Bearbeiten] 100%-angaben
es gibt da noch irgendein problem mit irgendeinem feld im generierten html-code, das geändert werden müsste. denn
<div style="width:100%; background-color:#F09090">'''demonstration'''</div>
bewirkt nicht das erwartete, richtige ergebnis, sodass dummerweise schon häufiger zu angaben wie "95%" oder so gegriffen werden musste. folgendes entsteht dabei:
zumindest bei mir (browser: internet explorer, auflösung: 1152x864) entsteht dabei eine horizontale scrollbar.
mfg --joni Δ 11:39, 28. Jun 2005 (CEST)
Dies ist ein Problem des Internet Explorer. Man kann das nicht so ohne weiteres ändern (entweder es würde in anderen Browsern falsch sein oder man müsste viel drum rum bauen). Der Internet Explorer 7 stellt es in der ersten Beta-Version schon korrekt dar, also einfach auf den IE7 warten. MfG --APPER\☺☹ 23:38, 29. Jul 2005 (CEST)
Ich habe weder mit Firefox noch mit IE6 Probleme damit. - FWHS 13:12, 1. Aug 2005 (CEST)
- ich auch nicht (IE 6)--Löschfix 17:17, 15. Sep 2005 (CEST)
[Bearbeiten] Bilder zurechtschneiden
Wenn man Bilder beliebig verkleinern kann, dann wäre es doch auch vorstellbar Bilder skriptgesteuert zuschneiden zu können um Ausschnitte zu erstellen. Das Ganze sollte für folgendes dienen:
in den Commons gibt es jetzt 10.000 Gemälde alter Meister und der klassischen Moderne. Diese sind hochauflösend und es würden sich detailierte Bildbesprechungen dafür anbieten (ähnlich der 1000 Meisterwerke im Fernsehen). Dafür könnte man nun wieder eine Menge von Bildausschnitten gebrauchen um im Text darauf einzugehen. Schön wäre es wenn man dafür nicht jeden Ausschnitt einzeln wieder hochladen müßte sondern das über die Eckkoordinaten steuern könnte. Wenn man das Bild downloaded, kann man z.B. mit Irfanview einen Bereich markieren und bekommt die Koordinaten ganz oben einfach angezeigt. Ist sowas möglich? Es gibt bestimmt auch noch andere Anwendungsfelder(Karten). Somit könnte man dann auch ein gutes Bild zum Thema Kirchturm auch für den untergeordneten Artikel Turmuhr benutzen und somit auch Speicherplatz sparen. Formatierungsvorschlag
[[Bild:Pilzkorb.jpg|top=150|le=200|he=100|wi=300|thumb|none|100px|Ein Korb voller Speisepilze]]
Kolossos 12:36, 24. Jun 2005 (CEST)
- Das wäre zweifellos eine feine Sache. Bei der Gelegenheit würde ich mir ja noch wünschen, Thumbs von älteren Bildversionen erzeugen zu können. Ist zwar für den Artikelraum unwichtig, bei der Bilderwerkstatt oden den exzellenten Bildern wäre es aber sehr nützlich. Rainer ... 12:42, 24. Jun 2005 (CEST)
- @Kolossos: Klingt interessant, sieht aber nicht nach Ausschnitt aus. Rainer ... 14:31, 24. Jun 2005 (CEST)
-
- Wieso? Ich hatte mir das so gedacht: top(Top) gibt den Abstand des Ausschnittes von oben an, le (left) den Abstand von links (left als Parameter ist leider schon vergeben), he (height) die Höhe und wi die Breite. Alles in Pixel der Originalgröße. Am Ende wird das Ergebnis ggf. auf 100px geschrumpft. In PHP sollte das eigentlich einfach umzusetzen sein. Kolossos 16:37, 24. Jun 2005 (CEST)
-
-
- Die Idee gefällt mir auch. Bin auch dafür. Parameter nach Machbarkeit. --Raymond 08:11, 30. Jun 2005 (CEST)
-
-
-
-
- dafür --Flominator 17:51, 11. Jul 2005 (CEST)
-
-
-
-
-
-
- Ich bin auch dafuer: Eine sinnvolle anwendung sind z.B. auch Gruppenbilder, bei denen man nur eine Person im Artikel haben moechte. --Prolineserver 09:58, 25. Sep 2005 (CEST)
-
-
-
Auch dafür. weitere Überlegungen: ich denke man könnte das Schema vom padding bei CSS verwenden. Das wäre dann „left“, „top“, „right“ und „bottom“, allerdings ohne abkürzungen. Ich zitiere den eben angegebenen link:
Angeben kannst du ein bis vier Werte, die wie folgt berechnet werden:
- Ein Wert: Abstand oben, unten, links und rechts
- Zwei Werte: Der erste Wert für den Abstand oben und unten, der Zweite links und rechts
- Drei Werte: Der erste Wert für den Abstand oben, der Zweite links und rechts und der Dritte unten
- Vier Werte: Der erste Wert für den Abstand oben, der Zweite rechts, der Dritte unten und der Vierte links
Könnte dann so aussehen: [[Bild:Pilzkorb.jpg|crop=120 25%|thumb|none|100px|Ein Korb voller Speisepilze]]
statt [[Bild:Pilzkorb.jpg|top=120|le=25%|re=25%|bo=120|thumb|none|100px|Ein Korb voller Speisepilze]]
Jedenfalls wäre ich für ein beschneiden von oben, unten, rechts und links und nicht ausschneiden an einer Position mit gewisser größe, sofern einem nicht die Wahl bleibt. -- Jakov 19:40, 18. Jul 2005 (CEST)
- Dafür: Kolossos, Joni2, Raymond, Flominator, Jakov, FWHS, the one who was addicted (#), Prolineserver, Ce
- Dagegen:
[Bearbeiten] :----
von Wikipedia:Verbesserungsvorschläge hierher verschoben. --joni Δ 20:19, 29. Jun 2005 (CEST)
:----
sollte möglich sein, in diskussionen z.b., wenn man seinen beitrag einrückt und dann eine horizontale linie ziehen will. momentan erfolgt in so einem fall nur der text „----“ eingerückt. danke --joni Δ 10:15, 19. Mär 2005 (CET)
- Geht nicht, HTML-Standard. "----" wird geparst zu "<hr>" und ist damit nicht veränderbar. -- da didi | Diskussion 23:18, 19. Mär 2005 (CET)
-
- oh doch, es geht. probier mal folgenden code aus:
<html> <head> <title>Test</title> </head> <body> <hr /> <dd><hr /></dd> </body> </html>
-
-
- noch was dazu: bei rechten boxen (wie sie z. b. bei städten und so verwendet werden) sieht es so aus, dass eine eigene mit „----“ erzeugte trennlinie etwas davor aufhört, eine überschriftenerzeugte jedoch nicht. wenigstens wird der bearbeiten-link verschoben, doch wäre es natürlich sehr schön, wenn auch die trennlinie angepasst werden würde. --joni Δ 16:14, 25. Mär 2005 (CET)
-
[Bearbeiten]
am ende von url nicht mitverlinken
bei den weblinks steht hinter den links oft ein gedankenstrich und dann eine kurze erklärung, was dort zu finden ist. nun gibt es aber die regelung, dass vor gedankenstrichen kein zeilenumbruch erfolgen darf, weshalb man immer, wenn man den gedankenstrich verwendet, –
schreiben sollte. wenn man das jedoch bei solch einer weblinks-liste tut, werden die urls verfälscht. also sollte ein
am ende einer url erkannt und nicht mitverlinkt werden. mfg --joni Δ 21:58, 29. Jun 2005 (CEST)
- Ich finde, dass der quellcode für weblinks jedenfalls um das „|“ erweitert werden sollte. Leider weiß ich nicht ob das machbar ist. Wenn nicht unterstütze ich diese forderung. Jakov
- Das fände ich auch besser, als Ausnahmen in der Verlinkung, denn könnte ja auch mal als Parameter übergeben werden: test.cgi?var=42 xyz=21 oder ähnlich, soweit ich weiß, kann ; verwendet werden.) FWHS 23:17, 21. Aug 2005 (CEST)
- Nein, das ist eigentlich nicht zulässig, da das &-Zeichen in HTML (bzw. in SGML/XML) für Entities reserviert ist. Um es trotzdem in URLs verwenden zu können müßte es eigentlich entweder mit %26 oder & encoded werden. Da es aber auch als Trennzeichen für Parameter von GET-Forms verwendet wird, versuchen alle Browser damit "intelligent" umzugehen, indem sie nur korrekte und bekannte Entities ersetzen und alles andere in Ruhe lassen. Ein &npsp; in der URL eines <a> Tags würde also sowieso vom Browser in ein Leerzeichen verwandelt werden. Daher fände ich es eigentlich logisch es auf der Serverseite ebenso zu behandeln. --X4u 21:08, 5. Sep 2005 (CEST)
- Das fände ich auch besser, als Ausnahmen in der Verlinkung, denn könnte ja auch mal als Parameter übergeben werden: test.cgi?var=42 xyz=21 oder ähnlich, soweit ich weiß, kann ; verwendet werden.) FWHS 23:17, 21. Aug 2005 (CEST)
[Bearbeiten] Unterschiede besser markieren
Es gibt ja drei Arten von Unterschieden: hinzugefügte Zeilen, gelöschte Zeilen und geänderte Zeilen. Bei letzteren werden die konkreten Unterschiede momentan mit <
span>-Konstrukten rot eingefärbt. Wenn nun jemand beispielsweise einen Textbrowser verwendet oder derartige Formatierungen unterdrücken läßt, sieht er einfach nur, daß die Zeile geändert wurde, aber nicht, was geändert wurde. Es wäre m.E. besser, wenn man das beispielsweise mit <em>
oder ähnlichen "logischen" Tags machen würde, die werden nämlich auf jeden Fall hervorgehoben.
[Bearbeiten] automatische mitverlinkung anliegender interpunktionszeichen
gemäß http://www.duden.de/service/download/textverarbeitung_duden1.pdf (seite 98, rubrik „Schriftauszeichnung“) werden – grob gesagt – anliegende interpunktionszeichen mit ausgezeichnet. (zum begriff „auszeichnung“ siehe Textauszeichnung.) so muss man beispielsweise schreiben:
- Wort 1, Wort 2, Wort 3
- „Ein Zitat.“
- Text mit Farbe!
- das große, schöne Wort
somit sollte genau dasselbe auch mit der auszeichnung geschehen, die man verlinkungen verleiht. ein beispiel gibt in diesem punkt schon einmal http://www.duden.de/. wenn man dort auf „Duden-Suche“ geht und nach einem ausdruck sucht und zum beispiel ein komma dahinter steht, ist dieses komma nicht nur mit fett ausgezeichnet, sondern auch mit verlinkt, sodass es auch mit rot wird, wenn man er mit der maus überfährt. auch mediawiki tut dies schon teilweise. unter „Benutzerbeiträge“ wird der text „(Unterschied)“ zur gänze verlinkt, was auch so gehört; denn wenn der gesamte klammerinhalt ausgezeichnet ist, nur dann werden auch die klammern mit ausgezeichnet.
es sollte also von der mediawiki-software her automatisiert werden, dass diese regel eingehalten wird, sodass verlinkungen wie die folgenden entstehen:
- Neskaupstaður: „Unweit der isländischen Ringstraße (Hringvegur) ist Neskaupstaður über die durch enge Windungen, steile Anstiege und Gefälle von bis zu 13 % gekennzeichnete Nebenstraße 92 zu erreichen.“
- Smangaliso Mkhatshwa: „1996 wurde er zum Bildungsminister von Südafrika ernannt; diesen Posten behielt er bis 1999.“
- Salto (Sprung): „Der Salto wird im Kunstturnen, Trampolinturnen und Wasserspringen in verschiedenen Formen und Variationen (z. B. Salto mit mehreren Schrauben beim Turnen oder mehrfache Salti beim Wasserspringen) vorgeführt.“
auch, wenn man es zu anfang komisch finden mag, so ist es doch die regel!
mfg --joni Δ 17:23, 30. Jun 2005 (CEST)
- Auch wenn wenn ich immer für die Einhaltung typografischer Regeln bin, so muss ich hier trotzdem widersprechen. Nicht alle Regeln aus dem Druck lassen sich so einfach auf Webseiten anwenden. Aus Sicht von barrierefreien Webseiten ist dies nämlich ziemlich schädlich, da der Linktext unnötig verfälscht wird. Lässt sich dann bspw. ein Blinder mit einem Voicebrowser die Links zum Navigieren vorlesen, würde der Browser evtl. „Kunstturnen-Komma“ vorlesen und das kann nicht der Sinn der Sache sein. Deshalb rate ich davon ab. -- net 19:23, 30. Jun 2005 (CEST)
-
- okay, das ist ein gutes gegenargument. aber sind diese browser denn tatsächlich so konzipiert, dass sie es falsch vorlesen würden? sie sind doch sicher so gestrikt, dass sie auch so einige fehler erkennen und das vorlesen, was gemeint ist; so wie weitgehend auch fehlerhafter html-code dargestellt wird.
-
-
- Das war nur ein Beispiel, was passieren könnte. Ob manche Voicebrowser das wirklich so vorlesen würden, kann ich dir nicht sagen. Der springende Punkt ist aber, dass das Interpunktionszeichen nicht mit zum Link gehört. Der HTML-Quellcode <a href="…">Kunstturnen,</a> wäre also semantisch falsch, da sich der Link nur auf Kunstturnen bezieht. An dieser Stelle kann man also die typografischen Regeln aus dem Druckbreich nicht so ohne weiteres anwenden, da die korrekte Auszeichnung des Quellcodes IMO wichtiger ist. Außerdem weiß man ja gar nicht, wie der Link letztendlich beim Nutzer dargestellt wird. Blau und unterstrichen ist ja nur ein Vorschlag über das Stylesheet. Nun könnte Jemand auch ein Userstylesheet haben, in welchem sich die Links nicht vom Text unterscheiden und nur durch eine kleine Grafik markiert werden. Wird zwar eher selten vorkommen, ist aber auch nicht auszuschließen. -- net 22:47, 30. Jun 2005 (CEST)
-
-
-
-
- Wir sollten weitere Argumente abwarten, ich bin auch immer für die Einhaltung von Regeln, aber ich halte das Gegenargument für sehr wichtig. Feinschreiber ?+! 1. Jul 2005 07:15 (CEST)
-
-
-
-
- Ich finde das aussehen dieser Schreibweisen SChlicht ekelhaft und kann mir nicht vorstellen, wie jemand auf die idee kommt, wie oben dargestellt, „Ein Zitat.“ mit zwei verschieden formtierten anführungszeichen anzubringen. Auch hat IMO die Formatierung meist nichts mit den Satzzeichen zu tun: Wenn ich die "Farbe!"(also Farbe einer Firma die als Markenname ein Rufzeichen angefügt hat) meine, dann ok, aber inn einem Sinnvollen Satz will ich NUR "Farbe" und nicht etwa das Rufzeichen hervorheben.
- Die AUtomatisierung dazu wäre wahrscheinlich kontraproduktiv. Wenn ich mehrere Begriffe in einer Aufzählung trennen will möchte ich, dass sie sichtbar getrennt sind (Wort, Haus, Tür) und nicht (Wort, Haus, Tür,). Es ist mir außerdem noch NIE so untergekommen; weder im Netz noch offline. Diese Norm hat für mich also noch keinen ersichtlichen, logischen SINN.
- Ich unterstütze die Argumente von net. -- Jakov 03:49, 11. Jul 2005 (CEST)
-
-
-
-
- „Diese Norm hat für mich also noch keinen ersichtlichen, logischen SINN“ (Jakov). das ist das typische – bitte nicht übel nehmen! – gefühlsgedusel von nichttypographen. so wird alles ziemlich uneinheitlich. der eine sieht es so, der andere so. nicht umsonst haben sich menschen daran gemacht und jene regeln entworfen. sie dienen – speziell für fließtext – der schnelleren lesbarkeit – und zwar nicht für leute, die ihr gemüt darüber erhitzen, wenn so etwas auftaucht, und die somit langsamer sind, sondern für leute, die dem gegenüber ausgeglichen eingestellt sind. (falls das jetzt meckerig gewirkt hat, dann sei mir bitte nicht böse.)
- „[…] inn einem Sinnvollen Satz will ich NUR "Farbe" und nicht etwa das Rufzeichen hervorheben“ (Jakov). auf Wikipedia:WikiProjekt Kinderseite habe ich die auszeichnung von „Schüler!“ zu „Schüler!“ korrigiert – gemäß regeln! –, und darauf hat mich sogar jemand angeschrieben und mir mitgeteilt, wie positiv er diese änderung finde.
- „Wenn ich mehrere Begriffe in einer Aufzählung trennen will möchte ich, dass sie sichtbar getrennt sind […]“ (Jakov). bei einem komma an einem link kommt es sowieso nur bei gaaaaaaaaanz genauem hinschauen zum tragen, das es nicht auch blau ist. da muss man sich wohl die mühe machen – wie ich mich jetzt schon dazu gezwungen sehe – und einmal mit der maus den link überfahren, oder auch klicken, wegziehen und loslassen, sodass der link fokussiert ist.
- in http://www.duden.de/produkte/dudenreihe/duden04/pdf/duden04_fachausdruecke.pdf ist übrigens eine wunderschöne umsetzung der regeln zu betrachten. beispiel: „Adverbphrase: Phrase mit einem Adverb als Kern; Adverbgruppe (Anna steht vorn; die junge Frau ganz vorn)“.
- „HTML-Quellcode <a href="…">Kunstturnen,</a> wäre also semantisch falsch, da sich der Link nur auf Kunstturnen bezieht“ (net). das ist so meines erachtens nicht wahr. das, worauf es sich semantisch bezieht, ist das im „href“-attribut. das vom „a“-tag eingefasste ist nur das, was indizieren soll, dass man bei betätigung des textes woanders hin verwiesen wird; und dies erfolgt durch textauszeichnung, wo wir wieder beim typographischen wären.
- mfg --joni Δ 15:09, 11. Jul 2005 (CEST)
- Du hast wohl recht, ich bin kein typograph - das heißt aber nicht, dass ich nicht an typographischen normen interessiert bin. Ich spreche hier nicht gegen diese norm, weil ich finde, dass solche normen keinen sinn haben, sondern weil mir speziell diese norm nicht ganz klar wirkt: Zwei Klammern "(",")" begrenzen einen Satzteil doch in gleicher Weise wie zwei Anführungszeichen („,“), oder? Für mich hat es zB hier keinen logischen Grund, weshalb die klammern, wenn der text unterschiedlich mit kursiv bzw gerade, beginnt bzw endet, gerade ausgeführt werden, die anführungszeichen jedoch nicht (zumindest ist es im Regeltext nicht explizit auch für die Anführungszeichen erwähnt (S.99)). Selbiges siehe obiger Beispielsatz („Adverbphrase: ... )“.), die beiden anführungszeichen sind unterschiedlich. ich glaube nicht, dass das den textfluss - und vor allem die logik des satzes bei verschachtelten sätzen - verbessert.
- Ich habe auch kein Problem mit dem angehängten formatieren der Satzzeichen (Adverbphrase:), glaube aber (wie net bereits erwähnt hat), dass das besonders bei (automatischen) verlinkungen zu Problemen führen kann.
- Zu deinem Paradebeispiel "Schüler!" finde ich, dass deine Korrektur durchaus gerechtfertigt ist, wie du sie aber präsentierst ist wiederum verwirrend: keiner weiß -ohne sich davon auf der verlinkten seite zu überzeugen - ob Schüler! gemeint ist oder ob die Anführungszeichen ("Schüler!") auch dazugehören; es ist also nicht NUR das hervorgehoben, was betont werden soll.
- Ebenso finde ich es besonders bei links kritisch etwas auszuzeichnen, was nicht zu linktext gehört. Meines erachtens ist es besonders nachvollziehbar für den user, wenn der linktext mit dem link bzw der gelinkten file ident ist (<a href=link>linktext</a>). In der wikipedia würde dies bedeuten, dass eine verwendung von [[link]] der von zb [[link|hier klicken]] zu bevorzugen ist. Mit [[-]] wird derselbe link erreicht wie mit [[strich]]. Will jemand diesen wikilink so einsetzen, so wird es den endbenutzer verwirren, wenn das satzzeichen danach (zb in einer aufzählung) mit ausgezeichnet wird.
- -- Jakov 14:53, 13. Jul 2005 (CEST) (edit Jakov 13:00, 14. Jul 2005 (CEST))
-
-
[Bearbeiten] endzeilenumbruch weg
wenn man den code einer seite editiert, ist am ende immer ein zeilenumbruch. man entfernt ihn, doch nach der nächsten vorschau oder beim nächsten bearbeiten ist er wieder da. der sollte weg! --joni Δ 15:32, 28. Jul 2005 (CEST)
- Warum sollte er weg? Eine Zeile endet mit einem Zeilenende ("Zeilenumbruch"). Warum sollte das für die letzte Zeile nicht gelten? In der Tat würde es mich eher irritieren, wenn da kein Zeilenende an der letzten Zeile wäre. --Ce 15:15, 12. Mai 2006 (CEST)
[Bearbeiten] automatisches setzen geschützter leerzeichen
von »Wikipedia:Verbesserungsvorschläge/Archiv/2005/Mai« hierher verschoben. --joni Δ 23:09, 29. Jul 2005 (CEST)
ich finde, es wäre sehr nützlich, wenn man folgende zeichen (dasselbe, Akut-Akzent, im doppelpack) als einfasser definieren würde, um automatisch leerzeichen durch geschützte leerzeichen („ “) zu ersetzen: ´´
das wäre aus dem grunde sehr praktisch, dass man dann erkennen würde, wo geschützte leerzeichen benutzt werden, wie z.b. bei der zahlentrennung: „Einwohnerzahl (Weltrang: 2): ´´1 049 700 118´´“
und so, wie „{{…}}“ für vorlagen verwendet wird, da man sowas in artikeln sonst nicht schreiben muss (wenn dannn doch, halt durch „<nowiki>{{<nowiki>“/„</nowiki>}}</nowiki>“), kann man, wie ich finde, auch „´´“ als besagten einfasser benutzen. es sei denn, jemand hat eine brilliantere idee. :) mag natürlich auch sein, dass das zeichen aufgrund von anderen wikipedias, an denen leute mit anderen tastaturlayouts arbeiten, nicht so gut ist.
ich würd's wirklich toll und ungemein praktisch finden, wenn man das realisieren würde.
danke --joni Δ 12:05, 19. Mär 2005 (CET)
-
- Und wenn dann einer ´ mit ' oder mit ` verwechselt, funktioniert es nicht, und er wechselt dann doch lieber wieder zu — Martin Vogel 鸟 19:35, 9. Apr 2005 (CEST)
-
-
- wie bereits erwähnt: es sei denn, jemand hat eine brilliantere idee! also dieses zeichen zu benutzen, ist lediglich ein vorschlag.
- willst du tatsächlich immer schreiben, und so den code schööööön unleserlich machen? in abkürzungen, zahlen über 999 und evtl. noch weiterem wäre das eine grandiose erleichterung.
- und wenn man, um den code leserlich zu halten, wie es ja auch getan wird, einfach immer ein geschütztes leerzeichen direkt eingibt (z. b. per alt+255 oder alt+0160), kann dies nicht beim bearbeiten von code erkannt werden und man weiß nicht, ob man nun ein leerzeichen oder ein geschütztes leerzeichen vor sich hat und muss es vorsichtshalber ersetzen, und das jedes mal wieder in den artikeln, das nervt schon. so eine vereinfachung wäre ungemein praktisch! --joni Δ 01:30, 10. Apr 2005 (CEST)
- übrigens: die verwechselungsgefahr ist, denke ich, gering, da dieses zeichen ja erstens nur im code erscheint, in dem eine schriftart mit einheitlicher zeichenbreite verwendet wird, zweitens es beim häufigen gebrauch – was ja dann der fall wäre – genügend popularität erlangen würde, damit jeder es flüchtig in der syntax erkennt (immer zweimal hintereinander vorhanden, und dieses paar ebenfalls zweimal als einfasser) und drittens die schriftarten eindeutig genug sind, damit man diese drei zeichen auseinanderhalten kann, ich konnte es ja auch in deinem text auf der stelle. --joni Δ 01:37, 10. Apr 2005 (CEST)
-
Nach Jonis Hinweis kopiere ich mal meine Anfrage auf Wikipedia:Ich brauche Hilfe hierher: ::Slomox:: >< 20:22, 19. Apr 2005 (CEST)
Nur mal so als Idee, die mir grad in den Sinn kam: Bei Einheiten zum Beispiel sollen ja benutzt werden, die einen Zeilenumbruch zwischen Zahlenangabe und Einheitenzeichen verhindern. Da das aber lästig einzugeben ist und im Quelltext hässlich aussieht, macht das kaum einer. Könnte man nicht den Unterstrich als Ersatz benutzen, um mit ersetzt zu werden? Wird ja in Links schon ähnlich verwendet. In normalen artikeln dürfte der Unterstrich ja nicht oft auftauchen. --::Slomox:: >< 21:31, 15. Apr 2005 (CEST)
- Man kann auch das geschützte Leerzeichen direkt eingeben, aber einige Browser zerstören das sowieso beim Speichern, also sinnlos. Der Unterstrich wäre eine Idee, aber ob die Entwickler das umsetzen?
- Außerdem wird ja der Unterstrich bei Artikeln nicht entfernt. Vielmehr wird er eingefügt, wenn er fehlt, denn die Links zeigen ja immer zu http://.../Albert_Einstein etc. (also mit Unterstrich). Das ist nicht vergleichbar. MfG --APPER\☺☹ 22:53, 15. Apr 2005 (CEST)
-
-
- Ich hab das nochmal aus dem Archiv nach oben geholt. Ich finde die Idee immer noch gut. Erstmal werden unmaskiert eingegebene geschützte Leerzeichen oft zerstört und sind zudem nicht ohne weiteres zu erkennen. "Fluss X ist 1234_km lang" ist doch im Quelltext im Vergleich zu "Fluss X ist 1234 km lang" viel leichter zu lesen. Zu Stern: Braucht man den Unterstrich denn an irgendwelchen Stellen mal? Ich wüsste spontan keine Stelle, wo man es nicht leicht mit <nowiki>_</nowiki> maskieren könnte. --::Slomox:: >< 17:44, 19. Apr 2005 (CEST)
-
-
-
-
- wie wundervoll, dass auch andere diese idee unterstützen. ich habe dies bezüglich auch eine gute idee gehabt und sie vorgeschlagen. auf Wikipedia:Verbesserungsvorschläge in der sektion automatisches setzen geschützter leerzeichen könnt ich es euch anschauen. leider wurde bisher nicht richtig geantwortet. ich hoffe mit euch zusammen wird das nun was :) mfg --joni Δ 17:58, 19. Apr 2005 (CEST)
-
-
-
-
-
-
- Ich finde Slomox' Idee auch gut. Echte Unterstriche in der Anzeige könnte man einfach durch Eingabe von zwei Unterstrichen erzeugen - schließlich braucht man immer nur einen geschützten Zwischenraum zur Zeit, ein doppelter Unterstrich kann also nicht als sinnvoller Zwischenraum mißverstanden werden. Und es ist dem Laien sicher leichter verständlich als --HoHun 18:00, 19. Apr 2005 (CEST)
-
-
-
-
-
-
-
-
-
- das hast du toll gemacht mit dem farbigen feld, ernsthaft. :) gute idee
- müsste man dann aber nicht alle artikel einmal durchgehen (sql-abfrage?), um zu schauen, wo es nun doch geändert werden muss, wo die entsprechende zeichenkette steht und demaskiert werden muss?
- was haltet ihr denn nun für besser: einen einfasser, innerhalb dessen die leerzeichen ersetzt werden oder eine zeichenkette zur direkten indizierung eines geschützten leerzeichens und ersetzung durch dieses? ich bin mir nicht sicher. man müsste das wohl mal noch näher untersuchen (mittels sql-abfragen?) – ob z. b. ein unterstrich geeignet wäre. soll ich oder will jemand mal ein meinungsbild dazu erstellen?
- mfg --joni Δ 21:13, 19. Apr 2005 (CEST)
-
-
-
-
-
Der Unterstrich kommt häufig in <math>…</math>-Abschnitten vor, inwieweit die Software das zu unterscheiden vermöge, kann ich nicht beurteilen --141.53.194.251 11:32, 20. Apr 2005 (CEST)
- Da eine entsprechende Syntax ja sowieso neu programmiert werden müsste, sollte man das leicht(?) ausnehmen können. Neben <math> wohl auch <nowiki> und <pre>-Bereiche, kommt da noch was dazu?
- Mir persönlich gefallen die Unterstriche besser als solche Einfasser, man wird ja meist auch keine längeren Abschnitte ohne Umbruch darstellen wollen, und Unterstriche bedeuten auch keine zusätzlichen Zeichen. Ich werd mal gucken, ob ich es hinkriege mit einer schönen Abfrage die Zahl der betroffenen Stellen in meinem lokalen Dump abzufragen. --::Slomox:: >< 17:11, 20. Apr 2005 (CEST)
-
-
- Entenhausen hat nie und nimmer 18 Millionen Einwohner. Wenn ich mich richtig erinnere, wurde in irgeneiner Geschichte von etwa 1 Million gesprochen, ts. :-)
- Sind aber immer noch 2 Zeichen zu tippen gegenüber einem beim Unterstrich. Meine SQL-Abfrage war bisher nicht sehr aussagefähig. Es gestaltet sich schwierig, alle syntaktischen Ausnahmen, in denen Unterstriche weiterhin andere Funktionen haben können, auszunehmen. Das sind - neben <math>, <nowiki> und <pre> - <gallery>, Vorlagenlinks, Wikilinks und Weblinks (ich schreibe aus der Erinnerung, vielleicht habe ich noch wieder was vergessen). Wenn ich diese versuche auszunehmen, bleiben etwa 1000 Seiten übrig, die Unterstriche enthalten (wobei es noch etwas mehr sein könnten, da obige Ausnahmen mit SQL-Mitteln formuliert möglicherweise mehr Seiten ausschließen, als nötig). Von diesen 1000 Seiten sind fast alle außerhalb des Artikelnamensraums und unproblematisch (zum Beispiel Emphatisierung durch "_betont_"). Aber ich werd versuchen das noch genauer zu machen. --::Slomox:: >< 17:56, 22. Apr 2005 (CEST)
-
-
-
-
- Sind aber immer noch 2 Zeichen zu tippen gegenüber einem beim Unterstrich. das stimmt nicht so ganz. :) um einen unterstrich zu erzeugen, muss man shift gedrückt halten und dann die bindestrichtaste drücken. möglicherweise sogar umständlicher, als zweimal schnell hintereinander auf dieselbe taste zu hauen. --joni Δ 23:07, 22. Apr 2005 (CEST)
-
-
-
-
-
-
- Ich glaube, das gibt sich nicht viel, aber ´´ wird eigentlich für sonst nichts verwendet, der Unterstrich hingegen schon. (Korrigiert mich, wenn ich mich irre.)--FWHS 10:45, 23. Apr 2005 (CEST)
-
-
-
-
-
-
-
-
-
- Na gut, vom Tippen her kommt es aufs gleiche raus, aber es wird nur ein Byte entgegen zwei Bytes für ´´ benötigt, außerdem neigen Diakritika zum Verschmelzen mit anderen Zeichen, aus 12´´Ar könnten zum Beispiel 12´Ár werden oder sowas. Zudem ist der Unterstrich intuitiver, da die Assoziation zum Leerzeichen näher liegt, IMHO. --::Slomox:: >< 17:35, 26. Apr 2005 (CEST)
- Das stimmt allerdings. FWHS 14:35, 27. Apr 2005 (CEST)
- Na gut, vom Tippen her kommt es aufs gleiche raus, aber es wird nur ein Byte entgegen zwei Bytes für ´´ benötigt, außerdem neigen Diakritika zum Verschmelzen mit anderen Zeichen, aus 12´´Ar könnten zum Beispiel 12´Ár werden oder sowas. Zudem ist der Unterstrich intuitiver, da die Assoziation zum Leerzeichen näher liegt, IMHO. --::Slomox:: >< 17:35, 26. Apr 2005 (CEST)
-
-
-
-
-
-
-
-
-
-
-
- Ich könnte mich auch eher mit einem _ anfreunden als an einem ´´ oder muss ich ^^ eintippen? Ach da gab es noch '' und `` und „“. Entschuldigung um welche alternativen Striche wird hier noch diskutiert? ;-) --Atamari 19:21, 26. Apr 2005 (CEST)
- Diese beiden hier: ´´, aber `` nicht und auch keine Zitatzeichen FWHS 14:35, 27. Apr 2005 (CEST)
- Ich könnte mich auch eher mit einem _ anfreunden als an einem ´´ oder muss ich ^^ eintippen? Ach da gab es noch '' und `` und „“. Entschuldigung um welche alternativen Striche wird hier noch diskutiert? ;-) --Atamari 19:21, 26. Apr 2005 (CEST)
-
-
-
-
-
Einfasser für geschützte Leerzeichen zu verwenden, ist meiner Ansicht nach zu umständlich, besser wärem, alle ´´
oder _
(weiß noch nicht genau, was besser ist, außer in Links oder ähnlichem) im Quelltext als
an den Browser zu senden. - FWHS 13:59, 1. Aug 2005 (CEST)
- Nach der Diskussion weiß ich jetzt zwar nicht, wofür das dafür, bzw. das dagegen steht ;-), aber der normale Unterstrich wäre das einfachere --K@rl 09:34, 17. Aug 2005 (CEST)
»dafür« und »dagegen« aufgezweigt. --joni (Δisκussion) 14:21, 20. Aug 2005 (CEST)
-
- »es ist natürlich auch die frage, ob es nicht eher zur verwirrung führt, wenn der unterstrich trotzdem noch in dateinamen als normales leerzeichen gilt« (joni). --joni (Δisκussion) 14:21, 20. Aug 2005 (CEST)
- In Dateinamen sind Leerzeichen, und Unterstrich drei verschiedene Zeichen, wenn überhaupt vorkommt, aber so normal ist das Leerzeichen in Dateinamen nicht, an dessen Stelle ein Unterstrich gesetzt wird. Ein Zeilenumbruch ist auch da nicht erwünscht und so viel Verwirrung schafft der Unterschied in der Wikipedia nicht. FWHS 23:36, 21. Aug 2005 (CEST)
- Ich schätze mal ein
_
sieht für diesen Zweck einleuchtender aus und würde vielleicht eher von Gelegenheitseditoren als solches erkannt und verwendet werden, da sie es sich besser merken können. Außerdem gäbe es keine Verwechslungsgefahr wie bei´´
mit''
oder``
. --X4u 21:56, 5. Sep 2005 (CEST)
- »es ist natürlich auch die frage, ob es nicht eher zur verwirrung führt, wenn der unterstrich trotzdem noch in dateinamen als normales leerzeichen gilt« (joni). --joni (Δisκussion) 14:21, 20. Aug 2005 (CEST)
Man sollte auf keinen Fall Akzente verwenden, sonst kommt wieder mehr Leute auf die Idee, sie auch statt ’ oder ' als Apostroph zu verwenden. Außerdem kann ich dann nicht mehr per einfacher Textersetzung ganze Artikel korrigieren. --ChristianErtl 02:21, 26. Okt 2005 (CEST)
Punkt 1:
- für Extrasyntax für geschützte Leerzeichen: joni (Δisκussion), FWHS, Ce, x4u, ChristianErtl, Benutzer:Abubiju
- gegen Extrasyntax für geschützte Leerzeichen:
Punkt 2:
- für
´´
: joni (Δisκussion) - für
_
: x4u, ChristianErtl, Benutzer:Abubiju
Punkt 3:
- für Realisierung als Einfasser, in dem alle Leerzeichen durch geschützte Leerzeichen ersetzt werden:
- dafür, dass Vorkommnisse des/der dafür festgelegte(n) Zeichen direkt durch geschützte Leerzeichen ersetzt werden: FWHS, joni (Δisκussion), Ce, Benutzer:Abubiju
[Bearbeiten] vorlage in parameter von vorlage benutzen
es geht mir nicht darum, beim schreiben einer vorlage eine vorlage in ihr zu verwenden – das geht nämlich schon –, sondern, wenn man eine vorlage mit »{{…« einbindet, in dieser vorlage in einem parameter von ihr eine weitere vorlage benutzen zu können. das wäre manchmal echt hilfreich. --joni Δ 23:09, 29. Jul 2005 (CEST)
- Jo den Quelltext möchte ich sehen. Anfänger haben ja schon bei standard Tabellen oder Vorlagen Probleme den zu verstehen. Aber mach du mal :) --Träumer 12:00, 15. Aug 2005 (CEST)
-
- das macht es ja nicht weniger nützlich.
- beispiel:
{{Vorlage 1|{{Vorlage 2|bla}}|Test}}
--joni (Δisκussion) 13:47, 15. Aug 2005 (CEST)
- Über das Problem bin ich heute auch gestolpert und habe in der Diskussion zu Vorlagen nachgefragt da es mir unlogisch erschien. Es gibt auch bereits einen Wikimedia Bugzilla Eintrag dazu. --X4u 19:19, 19. Sep 2005 (CEST)
[Bearbeiten] nach abspeichern zur richtigen überschrift springen
wenn es zwei überschriften gibt, die gleich lauten, und man im inhaltsverzeichnis eine auswählt, kommt man zur richtigen überschrift. aber wenn man eine neue überschrift mit dem plus neben »Seite bearbeiten« erstellt und sie so benennt wie eine andere schon existente, wird nach speichern zur ersten gesprungen. es sollte zur richtigen gesprungen werden. --joni (Δisκussion) 19:05, 14. Aug 2005 (CEST)
- Es sollte doch keine zwei gleichlautende Überschriften geben, oder? Etwas anderes wäre dies bei Überschriften in der "Ebene 3" innerhalb zwei verschiedener "Ebene 2"-Abschnitte. Aber kommt das vor? Und wird das falsch behandelt? FWHS 23:42, 21. Aug 2005 (CEST)
- dafür: joni (Δisκussion), ((ó)) Käffchen?!? ,
- dagegen:
[Bearbeiten] Visuelle Kenntlichmachung neuer Benutzer in den Recent Changes
(von "Wikipedia:Verbesserungsvorschläge" hierhin kopiert und leicht modifiziert)
Von IPs und neuen Benutzern werden neben gutem sinnvollen Edits und Artikelneuanlagen häufig leider auch weniger sinnvolle Aktionen getätigt, und es gibt die Special:Recentchanges-Liste die die neuesten Änderungen anzeigt, und für IPs sogar einen extra Filter bereitstellt. Es wäre hilfreich, auch neue Benutzer, die ja nicht immer "rot " sind, in dieser Liste erkennen zu können, um ggf einen prüfenden Blick auf die jeweilige Änderungen werfen zu können. URV's z.B. kommen meiner Erfahrung nach nahezu ausschliesslich von IPs und neuen Benutzern. Weiterhin würde dies ein gezieltes Coaching betroffener Benutzer erleichtern. Eine Kennzeichnung könnte z. B. so aussehen : "Benutzer (n)", und analog zur Sperre der Verschiebefunktion für das neueste Prozent der Benutzer geschehen. -- Littl relax 08:58, 17. Aug 2005 (CEST)
- Vor allem im Sinne einer Möglichkeit diesen besser helfen zu können. ((ó)) Käffchen?!? 09:43, 17. Aug 2005 (CEST)
- Ich habe den Vorschlag als Bug 3226 auf MediaZilla eingetragen. --MaKoLine 13:58, 23. Aug 2005 (CEST)
Heute wurde der Feature-Request von Rob Church abgelehnt. Er sagt, dass das zu viele SQL-Queries hervorrufen würde, da hat er schon Recht, aber weiß jemand von euch, wie das mit dem Verschieben (bzw. der Berechtigung zu selbigem) gemacht wird? Sollten wir unsere Idee noch weiter erklären? --MaKoLine 17:41, 16. Dez 2005 (CET)
- Brion hat den Feature Request gestern Abend wieder geöffnet! --MaKoLine 11:24, 17. Dez 2005 (CET)
- dafür: Littl relax, Gunter Krebs Δ, ((ó)) Käffchen?!? , Liesel, Magadan ?! , He3nry, Gunfighter-6, Meleagros, Sechmet Ω, Jcornelius , NiTen (Discworld), MaKoLine, FWHS, Idler ∀, Benutzer:Rdb?
- dagegen:
[Bearbeiten] Hilfreichere Redirects
Wenn man über einen Redirect auf eine Seite kommt, kann es vorkommen, dass einem der Grund dafür nicht gleich ersichtlich ist. Wenn ich zum Beispiel nach "Bremuki" suche, weil ich nicht weiß, was das ist, werde ich auf die Seite "Revensteinen" weitergeleitet. Nun hilft mir die Seite über die Stadt Revensteinen nicht zu klären, was "Bremuki" ist. Erst mit der Suchfunktion meines Browsers gelange ich dann zu einen Abschnitt, der mir erklärt, dass Bremuki eine Revensteinener Backspezialität ist. Diese Möglichkeit hätte ich nicht, wenn
- ich die Suchfunktion meines Browsers nicht kennte.
- das Wort Bremuki gar nicht vorkommt, z.B. weil es im Artikel mit einem Synonym bezeichnet ist.
Daher schlage ich vor, dass bei erfolgtem Redirect statt (Weitergeleitet von Bremuki) eine kurze Erklärung angezeigt wird: (Bremuki ist eine Revensteinener Spezialität, siehe unten). Dies kann mittels erweiterter Redirect-Notation geschehen, etwa:
#REDIRECT [[Revensteinen|ist eine ...]]
--Duende 23:35, 10. Sep 2005 (CEST)
- Die Kenntnis grundlegender Brwoserfunktionen dürfen wir wohl schon voraussetzen. Sollte allerdings der Redirect-Begriff im Zielartikel tatsächlich einmal nicht auftauchen, dann wäre der Redirect auch konsequenterweise zu löschen. --Zinnmann d 21:49, 11. Sep 2005 (CEST)
- Löschtroll. nein nicht löschen, sondern den Begriff in den Artikel ergänzen.--Löschfix 03:32, 24. Aug 2006 (CEST)
- Auch wenn man die gesuchte Stelle per Browserfunktion finden kann, halte ich es für sinnvoll, begründete Redirects einzuführen. Schließlich schlägt man im Lexikon etwas nach, was man nicht kennt. Daher kann es (besonders für Anfänger) verwirrend sein, plötzlich von einem zum anderen Begriff zu kommen, ohne den Zusammenhang zu kennen. --Duende 16:38, 14. Sep 2005 (CEST)
- Grundsätzlich wäre eine derartige Funktion hilfreich. Allerdings sollte sie anders implementiert werden: Der Rest des Quellcodes der Redirectseite nach der Redirektzeile sollte einfach am Anfang der Zielseite eingefügt werden.-- StefanL 22:02, 14. Sep 2005 (CEST)
Eigentlich erübrigt sich die Diskussion, da eine Umleitung bei der Backspezialität falsch ist. Umleitungen sollen nur bei Synonymen verwendet werden, also etwa "Apfelsine → Orange" oder "Vicco von Bülow → Loriot". Falsch hingegen sind Teilbegriffe (Geschichte Chiles → Chile) oder weitere Umleitungen (Bremuki → Revensteinen). Sowas ist deshalb ungünstig, weil man zum einen im Artikel erst suchen muss, die Artikel auch länger (und damit unübersichtlich werden) und letztlich die Wikipedia um einen vielleicht ja spannenden Artikel über Bremuki gebracht wird. Meine Empfehlung: Umleitung einfach löschen lassen oder zu einem Kurzartikel umbauen. Stern 21:21, 24. Feb 2006 (CET)
- Ich finde das ist eine zu strenge Auslegung, es macht in Einzelfällen durchaus Sinn, auch Teilredirects zu erlauben. Wie wäre es wenn der redir nicht von "Geschichte von Chile" auf "Chile" verweist, sondern auf "Chile#Geschichte".--Löschfix 03:32, 24. Aug 2006 (CEST)
- Das Feature ist weniger notwendig, als den Begriff, im Artikel selbst zu erklären. Viel schlechter finde ich, wenn redirects aufgelöst werden - dann weiß man nämlich noch weniger, warum man daher kommt. Deshalb siehe Anfrage unten. --K@rl 20:05, 24. Jan. 2007 (CET)
[Bearbeiten] 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)
- Siehe auch die entsprechende Diskussion auf Wikipedia-l: hier und hier (unten). --rdb? 12:07, 19. 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)
[Bearbeiten] 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)
[Bearbeiten] Suchfunktion ergänzt keine ´`^ (z.B.: e->é; o->ô; a->à)
Die Suchfunktion findet bei der Eingabe z.B. "Gerondif" keinen einzigen Artikel, obwohl der Artikel "Gérondif" existiert. Dieses Problem ist z.B. in der Suchfunktion auf der Seite http://dict.leo.org/?lp=frde&search= gelöst, also wird es auch möglich sein, dies in Wikipedia umzusetzen.
--- Georg Konwiser
- pro: Tlustulimu, Löschfix Die Suchfunktion ist sowieso unter aller Kanone
- contra:
[Bearbeiten] weiterführende Links auch auf Bilder
Zweck:Usability
Beispiel Hauptseite: bei einigen Bildern macht es einfach keinen Sinn das Bild vergrößert anzuzeigen, so beim Bild vom Artikel des Tages oder den Bildern zu den Schwesterprojekten der WP. Bei diesen und nur bei diesen wäre es gut wenn man wie folgt sinnvoll verlinken könnte:
[[Bild:Artikel_des_Tages.jpg|thumb|link:[[Artikel_des_Tages]]|Beschreibungstext]]
Anfänger sind das einfach gewöhnt auf Bilder zu klicken. Kolossos 14:31, 4. Dez 2005 (CET)
- pro:
--Bbswl 21:29, 16. Dez 2005 (CET)
- Diese Option halte ich für l-a-n-g-e überfällig. Das ist doch eine Brot-und-Butter-Funktion jeder Internetseite, z.B. über <A HREF="http://... verlinkte Seite.htm"><img src="Bild-Pfad"></A> Man klickt auf ein Bild und wird auf einen mit dem Bild verknüften Link weitergeleitet. Ich kann in keiner Weise nachvollziehen, warum die MediaWiki-Software diese wichtige Funktion bislang ausklammert. IMHO ein echtes Manko gegenüber HTML!
--Atreiju 01:29, 17. Dez 2005 (CET)
- Also ich finde das auch sehr sinnvoll! gerade bei dem Artikel des Tages.
- contra:
- Ich fürchte das gibt Lizenzprobleme, da man dann nicht mehr so einfach auf die Bildbeschreibungsseite mit den Lizenzangaben kommt. -- Timo Müller Diskussion 15:32, 4. Dez 2005 (CET)
- Nicht so einfach, aber über den Quelltext kommt trotzdem jeder dran.Kolossos 21:34, 16. Dez 2005 (CET)
- Wird schon lange durch bug 539 abgedeckt, bitte dort besonders #comment 6 und #comment 12 beachten. M.E. ein Feature, auf das bewusst komplett verzichtet werden sollte, weil es sich sonst nicht nur auf die Hauptseite o.ä. Ausnahmezwecke beschränken lässt und dann auch für Inkonsistenz sorgt. --:Bdk: 13:52, 19. Dez 2005 (CET)
Der genannte bug 539 hat soweit ich gelesen habe keinen Zugriff auf die Bildbeschreibungsseite, dabei kann man mittels CSS Bilder übereinander legen und somit eine Lupe am Bildrand einblenden. Wie man an meinem ersten Versuch mit einer einfachen Vorlage erkennen kann, wenn man mit der Maus über das Bild bzw. die Lupe geht und die Maus kurz ruht. Kolossos 18:08, 2. Feb 2006 (CET)
- Hat sich durch Vorlage:Link-Bild erstmal erledigt. Kolossos 19:41, 16. Feb 2006 (CET)
[Bearbeiten] 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)
-
[Bearbeiten] 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)
- Benutzer:BLueFiSH.as/Javascripts_&_Stylesheets_von_Benutzern#dbenzhuser denke ich erledigt dies.
-- Ολλίμίνατορέ •Ω• 13:44, 26. Apr 2006 (CEST)
- Benutzer:BLueFiSH.as/Javascripts_&_Stylesheets_von_Benutzern#Tinz 2. Möglichkeit -- Ολλίμίνατορέ •Ω• 03:10, 28. Apr 2006 (CEST)
[Bearbeiten] 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
- Contra 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)
[Bearbeiten] Variable CURRENTTIME (erl)
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)
[Bearbeiten] 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)
[Bearbeiten] 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:
- Wenn beim Bearbeiten eines Absatzes ein Bearbeitungskonflikt auftritt, sollten die beiden Bearbeitungsboxen auch nur den entsprechenden Absatz anzeigen.
- 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)
[Bearbeiten] 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.
- 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.
- 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)
[Bearbeiten] 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)
- Dafür: CyRoXX (? ±) Tlustulimu
- Dagegen:
[Bearbeiten] 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 MediaZilla:2699, da tut sich allerdings schon länger nichts mehr. Viele Grüße Pill δ 00:08, 10. Aug 2006 (CEST)
[Bearbeiten] 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)
[Bearbeiten] 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 [6], 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 hier, 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)
[Bearbeiten] 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:
[Bearbeiten] 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:
[Bearbeiten] Änderungen von IPs überprüfen
Hallo! Wäre es nicht sinnvoll einen Knopf für die Admins zu schaffen, mit dem sie hinter Änderungen von IPs einen automatischen "Überprüft"-Vermerk machen können? Ich denke dabei an sowas in der Beobachtungsliste:
(Unterschied) (Versionen) . . Adana; 17:16 . . (+2 Bytes) . . 89.49.70.230 (Diskussion) Überprüft. Admin-Name |
Dann müssten wir uns nicht mehr alle gleichzeitig auf die Änderungen von IPs stürzen, sondern würden auf Anhieb sehen, dass da schon ein Admin drüber geguckt hat. --Enricopedia ⇄ 17:41, 21. Jan. 2007 (CET)
- Erstens glaube ich ist es der falsche Ansatz nur Admins sowas zu erlauben (viel zuviel Aufwand alle zu überprüfen; Überprüfung ist auch normalen Benutzern möglich). Zweitens wird das allgemein schon praktiziert, und zwar bei den Tools, die einem die Letzten Änderungen anzeigen. Zu guter Letzt gibt es noch Wikipedia:Geprüfte Versionen und Wikipedia:Gesichtete Versionen. -- Amtiss, SNAFU ? 19:23, 21. Jan. 2007 (CET)
-
- Die Tools die einem die letzten Änderungen anzeigen und wo dies praktiziert wird, kenne ich nicht.
- Die Beschränkung nur Admins zuzulassen, muss natürlich nicht sein aber es sollte auch nicht jeder angemeldete Benutzer die Möglichkeit haben, weil man sich dann wieder nicht darauf verlassen kann, dass da nicht zwei Spinner am Werk sind.
- Wikipedia:Geprüfte Versionen ist ein ganz anderes Thema
- Wikipedia:Gesichtete Versionen würde, wenn es so umgesetzt wird, meinen Vorschlag überflüssig machen, weil nicht gleich jeder Mist sofort im Artikel steht und man mehr Zeit zum überprüfen hat.
- Letztendlich sollte mein Vorschlag eine Verbesserung für Jeden und für jedermanns Beobachtungsliste sein, weil die ja wohl von den meisten Leuten regelmäßig genutzt wird − im Gegensatz zu den angesprochenen tools. Gruß --Enricopedia ⇄ 21:16, 21. Jan. 2007 (CET)
-
[Bearbeiten] Anzeige von Herkunftslink
Es wäre oft hilfreich, wenn unter einem Artikel, ähnlich dem redirect Link angezeigt wäre, was in dem angeklickten Link hinter dem | steht. Oft ist dann klarer, warum man hierher kommt. Denn manchmal sind ja die Links mit einem ganz anderen Text als den eigentlichen verlinkten Artikel überblendet. Das würde die Handhabung meiner Meinung für den Leser wesentlich erleichtern. --K@rl 22:53, 22. Jan. 2007 (CET)
[Bearbeiten] Von den Admins hier realisierbar
[Bearbeiten] HTML-Titel beim Bearbeiten einer Seite
Wenn man eine Seite bearbeitet, erscheint im Moment im HTML-Titel-Tag (also oben in der Leiste des Browserfensters)
Bearbeiten von TITEL -- bearbeiten -- Wikipedia
das ist etwas redundant, nehmt doch eines der "bearbeiten"s raus --Pinguin.tk 19:02, 29. Mai 2004 (CEST)
- Vielleicht wurde es inzwischen geändert, aber bei mir heißt es wie eh und je "Bearbeiten von xy", also nur einmal "bearbeiten". --Zebbo 23:39, 29. Mai 2004 (CEST)
- Hm, ist vielleicht browserabhängig, bei mir ist es immer noch wie oben beschrieben... (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204) --Pinguin.tk 00:43, 30. Mai 2004 (CEST)
- kl. Update, war wohl missverständlich, ich bezog mich auf den HTML-Titel-Tag... sorry! Pinguin.tk 20:06, 30. Mai 2004 (CEST)
-
- Ist mir gerade auch aufgefallen, denn im Tag ist es auch bei mir wie beschrieben. Ist auf jeden Fall redundant und ich stimme für Änderung. "Wikipedia: Bearbeiten von XY" wäre imho perfekt. --Zebbo 12:47, 31. Mai 2004 (CEST)
-
-
- Es wird noch unsinniger, wenn man nur einen Absatz bearbeitet:
Bearbeiten von Wikipedia:Verbesserungsvorschläge/Feature-Requests (Absatz) - Seite bearbeiten - Wikipedia
Da steht dann auch nciht dabei, welcher Absatz es ist. Deshalb bin ich für die FormBearbeiten: Seitentitel - Wikipedia
oder beim Bearbeiten eines Absatzes wenn möglichBearbeiten: Seitentitel#Absatztitel - Wikipedia
(# als Trennzeichen, weil es auch in den URLs verwendet wird.) - FWHS 15:00, 1. Aug 2005 (CEST)
- Es wird noch unsinniger, wenn man nur einen Absatz bearbeitet:
-
[Bearbeiten] Zeilenabstand Skin MonoBook
(Das gilt ebenso für das Skin Cologne Blue)
Das Stilesheet setzt die Zeilenhöhe (line-height) in #content, aber z.B. nicht bei h3. Das hat zur folge, dass Überschriften innerhalb von content einen zu kleinen Zeilenabstand haben. Ich empfehle daher z.B.
h1, h2, h3, h4, h5, h6 { line-height:1em; }
einzufügen. --Hokanomono|Diskussion 17:46, 1. Jun 2004 (CEST)
- dafür: FWHS
- dagegen:
[Bearbeiten] Hinweis auf Unterschrift im Handbuch
- Ihr "Spitzname" (zum "Unterschreiben"): sollte einen Link auf die entsprechende Handbuchseite stehen (ich hab zu lange gebraucht um ~~~~ zu finden. -- TomK32 07:20, 27. Feb 2003 (CET)
- dafür: FWHS
- dagegen:
[Bearbeiten] "Links auf diese Seite" in "Was verweist hierher" umbenennen
Ich möchte diese Umbenennung analog zur englischsprachigen Wikipedia (dort: What links here) vorschlagen. Ich benutze beide Wikipedias, und mir geht es deshalb oft so, dass ich in der deutschen Wikipedia instinktiv nach einem Link "Was verweist hierher" suche, bis mir klar wird, dass der gesuchte Link hier "Links auf diese Seite" heißt. Weniger gut fände ich dagegen "Was linkt hierher", weil das zu denglisch klingt. -- Neitram 11:57, 19. Mär 2004 (CET)
- Da gab schon mal ne Diskussion zu, da es verschiedene Auffassung gibt, was der Unterschied zwischen 'hin' und 'her' ist. ich bin auch für 'Was zeigt hierher' - WikiWichtel 12:28, 19. Mär 2004 (CET)
- Wie wär's stattdessen mit "Verweise auf diesen Artikel" und "Verweise auf andere Artikel"? --Tobias 23:38, 11. Jan 2005 (CET)
[Bearbeiten] "Hierher oder Hierhin"!?
Auf der linken Seite steht unter Werkzeuge das schreckliche Wort „hierhin“. Das ist nicht Deutsch, im Deutschen gibt es nur „hierher“ (Bewegung zum Sprecher) oder „dorthin“ (Bewegung vom Sprecher weg). Bitte schnell ändern, mir verursacht diese Sprachschluderei schlimme Schmerzen.
- abgesehen davon daß es mir total egal ist; aber der Duden kennt das wort durchaus (www.duden.de) ...Sicherlich 00:22, 10. Aug 2004 (CEST)
- "Hierhin" ist zwar korrekt, ich finde aber trotzdem, dass "what links here" etwas unglücklich übersetzt wurde. "Welche Artikel verweisen hierher" klingt imho besser. --Zebbo 15:52, 20. Aug 2004 (CEST)
- "Was zeigt hierher" reicht, "Welche Artikel verweisen hierher" ist zu lang. Royd
- „Der Ort zum Herausfinden“ ist auch etwas komisch.--Hannes2 Diskussion 20:13, 4. Mär 2006 (CET)
- "Was zeigt hierher" reicht, "Welche Artikel verweisen hierher" ist zu lang. Royd
[Bearbeiten] "Verlinkte Seiten" in "Letzte Änderungen" umbenennen
Ebenfalls möchte ich diese Umbenennung vorschlagen, da "Verlinkte Seiten" eine sehr unklare, vieldeutige Formulierung ist. (Seiten, die von hier aus verlinkt sind? *) Oder was?) Die Seite, auf die man durch diesen Link kommt, heißt "Letzte Änderungen" **), also wäre das ein besserer Name für diesen Link. -- Neitram 12:13, 19. Mär 2004 (CET)
- *)genau das
- **) es ist aber eine spezielle Form dieser Seite...
- --WikiWichtel 12:28, 19. Mär 2004 (CET)
-
- Letzte Änderungen ist schon belegt. Andere Vorschläge? --elian 20:55, 19. Mär 2004 (CET)
-
-
- Eigentlich müsste man Letzte Änderungen auf verlinkten Seiten schreiben, was für die Navigation viel zu lang und umständlich ist. Das Skript heißt Spezial:RecentchangesLinked, die en: verwendet Related Changes. Vielleicht könnte man das durch
-
- Verwandte Änderungen
-
- oder
-
- Verlinkte Änderungen
-
- ausdrücken? Ist zwar auch etwas gewöhnungsbedürftig, trifft's aber etwas besser --Hubi 18:54, 30. Aug 2004 (CEST)
- Eigentlich müsste man Letzte Änderungen auf verlinkten Seiten schreiben, was für die Navigation viel zu lang und umständlich ist. Das Skript heißt Spezial:RecentchangesLinked, die en: verwendet Related Changes. Vielleicht könnte man das durch
-
[Bearbeiten] Unerwünschte Lemmata sperren
Es tauchen immer wieder unerwünschte Artikel auf, die entweder pubertär motiviert sind, oder aber aufgrund von Links in bestehenden Artikeln als fehlend erscheinen. Ich hielte es für eine gute Sache wenn man Lemmata sperren könnte, natürlich nach Diskussion wie beim Löschen. Ich könnte mir dazu gesperrte redirects vorstellen, die auf ein sinnvolles Lemma oder eine Erklärung weiterleiten. So könnte man sowohl pubertäre Ausdrücke abfangen, als auch Kleinstartikel durch Weiterleitung zum nächststehenden Artikel vermeiden. Mit der Funktion "Links auf diese Seite" würde man auch falsche Verlinkungen finden, sogar eine Korrektur durch Bots wäre möglich. --stefan (?!) 19:55, 8. Sep 2004 (CEST)
- Es gäbe auch noch eine alternative Methode mit Vorlagen. Außerdem sollte die Software in diese Artikel "noindex" rein, damit sie nicht in Suchmaschinen auftauchen. --stefan (?!) 12:20, 9. Sep 2004 (CEST)
- Für unerwünschte Wörterbuch-Artikel habe ich die [Vorlage:Wiktionary] angelegt - für Artikel, die aus anderen Gründen unerwünscht sind, könnte man ähnliche Bausteine erstellen. -- D. Düsentrieb (?!) 20:29, 12. Sep 2004 (CEST)
- Siehe bitte zu dem Thema meine Lösung des Problems der Beleidungen in Spasti. ((ó)) Käffchen?!? 10:03, 17. Aug 2005 (CEST)
es gibt auch noch {{Gesperrtes Lemma}} - reinschmeißen, seite sperren und gut ist. -- ∂ 10:38, 17. Aug 2005 (CEST)
-
-
- Die Vorschläge sind beide gut, aber leider fehlen Kategorien. Welche wären denn da am besten? FWHS 23:58, 21. Aug 2005 (CEST)
-
[Bearbeiten] InterWiki-Links markieren (Skins)
Ich möchte Vorschlagen alle Skins so anzupassen, dass InterWiki-Links deutlich von internen Wiki-Links zu unterscheiden sind (im Text, nicht für Sprachlinks in der Navigationsleiste!). Derzeit werden InterWiki-Links nur farblich etwas anders dargestellt - das reicht IMHO nicht aus. Man könnte den Farbunterschied prominenter machen - das würde dann vermutlich aber sehr Bunt. Desshalb würde ich vorschlagen, hinter InterWiki-Links ein Icon oder Symbol anzuzeigen, ähnlich wie das bei externen Links der Fall ist - das lässt sich leicht mit CSS realisieren:
#bodyContent a.extiw:after { content:"✩"; font-size:120%; }
Der Hintergrund ist folgender: Wörterbucheinträge gehören nicht in die Wikipedia - sie werden in's Wiktionary verschoben. Manchmal ist es aber dennoch wichtig, mit einem InterWiki-Link auf den Wiktionary-Eintrag zu verweisen. Für Benutzer und nur-Leser ist das aber verwirrend, wenn sie einem Link folgen und plötzlich in einem anderen Wiki sind - oder schlimmer, sie merken es gar nicht, und wundern sich, dass sie über die Suche nicht das finden, was sie erwarten. Siehe dazu auch: Vorlage Diskussion:Wörterbuch#Projekte unterschieden. -- D. Düsentrieb (?!) 20:52, 12. Sep 2004 (CEST)
- Schön wäre auch ein Link-Titel, der angibt, zu welcher Interwiki denn verwiesen wird, z.B. "Wikitionary - Wörterbuch". --Tobias 23:43, 11. Jan 2005 (CET)
Hinweis: wie alles, was mit CSS zu tun hat, lässt sich das in den Benutzereinstellungen abschalten (per user-css). Eine eigene (leichter zu bedienende) Option wäre wohl auch kein Problem, würde aber eine kleine Softwareänderung erfordern. -- D. Düsentrieb (?!) 14:06, 16. Sep 2004 (CEST)
Dafür: Melancholie, Tobias, FWHS
Dagegen: Ce (es sei denn, ich kann das in den Benutzereinstellungen abschalten), Elian Φ (korrespondiere Interwiki-Links gehören in die Seitenleiste, oder als ganz normale externe Links unter Weblinks, auf keinen Fall haben sie jedoch was im Artikeltext verloren) Meph666
@Elian: wenn es einen Gleichnamigen Artikel in der WP nicht gibt, wo soll der Link dann in die Seitenleiste? Und in welchem Artikel unter Weblinks? Es geht doch darum, was mit links passiert, die auf einen Artikel zeigen, der ins Wiktionasy verschoben wurde. Ansonsten würde ich dir zustimmen - in diesem Fall wäre dem Benutzer klar, dass er in ein anderes Projekt wechselt. -- D. Düsentrieb ⇌ 01:49, 26. Sep 2004 (CEST)
[Bearbeiten] Vorschlag für eine Wikipedia "Einfaches Deutsch", ähnlich der Wikipedia "Simple English"
Ich schlage vor, eine weitere deutschsprachige Wikipedia ähnlich der "Simple"-Wikipedia, einzurichten.
Zielgruppen
- Teilnehmer an Kursen von "Deutsch als Fremdsprache" und deren Lehrern
- Diesen Personen steht so ein Korpus an einfachen, aber aktuellen und realitätsbezogenen Text in Deutsch und über deutsche Themen zur Verfügung
- Schüler der niedrigen Klassenstufen
- Vergleichbar einem "Schülerlexikon" gibt es für Kinder eine kleinere Enzyklopädie, die ihre Inhalte in einfachen Worten darbietet
- Editoren anderssprachiger Wikipedias, die nach übersetzbaren Texten zu spezifisch deutschen Themenbereichen suchen
Inhalte
- Grundversorgung: Texte zu Lemmas, die es auch in der "Simple" und in der Liste der 1000 wichtigsten Themen gibt
- Biografien: Texte, über deutschsprachige Personen, die international bekannt sind, sowie Personen, die für den deutschsprachigen Raum eine besondere Bedeutung haben
- Spezifisch deutsche Begriffe, wie "Sachzwang", "Gemütlichkeit", "Tümlichkeit", "Treppenwitz", usw.
- Geografie und Geschichte des deutschsprachigen Raums
Form
- Kurze Artikel, weitgehend aus Hauptsätzen (Präsens, Aussageform) nach dem Muster Subjekt, Prädikat, Objekte Satzende
- Verwendung der allgemeinüblichen deutschen Verben, Vermeidung von extravaganten Formulierungen
- wo möglich, Vermeidung von Fremdwörtern und zu vielen Adjektiven
- Am Ende jedes Artikels eine alphabetische Liste sämtlicher im Artikel verwendeten Wörter (Vokabeln) in der Form von Links auf die entsprechenden Einträge in allen (verschiedensprachigen) Wiktionaries, soweit es dort das jeweilige Lemma gibt (sollte durch einen Bot gemacht und regelmäßig aktualisiert werden)
Umsetzung
- Erstellung eines Grundbestands an Artikeln durch Kürzung und Vereinfachung von bestehenden Artikeln aus der deutschen Wikipedia
- Pressemitteilungen an Goethe-Institut, Vereinigung der Lehrer von Deutsch als Fremdsprache, Sprachschulen
80.226.226.180 17:55, 12. Okt 2004 (CEST)
- Dafür:
- M. Schebsdat / m-s / KalKin
- Raus aus dem Elfenbeinturm. Mir gefällt aber die Variante Simple English nicht. Eleganter fände ich es, wenn die Artikel unter einem Dach bleiben würden. Vielleicht als eine Art zweiter Ebene zu jedem Artikel (Ähnlich der Diskussionsseite), die den Sachverhalt in einfachen Wörtern erklärt. Vorteil wäre das gemeinsame Nutzen einer Suchfunktion. Auch gibt es jetzt bereits etliche Artikel (vor allem die kurzen), die nicht mer vereinfacht werden müssen. -- Hey Teacher 13:35, 10. Feb 2006 (CET)
- Dagegen:
- Wir sollten unsere Bearbeiterkräfter bündeln, nicht splitten! --Flominator 17:15, 11. Jul 2005 (CEST)
- Ich finds gut, das sich die englische Wikipedia gesplittet hat. So haben wir mehr Chancen sie einzuhohlen. Ähm ^^. Ich schließ mich Flominators meinung an Träumer
- --the one who was addicted (#) 23:07, 15. Aug 2005 (CEST)
- --Jcornelius 15:09, 17. Aug 2005 (CEST) ACK Flominator. Schon jetzt fehlen uns für bestimmte Bereiche Bearbeiter. In einer "Einfach Deutsch"-WP wird das noch häufiger auftreten.
- --chris 論 11:02, 30. Okt 2005 (CET)
- --Tlustulimu 12:59, 10. Feb 2006 (CET)
- --Heiko A 14:17, 21. Apr 2006 (CEST)
- --Spongo ⇄ 15:52, 22. Aug 2006 (CEST) Nicht noch mehr Müll.
- --Hannes2 Diskussion 16:32, 22. Aug 2006 (CEST)
- Neutral: Idee könnte mit der angedachten Kinder-Wikipedia umgesetzt werden. Gebu
- Kommentare:
- von M. Schebsdat / m-s / KalKin 11:47, 9. Jan 2005 (CET)
Ich würde die Gewichtung mehr auf die Kindgerechtigkeit legen. Also eine Wiki, die viel mit Bildern und Symbolen arbeitet. Eine große Schrift ist ebenso wichtig wie kurzer klarer Schreibstil.- Dazu gibt es hier schon Überlegungen: Wikipedia:WikiProjekt_Kinderseite --Gebu 12:02, 20. Jan 2005 (CET)
[Bearbeiten] Empfohlene Dateiformate - wanted: MIDI
Kürzlich wollte ich zu Scott Joplin eine seiner Kompositionen hochladen (er ist seit 87 Jahren tot, und die Datei habe ich eigenhändig erstellt), aber es wurde mir verwehrt: ".mid" ist kein empfohlenes Dateiformat. Empfohlene Dateiformate sind: jpg/jpeg und png. Es wäre doch nicht schlecht, wenn auch MIDI-Dateien erlaubt wären. Meine Datei ist nur 13,7 kB groß und bringt 3:43 Minuten Musik, das ist doch ein hervorragendes Verhältnis von Nutzen zu Datenvolumen. --Plenz 07:06, 14. Okt 2004 (CEST)
- früher konnte man alles hochladen, man musste die Warnung über die nicht empfolenen Formate nur ignorieren. Jetzt ist das für viele Formate deaktiviert, wegen einer Verweundbarkeit des Internetexplorer gegen JavaScript-Code in *beliebigen* Dateien - wie es scheint sind ein paar schon wieder Freigegeben worden, nachdem eine Möglichkeit gefunden wurde, Vieren dort aufzuspühren. Ich fände es aber auch sehr wichtig, dass MIDI und SVG wieder geht... könnte da mal jemand nachhaken? -- D. Düsentrieb ⇌ 14:39, 14. Okt 2004 (CEST)
-
- Verstehe ich jetzt nicht... wenn ich JavaScript in eine MIDI-Datei einbaue, wird der Code ausgeführt? Und bei JPG-Bildern braucht man den Benutzer nicht zu "schützen", weil man davon ausgeht, dass alle inzwischen die Patches installiert haben? Und was ist anders, wenn ich die MIDI-Datei auf eine andere Seite lade und in der Wikipedia verlinke? Nichts, oder? Also kann man auch gleich den Upload hier zulassen. --Plenz 00:29, 18. Okt 2004 (CEST)
-
-
- Soweit ich weis ist das so: ja, der Internet Explorer führt JavaScript in allen Dateien aus, die er für HTML hällt - völlig egal, was die Datei für eine Endung hat oder was der Server für einen MIME-Typ angibt. Will heissen: man kann in den IE mit einer bösen HTML+JavaScript-Datei, die auf .mid ended, Viren einschäusen. Zu den JPEGs: dort ist das Problem ein anderes (Buffer-Overflow-Exploits für SDK+), und das wird wohl durch einen scanner auf dem server abgefangen (soweit ich das der Mailingliste entnehmen konnte). Externe Links können natürlich verseucht sein, aber das ist dann auch eine rechtlich Frage (Sorgfaltspflicht und so) - es soll ja nachher keiner sagen, er hat sich den Virus in der Wikipedia gefangen. Auch wird auf diese Weise ein Bewusstsein für das Prtoblem geschaffen.
- Es ist übrigens durchaus möglich, das MIDIs eigentlich gefahrlos zu verwenden wären (weils 'nen scanner gibt oder aus irgend einem anderen Grund), dass es nur halt keiner Freigeschaltet hat. Frag doch mal auf dem Wikipedia:Chat. -- D. Düsentrieb ⇌ 03:55, 18. Okt 2004 (CEST)
- Im Chat konnte mir zwar jemand erklären, wie das mit den MIDI-Dateien und JavaScript ist, aber weiter sind wir leider nicht gekommen. Tatsache ist jedoch, dass jeder blutige Anfänger einen passenden Filter programmieren kann:
- * Alle MIDI-Dateien beginnen mit der Zeichenkette "MThd"
- * MIDI-Dateien enthalten keine JavaScript-Schlüsselwörter wie "function" etc.
- Mit diesen beiden Kriterien kann man doppelt sicher sein, lupenreine MIDI-Dateien vor sich zu haben. --Plenz 00:23, 20. Okt 2004 (CEST)
-
- Dafür : Leopard, thomas g graf ~ diskussion, FWHS, chris 論, Constructor
[Bearbeiten] Diskussionen im Text / Bessere Nachvollziehbarkeit von Diskussionsketten
Der Punkt Diskussion in der oberen Zeile
+-------+----------+ +----------+---------+ |Artikel|Diskussion| |bearbeiten|Versionen| +---------+ +-------------------------+ | |
ist für größere Artikel ziemlich ungeeignet. Bei größeren Artikel wäre es wesentlich übersichtlicher,
- wenn Bemerkungen (optional) am Ort des Geschehens plaziert wären
- für den normalen Wiki-Leser unsichtbar
- aber aufdeckbar
- könnte auch benutzt werden, um unfertigen Stoff zu verstecken (Mozilla stürzt ja häufig mal ab)
- Die alte Form der Diskussion würde ich beibehalten wollen, allerdings sollten auch dort ältere Bemerkungen in ein eigenes Untermenü abwandern.
- wenn erkennbar wäre, wer auf wen geantwortet hat, ähnlich wie bei News
slrn 0.9.7.4 ** Press '?' for help, 'q' to quit. ** Server: proxy.zeiss.de 1 - 21:[Herbert Feue] Sennheiser, defektes Kopfhörerkabel und Kulanz 2 - 9:[Oliver Brose] ├─> 3 - 24:[Norbert Hahn] ├─> 4 - 24:[Herbert Feue] │ └─> 5 - 18:[Andreas Wenz] ├─> 6 - 12:[Oliver Benni] ├─> 7 - 13:[Gernot Pruen] │ └─> 8 - 19:[Herbert Feue] │ └─> 9 - 34:[Falk Dübbert] ├─> 10 - 10:[Herbert Feue] │ └─> 11 - 25:[Herbert Feue] └─> 12 - 11:[Martin Erdtm] Suche Sicken fuer Coral 15L70 oder gleich Ersatztreiber [277/286 unread] Group: de.rec.musik.hifi -- 57/65 (89%) From: Herbert Feuerbach <herbert_feuerbach@gmx.de> Newsgroups: de.rec.musik.hifi Subject: Sennheiser, defektes Kopfhörerkabel und Kulanz Hallo, nachdem das Anschlusskabel meines gar nicht mal so alten HD-600 einen Wackelkontakt hat, habe ich hier in der Gruppe den Hinweis gefunden, es mal mit Kulanz zu versuchen. Sennheiser hielt davon gar nichts... statt auf meine Anfrage überhaupt einzugehen, bedankte man sich in bester Textbaustein-"Freundlichkeit" für meine Ersatzteilanfrage. Für mein Empfinden einigermassen frech. Beigefügt war ein Angebot über 28,78 frei Haus zzgl. 5,34 EUR Nachnahmegebühr. Verwendet habe ich das Service-Formular auf deren Website. Gibt es vielleicht noch eine andere "passende" Kontaktmöglichkeit? Gruß, Herbert 65151 : Sennheiser, defektes Kopfhörerkabel und Kulanz -- 1/25 (All) End of Thread.
- Wenn Diskussionen geschlossen sind und das Problem verschwunden ist, gehört es aus der Diskussion heraus. Sonst droht "Vermüllung" der Diskussionen, wie man es schon an vielen Stellen sieht.
Vorschlag für Bemerkungen innerhalb des Textes:
<<<Bemerkung <<<tiefer geschachtelte Bemerkung>>> >>>
Der Berg ist ca. 8800 Meter hoch <<<Weiß das jemand genauer? <<<Ich habe das mal vor langer Zeit ...>>> >>>
[Bearbeiten] Systematische Diskussionen (Erörterungen)
Hallo,
vorab: Ich bin mir bewußt, dass ich mit meinem Thema hier nicht so ganz richtig bin. Leider konnte ich auch nach längerem Suchen keine geeignetere Stelle finden - ich bitte um Nachsicht.
Mir liegt etwas am Herzen, dass ich gerne versuchen würde als Teil der Wikipedia oder im Rahmen eines Schwester-Projekts zu realisieren. Das Problem kennt bestimmt jeder von euch: Ein und dasselbe Thema (z.B. Agenda 2010, Genetischer Fingerabdruck Pro und Contra) wird in 100 verschiedenen Foren, im Fersehn oder im Radio mit immer wieder den gleichen Argumenten ausgetragen.
Am Ende der Sendezeit oder des Userinteresses steht dann ein laues Niveau im Raum und nächste Woche fängt das gleiche wieder bei null an. Hinzu kommen Abschweifungen (Beleidigungen inklusive), die mit dem eigentlichen Thema wirklich rein garnix zu tun haben, und die Diskussion im nichts versanden lassen. Außerdem kommt es z.T. zu Zeitintensivem Streit um die Sachliche Richtigkeit von Argumenten (z.B. so gesehn bei Frau Christiansen in der Sendung über den genetischen Fingerabdruck)
Wäre es da nicht gut wenn man da eine Struktur reinbekommen könnte. soetwas wie eine moderierte (Flames und Abschweifungen sind nicht konstruktiv) Erörterung, bei der alle Argumente und Gegenargumente mit Beispielen und allem drum und dran in einer ansprechenden Struktur aufgenommen wird.
Ich würde gerne wissen wie ihr über das Thema denkt und ob so ein Projekt möglich und gewollt ist?
Viele Grüße -- Garak76 16:43, 1. Feb 2005 (CET)
- Und wie soll die Wikipedia dafür sorgen, dass bei Christiansen die Diskussionen sachlich verlaufen? Oder was genau meinst du? --::Slomox:: >< 17:16, 1. Feb 2005 (CET)
-
- Das sollte nur auf ein Problem des derzeitigen Diskussios-Procedere hinweisen, dass auf TV / Radio zutrifft. Online ist es irrelevant. Die Kernaussage meines vorangegangenen Beitrags ist, dass immer wieder die gleich Diskussionen mit unbefriedigendem Verlauf und Ausgang geführt werden und ich mir das anders wünschen würde. -- Garak76 21:24, 1. Feb 2005 (CET)
-
-
- Das würde bedeuten, dass die WP aktueller werden müsste. Hartz 4 wäre so ein Artikel, der Hilfestellung bei der aktuellen politischen Diskusion finden könnte. Vielleicht könnte man ein Portal Aktuelles bauen, wo auf diese Dinge verwiesen werden könnte. Ich sehe z.B. seit einigen Tagen wie zur irakischen Wahl die Artikel täglich nachgeschrieben werden. Wenn man das z.B. mit WikiNews abstimmen könnte, gäbe es ein unabhängiges Archiv, wo die Zuschauer den Stand politischer Diskusionen oder ähnliches nachschlagen könnten. Z.B. für die Visa-Affäre wäre das nützlich. Ich weiß nur nicht, ob das von der WP geleistet werden kann. Ich wäre damit z.B. überfordert. --Zahnstein 03:49, 18. Feb 2005 (CET)
-
-
-
-
- Vielen Dank für deine Antwort. Für die praktische Umsetzung sehe ich es auch so, dass man die eine oder andere Erweiterung am WIKI-Code vornehmen müßte - um eine ansprechende und leistungsfähige Funktionalität zu gewährleiste. Daran würde ich mich, bei grundsätzlichem Interesse an dieser Idee, gerne beteiligen. Wer wäre denn der richtige Ansprechpartner um so etwas auf den Weg zu bringen? --Garak76 16:58, 18. Feb 2005 (CET)
-
-
- Wiki-Code ändern: Grundsätzlich ist der Wiki-Code frei erhältlich und kann zu Hause abgeändert werden. Wie das Einbringen von neuem Code in das bestehende System zu machen ist, erfährst du am besten hier [7] und noch spezieller auf der WikiTech-I Liste. Übrigens, wenn du dir so etwas zutraust, könnte auch das hier [8] für dich interessant sein. Jetzt zum Inhalt: Ich dachte weniger an Codeänderungen, als an die Frage, wo die Inhalte herkommen. Ich war mal eine Zeitlang bei einer politischen Partei in Gründung dabei und hatte dort versucht Leute zu motivieren, so etwas wie eine Datenbank des politischen Wissens aufzubauen. Das könnte man sehr gut mit einem Wikisystem machen, aber das Problem war und ist, dass dafür in der Regel das Wissen und das Interesse fehlt. Es gibt hier etwas, was in die Richtung geht, das Wikipedia:WikiProjekt Kommunalpolitik. Doch leider ist das tot. Auch bin ich mir nicht sicher, ob man politisches Basiswissen neutral formulieren kann, damit das hier akzeptiert wird. Entscheident für das alles sehe ich die Frage, woher nimmt man die Leute. Am besten wäre deshalb ein Verbleib in der Wikipedia mit einem z.B. Portal Politisches Wissen oder so (Falls du in einer Partei oder NGO sein solltest, wäre das mit dem Mitarbeitern nicht so problematisch und es würde nur ein Ort für das Wiki fehlen. Ist aber kostengünstig machbar). Doch kann man dann z.B. Genetischer Abdruck auch in einer Tiefe darstellen, die der Thematik angemessen ist? Oder würde das nicht z.B. ein ganzes Bündel von WP-Seiten benötigen, um das technisch, politisch, von der Sicherheit, wirtschaftlich, Machtstrukturen, Beteiligte Kräfte, etc. zu beschreiben. Alleine dieses Thema würde ich für eine Person mit einem Zeitbedarf von einem Monat ansetzen. Kurz um, so ein Politi-Wiki, wie es dir vorschwebt, ist sehr anspruchsvoll. Vielleicht, wäre es ein guter Anfang, wenn du auf dem Partal Politik und seinen Wikiprojekten deine Überlegungen vorstellst und nach Mitstreitern schaust. Vielleicht wäre es auch sinnvoll, anhand der Artikel Leute gezielt anzusprechen. Diese Seite hier dürfte dazu zu selten frequentiert werden und in Spezial:Recentchanges gibt es zu wenig PR mit dem Text „Systematische Diskussionen (Erörterungen)“ --Zahnstein 18:07, 18. Feb 2005 (CET)
Dass ich das noch erleben darf! ;o) Ich besessen von der Idee zu einem Thema die Argumentationslinien zusammen zu fassen. Allerdings ist Info-Hype wie gesagt erstmal nur blühende Phantasie ... nix dagegen, aber ich darf (als Philosophie und Linguistik Student) erfahren, dass das harte Arbeit bedeutet und so unendlich komplex ist; allerdings was bringt es, wenn man Prof. sein muss, um einen Artikel zu schreiben, dass wäre doch das beste, wenn das Diskurssystem, die gängigen Positionen darstellt und der Autor sich überlegen muss:" Welche Position vertrete ich, welche ARgumente führe ich an ...?" Aber ich fürchte, dass das ein Fass ohne Boden ist: Von welchen Vorraussetzungen gehe ich aus? Welche Weltsicht vertrete ich? Wenn es ganz schlecht läuft hat man so viele Positionen wie Diskussionsteilnehmer. Aber etwas mehr Struktur wäre schon machbar. Etwa mit dem IBIS Konzept, dass grob in Problem, Position, Argument einteilt, dann aber auch noch in konkret und abstrakt ... Vielleicht wäre der obige Vorschlag, die Diskussion zu einem Unterpunkt zu verbergern der beste, interessant wäre auch, wenn ... *seufz* wir können das ja hier mal testen: Das Problem sind die lauen, unübersichtlichen, verchinsischten, medial verramschten, sich über Jahrzehnte (!) im Kreise drehenden öffentlichen Debatten. Also das Subjekt der Begierde ist DIE DISKUSSION es gibt eine Spezifizierung öffentliche und die Charakterisierung durche die Aufzählung von Adjektiven, Partizipien, Adverbialen oje ... was wenn nun jemand in Bildern oder mit Engelszungen anfängt zu kommunizieren ??? tja, wie weiter???
141.58.115.197Stefahn
[Bearbeiten] Offene Datenbank
Hi, bin mir ja ziemlich sicher, dass Wikipedia eine offene Datenbank wie MySQL verwendet. Ich fände es toll, wenn sicherheits-unkritische Teile dieser Datenbank (also z.B. NICHT die Datenbank mit den Passwörtern) öffentlich zugänglich wären. Das man also z.B. das Recht hat, per SQL-Abfrage nachzuschauen, welche Benutzer einen Artikel bearbeitet haben. Es wäre nur lesender Zugriff notwendig. Mit den SQL-Abfragen könnten interessierte Benutzer eigene Statistiken erstellen (z.B. "welcher Benutzer auf der Wikipedia hat die meisten Diskussionsbeiträge beigesteuert?"). Die Informationen die man aus den Datenbanken ziehen kann, sind ja die gleichen, wie sie auch beim regulären http-Besuch der Wikipedia anfallen (ich könnte jetzt per Browser alle Disusssionsseiten abgrasen, und aufaddieren, wie viel Benutzer X diskutiert hat, aber das geht mit einem SQL-Query viel einfacher).
Dafür:
Dagegen:
- --BLueFiSH ?! 10:24, 23. Mär 2005 (CET)
- -- ma(c|d)dog 16:59, 24. Apr 2005 (CEST)
Kommentare: Sagt mir, was ihr davon haltet, und welche Bedenken ihr habt. Danke, --Abdull 10:00, 23. Mär 2005 (CET)
- Braucht eigentlich gar nicht drüber nachgedacht zu werden, Admins haben einen solchen Zugang. Was ein Benutzer anrichten kann, der böses will, dürfte auch klar sein. Zum Beispiel so große/viele Abfragen starten, dass die DB die Hufe hochreißt -> DOS. --BLueFiSH ?! 10:24, 23. Mär 2005 (CET)
- Das es das nciht gibt leigt nur an dem Problem der Serverlast (daher laufen auch manche automatischen Listen oder Statistiken so selten). Wen solche Sachen aber Glücklich machen der kann sich die vollständige Wikipedia runterladen und sich selbst seinen Wikipedia Server aufsetzen (mit PHP und Mysql) nud nach herzenslust Abfragen drüber laufen lassen. -- ma(c|d)dog
[Bearbeiten] Lautschrift
Meine Idee: Ich habe es nicht gelernt Wörter in der Wikipedia:Lautschrift (zum Beispiel: Becquerel [bɛkə'rɛl]) zu schreiben und auch lesen kann ich diese Schrift nicht, dennoch erkenne ich dessen Sinn.
Das Lesen, bzw. das Vorlesen kann man doch nun den Computer überlassen. Ähnlich wie der Geografische Lage (zum Beispiel: Berlin: 52° 31' 00" n. Br. 13° 23' 40" ö. L.), die nun recht gut funktioniert, könnte eine Vorlage auf ein Programm verweisen, dass die Lautschrift in eine wav-Datei konvertiert und im Browser abspielen kann. Ich weis leider nicht, ob es passende Software dazu gibt. Wenn aber die Brücke zur Ausgabe geschaffen wurde, lassen sich auch einige Benutzer dazu begeistern bei Fremdwörter oder Ortsbezeichnungen (ich denke an die Osteuropäischen) die Lautschrift hinzu zu fügen. --Atamari 13:39, 23. Mär 2005 (CET)
Dafür
- Atamari
- Heidas
- Stefan-Xp
- Wolfgang1018
- rdb?
- Avatar
- joni Δ (müsste aber schon einigermaßen schön anzuhören sein und der lautschrift tatsächlich voll entsprechen.)
- Jakov
- FWHS
- Träumer
- Parvati
- Ce
- Hey Teacher
Dagegen
Kommentare
Ich denke das wäre doppelte Arbeit seit es die Audiovorlage in Form von: anhören ?/i gibt. --devil Diskussion 11:53, 13. Jun 2005 (CEST)
- Der Vorteil liegt klar auf der Hand - es müssen nicht extra Audio-Dateien aufgenommen werden. --Avatar 11:39, 15. Jun 2005 (CEST)
- Mittlerweite gibt es über fünfhundert Lautschriften, siehe hier. Bald werden es über 200.000 Lautschriften sein... Benutzer:Devil_m25 fängt Morgen schon an die fehlenden Audiovorlagen zu besprechen.... ich hoffe er kann die ca. 100 Sprachen. --Atamari 18:58, 15. Jun 2005 (CEST) ;-)
Ist denn die Sprachsynthese tatsächlich schon in der Lage, Lautschrift widerzugeben? Ich denke, da müssen wir uns noch ein Weilchen gedulden. Hinzu kommt, dass die Forschung eher an der Aussprache von normal geschriebenem Text arbeitet als an der Aussprache von phonetischer Umschrift. -- j. 'mach' wust ˈtʰɔ̝ːk͡x 9. Jul 2005 06:05 (CEST)
Ich halte die gegenteilige These für wahrscheinlicher: Ich nehme an, dass die entwickler solcher software eher zuerst den Normalen text in Lautschrift umwandeln um diese dann wiedergeben zu können. Würde nämlich auch den Sprachübergreifenden Aspekt der Software unterstützen. Es ist sich er einfacher eine allgemeine Lautschrift in sprache umzusetzen als zig verschiedene "Normalschriften". -- Jakov 03:23, 11. Jul 2005 (CEST)
[Bearbeiten] Zusatzinformationen in der Versionen/Autoren-Liste
Meiner Meinung nach wäre es sinnvoll, zu jedem Eintrag in der Version/Autoren-Liste automatisch die Größe der vorherigen oder der neuen Version sowie den Umfang der Änderungen (jeweils in Bytes, z.B. in der Form "(3456/+78)" oder "(12345/-2)") hinzuzufügen and anzeigen zu lassen. Das würde zwar nicht in allen, aber in einigen Fällen helfen, Vandalismus schneller zu erkennen, z.B. auch auf der Seite mit den letzten Änderungen. Hilfreich wäre es dann, wenn jemand absichtlich eine falsche Beschreibung seiner Änderung angibt, um Vandalismus zu verschleiern. Also z.B. massiv Text löscht, diese Änderung aber mit "Informationen hinzugefügt" beschreibt. Auch eine Angabe wie z.B. "Typo korrigiert" (zusätzlich markiert mit "Nur Kleinigkeiten wurden verändert") liesse sich dann leichter als falsch erkennen, wenn statt einer zu erwartenden Änderung von wenigen Bytes (oder gar keiner Größenänderung) der Artikel massiv geschrumpft ist. Eventuell wäre es auch noch möglich/ sinvoll, Verkleinerungen und Vergrößerungen farblich unterschiedlich darzustellen, massive Änderungen (z.B. mehr als +/-50%) hervorzuheben (z.B. Fettdruck) und massive Änderungen auch auf einer speziellen Unterseite als automatisch generierte Liste anzuzeigen, die es dann ermöglicht, auf solche großen Änderungen schneller mal ein Auge zu werfen. Also analog der Liste "Letzte Änderungen" eine Liste "Letzte größere Änderungen". -- Uwe 04:33, 18. Mai 2005 (CEST)
- Klingt gut, wäre eine sinnvolle Ergänzung bei der IP-Patrol, zumal es ja sowas schon im RC Channel im Chat gibt. --finanzer 00:43, 21. Jun 2005 (CEST)
- Sowas wurde schonmal irgendwo vorgeschlagen, aber ich weiß leider nicht mehr wo und was damit passiert ist... Also erst mal eine pro-Stimme von mir... --Benutzer:Rdb? 07:32, 21. Jun 2005 (CEST)
Ich habs auf jeden Fall schon mal vorgeschlagen gab aber nicht viele Reaktionen. Also auf jeden Fall pro. Es hilft auch wenn man die längere Geschichte eines Artikels überpüfen will.--G 12:09, 23. Jun 2005 (CEST)
Ich bin auch dafür, am besten zwischen (Vorherige) und den Auswahlknöpfen in jeweils eine eigene Spalte. - FWHS 15:00, 1. Aug 2005 (CEST)
Klingt sinnvoll, es gibt auch bereits eine ähnliche Anfrage in Bugzilla:1723 --X4u 21:49, 5. Sep 2005 (CEST)
- Wenn ich nicht irre, gehört das in die obige Kategorie --JohannesPonader 05:59, 29. Apr 2006 (CEST)
[Bearbeiten] gelbes Fähnchen
Wenn man den Mauscursor über einen Wikilinks verweilen lässt, erscheinen diese gelben Fähnchen (IE6) mit dem Wikilink (z. B. "Hauptseite" oder "Benutzer:Dummy"). Meine Idee ist es nun wenn der Link zu einer Begriffsklärung verweist, könnte dieses im gelben Fähnchen mit erwähnt werden. Vielleicht kann das im Interpeter der Wikisprache mit integriert werden? Dadurch würde das Überprüfen - ob die wikilinks (noch) richtig gesetzt sind und nicht zu einer BKL verweisen vereinfachen. --Atamari 22:17, 14. Jun 2005 (CEST)
- Unter "Einstellungen>Letzte Änderungen und Anzeige kurzer Artikel>Kurze Artikel markieren bis" kannst du eine Größe angeben, bis zu der Artikel per Linkfarbe hervorgehoben werden. Damit sollte man die meisten BKLs erschlagen können. --::Slomox:: >< 04:10, 11. Jul 2005 (CEST)
[Bearbeiten] Textbaustein, der auf von Fachleuten gegengelesene und "freigegebene" Version hinweist
Werte Mitautoren,
Ihr habt sicher den ein oder anderen Artikel der Presse gefunden, wo die Glaubwürdigkeit von Wikipedia mit der von anderen Lexika verglichen wird. Als in der Forschung tätiger Akademiker finde ich dass das Argument, dass ein Artikel von fachlicher Seite her durchaus fragwürdig bzw. meinungsgerichtet sein könnte, durchaus durchaus nicht einfach von der Hand zu weisen ist.
Mein Vorschlag: in von 2-3 Autoren "vom Fach" beurteilten Artikeln einen Textbaustein einbauen, der auf die letzte von den Fachautoren freigegebene Version hinweist. Eine Freigabe könnte z.B. nach Erfüllung folgender Kriterien erfolgen:
- Fachlich richtig, nicht parteiergreifend
- Zitate sind als solche gekennzeichnet und die entsprechenden Literaturverweise sind vorhanden und auf dem aktuellsten Stand
- Sämtliche Inhalte ist mit der Wikipedia-Rechtepolitik konform, keine Plagiat-Abschnitte, etc.
- Auf die Begutachter wird verwiesen, ihr wissenschaftlicher Hintergrund wird auf ihren Benutzer-Seiten beschrieben und von anderen Kollegen bestätigt.
- Der Artikel ist fehlerfrei, durchgängig gut formuliert und dem Kontext entsprechend verlinkt
So long --Tobias ✉ 23:59, 14. Okt 2005 (CEST)
- Nette Idee.
- Vielleicht sollte getrennt werden zwischen wissenschaftlich korrekt und formal + im Aufbau korrekt.
- Wie wird die Versionskontrolle behandelt? Wer beobachtet die Artikel, wenn unsere witzigen Mitmenschen Gleichungen um den Faktor 2 erweitern?
- Die Idee ist, dass der Textbaustein auf die letzte durchgesehene Version hinweist. Wir können also bei Version x+n sein, Version x ist aber die Referenzversion. Wenn es größere Änderungen gibt, könnte ja eine neue Referenzversion freigegeben werden. --Tobias ✉ 12:01, 16. Okt 2005 (CEST)
- Werden Mitarbeiter informiert, wenn der Textbaustein mit Verweis auf ihren Namen verwandt wird?
- Na ja, wenn einige Autoren einen Artikel gemeinsam durchsehen, dann nehme ich 'mal stark an, dass sie mit Ihrem Namen im Textbaustein einverstanden sein werden. --Tobias ✉ 12:01, 16. Okt 2005 (CEST)
- Dantor 15:42, 15. Okt 2005 (CEST)
Dafür:
- --Tobias ✉ 23:59, 14. Okt 2005 (CEST)
Dagegen (oder hat vielleicht einen besseren Vorschlag zum Thema):
[Bearbeiten] 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
[Bearbeiten] Quellenangaben
[Bearbeiten] Quellenangaben: äußere Form, Schriftsatz
[Bearbeiten] 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:
-
- Das Problem ist im Opera am größten
- Im IE ist das Problem bemerkbar
- 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. 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.----
- 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::
- Für Variante 4: Wie alte Vorlage:Ref (Nachtrag):
-
- --Franz (Fg68at) 23:31, 2. Jun 2006 (CEST)
- Wolfgang Kopp
[Bearbeiten] 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)
- 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)
- 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 nochol,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)
- 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)
- "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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] Löschwarnung
Problem: Vandalismusartikel und der {{löschen}}-Baustein
Kommt ja dann und wann mal vor daß man einen Artikel bearbeitet, der von einem Admin gerade gelöscht wird. Bei paralleler Bearbeitung käme da ja diese Bearbeitungskonflikt-Warnung; wäre so etwas auch bei gerade gelöschten Artikeln möglich? Vieleicht x Minuten nach Löschung "Warnung: Dieser Artikel wurde gerade gelöscht. Bitte schau ins [[Spezial:Log/delete?page=$titel|Löschlogbuch]] ... blabla...", dann spart man den Admins des erneute Löschen vom Artikel (und macht sich selber nich ganz so oft zum Troll des Tages ;o)). --Ratatosk ✍ 11:20, 20. Jun 2005 (CEST)
- Fände ich gut, sollte damit verbunden werden, dass Löschungen und Verschiebungen in der Versionsliste wie Bearbeitungen angezeigt werden. - FWHS 15:03, 1. Aug 2005 (CEST)
- eins geht bereits: wenn ein artikel gelöscht wurde nachdem man den edit-button geklickt hat, bekommt man eine warnung. -- ∂ 07:56, 13. Nov 2005 (CET)
[Bearbeiten] Lemmata auch in Kleinschreibung
Problem: Lemmata müssen mit einem Großbuchstaben beginnen. Ein Grund dafür ist nicht ersichtlich, sieht man von Sachen wie en:Foo ab (könnte man auch mit Test auf ":" erschlagen). Beim Rest der Lemmata dagegen wird peinlich genau auf Groß/Kleinschreibung geachtet (was zu jeder Menge überflüssiger Redirect-Lemmata führt). Ist jetzt unsachlich, aber hier entsteht etwa folgender Eindruck: anstatt ihre Software zu reparieren, legen sie noch extra eine Liste kaputter Artikel an. --Miez 10:52, 25. Jun 2005 (CEST)
- Die Software kann das schon lange, die Option ist absichtlich nicht aktiviert, da fast alle Einträge groß geschrieben werden sollen und vor allem wohl auch, weil das Verlinken im Englischen so einfacher ist (weil sich der Wortstamm dort selten ändert). Eine Lösung, bestimmte Artikel klein darzustellen ist erwünscht (wollen auch die Entwickler), bisher aber aus Zeit/Dringlichkeitsgründen nicht umgesetzt. Wenn es jemand programmiert, wird es eingesetzt. --APPER\☺☹ 23:30, 29. Jul 2005 (CEST)
-
- Ist das nun für diese Seite erledigt, weil die Entwickler daran arbeiten, oder muss da noch ein Meinungsbild dazu? FWHS 15:03, 22. Aug 2005 (CEST)
[Bearbeiten] Seit Ihrem letzten Login haben Benutzer folgende Artikel vandaliert
... oder auch "folgende wertvolle Beiträge geliefert". Ähnlich Contributions, aber nur geänderte Artikel; die mir empfohlene Watchlist tut auch nicht. Idealerweise sollten wie bei Google Auszüge des Diffs gleich danebenstehen. --Miez 10:52, 25. Jun 2005 (CEST)
- Watchlist, alle anzeigen, alle geänderten Artikel automatisch auf WL funktioniert zwar nicht wie bei Google, aber einigermaßen. Niedrige Dringlichkeit --Miez 8. Jul 2005 20:43 (CEST)
[Bearbeiten] Fußnoten
Dringend gebraucht für weitergehende Information, Quellen usf. (nein, Lemma#Anchor gilt nicht). Hier könnte auch das Popup-Feature des Klickibunti-Web mal sinnvolle Anwendung finden. Bis jetzt behelfe ich mir gelegentlich mit small und kursiv. --Miez 10:52, 25. Jun 2005 (CEST)
Dem kann ich nur zustimmen: Ich würde v.a. bei längeren Artikel gerne Links im Text auf Fußnoten einfügen, die nicht selbst Links sind, sondern schlicht weiteren Text enthalten. -- Christian Körner 7. Jul 2005 22:32 (CEST)
Die Fußnoten wären am Ende der Seite weit weg von dem Ort, wozu sie inhaltlich gehören. Dazu wäre ein Link gut, der beim draufklicken an seiner Stelle den Text einfügt und beim Klicken auf den Text wieder zu einem kurzen und kleinen Link wird. Also etwa so:
Text! <--Klick--> Text Fußnote!
Allerdings musste ich hier den Wikilink missbrauchen, damit die Darstellung stimmt, aber die Software könnte da dann einen normalen Link auch in einer anderen Farbe darstellen, der das entsprechende Skript aufruft. Praktisch wäre auch die Möglichkeit, alle Fußnoten auf einmal ausklappen und einklappen zu können. Das geht glaube alles ich mit JavaScript, ich weiß nur gerade nciht wie. Das Verfahren wird aber in der Wikipedia schon verwendet, nämlich bei den Pfeilen auf Spezial:Recentchangeslinked, so dass möglicherweise die Admins das einbauen könnten. - FWHS 15:27, 1. Aug 2005 (CEST)
[Bearbeiten] Synonymliste beim Anlegen abfragen
Habe diverse Redirects angelegt -- dergleichen sollte beim Anlegen eines neuen Artikels mit abgefragt werden. Oder ganz luxuriös automatisch: etwa so: "Der [[*KC 87]] war ..." wobei sofort ein Redirect von KC 87 auf diesen Artikel angelegt wird, falls noch kein separater KC 87-Artikel existiert. --Miez 10:52, 25. Jun 2005 (CEST)
- Ich verstehe noch nicht, was du möchtest, was meinst du damit? - FWHS 15:30, 1. Aug 2005 (CEST)
[Bearbeiten] Entwurfsnotizen
Notizen im Text, die Hinweise für andere Benutzer geben; abschaltbar. Bis jetzt mit kursivem TBD: ... beholfen. Ein Traum wäre es, wenn Diskussionsseiten in den Artikel integriert (abschaltbar) werden könnten - immer zwei Pages begucken kann nerven, Diskussionsseiten können sehr länglich werden (nicht ortsnah) --Miez 10:52, 25. Jun 2005 (CEST)
- Diskussionsseite (optional) in den Artikel eingebaut wäre super! Sieh dir mal Joni2s Idee (absatz "sektion hinzufügen nicht nur für die ganze seite") an. Ich habe mir gedacht, dass man via [?] Diskussionen zu den Absätzen erstellt (dh. die Struktur des Artikel wird übernommen.) die dann, wenn möglich direkt einzublenden sind. -- Jakov 17:07, 17. Jul 2005 (CEST)
-
- Das ließe sich vll auch mit den Fußnoten (s.o.) verbinden, also so, dass die Diskussion wie eine Fußnote mit eingebaut wird und auch die Strukturen innerhalb der Diskussion klappbar sind. - FWHS 15:35, 1. Aug 2005 (CEST)
Also das beschäftigt mich auch; wenn ich auch noch nicht so die Wiki-Erfahrung habe, frage ich mich, wie man die verschiedenen Standpunkte gleichwertig behandeln könnte, falls derartiges überhaupt wünschenswert ist (soll jede blöde Meinung verhanden sein? WEr entscheidet was blöd ist? Die Mehrheit?) Naja, also als staubtrockener Theorie-Fan träume ich von MetaTags, etwa <Problem>, <Definition>, <Position>, <Begründung>, <Beispiel> die den Text (und das Denken?) strukturieren helfen täten ... **träum weiter ** ;o)
141.58.115.197Stefahn
[Bearbeiten] foo (bar)
Diesen Link als "foo" zeigen. --Miez 8. Jul 2005 20:45 (CEST)
-
- Beispiel: [[Wilhelm (Deutsches Reich)]] als "Wilhelm" anzeigen, aber korrekt linken. --Miez 8. Jul 2005 21:53 (CEST)
-
-
- du sparst aber stark an erklärung. ich bin mir nicht sicher, ob du das meinst, denn das wäre ja zu einfach; aber könnte es folgendes sein: du willst auf den artikel „Wilhelm (Deutsches Reich)“ verlinken, jedoch nur „Wilhelm“ anzeigen? das geht doch schon ganz einfach mit
[[Wilhelm (Deutsches Reich)|Wilhelm]]
und sieht dann so aus: Wilhelm. mfg --joni Δ 8. Jul 2005 23:00 (CEST)
- du sparst aber stark an erklärung. ich bin mir nicht sicher, ob du das meinst, denn das wäre ja zu einfach; aber könnte es folgendes sein: du willst auf den artikel „Wilhelm (Deutsches Reich)“ verlinken, jedoch nur „Wilhelm“ anzeigen? das geht doch schon ganz einfach mit
-
-
-
-
- Klar. Die Idee ist, standardmäßig das in Klammern wegzulassen, weil es sich meistens um Disambiguation handelt. --Miez 9. Jul 2005 07:49 (CEST)
-
-
-
-
-
-
-
- Aus meiner Sicht ist das bereits erledigt: Aus
[[Wilhelm (Deutsches Reich)|]]
d.h. nur mit der "bar" dahinter wird Wilhelm -- Jakov 03:03, 11. Jul 2005 (CEST)
- Aus meiner Sicht ist das bereits erledigt: Aus
-
-
-
-
[Bearbeiten] http:// automatisch anfügen bzw verstecken
Bin über die ISBN-Suche gestolpert und habe dort gesehen, dass unabsichtlich jemand WikiLinks satt WebLinks verwendet hat. (ca so: buecher.de) Damit diese Links anschaulich zu weblinks werden muss aber mehr getan werden als die überflüssigen eckigen klammern außen zu entfernen (so: [buecher.de]). Man muss (derzeit) um schöne links zu erhalten das zeug mt dem http:// bzw http://www. außschreiben:
[http://www.buecher.de buecher.de]
ich fände eine vereinfachung dieser art praktisch: [buecher.de]
müsste reichen da ein script das http://www.
für die verlinkung vorne anfügen könnte.
Umgekehrt wäre es praktisch - ähnlich wie bei Wilhelm durch ein einzelnes (bzw zwei) zeichen das http://www.
bzw auch den link nach der domain wegzulassen. Das sähe dann so aus: [http://de.wikipedia.org/wiki/Hauptseite %%]
= de.wikipedia.org; (angenommen das %-zeichen wäre dieser Schalter; ich weiß leider aber nicht welche zeichen in der adressleiste alle vorkommen können, dh nicht als schalter dienen können...)
--Jakov 13:39, 14. Jul 2005
- „www“ auch automatisch anzuhängen, halte ich für ungünstig, da mir schon einmal eine url untergekommen ist, die nur mit „http://urlname.de/“ und nicht mit „http://www.urlname.de/“ zu erreichen war. mfg --joni Δ 00:15, 16. Jul 2005 (CEST)
-
- Außerdem ist hier das "buecher.de" die Beschreibung des Links. wenn die Seite anders als der Link heißt funktioniert das überhaupt nicht. Aber vielleicht könnte man die Syntax für Links vereinheitlichen. Das also für Links immer [[Linkziel|Beschreibung]] gilt, egal ob jetzt [[LinkzielWikipediaIntern|Beschreibung]] oder [[http://Linkziel.de|Beschreibung]]. --Habakuk <>< 14:29, 16. Jul 2005 (CEST)
-
-
- Joni2, du hast recht. Dummerweise gibt es umgekehrt auch seiten, die ohne www. nicht funktionieren. Vielleicht könnte man das "www" aber auch einfach im nachhinein verstecken (weil unschön), wäre aber nicht mehr so wichtig. Oberes bezieht sich ergo nur noch auf das "http://".
- Im moment habe ich kein Problem damit, dass bei externen Links nur ein statt zwei "[" verwendet wird, das kann meinetwegen so bleiben.
- Um es nochmal zu verdeutlichen:
[http://de.wikipedia.org/wiki/Hauptseite]
-->[de.wikipedia.org/wiki/Hauptseite]
. Man soll sich das Schreiben und anzeigen des "http://" sparen.[de.wikipedia.org/wiki/Hauptseite %]
--> de.wikipedia.org. Weiters würde ich einen Schalter begrüßen, der die unterordner versteckt. Hiervon könnte zb der Ballontipp ausgenommen sein.[http://de.wikipedia.org/wiki/Hauptseite Hauptseite der WIKIPEDIA]
-->[http://de.wikipedia.org/wiki/Hauptseite|Hauptseite der WIKIPEDIA]
. Natürlich wäre es auch besser, wenn auch bei externen Links der bar "|" verwendet werden könnte (siehe kommentar v. Habakuk). Ich weiß leider nicht ob das möglich ist.
- -- Jakov 16:18, 17. Jul 2005 (CEST)
-
-
-
-
- auf „|“ umzusteigen, ist wohl viel zu spät – so viel, wie die jetzige form verwendet wird. aber möglicherweise wäre folgendes eine Überlegung wert:
[http://de.wikipedia.org/wiki/Hauptseite Hauptseite der Wikipedia]
ergibt: Hauptseite der Wikipedia[http://de.wikipedia.org/wiki/Hauptseite|%1]
ergibt die url ohne protokoll: de.wikipedia.org/wiki/Hauptseite[http://de.wikipedia.org/wiki/Hauptseite|%2]
ergibt nur den server: de.wikipedia.org
- „%“ hat dabei den sinn von „nur teilweise Anzeige“; und die ziffer steht für „kürzung des grades x“.
- mfg --joni Δ 21:05, 17. Jul 2005 (CEST)
- auf „|“ umzusteigen, ist wohl viel zu spät – so viel, wie die jetzige form verwendet wird. aber möglicherweise wäre folgendes eine Überlegung wert:
-
-
Genau, Man sollte:
- optional (über den Quellcode, also einem Schalt-zeichen) NUR den Server annzeigen.
- Das Protokoll ausblenden können: Ein häckchen in den User-preferences könnte genügen um bei allen links das Protokoll auszublenden. (Ich denke nicht, dass das zu aufwändig wäre.) Ein weiterer Schalter im Quellcode wäre dann nicht mehr nötig.
- Im Quellcode das Protokoll weglassen können, sodass Mediawiki automatisch "http://" (den Standard) annimmt. Über die User-Prferences könnte der dann wieder ausgeblendet werden.
- Einheitlich „|“ für WikiLinks als auch externe Links verwenden (übergangsweise können). Die technische umsetzbarkeit ist mir jedoch noch nicht klar - ich fürchte, dass „|“ ein für die URL zulässiges zeichen ist und deshalb nicht als schalter verwendet werden kann.
-- Jakov 18:08, 18. Jul 2005 (CEST)
- nein, „|“ wird in „%7C“ umgewandelt. beispiel: „
[http://www.beispiel.de/index.php?bartest=%7C|%]
“. mfg --joni Δ 18:28, 18. Jul 2005 (CEST)
[Bearbeiten] Externe Links besser handhaben
Mittlerweile beginnt die Wissenssuche im Internet entweder bei Google oder bei der Wikipedia. Um Informationen im Internet aufzufinden gibt es Suchmaschinen und Webkataloge. Die Wikipedia ist erste Anlaufstelle wenn es um die Begriffsklärung geht und sollte daher Verweise auf externe Internetseiten besser handhaben können. Dazu habe ich folgende Verbesserungsvorschläge, die im Sinne der kollektiven Erarbeitung einer Online Enzyklopädie sind:
[Bearbeiten] Visuelle Linkauszeichnung
Die Artikel der Wikipedia könnten mit grafischen Auszeichnungen externe Links auf einen Blick besser strukturieren und ihren Nutzen stark vergrößern. Mit einer dezenten Grafik vor dem Link könnte deutlich gemacht werden, ob es sich um eine "normale" Seite, ein Wissenschaftliches Papier, ein Wiki, ein Forum, ein Blog, eine Newsseite, ein FAQ, ... handelt. Die inhaltliche Relevanz zum Wikipediartikel könnte mit einer Bewertung (3/10 oder Sterne hinter dem Link) ausgedrückt werden. Ein Leser könnte dann besser einschätzen was hinter den Links steckt. Sicherlich lässt sich das alles auch manuell mit Textauszeichnungen lösen, aber optisch ansprechender wäre eine Visualisierung durch das Mediawiki.
- Könnte man das nicht auch durch Formatvorlagen erreichen, die eine entsprechende Grafik einbinden? Also z.B.
{{FAQ|http://xy.de/faq.html}}
,{{Blog|http://ein.blog.de/}}
oder{{Paper|http://de.arxiv.org/xy}}
.
[Bearbeiten] Linkbereich für Seiten
Für die weiteren Vorschläge wäre es hilfreich, wenn in einem Artikel die Stelle ausgezeichnet werden könnte an der externe Links angegeben werden. Ein solcher Bereich könnte mehrere Male auf einer Seite angegeben werden, um die Links inhaltlich zu Gruppieren (pro / kontra oder unterschiedliche Themengebiete). Die grafische Auszeichnung sollte sich auf den Typ beschränken.
[Bearbeiten] Browserplugin zum hinzufügen und Löschen von Links
Ein Browserplugin, das Links mit einem Knopfdruck zu einem (durch ein Eingabefeld angegebenen) Wikipediartikel hinzufügt, wenn er einen ausgezeichneten Linkbereich hat. Wer gerade eine Internetseite entdeckt hat, die er für erwähnenswert in der Wikipedia hält könnte den passenden Artikel eingeben, den Typ bestimmen (Forum, Blog, etc.), die Relevanz und Linkgruppe einstellen, und mit einem Klick den Link in den Artikel einfügen. Das Plugin versucht dann die entsprechende Stelle zu finden und den Link dann dort einzufügen (evtl. nach relevanz sortiert) und bietet im Fehlerfall an die Bearbeiten Seite des Artikels zu öffnen. Umgekehrt sollte es mit dem Plugin möglich sein Links wieder zu entfernen / zu ändern, wenn man grade von einem Wikipediaartikel gekommen ist (das Plugin erkennt den klick auf einen externen link und übernimmt ihn). Hat die externe Seite keinen Bezug mehr zum Artikel hat den Benutzer die möglichkeit den link mit einem Klick wieder zu entfernen.
[Bearbeiten] Ausblenden Externer Links bei Bedarf
Sollte die Anzahl der Externen Links zu groß werden (z.B. mehr als 7, was auch die Obergrenze für Punkte auf einer Vortragsfolie ist) sollte automatisch ein "Weitere Externe Links" erscheinen, über das man diese erreichen kann... (oder einfach nur ausklappen)
- Ich würde die Anzahl sogar auf 5 beschränken. Eigentlich sollte das auch eher eine Stilvorgabe für gute Artikel sein, aber zum einen gibt es begründete Ausnahmen, zum anderen sind Stilvorgaben selten konsequent durchgesetzt. Da finde ich so eine technische Beschränkung (vor allem das einfache ausklappen) eine gute Idee.--Dr. Schorsch 10:42, 26. Jul 2005 (CEST)
- dafür: Dr. Schorsch, FWHS (bei Bedarf mehr einblenden zu können wäre besser)
- dagegen: Schlurcher ???, :Bdk:, Staro1
[Bearbeiten] Kommentare:
Wikipedia als Webkatalog?
Ich denke nicht, das die Wikipedia dadurch zu einem Webkatalog mutiert, da jeder die Links auch wieder einfach löschen kann. Selbst wenn kann die Wikipedia davon nur profitieren, denn von den vielen Besuchern werden einige wieder zu Autoren. Ich sehe zwar die steigenden Anfragen an die Server, die mit einem Plugin einhergehen, aber halte es für wichtig, um die Wikipedia als Informationsquelle zu verbessern. Wenn dann allerdings jemand ein Browserplugin schreibt, was die Externen Links zu einem Wikipediaartikel raussucht könnte das allerdings unser Tod sein ;) Aber das bleibt abzuwarten. Jörn Dreyer 22:51, 15. Jul 2005 (CEST)
Wenn ich das richtig verstanden habe soll man Links zu wertvollen seiten einfacher einarbeiten können. Für mich bliebe allerdings wichtig, dass nicht hirnlos hinzugfügt wird: d.h, wenn, dann sollten diese Links (über ein browserplugin??? (wie wärs mit sidebar?)) in die diskussionsseite eingefügt werden und dann die dort zu findenden resourcen verarbeitet/evtl in den artikel eingebaut werden. Erst dannach sollte ein link an eine seite angeheftet werden. Ich glaube der Wert der wikipedia liegt in der individuellen auseinandersetzung mit den Themen.
Den vorschlag zum Rating und Kategorisierung der externen links finde ich gut. -- Jakov 16:29, 17. Jul 2005 (CEST)
- Zu viele Weblinks sind ein Grund, auszumisten, nicht auszublenden. Die optische gesonderte Auszeichnung von Weblinks ist m.E. völlig zu Recht den Wikimediaprojekten vorbehalten. Denn eine wie auch immer geartete Klassifizierung und damit (bevormundende) Bewertung externer Links ist zutiefst unenzyklopädisch und daher bislang auch immer abgelehnt worden. Entweder ist ein Link sinnvoll oder er ist es nicht, im zweiten Fall hat er hier nichts zu suchen. Textliche Hinweise, d.h. konkretere Beschreibungen, die über die URL hinausgehen, sind eh möglich und üblich. Ich sehe da einfach keinen Bedarf. --:Bdk: 19:55, 19. Okt 2005 (CEST)
[Bearbeiten] Vorschau ganze Seite (Button)
Wer in Artikeln einen Absatz bearbeitet müsste die Seite unnötig speichern, um den bearbeiteten Teil im Kontext anzusehen. Vielleicht wäre es also sinnvoll (zusätzlich zu "Seite speichern", "Vorschau", und "Änderungen") einen "Vorschau (der ganzen Seite) zeigen"-button einzubauen. -- Jakov 16:59, 17. Jul 2005 (CEST)
- braucht man denn so etwas tatsächlich? wann will man denn schon mal einen absatz im kontext der gesamtseite ansehen? --joni Δ 20:46, 17. Jul 2005 (CEST)
-
- Bei einem kurzen Abschnitt mit einem Bild das höher ist als der Abschnitt beinflusst das auch den Umbruch der nachfolgenden Abschnitte und Bilder aus dem vorangegangenen Abschnitt tun das genauso mit dem bearbeiteten. Daher halte ich das auch für sinnvoll. --Dr. Schorsch 14:06, 28. Jul 2005 (CEST)
- ist ein uter Vorschlag, dann sieht man auch Ergänzungen, die vielleicht sowieso in einem anderen Absatz stehen, man kennt ja den Artikel nicht wirklich auswendig --K@rl 09:42, 30. Jul 2005 (CEST)
- Es gibt auch Bausteine, die, auch wenn sie nur in einem Absatz stehen, die Gesamtseite beeinträchtigen. Funktion wäre hilfreich.StefanL 01:17, 31. Jul 2005 (CEST)
- Bei einem kurzen Abschnitt mit einem Bild das höher ist als der Abschnitt beinflusst das auch den Umbruch der nachfolgenden Abschnitte und Bilder aus dem vorangegangenen Abschnitt tun das genauso mit dem bearbeiteten. Daher halte ich das auch für sinnvoll. --Dr. Schorsch 14:06, 28. Jul 2005 (CEST)
-
- Ja, braucht man. Beispiel: Ich habe im Artikel Åland in einem Abschnitt eine Tabelle auf float:right umgestellt und erst nach dem Speichern festgestellt, dass die Tabelle in den nächsten Abschnitt reinragt, was mir aber überhaupt nicht gefällt, darum musste ich den Abschnitt nochmals bearbeiten um das zu beheben.
--the one who was addicted (#) 13:25, 23. Aug 2005 (CEST)
- Ja, braucht man. Beispiel: Ich habe im Artikel Åland in einem Abschnitt eine Tabelle auf float:right umgestellt und erst nach dem Speichern festgestellt, dass die Tabelle in den nächsten Abschnitt reinragt, was mir aber überhaupt nicht gefällt, darum musste ich den Abschnitt nochmals bearbeiten um das zu beheben.
-
-
- Zweifelsohne sinnvoll, u.a für Tabellen, Bilder, Leerzeilen, usw. -- Ολλίμίνατορέ •Ω• 15:13, 7. Apr 2006 (CEST)
-
- Einzelnachweise (und
<references />
) sind mMn wieder ein Grund diesem Vorschlag Aufmerksamkeit zu schenken. --the one who was addicted (#) 20:02, 21. Jan. 2007 (CET)
- dafür: Jakov, Dr. Schorsch, K@rl, StefanL, FWHS, the one who was addicted (#), Tolanor (Diskussion), Ολλίμίνατορέ •Ω•, Staro1, Löschfix 02:02, 24. Aug 2006 (CEST) Aber es könnte dafür auch nur ein Shortcut eigesetzt werden, z.B, STRG-Klick auf Vorschau.--Löschfix 02:02, 24. Aug 2006 (CEST)
- dagegen:
[Bearbeiten] Bemerkung in revert
Es wäre günstig, wenn man auch beim revert eine Bemerkung angeben könnte und nicht nur die automatische von ...revert auf Version von ... ohne unbedingt in der Diskussion etwas hineinschreiben zu müssen --K@rl 09:42, 30. Jul 2005 (CEST)
- ich verstehe nicht richtig, was du meinst. willst du wie fürs verschieben eine extrafunktion zum reverten, wo man dann eine zusammenfassung geben kann? --joni Δ 20:46, 31. Jul 2005 (CEST)
- richtig, damit man in den revertgrund hineinschreiben kann, sodass in der Beobahctungsliste nicht nur reverted von nach steht. das kann Vandalismus aber auch eine falsche Information sein oder was auch immer, einerseits wäre es höflicher gegenüber dem vorherigen Benutzer, andererseits ein Hinweis für andere die auch einen Vandalen beobachten. --K@rl 17:56, 7. Aug 2005 (CEST)
- Damit würde das Reverten eines Artikels doppelt so lange dauern. --Silberchen ••• 11:02, 28. Apr 2006 (CEST)
- Das wäre aber sehr zu begrüssen, denn es wird sowieso viel zu leichtfertig revertiert. Imho nur für Vandalen statthaft, ansonsten sollte editiert, statt revertiert werden.--Löschfix 02:05, 24. Aug 2006 (CEST)
- Damit würde das Reverten eines Artikels doppelt so lange dauern. --Silberchen ••• 11:02, 28. Apr 2006 (CEST)
- richtig, damit man in den revertgrund hineinschreiben kann, sodass in der Beobahctungsliste nicht nur reverted von nach steht. das kann Vandalismus aber auch eine falsche Information sein oder was auch immer, einerseits wäre es höflicher gegenüber dem vorherigen Benutzer, andererseits ein Hinweis für andere die auch einen Vandalen beobachten. --K@rl 17:56, 7. Aug 2005 (CEST)
- dafür: K@rl, FWHS, joni (Δisκussion)
- dagegen: Silberchen
[Bearbeiten] Redirects auf Abschnitte umleiten
Mir ist bekannt, das die Realisierung eines Redirects auf Abschitte problematisch sein soll. Wenn ich bisherige Diskussionen richtig interpretiere, muß sich das nicht unbedigt auch auf die hier Vorgeschlagene Variante beziehen: Der Redirect selbst soll ein ganz normaler Redirect werden. Stattdessen soll der Zielartikel einen Eintrag erhalten, das Redirects von einem bestimmten Lemma auf einen bestimmten Abschnitt im Artikel umgeleitet werden. Bzw. im Zielartikel könnte an der betreffenden Zielposition eine Zielmarkierung für den Redirekt vorhanden sein. Es hätte zudem den Vorteil, dass diese Variante bei der Bearbeitung des Zielartikels unproblematischer ist. Wäre das in dieser Form realisierbar?-- StefanL 01:03, 31. Jul 2005 (CEST)
- Ganz praktisch fände ich einen Anker im Zielartikel. Um Verwechslungen zu vermeiden, sollte dieser den Namen des Redirects tragen. Beispiel: Artikel A enthält an einer Stelle
<a name="B"></a>
Artikel B enthält nur#REDIRECT [A#B]
. Statt<a name="B"></a>
könnten dann solche Zeichen wie eckige Klammern für Links oder geschweifte für Vorlagen das B umfassen. Möglicherweise lässt sich das auch ohne Softwareänderung mit Vorlagen umsetzen:{{anker|B}}
oder kurz{{a|B}}
, wobei ich leider nciht weiß, ob<a name="{{{1}}}"></a>
in der Vorlage vernünftig interpretiert würde. - FWHS 16:07, 1. Aug 2005 (CEST)- Redirects auf Kapitel können von Fall zu Fall sehr sinnvoll sein. Die bisherige Argumentation, dass sich die Kapitel-Namen im Ziel-Artikel ja ändern könnten kann ich nicht wirklich nachvollziehen, denn dann kommt man halt am Anfang des Artikels raus, was ja ohne diese Möglichkeit sowieso der Fall ist. Als Vergleich eine Argumentation "aus dem wirklichen Leben": Ich fahre nie mit meinem Auto, sondern gehe immer zu Fuß, weil es ja sein kann, dass der Motor nicht anspringt, und dann müsste ich zu Fuß gehen, und das dauert mir zu lang. Den gleichen logischen Knick sehe ich in der Argumentation gegen Redirects auf Kapitel --JuTa Talk 18:46, 2. Aug 2006 (CEST)
[Bearbeiten] Explizit benanntes Linkziel in Artikel (erledigt, Funktion ist vorhanden)
Die Verlinkung von Abschitten eines Artikels ist ja schon möglich. Dies ist aber nicht unproblematisch, da sich die Abschnittsüberschriften ändern können. Das Problem ist vor allem, dass im Zielartikel nicht erkennbar ist, das auf einen Abschnitt verlinkt ist. Daher schlage ich benannte Zielmarkierungen vor, die in den Zielartikel eingebaut werden können. Bei der Verlinkung wird dann statt des Abschnittsnamens der Name des Zielartikels eingefügt. Damit wäre auch eine Verlinkung z.B. von Tabellen im Zielartikel ohne eigene Abschnittsüberschrift machbar.-- StefanL 01:35, 31. Jul 2005 (CEST)
- Bei der Suche in der englischen Hilfe habe ich festgestellt, dass diese Funktion schon vorhanden ist, nur in der deutschen Beschreibung leider nicht dokumentiert ist.-- StefanL 15:02, 28. Aug 2005 (CEST)
- dafür: StefanL, FWHS (siehe "Redirects auf Abschnitte umleiten"), Timo Müller
- dagegen:
[Bearbeiten] Verlinkung auf Abschnitt am Artikelende
Wenn der Abstand zwischen verlinkter Abschnittsüberschrift und Artikelende kleiner als die dargestellte Seitenhöhe ist, sollte die Darstellung dennoch so sein, dass sich die Abschnittsüberschrift am oberen dargestellten Seitenrand befindet (ggf. Artikel künstlich mit Leerraum verlängern). Damit kann der Benutzer dann das wirkliche Linkziel korrekt erkennen.-- StefanL 01:35, 31. Jul 2005 (CEST)
- Ein Minimum an Erkennungsfähigkeit des menschlichen Geistes (im Bezug zur künstlichen Funktion) sollte noch zumutbar sein (und wenn wäre es auch eher eine Browser-tech. Frage).
- dafür: StefanL, FWHS
- dagegen: Ολλίμίνατορέ •Ω•
[Bearbeiten] Angezeigte Bezeichnung in Kategorie
Bei der Kategoriesierung ist es bereits möglich, eine alternative Bezeichnung für die Sortierung anzugeben. Es wäre gut, wenn man die angezeigte Bezeichung in ähnlicher Weise optional vorgeben könnte. Bevorzugt wäre, wenn damit auch Doppeleinträge in einer Kategorie möglich wären. Aber auch ohne diese Doppeleinträge wäre die Funktion schon hilfreich.StefanL 01:49, 31. Jul 2005 (CEST)
- wurde früher auch schon vorgeschlagen, leider keine Reaktion. --K@rl 13:10, 22. Aug 2005 (CEST)
- Nachfrage: Wo ist der Sinn doppelter Einträgen eines Artikels in einer Kategorie? Meinst Du sowas, wie [Hamburg-Fuhlsbüttel] in einer Kategorie einmal unter H und gleichzeitig einmal unter F abzulegen? Problem wäre dabei m.E., dass die absolute Zahl der Kategorieeinträge neu berechnet und nachvollziehbar angezeigt werden müsste. Und kann jemand mal anschauliche Beispiele für den wirklichen Bedarf dieser Optionen geben? Meinst Du mit "angezeigter Bezeichnung" das, was in der Artikelseite oder aber lesbar in der Kategorie selbst erscheint, oder aber beides? --:Bdk: 19:33, 19. Okt 2005 (CEST)
- Die angezeigt Anzahl der Artikel stimmt bei großen Kats sowieso nicht, da werden immer 200 angezeigt, auch wenns 5000 sind. Eine mögliche Anwendung für doppelte Kategorie Einträge wäre zum Beispiel bei Schriftstellern, die unter verschiedenen Pseudonymen veröffentlicht haben. --Jutta234 - Diskussion 19:40, 19. Okt 2005 (CEST)
- So eine Funktion vermisse ich auch. Z.B. für Wilken F. Dincklage, der einmal unter seinem Namen, das andere mal unter "Willem" erscheinen müßte. --Tondose 17:27, 15. Aug 2006 (CEST)
- Die angezeigt Anzahl der Artikel stimmt bei großen Kats sowieso nicht, da werden immer 200 angezeigt, auch wenns 5000 sind. Eine mögliche Anwendung für doppelte Kategorie Einträge wäre zum Beispiel bei Schriftstellern, die unter verschiedenen Pseudonymen veröffentlicht haben. --Jutta234 - Diskussion 19:40, 19. Okt 2005 (CEST)
- Nachfrage: Wo ist der Sinn doppelter Einträgen eines Artikels in einer Kategorie? Meinst Du sowas, wie [Hamburg-Fuhlsbüttel] in einer Kategorie einmal unter H und gleichzeitig einmal unter F abzulegen? Problem wäre dabei m.E., dass die absolute Zahl der Kategorieeinträge neu berechnet und nachvollziehbar angezeigt werden müsste. Und kann jemand mal anschauliche Beispiele für den wirklichen Bedarf dieser Optionen geben? Meinst Du mit "angezeigter Bezeichnung" das, was in der Artikelseite oder aber lesbar in der Kategorie selbst erscheint, oder aber beides? --:Bdk: 19:33, 19. Okt 2005 (CEST)
- Doppeleinträge sind nicht vordringlich, sondern Abweichungen vom Artikeltitel --Hb 21:08, 24. Jan 2006 (CET)
- dafür: StefanL,K@rl, FWHS, Timo Müller Diskussion, Hb, Fritz @
- dagegen:
[Bearbeiten] Abkürzungen "geb." und "gest."
Verschoben nach Wikipedia:Verbesserungsvorschläge. -- Timo Müller 21:09, 10. Aug 2005 (CEST)
[Bearbeiten] 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)
- dafür: Timo Müller, StefanL, Schlurcher ??? , FWHS, Schreiber, Tlustulimu, Hannes2 Diskussion , Ce, Fritz @
- dagegen:
[Bearbeiten] 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:
[Bearbeiten] Rechnen mit Wikipedia
Statt
- g = 6,674E-11 /5,972E24 * 286371E3 / 6371E3 = 9.82
kann man schreiben:
- ... g= 9,82 m/s² [9].
bzw:
Frage: Ist es möglich, einen Rechenlink auch in Wikipedia zu integrieren?
Dantor 16:12, 15. Aug 2005 (CEST)
- das ganze ist wohl nicht nötig genug. ich erkenne kein problem darin, google oder was anderes zum rechnen zu benutzen. den wikipedia-server muss man damit nicht noch belasten. --joni (Δisκussion) 17:18, 15. Aug 2005 (CEST)
-
- Dem ist nichts hinzuzufügen. --Dr. Schorsch 17:27, 15. Aug 2005 (CEST)
- Ich finde die Idee garnicht so dumm. Allerdings würde ich es erst durch die Einbeziehung verschiedener Artikel als wirklich sinnvoll erachten und vielleicht nicht unbedingt im Rahmen der Wikipedia. Man stelle sich z.B. ein Politikwiki vor bei dem viele Autoren an der mathematischen Beschreibung von Objekten [Arbeitslosenzahlen, Steuerquote, Staatsverschuldung...) und deren Beziehungen untereinander (...) arbeiten, also ein komplexes Dynamisches System (s. Entity-Relationship-Modell) beschreiben. Wenn man sich dann auf die Beschreibung des Systems geeinigt hätte könnte jeder durch einen Datenbankdownload das ganze in sein Simulationsprogramm laden und die Optimierung starten. Das wäre eine kleine Revolution Richtung wahrer Demokratie. Aber auch für Firmenwikis könnte es interessant sein Rechnungen und Statistiken durchzuführen. Für mich als Ingenieur wäre somit absolut interessant Berechnungen über verschiedene Maschinenelemente webbasiert, parametrisch, mit Templates und mit ordentlichen Formelsatz durchführen zu können. In der einfachen Form von oben bin ich aber auch eher dagegen. Kolossos 21:41, 15. Aug 2005 (CEST)
- dafür:
- dagegen: Dr. Schorsch, FWHS
[Bearbeiten] 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)
-
-
-
-
-
[Bearbeiten] Empfehlungsystem für Weblinks (war: Rating für Weblinks)
Problem:
- Da Wikipedia für viele Leute zum Einstieg für die Suche im Internet geworden ist, hat das Link-Spamming in der Wikipedia in letzter Zeit ärgerliche Ausmaße angenommen.
Vorchlag:
- Es wird ein Mechanismus zum "Empfehlen" von Weblinks eingeführt. Ein Wikipedianer kann einen als nützlich empfundenen Weblink jederzeit "empfehlen" (z. B. durch Klick auf ein Symbol neben dem Link). Seine Empfehlung wird um so stärker gewichtet, je mehr Benutzerbeiträge er geleistet hat. (Das soll verhindern, daß Linkspammer sich in kurzer Zeit viele Pseudo-Benutzer zulegen, um ihr Rating hochzutreiben.) Die Wertung eines Links wird in möglichst einfacher Form beim Laden der Seite angezeigt. (Beispiel: http://www.echt-brauchbar.de [42 "Gut"-Punkte], http://www.nur-schrott.de [1 "Gut"-Punkt].)
Nachteile (hier muß ich raten):
- Aufwendig zu implementieren, Benutzeroberfläche für das Abgeben von Ratings notwendig, Weblinks müssen eine symbolische Einheit statt bloßen Markups werden, Anzahl der Datenbankzugriffe wird erhöht. (Anscheinend gibt es bisher eine "Schwarze Liste" für Spam-URLs, die recht performance-intensiv ist.)
Nutzen:
- Alle Leser können auf einen Blick sehen, ob bestimmte Weblinks von anderen Wikipedianern geprüft und empfohlen wurden. Linkspammer haben es deutlich schwerer, die Wikipedia für ihre Zwecke zu mißbrauchen.
--HoHun 22:26, 18. Aug 2005 (CEST)
- Das Problem ist eigentlich garkeines. Die Wikimediasoftware baut in jeden externen Link automatisch ein rel="nofollow" ein. Das gibt den Suchrobotern von Google und Co. an, dass dieser Link nicht zu berücksichtigen ist z. B. bei Googles Berechnung des Pageranks. Du kannst also so viele Links zu einer Seite in die WP einbauen wie Du willst, ohne dass deren Pagerank dadurch von Wikipedias Pagerank profitiert. Mehr Infos dazu gibts z. B. Hier. Gruß --Spuerhund 20:28, 23. Aug 2005 (CEST)
-
- OK, dann bricht mir die Hälfte der Motivation weg. Die andere Hälfte bleibt aber, Linkspams gibt's nun mal wirklich, und ich lande über Google-Artikel tatsächlich häufiger mal auf irrelevanten Seiten. Ein "thumbs up" für einen Link von anderen Wikipedianern würde ich daher immer noch begrüßen, und den soll mein Vorschlag möglich machen. --HoHun 20:49, 23. Aug 2005 (CEST)
-
-
- Ich sehe aber neben der sehr komplizierten technischen Umsetzung und zusätzlichen Serverbelastung zwei große "Fehler im Design". Erstens, wer will beurteilen, ob ein Link so gut ist eine Empfehlung zu bekommen oder nicht? Du? Jimmy Wales? Oder wird für jeden Link eine Umfrage gestartet? Welche Mehrheit soll da entscheiden? Was, wenn nur 3 Leute abstimmen? Wie lange soll eine Abstimmung überhaupt gehen? Dürfen nur langjährige Wikipedianer abstimmen? Das würde gegen den bisherigen Grundgedanken der WP verstoßen und Einsteiger abschrecken denke ich. Und zweitens wenn man überhaupt erstmal "empfehlende" Links (also auch ohne ein ref="nofollow") einbaut lockt das doch erst Recht Spammer auf den Plan, die dann über die WP herfallen und überall (automatisiert) ihre scheiss Links eintragen (lassen). Insofern sicher eine gute Absicht von Dir, aber ich halte es für die Praxis leider nicht für praktikabel. --Spuerhund 01:40, 2. Sep 2005 (CEST)
-
-
- Hm, die von Dir genannten Punkte sind in meinem Vorschlag eigentlich alle schon berücksichtigt. Ich schätze, ich hab's einfach nicht so gut erklärt - daher habe ich erstmal die Erklärung überarbeitet. Erscheint Dir mein Vorschlag in der neuen Formulierung jetzt sinnvoller? --HoHun 22:41, 2. Sep 2005 (CEST)
[Bearbeiten] Datumsformat frei einstellen
Man kann zwar unter "Einstellungen" > "Datumsformat" aus 5 vorgegebenen verschiedenen Formatierungen wählen, aber das ist mir nicht komfortabel genug. Perfekt wäre ein Eingabefeld, wo man die gewünschte Formatierung von Datum und Uhrzeit frei eintragen kann. Da intern vermutlich ohnehin die PHP Date Funktion benutzt wird, sollte das kein Problem sein.
Im phpBB Board (zum deutschen Handbuch) ist dies z. B. auch problemlos möglich. Jeder Benutzer kann in seinen Einstellungen die Formatierung selber einstellen. Ich hätte z. B. gerne eine Formatierung "d.m.Y, H:i", andere Benutzer hätten es wahrscheinlich gerne noch anders.
Um technisch unversierte Benutzer, die sich nicht mit Parametern von PHP Funktionen auseinandersetzen wollen, nicht zu verschrecken, könnte man ja die bewährte bisherige Auswahl mit den 5 vorgegebenen Möglichkeiten beibehalten und darunter - mit einem entsprechenden Hinweis und einem Link zu einer erklärenden Seite - das Eingabefeld für die Formatierungsoptionen, um Nutzern wie mir eine individuelle Formatierung anzubieten. --Spuerhund 03:15, 22. Aug 2005 (CEST)
- dafür: FWHS, Στέφανος (Stefan) ■ ich nähme D | d.m. | H:i
- dagegen:
[Bearbeiten] Hieroglyphen
Könnte man die Software nicht so ändern, dass (ägyptische) Hieroglyphen keine eigene Zeile beanspruchen, sondern sich in eine Textzeile einpassen lassen?--Schreiber 15:01, 23. Aug 2005 (CEST)
- dafür --qwqch 02:26, 24. Okt 2005 (CEST)
[Bearbeiten] Kleines Feature in "Letzte Änderungen"
Hallo, bei der Letzte Änderungen Seite kann man einige Beiträge zeigen/verbergen. Kurze,Anonyme,etc.
Was ich da noch vermisse wären z.b. neue Seiten anzeigen/verbergen. Ok, dafür gibts es Special:Newpages ABER...
- Es wäre in kombination mit Anonymen Beiträge eine super einfache Möglichkeit schnell schnelllöschungswerte Beiträge zu entdecken, denn ich schalte immer Anonym ein und suche die Neuen und klicke diese dann durch und hab dadruch schon ein paar Schnelllöschbeiträge gefunden.
- Falls einer meint mit einem geübtem Auge könne man das auch auf Newpages sehen, den muss ich fragen: Warum brauche ich ein geübtes Auge? Warum lässt man eine einfach zu programmierende Funktion weg und erhöht dadurch das Risiko nen Schrottbeitrag zu übersehen.
- Andersherum kann man alle geänderten Beiträge bis auf die neuen sehen, ist für manchen ähnlich sinnvoll wie die kurzen Änderungen auszublenden
- Es sollte für die Programmiere nichtmehr als 10-15 min dauern sowas einzubauen, ist ja nur eine zusätzliche suchtoption im SQL Query
-- Mokros 23:58, 24. Aug 2005 (CEST)
[Bearbeiten] 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)
- 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)
- 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: [10] -- 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)
[Bearbeiten] <math>-Internationalisierung
Diese Anzeigen sollten mit dem richtigen Locale generiert werden - siehe zB Lichtstärke (Photometrie). Dort ist in der Formel "12.566" mit der Bedeutung "12 Komma 566" (4*pi). -- Phmarek 12:28, 31. Okt 2005 (CET)
- Das zugrundeliegende LaTeX wird von der Software ziemlich unverändert eingebaut. Wenn es da für normales TeX/LaTeX eine Package oder irgend eine Lösung gibt, könnte man die wohl einbauen. Dazu müsste aber erst mal jemand etwas passendes wissen oder finden. -- Schnargel 03:21, 4. Nov 2005 (CET)
- Man hätte halt Hilfe:TeX lesen sollen. --ChristianErtl 16:05, 11. Nov 2005 (CET)
[Bearbeiten] Keine Suchergebnisse gefunden
Könnte man nicht vielleich in die Ergebnisseite einen Link auf die Englische Wikipedia anlegen? es würde ja schon reichen wenn da stehen würde: Vielleicht gibt es bereits in der Englischen Wikipedia einen Artikel, [[w:en:{{{1}}}|{{{1}}} auf Englisch]] --Stefan-Xp 19:51, 28. Aug 2005 (CEST)
- Oder es könnte sein, dass die Rechtschreibung des Suchbegriffes nicht mit der Schreibung des Begriffes in der Wikipedia übereinstimmt. Beispiel für de.wiki: Küssnacht am Rigi / Küßnacht am Rigi (Ort in der Schweiz mit schweizspezifischer Schreibung, die der deutsch-deutschen Schreibung widerspricht; Beispiel für fr.wiki: Geneve / Genève; Beispiel für ln.wiki: Kɔ́ngɔ / Kongo. Ich würde es sehr begrüssen, wenn die Suchfunktion eine gewisse Toleranz aufwiese. konkret denke ich an die Gleichbehandlung der folgenden Zeichen bei der Suche:
- alle diakritischen Zeichen ignorieren, d.h. a=à=á=ǎ=â etc.
- Ligaturen auch als zwei Buchstaben finden: æ sucht æ und ae etc.
- im lateinischen Alphabet jedoch nicht auf unseren Tastaturen vorhandene Zeichen den (fast) gleich tönenenden gleichstellen, Beispiel e=é=è=ê=ɛ=ɛ́=ɛ̂, etc. oder o=ò=ó=ɔ=ɔ́=ɔ̂=ɔ̌
Begründung: Gerade die im letzten Punkt aufgeführten Zeichen werden in vielen Sprachen verwendet, welche wohl meistens über eine Grammatik und Orthographie verfügen, die aber – ich denke da v.a. auch an afrikanische Sprachen, asiatische haben oft andere Schriften – oft nicht unterrichtet werden. Und Wikipedia macht ja nur dann einen Sinn, wenn die Artikel auch gefunden werden können. -Etienne 11:42, 6. Dez 2005 (CEST)
-
-
- siehe auch weiter unten... --M.A. (Marc-André Aßbrock) 11:35, 27. Dez 2005 (CET)
-
[Bearbeiten] Frames
Speziell bei großen Seiten oder auch Diksussionen stört es mich häufiger, dass ich recht viel rauf und runter scrollen muss, um an (nennen wir sie mal) Werkzeug-Links zu kommen. Dies sind im einzelnen.
- ..., Beobachtungsliste, Eigene Beiträge, ..., Versionen/Autoren, ..., beobachten ganz oben
- Kategorien ganz unten
- Suche, Werzeuge links oben
Mein Gedanke ist nun, dass man die Wiki-Seiten mit Frames anzeigen könnte, so daß diese links einfach immer sichtbar sind und man nicht umständlich rauf und runterscollen muss, wenn man z.B. die Kategorien zu denen ein Artikel gehört und danach die Versionen kontrollieren will.
Ob es sich dabei um 3 zusätzliche Frames (oben, unten, links) handelt, um die gewohnten Plätze beizubehalten, oder nur ein zusatzlicher Frame (wo auch immer auf der Seite) erzeugt wird, ist mir zunächst mal egal, und müsste noch im Detail diskutiert werden.
Ich weiss dass es verschiedene Skins gibt, aber etwas wirklich zufriedenstellendes in dieser Beziehung ist IMHO nicht dabei.
Ich weiss leider nicht, ob sich mein Wunsch mit einem weiteren skin realisieren liesse, oder ob dafür die Software geändert werden müsste. --Jutta234 - Diskussion 18:40, 7. Sep 2005 (CEST)
- Wenn Du Skin "Standard" einstellst und die Option "Seitenleiste freischwebend" in den Optionen einstellst, dann sind die genannten Links alle ortsfest. Das ist der Hauptgrund, warum ich immer noch diesen Skin verwende. --Ce 21:16, 7. Sep 2005 (CEST)
- Hab eben mal ein klein bisschen getüftelt: ist zwar nicht 100%ig was du haben wolltest, aber erfüllt im Prinzip das gleiche: Füge in deiner Benutzer:Jutta234/monobook.css (wirst ja sicherlich Monobook verwenden) die Zeile
#bodyContent {height:665px; overflow:scroll;}
hinzu, dann befindet sich der Text der eigentlichen Seite (inkl. Vorschau, Bearbeiten-Fenster, Abspeicherknöpfe und Kategorie-Anzeige) in einem einzelnen scrollbaren Bereich. Die Höhenangabe hab ich auf meine Verhältnisse so abgestimmt, dass grade so keine zusätzliche Scrollleiste ganz rechts vom Browser erscheint. Diese kommt dann nur noch wenn es auf einer Seite viele Interwiki-Links gibt, die werden dann gescrollt. Ich persönlich kann mich aber nicht damit anfreunden, denn das Mausrad und die Bild-Ende- und Bild-Runter-Tasten reagieren in diesem Scrollbereich nicht mehr. K.O.-Kriterium. Ansonsten bleibt noch die komplette Anzeige per user-javascript umzuprogrammieren. zumindest für die Sidebar links bin ich grad an sowas dran. Wenn ichs eingebaut hab, stehts in Benutzer:BLueFiSH.as/Javascripts & Stylesheets von Benutzern. Littl hat's wohl schon gemeistert, muss morgen mal schmulen gehen bei ihr wie das aussieht. --BLueFiSH ?! 22:03, 7. Sep 2005 (CEST)
- @ce: Sorry aber ich finde die Einstellungen, die Du angibst nicht. Die Option "Seitenleiste freischwebend" hab ich irgendwann mal gesehen. Jetzt ist sie aber komplett verschwunden. Wo genau befindet sie sich denn bei Dir? (Vielleicht bin ich ja nur blind..) Und den Skin "Standard" finde ich auch nicht bei mir gibt es nur : MonoBook (default), Klassik , Küken, MySkin, Kölnisch Blau, Amethyst, Nostalgie und Simple. Oder meinst Du MonoBool (default)
- @Bluefish: Ich hatte ein monobook.css, allerdings als ich es jetzt aufrief erhielt ich die Meldung, dass der Inhalt nicht in der Datenbank gefunden werden konnte - seltsam seltsam. Die vorherigen Einstellungen sind jedenfalls damit futsch - naja. Ich habe das mal so wie von Dir vorgeschlagen eingetragen. Es hat wirklich einen positiven Effekt, nur bin ich nicht 100%ig glücklich. Die Kategorien befinden sich ja innerhalb vom "bodyConent". Deshalb sind muss ich großen Artikeln immer noch "kilometerlang" nach unten scrollen.
- Allgemein: Danke für die "Workaround" Vorschläge, sie helfen mir wirklich. Aber mein Eintrag war eigentlich als allgemeiner Verbessungsvorschlag zu verstehen. Also entweder eine Änderung der Software vorzunehmen bzw. einen "Frames - Skin" zu erstellen,der dann unter "Einstellungen" für jedermann zu finden ist. Frames sind ja nun wirklich seit langem absolut im Internet verbreitet. Ich wollte zur DIskussion stellen, ob es Sinn macht, wenn Wikipedia dies ebenso nutzt. --Jutta234 - Diskussion 10:18:30, 8. Sep 2005 (CEST)
-
- Der Skin, den ich meine, heisst in den Einstellungen inzwischen "Klassik" (wurde wohl umbenannt, weil er ja inzwischen nicht mehr der Standard-Skin ist). Die Benutzer-CSS etc. heißen aber immer noch "standard", deshalb ist mir die Umbenennung nicht aufgefallen.
- Es ist möglich, dass die Option für die freischwebende Seitenleiste nur bei Skins angezeigt wird, die diese auch unterstützen (das wäre auch irgendwo sinnvoll). Beim Skin Klassik befindet sich die Gruppe "Seitenleiste" zwischen "Benutzerdaten" und "Skin".
- Echte Frames halte ich für keine gute Idee, weil es da Probleme mit der URL gibt (Bookmarks!).
- Die Kategorien hatte ich oben übersehen; die sind tatsächlich immer im content, auch im Klassik-Skin. Allerdings kann man die auch ganz einfach an eine absolute Position versetzen:
#catlinks { position: fixed; top: 10px; left: 10px; }
-
- Hierbei geben die "top" und "left" die Position im Fenster an (die angegebenen Werte sind nur als Beispiel gedacht; im Klassik-Skin wäre diese Position natürlich nicht ideal). Zusätzlich ist es natürlich möglich, ein width-Attribut einzusetzen (z.B. damit es im Seitenleistenbereich bleibt). --Ce 16:30, 8. Sep 2005 (CEST)
Bei mir funktioniert das ncith (IE6). Auch der Skin Wasserblau oder wie der heißt, bietet das Menü. Seitenleiste und ich kann freischwebend wählen, aber das schwebt ncihts.--Löschfix 18:09, 15. Sep 2005 (CEST)
[Bearbeiten] Benutzer benachrichtigen: Beobachtungsliste
Ich fände es ganz nett, wenn man eine Email kriegte, sobald ein beobachteter Artikel bearbeitet wird. Idealerweise einstellbar für jeden Artikel einzeln und mit Filter, so dass ich "Kleine Änderungen" ausblenden kann. Die Einstellung dieser Optionen könnte man in der Beobachtungsliste ganz einfach einbauen. --Merkosh O=O 09:57, 12. Sep 2005 (CEST)
-
- Hmmm - Soweit ich das sehe, müsste es auf dem Wikipedia-Server installiert werden. Ohne die Beschreibung wirklich tiefgehend gelesen zu haben, postuliere ich mal, dass es in meinem Sinn funktioniert ... dann müsste es nur noch jemand einstricken. Um mit Captain Picard zu sprechen: "Energize !". --Merkosh O=O 15:30, 12. Sep 2005 (CEST)
-
-
- Mir ist nicht klar, ob das für die Wikipedia jemals implementiert wird. Das Mailaufkommen wäre riesig. --Avatar 10:05, 15. Sep 2005 (CEST)
-
-
-
-
- Hmmm ... dass das ein riesiges Mailaukommen ergäbe, ist klar. Liesse sich aber reduzieren, indem z.B. nur 1 x täglich eine Nachricht in der Art von "Es wurden beobachtete Artikel geändert. Du solltest mal nachsehen !" bzw. eine Liste der geänderten Artikel versandt wird. In dem Fall wäre das täglichen Mailaufkommen maximal gleich der Anzahl der Benutzer, vermutlich aber weit weniger. Im Traffic der Wikipedia-Server sollte das weitgehend untergehen, vor allem wenn man es nachts um 3 Uhr oder so macht, wenn der Traffic eh' geringer ist. --Merkosh O=O 15:58, 16. Sep 2005 (CEST)
-
-
-
-
-
-
- Dann müsste Enotif entsprechend angepasst werden. Ich gebe allerdings zu Bedenken, dass, wenn es 3 Uhr in Deutschland ist, der Traffic recht groß ist, da es in Amerika 18:00 bis 21:00 Uhr ist :-). --Avatar 16:33, 16. Sep 2005 (CEST)
-
-
-
Ich halte es für wenig sinnvoll. Man könnte genauso gut ein Lesezeichen auf seine Beobachtungsliste setzen. --Royd 22:07, 16. Sep 2005 (CEST)
- Gut und schön - da bedingt aber, dass ich als Normalverdiener und Familienmensch noch hochpriorisierte Timereinträge im nichtflüchtigen Gedächtnis frei habe. Eine Email-Notification wäre da hilfreicher, vor allem wenn es um Artikel geht, die eher selten von anderen Leuten bearbeitet werden - 1000 mal kontrolliert, 1000 mal ist nix passiert ...
-
- In diesem Fall wäre es aber vermutlich sinnvoller, wenn dafür eine eigene "Benachrichtigungsliste" eingerichtet würde. Dann könnte man unterscheiden zwischen Artikeln, wo man einfach auf dem Laufenden bleiben will, und Artikeln, wo man wirklich sofort über jede Änderung benachrichtigt werden will. --Ce 11:03, 29. Sep 2005 (CEST)
-
-
- Das geht auch auf nem kleinen Umweg, wird auch von einigen Benutzern genutzt: Lege dir eine Unterseite an (z.B. Benutzer:Amtiss/Beobachtungslistenauslagerung), verlinke alle Artikel, die selten bearbeitet werden bzw. für die du eine abgetrennte Beobachtung vornehmen willst, und dann klicke links unter Werkzeuge auf "Änderungen an verlinkten Seiten". -- Amtiss, SNAFU ? 16:58, 27. Dez. 2006 (CET)
-
Hier also eine Voting-Ecke dafür
- dafür: Merkosh
- dagegen: Royd
[Bearbeiten] Toolbar
Wäre es keine Gute Idee, eine Wikipedia-Toolbar zu entwickeln, damit man sein Suchwort direkt eintippen kann und direkt zum gewuenschten Eintrag weitergeleitet wird (besser noch: pop-up).
Wäre bestimmt vorteilhaft!
LG
Ernest D.
- Ich zitier mal Mathias Schindler:
Es gibt derzeit einige Toolbarprojekte, die auch auf Wikipedia zurückgreifen. Dazu gehört zum einen der Browser Firefox, der Suchanfragen in Wikipedia von Anfang unterstützt. Eine vollständige Toolbar für Wikipedia in XUL wird derzeit auf http://wikipedia.mozdev.org/ gepflegt, der Quellcode steht unter einer freien Lizenz. Darüber hinaus gibt es noch einige Computerprogramme für einzelne Betriebssysteme, die Wikipedia-Suchanfragen anbieten, etwa webtip Titlebar: http://www.chip.de/downloads/c1_downloads_16210238.html oder das Suchwidget für MacOS X Tiger/dashboard. http://www.apple.com/downloads/dashboard/reference/wikipedia.html
- --Avatar 10:03, 15. Sep 2005 (CEST)
-
- Opera hat ne "Suchleiste" da kann neben den gängigen Suchmaschinen auch Wikipedia reingetan werden. IMO ist Standard die englische, aber die deutsche läßt sich auch problemlos integrieren. --Sarkana 21:10, 25. Sep 2005 (CEST)
- FireFox hat die auch. Aber Opera hat noch eine viel bessere Funktion: Wenn man z.B. in die Adressleiste y Suchwort eingibt sucht er bei yahoo! nach diesem Suchwort. Mit g Suchwort sucht er bei google (bei Firefox gibt es nur die Funktion, dass man mit google Suchwort den ersten Treffer oder so anzeigt). Im Opera kann man diese Funktion für die Wikipedia und andere Seiten problemlos ergänzen - das ist bedeutend benutzerfreundlicher, als eine Suchfeld. (Man muss natürlich Opera haben...) --M.A. (Marc-André Aßbrock) 18:33, 26. Dez 2005 (CET)
- Opera hat ne "Suchleiste" da kann neben den gängigen Suchmaschinen auch Wikipedia reingetan werden. IMO ist Standard die englische, aber die deutsche läßt sich auch problemlos integrieren. --Sarkana 21:10, 25. Sep 2005 (CEST)
[Bearbeiten] 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)
[Bearbeiten] Begriffsklärung aus Nicht kategorisierte Seiten entfernen (erledigt)
Hi, ich betrachte die Spezialseite: "Nicht kategorisierte Seiten" als ein Hilfsmittel um die Qualität der Wikipedia weiter zu verbessern. Begriffsklärungen sollen jedoch explizit nicht Kategorisiert werden. Daher wäre es gut wenn sie in der Spezialseite nicht auftauchen. Des weiteren scheint die Software auch nicht zu erkennen, wenn ein Artikel durch Verwendung einer Vorlage kategorisiert ist. Wenn man dieses Problem beheben würde, wäre das erste automatisch gelöst, da es ja die Kategorie:Begriffsklärung gibt. --Trickstar 15:34, 1. Okt 2005 (CEST)
Nachtrag: Gleiches gilt für verwaiste Artikel, Begriffsklärungen sollen ja gerade _nicht_ verlinkt werden. --Trickstar 00:59, 7. Okt 2005 (CEST)
[Bearbeiten] Bilder bevorzugt auf die Commons laden
Ich weiß, dass sie Gelegenheit für diesen Vorschlag gerade sher ungünstig kommt, weil gerade ein Meinungsbild darüber stattfindet, ob man die Hochladefunktion hier abschalten sollte, aber ich hätte eine Möglichkeit, die einen Großteil der Leute, die nur schnell mal eben ein Bild hochladen möchten, auf die Commons leitet: Der Link „hochladen“ verweist nicht mehr auf die eigentliche Hochladeseite, sondern auf eine zwischenseite, auf der ein Text steht wie dieser: „Bilder lädst du am Besten direckt auf die Wikimedia Commons, sodass sie von allen Wikimedia-Projekten verwendet werden können.“ Darunter kommt ein Link „Bild auf die Commons laden“, der direkt auf die Hochladeseite der Commons linkt, sowie ein kleinerer Link „Bild nur auf die deutsche Wikipedia laden (nur in Ausnahmefällen sinnvoll)“, der auf unsere eigentliche Hochladeseite linkt. Diese Änderung müsste sich ohne viel Aufwand verwirklichen lassen, und führt dazu, dass ein sehr großer Teil der Bilder auf die Commons geladen werden, aber die Möglichkeit, Bilder in der deutschn Wikipedia hochzuladen, trotzdem bestehen bleibt. -- Timo Müller Diskussion 19:36, 9. Okt 2005 (CEST)
Pro:
- jedenfalls sowas in der Richtung. Und als Zwischenlösung bitte den Hinweistext zum Hochladen drastisch verkürzen und den Commons-Hinweis sehr stark (rot usw.) hervorheben! --qwqch 02:21, 24. Okt 2005 (CEST)
- Hier ein Vorschlag: Benutzer:iGEL/Hochladen. -- iGEL (+) 17:54, 28. Okt 2005 (CEST)
- Die Richtung stimmt, aber verbieten würde ich das Hochladen auf der deutschen Wikipedia nicht. --Immanuel Giel 09:02, 14. Nov 2005 (CET)
- Hatte ich doch auch gar nicht vor. (Siehe oben) -- Timo Müller Diskussion 09:39, 14. Nov 2005 (CET)
- Bin auch dafür. Selbst kleine Wikis mit rund 100 Artikeln handhaben das so: http://ln.wikipedia.org/wiki/Special:Upload Etienne 12:13, 2. Dez 2005 (CET)
- --Hannes2 Diskussion 09:15, 26. Aug 2006 (CEST) Ganz abschalten geht nicht, schließlich muss z. B. das Logo hier bleiben, aber ein solcher Link würde manches verbessern.
Contra:
[Bearbeiten] Syntax Numerierte Listen ab 2 oder höher
Wie sieht es mit einer Syntax aus, wo man den Beginn der Zählung setzen kann (auch innerhalb der Liste, um die Aufteilung in mehrere Listen zu verhindern)? Die direkte Formatierung einer Liste ist im Moment auch nur über HTML-Elemente zugänglich, die doch aber unerwünscht sind. --ChristianErtl 03:57, 14. Okt 2005 (CEST)
- Ich bin dafür. -- Timo Müller Diskussion 20:57, 16. Okt 2005 (CEST)
Empfinde ich auch als nützliches Feature. Dafür. -- Hey Teacher 14:20, 11 November 2005 (CET)
von 213.6.254.25: Mit der Raute (#) kann ich schöne numerierte Listen anlegen, wie es das <ol>-Tag hergibt.
Nur möchte ich solche Listen aus Formatierungsgründen ggf. auch gerne mal unterbrechen und anderswo fortsetzen.
Kann ich aber anscheinend mit Wiki-Funktionen nicht: es geht dann wieder bei Nr.1 los.
Bsp:
- eins
- zwei
- drei
- vier
- fünf
Lösung: <ol start=nummer>. Geht z.Zt. anscheinend nur, indem ich HTML hart in die Seite editiere.
Bsp:
- eins
- zwei
- drei
- vier
- fünf
Also nochmal:
Numerierung wäre noch relativ einfach zu machen, für Syntax zur Formatierung wie bei Tabellen habe ich allerdings keine Idee.
- Dafür: ChristianErtl, Timo Müller Diskussion
- Dagegen:
[Bearbeiten] 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:
[Bearbeiten] Aktuelle Kategorienstruktur für einzelne Fachbereiche
Zur Kategorisierung von Artikeln ist eine aktuelle Übersicht über die bestehenden Kategorien wünschenswert. Ich vermute, dass sich eine solche unter Wikipedia:Kategorien/Übersicht findet, kann die Seite aber wegen ihres Umfangs nicht öffnen, sie wäre sicher auch sehr unhandlich. Wäre es möglich, eine automatisch generierte aktuelle Kategorienstrukturübersicht für Teilbereiche zu schaffen, beispielsweise für die Hauptkategorie "Recht" und alle zugehörigen Unterkategorien bis zur tiefsten Gliederungsebene? (Man gibt eine bestimmte Kategorie ein und bekommt die zugehörige Teilübersicht.) --wau > 20:26, 2. Nov 2005 (CET)
- Die Idee ist überzeugend. Kann man das schnell umsetzen? Danke --Pelz 23:02, 3. Nov 2005 (CET)
- Auch ich würde mich über die Umsetzung freuen. -- Stechlin 10:22, 5. Nov 2005 (CET)
- Das ist ein Fall für Benutzer:SirJective, zumindest für den Mathebereich hat er genauso etwas schonmal gemacht. --DaTroll 23:48, 12. Nov 2005 (CET)
- Ich habe schon solche Strukturdarstellungen erstellt (Beispiel: Benutzer:KatBot/Afrika). Das Problem ist, dass eine vollständige Darstellung auch der Hauptkategorien teilweise unmöglich ist, da die Kategorien recht komplex und oft auch doppelt verlinkt sind (Beispiel: Wikipedia:WikiProjekt Philosophie/Kategorien/Übersicht Seite ist sehr umfangreich). Falls wer interesse hat kann er sich bei mir melden. --SteveK ?! 10:34, 30. Nov 2005 (CET)
[Bearbeiten] Unterdrückung der Anzeige in Kategorie
Es sollte ermöglicht werden, dass ein Artikel einer Kategorie zugeordnet werden kann, ohne dass der Artikel in der Kategorie angezeigt wird. Damit wird dann nur im Artikel die Kategorie angezeigt. Dies könnte zum Beispiel durch Angabe einer speziellen Sortierzeichenkette wie "@@@@" in der Form [[Kategorie:Name|@@@@]] erfolgen. Der Sinn dieser Funktion wäre folgender: Wird statt des Artikels selbst ein Redirect kategorisiert, weil der Artikel beispielsweise ein für die jeweilige Kategorie unpassendes Lemma besitzt, so fehlt dem Benutzer im Artikel der Verweis auf die Kategorie.StefanL 01:00, 5. Nov 2005 (CET)
- dafür: StefanL
- dagegen:
- Kommentar: Ein Redirect lässt sich doch gar nicht kategorisieren. -- Martin Vogel قهوة؟ 01:10, 5. Nov 2005 (CET)
- Kommentar zum Kommentar: Doch ein Redirect lässt sich kategorisieren. z.B. #redirect [[Dorthin]] [[Kategorie:Xyz]] dann erscheint auch der redirect in der (den) Kats. siehe z.B. hier --Jutta234 01:32, 5. Nov 2005 (CET)
- Das war mir neu, danke. -- Martin Vogel قهوة؟ 06:03, 5. Nov 2005 (CET)
- Kommentar zum Kommentar: Doch ein Redirect lässt sich kategorisieren. z.B. #redirect [[Dorthin]] [[Kategorie:Xyz]] dann erscheint auch der redirect in der (den) Kats. siehe z.B. hier --Jutta234 01:32, 5. Nov 2005 (CET)
- Das ist ungefähr so ähnlich, wie der Vorschlag, neben der lexikalischen Einordnung auch den Anzeigenamen in der Kategorie bestimmen zu können. Wie sieht es damit aus? Welches ist technisch ungünstiger? Dass man immer Redirects anlegen müsste, um den Eintrag in der Kategorie zu beeinflussen, finde ich ungünstig.
- das ist doch schon möglich: verwende einfach Kategorie:Name als Link mit einem ":" vor "Kategorie", dann musst du allerdings noch dafür sorgen, dass es richtig aussieht, also einfach Kategorie:Name schreiben Sven-steffen arndt 19:20, 30. Nov 2005 (CET)
- Nein, das ist mir bekannt und etwas anderes. Es geht darum, die Anzeige in der Kategorie-Übersicht zu beeinflussen, eben passend zur Kategorisierung von Redirects (mehr oder weniger ein Hack). --ChristianErtl 23:31, 1. Dez 2005 (CET)
[Bearbeiten] Link zur englischen Wiki
Wenn die Wikipedia eine Anfrage von mir nicht findet, zeigt sie die SuchHilfe, in der die Anfrage gleich an Google oder Yahoo weitergeleitet werden kann. Hier sollte es auch eine AnfrageOption an die englische Wikipedia geben. Ich sehe dort immer zunächst nach. Wenn es eine deutsche und eine englische Version eines Artikels gibt, sehe ich mir sowieso immer beide Versionen an. Bei den meisten Artikeln steht an der linken Seite eine Auswahl and verschiedenen Sprachen, in denen es eine Version dieses Artikels gibt. Meistens ist Englisch dabei, manchmal nicht. Ich schlage vor, daß ein Verweis zur englischen Wikipedia immer vorhanden ist, zumindest zur HauptSeite. Vom Fehlen eines Verweises auf eine englische Version lasse ich mich nicht abhalten, in der englischen Wikipedia nachzusehen. Oft fehlt nur die Verlinkung. Oder die Information ist unter einem anderen Namen zu finden.
Diese Anfrage betrifft natürlich nur die deutsche Wikipedia. Umgekehrt würde ich es auch in der englischen Wikipedia vorziehen, einen Link zur deutschen vorzufinden. Das könnte aber auf weniger Zustimmung stoßen. Vor allem könnte in Frage gestellt werden, warum nur die deutsche Version eine SonderBehandlung erfährt. Es mag aber auch eine allgemeinere Lösung geben, zB ein Auswahlfeld mit den am meisten benutzten Sprachen zuoberst.
- Ich finde, unter "Andere Sprachen" sollten weiterhin nur die Sprachen aufgeführt werden, bei denen der Artikel auch vorhanden ist. Ansonsten wäre es viel zu unübersichtlich und würde eh nichts bringen: Dann kann man ja gleich jede Wikipedia selbst aufrufen. Allerdings fände ich es auch gut, wenn zusätzlich zu der Suchfunktion Artikel mit dem gleichen Namen aus den anderen Wikipedias erscheinen würden. Also so ähnlich, wie das Tool globalwpsearch von Aka (nur sollten nicht die fehlenden Interwikilinks aufgelistet sein, da die Funktion ja ehr für den Anwender als für den Schreiber wäre) --M.A. (Marc-André Aßbrock) 18:12, 26. Dez 2005 (CET)
siehe Benutzer:Cordobes/Erweiterte Internationalisierung - zu diesem Thema wird gerade eine Umfrage vorbereitet, wie und ob sowas realisiert werden könnte. --cordobés ¿? 06:31, 25. Okt. 2006 (CEST)
[Bearbeiten] Wiedervorlage
Ich bearbeite oft Artikel, indem ich auf den Dis-Seiten Hinweise gebe. Diese möchte ich mir nach einiger Zeit wieder ansehen, um zu sehen, ob sich irgenwas an dem Artikel getan hat. Die Beobachtungsliste hilft hier erstmal nicht weiter, weil ich leider nicht immer meine komplette Liste durcharbeiten kann und weil ja vielleicht keine Änderungen nach meinem Edit vorgenommen wurden. Aus den genannten Gründen rege ich eine Funktion an, die den entsprechenden Artikel nach einem zu bestimmenden Zeitablauf automatisch in Form einer Nachricht anzeigt. Natürlich könnte ich die mir auffallenden Artikel auch auf eine Unterseite eintragen, aber das ist natürlich deutlich aufwändiger . --Pelz 23:25, 2. Dez 2005 (CET)
[Bearbeiten] Kurzüberblick Artikelhistorie
Mit der Seigenthaler-Episode ist in der Öffentlichkeit noch einmal der Focus auf Qualitätsprobleme in der Wikipedia gelenkt worden. Um dem Leser die Einschätzung der Zuverlässigkeit eines Artikels zu erleichtern, wäre es meiner Meinung nach hilfreich, die Zahl der Artikelversionen und die Anzahl der beteiligten Nutzer zu kennen. Daher fände ich es sinnvoll, wenn am Artikelende nicht nur Datum und Uhrzeit der letzten Änderung, sondern auch 1. die Zahl der angemeldeten Benutzer, die an dem Artikel etwas editiert haben, 2. die Zahl der entsprechenden IP-Adressen und 3. die Anzahl der bisherigen Artikel-Versionen zu erfahren. Das Ganze natürlich in der gebotenen Kürze, z.B. (31/66/249). Ich weiß nicht, wie groß der technische Aufwand für eine solches Feature ist, aber ich fände es recht nützlich. --Schreibkraft 10:40, 5. Dez 2005 (CET)
- Ganz kurz: Guckstu bug 4142 Feature request: Attention score, das entspricht dem Wunsch so ziemlich :-) Du kannst auch für den bug abstimmen. Wie, steht da. Gute Grüße --:Bdk: 10:59, 5. Dez 2005 (CET)
-
- Hört sich interessant an, der Vorschlag. Wobei ich die aufgeschlüsselte Angabe der Artikelhistorie transparenter als einen "Attention score" finde. --Schreibkraft 11:10, 5. Dez 2005 (CET)
- Ich guck mal, ob sich das kombinieren lässt oder ob ich noch was Vergleichbares finde, wie die Diskussionen auf .en sind, und dass ich den Vorschlag bald bei MediaZilla reinpack, wenn niemand schneller ist ;-) Interessante Idee allemal. --:Bdk: 11:21, 5. Dez 2005 (CET)
- Tschaka, da warst Du aber fix. Weiter so :-) --:Bdk: 11:33, 5. Dez 2005 (CET)
- Ich guck mal, ob sich das kombinieren lässt oder ob ich noch was Vergleichbares finde, wie die Diskussionen auf .en sind, und dass ich den Vorschlag bald bei MediaZilla reinpack, wenn niemand schneller ist ;-) Interessante Idee allemal. --:Bdk: 11:21, 5. Dez 2005 (CET)
- Hört sich interessant an, der Vorschlag. Wobei ich die aufgeschlüsselte Angabe der Artikelhistorie transparenter als einen "Attention score" finde. --Schreibkraft 11:10, 5. Dez 2005 (CET)
In diesem Zusammenhang ist folgende Studie interessant: Andrew Lih: Wikipedia as Participatory Journalism: Reliable Sources? Metrics for evaluating collaborative media as a news resource. Lih versucht die Zuverlässigkeit von Wikipedia-Artikeln anhand der Artikelversionen (Edits) und Einzelautoren (Unique Editors) einzuschätzen. Er berichtet, dass er verschiedene Tools entwickelt hat, um diese Daten einfach zu extrahieren. --Schreibkraft 01:15, 6. Dez 2005 (CET)
[Bearbeiten] Automatische mehrspaltige Tabellen
In der Wikipedia gibt es jede Menge Listen, wobei einfach die Einträge untereinander geschrieben werden und sie dadurch sehr lang und unübersichtlich werden wie z.B. Liste klassischer Komponisten in der DDR. Besser wäre eine Tabellenform wie diese:
Asriel | Dehnert | Hanell |
Beilschmidt | Finke | Irrgang |
Cilenšek | Gerster |
Solche Tabellen sind jedoch sehr schwer zu pflegen, denn wenn man jetzt "Eisler" an die richtige Stelle einfügen wollte, müsste man die ganze Tabelle umschreiben.
Vorschlag: den Aufbau solcher Tabellen der Wiki-Software überlassen. Man schreibt einfach alle Einträge untereinander und bestimmt über einen Syntax (z.B. autocols="3"), wie viele Spalten die Tabelle haben soll. --Plenz 18:39, 8. Dez 2005 (CET)
[Bearbeiten] Automatische Vandalensperre
Ich habe soeben in dem Artikel Nikotin den Eintrag Der NkshdSNSKXNKLXHikotingehalt korrigiert. Dabei kam mir die Idee, ob man nicht gewisse Algorithmen ähnlich wie in Spam-Filtern einbauen könnte, um wenigstens einen Teil des Vandalismus zu verhindern. Zum Beispiel:
Eine Änderung wird nicht gespeichert, wenn der User anonym ist und außerdem
- in der Änderung mehr als 3 Konsonanten ohne "sch" hintereinander vorkommen
- in der Änderung mehr als 5 Konsonanten mit "sch" hintereinander vorkommen
- die Änderung ein q ohne u enthält
- die Änderung ein j ohne folgenden Vokal enthält
- in der Änderung mehr als 3 gleiche Buchstaben hintereinander stehen
Wenn ich sehe, was ich so an Vandalismus beseitige, könnten derartige Mechanismen etwas ein Drittel davon verhindern. --Plenz 15:49, 8. Dez 2005 (CET)
- Also wäre ein Wort wie Angstschweiß (8 Konsonanten!) automatisch gesperrt? Die Stadt Qingdao nicht mehr existent? Die Begriffe JPEG oder J-Pop nicht mehr erlaubt? Ich verstehe schon sehr gut, was Du meinst. Die Implemetierung aller erforderlichen Ausnahmen wäre sauschwierig, sonst würde es sich aber zu einer Behinderung auswachsen - wie bei den US-Börsenmaklern, die nicht mehr über das Unternehmen FAG Kugelfischer berichten konnten, weil der "Webwasher" das Wort fag als unzüchtig erkannte und verhinderte .... Gruß --Idler ∀ 16:12, 8. Dez 2005 (CET)
-
- Mein Gott, dass sind doch nur Vorschläge, über die sich reden lässt! Dann eben mehr als 8 Konsonanten mit sch. Und Qingdao kann eben nur ein registrierter Benutzer eingeben. Oder das System schaut in der Datenbank nach, ob es das verdächtige Wort bereits gibt, dann wird es eben akzeptiert. --Plenz 18:35, 8. Dez 2005 (CET)
-
-
- Viel zu fehleranfällig für einen marginalen Nutzen. Vandalismus wie der o.g. ist selten, da wäre eine Komplettlöschung von Artikeln eher ein lohnenderes Kriterium.--Gunther 18:57, 8. Dez 2005 (CET)
-
-
- Ich frage mich was dann mit Wörtern wie Rheinschifffahrtsbehörde oder schwer passieren wird, wenn der erste Punkt durchgesetzt wird!
- Ich bin auch für eine solche Lösung, aber es wird sehr schwer sowas durch zusetzten, denn da musste man dieses Programm entsprechen so programmieren, das es ALLE Wörter kennt, und nur Wörter löscht, die keinen Sinn haben!
- Da haben wir dann aber das Problem mit Fremdwörtern, diese dann meistens vom Programm nicht erkennt werden. (Ich denke da vorallem mal an die vielen russischen Wörter!)
-
- Ist aber ein guter Vorschlag, man müsste einfach viel zeit in sowas investieren!
-
- Freundliche Grüsse: 59th_teegee (Marton) 22:00, 8. Dez 2005 (CET)
-
-
- Schifffahrt' hat nicht mehr als drei gleiche Buchstaben. Schwer hat nicht mehr als 8 Konsonanten mit sch. Das Systen muss nicht alle Wörter kennen. Es kennt bereits die Wörter, die in der Wikipedia-Datenbank stecken, und das sollte genügen. --Plenz 22:47, 8. Dez 2005 (CET)
-
Der Gedanke hat wirklich etwas Verlockendes, aber ich fürchte, einfache Regeln tun's nicht, die Vandalen finden schnell Wege darum herum - z.B. mit dem beliebten asdfasdf. Und alle bekannten Wörter abzugleichen, das würde auf eine Online-Rechtschreibkontrolle aller IP-Edits hinauslaufen; haben wir dafür genug Rechenleistung? Wenn es eine Möglichkeit gibt, das ohne wesentliche Entschleunigung der WP zu implementieren, wäre ich sofort dafür. (Mit den angemeldeten Vandalen wird man wohl leben müssen.) Gruß --Idler ∀ 12:28, 9. Dez 2005 (CET)
- Die Frage ist, wie sehr sich die Vandalen wirklich anstrengen, Vandalismus anzurichten. Man könnte auch bei jemandem, der wegen zrtzrtz rausgeflogen ist, ein Cookie setzen, sodass er anschließend immer wieder rausfliegt, egal was er schreibt. Ich habe selbst mal ein Forum betrieben, das oft von Störern heimgesucht wurde. Wenn ich einen Benutzernamen gesperrt hatte, haben sie unter einem anderen Namen weiter gestört. Bis ich die Sache mit den Cookies programmiert hatte, dann war Schluss. Es hat drei Jahre gedauert, bis einer (und sonst keiner!) meinen Trick durchschaut hatte. --Plenz 13:36, 9. Dez 2005 (CET)
- Security by obscurity... nun ja. Trolle wird man nicht fernhalten können, die besten Chancen sollte man bei "Ersttätern" haben. Eine Blacklist mit Fäkalausdrücken u.ä. könnte da halbwegs funktionieren, genau wie ein Verbot, ganze Artikel zu leeren. Tastaturtests sind einfach viel zu selten. Das größte Problem sind solche Edits, und gegen die hilft keine automatisierte Lösung.--Gunther 13:53, 9. Dez 2005 (CET)
-
-
- Selten? Gerade vorhin schon wieder vorgekommen... --Plenz 00:33, 10. Dez 2005 (CET)
- Hm, was belegt das? Einer von hunderten heute...--Gunther 00:52, 10. Dez 2005 (CET)
- Selten? Gerade vorhin schon wieder vorgekommen... --Plenz 00:33, 10. Dez 2005 (CET)
-
Eine automatische Filterung, die das abspeichern verhindert, halte ich für sehr bedenklich. Es wird immer mal zu einer Fehlauslösung der Sperre kommen, die dann auf normale Bearbeiter abschreckend wirkt. Es sollte aber möglich sein, mit einem Filter eine Liste von Änderungen mit Vandalismusverdacht zu erzeugen, die das Auffinden von Vandalismus erleichtert.-- StefanL 03:04, 12. Dez 2005 (CET)
[Bearbeiten] Automatische Vandalensperre II
Wo ich das hier grad sehe, wollte ich mal eine andere Idee kundtun die ich kürzlich hatte:
Wie wäre es wenn die Software IPs und Benutzer automatisch für einen kurzen Zeitraum sperrt, wenn "seine" Beiträge zu oft in zu kurzer Zeit reverted werden.
Ich weiß nicht ob das technisch machbar ist und inwieweit dies die Server (noch mehr) belastet; ist halt nur so ein Gedanke.
Im einzelnen würde ich mir das in etwa so vorstellen. Ein Stück Software das folgenden macht:
- Bei folgenden Vorgängen beginnt eine Überprüfung
- Ein Admin betätigt sein Revert Knöpchen
- oder ein normaler User (angemeldet) schreibt in den Bearbeitungskommentar den string revert
- Überprüfe ob der revertende Benutzer (also der, der den Vandalismus entfernt) mindestens, sagen wir mal 1000 Edits hat. Dies um zu verhindern, dass Vandalen mit diesem "Werkzeug" gutwillige Benutzer sperren können.
- Falls ja, vergleiche die neue Version mit der des vor-vor-letzen Bearbeiters
- Falls dies indentisch ist (also es ein wirklicher kompletter Revert war), mache einen neuen Eintrag auf einer neuen noch zu erzeugenden Datenbanktabelle, die die Zeiten der Reverts pro Benutzer oder IP enthält (also des vermeintlichen Vandalen)
- Überprüfe in dieser Tabelle die Anzahl der Reverts z.B. in den letzen 2 Stunden.
- Sind diese größer/gleich z.B. 3
- Sperre den Benutzer oder die IP für z.B. 1 Stunde
- Hinterlasse dem Benutzer/IP eine automatische Nachricht auf seiner Disku-Seite
- Protokoliere den Vorgang in den Logbüchern und evtl auch auf der Vandalensperrseite
- Evtl. könnte die Software dies bei Wiederholungstätern nach und nach auch immer längere Sperrzeiträume verhängen und z.B. nach der 10ten Sperre innerhalb von 4 Wochen zur dauerhaften Sperrung vorschlagen.
Dies hätte allerdings auch einen Effekt bei Edit-Wars denn falls sich da 2 Benutzer immer mit dem Vermerk revert gegenseitig reverten, sind beide recht schnell blockiert, und bekommen so eine Denkpause.
Was haltet Ihr davon? --Jutta234 Talk 02:36, 9. Dez 2005 (CET)
- Eine automatische Sperre spart nicht viel Arbeit, und manchmal will man vielleicht wirklich mehrere Beiträge eines Benutzers rückgängig machen, ohne dass dieser gleich gesperrt werden müsste.
- Anderer Vorschlag: ein Knopf "rollback für alle Beiträge dieses Benutzers" auf der Sperrseite.--Gunther 02:50, 9. Dez 2005 (CET)
-
- '"Rollback für alle Beiträge dieses Benutzers" kann aber bei dynamischer IP auch sinnvolle Beiträge eines anderen Benutzers löschen, dem diese IP vorher zugeordnet war. Wäre evtl. eine Aufstellung möglich (so wie bei der Wiederherstellung gelöschter Versionen), bei der die zu revertierenden Edits markiert werden? Gruß --Idler ∀ 12:35, 9. Dez 2005 (CET)
- Ein Klick pro Bearbeitung gibt es ja jetzt schon. Dynamische IPs haben eigentlich (noch) i.d.R. keine Überschneidungen. Aber so groß wäre der Vorteil nicht, dass sich ein feature request lohnen würde.--Gunther 12:43, 9. Dez 2005 (CET)
- Doch, es gibt inzwischen sehr viele dynamische IPs mit Überschneidungen (wenn du damit meinst, dass z.B. erst ein konstruktiver Benutzer und dann ein Vandale unter derselben IP unterwegs waren).
- Ich bin gegen diese Regelung - ein solcher Automatismus ist nie gut! (vgl. das Meinungsbild "Three strikes and you are out", ist so ziemlich das gleiche wie hier). --rdb? 00:57, 10. Dez 2005 (CET)
- Ein Klick pro Bearbeitung gibt es ja jetzt schon. Dynamische IPs haben eigentlich (noch) i.d.R. keine Überschneidungen. Aber so groß wäre der Vorteil nicht, dass sich ein feature request lohnen würde.--Gunther 12:43, 9. Dez 2005 (CET)
- '"Rollback für alle Beiträge dieses Benutzers" kann aber bei dynamischer IP auch sinnvolle Beiträge eines anderen Benutzers löschen, dem diese IP vorher zugeordnet war. Wäre evtl. eine Aufstellung möglich (so wie bei der Wiederherstellung gelöschter Versionen), bei der die zu revertierenden Edits markiert werden? Gruß --Idler ∀ 12:35, 9. Dez 2005 (CET)
[Bearbeiten] diff-darstellung
Hallo, könnten wir nicht vielleicht im diff auch rot und fett, so wie in der enWP, haben? --Stefan-Xp 10:11, 10. Dez 2005 (CET)
[Bearbeiten] Umgehung von IP-Sperren durch Benutzer
Ist es möglich, dass ein Benutzer nach Kandidatur ein Flag erhält, womit er auch unter gesperrtenIPs editieren kann?? Dark Lord Klever Battle
[Bearbeiten] 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:
[Bearbeiten] 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:CurrywurstBenutzer:84.58.132.80 - Dagegen: ChristianErtl
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
Dagegen:
[Bearbeiten] 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. [11]
<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. [12] 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)
- Dafür: ISBN
- Dagegen: net, Habakuk <><
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
- auf diese Weise einfach sichergestellt werden kann, dass nur Administratoren Links freischalten können, und
- 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)
[Bearbeiten] Blockquote
Ich lese gerade ... ich hätte hierhin posten müssen. Seis drum, ich verweise einfach mal auf den Artikel in Verbesserungsvorschläge: [13]--Richardigel 14:36, 16. Feb 2006 (CET)
[Bearbeiten] 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
[Bearbeiten] Metainfo in Sprachennamen
Auch ich merke gerade, daß ich hierher hätte posten sollen und verweise auf Wikipedia:Verbesserungsvorschläge#Kleine kosmetische Änderung. Wikipeditor
[Bearbeiten] Wunsch nach Spezialseite:Weiterleitung
siehe bitte Hilfe_Diskussion:Weiterleitung#Spezialseite --Emgo 12:39, 1. Mär 2006 (CET)
[Bearbeiten] 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)
-
- dafür: Diwas 18:42, 24. Mär. 2007 (CET)
-
- dafür:
- dagegen:
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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
[Bearbeiten] 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)
[Bearbeiten] 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.
[Bearbeiten] 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.
[Bearbeiten] Nachteile
- Zusätzliche Funktionalität --> Komplexität nimmt zu
- Aufwand
- 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)
- 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)
[Bearbeiten] 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)
[Bearbeiten] 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: [14]. Geht doch bestimmt auch geschickter, oder? igel+- 10:53, 19. Jun 2006 (CEST)
[Bearbeiten] 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 ...
- 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)
-
-
-
-
- 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)
-
-
[Bearbeiten] 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.
[Bearbeiten] 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)
[Bearbeiten] 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)
- 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)
- Find ich auch. Andererseits wäre dann auch dein "•λ•" nicht mehr möglich. -- sebmol ? ! 12:18, 8. Jul 2006 (CEST)
-
[Bearbeiten] "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:
- 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.
- 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:
- ob meine darstellung der situation überhaupt korrekt ist, oder ich irgendwelche einstellungen vornehmen kann, um dieses zu ändern.
- 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
- 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)
-
[Bearbeiten] 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)
[Bearbeiten] 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)
- 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)
[Bearbeiten] 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 (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)
- 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] editcounter
moin moin, kolleginnen und kollegen
ich habe folgende probleme:
- 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.
- 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
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)
[Bearbeiten] 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%9Cberschriftensimulation_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)
[Bearbeiten] 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/unsigned.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:unsigned). Danke für die (unterstützende) Werbung Spongo, schade aber, dass dieses bei Dir deaktiviert ist [15]. 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)
[Bearbeiten] 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)
- Contra 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)
[Bearbeiten] 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.
-
[Bearbeiten] 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)
[Bearbeiten] „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)
[Bearbeiten] 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:
- Vorlage:Spielwiese
- Wikipedia:Spielwiese
- Benutzer:Neu
- Benutzer:Älter/Spielwiese
- Artikel)
--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
Contra andere Darstellung von über Vorlagen verlinkte Seiten
[Bearbeiten] 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)
[Bearbeiten] 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)
- lesen hier einklich irgendwelche Entwickler? Oder ist das eine WORN-Seite? -- Smial 13:35, 7. Nov. 2006 (CET)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] Auch unter Werkzeuge
Ein Verlinkung von jedem Artikel auf das Logbuch. Das wäre auch für die Vorlage bei nicht vorhandenen Artikeln sinnvoll, siehe Benutzer:Thiemo Mättig/Vorlage:MediaWiki Newarticletext NS (bzw. die Diskussion). Andererseits ist das Logbuch in anderen Vorlagen überhaupt nicht verlinkt (wahrscheinlich in jedem anderen Namespace). -- Amtiss, SNAFU ? 13:20, 8. Sep 2006 (CEST)
[Bearbeiten] Zwangs-Subst-Parameter für Vorlagen
Einige Vorlagen sind strukturell für den 'Subst:-Einsatz' gemacht (z.B. {{Hallo}}, {{Unsigned}}, etc.). Nur wird dies regelmäßig vergessen oder ist sogar bei manchen Teilnehmern gar nicht bekannt, wodurch u.a. eine ständige Serverlast erzeugt wird. Wäre es nicht sinnvoll, einer Vorlage eine Anweisung hinzuzufügen, dass diese bei jedem Einsatz auch ohne {{Sunbst:Vorlage}} 'zwangsweise' ersetzt wird? Habe auf Bugzilla keinen derartigen Vorschlag finden können, er macht jedoch hinsichtlich Benutzbarkeit und Ressourcenschonung IMHO Sinn... --NB > ?! > +/- 12:44, 8. Sep 2006 (CEST)
- Zum Thema Ressourcenschonung: Brion hat sich schon mehrfach dahingehend geäußert, dass sich die Projekte um so etwas nicht kümmern sollen. Die Entwickler sehen es als ihre Aufgabe, die Software und Hardware den Bedürfnissen der Projekte anzupassen, nicht umgekehrt.
- Zum Thema Benutzbarkeit: Es ist möglich Vorlagen so zu programmieren, dass sie eine Fehlermeldung ausgeben, wenn sie nicht mit subst: eingebunden werden. -- sebmol ? ! 12:54, 8. Sep 2006 (CEST)
- Hallo Sebmol, danke für die schnelle Antwort!
- Aber die Entwickler haben doch noch keine Gedanken lesende Software in der Mache, oder? ;-) - Irgendeinen Hinweis werden auch zukünftige Versionen benötigen, um die Benutzer-Intention bei Vorlagen zu erkennen, damit die Entwickler die Software entsprechend auslegen können...
- Hast Du mal ein Beispiel (bevor ich hier erst noch durch alle Handbücher fräse)? Wobei die Fehlermeldung ja auch nur dann hilft, wenn alle Benutzer immer brav die Vorschau benutzen - und dafür willst Du bestimmt nicht deinen Kopf hinhalten, oder? ;-)
- --NB > ?! > +/- 13:19, 8. Sep 2006 (CEST)
- Tatsächlich ist die Überprüfung ein ekliger Hack. Also, schau mal auf Benutzer:Sebmol/Vorlagenspielwiese. Wenn das mit subst: eingebunden wird, steht da "SUBST BENUTZT", wenn nicht dann "SUBST NICHT BENUTZT". Damit kann also zwischen den Einbindungsmöglichkeiten unterschieden und ggf. eine Warnung ausgegeben werden. Das ist vielleicht nicht ideal, sollte aber ausreichen. Zum Thema Vorschau: selbst wenn sie die Vorschau nicht benutzt haben, sehen sie ja danach, dass subst: vergessen wurde, können es also nachträglich noch ändern. -- sebmol ? ! 11:59, 12. Sep 2006 (CEST)
- Danke! Wobei meine Definition von 'eklig' eindeutig eine andere ist, das ist doch noch 'elegant'... ;-) --NB > ?! > +/- 12:56, 12. Sep 2006 (CEST)
- Tja, so 'einfach' klappt es leider bei Parameter-Vorlagen nicht - was also spricht genau gegen einen Vorlagenmarker, der ohne programmtechnische Klimmzüge jedem die Zwangssubstituierung von Vorlagen erlaubt. Bedarf besteht dafür jedenfalls, wenn ich mir die Kategorie:nur Subst anschaue (zumal dieses Problem sicher nicht nur in der de:wp existiert) - und die Programmierer doch dem Volk auf die Tastatur schauen wollen... --NB > ?! > +/- 13:26, 12. Sep 2006 (CEST)
- 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)
- Wenn man diese Diskussion liest, erscheint mir mein Vorschlag sogar sehr begründet... ;-) --NB > ?! > +/- 11:41, 13. Sep 2006 (CEST)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] SVG wird von der Software zu PNG konvertiert
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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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
[Bearbeiten] 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!
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] Barrierefreies Webdesign
Für behinderte Menschen sind die Schaltflächen wie "Artikel" und "Suche" nur schwer zu bedienen. Dies lässt sich mit dem Tool http://wave.webaim.org/ auch überprüfen. Gruß Christian., 22. Okt. 2006.
[Bearbeiten] 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)
[Bearbeiten] 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(Der vorstehende, nicht signierte Beitrag stammt von Pens.ar (Diskussion • Beiträge) igel+- 11:52, 10. Nov. 2006 (CET))
- 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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)
[Bearbeiten] 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? ch halte an dem Vorschlag fest! --Στέφανος (Stefan) ± ■ 22:37, 17. Jan. 2007 (CET)
[Bearbeiten] 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)
[Bearbeiten] Kategorie in Redirects
nun gibt es das problem, dass im artikel nicht mehr über die kategorien navigiert werden kann, dazu müsste man auf die zeile unter der überschrift klicksen, um direkt im redir zu landen. daher wäre es sehr hilfreich, wenn die kategorien der weiterleitung auch im zielartikel aufscheinen. zb Schnitzen
- die zeile „weitergeleitet“ erscheint auch unten bei den kats
- Kategorien: Holzverarbeitung ..
- Kategorien der Weiterleitung siehe: Holzschnitzer - mit redirect=no, das liesse sich wohl auch per CSS erledigen, erfordert aber den zusätzlichen klick
- die kategorien werden mit in den artikel übernommen (fernziel wäre natürlich eine aufsummierung aller weiterleitung im sinne eines „in diesem artikel werden folgende schlagworte zusätzlich behandelt“)
- Schnitzen: Kategorien: Holzverarbeitung .. - also mit {PAGENAME} davor
- Holzschnitzer: Kategorien: Handwerksberuf .. mit dem referrer-titel
- manuell eingepflegen - dazu müsste es dann eine ungekehrte variante des <NOINCLUDE> geben, damit jetzt der artikel nicht kategorisiert wird, sondern nur angezeigt wird, etwa <REDIRKAT>Kategorie:Handwerksberuf</REDIRKAT> oder könnte das eine Vorlage {Redirkat|Holzschnitzer|Handwerksberuf|..} leisten?
- automatisch einbinden - der quellcode des redirects muss sowieso ausgelesen werden, also könnten die kats ohne sonderliche serverarbeit zwischengespeichert und automatisch angezeigt werden, was aber softwareseitig wenig sinn macht, wenn es sich nur um schreibvarianten handelt, und zwei „arten“ von redirs einführen, ist wohl auch sinnlos - andrerseits, reine schreibvarianten sind wohl kaum kategorisiert, und unkategorisierte redirs können dann ausgeblendet werden
-- W!B: 05:36, 8. Jan. 2007 (CET)
[Bearbeiten] das Feld "Zusammenfassung und Quellen"
Als User kann man einstellen dass man gewarnt wird wenn man das Feld leer lässt. Dies ist eigentlich nützlich. Könnte man das nicht für alle IP's und für neuen User als Standard setzen?
Außerdem wäre es besser wenn man das Häkchen getrennt für Artikel und Disk Seiten setzen könnte. Das eine Default-mäßig an das andere aus.
(Ich habe das gleiche schon auf FZW und VV vorgeschlagen, jedoch ohne Reaktion) --Steffen2 20:21, 8. Jan. 2007 (CET)
[Bearbeiten] Beim Ausführen von SLA...
...bekommt man einen Text angezeigt: Dieser Artikel hat eine Versionsgeschichte, dann ein Link darauf. Praktisch wäre, wenn die Anzahl der Versionen angezeigt werden könnte. Damit würde vermieden, dass vandalierte und dann irrtümlich mit {{löschen}} versehene Artikel gelöscht werden. Natürlich sollte man das ohnehin überprüfen, aber das dauert eben... Wenn das nicht zuviel Arbeit wäre also eine gute Sache --schlendrian •λ• 11:33, 9. Jan. 2007 (CET)
[Bearbeiten] E-Mail Benachrichtigung
Hallo bin ich hier richtig? Wäre es nicht schön eine E-Mail Benachrichtigung zu bekommen, wenn sich an einem speziellen Artikel (an dem man sehr interessiert ist) etwas geändert hat? Grüße --LBRH 19:48, 13. Jan. 2007 (CET)
- Sollte nicht so problematisch sein, ist auf den Commons bereits aktiv und funktioniert super. Hab aber keine Ahnung, ob das bei einer Wikipedia die Server mitmachen. --Flominator 20:13, 13. Jan. 2007 (CET)
-
- Macht auf jeden Fall Sinn. Für die Admins .Die könnten sich die Wikipedia in "Destrikte aufteilen" - dann weitere Bezirke (und für die wiederum zuständige Admins ernennen) usw.... Wenn in jeweiligen Zuständigkeitsbereich gearbeitet wird gibt es eine Benachrichtigung. Wäre auch ne Art von Qualitätssicherungssystem. Aber das machen die bestimmt schon oder? Grüße --LBRH20:24, 13. Jan. 2007 (CET)
-
-
-
- Danke CyRoXX/Flominator ! Grüße --LBRH 22:38, 13. Jan. 2007 (CET)
-
-
[Bearbeiten] Leute lasst uns WikiQuiz spielen !
Jeder der mitspielen möchte baut in einen/mehreren Artikel(n) seiner Wahl folgenden Baustein ein:
Beispiel: Artikel Boris Becker
{WikiQuiz:nodisplay
|frage-schwierig=2|Wann wurde Borris Becker Wimbledon Sieger?
|antwort-n|1968
|antwort-r|1985
|antwort-n|1990
}
Die Frage sollte möglichst leicht zu beantworten sein, und drei Antworten zur Auswahl geben. Der Baustein befindet sich im Artikel und wird nicht angezeigt, damit das Layout nicht leidet. Auf der Hauptseite plazieren wir das WikiQuiz Feld mit der Frage und den möglichen Antworten. Das Spielen erfolgt mittels anklickbaren Checkboxen. 500000 mögliche Fragen von einem Script per Zufall erstellt das ist schon was, oder? Wo gibt es sowas sonst? Wie wärs mit einer Rangliste, einsetzbaren Joker.....und .....und..... Das Quiz spricht sich rum => mehr Traffic => mehr Sponsoren......
Grüße an alle: --LBRH 16:37, 16. Jan. 2007 (CET)
- ganz sicher wird dafür nicht der Artikel-Quelltext mit dem Baustein aufgeblasen --schlendrian •λ• 17:59, 17. Jan. 2007 (CET)
- Ich finde die Vorteile überwiegen, oder? --LBRH 18:43, 17. Jan. 2007 (CET)
Unnötige Spielerei. --Στέφανος (Stefan) ± ■ 18:45, 17. Jan. 2007 (CET)
[Bearbeiten] dvd update
Da die Wiki-DVD immer umfangreicher wird, wäre eine update-version sinnvoll: nur neue oder veränderte daten werden nachgeladen (inkrementeller zuwachs) - das würde möglicherweise einen neuen zeno-reader bedingen.
[Bearbeiten] Lizenzen in der Versionsgeschichte
Da ja viele Autoren, ich auch, ihre Beiträge nicht nur unter der GFDL, sondern auch anderen Lizenzen freigeben, und das besonders für WEiternutzer interessant ist, wäre es ja praktisch, das gleich in der Versionsliste sichtbar zu machen. So könnte man beispielsweise in den Einstellungen eine Zusatzlizenz angeben, die dann automatisch in der Versionsgeschichte agezeigt wird:
- 20:05, 24. Jan. 2007 Benutzer (Diskussion | Beiträge | CC-BY-SA) K typo
- 20:03, 24. Jan. 2007 Name (Diskussion | Beiträge)
- 20:00, 24. Jan. 2007 Blabla (Diskussion | Beiträge | FWL) Kommentar
- 19:35, 24. Jan. 2007 NickiBot (Diskussion | Beiträge | PD) K interwiki
- 14:10, 20. Jan. 2007 ≈ (Diskussion | Beiträge | Lizenziert) Schlimme Fehler entf.
„Lizenziert“ würde bedeuten, dass ein Benutzer beispielsweise mehr zwei oder mehr zusätzliche Lizenzen benutzt und diese alle auf einer eigenen Seite sammelt und kommentiert. Die Links zu den WP-Artikel sollten durch solche auf spezielle Hinweisseiten oder Bausteine ersetzt werden. Einfacher als diese m. E. eleganteste Lösung wäre vermutlich eine automatisierte Hinzufügung des Lizenzlinks zur Zusammenfassung.--Hannes2 Diskussion 18:37, 1. Feb. 2007 (CET)
- Nein, das halte ich für keine gute Idee. Es ist grundsätzlich sogar fraglich, ob manche Lizenzen einfach inkompatibel mit GNU-FDL sind (Näheres weiß ich dazu nicht), außerdem würde es ein riesiges Chaos verursachen, da verschiedene Bearbeitungen eines Artikels teilweise unter verschiedenen Versionen vorlägen, wobei ja nur die hinzugefügten Teile eine andere Lizenz hätten … Grüße, — Pill δ 12:03, 22. Feb. 2007 (CET)
[Bearbeiten] Assoziationsvorschläge und Schnittmengensuche
könnte man nicht, ähnlich wie bei amazon, eine Funktion einbauen ala ?wenn sie das hier mögen, könnte ihnen auch das hier gefallen? Eine Assoziationsfunktion auf Grundlage der bisherigen Seitenaufrufe bisheriger Nutzer?
und noch einen: Gibt es eine Möglichkeit die Suche auf eine Untergruppe einzuschränken? Was großartig wäre, wenn man irgendwie aus Gruppen Schnittmengen bilden könnte: Beispielsweise: Suchbegriff: "Daniel"...zeige alle gemeinsamen Artikel der Gruppe: Drogendealer und Schauspieler. Das wäre doch was.
[Bearbeiten] TOC automatisch einklappen u.Ä. TOC
auf WP:VV#TOC automatisch einklappen u.Ä. habe ich schon eine Diskussion angefangen. vielleicht war das der falsche platz. Deshalb stelle ich das jetzt noch hier herein! --Marci Diss. 13:52, 14. Feb. 2007 (CET)
[Bearbeiten] Versionsvergleich genauer dargestellt
Teilweise werden nichtpassende Absätze miteinander verglichen und der passende Absatz erscheint dann darunter. Wenn z.B. ein Absatz eingefügt wurde. Dies sollte die Software erkennen. Wahrscheinlich ist der beste Weg nach dem jetzigen Vergleich für sehr "rote" Texte zu prüfen ob nicht der darüber oder der darunterstehende besser passt. Passen zwei ein wenig dann ist es wahrscheinlich eine Aufteilung. Dann sollte der Absatz der z.B. aufgeteilt wurde (gekennzeichnet) zweimal dargestellt werden. --Diwas 05:05, 18. Feb. 2007 (CET)
dafür:W!B: - WinMerge etwa ist ein OpenSource-Projekt, dass genau diese option bietet, falls ein algorithmus noch gesucht wird- ich find, einer der nettesten differ am markt..
dagegen:
Falls das automatisch nicht geht, dann sollte man die Zuordnung manuell (temporär) machen können. --Diwas 05:05, 18. Feb. 2007 (CET)
[Bearbeiten] Versionen vorschlagen, bewerten und verzögert aktivieren (Effizienz und Qualität der Wikipedia verbessern)
Ziele: - weniger Versionen, also übersichtlicher und weniger Speicherplatz und schnellere Recherche in Versionen - bessere Qualität der Artikel - bessere und komfortablere Zusammenarbeit
(Edit: Da es auch um das Verfahren geht und weil hier eher wenig Traffic ist, habe ich eine allgemeinere einfachere Formulierung des Vorschlags in Wikipedia:Verbesserungsvorschläge#Effizienz und Qualität der Wikipedia verbessern: neue Versionen werden nicht sofort zur aktuellen Version gestellt. --Diwas 20:31, 22. Feb. 2007 (CET)
Vorschlag: Wenn jemand einen Artikel bearbeitet, dann wird der nicht sofort als aktuell gespeichert, sondern als vorgeschlagene Version. Der Autor selbst und andere Autoren können die Version weiterbearbeiten, oder aber (bei Nichtgefallen der vorgeschlagene Version) die aktuelle Version bearbeiten. Die vorgeschlagenen Versionen erscheinen temporär gekennzeichnet in der Versionsgeschichte (wenn in benutzereinstellungen gewählt) Startet jemand eine Bearbeitung, wird ihm eine Liste der aktuellen und der vorgeschlagenen Versionen dieses Artikels angezeigt (wie Versionsgeschichte) sowie Bewerter, Bewertung, Kommentare. Die Änderung (nicht der Artikel) können von Angemeldeten und dauerhaft registrierten IP bewertet werden. Bewertungsstufen: -- falsch, ganz schlecht, Vandalismus, - aktuelle Version beibehalten weil besser, o egal, + besser als aktuelle Version, ++ unbedingt neue Version übernehmen. Kommentare können von allen abgegeben werden. Es kann maximal drei parallele temporäre Versionen/Versionsgeschichten geben.
Die Erstellung selbst ist schon eine Positive Bewertung ++, daraus folgt: ohne weitere Bewertung wird die Version nach Ablauf automatisch aktuell. Der Autor darf als angemeldeter Benutzer oder dauerhaft registrierte IP nach frühestens 20 h die Version einmalig nochmal zusätzlich bewerten. Nichtangemeldete Benutzer können ein temporäres Passwort für einen Beitrag anfordern, dann können auch sie ihren eigenen Beitrag noch einmal zusätzlich bewerten oder auch löschen. Der Autor, kann also bis zu 4 + vergeben. Es kann also einen bis zwei Benutzer erfordern um den Beitrag zu stoppen. Bewertungen können jederzeit revidiert werden. Versionen können vom Autor gelöscht werden, wenn darauf noch keine neueren Versionen aufsetzen. Da die Bewertungen im Versionvergleich erfolgen, sind sie immer relativ, so ergibt sich bei zwei gleich gut gegenüber der aktuellen Version bewerteten Versionen die Entscheidung welche als aktuell gespeichert wird.
bei Bearbeitung vom Autor einstellbare Optionen: Verzugszeit : von 30 bis 200 Stunden, je nachdem wie dringend und wie sicher die Bearbeitung und wie intensiv der Artikel gepflegt wird. In wenig beobachteten Artikeln kann die Zeit nicht kürzer als 70 Stunden sein, in stark beobachteten nicht länger als 100 stunden Verkürzung bei positiver Bewertung auf: 30 bis 100 Stunden. In wenig beobachteten Artikeln kann die Zeit nicht kürzer als 50 Stunden sein, in stark beobachteten nicht länger als 50 stunden Bei positiver Bewertung kann die Verzögerung automatisch verkürzt werden. Bei negativer Bewertung wird die Verzugszeit verlängert. Vorschlag: Der Autor kann seine Version als Vorschlag kennzeichnen. Diese Version wird niemals aktuell und erscheint nicht in der Versionsgeschichte. Andere können aber auf diese Version aufsetzen (ggf.unverändert speichern) und werden so zum Autor. (Man könnte noch überlegen, ob es Optionen bzgl. der Nennung von "Vorschlagenden" geben soll, wenn ein Vorschlag weitergeführt wird.)
Wird auf eine Vorgeschlagene Version aufgesetzt, dessen Restverzugszeit kleiner 30 Stunden ist bekommt die neue Vorgeschlagene Version 30 Stunden Verzugszeit. Läuft die Verzugszeit für eine Version ab die derzeit die beste und eine positive Bewertung hat, so wird sie damit aktuelle Version. Nach Ablauf der Verzugszeit der jüngsten Bearbeitung wird die bestbewertete vorgeschlagenen Version automatisch gespeichert.Dabei werden für Zwischenversionen nur die Unterschiede dauerhaft gespeichert, der vollständige Quelltext wird nur von der neuen aktuellen Version gespeichert. Artikelanzeigeoptionen: Angezeigt wird die aktuelle Version. Existieren vorgeschlagene Versionen so wird dies als Hinweis bei Aufruf des Artikels angezeigt.Die Änderungen oder die geplanten Versionen können alternativ aufgerufen werden. Angemeldete können auch einstellen, daß standardmäßig die geplanten Versionen angezeigt werden. Auch eine Kennzeichnung von betroffenen Textstellen im Artikel (wahlweise) ist denkbar.
Es gibt Einstellungsmöglichkeiten, z.B. für Beobachtungsliste oder global oder nach Kategorien sich alle oder alle weniger gut bewerteten vorgeschlagenen Änderungen, nach Restzeit und Bewertungen anzeigen zu lassen, um sie durch eigene Bewertung Einflußzunehmen. Admins können löschen (z.B. bei URV oder eindeutigem Vandalismus) oder eine Version stoppen. Dann wird sie nicht aktuell, aber es können weitere Bearbeitungen darauf aufsetzen. Vorgeschlagene Versionen die nicht in die aktuelle Version münden, werden Normalerweise nicht in der Versionsgeschicht angezeigt. Wird ein Beitrag nicht aktuell, so kann der Autor den Vorschlag permanent als Vorschlag speichern, mit Bewertungen und Kommentaren. Vorgeschlagene Versionen die indirekt in die aktuelle Version münden, werden in der Versionsgeschichte ähnlich den Mehrfachänderungen in der Beobachtungsliste angezeigt. Wikiblame sollte angepasst werden, so dass die Zwischenversionen erstmal übersprungen werden.
Das ganze wird entsprechend auch auf Neuanlagen von Artikeln angewandt.
Die Software sollte so geschrieben werden, dass Variable wie Bewertungsalghoritmus und anderes ggf. ohne Softwareänderung optimiert werden kann.
Bots sollten die aktuelle sowie vorgeschlagene positiv bewertete Versionen bearbeiten. Dabei wird die bestehende Bewertung übernommen. --Diwas 01:05, 19. Feb. 2007 (CET)
- Hoi, das wäre viel zu viel Aufwand (sowohl für die Entwickler als auch für die Benutzer der Wikipedia). Ein ähnliches, vereinfachtes, Konzept zur Sicherung der Qualität ist allerdings mit den gesichteten (→) und geprüften Versionen (→) in Planung. Grüße, — Pill δ 11:30, 22. Feb. 2007 (CET)
- Für die Benutzer ist es insgesamt nicht mehr Aufwand, weil die Versionsgeschichte sauberer wird und sich viele Anträge und reverts erübrigen. Vorschau erübrigt sich, eine fehlerhafte Version kann vom Autor sofort überschrieben werden, ohne Spuren zu hinterlassen. Es ist erstmal etwas aufwändiger, eine Bearbeitung wirksam werden zu lassen, dass verringert aber Vandalismusbehebungsaufwand. Die Gesichteten Versionen sind eine sehr schwaches Mittel.siehe: Wikipedia:Verbesserungsvorschläge#Effizienz und Qualität der Wikipedia verbessern: neue Versionen werden nicht sofort zur aktuellen Version --Diwas 20:31, 22. Feb. 2007 (CET)
[Bearbeiten] Automatische Anpassung der Links beim verschieben (umbenennen) von Artikeln, Vorlagen und auch Bildern
Zur Zeit haben wir folgende Situation:
- wenn ein Artikel verschoben wird, entsteht ein Redirect unter dem alten Lemma. Es müssen manuell alle Links an das neue Lemma angepasst und dann das alte Lemma gelöscht werden.
- gleiches Problem bei den Vorlagen. Die Einbindungen "{{{...}}}" müssen manuell angepasst werden.
- Bilder kann man erst gar nicht verschieben. Ist unglücklicherweise ein unpassender Dateiname gewählt worden, lässt sich dieser nicht mehr ändern.
Mein Vorschlag wäre:
- wenn ein Artikel [[Alter Name]] nach [[Neuer Name]] verschoben (bzw. umbenannt wird) wird kein Redirect [[Alter Name]] mehr erzeugt, sondern automatisch alle Links [[Alter Name]] in [[Neuer Name|Alter Name]] geändert.
- analog bei den Vorlagen. Alle Einbindungen werden von {{Alter Name}} auf {{Neuer Name}} angepasst.
- Bilder (auch Videos, Tondateien, ...) soll man umbenennen dürfen. Automatisch werden alle Einbindungen [[Bild:Alter Name.png]] in [[Bild:Neuer Name.png]] geändert. --Florian Hurlbrink (Diskussion) (Babelbausteinzentrale) 18:29, 20. Feb. 2007 (CET)
- versteh ich nicht, wieso müssen alle links manuell angepasst werden? link auf redirect ist eh' kein problem, nötig wäre Dein vorschlag allenfalls beim löschen -- W!B: 19:23, 20. Feb. 2007 (CET)
- Es wäre eleganter, wenn alle Links direkt auf das neue Lemma zeigen anstatt auf ein Redirect. Zur Zeit entstehen bei jeder Verschiebung massenweise Redirects. --Florian Hurlbrink (Diskussion) (Babelbausteinzentrale) 18:50, 21. Feb. 2007 (CET)
- Und wie soll das realisiert werden? Soll nach jeder verschiebung ein Bot über die ganze Wikipedia laufen und nach verweisen auf die alte Seite schauen? Ne so kann das net gehen. Und wenn man sozusagen ein system einführt, das nach dem kategoriesystem funktioniert, so dass jede seite und jeder verweis auf eine Seite in einen art katogorie verschoben wird und man/der Bott dann nur diese Liste durchforsten muss; das würde gehen, allerdings finde ich das sehr aufwendig. Was haltet ihr davon, wenn man einfach die paaar bytes großen redirekts bestehen lässt, womit dann ja auch die links automatisch weitergeleitet werden und bei vorlagen wird automatisch der neue inhalt eingebunden! --Marci Diss. 20:53, 21. Feb. 2007 (CET)
- Die Liste gibt es doch: "Links auf diese seite" z.B. Spezial:Verweisliste/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests. Der Bot muß nur die Liste abarbeiten. Ich denke aber es gibt schlimmeres als Redirects. --Diwas 01:19, 22. Feb. 2007 (CET)
- Ich wusste nicht, dass es eine solche Liste gibt. Naja egal. Ich glaube es ist ein Bot nicht wert, nur für die verschiebung alle Links zu ändern. Allerdings könnte man einen Bot machen, oder einem anderen noch zusätzlich diese Aufgabe zuweisen, dass dieser bei einer Löschung der Seite mit einem Redirekt die Links auf die Seite ändert.
- Die Liste gibt es doch: "Links auf diese seite" z.B. Spezial:Verweisliste/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests. Der Bot muß nur die Liste abarbeiten. Ich denke aber es gibt schlimmeres als Redirects. --Diwas 01:19, 22. Feb. 2007 (CET)
- Und wie soll das realisiert werden? Soll nach jeder verschiebung ein Bot über die ganze Wikipedia laufen und nach verweisen auf die alte Seite schauen? Ne so kann das net gehen. Und wenn man sozusagen ein system einführt, das nach dem kategoriesystem funktioniert, so dass jede seite und jeder verweis auf eine Seite in einen art katogorie verschoben wird und man/der Bott dann nur diese Liste durchforsten muss; das würde gehen, allerdings finde ich das sehr aufwendig. Was haltet ihr davon, wenn man einfach die paaar bytes großen redirekts bestehen lässt, womit dann ja auch die links automatisch weitergeleitet werden und bei vorlagen wird automatisch der neue inhalt eingebunden! --Marci Diss. 20:53, 21. Feb. 2007 (CET)
- Es wäre eleganter, wenn alle Links direkt auf das neue Lemma zeigen anstatt auf ein Redirect. Zur Zeit entstehen bei jeder Verschiebung massenweise Redirects. --Florian Hurlbrink (Diskussion) (Babelbausteinzentrale) 18:50, 21. Feb. 2007 (CET)
Hallo, die automatische Änderung der auf die verschobene zeigenden Links würde mit einem Bot oder Ähnlichem natürlich hohen Traffic verursachen, da ja teilweise Seiten verschoben werden, die von sehr vielen anderen Seiten verlinkt sind. Ein Vorteil dieser Redirectlösung ist beispielsweise, dass auswärtige Links von anderen Websites immer noch funktionieren, ebenso verhält es sich mit nichtverlinkten Nennungen einer Seite. Zu der anfangs angeführten Problematik mit der Verschiebung von Bild- und anderen Dateien, siehe Bug 709, ein solches Feature soll schon eingebaut werden, es ist technisch allerdings wohl aufwändig. Zum letzten Kommentar: Nun ja, wenn ein Administrator eine Redirectseite löscht, muss er eigentlich die Links auf den darauf verweisenden Seiten ändern; wenn es sich um viele handelt, kann er ja einen Botbetreiber damit beauftragen (auch noch nach der Löschung), das ist nicht sonderlich schwierig. Grüße, — Pill δ 11:25, 22. Feb. 2007 (CET)
das zu automatisieren ist unmöglich. Woher soll ein BOT wissen welche Links er umbiegen darf und welche nicht. Oft werden Artikel verschoben um Platz für eine BKL zu machen. Da muss man dann sowieso von Hand jeden einzelnen richtig verbiegen. --Steffen2 11:48, 25. Feb. 2007 (CET)
- Also woher der Bot das wissen soll ist ganz einfach. er "schaut" in der passenden liste zu dem verschobenen Artikel nach den Seiten, auf denen ein Link ist ( Spezial:Verweisliste/Seite ). Danch durchsucht er diese Seiten nach der Adresse des verschobenen artikels und ersetz dieses duch den neuen link. allerding finde ich, dass das einen Zu hohen Traffic verursacht und nur bei Seiten mit einen entstandenen Redirect gemacht werden soll, der überhaupt nicht passt. Ansonsten finde ich es gar kein Problem den Redirekt da stehen zu lassen. Und bei Bilder u.Ä. steht oben schon eine Antowrt. --Marci Diss. 14:16, 26. Feb. 2007 (CET)
-
- und genau das ist falsch, da die Links oft auf den falschen Artikel zeigen (bei der BKL-Artikeln). Beispiel: [17] Da muss man regelmäßig von Hand aufräumen, das kann NIE ein Bot erledigen. --Steffen2 21:42, 26. Feb. 2007 (CET)
- und wenn der Bot da nichts findet wird er auch nichts ersetzen! So einfach ist das. Das wird der hächstens in die Log reinschreiben, dass man weiß, dass da was net klappt. Du unterschätzt Bots! Mann kann denen einfach sagen dass der den Links folgen soll, z.b. über quelltextabschnitte oder frames oder so und dann dort eine vestimmte zeichenfolge suchen und diese ersetzen soll. das klappt 95%. ein bug kann immer einmal drin sein! --Marci Diss. 21:16, 27. Feb. 2007 (CET)
- und genau das ist falsch, da die Links oft auf den falschen Artikel zeigen (bei der BKL-Artikeln). Beispiel: [17] Da muss man regelmäßig von Hand aufräumen, das kann NIE ein Bot erledigen. --Steffen2 21:42, 26. Feb. 2007 (CET)
[Bearbeiten] Link zur Bearbeitung eines Abschnitts
Moin ! Die kleinen [Bearbeiten]-Links zur Abschnittsbearbeitung landen beim IE7 (ob's bei Vorgängerversionen genauso ist, weiß ich nicht) immer am rechten Seitenrand und etwas unterhalb des Abschnittstitels - und damit oft genau in der ersten Zeile des folgenden Textabschnitts, wenn die sich über die gesamte Breite erstreckt. Das sieht irgendwie nicht so toll aus. Beim Firefox landet der Link dagegen direkt neben dem Abschnittstitel !? Ok, klarer Fall von unterschiedlicher CSS-Interpretation der Browser, aber ein bißchen einheitlicher müßte man es schon hinbekommen können, oder ? -- 62.180.198.58 20:04, 22. Feb. 2007 (CET)
- Bei Einstellungen kann man einstellen, wo der Link angezeigt werden soll. Probier mal, ob es dann klappt. (Der vorstehende, nicht signierte Beitrag stammt von MarciS (Diskussion • Beiträge) — Pill δ 13:11, 24. Feb. 2007 (CET))
- Hoi, der Benutzer ist nicht angemeldet und hat somit auch keine persönlichen Einstellungen zur Verfügung. Außerdem kann die Position der Links ohnehin nicht in den Einstellungen geändert werden, sondern nur im Monobook (→), das wiederum ausschließlich angemeldeten Benutzern zur Verfügung steht. Ich habe bzgl. des Problemes einen anderen Benutzer von IE7 gefragt, der sagte, die Links seien zwar unter der Überschrift, es gebe aber keine Überschneidungen. Eventuell kannst du ja einen Screenshot machen. Grüße, — Pill δ 13:11, 24. Feb. 2007 (CET)
- Des mit dem net angemeldetem Benutzer hab ich übersehen. Aber ich hab vor nem Monat oder 2 meine einstllungen geändert und danch hats des rechts angezeigt. vlt ham die des einfach rausgenommen.
- Moin. Textüberlappung liegt nicht vor, der zwangsweise Umbruch sieht allerdings doof genug aus. Wie ich bei weiteren Recherchen in den Tiefen der Wikipedia gelernt habe, ist das Skript MediaWiki:Monobook.js, das offenbar standardmäßig bei allen nicht angemeldeten Benutzern in Aktion tritt, für die Umpositionierung der Links zuständig. Normalerweise müßten diese bei nichtregistrierten Benutzern direkt neben der Überschrift landen (was bei Firefox offensichlich auch funktioniert), könnte also ein IE7-spezifisches Problem sein. Hab' mich mal auf der Diskussionseite des Benutzers verewigt, der wohl diesen Teil des Skripts geschrieben hat, bis jetzt gab's allerdings noch keine Reaktion. Im Prinzip ist die Angelegenheit damit hier wohl auch fehl am Platz, bitte dies zu entschuldigen. ;-) 62.180.198.21 10:19, 25. Feb. 2007 (CET)
- Des mit dem net angemeldetem Benutzer hab ich übersehen. Aber ich hab vor nem Monat oder 2 meine einstllungen geändert und danch hats des rechts angezeigt. vlt ham die des einfach rausgenommen.
- Hoi, der Benutzer ist nicht angemeldet und hat somit auch keine persönlichen Einstellungen zur Verfügung. Außerdem kann die Position der Links ohnehin nicht in den Einstellungen geändert werden, sondern nur im Monobook (→), das wiederum ausschließlich angemeldeten Benutzern zur Verfügung steht. Ich habe bzgl. des Problemes einen anderen Benutzer von IE7 gefragt, der sagte, die Links seien zwar unter der Überschrift, es gebe aber keine Überschneidungen. Eventuell kannst du ja einen Screenshot machen. Grüße, — Pill δ 13:11, 24. Feb. 2007 (CET)
[Bearbeiten] Versionsvergleich manuell anpassen
Möglichkeit schaffen bei dem Versionsvergleich, die Absätze mit Mausklicks neu zuzuordnen. Hintergrund: Teilweise werden nichtpassende Absätze miteinander verglichen und der passende Absatz erscheint dann darunter. Wenn z.B. ein Absatz eingefügt wurde. Noch besser: wenn auch bestimmte Textpassagen markiert und verglichen werden können. Zusätzlich sollte die Möglichkeit eingebaut werden, alles was nicht rot ist unsichtbar zu machen. --Diwas 07:25, 25. Feb. 2007 (CET)
dafür:
dagegen:
[Bearbeiten] Beobachtungsliste: automatische Verlinkung bei der Bearbeitung einzelnder Abschnitte
Könnte man bei der Bearbeitung einzelner Abschnitte bei den Zusammenfassungs und Quellenangaben, die hinterher auch in der Beobachtungsliste angezeigt werden, eine automatische Verlinkung zu diesem Abschnitt machen? Das würde die Navigation bei großen Seiten sehr vereinfachen! --Marci Diss. 12:05, 25. Feb. 2007 (CET)
dafür:
dagegen:
- .
Öhm, ist doch schon so (per Klick auf den Pfeil links vor der Zusammenfassung), oder missverstehe ich den Vorschlag? — Pill δ 09:21, 26. Feb. 2007 (CET)
- Oh, das wusste ich nicht. Ich hätte da auch so gemeint, dass dann die Schrift als Link erscheint, allerdings ist es so besser zu unterscheiden, von dem zusätzlichen Text (Zusammenfassung und Quellen). Könnte das jemand zur Hilfe hinzufügen? Wenn es nichts mehr dazu gibt, ist das erledigt. --Marci Diss. 14:20, 26. Feb. 2007 (CET)
-
- Link führt zum Abschnitt wenn man im selben Fenster bleibt (linke Maustaste oder linke Maustaste + Strg für neue Registerkarte). Aber beim Öffnen in einem neuen Fenster wird nur die Seite geladen aber nicht zum Abschnitt gesprungen. Geht aber bei anderen Links auf Abschnitte auch nicht. (Internet Explorer 7)
Ich wünsche mir noch einen zusätzlichen Link der direkt zur Bearbeitung des Abschnitts führt (mit Vorschau). Ideales Beispiel ist diese Seite. Ich will eine Antwort zu einem Thema schreiben, aber doch nicht die ganze Seite laden. Macht die Arbeit an langen Artikeln und besonders an Diskussionsseiten und Wartungsseiten effizienter. Besonders bei Schmalspur-Internet --Diwas 21:08, 26. Feb. 2007 (CET)
dafür:
- . -- Diwas
- .
dagegen:
- .
[Bearbeiten] Einfache Tabellenkalkulation
Hallo,
die Software TWiki unterstützt einfache Tabellenkalkulation. D.h. beim Bearbeiten einer Seite wird ein Tabellenblatt angezeigt, welches wie in Tabellenkalkulationsprogrammen gewohnt bearbeitet werden kann. Die Bearbeitung einer solchen Tabelle ist somit wesentlich einfacher als mit prettytable - wo zumindest Anfänger große Probleme haben, die Syntax zu verstehen und richtig anzuwenden. Daher wäre ich für eine entsprechende Ergänzung der Mediawiki-Software. --BabyNeumann 21:39, 25. Mär. 2007 (CEST)
- Es gibt eine MediaWiki-Extension, die derzeit noch in der Entwicklungsphase ist, die das Erstellen von Tabellen ebenfalls erleichtern soll, siehe dafür diese Infoseite. Wann das ganze fertig ist und ob es auch auf Wikimedia-Wikis implementiert werden wird, steht natürlich in den Sternen. — Pill δ 22:37, 26. Mär. 2007 (CEST)
- Und wie kommt es jetzt laut Text oben auf dieser Seite zu einer Durchsetzung meines Requests und Weiterleitung an die Entwickler? (wobei ich "Durchsetzung" jetzt eher mal als "findet zahlreiche Unterstützer bzw. Personen die die Ergänzung ebenfalls sinnvoll fänden" interpretiere) --BabyNeumann 01:01, 27. Mär. 2007 (CEST)