Diese Seite ist zur Diskussion von Verbesserungsvorschlägen technischer Art an der deutschsprachigen Wikipedia gedacht;
sie ersetzt nicht die Diskussionsseiten der Artikel- oder anderer Wikipedia-Seiten.

---

Es gibt immer was zu tun …

Artikel-Inhalte werden direkt beim/im Artikel verbessert, Änderungen an Seiten der anderen Namensräume auf den entsprechenden Diskussionsseiten verhandelt, siehe Wikipedia:Diskussionsseiten. Vermutete Softwarefehler (Bugs) bitte gemäß Hilfe:Fehler und Probleme melden; am einfachsten in der Werkstatt. Softwareverbesserungen bitte auf der Unterseite Wikipedia:Verbesserungsvorschläge/Feature-Requests vorschlagen bzw. bewertend kommentieren, damit man sehen kann, welche Vorschläge an die Entwickler weitergeleitet werden sollten. Projektanregungen nichttechnischer Art, auch Anregungen auf Basis von Erfahrungen aus anderen Wikimedia-Projekten, können auf Wikipedia:Projektdiskussion besprochen werden. Allgemeine Fragen zur Wikipedia und zur Artikelbearbeitung werden bei Wikipedia:Fragen zur Wikipedia diskutiert. Administratives: Falls es sich um eine Angelegenheit handelt, die durch einen Administrator erledigt werden kann, stelle eine Anfrage bei Wikipedia:Administratoren/Anfragen.

… und bitte mit --~~~~ unterschreiben.

Wenn ein Abschnitt abgearbeitet ist, kann er mit {{Erledigt|1=--~~~~}} markiert werden, wodurch er nach fünf Tagen ins Archiv (aktuelles Archiv) verschoben wird. Anfragen, deren letzter signierter Beitrag mindestens 100 Tage zurückliegt, werden ebenfalls archiviert.
Sollen bereits archivierte Beiträge wieder diskutiert werden, erstellt hier bitte einen neuen Abschnitt mit Verweis auf den archivierten.

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten.

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 3 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

• Besucherzähler/Statistikanzeige pro Artikel: Gibt es prinzipiell, ist aber schon lange wegen zu hoher Serverbelastung ausgeschaltet. Über dieses externe Tool kann zu jedem Artikel die Seitenzugriffszahl ermittelt werden.
• Rechtschreibprüfung: Ist für angemeldete Benutzer in den Einstellungen, Karteireiter Helferlein (Abschnitt Bearbeitungswerkzeuge) verfügbar.
• Alte oder neue Rechtschreibung: siehe Wikipedia Diskussion:Rechtschreibung
• Farbenblindheit: Linkfarben lassen sich benutzerspezifisch auf für Farbenblinde besser erkennbare Farben umstellen, siehe Hilfe:Eigene Stylesheets und Benutzer:Wolfgangbeyer/monobook.css. Weiterhin kann durch Aktivierung des Gadgets Rot-Grün-Sehschwäche-Helferlein die Wikipediaoberfläche für Rot-Grün-Fehlsichtige in für sie erkennbare Farben abgewandelt werden. Zudem kann man die Linkfarben auch in den Einstellungen des Browsers festlegen.
• Artikel bewerten: Ein Bewertungssystem ist noch in Entwicklung/Testphase begriffen (Diskussion bitte auf Mailinglisten)
• Redirects auf Artikelabschnitte sind technisch möglich. Vorzuziehen ist jedoch eine Verlinkung auf Artikelabschnitte durch die Vorlage:Anker. Dadurch bleibt der Link auch bei Änderung der Abschnittsüberschrift aktuell.
• Javascript einbinden: ist ein Sicherheitsproblem und wird es deshalb nicht geben.
• Externe Links prinzipiell in einem separaten Fenster öffnen: wird es nicht geben, empfinden auch viele Nutzer als bevormundend. (Wo ein Link geöffnet wird, kann man in den meisten Browsern selbst entscheiden durch die Art, wie man draufklickt.)
• Mindestgröße für neue Artikel: umstritten, siehe WP:WSIGA
• Allgemeinen Zugriff auf gelöschte Artikel: gibt es derzeit nicht
• Beim Bearbeiten anzeigen, zu welchen Begriffen Artikel existieren: sehr aufwendig zu realisieren. Lösung: Vorschau oder das externe Tool Wikifizierer von Bananeweizen nutzen.
• Artikelvorschau beim Überfahren von Links: Ist für angemeldete Benutzer in den Einstellungen, Karteireiter Helferlein (Abschnitt Lesehilfen) verfügbar.
• Metadaten, welche die Richtigkeit belegen: Interessant, aber aufwendig
• Essays: Eventuell, und wenn, dann nur was für Wikibooks
• RSS-Feed: ist verbesserungswürdig, hat aber eine geringe Priorität
• Versionsgeschichte erweitern um Grund für Löschung/Sperrung/Wiederherstellung und welcher Admin ausführte : Interessant, zum Teil umgesetzt über "Ansicht gelöschter Versionen"
• Expertenabschnitte: Kontrovers diskutiert, kein Ergebnis

Feature-Requests sind auf der Unterseite Wikipedia:Verbesserungsvorschläge/Feature-Requests zu finden.

Wenn ein hier diskutierter Feature request auf Bugzilla gestellt wurde, bitte hier auflisten:

• Bug 164: Sprachspezifische Sortierreihenfolge (also Ä unter A und nicht ÄÖÜ nach Z z. B. auf Spezial:Allpages)
• Bug 189: Musikmodul für Mediawiki
• Bug 674: Artikel für einzelne Benutzer sperren
• Bug 708: Links zu den Schwesterprojekten (Wiktionary, Wikibooks etc.) ins Interface integrieren
• und viele weitere - mit einem Account könnt ihr für einzelne Bugs voten

<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.

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 verbessertBeantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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 WP: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)Beantworten

(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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

„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)Beantworten

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

class="hintergrundfarbe5" funktioniert bei geraden Zeilen nicht mehr:

Ä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)Beantworten

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)Beantworten

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)Beantworten

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

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)Beantworten

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)Beantworten

@-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)Beantworten

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)Beantworten

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)Beantworten

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

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

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)Beantworten

„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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Das geht mithilfe der "Entfernen"-Links in der Versionsgeschichte . 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)Beantworten

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

*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)Beantworten

Ä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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Unter dem Editfenster wird in der Werkzeugleiste "Gedankenstrich" angezeigt, wenn man auf ebendiesen mit der Maus fährt. Dort sollte allerdings besser "Bisstrich/Gedankenstrich" stehen, da es ja beides sein kann. Die einseitige Anzeige kann bei Benutzern zu Verwirrung und Ratlosigkeit führen, wie ich kürzlich in einer Diskussion feststellen musste. Στε Ψ 19:49, 2. Apr. 2010 (CEST)Beantworten

Das ist kein Problem, es braucht hierfür bloß einen Admin. -- ✓ ^Bergi 12:52, 3. Apr. 2010 (CEST)Beantworten

Hi ihr zwei, ist erledigt. Gruß --W_I^KImaniac 12:56, 3. Apr. 2010 (CEST)Beantworten

Weitere Verwendung findet der Strich als Streckenstrich und als Gegenstrich. Vielleicht wäre es besser den Strich beim Namen zum nennen (Halbgeviertstrich) und seine Verwendungen als Satzfunktion in Klammern aufzuzählen: „Halbgeviertstrich (Gedankenstrich, Gegenstrich, Bis-Strich, Streckenstrich)“ --Fomafix 13:08, 3. Apr. 2010 (CEST)Beantworten

Kann man auch mit Doppeltipp auf - zu einem – machen, wenn man Jowereits Typohilfe in seine .js einbindet. -- Hæggis 00:44, 16. Apr. 2010 (CEST)Beantworten

Zunächst ist es nur eine Sammlung von unenzyklopädischen Formeln, Phrasen und Wörtern. Später kann man damit einmal gezielt nach unenzyklopädischen Passagen suchen. Über Mitarbeit beim sammeln würde ich mich freuen: Benutzer:Chautauqua Tourbillon/Floskeln, die auf Verlegenheit des Schreibers schließen lassen ... Gruß --Chautauqua Tourbillon 13:43, 5. Apr. 2010 (CEST)Beantworten

Jetzt wird's lustig: die Wikipedia erhält ihre eigene Giftmülldeponie. Da bin ich aber mal gespannt...  ;-D

Nur so interessehalber: wenn ich auf einen Kandidaten für deine Deponie stoße, ändere ich ihn. Ich werde also, wenn überhaupt, nur Links auf frühere Versionen liefern können. Reicht dir das auch? Gruß, --Snevern ^{(Mentorenprogramm)} 14:12, 5. Apr. 2010 (CEST)Beantworten

Du änderst das wort sozusagen und prüfst so, wie verbreitet die Unart ist: sozusgen Gruß --Chautauqua Tourbillon 14:30, 5. Apr. 2010 (CEST)Beantworten

Jetzt hier zu finden, ist & bleibt vorerst ne BNR-Sammlung. Anregungen immer willkommen. -- Hæggis 00:40, 16. Apr. 2010 (CEST)Beantworten

Könntet Ihr bitte beim Formular "Hochladen" das Eingabefeld "Beschreibung/Quelle" etwas kürzer machen, damit das Eingabefeld "Lizenz" am unteren Bildrand höher rückt und sichtbar wird? Mir ist wiederholt passiert, dass ich die Angabe zur Lizenz schlichtweg "übersehen" habe, weil nicht sichtbar (und hatte dann hinterher ne Menge Stress). Ich denke, das ist kein Problem, weil ja das Eingabefeld "Beschreibung/Quelle" bezüglich der "Bemerkungen" sehr großzügig bemessen ist. Danke und Gruß --Ulrich Waack 18:47, 5. Apr. 2010 (CEST)Beantworten

Das Feld "Beschreibung" war vorher mal kleiner, dann sah man aber nicht alle Zeilen des bereits gesetzten Inhalts, daher wurde es größer gemacht (MediaWiki Diskussion:Common.css/Archiv2#Sichtbare Zeilenzahl beim Upload). Da sich die Schaltfläche zum Hochladen ja auch am unteren Ende der Seite befindet, sollte man die Lizenz eigentlich nicht übersehen (meine Meinung, aber ich habe auch noch nie Bilder hochgeladen). Der Umherirrende 08:47, 6. Apr. 2010 (CEST)Beantworten

Sehe ich auch so. Alternativ könnte man die Reihenfolge ändern, also „Lizenz“ vorziehen. Ich würde aber alles so belassen. --Leyo 09:24, 6. Apr. 2010 (CEST)Beantworten

Ja, höchstens die Reihenfolge ändern. Ansonsten ist das sowieso alles nur eine Frage der Bildschirmgröße (OK, ich sehs auch nur im Vollbildmodus) :)
meint -- ✓ ^Bergi 13:29, 6. Apr. 2010 (CEST)Beantworten

Ja, Lizenz eine Position vorziehen, ist eine gute Lösung. Wenn das Ende des großen Eingabefeldes dadurch unter den unteren Bildschirmrand reicht, so ist das kein Problem. Danke. Und wenn setzt es nun um? --Ulrich Waack 08:17, 26. Apr. 2010 (CEST)Beantworten

Spezial:Einstellungen → Letzte Änderungen → Anzahl der standardmäßig angezeigten Bearbeitungen. Dies umfasst die Liste der letzten Änderungen, die Versionsgeschichte und die Logbücher.
Ist es (leicht) möglich, zu differenzieren? Für meine Benutzeroberfläche z.B. hätte ich gern die Einstellungen:

40 – Letzte Änderungen
20 – Eigene Beiträge
7 – Versionsgeschichte
200 – Logbücher

Wenns arg umständlich wär, ist der Extraklick auf (20 | 50 | 100 | 250 | 500) weiterhin in Ordnung. -- Hæggis 23:46, 5. Apr. 2010 (CEST)Beantworten

Per Javascript könnte man die Links auf die 4 Seiten alle umbauen lassen. Und in der Auswahlzeile je nach Seite eine Link hinzuzufügen ist auch nicht schwer. Aber die Einstellungsseite würde ich nicht verändern.
meint -- ✓ ^Bergi 13:36, 6. Apr. 2010 (CEST)Beantworten

Ich hatte eine derartige Änderung (selbstverständlich ohne Java/scripte) bereits einmal programmiert und Anteile davon in den damals aktuellen Source Code eingebracht. Sie wurden bei der Neuorganisation der Datenbanktabellen für die Benutzereinstellungen wieder fallengelassen. Wenn ein hinreichender Bedarf besteht, finde bitte eine entsprechende Anforderung in bugzilla oder stelle sie dort ein, falls noch nicht vorhanden. Dann schreib mir eine Nachricht mit einem Link auf den Bug, oder seine Nummer, auf meine Benutzerdiskussionsseite, ich kümmere mich dann um die Anpassung. Gruß -- Purodha Blissenbach 16:04, 8. Apr. 2010 (CEST)Beantworten

Service 1. Klasse, danke. Brauche noch ein bisschen Zeit, bis ich alle möglichen Suchbegriffe bei Bugzilla eingegeben hab… -- Hæggis 00:39, 16. Apr. 2010 (CEST)Beantworten

Das gegenwärtige Logo liegt als 135px × 155px vor, wird aber vom Firefox (andere Browser benehmen sich) hochgepumpt. Gibt's da einen FF-Hack für? Auf WP:EN geht's (hab's mir nicht genau angesehen, aber die CSS-Klassen sollten doch die selben sein). Gruß, -- E (D) 03:07, 13. Apr. 2010 (CEST)Beantworten

Monobook und Modern haben im Skin (keine lokale Anpassung) einen Rahmen um noarticletext stehen (erscheint bei der View-Ansicht von nicht existierenden Seiten). Jetzt ist mir aufgefallen, dass dies bei vector nicht der Fall ist. So kann man solche Seiten kaum von angelegten Seiten unterscheiden, weshalb ich denke, dass dort ebenfalls der Rahmen definiert werden sollte. Da ich selber das Skin aber eigentlich nicht nutze, wollte ich mal erst kurz Zustimmung von den Nutzern einholen. Zudem könnte man klären, ob man es global ändern sollte. Merlissimo 00:11, 14. Apr. 2010 (CEST)

Beim Durchwandern einiger Kategorien ist mir immer wieder aufgefallen, dass ein gesuchtes Lemma (dessen genauen Wortlaut ich nicht kannte, das Suchfeld also nicht weiterhalf) des öfteren in einer kaum gefüllten Unterkategorie lag. Inwzischen habe ich für den Firefox die Rücktaste entdeckt; die Suche geht hierdurch zwar schneller,
doch die Suche würde noch schneller gehen, wenn es eine Funktion ähnlich der mit dem [+]-Symbol verknüpften Fkt gäbe, die alle in den angezeigten Unterkategorien enthaltenen Seiten anzeigt, incl. Unter-Unterkats (nicht deren Seiten). Evtl. kann die Fkt. auch individualisiert werden, also auch für einzelne Unterkategorien abrufbar sein, doch die Alle Seiten von Unterkategorien anzeigen-Fkt. wäre m.E. schon eine echte Verbesserung. Bsp.-Kats. sind Chinesische Musik und Brauerei (Nordrhein-Westfalen), mit etwas Geduld finden sich etliche mehr.
Standard wäre die bisherige Oberfläche, ist nur als wählbarer Zusatz gedacht. -- Hæggis 00:30, 16. Apr. 2010 (CEST)Beantworten

Mit der Kategorienbaum-Erweiterung geht das:

Ob bzw. wie sich das benutzerkonfigurierbar in Kategorieseiten aktivieren lässt, weiß ich nicht. --Schnark 09:30, 16. Apr. 2010 (CEST)Beantworten

Danke für den Tip, Schnark! Ich wußte, daß das für Unterkategorien funktioniert, aber daß es auch mit Seiten funktioniert, war mir neu. Gut zu wissen.

Was nun nur noch fehlt, wäre die Möglichkeit, alle Seiten, auch die von ausgeklappten Unterkategorien, in einer alphabetisch sorierten Liste darzustellen, also oben alle Kategorien und unten alle Seiten. Es wäre zu überlegen, wie man dann kenntlich machen kann, zu welcher Unterkategorie eine Seite gehört. --TETRIS L 09:53, 16. Apr. 2010 (CEST)Beantworten

Wäre das möglich, da noch einen 2em-left-margin dazuzubauen? Danke, -- E (D) 21:29, 17. Apr. 2010 (CEST)Beantworten

Standardmäßig wäre das sicherlich unangebracht, da es dann für alle gilt, auch, die es nicht wollen/brauchen/mögen usw. Du kannst aber einen style verwenden: <poem style="margin-left:2em;"> ergibt:

— Raymond ^Disk. 09:59, 26. Apr. 2010 (CEST)Beantworten

Jupp, aber Poem-CSS mit Default-2em fände ich einfach besser, auch wenn das vermutlich mit einem Bot vorher durchgecheckt werden müsste, falls schon styles benutzt wurden. Aber meinetwegen ad acta. Gruß, -- E (D) 02:27, 30. Apr. 2010 (CEST)Beantworten

→ WP:Fragen zur Wikipedia#Begründung für Revert. -- E (D) 02:23, 30. Apr. 2010 (CEST)Beantworten

Könnte man nicht für die "Beoachtungsliste" Totalreverts von Vandalismen auffällig kennzeichnen, um sich viel lästiges Nachschlagen zu erparen? --Ulrich Waack 01:22, 30. Apr. 2010 (CEST)Beantworten

Könnte man, aber auch und gerade Vandalenjäger machen durchaus auch Fehler. --95.88.94.7 14:45, 11. Mai 2010 (CEST)Beantworten

Es wäre schön wenn auf der Benutzerseite angezeigt werden würde wann der Benutzer zuletzt editiert hat und/oder zuletzt eingeloggt war, das würde die Kommunikation erleichtern. Stelle mir da eine Art Ampel vor, etwa: grün=die letzte Woche aktiv, gelb=im letzten Monat aktiv, orange=im letzten Jahr aktiv, rot=inaktiv seit mehr als einem Jahr --Antemister 21:11, 4. Mai 2010 (CEST)Beantworten

Schau dir doch seine Benutzerbeiträge an - dann weißt du das nötige. Wann jemand eingeloggt war, nun das muss nicht geloggt werden. Und die Lämpchen: abgesehen davon, dass blinkendes Unzeug vermieden werden sollte - es würde so ziemlich viel Ressourcen zusätzlich fressen, denke ich. -jkb- 22:34, 4. Mai 2010 (CEST)Beantworten

<Eigenwerbung>Versuch es mal mit

importScript('Benutzer:Schnark/letzteredit.js'); //importiert [[Benutzer:Schnark/letzteredit.js]]
                                                 //um anzuzeigen, wann ein Benutzer zuletzt aktiv war

in deiner monobook.js (bzw. vector.js, wenn du das neue Skin verwendest). Ist zwar nicht bunt, aber nützlich finde ich es trotzdem.</Eigenwerbung> --Schnark 09:15, 5. Mai 2010 (CEST)Beantworten

@schnark: Wie funktioniert dieses Script (oder was auch immer das ist). Was muss ich da tun?--Antemister 19:14, 7. Mai 2010 (CEST)Beantworten

Du musst einfach nur die beiden Zeilen ("importScript … aktiv war") kopieren und in deiner monobook.js einfügen. Dann sollte auf jeder Benutzerseite hinter dem Namen erscheinen, wann der Benutzer zum letzten Mal aktiv war. (Bei dir zum Beispiel sehe ich gerade ein "(zuletzt aktiv gestern um 19:30)", bei mir "(zuletzt aktiv vor 5 Minuten)") Ich habe gerade noch mal etwas am Skript geändert, dass es jetzt auch in älteren Internet Explorern funktionieren sollte. --Schnark 09:30, 8. Mai 2010 (CEST)Beantworten

Ah, so gehts. Danke, so etwas wollte ich haben--Antemister 10:05, 8. Mai 2010 (CEST)Beantworten

Wie wäre es mit der Erweiterung WikiTeX für Wikipedia? WikiTeX ist eine LaTeX-Erweiterung, mit der man Musiknoten, Strukturformeln und Gnuplot-Diagramme mit Wikicode einbinden kann. Hier sind einige beeindruckende Beispiele dafür, was WikiTeX kann. Man müsste dann nicht mehr so viele SVG-Bilder für chemische Formeln und Diagramme hochladen, außerdem wäre das Aussehen der Formeln einheitlich. --Gaussianer (Diskussion | Beiträge) 12:08, 9. Mai 2010 (CEST)Beantworten

Hallo Gaussianer, ich unterstütze deinen Vorschlag. Die Möglichkeiten, die WikiTeX bieten würde, sind beeindruckend und würden meiner Meinung nach die Qualität der Wikipedia steigern. -- René Schwarz 12:39, 9. Mai 2010 (CEST)Beantworten

Das sehe ich auch so! --Christian1985 13:13, 9. Mai 2010 (CEST)Beantworten

 Pro --Ce 13:59, 9. Mai 2010 (CEST)Beantworten

Es wäre schön, wenn die Captchas Worte der jeweiligen Sprachversion abfragen würden und sich nicht auf englisch beschränken. Dem Algorithmus sollte eigentlich mit den Artikeln der WP selbst ein hinreichend großer Vorrat zur Verfügung stehen. --82.113.106.36 14:15, 10. Mai 2010 (CEST)Beantworten

He, das ist fies, wollte ich heute Vormittag (als IP) auch vorschlagen. Aber ich glaube nicht dass wahllos Lemmata verwendet werden sollten, abgesehen von Kuriosa wie Uschebti dürften auch sämtliche Artikelnamen mit äöüâêêî$@… zu filtern sein.
meint -- ✓ ^Bergi 14:55, 10. Mai 2010 (CEST)Beantworten

Guter Einwand. Gerade für die kleineren Sprachversionen würde ich eh nicht nur auf die Lemmata zurückgreifen, sondern auf die Artikeltexte. Ein Captcha aus 3 oder 4 aufeinanderfolgenden Worten sollte normalerweise für einen Menschen gut lesbar und lang genug sein. --82.113.106.36 15:26, 10. Mai 2010 (CEST)Beantworten

Den Vorschlag finde ich unterstützenswert. Im Vergleich zu anderen Websites sind die Wikimedia-Captchas relativ gut zu lesen, aber manches Mal wäre ich ohne meine Fremdprachkenntnisse am Captcha gescheitert; da hab ich glücklicherweise die Wörter erkannt, hätte aber sonst was anderes gelesen. --95.88.94.7 14:59, 11. Mai 2010 (CEST)Beantworten

Als IP bekommt man, wenn man einen Edit vornehmen will, über dem Bearbeitungsfenster folgende Meldung angezeigt:

Du bearbeitest diese Seite unangemeldet. Wenn du deine Änderung speicherst, wird deine aktuelle IP-Adresse in der Versionsgeschichte aufgezeichnet und ist damit öffentlich einsehbar. Wenn du ein Benutzerkonto anlegst, bleibt deine IP-Adresse verborgen.

Ich bin mir zwar darüber im Klaren, dass das Opt-In die Problematik dieser Diskussion entschärft, halte es aber nach wie vor für sinnvoll, darauf beim Editieren hinzuweisen:

Speicherst du eine Änderung unangemeldet, wird deine aktuelle IP-Adresse in der Versionsgeschichte aufgezeichnet und ist damit öffentlich einsehbar. Wenn du ein Benutzerkonto anlegst, bleibt deine IP-Adresse verborgen.

Speicherst du eine Änderung angemeldet, sind alle deine Änderungen für alle Zeiten von jedem einsehbar und können unter Umständen ein Persönlichkeitsprofil darstellen. Wenn du dich ausloggst, ist dies nicht möglich.

--82.113.106.36 15:03, 10. Mai 2010 (CEST)Beantworten

Ausgenommen von WP Regeln, die mit der deutschen Sprache oder deutschen Gesetzen zusammen hängen, sehe ich keinen Grund, dass die deutsche WP andere Regeln haben muss als in der englischen Wikipedia.

Mein Vorschlag wäre, alle Regeln der deutschen WP zu verwerfen (bis auf oben genannte) und die der englischen WP zu übernehmen und auch in Zukunft keine Differenzierung bei Regeln zwischen der deutschen und englischen WP vorzunehmen.

Insbesondere finde ich das wichtig für Regeln, die folgendes definieren / betreffen:

• Ziel von Wikipedia
• Neutraler Standpunkt
• Artikel über lebene Personen
• Wikiquette
• Relevanzkriterien
• Aufbau / Stil / Illustrationen
• Belege / Literatur / Links

Ich finde, es macht keinen Sinn, hier andere Regeln für die deutsche WP zu haben als in der englischen WP. Man kann das auch nicht wirklich mit der andersartigen deutschen Kultur erklären, da die deutsche Kultur sich größtenteils in der Kultur der englischsprachigen Länder wiederfindet.

--Albertzeyer 07:24, 11. Mai 2010 (CEST)Beantworten

Klar, wieso nicht? Jetzt haben wir einen Konsens von 2 Leuten, wir sollten gleich anfangen, die Seiten zu ändern ;-)

Ernsthaft: Das hat m.E. weniger mit einem doch recht abstrakten Kulturbegriff zu tun als also dem Prozess der Willensbildung: Die von dir genannten Richtlinien haben sich schlichtweg so entwickelt. Die deWP ist ein annährend rein selbstverwaltetes bzw. Mitarbeiter-kontrolliertes *irgendwas*, wenn die Seiten heute so aussehen, wie sie aussehen, ist es das ein Ergebnis von jahrelangem Wirken und teils zermürbenden Debatten und Abstimmungen. Das ist imho nicht umkehrbar und auch nicht per Konsens in relativ kleinem Kreis – ja selbst wenn es 400 deWikipedianer wären – an die enWP angleichbar, die wiederum durch die Tätigkeiten ihrer eigenen Mitarbeiter so gewachsen und sicherlich nicht ,perfekt‘ ist. -- Hæggis 11:12, 11. Mai 2010 (CEST)Beantworten

Und übrigens könnte man sich fragen, warum das nicht umgekehrt gemacht werden sollte: die englische Wikipedia beseitigt ihre Richtlinien und übernimmt die deutschen von hier (wäre in einigen Fällen auch besser so, denke ich). Gruß -jkb- 11:22, 11. Mai 2010 (CEST)Beantworten

+ P.S.: Deutschsprachige Wikipedia. Nie vergessen. -- Hæggis 13:09, 11. Mai 2010 (CEST)Beantworten

Ein Großteil der Regel wurde in einer vergleichsbar kleinen Runde diskutiert und beschlossen. Das hat wenig mit der Willensbildung der Gesamtheit der WP Benutzer zu tun. Auch ist der Ausgang bei sowas im höchsten Maße chaotisch, je kleiner die Gruppe ist. Die Regeln der englischen WP sind erprobter, da sie im größeren Umfang beschlossen und getestet wurden. Auch sind sie allgemeiner (insbesondere auch von Deutschen) akzeptierter als die Regeln der deutschen WP.

Dass sich die Regeln der deutschen WP zu denen der engl. WP so deutlich unterscheiden ist eher ein Zeichen dafür, dass das allgemeine Regelerstellungsmodell viel zu chaotisch und undeterministisch ist. Es ist absolut falsch anzunehmen, dass tendenziell deutschsprachige Benutzer wirklich eine andere WP haben wollen als englischsprachige Nutzer.

--Albertzeyer 17:18, 11. Mai 2010 (CEST)Beantworten

• Ein Großteil der Regel wurde in einer vergleichsbar kleinen Runde diskutiert und beschlossen. Halt denjenigen, die sich dafür interessieren. Übrigens sind sie nicht in Stein gemeißelt, sondern unterliegen kontinuierlichen Verändungen.
• Das hat wenig mit der Willensbildung der Gesamtheit der WP Benutzer zu tun. Wie stellst du dir das vor? Möchtest du tatsächlich die Gesamtheit der WP-Benutzer zu jeder noch so speziellen Detailfrage hören? Und wie soll das gehen? Wen interessiert alles?
• Auch ist der Ausgang bei sowas im höchsten Maße chaotisch, je kleiner die Gruppe ist. Sagt wer? Wieso chaotisch? Und wenn es vielen nicht gefällt, dann wird es halt später geändert. Regeln, speziell schlechte, sind doch nicht in Stein gemeißelt.
• Die Regeln der englischen WP sind erprobter, da sie im größeren Umfang beschlossen und getestet wurden. Das stimmt. Je größer die Community, desto mehr Regeln gibt es auch und desto spezieller sind sie. Allerdings wären bspw. die en:Wikipedia:Criteria_for_speedy_deletion z.B. in der plattdeutschen oder der sorbischen WP leicht überdimensioniert. Also die Größe der Communitys spielt eine Rolle, aber auch deren unterschiedliche Kultur/Mentalität. Z.B. hat die EN-WP eine entspanntere Einstellung zu unbequellten Artikeln mieser Qualität, um das mal so zu formulieren. Deswegen kann man nicht allen WPs die selben Regeln aufzwingen. Anderes Beispiel: Dem Irak oder Afghanistan US-amerikanische Demokratie zu verordnen ist nicht so einfach, wie sich die Amis das gedacht haben. Man muss auch Kultur und Mentalität beachten. Z.B. verbringen Amis viel mehr Zeit vor dem Fernseher als der durchschnittliche Europäer, entsprechend ist in der EN-WP die Populärkultur wesentlich stärker vertreten als hier.
• Auch sind sie allgemeiner (insbesondere auch von Deutschen) akzeptierter als die Regeln der deutschen WP. Sagt wer? Ich habe den Eindruck, du willst einzig und allein für lockerere Relevanzkriterien werben, ist das korrekt?
• Dass sich die Regeln der deutschen WP zu denen der engl. WP so deutlich unterscheiden ist eher ein Zeichen dafür, dass das allgemeine Regelerstellungsmodell viel zu chaotisch und undeterministisch ist. Jede Community macht sich ihre Regeln selbst, denn sie ist es ja, die dann damit arbeiten muss. Was sieht denn dein Regelerstellungsmodell vor? Jimmy Wales macht alle Regeln alleine und verbindlich für alle WPs?
• Es ist absolut falsch anzunehmen, dass tendenziell deutschsprachige Benutzer wirklich eine andere WP haben wollen als englischsprachige Nutzer. Hä? Sagt wer? Und was ist denn sooo anders? Und so schlimm daran? --95.88.94.7 18:00, 11. Mai 2010 (CEST)Beantworten

Bei verschiedenen Ereignissen würde ich mir eine automatische Benachrichtigung via Mail wünschen:

• Eine Antwort zu einem meiner Beiträge auf einer Diskussionsseite (oder einer Seite wie dieser hier).
• Wie oben aber auch anderen, explizit von mir auserwählte Beiträge.
• Änderungen jeglicher Art auf einer Seite / in einer Sektion einer Seite.

Die Benachrichtigung könnte dann auch automatisch aktiviert sein auf der Diskussionsseite von meinem eigenen Account.

--Albertzeyer 07:00, 11. Mai 2010 (CEST)Beantworten

Technisch möglich und wird in den kleinen Projekten verwendet. Für die großen Projekte ist es deaktiviert, da es zu viel Serverkapazität verbraucht. XenonX3 - (☎:±) 10:48, 11. Mai 2010 (CEST)Beantworten

Es gibt die Beobachtungsliste als RSS- oder Atom-Feed, mit speziellen Programmen oder auch einfach deinem Feedreader (Browser etc) kannst du das Filtern. Nach Seite (Abschnitt) oder Bearbeiter durchsucht sollte das was du willst herauskommen. Ich glaube es gibt auch Programme die das dann als PDF exportieren und als Mail verschicken.
meint -- ✓ ^Bergi 11:39, 11. Mai 2010 (CEST)Beantworten

Mit BlogAlert kann man aus dem Feed eine Mail erzeugen. --Flominator 13:03, 11. Mai 2010 (CEST)Beantworten

Ja, und auch Filter gibts auch online. Vielleicht liegt dir sogar dieser c't-Artikel vor, war ganz interessant. -- ✓ ^Bergi 16:04, 11. Mai 2010 (CEST)Beantworten

Man könnte einen extra Server dafür benutzen, falls dieser Zusatz wirklich sonst nicht handhabbar ist (scheint mir dann aber eher ineffizienter Code zu sein).

Mein Vorschlag bezieht sich vor allem darauf, so eine Funktion von Seite des WP Projekts anzubieten um nicht notwendigerweise auf eine externe Lösung zurückgreifen zu müssen.

--Albertzeyer 17:02, 11. Mai 2010 (CEST)Beantworten

Ein Forum basierend auf Software wie SMF (oder Ähnliche, evtl. auch modernere) wäre deutlich angenehmer als die aktuellen Diskussionsseiten (und auch Seiten wie diese hier). Natürlich basierend auf den gleichen Benutzeraccounts.

Technisch wäre es nicht sonderlich aufwendig, das zu realisieren. Warum wurde das bisher noch nicht gemacht? --Albertzeyer 06:55, 11. Mai 2010 (CEST)Beantworten

Kommt bald, siehe Wikipedia:WikiProjekt LiquidThreads. XenonX3 - (☎:±) 10:49, 11. Mai 2010 (CEST)Beantworten