Wikipedia Diskussion:Projektneuheiten/Archiv/2018
TemplateStyles
@Raymond: Hast Du einen Überblick, wie der aktuelle Stand in Sachen mw:Extension:TemplateStyles ist. Wann kann man mit diesem Feature hier-zu-wiki rechnen? Ich hätte dafür zig Anwendungsfälle (gerade wieder im WP:Tutorial) und bräuchte es eher heute als morgen. // Martin K. (Diskussion) 10:38, 11. Jan. 2018 (CET)
- @Martin Kraft: Es scheint schon möglich zu sein. Phab:T133410 ist der allgemeine Task für Aktivierung WMF-weit, dazu hat sv.wiki über Phab:T176082 einen Aktivierung für sich beantragt. Es wird jetzt noch auf das OK eines WMF-Mitarbeiters gewartet. Ich würde daher sagen, wir sollten hier die Initiave ergreifen, und nach lokaler Umfrage (ein formales MB halte ich für unnötig, da die Community keine Nachteile hat, oder?) auch einen Task zur hiesigen Aktivierung erstellen. Meine Unterstützung hast du für eine Umfrage. — Raymond Disk. 10:55, 11. Jan. 2018 (CET)
- Ok, dann lass uns das am Wochenende mal in Angriff nehmen. // Martin K. (Diskussion) 11:02, 11. Jan. 2018 (CET)
Checkuser und Stewards können nun private Daten im Missbrauchsfilter-Logbuch einsehen
Hi, welche privaten Daten sind denn das und seit wann werden überhaupt beim Missbrauchsfilter-Log private Daten erhoben? Wäre nicht das die wahre Neuheit? Nicht wer sie wie einsehen kann? --h-stt !? 20:19, 21. Feb. 2018 (CET)
- ich gehe nach lektüre von T160357 davon aus, dass nunmehr CUs und stewards accounts zugeordnete IP-adressen einsehen können; dies wird jedoch wie ein sonstiger CU-eingriff protokolliert (und wird dann wohl auch nur im rahmen von CUAs eingesetzt; so mein verständnis - alles andere wäre eieieiei [ich überlasse das finden passender skandalbegrifflichkeiten an dieser stelle anderen]). --JD {æ} 20:25, 21. Feb. 2018 (CET)
- Es werden dieselben Daten erhoben wie bei jedem Edit, so sehe ich da kein Problem. Die technische Neuerung ist nur, das das jetzt geloggt wird. Vorher war das nicht der Fall. Allerdings war das auch der Grund, warum CUs und Stewards vorher nicht die Daten einsehen konnten und durften. Viele Grüße, Luke081515 20:34, 21. Feb. 2018 (CET)
- OK, danke. Wenn es um die IP geht und das wie ein CU dokumentiert wird, ist das für mich völlig OK. Grüße --h-stt !? 21:20, 21. Feb. 2018 (CET)
- Ja genau. Es geht halt darum die Daten wie im Normalfall mit "normalen CU" zu nutzen. Nur da ja der Edit teilweise unterbunden wurde, gab es da vorher keine Daten, was dann problematisch sein kann. Das stopft das jetzt im Prinzip. Viele Grüße, Luke081515 22:12, 21. Feb. 2018 (CET)
- Praktisch und neu ist auch, dass auch die IPs von vom MBF verbotenen Aktionen erfasst werden, zum Beispiel verbotene Bearbeitungen oder fehlgeschlagene Anlagen von Benutzerkonten. --MGChecker – (📞| 📝| ) 01:11, 22. Feb. 2018 (CET)
- Ja genau. Es geht halt darum die Daten wie im Normalfall mit "normalen CU" zu nutzen. Nur da ja der Edit teilweise unterbunden wurde, gab es da vorher keine Daten, was dann problematisch sein kann. Das stopft das jetzt im Prinzip. Viele Grüße, Luke081515 22:12, 21. Feb. 2018 (CET)
- OK, danke. Wenn es um die IP geht und das wie ein CU dokumentiert wird, ist das für mich völlig OK. Grüße --h-stt !? 21:20, 21. Feb. 2018 (CET)
- Es werden dieselben Daten erhoben wie bei jedem Edit, so sehe ich da kein Problem. Die technische Neuerung ist nur, das das jetzt geloggt wird. Vorher war das nicht der Fall. Allerdings war das auch der Grund, warum CUs und Stewards vorher nicht die Daten einsehen konnten und durften. Viele Grüße, Luke081515 20:34, 21. Feb. 2018 (CET)
Zusammenfassungszeile 2.3.2018
Siehe dazu Kommentare auf WP:FzW#Zusammenfassungszeile? -jkb- 21:59, 2. Mär. 2018 (CET)
- Was dür ein Quatsch, dass ohne weitere Vorbereitungen und Maßnahmen in diesem Umfang einfach so auf die Benutzer zu schmeißen. Soweit ich weiß, war das eigentlich nie so gedacht, imho ist das ein Fehler bei der Umstellung der Versionstabelle in der Datenbank auf das neue Schema. Die Zusammenfassungen sind in vielen Fällen zu kurz, aber das was hier geschehen ist ist keine Problemlösung. Es sollte ein anständiges Limit (auf jeden Fall weniger als 500 Zeichen) geben, wobei die Standardtexte ausgenommen sind und internationalisierbar als json gespeichert werden. Mein Senf dazu, jetzt guck ich mal auf Phab. --MGChecker – (📞| 📝| ) 00:12, 3. Mär. 2018 (CET)
- → phab:T188798 Sehe ich genauso. -- User: Perhelion 02:10, 3. Mär. 2018 (CET)
- Ich seh das völlig anders. Ich halte die Neuerung für sehr sinnvoll. Es ist blinder Aktionismus, das jetzt schnell über Nacht wieder rückgängig machen zu wollen. -- Chaddy · D 02:56, 3. Mär. 2018 (CET)
- Es ist viel sinnvolles daran, aber es ist blinder Aktionisimus ohne jegliche Diskussion über ein geeignetes Zeichenlimit oder die Umsetzung in verschiedenen Sprachen einfach einen Change über Nacht zu mergen, über den zuvor nie gesprochen wurde. Man muss erstmal nachdenken, bevor man was ändert. --MGChecker – (📞| 📝| ) 03:14, 3. Mär. 2018 (CET)
- Entschuldige mein Englisch, ich spreche kein Deutsch.
- Hello. The Wikimedia Foundation’s Community Wishlist team has been reading this discussion (and others on different wikis) and believes that 255 bytes is too short for some edit summaries and 1,000 characters is too long. We want to set an agreeable number. We propose 500 characters. We plan to make this change in the coming weeks, and our work can be tracked at phab:T188798.
- Our current plan is to leave the underlying database change in place (making changes to the database is possible, but requires much more time and work and affects all wikis) but change the ‘Zusammenfassung’ text input box in all supported editors (e.g. VisualEditor, wikitext editor, new wikitext editor, mobile editor) enforce the 500 character limit.
- Danke schön. — TBolliger (WMF) (Diskussion) 22:26, 12. Mär. 2018 (CET)
"In der Nähe" ohne Beschreibungen
Seit etwa 15. Februar erscheint unter Spezial:In der Nähe nicht mehr die Wikidata-Beschreibung. Das ist sehr schade, z.B. im Ausland ist das sehr hilfreich wenn einem der Begriff nichts sagt, oder im Inland um zu erkennen wo noch wenig Daten verfügbar sind. Wurde das mit Absicht geändert, kann man das irgendwie rückgängig machen? Gibt es eine Diskussion dazu? Auf WP:FZW hat sich bisher auch niemand dazu geäußert. --Gerd Fahrenhorst (Diskussion) 09:00, 23. Feb. 2018 (CET)
- Scheint seit ca. Anfang KW 11/2018 wieder zu funktionieren. Also Erledigt. -- Gerd Fahrenhorst (Diskussion) 11:01, 16. Mär. 2018 (CET)
Nachdem ich gestern mit großem Erschrecken bemerkt habe, dass die von mir angelegte Hilfeseite zum VisualEditor, die die Bearbeitung der Notenschriftfunktionen beschreiben soll, völlig zerstört dargestellt wurde, weil etliche Funktionen verändert wurden, was auch die nachgestellte Ausgabe der Dialogfelder betrifft, sprich Interlanguagemessages wie notelanguage → „⧼Score-visualeditor-mwscoreinspector-notelanguage⧽“ die hinzugekommen ist und MIDI → ⧼Score-visualeditor-mwscoreinspector-card-midi⧽ was plötzlich zu einer fehlerhaften Ausgabe führt und somit die Hilfeseite nicht mehr dem entspicht was tatsächlich passiert … … … Bin ich ratlos wie ich das richten soll.
- Ich bin absolut unmusikalisch, kann diese Notensätze weder lesen noch erstellen
- Was ist sehe ist jedoch, dass man im VisualEditor gar nicht die Möglichkeit hat die ausgegebene Notensatzgrafik anzuklicken, da sich diese ja innerhalb einer Art Vorlage befindet, nämlich dem umschließenden score. = nichts mit einem auftauchenden Dialogfeld mit den beiden Optionen MIDI-Datei herunterladen • LilyPond-Datei herunterladen
- Ist diese Option oder das Attribut
<score midi="1">
noch wirksam??? Und wenn ja, wie lässt sich das nun nach den Änderungen mit dem VisualEditor zu bedienen? - Wie kommt der VE-Bearbeiter an die Downloads???
Und zur Neuerung vom 19. Januar
- Was hat es mit diesen Sprachangaben auf sich?
- Ein verstellen der Angabe in einem funktionierenden Datensatz erzeugt Fehler, ich weiß nicht einmal worauf sich diese Sprachangabe beziehen soll, geschweige denn wie ich diese Funktion nun verständlich beschreiben sollte. Bezieht es sich auf den Liedtext, auf die Noten selbst, also cdefgahhc oder was soll diese Sprache ändern?
- Ich bin völlig hilflos, ich verstehe diese Funktionen nicht es wir immer einfach irgendetwas angeblich supertolles hier ausgekippt und andere können dann sehen wie sie das wieder richten.
Grummel ich bin echt knurrig, wird so etwas überhaupt vorher für alle Eventualitäten getestet oder stelle ich mich zu dusselig an, dass ich als musikalische Laiin hier völlig auf verlorenem Posten stehe aber die Hilfeseite doch irgendwie wieder reparieren muss, damit sie das beschreibt was der VE-Benutzer dort sieht.
- die völlig zerschossene Version von gestern
- die derzeitige Version → ich hoffe ich habe nichts übersehen
@Raymond: kannst du mir dazu etwas sagen? --Liebe Grüße, Lómelinde Diskussion 08:23, 23. Mär. 2018 (CET)
- @Lómelinde: Nur ein paar wenige Antworten, da score für mich auch etwas fremd ist.
- 1. *Im* VE steht der Download auch nicht zur Verfügung. Nur im Lesemodus und das finde ich auch sinnvoll.
- 2.
<score midi="1">
scheint es laut mw:Extension:Score weiterhin zu geben. Selber aber nicht getestet. - 3. Welche Funktion die Notationssprache hat, weiß ich als Nicht-Komponist leider auch nicht. Gerade einige Einstellungen durchprobiert, mache Notationen sind danach kaputt, vermutlich weil die Notationssprache nicht mehr passt. Da muss mal ein Musiker ran. — Raymond Disk. 14:16, 23. Mär. 2018 (CET)
- Dankeschön. Ich habe auch mehr Fehlerfälle als alles andere produziert, wirklich benutzerfreundlich scheint das noch nicht zu sein. --Liebe Grüße, Lómelinde Diskussion 14:29, 23. Mär. 2018 (CET)
500 Zeichen
Im neuen Bearbeitungskommentar-Feld stehen nun an der recht Seite die Anzahl der noch nicht verbrauchten Zeichen. Nett aber überflüssig, außer man legt es darauf aus, das Limit auszuschöpfen. Das ganze hat aber scheinbar einen Preis:
- Das Dropdown der gespeicherten Kommentare funktioniert nicht mehr. Anstatt 2-3 Zeichen einzugeben um den passenden Eintrag aus dem Dropdown zu wählen, muss man nun jeden Text jedes mal neu eingeben.
Für Leute die viele kleine edits mit relativ standardisierten Editkommentar machen, ist das eine echte Belastung. Frohes Schaffen — Boshomi ⌨ 21:52, 3. Apr. 2018 (CEST)
- Die Zeichenanzeige gibt es schon lange, die gab es, wenn ich mich richtig erinnere, auch schon, als die Zusammenfassungszeile noch auf 255 Zeichen begrenzt war.
- Diese Funktion funktioniert bei mir weiterhin einwandfrei. Sie ist aber ohnehin nicht von der MediaWiki-Software, sondern vom Browser abhängig. -- Chaddy · D 21:59, 3. Apr. 2018 (CEST)
- Ich verwende einen der häufigst verwendeten Standardbrowser, aber seit heute funktioniert es nicht mehr. :-( Frohes Schaffen — Boshomi ⌨ 23:28, 3. Apr. 2018 (CEST)
- Im FireFox geht es, ging aber eigentlich immer nur bis zu einer bestimmten Anzahl an Zeihen, sowohl bei Überschriften als auch in der Zusammenfassungszeile. Wenn man da über eine bestimmte Anzahl hinausging kamen diese Einträge nicht als Angebot. Vielleicht hast du versucht eine zu lange Zusammenfassung erneut zu verwenden. Ich weiß nicht wo das Limit liegt, aber ich vermute das sind genau 200 Zeichen, weil diesen Vorschlag
- [[Kategorie:Wikipedia:Defekte Weblinks/Ungeprüfte Archivlinks 2018-04]] [[Kategorie:Wikipedia:Defekte Weblinks/Ungeprüfte Botmarkierungen 2018-04]] [[Kategorie:Wikipedia:Weblink offline IABot]] fixed
- oder diesen
- [[Spezial:LintErrors/deletable-table-tag|Tabellensyntaxfehler]] verschachtelte Tabellen und bitte die veraltete Tabellensyntax ersetzen keine [[Hilfe:Tabellen/prettytable|prettytable]], kein bgcolor …
- habe ich noch in meiner Auswahl, der Restbetrag steht auf genau
300
. So gesehen ist die Anzeige schon wichtig, gerade auch, wenn man wiederverwendbare Zusammenfassungen benutzen möchte. --Liebe Grüße, Lómelinde Diskussion 07:23, 4. Apr. 2018 (CEST)
- Im FireFox geht es, ging aber eigentlich immer nur bis zu einer bestimmten Anzahl an Zeihen, sowohl bei Überschriften als auch in der Zusammenfassungszeile. Wenn man da über eine bestimmte Anzahl hinausging kamen diese Einträge nicht als Angebot. Vielleicht hast du versucht eine zu lange Zusammenfassung erneut zu verwenden. Ich weiß nicht wo das Limit liegt, aber ich vermute das sind genau 200 Zeichen, weil diesen Vorschlag
- Ich verwende einen der häufigst verwendeten Standardbrowser, aber seit heute funktioniert es nicht mehr. :-( Frohes Schaffen — Boshomi ⌨ 23:28, 3. Apr. 2018 (CEST)
Rechte-Logbuch
Kann man bitte die Dankeschöns für eine „automatische Rechtevergabe“ deaktivieren. Wem soll denn da das Dankeschön zukommen, dem Neusichter? Also quasi danke, dass deine Seiten jetzt nicht mehr nachgesichtet werden müssen? Finde ich etwas merkwürdig, ginge das auch bei einer Rückstufung, also wenn jemandem die Schreibrechte entzogen wurden? Könnte man sich dafür wirklich bei dem ausführenden Admin bedanken? Also beispielsweise so etwas?
- 20:32, 9. Okt. 2015 [Admin] (Diskussion | Beiträge) änderte die Gruppenzugehörigkeit für [Benutzer] von Passiver Sichter zu (–) (Missbrauch) (danken)
Ich weiß nicht so etwas finde ich nicht wirklich toll. Ich denke dieses Logbuch sollte wieder aus der Dankefunktion entfernt werden, auch wenn ich mich jetzt endlich mal bei dem Admin nachträglich bedanken konnte, der mir einstmals meine Sichterrechte anvertraute. Irgendwie musste ich es ja testen. Falls das also bleiben sollte, kann mir dann bitte jemand verraten, wie da die Icons aussehen würden, die in den Echobenachrichtigungen angezeigt werden? Ist das dieses Männchen? --Liebe Grüße, Lómelinde Diskussion 09:50, 6. Apr. 2018 (CEST)
- Task erstellt. Zu den Icons kann ich dir leider nichts sagen. — Raymond Disk. 10:13, 6. Apr. 2018 (CEST)
- Dankeschön. --Liebe Grüße, Lómelinde Diskussion 10:21, 6. Apr. 2018 (CEST)
Kartographer: Direkte Karteneinbindung
Laut aktueller Nachricht der WMF (Turn mapframe for English Wikipedia? We’re ready if you are) haben nun die WMF-Entwickler wieder Kapazitäten, mapframe für weitere Wikis zu aktivieren. Hierzuwiki müssten wir dazu einen Konsens, den ich sehr befürworten würde, herstellen. — Raymond Disk. 13:50, 7. Apr. 2018 (CEST)
- Her damit. Marcus Cyron Reden 14:05, 7. Apr. 2018 (CEST)
- Siehe dazu auch Wikipedia:Technik/Werkstatt#Interaktive_Karten_auf_Wikipedia --Crazy1880 14:19, 7. Apr. 2018 (CEST)
- Die direkte Kartographer-Karteneinbindung ist ein sehr nützliches Werkzeug, das wir auf Wikivoyage schon seit mehreren Jahren einsetzen. Und wir kümmern uns auch im Rahmen unserer Möglichkeiten um die Weiterentwicklung. Geheimtipp: Im Wikivoyage-Modus gibt es noch mehr Features. --RolandUnger (Diskussion) 21:05, 7. Apr. 2018 (CEST)
- Je intensiver diese Werkzeuge genutzt werden, um so sicherer wird auch die zukünftige Unterstützung durch die Wikimedia Foundation. --RolandUnger (Diskussion) 21:07, 7. Apr. 2018 (CEST)
- Moin Moin @RolandUnger:, gibt es Erfahrungen in der Einbeziehnung von Wikidata zu diesem Thema? Bzw. gibt es auf Wikivoyage ein Beispiel für diese Einbeziehung? mfg --Crazy1880 21:16, 7. Apr. 2018 (CEST)
- Je intensiver diese Werkzeuge genutzt werden, um so sicherer wird auch die zukünftige Unterstützung durch die Wikimedia Foundation. --RolandUnger (Diskussion) 21:07, 7. Apr. 2018 (CEST)
- Die direkte Kartographer-Karteneinbindung ist ein sehr nützliches Werkzeug, das wir auf Wikivoyage schon seit mehreren Jahren einsetzen. Und wir kümmern uns auch im Rahmen unserer Möglichkeiten um die Weiterentwicklung. Geheimtipp: Im Wikivoyage-Modus gibt es noch mehr Features. --RolandUnger (Diskussion) 21:05, 7. Apr. 2018 (CEST)
- Siehe dazu auch Wikipedia:Technik/Werkstatt#Interaktive_Karten_auf_Wikipedia --Crazy1880 14:19, 7. Apr. 2018 (CEST)
- Ja, indirekt. Wir beziehen für verschiedene Einrichtungen Daten aus Wikidata, auch die Koordinate und die Art der Einrichtung, siehe z. B. Wernigerode. Vielmehr beziehen wir Daten von OpenStreetMap (OSM) und Wikimedia Commons. Hier erhalten wir Konturen für Grenzen, aber auch für Streckenführungen von öffentlichen Verkehrsmitteln, siehe z. B. Vorlage:Mapshape. Wikidata selbst eignet sich gar nicht so gut für die Speicherung von Kartendaten, deshalb die Speicherung als GeoJSON auf Commons. Auf Wikidata speichern wir den Rückbezug auf OSM Relations. Da diese instabil sind, fragen wir die OSM-Datenbank, ob sie eine entsprechende Wikidata-Id kennen. Nützlich wiederum ist Wikidata, wenn wir z. B. ganze Verkehrsnetze abfragen. Hier wird z. B. in Qaṣr en-Nīl mit einer Wikidata-Abfrage über Q685381 das gesamte Kairoer Metronetz eingeblendet. --RolandUnger (Diskussion) 21:34, 7. Apr. 2018 (CEST)
Danken für Logbuchaktionen
„Das Danken ist nun auch für Logbuchaktionen möglich, die eine Version erzeugen (beispielsweise Artikel verschieben, nicht aber Benutzer sperren“ heißt es umseitig. Das ist entweder falsch oder missverständlich formuliert. Ich kann mich auch für Seitenlöschungen bedanken, oder für Seitenschutze niemals existierender Seiten, siehe Spezial:Log. Bug oder Feature? Gruß --Schniggendiller Diskussion 23:47, 8. Apr. 2018 (CEST)
- So oder so sehr schön. Marcus Cyron Reden 23:53, 8. Apr. 2018 (CEST)
- So schwierig ist das doch nun wirklich nicht, man kann sich für alle Logbuchaktionen bedanken, die eine Version in der Versionsgeschichte auslösen, nur für eine Aktion geht das bewusst nicht und das sind explizit „Benutzersperrungen“. Du kannst dich zwar indirekt für die Sperrung der Benutzer- oder der Benutzerdiskussionsseite durch einen Admin bedanken
- [Erstellen=Nur Administratoren] (unbeschränkt) (Diskussionsseite eines unbeschränkt gesperrten Benutzers) (Versionen) (danken)
- nicht jedoch für den Eintrag in das Benutzersperrlogbuch. Da gibt es kein (danken) Gleiches gilt auch für die Erstellung eines neuen Benutzerkontos.
- Im Allgemeinen kannst du das auch hier →Hilfe:Echo/Danke#Wofür kann gedankt werden? nachlesen. --Liebe Grüße, Lómelinde Diskussion 08:41, 9. Apr. 2018 (CEST)
- So schwierig ist das doch nun wirklich nicht, man kann sich für alle Logbuchaktionen bedanken, die eine Version in der Versionsgeschichte auslösen, nur für eine Aktion geht das bewusst nicht und das sind explizit „Benutzersperrungen“. Du kannst dich zwar indirekt für die Sperrung der Benutzer- oder der Benutzerdiskussionsseite durch einen Admin bedanken
[TWS] Notification from edit summary
Hallo,
Die Möglichkeit, andere Benutzer in den Bearbeitungszusammenfassungen zu benachrichtigen, wird im Laufe der Woche, ab dem 15. März, verfügbar sein. Andere Benutzer können dann benachrichtigt werden, so als ob deren Name auf einer Diskussionsseite erwähnt wurde, indem ein Wiki-Link zu deren Benutzerseite in der Bearbeitungszusammenfassung eingefügt wird. Du kannst in Deinen Einstellungen ändern wie Du diese Erwähnungsbenachrichtigungen erhältst. Diese Funktion wurde in der Community-Wunschliste 2017 gewünscht. Rückmeldungen und Kommentare sind willkommen.
Danke und frohes Editieren! -Keegan (WMF) (talk) 22:09, 12. Mär. 2018 (CET)
nachrichtlich --PerfektesChaos 22:20, 12. Mär. 2018 (CET)
- zum archivieren, --Wetterwolke (Diskussion) 12:39, 24. Apr. 2018 (CEST)
Bald / Vorschau
"Nicht angemeldete Benutzer, deren IP-Adresse gesperrt wurde..." - sicher nützlich, da man es aber jetzt weiß, wie hoch ist der Nutzen, auch wenn zu der Änderung keine Anleitungen, "wie kann ich cookies auf meinem PC löschen" geliefert werden? Hm. Gruß -jkb- 11:34, 31. Mai 2018 (CEST)
- Security through obscurity hat noch nie auf Dauer funktioniert. — Raymond Disk. 12:24, 31. Mai 2018 (CEST)
- OK, kenne ich, und ich würde das allgemein vor allem für kompliziertere Sicherheitsmaßnahmen auch so annehmen. Nur dass man es ankündigt, wobei erfahrene Sockenzüchterfüchse wissen sollten was ein Cookie ist, und gleich die Abwehr beschreibt, fand ich lustig. Na gut. Gruß -jkb- 12:41, 31. Mai 2018 (CEST)
- Zumindest dürfte es ein paar Schülervandalen stören, und für die üblichen Trolle ist es ein Schritt mehr, den sie tun müssen. Kann man WP (angemeldet) benützen, wenn man Cookies ganz blockiert? --PaterMcFly Diskussion Beiträge 15:49, 1. Jun. 2018 (CEST)
- OK, kenne ich, und ich würde das allgemein vor allem für kompliziertere Sicherheitsmaßnahmen auch so annehmen. Nur dass man es ankündigt, wobei erfahrene Sockenzüchterfüchse wissen sollten was ein Cookie ist, und gleich die Abwehr beschreibt, fand ich lustig. Na gut. Gruß -jkb- 12:41, 31. Mai 2018 (CEST)
Neues responsives Layout in monobook
Anscheinend gibt es seit gestern ein neues Layout für kleinere Bildschirme. Das hat leider den gravierenden Nachteil, dass auf Smartphones und Tablets anstelle der lesbaren Menüeinträge nur noch nichtssagende Icons angezeigt werden. So ist das für mich nicht nutzbar. Wie kann man das deaktivieren? --Rodomonte (Diskussion) 09:45, 1. Jun. 2018 (CEST)
- Das Problem hast nicht nur du. Auf meinem Notebook passiert das gleiche. Siehe auch Wikipedia:Fragen_zur_Wikipedia#Merkwürdige_Seitendarstellung. Für eine Deaktivierungsmöglichkeit wäre ich ebenfalls dankbar, weil ich so nicht mehr wirklich editieren kann. --Alraunenstern۞ 15:14, 1. Jun. 2018 (CEST)
RfC in Vorbereitung: Benutzergruppe für JS/CSS
Birgit hat mich freundlicherweise auf einen RfC in Vorbereitung aufmerksam gemacht: meta:User:Tgr/Create separate user group for editing sitewide CSS/JS und dazu Phab:T190015.
In aller Kürze: Es geht darum, eine neue Benutzergruppe zu definieren, deren Mitglieder nur JS- und CSS-Seiten bearbeiten können und ggfs. diese Berechtigung Otto-Normal-Admin wegzunehmen. Das reduziert die Gefahr von gehackten Admins-Accounts, und damit also für Admins, die sowieso keine JS/CSS-Kenntnisse haben.
Sinnvollerweise sollte für diese neue Benutzergruppe die Zwei-Faktor-Authentifizierung (2FA) verpflichtend sein. Vor einigen Tagen sind einige Admin-Accounts gehackt worden (siehe Commons), die *keine* 2FA aktiviert hatten und auf Wikimedia Commons wurde Schadecode in die Common.js eingespielt :-(
Ich habe schon länger über so eine neue Benutzergruppe nachgedacht, für mich und bisweilen im persönlichen Gespräch habe ich sie "technische Admins" genannt. Weniger unter dem Sicherheitsaspekt, mehr mit dem Gedanken, dass Benutzer, die an Seiten sperren, VM, etc. kein Interesse haben, trotzdem auf technischer Ebene hier mitarbeiten können.
Falls ihr Mitlesenden meint, das Thema sollte jetzt schon weiter bekannt gemacht werden, als hier im technischen Hinterzimmer, bin ich für Hinweise dankbar. — Raymond Disk. 12:48, 12. Jun. 2018 (CEST)
- Man wird sich beizeiten Gedanken über den Rechtevergabe-Prozess machen müssen, wobei ja offensichtlich noch nicht klar ist, ob einzelne Communities darüber entscheiden oder ob es eine allgemeine Richtlinie dafür geben soll. Ansonsten ahne ich, dass das eher kein Thema von breiterem Interesse ist. NNW 13:36, 12. Jun. 2018 (CEST)
- Ist diese Benutzergruppe dann nur für die JS/CSS-Aktionen berechtigt und nicht zum Löschen,Sperren,Schützen oder ist das ein Zusatz zum Adminrecht? --84.161.141.49 18:26, 12. Jun. 2018 (CEST)
- Soweit ich das verstanden habe, wird den heutigen Admins etwas weggenommen (oh Schreck!!!!) und in die neue Benutzergruppe verlagert. D.h. die neue Benutzergruppe kann dann nur JS/CSS-Seiten bearbeiten und Admins können sich natürlich ebenfalls für diese neue technische Benutzergruppe melden, so dass sich für auch technisch versierte Admins nichts ändert. Aber das wird aktuell alles auf Meta im Detail diskutiert. Meine Aussagen hier sind wirklich noch unverbindlich zu verstehen. Alles im Fluss. — Raymond Disk. 19:08, 12. Jun. 2018 (CEST)
Die Geschichte gibt es schon seit Jahren köchelnd, und die deWP-Community müsste sich dann mittelfristig dazu stellen, wie sie mit den Benutzerrechten zu verfahren wünscht. Es ergeben sich fünf Konstellationen:
- Gewählte Admins, die sich mit Technik auszukennen meinen und auch die Technik-Rechte ausüben möchten; also unverändert gegenüber dem althergebrachten Stand. Formlos bei der Bürokratie.
- Gewählte Admins, die allenfalls auf Zuruf irgendwas irgendwo drüber kopiert hatten, aber noch nie wussten was sie da eigentlich taten und heilfroh sind, nunmehr aus der Verantwortung entlassen zu werden und auch in dieses neumodische F2A dann nicht einsteigen müssen.
- SG-Mitglieder, die keine Admins sind und für ihre Tätigkeit der Einsichtnahme keine Änderungsrechte an der Oberfläche benötigen.
- Erfahrene JavaScript-Programmierer mit sehr guten Kenntnissen der Wiki-Systematik, die keine Admins sind und sich irgendwie um Erteilung der Techie-Rechte bewerben könnten und für die ein Verfahren erarbeitet werden müsste. Wir haben eine Handvoll Benutzer, die JS+mw-fachlich dafür in Frage kämen und es meist besser als Admins könnten. Bot-Rechte werden von einer Art Bot-Senat nach Bewerbung verliehen, aber den Techie-Admin-Ausschuss gibt es nicht. Löschrechte oder Benutzersperrung sind natürlich nicht drin. Ein MB würde es wohl heutzutage dazu brauchen, wir haben nicht mehr 2007.
- Bürokraten, CU, OS, sogar Stewards, äh, wie mit diesen? Eigentlich genau wie alle Admins bzw. SG.
Global gibt es eine solche Gruppe übrigens schon seit Jahren, so rein informativ am Rande bemerkt.
VG --PerfektesChaos 12:04, 13. Jun. 2018 (CEST)
Das ist aber nur ab dem heutigen Datum, richtig? Zuvor erstellte Seiten werden dort nicht gelistet. Ist das so erwünscht? Ich hatte erwartet, dass ich dort nun alle von mir jemals erstellten Seiten abrufen könnte, zumindest suggeriert die Datumsauswahl, dass das möglich sein sollte. Die Älteste ist aber von heute 01:14 Uhr. Das ist für mich irgendwie nutzlos. --Liebe Grüße, Lómelinde Diskussion 09:13, 28. Jun. 2018 (CEST)
- Korrekt. — Raymond Disk. 09:34, 28. Jun. 2018 (CEST)
- @Lómelinde: In den "eigenen Beiträgen" kann man "nur Seitenerstellungen" ankreuzen. Dann siehst Du doch all Deine Seitenerstellungen. --tsor (Diskussion) 09:45, 28. Jun. 2018 (CEST)
- Ich frage mich, wo da jetzt genau der Unterschied zu Neue Seiten ist, dort nämlich kann ich gezielt nach Seiten schauen die ich erstellt habe, ist das nicht irgendwie redundant? Oder ist das nur ein Auszug aus der anderen Liste. Muss ich etwas an den Hilfeseiten anpassen? Wo sortiert sich das ein? Ist eine neue Seite nicht auch eine neu erstellte Seite? Ich bin völlig verwirrt von dieser Meldung. --Liebe Grüße, Lómelinde Diskussion 11:00, 28. Jun. 2018 (CEST)
Es werden scheinbar auch gelöschte Seiten angezeigt. Verschiebereste werden nicht angezeigt, ob das der Fall sein wird, wenn diese mal zu einer BKL mutieren, ist fraglich. --Färber (Diskussion) 11:06, 28. Jun. 2018 (CEST)
- Spezial:Neue Seiten reicht nur 30 Tage zurück und nutzt dieselbe Datenbasis wie Spezial:Letzte Änderungen und die Beo.
- Benutzerbeiträge→Seitenerstellungen listet alle noch existierenden Seiten eines einzelnen Accounts.
- Das neue Logbuch soll meinem Verständnis nach diese Lücke füllen; also zeitlich unbegrenzt auch für nicht mehr existierende Seiten auch über inzwischen umbenannte Seiten ausnahmslos alle Seitenerstellungen auflisten, und das dann in auswertbar/filterbar unabhängig von einzelnen Benutzern.
- Müsste man im Prinzip rückwirkend bis 2001 vom Server aus rekonstruieren lassen.
- LG --PerfektesChaos 11:36, 28. Jun. 2018 (CEST)
- Wie geschrieben, mich verwirrte das etwas. Ja stimmt es wäre gerade bei Beiträgen von neu angemeldeten Autoren nützlich zu sehen welche Seite sie kurz zuvor erstellt haben, worauf sich ihre Frage also bezieht, falls diese inzwischen gelöscht wurde, das war bisher für Nichtadmins recht umständlich zu finden.
- Es dauert halt etwas bis ich den Sinn dieses Loggings verstehe (ich mag nicht so gern geloggt werden), etwas mehr Hintergrundinformation, wäre schon schön gewesen.
- Danke für die Nachlieferung. --Liebe Grüße, Lómelinde Diskussion 11:49, 28. Jun. 2018 (CEST)
- Insbesondere erlaubt es auch bei gelöschten Seiten, die grobe Historie der Seite aus Erstellungen, Verschiebungen und Löschungen nachzuvollziehen. --MGChecker – (📞| 📝| ) 22:41, 28. Jun. 2018 (CEST)
Become a Tech Ambassador today
Hallo. Hilf bitte mit, in deine Sprache zu übersetzen. Danke! Some of you may have seen this message before. I am looking for community members with a passion for technology and who enjoy supporting this community in things like figuring out software changes and communicating with the developers.
The Community Liaisons team at the Wikimedia Foundation is looking for active tech ambassadors in this community. We would like to help make this volunteer role an attractive and low-barrier contribution path in our movement, and we're only a few communities short from our kickstarting goal. You can add your name to the table on Meta, or you can let me know about someone else who should really, really be in that list.
Please, do not assume that you are not "fit", that you lack the skills, or the experience etc. If you have doubts, questions, etc., if you would maybe consider doing it, but you don't know where to start, just contact me. I also understand that some may think that somebody else in particular should be stepping up instead and are worried about stepping on others' toes. FWIW, I think this call has been around for so long that this should no longer be the case. Thanks a lot for your attention. :) Elitre (WMF) (Diskussion) 12:34, 8. Mär. 2018 (CET)
- zum archivieren, --Wetterwolke (Diskussion) 01:16, 2. Jul. 2018 (CEST)
Neue Wartungskategorie
Ich habe die „Kategorie:Seiten, die Timeline verwenden“ vorhin „provisorisch“ angelegt, weil sie rot war. Sie müsste aber noch angepasst werden, ich vermute sie gehört zu dieser Serie Kategorie:Wikipedia:Syntaxfehler durch MediaWiki-Komponente erkannt.
- Dort haben alle Kategorien einheitlich das Präfix
Kategorie:Wikipedia:
- Es sollte zudem eingefügt werden, wozu diese Kategorie dient und was der genaue „Wartungsauftrag“ wäre, warum stehen hier Seiten, wie stellt man das ab, wie soll es aussehen, was ist zu tun?
- Der Inhalt der Seite MediaWiki:Timeline-tracking-category = „Seiten, die Timeline verwenden“ müsste entsprechend auf „Wikipedia:Seiten, die Timeline verwenden“ geändert und die Kategorie dann auf das passende Lemma verschoben werden.
Es wäre nett, wenn sich ein Administrator darum kümmern würde. Vielen Dank im Voraus. --Liebe Grüße, Lómelinde Diskussion 12:18, 29. Jun. 2018 (CEST)
- WP:AAF. Marcus Cyron Reden 12:25, 29. Jun. 2018 (CEST)
- Nein, da schreibe ich nicht, es eilt auch nicht. Hier erfolgte der Hinweis hier kennen sich diejenigen, die solche Hinweise hier eintragen auch mit den Hintergründen aus, zumindest gehe ich davon aus, dass sie das tun. --Liebe Grüße, Lómelinde Diskussion 12:40, 29. Jun. 2018 (CEST)
- Ich habe sie nach Kategorie:Wikipedia:Beobachtung umsortiert, da die Kategorie keine Fehler auflistet, sondern einfach nur die Verwendung dokumentiert, analaog Kategorie:Wikipedia:Seite mit Karte. — Raymond Disk. 13:39, 29. Jun. 2018 (CEST)
- PS: Und nach Kategorie:Wikipedia:Seiten, die Timeline verwenden verschoben. — Raymond Disk. 13:41, 29. Jun. 2018 (CEST)
- Nein, da schreibe ich nicht, es eilt auch nicht. Hier erfolgte der Hinweis hier kennen sich diejenigen, die solche Hinweise hier eintragen auch mit den Hintergründen aus, zumindest gehe ich davon aus, dass sie das tun. --Liebe Grüße, Lómelinde Diskussion 12:40, 29. Jun. 2018 (CEST)
Vielen Dank. Ach so, und ich dachte es wäre Wartung. --Liebe Grüße, Lómelinde Diskussion 13:43, 29. Jun. 2018 (CEST)
- Sollten wir hier nicht auch die Singularregel anwenden? --Wiegels „…“ 15:15, 30. Jun. 2018 (CEST)
- Das hat PerfektesChaos doch unten schon geschrieben bitte auf Singular setzen → Zitat von unten: „Bitte verschieben nach Singular; Wikipedia:Seite, die Timeline verwendet oder kurz Wikipedia:Seite mit Timeline“. --Liebe Grüße, Lómelinde Diskussion 19:15, 30. Jun. 2018 (CEST)
- Sollten wir hier nicht auch die Singularregel anwenden? --Wiegels „…“ 15:15, 30. Jun. 2018 (CEST)
- @Admins:
- „WP:AAF“ – Naja, das ist erstmal nur was für die triviale Ausführung bereits ausdiskutierter Entscheidungen; diese hier auch nicht-administrativ beobachtete Seite ist für den Klärungsprozess schon richtig, und die hier mitlesenden Admins können das nach Konsens dann direkt umsetzen.
- MediaWiki:Timeline-tracking-category
- Bitte umsetzen auf:
-
- Damit ist sie erstmal deaktiviert.
- Damit erscheint sie nicht unten auf den betroffenen Seiten (für Fortgeschrittene), und löst dort keinen Zwergenaufstand mit irritierten Autoren aus.
- Zurzeit gibt es keinen Grund, urplötzlich die seit einem Jahrzehnt damit ausgestatteten Artikel unter der Überschrift „Wartungskategorien“ zu belästigen.
- Perspektivisch vorgesehen ist das für die mögliche Ablösung der ururalten
<timeline>
durch Hilfe:Graph (phab:T137291), oder im Falle von Änderungen an der Extension (bloß nicht dran rühren), was Fehler auslösen könnte. - Hier arbeitet aber momentan niemand mit dieser Kategorie.
- Sobald ein konkreter Umstellungsprozess beginnt, dann wieder scharf schalten.
- Bitte umsetzen auf:
- Kategorie:Wikipedia:Seiten, die Timeline verwenden
- Bitte verschieben nach Singular; Wikipedia:Seite, die Timeline verwendet oder kurz Wikipedia:Seite mit Timeline
- Wenn das unten erscheint, sieht der Plural sehr merkwürdig aus.
- Einheitlich mit Kategorie:Wikipedia:Seite durch MediaWiki-Komponente kategorisiert und allen Unterkats.
- MediaWiki:hidden-categories
- Bitte umschreiben von „Wartungs“ auf „Versteckte“.
- Grund: Seit 2015 mit „österreichbezogen“ gibt es auch einfach-nur-so-Kategorien, die überhaupt keinen akuten Wartungsbedarf anzeigen, was bereits mehrfach zu Konflikten führte.
- Bis 2015 war immer jede versteckte auch eine Wartungskategorie gewesen.
- Am Rande bemerkt ist in Vorlage:österreichbezogen die Kategorisierung absolut überflüssig, weil sowohl Cirrus (seit 2014) wie auch Petscan bereits das Vorhandensein der Vorlageneinbindung hinreichend erkennen und filtern können.
- MediaWiki:Templatestyles-stylesheet-error-category
- Bitte auf
Wikipedia:TemplateStyles-Stylesheet mit Fehler
(seit gestern) – Kategorie:Wikipedia:TemplateStyles-Stylesheet mit Fehler.
- Bitte auf
- MediaWiki:Templatestyles-page-error-category
- Bitte auf
Wikipedia:Seite mit TemplateStyles-Fehler
(seit gestern) – Kategorie:Wikipedia:Seite mit TemplateStyles-Fehler.
- Bitte auf
- Schönes Wochenende --PerfektesChaos 16:28, 29. Jun. 2018 (CEST)
- alle erledigt.--Mabschaaf 19:50, 30. Jun. 2018 (CEST)
- @Mabschaaf: Schönen Dank soweit, aber eine kleine Nacharbeit kam mir noch unter:
- MediaWiki:hidden-categories mit Strich ist erl.
- MediaWiki:hiddencategories ohne Strich fiel mir noch in die Hände (Seite nur ansehen).
- @Mabschaaf: Schönen Dank soweit, aber eine kleine Nacharbeit kam mir noch unter:
Diese Seite gehört zu {{PLURAL:{{{1|$1}}}|einer versteckten Kategorie|{{{1|$1}}} versteckten Kategorie}}:
- LG --PerfektesChaos 14:19, 1. Jul. 2018 (CEST)
- ebenfalls done.--Mabschaaf 16:35, 1. Jul. 2018 (CEST)
- LG --PerfektesChaos 14:19, 1. Jul. 2018 (CEST)
- Und noch einer, MediaWiki:tog-showhiddencats
Zeige versteckte Kategorien
– nach mittlerweile namensraumweiter Suche offenbar die letzte generische Verwendung. - LG --PerfektesChaos 12:09, 2. Jul. 2018 (CEST) H:SET
- Und auch die noch - done.--Mabschaaf 17:26, 2. Jul. 2018 (CEST)
- Und noch einer, MediaWiki:tog-showhiddencats
Cookie bei IP-Sperre
Nette Idee, aber das müsste ja eigentlich sehr einfach zu umgehen sein, indem man regelmäßig seine Cookies löscht oder gleich den Browser anweist, erst gar keine zu speichern? -- Chaddy · D 15:17, 12. Jul. 2018 (CEST)
- Siehe dazu die Diskussion im Archiv. --\m/etalhead ✉ 15:36, 12. Jul. 2018 (CEST)
- Danke für den Link! -- Chaddy · D 19:41, 12. Jul. 2018 (CEST)
Logbuch
(Softwareneuheit) Das Logbuch hat eine neue Gestaltung erhalten. Außerdem kann jetzt ein genauer Tag angegeben werden. (Task 117737)
- Wem ist denn dieser Unsinn eingefallen? Warum zeigt mir ein Klick auf Logbücher jetzt immer nur die mir zugeordneten Logbücher an und ich muss megaumständlich versuchen meinen Namen oben aus der URL zu entfernen damit ich auf das generelle Verzeichnis aller Logbucheinträge wechseln kann? Das habe ich immer so gemacht um schnell einen aktiven Admin finden zu können. Das ist doooooof.
- Konnte ich zuvor einfach meinen Namen aus dem Eingabefeld löschen und auf Anzeigen klicken um nach hier Spezial:Logbuch zu wechseln, so sind die Felder jetzt schon leer und ich habe keine Möglichkeit mehr dorthin zu kommen. Ich muss also, wie geschrieben, oben in der URL meinen Benutzernamen löschen
https://de.wikipedia.org/wiki/Spezial:Logbuch/Lómelinde
oder in das Suchfeld explizitSpezial:Logbuch
einfügen. - Klar, wenn man es weiß, kann man sich umgewöhnen, aber allein das neue Layout ist einfach nur unschön weil die Auswahlbox jetzt in der Mitte steht und nicht mehr wie zuvor links Hilfe:Logbücher#Eingabeformular mit den Benutzernamen sichtbar daneben. Das Beispielformular kann ich nun auch wieder umbauen, was nicht so ein Problem ist, mich stört es aber gewaltig wenn hier ständig wöchentlich meine Gewohnheiten durch für mich absolut nicht nachvollziehbare Anpassungen durcheinandergewürfelt werden.
- Ich brauche diese Funktion, wenn ich schnell einen Admin benötige.
- Das regt mich echt megamäßig auf. Ich möchte einfach und mit einem Klick an alle öffentlichen Logbücher herankommen und nicht erst irgendwelche Umwege gehen müssen. Gmpf.
- Nicht ein einziges mal wird etwas so geändert, dass es mich freuen würde, weil es mir einen Vorteil bringt, immer nur Einschränkung → Umstellung → Funktionsverluste. Beispielsweise klappt seit einiger Zeit die erweiterte Bearbeitungswerkzeugleiste ständig zu während das zuvor nie passierte, denn ich benötige auch diese Funktionen ständig und das immer wieder aufklappen müssen nervt auch nur unnötig. Warum werden einem hier so viele Steine in den Weg geworfen????? Und wenn man schon ein tolles neues Formular erstellt, könnte es dann nicht wenigstens auch in der kleinstmöglichen Bildschirmbreite auf den Schirm passen ohne einen Scrollbalken zu erzeugen? Na immerhin der Ausklapppfeil ist noch im Seitenbereich. Grummel --Liebe Grüße, Lómelinde Diskussion 14:47, 26. Jul. 2018 (CEST)
- Das geht seit Jahren so. Vergleichbar mit "tree swing cartoon" (translated by Raymond) und wie Rillke in seinem Abschiedsbrief schreibt (Englisch): „Die Entwicklung geht in die falsche Richtung“. Für Tool-Entwickler werden auch immer höhere Hürden aufgebaut, dass zukünftig nur noch WM-Leute (oder extrem Involvierte) Tools bereitstellen können (ob da System hinter steckt kann ich nicht sagen). -- User: Perhelion 15:38, 26. Jul. 2018 (CEST)
- Ja so fühle ich mich hier auch, immer wenn man meint man kommt einigermaßen klar dann kommen sie mit einer hübschen Überraschung daher und das Kartenhaus stürzt wieder ein. Manchmal habe ich wirklich das Gefühl, dass man hier auf verlorenem Posten steht, wenn man nicht zu den Spezialisten zählt, wie frage ich mich, soll sich da jemand fühlen, der neu hinzukommt. Das muss doch Frust erzeugen. --Liebe Grüße, Lómelinde Diskussion 16:12, 26. Jul. 2018 (CEST)
- Das geht seit Jahren so. Vergleichbar mit "tree swing cartoon" (translated by Raymond) und wie Rillke in seinem Abschiedsbrief schreibt (Englisch): „Die Entwicklung geht in die falsche Richtung“. Für Tool-Entwickler werden auch immer höhere Hürden aufgebaut, dass zukünftig nur noch WM-Leute (oder extrem Involvierte) Tools bereitstellen können (ob da System hinter steckt kann ich nicht sagen). -- User: Perhelion 15:38, 26. Jul. 2018 (CEST)
- Den Fehler, dass der Benutzername nicht mehr ins Eingabefeld übernommen wird, habe ich per Phab:T200446 reklamiert. — Raymond Disk. 18:32, 26. Jul. 2018 (CEST)
- Dankeschön, ich habe eh ein wirklich gespaltenes Verhältnis zu manchen Logbüchern. Wenn ich bedenke, dass ich dafür, dass ich für die Mühe solchen Müll (rund 122000 Bytes) aus einem Artikel zu entfernen, als kleines Dankeschön einen Eintrag im Bearbeitungsfilterlogbuch (Und das heißt noch immer in der URL Missbrauchsfilter/236) bekommen habe, dann fällt es mir immer schwer, hier noch an das „Gute“ zu glauben. Wann wird hierfür endlich eine Verjährungsfrist oder eine andere Möglichkeit der Löschung von solchen Bearbeitungsfilterungen eingeführt? Ich bin nicht hier, um mutwillig etwas „kaputt“ zu machen. Ich mag diese Einträge nicht. Ich weiß auch so, dass ich nicht frei von Fehlern bin. --Liebe Grüße, Lómelinde Diskussion 19:09, 26. Jul. 2018 (CEST)
- Hallo @Lómelinde:, Danke für die Rückmeldung hier. Eine Problemlösung um direkt über Browseradressleiste auf den Benutzernamen-Log zu kommen ist dank @Raymond:s Phabricator-Task bereits in Arbeit. Hintergrund der Änderung ist Standardisierung aller Administrationsformulare auf einheitlichen Code und Design mit unserer User-Interface-Bibliothek OOUI als Code-Basis und Erscheinungsbild. Das bedeutet, dass sich das Aussehen nochmals ändern wird, danach aber Ruhe einkehren wird, da es dann in Einklang mit anderen Spezialseiten für Contributoren steht und nicht mehr historisch gewachsenen Spezialcode enthält, der schlecht wartbar oder kaum einfach für zukünftige Aufgaben erweiterbar wäre. Bitte warte mit dem Umbauen des Beispielformulars also noch zu.
- Ich werde Deine oben genannten Ideen („Verjährungsfrist oder eine andere Möglichkeit der Löschung von solchen Bearbeitungsfilterungen“) auch mit Phabricator abgleichen, ob es dazu bereits etwas gibt. Mir ist klar, dass solche Umstellungen problematisch sein können, aber es sei Dir versichert, dass wir versuchen mit begrenzten Mitteln bestehende und erfahrene Contributoren so gut es geht nicht in ihrer Produktivität zu stören, sondern langfristig zu fördern und neue, einfachere, mobil-freundliche Interfaces zur Verfügung zu stellen.
- --Besten Gruß Volker E. (WMF) (Diskussion) 20:40, 26. Jul. 2018 (CEST)
- @Volker E.: Genau das aber ist mein Problem, ich benötige diese riesenhaften Schaltflächen, wie sie über ooui erzeugt werden nicht, ich bin nicht mobil für mich stellen diese Umstellungen also auch langfristig „keine Verbesserung“ dar. Du erinnerst dich sicherlich noch an das Problem mit den OOUI-Icons. Ihr ändert munter drauf los und das Wartungspersonal hat das Nachsehen. Ich möchte auch nicht über die Browseradressleiste zum Logbuch wechseln, im Gegenteil, vorher war es möglich den eigenen Namen aus dem Eingabefeld
- (Ausführender Benutzer:
Lómelinde+ Anwenden) zu löschen und man kam direkt zu allen nicht IP- oder Namensbezogenen Einträgen im →Logbuch. - Es ist kein Fortschritt, wenn diese Möglichkeit verkompliziert wird. Es geht mir wirklich sehr selten darum Logbucheinträge zu durchsuchen, die mit mir und meinen Edits zu tun haben. Für mich stellte das bisher einen recht einfachen und schnellen Weg bereit, zu sehen welcher Admin gerade online ist, wenn ich eine Adminaktion auf dem kleinen Dienstweg benötige (klar ich könnte auch über die Letzten Änderungen gehen, aber auch wenn das seltsam klingen mag die Spezialseite rufe ich eher sehr selten auf).
- Die Hilfeseite ist längst angepasst und wird es erneut, sobald das Layout wieder wechselt und sie dann statt der kleinen mir eigentlich wirklich liebgewonnenen Checkboxen ↔ und Tasten riesenhafte fingertipgerechte Quadrate (hier kleiner als die Originale) → und Schalterbalken anzeigen wird.
- Um es deutlich zu sagen, diese ganzen Umstellungen hatten bisher für mich persönlich und für meine Art hier zu arbeiten nur Nachteile, angefangen mit dem riesenfhaften Bearbeitungsfenster (Höhe knapp 20 cm), das quasi fast meine kompletten Bildschirmhöhe füllte und das ich nur noch mit Hilfe von lokalen Softwaretechnikern wieder (auf rund 9 cm) verkleinern und auf meine Bedürfnisse umstellen konnte (da die bisherige Funktion der persönlichen Einstellmöglichkeit einfach mal komplett abgeschafft wurde). Gleiches gilt auch für die Icons meiner Symbolleiste. Ich erkenne sie in bunt schneller, bunt erleichtert mir die Mitarbeit und alles wird mit schwarz/weiß übertüncht. Allein „lokale Tools“ helfen mir hier effektiv mitzuarbeiten. Ich fühle mich daher leider ständig in „meiner Produktivität“ gestört und ärgere mich über jede, wirklich fast jede Änderung, ich wüsste auf Anhieb keine, die ich je als gut empfunden hätte. Aber das soll nicht wichtig sein, ich bin ersetzbar und nur ein Gast in dieser Welt. --Liebe Grüße, Lómelinde Diskussion 06:48, 27. Jul. 2018 (CEST)
- Das grundlegende Problem ist, dass viele „alte Hasen“ sich an die Merkwürdigkeiten und Inkonsistenzen der Oberfläche gewöhnt haben und die nun vorangetriebene Verschlankung und Vereinfachung so wirkt, als würde alles komplizierter. Mein persönlicher Eindruck ist aber, dass die WMF-Entwickler diesen Spagat in den letzten Jahren gut hinbekommen. Im Hintergrund wurde viel geräumt und verbessert, oft unbemerkt von uns als Community. Wenn bestimmte Arbeitsabläufe gestört oder gebrochen werden, gibt es seitens der Entwickler eigentlich immer zumindest die Bereitschaft, sich das Problem anzusehen und ggf. Entscheidungen zu überdenken, die natürlich oft ohne Kenntnisse der zig verschiedenen Arten, MediaWiki zu benutzen, getroffen wurden. Dieser Rückkanal steht allen offen. Gerade deine Fehlermeldungen, die ich in den letzten Monaten auf Phabricator übersetzt und dokumentiert habe, wurden doch (häufig sogar sehr kurzfristig) von den Entwicklern dankbar aufgenommen. Daher kann ich deine große Frustration nicht so richtig nachvollziehen.--Cirdan ± 10:47, 28. Jul. 2018 (CEST)
- @Cirdan diese Meldungen betrafen zumeist einen Editor (VE), den ich nicht verwende, ich versuche aber trotzdem dort zu helfen. Mein persönliches Arbeitsumfeld wurde massiv gestört. Durch dicke Schalter duch farblose Icons durch den Zwang immer mehr Skrollen zu müssen und durch das aufblähen der Texthöhe in allen möglichen Listen, selbst vor der Höhe des Bearbeitungsfensters, die lange Zeit „individuell an die persönlichen Bedürfnisse angepasst werden konnte“ hat man einfach auf eine fixe für mich völlig unakzeptable Höhe eingestellt. Da wundert es dich, dass ich frustriert bin? Meine Nachfragen, die konkret in die Richtung gingen mir zerstörte Funktionen wieder zu richten, wurden schlichtweg ignoriert. Beispielsweise, dass seit einem Jahr in meinem Bearneitungsfenster nichts mehr rückgängig zu machen geht, das ich aus der Umgebung (Schaltflächen zum einfügen von Tabellen, Belegen, Fettschrift, Personendaten, Kategorien, Sonderzeichen … selbst eine falsch platzierte Signatur müsste ich von Hand markieren, um sie wieder zu entfernen, denn mein Browser erkennt diese Einfügung nicht, ergo ist sie auch nicht rücksetzbar [rechte Maustaste → Rückgängig ist inaktiv]) einfüge, zuvor konnte ich beispielsweise durch Suchen und Ersetzen etwas einfügen und bei Bedarf einzeln wieder zurücksetzen, das geht nicht mehr, das ist kaputt wie viele andere Dinge auch, an die ich gewöhnt war und die für mich wichtig waren. Nein, für „mich“ wurde hier nichts geändert, ich weise nur auf Fehler hin, die mir auffallen. Verbessert hat sich hier nie etwas, es wird immer nur schlechter und nerviger und zeitintensiver und frustriert mich wirklich. Das mit den fehlenden Verlinkungsechos ist auch bisher nicht dort angekommen, ich sehe keinerlei Interesse der Entwickler das anzupassen (O.k. ich verstehe Phab eh nicht), das aber ist wiederum etwas, was „mich direkt betrifft“. Sie mögen mich nicht (weil ich einen Desktoprechner bevorzuge), das ist es, was bei mir ankommt. Wenn ich für mich mal etwas möchte interessiert das niemanden, so wie die Sache mit den Icons für unsere Hilfeseiten VE und Echo, die wir (also nicht ich) neu erstellen mussten, weil sie uns selbst auf Nachfragen und Bitten hin nicht bereitgestellt wurden, das frustriert, weil es „meine Mitarbeit“ (sprich die Aktualisierung von Hilfeseiten) massiv behindert. --Liebe Grüße, Lómelinde Diskussion 12:30, 28. Jul. 2018 (CEST)
- Hallo @Lómelinde: der originale Fehler in dieser Diskussion zum Aufrufen der vorausgefüllten Felder mit “
https://de.wikipedia.org/wiki/Spezial:Logbuch/Lómelinde
” (Phab:T200446) ist inzwischen behoben und wird demnächst veröffentlicht. - --Besten Gruß Volker E. (WMF) (Diskussion) 21:32, 31. Jul. 2018 (CEST)
- Hallo @Lómelinde: der originale Fehler in dieser Diskussion zum Aufrufen der vorausgefüllten Felder mit “
- Danke für die Nachricht, ich habe gestern schon bemerkt, dass etwas angepasst wurde, wenn ich nun bei leeren Eingabefeldern auf Anzeigen klicke, springt es auf diese URL https://de.wikipedia.org/wiki/Spezial:Logbuch?type=&user=&page=&wpdate=&tagfilter= um, die nicht mehr meinen Benutzernamen enthält das würde mir schon reichen. Denn das würde ich bei einer leeren Eingabe auch erwarten. --Liebe Grüße, Lómelinde Diskussion 06:15, 1. Aug. 2018 (CEST)
- Dankeschön, ich habe eh ein wirklich gespaltenes Verhältnis zu manchen Logbüchern. Wenn ich bedenke, dass ich dafür, dass ich für die Mühe solchen Müll (rund 122000 Bytes) aus einem Artikel zu entfernen, als kleines Dankeschön einen Eintrag im Bearbeitungsfilterlogbuch (Und das heißt noch immer in der URL Missbrauchsfilter/236) bekommen habe, dann fällt es mir immer schwer, hier noch an das „Gute“ zu glauben. Wann wird hierfür endlich eine Verjährungsfrist oder eine andere Möglichkeit der Löschung von solchen Bearbeitungsfilterungen eingeführt? Ich bin nicht hier, um mutwillig etwas „kaputt“ zu machen. Ich mag diese Einträge nicht. Ich weiß auch so, dass ich nicht frei von Fehlern bin. --Liebe Grüße, Lómelinde Diskussion 19:09, 26. Jul. 2018 (CEST)
Technical administrators
Es wird eine sich seit fünf Jahren abzeichnende Entwicklung allmählich spruchreif:
Auf Archiv/2018#RfC in Vorbereitung: Benutzergruppe für JS/CSS hatte ich kürzlich die Variationen ausdifferenziert.
- Es wird so oder so mittelfristig wie vorgezeichnet passieren, anschließend ohne Aktivität wären den Admins die Rechte entzogen.
- Die Community müsste sich dazu positionieren und Verfahren entwickeln.
- Auf A/N sollte jemand eine Zusammenfassung einstellen.
- Bürokraten müssten auch was davon wissen.
- WP:TWS #Consultation on the creation of a separate user group for editing sitewide CSS/JS empfing gerade ein Rundschreiben.
VG --PerfektesChaos 13:48, 9. Jul. 2018 (CEST)
- Die Regularien dazu werden auf WD:Meinungsbilder/Oberflächenadministratoren entwickelt. --MGChecker – (📞| 📝| ) 16:06, 13. Aug. 2018 (CEST)
Größere Thumbnails in Galerien: phab:T3340
Da neue Gadgets heutzutage eher rar gesät sind, hier ein Hinweis zu einem solchen nun auf Commons:MediaWiki:Gadget-LargerGallery.js (s.d. vor über 10 Jahren schon u.a. von Admin PDD vehement eingefordert).. -- User: Perhelion 20:14, 8. Mär. 2018 (CET)
- kann archiviert werden, --Wetterwolke (Diskussion) 19:15, 2. Sep. 2018 (CEST)
Server switch 2018
Lt. meta:Tech/Server switch 2018 wird voraussichtlich am 12. September und 10. Oktober jeweils um 16:00 MESZ bis zu eine Stunde lang kein Editieren möglich sein. Wie und wann kommunizieren wir dies? SiteNotice und/oder WatchListNotice? Von einer WMF-Wiki-weiten CentralBotice steht unter meta:CentralNotice/Calendar bislang noch nichts. Gruß --Schniggendiller Diskussion 17:37, 25. Aug. 2018 (CEST)
- Sowas lief zuletzt immer per MediaWiki:Sitenotice, 24 Stunden vorher, soweit ich weiß. Dazu am besten einen Hinweis auf WP:FZW, der kann auch schon etwas früher kommen. NNW 17:47, 25. Aug. 2018 (CEST)
- Bzw. etwas servicefreundlicher:
- WatchlistMessage um drei Tage vorher, für angemeldete Hochaktive, gleich den zweiten Termin vorankündigen, können sich ihre Arbeitspläne schon mal anpassen.
- Wikipedia:Technik/MediaWiki/SiteNotice etwa 18–24 Stunden vorher; informiert auch die IP, und erinnert die angemeldeten noch mal dran.
- Beide können weggeklickt werden.
- FZW könnte man noch extra machen, hat aber wesentlich geringere Wahrnehmungsquote als WatchlistMessage.
- VG --PerfektesChaos 21:03, 2. Sep. 2018 (CEST)
- Bzw. etwas servicefreundlicher:
No longer allowed to load normal pages (not protected, NS_MEDIAWIKI or user js subpage) as javascript
Hi everyone, In order to improve site security, we are no longer allowing ordinary pages to be loaded as javascript (That is, ?action=raw&ctype=text/javascript ). Only pages that are (fully) protected, in the MediaWiki: namespace, or is a user JS subpage can be loaded with the ctype=text/javascript We made this change because there was a large number of users accidentally loading unprotected page in their JS, often as a result of copying scripts between languages. Thank you for your understanding, Brian Wolff Wikimedia Security Team
Kann das jemand vorne in verständlichem Deutsch formulieren? Danke. Quelle. — Raymond Disk. 22:53, 27. Sep. 2018 (CEST)
Hallo zusammen, um die Websitesicherheit zu verbessern, lassen wir ab sofort nicht mehr zu, dass normale Seiten als Javascript geladen werden können (d.h.: ?action=raw&ctype=text/javascript). Nur Seiten, die (voll-)geschützt sind, Seiten im MediaWiki-Namensraum oder Benutzerunterseiten können noch mit ctype=text/javascript geladen werden Wir haben diese Änderung vorgenommen, weil viele User versehentlich ungeschützte Seiten in ihr Javascript kopiert haben, häufig verursacht durch das Kopieren von Scripten zwischen Sprachen. Danke für euer Verstänids Brian Wolff Wikimedia Security Team
(ich verstehe die Worte, aber nicht den Sinn, deshalb erst mal nur hier ;-) --elya (Diskussion) 23:08, 27. Sep. 2018 (CEST)
- (BK; ich verstehe auch den Vorgang)
- Sehr frei übertragen:
- Um die Sicherheit aller Projektbeteiligten zu erhöhen, ist es nicht mehr möglich, normale Wiki-Seiten als JavaScript zu laden. Nur noch solche Seiten, die entweder vollgeschützt (in der Regel im MediaWiki-Namensraum) sind (und nur noch von Benutzeroberflächenadministratoren bearbeitet werden können) bzw. im Benutzer-Namensraum liegen (und ansonsten nur vom zuständigen Benutzer selbst bearbeitet werden können) werden beim Abruf mit den URL-Parametern
action=raw&ctype=text/javascript
geeignet ausgeliefert. - Diese Maßnahme wurde erforderlich, weil eine größere Zahl von Benutzern irrtümlich ungeschützte Seiten als JavaScript ausgeführt hatten, was ein extremes Sicherheitsrisiko ist. Ursache war oft ein Kopieren zwischen Wiki-Projekten, ohne genau zu verstehen, worum es sich handelt.
- Um die Sicherheit aller Projektbeteiligten zu erhöhen, ist es nicht mehr möglich, normale Wiki-Seiten als JavaScript zu laden. Nur noch solche Seiten, die entweder vollgeschützt (in der Regel im MediaWiki-Namensraum) sind (und nur noch von Benutzeroberflächenadministratoren bearbeitet werden können) bzw. im Benutzer-Namensraum liegen (und ansonsten nur vom zuständigen Benutzer selbst bearbeitet werden können) werden beim Abruf mit den URL-Parametern
- LG --PerfektesChaos 23:12, 27. Sep. 2018 (CEST)
- Außer Benutzer:APPER/RP/js und noch weiteren Seiten von Benutzer:APPER (die alle noch funktionieren, weil sie geschützt sind, wenn auch nicht automatisch) sind mir keine Seiten bekannt, die betroffen sein könnten. Die zugehörige Phabricator-Task ist übrigens phab:T171563, wo der Vorschlag von mir kam, dieses unsichere Laden zu unterbinden. –Schnark 09:46, 28. Sep. 2018 (CEST)
- WP:PB läuft deswegen gerade nicht. NNW 09:52, 28. Sep. 2018 (CEST)
- Außer Benutzer:APPER/RP/js und noch weiteren Seiten von Benutzer:APPER (die alle noch funktionieren, weil sie geschützt sind, wenn auch nicht automatisch) sind mir keine Seiten bekannt, die betroffen sein könnten. Die zugehörige Phabricator-Task ist übrigens phab:T171563, wo der Vorschlag von mir kam, dieses unsichere Laden zu unterbinden. –Schnark 09:46, 28. Sep. 2018 (CEST)
- Wurde etwas am Medienbetrachter verändert?
- Kann es sein, dass dabei etwas unbeabsichtigt kaputtgegangen ist?
- → Wikipedia:Fragen zur Wikipedia#Schwarzer Bildschirm auch weitere Probleme mit Medien sind heute schon aufgetreten, so beispielsweise alte Versionen von gekippten (90° gedrehten) Bildern, die in manchen Kombinationen die alte, nicht gedrehte Version anzeigen Hilfe Diskussion:Bilder, möglicherweise besteht auch da ein Zusammenhang.
- InternetExplorer zeigt mit Medienbetrachter einen schwarzen Bildschirm.
Bitte möglichst schnell reparieren. --Liebe Grüße, Lómelinde Diskussion 13:22, 21. Sep. 2018 (CEST)
- Ist bereits gefixed - ErledigtDer Umherirrende 20:34, 30. Sep. 2018 (CEST)
Löschen verwendet jetzt die Job Queue
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/456035/ ist vermutlich wichtig für die Vorderseite, bin aber gerade nicht in der Lage, das dort angemessen einzufügen. --MGChecker – (📞| 📝| ) 09:36, 10. Okt. 2018 (CEST)
- Gilt aber, wenn ich das richtig lese, nur für Seiten mit über 1000 Versionen. -- hgzh 13:32, 10. Okt. 2018 (CEST)
STL
Ein Eingeweihter möge Hilfe:Dateien#Erlaubte und erwünschte Dateiformate bzw. c:Commons:Dateitypen entsprechend ergänzen. --Leyo 17:42, 13. Feb. 2018 (CET)
- hinweis auf der disku dort hinterlassen Hilfe_Diskussion:Dateien#STL, --Wetterwolke (Diskussion) 15:15, 21. Okt. 2018 (CEST)
CSP report only mode
Just a heads up, we're enabling CSP in report only mode on wikis. This means if you are loading external resources in your user scripts, you might get an error in your javascript console. Don't panic, so far we are only enabling report only, and will of course give people notice before actually enabling it enforcing. At this stage we are just gathering information on what the impact of CSP would be on the wikis and what sort of external javascript is used in practise. That said, if you are loading externally hosted javascript from your user JS page, we strongly suggest you do not do this for security reasons.
Quelle: https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2018-October/001994.html
Ist das etwas, das auf die Vorderseite sollte? Wer könnte es ggfs. allgemeinverständlich formulieren? — Raymond Disk. 15:32, 26. Okt. 2018 (CEST)
- Wenn man ein Skript aus einer fremden Quelle lädt (wobei fremd heißt: kein WMF-Wiki, Skripte von Commons oder so sind weiter kein Problem, wohl aber von Toolforge oder von wirklich fremden Seiten), dann gibt der Browser eine Warnung auf der Konsole aus und es wird serverseitig geloggt. Ansonsten funktioniert im Moment alles wie bisher auch. Prinzipiell ist geplant, dass solche Ladeversuche nicht nur protokolliert, sondern ganz verboten werden, aber soweit ist es noch nicht.
- Wenn jemand eine solche Warnung in der Konsole findet und er nicht weiß, dass er da ein Skript von sonstwo lädt (oder das zwar weiß, jetzt aber beschließt, dass er dem Inhaber dieser fremden Seite nicht wirklich vertraut), der sollte dafür sorgen, dass er eben dieses Skript nicht mehr lädt. Da es in der Vergangenheit schon Fälle gab, bei denen durch ein gehacktes Adminkonto irgendwelche Crypto-Mining-Skripte in die common.js eingebunden wurden, kann es durchaus sein, dass irgendwo irgendwas geladen wird, was man nicht laden will. Andererseits werden solche Fälle durch das serverseitige Loggen in Zukunft noch schneller entdeckt als bisher, sodass die Wahrscheinlichkeit, dass man etwas wirklich zweifelhaftes findet, doch ziemlich gering ist.
- Wer tatsächlich bewusst Skripte aus fremden Quellen lädt (etwa Benutzer von Wikipedia:Helferlein/Rechtschreibprüfung oder Benutzer:Schnark/js/personendaten/normdaten), der kann die Meldungen erst einmal ignorieren, nach gegenwärtigem Stand der Planung wird es für angemeldete Benutzer eine Einstellung geben, um das Laden von Skripten aus fremden Quellen dauerhaft zu erlauben.
- Alles in allem: Der „normale“ Benutzer braucht sich im Moment noch für nichts zu interessieren, und die anderen haben es ja jetzt hier gelesen. –Schnark 09:32, 27. Okt. 2018 (CEST)
Begriffsklärungsseiten unter Spezial:Linkliste
(kopiert nach Wikipedia:Verbesserungsvorschläge/Feature-Requests --PerfektesChaos 13:11, 21. Okt. 2018 (CEST))
- hier erledigt. --Wetterwolke (Diskussion) 09:01, 6. Nov. 2018 (CET)
BREAKING – mw.toolbar wird entfernt
Wie schon länger bekannt, soll die JavaScript-Bibliothekskomponente mw.toolbar nicht mehr unterstützt werden und wird offenbar in den kommenden Wochen tatsächlich wegfallen: phab:T30856 – mw:Contributors/Projects/Removal of the 2006 wikitext editor.
Das hat für uns mindestens zwei Konsequenzen:
- Die Werkzeugleiste mit den grauen 3D-Buttons von 2006 entfällt.
Sie solle auch nur noch eine Handvoll Anwender auf dewiki haben. - Unsere „Edittools“ in MediaWiki:Onlyifediting.js können nicht mehr funktionieren, da sie eine toolbar-Funktion nutzen.
Irgendwelche Benutzerskripte könnten ebenfalls betroffen sein.
Was den zweiten Fall angeht, habe ich schon seit längerer Zeit einen optisch zunächst gleichwertigen Ersatz in der Schublade:
- menuSwitcher@PerfektesChaos
- Sie kann das bisherige Verhalten zunächst exakt nachbilden (versteht das bisherige Konfigurationsobjekt), sofern diese Definitionen geladen werden.
- Zusätzlich bietet sie weitere Möglichkeiten zur Konfiguration durch Benutzer und hat ein Gedächtnis für die letzte Auswahl.
VG --PerfektesChaos 13:07, 21. Okt. 2018 (CEST)
- Es gibt auch noch Wikipedia:Helferlein/Extra-Editbuttons, das dann entweder umprogrammiert werden muss, oder nicht mehr funktionieren wird.
- Sonderzeichen, die für alle Benutzer im VE leicht einzufügen sein sollen, können übrigens einfach in MediaWiki:Visualeditor-quick-access-characters.json eingetragen werden. –Schnark 09:19, 22. Okt. 2018 (CEST)
- Ja, Wikipedia:Helferlein/Extra-Editbuttons von 2007 ist dann obsolet.
- Eine Neuprogrammierung lohnt nicht mehr, weil eine Simulation in der 2010 oder gar 2017 nicht darstellbar oder von vornherein schon abgedeckt ist. Es fehlen mindestens die Buttons, oder hätten nicht mehr das gewohte Erscheinungsbild, und wären in diversen Menüs verteilt.
- Etwa bis Mitte/Ende 2019 sollte auf dem Gadget-JS noch ein eingefügtes div mit der Aufforderung zur Bereinigung des Benutzerprofils von einem redundanten Häkchen erscheinen, bis das Gadget dann endgültig archiviert und eliminiert wird.
- Deshalb schrub ich oben erstmal „mindestens zwei Konsequenzen“, hatte aber erstmal nur gepostet und noch nicht weiter nach Details geflöht.
- Es gibt zwar Suchtreffer, aber nicht alle haben unmittelbar problematische Auswirkungen.
- Vorlagenmeister beispielsweise hat auch sowas, fragt aber zunächst nur, ob der momentane Benutzer eine 2006-Werkzeugleiste verwendet. Das kann dann mittelfristig eingekürzt werden, schadet aber bis auf Weiteres nicht, weil kein Anwender mehr eine solche am Start haben kann. Allerdings gibt es gleichzeitig eine dependency für IE-Benutzer wegen insertTags(); an die werde ich wohl ran müssen (bereits in Entwicklung).
- Viele Skripte, die einen Button/Link in die jeweilige Benutzeroberfläche einfügen wollen, fragen die aktuelle Situation ab und suchen sich dann einen geeigneten Landeplatz. Die brauchen erst angepasst werden, nachdem sich die Eliminierung auch als endgültig erwiesen hat. Soll ja manchmal Kurswechsel nach weltweitem Aufschrei geben. Die Absicht zur Abschaffung besteht schon seit 2011, da kann man das ohne Hektik angehen.
- Nebenbei mochte ich das kleine minimalistische schnelle lightweight von 2006 sehr gern.
- Mein oben erwähntes Skript kann übrigens auch eine graue-Button-Simulation für die traditionellen und wichtigsten Knöpfe.
- VG --PerfektesChaos 10:50, 22. Okt. 2018 (CEST)
- Ähm*,
mw.toolbar
wird aller Wahrscheinlichkeit nach als Gadget oder Erweiterung erhalten bleiben, somit sollte Extra-Editbuttons wohl ebenfalls (ohne großen Aufwand) erhalten bleiben. VG -- User: Perhelion 16:15, 22. Okt. 2018 (CEST)- Als Erweiterung bleibt das nicht erhalten, jedenfalls weiß ich von keiner. Dass in irgendeinem Wiki irgendjemand ein Gadget dafür programmiert, ist nicht unwahrscheinlich, aber solange das niemand hierher übernimmt, völlig irrelevant. Ob ein solches Gadget übernommen werden sollte, ist höchst fraglich, insbesondere bezweifle ich erst einmal, dass – wenn es überhaupt ein Gadget gibt – das keine deutsche Lokalisierung mehr hat. Selbst wenn es die alte Werkzeugleiste als Gadget hier gäbe, wäre immer noch nicht klar, ob es die bisherige API zum Erweitern bereitstellt, und falls ja, ob das auch zuverlässig funktioniert – insbesondere eine instabile Ladereihenfolge kann das verhindern. Ein weiterer Punkt, den man beachten müsste: Nicht alle Benutzer, die das Extra-Editbuttons-Gadget aktiviert haben, verwenden es auch, es würde mich sogar nicht wundern, wenn die Mehrheit der aktiven Benutzer, die es aktiviert haben, eine andere Werkzeugleiste verwenden und gar nicht wissen, was sie da aktiviert haben und daher negativ überrascht wären, wenn das Gadget bei ihnen plötzlich funktionieren würde.
- Betroffene Benutzer können – da es ja zeitlich passt – zu Allerseelen das Totenoffizium für die alte Werkzeugleiste und ihre Erweiterungen beten und sie dann in Frieden ruhen lassen. –Schnark 09:49, 24. Okt. 2018 (CEST)
- Ähm*,
- Ja, Wikipedia:Helferlein/Extra-Editbuttons von 2007 ist dann obsolet.
- Ich halte es für höchst unangemessen, hier die Benutzer für die Verwendung alter, aber bewährter Bearbeitungshilfen so herabzuwürdigen. Da sind jede Menge alte Hasen dabei, die genau wissen, was sie tun. Ich lästere ja auch nicht über den Visual Editor. Jeder, wie er mag.
- Wie das unter der Haube technisch gelöst wird, ist mir gleichgültig, Hauptsache es funktioniert. Es geht nicht an, daß technische Probleme unter den Entwicklern auf dem Rücken erfahrener Benutzer ausgetragen werden, die einfach nur ihre gewohnte Arbeitsumgebung behalten wollen. Eloquenzministerium (Diskussion) 12:54, 3. Nov. 2018 (CET)
- +1. Leute, ernsthaft: Das ist nicht lustig. Mir wird da ungefragt unter dem Hintern eine seit zig Jahren gut funktionierende Arbeitsgrundlage weggelöscht. Das kann und will ich nicht glauben. @Perhelion: Du schreibst oben, es gäbe einen Weg. Wie? Wann? Wer?
- Besser unter Wikipedia:Fragen_zur_Wikipedia#haben_Hamster_die_Bearbeitungssymbole_verschluckt? weiterdiskutieren? --JD {æ} 22:40, 5. Nov. 2018 (CET)
- nur noch eine Handvoll Anwender auf dewiki halte ich für Fake News. --Leyo 23:37, 5. Nov. 2018 (CET)
- Super, wenn man sich ohne wirksame Ankündigung dumm und dusslig suchen muss, warum die Bearbeitungsleiste plötzlich komplett weg ist. Und das unsigned-Skript funktioniert auch nicht mehr. Die WMF-Programmierer stellen irgendwas um, und der Normal-Wikipedianer steht blöd da, und weiß nicht, was er machen soll, damit er weiterarbeiten kann.
- Ganz großes Kino von der Foundation wieder einmal, man muss sie einfach lieben. Und wieso es bei WMF und WMDE inzwischen zahlreiche Mitarbeiter gibt, die sich um die Technik-Kommunikation in die Community kümmern sollen (zumindest laut Berufsbezeichnung), bleibt mal wieder ein großes Rätsel.
- Aber die nahezu völlig wirkungslosen Neulingskampagnen sind ja wichtiger, als die etablierten Leute nicht zu verärgern!
- Falls das gerade ziemlich sauer und genervt von mir rüberkommt: Dem ist exakt so. --Stepro (Diskussion) 08:26, 6. Nov. 2018 (CET)
Ich habe in meiner alten Kopie von MediaWiki:Onlyifediting.js die Entfernungen aus gerrit:317079 lokal übernommen und damit die Toolbar wieder aktiviert. --Fomafix (Diskussion) 09:23, 6. Nov. 2018 (CET)
- Letztgenanntes würde die Angelegenheit auf dem statischen Zustand von 2009 einfrieren. Keinerlei Fortschritt in einem Jahrzehnt.
- menuSwitcher@PerfektesChaos habe ich gerade deshalb geschrieben, damit ausgehend vom vertrauten Zustand (2009) Benutzer die Möglichkeit haben, die Menüs zu erweitern, insbesondere ganze eigene Menüreihen hinzuzufügen. Und viele zeitgenössische dynamische Möglichkeiten mehr.
- Das auch vor dem Hintergrund, dass die selbst konfigurierbaren Extra-Editbuttons weggefallen sind, und persönliche Ausbaumöglichkeiten erforderlich bleiben.
- VG --PerfektesChaos 09:48, 6. Nov. 2018 (CET)
- Diese Änderung ist als Anleitung zum Reparieren gedacht, weil danach mehrfach gefragt wird. --Fomafix (Diskussion) 11:11, 6. Nov. 2018 (CET)
Mal ganz dumm gefragt:
- Gibt es Einwände gegen die projektweite Nutzung von Benutzer:PerfektesChaos/js/menuSwitcher? Hier insbesondere @Schnark:
- Was genau müssten Oberflächenadministratoren bei einer Nutzung von Benutzer:PerfektesChaos/js/menuSwitcher tun, um das vorherige Verhalten erst einmal wieder standardmässig projektweit für alle Nutzer zu aktivieren?
--Count Count (Diskussion) 15:20, 6. Nov. 2018 (CET)
- Mal ganz dumm geantwortet:
- Keine Ahnung; ich weiß ja nichtmal, wie das Ding aussieht, wie ich es aktivieren könnte, was das Ganze kann.
- -
- Ich verlasse mich jetzt bis auf Weiteres auf DaB. [1].
- --JD {æ} 18:21, 6. Nov. 2018 (CET)
Benötige Hilfe zu EditTools
Moin, die Deaktivierung von mw.toolbar hat uns auch auf nds.wp getroffen. Leider haben wir keinen Oberflächenadministrator, so dass wir nicht mal selbständig die jetzt nicht mehr funktionierenden Skripte deaktivieren könnten... Wir haben jetzt unterhalb des Bearbeitungsfensters eine Zeile mit toten Zeicheneinfügelinks, die nichts mehr bewirken (eingefügt aus nds:MediaWiki:Onlyifediting.js).
Ich habe keine starken Emotionen, dass die Zeile in ihrer jetzigen Form erhalten bleiben muss, aber zumindest einige Zeichen müssen mit einem Klick erreichbar sein. Ich suche jetzt also nach Alternativen.
Meine erste Frage: was ist die aktuelle Entsprechung zu mw.toolbar.insertTags()
, die ich einsetzen muss, um Zeichen in Bearbeitungsfenster oder Zusammenfassungszeile einzufügen?
Meine zweite Frage: welche Möglichkeiten gibt es, die Toolbar oberhalb des Bearbeitungsfensters zu erweitern? Einerseits um Buttons auf der obersten Ebene, die also immer sichtbar sind, und andererseits um zusätzliche Zeichen oder Zeichenfolgen im entsprechenden Ausklapp-Menü „Sonderzeichen”? --::Slomox:: >< 10:45, 6. Nov. 2018 (CET)
- Mein Tipp:
- menuSwitcher@PerfektesChaos als Basis-Software verwenden.
- Dem kann man alle existierenden Definitionen als Grundausstattung verklickern; das Format wird verstanden.
- Danach kann jeder einzeln für sich diese projektseitige Definition erweitern, auch was rauslöschen, und mehr.
- Die Kollegen auf de-Wikisource handhaben das seit einem Jahr mit deren Altbestand in s:MediaWiki:Gadget-Sonderzeichenauswahl.js genauso.
- In nds: bräuchte ich einen lokalen Ansprechpartner, möglichst eine Art Technik-Werkstatt oder Forum, und einen passenden WP:BOA.
- LG --PerfektesChaos 10:58, 6. Nov. 2018 (CET)
- Danke! Das wird wohl der Weg sein, den ich gehen werde, je nachdem wie die Antworten auf meine Fragen oben ausfallen und was die anderen Nutzer auf nds.wp wünschen.
- Zu meiner ersten Frage oben habe ich die Antwort gefunden: In dieser Änderung taucht das notwendige JS auf, um Zeichen einzufügen (gefunden im Beitrag von Fomafix weiter oben auf der Seite, danke dafür).
- Offen ist dann nur noch die Frage, ob es möglich ist, die aktuelle Toolbar zu erweitern. --::Slomox:: >< 12:35, 6. Nov. 2018 (CET)
- Wie die Toolbar sich erweitern lässt, habe ich jetzt auch herausgefunden. Mit:
$('#wpTextbox1').wikiEditor('addToToolbar', {
'section': 'main',
'group': 'insert',
'tools': [
{
id: '',
label: '',
type: 'button',
icon: '',
action: {
type: 'encapsulate',
options: {
pre: '',
peri: '',
post: ''
}
}
}
]
});
- An dieser Stelle ist meine Frage also erledigt. @PerfektesChaos: Eventuell werde ich auf dein Angebot noch zurückkommen, muss aber erst klären, welche Lösung gewünscht ist. --::Slomox:: >< 16:08, 6. Nov. 2018 (CET)
Abschnittsverlinkung
- (Softwareneuheit) Versionsgeschichte: Der Link auf den Abschnitt, in dem Änderungen stattgefunden haben, wurde jetzt vom Pfeil (→) ausgedehnt auf den Abschnittsnamen, so dass der Linkbereich größer und somit leichter anklickbar ist (Task 165189, Gerrit:475230).
Kann das bitte auf die mobile Version beschränkt werden? In der Desktopversion ist dies unnötig bzw. stört: Nun ist in der Beobachtungsliste fast alles blau … --Leyo 11:19, 30. Nov. 2018 (CET)
- Hmm, ich finde diesen Link hilfreich - arbeite mit Desktop. --tsor (Diskussion) 11:21, 30. Nov. 2018 (CET)
- … und triffst das Pfeilsymbol mit der Maus nicht?! --Leyo 11:22, 30. Nov. 2018 (CET)
- Hast recht, den Pfeile treffe ich noch trotz meines fortgeschrittenen Alters. Ob das in 3 Jahren noch klappt? ;-)) --tsor (Diskussion) 11:28, 30. Nov. 2018 (CET)
- … und triffst das Pfeilsymbol mit der Maus nicht?! --Leyo 11:22, 30. Nov. 2018 (CET)
Mich stört dies wie Leyo auch sehr! Monobook und Desktop. --KurtR (Diskussion) 17:08, 30. Nov. 2018 (CET)
- +1. --JD {æ} 17:30, 30. Nov. 2018 (CET)
- +1 Finde das extrem verwirrend. Sophie 19:16, 30. Nov. 2018 (CET)
Also ich finde die neue Verlinkung ziemlich praktisch. Den Pfeil-Link vorher kannte ich wohl, aber irgendwie hab ich den nie genutzt, weil er nicht auf den ersten Blick als Direktlink erkennbar war. Jetzt wo der ganze Titel verlinkt ist, hab ich da ziemlich fix meine Gewohnheiten angepasst und was soll ich sagen … das ist sehr angenehm. Ich würde das ungern wieder verlieren. —MisterSynergy (Diskussion) 18:01, 30. Nov. 2018 (CET)
- +1 zu MisterSynergy, es erleichtert gerade bei langen Diskussionsseiten einiges. Darstellungsprobleme gibt es keine. mfg --Crazy1880 19:44, 30. Nov. 2018 (CET)
- +1, ich finde die Umstellung auch gut. Wem das zu bunt ist, kann das bestimmt leicht über eine benutzerdefinierte CSS-Regel ergrauen. --CorrectHorseBatteryStaple (Diskussion) 19:51, 30. Nov. 2018 (CET)
Im Phabricator wird das aktuell alles noch diskutiert. Die weitgehende Bläuung mancher Seiten empfinde ich auch als unschön, doch die Verlinkung bietet auch Vorteile. Sie wurde ursprünglich für die Desktopdarstellung gewünscht. Der beste Ort für Kritik ist im Phabricator oder auf der wishlist, die auch dort verlinkt ist: Phab:T165189. --Holmium (d) 20:20, 30. Nov. 2018 (CET)
Mich stört es nicht groß. Es ist mir nichtmal aufgefallen, bis ich das hier gelesen hatte. -- Chaddy · D 20:57, 30. Nov. 2018 (CET)
Zumindest auf einem Tablet ist die Komplett-Verlinkung deutlich praktischer, der Link war mit Touch-Bedienung manchmal schwer zu treffen. --Kam Solusar (Diskussion) 21:02, 30. Nov. 2018 (CET)
- Genau deswegen bezog ich mich ja eingangs auf die Desktop-Version. Je nach Textlänge der Abschnittslinks ist die Beobachtungsliste (oder die letzten Änderungen/Benutzerbeiträge) eine blauen Bleiwüste. :-( Ein Bearbeitungskommentar mit Wikilink kann nun leicht übersehen werden. --Leyo 00:12, 1. Dez. 2018 (CET)
- Wäre es nicht optimal, daraus eine Einstellung zu machen? Dann kann jeder selber entscheiden.... (oder ein Gadget für das alte Verhalten). Viele Grüße, Luke081515 00:55, 1. Dez. 2018 (CET)
- Ich meinte ebenfalls die Desktop-Version. Auf Tablets ist man ja bei ausreichender Bildschirmgröße nicht gezwungen auf die (IMO) schlechtere Mobil-Variante zu wechseln. --Kam Solusar (Diskussion) 07:00, 1. Dez. 2018 (CET)
- War es zuvor nicht eigentlich möglich im Abschnittslinktext vorhandene Verlinkungen zu erkennen? Mir ist zumindest so, als wäre das so gewesen. Das ist aber in der Form ganz sicher unmöglich, da alles ein blaues Wischiwaschi ist.
- Zugegeben, es hat auch bei mir recht lange gedauert, bis ich mal verstanden hatte, dass der Pfeil → ein Link zum Abschnitt ist. Aber man könnte das durchaus auch anders kennzeichnen, beispielsweise so
- (→ Abschnittsverlinkung: Ich habe etwas hinzugefügt)
- Es kommt schon des Öfteren vor, dass da Links im Abschnittstitel stehen. Und wenn dann noch jemand aktiv Verlinkungen in den Bearbeitungskommentar setzt, um auf Richtlinien oder einen Difflink hinzuweisen, weiß (oder sieht) man möglicherweise nicht mehr, ob das ein eigenständiger Link oder ein Teil des Abschnittstitels ist. Beispiel das
so?
ist auch ein Link, alles ist somit blau. - Ich finde das nicht wirklich nur vorteilhaft. --Liebe Grüße, Lómelinde Diskussion 09:25, 1. Dez. 2018 (CET)
- Ich find's auch auf dem Desktop praktisch. — Raymond Disk. 11:41, 1. Dez. 2018 (CET)
- Was um alles in der Welt ist daran störend? fragt sich --Kpisimon (Diskussion) 12:06, 1. Dez. 2018 (CET)
- Es erschwert die Erkennung tatsächlicher Links in der Zusammenfassungszeile im Unterschied zu den normalen Abschnittsbearbeitungen. Ich finde das auch ziemlich störend. --Prüm 12:30, 1. Dez. 2018 (CET)
- Vor allem, wenn so ein Schwachsinn wie hier dabei rauskommt. Ich hatte gar nichts in der Zusammenfassungszeile geschrieben. NNW 17:38, 1. Dez. 2018 (CET)
- Es erschwert die Erkennung tatsächlicher Links in der Zusammenfassungszeile im Unterschied zu den normalen Abschnittsbearbeitungen. Ich finde das auch ziemlich störend. --Prüm 12:30, 1. Dez. 2018 (CET)
Wenn man dem Link noch eine Klasse spendiert, könnte sich den jeder wie persönlich gewünscht (ent-)färben. -- hgzh 12:41, 1. Dez. 2018 (CET)
- Ernst gemeint? Schau dir mal den Quelltext der Letzten Änderungen an, der ist sowieso schon aufgeblasen wie sonst was. --Prüm 14:29, 1. Dez. 2018 (CET)
- Ja, ernst gemeint. Wen interessiert die Quelltextgröße? -- hgzh 19:19, 1. Dez. 2018 (CET)
Solche Neuerungen sollten bitte als opt-in laufen. Nur als opt-in.--Aschmidt (Diskussion) 19:27, 1. Dez. 2018 (CET)
- +1 zu "es stört" (auf Desktop) -jkb- 19:33, 1. Dez. 2018 (CET)
na, also ich hab mich gefreut drüber, mit kleinerem notebook (12zoll/10zoll) ist definitiv praktischer, v.a. ohne maus. und am desktop störts mich nicht weiter. Und: für newbies ist es auch intuitiver greifbar. grüße --Rax post 19:54, 1. Dez. 2018 (CET)
Nun werden die Abschnittslinks in grauer Schrift angezeigt. Dies ist IMHO ein guter Kompromiss. --Leyo 10:13, 4. Dez. 2018 (CET)
- Gibt es denn eine CSS-Klasse, mit der ich das einfach wieder blau bekomme? Wie oben bereits gesagt, ich weiß grundsätzlich dass da Links sind, aber ich klicke sie nicht wenn sie nicht als solche erkennbar sind. —MisterSynergy (Diskussion) 12:52, 4. Dez. 2018 (CET)
- Versuch bitte mal folgendes in deine common.css einzufügen
.autocomment, .autocomment a {
color: #0645AD;
}
- Ich hoffe das ist korrekt, um das grau zu überschreiben. Ich habe es zwar in der Vorschau (für die Zusammenfassungszeile) getestet, aber nicht gespeichert. --Liebe Grüße, Lómelinde Diskussion 13:24, 4. Dez. 2018 (CET)
- Danke, das "klappt" weitgehend. In meta:User:MisterSynergy/global.css musste da aber noch eine Skin-Weiche dazu, weil im Timeless-Skin, den ich hier nutze, der Standardblauton ein anderer ist als im Vector-Skin, den ich überall anders nutze. Sofern ich das richtig verstehe, wird jetzt das Standard-Linkblau von Mediawiki überschrieben mit diesem Grau, und ich überschreibe das dann wieder mit dem skinabhängigen Standardblau. Hoffentlich läd das immer in der richtigen Reihenfolge, und hoffentlich wird
autocomment
nirgendwo in anderem Context verwendet. —MisterSynergy (Diskussion) 13:46, 4. Dez. 2018 (CET)- Ich habe davon eigentlich absolut gar keine Ahnung, ich habe nur etwas in der Konsole geschaut und nach dem Motto „was passiert dann“ herumprobiert. Ich wüsste nicht einmal was eine Skinweiche ist oder wie man die einbaut. --Liebe Grüße, Lómelinde Diskussion 13:59, 4. Dez. 2018 (CET)
- In meiner verlinkten global.css steht das ganz unten drin. Letztlich muss die Anweisung wegen der verschiedenen Standardfarben für jeden genutzten Skin separat erfolgen, und da wird dann ein skin-spezifischer Selektor mit eingebaut. Was mich etwas ärgert ist, dass das am Ende doch eigentlich eine Pfuschlösung ist (was ich ausdrücklich nicht Dir anlaste). Es ist nicht schwierig, solchen CSS-Code mit den Webdeveloper-Tools der modernen Browser selbst zu erarbeiten, aber schwer ist festzustellen, ob es irgendwo unerwünschte Seiteneffekte gibt – beispielsweise weil die autocomment-Klasse irgendwo anders auch genutzt wird, oder etwa race conditions bei der Codeausführung auftreten. —MisterSynergy (Diskussion) 14:26, 4. Dez. 2018 (CET)
- Ich habe es mir durchaus angesehen, aber, wie gesagt, habe ich von all dem zu wenig Ahnung. Ich bin schon froh, dass ich herausgefunden habe wie die Bezeichnung lauten muss, um das anzusprechen. Ich denke hier sollten wir das nicht weiter ausdehnen, wenn du mal Lust oder Zeit hast, kannst du mir gern ein Paar Dinge auf meine Diskussionsseite der common.css schreiben. Vielleicht lerne ich dann noch etwas dazu. Dankeschön für die Erklärung. --Liebe Grüße, Lómelinde Diskussion 14:41, 4. Dez. 2018 (CET)
- Hallo, es scheint wohl nicht möglich zu sein, eine einzelne CSS-Farbdefinition durch Überschreiben unwirksam zu machen. Den gewünschten Effekt kann man allerdings durch Entfernen der neuen (?) CSS-Klasse erreichen, indem man in der eigenen Skin-unabhängigen Benutzer-JavaScript-Seite common.js den Code einträgt. --Wiegels „…“ 15:32, 4. Dez. 2018 (CET)
$('.autocomment').removeClass('autocomment');
- Also ohne zu wissen wo
autocomment
überhaupt eingesetzt wird, halte ich das für ziemlich riskant. - Technisch wäre es im Übrigen tatsächlich einfacher gewesen, die Links einfach ohne spezielle Formatierung (blau) anzubieten, und wer das grau haben möchte, überschreibt den Standard; die jetzt angebotene Lösung überschreibt das blau mit grau, und wer blau haben möchte, muss das überschreibene grau erneut mit dann Skin-abhängigem blau überschreiben. Leider reichen viel zu oft ein paar Proteststimmen aus, um jegliche Veränderung an der Software zu unterdrücken :-( —MisterSynergy (Diskussion) 17:53, 4. Dez. 2018 (CET)
- Also ohne zu wissen wo
- Hallo, es scheint wohl nicht möglich zu sein, eine einzelne CSS-Farbdefinition durch Überschreiben unwirksam zu machen. Den gewünschten Effekt kann man allerdings durch Entfernen der neuen (?) CSS-Klasse erreichen, indem man in der eigenen Skin-unabhängigen Benutzer-JavaScript-Seite common.js den Code
- Ich habe es mir durchaus angesehen, aber, wie gesagt, habe ich von all dem zu wenig Ahnung. Ich bin schon froh, dass ich herausgefunden habe wie die Bezeichnung lauten muss, um das anzusprechen. Ich denke hier sollten wir das nicht weiter ausdehnen, wenn du mal Lust oder Zeit hast, kannst du mir gern ein Paar Dinge auf meine Diskussionsseite der common.css schreiben. Vielleicht lerne ich dann noch etwas dazu. Dankeschön für die Erklärung. --Liebe Grüße, Lómelinde Diskussion 14:41, 4. Dez. 2018 (CET)
- In meiner verlinkten global.css steht das ganz unten drin. Letztlich muss die Anweisung wegen der verschiedenen Standardfarben für jeden genutzten Skin separat erfolgen, und da wird dann ein skin-spezifischer Selektor mit eingebaut. Was mich etwas ärgert ist, dass das am Ende doch eigentlich eine Pfuschlösung ist (was ich ausdrücklich nicht Dir anlaste). Es ist nicht schwierig, solchen CSS-Code mit den Webdeveloper-Tools der modernen Browser selbst zu erarbeiten, aber schwer ist festzustellen, ob es irgendwo unerwünschte Seiteneffekte gibt – beispielsweise weil die autocomment-Klasse irgendwo anders auch genutzt wird, oder etwa race conditions bei der Codeausführung auftreten. —MisterSynergy (Diskussion) 14:26, 4. Dez. 2018 (CET)
- Ich habe davon eigentlich absolut gar keine Ahnung, ich habe nur etwas in der Konsole geschaut und nach dem Motto „was passiert dann“ herumprobiert. Ich wüsste nicht einmal was eine Skinweiche ist oder wie man die einbaut. --Liebe Grüße, Lómelinde Diskussion 13:59, 4. Dez. 2018 (CET)
- Danke, das "klappt" weitgehend. In meta:User:MisterSynergy/global.css musste da aber noch eine Skin-Weiche dazu, weil im Timeless-Skin, den ich hier nutze, der Standardblauton ein anderer ist als im Vector-Skin, den ich überall anders nutze. Sofern ich das richtig verstehe, wird jetzt das Standard-Linkblau von Mediawiki überschrieben mit diesem Grau, und ich überschreibe das dann wieder mit dem skinabhängigen Standardblau. Hoffentlich läd das immer in der richtigen Reihenfolge, und hoffentlich wird
- Ich hoffe das ist korrekt, um das grau zu überschreiben. Ich habe es zwar in der Vorschau (für die Zusammenfassungszeile) getestet, aber nicht gespeichert. --Liebe Grüße, Lómelinde Diskussion 13:24, 4. Dez. 2018 (CET)
Gerrit:477030 wird diese Woche, vermutlich am Donnerstagabend, die Farbe grau zentral wiederhergstellt, dabei die neue Form der Verlinkung aber beibehalten. — Raymond Disk. 20:01, 4. Dez. 2018 (CET)
Info: Bevor ihr euch mit allen möglichen lokalen CSS-/JS-Hacks "eure" Farbe zurechtbastelt: Per- Das war bei mir schon heute Mittag grau, und User:Leyo’s Kommentar deutet das auch an. Da ich das Grau nicht haben möchte, muss ich eh was machen. —MisterSynergy (Diskussion) 20:07, 4. Dez. 2018 (CET)
- MisterSynergy: Wo das Grau bei dir herkommt, kann ich gerade nicht sagen. Bei mir im Vector-Skin ist noch alles blau (was für mich auch OK ist, auch auch grau ist OK für mich. Oder grün?). — Raymond Disk. 20:15, 4. Dez. 2018 (CET)
- Die graue Färbung kommt von hier. --Wiegels „…“ 20:53, 4. Dez. 2018 (CET)
- MisterSynergy: Wo das Grau bei dir herkommt, kann ich gerade nicht sagen. Bei mir im Vector-Skin ist noch alles blau (was für mich auch OK ist, auch auch grau ist OK für mich. Oder grün?). — Raymond Disk. 20:15, 4. Dez. 2018 (CET)
Natives SVG
Passend zum Abschnitt über mir: Wird Mediawiki jemals richtig SVG unterstützen? Damit meine ich, dass der Browser SVG direkt rendern darf und nicht immer Mediawiki erst ein PNG daraus macht. Bei anderen Webtechniken ist Mediawiki oft auf dem aktuellen Stand, nur um SVG (das immerhin hier extrem weit verbreitet ist) wird ein großer Bogen gemacht. Das ist Schade. --195.192.204.115 17:30, 20. Dez. 2018 (CET)
- Das ist kompliziert. Es gibt nämlich (leider) auch Gründe die dafür sprechen, die Bilder auf dem Server zu rendern und als PNG auszuliefern:
- Einige SVGs sind sehr groß (etliche Megabyte) und als PNG in thumbnail-größe nur wenige Kilobyte groß
- Manche SVGs sehen in jedem Browser anders aus.
- Es gibt daher die Überlegung das pro Dateieinbindung auswählbar zu machen, ob es als Vektor-Grafik (svg) oder als Raster-Grafik (png) ausgeleifert werden soll. Meines Wissens arbeitet aber leider noch niemand daran. :( -- Michi 19:28, 20. Dez. 2018 (CET)
- Eine Möglichkeit wäre auch, das ganze mit einem Parameter beim Einbinden zu klären. hier haben wir selbst bei der 320px Version einen höheren Speicherbedarf und außerdem wäre es somit möglich animierte SVG einzubinden. Bei manchen SVG wäre natürlich häufig schlauer zu Rendern, deshalb könnte wir ja eine kann-Regelung schafen (z. B.
[[Datei:Coat of Arms of Great Britain (1714-1801).svg|320px]]
oder[[Datei:Reiss-Engelhorn-Museen.svg|320px|svg]]
) --Habitator terrae 21:31, 20. Dez. 2018 (CET)
- Eine Möglichkeit wäre auch, das ganze mit einem Parameter beim Einbinden zu klären. hier haben wir selbst bei der 320px Version einen höheren Speicherbedarf und außerdem wäre es somit möglich animierte SVG einzubinden. Bei manchen SVG wäre natürlich häufig schlauer zu Rendern, deshalb könnte wir ja eine kann-Regelung schafen (z. B.
SVG können unerlaubte automatisch ausgeführte URL enthalten (Zählpixel), und man kann versuchen noch fiesere Sachen darin zu verstecken. Insofern ist da erstmal eine Sicherheitsprüfung auf dem Wiki-Server angesagt.
- Browser teilen in ihrem Abfrageprofil eine ganze Menge mit, und der Browser des Lesers kann offenbaren, ob er SVG (eines bestimmten Levels?) selbst rendern kann. Sobald das hinreichend breit verfügbar ist, kann man überlegen, ob der Wiki-Server diesen Anfragen mit SVG antwortet, sonst PNG.
VG --PerfektesChaos 22:12, 20. Dez. 2018 (CET)
- Siehe phab:T5593 und die dort verlinkten Tasks. –Schnark 08:51, 21. Dez. 2018 (CET)
Technische Wünsche: Vorschau von Einzelnachweisen im Artikeltext
Hallo, in Kürze beginnen die Arbeiten am Wunsch Vorschau von Einzelnachweisen im Artikeltext. Mehr Information zur geplanten Funktion gibt's hier. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 12:55, 6. Dez. 2018 (CET)
- zum archivieren. --Wetterwolke (Diskussion) 13:55, 10. Apr. 2019 (CEST)
Multilinguale SVG-Grafiken
- (Softwareneuheit) SVGs mit mehreren Sprachebenen werden automatisch in der Inhaltssprache des Wikis dargestellt
Hm, weshalb werden denn die multilingualen Grafiken unter Wikipedia:Grafikwerkstatt#Multilinguale Grafik auf Englisch angezeigt? Ist dies NR-abhängig? --Leyo 09:34, 10. Dez. 2018 (CET)
- Der Abschnitt befindet sich inzwiuschen unter Wikipedia:Grafikwerkstatt/Archiv/2018/November#Multilinguale Grafik. Die Frage ist leider noch ungeklärt. --Leyo 14:35, 22. Jul. 2019 (CEST)