Wikipedia Diskussion:Schreibweise von Zahlen

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Abkürzung: WD:SVZ
Automatische Archivierung
Auf dieser Seite werden Abschnitte montags automatisch archiviert, wenn sie mit {{Erledigt|1=~~~~}} markiert sind und deren jüngster signierter Beitrag mehr als 30 Tage zurückliegt. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.
Archivübersicht Archiv
2003 bis 2007
2008 bis 2015
ab 2016

Wie wird ein Archiv angelegt?

Zahlen mit Maßeinheiten in Artikeln mit technischem Inhalt[Quelltext bearbeiten]

In Zahlen mit Maßeinheiten steht: In Artikeln mit nur wenigen einheitengebundenen Angaben (vorwiegend nichttechnischer Art) bietet es sich zur Vereinheitlichung der Textstruktur an, diese auszuschreiben. Das ist vollkommen richtig, aber viele Benutzer lesen nur, dass Zahlen auszuschreiben sind. In technischen Texten mit vielen Zahlenangaben kann einen diese vollkommen überflüssige Aufblähung mit überflüssigem Text auf die Palme treiben. Bitte fügt deshalb noch einen Satz ein, wie z.B. In Artikeln mit vielen Zahlenangaben (meist technischer Art) werden die für die Maßeinheit üblich Abkürzungen verwendet, also in der Regel die SI-Einheiten. Der nächste Satz müsste dann anders angekoppelt werden: Für Gleichungen und zusammengesetzte Einheiten gilt im allgemeinen ... Grüße --AHert (Diskussion) 12:52, 3. Dez. 2017 (CET)

Das würde ich etwas anders formulieren. Denn es beschränkt sich nicht auf technische Artikel.
Kenndaten sollte man immer mit entsprechenden Abkürzungen angeben, insbesondere dann, wenn in einem Artikel mehrere Kenndaten stehen, die verglichen werden können. Eine Talsenke ist z. B. 50 km lang und etwa 7 km breit, sie verjüngt sich nach Westen auf 4 km Breite. Auch wenn meinetwegen die Truppen Napoleons dort 1803 einen Fußmarsch von gut zwölf Kilometern zurücklegten und zu einem fünf Hektar großen Gehöft kamen. Es gibt diverse botartige Benutzer, die das nicht verstehen. --Elop 14:14, 3. Dez. 2017 (CET)
Finde ich gut, mit den Beispielen. Fügst du das ein, oder ist da ein Beschluss eines Hohen Rates notwendig? Grüße --AHert (Diskussion) 11:35, 4. Dez. 2017 (CET)
AHert hat nun diese Aussage und das Beispiel von Elop umseitig eingefügt. Ich verstehe nicht, was Elop mit einem Kenndatum meint. Ich sehe keinen prinzipiellen Unterschied zwischen der Höhe einer Mauer oder der zulässigen Höchstgeschwindigkeit in Ortschaften, die zuvor als Beispiele aufgeführt werden, und der Länge und Breite einer Talsenke, die nun als Beispiele für Kenndaten eine besondere Schreibweise erfordern. Auch durch den Kursivsatz wird für mich nicht verständlich, was gemeint ist. --BurghardRichter (Diskussion) 02:53, 17. Nov. 2018 (CET)
Maßgebliche Daten, die das (Lemma-)Objekt beschreiben und mit ähnlichen Objekten vergleichbar machen. Dürfte doch klar sein. Wie groß ist der Edersee im Vergleich zum Biggesee, wie groß München im Vergleich zu Nürnberg.
Bei Objekten wie der Talsenke ist der Unterschied, daß man sie nicht beliebig genau angeben kann bzw. die Größe, je nach Def., schwankt. Aber auch die ungefähre Größe ist maßgeblich für die Vorstellung des Lesers. Und die geht unter, wenn sie prosafiziert wird. --Elop 09:48, 17. Nov. 2018 (CET)
Nein, das Wort Kenndaten gibt es nicht, steht auch nicht im Duden, ist somit reinste TF.
Der Benutzer weiß nicht, was er mit dem Begriff anfangen soll. Er kann nur erraten, was gemeint ist. MfG Harry8 10:13, 17. Nov. 2018 (CET)
Im Duden steht das Wort schon (wär auch komisch, wenn nicht - denn gebräuchlich ist das Wort schon). Es gibt nur keine allgemeinverbindliche Definition, weshalb gegebenenfalls beschrieben werden sollte, für welche Fälle genau eine Schreibweise in Zahlen und Einheiten angezeigt sein kann. --Elop 10:21, 17. Nov. 2018 (CET)
Nun gut, in meinem gedruckten Duden steht es nicht.
Ich hatte das Wort geändert und mit einem Wikilink versehen. Leider wurde meine Änderung revertiert. MfG Harry8 11:16, 17. Nov. 2018 (CET)
Dimension (Größensystem) als Link halte ich hier aber auch nicht für sinnvoll. M. E. reden wir hier mehr oder weniger über charakteristische Daten mit Aussagekraft für das Objekt, die es insbesondere mit anderen Objekten vergleichbar machen und helfen, seine Ausdehnung einzuordnen. --Elop 12:51, 17. Nov. 2018 (CET)
Die Vergleichbarkeit mit anderen Objekten mag ein wesentlicher Gesichtspunkt sein, der für die technisch-wissenschaftliche Darstellungsweise (Zahl in Ziffern und Einheit abgekürzt geschrieben, oft auch mit Zehnerpotenz) spricht. Das ausschliesslich entscheidende Kriterium ist sie nicht. Wenn zum Beispiel im Artikel über die Erde deren äquatorialer und polarer Durchmesser oder deren Masse angegeben werden, dann ermöglichen diese Daten zwar auch den Vergleich mit anderen Planeten; viele Leser wollen aber auch nur eine Vorstellung über die Grösse unserer Erde gewinnen, ohne dass sie die Absicht hätten, sie mit anderen Planeten zu vergleichen. Diese Angaben würden sicher auch in der gleichen Weise geschrieben, wenn es neben der Erde keine anderen Planeten gäbe. Ein anderes Beispiel: Die Newtonsche Gravitationskonstante wird selbstverständlich nur in der technisch-wissenschaftlichen Darstellungsweise angegeben, obwohl es keine andere Gravitationskonstante gibt, mit der man sie vergleichen könnte. (Die Gaußsche Gravitationskonstante hat eine andere physikalische Dimension und ist nicht mit der Newtonschen vergleichbar.)
Zahlen, die in der technisch-wissenschaftlichen Weise geschrieben werden, sind in der Regel Realzahlen, also Zahlen mit einem Dezimalkomma und einer der gewünschten Genauigkeit entsprechenden Anzahl von Nachkommastellen. Auch wenn eine solche Zahl numerisch auf eine Integerzahl gerundet ist, so ist doch die eigentliche Zahl real; d.h. sie könnte, wenn man die Genauigkeit erhöhen wollte, um Nachkommastellen erweitert werden. Wenn die Zahl der Nachkommastellen grösser als null ist, ist die ausgeschriebene Darstellung ohnehin nicht möglich.
Was generell das entscheidende Kriterium ist, hat AHert schon in der Überschrift dieses Artikels angedeutet: Zahlen mit Masseinheiten in Artikeln mit technischem Inhalt. Nur muss man, entsprechend dem Einwand von Elop, den Bereich erweitern; denn natürlich gilt das nicht nur für Artikel zu technischen Themen, sondern ebenso auch für Artikel (oder Teile von Artikeln) aus der Geographie, der Physik, der Meteorologie, der Astronomie, der Medizn, …, also für Gebiete, in denen typischerweise reale Zahlen eine wichtige Rolle spielen. Von einem Leser solcher Artikel kann man erwarten, dass er die Abkürzungen der gängigen Masseinheiten kennt.
Wenn etwa in einem biographischen Artikel über einen Dichter mitgeteilt wird, dass er auf einer Wanderung auf einen über 1000 Meter hohen Berg ein wichtiges Erlebnis hatte, dann darf hier die Einheit Meter gerne ausgeschrieben werden. In einem geographischen Artikel über ein Gebirge ist bei den Angaben von Berghöhen die Masseinheit tunlichst abzukürzen. Wenn in einem Artikel über eine Stadt im Einleitungsteil (meist in der Infobox) die Fläche und die Höhenlage der Stadt mitgeteilt werden, so sind das geographische Angaben, in denen die Masseinheiten abzukürzen sind. Wenn weiter unten im Abschnitt über Baudenkmäler die Grösse eines mittelalterlichen Gebäudes beschrieben wird, dann kann in den entsprechenden Angaben (sofern sie auf volle Meter gerundet sind) die Einheit Meter ausgeschrieben werden. --BurghardRichter (Diskussion) 15:44, 17. Nov. 2018 (CET)
+1
Ich ahne, worauf das abzielen soll – wenn es im Artikel um ein Auto- oder Flugzeugmodell ginge, dann mögen Autoren für die Geschwindigkeit, Masse, Reichweite vergleichbare Daten verwenden.
Ein Tal oder ein See und selbst die menschengemachte Straße hat jedoch keine Kenndaten in diesem Sinn. Wie groß ist ein See? Volumen, mittlere amtliche Pegeltiefe, maximale Tiefe, maximale Längenausdehnung? Was sagt mir das und wieso kann ich deshalb einen See mit einem anderen vergleichen und welcher ist jetzt angeblich „größer“ und wozu will ich das wissen? Auto-Quartett? Wer hat den längsten? Schmarrn. Genauso eine Stadt; Einwohnerzahl, Fläche, maximale Längenausdehnung, Anzahl der Gebäude? Welche ist denn nun größer? Was soll das? Diese Daten stehen längst in einheitlicher Form in den Infoboxen, und alle relevanten Themengebiete haben serienmäßig eine Infobox; im sonstigen Fließtext des Artikels ist es überflüssige Autorenquälerei, dort noch kuriose Sonderregelungen für unklar abgegrenzte Spezialfälle aufzuzwingen.
Insofern können Autoren diese diffuse Extra-Regel in ihren Artikeln nicht flächendeckend umsetzen. Sie ist aber bereits durch die den umseitigen Abschnitt einleitenden Bemerkungen hinreichend abgedeckt. Wenn das dann auch noch im Sinne von WSIGA langwieriger Definitionen bedarf, im Fall genau welcher Lemmata an genau welcher Stelle des Fließtextes angeblich genau welche Formatierung vorgeschrieben werden müsse, dann kann sich das niemand merken und das gesamte Vorhaben ist für die Katz.
Hier ist der Ort für die Schreibweise einer einzelnen Zahlenangabe in ihrem unmittelbarem Kontext, nicht aber um hinter dem Rücken der Autoren einen StyleGuide für bestimmte unbestimmte Arten von Artikeln vom Himmel plumpsen zu lassen.
Ich empfehle Rückbau.
VG --PerfektesChaos 17:08, 17. Nov. 2018 (CET)

Schreibweise von Bruchzahlen[Quelltext bearbeiten]

Bei Verwendung der Zeichen ½, ¼ und ¾: Ist die korrekte Schreibung 11 ½ oder 11½? Ist 11 ½ (11 ½) gewünscht? --Neitram  16:58, 6. Jun. 2018 (CEST)

Da gibt es einen Widerspruch auf dieser Projektseite:33¾ oder 3334. Die letztere Schreibweise gefällt mir wegen der klareren Ziffernschreibweise besser. Eigentlich müsste nmM der Bruchteil aber unmittelbar folgen. MfG Harry8 17:15, 6. Jun. 2018 (CEST)
Das ist ein typisches Beispiel für einen Fall, in dem eigentlich ein schmales Leerzeichen richtig ist. Ich nehme an, dass die von Harry benutzte Vorlage:Bruch ein solches einsetzt. Ich bevorzuge auch diese Vorlage. Sie erzeugt den Zähler und den Nenner in optimaler Grösse und setzt sie in die richtige Höhe.
Wenn ein schmales Leerzeichen nicht möglich sein sollte, würde ich den Bruch auch lieber ohne Zwischenraum als mit einem ganzen Zwischenraum setzen. Der ganze Zwischenraum erzeugt zu sehr den Eindruck, als ob die beiden Zahlen nichts miteinander zu tun hätten. Was sind 2 ½-geschossige Häuser oder 3 ½-Zimmer-Wohnungen? --BurghardRichter (Diskussion) 17:36, 6. Jun. 2018 (CEST)
Das lästige nbsp ist fast immer falsch. Es erzeugt bei vielen Schriftarten einen überbreiten Weißraum, der jeden Zusammenhang zwischen den Teilen, die es eigentlich zusammenhalten soll, zerreißt. Zwischen den ganzzahligen und gebrochenen Teil derartiger gemischter Zahlen (so hieß das mal ganz offiziell) gehört kein noch so schmales Leerzeichen. Zwischen die sonstigen Stellen einer mehrstelligen Zahl kommen schließlich, abgesehen von den schmalen Leerzeichen zur Gruppierung ab fünf Stellen, auch keine Weißräume. Etwas anders sieht das aus, wenn es nicht möglich ist, Zähler und Nenner des Bruches hoch- und tiefzusetzen. Dann ist ein schmales Leerzeichen unverzichtbar, sonst wird der Sinn entstellt. –Falk2 (Diskussion) 21:30, 6. Jun. 2018 (CEST)
Wenn ich den Bruchzahlenschreibweiseabschnitt anschaue, dann interpretiere ich: ½, ¼ und ¾ kann man als Einzelzeichen benutzen, sobald entweder ein anderer Bruch oder eine gemischte Zahlgeschrieben werden soll, wird die Vorlage:Bruch empfohlen. Und die scheint mir ja sehr einfach zu benützen: {{Bruch|a|b|c}} ergibt abc. Wenn man das mal kennt (war mir bislang neu...), dann ist das sogar bequemer zu nutzen als die 1/2... äh, die Bruchzeichen da oben, anderen Code ich mich auch erst erinnern müsste. --Pcb (Diskussion) 22:10, 6. Jun. 2018 (CEST)
59607 Der Bruchstrich sieht ein bisschen verhungert aus, aber es scheint auch mit mehrstelligen Zählern und Nennern zu funktionieren. Vergleichen wir mal 3¼ (unicode UTF-8) mit 314 (Vorlage Bruch), 31/4 (hoch- und tiefgestellt) und 31/4 hoch- und tiefgestellt mit Zeichenverkleinerung), dann zeigen die Vorlage Bruch und das Hoch- und Tiefstellen auch mit (umständlich) verkleinerten Zeichen allerdings deutliche typografische Schwächen. Ein Grund, sie nur zu benutzen, wenn andere Darstellungsmöglichkeiten nicht bestehen. Die Unicode-Darstellung dürfte die Referenz sein. –Falk2 (Diskussion) 22:57, 6. Jun. 2018 (CEST)
Danke für die Zusammenstellung der Vergleichsbeispiele! Für mich hat der Unicode-Bruch den wesentlichen Nachteil, dass die Ziffern des Zählers und des Nenners viel zu klein sind. Zähler und Nenner sind nicht weniger wichtig als die ganze Zahl vor dem Bruch. Nur aus graphischen Gründen müssen sie etwas verkleinert sein; aber sie sollten nicht kleiner als nötig sein. Unter diesem Gesichtspunkt erscheinen mir die Konstruktionen der Vorlage:Bruch und der Hoch- und Tiefstellung (ohne zusätzliche Verkleinerung) optimal.
Dass ein ganzes Leerzeichen (Viertelgeviert) zwischen der ganzen Zahl und dem Bruch nicht in Betracht kommt, darüber sind wir uns anscheinend einig. Überhaupt keinen Zwischenraum zu setzen, halte ich allerdings auch nicht für optimal. Ein Bruch mit seinen zwei Zahlen in unterschiedlicher Höhe und dem schrägen Strich dazwischen ist ein komplexes Gebilde, das graphisch vollkommen anders geartet ist als eine einfache Ziffer; ich finde es unbefriedigend, wenn er mit der vorhergehenden ganzen Zahl genauso eng verbunden ist wie die Ziffern dieser Zahl (sofern sie mehrstellig ist) untereinander oder die Ziffern des Zählers und des Nenners untereinander. In der Zahl 1641825 hat der Bruch als ganzes eine höhere Eigenständigkeit als die drei Ziffern der Zahl 164. Man kann ihn nicht einfach wie das vierte Element einer insgesamt vierstelligen Zahl behandeln. Zähler und Nenner sind ja selbst mehrstellige Zahlen wie auch die 164. Dass der Abstand zwischen ganzer Zahl und Bruch unbedingt ein schmales Leerzeichen (Achtelgeviert) sein muss, darauf will ich mich nicht versteifen; vielleicht ist die Hälfte davon noch besser. Aber ein schmales Leerzeichen erscheint mir auf jeden Fall besser als gar kein Zwischenraum. --BurghardRichter (Diskussion) 01:27, 7. Jun. 2018 (CEST)

(Wieder vor) Nur ist das Ungetüm 1641825 kaum handhabbar. Kaum jemand hat eine Vorstellung davon, was der Bruch ausmacht. Derartige Werte sollte man immer als Dezimalbruch darstellen. 164,72 ist deutlich klarer und sollten sich übermäßig viele Nachkommastellen oder gar eine Periode ergeben, dann würde ich das immer auf zwei Nachkommastellen runden. Brüche sollten im Fließtext ohnehin vermieden werden. Dass sie nicht aus der Schriftkontur herausragen sollen, hat einfach damit zu tun, dass sonst das Layout gefährdet ist. Der Zeilenabstand darf sich deswegen im Fließtext eben nicht ändern. Deswegen werden auch Indizes und Exponenten mit deutlich verkleinerten Zeichen gesetzt. Bei einer gemischten Zahl stellt der Bruch die Nachkommastellen dar. Bei einer Dezimalzahl wird auch kein Weißraum gesetzt. Was zu kleine Ziffern betrifft, da habe ich einen anderen Verdacht. Viele Nutzer passen an ihren Rechnern die Schriftgrößen und -arten nicht an und die Vorgaben stammen meist aus Zeiten, als eine Monitorauflösung von 768 × 1024 Punkten als groß galt. KDE zum Beispiel ärgert die Nutzer noch immer mit der verhungerten »Sans serif« und neun Punkten Höhe (und das hat sich seit mindestens fünfzehn Jahren nicht geändert). Wer über dreißig ist, fängt da schon an zu blinzeln und mit Mitte vierzig wird es richtig anstrengend. Nur ist das kein Grund, das Layout gerade im Indernnetz für alle in Grund und Boden zu schießen. Für sowas gibt es lokale Einstellungen. Leider sind die bei den Spitzenprodukten aus Redmond schon immer gut an mehreren Stellen versteckt (wer denkt schon daran, dass sich die IEx-Einstellungen in der Systemsteuerung auf nahezu jede Anwendung auswirken?) und bei jeder Version kann man weniger anpassen. Das Problem liegt aber dann wirklich bei denen, die Bill G. aus R. noch reicher machen wollen. Bei mir ist die Menüschrift jedenfalls Square 721BT mit elf Punkten und im Browser werfe ich noch eine Schippe drauf. Ansonsten Strg + Mausrad, doch selbst das spricht sich kaum rum, auch bei den in der Regel hochbezahlten Webdesignern nicht. –Falk2 (Diskussion) 02:32, 7. Jun. 2018 (CEST)

Es geht mir erst einmal nur um gemischte Brüche mit den Zeichen ½, ¼ und ¾, nicht um andere gemischte Brüche. Zur Verwendung schmaler Leerzeichen in Wikipedia gibt es, wenn ich mich nicht irre, bisher noch keinen Konsens (Wikipedia:Typografie#Leerzeichen und Wikipedia Diskussion:Typografie#Vorlage:Nnbsp), oder? --Neitram  11:14, 7. Jun. 2018 (CEST)
Wenn wir schmale Leerzeichen ausklammern, sehe ich noch folgende Varianten zur Auswahl:
  1. Zusammenschreibung: 11½
  2. Ein normales Leerzeichen zwischen ganzer Zahl und Bruch: 11 ½
  3. Ein geschütztes Leerzeichen zwischen ganzer Zahl und Bruch: 11 ½ ergibt 11 ½
  4. ½, ¼ und ¾ sollen überhaupt nicht in gemischten Brüchen verwendet werden, statt dessen soll die Vorlage:Bruch verwendet werden: {{Bruch|11|1|2}} ergibt 1112
Finden wir unter diesen 4 Varianten einen Konsens? --Neitram  11:58, 8. Jun. 2018 (CEST)
Dass ein ganzes Leerzeichen einen zu grossen Abstand erzeugt, darüber bestand meines Erachtens Einigkeit. Ein ungeschütztes Leerzeichen hat überdies den Nachteil, dass der ganzzahlige Teil und der Bruchteil der Zahl durch den Zeilenumbruch getrennt werden können. Die Formen 2 und 3 scheiden damit aus. --BurghardRichter (Diskussion) 12:32, 8. Jun. 2018 (CEST)
Im Artikel ¼ (den gibt's) las ich gerade den Satz: "Gemischte Brüche werden in Texten kompress (ohne Leerzeichen) gesetzt". Aber ohne Einzelnachweis. Beispiele für Variante 2 finde ich in großer Zahl, zum Beispiel im Artikel Bentley 3 ½ Litre. Vermutlich ist Variante 2 die derzeit häufigste in der Praxis. Was natürlich nicht heißt, dass wir sie nicht ächten dürfen. --Neitram  15:39, 11. Jun. 2018 (CEST)

Verwendung des einfachen Schrägstrichs ohne Hochstellung des Zählers und Tiefstellung des Nenners[Quelltext bearbeiten]

Neitrams heutiger Änderung kann ich nicht uneingeschränkt zustimmen. Was spricht dagegen, einen reinen Bruch in der Form 1/2 oder 3/4 zu schreiben? Diese weit verbreitete Schreibweise hat immerhin den Vorteil, dass Zähler und Nenner in gleicher Grösse erscheinen. Normalerweise suggeriert Kleinschreibung, dass es sich um etwas von geringerer Wichtigkeit handelt. Das ist hier aber nicht der Fall. Im Gegensatz zu der in mathematischen Formeln üblichen Schreibweise mit waagerechtem Bruchstrich bietet diese Schreibweise gleichzeitig den Vorteil, dass der Zeilenabstand garantiert nicht vergrössert wird, da Zähler und Nenner beide auf normaler Höhe stehen. Ausserdem erfordert diese Schreibweise keinerlei Spezialkenntnisse von einer Vorlage und ihrer korrekten Anwendung oder von irgendwelchen exotischen Unicode-Zeichen. Sie ist nur dann ungeeignet, wenn es sich um einen gemischten Bruch handelt, weil dann der ganzzahlige Teil und der Zähler nicht klar trennbar sind. --BurghardRichter (Diskussion) 13:10, 8. Jun. 2018 (CEST)

Da bin ich jetzt nicht einverstanden. 1/2 ist nicht (nur) ein Bruch, sonder z.B. "eins von zwei". Ausserdem ist "½" keine Kleinschreibung, sondern damit ist der Bruch gleichgross wie eine normale Zahl. Passt also. Trotzdem bin ich mit obengenanntem Edit nicht ganz einverstanden. In meinen Augen wäre es sinnvoll, die ganzen Kann-Regelungen abzukürzen, i.S. von "½, ¼ und ¾ alleine so im Fliesstext, alle anderen Brüche sowie alle gemischten Zahlen mit der Vorlage". --Pcb (Diskussion) 14:13, 8. Jun. 2018 (CEST)
Diese Setzweise ist schon Murks und ein Fall von »gewollt und nicht gekonnt«. Davon abgesehen, wer will eigentlich mit dem Holzhammer Vorgaben erlassen und durchsetzen und vor allem, warum? Geht es dann irgendjemand besser, steigt der Wahrheitsgehalt? Haben wir wirklich keine anderen Sorgen? Es geht erstmal um Inhalte. Die Vorlage Bruch ist nicht perfekt, aber man kann mit ihr leben. Unicode-Brüche sind ebenfalls unkritisch. Dass sie die, die unbedingt Windows benutzen wollen, nicht so einfach hinkriegen, ist ihr eigenes Problem. Dass die Vorlage Bruch bei Windows Phone richtig entgleist, passt dazu. Ich werde mich weiter an die Regel »ignoriere alle Regeln« halten und @Neitram, nach allem beckmesserhaftem Leerzeichenunsinn bin ich auch da an irgendwelchen Konsensen nicht mehr interessiert. nbsp wird weiter wie Unkraut behandelt. –Falk2 (Diskussion) 07:20, 9. Jun. 2018 (CEST)
Der Schrägstrich hat viele verschiedene Funktionen und wenn irgendwo "767854/32427" steht, weiß der Leser erst einmal nicht, ist das eine Typenbezeichnung, eine Telefon- oder andere Nummer, soll es bedeuten "767854 beziehungsweise 32427", "767854 und 32427", "767854 von 32427", die Formel "767854 geteilt durch 32427" oder der Bruch 76785432427. Wenn es kein Konsens ist, dass der Schrägstrich ein schlechter Bruchstrichersatz ist, sollten wir den von mir dazu eingefügten Satz natürlich ändern, dann bitte ich um Vorschläge dazu. --Neitram  10:24, 9. Jun. 2018 (CEST)
Oh! Ich habe gerade etwas Kurioses bemerkt. Ich hatte bei meinem Edit eingebeben: 1⁄2, also die Ziffer 1, dann den ⁄, und dann die Ziffer 2. Für mich war es auch noch so als drei Zeichen nebeneinander zu sehen, mit normalgroßen Ziffern -- das war allerdings auf einem anderen Computer als der, an dem ich jetzt gerade sitze. Hier habe ich nun den krassen Effekt: 1⁄2 wird genauso dargestellt wie ½, und es geht mit beliebigen Zahlen: 1234⁄5678 funktioniert! Wird das bei euch auch korrekt angezeigt? --Neitram  10:31, 9. Jun. 2018 (CEST)
Bei mir wird die Eingabe, wie du sie beschrieben hast, auch in einen Bruch umgewandelt, aber nur wenn links und rechts von dem schrägen Bruchstrich jeweils eine Zahl steht. Mit Buchstaben funktioniert es nicht.
Ich weiss allerdings nicht: Wie gibt man denn solch einen Bruchstrich ein? Ich habe ihn jetzt für den Test aus deinem hierüber stehenden Edit kopiert. Aber er ist weder auf meiner Tastatur noch in der unterhalb des Bearbeitungsfensters angezeigten Sonderzeichenliste vorhanden, und die Unicode-Nummer ist mir nicht bekannt. So bin ich also normalerweise gar nicht in der Lage, solch einen Bruchstrich zu erzeugen. Aber es genügt mir ja auch, dass die Vorlage Bruch es kann. --BurghardRichter (Diskussion) 12:08, 9. Jun. 2018 (CEST)

Es ist das Zeichen U+2044 FRACTION SLASH beteiligt, was einen etwas flacheren schrägen Strich als in ASCII U+002F ergibt.

  • Es ist offenkundig ein Feature einiger aber nicht aller Browser, wenn sie dieses Zeichen links und rechts unmittelbar von Ziffern benachbart sehen diese Zifferngruppen wie beschrieben hoch- und tiefzustellen.
  • Als Empfehlung für Wikitext ist das denkbar ungeeignet; im Gegenteil müsste der Effekt sogar aktiv verhindert werden und eine für alle Leser gleiche Darstellung explizit organisiert werden.

VG --PerfektesChaos 14:20, 9. Jun. 2018 (CEST)

Ich habe den Absatz jetzt entsprechend angepasst. --Neitram  07:44, 11. Jun. 2018 (CEST)
Vielen Dank, Neitram! Etwas unbefriedigend ist allerdings der Satz „Die Brüche ½, ¼ und ¾ sind in allen gängigen Zeichensätzen enthalten und können unbedenklich im Fließtext eingesetzt werden.“ Die Sonderzeichenliste unterhalb des Bearbeitungsfensters im Editor enthält nur den Bruch ½. Bei den beiden anderen Brüchen ist für die Benutzer nicht ersichtlich, wie man sie erzeugen kann. Weiss jemand, wie man in der Sonderzeichenliste weitere Zeichen hinzufügen kann? --BurghardRichter (Diskussion) 10:22, 11. Jun. 2018 (CEST)
Denk an die AltGr-Taste. und probiere Kombinationen mit der Ziffernreihe durch. AltGr + 4 ergibt ¼, AltGr + 5 ½. Achtel gibt es mit AltGr + Umsch + Ziffernreihe. Windows ist allerdings in dieser Hinsicht minderbemittelt und kennt nur die Ziffernblockkombinationen mit Alt. –Falk2 (Diskussion) 10:30, 11. Jun. 2018 (CEST)
Deine Kritik an Windows mag berechtigt sein. Aber wir können hier in der WP-Richtlinie nicht etwas empfehlen, was in einem der meistbenutzten PC-Betriebssysteme nicht funktioniert. Das hilft den meisten Benutzern nicht weiter. --BurghardRichter (Diskussion) 10:39, 11. Jun. 2018 (CEST)
Solange es keine befriedigende Alternative gibt, die auch für Benutzer ohne Kenntnis von Vorlagen und Codezahlen anwendbar ist, müssen wir die „primitive“ (aber traditionell sehr gebräuchliche) Schreibweise 1/4 und 3/4 akzeptieren. Dass hiermit ein numerischer Bruch gemeint ist, dürfte sich in den allermeisten Fällen klar aus dem Zusammenhang ergeben, so dass eine Verwechslung etwa mit „1 (von 4)“ bzw. „3 (von 4)“ nicht zu befürchten ist.
Für vordringlich halte ich es, dass wenigstens die häufig vorkommenden Brüche ¼ und ¾ (neben dem schon vorhandenen ½) in die Sonderzeichenliste unterhalb des Beabeitungsfensters aufgenommen werden, so dass man sie dort nur anzuklicken braucht. Die Notwendigkeit ist hier ebenso gegeben wie etwa beim Halbgeviertstrich, dem Minuszeichen oder den korrekten Anführungszeichen, die auch alle nicht standardmässig auf den PC-Tastaturen vorhanden sind. --BurghardRichter (Diskussion) 12:12, 11. Jun. 2018 (CEST)
(BK) Auf Hilfe:Sonderzeichen#Allgemeine Sonderzeichen gibt es bereits ¼ und ¾ zum Rauskopieren. Ob sie in Edittools hinzugefügt werden sollten, ist die Frage: dort steht ja aus Platzgründen nur eine Auswahl der allerhäufigsten Sonderzeichen. Andererseits nimmt "¼ ¾" sehr wenig Platz ein und würde kaum stören. Vielleicht wäre es auch mal interessant, über einen weiteren Edittools-Leisteneintrag unterhalb "Standard" auf MediaWiki:Onlyifediting.js nachzudenken, mit weiteren Sonderzeichen. --Neitram  12:15, 11. Jun. 2018 (CEST)

Ich finde die Formulierungen, so wie sie jetzt sind, eigentlich als ausreichend gut. Es wird gesagt, es gebe eine Vorlage Bruch, es werden die Unicode-Brüche, die auf fast allen Systemen korrekt dargestellt werden, genannt und als akzeptabel für Fliesstext bezeichnet, ungünstige Möglichkeiten werden angesprochen. Kann man m.E. so lassen. --Pcb (Diskussion) 16:29, 11. Jun. 2018 (CEST)

(BK) @BurghardRichter: Wir sollten m.E. die Schreibweise mit Schrägstrich (1/4) durchaus als erlaubte Schreibweise „akzeptieren“, weil sie es dem Schreiber maximal einfach macht, weit verbreitet ist und es beim Lesen keine ernsthaften Probleme gibt, solange der Kontext klar macht, dass es eine Bruchzahl ist, und bei gemischten Brüchen (1 1/4) ein Leerraum gesetzt wird. Aber wir sollten m.E. die Schrägstrich-Schreibweise auf dieser Seite nicht gerade „empfehlen“, sondern vielmehr darauf hinweisen, dass die Bruch-Vorlage eine für den Leser bessere Schreibweise erzeugt. --Neitram  16:32, 11. Jun. 2018 (CEST)
Voll einverstanden. --BurghardRichter (Diskussion) 16:52, 11. Jun. 2018 (CEST)

Gemischte Zahlen kompress? (ff)[Quelltext bearbeiten]

hierher aus Diskussion:¼ --W!B: (Diskussion) 11:04, 9. Jun. 2019 (CEST)

@W!B:: Im Jahr 2013 hast du hier hinzugefügt: "Gemischte Brüche werden in Texten kompress (ohne Leerzeichen) gesetzt: „2¼“" Hast du dafür einen Beleg? --Neitram  09:30, 31. Mai 2019 (CEST)

@Neitram: nein. hast recht: da gehört eigentlich ein "üblicherweise" rein. cf. https://www.typografie.info/3/topic/32273-spationierung-bei-bruchzahlen/ (die streiten sich dort aber sonst recht viel um ganz was anderes). allenfalls vielleicht sehr eng spationieren, sonst verwechselt man «2¼“» ("zwei-[und-]ein-viertel-zoll") mit «2 ¼“» ("zwei (mal je ein) [ein-]viertel-zoll"), etwa als «2¼“-Rohr» vs «2 ¼“-Rohre»: ersteres ist ein dickes, zweiteres zwei dünne. oder «2¼ kg» ("zwei-ein-viertel kilo" = 2,25 kg) vs. «2 ¼ kg» ("zwei viertel-kilo" = 0,5 kg). oder? man schriebe ja auch «2¼-kg-Laib» vs «2 ¼-kg-Laibe», also auch «2 2¼-kg-Laibe» (= 4,5 kg Brot).
aber «1/4» natürlich mit leerzeichen: «11/4» statt «1 1/4» geht ja gar nicht (cf. http://www.angelika-steidle.info/inhalt/textgestaltung-zahlen.htm#Zahlen%20bei%20Rechenzeichen)
eine konkrete vorschrift/empfehlung finde ich per google aber nicht. --W!B: (Diskussion) 17:00, 31. Mai 2019 (CEST)
Danke. Ich finde derzeit annähernd gleich viele Fälle in Wikipedia-Artikeln, wo gemischte Brüche mit den Zeichen ½, ¼ usw. derzeit kompress stehen, und wo sie mit Leerzeichen (nicht kompress) stehen. Beispiele für letzteres sind etwa Barill, Denaro (Einheit), Anker (Hohlmaß), Sack (Einheit), Famn, Star (Einheit)... Wir hatten dazu letztes Jahr im Juni 2018 eine Diskussion auf Wikipedia Diskussion:Schreibweise von Zahlen#Schreibweise von Bruchzahlen, die bislang ohne Ergebnis ist. Vielleicht macht es Sinn, die Diskussion dort wieder aufzunehmen? Irgendwie fände ich es gut, wenn die Frage "Kompress oder mit Leerzeichen?" auf Wikipedia:Schreibweise von Zahlen#Schreibweise von Bruchzahlen klarer geregelt wäre (also auch für gemischte Brüche mit ½, ¼ und ¾). Dazu wäre es hilfreich zu wissen, ob es eine Regelung einer typografischen Autorität gibt, der wir uns ggf. in Wikipedia anschließen wollen. --Neitram  15:22, 4. Jun. 2019 (CEST)
End of hierher

(BK) Benutzer:Neitram: hab unsere disk hierherübersiedelt, damit man gleich anknüpfen kann: stimmt, aber zb Denaro (Einheit) ist ja eine listenförmige rudimentärtext-aufzählung:

  • Herzogtum Parma 1 Denaro = 1 3/22 Gramm
  • Herzogtum Piacenza 1 Denaro = 1 ⅛ Gramm
  • Venedig, Mailand 1 Denaro = 90/91 Gramm

und der autor mischt hier die plain-ascii-schreibweise mit den unicodes, weshalb er wohl die syntax beibehält. hier scheint das plausibel. (ditto die anderen deiner beispiele – ausserdem sind viele der alte-maßeinheiten-artikel aus derselben hand, das könnte ales präferenz eines kollegen sein). ich hätte aber betonen sollen: "im fliesstext kompress" – eine formelhafte aufzählung hat andere regeln. --W!B: (Diskussion) 11:16, 9. Jun. 2019 (CEST)

Vorschlag: 2¼ kompress, aber 3 5/37 nicht kompress. MfG Harry8 11:09, 9. Jun. 2019 (CEST)

ja, so ungefähr meinte ich das. --W!B: (Diskussion) 11:16, 9. Jun. 2019 (CEST)
Wir haben doch dafür die Vorlage Bruch, die das Problem der überbreiten Weißräume elegant umgeht und Missverständnisse vermeidet: 3557, {{bruch|3|5|57}}. Sie ist noch dazu einfach zu setzen. Man sollte sie für ein einheitliches Schriftbild nur gerade in Aufzählungen auch konsequent benutzen. –Falk2 (Diskussion) 11:58, 9. Jun. 2019 (CEST)
die vorlage haben wir gebastelt, also ist sie noch keine verbindliche darstellung. ausserdem kann man autoren nicht verbieten, die unicode-zeichen zu verwenden. ziel ist ja eine halbwegs einheitliche darstellung, ohne eine gewisse technologie vorzuschreiben. --W!B: (Diskussion) 12:02, 9. Jun. 2019 (CEST)
Von Vorschreiben war doch gar keine Rede. Nur ist diese Vorlage ein einfacher Weg, um das oben beschriebene Durcheinander zu vermeiden. »3 5/37« ist jedenfalls ein Augenkrebsauslöser und ein schmales Leerzeichen macht es nicht schöner. 3 5/57 (3{{nnbsp}}<sup><small>5</small></sup>/<sub><small>57</small></sub>) ist sicherlich die ansehnlichste Darstellung, aber ob den Quelltext jemand nachbastelt? –Falk2 (Diskussion) 12:14, 9. Jun. 2019 (CEST)
das geht in voll-unicode aber einfacher: 3 ⁵⁄₅₇ (3 ⁵⁄₅₇ = U+0033 U+202F U+2075 U+2044 U+2085 U+2087) mit den zeichen aus Unicodeblock Hoch- und tiefgestellte Zeichen und dem obengenannten FRACTION SLASH (um sich nicht auf die automatische hoch-tief-stellung durch denselben zu verlassen: mein firefox macht das nicht). da unicode sukzessive von allen browsern implementiert wird, kann man sich auch darauf verlassen, dass sie das korrekt darstellen: die niedrig-nummrigen blöcke gibt es seit 1991, die sollten inzwischen also überall implementiert sein. das schriftbild ist dann jedenfalls deutlich besser als mit unserem vorlagen-workaround. und im quelltext aufwändiger ist es auch nicht. und kopierstabil –in der "anderen richtung": typographisch, nicht vorrangig semantisch --W!B: (Diskussion) 12:47, 9. Jun. 2019 (CEST)
Wie gibst Du die hoch- und tiefgestellten Zeichen ein? Darüber schweigt sich der Link leider aus. In der dritten und vierten Ebene der Tastaturbelegung liegen sie jedenfalls nicht. –Falk2 (Diskussion) 13:11, 9. Jun. 2019 (CEST)
aus der Zeichentabelle – die habe ich, wenn ich nur irgendwie mit "sonderzeichen" hantieren muss, standardmässig offen: die wp-edittools sind mir zu unvollständig, und tastaturbelegung interessiert mich nicht, ich bin mausschubbser. oder arbeite direkt mit grafiktablet & handschrifterkennung. alternativ übrigens copy&paste über unsere unicode-artikel: was einmal in die wp getippt wurde, braucht man nie wieder tippen – meine abneigungen gegen das tippen an sich ist ja offenkundig erkennbar ;) -- ich vermeide jeden unnötigen tastendruck. drum schätze ich übrigens die vorlage:bruch nicht sonderlich, denn die kann man nicht sauber kopieren und direkt weiterverwenden, man muss immer im quelltext nacharbeiten. --W!B: (Diskussion) 13:31, 9. Jun. 2019 (CEST)
PS: meine nächste etappe wird übrigens spracheingabe, dann will ich nurmehr "drei schmal-space hoch-fünf bruchstrich tief-sieben" sagen. --W!B: (Diskussion) 13:38, 9. Jun. 2019 (CEST)
(BK)
„da unicode sukzessive von allen browsern implementiert wird“ – das ist ein ururalter aber nicht auszurottender Denkfehler.
Die Browser haben absolut nullkommanix mit den dargestellten Zeichen zu tun.
Maßgeblich ist, ob die für die Darstellung verwendete Schriftart (oder überhaupt irgendeine auf dem Gerät installierte Schriftart) eine grafische Definition für die Zeichen kennen würde.
Und das ist bei den in Rede stehenden exotischen Zeichen weiterhin nicht gesichert, und es wird immer wieder von Darstellungsfehlern berichtet.
Die Unicode-Zahlenwerte sind den Browsern seit bald zwanzig Jahren immer bekannt gewesen, aber was hilft es, die Codenummer zu kennen, wenn der Browser nicht weiß, wie die Grafik dazu aussehen soll?
Unicode mag ja 1991 festgelegt haben, dass der Code Nr. 12345 dies und das bedeuten solle; aber das heißt noch lange nicht, dass bei unseren Lesern auch eine grafische Umsetzung dafür aktiv ist.
VG --PerfektesChaos 13:17, 9. Jun. 2019 (CEST)
ich sprach von "niederige blöcke", nicht 12345: also, wer sieht ⁵⁄₇ falsch? wir sollten eine vergleichstabelle über die möglichen setzarten machen (mit "browser" meinte ich übrigens natürlich "clientseitige systemkonfiguration", in abgrenzung zur serverseitigen konfiguration der wp: wo man fonts installiert, ist mir bekannt. ich weiß sogar, wie man sie baut) --W!B: (Diskussion) 13:38, 9. Jun. 2019 (CEST)
PS: ausserdem sind wir eine erstzunehmende wirtschaftpolitische macht, wir haben schon um 2005 microsoft gezwungen, endlich unicode wenigstens im basis-ansatz sauber zu implementieren: wenn wir etwas verwenden, ziehen erfahrungsgemäß alle namhaften anbieter nach. man kann es sich heute nicht mehr leisten, die wp unleserlich darzustellen. und auf eine weitere inaccessibility in der wp kommt es sowieso nicht mehr an, um die haben wir uns nie sonderlich geschert. hier gehts aber um durchsetzung eines international sowieso verbindlichen standards --W!B: (Diskussion) 13:49, 9. Jun. 2019 (CEST)

PS: im übrigen kann man auch den o.g. "Augenkrebsauslöser" nicht in toto verbieten, denn die angabe G 1 3/8" „Gewinde Ein-drei-achtel-Inch“ (Whitworth Rohrgewinde BSP British Standard Pipe) ist nach DIN ISO 228 genauso möglich wie G1³⁄₈″ – technische angaben legen ihren fokus nicht unbedingt auf typographische eleganz, sondern auf standardkonformität (ist der wortlaut eigentlich typographisch korrekt, oder schriebe man „ein-drei-achtel-Inch“ oder „Ein-Drei-Achtel-Inch“? -- nicht meine stärke.. ;) --W!B: (Diskussion) 13:40, 9. Jun. 2019 (CEST)

Danke, aber das ist ja noch unbequemer als mein sup- und small-Versuch. Die Mausschiebe- und -kickserei ist in der Texteingabe wirklich unpraktisch und Spracheingabe nervt. Davon abgesehen, meine Standardschrift Square 721 kommt mit den ⁵/₇ klar, nur den hässlichen, zu kurzen Schrägstrich habe ich mal ersetzt. –Falk2 (Diskussion)
Ein-drei-Achtel-Zoll, »inch« ist Sprachpanscherei. 13:50, 9. Jun. 2019 (CEST)
danke dir. ja stimmt, gepantsche. und PPS zu oben: ausserdem beherrscht natürlich jedes system die direkteingabe von unicodenummern. und wie gesagt, bei den eingabemethoden hat jeder seine prvaten vorlieben, da können wir keine als "besser" oder "schlechter" deklarieren --W!B: (Diskussion) 15:04, 9. Jun. 2019 (CEST)
Zurück zur Ausgangsfrage:
  • Vermieden werden soll eigentlich nur eine uneinheitliche Darstellung im selben Textbereich (Absatz, Artkel).
  • Wenn in einem literarischen Text aus dem 19. Jahrhundert mal ein damals üblicher gemischter Bruch vorkommt (wir waren 2½ Stunden vom nächsten Gasthofe entfernt, als uns ein heftiges Gewitter überraschte), dann ist aus heutiger Sicht ziemlich wurscht, wie viele Minuten das denn genau gewesen sein sollen und ob man die kleine Zahl da lesen kann und ob das nun zwei oder drei Stunden wären, weil wir müssen die sowieso nicht laufen und es ist eh nur Fiktion.
  • In einem literarischen Text wird das auch nur einmalig vorkommen; die Wiederholungsgefahr auf dieser Bildschirmseite ist gering.
  • Wenn bei organisatorischen, finanziellen, musikalischen, technischen, älteren physikalischen Themen irgendwelche Zwölftel, Hundertstel, Sechzehntel, Siebtel vorkommen, dann sind die Zahlenwerte inhaltlich wichtig und sollten gut lesbar sein und zuverlässig dargestellt werden, und dann sollen ausnahmslos alle Zahlen dieser Art im Textbereich einheitlich formatiert sein. Und {{Bruch}} ist dafür Mittel der Wahl.
VG --PerfektesChaos 13:53, 9. Jun. 2019 (CEST)
wie gesagt, die "zuverlässigkeit" der vorlage:bruch bezeifle ich: sie begeht nämlich (in der derzeitigen implementierung) die größte sünde im webdisgn, nämlich die unsaubere trennung von content und darstellung:
{{bruch|3|5|57}} → 3557 und dieses c&p ergibt 3 5⁄57, das ist weder fisch noch fleisch
  • entweder müsste sie plain-ascii ergeben, also 3 5/57 mit echtem ascii-slash
  • oder sie verwendet unicode &frasl;, dann müsste sie auch die zugehörigen unicode-zahlzeichen (¹ ff) verwenden
und ausserdem verwendet sie "handgestricktes" sup style="font-size: 70%; vertical-align: 0.4em;" «1», was weder die standarddarstellung für sup/sub «1» (editbuttons ), noch für ascii/unicode hoch/tiefgestellt «¹» (standardtastatur und eingabemethode) noch für ascii/unicode bruch «½» (edittools sonderzeichen) ist, und natürlich schon gar nicht math/TeX: vulgo, sie passt explizit zu keinem der anderen angebote zu schneller eingabe, noch zu irgendeinem anderen angebote zu sauberer ausgabe, einschliesslich der unicode-spezifikation: sie ist schlicht nur ein hack (behübschungs-workaround), und völlig solitär-inkompatibel. würde sie auf den anderen standardisierten eingabemethoden aufsetzen, wäre das jedenfalls ein schritt vorwärts --W!B: (Diskussion) 15:04, 9. Jun. 2019 (CEST)
ASCII ist auf dem Friedhof und dort längst zu Kompost geworden. Bitte nicht wieder ausgraben!
Die Unicode-Direkteingabe beherrscht jedes System? Windows und MacOS X sind alles mögliche, aber bestimmt nicht »jedes System«. Gar so einfach darf man es sich nicht machen. –Falk2 (Diskussion) 16:16, 9. Jun. 2019 (CEST)
?? ascii ist schlicht in unicode aufgegangen, wenn man heute "ascii" sagt, meint man damit den Unicodeblock Basis-Lateinisch U+0000 bis U+007F, also im groben das, was die basis-tastaturbelegung ist. ascii wird erst zum kompost, wenn die tastatur zum kompost wird. und das dauert noch. nämlich, bis die lateinschriften abgeschafft werden. --W!B: (Diskussion) 18:09, 9. Jun. 2019 (CEST)
ASCII alleine patzt schon bei č und ř und eng gesehen bei allen Zeichen, die es ausgerechnet in der armen englischen Sprache nicht gibt. Dahin will niemand zurück, zumindest niemand außer Trump & Co. –Falk2 (Diskussion) 18:52, 9. Jun. 2019 (CEST)
 ?? wer hat hier je von "ascii alleine" gesprochen? und gerade diakritika aus Unicodeblock Lateinisch, erweitert-A und B sind alternativ immer auch mit Unicodeblock Basis-Lateinisch (plain-ascii) und Unicodeblock Kombinierende diakritische Zeichen setzbar: was man nimmt, ist gusto. tatsächlich ist zweiteres sogar wesenlich flexibler, und mittel der wahl, wenn eine sprache/umschrift nicht via erweitertem basis-lateinisch darstellbar oder eigenem codeblock implementiert ist. --W!B: (Diskussion) 10:31, 12. Jun. 2019 (CEST)

also: hier nochmal die gültige unicode-definiton, da die offenkundig bisher niemand wirklich gelesen hat (The Unicode Standard, Version 6.0 – Core Specification, 2011 [1])

Fraction Slash. U+2044 fraction slash is used between digits to form numeric fractions, such as 2/3 and 3/9. The standard form of a fraction built using the fraction slash is defined as follows:
any sequence of one or more decimal digits (General Category = Nd), followed by the fraction slash, followed by any sequence of one or more decimal digits.
Such a fraction should be displayed as a unit, such as ¾ or . The precise choice of display can depend on additional formatting information. If the displaying software is incapable of mapping the fraction to a unit, then it can also be displayed as a simple linear sequence as a fallback (for example, 3/4).
(formatierung der beiden "should be displayed" hier manuell visuell nach pdf)

das heisst:

  • entweder wir verlassen uns auf die unicode-spezifikation, dann ist die immer bevorzugte form 3 Fraction-Slash 4 sic – dann brauchen wir die vorlage:bruch gar nicht
  • oder wir verlassen uns nicht drauf, dann ist die bevorzugte form 3/4 ("simple linear sequence as a fallback"), formatiert nur mit XHTML – mit vorlage:bruch, aber umgebaut
    alternativ besser mit U+2215 DIVISION SLASH aus Unicodeblock Mathematische Operatoren (der in jeder schriftart wohl zumindest mit plain-ascii /U+002F SOLIDUS dargestellt wird), denn wir empfehlen auch − U+2212 MINUS SIGN aus diesem block (in den edit-tools, das heisst, wir könnten ihn dort nach dem ÷ oder beim ½ einbauen, für die schnelle eingabe).

wobei die Vorlage:Bruch auch buchstaben verarbeitet (1x ist möglich), was aber definitiv nicht unicodekonform ist (plain 1⁄x wird wohl nie sinnvoll werden), das heisst:

  • man empfiehlt hier alternativ Unicodeblock Hoch- und tiefgestellte Zeichen, also ¹⁄ₓ mit U+2093 LATIN SUBSCRIPT SMALL LETTER X (respektive die anderen schon früher implementierten hoch- und tiefgestellten buchstaben)
  • oder wir empfehlen für brüche mit variablen ausnahmslos math (dann können wir Vorlage:Bruch ebenfalls wieder eindampfen)

alles andere ist inkompatibler pfusch.
jedenfalls, die spezifikation führt weiter aus

If the fraction is to be separated from a previous number , then a space can be used, choosing the appropriate width (normal, thin, zero width, and so on). For example, 1 + thin space + 3 + fraction slash + 4 is displayed as 1¾.
(setzung für letzteres hier wieder visuell)

das heisst, unicode empfiehlt bezüglich gemischte Zahlen kompress nicht spezielles (gibt aber vielleicht thin space als best practice) --W!B: (Diskussion) 10:31, 12. Jun. 2019 (CEST)

Hm, und was wolltest Du nun den zwar geneigten, aber durch die majuskelfreie Bleiwüste auch ziemlich strapazierten Lesern damit nun sagen? Ohne eine halbwegs komfortable Tastatureingabe halte zumindest ich alles mit hoch- und tiefgestellten Zeichen für Muster ohne Wert. –Falk2 (Diskussion) 16:43, 12. Jun. 2019 (CEST)

naja, auch die eingabe von vorlagen, oder von math-code ist nicht allzu "komfortabel". dann empfehlen wir:

  1. plain ascii ("simple linear sequence", oben auch "augenkrätze" genannt), aber vorzugsweise mit U+2215 (verlässliche minimalvariante), und U+2215 in die edittools
    • allfällig mit Vorlage:Bruch (wenn die ebenfalls den U+2215 verwenden würde, und alle formatierung per XML macht), und Vorlage:Bruch in die edittools:wikisyntax
  2. oder unicode mit den vorhandenen bruch-glyphen der basisblöcke
    • ersatzweise U+2044 und hoch- und tiefgestellt (wen die eingabe nicht stört, aber nur für einfache numerische formen)
  3. oder math tfrac (aber nur, wenn math öfter im artikel vorkommt, wegen der unangenehmen auswirkungen auf den zeilenabstand, den unser math-modul nicht in den griff bekommt)

das sollte die unzulänglichkeiten der jeweiligen darstellungen halbwegs gleichmässig verteilen. 1. und 2. sind dann abwärtskompatibel c&p-fähig; und alle diese darstellungsformen lassen sich aufwärtskompatibel verfeinern und botgestützt manipulieren:

  • automatische ersetzung U+2215 zu U+2044, falls dereinst die unicodspezifikation des letzteren allgemein sauber implementiert ist; parallel rückbau der dann ebenfalls unnötigen vorlage:bruch; parallel umwandung aller hoch- und tiefgestellt in nachbarschaft eines U+2044 in normalzeichen;
  • oder alternativ automatische umwandlung der umgebung eines U+2215 resp U+2044 in eine tfrac-konstruktion, wenn unser math-modul dereinst für diesen zweck sinnvoll läuft
  • oder automatische umwandlung konsistent in unicode-bruch-glyphen, falls einmal ein block für alle einfacheren bruchzahlen kommt

und für gemischte zahlen form 1. empfehlen wir Vorlage:nnbsp oder thinsp mit Vorlage:nowrap aussen, für 2. nnbsp direkt (ohne vorlage, wer so eingibt, gibt unicode sowieso direkt ein), und für 3. \, (= 3/18 Em). das sollte halbwegs einheitlich sein: dieser abstand ist dann ca. so breit wie ein komma und ein tausenderpunkt oder -leerzeichen oder hochkomma, und die scheinen der passende abstand zu sein, um ziffern als eine zahl erscheinen zu lassen, und trotzdem zu gliedern --W!B: (Diskussion) 09:36, 18. Jun. 2019 (CEST)

Vorlage für Exponentialdarstellung[Quelltext bearbeiten]

Bisher empfiehlt diese Richtlinie für Zahlenangaben in Exponentialdarstellung die folgende Eingabe:

1,672&nbsp;·&nbsp;10<sup>&minus;27</sup>&nbsp;kg wird dargestellt als: 1,672 · 10−27 kg

Ich bin sicher nicht der Erste, der das als unangemessen mühsam empfindet. Dazu kommt der Malpunkt in der Mitte, den ich auf meiner Tastatur vergeblich suche. In der englischsprachigen Wikipedia wird seit langem die Vorlage verwendet. Vorhin stellte ich erfreut fest, dass diese Vorlage bei uns automatisch die deutsche Variante darstellt. Das bedeutet Dezimal-Komma statt Dezimalpunkt und Malpunkt statt Malkreuz. Konkret sieht das dann so aus:

{{val| 1,672| e=-27| u=kg}} wird dargestellt als: 1,672·10−27 kg

Das halte ich für sehr viel angenehmer handhabbar als die "rohe" Formatierung oben. Die Vorlage kann übrigens noch einiges mehr - Unsicherheit in verschiedenen Formatierungen, ein Link zum Artikel zur jeweiligen Einheit oder Tausendertrennung. Und als Bonus sind Tabellen mit so formatierten Werten sortierbar.
Was noch fehlt, wäre:

  • eine deutsche Übersetzung der Hilfeseite zur Vorlage (vorlage:val führt im Moment zu einer leeren Seite)
  • die Links zu den Einheiten-Artikeln sind teilweise defekt. (kg verlinkt zu [[Kilogram]], N verlinkt zu [[Newton (unit)]], aber immerhin m verlinkt erfolgreich zu [[m]])

Gibt es Einwände dagegen, diese Vorlage in die Richtlinie zu übernehmen? ---<)kmk(>- (Diskussion) 03:31, 30. Jul. 2018 (CEST)

Ja, mehrere.
  1. Namensgebung:
    • Drei Buchstaben als Namen verwenden wir heute nicht mehr neu; wenn überhaupt, dann mit einem selbsterklärenden deutschsprachigen Namen.
    • Der Vorlagenname val ist hierzuwiki reserviert für die Sprache „Vehes“.
    • Wenn überhaupt, dann nur mit einem längeren und selbsterklärenden deutschsprachigen Namen der Vorlage.
  2. Ausschließlich für Zahlen in Exponentialdarstellung und mit ggf. angehängter direkt verlinkter Maßeinheit, ohne Rückgriff auf andere Systeme. Dazu unten mehr.
  3. Die vorgeschlagene Syntax zielt in Wirklichkeit darauf ab, projektweit jede einzelne Zahlenangabe mittels val zu formatieren, indem einfach der Exponent e= nicht angegeben wird.
    • Die jüngste Umfrage Wikipedia:Umfragen/Zeichen für Zifferngruppierung, die von genau dem Ersteller der Vorlage:val initiiert wurde, zielte auf genau diese flächendeckende Verwendung von Vorlagen für jede einzelne Zahlenangabe im Wiki ab; egal ob Exponentialdarstellung oder nicht; egal ob Maßeinheit oder nicht. Dies erklärte der Initiator der Umfrage freimütig unter Wikipedia:Umfragen/Zeichen für Zifferngruppierung #Darstellung durch die Wiki-Software.
    • Ebendiese Umfrage ergab stattdessen, dass eine derartige Syntaxverkomplizierung in unseren Artikeln auf breiter Ebene abgelehnt wird. Wie notfalls ein MB gegen den hier gemachten Vorschlag ausgehen würde, ist absehbar.
    • Die Umfrage erwähnt Wikipedia:Umfragen/Zeichen für Zifferngruppierung #en:Template:Val ausdrücklich. Damit wird der U-Boot-Charakter des hier gemachten Vorschlags deutlich, der erstmal unschuldig mit dem Parameter e= daherkommt, um die Syntax tatsächlich zu vereinfachen, und es dann im nächsten Schritt einfach ohne diesen Parameter schlicht auf jede beliebige Zahlenangabe anzuwenden, nachdem erstmal Fakten geschaffen wurden und man heimlich den Fuß in die Tür bekam. KaiMartin war (verdeckt als kmk) unter den sehr wenigen Befürwortern in dieser Umfrage gewesen, die eine allgemeine Syntaxverkomplizierung anstreben, und muss sich des Zusammenhangs bewusst sein. Hier scheinheilig unter der Abschnittsüberschrift „Vorlage für Exponentialdarstellung“ aufzuschlagen und dann verdeckt per Mogelpackung solche weitreichenden Folgen einzuschmuggeln ist schon ziemlich dreist.
  4. Hinter der vorgeschlagenen Implementierung steckt die Übernahme eines hochkomplexen Systems von einem halben Dutzend Lua-Module der englischsprachigen Wikipedia, die nicht oder nur mangelhaft für eine Konfiguration in einer anderen Sprache oder einer anderen Projektstruktur programmiert wurden.
    • Für dieses Zeugs wird es hier keine fachkundige Pflege geben.
    • Triviale Updates der Module aus der englischsprachigen Wikipedia sind ebenfalls nicht möglich, weil die Kernprogrammierung nicht für eine dauerhafte Installation anderswo als in der englischsprachigen Wikipedia geschaffen wurde, und die Anpassung an fremde Projekte nicht vollständig separiert wurde, sondern vielmehr ein deutschsprachiger Fork der funktionalen Programmierung geschaffen und individuell gepflegt werden müsste.
  5. Wenn überhaupt eine Vorlage, dann ähnlich wie Vorlage:Bruch mit:
    1. selbsterklärendem Namen;
    2. ausschließlich für Zahlen in Exponentialdarstellung und mit ggf. umbruchgeschützt angehängtem beliebigen Text, etwa eine Maßeinheit, ohne eine automatisierte Generierung von Verlinkungen;
    3. in trivialer Vorlagenprogrammierung wie in Vorlage:Bruch ohne Verwendung von Lua-Modulen;
    4. ohne formatierende Eingriffe in die Komponenten Mantisse, Exponent, umbruchgeschützt angehängte Einheit;
    5. ohne Exponentialdarstellung nicht einsetzbar.
VG --PerfektesChaos 06:10, 30. Jul. 2018 (CEST)
Den meisten WP-Autoren ist solche "WP-Politik" ziemlich egal.
Eine Vereinfachung bei der Schreibweise von Exp-Zahlen würden sie (und ich) durchaus begrüßen.
Ob das dann "deWP-Politik-konform" oder "via U-Boot" geschieht - ist mir, und vmtl. den meisten anderen - ziemlich egal.
--arilou (Diskussion) 09:22, 14. Mär. 2019 (CET)

WP:SVZ am Satzanfang[Quelltext bearbeiten]

Ich glaube der Satz "Am Satzanfang werden Zahlen in Ziffern vermieden, indem man diese in Buchstaben schreibt oder den Satz umstellt." wird gerne missverstanden. Ich habe mal gefragt was man von sowas halten soll. Ich bekam als Antwort, dass es bei WP:SVP nicht darum geht, auf Krampf die Ziffer am Satzanfang zu entfernen. Ich zweifle hier stark an der Sinnhaftigkeit der Bearbeitung, die WP:SVZ als Grund enthält. Ich würde gerne eine Formulierung finden fie darauf hinweist, dass man nicht übertreiben soll.--Schweiz02 (Diskussion) 22:28, 28. Feb. 2019 (CET)

Deklination von Einheiten[Quelltext bearbeiten]

Ich sähe im Abschnitt Zahlen mit Maßeinheiten gern noch einen Hinweis, ob es erwünscht ist, Einheiten, die anhand der Präposition ihrer Angabe als Dativ aufgefasst werden können, entsprechend zu deklinieren. Ist es also eine Entfernung von 74,2 Kilometer oder eine Entfernung von 74,2 Kilometern? [2] macht deutlich, dass die Deklination nur im narrativen Kontext ihren Platz hat (ab zehn Metern Höhe wurde ihr schwindlig), nicht aber bei exakten Angaben, und begründet das im übernächsten Beitrag mit einer DUDEN-Regel. Ich fände es schön, hierzu ein klares Statement in der WP-Hilfe zu haben, da ich immer wieder auf Edits dieser Art stoße, die einen Dativ einsetzen, was ich zumindest unnötig finde. Mein Sprachgefühl hat gegen die erforderliche Höhe liegt bei 12,5 Meter nichts einzuwenden, da das ja nur eine Ellipse von … liegt bei dem Wert 12,5 Meter ist – die Höhe liegt ja nicht räumlich bei 12,5 Metern, als wären diese Meter aufgehäufte Gegenstände. Was sagt euer Sprachgefühl, wo findet man Regeln dazu? Mir liegt hier kein gedruckter DUDEN vor. --Kreuzschnabel 18:59, 4. Mär. 2019 (CET)

Das ist doch aber simpel: Ausgeschriebene Einheiten werden dekliniert. Davon abgesehen stören abgekürzte Einheiten im Fließtext ebenso häufig wie Ziffern (Wie liest man »Er kaufte 1 Möhre«?). Dafür brauchen wir keine zusätzlichen Regeln. –Falk2 (Diskussion) 19:27, 4. Mär. 2019 (CET)
So simpel scheinen das nicht alle zu finden, siehe [3] (vor allem die Beispiele). --Kreuzschnabel 19:38, 4. Mär. 2019 (CET)
Der Duden überrascht immer wieder aufs Neue (oder neue?) und missachtet dabei manchmal sogar seine üblichen Regeln. Ich stimme Falk2 zu: entweder eine Hohe von 12,5 m oder eine Höhe von 12,5 Metern, im Fließtext aber die letztere Variante. Schließlich steht die Präposition von immer mit dem Dativ und nie mit dem Akkusativ oder gar Nominativ. MfG Harry8 20:17, 4. Mär. 2019 (CET)
Dass „von“ mit Dativ steht, ist unstrittig. Siehe aber oben mein Argument mit der Ellipse, was bei „bei“ besonders deutlich wird. „Die Höhe liegt bei 8 m“ bedeutet ja nicht, dass da acht einzelne Meter rumliegen und die Höhe liegt daneben, sondern es heißt, dass sie in der Nähe des Wertes „8 Meter“ liegt. Und dieser Wert wird nicht dekliniert – „liegt bei 8 Meter“ habe ich übrigens in den 1980ern schon in der Schule gelernt, das ist keinesfalls Neuschrieb. Falls sich das allgemeine Sprachgefühl seitdem geändert haben sollte, bin ich gern dazu bereit, meines anzupassen. Daher die Frage, auch wenn ihr mich für doof halten solltet. --Kreuzschnabel 20:42, 4. Mär. 2019 (CET)
Vorab: Keiner hält dich für doof.
Die Sprache umfasst mehrere Möglichkeiten der Ausdrucksweisen, wie du schon richtig angegeben hast. 8 Pfennig war in der Regel ein bestimmter Geldbetrag. 8 Pfennige konnte auch dieser Geldbetrag sein, aber es konnten auch einzelne Pfennigstücke sein. Die Engländer unterscheiden da 8 pence und 8 pennies.
Nach meinem Dafürhalten muss das Wort Meter, um nicht dekliniert zu werden, direkt bei dem Wort Wert stehen, also: Die Höhe liegt bei dem Wert 8 Meter. Andererseits heißt es nach meinem Sprachempfinden: Die Höhe liegt bei 8 Metern. Die Beispielsätze sind aber wohl unglücklich formuliert. Ich würde schreiben: Die Höhe beträgt 8 Meter oder etwa 8 Meter. Bei kann nämlich auch für einen ungefähren, also nicht genauen Wert stehen. MfG Harry8 22:44, 4. Mär. 2019 (CET)

² und ³[Quelltext bearbeiten]

Im Artikel werden " ² " und " ³ " nur genau 1* erwähnt, dass sie nicht als Exponenten bei Exponentialdarstellung verwendet werden sollen.

Hier vertritt ein langjähriger Mitautor die Ansicht, dass bei üblichen Einheiten-Exponenten (m², m³ ; alternativ m2, m3) diese sogar vorranging verwendet werden sollen (wie er es in diesem Edit durchführt).

Es sollte in hiesigem Artikel genannt werden, ob ² und ³ dafür sinnvoll sind - oder auch beim Verwendungszweck "Einheiten-Exponent" unerwünscht sind.

--arilou (Diskussion) 08:59, 14. Mär. 2019 (CET)

Die hochgestellten ² und ³ (und nur diese) kommen in praktisch allen Zeichensätzen oberhalb von ASCII vor, damit würde ich Transport- und Darstellungsprobleme weitgehend ausschließen, was die Fragestellung auf den satzästhetischen Aspekt reduziert. Werden nur diese zwei gebraucht (für Flächen- und Volumeneinheiten), kann man davon ausgehen, dass sich die Exponentialglyphen besser in den Textfluss einfügen als hochgestellte Normalziffern, da sie nativ zum Schriftschnitt gehören (natürlich vorausgesetzt, die verwendete Schriftart enthält sie). In einem Text dagegen, der auch andere Exponenten verwendet und dort auf hochgestellte Ziffern zurückgreift, sollte das für ein gleichmäßiges Satzbild natürlich bei sämtlichen Exponenten einschließlich ² und ³ so gemacht werden. --Kreuzschnabel 09:44, 14. Mär. 2019 (CET)
Es steht mindestens angedeutet unter Hilfe:Sonderzeichen #Mathematische Zeichen: „Die Verwendung sollte deshalb auf offenkundige Flächen und Volumina wie m² und m³ beschränkt bleiben, wo die Bedeutung vertraut ist und sich bereits aus dem Zusammenhang ergibt.“
Dies wird zu 98 % oder 99 % auch so im Artikelbestand praktiziert; wohl bald eine halbe Million Artikel verwenden die ² und ³ für triviale Flächen, Volumina und einfache Kehrwerte, auch mal eine Beschleunigung. Die Cirrus-Suche versagt wegen zu großer Trefferzahl.
Lediglich bei komplexen naturwissenschaftlichen Ausdrücken und Exponenten außerhalb von 2 und 3 werden die HTML-Elemente durchgängig verwendet.
Ein Grund ist die Verkomplizierung des Wikitextes, während die Zeichen auf den meisten Tastaturen als Sonderzeichen belegt sind.
Umseitig steht das übrigens im Abschnitt „Exponentialdarstellung“, in dem es um die Notation sehr großer oder sehr kleiner Zahlen geht, also mit Zehn hoch und dann Exponent. Der Exponent 2 wäre unüblich, für 3 lohnt sich der Aufriss nicht, also müssen im Kontext auch Exponenten ungleich plus 3 auftreten und dann ist in diesem Bereich einheitlich zu gestalten.
Ich denke, über diese Frage ist so alle zwei bis drei Jahre schon mal erschöpfend diskutiert worden; direkt hier oder auf anderen Projektseiten. Es würde mich auch nicht wundern, wenn sich zusätzliche Textpassagen finden ließen, falls man die Geschichte der Projektseite mal in Halbjahresschritten durchgeht, und die irgendwer eingefügt und irgendwer wieder rausgelöscht hatte.
Ob das schwer oder leicht zu erkennen wäre, liegt übrigens an den Gegebenheiten beim Leser: Bildschirmauflösung, Schriftdesign, Schriftgröße, persönliche Sehschärfe.
superscriptMagnifier@PerfektesChaos vergrößert ansonsten die Zeichen für Leute, die es nicht gut erkennen können, jedoch eindeutig unterscheiden möchten.
VG --PerfektesChaos 11:03, 14. Mär. 2019 (CET)
Ich bin der Meinung, dass der Abschnitt Hilfe:Sonderzeichen#Mathematische Zeichen überarbeitet werden sollte. Die hochgestellten Ziffern 1, 2 und 3 (¹ ² ³) sollten nicht pauschal als "nicht zu verwendende Zeichen" gelistet werden, sondern als durchaus erlaubte und erwünschte Zeichen, auch in Artikeln. Das entspricht auch der Praxis. Deshalb haben wir ja auch ² und ³ extra in der Sonderzeichenleiste, damit sie verwendet werden können. --Neitram  11:44, 14. Mär. 2019 (CET)
@Neitram: Da steht aber was anderes: 1,2,3 können als Exponenten verwendet werden, alle anderen Hochzahlen und ausnahmslos alle tiefgestellten Ziffern nicht. Weil: Beim Leser im Font womöglich nicht unterstützt; nebenbei in icht selbsterklärendem Kontext obendrein Augenprobleme möglich. VG --PerfektesChaos 11:51, 14. Mär. 2019 (CET)
Lass uns diese Diskussion auf Hilfe Diskussion:Sonderzeichen#Mathematische Zeichen weiterführen, damit sie nicht gedoppelt wird. --Neitram  12:06, 14. Mär. 2019 (CET)

Vorschlag für diese Seite:

(hinten angehängt an Kapitel Wikipedia:Schreibweise von Zahlen#Exponentialdarstellung):

² und ³ können bei offenkundigen Angaben wie Flächen und Volumina, also zum Beispiel km² und cm³, verwendet werden, wo die Bedeutung sich bereits aus dem Zusammenhang ergibt und vertraut ist, sofern nicht in naher Umgebung weitere hoch- und tiefgestellte Zahlenwerte erscheinen (keine Misch-Schreibweise). Sieh hierzu auch Hilfe:Sonderzeichen#Mathematische Zeichen.

(Formulierung weitgehend übernommen aus Hilfe:Sonderzeichen#Mathematische Zeichen .) --arilou (Diskussion) 13:42, 14. Mär. 2019 (CET)

+1 Finde ich gut, den Vorschlag. --Neitram  14:50, 14. Mär. 2019 (CET)

Jahreszahlen[Quelltext bearbeiten]

Moin zusammen. Ich finde hier den Satz „Bei Jahreszahlen ... steht nie ein Tausendertrennzeichen.“ Das kann doch wohl nur für vierstellige Jahreszahlen gemeint sein, also nur für solche bis 9999 v. Chr. beispielsweise, oder? Bein einem weiteren Jahr „rückwärts“ würde ich 10.000 v. Chr. schreiben, und das scheint mir hier auch die Regel zu sein. --Hans-Jürgen Hübner (Diskussion) 19:06, 8. Sep. 2019 (CEST)

Der Tausendertrennpunkt ist immer falsch, das hatten wir schon ziemlich oft. Er ist nur bei Buchhaltern und sonstigen Geldgeiern üblich, die sich gegenseitig nicht trauen und mit den Punkten verhindern wollen, dass ihr Geschäftspartner noch eine Ziffer reinmogelt. Ansonsten ist der Tausendertrenner, der im deutschsprachigen Raum regelkonform ist, ein schmales Leerzeichen. Dass Du mit dem Verweise auf Jesus C. aus N. ebenfalls ein Problem erzeugst, weil es den neutralen Standpunkt verletzt, weißt Du? Homo sapiens ist auch im deutschsprachigen Raum nicht per Dekret christlich, die Bibel ist kein Geschichtsbuch und ob es diesen Jesus C. überhaupt gegeben hat, ist weiterhin fraglich. Das Einwohnermeldeamt von Beit Lam hat ihn jedenfalls nicht in der Kartei. »Das ham wir schon immer so gemacht« und »Das ham wir noch nie so gemacht« sind keine Argumente. –Falk2 (Diskussion) 22:18, 8. Sep. 2019 (CEST)
Hier geht es nicht um deine persönliche Meinung (auch nicht um meine), schon gar nicht um Schnellurteile gegenüber bestimmten Berufsgruppen. Und: Naja, die Datierung nach jenem Nazarener ist in den Wissenschaften Standard und damit verletze ich selbstverständlich nicht den neutralen Standpunkt. Aber das waren hier auch nicht die Fragen. Mein Problem ist: Ich sehe in zahlreichen Artikeln Angaben wie 11.000 v. Chr., meinetwegen auch 18.000 BP, v.u.Z. usw. Wenn der Tausendertrennpunkt tatsächlich immer falsch sein sollte, dann müsste dies in diversen Artikeln geändert werden. Bisher sehe ich in unseren Regularien auch kein schmales Leerzeichen, oder? Richtig schwierig wird es bei sechsstelligen Angaben, da sollte doch schon zugunsten der Lesbarkeit die optische Trennung in Dreierblöcke sinnvoll sein, auch bei Jahreszahlen. --Hans-Jürgen Hübner (Diskussion) 02:02, 9. Sep. 2019 (CEST)
Diese typografische Unart ist in der deutschsprachigen Wikipedia ein Geburtsfehler, der allerdings von einigen mit allen Mitteln verteidigt wird. Ich weiß nicht, wer damit angefangen hat, die anfänge liegen vor meiner Rechnernutzungszeit. Mir ist allerdings kein deutschsprchiges Gebiet bekannt, wo die Tausendertrennung durch Punkte in der Schule gelehrt wird. Denk doch einfach an deine eigenen Schulzeit. Bei mir in den frühen Siebzigern waren große Zahlen Stoff in der vierten Klasse. Schmale Leerzeichen kennen Setzer schon sehr lange. Die Schriftsatzunarten dürften insbesondere mit dem sehr unvollkommenen Zeichensatz ASCII eingerissen sein. Leider leiden die, die damit aufgewachsen sind, inzwischen an Altersstarrsinn. Den Sinn der Tausendertrennung ab fünfstelligen Zahlen hat übrigens noch nie jemand bestritten. Nur sind eben Punkte dafür nur in der Finanz- und Geldwirtschaft üblich, dort nur bei Geldbeträgen und das aus demselben Grund, warum auf Zahlbelegen der Betrag davor und dahinter durch Striche abgesperrt und in Worten wiederholt wird – eben als Schutz vor nachträglicher Veränderung. Das hat alles nichts mit Schnellurteilen gegenüber Berufsgruppen zu tun. Es wird allerdings eins, wenn Angehörige dieser Berufsgruppen Allmachtsphantsien entwickeln und die in diesem einen Fall begründete Setzweise auf den gesamten Schriftsatz ausdehenen wollen. Mit Unicode sind schmale Leerzeichen überhaupt kein Problem mehr. Man muss nur wollen und auch die Größe besitzen, uralte Zöppe endlich mal zu entsorgen. Wir brauchen für alle diese Fälle im Übrigen keine besonderen Richtlinien. Daran geilen sich nur einige Beckmesser immer wieder auf. Ich sehe absolut keinen Grund, wieder eine Änderungskampagne zu beginnen. Aus vierstelligen Zahlen beseitige ich den Tausendertrennpunktunsinn schon lange, wenn ich einen Artikel ohnehin bearbeite. Kampagnen sind mit seit jeher suspekt und Ordnungspolizisten, die sich in den Wikis in der Regel Administratorrechte erschleichen, ganz besonders. Ich mache das hier in meiner Freizeit und da sind solche Feldwebel, die im Übrigen in Artikelnamensräumen kaum beitragend bis verbessernd auffallen, grundsätzlich überflüssig. –Falk2 (Diskussion) 10:27, 9. Sep. 2019 (CEST)
Ich wollte hier eigentlich nicht die Frage aufwerfen, warum der Punkt und nicht das besagte Leerzeichen, zur leichteren Lesbarkeit eingefügt werden sollen, oder ob überhaupt. Ich stand vor dem Problem, dass Angaben wie „10.200–9.800 v. Chr.“ immer wieder in „10.200–9800 v. Chr.“ geändert werden. Dies schien mir in Gegensatz zum Satz „Wenn eine vierstellige Zahl jedoch innerhalb des laufenden Textes oder in einer Tabelle in direktem Zusammenhang zu Zahlen mit fünf oder mehr Stellen steht, so sollte zugunsten einer einheitlichen Darstellung auch für die vierstellige Zahl ein Tausendertrennzeichen verwendet werden.“ Hier geht es also um Einheitlichkeit. Dann folgt der besagte Satz über die stets ohne „Tausendertrennnzeichen“ zu schreibenden Jahreszahlen. Daraus ergibt sich ein Widerspruch, der mich hierher geführt hat. Mir persönlich ist es gleich, ob ich „10200–9800“ oder„10.200–9.800“ schreibe, aber einheitlich sollte es schon sein. Daher sollten die Formulierungen hier so gewählt werden, das Wohlmeinenden aber allzu Akribischen nicht schon wieder eine Vorlage geliefert wird, „verbessernd“ einzugreifen. Ich hoffe, so wird mein Problem klarer. --Hans-Jürgen Hübner (Diskussion) 18:19, 9. Sep. 2019 (CEST)
Ich schrieb weiter unten bereits, dass „Jahreszahlen“ kalendarische Jahreszahlen meint.
Die gleiche Regel steht auch in den Typografie-Tipps des Rechtschreibdudens – Jahreszahlen, Postleitzahlen, Seitenzahlen werden nicht gegliedert. Es soll also keiner auf die Idee kommen, 2.019 in unser momentanes Datum zu schreiben, und das wird da ausdrücklich nochmal aufgeschrieben.
Gedacht wurde dabei in erster Linie an die Zeit ab dem Mittelalter; aber bei den Ägyptern oder Babyloniern mag man das auch anwenden.
Voraussetzung ist immer, dass das einzelne Jahr konkret benannt wird, also im Kalender steht; Gaius Iulius Caesar starb am 15. März 44. Das geht nicht in vorhistorischen Zeiten.
Die Zeiträume „10200–9800“ oder „10.200–9.800“ sind mehr physikalisch gemessene Zeiträume. Da ist nichts am 1. Januar 10200 v. Chr. gesetzlich wirksam geworden.
Hier gelten nicht mehr die Regeln für Kalender, sondern für physikalische Zeitmessungen, wie sie auch in Geologie und Artrophysik vorkämen. Heißt: Gliederung.
Siehe ansonsten etwas weiter unten.
VG --PerfektesChaos 19:57, 9. Sep. 2019 (CEST)
Das sieht nach einer handlichen Regelung aus. Vielen Dank, --Hans-Jürgen Hübner (Diskussion) 22:14, 9. Sep. 2019 (CEST)
@Hans-Jürgen Hübner: Danke für deine Aufmerksamkeit. Ja, ich denke auch, der Satz meint nur vierstellige Jahreszahlen und habe es zur Verdeutlichung jetzt so ergänzt. --Neitram  13:08, 9. Sep. 2019 (CEST)
(BK)
Die umseitigen „Jahreszahlen“ meinen kalendarische Einträge; denken ohnehin eher positiv.
Die frühesten kalendarischen Einträge hätten die ollen Ägypter gehabt; auch bei denen wird es nicht fünfstellig.
Alle Angaben davor kennen keine jahresgenaue Datierung, sondern sind eher eine physikalische Angabe: Das Universum ist 14.000.000.000 Jahre alt, vor 65.000.000 Jahren starben die Dinos aus, die Pfahlbausiedlung ist 7.000 Jahre alt.
Rein theoretisch könnte irgendwann dendrochronologisch das Alter einer 15.000 Jahre alten menschlichen Feuerstelle auf das Jahr der Fällung des Feuerholzes genau bestimmt werden, aber ganz so lückenlos sind diese Daten wohl bislang nicht zusammengestückelt.
Unter Zurückweisung privater Einzelbetrachtungen im Übrigen. Ihm wurde schon vielfach verdeutlicht, dass es im Interesse der allgemeinen niedrigschwelligen Benutzbarkeit absolut unerwünscht ist, die von ihm eingeforderten 14&#8239;000&#8239;000&#8239;000 in unsere Wikitexte zu schreiben; womöglich auch noch im VisualEditor. Die Community hat derartige Zumutungen seit anderthalb Jahrzehnten stets abgelehnt; eine andere die Anforderungen hinsichtlich einfacher übersichtlicher Eingabe, leichter Datenkontrolle im Quelltext und sicherer Darstellung erfüllende Lösung konnte in anderthalb Jahrzehnten niemals irgendjemand präsentieren.
VG --PerfektesChaos 13:22, 9. Sep. 2019 (CEST)