Wikipedia:Technische Wünsche/Wunschparkplatz

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Willkommen auf dem Wunschparkplatz![Quelltext bearbeiten]

Etwa alle zwölf Monate findet die Umfrage Technische Wünsche statt, in der ein Themenschwerpunkt gewählt wird. Mit diesem Schwerpunkt beschäftigt sich das Team Technische Wünsche dann etwa zwei Jahre lang. (Mehr zu der Arbeit in Themenschwerpunkten steht hier.)

Die nächste Umfrage ist für Januar 2022 geplant. Bis zum 14. November wurden hier einige Themen und Probleme für die kommende Umfrage eingetragen. Danke dafür! In den kommenden Wochen sichtet das Team Technische Wünsche die Probleme aus dieser Quelle (und weiteren) und erarbeitet daraus Themenvorschläge, über die dann im Januar abgestimmt werden kann. Vor der Umfrage werden sie im Wiki präsentiert und können dort kommentiert werden. Genaueres zum Zeitplan findet sich hier auf der Umfrageseite.

Alles, was ab dem 15.11.2021 eingetragen wird, findet dann in der übernächsten Umfrage Verwendung. -- Johanna Strodt (WMDE) (Diskussion) 11:50, 15. Nov. 2021 (CET)

[Antworten]


Icon for the German Technical Wishlist Project Parkin Lot.svg

Wie entstehen die Themenschwerpunkte, über die in der Umfrage abgestimmt wird?[Quelltext bearbeiten]

Die zur Wahl stehenden Themenschwerpunkte werden vom Team vorbereitet, damit sie

  1. im Rahmen der zwei Jahre, die für die Umsetzung zur Verfügung stehen, machbar wären, und
  2. so formuliert sind, dass sie auch für technisch weniger Versierte gut verständlich sind.

Konkret sichtet das Team Technische Wünsche ab dem 15. November verschiedene Quellen aus den deutschsprachigen Communitys (unter anderem diesen Wunschparkplatz) und schnürt daraus die Themenschwerpunkte für die Umfrage. Vor der Umfrage wird es noch die Möglichkeit geben, diese Pakete zu kommentieren.

Welche Bedeutung haben die konkreten Probleme für die Umfrage?[Quelltext bearbeiten]

Alle eingereichten konkreten Probleme dienen dazu, größere Themen zu identifizieren. Abgestimmt wird in der Umfrage allerdings nur über Themenschwerpunkte und nicht über konkrete Probleme darin.

Erst wenn der Gewinnerschwerpunkt feststeht, wird in einer ausführlichen Recherchephase unter Einbindung der Community erarbeitet, was die größten Probleme darin sind. Dann werden schon eingereichte Probleme betrachtet, aber wahrscheinlich zeigen sich dann auch noch weitere wichtige Probleme. Welche davon das Projektteam dann angeht, entscheidet sich anhand verschiedener Kriterien, z. B. wie groß der Nutzen ist, Machbarkeit und mehr.

Vorschläge für die Umfrage im Januar 2022[Quelltext bearbeiten]

Alle Probleme, die seit Juni 2020 hier notiert oder kommentiert wurden.

Platzierung von Diskussions-Seiten-Links in der mobilen Ansicht[Quelltext bearbeiten]

Was ist das Problem?

Die Platzierung von Diskussionsseiten-Links ist in der Desktop-Ansicht über die gesamte Wikipedia hinweg gleich, in der mobilen Ansicht aber seitenspezifisch unterschiedlich:

Diskussionsseiten-Links

  1. Im Artikelnamensraum unter dem kompletten Artikel (bei langen Artikeln nur durch langes Scrollen erreichbar)
  2. Im Benutzernamensraum klein unter dem Namen (warum nicht als Button wie im Artikelnamensraum?!)
  3. Die Diskussion zur Hauptseite ist aus der mobilen Ansicht heraus nicht erreichbar.
Wen betrifft das Problem besonders?

Alle Leser, die Wikipedia in der mobilen Ansicht nutzen.

Lösungsvorschlag
Keine der drei Platzierungen finde ich richtig gelungen. Am liebsten wäre mir entweder ein Link im Seitenmenü oder ein Button im oberen Bereich der Seite. In jedem Fall sollte die Platzierung genauso einheitlich realisiert werden wie in der Desktop-Ansicht.
Vorschlagende Person

Tkarcher (Diskussion) 12:01, 2. Okt. 2017 (CEST)[Antworten]

Diskussion

ja. fände ich wichtig. überhaupt, dass mobile die diskussion zugänglich gemacht wird. --Sms2sms (Diskussion) 10:21, 28. Mär. 2019 (CET) Oh, ja, das Problem kenne ich. Hoffe ebenfalls auf eine baldige Lösung.— Sivizius (Diskussion) 08:12, 4. Jul. 2020 (CEST)[Antworten]

Diskussion sollte ein Link sein und kein Button, weil navigiert wird. Buttons stehen eher fuer Aktionen. Anstelle von

Im Benutzernamensraum ... Warum nicht als Button wie im Artikelnamensraum ?!

wuerde ich also schreiben:

Im Artikelnamensraum ... Warum nicht als Link wie im Benutzernamensraum ?!

-- Juergen 217.61.204.70 12:47, 8. Jun. 2021 (CEST)[Antworten]

Das lässt sich dadurch erreichen, dass die erweiterte Mobilansicht (advanced mobile contributions) zur Standardansicht gemacht wird. Würde ich sehr begrüßen.–XanonymusX (Diskussion) 13:14, 26. Okt. 2021 (CEST)[Antworten]
Pro Klingt logischer. --Grizma (Diskussion) 10:31, 1. Nov. 2021 (CET)[Antworten]



Automatische Ersetzung bestimmter Zeichen[Quelltext bearbeiten]

Was ist das Problem?

Viele Bearbeitungen in der Wikipedia gehen auf formale Sachen zurück, wie z. B. das Setzen von richtigen Anführungszeichen („ und “ anstatt " ") oder eines Halbgeviertstrichs (– anstatt -) oder des geschützten Leerzeichens bei z. B.; u. a. usw. . Wenn man die richtigen Zeichen auf der Tastatur kennt, oder die kleinen Zeichen unten am Quelltexteditor beachtet, ist das kein Problem. Aber viele machen das nicht und so fällt formale Arbeit an, die sich mittels Technik beheben lässt.

Wen betrifft das Problem besonders?

Erstmal die Neuautoren, weil viele es nicht richtig wissen, aber auch die erfahrenen Autoren, weil sie es korrigieren müssen.

Lösungsvorschlag

Automatische Ersetzung von Kombinationen, die die Wikisoftware erkennt:

  • Leerzeichen + Anführungszeichen + Buchstabe ( "b) durch „b
  • Buchstabe + Anführungszeichen + Leerzeichen (b" ) durch b“
  • Buchstabe + Leerzeichen + Minus + Leerzeichen + Buchstabe (b - b) durch b – b
  • z. B. direkt durch z.& nbsp;B. (nur ohne Leerzeichen nach dem &)
    Vorschlagende Person

Craeosh 77 (Diskussion) 14:39, 2. Jun. 2019 (CEST)[Antworten]

Diskussion

Pro  — Johannes Kalliauer - Diskussion | Beiträge 12:36, 10. Jul. 2020 (CEST)[Antworten]

Pro  — --Klaus-Peter (aufunddavon) 05:39, 11. Jul. 2020 (CEST)[Antworten]

Neutral Sowas wird wohl nur mit aktiviertem JavaScript funktionieren (was bei mir i.d.R. abgeschaltet ist). NB: sorry für die Darstellungsänderungen ... :) [Signatur fehlt]

Pro — --Fuchs B (Diskussion) 20:34, 31. Okt. 2021 (CET)[Antworten]

Änderungsvorschlag: Grundsätzlich gute Idee. In manchen Fällen kann man aber auch explizit die ersetzten Zeichen wollen. Deshalb bin ich der Meinung, dass die automatischen Änderungen vorgeschlagen werden, und man ja oder nein klicken muss. Eine automatische ERsetzung finde ich problematisch. Wir kennen doch alle Autokorrektur-Fails. --Fan-von-mir (Diskussion) 13:32, 29. Okt. 2021 (CEST)[Antworten]

Pro für optional. Zumal in der Einzelnachweis-Formatvorlage im Visual Editor die Korrektur der Zeichen nicht möglich ist, dafür muss ich erst wieder in den Quelltext wechseln, um dann auf die kleine Leiste unter dem Bearbeitungsfenster zu klicken. Auch wieder ein Arbeitsschritt mehr als nötig. --Grizma (Diskussion) 10:29, 1. Nov. 2021 (CET)[Antworten]

Pro ---Bärbel Miemietz (Diskussion) 20:14, 14. Nov. 2021 (CET)[Antworten]

Pro — --Gnom (Diskussion) Wikipedia grün machen! 20:20, 15. Nov. 2021 (CET)[Antworten]

Pro für optional — --Wilhelm (Diskussion) 08:56, 20. Nov. 2021 (CET)[Antworten]



Automatische alphabetische Reihenfolge auf Begriffsklärungsseiten[Quelltext bearbeiten]

Was ist das Problem?

Ich habe heute in einem Artikel den Boxverband „IBO“ verlinkt und ich kam natürlich, wie gewünscht, erst einmal auf die Begriffsklärungsseite Ibo. Wie schon des Öfteren, habe ich zunächst die Begriffsklärungsseite aufgeräumt, also alle Einträge nach dem ABC geordnet. Das habe ich bei unterschiedlichen Begriffsklärungsseiten schon oft gemacht, aber eigentlich wollte ich mich damit nicht aufhalten, dachte nur, dass es sinnlos wäre, eine falsche alphabetische Reihenfolge stehen zu lassen.

Wen betrifft das Problem besonders?
  • Leser, die nach einem bestimmten Begriff suchen und dann eine verwirrende, fehlerhafte alphabetische Sortierung vorfinden
  • Autoren, die nicht nur eine angetäuschte alphabetische Reihenfolge wünschen, sondern eine tatsächliche alphabetische Reihenfolge
Lösungsvorschlag
wenn jemand einen neuen Begriff einträgt, zum Beispiel bei Ibo, dann wird ihm eine Maske gezeigt mit genau zwei Feldern: erstes Feld Pflicht: der Begriff (zum Beispiel International Boxing Organization), zweites Feld keine Pflicht: die Erklärung (im Fall der International Boxing Organization ist eine Erklärung obsolet, zweites Feld wird nicht ausgefüllt)
Anmerkungen
  • bessere Wirkung nach außen durch korrekte Anwendung des ABC
  • Autoren-Arbeitsaufwand sinkt nach Erfüllung des Wunschs
    Vorschlagende Person

Bluemel1 🔯 08:39, 10. Jun. 2019 (CEST)[Antworten]

Diskussion



Automatisches Eintragen von Artikeln bei LA, QS, etc.[Quelltext bearbeiten]

Was ist das Problem?

Es kann doch nicht sein, dass man alle Artikel immer noch manuell in auf der LA-Diskseite, QS-Seite, etc. eintragen muss, wenn man die Vorlagen ({{ers:QS...}}, {{ers:Löschantrag...}}, etc. einbindet, oder? Das muss doch automatisch auch gehen.

Wen betrifft das Problem besonders?

alle Benutzer

Lösungsvorschlag
automatische Eintragung von Artikeln auf den vorgesehenen Seiten
Vorschlagende Person

Lg {TheToklDisk 📢E-Mail ✉️❔Hilfe❔} 12:26, 10. Sep. 2019 (CEST)[Antworten]

Diskussion

Der Vorschlag ist hier nicht umsetzbar. Jedes Projekt hat eigene Regeln und Seiten, daher muss dieser Vorschlag per Userscript umgesetzt werden und nicht per MediaWiki.-𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬Rechte ︱ Kenst du scho de boarische Wikipedia? 22:16, 8. Nov. 2020 (CET)[Antworten]



Anlagen von weiterleitungen zu nicht existierenden Seiten verhindern[Quelltext bearbeiten]

Was ist das Problem?

Weiterleitungen können ohne Einschränkung angelegt werden; da kann es vorkommen, dass sich jemand vertippt oder auch absichtlich Vandalismus betreibt.

Wen betrifft das Problem besonders?

Jeden, der sich vertippt, und vor allem Autoren der boarischen Wikipedia.

Lösungsvorschlag
Der Missbrauchsfilter könnte so angepasst werden das der Filter Weiterleitungen prüfen kann.
Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 Kenst du scho de boarische Wikipedia? 11:19, 19. Nov. 2019 (CET)[Antworten]

Diskussion
  • Eine Warnung (und nicht sofortiges Speichern) kann sinnvoll sein – Verunmöglichung wäre doof! Oftmals ist es sehr wohl angebracht, eine WL auf eine noch nicht existierende Seite zu setzen – nämlich wenn parallel dazu dort etwas entstehen oder etwas dorthin verschoben werden soll. (PS: sorry für Ortho)--ProloSozz (Diskussion) 11:49, 7. Jul. 2021 (CEST)[Antworten]
  • Kann man dies mithilfe eines Bearbeitungsfilters umsetzen? --Zabe (Diskussion) 15:55, 25. Okt. 2021 (CEST)[Antworten]



Massblock-Erweiterung[Quelltext bearbeiten]

Was ist das Problem?

Bei Spambots und LTAs ist es oft nötig 100+ Accounts zu sperren, dies ist sehr aufwendig und dauert lange. Zwar gibt es Scripts wie m:User:Tks4Fish/massBlock.js Massensperrungen erheblich beschleunigen diese Scripts haben aber auch Grenzen und sind in der Bedienung auch nicht gerade schnell.

Wen betrifft das Problem besonders?

Administratoren/Globale Administratoren/Stewards

Lösungsvorschlag
Eine Erweiterung die es durch eine Auswahl (z. B. Checkboxen) in Logbüchern (letzte Änderungen/Neuanmeldungslogbuch) ermöglicht, diese Accounts mit vergleichsweise wenig Aufwand zu sperren.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬Rechte | Kenst du scho de boarische Wikipedia? 10:31, 26. Jul. 2020 (CEST)[Antworten]
Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬Rechte | Kenst du scho de boarische Wikipedia? 10:31, 26. Jul. 2020 (CEST)[Antworten]

Diskussion



Artikel auf Wiedervorlage setzen[Quelltext bearbeiten]

Schaffung einer Möglichkeit, für Artikel eine (benutzerspezifische) Wiedervorlage einzurichten. ==

Was ist das Problem?

Derzeit gibt es keine besonders gut geeigneten Hilfsmittel, um Artikel mit sich regelmäßig (aber nicht zwingenderweise häufig) ändernden Informationen aktuell halten. Ein Beispiel sind Unternehmensartikel, in denen man in jährlichem Turnus die Umsatz- und Mitarbeiterzahlen aktualisieren möchte.

Wen betrifft das Problem besonders?

(angemeldete) Benutzer, die eine größere Anzahl Artikel längerfristig aktuell halten wollen

Lösungsvorschlag

Ähnlich dem Stern zum Hinzufügen eines Artikels zur Beobachtungsliste gibt es ein weiteres Icon. Beim Klick auf das Icon erscheint ein Popup oder eine anderweitige Eingabemöglichkeit, die es dem Benutzer erlaubt, zu spezifizieren, wann der Artikel wiedervorgelegt werden soll (bspw. "in x Tagen/Wochen/Monaten" oder "am dd.MM.yyyy").

Ähnlich der Beobachtungsliste gibt es zudem eine Wiedervorlageliste:

  • Die auf WV gesetzten Artikel sind darin anhand des ausgewählten WV-Datums sortiert.
  • Einträge, deren WV-Datum in der Vergangenheit liegt, die aber immer noch auf der Liste sind (d.h. nicht als erledigt markiert worden sind), werden in geeigneter Weise hervorgehoben (z.B. farblich).
  • Jeder der Einträge kann einzeln als "erledigt" markiert werden (dann verschwindet er von der Liste).
  • Alternativ zum "erledigen", sollte man auch "erledigen und erneut wiedervorlegen" können; in diesem Fall erscheint erneut ein Popup zur Auswahl des WV-Termins wie eingangs beschrieben.

Die WV-Funktion sollte unabhängig davon funktionieren, ob ein Artikel beobachtet wird oder nicht.

Optional: Beim erstmaligen Aufruf einer dewiki-Seite an einem Tag wird der Benutzer auf fällige WV hingewiesen (bspw. per Browser-Benachrichtigung).
Vorschlagende Person

M-hue (Diskussion) 06:28, 10. Aug. 2020 (CEST)[Antworten]

Diskussion

Aus ähnlichem Wunsch eines Benutzers habe ich mal eine Komplettbeobachtungsliste programmiert, um sich seine ältest-ungeänderten Artikel gelegentlich zur Brust zu nehmen, Du meinst das natürlich noch viel automatischer. --DB111 (Diskussion) 00:52, 9. Nov. 2020 (CET)[Antworten]

Das ist ja schön und hilfreich, aber nie gebe ich in einer externen Anwendung mein Passwort ein. Das sollte für alle 3 Listen entbehrlich sein.--Klaus-Peter (aufunddavon) 06:40, 9. Nov. 2020 (CET)[Antworten]
Die Bedenken kann ich verstehen (ich versichere hiermit nochmal ausdrücklich, dass das Passwort in keiner Weise abgegriffen oder missbraucht wird), das wurde wie gesagt auch nur nach einem Stammtischgespräch für jemanden gebastelt, der konkret dieses Problem hatte. Die Beobachtungsliste ist persönlich und geheim, ohne Authentifizierung des Nutzers geht da nichts. Falls die hier vorgeschlagene Funktionalität aber ewig auf sich warten lässt, werde ich die Funktion vielleicht auch mal als Helferlein in die normale Wiki-Oberfläche integrieren, dann ohne Extra-Anmeldung. --DB111 (Diskussion) 11:33, 9. Nov. 2020 (CET)[Antworten]
Jetzt ohne Extra-Anmeldung... --DB111 (Diskussion) 17:00, 3. Mai 2021 (CEST)[Antworten]

Siehe auch Benutzer:Schnark/js/notizen mit seitengebundener Erinnerung. --FriedhelmW (Diskussion) 21:53, 8. Apr. 2021 (CEST) Siehe auch Benutzer:ErinnerMichBot. Wobei ich nichts dagegen hätte, diesen Bot durch eine bessere, integrierte Lösung zu ersetzen. --Tkarcher (Diskussion) 12:10, 26. Okt. 2021 (CEST)[Antworten]

Pro — --Gnom (Diskussion) Wikipedia grün machen! 20:20, 15. Nov. 2021 (CET)[Antworten]



Privaten Notizblock[Quelltext bearbeiten]

Was ist das Problem?

Wenn man sich etwas Notieren, muss/möchte kann man das entweder öffentlich im Benutzernamensraum machen oder man benötigt etwas Externes. Nicht alle Notizen sollen öffentlich sein, dies erfordert immer eine Externe Lösung und ist unpraktisch.

Wen betrifft das Problem besonders?

Autoren Administratoren usw.

Lösungsvorschlag
Eine Art Notizblock auf den nur der Autor/Benutzer zugriff hat.
Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬Rechte | Kenst du scho de boarische Wikipedia? 11:18, 11. Aug. 2020 (CEST)[Antworten]

Diskussion

So öffentlich ist der Benutzerraum nicht! Einfach mal Benutzer:WikiBayer/Schmierzettel anlegen, das kommt nur raus, wenn man es verbreitet oder gute Hacker bemüht.--Klaus-Peter (aufunddavon) 13:49, 11. Aug. 2020 (CEST)[Antworten]

Oder wenn man »Benutzer:…« in die Suche eingibt, meist reichen auch schon die Vorschläge. Aber ich glaube, ein einfacher Schmierzettel, ob auf Papier oder als .txt, reicht wohl auch. Aber ich wäre dieser Idee nicht abgeneigt, vielleicht ist das gar nicht mal so schlecht, vor allem, wenn man von mehreren Rechnern editiert und nicht den eigenen Rechner zumüllen will.— Sivizius (Diskussion) 20:02, 21. Aug. 2020 (CEST)[Antworten]
Oder wenn man auf Spezial:Präfixindex/Benutzer:WikiBayer geht. --Zabe (Diskussion) 15:59, 25. Okt. 2021 (CEST)[Antworten]


Das Problem an Benutzerunterseiten ist, dass da jedes Detail in der Beitragshistorie landet. Ein Notizzettel ist da schon praktischer. Mittlerweile nutze ich eine lokale Textdatei. Der Vorteil eines Notizzettel ist aber, dass er überall, egal wo man sich einloggt, verfügbar ist. Also schon sinnvoll, wenn auch höchstpriorisiert mMn --Fan-von-mir (Diskussion) 13:44, 29. Okt. 2021 (CEST)[Antworten]
  • Kontra Finde, jede*r kann sich eine lokale Textdatei anlegen und auf die eigene Cloud legen, das muss WP nicht leisten. Was für Notizen sollten denn nicht BNR-öffentlich sein? Ist dann WP auch für den Datenschutz zuständig, falls der Private Notizblock gehackt wird? Gruß --Fuchs B (Diskussion) 20:40, 31. Okt. 2021 (CET)[Antworten]

Überschriften aus Tabellen; Links auf Abschnitte aus Tabellen setzen.[Quelltext bearbeiten]

Was ist das Problem?

Beim Verwenden von Tabellen kann die Sortierfunktion ganz nützlich sein. Das Problem daran ist, dass mögliche Zwischenüberschriften nicht mehr im Inhaltsverzeichnis auftauchen und auch nicht mehr direkt auf diese verlinkt werden kann. Fügt man == ... == in der Tabelle ein, erscheinen zwar die Zeichen in der Tabelle, aber der Text wird nicht, wie üblich, als Überschrift formatiert. 217.85.16.81 07:45, 19. Aug. 2020 (CEST)[Antworten]

Wen betrifft das Problem besonders?
Vorschlagende Person

217.85.16.81 07:45, 19. Aug. 2020 (CEST)[Antworten]

Diskussion



Kommentar beim Danken sowie Undank- Funktion einführen und Kommentar beim Undank[Quelltext bearbeiten]

Was ist das Problem?

Wenn ich eine Änderung sinnvoll finde bedanke, ich mich sehr gerne und manchmal möchte ich noch ein paar Wöter an den Bedankten hinzufügen. Gleichzeitig gibt es Situationen, in den ich den Änderung nicht so glücklich finde, sie aber akzeptiere (warum auch immer). Wäre es da nicht konsequent, dies mit einem Undank auszudrücken. Auch den Undank würde ich dann möglicherweise kommentieren wollen.

Wen betrifft das Problem besonders?

Auf die Idee bin ich beim Lesen des Universal Code of Conduct gekommen. Vielleicht würden dies auch zur Durchsetzung des Universal Code of Conduct betragen.

Lösungsvorschlag
Erweiterung der Danke-Funtion um eine Kommentarmöglichkeit und Schaffung einer Undank-Funktion mit Kommentarmöglichkeit.
Anmerkungen
Ganz konsequent wäre es dann, wenn Undank genauso wie Dank in der Statistik der Bearbeitungen ausgewiesen werden würde.
Vorschlagende Person

Mobil-Sockenpuppe (Diskussion) 13:39, 20. Sep. 2020 (CEST)[Antworten]

Diskussion

"Undank- Funktion einführen" Trolle jubeln jetzt schon. Kommentare kann man auch auf einer Diskussionsseite hinterlassen. Der Vorschlag ist zwar nicht schlecht, aber es gibt weitaus wichtigere Baustellen, die angegangen werden müssen.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬Rechte ︱ Kenst du scho de boarische Wikipedia? 10:58, 11. Nov. 2020 (CET)[Antworten]

Also ich verstehe den Gedanken schon. Wenn ich mir das vorstelle, meine ich, dass sich dadurch die Stimmung innerhalb der Community im besten Fall konstant bleibt, weil es nicht genutzt wird, die Stimmung sich verschlechtert oder im schlimmsten Fall sogar kippen könnte. Ich glaube eine Verschlechterung der Stimmung innerhalb der Community kann man nicht wollen, weil es ja auch die Motivation mindert. Und wenn Beiträge garnicht angehen, gibts ja schon die Revert-Funktion. --Fan-von-mir (Diskussion) 13:50, 29. Okt. 2021 (CEST)[Antworten]
Ja, ich erinnere mich auch an einen problematischen Benutzer, der grundsätzlich alles anders machen wollte als vorgesehen. Der hat neue Artikelversionen auf Benutzerdiskussionsseiten verhandelt, neue Artikelversionen erst mal auf der englischen Wikipedia gespeichert etc. Probleme mit Benutzern wurden auf Artikeldiskussionsseiten oder in der Kommentarzeile verhandelt oder auf VM. Und die Danke-Funktion hat er immer dann benutzt, wenn er mit irgendwas nicht zufrieden war, wofür auch sonst? --Giftzwerg 88 (Diskussion) 12:34, 31. Okt. 2021 (CET)[Antworten]
  • Kontra --Fuchs B (Diskussion) 20:45, 31. Okt. 2021 (CET)[Antworten]
  • Kontra Es wird schon genug gehatet, dafür ein Knöpfchen einführen, das es sogar noch mehr erleichtert? Nein danke. --Grizma (Diskussion) 10:23, 1. Nov. 2021 (CET)[Antworten]
  • Letztlich geht es darum eine konkrete Änderung zu kommentieren. Heute kopiere ich dazu den Difflink auf die Diskussionsseite und schreibe dann meine Bemerkung. Wenn das einfacher wäre wird der Undankknopf nicht gebraucht.—Hfst (Diskussion) 12:25, 1. Nov. 2021 (CET)[Antworten]



Gespeicherte Artikel in Mobile App auch in Browser Version sichtbar[Quelltext bearbeiten]

Was ist das Problem?

Unterwegs nutze ich die Wikipedia App (Native iOS), um Artikel zu lesen und setzte Lesezeichen (Gespeicherte Artikel), wenn ich später weiterlesen oder ergänzen möchte. Es wäre super, wenn ich auf diese Liste auch in der Browser-Version zugreifen könnte, sofern ich unter gleichem Namen eingeloggt bin.

Wen betrifft das Problem besonders?

Alle Nutzer, die regelmäßig zwischen Wikipedia browserbasiert am Desktop und einer (nativen iOS/Android) mobile App hin und her wechseln.

Lösungsvorschlag
In der Browserversion gibt es die "Beobachtungsliste". An ähnlicher Position könnten auch die mobil gespeicherten Artikel aufgeführt werden, falls technisch möglich.
Vorschlagende Person

Tine2nd (Diskussion) 21:07, 9. Okt. 2020 (CEST)[Antworten]

Diskussion
Pro Betrifft auch den Abschnitt weiter unten zum Thema App-Verbesserungen. Dass die Beo nicht geräteübergreifend nutzbar ist, ist lästig. --Grizma (Diskussion) 10:22, 1. Nov. 2021 (CET)[Antworten]



Ping-Funktion an Oversighter und Admins für dringende Versionslöschungen[Quelltext bearbeiten]

Was ist das Problem?

Hallo zusammen, es kommt immer wieder vor, dass in der Wikipedia Texte eingebracht werden, die Versionsgelöscht werden müssen. Das sind z.B. schwere Beleidigungen gegen im ANR beschriebene Personen, gegen Autoren, Volksverhetzungen aber z.B. auch ANON-Verstöße. Auf häufig frequentierten Seiten werden solche Sätze meist recht schnell enfernt, aber gerade auf abgelegenen Seiten, die nur von wenigen Personen beobachtet werden, stehen solche Verstöße oft viele Stunden. Nun kann man zwar eine VM stellen, die dann oft schnell abgearbeitet wird, allerdings ist das natürlich immer auch mit einem gewissen Streisand-Effekt verbunden, weswegen diese Option gerade für besonders schwere Verstöße flach fällt. Die empfohlene Alternative, diskret eine E-Mail an die Oversighter zu schreiben, führt abhängig von er Tageszeit aufgrund der geringen Zahl dieser Posten nicht selten dazu, dass die Entfernung erst nach einigen Stunden stattfindet. Das ist eine suboptimale Situation, wofür man aber den Oversightern keinen Vorwurf machen kann. Dashalb wäre es gut, wenn es eine technische Lösung für dieses Problem gäbe, die sowohl schnell als auch effektiv ist.

Wen betrifft das Problem besonders?

Diverse, sowohl Autoren als auch Personen mit Wikipedia-Artikel

Lösungsvorschlag

Mein Lösungsvorschlag wäre deshalb, die Pingfunktion so zu erweitern, dass man mit dieser diskret Oversighter und ggf. Admins auf Verstöße aufmerksam machen kann. Ich stelle mir vor, dass in der Versionsgeschichte neben der Danke-Funktion auch ein Versionslöschungs-Funktion implementiert wird. Löst diese ein Autor aus, dann erhalten alle Oversighter einen Ping, dass eine Versionslöschung beantragt wurde (hier sollte am besten noch ein Kommentar übermittelt werden können), sodass diese sofort zur Tat schreiten und bei Bedarf die Version verstecken können. Alternativ könnte der Ping zusätzlich auch an Admins gehen, um die Geschwindigkeit abzuarbeiten (evtl. auch mit Wählfunktion Nur Oversighter bzw. Oversighter plus Admins).

Optimal wäre eine Funktion, bei der das System automatisch erkennt, welche Admins aktiv sind, und nur diesen dann einen Ping zukommen lässt. Das könnte z.B. so funktionieren, dass nach Auslösen des Alarms durch einen Autoren nur die Admins einen Hinweis bekommen, die darauf editiert haben. Wenn also um 12:00 ein Alarm ausgelöst wird und um 12:01 ein Admin einen Edit tätigt, bekommt er mit diesem Edit einen Ping "Versionslöschung angefragt". Ein Admin, der hingegen nicht editiert, bekommt auch nichts angezeigt. So könnte der Kreis der Empfänger begrenzt werden, ohne an Effektivität und Bearbeitungsgeschwindigkeit zu verlieren. Natürlich müssten abarbeitende Admins diesen Ping dann auch abschalten können, entweder durch die Versionslöschung oder eben, falls nicht angebracht, durch aktives Abschalten. Um etwaigen Missbrauch der Meldefunktion durch IPs oder Vandalen zu verhindern, könnte man die Nutzung der Funktion nur auf (aktive/passive) Sichter beschränken.
Anmerkungen
Steht alles bereits oben
Vorschlagende Person

Andol (Diskussion) 21:09, 12. Okt. 2020 (CEST)[Antworten]

Diskussion

Hat enormes Missbrauchspotential und es gibt bereits Möglichkeiten Admins zu informieren ohne extrem viel Aufmerksamkeit auf sich zu ziehen--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬Rechte ︱ Kenst du scho de boarische Wikipedia? 13:29, 8. Nov. 2020 (CET)[Antworten]

Leider hapert es auch an der mitunter mehr als lässigen Aufmerksamkeit der Admins, z.B. in WP:AA. Da erlebte ich schon Anfragen, die ohne jegliche Admin-Reaktion archiviert wurden. Das ist fast so langweilig und witzlos wie hier. --Klaus-Peter (aufunddavon) 11:39, 12. Dez. 2020 (CET)[Antworten]

Oversighter kann man potienziell in [#wikipedia-de-os] Webchat anpingen. --Zabe (Diskussion) 16:04, 25. Okt. 2021 (CEST)[Antworten]



Beobachtungsliste, Trennung Artikel / Diskussion[Quelltext bearbeiten]

Was ist das Problem?

Wenn man einen Artikel beobachten will, hat man immer die Diskussionsseite mit auf der Beobachtungsliste. Manchmal möchte man aber nur die Änderungen am Artikel verfolgen und keine ausufernenden Diskussionen, die manchmal zeitgleich dazu stattfinden. Andererseits gibt es vielleicht auch Seiten, auf denen man lieber nur die Diskussion verfolgt, aber von den Artikeländerungen nichts mitbekommen will.

Wen betrifft das Problem besonders?

Jeden, der auf seine Beobachtungsliste schaut.

Anmerkungen
Verfeinern könnte man die Sache noch, wenn sich nur einzelne Artikel- oder Diskussionsabschnitte auf die Beobachtungsliste setzen lassen. Wird aber vermutlich schwierig, weil sich die Überschriften der Abschnitte jederzeit ändern können.
Vorschlagende Person

Sinuhe20 (Diskussion) 12:30, 5. Nov. 2020 (CET)[Antworten]

Diskussion
  • Sehr gut!!! Ich stehe voll dahinter! Ich habe zwar keine Ahnung, wie und wo es technisch realisierbar ist, aber könnte mir vorstellen, dass man in der Beobachtungsliste statt [[Artikel:Diskussion]] [[Artikel:Diskussion#Abschnitt]] speichert/verfolgt. --Klaus-Peter (aufunddavon) 06:08, 6. Nov. 2020 (CET)[Antworten]
  • Still ruht der See und man sollte den Parkplatz in Abstellplatz umbenennen. Zeit kann man besser verplempern! --Klaus-Peter (aufunddavon) 11:48, 12. Dez. 2020 (CET)[Antworten]



Missbrauchsfilter besser Filtern[Quelltext bearbeiten]

Was ist das Problem?

Das Missbrauchsfilterlogbuch bietet einen guten Überblick über Vandalen/Spambots. Es gibt immer eine Vielzahl von Einträgen, die aber nicht immer aktuell sind, dies muss man aber immer kontrollieren.

Wen betrifft das Problem besonders?

Administratoren/Globale Administratoren/Stewards/andere Benutzer die mit dem Logbuch arbeiten.

Lösungsvorschlag
Die Filtermöglichkeiten sollten ausgebaut werden. Zum Beispiel Einträge von gesperrten und global gesperrten Benutzer ausblenden.
Vorschlagende Person

𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬Rechte ︱ Kenst du scho de boarische Wikipedia? 13:26, 8. Nov. 2020 (CET)[Antworten]

Diskussion



geprüfte Datenübernahme aus Wikidata[Quelltext bearbeiten]

Was ist das Problem?

Daten, welche in Wikidata gepflegt werden, und durch Einbindung / Verknüpfung in der deutschen Wikipedia erscheinen können, sollten vor der automatischen „Datenübernahme“ im Artikel überprüft werden.
In der de.wikipedia wird mit der Einbindung von Wikidata-Daten sehr unterschiedlich verfahren. In der Vorlage:Infobox Software können Daten aus der Wikidata übernommen werden, in anderen Vorlagen, z.B. in der Vorlage:Infobox Unternehmen ist eine Datenverknüpfung nicht gewünscht. Die ablehnende Haltung hinsichtlich der Einbindung der Wikidata wird damit begründet, dass die automatisch „übernommenen“ / angezeigten Daten im Artikel keiner Sichtung unterliegen und somit die Qualität der Artikel gemindert werden kann.

Wen betrifft das Problem besonders?

Auch wenn Wikidata eine andere Plattform ist, bietet sie doch Chancen für die Gesamtstuktur wikipedia.org und damit auch Chancen für die de.wikipedia.

Lösungsvorschlag
Um von der zentralen Datenhaltung der Wikidata profitieren zu können und gleichzeitig den hohen Qualitätsanforderungen der de.wikipedia gerecht werden zu können, sollen Artikel, in denen Wikidata-Daten eingebunden sind, den Status „ungesichtet“ erhalten, sofern Daten in der Wikidata aktualisiert und somit im Artikel angezeigt werden.
Vorschlagende Person

WikiFreibeuter Kontakt 11:07, 11. Dez. 2020 (CET)[Antworten]

Diskussion

Der Ansatz ist beachtenswert. Wikidata ist eine tolle Idee, aber ein recht stumpfes Schwert.
Primär sehe ich das Problem bei der teilweise mangelhaften Pflege von Wikidata. Die Idee ist ja generell zu begrüßen, aber oft erweckt es den Eindruck, dass Wikidata zwangsläufig mitgeschleppt wird.

Alle Autoren sollten generell und international animiert werden, diese Daten vorrangig zu pflegen, damit der globale Nutzen gewährleistet wird. Wenn man sich auf Wikidata verlassen kann, sollte eine Nachprüfung (Status „ungesichtet“ ) obsolet sein. Mein Ergänzungs- oder Alternativvorschlag:

  • Entwicklung einer bequeme (und damit quasi einladenden) Editieroberfläche für Wikidata (mehrsprachig) bei der alle gemeinsam relevanten Daten erfasst und gepflegt werden.
    • Der derzeitige Aufbau von Wikidata ist nur versierten Autoren zugänglich. die die Property-Nummern im Kopf haben.
  • Deutlicher Hinweis auf ALLEN Bearbeitungsseiten, Wikidata zu pflegen (Ergänzung, Aktualisierung)
    • Ggf. Wikidata durch Quellangaben zu ergänzen, die evtl. auch in den Artikel als Verweis übernommen werden.
  • Entwicklung einer ‚Universalvorlage‘, mit der locker und bequem Wikidata abgefragt und eingebunden werden kann.
    • Auch hier sollte Eingabe via Klartext in Property-Nummern umgesetzt werden.

Als Denkansatz sehe ich die individuell resp. gestaltbaren Möglichkeiten von JOSM mit entsprechenden Vorlagen/Plugins an. Denkbar wäre auch etwas Generierbares auf der Basis von TemplateData/Generator. Doch das ist noch ein weiter Weg. --Klaus-Peter (aufunddavon) 11:33, 12. Dez. 2020 (CET)[Antworten]

Dem ersten Punkt kann ich irgendwie nicht zustimmen, die Oberfläche von Wikidata ist schon sehr benutzerfreundlich und zudem bereits mehrsprachig. Wenn man eine Aussage hinzufügen will, werden einem meist passende (bzw. fehlende) Eigenschaften angezeigt, und man braucht nicht „die Nummer im Kopf haben“, sondern bekommt den Namen und die Beschreibung angezeigt.--Sinuhe20 (Diskussion) 12:38, 12. Dez. 2020 (CET)[Antworten]
Ist jetzt nicht das Thema, aber erst mal muss man wissen, dass Zusatzangaben via „Aussage hinzufügen“ eingetragen werden. Das findet man ganz ‚dezent‘ irgendwo weit unten, aber nicht mal ganz unten. So, will ich den Landkreis eintragen (P131) sollte man nicht nach Landkreis suchen, sondern „liegt in der Verwaltungseinheit“. Klar, das ist Allgemeinwissen, aber ich bin ein WP-ungebildeter Fachidiot, also bleibt mein Wissen außen vor. Aber wie gesagt, andere Thematik! --Klaus-Peter (aufunddavon) 16:20, 12. Dez. 2020 (CET)[Antworten]
Vielen Dank für die positive Rückmeldung. Ich erkenne ebenfalls erhebliches Entwicklungspotenzial in der Wikidata. Mein Wunsch hat allerdings nichts mit der Hebung dieser Potenzialle zu tun, sondern bezieht sich rein auf die Datenanzeige/Datenübernahme aus der Wikidata zur Wikipedia. Die korrekte Verknüpfung von Wikidata-Daten in die Wikipedia kann durch technisch solide Vorlagen und deren Dokumentation unterstützt werden. --WikiFreibeuter Kontakt 14:17, 14. Dez. 2020 (CET)[Antworten]

Interessant: Angenommen Wikidata würde für die Unternehmens-Infobox verwendet werden und irgendjemand läd einen großen Datensatz mit beispielsweise Umsatzdaten der an Börse XY gehandelten Unternehmen bei Wikidata hoch in der Annahme, dass das so passt und setzt bei uns automatisiert einen ganzen Stapel Unternehmensartikel auf "ungesichtet". Wer will das überprüfen und ggf. nacharbeiten? Wir haben schon nicht genug Mitarbeiter, die Artikel in diesem Bereich rudimentär qualitätssichern, geschweige denn Lust verspüren sich in das, mit Verlaub, nicht gerade selbsterklärende System Wikidata einzuarbeiten. Kurz: "Edits woanders ändern bei uns den Sichtungsstatus" halte ich für kein sinnvolles Konzept. --Millbart talk 15:04, 14. Dez. 2020 (CET)[Antworten]

Ich erkenne hier kein Gegenargument. Wenn jemand in der WP einen „großen Datensatz“ hochlädt, hätten wir doch genau das gleiche Szenario... Daten aus der Wikidata können selbstverständlich die Qualität der de-WP mindern, das genaue Gegenteil kann aber auch der Fall sein. --WikiFreibeuter Kontakt 15:14, 14. Dez. 2020 (CET)[Antworten]


Der Ansatz mit Wikidata war sicherlich gut. Es sollte und müsste ein international relevantes Gerippe sein, um dass sich die verschiedensprachigen Artikel ranken. Dort stehende Daten müssten quasi amtlich sein und bei Aktualisierung sofort in alle Versionen der Lemmas übernommen werden. Das dann jeweils dort noch mal zu überprüfen, wäre unproduktiv. Blasse Theorie, denn Wikidata ist scheinbar weniger kontrolliert, als jeder Bla-Bla-Text in de:WP. Da stimme ich @Millbart: zu, Wikidata ist nicht sehr einladend gestaltet, um sich damit zu vergnügen. Nun noch mal übernommene Daten in der Sprachversion zu sichten, wäre doppelt-gemoppelt. --Klaus-Peter (aufunddavon) 15:23, 14. Dez. 2020 (CET)[Antworten]

Solange die zu jener damaligen Zeit eingetragenen WD-Daten nicht gleichzeitig jeweils in den alten Versionen einer Historie zu finden sind, sondern nur die aktuellen, hat WD in Wikipedia nichts zu suchen. --Jbergner (Diskussion) 18:58, 25. Okt. 2021 (CEST)[Antworten]

Siehe dazu auch

--M2k~dewiki (Diskussion) 19:51, 25. Okt. 2021 (CEST)[Antworten]

Ich finde es bei weitem einfacher, die vielleicht nicht perfekten aber unterm Strich ziemlich klaren Regeln von Wikidata zu erlernen als die teils ungeschriebenen, von Auslegung abhängigen und keineswegs leicht auffindbaren Regeln für Wikipedia. Die Nutzung von Wikidata Infos bei Wikipedia wäre eine riesengroßer Gewinn. --Bärbel Miemietz (Diskussion) 20:44, 14. Nov. 2021 (CET)[Antworten]

Weblinks automatisch archivieren[Quelltext bearbeiten]

Was ist das Problem?

Weblinks kommen und gehen. Ein Phänomen, das unter den Begriffen tote Links, Totlinks, Broken Links und Linksterben zusammengefasst wird. Ursachen dafür gibt es viele: So kann eine Domain nicht mehr existieren, neu vergeben worden sein oder der Webserver nicht mehr erreichbar sein. Darüber hinaus entstehen oft tote Links, wenn der Inhalt einer Website neu organisiert oder das Content Management System gewechselt wird, wie das bei Tageszeitungen und anderen Medien immer wieder passiert.

Wen betrifft das Problem besonders?

Das Problem betrifft alle Wikipedianer, die Weblinks in Artikeln verwenden oder als Einzelnachweise nutzen. Die vielen von Bots im Artikelnamensraum gefundenen und auf den dazugehörigen Diskussionsseiten gemeldeten toten Links sprechen da eine deutliche Sprache. Trotzdem dürften sie nur einen Bruchteil der toten Links erfassen. Bisher ist es so, dass Bots, so vorhanden, auf den Diskussionsseiten auf archivierte Versionen z. B. aus dem Internet Archive hinweisen.

Lösungsvorschlag
Weblinks, die als Einzelnachweise genutzt werden, sollten künftig automatisch im Internet Archive gespeichert werden. Bisher ist es so, dass jeder, der einen Link archivieren möchte, dies händisch veranlassen kann. In der en-Wikipedia gibt es dazu eine Anleitung. Dieser Prozess müsste auch automatisiert zu erledigen sein.
Vorschlagende Person

Matthias Süßen ?! 11:12, 26. Jan. 2021 (CET)[Antworten]

Diskussion
@Matthias Süßen:, dieser Wunsch kam 2017 in die Top10 der Wünsche, wir haben daher vorletztes Jahr mit dem Team des Internet-Archivs geredet. Diese haben uns versichert, dass sie schon seit einiger Zeit die Recent Changes der Wikipedias nach neu eingetragenen URLs scannen und diese dann automatisch archivieren. Ausgenommen sind nur Webseite deren Betreiber das Archivieren untersagt haben. Insofern dürfte dieser Wunsch unseres Wissens nach bereits gelöst sein. -- Michael Schönitzer (WMDE) (Diskussion) 16:02, 1. Feb. 2021 (CET)[Antworten]
@Michael Schönitzer (WMDE): Vielen Dank für die schnelle Antwort. Das war mir bis dato nicht aufgefallen. Ich werde das jetzt mal beobachten. Vielen Dank aber schonmal für Euer Engagement (nicht nur) in Zusammenarbeit mit dem Internet-Archiv. Gruß --Matthias Süßen ?! 18:01, 1. Feb. 2021 (CET)[Antworten]
Das heißt, InternetArchive archiviert seit 2019 (fast) alle Weblinks in der WP? - Das wäre sehr begrüßenswert. Es ist wahrscheinlich nicht so zuverlässig, dass die seit 2019 gesetzten, archivierten Links nicht mehr händisch überprüft werden müssen,oder? Das ist nämlich sehr aufwändig und zeitraubend. Ich arbeite gerade die elend lange Liste an Defekte-Weblinks-Artikeln dieses WikiProjekts ab und leider sind erstaunlich viele, ca. 30 % aller defekten Weblinks, nicht archiviert. Ca. 20 % der defekten Weblinks wurden außerdem vom Bot nicht als defekt erkannt.
Finde dieses Thema jedenfalls sehr wichtig, denn zum Teil sind jetzt schon wieder in Artikeln, die ich im Januar 2021 überarbeitet habe, schon wieder Links kaputt. So schnell kann man gar nicht hinterherprüfen. Gruß --Fuchs B (Diskussion) 21:00, 31. Okt. 2021 (CET)[Antworten]
Hallo Fuchs B, das Internet Archive archiviert schon seit 2013 so gut es eben geht alle Weblinks, die in die Wikipedia eingefügt werden. Auch wenn eine Archivversion nicht sofort öffentlich verfügbar ist, liegt sie meistens schon wenige Sekunden nach Speichern der Änderung im Internet Archive ab. Eine Ausnahme scheint es für in den BNR eingefügte Links zu geben, das versuche ich gerade, in Erfahrung zu bringen. Ich schaue mir gerne mal eure Defekte-Weblink-Liste an, um herauszufinden, warum die Archivierungsquote bei euch so niedrig zu sein scheint.
Eigentlich soll der InternetArchiveBot die defekten Links erkennen und passende Archivlinks einfügen, allerdings hat dieser Bot seit Jahren technische Probleme und die teilweise vom Internet Archive dafür bezahlten Entwickler kommen nur langsam voran. (Ich würde sagen, es ist ein typischer Fall eines Tools, das von einem Ehrenamtlichen entwickelt und ihm dann zwischenzeitlich über den Kopf gewachsen ist, als es auf einmal weltweit in vielen Sprachversionen eingesetzt werden sollte.) Sobald der Bot wieder zuverlässig arbeitet, wird er seinen Betrieb wieder aufnehmen.--Cirdan ± 12:40, 1. Nov. 2021 (CET)[Antworten]



Geänderte eigenen Beiträge suchen[Quelltext bearbeiten]

Was ist das Problem?

Ich möchte eine Liste von Artikeln (nicht Versionen im Sinne von einzelnen Bearbeitungen), in denen ich mitgewirkt habe, aber die aktuellste Version nicht von mir ist. Am besten wäre dann ein Link mit dem diff von meiner letzten Bearbeitung an dem Artikel zum aktuellen Stand.

Wen betrifft das Problem besonders?

Alle Leute, die auf Wikipedia schreiben und sich über Feedback freuen. Wie wurde „mein“ Artikel (i.e. ein Artikel, in dem ich mitgewirkt habe) weiterentwickelt? Wurden vielleicht meine Bearbeitungen ergänzt oder verändert, oder gar zurückgesetzt? Wie wurde durch andere Wikipedianer der Artikel seit meiner letzten Beteiligung weiter geschrieben?

Lösungsvorschlag
Die Liste "Benutzerbeiträge" ist leider nicht geeignet, da dort alle Änderungen einzeln aufgelistet sind, und es gibt nur einen Filter für die aktuellen Beiträge, nicht das umgekehrte.
Anmerkungen

Warum die Liste "Benutzerbeiträge" nicht geeignet ist.

  • Es ist nicht übersichtlich und die Liste ist unnötig lang. Genau dafür sollte ja eine Suche da sein - als Filter.
  • Es werden mehrere Einträge angezeigt, wenn ich mehrmals einen Artikel geändert habe. Das möchte ich nicht.
Referenz: Benutzerbeiträge Frage
Vorschlagende Person

Pascamel (Diskussion) 16:07, 1. Feb. 2021 (CET)[Antworten]

Diskussion

Gibt es dafür nicht die Beobachtungsliste? --Fan-von-mir (Diskussion) 13:58, 29. Okt. 2021 (CEST)[Antworten]

Nein, das ist deutlich mehr als die Beobachtungsliste, ich habe mir sowas offline gestrickt: Ein Skript liest mein Spezial:Beiträge aus und zeigt mir die Liste nur der Beiträge, die nicht mehr aktuell sind UND die ich mir seit meiner letzten Änderung noch nicht habe anzeigen lassen. Das Ergebnis ist gleich verlinkt auf das Diff zwischen der aktuellen Version und meiner letzten Bearbeitung. Das ist ein ganz wichtiges Feedback, so erfahre ich, ob meine letzte Änderung überlebt hat. Da sich nur 4000(?) Beiträge abrufen lassen (ich rufe 1000 ab), muss ich irgendwann (nach etwa 500 Änderungen) das „Gedächtnis“ manuell aufräumen. Das ist aber immer noch besser als ohne Gedächtnis (aka Beobachtungsliste). Mit serverseitiger Unterstützung könnte das perfektioniert werden, danke Pascamel für den Vorschlag. Sprecht mich bitte an, wenn ich das näher ausführen soll. --Frühlingsmädchen (Diskussion) 12:17, 14. Nov. 2021 (CET)[Antworten]

Pro  — --Wilhelm (Diskussion) 09:04, 20. Nov. 2021 (CET)[Antworten]



Seitenvorschau beim Verlinken auf andere WP-Seiten[Quelltext bearbeiten]

Was ist das Problem?

Wenn man ein oder mehrere Worte mittels dem Link-setzen-Tool verlinken möchte, wird einem derzeit eins von drei Textkommentaren angezeigt: "Seite existiert nicht", "Seite bereits vorhanden", oder "Begriffsklärungsseite". Bei letzterem bekommt man durch Eingabe eines Leerzeichens noch ein Dropdown-Menü mit verschiedenen Möglichkeiten aus der BKS angezeigt. So weit, so gut. Trotzdem passieren immer wieder falsche Verlinkungen, zu Seiten die eine andere Person oder einen anderen Themengegenstand haben, als jenen, den man eigentlich verlinken möchte. Weil man im Tool nicht sehen kann, was auf der Seite steht, die man gerade verlinken möchte, muss man erst den Link setzen, den Knopf "Vorschau zeigen" anwenden, und dann prüfen, ob der Link tatsächlich dorthin führt, wo er hin soll.

Wen betrifft das Problem besonders?

Besonders Neulinge und etwas seltener arbeitende Wikipedianer setzen natürlich falsche Links, aber auch Erfahrene könnten fehlerfreier und vor allem schneller arbeiten, wenn sie beim Verlinken schon wüssten, wie der Inhalt der zu verlinkenden Seite aussieht.

Lösungsvorschlag
Es gibt seit ein paar Jahren die tolle Möglichkeit, sich eine Seitenvorschau von bereits verlinkten Textstellen anzeigen zu lassen, also wenn die Maus über einem Wiki-Link schwebt, bekommt man den ersten Absatz und gegebenfalls auch ein Bild aus dem Artikel angezeigt. So würde ich es mir auch für das Verlinkungstool wünschen: Dass mir eine Seitenvorschau geboten wird, bevor ich den Link setze. Vielleicht lässt sich das für das Dropdown-Menü bei mehreren Begriffen technisch nicht realisieren, aber jedenfalls der vorausgewählte Begriff im Eingabefenster, sollte eine Vorschau bieten, wenn die Maus über ihm schwebt. Dadurch würde man z.B. ganz schnell erkennen, dass zwar ein bestimmter Name bereits als Artikel existiert, es sich aber um eine andere Person handelt, als diejenige, zu der man verlinken möchte.
Vorschlagende Person

Sprachraum (Diskussion) 15:27, 3. Mär. 2021 (CET)[Antworten]

Diskussion

@Sprachraum: Der VisualEditor (und auch der darauf basierende neue Quelltext-Editor) zeigen beim Verlinken zumindest die Wikidata-Kurzbeschreibungen an. Vielleicht ist das schon ausreichend?--Cirdan ± 13:10, 25. Okt. 2021 (CEST)[Antworten]



Filter "Kurze Links" in den Letzten Änderungen in die Benutzereinstellungen[Quelltext bearbeiten]

Was ist das Problem?

Ziel ist, dass in den 'Letzten Änderungen' die Filtereinstellung 'Kurze Links' stabil bestehen bleibt.

Wen betrifft das Problem besonders?

Alle angemeldeten Benutzer

Vorschlagende Person

Betterknower (Diskussion) 19:00, 3. Apr. 2021 (CEST)[Antworten]

Diskussion



Optimierung der Vorlage Worldcat[Quelltext bearbeiten]

Was ist das Problem?

In der Vorlage Worldcat ist es --- im Gegensatz etwa zu den Vorlagen DNB oder IMDb --- nötig, bei abgeleiteten Lemmata jedes Mal die Lemmaperson unter NAME= einzusetzen, was äußerst nervig ist, wenn man diese Vorlage mehrmals täglich neu in einen Artikel einsetzt. Der Gebrauch dieser Vorlage etwa im Literaturbereich hat stark zugenommen, sodass eine Anpassung an die automatische Generierung ohne die Klammerangabe höchst wünschenswert wäre. Beispiel:

Wen betrifft das Problem besonders?

Betroffen sind potentiell alle Benutzer, die einen Personenartikel anlegen.

Lösungsvorschlag
??
Anmerkungen
- - -
Vorschlagende Person

Qaswa (Diskussion) 20:34, 5. Apr. 2021 (CEST)[Antworten]

Diskussion

@Qaswa: Dieser Änderungswunsch wäre auf Wikipedia:WikiProjekt Vorlagen/Werkstatt gut aufgehoben. Hier auf den Wunschparkplatz passt er nicht gut, weil im Projekt Technische Wünsche keine individuellen Vorlagen bearbeitet werden. Ich wünsch dir viel Erfolg, dass die Vorlagenwerkstatt dir weiterhelfen kann. -- Beste Grüße, Johanna Strodt (WMDE) (Diskussion) 16:34, 8. Apr. 2021 (CEST)[Antworten]



definierte Bezeichnungen vor automatischem Zeilenumbruch schützen[Quelltext bearbeiten]

  • Schaffung einer Mediawiki-Funktion, die die Definition von zusammengehörigen Zeichen (Bezeichnungen) festlegen kann, mit dem Ziel, automatische Zeilenumbrüche zu unterbinden.
Was ist das Problem?

Es gibt Bezeichnungen, die freistehende Zeichen beihalten und daher als gesonderte Zeichen automatisch in die nächste Zeile rutschen können. Beispielsweise „z. B.“, was derzeit durch manuelles Setzen eines geschützten Leerzeichens unterbunden wird. Andere Beispiele sind Eigennamen wie das X Window System, Mutant X oder OS X, aber auch bei Namen mit zwei freistehenden Zeichen wie Windows NT oder Windows 9x.

  • Was ich möchte: Um nicht jedes einzelne Mal dieselbe Bezeichnung wieder und wieder mit einem geschützten Leerzeichen (oder der Vorlage:Nowarp, oder einem geschützten Bindestrich) vor einem ungewollten Zeilenumbruch schützen zu müssen, wünsche ich mir eine Möglichkeit, pro Artikel Bezeichnungen zu definieren, die im gesamten Artikel wie eine Einheit behandelt und daher nicht umgebrochen werden. Die Wikimedia-Software würde dann automatisch für jedes Vorkommen der definierten Zeichenkette die darin enthaltenen Leerräume und Bindestriche durch deren geschützten Varianten ersetzen.
  • Welche Schritte sind derzeit notwendig: Jedes Vorkommen der Bezeichnung, etwa „Mutant X“, muss (bzw. müsste) derzeit manuell mit einem geschützten Leerzeichen zusammengehalten werden. Mit einer solchen Funktion wäre nur noch ein einziger Schritt notwendig: Ähnlich der Funktion DISPLAYTITLE würde man per Funktion die Zeichenkette „Mutant X“ als zusammenhängend definieren, woraufhin der Umbruch im gesamten Artikel verhindert würde.
  • Die Probleme, die im Moment (durch das Fehlen einer solchen Funktion) auftreten, sind, dass manche Autoren darauf keine Acht geben (oder im Visuellen Editor die geschützten Leerzeichen nicht erkennen) und sich so im selben Artikel bei fortschreitender Bearbeitung immer wieder unerwünschte Umbrüche ergeben, bzw. Autoren, denen der Lesefluss wichtig ist, ständig nacharbeiten müssen. Ein zusätzliches Problem sind Meinungsstreitigkeiten, wo und wann ein geschütztes Leerzeichen wirklich nötig ist, weil es ja gleichzeitig die Lesbarkeit des Quelltextes erschwert. Das ist Ansichtssache und förtert derlei Meinungsstreitigkeiten sogar noch, die sich negativ auf die Produktivität auswirken können.
Wen betrifft das Problem besonders?

Alle, die sich um Umbrüche Gedanken machen, sind betroffen: also jeder, der weiß, was   ist...

Lösungsvorschlag

Eine Wikimedia-Funktion, die die Definition von zusammenhängenden Worten erlaubt, ähnlich wie es im Textsatzsystem TeX mit dem Kommando \hyphenation möglich ist, Umbrüche für einzelne Worte zu verhinden. Als Beispiel könnte dies so aussehen:

{{nowrap:Mutant X}}
würde im gesamten Artikel – Nachtrag: bei der Ausgabe (und daher nicht im Quelltext) – jedes Mutant X per Software automatisch in Mutant X umwandeln, und jedes Mutant-X in Mutant‑X (für Durchkopplungen).
Anmerkungen
Zusätzlich würde eine solche Funktion globale Ersetzungen erlauben, beispielsweise „z. B.“ in „z. B.“ usw... Eine ähnliche Funktion bzw. eine Erweiterung könnte auch erlauben, Falschschreibungen wie „z.B.“ (ohne Leerzeichen) bei der Anzeige automatisch in „z. B.“ zu ändern.
Vorschlagende Person

Andreas 11:29, 29. Apr. 2021 (CEST)[Antworten]

Diskussion

Also wenn soll die Software bitte nicht selbst das geschützte in den Quelltext setzen, sondern der Quelltext soll ohne diese Sonderzeichen auskommen, vielmehr soll wie beim % auch jetzt schon die Anzeige entsprechend angepasst werden, so dass letztendlich nur die Ausgabe betroffen ist (so wie aus dem Wiki-Quelltext [[Hier|dort]] der Quelltext der Internetseite generiert wird: <a href="/wiki/Hier" title="dort">. Godihrdt (Diskussion) 11:46, 29. Apr. 2021 (CEST)[Antworten]

Ja, so war es aber auch gemeint. Im Quelltext steht oben das zusammengesetzte Wort ("Mutant X"), das keinen Umbruch haben soll, und bei der Ausgabe wird es dann ersetzt. Im Quelltext selbst entfällt dann die Notwendigkeit, ein geschütztes Zeichen manuell einzusetzen. So wie beim %-Zeichen. ‣Andreas 12:34, 29. Apr. 2021 (CEST)[Antworten]


Warum eigentlich pro Artikel? Wie wäre es mit einer Mediawiki-Systemseite? Sie könnte pro Zeile ein Pärchen beinhalten und der Parser muss nur Suchen und Ersetzen: z.B.|z. B.. Alternativ wäre der Ansatz, dies vom Quelltext/Markup zu entkoppeln. Ein Gadget könnte solchen Text doch auch live im Browser typografisch korrigieren. -- DerFussi 14:09, 27. Okt. 2021 (CEST)[Antworten]
Wichtig wäre aus meiner Sicht auch soviel Wiki-Markup wie möglich aus Artikeln herauszuhalten - für die Nicht-Nerds. -- DerFussi 09:36, 2. Nov. 2021 (CET)[Antworten]

Intelligenter Textsatz (automatischer Zeilenumbruch)[Quelltext bearbeiten]

  • Schaffung eines intelligenten Textsatzsystems u. a. beim automatischen Zeilenumbruch
Was ist das Problem?
  • Zu viel, was in einer Textverarbeitung oder in einem Textsatzsystem automatisch geschieht, muss in der Wikipedia manuell und händisch erledigt werden.
  • Jeder Autor macht bei seinen Edits Stilentscheidungen beim Textsatz, die mit anderen Autoren bzw. anderen Artikeln in der Konvention brechen, sodass viele Artikel unterschiedlich aussehen. Ein automatisches System könnte dies teilweise beheben.
  • Beispiele für Systeme, die des semi-automatisch erledigen: TeX
Wen betrifft das Problem besonders?

Alle, die sich über Typografie, Layout, Textsatz und üblichen Konventionen Gedanken machen und denen das daher auch in der Wikipedia wichtig ist, da es nicht selten die Lesbarkeit unserer Artikel fördert.

Lösungsvorschlag
Sprachspezifischer von TeX inspirierter (oder daraus übernommener) intelligenter automatischer Textsatz. Eine Implementierung könnte sich stufenweise voranarbeiten, beginnend bei automatischen Umbrüchen bzw. Verhinderung derselben an Stellen, wo dies nicht passieren sollte (bei „z. B.“, „u. a.“ usw...). Ebenso die automatische Nutzung von typgrafischen Anführungszeichen. Es muss dabei die Möglichkeit bestehen, dieses Verhalten zu beeinflussen/abzuschalten (analog zu HTML-<pre>).
Anmerkungen

Intelligenter Textsatz erkennt, wann ein automatischer Zeilenumbruch gut ist und wann nicht. Umbrüche nach einem Viertelgeviertstrich sind zwar sehr oft richtig, aber nicht immer, beispielsweise bei Wortergänzungen. Beispiele (von Viertelgeviertstrich#Ergänzungsstrich): Verkehrslenkung und ‑überwachung oder Laserstrahlschmelz-, ‑brenn- und ‑sublimierschneiden. Die Wikimedia-Software macht dies derzeit noch zu oft falsch. Es gibt aber auch noch weitere Beispiele, wo eine intelligente Software den Autoren viel Arbeit (und Streit) abnehmen würde...

Ein derartiges Textsatzsystem könnte nicht nur Zeilenumbrüche intelligenter steuern, sondern auch automatische Zeichenersetzung:

Und es würde eine rein manuelle Implementierung großteils ersetzen (aber nicht unnötig machen):

Ein weiters Beispiel ist die Nutzung von Schrägstrichen im Deutschen. Zwischen WortEins/WortZwei macht die Software keinen automatischen Zeilenumbruch, obwohl nach dem Schrägstrich einer zugelassen werden sollte: WortEins/WortZwei. Gerade bei langen Worten, die mit Schrägstrich gleichwertig nebeneinander stehen (Bedeutungseinheit), sieht der automatische Zeilenwechsel sonst oft sehr unprofessionell aus. Die Schreibweise mit Leerzeichen (wenn es keine Bedeutungseinheit gibt) hat ebenfalls das Problem, dass es damit möglich wird, dass der Schrägstrich selbst bereits in der nächsten Zeile steht. "WortEins/ WortZwei" ist keine im Deutschen typografisch korrekte Form, sie ist rein der (derzeit) schlechten Automatik geschuldet.
Vorschlagende Person

Andreas 11:29, 29. Apr. 2021 (CEST)[Antworten]

Diskussion

Zeilenumbrüche regelt nicht MediaWiki, sondern der Browser. Wenn das gewünscht ist, könnte das per CSS aktiviert werden bzw. kannst du es dir in deine common.css eintragen: ausführliche Erläuterung. Das scheint mir im Internet aber recht ungewöhnlich zu sein, weil es – wie du schon andeutest – recht komplex ist, einen Text passend zu setzen. Bei TeX funktioniert das, weil die Zeilenlänge und Laufweite der Schrift fest definiert ist (und selbst da muss man manchmal per Hand nachhelfen und problematische Zeilen und Wörter zurechtrücken). Bei einer Website wie Wikipedia weiß niemand, wie viel Platz und welche Schriftarten zur Verfügung stehen.--Cirdan ± 20:20, 2. Nov. 2021 (CET)[Antworten]



Bitte eine Benutzeroberfläche mit Darkmode-CSS hinzufügen.[Quelltext bearbeiten]

Was ist das Problem?

Bei einem Rechner, der überwiegend mit Programmen in einem Darkmode betrieben wird, wird man bei Aufruf der Wikipedia durch die Helligkeit geblendet. Ein Darkmode in Wikipedia würde das Arbeiten am Bildschirm angenehmer machen und bei Mobilgeräten mit OLED-Displays auch die Batterie schonen. Das oft empfohlene Herunterregeln der Helligkeit ist keine Lösung, da beim Hin- und Herschalten zwischen den Programmen nicht jedes mal die Helligkeit nachgeregelt werden kann.

Sicherlich ist das Augenschonende eines Darkmodes noch umstritten, aber das grelle Aufblitzen des Bildschirmes bei Aufruf von Wikipedia stört eben doch. Da wäre es eine gute Möglichkeit, bei den Einstellungen statt Vector oder Monobook auch einen Darkmode einstellen zu können.

Wen betrifft das Problem besonders?

Alle Nutzer, besonders die mit Mobilgeräten mit OLED-Display.

Lösungsvorschlag
Bei den Einstellungen ein CSS mit Darkmode hinzufügen.
Vorschlagende Person

c.w. @… 08:55, 30. Apr. 2021 (CEST)[Antworten]

Diskussion
Ja, nun: nachdem das hier mehr als 2 Monate unbeachtet blieb und eine professionelle Lösung nicht in Aussicht ist, habe ich eine private, nicht-professionelle Lösung erarbeitet: Benutzer:Charly_Whisky/common.css
…nicht vollkommen und mit heißer Nadel gestrickt, aber für meine Augen ausreichend. (Und wenn mir noch irgendeine farbliche Dissonanz auffällt, wird sie dort ergänzt.)
Von dem Team „Technische Wünsche“ bin ich stark enttäuscht: sie reagieren zwar wenn man ihnen auf die Füße tritt (was die hiesige Disk zeigt), aber besonders hilfreich ist das nicht.--≡c.w. @… 07:36, 10. Jul. 2021 (CEST)[Antworten]
Das ganze CSS des Wikis ist auch sehr unsauber und völlig chaotisch programmiert. Es gibt ungewöhnlich viele Objekte, die schon vom PHP her eine direkte Style-Zuweisung machen (also ohne Klassen oder ID-Namen) und die man dann gar nicht über eine individuelle Farbgebung beeinflussen kann. Dazu kommen noch die Style-Angaben direkt in den Vorlagen, die keinerlei Rücksicht auf mögliche andere Farbvarianten nehmen. --≡c.w. @… 21:31, 10. Jul. 2021 (CEST)[Antworten]
Hallo c.w., ich kann verstehen, dass das enttäuschend ist. Es gibt einfach so viele Dinge, die man an der Software hinter Wikipedia verbessern könnte, aber leider ist es nicht möglich, sie alle anzugehen. Hinter jedem Wunsch stecken mehrere Monate Recherchearbeit, um beispielsweise zu verhindern, dass Änderungen, die für eine Person hilfreich sind, die Arbeitsabläufe von anderen Personen behindern. Auch die Umsetzung von Funktionen in MediaWiki (und auf MediaWiki konzentrieren wir uns ja) ist selbst bei vermeintlich kleineren Änderungen immer zeitaufwändig; u.a. muss in der Regel alter Code erstmal aufgeräumt werden, bevor man neue Funktionen ergänzen kann, aber auch die Vielzahl von Nutzerscripten, Helferlein, Skins usw. verlangsamen die Arbeit. Auf dem Wunschparkplatz befinden sich gerade 88 Wünsche. Wenn jeder Wunsch innerhalb von drei Monaten lösbar wäre (was bereits superoptimistisch geschätzt ist), wäre das Projektteam damit schon 264 Monate beschäftigt.
Darum lässt das Projekt Technische Wünsche die gesammelten Probleme durch die Mitglieder der deutschsprachigen Community priorisieren und es wird dann das umgesetzt, das den meisten Leuten wichtig ist. Um diese Priorisierung ging es schon in der ersten Umfrage 2013 und geht es weiterhin. Ich hoffe, ich konnte ein bisschen Klarheit schaffen, warum das hier nur ein Parkplatz sein kann, und es nicht möglich ist, sich all die Wünsche hier im Einzelnen anzusehen, geschweige denn Lösungen dafür zu entwickeln. -- Viele Grüße, Johanna Strodt (WMDE) (Diskussion) 10:57, 12. Jul. 2021 (CEST)[Antworten]
Es gibt bereits die DarkMode Erweiterung für MediaWiki, welche seit einiger Zeit von einigen Freiwilligen entwickelt wird. Ich habe sie mal lokal getestet und sie scheint recht gut zu funktionieren. Allerdings ist es wie immer eine große Qual eine neue Erweiterung auf die WikiMedia Server zu bekommen, siehe den vollen Prozess: mw:Writing an extension for deployment. --Zabe (Diskussion) 16:14, 25. Okt. 2021 (CEST)[Antworten]
Ich bin gerade dabei, aufbauend auf dem CSS von @Charly Whisky: mir ein eigenes Set zusammenzubauen: meta:User:DerFussi/global.css. Dabei sind mir ein paar Dinge aufgefallen die vielleicht mal vorbereitend getan und gewünscht werden sollten
  • Ich habe hier auf der WP Infoboxen, die ich nicht umgefärbt bekomme. Ich denke vorher sollten alle Vorlagen auf der Wikipedia daraufhin überprüft und gefixt werden, die die Farbanweisungen hart im Tag vercodet haben und alle Styles in Klassen ausgelagert werden. Ich habe das auf Wikivoyage früher schon mal begonnen (wir haben ja nicht so viele wie ihr) und gerne ein Präfix davorgesetzt wie "wv" für Wikivoyage oder besser noch mit Sprachcode, sowas wie: "WVde-foo-bar". Dann kann man den Darkmode auch ordentlich parametrieren.
  • Einige Symbole in den Wikis wie z. B. die Edit-Buttons auf Wikidata sind als Hintergrundbild eingebunden. Wäre es SVG direkt innerhalb des HTML könnte man die Bildchen auch einfach per CSS einfärben, mit Hover-Effekten versehen usw. Vielleicht sollte man als ersten Schritt mal von den Technikern das geparste HTML daraufhin optimieren lassen, dass man sämtliche Designelemente einfach und bei Basiselementen der Wikisoftware gleichzeitig für alle Wikis beeinflussen kann. -- DerFussi 12:06, 3. Nov. 2021 (CET)[Antworten]
  • Pro Darkmode auf Handy und PC wäre schön. --Fuchs B (Diskussion) 21:11, 31. Okt. 2021 (CET)[Antworten]
  • Pro Bin auch dafür -- DerFussi 12:06, 3. Nov. 2021 (CET)[Antworten]
  • Pro Klar doch, nur schade, dass in der Vorlagenwerkstatt die Meinung vorherrscht, ein Dark-mode sei Quatsch und würde (der Vorlagenwerkstatt!) viel zu viel Arbeit machen. (Da gab es schon eine sehr negative Diskussion darüber.) Und deswegen werden auch bei neuen Vorlagen demonstrativ direkte Farbzuweisungen eingesetzt, die durch derart CSS-Dateien nicht geändert werden können. --≡c.w. @… 08:58, 5. Nov. 2021 (CET)[Antworten]
  • Pro greetz vanGore 13:52, 5. Nov. 2021 (CET)[Antworten]
  • Pro Dark Mode ist ein absolut essenzielles Basis-Feature im Kontext des Jahres 2021. Der aktuelle Zustand wirkt auf mich schlicht vorsteinzeitlich. --BourgetJuin (Diskussion) 09:05, 6. Nov. 2021 (CET)[Antworten]

Pro — --Gnom (Diskussion) Wikipedia grün machen! 20:20, 15. Nov. 2021 (CET)[Antworten]



Auflösen von <ref> bei <onlyinclude> [Quelltext bearbeiten]

Was ist das Problem?

Besonders bei Künstlern ist es beliebt die Diskographie in eine eigene Seite auszulagern. Dann werden oft Teile dieser Seite z.B. Liste mit Titel mit Hilfe von <onlyinclude> wieder in den Originalartikel importiert. Wird nun im <onlyinclude> ein <ref name="" /> verwendet kann dieser nicht in der Originalseite nicht aufgelöst werden und führt zu einem Fehler, der nicht ohne weiteres zu finden ist, da eine einfache Suche nichts findet.

Wen betrifft das Problem besonders?

im Prinzip alle Autoren

Lösungsvorschlag

1. Beim Parsen von onlyinclude immer die Referenzen der Originalseite mitnehmen (Cache)
2. Als Minimum eine Fehlermeldung ausgeben, mit dem Hinweis das die Referenz vermutlich auf der Seite include liegt.

3. Bei onlyinclude einen Fehler ausgeben, dass eine Referenz nicht exportiert wird (kann zu Missverständnissen führen)
Anmerkungen
Ich denke das ein großen Problem darin liegt, das mit dem jetzigen Verfahren eine Fehlermeldung ausgegeben wird, die einfach nur verwirrt, da diese Referenz auf der Seite nicht existiert. Das passiert bei (fehlerhafter) Verwendung von ref auch in anderen Umständen. Mit Erfahrung ist das Problem lösbar, führt aber dann unter Umständen dazu, dass auf der Original-Seite und der Include-Seite die gleiche Referenz eingetragen wird und im verlauf der Zeit sich aber an einem Ort verändert oder beim Inlcude gleich (versehentlich) auf die falsche Ref zeigt. Eine echte Gefahr bei Namen wie ":0" etc.
Vorschlagende Person

A1000 (Diskussion) 10:45, 3. Jun. 2021 (CEST)[Antworten]

Diskussion



Automatisch nachgefuehrte Links auf Abschnitte von Diskussionsseiten mit Archiv[Quelltext bearbeiten]

Was ist das Problem?

Setzt man einen Link auf eine Diskussion in einer archivierten Diskussionsseite, verwandelt sich dieser Link eine Woche nach Ende der Diskussion in einen toten Link, weil der betreffende Abschnitt auf die Archivseite verschoben wird, die darauf zeigenden Links beim Archivieren aber nicht mitgenommen werden.

Besonders bedeutsam ist das bei Links, die man gar nicht nachtraeglich anpassen kann, naemlich Links in der Zusammenfassungszeile von Artikelaenderungen, die ja auf eine der Aenderung zugrunde liegende Diskussion verweisen sollen. Ein Beispiel dafuer ist der Link in der Zusammenfassungszeile dieser Aenderung (von mir selbst).

Wen betrifft das Problem besonders?

Bearbeiter der Wikipedia, die an Diskussionen teilnehmen und diese an anderer Stelle verlinken wollen.

Lösungsvorschlag

Ich habe den Eindruck, dass sich das nicht einfach mit einer Vorlage erledigen laesst, die dynamisch ermittelt, ob der Abschnitt schon verschoben wurde oder noch nicht, und dann den richtigen Link generiert, sondern dass fuer die Loesung dieses Problems weitergehende technische Unterstuetzung erforderlich ist.

Konkreter Vorschlag wird gesucht.
Vorschlagende Person

Juergen 217.61.204.70 00:36, 9. Jun. 2021 (CEST)[Antworten]

Diskussion



Tabelle mit sortierbaren Spalten: Möglichkeit, eine statische (nummerierende) Randspalte zu erstellen, um den Rang ablesen zu können.[Quelltext bearbeiten]

Was ist das Problem?

Beispiel: Liste der Länder nach Gefängnisinsassen: Eine Liste, in denen die eingetragenen Länder in den sortierbaren Spalten (Gesamtzahl der Gefangenen; Anzahl der Gefangenen pro 100 Einwohner, Frauen- und Ausländeranteil) unterschiedliche Ränge einnehmen. Es ist nicht möglich, links eine statische Randspalte zu erstellen, an der man den Rang betreffend der ausgewählten Sortierspalte ablesen kann. Stattdessen wären dort in Kleinarbeit (wie für vorgenannte Liste bereits erfolgt für Gesamtzahl der Gefangenen und Anzahl der Gefangenen pro 100 Einwohner) jeweils für die Kategorie zusätzlich eine entsprechende Spalte für die dementsprechende Rangliste zu erstellen. Das bedeutet einmal erheblichen Arbeitsaufwand zur Erstellung und erst Recht bei Aktualisierung längerer Ranglisten. Zudem ist es ziemlich "unschön", mehrere Spalten für den entsprechenden Rang einer Sortieroption vorzusehen. Wie es im Optimalfall aussehen könnte, sieht man in der englischen Version des Artikels, siehe [1].

Wen betrifft das Problem besonders?

Leser und Bearbeiter längerer Ranglisten mit unterschiedlichen Sortieroptionen, es existiert eine Vielzahl von Listen mit diesem Defizit, wahllos fünf Beispiele nur aus der Kategorie Liste (Staaten): Liste der Länder nach Zigarettenkonsum (Rangliste betreffend Geschlechteranteil nicht ablesbar);Liste der Staaten mit dem höchsten Energieverbrauch (Rang nur für das Jahr 2016 ablesbar);Rangliste der Pressefreiheit (Rangliste ohne ablesbaren Rang);Liste der Länder nach Staatshaushalt (Rang betreffened BIP nicht ablesbar); Liste von Ländern nach durchschnittlicher Lebenserwartung (Rangliste nur für ein Jahr ablesbar, Rang zudem betreffend Geschlechteranteil nicht ablesbar)

Anmerkungen
Hilfe:Tabellen/Sortierung#Rangliste aktualisieren
Vorschlagende Person

Quintil Jan Verus (Diskussion) 10:57, 10. Jun. 2021 (CEST)--[Antworten]

Diskussion



Letzte eigene Bearbeitungen, die nicht aktuell sind, besser erkennen können[Quelltext bearbeiten]

Was ist das Problem?

Ich will nachschauen können, wenn auf einer von mir editierten Seite nach meinem letzten Edit jemand anders etwas geändert hat.

Nachschauen auf der Seite der eigenen Beiträge (bei angemeldeten Benutzern auf der Seite ganz oben rechts; 2. Wort/Link von rechts, links von Abmelden) ist äußerst unübersichtlich, wenn es darum geht, jene Beiträge aufzulisten, die nicht mehr aktuell sind UND bei denen ich nicht selbst der letzte Editor war. Dies gilt für Artikel genauso wie für Diskussionen.

Beispiel: ich editiere irgendwo; solange niemand anders dort editiert, erscheint auf meiner Liste ein (aktuell) hinter dem Edit. Hat später jemand dort editiert, verschwindet die Klammer mit "(aktuell)". Ich editiere nicht nur einmal, sondern z.B. in einer Diskussion innert Wochenfrist mehrmals. Damit entstehen in meiner Liste mehrere Einträge mit einem Link zu jener Diskussion, wovon hinter dem letzten ein (aktuell) steht, solange niemand anders etwas geändert hat. D.h.: die derzeitige Hervorhebung besteht dann, wenn ich der letzte Editor war.

Viel interessanter sind jedoch jene Artikel/Diskussionen, bei denen nach mir sonstwer etwas editiert hatte. Bei mir erscheinen alle Einträge der genannten Seite ohne aktuell-Klammer. Insbesondere bei Vorhandensein mehrere Einträge kann ich aber nur schwer erkennen, welches nun der letzte dieser Einträge war, da die Einträge auf meiner Seite mehrfach erscheinen – und alle ohne Hervorhebung.

Ziel ist es, sämtliche Artikel/Diskussionen besser erkennen zu können (in welcher Art auch immer), die ich editiert hatte, bei denen ich aber nicht der letzte Editor war – und zwar pro Artikel/Diskussion nur mit einer einzigen Erwähnung (nämlich der allerletzten – sprich: mein allerletzter Edit).

Fazit: die Liste der eigenen Beiträge müßte so gefiltert werden können, daß eine editierte Seite nur ein einziges mal aufgeführt wird – nämlich nur der letzte von mir getätigte Edit auf jeder Seite. Frühere nicht mehr aktuelle Edits müßten weggefiltert werden können.

D.h. die Filtermöglichkeit müßte ergänzt werden mit sowas wie "editierte Seiten nur 1x aufführen" resp. "nur letzten Edit einer Seite aufführen". Dann wird es übersichtlicher, zu erkennen, wenn eine Seite nach meinem Edit wieder geändert worden ist (die hat dann keine "(aktuell)"-Klammer.

Wen betrifft das Problem besonders?

Sämtliche angemeldeten Benutzer

Lösungsvorschlag
Filter ergänzen mit "nur letzten Edit einer Seite anzeigen" oder (o.ä.)
Anmerkungen

Dieser Filter auf nur die letzten Edits jeder Seite soll zusätzlich zur jetzigen Anzeige sämtlicher Edits bestehen.

Eine andere (ohne zusätzlichen Filter) ev. einfach(er) umsetzbare Variante wäre, daß bei sämtlichen Edits jeweils die letzte Erwähnung jeder Seite erkennbar andersfarbig unterlegt würde. Das Auge müßte sich dann nur auf diese Hinterlegungsfarbe konzentrieren und könnte so besser erkennen, ob nun ein "(aktuell)" dasteht oder nicht. Eine Variante wäre, daß dieses anderfarbige Hinterlegungsfarbe in den eigenen Einstellugnen ein-/ausgeschaltet werden müßte (und nicht automatischaktiv wäre).
Vorschlagende Person

ProloSozz (Diskussion) 11:03, 7. Jul. 2021 (CEST)[Antworten]

Diskussion



In Beobachtungsliste gleichzeitiges Öffnen aller Änderungen ermöglichen[Quelltext bearbeiten]

Was ist das Problem?

Wer viele Seiten beobachtet und sich die Änderungen auch im Detail anschauen möchte, muss derzeit jede Seite einzeln öffnen. Das ist ein unnötiger Aufwand, der vermutlich relativ einfach minimiert werden könnte.

Wen betrifft das Problem besonders?

Alle Nutzer der Beobachtungsliste, speziell die mit vielen beobachteten Seiten.

Lösungsvorschlag
Anbieten zusätzlicher Links auf der Beobachtungsseite, die dafür sorgen, dass die Mindestangebote "Alle Seiten mit ungesehenen Änderungen öffnen" sowie "Alle Seiten mit ungesehenen Änderungen unter Anzeige der Versionsunterschiede öffnen" mit einem Mausklick ausgewählt werden können. Ich persönlich hätte das gerne als neue Tabs, andere vielleicht lieber als neues Fenster. Deshalb und weil es bestimmt noch andere Nutzungsvorlieben für die Beobachtungsliste gibt, sollte man je nach Diskussionsverlauf vielleicht eine benutzerspezifische Einstellung ermöglichen.
Vorschlagende Person

Lguenth1 (Diskussion) 18:32, 7. Jul. 2021 (CEST)[Antworten]

Diskussion

sehr gute Idee! --Fan-von-mir (Diskussion) 14:16, 29. Okt. 2021 (CEST)[Antworten]



Bildbetrachter sollte in Bildlegende enthaltenes TeX darstellen können[Quelltext bearbeiten]

Was ist das Problem?

Wenn man in einem Wikipedia-Artikel auf ein dort eingebundenes Bild klickt, wird es bekanntlich im Bildbetrachter geöffnet und (oft vergrößert) dargestellt. Die Bildlegende wird dabei aus dem Artikel übernommen und im Bildbetrachter unten angezeigt. In der Bildlegende enthaltenes TeX geht im Bildbetrachter allerdings fehlerhafterweise verloren – anstelle der TeX-Inhalte wird hier nichts ausgegeben. Das kann im Bildbetrachter zu verstümmelt dargestellten Bildlegenden führen. (In den Artikeln werden TeX-Inhalte in Bildlegenden hingegen problemlos dargestellt.)

Daher mein Anliegen: Auch der Bildbetrachter sollte in der Bildlegende enthaltenes TeX darstellen können.

Beispiele:

  1. Beispiel 1
  2. Beispiel 2
  3. Beispiel 3
Wen betrifft das Problem besonders?

Alle NutzerInnen, die in Artikeln auf Bilder klicken, deren Bildlegende TeX enthält

Vorschlagende Person

SweetWood (Diskussion) 19:54, 8. Jul. 2021 (CEST)[Antworten]

Diskussion



Bilder-Vorschau in Commons Unterkategorien[Quelltext bearbeiten]

Was ist das Problem?

Man möchte ein Foto in eine Kategorie einsortieren weiß aber nicht ob/welche Unterkategorie eventuell passt. Ich habe z.B. eine Skulptur fotografiert, bei der Titel und Künstler nicht angegeben sind, und schaue dann z.B. in c:Category:Sculptures in Hannover - da sind aber 196 Unterkategorien, wohin gehört nun mein Foto? Wäre schön wenn man hier eine Vorausschau einiger Bilder aller direkten Unterkategorien aktivieren könnte (je drei? fünf? je nach Bildschirmbreite?) (ggfs. Gesamtzahl limitiert falls Performanceprobleme). Ähnliche Anwendung: man sucht ein bestimmtes Gebäude kennt aber den Namen der Unterkategorie nicht.

Wen betrifft das Problem besonders?

Commons-Nutzer

Lösungsvorschlag
Entweder ein Button, oder z.B. in der Reiterleiste unter "Weitere" einen Punkt "Vorschau bei Unterkategorien"
Vorschlagende Person

Gerd Fahrenhorst (Diskussion) 13:48, 12. Jul. 2021 (CEST)[Antworten]

Diskussion
  • Pro --Fuchs B (Diskussion) 21:17, 31. Okt. 2021 (CET)[Antworten]
  • Pro Das wär toll. Arbeite im Moment immer mit unterschiedlichen Fenstern, in dem einen suche ich nach passenden Kategorien, in das andere füge ich sie ein. Echt umständlich. --Grizma (Diskussion) 10:16, 1. Nov. 2021 (CET)[Antworten]
  • Pro - --Bärbel Miemietz (Diskussion) 20:53, 14. Nov. 2021 (CET) Super Idee! Mit dem Problem schlage ich mich auch ständig rum.[Antworten]



In der Vorlagenprogrammierung die Funktion Schleife ermöglichen[Quelltext bearbeiten]

Was ist das Problem?

Ich möchte z. B. in Vorlagen identische Programmteile

  1. jeweils für alle Monate eines Jahres aufrufen und diese nicht 12 Mal mit identischem Code einprogrammieren.
  2. von einem Ausgangsjahr bis zum aktuellen Jahr das Ergebnis generieren ohne jährlich die Vorlage für das aktuelle Jahr zu erweitern.
Wen betrifft das Problem besonders?

Vorlagenprogrammierer

Lösungsvorschlag
Diese Erweiterung in der deutschen Wikipedia installieren.
Anmerkungen

Es geht um solche und ähnliche Konstruktionen:

  1. {{ #loop: monat | 1 | 12 | <!-- Hier ein Anweisungsblock, in welchem {#var: monat}} benutzt wird --> }}
  2. {{ #loop: jahr | 2010 | {{#expr: 1+{{JETZIGES_JAHR}}-2010}} | <!-- Hier ein Anweisungsblock, in welchem {#var: jahr}} benutzt wird --> }}
    Vorschlagende Person

Former111 (Diskussion) 16:37, 21. Okt. 2021 (CEST)[Antworten]

Diskussion

@Former111: Könntest du hierfür nicht Lua einsetzen? Das ist mutmaßlich auch deutlich performanter als die Loops-Extension. Vielleicht kann Benutzer:MGChecker als Maintainer dazu eine Einschätzung abgeben?--Cirdan ± 13:05, 25. Okt. 2021 (CEST)[Antworten]

Das sehe ich ganz genau so. Loops ist für größere Wikis wie die Wikipedia durch Scribunto effektiv obsolet, und ich kann mir nicht vorstellen dass die WMF eine Installation zulassen würde. Darüber hinaus kann Loops seine Vorzüge so wirklich nur im Zusammenhang mit Variables ausspielen, die gemäß der Parsoid-Pläne ganz gewiss nicht von der WMF installiert werden werden. (nicht signierter Beitrag von MGChecker (Diskussion | Beiträge) 14:16, 25. Oktober 2021 (CEST))
@MGChecker: Danke für deine kompetente Einschätzung!--Cirdan ± 16:08, 25. Okt. 2021 (CEST)[Antworten]
BK: : @Cirdan: Nach meiner Erkenntnis muss dann die gesamte Vorlage mit LUA programmiert werden, da die Laufvariable nicht in die Schleife der "normalen" Programmierung übergeben wird. Mir wurde von Benutzer PerfektesChaos mitgeteilt, dass gesamte Vorlagen mit LUA zu programmieren nicht gewünscht ist. Ich habe das so verstanden, dass nur noch universell einsetzbare Module in LUA erstellt werden sollen. Auch möchte ich aufgrund meines Alters nicht die Programmsprache LUA erlernen, dafür gibt es sicher Spezialisten. --Former111 (Diskussion) 14:27, 25. Okt. 2021 (CEST)[Antworten]
@Former111: Du könntest aber doch ein Schleifen-Modul in Lua bauen? Dann übergibst du aus einer "klassischen" Vorlage die Liste, über die iteriert werden soll, an das Lua-Modul. Wenn du programmieren kannst, sollte Lua kein Problem für dich darstellen, ich habe selbst auch ohne Lua-Erfahrung vor einigen Jahren ein Modul geschrieben und fand das wesentlich angenehmer als das übliche Vorlagen-Gebastel.--Cirdan ± 16:08, 25. Okt. 2021 (CEST)[Antworten]
Ich habe das Programmieren und Kodieren Anfang der 1960er Jahre gelernt und wir haben die Maschinenbefehle noch als Binärkode kodiert. Die späteren Assembler waren eine enorme Erleichterung, da wir dann symbolische Anweisungen verwenden konnten. Mittels "If, Then, Goto ..." usw. wurden vorher im Groben die Programmablaufpläne dargestellt um eine Codierung danach zu ermöglichten. Deshalb fiel mir das "übliche Vorlagen-Gebastel" relativ leicht.
Könntest du einem solchen universellen Lua-Modul erstellen? --Former111 (Diskussion) 16:28, 25. Okt. 2021 (CEST)[Antworten]
Ich habe leider keine Zeit dazu bzw. derzeit andere Interessen in der Wikipedia, als Entwicklung von Vorlagen. Gerade mit deinem Grundlagenwissen sollte dir Lua allerdings sehr leichtfallen. Hast du dir "mein" Modul einmal näher angeschaut? Das ist genau solch ein sehr strukturierter Ablauf, wie du ihn beschreibst. Sei mutig!--Cirdan ± 16:51, 25. Okt. 2021 (CEST)[Antworten]
Habe mir deinen Modul angesehen. Es ist doch was ganz anderes als ein "linearer" PAP. Mein Einarbeiten in diese Hochsprache würde zu Fehlern und Problemen führen. Entsprechend "Schuster bleib bei deinen Leisten" sollen das besser jüngere LUA-Codierer machen. --Former111 (Diskussion) 11:25, 26. Okt. 2021 (CEST)[Antworten]
@Former111: Schade, ich hatte den Eindruck bzw. die Hoffnung, dass wenigstens durch die Kommentare im Code sehr deutlich wird, was in jedem Schritt passiert.--Cirdan ± 18:12, 26. Okt. 2021 (CEST)[Antworten]
@Cirdan: Dein Quellcode ist vorbildlich kommentiert. Voraussetzung das Verständnis des Codes ist aber wie immer bei IT, dass man die Syntax der Sprache des Assemblers, Compilers oder Interpreters beherrscht. Ich kann vieles vermuten, z. B., dass mw.ustring.rep der Aufruf eines Systemroutine wäre.
Ich habe bereits in der Lua-Werkstatt um Unterstützung angefragt. --Former111 (Diskussion) 17:10, 28. Okt. 2021 (CEST)[Antworten]

Oh gott, ich sehe es schon kommen, Wikiseiten, die willkürlich abstürzen / nicht laden, weil irgend ein Bug in den Schleifenparametern zu einer Endlosschleife führt. ;-) Könnte man aber umgehen, wenn man die Zahl der Iterationen beschränkt. Dann ist maximal die einzelne Vorlage kaputt aber nicht die gesamte Seite. --TheRandomIP (Diskussion) 22:53, 25. Okt. 2021 (CEST)[Antworten]

Hat ein sehr großes Missbrauchspotenzial auf Wikis so groß wie die Wikipedia. Würde die WMF daher auch höchst wahrscheinlich nicht zulassen. --Zabe (Diskussion) 23:45, 25. Okt. 2021 (CEST)[Antworten]

Worin sollte das Missbrauchspotential bestehen? Mit Lua ist diese Funktionalität ohnehin seit langem schon vorhanden.--Cirdan ± 09:27, 26. Okt. 2021 (CEST)[Antworten]



Verbinden/Anlegen von bestehenden/neuen Wikidata-Objekten mit neu angelegten Artikeln/Kategorien unter Vermeidung von Dubletten[Quelltext bearbeiten]

Was ist das Problem?

Das Problem, neu angelegte Artikel, Kategorien, Vorlagen, Navigationsleisten, Commonscats, etc. entweder

  • mit bestehenden Wikidata-Objekten zu verbinden, sofern vorhanden oder
  • neue Wikidata-Objekte anzulegen, sofern noch nicht vorhanden

für hunderte von täglich neu angelegten Artikeln, Kategorien, etc. (siehe Bild)

Zahl der täglich neu erstellten Artikel in dewiki.png
  • bei gleichzeitiger möglichster Vermeidung von Dubletten unter den 95 Millionen vorhandenen Objekten (d:Special:Statistics)

wird seit Jahren immer wieder diskutiert, beispielsweise unter

uvam.

Wen betrifft das Problem besonders?

Alle Autorinnen und Autoren sowie alle Leserinnen und Leser, weil ein Artikel bei falscher/fehlender Zuordnung ggf. keine/falsche/fehlende Interwiki-Links zu anderen Sprachen bzw. Projekten (Wikisource, Commons, Wikivoyage, ...) hat

Lösungsvorschlag

Im Zuge der Diskussionen, wer, wann, wie (z.B. über verschiedene eindeutige IDs, wie Baudenkmal-IDs, GND, VIAF, LCCN, IMDb, Wfb, ...), ... die Artikel bestehenden Objekten zugeordnet werden bzw. neue Objekte angelegt werden sollen (durch einen Bot, manuell, teilweise durch Bot/teilweise manuell, ..., wann soll der Bot für welche Artikel laufen, etc.) wurde der Vorschlag gemacht, dem Autor/der Autorin nach dem Anlegen eines Artikels, einer (Commons)-Kategorie, etc. ein Pop-Up anzubieten, mit dem das Verbinden bzw. Anlegen eines Objektes ermöglicht werden, analog zu "Duplicate" in "PetScan".

Problem sind dabei unterschiedliche Sprachen, Bedeutungen, Schriftzeichen/Zeichensätze, usw., sodass ein Bot das Problem nur teilweise sinnvoll lösen kann. Viele Autoren/Autorinnen wissen nicht von der Existenz von Wikidata oder vergessen, mit einem Objekt zu verbinden bzw. ein Objekt zu erstellen oder es fehlt das entsprechende Wissen, wie dieser Schritt vorgenommen werden kann. Ein Pop-Up nach dem Anlegen eines Artikels, einer Kategorie, ... könnte den Autor/die Autorin daran erinnern, diese Aktivität noch durchzuführen.

Beispiel:

  • Außerdem sollten Übersetzungen automatisch mit jenen Artikel verbunden werden, aus denen die Übersetzung vorgenommen werden (auch nach Verschiebung vom Benutzernamensraum in den Artikelnamensraum)
  • Soweit eindeutig möglich (z.B. anhand von IDs, wie CAS-Nummer, IMDb, GND, VIAF, ...) könnten Bots automatisch Anlegen/Verbinden übernehmen und nur im Zweifel/bei Nichteindeutigkeit diese Arbeit einem Benutzer überlassen
    Vorschlagende Person

M2k~dewiki (Diskussion) 14:48, 25. Okt. 2021 (CEST)[Antworten]

Diskussion



Häufig fehlende Kategorien, Normdaten, Personendaten, Links auf BKLs, falsche Commonscat, etc. bei neu anlegten Artikeln bzw. vom BNR in den ANR verschobenen Artikeln[Quelltext bearbeiten]

Was ist das Problem?

Bei neu angelegten Artikeln gibt es eine Reihe von häufig auftretenden Problemen:

Beispielsweise

Wen betrifft das Problem besonders?

Alle Autorinnen und Autoren, Entlastung der Eingangkontrolle und Qualitätssicherung, mehr Effizienz und Konzentration auf inhaltliche Fehler statt Formalitäten

Lösungsvorschlag
  • Daher sollten standardmäßig verschiedene Helferleins aktiviert werden, sofern dies noch nicht der Fall ist
  • Benutzer sollten beim Speichern von neuen Artikeln
  • sowie beim Verschieben von Artikel vom Benutzernamensraum in den Artikelnamensraum
    • an das Hinzufügen von Kategorien (und ggf. Personendaten, Normdaten, ...) erinnert werden bzw. dabei (z.B. mittels Wizard/Pop-Up) unterstützt werden
    • eventuell können passende Kategorien automatisch vorgeschlagen werden (siehe Schnark-Helferlein), sodass der Benutzer diese nur mehr bestätigen/korrigieren muss
    • an das Verbinden/Anlegen mit/von einem Wikidata-Objekt erinnert werden, z.B. https://wikidata-todo.toolforge.org/duplicity.php?wiki=dewiki&norand=1&page=Vasco%5FCordeiro
    • Commonscats sollten beim Speichern auf Existenz überprüft werden, falls nicht vorhanden sollte eine Fehlermeldung erscheinen
    • ein fehlendes reference-Tag im Abschnitt Einzelnachweise sollte automatisch hinzugefügt werden
    • das Lemma in der Einleitung sollte ggf. automatisch hervorgehoben werden
    • könnte auf leere Abschnitte ohne Inhalt bestehend nur aus der Überschrift beim Speichern hingewiesen werden
      Anmerkungen

Siehe auch

--M2k~dewiki (Diskussion) 16:25, 25. Okt. 2021 (CEST)[Antworten]

Diskussion
  • Pro --Fuchs B (Diskussion) 21:20, 31. Okt. 2021 (CET)[Antworten]
  • Pro Ähnliches Problem wie in den Commons mit dem Bild-Upload. Wär super, wenn da Hilfestellungen und Erinnerungen auftauchen würden, wenn diese Abschnitte fehlen. --Grizma (Diskussion) 10:14, 1. Nov. 2021 (CET)[Antworten]



Farbliche unterschiedliche Darstellung von missbilligten bzw. bevorzugten Rängen in Wikidata-Objekten[Quelltext bearbeiten]

Was ist das Problem?

In Wikidata-Objekten sind Eigenschaften mit missbilligten Rängen optisch nicht von solchen mit bevorzugten oder normalen Rängen zu unterschieden, was zu Verwirrungen/Missverständnissen führen kann.

Beispielsweise:

Wen betrifft das Problem besonders?

Alle Benutzer von Wikidata

Lösungsvorschlag

Die missbilligten und bevorzugten Eigenschaften können mittels CSS farblich (z.B. rot für missbilligt bzw. grün für bevorzugt) gekennzeichnet werden.

Für das CSS siehe:

Dies sollte für alle Benutzer standardmäßig aktiviert werden.
Vorschlagende Person

--M2k~dewiki (Diskussion) 16:25, 25. Okt. 2021 (CEST)[Antworten]

Diskussion



Online-Typografiecheck im Editfenster vor Abschicken eines Edits, z.B. wie in Word[Quelltext bearbeiten]

Was ist das Problem?

Haufenweise grottige Typografie insbesondere im Fließtext

Wen betrifft das Problem besonders?

jeden Autor

Vorschlagende Person

Jbergner (Diskussion) 18:50, 25. Okt. 2021 (CEST)[Antworten]

Diskussion
Aus meiner Sicht ein Teilaspekt von Wikipedia:Technische_Wünsche/Wunschparkplatz#Häufig_fehlende_Kategorien,_Normdaten,_Personendaten,_Links_auf_BKLs,_falsche_Commonscat,_etc._bei_neu_anlegten_Artikeln_bzw._vom_BNR_in_den_ANR_verschobenen_Artikeln (Punkt Wikipedia:Helferlein/Rechtschreibprüfung), es sollten meiner Meinung nach darüber hinaus wie oben vorgeschlagen weitere Punkte beim Speichern geprüft, sofern möglich (halb)automatisch korrigiert/ergänzt oder dem Benutzer zur Korrektur gemeldet/vorgeschlagen werden. --M2k~dewiki (Diskussion) 19:37, 25. Okt. 2021 (CEST)[Antworten]
Aus meiner Sicht nicht mit etwas anderen verquicken, und dann bekommen wir gar nichts davon. Das ist mMn ein unabhängiges Thema, das immer die Glaubhaftigkeit der Texte betrifft. Viele glauben nicht, dass Qualität in der Sache dahintersteckt, wenn schon die Qualität der Darstellung nicht stimmt. --Jbergner (Diskussion) 10:57, 26. Okt. 2021 (CEST)[Antworten]



Ändern des SVG-Renderers, wie in phab:T283083 vorgeschlagen[Quelltext bearbeiten]

Was ist das Problem?

Viele SVG-Grafiken können derzeit nicht richtig als PNG dargestellt werden (z.B. textPath, FlowRoot), dafür gibt bereits einige Problemsammlungen/Workarounds:

Wen betrifft das Problem besonders?

Grafiker, WP:Grafikwerkstatt, alle Autoren die Vektorgrafiken einbinden wollen (dafür müssen die richtig dargestellt werden)

Lösungsvorschlag
Statt libRsvg REsvg zum Rendern der SVGs verwenden, siehe phab:T40010
Anmerkungen

auf c:User:JoKalliauer/SVG_test_suites sind Vergleiche von rsvg, resvg, inkscape and batik. Resvg ist in allen Kategorien rsvg überlegen.

SVG librsvg 2.50 resvg 0.14.0 Inkscape 1.0 batik 1.13; 1.14
W3C correctness 0,662 0,831 0,745 0,801
W3C cpu-time (512px) 1m 46,776s 1m 04,490s 7m 57,465s 6m 51,560s
RazrFalcon correctness 0.754 0.956 0.729 0.703
RazrFalcon time 4min 05sek 2min 30sek 46min 22sek 61min 29sek
featured correctness 0.92 1.00
featured time 5m 17,701s 4m 46,639s 15m 28,202s 11m 30,768s
time 2006-MediaWiki-collection (512px) 23.129s 9.551s 186.809s 87.313s
solved phab:-tasks relative to all tasks 0.55 0.88 0.78
Vorschlagende Person

 — Johannes Kalliauer - Diskussion | Beiträge 19:28, 25. Okt. 2021 (CEST)[Antworten]

Diskussion



Artikel mit Versionsgeschichte einfach kopieren[Quelltext bearbeiten]

Was ist das Problem?

Häufig hat man das Problem, dass Artikel zu aktuellen Themen unüberschaubar lang werden oder man ältere Artikel anders aufteilen möchte. Dann möchte man Teile des Artikels in andere (neue) Artikel kopieren. Dabei ist aber das Urheberrecht zu beachten. Dazu gibt es aktuell Möglichkeiten des Versionsimports. Diese können aber nur von speziell technisch begabten Administratoren gemacht werden, und wenn ein Artikel mehr als 1000 Versionen hat, ist es eine mega Arbeit für den Administrator. Das ist technisch nicht mehr zeitgemäß und liegt an einer veralteten technischen Umsetzung in der Wikisoftware. Besonders bei den Artikelserien zur COVID-19-Pandemie ist das Problem sichtbar geworden. Dort haben Leute anfangs alles in einen Artikel geschrieben aber schnell wurde klar, dass man solch ein Weltereignis nicht bloß in einem Artikel beschreiben kann. Es folgten unzählige Auslagerungen mit mühsamen Versionsimport.

Oder wenn ich einen Artikel übersetzen möchte aus einer anderen Sprache, dann ist es genau das gleiche Prozedere.

Wen betrifft das Problem besonders?

Autoren, die sich um das Aufräumen der Erzeugnisse von Newsticker-Inklusionisten kümmern. Autoren, die die Artikellandschaft anders strukturieren wollen. Übersetzer.

Lösungsvorschlag

Wenn ich einen Artikel sehe, den ich gerne in mehrere Einzelartikel spalten möchte, dann möchte ich einen Knopf drücken, und schwupps hab ich einen zweiten Artikel unter anderem Namen, der exakt die gleiche Versionsgeschichte teilt. Einen Knopf. Mehr nicht. So wie man das z.B. von Versionsverwaltungstools wie git kennt. Dort können einzelne Commits (Edits) auch zwischen verschiedenen Branches (Lemma) geteilt werden. Wikipedia sollte genau so funktionieren.

Bonusfeatures: Mehrere Versionsgeschichten zusammenführen, Versionsgeschichte in eine andere Versionsgeschichte importieren usw. sollte auch mit einem Knopf möglich sein.

Technisch sollte das alles möglich sein, denn wenn man etwas manuell machen kann, kann man es auch automatisieren. Nur als Reminder: Computer sind turing-vollständig, also (fast) alles, was erdacht werden kann, kann auch programmiert werden. (Falls das Gegenargument käme "technisch nicht umsetzbar")
Anmerkungen
Aktuell werden Versionsimports manuell durchgeführt. Laut Statistik gab es im letzten Jahr 5824 Importe (etwa 485 pro Monat). Gehen wir mal davon aus, jeder Import dauert im Schnitt 5 Minuten (via.), dann werden pro Monat 40 Stunden ehrenamtliche Arbeitszeit derzeit verbraucht, um einen eigentlich voll-automatisierbaren Task zu erledigen. Wenn man das mal gescheit automatisiert, sollte sich das also recht schnell amortisieren. (Wenn man es zentral für alle Wikis macht sowieso)
Vorschlagende Person

--TheRandomIP (Diskussion) 23:09, 25. Okt. 2021 (CEST)[Antworten]

Diskussion
Das lässt sich vielleicht technisch, aber nicht organisatorisch bewerkstelligen. Ein Problem wäre, dass nur jemand mit Admin- oder Importrechten importieren darf, egal ob ein einzelner Knopf da ist oder nicht. Ein weiteres Problem wäre, dass Importoptionen nicht ausgewählt werden können, wie sie auf Special:Import beim XML-Upload einstellbar sind. Des Weiteren prüft der Importeur, inwieweit ein Import überhaupt notwendig ist, bevor er ihn ausübt, denn wir importieren einzig und allein aus lizenzrechtlichen Gründen. Außerdem muss darauf geachtet werden, dass sich bei der Vereinigung von Artikeln die Versionsgeschichten nicht überschneiden. Mit einem Knopf geht das leider nicht. Soll das Importieren künftig auch anderen Benutzern als Administratoren erlaubt werden, muss zuerst ein Meinungsbild durchlaufen werden, aber auch dann ist der einzelne Knopf zu wenig. – Doc TaxonDisk. 22:29, 27. Okt. 2021 (CEST)[Antworten]
Ich bin mir sicher, wenn man das mal gescheit mit GUI-Elementen implementiert, wenn man nicht mit XML-Dateien? herumfummeln muss, mit denen man im Zweifel wohl auch einiges kaputt machen kann, wenn es also "idiotensicher" ist, wird die Community den Vorteil schon erkennen.
Wenn ich mal träumen dürfte, Wikipedia müsste eigentlich intern mal die ganze Versionsverwaltung umschreiben, damit es funktioniert wie bei git. Damit so etwas wie eine Nicht-lineare Entwicklung möglich ist. Beliebig branchen (abzweigen), mergen (zusammenführen) usw. Das wär's doch. Überleg mal, man könnte "Pull Requests" für Artikel machen. Man könnte eine Änderung an einem Artikel zuerst in einem privaten Branch vorbereiten, und dann der Community als sogenanntes "Pull Requests" vorstellen. Und erst, wenn eine gewisse Mindestzahl an "Approvern" (formal) zugestimmt haben, darf gemergt werden. Damit könnte man umkämpfte Honey-Pots sofort entschärfen und würde die Ambiguität, ob nun ein Konsens herrscht, sofort auflösen. Wobei man das natürlich bei weniger umkämpften Artikeln nicht machen muss. Das würde die Wikipedia auf ein neues Level heben... Da müsste Wikipedia perspektivisch hin... der Use Case Artikel duplizieren wäre ein Anfang, den man sich vornehmen könnte. --TheRandomIP (Diskussion) 23:03, 27. Okt. 2021 (CEST)[Antworten]
An XML-Dateien fummelt man nicht rum. So kriegt man die dann auch nicht kaputt. Für ein Editieren per git müsstest Du so ziemlich die gesamte Software umschreiben. So kaputt, wie die jetzt schon ist, und so voll, wie die Datenbanken sind, kriegst Du wohl kaum eine Änderung diesbezüglich hin. Du müsstest die Software komplett neu schreiben und die Datenbankinhalte dann rüberschieben. Aber wer von unseren Benutzern ist schon geübt darin, mit Pull Request und Merge zu arbeiten? Du könntest ja mit einer Wikigitia einen ernstzunehmenden Wikipedia-Konkurrenten auf den Markt werfen. – Doc TaxonDisk. 05:27, 28. Okt. 2021 (CEST)[Antworten]



Visueller Editor performanter machen[Quelltext bearbeiten]

Was ist das Problem?

Der Wikisyntax ist umständlich, man muss viel tippen, er ist nicht barrierefrei, ein Relikt aus den 00er Jahren, nicht für alle konzeptionell verständlich (Ältere Menschen usw.). Deshalb wurde vor einiger Zeit endlich der visuelle Editor vorgestellt.

Doch leider ist dieser immer noch viel zu langsam und träge, gerade bei längeren Artikeln nicht zu gebrauchen. z.B. versucht mal COVID-19-Pandemie mit dem visuellen Editor zu bearbeiten. Holt euch schon mal einen Kaffee. Also muss man wieder auf den Wikisyntax ausweichen.

Wen betrifft das Problem besonders?

Fast alle Autoren, die an größeren Artikeln arbeiten.

Lösungsvorschlag

Es gäbe mehrere Möglichkeiten, die man evaluieren könnte:

  • Entwicklungszeit in das Profiling des visuellen Editor investieren, um ihn schneller zu machen. Sprich: Langsamen Code identifizieren, ihn durch performanteren Code ersetzen. Ihr denkt vielleicht, das bringt nichts? Doch! Durch Softwaretricks kann man manchmal die Laufzeit um den Faktor 100 und mehr reduzieren.
  • Andere Webtechniken, Programmiersprachen evaluieren, z.B. WebAssembly. Vielleicht ist der Bottleneck auch die Skriptsprache, die aktuell verwendet wird, könnte ja sein.
  • Möglichkeit einbauen, visuellen Editor auf einzelne Abschnitte beschränken zu können, so wie man es heute auch mit dem Wikisyntax kann.
  • Visueller Editor mit optionalem "Fast Mode", bei dem z.B. Bilder und Tabellen (oder alles, was ihn langsam macht) nicht geladen werden, wenn man eh nur am Text arbeiten will.
    Vorschlagende Person

TheRandomIP (Diskussion) 22:30, 25. Okt. 2021 (CEST)[Antworten]

Diskussion
Der visuelle Editor ist auch noch nicht fertig und wurde bereits vor der Komplettierung bereitgestellt. Seit dem hakt die Weiterentwicklung, Fehlerbekämpfung, und es fehlt ein Team, das sich auf diesen Editor spezialisiert hat. Des Weiteren empfehle ich die Nutzung mit mobilen Phones, wie man es auch nehmen mag zwinkerVorlage:Smiley/Wartung/zwinker  Wer ernsthaft editieren will, nimmt den herkömmlichen Editor. – Doc TaxonDisk. 05:43, 28. Okt. 2021 (CEST)[Antworten]
Es gäbe wahrlich viel zu modernisieren in der Wikipedia... die sollen halt mal unsere Spendengelder zielgerichteter einsetzen. Anstatt für unnötige Dinge wie ein Code of Conduct, sollen die mal Geld für Programmierer ausgeben, die das weiterentwickeln. --TheRandomIP (Diskussion) 16:10, 28. Okt. 2021 (CEST)[Antworten]
Sowohl der VisualEditor als auch die zugehörige Komponente Parsoid werden bei der WMF jeweils von einem Team aktiv betreut und weiterentwickelt.--Cirdan ± 22:03, 28. Okt. 2021 (CEST)[Antworten]
Im Artikel Bundestagswahl 2021/Umfragen und Prognosen konnte ich schlicht keine Veränderungen durchführen (auch Quelltext nicht), weil der ARtikel wohl zu groß oder komplex war. Ich musste dann über die Disk alles regeln, war etwas anstrengend. --Fan-von-mir (Diskussion) 15:21, 31. Okt. 2021 (CET)[Antworten]
Die Quelltextbearbeitung solltest du hinbekommen, wenn du Syntaxhervorhebung ausschaltest. Also zumindest bei mir hat das dann geholfen. Darüber hab ich auch schon mal einen Rant verfasst. --TheRandomIP (Diskussion) 16:57, 31. Okt. 2021 (CET)[Antworten]
Der Visual Editor ist für große Artikel nicht geeignet, weil die Browser das schlichtweg nicht schaffen. Beim VE wurde die Kuh ohne Milch aufgezogen, und mit dem erzeugenden Ärger dann auf uns losgelassen. Das schlichtweg einfachste wäre eine kombinierte Edit-Umgebung gewesen, aber wer entwickelt schon lieber etwas weiter als etwas neues. Letzten Endes will ich damit sagen, dass die Benutzer viel zu wenig (bzw. nicht ausreichend oder gar gar nicht) in die Weiterentwicklung der Software, die sie selbst dauernd benutzen, einbezogen werden, und das finde ich wirklich sehr schade. – Doc TaxonDisk. 07:53, 1. Nov. 2021 (CET)[Antworten]
Ich hatte Syntyhervorhebung aus und war auch im Queltexteditor, also daran lags nicht – bei mir zumindest. --Fan-von-mir (Diskussion) 12:57, 1. Nov. 2021 (CET)[Antworten]



&nnbsp; als Synonym für &#8239;[Quelltext bearbeiten]

Was ist das Problem?

Es scheint sehr großes Interesse zu geben, in Abkürzungen oder zwischen Zahl und Einheit das typografisch ›korrektere‹ schmale geschützte Leerzeichen zu verwenden. Siehe Verwendung der HTML-Entität oder die {{Nnbsp}}. Ersteres hat den Nachteil, dass es derartige Zahlen recht kryptisch erscheinen. Letzteres hat u. a. den Nachteil, dass dies im visuellen Editor kaputt erscheint. Auch war diese Vorlage lange Zeit fehlerhaft eingestellt und wird nun fehlerhaft als Tausendertrenner verwendet (dort sollte zwar ein größerer Zwischenraum erscheinen, beim kopieren darf aber kein Leerzeichen gesetzt werden).

Da HTML-Entitäten sowieso von der Software in die dezimale Form umgewandelt werden, siehe z. B. der Quelltext dieser Seite in den Abkürzungen, könnte die Software auch weitere benannte Enitäten erlauben, die so eigentlich nicht existieren. Ein Nachteil daran könnte sein, dass möglicherweise nicht alle Browser diese Entität kennen. Alle großen Browser und Browserengines, nahezu alle Schriftarten und auch viele ungewöhnliche Browser wie w3m scheinen damit umgehen zu können, insofern denke ich, dass das mehr als 99 % der Leser nicht betreffen wird.

Wen betrifft das Problem besonders?

Autor*innen, die Typographie manchmal etwas zu ernst nehmen

Lösungsvorschlag

An der Stelle, wo &nbsp; ersetzt wird ein Synonym für &nnbsp; hinzufügen:

Hinter Zeile 210 in [2] 'nnbsp' => 8239, // MediaWiki-specific named entity to prevent magic numbers einfügen

Falls das Problem veralteter Browser noch existiert, könnte man eine kompliziertere Lösung wählen, wo anhand des User-Agent statt &#8239; einfach &#160; gesetzt wird. Beispielsweise durch einsetzen eines <span class="nnbsp"></span> und über css und js clientseitig. Ich glaube aber, die einfachste Lösung wird am ehesten akzeptiert, da man bei einem einfach &…; kein komplexes Verhalten erwarten würde.
Anmerkungen
Weitere Entitäten zu benennen wäre auch überlegenswert, beispielsweise &lsqb; und &rsqb; für [ und ]. Ein gleichlautender Vorschlag wurde 2010 abgelehnt. Die Löschung von {{Nnbsp}} wurde im Übrigen deshalb abgelehnt, weil es noch keine bessere Lösung, wie z. B. ein &nnbsp; gibt und &#8239; ungeeignet ist, weil sich das niemand merken könne.[3].
Vorschlagende Person

— Sivizius (Diskussion) 13:12, 26. Okt. 2021 (CEST)[Antworten]

Diskussion

Ich hörte, es gebe mit Safari 13.1, einem durchaus modernen Browser Probleme. Kann das jemand bestätigen?— Sivizius (Diskussion) 10:19, 4. Jul. 2020 (CEST)[Antworten]

Ungewöhnliche Browser sollte man modernisieren, um aus der Inter-Nett-Steinzeit herauszukommen. Ansonsten unbedingt dafür! --Klaus-Peter (aufunddavon) 10:39, 4. Jul. 2020 (CEST)[Antworten]

Wie würde es sich eigentlich mit dem visuellen Editor verhalten, wenn da ein &nnbsp; steht? Derzeit wird einfach &nnbsp; angezeigt, aber ich weiß nicht, ob das nach dieser Änderung ebenfalls bleibt.— Sivizius (Diskussion) 20:39, 7. Jul. 2020 (CEST)[Antworten]



Individuelle Anpassung des Bearbeitungsfensters[Quelltext bearbeiten]

Was ist das Problem?

Beim Erstellen längerer Textblöcke oder Artikel ist es oft lästig, dass das Bearbeitungsfenster auf ca. die halbe Bildschirmhöhe begrenzt ist. Es wäre mMn nach günstiger wenn man die Höhe des Fensters individuell festlegen kann.

Wen betrifft das Problem besonders?

alle Benutzer, die längere Texte bearbeiten und die „alte Methode“ verwenden (ohne Visueller Editor)

Lösungsvorschlag
  • der Parameter, der die Höhe definiert, sollte in den eigenen Grundeinstellungen (Profil) veränderbar sein. Das wird ja nur ein Zahlenwert sein? Das wäre dann immer wirksam (solange man/frau den Wert gleich lässt)
  • Noch besser wäre ein Button in der Bearbeitungsleiste, der das Fenster größer macht (im jeweiligen Bearbeitungsschritt), zB durch die + / - Taste
  • technisch aufwendigere aber noch praxisnähere Lösungen, wie zB Klicken eines Button und ziehen des unteren Bildrandes auf die gewünschte Höhe, wären das Optimum ;-)
    Vorschlagende Person

Hannes 24 (Diskussion) 13:44, 26. Okt. 2021 (CEST)[Antworten]

Diskussion

Oder Firefox benutzen :-) --TheRandomIP (Diskussion) 14:05, 26. Okt. 2021 (CEST)[Antworten]


solche Kommentare kannst Du dir eigentlich ersparen, die sind nicht sehr hilfreich. --Hannes 24 (Diskussion) 19:32, 26. Okt. 2021 (CEST)[Antworten]
Firefox fügt eben automatisch die Resize-Eigenschaft hinzu, wenn nicht schon vorhanden. Sicher, dass es bei dir nicht auch geht? Einfach mal in die untere rechte Ecke gehen und Textbox per Drag & Drop größer ziehen. Sollte bei allen modernen Browsern gehen.
Und ist eigentlich sogar schon automatisch aktiviert: https://de.wikipedia.org/w/load.php?lang=de&modules=ext.wikiEditor.styles&only=styles&skin=vector #wpTextbox1{line-height:1.5em;resize:vertical}
Sofern du nicht einen Uralt-Browser nutzt, oder einen anderen Wikipedia-Stil als Vektor, sollte das gehen.
Wikipedia sendet jedenfalls die richtigen Eigenschaften mit, wenn es nicht geht liegt es nicht an Wikipedia... --TheRandomIP (Diskussion) 20:23, 26. Okt. 2021 (CEST)[Antworten]
ich bin schon ein „älteres Semester“ und nutze einen „Uralt-Browser“, das ist reine Bequemlichkeit (keine Lust in der Arbeit/privat zwei versch Systeme merken zu müssen ;-) Wenn es technisch nicht geht, dann eben nicht. --Hannes 24 (Diskussion) 21:08, 26. Okt. 2021 (CEST)[Antworten]
Sicher wäre das technisch möglich, was du vorschlägst, aber wäre dann halt nur als "Krücke" für "Uralt-Browser" nützlich, während der Rest einfach die schon vorhandene Möglichkeit nutzt, die Textbox per Maus größer zu ziehen. --TheRandomIP (Diskussion) 00:47, 27. Okt. 2021 (CEST)[Antworten]
P.S. Der Internet Explorer, wie ich ihn liebe. "Resize? Nie gehört! Rot unterkringeln". Die Resize-Eigenschaft gibt es seit mehr als 10 Jahren. Der Firefox kann das seit Version 5. Der Internet Explorer kann das bis heute nicht. Firefox kann das seit 10 Jahren. Vielleicht sollte man die Wahl des Browsers doch nochmal überdenken ;-) --TheRandomIP (Diskussion) 01:02, 27. Okt. 2021 (CEST)[Antworten]
Danke für deine Erläuterungen. Ich verwende auch Chrome, aber du hast im Grunde recht, es wäre zu aufwändig. lG --Hannes 24 (Diskussion) 18:49, 28. Okt. 2021 (CEST)[Antworten]
hat sich erledigt, hab die Funktion jetzt (in chrome) entdeckt. ;-) --Hannes 24 (Diskussion) 19:34, 28. Okt. 2021 (CEST)[Antworten]

Reaktivierung der PDF-Buchfunktionalität[Quelltext bearbeiten]

Was ist das Problem?

Die PDF-Buchfunktionalität (Erstellung von mehreren gesammelten PDFs mit einer Auswahl von Artikel inkl. Inhaltsverzeichnis etc.)

ist seit ein paar Jahren nicht mehr verfügbar

Die vorgeschlagene Alternative

bietet hinsichtlich Lesbarkeit/Formatierung der erzeugten PDFs, Skalierbarkeit/Laufzeit leider nicht die Eigenschaften der ursprünglichen Funktionalität.

Wen betrifft das Problem besonders?

Wen betrifft das Problem besonders?

Lösungsvorschlag

Eine Reaktivierung wäre wünschenswert.

--M2k~dewiki (Diskussion) 17:51, 26. Okt. 2021 (CEST)[Antworten]

Diskussion

Warum wurde das denn deaktiviert? --Fan-von-mir (Diskussion) 14:20, 29. Okt. 2021 (CEST)[Antworten]

Naja es wurde deaktiviert weil es keiner die Entwickler bezahlen wollte um die Software zu warten. Ich selbst könnte die Funktion mit den ursprünglichen Eingenschaften leicht herstellen, nur da man auch mich nicht dafür bezahlen würde, werde ich es lassen. Man muss lediglich das HTML etwas bereinigen und anschließend durch den PDF Generator von QtWebkit jagen. Eine C Bibliothek mit der sich dass HTML bereinigen lässt ist htmltidy. Das ist dann auch hinreichen performant wie ich bereits gemessen habe. Geschätzte Kosten 200000 EURO Viele Grüße --Dirk Hünniger (Diskussion) 17:41, 29. Okt. 2021 (CEST)[Antworten]
Meiner Meinung nach sind die genannten Kosten im Verhältnis zum Ergebnis unverhältnismäßig hoch. Ich persönlich habe aber auch keine so hohen Ansprüche an das Aussehen von Texten.--Hogü-456 (Diskussion) 11:29, 30. Okt. 2021 (CEST)[Antworten]



Danken für’s Sichten[Quelltext bearbeiten]

Was ist das Problem?

Sichten ist of aufwendig und verantwortungsvoll. Ein Dankeschön ist eine nette Geste. (Sicherlich könnte ich in Einzelfällen auf die Disk des Sichters schreiben. Das finde ich im Normalfall aber zu aufwendig.)

Wen betrifft das Problem besonders?

Neue Wikipedianerinnen und Wikipedianer, die noch nicht Sichten dürfen.

Lösungsvorschlag
Schaltflächen für angemeldete Mitschreibende.
Vorschlagende Person

Mobil-Sockenpuppe (Diskussion) 06:38, 18. Jun. 2020 (CEST)[Antworten]

Diskussion
  • Pro --Fuchs B (Diskussion) 21:26, 31. Okt. 2021 (CET)[Antworten]
  • Pro --Himbeerbläuling (Diskussion) 22:23, 4. Nov. 2021 (CET)[Antworten]
  • Neutral Manchmal gibt es auch ungesichtete Beiträge, die niemand sichten oder revertieren mag. Wenn dann sich jemand intensiv damit beschäftigt hat und den gordischen Knoten durchtrennt hat, möchte man gern mal Dankbarkeit zeigen, auch wenn man die Sichterrechte schon hat. Auf der anderen Seite sind für mich andere Vorschläge einfach wichtiger. --Fan (Diskussion) 22:38, 4. Nov. 2021 (CET)[Antworten]



Dateien Hochladen und Verwalten[Quelltext bearbeiten]

Beschreibung des Themas

Verbesserung der Tools zum Hochladen von Dateien und die Möglichkeit große Dateien(>4GiB) hochzuladen.

Begründung

Das Fotos und andere Medien zuverlässig und einfach hoch geladen werden können ist wichtig, um Inhalte zu illustrieren. Gibt es dabei Probleme werden neue Menschen die eigene Fotos beitragen wollen abgeschreckt und Menschen die große Mengen an meist eigenen Fotos beitragen wollen hören im schlimmsten Fall damit auf.

Was ist das Problem?
  • Der UploadWizard funktioniert nicht zuverlässig. Es gibt Abbrüche, unklare Fehlermeldungen und lange Wartezeiten.
  • Es gibt kein offizielles Uploadtool das auf dem System installiert werden kann, so dass, gerade für Massenuploads, eine Alternative besteht. Alle existierenden Tools werden von Freiwilligen gepflegt, die aber zum Teil gar nicht mehr dabei sein. Das GLAM Toolset wurde 2019 eingestellt.
  • Dateien über 4GiB Größe können nicht hochgeladen werden.
Wen betrifft das Problem besonders?

Alle die Dateien hochladen, insbesondere große Dateien oder viele Dateien.

Lösungsvorschlag
  • Behebung der Probleme des UploadWizard.
  • Bau eines modernen Crossplattform Tools zum Massenupload als Nachfolger für das GLAM Toolset.
  • Schaffung einer Möglichkeit zum Upload von Dateien größer als 4GiB.
    Vorschlagende Person

GPSLeo (Diskussion) 20:06, 26. Okt. 2021 (CEST)[Antworten]

Diskussion


Es gibt im UploadWizard seit Jahren unverändert einen Bug, der insbesondere neue oder mit Commons unerfahrene Benutzer unnötig in Stress versetzt. Bilder im Hochformat werden nicht erkannt und in der Vorschau im Querformat angezeigt. Manche Benutzer brechen dann mehrfach ab und versuchen es erneut oder denken ihr Bild sei defekt, obwohl es dann später korrekt angezeigt wird. Und der Wizzard nutzt aus irgendwelchen Gründen die mögliche Bandbreite für den Upload nicht und ist unnötig langsam. Manchmal muss auch ein Benutzer mal schlafen oder zur Arbeit oder möchte mehr Zeit für die Fotografie als für den Upload verbringen. Ein Dropdown Menü für die Dateibeschreibungsseite, das sich die zuvor eingegebenen Kategorien merkt und auch sonst noch ein paar Hilfen dabei hat. Eine Pausenfunktion fehlt auch. Nicht immer kann man stundenlang neben dem PC sitzen und warten, bis die letzte Datei nach drei Versuchen endlich hochgeladen ist. Dateien im Stash kann man nicht per Mausklick auswählen und nachträglich veröffentlichen, wenn es zwischendurch einen Verbindungsabbruch gab, gleichzeitig kann man das Bild auch nicht ein zweites Mal hochladen. Auch das bringt neue Benutzer an den Rand des Nervenzusammenbruchs. Und es ist ja nicht so, dass nur wenige das Programm benutzen. Gemäß einer alten einfachen Regel sollten die am meisten benutzten Werkzeuge oder wenn man will einer Software von besonders hochwertiger Qualität, besonders gebügelt, gestriegelt und geschniegelt werden und besonders stabil laufen und flutschen. Gelegentlich werden Dateien am Ende abgeschnitten, der Uploadwizzard merkt anscheinend nichts davon, oder wenn er es tut, so lässt er sich das nicht anmerken, was für den Benutzer das Gleiche ist. Erst Wochen später merkt das dann ein Bot, dass die letzten Zeilen des Bildes alle grau sind. Jetzt, um Himmels willen, wie hieß die Datei noch beim Hochladen? Das wäre mal eine nützliche Information, die nicht mehr angezeigt wird. Auch wenn man später eine Datei nachbearbeiten will, wäre so ein ursprünglicher Dateiname nützlich. Dann viel Spaß beim erneuten Suchen der Originaldatei. Suche nach Datum und Uhrzeit bleibt da noch. Das Tool ist im momentanen Zustand mit zwei bis drei von fünf möglichen Sternen gerade noch gut genug, dass die Benutzer nicht anfangen sich aus lauter Frust selbst zu verletzen oder ihren PC aus dem Fenster werfen wollen. Aber so mancher Fluch über den Wizzard bringt mir negatives Karma.--Giftzwerg 88 (Diskussion) 12:18, 31. Okt. 2021 (CET)[Antworten]

Bearbeitungskonflikt bereits bei der Vorschau erkennen[Quelltext bearbeiten]

Beschreibung des Themas

Wenn man eine Seite mit dem Quelltexteditor bearbeitet, bemerkt man erst einen Bearbeitungskonflikt, wenn man auf Veröffentlichen geht.

Begründung

Verhindert mühevolles neuedieren oder umändern, besonders bei umfangreicheren Bearbeitungen

Was ist das Problem?

Wenn man nach einer Inhaltsänderung in einem Artikel im Quelltexteditor auf Veröffentlichen geht, wird dann erst ein aufgetretener Bearbeitungskonflikt angezeigt. Daraufhin muss man einzelne Textpassagen des eigenen Textes an die richtige Stelle wieder einfügen, was auch fehlererzeugend sein kann. Oft nutzt man bekanntlich zwischendurch die Vorschau. Bei einem frühzeitig angakündigten Bearbeitungskonflikt kann man die Bearbeitung neu starten und/oder der nachzubearbeitende Textumfang ist geringer.

Wen betrifft das Problem besonders?

Alle Autoren, die mit dem Quelltexteditor arbeiten

Lösungsvorschlag
Nach Druck auf den Vorschau-Button wird ein Hinweis eingeblendet, dass ein Bearbeitungskonflikt vorliegt
Anmerkungen
Ich kann nicht beurteilen, ob das technisch überhaupt möglich ist
Vorschlagende Person

Orgelputzer (Diskussion) 16:42, 27. Okt. 2021 (CEST)[Antworten]

Diskussion
So was hab ich mir auch schon so oft gewünscht, und mit Sicherheit sind wir beiden da nicht die einzigen. Eine Vorschau sollte vorausschauen, also auch auf eine Änderung des Artikels aufspringen, während jemand anders dran arbeitet. Nur so funktioniert die Erkennung und Bearbeitung von Bearbeitungskonflikten wirklich sinnvoll. – Doc TaxonDisk. 05:51, 28. Okt. 2021 (CEST)[Antworten]
  • Pro --Fuchs B (Diskussion) 21:28, 31. Okt. 2021 (CET)[Antworten]
  • Pro Zwar schon verbessert im Vergleich zu früher, als noch Textmengen unwiderruflich verloren waren, aber immer noch ein nerviges Problem. --Grizma (Diskussion) 10:10, 1. Nov. 2021 (CET)[Antworten]



Übernahme von Geokoordinaten nach Wikidata mit deutschem Zahlenformat[Quelltext bearbeiten]

Was ist das Problem?

Bei der manuellen Übernahme von Geokoordinaten aus der deutschen Wikipedia nach Wikidata sollte auch das deutsche Zahlenformat akzeptiert werden. Bisher muss man manuell wandeln z.B. aus der Anzeige rechts oben 53° 31′ 44,43″ N, 10° 20′ 24,3″ O muss werden 53° 31′ 44.43″ N, 10° 20′ 24.3″ E , d.h. Punkt durch Komma ersetzen und O durch E - das könnte doch automatisch gehen.

Wen betrifft das Problem besonders?

Leute die mit Wikidata arbeiten, z.B. um Lagekarten zu erstellen. Wenn man 50 Objekte übernehmen will, nervt das etwas.

Lösungsvorschlag
Eine Möglichkeit wäre wenn die Software die eingegebenen Daten analysiert und das Format der Daten automatisch erkennt und passend wandelt. Noch schöner wäre, wenn es einen Button gäbe "Übernahme aus dt. Wikipedia" gleich mit Angabe der Fundstelle.
Vorschlagende Person

Gerd Fahrenhorst (Diskussion) 19.22, 27. Okt. 2021 (CEST)

Diskussion

Meines Wissens nutzen nicht nur die Deutschen Wikidata. Andere erdreisten sich ebenfalls, die dort eingetragenen Koordinaten zu verwenden. Die Variante mit 'E'st und Dezimalpunkt wird international verstanden und kann zudem von Programmen, die diese Daten nutzen, verarbeitet werden.

Als Alternative denkbar wäre die Dezimaldarstellung, aber auch die mag den Dezimalpunkt aber zumindest entfallen die Himmelsrichtungen.--Klaus-Peter (auf und davon) 08:39, 18. Mai 2020 (CEST)[Antworten]

Es geht mir zunächst einmal darum, dass das Copy&Paste aus der dt. Wikipedia funktioniert. Wie die internen numerischen Koordinaten hinterher angezeigt werden, ist eine ganz andere Frage. Falls man als Konfortlösung einen Button zu Übernahme vorsieht, könnte der natürlich die Sprachversion abfragen. -- Gerd Fahrenhorst (Diskussion) 21:23, 18. Mai 2020 (CEST)[Antworten]
Da das Format in GeoHack inzwischen oben rechts international dargestellt wird, ist es via dem kleinen ‚Umweg‘ flott realisierbar. Auch unten unter „Koordinaten für Kartendienste ...“ findet man alle verwertbaren Darstellungsfornmen. -→KPF&Blabla← 19:46, 27. Okt. 2021 (CEST)[Antworten]



Quelltexterstellung des Visual Editor[Quelltext bearbeiten]

Beschreibung des Themas

Der Visual Editor erstellt Quelltext, der nicht immer optimal ist und zu Edits im Quelltext führt, die überflüssig gemacht werden könnten, indem der Visual Editor verbessert würde.

Begründung

Weil es mich immer wieder nervt und es aber einmalig gelöst werden könnte. Es führt zu längeren Versionsgeschichten bzw. vielen Änderungen im Quelltext, die im Versionsunterschied angezeigt werden, aber eigentlich keine Relevanz haben.

Was ist das Problem?

Beispiel 1: Durchkopplung

Beispiel 2 Mit typo wie Kursivschrift ist mir das auch schon mehrfach passiert. Das folgende Beispiel ist real, siehe hier

  • [[MTV Unplugged – Live aus dem Hotel Atlantic|''MTV Unplugged – Live aus dem Hotel Atlantic'']] statt ''[[MTV Unplugged – Live aus dem Hotel Atlantic]]''

Beipiel 3

  • Ich erstelle eine Liste im Visual Editor
  • Im Quelltext wird zwischen dem Stern und dem ersten Buchstabe kein Leerzeichen eingefügt
  • entweder ich oder andere machen das dann händisch im Quelltext, zum Beispiel hier
  • siehe auch Hilfe_Diskussion:Listen#Leerzeichen_nach_*
Wen betrifft das Problem besonders?

Benutzer wie Aka und andere, denen ein möglichst gut lesbarer Quelltext wichtig ist. Nicht technisch versierte (und neue) User werden unnötig durch die Änderungen verwirrt.

Lösungsvorschlag
Der Visual Editor sollte die Verienfachung von Wikilinks automatisch erkennen und entsprechend anpassen und beim Erstellen von Listen/Aufzählungen u. ä. automatisch ein Leerzeichen hinter das Sternchen bzw. die Raute machen.
Anmerkungen

Von mir aus kann das in einen größeren Themenschwerpunkt gebündelt werden, zB mit:

  • Online-Typografiecheck im Editfenster vor Abschicken eines Edits, z.B. wie in Word
  • Visueller Editor performanter machen
  • Individuelle Anpassung des Bearbeitungsfensters
  • Bearbeitungskonflikt bereits bei der Vorschau erkennen
Ehrlich gesagt scheint mir der Aufwand nicht allzugroß zu sein. Ein paar Zeilen zur Stringbearbeitung sind zu schreiben und anschließend muss der Visual Editor geupdatet werden. Ich kann nicht nachvollziehen, warum das zu anderen Themen in Konkurrenz treten soll.
Vorschlagende Person

Fan-von-mir (Diskussion) 17:19, 28. Okt. 2021 (CEST)[Antworten]

Diskussion

Die ersten beiden Fehler sind seit Jahren bekannt und aus verschiedenen Gründen offenbar schwer zu lösen: phab:T50463/phab:T54240 entsprechen Beispiel 1, phab:T247241 entspricht Beispiel 2 (dort wird auch eine Methode beschrieben, wie das Problem umgangen werden kann). Dein Beispiel drei kann ich nicht nachvollziehen. Wenn ich mit dem VisualEditor eine Liste anlege, werden Leerzeichen zwischen Stern und Listeneintrag eingefügt (Beispiel). Falls das bei dir anders ist: Kannst du mir eine Schritt-für-Schritt-Anleitung geben, damit ich den Fehler nachvollziehen kann? Grundsätzlich ist es so, dass der VisualEditor bzw. die Komponente Parsoid, die letztlich den Wikitext erzeugt, durch Altlasten in der Wikisyntax und dem nicht sauber entworfenen MediaWiki-Parser sehr eingeschränkt sind. Es ist also leider nicht mit „ein paar Zeilen zur Stringbearbeitung“ getan – allein schon, weil dann auch in Stellen des Quelltexts eingegriffen würde, die gar nicht bearbeitet wurden, was erst recht zu unleserlichen Versionsunterschieden führen würde. (Es ist schon fast eine Meisterleistung, dass der VisualEditor es von ganz wenigen Ausnahmen abgesehen schafft, nicht den Quelltext zu verändern, wenn man mit ihm eine Seite bearbeitet.)--Cirdan ± 21:54, 28. Okt. 2021 (CEST)[Antworten]

Vielen Dank für die Erläuterung! Dann kann das ja archiviert werden. --Fan-von-mir (Diskussion) 00:21, 29. Okt. 2021 (CEST)[Antworten]
Hallo Fan-von-mir, ich denke nicht, dass das unbedingt archiviert werden sollte. Ich wollte mit meinem Beitrag nur darauf hinweisen, dass die Probleme schon bekannt und kompliziert zu lösen sind – was man durchaus auch als Grund sehen könnte, sich darum zu kümmern, weil es im laufenden Entwicklungsbetrieb der Wikimedia Foundation offenbar nicht möglich ist. In jedem Fall fände ich es prima, wenn du entweder hier oder auf Wikipedia:Technik/Text/Edit/VisualEditor/Rückmeldungen das Problem mit den Leerzeichen bei Listen beschreiben könntest. Danke!--Cirdan ± 10:47, 29. Okt. 2021 (CEST)[Antworten]
Bei neue erstellten Listen im Visual Editor gibt es das Problem nicht. Problematisch wird es, wenn irgendwo innerhalb einer bereits existierenden Liste ein Stichpunkt mit Enter eingefügt wird:

(Stichpunkte 1, 2 und 3 existierten bereits vorher richtig formatiert.)

* Stichpunkt 1

*hinter „Stichpunkt 1“ war der Curor, anschließend Enter gedrückt so ist dieser Stichpunkt entstanden

*gleich nochmal Enter gedrückt

* Stichpunkt 2

* Stichpunkt 3 --Fan-von-mir (Diskussion) 14:38, 29. Okt. 2021 (CEST)[Antworten]


aktuelles Beispiel: [[4]] --Fan-von-mir (Diskussion) 15:18, 31. Okt. 2021 (CET)[Antworten]
@Fan-von-mir: Vielen Dank für die Beschreibung, ich konnte damit den Fehler nachvollziehen und habe ihn gemeldet.--Cirdan ± 23:12, 31. Okt. 2021 (CET)[Antworten]
Das Problem war tatsächlich schon in anderer Form bekannt.--Cirdan ± 17:33, 3. Nov. 2021 (CET)[Antworten]
  • Pro Ich hätte gerne nicht mehr so ein schlechtes Gewissen gegenüber Aka. --Fuchs B (Diskussion) 21:34, 31. Okt. 2021 (CET)[Antworten]
  • Pro Ja bitte! Manchmal denk ich nicht dran, nochmal den Quelltext zu checken und dann sind da diese blöden nowikis drin, die anderen Leuten wieder nur Arbeit machen. --Grizma (Diskussion) 10:07, 1. Nov. 2021 (CET)[Antworten]



Zwei-Faktor-Authentifizierung[Quelltext bearbeiten]

Was ist das Problem?

Die Accounts normaler Nutzer*innen sind normalerweise lediglich durch ein Passwort geschützt. Die meisten Nutzer*innen müssen erst einen Antrag auf 2FA stellen. 2FA gehört mitlerweile zu den typischen Sicherheitsmaßnahmen und ist insbesondere bei Plattformen, die eine große Informationsmacht haben, wie die Wikipedia, wichtig.

Wen betrifft das Problem besonders?

Momentan wird scheinbar davon ausgegangen, dass das Hacken einer passiven oder aktiven Sichterin keinen großen Schaden anrichten kann. Aber gerade diese Accounts sind attraktiv für Personen, die nicht häufig abgerufende Artikel ändern wollen.

Lösungsvorschlag
Ettablieren von 2FA beim Erreichen vom passiven Sicherrecht
Anmerkungen
{{{Anmerkungen}}}
Vorschlagende Person

Jonsonr (Diskussion) 21:48, 28. Okt. 2021 (CEST)[Antworten]

Diskussion

Sehr sinnvoll. Besser Vorsicht als Nachsicht. Und Sicherheitsprobleme merkt man erst dann wenn es zu spät ist. Danke für den Voschlag! Ich werde es womöglich erst machen, wenn ich sanft dazu gezwungen werde und glaube auch, dass das anderen so geht. Also bitte bitte! Die 2FA ist ja technisch bereits ausgerollt, also muss man das „nur“ schrittweise als Pflicht einführen. So unter dem Motto. Du willst sichten? Dann hier entlang zur 2FA --Fan-von-mir (Diskussion) 14:24, 29. Okt. 2021 (CEST)[Antworten]

ZFA setzt voraus, dass man immer ein Handy mit sich rumschleppt. Das schließt alle aus, die ein Telefon zum Telefonieren haben und alle, die nur einen Desktop haben, ist also nicht barrierefrei. Man kann also nicht schnell mal im Internetcafe was machen, wenn der Handyakku leer ist und das Netzteil nicht dabei. Wenn, dann also höchstens als Opt-in. --Jbergner (Diskussion) 22:42, 30. Okt. 2021 (CEST)[Antworten]

Dies ist phab:T166622. Einer der Hauptgründe warum die Meisten für 2FA erst einen Antrag stellen müssen ist de-facto, dass T&S nicht mit Zurücksetzungsanträgen überschwemmt werden will, siehe phab:T180648#3975239 und Beschreibung von phab:T180896. --Zabe (Diskussion) 02:12, 31. Okt. 2021 (CET)[Antworten]

Kontra Mich nervt die 2F-Authentifizierung kolossal. Bei Bankkonten und sonstigen kritischen Apps und Portalen ergibt das für mich noch einigermaßen Sinn, aber bitte nicht bei Wikipedia. Vor allem, wenn man unterwegs editiert oder an einem anderen Gerät. Es ist für Hacker wohl wenig lohnend, sich in WP-Nutzer:innenkonten einzuhacken ... --Grizma (Diskussion) 10:06, 1. Nov. 2021 (CET)[Antworten]
Wir sprechen nicht von einer Verpflichtung (soweit ich weiß), sondern davon, dass jeder der 2FA möchte, diese aktivieren kann. --Zabe (Diskussion) 17:56, 1. Nov. 2021 (CET)[Antworten]
Ich bin dagegen, das zur Pflicht zu machen. Ist hoffentlich nicht gemeint.--Himbeerbläuling (Diskussion) 22:21, 4. Nov. 2021 (CET)[Antworten]



Wikipedia-App[Quelltext bearbeiten]

Beschreibung des Themas

Verbesserungsvorschläge zum Umgang mit der Wikipedia-App

Begründung

Ich nutze die Wikipedia-App und manches funktioniert mehr schlecht als recht. Ich würde mich freuen, wenn das besser funktioniert.

Was ist das Problem?

1) Gerne schaue ich mir mobil die Beobachtungsliste an. Leider funktioniert das nicht immer. Manchmal kommt stattdessen die Meldung, dass ich mich anmelden müsse, was Quatsch ist, weil ich ja eingeloggt bin. Z.B. kann ich immer direkt auf meine Benutzerdisk zugreifen, habe also Netz und die App weiß auch, dass ich das bin. Nach Neustart klappt es manchmal, manchmal nicht. Absolut zufälliges Auftreten. Manchmal hilft es auch ein paar Minuten zu warten und es erneut zu versuchen :D Bitte bugfixen

2) In der App kann man die sog. „Artikelbeschreibung“ ändern, aber nicht am PC. Wäre doch super, wenn man das auch ohne App erledigen könnte.

3)

  • Ich bin auf der Beobachtungsliste und touche auf einen Edit auf einer Diskussionsseite
  • Ich touche oben links auf „Diskussion:[Lemma]“ um mir den Kontext nochmal zu erschließen
  • Dann stelle ich fest: Hm, ich möchte aber noch in den Artikel schauen. Oben rechts gibt es 3 Punkte und ich kann die „Seite im Browser ansehen“, warum nicht in der App? Ich möchte mir das aber ohne große Umweg in der App anschauen können.

Übrigens: Innerhalb der App kommt man von einem Artikel zur Diskussion, nur nicht andersherum

4) Leider sind Versionsgeschichten auch noch nicht in der App implementiert

5)

  • Ich habe ein paar Artikel gelesen.
  • Danach möchte ich auf meine Beobachtungsliste
  • Das geht nur indem ich ganz oft auf zurück klicke, aber auch nicht zuviel, weil sich sonst die App schließt...

Fände ich schöner, wenn die 5 Symbole unten nicht einfach verschwinden, und man direkt zur Beobachtungsliste kommen kann.

6) [nachgetragen am 3. Nov. 2021] Beim Lesen gibt es quadratische Vorschaubilder. Diese werden gewöhnlich aus dem Hauptbild oben rechts des Artikels generiert, indem diese auf ein Quadrat zugeschnitten wird. Bei besonders breiten und v.a. hohen Bildern wird das manchmal ungünstig bis problematisch: Bei Porträts sieht man z.T. mehr Ausschnitt als Stirn. Gibt man „Annalena“ in die Suchleiste ein, sieht man nicht nur den oben etwas abgeschnittenen Kopf von Annalena Baerbock, man stößt auch beim runterscrollen auf Vorschaubilder von Sportlerinnen (Annalena Grätz, Anna-Lena Grönefeld, Anna-Lena Friedsam) von Mund bis zum Oberschenkel, also quasi ohne Kopf. Man sollte im Quelltext der Artikel einstellen können, welcher Ausschnitt des Hauptbildes angezeigt werden soll. Twitter nutzt soweit ich weiß da eine Automatik, die aber auch fehlerhaft und wohl auch teilweise recht schräg sein soll, also ich bin für händische Lösung. Vieleicht wäre auch ein erster Ansatz nicht einfach den mittleren Bildteil zu nehmen, sondern bei Menschen den oberen.

Wen betrifft das Problem besonders?

Alle Autoren, die die App nutzen.

Lösungsvorschlag
keine Ahnung, bin kein Software-Profi
Anmerkungen
Kann gerne mit anderen Themenschwerpunkten vereinigt werden.
Vorschlagende Person

Fan-von-mir (Diskussion) 15:00, 29. Okt. 2021 (CEST)[Antworten]

Diskussion
Pro Die App nervt mich kolossal. Ich kann mich in die Logik nicht eindenken und verstehe bis heute nicht, wo ich welche Einstellung finde. Im Browserfenster am klassischen Monitor ist alles so schön übersichtlich eingerichtet, in der App kommt mensch erst nach Zwischenschritten in die Einstellungen oder findet überhaupt den Knopf für Login oder Logout. Finde die komplett verwirrend, weil sie nicht der Wikipedia-Logik folgt. --Grizma (Diskussion) 10:03, 1. Nov. 2021 (CET)[Antworten]
  • Pro Es werden in der App auch keine Rotlinks angezeigt. Die Bedienung ist unübersichtlich und oft mit sehr viel Zeitaufwand verbunden um die gewünschte Funktion zu finden. Auch nervt mich, dass manchmal, wenn ich im Smartphone-Browser einen Wikipedia-Artikel ansehe, sich automatisch dieselbe Seite in der App öffnet.



Bilder hochladen.[Quelltext bearbeiten]

Beschreibung des Themas

Es geht um den Vorgang des Bilderhochladens bei Wikimedia Commons und das anschließende Hochladen bzw. Einbinden der Bilder in einen Wikipedia-Artikel.

Begründung

Das Thema ist wichtig, weil eine Bebilderung von Wikipedia-Artikeln wichtig ist, besonders bei biographischen Artikeln, aber auch generell um Themen anschaulich darzustellen, und Menschen ohne viel Technikkenntnis und Zeit sollten auch einfach Bilder hochladen können, um Artikel zu bereichern.

Probleme sind z.B.: Das aufwendige Prozedere, man muss sich bei Wikimedia Commons anmelden, um dort Bilder hochzuladen, arbeitet aber eigentlich bei Wikipedia.de an einem Artikel. D.h. man muss zwischen diesen beiden Plattformen hin- und herwechseln. Einfacher wäre es, wenn man direkt auf der Seite der Wikipedia z.B. unter seinem Benutzeraccount Bilder hochladen könnte und die dann automatisch auch bei Wikimedia Commons gespeichert werden. Zweitens ist das Hochladen von Bildern sehr zeitaufwendig, es ist zwar wichtig, alle notwendigen Angaben dort zu machen, aber vielleicht könnte man die Schritte dort verkürzen/vereinfachen. Drittens kann man bei Wikimedia Commons nicht einfach seine eigenen hochgeladenen Bilder löschen, falls man ausversehen einen Fehler gemacht hat, sondern muss erst einmal rausfinden, wo man sich an wen wenden muss, um das Bild löschen zu lassen. Viertens wäre es einfacher, wenn man die Bildbearbeitung (Zuschneiden usw.) bei Wikimedia Commons nicht extra einrichten müsste, sondern wenn sie bereits in der Menüleiste angezeigt wird oder wenn man beim Einbinden eines Bildes in einen Wikipedia-Artikel dort das Bild zuschneiden könnte.

Was ist das Problem?

Ich möchte z.B. einen Wikipedia-Artikel mit einem Bild bereichern. Hierzu muss ich mich bei Wikimedia Commons anmelden, alle Schritte durchlaufen (Urheberrecht angeben, Bild mehrmals mit Stichworten versehen usw.). Dann gehe ich wieder zu Wikipedia und dem Artikel zurück und lade das Bild hoch. Es ist insgesamt einfach ein sehr zeitaufwendiger Prozess.

Wen betrifft das Problem besonders?

Alle, die Bilder hochladen möchten.

Lösungsvorschlag
Z.B.: Bilderhochladen direkt bei Wikipedia ermöglichen (damit man nicht zwei Plattformen auf einmal offen hat) bzw. beide miteinander verknüpfen, sodass man nur bei Wikipedia.de angemeldet ist und die Bilder automatisch bei Wikimedia Commons gespeichert werden. Die Schritte beim Hochladen von Bildern könnten abgekürzt werden, nicht bei den Urheberrechtsangaben, sondern bei der Beschriftung und Verschlagwortung des Bildes. Bei der Übersicht der eigenen hochgeladen Bilder auch die Möglichkeit durch einen Button geben, das Bild zu löschen.
Anmerkungen
Ich hoffe, meine Angaben sind verständlich, ich habe leider nicht so viel Zeit, um das Formular so ausführlich auszufüllen und bin auch nicht so versiert mit dieser Quelltextansicht, hoffe aber, dass mein Problem verständlich geworden ist.
Vorschlagende Person

Auguste de Gouges (Diskussion) 14:08, 30. Okt. 2021 (CEST)[Antworten]

Diskussion

Du kannst jederzeit Bilder in der DE-Wiki hochladen. Dass dir eingeredet wird, das ginge nicht, ist nur, weil MAMA möchte, dass die Bilder weltweit und von jedem in jedem Wiki nutzbar sind. --Jbergner (Diskussion) 22:34, 30. Okt. 2021 (CEST)[Antworten]

  • Pro - Ich fände es wert, sich das Problem einmal genauer anzuschauen und zu versuchen, das Bilderhochladen aus einem Artikel heraus zu erleichtern. Viele Neulinge kommen über das Schreiben von Artikeln zur WP. Ihre Artikel möchten sie gerne bebildern (und die WP will Bilder), logisch, erst dann sind sie rund. Das Hochladen ist aber noch mal eine neue Komplexitätsstufe und vielleicht eine Hürde, vor der man zurückschreckt.
Vielleicht könnte man mit Drag&Drop arbeiten? Wenn man eine Bilddatei auf einen Artikel zieht, könnte ein Dialogfeld erscheinen in Richtung "Willst Du die dieses Bild verwenden? Lade es hier bei Commons hoch" und dann öffnet sich der UploadWizzard (und die Person ist automatisch in Commons angemeldet). Richtig toll wäre natürlich auch, wenn man einfach Bilder aus Commons in einen Artikel mit Drag&Drop ziehen könnte... Gruß --Fuchs B (Diskussion) 21:48, 31. Okt. 2021 (CET)[Antworten]
  • Pro - mobiles und analoges hochladen ist mit Lizenzgewirr bei nicht-eigenen Werken sehr abschreckend-und könne für eigene Bilder noch viel einfacher sein. Auch das einbinden könnte einfacher sein-also alles, was die Hürden von veröffentlichen und einbinden niedriger machen könnte. MfG --Alter Fritz 09:42, 1. Nov. 2021 (CET)[Antworten]
  • Pro Was fehlt, ist auch ein verständlicher Dialog, der unerfahrenere Nutzende durch das Procedere führt, insbesondere wenn ich noch Freigaben von Urheber:innen einholen und diese an permissions senden muss. So eine Art integrierte Checkliste oder Standard-Verfahren. Das müssen Menschen, die Anfänger:innen betreuen extrem aufwändig erklären. Wir sind schon am Überlegen, so eine Checkliste handzustricken, offenbar gibt es nirgends eine Schritt-für-Schritt-Anleitung, wie das Vorgehen ist, wenn Bilder Dritter hochgeladen werden. --Grizma (Diskussion) 09:54, 1. Nov. 2021 (CET)[Antworten]
  • Pro Ich als "Anfängerin" (obwohl jetzt mehr als ein Jahr aktiv) möchte das unterstützen. Ich hab mehrere Anläufe genommen, selbst Bilder hochzuladen oder die Rechte zu besorgen, hab es dann aber aufgegeben, weil es wirklich höllisch kompliziert ist. Bei einer Vereinfachung würde ich mich wieder mehr um Bilder kümmern, versprochen! --Helga Wiki (Diskussion) 12:57, 1. Nov. 2021 (CET)[Antworten]
  • Pro Wir brauchen einen funktionierenden, nativen Uploader, der auch institutionelle Nutzungen zulässt. --Gnom (Diskussion) Wikipedia grün machen! 20:25, 15. Nov. 2021 (CET)[Antworten]



"wieder editierbare" Bearbeitungszusammenfassungen[Quelltext bearbeiten]

Beschreibung des Themas

Hilfe:Zusammenfassung und Quellen

Begründung

Ich bin mir sicher, dass ich nicht der Einzige bin, der eine Bearbeitung vornimmt und dann in der Bearbeitungszusammenfassung einen Tippfehler, einen grammatikalischen Fehler usw. bemerkt, und da diese nicht wieder editierbar sind, bleibt es für immer in dieser Form. Glaubt ihr, dass Bearbeitungszusammenfassungen wieder editierbar sein sollten? Ich weiß nicht, ob für unbegrenzte Zeit, für 24 Stunden, 60 Minuten oder vielleicht 10 Minuten nach der Bearbeitung, aber es wäre toll, wenn man die Bearbeitungszusammenfassungen einfach abändern könnte.

Was ist das Problem?

siehe oben

Wen betrifft das Problem besonders?

siehe oben

Vorschlagende Person

Degon Trojvil (Diskussion) 21:02, 30. Okt. 2021 (CEST)[Antworten]

Diskussion

Kontra später nicht mehr verfälschbare Z&Q sind vor ihrer Speicherung der Zeitpunkt, sich in Ruhe zu überlegen, was man da getan hat und dass man dazu steht. Für jetzt und immer. --Jbergner (Diskussion) 22:31, 30. Okt. 2021 (CEST)[Antworten]

Kontra die Korrektur von Tipp- oder Grammatikfehler in Zusammenfassungen sind unerheblich, wie aber Jbergner schon richtig betont, gibt es auch systemische Zusammenfassungen, die nicht verfälscht werden dürfen (z.B. Sperr-, Schutz- oder Entscheidungsbegründungen). Aber es gibt da durchaus noch mehr. – Doc TaxonDisk. 08:01, 1. Nov. 2021 (CET)[Antworten]
Kontra Das ist ja nur interne Kurz-Info über gemachte Änderungen und kommt nicht an die Öffentlichkeit. --→KPF&Blabla← 08:36, 1. Nov. 2021 (CET)[Antworten]
Kontra Öffnet Tür und Tor für Verfälschungen. Selbst bei einem Zehn-Minuten-Zeitfenster. Man denke an einen Edit-War, in dem es Schlag-auf-Schlag geht. --Grizma (Diskussion) 09:57, 1. Nov. 2021 (CET)[Antworten]
Pro Es ist möglicherweise schwierig, d.h. nicht leicht mit der vorhandenen Software zu lösen. Die obigen Contra-Argumente laufem m.M.n. darauf hinaus, dass die nachträglichen Änderungen sinnvoll dokumentiert werden müssten, was vermutlich nur möglich ist, wenn gleichzeitig eine (für den Artikelleser ungeänderte) neue Artikelversion geschaffen wird und dann die Version mit der feherhaften Zusammenfassungszeile versteckt wird. Das Anliegen wird aus den oben genannten Gründen wohl abgelehnt werden. Trotzdem ist es berechtigt und ich möchte es unterstützen: das Problem an sich existiert, es ist lästig und zumindest im Prinzip mit gewissem Aufwand (vermutlich Bestätigung durch einen Administrator) auch lösbar. Sehr ärgerliche Fehler (Tipp/Grammatik u.A.) in der Zusammenfassung hatte ich jedenfalls auch schon… --Nick B. (Diskussion) 13:23, 13. Nov. 2021 (CET)[Antworten]



Entrümpelung der Kategorien[Quelltext bearbeiten]

Was ist das Problem?

Es gibt etliche überladene „Monster-Kategorien“

Ich bin mir sicher, dass da nicht einmal alle erfasst und entsprechend kategorisiert sind.
Kategorie:Diverse könnte (immer noch) übersichtlich sein, gibt es aber nicht.

Das sind nur exemplarische Bespiele. So etwas findet sich in sehr vielen Themenkreisen.

Wen betrifft das Problem besonders?

Alle, insbesondere Suchende

Lösungsvorschlag
Ich schlage vor, die Anzahl der aller Kategorie-Einträge auf ein festzulegendes Höchstmaß zu begrenzen (über 2 Bildschirmseiten wird es nmuM schon zu viel). Sollte es sinnvoll sein, konnte man passende Unterkategorien Anlegen (‚Mann mit Bart‘, ‚Mann mit Glatze‘, ‚Mann der Geschichte‘, der Wirtschaft, Politik ...), die ggf. selbst wieder begrenzt werden und sich dann auf weitere Unterkategorien verzweigen.
Anmerkungen
Ich kann mir gut vorstellen, dass ein Bot alle relevanten Kategorie-Einträge pauschal löscht. Die Autoren und Beobachter werden dann schon sinnvolle Einträge in entsprechende Unterkategorien machen. Bleibt es aus, wird es nicht so wichtig und somit entbehrlich sein.
Vorschlagende Person

KPF&Blabla← 10:22, 31. Okt. 2021 (CET)[Antworten]

Diskussion

Hier falsch, kein "technischer Wunsch". --Jbergner (Diskussion) 10:28, 31. Okt. 2021 (CET)[Antworten]

Kann man das anders, als durch ‚technische‘ Eingriffe realisieren? Erbitte sachliche und realisierbare Hinweise auf ein entsprechendes Portal. --→KPF&Blabla← 12:45, 31. Okt. 2021 (CET)[Antworten]
Wikipedia:Projektdiskussion --Mabschaaf 15:27, 31. Okt. 2021 (CET)[Antworten]
Wohl keine technische Lösung möglich, dafür bräuchte es eine Restrukturierung, eine Mammut-Aufgabe. --Grizma (Diskussion) 09:58, 1. Nov. 2021 (CET)[Antworten]

Unabhängig einer technischen Lösung. Das ist so nicht erwünscht. Wir machen das bewusst so, damit die Schnittmengensuche funktioniert. Wenn du Schweizer Männer, die Fussballer sind und nebenbei auch Politiker waren, suchen möchtest, suchst du nach der Schnittmenge Kategorie:Mann, Kategorie:Schweizer, Kategorie:Fußballspieler (inkl. Unterkat.), Kategorie:Politiker (inkl. Unterkat.) und hast gleich alle. Mit deiner Lösung müsstest du, vorausahnend, dass jemand genau das möchte, eine Kategorie Kategoire:Männliche Fußballspieler Schweizer Nationalität, Politikerfunktion ausübend anlegen. --Filzstift (Diskussion) 12:03, 3. Nov. 2021 (CET)[Antworten]

Kann mich Kpfiwas Idee nur weitgehend anschließen. Diese ganze Kategosiererei ist völlig schwachsinnig und nur ein Zeichen bzw Ausdruck für typisch teutsches Schubladendenken. Habe die noch nie für irgend etwas gebrauchen können. Leser*innen aus dem RL werden da erst recht nix damit anfangen können. Aber die Kategosiererei ist natürlich heiß begehrt bei allen Querulanten und allen Quer-Querulanten und allen Trolls und allen selbsternannten Besserwissern etc. pp. Man kann dort eher unauffällig wochenlange Grabenkämpfe mit allem was das Herz begehrt, wie EWs, VMs usw vom Zaun brechen oder sich einmischen. Mein Wunsch an die Techniker*innen hier wäre einen Bot zu basteln der sämtliche Kategorien so wie die Links dazu aus der gesamten deWP raus putzt.--Ciao • Bestoernesto 06:53, 4. Nov. 2021 (CET)[Antworten]



Vorlage bearbeiten im VisualEditor[Quelltext bearbeiten]

Was ist das Problem?

Wenn ich eine Vorlage wie Mehrspaltige Liste oder Infobox bearbeite, muss ich in sehr kleine Felder z.T. komplexe Syntax einfügen.

Wen betrifft das Problem besonders?

Alle die Inhalte in Vorlagen editieren

Lösungsvorschlag
Es wäre optimal wenn die Bearbeitung von Vorlagen ohne eigenes Fenster sondern so wie im VisuEditor auch direkt an der Stelle vorgenommen werden könnte.
Anmerkungen
kann gerne mit anderen Abschnitten zusammengefasst werden.
Vorschlagende Person

Fan-von-mir (Diskussion) 15:59, 31. Okt. 2021 (CET)[Antworten]

Diskussion
Das Problem ist, dass Vorlagen das Thema der Technischen Wünsche in der letzten Runde war. Ich fände das auch prima, wenn im Visual Editor an Ort und Stelle bearbeitet werden könnte, gehe dann aber einfach in den Quelltext, was auch kein großer Aufwand ist. --Grizma (Diskussion) 10:00, 1. Nov. 2021 (CET)[Antworten]



Vereinfachte Eingabe von ähnlichen Einzelnachweisen[Quelltext bearbeiten]

Was ist das Problem?
Wen betrifft das Problem besonders?

Schreibende

Lösungsvorschlag
Keine
Anmerkungen
Ich finde die Unterstützung zur Erstellung von Einzelnachweisen ist vorsintflutlich
Vorschlagende Person

Hfst (Diskussion) 12:15, 1. Nov. 2021 (CET)[Antworten]

Diskussion

In der englischsprachigen Wikipedia gibt es dazu eine Vorlage, die zum Verweis auf die Seite einer schon genannten Literaturstelle dient: das Template en:Template:Rp. Sie wird dort über 45.000 mal genutzt. Dann erscheint im Artikeltext die Seitennummer direkt nach dem hochgestellten Link zu Literaturangabe (z.B. [2]:53 verweist auf Seite 53 der Literatur [2]). Für diese Art des Verweises kenne ich kein Beispiel außerhalb der Wikipedia, d.h. das ist bei wissenschaftlichen Literaturangaben nicht etabliert. Aber ich finde, diese neue Methode hat durch die Knappheit der Angaben durchaus Eleganz. Wenn es auf Englisch funktioniert ist vermutlich die technische Übertragung auf die deutschen Seiten kein Problem.--Nick B. (Diskussion) 13:43, 13. Nov. 2021 (CET) Vielleicht etwa konkreter: bei LaTeX gebe ich einmal die bibliographischen Daten an. Und dann verweise ich auf das Dokument und kann als optionales Argument sowas wie „S.42“ ergänzen. Und dann steht da [63, S.42] also ähnlich wie oben beschrieben. Und das finde ich auch in ingenieurwissenschaftlichen Literatur. Was das Argument „nicht etabliert“ angeht, so ist auch das Verbot von „aaO“ oder „ebenda“ nicht etabliert; also also kein Argument. Diese oder eine ähnliche Bequemlichkeit wünsche ich mir.—Hfst (Diskussion) 15:48, 13. Nov. 2021 (CET)[Antworten]

Pro Ich fände es prima, technische Unterstützung für eine einfache Seitenangabe zu haben. --Bärbel Miemietz (Diskussion) 21:12, 14. Nov. 2021 (CET)[Antworten]



Fehler beim Einfügen eines Wikipedia-Links in einen Text außerhalb von Wikipedia[Quelltext bearbeiten]

Was ist das Problem?

Wikipedia-Link mit abschließender Klammer "verlieren" trotz mitkopierter abschließender Klammer ebendiese Klammer (sie wird zwar angezeigt, ist aber nicht unterstrichen und somit außerhalb des Links -> Effekt: Wird der WP-Link aufgerufen, kommt es zu einer Fehlermeldung und NICHT zum gewünschten Beitrag, da ja die abschließende Klammer fehlt.

Wen betrifft das Problem besonders?

Sehr viele von mir eingefügte Wikipedia-Links, wie etwa

Lösungsvorschlag
Keine Ahnung.
Anmerkungen
Vermutlich gibt es hier den "Vorführeffekt", dass alles klappt mit den beiden Beispiel-Links. Doch das ist ja in Wikipedia; das Problem tritt bei Texten außerhalb von Wikipedia, Wikimedia etc. auf ...
Vorschlagende Person

Ghostwriter123 (Diskussion) 17:19, 2. Nov. 2021 (CET) Ghostwriter123 (Diskussion) 17:19, 2. Nov. 2021 (CET)[Antworten]

Diskussion

Kannst du eine Schritt-für-Schritt-Anleitung geben, wie der Fehler reproduziert werden kann? In welchem Programm befindet sich der „Text außerhalb der Wikipedia“ und welchen Browser benutzt du?--Cirdan ± 20:06, 2. Nov. 2021 (CET)[Antworten]

Kann das nicht nachvollziehen. Habe beide URLs mal in ein MS-Office Dokument als auch in eine E-Mail, die ich anschließend an mich selbst schickte, eingefügt. In allen Fällen war der kompl. Link inkl. der schließenden Klammer unterstrichen und ließ sich auch ordnungsgemäß ohne Fehleranzeige aufrufen. Möglicherweise ist dir ja bei der Kopiererei irgendwie ein Leerzeichen vor die schließende Klammer geraten, dann wird sie auch von jeglicher Software nicht mehr als Bestandteil der URL wahrgenommen.--Ciao • Bestoernesto 06:25, 4. Nov. 2021 (CET)[Antworten]



Unterdrückung automatisches Inhaltsverzeichnis auf Wikisource-Seiten[Quelltext bearbeiten]

Was ist das Problem?

Bei Anlagen von Index-Seiten wird ab 4 Überschriften das Inhaltsverzeichnis automatisch generiert. Dies ist aber bei den Einzelseiten unnötig und nervt. Dies kann mit dem händischen Eintrag von __NOTOC__ in der Kopfzeile unterdrückt werden. Beispiel: s:Seite:Die Bereitung warmer und kalter Bowlen.pdf/86

Wen betrifft das Problem besonders?

Wikisource-Nutzer

Lösungsvorschlag
Anordnung eines Buttons in der Bearbeitungsseite auf der Bearbeitungsleiste, ähnlich zu den dort schon vorhandenen.
Anmerkungen
Wenn das Problem gelöst ist, kann sich der Bearbeiter/die Bearbeiterin mit den Rezepten auf der verlinkten Seite einen schönen Glühwein machen, die klassische Win-Win-Situation.
Vorschlagende Person

A. Wagner (Diskussion) 18:12, 2. Nov. 2021 (CET)[Antworten]

Diskussion

Ich kann das Problem nicht direkt nachvollziehen, auf der von dir verlinkten Seite sehe ich weder ein Inhaltsverzeichnis noch __NOTOC_ im Quelltext, aber ich kenne mich mit den Begriffen und der Systematik von Wikisource leider auch überhaupt nicht aus. Aber wäre es eine Lösung, die Sache umzudrehen, also nie ein Inhaltsverzeichnis zu zeigen, außer es wird per __TOC__ explizit gewünscht? Ich denke, das sollte man in MediaWiki ohne Änderungen an der Software konfigurieren können, indem man die Mindestzahl der Überschriften, ab der automatisch ein Inhaltsverzeichnis erzeugt wird, extrem hoch (quasi auf unendlich) einstellt.--Cirdan ± 20:05, 2. Nov. 2021 (CET)[Antworten]

Das __NOTOC__ steht in der sog. Kopfzeile, diese siehst Du, wenn Du die Seite bearbeitest: [5]. Ich nehme es hier s:Seite:Die Bereitung warmer und kalter Bowlen.pdf/87 jetzt mal raus, dann siehst Du das Ergebnis. --A. Wagner (Diskussion) 21:58, 2. Nov. 2021 (CET) PS: Dein Vorschlag, nie ein Inhaltsverzeichnis anzuzeigen, es sei denn, es wäre gewünscht, könnte für Wikisource praktikabel sein, denn wir brauchen das Inhaltsverzeichnis in Quellentexten nicht, da die Quelle original wiedergegeben werden muss. Sollten wir eins brauchen (z. B. in Themen- oder Autorenseiten), dann muss es mit __TOC__ erzeugt werden. Aber... falls so eine Änderung käme, müsste das dann in allen Seiten nachgeführt werden, wo es derzeit nicht vorhanden ist. Ein immenser, nicht zu realisierender Aufwand...--A. Wagner (Diskussion) 22:05, 2. Nov. 2021 (CET)[Antworten]
Deine Idee ist super, wenn man diese auf den Namensraum Seite: beschränkt. --A. Wagner (Diskussion) 12:47, 5. Nov. 2021 (CET)[Antworten]



Eigene Top-Level-Domain für alle Wikipedias[Quelltext bearbeiten]

Was ist das Problem?

Die Wikipedia URLs sind ja grundsätzlich recht lang (xx.wikipedia.org/wiki/)). Es wäre sinnvoll eine Top-Level-Domain (z.B. .wp) als forwarder (nicht als shortener) für Wikipedias zu betreiben.

de.wp/Top-Level-Domain

wäre ja viel kürzer als :

de.wikipedia.org/wiki/Top-Level-Domain

Das wichtigste wäre dass man die kurze URL noch selber lesen (was mit bitly und co nicht möglich ist) und die URL, ähnlich wie ein hashtag oder einem interwiki, in den Satz einbauen kann, anstatt eine (short)-URL anzuhängen (egal ob auf twitter oder einer mail)

Der Legende nach ist unter dem #Grabhügel https://de.wp/Raknehaugen ein König zwischen zwei weißen Pferden begraben worden.

anstatt :

Der Legende nach ist unter dem #Grabhügel Raknehaugen ein König zwischen zwei weißen Pferden begraben worden. https://de.wikipedia.org/wiki/Raknehaugen
Wen betrifft das Problem besonders?

Alle Internetnutzer die auf die Wikipedia verlinken möchten, vor allem in Kurznachrichtendiensten.

Lösungsvorschlag

Betreiben müsste diese TLD vermutlich die Wikimedia Foundation, ich denke technisch wäre das möglich.

Die ICANN will anscheinend 185.000 $ für eine sponsored TLD, aber vielleicht gibt es die TLD für ein nonprofit günstiger.

Ich bin darauf hingewiesen worden das die ICANN 2-stellige TLDs nur an Länder und die EU (.eu) vergibt, aber vielleicht bekommt man für eine sooo große "Webseite" und zentrale Ressource im Netz eine Ausnahme;)

Diese kurzen URLs sollen nicht die klassische URL (de.wikipedia.org/wiki/Top-Level-Domain) als canonical URL ersetzen, sondern nur darauf weiterleiten.
Anmerkungen

Ich habe diesen Vorschlag schon einmal auf der VereinDE-l und 2017 gestellt.

Auf meta.wikimedia.org gibt es einen Special:UrlShortener, dieser würde aber "unlesbare", wenn auch kurze, shortlinks erzeugen (https://w.wiki/4Kmi anstatt de.wp/Raknehaugen).
Vorschlagende Person

vanGore 18:55, 2. Nov. 2021 (CET)[Antworten]

Diskussion

Technische Wünsche 2017 Eigene Top-Level-Domain für alle Wikipedias



Bildbeschreibungen für Blinde (automatisiert) einbinden[Quelltext bearbeiten]

Beschreibung des Themas

Bildbeschreibungen ermöglichen blinden und sehbeeinträchtigten Menschen Zugang zu bildhaften Darstellungen wie Gemälden, Fotografien, Diagrammen und Schaubildern. Bisher müssen diese Beschreibungen einzeln eingefügt werden.

Begründung

Alt-Texte (kurz für Alternativtexte) sind kurze Bildbeschreibungen, kurze sprachliche Übersetzungen visueller Inhalte im Internet, die blinden Benutzern von Hilfsmitteln wie Screenreadern anstelle des Bildes vorgelesen werden. Sie sind eine wichtige Bedingung für ein barrierefreies Internet. Sie können jedoch auch anstelle des Bildes im Browser angezeigt werden, wenn z. B. die Internetverbindung zu langsam ist, um das Bild zu laden, oder wenn Bildanzeige zum beschleunigten Laden oder Einsparen von Datenvolumen deaktiviert ist, sowie von textbasierten Browsern. Mit Alt-Text versehene Bilder können von Suchmaschinen besser gefunden werden.

Was ist das Problem?

Bildhafte Darstellungen wie Gemälden, Fotografien, Diagrammen und Schaubilder sind für blinde und sehbehinderte Menschen in Wikipediaartikeln oftmals nicht zugänglich. Die Bildbeschreibung (Alt-Text) muss momentan manuell im Quelltext zu den jeweiligen Bildern im Artikel eingetragen werden. Einfacher wäre es, wenn beispielsweise direkt beim Hochladen des Bildes/Fotos diese Möglichkeit gegeben wäre, welche dann von dort aus auch für andere Seiten/Artikel weiter verwendet werden können.

Wen betrifft das Problem besonders?

Blinde und Menschen mit Sehbehinderungen.

Lösungsvorschlag
Alt-Texte (kurz für Alternativtexte) automatisiert beim Hochladen der Bilder, Grafiken etc. in Form einer Vorlage, welche vielfach weiterverwendet werden kann, einbauen. Beispielsweise direkt im Hochladevorgang mit eigenem Feld, wie die reguläre Bildbeschreibung, der entsprechenden Medien. So wird ein Standart geschaffen und es muss nicht in jedem Artikel immer wieder neu diese Ergänzung manuell eingefügt werden. Ideal wäre, wenn direkt bei Commons ein Eingabefeld, wie auch für die reguläre Bildbeschreibung, dafür geschaffen werden könnte. So ließe sich das mehrfache Eingeben der Bildbeschreibung vermeiden und evtl. wird so auch ein Bewusstsein geschaffen, diese Möglichkeit zukünftig öfter zu nutzen.
Vorschlagende Person

Zartesbitter (Diskussion) 19:56, 3. Nov. 2021 (CET)[Antworten]

Diskussion
Pro Top, ein Eingabefeld gleich in den Commons, so ist es immer hübsch im Fokus. Bin dafür.
Pro Ich bin SEHR für eine klare, präzise, informative Bildbeschreibung, allerdings bin ich Kontra noch eine weitere Beschreibung. Es gibt ja schon drei: eine Bescheibung, eine Kurzbeschreibung und eine "Motivauswahl"-Beschreibung bei den strukturierten Daten. Und das alles in mehreren Sprachen - so man es für sinnvoll hält. Lässt sich daraus vielleicht eine einzige Beschreibung machen? Und dann möglicherweise sogar technisch verhindern, dass eine Datei hochgeladen wird, die keine richtige Bildbeschreibung hat? --Bärbel Miemietz (Diskussion) 21:31, 14. Nov. 2021 (CET)[Antworten]



3-spaltig, bitte[Quelltext bearbeiten]

Was ist das Problem?

Völlig leseunfreundlich

Wen betrifft das Problem besonders?

Jeden Leser/Leserin

Lösungsvorschlag
2 oder 3 Spalten einführen
Anmerkungen
Der Eindruck einer Seite erzählt von Unbeholfenheit
Vorschlagende Person

--Wikipus (Diskussion) 00:33, 4. Nov. 2021 (CET)[Antworten]

Diskussion



Den Schalter [Abrufstatistik] in die Liste der Werkzeuge in der linken Spalte integrieren[Quelltext bearbeiten]

Was ist das Problem?

So gut wie auf allen Seiten (Artikel-, WP:-, Projekt, Hilfe-, Disk-Seiten etc.) gibt es in der schmalen linken Spalte (ich nenne sie "Dashboard") unter anderem auch eine kleine Werkzeugliste: Werkzeuge

  • Links auf diese Seite
  • Änderungen an verlinkten Seiten
  • Datei hochladen
  • Spezialseiten
  • PermaLink
  • Permalink (Artikel)
  • Seiten­informationen
  • Artikel zitieren
  • Wikidata-Datenobjekt

Nur den Schalter "Links auf diese Seite" benötige und benutze ich immer wieder mal, den Rest so gut wie nie. Aber so richtig häufig, vor allem bei Diskussionen um das richtige Lemma oder bei Relevanz-Fragen in LAs benötige und benutze ich das Werkzeug bzw den Schalter [Abrufstatistik]. Dieses Tool befindet sich jedoch seltsamer Weise im tiefen Keller gaaanz unten auf jeder Seite und manch eine Seite ist ziemlich lang. Z.B.: beim Artikel Student muss ich 32 Bildschirmhöhen auf meinem Laptop nach unten scrollen, um dort an das Tool [Abrufstatistik] zu gelangen, bei Europäische Union 76 Bildschirmhöhen.

Wen betrifft das Problem besonders?

Zunächst natürlich alle Benutzer*innen, die aus welchen Gründen auch immer, das Werkzeug benutzen möchte. Für reine Leser*innen im RL sind alle aktuell angezeigten Werkzeuge in der Liste vermutlich völlig uninteressant. Aber wie häufig ein Artikel zu bestimmten Zeiten aufgerufen wird, würde sie dann vielleicht doch interessieren. Nur ahnen die natürlich nicht, dass es am untersten Ende der Seite einen Schalter dafür gibt.

Lösungsvorschlag
Für einen Webdesign versierten Menschen dürfte das Umpositionieren bzw Einreihen des Schalters in die vorhandene Werkzeugliste eine der leichtesten Übungen sein. Und da es wohl das einzige auch für reine Leser*innen interessante Werkzeug ist, würde ich es an die oberste Position noch vor [Links auf diese Seite] setzen.
Anmerkungen
Ausschließlich auf Seiten im ANR gibt es ganz unten neben [Abrufstatistik] auch noch ein Tool namens [Autoren]. Da diese ja bereits in der Versionsgeschichte feststellbar sind, hab ich da noch nie reingeschaut. Aber man kann dieses Tool bei der Gelegenheit natürlich auch nach in die Werkzeugliste verschieben, am besten an letzter Stelle
Vorschlagende Person

Ciao • Bestoernesto 04:03, 4. Nov. 2021 (CET)[Antworten]

Diskussion

2 Anmerkungen, die vermutlich Gegenrede sind: (1) Ich habe auf meinem Schoßrechner (Laptop) eine Taste mit Aufschrift „Ende“, die bei mir das Scroll-Problem zufriedenstellend löst. (2) Die Funktionen „Autoren“ und „Abrufstatistik“ rufen so weit ich weiß einen externen Dienstleister auf, „Links auf diese Seite“ etc sind meines Wissens Wikimedia-intern, vielleicht macht das einen Unterschied. --Himbeerbläuling (Diskussion) 22:18, 4. Nov. 2021 (CET)[Antworten]



Beobachtungsliste als Email und Feed mit diff.[Quelltext bearbeiten]

Beschreibung des Themas

Die Beobachtungsliste als Email, sowie der als feed enthält derzeit nur das Lemma, die Bearbeitungszusammenfassung und den Autor.

Es wäre besser beide format würden auch die Änderung an sich als diff mitliefern. Evtl als Zusatzoption mit unterschiedlichen Ausgabeformaten: normal diff (>), unified diff (+) oder der HTML-Tabelle wie in der Mediawiki Webansicht.

Begründung

Man kann bereits in der mail oder im feeditem den Änderungsinhalt sehen.

Was ist das Problem?

Man muss zusätzlich die Seite mit der diff Ansicht anklicken, das stört den Lesefluss in der mail oder im feedreader.

Wen betrifft das Problem besonders?

Alle mail und feed User.

Vorschlagende Person

greetz vanGore 13:54, 5. Nov. 2021 (CET)[Antworten]

Diskussion



Erleichterung für Neulinge[Quelltext bearbeiten]

Beschreibung des Themas

Als langjähriger Editor habe ich mich an diverse Problemchen gewöhnt. Das aber schreckt neue Editoren ab. Sollte irgendetwas fehlen, wäre es gut eine Warnmeldung zu generieren, das Abspeichern aber trotzdem möglich sein. Noch besser wäre es, wenn dann an die Qualitätssicherung ein Hinweis weitergeleitet wird.

Begründung

Wikipedia lebt von Editoren. Gerade neue Editoren werden aber von Fehlermeldungen abgeschreckt

Automatisches einfügen von Weblinks bei Quellenangaben

Es sollten alle Dinge z.B Banner "Belege fehlen" oder "Qualitätssicherungsseite" usw. durch anklicken eingebunden werden können.

Was ist das Problem?

Beispiel Weblink Wysiwyg Editor Weblink einfügen

"Belegen" aufrufen

Link eingeben z.B https://www-baseball--reference-com.translate.goog/bullpen/Jürgen_Helmig

Ergebnis: Wir konnten kein Zitat für dich erstellen. Du kannst eines manuell erstellen, indem du den Reiter „Manuell“ oben benutzt.

Wenn dann der Ungeübte die Eingabemaske sieht gibt er oftmals auf

Wen betrifft das Problem besonders?

Neue Wikipedianer

Anmerkungen

Sicher gibt es noch andere Hürden für Einsteiger, eventuell können hier andere noch Beispiele dazu beitragen.

Leider hört man selten etwas von denen die sich abschrecken lassen. Wir müssten also aufmerksam sein und solche Dinge, die Routiniers inzwischen als normal empfinden hier zusammenfassen.
Vorschlagende Person

Knut Krüger (Diskussion) 16:02, 5. Nov. 2021 (CET)[Antworten]

Diskussion

Siehe auch

--M2k~dewiki (Diskussion) 16:07, 5. Nov. 2021 (CET)[Antworten]



Fehler im VisualEditor beheben: Mängel des Editors für chemische Formeln[Quelltext bearbeiten]

Was ist das Problem?

Der Formeleditor für chemische Formeln, den man im Werkzeug VisualEditor aufrufen kann (unter Einfügen > Mehr > Chemische Formel), hat eine Reihe von z.T. gravierenden Fehlern und fehlerhafter oder zumindest ungünstig gewählter Beispiele.

Es geht um ein Werkzeug, das bei der Erstellung korrekt gesetzter Formeln helfen soll. Da ist es schlecht, wenn das Werkzeug Beispiele zeigt, die zu falsche Ergebnissen führen. Da es um den korrekten Formelsatz geht, ist ein nicht hochgestelltes Minuszeichen (bei der Angabe einer Ladung) hier als schwerer Fehler zu werten. Didaktisch ist es mangelhaft, wenn die Beispiele fehlerhaft oder irreführend sind.

Beispielsweise versteht man unter dem Aggregatzustand eigentlich den temperaturbedingten Wechsel zwischen Fest, Flüssig und Gasförmig. Im Formeleditor finden sich aber nur Beispiele zum gelösten Zustand (mit (aq) als Bezeichnung für wässrige Lösung). Ein gravierender Fehler im Formeleditor ist in der Formel des gelösten Carbonats: Mit den Beispielen des Editors erhält man dafür , richtig wären oder noch besser . Eine umfangreiche Liste dieser und vieler weiterer Fehler und Verbesserungsmöglichkeiten habe ich im Juni 2020 dort bei den Rückmeldungen zum VisualEditor gemeldet. Da die genannten Probleme immer noch alle ungelöst sind melde ich sie hier.

Wen betrifft das Problem besonders?

Das Problem trifft Nutzer, die mit Hilfe des VisualEditors chemische Formeln oder Reaktionsgleichungen erstellen wollen. Es betrifft besonders die Nutzer, die wenig Erfahrung mit Formelsatz und mit der korrekten Schreibweise chemischer Formeln haben. Das sind vermutlich genau diejenigen, die die Formeln nicht als Quelltext schreiben, sondern dafür gerne ein Hilfswerkzeug nutzen wollen. Schlecht, wenn das Werkzeug mangelhaft ist.

Lösungsvorschlag

1. Fehlerhafte oder irreführende Beispiele und Beschriftungen bitte durch korrekte bzw. geeignetere ersetzen.

, oder statt (nicht existentes Teilchen)
statt (nicht existentes Teilchen)
statt (sinnvolle Formel statt Quatsch)
oder statt (zur didaktischen Verbesserung)
Ladungen statt Aufladungen
Weitere Punkte hier.

2. Fehlerhafte Beispiele wie (die Variable n sollte kursiv gesetzt werden) bitte entfernen, solange sie vom Editor nicht richtig dargestellt werden können. Das betrifft insbesonders aufrecht zu beschriftende Reaktionspfeile.

3. Für die Fälle, die mit dem chem-Tag problematisch sind, beispielsweise bei der Reaktionsgleichung : wäre es sinnvoll und möglich, dass der Formeleditor sie – analog zur Arbeit mit Quelltext wie hier beschrieben – mit dem math-Tag setzt? Mit diesem erhält man auch den korrekten Formelsatz von .

4. Die schon lange bekannten technischen Probleme des chem-Tags beheben.
Anmerkungen

Wie hier bereits andiskutiert wurde lassen sich die Probleme in zwei Kategorien einteilen:

1.) ungünstige und fehlerhafte Beispiele und Beschriftungen und sprachliche Mängel, die man vermutlich relativ leicht verbessern könnte.

2.) Mängel, die auf technischen Problemen des chem-Tags beruhen. Diese lassen sich vermutlich nicht so leicht beheben. Dazu gehören beispielsweise die nicht problemlos funktionierenden aufrechten Beschriftungen von Pfeilen. Zu schlecht oder nicht funktionierenden Funktionen sollte man dann aber wenigstens keine Beispiele bringen.
Vorschlagende Person

Nick B. (Diskussion) 14:09, 13. Nov. 2021 (CET)[Antworten]

Diskussion

Pro  — --Wilhelm (Diskussion) 09:10, 20. Nov. 2021 (CET)[Antworten]



Genaue Wortsuche, die Groß- und Kleinschreibung beachtet[Quelltext bearbeiten]

Beschreibung des Themas

Ich suche Tippfehler. Oft muss ich dabei genau nach einer Schreibweise eines Wortes suchen und die Groß- und Kleinschreibung berücksichtigen. Die Such-Syntax ~"Wort" ist schon sehr hilfreich, unterscheidet jedoch nicht die Groß- und Kleinschreibung, so dass die Falschschreibung in vielen false positives untergeht und nicht effektiv gefunden wird.

Begründung

Textqualität trägt zur Reputation von Wikipedia bei. Sie steigt, wenn sich genaue Schreibweisen von Wörtern leicht finden lassen. Denn das ist die Voraussetzung für die Korrektur.

In Wikipedia wimmelt es von Tippfehlern (Zusammenerbeit statt Zusammenarbeit, Dictionery statt Dictionary, Seminer statt Seminar, völling statt völlig). Das sind Tausende. Zwar gibt es die Suchmöglichkeit im Volltext (insource:/völling/), aber oft ist der Server überlastet oder nach 30 Anfragen wird man nicht mehr bedient, weil das ja auch „teuer“ ist. Wikipedia nach ~"völling" durchsuchen geht hingegen fix, hilft meist schon, reicht oft nicht (Völling ist häufig und korrekt, völling nicht, geht aber im Suchergebnis unter).

Was ist das Problem?
  • Häufig ist die Groß- und Kleinschreibung wichtig, z. B. bei einar statt einer. Da gibt die Suche dann tausend richtige Schreibungen des Vornamens Einar zurück – die eigentlich gesuchte Kleinschreibung lässt sich nicht effektiv finden.
  • Ich suche (um im Beispiel zu bleiben) nach insource:/ einar /. Das dauert bestenfalls lange (zum Beispiel 20 Sekunden), oder es wird nur eine „Teilliste“ ausgegeben (0 Einträge), weil der Server überlastet ist. Je häufiger ich suche, desto weniger erfolgreich bin ich, weil offenbar die Priorität mit jeder insource-Anfrage herabgesetzt wird. Meine jetzige Lösung ist unbefriedigend: Ich suche lokal im Volltext (verlässlich, aber nur ein Wort in zwei Minuten, Lüfter springt an).
Wen betrifft das Problem besonders?

Betroffen ist insbesondere die Community, die sich um Textqualität sorgt.

Lösungsvorschlag
Für die genaue Wortsuche gibt es offenbar bereits eine Wortdatenbank, die die Groß-/Kleinschreibung nicht berücksichtigt. Es kann also nicht so aufwändig sein, eine weitere Wortdatenbank anzulegen, die Groß- und Kleinschreibung berücksichtigt, und diese über eine bestimmte Syntax (Vorschlag: ~~"suchtext") verfügbar zu machen. Oder das Ergebnis von ~"suchtext" (liefert Groß- und Kleinschreibung) wird nach Großschreibung bzw. Kleinschreibung gefiltert.
Vorschlagende Person

Frühlingsmädchen (Diskussion) 13:16, 14. Nov. 2021 (CET)[Antworten]

Diskussion



Tote Links (nach bestimmten Kriterien) ermitteln[Quelltext bearbeiten]

Beschreibung des Themas

Es ist kein Geheimnis, dass die Wikipedia-Artikel jede Menge tote Links enthalten. Die Gründe dafür sind vielfältig und an dieser Stelle nicht relevant. Die Anzahl der toten Links wächst stetig, deren Pflege und Beseitigung hinkt aber hinterher.

Begründung

Der Fakt, dass man immer wieder auf veraltete Inhalte und nicht funktionierende Links in den Wikipedia-Artikeln stößt, trägt nicht zum Vertrauen in Wikipedia bei. Damit sie den verdienten Respekt und die Glaubwürdigkeit nicht verliert, sollen wir darauf achten, dass die Informationen immer aktuell und zuverlässig sind.

Was ist das Problem?

Ein konkretes Beispiel für das Problemausmaß könnte dieses Projekt des Teams Wikipedia Hannover dienen.

Alle vorhandenen Links (tot und funktionierend), die auf eine bestimmte Domain zeigen, kann man z. B. mithilfe dieses Tools ermitteln. Das wäre schon eine gute Hilfe, wenn der Bot richtig funktionieren würde. Die Ergebnisse werden als numerierte Liste dargestellt, 100 Treffer pro Seite. Das Problem ist, dass nur die erste Seite mit den Suchergebnissen angezeigt wird. Versucht man, weitere Treffer auf der nächsten Seite anzeigen zu lassen, klappt es nicht.

Bei unseren Wiki-Kollegen aus anderen großen Städten "vorbeigeschaut" muss ich feststellen, dass es da nicht besser aussieht. Z. B. fünf zufällig angeklickte Links, die mit dem giftbot ermittelt wurden, ergeben folgendes Bild:

  • berlin.de – drei von fünf zufällig angeklickten Links: Fehler 404 (Seite nicht gefunden)
  • hamburg.de – zwei von fünf: Fehler 404 (nicht gefunden)
  • koeln.de – zwei von fünf: Fehler 404 (nicht gefunden)
  • muenchen.de – fünf von fünf: Umleitung auf die Startseite (die Inhalte können also nicht mehr als Nachweis dienen)
  • stuttgart.de – vier von fünf: Fehler 404 (nicht gefunden)
Wen betrifft das Problem besonders?

Sowohl alle Wikipedianer, die Weblinks als solche oder als Einzelnachweise verwenden als auch alle Nicht-Wikipedianer, die nach den verlässlichen Informationen auf den Wikipedia-Seiten suchen.

Lösungsvorschlag
Einen konfigurierbaren Bot programmieren, der nach toten Links unter Berücksichtigung von bestimmten Kriterien suchen kann.
Vorschlagende Person

tender tiger 🐯 18:09, 14. Nov. 2021 (CET) im Namen des Teams von Wikipedia:Hannover[Antworten]

Diskussion



Fortführung des Schwerpunktes "Leichter mit Vorlagen arbeiten"[Quelltext bearbeiten]

Beschreibung des Themas

Als Hinweis für das Ausfüllen dieses Punktes (Beschreibung des Themas) wurde in diesem „Formular“ (Vorlage Themenvorschlag) Folgendes angemerkt:

  • <!-- Bitte beschreibe, was du dir unter dem Themenschwerpunkt vorstellst. Bitte darauf achten, dass die Beschreibung so formuliert ist, sodass man sie auch ohne Fachkenntnis verstehen kann. -->

Damit ist ein großes Problem bereits angesprochen: Das Thema Vorlagen ist ohne Fachkenntnisse auf dem Gebiet der „Wikipedianologie“ nicht besonders gut zu verstehen. Da das Thema „Leichter mit Vorlagen arbeiten" bereits der Gewinner als Schwerpunkt für die Mühen des Teams Technische Wünsche in 2019 geworden ist, liegen Beschreibungen bereits vor:

Einiges, was während der Laufzeit des Schwerpunkts herausgearbeitet wurde, ist bereits umgesetzt worden, bspw. Zeilennummerierung und farblich markierte Klammerpaare für Vorlagenprogrammierende. Anderes ist erst einmal nicht möglich gewesen, z. B. „Verbesserungen im Vorlagendokumentations-Editor“.

Begründung
  • <!-- Warum ist das Thema wichtig? -->

Das Thema ist deshalb wichtig, weil es Vorlagen nun einmal gibt und weil sich Benutzer*innen, die einen Artikel bearbeiten wollen, es sich nicht aussuchen können, ob sie dort Vorlagen vorfinden oder nicht.

  • <!-- Beschreibe jetzt noch MINDESTENS ZWEI PROBLEME, die deiner Ansicht nach zu diesem Themenschwerpunkt gehören. OHNE konkrete Beispiel-Probleme kann der Themenschwerpunkt NICHT zur Wahl gestellt werden. -->
Was ist das Problem?

Beispiel-Problem 1: Anmerkung in einer Infoboxen

Was möchtest du machen und warum?

Ich wollte im Artikel SARS-CoV-2 in der einleitenden „Infobox Virus“ einen Anmerkung bei einer Rubrik anbringen. In einer einfachen Tabelle würde man diese Anmerkung in der entsprechenden Zelle einfügen. In der Vorlage:Infobox Virus ist es ein Parameter, der anders heißt, nämlich Subspezies, als man das Ergebnis in der Infobox letztlich sieht: als Rubrik „Unterart“. Der sachliche Hintergrund für die Anmerkung ist der, dass es Subspezies bzw. Unterarten zwar in manchen Fällen geben könnte, dies aber beim Virus SARS-CoV-2 nicht der Fall ist.

Welche Schritte durchläufst du dabei?

Im konkreten Fall hatte ich mich dazu entschieden, die Gründe für die explizite Anmerkung und meine Vorgehensweise bei der Umsetzung auf der Diskussionsseite zu notieren (April 2021, später im Archiv: Diskussion:SARS-CoV-2/Archiv/2021/2#SARS-CoV-2, ICTV-CSG, Schwesterklade). Ich hatte eine Art „Lesezeichen“ (Vorlage:Anker) im ersten Beitrag unter dem Abschnitt angelegt, wobei die Texte unter den ersten fünf Sprungzielen von Virentaxonomie handeln. Unter dem nächsten Sprungziel steht eine Zusammenfassung, was ich warum vorhatte, Lesezeichen Fazit (zum Sprungziel: ...006), und dann folgen zwei Sprungziele,

Welche Probleme treten auf?

  • Ich konnte den Visual Editor (WP:VE; H:VE) nicht wirklich direkt benutzen, da innerhalb eines Feldes für einen Parameter nur Wikitext funktioniert.
  • Normalerweise kann man im VE die Belegen-Funktion nutzen, um eine Anmerkung als Referenz einzufügen. Die Funktion erstellt Tags in der Form <ref>...</ref> oder <ref name=":0">...</ref>. Bei einer Anmerkung in meinem Sinne, z. B. <ref name=":0" group="A">...</ref>, würden die drei Punkte (...) für jede Menge Text stehen, der eine Vorlageneinbindung für eine Infobox sehr unübersichtlich machen würde. Daher hatte ich die Referenz benannt und eine Kurzform in der Vorlage-Einbindung beim Parameter Subspezies gesetzt (<ref name="Anm-Schwesterkladen-CSG" group="A" />), während ich die Referenz mit ihrem Inhalt zwischen <reference ...> und </reference> platziert hatte.
  • Die komplizierte Referenz für die Anmerkung in der Infobox lässt sich nicht besonders einfach warten, da sie im Fließtext nicht auftaucht. Im Fließtext bekäme man durch den VE ein Dialogfenster, wenn man auf die Referenz klickt, in einer Vorlage-Einbindung erscheint bloß ein Parameterfeld, in dem Wikitext ohne Syntax-Hervorhebung steht.

Beispiel-Problem 2: Dieses Abfrage-Formular

Was möchtest du machen und warum?

Ich möchte die Wikisyntax-Konstruktion, die ich beim Klick auf [ Themenschwerpunkt vorschlagen ] erhalte – und die als eine Art „Formular“ dient – ausgefüllt abschicken, um die Verlängerung des Themenschwerpunktes „Leichter mit Vorlagen Arbeiten“ anzuregen. Genau genommen möchte ich das Formular mittlerweile vermutlich nicht mehr abschicken, da es schon erlegt ist, wenn Du diesen Text vor Dir sieht.

Welche Schritte durchläufst du dabei?

Ich habe mir die Wikisyntax in maskierter Form auf eine Benutzerseite kopiert, um sie dort zu analysieren. Ich bin die einzelnen Punkte Schritt für Schritt durchgegangen und habe versucht, das Formular sinnvoll auszufüllen. Das habe ich mit dem VE erledigt. Nachdem ich meinte, mit der Vorbereitung fertig zu sein, habe ich die Textpassagen als Wikitext zu den einzelnen Parametern kopiert und die Vorlage abgeschickt.

Welche Probleme treten auf?

Da ich ganz gern den Text so sehe, wie er am Ende sein wird (WYSIWYG), nutze ich auch gern den VE. Bei einem Qelltexteditor, z. B. WikEd (Hilfe), hat man immerhin eine Vorschau. Bei einer Vorlage hat man weniger. Auch wenn ich die Texte vorbereite, weiß ich nie genau, welcher Code auf der Vorlage-Seite welchen Code auf der Einbindungs-Seite wie umsetzen wird. Vor allem verhalten sich irgendwelche Sonderzeichen oft für mich nicht eindeutig vorhersagbar. Bei der Vorlage (Themenvorschlag) ist zwar eine Vorschau möglich, ich muss aber Stück für Stück den auf einer Benutzerseite vorbereiteten Text übertragen und nachsehen.

Was ich auch ein wenig für eine Absurdität halte, ist die Diskussion, die innerhalb einer einzelnen Vorlage-Einbindung erfolgen soll, wobei jede und jeder eigentlich daran denken muss, die schließenden Klammer unterhalb ihres oder seines Beitrags zu platzieren.

Wikipedia:Technische_Wünsche/Topwünsche/Verbesserungen_im_Vorlagendokumentations-Editor

Wen betrifft das Problem besonders?

Den Wunsch, der hinter dem Schwerpunkt „Leichter mit Vorlagen arbeiten“ stand, könnte man als Problem so formulieren: „Mit Vorlagen zu arbeiten ist schwer“.

Das betrifft unterschiedlich Gruppen in verschiedenem Maße.

Unter: oldid=194822419 – „Häufigst genannte Probleme“ wurden zwei Gruppen definiert:

  1. Primäre Zielgruppe: Personen, die an Vorlagen arbeiten;
  2. Primäre Zielgruppe: Nutzende von Vorlagen.

Die Schwierigkeiten bestehen wohl vor allem bei den „Nutzenden von Vorlagen“, die mit dem zurecht kommen müssen, was da ist. Die „Personen, die an Vorlagen arbeiten“ können sich vermutlich häufiger selbst helfen. Es gibt natürlich auch Vorlagenprogrammierende, die auch Vorlageneinbindungen nutzen. Ich denke, die Pesonen, die den VE nutzen, würden am meisten profitieren, wenn das Thema in entsprechender Richtung weitergeführt würde.

Lösungsvorschlag

Weiterführung des Themas unter besonderer Berücksichtigung

Das habe ich nicht verstanden:

<!-- Vorlage zur Erfassung von Problemen kopieren, um weitere hinzuzufügen. -->
Vorschlagende Person

Dirk123456 (Diskussion) 23:46, 14. Nov. 2021 (CET)[Antworten]

Diskussion



Vorschläge für die Umfrage 2023[Quelltext bearbeiten]

Alle Probleme, die nach dem 15.11.2021 hier notiert werden, fließen in die Umfrage 2023 ein.