Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2010

Spracheinstellung des Browsers für "In anderen Sprachen"-Liste verwenden

Die "In anderen Sprachen"-Liste in der Artikelansicht sollte anhand der vom Browser im HTTP Request gesendeten "Accept-Language" Header (RFC 2616 Sektion 1.4) aufgebaut werden. Das bedeutet entweder die Liste mit diesen Sprachen beginnen oder diese Sprachen hervorheben. Der Sinn sollte klar sein: Man erreicht schneller die einem vertrauten Sprachen. (nicht signierter Beitrag von 87.168.229.240 (Diskussion) 00:12, 15. Mai 2010)

Die Idee gefällt mir sehr gut! Sollte eigentlich auch nicht kompliziert umzusetzen sein, oder? --Revo Echo der Stille

00:13, 15. Mai 2010 (CEST)

Wirklich eine gute Idee! Zum Hervorheben müsste nur eine CSS-Datei mitgeschickt werden, die für jede Sprache ein .interwiki-xyz { font-weight: bold; } enthält (xyz ist der jeweilige Code der Sprache), das sollte wirklich nicht allzu schwer sein. Wer stellt die Idee bei Bugzilla ein? --Schnark 09:09, 15. Mai 2010 (CEST)

Scheint demnächst zu kommen: rev:67559 --Schnark 09:19, 9. Jun. 2010 (CEST)

Kommt bald für Vector, sollte damit hier erledigt sein. Kann auf Wikipedia:NEU beobachtet werden. Der Umherirrende 22:27, 18. Jun. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:27, 18. Jun. 2010 (CEST)

Neues Format für Einzelnachweise

Ich halte die jetzige Art und Weise der Einbindung von Literaturnachweise für ziemlich unbequem:

Das Gras ist grün.^[1]
Manchmal wird Gras gelb.^[1]

↑ ^a ^b M. Musterman: Über die Farbes des Grases. ...

Sollte der Satz, an dem der Literaturnachweis dranhängt gelöscht werden, würde für den zweiten Satz die Referenz fehlen und ich müsste das umständlich umformatieren.

Es wäre schön wenn die Verlinkung genau umgekehrt funktionierte, dass heißt ich habe das Literaturverzeichnis als eine Liste von Titeln vorliegen und der Fließtext verlinkt auf ein entsprechend markiertes Werk in dem Literaturverzeichnis-Block.

Das würde die Pflege der Einzelnachweise vereinfachen und den Code eines Artikels mit vielen Einzelnachweisen wesentlich übersichtlicher gestalten. Letztlich funktionieren professionelle Literaturverwaltungsprogramme auch auf diese/ eine ähnliche Art und Weise.

LG--Chadmull 01:08, 16. Aug. 2010 (CEST)

Das geht bereits: Statt <references /> schreibt man <references>…</references>. Dazwischen stehen dann die <ref>-Tags. --Morten Haan Wikipedia ist für Leser da 16:11, 16. Aug. 2010 (CEST)

Ich glaub, ich hab noch nicht raus, wie es geht, aber ich schau mal, ob ich Beispiele finde, wo jemand das Format angewendet hat. Danke! --Chadmull 18:28, 16. Aug. 2010 (CEST)

Siehe auch Hilfe:Einzelnachweise#Inhalt der Einzelnachweise am Ende des Artikels --Der Umherirrende 20:43, 16. Aug. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:43, 16. Aug. 2010 (CEST)

Auto-Login bei anderen Wikimedia-Projekten mit SUL

Hallo, wenn man einen SUL hat, ist man derzeit automatisch in anderen Sprachversionen der Wikipedia eingeloggt, wenn man sich einmal in der de.wp einloggt - d.h. ich kann auf einen Interwiki klicken und bin in der jeweils anderen Sprachversion automatisch auch eingeloggt.

Bei anderen Projekten, bei denen eigentlich ebenfalls der SUL existiert, wie "commons", funktioniert das nicht. D.h. hier muss ich mich, obwohl in in der de.wp schon eingeloggt bin, nochmal neu einloggen.

Lässt sich das so einrichten, dass ein einmaliges einloggen für den gesamten SUL ausreicht? Danke+Grüße --Teilzeittroll 19:32, 17. Nov. 2010 (CET)

Das funktioniert eigentlich schon. Das Hindernis bei dir ist wahrscheinlich dein Browser, weil dieser nicht erlaubt, dass Cookies Domainübergreifend verwendet werden. Eigentlich eine sinnvolle Konfiguration. Bei einigen Browser kannst du manuell Ausnahmen für bestimmte Domains angeben. Dann sollte es funktionieren. Wenn du die Sicherheitseinstellungen nicht lockern möchtest, hilft der SSL-Zugang, weil dort alles unter der gleichen Domain zusammensgefasst ist. Merl issimo 19:52, 17. Nov. 2010 (CET)

Danke, dann werde ich einen Deiner Lösungsvorschläge umsetzten. --Teilzeittroll 19:57, 17. Nov. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Teilzeittroll 19:57, 17. Nov. 2010 (CET)

MediaWiki:Confirmrecreate

Der Text, der beim Speichern einer während des Bearbeitens gelöschten Seite angezeigt wird, enthält die Löschbegründung. War das schon immer so, dass in der Begründung enthaltene Vorlagen dabei expandiert werden (gerade mit {{SLA}} passiert) oder ist da vor kurzem eine Softwareänderung erfolgt? Ansonsten: Lässt sich das Problem durch ein <nowiki> (evtl. {{#tag:nowiki) beheben? Ich würde die Änderung an der Systemnachricht auch im Translatewiki durchführen können, sie wird aber lokal überschrieben.
fragt -- ✓ ^Bergi 20:39, 30. Nov. 2010 (CET)

Es sollte nicht einfach so die Standard-Message geändert werden, da es ja schon eine über die Sprache hinausgehenden Unterschied zum Original ist, was zu Vermeidung gilt. Du könntest das ganze als Bug melden oder über die Support-Seite des translatewiki darauf aufmerksam machen. Für die lokale Änderung ist Wikipedia:AA gut geeignet. Soweit ich weiß, gab es in dem Bereich keine Änderung, das dürfte also "schon immer so sein". Der Umherirrende 21:45, 30. Nov. 2010 (CET)

Ist das denn ein Bugzilla-würdiger Bug? Die MediaWiki-Software dürfte doch damit eigentlich nichts zu tun haben, oder meinst du das <nowiki> solle automatisch in die Nachricht eingefügt werden (spezifisches Rendern ist wohl unmöglich)? -- ✓ ^Bergi 18:01, 1. Dez. 2010 (CET)

Man könnte das nowiki in die Original-Nachricht aufnehmen oder MediaWiki wrapped den Parameter in nowiki, wenn es ihn an die Nachricht übergibt. Beides würde allen Nutzern der neuesten Wiki-Version zugute kommen. Auch Änderungen an Nachrichten können über Bugzilla abgehandelt werden. Warum sollten wir das Problem nur lokal beheben, wenn es alle Installationen betrifft? Der Umherirrende 18:20, 1. Dez. 2010 (CET)

Nein, lokal wolle ich nur testen lassen ob nowiki das Problem überhaupt behebt. Ich wusste aber weder, dass man das über translatewiki:Support lösen (lassen) kann noch dass sich auch Bugzilla derart mit Systemnachrichten beschäftigt. Danke, -- ✓ ^Bergi 18:38, 1. Dez. 2010 (CET) PS: bugzilla:26187

Die Systemnachrichten gehören ja auch zu MediaWiki, daher kann man sie auch mit einem Bug versehen. Auf der Support-Seite des Translatewikis kann man beispielsweise Rechtschreibfehler im englischen Original anmerken, da man die nicht direkt bearbeiten sollte. Ich weiß aber nicht, ob dieser Fehler dort auch berücksichtigt wird, aber im Zweifelsfall wird einem dort auf Bugzilla verwiesen. Eine lokale Änderung kann man ja immer noch erreichen. Der Umherirrende 22:05, 1. Dez. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:05, 1. Dez. 2010 (CET)

Shortcuts für Spezialseiten

Wäre es möglich, Shortcuts für Spezialseiten einzurichten, z.B. SP:RC für Spezial:Letzte Änderungen, SP:NS für Spezial:Neue Seiten etc.? Derzeit funktionieren Shortcuts nur mit dem Präfix "WP" oder "P". Grüße --Wkpd 17:54, 7. Okt. 2010 (CEST)

Der möglich Namensraumprfix "SP" für Spezialseiten würde nur sehr wenig bringen, weil der Spezialseitenname selber technisch bedingt lokal nicht abgekürzt werden kann. Eine Änderung beträfe alle Wikipedias. Es wäre also nur "SP:Letzte Änderungen" möglich und nicht "SP:RC". Merl issimo 18:04, 7. Okt. 2010 (CEST)

Eine Weiterleitung auf eine Spezialseite ist aktuell technisch auch nicht möglich. Das weitere Problem wäre, das im Spezialseitennamensraum keine Seiten angelegt werden können, also könnte man keine Weiterleitungen lokal einrichten, sondern müsste diese direkt in MediaWiki integrieren und das, so finde ich, ist etwas übertrieben, vorallem betrifft es alle Installationen. Der Umherirrende 18:12, 7. Okt. 2010 (CEST)

Schade. Danke für die Antworten! --Wkpd 18:17, 7. Okt. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 22:50, 4. Aug. 2011 (CEST)

Zusätzliche Links bei Versionsvergleich über mehrere Versionen

Beim Versionsvergleich steht: (Der Versionsvergleich bezieht 6 dazwischenliegende Versionen mit ein.) stattdessen sollte dort beispielsweise stehen: (→Der Versionsvergleich bezieht 6 dazwischenliegende Versionen mit ein.←) Dann könnte man nach dem Versionsvergleich über mehrere Versionen entscheiden ob man sich die einzelnen Versionsvergleiche noch anschauen will. Dabei hätte man die Möglichkeit zeitlich vorn oder hinten zu beginnen. Das ganze direkt ohne den Aufruf anderer Seiten. -- Diwas 13:43, 11. Jan. 2010 (CET)

Gute Idee. Das müsste per JavaScript recht leicht zum implementieren sein. Vielleicht mache ich mich mal dran. --Fomafix 14:15, 13. Jan. 2010 (CET)

Das würde mich freuen. Grüße -- Diwas 14:19, 13. Jan. 2010 (CET)

Hier habe ich was für Deine Benutzer:Diwas/monobook.js:

addOnloadHook(function() {
	var multidiff = getElementsByClassName(document, "td", "diff-multi")[0];
	if (! multidiff) return;

	var leftlink = document.getElementById("mw-diff-otitle1").getElementsByTagName("a")[0].href;
	var left = document.createElement("a");
	left.href = leftlink + "&diff=next";
	left.appendChild(document.createTextNode("→"));
	multidiff.insertBefore(left, multidiff.firstChild);

	var rightlink = document.getElementById("mw-diff-ntitle1").getElementsByTagName("a")[0].href;
	var right = document.createElement("a");
	right.href = rightlink + "&diff=prev";
	right.appendChild(document.createTextNode("←"));
	multidiff.appendChild(right);
})

Ich teste es gerade. Bei Problemen bitte melden. Kennst Du Benutzer:DerHexer/revisionjumper? --Fomafix 23:33, 14. Jan. 2010 (CET)

Ich sehe leider noch keine Pfeile. Muss ich außer dem Reinkopieren und Browsercache leeren noch was machen? Oder liegt es daran, dass ich den IE benutze? -- Diwas 12:44, 15. Jan. 2010 (CET)

document.getElementsByClassName() wird noch nicht von allen Browsern unterstützt. Als Alternative gibt es in http://bits.wikimedia.org/skins-1.5/common/wikibits.js die Methode getElementsByClassName(oElm, strTagName, oClassNames). Ich habe es in dem obigen Codeschnipsel eingebaut und mit erfolgreich mit dem IE6 getestet. --Fomafix 16:50, 15. Jan. 2010 (CET)

Ja super, das läuft. Dank dir. Den revisionjumper probier ich dann auch mal. Grüße -- Diwas 17:01, 15. Jan. 2010 (CET)

Gadget Anzeige Weiterleitungen

Ähnlich dem Gadget Wikipedia:Helferlein/Begriffsklärungs-Check würde ein Script zur farbigen Anzeige von Links auf Redirects sehr sinnvol finden (habe schon mal anderswo gesehen). Man könnte 1) besser aufräumen 2) beim Schreiben von Artikel dies gleich vermeiden. -jkb- 10:14, 17. Jan. 2010 (CET)

Das gibt es längst. Du muss nur in deiner monobook.css mit

.mw-redirect { background: #fda; }

die Weiterleitungen farbig hervorheben. Aber Vorsicht! Links auf Weiterleitungen sind in vielen Fällen explizit erwünscht und sollen auf keinen Fall „aufgeräumt“ oder „vermieden“ werden, da sie kein Fehler oder Makel darstellen (Hilfe:Weiterleitung#Verlinkung auf eine Weiterleitung). Ich lasse mir die Weiterleitungen daher nur beim Drüberfahren anzeigen:

body .mw-redirect:hover, .mw-redirect:hover * { background: #fda; }

--Fomafix 11:11, 17. Jan. 2010 (CET)

Aha, funktioniert. Klar, mit Aufräumen meinte ich nicht irgendeinen brutelen Zug und alles weg. Manche machen so was aber aus Unachtsamkeit oder mangels Kontrolle. Jedenfalls, danke für die Hilfe! Gruß -jkb- 11:34, 17. Jan. 2010 (CET)

Mit weiterleitungen.js kannst du dir auch noch anzeigen lassen, wohin die Weiterleitung führt. -- ✓ ^Bergi 13:52, 17. Feb. 2010 (CET)

"Wildcard"-Suche

Übertrag von Wikipedia:Verbesserungsvorschläge#"Wildcard"-Suche

Hi, ist es möglich, die Spezialseite "Linkliste" durch eine Art Wildcard-Suche zu erweitern, mit der man Links auf Seiten suchen kann, deren Klammerzusatz man nicht kennt. Grund: Bei der Auflösung von BKL-Links (speziell zu Personen) findet man in der BKL mitunter noch keinen passenden Eintrag. Dann wäre es ganz gut zu wissen, ob es schon Rotlinks auf diese Seite mit irgendwelchen Klammerzusätzen gibt, die vielleicht passen könnten. Grüße -- Jesi 02:20, 5. Feb. 2010 (CET)

Hört sich ziemlich cool an, wäre aber wohl ein Fall für Wikipedia:Verbesserungsvorschläge/Feature-Requests --Flominator 16:38, 7. Feb. 2010 (CET)

/Übertrag

Nachtrag: Mit einer solchen erweiterten Suche sollte auch vermieden werden können, dass gleichen Personen unterschiedliche Klammerzusätze gegeben werden. Die Suchmaske könnte etwa so aussehen "Vorname Name (*)". -- Jesi 18:21, 7. Feb. 2010 (CET)

Noch ein Nachtrag: Die "Ergbnisliste" müsste nicht die Seiten anzeigen, von denen aus verlinkt wird, sondern es müsste nur angezeigt werden, auf welche Lemmata verlinkt wird, also etwa

verlinkt wird auf:

Vorname Name (Maler)

Vorname Name (Schriftsteller)

usw. -- Jesi 17:25, 8. Feb. 2010 (CET)

Es geht also eher darum, Spezial:Gewünschte Seiten zu durchsuchen; oder verstehe ich das falsch?
meint -- ✓ ^Bergi 13:28, 17. Feb. 2010 (CET)

Hm ja, das wäre eine Möglichkeit, wenn die denn einigermaßen "gepflegt" (also aktuell und vollständig) und die Suche einigermaßen praktikabel wäre. Aber wenn ich zum Beispiel wissen will, ob außer auf "Albert Koch (Politiker)" vielleicht noch andere Links auf dieselbe Person zeigen (z.B. "Albert Koch (SPD)", "Albert Koch (Bayern)" usw.), dann wäre eine Liste der Seiten, die auf "Albert Koch (*)" zeigen willkommen. Wenn ich mir das aus den "gewünschten Seiten" raussuchen muss, erscheint mir das zu langwierig. Und da die Linklisten offenbar gut indiziert sind, dürfte es sicher kein allzugroßes Problem sein, eine solche (*)-Liste anzuzeigen. -- Jesi 00:03, 19. Feb. 2010 (CET)

Doch, weil die Indizierung solcher *-Listen ist wohl deutlich umfangreicher ist. Aber ein Spezial:Links oder Spezial:Verlinkte Seiten, das durchsuchbar wäre, ist sicher nicht schlecht.
meint -- ✓ ^Bergi 21:38, 25. Feb. 2010 (CET)

Deinen ersten Einwand verstehe ich nicht (oder mein Wissen ist falsch). In der Indexliste stehen ja die Einträge "Vorname Name (Klammer_1)" bis "Vorname Name (Klammer_n)" sowieso alle schon drin und in der Indexreihenfolge auch hintereinander. Man muss also lediglich den ersten Eintrag "Vorname Name (" suchen und dann bis zum letzten auflisten. -- Jesi 22:58, 25. Feb. 2010 (CET)

Ja, stimmt eigentlich. Ich kenne mich mit WP-internen Indizierungsdatenbanken auch nicht aus, aber es geht ja eben um die Ausgabe dieser irgendwie gearteten Indexliste. Theoretisch ist diese ja 2-dimensional, nämlich einmal nach dem verlinkten Lemma, und einmal nach den verlinkenden Seiten. Praktisch ausgeben lässt sich aber wohl nur eine Dimension. Und Spezial:Linkliste - also das zweite - gibts ja schon. das erste würde mir also noch fehlen, hilfreich wäre dann natürlich ein gleich eingebauter Link zur Linkliste.
meint -- ✓ ^Bergi 15:04, 26. Feb. 2010 (CET)

Informationen zu den Tabellen finden sich unter mw:Manual:Pagelinks table, eine Machbarkeitsanfrage sollte direkt an die Entwickler über Bugzilla erfolgen. Auf Basis eines Dumps kann man sich dies aber auch selber schreiben (unter Ignorierung der Links aus Vorlagen) --Der Umherirrende 16:45, 15. Mär. 2010 (CET)

Neue Spezialseite Spezial:Benutzerinfo

Hi, ich hab unter Bug 22516 einen Vorschlag für eine neue Spezialseite gemacht. Bevor ich das implementiere, wäre es hilfreich Feedback zu bekommen. Wenn jemand weitere Ideen hat, kann er diese auch gerne mit einbringen. Gruß, --Church of emacs D B 15:39, 14. Feb. 2010 (CET)

Verständisfrage: sind die dort vorgeschlagenen Seiten zugänglich nur für den jeweiligen User oder für jeden, der die User-Seite öffnet? Danke -jkb- 15:44, 14. Feb. 2010 (CET)

Für jeden. Es werden auch keine neuen Daten veröffentlicht, sondern nur bereits bekannte Daten von verschiedenen Seiten auf einer Seite zusammengestellt. Eine Ausnahme ist vielleicht der Editcounter, der ja bislang nur über den Toolserver erreichbar ist (für die Wikimedia-Projekte würde es keinen Unterschied machen, höchstens für Wiki-Projekte die keinen Editcounter haben und auch keinen möchten). Andererseits ist die Anzahl der Bearbeitungen mit ein wenig Aufwand durch Spezial:Beiträge ermittelbar. Gruß, --Church of emacs D B 15:57, 14. Feb. 2010 (CET)

Danke. Ganz einfache globale Editcounterzahlen sind auch aus meiner Sicht OK, siehe jedoch Wikipedia:Fragen zur Wikipedia#Mitarbeit, wo es gerade kam. Sonst unterstütze ich die Idee. -jkb- 16:03, 14. Feb. 2010 (CET)

Stellt sich die Frage, wie der Editcounter aussieht. Die Anzahl der Bearbeitungen die jeder in den Einstellungen stehen hat, kann man jetzt auch schon für jeden Benutzer auslesen (per API). Eine Aufbereitung auf Namensräume wäre hingegen neu. Der Umherirrende 16:47, 15. Mär. 2010 (CET)

Links auf andersprachige Wikipedias wenn kein deutscher Artikel gefunden wurde.

Immer (ohne Ausnahme) wenn ein Artikel in der deutschen Wikipedia nicht vorhanden ist, möchte ich auch in der englischen und manchmal in der französischen Wikipedia suchen. Mein Vorschlag: Ähnlich wie die Links die auf andersprachige Artikel verweisen, wenn sie vorhanden sind, möchte ich einen Link auf der "nicht gefunden" Seite haben, der mich direkt auf eine Andersprachige Wikipedia verweist um dort zu suchen. Die Sortierung sollte jedoch nicht alphabetisch, sondern nach der Größe der Wikipedia erfolgen. Also immer als erstes die englische, (deutsche), polnische, italienische chinesisch...

Es könnte z.B. so aussehen: [1]

Und wohin sollte verwiesen werden beispielsweise im Falle eines Lemmas, das mehr bedeutungen hat, im Deutschen jedoch die Bedeutung A als die meistgebräuliche, während in der en.wiki alle Bedeutungen die gleiche Gewichtung haben, so daß unter dem eigentlichen Lemma sich dort BKL befindet??? Das kann man doch nur manuell machen, meist erst dann, wenn klar ist, welche/wieviel Artikel in der jeweiligen Sprache es geben wird. (Außerdem, einen Stub zu dem Lemma zu schreiben wäre u.U. einfacher als all dies zusammenzusuchen und so ein Interwiki zu machen. -jkb- 17:16, 22. Feb. 2010 (CET)

Es würde ja ausreichen, anstelle der Interwikilinks Links auf die Suchseite des betreffenden Wikis zu setzen. Gibt es den Artikel dort, wird man automatisch weitergeleitet. Fehlt mir genauso wie die Option "alle Wikis" auf [2].
meint -- ✓ ^Bergi 18:47, 23. Feb. 2010 (CET)

Ich bin absolut auch der Meinung, diese Funktion gehört implementiert. Es geht dabei nicht um eine 100% richtige Verknüpfung, sondern darum dem Suchenden weiter zu helfen. Denn was machst du wenn du deinen gesuchten Artikel nicht findest im deutschen?? Du suchst im mindestens mal im Englischen. Also eine 95% Lösung ist besser als gar keine. Bitte umsetzen!! Gruss 80.219.254.67 14:30, 7. Mär. 2010 (CET)

Ich schließe mich an. Wenn ein Artikel in der deutschen Wikipedia nicht gefunden wurde, ist der umständliche Weg: Wieder auf die Startseite, dort runterscrollen, auf "Englisch" klicken, dann erst suchen. Leichter wäre: Auf der Artikel-nicht-gefunden-Seite klicken auf (z. B.) "Diesen Begriff in der englischen/in anderssprachigen Wikipedias suchen". --178.203.65.147 13:44, 30. Jan. 2011 (CET)

Sehe ich ganz genau so. Diese Möglichkeit würde schon vielen weiterhelfen und wird sicher auch relativ einfach zu implementieren sein. Ich stelle mir das so vor: "Wenn dir die folgenden Suchergebnisse nicht weiterhelfen, wende dich bitte an die Suchhilfe oder klicke hier um den Artikel in anderen Sprachen zu suchen: ENGLISCH FRANZÖSISCH CHINESISCH WEITERE_SPRACHEN" --129.247.247.239 08:52, 10. Mär. 2011 (CET)

Ich hatte das Problem auch schon einmal angesprochen, war aber offenbar am falschen Ort (siehe meine eigene Diskussion). Nun, ein Teil davon ist schon implementiert, und zwar: wenn für ein Suchwort weder ein Artikel existiert, noch es in einem anderen gefunden wird, so erscheint der Vorschlag, ob in einem andersprachigen Wiki gesucht werden soll. Ist kein Lemma vorhanden, das Wort erscheint aber in irgendwelchen Artikeln, so erscheint dieser Vorschlag nicht. Ein erster Schritt wäre nun, diese Anzeige IMMER erscheinen zu lassen, wenn kein Lemma vorhanden ist (dort lässt sich ja direkt zu anderen Sprachen gehen). Und in einem zweiten Schritt sollte es dann nicht einfach auf eine manuelle Sprachwahl gehen, sondern es sollte (in absteigender Reihenfolge nach Treffern sortiert) angezeigt werden, a) ob ein Artikel existiert, und b) in welchen Sprachen wieviele Treffer gefunden wurde. Ich stelle mir das als Liste vor - linke Spalte, wenn ein Artikel existiert, rechte Spalte Nennung der Sprache mit Anzahl Treffern (als Zahl) in anderen Artikeln. --ProloSozz 02:36, 13. Feb. 2011 (CET)

includeable includes

…oder so. Wie kann ich es erreichen, dass ich in eine Vorlage das <onlyinclude>-Tag und Co einbinden kann? Ich vermute mal, dass MediaWiki das nicht zulässt. Mein Versuch war, ähnlich wie bei der substituierten Unterschrift den Parser per <includeonly><only</includeonly><includeonly>include></includeonly> an der direkten Auswertung zu hindern, was aber gescheitert ist. Diese Methode funktioniert nämlich nur beim Substituieren der Vorlage. Könnte man in MediaWiki eine Funktionalität einrichten, die es erlaubt solche tags erst in der eingebundenen Vorlage anzuwenden? Damit ließe sich u.a. die Notwendigkeit von Metadatenvorlagen umgehen, und die Daten werden trotzdem nur einmal notiert.
meint -- ✓ ^Bergi 15:15, 15. Mär. 2010 (CET)

Übrigens wird {{#tag:includeonly|Irgendwas}} zu Unbekannter Extension-Tag „includeonly“. -- ✓ ^Bergi 15:47, 15. Mär. 2010 (CET)

WikiTex-Erweiterung

(Übertragen von Verbesserungsvorschläge) Hier passt das wohl besser. Ich habe die Strukturformeln mal mit LaTeX ausprobiert, sie sehen als PNG wirklich gut aus. Musiknoten kann man auch automatisch im MIDI-Format abspielen lassen.

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 (Gaussianer | Beiträge) 12:08, 9. Mai 2010 (CEST)

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)

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

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

Pro --Tlustulimu 21:33, 11. Mai 2010 (CEST)

Pro --Christian Stroppel 02:42, 5. Sep. 2010 (CEST)

Bug 1792 --Der Umherirrende 22:28, 18. Jun. 2010 (CEST)

Die "Bug"-Meldung ist 5 Jahre alt! Meinst du da tut sich noch was, oder wo muss man da Druck machen? 89.247.171.253 16:38, 7. Jul. 2010 (CEST)

Keine Ahnung, wie man das beschleunigen könnte oder wo man das ganze vorbringen kann. Der Umherirrende 18:53, 7. Jul. 2010 (CEST)

Laut dem Bug gibt es Implementierungsprobleme. Die Extension wird demnach nicht gewartet, ist schlecht lokalisiert, der Code ist schlecht und es besteht die Möglichkeit eines DoS. Somit sei sie nicht für WMF-Wikis geeignet. Dauert also wohl eher etwas länger. -- ✓ ^Bergi 12:08, 5. Sep. 2010 (CEST)

Wenn WikiTeX nicht genutzt werden kann, sollte unbedingt eine andere Erweiterung für die Wikipedia gefunden werden, mit der einfache X-Y- und Balkendiagramme erstellt werden können, da diese in vielen Fällen (z.B. Bevölkerungsentwicklung eines Ortes) eine übersichtlichere Form der Darstellung als z.B. Tabellen sind. Gegenüber normalen Bildern hätte eine Direkterzeugung aus dem Quelltext unschlagbare Vorteile, allen voran

Schnelligkeit beim Erstellen und Abändern (bei Tippfehlern, Zahlendrehern...) bzw. Aktualisieren (jedes Jahr einen neuen Wert hinzufügen o.ä.)
Benutzerfreundlichkeit seitens des Autoren, der sich nicht mit SVG- oder Bildbearbeitungsprogrammen auszukennen braucht
einheitliches Design in allen Artikeln
enorme Ersparnis an Speicherplatz und „Datenmüll“, einfache Entfernbarkeit

Fazit: unbedingt an einer Lösung arbeiten! --W. Kronf *@* 14:07, 24. Feb. 2011 (CET)

Gerade für solche Diagramme gibt es Hilfe:Zeitleisten. --Schnark 11:07, 25. Feb. 2011 (CET)

Danke für den Hinweis. Wie der Name schon sagt, ist dieses Feature aber vor allem für Zeitleisten sinnvoll, während mir X-Y-Diagramme damit zu kompliziert für den schnellen Gebrauch erscheinen. --W. Kronf *@* 11:40, 25. Feb. 2011 (CET)

"Tabelle speichern als..."

Da man auch viele Statistiken in der Wikipedia findet und (zumindest ich) gern weiter mit Tools wie Tableau bearbeiten will, wäre es oft sehr nett, nicht den Umweg über Copy-Paste gehen zu müssen, sondern direkt einen Button für "Speichern als XML | CSV | ..." zu haben. 92.206.100.45 10:14, 22. Jun. 2010 (CEST)

So etwas müsste per JavaScript im Browser als Helferlein zu realisieren sein. --Fomafix 10:41, 22. Jun. 2010 (CEST)

Sortierbare Tabelle: Pfeile neu anordnen

Salute zusammen,

mich hat die unregelmäßige Anordnung der Sortierpfeile bei den Tabellen-Kopfzeilen immer gestört. Ich schlage daher vor, die Sortierpfeile stets rechtsbündig in der obersten Tabellenzelle auszurichten, was auf dieses Layout hinausläuft:

Was meint Ihr dazu? Grüßken --Robb 21:36, 5. Jul. 2010 (CEST)

Erforderliche Änderung in der wikibits.js (siehe Kommentare):

function ts_makeSortable(table) {

...

	// We have a first row: assume it's the header, and make its contents clickable links
	for (var i = 0; i < firstRow.cells.length; i++) {
		var cell = firstRow.cells[i];
		if ((" "+cell.className+" ").indexOf(" unsortable ") == -1) {
			cell.innerHTML = '<div class="float-left" style="margin:0;">' /* Robb-Edit (hinter cell.innerHTML): Reihenfolge angepaßt und Klassen und Styles eingefügt */
				+ cell.innerHTML + '</div>'
				+ '<a href="#" class="sortheader" '
				+ 'onclick="ts_resortTable(this);return false;">'
				+ '<span class="sortarrow">'
				+ '<img src="'
				+ ts_image_path
				+ ts_image_none
				+ '" alt="↓" class="float-right" align="middle" style="margin:0.5ex 0 0 1ex;"/></span></a>';
		}
	}
	if (ts_alternate_row_colors) {
		ts_alternate(table);
	}
}

...

function ts_resortTable(lnk) {
...
var arrowHTML;
	if (reverse) {
		arrowHTML = '<img src="'+ ts_image_path + ts_image_down + '" alt="↓" class="float-right" style="margin:0.5ex 0 0 1ex;"/>'; /* Robb-Edit: Klasse und Style ergänzt */
		newRows.reverse();
		span.setAttribute('sortdir','up');
	} else {
		arrowHTML = '<img src="'+ ts_image_path + ts_image_up + '" alt="↑" class="float-right" style="margin:0.5ex 0 0 1ex;"/>'; /* Robb-Edit: Klasse und Style ergänzt */
		span.setAttribute('sortdir','down');
	}

...

	// Delete any other arrows there may be showing
	var spans = getElementsByClassName(tr, "span", "sortarrow");
	for (var i = 0; i < spans.length; i++) {
		spans[i].innerHTML = '<img src="'+ ts_image_path + ts_image_none + '" alt="↓" class="float-right" style="margin:0.5ex 0 0 1ex;"/>'; /* Robb-Edit: Klasse und Style ergänzt */
	}

Knöpfe rechts wäre prinzipiell schön, aber es gibt folgendes Problem: Kopfzeilen sind normalerweise zentriert. Mit Knöpfen rechts ist entweder der Text nicht mehr exakt in der Mitte oder es muss links der gleiche freie Platz sein wie rechts, was die Zellen breiter macht. --Fomafix 08:31, 6. Jul. 2010 (CEST)

Hmm, okay. Ich hatte in der Tat die Überschrift mit der notwendigen div-Box eigens linksbündig platziert, weil auch das meinen Vorstellungen eher entspricht. Wenn Du die div-Box entfernst, ist die Überschrift aber in der Mitte zwischen linker Zellengrenze und Sortierknopf, und das sieht doch auch prima aus:

Grüße --Robb 09:14, 6. Jul. 2010 (CEST)

Bei mehrzeiligen Tabellenköpfen verrutscht die Mitte: --Fomafix 09:42, 6. Jul. 2010 (CEST)

Beispieltabelle 1
Zweizeiliger Tabellenkopf	Zweizeiliger Tabellenkopf
breiter Tabellenrumpf	breiter Tabellenrumpf
bisher	neu

Dat stimmt, ist aber ein generelles Problem und von dieser Fragestellung hier unabhängig. --Robb 10:52, 6. Jul. 2010 (CEST)

Nicht ganz. Bisher gehört der Knopf zum Text und der bleibt damit in der Mitte. Wenn der Knopf ein Fließobjekt ist, dann verschiebt er die Mitte. Wie oben erwähnt, würde es auch ohne Verschiebung gehen:

Beispieltabelle 2
Zweizeiliger Tabellenkopf	Zweizeiliger Tabellenkopf
breiter Tabellenrumpf	breiter Tabellenrumpf
bisher	neu

Allerdings benötigt der Tabellenkopf dann mehr Platz in der Breite, denn links ist immer ein freier Platz. --Fomafix 11:00, 6. Jul. 2010 (CEST)

Anpassung der Versionsgeschichte bei Importen?

In der deutschen Wikipedia ist es verbreitete Praxis, die Versionsgeschichte von Artikeln aus anderen Wikipedias, die übersetzt werden, mit Hilfe von Spezial:Importieren zu importieren. Man trachtet damit danach, die Lizenzbestimmungen möglichst perfekt einzuhalten (wobei sich andere Wikipedias z.B. mit einem Übersetzungsbaustein begnügen, aber das ist ein anderes Thema). In der importierten Versionsgeschichte werden die Benutzernamen dann jedoch den Usern mit diesem Namen hier auf de zugeordnet. Das führt durchaus häufig zu Fehlzuschreibungen, da viele Nicht-SUL-Accounts existieren und der Benutzer "Xyz" hier nicht mit dem Benutzer "Xyz" in der Ausgangswikipedia identisch sein muss. Damit wird also sowohl das Urheberrecht des Originalautors als auch das Droit de non-paternité des Wikipedianers, der hier fälschlich als Urheber ausgewiesen wird, verletzt (für ein harmloses Beispiel siehe unten in diesem Abschnitt). Ich könnte mir für dieses Problem eine technische Lösung vorstellen, daher die Anfrage hier... Wie wäre es, wenn man dafür sorgen würde, dass die User-Links in Versionsgeschichten nach Importen auf die jeweiligen Nutzer nicht hier, sondern im Ausgangswiki zeigen würden? Wäre das wohl möglich? Natürlich nur die Links bis zum Importzeitpunkt. Gestumblindi 02:12, 18. Jul. 2010 (CEST)

Aktualitätsprüfung

Wir sollten koordinierter die Aktualität von Artikel in bestimmten Themengebieten sicherstellen. Ich denke da an ein System ähnlich der gesichteten Versionen. Man definiert ein Prüfungsintervall, z.B. bei einem Artikel über eine Software 1 Jahr, bei lebenden Personen 2 Jahre, und hinterlegt das Datum der letzten Prüfung. Viele Artikel wie z.B. die über Lebewesen brauchen hingegen keine Aktualitätsprüfung. Ist der Zeitraum seit der letzten Prüfung abgelaufen, wird sowohl der Leser gewarnt, dass der Artikel möglicherweise veraltet ist, als auch über Wartungskategorien die Bearbeiter von den entsprechenden Portalen informiert. Im Gegensatz zu den gesichteten Versionen sollten die Prüfungen den Fachleuten obliegen. Aktualitätsprüfer müssen nur die Sachen prüfen, die sich geändert haben können, z.B.: Lebt die Person noch? Hat der Schauspieler einen neuen Film gedreht? Gibt es von der Software eine neue Version mit deutlich erweitertem Funktionsumfang oder wurde das Projekt eingestellt? Gibt es in dem Ort einen neuen Bürgermeister...

Eigentlich sollte das ganze System über die reine Umsetzung über eine Vorlage & Bots funktionieren, aber mit Softwareunterstützung sollte es deutlich komfortabler werden, da Prüfer dann einfach ein Häkchen setzen müssten ohne die Historie zu verstopfen. Ich denke das Thema wird mit zunehmendem Artikelbestand bei immer weniger Ursprungsautoren immer relevanter und sollte daher mittelfristig angegangen werden. Ich habe mir sagen lassen, dass professionelle System auch solche Funktionen zur regelmäßigen Wiedervorlage haben.

Hauptmotivation für mich ist, dass häufige Löschargument für Artikel über Softwareprojekte zu entkräften, wonach solche Artikel ja so schnell veralten und sich dann keiner mehr darum kümmert.... Da wäre es schön ein Aktualitätmanagement entgegensetzen zu können. --Kolossos 20:46, 19. Jul. 2010 (CEST)

Das könnte vielleicht was für den Toolserver sein. Je nach Kategorie (inklusive Unterkategorien) oder eingefügter Vorlage (z. B. eine Infobox) könnte ein entsprechender Zeitraum definiert werden. Für die Artikeledits sollte außerdem festgelegt werden, dass kleine und Botedits nicht mitgezählt werden. Vielleicht könnte man auch noch zurückgesetzte Edits ausklammern. --Morten Haan Wikipedia ist für Leser da 17:04, 20. Jul. 2010 (CEST)

Naja, ich will schon, dass bewußt die Aktualität geprüft wird und nicht nur z.B. eine Ergänzung im Abschnitt Trivia editiert wurde. Das Hinterlegen diese Prüfung sollte im Wiki erfolgen, ein einfaches Tool reicht daher wohl nicht. -Kolossos 14:25, 21. Jul. 2010 (CEST)

Gut, wie wäre es damit: Die Vorlage {{Aktualitätsprüfung}} wird in die jeweiligen Artikel eingetragen. Man gibt an, wie häufig der Artikel überprüft werden soll (z. B. ein Jahr: jahr=1), wann er zuletzt überprüft wurde (z. B. stand=2009-05-25), wer ihn überprüft hat (benutzer=~~~) und ggf. auf welcher Portalseite (z. B. eine Fach-QS) ein Bot den Artikel melden soll, wenn er überfällig ist. Es gibt des weiteren die Kategorien Kategorie:Wikipedia:Aktualitätsprüfung und Kategorie:Wikipedia:Aktualitätsprüfung/überfällig, in denen die Artikel gelistet sind. Ist das besser? --Morten Haan Wikipedia ist für Leser da 17:31, 21. Jul. 2010 (CEST)

Könnte man mal probieren. Mal sehen, was andere dazu meinen. --Kolossos 19:31, 21. Jul. 2010 (CEST)

Ich verstehe zwar nichts von Software, daher kann ich zur Leichtigkeit der Umsetzung nur wenig sagen, aber grundsätzlich klingt der Vorschlag sehr gut. Die einzige Frage, die für mich vorerst offen bleibt (abgesehen von Sachen wie den genauen Fristen, die man ja auch später noch festlegen kann), ist: Wer gilt als Experte? Wer darf denn entscheiden, ob ein Artikel nun aktuell (genug) ist? Administratoren? Sichter? Speziell nach Kategorien und Themenportalen gekennzeichnete Nutzer? Man könnte hier eventuell nach dem Vorbild der Vorraussetzungen für den Sichterstatus ähnliche Richtlinien bzw. Mindestbedingungen formulieren, um zu gewährleisten, dass möglichst nur Personen mit hinreichender Sachkenntnis über den Aktualisierungsbedarf entscheiden. Allerdings gibt es hier je nach Themenbereich auch das Problem, dass manche User nur in Teilbereichen Spezialisten sind: So weiß ich z.B. zwar Einiges über Tarja Turunen, als "Prüfer" für den Metal - Bereich wäre ich aber wahrscheinlich trotzdem nicht unbedingt geeignet, denn mit Slayer und Cannibal Corpse zum Beispiel kenne ich mich (imo) nicht gut genug aus. Ob man das dann einfach der Erfahrung der entsprechenden Benutzer überlässt, und darauf vertraut, dass jeder nur das als aktuell markiert, bei dem er / sie sich wirklich sicher ist - meinentwegen, würde insgesamt wahrscheinlich schon funktionieren, könnte halt aber teilweise auch schief gehen. --Firefly05 21:32, 20. Sep. 2010 (CEST)

Kurzfristiger Vorschlag mittels Vorlage: Überfällige Artikel sollen per Bot bei der jeweiligen Fach-QS (ersatzweise allgemeine QS) eingetragen werden. Wie beim Abarbeiten der QS-Bausteine wird auf das Viel-Augen-Prinzip vertraut.

Langfristiger Vorschlag mittels Softwareerweiterung: Wenn die Aktualisierung mit einem Flag ähnlich des Sichtungsflags gekenzeichnet wird kann man dafür auch eine neue Benutzergruppe einführen oder eine bestehende verwenden (z. B. Prüfer). Das oben genante Problem wurde bezüglich der Geprüften Versionen schon einmal diskutiert, mit dem Ergebnis, dass es daher bis auf weiteres keine Geprüften Versionen geben wird. --Morten Haan Wikipedia ist für Leser da 17:53, 22. Sep. 2010 (CEST)

`class="wikitable (sortable) collapsible"`

Wenn ich Artikel mit vielen langen Tabellen lese, wünsche ich mir manchmal eine class="wikitable (sortable) collapsible". Dann bräuchte man nicht mehr so viel zu scrollen, gerade wenn man weiter oben noch mal etwas nachlesen möchte, und könnte Tabellen, die einen womöglich nicht mal interessieren, einfach zuklappen. So könnte das Ganze aussehen:

Titel

Überschrift	Überschrift	Überschrift

Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel
Beispiel	Beispiel	Beispiel

Was haltet ihr von dem Vorschlag? -- Henrik 17:02, 27. Jul. 2010 (CEST)

Nicht viel. Mal abgesehen von Listen sollten Artikel keine "vielen langen Tabellen" enthalten. --Rosentod 17:16, 27. Jul. 2010 (CEST)

Ich halte diese Beurteilung für wenig differenziert. Sowohl Fließtext als auch Tabellen haben ihre Vor- und Nachteile. Im Fließtext können komplexe Zusammenhänge erklärt werden, dafür ist er wenig übersichtlich. Tabellen sind zwar übersichtlich, trennen aber zu sehr zwischen ihren Einträgen, als dass komplexe Zusammenhänge dargestellt werden könnten. Im Bezug auf Gesetzmäßigkeiten, Funktionsweisen, Vorgänge, abstrakte Begriffe und dergleichen hast du daher sicherlich recht. Man darf aber auch Titel nicht vergessen, die ein Ganzes darstellen, dessen Bestandteile wenig bis gar nicht miteinander interagieren, aber für sich genommen noch nicht relevant genug sind. Man denke nur an Sportwettkämpfe und die erfolgreichen Sportler/Teams in den einzelnen Disziplinen/Kategorien oder auch an Vergnügungsparks und ihre einzelnen Attraktionen. Artikel in diesen Bereichen beweisen recht eindrucksvoll, dass „viele lange Tabellen“ sehr wohl enzyklopisch sinnvoll sein können.

Eine class="wikitable (sortable) collapsible" sollte mit einigen Ergänzungen in Common.js und Common.css leicht umzusetzen sein, klappbare Tabellen sind im MediaWiki in einer Anleitung beschrieben. Ein Missbrauch wäre kaum dramatisch, im schlimmsten Fall wird der Leser einen „Einklappen“-Link sehen, den er nicht nutzen möchte. An softwarebedingten Barrieren festzuhalten, wie es bereits im Bezug auf den neuen Tabellenassistent gefordert wurde, halte ich hingegen für ein ungeeignet Mittel, um die Verwendung von Tabellen auf ein sinnvolles Maß zu beschränken. -- Henrik 19:23, 29. Jul. 2010 (CEST)

Wenn darüber nachgedacht wird, etwas aus dem Artikel auszublenden, weil der Artikel zu voll wird, der sollte das wirklich mal überdenken und dann zur Lösung kommen, das ein Löschen der Textpassage genauso gut ist. Der Hauptteil der Artikel sollte ohne zutuen direkt erfasst werden. Es gibt sicher viele Leute die mal durch einen Artikel durchscrollen und dann bei interessant aussehenen Bildern, etc hängen bleiben und dort lesen. Diesen Lesern wird die Möglichkeit genommen. Meiner Meinung nach wird die Navigationsleisten-Technik im Hauptteil von Artikel schon viel zu häufig genutzt. Zusätzlich gibt es Leser mit motorischen Einschränkungen, die auch Probleme bekommen können, den Ausklappen-Link zu treffen, etc., um an die Zusatzinformationen zu kommen. Daher halte ich nichts davon, Teile des Artikelhauptteils zu verstecken. Der Umherirrende 21:15, 29. Jul. 2010 (CEST)

Solche Tabellen müssten dann natürlich standardgemäß ausgeklappt angezeigt werden. So wird das Beispiel bei mir auch angezeigt. Vielleicht verstehen wir uns nicht richtig, weil das bei dir anders ist. Mir geht es nur darum, lange Tabellen einklappen zu können, damit man über weniger hinweg scrollen muss, wenn man immer wieder zwischen verschiedenen Stelle im Artikel hin- und her wechselt oder die Tabelle beim Lesen überspringen möchte. -- Henrik 13:00, 30. Jul. 2010 (CEST)

Sofern die gleiche Technik wie für Navigationsleisten verwendet wird (wie in deinem Beispiel), dann wird eine einzelne Tabelle ausgeklappt sein. Sofern aber eine weitere Tabelle oder Navigationsleiste hinzukommt, ist alles standardmäßig eingeklappt. Und ich denke es wird dann darauf hinauslaufen, das nicht nur eine Tabelle im Artikel gibt, sodass alles immer eingeklappt ist. Wenn es allerdings standardmäßig nicht eingeklappt ist, dann sehe ich kein Problem. Der Umherirrende 15:53, 30. Jul. 2010 (CEST)

Wie bereits erwähnt, gibt es im MediaWiki eine Anleitung. Dort findet sich der Quelltext, den man nur in Common.js und Common.css einzufügen braucht. Das ist so einfach, das ich es selbst tun könnte, wenn ich denn die Rechte dazu hätte. In der englischen Wikipedia hat man längst eine class="wikitable (sortable) collapsible", beschrieben unter en:Help:Collapsing. Es lässt sich übrigens sogar auswählen, ob die Tabelle standardgemäß ein- oder ausgeklappt sein soll, Default ist ausgeklappt. -- Henrik 17:14, 31. Jul. 2010 (CEST)

Hallo zusammen! Ich bin gerade dabei, die Vorlage:Infobox Tennisspieler zu überarbeiten. Im Portal:Tennis wurde gewünscht, die Infobox u.a. um Informationen zu Mixed- und Olympia-Titeln zu erweitern, falls diese existieren. Damit die Infobox jedoch nicht zu riesig wird, wäre es gut, wenn man dort Informationen ein- und ausklappen könnte. Da ich noch nicht so viel Erfahrung mit Vorlagenbearbeitung und insbesondere Tabellen habe, probiere ich jetzt schon seit einer ganzen Weile rum. Irgendwann bin ich dann auf diesen Link gestoßen, und habe mich schon gefreut, eine Lösung gefunden zu haben. Dann musste ich leider feststellen, dass dies nur in der englischen Wikipedia möglich ist, nicht jedoch in der deutschen. Scheinbar bin ich nicht der einzige, der sich dies wünschen würde. Wäre da nicht doch was machbar? Gruß, Tim-- VIPer7asdf 23:02, 9. Aug. 2010 (CEST)

Für klappbare Inhalte in Infoboxen müssen bisher die für Navigationsleiten geschaffenen Klassen missbraucht werden, wie ich es beispielhaft am Anfang dieses Abschnitts getan habe. Der Wunsch nach klappbaren Inhalten in Infoboxen ist stark, so stark, dass dieser Missbrauch längst auch praktisch stattfindet (Vorlage:Infobox Behindertensportler, Vorlage:Infobox Gewichtheber, Vorlage:Infobox Schwimmer, …). Insofern ist es vielmehr das Fehlen von klappbaren Tabellen, das die vom Umherirrenden beschriebenen Probleme schafft. Ich habe den Wunsch jetzt unter Hilfe Diskussion:MediaWiki-Namensraum gemeldet. -- Henrik 15:38, 10. Aug. 2010 (CEST)

Im Bereich Eisenbahnen ist in einem Artikel die Frage aufgetaucht, ob man nicht Zusatzinformationen, die nur einen Teil der Leserinnen und Leser interessiert, die aber trotzdem von einem gewissen allgemeinen Interesse und enzyklopädisch relevant sind, einklappbar darstellen könnte. Ich bin in WikiCommons auf ein Beispiel gestossen, siehe Commons:Category:Rolling stock, wo es eine einfache Klappbox (Template:Collapse) gibt, im Beispiel für "Rolling stock types in other languages". Ich würde es sehr begrüssen, wenn eine solche Möglichkeit auch in der deutschen Wikipedia geschaffen würde.-- Gürbetaler 23:19, 11. Aug. 2010 (CEST)

Bevor irgendein Admin damit anfängt, zusätzlich die vorgeschlagenen Quelltexte einfach zu übernehmen, sollte auf alle Fälle noch eine Diskussion zur Technik gestartet werden, die neue Skripte / CSS entwirft. Die Idee mit den verschiedenen Klassen (autocollapse, collapsed) ist gut, wurde aber für mich unbefriedigend umgesetzt. Zudem sollte man die Klassen evtl. auch auf Deutsch verfügbar machen, und vor allem sollte es natürlich nicht zwei parallele Skripte für Navis und Tabellen geben, die ja sowieso dasselbe machen.
meint -- ✓ ^Bergi 16:54, 12. Aug. 2010 (CEST)

Auf Deutsch verfügbare Klassen sind bisher unüblich und soweit ich weiß im Zuge der Internationalisierung unerwünscht. Wenn du damit anfangen möchtest, solltest du auch an die class="sortable" denken.

Wie die Skripts aussehen ist mir im Grunde ziemlich egal. Ich weiß nur, dass es in der en:Wikipedia trotz Kopieren und Einfügen wunderbar funktioniert. Gruß, Henrik 18:27, 12. Aug. 2010 (CEST)

Bevor jetzt gar nichts umgesetzt wird, wäre es doch sicherlich besser, die im MediaWiki vorgeschlagenen und in diversen Wikis bewährten Quelltexte zu übernehmen. Kümmert sich bitte jemand drum? -- Henrik 18:07, 12. Okt. 2010 (CEST)

Allerdings muß kein kombiniertes Javascript mehr entwickelt werden, welches gleichermaßen für ausklappbare Tabellen als auch DIVs taugt, denn so etwas gibt es längst. Bereits 2008 habe ich diese Funktionen in hsb:MediaWiki:Common.js eingebaut. Das Original stammte damals aus der russischen Wikipedia. Gruß --Tlustulimu 12:15, 15. Okt. 2010 (CEST)

Wie sollen die Quelltexte dann konkret aussehen? -- Henrik 13:18, 20. Okt. 2010 (CEST)

Es ginge also um folgendes:

// ============================================================
// BEGIN hasclass
//hasClass, from en.wp and ru.wp
var hasClass = (function (){
var reCache = {}
return function (element, className){
return (reCache[className] ? reCache[className] : (reCache[className] = new RegExp("(?:\\s|^)" + className + "(?:\\s|$)"))).test(element.className)
}
})()
 
 
function addLoadEvent(f) {addOnloadHook(f)} //for backwards compatibility
// END hasclass
// ============================================================

// ============================================================
// BEGIN Dynamic Navigation Bars
// NEEDS Enable multiple onload functions 
// nowa wersija po ruskej wikipediji
//Collapsible Tables and Divs, [[:ru:ВП:СБ]]
 
var autoCollapse = 0
var collapseCaption = 'Verstecken'
var expandCaption = 'Anzeigen'
 
function collapsibleTables(){
var Table, HRow, THs, Header, btn, a, tblIdx = 0, colTables = []
var allTables = document.getElementsByTagName('table')
for (var i=0; Table = allTables[i]; i++){
if (!hasClass(Table, 'collapsible')) continue
if (!(HRow = Table.rows[0])) continue
THs = HRow.getElementsByTagName('th')
if (THs.length == 0) continue
Header = THs[THs.length-1] //last TH, not 1st like in en.wp
Table.id = 'collapsibleTable' + tblIdx
btn = document.createElement('span')
btn.style.styleFloat = btn.style.cssFloat = 'right'
btn.style.fontWeight = 'normal'
a = document.createElement('a')
a.id = 'collapseButton' + tblIdx
a.href = 'javascript:collapseTable(' + tblIdx + ');'
a.appendChild(document.createTextNode(collapseCaption))
btn.appendChild(document.createTextNode('['))
btn.appendChild(a)
btn.appendChild(document.createTextNode(']'))
Header.insertBefore(btn, Header.childNodes[0])
colTables[tblIdx++] = Table
}
for (var i=0; i < tblIdx; i++)
if ((tblIdx > autoCollapse && hasClass(colTables[i], 'autocollapse')) || hasClass(colTables[i], 'collapsed'))
collapseTable(i)
}
 
function collapseTable (idx){
var Table = document.getElementById('collapsibleTable' + idx)
var btn = document.getElementById('collapseButton' + idx)
if (!Table || !btn) return false
var Rows = Table.rows
var isShown = (btn.firstChild.data == collapseCaption)
btn.firstChild.data = isShown ?  expandCaption : collapseCaption
var disp = isShown ? 'none' : Rows[0].style.display
for (var i=1; i < Rows.length; i++)
Rows[i].style.display = disp
}
 
var NavigationBarHide = '[' + collapseCaption + ']'
var NavigationBarShow = '[' + expandCaption + ']'
var NavigationBarShowDefault = autoCollapse
 
function collapsibleDivs(){
var navIdx = 0, colNavs = [], i, NavFrame
var divs = document.getElementById('content').getElementsByTagName('div')
for (i=0; NavFrame = divs[i]; i++) {
if (!hasClass(NavFrame, 'NavFrame')) continue
NavFrame.id = 'NavFrame' + navIdx
var a = document.createElement('a')
a.className = 'NavToggle'
a.id = 'NavToggle' + navIdx
a.href = 'javascript:collapseDiv(' + navIdx + ');'
a.appendChild(document.createTextNode(NavigationBarHide))
// Find the NavHead and attach the toggle link (Must be this complicated because Moz's firstChild handling is borked)
for (var j=0; j < NavFrame.childNodes.length; j++)
if (hasClass(NavFrame.childNodes[j], 'NavHead'))
NavFrame.childNodes[j].appendChild(a)
colNavs[navIdx++] = NavFrame
}
for (i=0; i < navIdx; i++)
if ((navIdx > NavigationBarShowDefault && !hasClass(colNavs[i], 'expanded')) || hasClass(colNavs[i], 'collapsed'))
collapseDiv(i)
}
 
function collapseDiv(idx) {
var div = document.getElementById('NavFrame' + idx)
var btn = document.getElementById('NavToggle' + idx)
if (!div || !btn) return false
var isShown = (btn.firstChild.data == NavigationBarHide)
btn.firstChild.data = isShown ? NavigationBarShow : NavigationBarHide
var disp = isShown ? 'none' : 'block'
for (var child = div.firstChild;  child != null;  child = child.nextSibling)
if (hasClass(child, 'NavPic') || hasClass(child, 'NavContent'))
child.style.display = disp
}
 
addOnloadHook(collapsibleDivs);
addOnloadHook(collapsibleTables);
 
// END Dynamic Navigation Bars
// ============================================================

Ich habe denn schon mal zwei Variablen angepaßt. Eine funktionierende Variante befindet sich außerdem in meinem Wiki [3], und ist dort in der Dokumentation der Vorlagen [4] und [5] gut zu sehen. Gruß --Tlustulimu 17:50, 20. Okt. 2010 (CEST)

Vielen Dank! Ich würde allerdings die Bezeichnungen einklappen und ausklappen favorisieren. Müsste der Wert für var autoCollapse nicht eigentlich 2 sein?

Ich kann leider nicht selbst beurteilen, ob das bei deinem Vorschlag der Fall ist, aber Tabellen mit class="collapsible" müssen in jedem Fall standardgemäß ausgeklappt sein. Gruß, Henrik 15:38, 22. Okt. 2010 (CEST)

Wir brauchen uns keine Mühen über eine eigene Programmierung mehr machen, denn nach Wikipedia:Projektneuheiten#Vorschau auf Version 1.18 wird es dieses Jahr noch eine Klappfunktion für Tabellen geben. --18:12, 7. Jan. 2011 (CET)

Mein Skript Benutzer Diskussion:TMg/showInfoboxToggle.js erkennt class="collapsible". Wer möchte, kann das Skript mitbenutzen und erhält dann überall dort, wo dieser CSS-Klassenname vorkommt, Links zum Ein- und Ausklappen von Tabellen. Das klappt an erstaunlich vielen Stellen. Bis die nächste MediaWiki-Version so weit ist, hilft das vielleicht etwas. --TMg 01:01, 16. Mär. 2011 (CET)

Spezial:Verwaiste Seiten

Die Beschreibung dieser Spezialseite sagt: "Diese verwaisten Seiten sind [...] nicht erwünscht, [...] weil sie über die normale Navigation durch die Wikipedia nie aufgerufen werden können." Nun finden sich auf dieser Seite fast ausschließlich Begriffsklärungsseiten sowie ggf. Falschschreibungen und Weiterleitungen (auf die ja im Regelfall explizit nicht verlinkt werden soll), so dass sie als Werkzeug für die Auffindung echter Waisenkinder nichts taugt. Daher sollte es mMn künfitg Folgendes geben:

Spezial:Verwaiste Seiten, die wie bisher funktioniert,
Spezial:Echte Waisen, auf der alle Waisen angezeigt werden, die NICHT in den Kategorien Kategorie:Begriffsklärung, Kategorie:Wikipedia:Falschschreibung enthalten sind und weder #Redirect noch #Weiterleitung enthalten; sowie
Spezial:Falsche Waisen, die alle weiteren Waisen auflistet.

--Carbenium 16:06, 29. Jul. 2010 (CEST)

Siehe Wikipedia:WikiProjekt Verwaiste Seiten, welches Botunterstützung beim finden hat. Der Bot berücksichtigt deine Vorschläge teilweise. Der Umherirrende 21:10, 29. Jul. 2010 (CEST)

URL-Parameter zum Verstecken von reference-Objekten

Soll heißen, "hiderefs=1" (oder so) würde alle Fußnoten ausblenden. Imo eine Investition in die Zukunft.--141.84.69.20 19:27, 29. Jul. 2010 (CEST)

Wo und in welchem Zusammenhang soll das nützlich sein? --Carbenium 20:39, 29. Jul. 2010 (CEST)

"Lesefassung" eines Artikels.--141.84.69.20 22:12, 29. Jul. 2010 (CEST)

Notizzettel

Dieses Feature könnte imho den Nutzer für Leser bereichern und die Arbeit der Pfleger von WP-Inhalten erleichtern. Dabei handelt es sich um einen Notizzettel, der bei jedem Eintrag zur Verfügung steht. Dieser Notizzettel ist funktional sehr begrenzt:

max 200 Zeichen pro Eintrag (ggf. max. 2 Einträge pro Nutzer/Eintrag pro Tag, um Spamming zu verhindern)
jeder darf einen Eintrag auf dem Notizzettel anlegen, der jüngste Eintrag steht oben
jeder darf einen Eintrag auf dem Notizzettel ohne Angaben von Gründen löschen
jeder darf einem Eintrag einstufen: als „fragwürdig/irrelevant“, „sehr wichtig/in Eintrag möglichst bald berücksichtigen“ und „guter Hinweis“ (neutral = Eintrag sollte vorerst bleiben); der Artikelverantwortliche erhält eine vierte Stufe „danke, ist in Arbeit“ (nach dem Einarbeiten wird der Eintrag gelöscht)
Einträge auf dem Notizzettel werden nicht/niemals debattiert/diskutiert (wer eine Diskussion darüber beginnt, wird auf eine Infoseite verwiesen)
jede Löschung wird von der Technik erst nach frühestens 14, spätestens 30 Tagen ausgeführt
nur Administratoren dürfen Löschungen sofort auslösen, wenn der Eintrag eine wirklich (!!) unpassende Bemerkung (z.B. Beleidigung, keinerlei Bezug zum WP-Eintrag) oder einen unpassenden Link (der nicht den WP-Kriterien entspricht: kostenpflichtig, eindeutiger Linkspam, keinerlei Bezug zum Thema) enthält; im Zweifelsfall lieber auf „normales Löschen“ mit der Verzögerung zurückgreifen
man darf natürlich seinen eigenen Beitrag löschen (wenn man jeweils eingeloggt war), dann beträgt die Verzögerung nur 24 Stunden
Löschungen können nicht rückgängig gemacht werden; (Idee: zu jedem Notizzettel besteht ein Ein-Jahres-Archiv, wo sämtliche Einträge mit Datum des Eintrags und Datum des Löschens aufgelistet werden)

Diskussionen in der realen Welt haben gezeigt, dass bei einigen WP-Lesern der Wunsch besteht, auf einen Fehler oder eine Ergänzung hinzuweisen, doch dazu müssten sie sich mit der technischen Bedienung auseinandersetzen. Der Notizzettel kann für diese Leute sehr hilfreich sein, da er eben nur eine einzige Eingabe ohne Formatierungen etc. verlangt: max. 200 Zeichen Text. Somit muss man nicht im Artikel „herumpfuschen“, sondern kann denen, die das gut beherrschen, inhaltliche Unterstützung bieten. Das senkt auch die Hemmschwelle, nicht nur passiv zu lesen, sondern mit einem kurzen Hinweis unaufwändig zur WP beizutragen. „WP-intern“ kann der Notizzettel als Informationsgeber für alle fungieren, die sich mit dem Thema beschäftigen oder den WP-Eintrag verbessern wollen. Wer einen Text bearbeitet, kann dort eine Info hinterlegen, was er plant (und jetzt gerade nicht schafft), kann dort auf interessante Dinge hingewiesen werden, die ihm und auch dem Google-Index entgangen sind.

Theoretisch könnte das auch über die Diskussionsseite gehandhabt werden, doch diese sind dafür wenig geeignet. Für Leser, die mehr Informationen zu einem Thema suchen, können auf dem Notizzettel hinterlegte Links und Tipps, Fragen, Hinweise sinnvolle Ergänzung bieten; die Diskussionen nach solchen abzusuchen, ist mühsam und wenig ergiebig. Außerdem soll der Notizzettel -- wie der Name verdeutlicht -- eine Art Stichpunktliste sein, während die Diskussion ein Gedanken- oder Argumenteaustausch ist. Beide Arten sind zu verschieden, als dass sie mit dem selben bestehenden Werkzeug abgebildet werden könnten.

Die Begrenzung auf eine Zeile (max. 200 Zeichen) sowie die einfache Löschung würde die Natur eines Notizzettels unterstützen. Insbesondere bei Einträgen, für die sich mehrere Experten berufen fühlen, oder die an einem Mangel von Bearbeitern leiden, kann dieser Notizzettel ein wirkungsvolles Hilfsmittel sein. Dort können Links und Gedanken für eine späteren Be- oder Überarbeitung gesammelt werden. Links, die einen Eintrag im WP-Eintrag nicht verdient haben, könnten monatelang dort stehen, bis beispielsweise die dort aufgeführten Informationen eingearbeitet wurden. So muss eine Information nicht aus Angst vor Vergessen flüchtig eingearbeitet werden, und WP-Leser können auch von solchen Links oder Hinweisen profitieren.

Durch den reinen Hinweischarakter (in der Länge von nicht mal zwei SMS), durch das einfache Löschen und das Diskussionsverbot ist der Bearbeitungsaufwand gering. Die verzögerte Löschung stellt sicher, dass jeder Eintrag dennoch für eine gewisse Zeit wahrgenommen werden kann (was viele potenzielle Diskussionen verhindert). Es wäre sicher vielen Wikipedianern lieber, wenn Übereifrige oder Voreilige nicht einfach direkt im WP-Eintrag Dinge an falscher Stelle oder in unpassendem Stil oder in ungeeigneter Formatierung ergänzen, sondern lieber einen Hinweis oder Linktipp oder eine Frage auf dem Notizzettel hinterlassen, sodass beim Einpflegen in den WP-Eintrag die Qualität gewahrt bleibt. Damit kann die Grenze zwischen passiven WP-Lesern und aktiven WP-Mitgliedern durchlässiger werden.

Der entstehenden Pflegeaufwand ist gering: Löschtaste bei einem Eintrag betätigen oder einer Information nachgehen - was ja grundsätzlich sinnvoll ist. Der Nutzen ist deutlich höher: zusätzliche Informationen, kurze, überschaubare Informationsliste, einfachere Mitarbeit WP-Fremder. Bei der Abschätzung, ob man für die Einrichtung eines solchen Features ist, bitte nicht pauschal alles Neue ablehnen, sondern kurz abwägen, ob die geschilderten Vorteile tatsächlich eintreten können. -- Zanjero 21:37, 29. Jul. 2010 (CEST)

Ich befürchte, deine Darstellungen sind zu ausführlich, als dass sich viele die Zeit nehmen, sie durchzulesen ;-)

Pro Was mich betrifft, hat mich insbesondere dein Argument bezüglich der Hemmschwelle, auf einen Fehler oder eine nötige Ergänzung hinzuweisen, überzeugt. -- Henrik 16:05, 10. Aug. 2010 (CEST)

Pro geringe Hemmschwelle. Ein Bewertungsbutton "Der Artikel war hilfreich 1-7" könnte die Qualitätssicherung ebenso verbesern.--Christian Stroppel 03:20, 5. Sep. 2010 (CEST)

Kontra Ersteinmal eine schöne Idee. :)

Ob die Hemmschwelle aber tatsächlich sinken würde ist fraglich. Andererseits müsste man diese Notizzettel irgendwie ins Interface integrieren, ohne den Leser zu stören. JavaScripte werden heute - rein empirisch belegt (und gern widerlegbar) - oft einfach nur geblockt. Würde man einen weiteren Reiter integrieren, könnte man auch gleich zumuten, die Diskussionseite für Vorschläge zu benutzen. Ein anderer Punkt wären z.B. noch Netbooknutzer, Besucher von Handybrowsern usw. Diese hätten durch ein weiteres Feld o.ä. noch ein Platzdefizit mehr.

Kurzum: Ich fürchte, dass Aufwand-Nutzen/Schaden-Verhältnis ist unpassend. MfG --Espero soph 18:37, 5. Jan. 2011 (CET)

Unter englischen Wikipedia-Artikeln findet man immer häufiger ein „page rating“. Wieso wird nicht einfach das Article feedback auch in der de:Wikipedia eingeführt? -- Henrik 18:25, 22. Jan. 2011 (CET)

Der Notizzettel könnte evtl. in die Diskussionsseite integriert sein, als Block oberhalb der eigentlichen Diskussion und diese damit deutlich entlasten. Ein Bewertungsbutton hilft nicht wirklich weiter (ist eher eine Möglichkeit zur Qualitätssteigerung im Allgemeinen). In der Realität so passiert: Ein Fachmann seines Gebiets beklagt einen sachlichen Fehler in einem WP-Eintrag. Dann korrigier ihn doch einfach, sag ich. Wie denn, lautet die Antwort, das ist viel zu kompliziert. Genau für solche Leute ist der Notizzettel gedacht – und alle anderen profitieren ebenfalls davon. Wenn man das Feature im Interface haben will (und ich würde es als unverzichtbar ansehen), dann wird man auch einen Platz dafür finden. Es gibt den WP-Artikel, um den sich alles dreht. Es gibt den Notizzettel für kurze Anmerkungen, Hinweise, quasi auch als Tool zum Projektmanagen (wenn man den WP-Artikel als Projekt ansieht). Und die Diskussion, um tatsächlich zu diskutieren (Rede und Gegenrede, Argumenteaustausch). Zanjero 02:25, 16. Apr. 2011 (CEST)

Schnittmenge mehrer Kategorien bilden (zur Eingrenzung des Ergebnisses)

Gibt es die Möglichkeit, verschiedene Kategorien miteinander zu kombinieren, um den Kreis der Ergebnisse (Schnittmenge) immer stärker einzuschränken?

Bsp.: Suche einen deutschen Philosophen aus dem 20. Jahrhundert. Da ich den Namen nicht kenne, wäre die Suche über die Kombination der Kategorien "Philosoph", "Deutscher", "Mann", "20. Jahrhundert" sehr hilfreich, da es über 1.000 Beiträge der Kategorie "Philosophen des 20. Jahrhunderts" gibt.

Eine solche Funktion konnte ich nicht finden, halte sie aber zur Recherche für äußerst hilfreich. (nicht signierter Beitrag von 130.75.183.170 (Diskussion) 21:02, 12. Sep. 2010 (CEST))

→ Wikipedia:CatScan. XenonX3 - (☎:±) 21:03, 12. Sep. 2010 (CEST)

Ein "Bearbeitungsspeicher" wäre gut

Hallo,

ich habe die Erfahrung gemacht, dass die Bearbeitungen von Artikeln einiges an Zeit benötigen und gerade bei der Bearbeitung/Überarbeitung/neu Verfassung von Abschnitten oder ganzen Artikeln ist es in einem "Arbeitsgang" fast unmöglich. Das Ergebnis ist entweder eine "Flickschusterei" oder aber man überlegt es sich noch drei mal bevor man sich da ran setzt. Denn wann hat man schon am Stück genug Zeit um größere Artikel zu überarbeiten?

Mein Vorschlag wäre daher ein "Bearbeitungsspeicher" in dem man die bisherigen Ergebnisse ablegt und dann weiter arbeitet. Dieser muss ja nicht übermäßig groß sein. Wenn darin drei oder fünf Artikel Platz finden würde es denke ich reichen. Dazu eine noch eine gesonderte Anzeige (bei endgültiger Speicherung) von allen Veränderungen die während der der Bearbeitungszeit gemacht wurden, um auch die Aktualisierungen Anderer zu Berücksichtigen. Dieser Speicher kann auf beispielsweise 30 Tage begrenzt sein. Wird in dieser Zeit nicht daran gearbeitet, wird die Bearbeitung aus dem Speicher entfernt und nimmt keinen weiteren Speicherplatz auf den Servern ein. Dies wäre denke ich eine sehr sinnvolle Erweiterung von Wikipedia. --Shinji311 13:32, 24. Sep. 2010 (CEST)

Was du vorschlägst, ist bereits in Entwicklung: mw:Extension:Drafts. Ausprobieren kannst du das Ganze bereits im Testwiki:, wann es so gut funktioniert, dass es auch hier eingesetzt wird, kann man aber noch nicht so genau wissen. --Schnark 09:12, 25. Sep. 2010 (CEST)

oh, na das klingt ja sehr gut. Und vielen Dank für die Antwort --Shinji311 11:48, 25. Sep. 2010 (CEST)

Alternativ würde ich vorschlagen du nutzt deinen Benutzernamensraum und legst dir dort Unterseiten (getrennt durch "/") an. Viele machen das schon, daher ist der Druck zur Einführung deines Vorschlages aus meiner Sicht sehr begrenzt. Man sollte diese Möglichkeit vielleicht auch für Neulinge mehr bekannt machen, anstatt immer gleich halbfertige Artikel mit dem Kommentar "kein Artikel" schnellzulöschen. --Kolossos 16:30, 25. Sep. 2010 (CEST)

Wie den Benutzernamensraum nutzen? Was ist das überhaupt? und wie geht das? --Shinji311 18:42, 25. Sep. 2010 (CEST)

In Hilfe:Glossar steht bei Benutzernamensraum, BNR ein Link auf Hilfe:Benutzernamensraum. Da sollte alles erklärt sein. In diesem Fall ist besonders der Abschnitt Unterseiten interessant.--Diwas 19:31, 25. Sep. 2010 (CEST)

Solche Unterseiten sind besonders dann gut verwendbar, wenn du einen Artikel oder Abschnitt komplett neu schreibst. Man kann aber auch den Quelltext eines Artikels oder einen Abschnitt den man überarbeiten möchte per Copy&Paste in eine solche Unterseite kopieren. Dann sollte man aber die Vorlage:Temporärkopie einfügen.--Diwas 19:50, 25. Sep. 2010 (CEST)

Fehler melden

Das Wiki-Prinzip lebt davon, dass Fehler bei vielen Lesern schnell auffallen. Wenn man dabei auch IPs mit einbinden möchte, gilt es, die Hemmschwelle, sich zu beteiligen, abzubauen. In einem Bereich ist dies bereits gelungen:

Wenn ein unerfahrener Leser einen Fehler entdeckt, den er selbst korrigieren kann, besitzen viele den Mut, auf bearbeiten zu klicken. Sie suchen die Stelle im Quelltext, ergänzen beispielsweise ein Komma und klicken dann auf speichern.

Wenn der unerfahrene Leser hingegen einen Fehler entdeckt oder vermutet, von dem er nicht weiß, wie er ihn korrigieren soll, finden nur die wenigsten den Weg auf die Diskussionsseite. Sie würden vielleicht gerne auf den Missstand hinweisen, wissen aber nicht wie oder werden von den Richtlinien für Diskussionsseiten (für deren Lektüre man sich auch noch die Zeit nehmen soll!) oder der Wiki-Syntax abgeschreckt. An dieser Stelle wird Potenzial verschenkt.

Ich schlage deshalb vor, im Artikelnamensraum in Analogie zum „bearbeiten“-Link einen „Fehler melden“-Link als Reiter und hinter allen Überschriften einzuführen. Wer darauf klickt, erhält ein einfaches Eingabeformular unter der Überschrift Fehler [im Abschnitt X] melden. In einer Betreffzeile kann die Art des Fehlers, in einem Textfeld eine Beschreibung angegeben werden. Mit einem Klick auf senden fügt die Software der Diskussionsseite einen neuen Abschnitt unter dem angegebenen Betreff hinzu, gegebenenfalls mit einem vorangestellten Verweis auf den Abschnitt. Außerdem wird automatisch die Signatur und ein Bearbeitungskommentar ergänzt. Die IP erhält ein Dankeschön und den Link auf den Abschnitt, unter dem sie die Reaktionen verfolgen kann.

Bei angemeldeten Autoren könnte man auf diese Funktion ganz verzichten oder sie zumindest durch das normale Hinzufügen eines Abschnitts auf die Diskussionsseite ersetzen. -- Henrik 14:15, 20. Okt. 2010 (CEST)

Gute Idee. Kann man dies durch Erweiterung einer MediaWiki-Seite ergänzen, oder muss man die Software dazu anpassen? --Morten Haan Wikipedia ist für Leser da 17:38, 23. Okt. 2010 (CEST)

Gute Idee. Dies wäre auch eine Funktionalität für den von mir oben vorgeschlagenen Notizzettel. Ziel ist ja das gleiche: Neulingen/Wikipedia-Unerfahrenen eine einfache Mitteilungsfunktion zu geben, um die Hemmschwelle zu senken, eine Information, ein Feedback, einen Hinweis dazulassen. Zanjero 02:32, 25. Dez. 2010 (CET)

Gruppierte Einzelnachweise kompakt und doch gut nutzbar darstellen

Beispielsweise so

Günther Drosdowski (Bearbeitung): Duden – Das Herkunftswörterbuch – Etymologie der deutschen Sprache, Bibliographisches Institut & F.A. Brockhaus AG, Mannheim 1989, ISBN 3-411-20907-0 • 1. ↑ S. 666 • 2. ↑ S. 469 • 3. ↑ S. 748 • 4. ↑ S. 203.
Manfred von Lewinski: Ausharren oder gehen? – Für und wider die Freiheit zum Tode. Olzog, München 2008, ISBN 985-37-8928254-6 • 1. ↑ S. 161 ff. • 2. ↑ S. 117 ff.

anstatt so wie bisher

Günther Drosdowski (Bearbeitung): Duden – Das Herkunftswörterbuch – Etymologie der deutschen Sprache, Bibliographisches Institut & F.A. Brockhaus AG, Mannheim 1989, ISBN 3-411-20907-0
1. ↑ S. 666
2. ↑ S. 469
3. ↑ S. 748
4. ↑ S. 203.
Manfred von Lewinski: Ausharren oder gehen? – Für und wider die Freiheit zum Tode. Olzog, München 2008, ISBN 985-37-8928254-6
1. ↑ S. 161 ff.
2. ↑ S. 117 ff.

Vorteile: Man kann direkt zur Textstelle zurückspringen, wenn man sich die Nummer gemerkt hat. Seitenzahlen bleiben erhalten, aber die Liste wird nicht so elend lang (zumindest bei breitem Fenster).--Diwas 03:34, 10. Nov. 2010 (CET)

Also als CSS-Gadget? Oder meinst du in die Extension implementiert, â la <references group="Autor1" display="inline" />? -- ✓ ^Bergi 20:34, 10. Nov. 2010 (CET)

Besser wäre es in die Extension, denn Ziele sind: 1. Niemand soll sich veranlasst sehen, Seitenzahlen zu unterschlagen, um die Liste der Einzelnachweise nicht endlos erscheinen zu lassen. 2. Mehrfachreferenzierungen sollten verzichtbar gemacht werden, damit man auch ohne Browser-zurück, durch klicken auf den Pfeil genau zur gerade gelesenen Textstelle zurückgeleitet wird. Es geht also darum Vorbehalte gegen sehr viele einzelne Einzelnachweise auf teilweise dasselbe Werk auszuräumen und so genaue Referenzierung zu erleichtern. Als Gadget, sollte das dann standardmäßig für alle auch unangemeldete aktiviert sein, geht das? --Diwas 14:25, 15. Nov. 2010 (CET)

Vielleicht sollten Extension und Gadget kombiniert werden: Wenn <references /> das Attribut class="inline" zulassen würde, dann könnte mit ol.references.inline > li { display: inline } das gewünschte realisiert werden. --Fomafix 14:36, 15. Nov. 2010 (CET)

Sollen dann aber allgemein class-, style- und andere Attribute erlaubt sein? Halte ich für eher ungut (auch wenn jetzt schon <div class="hintergrundfarbe"><references /></div> möglich ist), natürlich würde aber wohl ein keyword im extension-tag einfach eine Klasse neben references setzen. -- ✓ ^Bergi 15:52, 15. Nov. 2010 (CET)

nein, keine stylerei: das layout sollte der technologie vorbehalten sein, allein schon um der einheitlichkeit willen: je freier die gestaltung wird, desto weniger intutiv wird der zugang (für OMA), hier ist corporate design gefragt, die referenziererei ist schon so komplex genug

das layout mit dem · gefällt mir aber extrem gut, höchst übersichtlich (und erspart das ganze column-getrixe bei den refs) --W!B: 20:56, 12. Dez. 2010 (CET)

Benutzersperren auf einzelne Artikel oder Namensräume begrenzen

Ich möchte eine differenziertere Gestaltung der Sperrfunktionen anregen. Zum einen würde ich die Möglichkeit wünschenswert finden, Sperren von Benutzern bzw. IP-Adressen/ Adressbereichen auf einzelne Seiten, Kategorien(bäume) oder Namensräume begrenzen zu können. Dies könnte entweder dadurch geschehen, dass dies auf den Benutzernamen bzw. die IP-Adresse bezogen als Einschluss- ("darf nur noch folgende Seiten/ Artikel aus folgenden Kategorien/ Namensräume bearbeiten") oder Ausschlussliste ("darf folgende Seiten/ Artikel aus folgenden Kategorien/ Namensräume nicht bearbeiten") festgelegt werden kann. Ein entsprechender Hinweis beim Bearbeitungsversuch, z.B. "Du darfst derzeit nur folgende Seiten bearbeiten", ergänzt um einen spezifischen Kommentar mit Begründung, könnte beispielsweise einen Benutzer gezielt auf eine Diskussionsseite führen, um inhaltliche Differenzen auszudiskutieren. Alternativ könnte eine solche differenzierte Sperre auch seitenbezogen als Ausschlussliste festgelegt werden ("darf von folgenden Benutzern/ IP-Adressen nicht bearbeitet werden"). Ich denke, dass wir mit solch differenzierten Sperrmöglichkeiten besser auf Konflikte reagieren könnten, indem die meisten Sperren auf die betroffenen Kombinationen Benutzer <-> Seiten beschränkt sein würden. Andererseits könnten wir solche Sperren gegebenenfalls auch längerfristig oder dauerhaft bestehen lassen, anders als viele Benutzer- oder Seitensperren nach dem derzeitigen "Ganz-oder-Gar-nicht-Prinzip", da vor allem bei kompletten Seitensperren immer auch unbeteiligte Benutzer von einer Bearbeitung ausgeschlossen werden. Wünschenswert für eine solche differenzierte Sperrmöglichkeit wäre außerdem eine entsprechende Wildcard-Funktionalität.

Reale und wiederholt auftretende Beispiele: Ein Benutzer, der nur in einem Artikel einen Editwar führt und ansonsten konstruktiv mitarbeitet, müsste nicht mehr komplett gesperrt werden. Eine Benutzerdiskussionsseite, die wiederholt aus einer bestimmten IP-Range vandalisiert wird, könnte dauerhaft nur für diese IP-Range gesperrt werden. Benutzernamen, die einen bestimmten Namensbestandteil enthalten, könnte von der Auskunftsseite ferngehalten werden. Ein Neubenutzer, bei dem in seinen ersten Edits guter Wille erkennbar ist, würde erstmal mit einem entsprechenden Hinweis auf die Spielwiese, aufs Mentorenprogramm und auf seine Benutzerdiskussionsseite geleitet werden. Und so weiter. Als Nachteil sehe ich momentan nur das unbestimmte Gefühl, dass dies der "Admin-Willkür" noch weiter Tür und Tor öffnen würde. Dem ist entgegenzuhalten, dass eine solche Lösung die Auswirkungen von "Admin-Willkür" zumindestens deutlich einschränken würde. --Uwe 10:29, 15. Nov. 2010 (CET)

Eine sehr gute Idee! XenonX3 - (☎:±) 10:33, 15. Nov. 2010 (CET)

+1. Angesprochen wurde das bereits mehrfach, bisher ohne technische Umsetzung (gab’ aber auch einen guten Einwand dagegen, leider vergessen, welcher). Irgendwo in der enWP meinte ich aufgeschnappt zu haben, dass das dort bereits geht. --Hæggis 21:27, 15. Nov. 2010 (CET)

P.S.: Der Einwand war, dass Benutzer – je länger, desto stärker – aus inhaltlichen Gründen (unliebsamer Standpunkt) von einer Seite ferngehalten werden können und z.B. KPA eher als Vorwand dient. Das halte ich zwar durch präzise ^ durchdachte Anwendungsregelungen und tendenziell kurze Seiten- bzw. namensraumspez. Sperren für minimierbar, trotzdem sollte jede Richtlinie & (sperr)eingreifende Aktion genauestens auf damit machbaren Missbrauch überprüft werden. --Hæggis 21:47, 15. Nov. 2010 (CET)

Eine Benutzersperrung für einzelne Artikel ist im Prinzip bereits über den Missbrauchsfilter möglich. --Schnark 09:17, 16. Nov. 2010 (CET)

Wurde hier sogar (kurz) diskutiert. Können die Filter auch so eingestellt werden, dass sie autoamtisch ablaufen? --Hæggis 20:02, 22. Nov. 2010 (CET)

Beobachtungsliste: Automatisches Austragen + Botedits namensraumspezifisch ausblenden

Zum Ersten: Gemeint ist eine Hilfe für die Eingangskontrolle, die ein effektives Vorgehen gegen ausdauernden Vandalismus bietet. Unter Spezial:Einstellungen → Beo gibt es „Selbst geänderte Seiten automatisch beobachten“ (4. von unten). Vorgesehen ist eine abschaltbare Funktion, die während der EK alle selbst bearbeiteten/revertierten Seiten auf die Beo nimmt, sie aber – sofern während der aktiven Funktion in die Beo übernommen – nach x Tagen/Wochen automatisch wieder austrägt. Somit hat man die vandalisierte Seite noch eine Weile auf dem Schirm, überlastet aber langfristig seine Beo nicht (bzw. muss alle paar Sonnenumdrehungen wieder komplett aufräumen).
Auch möglich: Eine Tastenkombination, die Seiten auf der Beo z.B. mit Strg + linker Mausklick automatisch wieder austrägt, ohne Seitenaufruf und Stern-Anklicken.

Zum Zweiten: Unter Spezial:Einstellungen → Beo gibt es „Bearbeitungen durch Bots in der Beobachtungsliste ausblenden“ (3. von oben). Wenn auf einer Diskseite archiviert wird, wäre das nicht auf der Beo zu sehen, im ANR aber schon, was die Beo ingesamt übersichtlicher machen würde.
Auch möglich: (Bot-)benutzerspezifisches Ausblenden, sodass ein Singaturnachtrag erscheint, Archiv- und SpBot aber nicht. --Hæggis 21:41, 15. Nov. 2010 (CET)

Zu deinem ersten Wunsch gibt es bereits seit einer halben Ewigkeit einen Feature-Request bei Bugzilla: bugzilla:6964.

Auf en findest du einige Benutzerskripte, die du auch hier verwenden kannst, unter anderem zum direkten Austragen von Seiten auf der Beobachtungsliste. --Schnark 09:29, 16. Nov. 2010 (CET)

Vielen Dank, ich schau’s mir mal an. --Hæggis 20:02, 22. Nov. 2010 (CET)

Darstellung von Kategorien in den Artikeln

Wir haben hier das Superinstrument der Kategorisierungen der Artikel, das auch vermehrt genutzt wird. Es ist auch gut wenn ein Artikel in vielen (natürlich korrekten ;-) Kategorien vorkommt und damit auch leichter auffindbar wird. Im Artikel selbst wird allerdings die Darstellung der Kategorien immer unübersichtlicher. Allein wenn ich mir einen Personenartikel anschaue - ich zitiere nur als Beispiel vollkommen wertlos Winston Churchill:

Da wäre doch eine Darstellung wie:

Adelstitel: Lord Warden of the Cinque Ports

übersichtlicher.

Es wäre aber auch in anderen Artikeln von Vorteil, wenn man dabei z.Bsp. hinweisen will, dass nicht der ganze Artikel auf diese Kategorie zutrifft. Wenn ich beispielsweise einen Artikel wie Asea Brown Boveri hernehme. So ist dies ein Schweizer Unternehmen, hat aber aber eine gleich große Bedeutung z.Bsp. für D oder A. und das nicht nur heute, sondern ebenso eine Geschichte bei allen Standorten, so dass man es eigentlich nicht nur bei Züri einordnen sollte sondern genauso bei Mannheim oder Wiener Neudorf. In diesem Fall wäre es bei der Kategorieanzeige nützlich wenn es dann ausschauen würde:

Kategorien: Unternehmen (Zürich) | Elektrotechnikhersteller | Robotikhersteller

Deutscher Teil des Unternehmens: Mannheim, ..

Österreichischer Teil: Wien, Wiener Neudorf, Neutal

Eine weitere Möglichkeit wäre das Ausblenden von Kategorien im Artikel selbst. Damit erscheint ein Artikel zwar in einer Kategorie. Im Artikel selbst verwirrt der eintrag aber nicht. Um auf das o.a. Beispiel zurückzukommen, bei ABB - das könnte bei Wiener Neudorf drin stehen, denn für diesen Ort hatte das Unternehmen mit ein paar hundert Arbeitsplätzen sehr wohl eine Relevanz, obwohl er im Konzernartikel als einzelner Standort, wenn überhaupt, gerade erwähnt wird. Damit würde der Leser nur verwirrt werden und dann vielleicht sogar unkorrekt zum Editieren beginnen.

Über das wie kann es verschiedene Ansätze geben, wie einen Zusatz in der Katangabe im Artikel oder ähnlich dem Defaultsort. Ich weiß dass das ein gewaltiger Programmieraufwand wäre, bevor ich aber Programmierern damit am Wecker falle, wäre eine Diskussion vorerst besser. --K@rl (Verbessern ist besser als löschen) 11:40, 11. Dez. 2010 (CET)

ausblenden ist IMO keine Option; dann findet es gar kein leser mehr. Schon jetzt wird es wohl eher von Wikipedianern als von Lesern genutzt: Kategorie Deutscher, Nobelpreisträger Literatur, Unternehmen_(Zürich) ... das zeigt IMO gut das es für den leser entweder nicht interessant ist oder er es gar nicht kennt. das eine schließt das andere nicht aus; was er nicht vermisst sucht er auch nicht. Daher auch die frage ob der aufwand nicht besser in andere ggf. für den leser relevante dinge gesteckt werden sollte ..Sicherlich ^{Post / FB} 11:48, 11. Dez. 2010 (CET)

//1x Beitrag weg, 1x BK :-)// Nur am Rande zu Unsichtbarmachen: technisch kein Problem, s. hidden categories, aber man kommt da mit Sicherheit in unendliche Diskussionen darüber, was versteckt werden soll und was nicht (die heutige Regelung dagegen ist klar: Wartungskategorien werden verstekct, Punkt). Aber sonst: eine Kategoriestruktur wäre bei manchem Artikel nicht übel. -jkb- 11:50, 11. Dez. 2010 (CET)

@Sicherlich: Kann es nicht sein, dass der Leser es gerade wegen der Unübersichtlichkeit nicht verwendet?

@Allgemein: Zu den Nicht sichtbaren. Ich möchte nicht wissen, was heraus kommt, wenn ich bei der ABB alle großen Standorte (nicht Büros ;-) als Kategorien dazu gebe. Für Neutal, einem Ort mit 1000 Einwohner hat der Betrieb aber dieselbe Bedeutung wie der ganze Konzern für Zürich. deshalb meine Idee praktisch die Kategorie nur als Einbahnstraße, d.h. Kategorie > Artikel aber nicht Artikel > Kategorie --K@rl (Verbessern ist besser als löschen) 12:54, 11. Dez. 2010 (CET)

glaub ich nicht. Wie oft kann eine Frage in der Auskunft mit "Siehe kategorie XY" beantwortet werden? Mir fällt gerade keine einzige ein. das als indiz, natürlich nicht als beweis. und dann einfach mal exemplarisch die von mir verlinkten;

Kategorie:Deutscher - welcher leser würde diese kategorie nutzen wollen? Wofür? Ich wollte schon immer mal wissen wer alles deutscher ist? :D

Kategorie:Nobelpreisträger für Literatur - Liste der Nobelpreisträger für Literatur ist viel handlicher wenn ich was suche; da stehen nicht nur irgendwelche Namen alphabetisch sortiert. Die Kat macht das selbe wie die Liste nur schlechter ;)

Kategorie:Unternehmen (Zürich): es gibt keine adäquate liste, aber wiederum; was mache ich mit der Kategorie? Wann brauche ich die als leser? Ich halte es für denkbar dsa man es hin und wieder für etwas nutzen kann; aber die nachfrage nach dieser Info halte ich für sehr überschaubar. ...

alles keine "beweise" aber der "gegenbeweis" steht ja auch aus :P - ich denke die Kats sind ein verwaltungstool um das inzw. ein ziemlicher aufwand betrieben wird der aber nicht dem doch eher überschaubaren nutzen für den leser entspricht ...Sicherlich ^{Post / FB} 13:49, 11. Dez. 2010 (CET)

@Sicherlich: Ich glaube wir beide stehen da in einem Patt - ich sehe du hälst nicht viel von den Kategorien ;-), der Leser braucht sie gar nicht - ich halte sie prinzipiell gut, möchte sie aber verbessern. Dass du die Ressourcen dann wo anders leiber eingesetzt siehst, ist natürlich legitim. Nur möchte ich deshalb meine Idee nicht zu Tode diskutiert wissen, das sehe ich für mich auch legitim - Beweise haben wir beide keine also 1:1 ;-) --K@rl (Verbessern ist besser als löschen) 14:39, 11. Dez. 2010 (CET)

ich finde meine argumentation (logischerweise) recht schlüssig. Was ist deine gegenargumentation - "ich halte sie prinzipiell gut" ist inhaltlich nicht sonderlich tiefgehend. ich halte es auch durchaus für einen sehr wichtigen punkt zu klären wie bedeutend eine anfrage für den leser ist. was nützt es wenn wir resourcen in dinge stecken die dem leser keinen oder allenfalls marginale vorteile bringen? ...Sicherlich ^{Post / FB} 19:14, 12. Dez. 2010 (CET)

Sollte man nicht vielleicht einfach die Zuordnung ändern? ala Kategorie:Unternehmensstandort von ABB in den Artikel pflanzen? Eigentlich reicht aber die gegenseitige Verknüpfung durch Links aus (Liste der Standorte im Unternehmensartikel und Wirtschaftsabschnitt im Ortsartikel). Wir können nicht für jede logische Verknüpfung ne neue Kat anlegen. -- ✓ ^Bergi 18:13, 12. Dez. 2010 (CET)

@Sicherlich: Ich will da nicht die Kategorie selbst in Frage stellen, daher brauche ich da auch nicht tiefergehend argumentieren, sondern nur eine weitere Änderung, die in meinen Augen eine Verbesserung darstellen würde.

@✓: da reden wir aneinander vorbei, denn ich will damit nicht neue Kategorien schaffen, sondern will das Unternehmen bei Ortskategorien, die ja bestehen einordnen. Dabei aber nicht nur die Zentrale, denn wie schon oben beschrieben will ich die Asea Brown Boveri auch bei den Produktionsstandorten finden. Auch in Wiener Neudorf hatte die ASEA Brown Boveri die selbe Bedeutung wie beispielsweise Rewe International. Nur weil Rewe die Zentrale (und eigenen Artikel) dort hat findet man es in der Kategorie, und ASEA Brown Boweri aber nicht. - da stimmt die Relation nicht ganz. --K@rl (Verbessern ist besser als löschen) 19:30, 12. Dez. 2010 (CET)

womit K@rl sicher recht hat, ist, dass mit den neuen koordinatentools (allcoord) für die kategorien diese als interface zwischen den artikel und den georeferenzierungs-schwesterprojekten immer wichtiger werden, und auch sonst in dem maße, in dem internetuser mit der kategorientechnik vertraut werden (man denke an MySpace und ähnliche socials, aber auch wissenschaftlich/technisch arbeitende menschen, denen in indizes nachschlagen handwerkszeug ist), auch die anzahl der leser zunehmen wir, für die sehrwohl die kategorien (zumindest in gewissen themenbereichen) einen intuitiven zugang darstellen, sowieandererseits die fortschritte, die das semantic web macht (ich verweise da nur auf den Spektrum-artikel über uns letzthin: Computerlingustik: Wikipedia: Wissen für die künstliche Intelligenz
diese mächtige technologie zu vernachlässigen, wäre auf jeden falsch - wenn man zum beispiel an den ausbau von ref auf ref group denkt, was das alles gebracht hat, warum nicht ein cat group - allein schon um die kategorien sinniger anzuordnen, siehe churchil, was das für ein wirres zeug ist, weil es historisch gewachsen ist (in diesem kontext wirkt die Kat:Mann auch extrem doof), während eine semantisch korrekte anordnung

wirklich sehrviel einleuchtender (liest sich schon wie eine kurzbiographie), sowohl, um die kategorisierung zu lesen, als auch zu warten, wie auch, kategorien dann syntaktisch richtig zu benamesen
und wie bei so vielen innovationen: wozu man es wirklich noch verwenden kann, zeigt sich erst, wenn man es kreativ verwendet, also im laufe der anwendung (brauch ich nicht, hab ich zum handy auch gesagt, und zum computer in den 80ern auch..) --W!B: 20:50, 12. Dez. 2010 (CET)

Suchen und Ersetzen

Das Werkzeug „Suchen und Ersetzen“ ist mir als ziemlich nutzlos aufgefallen. Schon das Prinzip ergibt keinen Sinn: Wenn ich nicht alles ersetzen möchte, kann ich einzelne Zeichenketten suchen lassen. Wenn ich dann aber etwas gefunden habe, das ich ersetzen möchte, gibt es keinen Knopf „Dies ersetzen“. Stattdessen findet man „Nächste ersetzen“. Wer möchte aber den nächsten Treffer ersetzen, ohne zu wissen, worum es sich dabei handelt? Man könnte diese Funktion nutzen, wenn die Treffer bei Eingabe des Texts gelb hinterlegt würden. Stattdessen verdunkelt sich der Hintergrund und das Fenster versperrt die Sicht.

Man könnte meinen, dass dann zumindest die „Alles ersetzen“-Funktion zu gebrauchen ist, aber die arbeitet so fehlerhaft, dass man es besser bleiben lässt.

Ausprobiert habe ich das Werkzeug unter IE und Opera. -- Henrik 12:25, 16. Jul. 2010 (CEST)

Können die Fehler behoben werden? Oder funktioniert das Werkzeug nur mit Firefox? -- Henrik 17:30, 22. Jul. 2010 (CEST)

Dass die Suchen-und-Ersetzen-Funktion im Moment vermutlich eher als Bug als als Feature anzusehen ist, ist den Programmieren nach etlichen Fehlermeldungen in Bugzilla vermutlich bewusst, teilweise werden sie sogar ziemlich schnell behoben, sodass ich einfach mal optimistisch behaupte: Es besteht Hoffnung, dass die Funktion irgendwann nützlich sein wird. Bis dahin heißt es abwarten. Die Diskussion findet übrigens vor allem unter Wikipedia:Usability-Initiative/Softwarefehler statt. --Schnark 09:56, 26. Jul. 2010 (CEST)

Undo-Funktion

Da dummerweise alle Funktion des Wikieditor sich nicht rückgängig machen lassen (STRG + Z), fehlt diese Funktion um so mehr im Suchfenster. Des Weiteren könnte wenigstens sinnvoller Weise der markierte Text automatisch ins 1. Feld eingetragen werden (zum Text kopieren kommt man danach ja auch nicht mehr). -- πϵρήλιο ℗ 19:17, 26. Jul. 2011 (CEST)

Beziehst du dich auf Benutzer:Schnark/js/wikieditor? --Leyo 19:24, 26. Jul. 2011 (CEST)

Eigentlich nicht, ich meine das normale Suchen Ersetzen des Vector-Skins, aber der Wikipedia:wikEd hat diese Undo-Funktion. Nur benutz ich diesen nicht wegen zu vieler Bugs und Redundanz und zu niedriger Performance. -- πϵρήλιο ℗ 04:53, 21. Aug. 2011 (CEST)

[Autor-1] M. Musterman: Über die Farbes des Grases. ...

[1]