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

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

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

[[Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2012#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Requests/Archiv/2012#Thema_1

Mouseover bei refs

Ich möchte hier einen von Mai-Sachme in dieser Disk gemachten Vorschlag weiterleiten.

Das Problem

Fußnoten-Marker erklären nicht, auf welchen vorangegangenen Textabschnitt sie sich genau beziehen (Beispiel: Ist das letzte Wort, die letzte Wortgruppe, der ganze Satz oder evtl. der ganze Absatz gemeint?); das erschwert sowohl das eindeutige Verständnis für den Leser als auch das Nachbearbeiten durch Andere (mögliche Interferenz der Änderung mit einem nachfolgenden ref ). Erläuterungen im Fußnotentext selbst z.B. können helfen, machen die Sache ggf. jedoch auch komplizierter. Derzeit versucht jeder Autor, das selbst zu lösen. Wie (eben hier) nachzulesen ist, führt das wiederum leicht zu "internen Codes", die erst recht unverständlich bleiben können. Eine klare und verbindliche Lösung ist mit den derzeitigen Möglichkeiten zur Darstellung nicht erreichbar.

Der Vorschlag

Ein Mouseover beim Marker läßt die gemeinte Textpassage farbig unterlegt hervortreten.
Syntax, zum Beispiel: <ref>\referenzierter Textabschnitt\ Referenz-wie-bisher</ref>. Hierbei würde das erste <ref> im Text an den Anfang der referenzierten Passage gesetzt (anderenfalles müßte diese ja im Fußnotentext wiederholt werden, was den Quelltext übergehen ließe und ihn noch unverständlicher machen würde).
Die bisherige Option (also der Verzicht auf Vorziehen des Eingangs-<ref> samt Referenztext zwischen Backslashes oder wie auch immer) müßte natürlich - wegen der vorhandenen Einträge - erhalten bleiben.

Vorteile

• Intuitive Nachvollziehbarkeit für die Leser und klare Vorgaben für Autoren.

Nachteile

• Vermutlich einiger Aufwand, das zu implementieren. Sonderfälle wie verschachtelte Referenzierungen müßten bedacht werden, die Anleitungen für Autoren aktualisiert, und so weiter. (Einmal abgesehen von Detaildiskussionen wie "In welcher Farbe soll denn das aufscheinen" ... )

--Avstriakos 21:53, 18. Jan. 2012 (CET)

Ohne auf den Sinn der Übung einzugehen und wie das der Community vermittelt werden soll oder ob das Leser noch vertrauensseliger macht, aus technischer Sicht:

• annotierte Abschnitte, worauf sich welche Referenzen beziehen, klingen cool. Habe ich noch nirgendwo gesehen, ist aber eigentlich nur logisch.
• das Markup wird kompliziert. Du schreibst schon von „verschachtelten refs“, dazu kommen sich überschneidende (wie ''kursiv'''beides''fett'''). Das größte Problem sehe ich aber darin, dass nachträglich in einen annotierten Abschnitt eingefügte oder korrigierte Informationen a) verboten werden b) von einem Quelleneinsichtigen überprüft werden müssen oder c) die Annotation für dieses Stückchen aufgehoben werden muss.
• eine Schachtelung von Extension-Tags mit a) anderen Extensions b) Vorlagen c) Wikisyntax ist derzeit unmöglich (und refs funktionieren auch nur mit Workaround). Ebenso schwierig ist die Verknüpfung von zwei Elementen, da beide Markup beinhalten müssen (hast du so schön mit dem Schrägstrich umgangen). Eigentlich ist nur <ref text="Bienen tanzen">laut Jemand [//example.com/bees]</ref> oder <ref quelle="Jemand" url="//example.com/bees">Bienen tanzen</ref> möglich: Attribute dürfen nur reinen Text enthalten. Lassen wir das also.

Ich sehe allerdings die Möglichkeit, das ganze mit Vorlagen zu realisieren. Vorteile:

• schachtelbar
• ohne Softwareänderungen realisierbar (ein lokales Skript in Mediawiki:common.js reicht aus, besser: ein opt-out-Gadget)
• die enwp macht Referenzen schon ständig nur über Vorlagen, so schlimm kann das nicht sein.
• mit dem derzeigen System vereinbar.

HTML bietet m.W. für sowas keine semantischen Tags an, daher müssen wir wir wohl auf spans zurückgreifen. Schön wäre es eigentlich, die Absatz-Elemente mit einzubeziehen, das scheint aber erstmal unmöglich. Um mal den Text aus Denis Barthels Quelle zu klauen, würde es so aussehen:

{{belegter Absatz|von=phyl|Die Art gilt evolutionsgeschichtlich als jung. {{belegt|von=w1985|Die Art wurde 1851 von [[Louis Felicien de Saulcy]] im Umland von [[Jericho]] entdeckt und ihm zu Ehren 1854 von seinem Begleiter und Freund [[Jean-Hippolyte Michon]] im Werk {{belegt|von=mayeur|nicht=w1985|„Voy. Relig. Or. ii. 383“}}<ref name="mayeur" /> als ''Gargela nanus'' erstbeschrieben, wurde jedoch seither meist als ''Popolo nanus'' angeführt.}}<ref name="w1985" /> Spätere molekularbiologische Untersuchungen bestätigten diese Einstufung. Als nächstverwandte Art gilt demzufolge ''[[Popolo maritima]]''. Die dritte Art der Gattung, ''[[Popolo spinosa]]'', gilt als basale Schwesterart der gemeinsamen [[Klade]].<ref name="phyl" />}}
== Einzelnachweise ==

<references>
 <ref name="mayeur">Jean-Marie Mayeur: ''Claude Savart, L'abbé Jean-Hippolyte Michon (1806–1881)'' In: ''Contribution à l'étude du catholicisme libéral au XIXe siècle, Annales. Économies, Sociétés, Civilisations'', 1974, vol. 29, n° 5, S. 1277–1278.</ref>
 <ref name="w1985">A. Wistell:''The genus Popolo (Asteraceae-Inuleae).'' in: Southern Journal of Botany, Bd. 99, S. 299–999, ISSN 0107-099X.</ref>
 <ref name="phyl">Leslie R. Gomo, Javier Francisco, Arnoldo Santos, J. Power, C. Rander, Robert Ken: ''Molecular Systematics of the Popolo Alliance: Combined Nuclear and Chloroplast Data'' In: Systematic Plants, Bd. 27, Heft 4, 2006, S. 815–999.</ref>
</references>

Die Vorlagen „Belegt“ und „Belegter Absatz“ machen dasselbe, nur dass die erste ein Block-Element (<p>), die zweite ein inline-Element (<span>) ausgibt. Diese Elemente seien mit den Klassen „beleg“ und, individuell vom Parameter von abhängig, „beleg-ref-mayeur“ (etc.) versehen. Eventuell wird das ref-Tag auch gleich [automatisch] ans Ende hinzugefügt. Per Skript könnte man diese dann on-hover hervorheben (abschaltbar, einstellbar…). Klassen deshalb, weil es mehrere Stellen geben könnte die von derselben Referenz belegt werden. Zusätzlich hätte ich den Parameter nicht vorgesehen, um zu markieren dass der Werktitel nur von mayeur, nicht von w1985 belegt wird. Und es bräuchte auch eine Option nicht=alle o.ä., die bedeutet dass eine Stück von keiner der umschließenden Belege belegt wird. Bis hin zu Vorlage:Nicht Belegt, wenn es kein von gibt, auch wenn das dem unerwünschten [citation needed] ziemlich nahe kommt…
denkt -- ✓ ^Bergi 00:01, 19. Jan. 2012 (CET)

Hallo Bergi - vielen Dank für Deinen Vorschlag! Mir gefällt er sehr gut, weshalb ich ihn auch in der einschlägigen Disk verlinkt habe. Wie dort zu lesen ist, fürchtet sich aber Mancher vor der Syntax ... nun ja. Am ehesten kann ich noch die Besorgnis nachvollziehen, daß lustige Reinigungsmänner dann mit dem neuen Werkzeug über sämtliche Lemmata herfallen. Wird wohl nix - schade. Trotzdem Dank & Grüße, --Avstriakos 20:31, 20. Jan. 2012 (CET)

Ungesichtete Seiten: korrekter Link bei Datei- und Vorlagenkategorien

Bei Datei- und Vorlagenkategorien sollte der Link auf „Ungesichtete Seiten“ nicht auf den ANR voreingestellt sein. &namespace=6 bzw. &namespace=10 müsste an die URL angefügt werden. --Leyo 14:28, 21. Feb. 2012 (CET)

Du meinst MediaWiki:flaggedrevs-categoryview? -- ✓ ^Bergi 15:10, 21. Feb. 2012 (CET)

Ja. Wie ich gerade sehe, wurden Benutzer mit de-at, de-ch und de-formal mal wieder vergessen. --Leyo 15:18, 21. Feb. 2012 (CET)

Da müsste man aus dem Kategorienamnen den Namensraum extrahieren und dann die Nummer. Habe ich mal gemacht, scheint auch zu funktionieren, mal schauen, wie die Server das finden. Die anderen 3 Sprachen habe ich auch angelegt. Der Umherirrende 18:42, 21. Feb. 2012 (CET)

Auf lange Sicht sollte die Software aber alle Namensräume auswählbar machen, daher Bug 34568. Der Umherirrende 18:46, 21. Feb. 2012 (CET)

Danke! Bei de funktioniert es, bei den Varianten davon kriege ich &category=$1 in der URL.

Ja, das wäre das beste. --Leyo 18:48, 21. Feb. 2012 (CET)

Macht Sinn, ich hatte da noch etwas vergessen. Beim Prüfen der Varianten hatte ich nur auf den namespace-Parameter geachtet, nicht auf die Kategorie. Der Umherirrende 19:21, 21. Feb. 2012 (CET)

Perfekt, danke. --Leyo 19:30, 21. Feb. 2012 (CET)

Keine Ursache. Der Umherirrende 19:32, 21. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 19:32, 21. Feb. 2012 (CET)

Bei XML-Dumps (*.xml.bz2) Namesraum-Redirects angeben.

Wikitaxi ist nett, nur kann es nicht wahrsagen. :-)

Im Wiktionary gibt es auf Englisch den Namensraum [[Wikisaurus:. Auf Deutsch gab es früher [[WikiSaurus:. Dieser wurde 2009 in [[Thesaurus: umbenannt und ein Namensraum-Redirect angelegt. So weist [[WikiSaurus:koitieren]] im HTML-Link auf http://de.wiktionary.org/wiki/Thesaurus:koitieren (zB). Dies vermeidet einen BOT losschicken zu müssen um alles zu ändern. Dasselbe ist hier mit [[Bild: auf [[Datei:.

Wenn jedoch der Artikel-Dump hergenommen wird, ist die interpretierende Software ahnungslos und der Link zu WikiSaurus:koitieren geht genau dort hin, also ins Leere, da die Seite unter Thesaurus:koitieren zu finden ist. Wenn das in der XML-Datei im Abschnitt <namespaces> bekannt gegeben werden würde, könnte sich andere Software darauf einstellen. So wie auch die Systemvariable "Medium:" für "Datei:" bekanntgegeben wird, allerdings ohne zu sagen dass sie gleichbedeutend sind: <namespace key="-2" case="case-sensitive">Medium</namespace>.

Ebenso könnte man die jeweils landessprachliche Bezeichnung für "Book search" bzw. "ISBN-Suche" bekanntgeben. Die gibt es einmal als Spezial:ISBN-Suche (Nicht im Dump enthalten) und in manchen Wikis wird der Inhalt der Seite unter Wikipedia:ISBN-Suche editiert (im Dump enthalten), respektive in den Bezeichnungen der Landessprachen. Andernfalls kommen lokalisierte Systemeinstellungen zum tragen. Dies ist meines Wissens die einzige solche Seite im Wikipedia-Namensraum. Wenn interpretierende Software den Namen in der jeweiligen Sprache weiß, kann sie die Seite verwenden. Andernfalls kann es einen allgemeinen Link zu WorldCat oder so anbieten. --Franz (Fg68at) 14:58, 1. Feb. 2012 (CET)

Im xml-Dump bringt das vermutlich eher wenig, Wikipedia:Wikitaxi müsste das dann schon auch verstehen können. Die Infos lassen sich auch per API abfragen [2], vielleicht kann man Wikitaxi dazu bringen diese einzulesen bei der Umwandlung ins .taxi-Format. Ich weiß allerdings nicht, wie man dort Bugreports erstellt.

Ansonsten scheint Schnark auf Wikipedia:Wikitaxi/Skripte einige Dump-Ausbesserungsskripte gesammelt zu haben, die auch eine Ersetzung von Wikisaurus: durch Thesaurus: im Dump vornehmen können. -- ✓ ^Bergi 15:51, 1. Feb. 2012 (CET)

Klar muss Wikitaxi erweitert werden um das zu verstehen. Das kann dann in die konvertierte Datenbank eingearbeitet werden, soferne es nur zur Verfügung steht. Bei der API-Abfrage müsste das Programm noch um einen Internetclient erweitert werden und man muss zum Zeitpunkt der Konvertierung einen Internetzugang haben. Da sind die paar Zeilen <namespacealiases> weniger Aufwand. Und so hat man alle Offline benötigte Information immer bei der Hand. Das mit der ISBN-Seite lässt sich einmal erledigen, weil die ändert sich weniger oft. --Franz (Fg68at) 22:06, 1. Feb. 2012 (CET)

Seiten einer Kategorie nach Datum der Hinzufügung zur Kategorie sortieren

Ich bin daran interessiert sehen zu können, welche Seiten einer Kategorie zuletzt hinzugefügt wurden. (vgl. auch meine Frage unterWikipedia:FZW#Neueste_Mitglieder_einer_Kategorie). Das kann sehr hilfreich sein, wenn man Kategorien "beobachten" möchte, vergleichbar zur Versionsgeschichte/Beobachtungsliste für Seiten.

Eine Lösung würde ich darin, sehen, die Zuweisung einer Seite zu einer Kategorie in Zukunft automatisch in einem Log der betreffenden Kategorie zu loggen. Dazu müssten die letzten Änderungen der WP gescannt werdne auf die Vergabe von Kategorien. Im Ergebnis würde jede Kategorie in eigenes Log bekommen. --Zulu55 11:50, 8. Feb. 2012 (CET)

Anpassung des Vorschlags: Noch besser wäre ein Log das generell "Änderungen" (Hinzufügungen und Streichungen) von Seiten zu bzw. von einer Kategorie loggt. Die Seite dazu wäre dann Kategorie:XYZ/Log mit folgenden einträgen:

DATUM/UHRZEIT, BENUTZER/IP hat SEITE hinzugefügt (DIFFLINK)
DATUM/UHRZEIT, BENUTZER/IP hat SEITE gestrichen (DIFFLINK)

--Zulu55 11:56, 8. Feb. 2012 (CET)

Wäre praktisch, ja. --Summ 13:07, 8. Feb. 2012 (CET)

Ich habe mal Bug 34269 angelegt. Ich glaube aber nicht, dass er umgesetzt wird, es sind imho zu viele Logevents und m.W. passt die Filterung nach Kategorie nicht ins Schema des Logbuches.
Wenn es dagegen nur um die Daten der Hinzufügungen von aktuell enthaltenen Seiten geht, kann man dazu sicher ein Skript schreiben welches die Infos über die API extrahiert (konkret eine Filterung der Spezial:Änderungen an verlinkten Seiten). -- ✓ ^Bergi 15:40, 8. Feb. 2012 (CET)

Toll, danke. --Zulu55 16:03, 8. Feb. 2012 (CET)

Skript

PS: Falls ein derartiges Skript gewünscht ist, bitte auf Wikipedia:TSW melden. --17:40, 8. Feb. 2012 (CET) (Benutzer:✓)

Mir ist noch nicht ganz klar, was dieses Skript leisten würde. Wenn es eine Abfrage wie Wikiblame wäre müsste doch jeder in der betreffenden Kategorie enthaltende Artikel in seiner Versionsgeschichte komplett gescannt werden, oder? --Zulu55 11:58, 9. Feb. 2012 (CET)

Leisten wird es das, was gefordert wird. Natürlich dauert das dann, wie bei Wikiblame, seine Zeit. Im Zweifelsfall könnte es sämtliche Versionen nicht gelöschter Artikel durchgraben, parsen und nach Kategorien checken (das dauerte dann aber solange, dass es lieber auf dem TS erledigt werden sollte und das Ergebnis in einer Datenbank gespeichert würde). Ich stelle mir zurzeit einen intelligenten Algorithmus vor, der mit den ältesten Versionen von Artikeln anfängt (wo üblicherweise kategorisiert wird) und gleichzeitig Neukategorisierungen schnell über ÄnderungenAnVerlinktenSeiten findet. Beschränkt sich dabei auf Artikel, die derzeit schon in der Kat sind, und vermutlich werden per Vorlage eingebundene Kategorien nicht berücksichtigt. Genaueres erst auf Implementierungsauftrag :) -- ✓ ^Bergi 19:40, 9. Feb. 2012 (CET)

Eine andere Möglichkeit: Kategorien erhalten für einen Bot eine {{Vorlage:KategorieLog}}, so dass er weiß, das hier ein Log gewünscht ist. für diese Kategorie erstellt er im ersten Schritt eine Liste der aktuellen Artikel. Ab dann scannt er täglich die Kategorie und vergleicht aktuelle Kategorisierungen mit der Liste. Bei veränderungen (+/-) macht er Einträge "SeiteXY wurde am DatumXY hinzugefügt/gestrichen". Ein genauer Difflink ist dann nicht vorgesehen. Im Ergebnis könnte man ab dem Tag des Setzens der Vorlage Veränderungen relativ genau nachvollziehen. Ich mach mal eine neue Botanfrage draus. --Zulu55 08:51, 10. Feb. 2012 (CET)

siehe die Botanfrage Wikipedia:Bots/Anfragen#Ver.C3.A4nderungen_in_Kategorien_beobachten hier. --Zulu55 15:35, 15. Feb. 2012 (CET)

Zusätzlicher Hinweis: Die Aufnahme in eine Kategorie wird bereits jetzt von MediaWiki mit einem Timestamp versehen. Mit der Api lässt sich dieser abfragen: action=query&list=categorymembers&cmsort=timestamp&cmlimit=500&cmprop=title|sortkeyprefix|timestamp&cmtitle=Kategorie:*. Das ist vielleicht alleine schon hilfreich, würde aber jedenfalls auch ein Graben in den Versionen erleichtern :-) -- ✓ ^Bergi 15:53, 15. Feb. 2012 (CET)

externer Behelf

Ich wünsche mir auch schon seit Jahren ein Tool, das einem die neuesten Artikel in einer gewünschten Kategorie anzeigt. Da es bisher keine wikiinterne Lösung gab, habe ich mit dem Firefox-Updatescanner nachgeholfen. Allerdings habe ich das Gefühl das mein guter Browser nach und nach langsamer wird, je mehr Aufträge ich dem Update-Scanner zumute. Eine wikiinternes einfaches Tool wäre sehr wünschenswert. Bin Bot- und Script-mäßig unerfahren. Also falls der Aufwand dem Nutzen nicht gerecht wird, dann will ich mal nicht meckern ;) Aber wenn das umsetzbar wäre, dann würde das sicherlich vielen Benutzern ein willkommenes Zusatztool sein. Grüße, --BlueCücü 23:19, 16. Feb. 2012 (CET)

---

Nachträglicher Hinweis: Eine Übersicht zu Diskussionen zum Thema "Kategorien beobachten" im Sinne der neuesten Zu- oder Abgänge in einer Kategorie findet sich unter Benutzer:Zulu55/Wikipedia:Kategorien "beobachten". --Zulu55 (Diskussion) _Unwissen 15:34, 27. Aug. 2013 (CEST)

?redirect=no auf Beobachtungsliste

Unter Spezial:Neue Seiten werden sämtliche Seiten mit dem Parameter ?redirect=no aufgerufen, um bei Weiterleitungen auf dem neuen Artikel zu bleiben. Bei der Beobachtungsliste hingegen wird man beim Klick auf eine Weiterleitung (an der die Veränderung stattgefunden hat) zum eigentlich Artikel weitergeleitet. Das erscheint mir nicht sinnvoll. Kann man das ändern? Ich habe keine persönliche Einstellung gefunden, wo man dies tun könnte. Ich hoffe, dass der Vorschlag hier richtig ist. In den Archiven hab ich nicht gefunden, dass das Thema schon behandelt wurde. Gruß --Richtest^D 17:39, 5. Feb. 2012 (CET)

Das ist schon ein sehr lang gehegter Traum: Bug 890. Der Umherirrende 21:03, 20. Feb. 2012 (CET)

Hmm, das ist wirklich ärgerlich, 7 Jahre ist ja eine lange Zeit. Wo ist denn das Problem, an alle URLs ein redirect=no dranzuhängen? Oder überseh ich was fundamentales? --Richtest^D 19:57, 21. Feb. 2012 (CET)

Es scheint sich kein Entwickler gefunden zu haben. Das einzige Problem ist, das sich die Beobachtungsliste viel Quelltext mit den Letzten Änderungen teilt, wenn man es nicht auf beiden haben möchte, ist es etwas schwieriger, aber eigentlich machbar, denke ich. Der Umherirrende 18:26, 22. Feb. 2012 (CET)

Jein, Neue Seiten teilt sich doch den Code erst recht mit den Letzten Änderungen? -- ✓ ^Bergi 00:02, 23. Feb. 2012 (CET)

Nein, Recentchanges/Recentchangeslinked und Watchlist nutzen Funktionen von ChangesList.php zur Ausgabe. NewPages baut sich die Ausgabe selber zusammen. Der Umherirrende 19:08, 23. Feb. 2012 (CET)

Erweiterte Filtermöglichkeiten für die Beobachtungsliste

Ich fände es sehr hilfreich, wenn die Einträge der Beobachtungsliste auf verschiedene Art gefiltert werden könnten, um für eine bessere Übersicht zu sorgen. Einige Beispiele (in Klammern: Anwendungsszenario für mich):

• Hervorhebung der Beiträge bestimmter Nutzer (Hervorhebung der Beiträge betreuter Nutzer im Mentorenprogramm)
• Ausblendung von Beiträgen mit bestimmten Bearbeitungskommentaren bestimmter Nutzer (Ausblendung von fleißigen Nutzern, die im großen Stil Personendaten anpassen und Rechtschreibfehler korrigieren)
• Hervorhebung von Diskussionsseiten, die erstmals seit der eigenen Bearbeitung editiert werden (keine Antworten mehr übersehen)
• Hervorhebung/weniger prominente Darstellung ausgewählter Seiten (Hervorhebung eigener Anlagen, Unterdrückung von regelmäßig vandalierten Artikeln der eigenen Beobachtungsliste, u.ä.)

Kurzum: Es wäre schön, wenn man einige Regeln für die eigene Beobachtungsliste erstellen könnte, um die etwas individueller zu gestalten.

Grüße, --Polarlys 23:50, 8. Feb. 2012 (CET)

Zum dritten Punkt: Auf kleineren Wikis werden noch nicht gelesende Seiten auf der Beobachtungsliste fett dargestellt, dies ist aber aus Performanzgründen auf der deutschsprachigen Wikipedia nicht verfügbar. Der Umherirrende 21:02, 20. Feb. 2012 (CET)

Zum ersten Punkt:

a[href*="Benutzername"] { background:#C1FFC1; }

(„Benutzername“ und Farbe anpassen) in dein common.css einfügen. --Leyo 14:34, 21. Feb. 2012 (CET)

Oder (gewissermaßen als Eigenwerbung): Wikipedia:CSS #Beobachtungsliste.

Zum Ausblenden bräuchte es

.page-Spezial_Beobachtungsliste li Filterbedingung1,
.page-Spezial_Beobachtungsliste li Filterbedingung2,
.page-Spezial_Beobachtungsliste li Filterbedingung3 {
   display: none;
}

Dabei geht „Filterbedingung“ nur mit neueren Browsern; könnte etwas sein wie A[title="Benutzer:Aka"]. Auf den Textinhalt des BK („PDfix“) zuzugreifen wird mit CSS wohl nicht gehen; das bräuchte JavaScript. Mit CSS gingen nur Attribut-Werte und einige Pseudo-Klassen.

HGZH --PerfektesChaos 16:37, 25. Feb. 2012 (CET)

Geänderter Text in Kategorieübersicht

Es wäre sehr hilfreich, wenn man statt dem Artikelnamen einen Alternativtext in der Kategorie anzeigen lassen könnte. Das würde vieles Übersichtlicher machen. Beispielsweise könnte man in der Kategorie:Liste (Abgeordnete zum Kärntner Landtag) dann nur die Artikeln 1. Wahlperiode etc. benennen und es wäre übersichtlicher. Von den Vorlagenkategorien, wie Kategorie:Vorlage:Fremdsprachenunterstützung, wo man echt die Sprache statt dem teils unverständlichen Kürzel, will ich gar nicht reden ;-), <ironie>denn die Kat braucht ja eh niemand</ironie> --K@rl (Verbessern ist besser als löschen) 08:48, 25. Feb. 2012 (CET)

Eine Alternative wäre noch ein abweichender Tooltip - da wäre auch schon geholfen. --K@rl (Verbessern ist besser als löschen) 16:49, 25. Feb. 2012 (CET)

Verlinkung von Überschriften auf sich selbst

Ich hätte gerne, dass die Überschriften auf sich selbst verlinken, das würde es einfacher machen, direkte Links auf bestimmte Abschnitte zu kopieren. Wenn ich jetzt jemandem einen Abschnitt zeigen möchte, muss ich erst nach oben zum Inhaltsverzeichnis scrollen und dort auf die Überschrift klicken um die Adresse zu dem Anker im Adressfeld des Browsers zu haben (kann die Adresse natürlich auch auf dem Link im Inhaltsverzeichnis mit einem Rechtsklick kopieren). Es wäre einfacher, wenn jede Überschrift den eigenen Direktlink zu sich hätte. Es würde ja auch niemandem einen Nachteil dadurch entstehen. -- Graf Westerholt 08:58, 25. Feb. 2012 (CET)

Der Wunsch besteht schon länger: bugzilla:16691 --Schnark 09:38, 25. Feb. 2012 (CET)

Vorlage zur Verlinkung der Einzelnachweise

Hallo @ all,

in der englischen WP gibt es eine sehr gute Vorlage ({{harvnb}}), die es ermöglicht die Kurzzitate (in den Einzelnachweisen) mit Autor + Jahr auf das Literaturverzeichnis mit dem Langzitat zu verlinken (siehe zum Beispiel hier --> wie es sein sollte z. B. bei der dritten Referenz: Arredi, Poloni & Tyler-Smith 2007). Eine ausführliche Erklärung zu den „Shortened footnotes“ steht hier. Im Einzelnachweis steht dann verlinkt "Autor + Jahr", dann unverlinkt dahinter die jeweilige Seitenzahl (englisch: p. = page). Die englischen Vorlagen dazu sind ([3] und [4]. Kann das vielleicht jemand für die deutsche WP anpassen?

Edit: Es geht also darum, das Kurzzitat wie einen Link einbauen zu können, der aber nicht unterstrichen ist. Einen unterstrichenen Link, der im Prinzip genau das macht was ich meine (auf die Lit.-liste verlinkt), kann man mit der Vorlage Anker erstellen, das sieht aber wie hier im Beispiel (Conard 2009, S. xy) nicht gut aus! Es würde aber m.E. auch ausreichen, eine modifizierte Vorlage Anker mit nicht unterstrichenem Link zu erstellen. Ich habe jetzt mehrere Anläufe unternommen um auf das Thema aufmerksam zu machen, danke für Rückmeldungen.--LS 10:16, 23. Feb. 2012 (CET)

Ich sehe nicht, was an deinem Beispiel in Venus vom Hohlefels so viel schlechter sein soll als in en. In en finde ich den Wikitext deutlich unübersichtlicher, zudem stört mich, dass die öffnende Klammer verlinkt ist, die schließende nicht, das sieht irgendwie so unausgewogen aus. Das Einzige, was dort hübscher ist, ist die bläuliche Hinterlegung, aber die funktioniert im Internet Explorer bis einschließlich zur Version 8 ohnehin nicht und bräuchte neben dem massiven Einsatz komplexer Vorlagen auch noch zusätzlich globale CSS-Deklarationen. Die Lösung mit {{Anker}} dagegen ist einfach und relativ leicht nachzuvollziehen, daher in meinen Augen irgendwelchen komplexeren Lösungen vorzuziehen. --Schnark 09:57, 27. Feb. 2012 (CET)

Hallo Schnark, meines Erachtens irritiert es, wenn die Unterstreichung das Kurzzitat optisch nicht von einem WP-Link abgrenzt. Ohne Unterstreichung wären solche Links hingegegen sofort unterscheidbar. Wie groß wäre denn der Aufwand, einen nicht unterstrichenen Anker-Link zu bauen? Grüße--LS 12:15, 27. Feb. 2012 (CET)

In der Standard-Einstellung werden die Links nicht unterstrichen, nur wenn man mit der Maus darüberfährt. --Schnark 12:22, 27. Feb. 2012 (CET)

Sortierung in Spezial:Linkliste

Es wäre sehr praktisch, wenn die Liste, die bei Spezial:Linkliste alphabetisch sortiert angezeigt würde. Nichts ist umständlicher, wenn man Linkreparaturen oder was anderes bei solchen Artikel durchführt. Jedes Mal aufrufen wird es in einer anderen Reihenfolge (weiß nicht Artikel ID oder ÄnderungsID oder einer sonst nicht wirklich brauchbare Sortierung anzeigt. Beim Alphabet könnte maximal bei einer Änderung eines Artikels noch wer reinrautschen oder rausfallen. Aber es wäre insgesamt wesentlich einfacher zu arbeiten. derziet ist es nur Botfähig, dem ists wurscht ;-) --K@rl (Verbessern ist besser als löschen) 12:34, 27. Feb. 2012 (CET)

Das ist nach Artikel-ID. Aus Performanzgründen ist das aber nicht wirklich machbar. Außerdem hat die Datenbank aktuell keine Unterstützung für eine ordentliche Sortierung. So "verkehrt" wie auf Spezial:Alle Seiten macht auch keinen Sinn. Der Umherirrende 19:19, 27. Feb. 2012 (CET)

Nur dabei handelt es sich ja nicht um die zig-tausend Artikeln wie bei alle Artikel - aber vielleicht könnte man die Artikel ID mit anschreiben, das wäre dann auch schon übersichtlicher. Gibt es eine Exportmöglcihkeit einer solchen Liste, dass man sie at home sortieren könnte? --K@rl (Verbessern ist besser als löschen) 19:24, 27. Feb. 2012 (CET)

Die ArtikelID wird dem Benutzer vorenthalten, weil er vermutlich nicht sehr viel damit anfangen kann. Eine Exportmöglichkeit gibt es nur über diei Wikipedia:API, was für dich vielleicht schon zu umständlich sein kann. Ansonsten kann man das Limit der Spezialseite auch bis 5000 hochstellen und dann dürfte man in sehr vielen Fällen alle Seiten bekommen. Ansonsten sei noch gesagt, das es auch Seiten mit zigtausend Links gibt: Spezial:Meistverlinkte Seiten. Der Umherirrende 20:27, 27. Feb. 2012 (CET)

Neues Verschiebeformular hat einen Fehler

Moin, das neue Verschiebeformular (mit der Namensraum-Wahl) hat einen Fehler. Es bietet nämlich die Möglichkeit, den Kategorienamensraum auszuwählen. In den lässt sich aber gar nicht verschieben. Es wäre also besser, den Namensraum aus dem Formular zu nehmen. XenonX3 - (☎:✉) 23:43, 5. Mär. 2012 (CET)

Bug 35137 ist gemeldet. -- ✓ ^Bergi 23:40, 10. Mär. 2012 (CET)

meta-viewport mit Breite 768 Pixel für Tabletts

Wäre es möglich, den folgenden meta-Eintrag im Kopfbereich jeder Wikipedia-Seite (in der normalen Ansicht) mit auszugeben? <meta name="viewport" content="width=768"> Damit wären die Wikipedia-Seiten auch in der normalen Ansicht auf Tabletts (zum Beispiel iPad) viel besser lesbar. -- Pikachu (Diskussion) 21:31, 13. Mär. 2012 (CET)

Warum so schmal? Warum gerade 768 (Pixel)? Sollte die Breite nicht eher das Ausgabegerät bestimmen? -- ✓ ^Bergi 22:05, 13. Mär. 2012 (CET)

meta-viewport gibt die "Fensterbreite" an, für die ein Tablett die Seite auslegt. Am besten nimmt man hier eine so kleine Breite wie möglich, bei der die Seite gerade noch ohne "Rollbalken" dargestellt wird. Ohne diese Angabe wird die Seite beim iPad / iPhone und iPod touch auf 980 Pixel Breite ausgelegt und dann im Portraitmodus auf 768 Pixel oder weniger geschrumpft. Da die Wikipedia-Seiten komplett in ein 768-Pixel-breites "Fenster" passen (für weniger sind sie wahrscheinlich nicht flexibel genug), wäre diese Angabe für Tabletts sinnvoll. Dadurch würde der Seiteninhalt auf Tabletts größer dargestellt, da im Portraitmodus nicht von 980 Pixel auf 768 Pixel verkleinert werden würde. -- Pikachu (Diskussion) 12:17, 14. Mär. 2012 (CET)

Aber im Landscape-Modus würden dann 768px breite Seiten auf 980 aufgezoomt? content="initial-scale=1, maximum-scale=1" wäre doch sinnvoller, oder nicht? Ich weiß nicht, kennst du dich mit https://developer.mozilla.org/en/Mobile/Viewport_meta_tag bzw https://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html gut aus? -- ✓ ^Bergi 13:03, 14. Mär. 2012 (CET)

Naja, ich hab mich da mal eingelesen, aber das ist dort doch etwas kompliziert beschrieben, finde ich. initial-scale=1 wäre gut, maximum-scale=1 jedoch würde ein manuelles Zoomen am iPad unmöglich machen. Nochmal zu width=768: Ohne die viewport-Angabe mit width=768 wird beim iPad eine Webseite layouttechnisch für 980 Pixel Breite berechnet (Standardwert bei Fehlen einer viewport-width-Angabe) und dann im Portraitmodus auf 768 Pixel verkleinert und im Landscape-Modus entsprechend auf 1024 Pixel vergrößert. Durch eine viewport-Angabe mit width=768 würde die Seite gleich für 768 Pixel Breite berechnet und es käme im Portraitmodus zu keiner Verkleinerung, wodurch die Schrift auf der Seite größer und besser lesbar wäre. -- Pikachu (Diskussion) 15:39, 14. Mär. 2012 (CET)

Ja, das mit dem maximum-scale hatte ich übersehen. Für hochauflösende Displays wohl eher ungeeignet.

An width=768 stört mich etwas, dass das genau aufs iPad im Portrait-Modus zugeschnitten ist. Im Landscape-Modus wäre eine breitere Seite deutlich angebrachter. Und bei kleineren Displays, die sowieso Zoomen müssen, sind 768px doch etwas schmal.

Optimal wäre bei großen Displays mMn width=device-width (initial-scale=1.0). Nur wird dann bei kleineren Displays die WP in die 320px/480px eines iPhones gequetscht. Eigentlich bräuchte ich also min-width=768 - gibts leider nicht. Nach http://www.quirksmode.org/blog/archives/2010/09/combining_meta.html könnte man das aber evtl mit CSS erreichen: <meta name="viewport" content="width=device-width" /><style>@media all and (max-width: 767px) { body { min-width:800px } }</style>. Ich frage mich nur wie sich da der initial-scale verhält, kannst du das vielleicht mal ausprobieren? -- ✓ ^Bergi 17:18, 14. Mär. 2012 (CET)

Die 768 Pixel geben ja nicht die Breite des Displays an, sondern die Breite, die zum layouttechnischen Aufbauen der Seite benützt wird. Anschließend wird das so ermittelte Layout so gestaucht/gestreckt, damit es aufs Display paßt. Also je schmaler die Breite fürs Layout desto besser, denn dann wird die Seite bei größeren Displays auch größer dargestellt (gestreckt). Ohne die viewport-Angabe werden immer fix 980 Pixel genommen (zumindest beim iOS), unabhängig von der Breite des Displays (soweit ich weiß). -- Pikachu (Diskussion) 18:01, 14. Mär. 2012 (CET)

Ja, klar. Aber warum sollte ein iPad3 auf seinen 2048 Pixeln ein 768px schmales Layout anzeigen, das ist fast 3fach vergrößert? Ein 1024er-Layout wäre deutlich angenehmer. Auch würde sich beim Wechsel auf Hochkant die Zoomstufe verändern, was mir für breitenflexible Seitenlayouts wie hier in WP absolut unsinnig erscheint. -- ✓ ^Bergi 18:20, 14. Mär. 2012 (CET)

Ohne eine viewport-Angabe nimmt iOS jedenfalls standardmäßig 980 Pixel an, auch bei einem iPhone. Und ich vermute mal auch bei einem iPad3. Sonst wird die logische Seitenbreite zu groß (entspricht dann einem überbreiten Browserfenster) und dadurch die Schrift zu klein. Die Zoomstufe ändert sich ohne eine Viewport-Angabe auch beim Drehen. Wikipedia in der normalen Ansicht mal auf einem iPad gesehen? Die ist im Portraitmodus kaum lesbar, weil so kleine Schrift. Durch Anwenden des Lesezeichens unten (viewport width=768) wird sie lesbar. Einfach mal selber auspobieren. Ein Bild sagt mehr als 1000 Worte. :) -- Pikachu (Diskussion) 21:58, 14. Mär. 2012 (CET)

Dieses Javascript als Lesezeichen auf dem iPad anlegen. Damit kann das getestet werden. -- Pikachu (Diskussion) 12:31, 14. Mär. 2012 (CET)

javascript:

meta = document.createElement("meta");

meta.name = "viewport";

meta.content = "width=768";

document.getElementsByTagName("head")[0].appendChild(meta);

Kürzer: javascript:$('head').append('<meta name="viewport" content="width=768" />');return void(0); -- ✓ ^Bergi 13:03, 14. Mär. 2012 (CET)

Das geht aber nur, wenn die angezeigte Seite die Funktion $ (zum Beispiel aus jQuery) eingebunden hat, da dieses Javascript-Lesezeichen direkt auf die angezeigten Seite angewendet wird. -- Pikachu (Diskussion) 15:39, 14. Mär. 2012 (CET)

Haben wir aber auf Wikipedia :-) Klar, bei anderen Seiten funktionierts nicht. -- ✓ ^Bergi 17:18, 14. Mär. 2012 (CET)

Balkenanzeige über relativen Zeitpunkt der Versionserstellung

Bei umstrittenen Artikeln wie auch bei Vandalismus wäre es sehr hilfreich, wenn Nutzer schon gleich bei Aufruf der Artikelseite einen Hinweis darauf finden. Ich stelle mir das z.B. so vor, dass der Link "Versionsgeschichte"

• bei Veränderung innerhalb a) der letzten Stunde b) der letzten 24 Stunden c) der letzten Woche und d) des letzten Monats in unterschiedlichen Stufen auffälliger dargestellt wird (Blinken, Unterstrich, Hintergrundfarbe), oder alternativ dazu
• einen zusätzlichen Balken bekommt, der logarithmisch den zeitlichen Abstand zur letzten Version verdeutlicht.

So hat man schnell eine besser Übersicht, ob man mit der aktuellen Version eventuell einen (un-)umstrittenen Stand vorliegen hat. Nicht bei jeder Information muss man dann immer die Versionsgeschichte oder die Diskussion (für die wohl auch ein solcher Balken sinnvoll wäre) aufrufen. Blinken hätte den Vorteil, dass unbedarfte Nutzer deutlicher auf die Relativität des Wissens der jeweils aktuellen Artikelseite hingewiesen werden, stört aber vielleicht bei Artikeln, die häufig nur gering verbessert werden, all zu unnötig das Erscheinungsbild. --31.16.106.103 14:48, 17. Mär. 2012 (CET)

Einbindung von Wikidata

Auch wenn es noch ein Jahr hin ist, aber es ist nie zu früh, sich über die Realisierung der Einbindung von Wikidata und seiner Informationen in die Media-Wiki-Oberfläche Gedanken zu machen. So einfach wie mit Commons, wo man einfach einen Link mittels {{Commonscat}} o. ä. setzt, wird es nicht gehen, und die Einbindung von Bildern ist auch nochmal was anderes als die Einbindung von komplexen Daten und Zusammenhängen. Gibt es zu der Thematik schon lokal Überlegungen? Konkret würde ich vorschlagen, einen neuen Reiter "Metadaten" oder so neben "Bearbeiten" und "Versionen/Autoren" zu platzieren, hinter dem die eingebundenen Daten übersichtlich dargestellt werden. 79.217.172.165 18:15, 10. Apr. 2012 (CEST)

Da das Projekt noch in der Entstehung ist, solltest du den direkten Weg mit dem Projekt suchen. Neben Wikipedia:Wikidata wird es wohl auch auf Meta eine Seite geben oder eine E-Mail-Möglichkeit. Der Umherirrende 20:22, 10. Apr. 2012 (CEST)

letzte Änderung bezieht sich auf einzelne Abschnitte

Für große ausgewählte Seiten, vor allem Löschkandidaten fällt mir das regelmäßig auf, die sich auf meiner BL befinden, wäre es schön, wenn die letzten Änderungen nach den einzelnen Abschnitten "aufgedröselt" werden. So sehe ich zwar auf meiner BL die letzten Änderung an der Seite Löschkandidaten/Datum aber ob sie "meinen" Löschkandidaten betrifft oder ob es Änderungen "meinen" Löschkandidaten betreffend gibt, sehe ich nicht. Ich hätte gern statt

  Wikipedia:Löschkandidaten/29. Mai 2012‎

die Ansage

  Wikipedia:Löschkandidaten/29. Mai 2012#mein Kandidat

Ich hoffe, ich habe mich verständlich ausgedrückt.

LG

-- Matthias (Diskussion) 21:20, 29. Mai 2012 (CEST)

Hilft dir Benutzer:DrTrigonBot/Doku#Diskussions-Zusammenfassung? --Leyo 10:22, 1. Jun. 2012 (CEST)

Hab mich gerade eingetragen, aber das ist, so glaube ich, nicht das, was ich will, zumal der Bot nur einmal am Tag läuft. Ich bin aber trotzdem auf die Veränderungen gespannt. -- Matthias (Diskussion) 12:12, 1. Jun. 2012 (CEST) --

nein, das ist nicht das, was ich möchte: Ich möchte Wikipedia:Löschkandidaten/29. Mai 2012#mein Kandidat beobachten aber nicht Wikipedia:Löschkandidaten/29. Mai 2012. -- Matthias (Diskussion) 14:00, 2. Jun. 2012 (CEST) --

Das ist aktuell technisch nicht möglich. Dies liegt daran, weil MediaWiki die Seite nicht in Abschnitte speichert, sondern immer ganz. Es ist also garnicht bekannt, das sich ein Abschnitt ändert. Zusätzlich kann es ja sein, das der Abschnitt umbenannt wird oder verschoben wird. All das müsste man beachten. Zur Vereinfachung gibt hat sich ein Freiwilliger den Bot geschrieben und teilt in mit anderen. Alternativ kann man die Beobachtungsliste auch so steuern, das sie alle Änderungen zeigt und nicht nur die letzte (Einstellungen -> Beobachtungsliste -> "Erweiterte Beobachtungsliste zur Anzeige aller Änderungen"), dann würdest du auch die Änderungen an "deinem" Abschnitt mitbekommen, leider aber auch sehr viele andere Änderungen. Eine Software-Lösung wäre Wikipedia:LiquidThreads, aber die ist noch nicht so weit. Der Umherirrende 14:27, 2. Jun. 2012 (CEST)

Vielen Dank für die ausführliche Info -- Matthias (Diskussion) 17:16, 2. Jun. 2012 (CEST) --

Archivierung dieses Abschnittes wurde gewünscht von: Leyo 21:12, 2. Jun. 2012 (CEST)

Variable abgeleitet von Pagename für Sortierung

Es wäre nicht schlecht, wenn man die Variable von Pagename auch als eine darstellen könnte, wie man sie in diversen Sortierungen braucht also Pagename konvertiert ohne Umlaute, Hatschek etc. Das wäre im Vorlagenbau sicher sehr wertvoll. Außerdem sollte diese dann gleich als Defaultsortierung herangezogen werden, dann würden zahlreiche nicht notwendige Einträge für Sortierung wegfallen. D.h. Österreich würde standardmäßig unter O wie Osterreich eingeordnet werden ;-) --K@rl ("Vorsicht, Wikipedia geht über") 13:21, 10. Mai 2012 (CEST)

Den Wunsch mit der Sortierung gibt es schon lange, scheint aber im Momment nicht Performant lösbar zu sein. Falls man in der Vorlagenprogrammierung Kategorien setzt, kann man diesen keinen direkten Sortierschlüssel geben und dann sieht DEFAULTSORT aus der einbindenen Seite. Somit besteht eigentlich kein Bedarf für eine extra Variable. Der Umherirrende 18:19, 10. Mai 2012 (CEST)

Ich bin gerade mit den slowakischen Gemeinden und deren Denkmäler beschäftigt, wie Liste der denkmalgeschützten Objekte in Dolný Badín wie sollte ich das sortieren wenn ich in der Vorlage das Liste der denkmalgeschützten Objekte in abschneide und es unter PAGENAME einsortiere. Soll ich da als Sortierung:Dolni Badin reinschreiben? K@rl ("Vorsicht, Wikipedia geht über") 18:36, 10. Mai 2012 (CEST)

Du möchtest die Seite in die Kategorie unter "Dolni Badin" einsortieren? Dann schreib es in die Seite. Die Möglichkeit der Textbeschneidung sind eh bescheiden (und langsam), so dass es sinnvoller ist, das in den Artikelquelltext zu schreiben. Der Umherirrende 18:42, 10. Mai 2012 (CEST)

Na es soll (so wie es jetzt ist unter Liste (Kulturdenkmale im Banskobystrický kraj) mit der Sortierung Dolni Badin einordnen. Ich wollte in die Navileiste mit Str Len und Str right den Gemeindenamen ausfiltern und als Sortierung eiinfügen. Aber scheinbar geht das nicht. --gruß K@rl ("Vorsicht, Wikipedia geht über") 21:54, 10. Mai 2012 (CEST)

Sichten ohne Freigeben

Gesichteten Artikelversionen kann der Status gesichtet entzogen werden, ungesichteten jedoch nicht. Wäre es möglich, zwischen gesichtet/ungesichtet und freigegeben/nichtfreigegeben zu unterscheiden? Dann könnte, wenn ein Problem mit einer Änderung vorliegt, die kein klarer Vandalismus ist, beim Sichten der Status "nicht freigegeben" vergeben werden (evtl. mit Begründung). So muss nicht revertiert werden, aber es wird nach wie vor die alte Version angezeigt, und andere Autoren können sehen, dass es eine neue, bereits durchgesehene Version gibt, die nicht grundsätzlich abzulehnen (oder gar Vandalismus) wäre, mit der es aber Probleme gibt. Dieses Vorgehen wäre weniger eskalativ und die Sichter müssen sich bei sinnvollen, aber bspw. orthografisch oder technisch fragwürdigen Änderungen nicht zwischen Revert und eigenem Nacharbeiten entscheiden. Wenn nicht revertiert werden muss, wird zudem auch kein Duplikat einer älteren Version erzeugt. Man könnte sogar überlegen, den Passivsichter-Status an die Zahl der freigegebenen (statt nur der gesichteten) Versionen zu binden. -- Leif Czerny 12:56, 7. Mai 2012 (CEST)

Ob so etwas gewünscht ist, müsste m.E. zuvor mit einem Meinungsbild geklärt werden, denn ein derartiges Feature würde einen nicht unerheblichen Eingriff in die Abläufe darstellen und neue Konfliktfelder schaffen. Das kann man nicht einfach mal eben einführen. Gestumblindi 13:23, 10. Mai 2012 (CEST)

Naja, oder eben ein Bestehendes Konfliktfeld aufteilen. Ginge es den überhaupt (es lohnt ja nicht, in meinungsblid über etwas zu starten, das nicht mit vertretbarem technischen Aufwand umgesetzt werden kann). LG -- Leif Czerny 13:46, 10. Mai 2012 (CEST)

Im Prinzip wäre das ja eine weitere Stufe der Sichtung, etwas zwischen der bestehenden "Anti-Vandalismus-Sichtung" und den bisher nicht eingeführten Geprüften Versionen, oder? Gesichtet: Der Edit ist kein Vandalismus. Freigegeben: Der Edit sieht ausserdem sinnvoll aus. Technisch wäre es sicher möglich, technisch ist sehr vieles möglich, ob aber der Aufwand "vertretbar" wäre, weiss ich auch nicht. Ich denke ja, dass man dafür MediaWiki etwas umschreiben müsste... ein Community-Wunsch aus einer der grössten Wikipedia-Sprachversionen könnte dafür vielleicht schon ausreichend sein, er müsste allerdings sehr klar sein. Ich selbst bin eher dagegen und denke, dass der mögliche Nutzen den dadurch entstehenden Aufwand für die Community (jeder ungesichtete Edit müsste neuerdings "zweistufig" beurteilt werden) nicht aufwiegen würde. Gestumblindi 21:43, 10. Mai 2012 (CEST)

Mir scheint es sinnvoller den Vorschlag zum Anlass zu nehmen die geprüften Versionen voranzutreiben. Denn der Vorschlag die Änderung neben offensichtlichen Vandalismus auch weiter inhaltlich zu validieren gist ja genau Idee der geprüften Versionen.--BECK's 21:49, 10. Mai 2012 (CEST)

Die Geprüften Versionen, wie sie bislang konzipiert sind, setzen allerdings einen sehr hohen Aufwand voraus. Sie gehen weit über die Beurteilung, ob einzelne Edits sinnvoll aussehen, hinaus, denn ein "geprüfter" Artikel soll insgesamt "keine falschen Aussagen und keine verfälschenden Lücken" enthalten. Das setzt voraus, dass sich der Prüfende intensiv mit der gesamten Literatur zum Thema auseinandergesetzt und den Artikel mindestens so gründlich durchgearbeitet hat wie seine Autoren, bevorzugt sollte er vom Fach sein. Dass die Geprüften Versionen bisher nicht gekommen sind, liegt wohl daran. Gestumblindi 22:05, 10. Mai 2012 (CEST)

Zu Gestumblindis erster Antwort: Ja, so hatte ich es gedacht. Allerdings würde ich driekt "gesichtet" und "gesichtet und freigegeben" als alternative Buttons nebeneinander packen, d.h. das zweistufige Sichten müsste eben nur bei Problemfällen erfolgen. Wie würdest du die Annehmbarkeit dan beurteilen? Zu BECK's . ich würde auch eher sagen, dass die Geprüfte Version, wie Du sie beschreibt, viel höher hängt als das, was ich meine, aber ich wollte keinesfalls von einem solchen Plan Ressourcen abziehen oder ihn zurückstellen lassen. LG -- Leif Czerny 22:50, 10. Mai 2012 (CEST)

Die "zweistufigen" Gedanken müsste man sich auch dann so oder so machen ("sichte ich nun oder sichte ich und gebe frei?"), auch wenn man nicht zweimal aktiv werden müsste. Und wäre womöglich wilden Anwürfen ausgesetzt, wenn man sich erfrecht hat, eine Version freizugeben, die jemand anders für blühenden Unsinn hält ;-) Ich weiss nicht, ich weiss nicht... du könntest auch mal eine informelle Umfrage anlegen, um festzustellen, was die Wikipedianer so darüber denken? Gestumblindi 23:10, 10. Mai 2012 (CEST)

So viel Meta habe ich zwar bisher nicht gemacht... Ich denke mal darüber nach. LG -- Leif Czerny 19:39, 12. Mai 2012 (CEST)

Abschnittsweises Beobachten ermöglichen

Hi!

Wenn man Seiten wie Wikipedia Auskunft jedes Mal in der ganzen Form der Seite beobachten muss, wenn man dort eine Anfrage gestellt hat und eigentlich nur bei der eigenen Anfrage mithilfe der Beobachtungsliste auf dem Laufenden bleiben möchte, wird das relativ schnell sehr unübersichtlich, da solche Seiten in einer hohen Frequenz bearbeitet werden und so eine Antwort auf den eigenen Abschnitt sogar häufig untergeht. Darüber hinaus ist es auch relativ nervig, wenn man dann noch die E-Mail-Benachrichtigungen der Beobachtungsliste aktiviert hat. Ein volles Postfach ist so vorprogrammiert.

Und somit wäre ein Feature, das es ermöglicht, wenigstens auf wikipediainternen Seiten, nur bestimmte Abschnitte zu beobachten, sehr nützlich.

Liebe Grüße! --Wiki Gh! ^{Disk.; Bew.; ✉} 21:45, 8. Jun. 2012 (CEST)

War vor einigen Tagen auch schon Thema hier: /Archiv/2012#letzte Änderung bezieht sich auf einzelne Abschnitte. Der Umherirrende 00:04, 9. Jun. 2012 (CEST)

Das habe ich übersehen. LG --Wiki Gh! ^{Disk.; Bew.; ✉} 00:10, 9. Jun. 2012 (CEST)

Nachdem ich mir die alte Diskussion durchgelesen habe und zu erwarten ist, dass in naher Zukunft keine Lösung für die deutsche Wikipedia zur Verfügung stehen wird (Stichwort: LiquidThreads), wäre es zumindest sinnvoll, für die Beobachtungsliste zu ermöglichen, dass nur manche der beobachteten Seiten auch durch den E-Mail Benachrichtigungsdienst abgedeckt werden. --Wiki Gh! ^{Disk.; Bew.; ✉} 00:46, 9. Jun. 2012 (CEST)

Ob das dann schneller zur Verfügung steht, kann auch keiner sagen. Bei Google Summer of Code gibt es aber dieses Jahr ein Projekt zur Bebachtungsliste: mw:User:Blackjack48/GSOC proposal for watchlist improvements, vielleicht umfasst das ja einige deiner Wünsche (aber ob/wann das dann wirklich eingesetzt wird, ist auch nicht sicher). Der Umherirrende 11:29, 9. Jun. 2012 (CEST)

Suchen in fremdsprachigen Wikipedias

Wenn man nach einem Artikel sucht, der in der deutschsprachigen Wikipedia nicht vorhanden ist, fände ich es sinnvoll, eine Möglichkeit zu geben, fremdsprachige Wikipedias zu durchsuchen. Dafür könnte man zum Beispiel einen Button neben der Volltextsuche einfügen. Gruß --Jönd (Diskussion) 16:28, 3. Jun. 2012 (CEST)

Auf Spezial:Suche taucht der Satz "Für die Suchanfrage wurden keine Ergebnisse gefunden. Suche nach „Suchwort“ in anderssprachigen Wikipedias." auf, wobei der letzte Satz eine Verlinkung ist. Hierdrüber ist eine Suche auf einzelnen anderen Wikis möglich. Der Umherirrende 19:04, 3. Jun. 2012 (CEST)

Danke für die Antwort! Das Problem ist aber, wenn man nach Orten oder Personen sucht, die zwar erwähnt werden, über die jedoch kein Artikel existiert, erscheint diese Suche in anderssprachigen Wikipedias nicht. --Jönd (Diskussion) 18:07, 6. Jun. 2012 (CEST)

Das wäre in der Tat mal ein Service für den recherchierenden Leser. Diese scheinen in der "Community" allerdings nicht vorzukommen. Im Ergebnis suche ich natürlich nicht in Wikipedia, sondern in Google und wenn ich WP-Ergebnisse, gleich welcher Sprache, haben will, setze ich "Wikipedia" als zweiten Suchbegriff mit rein. Nur so findet man die Dinge, die nicht ohnehin jeder kennt. --13Peewit (Diskussion) 22:16, 15. Jun. 2012 (CEST)

Ich habe da mal etwas geändert. Vielleicht entspricht das euren Vorstellungen. Der Umherirrende 13:17, 16. Jun. 2012 (CEST)

Wobei, so gut ist der Platz auch nicht gewählt, weil der Text "Suche nach „Suchwort“ in anderssprachigen Wikipedias." jetzt auch zweimal auftauchen kann. Vorschläge? Der Umherirrende 13:35, 16. Jun. 2012 (CEST)

Sprachausgabe von IPA

Viele Leser haben Mühe mit der korrekten Interpretation von IPA. Daher wäre es toll, wenn die Wikisoftware eine automatische Konvertierung in eine Audiodatei durchführen könnte, so dass man sich die Aussprache auch anhören könnte. Ob dieser Wunsch realistisch ist, kann ich nicht beurteilen. --Leyo 08:43, 16. Mai 2012 (CEST)

Senf:

• Technisch ist das möglich.
  • Genauso wie die vorfabrizierten thumbs generiert werden und dann bei upload / im Cache liegen, könnten weltweit alle mittels Extension in Vorlage eingebundenen IPA-Code-Folgen jeweils in eine schäbige Audio-Datei geschrieben und in einer zentralen DB für alle Projekte abrufbar gehalten werden, mit den üblichen Cache-Mechanismen wie bei der Vorlagen-Expansion verwaltet und aktualisiert werden. Notfalls live generiert und dann erst in den Cache übernommen.
• International mit Sicherheit ein sinnvolles Feature.
• Organisatorisch müsste allerdings auf weltweiter Ebene irgendwer initiativ werden.
  • Es müsste sich eine Projektgruppe bilden, die das vorantreibt; MW-Leutchen müssten überzeugt werden.
  • Eine formelle Beschlussfassung auf Einführung eines derartigen Features mit Folgekosten für Hardware + Extra-Traffic muss irgendwo erfolgen.
  • Kommerzielle Produkte, die IPA→Audio können, gibt es die Menge. Wir könnten eigentlich einmal 120 $ investieren und sowas kaufen.
  • In unserer Philosophie bevorzugen wir OpenSource, aber selbst da gibt es wohl Werkzeuge (etwa Speech Dispatcher u. a.). Eine Extension müsste wohl die {{IPA}} in Speech Synthesis Markup Language wandeln und damit irgendeinen gerade installierten Generator anschieben.
  • Grundsätzlich betreiben wir erfolgreiche Live-Kooperation mit diverser externer Software, so
    • GeSHi in Hilfe:Syntaxhighlight
    • mathjax.org in Hilfe:Math
    • Allerlei Bildkonvertierung und Generierung
    • Ableger von HTML Tidy
• Wenn man mit sowas erstmal anfängt, will man natürlich auch die wiktionaries durch alle Sprachen durchkonjugiert bekommen; als nächstes jeden Artikel und jede Diskussionsseite als gesprochene Version auf dem Server vorhalten. – Eine Begrenzung auf IPA et al. und eine gewisse Textlänge wäre sinnvoll.

Liebe Grüße --PerfektesChaos 14:18, 18. Mai 2012 (CEST)

Vielen Dank für deinen hilfreichen Senf! :-)

Meine Anfrage, ob ein Antrag auf eine Förderung durch das Community-Projektbudget Erfolg haben könnte, wurde positiv beantwortet. Um selbst einen Projektantrag zu schreiben, fehlt mir das Wissen, beispielsweise bezüglich des geschätzten Programmieraufwands. Jede Hilfe in dieser Hinsicht ist willkommen. --Leyo 22:17, 28. Mai 2012 (CEST)

Unter Wikipedia:Community-Projektbudget/Sprachausgabe von Lautschrift habe ich mal einen Entwurf begonnen, der aktuell noch sehr unvollständig ist. --Leyo 11:20, 1. Jun. 2012 (CEST)

Beitrag von wikt:Benutzer Diskussion:Dr. Karl-Heinz Best zur allg. Diskussion hierher kopiert. --Leyo 14:06, 13. Jun. 2012 (CEST)
Die Idee ist faszinierend. Ob und wie sie realisiert werden kann, vermag ich nicht zu übersehen.
Ich möchte ein paar Aspekte nennen, die sich als Problem erweisen könnten:

• Es ist nicht ganz klar, was mit IPA genau gemeint ist. Das tatsächlich angewendete System unterscheidet sich von Handbuch zu Handbuch immer, mehr oder weniger. Soviel ich weiß, ist auch IPA selbst über die Jahre nicht ganz gleichgeblieben. Schaut man sich mal genau die beiden maßgebenden deutschen Aussprachewörterbücher (Duden; Krech/Stock u.a.) an, so gibt es bemerkenswerte Unterschiede. Ich halte sie für IPA-nah, aber sie sind keineswegs gleich.
• Geht man von vorhandenen IPA-nahen Transkriptionen aus, so haben wir natürlich eine Menge von bisher nicht bemerkten Fehlern in den einzelnen Artikeln, die den einzelnen Bearbeitern unterlaufen sind. Frage ist dann: werden diese Fehler automatisch korrigiert?
• Wenn man vom Schriftbild ausgeht, so verbirgt sich hinter gleichen Buchstabenfolgen keineswegs immer die gleiche Aussprache. (Umgekehrt natürlich auch nicht.) Beispiele: "beinhalten" könnte als "Bein-halten" oder als "be-inhalten" gelesen werden; der Ortsname "Giengen" enthält ein kurzes "i"; "Mecklenburg" ein langes "e"; etc. "Haiti" darf nicht mit Diphthong gelesen werden. Bei Fremdwörtern gibt es bei gleicher Schreibung oft mehrere Aussprachen, je nach dem, wie stark jemand das Wort noch als Fremdwort oder schon als einheimisches Wort betrachtet. Zumindest für solche Sonderfälle müssten m. E. Kontrolllisten angelegt werden.

Ich will die Idee nicht in Zweifel ziehen, sondern nur darauf hinweisen, dass es m. E. einige Probleme gibt, von denen ich nicht recht weiß, wie sie gelöst werden können. Bin gespannt, wie das weitergeht.
Beste Grüße! Dr. Karl-Heinz Best 10:56, 12. Jun 2012 (MESZ)

Die Idee ist nicht neu, ich hatte sie mal vor Jahren (2006/2007?) hier an dieser Stelle schon mal vorgestellt. Bin aber nach-wie-vor überzeugt, dass das eine sehr gute Idee ist - da ich kein IPA lesen kann. --Atamari (Diskussion) 14:15, 13. Jun. 2012 (CEST)

OK, es war 2005: hier --Atamari (Diskussion) 14:18, 13. Jun. 2012 (CEST)

Danke für den Hinweis. Das war vor meiner (aktiven) Zeit… --Leyo 14:24, 13. Jun. 2012 (CEST)

Zum letzten Punkt: Genau deswegen soll ja die Lautschrift direkt als Basis für die Aussprache herangezogen werden. Jedes mir bekannte TTS-Programm kämpft mit eben diesem Problem, da bisher immer die Orthografie der Sprache als Basis für die Aussprache gedient hat. Mit IPA ist eine fast exakte Wiedergabe von jeder realisierbaren Aussprache möglich. Der Zwischenschritt von interner Analyse und Interpretation des Geschriebenen entfällt folglich, was es deutlich einfacher machen könnte, ein solches Tool zu entwickeln. —★PοωερZ_Diskussion 14:25, 13. Jun. 2012 (CEST)

Nur eine Bemerkung: Das grundlegende Problem wäre dann, IPA-getreue Transkriptionen zu finden. Ich kenne nur welche, die der IPA mehr oder weniger nahe kommen; von den vielen ungewollten Fehlern will ich mal absehen. Die IPA-Hilfe im deutschen Wiktionary (http://de.wiktionary.org/wiki/Wiktionary:Lautschrift), nach der wir uns richten, entspricht keineswegs genau der IPA. Dr. Karl-Heinz Best (Diskussion) 17:13, 13. Jun. 2012 (CEST)

Allgemein zur weiteren Aufklärung:

1. Im Vorschlag geht es um die beiden Fälle
   1. <speech lang="IPA">bəˈʔɪnˌhaltən</speech> – wäre be-inhalten

      (credits to wikt:beinhalten) und

   2. <speech lang="IPA">baɪ̯nˈhaltn̩</speech> – wäre Bein-halten

      (credits to wikt:Bein + wikt:halten).

2. Eine völlig andere Liga würde das wohl mit „Schriftbild“ gemeinte

   <speech lang="de">beinhalten</speech>

   sein.

   • Das steht im Moment nicht zur Debatte; gleichwohl ist es als Potenzial in der vorgeschlagenen Syntax enthalten.
   • Mittlerweile seit Jahrzehnten beherrschen dies die Screenreader für Sehbehinderte, wiewohl zuweilen mit lustigen Versprechern.
   • Screenreader werten durchaus die Kontextinformationen aus, soweit sie ihnen bekanntgemacht wurden, und unterscheiden zwischen einem Physiotherapeuten, der gymnastische Übungen der unteren Extremität veranlasst, und einem Juristen, der Vertragsbestandteile einordnet.
3. Von der Vielzahl der vorhandenen Hörbeispiele erscheinen mir etliche so, als ob sie nicht von einem lebenden Menschen mit Mikrofon eingesprochen wurden, sondern bereits software-generierte Audio-Dateien sind.
4. Was mögliche Fehler im IPA angeht:
   • Auch die falsch getippte IPA-Sequenz ließe sich Sekunden später abhören und (noch vor dem Abspeichern der Wiki-Seite) bei einem offenkundigen Fehler durch Muttersprachler berichtigen.
   • Der Server würde sich die unbrauchbare Sequenz jetzt zwar noch einige Monate merken und auf Abruf bereithalten; weil das aber nie wieder jemand hören möchte, wird es irgendwann vergessen.

LG --PerfektesChaos 20:33, 13. Jun. 2012 (CEST)

Ausführliche Stellungnahme von Mai-Sachme. --Leyo 17:17, 18. Jun. 2012 (CEST)

Zugangsdaten per Mail zuschicken lassen

Moin, heute ging eine Mail ans Support-Team, dass eine Benutzerin nicht mehr auf ihren Account zugreifen könne, da sie Benutzername und Passwort vergessen habe. Sie schlug vor, dass eine Funktion eingerichtet werden sollte, bei der man nur seine Mailadresse angeben muss und dann sein Passwort und den Benutzernamen zugeschickt bekommt (wie bei den meisten Foren). Lässt sich das für Mediawiki bzw. die WP auch einrichten? Ich finde die Idee gut, da das Support-Team häufig solche Anfragen bekommt (in der Regel mit der Frage, ob die Admins oder OTRSler einem die Daten zuschicken können), die man dann leider verneinen muss. Grüße, XenonX3 - (☎:✉) 16:29, 27. Jun. 2012 (CEST)

Der Wunsch ist schon älter: Bug 28085: allow login with email as well as username. Mit anderen Worten: Sowas muss erst programmiert werden. — Raymond ^Disk. 17:14, 27. Jun. 2012 (CEST)

Ich lese XenonX3 Anfrage so, das man nach Eingabe einer E-Mail-Adresse einer Liste der Benutzernamen an diese gesendet bekommen sollte. Diese Funktion ist in MediaWiki implementiert, aber der Datenbankindex fehlt auf WMF-Wikis, um auch in endlicher Zeit ein Ergebnis zu finden, siehe Bug 34386. Vielleicht könnt ihr dort noch schreiben, das es häufiger Anfragen zu diesem Thema gibt und es deshalb sehr sinnvoll ist.

Das man sich per E-Mail-Adresse anmelden kann, ist sicher auch nett, aber etwas anderes. Der Umherirrende 18:28, 27. Jun. 2012 (CEST)

Umherirrender hat Recht. Es ist so gemeint, dass man, vergleichbar zu Spezial:Passwort neu vergeben, seine E-Mail-Adresse angibt und dann per Mail seine(n) Benutzernamen und die dazugehörigen Passwörter bekommt. XenonX3 - (☎:✉) 18:43, 27. Jun. 2012 (CEST)

Die ursprünglichen Passwörter gibt es nicht in der Mail, weil sie garnicht im Klartext in der Datenbank stehen. Aber es werden temporäre Passwörter für die Benutzerkonten vergeben, die dann eine zeitlang gelten, aber nicht das ursprüngliche Passwort vernichten. Es ist also genau das selbe, wie bei der Passwort-Zurücksetzung für einen bestimmten Benutzername, nur das die Benutzerkonten auf Basis der E-Mail-Adresse ermittelt werden. Der Umherirrende 19:25, 27. Jun. 2012 (CEST)

Oder so. Ein temporäres Passwort würde auch reichen. Man könnte ja eine Auswahlmöglichkeit bieten: Entweder temp. Passwort oder Benutzername(n) zuschicken lassen. XenonX3 - (☎:✉) 19:52, 27. Jun. 2012 (CEST)

Fehlermeldung „Ungültiger Titel“ bei gelöschtem Artikel

Ich habe auf die Falschschreibungsweiterleitung Brett vor´m Kopp einen SLA gestellt. Bevor der Artikel gelöscht wurde habe ich meine Beobachtungsliste geladen:

K   17:12 	Brett vor´m Kopp‎ (Unterschied | Versionen) . . (+207)‎ . . Fomafix (Diskussion | Beiträge) (SLA+)

Die beiden Links Unterschied und Versionen führen nun aber zu einer Seite mit folgender Fehlermeldung:

Ungültiger Titel

Der Titel der angeforderten Seite ist ungültig, leer oder ein ungültiger Sprachlink von einem anderen Wiki. Möglicherweise enthält er nicht zulässige Sonderzeichen wie zum Beispiel <, >, |, [, ].

Zurück zur Seite Wikipedia:Hauptseite.

Erwarten würde ich hier eine Information, dass der Artikel gelöscht wurde. --Fomafix (Diskussion) 22:56, 27. Jun. 2012 (CEST)

Der Titel kommt von MediaWiki:Badtitle und der Text von MediaWiki:Badtitletext. --Fomafix (Diskussion) 15:09, 9. Jul. 2012 (CEST)

Formatvorlage: nicht unterzeichneter Beitrag

In Diskussionen: Beispiel: (nicht unterzeichneter Beitrag von IP-Adresse 217.184.123.190 am 23. Aug. 2007 um 12:23) // Zum einen: Unterschreibe bitte Deine Beiträge (am Ende des Beitrages mit vier "~")...

Es gibt wohl keine Formatvorlage mit

nicht unterzeichneter Beitrag von Benutzer NAME vom DATUM nachgetragen von ~4~ . Ich würde mir das wünschen. --Schwab7000 (Diskussion) 16:18, 11. Jul. 2012 (CEST)

Hallo Schwab7000, wie wäre es mit Vorlage:Unsigniert? --Wiegels „…“ 17:08, 11. Jul. 2012 (CEST)

Danke. Hatte es gerade auch selbst gefunden, aber über den Umweg von en:wiki. Problem: Das Wort «(Un)signiert», man muss drauf kommen, statt «unterzeichnet» oder gezeichneter (Beitrag). erledigtErledigt--Schwab7000 (Diskussion) 12:56, 12. Jul. 2012 (CEST)

Linktext bei Spezial:Linkliste

Mit Spezial:Linkliste werden die Artikelnamen mit Links auf diese Seite angezeigt. Es wäre schön, wenn zusätzlich die Linktexte der einzelnen Links, also der Text nach dem |, angezeigt werden können. --Fomafix (Diskussion) 15:13, 9. Jul. 2012 (CEST)

Das würde eine Datenbankänderung bedeuten, müsste also über Hilfe:Bugzilla angefragt werden. Gerne gesehen wäre auch das Abspeichern der Ankertexte. Das Problem dabei ist nur, das man wohl maximal 255 Bytes vom Linktext oder Anker speichern wird, wobei das manchmal wohl auch zu kurz ist. Der Umherirrende 18:05, 9. Jul. 2012 (CEST)

Ich habe erst mal an ein Tool auf dem Toolserver gedacht, das per JavaScript eingebunden wird. Eine direkte Integration in MediaWiki wäre natürlich auch nicht schlecht. Den Anker separat zu erfassen wäre auch gut. Technisch gesehen wäre das eine Tabelle, die für jeden Artikel das Linkziel, den Anker und den Linktext speichert. --Fomafix (Diskussion) 13:03, 10. Jul. 2012 (CEST)

Ja, so eine Tabelle gibt es ja aktuell auch schon und diese beinhaltet aktuell nur das Linkziel (geteilt in Namensraum und Seitennamen). Eine Lösung auf dem Toolserver müsste ja auch eine solche Tabelle aufbauen und halbwegs synchron halten (mit Dumps oder ähnlichem) damit sie verwertbar ist. Wahrscheinlich keine schöne Aufgabe. Der Umherirrende 17:11, 10. Jul. 2012 (CEST)

Wenn die bestehende Tabelle um zwei weitere Spalten für Anker und Linktext erweitert wird, dann werden auch mehr Zeilen eingetragen. Bisher kann pro Artikel ein Linkziel nur einmal vorhanden sein. Mit den zusätzlichen Spalten kann bei unterschiedlichen Ankern oder Linktexten ein Linkziel mehrfach in der Tabelle eingetragen sein. Bei einer solchen Änderung muss die Performance beachtet werden. --Fomafix (Diskussion) 09:47, 11. Jul. 2012 (CEST)

Dieses Feature müsste sich auch clientseitig als Gadget realisieren lassen. Bei Gelegenheit mache ich mich mal ran. --Fomafix (Diskussion) 10:44, 19. Jul. 2012 (CEST)

Ranking in einer sortierbarenTabelle

Folgendes Beispiel:

Ranking	Gemeinde	Einwohner	Fläche
1.	Ort 1	20514	9.95
2.	Ort 2	4050	16.97
3.	Ort 3	14614	12.57

Soweit so gut. Es wäre nur nicht schlecht eine fixe erste Spalte zu haben. Damit kann ich bei längeren Tabellen leicht sehen , welcher ist jener an der 20. Stelle in Bezug auf Bewohner und das nächste Mal in Bezug auf die Fläche etc.Also Beipielsweise wenn man in der ersten Spalte # einfügt. --K@rl ("Vorsicht, Wikipedia geht über") 17:31, 6. Jul. 2012 (CEST)

Machst du zwei Tabellen nebeneinander als Bastellösung. Steak 19:13, 7. Jul. 2012 (CEST)

Das heißt du musst drei machen, wobei die 2. und die 3. in der ersten drin sind. Das ist schon eine Bastellösung und hoffentlcih in allen möglcihen Bildschirmvarianten gleich und vor allem korrekt ;-) - aber danke für den Tip. --K@rl ("Vorsicht, Wikipedia geht über") 20:27, 7. Jul. 2012 (CEST)

PS. das funkt aber nur wenn wirklich alle Zellen einzeilig sind, eine Zeilenschaltung und aus ists. --K@rl ("Vorsicht, Wikipedia geht über") 20:28, 7. Jul. 2012 (CEST)

So schauts nicht gerade gut aus - wenn es auch den Zweck erfüllt, was ich möchte. --K@rl ("Vorsicht, Wikipedia geht über") 10:11, 13. Jul. 2012 (CEST)

Hier wirkt es auch schon besser. Aber kaum ist in einer Zelle eine 2. Zeile - ist das Modell über dem Haufen gehaut. Also eine Fixgröße in Form einer Systemvariablen wäre das beste ähnlich der # --K@rl ("Vorsicht, Wikipedia geht über") 11:28, 29. Jul. 2012 (CEST)

Verhindern von falschen OP-Sperren

Moin, in Ticket:2012073010006698 wurde seitens eines kleinen lokalen Providers darauf aufmerksam gemacht, dass aufgrund unserer no-open-proxy-policy die Gefahr besteht, dass mit einer Sperre mehrere Tausend Benutzer auf einmal gesperrt werden können. Offenbar leiten einige dieser Provider alle ihre Kunden über einen NAT-Router ins Internet. Wenn nun die IP des Routers gesperrt wird (wie in diesem Fall bei 194.25.112.134 (Diskussion • Beiträge • gelöschte Beiträge • SBL-Log • Sperr-Logbuch • globale Beiträge • sperren • Whois • GeoIP • RBLs)), dann können mehrere Tausend Kunden nicht in der Wikipedia editieren. Der Provider hat angefragt, ob sich eine Technik einrichten lassen könnte, die sowas verhindert. Vorgeschlagen wird, dass "Wikipedia mit uns kleinen Providern einen Mechanismus ausarbeitet welche Falscherkennungen vermeiden hilft ohne euren Schutz vor Proxy-Vandalen unscharf werden zu lassen." Geht sowas überhaupt? Danke im Voraus + Grüße, XenonX3 - (☎:✉) 14:09, 2. Aug. 2012 (CEST)

Beitragslisten

Hallo! Für Beitragslisten wie "eigene Beiträge" und "Versionsgeschichten" schlage ich vor, dass eigene Artikel (eigener Benutzername) hervorgehoben werden (Zeile bzw. Links z. B. in grün statt in blau). Begründung: beim Betrachten von früher mal bearbeiteten Artikeln (etwa aus der Beobachtungsliste) findet man schneller wieder, mit was man sich da damals befasst hat DANKE --kai.pedia (Diskussion) 14:24, 2. Aug. 2012 (CEST)

Darf ich dir die vielfältigen Gestaltungsmöglichkeiten gemäß Wikipedia:CSS #Eigene Beiträge anempfehlen? Auf deinen eigenen Spezial:Beiträge siehst du ohnehin nur dich selbst; vielleicht meintest du die Beobachtungsliste. Ich hoffe, das trifft das, was du oben gemeint hast. --PerfektesChaos 15:06, 2. Aug. 2012 (CEST)

Erst mal danke für den Tip! Allerdings hab ich (noch) nicht kapiert, wo diese Einstellungen vorzunehmen sind... (auf jeder Seite, die man so sehen will oder gibt es eine benutzerbezogene Zentrale Stelle für sowas...) - muss das mal im Detail studieren... --kai.pedia (Diskussion) 19:06, 7. Aug. 2012 (CEST)

→ Wikipedia:CSS#Einbindung. XenonX3 - (☎:✉) 19:12, 7. Aug. 2012 (CEST)

Einfügen von Links

Hallo, ich schlage vor bei der Funktion zum Einfügen und Setzen von Wiki-Links mittels kenntlich zu machen, ob es sich um eine BKL handelt oder um einen Artikel. Dies würde das Setzen deutlich erleichtern und eine spätere Auflösung der BKL zum korrekten Artikel ersparen. Gruss --Mogadir Disk. 13:29, 16. Aug. 2012 (CEST)

Hinweis an Benutzer von Älteren Browsern

Zahlreiche Internetnutzer surfen heute immer noch mit teils Uralten Browserversionen wie z. B. Internet Explorer Versionen 6 oder 7. Diese Browser können mit den heutigen Webstandards nicht umgehen und erfordern erheblichen Mehraufwand bei der Entwicklung von Websites. Zudem sind diese Browser auch ein Einfallstor für Schadsoftware. Mein Vorschlag wäre, in die Mediawiki-Software global einen Hinweis einzubauen, der Benutzern solcher Urzeit-Browser angezeigt wird, z. B.:

Lieber Nutzer, du verwendest einen Veralteten Internetbrowser.
Es kann sein das Internetseiten nicht richtig dargestellt werden oder nicht richtig benutzt werden können.

Weiterhin kann auf entsprechend präparierten Seiten Schadsoftware auf deinen Computer gelangen.

Erwäge eine neuere Version deines Browsers zu Installieren. Wenn du selbst keinen Einfluss auf die Software-Installation hast, informiere deinen System-Administrator!

Man könnte auch noch einen Link zur aktuellen Version des jeweiligen Browsers integrieren. (nicht signierter Beitrag von Jogo.obb (Diskussion | Beiträge) 20:00, 20. Aug. 2012 (CEST))

Sprachlich sollte man das noch anpassen, aber grundsätzlich finde ich die Idee gut. Wobei ich mir wünschen würde, dass ein solcher Hinweis einem User nur einmalig (bzw. bis zum Cookie-Ablauf oder so) angezeigt wird und nicht ständig nervt, wenn er nichts dagegen machen kann... Man könnte auch inhaltlich noch etwas feilen. Einem Nutzer, für dessen Betriebssystem keine neuere Version des genutzten Browsers verfügbar ist, würde der Hinweis in dieser Form z.B. nicht helfen. Gestumblindi 21:21, 20. Aug. 2012 (CEST)

Die technische und inhaltliche Umsetzung darf natürlich gerne anders aussehen, frei nach dem Motto "Sei mutig", ich hab das gestern nur mal auf die schnelle so geschrieben. Grüße --Jogo.obb (Diskussion) 14:49, 21. Aug. 2012 (CEST)

Bitte nicht auch noch solche Gängelung auf Wikipedia. Dieser Warnhinweis nervt jetzt bereits auf vielen Internetseiten. Dank Mozillas Update-Politik bekommt man den Hinweis ständig zu sehen. Abgesehen davon, dass er auf vielen Seiten auftaucht, wenn man gerade erst geupdatet hat und die Seite selber noch eine niedrigere Versionsnummer erwartet, ebenso seh ich diese Warnmeldung ständig auf Arbeit, wo FF als Beta schon immer installiert wird. <Sarkasmus>Nicht zu vergessen, dass wenn man länger als 30min bei Wikipedia ist, der Bildschirm sich für 10min abdunkelt und der Hinweis kommt "Bitte schützen Sie ihre Augen - sie sitzen zu lange vorm PC"</Sarkasmus>. -- Quedel ^Disk 18:33, 1. Sep. 2012 (CEST)

Es geht nicht darum irgendjemand mit halbwegs modernem Browser zugängeln, das ganze müsste so umgesetzt werden, das wirklich nur sehr alte Browser wie z.B. IE 6 oder FF 3.5 gewarnt werden. Grüße --Jogo.obb (Diskussion) 10:58, 2. Sep. 2012 (CEST)

Hallo! Was genau auf/von WP geht nicht mit solch alten Browsern? Mich nerven eher die Seiten, die immer den modernsten Schnickschnack brauchen... Im Sinne des Schwerpunkts auf Wissensvermittlung und einer möglichst weiten Verfügbarkeit (auch Barrierefreiheit usw...) sollte IMHO(!) WP also keine zu hohen Standards verlangen = und dann braucht WP IMHO(!) auch keine Versionenwarnungen usw... --kai.pedia (Diskussion) 13:55, 2. Sep. 2012 (CEST)

1. Beim reinen Ansehen von Artikeln gibt es eigentlich keine wesentlichen Einbußen.
   • Manche fortgeschrittenen Features sind halt nicht verfügbar, etwa „animierte SVG“.
   • Gelegentlich gibt es kleine Mängel in optischen Details; wer eine Tabelle oder Vorlage gestaltet und die Konstruktion mit seinem aktuellen Browser sorgfältig prüft, kann nicht wissen, dass etwas von alten Browsern nicht richtig dargestellt wird. Hier ein Beispiel aus jüngerer Zeit; es ließ sich lösen, wenn man darauf aufmerksam gemacht wird.
2. Das Bearbeiten kann in manchen Situationen problematisch sein; es gab wohl mit dem IE6 mal Schwierigkeiten bei Wikitext mit mehr als 32 kB.
3. Manche Gadgets mit fortgeschrittenen Funktionen unterstützen alte Browser wohl nicht, und können das auch nicht. Wer sich fortgeschrittener Funktionen bedient, hat meist auch halbwegs aktuelles Werkzeug installiert.
4. Ernsthafte Sicherheitsprobleme gibt es für das Wiki nicht; zumindest wenn man kein Admin ist. Sicher ist das Online-Banking mit einem alten Browser riskant; aber darauf möge das Geldinstitut aufmerksam machen.

Kurzum: Ich sehe keinerlei Notwendigkeit für allgemeine Belehrungen; insbesondere nicht für das reine Lesen. Wer irgendwo in unserer weltweiten Leserschaft einen alten Browser hat, kann möglicherweise nichts daran ändern; sei es aus technisch-organisatorischen Gründen, sei es weil man sich sowas im Alter nicht mehr antun möchte oder nur alte Hardware hat.

LG --PerfektesChaos 14:25, 2. Sep. 2012 (CEST)

sehe ich genauso --kai.pedia (Diskussion) 16:06, 2. Sep. 2012 (CEST)

Weiternutzung erleichtern

Unter jedem Artikel (ganz unten) sollte neben den Links "Datenschutz", "Über Wikipedia", "Impressum", "Mobile Ansicht" ein weiterer Link "Weiternutzung" (oder ähnlicher Titel) hinzugefügt werden. Dieser neue Link führt auf eine Kopiervorlage gemäß Wikipedia:Weiternutzung#Beispiel für eine Artikelnutzung mit den Daten des zugehörigen Artikels. Einziges Problem ist der Link "GNU-Lizenz für freie Dokumentation", der auf den Server des Weiternutzers zeigen muss. (Hier müsste ein auffälliger Dummyeintrag den Weiternutzer zu einem korrekten Eintrag zwingen). --tsor (Diskussion) 18:59, 30. Aug. 2012 (CEST)

Prima Idee, die sicher einiges bewirken könnte in Sachen korrekter Weiternutzung. Da allerdings über der Kopiervorlage auch einiges an erklärendem Text und dort zudem noch Hilfetext in Bezug auf weitere Möglichkeiten der Weiternutzung von Wikipedia-Inhalten zu finden sind, wäre evtl. auch ein allgemeiner Link nach Wikipedia:Weiternutzung angebracht. Gruß -- Ra'ike ^Disk. _LKU ^WPMin 21:40, 30. Aug. 2012 (CEST)

Das könnte auch in MediaWiki:Cite text eingebaut werden. Danach müsste man eventuell noch MediaWiki:Cite article link ändern. Damit stünde es in der Seitenleiste, wo es sicher auch nicht verkehrt ist. --Schnark 09:19, 31. Aug. 2012 (CEST)

Wenn man es Weiternutzern einfach machen möchte, kickt man die GFDL einfach raus. Wer die GFDL wirklich braucht, dem ist mit einem einfachen Link eh nicht geholfen. Nacktaffe (aka syrcro) 11:21, 31. Aug. 2012 (CEST)

Ich weiß nicht, inwieweit das bei mir durch PDDs Script kommt, aber bei mir steht links (Monobook) im ANR die Schaltfläche "Seite Zitieren" die auf (beispielsweise) http://de.wikipedia.org/w/index.php?title=Spezial:Zitierhilfe&page=Wikipedia&id=107495204 weiterleitet. Hier sollte man evtl. ähnliches schaffen über Spezial:Weiternutzung. -- Quedel ^Disk 18:29, 1. Sep. 2012 (CEST)

Auch ich würde einen Link auf WP:Weiternutzung sehr begrüßen, am liebsten in der Fußzeile ergänzend zu den Lizenzinformationen, notfalls in der seitlichen Navigation (da geht's aber schneller unter). Den langen Text in den offiziellen Nutzungsbedingungen kann man m.E. niemandem ernstlich ohne weitere Hilfestellung zumuten.

@Quedel: "Seite zitieren" seh ich nirgends.

@Syrcro: Wo soll die GFDL raus? --Martina _Disk. 00:12, 3. Sep. 2012 (CEST)

"Seite zitieren" steht bei Artikeln unter "Werkzeuge" in der Seitenspalte. Das habe ich auch schon geschrieben, nur im Gegensatz zu Quedel nicht aus der Sicht des Anwenders, sondern aus der Sicht desjenigen, der den Vorschlag umsetzten möchte. --Schnark 09:23, 3. Sep. 2012 (CEST)

Bei mir steht das da nicht. --Martina _Disk. 00:33, 4. Sep. 2012 (CEST)

Suchhilfe erleichtern

Verschoben von Wikipedia:Fragen von Neulingen. XenonX3 - (☎:✉) 20:26, 3. Sep. 2012 (CEST) Sehr geehrtes Wikipedia-Team,

ich habe eine Frage bezüglich der Suchhilfe in Wiki oder auch wenn man den gesuchten Begriff in Google eingibt. Nach Eingabe des Begriffes erscheint sofort die passende Artikelzeile aus dem Wiki-Artikel, wenn man nun jedoch auf den Artikel klickt kommt man auf die generelle eite des Artikels und nicht zur gesuchten Stelle, die ja vorher auch bei Google oder bei der Wiki-Suchmaschine angegeben wurde. Es wäre sehr hilfreich, wenn Sie es einrichten könnten, dass die gesuchte und angezeigte Stelle im Artikel dann entweder farbig markiert oder man sofort dort hingeleitet wird. Das würde die Durchsuchung des kompletten Artikels erleichtern, Vielen Dank im Voraus

Sonst find ich Wiki einfach klasse!!!

--89.183.81.208 19:41, 3. Sep. 2012 (CEST)

Freut mich, wenn dir Wiki gefällt.

Dein Vorschlag gefällt mir auch.

1. Ich habe mal eine Spezifikation für ein JavaScript-Gadget geschrieben, mit dem wir das mit überschaubarem Aufwand hier in der deutschsprachigen Wikipedia realisieren könnten. Ein Programmierer müsste sich noch finden, der das Skript schreibt.
2. Irgendwann könnte das weltweit von unseren Servern unterstützt werden. Das zieht sich aber mit Sicherheit etwas.
3. Da Google gern die Wikipedia verlinkt, kann es sogar sein, dass eines Tages Suchmaschinen von einer funktionstüchtigen Schnittstelle Gebrauch machen würden. Aber ob das noch in diesem Jahrzehnt passiert?

Liebe Grüße --PerfektesChaos 23:53, 4. Sep. 2012 (CEST)

Such-Buttons wahlweise in neuem Tab

Ich vermisse schon lange eine Möglichkeit: Wenn ich auf einer Wikipedia-Seite bin und dann etwas nachschlagen möchte, ohne die Seite zu verlassen, wäre mein intuitiver Weg so: ich gebe den gesuchten Begriff im Suchfeld ein und mache dann statt eines Linksklicks auf einen der Buttons "Artikel" oder "Volltext" einen Rechtsklick auf den Button. Dann sollte -- wie bei gewöhnlichen Links -- ein Kontextmenü aufgehen, wo ich auswählen kann "Link in neuem Tab öffnen". Alternativ, oder als zusätzliche Lösung, wäre es praktisch, wenn die Suchergebnisseite dann in einem neuen Tab geöffnet wird, wenn die Strg-Taste gedrückt wird, während der Button angeklickt wird. Kurzum, es wäre schön, wenn die Such-Buttons "Artikel" und "Volltext" sich mehr wie normale Links verhielten. --Neitram 09:40, 4. Sep. 2012 (CEST)

In Bug 21167 wird vorgeschlagen, dass die Suchvorschläge normale Links sind, damit sie in einem neuen Tab geöffnet werden können. --Fomafix (Diskussion) 09:51, 4. Sep. 2012 (CEST)

Ja, genau. Und zusätzlich wäre das eben auch für die beiden Buttons wünschenswert. --Neitram 12:16, 4. Sep. 2012 (CEST)

Mit den beiden Buttons „Artikel“ und „Volltext“ meinst Du vermutlich den Skin Monobook. Beim Skin Vector sind die Funktionen bereits statt mit Buttons mit div und span realisiert. Auch hier muss genauso wie bei den Suchvorschlägen ein a hinzugefügt werden, damit die Knöpfe auch in einem neuen Tab geöffnet werden können. --Fomafix (Diskussion) 13:17, 4. Sep. 2012 (CEST)

Richtig, ich beziehe mich auf den Skin Monobook. Es betrifft aber außerdem auch alle anderen Skins außer Vector. --Neitram 16:37, 4. Sep. 2012 (CEST)

Stimmt! Das Problem hatte ich auch immer - mir ist es nur bis jetzt nicht aufgefallen ;-) Ich hab immer erst nen neuen Tab gemacht und dann gesucht (total umständlich!). Grüße — Alleskoenner (Diskussion) 06:28, 8. Sep. 2012 (CEST)

<nocategory>

Ist es technisch möglich, angelehnt an das <nowiki> einen bestimmten Textausschnitt von der Kategorisierung auszuschließen? Das würde sich nämlich zur Präsentation einer Vorlage lohnen, ohne dass die in dieser enthaltenen Kategorien auf den Artikel angewandt werden. Bspw. auf der Seite Wikipedia:ATB stört es, dass Vorlagen, die hier nur der Präsentation dienen sollen, automatisch die Seite kategorisieren. Wenn man nun die Vorlageneinbindung von der Kategorisierung ausschließen könnte (bspw. so: <nocategory>{{Neutralität}}</nocategory>), würde man es sich ersparen, bei jeder Änderung der Vorlage den gesamten Quelltext überarbeiten zu müssen. Ein weiteres Beispiel wären Diskussionen über Vorlagen: mit dieser Funktion könnte man Vorlagen beispielhaft in die Diskussion einbinden, ohne dass jedoch die Seite kategorisiert wird. Grüße — Alleskoenner (Diskussion) 15:04, 8. Sep. 2012 (CEST)

nö, Derartiges gibt es nicht. Aber man kann die automatische Kategorisierung namensraum- oder parameterabhängig bauen. -- ✓ ^Bergi 20:04, 8. Sep. 2012 (CEST)

Ich weiß. Deshalb frage ich ja, ob man das entwickeln könnte ;-) Das mit der NR-abhängigen Programmierung weiß ich, aber leider ist das nunmal nicht überall (bzw. fast nirgends) umgesetzt. Grüße — Alleskoenner (Diskussion) 20:37, 8. Sep. 2012 (CEST)

Interaktiver Bildbetrachter

In der Vorlage:Panorama gibt es einen sog. "Interaktiven Bildbetrachter", der mir sehr gefällt. Warum wird dieser Link nicht automatisch in jedes thumb-Bild eingebunden? Grüße — Alleskoenner (Diskussion) 18:06, 15. Okt. 2012 (CEST)

Der „Interaktive Bildbetrachter“ ist ein externes Tool auf dem Toolserver, das von der Vorlage:Panorama nur verlinkt wird. Dieser Bildbetrachter ist nur bei richtig großen Bilder sinnvoll. Bei kleinen Bildern ist ein normales Laden schneller und einfacher. Mit Vorlagenprogrammierung lässt sich die Größe eines Bildes nicht ermitteln. Daher lässt sich mit Vorlagenprogrammierung keine Einschränkung über die Bildgröße machen. Auf Commons sind alle großen Bilder über das Gadget commons:MediaWiki:Gadget-ZoomViewer.js mit dem „Interaktiven Bildbetrachter“ (dort ZoomViewer genannt) verlinkt. Da jedes Bild von Commons mit der Seite von Commons verlinkt ist, lässt sich der „Interaktive Bildbetrachter“ bereits darüber aufrufen. Das ist meiner Meinung nach ausreichend. --Fomafix (Diskussion) 20:08, 15. Okt. 2012 (CEST)

Ergonomie im Bearbeitungsfenster

Ich möchte die Ergonomie im Bearbeitungsfenster ansprechen und habe da schon eine Diskussion eröffnet.

Wikipedia:Projektdiskussion/Ergonomie im Bearbeitungsfenster

Wo schlägt man so eine Änderung vor? --Ohrnwuzler (Diskussion) 01:32, 16. Okt. 2012 (CEST)

Byte-Änderungen neu durchzählen

Ich würde mir ein Feature wünschen, mit dessen Hilfe man die Byte-Änderungen, die in der Versionsgeschichte bei jedem Edit angezeigt werden, neu durchzählen kann. Schaut man sich die Versionsgeschichte von Richard Price (Philosoph), gibt es dort zig Edits, wo dransteht "+ 20.000", obwohl nur wenige Bytes hinzugefügt oder sogar welche entfernt wurden. Das resultiert vermutlich aus dem Import. Würde die Software jedenfalls neu durchzählen, stünden dort nach dem Refresh die korrekten Byteangaben. 213.54.43.16 22:29, 26. Okt. 2012 (CEST)

Ähm* ich glaube nicht. Das sieht eher nach einem üblen Bug aus. Aber keine Ahnung ob der schon bekannt ist. -- ΠЄΡΉΛΙʘ 18:45, 31. Okt. 2012 (CET)

Das passiert bei Imports, weil sie die falsche Basis haben (die falsche Eltern-Versionsnummer), siehe Bug 36976. Der Umherirrende 18:55, 9. Nov. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: ΠЄΡΉΛΙΟ 01:16, 15. Nov. 2012 (CET)

Neuer Button [[...]]

Beim Drücken vom Button #WEITERLEITUNG [[Name der Zielseite]]
Warum erscheint da nicht nur [[....]]?
Wäre es nicht sinnvoll, noch einen Button
"Einfügen" [[.....]]
einzuführen, da man ja eh die Maus in der Hand hat? Spart ebenfalls viel Arbeit!!! --Frze (Diskussion) 18:23, 31. Okt. 2012 (CET)

Wie meinen? Was in möchtest Du genau? Tiefe Verneigung vor dem der das nach zweimaligen Lesen verstanden hat.Vorlage:Smiley/Wartung/8p  -- ΠЄΡΉΛΙʘ 18:50, 31. Okt. 2012 (CET)

Ich will nicht vier mal

 AltGr+8 AltGr+8 AltGr+9 AltGr+9

drücken müssen - sondern einen einzigen Button, der so aussieht

[[...]]

Mit Maustaste links in der erweiterten Bearbeitungswerkzeugleiste. Besser verständlich? Somit erschiene dann [[.............]] und, weil man ja eh was einfügt, ist das mit drei Mausklicks getan und nicht mit vier mal Doppeltasten u n d drei Mausklicks. Aus der Rationalisierung grüßt --Frze (Diskussion) 19:31, 31. Okt. 2012 (CET)

Hallo Frze, hast du schonmal auf das vierte Symbol geklickt, das aussieht wie drei Kettenglieder, dann Text eingetippt und die Eingabetaste betätigt? Das sollte zum Erzeugen eines Links genau das erfüllen, was du dir wünschst. --Wiegels „…“ 19:50, 31. Okt. 2012 (CET)

... was es nicht alles so gibt ... erfährt man nach 534 Tagen wikipedia ... DANKESCHÖN! --Frze (Diskussion) 20:11, 31. Okt. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: ΠЄΡΉΛΙΟ 01:05, 15. Nov. 2012 (CET)

Spezial:Letzte Änderungen, etc. als wirkliche Tabelle anzeigen wäre viel übersichtlicher!!

nimmt das mal jemand in Angriff? Ich meine: schaut euch Spezial:Neue_Seiten an, das ist im Moment sooo unübersichtlich, hätte man da durch eine Tabelle eine klare Struktur, würde man sich sehr viel leichter tun einen Überblick zu bekommen. Und dann bitte gleich global freischalten..., das betrifft alle--92.205.56.224 18:14, 25. Sep. 2012 (CEST)

+1. Und dann bitte auch für die Beobachtungsliste. Grüße — Alleskoenner (Diskussion) 20:08, 25. Sep. 2012 (CEST)

Die Forderung aufzustellen ist etwas billig. Man muss schon sagen wieviele Spalte es geben soll, wie die Spalten heissen und was sie beinhalten sollten. Und dann macht mach einen Quicktest und formatiert eine Ausgabe (oder vieleicht auch mehrere) des derzeitigen Systems einmal um ... das Ergebnis bringt Überraschungen! -- 188.97.4.18 02:19, 26. Sep. 2012 (CEST)

Nagut, ich beschreibe die Idee etwas genauer: die Seitenbreite sollte an die Breite des Bildschirms angepasst bleiben. D.h. man muss in den Spalten entsprechende Zeilenumbrüche einfügen, damit die Seitenbreite nicht überschritten wird - das ist problemlos möglich, da die Länge der Seite flexibel ist. Eine Zeile sollte dann so breit sein, wie die breiteste Zelle der Zeile. Es sollte nun die Spalten für

1. das Datum
2. den Artikel
3. den Benutzer
4. und den Kommentar geben (wird die Zelle sein, in der man die Zeilenumbrüche einfügen muss)--92.205.34.36 11:13, 26. Sep. 2012 (CEST)

also ich finde die derzeitige Form recht übersichtlich und wenn, dann sollte in die Tabelle auf jeden Fall noch die Änderung der Größe mit rein --Jönd (Diskussion) 17:54, 26. Okt. 2012 (CEST)

E-Mail-Vorlagen in weiteren Sprachen

• Für Russisch erledigt: [[ru:Википедия:Примеры запросов на получение разрешения]] added aufCommons:Emailvorlagen --Frze (Diskussion) 08:40, 12. Nov. 2012 (CET)

Den nachstehenden Vorschlag habe ich von HD:F hierher kopiert; er scheint mir hier am richtigen Ort und in guter Gesellschaft. Zusammengefasst geht es offenbar um den Wunsch, dass Wikipedia:Textvorlagen prominenter verlinkt werden soll. --PerfektesChaos 20:07, 5. Nov. 2012 (CET)

Nicht prominenter - einfach fachlich-sachlich-komplett-richtig. Habe eben etwas lange gebraucht, die russische Vorlage zu erreichen. Damit es anderen nicht auch so geht, bitte linksseitig alle vorhandenen Sprachversionen verlinken. Danke --Frze (Diskussion) 20:20, 5. Nov. 2012 (CET)

E-Mail-Vorlagen ru
SgDH nach einigem Suchen bin ich auf die russische Vorlage gestoßen. In der deutschen Wikimedia commons sind diese (links in der Werkzeugleiste) nur für

   Български
   Deutsch
   English
   Français
   Polski
   Svenska

sichtbar verlinkt. Bitte ergänzen Sie die Vorlagenverlinkung in der deutschen Version zu den noch möglichen Sprachen. "На других языках"

   العربية
   Česky
   Español
   Magyar
   Italiano
   Bahasa Melayu
   Português

Русский

   Slovenčina
   Српски / srpski
   Українська

Spasibo wam bolschoje. --Frze (talk) 01:34, 3 November 2012 (UTC)

Dass alle Sprachversionen verfügbar sind im Seitenkopf

entdeckte ich erst nach meinem Umweg über die Български Version. --Frze (talk) 05:33, 3 November 2012 (UTC)

Spezialseite statt Toolserver - Geohack

Im Schwesterprojekt Wikivoyage funktioniert das Koordinatentool mit einer Media-Wiki-Spezialseite (Beispiel), während wir hier auf den Toolserver zurückgreifen müssen (Beispiel). Es kann doch wohl nicht so schwer sein, die gleiche Spezialseite auch auf de:wp zu platzieren. Das wäre jedenfalls sinnvoll, damit man in dem Fall nicht mehr auf den gerne ausfallenden Toolserver angewiesen ist. Steak 22:15, 11. Nov. 2012 (CET)

Stimme dir voll zu. Angesichts der Tatsache, dass wir inzwischen sogar ganz unten am Ende jedes Artikels ("Abrufstatistik") auf den Toolserver verweisen, fände ich es nun, da diese Funktionen offensichtlich nicht mehr nur für Wikipedianer gedacht zu sein scheinen, inzwischen ganz angebracht diese im SNR anzusiedeln (auch wenn die eigentliche Arbeit meinetwegen weiterhin der Toolserver erledigt, aber IMHO find ichs unschön dafür immer auf nen externen Weblink zu verweisen). Übrigens ergäbe sich daraus auch die Möglichkeit, Toolserver-Informationen künftig per {{Vorlage}} einzubinden (das geht im Moment noch nicht, da die Seite sich nicht innerhalb der WP befindet). Grüße — Alleskoenner (Diskussion) 22:42, 11. Nov. 2012 (CET)

Nach mw:Extension:MapSources zu urteilen, ist das noch Beta, gibt es also noch nicht so lange (16. Oktober) und ist in der Testphase. Daher denke ich, das es auch mal hier aktiviert werden könnte. Der Umherirrende 17:52, 12. Nov. 2012 (CET)

bg, wiki Werkzeugleiste

Liebe Programmierer, auf der bulgarischen Bearbeiten-Seite entdeckte ich die wunderbare WERKZEUGERGÄNZUNGS-LEISTE, die sich selbst erklärt und alle Vorlagen (Infoboxen, Kategorien, Schablonen, Tabellen etc. pp.) enthält, so auch den von mir vor drei Tagen gewünschten [[]]-Button. Ich finde, diese Ergänzung vereinfacht die Arbeit für bg.wikipedianer immens. Nur als Anregung für Euch; diese oder eine abgewandelte Variante ließe sich doch auch für de.wikipedia einarbeiten. Würd mich und zig weitere, insbesondere Neulinge, freuen, eine Verbesserung der Nutzeroberfläche zu bekommen. Danke - --Frze (Diskussion) 19:50, 3. Nov. 2012 (CET)

Alles drin, was das Herz begehrt...

 Pro »dafür« -- ΠЄΡΉΛΙʘ 01:22, 15. Nov. 2012 (CET)

Anzeige Miniaturansicht auf commons Kategorien Unterkategorien analog Windows-Explorer...

...mit Ansichtswahloption. Würde den Faktor Komfortabilität potenzieren. Nur als Anregung. --Frze (Diskussion) 09:10, 7. Nov. 2012 (CET)

+1. Grüße — Alleskoenner (Diskussion) 23:43, 10. Nov. 2012 (CET)

Vielen Dank! --Frze

 Pro »dafür« -- ΠЄΡΉΛΙʘ 01:27, 15. Nov. 2012 (CET)

Kleines Dankeschön an IPs

Ich fände eine Funktion sinnvoll, mit welcher man IP-Benutzern, die Tippfehler oder andere Fehler ausbessern, schnell und einfach per Knopfdruck danken und sie so vielleicht zur zukünftigen vermehrten Mitarbeit anregen könnte. Ich stelle es mir ein bisschen wie WikiLove light vor. Eine Integration dieser Funktion in Huggle und ähnliche Werkzeuge (als Gegenstück zu Warnungen) wäre zu überlegen. --Leyo 20:51, 19. Sep. 2012 (CEST)

WikiLob?

statt WikiLove?

Ich finde das einen wichtigen und sinnvollen Vorschlag, und nicht nur für IPs! Auch für Neulinge und noch-nicht-Sichter wäre es toll, etwas mehr positives Feedback zu bekommen (ok, eigentlich für alle Benutzer ;-). Einfach gelegentlich mal eine "warme Dusche" statt immer nur den "kalten Guss", was man alles noch nicht kann, weiß, falsch macht. Gerade bei IPs wäre es wichtig, schnell eine Nachricht zu schicken - da soll ja ein Zeitfenster von ca. 30 Minuten bestehen, in denen man die Leute noch erwischt (ich erinnere mich leider nicht mehr, welche Tests diese Ergebnisse ergaben). Und WikiLove ist ja schon eine bestehende Funktion, die man nur noch sinnvoll modifizieren müßte. Am WikiLove Design fände ich vor allem zwei Sachen veränderungsbedürftig:

1) Konzentration weg von den Bildern, Textnachricht sollte mindestens so wichtig sein, also gleich ein Texteingabefeld im Wikilove-Fenster anzeigen

2) Anbindung an Edits. Also Wikilove (oder Wikilob? Wikidanke?) für eine gute Bearbeitung ausdrücken, nicht für eine Person (wer ist das überhaupt? Erstmal recherchieren, ob man alle bisherigen Bearbeitungen gut findet? Ist jetzt WikiLove nicht doch etwas "too much"?) Vielleicht direkt aus der Versionsgeschichte oder aus der Sichtungsdiff einen Knopf "WikiDanke" zum drücken und (mit automatischem Mitverschicken des gelobten difflink?). Diese Idee, wie immer man das auch nennt (Editlove? ;-), ist übrigens nicht so neu, ich hab schon ein paar mal ähnliches gelesen:

• Eigentlich wäre es ja im Sinne der Motovation und des Lobes auch sinnvoll einzelne Edits zu Bewerten und somit dem Author ein direktes Feedback/Lob zukommen zu lassen. Aber wer sucht denn schon in der Versionsgeschichte raus, welcher Satz im Artikel von welchem Author stammt? Da sind wir wieder an dem Punkt wo sich die Ratte in den Schwanz beißt und man eigentlich die Authoren direkt Loben sollte. Aber das ist in jedem Falle in individueller Textform erbaulicher als wenn einem einer irgendwelche bunten bildchen auf die Disk knallt. -- Lord van Tasm «₪» 09:14, 29. Jun. 2011 (CEST) Wikipedia:Café/Archiv_2011_Q2#Love_-_Like_-_Lesenswert
• Ich würde sogar noch weitergehen. Das Lob des Lesers: o. k., schöne Sache. Aber Lob der anderen Wikipedianer ist gerade für die neueren Mitarbeiter und vor allem die fleissigen Verbesserer doch fast noch wichtiger. Mein Vorschlag: Ein "Gefällt mir"-Button an jedem einzelnen Edit, der in der Beobachtungsleiste erscheint. Und vor allem auch an jedem Bild. Wie man das versammelte Lob dann dem Gelobten präsentiert, ist zweitrangig (vielleicht per Spezialseite, nur für den Nutzer einsehbar). --FA2010 15:06, 14. Jul. 2011 (CEST) Wikipedia:Café/Archiv_2011_Q3#Gef.C3.A4llt_Dir_dieser_Artikel.3F_Dann_klicke_.5Bhier.5D._Zusammenfassung:_.5BF.C3.BCge_hier_Deine_.28kurze.29_Begr.C3.BCndung_ein..5D
• Christopher Wood says: I’d prefer if you could “love” a particular edit… but that would require a lot of design work to be effective - 2011/06/30 at 18:25 [5]
• "WikiThanks Button": I would love to give some love to an editor for a particular action. For example I would love to give a quick "thanks" to a revision directly inside the history of the page. For example, I made some changes yesterday on and someone corrected a typo error here by user Pom445. I would love to give him a quick "thank you" for that simple action. I think that the WikiLove button is great, but it's more something for big actions. In real life, using the "Wikilove" button for a syntax error would be like buying flowers for someone who picked up a coin you lost in the street. Sebculture‎15:41, 14 September 2011

+1 Helder‎16:40, 16 September 2011 [6]

• I agree. I have felt that I wanted to thank people, but a cookie or a barnstar is a bit much sometimes. I've also even had newbies I welcomed tell me they couldn't possibly deserve a welcome for their "minor" edits. Steven Walling (WMF) • talk‎18:48, 15 September 2011

This describes a feature I have wanted to build for a very, very long time - in fact, it's in the first drafts of my LiquidThreads designs. A simple "thanks" button. Something small. We could tie it to revisions. Maybe I'll pull up a design this weekend. Jorm (WMF)‎01:54, 16 September 2011

Errm… what's the problem about just saying "thanks" to the one? Kronf‎20:53, 26 September 2011

You mean just saying "thanks" on the discussion page ? First, the receiver of the "thanks" should quickly be able to know for what contributions he got the "thanks". Of course you could do everything by yourself by

   Visiting discussion page of the User
   Copy URL of his contribution
   Edit page / Create new section
   Write '"thanks" and paste contribution URL
   Save changes

But this would be way to long for a spontanious and quick "hey thanks". A quick "Thanks" button could automate this process, and thus give a fast, precise and satisfying feedback. "thanks" = "hey I saw your change, I validate it, I think it's improvement, and thank you for this !" Sebculture‎16:48, 27 September 2011

Yeah, this is closer to the logic I'm thinking about. Jorm (WMF)‎19:02, 27 September 2011 [7]

• WikiLike: To be clear, I am suggesting a like button on our watchlists - nothing more or less. (...) I am talking about a "Hey, nice editing work" button for wikipedians. I am trying to make more salient the worry that this is something perfectly in line with Wikipedia's goals lately (as we have seen by their implementation barnstar template systems for the same goal I am pursuing: increasing the sense of community among Wikipedians). It is a less radical suggestion that I have seen elsewhere here. Still, I need a little more meaningful engagement here.-Tesseract2(talk) 20:16, 12 December 2011 (UTC) [8]
• "Liking " others' edits: Oftentimes I come across edits where I think, "that's a really useful bit of editing". Little things like adding sources, tweaking grammar, tidying up section headers - gnomish things which all contribute to improving the encyclopedia, but aren't especially showy. Whilst we do have barnstars (and kittens, cookies and all sorts of other crap) to show approval for this sort of thing, sometimes that level of Wikilove seems excessive for individual edits. What would be nice would be a "Like" (or "Approve", or "Commend" or something else that doesn't make us look like Facebook) button, perhaps next to the button for "Undo", that appeared when an edit was viewed. Users could then show their approval for one another's more minor edits without having to slap a barnstar on their talkpage ("Thanks for deleting that one extraneous apostrophe! I hereby award you this award! Keep up the good work!"). It would also be motivating for new users to see that their edits were approved of - it can take a while to get positive feedback when you first start out (far easier to receive a warning template), and this would show newer users that their efforts were appreciated. Just a thought - second opinions solicited... Yunshui 雲‍水 14:52, 12 December 2011 (UTC)[9]

Eine Idee, die offensichtlich einiges für sich hat. Grüsse --Atlasowa (Diskussion) 00:36, 20. Sep. 2012 (CEST)

Ich habe übrigens nichts gegen die Bilder bei WikiLove, das ist nett. Das sollte nur nicht der Hauptzweck sein, und so erscheint es aber im Design:

• 
  The WikiLove dialog upon first load
• 
  The WikiLove dialog upon selecting an award category
• 
  The WikiLove dialog upon filling out details for an award
• 
  The WikiLove dialog in preview mode
• 
  The hover state for the award selection pane
• 
  Wikilove auf russisch [1]

Ich habe schon ein paar Mal "von Hand" eine Art WikiLove versendet, das ist ziemlich mühsam (siehe oben), aber die Reaktionen und Erfahrungen sind sehr, sehr positiv. Früher wurden noch viel öfter die Vorlage:Danke und Vorlage:Wikiliebe verwendet Wikipedia:Textbausteine/Benutzerseiten#Nette_Kleinigkeiten. Ich glaube inzwischen auch, dass das Wikipedia:Cafe nicht zuletzt deshalb eine der meistbesuchten Seiten ist, weil man dort auch mal nette Bilder "serviert" bekommt. Wir müssen ein kleines Danke oder kleines Lob viel einfacher machen, insbesondere für Unangemeldete und Neuangemeldete, aber eigentlich für alle. --Atlasowa (Diskussion) 09:30, 20. Sep. 2012 (CEST)

Auszug aus einer Versionsgeschichte: "Kommentarlos zurücksetzen" (Rollback), "Rückgängig" machen (mit Kommentar was alles falsch gemacht wurde), und bei ungesichtetem kann man auch noch "Änderungen verwerfen" - eine Menge negatives Feedback wird leicht gemacht. Aber mal "Gute Idee" sagen? Schwierig. Gesichtet wird kommentarlos:

Könnte man beim Sichten nicht auch noch die Möglichkeit haben, per WikiLob-Knopf kurz "Danke für Deine Verbesserung" zu sagen?

So (oder anders, Bilder wählbar) könnte das gesendete WikiLob aussehen:

Einfach mal ein kleines Dankeschön für Deinen Beitrag in Liste der Universitäten in Ghana... Gute Arbeit! :-) --Atlasowa (Diskussion) 11:11, 20. Sep. 2012 (CEST)

Vielen Dank für deine ausführliche Stellungnahme!

Ich würde es erstmal wirklich auf IPs beschränkten wollen, da dort die Ansprüche anders sind: Da muss es vor allem schnell gehen, damit eine realistische Chance besteht, dass die Person noch in der Wikipedia herumsurft und es noch liest. Daher gefällt mir dein Vorschlag unter 2), bei der Anzeige des Diffs einen Link für EditLove (oder WikiThanks?) zu ergänzen. Damit soll mittels 1–2 Klicks das Dankeschön auf der IP-Disk. (inkl. Difflink der verdanken Änderung) gepostet werden. --Leyo 13:04, 30. Sep. 2012 (CEST)

Ich begrüße gerne neue Nutzer und sage auch manchmal bei IPs „manuell“ danke. Die Erfahrungen sind meist positiv. Wir sollten zurückhaltend sein, wenn Herzchen, Plätzchen oder Blumensträuße verteilt werden. Diese Art von Auszeichnung mag hier zwar beste Tradition haben, allerdings ist sie IMHO auch etwas verschroben und passt nicht unbedingt zum Empfänger (manche Leute fühlen sich vom „du“ in meinem Begrüßungstext schon „verarscht“). Bei Automatisierung sollten wir immer meta:Research:The Rise and Decline und Geiger et al.: Defense Mechanism or Socialization Tactic? Improving Wikipedia’s Notifications to Rejected Contributors im Hinterkopf behalten: Die semi- oder vollautomatische Ansprache ist nicht immer geeignet (die Arbeiten gehen allerdings von einem anderen Setting aus). Parallel dazu müssen wir für schnelle Sichtung sorgen (häufige Frage: „Wo ist meine Änderung?“) und Zurücksetzen erklären (anstelle „Level-X“-Warnungen zu versenden). Grüße, --Polarlys (Diskussion) 14:46, 30. Sep. 2012 (CEST)

Sich manuell zu bedanken, ist – besonders bei neu angemeldeten Benutzern (daher meine Einschränkung auf IPs) – natürlich besser. Nur ist es so, dass man sich diese Zeit oft nicht nimmt. Und IMHO ist ein standardisiertes Dankeschön meist besser als gar keins. Es liesse sich bestimmt so formulieren, dass man um „du“ oder „Sie“ herumkommt. Wenn man die Änderung gerade gesichtet hat, könnte dies (also, dass die Änderung nun für alle sichtbar ist) auch erwähnt werden. --Leyo 15:20, 30. Sep. 2012 (CEST)

Ich denke, die Hauptarbeit wäre das Schreiben des entsprechenden Scripts/Gadgets, so dass in Artikeldiffs ein neuer Link ergänzt würde. Hauptpunkte wären wohl Bestimmen ob IP oder nicht, herauslesen des Diffs/Artikelnamens und Posten auf der IP-Diskussionsseite. --Leyo 14:02, 20. Okt. 2012 (CEST)

Ich wäre dafür mw:WikiLove zu verwenden nur halt einfach auf ein Dankeschön oder meinetwegen noch Auszeichnungen beschränken. Die Erweiterung lässt sich sicherlich entsprechend konfigurieren. Bitte keine Kätzchen, Blumen, Kekse. Auch en:Barnstars sind sehr regional auf die US-Ostküste beschränkt. Ich glaube das versteht hier keiner. Gruß Matthias (Diskussion) 16:37, 20. Okt. 2012 (CEST)

Für WikiLove sind einige Klicks notwendig. Der Vorschlag hier bezieht sich auf eine Einklicklösung ohne Auswahlmöglichkeiten. --Leyo 17:30, 20. Okt. 2012 (CEST)

Ich denke wir können beides haben :-) Siehe auch meine Beispiele/ Vorschläge unter Wikipedia:Technik/Skin/Werkstatt#WP:FR#Kleines Dankeschön an IPs. Grüsse --Atlasowa (Diskussion) 16:38, 29. Okt. 2012 (CET)

Das sehe ich auch so. --Leyo 10:48, 15. Nov. 2012 (CET)

Gut finde ich auch deine Idee "Wenn man die Änderung gerade gesichtet hat, könnte dies (also, dass die Änderung nun für alle sichtbar ist) auch erwähnt werden." Also ein automatischer Satz "Ich habe Deine Bearbeitung gesichtet, so daß diese jetzt für alle Leser sichtbar ist." oder so ähnlich, falls man aus der Sichtungsdiff Wikilob/Wikidank verschickt. Das hat Mehrwert :-) --Atlasowa (Diskussion) 19:24, 24. Nov. 2012 (CET)

Ich habe daraus diesen Use Case abgeleitet. --Leyo 22:55, 27. Nov. 2012 (CET)

Notizfunktion

Ich fände eine Notizfunktion sinnvoll, in der sich angemeldete Benutzer kleine Gedankenstützen machen könnten (z.B. in der Leiste zwischen Eigene Beiträge und Abmelden

MfG --Jönd (Diskussion) 17:51, 26. Okt. 2012 (CEST)

Habe die seit längerem kursierende Idee/Wunsch aufgegriffen; bzw. die Skin-Werkstatt wird sich dessen irgendwann mal annehmen und zur weltweiten Verwendung bringen.

Damit das auch so programmiert wird, wie du dir das wünscht:

• Würde es genügen, wenn diese Infos nur innerhalb des eigenen Rechners verfügbar wären? Die Tücke an bisherigen Wünschen war immer, dass der ganze Kram sonst jedes Mal einen Eintrag in der Versionsgeschichte hervorruft und du sonst 5678 Benutzerseiten-Edits hättest gegenüber einer dreistelligen Zahl im Artikel-Bereich.

Liebe Grüße --PerfektesChaos 18:14, 26. Okt. 2012 (CEST)

es würde mir auch reichen, wenn es nur auf meinem Computer verfügbar wäre. Danke für die Antwort --Jönd (Diskussion) 21:59, 6. Nov. 2012 (CET)

Okay, wenn ich oder jemand anders es irgendwann fertig bekommen sollte, laden wir dich als Beta-Tester ein. Liebe Grüße --PerfektesChaos 22:04, 6. Nov. 2012 (CET)

Danke, sehr nett. --Jönd (Diskussion) 17:18, 7. Nov. 2012 (CET)

Hm, also ich finde, sowas ist nichts, wofür es eine eigene Funktion geben braucht. Jeder kann eine BNR-Unterseite anlegen, auf der er Notizen machen kann. Ansonsten rate ich zu "Offline-Notizen": Man muss ja nun wirklich nicht alles online (und öffentlich einsehbar) speichern, zumal das alles auch Speicherkapazität kostet. Grüße — Alleskoenner (Diskussion) 18:15, 29. Nov. 2012 (CET) PS: Es gibt übrigens auch noch sowas altmodisches wie "Notizzettel" ;-)

Wir reden hier natürlich von einer intelligenten Notizfunktion, die einen genau dann an offene Fragen erinnert, wenn man auf eine Seite kommt, zu der man sich eine Notiz gemacht hatte, beispielsweise durch den Import von Wartungslisten. Damit können dann alle Kleinigkeiten miterledigt werden, für die man nicht einzeln editieren wollte, und das entlastet die Versionsgeschichte der Seite.

Dass man solche Vorhaben nicht öffentlich speichern muss und die Versionsgeschichten seiner Benutzerseiten belasten braucht, hatte ich oben bereits angedeutet; siehe deshalb auch meine Rückfrage hinsichtlich lokalen Rechners.

VG --PerfektesChaos 21:11, 29. Nov. 2012 (CET)

Bausteine in Menüleiste

Ich fände es sehr sinnvoll, wenn in der Menüleiste auch Buttons für Bewertungs-Bausteine, wie z.B. QS, (S)LA, Belege untergrbracht wären, die bei einem Klcik den entsprechenden Quellcode in die Seite einfügen. Auf den Seiten der Qualitätssicherung könnte man das ja auch noch um ein erledigt ergänzen. --Jönd (Diskussion) 21:06, 15. Nov. 2012 (CET)

+1. Die wichtigsten (und am häufigsten benutzte Vorlagen) sollten direkt per Menüleiste eingebunden werden können. So könnte man übrigens auch die falsche Verwendung von Bausteinen verhindern, indem man zB Bausteine, die substituiert werden müssen, direkt mit subst: einfügen lässt. Grüße — Alleskoenner (Diskussion) 18:08, 29. Nov. 2012 (CET)

Es gibt unendlich viele Wünsche, sich die Werkzeugleisten zu gestalten; je nachdem, in welchem Bereich man tätig ist und was man braucht.

Andere Benutzer würden sich belästigt fühlen, wenn dort lauter Knöpfe stehen, die niemand braucht. Sie fänden dann vor lauter unbenötigten Knöpfen diejenigen nicht, die sie wirklich benötigen.

Deshalb ist weltweit ein ausgewähltes Standardsortiment vorgegeben.

Dieses kann sich jeder Benutzer individuell nach seinen Wünschen selbst zusammenstellen und erweitern.

Für die Leiste oberhalb des Bearbeitungsfeldes Anleitung unter mw:Extension:WikiEditor/Toolbar customization

Für das Werkzeug unterhalb des Bearbeitungsfeldes dies hier laden und selbst nach eigenen Vorlieben völlig frei konfigurieren.

VG --PerfektesChaos 21:03, 29. Nov. 2012 (CET)

Wikipedia article traffic statistics

Zu ...has been viewed 16037 times in the last 90 days... bitte eine Zahl Tagesdurchschnitt ergänzen. Danke --Frze (Diskussion) 00:15, 18. Nov. 2012 (CET)

Siehe http://stats.grok.se/about, du kannst dich direkt an den entsprechenden Benutzer wenden. Der Umherirrende 21:04, 30. Nov. 2012 (CET)

von Versionsunterschied einfach in zeitraumgleiche Versionsgeschichte wechseln

Wenn ich manchmal ältere Versionunterschiede/Bearbeitungen von einem Artikel anschaue, vermisse ich die Möglichkeit per Klick schnell in die Versiongeschichte des Zeitraums zu gelangen, in dem die entsprechende Bearbeitung stattgefunden hat.

Beispiel: im Artikel Praun wurde ein Bild entfernt. Ich frage mich, wann das eingefügt wurde und muss dann erst auf Versionen klicken, das Datum eintippen und den Monat auswählen. Sehr schön wäre es mittels eines einzigen Klicks direkt dorthin zu gelangen.

Da ich selbst das öfter brauche, mir aber vorstellen kann, dass es anderen überhaupt nicht so geht, wäre die beste Lösung natürlich ein Tool oder eine Ergänzung meiner monobook.js.

Wisst ihr da eine gute Lösung? -- Amtiss, SNAFU ? 16:41, 28. Nov. 2012 (CET)

Es gibt ein Helferlein revisionjumper welches dir hier vielleicht hilft/die Funktionalität abbildet. Der Umherirrende 20:58, 30. Nov. 2012 (CET)

Button "Änderung vorschlagen" bzw. "Sichtungspflicht"

Bestätigte Nutzer brauchen, wenn sie editieren, keine Sichtung mehr abwarten, damit ihre Änderungen im Artikel erscheinen. Doch warum nehmen wir bestätigten Nutzern die Möglichkeit, ihre Änderungen trotzdem freiwillig sichten zu lassen? Wenn sich nämlich ein Nutzer bei einer Änderung nicht ganz sicher ist und sie gerne gegengeprüft haben möchte, bevor sie öffentlich erscheint, könnte er sie so direkt im Artikel vorschlagen, aber ohne dass die Änderungen direkt jedem Benutzer angezeigt werden. Mir persönlich ist das aufgefallen, als ich etwas an einer komplexen Vorlage ändern wollte - die Änderung selbst ist schwer auf der Disk zu beschreiben und mögliche technische Fehler sind dabei völlig außen vor gelassen. Könnte ich aber auf einen Button neben "Seite speichern", "Vorschau anzeigen" und "Änderungen zeigen" namens "Änderung vorschlagen" klicken, könnte sich dies ein anderer Nutzer dann anschauen und ggf die Änderung freischalten, indem er sie sichtet (technisch wäre das also sozusagen ein freiwilliges Sichten-lassen). IMO hat Sichten nämlich nicht nur die Funktion, Vandalismus abzuwehren, sondern kann auch dazu dienen, Änderungen gegenzuprüfen.

Als eine weitere Möglichkeit dieses Systems schlage ich vor, dass es künftig neben Halb- und Vollsperre für Artikel auch noch die Möglichkeit "Verpflichtete Sichtung" gibt; bei besonders kritischen, oder in Edit-Wars umkämpften Artikeln würde man so IPs und/oder auch angemeldete Nutzer nicht einfach pauschal ganz vom Editieren abhalten, sondern dazu zwingen, ihre Änderungen erst gegensichten zu lassen, bevor sie veröffentlicht werden. Dies könnte bestimmt viele Edit-Wars unterbinden, da es dann nicht mehr ausreicht, immer wieder zu editieren, stattdessen muss der Autor (egal ob IP oder angemeldeter Nutzer) erst die Sichtung seiner Änderung abwarten. Diese dann durch einen Admin einschaltbare "Sichtungspflicht" könnte als Ersatz für die relativ rabiaten Sperren dienen, bei denen zwar Störungen ausgeschlossen werden, allerdings gleichzeitig auch jede andere Art von Änderung. Zudem fände ich es gut, wenn es dieses System auch als Sanktion gegen Nutzer gäbe, statt immer direkt eine Sperre zu verhängen: und zwar könnte man als "Strafe" vorübergehend die passiven Sichtungsrechte (also nicht gleich alle Schreibrechte) entziehen, wodurch der Nutzer für einen bestimmten Zeitraum seine Änderungen wieder erst sichten lassen muss.

Dieses Prinzip von gegenseitiger Kontrolle durch verpflichtetes Sichten für jederman würde bei Artikeln zu einer höheren Sicherheit vor Edit-Wars und Vandalismus führen, aber gleichzeitig nicht direkt jeden Nutzer vom editieren abhalten. Als "Strafe" für Nutzer könnte das System erreichen, dass zwar die passiven Sichtungsrechte entzogen werden und man Änderungen erst gegensichten lassen muss, der Nutzer aber weiterhin arbeiten darf und nicht völlig ausgeschlossen wird. Grüße — Alleskoenner (Diskussion) 19:57, 3. Dez. 2012 (CET)

Die Sichtungsfunktion dient ausschließlich der Abwehr von Vandalismus. Du kannst aber deine eigene Sichtung nach dem Speichern zurücknehmen. Besser wäre aber, du bespricht die Änderung und die Kontrolle mit der Vorlagenwerkstatt oder anderen. --Diwas (Diskussion) 21:55, 3. Dez. 2012 (CET)

Ja, bisher. Wie im ersten Teil meiner Anfrage geschrieben finde ich aber, dass jeder die Möglichkeit haben sollte, seine Sichtung zurückzunehmen. Offensichtlich geht das - das wusste ich nicht. Ich fände es trotzdem besser, das Sichtungs-System auch auf eine Art Review-System zu erweitern, indem man einen "Änderung vorschlagen"-Knopf einführt.

Viel wichtiger ist mir aber der zweite Punkt: Und dieser Punkt widerspricht auch nicht dem Prinzip, dass die Sichtungsfunktion ausschließlich der Abwehr von Vandalismus dient - ganz im Gegenteil; in der deutschen Wikipedia gibt es gegenüber Benutzern lediglich die Sanktion "Sperre" - hier schlage ich vor, ebenfalls die Möglichkeit "Automatisches Sichtungsrecht vorübergehend entziehen" als mögliche Sanktion einzuführen; der Autor darf weiterhin editieren, allerdings müssen seine Änderungen erst gesichtet werden. Und auch für Artikel ist dieses System sehr sinnvoll: Und zwar sollten die Schutzfunktionen eines Artikels differenzierter betrachtet und um eine weitere Möglichkeit ergänzt werden: Die "verpflichtete Sichtung". Hierbei handelt es sich um ein System, das in der englischen Wikipedia bereits existiert (es heißt dort Pending changes protection) - dabei wird für jeden Nutzer (egal ob IP, oder angemeldeter) eine Sichtung zur Freischaltung der Änderungen erforderlich. Das heißt, nicht mehr nur IPs müssen ihre Änderungen von einem Sichter bestätigen lassen, sondern auch alle angemeldeten Nutzer bis einschließlich des Autoreviewers. Das hat den Vorteil, dass alle Autoren den Artikel weiterhin bearbeiten können, dieser aber besser vor Vandalismus geschützt ist. In der englischen Wikipedia wird diese Art von Sperre, die einen Mittelweg zwischen Halb- und Vollsperre darstellt, vor allem für Artikel mit persistent hohem Vandalismus-Risiko und BLP-Artikeln eingesetzt, wodurch ein höherer Schutz gewährleistet, aber die Bearbeitung des Artikels nicht ganz ausgeschlossen wird. (Weiteres siehe auch unter en:Wikipedia:PP#Pending_changes_protection: dort wird dieses Prinzip noch in zwei Stufen unterteilt; die eine betrifft nur IPs und neue Nutzer, die andere alle bis Autoreviewer). Ich denke, wir sollten uns ernsthaft überlegen, dieses System ebenfalls einzuführen, da es sehr sinnvoll für die Vandalismus-Bekämpfung ist, aber die Bearbeitung eines Artikels dabei nicht ganz verhindert. Grüße — Alleskoenner (Diskussion) 23:49, 6. Dez. 2012 (CET)

To-Do-Liste für Artikel oder Portale

Dieses Feature aus der englischen Wikipedia finde ich sehr gut und sollte IMO auch hier übernommen werden: Dort ist es nämlich möglich, oben auf einer Artikeldiskussion eine "To-Do-Liste" einzufügen, auf der alle gewünschten Änderungen aufgelistet sind (siehe entsprechende Erläuterungsseite und Vorlage). Die Diskussionen zu den Wünschen und Änderungen finden natürlich weiterhin darunter auf der Disk statt, aber so hat man auch bei längeren Diskussionen noch einen Überblick darüber, was alles getan werden muss. Diese Funktion würde sich auch für Portale anbieten, die so direkt die wichtigsten To-Dos in ihrem Fachbereich auf einen Blick sehen könnten, bzw. die Mitarbeiter eine Liste haben, die sie abarbeiten können. Grüße — Alleskoenner (Diskussion) 18:02, 3. Dez. 2012 (CET)

Ist das nicht eigentlich sowieso leicht zu übernehmen, wenn man die Vorlage:Kasten (oder eine Ähnliche) verwendet und eine Liste reinschreibt? --BuschBohne 18:05, 3. Dez. 2012 (CET)

Klar, in dieser Weise (oder so ähnlich) würde das technisch natürlich auch am Schluss funktionieren, aber bisher gibt es ein solches System einfach noch nicht. Durch eine eigene Vorlage würde es sich besser einbürgern können. Würde ich auf einer Disk eine solche Liste einfügen, würden das vermutlich viele sofort für einen eigenen Kommentar halten, oder die Liste gem Wikipedia:DS nicht mehr verändern (weil ihnen das als Disk-Verfälschung erscheinen könnte). Die meisten Kästen, die es so gibt, könnte man theoretisch auch immer selber bauen, aber durch eine eigene Vorlage wird das ganze koordinierter und einheitlicher. Ich hatte mir auch überlegt, ob man das irgendwie mit dem bald freigeschalteten Artikel-Feedback-Tool verbinden könnte, aber das würde technisch sofort wieder relativ schwer werden (auch wenn ich es gut fände). Grüße — Alleskoenner (Diskussion) 18:14, 3. Dez. 2012 (CET)

Da fällt mir ein, solche To-Do-Listen werden jetzt schon als Unterseiten angelegt und dann auf der Portal-Seite verlinkt oder eingebunden. Eine eigene Vorlage dafür ist meiner Meinung unnötig, da Verheinheitlichung hier wirklich nicht notwendig ist.--BuschBohne 18:24, 3. Dez. 2012 (CET)

Ja, in manchen Portalen gibt es sowas ähnliches, aber in Artikeln (wo es am nötigsten wäre) bisher nicht. Grüße — Alleskoenner (Diskussion) 18:25, 3. Dez. 2012 (CET)

In Artikel-Disks gibst das auch schon, ganz ohne Vorlagen, z. B. Diskussion:Bart Simpson#To-Do-Liste. --BuschBohne 18:33, 3. Dez. 2012 (CET)

Ja, wie oben bereits gesagt: Das sollte man aber flächendeckend einführen. Grüße — Alleskoenner (Diskussion) 18:48, 3. Dez. 2012 (CET)

Dafür brauchts aber keine Vorlage --BuschBohne 14:28, 4. Dez. 2012 (CET)

Sondern? Grüße — Alleskoenner (Diskussion) 23:52, 6. Dez. 2012 (CET)

Man machts so wie bisher, und schreibt die To-Do-Liste ganz normal in die Artikeldisk.--BuschBohne 17:16, 7. Dez. 2012 (CET)

Rückgängig / Undo Button

Fall 1: Falschen Button galerie gedrückt
<gallery>
Datei:Beispiel.jpg|Beschreibung1
Datei:Beispiel.jpg|Beschreibung2
</gallery>
so - hier habe ich mich vertippt. Bin auf Einfügen>Bildergalerie geraten und wollte eigentlich Einfügen>Weiterleitung
[[....]]
Umständlich muss ich die ganze Sache wieder löschen.
Fall 2:
Ich habe etwas falsch gemacht (Bild oder link eingefügt, Rechtschreibfehler, Ihnhaltfehler).
Umständlich muss ich die ganze Sache wieder löschen.
Ganz simpel würde es gehen mit einem Button "Rückgängig":


--Frze (Diskussion) 17:37, 31. Okt. 2012 (CET)

Hallo Frze, hast du es schonmal mit der Tastenkombination Strg+Z probiert? Das erspart dir das umständliche Löschen, ohne dass du auf ein Symbol zielen musst. --Wiegels „…“ 17:49, 31. Okt. 2012 (CET)

Danke. Es gibt Leute, die arbeiten viel mit der Maus, Und Leute aus der Crash-Kurs-Rechner-Generation arbeiten vorrangig mit der rechten Maustaste. So ein Button hülfe viel. Aber die Wikipedia-Programmierer kennen ja alle Tastenkombinationen. Versetze man sich mal in die Lage Otto (Normalbenutzer) --Frze (Diskussion) 18:16, 31. Okt. 2012 (CET)

WORD, Excel, Powerpoint, AVS - ALLE haben diesen Button - nur wir nicht!
--Frze (Diskussion) 18:35, 31. Okt. 2012 (CET)

Ist der Button aus MS-Office nicht standardmäßig rausgeflogen? Wenn er noch da ist, dann steht STRG-Z im Tooltip, bzw. früher im Text des Menüpunkts, ist also kein Geheimwissen. Ich habe nichts gegen einen zusätzlichen Button einzuwenden, aber ganz ehrlich bin ich der Meinung, dass man sich die hilfreichsten Kombinationen – STRG-Z für Rückgängigmachen, STRG-Y für Wiederherstellen, STRG-C für Kopieren, STRG-V für Einfügen, vielleicht noch STRG-X für Ausschneiden und STRG-A für Alles markieren – aneignen sollte. Funktioniert bei sehr vielen Anwendungen und spart viel Zeit gerade auch bei Anwendungen, die man ohne Anleitung zum ersten Mal benutzt. --Diwas (Diskussion) 20:10, 31. Okt. 2012 (CET)

Vielen Dank - habe mir die Strg+ Funktionen angeeignet. --Frze (Diskussion) 20:27, 5. Nov. 2012 (CET)

 Pro »dafür« Generell keine schlechte Idee, auch im Angesicht, dass jetzt auch Undo per Tastenkürzel funzt (was nicht immer so war und immer noch nicht immer und bei allem), sind wie gesagt nicht alle Benutzer "Shortkey User". Ich selbst habe diesen Vorschlag vor über einem Jahr hier gemacht, der ohne Reaktion blieb. Dabei gibts diesen Button schon Jahre lang als Userscript (z.B. beim WikEd). -- ΠЄΡΉΛΙʘ 01:11, 15. Nov. 2012 (CET)

1+ Bin auch für die Idee. (Auch wenn die Möglichkeit durch Strg+Z natürlich schon besteht, aber das ist eigentlich kein Gegenargument). Grüße — Alleskoenner (Diskussion) 18:12, 29. Nov. 2012 (CET)

Mal eine Frage - Bei wem funktioniert das Rückgängig bei der Suche/Ersetzen Funktion des Vector-Skins? Bei mir nicht. -- ΠЄΡΉΛΙʘ 16:36, 17. Dez. 2012 (CET)

Mit STRG-Z kann ich einzeln (beginnend mit der letzten) jede Ersetzung (bis schließlich zur ersten) rückgängig machen. --Diwas (Diskussion) 17:41, 17. Dez. 2012 (CET)

Artikel Chronik

Hi, es wäre praktisch wenn es eine art Artikel Chronik geben würde, d.h. oft merke ich das ich von einem Artikel zum nächsten komme, und letztlich wieder zum Ausgangspunkt kommen möchte. Man könnte das z.B. durch eine Chronik sichtbar machen, welche chronologisch anzeigt, welche Artikel ich besucht habe.

hi, it would be useful, having something like an articel chronicle on top of the website, where you can see what articels u have visited chronologically, and switch between them-

if this suggestion is not usefull, just delete it. its just from an average user. so dont mind-

reagrds david (nicht signierter Beitrag von 92.77.167.44 (Diskussion) 13:51, 16. Dez. 2012 (CET))

Hi, dafür gibt es doch die 'zurück'-Funktion, die schrittweise (per Stack-Abbau) zum jeweils vorherigen Artikel zurückkehrt. Oder möchtest du dieses 'Unstacking' optional umgehen und gezielt auf frühere Einträge zurückspringen? --VÖRBY (Diskussion) 15:58, 17. Dez. 2012 (CET)

Löschungen bei Versionsabgleich besser erkennen

Wikipedia zeigt bei 'Änderungen anzeigen' (im Bearbeitungsmodus) oder bei 'Unterschied' in der Beobachtungsliste an, was geändert, hinzugefügt oder gelöscht wurde. Dies ist eine sehr nützliche Funktion - die allerdings nur bedingt funktioniert: Werden ganze Abschnitte gelöscht, so wird das nicht erkannt, sondern der Text, der anschließend an die gelöschten Zeilen folgt, wird rechts als 'neu' dargestellt, folgt aber auf der linken Seite im Anschluss an die gelöschten Textteile nochmal. Beispiel siehe [10]. Dies wäre grundsätzlich nicht schlimm, allerdings wird dadurch die Textvergleichsfunktion für diese Textteile nicht mehr ausgeführt - und man erkennt Änderungen darin nicht.

Der Algorithmus zur Feststellung von Änderungen synchronisiert beim Erkennen von Löschungen die beiden Artikelversionen nicht ~korrekt bzw. nicht leistungsfähig genug: Er müsste (im Beispiel) bei ungleichen Inhalten links einseitig weiter prüfen, ob dort die rechts erkannten Texte weiter unten wieder auftreten, dann alles was dazwischen liegt, als Löschung behandeln und danach wieder synchron mit dem Textvergleich weiterarbeiten.

Mir ist klar, dass das im Detail nicht so einfach ist. Aber vielleicht ist die Logik für diesen Algorithmus auch öffentlich verfügbar. Evtl. liegt auch nur ein kleiner Fehler vor, der diese Asynchronität bewirkt. Möglicherweise müssten die Textvergleiche lediglich auch über das 'Abschnittsende' von Texten hinaus erfolgen; bisher bricht der Vergleich hier ab und behandelt die beiden Seiten als unidentisch, links (im Beispiel) als gelöscht, rechts als neu. Grüße von --VÖRBY (Diskussion) 15:52, 17. Dez. 2012 (CET)

1.  Pro Auch hier haben Benutzer sich schon selber nach einer besseren Alternative gekümmert, z.B: Benutzer:Schnark/js/diff Dort sehe ich bei Deinem Link den entfernten Text direkt rot, dort wo er auch stand. -- ΠЄΡΉΛΙʘ 16:34, 17. Dez. 2012 (CET)

Danke, aber bei mir sieht dieser Unterschied noch genauso aus wie vorher: Rechts wird ein blauer Textblock (beginnend mit "Die übliche maximale Zeilenlänge ...") als NEU ausgewiesen, während dieser Text links weiter unten genauso steht und wie GELÖSCHT aussieht (rechts kein Text). Ditto für den nächsten Textblock ("In die Lochkarte ...").

Oder habe ich das Einbinden falsch gemacht? Im meinem Common.js habe ich - wie bei Schnark... unter "andere Benutzer" beschrieben - einfach die dort enthaltene eine Zeile eingefügt, dann den Cache geleert (muss man das nur 1x machen oder wann sonst?) und danach den 'Unterschied' für diesen Artikel wieder aufgerufen. Magst du bitte mal nachschauen, ich bin kein Technikfreek. Danke. --VÖRBY (Diskussion) 19:04, 17. Dez. 2012 (CET)

Die MediaWiki-Erweiterung die hier verwendet wird, ist mw:Extension:Wikidiff2. Diese Erweiterung bekommt Einfügungen wie oben beschrieben nur hin, wenn der nachfolgende Absatz unverändert bleibt, da aber das <br/> entfernt wurde, klappt das nicht und alles wird als Löschung/Einfügung erkannt. Wenn das Skript erfolgreich eingebunden ist, müsstes du unterhalb der Seitenüberschrift 3 Tabs/Reiter sehen, wo der zweite der Diff von Schnark ist. Der Umherirrende 19:21, 17. Dez. 2012 (CET)

ich kann leider mit Euren technischen Hinweisen inkl. den Links überhaupt nichts anfangen, ich verstehe die technischen Zusammenhänge nicht. Ich denke aber, SOOO wichtig ist das auch nicht, und wenn Wikipedia das nicht im Standard schafft, dann ist das halt so. Wenn schon, dann sollte diese Verbesserung ja für ALLE wirksam sein, für mich selbst könnte ich zB auch MS Word benutzen. Danke für eure Mühe. --VÖRBY (Diskussion) 23:06, 17. Dez. 2012 (CET), ergänzt: --VÖRBY (Diskussion) 09:11, 18. Dez. 2012 (CET)

Ja ich habe auch keine Ahnung was die Entwickler so alles machen, das scheinen irgendwelche Geister zu sein. Also nochmal zum Script von Schnark, die erwähnten 3 Tabs/Reiter vom Umherirrenden werden in der Beschreibung leider nicht gezeigt. Wie gesagt sind sie unten und oben links, auf das Dreieck klicken und dann erst wird das „verbesserte Diff“ aktiv. Deine Einbindung war schon richtig, sollte also da(gewesen) sein. -- ΠЄΡΉΛΙʘ 22:03, 18. Dez. 2012 (CET)

Danke nochmal. Sieht ja jetzt ganz ordentlich aus. Leider nur mithilfe von privaten Lösungen. Gelten damit solche VV's als nicht nötig? Das scheint mir ja mächtig 'open' (von OpenSource kommend, jeder macht was er will und kann ;-) zu sein. Gruß von --VÖRBY (Diskussion) 19:28, 19. Dez. 2012 (CET)

Favoritenliste

Ich fänd es sinnvoll, wenn man die Möglichkeit hätte, bestimmte Artikel zu persönlichen Listen hinzuzufügen. (Wenn das bereits geht, sagt mir bitte bescheid.) Beispiellisten wären etwa "Favoriten" oder "noch zu lesen". Das Interface ist allgemein recht stark auf die Autorenschaft ausgelegt und weniger auf die Leser, was man zum Teil auch verstehen kann. (Weniger ist mehr.) Aber an dieser Stelle würde das schon Sinn machen. Mir passiert es ziemlich oft, dass sich die Artikel in meinem Browser nur so stauen. Ausserdem könnte man so auch von anderen PCs auf die Bookmarks zugreifen. (Ja, das geht sicher auch über Alternativen, trotzdem ;)) --Sagehorn (Diskussion) 16:31, 14. Dez. 2012 (CET)

Sinnvoll ist es, sich auch als häufiger Nur-Nutzer anzumelden und ein eigenes Konto anzulegen. Dann kannst Du das Sternchen oben rechts zwischen Versionsgeschichte und Suchen anklicken und Dir eine Beobachtungsliste Deiner Favoriten anlegen, auf die Du jeder Zeit an jedem Ort zugreifen kannst. -- Frze (Diskussion) 18:29, 14. Dez. 2012 (CET) PS - seh grad, dass Du natürlich angemeldet bist... (Favoriten-)Beobachtungsliste dann alphabetisch geordnet ganz oben rechts zwischen Einstellungen und Beiträge. >>> auf Beobachtungsliste: Änderungen | normal bearbeiten | im Listenformat bearbeiten (Import/Export) gehen.

Die Idee einer „Leseliste“ ist nicht schlecht. Unsere „Beobachtungsliste“ fokussiert auf die Bedürfnisse von Mitarbeitern. Allerdings gibt es zahlreiche Hilfsmittel, die du für diesen Zweck in deinen Browser einbinden und auch außerhalb der Wikipedia und geräteübergreifend nutzen kannst. (Bspw. Pocket (früher Read-it-later) oder Instapaper). Viele Grüße, --Polarlys (Diskussion) 19:05, 14. Dez. 2012 (CET)

Ja, das wollte ich mit "stark auf die Autorenschaft ausgelegt" ausdrücken. ;) Die Beobachtungsliste kommt dafür m.E. nicht in Frage. Wie gesagt, Alternativen finden ist für mich kein Problem, aber letztlich ist es einfach "naheliegender", diese Links auch hier zu speichern. Anders gesagt: Ich möchte nicht extra solche Listen bei irgendwelchen Diensten starten, wenn ich ansonsten kein Interesse daran hab. --Sagehorn (Diskussion) 00:07, 26. Dez. 2012 (CET)

Siehe auch hier - ich unterstütze den Vorschlag. Grüße — Alleskoenner (Diskussion) 01:41, 26. Dez. 2012 (CET)

Zwischenspeichern von Bearbeitungen

Wenn ich einen Text bearbeite, pflege ich die Änderung in der Regel durch "Vorschau anzeigen" zu kontrollieren. Bei mehreren Bearbeitungen und Vorschau-Kontrollen, kann es dann sein, dass ich irgendwann mal Fehler mache, die sich händisch nicht so leicht rückgängig machen lassen. Den Zurück-Button vom Browser kann ich dazu leider auch nicht verwenden, da die Seite 'expired' ist. Dies zwingt mich sehr häufig bevor ich eine Seite in der Vorschau ansehe, ihn erst in die Zwischenablage zu nehmen.

Mein Vorschlag daher: Einen neuen Button "Letzte Bearbeitungs-Version" oder "Rückgängig machen", dort wo die anderen Buttons sind (Änderung übernehmen, Vorschau anzeigen,...). Sprich: Die letzte Bearbeitungsversion wird immer irgendwo/irgendwie gecached und man hat die Möglichkeit ungewollte Änderungen wieder rückgängig zu machen. --Nightwish62 (Diskussion) 01:46, 25. Dez. 2012 (CET)

Wenn du in deinen Bearbeiten-Einstellungen den Punkt "Vorschau sofort anzeigen" anklickst, wird das Editor-Fenster technisch vom Vorschau-Fenster "getrennt" - das heißt durch den Klick auf "Vorschau zeigen" wird nicht mehr die gesamte Seite neu geladen, sondern nur das Vorschau-Fenster. Dadurch kann man seine Änderungen auch nach einer Vorschau im Editor-Fenster mit Str+Z rückgängig machen. Grüße — Alleskoenner (Diskussion) 01:37, 26. Dez. 2012 (CET)

Danke für den Hinweis. Klappt aber leider nur im Chrome und nicht im IE mit dem ich normalerweise arbeite. Fände eine solche Funktion wie oben beschrieben dennoch sinnvoll. --Nightwish62 (Diskussion) 14:34, 26. Dez. 2012 (CET)

Vielleicht ist das was /localEdit. -- ΠЄΡΉΛΙʘ 17:09, 26. Dez. 2012 (CET)

CatScan als Spezialseite

Ich möchte, dass CatScan als Spezialseite ins Media-Wiki-Interface integriert wird. Neben Performance-Vorteilen wäre man nicht mehr vom Toolserver abhängig und könnte den Kategorienbaum deutlich entschlacken, weil man dann von Haus aus Schnittmengen bilden kann, ohne Notwendigkeit des bald abgeschalteten Toolservers. Steak 14:25, 28. Nov. 2012 (CET)

Die Toolserver-Funktionen sollten allgemein auf Spezialseiten überführt werden. Dies würde auch die Vorlageneinbindung der Daten ermöglichen und man würde nicht auf andere Seiten weitergeleitet werden müssen. Grüße — Alleskoenner (Diskussion) 18:06, 29. Nov. 2012 (CET) PS: Siehe auch #Spezialseite statt Toolserver - Geohack

Die MediaWiki Datenbank ist nicht für solche Katbaum-Anfragen designt. Sowas wird es nie direkt in Mediawiki geben, weil das live-DB-System dadurch viel zu stark belastet würde. Merlissimo 18:57, 3. Dez. 2012 (CET)

Nur weil man die Toolserver-Funktionen als Spezialseite anzeigt, heißt das ja nicht, dass man deshalb gleich die MediaWiki Datenbanken belasten muss. Warum kann man nicht im Hintergrund weiterhin auf den Toolserver zugreifen, aber die Oberfläche trotzdem in eine Spezialseite integrieren? Grüße — Alleskoenner (Diskussion) 19:06, 3. Dez. 2012 (CET)

Das würde die Abhängigkeit vom Toolserver überhaupt nicht verringern. 213.54.32.216 14:52, 15. Dez. 2012 (CET)

Siehe auch hier. Grüße — Alleskoenner (Diskussion) 01:24, 26. Dez. 2012 (CET)

was bedeutet das hier jetzt? ich wollte nämlich gerne den CatScan fest integriert haben im mediawiki, damit auch andere wikis mit mediawiki software die kategorien-suche (schnittmengen usw.) benutzen können. kommt das denn jetzt? --Kenji (Diskussion) 12:26, 29. Dez. 2012 (CET)

Nekrolog mit Formular

Hallo! Das Bearbeiten einer Seite wie Nekrolog 2012 ist umständlich, es muss die passende Zeile gefunden und dann die Tabellensyntax per copy & paste oder manuell eingefügt werden. Im Wiktionary (en) gibt es ein Skript, mit dem eine Tabelle an der richtigen Stelle mit Übersetzungen und Zusatzinformationen gefüllt werden kann (Editor.js). Kann jemand sowas für den Nekrolog umsetzen? Grüße, --Polarlys (Diskussion) 17:02, 29. Dez. 2012 (CET)

Zusammenfassung von Beiträgen eines einzelnen Benutzers

Hoffe ich bin hier richtig.

Hatte einen Artikel erstellt, musste ihn aber immer wieder bearbeiten. So entstand eine (mir auch peinliche) viel zu lange Versionsgeschichte, die nicht nur unübersichtlich ist, sondern auch unnütz Speicherplatz beanspruchen dürfte (denk ich)--->[11].

Meine Überlegung: Ev könnte man ja ein Tool in der Versionsgeschichte einbauen, mit dem man einzelne kleine Veränderungen (eines einzelnen Benutzers) zusammenziehen könnte, sodass aus zB. fünf kleinen Bearbeitungen dann am Ende nur eine Einzige wird.

Bsp. an dem link oben, da steht zur Zeit ganz am Anfang:

• (Aktuell | Vorherige) 02:46, 16. Nov. 2012‎ Eddgel (Diskussion | Beiträge)‎ K . . (9.435 Byte) (+2)‎ . . (→‎Handlung) (rückgängig) [automatisch gesichtet]
• (Aktuell | Vorherige) 02:37, 16. Nov. 2012‎ Eddgel (Diskussion | Beiträge)‎ K . . (9.433 Byte) (-17)‎ . . (rückgängig) [automatisch gesichtet]
• (Aktuell | Vorherige) 02:35, 16. Nov. 2012‎ Eddgel (Diskussion | Beiträge)‎ . . (9.450 Byte) (+21)‎ . . (→‎Handlung) (rückgängig) [automatisch gesichtet]
• (Aktuell | Vorherige) 23:24, 15. Nov. 2012‎ Eddgel (Diskussion | Beiträge)‎ . . (9.429 Byte) (+42)‎ . . (→‎Handlung) (rückgängig) [automatisch gesichtet]
• (Aktuell | Vorherige) 22:24, 15. Nov. 2012‎ Eddgel (Diskussion | Beiträge)‎ . . (9.387 Byte) (-15)‎ . . (→‎Handlung) (rückgängig)

So könnte der erste Beitrag zB. aussehen: X (Aktuell | Vorherige) 22:24, 15. Nov. 2012‎ Eddgel (Diskussion | Beiträge)‎ . . (9.387 Byte) (-15)‎ . . (→‎Handlung) (rückgängig)

X = Button durch dessen klicken, der Beitrag mit dem nächsten Beitrag des gleichen Benutzers vereint wird.

Am Ende sollte dann aus diesen fünf Bearbeitungen nur eine werden. Denke diese Idee könnte Speicherplatz sparen und die Versionsgeschichte übersichtlicher machen. Einziger Nachteil ist ev, dass es manuell getätigt werden müsste, aber ich zumindest wäre dazu bereit. Weis allerdings nicht ob das technisch möglich ist. Gruß--Eddgel (Diskussion) 08:23, 5. Dez. 2012 (CET)

→ MediaWiki Diskussion:Common.js#Funktion erstellt: History-Einträge zusammenfassen --Leyo 09:47, 5. Dez. 2012 (CET)

→ Benutzer:PerfektesChaos/js/resultListSort kann das auch übersichtlicher machen. Der Speicherplatz wird sowieso gebraucht; steht ohnehin in der Datenbank. --PerfektesChaos 21:27, 2. Jan. 2013 (CET)

URV-Hinweis bei jedem Edit wirklich nötig?

Ich halte den URV-Hinweisblock der bei jedem Edit erscheint für unnötig und hinderlich, was die Übersicht betrifft. Das editieren sollte so einfach und übersichtlich wie möglich gestaltet werden. Man kann erwarten, dass zum Beispiel Benutzer mit 50+ Edits den Hinweis häufig genug gesehen haben, um die Regel zu kennen. Sobald man nur schon einmal den "Vorschau anzeigen" Button geklickt hat, wird die Bearbeitungsseite in der Regel sehr lange, bestehend aus: Der Vorschau, dem Editor zur Bearbeitung, dem erwähnten URV-Hinweisblock, den eingebundenen Vorlagen.

Ich empfehle also eine Programmierung, welche den Hinweisblock ab einer bestimmten Anzahl Edits (für angemeldete Benutzer) automatisch entfernt oder gegen einen sehr dezenten Einzeiler austauscht. --Nightwish62 (Diskussion) 01:57, 25. Dez. 2012 (CET)

Es gibt auch Benutzer mit mehreren 1000 Edits, die sich der URV-Problematik noch nicht so wirklich bewusst sind... Wem der Hinweis stört, kann ihn übrigens für sich persönlich bereits jetzt per persönlicher css ausblenden. -- Chaddy · D – DÜP – 02:32, 25. Dez. 2012 (CET)

Und solche Benutzer lesen es beim 1001, 1002 und beim 5000 Edit immer noch nicht. Was mich stört ist die Verhältnismässigkeit. Wir können hier nichtmal von einer 80/20-Regel, sondern von einer über 95% Wahrscheinlichkeit reden, dass man nach 50 Edits den Hinweis irgendwann mal gelesen hat oder sonst nie mehr lesen wird. Aber genau wegen solchen Gegenargumenten habe ich bereits eingeräumt den Text auf einen Einzeiler auszuwechseln statt ganz zu entfernen. Ich Versuche hier eine Verbesserung für die Allgemeinheit zu schaffen, darum geht es mir nicht um irgendwelche Einstellungen an meinem persönlichen CSS. Danke trotzdem für den Hinweis der Möglichkeit. --Nightwish62 (Diskussion) 03:14, 25. Dez. 2012 (CET)

Inhaltlich kann ich i.W. zustimmen. Ergänzung: Den Einzeiler immer bringen - mit einer Möglichkeit, den vollen Text zu öffnen. Ist aber aus meiner Sicht Prio C, also weniger bedeutend. Zur Wirkung für die Allgemeinheit stimme ich Nightwish52 ebenfalls zu: Zu oft wird hier auf private, inoffizielle Möglichkeiten verwiesen. Eingereichte VVs sollten aber in einem definierten Prozess behandelt, priorisiert, präzisiert, zur Umsetzung vorschlagen oder abgelehnt werden. Mit sichtbarem Status (neue Vorlage?) im Artikel.--VÖRBY (Diskussion) 10:09, 25. Dez. 2012 (CET)

• Der Hinweis ist juristisch notwendig.
• Wenn er entfernt oder verkleinert wird, dann kann diese Aktion nur vom Benutzer ausgehen, und die Aktion muss in einem Logbuch oder in einer Versionsgeschichte nachweisbar sein, wie das bei Wikipedia:CSS #Hinweise der Fall ist.
  • Ein einfacher Mausklick irgendwo unter Einstellungen genügt nicht; der kann auch aus Versehen und ohne Verständnis für die Folgen passiert sein.
  • Es ist auch nicht nachweisbar, welche Person bei den vorangegangenen 50 Edits unter diesem Account am Bildschirm gesessen hatte.
• Jede Verkleinerung durch das Projekt, deren Programmierung auch weltweit auf alle Projekte Auswirkungen hätte, würde ansonsten die Wikis in unübersehbare Schwierigkeiten bringen und die Beweislast umkehren, weil von jetzt an jeder Benutzer behaupten kann, er hätte ihn bei gerade diesem Edit nicht gesehen, und der Hinweis würde ja sowieso automatisch ausgeblendet und wäre nicht erschienen. Also muss nunmehr das Projekt dem letztlich anonymen Benutzer nachweisen, dass er gewusst hatte, dass für diesen Edit die URV-Bestimmungen gelten würden. Und das macht mir mal vor. Damit wäre aber auch jede folgende Weiternutzung in Frage gestellt und das weltweite Projekt kann umgekehrt für jede URV jedes angemeldeten Benutzers zur Verantwortung gezogen werden.
• Wenn hingegen jemand durch eigene „Manipulation“ den ihm gegebenen Hinweis unterdrückt, ist das Projekt nicht verantwortlich.

Schönen Feiertag --PerfektesChaos 14:53, 26. Dez. 2012 (CET)

Super und Danke, das ist eine klare Antwort. Die Anfragen haben sich damit wohl erledigt. Guten Rutsch ins Neue Jahr wünscht --VÖRBY (Diskussion) 12:31, 27. Dez. 2012 (CET)

Der Hinweis ist juristisch notwendig. --> Darum in minimierter Version bestehen lassen. Bei den EULAs wird auch niemals alles auf einen Blick dargestellt, sondern in einem Scrollfenster. Ist genau die gleiche Situation.

Es ist auch nicht nachweisbar, welche Person bei den vorangegangenen 50 Edits unter diesem Account am Bildschirm gesessen hatte. --> Wir reden hier aber schon nur von angemeldeten Benutzern, keine IPs?! Der Account ist personenbezogen und darf (ohne jetzt nachgeschaut zu haben) auch nicht mit anderen Personen geteilt werden. Somit ist es aus rechtlicher Sicht abgesichert.

Jede Verkleinerung durch das Projekt, deren Programmierung auch weltweit auf alle Projekte Auswirkungen hätte --> Mal eine Frage dazu. Gibt es den keine Variable wie {{Useredits}}? Falls ja, könnte man ja die Vorlage einfach anpassen, dazu braucht es keine Änderung an der Software und somit auch keine Auswirkung auf andere Projekte.

So wie es aussieht habe ich einfach einen wunden Punkt getroffen. Dass sich die Wikipedia rechtlich absichern möchte, verstehe ich. Ich sage es aber nochmal, dass es um Verhältnismässigkeit geht. Hier wird immer wieder diskutiert wie man mehr Bearbeiter für die Wikipedia gewinnen kann und genau sowas wie mein Vorschlag, was die Übersicht erhöht, wäre ein kleiner Beitrag. Wenn ich editiere möchte ich mich um den Edit kümmern und nicht zum tausendsten Mal diese Warnung vorgehalten bekommen.

Ich bleibe beim Standpunkt, dass ein minimierte (ausklappbare?) URV-Hinweis nach x Edits für angemeldete Benutzer reicht - auch rechtlich. Hier aber mal ein 'entgegenkommen': Der ganze Block enthält ja neben dem URV-Hinweis auch noch den Teil mit dem Hinweis zur Quellenangabe. Mindestens diesen Teil könnte man nach x Edits ausblenden. Ansonsten könnten wir all die anderen Hinweise wie NPOV, Schreibstil, Verlinkung usw. auch gleich rein nehmen. --Nightwish62 (Diskussion) 13:30, 27. Dez. 2012 (CET)

• Ich glaube nicht, dass du schon mal eine millionenschwere Klage gegen eine der zehnthäufigst besuchten Websites der Welt abgewehrt hast. Es gibt US-Anwälte, die nur darauf warten, dass sich das Projekt so eine Blöße geben würde.
• Der Kasten enthält nicht nur das Verbot der URV, sondern auch die ausdrückliche Erlaubnis zur Weiternutzung dieses Edits. Ist diesem nicht gültig zugestimmt worden, kann die Bearbeitung auch nicht nach den Lizenzbestimmungen weitergenutzt werden.
• Es gibt ohnehin Überlegungen, gelegentlich den Inhalt des Kastens in zwei Teile aufzuteilen; der juristisch zwingende Teil bliebe in vollem Umfang unübersehbar direkt oberhalb des Speichern-Knopfes.
• Innere Angelegenheiten wie NPOV usw., die du erwähnt hast, haben juristisch eine fundamental andere Qualität und Wichtigkeit (nämlich so gut wie keine) als Rechtsansprüche Außenstehender; der Urheber wie der verklagten Weiternutzer.

VG --PerfektesChaos 21:44, 27. Dez. 2012 (CET)

Also, lassen wir die ganze Diskussion betreffend URV-Teil mal und führen die Diskussion nur noch betreffend NPOV-Teil weiter. Du schreibst ja selber dsas dies eine ganze andere Qualität und Wichtigkeit hat. Braucht es den NPOV-Teil wirklich immer, selbst nach X Edits? --Nightwish62 (Diskussion) 22:37, 30. Dez. 2012 (CET)

→ mw:Micro Design Improvements #Changes --PerfektesChaos 13:38, 6. Jan. 2013 (CET)

Kategorien-Ein- und Austragungen auflisten

Wäre ein Tool möglich, daß Ein- und Austragungen von Artikeln in/aus Kategorien auflistet? Das wäre in manchen Fällen hilfreich, u. a. um vandalischem Falschkategorisieren beizukommen.

Formular

Kategorie: Politiker (Deutschland)
Datum ab: 23. Mai 2012 bis: 29. Mai 2012
Nur Eintragungen: _ Nur Austragungen: _ Ein- und Austragungen: X
Nur Anzeigen, wenn Artikel seither nicht mehr ein/ausgetragen wurde: _
Austragung nicht anzeigen, wenn Artikel aktuell wieder in der Kategorie steht: X
Austragung nicht anzeigen, wenn Artikel aktuell in einer Unterkategorie steht: X
Eigene Edits ausblenden: _
Edits von Sichtern ausblenden: _

Resultat

• 23. Mai 2012, 7:55 Uhr: Norbert Blüm wurde von Benutzer:Giauwefhsdf eingetragen
• 26. Mai 2012, 19:12 Uhr: Rudolf Scharping wurde von Benutzer:Zwegfaiwerfg ausgetragen
• 26. Mai 2012, 19:13 Uhr: Norbert Blüm wurde von Benutzer:Zwegfaiwerfg ausgetragen
• 27. Mai 2012, 10:54 Uhr: Gustav Stresemann wurde von Benutzer:23.199.37.0 ausgetragen
  

Summe: 1 Eintragung, 3 Austragungen. Kategoriengröße am Beginn des Beobachtungszeitraumes: 45 Artikel, am Ende: 43 Artikel.

Gruß, Aspiriniks (Diskussion) 19:29, 31. Dez. 2012 (CET)

Frohes Neues!

Ich sehe deinen Vorschlag als sinnvoll, zeitgemäß, wünschenswert und realisierbar an.

• Die Sache hat einen kleinen Haken: Zurzeit haben wir kein Gedächtnis. Mit einem Tool alleine ist es deshalb nicht getan; zunächst einmal müsste eine Datensammlung geschaffen werden, die sich eine Weile lang die vorherigen Zustände merkt.
  • Bislang wird im Moment der Anfrage nach Kategorienzugehörigkeit geschaut, welche Seiten jetzt gerade in diese Kategorie einsortiert sind.
• Ich sehe zwei Wege zur Realisierung:
  1. Weltweit wirksame Erweiterung der MediaWiki-Software und der ihr zugrundeliegenden Datenbanken:
     • Es müsste eine zusätzliche Tabelle angelegt werden.
       • Diese merkt sich für jede Kategorie des Projekts, welche Seiten ihr zugeordnet sind.
       • Das wird für eine begrenzte, konfigurierbare Zeit aufgehoben; etwa 30 Tage wie bei der Beo.
       • Inhalt der Tabelle wären nur drei bis vier Werte:
         1. curid der Kategorie
         2. oldid der Seiten-Veränderung
         3. Häkchen für Zugang/Abgang (boolean).
         4. ggf. auch curid der veränderten Seite, siehe unten.
       • Wenn eine Anfrage gestellt wird, lassen sich alle weiteren Informationen (Bearbeiter, Uhrzeit) aus der oldid ableiten.
       • Einmal täglich registriert das Projekt, welches gestern die letzte vergebene oldid gewesen war.
       • Danach werden alle Einträge aus der Kategorie-Tabelle gelöscht, die kleiner oder gleich der vor 30 Tagen registrierten oldid sind.
     • Jedes Mal, wenn eine Seite gespeichert wird, ist zu vergleichen: In welche Kategorien war die Seite zu Beginn der Bearbeitung einsortiert; in welche jetzt und gibt es Unterschiede? Die differierenden Kategorien bekommen in der Kategorie-Tabelle die oldid dieser Bearbeitung eingetragen.
       • Problem: Indirekte Kategorisierung (etwa über Vorlagen; Wartungskategorien) werden so nicht erfasst; sind aber auch nicht im Mittelpunkt des Interesses und Ziel dieser Anfrage.
     • Auf einer Spezialseite ist abfragbar, was mit der gewünschten einzelnen Kategorie losgewesen war.
       • Da die Gesamtzahl jetzt bekannt ist, kann mittels Durchzählen der Häkchen die Gesamtzahl an jedem Startzeitpunkt der Analyse ermittelt werden (solange sie dieser innerhalb des Gedächtnisintervalls läge).
       • Filterei („Nur Austragungen“, „Nur Eintragungen“) ist unproblematisch; auch „Jetzt in einer Unterkat“ würde sich zaubern lassen.
       • Problem: Das Gewürge mit Unterkategorien und die Intelligenz, ob die Seite anschließend oder vorher in Ober- oder Unterkategorien eingetragen wurde und ob dies clever war oder nicht, wird dir kaum ein Tool vollständig abnehmen können. Dazu musst du dir gewissermaßen eine auf Basis der Kategorie-Tabelle gebildete alternative „Kategorie-Geschichte“ für jede einzelne Seite angucken, die analog zur Versionsgeschichte für diese Einzelseite alle Kategorie-Transaktionen der letzten 30 Tage auflistet, und natürlich die momentanen Kats. Dazu empfiehlt es sich dann, in die Kategorie-Tabelle auch die curid der Seite aufzunehmen; das ist aber eigentlich redundant und wäre von Datenbank-Betreuern zu entscheiden, ob direkt gespeichert oder on-the-fly relational über die oldid bestimmt.
     • Der Aufwand (Programmierung, Speicherplatz, Performance) ist überschaubar.
       • Wenn man weiß, was alles für Zeugs gespeichert wird und was so alles in MediaWiki passiert, ist auch das noch zu verschmerzen.
  2. Entwicklung einer externen Lösung auf dem Toolserver-Nachfolger
     • Bot-Prinzip: Ein Bot bekäme von einem Portal, einer Redaktion usw. den Auftrag, eine bestimmte Kategorie zu überwachen (und bitte auch gleich noch sämtliche Unterkategorien, sonst geht das ins Unzumutbare).
     • Etwa einmal wöchentlich macht der Bot von allen angeforderten Kategorien einen Schnappschuss und vergleicht das Ergebnis mit der Vorwoche; die Differenz wird auf einer Wartungsseite dargestellt.
• Vergleich der beiden Varianten:
  • Die zweite Lösung können einzelne Programmierer hinzaubern; für die erste ist eine weltweite Entscheidung erforderlich.
  • Die erste Lösung ist die professionellere und sauberere.
  • Die erste Lösung registriert jede Einzelveränderung, auch wenn sie nur kurzzeitig aktiviert war. Die zweite Lösung bekommt nicht mit, was unter der Woche hin- und hergeschehen war.
  • Ressourcen:
    • Der Speicherbedarf dürfte zunächst nach Etablierung der Wartungsaufträge ähnlich, im Lauf der Zeit für die zweite Lösung aber größer sein. Grund: Die erledigten Wartungsseiten verbleiben auf ewig in der Datenbank, und ihre angesammelte Größe übersteigt irgendwann die Kategorienveränderungen innerhalb des Beobachtungszyklus. (Es sei denn, sie würden temporär beim Tool gehostet; wie Templatetiger, checkwiki; und dort analog als Datenbank analysiert).
    • Rechenzeit und Programmieraufwand würden sich nicht sonderlich unterscheiden, fallen nur an unterschiedlichen Stellen an.

Viel Erfolg --PerfektesChaos 18:17, 1. Jan. 2013 (CET)

Ja, die Idee ist gut und kam mir auch schon. Wie PerfektesChaos sagt, die Datenbank ist die sauberste Lösung. Und darum: Kommt Zeit, kommt Rat. Mit WikiData werden wir ganz neue Möglichkeiten haben. Die Interwiki-Links nach WikiData zu verlegen ist ja auch nicht viel anderes als die Kategoriesierung. Soviel ich weiss ist für Kategorisierung keine der drei Initialphasen von Wikidata was angedacht, aber sobald das ganze mal lauffähig ist, könnte man das Thema nochmal hervorbringen. Ich glaube jetzt hat es noch keinen Sinn, da das ganze Projekt eh schon ausgelastet ist. Lassen wie die zuerst mal die Basis schaffen und kommen dann mit dem Wunsch. --Nightwish62 (Diskussion) 20:30, 2. Jan. 2013 (CET)

OK, vielen Dank schonmal Euch beiden! Gruß, Aspiriniks (Diskussion) 13:41, 6. Jan. 2013 (CET)

---

Nachträglicher Hinweis: Eine Übersicht zu Diskussionen zum Thema "Kategorien beobachten" im Sinne der neuesten Zu- oder Abgänge in einer Kategorie findet sich unter Benutzer:Zulu55/Wikipedia:Kategorien "beobachten". --Zulu55 (Diskussion) _Unwissen 15:36, 27. Aug. 2013 (CEST)

Bot, der externe Links auf Google(.., .., ..) oder Adblock+ gelistete Websites untersucht

Wikipedia ist eine erste sichere Anlaufstelle im Internet.
Es wäre schön, wenn zumindest der erste Mausklick von einem Wikipedia Artikel aus genau dieses bliebe. Hierfür wünsche ich mir, dass ein Bot externe Links automatisiert z.B. auf Adblock+ gelistete Websites untersucht.
Ob das Ergebnis dieser Untersuchung eine Färbung des externen Links, die Entfernung des Links, das Anhängen einer Liste von Attributen (Facebook Social Plugins, googlesyndication.com, google +1, twitter, INFOnline, .., .., ..) ist, ist mir nicht wichtig. Wichtig ist mir, dass diese Überprüfung nicht durch einen Menschen möglicherweise nach, sondern automatisiert (2012) vor dem Klick stattfindet.
Anlass für diesen Request ist der erste externe Weblink auf [12], der sowohl kommerziell wie auch privatsphärenrelevant zu sein scheint.--HeWhoMowedTheLawn (Diskussion) 23:39, 10. Nov. 2012 (CET)

Hoppla, ich war zu langsam:) Wow. Der Artikel ist bereits korrigiert, der angeführte Link ist stattdessen er erste bei https://de.wikipedia.org/w/index.php?title=Body-Mass-Index&oldid=110012092 --HeWhoMowedTheLawn (Diskussion) 23:51, 10. Nov. 2012 (CET)

Naja, dafür haben wir ja eigentlich die Spam-Blacklist (bzw. hier). Wenn ein Link nicht vertrauenswürdig ist, sollte er gar nicht erst eingefügt werden (nicht nur markiert). Grüße — Alleskoenner (Diskussion) 18:10, 29. Nov. 2012 (CET)

Eine händische Sichtung bei einem Vorgang, der sich automatisieren lässt und Tausende Webseiten betrifft, erscheint mir nicht zeitgemäß. Und wird absehbar beim Entfernen zu vielen fruchtlosen Diskussionen führen. Zudem ist zu erwarten, dass sich externe Webseiten ändern. Bei der binären Entscheidung fliegt raus oder bleibt drin sehe ich zwei Schwachpunkte
a) es lässt sich kein von allen gleichermaßen anerkannter Bewertungsmaßstab/Schwellwert finden und
b) ein entfernter externer Link fehlt einfach (d.h. möglicherweise wird den Autoren, nicht aber den Normalbesuchern des Wikis, bewusst, dass Funktionalität oder Links zu Information einmal da war).
Beispiel nun: die Tracker im ersten externen Link bei Ponderal-Index. --HeWhoMowedTheLawn (Diskussion) 20:09, 9. Dez. 2012 (CET)

On Wikipedia:Bots/Status there are 56 bots listing the keyword "Interlink" in their task description. Only 2 bots have the keyword "external" in their task description. To my naive reading this suggests that external links (and their services) are not adequately paid attention to. --HeWhoMowedTheLawn (Diskussion) 21:19, 20. Jan. 2013 (CET)

Verweis auf Eintrag in anderer Sprache bei fehlendem Artikel

Fehlt ein Artikel, werden andere Artikel angeboten, die das Stichwort enthalten oder es wird ein Edit eingeleitet. Dies ist in vielen Fällen sinnvoll. Gelegentlich böte es sich aber auch an, den gesuchten Artikel in anderssprachigen Wikipedien zu suchen und, ähnlich wie bei Sprachverlinkung bestehender Artikel, entsprechende Links je Sprache zu setzen. Besonders sinnvoll ist dies bei der Suche nach einer Person, die in der deutschen Wikipedia nicht vermerkt ist, aber in einer anderen, da bei Namen die Schreibweise in der Regel nicht abweicht.

--So66 (Diskussion) 15:09, 4. Dez. 2012 (CET)

Diese Funktion ist in der fr:wp schon lange vorhanden. Es werden dort auf Nachfrage alle Artikel mit dem gleichen Lemma aufgeführt (klappt eigentlich nur gut bei Namen). --Eingangskontrolle (Diskussion) 22:18, 18. Dez. 2012 (CET)

Ein gesuchtes Stichwort in anderen Sprachversionen anzuzeigen wurde als Feature auch in einem taz-Artikel vorgeschlagen. Eine globale Wikipediasuche bietet dieses Tool, das auch in der fr.wp (oben rechts) verlinkt ist.--Sinuhe20 (Diskussion) 14:35, 26. Jan. 2013 (CET)

Kurz-URL-Dienst

Kopiert von Artikel-Diskussion:Kurz-URL-Dienst:

Ich weiß leider nicht, wo ich dieses Feature am besten "beantrage": Aufgrund der (auch im Artikel erwähnten) Risiken wäre es imho wünschenswert, dass Wikipedia einen eigenen url-shortener hat. Welche adresse dann die beste wäre sollte wahrscheinlcih abgestimmt werden, eine idee wäre http://dewp.org (die laut whios Wikimedia Deutschland e.V. gehört) dafür zu verwenden:

Also zB http://dewp.org/?/96521818, http://wikipedia.de/?/96521818, http://dewp.org/?/Kurz-URL-Dienst und http://wikipedia.de/?/Kurz-URL-Dienst könnten auf diesen artikel verlinken, also http://de.wikipedia.org/w/index.php?oldid=96521818 Die nummer, die ich aus der Versionsgeschichte gekramt habe(also bereits existiert und keine neue datenbank benötigen würde), würde also auch gleich die version des artikels beinhalten (was zT gewünscht sein kann, wenn nicht findet man ja schnell den neuen artikel). Das Fragezeichen ist ein Platzhalter (kann natürlich aber auch ein Fragezeichen bleiben) damit zB Seiten wie http://wikipedia.de/properties noch möglich sind, man sich also nicht alle URLs verbaut. Der Platzhalter könnte für den Nummerncode anders sein als für Text-links und mit /wiki/ sollte es auf jeden fall so funktionieren wie es derzeit im original funktioniert.

Falls jemand weiß, wo ich das am besten unterbringe bin ich für hinweise dankbar. --Jakov (Diskussion) 17:43, 17. Dez. 2012 (CET)

• Der Wunsch kam in den letzten Jahren immer wieder mal auf, in diesem Jahr schon häufiger.
• Grad vor ein paar Wochen ist es in der weltweit zentralen technischen Entwicklungsebene für Wikis konkreter diskutiert worden: mw:Requests for comment/URL shortener bzw. Bugzilla:42085 (englisch). Verschiedene Formate und Lösungen sind möglich.
• In der deutschsprachigen WP wäre die Seite Wikipedia:Verbesserungsvorschläge/Feature-Requests für derartige Wünsche optimal.
• Nebenbei gefragt: Für welches Szenario, welchen konkreten Anwendungsfall, in welcher Situation würdest du dir das denn wünschen? Kannst du das etwas näher beschreiben?

Viele Grüße --PerfektesChaos 21:32, 17. Dez. 2012 (CET)

• Also mein persönlicher anlass ist, dass ich oft auf verschiedenen rechnern arbeite, wo ich nicht meine persönlichen suchkürzel installieren kann; also zB einfach "wp Kurz-URL-Dienst" in die adressleiste eingeben kann. Wenn ich zB bei der bedeutung eines englischen wortes nicht sicher bin, tippe ich einfach (egal wo ich bin) "dict.cc/harassment" in die adressleiste. Genauso würde ich gerne zB "wikipedia.de/Paris" (oder etwas ähnlich kurzes und intuitives) eintippen können. "de.wikipedia.org/wiki/Paris" ist eben ein gutes stück mühsamer zu tippen, vor allem weil man meist zuerst "wikipedia.org" denkt, dann erst, dass man ja noch "de." davortun muss, und das "/wiki/" macht es auch nicht kürzer. Ich denke, dass hier der aufwand alles was an wikipedia.de geht obwohl nichts da ist entsprechend an de.wikipedia.org weiterzuleiten relativ gering ist (zB mittels http://en.wikipedia.org/wiki/URL_redirection#Apache_mod_rewrite).
• Als einen weiteren Grund würde ich Kurznachrichtendienste wie Twitter nennen, die ja zum bedarf an URL-Shortenern geführt haben, mitsamt der in diesem Artikel dargestellten Probleme, d.h. quasi URL-shortener mit Ursprungsgarantie, der keine krummen sachen macht.
• Rohtext-formate wie die Wiki-Syntax, Markdown, etc. sind mit von Menschen lesbaren URL angenehmer zu lesen.
• Auch verweise aus Zeitungsartikeln wären einfacher abzutippen. Beim abtippen von "http://de.wikipedia.org/wiki/Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch" geht sicher etwas schief. In solchen Fällen könnte auf die versionsnummern zurückgegriffen werden: http://de.wikipedia.org/w/index.php?oldid=111557720 funktioniert bereits, "wikipedia.de/111557720" wäre aber schöner und funktioneller.

Stackoverflow verwendet zum Beispiel eine kombination aus nummer und name: "http://meta.stackoverflow.com/questions/109795/what-shortened-urls-are-available-through-s-tk", sodass anhand der URL zwar sofort erkennbar ist worum es geht, der text nach der nummer aber eigentlich irrelevant ist, sodass "http://meta.stackoverflow.com/questions/109795/what-the-fuck" das selbe ziel erreicht.

• Auch Referenzlisten in Wissenschaftlichen Arbeiten könnten direkt an die Versionsnummer verweisen und sich damit zwar nicht das "aufgerufen am" sparen, beim nachvollziehen müsste man aber nicht erst die entsprechende version suchen.

Im Übrigen habe ich gerade herausgefunden, dass zB http://enwp.org/Obama bereits als URL-Kurz-Dienst funktioniert.

Amike, --Jakov (Diskussion) 17:22, 18. Dez. 2012 (CET)

Kara amiko!

Danke für deine Anregungen und deine Unterstützung. Ich sortier mal:

• Wir werden aus Sicherheitsgründen nur einen eigenen Server einsetzen; kein Betreiber soll die IP-Adressen und Seitentitel mitlesen dürfen und für kommerzielle oder politische Zwecke auswerten können – es reicht völlig, dass die physischen Netzbetreiber den http-Verkehr sehen.
  • Experimente gibt es bereits; enwp.org ist eines.
• Die wikipedia.de zu nutzen ist eine neckische Idee.
  • Diese Domain macht zurzeit nichts anderes, als pfadlos in die USA weiterzuleiten.
  • Ein deutsches Gericht hatte mal diese Weiterleitung für ein paar Tage gesperrt (Lutz Heilmann).
  • Man weiß aber auf dem Server in den USA, welche URL ursprünglich eingegeben worden war, und könnte sich das /wiki/ in diesem Fall dazudenken.
  • Allgemein brauchen die URL von Servern, die mit der Mediawiki-Software arbeiten (nicht nur die WMF), eine solche /wiki/-Information, weil im Prinzip auch andere Sachen laufen können und man auch anderes haben könnte.
  • Nur so kann der Artikel wiki unterschieden werden.
  • Auf meta:Wikipedia.de wird die Seitenorganisation betreut.
• Das mit den Zahlen ist eine andere Sache und würde nicht gehen:
  1. Es sind legitime Seitennamen aus Ziffern möglich.
     • 1234 und 10000 existieren bereits, Skandal im Sperrbezirk hätte auch 32168 heißen können und eine Band oder ein Dichter könnte das nächste Werk 123456789 betiteln.
  2. Jede Seite hat eine „Seitenkennnummer“ („curid“), die unabhängig von der Umbenennung („Verschiebung“) immer dieselbe Vorgeschichte behält. Die aktuelle Version von dieser hier findest du immer mit de.wikipedia.org/w/index.php?curid=6769926 und das wäre eine weitere Interpretation einer Zahl.
• Tückisch ist, dass es nicht nur Wikipedia gibt, sondern auch die Wikisource und Wikibooks; ich füchte, die wollen dann auch. Und die eoWP; und die dann alle nach einem weltweit einheitlichen Schema.
• Was deine Anmerkungen zum Zitieren angeht, schau doch mal nach links zu der Box „Werkzeuge“ – dort findest du die Links „Seiteninformationen“ und (nur beim umseitigen Artikel verlinkt) „Seite zitieren“. In der Wissenschaft soll man sich ja mit copy&paste gut auskennen.
• Weiterhin gibt es dort links ein Link „Permalink“ (das sogar noch ausgebaut werden kann, →Einstellungen und dann Permalink (Version) + Permalink (Artikel) verfügbar); siehe auch Hilfe:Permalink. Das wäre die von dir genannte Kombination aus Nummer und Name.
  • Als dynamische Enzyklopädie möchten wir, dass die Leute in der Regel die frischeste und aktuellste Version der Artikel lesen.
  • Die meisten Leser wären aber mit wikipedia.de/paris glücklicher als mit wikipedia.de//11446 oder ähnlich.
• Nachdem wir an dieser Stelle Durchblick bekommen hatten, werde ich gelegentlich unsere ertragreiche Diskussion verschieben nach Wikipedia:Verbesserungsvorschläge/Feature-Requests.

Gute Nacht erstmal --PerfektesChaos 23:44, 18. Dez. 2012 (CET)

--PerfektesChaos 19:30, 30. Dez. 2012 (CET)

Zwar kein ganz kurz URL-Dienst, aber vielleicht hilft auch das Helferlein PermaPageLink ändert den Link „Permanenter Link“ in der Werkzeugleiste zu „Permalink (Version)“ und fügt „Permalink (Artikel)“ hinzu mit Permalink (Artikel), ist es schon etwas kürzer und vor allem auch fix. --K@rl 18:16, 9. Mär. 2013 (CET)

Portal-Hinweise auf Diskussionsseiten

Ich schlage vor, einen Baustein einzuführen, der oben auf Artikel-Diskussionsseiten eingesetzt werden kann, um auf ein bestimmtes, zuständiges Portal, bzw. eine bestimmte Redaktion hinzuweisen, an das/die sich ein Leser bei Fragen oder Problemen ggf. wenden kann. In den meisten größeren fremdsprachigen Wikipedien ist das bereits Standard und diese Portal-Hinweise machen IMO auch Sinn, da man das zuständige Portal so viel leichter herausfinden und kontaktieren kann. Im Moment bestehen ja große Probleme darin, dass Portale 1. zT schwer auffindbar sind, da sich nicht jeder Nutzer in der Masse an Portalen zurechtfindet und dann auch das richtige ausfindig machen kann, 2. die Portale keine ausführliche Übersicht über "ihre" Artikel haben und es 3. oftmals untergeordnete Fachportale gibt, die zwar für einen bestimmten Artikel geeigneter wären, als das Hauptportal, allerdings diesem nicht zugeordnet wurden und daher gar nicht erst aufgesucht werden. Ich finde wir sollten die Fach-Portale und -Redaktionen und dadurch auch die Qualität der Artikel weiter fördern, indem wir unter anderem auch Zuständigkeiten klarer verteilen und es dem Leser einfacher machen, die zuständigen Portale zu kontaktieren. Das könnte dieser Baustein ermöglichen.

Ich habe unter Benutzer:111Alleskönner/Vorlagen/Portale mal eine Beispiel-Vorlage angefertigt, die einen solchen Hinweis ermöglichen könnte. Man könnte sie später über die Parameter ggf. auch noch um Kategorien ergänzen, die jeden Artikel in eine Portal-Kategorie einteilt durch die jedes Portal einen besseren Überblick über "seine" Artikel bekommen würde.

Hier noch einige Beispiele für ähnliche Vorlagen in anderen Wiki-Projekten:

• en:Template:Portal bar (ähnlich der Beispiel-Vorlage: Ein Balken mit dem zuständigen Portal)
• en:Template:WikiProjectBannerShell (in der en:WP inzwischen Standard, IMO aber etwas unübersichtlich und aufdringlich: der "Project-Banner" für Diskussionsseiten)
• fr:Modèle:Portail (wie 1. Beispiel)

Viele Grüße — Alleskoenner (Diskussion) 22:18, 29. Nov. 2012 (CET)

Es gibt Benutzer, die das "Zupflastern" der Diskussionsseite mit solchen Bausteinen nicht begrüßen und nicht hilfreich finden. Hier muss vermutlich ein Meinungsbild her, ob solche Bausteine in der deutschsprachigen Wikipedia erwünscht sind oder nicht. Der Umherirrende 21:01, 30. Nov. 2012 (CET)

Oh ja. Machen wir gleich nach Wikipedia:Meinungsbilder/Vorlage zur Markierung von Belegmängeln. --92.72.53.181 08:47, 1. Dez. 2012 (CET)

@Umherirrender: Ja, das denke ich auch. Deshalb wollte ich hier mal anfragen, wie ihr dazu steht. Ggf. könnte man dann ja zusammen eine Vorlage entwickeln und ein MB formulieren - aber erst wollte ich hier mal nachfragen =) Grüße — Alleskoenner (Diskussion) 14:46, 1. Dez. 2012 (CET)

Nachtrag: Man könnte die angesprochene Funktion natürlich auch mit der Vorlage:Diskussionsseite kombinieren, indem man dort einen zusätzlichen Parameter hinzufügt, der auf das zuständige Portal verweist. Grüße — Alleskoenner (Diskussion) 00:09, 4. Dez. 2012 (CET)

Was denn bitteschön soll den ein solcher Hinweis bringen. Daß der Artikel von einem Portal betreut wird ist dort ja bekannt. Und im Artikel selber ist diese Information völlig irrelevant. Im Übrigen reicht ein Blick in die Verlinkungen auf die Seite, welche Portale einen Artikel im Blickfeld haben.  @xqt 07:01, 18. Jan. 2013 (CET)

Nun ist übrigens eine Umfrage zu dem Thema gestartet - siehe Wikipedia:Umfragen/Klärung der Portalstrukturen. Grüße — Alleskoenner (Diskussion) 01:20, 3. Feb. 2013 (CET)

 Info: Siehe zu dem Thema bitte auch das kürzlich initiierte MB: Wikipedia:Meinungsbilder/Portalhinweise auf Diskussionsseiten. Grüße — Alleskoenner (Diskussion) 15:15, 2. Apr. 2013 (CEST)