Wikipedia Diskussion:Lua/Modul/FormatNum

Vorlagenprogrammierung	Diskussionen	Lua			Test	Unterseiten
		Modul	Deutsch	English		Modul:	Dokumentation

Verwendete römische Zahlzeichen

900.000 = 'ↈↈↈↈ ↈↈↈↈↈ' 800.000 = 'ↈↈↈ ↈↈↈↈↈ' 700.000 = 'ↈↈ ↈↈↈↈↈ' 600.000 = 'ↈ ↈↈↈↈↈ' 500.000 = 'ↈↈↈↈↈ' 400.000 = 'ↈↈↈↈ' 300.000 = 'ↈↈↈ' 200.000 = 'ↈↈ' 100.000 = 'ↈ'

90.000 = 'ↂↈ' 80.000 = 'ↇↂↂↂ' 70.000 = 'ↇↂↂ' 60.000 = 'ↇↂ' 50.000 = 'ↇ' 40.000 = 'ↂↇ' 30.000 = 'ↂↂↂ' 20.000 = 'ↂↂ' 10.000 = 'ↂ'

9.000 = 'ↀↂ' 8.000 = 'ↁↀↀↀ' 7.000 = 'ↁↀↀ' 6.000 = 'ↁↀ' 5.000 = 'ↁ' 4.000 = 'ↀↁ' 3.000 = 'ↀↀↀ' 2.000 = 'ↀↀ' 1.000 = 'ↀ'

"Moduleinbindung nicht verändern"

Begründung? Wenn schon drübersteht, "Formatiert Zahlen gemäß WP:SVZ", dann sollte die Vorlage das auch tun. Macht sie mit format=de nicht (-123 456,789 0 ist selbst in AT und CH nicht richtig, und in DE muss es (in der WP) so aussehen: -123.456,7890; das geht sogar mit {{formatnum:-123456.7890}} → −123.456,7890). --AMGA (d) 20:44, 18. Mai 2013 (CEST)

Die Vorlage fügt keine Dots ein, sondern schmale Leerzeichen. Das ist gem. Norm und WP:SVZ richtig. Die Testausgabe der Doku zeigt, dass es stimmt. ÅñŧóñŜûŝî (Ð) 22:23, 18. Mai 2013 (CEST)

Äh, nein. WP:SVZ: Das in der deutschsprachigen Wikipedia für nicht speziell auf die Schweiz oder Liechtenstein bezogene Artikel zu verwendende Dezimaltrennzeichen ist das Komma. Als Tausendertrennzeichen wird in diesen Artikeln ein Punkt (».«) verwendet. --AMGA (d) 01:12, 19. Mai 2013 (CEST)

Hm. In der Tabelle darunter steht "Punkte oder Freiräume". Ich vermute mal, dass die normwidrigen Tausenderpunkte ein Kompromiss waren, weil die Browser früher Probleme mit dem schmalen Leerzeichen hatten. Das dürfte immer unwichtiger werden, da die meisten neueren Browser damit klarkommen. ÅñŧóñŜûŝî (Ð) 01:35, 19. Mai 2013 (CEST)

Wer weiß. Jedenfalls ist jetzt die Situation so, dass man in Infoboxen, wo aus verschiedenden Gründen unterschiedliche Untervorlagen verwendet werden (so bin ich ja von Infobox Ort in Russland bzw. Föderationssubjekt Russlands hierher gelangt) Zahlen unterschiedlich formatiert sind. Bspw. Fläche über Vorlage:Maß → Vorlage:FormatNum → Leerzeichen, Einwohner über Vorlage:FormatZahl → Punkt, Bevölkerungsdichte über Vorlage:FormatBevölkerungsdichte → auch Punkt. Das ist Mist. Und wie gesagt, sogar die vielfach eingesetzte Parserfunktion formatnum erzeugt ja Punkte (die macht das auch in den letztgenannten Vorlagen). Da muss ich wohl in den "von mir betreuten" Vorlagen direkt auf die Grundfunktionen zurückgreifen... ist performancemäßig vielleicht sowieso besser. --AMGA (d) 01:59, 19. Mai 2013 (CEST)

Oh, sehe gerade, dass du im August 2012 in der Vorlage:Maß formatnum durch FormatNum ersetzt hast, und jetzt liefert FormatNum nicht mehr dasselbe wie damals. Das ist eine suboptimale Vorgehensweise... ist das irgendwo abgestimmt? Hat ja doch etwas, äh, weitreichende Folgen... --AMGA (d) 02:06, 19. Mai 2013 (CEST)

Soweit ich mich erinnern kann, war das zu diesem Zeitpunkt wohl eine "Eindeutschung" von formatnum (also "." statt "," und umgekehrt), wenn das Sinn machte. Ich bin mir aber nicht mehr sicher, da ehem. Untervorlagen gelöscht sind. Die Abweichung ist jetzt durch Einführung der Module entstanden. Es hängt heute ganz von der Programmierung des Moduls ab. Die Frage lautet:

Sollen normgerecht schmale Leerzeichen verwendet werden oder bleibt es bei der veralteten und missverständlichen Verwendung der Punkte?

Die Vorlage kann nur ein Format als Standard - und damit für alle bisherigen Einbindungen - haben. Ein etwaiger Extraparameter ist nur via Einbindungsänderungen nutzbar. ÅñŧóñŜûŝî (Ð) 21:57, 19. Mai 2013 (CEST)

Hallo Antonsusi, sei mir nicht böse, dass ich wieder auf die Vorgängeraccounts zu sprechen komme, aber m. E. hast du nie richtig verstanden, was {{formatnum:...}} macht, was unter anderem die Neuanlage der Vorlage:Formnum zeigt (Permalink zur Erstversion mit falschen Informationen, die bis jetzt noch da stehen).

Korrekt ist folgendes: Die Parserfunktion {{formatnum:...}} hat sich schon immer sprachabhängig verhalten. Die Einbindung {{formatnum:XXX}} erwartet als Eingabe immer eine „unformatierte Computerzahl“ (Punkt als Dezimaltrenner, kein Tausendertrenner) und gibt die sprachabhängig formatierte Zahl aus. Für Deutsch war dies immer das Komma als Dezimaltrenner und fast immer der Punkt als Tausendertrenner; lediglich 2009 gab es für kurze Zeit das Leerzeichen als Tausendertrenner.

Die Einbindung {{formatnum:XXX|R}} dagegen macht dies gerade rückgängig und erzeugt aus der formatierten Zahl eine „unformatierte Computerzahl“, für Deutsch heißt das: Tausenderpunkte werden entfernt und Dezimalkommata durch Dezimalpunkte ersetzt. (Hieraus kann man direkt folgern, dass und wann die Vorlage:Formnum etwas anderes tut, als in der Dokumentation steht.)

In Wikipedia:Schreibweise von Zahlen ist – momentan immer noch – festgelegt, dass in der Wikipedia der Punkt als Tausendertrenner verwendet wird. Das Verhalten von {{formatnum:...}} kommt dem schon sehr nahe, lediglich die Handhabung vierstelliger Ganzzahlen ist anders (diese bekommen laut Wikipedia:Schreibweise von Zahlen keinen Tausendertrenner).

Unter dem Namen dieser Vorlage stand einmal eine Vorlage, die nach deiner Verschiebung mittlerweile Vorlage:FormatZahl heißt und das Ziel hatte, Wikipedia:Schreibweise von Zahlen exakt umzusetzen (also auch für vierstellige Ganzzahlen).

Seit deinen Änderungen tut sie das nicht mehr, sondern etwas völlig anderes – das Leerzeichen ist laut Wikipedia:Schreibweise von Zahlen nicht vorgesehen. Insofern kann ich nur der Aussage zustimmen, dass man schlicht und einfach die Parserfunktion {{formatnum:XXX}} verwenden sollte – die tut, was sie soll (bis auf einen m. E. sowieso sehr spitzfindigen und in der Praxis so nicht behandelten Spezialfall), tut dies auch sehr effizient und ohne die Anzahl überall eingebundener Vorlagen zu erhöhen, und sie ist spontanen Änderungen entzogen.

Das Verhalten der Parserfunktion kann übrigens durchaus verändert werden, wenn es einen Konsens dafür gibt. (Den gab es bei der letzten Änderung nicht, was zur Rücknahme derselben geführt hat.) --Entlinkt (Diskussion) 23:03, 19. Mai 2013 (CEST)

Du musst ein gutes Gedächtnis haben...

Wenn die Leerzeichen im Fließtext nicht als Alternative erwähnt werden, warum steht dann - seit 13. September 2009 (!) - in der Tabelle "Punkte oder Freiräume zur Tausendertrennung"? Nach der Angabe habe ich mich orientiert. Bevor ich hier virtuell gesteinigt werde kann das aber auch auf Punkte umstellen. Das Modul hat das eingebaut. ÅñŧóñŜûŝî (Ð) 23:43, 19. Mai 2013 (CEST)

Ja, schön, danke. <hubrismode>Und die unsägliche Norm mit den hässlichen schmalen Leerzeichen (v.A. denen in den Nachkommastellen) kriegen wir auch noch zu Fall. Normen sind schließlich nicht gottgegeben ;-) Ist ja fast so schlimm wie die ISO 9:1995.</> --AMGA (d) 08:58, 20. Mai 2013 (CEST)

Leeres Format

Mir fiel auf, dass {{FormatNumDef|10000|}} alles unformatiert ausgibt, weil das leere Format als ungültig erkannt wurde. Meiner Meinung nach muss der leere Parameter ignoriert werden und die Ausgabe die selbe wie bei {{FormatNumDef|10000}} und {{FormatNumDef|10000|dewiki}} sein. Das nur zur Erklärung, geändert habe ich es ja schon. --TMg 16:49, 18. Jul. 2013 (CEST)

Fein. Das ist wohl erledigt. ÅñŧóñŜûŝî (Ð) 17:17, 18. Jul. 2013 (CEST)

Fast. Weil dies ein unbenannter Parameter ist, kann auch beliebige Menge an Whitespace vorkommen.

@TMg: Du bist nicht an der Schnittstelle für Vorlagen, sondern an der Lua-Schnittstelle gelandet. Bei letzterer ist das jedoch nicht zu erwarten. Macht nix.

Ich setze das bei Gelegenheit nach unten und trimme dann auch. Es müssen ohnehin die deprecated entfernt werden und ein weiterer Parameter wird deprecated; und dann ist hier noch die Geschichte mit ohne Tausendertrenner bei vierstelligen Zahlen nur bei positiver Ganzzahl offen.

Um die Server nicht zu sehr zu nerven, erprobe ich das zunächst auf Beta und übertrage dann in einem Rutsch auf de.wikipedia.org.

Im Moment komme ich aber nur in wenigen kühlen Nachtstunden zu anspruchsvollerer Denke.

VG --PerfektesChaos 20:17, 18. Jul. 2013 (CEST)

In der Vorlage wird der zuvor unbenannte Parameter als benannter Parameter „format“ an das Modul weiter gereicht. Ich nahm an, da wäre Trimmen wie gewohnt inbegriffen. Test: 10.000. Scheint zu stimmen. Aber so weit gedacht hatte ich wirklich nicht, insofern Danke für den Hinweis. :-) --TMg 21:49, 18. Jul. 2013 (CEST)

Schmaler umbruchgeschützter Leerraum als Tausendertrennzeichen

Wird der schmale umbruchgeschützte Leerraums als Tausendertrennzeichen unterstützt? Wenn nein warum nicht? --Cepheiden (Diskussion) 20:23, 11. Aug. 2014 (CEST)

Du findest drei verschiedene Schlüsselwörter, die deinen Wunsch (U+202F) unterstützen. LG --PerfektesChaos 20:45, 11. Aug. 2014 (CEST)

Parserfunktion

(Überschrift nachträglich eingefügt --Peter Gröbner (Diskussion) 19:05, 6. Apr. 2015 (CEST))

Wieso wird {{formatnum:8790}} in Marktheidenfeld (Marktheidenfeld) entgegen „Ein Tausendertrennzeichen wird in der Regel erst ab fünf Stellen gesetzt.“ (Wikipedia:Schreibweise von Zahlen#Tausender- und Dezimaltrennzeichen) mit Tausendertrennzeichen ausgegeben? --Peter Gröbner (Diskussion) 16:19, 6. Apr. 2015 (CEST)

• Falls das eine Beschwerde darstellen soll, dann beschwerst du dich auf der falschen Seite.
• Im laufenden Artikeltext im Einleitungsabschnitt steht:

  Sie hat {{formatnum:8790}} … Einwohner.

  • Das ist eine Parserfunktion.
  • Parserfunktionen gehören zur weltweiten Software und verhalten sich insbesondere für deutsprachige Wikis gleich.
  • Siehe Hilfe:Variablen #formatnum.
  • Warum die jetzt auf einmal einen Punkt ausspuckt, und seit wann sie das täte, weiß ich auch nicht.
  • Der mehrjährigen Doku zufolge seit 2009 erst ab 5 Ziffern: Spezial:Diff/61225511 + Spezial:Diff/64770117.
• Dieses Modul hier beschreibt eine andere Funktion.
  • Sie würde sich lesen als: {{#invoke:FormatNum|format|8790}}
• Die Infobox verwendet mittelbar dieses Modul.
  • Dementsprechend steht es in der Infobox ohne Tausendertrennzeichen.
  • Siehe dazu auch Wikipedia:Lua/Modul/FormatNum #Formatierungsoptionen.
  • Für die Programmierung der Vorlage:Infobox Ortsteil einer Gemeinde in Deutschland ist die Größe der Gemeinde unbekannt; sie muss mit allem von Hintertupfingen bis Berlin rechnen.
• Der Artikeltext lautet in der Einleitung

  Sie hat {{formatnum:8790}} Einwohner.

  • Warum zum Henker muss man das so kompliziert schreiben?
  • Warum schreibt man da nicht einfach:

    Sie hat 8790 Einwohner.

  • Für den Einleitungsabschnitt dieses einen Artikels ist es eine Konstante. Ihr wisst doch, wie groß die Zahl ist?
• @Umherirrender: history: includes/parser/CoreParserFunctions.php ist seit Ewigkeiten unverändert, demnach müsste im translatewiki oder als LocalSetting irgendwas passiert sein?

VG --PerfektesChaos 18:54, 6. Apr. 2015 (CEST)

„Warum zum Henker muss man das so kompliziert schreiben? Warum schreibt man da nicht einfach: Sie hat 8790 Einwohner.“ Das frage ich mich auch. Vgl. WD:ZF#Unterscheidung von Jahreszahlen und anderen vierstelligen Zahlen. Gruß und Dank --Peter Gröbner (Diskussion) 19:01, 6. Apr. 2015 (CEST)

formatnum hat immer bei 4 stelligen Zahlen einen Tausenderpunkt ausgegeben, da hat sich nichts geändert. Nachträglich das zu ändern ist auch schwierig, weil beispielsweise in Tabellen die Formattierung einen Tausenderpunkt haben darf, damit die Zahlen untereinander stehen. Man weiß halt nie wo etwas verwendet wird. Der Umherirrende 10:27, 7. Apr. 2015 (CEST)

Ich war auch etwas irritiert, konnte mich aber nicht mehr so genau dran erinnern.

• Dementsprechend ist die seit 2009 auf Hilfe:Variablen #formatnum stehende Beschreibung schlicht falsch.
• Das hätte auch geheißen, dass es irgendwo als LocalSetting irgendwelche Einflussmöglichkeiten gäbe.

Dieses Modul hier hat ja gerade die Aufgabe, bei den Fällen, wo nur eine Zahl auf einmal vorkommt, die vierstelligen noch ohne Punkt zu schreiben. Deshalb macht die Infobox das ja auch ganz brav mit diesem Modul. Zumindest im Standardmodus dewiki, der ja eben SVZ widerspiegelt.

• Ist man hingegen in einer Tabelle mit beliebigen Daten unbekannter Herkunft, dann müssen vorsorglich alle vierstelligen schon mit Punkt angegeben werden. Das war eigentlich auch noch nie ein Problem.

LG --PerfektesChaos 10:50, 7. Apr. 2015 (CEST)

@PerfektesChaos, Umherirrender: Ich danke euch herzlichst für eure Auskunft/Informationen, die ich leider mangels Vorkenntnissen nicht alle(s) verstehe; nur soviel, dass Hilfe:Variablen #formatnum falsch ist. Kann man das ändern? Ich mache es vorsichtshalber lieber nicht selber. Gruß und nochmals Dank! --Peter Gröbner (Diskussion) 11:29, 7. Apr. 2015 (CEST)

Ich hatte oben Spezial:Diff/61225511 + Spezial:Diff/64770117 verlinkt und überlasse die Korrektur auch lieber jemandem, der sich damit auskennt. LG --PerfektesChaos 11:32, 7. Apr. 2015 (CEST)

Ich habe es korrigiert. Der unter Wikipedia:Projektneuheiten/Archiv/2009-2#17. September geschriebene Text hat mich wohl dazu veranlasst, davon auszugehen dass die Sache mit den 5 Stellen erhalten bleibt. Damals habe ich mir die Implementierung wohl nicht angeschaut. Der Umherirrende 11:39, 7. Apr. 2015 (CEST)

Auch an dieser Stelle meinen Dank! --Peter Gröbner (Diskussion) 11:45, 7. Apr. 2015 (CEST)

Parameter 2 und das Dezimalzeichen

Bisher wird bei der Angabe "0" als zweiten Parameter eine Angabe wie "123." zurückgegeben, was nicht der allgemeinen Schreibweise entspricht. Für "123" muss man "-0" angeben. Ich schlage vor, den spieß umzudrehen und den normalen Darstellungen der Zahlen "-2", "-1", "0", "1", "2" u.s.w die natürliche Schreibweise zuzuordnen und ein "123." nur bei der Angabe "+0" zurückzugeben. ÅñŧóñŜûŝî (Ð) 19:53, 18. Nov. 2016 (CET)

Nein; zuvor war das Verhalten undefiniert, undokumentiert, nicht vorgesehen und reiner Zufall.

Jetzt ist es eindeutig: Alle mit Minuszeichen sind ohne Punkt, alle ohne Minuszeichen sind (ggf.) mit Punkt.

Was du vorschlägst, würde diese simple Regel durcheinanderbringen, weil die 0 und die -0 dann plötzlich hin und her springen würden.

Eine +0 hatte es bisher genausowenig gegeben wie eine -0; wenn also schon seit einigen Wochen neu eingeführt, dann bleiben wir auch konsistent.

VG --PerfektesChaos 20:04, 18. Nov. 2016 (CET)

Wieder einmal scheitert eine Vorlagenoptimierung nur deshalb, weil die Idee dazu nicht von dir kam und du dich für den perfekten Programmierer hältst... ÅñŧóñŜûŝî (Ð) 09:35, 19. Nov. 2016 (CET)

• Wer das mitliest und sich wundert: Es geht offenbar um die Funktion round.
• Bereits in der allerersten Version 2013 hieß es:
  • „(PC-kompatible Schreibweise ohne Formatierung). Diese kann mit der Funktion formatNumber() weiter formatiert werden“.
  • So steht das bis heute in der Doku, mit gekürztem Funktionsnamen.
• Die Funktion round ist eine Erweiterung von {{#expr: 30 / 7 round 7 }} und macht es genauso (diese kann ebenfalls -2), fügt jedoch als Alternative zur kaufmännischen Rundung standardmäßig die IEEE 754 hinzu.
• Das Ergebnis ist deshalb „PC-kompatible Schreibweise“, damit das in #expr:-Ausdrücken für weitere Berechnungen genutzt werden kann.
• Das Ergebnis ist grundsätzlich nicht dazu gedacht, direkt in Artikeln angezeigt zu werden. Deshalb heißt es da oben „PC-kompatible Schreibweise ohne Formatierung“.
  • Das merkt man schon daran, dass man Punkte als Dezimaltrenner erhält und kein Komma.
  • Das ist auch bei den Ergebnissen von #expr: so vorgesehen.
  • Deshalb sind diese Ergebnisse zum Schluss immer schon in die Parserfunktion {{formatnum:1234.56}} eingepackt worden.
• Ich weiß nicht, um welche Vorlage es hier geht.
  • Aber ganz offenkundig wurde der Fehler gemacht, das Ergebnis nicht deutschsprachig zu formatieren, wie das serienmäßig vorgesehen ist und wo bei Fehlen von Nachkommastellen eine Ganzzahl ohne Dezimalzeichen dargestellt wird.
  • Um das ausnahmweise zu erleichtern und gelegentliche Direktverwendung zu ermöglichen, habe ich vor einiger Zeit den Fall -0 programmiert.
• Damit man nicht mehrere Aufrufe mittels #invoke benötigt, habe ich Anfang des Jahres der round-Funktion durch zwei zusätzliche Parameter ermöglicht, deren Ergebnis gleich mit den Funktionen format und padding weiterzuverarbeiten.
  • Weitere Basteleien an der Funktion round sind absolut nicht erforderlich und machen die Sache nur unverhältnismäßig kompliziert und fehleranfällig; sowohl in der Programmierung wie auch in der sachgerechten Benutzung.

VG --PerfektesChaos 19:10, 20. Nov. 2016 (CET)

Ok, das klingt überzeugend. Ich nehme die Kritik weiter oben zurück. Es ist auch nicht so tragisch, denn es soll ja, wie du selbst schreibst, schließlich nachbearbeitet werden. Zweifelsfrei etwas für Infoboxen etc. und nur im Ausnahmefall etwas für den Fließtext. ÅñŧóñŜûŝî (Ð) 19:17, 24. Nov. 2016 (CET)

Leerzeichen nicht geschützt

@PerfektesChaos: Obwohl im Modul-Quelltext mit THIN_SPACE = mw.ustring.char( 8239 ) das Unicode-Zeichen für einen kleines geschütztes Leerzeichen verwendet wird, macht die mit FormatNum formatierte Zahl 111 222 333 444 555 666 777 888 999 000 einen Zeilenumbruch bei den Leerzeichen, während bei direkter Verwendung von 8239 im Artikel-Quelltext dies nicht passiert: 111 222 333 444 555 666 777 888 999 000 Woran liegt dies? --Nov3rd17 (Diskussion) 13:19, 6. Mai 2018 (CEST)

Weiß ich auch grad nicht, wird aber morgen vormittag wieder robust laufen. Es gab letzten Dezember eine Änderung der Wiki-Server-Textverdauung, die einiges in dem Bereich mächtig durchgeschüttelt hat. Vorher ging es fünf Jahre. Danke für den Hinweis --PerfektesChaos 14:12, 6. Mai 2018 (CEST)

Führende Nullen entfernen

Führende Nullen im Eingangswert sollten vor der Formatierung entfernt werden, vgl. {{FormatNum|00002.4}} → 00.002,4. Mir fällt jedenfalls spontan kein Fall ein, in dem das aktuelle Verhalten einen Sinn ergeben würde. Manche Metadatenvorlagen füllen leere Tausenderstellen mit Nullen auf und werden dann falsch formatiert. Gruß, -- hgzh 18:38, 4. Nov. 2020 (CET)

• Kann ich mir gern anschauen. Da es aber eine hochfrequent eingebundene Geschichte ist bedarf jede Veränderung vorheriger gründlicher Erprobung auf BETA, wo die Mutterversion residiert, auch hinsichtlich nicht offenkundiger Nebenwirkungen.
• Wobei sich mir zuallererst die Frage stellt, welcher Gipskopf denn in Metadaten sinnlose Nullen voranstellt. Während die von dir gewünschte Veränderung die Performance für sämtliche Einbindungen einen Tic verschlechtert und seit 2013 niemals erforderlich gewesen war, wäre mein erster Ansatzpunkt dass gezielt diejenige Metadaten-Funktion, die mit sinnlosen Nullen daherkommt, entweder in ihren Grunddaten bereinigt würde oder aber diese und nur diese eine individuelle Vorformatierung vornimmt, nur deren eigene Performance schädigt und der Rest der Menschheit nicht belästigt wird.
• Dieses Modul hier war die erste saubere produktive Bibliothek mit großmaßstäblicher Anwendung bei der Einführung von Lua 2013, ist aber selbst in die Jahre gekommen und bei mir als Sanierungsfall vorgemerkt.
• Wobei wir eine Müllhalde an Bastelarbeiten aus den Jahren um 2005 herumzuliegen haben, die entrümpelt und vereinfacht und vereinheitlicht gehört. Das wäre in eine anstehende Grundsanierung einzubeziehen. Sowas fängt an mit der seit 2012 obsoleten Vorlage:nts und ihrer teils sinnfreien und andere Tabellenzellen störenden Einbindung, teils intern eine private Zahlenformatierungsfunktion in Konkurrenz zu diesem Modul hier ausübenden Darstellung.
• Problem dabei ist, dass die an die Hacks von 2005 gewöhnten Leutchen jeglicher Modernisierung und Vereinfachung erheblichen Widerstand entgegensetzen.
• Neuere und moderne Techniken würden auf Vorlage:ZahlZelle zurückgreifen, die auch führende Nullen eliminert (jage 007) und perspektivisch völlig anders vorgeht.
• Jede Sanierungsarbeit dieser Art kostet mich ein halbes bis ein ganzes oder mehrere Wikijahre. Zurzeit bin ich seit Frühjahr noch damit beschäftigt, die Tabellensortierung zu sanieren; eines der nächsten Projekte auf der Agenda wäre die Entrümpelung des überkommenen Dschungels an Datumsformaten (was bereits begonnen hat), dann habe ich Zitationen, Weblinks und als mehrjährige Schwerpunktaufgabe Kategoriesortierung auf der Agenda. Leider ist unser Personalbestand an Leuten, die sauber und ohne zu pfuschen robuste und einfache und wartungsfähige Software schreiben können, extrem begrenzt.

VG --PerfektesChaos 20:59, 4. Nov. 2020 (CET)

Aufgefallen war es bei österreichischen Flächenmetadaten, ob es noch weitere Fälle hier gibt, keine Ahnung. Dass in externen Datenquellen alle gleichartigen Werte auf die selbe Vorkommastellenanzahl gebracht werden, habe ich allerdings schon häufiger gesehen. -- hgzh 09:31, 5. Nov. 2020 (CET)

• Ich habe es mir die Nacht über durchgeknetet und verdaut.
• Wir haben gerade Trubel, weil schließende Nullen in den Darstellungen weggelassen werden, obwohl Benutzer sie unbedingt sehen wollen und wir sie unbedingt anzeigen sollen.
• Wenn ein Benutzer mit einer Zahl ankommt, die aus irgendwelchen Gründen führende Nullen enthält, dann bekommt er das [bis auf Weiteres] auch so angezeigt; zumindest mit den Bestandsfunktionen. Wem das nicht gefällt, der kann sinnfreie Nullen aus seinen Metadaten-Seiten entfernen oder auf eigene Kosten einen privaten Filter vor seine eigene Anwendung schalten.
• Dieses Modul wird auch global verteilt, und mögliche Auswirkungen einer Veränderung sind nicht absehbar. Zu Gunsten des Bestandsschutzes soll das Verhalten einer seit 2013 unverändert wirksamen Formatierung nicht verändert werden. Eine Notwendigkeit für diesen Eingriff besteht nicht. Ansonsten kommt immer hinterher irgendwer um die Ecke und schreit Zeter und Mordio, weil in seinem Fachgebiet oder seiner Anwendung genau diese Nullen irgendwas Wichtiges signalisieren; vielleicht eher Schlüssel als numerischer Wert wären.
• Die Parserfunktion {{formatnum:007}} → 007 behält die führenden Nullen auch bei; das Modul soll deren Verhalten nachahmen und nur situativ verbessern (keine Gliederungspunkte bei Zahlen von 1000 bis 9999, andere [CH] Gliederungszeichen für Tausender). Alle vom Anwender gelieferten Ziffern bleiben unbeeinflusst; einschließlich schließender und führender Nullen.
• Die Leutchen mit österreichischen Flächenmetadaten müssen dann halt zukünftig vor dem Abspeichern ihre Daten um einige KB sinnfreie Nullen erleichtern. Jede Null, die bei jedem Seitenaufbau vom System transportiert werden muss, kostet eine Nanosekunde; jeder Funktionsaufruf zum Trimmen kostet eine Millisekunde. Dies ginge zu Lasten aller Millionen und Abermillionen der Aufrufe des hiesigen Moduls, weil ein einziger Benutzer auf einer oder gelegentlich mal einer anderen Seite seine Daten im Rohformat abkippt. Wenn schon Funktionsaufruf, dann dort und nur dort wo der Verursacher sitzt.
• Das war auch schon immer so gewesen; ich wüsste nicht, dass wir vor Vorlage:ZahlZelle jemals eine Standardfunktion angeboten hätten, die solche Nullen trimmt, sieht man von {{#expr:007}} → 7 ab. Wir bündeln wohl seit einem Dutzend Jahren Metadaten, und alle anderen haben es bisher immer hinbekommen, dass es keine solchen Probleme gibt.

VG --PerfektesChaos 17:32, 5. Nov. 2020 (CET)

Ok, habe nun die Metadatenvorlagen angepasst. Damit hier erledigt. -- hgzh 19:44, 6. Dez. 2020 (CET)

Minuszeichen

Hallo, spricht irgendetwas dagegen, dass das Modul beim Format-Aufruf bei negativen Zahlen ein korrektes Minuszeichen ausgibt anstatt des Bindestrichs? Test: −1,234 vs. −1,234. Hintergrund: Benutzer_Diskussion:Aka#Bearbeitungsfehler. -- Gruß, aka 10:12, 18. Jan. 2021 (CET)

Ja, weil bereits seit acht Jahren genau so definiert und jede Änderung in unvorhersehbarer Weise andere Verwendungen brechen kann.

• Es könnte in andere Parameter oder Bezeichner oder Seitennamen oder URL oder Grafiken oder sonstwas eingehen.
• Wir haben seit immer für uns eine reine ASCII-Zeichenkette durch die genannte Funktion zurückgegeben.
• Insbesondere #expr käme mit Typografie bei den Eingabeformaten nicht klar.
• Genauso kämen heutzutage Gültigkeitsprüfungen in Frage, die früher nicht so üblich gewesen waren.

Es gibt auch schon seit ewig eine Minuszeichen-Funktion zur Umwandlung in der Darstellung.

• Wer Typografie haben möchte, der kann das in seiner Programmierung im allerletzten Schritt zur Präsentation anwenden.

Wir geben Vorlagenparameter im computerkompatiblen Format an; also Punkt als Dezimaltrennzeichen, ASCII-Strich-Minus, keine Tausendertrennung.

• So auch in der verlinkten Diff.
• Erst im letzten Schritt unmittelbar zur Präsentation wird umdekoriert, mit Komma und Typografie und Zahlengliederung.
• Das ist in diesem Fall Aufgabe der Infobox Stern, während sie intern und mit möglichen Untervorlagen noch nach Lust und Laune rechnen darf, oder Sortierschlüssel oder Kategorisierungen oder Zeichenkettenanalysen bilden darf.
• Wenn etwas zu ändern wäre, dann müsste die Infobox-Programmierung zentral für alle Artikel die präsentierte Darstellung ändern.
• Auch für den Export nach außen halten wir die Vorlagenparameter konsistent im computerkompatiblen Format, um bei der Auswertung der Parameter keine Überraschungen zu erleben.
• Nicht zuletzt lassen sich damit die Parameterwerte trivial über jede Tastatur und selbst mit Smartphone-Daumen eingeben. Das gilt insbesondere für die von mehreren Werkzeugen angebotenen Formulare zum Ausfüllen von Vorlagen, die keine typografischen Minuszeichen unterstützen.
• Internationaler Austausch oder Nutzung durch andere Vorlagen sowie Bots und Skripte sind auf ein simples Einheitsformat der Quelltext-Daten ohne Extraschnörkel angewiesen.

Perspektivisch kann ich bei der angefragten Modulfunktion über die Einführung eines neuen Optionsparameters minus=1 nachdenken, der die Bestandseinbindungen in Frieden lässt und bei expliziter zukünftiger Angabe in den gewünschten Einzelfällen die Zeichenumwandlung in dafür geeigneter Situation im selben Aufruf und damit ressourcenschonend vornimmt.

• Dies muss dann aber durch round durchgeschleift werden, weil sie sich ebenfalls verkettet in einem einzigen Modulaufruf ausführen lassen.

VG --PerfektesChaos 15:29, 18. Jan. 2021 (CET)

"Nicht zuletzt lassen sich damit die Parameterwerte trivial über jede Tastatur und selbst mit Smartphone-Daumen eingeben" halte ich für Quatsch und es gibt vermutlich Millionen Gegenbeispiele. Mit diesem Argument (und der Hälfte deiner anderen) kannst du jede sinnvolle Typographie aushebeln und bist wieder bei der Schreibmaschine. Auch "Bots und Scripte" müssen einfach mit den richtigen Angaben klarkommen - wir sind hier keine Datenbank und auch nicht bei Wikidata. Warum jemand mit dem Ergebnis von FormatNum noch irgendwie mit #expr rechnen sollte, erscheint mir auch nicht so logisch. Naja, ich baue dann eben noch die Minus-Funktion in die Vorlage ein - das geht schon auch, ist halt nur umständlich, weil das dann eigentlich in jede Vorlage muss, die FormatNum verwendet. Meine Meinung bleibt: das gehört direkt in die Vorlage. -- aka 15:46, 18. Jan. 2021 (CET)

Die typografische Darstellung gehört in diejenige Vorlage, die die Präsentation für die Leser vornimmt, und das ist Infobox Stern.

• Und nur dorthin.

Wir werten die Parameter in den Einbindungen systematisch aus, exportieren sie, laden sie herunter, sortieren sie in externen Systemen, führen extern Berechnungen damit aus, prüfen auf Gültigkeit, bearbeiten sie mit Bots und Skripten, tauschen sie mit anderen Vorlagen und anderen Wikis aus.

• Wenn die Werte in den Einbindungen alle möglichen Formate annehmen, dann wird es für alle weiteren nachfolgenden Vorgänge zerschossen.
• Das gilt auch für eine Suche nach Eingabewerten, die bestimmte Bedingungen erfüllen; auch diese werden dadurch unnötig verkompliziert, oder es werden bestimmte Treffer nicht gefunden, weil die Suchenden nur nach dem ASCII-Zeichen gesucht hatten.
• Für alle zusätzlichen Wartungs-, Pflege- und weiterverarbeitenden Vorgänge wird das Leben unnötig verkompliziert, wenn die Werte in den Einbindungen tausenderlei Formatierungen annehmen können. Wir nehmen deshalb die Wertangabe im Quelltext in einem möglichst einfachen und einheitlichem Format vor, das auch alle eingeben können.
• Als Wert in die Einbindung gehört einheitlich nur ASCII, Dezimalzeichen ist der Punkt; alle Präsentationsaufgaben sind Aufgabe der präsentierenden Vorlage.

VG --PerfektesChaos 16:13, 18. Jan. 2021 (CET)

Ja, deine Meinung kenne ich ja nun - ich sehe das trotzdem anders und die Praxis auch. Ein betroffener Artikel war Eta Geminorum - guck doch mal, was da sonst für Zeichen in den Parametern vorkommen. Selbst das Minuszeichen ist bei anderen Parametern dabei ;-) Und eigentlich ging es mir auch gar nicht um die Art, wie man die Werte angibt (da würde ich auch nicht alles von dir gesagte unwidersprochen lassen, das führt jetzt aber zu weit), sondern um die Art, wie sie am Ende dargestellt werden. Und zumindest für den Leser sollte dort ein richtiges Minuszeichen schon möglich sein. -- Gruß, aka 16:28, 18. Jan. 2021 (CET)

Es ist Vorlage:Infobox Stern, die ganz zum Schluss dafür verantwortlich ist, dass die Darstellung für die Leser ansprechend formatiert wird.

Es ist völliger Unsinn, in den 1132 Einbindungen dieser Infobox jedes Mal wie kürzlich in Eta Geminorum händisch drei Vorlagenparameter von ASCII auf typografisch umzustellen.

Es ist auch völlig egal, was momentan in irgendwelchen anderen Parameterwerten rumstand. Ziel ist, dass die Einbindungen durchgängig ASCII verwenden, damit sie leicht eingegeben und einheitlich ausgewertet und einheitlich sortiert werden können. Ggf. ist deshalb in Richtung der ASCII-Zeichen zu wirken. Nur damit sind auch weitere Berechnungen und Vergleiche und Weiterverarbeitung möglich.

Genau deshalb steht in der Einbindung auch der computergerechte Punkt als Dezimaltrennzeichen und kein Komma, wie es hinterher in der Schlusspräsentation für die Leser zu formatieren ist.

VG --PerfektesChaos 19:22, 18. Jan. 2021 (CET)

Du bringst schon wieder alles durcheinander, das aber schön strukturiert. Wir lassen einfach die Frage einmal außen vor, wie die Daten in der Infobox angegeben werden sollten. Vor meiner - in bester Absicht durchgeführten - Änderung wusste ich nicht, dass es auch diese Bestrebung gibt, diese Daten möglichst einfach auswertbar zu halten, zu Ungunsten des Erstellers, der dann beispielsweise im Fließtext Zahlen anders angeben muss als in der Vorlage. Das kann man sicher so sehen, auch wenn ich anderer Meinung bin. Meine Frage war doch nur, ob FormatNum gleich ein richtiges Minuszeichen ausgeben könnte. Und du willst das nicht aus Angst, es könnte etwas kaputtgehen. Dann ist das eben so. Man. -- aka 19:31, 18. Jan. 2021 (CET)

Nur für's Protokoll. Ich unterstütze Akas Änderung der Vorlage. Zum einen, weil damit wieder Konsistenz zur Ausgabe der Parserfunktion formatnum: hergestellt wird, die seit kurzem ja auch ein Minuszeichen ausgibt, zum anderen halte ich es auch für sinnvoll, dass eine Vorlage FormatNum eine korrekt formatierte Zahl ausgibt. Wer mit diesen formatierten Werten anderswo weiterarbeitet, hat eher die Vorlage falsch verwendet.

Das Problem bei der Stern-Vorlage und einigen anderen Astro-Vorlagen ist eher, dass Zahlenwerte mitunter innerhalb der Vorlage verschieden erwartet werden oder Text eingetragen wird (ähnlich auch bei Vorlage:Infobox Schiff), sodass am Ende niemand mehr durchsieht und eine vernünftige Konvertierung gar nicht möglich ist. Solche Seiten sammel(te)n sich dann fröhlich in der Kategorie:Wikipedia:Seite mit nicht-numerischem formatnum-Argument. Gruß, -- hgzh 11:02, 20. Jan. 2021 (CET)

• Das umseitig ist ein globales Modul.
  • Es wird in einem Dutzend Wikis eingesetzt.
  • Allein bei uns hat es eine Viertelmillion Einbindungen.
  • Da gibt es keinerlei disruptive Veränderung einer langjährig eingeführten korrekten Funktionalität.
  • Die Auswirkungen sind unübersehbar.
• Ich habe bereits auf der Festplatte eine Nachfolgeprogrammierung, die auf explizite Anforderung ein typografisches Minuszeichen bewirkt.
  • Ich habe aber diesen Monat und unter Lockdown-Organisation keine Zeit, das beschleunigt einzuführen.
  • Es gibt auch keinerlei angeblichen Fehler oder großes Problem, das jetzt dringend repariert werden müsste.
  • Änderungen an derartigen produktiven Programmierungen erfolgen nicht spontan, sondern werden zuvor auf BETA an einer Testsuite erprobt und hinterfragt.
• Die Bestandsprogrammierung der umseitigen Modulfunktion reicht ein vorgegebenes Vorzeichen, egal ob typografisch Minus oder Plus oder ASCII-Strich unverändert und unbeanstandet durch.
• Die Astros hinterlegen ihre sämtlichen Daten in allen ihren Vorlagen im für Berechnungen geeigneten Format, mit Punkt als Dezimaltrenner, ohne Tausendergruppierung, mit ASCII-Strich.
  • Damit können sie Auswertungen herunterladen, extern Berechnungen ausführen, Werte suchen, in andere Wikis exportieren, intern mit #expr rechnen oder was immer.
  • Das gilt unabhängig davon, ob durch C&P in einzelne Vorlageneinbindungen mal typografisch Minus oder ein Komma oder sonstwas verschleppt sein mag.
  • Das gilt auch unabhängig davon, ob die Astros in allen ihren Vorlagendokus explizit das zulässige Format angegeben haben.
• Zuständig für die Präsentation zum Schluss für die Leser ist ausschließlich die Vorlage:Infobox Stern.
  • Das gilt unabhängig davon, ob sie dies bereits jetzt im Moment ordnungsgemäß macht.
  • Es wäre dort mit genau einem Edit zentral für sämtliche Artikel zu bewerkstelligen.
• Pfuscherei in Bestandsprogrammierungen anderer Vorlagen wird nicht dadurch entgegengewirkt, dass man ins Blaue hinein noch größere Pfuscherei in Bibliotheksfunktionen und Einbindungen anrichtet.
  • Ziel muss es sein, alle Vorlagen in Richtung einer sauberen Programmierung, Dokumentation und Präsentation zu bringen; nicht aber, Pfusch im Altbestand durch Gegenpfusch zu beantworten mit nicht mehr vorhersehbarem und nicht mehr verständlichem Verhalten beim Zusammenwirken und Durchreichen und Berechnen und Exportieren und Importieren und Vergleichen.
• Veränderungen an Bibliotheksfunktionen, die in andere Programmierungen und Darstellungen hineinwirken, erfolgen nur selten, ändern in der Regel nie die Bestandsfunktionalität, und werden dann (wenn überhaupt) nicht spontan und ohne vorherige mehrwöchige Ankündigung auf der Diskussionsseite mal so eben im Alleingang aus dem Handgelenk reingedrückt.
  • Wenn eine Veränderung der Bestandsfunktionalität bewirkt werden soll, dann muss auch ein konkreter und präziser Migrationsplan in der Diskussion vorgelegt werden, wie die Bestandstexte robust und sicher auf neue Funktionalitäten umgestellt werden sollen.
  • Insofern sind wir hier auf der Diskussionsseite zum Modul ja genau richtig.

VG --PerfektesChaos 15:37, 20. Jan. 2021 (CET)

• • • Was es das Minuszeichen angeht: Das ist am Besten in der Infobox am dort erstellten String zu erledigen. Da braucht man weder am Modul noch an der Formatvorlage herumzufummeln. Es hat darüber hinaus auch den Vorteil, dass auch Zeichenketten wie (-123,45 ± 45) richtig umgeformt werden. ÅñŧóñŜûŝî (Ð) 19:29, 20. Jan. 2021 (CET)

Nur zur Klarstellung, ich hatte nie eine stante-pede-Änderung des Moduls gefordert oder befürwortet, lediglich die Änderung der Vorlage:FormatNumDef, die meiner Ansicht nach nur korrekt zur Endformatierung eingesetzt werden kann („ganz zum Schluss dafür verantwortlich [ist], dass die Darstellung für die Leser ansprechend formatiert wird“) – wären durch die Umstellung hier Fehler entstanden, wäre das kein Problem der Änderung an sich, sondern die Vorlage wäre sowieso schon falsch verwendet worden.

Was die Astrovorlagen angeht, mag das über meine bescheidenen Kenntnisse in diesem Bereich hinausgehen, aber wenn ich mir den Quelltext von Alphard anschaue, bekomme ich schon den Eindruck, dass hier nicht wirklich eine konsequente Notation verfolgt wird (oder verfolgt werden kann). Aber dafür sind wir hier nicht richtig ;) -- hgzh 12:41, 21. Jan. 2021 (CET)

Missing Feature: Nachfolgende Nullen sicherstellen

Die Funktion round gibt nachfolgende Nullen (Nachkommastellen) nur aus, wenn der erste Parameter genügend nachfolgende Nullen liefert. Das ist bei einem Expr-Ergebnis aber nicht der Fall. Ich würde es daher begrüßen, wenn man mit einem weiteren Parameterwert, beispielsweise format=! dies explizit sicherstellen könnte. Egal, ob der erste Parameter 321, 321.1, 321.10 oder 321.100 lautet, sollte bei dieser Option mit

{{#invoke:FormatNum|round|..|3|format=!}}

immer 321.100 zurückgegeben werden. Selbstverständlich muss man den Rückgabewert dann als String behandeln, also z. B.

{{Str_replace|{{#invoke:FormatNum|round|..|3|format=!}}|.|,}}

für das Dezimalkomma (evtl. integrierbar?). ÅñŧóñŜûŝî (Ð) 22:01, 22. Mär. 2021 (CET)

Falsche Angabe der Nachkommastellen

Die Tabelle im Artikel Dänemark #Verwaltungsgliederung gibt für jede Region des Landes die Einwohnerzahl, die Fläche und die Bevölkerungsdichte an. Die ersten beiden Zahlen werden aus einer externen Datei abgerufen, die dritte wird als Quotient der ersten beiden berechnet. Alle drei Zahlen werden mit der Vorlage:formatnum dargestellt. Obwohl bei allen Bevölkerungsdichten der Parameter „round 1“ gesetzt ist, wird die Bevölkerungsdichte der Region Hovedstaden ohne Nachkommastelle als 725 angegeben. Der exaktere Wert lautet 724,954; gerundet auf eine Nachkommastelle müsste er also 725,0 lauten.
Letzte Nachkommaziffern, die gleich 0 sind, dürfen nicht weggelassen werden:

• Dadurch wird die rechtsbündige Anordnung der Zahlen in einer Tabellenspalte gestört.
• Es wird eine geringere Genauigkeit als bei anderen gleichartigen Zahlen in der Tabelle vorgetäuscht.
• Es ist eine numerische Verfälschung der Realzahl; 725,0 kann jede Zahl zwischen 724,95 und 725,05 bedeuten; 725 kann dagegen jede Zahl zwischen 724,5 und 725,5 bedeuten.

Ich bitte darum, diesen Fehler zu beheben. --BurghardRichter (Diskussion) 03:48, 19. Feb. 2022 (CET)

1. formatnum ist keine „Vorlage“, sondern eine Parserfunktion.
   • Wenn du in deiner Abschnittseröffnung die Vorlage:formatnum verlinkt hättest, wäre dir das aufgefallen.
   • Für Parserfunktionen sind Module unzuständig.
2. Hier gibt es keine „Falsche Angabe“, zumindest nicht solange dieses Modul betroffen ist.
   • Dieses Modul macht exakt das, was es machen soll, und das schon seit 2013, und in den Zeiten zuvor war es mutmaßlich auch schon so seit ca. 2006/2007.
   • Es ist nebenbei bemerkt unser ältestes weil allererstes produktives.
3. Dieses Modul erfindet keine signifikanten Stellen hinzu, die in der Eingabe nicht vorhanden sind. Grundsätzlich nicht.
   • Wenn du zur Formatierung die von dir behaupteten 724,954 verwendet hättest, dann würdest du dies bei Anforderung von einer Nachkommastelle auch als 725,0 erhalten haben.
   • Sofern das in Rede stehende Modul beteiligt war, hätte die Eingabe 725 gelautet. Wo es keine signifikante Nachkommastellen gab, erfindet dieses Modul auch keine nichtexistenten signifikanten Stellen hinzu, aus genau den von dir angeführten Gründen.

VG --PerfektesChaos 09:45, 19. Feb. 2022 (CET)

Eine so unverständliche und nutzlose Antwort habe ich noch nie auf eine Systemanfrage erhalten. Sie hilft mir bzw. dem Artikel Dänemark kein bisschen weiter.

Der Artikel enthält im Abschnitt Dänemark #Verwaltungsgliederung eine Tabelle der Regionen mit Angaben der Einwohnerzahl, der Fläche und der Bevölkerungsdichte. Die Bevölkerungsdichte ist durchweg mit einer Nachkommastelle angegeben, nur bei einer Region steht sie ohne Nachkommastelle (also als Integerzahl) als 725. Um den Fehler aufzuklären und wenn möglich zu beheben, sah ich in die Quelldatei. Dort wird die Zahl erzeugt durch {{formatnum: {{#expr: ( {{Metadaten Einwohnerzahl DK|DK-84}} / {{Metadaten Fläche DK|084}} ) round 1 }} }} Anscheinend ist die Angabe round 1 für die Zahl der Nachkommastellen massgeblich; wenn ich die 1 durch eine 2 oder 3 ersetze, funktioniert es auch richtig; nur bei 1 erscheint fälschlich gar keine Nachkommaziffer anstatt der richtigen 0.

Ausdrücke in doppelten geschweiften Klammern kenne ich als Vorlagen. Eine Vorlage:formatnum scheint es aber nicht zu geben. In der unterhalb des Bearbeitungsfensters aufgeführten Aufzählung der von dem Artikel verwendeten Vorlagen fand ich aber Vorlage:FormatNum und Modul:FormatNum. Was ein Modul ist, weiss ich nicht. Bei beidem führte der Aufruf der zugehörigen Diskussionsseite auf diese Seite. Also habe ich hier das Problem dargestellt und um Abhilfe gebeten. Und dann bekam ich eine solche Antwort! Was dieses Modul im einzelnen macht, weiss ich nicht, und ich weiss auch nicht, was eine Parserfunktion ist (und ich habe auch nicht vor, das für meine Wikipedia-Arbeit zu lernen). Es kann ja sein, dass die Ursache des Fehlers an anderer Stelle liegt; dann muss er eben dort behoben werden. Aber ich kann das nicht herausfinden.

So muss dann eben der Fehler, der mir aufgefallen ist, in dem Artikel bleiben, und an Hunderten anderer Stellen vermutlich genauso. Ich habe getan, was ich konnte, um auf eine Behebung hinzuwirken. Aber wo kein Wille ist, ist auch kein Weg. --BurghardRichter (Diskussion) 21:50, 19. Feb. 2022 (CET)

Du müsstest dich an die Programmierer dänischer Bevölkerungsstatistiken wenden.

Hier bist du dann schlicht falsch.

Weil du per Abschnittsüberschrift bereits entschieden hattest, das umseitig dokumentierte Modul würde angeblich falsche Resultate liefern – nein, macht es nicht.

• Dein Begehren würde darauf hinauslaufen, dass bei einer Angabe ≈1 Meter und einer vorgegebenen Rundung von 2 entsprechend der maximalen Anzahl der Nachkommastellen eine Darstellung ≈1,00 Meter produziert wird.
• Das wäre aber genau diejenige Produktion und Vortäuschung einer Scheingenauigkeit, welche die Eingabedaten überhaupt nicht hergeben, und die du selbst beanstandest.
• In der Test- und Beispielseite findest du unter den Suchtreffern 567 und 1.400 exakt das erwartete und vorgesehene Verhalten dieses Moduls, je nach Eingabewerten.

Wenn du dich an die Betreuung eines Moduls wendest und behauptest, es würde angeblich „falsche Angaben“ liefern und das Modul müsse jetzt korrigiert werden, dann musst du dir auch sicher sein, dass dieses Modul für dein Problem verantwortlich ist.

• Wenn du hingegen nicht zwischen Parserfunktion, Vorlage und Modul unterscheiden kannst, dann kannst du auch kaum Zuweisungen vornehmen, wer angeblich für dein Problem verantwortlich sein soll.
• Hier geht es um die Pflege des umseitig dokumentierten Moduls, hier ist keine allgemeine Auskunftsplattform, insbesondere nicht für Programmierfehler in dänischen Bevölkerungsstatistiken.
• Mal abgesehen davon haben im Quelltext enzyklopädischer Artikel solche fortgeschrittenen Berechnungsfunktionen überhaupt nichts verloren. Das müsstest du dann schon auf der Artikeldiskussionsseite zu Dänemark mit den dortigen Verursachern abkaschpern.

VG --PerfektesChaos 22:52, 19. Feb. 2022 (CET)

Okay, vielen Dank, auch für deine Geduld!

Allerdings: Nein, an der dänischen Statistikbehörde kann es nicht liegen. Von der werden nur die Ausgangsdaten (Einwohnerzahl und Fläche) abgerufen; daraus wird, wenn ich es richtig verstehe, hier bei uns (korrekter gesagt, wohl auf dem Rechner dessen, der den Artikel liest) mit der Funktion, die ich oben aus der Quelldatei zitiert habe, die Bevölkerungsdichte als Quotient berechnet und in der vorgegebenen Form ausgegeben.

Und nein, selbstverständlich wird kein vernünftiger Mensch „≈ [x] Meter“ schreiben, wenn [x] eine natürliche (also Integer-) Zahl ist, die gemäss Formatierungsangabe mit zwei Stellen nach dem Komma ausgegeben werden soll; aber natürlich kann es auch Näherungsangaben mit einer bestimmten Zahl von Nachkommastellen geben. Ich bin es von meiner Fortran-Programmierung seit fast 50 Jahren gewöhnt, dass ich entscheide, in welchem Format eine Zahl ausgegeben werden soll, und dass der Rechner die Zahl dann auch exakt so auf den Drucker oder den Bildschirm leitet, wie ich es programmiert habe. Und selbst mein HP-Taschenrechner zeigt alle Zahlen exakt mit der von mir festgelegten Stellenzahl an. Hier in der Wikipedia erlebe ich dagegen, dass das in der Quelltext-Anweisung enthaltene Programm zwar eine bestimmte Anzahl von Nachkomma-Stellen vorschreibt und das System dann aber eigenmächtig die letzten Ziffern weglässt, wenn diese zufälligerweise gleich 0 sind. Und es ist anscheinend unmöglich herauszufinden, welches Systemelement für diesen Unsinn verantwortlich ist. Das ist eine Ungeheuerlichkeit, die ich einfach nicht fassen kann: Der Anwender, d.h. der Ersteller der Quelldatei, kann zwar eine Vorgabe machen, wie eine Zahl formatiert werden soll; aber das System entscheidet dann selbst nach unsinnigen Kriterien, ob es sich an die Vorgabe hält oder nicht, und der Anwender steht dem machtlos gegenüber. Da kann ich nur den Kopf schütteln.

Entschuldige bitte, dass ich dich damit behellige – als ich den ersten Beitrag oben schrieb, wusste ich nicht, dass ich damit an dich geraten würde. Natürlich ist mir klar, dass du nicht für all die Missstände hier verantwortlich bist, sondern – ganz im Gegenteil – selbst am meisten damit zu kämpfen hast und dabei mit Sicherheit viel mehr Frustration erlebst als ich oder andere Benutzer der Wikipedia. Ich weiss das zu schätzen und bin dir sehr dankbar für deinen selbstlosen Einsatz für die Wikipedia. --BurghardRichter (Diskussion) (ohne (gültigen) Zeitstempel signierter Beitrag von BurghardRichter (Diskussion | Beiträge) 00:17, 20. Feb. 2022 (CET))

Einfache Fehlermeldung ohne weitere Analyse

Bitte um Behebung.

• {{FormatNumDef|0.00015|3=km²}} = 0,000.15 km² (aus https://de.wikipedia.org/w/index.php?title=Formiche_di_Grosseto&oldid=229182591)  Nein
• {{FormatNumDef|0.0015|3=km²}} = 0,001.5 km²  Nein
• {{FormatNumDef|0.015|3=km²}} = 0,015 km²  Ja
• {{FormatNumDef|15000000|3=km²}} = 15.000.000 km²  Ja

lg --Herzi Pinki (Diskussion) 19:29, 25. Dez. 2022 (CET)

@Antonsusi, PerfektesChaos: zur Sicherheit. lg --Herzi Pinki (Diskussion) 09:35, 26. Dez. 2022 (CET)

1. Ich habe nicht verstanden, was du überhaupt für ein Problem mitteilen möchtest.
2. Du beschwerst dich über irgendwas mit der Vorlage:FormatNumDef.
   • Die Vorlage:FormatNumDef hat eine eigenständige nicht-triviale Programmierung.
   • Probleme mit deren Funktionalität sind auf deren eigener Diskussionsseite mit den dort Verantwortlichen zu erörtern.
3. Diese Diskussionsseite hier betrifft ausschließich die Lua-Programmierung des Moduls und die Dokumentation der unmittelbaren Funktionalität des Moduls und ist an Programmierer gerichtet, nicht an Autoren bei Erstellung enzyklopädischer Artikel.
4. Das Modul kennt keine „Fehlermeldung“, keine „Einfache Fehlermeldung“ und keine „weitere Analyse“.
5. Wer Gültigkeitsprüfungen von Vorlagenparametern vornehmen und kommunizieren möchte, ist dafür selbst verantwortlich.

Hier unzuständig und damit erledigt. VG --PerfektesChaos 10:00, 26. Dez. 2022 (CET)

• Vorlage Diskussion:FormatNumDef führt hierher.
• Ohne weitere Analyse habe ich das hierhin geschrieben, in der Hoffnung, dass die Autor*innen von Modul / Vorlage oder was auch immer schon wissen, wo das Implementierungsproblem liegt. Ich habe weder den Vorlagen- noch den Luacode analysiert, um zu verstehen, warum dieses Verhalten auftritt. Probleme dürfen angesprochen werden auch wenn man selbst keine Lösung dafür hat.
• Das Problem in Langform: Komma und Dezimalpunkt in einer Zahl, sollte es sich bei dem Punkt um einen Tausendertrenner handeln, dann fehlen in {{FormatNumDef}} und bei der Modulbeschreibung die Beispiele (habe jetzt die Fußnote gefunden). Das mag irgendeiner Norm entsprechen, die Lesbarkeit von 0,000.15 km² ist mE nicht gegeben.
• Generell: Wie kann ich Fehler zu Modulen melden, wenn nicht hier auf der Disk? (egal ob einfach oder nicht).

Gar nicht so selten fühle ich mich von dir abgeschaselt, lg --Herzi Pinki (Diskussion) 10:49, 26. Dez. 2022 (CET)

3,141.592.653.589.793.238.462.643.383

• Die Darstellung ist beabsichtigt und völlig korrekt.
• Es gibt keinen Fehler, am Modul ist nichts zu beheben.

0,00015 km² sind 150 m² und damit weniger als die Größe eines Tennisfeldes im Einzel; anderthalb Ar oder 0,015 ha.

• Wer sowas unbedingt in Quadratkilometern darstellen will muss mit dem Ergebnis leben.

Wenn dir das Ergebnis der Vorlage nicht gefällt, dann benutze sie halt nicht.

Wenn Vorlagen automatisiert in anderen Vorlagen zur Ergebnisformatierung benutzt werden sollten, dann müssen sie eben selbst Sorge tragen, dass die gewünschte Darstellung herauskommt.

• Es gibt irgendwen, der stellt Flächen <1 km² in Hektar dar, und Flächen <2 ha in m² oder irgendwie sowas.

Dies hier ist die Diskussionsseite zur Lua-Programmierung.

Fragen der Einbindung der Vorlage:FormatNumDef sind auf deren eigener Diskussionsseite mit den dort für die Vorlage und deren Diskussionsseite Verantwortlichen zu erörtern.

Hier nicht zuständig. VG --PerfektesChaos 12:30, 26. Dez. 2022 (CET)