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.

Inhaltsverzeichnis

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)

Interwikilinks - Fragen dazu[Quelltext bearbeiten]

Hallo, mir war bis vor einigen Minuten nichts von dieser offensichtlich furchtbar strengen Regel ( https://de.wikipedia.org/wiki/Hilfe:Internationalisierung#Im_Text_sichtbare_Interwiki-Links ) bekannt, wurde aber imperativ darauf hingewiesen, daß ich mich in Zukunft daran zu halten habe. Das ruft natürlich meinen Widerspruchgeist auf den Plan, der bei m.E. unsinnigen Regelungen sofort anspringt. Und diese Regeung ist für mich unsinnig. Wer hat diese Regelung überhaupt eingeführt und mit welcher Begründung? Englisch sollte von der überwiegenden Zahl von Lesern aller Wikis soweit verstanden werden, daß solche Links für diese Menschen problemlos lesbar sind, bei Links auf eher exotische Sprachen wie von Englisch nach Deutsch (meine ich wirklich so!) kann man ja eine solche Regelung noch verstehen, aber Links auf die englische Wiki erscheinen mir in vielen/den meisten Fällen sinnvoll. Mir ist es z.B. eben passiert, daß in meinem Artikel Liste gehörloser Musiker und Komponisten zwölf solcher Links gelöscht wurden und ich der Meinung bin, daß der Artikel so ungemein an Wert verloren hat. Falls jetzt jemand auf die gloreiche Idee kommt und mir rät, diese Artikel doch anzulegen; ich bin ein Mensch der einer geregelten Arbeit nachgeht und eine Familie hat. Für mich gibt es also noch ein Leben neben der Wikipedia. Und falls man mir das Leben als Autor weiter so vergrault, kann es problemlos passieren, daß ich meine Mitarbeit hier zumindest deutlich einschränke oder völlig einstelle, gängeln lasse ich mich für freiwillige Arbeit nicht, zumindest wenn ich den Sinn der Gängeleie nicht einsehen mag. So was sollte im Rahmen des allgemeinen Wehklagens, daß die Mitarbeiterzahl einbricht auch mal bedacht werden. Aufgrund des ansonsten von mir sehr geschätzten Prinzip der Freiheit und Hirarchiearmut weiß ich in diesem Fall allerdings nicht, an wen man sich zwecks Änderung bzw. Diskussion dieses Prinzipes wenden kann, hier (Im Cafe und der Diskussionsseite der oben zitierten Seite, wo ich diese Frage auch schon aufgeworfen habe und hier) denke ich bin ich wohl ein Rufer in der Wüste. --Elrond (Diskussion) 11:04, 27. Nov. 2015 (CET)

Die meisten Regeln hier gehen auf Community-Entscheidungen zurück (der Rest einfach auf Gewohnheit, ganz wenige sind durch Wikimedia vorgegeben). Deine Kritik geht also in die falsche Richtung, gegen wen auch immer genau sie nun gerichtet sein mag. Du kannst gerne ein Meinungsbild anregen, um diese Regel per Mehrheitsbeschluss zu ändern. --mfb (Diskussion) 14:12, 27. Nov. 2015 (CET)
ad WP:Regel: ja, die gibt es
ad Frust und Artikelschreibervergraulen: ja, das ist so
ad selbsternannte Aufpasser und Hinterherräumer: ja, solche gibt es
ad Informationsverlust für den Leser: ja, das wird hier in Kauf genommen, derweil ...
ad Umgehungsmöglichkeiten, ja, es gibt welche, weil die Aufpasser auch nicht alles merken
zu dem konkreten Fall: ich hätte das auch nicht so gemacht, sondern einen Mittelweg gesucht, vielleicht so
Frederick May1 * 9. Juni 1911, † 8. September 1985 ab seiner Kindheit Hörprobleme
Sean Forbes1 US-amerikanischer Hip-Hoper
1 In der englischen Wikipedia vorhandene Artikel
en:Frederick May (composer)
en:Sean Forbes
oder auch so: Frederick May (composer)
--Goesseln (Diskussion) 16:01, 27. Nov. 2015 (CET)
✔ Ja - ein sehr guter Workaround, der mMn alle Regeln befriedigen sollte. -- Sonne7 (Diskussion) 00:31, 28. Nov. 2015 (CET)
Diskussionshinweis: Wikipedia:Café#Interwikilinks_-_Fragen_dazu, Hilfe_Diskussion:Internationalisierung#Interwikilinks_zum_.23 - es wäre ja auch zu naheliegend, die Diskussion nur an einem Ort zu führen. --mfb (Diskussion) 17:21, 27. Nov. 2015 (CET)
Also, ich find ja, persönlich und so, für s Café is das nix. Das Thema, mein ich. fz JaHn 19:49, 27. Nov. 2015 (CET)

Diese Regel, dass man keine Interwiki-Links in Artikeln haben darf, geht auf eine unsorgfältige Änderung von mir und eine spätere Umformulierung zurück, wie ich hier darlege. Es gibt vermutlich keinerlei Community-Entscheidung dazu, dass die Regelung von "soll nicht" auf "darf nicht" geändert werden soll. Ich bitte das bei der Diskussion zu berücksichtigen.
Ich selbst halte das Verbot der Interwiki-Links übrigens auch für nicht sinnvoll. Ich rege hiermit ein Meinungsbild an. Auf meiner Diskussions-Seite (ganz unten) hat Ulamm dargelegt, wie er sich Interwiki-Links vorstellt, bei denen man sofort sieht, dass es sich um solche handelt. --Lu (Diskussion) 23:57, 30. Jan. 2016 (CET)

Bevor das hier einschläft: der derzeitige Regelzustand ist in my humble opinion nicht wirklich gut: heute hat jemand in einer "meiner" Artikelneuanlagen gleich einen doppelten verbotenen Interwikilink auf die russische Wikipedia eingefügt: Andrej Žarnov. Und kein Polizist mit einer Trillerpfeife in der Nähe. Das geht nicht gut. --Goesseln (Diskussion) 00:12, 8. Mär. 2016 (CET)

Cursor direkt im Suchfeld[Quelltext bearbeiten]

Guten Tag, eine Frage: Wenn ich die wikipedia-Hauptseite öffne (https://de.wikipedia.org/wiki/Wikipedia:Hauptseite), warum erscheint der Cursor nicht gleich im Eingabe-Feld, so daß man direkt drauflostippen kann? Habe versucht, eine Antwort darauf in den FAQ zu finden, leider ohne Erfolg. Bin mir auch nicht sicher, ob ich damit hier richtig bin, bitte um Nachsicht und einen Hinweis, wo ich diese Frage am besten loswerde - Danke. MfG Peter (nicht signierter Beitrag von 84.58.200.164 (Diskussion) 16:08, 13. Dez. 2015 (CET))

Das wurde schon sehr oft diskutiert. Bisher haben wir uns immer dagegen entschieden, weil viele Leute mit dem Cursor nach unten navigieren. Das hat Vorrang. Grüße --h-stt !? 18:22, 15. Dez. 2015 (CET)
Einige solcher Anfragen findest du unter anderem bei Wikipedia:Fragen zur Wikipedia/Archiv/2007/Woche 20#Idee: Focus auf das Textfeld "Suche" bei Wikipedia setzen, Wikipedia:Fragen zur Wikipedia/Archiv/2008/Woche 02#Usability - Sofortige Eingabemöglichkeit beim Fensteraufruf und Wikipedia:Fragen zur Wikipedia/Archiv/2010/Woche 46#Cursor nicht im Suchfeld, z.T. auch mit Hinweisen zur evtl. Umsetzung. -- Jesi (Diskussion) 12:02, 16. Dez. 2015 (CET)
Ich hätte eine Idee für eine Alternative: statt des Cursors im Suchfeld könnte man es vielleicht so machen, dass jeder Textinput im Suchfeld landet, auch wenn der Cursor nicht dort ist. Zumindest dort, wo das Suchfeld das einzige Textfeld ist (also auf allen Artikelseiten); auf anderen Seiten wüsste man ja ohne Cursor nicht, wo der Text hin soll, aber andere Seiten sind ja auch weniger das Problem, die Artikelseiten wären ja schon ein riesiger Fortschritt. So könnte man einerseits weiter mit den Cursortasten scrollen, aber zum Suchen von Begriffen drauflostippen, ohne erst den Cursor ins Suchfeld setzen zu müssen. Ich habe das schon mal auf einer andere Seite gesehen. Das müsste also technisch möglich sein (vermutlich mit JavaScript).--137.226.116.99 13:23, 4. Feb. 2016 (CET)
Es gibt auch Leute, die ihren Browser so konfiguriert haben, dass die (browserinterne) Suche innerhalb der Seite aufgerufen wird, wenn man zu tippen beginnt, ohne dass sich der Cursor in einem Textfeld steht. In Firefox ist das die Einstellung "Suche bereits beim Eintippen starten" unter "Erweitert". Diese wären sehr überrascht und genervt, wenn eine Seite da eingreift und die Tastatureingaben unerwartet abfängt. --Schnark 09:54, 6. Feb. 2016 (CET)

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)

Nachträgliche Überschrift für alte, abschnittslose Beiträge auf Diskussionsseiten[Quelltext bearbeiten]

Auf Diskussionsseiten sollte idealerweise für jedes angesprochene Thema eine Überschrift angelegt werden. Aber früher wurde das oft nicht gemacht, weswegen auf sehr vielen Diskussionsseiten ganz oben, noch über dem Inhaltsverzeichnis, einige lose Wortmeldungen stehen, die den Gesamteindruck der Diskussionseite prägen - oft durchaus negativ, nicht zuletzt, weil sie eben durch die exponierte Wirkung zu Vandalismus einladen (Beispiel). Wie wäre es, systematisch nachträgliche Sammelüberschriften für solche Beiträge zu setzen (etwa "Beiträge vor August 2008") und sie dann zumindest gebündelt unter dem Inhaltsverzeichnis zu haben, was oben genanntes Problem entschärften würde? --KnightMove (Diskussion) 01:32, 3. Jan. 2016 (CET)

Könnte man die Botbetreiber fragen, insbesondere die Archivbots untersuchen Diskussionsseiten ohnehin schon auf ihre Abschnittsstruktur. --mfb (Diskussion) 02:08, 3. Jan. 2016 (CET)
Ja - mir schien eine Vorab-Diskussion hier sinnvoll. --KnightMove (Diskussion) 02:22, 3. Jan. 2016 (CET)
✔ Ja - Bitte dieses Feature realisieren - idealerweise mit einer Möglichkeit zum Opt-out via einer entsprechenden Vorlage dazu. -- Sonne7 Disk!  13:29, 22. Jan. 2016 (CET)
✔ Ja – gute Idee!
     Aber statt Beiträge vor August 2008 würde ich schlicht (z. B:) Diskussionsabschnitt ohne Überschrift wählen.
     Hierzu kann dann eine Übersichtsseite zur Abarbeitung erstellt werden, anhand der man dann fehlende Überschriften ergänzen kann!
--TOMM (Diskussion) 15:58, 22. Jan. 2016 (CET) und --TOMM (Diskussion) 16:19, 22. Jan. 2016 (CET)
✔ Ja - bin auch absolut dafür! Verhindert auch, dass verunsicherte Benutzer aktuelle Beiträge oben anfügen anstatt unten!--Nix schlecht (Diskussion) 23:21, 2. Feb. 2016 (CET)
✔ Ja – Mit neutraler Überschrift wie von TOMM vorgeschlagen. Lage zum Inhaltsverzeichnis so, wie es sich dann halt nach den jetzigen Regeln automatisch ergibt; wir wollen doch schließlich keine Sonderbehandlung von Diskussionsabschnitten. --Silvicola Disk 20:58, 12. Feb. 2016 (CET)

Popups für Belege (wie in der englischen Wikipedia)[Quelltext bearbeiten]

In der englischen Wikipedia wird wenn man mit der Maus über die Fußnote eines Belegs fährt, der entsprechende Beleg (also quasi "der Inhalt der Fußnote") in einem Popup an Ort und Stelle angezeigt. So braucht man nicht immer zwischen der Liste aller References unten am Artikel (die es natürlich weiterhin gibt) und der Fundstelle im Artikel zu wechseln. Das finde ich sehr praktisch. Wäre das vielleicht auch in der deutschen Wikipedia umsetzbar? --79.224.81.242 17:27, 9. Jan. 2016 (CET)

Wenn du dich anmeldest, kannst du es in den Einstellungen aktivieren, standardmäßig für unangemeldete Benutzer ist das Feature derzeit nicht aktiviert (ich finde es auch praktisch). --mfb (Diskussion) 17:30, 9. Jan. 2016 (CET)
Vielen Dank für die Info. Ich benutze Wikipedia bisher immer unangemeldet. Und in der englischen funktioniert das auch ohne Anmeldung. Wäre vielleicht mal eine Diskussion wert, ob das auch in der deutschen für alle Nutzer aktiviert wird. --79.224.81.242 17:33, 9. Jan. 2016 (CET)
Das wurde schon mehr als einmal diskutiert: Wikipedia:Verbesserungsvorschläge/Archiv/2010/Juli#Einzelnachweis-Vorschau beim Drüberfahren, Wikipedia:Verbesserungsvorschläge/Archiv/2012/August#MouseOver bei Einzelnachweisen, Wikipedia:Verbesserungsvorschläge/Archiv/2012/Oktober#Mouseover, Wikipedia:Fragen zur Wikipedia/Archiv/2013/Woche 10#Mouse Over, Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2014#Vorschaufenster für Fußnoten als Standard für alle Leser (wie in der englischen Wikipedia)? nur als Beispiele, die ich gerade so fand. --Diwas (Diskussion) 00:32, 10. Jan. 2016 (CET)
Fände auch ich sehr praktisch, wenn man nicht mehr ständig auf der seite hin- und herspringen müsste. Diejenigen die das lieber anklicken (oder Touch-Bedienung nutzen, wo es keine andere Möglichkeit gibt) ändert sich nichts. Aber es kommt für Mausnutzer ein weiterer Komfort-Gewinn dazu. Wäre sicher sehr nützlich.--GB1974 (Diskussion) 09:19, 22. Jan. 2016 (CET)
Das fände ich auch sehr nützlich. Da freue ich mich in der englischen Wikipedia immer drüber und fände es toll, wenn auch die deutsche Wikipedia dies böte. Ist nur eine Kleinigkeit, die die Benutzerfreundlichkeit im täglichen Gebrauch aber massiv steigern würde.--137.226.116.99 13:25, 4. Feb. 2016 (CET)

Vielen Dank für die vielen Antworten und Hinweise. Ich habe mal die alten Diskussionen zu dem Thema gelesen und das Hauptargument ist die Barrierefreiheit. Das ist ohne Zweifel von großer Wichtigkeit. Aber da sehe ich keine diesbezüglichen Nachteile. Ich weiß nicht, wie das damals umgesetzt werden sollte, aber so wie aktuell in der englischen Wikipedia funktioniert es ja sehr gut. Da es im Sinne des Progressive Design eine Zusatzfunktion ist (bei Mouse-over) und die alte Zugriffsmöglichkeit (durch Klick) weiter erhalten bleibt stellt es ja keinerlei Einschränkung oder Umstellung dar. Auch für Screenreader sollte das kein Problem sein und für Bildschirmlupen, Zoom, etc. erst recht nicht. Ich habe auch bei der englischen Wikipedia noch keine diesbezüglichen Beschwerden gehört. Es scheint also von der Barrierefreiheit wirklich kein Problem zu sein. Und andere Probleme kann ich auch nicht erkennen. Fände ich auf jeden Fall toll, wenn dieses praktische Feature auch in der deutschen Wikipedia umgesetzt würde. --79.252.208.204 21:28, 4. Feb. 2016 (CET)

Das Popup sollte eine progressive Verbesserung sein, ja, aber da es Fehlermeldungen wie en:Wikipedia:Village pump (idea lab)/Archive 15#The reference popup should last longer gibt, ist es das nicht in allen Fällen. Auf Geräten mit Touchscreen und Screenreader kann der Screenreader die angewählten Einzelnachweise nicht finden, weil das Popup am Ende der Seite angefügt wird, wo der Screenreader es nicht finden kann, durch das Zeigen des Popups beim Antippen aber auch der normale Sprung zur Liste der Einzelnachweise ausbleibt. (Die Hintergründe, die für Lightboxen gelten, sind auch hier relevant.)
Zur Barrierefreiheit gehört auch die Schriftgröße, und die ist im Popup deutlich kleiner als im normalen Text (10px vs. 13px), ohne dass es dafür einen vernünftigen Grund gibt.
Das in meinen Augen wichtigste Argument gegen das Gadget ist aber die Tatsache, dass es nicht mehr aktiv gepflegt wird. Der ursprüngliche Autor ist zwar noch aktiv, hat aber seit Jahren keine Fehlerbehebungen mehr durchgeführt. Das Gadget hier ist ein Fork des Originals, sodass eventuelle Verbesserungen nicht so einfach übernommen werden können. Es ist damit zu rechnen, dass in nicht allzu ferner Zukunft die interne Struktur der Einzelnachweise geändert wird, was dazu führen wird, dass das Gadget sie nicht mehr finden kann und damit nicht mehr funktionieren wird, sofern es nicht weiterentwickelt wird. --Schnark 10:14, 6. Feb. 2016 (CET)
Ich habe mir das mal angeschaut: also bei Touch-Bedienung kommt bei mir nicht das Pop-Up, sondern dieses "Slide-Out" am unteren Bildschirmrand; aber auch mit normaler Schriftgröße. Und das ist bei der deutschen Wikipedia bei Touch-Bedienung genauso wie bei der englischen. Es muss ja auch gar nicht unbedingt exakt wie in der englischen Wikipedia gelöst sein. Eine größere Schriftart (wie der noramle Fließtext) im Mouse-Over fände ich z.B. auch sehr gut. --79.224.83.32 12:40, 10. Feb. 2016 (CET)
Auf der mobilen Seite (en.m.wikipedia.org) wird das Gadget nicht geladen, und der Einzelnachweis wird am unteren Rand angezeigt, ja. Aber wenn du zur Desktop-Ansicht wechselst (Link dazu ist am Seitenende, ich verstehe zwar nicht, warum man das machen sollte, aber viele machen es), dann kommt das Gadget auch auf Mobilgeräten zum Einsatz. Und da ist es dann (vermutlich, das habe ich nicht getestet) unzugänglich für Screenreader und (zumindest für mich im Standard-Zoom) unlesbar klein. --Schnark 09:20, 11. Feb. 2016 (CET)

✔ Ja - Ich würde eine Umsetzung dieses praktischen Features sehr begrüßen. Wenn es da noch Probleme mit Usability oder Barrierefreiheit gibt (z.B. zu kleine Schriftgröße) dürfte das doch alles nichts sein, was sich nicht lösen lässt. Und wenn man das entsprechend umsetzt, ist es halt enorm praktisch und eine echte Erleichterung.--GB1974 (Diskussion) 20:27, 12. Feb. 2016 (CET)

✔ Ja – Sollte umgesetzt werden. Ich verstehe ehrlich gesagt gar nicht, wo das Problem ist. Das ist ja nur eine Zusatzfunktion bei Maus-Bedienung, die bei Touch-Bedienung und Screenreadern erst gar nicht bemerkbar ist und dort keinerlei Auswirkungen hat. Und auch bei Maus-Bedienung ist das ja ein zusätzlicher (!) Hover-Effekt, der nur bei Maus über der Fußnoten-Nummer sichtbar wird – das jetzige Verhalten, dass ein Klick auf die Fußnoten-Nummer zur entsprechenden Fußnote in der Fußnotenliste unten auf der Seite führt, bleibt vollständig erhalten und wird durch den Hover-Effekt nicht beeinträchtigt. -- 134.61.102.221 08:22, 29. Feb. 2016 (CET)

Und wie gesagt: bei Touch-Bedienung und Screenreadern merkt man erst gar nichts davon.-79.224.89.174 11:07, 29. Feb. 2016 (CET)

Angabe des Alters in Infobox bei Personen-Artikeln (wie in englischer Wikipedia)[Quelltext bearbeiten]

In der englischen Wikipedia wird bei Personen-Artikeln in der Infobox hinter dem Geburtsdatum das aktuelle Alter angezeigt (bzw. bei verstorbenen Personen hinter dem Todesdatum das Alter, in dem sie gestorben sind). So sieht man schnell (und an der immer gleichen, gewohnten Stelle) das Alter, ohne erst rechnen zu müssen bzw. bei verstorbenen Personen das Todesalter im Fließtext zu suchen (wo es auch nicht immer steht). Das wird ja vermutlich nicht immer händisch gemacht und aktualisiert, sondern geschieht automatisiert. Es wäre schön, wenn es dieses kleine, aber enorm praktische Feature auch in der deutschen Wikipedia gäbe. --79.224.81.242 17:31, 9. Jan. 2016 (CET)

Fände ich sehr nützlich, wenn man nicht immer rechnen müsste, sondern das aktuelle Alter gleich in der Infobox angezeigt bekäme. Hat sich ja auch in der englischen Wikipedia bewährt. --GB1974 (Diskussion) 09:21, 22. Jan. 2016 (CET)
✔ Ja - Bitte diese Erweiterung einführen. -- Sonne7 Disk!  13:20, 22. Jan. 2016 (CET)
✔ Ja – gute Idee!
--TOMM (Diskussion) 15:58, 22. Jan. 2016 (CET)
Infoboxen zu Personen sind in der deWP ausdrücklich nicht erwünscht. Menschen und ihr Leben lassen sich in aller Regel eben nicht in Schemata pressen. Ausnahmen gibt es bei Sportlern und Päpsten, sonst nicht. Deshalb wäre eine solche Änderung natürlich auch nur bei diesen sehr begrenzten Personengruppen möglich. Dann lohnt es sich aber eher nicht. Grüße --h-stt !? 16:03, 22. Jan. 2016 (CET)
Es geht wohl um die Zum-Beispiel-Sportler-Infoboxen.
--TOMM (Diskussion) 16:19, 22. Jan. 2016 (CET)

Links auf diese Seite[Quelltext bearbeiten]

Meinen Wunsch kann ich an einem Beispiel erklären: Leo Kerz erscheint heute auf der Wikipedia-Hauptseite in der Rubrik WP:SG?. Der interessierte Leser kann auch mal auf eine Artikelverlinkung drücken, um sich ein bißchen mehr zu informieren, vielleicht auch die Rotlinks bestaunen oder die Kategorien. Wenn wir ihn neugierig gemacht haben, könnte er vielleicht auch noch wissen wollen, in welchen Artikeln die Person erwähnt wird. Dafür könnte er die Funktion Links auf diese Seite aufrufen, wenn er denn wüsste, dass er da weiterkommt.
Nun kommt das Ergebnis (Stand heute): über einhundert Seiten sind mit dem Artikel verlinkt. Nur wo sind die wirklichen Artikel? Natürlich weiss der Leser, dass er jetzt in einem weiteren Schritt, die Namensraumvorgabe von „alle“ auf „(Artikel-)“ verändern muss und dann die Abfrage mit „Los“ erneut starten muss, oder er weiss es eben nicht.

Exkurs
Der Leser würde also auf die eine oder andere Weise erfahren, dass Leo Kerz mit Martha Jacob verlinkt ist, und sich sagen, aha, da schau her... . Bei Martha Jacob steht, dass die beiden drei Jahre lang verlinkt (verheiratet) waren. Davon stand bei Leo Kerz ja gar nichts... interessant, hat sich ja richtig gelohnt, da mal nachzufassen...

Ergo, bitte die Standardeinstellung in der Abfrage auf „(Artikel-)“ ändern.
Und ansonsten könnte für die Funktion vielleicht auch ein bisschen geworben werden, sie gehört eigentlich nicht zu den „Werkzeugen“, sondern zu den „Leserfunktionen“. Aber das ist dann schon wieder ein anderes Fass.
--Goesseln (Diskussion) 15:12, 26. Jan. 2016 (CET)

Wenn ich das nachsehe welche Seiten "hierher" linken dann interessieren mich meistens auch nur die Artikel und nicht der ganze Metakram. Allerdings gibt es einige Admins die nur eine sehr knappe Löschbegründung im Löschlogbuch angeben und noch anfügen "Siehe Links" was eienen dann zur Seite "Links auf diese (gelöschte) Seite" führt. (Beispiel.)Wenn dann standardmäßig der wikipedia-Namensraum ausgeblendet wird könnte das zu problemen bei weniger erfahrenen Leuten führen. --DWI (Diskussion) 16:38, 26. Jan. 2016 (CET)

Wäre es nicht, das sinnvollste, die Funktionalität der Suchfunktion zu übernehmen:

Enzyklopädische Artikel    Multimedia    Alles    Erweitert

--Diwas (Diskussion) 17:42, 26. Jan. 2016 (CET)

Bitte nicht die Standardeinstellung ändern. Ich halte den Link mehr für ein Werkzeug, und als solches sollte es auch standardmäßig alle Seiten anzeigen. Artikel, die im Zusammenhang mit dem aktuellen Artikel relevant sind, sind idealerweise in beide Richtungen verlinkt und beschrieben. Wenn nicht, hat das idR. gute Gründe. So steht bei irgendeinem Lokalpolitiker vielleicht ein Bezug zu einem Regierungschef, aber beim Regierungschef wird nicht jeder Lokalpolitiker genannt der jemals Kontakt zu ihm/ihr hatte. --mfb (Diskussion) 18:05, 26. Jan. 2016 (CET)

Zusammmenarbeit mit Suma e. V. (MetaGer) / Einbindung von MetaGer in Wikipedia[Quelltext bearbeiten]

Das Interesse für Wikipedia hat für mich „zur Folge“, dass ich mich auch für die freie „Wissensfindung“ und damit für MetaGer interessiere. (Das Projekt hat im April 20. Geburtstag.)

Wollte an dieser Stelle mal diskutieren, wie eine Zusammenarbeit der beiden Projekte aussehen könnte.


Hätte jemand eine Idee!?!


Viele Grüße --Molgreen (Diskussion) 11:16, 30. Jan. 2016 (CET)

Sprachen-Interwikilink abschnittspezifisch[Quelltext bearbeiten]

Ich wollte gerne einen Artikel, an dem auch ich mitgewirkt habe, mit seinem englischen Pendant verlinken. Dummerweise bekam ich eine Meldung, dieser sei bereits mit einem anderen deutschen Artikel verlinkt und dies sei daher nicht möglich. Nun haben allerdings zwei der Aspekte des englischen Begriffs „bulk density“ im Deutschen unterschiedliche Namen (der Aspekt Schüttdichte und der Aspekt Lgerungsdichte) und es ist vermutlich durchaus sinnvoll, auch zwei Artikel dafür zu haben. Könnte man nun „Lagerungsdichte“ mit „Bulk density#Soil“ und „Schüttdichte“ mit „Bulk density#Einführung“ verlinken, so könnten beide deutschen Artikel mit ihrem englischen Pendant verlinkt sein, ohne dass dort notwendigerweise ein Konvergenzproblem aufträte.

Eine andere Möglichkeit, ein Konvergenzproblem zu vermeiden wäre natürlich, im englischen Artikel unter Languages hinter Deutsch eine Klammer auf zu machen und eine anklickbare 1 und 2 hineinzuschreiben (so: Deutsch (1 2)).--Nix schlecht (Diskussion) 23:12, 2. Feb. 2016 (CET)

Artikel-Abrufstatistik[Quelltext bearbeiten]

Könnte man Seitenstatistiken nicht in die Wikipedia einbauen? Siehe bitte da.--just aLuser (Diskussion) 08:26, 3. Feb. 2016 (CET)

Themenportale fehlen auf mobiler Startseite[Quelltext bearbeiten]

Auf der mobilen Version der Startseite fehlen leider die Links zu den Themenportalen ("Gesellschaft", "Kunst und Kultur". etc.). Heutzutage sind doch auch bei mobiler Nutzung die Bandbreiten groß genug, dass man Seiten nicht mehr so spartanisch wie möglich gestalten muss. Auch bei den Bildschirmgrößen nutzt wohl kaum noch jemand Smartphones unter 4 Zoll. (Und scrollen muss man auch heute schon, um die ganze Startseite zu sehen.) Umgekehrt sind die Themen ein guter Startpunkt für die Leute, die nicht ganz konkret nach einem spezifischen Stichwort suchen, sondern sich einen Überblick über ein Thema verschaffen wollen und oft noch gar nicht wissen, nach welchen Stichwörtern man da alles suchen könnte. Ich fände es sehr nützlich, wenn die Themenportale nicht nur auf der klassischen Startseite verlinkt wären, sondern auch auf der mobilen Startseite.--137.226.116.99 13:46, 4. Feb. 2016 (CET)

Referenz-Auflösung in der Artikelvorschau beim Überfahren von Links[Quelltext bearbeiten]

Hallo, liebe Tekkies,

Als ich heute einen Artikel über Reinhold Messner las und dann mit der Maus über den Link "Ötzi" fuhr, um zu sehen, wann der gefunden wurde, war ich verwirrt: In dem Vorschau-Popup war ein auf den ersten Blick komischer Wortsalat, bis ich begriff, dass dort ein Referenz-Link, der in der Einleitung war, aufgelöst und mit in die Vorschau integriert wurde. Ich weiß nicht, ob man das technisch unterbinden kann. Das wäre wahrscheinlich einfacher als eine Richtlinie zu erlassen, dass in der Einleitung keine Referenzen sein sollten.

Einen schönen Abend --Hlambert63 (Diskussion) 19:19, 12. Feb. 2016 (CET)

Das ist ein Problem mit Wikipedia:Helferlein/Navigation-Popups. Das ist ein Gadget, das von freiwilligen Programmierern in der englischsprachigen Wikipedia entwickelt wurde. Fehlermeldungen müssen dementsprechend unter en:Wikipedia talk:Tools/Navigation popups gemeldet werden. Allerdings gibt es derzeit keinen, der das Skript noch aktiv pflegt, sodass es unwahrscheinlich ist, dass der Fehler behoben wird, selbst wenn du ihn dort meldest. --Schnark 10:16, 13. Feb. 2016 (CET)

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)

Darstellung von Tabellen auf mobilen Geräten / Stacked Tables[Quelltext bearbeiten]

Es wäre schön, wenn bei kleinen Bildschirmen Zellen von breiten Tabellen nicht mehr neben- sondern untereinander angezeigt werden würden. Siehe z.B. http://exisweb.net/responsive-table-plugins-and-patterns bzw. http://johnpolacek.github.io/stacktable.js/ --Sinuhe20 (Diskussion) 11:11, 20. Feb. 2016 (CET)

Benachrichtigungen[Quelltext bearbeiten]

In den "Einstellungen" kann ich mich mit "Seitenverlinkung" benachrichtigen lassen, wenn ein Link auf einen von mir jemals erstellten Artikel erfolgt. Nun bin ich schon lange dabei, habe anfangs viele Artikel angelegt die mich heute kaum noch interessieren (z.B. Bayer AG). Daher wünsche ich mir eine Option "Seitenverlinkung", wenn der verlinkte Artikel in meiner Beobachtungsliste enthalten ist. --tsor (Diskussion) 12:01, 22. Feb. 2016 (CET)

Falls es nicht um die E-Mail-Benachrichtigung geht, hätte ich ja eine andere Idee: Zu jedem Artikel sollte automatisch ein Verlinkungslogbuch geführt werden und in der Beobachtungsliste sollten optional die aktuellen Neueinträge der beobachteten Artikel mit aufgeführt werden. --Diwas (Diskussion) 12:14, 22. Feb. 2016 (CET)

Spaltung der Wikipedia in Repository und freier Kompilation[Quelltext bearbeiten]

Idee: Wir trennen die Wikipedia auf in eine Repository das die Inhalte enthält, und einer freien Kompilation dieser Inhalte. Im Repository kann grundsätzlich über alles geschrieben werden. Auch über "Hasans Dönerbude". Verschiedene von jedermann erstellbare Ausgaben dieser Inhalte definieren einfach nur noch welche Artikel und welche Teile eines Artikels sie in ihre Ausgabe aufnehmen wollen. So könnte unter der bisherigen Internetadresse von Wikipedia eine Ausgabe erstellt werden, die ihr bisherigen Ausrichtung entspricht. Aber es ist auch vorstellbar, dass jemand eine Ausgabe erstellt die nur kurioses enthält. Oder jemand kompiliert ne Wikipedia, die ellenlange Artikel auf das wichtigste kürzt. Oder mehrere Ausgaben mit der derselben Zielsetzung entstehen und die bessere Ausgabe setzt sich durch. --Uranus95 (Diskussion) 18:04, 26. Feb. 2016 (CET)

Alle Inhalte stehen unter einer Freien Lizenz. Du kannst jederzeit (d)ein eigenes Repositum ausgewählter, gekürzter, abgewandelter und so weiter Artikel erstellen. Nur den guten Namen "Wikipedia" darfst du dafür nicht benutzen. Denn den hat sich "Die Wikipedia" erarbeitet. Mit genau dem Konzept, das du hier in Frage stellst. Grüße --h-stt !? 18:31, 26. Feb. 2016 (CET)
Ein Fork stirbt sofort an Arbeitsaufwand, Veränderungen der Wikipedia bei sich einzupflegen. Es ist viel zu aufwändig mehrere Wissenbasen zu pflegen. Ich finde die Idee ziemlich gut. Der User kann dann selbst entscheiden ob er auch Informationen sehen will, die nicht in einer Kompilation stehen, die auf Vertrauenswürdigkeit optimiert ist. --Uranus95 (Diskussion) 19:13, 26. Feb. 2016 (CET)
Jeder kann sozusagen ein eigenes „Repository“ mit Artikelentwürfen auf seiner Benutzerseite erstellen. Und mit der Wikimedia API ist es möglich auf seiner Webseite mit den bisherigen Inhalten anzustellen was man will.--Sinuhe20 (Diskussion) 18:40, 26. Feb. 2016 (CET)

Inuse-Markierungen[Quelltext bearbeiten]

Hallo zusammen, weil dies immer wieder passiert und richtig ärgerlich ist: Man setzt einen inuse-Baustein in einen Artikel und trotzdem bearbeiten Kollegen den Artikel, weil er auf einer aktuellen Fehlerliste (z.B. orthographische Fehler) gelistet ist. Diesen Kollegen wird der inuse-Hinweis aber nicht angezeigt, so dass sie, ohne Böses zu wollen, den inuse missachten und dem am Text arbeitenden User nun erheblich Arbeit machen können. Kann nicht auf solchen Fehlerlisten auch ein kleiner Hinweis auf den inuse gesetzt werden, wenn das technisch irgendwie möglich ist. Danke schon mal, --Geolina mente et malleo 17:39, 28. Feb. 2016 (CET)

Auf welchen Fehlerlisten? Wieso (und wem, wo) wird der inuse-Hinweis nicht angezeigt? --mfb (Diskussion) 23:34, 28. Feb. 2016 (CET)
Ich habe Benutzer:HerrAdams gebeten, die Fehlerliste über die er in den Artikel gelangt ist, bitte hier zu verlinken. ggf. könnte ich auch noch andere Benutzer anfragen, denen es genauso ergangen ist. --Geolina mente et malleo 14:59, 29. Feb. 2016 (CET)
Hallo, es war diese Fehlerliste des Benutzers Aka. --HerrAdams (Diskussion) 18:16, 29. Feb. 2016 (CET)
Keine Chance. Wenn der Inuse-Baustein in die Seite eingefügt wird nachdem die Listen erstellt werden, können diese Listen das nicht "wissen". Falls er vorher schon da war (seltenst), könnte Akas Bot das ggf. berücksichtigen, aber da müsstet ihr ihn direkt fragen. Das müssen die Bearbeiter im Artikel selbst sehen - und falls sie es nicht sehen, muss eben später der Bearbeitungskonflikt aufgelöst werden. --mfb (Diskussion) 20:06, 7. Mär. 2016 (CET)
Man könnte aber eine Editnotice bekommen, wenn man einen Artikel bearbeitet, in den die Inuse-Vorlage eingebunden ist. --Jobu0101 (Diskussion) 20:29, 7. Mär. 2016 (CET)
Das wäre vorstellbar. Ich bezweifle aber, dass eine solche Softwareänderung hohe Priorität bekäme. --mfb (Diskussion) 21:12, 7. Mär. 2016 (CET)
Könnte man vorläufig in JS programmieren und über common.js individuell einfügen. --Jobu0101 (Diskussion) 22:26, 7. Mär. 2016 (CET)
Achso, dann binden es gerade die Nutzer, die die Inuse-Markierung missachten, nicht ein. Individuelles JS ist also keine gute Lösung. --Jobu0101 (Diskussion) 22:28, 7. Mär. 2016 (CET)

Neue längere IP-Nummern[Quelltext bearbeiten]

Die haben leider zur Folge, dass sie in ein dafür vorgesehenes Feld nicht mehr vollständig hineinpassen, wodurch öfter mal ein paar Bytes verloren gehen, und zwar auf der jeweilgen Seite "Benutzerbeiträge"! Gruß -- Dr.cueppers - Disk. 15:38, 7. Mär. 2016 (CET)
Das sind WP:IPv6. Es gibt in Zusammenfassungszeilen beim Zurücksetzen mal Probleme. Wo hast du abgeschnittene Texte noch gesehen? Der Umherirrende 18:56, 7. Mär. 2016 (CET)

Sortierung in Tabellen (Wikidata-IDs)[Quelltext bearbeiten]

Könnte die JS-Sortierung in Tabellen etwas intelligenter gestaltet werden, so dass auch nach Wikidata-IDs automatisch richtig sortiert wird? Sie müssen dafür als Zahlen, nicht als String erkannt werden. Weil aber ein Q vor der eigentlichen Zahl steht, werden sie bislang als String erkannt. Hier ein Beispiel, bei dem man schön die falsche Sortierung sehen kann und hier ein Beispiel, bei dem richtig sortiert wird, weil mit data-sort-value="..." gearbeitet wurde (sehr umständlich, das immer einzuarbeiten). --Jobu0101 (Diskussion) 09:09, 8. Mär. 2016 (CET)

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)

„Self-Checkuser“-Rechte[Quelltext bearbeiten]

Hallo.

Vor etwa einem Jahr habe ich auf WP:A/A eine IP-Sperre-Ausnahme beantragt, da andere Schüler vom Computerraum aus Vandalismus auf Wikipedia ausgeübt haben.
Ich bin in letzter Zeit leider schon wieder unschuldigerweise auf Problemen mit Checkusern gestoßen.

In der englischsprachigen Wikipedia wurde mein Account daher vom CheckUser Bbb23 gesperrt, da mir vorgeworfen wurde, schädliche Bearbeitungen als IP-Addresse durchgeführt zu haben.
Auf meiner Diskussionsseite habe ich einmal nachgefragt, unter welchen IP-Addressen, bei denen ich eingeloggt war, Vandalismus durchgeführt wurde. Diese Frage schien dort jedoch irrelevant, und wurde einfach überschrieben.

Mir wurde dort außerdem gedroht, den Zugriff auf meiner eigenen Diskussionsseite zu verweigern.
Es ist möglich, dass über IP-Addressen, mit denen ich auf der Deutschen Wikipedia eingeloggt war, ebenfalls vandaliert wurde. Daher riskiere ich mit dieser Nachricht, in der deutschsprachigen Wikipedia ebenfalls von einem Checkuser gesperrt zu werden.

Daher schlage ich ein Benutzerrecht vor, womit man die Checkuser-Logbücher des eigenen Accounts durchlesen kann.

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

Da bin ich klar dagegen. Ich hoffe doch sehr, dass jeder selber weiß wie er in Wikipedia eingeloggt ist. Für die die es nicht wissen, wird auch das selbstcheckusern nicht mehr helfen. Nachteile gibt es aber zuhauf: oft teilen sich viele Benutzer die selbe IP, oder selbe IP wandert von Benutzer zu Benutzer. Ohne Überprüfung besteht die Gefahr, dass du die Einstellungen fremder Konten siehst, die dich nichts angehen. Frohes Schaffen — Boshomi Defekte URLs - Hilfe mit!  23:03, 28. Apr. 2016 (CEST)
@Boshomi: welche Einstellungen?
Die IPs zu eigenen Beiträgen zu sehen wäre noch vorstellbar, Aktionen anderer mit diesen IPs sehen (insbesondere Accounterstellungen) geht nicht, abgesehen von dem was ohnehin schon zu IP-Aktionen öffentlich ist. Ich würde erwarten, dass ein CU die betroffenen IPs auflistet, wenn man ihn fragt, aber ein Recht darauf hast du wohl nicht. --mfb (Diskussion) 23:55, 28. Apr. 2016 (CEST)
Mein Vorschlag bestand eigentlich lediglich darin, zu sehen, in welchen IP-Addressen ich mich eingeloggt habe, und durch welcher IP-Addresse ich bearbeitet habe. ––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)