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

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/2009#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Verschiebung von Seitenschutzlogbuch

Hallo, ich weiß nicht, ob dies technisch machbar ist, schlage es aber an dieser Stelle trotzdem mal vor: Derzeit wird beim verschieben eines Artikels ein evtl. vorhandene Seitensperre mitverschoben. Dagegen bleibt das Seitenschutz-Logbuch beim alten Lemma. Dies hat zur Folge, dass die Seitensperrung nur noch schwierig nachvollzogen werden kann.

Aktuelles Beispiel: Windkraftanlage: Wurde 2006 unter dem Lemma Windenergieanlage gesperrt (Logbuch) – dann inklusive Sperre auf Windkraftanlage verschoben. Im Logbuch der „Windkraftanlage“ findet sich dementsprechend kein vermerk über eine Sperrung (Logbuch). Als ich heute für einen Entsperrung den Sperrgrund und Zeitpunkt nachschlagen wollte, fand ich diesen erst nach einigem Suchen unter dem alten Lemma.

Ließe sich also, wenn eine Seite incl. Sperre verschoben wird, auch der entsprechende Logbucheintrag mitverschieben? Grüße --Herr Meier (Disk.) 23:25, 13. Jan. 2009 (CET)

Das gibt's schon, aber noch nicht so lange. Vergleiche diesen Logbucheintrag vom September. Die entsprechenden Logbucheinträge wurden jedoch nicht rückwirkend erstellt. -- PaterMcFly Diskussion ^Beiträge 08:15, 14. Jan. 2009 (CET)

Danke für den Hinweis! Damit hat sich das natürlich erledigt. --Herr Meier (Disk.) 20:44, 14. Jan. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Herr Meier (Disk.) 20:44, 14. Jan. 2009 (CET)

SUL-Status-Informationen per API

Ich nutze diese Seite einfach mal im Wissen, das einige Softwareentwickler mitlesen und somit eventuelle Informationen über Möglichkeit geben können oder vielleicht auch einstellen.
Mein Anliegen: Per API ist es derzeit nicht möglich Informationen über den SUL-Status eines Benutzers/Konto zu erfahren.
Ich stelle mir vor, das man bei list=users eine Option angeben könnte, mit dem Ergebnis, ob das Konto zum globalen gehört (attached/unattached) und ob es überhaupt ein globales Konto ist. Diese Informationen sind derzeit nur per Spezial:Globale Benutzerliste oder sulutil: verfügbar.
Zusätzlich könnte man meta=userinfo eine Option hinzufügen, um den Inhalt von Spezial:Benutzerkonten zusammenführen (nach erfolgreicher Zusammenführung) abzurufen.
Vielen Dank für eine Einschätzung. Verbesserungen oder Einwände sind natürlich willkommen. Der Umherirrende 21:12, 5. Jan. 2009 (CET)

bugzilla:17234 und bugzilla:17235, zusätzlich gibt es auch bugzilla:17233, was sich aber mit einem anderen Thema beschäftigt (nur der vollständigkeitshalber nenne ich das) --Der Umherirrende 20:54, 29. Jan. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 20:54, 29. Jan. 2009 (CET)

Barrierefreies Webdesign

Für behinderte Menschen sind die Schaltflächen wie "Artikel" und "Suche" nur schwer zu bedienen. Dies lässt sich mit dem Tool http://wave.webaim.org/ auch überprüfen. Gruß Christian., 22. Okt. 2006.

solle bei Wikipedia:BIENE erläutert werden --Der Umherirrende 18:14, 7. Feb. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:14, 7. Feb. 2009 (CET)

dvd update

Da die Wiki-DVD immer umfangreicher wird, wäre eine update-version sinnvoll: nur neue oder veränderte daten werden nachgeladen (inkrementeller zuwachs) - das würde möglicherweise einen neuen zeno-reader bedingen.

Updates gab es schon, siehe Wikipedia:DVD --Der Umherirrende 18:14, 7. Feb. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 18:14, 7. Feb. 2009 (CET)

Vorlage zum Ergänzen von Schlüsselworten für die Wikipedia-Suche

Es sollte möglich sein, in einem Artikel oder gleich zielgenau in einem Abschnitt ein Schlüsselwort zu hinterlegen (ohne dass es im Text auftaucht), sodass die Wikipedia-Suche nach diesem Wort dann an prominenter Stelle einen Treffer für diese Stelle ausgibt. Natürlich werden in der Regel solche themarelevanten Begriffe einfach im Text stehen und dadurch für die Suche auffindbar sein, aber erstens findet die Suche teilweise elend viele Fundstellen, wo der Suchbegriff einfach benutzt und nicht weiter ausgeführt wird, und man sucht dann in den Suchergebnissen die Stecknadel im Heuhaufen. Zweitens möchte man die Artikeltexte ja auch nicht gekünstelt mit allen möglichen Synonymen und nicht-intuitiven Flexionsformen von mit dem Thema zusammenhängenden Begriffen überladen, insbesondere da der nächste Bearbeiter ja nichts vom Motiv „Auffindbarkeit“ ahnen muss und die Stelle vielleicht stilistisch verbessert, und schon ist das Schlagwort wieder weg.

Anlass dafür, den Vorschlag jetzt zu stellen, war mein Versuch, Dreimeterbrett auf Sprungturm weiterzuleiten, was schnellgelöscht wurde, und vermutlich mit Recht. Dreimeterbrett ist ein gängiges Wort (steht auch im Duden), die WP-Suche findet aber nichts Gutes, ein nach dem Artikel über Dreimeterbretter suchender Benutzer würde es wohl am ehesten bei Sprungbrett weiter versuchen und von da aus vielleicht zum Wasserspringen gelangen, wo er die Chance hat, hinter „Turm“ den Link auf Sprungturm zu finden. Aber Dreimeterbrett ist eben kein Synonym für Sprungturm, und der Sprungturm-Artikel ist auch kein „Sammelartikel“ für die verschiedenen …bretter.

Der Vorteil des von mir vorgeschlagenen Features gegenüber einer Weiterleitung wäre auch, dass die Zuordnung nicht apodiktisch erfolgt, sondern ggf. mehreren relevanten Artikeln die Chance lässt, gefunden zu werden (hier wäre es eine Alternative zu Begriffsklärungen von der Sorte, wie sie regelmäßig von irgendeinem über Assoziationsblasterei schimpfenden Altgedienten wieder ausgeleert werden).

Ich kann weitere Beispiele nennen, wo ich nach längerer Recherche gedacht habe, eigentlich sollte man bei der Wikipedia-Suche nach X den Artikel Y finden, wo ich mich aber aus verschiedenen Gründen nicht getraut habe, einen Redirect anzulegen oder das Wort in den Zielartikel zu schreiben: cor bovinum → Kardiomegalie; Käseschachtelaffäre → Gerhard Bletschacher; Milzbrandbrief → Anthrax-Anschläge 2001; Opriba → Alfred Hugenberg; Umzugskiste → Umzugskarton. (Wobei vermutlich die aus Wikipedianer-Sicht „richtige“ Lösung in manchen dieser Fälle doch eine andere wäre, aber vielleicht wird anhand dieser alphabetischen Aufzählung doch klar, wieso ich einen Bedarf sehe). --91.8.252.150 19:02, 18. Jan. 2009 (CET)

Tooltip bei Fußnoten

Wenn man mit der Maus über eine Fußnote fährt, sollte ein Tooltip mit der Quellenangabe erscheinen, wie bei MS Word. Dies erspart das lästige hin und her springen. --Uranus95 16:59, 19. Jan. 2009 (CET)

Wikipedia:Verbesserungsvorschläge/Feature-Requests#Verbesserung des ref-Elements für Quellenangaben -- Rosentod 17:02, 19. Jan. 2009 (CET)

Automatisches Einfügen von   in den generierten HTML-Code

Für die Zeichenfolge Ziffer + Leerzeichen + %-Zeichen gibt die Wiki-Software ja seit einiger Zeichen statt des Leerzeichens ein   aus. Das macht die Quelltexte übersichtlich und auch für Gelegenheitseditierer gut verständlich, außerdem muss man den Leuten, die das vergessen oder nicht kennen, nicht ständig hinterhereditieren.

Kann man diesen Automatismus nicht auch für andere Zeichenkombinationen einführen?

• Ziffer + Leerzeichen + SI-Einheit [kg|m|cm|mm|t|°C|...]
• Ziffer + Leerzeichen + Währunssymbol [€|$|¥|£]
• Ziffer + Punkt + Leerzeichen + Monatsname [Januar|Jänner|Februar|März|...]

-- H005 17:56, 22. Jan. 2009 (CET)

Informationen dazu findest du unter Wikipedia:Fragen zur Wikipedia/Archiv/2009/Woche 01#.26nbsp; --Der Umherirrende 19:06, 22. Jan. 2009 (CET)

Hm, danke, interessant. Aber leider wird Benutzer:Raymonds Vorschlag nicht weiter diskutiert. Das sieht mir doch nach einem Lösungsansatz aus. Die Performanceauswirkungen sind natürlich nicht gänzlich unerheblich, aber man sollte das wenigstens mal analysieren und bewerten. -- H005 19:14, 22. Jan. 2009 (CET)

mir faellt uebrigens dabei auf, dass die zeile

'/(.) (?=\\?|:|;|!|%|\\302\\273)/' => '\\1 \\2',

leicht fehlerhaft ist. schmeisst da php kein warning raus? $2 bzw. \2 ist doch hier nie definiert, da (?=...) non-capturing ist. eigentlich sollte die zeile

'/(.) (\\?|:|;|!|%|\\302\\273)/' => '\\1 \\2', oder

'/(.) (?=\\?|:|;|!|%|\\302\\273)/' => '\\1 ', oder sogar

'/(?<=.) (?=\\?|:|;|!|%|\\302\\273)/' => '&nbsp;',

heissen. ich kenne die regexp-engine von php nicht so gut, und weiss deswegen nicht, welcher der drei vorschlaege der effizienteste ist. ich vermute aus dem bauch heraus, dass der erste der lahmste ist. [nachtraegl. anm.] ist jetzt wurscht, hab's in den bugzilla eingetragen. -- seth 23:32, 22. Jan. 2009 (CET)

die idee von Raymond mit der ausgelagerten datei ist nicht schlecht und scheint wenig arbeit zu machen. ich frag ihn noch mal dazu. -- seth 22:13, 22. Jan. 2009 (CET)

Müsste es nicht (?: heißen? Einträge wie ([zZ]\.) (B\.) wären natürlich auch klasse. Gruß, --Revolus Echo der Stille 23:56, 22. Jan. 2009 (CET)

gudn tach!

(?:...) ist non-capturing clustering, also das gleiche wie (...) bloss ohne, dass eine back-reference angelegt wird.

(?=...) ist eine zero-width positive look-ahead assertion, und solche assertions sind per se ebenfalls non-capturing. "zero-width" bedeutet hier, dass die zwar beim matchen beruecksichtigt werden, aber im eigentlichen match nicht mehr auftauchen. iow: /foo(?:bar)/ matcht "foobar", dagegen matcht /foo(?=bar)/ ein "foo", auf das ein "bar" folgt. -- seth 00:40, 23. Jan. 2009 (CET)

eine lange version der erklaerung befindet sich in perldoc perlre.

bzgl. "z.b." (usw.) waere ich eher fuer den span-kram, der auf dem leider geloeschten Vorlage:\ basiert, da hier eigentlich ein schmales leerzeichen viel cooler ist. uebrigens zwischen zahl und % ebenfalls. -- seth 00:40, 23. Jan. 2009 (CET)

Ah, was dazu gelernt. :-) Spätestens mit erscheinen des GNU Internet Explorer 13, nach dem Konkurs Microsofts, wird der Großteil der Browser auch den NARROW NO-BREAK SPACE verstehen. Wenn man die linke und die rechte Seite der Ersetzung variabel machen würde, könnte man über die span-Variante nachdenken. Hardcodieren würde ich das aber nicht. --Revolus Echo der Stille 01:04, 23. Jan. 2009 (CET)

der witz an der ersetzung waere ja, wenn ich's richtig verstanden habe, dass man, sobald GNU IE 13 rauskommt, bloss diese paar zeilen im parser aendern muesste und der rest dann von zauberhand geschaehe.

theoretisch waere es mit diesem parser sogar moeglich, den schon hier und da mal geaeusserten wunsch nach "_"->" " und "__"->spangedoens oder etwas aehnlichem umzusetzen. man muesste halt bloss die ausnahmen definieren. siehe auch Wikipedia_Diskussion:Meinungsbilder/Typographie_(Zwischenräume)#Ganz_anderer_Vorschlag. -- seth 02:36, 23. Jan. 2009 (CET)

Fortsetzung der Diskussion hier: Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2009#Um_noch_mal_auf_...

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

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)

---

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:33, 27. Aug. 2013 (CEST)

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)

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)

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)

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;

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

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)

Ich glaube, das gibt die Datenbank in der jetztigen Form nicht her. Du könntest aber mithilfe der API dir dies nachbauen. Den jeweiligen Wikitext der verlinkten Seiten nehmen und nach dem Link suchen, falls nicht gefunden, ist die wahrscheinlichkeit hoch, das der Link durch eine Vorlage verursacht ist. Der Umherirrende 21:12, 6. Mär. 2009 (CET)

Tools, wpgrep

Im Moment arbeite ich Fehler-Listen ab, die von einem Tool auf dem Toolserver erzeugt werden (ist nicht mein Tool). Ich fände es gut, wenn es ein konfigurierbares Standardtool gäbe, dass solche Listen auswirft. Ich denke da an etwas wie das Programm grep. Das heißt, ich kopiere einen Satz von Konfigurationsdaten in die Eingabemaske und erhalte als Ausgabe eine Liste von wp-Lemmas. Ich würde das Tool also nur konfigurieren, aber nicht programmieren.

Problematisch dürfte sein die Belastung der Toolserver durch zu häufiges Benutzen zu begrenzen. Gibt es Software, wo man einstellen kann wie viel Rechnerleistung ein von einem Benutzer gestartetes wp-grep verbrauchen darf? Also beispielsweise darf jeder Benutzer nur 1 Prozent der Leistung eines Servers nutzen, entsprechend dauert es dann halt länger bis ein Ergebnis ausgeworfen wird. Oder es gibt eine Warteschlange wo man seinen Auftrag einstellt und irgendwann kann man dann das Ergebnis abholen. Noch schöner wäre es, wenn das Ergebnis auf einer Benutzerunterseite abgelegt wird und man eine Meldung auf die eigenen Disk. bekommt. --Goldzahn 01:00, 9. Mär. 2009 (CET)

So etwas ähnliche gibt es bereits: http://toolserver.org/~interiot/cgi-bin/queries/grep, allerdings nicht mit Volltextsuche, sondern mit Lemmasuche. Ich habe damit vor knapp zwei Jahren nach systematischen Falschschreibungen gesucht. Leider funktioniert das Tool seit ca. Sommer 2007 nicht mehr. --Fomafix 17:06, 30. Mär. 2009 (CEST)

Trotzdem danke für die Info. --Goldzahn 19:46, 30. Mär. 2009 (CEST)

Subst-Vorschau

Mit {{subst:Vorlage}} kann ich den Inhalt einer Vorlage substituieren, muss aber dazu eine neue Version speichern. Mit Spezial:Vorlagen expandieren kann ich mit eine Expansion einer Vorlage anschauen. Praktisch wäre es, wenn ich beides auf einmal erledigen können: Eine Vorschau der Substitution ohne zu speichern. Konkret stelle ich mir das so vor, dass es neben den Knöpfen „Seite speichern“, „Vorschau zeigen“ und „Änderungen zeigen“ einen weiteren Knopf „Vorlagen substituieren“ gibt, mit dem alle Vorlagen mit subst expandiert werden, ohne dass eine neue Version gespeichert wird. --Fomafix 17:20, 30. Mär. 2009 (CEST)

Ich hab mal versucht, sowas zu basteln. Austesten kannst du es mit

importScript('Benutzer:P.Copp/scripts/substnow.js'); //[[Benutzer:P.Copp/scripts/substnow.js]]

in deiner monobook.js. Gruß --P.Copp 18:34, 30. Mär. 2009 (CEST)

Respekt für die schnelle Programmierung. Code sieht gut aus (bis auf das ungesicherte eval(), aber das geht erst mit Firefox 3.1+ sauber [5]). Ich werde es bei Gelegenheit ausprobieren. --Fomafix 19:42, 30. Mär. 2009 (CEST)

Wenn ich sehen möchte, ob eine Vorlage vollständig expandiert wird, dann nutze ich die "Änderungen zeigen"-Funktion und schaue mir den generierten Quelltext im Diff an. Das klappt (für mich) sehr gut und ich brauche nicht immer speichern. Der Umherirrende 20:21, 30. Mär. 2009 (CEST)

Das ist richtig, aber ein automatisches Übernehmen in das Eingabefeld zum Weiterverarbeiten wäre ganz praktisch. --Fomafix 21:20, 30. Mär. 2009 (CEST)

Ermittlung der Spezialseite Nicht kategorisierte Artikel

Artikel die nur Wartungskategorien enthalten, sollten in obiger Spezialseite aufgenommen werden. Grund hierfür ist das sonst eventuelle Übersehen eines Artikels (vgl. Robert Baresel, Artikel wäre mit Sicherheit überarbeitet worden, Stand so 6 Monate katastrophal rum). Die Wartungskategorien haben keinen Mehrwert für den Leser, ein weiterer Grund weswegen der Artikel an und für sich als unkategorisiert gelten sollte. --Marcel1984 ^{(?! | ±)} 16:27, 5. Apr. 2009 (CEST)

Um noch mal auf ...

... diese Diskussion zurückzukommen: Es haben ja damals, wenn ich es richtig verstanden habe, durchaus praktiable Lösungsmöglichkeiten ergeben. Was muss man denn nun tun, damit das Ganze Wirklichkeit wird? -- H005 22:22, 19. Mär. 2009 (CET)

1. Raymond noch mal anstupsen? ;-)

2. klaeren, welche leerzeichen in welchen faellen eingefuegt werden sollten; am besten auf der talk page der entstehenden mediawiki-seite oder der talk page von Wikipedia:TYP. "nbsp" sollte eigentlich sowieso nur ganz selten wirklich gesetzt werden. meistens sollte das schmale (umbruchgeschuetzte) leerzeichen verwendet werden. es gibt auch moeglichkeiten, dieses zeichen ueber html-code zu erzeugen, ohne dass es nervt. -- seth 01:40, 20. Mär. 2009 (CET)

bugzilla:18443. -- seth 00:37, 13. Apr. 2009 (CEST)

Erweiterung Formeleditor

In DIN 5483-1 und DIN 40110-1 wird ein Formelzeichen verwendet, das sich offenbar mit dem TeX-Formeleditor nicht herstellen lässt. Daher fällt es mir schwer, über diese physikalische Größe zu referieren, wenn ich deren Formelzeichen nicht angeben kann. Das Formelzeichen besteht aus einem Buchstaben mit einem Akzent ^ über dem Buchstaben und zusätzlich einem gegenläufigen, v-förmigen Akzent unter dem Buchstaben.

Für den Akzent darüber gibt es die Hilfe mit „\hat“. Diese liefert eine Darstellung, die in Größe und Erscheinung der genormten Schreibweise entspricht. Für einen genauso großen Akzent darunter finde ich im Verzeichnis der Funktionen für LaTeX die Funktion „\underaccent … “, die das Benötigte möglicherweise liefern kann, die aber im Formeleditor nicht implementiert ist.

Ist bitte jemand bereit, diesen Erweiterungsvorschlag umzusetzen? -- Saure 21:36, 23. Apr. 2009 (CEST)

related: Diskussion von Hilfe:TeX. -- seth 22:08, 26. Apr. 2009 (CEST)

direkte Audiowiedergabe im Fliestext

Hallo, meine Anfrage bezieht sich auf den Artikel Katta. Dieser enthält sehr viele Audiodateien mit Tierlauten. Zur guten Lesbarkeit ist ein Fließtext sehr wichtig. Nun zum Problem: Bei der Einbindung mit der Vorlage Audio muss die Datei erst auf den Rechner geladen werden und dann je nach Rechner noch ein Zusatzprogamm aus dem Internet geladen werden um die Datei mit Endung .ogg wiederzugeben. => Umständlich und doof. Daher habe ich auf meiner Benutzerseite ein paar Tests gemacht. Problem: die alternative direkte Wiedergabe der Audiodatei über eine Taste lässt sich nicht in den Fließtext einbinden und die Lösungen mit den Tabellen sind keine Alternative bei vielen Tonwiedergabedateien. Ich wäre interessiert an einer Taste wie in Abschnitt 3 (vielleicht auch etwas kleiner, so dass die Zeilenabstände nicht so weit würden), die in den Fließtext eingebaut werden kann. Danke für jede Art von Tips und Hilfe, wie man so etwas umsetzen kann. -- Salino01 21:54, 11. Mai 2009 (CEST)

Übersichts-/Enzyklopädie-Einstellung

Nachdem immer mehr Artikel immer besser, schöner, lesenswerter, exzellenter aber auch länger werden, wäre es sehr geschickt (insbesondere auf dem Handy über m.wikipedia.org), wenn man eine Einstellung hätte, bei der nur die enzyklopädische Zusammenfassung des Artikels angezeigt werden würde. Also keine 3-10 Seiten Referat oder Biografie, sondern ein paar Sätze Zusammenfassung.

Das könnte - wenn der Artikel gut gegliedert ist - einfach nur der erste Abschnitt sein, bevor das Inhaltsverzeichnis beginnt. Das müsste technisch ohne größere Probleme umsetzbar sein.

Gibt's dazu schon einen Feature-Request (habe bei Wikimedia nichts gefunden) oder einen Hack oder etwas ähnliches? --SchorSch ^Diskussion 02:34, 25. Mai 2009 (CEST)

Vorlagen für nicht angemeldete Nutzer unsichtbar machen (erl.)

Es wäre schön, wenn es eine Möglichkeit gäbe einzelne Vorlagen unsichtbar zu machen, wie dass das Magic Word ___Hiddencat___ bei Kategorien tut. Wäre für Wartungszwecke interessant. -- chemiewikibm cwbm 19:39, 23. Jun. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: -- chemiewikibm cwbm 19:41, 24. Jun. 2009 (CEST)

Linkliste gliedern

Bei umfangreich verlinkten Artikeln fände ich es sinnvoll, wenn oben in der Linkliste die Anzahl der verlinkten Seiten/Artikel angegeben würde. Auch eine Gliederung nach Namensraum wäre m.E. wünschenswert, so das zunächst z.B. Links aus dem Artikelnamensraum bearbeitet oder angesehen werden könnten, vielleicht ließen sich die Namensräume in der Anzeige sogar einzeln ein- oder ausblenden. --Pflastertreter 13:45, 11. Jun. 2009 (CEST)

Die Möglichkeit der Namensraumeinschränkung gibt es auf Spezial:Linkliste bereits. Für die Anzahl kann ich nur auf Bug 4394 verweißen. Der Umherirrende 16:36, 11. Jun. 2009 (CEST)

Danke für den Hinweis, der Raum oberhalb der blauen Schrift ist dann wohl leider meinem Blickfeld entwichen :-((. Die Schnittstelle für die Namensräume und die Ausblendungen ist dann halt leider nicht einheitlich (einmal Auswahlbox, die anderen zur direkten Ja/nein-Auswahl). Der Zähler sollte aber vielleicht schon den Unterschied machen, wieviele Links in welchen Namensraum existieren. --Pflastertreter 17:59, 11. Jun. 2009 (CEST)

Bug der hidden-cats

Bug oder Feature? Sollen versteckte Kategorien in der Suche angezeigt werden? -- chemiewikibm cwbm 19:41, 24. Jun. 2009 (CEST)

Referenzen in der Vorschau

Da ich im Archiv nichts finden konnte: Wie groß ist der Aufwand, in der Vorschau von Abschnittsedits ein 'symbolisches' </references>-Tag zur Anzeige der in diesem Abschnitt enthaltenen Refenzen einzublenden? Mit ist inzwischen mehrfach unangenehm aufgefallen, dass bei Abschnittsedits die bearbeiteten Referenzen nicht per Vorschau kontrolliert werden können und Tippos etc. erst nach dem Speichern feststellbar werden... --NB > ?! > +/- 11:06, 25. Jun. 2009 (CEST)

Seiten in Bearbeitung für Bearbeitungszugriff durch andere Nutzer sperren

Während ein Nutzer eine Seite bearbeitet, sollte sie für den Bearbeitungszugriff anderer Nutzer gesperrt sein. Es könnte ähnlich wie in Netzwerken ein Insert erscheinen, im Sinne von "Datei ist zur Zeit zur Bearbeitung gesperrt".

Die derzeitige Fehlermeldung, wenn einem ein anderer Nutzer "dazwischengefunkt" hat, ist eher verwirrend. Auch gehen ja die vermeintlich gespeicherten Inhalte der eigenen Bearbeitung offenbar verloren. Wenn die Variante oben nicht möglich ist, könnte ersatzweise auch an dieser Stelle (d.h. beim Speichern) ein Hinweis erscheinen, im Sinne von "Seite wurde seit dem letzten Zugriff geändert. Speichern Sie Ihre Bearbeitung an anderer Stelle und rufen Sie die Seite erneut auf". --Feder.frau 12:22, 27. Jun. 2009 (CEST)

Für Artikel kann man diese Bearbeitungskonflikte mit der Vorlage {{Inuse}} umgehen -- Benzen ^C₆H₆ 15:20, 27. Jun. 2009 (CEST)

Ich öffne immer mal Artikel um mir den Quelltext anzuschauen und schließe danach den Tab oder den Browser, dabei würde die Seite nicht wieder freiggeben werden und keiner kann sie bearbeiten. Wenn ich mir nur ein Artikel anschaue und ihn garnicht bearbeiten möchte, belege ich auch unnötig. Zusätzlich kommt es immer mal vor das ein Browser abschmiert oder die Netzverbindung streitk, dadurch müsste ein weiterer Bearbeiter unnötig warten. Ansonsten kann ich nur auf Bug 17467 und Bug 4745 --Der Umherirrende 15:57, 27. Jun. 2009 (CEST)

Ratings für Bilder

wie für die textlichen Inhalte sollte auch langsam für multimediale Dateien eine Qualitätssicherung eingerichtet werden.

Ich finde nämlich, oftmals sind Bilder eingestellt, die zwar immerhin anschaulich das Objekt des Artikels zeigen, aber deren Qualität (da mittlerweile multimediale Einstellungen durchaus schon recht populär und zahlreich geworden sind) besser sein könnten.

Vielleicht ist es möglich die User über die Qualität mit Schulnoten, Sternchen, was auch immer entscheiden zu lassen.

Vielleicht macht sich dann sogar jemand auf die Socken und fotografiert das Ding neu und übersichtlicher ...

lg, -- dee.lite 13:31, 26. Jul. 2009 (CEST)

Es gibt die Exzellenten Bilder als Bewertung für Bilder. Es gibt derzeit keine Mindestanforderungen an Bildern. Da man auf Commons auch alles hochladen kann, macht es auch wenig Sinn, sich lokal welche zu Überlegen. Bei Bildern ist der subjektive Faktor stärker als bei Text, da man an Bildern nicht mal eben etwas ändern kann. Der Umherirrende 19:23, 30. Jul. 2009 (CEST)

Referenzen in der Vorschau

Ich will mich hier dem leider unkommentierten Verbesserungsvorschlag im Archiv anschließen: Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2009#Referenzen in der Vorschau. Beim Bearbeiten eines Abschnitts, kann in der Vorschau nicht gesehen werden, wie die Quellen aussehen, falls der Abschnitt nicht zufällig den Referenz-Foot (sagt man so?) unten hat.--Christian Stroppel 23:57, 27. Jul. 2009 (CEST)

Bug 5984 --Der Umherirrende 19:18, 30. Jul. 2009 (CEST)

Vielen Dank! Es hilft am besten seine Stimme dazu zu geben. Also wer dafür ist, nix wie ran.--Christian Stroppel 17:40, 3. Aug. 2009 (CEST)

Hier gibt es zumindest eine JS-Lösung... --NB > ?! > +/- 18:01, 3. Aug. 2009 (CEST)

Das findet meine volle Unterstützung! -- H005 18:18, 3. Aug. 2009 (CEST)

• Dieser alte Vorschlag ist natürlich auch interessant: Bei Abschnittbearbeitung zusätzlicher Button für Vorschau des Ganzen Artikels
• Die Diskussion zum Bug 5984 gab es wohl schon früher mit viel Zustimmung: Virtuelles „references“-Tag für „Vorschau zeigen“--Christian Stroppel 23:50, 3. Aug. 2009 (CEST)

Benutzerabhängige Variablen

Es gibt ja unter Hilfe:Variablen einige mehr oder weniger praktische Variablen. Wäre es technisch möglich, da auch Benutzerabhängige hinzuzufügen? Ein praktischer Nutzen wären Vorlagen, die je nach Spracheinstellung des Benutzers eine andere Sprache darstellen. Dazu die Möglichkeit, das ganze abhängig vom gerade besuchenden Nutzer zu machen oder von dem, auf dessen Benutzerseite die Variable verwendet wird, und man hat einige nette Einsatzzwecke. Für das Geschlecht gibt es ja sowas ähnliches bereits. Wie ich darauf gekommen bin? Ich wollte sowas wie Hallo {{USER_NAME}}. Willkommen auf meiner Benutzerseite verwenden ^^ --Nachtgestalt ^{Tür zu!} 14:20, 3. Aug. 2009 (CEST)

Hallo Nachtgestalt, generell ist die Idee zwar nett, sie hat aber einen großen Haken: Die Aufrufe werden gespeichert, weil die Generierung der Seiten aufwändig ist. Cachen wäre dann nicht mehr möglich. Die Server würden mit Sicherheit kollabieren, wenn solche Variablen in großem Umfang genutzt würden. Gruß, --Revolus Echo der Stille 14:31, 3. Aug. 2009 (CEST)

ach verdammt -.-

aber wie ist das dann mit den anderen Variablen? Werden die auch gecached und haben damit eine minimale Verzögerung oder sind die aktuell? Die Verwendung dürfte sich eh auf Babel-Bausteine und Benutzerseiten beschränken. Ich weiß nicht, ob das bereits zu "großem Umfang" zählt --Nachtgestalt ^{Tür zu!} 14:46, 3. Aug. 2009 (CEST)

Die meisten Variablen ändern sich ja nicht, der Seitentitel zum Beispiel ist ja konstant. Nur Zeitangaben sind nicht konstant. Da wird die Cachezeit auf 5 Minuten oder so herabgesetzt. Eine genaue Abschätzung kann ich dir natürlich nicht geben. Vielleicht magst du den Feature Request ja bei Wikipedia:Bugzilla einreichen? Da wird dir ein Entwickler schon sagen können, ob das machbar ist oder nicht. Gruß, --Revolus Echo der Stille 14:56, 3. Aug. 2009 (CEST)

Lokale Variablen kannst du über Untervorlagen zuweisen (Parameter sind auch Variablen). Du ermittelst die Werte und rufst die um deine Variablen erweiterte Untervorlage auf. Eine Erweiterung der Software würde das nur vor dir verstecken, müsste es aber genau gleich lösen. -- visi-on 17:13, 3. Aug. 2009 (CEST)

PDF-Darstellung

Ich drucke oder speichere mir oft Artikel als pdf-Version aus. Diese lässt sich zumeist sehr gut lesen und ist sehr schnell erstellt. Bei der normalen Druckversion muss man für längere Artikel meist noch in den Umbruch (per Textverarbeitung) eingreifen, um eine schöne Gestaltung zu erhalten. Zudem ist ein Druck von zwei auf einer Seite nicht direkt möglich. Pdf ist also in mancher Hinsicht besser. Allerdings hat die pdf-Darstellung ein Problem mit größeren Tabellen. Ein Beispiel dafür ist der Artikel Deutsche Bank, bei dem zur Zeit diese pdf Version entsteht.

• Auf S. 3 der derzeitigen pdf-Version steht die Tabelle „Konzernführung“. Diese wird im pdf-Format ineinander geschoben. Dabei nutzt die Darstellung nicht die Breite der Druckseite in gleichem Umfang wie der Text vorher oder nachher. Die Proportionen der Felder, die im Online-Umbruch auch bei unterschiedlichen Bildschirmgrößen beibehalten werden, werden hier nicht aufgenommen.
• Dass kleinere Tabellen, die im online Artikel mit umlaufendem Text gestaltet sind, in der pdf-Version gesondert stehen, ist kein eigentliches Problem. Schöner wäre es allerdings, wenn sie auch in pdf in den Text integriert würden. Ggf. auch mit einer etwas verkleinerten Schriftgröße.
• Problematisch ist wieder die Darstellung der Tabelle auf den pdf-Seiten 9-10 (Wirtschaftliche Entwicklung). Hier wird im Druck nun die ganze Seite genutzt. Trotzdem wird der Text der ersten Spalte in die Folgespalten reingeschoben. Wenn man den Schriftgrad der Tabelle etwas verkleinern würde (so erfolgt es in der Tabelle auf S. 3 und weiter unten S. 31), würde die Tabelle sauber kommen. Ungünstig ist auch, dass die Tabelle auf zwei Druckseiten angeordnet ist, obwohl gerade ein neuer Abschnitt angefangen hat. Hier wäre ein anderer Seitenumbruch (wie er bei eingebundenen Bildern stattfindet, sehr schön. Gibt es die Möglichkeit, in den Artikeltext einen Marker für den Seitenumbruch im pdf-Format aufzunehmen?
• Schlimm betroffen ist auch die Tabelle über die Entwicklung der Industriebeteiligungen auf der derzeitigen pdf-Seite 31. Hier gibt es zwar einen Seitenumbruch vor Tabellenbeginn. Auch wurde die Schriftgröße verkleinert. Beides ist gut. Aber die pdf-Fassung nutzt wieder nicht die Druckbreite der Seite und der Text der ersten Spalte fließt in die Folgespalten. Da auch im oberen und unteren Rand die Seite nicht genutzt wird, kommt ein sehr kleiner Teil der Tabelle auf die nächste Seine und dann kommt ein riesiges Loch bis der normale Text weiter geht.
• Unabhängig von den Tabellen noch ein kleiner Vorschlag: In den pdf-Versionen könnte man unter dem Strich, der unter auf jeder Seite ist, einen kurzen Hinweis aufnehmen, der zeigt, dass es sich um einen Wikipedia Artikel handelt und von wann der Ausdruck ist. So nach dem Motto: Artikel "Deutsche Bank" aus der Wikipedia vom 30. August 2009 (oder ähnlich). Dies wäre etwas Eigenwerbung und würde die Einhaltung der Urheberhinweises befördern.

Ich würde mir wünschen, dass an der Layout-Gestaltung der Tebellen in der pdf-Version noch ein Bisschen gebastelt wird. Gruß --Lutz Hartmann 11:58, 30. Aug. 2009 (CEST)

Da sich dies komplett auf die Buchfunktion bezieht, wäre Hilfe:Buchfunktion/Feedback zur Buchfunktion eine bessere Anlaufstelle. Dort schauen auch die Entwickler vorbei, die eventuelle Probleme lösen oder Anregungen umsetzen können. Der Umherirrende 12:15, 30. Aug. 2009 (CEST)

Bei den vielen Möglichkeiten, wo Verbesserungsvorschläge untergebracht werden können, ist man umherirrend:-). Aber vielen Dank, ich werden den Text auch dort einstellen. Gruß --Lutz Hartmann 12:29, 30. Aug. 2009 (CEST)

Ich kann dich gut verstehen ;-) --Der Umherirrende 12:37, 30. Aug. 2009 (CEST)

Überkategorien per Ajax

Derzeit können bei aktiviertem JavaScript auf Kategorieseiten Unterkategorien aufgeklappt werden. Es wäre hilfreich, wenn auch die Oberkategorien aufgeklappt werden könnten. Dazu müssten wie bei den Unterkategorien die Oberkategorien beim Aufklappen per Ajax nachgeladen und in der Seite angezeigt werden. Die Darstellung könnte ich mich folgendermaßen vorstellen:

Kategoriebaum

• Kategorie:Wurzelkategorie
  • Kategorie:Kategorie A
    • Kategorie:Kategorie A1
    • Kategorie:Kategorie A2
      • Kategorie:Unterkategorie
    • Kategorie:Kategorie A3
  • Kategorie:Kategorie B
    • Kategorie:Kategorie B1
      • Kategorie:Unterkategorie
    • Kategorie:Kategorie B2
    • Kategorie:Kategorie B3
  • Kategorie:Kategorie C
    • Kategorie:Kategorie B1
      • Kategorie:Unterkategorie
    • Kategorie:Kategorie C1

Die Kategorie:Unterkategorie gehört zu den Kategorien Kategorie:Kategorie A2 und Kategorie:Kategorie B1. Derzeit sieht die Kategoriezeile daher folgendermaßen aus:

Zum Klappen wird ein Element benötigt, das angeklickt werden kann. Hier könnte ich mir [↑] zum aufklappen und [↓] zum zuklappen vorstellen:

Wenn nun auf das [↑] bei Kategorie B1 geklickt, dann sieht die Darstellung so aus:

Wenn nun auf das [↑] bei Kategorie A2 geklickt, dann sieht die Darstellung so aus:

Wenn nun auf das [↑] bei Kategorie A2 geklickt, dann sieht die Darstellung so aus:

Gibt es vielleicht bereits eine solche Erweiterung? --Fomafix 15:14, 30. Aug. 2009 (CEST)

Alternativ könnten die Oberkategorien auch unterhalb der Kategorien angezeigt werden. Dazu muss die Pfeilrichtung ausgetauscht werden (↑ und ↓):

Der Vorteil dabei wäre, dass dies der üblichen Baumdarstellung mit Wurzel links oben entspricht und beim Auf- und Zuklappen die Position nicht verrutscht. --Fomafix 18:32, 30. Aug. 2009 (CEST)

Referenzierung mit DOI, ISBN, URI & Co.

Derzeit ist es immer etwas mühsam, einen Beleg mit dem ref-Element einzufügen. So muss man dann immer eine Zeile wie die folgende eingeben:

Dies ist ein Satz.<ref>Müller (2005): Die Rache der Frauen. Berlin, Wien. S. 5. ISBN 1234567890</ref>

Warum umständlich, wenn es auch einfach geht. Wenn man sowieso die ISBN rauskramt, dann kann man sich auch gleich den Rest sparen, etwa durch eine Eingabe wie die folgende:

Dies ist ein Satz.<ref isbn="1234567890">S. 5.</ref>

Das hätte genau dieselben Auswirkungen, wenn das System schnell in einer der zahllosen Datenbanken nachschlägt, was hinter der ISBN steckt. Dann kann man zugleich auch Fehler beim Abtippen von Buchtitel und dergleichen sparen. Statt ISBN wären auch URIs (für Webdateien) oder Digital Object Identifier für Artikel aus Fachzeitschriften denkbar, also etwa:

Dies ist ein Satz.<ref doi="1234567890">S. 5.</ref>

oder besser noch:

Dies ist ein Satz.<ref doi="1234567890" p="5" />

oder noch noch besser (weil XML-konform):

<ref doi="1234567890" p="5">Dies ist ein Satz.</ref>

statt:

Dies ist ein Satz.<ref>Müller, Meyer, Schulz (2009): Die Evolution der Grünalgen. In: International Journal of Wikipedia Research. Vol. 7, No. 3, p. 5. doi=1234567890</ref>

Könnte man das also nicht automatisieren? Der Quellcode wäre dann auch um einiges schlanker und übersichtlicher. 92.225.137.203 15:02, 30. Aug. 2009 (CEST)

Das wird so leider nicht gehen. Dazu müsste die Software jedes mal zig Datenbanken durchsuchen. Abgesehen davon, dass das wahrscheinlich die meisten Kataloge nicht mitmachen würden, wäre das ein riesen Aufwand. Was ist bei unterschiedlichen Angaben in den Katalogen, oder bei Ausfall? Was macht man bei fremdsprachigen die keine öffentliche Datenbank führen? Der Seitenaufbau könnte extrem lange dauern. Nicht alle ISBNs sind in Katalogen gelistet. Viele ISBNs sind für mehrere Auflagen vergeben. Alternativ könnte man sich eine WP eigene ISBN Datenbank überlegen. Aber auch da habe ich meine Zweifel. -- chatter™ 02:20, 12. Sep. 2009 (CEST)

Für ISBN gibt es die {{Vorlage:BibISBN}}. Die nutzt eine interne Datenbank. Bisher sind aber erst wenige hundert ISBN erfasst. Alle ISBN zu erfassen ist auch nicht Ziel – nur die oft genutzten. --Ephraim33 13:38, 12. Sep. 2009 (CEST)

Tooltip Sprache

Wäre es technisch möglich, beim Überfahren einer fremdsprachigen Textstelle mit der Maus, einen tooltip zu bekommen, wie z. b. beim gadet Seitenvorschau - also einfach alternativen Text anzuzeigen? Z. B. die Vorlage Sprache um ein zusätzliches ALT tag zu erweitern, in der Art: {{lang|en|Text|alt|Übersetzung}}. -- MfG Wikifantexter _{Alles Roger?} 19:03, 24. Sep. 2009 (CEST)

Es soll eh auf Deutsch geschrieben werden. Bei Eigennamen sollte man eine Übersetzung hinter den Begriff schreiben. Ich sehe also keinen Zweck dafür in der de.wp. Gruß, --Revolus Echo der Stille 19:22, 24. Sep. 2009 (CEST)

Hallo Revolus, ich möchte dich einladen, hier nachzusehen. Dort geht es um meine Bearbeitung und deren - nicht so ganz offensichtlicher - Revertierung. Vielleicht verstehst du dann, welchen Zweck meine Anfrage hatte. Warum ich zurückgesetzt habe steht hier. Gruß -- MfG Wikifantexter _{Alles Roger?} 21:58, 25. Sep. 2009 (CEST)

Links zu den einzelnen Überschriften

Ich habe ein Userscript für Greasemonkey erstellt, das die Aufgabe erledigt, doch ich denke, dass alle diese Funktion haben sollten. – Flying sheep 02:08, 12. Okt. 2009 (CEST)

Seitenuntertitel

Ich wünsche mir neben dem normalen Seitentitel einen Seitenuntertitel für Artikel. Der Untertitel wird unter oder neben dem Seitentitel angezeigt:

Seitentitel – Untertitel der Seite

Der Untertitel wird über eine Parserfunktion im Artikeltext erzeugt:

{{SEITENUNTERTITEL:Untertitel der Seite}}

Der Untertitel wird im title-Attribut von Links auf die Seite angezeigt:

„Dies ist ein Link auf Seitentitel.“

In Kategorien wird neben dem Seitentitel der Seitenuntertitel gezeigt:

S

• Seitentitel – Untertitel der Seite

In der Datenbank muss der Untertitel daher als weitere Spalte in der Artikeltabelle gespeichert werden.

Die Hauptanwendung dieser Untertitel sehe ich bei Abkürzungen. Abkürzungen werden im Artikeltitel häufig ausgeschrieben, obwohl die abgekürzte Form die üblichere und häufigere ist und auch keine Notwendigkeit wegen Mehrdeutigkeit besteht. Mit einem Untertitel könnte der Seitentitel die Abkürzung und der Seitenuntertitel die ausgeschriebene Form sein. Es gibt sicherlich viele weitere sinnvolle Anwendungsfälle von Untertiteln. --Fomafix 22:44, 7. Okt. 2009 (CEST)

Bitte nenne ein Beispiel, Abkürzungslemmata sollten eigentlich nicht die Regel sein. --Gnom 16:59, 23. Okt. 2009 (CEST)

• SECAM → Séquentiel couleur à mémoire
• ASCII → American Standard Code for Information Interchange

Alles Beispiele, bei denen der Begriff unter der Abkürzung bekannter ist, als in der ausgeschriebenen Version. Nach Wikipedia:NK#Abkürzungen sollte eigentlich der bekanntere Begriff verwendet werden. Eine solche Erweiterung könnte hier vielleicht als Kompromiss wirken. --Fomafix 17:16, 23. Okt. 2009 (CEST)

Dynamischer Indikator für Vertrauenswürdigkeit und Artikeldynamik

Ein Grundproblem mit jedem Beitrag in der Wikipedia ist die Qualitätseinschätzung. Wenn man einen Beitrag liest, helfen einem bereits einige sogenannte Bausteine zu erkennen, ob der Artikel offensichtliche Mängel hat (wie z.B. fehlende Quellen, fehlende Neutralität, unvollständiges Lemma usw.). Viele Artikel jedoch - ich würde behaupten wollen die meisten, also mind. 80% - haben keine optischen und/oder textuellen Hinweise auf die Qualität. Insbesondere die Vertrauenswürdigkeit der Information ist dabei aus meiner Sicht ein wichtiger Bestandteil der Qualitätswahrnehmung. Oft findet sich aber weder ein Lesenwert-Button und auch sonst keine andere Markierung die hier weiterhilft. Selbst wenn Artikel diese Markierung hätten, bleibt ein grundlegendes Problem: Jeder noch so gute Artikel kann wenige Minuten vor einem Besuch/Abruf verändert worden sein, und zwar zum Nachteil der Artikelqualität und -vertrauenswürdigkeit. Einzig der Blick in die Artikelhistorie der Edits hilft hier weiter. Für normale Wikipedianutzer ist das eher unpraktisch und wird sicher von den wenigsten durchgeführt.

Oft taucht das Problem der Vertrauswürdigkeitseinschätzung auf, wenn gerade ein Artikel im Fokus der (Medien-)Aufmerksamkeit steht. Der Fokus zieht sowohl Leser als auch interessierte Vandalen an und lädt ein, den Artikel zu editieren. Ein Besucher/Leser jedoch bekommt von dieser Dynamik die hinter einem Artikel steht in der Regel nicht viel mit. Weder von einer Diskussion die lebhaft auf der Diskussionsseite tobt, noch von der Heftigkeit der Änderungen pro Zeiteinheit, die in den vergangenen Tagen stattgefunden hat.

Aus diesem Grund schlage ich vor einen grafischen und/oder textuellen Indikator für JEDEN Artikel (Dynamischen Indikator für Vertrauenswürdigkeit und Artikeldynamik) zu berechnen und anzuzeigen, der berücksichtigt, wie hoch die Aktivität kürzlich rund um diesen Artikel war. Dieser Indikator sollte folgende Dinge einbeziehen in die Anzeige:

• Vielfalt der Autoren (Wieviele Autoren haben an diesem Artikel im Vergleich zur maximalen Anzahl an Autoren die bislang einen Beitrag editierten mitgewirkt?)
• Änderungen pro Zeiteinheit (Wieviele konstruktive vs. destruktive Veränderungen haben an dem Artikel in der letzten Zeit stattgefunden?)
• Aktivitäten der Diskussion (Wieviel Aktivität fand in der Diskussionsseite in letzter Zeit statt und wieviele Autoren waren daran beteiligt?)
• Aktivität der Abrufe (Wieviel Abrufe pro Tag hat der Artikel im Vergleich zu seiner sonstigen durchschnittlichen Abrufzahl pro Tag)

Ich denke ein solcher Indikator würde dramatisch dabei helfen eine schnelle erste Einschätzung zu erhalten, wie vertrauenswürdig der momentane Artikel ist. Auch für Administratoren wäre das eine echte Hilfe im Alltag. Wenn z.B. viel destruktive Aktivität aufblitzt bei gleichzeitig sehr wenigen Autoren und einem hohen Interesse/Medienfokus (überdurchschnittlich hohe Abrufzahlen pro Tag), dann ist das ein klares Warnzeichen bei der dynamisch berechneten Vertrauenswürdigkeit. Wenn wenig Veränderung vorliegt, aber viele Autoren an dem Beitrag mitgewirkt haben ist das zwar nicht unbedingt ein ausreichendes wohl aber ein mit hoher Wahrscheinlichkeit auf Vertrauenswürdigkeit deutendes Merkmal (Der Beitrag hat offenbar Konsens unter Vielen erzielt, scheint stabil zu sein und unterliegt keiner aktuellen Veränderung oder Zerstörung, ebenfalls sind Diskussionsaktvitäten verhalten bis mäßig).

Das soll ein Beispiel sein, wie ich mir eine nachhaltige Qualitätsverbesserung vorstelle die tatsächlich technisch unterstützt werden kann. Ich freue mich auf Feedback, gerne auch auf meiner Diskussionsseite! --Helge Städtler ^{Expect and Respect.} 16:41, 19. Okt. 2009 (CEST)

So etwas hat sich ein findiger Schweizer meines Wissens schon einemal gedacht und auch eine entsprechende Website gebastelt, die das sehr schön und farbig anzeigt. Ich weiß aber nicht mehr wo. Tipp: Anglizismen und zu viel bunte Farben schrecken Alteingesessene oft ab, vielleicht solltest du deinen Vorschlag daher umformulieren. --Gnom 16:58, 23. Okt. 2009 (CEST)

→ WikiBu -- Benzen ^C₆H₆ 08:47, 24. Okt. 2009 (CEST)

Danke, Benzen. Ich hab mal versucht das umzuformulieren und zu erweitern. Der Link zu diesem Schweizer wäre echt hilfreich. Ich hab bislang nur diese Idee gehabt, keinen Entwurf oder sowas dazu. --Helge Städtler ^{Sei willkommen!} 12:23, 24. Okt. 2009 (CEST)

Ah, mein fehler, hast den Link ja eingefügt!! Du meinst doch sicher WikiBu vermute ich mal, oder? --Helge Städtler ^{Sei willkommen!} 12:31, 24. Okt. 2009 (CEST)

Upsa, ich hatte nicht ordentlich unterschrieben. Ja, ich meinte Wikibu. --Gnom 12:53, 24. Okt. 2009 (CEST)

@Gnom Macht ja nix. =) Ich hab mir WikiBu mal angeschaut. Das sieht wirklich schon verdammt nach dem aus, was ich mir gedacht habe. Wobei ich es nicht unbedingt in einer Extraseite als Dienst sehen möchte, sondern mir eine auf den ersten Blick erfassbare Information wünschen würde.

Beispiel: Zu dem Wikipediaeintrag zum Arbeitskreis gegen Internetsperren und Zensur liefert WikiBu keinerlei brauchbare Information. Stattdessen meldet die Analyse: Dieser Artikel ist erst wenige Tage alt. Wikibu kann deshalb noch keine Bewertung vornehmen. Ist eine solche Aussage zielführend? Man könnte problemlos analysieren wieviel konstruktive und destruktive Aktivität herrscht, wieviele Zugriffe es gibt und wieviele Autoren daran augenblicklich arbeiten. Auch die interne Verlinkung kann man sehen und analysieren, ebenso die Aktivitäten und Beteiligten in den Diskussionen. Warum wurde hier innerhalb von WikiBu pauschal die Analyse abgelehnt, bloss weil der Artikel frisch ist? Von einer in die Wikipedia eingebauten Analyse vergleichbar zu der Indikatorbildung bei WikiBu würde ich mir tatsächlich sehr nützliche Hinweise auf Qualität und Vertrausenwürdigkeit für alle Wikipediagestalter und -nutzer erwarten. Eine tolle und unterstützenswerte Idee! --Helge Städtler ^{Sei willkommen!} 17:37, 24. Okt. 2009 (CEST)

Die dahin gehenden Energien werden momentan wohl für die gesichteten und geprüften Versionen aufgewendet. --Gnom 18:10, 24. Okt. 2009 (CEST)

Zusammenfassen meherer Edits

Wenn ein Nutzer, mehrere Edits hintereinander macht, sollte dies zu einem einzigen Edit zusammengefasst werden.

Vorteile:

• Versionsgeschichte wird übersichtlicher
• Speicherplatz wird gespart (bei jeder Änderung wird der komplette Artikel nochmal gespeichert)
• Editcount-Jäger habens nicht so leicht

--Uranus95 21:20, 24. Sep. 2009 (CEST)

Das wurde schon öfters angeregt: Wikipedia:Verbesserungsvorschläge/Archiv/2009/April#Änderungen in der Versionshistorie zusammenfassen und weitere --Der Umherirrende 11:33, 26. Sep. 2009 (CEST)

Und alle waren dafür/neutral (zumindest bei dem von dir verlinkten Vorschlag). Ich finde ein optionales (vom Autor aktivierbares) zusammenfassen sehr sinnvoll, da ich oft noch einen letzten beim vorschauen übersehenen Fehler entdecke, nachdem ich auf „speichern“ geklickt habe – Flying sheep 02:14, 12. Okt. 2009 (CEST)

Ja, optional wäre gut. Vorzugweise sollte die Version dann in der Versionsgeschichte als "zusammengefasst" gekennzeichnet werden, denn womöglich liest ja bereits jemand die Zwischenversion, versucht sie zu editieren, bekommt einen Editkonflikt gemeldet und findet die zuvor gelesene Version dann in der Versionsgeschichte nicht wieder. Ein Hinweis auf die Edit-Zusammenfassung erklärt dann immerhin, warum. --Carolin 10:12, 12. Okt. 2009 (CEST)

Eine Alternative wäre, die Konsolidierung mehrerer Edits erst nach einiger Zeit, zum Beispiel nach 3 weiteren Versionen und/oder sieben Tagen vorzunehmen. — 3247 ✐ 02:32, 31. Okt. 2009 (CET)

Nach Anmeldung immer Seite X anzeigen

Wäre es möglich in den Einstellungen einen Abschnitt hinzuzufügen der es ermöglicht nach dem Einloggen immer eine bestimmte Seite, wie Beispielsweise die eigene Beobachtungsliste oder die eigene Benutzerseite kommt?(siehe:Hilfe_Diskussion:Einstellungen#Nach_Anmeldung_immer_direkt_Seite_X_anzeigen) --martIGB disk 19:56, 25. Okt. 2009 (CET)

+1 --Helge Städtler ^{Sei willkommen!} 20:12, 25. Okt. 2009 (CET)

Das geht irgendwie mit &returnto: oder so. --Gnom 20:21, 25. Okt. 2009 (CET)

Kannst du das genauer erläutern? Aus:"irgendwie mit &returnto: oder so" werd ich gerade nicht so schlau. ist dass jetzt für die wikiprogrammierer hier, oder kann man das als normalbenutzer irgendwo dann einfügen. danke schon im vorraus für antworten, und danke @ Helge Städtler wegen der bewertung--martIGB disk 03:30, 31. Okt. 2009 (CET)

Der Parameter returnto in der URL definiert nur den Link unter "Zurück zur Seite". Automatisch ist da nichts möglich . Man könnte sicher etwas per JavaScript machen, ich hätte da aber kein Ansatz. Der Umherirrende 11:42, 31. Okt. 2009 (CET)

Per JavaScript geht immer:

var returnto = document.getElementById("mw-returnto");
if (returnto) document.location = returnto.childNodes[1].href;

--Fomafix 13:40, 31. Okt. 2009 (CET)

Danke--martIGB disk 15:30, 1. Nov. 2009 (CET)

oder:

if( wgCanonicalSpecialPageName == "Userlogin" ) {
 document.location = wgServer + wgArticlePath.replace(/\$1/, 'Spezial:Beobachtungsliste' );
}

Um nicht das returnto zu nutzen (da landen die meisten vermutlich auf der Hauptseite). Der Umherirrende 15:34, 1. Nov. 2009 (CET)

Danke Umherirrender. Nur noch die Frage: Wo müsste ich dieses in Java geschriebene jetzt einfügen das ich es für Wikipedia verwenden kann/also es auch bei jedem Anmelden benutzt wird? Ich hab jetzt einfach mal die Seite: Benutzer:MartinIGB/monobook.js angelegt, und das da eingefügt.--martIGB disk 15:38, 1. Nov. 2009 (CET)

Das in JavaScript geschriebende steht schon auf der richtigen Seite. Nur wird das so nicht vom Browser ausgeführt. Versuche mal:

addOnloadHook( function() {
 if( wgCanonicalSpecialPageName == "Userlogin" ) {
  document.location = wgServer + wgArticlePath.replace(/\$1/, 'Spezial:Beobachtungsliste' );
 }
});

So triggert MediaWiki nach dem kompletten Laden der Seite das Ausführen an. Der Umherirrende 16:11, 1. Nov. 2009 (CET)

Danke. Es funktioniert jetzt. Danke Fomafix und besonderer Dank an Den Umherirrenden --martIGB disk 22:08, 1. Nov. 2009 (CET)

Keine Ursache. Freut mich auch das es funktioniert, ohne die Idee von Formafix wäre es aber auch nicht möglich gewesen, so habe ich auch mal wieder was gelernt. Der Umherirrende 19:41, 2. Nov. 2009 (CET)

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

Oxygen Icons in der Beta

Der polierte Look der Icons des Oxygen-Projekts von KDE passt viel besser zum erscheinungsbild der neuen Wikipedia (Beta) als die aktuellen Gnome-Icons. – Flying sheep 02:08, 12. Okt. 2009 (CEST)

Es ist besser, das Feedback-Formular von Beta zu nutzen, dort kommt es auch wirklich bei den Entwicklern an. Der Umherirrende 15:39, 1. Nov. 2009 (CET)

Kategorien mit Historie

Kategorieseiten zeigen derzeit die nur aktuellen Artikel der Kategorie an. Es gibt keine Möglichkeit zu sehen, welche Artikel früher zu der Kategorie gehört haben. Neu hinzugekommene Artikel können noch über die Funktion Spezial:Änderungen an verlinkten Seiten gefunden werden. Entfernte Artikel sind nicht damit nicht zu finden.

Eine Änderungshistorie für Kategorien wäre perfekt für solche Recherchen. Wenn allerdings jede Änderung sofort protokolliert wird, könnten enorme Datenmengen entstehen. Eine versionsgenaue Verfolgung ist aber gar noch so wichtig. Eine tagesgenaue Versionierung würde ausreichen. Ein Bot könnte jede Nacht den aktuellen Inhalt der Kategorie in einer Archivseite speichern. Hat sich nichts geändert, wird auch keine neue Archivversion gespeichert. Änderungen der Kategorie können dann durch ein Versionsvergleich der Archivseite nachvollzogen werden. Eine solche Archivseite kann dann auch auf die Beobachtungsliste gesetzt werden und wird dann über neu hinzugekommene, entferne und umbenannte Artikel in der Kategorie informiert.

Welches Mengengerüst wäre dabei zu erwarten? Gibt es ein solches Feature bereits? --Fomafix 12:40, 2. Nov. 2009 (CET)

Automatisches Setzen von "Nur Kleinigkeiten wurden verändert"

Bei jedem Edit kann man vor dem Speichern "Nur Kleinigkeiten wurden verändert" angeben, bei den Einstellungen kann man "Eigene Änderungen standardmäßig als geringfügig markieren" angeben. Allerdings gibt es keine Empfehlung/Vorschrift/... die besagt was eine Kleinigkeit ist und was nicht.

Wir haben also jede Menge für die Allgemeinheit sinnlose & nicht auswertbare Informationen zu individuellen Vorstellungen was die "Größe" einer Änderung betrifft.

Vorschlag: Beide Checkboxen entfernen und statt dessen automatisch bei z.B. weniger als 100 Bytes Änderung eine Änderung als "Kleinigkeit" markieren. Wobei Änderung = Summe aller gelöschten, neu eingefügten, verschobenen Dinge.

--Sebastian.Dietrich 18:43, 20. Nov. 2009 (CET)

Nö, jeder bewertet die Kleinigkeit anders und für sich selbst. Ich gebe Dir insofern recht, das ein klares Kriterium für diese beiden Checkboxen fehlt, ich hab's mir daher angewöhnt, im Regelfall auf deren Benutzung zu verzichten. Ob die Box verzichtbar ist oder nicht, sei dahingestellt, das muss jeder für sich entscheiden, eine Belastung dürften die zwei Bits jedoch nicht sein. Aber es kann nicht angehen, eine Änderung unter 100 Zeichen automatisch als geringfügig zu kennzeichnen. Selbst ohne Änderung der Zeichenzahl kann man einen Artikel geradezu verfälschen. Ändere beispielsweise das Geburtsjahrtausend, oder den Geburtstag einer Person, und welche Änderung würdest Du in dem Falle sehen? Richtig, keine, können Null Zeichen mehr oder weniger sein, trotzdem ist die "geringfügige" Änderung grottenfalsch und keinesfalls eine "Kleinigkeit" (außer in Bits und Bytes). --Pflastertreter 21:56, 2. Dez. 2009 (CET) P.S.: Es sei denn, Du (und alle anderen) verstehen Kleinigkeit als Bytegröße, das sollte aber dann auch deutlich dabei stehen. Für die einen zählt die Quantität der Änderung, für die andern die Qualität. --Pflastertreter 22:10, 2. Dez. 2009 (CET)

Beim Algorithmus hast mich falsch verstanden: Eine Änderung des Geburtstages von z.B. 12. Dezember 2000 auf 21. Dezember 2011 wäre eine Änderung von 4 Zeichen, auch wenn die Größe insgesamt gleich geblieben ist.

Wir brauchen entweder allgemeingültige Kriterien für das Setzen des Flags welches technisch oder organisatorisch sichergestellt ist oder zumindest sollte das Flag "privat" sein - d.h. für andere Benutzer unsichtbar werden (weils eh für andere nix zu bedeuten hat). So wies aktuell ist ists kein Ding von Qualität, sondern eine persönliche Anschauung. --Sebastian.Dietrich 07:42, 3. Dez. 2009 (CET)

Siehe auch Wikipedia:FzW#K-Änderungen (kleine Änderungen) --Der Umherirrende 18:43, 3. Dez. 2009 (CET)

Der angegebene Link funktioniert nicht. Auf der verlinkten Seite kann ich auch keinen Hinweis mehr auf das Thema "kleine Änderungen" finden. Ich glaube, der Link ist Hilfe:Zusammenfassung_und_Quellen#Kleine_.C3.84nderung_.28K.29. Demnach ist die Bedeutung von "Kleinigkeit" nicht allgemeingültig festgelegt. Der einzige mir bekannte Fall, bei dem das Merkmal eine Rolle spielt, ist, dass man beim Beobachten von Seiten einstellen kann, dass eigene Änderungen oder Änderungen, die mit B oder K markiert sind, ausgeblendet werden. Das heißt, dass die Bedeutung des Merkmals "Nur Kleinigkeiten wurden verändert", darauf abzielt, bestimmte Änderungen auf Vertrauensbasis ausblenden zu können. Wenn Du einen Artikel jedoch ernsthaft "kontrollieren" möchtest, musst Du Dir aber zwangsweise alle kumulierten Änderungen anzeigen lassen. Ansonsten könnte ja auch jemand eine große Vandalismus-Änderung bewusst als kleine Änderung markieren, um Deiner Aufmerksamkeit zu entgehen. Persönlich würde ich eine solche Filterbedingung nie nutzen, weil ich mir genau so gut alle kumulierten Änderungen anzeigen lassen kann, und es mich erst dann überhaupt interessiert, wer im Einzelnen was geändert hat. Von der Bedeutung her denke ich, dass es (wie gesagt auf Vertrauensbasis) um die empfundene Bedeutung einer Änderung geht. Diese lässt sich leider automatisch nicht ermitteln, da auch Änderungen, die nur wenige Wörter umfassen, auf inhaltlicher Ebene bedeutungsschwer sein können. Z. B. kann das Einfügen des Wortes "nicht" (5 Zeichen + 2 Leerzeichen = 7 Zeichen Gesamtgröße) die Bedeutung eines kompletten Satzteils umkehren. Meinem Empfinden nach sind die Beseitigung von Rechtschreib- und Tippfehlern, geringfügige Umformattierungen, und das Korrigieren oder Verschieben defekter (aber bereits vorhandener) Links, etc. "Kleinigkeiten". Alle inhaltlichen Änderungen, welche die faktische Ebene betreffen, oder Ändern/Entfernen/Hinzufügen von Bildern, sind meinem Empfinden nach demgegenüber keine "Kleinigkeiten". Wenn etwas dem Empfinden nach bedeutungsverändernd ist, also sachlich in Frage gestellt werden kann, ist es (für mich) keine "Kleinigkeit" mehr. Wie gesagt ist das meinem Empfinden nach eine subjektive Einordnung auf Vertrauensbasis, deren Sinn, als Wikipedia-Feature allgemein, absolut in Frage zu stellen ist. Meine 2ct. --Dalvarez 03:07, 8. Dez. 2009 (CET)

Linkkorrektur: Wikipedia:Fragen zur Wikipedia/Archiv/2009/Woche 49#K-Änderungen (kleine Änderungen) (wurde ins Archiv verschoben).

Inhaltlich bin ich ganz Deiner Meinung. Es funktioniert nur auf Vertrauensbasis. Aber nachdem es keine Vorgabe zur Verwendung der Checkbox gibt, hat die Vertrauensbasis auch keine Basis. Auch wenn alle "brav" sind, hätte das Flag (für andere) keine Bedeutung. Leider wissen das nicht alle, darum gehört das Flag entweder weg, oder mit einer eindeutigen Aussagekraft versehen. --Sebastian.Dietrich 09:12, 8. Dez. 2009 (CET)

Die inzwischen existierende Option in den Einstellungen, alle eigenen "Änderungen standardmäßig als geringfügig markieren" zu lassen, führt diese Funktion endgültig ad absurdum. So kann und sollte sie schnellstmöglich abgeschafft werden. Nebenbei: waren die Regeln für das Setzen des "K"-Häkchens in der deutschen Wikipedia immer schon so locker bzw. nicht vorhanden? In vielen anderssprachigen Wikipedias gibt es dafür Regeln, s. z. B. en:help:minor edit--Biologos 16:46, 9. Mär. 2010 (CET)

Ich kann Dalvarez und Biologos nur zustimmen! Ich handhabe es in der Regel (was heisst, dass es auch Ausnahmen geben könnte) wie von Dalvarez beschrieben: dass nur reine Deutschkorrekturen (Orthographie, Interpunktion, Grammatik) oder Korrektur bestehender Links als kein zu deklarieren sind. Werden Sätze oder abschnitte umformuliert, um den Sachverhalt deutlicher zu machen oder in besseres Deutsc zu setzen, so deklariere ich dann auch als klein, wenn ich inhaltlich nichts angefügt oder entfernt habe. Ist inhaltlich irgend etwas verändert worden (Anfügung/Weglassung), so deklariere ich es nicht als klein - und wenn ich unsicher bin auch nicht. Das Automatische Setzen des Kleinigkeitenhäkchens ist mehr als fragwürdig und macht eigentlich ausschliesslich dann Sinn, wenn sich jemand selbst die Vorgabe gibt, ohnehin inhaltlich nichts zu verändern (resp. verändern zu wollen - und da fängt das Problem an) und nur die Schreibung zu kontrollieren. Da auch so jemand irgendwann mal etwas am Inhalt ändern wird, ist das automatische Setzen des Häkchens abzulehnen. --ProloSozz 13:21, 12. Feb. 2011 (CET)

Wikipedia Translations

(Nicht: Machine Translations, möglicherweise aber projekt-technisch daran gekoppelt) Dieser Thread ist evolviert aus "Sprachunabhängige Artikelstrukturen schaffen und Änderungen sprachübergreifend abgleichen").

Problem/Schwachpunkt: Wikipedia-Artikel unterliegen derzeit fast ausschließlich einer Weiterentwicklung und Sichtung innerhalb des gleichen Sprachraums. Bis auf die Quersprungmöglichkeit in andere Sprachen gibt es keine inhaltliche Verbindung mit anderssprachigen Artikeln zum gleichen Thema. Dies begünstigt die Bildung von Wissens-Inseln innerhalb der Landessprachen und führt dazu, dass die einzelnen Artikel, die in unterschiedlichen Sprachen vorliegen, aber das gleiche Thema betreffen, auch strukturell von einander abweichen. Dies führt in den unterschiedlichen Sprachen z. T. zu komplett unterschiedlichen Aufteilungen von Themengebieten. Da jeder Arikel nur bestimmte Inhalte berücksichtigt, und selten alle Inhalte, die in den anderssprachigen Artikeln evtl. schon enthalten sind, ist fast jeder Artikel unvollständig - bemessen am global erfassten Wikipedia-Wissen.

Lösungsvorschlag: Ich schlage vor, sprachunabhängige, einheitliche Strukturdaten einzuführen. Diese Strukturdaten würden an die Schlagwörter der Artikel geknüpft und würden nur aussagen, dass es ein Thema gibt, und dazu verschiedensprachige Artikel vorliegen, die in den unterschiedlichen Landessprachen jeweils bestimmte Schagwörter haben. Außerdem würden die Artikel sprachunabhängig in einheitliche Unterabschnitte eingeteilt (so wie man sie auch derzeit einzeln bearbeiten kann), und diesen Unterabschnitten würden in den Landessprachen ebenfalls bestimmte Titel zugeordnet. Durch die einheitlichen Strukturdaten wäre gewährleistet, dass die Verlinkungsstruktur, also die Aufteilung breiterer Themengebiete in Einzelartikel, unabhängig von der Sprache durchgehend die gleiche wäre, und auch die innere Gliederung der Artikel wäre einheitlich. In einem zweiten Schritt könnte man dann anhand dieser Strukturdaten dafür sorgen, dass alle Artikel, die das gleiche Thema betreffen, inhaltlich komplett gleich sind. Dies ist einfach umzusetzen, da Artikel ja ohnehin schon in den jeweiligen Landessprachen versioniert werden. Man könnte dies evtl. noch auf Unterabschnitte ausdehnen, um gezielter vorgehen zu können. Anhand der Versionierung kann man ein systematisches Vorgehen einrichten, um die Änderungen auch in die anderssprachigen Artikel zum gleichen Thema einzupflegen. Naheliegend wäre etwa, die Änderungen im Abstand einiger Wochen abzugleichen und erst in eine Weltsprache wie z. B. Englisch zu übersetzen, und anschließend in die anderen anderssprachigen Artikel zum gleichen Thema.

Damit wären die Artikel dann wirklich Übersetzungen eines einheitlichen Wissens, und nicht wie bisher inhaltlich komplett andere Artikel. Dies würde meines Erachtens zu einer vollständigeren Wissensabbildung führen, und einem globaleren Austausch z. B. bei der Sichtung und inhaltlicher Diskussion. Vor allem würde die Eigenbrödlerei der Sprachversionen zugunsten einer globalen Wissensbasis abgeschafft.

Es müsste eigentlich einfach sein, so etwas umzusetzen. Die Frage ist nur, ob man es möchte. Was denkt ihr?

--Dalvarez 04:02, 25. Nov. 2009 (CET)

VOLLSTE ZUSTIMMUNG! Das wäre die großartigste Sache seit der Geburt von Wikipedia! Die Umsetzung wäre allerdings ganz sicher nicht einfach. Der Aufwand wäre doch immens. Jeder einzelne der international über 10 Mio. Artikel muss an das neue Konzept angepasst werden... Vielleicht könnte man eine neue Wiki-Sprache hinzufügen?! Meta-English, in dem nur die von dir genannten "Strukturdaten" verwendet werden, um erst einmal eine Vorlagestruktur für die einzelnen Seiten zu erstellen. Diese könnten dann in die einzelnen Wikis übernommen werden, indem für jeden Artikel ein internationales Template (erstellt aus einer mehrfach überprüften Version x der Meta-English Wikipedia) gibt, das automatisch bei der Bearbeitung eines Artikels vorgeschlagen wird. Das Ganze setzt natürlich voraus, dass man die geasmte Wiki-Welt zu diesem Schritt bekommt... --Jonnyjones 03:58, 4. Dez. 2009 (CET)

Es wäre sicherlich eher ein ständiger Prozess als eine augenblickliche Umstellung. Ich denke, sobald die Software-Möglichkeit erstmal da ist, könnte Wikipedia Artikel für Artikel in Richtung der einheitlichen Strukturdaten konvergieren. Man kann ja erstmal zwischen "globalen" und "nicht globalen" Themen unterscheiden. Nutzen alle Artikel zu einem Thema sprachübergreifend die einheitlichen Strukturdaten, sind sie als solche erkennbar und werden vom System auch so gehandhabt. Alle Artikel, welche die Strukturdaten noch nicht nutzen, bleiben wie gehabt, bis jemand sich die Mühe macht, einen entsprechenden "Knoten" für das jeweilige Thema anzulegen. Ist ein Artikel einmal abgeglichen, werden weitere Änderungen an den mit dem Thema verknüpften verschiedensprachigen Artikeln einheitlich versioniert, und erkennbar gemacht, ob bereits neue zu übersetzende Änderungen vorliegen. Somit kann man wirklich schrittweise vorgehen. Es geht also nicht darum, mehrere Millionen Artikel auf einen Schlag zu übersetzen, sondern eine zusätzliche Möglichkeit anzubieten, die nach und nach eingeführt wird. Mit dem "Meta-English" meinst Du - wenn ich es richtig verstehe - etwa das gleiche, was ich mit den sprachübergreifenden Strukturdaten meine, nur verbunden mit dem englischen Artikel als eine Art Vorlage. Ich würde die Aussagekraft dieser Strukturebene aber bewusst darauf reduzieren, dass es eben ein Thema gibt (als begrifflicher Knotenpunkt in einer gedachten Wissensmenge), und inhaltliche Daten, die prinzipiell sprachabhängig sind, gar nicht erst dort hineintragen. Den Weg, den der Abgleich der inhaltlichen Daten und somit auch die Übersetzung nimmt, würde ich offen lassen. Ich tippe aber auch darauf, dass der englischsprachige Artikel derjenige sein wird, in den Änderungen immer als erstes übersetzt werden, und von dem dann weiter in die anderen Sprachen übersetzt wird. Aber die Strukturdaten sollten dennoch sprachunabhängig sein. Jeder Knoten in den Strukturdaten hat dann ein englisches Schlagwort (oder mehrere Schlagwörter/Synonyme), die gleichwertig zu den deutschen, bengalischen, etc. behandelt werden. Und die Bearbeitung der Strukturdaten sollte natürlich auch in jeder Landessprache möglich sein. --Dalvarez 01:53, 8. Dez. 2009 (CET)

Ein weiterer Gedanke: Die einheitliche Unterteilung in Abschnitte trüge dazu bei, die anfängliche Hürde, alle verschiedensprachigen Artikel zu einem Thema abzugleichen, deutlich zu senken. Durch die Einteilung kann man bereits für einen Abschnitt einen Abgleich herstellen, und der Abgleich großer Artikel kann somit in handhabbaren Teilschritten erfolgen. Außerdem bietet ein solches Grundgerüst eine Möglichkeit, die Arbeit an einem Artikel vorab gedanklich zu planen und aufzuteilen. Auch können strukturelle Änderungen an einer zentralen Stelle vorgenommen werden, und die Änderung wäre in allen verschiedensprachigen Artikeln zu dem Thema klar definiert, ohne dass Inhalte übersetzt werden müssten. Ich halte es für sinnvoll, auch Bilder und evtl. auch Quellennachweise auf der sprachunabhängigen Strukturebene zu erfassen. Dazu könnten dann natürlich in allen den Artikeln sprachabhängige Titel erfasst werden. Die Sprachunabhängige Struktur wäre keine Vorlage, sondern würde aktiv ausgewertet und wäre dadurch strukturbestimmend mit den jeweiligen sprachabhängigen Inhalten verbunden. Habt ihr ähnliche/abweichende Ideen? Was denkt ihr? --Dalvarez 02:12, 8. Dez. 2009 (CET)

Es wäre genial, da habt ihr recht. Ich glaube aber nicht, dass das umsetzbar ist, da dazu so etwas wie internationale Relevanzkriterien, Formatvorlagen etc. festgelegt werden müssten. Verschiedene Kulturen (Sprachen) haben davon aber weit auseinandergehende Vorstellungen. Dazu kommt zudem noch die babylonische Verwirrung erstens bei ebendieser Festlegung und zweitens bei der Strukturauszeichnungssprache. Einige Wiki-Nutzer wären begeistert, der große Rest (v. a. Neuautoren) wären in erster Linie von der Kompliziertheit abgeschreckt und das Wikiprojekt würde sterben.
Eine Möglichkeit wäre es, nur die Metadaten auf Commons zur Verfügung zu stellen und in die Sprachversionen automatisch per Infobox o.ä. einbinden zu lassen. Siehe auch ganz oben: Dauerbrenner: Trennung von Artikel und Meta-Daten: siehe Semantic MediaWiki. Diese Metadaten müssten aber ebenfalls sprachneutral, d.h. reine Zahlen sein. Als Beispiel die Personendaten: Geburts- und Sterbedatum wären innerhalb des Dezimalsystems und des gregorianischen Kalenders eindeutig, in andere Systeme lassen sie sich per Script übersetzen. Die Geburts- und Sterbeorte hingegen müssten als Koordinatenangaben gespeichert werden. die Bezeichnungen müssten händisch übersetzt werden, die Software muss von der Genauigkeit unterscheiden können. Der Geburtsort der Queen (erfunden), (genaue Koordinaten vorrausgesetzt) wird von den Briten als Ankleidezimmer festgelegt, die deutsche Version kennt bloß die übergeordete Bezeichnung Schloss xy. Schließlich die Beschreibung: Es wäre sinnvoll, wenn man deren Sprachvarianten direkt nebeneinander anzeigen lassen könnte, übersetzt müssten sie händisch werden. Gleichzeitig gibt es auch hier wieder das Präzisionsproblem wegen den Detaillierungskriterien der Sprachversionen.
Fazit: wenn es nur noch die eine Weltsprache gibt, gerne. Aber bis dahin wird es wohl an der Verschiedenheit der Wikis scheitern.
meint -- ✓ ^Bergi 14:35, 29. Dez. 2009 (CET)

Bei einer guten Übersetzung sollten insbesondere auch solche kulturabhängigen Besonderheiten und Vorlieben berücksichtigt werden. Ich spreche ja keinesfalls von einer wortgetreuen Übersetzung, sondern eben von einer vollwertigen Übersetzung, die den Satzbau auch vollständig verändern kann, und Unübersetzbares umschreiben oder zur Not auch nur annähernd genau übersetzen kann. Auch sind jederzeit Ergänzungen und Anmerkungen möglich, die der Verständlichkeit dienen. Zum Begriff Strukturauszeichnungs-"sprache" muss ich sagen, dass das über das Ziel hinausschießt. Was ich meine, ist eine einfache Sammlung an Strukturdaten, und nicht etwa eine Sprache. Diese Strukturdaten könnten einfach in einem relationalen Datenmodell abgelegt werden, oder auch als XML-Dokument. Eine bestimmte natürliche Sprache muss dazu nicht verwendet werden. Ein XML-Dokument für die Datenhaltung könnte etwa folgende Grundstruktur haben:

<Article>
   <Lemma language="EN">Solar Cell</Lemma>
   <Synonym language="EN">Photovoltaic Cell</Synonym>

   <Lemma language="DE">Solarzelle</Lemma>

   <Lemma language="ES">...</Lemma>
   <Lemma language="JA">...</Lemma>
   <Lemma language="ZH">...</Lemma>
   <Lemma language="BN">...</Lemma>
   <Lemma language="HI">...</Lemma>
   ...

   <Image File="solar cell.jpg">
      <Title language="EN">Solar cell made from a monocrystalline silicon wafer</Title>
      <Title language="DE">Aus monokristallinem Silizium hergestellte Solarzelle</Title>
      ...
   </Image>

   <Introduction>
      <Content language="EN">...</Content>
      <Content language="DE">...</Content>
      ...
   </Introduction>

   <Chapter>
      <Title language="EN">History</Title>
      <Title language="DE">Geschichte</Title>
      ...

      <Content language="EN">...</Content>
      <Content language="DE">...</Content>
      ...
   </Chapter>

   <Chapter>
      <Title language="EN">High-Efficiency Cells</Title>
      <Title language="DE">Hocheffizienz-Solarzellen</Title>
      ...
      
      <Image File="record efficiencies of research cells.jpg">
         <Title language="EN">Record efficiencies of research cells</Title>
         <Title language="DE">Rekord-Wirkungsgrade von Solarzellen unter Laborbedingungen</Title>
         ...
      </Image>

      <Section>
         <Title language="EN">High-Efficiency Cells</Title>
         <Title language="DE">Hocheffizienz-Solarzellen</Title>
         ...

         <Content language="EN">...</Content>
         <Content language="DE">...</Content>
      </Section>
   </Chapter>

   <See-Also-Ref>...</See-Also-Ref>
   <Reference>...</Reference>
   <External-Link>...</External-Link>
</Article>

Natürlich kann man das noch ausfeilen. Man könnte z. B. auch ein getrenntes Dokument pro Artikel und Landessprache erstellen. Dann könnte man sprachunabhängige Angaben in ein allgemeines Artikel-Dokument auslagern und sich die ständigen Sprachkennzeichnungen sparen, müsste dann aber auch mindestens jeweils zwei Dokumente auswerten, um eine Übersetzung auf Vollständigkeit hin zu validieren. In jedem Fall würde das Datenmodell dann über Schnittstellen bearbeitet werden, die das Dokument gezielt auswerten und jeweils nur die relevanten Daten (Quell- und Zielsprache) zur Bearbeitung bereit stellen. Zur schnellen Abfrage sollte natürlich alles in fertig aufbereiteter und gecacheter Form zur Verfügung gestellt werden (in den jeweiligen Landessprachen). Der Zugriff auf das eigentliche Dokument geschähe dann nur genau ein Mal nach jeder Bearbeitung, aber so funktioniert Wikipedia ja ohnehin (eingesetzt wird memcached). --Dalvarez 17:27, 13. Jan. 2010 (CET)

Möglicherweise wäre ein möglicher Name für so etwas "Wikipedia Translations". Etwas Software-Infrastruktur implementieren, und dann das Ganze als eigenständiges "Projekt" laufen lassen... In einem ersten Schritt könnte man die als "exzellent" bewerteten Artikel übersetzen. Viel mehr sagen kann man dazu wohl nicht, das Bild stellt sich sehr klar dar, jetzt geht es um die Umsetzung. Möglicherweise komme ich in den nächsten Wochen selber dazu, so etwas mit den derzeit aktiven Entwicklern abzusprechen und dann in Absprache umzusetzen. Derzeit kriege ich zeitlich kaum einen Fuß auf den Boden. Vermutlich wäre der richtige Ausgangspunkt für so etwas "Wikipedia Machine Translations" - ein Projekt, dass bereits läuft, dass aber den Fokus auf die Entwicklung automatisierter, statistisch gestützter Übersetzungen legt. Dennoch ist das letztliche Ziel von "Wikipedia Machine Translations" die Übersetzung von Wikipedia-Artikeln aus weit verbreiteten Sprachen in seltener verbreitete Sprachen. Klingt nach einem Ansatzpunkt für die Idee. -- Dalvarez 10:46, 8. Mai 2010 (CEST)

Anzeige des Sichters beim Vergleich der Artikelversionen

Ich würde mir wünschen, beim Vergleich von Artikelversionen neben einem Link zu den jeweiligen Bearbeitern auch einen vergleichbaren Link zu den etwaigen Sichtern zu sehen. --Pflastertreter 22:00, 2. Dez. 2009 (CET)

Anzeigeerweiterung bei Benutzerbeiträge

Ich fände es sinnvoll, wenn in der Liste der Benutzerbeiträge auch die Änderungsgröße (als Bytedifferenz) angezeigt würde. Damit wäre eine umfangreichere Änderungsliste oftmals gleichartiger Änderungen manchmal einfacher auf diejenigen Änderungen zu reduzieren, die einen zweiten Blick wert wären. --Pflastertreter 22:05, 2. Dez. 2009 (CET)

Mit Bug 24037 habe ich um die generelle Angabe der Bytes jeder Version bei den Benutzerbeiträgen gebeten. Die Bytedifferenz anzuzeigen ist zu aufwendig, da dann immer auch die frühere Version aus der Datenbank selektiert werden müsste, um die Differenz zu berechnen. Auf der Beobachtungsliste oder der letzten Änderung wird die Differenz in einer extra Datenbanktabelle gespeichert, die Datenbanktabelle umfasst aber nur die letzten 30 Tage (Generelle Begrenzung bei den letzten Änderungen). Der Umherirrende 22:39, 18. Jun. 2010 (CEST)

LiquidThreads

Hallo!

Es hat sich ein WikiProjekt geformt (Wikilink später), dass die Umstellung auf LiquidThreads, die in Zukunft irgendwann kommen sollen, helfen soll. Ich weise jeden, der denkt seine Skripte/Bots/etc. könnten von der Umstellung betroffen sein auf dieser Diskussion hin. Es geht dort nicht um den Vorschlag von Kolossos, sondern um die Vorbereitung zur Umstellung auf LiquidThreads. Bitte nicht hier oder auf der Hilfeseite antworten, sondern direkt zur Projektseite gehen oder sie zumindest beobachten. Weihnachtsgruß --Euku:^⇄ (LiquidThreads) 22:57, 25. Dez. 2009 (CET)

Spezial:Statistik

Hallo, ich finde, die Statistik wäre noch viel nützlicher, wenn sie auch die Anzahl der Seiten nach Namensraum, Namensraum:Diskussion und Weiterleitungen je Namensraum auflösen würde. So könnte man z.B. errechnen, wie viele Stichwörter es gibt (Artikel + Weiterleitungen im ANR). Zudem wäre es interessant, wie die registrierten Benutzer auch die Sichter in "Sichter gesamt" und "Sichter aktiv" aufzuteilen. Ebenso mit den Admins. --Carbenium 18:39, 29. Dez. 2009 (CET)

Ein und Ausblenden von Elementen

Hallo, ich hatte mir zur Zeit einige Gedanken darüber gemacht wie man zusätzliche Informationen in Infoboxen oder auch anderweitig bereitstellen könnte, ohne dabei den eigentlichen Inhalt eines Artikels zu überfluten. Dabei ist mir aufgefallen, dass hierzu immer mal wieder die Klappfunktion der Navigationsboxen mehr oder weniger missbräuchlich und erfolgreich eingesetzt wird. Bei einigen Vorlagen könnte es durchaus nützlich sein zusätzliche Elemente anzuzeigen, wenn ein anderes Element angeklickt oder mit der Maus über das Objekt gefahren wird.

Dabei fiel mir natürlich auf, das eine solche Umsetzung ohne Javascript nicht realisierbar ist und man es ja auch aus Sicherheitsbedenken nicht innerhalb von Artikeln oder Vorlagen verbauen kann. Daher dachte ich hier eine eingeschränkte Funktionalität, durch welche ein Element ein oder ausgeblendet werden kann, wenn ein anderes Element angeklickt wird oder mit der Maus (mouseover) eben über ein solches gefahren wird. Im folgenden habe ich mal ein Beispiel skizziert, aus dem ersichtlich werden sollte was ich meine:

<div id="switch-visibility-id1"/>
<div id="switch-target-id1"/>

<div id="switch-visibility-id2"/>
<div id="switch-target-id2"/>

Wird auf das Element mit der ID "switch-visibility-id1" geklickt, dann sollte "switch-visibility-target-id1" entweder ausgeblendet (display:none) oder eingeblendet werden. Dies wäre in etwa die gleiche Funktionalität wie bei den Klappboxen, nur eben flexibler. Zugleich würde ich mir wünschen, das dies ebenfalls mit "mouseover" funktionieren würde, sodass man z.B. die Möglichkeit hat informative Popups einzublenden, wenn dies notwendig oder sinnvoll sein würde.

Gefahr würde ich von dieser Funktionalität nicht ausgesehen sehen, da der Code entsprechend in der entsprechenden *.js Datei von Wikipedia enthalten wäre und nicht geändert werden kann, wie es ja auch bei den jetzigen Klappboxen der Fall ist.

Beispiele für eine sinnvolle Verwendung

In vielen Infoboxen wird immer wieder darüber beraten welche Parameter überhaupt angezeigt werden sollen, damit die Box nicht überdimensioniert ist. Gleichzeitig werden diese immer wieder als sinnvoll angesehen. Zur Anzeige solcher zusätzlichen Angaben, die nicht auf den allerersten Blick von Interesse sind, würde sich solch eine Funktionalität gut eignen. (Typische Negativbeispiele: Canon EOS 1000D, MG34 (Maschinengewehr), ...)

Machbarkeit und offene Fragen

Was haltet ihr von dieser Idee? Gibt es diesbezüglich Bedenken? Wenn ja, welche? -- 12:18, 29. Dez. 2009 (CET)

Klingt gut. Ich würde mir wünschen, dass innerhalb von Naviblocks einzelne Leisten per Mouseover ausklappbar wären. Wechselt der Fokus, klappen sie wieder zu. Die Möglichkeit des klickbaren Öffners/Schließers sollte aber erhalten bleiben, wenn mehrere gleichzeitig geöffnet werden sollen. Dieser Link, der zurzeit per Javasript dazugebaut wird (Text per:

var NavigationBarHide = 'Einklappen'; var NavigationBarShow = 'Ausklappen';, ich habs bei mir eh schon durch ▲ / ▼ ersetzt) sollte frei gesetzt (& positioniert) werden können.

Das erste könnte man beinahe per CSS bauen:

p#versteckbar       {visibility:inherit; height: 100%; }
p#versteckbar:focus {visibility:hidden; height: 5px; }

meint -- ✓ ^Bergi 15:04, 29. Dez. 2009 (CET)

Ich würde es gar nicht so kompliziert gelöst haben wollen. Ein einfaches Script mit folgender Funktionalität (als Pseudocode) sollte bereits reichen und weitgehende Freiheit gewähren:

1. Suchen aller Elemente die als id mit dem Prefix (z.B. switch-visibility) beginnen
2. Bei jedem dieser Elemente einen Event-Listener registrieren, der das dazu passende Element über die id anzeigt oder versteckt

schrieb -- 15:21, 29. Dez. 2009 (CET)

PS: Was mir noch nicht ganz klar ist, wie man das zugehörige Element bei Mehrfacheinbindungen von Vorlagen eindeutig identifizieren könnte. Schließlich würden die Elemente bei meinem derzeitigen Gedanken ja die gleiche "id" tragen, was sehr unschön ist. Wie ist das denn bei den Navigationsleisten umgesetzt? -- 15:26, 29. Dez. 2009 (CET)

Das sind mehrere Klassen. Ich hatte mich schon gewundert, als du was von IDs schriebst, das gibt bloß Salat. Die Funktion findest du hier, F3 nach "Nav". Man könnte imho in das Navi-div eine Auszeichnung <div class="Navxy" text="{{{Anzeige}}}>" oder so einbauen, die über ein verändertes JS ausgelesen wird, um den Anzeigetext zu ändern.
meint -- ✓ ^Bergi 16:23, 29. Dez. 2009 (CET)

Letzter Gedanke wird wohl nicht funktionieren, da - so glaube ich - nicht bekannte Attribute ausgefiltert werden und somit nicht beim JS ankommen würden. Trivialer Weise könnte man mein Problem damit umgehen, das nach dem Auffinden eines bestimmten Klassenattributes (z.B. "verstecker") einfach nach dem nächsten DIV-Element sucht, welches zur Klasse "versteckbar" gehört. Damit das effizient machbar ist, sollte man, wie schon bei dem Script der Navigationsleisten, die ID der Elemente nach einem ersten Durchlauf festlegen (durchnummerieren). Dadurch wäre es dann auch wieder eindeutig und nicht auf eine gewisse Anzahl beschränkt. -- 16:51, 29. Dez. 2009 (CET)