Wikipedia:Verbesserungsvorschläge

Diese Seite ist zur Diskussion von Verbesserungsvorschlägen technischer Art an der deutschsprachigen Wikipedia gedacht;
sie ersetzt nicht die Diskussionsseiten der Artikel- oder anderer Wikipedia-Seiten.

---

Es gibt immer was zu tun …

Artikel-Inhalte werden direkt beim/im Artikel verbessert, Änderungen an Seiten der anderen Namensräume auf den entsprechenden Diskussionsseiten verhandelt, siehe Wikipedia:Diskussionsseiten. Vermutete Softwarefehler (Bugs) bitte gemäß Hilfe:Fehler und Probleme melden; am einfachsten in der Werkstatt. Softwareverbesserungen bitte auf der Unterseite Wikipedia:Verbesserungsvorschläge/Feature-Requests vorschlagen bzw. bewertend kommentieren, damit man sehen kann, welche Vorschläge an die Entwickler weitergeleitet werden sollten. Projektanregungen nichttechnischer Art, auch Anregungen auf Basis von Erfahrungen aus anderen Wikimedia-Projekten, können auf Wikipedia:Projektdiskussion besprochen werden. Allgemeine Fragen zur Wikipedia und zur Artikelbearbeitung werden bei Wikipedia:Fragen zur Wikipedia diskutiert. Administratives: Falls es sich um eine Angelegenheit handelt, die durch einen Administrator erledigt werden kann, stelle eine Anfrage bei Wikipedia:Administratoren/Anfragen.

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 (aktuelles 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

Oft Gefragtes (FAQ)

• Besucherzähler/Statistikanzeige pro Artikel: Gibt es prinzipiell, ist aber schon lange wegen zu hoher Serverbelastung ausgeschaltet. Über dieses externe Tool kann zu jedem Artikel die Seitenzugriffszahl ermittelt werden.
• Rechtschreibprüfung: Ist für angemeldete Benutzer in den Einstellungen, Karteireiter Helferlein (Abschnitt Bearbeitungswerkzeuge) verfügbar.
• Alte oder neue Rechtschreibung: siehe Wikipedia Diskussion:Rechtschreibung
• Farbenblindheit: Linkfarben lassen sich benutzerspezifisch auf für Farbenblinde besser erkennbare Farben umstellen, siehe Hilfe:Eigene Stylesheets und Benutzer:Wolfgangbeyer/monobook.css. Weiterhin kann durch Aktivierung des Gadgets Rot-Grün-Sehschwäche-Helferlein die Wikipediaoberfläche für Rot-Grün-Fehlsichtige in für sie erkennbare Farben abgewandelt werden. Zudem kann man die Linkfarben auch in den Einstellungen des Browsers festlegen.
• Artikel bewerten: Ein Bewertungssystem ist noch in Entwicklung/Testphase begriffen (Diskussion bitte auf Mailinglisten)
• Redirects auf Artikelabschnitte sind technisch möglich. Vorzuziehen ist jedoch eine Verlinkung auf Artikelabschnitte durch die Vorlage:Anker. Dadurch bleibt der Link auch bei Änderung der Abschnittsüberschrift aktuell.
• Javascript einbinden: ist ein Sicherheitsproblem und wird es deshalb nicht geben.
• Externe Links prinzipiell in einem separaten Fenster öffnen: wird es nicht geben, empfinden auch viele Nutzer als bevormundend. (Wo ein Link geöffnet wird, kann man in den meisten Browsern selbst entscheiden durch die Art, wie man draufklickt.)
• Mindestgröße für neue Artikel: umstritten, siehe WP:WSIGA
• Allgemeinen Zugriff auf gelöschte Artikel: gibt es derzeit nicht
• Beim Bearbeiten anzeigen, zu welchen Begriffen Artikel existieren: sehr aufwendig zu realisieren. Lösung: Vorschau oder das externe Tool Wikifizierer (veraltet: Artikelliste vom 09.12.2004) von Bananeweizen nutzen.
• Artikelvorschau beim Überfahren von Links: Ist für angemeldete Benutzer in den Einstellungen, Karteireiter Helferlein (Abschnitt Lesehilfen) verfügbar.
• Metadaten, welche die Richtigkeit belegen: Interessant, aber aufwendig
• Essays: Eventuell, und wenn, dann nur was für Wikibooks
• RSS-Feed: ist verbesserungswürdig, hat aber eine geringe Priorität
• Versionsgeschichte erweitern um Grund für Löschung/Sperrung/Wiederherstellung und welcher Admin ausführte : Interessant, zum Teil umgesetzt über "Ansicht gelöschter Versionen"
• Expertenabschnitte: Kontrovers diskutiert, kein Ergebnis

Feature-Requests und Bugreports auf Bugzilla

Feature-Requests sind auf der Unterseite Wikipedia:Verbesserungsvorschläge/Feature-Requests zu finden.

Wenn ein hier diskutierter Feature request auf Bugzilla gestellt wurde, bitte hier auflisten:

• Bug 164: Sprachspezifische Sortierreihenfolge (also Ä unter A und nicht ÄÖÜ nach Z z. B. auf Spezial:Allpages)
• Bug 189: Musikmodul für Mediawiki
• Bug 674: Artikel für einzelne Benutzer sperren
• Bug 708: Links zu den Schwesterprojekten (Wiktionary, Wikibooks etc.) ins Interface integrieren
• und viele weitere - mit einem Account könnt ihr für einzelne Bugs voten

Verbesserungsvorschläge

Wer ist ein Wikipedia:Benutzer?

Ich vermute, ich spreche einen Evergreen an. Es hat mich schon immer irritiert, dass die ehrenamtlichen Mitarbeiter an WP als Benutzer bezeichnet werden, während in meinen Augen die Leute, die in WP etwas nachschlagen wollen, die eigentlicher Benutzer sind. „Benutzer“ ist etwas Passives, die „Mitarbeiter“ aber verschwenden „Blut, Schweiß und Tränen.“ Vermutlich wäre die Umstellung ein Riesenaufwand, aber Ähnliches haben wir ja bereits bei „Bild“ und „Datei“ gehabt. Frdl. Gruß --23:00, 5. Jun. 2010 (CEST)

Zustimmung ! --michelvoss 11:34, 6. Jun. 2010 (CEST)

Das wäre sogar ein noch größerer Aufwand, weil es in allen Sprachversionen "User", "Usurario", "Gebruiker", "Benutzer" usw. heißt. Der Name ist nicht wirklich treffend, hat aber inzwischen Tradition, ich würde ihn lassen. -- Perrak (Disk) 12:43, 6. Jun. 2010 (CEST)

Die en:WP hat immerhin eine Category:Wikipedians. „Benutzer“ ist falsch und herabsetzend. Würde eine Umstellung sehr begrüßen. --Hydro 12:56, 6. Jun. 2010 (CEST)

Das Wort User in seiner englisch-amerikanischen Bedeutung hat durchaus auch aktive Aspekte, Benutzer dagegen etwas einseitig Nehmendes. Insoweit haben wir hier ein typisches Beispiel für eine nicht geglückte Übersetzung; Anwender oder Bediener (als Übersetzung für user) wären immerhin etwas besser gewesen, aber auch nicht überzeugend. Müssen wir uns denn unbedingt mit einer passenden Übersetzung von user quälen, nur weil die amerikanische WP die Stammmutter ist? Wären englischsprachige WP-User irritiert, wenn es bei uns Mitarbeiter hieße? --Ulrich Waack 13:19, 6. Jun. 2010 (CEST)

ich halte das ja für eine absolut nebensächliche marginale und halte nichts davon das zu ändern; viel aufwand kein nutzen. aber wer spaß dran hat; auf pl heißen die benutzer Wikipedysta ....Sicherlich ^{Post / FB} 13:23, 6. Jun. 2010 (CEST)

Ja, Wikipedianer ist in jedem Fall besser als Benutzer, aber ich denke auch: Das Problem liegt nicht so sehr in einer passenden Wortfindung, sondern im technischen Aufwand der Umstellung, den ich nicht beurteilen kann. --Ulrich Waack 13:27, 6. Jun. 2010 (CEST)

Aus Bequemlichkeit etwas Verbesserungsbedürftiges so lassen? Das ist aber keine wp-würdige Lösung! --94.79.153.44 14:07, 6. Jun. 2010 (CEST)

Zum Vergleich: der user oder Benutzer heißt Westfriesisch Meidogger, Ripuarisch Metmaacher (Mitmacher, Mitarbeiter)

Die beiden gleichbedeutenden Namensraumpräfixe User: und Benutzer: um ein weiteres zu ergänzen, ist technisch gesehen simpel. Dazu muß man in der deutschen Lokalisierungsdatei in der Liste der $namespaceAliases (derzeit etwa in der Zeile 74) beispielsweise diese Zeilen eingefügen:

'Autor' => NS_USER,

'Autorendiskussion' => NS_USER_TALK,

Danach können Benutzer: und Autor: wahlweise verwendet werden.

Eine ähnliche Diskussion gab es auch über die Einführung von Benutzerin:

--Purodha Blissenbach 13:57, 11. Jun. 2010 (CEST)

Versuch einer Zusammenfassung: Ich sehe eine zustimmende Mehrheit. Die technische Umsetzung scheint ohne großen Aufwand machbar zu sein. Als neue Bezeichnung für Benutzer scheint sich Mitarbeiter anzubieten (oder MitarbeiterIn mit großem I?) oder Autor. - Falls nicht widersprochen wird - was ist der nächste Schritt? --Ulrich Waack 14:14, 13. Jun. 2010 (CEST)

Die oben von Purodha vorgeschlagene Änderung der deutschen Lokalisierungsdatei ist für eine projektspezifische Änderung tabu, da diese dann für alle Projekte der Wikimedia Foundation sowie alle Dritt-/Firmenwikis gelten würden. Nichtsdestotrotz wäre die Änderung über eine lokale Konfigurationsänderung möglich. Aber

a) ist zustimmende Mehrheit bei ~ 6 Diskutanten nicht aussagekräftig und

b) die Systemadministratoren für eine solche Änderung eine aussagekräftiges Meinungsbild fordern und

c) ich persönlich mich nicht für b) engagieren werden, da ich lieber Wichtigeres mache, was die Wikipedia inhaltlich voranbringt. — Raymond ^Disk. 17:07, 13. Jun. 2010 (CEST)

Nebenbei, der Ausdruck "Mitarbeiter" ist im Deutschen ein seit langem eingeführter terminus technicus und Euphemismus für "Arbeitnehmer", dieser wiederum ein Euphemismus für entweder Arbeiter oder Angestellter oder Beamter. Wenn von Mitarbeitern der Wikipedia die Rede wäre, würde jeder Nichtsahnende denken, das seien bezahlte Angestellte der Firma Wikipedia. Solche Mitarbeiter gibt es ja auch, also Verwechslungsgefahr. Der englische Ausdruck "user" (das ist auch nur ein Anwender, also kein Stück besser) wird gemeinhin mit "Nutzer", nicht mit "Benutzer" wiedergegeben. Ich kenne außer der Wikipedia keine Einrichtung im Internet, die einen so skurrilen Ausdruck verwendet. (Und wenn doch eine so aufwändige Änderung, dann natürlich nur in "Wikipedianer(in)". --Peewit 18:05, 25. Jun. 2010 (CEST)

Habt Ihr Langeweile, Euch so in Formalia zu ergehen? In der QS liegt genug Arbeit rum... ;-) Aber mal ehrlich: Sich durch eine semantische Softwarekonfiguration beleidigt zu fühlen, finde ich schon eine beachtliche Leistung. Wenn wir damit anfangen, müssen wir konsequenterweise auch versuchen, den ganzen Computer-Neusprech und alles sonstige Technogebabbel umzupolen. Sollte aus irgendeinem Grunde eine Umbenennung durchkommen, bitte NICHT "Mitarbeiter" (s.o., das Arbeitnehmerargument), sondern dann wünsche ich mir eine Bezeichnung als "Autor". Ach ja, und was machen wir mit Leuten, die nur in der QS helfen? Benennung als "Qualitätssicherer" oder "Helfer"? Wollen wir das Binnenmajuskel-I einführen? So à la "AutorIn", "QualitätssichererIn" (oder muss das dann "QualitätssicherIn" heißen?!) oder "HelferIn"? Und was wenn einer das Metier wechselt? Ratlose Grüße, Carbenium 16:17, 10. Jul. 2010 (CEST)

- - > Wikipedia:Umfrage zur Benennung der Mitarbeiter, -jkb- 16:25, 10. Jul. 2010 (CEST)

THX. --Carbenium 16:57, 10. Jul. 2010 (CEST)

Spezial:Weblink-Suche

(Dieses Thema wurde nachträglich von der Seite "Hilfe Diskussion:Diskussionsseiten" hier hergeschoben.)

Bitte die Protokolle verlinken, nicht jeder kann sich darunter was vorstellen, danke. --213.168.121.113 21:30, 10. Aug. 2009 (CEST)

Das ist Softwaretechnisch mit der aktuellen Mediawiki-Version nicht möglich, da die Protokollliste nicht lokal anpassbar ist. Müsstest du auf bugzilla: als neues Feature beantragen. Merlissimo 14:01, 10. Jun. 2010 (CEST)

Habe mal Bug 24038 erstellt. Falls ich mich dort nicht weitgenug gefasst habe, einfach ergänzen. Der Umherirrende 22:51, 18. Jun. 2010 (CEST)

Bitte (über)große Seiten kennzeichnen

Wie wäre es dann mal, wenn (über)große Seiten (wie z.B. "Wikipedia:Usability-Initiative/Feedback", also ab gefühlten zwei Gigabyte) vor dem Öffnen gekennzeichnet werden oder besser davor gewarnt wird? Ein Ort für diese Warnung wäre vielleicht, der Titel-Auszeichner (oder auf Neusprech das HTML-Title-Tag), der sichtbar wird, wenn ein normaler Nutzer mit seiner Maus über einen Verweis fährt. Und damit die Leute nicht damit beläßtigt werden, die normalerweise vor einem Superrechner sitzen, sollte diese Warung (über die Einstellungen) abgeschaltet werden können.
--Konrad – 09:23, 13. Jun. 2010 (CEST)

gudn tach!

hehe, dass ausgerechnet auch die usability-seite von dem problem betroffen ist, verleiht dem ganzen etwas komisches.

imho sollten solche seiten nicht (zeitlich) lange so gross sein und ansonsten aufgeteilt werden. bei talk-page-archiven gilt ja bereits die faustregel, dass jene nur etwa 250kB gross sein sollen. das halte ich fuer besser, als user mit lahmen computern auszusperren. -- seth 18:29, 13. Jun. 2010 (CEST)

Eigentlich ist nicht die Größe derartiger Seiten das (Haupt-)Problem (wobei die oben genannte Seite im Moment gerade einmal 567 Kibi- oder Kilobyte groß ist), sondern die übermäßige Anwendung von JavaScript. Oder anders ausgedrückt, das Problem hierbei ist die unsinnige Verschiebung aktiver Inhalten von der Server- auf die Klienten-Seite. Wobei auch mit den sogenannten Helferlein (oder auf Neusprech Gadgets) immer mehr der ursprünglich angedachte Sinn vom Klient-Server-Konzept auf den Kopf stellt wird.
--Konrad – 13:55, 15. Jun. 2010 (CEST)

Das ist eigentlich kein Problem, sondern die Lösung. Oder wie willst du aktive Inhalte denn sonst bereitstellen, wenn nicht per JavaScript? Und all diese JS- und CSS-Dateien lagert ein (vernünftig eingestellter) Browser einmal in den Cache, und ruft sie nie wieder ab. Leider sind halt auch einige Techniken, die für den Normalfall zu aufwändig sind (wie die von dir angesprochene Mitversendung der Seitengröße), nicht kompliziert als Einstellung in Mediawiki implementiert, sondern einfacher per JavaScript nachprogrammiert. Wobei, versuchen kann mans ja mal: bugzilla:23979.
meint -- ✓ ^Bergi 18:20, 15. Jun. 2010 (CEST)

Prima, aber leider nur eine Bekämpfung der üblichen Begleiterscheinungen (oder Symtome). Und dann nur zur Klarstellung, es liegt mir (allein schon aus Mangel an den dafür erforderlichen Englischkenntnissen) fern hier irgendwelche aktiven Inhalte bereit zu stellen und schon gar nicht mit JavaScript. Der Gedanke hinter meiner Anmerkung war eigentlich, daß dieses Klient-Server-Konzept mal etwas besser beachtet und auch tatsächlich umgesetzt werden sollte. So bin ich z.B. der Meinung, daß die Helferlein die bereits umgesetzt sind und sich schon über eine längere Zeit (positiv oder ohne negative Rückmeldungen) bewährt haben, dann irgenwann auf die Serverseite – also richtig ins MediaWiki hineingebracht werden sollten, so daß die dadurch anfallenden Berechnungen eben vom Server (also der der eigentlich die Dienste bereitstellen und fertig ausleifern sollte) und nicht vom Klienten (der der die Dienste normalerweise nur entgegennimmt und verwendet) berechnet werden. Und um mal ein konkretes Beispeil zu nennen, da wäre etwa mal wieder das Thema „Zeitzonen“ (siehe auch „MediaWiki Diskussion:Gadget-Zeitzonenkonverter.js“ und vielleicht auch passend dazu „Hilfe Diskussion:Einstellungen#Datum und Zeit“), welches mit dem Zeitzonenkonverter zwar schon ansatzweise umgesetzt wurde, aber eben ganz offensichtlich immernoch vom Klienten selbst berechnet werden muß und nicht – wie man es bei einer echten Klient-Server-Struktur erwarten würde – vom Server fix und fertig ausgeliefert wird. Wenn das genannte Beispiel eben mal richtig umgesetzt werden würde, dann sollte der Nutzer (oder der Klient) – der das bei sich entsprechend eingestellt hat (also in diesem Beispiel hier eine Zeitzone seiner Wahl) – auch komplett vom Server (einschließlich dem entsprechend angepaßten Quelltext) ausgeliefert bekommen. Übrigens scheint das beim Wiktionary schon seit einiger Zeit (zumindest mit ME(S)Z) zu funktionieren (siehe auch Wiktionary:Teestube). Bin mal gespannt, welche Zeitzone uns nach der nächsten Umstellung erwartet, wenn das MediaWiki dahingehend auch bei der Deutschen Wikipedia wieder umgestellt wird.
--Konrad – 20:18, 15. Jun. 2010 (CEST)

Zeitzonen sind ja auch statische Inhalte, und keine aktiven. Leider scheitert es hier am Mehrheitswillen, denn eine Umstellung (umgesetzt wie auf Wiktionary) würde für alle Nutzer gelten und nicht individuell einstellbar sein. Zudem dürfte es ein größeres Problem sein, sämtliche alten Formate zu parsen, die ja überall verstreut liegen. Ein Botlauf diesen Ausmaßes bräuchte schon sehr viele Umstellungsbefürworter, den meisten wird es aber egal sein und sie werden die Hamster nicht wegen sowas laufen lassen. -- ✓ ^Bergi 21:26, 15. Jun. 2010 (CEST)

Einstellbare Zeitzonen

(Der folgende Beitrag wurde nachträglich vom Thema „Bitte (über)große Seiten kennzeichnen“ hier herkopiert.)

Zeitzonen sind ja auch statische Inhalte, und keine aktiven. Leider scheitert es hier am Mehrheitswillen, denn eine Umstellung (umgesetzt wie auf Wiktionary) würde für alle Nutzer gelten und nicht individuell einstellbar sein. Zudem dürfte es ein größeres Problem sein, sämtliche alten Formate zu parsen, die ja überall verstreut liegen. Ein Botlauf diesen Ausmaßes bräuchte schon sehr viele Umstellungsbefürworter, den meisten wird es aber egal sein und sie werden die Hamster nicht wegen sowas laufen lassen. -- ✓ ^Bergi 21:26, 15. Jun. 2010 (CEST)

Eine einfache statische und somit (nur in einem Wiki) eben leider auch nur globale Umstellung der Zeitzonen (wie das bereits beim deutschen Wiktionary – mit der Umstellung von UTC nach ME(S)Z – sowie übrigens auch bereits bei der deutschen Wikipedia – mit der Umstellung von UTC nach CE(S)T – mindestens schon einmal geschehen ist) war von meiner Seite aus nie angedacht und sicher auch nicht gewollt. Denn es wird ja nicht nur in der mitteleuropäischen (Sommer-)Zeitzone die deutsche Sprache verwendet, sondern auch in anderen Zeitzonen. Und die jeweiligen Nutzer sind sicher auch (stillschweigend) verärgert, wenn sie jedes Mal die Zeitstempel ihrer Beiträge aus irgend einer anderen Zeitzone in ihre lokale Zeit umrechnen oder – wie zur Zeit hier (wenn sich zufällig ein Autor in der passenden Zeitzone befindet), auch nur von CE(S)T nach ME(S)T – übersetzen müssen. (Zudem haben die jeweils verwendete Sprache und die Zeitzone ja eigentlich auch nicht wirklich etwas miteinander zu tun.) Daher hatte ich ja auch schon (mehrfach) den Vorschlag der (über Benutzer-Einstellungen) Einstellbaren Zeitzonen gemacht. Und der daraus bisher entstandene Zeitzonenkonverter ist daher wohl auch nur als Provisorium anzusehen, welches vielleicht als Vorlage oder Ansatz für eine entsprechende MediaWiki-Erweiterung dienen könnte, die diese Bezeichnung auch wirklich verdient.

--Konrad – 09:39, 16. Jun. 2010 (CEST)

ME(S)T ist gleich CE(S)T, wobei das eine die englischsprachige Variante ist. Im deutschen wiktionary wird lokal die Zeitzone lokalisert (wikt:de:MediaWiki:Timezone-cest/wikt:de:MediaWiki:Timezone-cet). Dazu gab es schonmal eine Diskussion, es hat sich nur kein Admin getraut. Ich kann außerdem nur davon abraten, die alten Zeitstempel anschließend zu ändern, da es ein unnötiger und Fehleranfälliger Overhead ist. Es muss einfach ein Strich gezogen werden und fertig. Der Umherirrende 19:57, 17. Jun. 2010 (CEST)

gudn tach!

wie in der verlinkten diskussione bereits angemerkt, kann man es einfach bei den internationalen bezeichnungen belassen und muss somit nicht mal einen strich ziehen. -- seth 00:15, 18. Jun. 2010 (CEST)

Der Strich kann hier aber erst gezogen werden, wenn endlich mal dieses imperialistische Gehabe abgeschafft wird, mit dem hier immer wieder versucht wird, die deutsche Sprache zu anglisieren. Es wurde auch schon mehrfach genannt, daß ME(S)Z (natürlicherweise) im deutschen Sprachraum wesentlich gebräuchlicher ist, als das englische CE(S)T. Was gibt es da also noch zu diskutieren? In der Regel wird doch gerade das als DAS Totschlagargument verwendet, um z.B. auch deutschsprache Artkelnamen in englischsprachige umzubenennen. Aber jeder sieht und hört eben nur das, was er sehen will, oder? Und sich dabei einfach nur darauf zu berufen, daß eine anständige Übersetzung (natürlich) etwas mehr Arbeit macht, ist sicher auch kein guter Grund. Ansonsten können wir auch gleich alle Wikipedias unter einer vorgeblich internationalen oder noch einfacher, unter der englischen Wikipedia zusammenfassen. Im Übrigen, für die die es noch nicht wissen, die deutsche Sprache wird auch international verwendet (siehe auch Deutsche Sprache).
--Konrad – 11:50, 18. Jun. 2010 (CEST)

Dann nochwas, angeblich soll es ja gerade ein Vorteil von Software sein, daß diese leicht geändern werden kann. Irgendwas stimmt doch dann hier nicht, wenn die Entwickler der selben sich gegen jede Änderung streuben. Was mich gedanklich auch gleich wieder zurück zu den oben bereits angedeuteten üblichen Begleiterscheinungen bringt, welche mit einer ordentlichen Programmierung und der vernünftigen Trennung zwischen Klienten und Servern erledigt werden könnten.

--Konrad – 12:16, 18. Jun. 2010 (CEST)

Signaturen werden als Teil der Seite gespeichert, daher ist es nicht möglich, die Zeitzone der Signatur bei der Anzeige zu ändern, da es viel zu aufwendig und fehleranfällig ist. Mit LiquidThreads könnte sich das ändern. Ich weiß aber nicht, ob es dort vorgesehen ist, das sich die Diskussionszeit nach den Einstellungen richtet. Der Umherirrende 16:31, 18. Jun. 2010 (CEST)

Na das scheint ja ein Schritt in die richtige Richtung zu sein. Danke für den Hinweis, Umherirrender. :-)

--Konrad – 08:25, 20. Jun. 2010 (CEST)

Suche in anderen Sprachen

Ich will mit einem Beispiel anfangen: Das Reparatur-Handbuch für mein Motorrad habe ich nur auf Englisch und ich wollte jetzt mal eben nachsehen, wass denn "Crankcase" bedeutet. Hierzu wie gewohnt im Opera-Browser "w crankcase" eingetippt, um die Wikipedia zu durchsuchen -- bei mir standardmäßig die deutsche. Natürlich wird nichts gefunden, wie denn auch. Also zur englischen Version wechseln (wikipedia.org eintippen, weil ich auf den ersten Blick keinen Link finde), nochmal Suchen, Artikel anzeigen und Sprache auf Deutsch wechseln. Aha, "Kurbelgehäuse" also.

Worauf ich hinaus will: Wenn eine Suche nicht direkt einen Artikel zu Tage fördert, werden ja die Ergebnisse der Volltext-Suche gezeigt. Kann man da nicht eine kleine Funktion einbauen, so dass man nach dem gleichen Begriff in anderssprachigen "Projekt-Ablegern" suchen kann?

Das spart in solchen Fällen einige Mausklicks und Tastendrücke. Ich weiß der Wunsch ist wohl etwas exotisch, aber fragen kost ja nix :-) (nicht signierter Beitrag von 92.231.180.178 (Diskussion) 00:56, 18. Jun. 2010 (CEST))

Du kannst auch "w en:crankcase" eintippen. Alles, was du auch hier als Link schreiben kannst - also auch z.B. "w en:wikt:crankcase" wird funktionieren. Merlissimo 01:10, 18. Jun. 2010 (CEST)

Da fällt mir nur "RTFM" ein, hätte wohl nur mal irgendeine Doku lesen müssen. Vielen Dank für die Antwort, funktioniert in der Tat ganz fabelhaft :) (nicht signierter Beitrag von 92.231.183.225 (Diskussion) 20:20, 18. Jun. 2010 (CEST))

Oder du nutzt http://vs.aka-online.de/globalwpsearch/. Diese Suche könnte man evtl. auch verlinken, solange dadurch nicht die Gefahr einer Abschaltung wegen Überlastung geschaffen wird. -- ✓ ^Bergi 13:15, 19. Jun. 2010 (CEST)

Ich möchte mich dem Wunsch trotzdem anschließen. Wenn der Begriff nicht gefunden wurde, wäre insbesondere ein Link zu englischen Wikipedia sehr hilfreich, statt dort den Begriff nochmal eingeben zu müssen. Es geht mir nicht so um eine Übersetzung, sondern es gibt eben viele Begriffe, die deutsch und englisch gleich sind oder auf deutsch gar nicht existieren. Zumal außerdem nicht jeder über die Opera-Funktion "w " bei der Wikipedia landet, und diese nicht wirklich hilft, wenn man nicht weiß in welcher Wikipedfia der Artikel möglicherweise vorhanden ist... --92.225.21.189 20:18, 4. Jul. 2010 (CEST)

Das können inzwischen fast alle modernen Browser. Ich nutze es seit FF 2 (Wikipedia-such-addon Snstallieren->suchmaschienen verwalten und ein Schlüsselwort definieren z.B. das "w"). Beim IE 8 hab ich es auch schon gesehen. 05:48, 6. Jul. 2010 (CEST)

Spezial:Hochladen – Vorschaufunktion

Hallo, auf Commons existiert bereits seit geraumer Zeit eine Vorschau-Funktion für die Dateibeschreibungsseite beim Hochladen. Ist es möglich, diese Funktion auch bei unserem Hochlade-Formular zu übernehmen? Dies würde Arbeit das spätere Ausbessern der Seiten ersparen. Grüße --Carport ^{(Disk. • ± • MP)} 11:11, 19. Jun. 2010 (CEST)

klar dafür, hatte ich vor Ewigkeiten auch schon einmal vorgeschlagen. --Ephraim33 15:25, 19. Jun. 2010 (CEST)

Inhaltsverzeichnis ohne Gliederungsziffern

Von der Vorlagenwerkstatt (bitte dem Link folgen) hierher verschlagen, und gleich der Vorschlag für ein Magic Word:

__NONUMTOC__

Eine neue Vorlage oder ein Parameter für bereits bestehende Vorlagen wäre natürlich auch klasse, um dat Janze z.B. mit {{TOCright}} besser kombinieren zu können. Ich weiß nicht, ob es irgendwie weiterhilft, doch hier noch die funktionierende CSS-Zeile, gerichtet auf Wikipedia:Hauptseite/Aktuelles/Archiv 2010:

.page-Wikipedia_Hauptseite_Aktuelles_Archiv_2010 .tocnumber { display: none; } (zum Testen: MonoBook, Vector)

Danke fürs Kopferbrechen :-) Hæggis || ☎→♜ 17:24, 19. Jun. 2010 (CEST)

references-tag auch beim bearbeiten von einzelnen abschnitten

ist es sinnvoll und möglich, beim bearbeiten von einzelnen abschnitten und dem anschliessenden benutzen der vorschaufunktion ganz am ende ein <refences />-tag zu simulieren, dass einem den inhalt der einzelnachweise nur für diesen abschnitt anzeigt? meiner erfahrung nach vertippt man sich grade bei einzelnen abschnitten relativ oft bei den einzelnachweise und merkt das erst danach, weil man sie eben nur dann mit der vorschau sieht, wenn man den gesamten artikel auf einmal bearbeitet. grüße, --itsnotuitsme (bewerten? | verbessern?) 21:21, 20. Jun. 2010 (CEST)

Füge folgenden Text in deine monobook.js bzw. vector.js ein:

// [[Benutzer:ParaDox/monobook/VirtualReferences.js]]
document.write('<SCRIPT SRC="http://de.wikipedia.org/w/index.php?title='
    + 'Benutzer:ParaDox/monobook/VirtualReferences.js'   
    + '&action=raw&ctype=text/javascript&dontcountme=s"><\/SCRIPT>');

Dann werden die Refs über dem Bearbeitungsfeld angezeigt. XenonX3 - (☎:±) 21:37, 20. Jun. 2010 (CEST)

super, danke. probier ich gleich mal aus. wär das nicht auch was, was man generell umsetzen könnte? gabs dazu schon mal ne abstimmung oder wasweißich? grüße, --itsnotuitsme (bewerten? | verbessern?) 21:40, 20. Jun. 2010 (CEST)

Es wurde zumindest schon oft vorgeschlagen und daher gibts auch diese Notlösung. Es gibt sicher auch eine Bugmeldung dazu... XenonX3 - (☎:±) 21:45, 20. Jun. 2010 (CEST)

...vertippt man sich grade bei einzelnen abschnitten relativ oft bei den einzelnachweise und merkt das erst danach, ...Das ist auch mein Problem ! Wo finde ich monobook.js, vector.js und Bugmeldungen ? -michelvoss 22:00, 20. Jun. 2010

einstellungen --> aussehen --> dort stehen dann die links. grüße, --itsnotuitsme (bewerten? | verbessern?) 22:13, 20. Jun. 2010 (CEST)

... und die Bugmeldungen gibt's bei bugzilla:, siehe auch Hilfe:Bugzilla Gruß --Schniggendiller Diskussion 18:19, 30. Jun. 2010 (CEST)

Skin, Benutzer:michelvoss/monobook.js, Benutzer:michelvoss/vector.js --Flominator 09:17, 2. Jul. 2010 (CEST)

Bei mir kommt folgende Fehlermeldung: "VirtualReferences.js konnte nicht initialisiert werden!" Kann das am Browser liegen? Verwende (auf diesem Rechner) eine ältere Version des IE. Liebe Grüße, Powerboy1110 Sprich zu mir! ^+/- 14:34, 7. Jul. 2010 (CEST)

Ja, das liegt am Browser. Wenn du auf den Vorschau-Button klickst, wird schnell noch ein gekennzeichnetes <references />-Tag eingefügt, um esparsen zu lassen. Damit das Skript merkt, wann du auf den Button klickst, wird ein sog. Handler zum Button hinzugefügt, und das funktioniert im IE nicht so wie es offiziell in JavaScript vorgesehen ist (und wird deshalb meist nicht berücksichtigt). In anderen Browsern funktioniert :-) -- ✓ ^Bergi 16:16, 7. Jul. 2010 (CEST)

Aktuelle Themen

Angesichts des Edit-Wars und der ausufernden Diskussion nebst mehrmaliger Löschdiskussion auf Uwu Lena möchte ich anregen, gelockerte WP-Regeln für die Behandlung aktueller Themen zu diskutieren und zu erstellen. Man kann hier nicht dieselben Kriterien anlegen wie für ein z.B. historisches oder wissenschaftliches Lemma, weil sich ein solcher Artikel zeitbedingt noch in einem Entstehungsprozeß befindet. Ich rege hiermit z.B. an, auch direkte Quellen wie private Websites oder Blogs zuzulassen - unter entsprechenden Voraussetzungen natürlich - die dann oft schneller und zuverlässiger als die traditionellen Massenmedien berichten.

Möglich wäre z.B. ein Textbaustein mit einem Kommentar wie: Dieser Artikel behandelt ein aktuelles Thema und ist daher noch im redaktionellen Entstehungsprozeß. Nach Übergang in ein dauerhaft relevantes Lemma hilf bitte mit, ihn den dafür gültigen Kriterien anzupassen.

Der genannte Beitrag zeigt auf, wie Wikipedia sonst zum Hypeverstärker und "Nachbeter" von mangels Information irreführenden und massenhaft verbreiteten Medienberichten degenerieren kann - ob ein solcher Hype nun zufällig entstanden ist oder gezielt herbeigeführt wurde. In der Diskussion wurde z.B. angeführt, der WP seien diesbezüglich "die Hände gebunden". Das sollte doch wohl nicht sein. --HvA 08:50, 23. Jun. 2010 (CEST)

Die Leute sind dumm und ignorieren alle Bapperl. Auch haben wir genügend Zeit fürs warten bis die Massenmedien darüber berichten. Da gabs schon viele Diskussionen. --Search-url-decoder (14:59, 26. Jun. 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Dann sollte man sich diese Zeit auch lassen. Das wurde in den vorausgehenden Löschdiskussionen aber abgelehnt unter Hinweis auf das rasend schnell und möglicherweise künstlich erzeugte (?) Medienecho. Als Hypeverstärker in aktuellem Kontext sollte sich WP zu schade sein, und "Paragraphenreiter" fördern diese Tendenz lediglich. Dann wäre es besser, ein Admin würde eingreifen und das Thema vorläufig grundsätzlich sperren. Oder es finden sich eben angemessene Regeln, wie mit einem solchen Thema umzugehen ist und sich gleichzeitig Neutralität wahren läßt. So wie im vorliegenden Fall geschehen ist es jedenfalls wahrhaft ein Unding. Das macht die WP nur zum fallweise hilflosen Spielball kommerzieller Interessen und leicht manipulierbaren Pseudo-Informationsquelle für die Mainstrem-Medien, welche die Pseudo-Information dann wieder replizieren - ob das den WP-Protagonisten des jeweiligen Lemmas und insbesondere den unermüdlichen Bleistiftspitzern darunter nun klar ist oder nicht. Argumente wie "uns sind die Hände gebunden" sollte es jedenfalls nicht geben. Das entwertet die WP. --HvA 22:52, 30. Jun. 2010 (CEST)

URLs von Google-Suche

Hallo zusammen,

aus lauter langeweile habe ich ein kleines Programm geschrieben, das evtl. für den ein oder anderen nützlich ist. In der Google-Suche lassen sich pdf-Links nicht immer direkt auflösen (z.B. Firefox) und bleiben chiffriert. Abhilfe schafft ein kleines JavaScript -> hier. Vielleicht ist es ja für den ein oder anderen nützlich --Search-url-decoder 14:59, 26. Jun. 2010 (CEST)

Platzierung der Captchas

Gibt man als IP eine umfangreichere Änderung ein, die auch einen Weblink enthält, bekommt man das Captcha erst nach dem Hinweis, das noch eine Sichtung aussteht und einem Diff zur gesichteten Version angezeigt. Dadurch kommt es immer wieder vor, daß das Captcha erst nach längerem Scrollen zu sehen ist. Es entsteht so immer der Eindruck, dass die Änderung bereits gespeichert ist und nur noch gesichtet werden muss. Hierdurch werde ich oft verleitet den Tab zu schließen, ohne das Captcha eingegeben zu haben und darf - wenn ich es denn überhaupt bemerke - später alle Änderungen noch einmal vornehmen. Das Captcha sollte daher unbedingt oberhalb des Diffs angezeigt werden. --82.113.121.107 22:17, 26. Jun. 2010 (CEST)

Das ist nachvollziehbar, daher Bug 24291 --Der Umherirrende 20:18, 6. Jul. 2010 (CEST)

Hinweis auf noch zu sichtende Versionen

Wie im vorigen Beitrag schon ersichtlich, scheint es mir, das bei der Zwangssichtung mittlerweile etwas übertrieben wird. Habe mich versionsweise durch verschiedene, noch nicht gesichtete Änderungen geklickt, nicht selbst gesichtet, aber bei der letzten Version einige Änderungen eingefügt. Bei der anschließenden Voransicht (ohne vorherige Diff-Ansicht) wurde oben ein neues Feld eingeblendet, das auf noch ungesichtete Versionen hinwies. Beim Anklicken waren natürlich alle zehn bis zwölf vorher schon vorhandenen Änderungen eingeflossen und der ganze Text somit rot, was ich geändert hatte, was so nicht mehr erkenntlich. Bin also im Browser einen Schritt rückwärts marschiert und habe dann die Änderungsansicht gewählt, die normalerweise dann die Änderungen zur letzten gespeicherten Version zeigen sollte. Die zeigte dann keine Änderungen mehr an, alles für die Katz, nochmal von vorn. Für mich keine Verbesserung, Effekt heute erstmals bemerkt. --Pflastertreter 08:14, 27. Jun. 2010 (CEST)

Das müsstest du abschalten können in deinen persönlichen Einstellungen unter "Bearbeiten". Bei "Zeige beim Bearbeiten auch den Unterschied zur letzten stabilen Version im Versionsvergleich" musst du den Haken entfernen. -- Chaddy · D·B - DÜP 23:27, 28. Jun. 2010 (CEST)

Mag sein und will ich auch gar nicht bestreiten, vielen Dank für den Hinweis. Mir geht's aber hier eigentlich weniger um die persönliche Hilfestellung, sondern ich vermute einfach mal ganz dreist, das diese (neue?) Funktion auch bei anderen destruktive Aktivitäten verursachen könnte und daher vielleicht etwas weniger progressiv eingesetzt werden sollte. I.E. nämlich nur dann, wenn Benutzer das ausdrücklich angehakt hat (und also wissen könnte, was er an der Stelle tut) und nicht einfach so default für alle. Ein Hilfelink zu den jeweiligen Optionen wäre an der Stelle vllt. auch nützlich. --Pflastertreter 02:43, 29. Jun. 2010 (CEST)

Vorlagenänderungen in Artikelversionsgeschichte zu loggen

Ist es denkbar, für Vorlagenänderungen einen Eintrag in der Versionsgeschichte der Artikel mit der etsprechenden Änderung zu erzeugen, bzw. gäbe es andere Möglichkeiten, die Änderungen von Vorlagen mit Änderungskommentar in Artikeln mit der betreffenden Vorlage zu loggen. --Septembermorgen 23:11, 28. Jun. 2010 (CEST)

Nummerierungen in Tabellen

Hallo. Ich möchte mich bereits im Voraus entschuldigen, wenn dies bereits diskutiert wurde.
Da ich bei meiner Arbeit hier besonders viel mit Tabellen zu tun habe, wäre es "wünschenswert" wenn man in Ranglisten, wie zB hier automatisch nummerieren könnte. Gibt es technisch hierfür eine Möglichkeit? Beste Grüße, Jerchel 19:05, 1. Jul. 2010 (CEST)

Alles was zu Tabellen bereits möglich ist, ist (oder sollte) unter Hilfe:Tabellen zu finden (sein).

--Konrad – 09:10, 2. Jul. 2010 (CEST)

Tabellenbefehle

Ich wünsche mir die Möglichkeit, Layout-Befehle (zum Beispiel align="center") für eine gesamte Tabellenspalte auf einmal setzen zu können, damit der Befehl nicht mehr einzeln bei jedem Feld eingegeben werden muss. -- Memorino ^(D) _{Lust mitzuhelfen?} 22:01, 2. Jul. 2010 (CEST)

Und das ganze dann bitte auch gleich (entsprechend z.B. nach Ausrichtung=zentriert oder noch besser – so wie bei den Bildern – einfach nach zentriert) lokalisieren übersetzen.

--Konrad – 11:10, 3. Jul. 2010 (CEST)

HTML kann das mit <colgroup /> und <col />. Leider kennt Mediawiki diese Tags nicht. Allerdings funktionieren Ausrichtungen per CSS in den meisten Browsern nicht, nur die häßliche HTML-Syntax align="". Die andere Möglichkeit wäre der CSS-Selektor :nth-child, der aber nicht direkt im style-Attribut einbindbar ist. Und viele viele Klassen für table.spalte1-grün, table.spalte5-rechts etc. können wir uns kaum leisten. Das müsste also wie die Syntax-Highlighter-CSS dynamisch von MW erzeugt werden.
meint -- ✓ ^Bergi 15:07, 3. Jul. 2010 (CEST)

Automatischer Sichter als verleihbare Benutzergruppe

Moin, ich wäre dafür, den automatischen Sichter zu einer durch Admins vergebbaren Benutzergruppe zu machen. Es gibt viele Benutzer, die keinen Unsinn machen und deren Edits ruhig gesichtet werden können. Aber sie haben keine Ahnung von Vandalismus und sollten daher nicht aktiv sichten können. Daher wäre es praktisch, wenn man sie zu Automatischen Sichtern machen könnte, aber so, dass sie nicht automatisch Sichter werden, da dass ja nicht sein soll. Für diese Änderung brauchts wahrscheinlich einen Bug-Report, mag den jemand aufmachen? Grüße, XenonX3 - (☎:±) 09:14, 5. Jul. 2010 (CEST)

Inwiefern muss man "Ahnung" von Vandalismus haben? Den Vandalismus, den die Sichtungen verhindern sollen, sollte eigentlich jeder erkennen können, der hier mitschreibt. Zur Bekämpfung des subtileren Vandalismus, der darin besteht, plausibel klingende Falschangaben in Artikeln unterzubringen ist die Sichtung ungeeignet. -- Perrak (Disk) 11:30, 5. Jul. 2010 (CEST)

Ich habe schon Benutzer gesehen, die einfach alles gesichtet haben, was ihnen vor die Füße kam. Dementsprechend schnell waren die Rechte wieder weg. Die eigenen Edits waren aber ok. XenonX3 - (☎:±) 11:37, 5. Jul. 2010 (CEST)

@Perrak: wir brauchen hier jetzt keine Grundsatzdiskussion zu GSV. Es hat nur im Moment die Absurdität Bestand, dass eine Statistische Auswertung der Edits anhand ziemlich blöder Parameter darüber entscheiden darf, ob jemand zum Auto-Sichter wird, gleiches aber nicht durch administrativen Menschenverstand geleistet werden darf. Jener administrative Menschenverstand darf allerdings über das sehr viel weiterreichendere Sichterrecht entscheiden was das Auto-Sichterrecht inkludiert. Viele Grüße --Saibo (Δ) 23:50, 5. Jul. 2010 (CEST)

Ich habe ja gar nichts dagegen, dass wir Benutzern das Auto-Sichter-Recht auch per Hand geben können. Mir leuchtet nur die Begründung nicht ein. Wenn ich jemand für vertrauenswürdig genug halte, kann ich ihm ja schon das Sichterrecht geben. Wenn ich Bedenken hätte, ob er das aktiv bewusst genug nutzt, wäre eine passende Ansprache auf der Diskussionsseite möglich. Insofern: Von mir aus gern, aber der Nutzen ist aus meiner Sicht nicht sehr groß. -- Perrak (Disk) 08:41, 6. Jul. 2010 (CEST)

Sichterzähler

Anzahl der Benutzer mit dem Status „Sichter“ unter der Vorlage {{SICHERANZAHL}}. Weil immerhin gibt es ja auch {{BENUTZERANZAHL}} und {{ADMINANZAHL}} -- Bigbossfrin 18:28, 6. Jul. 2010 (CEST)

{{NUMBERINGROUP:editor}}: 22.540. Siehe Hilfe:Variablen Merlissimo 18:38, 6. Jul. 2010 (CEST)

Dangge --Bigbossfrin 21:06, 6. Jul. 2010 (CEST)

Zentrierte Darstellung von Galerien

In der französ. Wiki habe ich festgestellt, dss die Galerien automatisch zentriert dargestellt werden. Finde ich gut. Gibt es dazu schon einen Parameter oder müsste das erst programmiert werden? --Claus Diskussionsseite 09:42, 7. Jul. 2010 (CEST)

Galerien können folgendermaßen zentriert werden:

<gallery class="centered">
Datei:Rotkehlchen gr.jpg|Rotkehlchen
</gallery>

führt zu:

• 
  Rotkehlchen

Eine automatische Zentrierung kann zu Problemen führen und finde ich auch nicht überall geeignet. --Fomafix 09:49, 7. Jul. 2010 (CEST)

Danke für den Tipp! Bitte: Wo kann die Zentrierung zu Proplemen führen? Bitte Beispiel! --Claus Diskussionsseite 10:22, 8. Jul. 2010 (CEST)

In folgender Situation, die durchaus auch vorkommt, sind die beiden Boxen nicht übereinander: --Fomafix 13:10, 8. Jul. 2010 (CEST)

Infobox

• 
  Rotkehlchen

• 
  Rotkehlchen

Funktions- bzw "Meta"-Seiten sowie angemeldete Benutzer besser schützen

Da mir kein besserer Ort eingefallen ist, einfach mal hier ein kleines quo vadis zum Thema Sockenplage und Funktionsseiten. Ich frage mich, wie man dem Herr werden kann, und dass es so nicht weitergehen kann, dürfte auch klar sein. Generell frage ich mich, was überhaupt der Nutzen ist, wenn man IPs und Socken auf solchen Seiten zulässt. Es handelt sich in gefühlten 99% der Fälle um Sperrumgeher oder Ausgeloggte, die dem Projekt entweder mutwillig schaden oder durch ihre doppelte Anonymität für Verwirrung und Misstrauen sorgen. Hier ein paar Anregungen, die nicht als ausgefeilte Regeländerungsvorschläge betrachtet werden wollen:

• Es würde Sinn machen, Halbsperren für Funktionsseiten häufiger zu verhängen und teilweise vielleicht sogar dauerhaft
• Der Zeitraum für Neusocken, der überschritten werden muss, um eine Halbsperre zu umgehen, könnte deutlich angehoben werden
• KALP-Abstimmungen sollten, wenn man das Verfahren schon nicht grundsätzlich reformiert, wenigstens den angemeldeten und etablierten Autoren überlassen werden, und nicht irgendwelchen Dahergelaufenen, Mehrheits-Konstruktions-IPs und Feiglingen, die die Arbeit anderer ausgeloggt runtermachen. Dauerhalbsperre wäre denkbar, und/oder eine Ausweitung der Stimmberechtigungsregelung auf diesen Bereich.
• Auch in Löschdiskussionen sollten Kommentare von IPs und Neusocken, die den Artikel nicht verfasst haben, häufiger entfernt werden
• Die größten Probleme herrschen auf VM, SP und CU. VM-Anträge von Neusocken und IPs, die ohne Vorgeschichte auf diesen Seiten aufschlagen, sollten konsequenter als bisher kommentarlos und standardmäßig entfernt werden, ebenso Kommentare. Auf SP sollten nur bestätigte Sperrprüfsocken zugelassen werden. Auch hier sollte gelten: IPs, die nicht erkennbar an Konflikten im ANR oder auf Diskussionsseiten beteiligt waren, sollten kein Rederecht erhalten. Hier gilt es meines Erachtens, den angemeldeten Benutzer als etablierten Teilnehmer und Mitarbeiter unserer Enzyklopädie bewusst zu bevorteilen. Wenn die IP ausnahmsweise mal kein Ausgeloggter ist, sollte sie das verstehen und motiviert werden, sich anzumelden und sich das Recht auf Mitgestaltung im Metabereich zu erarbeiten.
• Die Sockenduldung - allgemein, und insbesondere die Duldung von Sperrumgehern - grundsätzlich überdenken.
• Last but not least sollte hier auf WP generell eine größere Wertschätzung für Mitarbeiter entwickelt werden, die mit einem einzigen Account editieren, denn das ist letztlich die Grundlage für ein konstruktives und vertrauensvolles Zusammenarbeiten. Sockenpupperei und Ausloggerei sind hingegen in aller Regel projektschädlich, siehe auch hier.

Freue mich auf sachliche Meinungen und ggf. weitere Vorschläge und Anregungen.--bennsenson - ceterum censeo 11:39, 9. Jul. 2010 (CEST)

Theoretisch nichts dagegen, praktisch umsetzbar wird das aber nicht alles sein. Insbesondere die Erkennung von Socken bedeutet einen erheblich größeren Arbeitsaufwand. Und auch die Anregung, unbeteiligte IPs auszuschließen, ist zwar sinnvoll, aber aufgrund dynamischer IPs unmöglich. Was genau meinst du eigentlcih mit „Funktions- und Meta-Seiten“? Die enzyklopädische Arbeit wird schließlich auch von IPs mitgetragen, alle nicht-ANR-Seiten zu sperren wäre Schwachsinn.
meint -- ✓ ^Bergi 14:37, 9. Jul. 2010 (CEST)

Probleme mit Vector

Verschoben nach: Wikipedia:Usability-Initiative/Softwarefehler#Probleme_beim_Editieren_unter_Vector – hier somit erledigt. --Carbenium 17:35, 13. Jul. 2010 (CEST)

Ich halte diesen Vorschlag für abgearbeitet. Wenn du anderer Meinung bist, kannst du diesen Baustein wieder entfernen. Sonst wird der Abschnitt in fünf Tagen ins Archiv verschoben. --Carbenium 17:35, 13. Jul. 2010 (CEST)

Suche in der Suche in der Suche ....

Es wäre ein großer Segen und gelegentlich eine riesige Arbeitserleichterung, wenn man nach einer Volltextsuche eine weitere Suche innerhalb der gefundenen Artikel starten könnte (und das auch mehrfach). Gruß -- Dr.cueppers - Disk. 18:34, 10. Jul. 2010 (CEST)

Wie genau meinst´n das? Bzw.: Inwiefern soll es die Browser-Suchfunktion (Strg + F) erweitern? --Hæggis ☎→♜ 21:03, 12. Jul. 2010 (CEST)

Na wie wohl? Wenn ich irgendwas suche und erhalte eine Liste von 55 Artikeln, dann müsste ich die alle einzeln anklicken, um sie per strg+f zu durchsuchen. Da wäre es tatsächlich ein große Erleichterung, wenn man innerhalb dieser Treffer nochmal nach anderen Stichwörtern suchen könnte. Finde ich einen guten Vorschlag. Gibts in Bugzilla bestimmt schon, oder? --91.64.58.117 15:13, 13. Jul. 2010 (CEST)

Ich habe z. B. per Volltextsuche nach "Buchenwald" gesucht, das gibt 2178 Treffer. Die musste ich in stundenlanger Arbeit alle einzeln betrachten, um diejenigen herauszufinden, die sich mit dem "Speziallager" befassen, wobei auch das Wort Speziallager im Text nicht unbedingt vorkommt oder nicht in den zwei Zeilen der gefundenen Artikel (es genügt also im jetzigen Suchverfahren auch nicht, die Begriffe "Buchenwald" und "Speziallager" einzugeben - mit dieser Methode habe ich nur ca. 60 % der gesuchten Artikel gefunden, weil sehr häufig das Wort "Speziallager" zwar enthalten war, aber innerhalb eines WP-Links "im vorderen Teil" versteckt ist, d. h. vor dem senkrechten Strich - da findet es die jetzige Suchfunktion offenbar nicht!).

Die meisten dieser gelisteten Artikel behandeln das KZ oder den "biologischen" Buchenwald. Hier wäre es über meinen obigen Vorschlag hinausgehend sogar nützlich, wenn man diese ursprüngliche Liste per "Negativ-Eingabe" dezimieren könnte; dafür hätte ich eingeben können "-KZ" und "-Konzentrationslager" und weniger als ein Viertel wäre übrig geblieben.

Die vorgenannte Arbeit habe ich übrigens - mit ähnlichen Mengen in der Liste - auch mit "Jamlitz", "Hohenschönhausen", "Sachsenhausen", "Bautzen", "Fünfeichen", "Mühlberg", "Torgau" und "Weesow" hinter mir, eine tagelange Sucherei (Ergebnis: Siehe Speziallager#Bekannte Insassen mit 85 Gefundenen, die nun nach und nach auch in die dafür organisierte Kategorie:Speziallagerhäftlingkommen).

Noch ein paar Anregungen:

Die Suchliste ist jetzt unsortiert, auch ein Knopfdruck zum Sortieren wäre nützlich, dann kann man beim Betrachten der Liste ganze Strecken übergehen, weil schon der Wortanfang besagt, dass sie nicht in Frage kommen. Ich habe z. B. (nur) nach Personen gesucht, da wären immer alle zum selben Vornamen beisammen.

Ein Kästchen pro Eintrag zum Ankreuzen: "Raus damit" - und beim nächsten Durchlauf sind sie weg.

Gruß -- Dr.cueppers - Disk. 10:31, 14. Jul. 2010 (CEST)

Merkwürdiger Effekt bei der "Suche"

Wenn man "Jaml" eingibt (um nach "Jamlitz" zu suchen),

erscheinen - je nach Lust und Laune des Programmes -

- entweder

Jamlitz

Jamlitz-Klein Düben (obwohl das Jämlitz ist)

Jamlitz (obwohl das Jämlitz ist)

usw.

- oder

Jämlitz (obwohl das Jamlitz ist)

Jämlitz-Klein Düben

Jämlitz

Im fettgedruckten Wortteil wird also entweder alles mit "a" oder alles mit "ä" dargestellt.

Gruß -- Dr.cueppers - Disk. 12:06, 11. Jul. 2010 (CEST)

Ich würde sagen, das ist ein Fehler mit dem Vector-Skin (bzw. mit den nur dort verfügbaren Suchvorschlägen). Am besten ist es wohl unter Wikipedia:Usability-Initiative/Softwarefehler#seltsame Vorschläge der Suchbox in Verbindung mit Leerzeichen aufgehoben. Der Umherirrende 16:15, 11. Jul. 2010 (CEST)

Neue Warnmeldung beim Verlassen der Bearbeitung

Die ist echt nervig! Früher konnte man sich darauf verlassen, dass nichts verloren ging, sobald man die "Vorschau" aufgerufen hatte. Ist das nicht mehr so? Wenn nein, sollte man diese Version wieder herstellen und nur dann eine Aufforderung zu "Vorschau" mit entsprechender Warnmeldung bringen, wenn noch keine "Vorschau" erfolgt ist. Ganz besonders nervig ist die neue Warnmeldung, wenn man nach getaner Arbeit (und nach Abspeichern!) den Weg wieder stufenweise zurückgeht (mit dem Pfeil ganz oben links); dann kommt man drei oder viermal auf einen älteren Bearbeitungszustand und wird jedesmal erneut gefragt - das ist reif für den Papierkorb! Gruß -- Dr.cueppers - Disk. 15:25, 11. Jul. 2010 (CEST)

- - > Einstellungen - - > Bearbeiten - - > Warnen, wenn eine zur Bearbeitung geöffnete Seite verlassen wird, die nicht gespeicherte Änderungen enthält deaktivieren -jkb- 15:29, 11. Jul. 2010 (CEST)

Dabei steht der Hinweis, wie man es wieder deaktivieren kann, sogar in der Hinweismeldung drin. Der Umherirrende 16:12, 11. Jul. 2010 (CEST)

diesen Hinweis konnte ich ja leider nicht geben, da ich es längst ausgeschaltet habe :-) -jkb- 16:19, 11. Jul. 2010 (CEST)

Ich halte diesen Vorschlag für abgearbeitet. Wenn du anderer Meinung bist, kannst du diesen Baustein wieder entfernen. Sonst wird der Abschnitt in fünf Tagen ins Archiv verschoben. Der Umherirrende 16:12, 11. Jul. 2010 (CEST)

Jups, war schonmal Thema. Falls innerhalb der nächsten 2 Tage ein gewählter Sperrumgeher mitliest: Wenn der Hinweis auf MediaWiki:Vector-editwarning-warning um […] „Bearbeiten-Bereich“ der Einstellungen unter „Warnen, wenn eine zur Bearbeitung geöffnete Seite verlassen wird, die nicht gespeicherte Änderungen enthält“ abgeschaltet werden. ergänzt wird, wäre die zusätzliche Länge m.E. mit der zielführenderen Info gerechtfertigt. --Hæggis ☎→♜ 20:59, 12. Jul. 2010 (CEST)

Veraltete Version einer Seite

Mir fehlt eine Funktion, die es ermöglicht veraltete Versionen einer Seite mit der entsprechend veralteten Version der Vorlagen anzuschauen. Kann man da was machen?
gruß BigbossFrin 15:51, 13. Jul. 2010 (CEST)

Als Behelfslösung hätte ich das Webarchiv anzubieten, z. B. http://web.archive.org/web/20090723041904/de.wikipedia.org/wiki/Wikipedia:Hauptseite. --Schnark 09:16, 14. Jul. 2010 (CEST)

Neue Funktion: Übersetzung

In vielen Artikeln werden standarmäßig englische Ausdrücke gebraucht, bspw. bei techniklastigen Artikeln (Luftfahrt, Waffen usw.). Leider werden, wenn deutsche Übersetzungen danebengestellt werden, diese nur sehr ungern aktzepiert (mein Eindruck) und oft ist es schwierig diese in den Text einzubauen.

Mein Vorschlag wäre, eine neue Funktion, zu schaffen, die gleich wie die <ref> funktionieren würde. D. h. neben dem nicht deutschsprachigen Worten wird ein „tag“ gesetzt, der beim draufklicken auf eine am Ende des Artikels stehende deutsche Übesetzung verweist. (Ebenso wie das bei den Ref tags der Fall ist.)

Beispielartikel: BAE Taranis. Hier ist von z. B. „UCAV“ und „Strategic Unmanned Air Vehicle (Experimental) (SUAV[E])“ die Rede, leider fehlt dazu eine deutsche Übersetzung. Leider (m.E.) wird das oft gern in Kauf genommen.

Was meint die „community“ dazu? --Juhuu! 11:11, 14. Jul. 2010 (CEST)

Das Problem ist, dass viele derartige Bezeichnungen Fachausdrücke gibt, für die es keine äquivalente deutsche Bezeichnungen gibt. Übersetzungen widersprechen damit häufig WP:KTF. Wenn es eine gibt, kann die auch gut in Klammern hinter den en-Fachausdruck gesetzt werden oder direkt genommen werden. Ein ref-artiges Tag ist unnötig. Viele Grüße --Orci Disk 11:28, 14. Jul. 2010 (CEST)