Wikipedia:Tellerrand/Archiv/2011
Löschdiskussion, Peer-Reviews, Qualitätssicherung auf Unterseiten pro Beitrag
Warum lagern wir die Einzel-Diskussion auf Projektseiten zu einem bestimmten Artikel nicht auf Unterseiten aus, die wir dann mit {{:Wikipedia:Projektseite/Unterseite}}
wieder einbinden, wie bei commons:Commons:Deletion requests. Das dürfte Speicherplatz sparen und man kann dann gezielt nur die Qualitätssicherungsmaßnahmen, Löschdiskussionen und Reviews abonnieren, die einen wirklich interessieren und alte Beiträge lassen sich (ohne Bots) leichter archivieren. Ansonsten ändert sich eigentlich nichts: die bekannten Projektseiten behalten ihren Inhalt und Layout bei. Matthias 17:21, 23. Jan. 2011 (CET)
- Wo wird da Speicherplatz gespart, wenn man den gleichen Text an einer anderen Stelle hat und auf der eigentlichen Seite noch Vorlagen einbindet? Die Vorlagen müssten dann jedesmal neu geparst werden, was langsam und serverunfreundlich ist. Um wenigstens auch ein paar Nachteile zu nennen. ;o) Grüße, —DerHexer (Disk., Bew.) 17:27, 23. Jan. 2011 (CET)
- Kommt ihn ähnlicherweise demnächst ( ;-) ) durch LiquidThread. Ich wäre eh dafür LiquidThread auf QS/LK beschränkt einzuführen. Erstens hat es dort den größten Nutzen wegen Beobachtung und zweitens kann sich dort am Besten mit dem neuen Feature vertraut machen, weil einem andere direkt helfen können. Merlissimo 17:30, 23. Jan. 2011 (CET)
- ... verstehe nur Bahnhof, möchte damit hier aber keine Erläuterung o. ä. einfordern, sondern nur mein Unwissen offenbaren. --Jü 19:53, 23. Jan. 2011 (CET)
- Also es geht darum z.B. die QS-Diskussionen für den Artikel Natriumchlorid unter Wikipedia:Redaktion Chemie/Qualitätssicherung/Natriumchlorid zu führen und den Diskussionsabschnitt wieder unter Wikipedia:Redaktion Chemie/Qualitätssicherung einzubinden, so dass es aussieht wie immer also alles im Blick. Technisch von Vorteil wäre halt, dass man nicht immer >100K Text bearbeitet und jedes mal, selbst wenn man nur ein Kommata setzt komplett gespeichert wird. Teilweise fangen auch schachbrünstige Rechner an zu ruckeln, wenn die Textfelder zu voll sind. Hexer hat aber auch schon angemerkt, Unterseiten wie Vorlagen einzubinden kostet auch Rechenzeit. Ich halte mal dagegen, dass wenn man einen Unterabschnitt einer 200K Seite bearbeitet auch die gesamte Seite neu geparsed werden muss. Okay, Festplattenplatz kostet heutzutage nichts mehr, aber CPU-Zeit ist teuer. Ich bin kein Server-Admin und kann das nicht einschätzen was günstiger wäre für Wikimedia. Die Archivierbots ziehen vielleicht auch noch irgendwo Ressourcen, wenn sie alle Seiten abscannen. Die mit LiquidThreads angedeutete Zukunft der Diskussionsseiten kann man schon unter https://forum.wikimedia.de angucken, aber ich glaube das wurde vor Jahren auch schon angekündigt, keine Ahnung ich bin kein Wikimedia-Insider. Matthias 21:59, 23. Jan. 2011 (CET)
- Ebenso wie Jü bin ich völlig unbeleckt bei diesem Thema. Gut fände ich, das wird aber wohl nicht gemeint sein, wenn die Diskussionen auf QS, LA etc. automatisch auf die Diskussionsseite des jeweiligen Artikels kämen. Das hätte den Vorteil, dass man nicht erst mühsam suchen muss, ob und wann der Artikel bereits mal in der QS etc. war und welche Argumente damals genannt wurden. Dann könnte man sich auch die ganzen Archive (LA, QS etc.) sparen und Bapperlsetzer auf bereits genannte und bearbeitete Umstände verweisen . Soviel von meiner Seite. Gruß. -- nfu-peng Diskuss 10:54, 24. Jan. 2011 (CET)
- Also es geht darum z.B. die QS-Diskussionen für den Artikel Natriumchlorid unter Wikipedia:Redaktion Chemie/Qualitätssicherung/Natriumchlorid zu führen und den Diskussionsabschnitt wieder unter Wikipedia:Redaktion Chemie/Qualitätssicherung einzubinden, so dass es aussieht wie immer also alles im Blick. Technisch von Vorteil wäre halt, dass man nicht immer >100K Text bearbeitet und jedes mal, selbst wenn man nur ein Kommata setzt komplett gespeichert wird. Teilweise fangen auch schachbrünstige Rechner an zu ruckeln, wenn die Textfelder zu voll sind. Hexer hat aber auch schon angemerkt, Unterseiten wie Vorlagen einzubinden kostet auch Rechenzeit. Ich halte mal dagegen, dass wenn man einen Unterabschnitt einer 200K Seite bearbeitet auch die gesamte Seite neu geparsed werden muss. Okay, Festplattenplatz kostet heutzutage nichts mehr, aber CPU-Zeit ist teuer. Ich bin kein Server-Admin und kann das nicht einschätzen was günstiger wäre für Wikimedia. Die Archivierbots ziehen vielleicht auch noch irgendwo Ressourcen, wenn sie alle Seiten abscannen. Die mit LiquidThreads angedeutete Zukunft der Diskussionsseiten kann man schon unter https://forum.wikimedia.de angucken, aber ich glaube das wurde vor Jahren auch schon angekündigt, keine Ahnung ich bin kein Wikimedia-Insider. Matthias 21:59, 23. Jan. 2011 (CET)
- ... verstehe nur Bahnhof, möchte damit hier aber keine Erläuterung o. ä. einfordern, sondern nur mein Unwissen offenbaren. --Jü 19:53, 23. Jan. 2011 (CET)
- @DerHexer: Die gestrige LK-Seite hat derzeit 106k. Das heißt jeder, der sich jetzt noch auf ihr verewigt, fügt ihr 106k + die Summe der weiteren Beiräge hinzu. Wenn die LDen wie auf Commons oder in EN pro Artikel eigene Unterseiten bekommen, dann fügt jeder Bearbeiter nur die Länge des (virtuellen) Abschnittes und seine Bearbeitung dazu, den er bearbeitet, eventuell nur wenige hundert Byte. --Matthiasb (CallMeCenter) 10:35, 31. Jan. 2011 (CET)
- Kommt ihn ähnlicherweise demnächst ( ;-) ) durch LiquidThread. Ich wäre eh dafür LiquidThread auf QS/LK beschränkt einzuführen. Erstens hat es dort den größten Nutzen wegen Beobachtung und zweitens kann sich dort am Besten mit dem neuen Feature vertraut machen, weil einem andere direkt helfen können. Merlissimo 17:30, 23. Jan. 2011 (CET)
- die Diskussionszusammenfassung von DrTrigonBot. Auch das Argument, dass man weniger Text im Bearbeitungsfeld hat, stimmt nicht. Man kann auch den Abschnitt-Bearbeiten-knopf wählen, dann hat man weniger Text als dei einem durchschnittlichem Artikel. --Fix 1998 Disk. +/- 12:53, 24. Jan. 2011 (CET) Kontra, weil das das Abarbeiten der betreffenden Seiten unnöitg erschweren würden, die Server belasten würden und das Beobachten wird auch nicht viel besser. Lieber nutzt man
- Nachtrag: Wenn das Ganze so gemeint ist wie bei WP:WN/M, ist´s nur sinnvoll, wenn man z.B. die QS-Seite in Wikipedia:QS/3. November 2024/Leichte Mängel und Wikipedia:QS/3. November 2024/Schwere Mängel, also irgendwie nach Art, Schwere oder sonstigen Kriterien unterteilt, sodass mehrere Artikel in eine Unterseite fallen. Kontra zu "Ein-Artikel-Unterseiten", sonst könnte man ja gleich die Artikeldisku verwenden und von der QS dorthin verweisen--Fix 1998 Disk. +/- 13:12, 24. Jan. 2011 (CET)
- Schau dir doch mal den Quelltext von Commons:Commons:Deletion requests/2024/11/03 an. --Leyo 13:51, 24. Jan. 2011 (CET)
- Also ich behaupte jetzt einfach mal, dass es aus technischer Sicht besser wäre, da der Speicherplatz ja beim Hinzufügen neuer Diskussionsbeiträge exponentiell steigt. Außerdem kann MediaWiki vielleicht leichter catchen, wenn es merkt, dass sich nur die eine eingebundene Unterseite ändert und der Rest nicht neu geparsed werden muss. Es wird schon einen Grund haben, dass das bei Commons so eingeführt wurde. Ich glaube in der englischen Wikipedia wird das auch so gemacht. Das man die Einzelbeiträge sogar noch kategorisieren kann, z.B. nach Schweregrad kommt dazu. Den einzigen Nachteil den ich sehe ist die Umgewöhnung: "wie es jetzt gemacht wird ist zwar scheiße, aber haben wir schon immer so gemacht". Bei Commons nutzen die da sehr intensiv Java-Script um mit einem Klick automatisch ein Bausteine auf der Benutzerdiskussion, dem eigentlichen Bild und eine Löschdiskussion eröffnet wird. Ein findiger Skripter kann so etwas sicher auch für uns basteln. Matthias 23:38, 24. Jan. 2011 (CET)
- Speicherplatz gibt es wie Sand am Meer. Im Dezember wurde gefeiert, dass die täglichen Commons-Upluads nun größer sind als alle Texte inkl. aller Archive aller Wikimedia-Projekte zusammen. Im Gegenteil: Eine Seite mit 20 Vorlageneinbindungen braucht mehr Performance, als eine Riesenseite ohne Vorlagen.
- Ohne die Liquid-Thread-Variante gibt es keine Möglichkeit alle Beiträge der Sammelseite zu beobachten. Gerade in Projekten/Portalen ist dies aber gewünscht. Das Hauptproblem bei Liquid-Threads ist im Moment das Layout, falls sich mehr als etwa 100 beobachtete Diskussionen geändert haben, da dies dann etwas unübersichtlich wird.
- Die Commons Deletion Requests müssten übrigens täglich von meinem Bot getouched werden, damit die Datenbank aktuell bleibt. Merlissimo 00:52, 25. Jan. 2011 (CET)
- Ich bleibe LD- und (allg.) QS-Seiten so weit wie möglich fern, weil ich die Seiten nicht ständig durch Beträge in für mich wenig interessanten Abschnitten ganz oben auf der Beobachtungsliste haben mag. Die Commonsvariante oder LiquidThreads wären in dieser Hinsicht ein klarer Gewinn. --Leyo 11:27, 26. Jan. 2011 (CET)
- Also ich behaupte jetzt einfach mal, dass es aus technischer Sicht besser wäre, da der Speicherplatz ja beim Hinzufügen neuer Diskussionsbeiträge exponentiell steigt. Außerdem kann MediaWiki vielleicht leichter catchen, wenn es merkt, dass sich nur die eine eingebundene Unterseite ändert und der Rest nicht neu geparsed werden muss. Es wird schon einen Grund haben, dass das bei Commons so eingeführt wurde. Ich glaube in der englischen Wikipedia wird das auch so gemacht. Das man die Einzelbeiträge sogar noch kategorisieren kann, z.B. nach Schweregrad kommt dazu. Den einzigen Nachteil den ich sehe ist die Umgewöhnung: "wie es jetzt gemacht wird ist zwar scheiße, aber haben wir schon immer so gemacht". Bei Commons nutzen die da sehr intensiv Java-Script um mit einem Klick automatisch ein Bausteine auf der Benutzerdiskussion, dem eigentlichen Bild und eine Löschdiskussion eröffnet wird. Ein findiger Skripter kann so etwas sicher auch für uns basteln. Matthias 23:38, 24. Jan. 2011 (CET)
- Schau dir doch mal den Quelltext von Commons:Commons:Deletion requests/2024/11/03 an. --Leyo 13:51, 24. Jan. 2011 (CET)
Weiterer Nachteil von unseren Megadiskussionsseiten ist aber auch, dass regelmäßig verschoben und gelöscht werden muss, weil es nach >10.000 Revisionen Softwareprobleme gibt. Wahrscheinlich machen das auch schon Bots oder MediaWiki kann jetzt mehr ab, aber wie gesagt: so wie jetzt ist es nicht elegant löst. Matthias 13:25, 29. Jan. 2011 (CET)
Bitte einen solchen Unsinn nicht einführen. Bei der Redaktion:Chemie würde ich ein striktes Veto für so was einlegen. Ich hoffe, dass LiquidThreads nie kommt. --Orci Disk 13:27, 29. Jan. 2011 (CET)
Ich verstehe die Motivation dieser Anregung, sehe auch Vorteile (v.a. gezielte Beobachtbarkeit), aber die Nachteile überwiegen meiner Meinung nach (v.a. Aktualisierungsproblem, Komplexität (die meiner Erfahrung nach nicht alle verstehen und die man durch Tools nur scheinbar kompensieren kann)). Zu LiquidThreads kann ich nichts sagen, habe mich noch nicht damit befasst.--Cactus26 13:38, 29. Jan. 2011 (CET)
Das Speicherplatz-Argument dürfte unerheblich sein. Ansonsten schau zu Commons: Die entsprechenden Unterseiten sind zwar durch Bots offenbar ganz gut zu händeln, für den größten Teil der Nutzer aber nicht. Hätte mir ein netter Kollege nicht mal irgendwann diverse Skripte gebastelt, wäre es ein Krampf, einen Löschantrag zu stellen und derartige Diskussionen zu beenden, auf dass sie archiviert werden können. Regelmäßig trifft man Nutzer, die irgendwas machen wollen, mit den Unterseiten und Einbindungen aber vollkommen überfordert sind und dann – wer möchte es ihnen verübeln – an den unmöglichsten Stellen posten. --Polarlys 15:00, 29. Jan. 2011 (CET)
- Danke. Du hast das, was ich im zweiten Punkt sagen wollte, viel konkreter und verständlicher formuliert.--Cactus26 15:13, 29. Jan. 2011 (CET)
- <quetsch> Benutzerunfreundlichkeit trifft auch die die oben erwähnte WP:WN/M zu und ist dort nur das kleinere Übel, weil diese Seite als "Portal" einen schnellen Überblick gibt gegenüber der früheren megagroßen Seite mit x Unter- und Quasiarchivseiten. Bei LiquidThread, zumindest so wie es sich im WMDE-Forum darstellt, ruft man auch immer erstmal die ganze Seite mit allen Threads auf und hat sie auch immer komplett auf der Beo und im Mailabo. Das Anwortfenster landet dort irgendwo mittendrin im Thread, Vorschau-Bug, verwirrende Verlinkungsmöglichkeiten usw. Ich hoffe, dass wir das erst kriegen, wenn's wesentlich ausgereifter ist. --Martina Nolte Disk. 17:20, 29. Jan. 2011 (CET)
- Hinzu kommt, dasss Vorlageneinbindung die Versiongeschichte von Übersichtsseiten kaum noch nachvollziehbar macht. Ich muss in der Versionsgeschichte nachschauen, welche Vorlagen wann wo eingebunden waren, dann muss ich die Seite dieser Vorlagen aufsuchen und mich erneut durch die Versionsgeschichte klicken. Blöd wirds erst recht, wenn dort dann Guerverweise zu Abschnitten kommen, die irgendwann mal gleichzeitig auf einer Seite standen. Die historische Struktur von Diskussionen geht so verloren.--† Alt ♂ 16:30, 29. Jan. 2011 (CET)
Das Einbinden von Seiten ist tatsächlich zunächst nicht gerade benutzerfreundlich. Es ist jedoch durchschaubar, weil MediaWiki die Einbindungen unten anzeigt. Sobald das Erstellen neuer Unterseiten automatisch angelegt wird, z.B. durch einen Rotlink in der QS-Vorlage, dürfte das für Otto-Normal keine Rolle mehr spielen. Wenn man auf Abschnitt bearbeiten drückt lenkt einen MediaWiki gleich in die richtige Unterseite, wenn die Überschrift mit eingebunden wird. Die Archivierung übernehmen sowieso die Admins, Stamm-Mitarbeiter oder Bots. Statt ganze Abschnitte von Bots kopieren zu lassen (Versionsgeschichte wird zerfleddert, möglicherweise nicht mal lizenzkonform), könnten diese einfach die Einbindung in einer Archivseite vornehmen oder sie chronologisch geordnet verlinken. Technisch überwiegen wirklich die Vorteile. Umgewöhnung und Komplexität sind tatsächlich Probleme. Es wäre auch nur eine Übergangslösung bis wir eine Forum-Erweiterung bekommen. Übrigens, wenn man noch ein bisschen weiter über den Tellerrand hinaus guckt: wikia:de.community:Forum:Index hat es möglicherweise am einfachsten und elegantesten gelöst, aber die verwendete MediaWiki Extension, die aus Kategorien solche Listen erstellt, ist hier nicht installiert. Matthias 19:15, 29. Jan. 2011 (CET)
- Du hast drei Vorteile genannt. 1. Speicherplatz: Speicherplatz war und ist kein Argument für irgendwas, es ist genug da. Umd im Vergleich zum Speicherplatz für Bilder oder Videos ist der nötlige Textspeicherplatz vernachlässigbar klein. 2. die Beobachbarkeit: sicher, für einige vielfrequentierte Seiten mag das nützlich sein, nur einzelne Diskussionen verfolgen zu müssen, hat aber gerade für kleinere Projekte, QS-Seiten etc. gravierende Nachteile: man verpasst z.B. sehr leicht neue Diskussionen und hat später über die Beobachtungsliste keine Chance mehr, die zu finden (geht mir z.B. bei Mentoren-Kandidaturen sehr häufig so, nervt sehr wenn man mal wieder eine Kandidatur erst dann mitbekommt, wenn sie gerade vorbei ist). Auch schwillt die Beobachtungsliste unweigerlich stark an, da man ständig neue Unterseiten beobachten muss. 3. Archivierung: das ist falsch, wenn per Bot archiviert wird, hat man die Gewissheit, dass alles sauber auf den Archivseiten aufgelistet ist. Diese Gewissheit hat man bei der Unterseiten-Variante nicht, wenn ohne Bot archiviert wird, kann es leicht passieren, dass die Diskussionsunterseite einfach rausgenommen wird und im Nirvana verschwindet. Man sieht, dass diese "Vorteile" bei näherem Betrachten eigentlich gar keine sind und die großen Nachteile bezg. Benutzerunfreudlichkeit (vor allem für Nicht-Nerds, die sich mit Vorlagen, Unterseiten etc. nicht auskennen) nicht im mindesten aufwiegen. Bitte diesen Vorschlag schnellstmöglich beerdigen. --Orci Disk 20:13, 29. Jan. 2011 (CET)
- Für mich überwiegen die Vorteile, aber nur bei LD und allg. QS. --Leyo 21:30, 29. Jan. 2011 (CET)
- Was hat LiquidThreads mit der Ordnerstruktur zu tun? Bei vielen Beteiligten werden Diskussionen hier rasch ineffizient (dazu gibt es sogar Forschung), deshalb würde ich LiquidThreads gerne einmal ausprobieren. Bei der neuen Ordnerstruktur bin ich mir nicht sicher. --ACNiklas 20:50, 30. Jan. 2011 (CET)
- Hoffen wir lieber, daß wir die LT nie kriegen. Wir brauchen kein Forumfeeling, das zu noch mehr Gequake unbeteiligter einlädt. Und überhaupt, wer ist mit LT überhaupt in der Lage, mit vertretbarem Zeitaufwand zu kontrollieren, welcher Beitrag durch Löschung eines Admins im Orkus verschwunden ist. Die Serverbelastung stelle ich mir gerade bei Artikelverschiebungen, wenn eine in dutzende von LTs (eigentlich Unterseiten) fragmentierte Diskussionsseite mit verschoben wird, um ein Vielfaches größer vor. --Matthiasb (CallMeCenter) 10:45, 31. Jan. 2011 (CET)
- Was veranlasst dich zu der Annahme, dass LT zu mehr "Gequake Unbeteiligter" führt? Ich hoffe eher, dass es zu mehr Beteiligung von nicht-techisch versierten Autoren führt. --ACNiklas 18:10, 31. Jan. 2011 (CET)
- Hoffen wir lieber, daß wir die LT nie kriegen. Wir brauchen kein Forumfeeling, das zu noch mehr Gequake unbeteiligter einlädt. Und überhaupt, wer ist mit LT überhaupt in der Lage, mit vertretbarem Zeitaufwand zu kontrollieren, welcher Beitrag durch Löschung eines Admins im Orkus verschwunden ist. Die Serverbelastung stelle ich mir gerade bei Artikelverschiebungen, wenn eine in dutzende von LTs (eigentlich Unterseiten) fragmentierte Diskussionsseite mit verschoben wird, um ein Vielfaches größer vor. --Matthiasb (CallMeCenter) 10:45, 31. Jan. 2011 (CET)
- Was hat LiquidThreads mit der Ordnerstruktur zu tun? Bei vielen Beteiligten werden Diskussionen hier rasch ineffizient (dazu gibt es sogar Forschung), deshalb würde ich LiquidThreads gerne einmal ausprobieren. Bei der neuen Ordnerstruktur bin ich mir nicht sicher. --ACNiklas 20:50, 30. Jan. 2011 (CET)
- Für mich überwiegen die Vorteile, aber nur bei LD und allg. QS. --Leyo 21:30, 29. Jan. 2011 (CET)
@Orci: Ich sehe eher eine Entlastung der Beo-Liste bzw. effektiveres Beobachten – du beobachtest nur die LD zu dem Artikel, der dich interessiert. Das Beobachten einer ganzen LK-Seite ist praktisch ineffizient, weil da fuffzich oder drölfundelfzig Abschnitte in chaotischer Folge bearbeitet werden. Die Änderung des 71. Unterabschnittes geht da oft unter. EN macht das seit langem so, Commons auch, aber bei uns ist das ein schnellstmöglichst zu beerdigender Vorschlag? Glaube ich nicht. --Matthiasb (CallMeCenter) 10:45, 31. Jan. 2011 (CET)
- Bei den Löschkandidaten ist das mit der Beobachtung weniger das Problem, das stimmt (das ist vor allem für Fach-QS-, Fach-Projektseiten etc. problematisch), dafür spielt dort das OMA-Problem eine größere Rolle. Die Löschkandidaten und QS-Seiten sind nun mal Seiten, an denen massenhaft Neulinge aufschlagen und warum sollten wir es denen auch noch technisch noch schwieriger machen, als sie es durch unsere Umgangsformen, kryptische Abkürzungen etc. eh schon haben. Dass es bei Commons nicht besonders gut funktioniert hat ja Polarlys oben ganz gut beschrieben. --Orci Disk 11:18, 31. Jan. 2011 (CET)
Irgendwie wird in der Diskussion hier Matthias-Variante mit LiquidThreads komplett vermischt. Letzteres wäre für Neulinge deutlich einfacher. Die Einführung von LiquidThreads auf QS/LD wäre durchaus möglich. Wirkliche Probleme existieren derzeit nur, wenn es im großen Umfang eingeführt würde. Matthias-Variante ist einfach viel zu aufwändig für den normalen Benutzer und führt dazu, dass vieles nicht mehr automatisch beobachtet werden kann. Ich habe auch wenig Lust sowas auch auf dewiki erstellen zu müssen. Merlissimo 18:22, 31. Jan. 2011 (CET)
- LT sind für EN:Wikinews auf den Meinungsseiten angeschaltet. Ich kann da nicht erkennen, daß die Bearbeitung für Neulinge einfacher würde. --Matthiasb (CallMeCenter) 20:00, 31. Jan. 2011 (CET)
- Du musst nicht die Doppelpunkt-Syntax zwecks Einrückung kennen. Du musst deine Beträge nicht mit Tilden signieren. Du kannst einfacher direkt auf einen älteren Beitrag antworten. Es gibt die Möglichkeit das LD-Urteil als Thread-Zusammenfassung zu erstellen - damit fällt eine LAE-Notiz leichter. Oben auf der Seite gibt es eine Zusammenfassung, die dir den Überblick über alle laufenden Disks erleichtert. Auf der Oberfläche wird direkt angezeigt, wenn jemand an deiner Disk antwortet, ohne das du jedes Mal deine Beobachtungsliste kontrollieren musst. Merlissimo 20:16, 31. Jan. 2011 (CET)
Ich möcht’ – unabhängig von der techn. Umsetzung – anmerken, dass es mit der Transparanz i.s.V. Auffindbarkeit noch besser werden kann:
Die Auffindbarkeit der archivierten Disk. wurde oben ja schon angesprochen. Wenn sie bei der Artikeldisk liegen, gehen sie nicht so schnell „verloren“. Die lokal eingebundene Vorlage:War Löschkandidat listet z.B. nicht immer alle LDs; nach einer Verschiebung bleibt der frühere-LDs-Benachrichtungs-Bot still; der Weg über „Links auf diese Seite“ ist nicht jedem bekannt (wird es auch nie sein) und mE auch nicht so offensichtlich, außerdem kann auch die Such-Einschränkung auf den WP-Namensraum (wieder ein Schritt mehr, den nicht jeder mitgeht bzw. „Verluste bringt“) eine lange, unübersichtliche Liste hervorbringen.
Am wichtigsten & verbesserungswürdigsten erscheint mir aber die Auffindbarkeit von aktuell besprochenen „Artikelproblemen“. Auch hier scheint mir die jeweilige Artikeldisk der beste Ort: Dort kann z.B. deren Kategorisierung dazu genutzt werden, die Diskussionen sowohl auf den „allg.“ LK/Review-Seiten als auch bei entsprechenden Redaktionen/Portalen anzeigen zu lassen. Änhliches mit DM-Anfragen, KALP-Kandidaten, als redundant markierten Artikeln u.a.
Im Ganzen steht dahinter die Idee, dass es (für verschiedene Autoren) drei Wege gibt, ein aufgestoßenes „Artikelproblem“ zu finden: Einmal über die Artikeldisk selbst, einmal über die Themenportale/-redaktionen und einmal über die – thematisch meist kaum eingegrenzte – WP-Seite für die „Problemklasse“ (WP:QS (allg.), WP:LK, WP:RV etc.). Wo sich das meiste Fachwissen „aufhält“ und jemand mit Ahnung „aufschlägt“ – beim Thema selbst (Artikeldisk) oder beim Themenfeld (Portal/Redaktion) – aber auch jemand mit Ahnung i.S.v. „allg.-enzyklopädischer“ Erfahrung z.B. gegenüber lewe/exzell Artikeln (WP:KALP) oder der Abarbeitung von Redundanzen (WP:RED) – ich weiß es nicht und glaube auch nicht, dass man so etwas sicher und stichhaltig herausfinden kann.
- Deshalb sollten imho alle drei verfügbar sein, allerdings, wie hier mehrfach gesagt, ohne großen manuellen Aufwand + Vorkenntnisse beim Straßenbau – z.B. möglichst keine komplizierte Vorlage für LKs oder einen QS-Kandidaten, der mit 1 Eingabe anschließend sowohl auf der Artikeldisk als auch auf WP:QSH als auch z.B. bei WP:QSG auffindbar ist.
Denkbar wäre auch eine Standardisierung von Unterseitennamen: Wenn ich den Artikel „Licht“ zum LK machen möchte, eröffne ich [[Diskussion:Licht/Löschdiskussion]], worauf ein Bot – nur für diesen & ähnliche Seitentitel – mit dem Einbinden auf den Portal-/Redaktions- und allg. WP-Seiten reagiert… der Benutzer braucht einfach nur zu schreiben, ohne weitere techn. (z.B. Vorlagen-)Kenntnisse. Nach Ende der Disk wird sie mit unterdrückter Weiterleitung ins Artikeldisk-Archiv verschoben, bei mehreren Disks mit Versionszusammenführung. Falls der zugehörige Artikel gelöscht wird, bleibt die Disk-Archivseite erhalten & könnte evtl. vor einer Neuanlage im obigen Hinweistext („Hier kannst du einen neuen Wikipedia-Artikel verfassen. Eine Anleitung für Anfänger findest du unter…“) verlinkt werden. Läuft in dieser Form auf eine Infotafel für „Artikelprobleme“ hinaus, die auf jeder Artikeldisk auf Redundanz-, QS-, Lösch- u.v.a. Diskussionen(/D-Unterseiten) verweist, sofern vorhanden. Keine Ahnung, inwieweit diese Vorgehensweise mit LT harmoniert oder auch über wäre.
Derzeit ist im Artikel selbst ein Baustein, der manchmal zur Disk auf einer WP-Seite führt oder, oft nur als „nackter Link“ (ohne D-Abschnitt), zur Diskussionsseite (und bei großen Artikeln manchmal untergeht oder generell am Ende steht & recht unauffällig per kl. Symbol verlinkt ist).
Dabei klappt’s (neben der Archiv-Auffindbarkeit) mit der „Dreiecksbeziehung“ Artikel–Redaktion/Portal–allg. WP-Seite für die enzykl. „Problemklasse“ noch nicht so recht.
</ OT> --Hæggis 21:28, 31. Jan. 2011 (CET)
- Ich glaube, jetzt habe ich verstanden, was du willst. Mit einer Struktur wie [[Diskussion:Licht/{Löschdiskussion|QS|...}]] hätte man tatsächlich immer alles schön beim Artikel. Trotzdem sehe ich noch einige Probleme: Ohne Baustein im Artikel kommst du nicht aus. Er weist nämlich nicht nur WP-Autoren auf den Stand der Bearbeitung hin, sondern warnt auch Leser, das hier etwas nicht in Ordnung ist. Da der Großteil der Leser wirklich nur den Artikel und nichts anderes ließt, ist kein anderer Ort für die Bausteine sinnvoll. Weiterhin benötigst du für dein Vorhaben mindestens einen Bot. Das macht das ganze System recht fehleranfällig. Wenn der Bot mal ausfällt, und eine Woche lang alle QS, LDs, etc. nicht funktionieren, werden wir danach ganz schön was aufzuräumen haben. Klar wäre das schaffbar, es wäre aber sehr ärgerlich. Um das Problem der Auffindbarkeit von QS-Diskussionen und ähnlichem trotzdem zu begegnen möchte ich vorschlagen, einfach die LD, QS und wichtige Portal-QS von einem Bot überwachen zu lassen. Sofort, wenn ein neuer Artikel eingestellt wird, setzt der einen Verweis in die Artikel-Diskussion. Dann würde auch bei Verschiebungen der Verweis immer erhalten bleiben. Große Änderungen in der Struktur wären darüber hinaus unnötig. --ACNiklas 16:06, 1. Feb. 2011 (CET)
Ein weiterer Vorteil von Unterseiten: Wie unter Commons:Commons:WikiProject Chemistry/Deletion requests gemacht, können Löschkandidaten des gleichen Themas auf einer Seite eingebunden und so an diesem Thema interessierten Benutzern „präsentiert“ werden. --Leyo 16:47, 6. Feb. 2011 (CET)
- Da gab es doch mal diese Riesendiskussion, weil einige Redaktionen eigene Löschkandidaten haben von denen die Stammbesatzung der Löschtruppe nichts mitbekommen hat. Das wäre doch DIE Lösung für das Problem. Ich bin weiterhin dafür, wenn auch nicht gleich auf allen großen Projektdiskussionsseiten. Matthias 08:00, 10. Feb. 2011 (CET)
Persönlicher Sandkasten
Gerade gesehen. In der polnischen Wikipedia besitzt jeder Benutzer in seiner Personaltoolbar einen Link zu einem eigenen Sandkasten (Spielwiese). Dies ist eine Seite im BNR des jeweiligen Nutzers. Diese standardmäßige Einstellung einer solchen Seite könnte vor allem Neulingen helfen sich besser in die WP reinzufinden. liesel Schreibsklave 19:35, 26. Jan. 2011 (CET)
- Vorlage:Hallo einen Link auf Spezial:Meine Benutzerseite/Sandkasten statt auf Wikipedia:Sandkasten. Matthias 13:30, 29. Jan. 2011 (CET) Pro Lässt sich ja ganz leicht umsetzen: einfach in
Jetzt Neutral Wenn jeder Benutzer selber entscheiden kann, ob er die Spielwiese in seinem BNR haben möchte und sie somit selbst erstellen muss, finde ich die Idee gut. Aber wenn die Seite gleich bei der Anmeldung automatisch erstellt würde, täte es viele unnötige LAs bringen. Pro--Fix 1998 Disk. +/- 20:22, 29. Jan. 2011 (CET)
- Es wird ja keine Seite erstellt. Man hat nur in der Personaltoolbar diesen Link. Diesen kann man später auch mit einer Änderung in der css entfernen. Und es wird ja niemand gezwungen auf die Seite was zu schreiben. liesel Schreibsklave 20:29, 29. Jan. 2011 (CET)
- Martin-rnr 21:38, 29. Jan. 2011 (CET) Pro - hört sich gut an. --
Wie wird’s gemacht? Auf pl:MediaWiki:Commons.css und .js ist kein Erklärbärtext, der Moja dyskusja enthält. --Hæggis 21:35, 31. Jan. 2011 (CET)
- Wenn man Common.js richtig schreibt, steckt die Funktion im Abschnitt „Link do brudnopisów w menu osobistym“. --Schnark 12:22, 1. Feb. 2011 (CET)
- Wenn :-) Thx, Hæggis 01:22, 10. Feb. 2011 (CET)
- Unterseite gehen, um Kategorien und Weiterleitungen zu testen; und man muss mit BKs rechnen sowie damit, dass der eigene Text nach kurzer Zeit wieder verschwindet. Alles sehr unbequem für jemanden, der gerade erst lernt, mit der Software umzugehen. Viele erstellen ihren ersten Artikel auf der Spielwiese oder auf ihrer Benutzerseite, weil sie es nicht besser wissen. Eine standardmäßig vorgesehene persönliche Spielwiese würde alle Probleme auf einmal lösen. -- Katimpe 01:53, 4. Feb. 2011 (CET) Pro Bei der allgemeinen Spielwiese soll man darauf achten, die Intro-Vorlage nicht zu entfernen; man kann sie nicht verschieben; man kann keine neue Seite anlegen; man soll auf eine
- DrTrigon 15:38, 12. Feb. 2011 (CET) Pro Hallo Leute; besser spät als nie noch mein Senf dazu... Ich halte das für eine sehr gute Idee, denn ich halte v.a. pers. Spielwiesen für sehr nützlich. Darum habe ich auch den Bot im pywikipedia framework angepasst und betreibe ihn. Ich unterstütze den Vorschlag, wenn ich helfen kann - sehr gerne! --
Anleitung
Im Gegensatz zu plwiki würde ich es gerne sehen, dass der Benutzer auch erfährt, was er damit anfangen soll, nachdem er auf seiner Spielwiesenseite ist. Also einen Text, der auf der noch nicht angelegten Spielweise erscheint und beschreibt, was er hier machen soll/kann. Eventuell Verweise zur Hilfe usw. Vielleicht gibt es Anregungen aus den Willkommensbausteinen. Auch ein Verweis auf den DrTrigonBot zum automatischen Mähen wäre imo sinnvoll. Es wäre auch sehr gut, wenn es neben der deutschen auch eine englische Version gibt.
Wenn ihr euch auf einen Vorschlag geeinigt habt, den man direkt einbauen kann, könnt ihr mir Bescheid geben und ich würde das für Nicht-Sichter einführen (damit sehen es Neulinge und es stört die alten Hasen nicht, die sonst aufschreien). Merlissimo 00:31, 10. Feb. 2011 (CET)
- FYI: die sk.wiki hat gerade vor etwa drei Tagen abgestimmt, dass sie dies - nach dem polnischen Muster - auch einführen möchte und dies irgendwo auf meta (oder per bug) beantragt. -jkb- 00:46, 10. Feb. 2011 (CET)
- Also: Diskussion, Antrag. -jkb- 00:49, 10. Feb. 2011 (CET)
- Ja, es funktioniert gar schon, wie ich sehe. Einfach sk.wiki ansteuern, liegt oben zw. Diskussion und Einstellungen. -jkb- 00:51, 10. Feb. 2011 (CET)
- P.S. In der bugzilla ist noch ein guter Hinweis, denke ich, nämlich, dass auf der Seite automatisch immer der Tag __NOINDEX__ erscheint. -jkb- 01:02, 10. Feb. 2011 (CET)
- Vorschlag: Spielwiese: hier kannst du ungestört üben. Die Vorlagen müsste noch angepasst werden, aber ich wollte zeigen, dass man editintro und preload ganz gut arbeiten kann um dem Nutzer zu erklären wie das jetzt überhaupt funktioniert. Gruß Matthias 07:56, 10. Feb. 2011 (CET)
- Die Idee mit dem Preload ist mit sicherheit prima. Die Vorlage müßte aber richtig schlanker werden - das verlinkte Beispiel könnte bei wirklichen Neulingen die Angst hervorrufen, so etwas zu editieren :-). Ich denke dabei an einen ganz schlichteren Kasten wo stehen würde "Dies ist ... ... und was und wie du hier machen kannst, findest du /+ Link zu der eigentlichen Anleitung/". Ferner würde ich gerne wissen, ob man auf die Seite etwas nicht beim Öffnen sondern beim Speichern reinpflanzen kann. Hier denke ich an die Idee mit NOINDEX, was sicherheitshalber beim Speichern der Seite mitgespeichert werden sollte. -jkb- 22:21, 10. Feb. 2011 (CET)
- Den preload wollte ich nicht als Tab einbauen, weil man sonst nicht mehr ohne preload auf seine Spielwiese kommen kann. Es geht um einen Text damit "Diese Benutzerseite existiert noch nicht. Wikipedia stellt jedem angemeldeten Benutzer Unterseiten im Benutzernamensraum zur Verfügung. * Du kannst mit Erstellen diese Unterseite neu anlegen" mit einer für die Spielwiese passenderer Variante ersetzt werden kann. Dort kann dann von mir aus der preload-Link dann rein. Merlissimo 23:16, 10. Feb. 2011 (CET)
Vorschlag:
Diese Seite ist deine persönliche „Spielwiese“: Du kannst sie ganz nach Belieben bearbeiten und verändern, die Wikisoftware ausprobieren oder in Ruhe deine Artikel vorbereiten. Außer dir bearbeitet im Normalfall keiner diese Seite.
Rechtswidrige oder sonstwie problematische Äußerungen (z. B. Beleidigungen) sind selbstverständlich nicht erlaubt. Dergleichen kann jederzeit von anderen entfernt werden und im Extremfall zur Sperrung deines Benutzerkontos führen.
Um diese Seite zu erstellen, gib einfach etwas in das Textfeld ein und klicke darunter auf Speichern. Du kannst auch die Hilfe- und Sonderzeichenleisten ober- und unterhalb des Textfeldes verwenden. Eine allgemeine Einführung in die Wikipedia findest du unter Hilfe:Tutorial.
Wenn du deine Spielwiese automatisch gemäht haben willst, klicke einfach auf diesen Link und dann auf "Seite speichern"
Dieser Text enthält alles, was vorerst zur Bearbeitung der Seite benötigt wird, und genau einen weiterführenden Link zur Hilfe (alles weitere kann man von dort aus suchen, das Intro sollte knapp sein und nicht zu einem eigenen Hilfeportal werden). Alternativ könnte man auch noch eine Seite Hilfe:Persönliche Spielwiese erstellen: Dort könnte dann der Hinweis auf DrTrigonBot stehen, wie man die Seite verschieben kann und darf, dass man keine Kategorien einfügen sollte etc.
Die Links in der ersten Zeile würden zu den anderssprachigen Versionen des Textes führen. -- Katimpe 03:00, 11. Feb. 2011 (CET)
- Der Text ist okay, schön gemacht. Matthias 19:42, 11. Feb. 2011 (CET)
- So ok, wenngleich ich die Links auf andere Sprache für überflüssig halte - jemand, der aus einer anderen Wiki kommt und hier editiert, ist mit Sicherheit nicht erst zwei Tage registriert, und außerden spricht er auch deutsch. Sonst ok. -jkb- 20:50, 11. Feb. 2011 (CET)
Zu der Anleitung ich kann hier v.a. (oder 'nur') Benutzer:DrTrigon/Entwurf/Vorlage:Spielwiese beisteuern. Diese Vorlage kann sehr gerne offiziell gemacht werden, ich wollte da nur nicht vorgreifen... nutze sie selbst schon sehr lange. Mein Bot arbeitet so, dass er nur den Seiteninhalt NACH der Vorlage leert. Dies hat den enormen Vorteil, dass man Sachen die längerfristig wichtig oder interessant sind (Tests, oder so) vor dieser Vorlage platzieren kann, ohne dass der Bot sie entfernt. Also so wie ich es unter Benutzer:DrTrigon/Spielwiese mache... Jeden Hinweis auf meinen Bot begrüsse ich (Werbung kann nicht schaden ;), obschon man sich dann überlegen müsste ihn leicht anzupassen; derzeit beachtet er nur Spielwiesen von Benutzern die unter Benutzer:DrTrigonBot/Diene_Mir! eingetragen sind, da ich nicht im Benutzernamensraum von anderen Benutzer rumfummeln wollte ohne Aufforderung. Grüsse --DrTrigon 15:38, 12. Feb. 2011 (CET)
- Ich hab mal die Language-Links entfernt, und der Bot sollte auch nicht standardmäßig "mähen", denn wenn ein Neuling seine Artikel darin vorbereitet, sind die ja dann wieder weg. Man sollte eher in der Begrüßungsvorlage darauf hinweisen, eine Vorlage (die man noch programmieren müsste, z.B. Vorlage:Spielwiese mähen), einzubinden, die den DrTrigonBot aktiviert. (so etwas wie der SpBot, der auf {{Erledigt|1=--~~~~}} reagiert)--Fix 1998 Disk. +/- 13:12, 13. Feb. 2011 (CET)
- Das Mähen der Spielwiese macht ja nur bei Wikipedia:Spielwiese Sinn. Persönliche Spielwiesen kann man ja selber mähen. Eine neue Vorlage und ein Bot. Das sind zwei komplexe Konzepte, die ich einem Neuling, der gerade Wiki-Syntax lernt nicht gleich zumuten würde. Matthias 13:17, 13. Feb. 2011 (CET)
- Doch, das Mähen macht Sinn, weil die SPW damit übersichtlich gehalten wird und der Neuling jedesmal auf einer "frischen" Seite testen kann. Ich hab mir das jetzt so überlegt: Wenn der Benutzer auf den Link in Personaltoolbar klickt, erscheieint der obrige Kasten, der auch einen Link enthält, mit dem die Vorlage:Spielwiese mähen (z.Z. unter Benutzer:Fix 1998/Vorlage:Spielwiese mähen) per preload eingbunden werden kann. einfacher geht´s nimmer, oder?--Fix 1998 Disk. +/- 15:16, 13. Feb. 2011 (CET)
- Das Mähen der Spielwiese macht ja nur bei Wikipedia:Spielwiese Sinn. Persönliche Spielwiesen kann man ja selber mähen. Eine neue Vorlage und ein Bot. Das sind zwei komplexe Konzepte, die ich einem Neuling, der gerade Wiki-Syntax lernt nicht gleich zumuten würde. Matthias 13:17, 13. Feb. 2011 (CET)
- Andererseits: wenn er das Archivieren falsch einstellt, kann es schief gehen und er findet seine vorbereiteten Artikel usw. nicht. Besser, dass er lernt, es selber zu machen (bzw. als Archiv zu archivieren, wenn schon). -jkb- 15:22, 13. Feb. 2011 (CET)
- @Fix 1998: Der Bot mäht nicht standardmässig, sondern nur auf ausdrücklichen Wunsch, wie ich oben (wohl unverständlich) erklärt habe. ;)
- Es kann auch sein, dass ein neuer Benutzer durch ne automatisch geleerte Spielwiese verwirrt wird, was auch immer. Ich habe meine Vorlage, u.a. darum auch an die Originale angelehnt, damit es einen Wiedererkunngs-Effekt gibt. Aber grundsätzlich passiert ja gar nix, wenn es der Benutzer nicht selbst so einstellt, bzw. konfiguriert. So wie ich es verstehe geht es hier ja nur darum, neue Benutzer auf die bestehenden Möglichkeiten hinzuweisen und nicht eine undurchschaubare Standard-Konfiguration zu erstellen. Grüsse --DrTrigon 15:49, 13. Feb. 2011 (CET)
- @DrTrigon:Ich meinte nur, weil du geschrieben hast "den bot etwas anzupassen", programmier deinen Bot auf deine oder, wenn sie dir gefällt auch meine Vorlage um, gerne--Fix 1998 Disk. +/- 15:54, 13. Feb. 2011 (CET)
Mit meiner Vorlage ist der Bot in Betrieb und läuft (wie beschrieben). Wenn Ihr das Bedürfnis habt die Vorlage zu ändern (Name oder Inhalt) dann teilt mir das bitte mit und ich passe den Bot soweit an, dass er das auch kann... ;) Grüsse --DrTrigon 10:24, 14. Feb. 2011 (CET)
- Wenn der Bot tatsächlich nur per Aufforderung tätig wird, ist es in Ordnung. Denn ein privater Sandkasten sollte nicht nur zum Probieren da sein, er bietet auch die Möglichkeit dem neuling solche Dinge beizubringen wie Löschen, Arbeiten mit Diffs, wo finde ich gelöschte Versionen und wie usw. Wenn er das nicht hinkriegt so fragt er und lernt es dabei. -jkb- 15:14, 14. Feb. 2011 (CET)
- Dem gibts aus meiner Sicht nichts beizufügen. ;) (ich würde sowieso alles was Du beschrieben hast als 'probieren' bezeichnen, nicht nur Text-Edits - ich benutze die Sandbox auch um versch. Bot-Funktionen von meinem und anderen Bots zu testen usw.)
- Um es mal ganz klar zu stellen; per Definition darf der Bot nur auf explizite Benutzeranforderung tätig werden, denn Edits im Benutzernamesraum sind für Bots sonst verboten. An das hält sich mein Bot auch. Er ist sogar extra-paranoid, denn man muss sich:
- Auf der Liste Benutzer:DrTrigonBot/Diene_Mir! eintragen und
- man muss die Vorlage Benutzer:DrTrigon/Entwurf/Vorlage:Spielwiese eingebunden haben, sonst mach der Bot gar nix
- Ich möchte Euch auch gar nicht rein-reden, ich wollte nur hinweisen auf das was schon vorhanden ist (von meiner Seite):
- Bot der Benutzer Sandboxen reinigen kann, wenn vom Benutzer ausdrücklich gewünscht (ist so übrigens schon seit etwa 3 Jahren in Betrieb)
- Vorlage für Benutzer Sandboxen (die zur Zeit auch von meinem Bot verwendet wird)
- Ich wäre (wie oben erwähnt) dafür nur eine 'Hilfe' oder einen 'Hinweis' zu erstellen, die die Benutzer einfach auf Möglichkeiten hinweisen, z.B. 'schau Dir mal andere Benutzer Spielwiesen an' usw. aber möchte eigentlich v.a. meine Bot Dienste anbieten. Bin da gerne bereit eine andere/weitere Vorlage zu berücksichtigen. Man könnte sich auch überlegen den Punkt 1 wegzulassen und einfach Seiten, die die Vorlage einbinden zu mähen. Aber da dürft Ihr entscheiden, was Ihr Euch wünscht... Ich passe mich gerne an. Sonst lasse ich den Bot einfach wie er ist (wie beschrieben), denn ich bin zufrieden damit und hatte bisher keine Beschwerden (könnte daran liegen, dass Ihn kaum jemand wirklich nutzt bisher... ;).
- Grüsse --DrTrigon 13:16, 15. Feb. 2011 (CET)
Den Hinweis zum automatischen Mähen würde ich – wie schon oben gesagt – eher außen vor lassen bzw. auf eine eigene Hilfeseite auslagern. Man kann die Funktion für nützlich halten oder nicht (der Zahl der Nutzer nach tun es wohl eher wenige ;-)), aber ich meine, ein Hinweis auf irgendwelche technischen Spielereien verwirrt an solch einer prominenten Stelle eher, als dass er nützt.
Eine Frage an die Vorlagenexperten: Könnte man erreichen, dass (da, wo vom Erstellen die Rede ist) ein anderer Text angezeigt wird, wenn die Seite schon erstellt wurde? Mit ifexist oder so? --Katimpe 01:49, 2. Mär. 2011 (CET)
Suche auf der itWP
Schaut mal. --Hæggis 11:48, 25. Mär. 2011 (CET)
- Was denn? --Leyo 11:49, 25. Mär. 2011 (CET)
- Das Ausklappdingsda rechts neben dem Suchfeld. Ist ein bisschen zu nah dran und Google etc. sind mE auch unnötig, aber mit einer Umstellung kann die Suche auf anderen WM-Projekten und/oder Sprachversionen der WP angeboten werden (am besten gleich Volltext, mit der hiesigen Eingabe „en:wp:fundstück“ landet man leider erstmal beim leeren Seitentitel). Wäre imho eine wesentliche Verbesserung der Suchfunktion. --Hæggis 12:35, 25. Mär. 2011 (CET)
- So was Ähnliches gab es auch mal hier. --Schnark 09:13, 26. Mär. 2011 (CET)
Aussehen der Hauptseite wie in der englischen Wikipedia
Warum nicht? -- 91.2.172.181 06:10, 23. Mär. 2011 (CET)
- Weil hellgrün nicht hübsch ist. --32X 09:25, 23. Mär. 2011 (CET)
Ich finde das Design der Hauptseite der englischen WK nicht schlecht. Man könnte ja die Farben und Rubriken der deutschen WK beibehalten und nur das Design anpassen. --Simon.hess 12:44, 31. Mär. 2011 (CEST)
Hallo, das Projekt en:Wikipedia:WikiProject Articles for creation finde ich ganz interessant, auch wenn bei uns auch unangemeldete Benutzer Artikel erstellen können. Vielleicht ließe sich mit so einem Projekt die Anzahl der missglückten Artikel-Versuche reduzieren und gleichzeitig die Einstiegsschwelle zur WP senken. Was meint ihr? --Wkpd 22:02, 18. Apr. 2011 (CEST)
- In der Sache immer noch etwas unentschieden; was ich aber auf jeden Fall gut finde, ist die Idee einer „lokalen“ Dauer-Bewertungs-/Rückmeldungsseite. -- Hæggis 19:15, 19. Apr. 2011 (CEST)
en:Wikipedia - Artikel zu Episoden von Serien
Hallo, in der englischsprachigen Wikipedia gibt es neben den (auch in der deutschen Version vorhandenen) Episodenlisten zu Serien, bei populären Serien zusätzlich einen Artikel zu jeder Folge. Wäre das nicht auch in unserer Wikipedia eine Überlegung wert?--Rekymanto 08:15, 4. Mai 2011 (CEST)
- Es gab schon endlos viele Diskussionen zu diesem Thema, das Ergebnis steht hier und wird sicher so schnell nicht geändert werden. Viele Grüße --Orci Disk 10:59, 4. Mai 2011 (CEST)
Browser-Leeren (STRG+F5)-Hinweis auf der Startseite
Gesichete Versionen werden in der öffentlichen (anonymen) Version nicht immer angezeigt
Im aktuellen Fall hatte ich bei einem Artikel einige kleinere Edits gemacht, und er wurde auch gesichtet. In der öffentlichen (anonymen) Version wurde aber immer noch die alte Version angezeigt. Erst nach dem Einloggen, erschien dann die "gesichtete" Version. Das habe ich auch schon bei anderen Artikeln erlebt. Und nicht nur ich. Ich dachte erst an einen technischen Bug oder ähnliches. Tatsächlich aber lag das Problem am serverseitigen Cache, in dem noch immer die vorherige Version (vor dem Sichten) gespeichert war.
Einfache Lösung: mit STRG+F5 den Cache manuell leeren.
Vorschlag: Vielleicht könnte man einen entsprechenden Hinweis auf die Start- bzw. "Servus"-Seite (nach dem Ausloggen) setzen, wie das z.B. die US-Wikipedia macht.
Zitat: Note that some pages may continue to be displayed as if you were still logged in; this can be fixed by clearing your browser cache.
Nur halt mit entsprechendem Hinweis.
Gruß--Bylot 16:11, 11. Dez. 2011 (CET)
Hinweis auf schnelle Veränderbarkeit eines Artikels wg. aktueller Ereignisse
Hallo,
in der englischen und französichen Wikipedia habe ich gesehen, dass es da so einen besonderen Hinweis gibt, der bei aktuellen Ereignissen oberhalb des eigentlichen Artikels eingeschoben wird.
Dieser verweist darauf, dass aufgrund gerade aktueller Geschehnisse, deren Folgen noch nicht absehbar sind, die Inhalte kurzfristig und häufiger geändert werden könnten. Beispiele: aktueller Vulkanausbruch oder politischer Umsturz oder dgl.
Fände ich prima, wenn es sowas bei uns in der deutschen Wikipedia auch gäbe.Reykholt 22:14, 11. Jul. 2011 (CEST)
Vgl. z.B.
http://fr.wikipedia.org/wiki/Puyehue_%28volcan%29 Reykholt 22:21, 11. Jul. 2011 (CEST)
- Sowas? --Engeltr 16:55, 26. Jul. 2011 (CEST)
Dieser Artikel dokumentiert ein aktuelles Ereignis. Informationen können sich schnell ändern. |
Eine solche Vorlage gab's mal auch hier: Vorlage:Neuigkeiten. --Leyo 17:04, 26. Jul. 2011 (CEST)
- Man könnte zusätzlich einen Hinweis auf Wikipedia:Neuigkeiten setzen um auf WP:WWNI#8 aufmerksam zu machen. Gruß Matthias 22:51, 21. Jan. 2012 (CET)
- Aktuell gibt es mal wieder eine solche Vorlage: Vorlage:Laufendes Ereignis, scheint aber nicht gänzlich unumstritten zu sein. --KMic 23:54, 21. Jan. 2012 (CET)
Löschdiskussionen wie bei Commons
Bei commons wird jede LD auf einer separaten Seite geführt, aber alle sind immernoch auf einer gemeinsamen Seitezu finden, wie bei uns nach Tagen sortiert. Dadurch sieht man in seiner eigenen Beobachtungsliste nur die Diskussionen, die man beobachtet, was imho den grossen Vorteil hat, dass die Beobachtungsliste schön übersichtlich bleibt. (nicht signierter Beitrag von Jackson (Diskussion | Beiträge) )
- Das wurde erst kürzlich diskutiert, nur finde ich die Stelle gerade nicht mehr. --Leyo 18:49, 22. Nov. 2011 (CET)
- Weisst du das Ergebnis denn noch? – Gruß, Jackson 19:00, 22. Nov. 2011 (CET)
- Da alles beim Alten geblieben ist, kannst du's wohl selbst erraten. :-) Vielleicht kannst du unter WP:? nach der Diskussion fragen. --Leyo 19:15, 22. Nov. 2011 (CET)
- Weisst du das Ergebnis denn noch? – Gruß, Jackson 19:00, 22. Nov. 2011 (CET)
- Schien mit nicht eindeutig so zu sein, da eine Umsetzung bei positiven Diskussionsergebnis wohl einige Zeit in Anspruch nehmen dürfte. MBs dauern immer sehr lange. – Gruß, Jackson 19:33, 22. Nov. 2011 (CET)
- Wikipedia:Tellerrand/Archiv/2011#Löschdiskussion, Peer-Reviews, Qualitätssicherung auf Unterseiten pro Beitrag --Der Umherirrende 19:37, 22. Nov. 2011 (CET)
- Ah, vielen Dank. Ein wirkliches Ergebnis scheint es ja nicht gegeben zu haben.... – Gruß, Jackson 13:34, 23. Nov. 2011 (CET)
- Wikipedia:Tellerrand/Archiv/2011#Löschdiskussion, Peer-Reviews, Qualitätssicherung auf Unterseiten pro Beitrag --Der Umherirrende 19:37, 22. Nov. 2011 (CET)
- Schien mit nicht eindeutig so zu sein, da eine Umsetzung bei positiven Diskussionsergebnis wohl einige Zeit in Anspruch nehmen dürfte. MBs dauern immer sehr lange. – Gruß, Jackson 19:33, 22. Nov. 2011 (CET)
Jackson: die Commons/enwp-Lösung finde ich auch gut. -- Nyan ∗ Dog 19:18, 22. Nov. 2011 (CET)
- Matthias 22:46, 21. Jan. 2012 (CET)
- Ich wäre eher dafür, die Löschdiskussionsseiten analog zu den QS-Seiten zu führen, sprich: Erledigte Diskussionen (ohne Veränderung der Überschrift!) per Bot auf eine Unterseite verschieben lassen (und nach Abschluss aller Diskussionen die Unterseite wieder zurück auf die Hauptseite). Dadurch wären die einzelnen Seiten übersichtlicher, da man sich nicht durch beendete Diskussionen durchquälen muss. Zudem würden Links und Bookmarks auf einzelne Unterabschnitte länger funktionieren, da die einzelnen Abschnittsnamen nicht andauernd durch irgendwelche "erledigt", "bleibt", "gelöscht" und sonstige Zusätze verändert werden müssten (stattdessen kann man entsprechende Bausteine verwenden). Und drittens ist die Technik auf den QS-Seiten bereits praxiserprobt und ließe sich daher schnell umsetzen (einen motivierten Bot-Betreiber vorausgesetzt, der dies zu übernehmen bereit ist). --KMic 00:10, 22. Jan. 2012 (CET)
Pro ist leichter zu handhaben und spart Speicherplatz. Gruß
Zur Info: Die Projektdiskussion funktioniert nach demselben Prinzip, die technische Frage wäre also auch hier in de.wp weitgehend gelöst (auch vom Thema Beobachtungsmöglichkeiten her). Wobei allerdings der (von mir betriebene) Bot, der die Unterseiten der Projektdiskussion archiviert, für eine große Funktionsseite wie LK/QS nicht ausgelegt ist. Da müsste man dann was neues basteln.--CroMagnon [disk.] 23:51, 27. Mai 2012 (CEST)
Diskussionsseiten in der französischen Wikipedia
Ich finde die Diskussionsseiten der französischen Wikipedia übersichtlicher und optisch ansprechender. (Beispiel hier) Das Aussehen erinnert leicht an LiquidThreads ([1]), allerdings werden die Beiträge nach dem gleichen System verfasst wie hier. Sieht aber halt schöner aus. --Christian140 18:00, 14. Dez. 2011 (CET)
- Das wurde mal vor Jahren diskutiert, den Link habe ich gerade nicht zur Hand. Kam hier wohl nicht so gut an. -- Liliana • 18:07, 14. Dez. 2011 (CET)
- Wenn das, was ich vermute, nur Optik ist, erweckt es zwar den Anschein von Übersichtlichkeit, ist aber eher unübersichtlicher als das blanke Aussehen hier. Ein Mehrwert wäre nur gegeben, wenn es Möglichkeiten gäbe, Zuordnungen zu kennzeichnen, beispielsweise zu weiter oben liegenden Beiträgen, was dann optisch erkennen ließe, das ein Beitrag sich nicht auf den vorhergehenden, sondern auf einen/welchen älteren Beitrag bezieht. Oder wenn man innerhalb eines Beitrages antworten könnte und der Zusammenhang des vorherigen bliebe bestehen. Aber im Beispiel sieht es so aus, das die IP am 22 novembre 2011 à 12:51 (CET) und Lanredec am 22 novembre 2011 à 14:49 (CET) von einer Person stammten. --Diwas 00:03, 15. Dez. 2011 (CET)
- Find ich mal garnicht. Das ist doch gut unterscheidbar. Ich wäre auch dafür, nicht in erster Linie, weil's schöner aussieht, sondern, weil bei weit eingerückten Beiträgen durch die vertikalen Linien besser sichbar ist welche Beiträge wie weit eingerückt sind und damit auf welchen Beitrag sie sich beziehen. – Gruß, Jackson 11:48, 15. Dez. 2011 (CET)
- Das Problem, welches in der damaligen Diskussion bemängelt wurde, ist, dass man überhaupt keine Leerzeilen im Quelltext mehr haben darf, was einer einfachen Ergänzung zuwider läuft. Sprich, die von dir eingefügte Leerzeile hätte das System schon gestört. --32X 13:02, 15. Dez. 2011 (CET)
- Mit JavaScript geht das schon, aber das ist 1. langsam und 2. wer kein Javascript angeschaltet hat, ist weiterhin betroffen. -- Liliana • 19:00, 15. Dez. 2011 (CET)
- Das Problem, welches in der damaligen Diskussion bemängelt wurde, ist, dass man überhaupt keine Leerzeilen im Quelltext mehr haben darf, was einer einfachen Ergänzung zuwider läuft. Sprich, die von dir eingefügte Leerzeile hätte das System schon gestört. --32X 13:02, 15. Dez. 2011 (CET)
- Find ich mal garnicht. Das ist doch gut unterscheidbar. Ich wäre auch dafür, nicht in erster Linie, weil's schöner aussieht, sondern, weil bei weit eingerückten Beiträgen durch die vertikalen Linien besser sichbar ist welche Beiträge wie weit eingerückt sind und damit auf welchen Beitrag sie sich beziehen. – Gruß, Jackson 11:48, 15. Dez. 2011 (CET)
- Naja, ich finde zwar, das Leerzeilen den Quelltext übersichtlicher machen, aber da könnte man drauf verzichten. Sachen, die das langsamer machen lohnen allerdings imho für so eine Kleinigkeit nicht. – Gruß, Jackson 19:16, 15. Dez. 2011 (CET)
- Für alle, die das Design ebenfalls wollen: Einfach folgenden Code in eurer common.css-Datei anfügen:
.ns-talk dl, .ns-talk dl dl dl, .ns-talk dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl {
background: none repeat scroll 0 0 #F5FAFF;
}
.ns-talk dl dl, .ns-talk dl dl dl dl, .ns-talk dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl dl {
background: none repeat scroll 0 0 white;
}
.ns-talk dl {
border-left: 1px solid #A7D7F9;
border-top: 1px solid #A7D7F9;
margin-left: 1em;
padding-left: 0.5em;
padding-top: 0.5em;
}
Gruß --Nightfly85 | Disk 12:20, 8. Jun. 2012 (CEST)