Wikipedia Diskussion:Projektneuheiten/Archiv/2017

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:Projektneuheiten/Archiv/2017#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wiki.x.io/wiki/Wikipedia_Diskussion:Projektneuheiten/Archiv/2017#Thema_1

MediaWiki:Unresolved-property-category

Gibt es einen Namensvorschlag für die Kategorie? Der Umherirrende 19:08, 13. Jan. 2017 (CET)

Kategorie:Wikipedia:Seite ruft nicht vorhandene Wikidata-Eigenschaft auf? -- hgzh 20:01, 13. Jan. 2017 (CET)

Lieber kürzer

• Wikipedia:Seite mit ungültiger Wikidata-Property
• Den geistigen Transfer, dass eine Wikidata-Eigenschaft eine #property meint, muss man nicht auch noch abfordern, und ob ein Syntaxschreibfehler oder Zahlendreher oder was immer zur Fehlersituation führte, ist auch egal.

Könnte noch mehr Seite mit ungültiger Wikidata-Dingens geben.

Kategorie:Wikipedia:Syntaxfehler durch MediaWiki-Komponente erkannt

Schönes Wochenende --PerfektesChaos 11:54, 14. Jan. 2017 (CET)

erledigtErledigt Kategorie:Wikipedia:Seite mit ungültiger Wikidata-Property ist erstmal da. Der Umherirrende 22:24, 19. Jan. 2017 (CET)

Lint-Fehler

Da LintErrors demnächst sicher auch zu uns rüberschwappt, denke ich gerade über einige Übersetzungen nach:

• Bogus file options = Falschdateioptionen = Fehlerhafte Datei-Optionen (heute selber im translatewiki.net korrigiert)
• Fostered content = Gepflegter Inhalt
• Stripped tags = Enthüllte Tags

Hat jemand passendere Übersetzungen zur Hand? — Raymond ^Disk. 12:54, 9. Mär. 2017 (CET)

Mal doof gefragt: Was ist mit den letzten beiden gemeint? --nenntmichruhigip (Diskussion) 15:33, 9. Mär. 2017 (CET)

Fostered content bezieht sich auf https://dev.w3.org/html5/spec-LC/tree-construction.html#foster-parenting. Es geht dabei um falsch verschachtelten Tabelleninhalt, der durch ein anderes Element im DOM „adoptiert“ wird (Beispiel). Die englische Bezeichnung fostered content ist wohl dadurch inspiriert, dass foster parents die Bedeutung „Pflegeeltern“ hat. (Das kann noch lustig werden, weil wir zahlreiche Vorlagen haben, in denen das vorkommt, vor allem im Zusammenhang mit „versteckten“ sogenannten „Wartungslinks“ in Infoboxen.)

Stripped tags bezieht sich auf HTML-Tags, die von der Software entfernt wurden, zum Beispiel End-Tags ohne zugehöriges Start-Tag. --Entlinkt (Diskussion) 20:20, 9. Mär. 2017 (CET)

„Falsch verschachtelter Inhalt“ klingt doch schon gar nicht so schlecht :-) Für „stripped tags“ fällt mir jetzt aber auch gerade keine kompakte und verständliche Bezeichnung ein. --nenntmichruhigip (Diskussion) 20:37, 9. Mär. 2017 (CET)

Vielleicht „ignorierte Tags“? –Schnark 08:58, 10. Mär. 2017 (CET)

Icons fehlen?

Hallo Bjarlin, ich hatte vorhin deine umseitige Bearbeitung rückgängig gemacht, da ich sie nicht nachvollziehen kann und es auch auf WP:FzW keine derartigen Fehlermeldungen gibt. Und bevor die Meldung über den Ausrufer weit verteilt wird, bin ich lieber auf Nummer sicher gegangen, denn ich vermute, das ist ein Effekt an deiner Einstellung. Tritt das Problem auch nicht angemeldet bei dir auf? — Raymond ^Disk. 10:06, 24. Mär. 2017 (CET)

Da es Echo nur für angemeldete Benutzer gibt, wird das etwas schwierig mit dem Testen. Tatsache ist, dass sich irgendwas an den Icons geändert hat, soweit ich es nachvollziehen kann, wird unsichtbar (für Screenreader und Textbrowser) die Zahl mit einem erklärenden Text hinterlegt. Ich hatte jedenfalls auch Probleme damit, aber meine waren nachweislich selbst verursacht. –Schnark 11:14, 24. Mär. 2017 (CET)

Oh man, wie doof mein Testvorschlag war :-( Die Frage ist, welche Änderung konkret dein (und Bjarlins?) Problem verursacht hat und wie man das ggfs. umseitig formuliert. — Raymond ^Disk. 11:23, 24. Mär. 2017 (CET)

Die Änderung ist wohl https://phabricator.wikimedia.org/rECHOd4d325e7e68f1e20d7ad2b61f6f964acaf2c8d12, aber eigentlich sollten sich daraus keine sichtbaren Änderungen ergeben, bei mir war das ja nur daher der Fall, weil ich das CSS komplett umschreibe. --Schnark 11:35, 24. Mär. 2017 (CET)

Danke für die Info, ich schau da mal rein. --Bjarlin 12:04, 24. Mär. 2017 (CET)

Eben, unangemeldet gab es diese Icons dort auf die Seite Spezial:Benachrichtigungen noch nie. Das Icon links neben dem Benutzernamen wird ja weiterhin angezeigt, nur eben nicht die, die zuvor einen Link auf die Spezialseite hatten. Dort steht nun stattdessen „0 Meldungen“ bzw. „Mitteilungen (0)“ oder „Eine Meldung“ bzw. Mitteilung (1)“, und zwar mit sich je nach Skin überlappendem Text, der überlappt sich auch noch mit dem Text „Diskussion“, das ist alles kaum lesbar. Deshalb habe ich mal den Skin gewechselt. Mit Kölnisch Blau konnte man den Text dann zumindest vollständig lesen, da steht er untereinander statt nebeneinander. Mit Monobook ist es am schlechtesten, mit Kölnisch Blau am besten. Bei Modern wird als Text nur „0“ oder „Eine“ angezeigt ohne das Wort „Meldungen“ und daneben „Mitteilungen“ ohne Zahl, auch seltsam, aber lesbar. Da überlappen sich dann nur etwas höhenmäßig versetzt die Wörter „Mitteilungen“ und „Diskussion“, sind aber lesbar. Bei Vector überlappt sich auch alles wie bei Monobook und ist kaum lesbar, aber das Wort „Diskussion“ ist etwas versetzt ein wenig tiefer, deshalb leicht besser als bei Monobook. Die Wörter sind normalerweise etwas heller und bei einer vorhandenen Nachricht werden sie einzeln dunkler und dadurch etwas besser lesbar.

Das ist alles ohne Skript (JS), aber mit Bildern (Icons wären also zu sehen, wenn sie da wären, so wie vorgestern auch noch). Habe nichts an den Einstellungen geändert, vorgestern wurden noch die Icons angezeigt, aber kein Text, nun umgekehrt. Ich habe mich schon gewundert, dass noch niemand gemeckert hat, aber es konnte ja sein, dass es nur noch nicht genauer aufgefallen war.

Mit Monobook sieht das Überlappen nun so aus: Bei mir steht jetzt lesbar oben neben dem Benutzernamen nur „0 Meld“, das „ungen“ überschneidet sich mit dem Wort „Mitteilungen“ und das wiederum in der 2. Hälfte mit dem etwas dickeren Wort „Diskussion“, auf das auch der Link zeigt. Damit ist das Wort „Mitteilungen“ gar nicht lesbar und habe ich nur über andere Skins erschließen können.

Bei Monobook gibt es auch keinen Link auf die Benachrichtigungsseite, der war aber vorher schon nicht vorhanden; man muss sich dann anders behelfen, mit anderen Skins sind Links da. Benutzerfreundlich ist das so nicht, barrierefrei wäre was anderes. Das ist aber definitiv kein Screenreader oder Textbrowser, dann hätte ich auch kein Icon vor dem Benutzernamen. --Bjarlin 12:04, 24. Mär. 2017 (CET)

Hast du irgendwo in den Browsereinstellungen festgelegt, dass Links immer in den vom Browser vorgegebenen Farben dargestellt werden sollen? Oder, anders gefragt: Sind bei dir Links auf fehlende Seiten rot? –Schnark 12:17, 24. Mär. 2017 (CET)

Siehe phab:T161302, egal, woran es bei dir liegt, so bleiben kann es jedenfalls nicht. –Schnark 12:25, 24. Mär. 2017 (CET)

Fehlende Seiten sind rot, ja. Ehrlich gesagt verstehe ich deinen ersten obigen phab-Link (der ohne T+Nr., warum hat der keine normale Nr.?) nicht. Warum wurde „Use words for describing notification counts in HTML text node“ überhaupt angelegt? Was soll denn die Verbesserung dabei sein, wenn man neuerdings Wörter erhält? Warum hat man nicht die Icons belassen? Wo ist da der Sinn? Denn anscheinend ersetzt ja der Text die Icons irgendwie. --Bjarlin 12:39, 24. Mär. 2017 (CET)

Bei Vector überlappt sich der Text „Mitteilungen (0)“ bis „Diskussi“, der Text „Mitteilung (1)“ nur bis „Diskus“, beides aber versetzt, also oben beim Wort, insbesondere über den i-Punkten, beim k-Strich oben und oben beim D. Bei Monobook ist der Text aber auf gleicher Höhe und überlappt deshalb die Buchstaben jeweils vollständig. Die Überlappung ist also etwa gleich breit in beiden Skins, bei Vector ist es nur in der Höhe versetzt. Bei Modern ist es auch nach oben versetzt und überlappt weniger, und da fehlt hinten auch die eingeklammerte Zahl, also kürzer.

Wie das aussieht, wenn man eine Nachricht auf der eigenen Diskussionsseite hat, ist noch unklar. Die Farbe (rot bzw. blau bei der Zahl, wenn neue Nachricht vorhanden) ist bei Monobook + Vector aber noch vorhanden.

Es wäre auch schön, wenn man bei Monobook einen Link auf die Spezialseite dorthin setzen könnte, wenn das wieder besser funktioniert. Dass es den hier gar nicht gibt, verhindert, dass man beim Klick auf „Diskussion“ bei den Benachrichtigungen landet. Bei Vector lande ich beim Klick auf den 2. i-Punkt oder oben auf das k aber auf der Benachrichtigungsseite, nicht nur beim D. Wenn man den oberen Strich von einem der 3 s erwischt (bei keiner vorhandenen Mitteilung), ebenfalls, bei vorliegender Mitteilung bis zum 2. der 3 s. --Bjarlin 13:11, 24. Mär. 2017 (CET)

Anders gefragt: Wenn du mir einen Code für die css-Datei nennen kannst, mit der der Text wieder ausgeblendet werden kann, werden dann die Icons stattdessen wieder angezeigt? --Bjarlin 13:15, 24. Mär. 2017 (CET)

@Schnark: Ich habe mir das mal bei Commons angesehen. Dort habe ich Englisch eingestellt und die Texte lauten dort statt „0 Meldungen“ bzw. „Mitteilungen (0)“ auf Englisch „Alerts (0)“ bzw. „Notices (0)“, also beim Ersten mit Zahl in der Klammer statt davor ohne Klammer, was sich auch auf den Modern-Skin auswirkt, wo nicht nur „0“, sondern „Alerts“ ohne Zahl steht und „Notices“ auch ohne Zahl. Warum wird eigentlich „Alerts (0)“ mit „0 Meldungen“ statt mit „Meldungen (0)“ übersetzt?
Die Überlappung von „Alerts (0)“ und „Notices (0)“ ist minimal („(0)“ überlappt bei Monobook + Vector den Anfang „No“), aber der Text „Notices (0)“ überlappt dort den gesamten Text des kurzen Wortes "t/Talk" sowohl bei Monobook („talk“) als auch bei Vector („Talk”). Da bei mir bei Monobook immer der Speziallink ganz fehlt, ist der Link zur Disk. problemlos möglich, bei Vector aber wird im oberen Teil des Wortes überall auf die Spezialseite verlinkt. Ich gehe deshalb und wegen deiner Beschreibung davon aus, dass du dort in Englisch mit Monobook gar keine Chance hast, mit dem Link auf deine Disk. zu klicken, weil dort an allen Seiten (links, rechts, oben und unten) überall der Text der Spezialseite dahintersteht. Das sollte man auch darstellen, denn mit dt. Lokalisierung erhält man zumindest noch beim Link auf das Ende des Wortes „Diskussion“ den normalen Link, in Englisch geht das gar nicht. Also noch verdeckter als im Deutschen. --Bjarlin 14:21, 24. Mär. 2017 (CET)

RC filters

Wann werden die voraussichtlich live gehen? --\m/etalhead ✉ 18:25, 23. Mär. 2017 (CET)

@Metalhead64: wikitech:Deployments schweigt sich für die hiesige Wikipedia noch aus. Nur plwiki und ptwiki sind für den 28. März 2017 vorgeplant. Auf dem Testwiki kann es schon getestet werden. — Raymond ^Disk. 21:40, 23. Mär. 2017 (CET)

@Metalhead64: Siehe Phab:T146972 für die Reihenholge. — Raymond ^Disk. 20:23, 27. Mär. 2017 (CEST)

Und @all: ein Video über die Funktionsweise. — Raymond ^Disk. 20:23, 27. Mär. 2017 (CEST)

Mehrspaltige Einzelnachweislisten

Aus Gerrit:229852:

„Implement responsive columns for reference lists This is based on the popular 'count' parameter from Template:Reflist on English Wikipedia, which has also been adopted by many other wikis. That template's 'count' parameter allows maximum flexibility on a per- page basis. This was important because the template can't know how many references the list will contain. Users typically manually add (and later, increment) the 'count' parameter when the list exceeds a certain threshold. The template currently sets an exact column count (via the CSS3 property `column-count`). This patch improves on that by instead using the closely related CSS3 `column-width` property. This automatically derives the column count based on the available space in the browser window. It will thus create two or three columns on a typical desktop screen, and two or no columns on a mobile device. The specified width is the minimum width of a column. This ensures that the list is not split when rendered on a narrow screen or mobile device. It also hooks into the raw list before parsing and adds the class only when the list will contain more than a certain number of items. This prevents very short lists from being split into multiple columns.Templates like Template:Reflist on English Wikipedia currently are not able to set inline styles on the list element directly, which is why they set it on a `<div>` wrapping the `<references />` output. Because of this, the feature of the Cite extension must not be enabled at the same time, as that would result in both the template's wrapper and the references list being split. The end result would involve sitations with three columns split in four sub-columns, creating a complicated mess of nine intermixed columns. To provide a smooth migration for wikis, this feature can be disabled by default using `$wgCiteResponsiveReferences = false`. Each individual template createing reference list can then be migrated, by removing the wrapper column styles and instead settting the new "responsive" attribute, like so: `<references responsive />`. Once any conflicting templates have been migrated, the default for the wiki can be swapped by setting `$wgCiteResponsiveReferences = true`. If wikis wish for some templates to keep their custom column splitting behaviour, templates can also opt-out by setting `responsive="0"`, which will make sure that it will keep behaving the current way even after the feature becomes enabled by default for the wiki. In summary, when disabled by default, pages can opt into this system with `<references responsive />`. When enabled by default, pages can opt out of the system with `<references responsive=0 />`. * Deprecate cite_references_prefix/cite_references_suffix. This message is rarely used and opens up compatibility hazards. It was already removed by Parsoid, but the PHP implementation still had it. It's typically used to add inline styles to the wrapper which is more appropiately done in Common.css (or obsoleted as part of the skin or Cite extenion itself nowadays depending on what style in question). It was also a HTML-style message with separated open and close segments, which is an anti-pattern in itself.<br> * Declare module target explicitly and include mobile. The absence of this stylesheet caused subtle BiDi/RTL bugs on mobile.“

Gibt es dazu bei uns Handlungsbedarf? Also Anpassung von Vorlagen? — Raymond ^Disk. 11:25, 8. Mär. 2017 (CET)

Interessant. Ich kenne keine Vorlagen, die ein References-Tag automatisch einbinden, also sehe ich in dieser Hinsicht eher keinen Handlungsbedarf. Allerdings wurden in einigen Artikeln die Einzelnachweise „per Hand“ vermehrspaltet, also per umschließendem div-Container entweder per column-count oder column-width. Diese müssten entsprechend entfernt werden. Und habe ich richtig verstanden, dass die Mehrspaltigkeit dann Standard werden soll, ohne dass man das responsive-Attribut angeben muss? -- hgzh 11:46, 8. Mär. 2017 (CET)

Stimmt, die "per Hand"-Mehrspaltigkeit hatte ich vergessen. Ich sehe daher folgende Schritte:

1. <references responsive /> kann ab nächster Woche Donnerstag von jedermann verwendet werden
2. "per Hand"-Mehrspaltigkeit sollte per Quarry gesucht und per Bot entfernt werden. Für einen Übergangszeitraum sind die Artikel dann eben mit einspaltigen Einzelnachweislisten versehen. Es geht aber nichts kaputt
3. Wenn 2. erledigt ist, kann für unser Wiki der Default auf die neue Technik gesetzt werden
4. Wer Zeit und Lust hat, kann überflüssige <references responsive /> dann wieder auf <references/> reduziere. Tut aber auch nicht weh, wenn das eine Weile drin bleibt. — Raymond ^Disk. 12:21, 8. Mär. 2017 (CET)

Ich würde aber – als jemand, der selbst gerne mal Mehrspaltigkeit setzt – darum bitten, Schritt 2 davon abhängig zu machen, dass wirklich feststeht, dass der Default auch tatsächlich auf die Mehrspaltigkeit gesetzt wird. Andernfalls erschiene vorzugswürdig, in Schritt 2 auf <references responsive /> zu ersetzen. Gruß, — Pajz (Kontakt) 13:18, 8. Mär. 2017 (CET)

Hast Recht mit deinem Vorschlag der Vorzugswürdigkeit. — Raymond ^Disk. 14:07, 8. Mär. 2017 (CET)

Kann also jeder "Autor" nach eigenem Gusto im Artikel entscheiden ob die Anzeige wie bisher einspaltig oder neu mehrspaltig ist?--Avron (Diskussion) 17:48, 8. Mär. 2017 (CET)

Zunächst kann jeder mit responsive="1" die Mehrspaltigkeit einschalten, wenn diese dann Standard ist, kann jeder diese mit responsive="0" ausschalten. Im Prinzip hat also der Autor das letzte Wort, das finde ich auch nicht schlimm. Im Übrigen +1 zu Raymond und Pajz. -- hgzh 22:09, 8. Mär. 2017 (CET)

Arm dran und Bein ab, das ist schlimm. Ich finde es einfach Quatsch so etwas pro Artikel zu machen.--Avron (Diskussion) 13:05, 9. Mär. 2017 (CET)

insource:/column\-count[^(div)]+references.+\<\/div\>/, insource:/column\-width[^(div)]+references.+\<\/div\>/ und insource:/Spaltenbreite[^(div)]+references.+\<\/div\>/ sollten die gängigen Fälle abdecken. -- hgzh 15:35, 13. Mär. 2017 (CET)

Ich habe jetzt auch RegExp fertig, die ~90% der Fälle recht sicher abarbeiten können. Der Rest muss dann eben noch per Hand gefixt werden. -- hgzh 12:59, 14. Mär. 2017 (CET)

Hallo! Vielleicht ist das hier von Interesse: Seit Kurzem gibt es zu dieser neuen Funktion eine Infoseite auf MediaWiki:Editing/Projects/Columns for references. Dort ist z. B. beschrieben, dass es einen vorformulierten Phabricator-Task gibt, mit dem die Aktivierung der Funktion in die Wege geleitet werden kann. Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 12:19, 16. Mär. 2017 (CET)

Danke für den Hinweis. Dort steht ja, dass wir für die Aktivierung wieder eine Diskussion verlinken sollen. Frage @all: reicht da eurer Meinung nach eine FZW-Kurzumfrage oder müssen wir das größer aufziehen? -- hgzh 12:52, 16. Mär. 2017 (CET)

erste Testedits. -- hgzh 20:52, 16. Mär. 2017 (CET)

Ausführlich: HD:EN #references responsive, dort maßgeblich. VG --PerfektesChaos 10:30, 2. Apr. 2017 (CEST)

Parser-Migrations-Werkzeug

Zufällig in den Einstellungen entdeckt: Inzwischen gibt es eine Möglichkeit die Auswirkungen zu testen, die sich durch die Migration weg von Tidy ergeben. –Schnark 11:39, 8. Apr. 2017 (CEST)

Ach da gibt es die Funktion.... Ich hatte nur die Aktivierung auf dem Server gesehen, aber irgendwie keine Zeit gehabt, das zu verfolgen. — Raymond ^Disk. 12:00, 8. Apr. 2017 (CEST)

Linter-Wartungskategorie

Noch ist die Linter-Spezialseite bei uns nicht angekommen (medium-Size-Wikis diese Woche); diese Woche wurde auch eine Wartungskategorie eingeführt. Hat jemand einen Vorschlag für die Wartungskategorie, einstellbar via MediaWiki:Linter-category-deletable-table-tag? — Raymond ^Disk. 12:22, 8. Apr. 2017 (CEST)

„Seite mit fehlerhaft verschachtelter Tabelle“? Das <table>-Tag zu löschen ist ja nur eine (wenn auch die durch Tidy automatisch vorgenommene) Methode, den Fehler zu beheben. Zur Dokumentation siehe mw:Help:Extension:Linter/deletable-table-tag. –Schnark 09:10, 10. Apr. 2017 (CEST)

• Kategorie:Wikipedia:Seite mit Tabellenfehler in Kategorie:Wikipedia:Syntaxfehler durch MediaWiki-Komponente erkannt.
• Ob jetzt im Moment Verschachtelung oder eines Tages weitere Fehler, ist egal; das Wartungspersonal, das zur Reparatur ausschwärmen müsste, ist identisch.

LG --PerfektesChaos 10:15, 10. Apr. 2017 (CEST)

Noch eine (Gerrit:347495): MediaWiki:linter-category-misnested-tag = Misnested tags. Vorschläge? — Raymond ^Disk. 10:05, 11. Apr. 2017 (CEST)

Da sollte eine ziemlich wörtliche Übersetzung eigentlich kein Problem sein: Seite mit falsch verschachtelten Tags. –Schnark 10:12, 11. Apr. 2017 (CEST)

• Unsere Normal-Autoren tun sich mit solchen Tagen immer etwas schwer.
• Wir haben schon Kategorie:Wikipedia:Seite mit problematischem HTML-Tag.
• Hier sind aber vermutlich nicht nur HTML-Tags involviert, so dass diese nähere Erläuterung unpassend wäre.
• Kategorie:Wikipedia:Seite mit falsch verschachtelten Elementen ist noch fachlich richtig, aber hoffentlich verständlicher, wenn am Fuß der Seite vorgefunden. Notfalls „Syntax-Elementen“.

LG --PerfektesChaos 13:14, 11. Apr. 2017 (CEST)

Benutzerskripte aktualisieren

Wo erhält man Hilfe beim Überarbeiten des Codes seiner .js-/.css-Benutzerseiten? --\m/etalhead ✉ 16:41, 28. Apr. 2017 (CEST)

WP:TWS. LG --PerfektesChaos 17:07, 28. Apr. 2017 (CEST)

DynamicSidebar

Guten Morgen. Mit dieser Änderung wurde de facto mw:Extension:DynamicSidebar für alle Wikis zugelassen. Ich finde die Extension ziemlich charmant. Sie ermöglicht Benutzer-, Benutzergruppen- und Kategoriespezifische Sidebars. Sie könnte ggfs. auch einige CSS/JS-Hacks ablösen. Wie ist eure Meinung? Lohnt sich der Aufwand für eine Umfrage, um den Devs zu zeigen, dass wir das aktiviert haben wollen? — Raymond ^Disk. 09:21, 10. Mai 2017 (CEST)

In der gegenwärtigen Form sollte die Erweiterung natürlich nirgendwo aktiviert werden, wo nicht nur vertrauenswürdige Benutzer arbeiten. Da die Sidebar-Benutzerunterseiten nicht geschützt sind, könnte man ansonsten jedem mehr oder weniger beliebige Links in die Seitenleiste vandalieren. Ich sehe durchaus einen gewissen Nutzen, aber nur bei einer eher kleinen Gruppe von Benutzern, die einerseits so fortgeschritten sind, dass sie tatsächlich Bedarf für zusätzliche Links haben, andererseits aber nur statische Links in einer vernünftigen Zahl (weder so klein, dass ein eigener Abschnitt dafür sich nicht lohnen würde, noch so groß, dass die Leiste völlig überladen würde) haben wollen. –Schnark 09:51, 10. Mai 2017 (CEST)

• +1
• Ich würde mw.util.addPortletLink() nicht als „JS-Hack“ diffamieren, sondern als reguläre Seitenprogrammierung ansehen.
• Im Unterschied zu dieser Extension, deren Dokumentation mir recht wenig praktische Beispiele und Zwecke liefert, auch hinsichtlich der zu verwendenden Syntax, kann addPortletLink einiges mehr und more „Dynamic“.
  • Offenbar gibt es das dann statisch auf allen Seiten, in allen Namensräumen?
  • JS kann dynamisch den Kontext untersuchen, und spezifische Links einfügen auf eigenen Benutzerseiten, auf allen Diskussionsseiten, nur wenn Benutzer IP ist, im eigenen WikiProjekt oder Wettbewerb, wenn Artikel zur Kategorie X gehört.
  • JS funktioniert übrigens auch bei nicht angemeldeten Benutzern.
• Wenn es jemand mit JS nicht selbst gebacken bekäme, reicht schon eine Anfrage auf FZW, erst recht TWS, um den Code mit heutigen Mitteln aufgeschrieben zu bekommen.
  • Für die Extension-Syntax, so sie überhaupt flexibel und mächtig wäre, würden wohl die gleichen Rückfragen kommen.
• Die Anzahl der Leutchen, die das brauchen und pflegen möchten, schätze ich ebenfalls als relativ klein ein.
  • Sie können es heute schon realisieren.
  • Und sie können das flexibler.
  • Übrigens nicht nur in der Sidebar, auch oben.
  • Und auf geschützten Benutzerseiten.

LG --PerfektesChaos 10:41, 10. Mai 2017 (CEST)

Danke für euer Feedback. Die verfl.... Vandalen hatte ich mal wieder nicht bedacht. Nun gut, mag mw.util.addPortletLink() als reguläre Seitenprogrammierung angesehen werden, ich bin trotzdem mehr ein Freund von Extensions, wo weitere Links vom PHP-Code direkt reingerendert werden und nicht erst Sekundenbruchteile später die per JS erzeugten Links erscheinen. Schade, ich werde die Idee der Aktivierung der Extension nicht weiter verfolgen, obwohl sie für mich persönlich ganz nützlich gewesen wäre. — Raymond ^Disk. 21:03, 10. Mai 2017 (CEST)

Autoblock-Cookie

Eine Verständnisfrage zur neuesten Softwareänderung: Fast alle modernen Browser bieten die Möglichkeit, Cookies zu blocken. Ist das nicht eine Lücke im System, die es ermöglicht, dieses Autoblock-Feature zu umgehen? -- Chaddy · D – DÜP – 22:42, 8. Mai 2017 (CEST)

Natürlich lässt es sich damit umgehen, aber die Funktion ist unerfahrenen Nutzern (Schülern z.B.) eher nicht bekannt. --FNDE 22:44, 8. Mai 2017 (CEST)

Wer es wirklich will, wird hier immer scheiße bauen können. --MGChecker – (📞| 📝| ) 17:43, 9. Mai 2017 (CEST)

Danke für eure Antworten! Dann ist dieses Feature aber leider nur eine kleine Ergänzung, zu mehr taugt es nicht. -- Chaddy · D – DÜP – 10:24, 11. Mai 2017 (CEST)

Spezial:LintErrors

Bitte in Mediawiki:linter-category-obsolete-tag-desc eine deutlich abschreckende Warnung einbauen, dass es sich nicht um einen „Fehler“ handelt, an dem man jetzt unbedingt sofort rummachen müsste.

• Die Browser werden diese Syntax noch auf Jahrzehnte verstehen, und wo welcher Ersatz sinnvoll ist, bedarf der Sachkunde und des Finferspitzengefühls und hat keine Dringlichkeit.
• Übereifrige semantische Murksereien können wir hingegen nicht brauchen; etwa dass jemand die längere Beschriftung einer Kirchenglocke zur angeblichen Tastatureingabe umdeklariert, nur um eine angeblich veraltete Darstellung in Schreibmaschinenschrift HTML5-konform zu „reparieren“.

Im Übrigen nett zu sehen, dass ANR und aktuelle Projektseiten zienmlich sauber sind, und weitaus überwiegend BNR und Archive die kleinen Problemchen haben.

LG --PerfektesChaos 02:01, 14. Apr. 2017 (CEST)

Hast du einen konkreten Wortlaut? Es ist ja in der Kategorie "Warnung" enthalten. Müsste nicht jede Kategorie einen solchen Hinweis enthalten? Es läuft ja dem Prinzip "kosmetische Änderung" etwas entgegen, wenn man hier die Korrekturen macht. In den wenigsten Fällen hat es aktuell auswirkungen. Durch die Ablösung von HTML Tidy kann es allerdings irgendwann auswirkungen haben (Könnte man sich mit dem ParserMigration anschauen, siehe Abschnitt hier). Der Umherirrende 21:29, 14. Apr. 2017 (CEST)

Wurde soeben wegen Performance-Problemen deaktiviert - Task 148609. Der Umherirrende 22:59, 14. Apr. 2017 (CEST)

Was genau heißt eigentlich "Lint"? Der Eintrag auf der Vorderseite ist recht dürftig. 79.229.67.23 21:50, 14. Apr. 2017 (CEST)

Bei den Entwicklern gibt für alles "linter": jslint, csslint, phplint, lesslint, jsonlint. Mehr infos unter Lint (Programmierwerkzeug). Der Umherirrende 22:03, 14. Apr. 2017 (CEST)

Auf den kleinen Wikis wie Wikivoyage/de ist die Spezialseite noch aktiv. Man bekommt dann schon mal einen Eindruck, wie viel Arbeit auf uns wartet. Gemeinheiten sind z.B. Inline-Tags wie span, die keine Umbrüche enthalten dürfen oder Bilder, bei denen "mini" und Breitenangaben in der richtigen Reihenfolge stehen müssen. Besonders ärgerlich ist, dass es keine Testwerkzeuge wie Kommentare im Quelltext gibt. --RolandUnger (Diskussion) 19:30, 5. Mai 2017 (CEST)

Die Reihenfolge von Dateioptionen ist beliebig. Der Unterschied ist, das nichts mehr doppelt sein darf. Das Modul hinter "Quickbar Ort" verdoppelt eventuell enthaltende thumb-Parameter, wenn außerdem ein px-Breitenangabe gesetzt ist. Dies führt zum Lint-Fehler. Mit dieser Änderung sollte diese Art der Fehler verschwinden. Der Umherirrende 02:06, 6. Mai 2017 (CEST)

Wann wird die Spezialseite auf de:wp wieder aktiviert? 92.75.202.24 22:17, 20. Mai 2017 (CEST)

prefer JS print over printable version.

Moin zusammen, hat Gerrit:350197 eine sichtbare Auswirkung auf die Wikipedia? In meinem lokalen Testwiki konnte ich keine Veränderung feststellen. Bzw. was übersehe ich? — Raymond ^Disk. 11:19, 22. Mai 2017 (CEST)

Wenn du mit dem Patch in seiner gegenwärtigen Form auf „Druckversion“ klickst, sollte sich der Druckdialog des Browsers öffnen, statt wie bisher (oder mit dem Patch bei einem Klick, der die Druckversion in einem neuen Tab öffnet) eine Version, die zeigt, wie die Seite vielleicht aussehen könnte, wenn man sie ausdruckt. –Schnark 12:11, 22. Mai 2017 (CEST)

Kategorie „Bald“

Brauchen wir den Abschnitt wirklich? Man kann die Neuerungen auch dann vermelden, wenn sie wirklich kommen. Und warum wird immer hinter dem Wort ein Trademark-Symbol gesetzt? --\m/etalhead ✉ 18:34, 19. Mai 2017 (CEST)

Hallo? --\m/etalhead ✉ 14:56, 20. Mai 2017 (CEST)

Also, ich finde ihn sinnvoll, um die unmittelbar und konkret in den nächsten Wochen bevorstehenden Angelegenheiten von denjenigen abzugrenzen, die perspektivisch vielleicht nächstes oder übernächstes Jahr mal akut werden könnten, auf die man sich aber programmierungstaktisch schon mal langsam einstellen könnte.

Und das ^TM ist eine ironische Umspielung des Wortes „Bald“, was zwischen nächstem Monat und nächstem Jahrhundert liegen mag.

VG --PerfektesChaos 15:11, 20. Mai 2017 (CEST)

Ich habe die Rubrik „Bald“ eingeführt, um auf Neuheiten hinzuweisen, die ziemlich sicher in relativer Bälde kommen werden. Um sich schonmal darauf zu freuen oder vorzubereiten. Die umseitigen Einträge habe ich bewusst recht eng ausgewählt in Hinblick auf eine Einführung hier in den Projekten. Neue Features in MediaWiki, die z.B. aus Performancegründen nie ihren Weg hierhin finden, habe ich nicht aufgenommen. Ich vermute und hoffe, dass auch weitere Leser der Projektneuheiten gerne über Dinge lesen, die in der Pipeline sich befinden. Und zum ^TM hat PerfektesChaos schon alles gesagt :-) — Raymond ^Disk. 22:16, 20. Mai 2017 (CEST)

Finde den Abschnitt sinnvoll; gerne beibehalten :-) Gruß --Schniggendiller Diskussion 13:57, 22. Mai 2017 (CEST)

Ich danke euch für die Antworten. Dann lassen wir den Abschnitt eben drin. --\m/etalhead ✉ 21:15, 25. Mai 2017 (CEST)

Notification-Blacklist

Da ich in diesem Task wirklich nicht durchblicke:

• Was genau blockiert diese Blacklist und was lässt sie durch?
• Ist sie privat oder auf einer Seite im BNR?
• Funktioniert sie nur zum Ausschließen einzelner Nutzer oder wurde auch der Wunsch mit den Gruppen umgesetzt?

Aufklärung zu diesen Punkten würde mich sehr freuen. --MGChecker – (📞| 📝| ) 23:47, 31. Mai 2017 (CEST)

@MGChecker: Auf die Schnelle, bevor ich weg muss: Sie ist privat. In den Benutzereinstellungen wird man eine Liste der Benutzernamen eingeben können: "List of usernames that are blacklisted from triggering most Echo notifications (edits to your user talk page will still trigger notifications). — Raymond ^Disk. 07:16, 1. Jun. 2017 (CEST)

Sehr gut, damit wäre meine größte Befürchtung, dass das mal wieder wie so vieles in den Wikitext ausgelagert wird, unbegründet. --MGChecker – (📞| 📝| ) 12:03, 1. Jun. 2017 (CEST)

Wobei ich mich Frage, wie mit Renames und UserMerges umgegangen wird. Man wird ja nicht die Einstellungen durchsuchen. Oder speichert man gar die User-IDs? Würde Platz sparen. Aber beides wird auf MediaWiki:Echo-blacklist ja auch nicht betrachtet. Der Umherirrende 20:52, 2. Jun. 2017 (CEST)

Support von ehrenamtlichen Entwicklern/Umfrage Technische Wünsche

Vielleicht kommt das für jemanden hier in Frage? Auf der Technischen Wunschliste gibt es in diesem Jahr zum ersten Mal einen reservierten Platz für die Unterstützung eines ehrenamtlichen Entwicklers. Leute, die bei ihrem eigenen Projekt gerne Unterstützung hätten, können in dieser Rubrik einreichen: Wikipedia:Umfragen/Technische_Wünsche_2017/Projekte_ehrenamtlicher_Entwickler. Eingereicht werden können nur Projekte, an denen man selbst arbeiten will. Das Projekt mit den meisten Stimmen würde dann Support in Form von Beratung in technischen, konzeptionellen und organisatorischen Fragen sowie Code Review bekommen. Gesamtumfang der Unterstützung wären ca. 30-40 Stunden, um es planbar zu machen. Wir freuen uns auf Einreichungen & auf die Zusammenarbeit mit X :-) - Bei Fragen gerne pingen. Viele Grüße, --Birgit Müller (WMDE) (Diskussion) 16:55, 2. Jun. 2017 (CEST)

MediaWiki 1.30.0-wmf.3

Ist gestern wieder mal nicht live gegangen. --\m/etalhead ✉ 19:54, 2. Jun. 2017 (CEST)

Aufgrund der Verspätung von wmf.2 wird wmf.3 ausgesetzt, siehe phab:T165957. Der Umherirrende 20:48, 2. Jun. 2017 (CEST)

Lesetipp: Pläne zum Druck-Stylesheet

Via Ambassodors-Mailingliste Update to web print styles: mw:Reading/Web/Projects/Print Styles. — Raymond ^Disk. 22:52, 5. Aug. 2017 (CEST)

(Ent-)Beobachtungslinks auf der Beobachtungsliste

Funktioniert bei mir (Firefox 55.0.1) im TWN nicht. JavaScript ist aktiviert. --\m/etalhead ✉ 21:32, 16. Aug. 2017 (CEST)

Die Funktion kommt erst mit dem neuen Update, das für morgen geplant ist. Kann also noch gar nicht funktionieren. ;) -- Chaddy · D – DÜP – 23:16, 16. Aug. 2017 (CEST)

@Chaddy: Im Translatewiki ist diese Neuerung wie gesagt schon aktiv. --\m/etalhead ✉ 09:43, 17. Aug. 2017 (CEST)

@Metalhead64: Ist bei die auf TWN die Benutzereinstellung "Änderungen auf „Letzte Änderungen“ und der Beobachtungsliste nach Seite gruppieren" aktiv? Dann klappt die neue Funktion bei mir auch nicht. Leider. — Raymond ^Disk. 21:29, 17. Aug. 2017 (CEST).

@Raymond: Genau das war der Grund. Hat schon jemand diesen Bug gemeldet? --\m/etalhead ✉ 21:46, 17. Aug. 2017 (CEST)

Besteht Euer Problem noch? Zumindest hier in de-WP funktioniert es bei mir. --Stepro (Diskussion) 14:28, 18. Aug. 2017 (CEST)

@Stepro: Nur, wenn die erweiterte Beo verwendet wird. --\m/etalhead ✉ 14:49, 18. Aug. 2017 (CEST)

Diff

Wurde Schnarks Diff durch die neue Diffansicht „Verbessert“ abgelöst? Basiert diese ggf. sogar darauf? --Leyo 10:52, 17. Aug. 2017 (CEST)

@Schnark: Du müsstest diese Frage ja beantworten können. --Leyo 13:31, 19. Aug. 2017 (CEST)

Einladung zum wöchentlichem Technical Advice IRC Meeting

Hey,

ich poste auch hier unsere Einladung zum neuen Technical Advice IRC Meeting. Die Einladung ist zwar auf englisch, weil es ein internationales Angebot ist, wir sprechen aber auch Deutsch, wenn das jemandem lieber ist.

On Wednesday, August 23rd, 2017 at 3 pm UTC, we start with our weekly Technical Advice IRC Meeting on #wikimedia-tech IRC channel.

The Technical Advice IRC meeting is open for all volunteer developers, topics and questions. This can be anything from "how to get started" over "who would be the best contact for X" to specific questions on your project.

If you know already what you would like to discuss or ask, please add your topic to the next meeting.

This meeting is an offer by WMDE’s tech team. Hosts of the meeting are: @addshore, @CFisch_WMDE.

Hope to see you there! -- Michael Schönitzer (WMDE) (Diskussion) 00:20, 19. Aug. 2017 (CEST)

Syntaxhervorbung für Wikisyntax

Ich habe grade die neue Syntaxhervorhebung für Wikisyntax aktiviert. Dafür, dass es seit über zehn Jahren vertrautes Verhalten ändert, gefällt es mir erstaunlich gut. Ein kleiner Bug aber: bisher konnte ich während des Editierens den Zurück-Button im Browser drücken, den Artikel nochmal angucken und dann den Vor-Button benutzen und weiter editieren. Das ist mit dem neuen Feature nicht mehr möglich. Die Syntaxhervorhebung nimmt nicht den von mir editierten Inhalt des Editierfensters, sondern den Inhalt, den das Fenster beim Laden der Seite hatte. Das ist bestimmt so nicht gewollt.

Hier ist sicher nicht die richtige Stelle für Bug Reports, aber vielleicht kann ja jemand kundigeres daraus einen offiziellen Bug-Report machen. --::Slomox:: >< 12:40, 23. Aug. 2017 (CEST)

Und was ebenfalls nicht mehr funktioniert: wenn man mit den Editiertools unterhalb des Editierfensters Sonderzeichen wie zum Beispiel die korrekten Anführungszeichen „“ eingefügt hat, dann sprang der Cursor bisher an die Stelle zwischen den beiden Zeichen. Mit Syntaxhervorhebung springt er ans Ende. --::Slomox:: >< 12:53, 23. Aug. 2017 (CEST)

Hallo ::Slomox::, deine Bugreports kannst du am besten entweder auf Phabrikator stellen, oder noch einfacher auf der Diskussionsseite des Betafeatures. Auserdem gibt es mittlerweile eine Seite zur neuen Syntaxhervorbung, wo Probleme und Tipps gesammelt werden! -- Michael Schönitzer (WMDE) (Diskussion) 15:37, 24. Aug. 2017 (CEST)

Ich habe in phab:T175509 das Problem mit dem Zurück-Button beschrieben. --Fomafix (Diskussion) 07:34, 11. Sep. 2017 (CEST)

phab:T175509 wurde geschlossen. Die Änderung wird mit Version 1.31.0-wmf.8 kommen. --Fomafix (Diskussion) 13:09, 8. Nov. 2017 (CET)

Verbesserter Versionsvergleich

Ein verbesserter Versionsvergleich steht nun auf http://test.wiki.x.io und http://mediawiki.org zur Verfügung: Textänderungen in verschobenen Absätzen werden nun kenntlich gemacht. Fehler können auf Phabricator oder auf der Diskussionsseite des Wunsches gemeldet werden. Zudem wurde dabei ein alter Fehler korrigiert: Unter gewissen Umständen, zum Beispiel wenn ein Abschnitt entfernt und ein anderer eingebaut wird, oder ein Abschnitt verschoben wird, passiert es, dass zwei Abschnitte, die nichts miteinander zu tun haben, als ein stark veränderter Abschnitt dargestellt werden. Dieser wurde Ende Oktober/Anfang November korrigiert und ist auch hierzuwiki bereits deployed. -- Michael Schönitzer (WMDE) (Diskussion) 16:59, 8. Nov. 2017 (CET)

Benutzergruppe „MP3-Hochlader“

Ich würde dann noch vorschlagen, die Benutzergruppen „JPEG-Hochlader“, „FLAC-Hochlader“, „SVG-Hochlader“, „OGG-Hochlader“ usw. einzuführen. --\m/etalhead ✉ 21:39, 14. Nov. 2017 (CET)

Eigentlich war eher eine Tendenz zu "trusted uploader" zu erkennen… Aber ja, schon eine ziemlich Perversion des Rechtesystems (mit haarsträubender Begründung). --MGChecker – (📞| 📝| ) 21:50, 14. Nov. 2017 (CET)

Mit dieser erneuten Restriktion soll vermutlich Missbrauch vermieden werden. --\m/etalhead ✉ 18:31, 15. Nov. 2017 (CET)

Nur fürs Protokoll: Die Einschränkung basiert auf einer Communitydiskussion: c:Commons:Village pump#RFC: Which user groups should initially be allowed to upload mp3s?. Ich persönlich begrüße die MP3-Hochlademöglichkeit, sehe jedoch auch die Schwierigkeiten bei der Kontrolle auf URVs. — Raymond ^Disk. 18:52, 15. Nov. 2017 (CET)

Diese Probleme sind doch zunächst mal bei jedem Dateiformat präsent. Nur weil sie bei mp3 einfacher herbeizuführen sind, ist das für mich keine Begründung, da solche Schranken zu setzen. Und in dieser Diskussion ist keine wirkliche Tendenz zu der letztlich getroffenen Entscheidung zu erkennen. --MGChecker – (📞| 📝| ) 00:01, 28. Nov. 2017 (CET)

Ich sehe keinerlei Unterschied zu anderen Dateien. Die Gefahr, hier URVen zu produzieren, ist nicht wirklich höher. Das ist also nur ein vorgeschobener Grund. -- Chaddy · D – DÜP – 04:33, 28. Nov. 2017 (CET)

Daran ist nichts vorgeschoben. Bei Bildern kann jedermann auf den ersten Blick eine URV erkennen. Bei Sound ist das nicht möglich. Oder kannst du im File-Manager erkennen, ob eine Datei eines Hayden-Stücks identisch ist mit einer alten (gemeinfreien) Einspielung oder mit einer neueren, dem Urheberrecht unterliegenden? Du musst einen Dateivergleich vornehmen, der könnte aber durch winzige Änderungen schon wieder getäuscht werden. URVs sind bei Sound kaum zu erkennen, deshalb ist es sinnvoll, hier vorsichtig zu sein. Wenn nach einiger Zeit keine Probleme auftreten, kann man die Schwelle senken, zB auf die vier Tage beim Bilderupload auf de-WP. Oder auf Null wie auf Commons. Grüße --h-stt !? 18:41, 28. Nov. 2017 (CET)

Das Argument klingt zwar nachvollziebar, zieht aber nicht, da es seither ja auch schon möglich war, Audiodateien hochzuladen. 92.75.194.118 21:49, 1. Dez. 2017 (CET)

Seit gestern Abend hat der Missbrauchsfilter 192 auf Wikimedia Commons, der das Hochladen von MP3 unterbindet, sofern der Hochlader nicht in bestimmten Benutzergriuppen ist, 50 mal angeschlagen. Bei Durchsicht des Logs komme ich zu dem Schluss, dass ca. 40 Dateinamen auf geschützte Musikstücke hinweisen. Einige Benutzer wurden gesperrt mit der Begründung "Wikipedia Zero abuse: misusing Commons by sharing nonfree files".
@IP 92.75.: Das ist richtig, und ich weiß nicht, wieviele URVs darunter sind. OGG war aber nie wirklich verbreitet, und den Aufwand, MP3 nach OGG zu konvertieren, haben vermutlich nicht viele betrieben. — Raymond ^Disk. 22:32, 1. Dez. 2017 (CET)

Ablösung von Tidy auf dewiki in einigen Wochen

Hi folks, please see HD:LINT #Tidy-ex.

In a nutshell:

• MediaWiki is planning to leave HTML Tidy (from 1998) in December for dewiki.
• Someone might announce this on WP:NEU and explain it to the entire community, even more when broadcasted by Ausrufer.
• We might discover unknown rendering issues, bit we caused them by non-standard syntax ourselves.

Regards --PerfektesChaos 01:25, 17. Nov. 2017 (CET)

(The anchor doesn't work for me? This was the proposal text. Let me know if there's anything you'd like me to do! Best, Elitre (WMF) (Diskussion) 09:11, 17. Nov. 2017 (CET))

Hi again. I assume Hilfe:Wikisyntax/Parsermigration was developed with the switch in mind, again, great work there. Who can update WP:NEU? I know User:Raymond usually takes care of it, but again, let us know if there's anything we could clarify etc. Best, Elitre (WMF) (Diskussion) 17:37, 20. Nov. 2017 (CET)

Textvorschlag für Vorderseite; <del> und <ins> okay:

Dezember

Für Jedermann

Breaking News – Voraussichtlich Anfang/Mitte Dezember wird für die deutschsprachige Wikipedia die Nachbearbeitung des Wikitextes mit HTML Tidy durch eine an Wiki-Seiten angepasste Version von RemexHTML ersetzt werden.

• Enzyklopädische Artikel, aktive Projekt- und Portalseiten sowie Vorlagen werden voraussichtlich nicht betroffen sein; sie wurden seit dem Sommer bereinigt.
• Benutzerseiten, Diskussionen und vergleichbare Foren sowie archivierte Seiten und Dateibeschreibungen könnten eine veränderte Darstellung zeigen.
• Siehe den ersten Abschnitt („Hohe Priorität“) auf Spezial:LintErrors.
• Weitere Einzelheiten unter Hilfe:Wikisyntax/Parsermigration #Tidy.

Es handelt sich um Korrektursoftware, die bei fehlerhaftem Wikitext zu erraten versucht, was Autoren gemeint haben könnten, und den HTML-Text in der Schlussfassung korrigiert, unmittelbar bevor er an die Browser der Leser ausgeliefert wird.

• Eindeutige, saubere und standardmäßige Anwendung der Wikisyntax ist der sicherste Weg, um Darstellungsfehler und spätere Migrationsprobleme zu vermeiden. Bei undefinierten, invaliden und mehrdeutigen Konstrukten ist nicht vorhersagbar, wie im Lauf der Zeiten die Wikisoftware darauf reagieren wird. Die Absichten der Autoren sollten durch eine klare, eindeutige und möglichst knappe Notation repräsentiert werden.

VG --PerfektesChaos 21:03, 20. Nov. 2017 (CET)

Danke, ich habe das mal auf der Vorderseite gepostet. Gruß, --Gnom (Diskussion) 23:17, 23. Nov. 2017 (CET)

Ich habe irgendwo etwas vom 5. Dezember gelesen. Keine Ahnung ob es noch aktuell ist. Der Umherirrende 21:19, 30. Nov. 2017 (CET)

Das stand auf HD:LINT#Tidy-ex, aber im aktuellen Deployment-Plan finde ich davon nichts, noch relevante Treffer auf die Stichwörter dewiki Tidy Parsoid Remex. Deshalb bin ich mit einem Datum immer recht zurückhaltend. LG --PerfektesChaos 12:09, 1. Dez. 2017 (CET)

Gemeldet in Phabricator
Task T181188

Buon giorno! I confirm the switch date is tomorrow 5 December. The Parsing team's slot is the 18 UTC one, per calendar. This is happening during the European SWAT slot, 14:00 UTC. As announced, if you notice any incorrect rendering, you can use ?action=parsermigration-edit to identify if the switch from Tidy actually caused it, by appending it at the end of a URL. And again, if we/you notice problems, we can revert the change, after identifying the source of the problem. I think the fastest way to get attention from the team would be on IRC, in the #mediawiki-parsoid channel. Or you can ping me or mw:User:SSastry (WMF), of course. Hope this helps! I'm going to drop a quick note to de.wiki's IRC channel as well. Arrivederci, Elitre (WMF) (Diskussion) 11:44, 4. Dez. 2017 (CET)

Change is now live, and for people wanting to fix errors, Spezial:LintErrors (you do have some great documentation locally, lucky you!). Best, Elitre (WMF) (Diskussion) 15:23, 5. Dez. 2017 (CET)

Datenbanktrennung von de.wp und wikidata

Aktuell liegen wikidata und de.wp auf den gleichen Datenbankserver s5. Da Wikidata viele Ressourcen braucht, soll hier eine Trennung erfolgen. In phab:T181645 wird über die Community-Kommunikation geredet. Vielleicht möchte sich jemand einbringen. TL;DR: 9. Januar 2018, 06:00 UTC - 06:30 UTC. Der Umherirrende 21:21, 30. Nov. 2017 (CET)

Ich denke, das gehört Anfang des Jahres zumindest auf WP:FZW, vielleicht auf die Admin-Notizen (da lesen auch viele mit) und auf MediaWiki:Sitenotice. NNW 15:32, 5. Dez. 2017 (CET)

erledigtErledigt Wurde heute durchgeführt. Der Umherirrende 17:28, 9. Jan. 2018 (CET)