Wikipedia:Verbesserungsvorschläge

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Abkürzung: WP:VV
Autorenportal < 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.

Zeichen 123.svg
Es gibt immer was zu tun …

… 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.

Oft Gefragtes (FAQ)[Quelltext bearbeiten]

  • Besucherzähler/Statistiken je Artikel: Der in MediaWiki vorhandene Zähler ist wegen zu hoher Serverbelastung ausgeschaltet. In der seitlichen Werkzeuge-Box erreicht man über den Link Seiteninformationen ganz unten oder am Ende jeder Seite unter dem Link "Abrufstatistik" dieses externe Tool, mit dem Zugriffszahlen für jeden Artikel ermittelt werden können.
  • Rechtschreibprüfung: Ist meist als Funktion im Webbrowser sowie 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 in den Einstellungen des Webbrowsers oder benutzerspezifisch auf besser unterscheidbare Farben umstellen, siehe WP:CSS und Benutzer:Wolfgangbeyer/monobook.css. Weiterhin existiert ein Helferlein für Benutzer mit Rot-Grün-Sehschwäche, siehe Wikipedia:BIENE/Farbenfehlsichtigkeit.
  • Artikel bewerten: Unter dem Namen Artikel-Feedback wurde ein Bewertungssystem aktiv getestet, jedoch wieder verworfen.
  • Weiterleitungen 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 deshalb in Artikeln ausgeschlossen. Siehe auch WP:JS.
  • Externe Links prinzipiell in einem separaten Fenster öffnen: Wird es nicht geben, da von vielen Benutzern als bevormundend empfunden. Wo ein Link geöffnet wird, kann üblicherweise durch die Art des Anklickens entschieden werden.
  • Mindestgröße für neue Artikel: Umstritten, siehe Wikipedia:Wie schreibe ich gute Artikel.
  • Allgemeinen Zugriff auf gelöschte Artikel: Gibt es indirekt via Marjorie-Wiki und weiterer externer Projekte, siehe Wikipedia:Enzyklopädie.
  • Beim Bearbeiten anzeigen, zu welchen Begriffen Artikel existieren: Sehr aufwendig zu realisieren. Einfachere Lösung: Vorschau 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, vgl. auch das Projekt Wikidata.
  • Essays: Eventuell, und wenn, dann nur was für Wikibooks.
  • RSS-Feed: Ist verbesserungswürdig, hat aber eine niedrige 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[Quelltext bearbeiten]

Explizite Feature-Requests sollten auf der Unterseite Wikipedia:Verbesserungsvorschläge/Feature-Requests diskutiert werden. Zugehörige Bugzilla-Einträge bitte hier auflisten:

Aufruf von Artikeln mit Klammern-Schreibweise[Quelltext bearbeiten]

Bis vor wenigen Wochen brauchte man beim Aufruf von Artikeln mit Klammern-Schreibweise, wie „Fulda (Fluss)“, in das Fenster Suche nur „Fulda Fluss“ eingeben. Während man dies eingab, erschien unterhalb des Suchfensters – spätestens ab Beginn der Eingabe des Wortes Fluss – der Artikelname bzw. das Lemma in Fettdruck, weil der Fulda-Fluss seit vielen Jahren als Artikel „Fulda (Fluss)“ angelegt ist. Per dann benutzter Tastenfolge „↓“–„Eingabe“ gelangte man schnell zum gesuchten Artikel.

Nun muss man leider und umständlicherweise, um zum gleichen Ergebnis zu kommen, die Klammer(n) [ „(“ und/oder „)“ ] mit eintippen – also „Fulda (Fluss)“!

Die alte Variante ist doch schneller und sinnvoller!
--TOMM (Diskussion) 12:52, 22. Mär. 2015 (CET) und --TOMM (Diskussion) 09:11, 23. Mär. 2015 (CET) (nur plus: „“)

Muss man nicht: Mit Suchbegriff "Fulda" erscheint in der dritten Zeile "Fulda (Fluss)" - was will man mehr? Gruß -- Dr.cueppers - Disk. 22:42, 22. Mär. 2015 (CET)
Es geht NICHT um den Suchbegriff Fulda sondern um die aneinander gereihten Suchbegriffe „Fulda Fluss“. Gab man diese Begriffe (wie oben erwähnt) oder nur „Fulda F“ (also ohne luss) bis vor wenigen Wochen ein, erschien das Fließgewässer in Fett-Schrift als direkt anwählbarer/anklickbarer Artikel (also aktiver Link). Wenn man aber nun (wie oben erwähnt) „Fulda Fluss“ ohne Klammer(n) eingegeben hat, erscheinen unterhalb des Suchfensters die Begriffe „Fulda Fluss“ in nicht fetter (also inaktiver) Form.
Analog hierzu ein weiteres Beispiel:
Früher gab man „Steinberg Kaufunger Wald“ oder nur „Steinberg K“ (also ohne aufunger) ein [also beides ohne Klammer(n)], und man erhielt als aktiv anwählbaren Link den Artikel „Steinberg (Kaufunger Wald)“. Aktuell muss man (mindestens) „Steinberg (K“ [also mit Klammer(n)] eingeben, um zu diesem Bergartikel zu gelangen. Dies geschieht (aber nur), weil in der Wikipedia derzeit nur ein Steinberg mit dem Klammerlemma-Beginn „(K…“ angelegt ist!
--TOMM (Diskussion) 09:12, 23. Mär. 2015 (CET)
+1. Ja, ich halte die Suchweise, wie es vor Kurzem noch war – also, dass die Klammern von der Suchfunktion ignoriert wurden – auch für sinnvoller und benutzerfreundlicher. -- Hans Koberger 15:18, 23. Mär. 2015 (CET)
Wenn man eine Klammer eingibt, sollte sie berücksichtigt werden, wenn nicht, sollte wohl die alte Methode wieder greifen. --Diwas (Diskussion) 01:38, 24. Mär. 2015 (CET)
Jawohl, so wie Diwas es geschildert hat, war es bis vor wenigen Wochen!
Und: Beide Suchmöglichkeiten sollten wieder möglich sein!
--TOMM (Diskussion) 19:23, 25. Mär. 2015 (CET)
Was ist aus meinem Such-Vorschlag bzw. -Rücksetzungswunsch (schnelles Anwählen/Suchen ohne Klammern einzugeben) geworden?
Wird daran gearbeitet?
--TOMM (Diskussion) 19:53, 15. Jun. 2015 (CEST)
Zum 2. Mal gefragt: Wird daran gearbeitet?
--TOMM (Diskussion) 10:01, 17. Aug. 2015 (CEST), --TOMM (Diskussion) 23:40, 23. Okt. 2015 (CEST) und --TOMM (Diskussion) 13:10, 10. Feb. 2016 (CET)

Wenn das vielleicht mal umgesetzt wird, steigen auch die Chancen, dass die Begriffsklärungsseite bei den Suchvorschlägen ist. Bei der Eingabe von Amazon, wird weder ein Artikel Amazon noch die Begriffsklärungsseite zu Amazon vorgeschlagen. Die Begriffsklärungsseite findet man also nur über die Volltextsuche oder Eingabe der Klammer, wobei man ja nicht weiß, ob sie eine Klammer hat. Grüße --Diwas (Diskussion) 22:50, 30. Aug. 2015 (CEST)

Zum 3. und 4. Mal gefragt: Wird daran gearbeitet?
--TOMM (Diskussion) 23:40, 23. Okt. 2015 (CEST), --TOMM (Diskussion) 15:58, 22. Jan. 2016 (CET) und --TOMM (Diskussion) 13:10, 10. Feb. 2016 (CET)
Nach Re-Import aus Archiv:
Es macht mich traurig, und es ist für mich völlig unverständlich, dass hiesiger Abschnitt Aufruf von Artikeln mit Klammern-Schreibweise ins Archiv verschoben wird, obwohl Antworten seit sehr langer Zeit noch ausstehen und ich 4mal nachfragte!
Daher:
Zum 5. Mal gefragt: Wird daran gearbeitet?
--TOMM (Diskussion) 13:10, 10. Feb. 2016 (CET)
Statt immer wieder zu fragen, kannst du auch den phabricator-Task anschauen: Offenbar nicht. Du kannst selbst daran arbeiten, wenn du möchtest. --mfb (Diskussion) 15:22, 10. Feb. 2016 (CET)
Ich habe mich mit derartigen Tasks noch nicht beschäftigt und daher keine Ahnung wie das geht.
Daher hoffe ich auf die Hilfe anderer Benutzer, und ich würde mich über die Umsetzung freuen!
--TOMM (Diskussion) 15:56, 10. Feb. 2016 (CET) und --TOMM (Diskussion) 09:25, 11. Feb. 2016 (CET)

@TOMM: Anscheinend ist das Problem jetzt behoben. Selbst bei fuldaf erscheint Fulda (Fluss) jetzt als erster Eintrag. Und bei Fulda ( erscheinen alle sieben Klammer-Fuldas. Amazon zeigt Amazon.com und Amazonas. Amazon- zeigt unter anderem Amazon Kindle und Amazon-Klasse (1971) aber nicht Amazonas. --Diwas (Diskussion) 11:10, 9. Apr. 2016 (CEST)

Nein, :-(
leider ist es immer noch nicht behoben;
denn es funktioniert nach wie vor nicht so wie es jahrelang zuvor war!
Anmerkung: Anfang/Mitte dieser Woche (KW 14) lief es kurzzeitig!
Für detaillierte Problem-Schilderung dazu siehe meine obigen 2 Beiträge:
– Diskussionsabschnitts-Einleitung
   vom 22. (und 23.) März 2015 (von „Bis vor wenigen Wochen“ … bis … „schneller und sinnvoller!“)
– Ergänzung dazu
   vom 23. März 2015 (von „Es geht NICHT um“ … bis … „angelegt ist!“)
--TOMM (Diskussion) 17:14, 9. Apr. 2016 (CEST)
Geht es dir, TOMM, um den Fettdruck? Reicht es nicht, dass man, wie jetzt, durch Eingabe von „fuldaf“–„↓“–„Eingabe“ den Artikel Fulda (Fluss) direkt aufrufen kann? --Diwas (Diskussion) 19:24, 9. Apr. 2016 (CEST)
Hallo Diwas,
lies Dir oben mal insbesondere mein weiteres Beispiel in meiner letzten Nachricht vom vom 23. März 2015 durch.
Füher wurde nach Eingabe von Steinberg K (also ohne beide Klammern und aufunger …) der Steinberg (Kaufunger Wald) in fett-Schrift angezeigt, so dass dieser optisch hervor stach!
So hätte es wieder werden sollen – wie einst auch Fulda (Fluss) nach Eingabe von „Fulda F“!
Aber: Weil nun noch mehr geändert wurde, wie Du in Deiner ersten Nachricht vom 9. April 2016 erwähnt hast, ist das wahrscheinlich nicht mehr möglich sowie vielleicht auch nicht mehr nötig und sinnvoll. ?!?
Ich werde in den nächsten Tagen mal ein Auge drauf werfen und ausprobieren, wie die neu gestaltete Suche funktioniert.
Übrigens:
Es fehlt noch eine Such-Ergänzung zur Begriffsklärungs-Auffindung. Doch dazu bitte NICHT hier sondern im Diskussionsabschnitt…
    Bei der Suche die Begriffserklärung immer gleichrangig anbieten
…weiter diskutieren!
--TOMM (Diskussion) 13:14, 10. Apr. 2016 (CEST) und --TOMM (Diskussion) 13:21, 10. Apr. 2016 (CEST)

Schriftgröße der Wikipedia-Artikel[Quelltext bearbeiten]

Hallo!

Ich stelle schon seit längerer Zeit fest, dass die Schriftgröße von neueren Wikipedia-Artikeln extrem klein ist.

Vermutlich gibt es technische Möglichkeiten, die Schriftgröße zu verändern. Aber genau die Leute, die - wie ich auch - in ihrem Sehvermögen eingeschränkt sind, sind auch ungefähr die letzten, die nach solchen Möglichkeiten suchen - erst recht, wenn sie ausschließlich*) für Wikipedia gebraucht werden.

  • ) absolut keine der sonst von mir m.o.w. regelmäßig aufgesuchten Websites gibt sich so wenig Mühe, für Sehbehinderte lesbar zu sein.

Angesichts des nicht eben kleinen (und kraft steigender Lebenserwartung zunehmenden ...) Bevölkerungsanteils mit Seheinschränkungen erscheint diese Praxis mit dem Anspruch von Wikipedia unvereinbar, ALLEN Menschen den Wissenszugang zu ermöglichen.

Es wird hoffentlich Besserung gelobt.

Mit freundlichen Grüßen,

BB (nicht signierter Beitrag von 91.51.73.6 (Diskussion) 22:47, 14. Dez. 2015 (CET))

Hallo! Die Schriftgröße ist in allen Artikeln gleich, egal wie alt sie sind. Sie ist auch seit Jahren mehr oder weniger unverändert. In meinem Browser (Firefox) kann man die Schriftgröße einer Webseite einfach per Strg+Plustaste verändern. Zudem lässt sich natürlich im Browser auch die Standardanzeigegröße im Browser definieren. Das halte ich ehrlich gesagt für keinen großen technischen Aufwand. Ich bin mir dagegen ziemlich sicher, dass es die Mehrzahl der Leser und vor allem auch der Autoren einigermaßen nerven würde, würden wir die Schriftgröße standardmäßig hinaufsetzen. Das ist allerdings nur meine persönliche Meinung dazu. Grüße, j.budissin+/- 23:10, 14. Dez. 2015 (CET)
Ich habe den Eindruck, dass das in der russischen Wikipedia z.B. der Fall ist, und ja, ich finde das alles andere als schön :-/ --Nix schlecht (Diskussion) 23:24, 2. Feb. 2016 (CET)
Wo ich das tatsächlich als Problem sehe, sind mobile Geräte wie Tablets und Handys. Auf meinem iPad gibt es z.B. nicht (weder in Safari noch in Chrome) die Möglichkeit, von vornherein Schriftgrößen zu ändern, wie es bei Desktop-Browsern Standard ist. Und der normale Zoom ändert auch die Größen von Bildern und anderen grafischen Elementen; und zerschießt damit das Layout und macht viele Artikel fast unbenutzbar. iOS bietet zwar eine Option, Schriftgrößen systemweit zu ändern, aber das funktioniert nicht wirklich (obwohl Apple gerne die Barrierefreiheit bewirbt) und ist in anderen Apps (mit eh größerer Schrift) oft negativ. Das Problem ist also durchaus vorhanden. Ich sehe zwar eigentlich bei diesem Problem eher die Hersteller der Betriebssysteme und Browser in der Pflicht und eine generelle Vergrößerung würden viele lästig finden, aber vielleicht hat ja jemand eine Idee, wie man das auch anders lösen kann...--137.226.116.99 13:38, 4. Feb. 2016 (CET)
Hallo, ich habe möglicherweise eine solche, für alle akzeptable Idee. Die Schriftgröße könnte in Abhängigkeit einer Benutzer-Variablen (für angemeldete Benutzer) und/oder einer extra Variablen in der URI (für IPs) modifiziert werden. Dazu könnte der Wert der Variablen das Delta der Schriftgröße in der Form '+'|'-'<<Ziffer>> (wie z.B. '+2') speichern. Die Einstellung dieser Variablen könnte für die angemeldeten Benutzer in die vorhandenen 'Einstellungen' des Benutzers integriert werden und/oder für die IPs sowohl via Anzeige-Menü in den mobilen Versionen selektierbar sein, als auch in der Startseiten-URI für die Wikipedia-Benutzung (App, etc.) als Startwertvorgabe mitgespeichert sein. Vermutlich bedeutet diese Lösung allerdings doch einen erheblichen Entwicklungsaufwand in der MediaWiki-Software. Ich hoffe ich habe die gewünschten Anforderungen richtig gedeutet und bin schon gespannt auf Eure Antworten zu dieser Idee. -- Gruß, Sonne7 Disk!  05:24, 10. Apr. 2016 (CEST)

Bei der Suche die Begriffserklärung immer gleichrangig anbieten[Quelltext bearbeiten]

Beim Eintippen im Suchfeld ist mir schon mehrfach Folgendes widerfahren. Ab einer bestimmten Länge des schon getippten Präfixes taucht das gesamte Lemma selbst, auf das ich es abgesehen habe, schon in der Aufklappliste auf. Wenn ich es anwähle, bemerke ich erst dort am Artikelanfang mit dem Begriffsklärungshinweis, dass es nur das Hauptlemma zu diesem Wort ist und nicht dasjenige, das ich will, bzw. mir fehlt jedenfalls zur Versicherung erst einmal das Angebot der Alternativen, die in der Begriffserklärung beisammen stehen. Irgendwie wurde ich da also auf einen Umweg gelockt. Mir erscheint es deshalb sinnvoll, dass in der Aufklappliste des Suchfeldes, sobald das Lemma EinBegriff angeboten wird, zugleich auch das Lemma EinBegriff (Begriffsklärung) angeboten werden sollte, wofern es denn so eine Begriffsklärung nach System Der häufigste Begriff – und nicht die Begriffsklärung selbst – bekommt das klammerlose Lemma gibt. Der Server würde auch oft eine Seite weniger ausliefern müssen, wenn die Folge der Seitenaufrufe von

XYZXYZ (Begriffsklärung)XYZ (WasAnderes)

auf

XYZ (Begriffsklärung)XYZ (WasAnderes)

verkürzt würde.

Es mag sein, dass man diese Gleichrangigkeit der „zurückgesetzten“ Begriffsklärung mit Klammerzusatz technisch nicht immer erreichen kann, wenn etwa noch andere Ergänzungen zu anderem klammerlosem Lemma durchs eingetippte Präfix noch nicht ausgeschieden sind. Aber es ist ärgerlich, wenn – wie mir oft widerfahren ist – in der Aufklappliste neben XYZ schon ein XYZ (NochWasAnderes) auftaucht, aber kein XYZ (Begriffsklärung). Die Begriffsklärung, so scheint mir, sollte jedenfalls immer jedem anderen Klammerzusatzlemma gegenüber priorisiert in die Aufklappliste gelangen. --Silvicola Disk 20:49, 12. Feb. 2016 (CET)

✔ Ja – gute Idee!
Bitte realisieren, dass künftig das Lemma EinBegriff und das Lemma EinBegriff (Begriffsklärung) in der Aufklappliste zugleich angeboten werden!
--TOMM (Diskussion) 22:33, 12. Feb. 2016 (CET)
Beispiel:
Wenn man Fulda, wie im Diskussionsabschnitt Aufruf von Artikeln mit Klammern-Schreibweise erwähnt, als Suche eingibt, sollte direkt unterhalb des dann als gefundener Begriff erscheinenden Wortes Fulda die dazugehörige BKL-Seite angezeigt werden – mit anderen Worten:
Fulda
Fulda (Begriffsklärung)
Aber dies geschieht aktuell…
nur bei manchen Begriffen (wohl nur bei solchen, die wenige gleichnamige Bedeutungen haben)
…erst, wenn man „Fulda (“   [also Fulda + Leerstelle + öffnende Klammer]   eingibt.
--TOMM (Diskussion) 13:19, 10. Apr. 2016 (CEST) bis --TOMM (Diskussion) 13:28, 10. Apr. 2016 (CEST)

Ich bin natürlich auch für diese Verbesserung. Wenn es nach mir ginge, könnte man sogar einen eigenen Abschnitt einrichten, mit den drei ähnlichsten Begriffsklärungsseiten unterhalb der (dann nur) Artikelvorschläge und oberhalb der Volltextsuche. --Diwas (Diskussion) 19:03, 10. Apr. 2016 (CEST)

W3C Konformität von Seiten der Wikipedia[Quelltext bearbeiten]

Eher zufällig habe ich festgestellt, dass sehr viele Seiten der deutschen Wikipedia nicht W3C konform sind, weil sie beispielsweise veraltete HTML-Elemente enthalten.

Beispiel: für die Seite Heidelberg meldet der W3C Validator mehr als 200 Fehler.

Gibt es eine Möglichkeit, alle Seiten mit bestimmten obsoleten HTML-Elementen zu finden, insbesondere in den Vorlagen?

Kann die Korrektur zumindest teilweise automatisiert werden?

--Stefan Weil (Diskussion) 12:37, 18. Feb. 2016 (CET)

  • Ich habe dich gerade eben erst hier gesehen und das teilweise schon unter Vorlage Diskussion:Infobox #W3C Konformität beantwortet.
  • Solange die Browser das alles noch brav anzeigen, gibt es bei der Masse der Bearbeiter aber noch keinen Leidensdruck, irgendwas zu ändern oder irgendwas dazuzulernen gegenüber dem, was sie schon seit zehn Jahren immer genauso machen.
    • Solange ist W3C-Kompatibilität auch nachrangig; Inhalte gehen vor Syntax.
  • Serienmäßige Bearbeitungen von Artikeln nur aus syntaxkosmetischen Gründen, bei denen sich hinterher am Erscheinungsbild nichts verändert und die sonst keine Außenwirkung haben, sind unzulässig.
  • Eine automatisierte Reparatur unterstellt, dass der menschengemachte Inhalt der Wikitexte syntaktisch einwandfrei, nur halt im veralteten Format vorliegen würde.
    • Das ist aber nicht der Fall.
    • Das ist voller Syntaxfehler, die bei der Seitendarstellung und der mehrstufigen Erarbeitung des HTML-Dokuments kurzerhand ignoriert oder wundersam interpretiert werden, und bei denen mehr oder weniger das herauskommt, was sich vor zehn Jahren mal dabei gedacht wurde.
    • Wenn man da mit irgendwelchen plumpen Automatismen hineingrätschen würde, käme aber ein völlig falsches Erscheinungsbild und Interpretation heraus, und dem Werkzeugersteller würde man ziemlich doll auf die Finger hauen.
  • Es läuft bereits seit Jahren mit WSTM ein Automatismus im Hintergrund durch die Bearbeitungen, der allerlei repariert, HTML modernisiert und andere Wikisyntax auf den aktuellen Stand bringt. Das aber immer nur in zweifelsfrei interpretierbaren Situationen, und fokussiert auf richtig falsche Fehler.
LG --PerfektesChaos 13:51, 18. Feb. 2016 (CET)
Mir würde als erster Schritt schon eine Liste aller Vorlagen, die bestimmte veraltete Attribute enthalten, reichen. Dann könnte man diese Liste manuell abarbeiten und so alle Seiten, die diese Vorlagen verwenden, verbessern. Gibt es bereits Module/Tools/Bots oder wie auch immer das bei WP heißt, die eine derartige Suche ermöglichen? Ich habe bisher noch keine eigene Programmiererfahrung mit WP Bots oder Tools. --Stefan Weil (Diskussion) 15:33, 18. Feb. 2016 (CET)
Die normale Suchfunktion kann nach regulären Ausdrücken suchen: "insource:/blabl(a|ub)/". Damit lassen sich die meisten Dinge finden, die man sucht. Oder, wenn es kein regulärer Ausdruck sein muss, einfach "insource:blabla" --mfb (Diskussion) 15:45, 18. Feb. 2016 (CET)
@Stefan Weil: Es gibt hier auch noch die WP:VWS.
Wenn du bisher noch „keine eigene Programmiererfahrung mit WP Bots oder Tools“ hat, ist es überhaupt keine gute Idee, jetzt loszurennen und um bloßer Syntaxkosmetik willen an hunderterlei Vorlagen herumzuzuppeln.
Wenn du eine Vorlage programmtechnisch überarbeiten willst, dann mach es auch richtig: Ggf. /Doku ausgliedern, /Meta eindampfen, bei im ANR einsetzbaren Vorlagen TemplateData anlegen.
Wenn du das nicht kannst, dann ist deine Bearbeiterei recht sinnfrei und wirkungslos und lässt absehbar mehr Kollateralschäden ahnen, als du etwas vorwärtsbrächtest.
Bevor du dich also serienmäßig in Basteleien stürzt, lege bitte auf der VWS klar, was du woran ändern willst und welche sonstigen Wartungsarbeiten an einer Vorlage du außerdem vornehmen möchtest oder müsstest. Ggf. ist die bisherige Programmierung völlig überholt und ein grundsätzlich anderer Weg wäre zu beschreiten; reines HTML-Rumgefrickel bringt dann überhaupt nicht weiter. Auf Holzwegen Perserteppich auszulegen macht keine Autobahn draus.
Wenn du dich allerdings so wenig mit den Feinheiten der Wiki-Technologie auskennst, dass dir die RegExp-Suche nicht bekannt ist, so fürchte ich, dass der Schaden den Nutzen überwiegen würde.
VG --PerfektesChaos 15:56, 18. Feb. 2016 (CET)
Im Gegensatz zu früher legen die tollen modernen Webstandards nicht nur fest, was „richtig“ und was „falsch“ ist, sondern auch, wie ein Browser „falschen“ Code behandeln soll. Die genaue Art der Fehlerbehandlung ist von ausgewiesenen Experten so spezifiziert worden, dass „falscher“ Code in aller Regel trotzdem sinnvoll interpretiert wird, und wird von den heute verbreiteten Browsern haargenau umgesetzt.
Hinzu kommt, dass die Fehler in Stefan Weils Validator-Link fast ausschließlich veraltete HTML-Layout-Attribute sind. Diese Fehlersorte ist wahrscheinlich die ungefährlichste überhaupt: Zwar sind diese Attribute in HTML5 offiziell verboten und sollten durchaus nach und nach ersetzt werden, in HTML4 waren sie aber noch erlaubt und in HTML5 ist exakt festgelegt, was sie bedeuten. Deshalb besteht kein akuter Handlungszwang.
Ganz allgemein kann man als „gewöhnlicher“ Wikipedia-Leser oder -Bearbeiter das Thema „Konformität“ weitestgehend ignorieren. Es ist beinahe unmöglich, über den Wikitext Fehler einzubauen, die wirklich gefährlich wären. Gruß --Entlinkt (Diskussion) 02:23, 22. Mär. 2016 (CET)
Die enwiki-Diskussionsseite zur HTML5-Projektseite ist ganz interessant, da hatte ich mich mal mit einem Bot-Betreiber über die Geheimnisse von Vorlagen für <br style="clear:both" /> als Inline-Element statt ähnlicher div-Lösung (Blockelement) in anderer Vorlage gestritten. –Be..anyone (talk) 19:56, 11. Apr. 2016 (CEST)

Direkte Seitenanwahl bei Suchergebnissen[Quelltext bearbeiten]

Hallo! Ich weiß nicht, ob es diesen Vorschlag schon mal gab, aber mir fehlt ab und an die Möglichkeit, in den Suchergebnissen eine Seite direkt anzuwählen, so wie bei Google – gerade wenn es einige hundert Ergebnisse betrifft. Wäre eine diesbezügliche Ergänzung sinnvoll und vor allem möglich? --j.budissin+/- 16:43, 8. Mär. 2016 (CET)

Reicht es dir, die URL manuell zu verändern? Über den offset-Parameter kannst du die Seite wählen, so gibt &limit=20&offset=60 direkt die Seite 3. --Schnark 10:07, 10. Mär. 2016 (CET)
Ja, das mache ich bis jetzt. Eine Leiste zum Anklicken untendrunter wäre natürlich bedienerfreundlicher. --j.budissin+/- 10:27, 10. Mär. 2016 (CET)
Die könntest du dir mit einem kleinen JS dazu bauen. --Jobu0101 (Diskussion) 10:36, 10. Mär. 2016 (CET)
Das würde mir erstmal reichen. Hättest du eins vorrätig? --j.budissin+/- 10:58, 10. Mär. 2016 (CET)
@Benutzer:J budissin: Da ich das auch wollte hab ich mal etwas gebastelt: Benutzer:Nfreaker91/common.js. Bitte mit Vorsicht genießen, das wurde nur bis zum groben Funktionieren gebastelt und hat einige Fehler. Wer es besser kann darf gerne direkt am Objekt arbeiten. (schön wäre ein Url-Parameter-Splitting) Gruß, --Nfreaker91 15:50, 16. Apr. 2016 (CEST)

Darstellung der Aktualität eigener Beiträge[Quelltext bearbeiten]

Bisher sind eigene Beiträge auf der Übersichtsseite, die noch nicht von anderen Schreiberlingen verändert wurden, mit einem fetten "(aktuell)" versehen. Dies ist optisch alles andere als wirklich übersichtlich, infolge Zeilenumbruch v.a. bei schmalen Bildschirmen. Es ginge aber auch besser: so wie bei Nichtsichtern noch ungesichtete Beiträge orange gefärbt werden, sollten auch eigene Beiträge in einer anderen Farbe erscheinen, wenn sie noch aktuell oder nicht mehr aktuell sind (ich lasse an dieser Stelle offen, was in welcher Farbe). Damit liesse sich viel schneller und besser erkennen, was inzwischen wieder verändert worden ist. Gerade bei Diskussionen ist das von Vorteil.

Nachtrag: es sollten auch jene Beiträge, die zwar nicht mehr aktuell sind, aber bei denen die letzte Änderung dennoch von mir stammt (zuoberst), von jenen zu unterscheiden sei, bei denen die letzte Änderung nicht von mir stammt. Ob dabei immer nur die letzte Änderung eingefärbt wird oder andere Farben genutzt werden könnten, lasse ich an dieser Stelle offen.

Und wenn wir schon an den Farben sind: mit Zusatzeinstellung sind interne Links auf BKLs dunkelrosa färbbar. Lässt sich das nicht etwas diskreter darstellen? Gelb oder hellrosa etc. würde reichen (muss einfach noch auf der helleren Seite sein, damit es beim s/w-Druckuck lesbar bleibt und nicht sowas auftaucht, das wie eine Zensurschwärzung aussieht.

PS: das ganze muss auch bei MonoBook-Darstellung auch hinhauen ... :) --ProloSozz (Diskussion) 02:44, 14. Mär. 2016 (CET)

Ich habe deine hauptsächliche Anregung soeben weitergegeben; zumindest um die technischen Voraussetzungen für eine einfache Dekoration zu schaffen.
BKL kannst du dir persönlich in jeder beliebigen Farbe darstellen; MediaWiki:Gadget-bkl-check.css bewirkt die für alle gewohnte Darstellung. Wenn sie dir nicht gefällt, schalte dir das Helferlein ab und schreibe dir deine private Dekoration gemäß WP:CSS in deine Bentzerseite(n).
@Entlinkt: Klingt so, als ob MediaWiki:Gadget-bkl-check.css eine @screen-Regel bräuchte, damit wir hier nicht weiter der Zensur bezichtigt werden.
VG --PerfektesChaos 12:56, 24. Mär. 2016 (CET)
Sodele: BKL definitiv erlederitzt (s.u.). Und auch bzgl. den aktuellen und nicht mehr aktuellen Beiträgen hat sich was getan ... :) ... je nach Monitor und Blickwinkel ist der Unterschied aber sehr blass und kaum erkennbar ... könnte minim kräftiger sein (aber nicht übermäßig). Danke soweit ... :) --ProloSozz (Diskussion) 17:49, 25. Mär. 2016 (CET)

Hintergrundfarbe BKL in Druckversion[Quelltext bearbeiten]

@ProloSozz: Bekommst du wirklich beim Ausdrucken von Wikiseiten einen dunklen Hintergrund bei Links auf Begriffsklärungsseiten? Das kann eigentlich nicht sein, da die Hintergründe sämtlicher Links beim Drucken wirksam abgeschaltet werden (Code hier, und ich habe es auch getestet).
Allgemein würde ich die Farbe dieser Hervorhebung nur sehr ungern ändern, da sie seit etlichen Jahren dieses Dunkelrosa ist und optische Änderungen von Dingen, die schon lange Bestand hatten, ein heikles Thema sind. Man kann sich damit durchaus den Ärger derjenigen einhandeln, die die alte Farbe gewohnt sind und sie behalten wollen. Gruß --Entlinkt (Diskussion) 00:45, 25. Mär. 2016 (CET)
Ich habe mal eine Zwischenüberschrift spendiert, da wir vom Thema des Ausangs-Thread doch deutlich abweichen.
  • Es war oben vom „s/w-Druckuck“ (niedlicher Typo nebenbei) die Rede; das könnte auf drei Arten zu verstehen sein:
    1. „Druckversion“ per &printable=yes in der linken Spalte des ANR.
    2. PDF von Artikeln
    3. HTML-Dokument im Browser Drucken.
  • Unabhängig davon, was im März 2016 in den ersten beiden Fällen erscheint, kann es sinnvoll sein, vorsorglich ein @media (positiv: @media screen,handheld) explizit zu spezifizieren.
    • Die kaskadierende Reihenfolge des legacy-commonPrint.css ist mir nicht so ganz klar.
    • Es wurde immer nach dem von Parser und Extensions und Skin generiertem CSS in die Kaskade eingefügt; mit important auch das inline-HTML abdeckend.
    • Wo genau da site- und user-CSS erschiene, ist mir nicht geläufig.
    • Es gibt in der Kaskadierungs-Reihenfolge einen ähnlichen und von mir immer noch nicht beanstandeten Bug, wonach group-CSS erst nach user-CSS wirksam wird und damit die ausdrückliche Spezifikation des Einzelbenutzers immer vom CSS der Benutzergruppe wieder überschrieben wird.
    • Die Aktivierung der Gadgets und ihres CSS kann aber eigentlich zu beliebiger Zeit erfolgen. Damit kann es heute oder später Zufall sein, ob die Auswirkungen von späterem commonPrint rückgängig gemacht würden oder nicht.
    • Im <head> steht ein <meta name="ResourceLoaderDynamicStyles">, hinter dem alle von Zusatzmodulen geladenen <style> eingefügt werden, damit sie das oben von mir aufgezählte statische CSS wieder überschreiben und eine vorhersagbare Reihenfolge herstellen können.
    • Mit legacy wird schon angedeutet, dass sich das irgendwann mal ändern könnte. Alle Jahre wieder bekommt irgendwer einen Rappel und beginnt zumindest eine größere Umstrukturierung, und der ganz große Wurf für die Modularisierung der überkommenen CSS-Ressourcen wird seit ewig versprochen. Einen neuen Namensraum für alle Ressourcen-Seiten, der MediaWiki:-Nachrichtentexte ablösen soll, gibt es auch schon; Veränderungen sind also absehbar.
Schöne Feiertage --PerfektesChaos 10:32, 25. Mär. 2016 (CET)
Ich werde das – nachdem ich es aufgrund des Vorschlags hier kurzzeitig irrtümlich eingefügt hatte – nicht (wieder) einfügen, weil es nun einmal redundant ist und Redundanz immer schlecht ist.
  1. Du schlägst @media screen, handheld vor und daran sieht man direkt, warum die Redundanz schlecht ist, weil der Medientyp handheld per https://drafts.csswg.org/mediaqueries/#media-types deprecated ist und nichts bewirkt (Authors must not use these media types … User agents must recognize the following media types as valid, but must make them match nothing). Wenn man die Redundanz vermeidet, kann so ein Fehler gar nicht erst passieren.
  2. Meine Glaskugel kommt zu einem anderen Ergebnis bezüglich der zukünftigen Funktionsfähigkeit. Die Einfärbe-Regel in MediaWiki:Gadget-bkl-check.css hat fast die niedrigste Spezifität, die in CSS überhaupt möglich ist, während ihr Gegenteil durch !important fast die höchstmögliche hat. Die Ladereihenfolge ist deshalb nicht relevant. Außerdem werden übrigens auch externe Links in MediaWiki mit einem Hintergrundbild dekoriert, d. h. man kann das Gadget gar nicht brechen, ohne alle externen Links zu brechen.
  3. Danke für die vielen Hinweise, allerdings weiß ich Allgemeinen meistens durchaus, was ich tue und warum. Im hier vorliegenden Fall wurde allerdings mit einer falschen Aussage argumentiert (dass im Schwarzweiß-Ausdruck dunkle Hintergründe vorhanden seien), die ich in dem Moment geglaubt habe.
Bitte mit dem Vorschlag wiederkommen, wenn es tatsächlich irgendwo ein Problem gibt, vorher ist es keine Verbesserung und birgt nur das Risiko von Inkonsistenzen. Gruß --Entlinkt (Diskussion) 11:22, 25. Mär. 2016 (CET)

Wenn beim Druckvorgang automatisch "entzensurbalkt" wird, wäre dieser somit ja in Butter (und der Druck nicht das Problem). Das recht dunkel erscheinende Rosa beeinträchtigt aber den Lesefluß beim direkt online lesen, v.a. auf kleineren Bildschirmen, da die entsprechenden Wörter nicht so normal sichtbar sind wie einfache Links oder der ganze Text. Da muß dann immer vergrößert (auf dem Handheld/SmaPho/etc.) oder der Bildschirm von einem anderen Blickwinkel schräggestellt angeschaut werden, damit die Farbkombination lesbar wird (je nachdem, in welcher Ecke des Bildschirms das Wort erscheint). Der Kontrast innnerhalb der Hervorhebung (nicht der Hervorhebung vor dem Seitenhintergrund) müßte besser sein (zwar unterlegt, aber eben nicht so dunkel erscheinend, und nicht so knallig). Knallig mag seine Berechtigung haben, ist in der vorliegenden Form aber nur dann nötig, wenn man auf Korrekturjagd geht. (Nachtrag: das Problem ist die Farbkombination selbst mit blau auf rosa und rot auf rosa.) Elegant wäre die Option, es in einer anderen Farbgebung selbst setzen zu können (in den Einstellungen) – d.h. man kann nicht nur ein-/ausschalten, sondern gleich auch entweder die Farbgebung selbst frei wählen oder aus mehreren fix vorgegebenen Optionen auswählen (wovon eine davon dann natürlich die bisherige wäre und mind. ein weitere ein dezentes hell... (was auch immer). Dann wäre das Problem umschifft und erledigt. Aber so wie bisher ist es immer Leseflußunterbrechend, was stört. NB: ich bin immer ohne Scripting (und mit einem älteren Brower) unterwegs. Optionen, die JavaScript/ActiveX etc. benötigen, wären verlorene Mühe. --ProloSozz (Diskussion) 15:39, 25. Mär. 2016 (CET)

Wenn das Gadget jetzt neu zu entwerfen wäre, würde ich mich deiner Argumentation anschließen und es zum Beispiel ungefähr so machen:
Das Problem ist einfach, dass das Gadget schon seit der allerersten Version von 2008 diese knallige Farbe (#ff9191) hat, die Farbe höchstwahrscheinlich bewusst so knallig gewählt wurde und mittlerweile überall mit Begriffsklärungen assoziiert wird. Ich persönlich hänge ganz sicher nicht an der aktuellen Gestaltung, bin aber etwas skeptisch, ob man den Wikipedianern in naher Zukunft hier noch eine optische Änderung zumuten sollte, da es um das Gadget auch aus anderen Gründen kürzlich einen ziemlichen Wirbel gab. Bitte etwas Bedenkzeit.
Konfigurierbar sind Gadgets leider nicht wirklich, erst recht nicht ohne JavaScript. Du kannst allerdings in Special:Mypage/common.css eine eigene Formatierung für die Klasse mw-disambig erstellen. Auch die oben genannte Beispielformatierung könntest du auf diesem Wege für dich realisieren. Gruß --Entlinkt (Diskussion) 16:06, 25. Mär. 2016 (CET)
Nochmal: ich kann die Motivation für eine knallige Farbe äußerst gut nachvollziehen – denn dabei geht es primär darum, Links auffinden zu können, die nachzukorrigerein sind, da bei einem früheren Lemma nun eine BKS steht und der Link aber immer noch auf denselben Artikel verweisen soll, der aber einen "eigenen Standort" erhalten hat, da noch weitere Dinge so bezeichnet werden – und genau dafür ist eine knallige Farbe auch sinnvoll. Aber eben: beim online lesen sind das dann immer fast schwarze Löcher, die auf Distanz nicht gelesen werden können, sondern die man separat entziffern muß – und das soll's nicht sein. Nun – das mit dem .css sieht insofern interessant aus, als dies ja auch script-unabhängig passieren müßte. Das wäre dann eine "benutzerweite Einstellung" (wie das Darstellungslayout auch); und wenn das hinhaut, wäre es genau das gesuchte ... :) ... Nun: was muß in jene "eigene .css" rein, was gilt da für eine Syntax? --ProloSozz (Diskussion) 16:33, 25. Mär. 2016 (CET)
Siehe Wikipedia:Helferlein/Begriffsklärungs-Check#Eigene Anpassungen und beispielsweise Vorlage:W3C-Farben. Das Gadget in den Einstellungen kannst du anschließend abschalten. Gruß --Entlinkt (Diskussion) 16:48, 25. Mär. 2016 (CET)
Danke – das haut hin (und sieht in PaleGoldenrod weit weniger störend aus als bisher). Frage: gibt's irgendwo eine Übersicht mit allen unterlegten Farben, die genutzt werden (damit ich da nicht was gleich setze, was unterschieden werden müßte)? --ProloSozz (Diskussion) 17:37, 25. Mär. 2016 (CET)
Ich hoffe doch sehr, dass wir in Artikeltexten keine anderen Farbmarkierungen haben.
Für Bausteine und Tabellen werden oft die Farben benutzt, die unter Hilfe:Farbe#Klassen aufgeführt sind, aber leider oft auch welche, die nirgends aufgelistet sind. Ansonsten verwendet auch die Wikisoftware selbst Farben, wobei ich aber nur in wenigen Fällen einen Ort kenne, wo sie aufgelistet wären (für Beitragslisten zum Beispiel ganz unten auf der Seite Spezial:Beiträge/ProloSozz). Das sollte aber kein Problem sein, da Artikeltexte hoffentlich weitgehend verschont bleiben.
Ich verwende für Begriffsklärungen übrigens jetzt testweise die folgende Gestaltung (wie das Beispiel oben):
.mw-disambig {
	background: url(//upload.wikimedia.org/wikipedia/commons/thumb/e/ea/Disambig-dark.svg/16px-Disambig-dark.svg.png) 4px center no-repeat #f9f9f9;
	background: url(//upload.wikimedia.org/wikipedia/commons/e/ea/Disambig-dark.svg) 4px center/16px no-repeat #f9f9f9;
	border: 1px solid #ddd;
	border-radius: 2px;
	padding: 1px 4px 1px 21px;
}
Gruß --Entlinkt (Diskussion) 17:58, 25. Mär. 2016 (CET)
Danke – das sieht auch ganz nett aus ... aber nur für vereinzelte BKL-Links – bei Abkürzungsauflistungen o.ä. zerreißt's die Tabellendarstellungsstruktur dann völlig. Mal schauen, wie ich das längerfristig belasse; das rosarote wäre an sich schon nicht unpassend – aber da die Schrift der Links selbst blau oder die der besuchten Links dunkelblau sind, beißen sich die blau mit rosa. Andere Frage: ließe sich bei einem "Rosalink zu einer BKL" allenfalls auch die Schriftfarbe ändern? Auch da sollte eigentlich unterschieden werdenzwischen besucht und unbesucht ... Keine farbliche Unterscheidung wäre in so einem fall aber hinnehmbar. Gesucht wäre eine Ersatzfarbe für die beiden blau, damit ie sich nicht mit dem rosa beißen – dann könnte das rosa bleiben ... --ProloSozz (Diskussion) 11:13, 26. Mär. 2016 (CET)
Ja, die Schriftfarben sind auch änderbar. Hier ein (völlig ungetestetes) Grundgerüst:
.mw-disambig {
	background-color: #ff9191; /* Hintergrundfarbe */
	color:            #006e6e; /* Schriftfarbe für unbesuchte Links */
}
.mw-disambig:visited {
	color:            #006e6e; /* Schriftfarbe für besuchte Links */
}
.mw-disambig:active {
	color:            #006e6e; /* Schriftfarbe für Links während des Anklickens */
}
(Die konkreten Farben sind nicht ernst gemeint, es geht nur um die Syntax.) --Entlinkt (Diskussion) 15:12, 26. Mär. 2016 (CET)

IP-Benutzerseite nicht verlinkt[Quelltext bearbeiten]

Hallo,

warum ist auf der Seite mit den Benutzerbeiträgen einer IP die Hauptbenutzerseite nicht verlinkt, wie sie es bei angemeldeten Benutzern ist?

Dort sieht man z.B. daß die IP einer Universität gehört. Das ist für einen Beobachter sehr erhellend, daß hier in kurzem Abstand auftauchende Edits nicht zum gleichen Rechner und Menschen gehören müssen.

--129.13.72.198 11:02, 24. Mär. 2016 (CET)

Die Tatsache, das auch IPs eine Benutzerseite haben, wird nicht gerne verlinkt, weil diese sonst vandaliert wird. Beispielsweise verlinken auch Unterschriften von IPs nicht auf die Benutzerseite. In den meisten Fällen ist die Benutzerseite auch leer/nicht vorhanden, nur bei statischen IPs finden sich dort Vorlagen. Im Zusammenhang mit IPs ist die Diskussionsseite wichtiger. Der Umherirrende 14:40, 24. Mär. 2016 (CET)
Dann sollte man die aber einfach schreibschützen, anstatt sie zu verstecken. --129.13.72.198 18:30, 30. Mär. 2016 (CEST)
In manchen Fällen ist die Seite sinnvoll. Und ob ein allgemeiner Schutz so einfach umsetzbar wäre weiß ich nicht. --mfb (Diskussion) 12:05, 5. Apr. 2016 (CEST)

Auflösung Wikipedialogo deutsches Wikipedia[Quelltext bearbeiten]

Hallo,

mir ist aufgefallen, dass das Wikipedialogo links oben, der deutschen Wikipedia deutlich unschärfer aussieht, als das der englischen Wikipedia, wenn man es auf einem high-dpi Bildschirm betrachtet oder die Seite heranzoomt.

Die englische Seite scheint ein .png mit etwa doppelter Auflösung zu verwenden. Ich würde gerne anregen das Logo durch ein .svg zu ersetzen oder mehrere größen des .pngs auf den Server zu legen und dann per css mediaquery entscheiden, welches geladen werden soll.. --Spacefish (Diskussion) 00:18, 5. Apr. 2016 (CEST)

dewiki.png (135x155) vs. enwiki.png (135x155) aus Sicht meines Browsers (Chrome) bestätigt das nicht, was hast Du? –Be..anyone (talk) 17:08, 8. Apr. 2016 (CEST)
Zur Info: Zu diesem Thema gibt es phab:T96397. In en.wp gibt es ein Gadget en:MediaWiki:Gadget-NewMainPage.css für eine neue Hauptseite, wo auch auflösende Logos verwendet werden. Der Umherirrende 20:56, 8. Apr. 2016 (CEST)
Aha, der Zoom-level spielt lt. Brion auch eine Rolle, das habe ich meist auf 125% oder mehr (wunderbarer Trick, um die nächste Brille noch ein (Paar) Jährchen aufzuschieben.) –Be..anyone (talk) 01:18, 9. Apr. 2016 (CEST)

"Review" vs. "Schon Gewusst"[Quelltext bearbeiten]

Es war erst in jüngster Zeit zu beobachten, daß sich im Schon gewusst die Beiträge und Kandidaten oft wochen- und monatelang stauen, wohingegen das Review teils tagelang unbesetzt blieb. Beides ist nicht wirklich wünschenswert. Besteht denn keine Möglichkeit die Overhangs beispielsweise mit einem 10- oder 15-k-Textsize-Kriterium, so ähnlich wie im Schreibwettbewerb, von der einen in die andere Kategorie umzuschaufeln, um eine gleichmäßigere Auslastung der Threads zu ermöglichen? SpockLebt (Diskussion) 04:24, 19. Apr. 2016 (CEST)

Das sind aber zwei ganz unterschiedliche Rubriken, im Review befinden sich derzeit etwa 20 Artikel. Dort sollen fortgeschrittene Artikel unter sehr aktiver Mitarbeit des Initiators verbessert werden. Unter Schon gewusst sollen neue Artikel, die nicht im Review sind, bekannt gemacht werden. So lese ich das jedenfalls auf den Seiten. --Diwas (Diskussion) 15:32, 19. Apr. 2016 (CEST)

Zwei weitere Verbesserungsvorschläge[Quelltext bearbeiten]

Hallo.

Mir sind zwei weitere Verbesserungsvorschläge eingefallen, die zwar eher unwichtig, meiner Meinung nach jedoch nicht komplett irrelevant sind:

1. Quelltext von Bearbeitungskommentaren anzeigen lassen[Quelltext bearbeiten]

Es gibt meines Wissens nach, noch keine Möglichkeit, den Quelltext von Bearbeitungskommentaren in der Versionsgeschichte auszulesen; daher schlage ich dies als Funktion vor. Das ist zwar eher Unwichtig, jedoch spricht meiner Meinung nach nicht wirklich etwas dagegen.

Der Quelltext von Bearbeitungskommentaren wird jedoch in E-Mails, die auf Änderungen von Seiten auf beobachteten Seiten aufmerksam machen, angezeigt.

S536870912 (Diskussion) 17:11, 28. Apr. 2016 (CEST)

Das Auslesen ist sehr wohl möglich, jedoch interessiert sich eigentlich niemand für den Quelltext; nur das Resultat. Deshalb gibt es keinen fertigen Knopf dafür. Mit der WP:API geht es gleichwohl; hier der Quelltext zu deiner Bearbeitung. LG --PerfektesChaos 22:28, 28. Apr. 2016 (CEST)
Achso, Danke. Ich bin durch die Bearbeitungskommentare in den Benachrichtigungs-E-Mails darauf aufmerksam geworden. --S536870912 (Diskussion) 15:06, 29. Apr. 2016 (CEST)

2. Nicht grundlos bedanken[Quelltext bearbeiten]

Es gibt sämtliche Internetforen, die über eine Funktion verfügen, bei der man beim Vergeben eines „Kudos“ noch einen Kommentar abgeben kann.

Ich halte solch eine Funktion auch für Wikipedia sinnvoll. -Hoffentlich sind meine Verbesserungsvorschläge nicht irrelevant. —S536870912 (Diskussion) 17:11, 28. Apr. 2016 (CEST)

Die Danke-Funktion ist ausdrücklich nur dazu da, mit einem kleinen Klick ein kurzes Dankeschön zu versenden, über das sich die Empfänger eine Minute freuen sollen, und das nach einer Viertelstunde wieder vergessen ist.
Was du vorschlägst, wurde bewusst nicht realisiert. Es liefe auf ein geheimes Kommunikationssystem hinaus, über das wildfremde Internetbenutzer Nachrichten austauschen könnten, über Bankraub und Bombenanschläge. Die Wikipedia ist aber eigentlich nicht als soziales Netzwerk gedacht, bei dem wir dann irgendwie für ein darknet geradestehen müssten.
Bei der Danke-Funktion ist für Dritte nur einsehbar, wer zu welcher Zeit wem gedankt hatte; nicht aber, wofür. Das ist Absicht, aber freie Nachrichtentexte für jedermann wird es nicht geben.
Die Empfänger wissen, wofür ihnen gedankt wird. Das reicht. Der Rest soll öffentlich sichtbar über Diskussionsseiten kommuniziert werden, wenn es über das genannte kleine Dankeschön hinausgehen soll, oder man möge sich E-Mail schicken.
LG --PerfektesChaos 22:37, 28. Apr. 2016 (CEST)
Verstehe. Danke fürs Antworten. --S536870912 (Diskussion) 15:06, 29. Apr. 2016 (CEST)

Versionsnavigation auch bei Δ-Darstellung[Quelltext bearbeiten]

Um eine Folge von Bearbeitungen eines Artikels schneller prüfen zu können, wäre es besser, wenn auch innerhalb der Δ-Darstellung bleibend das Vor-Zurück-Navigieren möglich wäre. Ich muss da in Serie ständig auf die D-Darstellung zurück, um die Navigation zu bekommen, dann vor- oder zurückgehen, dann die Δ-Darstellung wieder anwählen – eine Umwegigkeit, die doch nur aufhält. --Silvicola Disk 07:51, 29. Apr. 2016 (CEST)

Da bist du hier leider völlig falsch; du müsstest dein Ansinnen auf BD:Schnark/js/diff vortragen. LG --PerfektesChaos 10:10, 29. Apr. 2016 (CEST)

Anführungszeichen[Quelltext bearbeiten]

Ist mir gerade in der rumänischen WP aufgefallem: Dort kann man mittels der Werkzeugleiste obere und untere Anführungszeichen erstellen. Da ist es griffbereiter, mehr Leute würden auf diese typografische Detail achten. Das liese sich hier doch auch implementieren.--Antemister (Diskussion) 13:39, 7. Mai 2016 (CEST)

@Antemister: Aber das ist doch implementiert!? Siehe Hilfe:Symbolleisten#Edittools. Gruß, --Drahreg01 (Diskussion) Hilf mit! 06:47, 17. Jun. 2016 (CEST)
Es geht darum, es in die Werkzeugleiste über dem Edit-Fenster zu setzten, damit es greifbarer ist. Wäre eine Nudging-Sache.--Antemister (Diskussion) 19:17, 17. Jun. 2016 (CEST)
Wenn es um die Leiste über dem Bearbeitungsfeld geht: Unter "Sonderzeichen" -> "Symbole" sind Anführungszeichen enthalten. Unter sieht es für mich so aus wie hier. Der Umherirrende 10:12, 18. Jun. 2016 (CEST)

Länge des Begründung- und Quellen-Feldes[Quelltext bearbeiten]

Kann man das Feld für zusätzliche Angaben bei Änderungen eines Artikels (was dann auch in der Änderungsliste erscheint) vielleicht etwas länger machen? Gerade wenn man z.B. eine Änderung rückgängig machen will und dazu umfangreichere Quellen oder Begründungen angeben will, wird das schnell zu kurz. --79.252.218.75 14:43, 4. Jun. 2016 (CEST)

Möglicherweise gibt es dazu andere Meinungen als meine kurze Lösung und vielleicht ist sogar etwas in Arbeit. Wenn ich mich nicht irre, war übrigens das Feld früher noch wesentlich kürzer als heute. Meine Sofortlösung: Zunächst muss nicht zwingend angegeben werden, welche Änderung auf welche Version revertiert wurde, wenn es die letzte oder eine kürzliche Änderung betrifft. Reicht das nicht, kann man auf die Diskussion verweisen und dort ausführlich begründen und belegen. Dort schafft man damit auch gleich Gelegenheit das zu diskutieren, was sonst möglicherweise in rereverts und rerereverts in der Versionsgeschichte diskutiert wird. Durch zu lange Kommentare wird die Versionsgeschichte auch leicht unübersichtlich und wie gesagt, es könnte dazu verleiten, die Diskussion in die Versionsgeschichte zu verlagern. --Diwas (Diskussion) 23:05, 4. Jun. 2016 (CEST)
Anmerkung zur IP: Quellen gehören in die Einzelnachweise, nicht in den Editkommentar  Frohes Schaffen — Boshomi Defekte URLs - Hilfe mit!  17:25, 18. Jun. 2016 (CEST)
+1 zur Anmerkung: Aber auch im Editkommentar ist ein Hinweis sinnvoll, der z. B. mitteilt, dass ein Einzelnachweis für die Änderung mit eingefügt wurde oder welcher der bereits im Absatz vorhandenen Belege die hinzugefügte Information beinhaltet oder ähnliches. --Diwas (Diskussion) 23:42, 18. Jun. 2016 (CEST)
Das ist ein Top-Wunsch. Der Umherirrende 10:15, 18. Jun. 2016 (CEST)

Interface: Interwiki-Links verschwinden im Edit-Modus[Quelltext bearbeiten]

Ich rege an, dass die Interwiki-Links im Edit-Modus sichtbar bleiben (am besten dort, wo sie im Lese-Modus auch sind). --Mattes (Diskussion) 15:43, 26. Jun. 2016 (CEST)