Hilfe Diskussion:Textgestaltung/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Hilfe Diskussion:Textgestaltung/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Hilfe_Diskussion:Textgestaltung/Archiv#Thema_1

- 2003 -

Umgestaltung

Warum erscheint seit heute der Text in einer neuen, sehr schwer leserlichen Schriftart. Ich finde sie hätten es nicht ändern dürfen!! Viele Grüße Herbert Ohl, Herrenweg 17, D-83324 Ruhpolding

Kapitel(überschriften) und Links

Man sollte darauf hinweisen, daß Links auf Kapitel Links auf Bookmarks sind, die aus eben diesen Überschriften generiert werden.

Das führt zu folgenden Problemen:

• Bei ziemlich langen Überschriften welche zwar im Artikel schön aussehen (und auch passend sind), ist das ziemlich kompliziert – insbesonders wenn der verwendete Browser möglicherweise kein copy-and-paste unterstützt. Ein Beispiel wäre der Link auf Kartoffelstärke (Seite bearbeiten um den Quelltext zu sehen…).
• Wenn jemand aus welchen Gründen immer die Kapitelüberschrift ändert, so führt der Link ins Nirwana (na ja, nicht ganz – der Hauptartikel wird angezeigt, aber das Kapitel nicht mehr angesprungen).

Die Nutzer sollten also dazu angehalten werden, möglichst kurze Artikelüberschriften zu wählen.

Leute, die HTML können, können sich wie hier (Hugo) gezeigt helfen.

Wäre es nicht viel besser den <A NAME="xxx"/>-Tag irgendwie echt in die Wiki-Sprache einzubinden?
MikeTheGuru 18:30, 14. Feb 2004 (CET)

Links auf Überschriften in Artikeln sollten überhaupt nicht gesetzt werden, einfach weil man nicht erwarten kann, dass jemand beim Ändern einer Überschrift in einem Artikel noch überprüft, ob vielleicht irgendwer darauf einen Ankerlink gesetzt hat. --elian 20:02, 25. Mär 2004 (CET)

---

Gelegentlich tauchen Überschriften auf, die nur mit einfachen Gleichheitszeichen markiert wurden. Sehe ich das richtig, dass diese problematisch für das TOC sind? sollte man irgendwo betonen, dass man bei der Strukturierung mit jeweils zweien anfangen "muss"? Oder sehe ich Probleme wo keine sind? -- fristu 15:05, 3. Sep 2003 (CEST)

= machen für das TOC keine Probleme, die Überschriften sind dann nur im Text wesentlich größer. Soviel wie ich weiß, hat = noch keine spezielle Verwendung und == hat sich in der Wikipedia als "erste" Überschrift durchgesetzt. Ich denke deshalb nicht, dass das extra irgendwo betont werden müsste. --diddi 16:59, 3. Sep 2003 (CEST)

---

Warum ist das "br"-Tag eigentlich

ersatzlos rausgeflogen,

das ist doch auch für Laien problemlos nutzbar

und ohne sehen die Texte oft recht besch...

aus

Hafenbar 01:10, 9. Dez 2003 (CET)

Dein Text sieht auch schaut beschissen aus -- und du benutzt kein br. Es ist Aufgabe der Software, den Text zu formatieren und nicht die, des Benutzers. Und wer Absätze will, macht gescheite Absätze mit Zwei-Mal-Enter drücken und keinen so Pseudo Unfug mit HTML-Tags. --diddi 13:23, 9. Dez 2003 (CET)

Dein Text sieht auch schaut beschissen aus -- und du benutzt kein br Muss ich das verstehen ?
Es ist Aufgabe der Software, den Text zu formatieren und nicht die, des Benutzers. Eine Software rendert einen Text - nach den Formatierungs-Vorgaben eines Menschen.
Und das hier : <center>Zentrierter Text.</center> ist kein Pseudo Unfug mit HTML-Tags ???
Besten Dank für die fundierte Antwort ... Hafenbar 23:14, 22. Feb 2004 (CET)

habs ausgebessert, hoffe es gibt nun keinen Pseudo Unfug mit HTML-Tags mehr. --Pythagoras1 11:26, 7. Jul 2004 (CEST)

Hmm, es ist schon ein Unterschied zwischen Absatz und Zeilenwechsel, so wie hier:
Das ist eine neue Zeile im Absatz
und hier geht der Absatz wieder weiter.
Außerdem geht <BR> ohnehin, es sollte nur XML-Konform geschrieben werden: <BR/>

Was mir aber viel unangenehmer aufgefallen ist:
Das normale CR/LF welches durch normalerweise durch ENTER erzeugt wird führt bei durch ::…:: eingerückten Absätzen auch zu einem Zeilenwechsel, und das sollte beim Rendern ignoriert (d. h. wie ein sonstiges whitespace-Zeichen – also wie ein BLANK – behandelt) werden, siehe folgendes Beispiel: Hier kommt ENTER:

Jetzt geht's weiter - und das sollte ohne Zeilenumbruch weitergehen, wie diese Zeile zeigt (Quelltext angucken…);
MikeTheGuru 15:59, 24. Feb 2004 (CET)

@diddi: Dein Text "sieht auch schaut beschissen aus". Das <br />-Tag sollte unbedingt erklärt werden, denn es ist genau wie Satz-Tags (center, right, left etc.) in Tabellen durchaus sinnvoll, außerdem bei Textbeispielen in gebundener Sprache (Gedichte), wörtlicher Rede mit verteilten Rolle etc., oder willst Du das alles mit doppeltem Zeilenabstand formatieren?

BTW: was sollte denn das "und du benutzt kein br"? Hafenbar wollte doch gerade zeigen, daß es "besch..." aussieht, ohne br. Was meintest Du damit? --Rob 12:27, 26. Okt 2005 (CEST)

- 2004 -

Typografische Mittel

Ich bin mir etwas unsicher, was die Gestaltung von Wiki-Texten mit typografischen Mitteln angeht. Ich bin der Meinung, dass z. B. Gedankenstriche – wie dieser hier – mit Hilfe von Entities wie– kodiert werden sollen anstatt - wie hier - mit einfachen Strichen. Gibt es dazu Standards (keine gefunden) oder laufende Diskussionen?

Unter Wikipedia:Sonderzeichen#Satzzeichen und Webtypografie#Striche steht was.

Um es Techniklaien so einfach wie möglich zu machen, Artikel zu bearbeiten, sollte auf den Einsatz von Entities verzichtet werden. Diskussion dazu zum x-ten Male unter Wikipedia Diskussion:Rechtschreibung--elian 20:04, 25. Mär 2004 (CET)

Was sind Entities? Gibt es in Wikipedia ein Raum wo man bezüglich Rechtschreib-Fragen/Problematik hilfe erhalten kann? (habe vergebens gesucht) -- 21:36, 20. Jan 2006

Bei Wiktionary habe ich sehr schnell hilfe bekommen, dieses Schwester-Projekt sollte nicht so abgeschottet sein. --Olliminatore 19:21, 21. Jan 2006 (CET)

Formatierung von Programmcode

Ich würds toll finden, wenn man eine Formatierungshilfe für Programmcode einführen könnte. Wär vor allem für informatik-bezogene Artikel sinnvoll. Idealerweise dann gleich für eine allgemeine Algorithmus-Sprache wie Jana (Informatik). Wie schön das aussehen kann ... siehe Halteproblem. Jedoch führt der Einbau von div-Tags anscheinend leicht zu Anzeigeproblemen (siehe Diskussion:Halteproblem). Dieses Problem würde mit einer Formatierungshilfe auch erschlagen werden ...
Btw, warum kann man die Einfärbung von Text nicht mit span-Tags machen (Habs probiert, werden nicht interpretiert)? Die wären doch viel ungefährlicher für die Seiten-Struktur als div-Tags. --brunft 15:26, 12. Mär 2004 (CET)

Mittlerweile ist das kein Problem mehr. --ChristianErtl 01:08, 23. Sep 2005 (CEST)

variablen

Was haben eigentlich 'Variablen' mit 'Textgestaltung zu tun?

Hast Du einen besseren Vorschlag, wo die stehen könnten? - WikiWichtel 20:57, 24. Mär 2004 (CET)

Alphabetische Links

Wie wäre es mit Links zum alphabetisch vorhergehenden und nachfolgenden Artikel in der Zeile wo die Interwikilinks sind.

doch ein Apostroph

In der ersten Tabellenzeile steht (Das ' ist das Zeichen für Grad-Minuten oder Fuß. Es ist weder das Anführungszeichen, noch ein Apostroph oder Akzent.

Soweit ich weiß gibt es in der Unicode-Tabelle kein separates Zeichen für Grad-Minuten usw., oder lieg ich da falsch? Im Artikel Apostroph wird ja auch ausgeführt, daß es ein und dasselbe Zeichen ist. --Seither ¡! 00:39, 22. Nov 2004 (CET)

also ich sag dazu immer hochkomma. --Pythagoras1 (⠙⠊⠎⠉⠥⠎⠎⠊⠕⠝) 16:19, 23. Nov 2004 (CET)

nachtrag: mir ist des öfteren auch die bezeichnung einfaches anführungszeichen aufgefallen. speziell in tutorials von programmiersprachen tendiert man eher zur unterscheidung von einfachen und doppelten anführungszeichen. --Pythagoras1 (⠙⠊⠎⠉⠥⠎⠎⠊⠕⠝) 16:23, 23. Nov 2004 (CET)

Fein, aber meine Frage war eigentlich: sollte das nicht geändert werden? Für so einen wiki-internen Artikel bin ich nämlich noch nicht mutig genug ;) --Seither ¡! 20:56, 23. Nov 2004 (CET)

Der eigentliche Apostroph wird durch ’ (U+2019, Alt + 0146) dargestellt (bzw.: „preferred character“, eigentlich im Deutschen nicht verwendetes einfaches rechtes Anführungszeichen). --ChristianErtl 04:57, 19. Aug 2005 (CEST)

Es gibt übrigens doch ein Zeichen für Minuten und Fuß: ′. Es findet sich auch in der Sonderzeichenleiste im Bearbeitungsfenster. --ChristianErtl 01:41, 10. Okt 2005 (CEST)

Text über mehrere Absätze als Listeneintrag

Als ich EMEA bearbeiten wollte ist mir aufgefallen, daß sowas wie

# Dings
Bums
# noch eins

um eine Liste zu generieren nicht geht ohne die Einrückung zu verlieren und den Zähler zurückzusetzen.

Man kann aber doch nicht erwarten, daß sich jeder Punkt (gilt auch für *, : usw.) in einem Absatz beschreiben läßt, das ist unübersichtlich. Gibt's da eine Lösung, vielleicht lassen sich zwei Absätze irgendwie zu einem Punkt klammern. --jailbird 01:10, 14. Dez 2004 (CET)

Ich schreib das mal obwohl schon lange her ist... ganz spontan würd ich sagen

# Dings<br />bums<br />einer geht noch, und
# Nochwas

dann kommt

1. Dings
   bums
   einergeht noch, und
2. Sonstwas

raus ... --Telcontar 12:54, 11. Mär 2005 (CET)

Danke für Deine Antwort. Der angegebene Weg ist zwar nicht der Knaller, aber ein annehmbarer Workaround. --jailbird 16:34, 21. Jun 2005 (CEST)

Ist er natürlich nicht,weil nach pber einem Jahr Arbeit an der Wiki-SW keine vernünftigen Listen zustande zu bringen sind.

1. <1.>
   1. <1.1>
      1. <1.1.1>

erzeigt nur Blödsinn, wie man sieht. --มีชา 22:01, 18. Apr 2006 (CEST)

Text unter- und durchstreichen

<strike> und <u> sind lt. (X)HTML-Specs deprecated. Sollten wir dann nicht besser <del> für im Beispiel für durchstreichen benutzen? Nur was dann anstelle von <u>? --jailbird 14:29, 19. Dez 2004 (CET)

Nein, da nicht nur die Elemente <strike> und <u> missbilligt (deprecated) wurden, sondern die Benutzung von (X)HTML zur Formatierung allgemein. Der Missbrauch von Strukturelementen zur Formatierung ist damit genau so deprecated. <del> heißt nichts anderes als gelöscht, nicht durchgestrichen. Wer unbedingt Formatierungen in die Information panschen möchte, wie es vom W3C missbilligt wurde, der soll auch die missbilligten Elemente nutzen und nicht andere Elemente dafür missbrauchen. Ansonsten muss mal jemand in das Wikipedia-CSS schreiben, dass <del> nicht durchgestrichen, rot und mit gepunktetem Rahmen erscheinen soll. ;-) --Sascha Claus ✉ 15:02, 2. Apr 2005 (CEST)

Textausprägungen sollten generell mittels CSS und nicht mittels HTML-Tags vorgenommen werden, daher sind die beiden Tags auch als deprecated gekennzeichnet und in der XHTML2-Spec nicht mehr vorhanden. Meiner Meinung nach sollte hierfür eine Wiki-Syntax erstellt werden, und die Umwandlung in gültiges XHTML-Format sollte durch die Wiki-Software geschehen. Mir ist es ohnehin unverständlich warum es für fett- und italic-Schreibweise Wiki-Syntax gibt, für das Untersreichen jedoch (X)HTML verwendet werden soll. --DerCobold 11:13, 26. Mär 2005 (CET)

Ganz einfach: Früher, in der vorigen Software, gab es keine Wikisyntax für fett und kursiv, sondern nur für betont und wichtig. Das hat gereicht, für alles andere hätten, der Auffassung des W3C folgend, sowieso Klassen ran gemusst.

Der korrekte Weg wäre also: Anstatt dass jeder unter-, durch- und überstreicht und fett und kursiv formatiert wie er gerade lustig ist, werden für die auszeichnungswürdigen Dinge Klassen definiert, die zentral über das CSS formatiert werden. --Sascha Claus ✉ 15:02, 2. Apr 2005 (CEST)

Mir ist die Trennung von HTML und CSS, bzw. logischer und physischer Auszeichnung durchaus bekannt und ich verwende auch strikt CSS wenn ich Seiten erstelle. Aber hier mit der Abstrahierungsebene Wikisyntax möchte ich so wenig wie möglich class, style usw. einfügen.

Zumindest für <strike> kann ich mir überhaupt keine andere Bedeutung als Löschung, also <del> vorstellen. Von daher fände ich das ok. Die Sache mit der logischen Auszeichnung ist natürlich, daß die gleiche Auszeichnung je nach Stylesheet anders aussehen kann als erwartet/gewohnt. --jailbird 16:43, 21. Jun 2005 (CEST)

Sollste ja auch nicht selber machen, sondern sich irnkwer Wikisyntax dafür ausdenken. Sowas wie ==, * etc., nur halt für Lemma und alles andere auszeichnungswürdige. --Sascha Claus ✉ 21:58, 18. Aug 2005 (CEST)

- 2005 -

Zeilenumbruch

Hat jemand eine Idee, wie man für die Darstellung im Internet Explorer einen Zeilenumbruch nach einem Bindestrich verhindern kann? -  wird nämlich auch dann umgebrochen, wenn man einen geschützten Bindestrich (ANSI-Code 173) verwendet. Problematisch ist das bei manchen Navigationsleisten, z. B. bei Vorlage:Navigationsleiste Bundesministerien (Österreich) (z. B. „Land- und Forstwirtschaft“) --Alib 12:10, 21. Jun 2005 (CEST)

Bei Mozilla klappt der Zeilenumbruch nicht nur in der angegebenen Weise, sondern auch ohne Leerzeichen und Schrägstrich. Haben Leerzeichen und Schrägstrich nach dem "br" irgendeine andere Bedeutung oder ist das ein Schreibfehler? Außerdem klappt mein Zeilenumbruch sogar in Tabellen und im darüberstehenden Tabellentext. -- Ra'ike 11:34, 28. Jun 2005 (CEST)

Wie ist das mit dem < p >-tag? scheint ja

zu funktionieren.

Der abschließende Schrägstrich gehört laut XHTML dazu (beim W3C nachzulesen). XHTML verlangt eine korrekte Baumstruktur: Jedes Element muß einen Anfang und ein Ende haben, dabei dürfen sich Elemente nicht überlappen, z.B.

<p>Absatz mit <div class="cite">zitiertem Text</div></p>

aber niemals so: <p><div class="cite">Text</p></div>

"Leere" Elemente wie <br> und <hr> müssen außerdem - gewissermaßen zur Simulation des nicht existierenden </br> - mit einem Schrägstrich abgeschlossen werden: <br />. Da ein Browser normalerweise alles ignoriert, was er nicht versteht, stört das auch nicht, wenn der Browser von XHTML nichts weiß.

Wie man IE überredet, Zeilen an einer anderen Stelle umzubrechen als er es für gut hält, weiß ich leider auch nicht genau. Vielleicht funktioniert es mit dem Unicode non-breaking Hyphen &#x2011; und &nbsp;? Freundliche Grüße J. --89.57.186.216 13:45, 29. Sep 2006 (CEST)

Man kann auch die CSS-Eigenschaft "white-space" einem Element wie <a href="xyz">x- y</a> zuordnen (Referenz W3C):

<span style="white-space: nowrap;">x- y</span>

Oder man verwendet "pre" statt "nowrap", dann sollen die Leerzeichen wie beim <pre></pre> (HTML) erhalten bleiben, aber keine Monospace- (=Teletype-)Schrift eingestellt werden. Wenn man "span" aus irgendwelchen Gründen vermeiden will, tut es vielleicht statt dessen <div></div>. Beste Grüße J. --89.57.165.147 20:11, 11. Okt. 2006 (CEST)

Verschachtelte HTML-Tags

Sollte man beim folgenden Code zum Tiefstellen

<small>_1</small>

nicht die Tags in der richtigen (d.h. umgekehrten) Reihenfolge wieder schließen, also so:

<small>₁</small>

--Oliver Zettinig 19:42, 12. Jul 2005 (CEST)

• Hab's jetzt einfach ausgebessert... --Oliver Zettinig 10:43, 14. Jul 2005 (CEST)

So wie du's gemacht hast, ist es auch völlig richtig. --W.W. 00:00, 28. Sep 2005 (CEST)

Definitionsliste

Bei mir werden, wenn ich als Benutzer angemeldet bin, die Definitionslisten-Punkte nicht fett dargestellt. Gibt es hierfür eine spezielle Einstellung ? --MikeKrueger 11:36, 16. Jul 2005 (CEST)

Liste mit Startwert

In HTML kann man Aufzählungspunkte mit einem Startwert festlegen:

<ol><li value="16">Startwert 16</li></ol>

16. Startwert 16

Im Wiki erzeugt mal eine Liste mit Aufzählungspunkten mit dem Gatter #:

1. Punkt 1
2. Punkt 2

Wie kann ich mit diesem Gatter auch einen bestimmten Startwert einstellen, wenn eine Liste z.B. durch erläuterten Text unterbrochen und danach mit dem korrekten Wert fortgesetzt werden soll, oder die Listenteile in zwei nebeneinanderstehenden Tabellenfeldern stehen und im rechten Tabellenfeld mit dem fortgesetzten Wert des linken Feldes anfangen soll? --W.W. 14:26, 5. Sep 2005 (CEST)

Gesperrte Schrift, Laufweite verändern

Kann mir jemand sagen ob es mit Mediawikimitteln möglich ist Text mit einer größeren Laufweite darzustellen (oder auch gesperrt) -- Antropositiv 08:13, 21. Sep 2005 (CEST)

Hierfür gibt es keine gesonderte Wiki-Syntax, du kannst aber wie in XHTML sonst auch ein span mit entsprechendem CSS verwenden:
<span style="letter-spacing:0.3em">Text</span>. Siehe Quelltext von Auszeichnungsart. Man könnte eine Vorlage dafür erstellen. --ChristianErtl 04:51, 22. Sep 2005 (CEST)

Danke für die Hilfe. Mir ging es um mein eigenes Wiki und da habe ich mir eine Vorlage gebastelt, an die ich den zu sperrenden Text als Parameter übergebe. --Antropositiv 19:33, 30. Sep 2005 (CEST)

HTML-Tags verwenden

Hallo, warum darf man nicht einfach die normalen HTML-Tags benutzen? Die kenne ich wenigstens schon... -- 00:22, 3. Okt 2005 (CEST)

Viele Leute können es nicht, es wirkt für viele sehr unübersichtlich. Sofern es notwendig ist, musst du dich übrigens an die XHTML-Syntax halten. Die HTML-Umsetzung der Wiki-Syntax kann außerdem zentral geändert werden, HTML-Elemente müssten entweder als Syntax behandelt werden oder in jedem Artikel ersetzt werden. --ChristianErtl 23:34, 9. Okt 2005 (CEST)

Rahmen

Hallo ich vermisse Aussagen zu Rahmen bzw. Kästchen. Matt1971 ♫ 10:08, 9. Okt 2005 (CEST)

Was meinst du denn mit Rahmen? Frames gehen hier glücklicherweise nicht. Einige missbrauchen hier für Boxen Tabellen, aber man sollte divs und Cascading Style Sheets dafür verwenden. --ChristianErtl 20:34, 9. Okt 2005 (CEST)

• So etwas:

Text

Text

Text

Text

...	...
...	...

Matt1971 ♫ 16:03, 11. Okt 2005 (CEST)

Ich meinte mit den divs, dass man keine Tabellen verwendet, wenn sie keinen Sinn haben. Ich denke zudem, dass das überflüssig ist, der einfache Benutzer braucht das nicht. Am besten verwendet man eine Rahmengestaltung wie bei Tabellen mit der Vorlage:Prettytable. --ChristianErtl 21:40, 12. Okt 2005 (CEST)

Blocksatz

Ist es möglich einen längeren Text im Blocksatz zu formatieren, sodass er sowohl links-, als auch rechtsbündig ist? -- Spookyverse 08:43, 12. Okt 2005 (CEST)

Im Prinzip ist das möglich, wird aber von einigen Admins und anderen Seitenbearbeitern nicht gern gesehen, weil man als angemeldeter Benutzer das in seinen Grundeinstellungen einstellen kann (Rubrik: Verschiedene Einstellungen). Nicht angemeldete Besucher haben diese Möglichkeit natürlich nicht und sehen deshalb die Artikel im Flattersatz. Für Blocksatz kann man folgendes verwenden:
<span style="text-align:justify;">....Text....</span>
Es ist auch diese Variante für längeren Text möglich
<div style="text-align:justify;">....Text....</div>
Der Style-Befehl kann erweitert werden um Schriftart, Schriftgröße und Schriftfarbe in der Art

<span style="font-family:sans-serif; color:blue; font-size:12pt; text-align:justify;">....Text....</span>
Bei den Farben gibt es die Möglichkeit entweder die englischen Standarddefinitionen oder Hexadezimalzahlen zu verwenden, z.B. Blau wäre dann #0000FF. Bei Schriftgrößen wird in der Regel die Punktanzahl (pt) angegeben. Die Reihenfolge innerhalb des Style-Befehls ist beliebig, muss nur durch ein Semikolon von den anderen Befehlen getrennt werden.
---W.W. 11:07, 12. Okt 2005 (CEST)

(von oben ausgelagerte Kommentare: Nein! <span style="text-align:justify;">....Text....</span>
<div style="text-align:justify;">....Text....</div> ist richtig. Bitte unterschreiben! --ChristianErtl 21:42, 12. Okt 2005 (CEST)geht doch unten drunter noch weiter von mir. --W.W. 22:02, 12. Okt 2005 (CEST) da ist es aber auch nicht richtig. Ich nehme es ausnahmsweise mir mal heraus, es zu korrigieren. --ChristianErtl 01:51, 14. Okt 2005 (CEST) hab's noch weiter korrigiert. --W.W. 11:51, 16. Okt 2005 (CEST))

Schriftarten

Hier müßten mal Angaben zu verschiedenen Schriftarten eingestellt werden (das ist zwar für die Hauptarbeit - Artikelnamensraum - nicht erforderlich, wohl aber für den Portal- und Benutzernamensraum). Matt1971 ♫ 12:22, 21. Nov 2005 (CET)

„vorformatierter Text mit einem Leerzeichen am Zeilenanfang“-box

in bezug auf mein projekt in Wikipedia Diskussion:Kandidaten für exzellente Artikel#Layout 800x600 und bevormundende Mechanismen:

vielleicht könnten wir beim umbau gleich diese unselige konstruktion entsorgen, die keinen sauberen umbruch zulässt. sie sollte durch <code>...</code> ersetzt werden. --W!B: nachtrag

- 2006 -

Zeilenumbruch II: Das verpönte <br /> Tag

Auch wenn ihr mich foltert, ich *TUE* noch das <br /> verwenden, weil es einfach keine Alternative gibt! Einen von mir so gewollten Zeilenumbruch OHNE (Zwangs-)Leerzeile bekomme ich schlicht und einfach anders (noch) nicht hin! Natürlich sagen jetzt die Oberschlauen ich hätte ja keine Ahnung usw. Allerdings hab ich schon mindestens 100 Artikel bearbeitet und das Problem ist nach wie vor da. (Bei den nachstehenden ersten 5 Zeilen steht im Originalcode JEDES Wort in seiner eigenen Zeile -- wer's nicht glaubt soll es nachprüfen)

Zeilenumbruch soll hier jedesmal rein.

Da ging jetzt nichts.

Zeilenumbruch

soll

hier

jedesmal

rein.

Aha, ging, hat aber mords Durchschuß zwischen jeder Zeile. Will ich nicht.

Und jetzt mit <br />, tadaa: Zeilenumbruch
soll
hier
jedesmal
rein.

Und geht. Und wunderschön. Solange hier keine Alternativlösung geboten wird - und die Wikipedia ist schon mehrere Jahre alt, und keiner hat sich bisher gekümmert -, werde ich nach wie vor das br verwenden. Und ich werde auch KEINE Extra-Leerzeile jedesmal im Artikel belassen, nur weil ich einen Zeilenumbruch will. In Büchern gibt es schließlich auch Absätze OHNE Leerzeilen. -andy 217.91.47.231 11:52, 1. Feb 2006 (CET)

Es geht nicht darum, was du willst. Absätze mittels <br /> zu erzeugen, ist Bastelei. Es ist außerdem keineswegs eine ganze Zeile. Schau dir mal den XHTML-Quelltext an: Anstatt es so grauenhaft wie Spiegel Online zu machen (<br><br>), wird ein Absatz korrekt mit <p> und </p> umgeben. --ChristianErtl 22:46, 1. Feb 2006 (CET)

Nochmal: Es ist keine Leerzeile, sondern ein Abstand, der von CSS abhängig ist. Solche Paramter sollen nicht in jeden Artikel anders sein und sind allgemein festgelegt. --ChristianErtl 22:54, 1. Feb 2006 (CET)

Allerdings ist es manchmal nicht zu umgehen wie z.B. Bei Absätzen:

• Wenn ich jetzt hier ->

einen Zeilenumbruch brauche. (sieht man, es geht zwar, die nächste Zeile springt aber nicht unter die Zeile darüber)

• Auch wenn ich den Doppelpunkt ->

verwende, ist die Zeile verschoben.

• Es geht nur ->
  mit einem Breakzeichen

1. Noch interessanter wird es ->

mit Nummerierung

1. Oder irre ich mich? (Äh, nö.)
2. Mit Break ->
   geht es besser
3. wie man sieht.

Im normalen Text ist die Leerzeile und der damit verbundene, kleine Abstand bei einem neuen Absatz richtig und wünschenswert. Ein neuer Absatz bedeutet ja einen neuen Gedankengang und der Abstand verschafft einem die dafür notwendige Gedankenpause. Gruß -- Ra'ike Rede mit mir 13:44, 5. Feb 2006 (CET)

Zeilenschaltung <br clear="all">

Beim Artikel Pier wurde oben genanntes Zeichen eingefügt, um nach dem Bild eine Zeilenschaltung zu erzwingen, weil sonst bei größeren Bildschirmauflösungen der nachfolgende Text hinter das Bild geklemmt wird. Allerdings konnte mir auch FritzG nicht erklären, was nun dieser Befehl genau bewirkt. Hätte es ein einfaches, im Absatz darüber genanntes Break nicht auch getan? Gruß -- Ra'ike Rede mit mir 13:44, 5. Feb 2006 (CET)

Stattdessen sollte man <br style="clear:both" /> verwenden. Es sorgt dafür, dass der Text nicht die vorhergehenden Elemente umfließt. --ChristianErtl 20:41, 6. Feb 2006 (CET)

Siehe auch hier hier. --ChristianErtl 20:44, 6. Feb 2006 (CET)

Alles klar, hab' die Seite in meine Merkartikel aufgenommen, danke. Gruß -- Ra'ike Rede mit mir 20:57, 6. Feb 2006 (CET)

Wieso schafft man es eigentlich nicht, den Abstand von links beim Doppelpunkt und dem Sternchen zu eichen? Wo liegt das Problem, wenn der Text mit beiden Befehlen genau untereinandersteht?

• Diese Funktion ist blöde...

diese auch...

...da Diese und diese nicht untereinanderstehen. Kann man da nicht irgendwie was basteln? Diese ganzen Formatierungsmöglichkeiten sind gerade in größeren Artikeln nicht wirklich nutzbar, da sie mehr zermanschen, als Ordnung schaffen... --n·e·r·g·a·l 03:11, 25. Mär 2006 (CET)

blockquote

Ich denke, das default css sollten klarere Angaben über blockquote machen.

Ein blockquote ist doch etwas, das man in einem Wörterbuch sehr häufig trifft. Und in den Richtlinien steht doch klipp und klar, dass ein Blockquote kursiv sein muss. Also gehört das ganz klar in das globale CSS. Sich hier auf die Browserdefaults zu verlassen erscheint einigermaßen irrsinnig. So war es vom w3c nicht gemeint, wirklich nicht. --Richardigel 20:12, 15. Feb 2006 (CET)

Ein bisschen konkreter wünsche ich mir folgende Ergänzung zum bisherigen stylesheet:

blockquote { font-style: italic }

--Richardigel 22:30, 15. Feb 2006 (CET)

Du weißt schon, dass Du das für Dich selbst auch in Benutzer:Richardigel/monobook.css eintragen kannst?--Gunther 22:32, 15. Feb 2006 (CET)

Danke für den Tip! Aber das ändert nichts daran, dass man sich besonders bei blockquote nicht auf die Voreinstellung des Browsers verlassen soll. Iirc steht auch in der Spezifikation ziemlich klar, dass das default zu blockquote einfach sein soll, und man die Details besser per Stylesheet regeln sollte. Das wäre für Wikipedia sicherlich global sinnvoll. --Richardigel 23:52, 15. Feb 2006 (CET)

DIE Html-spezifikation hat dies dazu zu sagen: "Note. We recommend that style sheet implementations provide a mechanism for inserting quotation marks before and after a quotation delimited by BLOCKQUOTE in a manner appropriate to the current language context and the degree of nesting of quotations." In der Spezifikation wird auch erklärt, warum Browser das nicht von sich aus regeln: weil früher blockquote zum Einrücken benutzt wurde. Wenn man das aber nicht tut, soll man sein stylesheet ändern. --Richardigel 09:48, 16. Feb 2006 (CET)

Die Vorlage Zitat würde sich eignen, solange man nichts anderes als einen Absatz einfügen möchte. HTML in Artikeln ist nicht erwünscht. --ChristianErtl 17:56, 16. Feb 2006 (CET)

Mathematische Beweise

Ich weiss nicht, ob ich hier an der richtigen Stelle bin, aber ich finde, dass mathematische Beweise in Artikeln die Übersichtlichkeit sehr reduzieren. Was haltet ihr davon, wenn man diese auf Knopfdruck einblenden kann (so wie die Inhaltsverzeichnisse der Artikel)?

Das kommt sicher auf den Umfang und die Wichtigkeit des Beweises für den Artikel an. Zum Teil wurden längere Beweise, die für das Verständnis des Artikels nicht elementar sind, schon in separate Artikel "ausgelagert" und im ursprünglichen Artikel entsprechend verlinkt.

An sich finde ich deine Idee aber gut. Du kannst das ja mal auf Wikipedia:Verbesserungsvorschläge ansprechen. :-) --RokerHRO 10:38, 19. Jun 2006 (CEST)

Schriftbild

Ist es nicht möglich, die Zeilen standardmässig früher vor dem rechten Bildschirmrand enden zu lassen, dass dort noch eine freie Fläche bemerkbarer Grösse übrigbleibt? Vor allem kurze Artikel sehen obwohl alles richtig gemacht zuweilen schlecht aus, wenn die schrift so "hart" an den Rand rausläuft. Es scheint mir auch ermüdender(abschreckender?, solch breite Texte zu lesen.

Wie eine HTML-Datei von deinem Browser dargestellt wird, ist Sache deines Browsers. :-) Mit CSS kann man da einiges drehen. Vielleicht lädst du dir die Default-CSS herunter und passt sie nach deinen Wünschen an. Ein "Wenn die HTML-Seite kurz ist, nimm dieses Layout, ansonsten jenes" geht aber auch mit CSS nicht. Da müsste man schon JavaScript bemühen. :-( --RokerHRO 10:36, 19. Jun 2006 (CEST)

Nummerierungsproblem

Folgendes Problem:

1. Roberto Abbondanzieri (Boca Juniors) und Timo Hildebrand (VfB Stuttgart)
2. Tim Howard (Manchester United)
3. Fabien Barthez (Manchester United)

In dieser Rangliste müsste Tim Howard nicht als Zweiter sondern als Dritter erscheinen. Daher meine Frage: Kann man mit der Raute in irgendeiner Form die Zahl, mit der die Nummerierung beginnt / fortgesetzt wird, festlegen? Wenn nein, wie sonst? Geisslr 10:08, 19. Jun 2006 (CEST)

Leider nein. Entweder du benutzt HTML-Markup oder schreibst statt automatischer Numerierung die Plätze explizit hin. :-( --RokerHRO 10:34, 19. Jun 2006 (CEST)

Schade. Vielen Dank! Geisslr 10:56, 19. Jun 2006 (CEST)

alphabetische Aufzählungszeichen

Hallo Leutz,

wie mache ich bitte z.B. hier: Charta der Vereinten Nationen#Artikel 13 aus den eingerückten numerischen Aufzählungszeichen (1, 2) meine alphabetischen (a, b)? Vielen Dank Bahnemann 23:36, 24. Aug 2006 (CEST)

Bei 800x600 überlappen sich Tabelle und Navigation

Nachdem ich einen Web-Designer um Rat gefragt habe, kann ich zwar eine Bitte anbringen, aber nicht selbst realisieren (Zitat):

• "Eine wirklich dauerhafte Lösung würde m.E. nur ein Ausklappmenü bieten, das eingeklappt kaum Platz wegnimmt und ausgeklappt bewusst über dem restlichen Seiteninhalt liegt. Das ginge sogar allein mit CSS, JS ist dabei zwar praktisch, aber nicht zwingend notwendig."

Auf ein Beispiel dafür wurde hier in der Diskussion schon verwiesen, aber ich sehe mich als Leser bzw. einfacher Benutzer außerstande, das auf dieser Seite und anderen schon genannten zu realisieren (siehe Archiv-Seite 4 der Wikipedia Diskussion:Kandidaten für exzellente Artikel#Layout 800x600 und bevormundende Mechanismen; oben erwähnt). Von der anderen vorgeschlagenen Variante, den ersten Absatz einfach mit einem <br clear="all" /> abzuschließen, möchte ich lieber absehen; das würde das primäre Problem auch lösen, aber die Seite in meinen Augen doch darunter leiden. J. --89.57.186.216 11:35, 29. Sep 2006 (CEST)

- 2007 -

Aufzählungszeichen

Hallo,

mir ist da gerade aufgefallen, dass bei Aufzählungszeichen in einer Tabelle beim ersten Eintrag das Zeichen nicht angezeigt wird.
Beispiel in der Infobox Schienenfahrzeug: DB_Baureihe_E_10
Nummerierung, Hersteller und Bremse.

Man kann es nur durch einfügen von <br /> oder <p/> erreichen. Doch dadurch wird die Zeile etwas verschoben.

Gibt es noch eine andere Lösung?

Gruß, --Enkel 06:21, 8. Feb. 2007 (CET)

Das Zeichen * muss nach Expansion der Vorlage am Anfang der Zeile im Quelltext stehen. Das ist nicht der Fall und vielleicht eher ein Problem der Vorlage:Infobox Schienenfahrzeug. --80.129.107.19 15:20, 8. Feb. 2007 (CET)

Druckversion

Gibt es tags mit denen man Textpassagen in der Druckversion ausblenden kann? --Liberaler Freimaurer (Diskussion) 01:04, 28. Mär. 2007 (CEST)

Siehe m:Help:Cascading_style_sheets#Non-print. --80.129.77.183 02:25, 28. Mär. 2007 (CEST)

Man dankt! --Liberaler Freimaurer (Diskussion) 04:15, 28. Mär. 2007 (CEST)

Fett und Semikolon

Ich verwende häufig das Semikolon zur fetten Formatierung einer kurzen Zeile (es ist einfacher, ein Semikolon zu machen als drei Apostrophe vor und drei danach, außerdem ist der Übergang zur nächsten Zeile einfacher). Auch der Anleitung Hilfe:Textgestaltung kann man entnehmen, daß man unter Definition (die da nicht näher definiert ist) auch so etwas wie fette Überschrift einer Aufzählung verstehen könnte. Nun habe ich neulich irgendwo gesehen, daß jemand wg. des Semikolons getadelt wurde, da es nicht in allen Browsern/Skins fett erscheint und überhaupt semantisch falsch sei. Wo liegt nun die Wahrheit??? -jkb- ✉ 12:15, 1. Apr. 2007 (CEST)

Das Semikolon erzeugt die Formatierung <dt> wie hier beschrieben. Die Semantik ist also "Formatierung wie eine Definition", das heißt: nicht unbedingt Fettdruck, möglicherweise geänderte Zeilenabstände und andere Unterschiede. Die zweimal drei "Apostrophe" erzeugen die Formatierung <b>...</b> wie hier beschrieben. Die Semantik ist also "Fettdruck". --80.129.123.71 00:09, 14. Apr. 2007 (CEST)

Textgestaltung eines Gedichtes

Hallo, ich hätte eine Frage zu einem Gedicht von Wilhelm Ganzhorn. Wie kann man diesen Text etwas hervorheben? In der Hilfeseite steht, dass man folgende Formatierung <code>Markiert Text als Quelltext</code> nicht in normalen Wikipedia-Artikeln verwenden soll. So richtig gefällt mir diese Formatierung auch nicht. Wie kann man das besser machen? - Danke im voraus. --Joachim Köhler 21:38, 13. Apr. 2007 (CEST)

Formatierung mit

<poem>

Gedicht

</poem>

Hervorhebung von Text bevorzugt kursiv mit ''...'' (zeilenweise). Alternativ mit CSS, zum Beispiel

<poem style="font-style: italic">

Gedicht

</poem>

siehe auch Hilfe:Poem. --80.129.123.71 23:35, 13. Apr. 2007 (CEST)

Vielen Dank für die schnelle Hilfe. Ich habe mal die 2. Version mit kursiv verwendet. --Joachim Köhler 00:45, 14. Apr. 2007 (CEST)

Fußnoten

Wie werden Fußnoten formatiert? Manuell numerierte hochgestellte [Ziffer]? Oder gibt es da eine vernünftige Automatik?

Josha52 19:58, 16. Jul. 2007 (CEST)

Ja, es gibt eine Automatik, die möglichst verwendet werden sollte. Sie wird unter Hilfe:Einzelnachweise beschrieben. --80.129.107.16 20:05, 16. Jul. 2007 (CEST)

Danke. -- Josha52 08:47, 17. Jul. 2007 (CEST)

Links

Wie formatiere ich einen Link, der zu einem Wiki-Artikel führen soll, so daß die URL nicht sichtbar ist?

Wie formatiere ich einen Link, der zu einem Wiki-Absatz führen soll, so daß die URL nicht sichtbar ist?

Wie formatiere ich einen Link, der zu einer URL außerhalb von Wiki führen soll, ohne daß die URL im text ausgeschrieben ist?

Josha52 20:02, 16. Jul. 2007 (CEST)

Das wird in Hilfe:Links beschrieben. --80.129.107.16 20:07, 16. Jul. 2007 (CEST)

Danke. -- Josha52 08:47, 17. Jul. 2007 (CEST)

Preise mit Währungsangaben

Wie wünscht man sich in der Wiki die Darstellung von Preisen und Währung? (Es gibt Seiten, da müssen Beträge genannt werden.) -- Josha52 15:22, 25. Jul. 2007 (CEST)

Siehe Wikipedia:Schreibweise von Zahlen für die Zahlenangabe. Mehr wurde hier meines Wissens noch nicht besprochen, in der Regel wird man die Währungsbezeichnung im Fließtext ausschreiben (Euro, US-Dollar), eventuell auch nach ISO 4217 abkürzen und mit gewöhnlichem Leerzeichen als Abstand hinter die Zahlenangabe setzen. --80.129.88.87 15:51, 25. Jul. 2007 (CEST)

Merci. -- Josha52 16:05, 25. Jul. 2007 (CEST)

Kein "thumb"-Bild rechts überschneiden

Wie ist das möglich? Siehe hier. Wie behebe ich das? einfach <br /><br />... eingeben bis die gewünschte Höhe erreicht ist?
Gruss, Saippuakauppias ⇄ 01:19, 7. Aug. 2007 (CEST)

Ich sehe keine Überschneidung (mit Firefox 2.0.0.6). --80.129.123.218 00:25, 6. Sep. 2007 (CEST)

Die Überschneidung taucht bei einer Auflösung von 1024x768 Pixeln auf (auch bei Firefox 2.0.0.6.) beim Bild "Ansicht des Karl-Moser-Hauses", bei 800x600 ist keine Überschneidung da. Lösung: Bild einen Abschnitt höher setzen (oberhalb der Überschrift "Karl-Moser-Haus") oder in den Absätzen "Nutzung" oder "Kunst" mehr Text dazuschreiben. --W.W. 00:43, 6. Sep. 2007 (CEST)

Dafür gibt es Vorlage:Absatz -- MichaelFrey 09:07, 23. Dez. 2007 (CET)

Sperrschrift

Gibt es auch eine Vorlage für Sperrschrift? --Jarlhelm 03:45, 30. Aug. 2007 (CEST)

Es gibt die Vorlage:Sperrsatz. Sie wird bislang kaum verwendet und sollte möglichst noch verbessert werden. (Derzeit noch vorhandene Mängel sind: Vor und nach dem gesperrten Text werden zwei Leerzeichen eingefügt, Punkt wird entgegen den üblichen typographischen Regeln mitgesperrt.) --80.129.123.218 11:04, 5. Sep. 2007 (CEST)

Überlappende Boxen

Unter Firefox wird diese Seite nicht richtig dargestellt. Die Navigationsbox wird von der mit "Textgestaltung" überschriebenen Tabelle überlappt. Das sollte an sich ausgerechnet bei dieser Seite nicht passieren. Gibt es eine Methode, diesen Fehler zu beheben?--Karl-Friedrich Lenz Disk 09:50, 5. Sep. 2007 (CEST)

Bei mir (Firefox 2.0.0.6) ist alles ok. Erst wenn ich das Fenster so schmal mache, dass das Wort "Absätze" nicht mehr in die erste Zeile passt, wird die minimale Breite der Tabelle "Textgestaltung" erreicht, und die Tabelle beginnt mit der Hilfe-Box zu überlappen. --80.129.123.218 15:31, 5. Sep. 2007 (CEST)

Der Fehler taucht bei mir unter 2.0.0.6 auf, bei einem Fenster, das den ganzen Bildschirm einnimmt (also nicht verkleinert ist). --Karl-Friedrich Lenz Disk 01:58, 6. Sep. 2007 (CEST)

Schriftarten

Wo findet man die verwendbaren Schriftarten (font-variant)? Link gehört mit in die Textgestaltung mit aufgeführt! --WikipediaMaster 14:41, 15. Sep. 2007 (CEST)

Das ist nicht wikipediaspezifisch. Es gibt "normal" und "small-caps", Beschreibung zum Beispiel hier (de.selfhtml.org). --80.129.88.55 17:43, 8. Okt. 2007 (CEST)

Nicht sichtbare Kommentare

Wie fügt man die Kommentare ein die nur im Edit-Modus sichtbar sind? ~~Subfader (Der vorstehende, nicht signierte Beitrag stammt von 89.59.133.250 (Diskussion • Beiträge) 17:23, 8. Okt. 2007)

Das geht in HTML, und auch hier, zum Beispiel mit <!-- nur im Quelltext sichtbarer Text --> (und wird hier vor allem in der Form <!--sic!--> zur Kennzeichnung ungewöhnlicher Schreibweisen, die nicht korrigiert werden sollen, verwendet). --80.129.88.55 17:37, 8. Okt. 2007 (CEST)

Danke! --89.59.198.246 12:33, 15. Okt. 2007 (CEST)

Durchkreuzen

Ich brauche für ein Zitat die Möglichkeit Text kreuzweise durchzustreichen, d.h. stroke reicht nicht aus, sondern es müssen zwei sich in der Mitte kreuzende Linien sein, die das Wort diagonal durchstreichen. Weiß jemand ob das machbar ist? -- Tischbeinahe φιλο 16:29, 11. Nov. 2007 (CET)

nein, ist definitiv nicht möglich--85.178.216.133 19:59, 20. Dez. 2007 (CET)

Definitionslisten

Wenn nicht im HTML-Quelltext für jeden Begriff eine separate Definitionsliste begonnen und nach den Definitionen wieder geschlossen werden soll, sondern eine zusammenhängende Definitionsliste, so dürfen im Wiki-Code keine Absätze/Leerzeilen zwischen letzer Definition und nächstem Begriff eingefügt werden. Hab das mal im Beispiel hier auf der Hilfeseite entsprechend geändert.--Speck-Made 04:56, 13. Dez. 2007 (CET)

Das gilt entsprechend auch für normale Listen und sollte eigentlich generell beachtet werden, da die Darstellung sonst rein Browser-/CSS-abhängig ist. --ChristianErtl 20:53, 4. Feb. 2008 (CET)

verschachtelungen

gibt es eine möglichkeit mehrere absätze oder eine liste in eine Definitionsliste zu schreiben?--85.178.216.133 19:19, 20. Dez. 2007 (CET)

- 2008 -

Spickzettel

Warum ist denn hier http://www.wikimedia.de/files/Spickzettel.pdf nicht mehr verlinkt? --Flominator 19:59, 14. Jan. 2008 (CET)

Keine ahnung, wahrscheinlich weil der Inhalt redundant zum inhalt der Hilfeseite selbst ist. --Cepheiden 09:40, 12. Mai 2010 (CEST)

Aufzählungen mit mehreren Absätzen?

Wie können Aufzählungen/-listungen unter einem Punkt mehr als einen Absatz erhalten, ohne dass entweder ausgerückt oder (mit ':') ein Versatz erzeugt wird? --80.133.56.79 18:34, 20. Aug. 2008 (CEST)

Ich denke, diese fast zwei jahre alte Anfrage ist nicht mehr aktuell oder? --Cepheiden 09:52, 12. Mai 2010 (CEST)

Rechtschreibfehler

Auszug aus dem Text: Für Gedichte und ähnliche Texte:

Ob ich Biblio- was bin?
phile? „Freund von Büchern“ meinen Sie?
Na, und ob ich das bin!
Ha! und wie!

Es sollte wohl eher heißen: bibliophil, ohne e. --Helmut Gründlinger 12:16, 4. Feb. 2008 (CET)

Nein. Es ist ein Zitat aus „Der Bücherfreund“ von Ringelnatz. Das hier verwendete Fremdwort ist (ein) „Bibliophile“, Plural (zwei) „Bibliophilen“, so wie Bakteriophage. --80.129.86.80 19:06, 6. Feb. 2008 (CET)

Bilder mit absoluten Größenangaben

Einwände dagegen, wenn ich reinschreibe, dass absolute Größenangaben bei Bildern nicht erwünscht sind und man doch bitte frameless oder upright benutzen soll? --Revolus Echo der Stille 00:09, 13. Feb. 2008 (CET)

In der Regel nicht erwünscht, es gibt schon Ausnahmen.

Aber was hat das mit der Textgestaltung zu tun?

Ist das nicht eher Hilfe:Bild und Ton?

-- MichaelFrey 18:13, 13. Feb. 2008 (CET)

Dort stehen keine Richtlinien sondern nur Anleitungen. Ich hatte Textgestaltung etwas weitergefasst als Artikelgestaltung aufgefasst. --Revolus Echo der Stille 18:16, 13. Feb. 2008 (CET)

Das hier ist doch auch nur eine Anleitung:

Diese Seite erklärt, wie du in Wiki-Syntax Überschriften, Listen und Absätze erzeugst und Textstellen formatierst.

....

Bitte beachte die Wikipedia-Richtlinien zur Formatierung

Also wenn auf Wikipedia:Formatierung, womit auch der Titel der Seite zu deinem Vorschlag passt.

-- MichaelFrey 18:17, 14. Feb. 2008 (CET)

&#x202f;

Bei mir funktioniert &#x202f; weder im Firefox noch IE richtig. Beim IE wird es wohl eher an der Schrift liegen, beim Firefox bin ich mir nicht sicher. --ChristianErtl 22:24, 23. Feb. 2008 (CET)

Auch die Unicode-Vorlage half bei mir nichts (im IE). Es könnte sein, dass ich mich bzgl. des Firefox irre und es für nicht dargestellt halte, obwohl es richtig dargestellt ist. Bevor man das aber wiedereinführt, sollte man bedenken, dass das Beispiel für nbsp ist. (Also evtl. die Einheiten weg.) --ChristianErtl 22:38, 23. Feb. 2008 (CET)

Mea culpa. Ich hatte es nicht groß getestet. In der Kombination von Firefox3beta3 bzw

Opera 9.23 / Windows XP wurde es korrekt angezeigt --Fusselwurm 09:21, 25. Feb. 2008 (CET)

Ich hatte auch schon die Idee, die Schreibweisen manchner Seiten, wo der korrekte Titel mittels <sub>-Tag erzeugt wurde, dies über Unicode zu lösen und so das neue MediaWiki-Feature für korrekten Titel zu verwenden, aber ich denke, die Anzeige von Unicode geht leider noch in genug Fällen schief. :( --ChristianErtl 16:15, 3. Mär. 2008 (CET)

Schriftstil der Überschrift Ebene 6

Hallo!

Die Schriftgröße der Überschriftsebene 6 ist ein wenig zu klein und passt nicht ins Gesamtkonzept, vgl. Artikel Spannungsquelle. Ich empfehle diese Ebene wie folgt anzupassen:

• Schriftart von Ebene 5
• Schriftgröße von Ebene 5
• nicht fett dafür kursiv!

Danke.

Grüße
--JoBa2282 ^{Red mit mir} 22:37, 3. Mär. 2008 (CET)

Ich habe es mal angesehen, und eine Überschrift in der Größe 80% von Normal ist auch mMn ziemlich unütz. Festgelegt wird das z.Zt. in „http://de.wikipedia.org/skins-1.5/monobook/main.css?121“. Vielleicht würde es mehr als hier bringen, das Problem unter WP:FZW und/oder WP:AAF zu schildern. Als vorläufigen Notlösung müsste beispielsweise folgendes den gewünschten Effekt erzielen:

• aus z.B.
  ====== Audiotechnik ======
• wird
  ====== <span style="font-size:125%; font-weight:normal;">''Audiotechnik''</span> ======

was aber den Nachteil hätte, dass es bei einer Umstellung in „http://de.wikipedia.org/skins-1.5/monobook/main.css?121“ voraussichtlich plötzlich viel zu groß aussähe. Daher wäre folgendes sicherer (wenn auch noch weniger „Wikipediakonform“):

• ====== <span style="font:9.75pt/14.25pt Sans-serif; font-weight:normal;"><i>Audiotechnik</i></span> ======

--ParaDox 17:31, 13. Mär. 2008 (CET)

Hallo ParaDox!
Danke für die Antwort. Ich habe jetzt mal das Problem bei WP:FZW undWP:AAF gestellt. Mal schauen, was da raus kommt.
Gruß
--JoBa2282 ^{Red mit mir} 23:25, 14. Mär. 2008 (CET)

Die WP:FZW-Diskussion ist letzte Nacht archiviert worden. Ob, und wenn, wann sie in einer Änderung münden wird, kann ich auch nicht sagen …   Scheint allg. eher als irrelevant betrachtet zu werden. Gruß, --ParaDox 08:55, 18. Mär. 2008 (CET)

Hallo ParaDox! Ich habe eine neue Diskussionsrunde bei WP:FZW eröffnet (guckst du hier). Gruß --JoBa2282 ^{Red mit mir} 23:51, 23. Mär. 2008 (CET)

Das Thema ist noch immer nicht geklärt. Gruß --JoBa2282 ^{Red mit mir} 18:18, 12. Apr. 2008 (CEST)

Stimmt. -- Emdee 17:44, 2. Feb. 2009 (CET)

Schade. Vorschlag: Anfrage auf WP:AAF noch einmal stellen in einem Monat. WP:FZW ist ungeeignet, denn „die Seite Fragen zur Wikipedia dient für alle Probleme, deren Lösung keiner besonderen Rechte bedarf.“ Gruß, -- Emdee 14:10, 4. Feb. 2009 (CET)

Gültige HTML/CSS-Syntax im DIV?

Die momentan letzte Reihe im Tabellenabschnitt „Hilfe:Textgestaltung#nicht in normalen Wikipedia-Artikeln“ enthält folg. Code:

• <div style="text-align:justify;" "float:left">Links flutender Blocksatz</div>

Der Sinn bzw. die Funktion von „ "float:left"“ ist mit schleierhaft, und sieht für mich wie ungültige Syntax aus: Kann mir das jemand bitte erklären und/oder zu einer Erklärung in http://de.selfhtml.org verlinken? --ParaDox 23:55, 17. Mär. 2008 (CET)

http://de.selfhtml.org/css/eigenschaften/positionierung.htm#float --80.129.95.48 23:59, 17. Mär. 2008 (CET)

Schon klar/bekannt, danke. Aber ich hätte gern ein konkretes Beispiel mit obiger Syntax, wo ein Unterschied mit und ohne „ "float:left"“ zu sehen ist, denn ich vermute, dass das „ "float:left"“ so geschrieben bestenfalls gar nichts oder unter Umständen schlimmeres bewirkt. --ParaDox 00:05, 00:07, 18. Mär. 2008 (CET)

Ich habe den Ursprung des Rätsels gefunden. Vielleicht kommt von CFT (Permanentlink) eine Erklärung. --ParaDox 00:22, 18. Mär. 2008 (CET)

Float:Left soll Grafiken und Tabelle links umfluten lassen. Man kann sie auch rechts umfluten lassen. Ich habe den Befehl selbst irgend wo her, weiß aber nicht mehr von welcher Seite. float:left ist wahrscheinlich default und erzeugt deshalb kein anderes Bild als wenn es weg gelassen wird. Ich habe es aber trotzdem drin gelassen, falls andere Formatierungsbefehle für eine Tabelle oder etwas anderes (zu Umflutendes) das default imn Einzelfall überschreiben. Wenn Ihr Probleme mit dem Argument habt, könnt ihr es selbst raus nehmen. --Carl Projekt neue geeignete Benutzer finden 13:43, 19. Mär. 2008 (CET)

Hallo Carl, vielen Dank für deine Antwort :-)  Theoretisch war mir das vorher auch klar, aber es bleibt die Frage nach mindestens einem konkreten und kompletten Beispiel, welches die Funktion in Kombination mit einer Grafik oder Tabelle demonstriert. Fällt dir eins ein? Wenn ja, dann bitte in der Hilfeseite entsprechend nachtragen, mMn dann am besten als zusätzliches Beispiel hinter dem vorhanden, welches ich jetzt um das „Floaten“ erleichtere, und somit auf Blocksatz reduziere. Schließlich sollen auf Anfänger+innen mit den Beispielen auf der Hilfeseite möglichst auch etwas anfangen können, und das geht mMn ohne komplettes Beispiel von sehr schwierig bis gar nicht. --ParaDox 16:07, 19. Mär. 2008 (CET)

Schokoladen-Rührkuchen mit individuell gestalteter Glasur

Ich sehe gerade dass es auch ohne den float-Befehl geht. Ist vermutlich ein älterer und ersetzter Befehl. Lösch ihn einfach raus. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah.

Schokoladen-Rührkuchen mit individuell gestalteter Glasur

Hier nochmal mit right, geht aber auch so. Blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah.

← Vorstehender Text bzw. Beitrag stammt von CFT 18:12, 19. Mär. 2008 (CET) Nachtrag 2008-03-19 23:20 ←

Okay, danke für die Beispiele Carl. Ich habe es mittels Vorschau soeben überprüft: Die Wirkung von <div style="text-align:justify;" "float:..."> und <div style="text-align:justify;"> ist identisch, und so wie ich es erwartet hatte. Dagegen „zerstört“ <div style="text-align:justify; float:..."> sogar den Blocksatz (mit Firefox zumindest). Anyway, die Hilfeseite könnte ggf. immer noch ein gutes <div style="float:...">-Beispiel brauchen. BTW, falls du sie noch nicht kennst, vielleicht eine nützliche Webseite, welche ich erst neulich entdeckte. Gruß, --ParaDox 23:20, 23:23, 19. Mär. 2008 (CET)

Ja, da kommen auch die browserspezifischen Interpretationen dazu. Wie gesagt habe ich das nicht so im Überblick. Mach wie du denkst, ich bin mit allem einverstanden. :) --Carl Projekt neue geeignete Benutzer finden 17:07, 20. Mär. 2008 (CET)

SOURCE

Hallo,

mir ist aufgefallen, dass es kein Formatierungsbeispiel fuer das <source>-Tag gibt.

Grüße,

Richard
← Vorstehender Text bzw. Beitrag stammt von 62.50.42.18 15:06, 18. Apr. 2008 (CEST) Nachtrag 2008-04-18 15:13 ←

Dafür gibt's 'ne eigene Seite: Hilfe:Source. Gruß, --ParaDox 15:13, 18. Apr. 2008 (CEST)

Unsichtbarer Kommentar

Müsste <!-- unsichtbarer Kommentar--> nicht <!-- unsichtbarer Kommentar --> (mit 2. Leerzeichen) heißen? --Atlan da Gonozal _¿^?_¡^! 18:42, 30. Apr. 2008 (CEST)

Schöner wäre es, aber notwendig ist das nicht, denn auch <!--unsichtbarer-Kommentar--> ganz ohne Leerzeichen funktioniert einwandfrei. --ParaDox 18:53, 18:53, 30. Apr. 2008 (CEST)

Probleme mit vorformatiertem Text

Gibt es eine Möglichkeit, dass Überlappen bzw. Nicht-Zeilenumbrechen zu verhindern? Hier habe ich eine extrem lange Zeile (mit aktuellem Firefox), die über den WP-Rand hinausragt. Und das, obwohl ja auch Leerzeichen im Text vorkommen. Ich denke, in diesem konkreten Beispiel war das Leerzeichen unabsichtlich, aber ich habe schon viele solcher tollen Boxen entdeckt. --Sentropie 14:12, 5. Jun. 2008 (CEST)

Ergänzung: Das Problem besteht auch bei Code, wie man auf dieser Diskussionsseite sehen kann: Link. --Sentropie 14:16, 5. Jun. 2008 (CEST)

Zum ersten: Das ist doch gerade der Sinn der Sache ("vorformatierter Text"), dass die Zeilenumbrüche vorgegeben sind und nicht durch die Fenstergröße des Browsers bestimmt werden. Wer einen Abstand zum linken Rand möchte, muss einen Doppelpunkt statt eines Leerzeichens verwenden. Zum zweiten: Das habe ich nicht verstanden. Wo ist in diesem Abschnitt das Problem? Soweit ich sehe, geht es da nur um den seltenen Fall einer Überschrift 6. Ordnung. --80.129.95.195 14:57, 5. Jun. 2008 (CEST)

Zu 1: Na gut, aber es ist einfach doof, wenn Leute dadurch eine Zeile erzeugen, die die Länge mehrerer Fensterbreiten hat. Meistens nur, um ihren Text besonders hervorzuheben. Zumindest habe ich noch kein sinnvolles Beispiel dafür entdeckt, dass etwas überstehen muss.

Zu 2: Als über CSS gesprochen wird, gibt es mehrere Code-Formatierungen (mit <span... beinnend). Der letzte dieser Art (von ParaDox) ist ein überlanges Gebilde, was dadurch einen horizontalen Scrollbalken überzeugt und unschön über den Rand von WP hinausgeht. --Sentropie 15:57, 5. Jun. 2008 (CEST)

Zu 1: Meiner Ansicht nach könnte man das in den Abschnitt "Formatierungen, die nicht in normalen Wikipedia-Artikeln verwendet werden sollten" verschieben. Zu 2: OK, aber das ist dort sinnvoll, da bei Programmcode ein Leerzeichen oft eine ganz andere Bedeutung als ein Zeilenumbruch hat. Bei verhindertem Zeilenumbruch muss derjenige, der das verwendet, darauf achten, dass keine überlangen Zeilen entstehen. --80.129.95.195 16:35, 5. Jun. 2008 (CEST)

unterstrichene Buchstaben in einem Namen

Da ich diverse Ortsnamen mit unterstrichenen Buchstaben schreibe, diese Form aber nicht gebraucht werden sollte, wüsste ich gern eine akzeptierte Alternative zu < u > und dem dazugehörenden Schließungstag, wie bei unterstrichen. -- Hans-Jürgen Hübner 19:59, 17. Jun. 2008 (CEST)

Im Artikelraum sind unterstrichene Worte allerdings nicht gern gesehen. – Wladyslaw [Disk.] 10:18, 30. Jul. 2008 (CEST)

Es gibt aber Begriffe, die so geschrieben werden, wie z. B. im Artikel über die Kwakwaka'wakw: "Das Kwak'wala gehört zu den Wakash-Sprachen. Dabei gibt es heute fünf Dialekte: das am weitesten verbreitete ist Kwak̕wala, das beispielsweise von Kwagu'l (Kwagu'ł), Mamaliliḵala,'Namgis, Lawitsis (Ławitsis) und A'wa'etłala (Da'naxda'xw), aber auch von den Ḵwiḵwasut̓inuxw gesprochen wird." -- Hans-Jürgen Hübner 19:54, 5. Sep. 2008 (CEST)

Am besten wäre es, die entsprechenden Unicode-Zeichen zu verwenden. Wenn das ein technisches Problem ist (zum Beispiel kaum ein Browser/Betriebssystem diese Zeichen anzeigt), würde ich die Verwendung von <u> … </u> als Notbehelf für akzeptabel halten. --80.129.67.65 09:56, 10. Sep. 2008 (CEST)

Zum Beispiel

• mit dem Modifikator &#x0331: A̱'wa̱'etła̱la (Da̱'nax̱da'x̱w)
• mit Direkteingabe: A̱'wa̱'etła̱la (Da̱'nax̱da'x̱w)

Ich bitte um Kommentare auch anderer Benutzer, ob das bei ihnen korrekt dargestellt wird (auch im Bearbeitungsfenster). Bei mir ist es ok (Firefox 3.0.1, Ubuntu). --80.129.67.65 10:48, 10. Sep. 2008 (CEST)

Mit Firefox 3.0.1 und IE 7 unter Windows Vista funktioniert es ebenfalls, wobei im Bearbeitungsfenster die Unterstreichung nach dem Buchstaben angezeigt wird (aber nur beides zugleich mit der Maus markiert werden kann). --80.129.77.229 19:50, 11. Sep. 2008 (CEST)

Erzwingen eines Abstandes

Hallo,

Ich suche einen Befehl, der einen Abstand erzwingt. Gibt es sowas? Bräuchte den Befehl für eine Tabelle. Gruß – Wladyslaw [Disk.] 10:17, 30. Jul. 2008 (CEST)

Naja, unter einem erzwungenen Abstand in einer Tabelle kann ich mir gleich einige vorstellen. Welchen denn genau? Im Text zwischen den Zeichen oder zwischen den Zellen oder außerhalb ... --92.228.2.7 04:02, 6. Aug. 2008 (CEST)

Textkorrektur: bitte "englisches Komma" raus :)

Ein Text der von Typographie "in depth" handelt, sollte orthographisch natürlich astrein sein. Ein Komma stört mich: An diesem Beispiel zeigen die großen, unvorhersehbaren und wahrscheinlich zum Teil ungleichmäßigen Abstände zwischen den Wörtern, den entscheidenden Nachteil von Blocksatz in Webseiten. (oh yes, the distances between the words, they show... :)) Nach "Wörtern" darf kein Komma stehen. -andy 92.226.209.215 16:37, 5. Sep. 2008 (CEST)

Richtig. Korrigiert. Danke für den Hinweis. --YMS 16:41, 5. Sep. 2008 (CEST)

Kleiner Text, abkürzen mit <sm> und als Symbolleiste

Ich hätte zwei kleine Fragen zum kleinen Text:

1. könnte man den, für die Kleinschreibung notwendigen, Befehl <small> ändern, indem man ihn z.B. mit <sm>, <k>, <kl> oder Ähmlichem abkürzen könnte ?
2. könnte man für die Kleinschreibung auch eine Symbolleiste am Schreibfenster einbauen ?

Würde dies möglich sein, dann würde der Aufwand für eine weitere Textgestaltungsart erheblich erleichtert sein. --Adilhan ^Disko 04:59, 7. Sep. 2008 (CEST)

Schon geklärt, habe die Antwort selber gefunden, hier: Wikipedia:Helferlein/Extra-Editbuttons . Aber zu 1 (<small> abkürzen) kann man trotzdem Gedanken machen. -- Adilhan ^Disko 02:51, 10. Sep. 2008 (CEST)

Das dürfte aus mehreren Gründen nicht auf Zustimmung treffen: Die HTML-Formatierungen sind, wie auf dieser Projektseite Hilfe:Textgestaltung angegeben, in Artikeln überhaupt nicht erwünscht. Wie in Hilfe:Vorlagen#Einsatzmöglichkeiten erläutert, sollen Vorlagen nicht als reine Abkürzung verwendet werden, da sie vor allem den Quelltext unleserlich machen. <small> ist ein etablierter HTML-Befehl (siehe http://de.selfhtml.org/html/text/physisch.htm#elemente), der von den Browsern direkt interpretiert wird und auch für diejenigen, die das englische Wort kennen, unmittelbar verständlich ist. (Bei nicht eindeutigen Namen oder Abkürzungen spricht man in der IT auch von „namespace pollution“.) --80.129.67.65 08:56, 10. Sep. 2008 (CEST)

Es geht ja auch nicht darum in Artikel klein zu schreiben, sondern in Diskussionen, Benutzerseiten oder sonst andere Seiten außer Artikel. Bei einigen anderen Befehlen hat man ja auch abgekürzt, so z.B statt <strike> (duchstreichen) kann man auch <s> oder statt <underline> (unterstreichen) auch <u> eingeben. Nach Möglichkeit könnte man auch so ähnlich die Kleinschreibung formatieren, dachte ich jedenfalls. -- Adilhan ^Disko 15:42, 10. Sep. 2008 (CEST)

Das sind keine Abkürzungen, jedenfalls keine von der Wikisoftware bereitgestellte, sondern von allen Browsern direkt interpretierte HTML-Befehle (die übrigens als „deprecated“ gekennzeichnet sind), siehe den angegebenen Link http://de.selfhtml.org/html/text/physisch.htm#elemente (Den Befehl <underline> gibt es in HTML und Wiki nicht.) --80.129.67.65 17:27, 10. Sep. 2008 (CEST)

Befehle: hast du Recht, Probe durchgeführt, Ergebnis wie folgt;
<underline>wie gesehen, unterstreichen mit diesem Befehl nicht möglich</underline>, sondern unterstreichen nur mit -u-, aber durchstreichen sowohl mit -strike-, als auch duchstreichen mit -s- möglich.
Wikisoftware: aha, also daran etwas zu ändern liegt es nicht in der Hand der Wikisoftware. Ich dachte bis jetzt diese Befehle könnte man von der Wikisoftware aus programmieren und beliebig ändern. Danke für die Informationen. -- Adilhan ^Disko 22:16, 10. Sep. 2008 (CEST)

Hilfe bei Erstellung eines neuen Lemma

Zur Zeit wird auf meiner Spielwiese Entkarbonisierung erstellt. Bei der Formatierung treten folgende Fehler auf:

- das verborgene Inhaltsverzeichnis beginnt mit dem Artikelanfang (obwohl dafür die 1. Bearbeitungsebene und für den Rest die 2.Ebene eingegeben wurde

- die 3. Reaktionsgleichung kommt nur in Rot mit der Fehlermeldung Parser-Fehler; finde aber keinen Fehler

- in der Überschrift der Spielwiese erscheint immer noch der Zusatz Gleichstrom-Austauscher obwohl diese einschl. Diskussion verschoben wurde. Selbst wenn für die Gesamtseite Diskussion bearbeiten angewählt wird, ist der Titel nicht zu ändern.

Kann jemand Hilfestellung zu diesen 3 Problemen geben? Danke vorab.--Urdenbacher 15:22, 13. Sep. 2008 (CEST)

zu Punkt 1: Die erste Bearbeitungsebene wird überhaupt nicht verwendet. Einfach löschen, die Überschrift wird automatisch an der Stelle, wo jetzt "Benutzer:Urdenbacher/Spielwiese" steht, erscheinen, sobald der fertige Artikel an die richtige Stelle verschoben wurde. Man kann auch {{DISPLAYTITLE:Entkarbonisierung}} verwenden, das ist aber für Titel vorgesehen, die anders nicht korrekt angezeigt werden können.

zu Punkt 2: Innerhalb von TeX-Formeln muss der normale Bindestrich "-" verwendet werden, das im übrigen Text korrekte Minus "−" und den Gedanken- oder Streckenstrich "–" versteht TeX nicht.

zu Punkt 3: Das liegt daran, dass die Diskussionsseite mit einem redirect-Befehl auf die Diskussionsseite von Gleichstromaustauscher weitergeleitet wird. Das kann zum Beispiel bei einer Verschiebung der Spielwiese auf den Artikel Gleichstromaustauscher automatisch passiert sein. Um einen redirect zu löschen, muss man auf der Seite, zu der man weitergeleitet wurde, oben auf den Link hinter „Weitergeleitet von“ klicken, dann kann man die Seite, die den redirect enthält, bearbeiten und zum Beispiel einfach leeren. Indem man {{SLA}} und eine Begründung hineinschreibt, kann man einen Administrator bitten, die Seite ganz zu löschen. --80.129.102.182 16:24, 13. Sep. 2008 (CEST)

vorab Danke für die vorstehenden Angaben;

habe leider Betreff meine Spielwiese/gleicher Entwurf ein neues Problem, und zwar: in der 3.Gleichung in TeX wird der zentrierte Punkt nicht als Punkt sondern wie eingegeben als ...\cdot... angezeigt. Was ist falsch; habe die Sonderzeichen sowohl als Sonderzeichen wie als Textzeichen versucht. --Urdenbacher 12:25, 16. Sep. 2008 (CEST)

Da war ein Leerzeichen zwischen "\" und "cdot". Ich habe es entfernt. --80.129.82.201 13:50, 16. Sep. 2008 (CEST)

Danke, kleine Ursache aber große Wirkung (hatte zwar viele Varianten mit und ohne Leerzeichen versucht, aber offensichtlich nicht die richtige; --Urdenbacher 16:51, 16. Sep. 2008 (CEST)

wieder Hilfe benötigt:

grundsätzliches Problem: Bei der Erstellung eines neuen Lemma werden unter Versionen/Autoren alle einzelnen Bearbeitungen angezeigt. Eine Löschung ist nicht möglich. Als Beispiel sei das Lemma Gleichstromaustauscher angeführt. Unter Versionen/Autoren sind leider bei der seinerzeitigen Verschiebung alle Bearbeitungsschritte übernommen worden, die unter Spielwiese getätigt wurden. Sinnvoll wäre aber höchstens die Anzeige der 1. und der letzten Bearbeitung des Lemma vor der Verschiebung.

akutes derzeitiges Problem: Demnächst soll das neue Lemma Entkarbonisierung (derzeit unter: Benutzer:Urdenbacher/Spielwiese) verschoben werden. Unter Versionen/Autoren sind alle Bearbeitungsschritte aufgelistet, die nach der Verschiebung völlig überflüssig wären. Wie können diese vorher gelöscht oder in ein Archiv verschoben werden? Gelten dafür auch die obigen Angaben vom 13.09.08 bei der Verschiebung?

Danke vorab, --Urdenbacher 14:47, 1. Okt. 2008 (CEST)

Solche Fragen sind unter WP:FZW vermutlich besser aufgehoben – thematisch passender und weil dort mehr kompetente Wikileute mitlesen. Ich würde sagen: Falls, abgesehen von trivialen Bearbeitungen, der gesamte Artikel von einer Person erstellt wurde, ist es (urheberrechtlich) legitim und wegen der besseren Übersichtlichkeit der Versionsgeschichte sinnvoll, wenn diese Person ihn nicht verschiebt, sondern mit Hilfe von Copy & Paste im Artikelraum neu einstellt. --80.129.88.145 15:25, 1. Okt. 2008 (CEST)

<br />

„Text <br /> neue Zeile“ Mit welcher Begründung? Ein einfaches Enter funktioniert nicht, da damit der Wikitext noch immer zusammengezogen wird. Zwei Enter hinterlassen eine hässliche Lücke zwischen dem Text – bei längeren Texten sind Ablässe aber entlastend. Grüße, —DerHexer (Disk., Bew.) 20:59, 25. Sep. 2008 (CEST)

GENAUSOISSES. Jeder der mal layoutbezogen zu schreiben lernte nutzt Zeilenumbrüche.
Und: Insbesondere bei Nutzung von Aufzählungszeichen oder ~nummern ergibt die Einrückung per Doppelpunkt ein geradezu p.o.t.t.h.ä.s.s.l.i.c.h.e.s Layout, das sich durch den aus unerfindlichen Gründen als unerwünscht deklarierten "br/" tag leicht vermeiden lässt.
Bitte aus der Negativliste rausnehmen. Wolfgang 08:29, 20. Dez. 2008 (CET)

Darstellung mit opera

hallo, ich habe jetzt mal zur Abwechslung die Wikipedia mit opera benutzt und festgestellt, dass die Kursiv-Formatierungen überhaupt nicht angezeigt werden. das ist manchmal sehr ungünstig, siehe z.B. Kommunikation - Verweis auf 1 Werk von Paul Watzlawick: "Menschliche Kommunikation. Formen, Störungen, Paradoxien" - da die Kursiv-Formatierung fehlt und es auch keine Anführungszeichen gibt, sieht das bei mir so aus, als begänne mit dem Wort Formen ein neuer Satz. sehr irritierend.

ich wollte dann die fehlenden Zeichen für Kursivsetzung einfügen und musste mit Überraschung feststellen, dass die im Quelltext enthalten waren. hat dazu jemand hier eine Idee, wie man auch opera überzeugen kann, dass das dargestellt wird oder was man sonst machen kann? oder gibt es dazu irgendwo sonst hier schon einen Thread, den ich nicht finde? viele Grüße, --Geitost 10:52, 26. Sep. 2008 (CEST)

Das wird bei mir von Opera 9.27 unter Ubuntu (ohne irgendwelche Sondereinstellungen) korrekt angezeigt. Vielleicht muss einfach eine geeignete Schrift ausgewählt sein. --80.129.84.188 14:04, 26. Sep. 2008 (CEST)

Wird bei mir von Opera 9.52 unter Windows-2000 fehlerfrei angezeigt. --ParaDoxa 14:43, 26. Sep. 2008 (CEST)

Abstand zwischen Text und Formel

hallo, ich möchte nach einer Formel erklärenden Text schreiben, z. B.

$9\;{\bmod {\;}}6=3$ (dabei bezeichnet $\mod {}$ den Divisionsrest; siehe Modulo).

Es wäre aber schöner, wenn zwischen der Formel und dem Text etwas Abstand wäre. Wie geht das?

Man könnte den Text in \text{...} in die Formel hineinnehmen, aber dann wird der ganze text so groß dargestellt wie das „mod“, und es sieht nicht so schön aus. Außerdem soll man innerhalb von Formeln keine Links verwenden, soweit ich weiß. --Megatherium 15:45, 6. Okt. 2008 (CEST)

Hallo Megatherium, hilft dir dies weiter?

$9\;{\bmod {\;}}6=3$ (dabei bezeichnet $\mod {}$ den Divisionsrest; siehe Modulo).

--Wiegels „…“ 15:51, 6. Okt. 2008 (CEST)

Ja, danke :) --Megatherium 16:27, 6. Okt. 2008 (CEST)

Es geht auch mit ganz primitiver '&nbsp;'-Eingabe, nötigenfalls mehrfach:

$9\;{\bmod {\;}}6=3$       (dabei bezeichnet $\mod {}$ den Divisionsrest; siehe Modulo).

(ist unelegant, aber einfach & wirkungsvoll) -- sarang♥사랑 10:12, 15. Okt. 2008 (CEST)

Überschriften

Hallo, hab mal 'ne Frage: Es gibt User, die die folgenden Leerzeilen bei Überschriften entfernen („unnötig“). Kann ich verstehen, allerdings finde ich, dass diese Leerzeilen zur besseren Übersicht im Quelltext beitragen und das entfernen unnötige Edits sind. Was ist denn jetzt sinnvoller oder wie ist es angedacht? --Dbawwsnrw Lälles! 11:53, 20. Okt. 2008 (CEST)

Dass dies unnötige Edits sind, dürfte Konsens sein. Keinen Konsens gibt es in der Diskussion über Leerzeile oder nicht: siehe Wikipedia_Diskussion:Wie_gute_Artikel_aussehen#Leerzeile nach Überschrift. --80.129.87.115 12:14, 20. Okt. 2008 (CEST)

Danke! --Dbawwsnrw Lälles! 13:28, 20. Okt. 2008 (CEST)

Ich finde so eindeutig ist die Frage, ob jetzt ein Leerzeichen bei Überschriften vorhanden sein muss/soll oder nicht, ist in dieser Diskussion nicht geklärt... Gruß --JoBa2282 ^{Red mit mir} 14:26, 20. Okt. 2008 (CEST)

Ich finde, genau das habe ich geschrieben. --80.129.87.115 15:08, 20. Okt. 2008 (CEST)

Ups ... zu schnell gelesen. Konsens, Nonsens, keinen Konsens ... und dann das "Danke" von Dbawwsnrw. Das habe ich so aufgefasst, als hätte es eine eindeutige Lösung gegeben... Gruß --JoBa2282 ^{Red mit mir} 15:27, 20. Okt. 2008 (CEST)

Ich wollte nur eine Info und die hab ich bekommen! Da kann ich alles nachlesen... Gruß --Dbawwsnrw Lälles! 16:40, 20. Okt. 2008 (CEST)

Eine Linie

In der Darstellung wird bei mir keine Linie angezeigt. Der Versuch dieses zu verbessern ist leider auch fehlgeschlagen, da es ganz merkwürdige Anzeigen hervorbrachte. --Of 11:20, 28. Okt. 2008 (CET)

Das kann ich nicht nachvollziehen. Ich sehe dort eine Linie, die durch 4 Bindestriche ---- erzeugt wurde. Im Beispiel steht über der Linie "Eine" und unter der Linie "Linie". Welchen Browser verwendest du? Auf welcher Seite willst du eine Linie einbauen? Gruß, -- McFred 18:01, 29. Okt. 2008 (CET)

- 2009 -

fett und kursiv

Sollte das nicht besser unter „Formatierungen, die nicht in normalen Wikipedia-Artikeln verwendet werden sollten“ eingeordnet werden statt unter „Textgestaltung“? -- Ukko 12:28, 27. Jan. 2009 (CET)

Wenn man das nur dort eintragen würde, würde das bedeuten, dass fett und kursiv generell unerwünscht sind. Seit deinem Beitrag hat die Hilfeseite sich aber etwas geändert. Ich denke die vorhandenen Hinweise zum eingeschränkten Gebrauch dieser Formatierungen sind in Ordnung und ausreichend. Grüße --Cepheiden 09:44, 12. Mai 2010 (CEST)

Horizontale Linie (HR / horizontal rule)

Warum steht die eigentlich nicht unter WP:TG#nicht? Werde die dorthin verschieben, oder gibt es einen Grund, warum die in Artikeln verwendet werden könnte? Beispiel (verkürzt auf ⅓ Breite):

---

Gruß, -- E 15:09, 27. Aug. 2009 (CEST)

Warum sollten HRs verwendet werden? Meiner Meinung ist diese Formatierung störend. Ansonsten sollte so oder so die entsprechende Wiki-Syntax für dieses Element genutzt werden (----). --Cepheiden 09:46, 12. Mai 2010 (CEST)

Sind schon in WP:TG#nicht. (Eben, hr hat im ANR nichts zu suchen) -- E (D) 17:01, 13. Mai 2010 (CEST)

Link mit Sonderzeichen

Hallo wer kann helfen? Ich habe eine Referenz in der im Link die Zeichen "[" und "]" vorkommen. Der Link sieht so aus: "http://www.grenzlandnachrichten.de/index.php?id=43&tx_ttnews[tt_news]=4032"

Wie kann ich den Link im Artikel als Referenz verwenden, damit aus der Referenz heraus der Referenz Artikel aufgerufen wird?Neozoon 02:42, 28. Feb. 2009 (CET)

Habe Antwort im IRC bekommen: "Sind im Link selber eckige Klammern vorhanden, kann es notwendig sein, sie durch „%5B“ (für „[“) und „%5D“ (für „]“) zu ersetzen. " Neozoon 02:50, 28. Feb. 2009 (CET)

<br />

„Ein Zeilenumbruch ohne neuen Absatzbeginn wird durch die Eingabe von <br /> realisiert. Zur (sparsamen) Verwendung siehe oben.“

Hier stimmt "was Du schreibst" und "wie es dargestellt wird" nicht überein oder?

Müsste nicht um das <br /> in der Mitte ein nowiki gesetzt werden? -- schubi 16:31, 23. Mär. 2009 (CET)

Ja, man müsste auf der linken Seite im Quelltext <nowiki><nowiki><br /></nowiki></nowiki> schreiben, um als Ausgabe <nowiki><br /></nowiki> zu bekommen, was auf der rechten Seite im Quelltext steht und <br /> ergibt. --80.129.105.51 16:44, 23. Mär. 2009 (CET)

Redirect auf Kapitel in Artikel

Auch auf die Gefahr hin, dass meine Anfrage hier offtopic ist, stelle ich sie trotzdem, weil ich keine passendere Seite gefunden habe. Ich habe versucht, einen Redirect von „7 Wochen mit“ auf die Seite „7 Wochen Ohne“ zu setzen. Ich habe folgendes eingegeben: #REDIRECT 7 Wochen Ohne#Wirkungsgeschichte|7 Wochen Ohne (plus die rechteckigen Klammern für einen internen Link) – dann müsste eigentlich nur zu sehen sein: 7 Wochen Ohne mit dem entsprechenden Link auf den Artikel. Es erscheint jedoch Folgendes: 7 Wochen Ohne#Wirkungsgeschichte. Wie kann man das hinkriegen, dass das Unterkapitel im Redirect nicht erscheint. -- Maseltov 21:38, 24. Mär. 2009 (CET)

Hallo Maseltov, es scheint allgemein so zu sein, dass bei Weiterleitungen immer das Linkziel auch als Beschriftung angezeigt wird. Beispielsweise wäre bei #REDIRECT [[Eins|Zwei]] der Text Eins zu lesen. Fragen zu diesem Thema kannst du vielleicht besser bei Hilfe Diskussion:Weiterleitung oder Wikipedia:Fragen zur Wikipedia stellen. --Wiegels „…“ 23:26, 24. Mär. 2009 (CET)

Hallo Maseltov, der zweite Teil hinter dem senkrechten Strich ist unnötig. Schau dir z. B. mal Bereitschaftssiedlung Marl, das ist ein Redirect auf „Marl#Bereitschaftssiedlung und ECA-Siedlung“. Du würdest das - wenn ich dich richtig verstanden habe - so einbauen:

• Redirect [[Marl#Bereitschaftssiedlung und ECA-Siedlung|Marl]]

Es reicht aber die aktuelle Form, ohne das |Marl weil der normale Leser den eigentlichen Redirect gar nicht sieht. Er klickt auf den Link und landet im Zielartikel an der richtigen Stelle. Fertig. Alles dazwischen bekommt er nicht zu sehen (oder kann es sich nur anzeigen lassen wenn er den Trick kennt). Probiere es mal aus. --Nati aus Sythen _Diskussion 23:35, 24. Mär. 2009 (CET)

Einrückung mit Doppelpunkt (:)

Die Einrückung mit Doppelpunkt erzeugt momentan Definitionslisten-Tags:

<dl>
<dd>eingerückt
<dl>
<dd>doppelt eingerückt</dd>
</dl>
</dd>
</dl>

Das ist leider falsch (siehe W3 und BitV Anlage Anforderung 3) und daher sollte, wenn niemand etwas dagegen hat, dieser Abschnitt nach WP:TG#nicht. -- Emdee 20:00, 6. Mai 2009 (CEST)

Ist umgezogen. -- Emdee 20:13, 6. Mai 2009 (CEST)

Vielleicht sollten wir aber für einen Ersatz dafür sorgen. Beispielsweise werden mathematische Formeln gerne eingerückt. Optional versieht man <math> mit einem weiteren Parameter/Argument. -- Emdee 12:29, 27. Mai 2009 (CEST)

Zahlen im Text

Hallo, gibt es Richtlinien, wie Zahlen im Text formatiert werden sollten? Bsp.: 8 mal vs. acht mal -- Tastentipper snafu 14:45, 17. Mai 2009 (CEST)

Es gibt eine Seite zur Schreibweise von Zahlen. Gruß, -- Emdee 15:07, 17. Mai 2009 (CEST)

Einrückungen

"Einrückungen mit dem Doppelpunkt sollten vermieden werden, sofern sie nicht mit Definitionslisten benutzt werden."

Und wie sollen Einrückungen dann vorgenommen werden? --Pjacobi 19:42, 1. Jun. 2009 (CEST)

Wir brauchen dafür dringend einen Ersatz oder eine Änderung zur kontextbasierten Umsetzung der Doppelpunkteinrückung. So könnte ein Doppelpunkt, bei dem im gleichen Absatz kein Semikolon vorherging, eine einfache Einrückung bewirken (ohne das Definitionslistenproblem und ohne entsprechende XHTML-Tags). Alternativ könnte <math> modifiziert werden. -- Emdee 21:09, 1. Jun. 2009 (CEST)

Hallo, wie wäre es mit der Verwendung von blockquote-Tags in solchen Fällen? --Wiegels „…“ 22:09, 1. Jun. 2009 (CEST)

Siehe auch diese Ankündigung --Wiegels „…“ 22:29, 9. Jul. 2009 (CEST)

Zuersteinmal stellt sich mir die Frage, warum ":"-Einrückungen überhaupt vermieden werden sollen. Sie lassen sich sowieso nicht totschweigen, da sie alltäglich auf Diskussionsseiten benutzt werden. enwiki, und vermutlich die meisten anderen Projekte, unterstützen ausdrücklich ":"-Einrückungen und es ist bei uns auch noch kein Artikel nicht exzellent geworden, weil er ":"-Einrückungen enthält. --Pjacobi 22:16, 1. Jun. 2009 (CEST)

Es ist doch nicht wichtig, welches Wiki das noch falsch macht. Mediawiki generiert aus Semikolon und Doppelpunkt eine Definitionsliste (siehe oben). In mw:Help:Formatting wird das korrekterweise so ausgewiesen, es wird aber auch erwähnt, dass das Semikolon dafür adaptiert werden kann, um Einrückungen zu erzeugen (weist aber auf das Problem hin mit “This adoption may be controversial from the viewpoint of accessibility”). Wir haben hier sehr große Ansprüche und sollten dafür sorgen, dass wir diesen Ansprüchen auch gerecht werden. Und welcher Artikel ist exzellent, der den Doppelpunkt (außer bei mathematischen Formeln, das muss erst einmal toleriert werden) für eine Einrückung missbraucht? -- Emdee 22:27, 1. Jun. 2009 (CEST)

Die Benutzung von Doppelpunkten ist erst einmal eine eingeführte und relativ benutzerfreundliche Methode, Einrückungen zu erzielen. Dass die derzeitige Umsetzung von Wikitext in HTML zu einem nicht optimalen Markup führt, ist ein Problem, dass ohne Zeitdruck in MediaWiki beseitigt werden kann. --Pjacobi 22:40, 1. Jun. 2009 (CEST)

Und bis dahin sollte halt darauf hingewiesen werden, dass ein Missbrauch unerwünscht ist, der übrigens nicht nur „nicht optimalen Markup“ erzeugt, sondern dessen erzeugter Markup sogar schlicht falsch ist. -- Emdee 22:55, 1. Jun. 2009 (CEST)

Du hast in Deiner Posting eben auch ein ":" missbraucht. Das ganze Argument ist doch nicht wirklichkeitsnah. Die Wikipedia ist ein Autorensystem zum Erstellen einer Enzyklopädie, und dass ":" Einrückungen erzeugt ist gutes Features (es ist viel leichter zu benutzen als z.B. die Tabellensyntax, die in Usability-Studien immer das Grauen ist). --Pjacobi 08:24, 2. Jun. 2009 (CEST)

Ja, wir drehen uns im Kreis. Klar ist es bequem, aber es ist auch falsch; und es braucht eine Alternative, selbst für die Diskussionen. Jedoch geht es vor allem um den ANR, in dem wir, ganz edelmütig, das Wissen der Welt für die Welt (also möglichst für alle, ganz gleich, wie sie das Wissen präsentiert bekommen) speichern und anbieten. -- Emdee 22:16, 2. Jun. 2009 (CEST)

"Wir brauchen eine Alternative"? -- D.h. selbst wenn MediaWiki eine gute Form der Einrückung in der HTML-Ausgabe erzeugen könnte, würdest Du dafür plädieren, dass das Wiki-Markup dafür nicht ":" ist? Das halte ich für ausgesprochen widersinnig. --Pjacobi 22:34, 3. Jun. 2009 (CEST)

Siehe meine erste Antwort. -- Emdee 22:54, 3. Jun. 2009 (CEST)

Wenn Du aber zustimmst, dass auch in Zukunft ":" das Wiki-Markup für Einrückungen sein soll, warum soll es zwischenzeitlich verboten werden?

Überhaupt ist dies hier ja eine Plattform zur Schaffung von Inhalten im selbstgewählten Format Wiki-Markup und Mirrors oder alternative Renderer (z.B. PDF) sind heute schon frei, das ":" im Markup kontextsensitiv in Einrückung oder DL zu verwandeln.

--Pjacobi 23:09, 3. Jun. 2009 (CEST)

Jedoch interpretieren die Webbrowser wie deiner (ich unterstelle das einmal) nicht den MediaWiki-Markup, sondern das daraus generierte XHTML. Und Verbot riecht etwas streng, zumal wir den Doppelpunkt ja glücklicherweise kaum oder garnicht brauchen im ANR. -- Emdee 23:22, 3. Jun. 2009 (CEST)

Definitionsliste, Begriff

OK, was genau soll das sein? Für mich nur einfach - Liste. --Succu 21:39, 8. Jul. 2009 (CEST)

Siehe weiter oben unter #Einrückung mit Doppelpunkt (:) (dort die Links). -- Emdee 21:41, 8. Jul. 2009 (CEST)

Oder meinst du allgemein, was eine Definitionsliste sein soll? In einer derartigen Auflistung werden halt Begriffe definiert. -- Emdee 21:44, 8. Jul. 2009 (CEST)

Es geht um Wikilisten deren Einzeleinträge mit * beginnen, also das li-Element, korrekter das ul-Element. --Succu 21:57, 8. Jul. 2009 (CEST)

Das sind keine Definitionslisten, sondern eben UL (unnumbered lists). -- Emdee 22:10, 8. Jul. 2009 (CEST)

Anders herum, wie beginne ich mit der Wikisyntax explzit eine <dl> ? --Succu 22:15, 8. Jul. 2009 (CEST)

Ist das eine Fangfrage?

;foo
:bar

erzeugt

<dl>
<dt>foo</dt>
<dd>bar</dd>
</dl>

-- Emdee 22:19, 8. Jul. 2009 (CEST)

Hm, es ging mir um

;foo
*bar

Das erzeugt

<dl>
<dt>foo</dt>
</dl>
<ul>
<li>bar</li>
</ul>

was natürlich syntaktischer Schrott ist. Ok, was gelernt. Vielleicht formulierst du umseitig mal, das das Semikolon nicht im Zusammenhang mit * bzw # benutzt werden darf. Gruß --Succu 07:05, 9. Jul. 2009 (CEST)

DL und UL

Wiki	xhtml	Ausgabe
;Po :*Fluss in Italien :*Kurzform für ''Popo'' (ugs.)	<dl> <dt>Po</dt> <dd> <ul> <li>Fluss in Italien</li> <li>Kurzform für <i>Popo</i> (ugs.)</li> </ul> </dd> </dl>	Po Fluss in Italien Kurzform für Popo (ugs.)
Obiges könnte okay sein, obwohl ich mir nicht sicher bin, ob da nicht noch ein dd jeweils hingehört. -- Emdee 14:21, 9. Jul. 2009 (CEST)

Nachtrag: “Inside a <dd> tag you can put paragraphs, line breaks, images, links, lists, etc.” (W3-Schools) -- Emdee 14:25, 9. Jul. 2009 (CEST)

Overline möglich?

Ich habe folgendes Problem. Die Formel $C_{\text{4}}A_{\text{3}}{\overline {S}}$ (eine in der Bauchemie übliche Schreibweise) kann ich zwar mittels WP:TEX erstellen, ist aber umständlich und sieht im Fließtext auch nicht sonderlich gut aus. Gibt es eine Möglichkeit, '\overline S' für Fließtext anders zu erzeugen, per Sonderzeichen etc? Danke und Grüße, --Derhammer Erklärungsbedarf? 09:34, 10. Jul. 2009 (CEST)

Hallo Derhammer, du kannst CSS-Gestaltung zuhilfe nehmen, um einen Strich über einen Buchstaben zu zeichnen: C₄A₃S. Es passt besser zum Fließtext, ist aber noch länger als die math-Schreibweise. --Wiegels „…“ 11:43, 10. Jul. 2009 (CEST)

Hast recht: ist auch umständlich, sieht aber besser aus. Vielen Dank für den Tip, hat mir sehr geholfen. Grüße, --Derhammer Erklärungsbedarf? 19:36, 10. Jul. 2009 (CEST)

Bilder / Vorlagen nebeneinander anordnen

Ich möchte Elemente manchmal nebeneinander anordnen, z.B. Bilder oder im Moment vor allem Go-Bretter bzw -ausschnitte, die per Vorlage eingebunden werden:

Wie kann man erreichen, dass diese Darstellungen nebeneinander statt untereinander erscheinen? --Megatherium 14:59, 2. Aug. 2009 (CEST)

Wenn es sich um eine tabellarische Auflistung handelt, wäre dafür ausnahmsweise auch die Tabelle denkbar. Ansonsten z.B. auch via float:

oder

-- Emdee 15:04, 2. Aug. 2009 (CEST)

Variablennamen und andere Quelltext-Fragmente

Hallo, wie kann ich in einem normalen Absatz Variablennamen und andere Quelltext-Fragmente (z.B. Methoden-Namen) so auszeichnen, dass sie in vorformatiertem Text erscheinen? (Damit sie im Schriftbild genau so aussehen wie in einem gegebenen Programm-Listing.) Das code-Element ist ja unerwünscht. Wie sieht es mit tt aus? --Wikiplex 08:57, 28. Aug. 2009 (CEST)

tt ist erlaubt, wenn es eine komplette Zeile Code oder auch ein paar Zeilen Listing sind, schaue mal unter Hilfe:Source nach. — Raymond ^{Disk. Bew.} 10:04, 28. Aug. 2009 (CEST)

Unter Hilfe:Source finde ich nichts, was sich auf das inzeilige Zitieren von Code bezieht. dort geht es nur um komplette Code-Listings. Ich will so etwas schreiben wie "Die Klasse Math hat eine Funktion sqrt()". Und darin Math und sqrt eben nicht kursiv, sondern mit Fixed Font. Grüße! --Wikiplex 10:44, 28. Aug. 2009 (CEST)

Beispiel für die kombinierte Verwendung von tt und source:

Eingabe:

Die Klasse <code>Math</code> hat eine Funktion <syntaxhighlight inline lang="php">sqrt()</syntaxhighlight>.

ergibt:

Die Klasse Math hat eine Funktion sqrt().

Das steht auch in Hilfe:Source beschrieben. Hilft dir das weiter? — Raymond ^{Disk. Bew.} 11:01, 28. Aug. 2009 (CEST)

Ja, danke. Ich wusste nicht, dass man einfach tt verwenden darf. Das ist das, was ich will. Jetzt sehe ich auf Hilfe:Source auch, was du meinst. Das Problem mit dem source-Element ist, dass man eine Sprache angeben muss und dass der markierte Text dann nolens volens auch farbig gesetzt wird (was ich nicht will). Vielleicht sollte man das mit dem tt auf der Hilfeseite einfügen. Grüße! --Wikiplex 12:45, 28. Aug. 2009 (CEST)

Nachtrag: Warum steht die tt-Verwendung nicht gleich auf Hilfe:Textgestaltung? --Wikiplex 12:50, 28. Aug. 2009 (CEST)

<code>?

Warum ist <code> nicht zur Auszeichnung von Code im Fließtext erwünscht? Mir erschließt sich der Sinn dieser Richtlinie nicht und leider werden solche Dinge ja auch nicht wirklich im Text erkläutert. --Sebari ☢ 22:33, 28. Sep. 2009 (CEST)

Was genau meinst du? code taucht umseitig jedenfalls nicht unter WP:TG#nicht auf. Alternativ dazu würde ich aber ohnehin mehrere Blicke in Richtung < source > empfehlen. Gruß, -- E 17:17, 10. Nov. 2009 (CET)

Wo ist hier die Dimensionierung im Schriftsystem?

Wie würde in der Wikipedia eine Schriftart aussehen die auf "23 3/3" dargestellt werden kann? Ich habe bisher nur eine Schriftart gefunden die das kann das ist "andalemo.ttf" die ist aber für nicht-PC-Freaks nicht so einfach zu lesen weil man sich erst mal daran gewöhnen muß das eine 0 auch mal einen Punkt haben kann. Welches Schriftsystem würdet ihr verwenden was eine 0 eineindeutig von einen O und das eindeutig von einen o unterscheiden kann?

Was genau hast du vor? Andalemo ist eine nichproportionale Schrift, wofür willst du die einsetzen, für die Bearbeitung, also den Quelltext? Du kannst deinem Browser auch beibrinigen, bei Wikipediaseiten eine andere Schrift(familie) einzusetzen. -- E 17:15, 10. Nov. 2009 (CET)

Ich suche eine Mono-Schrift in der Wikipedia die eine 0 eindeutig von einen O unterscheidbar macht , ob die proportional ist ist mir egal ich kann alle Schriften lesen die auf das alte Glyphen-System aufgebaut sind nur kannte man damals die 0 (Null) als Glyphe nicht und im Sexagesimalsystem und im römischen Zahlensystem kenne ich die auch nicht deshalb suche ich nach einer 23 3/3 oder XXIII 3/3 darstellbaren Schriftart. (nicht signierter Beitrag von 217.234.233.73 (Diskussion | Beiträge) 17:56, 10. Nov. 2009 (CET))

- 2010 -

Überschriften Html Konform

Es sollte auf den Hilfeseiten hingewiesen werden, dass Überschriften mit einem Buchstaben beginnen sollen. Die wiki-Software macht aus den Überschriften eine id in diesem Muster

<span class="mw-headline" id="1924_bis_1939">1924 bis 1939</span></h3>

Bei der Validierung wird dann dieser Fehler ausgegeben: It is possible that you violated the naming convention for this attribute. For example, id and name attributes must begin with a letter, not a digit. --80.142.184.111 18:42, 24. Jan. 2010 (CET)

Bitte nicht, das geht gar nicht: Inhaltliche Vorgaben aus technischen Gründen. Das ist das Problem der Programmierer. --91.32.102.220 22:01, 24. Jan. 2010 (CET)

• Dann eben so. Sollen die Programmierer das lösen. Werden ja wohl hiervon Kenntnis haben / bekommen. --80.142.157.236 06:42, 25. Jan. 2010 (CET)

Serifen

Ich vermisse eine Angabe, ob in Wikipedia eine serifierte Schrift möglich ist (ja/nein), und falls 'ja', wie man sie wählt. MfG --Benutzer: Hermann Reichert 09:59, 7. Sep. 2008 (CEST)

Man kann HTML-Formatierungen verwenden, hierfür siehe http://de.selfhtml.org/css/eigenschaften/schrift.htm#font_family, also etwa so:

<span style="font-family:serif">Text in Serifenschrift</span>

(In den Artikeln sollte das laut dieser Projektseite, Hilfe:Textgestaltung, in der Regel nicht verwendet werden.) --80.129.67.65 09:09, 10. Sep. 2008 (CEST)

Ich bin zu blöd aka wie krieg ich den Text neben die Babelbox?

Hallo!

Irgendwie kann ich versuchen was ich will, es gelingt mir nicht, den Text auf meiner Userseite neben die Babelbox zu bekommen, also quasi so zu formatieren, dass der Text die Babelbox links umläuft. Kann mir jemand sagen wie das geht? Oder noch besser gleich machen???

Danke im Voraus und verzweifelte Grüße, Euer Thogru Sprich zu mir! 15:03, 31. Mär. 2010 (CEST)

Hallo Thogru, der Text umfließt jetzt die Babelbox. Viele Grüße --Wiegels „…“ 16:39, 31. Mär. 2010 (CEST)

Dieser Abschnitt kann archiviert werden. --Wiegels „…“ 16:39, 31. Mär. 2010 (CEST)

Top, danke für die schnelle Hilfe! Gruß Thogru Sprich zu mir! 16:40, 31. Mär. 2010 (CEST)

Zahlenreihen in Tabellen ausrichten

Wie kann man Zahlenreihen einer Spalte innerhalb einer Tabellen einheitlich Ausrichten (insbesondere wenn die Zahlen unterschiedlich lang sind). Wenn also in einer Tabelle untereinander z.B. diese Daten stehen:

Nr.	Titel	Land	Jahr	Produktion	Besucher
18	Name aaa	US	1959	hihaho	3.200.000
3	Name b	FR	1962	halligalli	20.000
100	Name xxyywz	BRD	1962	fiffifo	400.000
74	Name fff	GB	1966	testtest	1.600.000
177	Name dd	BRD	1972	lalelu	30.000

Die Zahlenreihe in Spalte "Besucher" sieht extrem unübersichtlich aus wenn sie linksbündig ist. Korrekt müsste diese Spalte rechtsbündig sein um die Zahlenreihe übersichtlich und vergleichbar zu machen (das ist ja nur eine kleine Tabelle, bei großeren Zahlenreihen ist das noch viel unübersichtlicher). Allerdings dürfte wiederum nicht die gesamte Tabelle rechtsbündig gemacht werden, da Namen (hier in Spalte "Titel" ) wiederum linksbündig sein sollten. Ein händisches Einrücken der kleineren Zahlen durch z.B. vorangehende Leerzeichen hat hier ja keine Wirkung. Was für eine Lösung gibt es? --93.135.102.210 00:50, 6. Jan. 2010 (CET)

Ich weiß nicht, ob man ganze Spalten rechtsbündig machen kann (ohne die Überschrift!), aber es geht z.B., wenn Du vor jeder Zahl style="text-align:right" | eingibst. --AHert 12:45, 8. Apr. 2010 (CEST)

Nr.	Titel	Land	Jahr	Produktion	Besucher
18	Name aaa	US	1959	hihaho	3.200.000
3	Name b	FR	1962	halligalli	20.000
100	Name xxyywz	BRD	1962	fiffifo	400.000
74	Name fff	GB	1966	testtest	1.600.000

Kein NBSP vor Prozentzeichen notwendig

Hätte jemand einen Vorschlag, wie man die Tatsache, daß das Leerzeichen vor Prozentzeichen automatisch geschützt ist, geschickt dokumentieren könnte, ohne daß dieser Sonderfall zu sehr ablenkt? --♗ 11:11, 13. Apr. 2010 (CEST)

Im Text ist ohnehin "Prozent" vor "%" zu bevorzugen. Daher würde ich das auf einer Tabellen-Hilfe-Seite erwähnen. (Da müsste es ja auch irgendwo um Prozentwerte gehen, oder?) Schönen Gruß --Emkaer 09:32, 12. Mai 2010 (CEST)

Warum sollte man auf einer Hilfeseite zu Tabellen erwähnen, dass "Prozent" im Fließtext dem "%" vorgezogen werden sollte? --Cepheiden 09:37, 12. Mai 2010 (CEST)

Das mit der automatischen Generierung des NBSP vor % sollte in Wikipedia:Schreibweise von Zahlen erwähnt werden bzw. wird dort schon erwähnt. --Cepheiden 09:38, 12. Mai 2010 (CEST)

Fett und Definitionslisten

Hallo, nachdem ich mal wieder eine Diskussion darüber führe, könnte man hier vielleicht darauf hinweisen, dass das Semikolon, das eine Definitionsliste erzeugt, ein ungeeignetes (wenn auch bequemes und deshalb verbreitetes) Mittel ist, Text fett auszuzeichnen, beispielsweise bei Teillisten als Zwischenüberschriften? Gibt es dafür einen Konsens oder andere Meinungen? --Wiegels „…“ 20:43, 6. Mai 2010 (CEST)

Der Wikitext

xxx
;yyy
zzz

erzeugt folgenden HTML-Code:

<p>xxx</p>
<dl>
<dt>yyy</dt>
</dl>
<p>zzz</p>

Die Fettschrift kommt erst durch den Eintrag

dt {
	font-weight: bold;
	margin-bottom: .1em;
}

in http://bits.wikimedia.org/skins-1.5/monobook/main.css und den entsprechenden Stylesheets anderer Skins zustande. Dass es skinabhängig definiert ist, sollte schon mal misstrauisch machen. Ganz ohne Stylesheets würde eine Definitionsliste so aussehen. Es ist die Zweckentfremdung eines der semantischen Auszeichnung dienenden Elements für Layoutzwecke. Es gibt jedoch keine Garantie, dass die Stylesheets überall und zu jedem Zeitpunkt gleich „aussehen“. Dieses Mittel ist deshalb rundweg abzulehnen.

Dir ist das natürlich klar, aber vielen anderen nicht. Mir ist es auch erst ziemlich spät durch deine Änderungen klar geworden. Ich nehme an, dass die meisten Benutzer sich mit Wikitext und HTML nicht befassen, sondern sich an vorhandenem orientieren und den Wikitext so einsetzen, dass das Ergebnis in ihrem Browser und ihrem Skin dem erwarteten „Aussehen“ entspricht. Da ist viel Aufklärungsarbeit nötig, weil es quer durch die Wikipedia und andere Wikis so gemacht wird. Ich würde es deshalb sehr befürworten, hier darauf einzugehen. Man muss nur einen Weg finden, der einerseits nachvollziehbar macht, warum es so „nicht geht“ und andererseits nicht mit zu viel Technik verschreckt. --Entlinkt 21:35, 6. Mai 2010 (CEST)

Ein ähnliches Problem wie das "!" (Syntaxelement für Tabellenheader) bei Tabellen. Eine ordentliche Empfehlung wäre wirklich wünschenswert, dass damit der etablierten Praxis abgeschworen wird, halte ich jedoch für fragwürdig. Viele Nutzer vor allem auch Neulinge formatieren eben nicht nach "Inhalt" sondern nach "optik" (weiß nicht wie ich das anders ausdrücken könnte). --Cepheiden 12:27, 8. Mai 2010 (CEST)

Ich gestehe, früher auch das Semikolon zweckentfremdet zu haben. Aber nur, weil ich nicht wusste, was für Probleme es geben könnte. Habe die "Warnmeldung" mit Erläuterung nun auf der Vorderseite eingefügt. Schönen Gruß --Emkaer 11:12, 12. Mai 2010 (CEST) P.S.: Vielen Dank, Entlinkt! Deine Erklärung hat die Begründung für mich erstmals verdeutlicht. --Emkaer 11:14, 12. Mai 2010 (CEST)

Schönen Dank für die Meinungsäußerungen und die klare Formulierung auf der Vorderseite! --Wiegels „…“ 11:45, 12. Mai 2010 (CEST)

Nachvollziehbar. Aber warum wird das Semikolon dann nicht vollständig "verboten"? Man könnte es ja auch durch

:'''xyz'''

ersetzen... --Carbenium 19:52, 28. Jun. 2010 (CEST)

Hallo Carbenium, Definitionslisten sollten auch als solche ausgezeichnet sein, hierbei die zu definierenden Ausdrücke als dt-Elemente, erzeugt mit Semikolon, und die Definitionen als dd-Elemente, erzeugt mit Doppelpunkt. Eine Seite mit mehreren solchen Listen ist Hilfe:Einstellungen. --Wiegels „…“ 20:44, 28. Jun. 2010 (CEST)

Hallo Wiegels, danke für Deine Antwort. Zwei Fragen hab ich dazu noch:

1. Hat das (also dass man diese Auszeichnungen verwenden soll) was mit den Bemühungen um ein semantisches Web zu tun?
2. Wie umschifft man die oben aufgeworfenen CSS-Style-Probleme?

Grüße, Carbenium 21:11, 28. Jun. 2010 (CEST)

Überschriften mit/ohne Absatz?

Jemand sollte auf der Hilfeseite bei den Überschriften einen Hinweis einfügen, ob man nach der Überschrift einen Absatz einfügen sollte oder nicht. Ich habe es mehrfach gesehen, dass Bearbeitungen gemacht werden, nur um diese Leerzeile einzufügen/rauszunehmen. --AHert 12:53, 8. Apr. 2010 (CEST)

Das ist eher was für Wikipedia:Formatierung als für diese Hilfeseite. Auf die Schnelle finde ich aber keine Empfehlung, nur eine alte Diskussion unter Wikipedia_Diskussion:Formatierung/Archiv#Leerzeile zwischen Überschrift und Absatz?. --Cepheiden 09:51, 12. Mai 2010 (CEST)

Als Wikisyntax-Unkundiger entnehme ich dieser Diskussion, dass es jeder machen kann, wie es ihm besser gefällt, dass die anderen dann aber keinesfalls die Leerzeilen einfügen/rausnehmen sollten. --AHert 14:30, 25. Aug. 2010 (CEST)

<nowiki>

Laut Artikel soll ich das nicht verwenden. Warum nicht und was ist die statt dessen empfohlene Alternative ? -- Juergen 91.52.148.159 13:00, 21. Aug. 2010 (CEST)

Hallo Juergen, in Fällen, bei denen die MediaWiki-Syntax eine ungewollte Umwandlung vornehmen würde, kann man das Problem umgehen, indem man nowiki-Tags verwendet. Um welchen Fall geht es denn? --Wiegels „…“ 13:17, 21. Aug. 2010 (CEST)

Um keinen: Ich habe einfach nur die Richtlinien gelesen und empfand diesen Passus als unverstaendlich. Oder anders formuliert: Nowiki hat den bekannten Zweck und sollte auch dafuer verwendet werden - eine Falschverwendung erscheint mir nicht vorstellbar und diese Richtlinie deshalb sinnlos. -- Juergen 91.52.148.159 13:55, 21. Aug. 2010 (CEST)

Wikipedia-Font?

Hallo, ich hab da mal eine Frage an alle, die sich bisschen besser auskennen als ich. Letztens habe ich den Artikel Marshallesische Sprache bearbeitet, weil in dieser Sprachen diese Buchstaben verwendet werden:

A

Ā

B

D

E

I

J

K

L

Ļ

M

M̧

N

Ņ

N̄

O

O̧

Ō

P

R

T

U

Ū

W

A

ā

b

d

e

i

j

k

l

ļ

m

m̧

n

ņ

n̄

o

o̧

ō

p

r

t

u

ū

w

aber bei M und N sieht das dann mit dem Wikipedia-Font etwas seltsam aus, deswegen habe ich es mit einem div dtyle font erweitert und das ganze in Arial Unicode MS wiedergegeben:

A

Ā

B

D

E

I

J

K

L

Ļ

M

M̧

N

Ņ

N̄

O

O̧

Ō

P

R

T

U

Ū

W

A

ā

b

d

e

i

j

k

l

ļ

m

m̧

n

ņ

n̄

o

o̧

ō

p

r

t

u

ū

w

wenigstens werden so M und N korrekt angezeigt, aber meine Frage nun:

Gibt es eine Schriftart, die diese Zeichen auch anzeigen kann und exakt die gleiche ist wie die, die bei Wikipedia-Artikeln normalerweise verwendet wird (sieht mit Arial irgendwie nämlich doch etwas ungewohnt aus, wenn die restlichen Wörter des Artikels in Wikipedia-Schrift geschrieben sind) bzw. wie heißt eigentlich die Wikipedia-Schrift?

lg -- Seitenverbesserer (nicht mit einer Zeitangabe versehener Beitrag von Seitenverbesserer (Diskussion | Beiträge) 21:13, 15. Mär. 2010 (CET))

Gibt es eine "Wikipdia-Schrift"? Meiner Meinung nach ist das die Standardschrift des Browsers, den der Nutzer verwendet. Wenn du das auf Arial Unicode MS umstellst wäre das also die "Wikipdia-Schrift" ansonsten wahrscheinlich Helvetia oder Arial. --Cepheiden 08:20, 16. Mär. 2010 (CET)

Auszeichnung für Zitate

Gibt es für Zitate nicht auch noch eine Auszeichnung? Ich meine mal auf Diskussionsseiten gesehen zu haben, daß einige WP-Autoren das auch mit (X)HTML-ähnlichen Auszeichnungen (wie etwa <Zitat></Zitat>) machen.
--Konrad – 07:18, 24. Jul. 2010 (CEST)

Ja, siehe Vorlage:Zitat, spezielle Sprachversionen findest du unter Kategorie:Vorlage:Zitation. Dies sollte in Artikeln eingesetzt werden. Auf Diskussionsseiten gibt es hingegen viele genutzte Lösungen. --Cepheiden 09:03, 24. Jul. 2010 (CEST)

Habe die genannte Vorlage mit in die Hilfeseite aufgenommen.^[1]
Übrigens gibt es dazu auch in HTML (ab v4.0 und XHTML ab v1.0) bereits die (natürlich nur englische :-\ ) Auszeichnung <q cite="Quellenangabe">...</q>, die genau dafür vorgesehen ist (siehe auch bei SelfHTML, unter „Logische Auszeichnungen im Text“ und auf Deutsch dann so aussehen könnte: <Zitat Quelle="Quellenangabe">...</Zitat> :-) ), aber im MediaWiki anscheinlich (auch) nicht unterstützt wird. Aber gut daß wie hier das Rad nochmal neu erfunden haben.
--Konrad – 17:57, 13. Jul. 2011 (CEST)

Verbergen/Anzeigen

Ist es möglich ein Stück Text oder eine Tabelle, die so in abgeänderter Form schon einmal im Text vorkommt, zu verbergen und wieder anzuzeigen, ähnlich wie beim Inhaltsverzeichnis? --funkfried 13:21, 29. Jul. 2010 (CEST)

Ja, es ist möglich. Etwas ähnliches wird z.B. bei den Navigationsleisten gemacht, die in diversen Artikeln zu finden sind, siehe auch „Berlin“ (mit derzeit drei eingeklappten) und „Land (Deutschland)“ (mit einer ausgeklappten Leiste) – jeweils am Ende des Artikels.

--Konrad – 18:12, 13. Jul. 2011 (CEST)

- 2011 -

Zeichen Hoch oder Tief stellen

Ich war auf der Suche, wie man ein Zeichen hoch oder Tief stellen kann. Ich konnte mir das "sub" für das Tiefstellen schon raus suchen, aber welches Element benötigt man für das Hochstellen? (nicht signierter Beitrag von 88.79.165.211 (Diskussion) 09:01, 2. Feb. 2011 (CET))

Das ist "sup": a² + b² = c². --91.32.84.246 09:09, 2. Feb. 2011 (CET)

Entität entkommen

Wie entkomme ich analog zu <nowiki> einer HTML-Entität wie &gt ; (hier getrickst) --Itu 02:28, 22. Apr. 2011 (CEST)

Du kannst das & mit &amp, maskieren. Also &gt; (>). Der Umherirrende 08:37, 22. Apr. 2011 (CEST)

OK, nachdem das auch hier so gemacht ist, ist das wohl der beste Trick. Einen regulären Escapebefehl gibt es dann wohl nicht. danke. --Itu 21:23, 22. Apr. 2011 (CEST)

Man kann auch Hilfe:Source verwenden:   oder ohne Syntaxhervorhebung  . --Schnark 09:59, 23. Apr. 2011 (CEST)

ok. --Itu 15:11, 23. Apr. 2011 (CEST)

Harte Zeilenumbrüche

Ich konnte trotz 2 Minütiger Suche nirgends einen Hinweis auf Richtlinien zu Zeilenumbrüchen mit <br /> finden. Vielleicht muss man da den Verweis korrigieren? Ich weiß nur immer noch nicht wohin der Verweis gehen sollte... Pirad 15:35, 14. Jul. 2011 (CEST)

Du meinst vermutlich den Verweis „Zur (sparsamen) Verwendung siehe oben.“ hier in der Hilfeseite. Wenn ich mich richtig erinnere, stand da wohl irgendwo mal was von, daß derartige Zeilenumbrüche normalerweise nicht im (Artikel-)Fließtext verwendet werden sollten, da diese in der Regel durch eine Leerzeile abgebildet oder genauer von der Wikisyntax automatisch in (X)HTML-Syntax umgewandelt werden. Und Sinn der Sache ist, daß die Autoren normalerweise kein (X)HTML können müssen sollten, um auch an Artikeln mitschreiben zu können. Da der genannte Verweis aber anscheinlich ins Leere führt, habe ich diesen nun entfernt.^[2]

--Konrad – 20:47, 14. Jul. 2011 (CEST)

Geschütztes Leerzeichen

Hallo. Warum soll man nbsp nur sparsam benutzen? --TP12 12:24, 13. Okt. 2011 (CEST)

Weil es a) den Quelltext verunstaltet und eine Hürde für technisch unerfahrene (aber potentiell fachlich hoch kompetente) Autoren darstellt und b) typographisch sehr viel seltener angemessen ist als die meisten in ihrer ersten Begeisterung glauben – häufig ist es eine Verschlechterung wegen des weniger gleichmäßigen Zeilenumbruchs. Bei mobilen Geräten mit kleinen Bildschirmen ist das Problem besonders gravierend. --84.130.168.251 12:54, 13. Okt. 2011 (CEST)

Ah, ok, Danke. Und ich dachte schon es gäbe einen wichtigen Grund. --TP12 07:20, 14. Okt. 2011 (CEST)

Nein, es gibt ja auch keinen wichtigen Grund für die Verwendung von nbsp. --84.130.165.98 08:41, 14. Okt. 2011 (CEST)

Fenerbahçe SK

die zwei infoboxen/vorlagen rechts oben sollen plätze tauschen. ich bekomme aber die formatierung nicht hin. kann mir einer dies bezüglich helfen. vielleicht wenns geht hier den fehlenden code schreiben. -- Denizli87 09:47, 20. Okt. 2011 (CEST)

Hallo Denizli87, nach Einfügen einer weiteren CSS-Eigenschaft in die Vorlage ließen sich die beiden Infoboxen vertauschen. --Wiegels „…“ 10:16, 20. Okt. 2011 (CEST)

jo danke dir -- Denizli87 14:02, 20. Okt. 2011 (CEST)

Gedichteinbindung

Hallo Leute, zur Einbindung von Gedichten habe ich »dort« mal einen Verbesserungsvorschlag gemacht. Weil “Poem” immer am linken Rand erscheint und nicht eingerückt wird. Ich würde mich freuen, wenn diese Vorschläge umgesetzt werden könnten. -- Liebe Grüße, Lómelinde Diskussion 10:40, 21. Nov. 2011 (CET)

Danke für den Hinweis. MfG, 92.231.187.92 18:53, 8. Apr. 2012 (MESZ)

- 2012 -

Zwischenräume, Formeln

Hallo, ich bin ganz neu hier und habe erste Änderungen an einem mathematischen Artikel vorgenommen. Dabei stört es mich, dass ich einen Text mit darin eingestreuten Formeln nicht gescheit formatieren kann. Beispiel:

"Hierbei wird die ursprüngliche Gleichung $r=a\cdot \varphi$ zu $r=a\cdot \varphi ^{\frac {1}{d}}$ mit $d\in \mathbb {R}$ erweitert. Für $d=1$ erhält man wieder ..."

Vor allem möchte ich jeweils links und rechts von einer Formel oder Gleichung Zwischenräume selber einfügen. Auch durch Wahl passender Schriftgrößen für die Formeln sowie deren vertikale Positionierung möchte ich gerne schöner als in diesem Beispiel gestalten. Wo kann ich mich über diese Dinge schlau machen ? --Yakob 14:21, 26. Feb. 2012 (CET)

Vielleicht hilft dir Hilfe:TeX, bedenke aber, das andere Leser aufgrund von anderen Endgeräten, anderen Browser oder anderen Bildschirmbreiten die Wikipedia "anders" sehen können, so dass etwas, was für dich vielleicht gut aussieht, bei anderen dafür sehr unschön ist. Der Umherirrende 14:27, 26. Feb. 2012 (CET)

Zwischenüberschrift

Gibt es irgendwo eine schriftlich niedergelegte Empfehlung, ob nach einer Zwischenüberschrift ein Leerzeile folgen soll oder nicht? --Gerbil (Diskussion) 15:58, 20. Mär. 2012 (CET)

Ja, gibt es, unter der Bezeichnung DIN 5008 (siehe auch „Wikipedia:Verbesserungsvorschläge/Archiv/2012/Januar#Überschriften automatisch (teilweise) nach DIN 5008 standardisieren“), die hier übrigens auch vom MedieWiki schon seit Anbeginn seiner Zeit (zumindest auf den Diskussionsseiten, siehe dazu auch unter „Hilfe:Neues Diskussionsthema“) unterstützt wird. MfG, 92.231.187.92 18:51, 8. Apr. 2012 (MESZ)

Zeilenumbruch zwischen Bild und nachfolgendem Wort verhindern

Hallo, ich habe ein Bild in einer Textzeile eingefügt und das anschließende Word mit einem geschützten Leerzeichen   verbunden. Trotzdem kommt es zu einem Zeilenumbruch zwischen Bild und nachfolgendem Wort. Wie kann ich dieses verhindern?--Salino01 (Diskussion) 08:10, 19. Jul. 2012 (CEST)

Hallo Salino01, ich habe gerade erfolgreich getestet, dass es mit <nobr>…</nobr> geht. --Wiegels „…“ 11:48, 19. Jul. 2012 (CEST)

Hallo Wiegels, ausch wenn ich code und nowiki weglasse, wird immer noch <nobr></nobr> lesbar angezeigt.--Salino01 (Diskussion) 17:08, 19. Jul. 2012 (CEST)

Nanu, dann habe ich ungeschickt getestet, nämlich mit Firebug. Dieses Mal mit Vorschau erfolgreich getestet habe ich jetzt <span style="white-space:nowrap;">…</span> (ohne code- und nowiki-Tags). --Wiegels „…“ 17:22, 19. Jul. 2012 (CEST)

Hallo Wiegels, durch eine Suche des obigen Codes in den Vorlagen bin ich auf eine noch viel einfachere Möglichkeit gestoßen: Man muss einfach nur die Vorlage:KU ("kein Umbruch") verwenden. Nochmals vielen Dank für die Hilfe.--Salino01 (Diskussion) 07:15, 21. Jul. 2012 (CEST)

Interessant, die Vorlage KU kannte ich noch gar nicht. --Wiegels „…“ 13:02, 21. Jul. 2012 (CEST)

Wurde als überflüssig bzw. redundant gelöscht, man soll also nun Vorlage:Zeile verwenden. --Geitost 17:47, 13. Okt. 2012 (CEST)

Zeilenumbruch verhindern

Kann man bei einem längeren Text den automatischen Zeilenumbruch verhindern? Also das Gegenteil von <br /> ? beispielsweise nach einem "%"-Zeichen oder vor einem Minuszeichen? --Ohrnwuzler (Diskussion) 05:38, 10. Okt. 2012 (CEST)

Den Zeilenumbruch bei „längeren Texten“ zu verhindern, wäre unsinnig. Ich vermute, dass du das nicht wörtlich meinst. Prozentzeichen kannst du einfach mit Leerzeichen schreiben (z. B. 5 %), dort setzt die Software automatisch ein geschütztes Leerzeichen ( ) ein. Um den Schutz des Minuszeichens (richtig: −100, falsch: -100) kümmert sich der Webbrowser. Sprich, mit den genannten Beispielen gibt es im Allgemeinen keine Probleme. Worin besteht dein Problem dann? --TMg 11:22, 10. Okt. 2012 (CEST)

Ich nehme mal an, dass dieses z.B. in Verbindung wie in 5 %-Hürde gemeint ist. Würde hier ein Umbruch gebraucht, so könnte dieser auch nach dem % und vor dem - erfolgen, d.h. so unschön aussehen wie in 5%
-Hürde. Am einfachsten zu sehen, wenn man das Fenster immer schmäler zusammenschiebt. Abhilfe würde hier {{nowrap|5 %-Hürde}} schaffen. Die Vorlage „KU“ steht für „kein Umbruch“ und ist auch im vorherigen Abschnitt als Lösung vorgeschlagen. Im obigen Beispiel würde sich 5 %-Hürde so nicht mehr trennen lassen. Ob derartige Konstrruktionen aber immer Sinn machen ist vom Einzelfall abhängig.--Salino01 (Diskussion) 20:25, 10. Okt. 2012 (CEST)

Internet Explorer ist der einzige, der das Beispiel „5 %-Hürde“ so unsinnig trennt. Falls das verhindert werden soll, wäre der Einsatz eines geschützten Bindestrichs der korrekte Weg. Vorlagen wie die genannte sind immer nur ein Notbehelf und sollten so weit möglich vermieden werden. --TMg 20:42, 10. Okt. 2012 (CEST)

"5 %-Hürde" ist sowieso falsch, richtig wäre "5-%-Hürde" (nach § 40 oder § 44) oder besser "5-Prozent-Hürde", "Fünfprozenthürde". --84.130.167.78 20:52, 10. Okt. 2012 (CEST)

Richtig, siehe auch Fünf-Prozent-Hürde in Deutschland. --Wiegels „…“ 20:56, 10. Okt. 2012 (CEST)

Ich wollte die Formel

Jahresnutzungsgrad der Gesamtanlage $\eta _{G}$ = 100% – %_{Abgasverluste} – %_{Bereitschaftsverluste} – %_{Lüftungsverluste}

in einer Zeile meiner Tabelle haben. Das System hat nach dem "100%" automatisch umgebrochen, obwohl in der Zeile genug Platz war. --Ohrnwuzler (Diskussion) 21:05, 10. Okt. 2012 (CEST)

Du kannst das etwas zu große und daher hässliche TeX durchgehend verwenden $\eta _{G}=100\,\%-\%_{\text{Abgasverluste}}-\%_{\text{Bereitschaftsverluste}}-\%_{\text{Lüftungsverluste}}$ oder geschützte Leerzeichen η_G = 100 % − %_{Abgasverluste} − %_{Bereitschaftsverluste} − %_{Lüftungsverluste} oder die Vorlage Zeile η_G = 100 % − %_{Abgasverluste} − %_{Bereitschaftsverluste} − %_{Lüftungsverluste} (siehe Quelltext, jetzt mit typographisch korrekten Minuszeichen). --84.130.167.78 21:58, 10. Okt. 2012 (CEST)

Bei den geschützten Leerzeichen wird zumindest bei der Benutzung des Internetexplorers trotzdem umgebrochen! Die TeX-Formel ist sehr breit und würde bei mobilen Geräten relativ früh Probleme bereiten. Je nach Breite der unterstützten Bildschirme könnte auch folgende Aufteilung sinnvoll sein :η_G = 100 % − \%_{Abgasverluste} − %_{Bereitschaftsverluste} − %_{Lüftungsverluste}.--Salino01 (Diskussion) 22:27, 10. Okt. 2012 (CEST)

In diesem speziellen Fall könnte man vielleicht auch noch einmal darüber nachdenken, ob sich nicht eine optisch gefälligere Formulierung der Gleichung finden lässt (mit Variablen wie p_Abgas statt des ungewöhnlichen % mit ellenlangem Index). --84.130.160.25 14:20, 11. Okt. 2012 (CEST)

Ginge es mit Vorlage:Nowrap ? --Ohrnwuzler (Diskussion) 01:46, 16. Okt. 2012 (CEST)

Das ist offenbar dasselbe wie Vorlage:Zeile. --84.130.173.228 10:09, 16. Okt. 2012 (CEST)

Vorlage:Zeile ist eine Weiterleitung auf Vorlage:Nowrap, sie sind daher quasi dasselbe. --Cepheiden (Diskussion) 11:05, 16. Okt. 2012 (CEST)

unsichtbares Trennzeichen

Gibt es dergleichen in Wikipedia und was gibt man dafür ein?

Könnte dieses Zeichen und der Bindestrich ohne Abtrennung im Artikel ergänzt werden und auch in der Sonderzeichenzeile im Kasten ganz unten im Bearbeitungsfenster? --Ohrnwuzler (Diskussion) 14:01, 11. Okt. 2012 (CEST)

Das gibt es und heißt "&shy;" (siehe [3] und Weiches Trennzeichen). Meiner Meinung nach sollte es aber, wie alle Spezialformatierungen, nur in gut begründeten Ausnahmefällen verwendet und nicht in die Sonderzeichenleiste aufgenommen werden (schlechter lesbarer Quelltext, mangelhafte/uneinheitliche Unterstützung durch Browser und andere Lesegeräte für Wikipedia-Artikel, schlechtere Suchmöglichkeiten und andere Probleme bei der automatisierten Verarbeitung der Texte). --84.130.160.25 14:22, 11. Okt. 2012 (CEST)

Wikipedia XHTML Tag's

Ich suche schon seit geraumer Zeit eine verbindliche Liste all jener HTML Befehle nach dem Muster <...> die in Wikipedia zugelassen sind, bzw. auch solcher Befehle die in Wikipedia unerwünscht sind wie z.B. <b> <i> usw. sowie der Wikipedia spezifischen Befehle wie z.B <ref>

Die Variablen nehme ich an, sind ja auf der entsprechenden Seite weitgehend vollständig gelistet.

Kennt jemand Seiten mit übersichtlichen Listen? -- Sorbas 48 (Diskussion) 15:21, 16. Apr. 2012 (CEST)

Gibt es inzwischen: Hilfe:Tags. LG --PerfektesChaos 12:31, 3. Jan. 2016 (CET)

- 2013 -

center in Zitaten

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

Erzwungener Zeilenumbruch

Warum sollte der <br />-Tag nur sparsam verwendet werden? Schließlich kann die Mediawiki-Software anders keinen einfachen Zeilenumbruch darstellen, obwohl der doch eigentlich ein ganz normales textgestalterisches Mittel darstellt. Damit wären wir übrigens auch bei meiner nächsten Frage: Warum kann Mediawiki das eigentlich nicht? --Nicor (Diskussion) 01:18, 10. Jan. 2013 (CET)

Ich fürchte, da widerspricht dir jedes Buch über Textgestaltung. Wie würden ein paar deiner Meinung nach ganz normale Anwendungsfälle dafür denn konkret aussehen? Suchst du möglicherweise <poem>? --TMg 01:42, 10. Jan. 2013 (CET)

Geschütztes Leerzeichen

Liebe Wissende der Textgestaltung! Ist das Geschützte Leerzeichen, wie es in Wikipedia:Schreibweise von Zahlen#Maßeinheiten dargestellt ist noch notwendig? Wann sollte man es verwenden und wann ist es zwingend erforderlich? --BotBln (Diskussion) 19:16, 31. Jan. 2013 (CET)

„Zwingend erforderlich“ ist es niemals. Es kann sogar sehr störend sein und das Gegenteil des Gewünschten bewirken, wenn man es übertrieben einsetzt, beispielsweise auf den schmalen Bildschirmen von Smartphones oder bei nachfolgenden Bearbeitungen des Wikitextes. Es gibt einige Stellen, an denen es sehr empfehlenswert ist. Dazu gehören Abkürzungen (z. B.) und abgekürzte Maßeinheiten. In allen Fällen, in denen man sich nicht sicher ist, sollte man es auch nicht verwenden. --TMg 21:39, 31. Jan. 2013 (CET)

& n b s p ;

Wo erfolgt ein Zeilenumbruch bei „20°C“ ?

Schreibt man:

*20 ° C
*20 °C
*20° C
*20°C

??? --Ohrnwuzler (Diskussion) 11:37, 20. Mär. 2013 (CET)

Am besten erfolgt kein Zeilenumbruch, es gehört aber ein Leerzeichen zwischen Zahl und °C, siehe WP:SVZ#Maßeinheiten. --84.130.246.109 11:51, 20. Mär. 2013 (CET)

Da Zweilenumbrüche von den Browsern automatisch gemacht werden, sollte wohl ein "& n b s p" zwischen der Zahl und dem "°C" stehen. Wird dann nach dem Gradzeichen umgebrochen??? --Ohrnwuzler (Diskussion) 19:48, 20. Mär. 2013 (CET)

Glaube ich kaum. Das käme einem Umbruch mitten im Wort gleich. VG --Apraphul (Diskussion) 19:51, 20. Mär. 2013 (CET)

POEM

Ich würd <poem> rauskicken - hab noch nie gesehen, dass das jemand benutzt und wirklich formatieren tut das ja auch nicht. Sowas ist dann (wenn überhaupt) schon eher was für Profis. Grüße — Alleskoenner (Diskussion) 22:33, 26. Mär. 2013 (CET)

Dann müsstest du dich mal in den ANR begeben und Artikel lesen, in denen von der Thematik her Lieder oder Gedichte vorkommen könnten. Ich habe schon bald Hundert derartige Artikel auch im Quelltext gesehen. Und gegenüber der sonstigen Krücken-Formatierung mit : und jede Zeile einzeln kursiv oder <br /> ist das definitiv besser; dass es sich hier nicht um wirkliche Formatierung handeln würde stimmt auch nicht. Und damit das nicht nur Profis raffen, ist auch ein Link auf die Hilfeseite mit mehreren anschaulichen Beispielen beigegeben. --PerfektesChaos 23:15, 26. Mär. 2013 (CET)

Wenn du so argumentierst, müsste man dann aber auch jede andere Art der Formatierung hier reinschreiben - es gibt dutzender solcher <html-tags>, die auch hin und wieder (zT sogar noch öfters als <poem>) im ANR auftauchen - sollen wir die hier jetzt alle vorstellen? Was ist z.B. mit <blockquote> oder <syntaxhighlight> oder den tausenden Möglichkeiten mit <span>, <div>, <span> etc. pp.? (etliche weitere gibts unter Hilfe:Tags zu bewundern) Müssen die hier jetzt alle erklärt werden? Grüße — Alleskoenner (Diskussion) 23:26, 26. Mär. 2013 (CET)

• <blockquote> ist kein erwünschtes Element. Es soll {{Zitat}} benutzt werden, das wesentlich mehr Möglichkeiten bietet; statt <blockquote> würde es auch ein simpler Doppelpunkt tun. <blockquote> soll vielmehr aus allen Wikitexten entfernt werden.
• <span> gehört in die Vorlagenprogrammierung ist keine empfehlenswerte Formatierung in Artikeln.
• Wer <syntaxhighlight> braucht, ist Programmierer und wird sich schon etwas tiefer eingelesen haben.

Die bestehende Auswahl ist für Einsteiger gerade richtig; nicht zuviel und nicht zuwenig. Lass es einfach.

--PerfektesChaos 23:46, 26. Mär. 2013 (CET)

Dann such dir aus Hilfe:Tags eben andere Beispiele raus - ich finde poem nicht so wichtig, dass es hier auftauchen sollte. Wenn, dann sollte lieber eine Vorlage für Gedichte erstellt werden. Grüße — Alleskoenner (Diskussion) 01:11, 27. Mär. 2013 (CET)

Kurz: Du hast keine stichhaltige Begründung. --84.130.251.33 01:41, 27. Mär. 2013 (CET)

So ein Unsinn - was hilft es, wenn ich hier dutzende Gegenbeispiele aufzähle? Der Punkt ist, dass poem hier sinnlos ist - mehr will ich damit nicht sagen. Grüße — Alleskoenner (Diskussion) 01:42, 27. Mär. 2013 (CET)

Poem steht hier bereits seit 8. Februar 2007.

Dies wurde in 147 Versionen von 87 anderen Benutzern so für sinnvoll erachtet.

Bloß weil ein Alleskönner daherkommt und meint, es müsse mal eben alles geändert werden, nur damit irgendwas geändert wird, werden wir garantiert nicht den Hampelmann geben. Ob Alleskönner irgendetwas für „hier sinnlos“ hält, ist demgegenüber völlig egal; es ist eine isolierte Einzelmeinung.

Eigenmächtige, undiskutierte Löschungen von Inhalten aus zentralen Projekt- und Hilfeseiten von fundamentaler Bedeutung sind im Übrigen nicht statthaft.

Es ist auch sinnlos, eine seit langer Zeit eingeführte Wikisyntax durch eine Vorlage zu maskieren, die mit den gleichen Parametern exakt das Gleiche macht; Anwender allerdings noch zusätzlich vor die Probleme des Escapens von Gleichheitszeichen und Pipe-Syntax stellt.

--PerfektesChaos 10:28, 27. Mär. 2013 (CET)

Falls möglich bitte Umleitung von Wikipedia:Kursiv

Im Moment ist Wikipedia:Kursiv hierher verlinkt. Der Nutzer erfährt hier aber nur, wie kursiv erzeugt wird, und das wissen die Nutzer, die „Wikipedia:Kursiv“ eingegeben haben, sicherlich schon. Ich habe gerade einen Abschnitt zum Thema Kursiv in Wikipedia:Typografie geschrieben (unter „Detailfragen“). Diese Informationen dürften für die Nutzer interessanter sein. Könnten wir die Umleitung dorthin legen? Lektor w (Diskussion) 08:33, 8. Jun. 2013 (CEST)

Hallo Lektor W, deinen Vorschlag finde ich sehr sinnvoll und ich habe ihn gerade umgesetzt. --Wiegels „…“ 11:47, 8. Jun. 2013 (CEST)

Abschnitt "Möglichkeiten zur Formatierung von Wikipedia-Artikeln"

Im Kapitel Möglichkeiten zur Formatierung von Wikipedia-Artikeln fehlt noch die Vorlage:Gesetzestext. Da der umseitige Text von "Möglichkeiten" und nicht von "Beispiele von Möglichkeiten" spricht, sollte die Vorlage noch erwähnt werden. Meinungen? --Matt1971 (Diskussion) 22:13, 13. Okt. 2013 (CEST)

Späte Antwort:

Diese Hilfeseite zählt ausschließlich die Möglichkeiten der weltweiten MediaWiki-Software auf, um Text zu formatieren.

Zusätzlich haben wir in der deutschsprachigen Wikipedia Hunderte und Aberhunderte von selbstgemachten Vorlagen, die zur Formatierung eingesetzt werden können. Wenn wir damit umseitig anfangen, geht diese Seite völlig kaputt.

VG --PerfektesChaos 21:48, 6. Dez. 2014 (CET)

- 2014 -

„ebenda“ und Einzelnachweis

Hallo VampLanginus, ich habe es so verstanden, dass ein Einzelnachweis nicht an einem „ebenda“ angebracht sein soll. Ich gehe davon aus, dass zum Ausdruck gebracht werden sollte, dass Geburts- und Sterbeort identisch sind, deswegen die Klammer vorher zu. Alternativ sollte aber wohl in Verbindung mit dem Einzelnachweis der Sterbeort erneut genannt werden. Habe ich da etwas falsch verstanden? Freundliche Grüße--Dmicha (Diskussion) 11:50, 13. Feb. 2014 (CET)

Hier bezieht sich ja der Einzelnachweis zum Tod und nicht zum Ort, also die Klammer nachher. Die Klammer dort vorher habe ich noch nie gesehen bzw. wurde dann geändert. Gruß --VampLanginus (Diskussion) 12:50, 13. Feb. 2014 (CET)

Und auf was bezieht sich „ebenda“?--Dmicha (Diskussion) 13:03, 13. Feb. 2014 (CET)

= Geburts- und Sterbeort sind identisch. --VampLanginus (Diskussion) 18:18, 13. Feb. 2014 (CET)

Zum Thema: Hilfe: Einzelnachweise steht: Als Quellenangaben dürfen die Begriffe „ebenda“ (auch oft: „ebd.“) oder „am angegebenen Ort“ (üblich: „a.a.O.“, auch: „a. a. O.“) nicht verwendet werden. In gedruckten Aufsätzen und Büchern oder auf statischen Webseiten sind solche Kurzbelege üblich und stellen kein Problem dar. Wikipedia-Artikel werden aber potentiell und tatsächlich laufend verändert. Ein „ebenda“ bzw. ein „a. a. O.“ bezieht sich in der Regel auf die vorhergehende Quellenangabe. Werden nun bei Überarbeitungen von Artikeln neue Quellenangaben zwischen alten erzeugt, so verändert sich die Reihenfolge und ein „ebenda“ bzw. ein „a. a. O.“ kann dann unbemerkt zu einem falschen Beleg führen. Aus diesem Grund muss der Beleg wie oben beschrieben immer genau angegeben werden. Ein Einzelnachweis an einem Wort nimmt zu diesem Bezug, hinter einem Satz auf den ganzen Satz oder Satzteil, hinter einer Klammer auf den gesamten Klammervermerk. Das sind die Hintergründe meiner Argumentation. --Dmicha (Diskussion) 06:37, 14. Feb. 2014 (CET)

Ich weiss, das habe ich auch gelesen. Beobachte viele Biografieartikel und dort wird immer wieder auf die ) nach dem Einzelnachweis geändert und nie umgekehrt. Sind leider viele blöde Beschreibungen hier im Wiki + viel zu wenig im Detail. --VampLanginus (Diskussion) 09:41, 14. Feb. 2014 (CET)

Wir können uns ja so einigen, dass wir beim Sterbeort diesen nochmals nennen, um „ebenda“ zu vermeiden, wenn der Einzelnachweis vor der Klammer stehen soll. Gruß--Dmicha (Diskussion) 09:59, 14. Feb. 2014 (CET)

Das auf keinen Fall. Bitte diskutiere doch das bei dieser Hilfe, vielleicht steht es sowieso dort im Archiv. --VampLanginus (Diskussion) 12:06, 14. Feb. 2014 (CET)

(Einschub)

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)

(Einschub Ende)

Eigentlich egal, wo es diskutiert wird. Im Archiv Wikipedia Diskussion:Belege kann ich nichts finden, dito in Wikipedia Diskussion:Formatvorlage Biografie. Das Beispiel in der „Formatvorlage Biografie“ lautet: „Frédéric Karl „Fred“ Freiherr von Dingsda, geboren als Frédéric Karl Müller, (* 1. April 1000 in Musterhausen; † 24. Dezember 1100 in Musterheim; Pseudonym: Primus von Primel) war ein deutscher Tiefsee-Astronom.“ Je nachdem, wo ich innerhalb der Klammer mit den Angaben zu den Lebensdaten einen Beleg vor der schließenden Klammer einfüge, dann nimmt meiner Meinung nach der Beleg Bezug auf das jeweilige Datum oder den jeweiligen Ort. Steht der Beleg direkt nach dem Semikolon, ist Geburtsdatum und -ort belegt; steht der Beleg direkt vor der schließenden Klammer, kann damit ausschließlich der Sterbeort oder Sterbedatum und -ort zusammen belegt sein. Wird der Beleg hinter der schließenden Klammer eingefügt, dann wird damit zum Ausdruck gebracht, dass alle Daten innerhalb der Klammer belegt sind. Anders macht das für mich keinen Sinn. Ob die Angabe des Sterbeorts mit „ebenda“ erfolgt, spielt doch keine Rolle, wenn es um die Frage geht, an welcher Stelle der Beleg eingefügt wird? (Die Funktion des „ebenda“ in Bezug auf den Sterbeort ist doch eine völlig andere als in Bezug auf eine Quellenangabe.) Aber wie bei so vielen anderen Fragen auch wird sich wohl keine einheitliche Regelung herbeiführen lassen. Ist halt so manches etwas uneinheitlich in der WP. --Horst Gräbner (Diskussion) 14:48, 16. Feb. 2014 (CET)

O.K. Du bist für Toleranz. Die Regel, „ebenda“ mit einem Einzelnachweis nicht zu kombinieren, ist doch klar?--Dmicha (Diskussion) 15:47, 16. Feb. 2014 (CET)

Wenn „ebenda“ den Sterbeort meint, dann kann da ebenfalls ein Einzelnachweis stehen. Weshalb denn nicht? In der Regel werden bei den Lebensdaten keine Belege angegeben, wenn sie allgemein zugänglich sind. Das Problem entsteht doch meistens bei einem aktuellen Todedatum, hier ist ein Beleg erforderlich, wenn es nicht gerade der Superpromi ist, dessen Tod durch die Presse geht. Als Beispiel: (* ... in Frankurt; † 15. Februar 2014 ebenda>ref, FAZ vom xyz<). Der Beleg gibt an, wann und wo die Person gesorben ist, wobei der Sterbeort mit dem Geburtsort identisch ist. Anders: (* ... in Frankurt;>ref, FAZ vom xyz< † 15. Februar 2014 ebenda>ref ebenda<). Der Beleg soll nicht durch ein „ebenda“ auf den vorher angegebenen Beleg Bezug nehmen. Sondern dann: (* ... in Frankurt;>ref, FAZ vom xyz< † 15. Februar 2014 ebenda>ref FAZ vom XxYyZz<). Viele Grüße. --Horst Gräbner (Diskussion) 16:15, 16. Feb. 2014 (CET)

Danke, dann werde ich das künftig so belassen. Gruß--Dmicha (Diskussion) 16:38, 16. Feb. 2014 (CET)

Bindestriche

Mir fallen immer wieder Editierungen auf, die nichts anderes zum Ziel haben, hunderte (-) Bindestriche (als "Minus"-Zeichen wie man es typisch auf der Tastatur findet) gegen (–) (Spiegelstrich, Geviertstrich) zu tauschen. Mit der entsprechenden Schaltfläche im Editor ist das auch kein Problem. Was mir (als doch nicht ganz unerfahrener User) immer fehlt, das ist eine saubere Übersicht auf der alle unerwünschten Zeichen mit den Ersatzzeichen aufgelistet sind. Auf der Seite Hilfe:Textgestaltung sucht man den Bindestrich jedenfalls vergeblich. Unter Hilfe:Sonderzeichen findet man natürlich die entsprechenden Zeichen, dort gibt es aber keine Hinweis, dass diese Zeichen ausschließlich zu verwenden sind. Für einen neuen User erscheint es mir, ist es fast unmöglich – ohne viel Aufwand alles richtig zu machen. -- Sorbas 48 (Diskussion) 15:29, 17. Feb. 2014 (CET)

Das steht auf der Seite WP:TYP. --84.130.152.12 15:40, 17. Feb. 2014 (CET)

Textgestaltung in "Disskussion"

Wie formatiert man in "Disskussion" richtig? Vorallem wenn man aufeinander antwortet, einfach mit einer Leerzeile oder mit ; ? (nicht signierter Beitrag von Cptechnik (Diskussion | Beiträge) 21:27, 6. Dez. 2014 (CET))

Hilft dir H:DS #gliedern und der Quelltext meiner Antwort?

LG --PerfektesChaos 21:39, 6. Dez. 2014 (CET)

- 2015 -

code und tt

Ist es Absicht, dass hier manche Zeilen mit code und andere mit tt formatiert sind? Ist da ein System dahinter? Mein Browser stellt die Zeilen mit "code" anders dar als die mit "tt". --Neitram ✉ 13:41, 18. Jun. 2015 (CEST)

Ja, ist Absicht.

Mit <code> wird eine Sequenz an Computercode usw. eingefasst, bekommt einen Rahmen und sollte möglichst nur innerhalb einer Zeile benutzt werden.

Das <tt> bedeutet einfach nur, dass ab jetzt in Schreibmaschinenschrift dargestellt werden soll, egal wie lange, und auf Wikisource hat es eine Sonderbedeutung.

LG --PerfektesChaos 13:46, 18. Jun. 2015 (CEST)

Ja, aber warum verwenden wir nicht überall hier <tt>? Ich finde die zeilenweisen Rahmen von <code> nur verwirrend und unschön und ich sehe auch wie gesagt kein System dahinter, wann wir vorderseitig in der linken Spalte <code> und wann <tt> verwenden. --Neitram ✉ 17:07, 18. Jun. 2015 (CEST)

‹tt›	‹code›	Ergebnis	Eingerahmt ‹tt›	Eingerahmt
* eins * zwei ** zwei-eins ** zwei-zwei * drei	* eins * zwei ** zwei-eins ** zwei-zwei * drei	eins zwei zwei-eins zwei-zwei drei	* eins * zwei ** zwei-eins ** zwei-zwei * drei	eins zwei zwei-eins zwei-zwei drei

@Neitram: siehst du da einen Unterschied?

code sollte dort verwendet werden, wo man etwas durch einen Rahmen vom Rest des Textes abgrenzen möchte, um es beispielsweise zum Kopieren bereitzustellen, aber es sollte dann immer in einer Zeile stehen damit der Rahmen nicht zerbrochen wird.

• Beispiel ‹code›: {{Löschen}} erkennt man besser als nur so {{Löschen}}
• Beispiel ‹tt›: <span style="font-family:monospace;">{{Vorlage|Löschen}}</span> ergibt keinen sichtbaren Unterschied zu {{Löschen}}
• Beispiel ‹span›: {{Löschen}} könnte man auch verwenden ist aber mehr Code

Es gibt also schon einen Grund warum einmal ‹code› und ein anderes mal ‹tt› verwendet wird. Ich hoffe ich habe nichts falsch erklärt. --Liebe Grüße, Lómelinde Diskussion 18:10, 18. Jun. 2015 (CEST)

Es ist völlig richtig.

• Wenn ich jemand erklären möchte, was ein Pipe-Symbol | oder ein ASCII-Anführungszeichen " ist und das Zeichen hervorheben möchte, dann schreibe ich <code>"</code> – das sieht dann besser aus, als wenn ich „"“ schreiben würde, und die zusätzlichen Anführungszeichen könnten jemand verwirren, der nun meint, sie würden mit zur Code-Sequenz dazugehören.
• Mehrzeilig mit Rahmen drumrum gibt es auch; hattest du heute schon mal gesehen:

<code>"</code> <!-- ASCII-Anführungszeichen -->
<span style="font-family:monospace;">|</span>     <!-- Pipe-Symbol -->

LG --PerfektesChaos 19:11, 18. Jun. 2015 (CEST)

Ich drücke mich vielleicht wirklich missverständlich aus. Ich frage nicht, warum es beide Auszeichnungsarten gibt und warum beide in Wikipedia ihre Einsatzgebiete haben. Sondern warum konkret auf der Vorderseite mal die eine und mal die andere verwendet wird, ohne erkennbares System. Im ersten Block ist alles mit "code". Im zweiten Block (Überschriften) ist auch alles mit "code". Im dritten Block (Listen) ist alles mit "tt". Und im vierten Block (Formatierung) ist es gemischt. --Neitram ✉ 11:40, 19. Jun. 2015 (CEST)

Möchtest du eine einfache Antwort? Weil diese Seite von mehreren Benutzern gestaltet und immer mal wieder verändert wurde.

Ich analysiere es mal die ‹code›-Tags stammen überwiegend von PC – beispeilsweise erstellt von PerfektesChaos am 19. Aug. 2013 um 21:17 (UTC), die ‹tt›-Tags haben hingegen eine gewisse Speck-Made am 13. Dez. 2007 um 3:51 (UTC) und jemand namens San Jose am 2. Dez. 2006 um 18:38 (UTC), R*elation am 20. Dez. 2012 um 18:44 (UTC), Raymond am 8. Feb. 2007 um 8:31 (UTC), sowie ebenfalls PerfektesChaos am 18. Nov. 2012 um 21:15 (UTC) eingefügt. Da bist du bei letzterem also an der richtigen Adresse. Ich hatte dich schon verstanden und auch ich finde es teilweise unschön formatiert, eben weil dort teilweise Rahmenbrüche vorkommen. Ich kann mir das nächste Woche einmal genauer ansehen, vielleicht fällt mir eine bessere Lösung ein. Klar ist jedoch, dass die Überschriften beispielsweise absichtlich komplett mit den ‹code›-Tags

== Überschriftenebene2 ==

eingerahmt wurden, damit man sofort sieht, dass die Gleichheitszeichen mit zu der Überschrift gehören und Teil des Quellcods sind. Ich wünsche euch ein schönes Wochenende, ich bin dann mal weg. --Liebe Grüße, Lómelinde Diskussion 14:21, 19. Jun. 2015 (CEST)

- 2006 -

Zeilenumbruch im Quelltext

Im Wiki-Quelltext kann man die Zeilenumbrüche i. d. R. beliebig setzen, eine Ausnahme sind Listen: dort wird ein Zeilenumbruch in einem *-Eintrag etc. anders interpretiert: welches Zeichen muss dann ans Quelltext-Zeilenende, damit der Umbruch nicht in den Artikel etc. übernommen wird? (dies wäre IMHO auch als Hinweis in Hilfe:Listen gut...) Danke --kai.pedia (Disk.) 21:07, 2. Jan. 2016 (CET)

• Wenn ich richtig verstehe, was du wissen möchtest,
• ist es,
  eine neue Zeile im dargestellten Text zu bewirken.
• Dazu nehme man <br />
• oder lese Hilfe:Listen #Tipps (a.F.)
• bzw. die vorletzte Zeile der bisherigen Tabelle.
• Wobei ich dies jetzt deiner Anregung entsprechend ausgebaut habe.
• In der Abschnittsüberschrift hier sollte es eher um „dargestellten Text“ als um „Quelltext“ gehen; in den Quelltext gehört ja grad kein Zeilenumbruch.

LG --PerfektesChaos 12:30, 3. Jan. 2016 (CET)

Nein, die Frage war imho anders gemeint. Er wollte wohl wissen,

• wie man verhindert, dass hi

er ein Zeilenumbruch im Quelltext einen Zeilenumbruch im HTML-Output erzeugt. 88.67.114.224 14:20, 3. Jan. 2016 (CET)

Mittels HTML-Kommentaren lässt sich das umsetzen:

* … dass hi<!--
             -->er ein Zeilenumbruch …

• … dass hier ein Zeilenumbruch …

LG, ℳ웃79 ^✍ 15:59, 3. Jan. 2016 (CET)

Hallo und Danke an alle - ja, es war das zweite und den Kommentartrick kann ich mir hoffentlich merken...

(hab es jedenfalls mal in Hilfe:Listen#Tipps hinterlegt, mal sehen, ob das drinbleibt :-) --kai.pedia (Disk.) 21:16, 4. Jan. 2016 (CET)

Promillezeichen

Wie sieht die derzeitige Situation beim Promillezeichen "‰": Wird hier von der mediawiki-software wie beim Prozentzeichen automatisch ein geschützes Leerzeichen gesetzt oder muss dass noch explizit eingegeben werden? Gruß a×p_de^Hallo! 10:38, 10. Mai 2016 (CEST)

International derzeit nur für % und Guillemets.

Das Promillezeichen wäre Kandidat für die geplante Wikipedia:Typografie/Automatische Leerzeichen in deutschsprachigen Wikis.

VG --PerfektesChaos 10:46, 10. Mai 2016 (CEST)

Geschützter Bindestrich

‑

&#x2011;

(ausgeführt dargestellt:) ‑

fehlt im Artikel.

dient zum Schützen eines Wortteils mit führendem Ergänzungsbindestrich.

Sonst erfolgt standardmässig ein Zeilenumbruch unpassend so, dass am Zeilende der Bindestrich verwaist verbleibt und die neue Zeile mit dem Wortteil beginnt.

z.B.

Meteorologen betreuen Barometer und -
graphen.

In Salzburg-Stadt und -
Land

--Helium4 (Diskussion) 11:38, 18. Sep. 2016 (CEST)

• Der geschilderte nachteilige Effekt tritt nur bei sehr sehr dummen oder aber fehlerhaften Browsern auf.
• Alle ordentlichen Browser bekommen es seit Jahrzehnten hin, den fraglichen Bindestrich auch auf eine neue Zeile zu schreiben.
• Nur weil irgendeine Browserversion 2016 mal kaputt ist und Anfang 2017 vielleicht schon wieder ordnungsgemäß funktioniert, verunstalten wir die Quelltexte unserer Artikel nicht mit irgendwelchem kryptischen #!&?$%-Zeugs.
• Deshalb steht es auch nicht umseitig als Empfehlung; vielmehr ist davon ausdrücklich abzuraten.

VG --PerfektesChaos 12:12, 18. Sep. 2016 (CEST)

Der IE11 ist sehr sehr dumm. Und fehlerhaft. Und bekommt das seit Jahren nicht hin.

Und ist erheblich verbreitet.

--arilou (Diskussion) 14:19, 12. Jan. 2017 (CET)

PS: Ein Betroffener.

ähnliches Problem -/-

Immer wieder nett ist auch der Umbruch bei z.B.

Diese(s) Super-Tanker/-Steuersparmodell ist in der BRD weit verbreitet.

Versucht mal hinzubekommen, dass nach '/' ein Zeilenumbruch stattfindet, aber der '-' vor '-Steuersparmodell' erhalten bleibt, aber nach '/' kein '-' eingefügt wird... (und auch nicht vor '/' umgebrochen wird)

--arilou (Diskussion) 14:29, 12. Jan. 2017 (CET)

Das ist die hohe Schule der Typografie und überfordert Normalautoren. Nix für diese Seite, die einen übersichtlichen Einstieg in die grundlegenden Elemente liefern soll.

Super-Tanker/<wbr />-Steuersparmodell

H:Tags #wbr – für diesen Sonderfall und da die Automatismen der englischsprachig programmierten Browser damit sonst überfordert sind. Wirkt zuverläsig und die Zeichen sind mit der normalen Textsuche auffindbar.

VG --PerfektesChaos 14:35, 12. Jan. 2017 (CET)

Danke! --arilou (Diskussion) 15:50, 12. Jan. 2017 (CET)

- 2017 -

Absatz

bzgl. diesem Revert

Hilfe:Index/Absatz ist ein Redirect hierher. Und da {{Absatz}} weder Bild- noch Tabellen- noch Video- noch Audio-spezifisch ist, sollte es in der allgemeinen Hilfe zur Formatierung aufgeführt sein - also hier im Artikel.

--arilou (Diskussion) 14:14, 12. Jan. 2017 (CET)

„Absatz“ meint Absatz (Text) – und das wird durch eine Leerzeile bewirkt und hat nichts mit einer Vorlage zu tun, deren Name im Übrigen hochgradig irreführend ist, weil sie tatsächlich was ganz anderes macht.

VG --PerfektesChaos 14:38, 12. Jan. 2017 (CET)

Hm, sie macht einen neuen Absatz, der auch Bild und Tabelle (+sonstiges) berücksichtigt.

Ich mag das etwas "laienhaft" sehen, aber so ein {{Absatz}} ist für mich auch ein(e Form von) "Absatz", und nichts "ganz anderes". (Deswegen tipp' ich ins Suchfeld auch "Hilfe:Absatz" ein, und find' sie nicht...)

--arilou (Diskussion) 15:53, 12. Jan. 2017 (CET)

• Einen neuen Absatz (Text) erzeugt man durch eine Leerzeile, fertig.
  • Genau das ist umseitig als erstes Element in der Tabelle dargestellt.
  • Genau darauf bezieht sich der Eintrag in Hilfe:Index.
• „Vorlage:Absatz“
  • Sie müsste korrekt heißen: Vorlage:Layoutfluss zurücksetzen oder so ähnlich.
  • Das war den Erfindern der Vorlage aber zu lang.
  • Also wählte man lieber einen völlig falschen und absolut irreführenden Namen, weil sich der mit sechs Buchstaben leichter tippen lässt.
  • Eine sachgerechte und trotzdem kurze Bezeichnung ist auch noch keinem eingefallen.
• div style="clear:
  • Das div hat als Nebeneffekt, dass auch ein Absatz entsteht.
  • Das ist aber nicht der Grund, warum diese Vorlage eingesetzt wird.
  • Das clear bedeutet: Layoutfluss float wieder zurücksetzen.
  • Das hat fundamentale Auswirkungen auf das Seitenlayout und die Anordnung umflossener Elemente, und ist viel viel mehr als nur ein Absatz; dafür bräuchte es diese Vorlage nicht (wenn überhaupt).
• Umseitig sollen nur kurz und knappp die auf allen Wikis gültigen Elemente der MediaWiki-Software übersichtlich dargestellt werden.
  • Vorlagen sind eine Privatangelegenheit der deutschsprachigen Wikipedia. Sie gehören nicht hierher.
  • Es gibt mehrere Hundert Vorlagen, die auch irgendwie auf die Textgestaltung einwirken. Der Versuch, die alle auf einer Seite darzustellen, muss scheitern. Und es wird auch völlig unverständlich und unlesbar, wenn man die einfach so hineinkippt, ohne auch didaktisch zu erklären, was da passiert. Und damit sprengt man jede Seite, die sowas versuchen würde, weil die nur noch in einer Flut von Detailfragen ersäuft.
  • Vorlagen werden in ihren jeweiligen 50.000 Vorlagendokumentationen erläutert und haben erstmal absolut nichts auf den Hilfeseiten verloren; von einigen wenigen verirrten Altlasten mal abgesehen.

VG --PerfektesChaos 16:15, 12. Jan. 2017 (CET)

• Tja, einen Absatz (Text) erzeugt man so. Einen Absatz (alle Anzeigeelemente) aber nur über {{Absatz}}. Pfff, als ob es nur Text gäbe!
• "Genau das ist umseitig als erstes Element in der Tabelle dargestellt.", "Genau darauf bezieht sich der Eintrag in Hilfe:Index." ~ und genau das ist imo zu wenig.
• "„Vorlage:Absatz“ [...] völlig falschen und absolut irreführenden Namen" - seh' ich nicht so. Sie macht einen Absatz (Text+sonstiges), und kann auch noch einiges zusätzlich (je nach Parametern). "[Name] Sachgerecht und kurz": Absatz - ist sowohl sachgerecht als auch kurz.
• Die Html-Umsetzung ist mir ziemlich wurscht; das Ergebnis zählt.
• "Umseitig sollen nur kurz und knapp die auf allen Wikis gültigen Elemente der MediaWiki-Software übersichtlich dargestellt werden." - Das ist hier aber immernoch die Hilfe für Autoren der deWP. Wer zur Wikimedia-Software was wissen will, soll in dortiger Hilfe nachlesen, vmtl. auf Englisch.
• "Vorlagen sind eine Privatangelegenheit der deutschsprachigen Wikipedia. Sie gehören nicht hierher." - Auf den Hilfeseiten der deWP sollte der Umgang mit der deWP erklärt werden. Damit gehören sie hierher!
• "Es gibt mehrere Hundert Vorlagen, die auch irgendwie auf die Textgestaltung einwirken." Und die wichtigen, weit verbreiteten sollten nicht ungenannt bleiben.

--arilou (Diskussion) 10:08, 13. Jan. 2017 (CET)

Erstmal zur Funktion von Vorlage:Absatz. Hier rechts habe ich eine Hilfebox eingebaut, und gleich anschließend mache ich {{Absatz}}

So, unmittelbar vorher stand {{Absatz}}. Und jetzt mache ich mal mittels Leerzeile einen Absatz (Text).

Siehst du nun, dass da ein himmelweiter Unterschied ist?

Zur Aufgabe des Hilfe-Namensraums: Er erläutert die Funktionen der weltweiten Software, und liefert ansonsten zu wichtigen Fragen Verlinkungen auf Projektseiten.

• Damit ist er voll und ganz ausgelastet, und beginnt schon unübersichtlich genug zu werden.
• Angelegenheiten des Projekts gehören auf Projektseiten der deutschsprachigen Wikipedia. Hilfeseiten können bei thematischer Verbindung darauf verlinken, und auf eine Auswahl der allerwichtigsten Projektseiten verlinken H:I und H:G. Ansonsten ist es nicht Aufgabe der Hilfeseiten, die mehreren Tausend Themen der Projektseiten auch noch einmal darzustellen.
• Die Benutzung einzelner Vorlagen wird in den weit über 50.000 Vorlagendokumentationen erläutert.
  • Sie werden nicht doppelt hier noch einmal erklärt.
  • Alleine an Formatierungshilfen gibt es mehrere Hundert, die auf die Textgestaltung Einfluss haben. Die lassen sich weder hier alle noch einmal erklären, noch kann das jemannd widerspruchsfrei und aktuell halten, noch gibt es überhaupt sachkundige personelle Kapazitäten, die eine solche Doppelarbeit leisten könnten.
• Der Umgang mit der dewP wird zunächst auf Projektseiten, dann auch auf Hilfeseiten, und schließlich in Vorlagendokumentationen erklärt; alles an seinem Platz und je besser und logischer alles an der richtigen Stelle angeordnet ist, desto besser ist das Riesending zu überschauen.

Was du dir vorstellst, würde im Ergebnis zu einem völlig undurchschaubaren Dschungel an nicht erklärten Schnipseln und Bröseln führen, und durch den von dir angestrebten Riesenhaufen würde weder jemand durchblicken und das finden, was er sucht, noch wäre es fachlich aktuell, noch würde das Ertränken in den Fluten woanders schon einmal erklärter Angelegenheiten irgendjemandem irgendwas weiterhelfen; vielmehr würdest du mit deiner Strategie die Hilfeseiten völlig unbrauchbar machen, und niemandem wäre geholfen, und schon gar nicht jemandem, der gerade erst anfängt.

VG --PerfektesChaos 10:39, 13. Jan. 2017 (CET)

• Natürlich kenne ich den Unterschied, und sehe ihn, und er ist "himmelweit", ja. Aber {{Absatz}} macht ziemlich genau das, was ich als Normalmensch unter einem 'Absatz' verstehe: Ende_von_allem_aus_dem_vorigen_Abschnitt_inkl._Bilder_und_Tabellen - und dann geht's neu weiter.
  Dagegen wirkt <Leerzeile> nur auf den Text, und der Großteil eines Bilds/Tabelle steht gar nicht neben "seinem Text", sondern neben dem nachfolgenden Textabschnitt, der gar nix mehr damit zu tun hat.
• "Aufgabe des Hilfe-Namensraums: Er erläutert die Funktionen der weltweiten Software, und liefert ansonsten zu wichtigen Fragen Verlinkungen auf Projektseiten." - Ich bin der Meinung, der Hilfe-Namensraum sollte zuallererst Hilfe zur deWP bieten. Das kann teilweise mit "Hilfe zum weltweit eingesetzten Wikimedia-SW-Paket" zusammenfallen, selbiges sollte aber nicht die "Primär-Aufgabe" sein.
• "Angelegenheiten des Projekts" - ich bin mir nicht sicher, ob ich das verstanden habe: Der Namensraum 'Hilfe:' und der Namensraum 'Wikipedia:' der deWP gehören also nicht zu einem bestimmten 'Projekt'; und welches wäre das? Ich dachte - und denke: auf gewisse Weise ist die gesamte deWP "ein Projekt". Und der Hilfe-Namensraum sind diejenigen "Projekt-Hilfe-Seiten" zu diesem gesamt-übergreifenden Projekt "deWP". Oder zu welchem bestimmten Projekt innerhalb der deWP sollen die Hilfeseiten und -Textgestaltung usw. denn sonst gehören?
  Ich kann in H:I und H:G nur Links wieder nach "Hilfe:..." finden, keine Links auf irgendwelche "Projekt-Seiten".
• "50.000 Vorlagendokumentationen [...] nicht doppelt hier noch einmal erklärt" - Ich erwarte auch nicht, dass alle 50000 Vorlagen-Dokumentationen nochmal in Hilfe:xxx auftauchen. Aber mit Bots o.ä. ließe sich durchaus herausfinden, welche z.B. Textgestaltungs-beeinflussenden die 20 am weitesten verbreiteten sind. Und die könnten hier durchaus kurz angesprochen werden, mit einer groben Beschreibung, was sie machen, und einem Link auf die Vorlagen-Dokuseite, für Leser, die's en Detail wissen wollen.
• "und je besser und logischer alles an der richtigen Stelle angeordnet ist, desto besser ist das Riesending zu überschauen" - "völlig undurchschaubaren Dschungel an nicht erklärten Schnipseln und Bröseln"
  Hm. Ich denke, das ist der Widerspruch zwischen "Hierarchisch geordnetes System" und "Hypertext-Linknetzwerk". Du willst ein "schön geordnetes System, alles an seinem Platz". Dafür braucht's nur eine Navbar, und niemals irgend einen Link. Doch eine gute Website muss beides bieten: Geordnete_Struktur und Shortcuts_und_Links, die über den Tellerrand rausreichen.
  "würde [...] die Hilfeseiten völlig unbrauchbar [...], und niemandem wäre geholfen, und schon gar nicht jemandem, der gerade erst anfängt." - struktur-durchdringende Verlinkung, zusätzlich zu einer hierarchischen (Themen-)Struktur, bringt im Allgemeinen mehr Nutzen als Schaden.

--arilou (Diskussion) 13:55, 27. Jan. 2017 (CET)

Tippfehler

Das </nowiki> im Abschnitt "Listen" in der linken Spalte hinter dem Wort "drei" gehört da nicht hin. Da die Hilfeseite geschützt ist, hier nur der Hinweis.--77.189.118.213 00:23, 31. Okt. 2017 (CET)

Jetzt ist es entfernt. Danke für den Hinweis! --Wiegels „…“ 03:31, 31. Okt. 2017 (CET)

Danke auch von mir; kam ebenfalls grad vorbei.

Dass diese und wenige andere Seiten bei IP / neu angemeldeten geschützt sind, liegt allein daran, dass sie sehr häufig bei den ersten Schreibversuchen mit dem Artikelentwurf überschrieben wurden. In der Regel sind die Hilfeseiten zur Korrektur und Verbesserung offen.

LG --PerfektesChaos 03:46, 31. Okt. 2017 (CET)

- 2018 -

Blockzitat

In dem rechten "Hilfe"-Kasten erscheint unter Textgestaltung als erster Punkt "Blockzitat", der allerdings auf eine Hilfeseite für den VE leitet. Könnt ihr das bitte kenntlich machen? Im normalen Quelltext ist das blockquote-tag unerwünscht - darauf kommt man aber nicht so einfach, wenn es hier schon als einer von drei Punkten aufgeführt wird. Eigentlich denke ich, dass der Punkt ganz gestrichen werden könnte, denn auch auf der VE-Hilfeseite steht eigentlich nur, dass man die Vorlage:Zitat nutzen soll. Die Überschrift "Diese Seite beschreibt die Bearbeitung oder Erstellung von Blockzitaten Textabschnitten mit der Bearbeitungsumgebung VisualEditor." ist insofern eigentlich verwirrend. --AnnaS. (Diskussion) 18:42, 14. Sep. 2018 (CEST)

Ja, okay. VG --PerfektesChaos 19:36, 14. Sep. 2018 (CEST)

Vorformattierter Text

@Lómelinde: Die <pre>…</pre>-Klammer ist in der linken (Quelltext-)Spalte nicht dargestellt. So wird dem Leser nicht verständlich, wie man vorformattiert darzustellenden Text erzwingt. Vielleicht sollte man auch noch einen Hinweis zur gefälligen Meidung ergänzen bzw. noch ein sinnreicheres Beispiel finden, damit der Leser nicht meint, wenn ich halt just mal eben aus Jux und Dollerei ein Leerzeichen am Zeilenanfang haben will, ja dann nehme ich doch einfach … --Silvicola ^Disk 09:06, 2. Dez. 2018 (CET)

Hmm ich habe es jetzt nicht hundertprozentig verstanden.

Das Tag pre funktioniert so ähnlich wie syntaxhighlight beides ist aber durchaus in der Darstellung anders als ein vorformatierter Text.

Beispiel pre

''kursiv'' (siehe [[Wikipedia:Typografie #Schriftauszeichnung]])
'''fett''' (bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der [[Prolog (Literatur)|Einleitung]] und für [[Wikipedia:Weiterleitung|Weiterleitungsziele]] vorgesehen)

Beispiel syntaxhighlight lang="text"

''kursiv'' (siehe [[Wikipedia:Typografie #Schriftauszeichnung]])
'''fett''' (bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der [[Prolog (Literatur)|Einleitung]] und für [[Wikipedia:Weiterleitung|Weiterleitungsziele]] vorgesehen)

Beispiel vorformatiert

kursiv (siehe Wikipedia:Typografie #Schriftauszeichnung)
fett (bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der Einleitung und für Weiterleitungsziele vorgesehen)

Wenn etwas hingegen eingerückt werden soll, müsste man Aufzählungen, div oder je nach Anwendung auch poem verwenden.

Beispiel eingerückt über Aufzählungszeichen (Nicht Doppelpunkte die nur fü Definitionsleisten vorgesehen wären)

• kursiv (siehe Wikipedia:Typografie #Schriftauszeichnung)
• fett (bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der Einleitung und für Weiterleitungsziele vorgesehen)

Beispiel div mit <br />

kursiv (siehe Wikipedia:Typografie #Schriftauszeichnung)
fett (bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der Einleitung und für Weiterleitungsziele vorgesehen)

Beispiel poem ohne <br />

kursiv (siehe Wikipedia:Typografie #Schriftauszeichnung)
fett (bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der Einleitung und für Weiterleitungsziele vorgesehen)

Das pre beinhaltet ein <nowiki>…</nowiki>, was die Wikisyntax außer Kraft setzt und den Quelltext sichtbar macht. Vorformatierter Text hingegen wird in eine Art Kasten eingeschlossen und wie normaler Seitentext formatiert jedoch in einer anderen Schriftart ausgegeben. Möchte man hingegen eine Inschrift imitieren kann die Vorlage:Inschrift verwendet werden. Alles in Allem ist es immer davon abhängig was man erreichen möchte. Siehe auch Hilfe:Tabellen#Tabellen im Schreibmaschinenstil ohne Formatierungen. --Liebe Grüße, Lómelinde Diskussion 09:50, 2. Dez. 2018 (CET)

Ich meinte in der Hauptsache viel einfacher Folgendes: Die Seite soll doch bei der Nutzung des Konstrukte helfen, also muss man sie auch zeigen. Aber in der linken Spalte sieht er keine geschriebene <pre>…</pre>-Klammer wie etwa in der Zeile darunter das <poem>, also versteht er auch nicht, was das soll bzw. wie das bewirkt wird. Er sieht einen Unterschied links/rechts nur im vertikalen white space und links nicht wie sonst den zugehörigen Quelltext.

Dass hier überdies etwas diffizile Unterschiede zwischen den verschiedenen Möglichkeiten ähnlicher Formnattierung bestehen, hast Du ja eben ausgeführt, aber die sollte man auf der Anleitungsseite selbst bei den entsprechenden Konstrukten bzw. über Querverweise zwischen diesen erfahren können. Zum noch dazu verdeckten pre aber: nichts. --Silvicola ^Disk 10:49, 2. Dez. 2018 (CET)

Du möchtest also, dass das Leerzeichen besser sichtbar gemacht wird?

Fließtext im Artikel Ein Leerzeichen am Zeilenanfang erzeugt einen vorformatierten Block mit sichtbaren Leerräumen Fließtext im Artikel	Fließtext im Artikel Ein Leerzeichen am Zeilenanfang erzeugt einen vorformatierten Block mit sichtbaren Leerräumen Fließtext im Artikel
Fließtext im Artikel  Ein Leerzeichen am Zeilenanfang  erzeugt einen vorformatierten Block   mit darin   sichtbaren   Leerräumen Fließtext im Artikel	Fließtext im Artikel Ein Leerzeichen am Zeilenanfang erzeugt einen vorformatierten Block mit darin sichtbaren Leerräumen Fließtext im Artikel

so in der Art? --Liebe Grüße, Lómelinde Diskussion 11:20, 2. Dez. 2018 (CET)

Gut so.

Ich habe die Intention dieser Tabellenzeile zur Formatierung wohl missverstanden, nachdem ich auf der Suche nach <pre> erst im Quelltext dieser Hilfeseite fündig wurde. Dann fehlt aber hier jedenfalls eine Zeile zum Tag <pre>, auch wenn das kein spezifisches Wiki-, sondern ein HTML-Tag sein mag. Es wird ja etwa für Quelltextschnipsel in Artikeln zu Programmierung und Programmiersprachen zuweilen benutzt, also sollte es hier auch dargestellt werden, mit allen gewiss erwähnenswerten Kautelen zum Gebrauch. --Silvicola ^Disk 11:50, 2. Dez. 2018 (CET)

Nein.

• Das hier ist für Einsteiger eine übersichtliche Einstiegsseite.
• Die Abschnittsüberschrift sagt: H:TG #Möglichkeiten zur Formatierung von Wikipedia-Artikeln – betone: Artikeln.
• Das erhebt keinen Anspruch auf eine vollständige Darstellung sämtlicher Techniken und Formatierungsmöglichkeiten; diese fändest du für Fortgeschrittene per H:pre auf der Seite Hilfe:Tags.

<pre> ist im ANR sehr selten (230 Treffer, einige nicht sehr glücklich) und eher was für interne Dokumentationsseiten.

• Für mehrzeilige codes im ANR würden wir zur Illustration vielmehr H:syntaxhighlight (3.034 Treffer) verwenden; aber selbst das ist etwas für Fortgeschrittene im IT-Bereich und deshalb auf dieser knappen Einsteiger-Seite nicht erwähnt.

VG --PerfektesChaos 13:10, 2. Dez. 2018 (CET)

Nachträge:

1. <pre> wird dazu eingesetzt, um Wikisyntax zu dokumentieren, ohne dass diese Wikisyntax interpretiert wird.
   • Diese Aufgabe ist für den ANR extrem untypisch und findet sich eher in einer Vorlagendoku.
   • Um einfach nur einen Absatz in Schreibmaschinenschrift darzustellen, genügt das Voranstellen eines Leerzeichens. Das ist triviale Quelltext-Syntax, erlaubt sogar Kursivierung und Fettschrift, und mag hie und da im ANR seine Berechtigung haben, auch wenn es optisch nicht mehr gern gesehen wird.
   • Abgesehen von der unwirksamen Wikisyntax hat das vorangestellte Leerzeichen praktisch die identische Wirkung wie <pre>.
2. Hilfe:Tags und Hilfe:syntaxhighlight sind umseitig sehr wohl erwähnt, allerdings rechts oben in dem grünen Kästchen.
   • Hilfe:Wikisyntax, die zweimal im oberen Bereich der Seite verlinkt ist, gibt hierzu einen konkreteren Überblick.
   • Eine vollständige Beschreibung aller Wikisyntax auf einer einzigen Seite is nix, erst recht nicht für Einsteiger, weil diese auch noch alle Tabellensyntax und alle Tags und Hilfe:CSS und alle magischen Wörter und die Link-Syntax und die Entities und alle Parserfunktionen und Medieneinbindung und Kategorisierung und eigentlich auch noch die über 50.000 Vorlagen mit aufzählen müsste. Selbst ohne die letzteren dürfte das Zwei-MB-Limit geknackt werden; dass eine derartige Seite weder lesbar noch zu pflegen wäre ist ohnehin klar.
   • Hilfe:Wikisyntax/Hintergrund liefert für Fortgeschrittene die nackte formale Struktur.

VG --PerfektesChaos 13:43, 2. Dez. 2018 (CET)

Anführungszeichen auch direkt eingeben ?

Umseitig steht in der Tabelle unter der Überschrift "Formatierung" folgendes:

Oder „kurzer zitierter Text“, auch mitten im Satz. (Stattdessen kann man die Anführungszeichen auch direkt eingeben.)

Was ist den hier mit "Stattdessen kann man die Anführungszeichen auch direkt eingeben." gemeint?

In diesem Beispiel scheinen doch die Anführungszeichen direkt eingegeben worden zu sein. Bzw. wie würde man diese den indirekt eingeben? Über die {{Zitat}} vermutlich? Doch diese wird ja in der Zeile darüber behandelt ..

-- Kai Kemmann (Diskussion) - Verbessern statt löschen: Enzyklopädie ist altgriechisch für "umfassend" - 01:33, 14. Dez. 2018 (CET)

Sorry, das war wohl mein Fehler. Gemeint ist es so.

• {{"|Hier das Zitat im Fließtext}} = „Hier das Zitat im Fließtext“ entspricht „Hier das Zitat im Fließtext“ (ohne Vorlage)

Da habe ich bei der Umstellung nicht aufgepasst. --Liebe Grüße, Lómelinde Diskussion 08:51, 14. Dez. 2018 (CET)

Doppelte oder mehrfache Leerzeilen

Benutzer:Aka verwies mich in dieser Diskussion über den Artikel Cenk Batu auf diese Seite. Im Abschnitt Hilfe:Textgestaltung#Hinweise heißt es:

„Bitte beachte die Wikipedia-Richtlinien zur Formatierung. Insbesondere […] Absätze durch doppelte oder mehrfache Leerzeilen […] solltest du nicht in Artikeln, sondern nur in Tabellen oder Textbausteinen verwenden“

Obwohl ich Software-Entwickler bin, verstehe ich weder, was genau gemeint ist, noch welchen Sinn das haben soll.

Einzelne Absätze werden für gewöhnlich getrennt durch mindestens 2 Zeilenumbrüche, also 1 oder mehrere Leerzeilen. Dass ein Abschnitt mehrere Absätze hat, ist doch völlig normal. In Tabellen wiederum finde ich mehrere Absätze in einer Zelle mindestens ungewöhnlich. Von den anderen aufgelisteten Elementen wie z.B. <br>-Tags wird zurecht abgeraten. Aber auf der verlinkten Seite Wikipedia:Formatierung finde ich gar keinen Suchtreffer zu zeil[e].

• Was ist tatsächlich mit der Formulierung gemeint?
• Weshalb ist es keine gute Idee, den untersten Abschnitt des Artikeltextes von den Kategorie-Links mit mehr als 1 Leerzeile zu trennen?
• Wie könnte man den Hilfetext hier verbessern und verständlicher machen?

(nicht signierter Beitrag von ‎Frupa (Diskussion | Beiträge) 2019-05-30 17:41:06)

Die Vokabel „Absätze“ ist möglicherweise umseitig, mindestens aber wohl für dich missverständlich bis falsch, steht da aber schon seit einem Dutzend Jahren oder so.

Absatz (Text), in HTML <p>, ist nicht das Problem; wir erzielen ihn durch eine einfache Leerzeile zwischen Blöcken aus regulärem Fließtext, oder er ergibt sich durch die Abfolge eines Textblocks und einer Aufzählung, eine Überschrift usw. Du hast oben welche gemacht, etwa bis „haben soll.“ und ab „Einzelne Absätze“.

Das Problem ist ein leerer Absatz, der durch zwei oder mehr aufeinanderfolgende Leerzeilen generiert wird.

• Das ist ein sehr starkes Gliederungsmittel, das allenfalls gerechtfertigt wäre, wenn eine Seite mehrere unterschiedliche Funktionsbereiche enthalten würde.
• Bei unseren enzyklopädischen Artikeln ist das jedoch regelmäßig nicht der Fall.
• Hier hat die Abfolge aller Absätze und Überschriften einen gewissen Rhythmus und ist bewusst gestaltet.
• Ein leerer Absatz, also ein großer Weißraum, reißt hier eine unerwartete Lücke hinein, und wirkt unansehnlich.
• Nachdem der Text anscheinend beendet wurde, kann beim Leser sogar der Eindruck entstehen, es wäre nun alles vorbei, und es wird nicht mehr bis ganz zum Ende gescrollt, wo dann noch die Kategorien usw. stünden.

Tipp: Hilfe:Signatur – zum Unterschreiben von Diskussionsbeiträgen.

VG --PerfektesChaos 18:03, 30. Mai 2019 (CEST)

Oookay, Mediawiki fügt also leere Absätze ein, wenn ich mehr als 1 Leerzeile einfüge. Verrückt.

Argh, ich vergesse immerzu die Signatur. Ich finde es völlig verrückt, Diskussionen zu führen, in dem wir händisch unsere Beiträge korrekt untereinander schreiben und die Meta-Daten einfügen. Es wirkt etwas archaisch, aber ich versuche, mich daran zu gewöhnen.

@PerfektesChaos: danke für deine Antwort!

--Frupa (Diskussion) 18:18, 30. Mai 2019 (CEST)

Noch’n Tipp: Wenn ich hier offensichtlich mitlese, die Seite beobachte, und binnen 22 Minuten meine erste Antwort geschrieben war, dann ist es nicht erforderlich, mich extra anzupingen, um mir mitzuteilen, dass du was geantwortet hattest.

Gilt auch für andere Benutzer; manche reagieren auf solche Alarme recht empfindlich, wenn sie erkennbar noch an einer Diskussion aktiv teilnehmen.

VG --PerfektesChaos 18:29, 30. Mai 2019 (CEST)

Vollständigkeit des Artikels

{{Klappbox}} Ich würde eine Information über Klappboxen oder einen Hinweis auf Klappboxen bzw. auf die Option „Text ausklappen“ in den Artikel einbauen, denn Hilfe:Textgestaltung war mein Anlaufpunkt für die Gestaltung von ausklappbarem Fließtext und es gab keinerlei Hinweise; anschließend wusste ich nicht, was ich noch als Suchbegriff eingeben soll, um Hilfe zu finden.--Bluemel1 🔯 15:55, 5. Jan. 2020 (CET)

Ich nicht.

• Nach Möglichkeit sollen Texte (zumindest in Artikeln) nicht verborgen werden
• Es handelt sich um Vorlagen wie beispielsweise H:Navigationsleisten die hier ebenso nicht erwähnt sind.

Die Hilfeseite behandelt aber eigentlich die allgemeine Syntax zur Gestaltung möglichst barrierefreier Texte. Nicht verborgen, nicht fett, nicht durchgestrichen, nicht bunt … Wo also würdest du das einfügen wollen unter →nicht in Artikeln, als Empfehlung würde ich das jedenfalls nicht haben wollen. Denn eingeklappte Texte führen zu mancherlei Problemen, sie verschlucken Belegtags oder Anker, deren Sprungmarken dann nicht erreichbar sind.

OT: Und noch eine kleine Info, <strong></strong> gehört auch zu den unerwünschten Formatierungen →Hilfe:Tags#wiki, die in der Textgestaltung vermieden werden sollten.

Merkwürdig klingt auch diese Überschrift „Vollständigkeit des Artikels“, eine Hilfeseite ist kein Artikel, sie erklärt eher die Syntax, die hinter der Gestaltung steckt.

Tipp für die Suche →Kategorie:Vorlage:Formatierungshilfe. Einen schönen Abend noch. --Liebe Grüße, Lómelinde Diskussion 19:44, 5. Jan. 2020 (CET)

Fettschrift sparsam?

Auf der Hilfeseite steht: »fett (bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der Einleitung und für Weiterleitungsziele vorgesehen)«

Ich finde, dass man, z. B. um Daten hervorzuheben*, auch im Text fett einsetzen sollte. Die Artikelüberschriften haben ja i. d. R. eine größere Schrift.

*z. B. in längeren Artikel oder Texten innerhalb eines Abschnittes (Übersichtlichkeit!)

Carmol7 (Diskussion) 00:40, 15. Feb. 2020 (CET)

Nee, find ich nicht gut. Das kann man auf einer Flyer-Seite machen. Aber nicht bei buchähnlichen Seiten wie hier, bei WIKIPEDIA. fz JaHn 00:49, 15. Feb. 2020 (CET)

Genau das ist seit Urzeiten hier unerwünscht. Für Hervorhebungen kann man Kursivschrift verwenden, Fettschrift stört aber zu sehr den Lesefluss. Außerdem sollten Hervorhebungen ohnehin bedacht verwendet werden, da sie meist subjektiv sind. -- Chaddy · D 01:56, 15. Feb. 2020 (CET)

Genau, siehe auch > Jan Tschichold. Erfreuliche Drucksachen durch gute Typographie. Eine Fibel für jedermann. Verlag Maro, 1. Juli 2001. ISBN 3875124138. Inwieweit das, was, hier, bei WIKIPEDIA, seit Urzeiten unerwünscht ist, relevant ist, ist allerdings eine GANZGanzganz und gar andere, ähm, Sache. fz JaHn 10:28, 15. Feb. 2020 (CET)

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 dem Wort "auskommentiert" höre ich spontan eher eine analoge Bildung zu "austherapiert" und frage mich, was das Wort bedeuten soll. --217.239.6.208 15:37, 11. Okt. 2020 (CEST)

Das ist kein WP-Slang, sondern zumindest im IT-Bereich sehr üblich und wird etwa auch in Kommentar (Programmierung) oder wikt:auskommentieren erklärt. Gruß --Magiers (Diskussion) 16:14, 11. Okt. 2020 (CEST)

Hmmm... jaaa... mag sein. Aber wird hier davon ausgegangen, dass alle WP-Autoren IT-Kenner sind? Ich wäre im Traume nicht auf die Idee gekommen, danach auf irgendeiner Programmierungs-Klammerlemma-Seite zu suchen, und in einem anderen Projekt erst recht nicht. Mir ist das Wort erstmals - und sehr häufig - in Kommentaren anderer WP-Autoren begegnet, und von daher fände ich es schon angebracht, wenn es irgendwo auf den Wikipedia-Hilfe-Seiten erklärt würde. --217.239.6.208 16:53, 11. Okt. 2020 (CEST)

Zeilenumbrüche

Ich bin jetzt schon eine ganze Weile mit dem Umstand der Zeilenumbrüche konfrontiert und befinde mich gegenwärtig in meiner Auseinandersetzung mit der vorgegebenen Regel, daß man br-Tags 'in der Regel' nicht anwenden soll. Als wesentlich erweist sich hingegen dem gegenüber, daß Zeilumbrüche doch gemäß html gar nicht umgesetzt werden - derart in Erscheinung treten, sodaß es dessen Anwendungsweise doch zwangsläufig erfordert. Ich bin erst bei meiner zweiten Artikelerstellung und gegenwärtig auch nur auf der Entwicklung des Zweiten auf der Dikussionseite damit konfrontiert, worin dies ja nicht wesentlich ist. Doch bewegt gerade dies mich auch einmal dazu, dies generell zu klären, denn selbst in Tabellen ergibt sich mir hierzu die generelle Erfordernis, dem gegenüber nämlich, dies rein tabellarisch zu gestalten, dies doch weiträumig zu völlig überflüssigen Aktionen führt. Generell erweist sich mir das außen vor stellen dieser 'Funktion' als nicht gerade sinnvoll. --Jörg Lenau^t@lk 12:50, 19. Mai 2021 (CEST)

In den allermeisten Fällen ist der br-Tag überhaupt nicht nötig. Allenfalls in Tabellen kann er sinnvoll sein, wenn man mehrere Informationen über mehrere Zeilen hinweg in ein Kästchen setzen möchte.

Hast du ein konkretes Beispiel, wo du diese Formatierung gerne verwenden möchtest? -- Chaddy · D 14:24, 19. Mai 2021 (CEST)

Hier 'mal ein Beispiel aus Diskussion: Splash (Musikgruppe), die ich zur Aufbereitung des Artikels nutze und gerade dort durchweg gebraucht wird:

GEMA Recherche:
ISWC: T-801.541.944-1 - GEMA-Werk.-Nr: 2488369
COPE-AVENUE, G - Komponist
COPE-AVENUE, M - Komponist
COPE-AVENUE, G - Textdichter
COPE-AVENUE, M - Textdichter
CLASSIC ARTS GMBH MUSIKVERLAG UND PROMOTION - Originalverlag

Die Diskografieliste z.B. habe ich bereits als Tabelle auch dort auf der Diskussionsseite zwischenzeitlich vorbereitend eingerichet. Für die regulären jeweiligen Listungen (zur Darstellung, zumal rein für andere Diskussionsteilnehmer - die es hier leider nicht gibt), ist dies hingegen überflüssig. Wobei mir jetzt gerade in den Sinn kommt, daß es weitläufig Sinn macht, dazu Listenpunkte zu verwenden, zumal ich ja bereits an dem Punkt bin, den Artikel jetzt auch inhaltlich sachlich dort vorzubereiten. Regulär zur Diskussion einzelner Fragmente, ist dies indess 'die Formatierung' absolut nicht von sonderlichem Belang, außer wenn es spezieller Inhalt ist. Das br-Tag wende ich hingegen aber auch situationsbedingt für die Unterzeichung an, insofern nämlich wie hier es sich um Gestaffeltes handelt - schafft Klarheit.

• GEMA Recherche:
  
  • ISWC: T-801.541.944-1 - GEMA-Werk.-Nr: 2488369
  • COPE-AVENUE, G - Komponist
  • COPE-AVENUE, M - Komponist
  • COPE-AVENUE, G - Textdichter
  • COPE-AVENUE, M - Textdichter
    • CLASSIC ARTS GMBH MUSIKVERLAG UND PROMOTION - Originalverlag
      

--Jörg Lenau^t@lk 15:20, 19. Mai 2021 (CEST)

Wie du ja selbst schon schriebst kann das in diesem Fall auch gut mit Listenpunkten gelöst werden oder auch mit Doppelpunkten. Da sind auch übrigens die Tags in der ersten und letzten Zeile nicht nötig, die du hier in diesem Beispiel noch verwendest.

Weiterer Hinweis: Bitte verwende das Tag auf jeden Fall in dieser Form: <br />. Die Variante <br> ist veraltet und wird von den Browsern irgendwann in Zukunft nicht mehr erkannt werden können (bisher können es die meisten Browser aus Kompatibilitätsgründen noch). -- Chaddy · D 15:53, 19. Mai 2021 (CEST)

Die umseitige Darstellung bezieht sich auf Fließtext; also fortlaufende Prosa.

• Wenn ein neuer Gedanke mit einem neuen Absatz begonnen werden soll, dann soll auch genau ein solcher verwendet werden.
• Vor einigen Jahrhunderten war es mal Sitte gewesen, dann nur eine neue Zeile anzufangen, und ein paar Autoren haben sich das in ihrem MS Word und im Wikitext so hingebastelt. Das ist aber längst unerwünscht.

In strukturierten Textformen kann es wünschenswert sein, Zeilen explizit zu gestalten.

• Aufzählungen hast du ja schon benannt.
• In Tabellen gibt es häufig Platzmangel, und Aufzählungspunkte würden stören und zu viel Platz rauben.
• Nach einer nachrangigen Überschrift in Fettschrift soll der Text auf einer neuen Zeile beginnen. Das ist okay.
• Wenn innerhalb eines <ref>-Einzelnachweises mehrere Literaturstellen zitiert werden, können diese übersichtlicher angeordnet werden.
• Alles das ist kein Fließtext; also kein fortlaufender Text.

Umseitig heißt es ja auch nur: „Ein erzwungener Zeilenumbruch sollte normalerweise vermieden werden – lieber eine Zeile freilassen und einen neuen Absatz beginnen.“ Das ist kein absolutes Verbot immer und überall.

Den vorstehenden Hinweis „Bitte verwende das Tag auf jeden Fall in dieser Form: <br />. Die Variante <br> ist veraltet und wird von den Browsern irgendwann in Zukunft nicht mehr erkannt werden können“ – das kannst du vollumfänglich sofort wieder vergessen.

• Richtig ist daran nur, dass wir in diesem Wiki seit zwanzig Jahren einheitlich <br /> schreiben.
• Mit Browsern hat das aber nichts zu tun. Mit und ohne Schrägstrich ist das korrekte Syntax, und Browser werden beide Formen problemlos verstehen.
• Der Schrägstrich soll menschliche Leser des Wikitextes daran erinnern, dass dieses Element sofort wieder geschlossen wurde. Normalerweise wäre zu erwarten, dass <br> einen Bereich eröffnet und dieser durch </br> wieder geschlossen wird. Das ist hier jedoch nicht der Fall. Den Maschinen ist das wurscht, die wissen das besser als Menschen.

VG --PerfektesChaos 16:09, 19. Mai 2021 (CEST)

Danke Chaddy und vor allem auch Danke für diese ausführliche Erläuterung PerfektesChaos! JETZT habe ich das 'reguläre' Bild auch wieder vor mir - wurde nur zwischenzeitlich äußerst verworren (und hat da so hier und da seine individuellen Anwendungen!). Hierzu gilt es mir zu erwähnen, daß ich 2 Monate extremste K(r)ämpfe bei Discogs hinter mir habe und bezüglich der fachtechnischen Fragen zur Musik, wie auch dem Aufbau des Artikels hier, nicht so sonderliche Hilfstellungen erlangen konnte (ist jedoch, wie sich aufzeigt Allgemeinsituation und nicht Wiki-typisch) - somit hier wie dort, mir sämtliches KnowHow erst einmal selbst verschaffen mußte. Und da kommt es dann halt auch einmal vor, daß man dann die Bäume im Wald nicht mehr sieht. Wie Du PerfektesChaos auf deiner Seite besagst, sprichst Du von perfektem Chaos hier bei Wikipedia - absolut harmlos gegenüber Discogs und wenn man von dort hier herüber schaut, da ist das doch tatsächlich dem gegenüber ein Garten Eden. Schau dir einmal den Thread von mir an (Trouble with thoughtless situation) - Wahnsinn pur. Wie ich sehe, bist Du mit technischen Dingen beschäftigt und so würde ich dich einmal bezüglich eines entsprechenden Aufbringens von mir bitten, ob Du dazu etwas beitragen kannst, denn dieser Umstand erweist sich nicht nur für mich als äußerst lästig, sondern vor allem geht aufgrund dessen da so einiges an Kommunikation verloren: Echo#Benachritungshickhack. --Jörg Lenau^t@lk 17:08, 19. Mai 2021 (CEST)

„dich einmal bezüglich eines entsprechenden Aufbringens von mir bitten, ob Du dazu etwas beitragen kannst“ – bedaure, ich bin massiv ausgelastet, genauer gesagt überlastet und habe aktuell Dutzende offener Baustellen und Hunderte Aktivitäten auf meiner ToDo-Liste und möchte nichts neu beginnen. VG --PerfektesChaos 17:16, 19. Mai 2021 (CEST)

Absätze funktionieren - oder manchmal auch nicht.

Ich habe seit einigen Wochen ein Problem, Absätze einzufügen:Bisher habe ich das immer so gemacht, wie es empfohlen wurde: zweimal Enter drücken und damit eine Leerzeile einfügen.

Aber das Problem ist: seit einigen Wochen (soweit ich mich erinnere seit etwa Mitte April 2021): manchmal funktionierts, aber meistens nicht. D.h. ich möchte einen Absatz in zwei trennen, drücke zweimal Enter um eine Leerzeile einzufügen (durch die ja ein Absatz und ein neuer Absatz beginnen sollte), aber: sowohl in der Vorschau als auch nach dem Veröffentlichen der Änderung fehlt der Absatz.

Manchmal hilft es, im Editor eine weitere Leerzeile einzufügen (was man auch bei ein paar Edits von mit sehen kann), manchmal funktionierts, wenn ich im Editor eine zweite oder auch dritte Leerzeile einfüge, und manchmal funktionierts, wenn ich Absätze beliebig einfüge und gleich wieder lösche. Sprich: ich kann das Verhalten nicht reproduzieren. --Whisker (Diskussion) 00:54, 18. Jun. 2021 (CEST)

Klingt merkwürdig. Kannst du ein Beispiel, wo es deiner Meinung nach falsch funktioniert, abspeichern und hier verlinken? Schreib dann dazu, wie es bei dir dargestellt wird. --Frupa (Diskussion) 01:33, 18. Jun. 2021 (CEST)

Mein Aufbringen im Abschnitt zuvor steht damit im Zusammenhang. Gerade DAS wurde mir hierin nämlich zur absoluten Last, daß nämlich weitläufig noch nicht einmal diese Anwendung der zeilenbegründenen Absetzung nicht funktioniert(e). Ich kann hierzu indess nicht auf die stattgefundenen Vorgänge verweisen. Es hängt nicht am eigenen System - habe auch Neuaufrufe der Seite und Neutstarts etc. getestet - dieses Mißverhältnis geht von Wikipedia softwaremäßig aus. --Jörg Lenau^t@lk 10:39, 18. Jun. 2021 (CEST)

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)

Nachtrag 2021

Ich möchte mich der Meinung von Jordi anschließen und erstmal aka für seinen unermüdlichen Einsatz danken, auch PerfektesChaos ist mir schon mal positiv aufgefallen.

Aber vielen Argumente gegen <small>, wie zur Leserlichkeit, kann ich nicht teilen.

Vor allem bin ich nicht begeistert wie die Empfehlung "Formatierungen, die nicht verwendet werden sollten" zur Zeit umgesetzt wird. Da wird massenhaft in Artikeln das <small> entfernt ohne eine Alternative einzubauen.

Beispiele: Alte_Kirche oder Alte_Börse oder Allendorf oder Allendorf(Eder) oder OnkelTom --Alex42 (Diskussion) 21:43, 22. Feb. 2021 (CET)

Es gibt schlicht und einfach keinen Grund, in einem normalen Fließtext <small> für irgendwelche inhaltlichen Aussagen zu verwenden, und es deshalb ersatzlos auf Normalschrift umzustellen ist völlig in Ordnung.

In Tabellen und für die immer gleiche Anleitung des Bots zum Umgang mit als defekt erkannten Weblinks mag das mal angehen.

Rund 10 % unserer Leser, weil schlicht aller Internetnutzer in DACH haben erhebliche Augenprobleme und können dieses Zeugs dann nicht mehr lesen. Zufällige Äußerung; eine von Hunderten ähnlicher Beschwerden.

Und nein, Barrierefreiheit bedeutet nicht, dass man sich erst anmelden und irgendwelche Gadgets installieren solle, um sinnfrei mit <small> versaute Artikel lesbar zu machen, die einem der Nachbar auf dem Smartphone oder Desktop unter die Nase hält; „Barrierefreiheit“ bedeutet, dass dies alles gleich so zu lesen ist, ohne irgendwelche Maßnahmen, jederzeit. Und eine Bildschirmlupe bedeutet, dass man statt 100 Buchstaben in einer Zeile nur 60 darstellen kann, wenn die Bildschirmlupe so eingestellt werden muss, damit auch <small> sichtbar wird.

Im Übrigen ist es sehr schlechter Stil, einen bereits archivierten 60 kB großen Thread aus dem Archiv zu kopieren und ein Wirrwarr in den Versionsgeschichten anzurichten, nur um einen Nachtrag zu anzuhängen, in dem absolut nichts Neues vorgetragen wird. Dann eröffnet man einen frischen Abschnitt und verlinkt auf die bereits abgeschlossen gewesene frühere Diskussion.

Und <small><sup> bedeutet zweifach, im Quadrat die Verkleinerung auf Minimum von Minimum; a^xy und ist schon für gut Sehende eine rücksichtslose Zumutung.

VG --PerfektesChaos 22:46, 22. Feb. 2021 (CET)

@PerfektesChaos: Ich finde das Small-Tag zumindest mal besser als irgendein "font-size:80%" oder so. Das Tag kann ein angemeldeter User mit seiner CSS-Seite - wofür wir hier viel mehr "Werbung" machen sollten, weil sie Streit vermeiden kann - auf eine ihm genehme Skalierung trimmen, eine feste Prozentangabe nicht. ÅñŧóñŜûŝî (Ð) 23:36, 26. Jun. 2021 (CEST)

Über 99 % unserer Leser sind aber nicht angemeldet, und ich wette, dass von den Angemeldeten auch maxmal 1 % in der Lage wäre, sich sein CSS so umzuschreiben, dass die small in normaler Schriftgröße erscheinen.

Barrierefreiheit bedeutet aber, dass alle Leser die ausgelieferte HTML-Seite in jedem ihrer Geräte sofort lesen können, ohne erst speziell für diese Domain in irgendwelchen Add-Ons irgendwelche Nerd-Regeln einzutragen, damit sie eine Wikipedia-Seite entziffern können. Wobei die nachlassende Sehfähigkeit mit dem Lebensalter korreliert und das widerum umgekehrt proportional mit der Begeisterung für Programmieraufgaben stehen soll.

Die Formatierung des small ist vor dreißig Jahren mal gewählt worden, als man noch nichts von Massenkonsum usw. ahnte, und Wissenschaftler ihre Papierdokumente nachahmten. Da sich jetzt aber auch sinnvolle Verwendungen in den Wiki-Seiten darauf verlassen, können wir das auch nicht mal so eben projektweit verändern.

Es gibt keinerlei Grund, wesentliche und relevante Informationen überhaupt zu verkleinern. Deshalb ist im Fließtext gar kein Tag erforderlich, und Ende. Das ist Masche aus überkommener Papier-Ära, als halbe Quadratzentimeter eingespart werden sollten, und für uns nicht relevant.

80% wäre ohnehin viel zu klein, die gebräuchliche Verkleinerung in small liegt bei 77 % bis 85 % und Schriftverkleinerung sollte hingegen maximal 90% betragen. Geht aber viel viel einfacher: Überhaupt nichts als Autor verkleinern, alles Normalschrift, finito. Entweder ist es notwendig, dann ganz normal hinschreiben, oder es ist unwichtig, dann weglassen.

VG --PerfektesChaos 00:19, 27. Jun. 2021 (CEST)

Ooopsi - zu spät gelesen. Weil das bei den von mir gerade im großen Stil überarbeiteten Lerchen völlig uneinheitlich war, habe ich es nun überall gleich gestaltet - nur eben blöderweise so, wie es hier gerade nicht erwünscht wird. Nun habe ich etwas Arbeit vor mir ... :-) --Andreas v. Stackelberg (Diskussion) 23:47, 30. Aug. 2021 (CEST)

Definitionslisten und andere Aufzählungen

Mir ist nicht ganz klar, warum ausgerechnet Definitionslisten fettgeschriebene Begriffe enthalten dürfen, aber andere Listen nicht.

Hier mal ein Beispiel für eine andere Art der Aufzählung von Sachverhalten bzw. Schlagwörtern, die im entsprechenden Abschnitt erläutert werden sollen: Kontrollierte_Wohnraumlüftung#Funktion

Meiner Meinung nach ist an der Verwendung fettgeschriebener Begriffe wie in diesem Beispiel nichts auszusetzen. Im Gegenteil scheint mir diese Art der Formatierung hilfreich zur übersichtlichen Gliederung von Unterabschnitten.

Umseitig lautet die Begründung für die Privilegierung von Definitionslisten:

Definitionslisten können zur Unterscheidung verschiedener Fachbegriffe benutzt werden. Sie sind nicht dafür verwendbar, durch das Semikolon Fettschreibung oder Zwischenüberschriften zu erzeugen, da die Auszeichnung vom Stylesheet abhängig ist.

Dies hilft mir nun gar nicht weiter. Vielleicht könnte mal jemand erläutern, wieso hier behauptet wird, dass das Semikolon keine "Fettschreibung oder Zwischenüberschriften" erzeuge und was eigentlich mit dem letzten Halbsatz gemeint ist.

besten Dank,

Kai Kemmann (Diskussion) - Verbessern statt löschen - 12:44, 25. Jun. 2021 (CEST)

Ich sage es mal so, sicherlich bewirkt das Semikolon am Zeilenanfang zunächst einmal Fettschrift, und zwar bis irgendwo ein zugehöriger Doppelpunkt erkannt und an dem dann eine zugehörige Begriffsdefinition erwartet und umgebrochen wird.

Beispiel

; Irgendetwas mit: Doppelpunkt dazwischen

wird zu

Irgendetwas mit

Doppelpunkt dazwischen

Das Semikolon erzeugt also nicht einfach nur Fettschrift, es hat auch eine, wie soll ich das sagen, „ich erwarte Doppelpunkte“ Funktion.

Das Semikolon erzeugt keine Zwischenüberschriften im Inhaltsverzeichnis = es kann nicht dazu genutzt werden, um Unterabschnitte im Inhaltsverzeichnis zu erzeugen, wie es etwa eine Überschrift der Ebene 3 === Zwischenüberschrift === täte. Sie erzeugt einzig einen Definitionszeilenbegriffskopfeintrag. Den Rest des Halbsatzes kann ich aber nicht genauer erklären. Im Grunde ist es aber, wenn ich es richtig in meiner Erinnerung habe, so, dass diese Zeichen eigentlich als Wiki-Umschrift für diese Tags dienen. Hilfe:Tags#wiki oder HTML <dl> dt dd Tag

<dt>Irgendetwas mit <code>dt-tags</code> erzeugt</dt><dd>und mit <code>dd-tags</code> fortgesetzt</dd><dd>und mit weiteren <code>dd-tags</code> in die nächste Zeile verrückt</dd>

ergibt entsprechend

Irgendetwas mit dt-tags erzeugt

und mit dd-tags fortgesetzt

und mit weiteren dd-tags in die nächste Zeile verrückt

Und ich meine dazu gehört auch noch ein Tag dl (definition list), dt (definition term), dd (definition data). Daher sollte das nicht zweckentfremdet werden. --Liebe Grüße, Lómelinde Diskussion 13:18, 25. Jun. 2021 (CEST)

Zur Ausgangsfrage, warum fettgeschrieben:

• Die Definitionsliste, mittlerweile alternativ auch Beschreibungsliste, stammt von etwa 1992.
• Damals war das Design dieser Listen so üblich. Das haben alle Browser der 1990er und 2000er gleichartig so umgesetzt. Mittlerweile garantiert die MediaWiki-Software dieses Erscheinungsbild.

Es handelt sich um eine Liste semantischer Zuordnungen, die je einem Term eine definition/description oder auch deren mehrere zuordnen.

• „was eigentlich mit dem letzten Halbsatz gemeint ist“ – das ist damit gemeint. Es geht um derartige Zuordnungen und nicht um das optische Erscheinungsbild, das im Prinzip egal ist.
• Heißt in Konsequenz: Es ist ungültige Syntax und wird auch seit Jahren angemeckert, wenn nur der Term→ ohne zugehörige Beschreibung angegeben wird, weil die Zuordnung dann unvollständig ist.

Die herausgehobenen Begriffe wirken als eine Art Unter-Überschriften, die kleine Abschnitte mit der Definition oder Erklärung einleiten.

• Deshalb ist es auch legitim, derartige Mini-Überschriften in Fettschrift darzustellen.

Das Erscheinungsbild ist aber nirgendwo standardisiert.

• Es gibt keinerlei Garantie, dass
  1. der Begriff in Fettschrift präsentiert wird,
  2. die Definition oder Erklärung eingerückt sein muss.
• Auf einigen Mobilgeräten der letzten Jahre wurde das Semikolon=<dt> nicht mehr in Fettschrift dargestellt, weshalb die MediaWiki-Software das zurzeit garantiert.
• Es ist aber langfristig den Browsern und zukünftigen Designkonzepten überlassen, auf welche Weise verdeutlicht wird, dass eine Zuordnung Term→Beschreibung besteht.

VG --PerfektesChaos 17:51, 25. Jun. 2021 (CEST)

Besten Dank für Eure Erläuterungen.

Aber, puh, das ist ja ein ganzes Bündel von Bezügen und vorausgegangenen Entwicklungen, die beim Umgang mit ; und : zu berücksichtigen sind.

Nicht ganz klar ist mir, warum es hier "langfristig den Browsern und zukünftigen Designkonzepten" überlassen werden müsste, wie die Darstellung der Formatierung vorgenommen wird, wenn diese doch inzwischen von der MediaWiki-Software übernommen wird. Sollte zukünftig eine andere Darstellung gewünscht werden, so läge es doch dann in der Hand der MediaWiki-Programmierer, eine angemessene Umsetzung und Anpassung projektweit zu implementieren. Oder spielen "externe Stylesheets" dann dennoch eine Rolle?

Und angenommen, entweder die Fettschreibung oder die Einrückung würden eines Tages entfallen, so würde doch immer noch das jeweils andere Merkmal verbleiben (oder durch eine alternative Kennzeichnung ersetzt werden), um die Begriffe ("Definitionen") als eine Art "Zwischenüberschrift niederster Rangordnung" erkennbar zu machen.

Ich würde beim umseitigen Hinweis den Begriff "Zwischenüberschrift" darum vielleicht durch "Unterabschnitt" ersetzen oder das ganze vielleicht gleich so formulieren:

Definitionslisten dieser Art können zur knappen Auflistung von Sachverhalten oder Schlagwörtern genutzt werden. Für längere Ausführungen zu den jeweiligen Punkten sollten reguläre Überschriften der Ebene 2 bis 6 verwendet werden, die auch den Vorteil haben, im Inhaltsverzeichnis zu erscheinen. Das Semikolon steht jeweils vor dem Schlagwort bzw. der Bezeichnung des zu erläuternden Sachverhalts. Unmittelbar anschließend oder in der nächsten Zeile soll grundsätzlich immer ein Doppelpunkt folgen, der den erläuternden Text einleitet.

Damit alle Leser der Hilfeseiten in den Genuß Eurer Hintergrundinformationen kommen, könnte als Fußnote vielleicht noch etwas in dieser Art hinzugefügt werden:

<ref>Die graphische Formatierung dieser sogenannten ''Definitionsliste'' (zur Zeit ''Fettschrift mit nachfolgender Einrückung'') kann sich zukünftig ändern. Ohne den Doppelpunkt ist die Syntax unvollständig, was unter Umständen zu Komplikationen führen kann.</ref>

beste Grüße,

Kai Kemmann (Diskussion) - Verbessern statt löschen - 05:09, 1. Jul. 2021 (CEST)

PS: Ich verstehe jetzt das im obigen Abschnitt Hilfe_Diskussion:Textgestaltung#Absätze_funktionieren_-_oder_manchmal_auch_nicht. angesprochene Problem: Wurden bei meinem Eintrag vom 25. Juni die doppelten Zeilenumbrüche noch als Leerzeilen dargestellt, so ist dies beim soeben verfassten Text nicht mehr der Fall. Egal wieviele Zeilenumbrüche ich fortlaufend hintereinander einfüge, wird der gesamte Text als fortlaufender Block dargestellt. Auch vor dem Zeilentext eingefügten Leerzeichen erzeugen nicht mehr den hellgrau unterlegten Kasten. (Obwohl der Quelltext vom 25. Juni analog formatiert ist, wird dieser nach wie vor korrekt dargestellt! Versuchsweise vor Lomelindes Beitrag nachträglich eingefügter Text wird in der Vorschau korrekt formatiert. Nach Lomelindes Eintrag aber nicht mehr. Was ist denn da los?) Lediglich die Doppelpunkte funktionieren noch und erzeugen die gewohnte Einrückung:

Mal sehen, ob sich dass vielleicht von selber wieder bereinigt ...

Kai Kemmann (Diskussion) - Verbessern statt löschen - 05:15, 1. Jul. 2021 (CEST)

nachträgliches PPS: Ich habe meinen obigen Beitrag nun noch einmal nachformatiert, um ihn leserlich zu machen. Doch es bleibt dabei: Zwischen Lomelindes erstem und zweiten Beitrag werden Zeilenumbrüche merkwürdigerweise nicht zu Leerzeilen umgesetzt und das Leerzeichen am Zeilenanfang erzeugt keine grau hinterlegte Textbox. Die Abgrenzung zwischen meinen "PS"-Beiträgen sowie zu Lomelindes folgendem Text musste ich mit {{Absatz}} herstellen. Das wäre sonst als fortlaufender Text angezeigt worden. An meinem obigen "PS"-Absatz ist das Problem zu erkennen. Davor und danach funktioniert alles wie gewohnt. Oder stellt sich das bei Euch anders dar?
Kai Kemmann (Diskussion) - Verbessern statt löschen - 16:53, 4. Jul. 2021 (CEST)

Na dann verstehe ich jetzt erst was in dem Abschnitt (Absatz funktioniert nicht) gemeint war.

Absätze zwischen den Zeilen	Syntax	Auswirkung
Text am Zeilenanfang + 2 × ↵	Text am Zeilenanfang + 2 Zeilenumbrüche Weiterer Text	Text am Zeilenanfang + 2 Zeilenumbrüche Weiterer Text
Es entsteht ein sichtbarer Absatz (Lücke zwischen den Texten)
Text am Zeilenanfang + <br />	Text am Zeilenanfang<br />Weiterer Text Text am Zeilenanfang<br /> Weiterer Text	Text am Zeilenanfang Weiterer Text Text am Zeilenanfang Weiterer Text
Es entsteht kein sichtbarer Absatz (der Text wird lediglich zum Zeilenanfang zurückgeschoben)
mit Doppelpunkten oder * # Aufzälungszeichen vor den Text + 2 × ↵	: Eingerückter Text : Eingerückter Text : Eingerückter Text : Eingerückter Text * Aufzählungen Text * Aufzählungen Text * Aufzählungen Text * Aufzählungen Text	Eingerückter Text Eingerückter Text Eingerückter Text Eingerückter Text Aufzählungen Text Aufzählungen Text Aufzählungen Text Aufzählungen Text
Es entsteht ein minimal größerer (bei Doppelpunkten) oder (bewusst) kein Abstand zwischen den Einträgen
mit Doppelpunkten oder * # Aufzälungszeichen vor den Text + 3 × ↵	: Eingerückter Text : Eingerückter Text : Eingerückter Text : Eingerückter Text * Aufzählungen Text * Aufzählungen Text * Aufzählungen Text * Aufzählungen Text	Eingerückter Text Eingerückter Text Eingerückter Text Eingerückter Text Aufzählungen Text Aufzählungen Text Aufzählungen Text Aufzählungen Text
Es entsteht ein sehr deutlicher aber viel zu großer Abstand zwischen den Einträgen
mit Doppelpunkten oder * # Aufzälungszeichen vor den Text + <br /> angehängt	: Eingerückter Text : Eingerückter Text<br /> : Eingerückter Text * Aufzählungen Text * Aufzählungen Text<br /> * Aufzählungen Text	Eingerückter Text Eingerückter Text Eingerückter Text Aufzählungen Text Aufzählungen Text Aufzählungen Text
Es entsteht kein Abstand zwischen den Einträgen das angehängte <br /> ist hier wirkungslos und kann entfallen
mit Doppelpunkten oder * # Aufzälungszeichen vor den Text + <br /> innerhalb	: Eingerückter Text : Eingerückter Text<br />Eingerückter Text * Aufzählungen Text * Aufzählungen Text<br />Aufzählungen Text	Eingerückter Text Eingerückter Text Eingerückter Text Aufzählungen Text Aufzählungen Text Aufzählungen Text
durch das <br /> innerhalb der Aufzählung wird ein Text ebenso eingerückt, jedoch ohne weiteres Aufzählungszeichen dargestellt
mit Doppelpunkten oder * # Aufzälungszeichen vor den Text + 2× <br /> innerhalb	: Eingerückter Text<br /><br /> : Eingerückter Text<br /><br />Eingerückter Text * Aufzählungen Text<br /><br /> * Aufzählungen Text<br /><br />Aufzählungen Text	Eingerückter Text Eingerückter Text Eingerückter Text Aufzählungen Text Aufzählungen Text Aufzählungen Text
Hier entsteht wieder ein recht großer eher störender Abstand

Mehr Beispiele fallen mir gerade nicht ein. Man erkennt aber, dass sich die einrückenden Doppelpunkte anders verhalten, als normale Aufzählungen mit * oder #. --Liebe Grüße, Lómelinde Diskussion 07:44, 1. Jul. 2021 (CEST)

+1 zu Ló, danke dafür, und nochmals konkret:

Umseitig steht eine knappe übersichtliche Darstellung, was gemacht werden soll und was nicht gemacht werden soll. Für sehr viele Syntaxelemente. Ausschweifende tiefschürfende philosophische glaskugelnde Anmerkungen zu einzelnen Syntaxelementen sind umseitig absolut fehl am Platz.

Die Bedeutung von ; ist: Hier steht ein Begriff, der gleich erläutert werden wird. Die Bedeutung von : ist: Hier steht eine Erläuterung zu dem vorgenannten Begriff.

Die Bedeutung von ; ist nicht: Hier steht eine neue Zeile, die in Fettschrift dargestellt wird. Die Bedeutung von : ist nicht: Hier steht eine neue Zeile, die eingerückt dargestellt wird.

Die Darstellung unterliegt Moden und kann sich nach Zeitgeschmack und auf unterschiedlichen Geräten ändern.

• Die derzeitige Mode geht auf Wissenschaftler von 1992/1994 zurück, denen das so gefiel.
• Smartphones ab 2010 ließen die Fettschrift weg; das geht genausogut auch ohne und ist weniger aufdringlich. Fettschrift ist nicht mehr Mode.
• Einrückung ist auf Smartphones unbeliebt weil platzraubend. Einrückung ist nicht mehr Mode.
• Es ist aber noch nicht einmal erforderlich, dass Begriff und Erläuterung auf einzelnen eigenen Zeilen stehen. Browser könnten auch darstellen:
  • Begriff → Erläuterung
  • Begriff?
    Nach Anklicken des Fragezeichens öffnet sich ein Pop-Up-Fenster, in dem die Erläuterung angezeigt wird.

Diskussionsseiten wie diese hier, die den Doppelpunkt zum Einrücken missbrauchen, sind heute schon auf Smartphones unlesbar und werden eines Tages wohl von der Wiki-Software nur noch als lineare Liste von signierten eingerahmten Chat-Beiträgen ohne Einrückung dargestellt werden; ggf. alles, was Doppelpunkt ohne vorheriges Semikolon hätte.

--PerfektesChaos 09:41, 1. Jul. 2021 (CEST)

Danke für Eure geduldigen Erläuterungen.

Ich habe gerade einmal nachgesehen: Auf dem iPhone wird sowohl vom Opera Browser, wie auch von Safari auf Diskussionsseiten die Einrückungen per Doppelpunkt wie auch Fettschrift per Semikolon wie üblich dargestellt. Die entsprechenden Formatierungen, die Lomelinde oben mit dt- und dd-Tags umsetzte, wird auf dem Mobiltelefon jedoch offenbar ignoriert, während sie auf dem Macintosh Safari Browser sichtbar ist.

Spricht das nun dafür, dass die Media-Wiki Software für eine einheitliche Darstellung sorgt oder nicht? Ich habe das offenbar immer noch nicht verstanden ..

Die durchaus interessanten Erläuterung der Hintergründe im Stil von ".. semantischer Zuordnungen, die je einem Term eine definition/description oder auch deren mehrere zuordnen .." sind mit leider zu abstrakt, um daraus herleiten zu können, ob, wann und wozu ich Semikolon und Doppelpunkt verwenden sollte bzw. darf.

Und wieso dies von einem mit unbekannten Stylesheet abhängen sollte, ist mir bis dato auch noch nicht klar geworden. Stylesheet ist zwar umseitig auf Stylesheet-Sprache verlinkt, doch dieser aus vier Sätzen bestehende Artikel hilft mir da irgendwie auch nicht weiter.

Aufschlussreicher wäre es da schon, auf unsere kleine Diskussion hier zu verweisen. Deren Inhalt wird den unbedarften Nutzer zwar sicherlich noch mehr verwirren, doch weiß er dann wenigstens, dass er sich mit dem Gebrauch von Semikolon und Doppelpunkt in Gefilde begibt, die für Normalsterbliche nicht zu navigieren sind, und dass er geduldig abwarten möge, bis er schließlich einmal an dem Punkt seines Lebens angelangt ist, an dem er eine Definitionsliste anzulegen wünscht, anläßlich dessen dann die Anwendung der Semikolon-Doppelpunkt-Auszeichnung tatsächlich offiziell sanktioniert wäre.

Nur noch eine letzte Frage, bevor ich Ruhe gebe: Nach dem bisher Gelernten gehe ich davon aus, dass Kowsalat mit dem Ersatz des Semikolons durch gewöhliche Fettschreibung hier richtig gehandelt hat, obwohl der Gebrauch von Fettschreibung außerhalb von Lemma, Weiterleitungszielen und eben Definitionslisten eigentlich nicht vorgesehen ist ...

Im Grunde sind mir solche Feinheiten in den Richtlinien relativ egal, solange es möglich bleibt, Texte schön übersichtlich zu strukturieren. Aber die Erfahrung zeigt ja, dass es immer mal wieder Mit-Autoren gibt, denen die Regelhuberei wichtiger ist, als die Lesbarkeit und nachvollziehbare Gliederung des Textes.

Vielleicht sollten wir in diesem Zusammenhang überlegen, ob umseitig evtl. eine Liste wie die bereits zitierte als Beispiel dargestellt werden sollte, um

1. eine Möglichkeit darzustellen, eine knappe Auflistung von Sachverhalten zu realisieren, die wohl nicht als typische Definitionsliste angesehen werden kann, aber aufgrund des begrenzten Inhalts auch nicht in den Rang einer regulären Zwischenüberschrift (samt Eintrag ins Inhaltsverzeichnis) erhoben werden soll und
2. eine Alternativ zur (offenbar) fehlerhaften aber häufig praktizierten Anwendung der Definitionslisten-Formatierung aufzuzeigen.

beste Grüße,

Kai Kemmann (Diskussion) - Verbessern statt löschen - 16:53, 4. Jul. 2021 (CEST)

Nein, umseitig steht eine klare einfache Handlungsanweisung in einer sehr kompakten Übersicht aller elementaren Formatierungsmöglichkeiten.

• Nein, wir machen dort keinerlei weitere Anmerkungen und wir verweisen nirgendwohin zusätzlich.
• Und gleich gar nicht wird von irgendeiner Vorderseite in diesen verworrenen Diskussionsabschnitt verlinkt werden, mit momentan 21 kB.
• Und nein, umseitig gibt es hinreichend viele leicht verständliche Beispiele, und alles was noch hinzukäme macht die Angelegenheiten für alle anderen außer dir unnötig kompliziert.
• Sobald auf irgendeiner Hilfeseite mehr steht als unbedingt erforderlich, kann ich sehr genau vorhersagen, wer der allerallererste sein wird, der angerannt kommt und sich bitterlich darüber beklagt, auf der Hilfeseite würde viel zu viel stehen und sie wäre viel zu unübersichtlich und man könne sich da überhaupt nicht mehr durchfinden und würde nichts finden können und das müsse unbedingt gekürzt und alles ganz doll vereinfacht werden.
• Das Verhalten von HTML-Browsern ist auf allen Mobilgeräten gleich; zumindest was ausgeliefertes CSS anginge. Du verwendest jedoch möglicherweise irgendwo die Wiki-App, und die ist wieder was anderes.
• Und es ist für die Vorderseite auch völlig egal, ob du begreifst wie und warum CSS funktioniert und welchen Einfluss das auf die Darstellung bei den Lesern hätte.
• Schließlich war auf Spezial:Diff/205341457 der Ersatz von kastrierten Definititionslisten durch explizite Fettschrift absolut korrekt und auch im Sinne von Hilfe:Überschrift #notoc. Die Behauptung, überall in einer Wiki-Seite wäre Fettschrift verboten, außer für Lemma und WL-Ziele, ist Nonsens. Die fragliche Regel bezieht sich auf die Verwendung von Fettschrift zur Hervorhebung im Fließtext, also einzelne Wörter mitten in einem Satz. Abschnittsüberschriften stehen weitaus überwiegend in Fettschrift, Spaltenüberschriften von Tabellen ebenso, die Terme von Definitionslisten desgleichen. Oder der Kopfbereich einer Infobox.

VG --PerfektesChaos 18:44, 4. Jul. 2021 (CEST)

Danke

• Der Vorschlag, auf diese Diskussion zu verweisen, war eher ironisch gemeint.
• Ich übermittle gerne ein Bildschirmfoto meiner Mobiltelefon Opera- und Safari-Browserfenster wenn das von Interesse ist. Von einer Wikipedia-App habe ich mal gehört, verwende sie jedoch nicht. Ich kann mir eigentlich auch nicht vorstellen, dass diese die Darstellung des mobilen Browsers beeinflussen würde.
• Von einem Verbot habe ich nicht gesprochen. Ich sagte vielmehr ".. eigentlich nicht vorgesehen ..". Die genaue Regel zur Fettschreibung lautet umseitig:

(bitte sparsam verwenden – in der Regel nur für das Artikelstichwort in der Einleitung und für Weiterleitungsziele vorgesehen)

.. und wie wir wissen hält man sich in der Deutschen Wikipedia an die Regeln - und zwar sogar dann, wenn diese mit der Formulierung "in der Regel" zu einer weichen Regel abgeschwächt wurde. Von Fließtext ist da nicht die Rede ..

• Vielen Dank für den Hinweis auf Hilfe:Überschrift#notoc. Das ist ja genau das, was ich meinte.

Besonders hilfreich sind die dortigen Erläuterungen natürlich, wenn auch an den richtigen Stellen darauf hingewiesen wird, also auf den Hilfeseiten, die sich mit der Textgliederung befassen.

Wenn Du Hilfe:Textgestaltung als inhaltlich abgeschlossen und nicht erweiterbar ansiehst, so läge es nahe, zumindest etwa in Wikipedia:Formatierung darauf hinzuweisen. Vielleicht so:

Durch Fettschreibung kann auf einfache Weise eine Überschrift eingefügt werden, die dann nicht im Inhaltsverzeichnis auftaucht. Siehe auch Hilfe:Überschrift#notoc

Das klingt zugegebenermaßen banal, doch hat die übliche Art und Weise, Überschriften mittels Gleichheitszeichen einzufügen, mein naives Köpfchen bislang davon abgelenkt, andere (naheliegende) Möglichkeiten überhaupt in Betracht zu ziehen ...

Zugleich entdecke ich in Hilfe:Überschrift#notoc gleich auch eine etwas verständlichere Erklärung dafür, warum Semikolon und Doppelpunkt nicht auseinandergerissen werden sollten.

Wäre umseitig statt auf die wenig hilfreiche "Auszeichnung vom Stylesheet" (auch der Begriff 'Auszeichnung' sagt mir übrigens nichts ..) direkt auf Hilfe:Überschrift#notoc verwiesen worden, so wäre ein Teil meiner Fragen wohl schon beantwortet gewesen.

• Und nun doch nochmal ein Nebenthema:

Wäre es nicht sinnvoll, wenn die vielgescholtene Foundation ihre Mittel auch zur Verbesserung der Hilfeseiten und anderer grundlegender Seiten wie Wikipedia:Richtlinien einsetzte? Das wäre doch hilfreicher und einleuchtender als die absurd und aufgeblasen erscheinenden Kampagnen zur Umbenennung, Gestaltung der allgemeinen 'Corporate Identity' und Erarbeitung irgendwelcher übergeordneter Leitideen in jahrelangen Prozessen ..

Dir persönlich hat die deutsche Wikipedia in diesem Bereich mehr zu verdanken, als irgendeiner anderen Person. Ich fände es überfällig, dass Deine immense Arbeit auch durch die Schaffung einer entsprechenden Stelle materiell (und immateriell) honoriert würde. Relativ zu uns 'gewöhnlichen Autoren' hast Du ja wohl eine klare Sonderstellung bezüglich der Aufrechterhaltung und Weiterentwicklung der Strukturen und bist wohl kaum so einfach zu ersetzen.

Sinnvoll wäre aber zusätzlich auch ein Gegenpart, der vielleicht eher eine sprachliche als technische Vorbildung besitzt und die bestehenden Texte einmal auf ihre Laienverständlichkeit hin überprüft und entsprechende Verbesserungen erarbeitet.

Falls Du das auch so siehst, wer wäre denn wohl der richtige Ansprechpartner, um einen solchen Vorschlag zu unterbreiten. Ich kenne mich mit den personellen Strukturen gar nicht so aus ..

beste Grüße,

Kai Kemmann (Diskussion) - Verbessern statt löschen - 15:30, 5. Jul. 2021 (CEST)

Abschnitt "Formatierungen, die nicht...", 1.Satz mit Fehler

@ PerfektesChaos
Im Abschnitt "Formatierungen, die nicht in Wikipedia-Artikeln verwendet werden sollten" ist der Schlussteil des ersten Satzes [vermutlich/möglicherweise/wahrscheinlich] verstümmelt: "...; möglicherweise technisch veraltet sind." Der mit Semikolon abgetrennte Satzteil soll vermutlich mit "oder..." an den vorhergehenden Teil angehängt werden, was dann - wohl - so aussehen sollte:

Folgende Formatierungen sollten im Artikelnamensraum im Normalfall nicht verwendet werden, da sie die Leserlichkeit stören (...), in diesem Zusammenhang unsinnig sind (...), einen formal-semantisch falschen Code (...) erzeugen oder möglicherweise technisch veraltet sind. 

.. wenn es denn dann so richtig ist. rät --Ruediger (nicht signierter Beitrag von 2001:67C:2D50:0:2058:2817:A949:DEEC (Diskussion) 06:07, 12. Jul. 2021 (CEST))

Steue (Diskussion) 16:13, 5. Jul. 2022 (CEST)

Siehe auch

Innerhalb eines Artikels kann man drei Seiten als Link innerhalb der Formatvorlage "Siehe auch:" hinzufügen. Wie ist die Vorgabe der gegebenen Formatvorlage zu verändern?

Grüße,

--PAidn (Diskussion) 15:03, 12. Jan. 2022 (CET)

Was genau meinst du mit verändern? Die Vorlage soll maximal drei Einträge anbieten. Ansonsten verweise ich mal auf Wikipedia:Assoziative Verweise. --Liebe Grüße, Lómelinde Diskussion 15:46, 12. Jan. 2022 (CET)

Warum soll sie? Würde man sie und die Vorlagenseite jeweils umschreiben, dann dürfte man es ändern? Oder zur Änderung vorschlagen? --PAidn (Diskussion) 16:32, 12. Jan. 2022 (CET)

Man soll nicht wahllos alles mögliche als „siehe auch“ verlinken, dafür habe ich dir doch den Link gesetzt. Zitat: „Assoziative Verweise sollten sparsam eingesetzt und, wenn möglich, in den Fließtext integriert oder in Listen mit klarem Bezug umgewandelt werden.“ Was ist daran jetzt nicht zu verstehen. Ich vermute mal aus diesem Grunde ist die Vorlage auf wenige (3) Einträge begrenzt, ändern kann man das, aber das müsstest du an einem anderen Ort ansprechen. Das ganze hat eigentlich sehr wenig mit der Hilfeseite zur Textgestaltung zu tun, siehe den Einleitungssatz: „Diese Seite erklärt, wie du in Wiki-Syntax Überschriften, Listen und Absätze erzeugst und Textstellen formatierst“. Entweder auf WD:Assoziative Verweise oder auf Vorlage Diskussion:Siehe auch ansprechen. Hier bist du jedenfalls falsch. --Liebe Grüße, Lómelinde Diskussion 18:05, 12. Jan. 2022 (CET)

Größen und Einheiten

In technischen Dokumenten gilt die Regel:

It is not permitted to modify a unit symbol (e.g. by means of a subscript) to give information about the special nature of the quantity or context of measurement.

EXAMPLE 1 
Correct: U_max = 500 V 
Incorrect: U = 500 V_max 

vgl. ISO/IEC Directives, Part 2: Principles and rules for the structure and drafting of ISO and IEC documents, Ed. 9.0, 2021-05, 9.3.2 Units, S. 32. Genaueres kann man in der Normenserie ISO/IEC 80000 Quantities and units nachlesen. [4]

Es geht also darum, dass man z.B. bei einer KWK-Anlage nicht schreibt: Leistung: 50 kW_el und 80 kW_th, sondern die Größen entsprechend benennt, also elektrische Leistung P = 50 kW; thermische Leistung Q' = 80 kW.

Gibt es eine passende Stelle, wo dieser Zusammenhang von den Wiki-Stilrichtlinien aufgegriffen wird?

ISO und IEC schreiben die Direktiven gemeinsam, die nicht nur die Autoren von technischen Normen anleitet, sondern auch die formalen Qualitätschecker vor Veröffentlichung einer Norm. Damit halten sich technische Regeln von ISO und IEC und davon abgeleiteten Organisationen wie CEN und CENELC oder auch DIN und DKE, die den selben Regelsatz zur Erstellung von technischen Dokumenten nutzen, an diese Vorgaben. Ich weiss nicht, warum es dazu kam, glaube aber, dass Einheiten eine heilige Kuh sind, bei denen man keine Modifikationen am Symbol zur Vermeidung von Missverständnissen bei Vertragsabschlüssen zulassen möchte. --Gunnar (Diskussion) 13:08, 28. Aug. 2023 (CEST)

Also, auf dieser Diskussionsseite bist du leider falsch, weil hier geht es um Wikisyntax und nicht um inhaltliche Fragen.

Dann ist die Wikipedia eine laienverständliche Aufbereitung und keine fachwissenschaftliche Abhandlung; wir orientieren uns im Zweifelfall an alltagstauglichen und in normalen Texten üblichen Darstellungen, wenn es um Alltagsrealitäten geht, etwa die Informationen über einen Pkw. Atomphysik und Biochemie sind wieder was anderes. Irgendwelche ISO und DIN und EN und IEC und VDE sind für uns nicht verbindlich; wir reichen keine Dissertation ein.

Nebenbei sind die historischen Notationen vorrangig, wenn historische Vorgänge erörtert werden.

Im Zweifelsfall sind unsere Fachredaktionen etwa zur Physik einschlägig.

In Sachen Allgemeinverständlichkeit würde ich es bei der Darstellung eines AKW bevorzugen, wenn die Informationen in der allgemeinen Beschreibung im Klartext benannt werden. Bei Platzmangel (Spaltenüberschriften von Tabellen) darf aber nach entsprechender Legende auch die Index-Formatierung benutzt werden.

„Stilrichtlinien“ für deine Anfrage gibt es eher nicht.

VG --PerfektesChaos 13:58, 28. Aug. 2023 (CEST)

Monospace: Text mit fester Zeichenbreite

Ich habe eine Frage bezüglich monospace-Text. Ich habe schon länger das Bedürfnis, die alten <tt>-Tags irgendwie zurückzubekommen, weil mir oft ein Wort zwar mit fester Zeichenbreite als das richtige erscheint, die Verwendung von z. B. <code> aber nicht passt und für mich den Lesefluss eher unterbricht. Das liegt auch daran, wie man hier gerade sehen kann, dass <code> durch die Box um den Text den Fließtext aufdringlicher „zerschneidet“ als es das alte <tt> tat. Das kann man beispielsweise mit <span style="font-family: monospace, monospace;"> wieder bekommen, womit man z. B. ein <tt>-Tag im Fließtext bekommt. Bei einem Tag ist das natürlich nicht wirklich sinnvoll, denn es ist immer Code. Aber wie sieht es z. B. bei cmd.exe aus? Sollte es nicht cmd.exe sein, weil das in fast allen Büchern, die ich zum Thema kenne, als Kommando ebenfalls in monospace verwendet wird, da es sich bei cmd.exe, wie bei command.com und fdisk, um Namen handelt, die 1:1 den Kommandos entstammen? Auch liest es sich meiner Meinung nach schöner bei Pfaden, vor allem, wenn sie im Fließtext genutzt werden: das /tmp-Verzeichnis vs. /tmp-Verzeichnis. Oder ohne Monospace, als das /tmp-Verzeichnis?

Ich habe das lange Zeit ignoriert und entweder normalen Text verwendet, oder ich habe versucht, es mit <code>-Tags darzustellen. Die Ergebnisse sind jedoch immer unzureichend. Hinzu kommt, dass das jeder Autor in der Wikipedia anders macht. Und so gibt es einen gewissen Wildwuchs, und jeder Artikel sieht anders aus.

Kürzlich habe ich mir dann doch gedacht, WP:Sei mutig, und habe einfach mal etwas erstellt, und zwar die Vorlage:Monospace. Nur um dann postwendend zwei Dinge festzustellen:

1. Die Vorlage gibt es in ganz vielen Sprachversionen bereits. Siehe dazu das zugehörige Datenobjekt von Wikidata, d:Q18123834.
2. Meine Verwendung in Artikeln wurde sofort wieder rückgängig gemacht.

Das führt mich dazu, nach einer Diskussion hier – die es hoffentlich geben wird – eine von zwei alternativen Vorgehensweisen zu planen:

• Entweder die Vorlage:Monospace ist berechtigt, dann darf man sie auch verwenden.
• Oder, die Vorlage:Monospace ist eben nicht berechtigt, dann werde ich einen WP:Löschantrag stellen. Denn dann ist sie ja sinnlos.

Im ersten Fall kann ich auf diese Diskussion verweisen, und die Vorlage folgerichtig in Artikeln auch verwenden.

Im zweiten Fall muss ich alles, was jetzt mit <span style="font-family: monospace, monospace;"> in Artikeln steht, ebenfalls hinterfragen. Und, je nachdem, konsequent entweder durch <code> ersetzen, oder es wird eben nicht mit fester Breite geschrieben.

Diskussionen, die ich bereits versucht habe, und wo bis jetzt niemand etwas dazu geschrieben hat:

1. Benutzer Diskussion:Y2kbug#Vorlage:Monospace
2. Vorlage Diskussion:Monospace#Zeichenbreite oder Schriftart?

Und das wichtigste zum Schluss: laut der Regelung auf dieser Hilfeseite, Hilfe:Textgestaltung, Abschnitt #Formatierungen, die nicht in Wikipedia-Artikeln verwendet werden sollten, soll keine andere Schriftart festgelegt werden. Allerdings, und das ist mein Argument hier: es geht nicht um die Schriftart, sondern um die Zeichenbreite. Gerade im Computer-Umfeld ist es vielfach üblich, Kommandos, Pfade und ähnliches in einer Schrift mit fester Zeichenbreite (=Monospace) darzustellen – und zwar auch dann, wenn es nicht explizit Code ist.

Da ich jedoch definitiv nicht darauf bestehe, und da es mir um Einheitlichkeit geht, würde ich hier gerne einen Konsens herstellen. Ich habe kein Problem damit, wenn wir das in Zukunft komplett unterlassen. Computer-Artikel lesen sich für mich dann zwar etwas schwerer, aber okay. Soll so sein.

In der Hoffnung auf eine echte Diskussion, ‣Andreas•⚖ 17:29, 22. Mai 2024 (CEST)

Nun ja für mich ist dafür (also Computerumfeld) genau das Tag code gedacht. Bei uns gibt es etliche Vorlagen nicht die du in der en:WP oder anderen Sprachversionen finden kannst. Dort gibt es Dinge wie {{'}} was als ’ verwendet wird, bei uns aber die Vorlage {{'}} mit ganz anderer Wirkung erwartet. Nicht alles, was andere Wikiprojekte verwenden, müssen wir hier übernehmen. Insbesondere bei Kommandos sehe ich keinerlei Vorteil, auf die code-Tags zu verzichten und diese zu ersetzen, siehe auch Hilfe:Tags#code. Für alle anderen Seiten, also nicht im Artikelbereich lässt sich aber auch die Vorlage {{Hilfe/tt}} einsetzen, die sogar Textblöcke formatieren kann.

Ein Textblock
mit einem Zeilenumbruch

Einrückung

• Aufzählung

1. nummerierte Aufzählung

Sie darf allerdings dann nicht selbst in einer Einrückung oder Aufzählung stehen, wenn sie einen Block umschließt, eingerückter Text in monospace ist nur inline möglich. Im Grunde ist sie also fast identisch zu deiner neuen Vorlage. Ich sollte sie damals aber bewusst unter dem Namen so anlegen, damit sie nicht in Artikeln verwendet wird, daher steht sie auch in der Kategorie:Vorlage:Formatierungshilfe nicht für Artikel. Es wäre also eine Art Konkurrenzprodukt. Also zwei Vorlagen die quasi fast das selbe tun, nur eben eine für den Artikelbereich und die andere für alle anderen, wie sinnvoll wäre denn das? --Liebe Grüße, Lómelinde Diskussion 19:43, 22. Mai 2024 (CEST)

Danke für die Antwort!

Ja, in anderen Sprachversionen gibt es natürlich Vorlagen, die bei uns keinen Sinn ergeben.

Ich habe natürlich auch gelesen, dass <code> der Nachfolger von <tt> ist (hier: Hilfe:Tags#code).

Wenn das so bleibt, wie soll ich dann mit cmd.exe, COMMAND.COM, IO.SYS, MSDOS.SYS usw. verfahren? Auch Fdisk wäre für mich schon länger ein Kandidat, die Form hin zu fdisk zu ändern, nicht zu fdisk. Man könnte das Programm natürlich auch Fdisk (als Hauptwort) nennen... All das kommt von DOS, und der Name ist eben von fdisk.com (einer Datei, und als Dateiname eben mit <code> formatiert) abgeleitet. Als Name verwendete ich bisher nicht gerne Code. Code ist für mich für einen Dateinamen, einen Pfadnamen, ein Stück Code usw. reserviert. Und Pfadnamen haben es auch so insich: sind sie als Teil eines Kommandos, einer Konfigurationsdatei u.d.gl. gemeint, würde ich definitiv <code> verwenden. Sind sie jedoch als Benennung, "als Name", im Fließtext, würde ich das nicht. Eine proportionale Schrift ist dafür jedoch dennoch unüblich. Leichter liest es sich für jemanden aus dem Computerbereich, wenn hier eine nichtproportionale Schrift (also monospace) verwendet wird, aber eben nicht <code>.

Soll wirklich jedes cmd.exe in cmd.exe geändert werden? Überall? Ist das nicht störend? Und wenn nicht, warum mal so, mal so?

Ein Beispiel, wo ich nicht <code> verwendet habe, ist der Filesystem Hierarchy Standard – hier zum Vergleich eine alte Version von 2017 ohne Monospace. Ich finde, dass man Kommandos und Pfade eben nichtproportional schreiben sollte. Aber alles mit <code> vollzupflastern, das stört mehr als es bringt – meiner Wahrnehmung und Meinung nach, versteht sich.

Nachtrag: ein anderes Beispiel ist Liste von DOS-Kommandozeilenbefehlen. Sollen die DOS-Kommandos auch alle mit <code> zugepflastert werden? Oder einfach in proportionaler Schrift, und das passt dann schon so? (Mich stört es...) ‣Andreas•⚖ 21:10, 22. Mai 2024 (CEST)

Wenn Vorlage:Hilfe/tt nicht für den Artikel-Namensraum gedacht ist, und <span style="font-family: monospace, monospace;"> nicht verwendet werden sollte, und <code> der Nachfolger von <tt> ist, dann kann ich meinen Löschantrag für Vorlage:Monospace gleich stellen.

Sieht denn sonst keiner den Bedarf dieser Vorlage?

‣Andreas•⚖ 21:02, 22. Mai 2024 (CEST)

Bitte nicht die Zuversicht verlieren. Neue Dinge sind nunmal, vor allem wenn sie (Anderen) erstmal unverständlich erscheinen, immer irgendwo bäh, so in der Art, was der Bauer nicht kennt, das frißt er nicht. Aus meiner Sicht ist bei dieser Vorlage aber schon dadurch ein deutlicher Vorteil ersichtlich, daß dieses aufgeblähte span style="font-family: … schon bei einer einzigen Verwendung (im HER oder HNR/ANR, und erstrecht bei mehrfachen Verwendungen, wie bspw. dort, am Eintrag zur cmd.exe, und deutlicher dort, am Eintrag zum [DOS-]BIOS) deutlich eingedampft wird (und das ursprünglich mal, als leichter verständlich angedachte hier dummerweise auch noch immer sobezeichnete Wikitext auch wieder ein wenig an Bedeutung gewinnt). Und besser (also selbsterklärender oder „sprechender“ um)benannt könnte diese (nun dummerweise hier erstmal auch wieder nur, meiner Ansicht nach völlig unnötig, fremdsprachig benannte) Vorlage sicherlich auch noch werden. Mit lieben Grüßen. -- 77.11.219.34 13:53, 23. Mai 2024 (CEST)

Ich habe mir auch überlegt, die Vorlage festeBreite oder festeZeichenbreite oder SchriftFesterBreite zu nennen, aber Monospace erschien mir dann doch viel klarer und schöner, vor allem im IT-Bereich. ‣Andreas•⚖ 17:21, 23. Mai 2024 (CEST)