Wikipedia Diskussion:Umfragen/Absichtliches Einfügen von Zeichen mit verborgener Nebenwirkung

Zum Geleit

@ BurghardRichter | aka | Sänger: Meine Ansicht aus August 2021 musste ich ob des Verlaufs dieses Jahres aktualisieren. VG --PerfektesChaos 09:28, 3. Jun. 2023 (CEST)

Problematik mit Weiterleitungen

Auch wenn Überschriften mit solchen Zeichen, sei es nun sichtbar oder unsichtbar, versehen werden, kann es zu Problemen führen, der Benutzer:Krdbot erkennt das dann als ungültiges Ziel für Abschnittsweiterleitungen, selbst wenn diese Links tatsächlich das Ziel erreichen, ein Fehler also auf Anhieb nicht erkennbar ist. Zuletzt hatten wir das hier Benutzer Diskussion:Krdbot#Problem bei Benutzer:Krdbot/RedirectDeeplink. Das könnte man in dem Zusammenhang auch mit erwähnen, weil auch in Überschriften oftmals abweichende Steuerzeichen (zumeist geschützte Leerzeichen) eingebaut werden. --Liebe Grüße, Lómelinde Diskussion 10:15, 3. Jun. 2023 (CEST)

Danke, aber das ist nur ein einzelner von ganz ganz vielen unbegreiflichen Effekten; genauso auch die Störung des Zeilenumbruchs, weil rätselhafterweise mehrere Wörter fest aneinander kleben, oder dass [[]] rätselhafterweise keine Verlinkung bewirkt. VG --PerfektesChaos 10:51, 3. Jun. 2023 (CEST)

Einen Tod muss man sterben

Wir hatten ja seinerzeit dort das Problem diskutiert, dass wir hier ein Trilemma haben. D.h. drei Möglichkeiten, die alle nennenswerte Nachteile haben. Wenn man einseitig über nur eine dieser Möglichkeiten abstimmt, bekommt man leicht eine Mehrheit. Ist aber verzerrend, teils sogar manipulativ, wenn man die jeweiligen Nebenwirkungen weglässt. Klassisches Beispiel ist die Sommerzeit, wo man leicht Mehrheiten gefunden hat, die gegen die Zeitumstellung sind. Nur komischerweise findet man weder eine Mehrheit dafür, dass es dann im Sommer schon um 3 hell und und um 21 Uhr dunkel werden soll, noch dafür, dass es im Winter dann eben erst gegen 10 hell wird. Es gibt hier die drei Optionen:

1. Man verzichtet weitgehend auf geschützte LZ (bis auf dringend nötige Ausnahmen, die man mit nbsp-regelt) und dergleichen, sowie verzichtet völlig auf schmale geschützte LZ (es sei denn, so eine nnbsp-Lösung setzt sich durch)
2. Man nutzt die hier disktutierten (fast) unsichtbaren Zeichen
3. Man knallt den Quelltext serienweise mit nbsp; shy und diverser Unicode-Syntax etc...voll.

Was mich betrifft: ich bin ein strikter Gegner von 3. Und damit bin ich strikt gegen eine Umfrage, die durch radikalen Verzicht auf 2 womöglich Leute zu 3 treibt. Ich kann wiederum mit 1 ganz gut leben. Und bislang gehen unsere Richtlinien- und Hilfeseiten in diese Richtung. Genannt wird nbsp, wobei diese äußerst sparsam eingesetzt werden sollen. Aber, wie auch immer, wenn man hier eine Möglichkeit ablehnt, muss man sagen, was dann stattdessen... Sonst ist man eben bei der Sommerzeit-Geschichte.
Man findet vermutlich leicht Mehrheiten für alles drei: dafür, dass diese Nebenwirkungs-Zeichen raus sollen, wie auch dafür, dass man auf Unicode-Syntax im Regelfall verzichtet, wie auch dafür, dass es sinnvoll ist (schmale) umbruchgeschützte LZ darzustellen.
Dass eigentlich mindestens die Fälle "z. B.", "d. h." etc. und Kombinationen aus Zahl/abgekürzter Einheit m. E. softwareseitig lösbar sein könnten, sei nur am Rande erwähnt. --Global Fish (Diskussion) 10:40, 3. Jun. 2023 (CEST)

Traditionell (seit zwei Jahrzehnten) ist 1.) der Projektstandard. Nur nicht schriftlich fixiert. Also gewissermaßen „status quo“ und recht breiter Konsens, mit einer Handvoll Opponenten gegen Zehntausende. Die Varianten 2.) und 3.) wären nagelneu, gibt nur wenige Einzeltäter und ist nirgendwo breit akzeptiert worden. VG --PerfektesChaos 10:47, 3. Jun. 2023 (CEST)

Ja, der Projektstandard ist so, und über unsere jeweiligen Präferenzen sind wir, wenn ich mich recht entsinne, auch ähnlicher Meinung. Nur "neu" sind beide Varianten wiederum auch wieder nicht. Es wurde immer wieder versucht (sonst müssten wir ja hier auch nicht diskutieren). Nur muss die Konsequenz eben strikt lauten: "Geschützte schmale Leerzeichen werden im ANR nicht verwendet."
Solange das nicht klar formuliert ist, treibt eine verbindlich festgestellte Ablehnung der Nebenwirkungszeichen (in Kombinationen mit der Ablehnung von nnbsp) die Leute, die unbedingt schmale LZ darstellen wollen, zur Unicode-Syntax. Und das hielte ich für einen Schritt in die falsche Richtung. --Global Fish (Diskussion) 11:38, 3. Jun. 2023 (CEST)

PS: Der jetzige Textentwurf Der Ersatz von Zeichen mit verborgen wirksamer Kodierung durch eine offensichtliche Zeichenkodierung gilt grundsätzlich nicht als „Kleine Änderung“, sondern beseitigt eine tückische Fallgrube und darf von allen in beliebigem Umfang überall ausgeführt werden lässt sogar das Ersetzen durch Unicode-Syntax explizt zu, da das ja eine "offensichtliche Zeichenkodierung ist. Von mir ein sehr striktes Nein dazu. Bitte dringend ändern, so geht es nicht. --Global Fish (Diskussion) 12:36, 3. Jun. 2023 (CEST)

Dieses PS habe ich nicht verstanden, und die Schlussfolgerung auch nicht.

Ich bemühe mich, gerichtsfest und präzise zu formulieren. Hier wird eine Alternative von zwei Optionen aufgezeigt:

1. „verborgen wirksame Kodierung“
2. „durch eine offensichtliche Zeichenkodierung“

Letzteres kann realisiert werden beispielsweise

• Ersatz durch  
• Ersatz durch ASCII-Leerzeichen.

Der Weg, wie ein „Ersetzen durch Unicode-Syntax explizt“ ermöglicht würde, ist mir schleierhaft. Ein Unicode-Zeichen im Sinne von U+202F ist ja gerade nicht „offensichtlich“, sondern transportiert zwei verborgene Effekte, sieht im Quelltext jedoch aus wie ein ASCII-Leerzeichen.

VG --PerfektesChaos 13:18, 3. Jun. 2023 (CEST)

Ähm, sorry, aber es ist keineswegs offensichtlich, dass   eine „offensichtliche Zeichenkodierung“ ist, aber U+202F nicht!
Es werden sicherlich mehr Menschen   kennen als die Unicode-Syntax, aber mindestens 90% der Leserschaft dürften weder das eine noch das andere kennen. Und einige wiederum werden beides kennen!
Bitte Vorsicht mit Wörten wie „offensichtlich“! Was für Dich offensichtlich ist, ist es keineswegs auch für andere!--Global Fish (Diskussion) 13:27, 3. Jun. 2023 (CEST)

Und mal wieder noch ein PS: "offensichtlich" hat noch eine weitere Bedeutung; nämlich im Gegensatz zu den hier diskutierten verborgenen Nebenwirkungen. In diesem Sinne ist auch *jeder* Code aus sichtbaren Zeichen (Buchstaben, Zahlen, Sonderzeichen) "offensichtlich", auch wenn man gar nicht weiß, was der bedeutet. Ich bitte wirklich dringend um eine Änderung dieser Formulierung. --Global Fish (Diskussion) 15:19, 3. Jun. 2023 (CEST)

Niemand wird hier irgendwohin „getrieben“.

Umseitig geht es ausschließlich um die Zeichenkodierung und nichts anderes. Alles hängt mit allem zusammen, aber umseitig ist nicht das Thema, zu welchem Zweck typografische Features genutzt werden und wann das übertrieben wäre und wie weit die typografische Aufmotzung der Darstellung gehen soll, zum Nachteil der Bearbeitbarkeit des Wikitextes durch nachfolgende Menschen.

For the record – Ich gehe von grundlegenden Anforderungen aus:

1. Die Wikipedia muss vom Publikum leicht zu lesen und zu verstehen sein; zumindest wenn es nicht grad um Biochemie oder Feinheiten der japanischen Liebeslyrik geht.
2. Die Wikipedia muss (im ANR) möglichst leicht und ohne Vorkenntnisse bearbeitbar sein; von allen die das plötzlich möchten.

Letzteres trifft nicht notwendig auf die Programmierung von Vorlagen, trickreichen Grafiken oder Lua zu. Aber ein schlichter Text mit drei Zahlenangaben muss sich verbessern, erstellen, ändern lassen. Ohne monatelanges Einweisungsseminar. Was projektorganisatorisch noch hinzukommt, ist WWNI, RK, BLG, WEB usw. und betrifft dann inhaltliche Aspekte.

Zum einfachen Verständnis gehört eine bedeutungsstützende Typografie und die erfordert zuweilen Umbruchschutz. Wenn eine Zeile endet mit Wilhelm und danach beginnt die neue Zeile I. beauftragte Bismarck mit, dann bekommen Normalsterbliche Schwierigkeiten mit der Sinnerfassung. Gleiches gilt für die Trennung einer (kurzen) Maßzahl und dem Einheitensymbol.

Desgleichen ist Zeilenumbruch, ggf. je nach Bedingungen auf dem Endgerät, für die Darstellung langer Wörter bei Platzmangel notwendig. Wenn ein Kompositum über die Bildlegende hinausragt, wird es kurzerhand abgeschnitten und ist futsch. Wenn eine Tabellenspalte übermäßig breit werden muss, um ein langes Wort unterzubringen, dann wird die gesamte Tabelle zu breit und passt nicht mehr auf das Endgerät und wird abgeschnitten und ist unsichtbar oder nur durch Scrollen erreichbar, wobei dann die Spalten links futsch sind.

Und was bringen jetzt „schmale“ Leerzeichen, und wem?

• Das Publikum bekommt davon nix mit. Bei mir ist   und normales Leerzeichen und schmales Leerzeichen praktisch gleich breit, und der Unterschied wäre nur ein Pixel mit Bildschirmlupe ermittelbar. Das Verständnis wird dadurch nicht verbessert.
• Bei der Bearbeitung gibt es zusätzliche Probleme aller Art; Verkomplizierung des Wikitextes, neue Regeln die alle Beteiligten erst erlernen müssen bevor sie mitwirken können.
• Aus diesem Grund noch niemals Projektstandard gewesen; mindestens nicht für den ANR.

Und was bringen jetzt weitere weiche Trennzeichen?

• Der Randausgleich rechts wird etwas gefälliger, fein.
• Die Wörter können bei Textsuche nicht mehr gefunden werden, es sind keine Ersetzungen mehr möglich, weil es andere Zeichenketten sind.
• Wenn die Trennzeichen versteckt werden, weiß niemand wo sie sind, kann ihre Richtigkeit nicht überprüfen, kopiert sie an Stellen wo keine hingehören ohne dies bemerken zu können.
• Wenn die Trennzeichen als Entity dargestellt werden, wird der Wikitext unlesbar, was jederzeit am tagesaktuellen AdT-Teaser unserer Hauptseite nachgeprüft werden kann. Das machen wir genau einmal an dieser allerprominentesten Stelle, aber sonst nur wenn zwingend notwendig.
• Aus diesem Grund noch niemals Projektstandard gewesen.
• Wer mag, kann sich die automatische Worttrennung des Browsers einschalten. Der hat aber nur ein paar simple Konsonanten-Regeln, und dann noch ein Wörterbuch um bei gängigen Komposita die Teilwörter zu identifizieren. Diese deutschsprachigen Wörterbücher langen jedoch nur für Einkaufszettel und kleine Briefe. Bei uns gibt es aber jede Menge Namen aus allen Regionen des Planeten, von Personen und Orten und Kunstwerken, dazu mittelhochdeutsche Zitate, und Codes von Platinen und Chemikalien und sonstwas. Deshalb liegt die automatische Browser-Worttrennung regelmäßig schief und trennt falsch, was zu dem Schluss führt, die Wikipedistas wären zum Schreiben zu dämlich und hätten das falsch in den Artikel geschrieben. Was dann dazu verleitet, den Artikel zu bearbeiten und irgendwie diese Falschschreibung zu korrigieren, aber da ist gar keine und am Ende ist das noch mehr zerschossen durch erfolglose Umbruchverhinderungsversuche. Deshalb trennen wir im allgemeinen Artikeltext nicht; oder nur bei technischer Notwendigkeit.

Alles das ist jedoch umseitig nicht das Thema. Dort geht es nur um die verborgene Eigenschaft, nicht aber welcher Zweck an welcher Stelle damit erreicht werden soll und ob dies an dieser Stelle sinnvoll wäre.

VG --PerfektesChaos 21:08, 5. Jun. 2023 (CEST)

Danke für Deine ausführliche Erklärung! Allerdings, es gibt hierbei zwei Ebenen: die Intention, was man erreichen möchte und die konkrete Formulierung des Umfrageentwurfs. Auf der Ebene der Intention sehe ich uns beide praktisch völlig einig. Offen scheint mir nur die Ebene der konkreten Formulierung.
Was die schmalen geschützten Leerzeichen angeht: ich brauche sie genauso wenig wie du. Ich sehe den Unterschied zu normalbreiten beim einfachen Lesen eines Textes nicht. Nur: es gibt Leute, denen das wichtig ist. Und denen muss man sagen, was an solchen Stellen geschehen soll, wenn man die unsichtbaren geschützten schmalen LZ ausschließt. Und da gibt es Leute, die dann anfangen, diese durch die 8239-Unicode-Syntax zu ersetzen. Sei es gutwillig wie hier, sei es verbissenener wie dort samt paralleler VM dazu.
Ich teile die Ablehnung gegen die unsichtbaren Leerzeichen durchaus, aber in Konstrukten wie zwischen Zahl und Einheit halte ich Zahlensalat wie 16,7 Hz für das noch größere Übel.
Und deswegen halte ich Formulierungen, die (egal ob gewollt oder ungewollt) die Interpretation zulassen,   wäre dann akzeptabel, ausdrücklich für eine *Verschlechterung* gegenüber dem Jetzt-Zustand. Und ja,   kann ich als "eine offen erkennbare Zeichenkodierung" interpretieren.
Nicht ganz verstehe ich Deinen Entwurf in Bezug auf die weichen Trenner. Die Intention dahinter scheint mir auch hier klar, und ich teile sie ebenso. Aber hier ging es doch um die Realisierung mittels ­. Das scheint mir doch eine klar definierte Codierung zu sein, völlig analog zu  . --Global Fish (Diskussion) 09:35, 6. Jun. 2023 (CEST)

Ich habe keine Lust, mich in dieses Drama einzumischen, aber wurde für nbsp als mögliche Alternative die verstärkte Verwendung von nowrap diskutiert? --194.199.25.87 14:47, 6. Jul. 2023 (CEST)

Es gibt auch noch {{Nnbsp}} für das schmale Leerzeichen. Die ist auch nicht weniger gut lesbar als (das normalbreite)  . --141.22.103.21 11:12, 7. Jul. 2023 (CEST)

Ich sehe gute Argumente für alle 3:

•   ist eine Konvention und bereits ein Kompromiss. Denn typografisch korrekt wäre allerdings zwischen Einheit und Wert, und ebenfalls bei Abkürzungen wie "d. h." das schmale geschützte Leerzeichen  . Das nutzen wir aus gutem Grund nicht, weil die numerische Codierung nicht von jedem flüssig zu lesen ist und die HTML-Entität Bedeutung vermittelt.
• Beim Editieren ist mir (als Quelltext-Editor-Nutzer) aus Editor-Effizienzgründen wichtig (find mal das eine ungeschützte Leerzeichen in einer Zahlentabelle, das Du durch ein geschütztes ersetzen willst) , dass ich den Quelltext eindeutig identifizieren kann. Gerade die "trennbaren" und "untrennbaren" Zeichen sehen jedoch visuell identisch aus, manche Zeichen sind nicht is_printable() und können nur erraten werden. Das ist für mich problematisch und hindert mich daran, Artikel typografisch (nebenbei mit) zu verbessern.

Ich mache das also im Allgemeinen so (first match wins):

• Wo ein Sonderzeichen nicht unbedingt nötig ist, baue ich keines ein.
• Wenn es gar keine visuelle Verwechslungsgefahr gibt, dann benutze ich direkt das Unicode-Zeichen.(bspw.: ä,ö,ü)
• Wenn es eine HTML-Entity gibt, dann benutze ich die. Ggf. die, die dem Zweck am nächsten kommt.
• Ich denke nochmal nach, ob ich wirklich das Sonderzeichen benötige.
• (noch nie passiert:) Ich benutze die direkte Unicode-Codierung von HTML. (bspw.:  

So ist für jeden ersichtlich, dass ich immer die Alternative gewählt habe, die jedem Editor die größtmögliche Klarheit gibt, was da eigentlich steht und ggf. geändert werden muss, bzw. nicht geändert werden sollte. Fertig. Wikipedia ist ja nicht dazu da, anderen Editoren Steine in den Weg zu legen oder Arbeit zu machen, für die man selbst zu faul (aka: copy&paste) ist. (nicht signierter Beitrag von Alturand (Diskussion | Beiträge) 18:31, 2. Aug. 2023 (CEST))Arx, ich sollte nicht so oft "Beantworten" verwenden

Kleine Änderung

Fiel mir beim obigen Absatz auf, aber ist unabhängig davon. Ich halte die Überschrift "Kleine Änderungen" hier für falsch. Natürlich sind rein typographische Korrekturen immer kleine Änderungen. Die Frage, ob große oder kleine Änderungen, hat nichts damit zu tun, ob sie von allen in beliebigem Umfang überall ausgeführt werden dürfen. Etliche kleinere Änderungen dürfen selbstverständlich immer und überall ausgeführt werden, so manche größere dagegen nicht. Was du vermutlich sagen willst, ist, dass eine solche Änderung keinen Verstoß gegen den Sinn von WP:KORR darstellt. --Global Fish (Diskussion) 12:36, 3. Jun. 2023 (CEST)

Danke, aber das ist schon genau so gemeint wie es da steht.

• Kann ich aber gern nochmal präzisieren; und genauer verlinken.
• Es geht um den Satz im grünen Kasten: „Ein Edit soll immer mindestens zu einer nach außen sichtbaren oder wirksamen Veränderung führen; neben einer inhaltlichen Änderung etwa eine Tippfehlerkorrektur, ein PDfix oder eine typografische Verfeinerung, sofern diese keinen geschmacklichen oder kosmetischen Hintergrund hat. Eine reine Syntax-Modernisierung oder Quelltext-Formatierung rechtfertigt keine neue Artikel-Version.“
• Nun könnte man die Sichtbarmachung verborgener Zeichen ja damit abzuwehren versuchen, dass es sich dabei ja nur um eine Quelltext-Formatierung handeln würde, die keinen nach außen sichtbaren oder wirksamen Effekt habe. Deshalb hätte sie nicht durchgeführt werden dürfen und könne als „Geschmacks-Edit“ revertiert werden.

WP:KORR beschäftigt sich mit Rechtschreibung, mit gleichermaßen zulässiger „alter“ und „neuer“ Rechtschreibung, mit gleichbedeutenden gleich gut verständlichen Formulierungen. WP:Rechtschreibung hat absolut nullkommanullnullnull zu tun mit Wikisyntax oder technischer Zeichenkodierung.

VG --PerfektesChaos 13:07, 3. Jun. 2023 (CEST)

Es geht um den Satz im grünen Kasten - dann schreib' das einfach so sinngemäß hin. Der Satz im grünen Kasten hat eine andere Bedeutung als das in Hilfe:Kleine_Änderungen gesagte. Nochmal: auch Kleine Änderungen (Typos, Linkfixes etc. ) können völlig unstrittig sein und "Fallgruben beseitigen". Rein typographische Änderungen sind von der Natur der Sache welche den sachlichen Inhalt eines Artikels nicht verändern. Ich halte es für völlig aberwitzig, so zu tun, als wären es keine. Mit dem grünen Kasten hat das nichts zu tun. Eine falsche Typographie durch eine richtige ersetzen, darf man selbstverständlich.--Global Fish (Diskussion) 13:20, 3. Jun. 2023 (CEST)

„KÄ“ ist diejenige Meta-Seite, die sich mit der Frage der „Mini-Edits“ und deren Unzulässigkeit beschäftigt, und das so nebenbei als Abfallprodukt einer Software-Doku, beim Ankreuzeln von „K“ oder nicht.

Seit zwei Jahrzehnten gibt es Streitigkeiten, wann was als „klein“ einzustufen sei und wann jemand genau was als „klein“ kennzeichnen dürfe oder müsse. Für ein kleines Wiki ist diese Softwarefunktion wohl hilfreich, bei Zigtausenden an Menschen mit unterschiedlichem Verständnis und vielerlei möglicher Arten von Veränderung ist ein solches ja/nein nicht umsetzbar. Ich wurde auch schon mehrfach angegangen, dass ich diesen oder jenen Edit nicht als K gekennzeichnet hatte, weil dann wäre er auf der Beo ausgeblendet worden, und bekam von anderer Seite Beschwerden, ich hätte als K markiert und versucht heimlich eine Beo zu untertauchen.

Die Funktion „K auf Beo ausblenden“ ist in der deWP nicht umsetzbar ob der zu vielen zu heterogenen Mitwirkenden. In einem Wiki mit einem Dutzend Konten ließen sich genau die unwichtigen Sachen ausfiltern, wer mag; bei uns müssen letztlich immer alle Edits kontrolliert werden, weil die kongruente Markierung bei jeglicher Bearbeitung nicht gesichert werden kann.

Den umseitigen Text habe ich jetzt auf „Kosmetik“ geändert.

VG --PerfektesChaos 21:08, 5. Jun. 2023 (CEST)

So scheint mir das - für diesen Teil des Satzes- in Ordnung. Danke. Zum Rest siehe oben.--Global Fish (Diskussion) 08:17, 6. Jun. 2023 (CEST)

Manipulative Umfrage

Soviel ich, @PC, von Deiner Arbeit halte, so enttäuscht bin ich, dass Du trotz diverser Hinweise auf dieser Disk hier (die Du letztlich ignoriert hast) die Umfrage in dieser Form gestartet hast. Ich halte sie für hochgradig manipulativ und in vielerlei Hinsicht für inhaltlich unausgegoren. Um beim Hauptpunkt schmale geschützte Leerzeichen zu bleiben, wir haben hier ein Trilemma. Es gibt keine allgemein akzepierte Möglichkeit, schmale geschützte Leerzeichen in Wikipedia darzustellen.
Es gibt drei Ansätze:

1. Verzicht auf die Darstellung schmaler geschützter Leerzeichen
2. Darstellung mit unsichtbaren Zeichen oder mit nnbsp
3. Darstellung mit Unicode-Entity-Sequenzen.

Jeder dieser drei Ansätze hat eindeutig *seine* spezifischen Nachteile. Eine Umfrage nur nach den Nachteilen *einer* dieser drei Möglichkeiten zu haben, ohne zu sagen, welcher Preis dafür zu zahlen ist, ist manipulativ. (Und nebenbei, verhindert das auch fallspezifische Lösungen, die vielleicht auch denkbar wären).

Vergleichbares Beispiel ist die Sommerzeit, wo sich leicht eine Mehrzeit gegen die Zeitumstellung findet. Aber genauso finden sich Mehrheiten dagegen, dass es im Winter erst um 10 hell wird (dauernde Sommerzeit) oder im Sommer schon um 3 hell (dauernde Winterzeit). --Global Fish (Diskussion) 10:58, 5. Jul. 2023 (CEST)

Nun ist das hier eine Umfrage und keine Abstimmung im Rahmen eines Meinungsbilds. Das heißt, Du, ich und alle anderen dürfen ihre abweichenden Ansichten oder zusätzliche Aspekte einbringen und die Umfrage entsprechend erweitern. ---<)kmk(>- (Diskussion) 00:17, 6. Jul. 2023 (CEST)

Ich wüsste nicht, was das Einfügen zusätzlicher Punkte bringen sollte. Das Problem liegt in den Ausgangsfragen, die kann ich natürlich nicht verändern.
Ansonsten hatte ich die Probleme, die ich mit der Umfrage sehe, längst vor der Abstimmung hier schon in die Diskussion eingebracht. --Global Fish (Diskussion) 10:44, 6. Jul. 2023 (CEST)

Softwareseitig lösen

Kann man das nicht einfach sw-seitig lösen? Dies betreffend verborgene Zeichen + "falsche Freunde" (CCCP vs. СССР).

• VE + Quelltexteditor mit eingeschaltetem Syntaxhighlight: Verborgene Zeichen + ähnlich aussehende Zeichen (kyrillisch etc.) farbig hinterlegen (ggf. dort Tooltip, was da hinterlegt ist). Bestimmte Texteditoren machen das bereits.
• Reiner Quelltexteditor - Pech gehabt.
• Ggf Zwischenstufe: Reiner Quelltexteditor ohne Syntaxhighlight, aber farbig hinterlegte verborgene Zeichen.

Dann wäre das bewusste Platzieren unsichtbarer Zeichen eigentlich nicht mehr so ein grosses Problem. --Filzstift (Diskussion) 17:21, 5. Jul. 2023 (CEST)

Der Quelltexteditor ist ein TEXTAREA und gehört dem Browser, und in dem gibt es nur plain text und keinerlei Eingriffsmöglichkeiten.

Irgendwer kann gern eine Darstellung in der Syntaxhervorhebung programmieren, aber dort funktionieren dann viele andere Features nicht.

Im VisualEditor wird das auch nicht dargestellt. Kann gern jemand dort programmieren, aber schon seit 2016 bastelt WMDE an der <ref>-Erweiterung mit wiederholten Einzelnachweisen desselben Buchs aber unterschiedlicher Seitenzahlen und scheitert schon seit mehreren Jahren, diese für den Quelltext bereits einsatzfähige Lösung mit dem VisualEditor kompatibel zu machen.

Nur mittels Spezialwerkzeugen für Fortgeschrittene ist es möglich, unsichtbar verborgene Zeichen sichtbar zu machen, aber schon deren Verständnis ist nur einer kleinen Gruppe Techies möglich.

Für Normalsterbliche müssen die Wikitexte ohne Informatikstudium bearbeitbar bleiben. Entities sind schon herausfordernd genug, und was über   und bei ein paar Bildlegenden und Tabellen ­ hinausgeht ist im ANR des Teufels.

Gerade alle Traditionalisten arbeiten im Quelltextmodus, also TEXTAREA, und dort sind verborgene Zeichen grundsätzlich nie von normalem Leerzeichen zu unterscheiden oder völlig unsichtbar.

VG --PerfektesChaos 17:35, 5. Jul. 2023 (CEST)

@Filzstift, ja kann man, müsste nur noch umgesetzt werden: https://phabricator.wikimedia.org/T181677 – und das ist per Javascript grundsätzlich lösbar: https://www.w3schools.com/jsref/prop_textarea_value.asp --ɱ 19:16, 5. Jul. 2023 (CEST)

Das zitierte Phabricator-Ticket betrifft CodeMirror; das ist im Prinzip das gleiche Vorgehen wie Syntaxhervorhebung.

Hierbei wird das TEXTAREA des Browsers ausgeblendet, und es wird eine HTML-Attrappe über das Rechteck des TEXTAREA drübergelegt.

In diesen Syntaxhervorhebungen funktionieren die Werkzeuge nicht, wie etwa die Zeichen-Einfügung durch unsere eigene Werkzeugliste unten oder den WMF-Wikieditor oben.

Die verlinkte w3schools-Seite hat rein überhaupt nichts damit zu tun; das machen wir schon seit zwei Jahrzehnten. Das ist allerdings der Inhalt des TEXTAREA als plain text und bietet keinerlei Eingriffsmöglichkeiten oder Hervorhebungen.

Dass es sich in der Syntaxhervorhebung programmieren ließe, dann aber unter Verzicht auf Bearbeitungswerkzeuge, hatte ich bereits 17:35 dargestellt.

In der Quelltextbearbeitung ohne Syntaxhervorhebung ist es grundsätzlich nicht möglich, weil das TEXTAREA den Browsern gehört und hier grundsätzlich keine Formatierungen möglich sind.

Der Einwurf mit seinen beiden Verlinkungen ist eine krasse Falschbehauptung und pure Nebelkerze.

--PerfektesChaos 19:27, 5. Jul. 2023 (CEST)

Ok, das mit CodeMirror hab ich nicht aufgepasst. Ich hab den VisualEditor testweise ausgeschaltet und edWiki ebenso. Nirgends sehe ich im Quellcode ein TEXTAREA. Wenn hier jemand Nebelkerzen wirft, dann du. Damit ists softwareseitig lösbar, es muss nur umgesetzt werden. --ɱ 22:09, 5. Jul. 2023 (CEST)

Begründung meiner Auswahlpunkte (Benutzer:Dirk123456)

Hallo @PerfektesChaos, erst einmal vielen Dank für deine Bemühungen um gute Konventionen beim Einsatz von Schriftzeichen im Quelltext!

Ich werde an drei Stellen (Sortierung nach Priorität) meine Signatur hinterlassen:

1. #Ablehnung der Umfrage
2. #MB zwingend erforderlich
3. #Richtlinienseite nicht erstellen

Mein Hauptgrund dafür, die Umfrage ablehnen zu wollen, ist der suggestive und bisweilen manipulative Stil, mit dem die Meinung der Teilnehmenden erfragt wird. Wie soll jemand nach seiner oder ihrer Ansicht abstimmen, wenn ihm oder ihr schon „vorgesagt“ wird, welche Meinung er oder sie zu haben hat? Solche Formulierungen wie „ist Projektschädigung“ oder „eine tückische Fallgrube“ sind da eher einschüchternd.

Schon die Überschrift „Absichtliches Einfügen von Zeichen mit verborgener Nebenwirkung“ klingt, als ginge es um Sabotage der Wikipedia. Es geht aber im Kern doch eher um Kleinteiliges. Es ist sicherlich nicht deine Absicht, jemanden zu verunsichern, aber es zählt hier das Ergebnis, da ggf. die gesamte Community damit zurecht kommen müsste.

Das Anliegen selbst, einen klaren Umgang mit bestimmten Zeichen definieren zu wollen, die Schwierigkeiten hervorrufen könnten, ist nachvollziehbar. Diese Umfrage reicht dafür nicht. Ich weiß nicht, ob sich der Aufwand wirklich lohnt: Aber wenn man doch noch etwas Klares zu dem Thema definieren will, brauchen wir dafür zwingend ein Meinungsbild (WP:MB).

Für den Fall, dass ich weder mit der Ablehnung der Umfrage etwas erreichen kann noch mit der Forderung nach einem Meinungsbild, möchte ich anmerken, dass ich lieber keine Richtlinienseite haben möchte.

Unter den Abschnitten:

• #Quelltext-Kosmetik
• #Vorsätzliches Einfügen

werde ich keine Signaturen hinterlassen, da diese Abschnitte meine Unzufriedenheit mit schwierigen Formulierungen am meisten befördern.

Im Folgenden werde ich auf einiges detaillierter eingehen, was aus meiner Sicht wichtig sein könnte. Meine Darstellung ist recht diffus, aber ich habe manches nicht sofort verstanden und anderes vielleicht auch gar nicht.

Worum geht es bei der Umfrage eigentlich? Es geht um solche Sachen, dass jemand in einem Artikel im Quelltext lieber so etwas haben möchte: „Am 7. Juli 1864“, statt so etwas: „Am 7. Juli 1864“ und jemand anders das Gegenteil (diff=next&oldid=234229061). Bei der Zeichenkette „7. Juli“ sieht es erst einmal so aus, als wäre dort ein übliches Leerzeichen verwendet worden, während bei der Zeichenkette „7. Juli“ ein geschütztes Leerzeichen verwendet wurde, nämlich das HTML-Entity „ “.

Ich habe eine Weile gebraucht, um festzustellen, dass das anscheinend normale Leerzeichen bei „7. Juli“ ebenfalls ein geschütztes Leerzeichen ist, aber ein solches, welches man auch im Quelltext nicht als geschütztes erkennt (jedenfalls nicht mit jeden Editor). Ich dachte anfangs, es ginge bei „verborgener Nebenwirkung“ auch um solche HTML-Entitäten, die ihr Verhalten in der normalen Browseransicht nur unter Umständen zeigen, nämlich dann, wenn sie am Zeilen-Ende stehen – wie es bspw. bei „ “ (als geschütztes Leerzeichen) und bei „­“ (als bedingter Bindestrich) der Fall ist.

Da unter „Außerhalb dieser Umfrage“ Folgendes steht:

• „Grundsätzlich nicht Thema dieser Umfrage ist die Frage, an welchen Stellen des Wikitextes im ANR welcher Umbruchschutz oder weiche Trennzeichen mittels sichtbarer Möglichkeiten (Entity, Vorlagen) eingearbeitet werden.“,

hätte ich mir vielleicht auch schneller erschließen können, dass es nur um solch Verborgenes gehen, dass auch nach Betrachten des Quelltextes verborgen bleiben würde. Ich dachte aber anfangs, dass es bei der Umfrage dennoch bspw. um HTML-Entities allgemein gehen würde, also darum, ob sie genutzt werden dürfen oder nicht, aber nicht darum, an welchen Stellen des Wikitextes im ANR genau. Ich dachte eher, dass es nicht um Detail-Fragen gehen soll, also bspw. nicht um so etwas, wie viele „­“-Elemente in einem langen Wort an welchen Stellen enthalten sein dürfen.

Für einen Autor wie mich besteht oft kein allzu großer Unterschied zwischen solchen Zeichen im Quelltext, deren Codierung kryptisch anmutet und solchen Zeichen, die wirklich nicht erkennbar sind, obwohl sie im Quellcode stehen: Daher bezieht sich das Wort Wirkung – bspw. für eine „verborgene Nebenwirkung“ – bei so einer Leseweise vorrangig auf das Ergebnis, die „normale“ Ansicht im Webbrowser.

Manchmal sind solche Zeichen, deren Verhalten man nicht in jedem Kontext sofort bemerkt, durchaus nützlich. Ich verwende außerhalb vom Artikelnamensraum (WP:ANR) gelegentlich lieber den geschützten Bindestrich als einen ungeschützten. Die Zeichenkette „‑“ funktioniert da meiner Erfahrung nach von den HTML-Entities am besten, um bspw. solch einen Namen: „SARS‑CoV‑2“ (Quellcode hier: „SARS‑CoV‑2“) nicht wie einen anderen Namen: „SARS‑CoV“ aussehen zu lassen, weil sonst „SARS‑CoV‑“ und „2“ in verschiedenen Zeilen stehen könnten (der Quellcode wäre normalerweise: „SARS‑CoV‑2“).

Damit diese Darstellung: „‑“ hier nicht wie dieses Zeichen: „-“ angezeigt wird, schreibt mir der VE (Hilfe:VisualEditor) einen anderen Code in den Quelltext: „‑“. Das Maskieren und Demaskieren von Zeichen ist recht aufwändig, unübersichtlich und daher fehleranfällig, wenn man es „per Hand“ und mit dem „unbewaffneten Auge“ anwendet. Deshalb verwende ich solche „Sonderlocken“ – wie „ “, „‑“ oder „­“ – eigentlich nur da, wo im Regelfall niemand anders meinen hinterlassen Quelltext editieren muss, also bisher nicht im Artikelnamensraum.

Und da bin ich bereits bei einem zweiten Punkt, der mir wichtig ist: Die Einbindung von potentiellen oder tatsächlichen Autorinnen und Autoren, die zum Projekt beitragen können, die aber keine Expertinnen oder Experten für das „Jonglieren mit Wikitext“ sind. Ich schreibe bewusst nicht „Neulinge“, weil ich nicht voraussetzen möchte, dass jemand ihr oder sein Sachgebiet vernachlässigen muss, um Expertin oder Experte für all das Spezielle hier zu werden.

Es gibt im „techniklastigen Wikisprech“ Formulierungen, die sich für jemandem, die oder der sich nicht hauptsächlich damit beschäftigt, nicht unmittelbar erschließen.

Was ist z. B. „Quelltext-Kosmetik“? Unter der Überschrift „Quelltext-Kosmetik“ steht, dass der Ersatz von Zeichen mit verborgen wirksamer Kodierung durch eine offen erkennbare Zeichenkodierung keine „reine Quelltext-Formatierung“ sei, wobei auf Folgendes verknüpft wird: Hilfe:Kleine Änderungen#Was keine kleinen Änderungen sind. Aber weder unter „#Was kleine Änderungen sind“ noch unter „#Was keine kleinen Änderungen sind“, steht etwas über „Quelltext-Kosmetik“ oder über „reine Quelltext-Formatierung“. Die unter der Überschrift stehenden Statements wirken dann so, als ob danach gefragt werden soll, ob jemand nach dem Ersatz von bestimmten Zeichen durch besser geeignete Zeichen vor dem Speichern den Haken für K – „Nur Kleinigkeiten wurden verändert“ – setzen sollte oder nicht.

Nur darum, ob die Markierung K beim Speichern einer Bearbeitungsversion zutrifft, wird es aber kaum gehen. Ich vermute, dass „Quelltext-Kosmetik“ und „reine Quelltext-Formatierung“ synonym gebraucht werden und dass beides nur kleine Änderungen wären, während der „Ersatz von Zeichen mit verborgen wirksamer Kodierung durch eine offen erkennbare Zeichenkodierung“ weder kleinen Änderungen wären, noch „reine Quelltext-Formatierung“, noch „Quelltext-Kosmetik“. Das leitete ich aber weniger aus dem ab, was geschrieben steht, sondern eher aus einer schwammigen Vorahnung, das „Kosmetik“ hier eher nichts Gutes bedeuten soll. Durch die Anordnung von Formulierungen in der Überschrift und im unmittelbar folgendem Text:

• »Quelltext-Kosmetik« ― »Der Ersatz von ... durch ... gilt grundsätzlich nicht als „reine Quelltext-Formatierung“, ...«,

könnte man aber auch auf den Gedanken kommen, dass der „Ersatz von ... durch ...“ etwas anderes wäre als „reine Quelltext-Formatierung“, nämlich „Quelltext-Kosmetik“. Die „Quelltext-Kosmetik“ wäre dann mehr als „reine Quelltext-Formatierung“. Wie auch immer, aus meiner Sicht wäre es einfacher zu verstehen, wenn der Bezug zwischen einem Ausdruck und einer Maßnahme direkt explizit angegeben worden wäre. So bleibt es ein wenig unklar:

• »Quelltext-Kosmetik« ←?→ »Ersatz von Zeichen mit verborgen wirksamer Kodierung durch eine offen erkennbare Zeichenkodierung«,

Ich versuche mal zu erklären, wie ich es bisher verstehe: Wahrscheinlich ist mit „Quelltext-Kosmetik“ und „reiner Quelltext-Formatierung“ gemeint, dass nur der Quell-Code – also der Wikitext – verändert wird, um ihn zu „verschönern“, ohne dass sich das in irgendeiner Weise auf das Ergebnis auswirkt: Das Ergebnis ist hier die Ansicht der Schrift- und Bildelemente eines Artikels im normalen Lesemodus in einem Webbrowser. Ich präsentiere mal ein Beispiel, um zu zeigen, was das Wort „Quelltext-Kosmetik“ meiner Annahme entsprechend bedeuten könnte:

Beispiel für meine angenommene Bedeutung von „Quelltext-Kosmetik“

Es ist ja meist ziemlich egal, ob für „des Baums“ im Quelltext die kurze Form, „des [[Baum]]s“, steht oder die längere, „des [[Baum|Baums]]“. Für sehr viele Verknüpfungen gibt es ohnehin nur die lange Form – für „die Bäume“ ist es bspw. „die [[Baum|Bäume]]“. Bei „Quelltext-Kosmetik“ akzeptiert jemand bei zwei Varianten im Quelltext, die genau dasselbe in der normalen Ansicht des Webbrowsers bewirken, wahrscheinlich nur eine dieser Varianten. Der eine sieht vielleicht „des [[Baum]]s“ lieber als „des [[Baum|Baums]]“ im Quelltext, während die andere dort lieber „des [[Baum|Baums]]“ sieht als „des [[Baum]]s“. Wer „des [[Baum|Baums]]“ lieber mag, findet vielleicht auch „der [[Baum|Baum]]“ toll, während für denjenigen, der „des [[Baum]]s“ mag, die Form „der [[Baum|Baum]]“ möglicherweise des Teufels wäre. (Letztes müsste derjenige durch „des [[Teufel]]s“ verlinken.) Dem VE (Hilfe:VisualEditor) ist es egal: Er schreibt zwar selbst immer nur die stets anwendbare allgemeine Form „[[Linkziel|Linktext]]“ in den Quelltext, das wäre zum Beispiel „der [[Baum|Baum]]“, versteht aber alle anwendbaren Formen, „der [[Baum]]“, „der [[Baum|Baum]]“, „des [[Baum]]s“ usw. Der VE betreibt keine „Quelltext-Kosmetik“, da er alles, was er nur liest, aber nicht bearbeiten muss, so lässt, wie es ist und dort nicht seinen Quelltext-Schreibstiel anwendet.

Wenn man aber statt der HTML-Entität „ “ als geschütztes Leerzeichen irgendein anderes Zeichen nimmt, dass sich in der normalen Leseansicht eines Artikel im Webbrowser zwar genau so wie „ “ als geschütztes Leerzeichen auswirkt, aber im Quelltext wie ein normales Leerzeichen aussieht, ist es was anderes als bei den oben genannten Verknüpfungsbeispielen, bei denen im Quelltext alle Zeichen vollständig sichtbar und nicht mehrdeutig sind.

Der Ausdruck „reine Quelltextformatierung“ deutet an, dass nur Quelltext verändert wird, ohne dass sich woanders was ändert.

Genau deswegen halte ich den Ausdruck „reine Quelltextformatierung“ für ungeeignet, bei den geänderten Zeichen was unterscheiden zu wollen. In beiden Fällen, wenn eindeutig sichtbare Zeichen im Quelltext ausgetauscht werden und wenn unsichtbare/ mehrdeutige u. ä. Zeichen im Quelltext ausgetauscht werden, ohne dass sich in der normalen Leseansicht eines Artikel im Webbrowser etwas ändert, wäre der Ausdruck „reine Quelltextformatierung“ plausibel: Man gestaltet den Quelltext zwar anders, aber man formatiert die Normalansicht nicht anders (also die normale Leseansicht eines Artikel im Webbrowser).

Das Anliegen selbst, im Wikitext etwas, das man nicht eindeutig sehen kann, lieber gegen etwas auszutauschen, was man eindeutig sehen kann, ist für mich nachvollziehbar.

Ich glaube in Bezug auf eine Verbesserung eher an neue Technik, um Nutzende beim Editieren zu unterstützen, als dass ich an Richtlinien glaube, die Autorinnen und Autoren auch erst einmal finden und verstehen müssen, um sie umzusetzen.

In letzter Zeit hat sich da was getan: Die Diskussionstools kommen zwar noch nicht ganz ohne Wikitext-Bearbeitung aus, aber es ist möglich auf den Beantworten-Knopf zu drücken und dann erhält man ein Feld, welches Bedienelemente enthält, u. a. für die Möglichkeit, zwischen „Visuell“ und „Quelltext“ umzuschalten. Wenn ich da versuche, etwas zu kopieren, was ich auf meinem PC vorbereitet habe, sehe sich seit geraumer Zeit zwar immer mal wieder etwas, was sich geändert hat und wahrscheinlich mit angepassten Verwirklichungen von Umbrüchen u. ä. zu tun hat, die aus fremden Systemen stammen; insgesamt bin ich aber ganz zufrieden.

Ich denke, dass es nicht mehr sooo lange dauert, bis die hiesige Software da Möglichkeiten anbietet, die versteckten Zeicheneigenschaften von woanders „gut zu verdauen“.

Ich würde es begrüßen, wenn ein Wort wie dieses:

• „Gipskartonplattendübeleinsetzwerkzeug“

in der Editieransicht eines Artikels nicht so aussehen würde:

• „Gips­kar­ton­plat­ten­dü­bel­ein­setz­werk­zeug“

Das Wort ist nicht offiziell; es handelt sich dabei um einen kleinen Stift, mit dem ich schon viele Dübel in eine Platte aus Gipskarton gebohrt habe. Hier dient das Wort als ausgedachtes Beispiel für ein sehr langes solches, bei dem einige bedingte Bindestriche als recht sinnvoll erscheinen würden. (Wenn man den Bedeutungsinhalt tatsächlich als Begriff adressieren müsste, wäre der passende Ausdruck wahrscheinlich eher „Setzwerkzeug für Gipskartondübel“)

Für Autorinnen und Autoren, die vielleicht nur über Wikitext-Kompetenz mit „verborgener Nebenwirkung“ verfügen, für Personen, die eigentlich keinen Wikitext schreiben wollen, sondern nur direkt formatierten Text (WYSIWYG), ist beides unschön: Sowohl die verborgenen bedingten Bindestriche, die zumeist aus Wiki-fremden Anwendungen kommen, als auch die Code-Elemente im Wikitext, die dem letztlichen Schriftbild in der Lesansicht nicht ähneln.

Es gibt auch Zeichen, deren Verborgenheit unterschiedlich definiert werden müsste, je nachdem, woher sie kommen. Jene bedingten Bindestriche, welche ich testhalber aus einen MS-Word-Dokument kopiert hatte, wurden mir im nahezu WYSIWYG-fähigen Editor VE (H:VE) gar nicht und im Quelltexteditor WikEd (WP:WikEd/Hilfe) vermittels einer Art hellblauer Bindestriche mit einem Buchstaben darüber („s“ – wahrscheinlich für „shy“) angezeigt.

Dasselbe Zeichen, nämlich der bedingte Bindestrich aus MS Word, ist in zwei Anwendung was Verschiedenes:

• Im VE ist es ein „verborgenes Zeichen mit der Hauptwirkung ‚bedingter Bindestrich‘“ und
• im WikED ist es ein „sichtbares Zeichen mit der Hauptwirkung ‚bedingter Bindestrich‘“.

Ob das Zeichen eine verborgene Nebenwirkung hat, weiß ich nicht. Insofern wäre das Zeichen für mich eines „mit potentiell verborgener Nebenwirkung“, da es aus einen fremden System stammt. Die Hauptwirkung vom bedingten Bindestrich ist ja eigentlich, in der Leseansicht meist nicht sichtbar zu sein: Es ist dann sozusagen die „verborgene Nebenwirkung“ manchmal am Zeilenende aufzutauchen, wenn dort ein Zeilenumbruch verursacht wurde. Das trifft aber auch für „­“ zu; deshalb habe ich anfangs gedacht, es geht in dieser Umfrage um alle geschützten oder bedingten Leerzeichen, Binde- oder Trennstriche, Umbrüche o. ä. usw. usf.

Und da sind wir wieder bei den Begriffen. Wenn man aus all dem Verborgenen Maßnahmen für oder gegen Bearbeitende von Wikipedia-Artikeln ableiten wollte, müsste man die Begriffe bezüglich der Ausdrücke und ihrer Bedeutungsinhalte um einiges besser adressieren als es in dieser Umfrage der Fall ist.

Was sollte ich denn damit anfangen, wenn etwas, das ich nicht richtig verstanden habe, „unerlaubt“ wäre?

Ich habe es jetzt so gelesen, dass absichtliche Sachen eigentlich verboten werden müssten und versehentliche – bspw. durch Kopieren – zu oft vorkommen, als dass man sie wirklich verbieten könnte.

Was macht man aber damit, wenn jemand weiß, dass sein Geschriebenes etwas enthalten könnte, was weder richtig erlaubt noch richtig verboten ist und es dann kopiert? (Das Wort „unerlaubt“ wollte ich im vorausgehenden Satz nicht nochmal hinschreiben, sonst glaube ich selbst noch daran, dass man es allgemein versteht.) Sagt bei „unerlaubten“ Dingen jemand:

• „Zweimal lass ich dir das durchgehen, aber beim dritten Mal wirst du infinit gesperrt! Du musst sämtliche Zeichen, von denen du jetzt weißt, dass sie für kritisch gehalten werden, auch wenn du sie nicht richtig siehst, selbständig in HTML-Entities – oder noch besser: in Einbindungen von Vorlagen – umwandeln, bevor du deinen Text einfügst! ...“

Ich weiß nicht so recht. Wenn aus dieser Umfrage eine anwendbare Richtlinie erwachsen sollte, wäre noch einiges zu tun.

Bspw. müsste eine Art von „Slang-Wörtern“ u. ä., die gegenwärtig verwendet werden, um in Ermangelung besserer Begriffe etwas darzustellen, durch eindeutig definierte Ausdrücke und Formulierungen ausgetauscht werden. Bei der Maßnahme, um die es hauptsächlich geht, dem Ersatz der einen Zeichen durch die anderen Zeichen wären wahrscheinlich drei Begriffe hilfreich: Einer für die einen Zeichen, einer für die anderen Zeichen und einer für den Ersatz. Für den Ersatz von Zeichen durch andere Zeichen würde man vielleicht einfacher ausdrücken können, was dieser Ersatz ist, wenn man nicht versucht zu beschreiben, was er nicht ist. (Wenn der Ersatz bspw. keine „pure Quelltextformatierung“ ist, was ist er dann? Der einfachste gegenteilige Ausdruck, „unpure Quelltextformatierung“, würde für den Ersatz von Zeichen gegen andere sicher nicht praktikabel sein.)

Ich weiß, dass klare Definitionen nicht einfach sind und könnte im Detail kaum etwas Hilfreiches beitragen. In einer vor Kurzem erfolgten Umfrage, Wikipedia:Umfragen/KI-generierte Artikel, wurde mit Nummern gearbeitet, bspw. für diesen Umfragepunkt: „Ich bin für Variante 1 (Status quo: Das Regelwerk reicht aus)“. Das fand ich ganz geschickt, da man als „Umfragender“ davon befreit ist, sich irgendwelche Begriffe auszudenken, die es eigentlich nicht gibt. Man beschrieb die Varianten 1 bis 4 und das ergibt dann quasi vier Begriffe mit jeweils einem Ausdruck und einem einzigen Bedeutungsinhalt.

Naturgemäß kann eine einzelne Person ihre eigene Meinung flüssiger formulieren als die widersprechenden Alternativen dazu. Wenn mehrere Personen bei einer Umfrage oder einem Meinungsbild konstruktiv kooperieren könnten, wäre die Wahrscheinlichkeit, dass es am Ende ungefähr so rüberkäme:

• »„Variante 1 ist alternativlos.“, „Variante 2 ist Projektschädigung, aber unterschreibt ruhig!“, ...«,

als wenn ein Thema nur aus der Perspektive einer einzelnen Person beleuchtet wird.

@PerfektesChaos, meine Ablehnung bezieht sich nur auf den Text der Umfrage und nicht auf dich. Ich respektiere deinen Einsatz für Verbesserungen in der Wikipedia, habe hier aber in der Summe andere Vorstellungen, wie man dahin kommen könnte. (Leider sind das keine besonders konkreten Vorstellungen.) Hier wird nach meinem bisherigen Ermessen – im übertragenen Sinne – mit Kanonen auf Spatzen geschossen, ohne dass die Kanonen besonders zielgenau wären. Ich fürchte mich mehr vor einer umfassenden, aber schwammigen und nicht von jeder und jedem verstandenen Richtlinie, als dass ich mich vor den systemfremden Zeichen fürchten würde, die gelegentlich in den Quelltext gelangen. Die im Wiki-System besser verwaltbaren Elemente (bspw. HTML-Entitäten) sind für Autorinnen und Autoren auch nicht gerade flüssig im Quelltext zu lesen. Das, was hier durch „Außerhalb dieser Umfrage“ ausgeklammert wurde (unter #Problematik), müsste bei einem Zustandekommen einer Richtlinie – glaube ich – ebenfalls berücksichtigt werden.

MfG --Dirk123456 (Diskussion) 10:28, 31. Jul. 2023 (CEST)

„In der Kürze liegt die Würze.“ -- Gruß, aka 10:40, 31. Jul. 2023 (CEST)

Ich wollte nichts würzen. MfG --Dirk123456 (Diskussion) 14:28, 31. Jul. 2023 (CEST)

Zu deinen umfangreichen Ausführungen nur eine Erläuterung des von dir angesprochenen Begriffs Quelltext-Kosmetik: Die im umseitigen Abschnitt Quelltext-Kosmetik stehende Aussage „… gilt grundsätzlich nicht als ‚reine Quelltext-Formatierung‘“ mit Link auf Hilfe:Kleine Änderungen #Was keine kleinen Änderungen sind bezieht sich nicht auf die Frage, welche Bearbeitungen mit einem K (für kleine Änderung) zu kennzeichnen sind und welche nicht, sondern auf den grün eingerahmten Kasten auf dieser Hilfeseite, in dem es heisst: „Ein Edit soll immer mindestens zu einer nach aussen sichtbaren oder wirksamen Veränderung führen.“ Diese Bestimmung gilt ebenso für kleine wie für grosse Änderungen. Eine Bearbeitung, die nicht zu einer nach aussen sichtbaren oder wirksamen Veränderung führt, ist in der Regel eine rein kosmetische Änderung des Quelltextes. Solche kosmetischen Änderungen sind selbstverständlich zulässig, wenn sie zusammen mit substantiellen Änderungen nebenbei mit durchgeführt werden; aber sie sollen nicht der einzige Inhalt einer Bearbeitung sein.

Diese Regel ist bewusst nur als eine Soll-Regel formuliert worden; d.h. es kann Ausnahmen geben – also Änderungen, die nicht nach aussen sichtbar oder wirksam sind und trotzdem keine rein kosmetischen Änderungen sind und damit auch dann zulässig sind, wenn sie der einzige Inhalt einer Bearbeitung sind. Das sind zum Beispiel solche Änderungen, die nachfolgenden Bearbeitern eines Artikels die Arbeit erleichtern. Ein typisches Beispiel dafür ist etwa die Einfügung eines auskommentierten (und damit nach aussen unsichtbaren) Sic-Vermerks, wenn man in einem Zitat aus einem Buch einen Rechtschreibfehler entdeckt hat. So bin ich einmal über einen Kommafehler in einem Zitat gestolpert, und da wusste ich nicht: Ist dieser Fehler auch schon im Original vorhanden, oder ist es nur ein Abschreibfehler? Nur im zweiten Fall durfte ich ihn korrigieren. Also bestellte ich mir das Buch in der Staatsbibliothek und suchte die Bibliothek auf, nur um festzustellen, ob das Komma an der Stelle auch dort fehlte. Ergebnis: Ja, der Kommafehler war auch in dem Buch vorhanden. Also durfte ich ihn nicht korrigieren. Stattdessen habe ich im Quelltext einen (auskommentierten) Sic-Vermerk hinzugesetzt. Das hatte keine im Artikel sichtbare Auswirkung; aber jedem nachfolgenden Leser des Artikels, der ebenso wie ich über den Kommafehler in dem Zitat stolpert, ist es damit nun erspart, dass er den gleichen Aufwand auf sich nimmt, wie ich es getan habe, um die Frage zu klären. Solch eine Änderung des Quelltextes ist selbstverständlich immer zulässig, obwohl sie keine sichtbare oder wirksame Änderung des Artikels erzeugt – also keine reine Kosmetik.

Ein anderes Beispiel für eine Änderung im Quelltext, die keine sichtbare oder wirksame Auswirkung hat, ist das Ersetzen eines unsichtbar geschützten Leerzeichens durch ein &nbsp; oder eines unsichtbaren weichen Trennzeichens durch ein &shy;. Im Artikel sichtbar sind jeweils beide in den meisten Fällen nicht – ausser wenn es zufälligerweise ans Ende einer Zeile fällt; und sie haben auch beide im Artikel die gleiche Wirkung, nämlich an der Stelle einen Zeilenbruch zu verhindern bzw. eine Silbentrennung zu ermöglichen. Solch eine Änderung ist zwar keine Verschönerung des Quelltextes, aber doch eine Verbesserung, insofern sie nachfolgende Bearbeiter, die den besonderen Charakter dieser unsichtbaren Merkmale nicht erkennen können, vor Irrtum oder Verwirrung bewahrt – dies umso mehr als solche unsichtbaren Zeichen leicht unwissentlich an andere Stellen kopiert werden können, wo sie keinen Sinn geben und eine schädliche Wirkung haben können. So war ich vor einiger Zeit mit einem Fall konfrontiert, in dem ein <references />-Tag aus scheinbar unerklärlichen Gründen nicht richtig funktionierte. Als Ursache stellte sich schliesslich heraus, dass das Leerzeichen vor dem Schrägstrich ein unsichtbar umbruchgeschütztes war, das auf eine nicht mehr nachvollziehbare Weise dort hineingeraten war. Darum ist solch eine Änderung keine reine Kosmetik; denn dadurch kann nachfolgenden Bearbeitern viel Verdruss erspart werden. Und es ist vollkommen richtig, so etwas als eine tückische Fallgrube zu bezeichnen, deren Beseitigung in jedem Fall eine Verbesserung ist. --BurghardRichter (Diskussion) 12:26, 31. Jul. 2023 (CEST)

Nein, eben nicht. Ich habe schon oft gesagt, dass nbsp falsch ist, weil es den Regeln der deutschen Sprache widerspricht. Die deutsche Sprache ist, um das makl auch für anglophile Zeitgenossen verständlich zu machen, freeware, aber nicht open source. Sie darf von jedem kostenlos benutzt, aber nicht eigenmächtig verändert werden. Das Regelwerk sieht nun einmal zwischen Wert und abgekürzter Einheit ein schmales geschütztes Leerzeichen vor. Darüber müssen wir nicht diskutieren. Genausogut könntest Du den Nieselregen im Nobember verbieten. &nbsp; war eine Krücke, als die nur für die englische Sprache passende Zeichencodierung ASCII für andere Sprachen erweitert wurde. Seit der generellen Einführung von Unicode gibt es keinen Grund für solche Versimpelungen mehr. Es gab für &nbsp; auch nie einen Konsens. Den wird es auch nicht geben, und das geht zu großen Teilen auf Deine Unduldsamkeit und die des Initiators dieses Versuchs, insbesondere mich loszuwerden, zurück. Nicht nur, dass diese Umfrage ausgesprochen demagogisch und suggestiv formuliert ist, sie geht auch von falschen, weil persönlichen Voraussetzungen aus. Wenn man eine Festbreitenschriftart im Editorfenster benutzt, dann kann man Zeichenbreiten natürlich nicht auseinanderhalten. Nur ist das, weil in praktisch jedem Browser einstellbar, eine persönliche Entscheidung und wer sie trifft, der muss auch mit den Konsequenzen klarkommen. Deshalb die Gemeinschaft in Geiselhaft nehmen, das kann es nicht sein.

Wie oft muss ich eigentlich noch sagen, dass es im Endprodukt (nur darum geht es, der Quelltext ist mittel zum Zweck und für die, die sich damit nicht abgeben können oder wollen, gibt es schließlich auch den visuellen Editor) eben doch viel ausmacht, ob ein Leerzeichen schmal, normal oder überbreit ist. Darauf ging nie jemand ein. Und ich soll jetzt und nach dem, was bei jedem anderen ein persönlicher angriff wäre, &nbsp; setzen? Die Antwort muss ich wohl nicht tippen. –Falk2 (Diskussion) 13:32, 31. Jul. 2023 (CEST)

Du bringst einiges durcheinander. Grundsätzlich: Es geht bei den Leerzeichen nicht um Regeln der deutschen Sprache, auch nicht einer anderen Sprache, sondern es geht um sprachunabhängige Regeln der Typographie. Ausserdem geht es in dieser Umfrage nicht um die typographische Frage, in welchen Fällen Leerzeichen normalbreit oder schmaler sein können oder sollen, und es geht auch nicht um die Frage, in welchen Fällen sie umbruchgeschützt sein sollen oder nicht, sondern es geht u.a. darum, ob ein Leerzeichen, welches sich in seiner Breite oder bezüglich seines Umbruchschutzes von einem gewöhnlichen (d.h. normalbreiten, nicht geschützen) Leerzeichen unterscheidet, im Quelltext eines Wikipediaartikels offen als solches erkennbar sein soll oder solche Eigenschaften einem – scheinbar gewöhnlichen – Leerzeichen auch unsichtbar anhaften dürfen. --BurghardRichter (Diskussion) 14:16, 31. Jul. 2023 (CEST)

Hallo Burghard, hier liegt das Probleme daran, dass der grüne Kasten unter Hilfe:Kleine Änderungen #Was keine kleinen Änderungen sind völlig deplaziert ist. Sowohl unter der Überschrift, als auch auf der ganzen Seite. Unerwünschte Geschmacksänderungen und kleine Änderungen sind zwei verschiedene Paar Schuhe.
Ein Edit, das ausschließlich eine falsche Formatierung in eine richtige umwandelt, ist natürlich keine kosmetische Änderung (grüner Kasten), aber dennoch eindeutig eine kleine Änderung (also falsch unter der Überschrift). Umgekehrt ist ein Edit, dass *neben* ein paar inhaltlichen Sachen auch reine Geschmacksänderungen beinhaltet, natürlich *keine* kleine Änderung, dennoch macht das die Geschmacksänderungen nicht akzeptabler.
Für diese Falschdarstellung dort kann diese Umfrage hier freilich nichts; wobei sie den Initiator beim Erstellen der Umfrage auch ein wenig durcheinander gebracht hat, siehe oben.
Und generell: Es gibt *keine* Konsensregelung für das Einfügen umbruchgeschützter schmaler Leerzeichen.
Du und ich können uns trefflich streiten, ob wir nun „120,8 km/h“ oder „120,8 km/h“ (mit umbruchgeschütztem schmalen LZ) für das kleinere Übel halten. Genau *darüber* (was ist nun das kleinere Übel?) könnte man durchaus eine Umfrage machen. Aber dann müsste man das auch eben so fragen. Hier werden einseitig die (ja durchaus vorhandenen Nachteile) der einen Variante dargestellt, ohne auf die Nachteile der anderen Variante zu verweisen. Und ohne darauf zu verweisen, dass die andere Variante auch nicht richtlinienkonform ist, sondern im Gegenteil mit dem Verweis auf den grünen Kasten zu suggerieren, es wäre eine Änderung unerwünscht -> erwünscht. Ich glaube nach diversen Diskussionen keineswegs, dass PC hier etwas bewusst vortäuschen wollte, sondern halte das für ungenaues Arbeiten.Mit Bedauern gestrichen, siehe unterster Thread. Aber es ändert nichts daran: ich halte die Fragestellung uneingeschränkt für manipulativ, und, Burghard, ich fände es schön. wenn wir uns auf diesen Minimalkonsens einigen könnten.
Nicht sachlich korrekt finde ich bereits die Überschrift „Zeichen mit verborgener Nebenwirkung“. Das Zeichen „ “ hat vielmehr eine ganz genau definierte Wirkung, keine verborgene Nebenwirkung. Es ist ein umbruchgeschützes schmales Leerzeichen, nicht mehr. Sein Problem (und das Problem ist ja unbestritten da), ist dass es im Quelltext nicht von einem normalen LZ unterscheidbar ist. Grüße, --Global Fish (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von Global Fish (Diskussion | Beiträge) 13:54, 31. Jul. 2023 (CEST))

Hallo Global Fish, Dass der grün eingerahmte Kasten, um den es hier geht, auf Hilfe:Kleine Änderungen #Was keine kleinen Änderungen sind deplaziert ist, darüber bin ich mit dir vollkommen einer Meinung. Das ist aber nicht hier, sondern dort zu diskutieren. Dadurch ist leider der Aspekt der „kleinen Änderungen“ auf diese Diskussionsseite geraten, obwohl er überhaupt nichts mit dem Thema zu tun hat.

Zu der von dir aufgeworfenen Frage: Ich halte sowohl 120,8 km/h als auch 120,8 km/h für unakzeptabel, aber aus ganz verschiedenen Gründen, die man schlecht miteinander vergleichen kann. Die Schreibweise eines schmalen umbruchgeschützten Leerzeichens in der Form &#8239; wird im allgemeinen aus gutem Grund abgelehnt, weil sie, besonders in der Nachbarschaft von Zahlen, den Quelltext schwer lesbar und schwer bearbeitbar macht. (Wenn es hierfür anstelle der numerischen Kodierung eine Buchstabenkodierung, ähnlich wie „nbsp“ oder „thinsp“ gäbe, sähe die Sache schon etwas anders aus.) Darum geht es aber in dieser Umfrage nicht, sondern es geht allein um die andere Schreibweise. Das darin enthaltene schmale Leerzeichen erscheint im Quelltext in der Schriftart meines Browsers (Firefox) exakt genauso wie ein gewöhnliches (normalbreites) Leerzeichen, und ich nehme an, dass es in anderen Browsern ebenso ist. In einer früheren Version von Firefox sah es dagegen bei genauem Hinsehen schmaler als ein gewöhnliches Leerzeichen aus. Es scheint also tatsächlich vom verwendeten Browser abzuhängen. Dennoch: Die Eigenschaft des Umbruchschutzes ist dem in dieser direkten Form angegebenen Zeichen in keinem Fall anzusehen, genauso wenig wie bei einem umbruchgeschützten normalbreiten Leerzeichen. Das Anliegen dieser Umfrage ist es, dass Schriftzeichen, die unsichtbar mit solchen besonderen Eigenschaften behaftet sind, in der deutschen WP nicht zulässig sein sollen.

Ja, das Zeichen hat eine genau definierte Wirkung. Aber diese, von einem gewöhnlichen (nicht umbruchgeschützten) Leerzeichen abweichende, Wirkung ist im Quelltext nicht klar erkennbar. Daher kann man durchaus von einer „verborgenen“ Nebenwirkung sprechen. Denn kein normaler Benutzer würde bei einem Leerzeichen, das exakt wie ein gewöhnliches (nicht umbruchgeschütztes) Leerzeichen aussieht, vermuten, dass es etwas anderes sein könnte. Wenn ich in meinen privaten Texten so etwas verwende, ist es unschädlich; denn da weiss ich ja, an welchen Stellen ich umbruchgeschützte (oder auch schmale oder mit beiden Eigenschaften behaftete) Leerzeichen verwende, und die Quelldatei wird von niemand anderem als von mir selbst bearbeitet. Aber in einem Gemeinschaftsprojekt wie der Wikipedia geht das meines Erachtens nicht. Da muss man sich darauf verlassen können, dass im Quelltext ein Zeichen, das wie ein gewöhnliches Leerzeichen aussieht, auch tatsächlich ein gewöhnliches Leerzeichen ist. Und ein anderes als ein gewöhnliches Leerzeichen muss als solches erkennbar sein. Wenn wir davon Abweichungen zulassen, passieren rätselhafte, scheinbar nicht erklärbare Dinge; das ist in der Wikipedia untragbar. --BurghardRichter (Diskussion) 15:37, 31. Jul. 2023 (CEST)

Meiner Ansicht nach müsste die Verantwortung eher bei der Software als bei den Nutzenden liegen (Bezugnahme auf 15:37, 31. Jul./ @BurghardRichter). Ein System sollte selbst erkennen können, was zu ihm gehört und was fremd ist. Das Fremde müsste ein System beim Einfügen in etwas Eigenes umwandeln oder aussieben.

Wenn ein systemfremdes geschütztes Leerzeichen von der Wikisoftware auch wie ein geschütztes Leerzeichen eingesetzt wird, dann wird es doch vermutlich von irgendeiner Softwarekomponente zu irgendeinem Zeitpunkt als geschütztes Leerzeichen erkannt, oder? Wäre es da nicht besser, wenn die Software die fraglichen Zeichen gleich beider „Annahme“ Import umwandelt oder beseitigt?

Wahrscheinlich stelle ich mir das zu einfach vor. Es wird vermutlich nicht zu jedem Zeitpunkt alles vollständig geprüft und auch nicht von jeder Softwarekomponente, da es sonst zum Kollaps kommen würde. Ich glaube trotzdem eher, dass die Software automatisch etwas farbig markiert, aussiebt oder umwandelt, als dass wir hier mit Richtlinien Transparenz ins Verborgene bringen.

Ein Punkt ist dabei, dass man das absichtliche Einfügen solcher Zeichen zwar verbieten könnte; aber man kann doch kaum verhindern, dass solche Zeichen unbeabsichtigt im Wikitext landen. Dann „passieren rätselhafte, scheinbar nicht erklärbare Dinge“, ohne dass man mit einer Richtlinie zum Verhalten von Nutzenden wirklich weiter kommt.

Du hast eigentlich Recht damit:

• „Denn kein normaler Benutzer würde bei einem Leerzeichen, das exakt wie ein gewöhnliches (nicht umbruchgeschütztes) Leerzeichen aussieht, vermuten, dass es etwas anderes sein könnte.“

Na ja ...

MfG --Dirk123456 (Diskussion) 17:59, 31. Jul. 2023 (CEST)

Natürlich, die allermeisten, die solche Zeichen in Artikel einfügen, machen das unbewusst und damit auch unabsichtlich, indem sie Textpassagen von irgendwoher einkopieren. Man sieht es ja nicht, und darum merken sie auch nichts davon. Da wäre es selbstverständlich nicht recht und billig, die Kollegen dafür zur Verantwortung zu ziehen, und das will ja auch keiner. Und ja, soweit ich weiss, gibt es auch Bots, die solche unbeabsichtigt eingefügten Zeichen aufspüren und in regelkonforme sichtbare ASCII-Darstellung, etwa mit &shy; oder &nbsp;, umwandeln, und dann können menschliche Mitarbeiter entscheiden, ob diese Darstellung so bleiben kann oder ganz entfernt werden soll. Dagegen hat auch niemand etwas. Dass so etwas unbeabsichtigt eingeschleppt wird, werden wir natürlich auch mit einer neuen WP-Richtlinie nicht verhindern können.

Das Problem entsteht nur dadurch, dass einige wenige Benutzer vorsätzlich unsichtbar geschützte Leerzeichen in grosser Zahl einfügen, und das führt dann zu Konflikten, wenn andere sie wieder entfernen. Da wird dann etwa argumentiert, dass es nicht erlaubt sei, eine zulässige Darstellung in eine andere ändern, oder dass es ja nur eine „kosmetische“ Änderung sei, die, wenn isoliert vorgenommen, ebenfalls nicht erlaubt sei, weil es keine sichtbare Auswirkung auf den Artikel habe, wenn ein unsichtbares geschütztes Leerzeichen durch ein sichtbares ausgetauscht wird. Daher brauchen wir eine „Rechtsgrundlage“, die klar feststellt, dass solche unsichtbar wirksamen Zeichen unzulässig sind, und auf die man sich berufen kann, um die Änderung zu rechtfertigen. --BurghardRichter (Diskussion) 19:00, 31. Jul. 2023 (CEST)

Hallo @BurghardRichter (Bezugnahme auf 12:26, 31. Jul.), abgesehen davon, dass ich dabei bleiben würde, das manche Ausdrücke sich zwar zum Erläutern, aber nicht zum Definieren von Sachverhalten eignen, wie das bspw. auch bei „keine reine Kosmetik“   (‑:  WP:KRK? Bitte nicht!  ;‑)  der Fall ist, hast du endlich ein Beispiel genannt, bei dem sich eines dieser Zeichen, die anscheinend als Gruppe keinen richtigen Namen haben, wirklich so verhält, dass eine „verborgene Nebenwirkung“ zutage tritt.

Es ist zwar „eine tückische Fallgrube“, wenn so ein geschütztes Leerzeichen, welches als normales Leerzeichen getarnt ist, in einer Vorlage { Nachträgl. Anmerkung: Laut einer späteren Änderung: diff=prev&oldid=236016536 (im Beitrag 12:26, 31. Jul.) handelt es sich zwar um keine Vorlage, aber um ein „references“-Tag. -Dirk123456 (Diskussion) 14:30, 3. Aug. 2023 (CEST) } auftaucht: Aber wie ist das Zeichen dahin gelangt? Ich habe für sich genommen nichts gegen eine solche Formulierung (also „eine tückische Fallgrube“), rege aber an, so etwas besser zu platzieren. Aus dem Kontext einer Umfrage muss für Unterzeichnende eindeutig hervorgehen, dass sie beim Hinterlassen einer Signatur bei einem der Auswahlpunkte nicht selber in eine „Fallgrube“ stürzen.

So wie die Umfrage formuliert ist, komme ich zu dem Schluss, dass ich bei einer Unterschrift unter einem der beiden Auswahlpunkte unter #Quelltext-Kosmetik gegen da Beseitigen einer „tückische Fallgrube“ wäre. Wäre ich dann bei einer Unterschrift unter der Aussage »Sichtbare Zeichenkodierung ist nur „Quelltext-Kosmetik“« für „tückische Fallgruben“?

Wie gesagt, die Formulierungen müssen eindeutiger sein, wie genau, weiß ich auch nicht. Aber das Wort „Kosmetik“ bedeutet nicht für alle Menschen und nicht in allen Kontexten etwas Wirkungsloses. Auch „Quelltext-Formatierung“ kann anders verstanden werden als in der Umfrage gemeint, nämlich bspw., dass die Code-Elemente im Quelltext selbst von Quelltexteditor oder anderen Anzeigetools kursiv, fett, farbig usw. angezeigt werden.

Eindeutiger würde es vielleicht durch so etwas ähnliches werden:

• „Ich bin dafür, dass die Zeichensorte X gegen die Zeichensorte Y ausgetauscht wird.“

Wie oben schon gesagt (10:28, 31. Jul./ 1. Beitrag unter der Überschrift↑), bräuchte man meiner Ansicht nach für so eine Umfrage – und erst recht für ein Meinungsbild bzw. für eine Richtlinie – zusätzlich mehrere gut abgegrenzte Begriffe, welche kein Slang sind, sondern definiert worden, um gezielter kommunizieren zu können.

MfG --Dirk123456 (Diskussion) 16:34, 31. Jul. 2023 (CEST)

Hallo Dirk, Das von mir beschriebene Beispiel, in dem die Wikisoftware sich nicht so verhielt, wie sie eigentlich sollte, war natürlich ein Extrembeispiel, das wohl nur ganz selten vorkommt. Aber „verborgene Nebenwirkungen“ sind durchaus keine Seltenheit. Zum ersten Mal stiess ich darauf vor einigen Jahren, als mir in einem WP-Artikel eine Silbentrennung auffiel. Das war mir unerklärlich; denn ich wusste ja, dass es in der Wikipedia keine automatische Silbentrennung gibt, und im Quelltext stand auch nirgends ein weiches Trennzeichen der Form &shy;. Wie konnte es dann zu der Silbentrennung kommen? Das erschien mir wie ein Spuk; das konnte doch nicht mit rechten Dingen zugehen. Einige Zeit später fiel mir in einem Artikel ein ganz seltsamer Zeilenumbruch auf: Mitten in einem Satz, an einer Stelle, wo die laufende Zeile erst zu etwa drei viertel gefüllt war, wurde die Zeile abgebrochen und es ging in der nächsten Zeile weiter, obwohl ohne weiteres noch drei oder vier Wörter in der vorhergehenden Zeile Platz gehabt hätten. Ich vermutete zunächst ein falsch plaziertes <br /> und wollte es entfernen; aber im Quelltext stand an der Stelle kein <br />, und auch sonst war dort nichts zu sehen, was den ungewöhnlichen Zeilenumbruch hätte erklären können. Das brachte mich fast zur Verzweiflung: Es gelang mir nicht, den hässlichen Fehler zu beheben, weil ich nicht seine Ursache herausfinden konnte. Dass es unsichtbare geschützte Leerzeichen gibt, wusste ich damals noch nicht. Erst allmählich ahnte ich dann, dass es wohl so etwas sein müsste. So löschte ich im Quelltext den ganzen Satz und schrieb ihn noch einmal neu; dann war der Spuk vorbei, und der Zeilenumbruch war gut. Tatsächlich waren sechs oder sieben aufeinanderfolgende Wörter des Satzes durch unsichtbar geschützte Leerzeichen statt durch gewöhnliche Leerzeichen getrennt, so dass der ganze Block in die nächste Zeile geschoben wurde, weil er in der vorhergehenden Zeile nicht genug Platz hatte. Die Erkenntnis kostete mich viele Stunden und einige Frustration. Nein, so etwas darf es in der Wikipedia nicht geben! Der Quelltext muss immer klar und deutlich sein, so dass man daraus eindeutig auf das Aussehen des damit erzeugten Artikels schliessen kann. Sonst gibt es keine ausreichende Grundlage für das nötige Vertrauen, das wir in die zugrundeliegende Technik haben müssen. Geradezu zornig machte es mich daher, als ich etwas später herausfand, dass ein Benutzer vorsätzlich solche unsichtbar geschützten Leerzeichen in grosser Zahl – wenn auch natürlich nur an Stellen, wo geschützte Leerzeichen sinnvoll sind – einfügte. Dafür haben wir &nbsp; oder meinethalben auch &#8239;, wenn es partout auch noch ein schmales Leerzeichen sein soll. Aber auf keinen Fall ein Zeichen mit unsichtbaren Zusatzeigenschaften; das ist eine vorsätzliche Täuschung der nachfolgenden Bearbeiter.

Was die Sprache angeht, da bin ich voll auf deiner Seite. Es gibt wohl (noch) keine etablierte Bezeichnung für solche unerwünschten unsichtbaren Dinge, und das ist eigentlich auch gut so. Ich bin auch grundsätzlich kein Freund von Jargon-Ausdrücken. Bei Kosmetik denke ich immer zuerst an gewisse Drogeriewaren, die hauptsächlich von Frauen gekauft und gebraucht werden. Die eigentliche Bedeutung des Wortes ist laut Duden „Schönheitspflege“. Und in übertragenem Sinne passt es ja auch für Änderungen am Quelltext, die keine inhaltliche, sprachliche oder sonstige Verbesserung bewirken, sondern nur den Quelltext etwas „schöner“ machen. Die Quelldatei einer WP-Seite ist immer eine reine ASCII-Datei. Für ihre Beschaffenheit gelten bestimmte Formatierungsregeln. Das hat nichts damit zu tun, dass manche Editoren, die zum Ansehen und Bearbeiten der Quelldatei dienen, in der Darstellung gewisse Modifikationen vornehmen, indem sie bestimmte Arten von Elementen zur besseren Veranschaulichung durch Farben oder abweichende Schriftart hervorheben. In der Quelldatei selbst gibt es das nicht. --BurghardRichter (Diskussion) 21:27, 31. Jul. 2023 (CEST)

Manipulative Umfrage II

Ebenfalls manipulativ ist dieser Auswerteversuch. Die Interpretation "Eine Richtlinienseite solle erstellt werden." ist falsch. Richtig ist vielmehr, dass eine relative Mehrheit der Abstimmenden dafür war, dass ein MB auch "zur Erstellung einer verbindlichen WP:Zeichenkodierung" nötig ist.
Ebenfalls falsch ist der Punkt "24, die nicht zum Kernthema votierten, lehnten die Umfrage aus unterschiedlichen Motiven ab." Tatsächlich lehnten 28 die Umfrage ab, ob zum Kernthema votierend oder nicht, ist dafür irrelevant.
Angesichts dessen kann man kaum von "einem breiten Umfrage-Konsens" sprechen, der auch ohne MB etwas gerissen hätte.
FÜrs Protokoll: ich habe die Umfrage abgelehnt, weil ich sie in der Form für manipulativ und ohne Aussagewert halte. Diese Auswerteversuch setzt der missglückten Umfrage noch eins drauf. --Global Fish (Diskussion) 08:38, 1. Aug. 2023 (CEST)

Wer die Umfrage ablehnt UND in der Kernfrage abstimmt, bekommt ZWEI Stimmen, wer sich nur zur Kernfrage äußert bekäme nach dieser Rechnung lediglich EINE Stimme.

• (PA entfernt. MBxd1 (Diskussion) 12:33, 1. Aug. 2023 (CEST))
• Schon dreist, das unter dem ewigen Vorwurf „manipulativ“ zu deklarieren, aber selbst mit allen Mitteln versuchen, eine weitaus überwiegende Community-Meinung noch irgendwie zu unterdrücken.

Und bevor der krude Vergleich zum MB kommt: Beim MB gibt es einen formalen Punkt für alle: Nehme das MB an / lehne das MB ab. Bei einer Umfrage gibt es diesen Punkt nicht; alle die inhaltlich teilnehmen, nehmen auch die Umfrage an. Wer die Umfrage ablehnt, kann kein inhaltliches Votum abgeben. Wer beides macht, wird nicht doppelt gezählt, sondern bekommt eine der beiden Aussagen gestrichen. Was wäre dir lieber? Beim Abschnitt „soll erlaubt sein“ oder bei „Ablehnung“? Im ersteren Fall bliebe grad mal ein Votum für die Erlaubnis übrig. Wir können natürlich auch aufnehmen: „50 Abstimmende nahmen die Umfrage formal an“; hätten aber wieder vier Leute doppelt und widersprüchlich gezählt. Das wären gleichwohl mehr als die bei MB für formale Annahme üblichen 50 %.

Die Fragestellung zum MB spricht von einem „verbindlichen WP:Zeichenkodierung?“; nur die Verbindlichkeit und damit die administrative Durchsetzung (bis zu Benutzersperren) ist damit vorläufig aufgeschoben. Die Erstellung einer Projektseite als solches ist nicht blockiert. Sie wurde mit 41:8 von der Community zweifelsfrei befürwortet.

Schon lustig, wie eine klare Ansage der Community mit (PA entfernt. MBxd1 (Diskussion) 12:44, 1. Aug. 2023 (CEST)) als nicht-existent herumgedeutelt werden soll.

@Funkruf, Karsten11:, ihr habt doch Erfahrung mit Auswertungen?

VG --PerfektesChaos 12:28, 1. Aug. 2023 (CEST)

Du hast da was nicht verstanden. Umfragen folgen nicht strikt dem MB-Muster, sondern dienen dem groben Erfassen von Meinungen und sollen Möglichkeiten für MB ausloten. Das von dir beschriebene Verbot mehrfacher "Abstimmung" gibt es dabei nicht, ohnehin kommt es mehr als bei MB auf die Kommentare an. Mit Umfragen wird per definitionem nichts beschlossen, somit wird auch nichts "vorläufig aufgeschoben". Man kann numerisch auswerten, muss aber nicht. MBxd1 (Diskussion) 12:38, 1. Aug. 2023 (CEST)

Die administrative Durchsetzung, was in der Konsequenz automatische Benutzersperren meint, ist bis zu einem MB aufgeschoben, ansonsten nichts, aber auch gar nichts.

Die Community hat mit 45:4 glasklar und unmissverständlich ausgedrückt, dass das vorsätzliche Einfügen unerlaubt ist. Darauf kann sich von nun an überall berufen werden. Auch in andere administrative Vorgänge kann die Sichtweise eines Großteils der (sich äußernden) Community einfließen.

--PerfektesChaos 12:48, 1. Aug. 2023 (CEST)

Quetsch  Info:: Obiges von mir mit dem MB und der Richtlinienseite bezog sich auf die Passage in der Umfrage: „Wäre ein zusätzliches MB zur administrativen Durchsetzung erforderlich, oder reicht erstmal diese Umfrage in einem breiten Wiki-Konsens zur Begründung administrativer Maßnahmen und zur Erstellung einer verbindlichen WP:Zeichenkodierung?“ (Hervorhebung von mir)--Global Fish (Diskussion) 19:57, 2. Aug. 2023 (CEST)

Umfragen sind per definitionem unverbindlich. Wenn dir das nicht passt, wirst du dir beim Umsetzungsversuch eine blutige Nase holen - erst recht, wenn du annimmst, dass der Inhalt einer möglichen Regelseite bereits definiert wäre. MBxd1 (Diskussion) 12:53, 1. Aug. 2023 (CEST)

+1: Wikipedia:Umfragen schreibt: "Meinungsbilder, die zur Veränderung der Wikipedia führen sollen, also nicht nur der Beschreibung dienen, finden sich unter Wikipedia:Meinungsbilder.". Dennoch war die Umfrage ja sinnvoll und vom Ergebnis her eindeutig (wäre wohl noch eindeutiger gewesen, wenn die Fragestellung ein wenig anders formuliert wäre). Der nächste Schritt wäre daher einen Entwurf der vorgesehenen Regelseite zu erstellen und dort konkret zu beschreiben, welche Zeichen welche Wirkung haben und daher unerwünscht sind. Besteht dann Konsens, dass das richtig und sinnvoll ist, brauchen wir nicht einmal ein MB. Gibt es aber Konflikte, so ist ein MB sinnvoll.--Karsten11 (Diskussion) 13:49, 1. Aug. 2023 (CEST)

Sinnvoll war die Umfrage auf jeden Fall, deswegen ist es auch bedauerlich, dass sie durch Überdehnung des Ergebnisses und Unterstellen von Nichtakzeptanz beschädigt wird.

Der Konsens zum exakten Inhalt der Regelseite bleibt natürlich noch zu finden, der ist noch nicht beschlossen. Muss man ja leider dazusagen. MBxd1 (Diskussion) 14:30, 1. Aug. 2023 (CEST)