Wikiup:Verbesserungsvorschläge/Archiv/2016/März

aus Wikipedia, der freien Enzyklopädie

Beobachtungen in der Beobachtungsliste entfernen

Warum kann man eigentlich Einträge in der Beobachtungsliste nicht direkt entfernen? --Sinuhe20 (Diskussion) 22:49, 7. Mär. 2016 (CET)

Würden zu viele aus Versehen draufklicken denke ich. Mit den Navigationspopups (Einstellungen -> Helferlein) ist es möglich. --mfb (Diskussion) 23:21, 7. Mär. 2016 (CET)
Vor schätzungsweise mehr als 5 Jahren gab es mal ein entsprechendes Script, das einen Link zum Entfernen neben jedem Eintrag auf der Liste hinzugefügt hat. Das funktioniert aber schon lange nicht mehr. Und fragt mich bitte nicht, wo man das finden könnte, ich habe es irgendwann aus meiner monobook.js entfernt. XenonX3 – (☎) 23:28, 7. Mär. 2016 (CET)
Ah gut, die Lösung mit den Navigationspopups reicht mir schon aus…--Sinuhe20 (Diskussion) 08:00, 8. Mär. 2016 (CET)

@Sinuhe20, XenonX3: Ich darf mal Benutzer:PerfektesChaos/js/listPageOptions anempfehlen.

LG --PerfektesChaos 10:38, 8. Mär. 2016 (CET)

Klasse, funktioniert! XenonX3 – (☎) 16:46, 8. Mär. 2016 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: XenonX3 – (☎) 16:46, 8. Mär. 2016 (CET)

Neue längere IP-Nummern

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)

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)

Darstellung der Aktualität eigener Beiträge

Gemeldet in Phabricator
Task T130824

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

@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

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)

Direkte Seitenanwahl bei Suchergebnissen

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)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup:Verbesserungsvorschläge/Archiv/2016/März&oldid=156455321“