Wikiup:Umfragen/Zeichen für Zifferngruppierung

Diese Umfrage ist beendet. Bitte nimm an dieser Seite keine Veränderungen mehr vor.

Obwohl es in Deutschland üblich ist, die Ziffern mit einem Punkt zu gruppieren, sollte man die Empfehlung, die Ziffern nur mit Leerzeichen zu gruppieren, in der Wikipedia umsetzbar machen, weil nicht nur im englischen Sprachraum (und damit auch bei vielen in Deutschland verwendeten Taschenrechnern), sondern auch z.B. in einigen Teilen der deutschsprachigen Schweiz die Bedeutung von Punkt und Komma gerade vertauscht sind. Leider gibt es dafür kein gut passendes Zeichen. Man müsste ein kleines geschütztes Leerzeichen dafür haben. Derzeit bräuchte man für 75.000.000 die Sequenz aus 75<small>&nbsp;</small>000<small>&nbsp;</small>000, mit dem Resultat 75 000 000. (Oder auch zweimal "small"). Dies bläht aber den Quelltext stark auf und wäre eine häufige Fehlerquelle bei Artikeländerungen.

Deswegen meine Umfrage: Könnte man ein eigenes Zeichen zur Zifferngruppierung (wie z.B. "&zffg") definieren, das diesselbe Wirkung hat? --Nov3rd17 (Diskussion) 12:16, 7. Apr. 2018 (CEST)

Die Umfrage läuft 2 Monate, also bis zum 7. Juni 2018.

Ideen bzw. Meinungen dazu

• Gibts doch schon: &#82x39;, bspw. 100 000. --MGChecker – (📞| 📝| ) 12:57, 7. Apr. 2018 (CEST)
• Also &#8239; eintippen kannst knicken. Die Nummer merkt sich keiner. &nnbsp; nennt sich das Zeichen, aber welcher Browser kann das? So eine Formatierung mit kryptischem &#8239; kannst in eine Vorlage einbauen, wobei natürlich auch die Frage ist: Wer verwendet eine Vorlage, wenn es ohne auch geht? --Wurgl (Diskussion)
• Ich sehe den Sinn nicht. Bei schweizbezogenen Artikeln wird ja schon üblicherweise die Schweizer Variante verwendet. -- Chaddy · D 21:58, 7. Apr. 2018 (CEST)
• Die Wikipedia:Richtlinien_Physik#Darstellung von Werten empfielt schon immer einen thinspace: <math>100\,000\,000</math>, bzw als HTML 100&thinspbla;000&thinspbla;000 das ist glaube ich das gleiche wie die 8239 oben.--Debenben (Diskussion) 18:33, 8. Apr. 2018 (CEST)

  Thinspace ist &#8201; Aber ich sehe keinen visuellen Unterschied … wenn ich ganz große Schrift mit Ctrl-+ mache, dann ist Narrowspace um 1 Pixel breiter.

  100 000 Thinspace (als Nummer)

  100 000 Thinspace (als &thinsp;)

  100 000 Narrowspace --Wurgl (Diskussion) 18:51, 8. Apr. 2018 (CEST)

Ich habe mal nachgeschaut. Ich glaube der Hauptunterschied ist, dass der narrowspace 8239 ein non-breaking space ist, während der thinspace 8201 Zeilenumbrüche erlaubt. Wahrscheinlich ist ersteres im Normalfall sinnvoller.--Debenben (Diskussion) 21:28, 8. Apr. 2018 (CEST)

Das wirklich korrekt zu machen, geht wahrscheinlich nur mit einer Vorlage {{NumberFormat|value= |locale=}} so ähnlich wie bei {{DateFormat}}, aber Vorlagen erzeugen bei jedem Abruf Serverlast und Netzwerktraffic. Vorteil wäre, dass je nach Lokation/locale des Lesers die Zahl korrekt formatiert wäre. Eine eigene HTML-Entity zu definieren wird hier wohl keiner schaffen. Es gäbe noch die Chance, eine Ersetzen-Vorlage zu erstellen, die automatisch beim Einsetzen die Zahl formatiert.--Alturand…D 15:44, 17. Apr. 2018 (CEST)

Alturand, das gibt es mit Vorlage:FormatNum schon. --Gr1 (Diskussion) 16:06, 17. Apr. 2018 (CEST)

@Alturand: Vorlagen verursachen nicht bei jedem Abruf Extralast – die Resultate werden in einem Cache gehalten. Nur wenn die Vorlage verändert wird, kommt es bei einer größeren Zahl an Verwendungen zu einer Extralast. Und natürlich muss die Vorlage bei jeder Bearbeitung neu ausgewertet werden – das ist aber nicht so häufig und nicht so dramatisch. --AFBorchert 🍵 17:52, 17. Apr. 2018 (CEST)

Merci. Dann sehe ich das Problem nicht.   ist der richtige Weg, oder die Math-Umgebung. Wenn sich die Formatierung nach dem Leser richten soll, dann geht Vorlage:FormatNum und wenn der Autor die Schreibweise festlegen will, dann macht er das eben.--Alturand…D 22:51, 17. Apr. 2018 (CEST)

• In den Naturwissenschaften wird seit Jahrzehnten kein Punkt zur Tausendertrennung verwendet. Wenn gruppiert wird, dann mit einem Abstand. Wobei der Abstand je nach Stil und Satztechnik größer, oder kleiner ausfällt. Die relevante internationale Norm dafür ist ISO 80000-1:2009. Gemäß dieser Norm ist eine Gruppierung von Ziffern erlaubt. Dabei sind allerdings Punkt und Komma als Trennzeichen ausdrücklich ausgeschlossen. Unsere Richtlinien empfehlen dagegen Punkte als erste Wahl zur Tausendertrennung. Abstände zur Trennung werden als "umstritten" qualifiziert und damit implizit von ihnen abgeraten. Meine Meinung: Es ist ein Unding, dass wir in Artikeln wie Lichtgeschwindigkeit begründen müssen, warum dort Werte so geschrieben, wie in der Fach- und Lehrliteratur üblich. -<)kmk(>- (Diskussion) 21:57, 18. Apr. 2018 (CEST)
• Das Hochkomma ist am Besten, da die Verwechslung mit einem Komma nicht möglich ist: 10'000 kann nicht mit 10.000 verwechselt werden. Das Hochkomma sollte überall eingeführt werden.--Keimzelle talk 01:45, 24. Apr. 2018 (CEST)

Ja - mag sein - aber das versteht in Deutschland kaum jemand! Alles so belassen wie bisher - kein wirklicher Änderungsbedarf--Lutheraner (Diskussion) 13:54, 24. Apr. 2018 (CEST)

• Ich würde es technisch lösen, d.h. im Quelltext steht einfach die Zahl z.B. 10000 ohne jegliche Formatierung. Die Formatierung erfolgt erst später beim dargestellten Text, so dass daraus dann bspw. 10.000 bei Spracheinstellungen "de-DE" wird. Die Formatierungseinstellungen sollte man aber individuell anpassen können, so dass jeder bekommt, was er möchte/gewohnt ist. (Über die Artikel hinweg wäre die Darstellung so auch einheitlich, so dass ich mich als Leser nicht fragen müsste, warum bei einem Artikel ein Punkt, beim anderen ein (Hoch-)Komma und beim nächsten ein (geschütztes) Leerzeichen steht. Und auch Diskussionen wie beim CERN zum Thema Schweizbezogen hätten sich bei dem Punkt erledigt.) --Doc ζ 14:03, 28. Apr. 2018 (CEST)
• So etwas sollte heutzutage nicht mehr bei der Textauszeichnung, sondern beim Rendern erledigt werden. Die Benutzer sind schon überfordert, sich an die Datumskonventionen zu halten, sie scheitern an genügend Vorlagen und Regeln, während woanders immer mehr serverseitig aufgefangen wird, z.B. die immer häufiger anzutreffende automatische Silbentrennung auf Websites, teils durch den Server, wenn weiche Trennstellen eingefügt werden, teils ganz durch den Webbrowser erledigt. Ein Fall für MediaWiki.--Aschmidt (Diskussion) 12:35, 30. Apr. 2018 (CEST)
• Könnte man danzu nicht eine Vorlage machen? Also {{Zahl|10000000}} die das dann erledigt? Ist auf jeden Fall besser zu lesen als jeden Punkt einzeln im Sourcetext zu haben. Generator (Diskussion) 00:29, 4. Mai 2018 (CEST)
• Es gibt einen [zu] umfangreichen Wiki Artikel Geschütztes Leerzeichen. Dort kann man sich diverse Kodierungen sowie Darstellungsweisen auf Computersystemen und Softwareprodukten raussuchen. --79.245.235.88 15:59, 9. Mai 2018 (CEST)
• Zum Hochkomma in Schweizbezogen Artikel: Dieses gilt schon seit Jahren als veraltet. Der aktuelle Standard sieht ein Lehrzeichen als Tausendertrennzeichen vor. Die Vorlage {{FormatNum}} sollte eigentlich mal angepasst werden. Siehe [Schreibweisungen Seite 80] Frohes Schaffen — Boshomi ⌨   14:44, 27. Mai 2018 (CEST)

Auf die Gefahr hin dass die Umfrage völlig vom eigentlichen Thema wie man die Zifferngruppierung mit Abständen technisch umsetzen könnte hin zur Dezimalkomma und Punktfrage in der Schweiz abdriftet: Mir war damals beim Überfliegen der Auszeichnungskandidaturseite der Kommentar von Benutzer:Krib aufgefallen, der sich an den Dezimalpunkten im Artikel Pax-Gebäude (Hauptautor Benutzer:Alabasterstein) gestört hat: Laut Wikipedia:Schreibweise_von_Zahlen#Dezimaltrennzeichen sollten Dezimalpunkte nur für Geldbeträge in Schweizer Franken verwendet werden.--Debenben (Diskussion) 22:38, 1. Jun. 2018 (CEST)

• Ich sehe nicht wirklich Änderungsbedarf, da der Staus quo meiner Meinung nach gut funktioniert, könnte aber auch gut damit leben, wenn nichtumbrechender typografischer Weißraum in der breite eines schmalen umbruchgeschützten Leerzeichens als gleichwertige alternative Schreibweise festgelegt wird. Ich halte es für sinnvoll, wenn Tausendertrennzeichen beim Copy and Paste nicht mitkopiert werden, daher sollte insbesondere ein aus typografischem Weißraum bestehendes Tausendertrennzeichen zum Beispiel in der Form <span style="margin-left:0.167em"></span> realisiert werden, damit beim Copy and Paste aus 1000000000,123456789 1000000000,123456789 wird (durch eine Vorlage oder eine Parserfunktion kann man das bei Bedarf zwecks Lesbarkeit des Quelltextes „hübscher“ und vor allem zwecks einfacherer Bearbeitbarkeit des Quelltextes kürzer und leichter merkbar gestalten). Dort, wo schmale umbruchgeschützte Leerzeichen zwischen Text stehen, zum Beispiel innehrhalb von Abkürzungen oder zwischen Zahlenwert und Maßeinheitensymbol halte ich hingegen die Verwendung des schmalen umbruchgeschützten Leerzeichens „NARROW NO-BREAK SPACE“, Unicode U+202F (8239) (HTML-Zeichenentität   oder  ) für sinnvoll, da es in diesen Fällen angebracht ist, dass das Zeichen beim Copy and Paste erhalten bleibt. Die aktuelle W3C Recommendation HTML 5.2 vom 14. Dezember 2017 enthält für U+202F leider keinen „character reference name“ (benannte Zeichenentität). Die Wikipedia-Software ersetzt aber ohnehin selbstständig alle ihr explizit als solche bekannten named character references außer >, <, & und " durch unbenannte. (Sie ist dabei allerdings leider nicht auf dem aktuellen Stand von HTML 5.2, sondern auf dem Stand von HTML 4.01 und XHTML (siehe phabricator:T94603) und wandelt daher jüngere named character references wie zum Beispiel Č, č, ě, ř und ž bei der Generierung des HTML-Quelltextes in Č, č, ě, ř und ž um, wodurch sie in der HTML-Seite als Name und nicht als Glyphe dargestellt werden.) Wenn also die Wikipedia-Software eine eigene (leider nicht aktuelle) Liste von Zeichenentitäten führt, die sie selbstständig umwandelt, könnte man prinzipiell in diese Liste auch eigene Definitionen eintragen, die im HTML-Standard nicht enthalten sind; ich bin aber sehr skeptisch, ob man dies wirklich tun sollte. --X black X (Diskussion) 11:30, 8. Jun. 2018 (CEST), korrigiert 11:35, 8. Jun. 2018 (CEST) und 00:07, 9. Jun. 2018 (CEST)

  Wichtig ist, dass im Quelltext auf gar kleinen Fall mehr als maximal ein einziges Zeichen zwischen den Gruppen steht, m.a.W.: Dass die Zahl im Quelltext klar und eindeutig für jedermensch als Zahl erkennbar und bearbeitbar ist und bleibt. Jegliches Einfügen von nerdigem Unsinn in den Quelltext ist zu vermeiden. Grüße vom Sänger ♫ ^(Reden) 11:51, 8. Jun. 2018 (CEST)

zu den technischen Problemen

Um zurück zur Frage der technischen Umsetzung zu kommen, mal eine Zusammenstellung was ich an Problemen sehe:

• Wenn man bei Wikipedia eine gute math-Erweiterung hätte, würde es Sinn machen die Zahlen im mathe-Modus zu setzen. Leider ist das Gegenteil der Fall, die Liste an Problemen spare ich mir an dieser Stelle, das Thema regt mich schon genug auf.
• &#8239; kann sich niemand merken, &nnbsp; verstehen die meisten Browser nicht, daran können wir nichts ändern.
• Vorlage:Nnbsp verwendet <span style="margin-left:0.167em"><span style="display:none">&nbsp;</span></span>. Mit diesem Hack ist das Leerzeichen nicht kopierbar, ich weiß nicht ob sich Screenreader daran stören.
• &thinsp; erlaubt Zeilenumbrüche, das könnte man theoretisch mit <span style="white-space:nowrap">&thinsp;</span> ändern, keine Ahnung ob das besser ist als das was die Vorlage macht.
• Vorlage:FormatNum mit Parameter de (standardmäßig wird dewiki verwendet). Allerdings scheint mir die Ausgabe entgegen dem was in der Dokumentation steht ein normalen non-break-space zurückzugeben. Vielleicht weiß ja @PerfektesChaos: warum.

Demo:

• 100 000 000 mit &#8239;
• 100&nnbsp;000&nnbsp;000 mit &nnbsp;
• 100 000 000 mit Vorlage:Nnbsp
• 100 000 000 mit &thinsp;
• 100 000 000 mit Vorlage:FormatNum
• 100 000 000 mit &nbsp;

--Debenben (Diskussion) 19:15, 20. Apr. 2018 (CEST)

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx * 100 000 000 000,00 (bei Zeilenumbruch, klares Nein)Tangomoos (Diskussion) 07:43, 27. Apr. 2018 (CEST)

Im Modul stand von Anfang an ein   – das ist gerade das, was der Wiki-Server nach draußen gibt, wenn man ein   in den Quelltext schreibt.

Vor fünf Jahren ging das auch als   nach draußen.

Vermutlich seit der Parser-Umstellung im letzten Dezember wandelt der Wiki-Server es jedoch in ein normales Leerzeichen um; ich habe ihm deshalb soeben noch ein nowrap gegeben.

Es war übrigens immer schon ein besonders aufwändiges <span>-Konstrukt gewesen, niemals ein womöglich problematisches  .

Beim C&P bekommt die Außenwelt jetzt halt ein normales Leerzeichen.

VG --PerfektesChaos 21:08, 20. Apr. 2018 (CEST)

Status quo

• Solange beim Status quo (D/A: Punkt; CH: Hochkommata bzw. &nbsp;) belassen, bis es eine Lösung gibt, die jeder versteht und die für alle DACH-Länder gleich ist. --Gr1 (Diskussion) 15:32, 17. Apr. 2018 (CEST)
• 📜 75.000.000 sollen 75.000.000 bleiben. ❗ In schweizbezogenen Artikeln wird kein ß geschrieben, da kann man auch den Tausenderpunkt weglassen. --🗡Siebert (P.W. Siebert) 16:57, 17. Apr. 2018 (CEST)
• Was spricht dagegen, diese spezielle Schreibweise auf entsprechende schweizbezogene Artikel zu beschränken? --AFBorchert 🍵 17:54, 17. Apr. 2018 (CEST)
• Lösung sucht Problem. Außerdem: 6 Monate? Im Ernst? --Gridditsch 19:00, 17. Apr. 2018 (CEST)
• Status quo ist akzeptabel. Die Länge einer Umfrage sollte drei Monate nicht überschreiten.  Dostojewskij 21:54, 17. Apr. 2018 (CEST)
• Ich sehe hier kein Problem. --Morten Haan 😈 Wikipedia ist für Leser da • Übersichtliche Artikelkriterien 23:01, 17. Apr. 2018 (CEST)
• Als jemand, der sowohl englische als auch deutsche Texte, gern auch durcheinander, liest: Kein Problem. Auch bei unterschiedlicher Verwendung von . und , ergibt sich die korrekte Dimension zumeist aus dem Kontext. Bei 75,000,000 ist klar, dass , hier kein Dezimaltrennzeichen ist. —viciarg 23:26, 17. Apr. 2018 (CEST)

Ist überhaupt nach der Formatierung an sich gefragt? Ich finde allerdings schon, dass häufig Verwechslungsgefahr besteht (Beispiel: Die Infobox im Artikel Erde). Weil international und daher in Suchmaschinen, Datenbanken, Algebra-Programmen, Programmiersprachen usw. immer Dezimalpunkte und manchmal Kommatas zur Zifferngruppierung verwendet werden, werden sie häufig (versehentlich?) auch in deutschsprachigen Wikipedia-Artikeln übernommen. Nicht ohne Grund werden im naturwissenschaftlichen Bereich schmale Leerzeichen zur Zifferngruppierung verwendet und sind von DIN, EN, Duden usw. in Deutschland, Österreich und der Schweiz vorgeschrieben.--Debenben (Diskussion) 00:20, 18. Apr. 2018 (CEST)

• Im Wesentlichen wie viciarg: Verstehendes Lesen hilft, auch bei Zahlen. Und selbst mir als Norddeutschem leuchten Darstellungen wie 75'000 oder 75,000 (wenn offenkundig fünfundsiebzigtausend gemeint sind) durchaus ein. Daher: Für mich ist kein Änderungsbedarf gegeben. --Altkatholik62 (Diskussion) 05:18, 18. Apr. 2018 (CEST)
• Zuerst sollte sich der englische Sprachraum und die Schweiz umstellen. Danach wir. --AchimP (Diskussion) 13:44, 18. Apr. 2018 (CEST)
• Prinzipiell wären für solche Dinge (wie auch bei "US-" und "*/†" Konflikten) Softwarelösungen charmant. Diese sollten alle (les- und editierbaren) Arten der Eingaben erkennen und den Nutzern diese wieder auf ihre bevorzugte Art & Weise anzeigen. Aber bitte keine Vorlagen (oder html Entitäten) oder ähnliches ... dann lieber den Status Quo und manche Leser lernen halt beim Lesen einer Enzyklopädie mal was. Ich musste in Wikipedia auch lernen wer oder was ein "Jänner" ist - hat mir nicht geschadet. --mirer (Diskussion) 14:49, 18. Apr. 2018 (CEST)
• Umgekehrt. Die Schweizer sollen endlich Deutsch und die Amis richtig zählen lernen. Realwackel (Diskussion) 09:19, 19. Apr. 2018 (CEST)
• --Gripweed (Diskussion) 22:43, 20. Apr. 2018 (CEST) Ich sehe da kein Problem.
• keine Sonderlösung, die man sich nicht merken kann und für die Neulinge dann regelmäßig angemacht werden --Riepichiep (Diskussion) 20:17, 21. Apr. 2018 (CEST)
• Ich bin auf jeden Fall für Einheitlichkeit (mit Ausnahme Schweiz, die für sich genommen aber auch einheitlich schreibt) und Sonderzeichen sollte man nur dann nutzen, wenn sie wirklich nötig sind. Ich sehe keinen Grund, weshalb wir auf den allgemein üblichen Dezimalpunkt verzichten sollten. Wozu Vorlagen nutzen, wenn es ein Punkt (bzw. Hochkommata) genauso tut? --H7 ^{Ein fröhlicher Franke} _(reden) 18:18, 22. Apr. 2018 (CEST)

  In den Naturwissenschaften sind weder Punkt noch Hochkomma zur Tausendertrennung üblich.---<)kmk(>- (Diskussion) 21:04, 23. Apr. 2018 (CEST)

  Wikipedia ist keine naturwissenschaftliche Publikation, sondern enthält lediglich naturwissenschaftliche Themen, das ist ein Unterschied! Die Tatsache, dass wir über naturwissenschaftliche Themen schreiben, heißt nicht automatisch, dass wir naturwissenschaftliche Schreibweisen befolgen müssen, solange der Inhalt dadurch nicht verändert wird. --H7 ^{Ein fröhlicher Franke} _(reden) 11:42, 26. Apr. 2018 (CEST)

  Auch in naturwissenschaftlichen Lehrbüchern angefangen mit Schulbüchern der Sekundarstufe sind Dezimalpunkte nicht üblich. In der Primarstufe nur deswegen nicht, weil da so große Zahlen schlicht noch nicht im Lehrplan sind. Im Rest der Welt außerhalb Wikipedia sind Punkte als Tausendertrenner die Ausnahme, nicht die Regel. Siehe auch die diversen Normen und Regularien.---<)kmk(>- (Diskussion) 18:03, 29. Apr. 2018 (CEST)

• In der CH bliebt es so wie es ist, im Rest der WP auch - wo sollte das Problem sein? Was ist so schlimm an so einem Unterschied? --Elmie (Diskussion) 10:00, 24. Apr. 2018 (CEST)
• Es gelten die Duden-Regeln. Demnach ist der Tausender-Punkt Kür, das Dezimalkomma Pflicht. Wenn's die Amis andersherum machen, ist das ihr Problem. Die rechnen auch in den Fußlängen König Edward II, in mittelalterlichen Fassgrößen (Gallonen) und in hintereinandergelegten Gerstenkörner (Inch). Kein Vorbild. --Zweimot (Diskussion) 12:43, 24. Apr. 2018 (CEST)
• Quasi wie Vorschreiber Zweimot. Frage: Weshalb 6 Monate Laufzeit? --Flönz (Diskussion) 19:04, 24. Apr. 2018 (CEST)

  @Zweimot, Blootwoosch: Der Duden schreibt Zwischenräume vor [1]. Ich halte übrigends nichts von dem Abstimmungspunkt "Status Quo": Der Status quo ist eine Richtlinie die den Duden-Regeln widerspricht, "umstritten" ist und nicht durchgesetzt wird. Sinnvolle Abstimmungsoptionen in dem Fall dass man die ursprüngliche Frage der technischen Umsetzung geklärt hätte wären: 1. Richtlinie mit Punkten verbindlich durchsetzen 2. Richlinie von Punkte auf Leerzeichen ändern 3. Richtinie aufweichen und Leerzeichen (eingeschränkt) erlauben 4. Richtlinie abschaffen.--Debenben (Diskussion) 22:52, 24. Apr. 2018 (CEST)

  „Der Duden schreibt Zwischenräume vor“ – Das ist schlicht falsch. Der Duden schreibt überhaupt nichts vor.

  Anders als für die Rechtschreibung gibt es für die Typografie weder Regeln noch Vorschriften noch irgendwelche amtlichen Standards oder Verpflichtungen. Wie auf WD:TYP regelmäßig nachzulesen ist, hatte es bis vor einem halben Jahrhundert sowas mal für Bleisetzer gegeben; heute nur noch für angelernte Schreibkräfte im Büro, die der Arbeitgeber dann als Maßstab für seine Firma vorgibt, um kostengünstig nett aussehende Geschäftsbriefe zu erhalten.

  Der Duden selbst nennt das lediglich „Hinweise“ – „Rechtschreibduden“ (Band 1), 27. Auflage, S. 110 – dort ist übrigens auch von „sachlich begründeten Abweichungen“ die Rede, und genau diese liegen in der WP vor.

  VG --PerfektesChaos 10:45, 25. Apr. 2018 (CEST)

• Gibt doch &#8239:, wozu jetzt was Neues? --Jojhnjoy (Diskussion) (Aktivität) (Schwerpunkte) 02:33, 25. Apr. 2018 (CEST)
• Ich bin auch absolut für die Beibehaltung des Status Quo. --Baumfreund-FFM (Diskussion) 11:24, 1. Mai 2018 (CEST)
• Kein Änderungsbedarf --Otberg (Diskussion) 12:59, 3. Mai 2018 (CEST)
• Keine Massenänderungen im Artikelbestand, kein Masseneinbau von Vorlagen in den Artikelbestand. --Magiers (Diskussion) 12:54, 4. Mai 2018 (CEST)
• In der de-WP Tausenderpunkt ab 1.000 (nicht erst ab 10.000). In schweizbezogenen Artikeln kann man es machen wie dort üblich. --Saloa (Diskussion) 13:55, 4. Mai 2018 (CEST)
• Kein Änderungsbedarf. --Druschba 4 (Diskussion) 00:12, 7. Mai 2018 (CEST)
• Für mich kein Nutzen erkennbar. --Zinnmann d 10:55, 7. Mai 2018 (CEST)
• Internationale Einheitlichkeit gibt es bei diesem Thema nun einmal nicht (v.a. Komma/Punkt vertauscht). Das hier ist die deutschsprachige Wikipedia und gut ist. Wenn ein paar Schweizer das anders machen, mag es eine schweizbezogene Regel geben oder auch nicht. Dem Rest kann das egal sein. --KnightMove (Diskussion) 18:14, 7. Mai 2018 (CEST)
• Kein Änderungsbedarf. --JasN (Diskussion) 00:10, 8. Mai 2018 (CEST)
• Keep it simple. --Parvolus 00:37, 10. Mai 2018 (CEST)

"Keine Massenänderungen und Masseneinbau von Vorlagen in den Artikelbestand" ist verständlich, zumal selbst Vorlage:FormatNum mit Parameter de die Tausendertrennung mit Abständen derzeit nicht gut hinbekommt. Von offizieller Seite ist die Komma/Punkt Frage im gesamten deutschsprachigen Raum einheitlich: Komma für Dezimaltrennung und Abstände für Tausendertrennung. "Kein Änderungsbedarf" kann ich nicht nachvollziehen: Soll die Vorlage also nicht repariert werden, die math-Erweiterung immer kaputt bleiben, Lua-Module immer etwas anderes ausgeben als man reinschreibt, Unicode-Direktzeichen (z.B. lateinisches vs. griechisches Α) nie im Quelltext unterscheidbar sein usw. damit man auf gar keinen Fall die offizielle Schreibweise in Wikipedia verwenden kann oder was genau ist damit gemeint? --Debenben (Diskussion) 23:38, 13. Mai 2018 (CEST)

• Keine Massenänderungen für Editjäger, Kein Änderungsbedarf--Roland Kutzki (Diskussion) 11:12, 18. Mai 2018 (CEST)
• +1 (aus statistischen Gründen)
  • Ich kann keinerlei neue Erkenntnisse im Sinne des Umfrageziels feststellen.
    • Diese Angelegenheit ist auf WD:SVZ im letzten Dutzend Jahre wohl knapp zwanzigmal durchgekaut worden, mit null Ergebnis und oft immer wieder von denselben Leuten initiiert.
    • Es hat sich im letzten Dutzend Jahren praktisch nichts an den Rahmenbedingungen geändert, weder an der Erfordernis eines einfachen, leicht verständlichen und ohne technische Spezialkenntnisse von allen zu bearbeitenden Wikitextes, noch gibt es bei den technischen Gegebenheiten irgendeine maßgebliche neue Entwiicklung.
    • Der einzige Vorteil ist, dass der nächste, der in den nächsten fünf Jahren auf WD:SVZ wieder mit derselben Leier aufschlägt, nunmehr knapp geerlt werden kann mit Verweis auf die Summe der Abschnitte #Status quo + das satirischen #Der Quelltext der Artikel ist noch nicht überfrachtet genug versus aller anderen.
    • Alles Nachtreten und alle weitergehenden Wünsche sind einem MB zu überantworten. Ende.
  • Einfachheit der Bearbeitung
    • Jeder Bearbeiter hat auf allen Geräten aller Art immer eine . in Reichweite, und da einmal drauf und fertig. Schweizer meinethalben '. Irgendwelche Browser-Skin-Software-VisualEditor-JavaScript-abhängigen Shortcut-Gadget-Dingsdas sind nicht massentauglich.
    • Der Initiator der Umfrage hat ausweislich #Darstellung durch die Wiki-Software die Vorstellung, jegliche der Abermillionen fünfstelliger Zahlenwerte (im Unterschied zu Schlüsselnummern, IP-Adressen usw.) und der in ihrem unmittelbaren textlichen Umfeld auftauchenden vierstelligen Zahlenwerte durch manuelle Entscheidung in einer Vorlageneinbindung zu verpacken, und damit sollen jetzt alle Autoren endlich anfangen, weil die langweilen sich ja und haben nichts Inhaltliches mehr zu tun.
    • Auf Rückfrage, nicht nur die relativ wenigen Ausnahmefälle wie Patent- und Lokomotivnummern zu kennzeichnen und den Rest einem angeblichen superschlauen Algorithmus zu überlassen, hieß es vom Initiator der Umfrage ausdrücklich, dass alle Zahlenwerte positiv zu klassifizieren seien.
    • Wer die Besucherkapazität eines Fußballstadions oder die Anzahl verkaufter Bücher oder Fahrgastzahlen angeben wolle, der müsse gefälligst dazu zukünftig eine Vorlage einfügen bzw. einen Vorlagenparameterwert aktualisieren.
    • Das widerspricht jedoch einem Grundprinzip und Erfolgsrezept der Wikipedia, wonach eine Änderung der Artikel möglichst einfach und niedrigschwellig möglich sein müsse.
    • Welche Vorlage oder Parserfunktion genau jetzt für die Einkleidung jeder größeren Zahl herangezogen werden solle ist dabei völlig irrelevant.
  • Einheitlichkeit
    • Ein weiteres Erfolgsrezept der Wikipedia lautet, dass wir mit möglichst wenigen und möglichst einfachen Regeln auskommen wollen, die möglichst wenige Ausnahmen vorsehen sollen. Wenn überhaupt eine Regel, dann nur, weil der Nutzen dem regellossen Zustand deutlich überlegen wäre.
    • Die Vorschläge, Uneinheitlichkeit zuzulassen und unterschiedliche Formatierungsregeln für wissenschaftliche und für unwissenschaftliche Zahlen einzuführen, sind weder praktikabel, noch überhaupt schlüssig formulierbar. In ein und demselben Artikel können unterschiedliche Kontexte und Zahlen vorkommen, wo jeweils andere Formatierungen anzuwenden wären, oder ein überwiegend wissenschaftlicher Artikel müsse dann einheitlich wissenschaftlich formatiert sein, wohingegen in einem Abschnitt in einem überwiegend unwissenschaftlichen Artikel dann auch die wissenschaftlichen Angaben Artikel-einheitlich unwissenschaftlich formatiert werden müssten.
    • Wobei die Zuordnung, wann welcher Zahlenwert wissenschaftlich und welche Zahlenwerte aber normal zu formatieren wären, dann je nach Kontext auszuhandeln und für jedes Fachgebiet in einem Katalog der Formatierungsregeln zu veröffentlichen und zu beachten sind. Wenn es um die Entfernung von Basel nach Zürich geht, dann ist das unwissenschaftlich und normal zu formatieren, die Kilometerangabe des Erdumfangs mit 40.000 ist unwissenschaftlich und normal zu formatieren, die metergenaue Angabe des Erdumfangs ist dagegen wissenschaftlich und muss wissenschaftlich formatiert werden. Wenn Essen und Trinken den Zuckergehalt von Erdbeerjoghurt nennt, dann ist das unwissenschaftlich und normal zu formatieren, hingegen ein Artikel über Diabetes ist ein medizinischer Fachartikel und alle Zahlenwerte müssen wissenschaftlich formatiert werden und die gleiche Zahlenangaben zu denselben Lebensmitteln sind hier wissenschaftlich anzugeben. Wobei Gramm auf Hundert noch nicht fünfstellig würden, andere Angaben sehr wohl.
    • Besonders absurd war der Vorschlag, jede größere Zahl mit <math>-Tags zu formatieren, weil ja irgendwann mathJax deren Textausgabe den Fonts des normalen Textes anpassen würde, oder eines Tages alle Browser MathML unterstützen würden.
    • Benutzer ohne aktiviertes JavaScript sehen immer eine eingepasste PNG-Grafik, die in aller Regel erheblich größer als der normale Text ist, und das dann für jede Zahl.
    • Die math-Ausgabe ist kursiviert mit normaler Schriftstärke, wie das für Formelzeichen auch sinnvoll ist. Im laufenden Text steht dann jede größere Zahl kursiv; wird ein Bereich (Tabellenüberschrift) in Fettschrift dargestellt, der das Pech hätte, eine größere Zahl zu enthalten, dann fällt die Zahl ohne Fettschrift heraus.
    • Die Zumutung für die Editierbarkeit mit oder ohne VisualEditor-Menü erwähnt man dabei besser gar nicht erst.
  • Die angeregten künstlichen Intelligenzen, die erst bei der Darstellung des Artikels automatisch eine hübsche Formatierung generieren sollen, müssten aber auch Patentnummern, IPv4-Adressen, Lokomotivbezeichnungen, Nummern von Asteroiden, Binärzahlen und was auch immer in ihrem Kontext erkennen und ihre automatisch aufgezwungene Formatierung dann unterlassen. Derartige Superintelligenzen der Software sind bislang ausnahmslos gescheitert, weil die reale Welt in den Artikeln halt etwas komplexer ist.
  • Es gibt keinerlei Vorschriften, die Autoren eines Werks wie des unseren zu irgendeiner Formatierung zwingen könnten oder irgendeinen Anspruch auf Befolgung erheben könnten.
    • Selbst die kleine Erste-Hilfe-Fibel zur Typografie im Rechtschreibduden sieht unsere Situation vor: „sachlich begründete Abweichungen“ unter „Hinweise“ – „Rechtschreibduden“ (Band 1), 27. Auflage, S. 110.
    • Die mehrfach wider besseres Wissen behauptete „offizielle Seite“ existiert überhaupt nicht; es gibt für Typografie und Formatierung keine Behörden, keine amtlichen Regeln und keine „offiziellen“ Vorschriften durch irgendwen oder für irgendjemanden verbindlich. Wenn, dann wir für uns.
    • Wie irgendein anderes Wiki oder irgendein Buch in der Welt da draußen ihr Zeugs formatiert, ist deren Ding und für uns nicht maßgeblich. Wir haben gute Gründe, warum wir unsere Sachen so machen wie wir sie machen; was eine professionelle Redaktion mit hauptberuflichen gelernten Mediengestaltern und deren Software anstellt, ist deren Angelegenheit.
  • Ohne eine Formatierung von zig Dutzend Millionen zumindest fünfstelliger bzw. in deren textlicher Nähe auch vierstelliger Zahlenwerte einzeln als Vorlage wird es keinerlei Sonderwünsche betreffend Verhalten beim Copy&Paste geben.
  • Fazit: Entweder einfacher Wikitext, von jedem leicht bearbeitbar, oder komplexe semantische Text- und Datenstruktur mit umfassendem Regelwerk, nur von Vollprofis nach mehrmonatiger Einarbeitungs- und Schulungsphase zu handhaben. Und eine Strategie zur Umschulung Tausender Autoren und zur Umstellung von Abermillionen an Zahlenwerten im Bestand. (nicht signierter Beitrag von PerfektesChaos (Diskussion | Beiträge) 8. Jun. 2018, 12:30:15)

Tausendertrennung mit Abstand als gleichwertig erlauben

• Abstände zur Tausendertrennung sind in den Naturwissenschaften in Lehr- und Fachliteratur sowohl national als auch international üblich. Das sollte in unseren Richtlinien nicht nur als weniger bevorzugte Möglichkeit vorkommen. -<)kmk(>- (Diskussion) 21:38, 18. Apr. 2018 (CEST)

  Ergänzung: Sowohl das Statistische Bundesamt als auch die regionalen statistischen Ämter in Deutschland verwenden in ihren Veröffentlichungen, die wir regelmäßig als Quellen für Einwohnerzahlen und ähnliches in Anspruch nehmen, durchweg den Abstand zur Tausendertrennung.---<)kmk(>- (Diskussion) 05:04, 7. Mai 2018 (CEST)

falsch: "So ist z.B. ersichtlich, dass die größte Gruppe innerhalb der deutschen Doppelstaatler Personen sind, die zusätzlich eine russische Staatsangehörigkeit besitzen (196.000). Der allergrößte Teil von ihnen ist im Ausland geboren (183.000)." (https://www.destatis.de/DE/Publikationen/Thematisch/Bevoelkerung/MigrationIntegration/MigrationshintergrundSonderausgabe5122121109004.pdf?__blob=publicationFile und durchgängig).--Esopsedana (Diskussion) 15:04, 27. Mai 2018 (CEST)

In dem von Dir verlinkten PDF sind die mehreren Tausend Zahlenangaben im etwa 400 Seiten umfassenden Tabellenteil mit Abstand als Tausendertrenner ausgeführt. Der Fließtext ist uneinheitlich gestaltet. Er verwendet verwendet auf Seite 11 sowohl Punkt ("1.047 Euro") als auch Abstand ("1 300 Euro") als auch keine Trennung ("1000 Euro"). Auf der Seite 10 sind wie von Dir zitiert zwei Zahlenangaben und eine weitere mit Punkt ausgeführt. Und auf Seite 14, im Glossar, finden sich drei Zahlenangaben mit Abstand als Tausendertrenner. Insgesamt sind im Fließtext dieses PDFs zwischen 10 und 20 Zahlen größer als 1000 enthalten.

Eine Stichprobe von weiteren Veröffentlichungen, wie etwa das aktuelle Statistische Jahresbuch des Bundesamts bestärkt mich in dem Eindruck, dass destatis durchweg den Abstand zur Tausendertrennung verwendet. In Tabellen habe ich keine einzige Zahlenangabe gefunden, die nicht den Abstand verwendet. Im Fließtext gilt dies für die Mehrheit der vergleichsweise wenigen Zahlenangaben.---<)kmk(>- (Diskussion) 00:53, 28. Mai 2018 (CEST)

Das Bundesamt für Statistik in der Schweiz, der Brockhaus, die Süddeutsche und Neue Züricher Zeitung ebenfalls. Ich finde nur die unterschiedlichen Hilfskonstrukte derzeit noch so problematisch, dass ich sie nicht uneingeschränkt empfehlen würde, sondern nur dann wenn man sowiso die math-Erweiterung benutzen muss und im Zweifelsfall wäre mir gar keine Tausendertrennung lieber als ein missverständlicher Punkt.--Debenben (Diskussion) 23:54, 13. Mai 2018 (CEST)

• +1, für Eindeutigkeit auch über Grenzen hinweg. Ich habe nichts gegen Ziffernfolgen, falls nötig. -- UKoch (Diskussion) 22:28, 22. Apr. 2018 (CEST)
• +1 wie kmk --Boehm (Diskussion) 23:17, 24. Mai 2018 (CEST)

+ sollte möglich sein --Lena1 (Diskussion) 10:39, 5. Jun. 2018 (CEST)

Der Quelltext der Artikel ist noch nicht überfrachtet genug

• Klar, was die Wikipedia unbedingt braucht ist mehr Überfrachtung des Artikelquelltextes, schützende Leerzeichen sind die Lösung. Damit ja keiner mehr mitarbeitet, der kein Diplom in höherer Quelltextverschandelung hat. --Informationswiedergutmachung (Diskussion) 00:34, 22. Apr. 2018 (CEST)
• Seufz... --Kenny McFly (Diskussion) 11:01, 23. Apr. 2018 (CEST)
• Ich wäre ja sofort dafür, jede Zahl als n * π^{0,123456789101112131415161718192021222324...} zu schreiben. --Keimzelle talk 01:42, 24. Apr. 2018 (CEST)
• stichwort bearbeiterfreundlichkeit, beginnend mit der albernen formatvorlage für fussnoten, wäre die zumüllung des quelltextes gerade in den zahlen, eine sinnvolle ergänzung, um möglichst viele neue benutzer von der mitarbeit abzuhalten. ☆ Bunnyfrosch 15:52, 24. Apr. 2018 (CEST)

  Wenn ich die Intention der Umfrage richtig verstehe, so war nach Ideen gefragt, wie man die Trennung mit Leerzeichen technisch umsetzen könnte und dabei "Quelltextzumüllung" und andere Probleme vermeidet. Wenn das einzige Argument der Quelltext ist, könnte man auch 123 456 789 123 456 789 direkt im Quelltext schreiben, den Leerzeichen sieht man es dann nur nicht an, dass sie besonders sind.--Debenben (Diskussion) 22:52, 24. Apr. 2018 (CEST)

  Diese Unicode-Direktzeichen, die du da ins Spiel bringst, sind für Bearbeiter des Quelltextes nicht von einem normalen Leerzeichen zu unterscheiden. Was würden die nächstfolgenden Autoren also tun, wenn sie eine mehrstellige Zahl sehen?

  • Sie müssten sicherheitshalber erneut ein geschütztes Leerzeichen drüberzaubern, um sicherzugehen, dass es kein normales oder ungeschütztes schmales ist; und so müsste jeder Bearbeiter bei jeder einzelnen Bearbeitung erneut vorgehen.
  • Sie könnten sich blind darauf verlassen, dass es ein geschütztes wäre, und es einfach so belassen, auf die Gefahr hin, dass es nur ein normales Leerzeichen ist.

  Für Bearbeiter, die es nicht mit monospace bearbeiten, etwa im VE, ist der Unterschied nur schwer zu erkennen und nur bei besonderer Aufmerksamkeit zu ahnen. Mit echtem monospace kann es überhaupt keinen Unterschied geben, weil dann per Definition alle Zeichen genau gleich breit sind.

  Beim C&P solcher Zahlen werden die unsichtbaren Zeichenvarianten unbemerkt an alle möglichen Stellen des Textes verschleppt, und geraten etwa zwischen zwei lange Wörter und verhindern dort auf rätselhafte Weise den Umbruch.

  Aus diesem Grund schreiben wir keinerlei unsichtbare Zeichen oder Zeichen mit anderer Kodierung als das normale Leerzeichen in den Quelltext, sondern immer nur Entities, damit die Besonderheit für alle Bearbeiter auffallend sichtbar wird.

  VG --PerfektesChaos 10:50, 25. Apr. 2018 (CEST)

• nicht noch mehr Spezialzeichen im Quelltext, selbst das nbsp sollte nahezu ausschließlich per Software gesetzt werden. -- hgzh 20:30, 25. Apr. 2018 (CEST)
• wenn wir sonst keine Sorgen hätten ;-) Solange DA und CH schon unterschiedlich sind, bleibt es sowieso schwierig ;-) Am einfachsten wäre ein shortcut [Abstand + ↑] oder so; mein laienhafter Senf dazu, --Hannes 24 (Diskussion) 19:37, 26. Apr. 2018 (CEST)
• Schon die Manie, alle kurzen Abkürzungen wie i.V. oder n.P. in Sportergebnislisten durch das Einfügen kryptischer Codes im Quelltext möglichst unlesbar zu gestalten geht mir persönlich tierisch auf den Senkel. Jetzt soll hier noch mehr quelltextverunstaltender Unsinn eingebaut werden? KISS! Wenn's dann mal 'nen Umbruch gibt, dann gibt es halt mal 'nen Umbruch, isso. Woran kann ein Mensch denn künftig noch im Quelltext erkennen, wie die Zahl tatsächlich aussieht? Da kann doch der Inhalt vor lauter merkbefreiter Syntax nicht mehr erkannt werden. Grüße vom Sänger ♫ ^(Reden) 08:54, 30. Apr. 2018 (CEST)
• Die Hürde für Einsteiger ist bereits hoch genug. Wenn für simple Zahl eine Vorlage oder kryptische Zeichenkombinationen benötigt werden, verletzen wir das KISS-Prinzip. Und egal, was wir machen, den Visual Editor nicht vergessen. Wir Quelltext-Dinos sterben eh aus. --Superbass (Diskussion) 22:01, 15. Mai 2018 (CEST)

Darstellung durch die Wiki-Software

Oben wurde der Vorschlag gemacht, es rein softwareseitig zu lösen. Allerdings gibt es Situationen, wo bei einer Ziffernfolge die Gruppierung nicht gewünscht ist. Wäre dies möglich, es als eine Art Formatierungsanweisung wie {"{Zahl|1234567,89}} zu realisieren, die dann durch die Wikisoftware mit Punkt oder Leerzeichen zur Gruppierung dargestellt wird? Beim Kopieren des Wikipedia-Quelltextes würde es hier auch nicht zu Missverständnissen kommen. --Nov3rd17 (Diskussion) 14:37, 29. Apr. 2018 (CEST)

Du hattest jetzt nicht ernsthaft vorgeschlagen, jede fünfstellige Postleitzahl in Deutschland oder sonstwo auf der Welt in eine Formatierungsverhinderungsvorlage einzubasteln, desgleichen jede Binärzahl, die größer als 31 ist, und alle möglichen Bezeichnungen von indonesischen Dampflokomotiven oder Asteroiden oder Archivstücke, oder technische Bezeichnungen und Modellnummern aller Art?

IPv4 wie 123.247.024.168 sind für Software nicht von irgendeiner großen Zahl unterscheidbar, müssen aber trotzdem ihre Punkte behalten. Gleiches gilt für Bezeichnungen von Patenten oder was immer.

Es gibt den naiven Kinderglauben, man müsse nur die Intelligenz der menschlichen Autoren an ein überirdisches Softwareprodukt von MediaWiki delegieren, und dann reicht ein Klick, schwups, und aus Wikidata und Übersetzungstool ist der perfekte neue Artikel entstanden, und die Zahlen sind alle dem Kontext entsprechend formatiert.

Die Bedeutung einer Folge von Ziffern ist mitnichten so trivial, dass eine Software da einfach drüberbügeln könnte und es gnadenlos umformatiert, und das dann einheitlich sachgerecht in zwei Millionen Artikeln. Und unsere gelangweilten unterbeschäftigten Autoren und Artikel- sowie Syntaxpfleger werden die alle durchflöhen und überall Verhinderungsvorlagen einbasteln.

VG --PerfektesChaos 12:04, 30. Apr. 2018 (CEST)

Gegen den unerschütterlichen Glauben an die Segnungen der KD - Künstlichen Dummheit ist kein Kraut gewachsen. Die Computer sollen es halt besser wissen als man selbst - stört niemanden. Das klassische Beispiel: MS Excel, wo seit Jahren jede Eingabe von z.B. 12.95 zwangsweise und unweigerlich in 1. Dezember 1995 umgewandelt wird. --109.40.64.176 12:42, 30. Apr. 2018 (CEST)

Gerade das ist nicht gemeint: Nur die Zahlen, die mit einer Formatierungsanweisung versehen wären, würden formatiert dargestellt werden. 1234567,89 würde weiterhin ganz normal dargestellt; "Verhinderungsvorlagen" bräuchte man also nicht. --Nov3rd17 (Diskussion) 12:37, 1. Mai 2018 (CEST)

Na, also so herum ist diese Idee ja noch bescheuerter.

• Wir haben zig über zig Millionen Zahlen größer als 9999 in unseren Artikeln, die Zuschauer bei einem Fußballspiel, die pro Jahr auf einer Insel verbrauchten Tonnen Heizöl, die Bevölkerung Roms zu Cäsars Zeiten, den Jahresumsatz einer Firma in Dollar.
• Zu 98 % sind das zu formatierende Zahlen; die nicht automatisch zu formatierenden Zahlen dürften nur 1 oder 2 % ausmachen, gehen aber trotzdem in die Hunderttausende bis Million einzelner Vorkommen.
• Natürlich würde man, wenn überhaupt, nur die Ausnahmen besonders kennzeichnen, um sie vor dem übergriffigen Automatismus zu schützen.
• Die „Formatierungsvorlage“ gibt es als Parserfunktion {{formatnum:}} wohl schon ein Dutzend Jahre: 12.345.678 – aber die wird nur in der Programmierung eingesetzt, um das Ergebnis von Berechnungen oder unformatierter externer Daten zu präsentieren.
• Und jeder, der die Anzahl der Besucher beim letzten Rockkonzert in den Artikel schreiben will, müsste das dann erstmal in eine Sonderformatierungsfunktion verpacken. Weil das absolut unzumutbar ist, darf es jeder erstmal ohne tippen, und wer vorbeikommt und es sieht, haut einmal auf die . (auf jeder Tastatur jedes Geräts simpel verfügbar) und fertig.

VG --PerfektesChaos 14:33, 1. Mai 2018 (CEST)

Vielleicht bin ich etwas vom Lesen englischsprachiger Texte "geschädigt" und projiziere meine Erfahrung aus dem naturwissenschaftlichen Bereich zu Unrecht auf andere Gebiete, aber einen Satz "[...] Einwohnerzahl von 12.345 [...]" lese ich "Einwohnerzahl von zwölf komma drei vier fünf", merke dann dass es keinen Sinn macht und dann fällt mir ein dass in der deutschsprachigen Wikipedia ja Punkte zur Tausendertrennung verwendet werden. Das ist nicht nur nervig, sondern diese Lesart ist im Allgemeinen auch häufig zutreffend, weil der Autor einfach vergessen hat die ursprünglich englisch geschriebenen Zahlen auf deutsch umzuformatieren.

Ich würde daher begrüßen wenn sich die Wikipedia-Richtlinien an den Duden-Hinweisen und die Ausnahmen an den Normen und Vorschriften für angelernte Schreibkräfte im Büro orientieren: Für elektronische Geschäftsbriefe in denen die Verwendung von schmalen geschützten Leerzeichen technische Probleme bereiten könnte, sind normale umbruchgeschützte Leerzeichen oder überhaupt keine Tausendertrennung vorgesehen. Letzteres lässt sich noch einfacher eingeben als ein Punkt. Auf Wikipedia übertragen hieße dies etwa: Wenn du sowiso die math-Erweiterung benutzen musst, verwende \, zur Tausendertrennung, wenn du sie nicht verwenden musst dann verwende bei Zahlen mit weniger als sieben Ziffern überhaupt keine Tausendertrennung und wenn beides nicht der Fall ist müsste man abwägen, was am Besten geeignet ist.--Debenben (Diskussion) 15:49, 3. Mai 2018 (CEST)

Die Vorlage mit FormatNum wäre eigentlich das Richtige, aber bei ihr kommt es bei den Leerzeichen zu einem Zeilenumbruch. Wenn man also das Fenster verkleinert, sieht man wie Dreieckgruppen von Ziffern umgebrochen werden und nicht die Zahl als ganzes: 1 234 567 890 987 654 321,123 456 7, was ein deutliches Manko ist. --Nov3rd17 (Diskussion) 18:20, 4. Mai 2018 (CEST)

Mit dem oberen Hinweis, dass mit &"#8239; (ohne ") ein umbruch-geschütztes kleines Leerzeichen erzeugt werden kann, könnte man doch eine weitere Option bei FormatNum erstellen, die gerade die math. Standard-Schreibweise mit geschütztem kleinen Leerzeichen realisiert. (also 12 345 678 909 876 543 210) Habe aber noch nie so eine Formatvorlage erstellt/verändert.--Nov3rd17 (Diskussion) 18:39, 4. Mai 2018 (CEST)

Und damit wird dieses Ungetüm zu einem unlesbaren Wust aus sinnfreien Zeichen im Quelltext, so etwas sollte es niemals zu lesen geben, wenn mensch auf "Bearbeiten" klickt, das ist nicht wartbar. Grüße vom Sänger ♫ ^(Reden) 18:47, 4. Mai 2018 (CEST)

Wieso? Es hieße doch im Quelltext einfach {FormatNum|1234567890987654321.1234567|iso}, wenn man diese Option "iso" nennen würde (bzw. {FromatIso|1234567890987654321.1234567} wenn man so eine Abkürzung hätte). Das ist dann eben kein Wust aus sinnfreien Zeichen und wäre auch problemlos zwischen den Wikipedia-Projekten austauschbar (->Die automatische Übersetzung dt. Wiki-Artikel für den fremdsprachigen Leser(!) hätte dann ein Problem weniger.) --Nov3rd17 (Diskussion) 08:19, 5. Mai 2018 (CEST)

Mit FormatNum funktioniert es jetzt (wieder) mit dem geschützten Leerzeichen, als einzige Kleinigkeit, dass die Nachkommastellen auch gruppiert werden was nicht üblich ist aber im Sinne der Lesbarkeit neutral bis positiv ist: 111 222 333 444 555 666 777 888 999 000,123 4 --Nov3rd17 (Diskussion) 09:55, 30. Mai 2018 (CEST)

Lösungsmöglichkeiten

formatnum:

Mit {formatnum:12345676890.123456} (mit zwei geschweiften Klammern) wird die Zahl wie in der dt. Wikipedia üblich mit Punkten zur Zifferngruppierung vor dem Komma und ohne Gruppierung hinter dem Komma dargestellt: 12.345.676.890,123500 und übernimmt man den Quelltext in die engl. Wikipedia, so funktioniert es auch, nur dass es eben in der engl. Schreibweise mit Punkten als Dezimaltennzeichen und Komma als Gruppierungszeichen geschrieben wird. Für die Portierung des Quelltextes ist das also ganz nützlich und schadet der Lesbarkeit für den Leser als auch für den (Quelltext-)Editor nicht. --Nov3rd17 (Diskussion) 10:43, 30. Mai 2018 (CEST) (Der nächste Schritt wäre die Frage, ob die übliche Schreibweise in der Wikipedia mit den Punkten die bessere ist, aber das ist eine eher grundsätzliche Frage und keine rein technische.) --Nov3rd17 (Diskussion) 10:48, 30. Mai 2018 (CEST)

en:Template:Val

Die Val-Vorlage in der englischen Wikipedia ist viel ausführlicher als das deutsche FormatNum. Müsste man in die dt. Wikipedia importieren. --Nov3rd17 (Diskussion) 11:28, 30. Mai 2018 (CEST)

@PerfektesChaos: Die deutsche Vorlage FormatNum mit Parameter de finde ich immer noch nicht empfehlenswert. Zwar sieht es jetzt so aus wie ein umbruchgeschütztes schmales Leerzeichen, aber beim Kopieren und für Screenreader wird es zu einem normalen Leerzeichen. Ein Screenreader kann mit umbruchgeschützten, umbruchgeschützten schmalen Leerzeichen sowie überhaupt keine Tausendertrennung problemlos umgehen und bei Punkten in den meisten Fällen bei entsprechender Einstellung ebenfalls, aber ein normales Leerzeichen wird immer falsch gelesen. Die englische Vorlage ist da besser, dort wird der Abstand nicht mitkopiert/gelesen.

Zu den ausführlicheren Funktionen der Val-Vorlage, insbesondere dem Punkt "Why not use <math>?" würde ich gerne noch anmerken, dass die Nachteile (Schriftart und Größe passt nicht zum Text, manche Zeichen haben Rendering-Probleme, nicht kopierbar, unlesbar für mobile Browser ohne MathML und svg Unterstützung, schwer lesbar für Textbrowser, keine automatischen Zeilenumbrüche bei längeren Gleichungen, kein Accessibility-explorer, extremst hässlich im Wikipedia/Chrome-generierten pdf-Ausdruck...) beispielsweise für MathJax auf math.stackexchange.com nicht zutreffen und dass man in fast allen mathematisch oder naturwissenschaftlichen Artikeln auf eine funktionierende Math-Erweiterung angewiesen ist und sich diese niemals vollständig durch behelfsmäßige Vorlagen ersetzen lässt.--Debenben (Diskussion) 13:53, 30. Mai 2018 (CEST)