Wikipedia Diskussion:Projektneuheiten

Archiv

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte morgens automatisch archiviert, deren jüngster Beitrag mehr als 14 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

MediaWiki:Spam-blacklisted-category

re Special:Diff/128499385. Vorschlag für Inhalt der obigen Systemnachricht: „Wikipedia:Seiten mit Links auf der Spam-blacklist“, alternativ auch das B groß geschrieben. --se4598 / ? 15:06, 14. Mär. 2014 (CET)

Veto.

„Spam-blacklist“ ändert gerade ihren Namen auf „Weblinks/Filter“.

Hat noch ein paar Tage Zeit; bitte mit user:lustiger seth abstimmen.

Könnte demnach auch etwas wie Wikipedia:Seiten mit gefilterten Weblinks werden.

VG --PerfektesChaos 15:29, 14. Mär. 2014 (CET)

Hast du dazu weitere Infos? Gefilterte Weblinks hört sich ja jetzt auch nicht schlecht an. Da dazu seth anscheinend gerade noch etwa 3 Wochen im Urlaub ist, fände ich den obigen Vorschlag oder deinen besser als wenn die zwischenzeitlich in Kategorie:Seiten mit schwarzgelisteten Links aufschlagen. --se4598 / ? 15:41, 14. Mär. 2014 (CET)

Dazu gehört noch Gerrit:118636, der aber noch nicht reviewed ist. Damit werden Blacklist-Weblinks im Artikel entlinkt bzw. entfernt. Ich denke, das muss man im Gesamtkontext sehen. Ich habe mich nämlich schon gefragt: wozu eine Kategorie, wenn man doch gar keine Blacklist-Weblinks abspeichern kann. — Raymond ^Disk. 15:44, 14. Mär. 2014 (CET)

Ich habe die Kategorie erstmal auf deaktiviert gesetzt. Ich sehe noch kein Nutzen darin, Seiten aufzulisten die ein geblackten Link enthalten. Vorallem nicht, wenn die Änderung der Blacklist nicht ein LinkUpdate zur Aktualisierung der Kategorieeinträge auslöst. Soweit ich weiß, wurde auf de.wp auch mal Links auf die Blacklist gesetzt, obwohl die bereits existierenden Links okay sind. Dann müsste man solche Links auf die Whitelist setzen, auch wenn man sie nicht in weiteren Artikeln haben möchte oder so. Der Umherirrende 15:50, 14. Mär. 2014 (CET)

Namensgebung: MediaWiki Diskussion:Spam-blacklist #name der unterseite

Zeitplan: April und seth abwarten. Solange niemand die Kat auswertet, muss sie auch noch nicht aktiviert und benannt sein, und spam-blacklisted-text, spam-blacklisted-bad-text sowie spam-blacklisted-url können dann im Zusammenhang konfiguriert werden.

Schönen Sonntag --PerfektesChaos 21:58, 14. Mär. 2014 (CET)

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte. →seth

gudn tach!

zum text:

eigentlich egal, ob erst mal "Seiten mit Links auf der Spam-blacklist" oder -- mit blick auf die kuenftige umbenennung -- "Seiten mit gefilterten Weblinks". nur bei den "schwarzgelisteten Links" musste ich ehrlich gesagt lachen.

zum neuen feature: @Raymond, ich hab's noch nicht verstanden. Der Umherirrende hat recht, dass das bisherige verhalten als feature interpretiert und genutzt wurde und man sich bei einer aenderungen recht viel arbeit aufhalsen wuerde. -- seth 22:31, 10. Apr. 2014 (CEST)

Interwiki-Präfix c:

Ich denke, wir sollten keine große Reklame machen für das Dings (obwohl die Existenz dokumentiert werden muss).

Das ist so unanschaulich und verwirrend wie nur was. Das gleiche Problem gab es schon mal mit m: – von dem kein normaler Nutzer weiß, was es bedeutet. Okay, es wissen auch nur wenige, was das Meta-Projekt ist (was machen die da eigentlich??), aber meta: ist wenigstens selbsterklärend.

• WSTM macht aus allen angetroffenen m: ein meta: und wird sich zukünftig entsprechend bei c: verhalten.
• Wir sollten unsere Quelltexte für Normalbenutzer verständlicher machen und nicht mit immer mehr kryptischen und unverständlichen Abkürzungen immer mehr zur Expertensache. Es ist mir auch egal, ob die enWP das immer schon ganz toll fand.
• Wenn sich Profis auf ihrer Disk oder in der DÜP unterhalten, dann sollen sie es machen, wie sie wollen. Mindestens in Artikeln, Hilfeseiten und auf allgemeinen Projektseiten hat das nix am Suchen.

Der Abkürzungswahn greift immer mehr um sich. Es gibt Tausende von Shortcuts, wobei das Pikante ist, dass diejenigen, die diese Shortcuts zum Verlinken nehmen, regelmäßig auf die falschen Seiten verweisen und den Leser aus der Kurve tragen; nicht mal diese begeisterten Anwender der Shortcuts haben Ahnung davon, was das wirkliche Seitenziel ist. Es gibt inzwischen auch jede Menge Vorlagen, bei denen ich als Werkstattler schon nicht mehr durchsteige, was der Zweck sein soll. Preisfrage: Was ist „AZ“? Nein, nicht die Automatische Zusammenfassung; es geht offenbar um eine Zeitung. Aber welche? Aachener Zeitung? Abendzeitung – welche? Allgemeine Zeitung, wenn ja: welche? Augsburger Zeitung?

Grüße --PerfektesChaos 18:30, 29. Apr. 2014 (CEST)

Mir würde gefallen, wenn die Abkürzungen vor dem Speichern automatisch expandiert werden würden. Der Autor kann seine geliebten Abkürzungen verwenden und alle anderen sehen die normalen ausgeschriebenen Schreibweisen. Lässt sich so etwas umsetzen? Für die Suchfunktion wäre so etwas auch praktisch. --Fomafix (Diskussion) 21:49, 29. Apr. 2014 (CEST)

Es gibt eine alte Grundregel: Der Wikitext wird so gespeichert, wie er da steht; mit sehr wenigen Ausnahmen (etwa die Tilden). Er kann so falsch sein, wie er mag, und eine noch nicht einmal fest in der Software verankerte Zuordnung wie hier, die letztlich projekt-konfiguriert sein kann oder volatil über die Interwiki-Map, wird kaum in das Abspeicherungs-PHP fest verdrahtet aufgenommen werden. LG --PerfektesChaos 22:07, 29. Apr. 2014 (CEST)

Der Pipe-Trick wird auch beim Speichern expandiert. Das betrifft ebenfalls Links. Vielleicht kann die Expansion auch clientseitig durchgeführt werden. Bei der Suchfunktion wäre eine Ersetzung auch rein mit JavaScript realisierbar. Eine projektspezifische oder gar benutzerspezifische Ersetztabelle würde mir hier gefallen. --Fomafix (Diskussion) 22:18, 29. Apr. 2014 (CEST)

Der Pipe-Trick war der andere Fall, der mir bei „mit sehr wenigen Ausnahmen“ vorschwebte.

Pipe-Trick und Tilden stehen aber seit zehn Jahren unmittelbar in der PHP-Implementierung spezifisch hardcoded.

Clientseitig ist Horror, weil nowiki und syntaxhighlight geparsed sein müssen; auch das Innere von Kommentaren. Mit einer trivialen JavaScript-Textersetzung wird das nichts, ich weiß, was ich in WSTM anstelle, um Linkziele zu identifizieren. Und das dann in der Zehntelsekunde, um den bearbeiteten Text abzuspeichern, und wobei nichts schiefgehen darf, und dann ist es ohne Einflussnahme des Bearbeiters abgespeichert.

Ich glaube nicht, dass sich die weltweite PHP-Programmierung auf solche Funktionen einlassen würde.

Wir sollten zurück zum Ausgangspunkt kommen: Wollen wir das in der deWP, und was raten wir Autoren?

VG --PerfektesChaos 23:12, 29. Apr. 2014 (CEST)

Mit Ersetzungen durch JavaScript habe ich an den Linkeingabedialog vom WikiEditor gedacht. Die gleiche Ersetzung kann auch interaktiv in der Suche verwendet werden. Konkret wünsche ich mir, dass bei der Eingabe von „k:“ nach Kategorien gesucht wird, aber ohne Alias. International wäre hier das „c:“ passend. Genau das ist aber jetzt ein Alias für Commons. --Fomafix (Diskussion) 08:18, 30. Apr. 2014 (CEST)

Ah so, Namensaum-Aliasse, die nur im Suchfeld gelten aber nicht als Verlinkung möglich wären? Halte ich für keine glückliche Idee, weil:

1. Jeder dritte Benutzer die dann auch als Verlinkung einsetzt und sich bitter beschwert, dass das nicht funktioniert.
2. Wenn k: zu Kategorie: expandiert wird, dann werden Bandnamen wie k:o oder sonstige Kreationen nicht mehr auffindbar; bzw. können nicht mehr über das Formular verlinkt werden.
3. Wenn ein Seitentitel nicht (mehr) zulässig ist, weil Alias etc., dann kann man ihn weder suchen noch verlinken. Wenn es aber ein zulässiger Seitentitel ist, dann darf es keine Sonderregelungen geben, die seine Handhabung auf unvorhergesehene Weise erschweren.

Ich verstehe ja, dass du das gern abkürzen würdest; und mich nervt auch Vorlage: einzutippen, aber grad vor zwei Sekunden habe ich das glatt geschafft. b: sind aber books und nicht Benutzer: und die Vorlage v: ist, nein, nicht voyage, versity. Man kann auch doi:10.1000/182 in die Suchbox eintippen und bekommt eine für manche unerwartete Antwort.

• Noch mehr Alias-Regeln und Abkürzungen und Ausnahme-Extras neben der Liste der NR-Aliasse sowie der IW-Map, die man ungefähr im Kopf haben müsste, verkomplizieren die Sache weit mehr als es einer Handvoll Experten-Benutzern mal ein paar Tastendrücke spart.
• Es ist nicht nur eine Frage, was einem Computer syntaktisch möglich ist, um zweifelsfrei einen Namen aufzulösen. Es gehören auch Menschen dazu, die sich zu jeder gelesenen und eingetippten Abkürzung merken können, zu welcher Wirkung sie expandiert würde. Mit einem Dutzend der besonders unanschaulichen Ein-Buchstaben-Abkürzungen, der durch ISO 639 eingeschränkten Welt der Zwei- und Drei-Buchstaben-Abkürzungen samt dazwischen herumgeisternden Nicht-Sprachen-Präfixe ist schon längst eine Grenze erreicht, die Normalbenutzer nur noch außen vor lässt.
• Und das alles, damit einige Nerds ein paar Tasten weniger zu drücken brauchen; ich arbeite hingegen viel mit C&P.

Schönen Tag --PerfektesChaos 10:20, 30. Apr. 2014 (CEST)

Ich habe häufig genug nicht funktionierende Links nach Commons:Forum#Problemfall gesehen, weil schon commons: davor stand und vielfach nicht verstanden wurde, dass für den Commons-Namensraum auf Commons commons:commons:Forum verlinkt werden muss. Es wäre grob idiotisch, Leuten jetzt die Abkürzung zu verheimlichen. Wer eine andere Projektsprache verlinken will, soll das Sprachkürzel davorpacken. Wer auch ein anderes Projekt verlinken will, packt das Projektkürzel davor. Wer das verinnerlicht hat, wird auch keine Probleme mehr mit c:commons:Forum haben und es intuitiv machen. -- 32X 09:48, 3. Mai 2014 (CEST)

+1 — Raymond ^Disk. 09:56, 3. Mai 2014 (CEST)

Wenn man es als commons:Commons:Forum schreibt, wird es eigentlich auch ersichtlich, das erst der Projektwechsel und dann der Namensraum gemeint ist. Dein Beispiel sollte man dann aber als c:Commons:Forum schreiben, weil die Zielseite ja auch ein Großbuchstaben am Namensraumanfang hat. Abkürzungen haben immer Vor- und Nachteile. Der Umherirrende 13:03, 3. Mai 2014 (CEST)

Kommendes jQuery-Upgrade (breaking change) von v1.8.3 auf v1.11.x

Info an die hier mitlesenden JS-Entwickler: jQuery wird bei uns demnächst von v1.8.3 auf v1.11.x geupgraded. Dabei verschwinden auch einige veraltete jQuery-Funktionen. Siehe Mailinglist-Post für mehr Infos. --se4598 / ? 22:42, 7. Mai 2014 (CEST)

mw:Talk:Compact_Personal_Bar

Ich würde gerne Rückmeldung zu der compact personal bar geben, aber Flow funktioniert nicht („An error occurred while contacting the server.“) und in #mediawiki fühlt sich auch niemand zuständig. Daher hier auf Zwischenlagerung, bis Flow funktioniert. –ireas (Diskussion) 12:01, 9. Mai 2014 (CEST)

Many users are adding items to the personal bar using the addPortletLink JS function with p-personal. As far as I see, there is no (easy) possibility to add items to the compact personal bar as there are no element IDs. It would be great if (1) the hitherto existing possiblity to use addPortletLink("p-personal", ...) would continue to work (but I guess it’s not possible) or (2) there is a JS method that adds an item to the regular personal bar or the compact personal bar (depending on which is activated at the moment). –ireas (Diskussion) 12:01, 9. Mai 2014 (CEST)

• Es hat vielleicht der oberste Software-Entwickler seinen Daumen dazwischengehalten und das Absenden aufgehalten.
• Das Dings reduziert nur die persönliche Leiste angemeldeter Benutzer auf Smartphone-Breite, nicht aber die Vector-Leiste usw. mit den Seitenfunktionen.
• Die in WP:GUI #Seitenaufbau in magenta dargestellten Selektoren sind im Wesentlichen vorhanden: #p-personal #pt-preferences #pt-betafeatures #pt-watchlist #pt-mytalk #pt-notifications #pt-logout
  • Es ist wie bisher eine (jetzt mehrere) <ul> – die Links wurden bislang als <li> eingefügt.
  • Ohne es getestet zu haben, würde ich denken, dass vorhandener einfügender Code problemlos weiter funktionieren sollte. Ich sehe erst mal nichts, was dagegen spräche.
  • Optisch mag man das unter den Bedingungen der Mini-Leiste etwas anders anordnen wollen, und zukünftiger JS-Code kann herausfinden, ob ein flyout vorhanden ist, und das dann ggf. anders handhaben wollen.
  • Das sollte dann dementsprechend in Other items added by extensions & gadgets landen; dafür sehe ich aber noch keinen vorbereiteten Selektor. Ob der es dann auch schafft, sein Lineal einzufügen, müsste ggf. mw.util zwecks Nacharbeit beim Layout anschubsen.
• Du kannst dir expertenmäßige Pluspunkte einhandeln, wenn du schreibst mw.util.addPortletLink() – weil obsoleting.
• Du kannst aber für mich mitfragen:
  • Was soll Help und Datenschutz als personalisiertes Feature da mittenmang?

    Das muss für die nicht angemeldeten Benutzer sowieso irgendwo auf dem Portal stehen; ist hier also redundant und nimmt nur Platz weg. Es ist auch nicht wie alle anderen Items personalisiert und deshalb nicht nachvollziehbare Systematik.

LG --PerfektesChaos 09:49, 10. Mai 2014 (CEST)

Kategorien verschieben

Endlich mal ein richtiger Meilenstein. Schade, dass ich das nicht vermelden durfte. --\m/etalhead ✉ 19:52, 9. Mai 2014 (CEST)

Wenn ich das gewusst hätte, hätte ich dir gerne den Vortritt gelassen ;-). So lässt sich auf jedem Fall die Versionsgeschichte behalten. Aufgrund der inaktivität des Botbetreibers von Sebbot wird es wohl bei WP:KWS keine automatische Verschiebung geben, aber der Einsteller dort könnte die Kategorieseite vorher verschieben, dann legt Sebbot sie nicht automatisch an, stellt aber den SLA auf die Weiterleitung. Aber dauert ja noch/nur 2 Wochen bis es hier verfügbar ist. Der Umherirrende 20:01, 9. Mai 2014 (CEST)

+1, ich habe mich gerade riesig gefreut. IW 20:06, 9. Mai 2014 (CEST)

Ist denn schon klar, ob es dafür eine eigene Benutzergruppe geben wird? --\m/etalhead ✉ 13:15, 11. Mai 2014 (CEST)

Es gibt ein neues Benutzerrecht move-categorypages, standardmäßig wird jeder Benutzer (Gruppe user) das Recht haben. — Raymond ^Disk. 13:21, 11. Mai 2014 (CEST)

En.wp will wohl nur Admins das erlauben: Bug 65221. Der Umherirrende 16:47, 12. Mai 2014 (CEST)

Zwei Kommentare dazu: a) Man sollte das Verschiebungsrecht - zumindest vorerst - nur Sichtern geben. Ansonsten könnte es Chaos geben. b) Wäre es sinnvoll, bei gelöschten Kategorien mit der Zeit die Versionsgeschichte wieder herzustellen und hinterherzuverschieben? Zumindest, wenn die History sehr lange ist, wäre das erwägenswert. 85.212.38.87 00:02, 13. Mai 2014 (CEST)

Im Kategorienamensraum gibt es aktuell 254.935 gelöschte Versionen unter 47.640 verschiedenen Namen. Das spricht für kurze Versionsgeschichten. Eine Wiederherstellung und Verschiebung (vorher muss das Ziel gelöscht werden oder kann man auf bestehenden Namen ohne Löschung schieben?, Verschiebung ohne Weiterleitung wäre möglich) ist in meinen Augen hier nur ABM ohne Nennenswerten nutzen (Keine Schöpfungshöhe und damit kein Lizenzproblem). Zusätzlich ist darauf zu achten, das es nicht zu Überschneidungen in der Versionsgeschichte kommt. Es könnte auch sein, das per Import die Versionsgeschichte bereits übertragen wurde. Ein Überprüfung, wann eine Kategorie nur gelöscht wurde oder wann sie umbenannt wurde ist wohl auch aufwändig. Nicht alles wurde im Kategorie-Projekt besprochen, das man die dortigen Diskussionen als Grundlage nehmen könnte. Im Grundsatz ist die Idee in Ordnung, aber in so einem alten Projekt wie de.wp sollte man mit diesem Cut leben und sich für die Zukunft freuen. Der Umherirrende 21:40, 13. Mai 2014 (CEST)

Neues Hindernis bei der Zugänglichkeit von Commons-Dateien

In vielen (möglicherweise den meisten) WPs, glücklicherweise (noch?) nicht in en.wiki und de.wiki, gibt es ein neues Hindernis, in die Artikel eingebettete Bilder und Karten in voller Größe zu betrachten oder die Hintergrundinformationen zu lesen:

Wenn man auf die Abbildung klickt, wird je nach Browser entweder das ganze Fenster schwarz, oder es erscheint auf schwarzem Hintergrund die Abbildung in der Größe, wie sie sonst im Commons-File angezeigt wird, aber ohne die Dateiinformationen. Es besteht stattdessen die wenig gebrauchte Möglichkeit, sich zu den übrigen in dem spanischen oder katalanischen usw. Artikel verwendeten Abbildungen durchzuklicken, aber eben alle ohne Dateiinformationen oder die Möglichkeit, die maximale Auflösung abzurufen.--Ulamm (Diskussion) 22:13, 13. Mai 2014 (CEST)