Wikiup:Verbesserungsvorschläge/Archiv/2010/März

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Projektseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikiup:Verbesserungsvorschläge/Archiv/2010/März#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Wikiup:Verbesserungsvorschl%C3%A4ge/Archiv/2010/M%C3%A4rz#Thema_1

Beitrags-Beobachtungsliste

Hallo! Ich hätte gern die Möglichkeit, auf einer Liste, ähnlich der Beobachtungsliste, die Beiträge mehrerer Benutzer beobachten zu können (entsprechend der die man einträgt). Also sozusagen mehrere Beitragslisten in einer. Das wäre für Mentoren wie mich eine tolle Sache, weil man nicht die Beitragsseite eines jeden Mentees einzeln aufrufen müsste sondern alle auf einer Seite hat. -- Don-kun Diskussion Bewertung 19:15, 7. Mär. 2010 (CET)

Sicher. Abgesehen davon dass es eine Idee für bugzilla wäre: wie weit wäre es - in den Händen einiger Benutzer - zum Stalking? Das ist das Problem, denke ich. -jkb- 19:18, 7. Mär. 2010 (CET)

Stalking kann man jetzt schon super betreiben, entweder indem man sich den Namen merkt oder zB Don-kun (Diskussion • Beiträge • gelöschte Beiträge • hochgeladene Dateien • SBL-Log • Sperr-Logbuch • globale Beiträge • SUL • Logbuch{{Wikipedia:Schiedsgericht/Auflagen und Maßnahmen/Vorlage|Don-kun}} • sperren) irgendwo hat, zB auf einer eigenen Unterseite zum Beobachten. Und wie wärs, wenn man das exklusiv auf den Mentorenbaustein einschränkt? Also es werden nur die auf der Liste geführt (automatisch), die diesen Betreuungsbaustein auf der Seite haben. Und die Liste sieht nur deren Mentor. Kann man das per Skript machen? -- Don-kun Diskussion Bewertung 19:25, 7. Mär. 2010 (CET)

Klar, es wäre nur eine leichte Verbesserung der Möglichkeiten. Übrigens, siehe auch bugzilla:1492. -jkb- 19:32, 7. Mär. 2010 (CET)

Ich verstehe nicht wirklich was die da so sophisticated von sich geben. Gäbs denn eine Möglichkeit sowas kurzfristig auch mit Java-Skript zu lösen? (also für die, die ein solche dann auch einbinden, is klar) -- Don-kun Diskussion Bewertung 19:34, 7. Mär. 2010 (CET)

Auf dem Toolserver gibts so was: [1] --Schnark 09:25, 8. Mär. 2010 (CET)

Naja das ist zum Socken-Finden bzw. Socken-Ausschließen. Aber ich such ja was, das sich die Benutzer merkt und nicht jedes mal neu eingerichtet werden muss. -- Don-kun Diskussion Bewertung 10:14, 8. Mär. 2010 (CET)

Man muss die Ergebnisseite nur als Lesezeichen setzen oder auf eine Unterseite stellen, dann merkt sich Erwin auch die Einstellungen. http://toolserver.org/~erwin85/contribs.php?lang=de&family=wikipedia&users=Don-kun%7CSchnark&limit=100&submit=Submit 77.0.43.103 10:19, 8. Mär. 2010 (CET)

Gute Idee, hab ich mal gemacht. Aber eine richtige Lösung ist das auch noch nicht. -- Don-kun Diskussion Bewertung 15:02, 8. Mär. 2010 (CET)

Bildinformationen nachtragen

Meiner Ansicht nach sind die Möglichkeiten beim Nachtragen von Dateiinformationen, z.B. Lizenzvorlagen verbesserbar: Beim Hochladen habe ich z.B. für die Lizenz ein schönes Drop-Down-Feld. Wenn ich aber eine Lizenz später nachtragen will, ist das wesentlich weniger einfach. Besonders nachdem das ja eher ein Problem von Anfängern sein dürfte, könnte eine Verbesserung in diesem Bereich vielleicht einige Dateien retten helfen, wer schon beim Ersthochladen Probleme hat, ist beim Nachtragen vmtl. häufig überfordert?--Svíčková na smetaně 08:04, 15. Mär. 2010 (CET)

Bessere Fehlermeldung wenn die Suche nicht findet

MediaWiki:Searchmenu-new ist momentan:

Der Artikel „$1“ existiert nicht in diesem Wiki.
Wenn Dir die folgenden Suchergebnisse nicht weiterhelfen, wende Dich bitte an die Suchhilfe.

Das ist problematisch, weil so oberhalb der Suchergebnisse in leuchtend roter Farbe genau das steht, wonach man gesucht hat, so klicken viele auf den Link und landen auf einer Seite, auf die sie gar nicht wollten. Das zumindest wäre eine Erklärung für viele neue Artikel die in Frageform verfasst sind, oder als Beschwerden, dass es den Artikel nicht gibt, oder als Chat/Forenbeiträge mit einem Hallo oder einer Vorstellung. Ich würde gerne mal sehen was passiert, wenn dort stattdessen sowas steht wie:

Der Artikel „$1“ existiert nicht in diesem Wiki. Du kannst den Artikel erstellen (Anleitung).
Wenn Dir die folgenden Suchergebnisse nicht weiterhelfen, wende Dich bitte an die Suchhilfe.

So bleibt die Möglichkeit über die Suchfunktion zur Erstellungsmaske zu kommen erhalten und hinreichend klar für interessierte Autoren, und für die nicht an der Artikelerstellung interessierten zieht der Link nicht mehr so viel Aufmerksamkeit auf sich. 94.223.219.94 20:43, 23. Mär. 2010 (CET).

So schlecht finde ich den Vorschlag nicht. Gibt es Einwände? --Euku:^⇄ 15:40, 3. Apr. 2010 (CEST)

Dem kann ich mich nur anschließen. Der Umherirrende 18:23, 12. Apr. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:23, 12. Apr. 2010 (CEST)

„Trainingsaudio“

In der gesamten WP brauche ich meine Augen, um mich zurechtzufinden. Manche Artikel sind vertont, doch Wiki-interne Seiten muss ich stets von oben bis unten (meist mehrmals) durchlesen, wenn ich sie langfristig verinnerlichen will. Viele Neuankömmlinge bauen gerade am Anfang viel Scheiße, die sie aus bloßer Unwissenheit begehen; ich persönlich bin gut 3 Monate dabei und kenne immer noch nicht einmal alle wichtigen Relevanzkriterien, NPOV-Indikatoren, Qualitätsansprüche, Weblinkbestimmungen, Literaturrichtlinien und Wikiquette-Regeln. Das Ohr ist (mehr oder weniger) bekanntlich meist schneller in seiner Informationsaufnahme bzgl. Worten/Texten, kann also längere Texte/Reden im Verhältnis zum Auge schneller aufnehmen & verarbeiten. Hier nun der Vorschlag:

Zentrale Seiten wie Wikipedia:NPOV, Wikipedia:RK, Wikipedia:WEB, Wikipedia:Quellen usw. im Rahmen des Projekts Gesprochene Wikipedia abschnittsweise (um auf Änderungen besser reagieren zu können) vertonen und zusätzlich in alle Begrüßungsvorlagen einbauen, um neuen Wikipedianern eine „völlig andere Qualität des Einstiegs“ (entschuldigt das Werbesprech) zu ermöglichen. Alte Hasen hätten hierdurch natürlich auch noch einen weiteren Zugang zu den Richtlinien. Gude -- Hæggis 19:10, 7. Mär. 2010 (CET)

Seit ein paar Monaten existiert die Seite Wikipedia:Archiv/Multimediale Hilfe. Benutzer:Souffleuse hat sich dort für kleinere Texte schon bereit erklärt, vielleicht sprichst du sie einfach mal auf ihrer Diskussionsseite an? --Schnark 09:17, 9. Mär. 2010 (CET)

Guter Hinweis, danke. -- Hæggis 18:00, 26. Mär. 2010 (CET)

Ankündigung eines neuen Artikels

Ich möchte an dieser Stelle anregen, eine Art Schwarzes Brett einzurichten, auf denen Autoren ankündigen können, an welchen größeren Artikeln sie gerade arbeiten. Damit könnte vermieden werden, daß es gerade bei umfangreicheren Fachartikeln zu Überschneidungen oder zu sinnlosen Doppelbearbeitungen kommen kann. Konflikten könnte so auch vorher der Wind aus den Segeln genommen werden. Das könnte später in Richtung der schon vorhandenen Fachgruppen weiter ausgebaut werden (zum Beispiel in Form von gemeinsamen Literaturlisten etc.) -- vortex_ 15:04, 6. Mär. 2010 (CET)

Das gibts doch schon so gut wie in jedem Portal, oder? Was macht man mit Themen, für die es keine Portale gibt :(-- ✓ ^Bergi 17:39, 6. Mär. 2010 (CET)

Bei Themen, für die es keine Fachportale gibt, empfehle ich den Autoren, den Artikel als Stub anzulegen und ihn mit Inuse-Baustein und entsprechenden Hinweisen auf der Diskussionsseite zu versehen. Ein allgemeines Schwarzes Brett für die gesamte Wikipedia halte ich nicht für praktikabel. --Snevern ^{(Mentorenprogramm)} 19:49, 28. Mär. 2010 (CEST)

Inflations-Vorlage analog zur Julgregdatum-Vorlage?

Es gibt ja bekanntlich die Vorlage:Inflation die z.B. ausgibt, wieviel 20 DM aus dem Jahr 1950 heute inflationsangepasst in Euro wären. In diesem Fall würde {{Inflation|DE|20|1950}} z.B. den Wert 58 ausgeben. Ich halte das, insbesondere wenn es dann um Reichsmark und noch ältere Werte geht, für eine sehr nützliche Information die ein wesentlich besseres Gefühl für z.B. die Kostendimension vermittelt. Den Wert einzubinden erfordert aber meist eine sehr ausführliche und komplizierte Erklärung in Klammer, so dass die Vorlage heute nur in wenigen Fällen eingesetzt wird. Ich würde deshalb gerne eine Vorlage analog zu Vorlage:JULGREGDATUM schaffen, die statt dem einfachen Zielwert so etwas wie 20 DM^{2010: 46 Euro, [i/?]} einfügt. Meinungen? --Studmult 12:26, 29. Mär. 2010 (CEST)

ref-vorschau

eben habe ich schon wieder zweimal unnötig die versionsgeschichte belastet, da ich kleinigkeiten bei einem einzelnachweis übersehen hatte. gerade hier gibt es viele fehlerquellen - warum gibt es keine vorschau, auch wenn man - wie sich das gehört - nur einen abschnitt bearbeitet? widerspricht das irgendwie dem wikimedia-softwaredesign? gruß --Jwollbold 22:09, 25. Mär. 2010 (CET)

Gibt es für die Monobook unter Benutzer:ParaDox/monobook/VirtualReferences.js. Ließe sich sicher auch als Gadget verfügbar machen.--Flominator 22:18, 25. Mär. 2010 (CET)

... und kann hilfweise gelöst werden, indem man unter den Abschnitt <references /> setzt (und natürlich vor dem Abspeichern nicht vergisst, das wieder zu entfernen ;-) -- Jesi 18:05, 31. Mär. 2010 (CEST)

Bapperldisk

Viele lesenswerte und exzellente Artikel wurden nach arg unterschiedlichen Kriterien ausgezeichnet, weil zu verschiedenen Zeiten kandidiert. Vgl. dazu diesen Beitrag von Vux.

Klick ich im Lemma Byzantinisches Reich oben rechts auf das -Bapperl, komm ich bei dieser Zeile raus. Der Link zu allen exzellenten Artikel ist natürlich angebracht, könnte evtl. noch spezifischer sein a lá Exzellente Geschichtsartikel o.ä. Um in diesem Fall die entsprechende Kandadaturdiskussion zu finden, musste ich bis zum 31. März 2004 zurückspringen und anschließend doch selbst im KALP-Archiv nachblättern. Dort konnte ich auch nach längerer Suche den Bewertungsprozess nicht finden, doch das mag (hoffentlich) eine Ausnahme sein.
Für Mitarbeiter wäre ein Direktlink zur entsprechenden Diskussion – sofern noch vorhanden – auf die konkrete Kandidatur äußerst hilfreich, um Entscheidungen nachvollziehbar zu machen und die argumentative Arbeit, oft mit Quellenarbeit verbunden, für einen weiteren Ausbau nicht verloren gehen zu lassen. Zudem könnten evtl. Änderungen an Artikelelementen, auf Grund derer sie ursprünglich für lewe./exzell. befunden wurden, besser für die Bewertung des aktuellen Artikelzustandes herangezogen werden. (Hypothetisches) Beispiel: Wird Bananenkrieg für befunden, weil der Artikel die Folgen & entsprechenden Abkommen sehr gut darstellt, und im Anschluss wird beschlossen, genau diesen Teil in einen entsprechenden Hauptartikel auszulagern, läge bei Driektlink zur K-Disk nicht Monate lang eine lewe-Leiche herum, bei der keiner mehr weiß, warum sie eigentlich so bewertet wurde, aber ebenso niemand den Bapperl unbegründet entfernen will. -- Hæggis 19:19, 28. Mär. 2010 (CEST)

Die Vorlage:Exzellent hat zwei optionale Parameter, wo zumindestens die Version und das Datum genannt werden kann, auf welchem der Status vergeben wurde. Die Diskussion zu verlinken halte ich nicht für nennenswert, da sie kaum ein Leser interessieren wird (persönliche Sicht), eventuell auf der Diskussionsseite könnte man sie verlinken (oder in der Versionsgeschichte, wenn man die Vorlage einsetzt, aber das wird man nicht erreichen können). Der Umherirrende 16:37, 30. Mär. 2010 (CEST)

In der Versionsgeschichte muss man ewig (= m.E. zu lang) suchen, aber mit dem Link auf der Diskseite könnte ich mich anfreunden.

Die Grenze zwischen Mitarbeiter & Leser ist ohnehin schwammig bzw. fließend, der Hinweis am Ende eines Artikels bezieht sich ja nicht auf den Artikel selbst, sondern auf eine assoziative Metastruktur WP-interne-Sammlung, die auf eine Lemma-übergreifende Wiki-Seite und eben nicht interessenspezifisch verlinkt wird (das würde im Fall Weitere lesenswerte Artikel aus [dem Portal] Gesellschaft/Sozialpsychologie zutreffen). Der Link muss ja nicht sonderlich auffallen, im Prinzip genügt

„Dieser Artikel wurde nach dieser Kandidatur in die Liste der lesenswerten Artikel aufgenommen.“

Mir gehts um die Transparenz bzw. leicht zugänglichen Nachvollziehbarkeit von WP-Entscheidungen. Ein erfahrener Mitarbeiter fände sich schnell zurecht; ein Leser, der den Artikel furchtbar findet, wird sich evtl. auch dafür interessieren, weshalb das Lemma besonders gut bewertet wurde. -- Hæggis 19:01, 30. Mär. 2010 (CEST)

Es gibt nur noch einige ganz alte Exzellente, bei denen die Kandidatur-Diskussion nicht auf der Artikel-Disk-Seite ist. Bei allen anderen sollte sie dort zu finden sein. Da ist das größere Problem die Archivierung, dass man dort u.U. verschiedene Archive durchsuchen muss, bis man die Kandidatur-Disk findet (ein Grund dafür, dass ich von automatischer Archivierung auf Artikel-Disk-Seiten nicht halte). Viele Grüße --Orci Disk 18:12, 31. Mär. 2010 (CEST)

Auf der Disk-Seite wärs ebenfalls sehr handlich, auch wenn sich die Klick-auf-das-Exzellenz-Symbol-Zeile geradezu anbietet. Mit den automatischen (aber z.T. auch manuellen) Archivierungen isses tatsächlich ein Problem, auch hier muss man entweder das Disk-Archiv oder generell auf Dis-Seiten das evtl. ellenlange Inhaltsverzeichnis durchstöbern, ehe man zum Ziel gelangt. Da es sich um eine übergreifende Struktur/Bewertung handelt, sollte das zugehörige Verfahren direkt & schnell verfügbar sein, also vllt. das /-Symvol auch auf der Disk-Seite mit Kandidatur-Link? Diese Doppelbebapperlung (Zungenbrecher ;) wäre gut umgangen, wenns – nenn mich knorrig – gleich in der K-a-d-l/e-S-Zeile eingebaut wird. Eine Schar an Grüßen zurück, Hæggis 00:35, 3. Apr. 2010 (CEST)

Allgemeine Zeitangaben definieren

Leider werden vielfach allgemeine bzw. nicht definierte Zeitangaben wie heute, Tag, Monat, Jahr, Jahrhundert, derzeit, Gegenwart, nun , vor usw. verwendet. Diese erlauben es dem Leser nicht zeitliche Bezüge oder die Aktualität abzuleiten Daher sollten Richtlinien, Definitionen und Konventionen hierfür aufgestellt werden. Z. B. mittels Zeitangabe in Klammern oder vorzugsweise mittels definierter Zeitangabe:

Anstatt von "Heutzutage ist es üblich ...": Heutzutage (2010) ... / Im Jahr 2010 war ... / In den 2010er Jahren war ...

Anstatt von "In der Gegenwart hat sich ...": / In der Gegenwart (2010)... / Im Jahr 2010 hatte sich ...

Anstatt von "Letztes Jahr ...": Letztes Jahr (2009) / Im Jahr 2009

Anstatt von "Ab heute wird sich Alles ändern.: / Ab heute (31.03.2010) sollte ... Ab dem 31.03.2010 sollte sich alles verändern

Anstatt von "In frühestens 10 - 20 Jahren wird ...": In frühestens 10 - 20 Jahren (ab 2010) / Frühestens ab 2020 - 2030 (verfasst 2009) wird ... / Aus heutiger Sicht (2009) wird frühestens in 2020 - 2030 ...

Anstatt von "In den nächsten Monaten ...": In den nächsten Monaten (ab März 2010)...

Anstatt von "Erst jetzt wird mit der Umsetzung ...: Erst am 31.03.2010 sollte ...

Anstatt von "Die Rechtslage in den USA unterscheidet sich insgesamt gravierend von derjenigen in Europa siehe: Die Rechtslage in den USA unterscheidet sich insgesamt gravierend von derjenigen in Europa (2010) / Die Rechtslage im Jahr 2000 in den USA unterscheidet sich insgesamt gravierend von derjenigen in Europa

Die Bezüge auf das laufende Jahr, sofern bereits eingetreten, sollten in der Vergangenheitsform geschrieben werden, damit eine künftige Überarbeitung der Zeitangaben nicht notwendig wird. Z.B. Nun (2010) beginnt eine neue Ära / Ab 2010 begann ... Anstatt von "; Im laufenden Jahr beginnt .../ Im Jahr 2010 sollte ... beginnen

--Sparko1 17:54, 31. Mär. 2010 (CEST)

Um Gottes Willen. "In den nächsten Monaten" bezieht sich in meinen Artikeln auf ein bestimmtes Datum, das zuvor angegeben wurde und bezieht sich nahezu nie auf 2010. Sowas muß immer in der Praxis entschieden werden, ein Automatismus ist Unsinn. Und den Stand bestimmter Aussagen anzugeben ist weit verbreitet im Projekt. Marcus Cyron 03:55, 3. Apr. 2010 (CEST)

Zusammenfassungszeile kürzen

Änderung5845225 von asr wurde rückgängig gemacht: versus: Änderung 25857587 von dsfears rückgängig:

Spart zwei Worte, mehr Platz für Begründungen. -- TJ.MD Fasse Dich kurz. 17:39, 4. Mär. 2010 (CET)

Nachdem ich erfasst habe, was du mit dieser Überschrift ausdrücken wolltest: Nein. Erstens ist deine Variante sprachlich unschön (zumindest ohne Begründung dahinter), und zweitens brauchen wir keine 2 Wörter zu sparen. Wenn du mehr Platz brauchst, dann wende dich an die Diskussionsseite, gib deine Quellen als ref an oder bitte bei Bugzilla um mehr Zeichen in der Zusammenfassung. Und „zur Not“ kannst du immer noch den Hinweistext einfach weglassen oder händisch auf Revert wegen blablabla kürzen. -- ✓ ^Bergi 19:47, 4. Mär. 2010 (CET)

Ich würde es eher begrüßen, wenn die Revisionsnummer, für die sich sowieso keiner interessiert aus der Standardbegründung rausfallen würde. Gerade bei einem Revert will man eben direkt in der Zusammenfassungszeile erklären, warum man die Änderung rückgängig gemacht hat und nicht erst auf die Diskussionsseite verweisen. --Schnark 09:41, 5. Mär. 2010 (CET)

Schnark: Zustimmung. --Snevern 10:13, 5. Mär. 2010 (CET)

Die Revisionsnummer kann sich doch später als wichtig oder interessant erweisen. Und, wenn der Platz nicht reicht, schreibe dorthin doch "siehe Diskussionsseite" und da kann sich jeder austoben. -jkb- 10:36, 5. Mär. 2010 (CET)

Die Begründung mit dem schlechten Sprachstil kann ich nicht teilen: In der Zusammenfassungszeile kommt es nun wahrlich nicht auf Stil an, zudem enthält auch die derzeitige Standartzeile 'keinen ' vollständigen Satz, es fehlt der Artikel DieÄnderung (..). Begründung soll ja dahinter, deswegen auch mehr Platz. TJ.MD Fasse Dich kurz. 11:10, 5. Mär. 2010 (CET)

@-jkb-: Für was könnte sich die Revisionsnummer in der Bearbeitungszeile des Reverts später als wichtig oder interessant erweisen? Und eine Garantie, dass sie drinbleibt, ist die vorgegebene Aufnahme nicht, denn jeder kann sie streichen.

@TJ.MD: Ich kürze die vorgegebene Begründung auch öfter mal von Hand, als erstes fliegt immer die Nummer raus. Aber für die meisten Reverts dürfte der Platz doch ausreichend sein, und wenn nicht, hilft "siehe Disk.". --Snevern 11:35, 5. Mär. 2010 (CET)

Ich könnte mir folgenden Satz vorstellen: „Änderung 1234567 von Benutzer entfernt.“ Kurz, verständlich, vollständiger Satz. --Fomafix 11:39, 5. Mär. 2010 (CET)

Bitte nicht. Unter entfernt stelle ich mir eine von einem Admin oder Oversign gelöschte Version vor. Das gibt nur Verwirrung.jodo 12:15, 5. Mär. 2010 (CET)

Dann sollte der Text des dazugehörigen Knopfs geändert werden, denn der heißt (entfernen). --Fomafix 12:23, 5. Mär. 2010 (CET)

stimmt, das verwirrt mich auch immer wieder, konnte mich nie damit anfreunden weshalb ich althergebracht reverte. --Aineias © 23:19, 5. Mär. 2010 (CET)

Das liegt daran, das der Text standardmäßig "rückgängig" heißt, aber von einem Admin umbenannt wurde (und der Begründungstext nicht). Es haben sich zwar viele Leute aufgeregt, aber auch genauso viele fanden es gut (grob geschätzt). Daher hat sich keiner getraut das wieder rückgängig zu entfernen. Der Umherirrende 19:51, 6. Mär. 2010 (CET)

„Creek hat in den amerikanischen Englisch eine andere Bedeutung (nämlich Bach) als im britischen Englisch (nämlich Priel) und wiederum als im Aussie-Englisch (nämlich Wadi) als im indischen Englisch (nämlich eine von Mangroven umwachsene Salzwasserbucht). Bei geographischen Artikeln muß man da höllisch aufpassen, was die Quelle eigentlich meint. (Lt. USGS gibt es 121 Bezeichnungen im Englischen für ein Fließgewässer, rund 190 verschiedene generische Namen für einen Berggipfel.)“ (Matthiasb in dieser Disk)

Wie viel muss ich zu einer einzelnen Wortbedeutung hinzuschreiben müssen, um den Sinn der Aussage zu vermitteln? Solche Hudeleien müssten m.E. ganz schnell entfernt (rückgängig gemacht?) werden; mir egal welches Wort für welchen Vorgang das passendere sei, doch auf jeden Fall sollten sie einheitlich verwendet werden, wenn wir noch in der Lage sein sollen, uns etwas über Revertvorgänge zu mitzuteilen. -- Hæggis 18:49, 7. Mär. 2010 (CET)

Mir ist in letzter Zeit immer wieder der Platz ausgegangen, um Reverts zu begründen. Auf der Disk-Seite würden oft schätzungsweise 3-5 Wörter stehen, für die in der Zusammenfunggszeile kein Platz mehr war; so werden viele Reverts, die speziellere Begründungen als „Mag stimmen, doch bitte belegen.“ oder „Bitte nicht unbegründet vorhandene Belege entfernen.“ erfordern, mit übelsten z.T. unverständlichen Abkürzungen versehen. Die Ticketnummern helfen bzgl. der Übersichtlichkeit nicht weiter, weil manchmal Monate alte Bearbeitungen revertiert werden. Zumal kann sie jeder entfernen, wodurch der Übersichtlichkeits-Apekt auch für jene entfällt, die mit der Zahl was anfangen können. Idee:
Änderungen/Bearbeitung (Direktlink zur Änderung) (vom 8. März 2010) zurückgesetzt:

Noch etwas: wenn ich alle Bearbeitungen eines (gutmeinenden!) Autors revertiere, muss ich ihn entweder auf der Benutzerdisk anschreiben, die Artikeldisk benutzen oder schnell was am Artikel selbst – wenn möglich – verbessern, um die Zsf-Zeile verwenden zu können. Eine Option auf Begründung bei „Änderungen von 192.68.0.1 rückgängig gemacht und Version von …“ wäre sehr hilfreich. -- Hæggis 18:49, 7. Mär. 2010 (CET)

Das ist eigentlich auch nicht der Sinn des Zurücksetzen. Alternativ kann man die alte Version öffnen und speichern. Für die Zurücksetzen-Funktion (rollback) gibt es bereits verschiedene JavaScript-Lösungen (beispielsweise unter WP:Skin#Revolus/#Benutzer:Codeispoetry) Der Umherirrende 18:56, 7. Mär. 2010 (CET)

Allet klar, danke für die Links. Was sagst du zu der Idee der automatisch verlinkten & erheblich verkürzten Änderungszeile (die m.E. auch nicht aus der Zfs.-Zeile entfernt/gelöscht werden können sollte)? -- Hæggis 19:13, 7. Mär. 2010 (CET)

Das ist mir nicht so wichtig, da ich damit nicht häufig in Berührung komme. Ich denke aber, dass die Freiheit der Gestaltung der Zusammenfassungszeile nicht genommen werden sollte. Der Umherirrende 17:39, 8. Mär. 2010 (CET)

Die Freiheit sollte m.E. in der Begründung liegen, nicht in der Revert-Markierung. Artikelarbeiten brauchen oft Stunden, ein Zurücksetzen/Entfernen/Rückgängigmachen-Klick ist im Bruchteil einer Sekunde geschehen, oft genug kommentarlos an Stellen, an denen es eines Statements bedarf. Hier ein gar nicht so alter Aufreger dazu. -- Hæggis 06:13, 9. Mär. 2010 (CET)

In en-WP gibt es auf Special:My preferences ein Gadget, das einem 50 zusätzliche Zeichen spendiert; es funzt aber wohl nicht mit allen Browsern (bei mir – FF 2 – ging's). Irgendwie kann man doch auf de-WP auch Scripte aus anderen Projekten einbinden, aber ob das auch mit Gadgets aus dem MediaWiki-Namensraum geht? Zu finden ist es unter en:MediaWiki:Gadget-LongEditSummaries.js; vielleicht kann man das auch hier anbieten? Unabhängig davon könnte man auch in MediaWiki:Undo-summary Special:Contributions durch Spezial:Beiträge ändern. Damit hätten wir auch schon mal 5 Buchstaben gespart (die mir auch schon oft gereicht hätten). Gruß --Schniggendiller Diskussion 14:34, 14. Mär. 2010 (CET)

Special:Contributions durch Spezial:Beiträge zu ersetzen ist auf jeden Fall sinnvoll.
Das die Eingabelänge per JavaScript verlängert werden kann bringt mich gerade zum stauen. Das Eingabefeld ist per HTML-Attribut maxlength="200" begrenzt. Die Datenbank kann aber anscheinend mehr. Ich vermute, dass die Datenbank 255(?) Bytes verarbeiten kann, die Eingabe erfolgt aber in UTF-8. Wenn ich in die Eingabezeile viele nicht ASCII-Zeichen schreibe, dann müsste die Eingabe nicht mehr in die Datenbank passen. Ich habe mal folgendes in die Eingabezeile geschrieben:

/* Zusammenfassungszeile kürzen */ Lange Eingabezeile €€€€€€€€€1€€€€€€€€€2€€€€€€€€€3€€€€€€€€€4€€€€€€€€€5€€€€€€€€€6€€€€€€€€€7€€€€€€€€€8€€€€€€€€€9€€€€€€€€€0€€€€€€€€€1€€€€€€€€€2€€€€€€€€€3€€€€€€€€€4€€€€€€

Mal schauen, wieviele Zeichen im Änderungskommentar übrig bleiben. Raymond habe ich auf ein solches Problem schon mal angesprochen: Benutzer Diskussion:Raymond/Archiv 2010-1#Ungültiges UTF-8-Zeichen. --Fomafix 15:12, 14. Mär. 2010 (CET)

Gegen das Ersetzen von Special:Contributions durch Spezial:Beiträge. Und das wegen 5 (FÜNF!!) läppische Buchstaben. -jkb- 15:19, 14. Mär. 2010 (CET)

Es werden sogar nur vier Byte eingespart, denn Spezial:Beiträge enthält ein Umlaut. Die Ersetzung ist trotzdem sinnvoll, denn {{#Special:Contributions}} ergibt Spezial:Beiträge. --Fomafix 15:30, 14. Mär. 2010 (CET)

Eine praktische Modifikation, doch leider nur angemeldeten Benutzern zugänglich. Daher noch mal der Vorschlag:

Die bisherige Zusammenfassungzeile nach dem Klick auf entfernen lautet:

• Änderung 72384144 von Hæggis wurde rückgängig gemacht. Dies ist eine Testbegründung.

Weil viele unbegründete Reverts für noch mehr Ärger, Frust, & Demotivation bei Artikelautoren sorgen und auch zukünftig sorgen werden, eine Änderung zu:

• Bearbeitung/Änderung vom 26. März 2010 zurückgesetzt: Dies ist eine Testbegründung.

Der kursiv geschrieben Teil ließe sich nicht aus der Z-Zeile entfernen, weil 2-Klick-Reverts gegenüber oft stundenlanger Arbeit stets angezeigt werden sollten. Vor allem beziehen sich die Reverts manchmal auf Bearbeitungen, die Monate zurückliegen, mit einer Ticketnummer wie 72384144 kann ein OMA-Benutzer (zu denen ich in diesem Fall auch zähle) nicht viel anfangen. Der blau gefärbte Text wäre ein Direktlink zur Bearbeitung, um schnell sehen zu können, welche denn nun gemeint ist. Kritik? Gude, Hæggis 18:26, 26. Mär. 2010 (CET)

Entschuldigung, wenn ich mal was ganz dummes dazwischenfrage - aber kann ich denn tatsächlich eine zeitlich weiter zurückliegende Bearbeitung revertieren, wenn zwischenzeitlich mehrere neue Edits erfolgten!? Es wird doch bei jeder Änderung der gesamte Artikel neu abgespeichert - demnach kann ich eine weiter zurückliegende Bearbeitung nicht revertieren, ohne auch die seither vorgenommenen Änderungen mit zu verwerfen. Oder mache ich da grad einen Denkfehler? Dann bitte ich um Aufklärung... --Snevern ^{(Mentorenprogramm)} 19:10, 26. Mär. 2010 (CET)

Ja, aber das geht nur dann, wenn die Änderung in einem Abschnitt liegt, wo es danach noch zu keiner Bearbeitung kam - sonst kommt eine Fehlermeldung. -jkb- 19:17, 26. Mär. 2010 (CET)

Soll heißen: Artikel "X" besteht aus zwei Abschnitten. Im Januar wird Abschnitt eins von User A bearbeitet - inhaltlich grober Unfug. Bevor das jemand merkt, bearbeitet im Februar User B Abschnitt zwei mit zahlreichen, sinnvollen Edits. Im März kann einer hergehen und die Bearbeitung von User A vom Januar revertieren, ohne die Edits von User B vom Februar im anderen Abschnitt zu entfernen?

Muss sagen: ich bin beeindruckt - und hab schon wieder was gelernt...

Wie geht das - sprich: wie mache ich selbst das? Und wie kriegt die Software das hin - durch Vergleich der von Edit/Revert betroffenen Abschnitte mit den korrespondierenden Abschnitten der aktuellen Version? --Snevern ^{(Mentorenprogramm)} 19:44, 26. Mär. 2010 (CET)

Das geht mithilfe der "Entfernen"-Links in der Versionsgeschichte Beispiel. Du siehst, das auf deinen Abschnitt bereits geantwortet wurde, ich ihn aber noch entfernen könnte. Technisch wird ein Diff der beiden Versionen erstellt, wenn sich in dem Diff nichts überschneidt, kann der Abschnitt ja entfernt werden und dann wird der Rest gemerged. Ähnlich wie bei den automatisch zusammengefügten Bearbeitungskonflikten. Der Umherirrende 20:33, 26. Mär. 2010 (CET)

Schönes Beispiel. -jkb- 20:38, 26. Mär. 2010 (CET)

*räusper* Ob es wirklich funktioniert, hab ich kurz vorher nochmal überprüft. Hat mich Anfangs auch gewundert & v.a. geärgert, weil ich keine Ahnung hatte (und es bis heute nicht weiß), welcher Edit mit entsprechender Z-Zeilen-Begründung revertiert wurde. Was sagt ihr zum Vorschlag? Gruß -- Hæggis 18:47, 28. Mär. 2010 (CEST)

Ähm... ja, tschuldigung, Hæggis. Jetzt, wo ich weiß, worum's geht und dass das geht, finde ich deinen Vorschlag gut - solange es wirklich nur ums Zurücksetzen geht. Bei allen anderen Bearbeitungen sollte der Editierende auch weiterhin die Zusammenfassungszeile frei wählen können. --Snevern ^{(Mentorenprogramm)} 18:53, 28. Mär. 2010 (CEST)

Kein Problem, wer geht nicht gern andere Wege… Jups die Z-Zeile sollte immer Platz für individuelle Kommentare lassen, weshalb auch beim Zurücksetzen aller Bearbeitungen eines Mitarbeiters Platz für eine Begründung sein sollte (bisher verbesser´ ich schnell krampfhaft was am Artikel, um die Z-Zeile im Anschluss nutzen zu können). Doch hier gehts erstmal um Einzelrevets, die für viel Ärger sorgen. Gude, Hæggis 19:25, 28. Mär. 2010 (CEST)

Hæggis, wenn ich mich nicht sehr irre, ist dein Vorschlag den vom 26.3. meine ich technisch nicht realisierbar: Wenn du in der Zusammenfassungszeile den Link Spezial:Beiträge/Schniggendiller unterbringst und den Link „maskierst“ und daraus Schniggendiller machst, verbrauchst du scheinbar nur 15 Zeichen (von 200), tatsächlich sind es aber 52: [[Spezial:Beiträge/Schniggendiller|Schniggendiller]]. Hinter dem blauen Text „Bearbeitung/Änderung“ in deinem Beispiel verbirgt sich ein noch viel längerer Link à la http://de.wikipedia.org/w/index.php?title=Wikipedia:Administratoren/Anfragen&curid=5022485&diff=72833637&oldid=72833457. Da reicht der Platz nicht für ... Übrigens bin ich strikt dagegen, zu verhindern, daß man Bearbeitung/Änderung vom 26. März 2010 zurückgesetzt: entfernen kann (auch hier bezweifele ich, daß das so ohne weiteres technisch machbar wäre). Manchmal kämpft man um jeden Buchstaben, die man für die eigentliche Begründung braucht; ich ändere dann oft Änderungen von Schniggendiller in Rev. Schniggendiller o. ä., kürze [[Spezial:Contributions/Schniggendiller|Schniggendiller]] zu [[Spezial:Beiträge/Schniggendiller]] oder gar Spezial:Beiträge/Schniggendiller. Trotzdem fehlen einem manchmal einige wenige Buchstaben. Gruß --Schniggendiller Diskussion 00:07, 7. Apr. 2010 (CEST)

Bei längeren Begründungen müsste man auf die Disk ausweichen, da schätze ich den verhinderten Verlust der Info, wer wann mit welcher Z-Zeilen-Begründung etwas eingestellt hat, was nun revertiert wird, als wertvoller ein. Doch mit dem 200-Zeichen-Problem hast du wohl Recht, dafür müsste der Wiki-Quellcode verändert werden, um etwas ,außerhalb‘ dieser 200 Zeilen zu integrieren (z.B. ein ʁ/R-Smybol mit dem Direktlink zur revertierten Version). Schade -- Hæggis 00:57, 16. Apr. 2010 (CEST)

Alternierende Tabellen-Hintergrundfarbe bei sortierbaren Tabellen

<aus WP:FzW> Hallo,

gibt es eine Möglichkeit einer Tabelle alternierende Hintergrundfarben zuzuweisen, die auch im anders sortierten Zustand alternierend bleiben? Ein Ausschnitt meiner Tabelle hier als Beispiel.

Name	Geboren	Gestorben	Alter	Todesumstände
Ida Siekmann	23. August 1902	22. Aug. 1961	58	…
Günter Litfin	19. Januar 1937	24. Aug. 1961	24	…
Roland Hoff	19. März 1934	29. Aug. 1961	27	…

Wenn diese nach dem Geburtsdatum sortiert wird, ist die dunklere Zeile ganz oben oder unten. Um es optisch besser zu halten sollte der dunklere Hintergrund aber in der Mitte bleiben. Gibt es da eine Lösung für oder verlange ich da was unmögliches? blunt. 00:11, 2. Mär. 2010 (CET)

Sogenannte Zebra-Tabellen sind meines Wissens nach nicht mit der Sortierfunktion vereinbar. Bei Tabellen mit nur wenigen Spalten ist diese Gestallung meiner Meinung nach eh überflüssig. Erst recht wenn diese (nicht wie in deinem Beispiel) auch noch schlecht umgesetzt wurd. Wer schonmal Artikel von überflüssiger Tabellensyntax gereinigt hat und danach feststellte, dass über 50 % des Artikels nur redundante Anweisungen waren, weiß was ich meine. --Cepheiden 08:20, 2. Mär. 2010 (CET) P.S. es gab irgendwo mal ein Buch, dass sich mit der Formatierung von Tabellen beschäftigte. Fazit war meines Wissens, dass man auch bei größeren Tabellen auf solche Hervorhebungen verzuchten sollte, da es meist nur vom Inhalt ablenkt und nicht wirklich die Übersicht verbessert

Mit CSS3 würde so etwas gehen:

table.wikitable.zebra tr:nth-child(even) { background:#fcfcfc }

Die Tabelle müsste dann mit

{| class="wikitable zebra sortable"

eingeleitet werden. Eine generelle Aktivierung aller wikitables geht nicht, weil es bei rowspan Probleme macht. Ein genereller Zebrahintergrund für alle sortierbaren Tabellen wäre denkbar, da dort kein rowspan verwendet werden kann:

table.wikitable.sortable tr:nth-child(even) { background:#fcfcfc }

Allerdings müssten diese CSS-Definitionen in MediaWiki:Common.css. --Fomafix 11:07, 2. Mär. 2010 (CET)

Danke. Das klappt, wenn ich es in meine monobook.css einfüge. Jetzt muss ich wohl nur noch einen Finden, der für gut befindet und in die Commons.css setzt. Ich schreib mal Merlissimo und Guandalug an. blunt. 11:39, 2. Mär. 2010 (CET)

Bei der CSS-Definition fehlt aber die Definition der Klasse zebra, wie im Beispiel verwendet. --Mps 13:12, 2. Mär. 2010 (CET)

Deine Anmerkung verstehe ich nicht. Mit

table.wikitable.zebra tr:nth-child(even) { background:#fcfcfc }

wird doch eine CSS-Klasse zebra definiert. --Fomafix 19:05, 2. Mär. 2010 (CET)

Ich auch nicht so recht. Habe es auch gerade probiert, sieht gut aus. Spricht noch etwas gegen diese Änderung außer, dass es manchein Browser noch nicht unterstützt? --Euku:^⇄ 22:24, 2. Mär. 2010 (CET)

Man müsste auf jeden Fall dafür sorgen, dass dies nur auf Bildschirmseiten so dargestellt wird. Beim Druck sollte kein Hintergrund vorhanden sein (auch ohne individuelle Browsereinstellung). Deshalb muss man auch MediaWiki:Print.css entsprechend ergänzen.

Als Farben muss man wahrscheinlich je nach Skin andere wählen, da auch die Hintergrundfarbe eine andere ist.

@blunt Können wir das nach Wikipedia:VV verschieben? Auf diese Disk. sollte man auf noch längerfristig antworten können. Hier ist das sonst in ein paar Tagen im Archiv.

@andere Benutzer: Haltet ihr das auch für sinnvoll? Falls nein könnte man noch auf ein Gadget ausweichen. Merlissimo 22:59, 2. Mär. 2010 (CET)

<Ende Übertrag blunt. 23:09, 2. Mär. 2010 (CET)>

Verschoben.

Danke für eure Anmerkungen. Ich denke, dass wäre eine gute Neuerung. blunt. 23:09, 2. Mär. 2010 (CET)

Im Prinzip: Ja. Natürlich nicht im Druck, wenn möglich auch nicht im PDF. Wer's nicht haben will, kann das dann ja per privater CSS wieder abklemmen. --Guandalug 23:21, 2. Mär. 2010 (CET)

(BK) Als weitere Möglichkeit, Tabellen zu gestalten, wäre das mMn sinnvoll, eine generelle Einführung bei sortierbaren Tabellen finde ich aber nicht sinnvoll. Wenn ich mal eine Tabelle bastele, bevorzuge ich farblosen Hintergrund, auch dass Farben mit Bedeutungen versehen werden habe ich schon gesehen (was mit Zebra-Design dann wohl nicht mehr gehen würde). Viele Grüße --Orci Disk 23:24, 2. Mär. 2010 (CET)

Sehe ich ähnlich. Eine solche "Zebra"-Klasse zu definieren ist okay - und wer sie einsetzen will, kann sie in den Bereichen einsetzen, wo es sinnvoll ist. Solange man Rahmen um die Tabellen hat, sollte es auch auf "screen" beschränkt werden, ansonsten wären natürlich rahmenlose, aber abwechselnd hellgrau/weiße Tabellen im Druck auch sehr angenehm.. aber erstmal im Druck weglassen.

Unterstützt wird das von allen modernen Browsern außer dem IE8, der IE9 wird dies auch beherrschen. Da fehlende Zeilenhinterlegung keine große Sache ist, halte ich das für unproblematisch. --APPER\^☺☹ 10:35, 3. Mär. 2010 (CET)

Zunächst bitte keine Schnellschüsse und zumindest eine Woche darüber diskutieren. Zusätzliche Hintergrundfarben sollten beim HTML-Ausdruck im Browser keine Probleme machen, denn die Browser ersetzen beim Ausdrucken die Hintergrundfarben durch weiß. Für ältere Browser und dem Internet Explorer könnte die fehlende CSS3-Funktionalität mit JavaScript nachprogrammiert werden. Die Hintergrundfarbe der geraden Zeilen lässt sich durch eine solche CSS-Definition nicht mehr an der Tabelle, sondern nur noch an der Zeile oder der Zelle überschreiben. Eventuell sollte die Definition der ungeraden Zeilen daher auch an die Zeile gehängt werden. Vielleicht gibt es auch noch einen Trick, wie beide Farben von die Tabelle aus gesteuert werden können. Eventuell sollte auch eine Einschränkung auf die aktuelle Tabelle gemacht werden, um eventuelle Untertabellen nicht zu beeinflussen: table.wikitable.zebra > tbody > tr:nth-child(even). Wenn diese Erweiterung als nur Gadget realisiert wird, dann wäre eine separate CSS-Klasse zebra schlecht, denn dann würden in Artikel Erweiterungen reingeschrieben, die nur die wenigsten sehen. Als optionales Gadget würde nur gehen, wenn die Artikel unverändert bleiben, und die Aktivierung über eine vorhandene Kennzeichnung geschieht, also table.wikitable.sortable tr:nth-child(even). Eine Erweiterung auf Tabellen ohne wikitable muss wegen dem fehlenden Einfluss auf die Farbe gut überlegt werden, wäre aber denkbar. Da die CSS3-Zebratabellen derzeit nicht überall gleich dargestellt werden, sollte sie keine notwendige Formatierung sein, sondern immer nur eine optische Ergänzung. Der generelle Nutzen von solchen Zebratabellen sollte zusätzlich diskutiert werden. --Fomafix 11:05, 3. Mär. 2010 (CET)

Persönlich halte ich die Erweiterung um Zebra-Tabellen für sinnvoll, dennoch sollte man diesen "Zebra-Look" nur optional und nicht generell verwenden. daThy 10:22, 4. Mär. 2010 (CET)

Was meinst Du mit optional? Optional für den Autor, also class="wikitable zebra" und table.wikitable.zebra tr:nth-child(even) oder optional für den Leser, also als Gadget zu class="wikitable sortable" mit table.wikitable.sortable tr:nth-child(even)? --Fomafix 11:48, 4. Mär. 2010 (CET)

Als Gadget finde ich das nicht sinnvoll, da Gadgets nur für angemeldete Benutzer zur Verfügung stehen. Gadgets sind für Bearbeitungserleichterungen sinnvoll, nicht aber für Dinge, die vorwiegend für Leser von Bedeutung sind. Viele Grüße --Orci Disk 11:52, 4. Mär. 2010 (CET)

Aus der bisherigen Diskussion geht hervor, dass eine neue Tabellenart (zebra sortable) auf breite Zustimmung stößt. Die bestehende Tabellen sollen dadurch nicht geändert werden. Ich bin der Meinung wir sollten das sehr bald einführen. blunt. 12:00, 4. Mär. 2010 (CET)

Bei einer neuen CSS-Klasse zebra habe ich etwas die Sorge, dass das dann Reihenweise in die Artikel eingebaut wird und dann darüber gestritten wird, was „schöner“ aussieht. Eine CSS-Klasse ist aber auf jeden Fall besser als ein manuelles einfärben jeder zweiten Zeile und bei sortieren Tabellen auch zwingend notwendig. Eine Zebra-Tabelle kann bei Bedarf auch wieder normal gemacht werden, durch table.wikitable.zebra > tbody > tr:nth-child(even) { background:transparent }. --Fomafix 13:50, 4. Mär. 2010 (CET)

Ich würde eher eine extra Klasse bevorzugen, also nur table.zebra . Nicht alles was alternierende Hintergründe hat, muss eine wikitable sein.
meint -- ✓ ^Bergi 15:49, 4. Mär. 2010 (CET)

Das ist auch möglich. Eventuell muss eine andere Farbe als #fcfcfc gewählt werden, denn normale Tabellen haben einen weißen Hintergrund und die Zebrafarbe ist von Autorenseite nicht beeinflussbar und gilt für alle Tabellen. #fcfcfc liegt zwischen #ffffff für weiß und #f9f9f9 von wikitable. Bei wikitable sollte die Zebrafarbe heller als das th mit #f2f2f2 sein. Wichtig: Die Farbe sollte im nachhinein nicht mehr geändert werden, denn die Autoren werden die anderen Farben an die vorgegebene Farbe anpassen. --Fomafix 16:48, 4. Mär. 2010 (CET)

Jetzt ist das Thema gute 20 Tage abgehangen. Gibt es neue Einwände oder kann die Umsetzung begonnen werden? blunt. 15:03, 24. Mär. 2010 (CET)

Ich habe nun seit knapp einem Monat die Zebratabellen-CSS-Definition table.wikitable.sortable tr:nth-child(even) { background:#fcfcfc } für alle sortierbaren wikitables aktiv. Bisher konnte ich keine Probleme feststellen. Diese Variante sollte – wie erklärt – nur optional und gegebenenfalls als Gadget angeboten werden.
Bei einer eigenen CSS-Klasse zebra bin ich immer noch etwas skeptisch, weil es nur eine kleine optische Veränderung ist, die nicht wirklich notwendig ist. Es wird Diskussionen und Regeln geben, welche Tabelle als Zebra markiert werden darf und welche nicht. Außerdem gibt es weiterhin das zentrale Problem, dass diese Farbe für alle gelten muss und nicht überschrieben werden kann. Eine scoped-Style-Definition von HTML5 direkt im Wikitext wäre mir lieber. Damit könnten auch für große Tabellen spaltenweise Vorgaben gemacht werden.
Wenn zebra in MediaWiki:Common.css aufgenommen werden soll, dann muss zuvor noch eine Diskussion über die Farbe geführt werden. --Fomafix 13:17, 30. Mär. 2010 (CEST)

Nach zwei Monaten: Gibt es was Neues? blunt.™ 18:01, 29. Apr. 2010 (CEST)

Gibt es Artikel, bei denen Zebratabellen absolut notwendig sind? Mit den Extensions mw:Extension:CSS, mw:Extension:AddScriptCss oder mw:Extension:PageCSS könnten CSS-Definitionen mit Selektoren artikelindividuell verwendet werden. --Fomafix 19:46, 29. Apr. 2010 (CEST)

„absolut notwendig“ ist oft Geschmackssache. Meiner Meinung nach wären die Listen der Fluchttunnel in Berlin während der deutschen Teilung und die der Todesopfer an der Berliner Mauer als Zebra wesentlich übersichtlicher sind (ich habs in meiner monobook.css (farblich moderat) aktiviert). Seit ich das für mich aktiviert hab, finde ich viele Listen besser lesbar und einfacher nachzuvollziehen. Jedes mal, wenn ich mich mit ner Socke anmelde, ärgere ich mich allerdings, dass die Listen eintönig sind. Mir ist durchaus klar, dass es lange dauern wird bis es die Zebras in einer größeren Population gibt. Man sollte halt mal mit der Zucht beginnen, aber lieber als Universallösung, denn als Einzelexperiment. Gruß blunt.™ 20:45, 29. Apr. 2010 (CEST)

Zur Farbe: spricht was gegen table.wikitable.zebra tr:nth-child(even) { background:white }, statt mit irgendwas bei #fcfcfc? Das hebt sich sonst nicht deutlich genug ab, zumindest auf meinem Zweitbildschirm. Bei Rest schließe ich mich blunt. an. --Euku:^⇄ 22:53, 30. Apr. 2010 (CEST)

Ok, schlagt mich. --Euku:^⇄ 23:08, 4. Mai 2010 (CEST)

class="hintergrundfarbe5" funktioniert bei geraden Zeilen nicht mehr: --Fomafix 19:49, 12. Mai 2010 (CEST)

Name	Geboren	Gestorben	Alter	Todesumstände
Ida Siekmann	23. August 1902	22. Aug. 1961	58	…
Günter Litfin	19. Januar 1937	24. Aug. 1961	24	…
Summe	Summe	Summe	Summe	Summe

Es müsste die CSS-Selektor-Spezifität für tr.hintergrundfarben erhöht werden. --Fomafix 19:49, 12. Mai 2010 (CEST)