Wikipedia:Verbesserungsvorschläge/Feature-Requests

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 30 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten.

Automatische Archivierung

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

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

Vorlage:Autoarchiv-Erledigt/Wartung/Festes_Ziel

Dauerbrenner

• Cursor im Suchfeld: Bug 1864 (als Gadget verfügbar: Spezial:Einstellungen -> Gadgets -> 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

Feature-Requests

Metainfo in Sprachennamen

Auch ich merke gerade, daß ich hierher hätte posten sollen und verweise auf Wikipedia:Verbesserungsvorschläge#Kleine kosmetische Änderung. Wikipeditor

Auch unter Werkzeuge

Ein Verlinkung von jedem Artikel auf das Logbuch. Das wäre auch für die Vorlage bei nicht vorhandenen Artikeln sinnvoll, siehe Benutzer:TMg/Vorlage:MediaWiki Newarticletext NS (bzw. die Diskussion). Andererseits ist das Logbuch in anderen Vorlagen überhaupt nicht verlinkt (wahrscheinlich in jedem anderen Namespace). -- Amtiss, SNAFU ? 13:20, 8. Sep 2006 (CEST)

Vorschlagserweiterung

Nach weiteren Diskussionen würde ich den Vorschlag wie folgt erweitern:

Jeder Vorlage sollte ein Typ-Flag zugeordnet werden, welches die vom Autoren gewünschte Einbindungsart angibt: Subst, Nosubst oder Mixed. Bei 'Subst' bzw. 'Nosubst' würde die Software bei der Einbindung der Vorlgae in anderen Seiten diese entsprechend vornehmen, bei 'Mixed' wäre es weiterhin optional. Dies könnte über den Parser-Check nach Vorlagen-Edit erfolgen (als Fehlermeldung in der Art „Sie haben noch keinen Vorlagentyp festgelegt, bitte tragen Sie das entsprechende Flag vor dem Speichern ein: Subst/Nosubst/Mixed/'Ich weiß nicht'“), so dass mit der Zeit jede (aktive) Vorlage ein entsprechendes Flag erhält. Dadurch würden dann bei 'Subst'-Vorlagen auch die ungesubsten Einbindungen mit der Zeit (beim nächsten Parsen nach Edits) gesubst, so dass auch hier die Aktualisierungen weitgehend automatisch erfolgen würde... --NB > ?! > +/- 09:09, 14. Sep 2006 (CEST)

Spezialseite:Anzeigen von Einleitungen

Die folgende Anfrage ist bereits mit einigen Benutzern diskutiert und wäre nach überwiegender Auffassung eine brauchbare Verbesserung, die sich auch umsetzen lassen könnte.

Konzept

Gesucht wird eine Spezialseiten-Funktion, die die Einleitungen aller Artikel einer Kategorie auf einer zu generierenden Seite anzeigen kann. Dabei sollen druckbare Seiten (Druckvorlage) entstehen, die wie die Seiten einer herkömmlichen Enzyklopädie aussehen und z.B. zu Readern oder Büchern gebunden werden können.

• das Skript sollte erkennen, wo die Einleitung beginnt und aufhört
• es sollte Vorlagen, Tabellen und andere Quelltextbestandteile vor dem Beginn des ersten Abschnitts ausklammern können
• wenn Bilder in der Druckvorlage gewünscht sind (selten), könnten diese vielleicht im Quelltext entspechend markiert werden, damit sie vom Skript erkannt werden
• auf der Druckvorlage zwei Spalten pro Seite, der Text formatiert

Weitere Bemerkungen

• Anders als für den Artikelkörper, für den ausführliche und umfassende Inhalte erwünscht sind, sollen die Einleitungen das Lemma und den Artikelinhalt kurz, aber möglichst vollständig erlären.[1] Damit liegt ein brauchbarer Text, allerdings mit geringerer Ausführlichkeit vor. Vermutlich wird deshalb eine Begrenzung aller Einleitung auf eine noch zu diskutierende Zeichenzahl wünschenswert sein. Artikeleinleitungen, die diese Begrenzung überschreiten, könnten in der Druckvorlage ausgespart oder stilistisch umgestaltet und komprimiert werden, damit die Spezialseite auch diese Artikel in das Druckbild integrieren kann.

Anwendungen

• Überall dort, wo kurze Artikel ausgedruckt werden sollen.
• Überall dort, wo Einleitungen der Reihe nach abgearbeitet werden sollen.
• Erstellung von Übersichten, um die Qualität der Einleitungen vieler Artikel beurteilen, verbessern und stilistisch und formal vereinheitlichen zu können.

Diskussion und Vorschläge

Bei der Realisierung der Idee werden wahrscheinlich noch einige konzeptionelle Probleme auftreten. Bitte beteiligt euch, indem ihr sie nennt. -- Carl 23:56, 29. Okt. 2007 (CET)

Probleme dürfte es vor allem mit Templates geben: einige will man ausfiltern (z.B. Taxoboxen, Neutralitätswarnungen, etc), andere will man auflösen (z.B. Lautschrift). Ansonsten wäre zu überlegen, ob man wirklich immer den ganzen abschnitt bis zur ersten Überschrift haben will, oder ob nicht auch der erste Absatz reicht - oder gar der erste Satz. Evtl sollte das Tool flexibel genug sein, das als Option anzubieten.

Ganz praktisch ist eine Umsetzung als Spezialseite wohl nicht möglich - das laden und auswerten aller Artikel einer Kategorie dauert einfach zu lange, um das "dynamisch" machen zu können. Als Tool das auf einem Dump arbeitet (oder auf der Datenbankkopie auf dem Toolserver), und alle paar Wochen solche Auszüge für eine Kategorie (oder auch alle Artikel) erstellt, wäre durchaus machbar. Ich würde das evtl sogar machen, aber erst in ein paar Monaten. -- Duesentrieb ⇌ 00:06, 30. Okt. 2007 (CET)

Gute Idee, dann könnten andere Webseiten(z.B. Google) Kurzdefinitionen anzeigen. Die Einleitung sollte man mit <def> </def> auszeichnen. mfg --Uranus95 16:53, 19. Jan. 2009 (CET)

Ich denke, das ist mit Wikipedia:Helferlein/Navigation-Popups auch gut zu lösen. Der Umherirrende 18:14, 7. Feb. 2009 (CET)

Verbesserung des ref-Elements für Quellenangaben

Mit der Einführung des ref-Elements können endlich sehr schön Quellenangaben gemacht werden. Diese orientieren sich offensichtlich an Quellenangaben in wissenschaftlichen Arbeiten. Allerdings ist die momentane Umsetzung nicht eindeutig, worauf sich die Quellenangabe bezieht. Ich verdeutliche das am folgenden Beispiel:

• Dies ist der erste Satz. Dies ist der zweite Satz.[ref]Quellenangabe[/ref]

Es ist offensichtlich, dass man nicht erkennen kann, ob sich die Quellenangabe auf beide Sätze bezieht oder nur den zweiten. Ich schlage daher folgendes Markup vor:

• Dies ist der erste Satz. [ref source="Quellenangabe"]Dies ist der zweite Satz.[/ref]

Hier ist eindeutig, dass die Quellenangabe sich nur auf den zweiten Satz bezieht statt auf beide. Merkwürdigerweise wurde nämlich im alten ersten Fall mit dem ref-Element ein Text ausgezeichnet, der eigentlich ein Attribut eines Textes sein müsste. Dies widerspricht der XML-Idee. Beste Grüße 85.178.41.71 13:28, 30. Nov. 2008 (CET)

Diesem Wunsch schließe ich nochmals meinen bereits archivierten Wunsch an. Quellenangaben sollten auch für Neulinge erleichtert werden. Für Quellenangaben sollte ein Button eingeführt werden, wie er für Fettdruck usw. schon besteht. Der Wunsch nach Quellenangaben sollten zum Dauerbrenner werden, da die Quellenangaben doch immer an Wikipedia kritisiert werden. --Christian stroppel 09:45, 1. Dez. 2008 (CET)

Der Button existiert bereits, siehe Einstellungen → Bearb.werkzeuge → „Das Extra-Editbuttons-Helferlein erweitert die Bearbeitungswerkzeugleiste“. Jedenfalls habe ich ihn dorther. -- Wwwurm Mien Klönschnack 09:54, 1. Dez. 2008 (CET)

Gibt es denn Kommentare zu meinem Voschlag? Ich halte die Veränderung des ref-Elements für sehr wichtig. 85.178.35.175 07:02, 11. Dez. 2008 (CET)

Ich halte den Vorschlag für sinnvoll, da man in der Tat oft nicht genau weiß, worauf sich eine Quellenangabe bezieht. Für weitere Autoren könnte das also hilfreich sein. Leider sieht der Leser dennoch nur eine Zahl, was natürlich schade ist. --Christian stroppel 17:14, 2. Jan. 2009 (CET)

Man könnte es ja beim Rüberfahren mit der Maus dann einfärben oder so. Ich finde den Vorschlag gut! Stern 20:40, 4. Jan. 2009 (CET)

Sehr guter Vorschlag, dann hätte auch der Leser etwas davon.--Christian stroppel 21:31, 5. Jan. 2009 (CET)

Die Idee ist nicht schlecht, ich sehe aber zwei Probleme:

• Wenn die Quellenangabe als Attribut eines XML-Elements notiert wird, können darin keine anderen Textauszeichnungen mehr benutzt werden (Z.B. <ref source="<small>Foobar</small>">...</ref> funktioniert nicht)
• Änderungen an der Wikisysntax müssen Rückwärtskompatibel sein, sonst müssten nach der Änderung projektübergreifend x Millionen Artikel angepasst werden.

Gruß --P.Copp 13:09, 1. Feb. 2009 (CET)

Standardbildgröße bei thumb nach der Fläche statt der Breite ausrichten

Bild1

Bild2

Bild3

Bild4

Mich stört irgendwie schon immer, dass die mit thumb markierten und ohne px-Angaben formatierten Bild alleine nach der Breite ausgerichtet werden. Alle Bild erhalten dadurch die Breite 180px. Das ist an sich nur für quadratische Bilder optimal, zumindest auf meinem Bildschirm. Hochkantbilder wirken dadurch oft viel zu groß, während Breitformatbilder sehr schmal sind. Nebenan verdeutliche ich das mit zwei Abbildungen. Mein Vorschlag wäre es nun, nach der Fläche, statt nach der Breite zu gehen. Als Optimalfläche könnte man zum Beispiel 200 x 200 = 40.000 Pixel wählen. Ein mit thumb markiertes Bild wird dann automatisch auf diese Fläche verkleinert, so wie ich das mit Bild3 und Bild4 gemacht habe. Hierzu wird Breite b mal Höhe h gerechnet, um die Fläche f zu erhalten. Typischerweise ist diese nun größer als 40.000 Pixel, sodass sie entsprechend runterskaliert werden muss. Für Bild1 ist die Fläche zum Beispiel 7.208.132, also etwa 180,2033 mal größer als gewollt. Die Wurzel davon ist 13,42398. Also muss die Breite durch diesen Wert geteilt werden: 246. Analog habe ich dann auch für das andere Bild gerechnet. Ich hoffe, Ihr gebt mir Recht, wenn ich behaupte, dass die unteren beiden Bilder besser zusammenpassen als die beiden oberen. Ich hoffe auch, dass ich richtig gerechnet habe (zumindest komme ich näherungsweise auf 40.000 Pixel). Stern 21:03, 4. Jan. 2009 (CET)

Dazu gibt es eigentlich längst den Parameter "upright", siehe hier. Leider ist der Parameter für hochformatige Bilder nicht sehr bekannt und stößt auch auf Widerstand, wie ich feststellen musste. Ein "Flächenautomatismus" wäre also vielleicht nicht so schlecht. --Brunosimonsara 22:22, 4. Jan. 2009 (CET)

Wir sind eben alles Kriechtiere die die horizontale einerseits mehr gewichten und andererseits auch eher annehmen ;-)-- visi-on 16:47, 22. Jan. 2009 (CET)

stimmt, klingt intuitiv einleuchtend, mit hochkant (upright) und querformat könnte man immer noch nachbessern - wär zu überlegen, dann für thumb und gallery denselben wert zu nehmen.. --W!B: 08:53, 22. Jan. 2009 (CET)

dann hat aber jedes Bild eine andere Breite. Schöner Flattersatz -- visi-on 09:52, 22. Jan. 2009 (CET)

immer noch besser als einmal klein (quer) und einmal groß (hoch). Das schafft zudem den Eindruck, dass die hochformatigen Bilder wichtiger sind, weil sie ja viel größer sind. --Brunosimonsara 15:56, 22. Jan. 2009 (CET)

Ich finde den Flattersatz auch viel weniger störend als die ungleiche Gewichtung, die wirklich oft stört und Breitformatbilder oft unterkennbar macht. Stern 19:05, 30. Jan. 2009 (CET)

stimmt, ausserdem haben wir mit infoboxen und anderem auch noch etliche andere seitenelemente, die sich auf den rechten rand auswirken, karten werden meist sowieso etwa upright=1.5/ca. 270-330px gesetzt, illustrationen und graphiken je nach lesbarkeit ganz anders - es dreht sich also mehr um den begriff foto als „bild“ im engerne sinne --W!B: 16:18, 31. Jan. 2009 (CET)

Beobachtung von Kategorien

Wenn man eine Kategorie beobachtet, sollte man auf der Beobachtungsliste darüber informiert werden, wenn ein neuer Artikel in die Kategorie aufgenommen wurde. --Uranus95 16:57, 19. Jan. 2009 (CET)

Es gibt die Extension:CategoryWatch, die diese Funktionaliät liefert. Ob oder wann eine Aktivierung hier möglich ist, kann ich aber nicht sagen. Der Umherirrende 20:32, 26. Jan. 2009 (CET)

Automatisches Einfügen der Signatur auf Diskussionsseiten

Wäre es nicht sinnvoll, wenn Beiträge, die man auf Diskussionsseiten macht, automatisch mit einer Signatur versehen werden? So wäre immer klar, welcher Beitrag von wem stammt (keine Möglichkeit der "Fälschung") und die Signatur müsste bei Versäumnis nicht via Vorlage:Unsigned erst sichtbar gemacht werden. Cheers, --Till Kraemer 13:33, 24. Jan. 2009 (CET)

Keine schlechte Idee, sie hat jedoch einen Haken: Wie willst du das machen, wenn man beispielsweise auf Diskussionsseiten eine Vorlage (Autoarchiv, Diskussionsseite etc.) einträgt? Da soll ja nicht immer gleich eine Signatur hinzugefügt werden? Oder wenn man nachträglich etwas am eigenen Diskussionsbeitrag korrigiert? Vor allem IPs und noch nicht lange angemeldete Benutzer, die die Vorschau-Funktion noch nicht nutzen, korrigieren bzw. ändern ihre Diskussionsbeiträge fleißig im Nachhinein (siehe bspw. [2]). Debianux 12:16, 25. Jan. 2009 (CET)

Naja, dann müsste man diese Konditionen halt festlegen. Vorlagen lassen sich doch soweit ich weiß immer an den {{...}} erkennen und das Script könnte doch auch checken, ob man den eigenen Beitrag korrigiert (z.B. dadurch, dass man ja beim Korrigieren nicht unterhalb seiner eigenen Signatur schreibt - das Script muss also nur checken, wo die letzte fremde Signatur bzw. der Anfang der Seite ist und wo die eigene Signatur und wenn man dazwischen schreibt, setzt es halt keine erneute Signatur drunter). Wenn letztere Geschichte zu aufwendig ist, könnte man die Korrektur des eigenen Beitrages zur Not auch einfach in klein dahinter schreiben und irgendwie vermerken, dass es ein Nachtrag, bzw. eine Korrektur ist. Cheers, --Till Kraemer 18:10, 25. Jan. 2009 (CET)

ich gehe davon aus, dass es dazu bereits mehrere diskussionen gibt. man muesste vielleicht mal im bugzilla und den mailing lists stoebern. es gibt vermutlich mehr haken als die bereits genannten. aber heuristische abfragen, die schauen, ob etwas eine signatur verdient oder nicht, kann man basteln. in en-wiki gibt es ja z.b. auch bereits bots, die das nachtraegliche signieren uebernehmen. die liegen aber halt auch nicht immer richtig. -- seth 19:19, 25. Jan. 2009 (CET)

Das Monobook von PDD hat eine Funktion, die "automatische Unterschrift auf Diskussionsseiten" ermöglicht, ich nutze diese Funktion nicht, kann mir aber vorstellen, das die gewünschtes Verhalten bringt. Das Skript liegt auf Benutzer:Olliminatore/signing.js. Vielleicht kannst du damit etwas anfangen. Der Umherirrende 20:00, 25. Jan. 2009 (CET)

Namensraum Auswahl umkehren auch für whatlinks

so, wie die Beobachtungsliste es hat: wäre ein grosser service, um festzustellen, wo über einen artikel diskutiert wurde: jetzt muss man sich durch alle durchklicken, je nachdem ob LK (Wikipedia), Projekte (Wikipedia Diskussion), Portal Diskussion, Benutzer, .. --W!B: 10:41, 27. Jan. 2009 (CET)

Siehe Bugzilla:16848: Special:WhatLinksHere should allow invert namespace selection. — Raymond ^{Disk. Bew.} 14:01, 27. Jan. 2009 (CET)

danke Dir! --W!B: 18:59, 27. Jan. 2009 (CET)

Sperren von Seiten für einzelne Benutzer

Z.B.bei einem Edit-War, sollten nur die am Edit-War Beteiligten der Schreibzugriff gesperrt werden und nicht allen Benutzern. --Uranus95 13:41, 2. Feb. 2009 (CET)

ja, darauf warte ich auch schon lange: siehe bugzilla:674. -- seth 16:16, 2. Feb. 2009 (CET)

Eingebundene Vorlagen ausblenden

Hallo, ich hätte mal einen Verbesserungsvorschlag für Spezial:Linkliste. Was mich schon länger stört ist, dass man Links, die nur durch Vorlageneinbindungen entstehen, nicht ausblenden kann. Bestes Beispiel sind Links auf Seiten, die durch Navigationsleisten generiert werden. Ich würde mir nun ein Schaltfeld „eingebundene Vorlagen ausblenden“ wünschen, durch das man Links durch Vorlageneinbindungen ausblenden kann. Das ist eine andere Funktion als „Vorlageneinbindungen ausblenden“, durch die lediglich andere Artikel, in denen die betrachtete Seite eingebunden wird, ausgeblendet werden.

Ein kleines Beispiel: in Forschungsreaktor Neuherberg gibt es unten eine Navigationsleiste mit ca. 20 Links auf andere Forschungsreaktoren. Die Linkliste würde sehr viel übersichtlicher sein, wenn man diese 20 Links ausblenden könnte:

• 
  Linkliste mit Links aus Vorlageneinbindungen
• 
  Linkliste ohne Links aus Vorlageneinbindungen

Ist das technisch machbar? Viele Grüße, --Quartl 10:47, 5. Feb. 2009 (CET)

Wo schlage ich die Schaffung neuer Tools für den Toolserver vor? Oder kann das jemand hier lösen?

Ichhätte gerne Tools, die mir folgendes ausgeben:

• meistverlinkte Artikel einer Kategorie
• Meistbesuchte Seiten einer Kategorie
• Meisteditierte Seiten einer Kategorie

Mit diesen Tools könnte man wichtige Seiten eines Themas identifizieren. Ich kann das aber nicht selber machen. Wo schlage ich vor, dass so diese Tools eingerichtet werden? --source 11:28, 7. Feb. 2009 (CET)

meistverlinkte Artikel einer Kategorie

Zu erstens habe ich gerade mal eine Datenbankabfrage durchgeführt. Die läuft jetzt bereits seit 330 Sekunken (da muss mal drei Tables joinen). Somit kann ich schonmal sagen, dass das Webtool nicht zu gebrauchen sein wird. Gruß, --Revolus Echo der Stille 19:24, 7. Feb. 2009 (CET)

zu erstens, "meistverlinkte Artikel einer Kategorie", stelle ich mir das eigentlich recht einfach vor. 1. Nur Artikel einer Kategorie betrachten und 2. bei jedem mit der Seite "Links auf diese Seite" zählen wieviele Seiten auf dem Artikel verweisen. (Idealerweise könnte man nur Verlinkte Seiten aus dem Artikelnamensraum zählen). Man würde im Tool die Kategorie eingeben, und das tool spukt aus, wieviele Namensraumseiten auf die jeweilgen Kategorieseiten verweisen. Bei manchen Kategorien kann man das ja schon fast von Hand machen. --source 19:31, 7. Feb. 2009 (CET)

Ich weiß nicht, ob ich das falsch angehe, aber müsste das nicht irgendetwas derartiges sein:

SELECT `page_title`, COUNT(*)
FROM `categorylinks`
  JOIN `page` AS `sup` ON `page_id` = `cl_from`
  JOIN `pagelinks` ON `pl_title` = `page_title` AND `pl_namespace` = `page_namespace`
WHERE `cl_to` = 'Informatik'
  AND (SELECT `page_namespace`
    FROM `page` AS `sub`
    WHERE `sub`.`page_id` = `sup`.`page_id`
  ) = 0
GROUP BY `page_title`
LIMIT 100;

[3] [4] [5] Aber meine SQL-Kenntnisse sind auch noch nicht allzu gut. --Revolus Echo der Stille 19:47, 7. Feb. 2009 (CET)

Sieht gut aus.. Bei pl_title = pl_title hast du dich wohl vertippt.. Bei größeren Kategorien wäre wohl noch ein ORDER BY hilfreich. Die Subquery würde ich als weiteren JOIN mit reinbringen, das ist aber wahrscheinlich nur Geschmackssache. Gruß --P.Copp 13:33, 8. Feb. 2009 (CET) P.S. Das DISTINCT würde ich noch weglassen, das sollte hier nicht benötigt werden und verlangsamt evtl. die Abfrage. --P.Copp 13:47, 8. Feb. 2009 (CET)

Danke für den Hinweis! Hab es berichtigt. Jetzt klappt es zumindest bei nicht allzu vollen Kategorien wie Kategorie:Informatik, nur will ich das Tool nicht hosten (könnte mein DB-Server-Verbindungslimit ausreitzen). Wo man nun darum bitten kann, dass einer das auf den Toolserver stellt, kann ich aber auch nicht sagen. @P.Copp: Magst du dich nicht vielleicht für einen TS-Account bewerben? --Revolus Echo der Stille 15:50, 8. Feb. 2009 (CET)

Ehrlich gesagt, wüsste ich gar nicht, was ich konkret auf dem Toolserver machen sollte.. Außerdem habe ich mal gehört, dass die Ressourcen dort eher knapp sind, da würde sich ein un- oder kaum -genutzter Account wohl nicht so gut machen :) --P.Copp 16:56, 8. Feb. 2009 (CET)

Der Server ist nicht der schnellste, ein ungenutzter Account sollte aber nicht viel ausmachen ;). Bald gibt es aber einen weiteren Webserver, der das ganze wieder beschleunigen sollte. Ich denke aber, dass dir ein Account helfen würde, alleine wenn ich daran denke, wie oft ich einfach mal in die de-wiki-sql-table gehe, um irgendwelche Abfragen mal laufen zu lassen... kann ziemlich nützlich sein ;). --APPER\^☺☹ 18:54, 16. Feb. 2009 (CET)

Hm, wenn ich mir meta:Toolserver/New_accounts so anschaue, werden aber inaktive Accounts schon nach einer Weile gelöscht.. Ich denke, ich warte damit bis ich etwas mehr Zeit zur Verfügung habe, um mich darum zu kümmern. Trotzdem danke für den Tipp euch beiden :). Gruß --P.Copp 18:36, 17. Feb. 2009 (CET)

Das wär mir neu. Es wird einmal im Jahr eine Anfrage über die Mailingsliste geschickt und jeder, der den Account noch will, muss antworten, damit der Account verlängert wird. Ansonsten werden meiner Meinung nach keine inaktiven Accounts gelöscht, aber ich bin ja auch seit Jahren nicht mehr dafür zuständig, also alles ohne Gewähr ;). --APPER\^☺☹ 19:30, 17. Feb. 2009 (CET)

Ich hab hier mal angefragt, hab aber das Gefühl, dass die Seite ziemlich tot ist. Es scheint keinen zentralen ORt für Toolvorschläge zu geben. Gruß --source 16:12, 8. Feb. 2009 (CET)

Nochmal mein Tipp: Wenn es dir um eine bestimmte Kategorie geht, frag am Besten konkret jemanden, dir die entsprechende Liste auszuspucken. Darauf zu warten, dass jemand ein solches Tool erstellt, kann lange dauern, falls es überhaupt effizient möglich sein sollte. Gruß --P.Copp 16:56, 8. Feb. 2009 (CET)