Wikipedia Diskussion:Projektneuheiten

Archiv

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

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, verbleiben mindestens 3 Abschnitte.

Beobachtungsliste-Nachfrage

1. Kann man diese (auf Commons jetzt schon) nervige Nachfrage irgendwie abschalten, also dass man das nicht unnötig nochmal bestätigen muss? (Ohne dass zwischendrin noch kurz was aufpoppt, und abgesehen von den anderen Problemen würde ich dem schon gerne eine Chance geben, weil mich die langen Ladezeiten auch stören)
2. Nach Verschwinden des Ladebalkens verbleibt ein unschöner Leerraum, da wo vorher der Button war.
3. Mit der erweiterten Beobachtungsliste (also der Variante, wo man alle Änderungen sieht) bleiben bei mehreren Änderungen die einzelnen Änderungen als ungelesen markiert.
4. Wie verhält sich diese Funktion bei zwischenzeitlich hinzugekommenen Änderungen? Werden diese wie bisher
   1. auch als gelesen markiert und
   2. sofort angezeigt, also wie wenn die Beo neu geladen würde?

--nenntmichruhigip (Diskussion) 15:58, 15. Dez. 2016 (CET)

Unnötiger Arbeitsoverhead. Bitte gleich wieder abschalten. --CeGe Diskussion 09:25, 16. Dez. 2016 (CET)

Nächstes Problem: Ich kann jetzt den Button – selbst nach Neuladen – nicht mehr drücken, also meine Beobachtungsliste praktisch nicht mehr nutzen. Ok, ich kann mittels der Webentwicklertools das disabled-Attribut entfernen, aber das kann man ja nicht von einem normalen Benutzer erwarten.

Meinen obigen Punkt 4 konnte ich inzwischen auch testen: Es ist der schlimmstmögliche Fall: Sie werden als gelesen markiert, aber nicht angezeigt, bis man die Seite neu lädt. Man muss also zusätzlich zum Bestätigen und dem Warten auf das Markieren nochmal genauso lange warten wie früher schon für alles zusammen.

Und dazu, dass das Bestätigen voll schnell gehen würde: Vorhin musste ich schon etwa fünf Sekunden lang darauf warten, dass der Bestätigungsdialog erscheint.

Ich wünsche euch dann mal schöne Weihnachtsfeiertage, und hoffe, dass das danach behoben ist… Siehe auch: Diverse Abschnitte auf FzW: 1, 2, 3 --nenntmichruhigip (Diskussion) 13:31, 16. Dez. 2016 (CET)

Oh, nochwas: Eine von mir selbst durchgeführte Zurücksetzung wurde iirc früher nie als ungelesen angezeigt, jetzt eben aber schon. --nenntmichruhigip (Diskussion) 13:37, 16. Dez. 2016 (CET)

@Umherirrender: Wann wird das hier hierzuwiki ankommen? --nenntmichruhigip (Diskussion) 10:05, 17. Dez. 2016 (CET)

Hab’ mir gerade mal den Button manuell freigeschalten: Es ist wohl da, aber es wurde nur die Nachfrage deaktiviert und die anderen Probleme nicht behoben. --nenntmichruhigip (Diskussion) 10:38, 17. Dez. 2016 (CET)

Bei mir ist der Button weg, aber es stört nicht, da ich die Seite ja eh irgendwann neuladen muss, um die neusten Änderungen zu sehen. Der Umherirrende 12:34, 17. Dez. 2016 (CET)

Bei mir war es bis zu der letzten Änderung so, dass der Button nach dem Neuladen dann inaktiv war. Das scheint jetzt nicht mehr neu aufzutreten, aber bestand bei mir weiterhin (also auch nach Neuladen), bis ich den Button einmal manuell aktiviert hatte. Und die anderen Probleme (für die ich vorhin Phab-Tickets erstellt habe) sind halt auch noch da. --nenntmichruhigip (Diskussion) 13:59, 19. Dez. 2016 (CET)

Ich habe mal Phab-Tickets für die verbleibenden Probleme angelegt:

1. Die Nachfrage wurde bereits wieder entfernt (phab:T153438)
2. phab:T153537
3. phab:T153536
4. siehe 6
5. Scheint behoben worden zu sein (phab:T153389). Musste den Button aber erst einmal manuell aktivieren, bisher funktioniert es jetzt.
6. phab:T153533

--nenntmichruhigip (Diskussion) 11:16, 17. Dez. 2016 (CET)

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)

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)

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 (Beispiel). Das kann noch lustig werden, weil wir zahlreiche Vorlagen haben, in denen das vorkommt (vor allem im Zusammenhang mit „versteckten“ „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)