Hilfe Diskussion:Textgestaltung

Diese Diskussionsseite wurde aufgeräumt.
Einträge ohne direkten Diskussionsbezug oder nicht unterschriebene Einträge wurden ohne Archivierung entfernt, Verbleibendes ins Archiv verschoben, sofern die Diskussion als abgeschlossen erachtet wurde. Bitte nicht wieder zurückverschieben, sondern das Thema neu starten. Die Archivierung erfolgt von Zeit zu Zeit, um die Übersicht wiederherzustellen.

Dies betrifft nur Abschnitte bis zum ungefähr Ende 2007. Sie sind hier auffindbar: Archiv.

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 90 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 2 Abschnitte.

center in Zitaten

Was ist, wenn in Zitaten/Inschriften zentriert wird? Hier ein Beispiel. --Spielertyp (Diskussion) 14:57, 12. Apr. 2013 (CEST)

„ebenda“ und Einzelnachweis

Ich stelle hier einmal eine kleine Diskussion ein. Es ging um eine Biografie, bei der Geburtsort und Sterbeort identisch sind. Statt des Sterbeortes wurde „ebenda“ geschrieben, der Einzelnachweis folgte und dann die schließende Klammer. Ich hatte die Klammer vor den Einzelnachweis gesetzt, weil „ebenda“ Bezug zum gleichlautenden Namen der Geburt nimmt. Wir haben hier abgebrochen, weil das Problem zu klein erscheint und die Vorgaben vielleicht nicht eindeutig genug umsetzbar sind .--Dmicha (Diskussion) 13:49, 14. Feb. 2014 (CET)

Small-Tag

Hallo, ich würde gerne einmal Meinungen dazu einholen, inwieweit es noch als sinnvoll erachtet wird, das HTML-Tag <small> als unerwünscht aufzulisten. Meiner persönlichen Meinung nach sollte es zwar so gut wie nie eingesetzt werden, aber die ca. 150.000 Artikel, in denen es direkt vorkommt, sind ein Indiz dafür, dass ein gewisser Bedarf besteht. Außerdem ist es auch in diversen Formatvorlagen (Beispiel) eingebunden. -- Gruß, aka 19:04, 1. Mai 2020 (CEST)

Naja, der Hintergrund der Unerwünschung sind wohl Benutzer mit Augenproblemen, und die von den Browsern dargestellte oft für diesen Personenkreis zu starke Verkleinerung.

Wer an seinem privaten Browser sitzt, der kann sich mit CSS-Tricks für alle Webseiten oder für Wikis eine mäßigere Verkleinerung einstellen; braucht aber viel Fachwissen und einen sehr kooperativen Browser.

Wer dann jemand anders über die Schulter guckt, ist wieder Neese.

Deshalb ist diese smallerei für enzyklopädische Inhalte unerwünscht und in den letzten zehn Jahren stark zurückgedrängt worden. Auch wenn 150.000 noch nach recht viel aussehen mag, ist es regelmäßig aus früher üblichen Attribuierungen wie (englisch) oder bei example.org oder (Stand: 2020) herauseditiert worden. Verglichen mit 2005 sind prozentual von zweieinhalb Millionen Artikeln wesentlich weniger noch irgendwo damit versehen als damals bei insgesamt 100.000 Artikeln.

Im Sinne der Barrierefreiheit sollte es auch weiterhin als unerwünscht gebrandmarkt bleiben, auch wenn niemand sehr aktiv der Verwendung entgegenwirkt.

Die Wikipedia von 2005 hatte sich stark an herkömmlicher gedruckter Literatur orientiert, und in der kam es darauf an, Papier zu sparen, und Barrierefreiheit war früher unbekannt. Heutzutage lösen wir uns von den Sitten gedruckter Zeitschriften, kürzen nicht so viel ab, verwenden keine kleine Schrift mehr. Ein paar Autoren-Fossilien formatieren noch so, wie sie das in ihrer Studentenzeit in den 1960ern mal gelernt hatten, aber wir haben uns längst davon gelöst und wirken auf einen laienverständlichen gut lesbaren barrierefreien Stil hin.

Umgekehrt ausgedrückt: Mein Bildschirm ist mehrere Kilometer lang, und ich habe keine Notwendigkeit, Platz auf der Seite einzusparen. Es gibt somit keinen positiven Grund, Schriftverkleinerung außer bei Exponenten und Indizes zu verwenden, und deshalb auch keinen wirklichen „Bedarf“. Es machen halt viele, weil sie es aus ihren Büchern auch so gewohnt sind.

LG --PerfektesChaos 19:21, 1. Mai 2020 (CEST)

+1. In Firefox kann ich zwar eine Mindestschriftgröße festlegen, dies ändert aber nicht den (dann zu kleinen) Zeilenabstand. Gruß --FriedhelmW (Diskussion) 19:50, 1. Mai 2020 (CEST)

Bitte dieses tag auch weiterhin möglichst nicht oder nur sparsam in Artikeln verwenden. Selbiges gilt übrigens auch für unnötig verkleinerte Schrift in Tabellen. Es ist für viele Menschen mühsam, kleine Schrift lesen zu müssen. Wikipedia war immer als möglichst für alle zugängliche Enzyklopädie gedacht, das schließt natürlich insbesondere Barrierefreiheit mit ein.

Außerdem sollten wir ohnehin möglichst wenige tags in Artikeln verwenden, um den Quelltext einfach und lesbar zu halten. Zugänglichkeit schließt auch die Zugänglichkeit für unerfahrene Neuatoren mit ein. -- Chaddy · D 20:51, 1. Mai 2020 (CEST)

Das berechtigt noch lange nicht, sämtliche Nutzung dieses Tags im ANR per Bot oder Massenedit zu entfernen. Es gibt durchaus sinnvolle Verwendungen. So z. B., wenn ein Infoboxparameter einen relativ langen Inhalt zugewiesen bekommt und eine generelle Verkleinerung per CSS in der Vorlage nicht sinnvoll ist. ÅñŧóñŜûŝî (Ð) 16:31, 2. Mai 2020 (CEST)

Ja, aber das hat ja auch niemand gefordert, soweit ich das sehe. -- Chaddy · D 16:36, 2. Mai 2020 (CEST)

Fein. Dann sollte Benutzer:Starkiller3010 seine diesbezügliche Aktivität etwas reduzieren. Gruß von ÅñŧóñŜûŝî (Ð) 16:52, 2. Mai 2020 (CEST)

Also ich denke, man sollte das schon mal aus Sicht der Regeln betrachten und daraus dann ableiten, wie wir vorgehen. Diese Regeln sagen auf globaler Ebene, dass <small> nicht eingesetzt werden soll. In obiger Diskussion ist auch nochmal erklärt, warum: Lesbarkeit. Wenn es also jetzt Ausnahmen geben soll, dann sollten wir die entweder explizit in den Regeln haben (z.B. auf Portalsebene, in der Doku zu der betreffenden Infobox) oder per Kommentar im Quelltext als Begründung (analog zu dem bekannten Sic! bei gewollter Falschschreibung). Ich habe mir auch mal konkret (1065) Amundsenia angesehen, in dem small entfernt wurde und diese Entfernung revertiert. Es ist für mich nicht ersichtlich, warum hier eine Small-Schreibweise erforderlich sein soll. Benutzer:Antonsusi, könntest Du das mal konkret erklären? Danke und VG --Bicycle Tourer (Diskussion) 18:51, 2. Mai 2020 (CEST)

<Quetsch>Es gibt keine allgemeine Regel dieser Art, das ist schlicht eine überstrenge, schematische Interpretation der Vorgabe. Kleinformatierung soll nicht benutzt werden, wenn und soweit es die Leserlichkeit stört. Das ist in vielen Fällen Auslegungssache, vielfach aber auch offensichtlich gar nicht der Fall (etwa bei Zusatz- oder Quellenhinweisen in Bildlegenden). Ist Sache des bearbeitenden Artikelautors, die Sinnhaftigkeit zu beurteilen. Korrektoren sollten das nur in offensichtlichen Fällen anfassen, sagen wir wenn einer mitten im Fließtext ein Zitat klein formatiert o.Ä. Sonst ist das übergriffig.--Jordi (Diskussion) 11:45, 23. Jul. 2020 (CEST)

Anstatt einer Erklärung hier hat Benutzer:Antonsusi seine Änderung selbst praktisch rückgängig gemacht. -- Gruß, aka 10:58, 3. Mai 2020 (CEST)

Ich habe es doch erklärt (Vorlagenparameter). Es geht ganz allgemein darum, dass es nicht pauschal automatisch entfernt wird. Dass es für diese konkrete Infobox eine andere Möglichkeit gibt, bedeutet noch lange nicht, dass du deinen Bot über die Small-Tags im ANR fegen lassen solltest. ÅñŧóñŜûŝî (Ð) 11:05, 3. Mai 2020 (CEST)

Das hatte ich auch überhaupt nicht vor. -- Gruß, aka 11:12, 3. Mai 2020 (CEST)

Moin Benutzer:Antonsusi, um das zu erläutern:

• Wir haben derzeit den Regelstand, dass <small> unerwünscht ist.
• Es gibt eine Fehlerliste, in der die Verwendung von <small> aufgezeigt wird.
• Es gibt ein Team von Autoren, dass diese Fehlerliste abarbeitet.
• Diese Autoren entscheiden nach dem Stand der Regeln, ob sie das <small> entfernen.
• Default-Aktion: Entfernen gemäß Regelwerk.
• Es ist für diese Autoren nicht erkennbar, dass und wann es eine Ausnahme von der Regel gibt.
• Eine Aussage "Es geht ganz allgemein darum, dass es nicht entfernt wird", ist nicht hilfreich, um zu einer anderen Entscheidung zu kommen, denn die allgemeine Regel lautet "Unerwünscht", spezifischere Regeln sind bisher nicht bekannt.

Damit diese Autoren die richtige Entscheidung treffen können: Könntest Du bitte eine genauere Beschreibung (Regel) angeben, wann <small> angemessen ist und deshalb nicht entfernt werden soll?

Danke und VG --Bicycle Tourer (Diskussion) 12:41, 3. Mai 2020 (CEST)

<Quetsch>Die Voraussetzungen deiner Argumentation stimmen ja nicht. Diesen "Regelstand" haben wir so nicht, und dass solche Dinge anhand von "Fehlerlisten" von Korrektoren "abgearbeitet" werden, ist selbst regelwidrig, weil es nicht in deren Aufgabenbereich fällt, Zweifels- und Ermessensfälle autoritativ zu entscheiden. Das Kriterium für "Ausnahmen" ergibt sich aus dem Regelwerk selbst (Beeinträchtigung der Leserlichkeit), wann das der Fall ist, entscheidet der Autor.--Jordi (Diskussion) 12:06, 23. Jul. 2020 (CEST)

Überall dort, wo es eng wird:

• Bei Parameterwerten eingebundeneer Vorlagen, besonders Infoboxen. Es ist nicht immer sinnvoll, das Tag in die Vorlage zu integrieren. hier bitte gar nichts entfernen.
• In Tabellenzellen. Hier kann das Tag auch notwendig sein. Diese Bereiche sind sensibel gegenüber verschiedenen userseitigen Einstellungen.
• Bereiche mit besonderem Layout, wie z. B. in der Umgebung von Math-Tags.

ÅñŧóñŜûŝî (Ð) 14:56, 3. Mai 2020 (CEST)

Nunja. "Eng" wird es auch, wenn man das Browserfenster schmaler macht oder die Seite auf einem Smartphone öffnet. Das gilt auf für Infoboxen. Wenn schon, dann sollte das über die konkrete Vorlage einheitlich geregelt werden. Auch bei Tabellen kann man sich nicht auf irgendeine vorhandene Breite oder eine eingesetzte Schriftart verlassen. Wenn irgendwas bei dir mit "small" hübsch aussieht, wird das sicherlich bei jemand anderem trotzdem umgebrochen oder es ist dadurch besonders viel Freiraum vorhanden oder jemand kann es aufgrund der Schriftgröße gar nicht mehr lesen. Ich plädiere da eher für WP:SM. -- Gruß, aka 15:03, 3. Mai 2020 (CEST)

Also ich sehe das so wie Benutzer Aka. Es gibt keine Website, die auf allen Endgeräten perfekt funktioniert. Der Benutzer, der eine Site auf seine 4 Screens aufzieht, ist nicht zu vergleichen mit einem Smartphone. Daher müssen sich halt manchmal die verschiedenen userseitigen Einstellungen an die Website anpassen und nicht umgekehrt.

Die Bemerkung nicht immer sinnvoll, das Tag in die Vorlage zu integrieren verstehe ich auch nicht. Eine Vorlage ist bspw. in 10.000 Artikel eingebunden. Bei 5.000 muss ich für bessere Lesbarkeit das <small> einfügen, in die anderen 5.000 nicht? Das kann doch nicht funktionieren.

Eine Ausnahme sehe ich natürlich bei mathematischen oder chemischen Formeln. Hier würde ich bestimmt die Finger von <small> oder <sup> lassen. Denn das könnte natürlich schnell schief gehen.

Eine Frage an @Antonsusi:. Benutzer @Bicycle Tourer: hatte Dich um genauere Beschreibung (Regel) gebeten. Du gibst hier nur Deine persönlichen Präferenzen an, aber keine Regel. vG --Koyaanisqatsi01 (Diskussion) 21:01, 4. Mai 2020 (CEST)

Es gibt keine feste Regelung. Hier muss man ganz einfach individuell entscheiden. Ich habe hier ganz einfach Fälle aufgelistet, bei denen das Small-Tag öfters sinnvoll ist. Zum Thema Vorlage: Wenn der Parameter einer Infobox bei einem kleineren Teil, z. B. 10 %, der Einbindungen einen relativ langen Text zugewiesen bekommt, dann kann ich nicht per Vorlage alle verkleinern, weil dann 90 % der Infoboxen einen unnötig kleinen Text enthalten. ÅñŧóñŜûŝî (Ð) 21:16, 4. Mai 2020 (CEST)

Variatio delectat. Zwanghaftes Entfernen, nur weil das Gesetz es befahl, ohne Nachdenken, also wie ein Bot, ist immer, ich wiederhole immer, falsch. Da muss halt ein wenig in jedem Einzelfall nachgedacht werden. Ist nicht so schön für den Editzähler, ist aber besser für's Betriebsklima, wenn solche Geschmacksänderungen nicht per Quasibot übergebürstet werden. Grüße vom Sänger ♫ ^(Reden) 21:29, 4. Mai 2020 (CEST)

Unfug vG --Koyaanisqatsi01 (Diskussion) 22:10, 4. Mai 2020 (CEST)

Zustimmung zu Antonsusi - bei Vorlagen/Infoboxen und Tabellenzellen hat die Verkleinerung aus den oben genannten Gründen schon ihren Sinn, in der Regel denken sich die Autoren auch schon was dabei wenn sie den Small-Tag verwenden. Wenn ich mir die letzten Massenedits von Starkiller3010 und Koyaanisqatsi01 so ansehe sind da auch deutliche Verschlimmbesserungen dabei --Julez A. 23:40, 4. Mai 2020 (CEST)

@Julez: Könntest Du konkrete Beispiele angeben, in denen Du die Entfernung von <small> für eine Verschlechterung hältst? Daraus könnten wir besser erkennen, wann dieser Tag sinnvoll ist. Danke und VG --Bicycle Tourer (Diskussion) 10:56, 5. Mai 2020 (CEST)

Ich fasse mal zusammen, wo wir IMHO bereits Konsens haben, dass die Verwendung von <small> sinnvoll ist (danke an Benutzer:Antonsusi für die Konkretisierungen oben) und dies m.E. auch bereits hinreichend genau beschrieben ist:

• In der Umgebung von <math> Formeln
• In der Umgebung von chemischen Formeln

Wo ich bisher nicht sehe, dass <small> "generell sinnvoll" ist:

• Bei Parameterwerten für Vorlagen, z.B. Infoboxen. (Konflikt "Lesbarkeit" <-> "schmal passt das noch hin", obwohl letzteres völlig von der Art der Anzeige (breiter Bildschirm, Mobilgerät etc.) abhängig ist)
• Tabellenzellen. (Konflikt "Lesbarkeit" <-> "schmal passt das noch hin", obwohl letzteres völlig von der Art der Anzeige (breiter Bildschirm, Mobilgerät etc.) abhängig ist)

Wie kann man die letzten beiden Bereiche so konkretisieren, dass es aufgrund von Regeln entscheidbar wird? VG --Bicycle Tourer (Diskussion) 10:58, 5. Mai 2020 (CEST)

So. Bin leider diese Woche in der Realworld mehr gefordert als in der virtuellen. Deshalb erst heute ein Ping von mir. Klar ist nach jetzigem Stand der Disk, dass bei mathematischen Formeln und Chemischen Formeln das <small> sinnvoll ist. Das ist einleuchtend wegen der Darstellung der Formel, da es in der Wiki keine entsprechenden anderen Möglichkeiten der Formatierung gibt. @Aka: wäre es hier vielleicht möglich diese Seiten anhand der Kategorie oder des im Artkel vorhanden <math> rauszufiltern? Wenn nicht würden die halt händig auf die Ausnahmeliste wandern. Damit wäre dieser Teil dann erschlagen. Im Fließtext (außerhalb von Tabellen und Infoboxen) ist die Sache auch klar, solange keine chemischen oder mathematischen Formeln betroffen sind. Da sind die <small> wie oben von @PerfektesChaos: angefügt. Bleibt zu klären wie mit Tabellen und Infoboxen umgegangen wird. @Chaddy: führt hier richtigerweise die Lesbarkeit und Barrierefreiheit an. In Tabellen ist mir persönlich das <small> Tag überwiegend bei selbstgebastelten Anmerkungen nich nicht <ref> nutzten vorgekommen. Wie oben geschrieben machen die Small-Tags in den Tabellen aber alleine schon wegen der verschiedenen genutzten Ausgabegeräten nicht wirklich Sinn. Denke hier gehören sie, wenn nicht Bestandteil von Formeln, auch nicht rein. Bleiben also die Infoboxen. Hier scheint es grundsätzlich Möglichkeiten zu geben. @Antonsusi: hat hier ja die Reverts rückgängig gemacht und die Info-Boxen ohne Small-Tag hergestellt. Trotzdem bleibt die Frage der Lesbarkeit und Barrierefreiheit. Hier sollten wir klarheitschaffen. Entweder die Lesbarkeit und Barrierefreiheit (also kein Small-Tag) oder den Small-Tag in Info-Boxen generell akzeptieren. Hier scheinenen ja die Infoboxen einer programiertechnischen Einschränkung zu unterliegen. --Starkiller3010 (Diskussion) 23:26, 5. Mai 2020 (CEST)

Bzgl. Tabellen meinte ich nicht nur die small-Tags, sondern auch Schriftverkleinerung mit Tabellensyntax (also style="font-size:XX%;"). -- Chaddy · D 00:02, 6. Mai 2020 (CEST)

Bei Infoboxen, bei denen Small-Tags verwendet werden handelt es sich meistens um Spalten der Form "Kurze Angabe (längere Erläuterung zu dieser Angabe und gegebenenfalls Stand der Datenerhebung etc.)". Falls man hier die Verkleinerung aufhebt nimmt die zugehörige Erläuterung sehr viel mehr Platz ein als der Datenwert, um den es an dieser Stelle eigentlich geht. Das schaut völlig unabhängig von der Bildschirmgröße schlecht proportioniert und damit unschön aus. Und wie oben bereits erläutert wurde, wird meist nur bei einigen wenigen Parametern ein längerer Text zugewiesen, was dann je nach Infobox entweder zu einer unnötigen Gesamt-Textverkleinerung oder zu zig Zeilenumbrüchen an der Stelle führt. Man könnte sich in solchen Fällen damit behelfen, die Anmerkungen generell in Fußnoten zu verlagern, allerdings sind Fußnoten, die nicht als EN dienen, auch unerwünscht.

Eine generell gute Diskussionsgrundlage ist die Infobox Asteroid im bereits diskutierten Artikel (1065) Amundsenia. Dort sind immer noch jede Menge Textverkleinerungen vorhanden, nur halt in den Infobox-Code verlagert, was ja wohl kaum etwas an der angeblich mangelnden Lesbarkeit ändert. D.h., wenn es um die Lesbarkeit geht, müsste man doch, auch in Tabellen, die Verwendung von style=font-size generell einschränken?

Ein weiteres betroffenes Beispiel ist die Vorlage:Personenleiste (Vorgänger <-> Nachfolger). Dort wird der gesamte unter AMT= eingetragene Text gefettet. Da zeilenweise Fettschreibung auch unschön und unerwüscht ist, ist der small-tag m.W. hier die einzige Möglichkeit, die Fettung an dieser Stelle etwas zu entschärfen --Julez A. 01:42, 6. Mai 2020 (CEST)

Ich denke nicht, dass Fußnoten, die nicht als EN dienen, unerwünscht seien. Wo kann man das nachlesen? - Jedenfalls fände ich diese Lösung für die Infoboxen sehr sinnvoll. -- Chaddy · D 01:45, 6. Mai 2020 (CEST)

Den Quellen-Abschnitt in der Infobox Asteroid finde ich nicht nur ein wenig, sondern sogar deutlich zu klein. Wikipedia lesen ja nicht nur 15-Jährige mit perfekter Sehkraft. Deshalb sollte meiner Meinung nach soweit wie möglich die im Browser eingestellte Schriftart und Schriftgröße verwendet werden, auch wenn manche Stellen dann eben etwas mehr Platz einnehmen. Es sollte nicht die Optik über der Funktion stehen. Deshalb plädiere ich dafür, auch auf Font-Size-Spielereien im Sinne der Lesbarkeit für alle soweit wie möglich zu verzichten. -- Gruß, aka 09:42, 6. Mai 2020 (CEST)

⇐ Ich habe auch nicht die besten Augen und deshalb zoome ich ganz einfach den Browser, wenn mir eine Schrift zu klein ist oder ich benutze die Bildschirmlupe. Wenn man die auf ca. 150 % stellt, dann kommt man da gut hin. Es ist nicht erforderlich, dass alle Texte Quellenseitig so groß sind. Mal ganz davon abgesehen, dass wir hier nicht derart massiv in die Autorenfreiheit eingreifen und Fußnoten verbieten dürfen . Mir ist auch nicht entgangen, dass Julez A. (gezielt?) Vorlagen angeführt hat, an denen ich beteiligt bin. Wo kommen wir hin, wenn wir hier pingelige Vorgaben machen? Ich kann es euch verraten: Der in den letzten Jahren zu verzeichnende massive Autorenschwund wird sich verschärfen! Also Schluss mit der übermäßigen Regelwut hier. Solange niemand Texte kleiner als 50% darstellt kommt man mit wenigen Mausklicks oder Tastendrücken auch ans Ziel. ÅñŧóñŜûŝî (Ð) 18:03, 6. Mai 2020 (CEST)

Das mit dem Zoomen durch den Browser ist sehr praktisch, und ich nutze es, wenn mir etwas zu klein ist. Leider muss ich aber zur Kenntnis nehmen, dass 80% (eher 90%?) der User diese Funktion im PC-Bereich nicht kennen. Das mag auf Mobilgeräten anders sein, da die Vergrößerung mittels zweier Finger dort in vielen Apps gängig ist. Ob das aber vor allem ältere User wissen, die mit kleiner Schrift eher Probleme haben? Insofern greift das Argument "Zoom"-Funktion nicht für das Problem "Lesbarkeit" vs. "Kleine Schrift". VG --Bicycle Tourer (Diskussion) 18:49, 6. Mai 2020 (CEST)

Zudem stellt die Voraussetzung, die Zoom-Funktion nutzen zu müssen, eine zusätzliche Hürde dar, was wir ja eigentlich im Sinne der Barrierefreiheit gerade vermeiden wollen. Es sollte weniger und nicht mehr Hürden geben. -- Chaddy · D 18:53, 6. Mai 2020 (CEST)

Hallo Antonsusi, ich wollte dich keinesfalls an den Pranger stellen o.ä., falls das so rüberkam tut es mir leid. Ich bin ja deiner Meinung was die Formatierung der Vorlagen angeht, d.h. ich finde das die Verkleinerung in den genannten Fällen die Übersichtlichkeit fördert und die Verwendung des small-tags im Einzelfall den Autoren überlassen werden sollte. Die Astronomie-Box wurde schlichtweg oben bereits diskutiert und die Folgenleiste habe ich selbst schon mit small-tag in einem knappen dutzend Artikel eingebaut, daher bin ich da direkt betroffen.

@ Chaddy: Bezüglich Verwendung der Fußnoten siehe Hilfe:Einzelnachweise ("Die Nutzung von Anmerkungen, die über Quellenangaben für die Aussagen des Artikels hinausgehen, ist umstritten.") sowie der roten Kasten in Vorlage:FN. --Julez A. 18:56, 6. Mai 2020 (CEST)

Wie seht ihr Kleinschreibungen innerhalb von Überschriften? Manchmal wird dort beispielsweise „(Auswahl)“ oder dergleichen kleingeschrieben. -- Gruß, aka 11:13, 7. Jun. 2020 (CEST)

Anlässlich dieses Threads achte ich in den letzten Wochen mal verstärkt drauf.

• In Überschrift, gemäß Anfrage: Sieht einfach nur doof aus, bringt niemandem nix, würde ein Drucker in einer Zeile auch nicht machen, höchstens in einem Untertitel in einer gesonderten Zeile auf Papier, wo das Layout bekannt wäre.
• Spezielle Notationen, also musikalisch-chemisch-mathematisch-linguistisch: Uneingeschränkt, wie schon oben.
• Wirklich irgendwann überflüssige Hinweistexte, namentlich die Ansage des Defekte-Weblinks-Bot mit Kurzanleitung: Gern klein.
• Normale Anmerkungen, gerade im Fließtext, gerade ohnehin eingeklammert und kurz; „(englisch)“ oder „abgerufen am“ und auch „(Auswahl)“ und „Stand: Juni 2020“: Normalgröße.
• Innerhalb einer Tabellenzelle oder Bildlegende eigentlich völlig unwichtige, nicht bedeutungstragende übermäßig lange Extra-Hinweise: Von mir aus auch mal klein, aber eigentlich bessere Lösung per Vorlage:FN oder Darlegung im begleitenden Text, einleitend oder sonstwie erläuternder Textblock außerhalb der Platzmangel-Situation.

Regelfall sollte überall die vorgesehene Normalschrift sein, mit den darin vorgesehenen Zeichen, und gesondertes small die große Ausnahme.

VG --PerfektesChaos 17:35, 7. Jun. 2020 (CEST)

Ich hatte ein paar hundert solcher Stellen in den letzten Wochen geändert, weil mich gerade in Überschriften diese zwei Schriftgrößen besonders gestört haben. In nur einem mir bekannten Fall gab es einen Revert: Diskussion:4. Sinfonie (Bruckner). Kriegsentscheidend ist es natürlich nicht, aber da sich hier die Aussagen widersprechen, ob ein Schriftsetzer so etwas machen würde: @Alfred Kiefer: -- Gruß, aka 17:51, 7. Jun. 2020 (CEST)

Ich habe vorstehende Diskussion bloß überflogen und kann mich deshalb nicht zu allem äußern. Deshalb nur Folgendes zu einer Aktion, die mir gestern auffiel: Ein mir bislang unbekannter Benutzer sah plötzlich seine Aufgabe darin, unter anderem Erläuterungen unter einer Tabelle wie in DKW Hobby in übliche Schriftgröße umzusetzen. Als Begründung schrieb er: „Unerwünschte Formatierung“. Warum sollte es aber unerwünscht sein, oder wer wünscht es nicht, dass derartige kurze Erläuterungen durch kleinere Schrift vom übrigen Text abgesetzt werden? Und warum soll ich einen Antrag stellen bzw. den Artikel in eine Liste eintragen müssen, wenn die Formatierung doch beibehalten werden soll? Viele Grüße -- Lothar Spurzem 10:22, 17. Jun. 2020 (CEST)

Die selbstgemachten Kriterien von @PC sind teilweise durchaus akzeptabel, aber grundsätzlich ist das wegen der vielen Ermessensspielräume nicht Sache von Korrektoren, bei solchen Formatierungen einzugreifen. Wie oben schon gesagt: Es gibt keine allgemeine Regel, die Kleinformatierung in jedem Fall unerwünscht macht, das wäre eine überstrenge, schematische Interpretation der Vorgabe. Kleinformatierung soll nicht benutzt werden, wenn und soweit es die Leserlichkeit stört. Das ist in vielen Fällen Auslegungssache, oft aber auch schlicht nicht der Fall. Ob bspw. in einer Bildlegende Zusatzinformationen klein formatiert werden sollen (das ist der m.W. [Nchtr.: neben Infoboxen] üblichste Fall, in dem Kleinformatierung bislang absolut akzeptiert war und nie negativ sanktioniert wurde), ist Sache des bearbeitenden Autors. Korrektoren sollten das nur in ganz offensichtlichen Fällen anfassen, sagen wir wenn einer mitten im Fließtext ein Zitat klein formatiert o.Ä. Sonst ist das übergriffig.

Im Einzelfall kann der Korrektor ja den Autor ansprechen und den Einzelfall besprechen und konsensuell lösen. Auf halbautomatischen "Fehlerlisten", wie sie Benutzer:Aka pflegt, sollten solche Zweifelsfälle nicht oder allerhöchstens mit scharfen Warnhinweisen für übereifrige Abarbeiter eingetragen werden.--Jordi (Diskussion) 11:54, 23. Jul. 2020 (CEST)

Habe jetzt spaßeshalber mal selbst einige Einträge aus @Akas Liste abgearbeitet, das ist schon eine zweischneidige Sache, finde ich. Man bekommt da sogar gleich einen vorgefertigten Bearbeitungskommentar mitgeliefert (ziemlich unfreundliche bis übergriffige Formulierung mit "unerwünscht" und Link auf irgendeine Regel), das würde ich von allein niemals schreiben, selbst wenn ich solche Korrekturen öfter machen wollte, schon gar nicht pauschal in so unterschiedlich gelagerten Fällen wie hier, wo es meistens eine Ermessensfrage ist, ob überhaupt ein "Fehler" vorliegt oder die Formatierung schlicht eine Geschmackssache und letztlich vertretbar ist. Im Ergebnis habe ich die meisten Beispiele tatsächlich berichtigt, weil da Kleinformatierungen mitten im Text standen, was tatsächlich etwas unschön wirkt und auch nicht üblich ist. Ohne @Akas Liste hätte man das so systematisch nat. nicht alles gefunden und daher wohl auch nicht geändert, insofern sind die Listen hilfreich; aber wirklich notwendig waren die meisten Änderungen dann auch wieder nicht und man hätte es auch so lassen können und abwarten, ob irgendeinem Mitautor des Artikels das aufstößt und das dann sowieso verbessert wird. In drei oder vier Artikeln waren Zuordnungsfehler zu berichtigen, die Kleinformatierung selbst war nicht das Problem und konnte in einigen Fällen beibehalten werden, weil sie vertretbar schien, in anderen habe ich sie mitgeändert. Drei Artikel zeigten überhaupt keinen Änderungsbedarf. Alle abgearbeitete Artikel, in denen man die <small>-Formatierung nicht entfernt, muss man anschließend noch auf die Ausschlussliste setzen und das auch begründen, sonst listet @Akas System das erneut auf. Mit all diesen zusätzlichen Hürden, Vorformulierungen und Bearbeitungsschritten werden hilfsbereite Korrektoren geradezu dazu verleitet, auf die Schnelle nicht notwendige "Verbesserungen" durchzuführen und Autoren vor den Kopf zu stoßen. Psychologisch ist das gar nicht sinnvoll, zumal man damit autoritäre Denkweisen unterstützt und die Korrektoren nicht schult, genauer hinzusehen und nur bei echter Notwendigkeit einzuschreiten. Insgesamt sehe ich da mehr Schaden als Nutzen, jdfs. wenn die "Fehlerlisten" solche nicht wirklich verbotenen Dinge als korrekturwürdige "Fehler" ausweisen und die Korrektoren in der falschen Sicherheit wiegen, sie täten mit solchen Änderungen etwas Richtiges und Wichtiges zur Verbesserung der Enzyklopädie.--Jordi (Diskussion) 16:36, 23. Jul. 2020 (CEST)

Zur Klarstellung: auf der Ausschlussliste muss gar nichts begründet werden und ob du die voreingestellte Zusammenfassung verwendest, ist dir überlassen. Wenn du einen konkreten Vorschlag für eine bessere hast, kannst du das gerne mitteilen. -- Gruß, aka 17:31, 23. Jul. 2020 (CEST)

Es wird immer wieder so getan, als ob ausnahmslos jede Formatierung eine bewusste Design-Entscheidung eines heute noch aktiven „Hauptautors“ wäre, und als ob dieser erstmal um Erlaubnis gebeten werden müsse, bevor an „seinem“ Artikel etwas verändert werden dürfe.

Viele fachlich hoffentlich kompetente Autoren haben aber noch nie etwas mit Typografie zu tun gehabt, und sie wissen auch nichts von Barrierefreiheit. Sie formatieren halt so wie es gerade kommt, wie sie es in ihren Büchern und Fachzeitschriften als Vorbild sehen, so müsse es also richtig sein, oder stellen beim C&P Formatierungen zusammen, die sie nicht beabsichtigt hatten sondern die sich eher zufällig ergaben; so wie es halt in dem ggf. externen Text gemacht wurde, der hineinkopiert wurde.

Sehr viele Formatierungen stammen von recht unerfahrenen Bearbeitern und aus der Frühphase der deutschsprachigen Wikipedia, als die Regeln für gute Textgestaltung noch nicht sehr weit ausgearbeitet und bekanntgemacht wurden; und viele Autoren haben umseitig oder andere typografische Hinweise noch nie gesehen oder es ging in der Vielzahl von Regeln zu RK und NK und TF und ZR und Belegpflicht bislang einfach unter.

Sehr viele Autoren, die einmal eine Textpassage eingefügt hatten, sind nicht mehr aktiv und leben womöglich nicht mehr. Sie können auch nicht mehr zu jeder kleinen Formatierung befragt werden. Viele hätten sich sicher gewünscht, dass die Darstellung ihrer Texte dem besten gebräuchlichen Standard entsprechen solle und von den Nachfahren entsprechend weiterzuentwickeln wäre. Die These, dass alles was ein „Hauptautor“ vor einem Dutzend Jahren mal hingeschrieben hätte dürfe auf keinen Fall niemals nicht verändert werden ist nicht haltbar.

Es gibt eine simple Regel:

• Im Fließtext hat Kleinschreibung nichts zu suchen, sofern sie nicht durch eine spezielle Notation aus Musik, Chemie oder derlei bedingt wäre.
• Wo immer für inhaltliche Darstellungen auf Kleinschreibung verzichtet werden kann soll dies geschehen. Es ist nicht nachvollziehbar, warum Bildunterschriften unlesbar werden sollen, weil das in gedruckten Büchern auch so wäre. Bildunterschriften sollen knapp das Bild einordnen; für umfangreichere Erläuterungen wäre ggf. der Fließtextbereich zu nutzen, der auch keinen Breitenbeschränkungen unterliegt.
• Im Rahmen von Tabellen können zuweilen wegen Platzmangel nachrangige Details verkleinert werden.
• Jede überflüssige Textverkleinerung ist eine Verletzung gegen die Barrierefreiheit und unterliegt damit nicht mehr gleichwertigen Geschmacksentscheidungen eines „Hauptautors“; insofern kann auch keine „Korrektoren-Regel“ herangezogen werden, sondern es ist eine Verbesserung des Artikels, wenn seine Lesbarkeit hergestellt wird.

VG --PerfektesChaos 18:01, 23. Jul. 2020 (CEST)

Das sind wie gesagt selbst ausgedachte Vorgaben und Interpretationen, die tw. sinnvoll sein mögen und die du in deiner eigenen Artikelarbeit gern beherzigen und anderen auch warm empfehlen kannst, aber niemandem vorzuschreiben hast.

• Bei der Korrektorenregel geht es gar nicht nur um Hauptautoren, jeder Autor, der zu einem Artikel beiträgt, kann natürlich auch Formatierungen, Stilfragen und sonstige Dinge verändern und sinnvoll an seinen eigenen Geschmack oder allgemeine Konventionen anpassen, soweit er sich dabei mit den übrigen Autoren einigt oder jdfs. nicht gegen den Konsens der Mitarbeiter handelt. Leute, die mit der Arbeit an dem jw. Artikel nichts zu tun haben, dürfen das dagegen nicht, sie dürfen nur eindeutige Fehler beheben und müssen sonst damit rechnen, dass irgendein an dem Artikel beteiligter Autor (nicht unbedingt nur der Hauptautor) ihre Korrekturen für unzweckmäßig hält und verwirft. Das ist normalerweise auch kein Beinbruch, vorschlagen darf man es ja trotzdem, aber eben nicht mit irgendwelchen Autoritätsargumenten durchdrücken und die beteiligten Autoren unter Druck setzen oder ihnen weismachen, man handele in höherem Auftrag.
• Mit Barrierefreiheit hat das Thema Kleinformatierung nichts zu tun, kommt jdfs. weder in dem Artikel über BI vor noch wird auf der umseitigen Hilfeseite ein solcher Zshg. hergestellt. Schau dir die Fußzeile dieser Diskussionsseite an, da steht: Diese Seite wurde zuletzt am 23. Juli 2020 um 16:02 Uhr bearbeitet. Auch das gesamte Navigationsmenü auf der linken Seite jeder Bildschirmansicht ist in klein formatierter Schrift dargestellt. Um einen Verstoß gegen Barrierefreiheit handelt es sich bei dieser Art etwas kleiner formatierter Schrift offensichtlich nicht. Genauso wenig ist es aus Sicht der Barrierefreiheit problematisch, wenn in den von mir im Rahmen meines Selbstversuchs als Korrektor unbeanstandet gelassenen Artikeln Bezirk Aarau, Bezirk Arbon und Bezirk Brugg die Angabe "Stand: 1. Januar 2020" in kleineren Buchstaben unter die Tabelle mit den Gemeindedaten gesetzt wird, weil sich der Ersteller dieser Schweizer Bezirksartikel das nunmal so angewöhnt hat. Das ist seine Sache, da haben wir nichts zu korrigieren. Das Gleiche gilt für @Spurzems Artikel aus dem Themenbereich DKW, wo er kurze Fußnoten mit händischem Sternchen und kleiner Schrift unter seine Datenblatttabellen setzt. Das kann man auch anders machen, auch professioneller oder fortschrittlicher, muss man aber nicht. Deshalb sind solche, seit jeher akzeptierten Kleinformatierungen auch innerhalb des ANR kein Problem und es gibt keinen Korrekturbedarf. Etwas anders ist das mit störenden Textgrößenänderungen mitten im Satz, sowas war noch nie üblich und das kann man sicher verbessern, hat mit Barrierefreiheit aber nichts zu tun, sondern stört einfach jeden (auch Nichtbehinderte). Barrierefreiheit darf jdfs. nicht als Vorwand für das Ausleben autoritärer Instinkte benutzt werden.
• Vergleich es einfach mal mit anderen unerwünschten Textauszeichnungen, sagen wir farbigem oder blinkendem Text im ANR. Jedem ist klar, dass das nicht erlaubt ist, weil es immer schon abgelehnt wurde und von praktisch allen seriösen Benutzern als störend oder unpassend empfunden wird und jedenfalls in der Praxis nicht konsensfähig ist. Das ist bei Kleinformatierung nunmal anders, da ist es in bestimmten Konstellationen durchaus üblich und stört keinen. Deshalb darf man das eine gern korrigieren, das andere nicht. Wenn das aus der umseitigen Hilfe nicht klar genug hervorgeht, dass da zu differenzieren ist, muss man ggf. den Text der Hilfeseite präzisieren, aber nicht die Praxis an die Hilfeseite anpassen, schon gar nicht mit Gewalt. So funktioniert das.--Jordi (Diskussion) 21:27, 23. Jul. 2020 (CEST)

Natürlich beißt sich verkleinerte Schrift mit Barrierefreiheit. Legenden besagen, dass es Menschen geben soll, die nicht über 100 % Sehkraft verfügen. -- Chaddy · D 22:16, 23. Jul. 2020 (CEST)

Und den Einsatz für eine für alle zugängliche Wikipedia mit dem Ausleben "autoritärer Instinkte" zu vergleichen disqualifiziert dich ohnehin für jede sachliche Diskussion. -- Chaddy · D 22:20, 23. Jul. 2020 (CEST)

Die Schriftgröße, um die es hier geht, ist aber offenkundig keine Barriere, sonst dürften Navigationsmenüs und Lizenzangaben in Fußzeilen nicht in ebendieser Größe formatiert sein. Schlagender können Sachargumente nicht sein, und das entlarvt eben auch, dass "Barrierefreiheit" hier nur als vorgeschobener Vorwand und nicht argumentativ sauber durchdacht eingesetzt wird, warum auch immer. Welche "Instinkte" oder Denkfehler dahinterstecken, muss man nicht weiter mutmaßen, da gebe ich dir Recht (habs gestrichen).--Jordi (Diskussion) 22:34, 23. Jul. 2020 (CEST)

Nur dass es an anderen Stellen auch schlecht ist rechtfertigt doch nicht, dass wir es einfach überall schlecht machen. -- Chaddy · D 23:40, 23. Jul. 2020 (CEST)

Es macht ja niemand etwas schlecht. Schlecht ist nur das systematische Einsetzen von Wartungstrupps, die "Fehler" und Regelverstöße erkennen, wo keine sind, und damit andere Benutzer drangsalieren und bevormunden.

@PerfektesChaos hat eingangs beschrieben, dass der Gebrauch solcher Kleinformatierungen in Artikeln nach seinem Eindruck im Vgl. zu früher nachgelassen hat. Man kann sich auch ohne Weiteres auf seine Formel einigen, wonach Kleinformatierungen im Fließtext von Artikeln natürlich nicht sinnvoll sind.

Eine Praxis, wie man sie bspw. aus juristischer Kommentarliteratur kennt, wo größer und kleiner gedruckte Textblöcke abwechseln, war in Wikipediaartikeln nie üblich und bleibt selbstverständlich unerwünscht. Damit gibt es aber keine Probleme.

Auch den früher üblichen Auszeichnungen durch Schriftgrößenänderungen mitten im Text (Stand 2010 o.Ä.) weint niemand hinterher. Dafür muss man aber nicht sämtliche <small>-Tags im ANR aufsuchen und ausmerzen, das ist völlig übertriebener Aktionismus mit einem unguten Beigeschmack. Eine systematische Änderung und komplette Ausmerzung des Tags durch Korrektoren brauchen wir nicht.

⇐ Bei dieser Aktion geht es auch nicht um Barrierefreiheit, sondern nur um das Entfernen dieses Tägs, selbst wenn es an der betr. Stelle harmlos oder sogar sinnvoll und jedenfalls erlaubt ist.

• @Aka hat meine bereits durchgesehenen Artikel wieder von seiner Ausschlussliste entfernt, erklärtermaßen aus dem alleinigen Grund, weil das Tag noch immer in den Artikeln vorkommt. Dabei besteht der Sinn dieser Liste genau darin, Artikel aufzuführen, in denen das Tag stehenbleiben kann.
• @Aka stellt genau das, was er hier oben in seinem Eingangsstatement als seine persönliche Meinung bezeichnet ("sollte ... so gut wie nie eingesetzt werden"), auf seiner Mitarbeiterinformationsseite als allgemeingültige Vorgabe dar ("sollte so gut wie immer verzichtet werden"). Und er spitzt seine Mitarbeiter durch vorformulierte Bearbeitungszusammenfassungen zusätzlich zu besonderer Schärfe an und verleitet sie dazu, seine persönliche Meinung als Wikipediaregel auszugeben (statt sie zu warnen, das Tag nur dann zu entfernen, wenn das wirklich nötig und unkontrovers ist).
• Kleinschreibung in Überschriften nach dem Muster Werke (Auswahl) finde ich persönlich potthässlich und würde das in von mir bearbeiteten Artikeln sofort ändern, aber das ist eben mein persönlicher Geschmack, hat mit Barrierefreiheit nichts zu tun und rechtfertigt keinen systematischen Korrektoreneinsatz.
• Ob @Spurzem die Fußnoten unter seinen DKW-Daten-Tabellen händisch mit <small>-Tags formatiert oder sagen wir die FNBox benutzt, ist gehoppst wie gesprungen. ^*

 

Weil die Fußnoten damit ebenfalls in kleiner Schrift dargestellt werden.

Ob jemand keine kleine Schrift mag oder bestimmte Tägs nicht zeitgemäß findet, ist Geschmackssache, hat auf die Barrierefreiheit wenig Einfluss und ist kein Betätigungsfeld für solche Schwarmaktionen.--Jordi (Diskussion) 11:08, 24. Jul. 2020 (CEST)

@Aka, du bis ja witzig. Du hast meine Einträge von der Ausschlussliste ja sogar gelöscht, obwohl ich sie begründet hatte. Und deine Begründung, die Small-Tags seien im ANR per se unerwünscht, ist eine dreiste Falschbehauptung, von der du als erfahrener Benutzer, der jeden Tag ich weiß nicht wie viele hundert Seiten im Artikelnamensraum anschaut, eigtl. genau wissen müsstest, dass sie nicht zutrifft.

Was unerwünscht ist, entscheidet nicht der Text irgendeiner Regel- oder Hilfeseite, sondern die eingebürgerte und bis dato unangefochtene Praxis der Autoren. Wenn @Bicycle Tourer das offb. noch nicht begriffen hat und die Formulierungen solcher Meta-Seiten für bindende Normierungen hält, an die sich die Praxis anpassen müsste (in Wirklichkeit ist es umgekehrt, siehe meine zwischengeschobenen Antworten an ihn oben), habe ich dafür noch ein gewisses Verständnis, bei dir als WP-Urgestein geht mir das aber ab.

Und das mit der Zusammenfassungszeile ist auch scheinheilig. Es geht doch nicht darum, dass ich oder jeder andere deine Voreinstellung im Prinzip nicht benutzen müssen, sondern darum, dass du deine vermutlich gutwilligen und positiv motivierten Mitarbeiter mit solchen Vorgaben dazu verleitest, sich autoritär aufzuspielen und dabei im Recht zu fühlen und dies auch noch in dem Bewusstsein zu tun, dass sie von oben gedeckt werden und die Verantwortung für ihr Verhalten an ein anonymes Regelwerk abgeben können. Das erinnert an Das Experiment (Film), das sind strukturell faschistoide Mechanismen, wo ganz normale Menschen zum Machtmissbrauch verführt werden, indem man sie mit Machtmitteln und "Regeln" ausstattet.

Also nochmal ganz deutlich: Deine Aufgabe ist es, eindeutig und von allen als solche erkennbare Fehler zu korrigieren. Dafür darfst du deine Listen führen und Mitarbeiter werben und selbstverständlich auch in die Zusammenfassungszeile schreiben, dass ein Fehler korrigiert wurde. Es ist nicht deine Aufgabe, Zweifels- und Ermessensfälle autoritativ im Sinne deiner eigenen Vorlieben oder irgendwelcher eingebildeter oder überstreng ausgelegter Regeln zu entscheiden, das ist Sache der Autoren jedes einzelnen Artikels und ggf. übergeordneter Redaktionen oder Fachgruppen, die dazu Vorgaben machen können. Das betrifft die Rechtschreibung, die Anwendung von Durchkopplungsregeln bei Verlagsbezeichnungen in Literaturangaben und natürlich auch unerwünschte Formatierungen. Du kannst nicht einfach auf deiner Benutzerseite vorgeben, Kleinformatierungen seien praktisch immer unerwünscht, obwohl du weißt, dass das gar nicht stimmt, und deine Mitarbeiter glauben dir das und ändern massiv alle möglichen Artikel, mit denen sie sonst nie zu tun hatten. Das ist absolut übergriffig, und dafür trägst du als Anstifter auch die Verantwortung.--Jordi (Diskussion) 21:27, 23. Jul. 2020 (CEST)

Deine Einträge auf der Ausschlussliste habe ich gelöscht, weil sie falsch waren. Hättest du sie ohne Begründung eingetragen, hätte das daran nichts geändert. Über die Zusammenfassungszeile hat sich bisher - außer dir - niemand beschwert. Einen besseren Vorschlag hat - inklusive dir - bisher auch niemand gemacht. Und bzgl. "Deine Aufgabe ist" - hier ist jede Mitarbeit freiwillig. Meiner Meinung nach regst du dich wegen Kleinkram (..) viel zu viel auf. -- Gruß, aka 09:30, 24. Jul. 2020 (CEST)

Meine Einträge waren das Ergebnis meiner Ermessensentscheidung, dass die Tags in den betr. Artikeln keine Störung und keinen Regelverstoß darstellen und deshalb von mir als Korrektor nicht einfach entfernt werden dürfen. Falsch ist deine Behauptung, das Tag müsse überall restlos entfernt werden, weil dies eine Vorgabe des Regelwerks sei. Und darüber rege ich mich auf, weil du bewusst falsche Regeln aufstellst und deine Mitarbeiter falsch informierst, um Pseudoregeln zu etablieren, die schlicht deine eigene Meinung widerspiegeln, aber nicht den tatsächlichen Regeln und Usancen entsprechen. Das ist m.M.n. Machtmissbrauch und viel schlimmer als die Tags.--Jordi (Diskussion) 11:42, 24. Jul. 2020 (CEST)

Deine Ermessensentscheidung kollidiert da mit meiner. Es sind auch nicht "meine Mitarbeiter". Die Liste zeigt nur auf, welche Artikel unseren Regeln (die du "Pseudoregeln" nennst) diesbezüglich widersprechen. Dein Ansatz ist der völlig falsche: du müsstest die Regeln ändern und nicht dort ansetzten, wo Verstöße aufgelistet werden. -- Gruß, aka 11:49, 24. Jul. 2020 (CEST)

Mit welchem MB wurde diese imho absurde "Regel" denn beschlossen? Natürlich ist das reine Geschmackssache, keine echte Regel. Grüße vom Sänger ♫ ^(Reden) 11:55, 24. Jul. 2020 (CEST)

Das hab ich ja oben schon erläutert. In der Wikipedia ist die gängige und akzeptierte Praxis die Regel. Regel- (oder wie hier bloße Hilfe-)Seiten besitzen aus sich selbst heraus keine normative Kraft, sondern stellen nur mehr oder weniger gelungen dar, worauf man sich in der Praxis geeinigt hat. Wenn die gängige und akzeptierte Praxis einer Regelformulierung widerspricht, muss die Regelformulierung präzisiert werden. Niemals dagegen die Praxis an die geschriebene Regel angepasst. Das ist ein absolutes Grundprinzip unseres Regelwerks, und dir als Urgestein muss das absolut klar sein, anders als bei jüngeren Mitarbeitern habe ich da für Aufweichungen oder Missinterpretationen keinerlei Verständnis. Wenn wichtige Mitarbeiter wie du dieses Grundprinzip freier Enzyklopädiearbeit unterlaufen oder nicht anwenden wollen, ist das ein riesiges Problem.--Jordi (Diskussion) 12:32, 24. Jul. 2020 (CEST)

Worauf man sich in der Praxis geeinigt hat - na das ist doch einmal eine Aussage. -- Gruß, aka 12:45, 24. Jul. 2020 (CEST)

Genau. Die Praxis hat sich darauf geeinigt, dass bspw. Fettformatierungen in Artikeln ganz bestimmten Regeln gehorchen (die auch nicht immer ganz eindeutig sind, aber doch relativ klar). Und dass farbige Schrift oder blinkende Buchstaben überhaupt nicht akzeptiert werden, während Kleinformatierung in weniger störenden Kontexten oder von den Autoren sogar als sinnvoll erachteten und mit Bedacht gewählten Verwendungen durchaus benutzt und akzeptiert wird, also keinen stört. Das hast du ja auch in deinem eigenen Eingangsstatement vom 1. Mai zutreffend dargestellt. Das ist die Regel, und an die soll man sich halten, und das sollte auch auf der umseitigen Hilfeseite möglichst klar dargestellt werden. Diese Hilfeformulierung ist insofern etwas irreführend, dass sie Kleinformatierungen und sagen wir Farbauszeichnungen beide als gleichermaßen unerwünscht darstellt, was der tats. Praxis nicht entspricht. Dass Kleinformatierungen grundsätzlich selten verwendet werden sollen und immer dann, wenn sie für Leser störend wirken, vermieden werden sollen, ist dagg. völlig richtig dargestellt. Allerdings ist das in aller Regel eine Auslegungs- und Ermessensfrage, die deshalb nur von Autoren und nicht von Korrektoren, jedenfalls nicht im Zuge von systematischen Massenkorrekturen entschieden werden kann.--Jordi (Diskussion) 13:15, 24. Jul. 2020 (CEST)

Barrierefreiheit

• Es ist so simpel und trivial einleuchtend und völlig banal, dass niemand dranschreibt, dass die vom Nutzer eingestellte Schriftgröße für Normalschrift diejenige ist, die gut zu lesen wäre, und jede maßgebliche Verkleinerung davon logischerweise nicht mehr erkannt werden kann. Und <small> in der von Browsern und anderen Wiedergabegeräten praktizierten Form ist zu klein; es kommen traditionell meist 85 % raus. Wenn ich explizit verkleinere, dann begrenze ich meist bei 92 % oder 93 %.
• Das braucht keine MB, dafür würde gesunder Menschenverstand langen.
• In EN 301 549 (PDF; 2 MB) Abschnitt 5.1.4, S. 23, ist das am Beispiel eines großen H vorgerechnet. Und das ist das große H in Normalschrift und eine grundlose Verkleinerung davon (außer Anmerkungszeichen usw.) ist definitiv zu klein bei 85 %.
  • WCAG 2.0
• Unser Barrierefreies Internet #Internet-Techniken, die Barrieren darstellen hebt bisher nur auf Skalierbarkeit der Schriftgröße ab, damit Besucher sich die Normalschrift einstellen können. So dämlich kannste janich denken wie sich die Leute anstellen; das meint natürlich gleichzeitig auch eine Mindestschriftgröße, ohne dass das nochmal extra dazugeschrieben würde.
• Wahllose Sammlung einiger einschlägiger Suchtreffer
  • imh gefördert durch das Bundesministerium für Arbeit und Soziales
  • textschoepfung.de
  • hellbusch.de (mit berechtigter Kritik an unserem Artikel).
  • leserlich.info
  • DIN 1450 – „Lesetext. Der Haupttext in Büchern, Broschüren, Anleitungen etc. mit den relevanten Informationen.“ (das sind unsere Artikel-Hauptteile)
• Nicht notwendig in small gesetzte Textfragmente zwingen die Betroffenen dazu, jedes Mal die Bildschirmlupe einschalten zu müssen, um das Textfragment entziffern zu können.
  • Das ist aber beispielsweise dann nicht der Fall, wenn sich der Inhalt aus dem Kontext erschließen lässt. Das Anmerkungszeichen unserer <ref> lässt sich anklicken, ohne die Nummer lesen zu müssen; mag 89 oder 98 oder 69 oder 96 sein, egal, ich werde meist auf die richtige Stelle platziert und diese blau hervorgehoben. Gleiches gilt für eine Flächenangabe; das Exponentialzeichen muss zwangsläufig die Ziffer 2 sein.
• Benutzer mit verminderter Sehkraft machen einen maßgeblichen Teil der Leserschaft aus; Institutionen gehen von 10 % bis 20 % an Internetnutzern mit spürbarer nichtkorrigierbarer Einschränkung aus.
• Im Übrigen steht das umseitig ununterbrochen seit Januar 2006 und schon vorher drauf; wenn das kein durch über ein Jahrzehnt gefestigter Konsens des Projekts ist dann weiß ich auch nichts mehr.

VG --PerfektesChaos 18:59, 24. Jul. 2020 (CEST)

Danke. Das klingt interessant.

• Inwieweit die Berechnung unter deinem ersten Link die These stützen soll, mit "small" formatierte Texte seien eine ernste Barriere, muss man auch erstmal verstehen. Wenn man das nachrechnet, heißt das, eine Person, die die normale Schriftgröße so eingestellt hat, dass sie sie bei einem Neigungswinkel von mind. 0,7 Grad aus 60 cm Entfernung gerade gut lesen kann, muss die Augen ca. 9 cm näher an den Bildschirm heranbewegen, um klein formatierten und vom Anzeigeprogramm mit 85 % der Originalgröße ausgegebenen Text mühelos entziffern zu können (ohne irgendwelche zusätzlichen Hilfsmittel wie Bildschirmlupe, Browservergrößerung, Lesebrille etc.). Schaut sie aus 50 cm Entfernung auf das Bild, muss sie ca. 8 cm näher rangehen; bei 40 cm sind es noch ca. 6 cm und bei 30 cm Abstand rd. 5 cm. Generell empfohlen werden 45–70 cm Entfernung vom Bildschirm, Oberkante in Augenhöhe, die Bildschirmfläche zum Blick ausgerichtet, leicht nach oben (S. 10). Zu bedenken ist, dass diese Person auch die Navigationsmenüs, die Lizenzhinweise am Fuß der Seite und sämtliche Bildlegenden, die ja ebfs. in kleinerer Schrift erscheinen, nur erkennt, wenn sie wenige Zentimeter näher an den Bildschirm herangeht.

• Zum letzten Punkt, der ist entscheidend: Du hattest oben selbst plausibel erklärt, dass es solche Kleinformatierungen im ANR seit jeher gab und das früher sogar recht ausgiebig gemacht wurde. Wenn die theoretische Vorgabe auf dieser Hilfe-Seite, möglichst keine Small-Tags zu benutzen, schon so alt ist und von Anfang an in der Praxis nie übermäßig streng beachtet oder hinterfragt worden ist, bedeutet das genau das Gegenteil von dem, was du daraus schließt ("gefestigter Konsens des Projekts"). Der seit 15 Jahren gefestigte Konsens des Projekts ist demnach, dass diese Vorgabe zumindest in ihrer strengen Auslegung ignoriert werden kann. Und zwar abweichend von der wohl gleichzeitig formulierten Vorgabe, keine Big-Tags oder keine farbige Schrift zu verwenden (obwohl übrigens gerade die aus Sicht der Barrierefreiheit empfohlen wird, wie dein zweiter Link belegt), denn das wurde immer beachtet.

Nochmal: Was irgendjemand irgendwann auf eine Hilfe-Seite geschrieben hat, ist für das Regelwerk unerheblich. Maßgebend ist immer, was in der realen Wikipediawelt tatsächlich praktiziert wird und allgemein akzeptiert ist. Und wenn das schon so lange entgegen dem Wortlaut der Hilfe toleriert und gutgläubig angewandt wird, gilt das umso mehr. Da ist es regeltechnisch völlig ausgeschlossen, als Korrektor unter Berufung auf eine vermeintliche "Regel" gegen den gefestigten Konsens des Projekts vorzugehen und eine massive und professionell organisierte "Fehlerkorrektur" zu beginnen, wie @Aka das versucht.

• Das schließt ja nicht aus, dass man sich weiter und von mir aus auch mit dem Argument der Barrierefreiheit darum bemüht, Kleinformatierungen zu reduzieren. Nur musst du dazu eben die Autoren überzeugen und kannst nicht autoritativ unter Berufung auf eine nicht existierende Regel vorgehen. Außerdem sollte man halt differenzieren und nur dort darauf drängen, wo die Kleinformatierung wirklich stört (also z.B. nicht in den Schweizer Bezirksartikeln oder bei Fußnoten, die sowieso kleiner ausgegeben werden).
• Man könnte zum Bsp. @Akas Liste nutzen und einen Bot irgendeinen Hinweis auf die Diskussionsseiten der betroffenen Artikel setzen lassen, nach dem Motto: Auf dieser Seite wurde klein formatierter Text gefunden. Bitte überlege, ob das wirklich nötig ist, und denke dabei auch an die Barrierefreiheit, danke! Das wäre dann auch weniger Arbeit für die Korrektoren. Einen generellen Ban des <small>-Tags mit systematischen Reinigungsaktionen wie hier von @Aka organisiert ist dagegen nach ggw. Stand der Dinge unerwünscht und nicht regelkonform.--Jordi (Diskussion) 01:34, 25. Jul. 2020 (CEST)

Na dann schreibe doch so einen Bot oder packe solche Hinweise per Hand auf die Diskussionsseiten oder frage die Autoren. Oder erstelle eine Liste nach deinen Wünschen und mit deinen Regeln. Oder, wenn dich meine so sehr stört, wie wäre es mit einem Löschantrag? -- Gruß, aka 09:15, 25. Jul. 2020 (CEST)

Bitte dieses BNS-lastige Schmollen unterlassen. Niemand stellt deine großartigen Leistungen für das Wikipedia-Projekt im Bereich Fehlerkorrektur in Frage. Ich selbst schicke dir stets Dankeschöns hinterher, wenn du wieder einmal binnen weniger Minuten einen von mir zu verantwortenden Rechtschreibfehler korrigierst. Diese Liste ist Teil deines BNR, wer bin ich, um da irgendwelche Löschungen zu verlangen? Für die richtige Verwendung und regelkonforme Anpassung der Mitarbeiterinformationen bist du allein zuständig. Die Idee mit dem Benachrichtigungsbot war ja gerade ein Versuch, wie man diese an sich nützliche Wartungsliste doch noch sinnvoll und in nicht übergriffiger Weise einsetzen könnte, um unnötige Kleinformatierungen reduzieren zu helfen, damit die Arbeit nicht umsonst war. Im Übrigen habe ich mich parallel zu dieser Diskussion ja selber auf der Basis dieser Liste betätigt und mehrere Artikel verbessert, die ich darüber gefunden habe.

Wenn derart wichtige Mitarbeiter wie du oder @PerfektesChaos, dessen Verdienste im Bereich der Anwendertechnik ich ähnlich hoch einschätze, ein positivistisches Regelverständnis zeigen, wie man es gltl. bei neueren Mitarbeitern antrifft, die Wikipedia-Regularien für ein durchkomponiertes und systematisch durchdachtes Regelkorpus halten und den grundlegenden Charakter solcher Aufzeichnungen als Gedankenstützen für die allein maßgebende Praxis verkennen, läuten gerade deshalb, weil eure Arbeit so wichtig ist und so großen Einfluss hat, sämtliche Alarmglocken.--Jordi (Diskussion) 10:45, 25. Jul. 2020 (CEST)

Em- und Strong-Tags

Sollen/können/mussen wir ggb. die em- und strong-Tags verwenden? --Z 18:15, 24. Sep. 2020 (CEST)

Nein. Siehe umseitig: "Fett- und Kursivschreibung soll nicht mit HTML-Tags formatiert werden." Und Hilfe:Tags#Unerwünschtes HTML: "Wo die Wikisyntax selbst Möglichkeiten bietet, sollen keine HTML-Elemente eingebracht werden." Also bitte keine weiteren Massenänderungen in dieser Richtung. --Magiers (Diskussion) 18:27, 24. Sep. 2020 (CEST)

Zwar würde ich em- und strong-Tags schon von i- und b-Tags abgrenzen wollen, aber was ich kürzlich über den Nutzen horizontaler Aufzählungen geschrieben habe, gilt wohl auch in diesem Fall. Diese rein semantische Meta-Syntax hat keinen offensichtlichen Mehrwert gegenüber der üblichen Darstellung und verkompliziert lediglich den Quelltext. Ich glaube nicht, dass Menschen, die auf Screenreader angewiesen sind, dadurch einen relevanten Nachteil erfahren; wenn doch, dann sollte man gleich softwareseitig immer em- und strong-Tags einsetzen lassen. Auf keinen Fall darf man das den Autoren aufbürden.–XanonymusX (Diskussion) 23:18, 24. Sep. 2020 (CEST)

Das bringt durchaus Nachteile mit sich, denn ein <em><strong> muss immer ein </strong></em> als Partner haben was zu einer vermehrten Fehleranfälligkeit führen würde, wenn mal wieder jemand irgendwo einen / vergisst. Wir haben auch so schon genügend Linterfehler da muss man nicht künstlich noch weitere Fehlerquellen erzeugen, die zudem für Verwirrung bei denjenigen sorgt, die diese Tags nicht kennen. Zudem hat das em eine andere Bedeutung als ein reines kursiv-Tag. Das em bewirkt eine besondere Betonung in der Aussprache (. Das <em> -Tag stellt die Betonung des Inhalts dar, während das <i> -Tag Text darstellt, der von der normalen Prosa abgesetzt wird ….) wenn ich das richtig interpretiere. Bitte also nicht irgendwo in die Seiten schreiben. Es ist schon so ein Fass ohne Boden alle Linterfehler zu eliminieren. --Liebe Grüße, Lómelinde Diskussion 09:05, 25. Sep. 2020 (CEST)

We have to look into history first.

• In the 1990s I and B have been introduced as typographic markup, since HTML.2 has been just typographic representation of paperwork on web pages.
• 1998 by HTML.4 course had changed.
  • HTML documents should be semantic declaration of content structures only, and it is up to the client environment (style sheets) how content is presented depending on semantic meaning.
  • EM and STRONG have been introduced.
  • I and B had been obsoleted and should be removed from all documents.
  • Browsers should continue to show I and EM in a reasonable way, for which italic might be helpful in latin scripting. The concept of italic does not work for Chinese, Japanese, Hebrew, Arabic and even not for Greek letters.
  • Browsers should continue to show B and STRONG in a reasonable way, for which bolding might be helpful in letter scripting. However, this concept does not work well for Chinese, Japanese, Hebrew, Arabic.
• The web designers never anticipated that on broad scale, nor were old documents rewritten.
• With HTML5 about 2010 the I and B have been rehabilitated with a cryptic and not reasonable message. They do mean actually the same as EM and STRONG but they should be something different. Actually this is confessing that the world did not honour introduction of those semantic elements.

Since none of billions of web documents never made a distinction between I and EM nor B and STRONG they do not make any difference.

• Both optical browsers and screen readers treat both the same way.
• The difference is stated in HTML5 only, but has no consequence.
• Since neither browser nor screen reader can know without further declaration what meaning a particular document would like to be assigned, they handle both pairs similar in standard production. Over decades there was no culture that all authors will distinguish anything.
• A screen reader has no big choice to express many levels which might be adressed by document authors. There are just two pronunciations available and could be interpreted by the listener:
  1. emphasized
  2. emphasized and louder
• If there is more distinction intended by particular publishers they have to provide specific screen/aural stylesheets. If not, standard presentation is identical.

A wiki text is heading for a very simplified language, which could be understood easily by all authors.

• For emphasizing '' is the sufficient syntax element.
• For strong emphasize ''' is the sufficient syntax element.
• Any further syntax element is unknown to our users and will confuse.
• German Wikipedia has abandoned usage of B I EM STRONG elements.
  • They might occur in some source text copied from anywhere.
  • As soon we detect them they will be replaced by syntax known to our users.
  • It is a rather bad idea to run over our community pages and modify them in a way which only a couple of HTML experts would understand.

Greetings --PerfektesChaos 01:16, 27. Sep. 2020 (CEST)

Thanks for the extensive clarification. Indeed, I thought the screen readers actually make a distinction. --Z 13:11, 27. Sep. 2020 (CEST)

Es ist eigentlich ein Defizit der Screenreader, wenn sie so wenig differenzieren können. Semantische Auszeichnung ist hier schwierig, denn viele schreiben im Quelltextmodus und da will man nicht halbe HTML-Seiten schreiben. ÅñŧóñŜûŝî (Ð) 13:37, 27. Sep. 2020 (CEST)

Das ist dieselbe Logik, als würdest Du sagen: Die Blinden sollen sich mal etwas mehr anstrengen; warum sollen wir das für sie barrierefrei gestalten?

Screenreader können schon erstaunlich viel und werden ständig besser, aber sie können noch nicht alles und werden es vermutlich nie können. Zum Beispiel Bilder interpretieren können sie auch noch nicht, wenn den Bildern kein Alternativtext o.ä. beigegeben worden ist.

Es kann jedenfalls nicht angehen, dass die Forderung nach Barrierefreiheit an die gerichtet wird, die auf sie angewiesen sind: "Seht gefälligst zu, dass Ihr bessere Geräte bekommt!" --217.239.6.208 12:58, 11. Okt. 2020 (CEST)

There are already four levels of intonation, which a screen reader needs to express:

1. Normal voice
2. Emphasized
3. Strong (perhaps louder)
4. Both strong and emphasized

How many feelings a screenreader shall express, and how many feelings will be understood by the listener, and how shall they adressed and linked with particular meanings by the publisher?

• Normal
• I
• EM
• EM + I
• B
• STRONG
• STRONG + B
• EM + STRONG
• I + B
• EM + STRONG + I
• EM + STRONG + B
• EM + STRONG + I + B

Since there are billions of web pages using B and I, and millions of web pages using EM and STRONG, and almost all of them are heading for typographic presentation only – what shall all these emotions tell a listener? Where is the dictionary of feelings telling both publishers and listeners all those interpretations?

It is a HTML zigzag only, but pointless for standard presentation.

If ever, a website needs to declare aural style sheet and define a language of emotions, by male or female speakers, or certain cues, and tell both authors and listeners the meaning of such encodings. Once such language has been published for this particular website, it does not matter whether they use class="strong" or class="louder" or class="emphasize" or class="strong emphasize" – or using HTML elements to mark a distinction.

Greetings --PerfektesChaos 14:39, 27. Sep. 2020 (CEST)

"Auskommentieren"

WP:Auskommentieren ist eine WL hierher. Das Wort kommt aber in dem Artikel nicht ein einziges Mal vor, geschweige denn eine Erklärung dazu. Wo finde ich dazu Informationen? --217.239.6.208 12:49, 11. Okt. 2020 (CEST)

H:Textgestaltung#Kommentar du kannst ja mal die WL dahingehend anpassen. --Liebe Grüße, Lómelinde Diskussion 13:18, 11. Okt. 2020 (CEST)

Danke für den Tipp! Mal sehen, ob's funktioniert... scheint so!

Allerdings gebe ich zu bedenken, dass das im WP-Insider-Slang vielfach gebrauchte Wort "auskommentieren" nach wie vor nirgends erklärt wird. Bei Wort "auskommentiert" habe ich eher die Assoziation "austherapiert". --217.239.6.208 15:35, 11. Okt. 2020 (CEST)