Wikipedia:Verbesserungsvorschläge

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.

Neuen Beitrag erstellen

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

Automatische Archivierung

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

Automatische Archivierung

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

Vorlage:Autoarchiv-Erledigt/Wartung/Parameter Zeigen auf Nein gesetzt

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Oft Gefragtes (FAQ)

• 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 und Bugreports auf Bugzilla

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

Verbesserungsvorschläge

Langer Pre-Text

Ich glaube es wäre ganz praktisch wenn man der Common.css folgendes hinzufügen würde.

pre {
    overflow: auto;
}

dann würde bei langem Text innerhalb des pre, der Text nicht aus der Seite und der Box herausfließen und der gesamten Seite einen horizontalen Scrollbalken verleihen. So wie in meinem Beispiel unten.

das hier ist ein ganz langer Text und der wird gleich in der Darstellung aus der Seite herausfallen und das sieht nicht wirklich gut aus und bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla 

Mit dem oben angebenen CSS-Einstellungen erscheint der Scrollbalken innerhalb der Box. Könnt ihr auch ausprobieren indem ihr das oben in eure monobook.css oder so einfügt.

--Finsterhell 17:53, 26. Dez. 2009 (CET)

 Pro. Ich möchte den Vorschlag dringlichst unterstützen (Alarmstufe ROT), da ich dieses unvermeidliche horizontale Scrollen auch als äußerst ärgerlich empfinde. Anscheinend hat hier jemand bei der Gestaltung das pre-Element in HTML überhaupt nicht verstanden. Das sollte umgehend nachgebessert werden. -- pretobras 22:19, 2. Jan. 2010 (CET)

 Pro. Ausgezeichnete idee. --helohe (talk) 21:11, 13. Jan. 2010 (CET)

 Pro. --79.218.27.120 00:39, 12. Feb. 2010 (CET)

 Pro. ...längst überfällig! --ulli purwin _fragen? 20:21, 19. Feb. 2010 (CET)

Gute Idee, ich habe es umgesetzt, hoffen wir, dass es keine Nebeneffekte gibt. Könnte jemand die IEs durchtesten? Chrome, Opera10, Safari4, FF3.5.7 funktioniert. --Euku:^⇄ 10:29, 18. Feb. 2010 (CET)

Beim Internet Explorer 6 gibt es jetzt bei Hilfe:Tabellen das Problem, dass neben dem horizontalen auch noch ein hässlicher vertikaler Scrollbalken entsteht. --Fomafix 10:38, 18. Feb. 2010 (CET)

Bei Seiten, die ein pre-Element mit viel Inhalt enthalten, wie MediaWiki:Common.css, ist overflow:auto störend. --Fomafix 10:50, 18. Feb. 2010 (CET)

Sollte man hier eine Ausname für diesen NR machen? Wo anders kommt soviel Text kaum vor. --Euku:^⇄ 20:16, 19. Feb. 2010 (CET)

gerne. --Atlan ^Disk. 23:11, 27. Feb. 2010 (CET)

bitte. (oder geht das kürzer?) --Euku:^⇄ 16:07, 1. Mär. 2010 (CET)

Kürzer wäre

pre { overflow:auto } .ns-5 pre { overflow:visible }

Auch das Problem beim Internet Explorer 6 lässt sich wahrscheinlich lösen. Allerdings gefallen mir die Scrollbalken generell nicht. Beim Ausdrucken können Scrollbalken eh nicht funktionieren. Hier würde aber

pre { white-space:pre-wrap; }

helfen. --Fomafix 16:36, 1. Mär. 2010 (CET)

das hier ist ein ganz langer Text und der wird gleich in der Darstellung aus der Seite herausfallen und das sieht nicht wirklich gut aus und bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla

Auch bei den Benutzer-Scripts und -Styles (Benutzer:*/*.{css,js}) ist der Scrollbalken extrem störend. Auch hier gibt es ein Gegenmittel:

.source-css, .source-javascript { overflow:visible }

Allerdings deutet die Anzahl der Probleme und der notwendigen Workarounds auf eine ungetestete CSS-Erweiterung. Besser die Definition wieder entfernen und bei Bedarf style="overflow:auto" im Wikicode verwenden. --Fomafix 20:30, 1. Mär. 2010 (CET)

quetsch dazwischen: s. dazu Wikipedia:Fragen zur Wikipedia#Seit unlängst eingefügte Bildlaufleisten bei überbreiten Inhalten, hängt wohl damit zusammen. -jkb- 20:34, 1. Mär. 2010 (CET)

Ja. --Fomafix 20:39, 1. Mär. 2010 (CET)

Damit der überlange Text in einer Zeile nicht aus der gestrichelten Box rausläuft kann beim Firefox übrigens die Box automatisch vergrößert werden:

pre { min-width:-moz-min-content; }

--Fomafix 20:39, 1. Mär. 2010 (CET)

das hier ist ein ganz langer Text und der wird gleich in der Darstellung aus der Seite herausfallen und das sieht nicht wirklich gut aus und bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla

Als weitere Alternative für den Firefox bietet sich das Addon Toggle Word Wrap an. --Fomafix 20:45, 1. Mär. 2010 (CET)

Im Moment habe ich bei großen, langen js und css-Seiten ein Riesenproblem, weil der horizontale Scrollbalken nicht sichtbar ist, sondern sich erst drei Bildschirmseiten weiter unten versteckt. Merlissimo 03:03, 2. Mär. 2010 (CET)

Dann also erst mal wieder raus aus den zentralen CSS-Definitionen. Zu solchen Problemen sollte erst mal alle Lösungsvarianten aufgezeigt werden und diese intensiv getestet werden, bevor solche Änderungen durchgeführt werden. --Fomafix 09:07, 2. Mär. 2010 (CET)

Im IE7/8 kommt es auch zu vertikalen Scrollbalken, womit man dann die letzten Milimeter der Box scrollen kann, sieht unschön aus. Sollte daher als unausgereift wieder entfernt werden. Der Umherirrende 21:33, 6. Mär. 2010 (CET)

Naja, gut, ist wieder raus. --Euku:^⇄ 23:12, 11. Mär. 2010 (CET)

Metakram aus Quelltext entfernen

Wäre es technisch möglich, den ganzen Metakram (Navileisten, Personendaten, Kategorien, Normdaten, Interwikis, Sortierungen, Geokoordinaten, ....) aus dem Quelltext des Artikels zu separieren und als eigenständigen Reiter neben "Versionen/Autoren", "Bearbeiten",... zu setzen? Das würde den Quelltext vor allem für Neulinge übersichtlicher machen, aber auch die Speicher- und Ladezeiten reduzieren. Denn weniger Metakram wirds nicht mehr, eher mehr. 79.217.211.29 21:42, 30. Jan. 2010 (CET)

ich wäre dafür. das würde auch das beobachten von änderungen in artikeln deutlich erleichtern ...Sicherlich ^Post 00:02, 31. Jan. 2010 (CET)

So muesste es sein. Einfach mal ausprobieren. Wurd auch schon oft erwaehnt, passiert ist nie was.--Meister Koch ^P:W 00:24, 31. Jan. 2010 (CET)

Auch diese Diskussion ist schon wieder im Sande verlaufen.... HALLOOOO, kann sich mal jemand technisch versiertes der Sache annehmen?? 88.130.192.224 17:15, 1. Feb. 2010 (CET)

naja die seite ist IMO mehr zur beruhigung des fußvolkes. technische veränderungen werden hier eher nicht in gang gebracht. ... auch bugzilla ist IMO eher was für die halde ... wo es wirklich diskutiert wird; keine ahnung ...Sicherlich ^Post 17:27, 1. Feb. 2010 (CET)

Bei Wikia gibt es das beim Standard-Skin, da werden dann die Kategorien in einem eigenen Quelltextfenster angezeigt. Man muss dann die Anzeige umschalten, wenn man den gesamten Quelltext inkl. Kategorien sehen will. Technisch ist es also möglich. XenonX3 - (☎:±) 17:28, 1. Feb. 2010 (CET)

Gut, dann müsste nur noch über die Vor- und Nachteile diskutiert werden. Die Vorteile habe ich oben schon genannt. Nachteile sind mögliche Doppeledits. Wie seht ihr das? 129.13.72.198 12:42, 3. Feb. 2010 (CET)

Nö, 2 Fenster (oder mehr für Interwiki etc) heißt nicht unbedingt mehrmals speichern. Ansonsten wäre das evtl. gut für die unübersichtliche Reihenfolge Kats-PD-Interwiki, die dann immer richtig wäre. Ich brauchs aber nicht. -- ✓ ^Bergi 16:56, 5. Feb. 2010 (CET)

Naja, wenn, dass sollte es ehe optional sein, ob die Voreinstellung dann standardmäßig "an" oder "aus" ist, braucht man ja jetzt aber eh noch nicht diskutieren. Liegt es an dem Vorschlag oder an dieser Seite, dass so wenige Reaktionen kommen? 89.247.152.239 17:13, 5. Feb. 2010 (CET)

Man sollte denken, hier schaut mal ein technisch versierter Programmierer/Benutzer vorbei, wozu diese Seite ja eigentlich gedacht ist. So wenig wie sich hier tut könnte man sie auch löschen, es bringt ja nichts, wenn Verbesserungsvorschläge gemacht werden, aber keine rechte Diskussion aufkommt und sich niemand zur Ausführung berufen fühlt. Schade. 129.13.72.198 10:50, 17. Feb. 2010 (CET)

...kategorien u.ä. in einem eigenen editfenster wären auch eine möglichkeit zur validierung der syntax während der eingabe (mittels vorgegebener eingabemasken) - verirrte benutzerunterseiten kämen dann z.b. erst garnicht mehr rein in die kats, weil dann auf "slash" geprüft werden könnte... gruß, --ulli purwin _fragen? 12:36, 19. Feb. 2010 (CET)

Aaaaalso: Ja, nach den üblichen Design-Guidelines wäre eine Trennung von Metakrams und abhängigen Attributen (Kats, PND-Daten, Einzelnachweise, Bilder(!)) sogar auf Datenbank-Ebene wirklich wünschenswert. Ich bin auch überzeugt, dass sich auf Dauer auch die Serverfarmen der Foundation darüber freuen würden. Aaaaaaaber: Die Software gibt es bisher nicht her... leider. Was Wikia macht, ist eine 'Pseudotrennung', bei der die einzelnen Bestandteile zwar visuell getrennt angezeigt werden, im Endeffekt doch wieder im gleichen Datenbankfeld landen. Ich will nicht verhehlen, dass es für die Benutzbarkeit schön ist, wenn die verschiedenen Komponenten auch getrennt bearbeitbar sind. Allein glaube ich, dass es ein ziemlich grundlegendes re-design des Datenbank-Layouts und damit auch der Software selber bedarf, um dies zu realisieren, zuzüglich sehr aufwendiger Migration des Datenbestandes. Angesichts der Schwerfälligkeit im Software-Bereich von Mediawiki glaube ich, dass wir derartiges in diesem Leben nicht mehr erleben werden (Liebe devs: Ich weiß, ihr seid freiwillige Entwickler und von daher ist etwas genau dann fertig, wann es fertig ist. Seht es also nicht als Kritik an euch an, sondern als meine persönliche Beobachtung des Entwicklungsmodells von Mediawiki. Ich rede hier ausdrücklich von 'nice-to-haves'). --Gnu1742 13:15, 5. Mär. 2010 (CET)

Du bist mir mit eine ausführlicheren Antwort zuvorgekommen. Insbesondere des notwendige Datenbank-Redesign und dann die Anwendung auf den Projekten der Wikimedia Foundation macht man mal nicht so eben mit links. Das hat nichts damit zu tun, dass „sich niemand zur Ausführung berufen fühlt“. — Raymond ^Disk. 13:25, 5. Mär. 2010 (CET)

//schon wieder mit BK// Als richtig großer Laie kann ich mir das leider dennoch schlecht vorstellen, so sehr eine Vereinfachung des Quellcodes wünschenswert ist. Zum Lesen kann man sicherlich die oben besprochene Variante der Wikia aqnwenden. Aber, wenn ich etwas ändern möchte, sollte vermieden werden, dass ich (wirklich nur vereinfacht beispielsweise) den Inhalt der Tabelle, den ich sehe, lösche, die ganzen Divs und andere Codes samt Formatierung da aber bleiben. Schön wäre es, aber ob damit alle umgehen könnten, ob ob ob..., tja. -jkb- 13:34, 5. Mär. 2010 (CET)

Willst du jetzt Layout von Inhalt trennen oder was? Sei lieber froh, dass du {| || |} '' '''statt umständlichen <table> <th> <td> <i> <b> etc. nutzen kannst. divs dürften in normalen Artikeln eigentlich gar nicht vorkommen. Für Leute, die WYSIWYG haben wollen, gibts in Wikipedia:Textverarbeitung ein paar Links.
meint -- ✓ ^Bergi 15:28, 5. Mär. 2010 (CET)

also ich bin Sicherlich nicht froh, dass ich {| || |} nutzen muss. für einsteiger ist das eine beachliche hürde, für viele erfahrene zumindest schwierig. "Es geht auch schlechter" ist als argumentation etwas rückwärtsgerichtet :D ....Sicherlich ^Post 16:14, 5. Mär. 2010 (CET)

wieso musst? <table> funktioniert doch auch :) Aber mal im ernst, wenn du eine Tabelle einbauen musst/willst, wie sonst ohne irgendeine Auszeichnungssprache soll das gehen?
meint -- ✓ ^Bergi 18:41, 5. Mär. 2010 (CET)

• g* ... lass der phantasie freien lauf (frei von den begrenzten technischen gedanken); so frei musst du sie gar nicht laufen lassen. Excel ist deutlich einfacher zu bedienen. ...Sicherlich ^Post 21:43, 5. Mär. 2010 (CET)

Wenn ich mich recht erinnere ist für den Editor unter Vector geplant Vorlageneinbindungen Ein/Ausklappbar zu machen (betrifft insbesondere Infoboxen). Im Rahmen der Usability-Initiative könnte da also schon etwas kommen. Eine Trennung von Metadaten und Inhalt ist das aber nicht und würde (imho) auch nicht wie oben vorgeschlagen durch eine Datenbankänderung funktionieren. Kategorien/Interwikis lassen sich dynamisch einbinden: So etwas wie {{#ifeq: {{#expr: {{#time: s}} mod 2 }} | 0 | [[Kategorie:Foo]] }} muss man parsen und kann man nicht einfach statisch in eine Datenbank eintragen (MediaWiki soll mit bereits bestehenden Vorlagensystemen kompatibel bleiben). Außerdem unterscheiden sich die erhobenen Metadaten von Wiki zu Wiki: Die Personendaten sind rein Wikipedia-spezifisch.
Eine rein visuelle Trennung von Metadaten und Inhalt beim Bearbeiten ist meiner Ansicht nach sehr viel realistischer zu erreichen und ebenfalls hilfreich. --Church of emacs D B 18:41, 5. Mär. 2010 (CET)

für mich wäre es sehr schön, wenn ich die ganzen änderungen an den meta-daten nicht auf meiner beobachtung hätte, sondern stattdessen die letzte inhaltliche änderung. Das hin und herschupsen von kats, "korrigieren" von PDs usw. müllt die beobachtung voll. zumindest mir ist es völlig wurst welche kat in welcher reihenfolge drin ist oder nicht ...Sicherlich ^Post 21:43, 5. Mär. 2010 (CET) der meta-kram dürfte für den allergrößten teil der leser völlig egal sein und ist mehr zu bespaßung von Wikipedianern da

Naja, aber was ist wenn jemand [[Kategorie:Dies ist ein Vandalenedit]] einträgt? Es hat schon seinen Sinn, dass auch Änderungen an den Metadaten angezeigt und überprüft werden. Du hast natürlich recht, dass die meisten dieser Änderungen okay sind, aber kontrolliert gehören sie trotzdem. --Church of emacs D B 00:24, 6. Mär. 2010 (CET)

Kein Widerspruch, aber glaubst du nicht, dass sich auch Änderungen an ausgelagerten Metadaten entsprechend kontrollieren lassen? Separater Eintrag in die RC z.B. Ohne ein fertiges Konzept zu haben bin ich der Meinung, dass dieser ganze Metakram ausgelagert gehört. Wenn er ordentlich in separaten Tabellen erfasst wird, kann man noch viel mehr schöne Sachen damit machen und vor allem stört er im Artikel nicht mehr. — Raymond ^Disk. 09:46, 6. Mär. 2010 (CET)

Sicherlich meinte, dass er ja gerade die oftmals langweiligen Änderungen an den Metadaten nicht auf der Beo haben und damit wohl auch nicht überprüfen möchte.
Nun gut, ich persönlich glaube eher das die Tendenz zu einem WYSIWYG-Editor gehen wird, der Inhalt und Metadaten von alleine trennt – die Zukunft wird es zeigen. Vielleicht wäre eine Lösung, dass man Meta-Daten in einen neuen Namensraum auslagert, z.B. Metadaten:Wikipedia:Verbesserungsvorschläge (Meta eignet sich leider nicht als Präfix). Ähnliche Konzepte verwendet ja LiquidThreads, wo einzelne Beiträge im Thread-Namensraum gespeichert werden. Eine separate Tabelle oder ein paar zusätzliche Attribute im Datenbankschema wird es imho in absehbarer Zukunft nicht geben (was Schemaänderungen anbelangt bin ich recht pessimistisch). Ansonsten gebe ich dir natürlich vollkommen recht: Metadaten und Inhalt gehören getrennt. Gruß, --Church of emacs D B 19:45, 6. Mär. 2010 (CET)

"Wer beobachtet diese Seite"

Ein solches Tool fehlt mir manchmal, um auf einen Blick zu erkennen, wer sich um den Artikel kümmert. Machbar? Oder gibt es das schon auf irgendwelchen Umwegen? Gruß -- Dr.cueppers - Disk. 19:51, 5. Feb. 2010 (CET)

Das ist wegen Datenschutzgründen nicht gewünscht. Die Anzahl (falls ≥ 30) kannst du aber nachschauen. Diese Seite hier haben aktuell 508 Benutzer auf ihrer Watchlist. --Leyo 20:32, 5. Feb. 2010 (CET)

Wäre es nicht sinnvoll eine Spezialseite für unbeobachtete Artikel zu haben? M.E. sollte es für jeden Artikel mindestens einen Autor geben, der sie beobachtet. Das könnte durch so eine Seite sichergestellt werden. --Enantiodromie 17:16, 9. Feb. 2010 (CET)

→ Spezial:Ignorierte Seiten --Leyo 17:21, 9. Feb. 2010 (CET)

Danke, kannte ich noch nicht. Scheint aber nur etwas für Admins zu sein. --Enantiodromie 18:04, 9. Feb. 2010 (CET)

Ja nur für Admins. Sonst würden Vandalen gezielt diese Artikel ansteuern. Merlissimo 18:33, 9. Feb. 2010 (CET)

Die ersten > 700 Artikel sind übrigens alles Asteroid-Artikel. :-) --Leyo 18:35, 9. Feb. 2010 (CET)

Und ich dachte schon Braune Zwerge ;-) --Enantiodromie 18:47, 9. Feb. 2010 (CET)

Ein Vorschlag wäre mir dann doch noch eingefallen. Ist es möglich die Sichtbarkeit der Seite auf Sicher zu erweitern? Bei dieser Stufe ging es doch genau darum, Mitarbeiter zu haben, von den man weiß, dass sie nicht vandalieren. --Enantiodromie 23:13, 12. Feb. 2010 (CET)

Das wurde schon oft vorgeschlagen. Es bringt aber nichts. Die Seite zeigt immer nur die ersten 2000 Einträge an, man kann sich nicht die nächsten Einträge anschauen, bis man welche der ersten 2000 beobachtet. Die Seite ist also nur was für kleinere Wikis mit wenigen Artikeln, wobei ich dort gar nicht die Beobachtungsliste nutze, da reichen die Letzten Änderungen. So viel passiert da täglich einfach nicht. Hier in der WP ist das anders, hier kommen täglich tausende neue Beiträge dazu. XenonX3 - (☎:±) 23:21, 12. Feb. 2010 (CET)

Bei den gesichteten Versionen war dies Standardmäßig so gedacht. Als die auf de.wp aktiv wurden, konnten alle Sichter die Seite sehen. Dann haben sich aber einige Leute aufgeregt und es wurde wieder geändert. (Zumindestens kann ich mich so daran erinnern, kann auch etwas anders gewesen sein) Der Umherirrende 20:30, 6. Mär. 2010 (CET)

Image Siblings aktivieren

Image Siblings im Einsatz (rechts)

Hallo zusammen, immer wieder entdeckte ich, wie wenig bekannt unseren Nutzern doch Commons ist. Dabei könnten sie dort sehr viele Bilder finden, die sie vielleicht sogar suchen. Daher hat Magnus seine Image Siblings nun auch für die deutschsprachige Wikipedia portiert: Durch die Einbindung von Benutzer:Magnus Manske/image siblings.js in die eigene Monobook erhält man bei Betrachtung einer Bildbeschreibungsseite einen kleinen Ausblick, was sich noch in den Kategorien und auf den Galerieseiten des Bildes befindet. Das globale Freischalten der Erweiterung wäre sicher eine schicke Sache. Einziges Problem, das ich derzeit noch sehe, sind die größtenteils englischen Namen der Seiten und Kategorien auf Commons. Welche Folgen die Aktivierung auf die Serverlast hätte, entzieht sich auch meiner Kenntnis. Danke, --Flominator 16:35, 7. Feb. 2010 (CET)

Also ich finde das überlastet die Bilderseite (graphisch). Wenn du meinst, dass Commons nicht bekannt genug ist, könnte man ja auch den Einbindungshinweis stärker betonen. Was mir allerdings tatsächlich fehlt, ist das Einbinden der Commonscats. Nicht nur bei der Bildbeschreibung und sogar der globalen Nutzung sowie den Metadaten geht das, aber die Kategorien werden vernachlässigt. Auch der Logbuch-Link zeigt im Gegensatz zu "Bearbeiten" nicht nach Commons, sondern in die de.WP. Diese Beiden Punkte würden mir schon reichen, die Einbindeung der jeweils ersten beiden Bilder aus den Commonscats finde ich überfrachtet.
meint -- ✓ ^Bergi 20:33, 8. Feb. 2010 (CET)

Wäre das ein weiterer Fall für einen Eintrag hier oder ist das eher ein Feature Request? Zudem wäre es schön, auch die Notizen auf den Bildern in de.wp verfügbar zu haben. Gruß, --Flominator 17:43, 28. Feb. 2010 (CET)

Image Siblings wird nun als Gadget diskutiert: MediaWiki_Diskussion:Gadgets-definition#Image_Siblings --Flominator 19:49, 28. Mär. 2010 (CEST)

Zusammenfassung von Miniedits zu einem Edit

Ich bin für die Zusammenfassung von Miniedits, die innerhalb einer ¼ Stunde, bei einem Artikel von einem Autor getätigt werden zu einem Edit.

Es ist einfach zusätzliche Arbeit sich durch 10 bis 20 Microedits der Versionsgeschichte eines Autor bei einem Artikel zu Hangeln. Man kann kleine Änderungen, auch in unserer schnelllebigen Zeit, sammeln - eben über 15 Minuten hinweg - und dann eintragen. Wenn dies nicht möglich ist werden die Edits einfach zusammengefasst und wie einer behandelt (mit Uhrzeit des letzten Edits innerhalb der Zeitspanne). Achtung Wertung: Mir kommt es immer so vor als wenn die Autoren die diese Microedits tätigen möglichst viele Edits für sich verbuchen wollen oder sich nicht konzentrieren können.

Die Größe der Edits die nicht innerhalb von 15 Minuten zusammengefasst werden, sollten größer als 1 kB sein. Außnehmen sollte man Diskusionsseiten.

Wenn binnen dieser 15 Minuten ein weiterer Autor einen Edit macht, sind die 15 Minuten des vorherigen Autors, um reagieren zu können hinfällig, d. h. es wird neu gezählt.

Um die Miniedits zu verhindern sehe ich allerdings noch eine Lücke. Es könnte jemand zwei Accounts anlegen und abwechselnd mal mit dem einen mal mit dem anderen einen Edit fabrizieren. Das sollte aber auffallen. -- Kandro 22:01, 17. Feb. 2010 (CET)

wurde schon mehrfach vorgeschlagen und diskutiert, ich würde das auch definitiv befürworten. von mir aus auch nur dann eine automatische zusammenfassung der edits, wenn die zusammenfassungszeile nicht jeweils genutzt wurde. --JD {æ} 22:08, 17. Feb. 2010 (CET)

Danke für die schnelle Antwort. Gab's hierzu auch eine Abstimmung? -- Kandro 22:14, 17. Feb. 2010 (CET)

Abgelehnt, weil dann Bearbeitungskommentare untergehen würden. --h-stt !? 00:33, 18. Feb. 2010 (CET)

Kandro: mag sein, dass es Benutzer mit der von dir vermuteten Motivation gibt; aber ich habe früher auch abschnittsweise editiert (bevor ich darauf hingewiesen wurde, dass dann jedesmal der gesamte Text und nicht nur der Unterschied gespeichert wird). Das Editieren größerer Artikel ohne Inuse-Baustein (was auch eine zusätzliche Versionsspeicherung erforderlich macht) ist sehr lästig, wenn man nicht speichern kann, weil jemand anderes zwischenzeitlich editiert hat. Dieses Risiko wird umso größer, je länger man für den Edit braucht - und die Folgen sind umso ärgerlicher, weil man die Veränderungen über einen größeren Bereich verteilt zusammensuchen muss.

Ich vermisse daher eine entsprechende Zusammenfassungsmöglichkeit auch; das Problem mit den verlorenen Bearbeitungskommentaren müsste dann in Kauf genommen oder anders gelöst werden (ich bin ohnehin einer derjenigen, die die Angabe von Quellen in der Zusammenfassung ablehnt: die findet später kein Mensch wieder. Quellen gehören in den Artikel). --Snevern 03:56, 18. Feb. 2010 (CET)

@h-stt: siehe dazu meine vorgeschlagene einschränkung. --JD {æ} 10:42, 18. Feb. 2010 (CET)

Wir machen aber massiv Werbung dafür, den Bearbeitungskommentar zu benutzen. Eine Funktion dran zu knüpfen, dass er nicht verwendet wird, erscheint mir da grob kontraproduktiv. --h-stt !? 19:17, 18. Feb. 2010 (CET)

Man kann die Bearbeitungskommentare ja auch zusammenfassen, dann geht nichts verloren. Wenn man dann auch noch ein paar Zeilenumbrüche einfügt bleibts auch schön übersichtlich. --David Lichti 16:02, 19. Mär. 2010 (CET)

Meine E-Mail-Adresse in Benachrichtigungs-E-Mails anzeigen

Vorhin hat mich Li (das von dem mal was konstruktives kommt ...) indirekt darauf hingewiesen, dass obige Zeile mit Checkbox nicht sinnvoll/nötig ist, denn bei uns ist ja das Informieren per Mail bei Änderungen nicht möglich. Könnte man die Zeile ausblenden oder ist es aus Kompatibilitätsgründen so erforderkich? --Atlan ^Disk. 12:41, 20. Feb. 2010 (CET)

Nein, die Wikisoftware wird global installiert. Die E-Mail-Benachrichtigungen sind nur in den fünf größten Projekten abgeschaltet. Irgendwann werden die Einstellungen auch global gelten. Merlissimo 12:54, 20. Feb. 2010 (CET)

aber die Checkboxen für die E-Mail-Benachrichtigungen sind für die 5 Projekte doch auch weg? --Atlan ^Disk. 13:12, 20. Feb. 2010 (CET)

Ich habe dafür mal Bug 22747 eröffnet. Der Umherirrende 20:19, 6. Mär. 2010 (CET)

Fehlender Artikel -> Liste von anderen Wikipedias die den Artikel führen

Hallo,

ich hoffe ich bin hier mit meinem Verbesserungsvorschlag richtig. Der Betreff sagt eigentlich schon alles. Ich denke wie mir geht es auch vielen anderen Benutzern, dass sie die deutsche Wikipedia verwenden und dann, wenn sie den Artikel nicht finden gleich in der englischen oder einer anderen Wikipedia nachschauen. Die Idee ist nun folgende: Wenn ein Artikel nicht gefunden wurde, der gleichnamige Artikel aber in einer anderen Wikipedia existiert, dann wird man über eine Meldung darauf hingewiesen und/oder man hat die Möglichkeit direkt auf einen kleinen Button zu klicken, der eine Liste aufruft, die alle gleichnamigen Artikel in anderen offiziellen Wikipedias aufführt. -- 134.2.245.100 19:23, 27. Feb. 2010 (CET)

Schon unendlich oft vorgeschlagen worden, und immer um sonst. Denn woher soll das System wissen, dass dein Suchbegriff dem Titel eines Artikels in einer anderssprachigen Wikipedia entspricht? Wenn wir keinen Artikel Pferd hätten, wie soll das System "horse" oder "paard" finden? Dies ist ein triviales Beispiel, vergiss nicht, dass wir massenhaft Artikel zu Themen haben, die in Wörterbüchern so nicht vorkommen. --h-stt !? 18:46, 28. Feb. 2010 (CET)

Naja ich dachte dabei eher daran das ein Artikel vorgeschlagen wird, der exakt den gleichen Namen hat. Bsp: Yair Bacharach Yair Bacharach. -- 78.42.11.32 16:06, 3. Mär. 2010 (CET)

Also en:Gift, wenn Gift nicht existieren würde. Merlissimo 16:11, 3. Mär. 2010 (CET)

Ja, ich gehe natürlich davon aus, dass der Nutzer diese Option auch nur dann wahrnimmt, wenn er die entsprechende Sprache beherrscht. In dem von dir genannten Beispiel würde man ja dann erkennen, das es nicht die gleichen Begriffe sind. -- 78.42.11.32 16:23, 3. Mär. 2010 (CET)

Was heißt "...dachte dabei eher daran das ein Artikel vorgeschlagen wird, der exakt den gleichen Namen hat..." - das klappt nicht einmal bei Personennamen, s. Breshnev - Breschnew - Brežněv ... -jkb- 16:21, 3. Mär. 2010 (CET)

In diesem Fall würde kein Vorschlag gemacht werden. -- 78.42.11.32 16:25, 3. Mär. 2010 (CET)

http://vs.aka-online.de/globalwpsearch/ ist bekannt? Merlissimo 16:27, 3. Mär. 2010 (CET)

Ja, sowas meinte ich, nur das nur die Artikel vorgeschlagen werden, die auch tatsächlich existieren. -- 78.42.11.32 16:29, 3. Mär. 2010 (CET)

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
Vorlage:SortKeyName	23. August 1902		58	…
Vorlage:SortKeyName	19. Januar 1937		24	…
Vorlage:SortKeyName	19. März 1934		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 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)

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

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)

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)

„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 WP:NPOV, WP:RK, WP:WEB, WP: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: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)

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

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)

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

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