„Wikipedia:Verbesserungsvorschläge/Feature-Requests“ – Versionsunterschied

Auf dieser Seite sollen Feature-Requests gesammelt werden, also Vorschläge, Wünsche oder Forderungen, der Software neue Funktionen hinzuzufügen bzw. eine vorhandene Funktionalität zu ändern. Wenn sie sich durchsetzten, werden sie an die Entwickler weitergeleitet. Durch die so erreichte Zustimmung haben sinnvolle Änderungen eine größere Chance. Umsetzungen finden sich auf Wikipedia:Projektneuheiten.

• Um allgemeine, nicht softwareabhängige Verbesserungsvorschläge zu machen, nutze bitte Wikipedia:Verbesserungsvorschläge.
• Um vermutete Softwarefehler (Bugs) zu melden, wende dich bitte an die Technik-Werkstatt.
• Um einen Vorschlag tatsächlich an die Programmierer weiterzugeben, wird jedoch Phabricator (ehemals: „Bugzilla“) verwendet, wo solche Vorschläge verwaltet werden.

Bitte gebt auf dieser Seite unter »dafür« (pro) oder »dagegen« (contra) eure Stimme ab, welche Feature requests an die Entwickler weitergeleitet werden sollen.

(Mehr Kommunikationsmöglichkeiten auf der Kontaktseite.)

Neuen Beitrag erstellen

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

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

Automatische Archivierung

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

Automatische Archivierung

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

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Dauerbrenner

• Cursor im Suchfeld: Bug 1864 (als Helferlein verfügbar: Einstellungen -> Helferlein -> Cursor-Platzierung auf der Hauptseite immer in der Suchbox)
• Trennung von Artikel und Meta-Daten: siehe Semantic MediaWiki
• Verbesserung der Suchfunktion: Bug 974, Bug 1837 u.a.
• Globale Benutzereinstellungen: Bug 14950 (globale CSS und JS: Bug 13953)
• Timeline aus allen in Texten geschriebenen Datumsangaben - Priorisierung nach Artikelgröße pp
• Beobachtung von Abschnitten: Aktuell nicht möglich. Siehe auch: Benutzer:DrTrigonBot/Doku#Diskussions-Zusammenfassung, Wikipedia:LiquidThreads

Feature-Requests

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)

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 [[1]], 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)

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)

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)

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)

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)--->[2].

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)

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)

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 [3]. 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)

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)

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

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)

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

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)

Suchfunktion: Erleichterte Suche und Verfügbarkeit der gesuchten Inhalte im Browser

Viele Nutzer gebrauchen die Suchfunktion sehr oft und haben mehrere der gesuchte Inhalte gerne gleichzeitig in eigenen Tabs verfügbar. Es wäre schön, wenn dem Button der Suchfunktion ein zweiter hinzugefügt werde, der den gesuchten Inhalt automatisch in einem neuen Tab darstellt. Jeder Benutzer nutzt in der Regel eine Suchleiste, die gerade in einem der Tab's verfügbar ist. So bleibt der bisher gesuchte/genutze Inhalt im aktuellen Tab erhalten und muss nicht erst mühsam durch Navigation wieder hergestellt werden, noch in den Browseroptionen eine universelle Taböffnung für jeden Link erzwungen werden. Man ist dann nicht mehr gezwungen sich auf einen eigenen tab für Suchen zu konzentrieren um unnötig, rückgängig machende Navigationsschritte in anderen, noch gebrauchten Tab's zu vermeiden. (nicht signierter Beitrag von 84.141.12.230 (Diskussion) 13:49, 12. Jan. 2013 (CET))

Der Wunsch ist verständlich und technisch relativ leicht mit JavaScript realisierbar.

Etwas schwierig ist es allerdings mit nicht angemeldeten Benutzern (IP, so wie hier). Das gewünschte Verhalten wäre vermutlich nur als Opt-In anzubieten, und dies bedarf der Speicherung persönlicher Benutzereinstellungen.

Für normale Links verwende ich die entsprechende Funktionalität schon seit längerer Zeit persönlich mit einer simplen Ergänzung; für das Suchfeld (das ein Formular ist) bedarf es einer etwas komplexeren, aber effizient machbaren Konstruktion.

Irgendwann bereite ich mein Skript sicherlich mal so passend zum aktuellen Stand der Technik auf, dass es allen Benutzern angeboten werden kann.

Liebe Grüße --PerfektesChaos 14:50, 12. Jan. 2013 (CET)

Ich bin es in meinem Opera gewohnt, in Suchfeldern Umschalt+Enter drücken zu können, um das Suchergebnis in einem neuen Tab zu öffnen. Hier geht das nicht, weil offenbar nicht einfach nur ein GET/POST-Request ausgelöst wird, den der Browser in einen neuen Tab schicken könnte, sondern jQuery dazwischen funkt. Das ärgert mich schon länger. --TMg 18:47, 12. Jan. 2013 (CET)

Heute in den von GiftBot gemeldeten Software-Neuheiten: „(Bugfix) Die Suchvorschläge im Suchfeld funktionieren jetzt als richtige Links. D.h. sie können mit der mittleren Maustaste in einem neuen Tab/Fenster geöffnet werden (Bug 17808, Bug 21167, Gerrit:23674)“. Funktioniert bei mir. Rechte Maustaste geht auch, die werden eben als richtige Links behandelt. -- Ivla^Disk. 16:55, 18. Feb. 2013 (CET)

Verspätet: Mich begeistert diese Änderung sehr. Warum muss man so etwas immer erst verkomplizieren, statt gleich auf die einfache Lösung zu setzen? Strg+Enter funktioniert leider immer noch nicht. Bin ich der Einzige mit diesem Problem? --TMg 21:18, 16. Mär. 2013 (CET)

Eine sprach-übergreifende Einstellung, dass alle Wikipedia-URLs auf englisch angezeigt werden

Die Umkehrung also davon, dass User:Erzbischof oder Special:Watchlist in URLs http://de.wikipedia.org/wiki/Benutzer:Erzbischof oder http://de.wikipedia.org/wiki/Spezial:Beobachungsliste umgewandelt wird. Bestünde dafür Interesse? --Erzbischof 15:01, 12. Jan. 2013 (CET)

1. Technisch machbar; wie herum immer du das haben möchtest.
2. Es geht in beide Richtungen; ich habe nicht ganz verstanden, wohin die Reise gehen soll.
3. Könntest du deine Anregung in ein Szenario einbetten, damit sichtbar wird, in welcher Situation was genau wo genau für wen wie dargestellt sein soll?
4. Bei Benutzerin geht was verloren; was wäre mit den Namensraumkürzeln?
5. Liebe Grüße --PerfektesChaos 15:22, 12. Jan. 2013 (CET)

Hallo PerfektesChaos. Zu allem: Ich aktiviere die Einstellung "Englische URLs auf allen Projekten." Daraufhin wird im Adressfenster http(s)://de.wikipedia.org/wiki/Special:Watchlist angezeigt, egal ob ich die auf die Spezialseite Beobachtungsliste über die Wiki-Links Special:Watchlist, Spezial:Beobachtungsliste oder über die URLs http(s)://de.wikipedia.org/wiki/Spezial:Beobachtungsliste oder http(s)://de.wikipedia.org/wiki/Special:Watchlist gekommen bin. Dies gilt für alle Spezialseiten auf Spezial:Spezialseiten plus die Namensräume hier aufgelistet http://de.wikipedia.org/wiki/Hilfe:Namensr%C3%A4ume#Bestandsauflistungen . Und endlich: Das aus Benutzer und Benutzerin "User" wird, ist mir ein willkommener Nebeneffekt. Die Namensraumkürzel sind eine etwas andere Frage, da sie selbst Weiterleitungen sind, da habe ich keine Meinung und würde diese Frage ausklammern. Liebe Grüße, --Erzbischof 15:32, 12. Jan. 2013 (CET)

Ah, das hat mir im Verständnis weitergeholfen.

Ich dachte, es ginge um diejenigen Links, die in der HTML-Seite (normale Ansicht oder Vorschau) stehen.

Das mit dem Adressfenster deines Browsers ist so eine Sache; ich vermute mal, dass das nicht klappt.

• Grundsätzlich sind JavaScript-Programmierer in der Lage, dir in das Adressfeld der aktuellen Seite die gewünschte URL mit englischsprachigen Namensräumen / kanonischen Spezialseitennamen hineinzuschreiben.
• Der Haken ist, dass in dem Moment ein neuer Seitenaufbau ausgelöst wird; rödel.
• Wenn die Seite dann neu aufgebaut ist, steht in diesem Adressfeld die deutschsprachige Normalisierung der URL; inklusive Benutzerin.

Ich sehe allenfalls folgende Lösungswege:

• Anzeige der URL-Variante in kleiner Schrift im Kopfbereich des Portals oder bei den Kästen im Fußbereich.
• Browser-spezifisches Add-On, das auf diesem Feld Zaubertricks vollführt; eine Wiki-Seite kommt dort nicht heran.

Es ist seitens der Browser-Programmierung beabsichtigt und aus Sicherheitsgründen aus der Seite selbst heraus nicht zu verändern, dass im Adressfeld exakt diejenige URL steht, von der der Server der Auffassung ist, dass sie zu dieser Seite gehört. Ansonsten könnte ich dir nämlich auch vorspiegeln, dass ich deine Banküberweisungen und TAN engegennehmen möchte, und auch sonst ließe sich beliebiger Schabernack treiben.

Beste Grüße --PerfektesChaos 16:06, 12. Jan. 2013 (CET)

Mir ist überhaupt nicht klar was das Problem ist. Es findet doch derzeit genau Folgendes statt: Gebe ich http://de.wikipedia.org/wiki/Special:Watchlist, gelange ich auf Beobachtungsliste http://de.wikipedia.org/wiki/Spezial:Beobachtungsliste. Wieso soll man das nicht umkehren sollen und was soll unsicher sein? LG, --Erzbischof 12:04, 25. Jan. 2013 (CET)

Es geht darum, wenn jemand auf https://de.wikipedia.org/wiki/Spezial:Beobachtungsliste ist, durch die Manipulation der Adresse in der Adresszeile des Browsers schnell nach en.wikipedia oder jeder anderen beliebigen Sprachversion zu kommen. Das ist nicht möglich, weil "Spezial:Beobachtungsliste" in en.wikipedia eine Artikelseite beschreibt. Aus en nach de ist es durch URL-Manipulation des Benutzers hingegen möglich. Der Umherirrende 16:46, 25. Jan. 2013 (CET)

Mit der Lokalisierung der Spezialseitennamen habe ich ebenfalls ein Problem. Ein extremes Beispiel ist http://tr.wikipedia.org/wiki/Özel:ÖnekDizini?uselang=en. Der angebliche Seitentitel „Özel:ÖnekDizini“ kommt auf der Seite, die sich öffnet, überhaupt nicht vor. Eine Einstellung würde nur in ganz wenigen Fällen helfen, solche Verwirrungen zu vermeiden. Die meiner Ansicht nach einzige Lösung, die nicht mit anderen Problemen wie Duplicate Content etc. daher kommt, ist das Abschalten der Übersetzung in der URI. Dort muss „Special:PrefixIndex“ stehen. Im sichtbaren Inhalt der Seite wird der Spezialseitenname natürlich übersetzt. Wird er ja sowieso (z. B. heißt Special:Longpages in der URI „Längste_Seiten“ und im Text „Lange Artikel“ oder anders, je nach Spracheinstellung). Bug 9040 ist seit 2007 offen, aber ich vermute, da die Entwickler alle englisch sprechen, interessiert sie das nicht. --TMg 18:43, 12. Jan. 2013 (CET)

@Erzbischof: Ist dir Benutzer:Schnark/js/specialinterwiki bekannt? --Leyo 17:15, 25. Jan. 2013 (CET)

Wikiquiz

Kann man hier auch Vorschläge für neue Schwesterprojekte machen? Wie wäre es mit einem Projekt „Wikiquiz“, wo man sagen wir mal für einen Wikipedia-Artikel 10 Fragen zusammenstellt, die ein Leser beantworten muss, um den Inhalt des Artikels verstanden zu haben? Ok, es gibt bereits Wikipedia:Quiz und zum Lernen gibt es Wikiversity, aber mir schwebt da eher etwas anderes vorher, womit man Wikipedia etwas auflockern könnte. Das Projekt sollte die Extension:Quiz nutzen und natürlich mehrsprachig sein. Das Quiz könnte dann unter den Weblinks im entsprechenden Wikipedia-Artikel verlinkt werden (so wie bei anderen Schwester-Projekten).--Sinuhe20 (Diskussion) 19:28, 14. Jan. 2013 (CET)

Spezial:Letzte Änderungen: Logbuch ausblenden

Gibt es eine Option, um bestimmte Logbücher auf Spezial:Letzte Änderungen auszublenden? Bzw. könnte man das realisieren? (Softwarerequest/Javascript) Derzeit finden sich da ja neben den normalen Edits die Neuanmeldungen, das Löschlogbuch und weitere. Konkret findet sich diese Idee/Problem hier: WP:AFT/N#Opt-Out in den RCs.

Dazu noch die Frage: Wie würde sich das Spezial:Logbuch/articlefeedbackv5 von dem Spezial:Letzte Änderungen-Feed für alle (per Konfigurationsänderung) entfernen lassen?--se4598 / ? 23:51, 14. Jan. 2013 (CET)

Ein Feature für eine weltweit realisierte Software-Änderung wird das wohl kaum werden.

• Schau aber mal auf WP:CSS:
  • WP:CSS #Identifizierung bestimmter Arten von Seiten – .mw-special-Recentchanges würde Anweisungen in deiner common.css auf diese Seite beschränken.
  • Weiter lässt sich dann ausnutzen: href="/wiki/Spezial:Logbuch/articlefeedbackv5 durch etwas wie

.mw-special-Recentchanges LI A[href="/wiki/Spezial:Logbuch/articlefeedbackv5"] {
   display: none;
}

• Alternativ lässt sich mit JS feststellen, dass WP:JS/V #wgCanonicalSpecialPageName anliegt und in diesem Fall mit WP:CSS#addCSS die oben stehende Anweisung für LI A gezielt aufdrücken.

Irgendwas für alle Benutzer auszublenden ist nicht Stil des Hauses.

Viel Erfolg --PerfektesChaos 23:41, 17. Jan. 2013 (CET)

Vorschlag: Dynamisches Inhaltsverzeichnis

Ich habe gestern an das Wikipedia Support-Team folgenden Vorschlag gesandt:

„Gegenwärtig ist das Inhaltsverzeichnis zu jedem Artikel statisch eingebunden. Der Benutzer muss dazu immer an den Beginn zurück-scrollen, wenn er rasch mal etwas Anderes einschieben will - und hat dann nachher oft schon vergessen, wo er vorher war. Außerdem wird bei diesem Design eine Menge Platz am linken Rand verschwendet, der meist nur ganz oben genützt wird und dann später einfach nur leer bleibt.

Bei meinem dynUIF hingegen wird ein dynamisches Inhaltsverzeichnis erzeugt. Der Benutzer findet es immer in der linken oberen Ecke des Bildschirms, egal wo im Artikel er gerade steht. Bewegt er die Maus dort hinauf, erscheint ein Menü mit dem Inhaltsverzeichnis und all den übrigen Links, die gegenwärtig den Platz im linken Rand verbrauchen. Das Menü ist wieder in sich strukturiert: Jedes Item kann auch ein 'Group Header' sein. Wenn der Benutzer darauf klickt, wird unter dem 'Header' eine Gruppe von Sub-Items sichtbar - von denen jedes wieder ein 'Group Header' sein kann, unter dem sich wieder eine Gruppe von Sub-Items verbirgt. - Wenn der Benutzer sein Menü wieder verkleinern will, braucht er nur eine Gruppe wegzuklicken. - Auf diese Weise können auch hunderte (oder sogar tausende) von Items benutzerfreundlich in einem Menü untergebracht werden. Außerdem könntet Ihr damit Eure Artikel bereit für on-screen-Markierungen durch den Benutzer machen. So etwas habe ich bisher noch nirgends in der online-Kommunikation gesehen - Wikipedia wäre hier wieder ein eindeutiger Pionier!

Wenn das interessant für Euch klingt, werde ich Euch gern eine Demo-Version davon mailen. Damit könnt Ihr Euch dann hands-on ein Urteil davon bilden!“

Darauf erhielt ich heute die Antwort:

„Die Inhaltsverzeichnisse in unseren Artikeln sind bereits dynamisch, da sie nur von der Software erzeugt werden, wenn mindestens 4 Artikelabschnitte vorhanden sind. Das Aussehen der Inhaltsverzeichnisse lässt sich in der Software anpassen, auch eine Verankerung an einer bestimmten Seitenposition ist möglich. Ob mehr möglich ist und ob Interesse an Ihrem Angebot besteht, müssten Sie unsere Techniker fragen: Wikipedia:Verbesserungsvorschläge“

Das tue ich hiermit. Ich muss es Ihnen überlassen, wie Sie nun weiter vorgehen wollen. M.f.G. Günter Gerdenitsch (nicht signierter Beitrag von 84.115.39.32 (Diskussion) 06:39, 22. Jan. 2013 (CET))

Hands-on? Handauflegen? ;-) Lade die Demo-Version einfach irgendwo hoch, so dass wir sie uns ansehen können. Ich denke aber, dass wir so etwas nicht brauchen. Wer würde eine solche Navigationsmethode erwarten und bedienen können, wenn man „so etwas bisher noch nirgends gesehen“ hat? Unsere Enzyklopädieartikel haben niemals „hunderte (oder sogar tausende) Items“, allenfalls mal ein paar Dutzend. Die weitaus meisten Artikel sind so kurz und so klar strukturiert, dass dafür häufig gar kein Inhaltsverzeichnis gebraucht wird. Deshalb wird es bei zu wenigen Überschriften auch ausgeblendet und lässt sich zuklappen. Aber vielleicht verstehe ich dich auch falsch. --TMg 15:21, 25. Jan. 2013 (CET)

Verlinkungen fremder Wikis

Es gibt ja die Möglcihkeit von WM-fremden Wikis Commons einzubinden. Praktisch wäre es aber wenn solche Verlinkungen bei Commons genauso wie WM-interne Verlinkungen angezeigt würden. Erstens wüte ein Fotograf, wenn eines seiner Fotos außerhalb Wikimedias Verwendung findet. Zweitens wäre es günstig, bei Löschungen, Verschiebungen etc. wenn man auch die WIkis außerhalb wissen würde. Vielleicht wäre es nötig, dass sich ein Wiki bei Commons registrieren muss, o.ä. aber das Internet lebt eben von Verlinken und kooperieren. --K@rl 20:09, 27. Feb. 2013 (CET)

Aktuell sind nur die Wikis der Wikimedia Foundation so miteinander verbunden. Ich halte es nicht für wünschenswert, beliebigen anderen Wikis zu erlauben, hier bei uns in den Linklisten aufzutauchen. Sagt dir das Stichwort Referrer-Spam etwas? --TMg 22:17, 27. Feb. 2013 (CET)

Das ist vielleicht falsch rüber gekommen. Bei Commons gibt es ja bewusst diese Features, siehe hier. Als Beipiel hier das hier. Es wäre nicht schlecht, wenn dies bei Dateiverwendung der Fotos auch aufscheinen würde. --K@rl 22:32, 27. Feb. 2013 (CET)

Ich denke, ich hatte dich richtig verstanden. Ich gebe dir Recht, dass solche Weiternutzungen überhaupt irgendwo einsehbar sein sollten. Allerdings nicht eingestreut in die normalen Linklisten sondern losgelöst davon, bspw. per Tool. --TMg 21:06, 16. Mär. 2013 (CET)

Sichten erleichtern

Wie wäre es mit einer Funktion/Extension, mit der man als aktiver Sichter automatisierte Sichtungen durchführen kann? Es ist doch ein bekanntes Problem, dass die WP mit den Sichtungen hinterherhinkt - Seiten wie Spezial:Seiten_mit_ungesichteten_Versionen und Spezial:Ungesichtete_Seiten sind IMHO jedoch völlig unstrukturiert und auch nur mäßig hilfreich, denn z.B. Spezial:Ungesichtete_Seiten ist nicht einmal nach Datum geordnet, was bedeutet, dass vor allem Artikel mit Anfangsbuchstaben aus der Mitte oder dem Ende des Alphabets erst später gesichtet werden, als Seiten mit A... oder B...

Ich schlage daher zwei Änderungen/Neuerungen vor:

1. sollte Spezial:Ungesichtete_Seiten (wie es bei Spezial:Seiten_mit_ungesichteten_Versionen bereits Realität ist) künftig nach dem Datum ihrer letzten Sichtung sortiert werden, statt nach dem Alphabet, um schon lange ungesichtete Seiten nach vorne rücken zu lassen.
2. schlage ich eine Funktion/Extension vor, mit der ein Editor leichter Artikel sichten kann; Ich stelle mir das so vor, dass man automatisch (und nach dem Datum der letzten Sichtung geordnet) von Artikel zu Artikel weitergeleitet wird, um diese dann (wie am Fließband) sichten zu können - bzw. ggf. andere Maßnahmen zu ergreifen. Dies würde dadurch ermöglicht, dass den Sichtungs-Buttons ein weiterer Knopf "Weiter zur nächsten Seite" (o.ä.) hinzugefügt wird, wodurch man automatisch zur nächsten ungesichteten Seite weitergeleitet wird. Ich erhoffe mir davon eine schnellere und effektivere Sichtung, sowie ein Abbau der noch ungesichteten Versionen. Ggf. könnten dabei potenziell vandalierte Seiten, oder Neuanlagen von Newbies bevorzugt werden.

Grüße — Alleskoenner (Diskussion) 18:04, 15. Mär. 2013 (CET)

Zu 2.: Geht das nicht genau so mit Huggle? Oder ist das Sichten da immer noch nicht aktiviert? XenonX3 - (☎) 18:11, 15. Mär. 2013 (CET)

Hm, also 1. hab ich kein Huggle und 2. keine Ahnung - wenn nicht, sollte man das vielleicht machen ;-) Grüße — Alleskoenner (Diskussion) 18:17, 15. Mär. 2013 (CET)

Du scheinst Spezial:Ungesichtete Seiten nicht verstanden zu haben. Die dort gelisten Seiten wurden noch nie gesichtet, somit kann man sie nicht nach dem Datum der letzten Sichtung sortieren. Eine Sortierung nach Artikelanlage wäre vermutlich das, was du bräuchtest oder eine Sortierung nach letzter Bearbeitung (zumindestens ist die angezeigte Zeitdifferenz im Verhältnis dazu). Eine solche Funktionalität kannst du über Bugzilla beauftragen. Da bereits über 1 Mio. Artikel ohne "Fließband" gesichtet wurde, wird es das für den Rest wohl auch nicht brauchen. Vielleicht findet sich unter WP:GSV noch ein Tool für deine belange. Der Umherirrende 18:59, 15. Mär. 2013 (CET)

Doch, ich habe die Seite verstanden und selbstverständlich meinte ich in diesem Fall das Datum der Anlage.

Dass bereuts über 1 Mio. Artikel ohne ein entspr. Tool gesichtet wurden sagt aber doch nicht aus, dass es mit einem solchen Tool nicht besser und schneller gehen würde?! Grüße — Alleskoenner (Diskussion) 19:34, 15. Mär. 2013 (CET)

1. find ich gut. Sollte per Button nach Datum der Seitenanlage sortiert werden können (und sowohl älteste als auch neueste zuerst), ABC kann ja zusätzlich bleiben. Hab mich schon oft gewundert, warum es die Möglichkeit nicht gibt. Außerdem sollte man auch gezielt die Artikel dabei ausblenden können und nur die WL anzeigen lassen, damit man die schneller gesichtet bekommen kann, sonst ist das sehr umständlich. Oder nach Seitengröße sortieren können. Dann könnten zumindest die WL und kleineren Seiten schneller gesichtet werden. Nur nach Alphabet ist das weniger motivierend. Und wenn die kleineren Seiten schneller gesichtet würden, wären es insgesamt gleich viel weniger. Die Sortierungsmöglichkeiten lassen dort sehr zu wünschen übrig, weshalb das auch immer ein ziemliches Erstsichtungslag bedeutet. Und dann hat man später viel mehr Versionen durchzusehen. Es wäre besser, neue Artikel und WL auch gezielt zügig erstsichten zu können, dann bliebe hinten raus weniger Lag übrig. --Geitost 21:46, 15. Mär. 2013 (CET)

Sicher liegt es an mir, aber mir kommt das unlogisch vor: Warum sollte man noch nie gesichtete Seiten unbedingt sichten müssen? Ungesichtete Bearbeitungen zu sichten ist wichtig, vor allem weil es den Bearbeiter frustet, wenn seine Verbesserung nicht sichtbar wird. Bei noch nie gesichteten Seiten gibt es dieses Problem nicht. Alles wird sofort sichtbar. Wie früher. Es reicht völlig, dort mal auf „Sichten“ zu klicken, wenn man sowieso an dem Artikel arbeitet. Die ungesichteten Seiten massenhaft nachzusichten erzeugt im Gegenteil mehr Stress bei den ungesichteten Bearbeitungen. --TMg 21:14, 16. Mär. 2013 (CET)

Erweiterung zur Anzeige von Einbindungen bei Commons

Nachdem es derzeit bei Wikipedia genauso wie bei Wikimediafremden Wikis keine Möglichkeit gibt, einfach anzuzeigen, welche Bilder oder Dateien von Commons eingebunden sind, wäre eine Erweiterung recht praktisch, sodass es genauso wie die Spezial:Präfixindex anzeigen, wo ich nur die fremden Dateinamen sehe. --K@rl 13:23, 21. Mär. 2013 (CET)