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

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.

Alle Leser, die Wikipedia in der mobilen Ansicht nutzen.

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.

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

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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.

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

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)[Beantworten]

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

 Pro  — --Klaus-Peter (^aufund_davon) 05:39, 11. Jul. 2020 (CEST)[Beantworten]

 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]

Ä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)[Beantworten]

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.

• 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

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)

• 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)[Beantworten]

•  Kontra alphabetische Reihenfolge ist nicht immer sinnvoll; vielmehr sind die BKS oft nach Themen oder Chronologie zu sortieren. --ProloSozz (Diskussion) 11:41, 7. Jul. 2021 (CEST)[Beantworten]
•  Kontra +1 --Jbergner (Diskussion) 10:51, 26. Okt. 2021 (CEST)[Beantworten]
• Warum müsst ihr da jetzt Contra geben? Es geht doch nur um eine optional Vorlage, die nicht zwangsweise eingebaut wird, oder verstehe ich das falsch? --Fan-von-mir (Diskussion) 13:35, 29. Okt. 2021 (CEST)[Beantworten]

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.

alle Benutzer

automatische Eintragung von Artikeln auf den vorgesehenen Seiten

Lg {TheTokl ► Disk 📢 • E-Mail ✉️ • ❔Hilfe❔} 12:26, 10. Sep. 2019 (CEST)[Beantworten]

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)[Beantworten]

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

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

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

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

• 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)[Beantworten]
• Kann man dies mithilfe eines Bearbeitungsfilters umsetzen? --Zabe (Diskussion) 15:55, 25. Okt. 2021 (CEST)[Beantworten]

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.

Administratoren/Globale Administratoren/Stewards

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)[Beantworten]

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

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.

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

Ä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).

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

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)[Beantworten]

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 (^aufund_davon) 06:40, 9. Nov. 2020 (CET)[Beantworten]

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)[Beantworten]

Jetzt ohne Extra-Anmeldung... --DB111 (Diskussion) 17:00, 3. Mai 2021 (CEST)[Beantworten]

Siehe auch Benutzer:Schnark/js/notizen mit seitengebundener Erinnerung. --FriedhelmW (Diskussion) 21:53, 8. Apr. 2021 (CEST)[Beantworten]

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.

Autoren Administratoren usw.

Eine Art Notizblock auf den nur der Autor/Benutzer zugriff hat.

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

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 (^aufund_davon) 13:49, 11. Aug. 2020 (CEST)[Beantworten]

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)[Beantworten]

Oder wenn man auf Spezial:Präfixindex/Benutzer:WikiBayer geht. --Zabe (Diskussion) 15:59, 25. Okt. 2021 (CEST)[Beantworten]

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)[Beantworten]

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

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.

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.

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

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

"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)[Beantworten]

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)[Beantworten]

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.

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

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

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

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.

Diverse, sowohl Autoren als auch Personen mit Wikipedia-Artikel

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. Steht alles bereits oben

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

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)[Beantworten]

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 (^aufund_davon) 11:39, 12. Dez. 2020 (CET)[Beantworten]

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

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.

Jeden, der auf seine Beobachtungsliste schaut.

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.

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

• 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 (^aufund_davon) 06:08, 6. Nov. 2020 (CET)[Beantworten]

• Still ruht der See und man sollte den Parkplatz in Abstellplatz umbenennen. Zeit kann man besser verplempern! --Klaus-Peter (^aufund_davon) 11:48, 12. Dez. 2020 (CET)[Beantworten]

• Ich finde den Vorschlag von Sinuhe20 gut. --Fan-von-mir (Diskussion) 13:53, 29. Okt. 2021 (CEST)[Beantworten]

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.

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

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

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

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.

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.

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.

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

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 (^aufund_davon) 11:33, 12. Dez. 2020 (CET)[Beantworten]

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)[Beantworten]

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 (^aufund_davon) 16:20, 12. Dez. 2020 (CET)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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.

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.

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.

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

• InternetArchiveBot siehe auch http://blog.archive.org/2018/10/01/more-than-9-million-broken-links-on-wikipedia-are-now-rescued/

@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)[Beantworten]

@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)[Beantworten]

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.

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?

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.

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

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

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

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.

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.

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.

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

@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)[Beantworten]

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

Alle angemeldeten Benutzer

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

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:

• Vorlage:Worldcat id

Betroffen sind potentiell alle Benutzer, die einen Personenartikel anlegen.

?? - - -

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

@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)[Beantworten]

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.

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

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). 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.

‣Andreas•⚖ 11:29, 29. Apr. 2021 (CEST)[Beantworten]

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)[Beantworten]

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)[Beantworten]

• 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

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.

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>).

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:

• #Automatische Ersetzung bestimmter Zeichen
• #&nnbsp; als Synonym für  

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

• #definierte Bezeichnungen vor automatischem Zeilenumbruch schützen

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.

‣Andreas•⚖ 11:29, 29. Apr. 2021 (CEST)[Beantworten]

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.

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

Bei den Einstellungen ein CSS mit Darkmode hinzufügen.

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

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

Besonders bei Künstlern ist es bliebt 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.

im Prinzip alle Autoren

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) 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.

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

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).

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

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.

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

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].

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)

Hilfe:Tabellen/Sortierung#Rangliste aktualisieren

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

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.

Sämtliche angemeldeten Benutzer

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

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).

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

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.

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

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.

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

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

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
   • Artikel: Funktion (Mathematik)#Verknüpfung
   • Bild mit TeX in Bildlegende im Bildbetrachter: Funktion (Mathematik)#/media/Datei:Binary operations as black box.svg
2. Beispiel 2
   • Artikel: Komplexe Zahl#Komplexe Konjugation
   • Bild mit TeX in Bildlegende im Bildbetrachter: Komplexe Zahl#/media/Datei:Komplexe konjugation.svg
3. Beispiel 3
   • Artikel: Parabel (Mathematik)#Jede Parabel ist zur Normalparabel y=x² ähnlich
   • Bild mit TeX in Bildlegende im Bildbetrachter: Parabel (Mathematik)#/media/Datei:Parabel-scal2.svg

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

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

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.

Commons-Nutzer

Entweder ein Button, oder z.B. in der Reiterleiste unter "Weitere" einen Punkt "Vorschau bei Unterkategorien"

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

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.

Vorlagenprogrammierer

Diese Erweiterung in der deutschen Wikipedia installieren.

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)[Beantworten]

@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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

@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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

@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)[Beantworten]

@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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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

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)

• bei gleichzeitiger möglichster Vermeidung von Dubletten unter den 95 Millionen vorhandenen Objekten (d:Special:Statistics)

wird seit Jahren immer wieder diskutiert, beispielsweise unter

• meta:Community Wishlist Survey 2021/Wikidata/Creation of new objects resp. connecting to existing objects while avoiding duplicates
• d:Wikidata:Contact_the_development_team/Archive/2020/09#Connecting_newly_created_articles_to_existing_objects_resp._creating_new_object_-_additional_step_when_creating_articles,_categories,_etc.
• d:User_talk:Mike_Peel/Archive_2#Matching_existing_wikidata_objects_with_unconnected_articles
• d:Wikidata:Requests_for_permissions/Bot/RegularBot_2
• d:Wikidata:Requests for permissions/Bot/Pi bot 19
• d:User_talk:Mike_Peel/Archive_3#Creation_of_categories_and_articles_after_14_days
• d:Topic:Vplpjjjpwfpmelfo
• d:Wikidata:Forum/Archiv/2020/07#Wikidata-Objekte_für_noch_nicht_zugordnete_Artikel,_Kategorien,_Vorlagen,_Listen,_Begriffsklärungen,_mit_bestehenden_Objekten_verbinden_bzw._neu_anlegen
• d:User_talk:Mike_Peel/Archive_3#Julie_von_Kästner
• d:User_talk:Mike_Peel/Archive_4#once_againg
• d:User_talk:Mike_Peel/Archive_3#Q105613214
• d:User_talk:MrProperLawAndOrder#Mathilde_Welcker_(Q94753027)_and_Mathilde_Welcker_(Q94753026)_are_identical
• Wikipedia:Kurier#Unterstützung_bei_der_Eingangskontrolle_und_Tätigkeiten_der_Qualitätssicherung_gesucht

uvam.

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

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:

• https://wikidata-todo.toolforge.org/duplicity.php?wiki=dewiki&norand=1&page=Vasco%5FCordeiro

• 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)[Beantworten]

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

• Benutzer:M2k~dewiki/Checklist
• Wikipedia:Kurier#Unterstützung_bei_der_Eingangskontrolle_und_Tätigkeiten_der_Qualitätssicherung_gesucht

Beispielsweise

• fehlen Kategorien (z.B. Helferlein "HotCat") inkl. Sortierschlüssel
• fehlen bei biografischen Artikel Personendaten und Normdaten (Benutzer:Schnark/js#personendaten.js, Benutzer:Schnark/js/personendaten)
• sind Rechtsschreibfehler enthalten (Wikipedia:Helferlein/Rechtschreibprüfung)
• sind Links auf BKLs enthalten (Wikipedia:Helferlein/Begriffsklärungs-Check)
• fehlt die Verbindung zu einem Wikidata-Objekt
• wird auf eine nicht vorhandene Commonscat verlinkt (oder es existiert eine Commonscat, diese wird aber nicht verlinkt, vorhandene Inhalte/Fotos nicht eingebunden)
• fehlt das reference-Tag im Abschnitt Einzelnachweise
• ist das Lemma in der Einleitung nicht hervorgehoben
• gibt es leere Abschnitte ohne Inhalt bestehend nur aus der Überschrift

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

• 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

• Wikipedia:Technische_Wünsche/Wunschparkplatz#Verbinden/Anlegen_von_bestehenden/neuen_Wikidata-Objekten_mit_neu_angelegten_Artikeln/Kategorien_unter_Vermeidung_von_Dubletten
• Wikipedia:Technische_Wünsche/Wunschparkplatz#Online-Typografiecheck_im_Editfenster_vor_Abschicken_eines_Edits,_z.B._wie_in_Word
  Vorschlagende Person

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

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:

• d:Topic:Wicllgduvgnw9lwy
• d:Wikidata:Forum#Q64168538
• Benutzer:M2k~dewiki/FAQ#missbilligter_Rang

Alle Benutzer von Wikidata

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:

• Benutzer:M2k~dewiki/FAQ#missbilligter_Rang

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

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

Haufenweise grottige Typografie insbesondere im Fließtext

jeden Autor

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

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)[Beantworten]

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)[Beantworten]

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

• Wikipedia:Probleme_mit_SVGs
• c:Librsvg_bugs
• c:Category:Pictures_showing_a_librsvg_bug

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

Statt libRsvg REsvg zum Rendern der SVGs verwenden, siehe phab:T40010

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

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

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.

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

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") 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)

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

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 Taxon • Disk. • 22:29, 27. Okt. 2021 (CEST)[Beantworten]

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)[Beantworten]

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 Taxon • Disk. • 05:27, 28. Okt. 2021 (CEST)[Beantworten]

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.

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

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)[Beantworten]

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 Vorlage:Smiley/Wartung/zwinker  Wer ernsthaft editieren will, nimmt den herkömmlichen Editor. – Doc Taxon • Disk. • 05:43, 28. Okt. 2021 (CEST)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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.

Autor*innen, die Typographie manchmal etwas zu ernst nehmen

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. 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].

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

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)[Beantworten]

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

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)[Beantworten]

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.

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

• 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)[Beantworten]

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

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

• https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality/de
• Wikipedia:Bücher

ist seit ein paar Jahren nicht mehr verfügbar

Die vorgeschlagene Alternative

• https://mediawiki2latex.wmflabs.org/

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

Wen betrifft das Problem besonders?

Eine Reaktivierung wäre wünschenswert.

• Wikipedia:Fragen_zur_Wikipedia#Wikipedia-Bücher_im_BNR_???
• Wikipedia:Fragen_zur_Wikipedia#Projekt_gedruckte_Bücher
  Vorschlagende Person

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

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

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)[Beantworten]

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)[Beantworten]

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.)

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

Schaltflächen für angemeldete Mitschreibende.

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

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

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.

• 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.

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

• 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)[Beantworten]

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

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

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.

Alle Autoren, die mit dem Quelltexteditor arbeiten

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

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

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 Taxon • Disk. • 05:51, 28. Okt. 2021 (CEST)[Beantworten]

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.

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

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.

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

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)[Beantworten]

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)[Beantworten]

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. -→_KP^F_&Blabla← 19:46, 27. Okt. 2021 (CEST)[Beantworten]

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.

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.

Beispiel 1: Durchkopplung

• Ich verlinke ein Wort mit dem Visual Editor, z.B. „Aktivistin“ verlinke ich zu „Aktivist“.
• Im Quelltext steht dann aber [[Aktivist|Aktivistin]]
• besser wäre [[Aktivist]]in
• deshalb gehe ich dann nochmal in den Quelltext und passe das direkt an oder andere User ändern das händisch
• reelles Beispiel (betrifft den Wikilink zu DVD)
• siehe auch: Hilfe_Diskussion:Links#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_*

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.

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.

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.

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

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)[Beantworten]

Vielen Dank für die Erläuterung! Dann kann das ja archiviert werden. --Fan-von-mir (Diskussion) 00:21, 29. Okt. 2021 (CEST)[Beantworten]

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)[Beantworten]

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)[Beantworten]

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.

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.

Ettablieren von 2FA beim Erreichen vom passiven Sicherrecht {{{Anmerkungen}}}

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

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)[Beantworten]

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)[Beantworten]

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)[Beantworten]

Verbesserungsvorschläge zum Umgang mit der Wikipedia-App

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

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.

Alle Autoren, die die App nutzen.

keine Ahnung, bin kein Software-Profi Kann gerne mit anderen Themenschwerpunkten vereinigt werden.

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

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

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.

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.

Alle, die Bilder hochladen möchten.

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. 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.

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

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)[Beantworten]

Hilfe:Zusammenfassung und Quellen

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.

siehe oben

siehe oben

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

 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)[Beantworten]