Last modified: 2013-08-01 21:17:05 UTC
This is a request for a variant on "formatnum:" called "delimitnum:" which will include in its output span tags that can have a margin set on them to enable spaces to visually appear between digit groups to the right of the decimal point while not causing them to be in the resulting string when the number is selected and copied. Each group of three digits, and a final group of two, three, or four digits, following the decimal point, should be output in a <span class="digitgroup"> tag, which should have a default style of .digitgroup { margin-left:0.25em }. Multiple span tags are closed at the end of the number. By "final group of two, three, or four digits", the following is meant: 1.2345 1.234 56 1.234 567 1.234 5678 1.234 567 89 The following additional parameters are also requested, in addition to the value to be formatted in the first parameter: Second parameter - uncertainty (output in parentheses after the number if present) Third parameter - power of ten (output × 10<sup>{{{3}}}</sup> after the number and uncertainty if present) Fourth parameter - unit (output {{{4}}} if present) So, the code {{delimitnum:1.356392733|30|32|Hz}} would have markup output of 1.356<span class="digitgroup">392</span><span class="digitgroup">733</span>(30) × 10<sup>32</sup> Hz and the visual appearance of 1.356 392 733(30) × 10³² Hz Discussion towards consensus for the use of this feature on enwiki can be found at: http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29#Continuing_Discussion.2C_specifically_regarding_latest_nutshell_proposal And an overview of the proposal being discussed can be found at: http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29#Overview The above-linked overview does not go into detail about where the span tags would be closed, and many of the examples provided there are not well-formed markup; I felt that having them surround each individual digit group (rather than all closing at the end of the numeric output, or at the end of the output of the tag) provides the most flexibility for user styles. This choice does not make any difference for the default appearance, as the default style proposed contains only a left margin. The overview also does not propose the 'class="digitgroup"' convention, instead simply showing examples of tags with inline styles. However, it is better practice to use a class and control the specific styles with stylesheets so that users may override this style in their own user css.
Sorry; the statement "Multiple span tags are closed at the end of the number." above is not consistent with my later statement or example output that the span tag should be closed after each digit group. I'd had trouble deciding which to recommend while writing up this bug report.
There needs to be an additional class for digit groups where the digit preceding the group is a "1", so that a different margin width (0.2em by default) can be applied to these.
The parser function delimits on both sides of the decimal marker. Thus, ::: <code><font color ="maroon"><nowiki>{{delimitnum:1579800.298728}}</nowiki></code></font color> → 1,579,800.298<span style="margin-left:0.25em">728</span> :::other examples are… ::: <code><font color ="maroon"><nowiki>{{delimitnum:6.02214179|30|23|kg}}</nowiki></code></font color> → 6.022<span style="margin-left:0.25em">141<span style="margin-left:0.2em">79(30)</span> × 10<sup>23</sup> kg ::: <code><font color ="maroon"><nowiki>{{delimitnum:1.356392733||50|Hz}}</nowiki></code></font color> → 1.356<span style="margin-left:0.25em">392<span style="margin-left:0.25em">733</span> × 10<sup>50</sup></span> Hz ::: <code><font color ="maroon"><nowiki>{{delimitnum:0.45359237|||kg}}</nowiki></code></font color> → 0.453<span style="margin-left:0.25em">592<span style="margin-left:0.25em">37</span> kg
Well, that didn’t work. That first example would appear as follows. {{delimitnum:1579800.298728}} → 1,579,800.298 728
Right, it delimits to the left of the decimal point with commas. I thought this was implicit in calling it a variant of formatnum.
This is a great idea. Bravo...
The overview of the proposal was archived and is now available here: http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29/Archive_94#Grouping_of_digits_after_the_decimal_point_.28next_attempt.29
Created attachment 4694 [details] an example function for the problem Instead of trying to separate the data into different field, I tried to take the approach to parse a given string instead, a test case for this function gave: input: 12,123,4534524.23456 4335 346346 3335(23)*10^23 km output: 121,234,534,524.234<span style="margin-left:0.25em">564</span><span style="margin-left:0.25em">335</span><span style="margin-left:0.25em">346</span><span style="margin-left:0.25em">346</span><span style="margin-left:0.25em">3335</span>(23) × 10<sup>23</sup> km input: .1 output: .1 input: .12 output: .12 input: .123 output: .123 input: .1234 output: .1234 input: .12345 output: .123<span style="margin-left:0.25em">45</span> (span/margins/nbsps converted to spaces for clarity): input: 12,123,4534524.23456 4335 346346 3335(23)*10^23 km output: 121,234,534,524.234 564 335 346 346 3335(23) × 1023 km input: .1 output: .1 input: .12 output: .12 input: .123 output: .123 input: .1234 output: .1234 input: .123 45 output: .123 45
Comment on attachment 4694 [details] an example function for the problem duh
I created a little custom sandbox for the developer on my home page. It features a variety of proof-check exercises for this parser function. It can be helpful for evaluating the proper functioning of various features of this parser function. It is here at… http://en.wikipedia.org/wiki/User:Greg_L#Delimitnum_sandbox I created this proof-check sandbox for another editor who has created a template, also titled "delimitnum", for doing the very same thing as this parser function. Note that I did not solicit this, he kindly took it upon himself to do this on his own.
Discussion regarding a formal MOSNUM policy on the use of this parser function and the template by the same name is ongoing at the following section of Talk:MOSNUM: http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29#.7B.7Bdelimitnum.7D.7D_template
Carl, I’ve moved the proof-checking sandbox to its own separate user page, at… http://en.wikipedia.org/wiki/User:Greg_L/Delimitnum_sandbox
A Wiki editor pointed out that {delimitnum|1.1200|25} should return 1.1200(25), not 1.12(25) I wanted to make sure that no trailing zeros in the significand are truncated if the uncertainty pipe has a value in it.
An entirely separate discussion got going on a new venue… http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style#Exponential_notation …(not Talk:MOSNUM, but Talk:MOS) where spacing on both sides of the × (times) symbol with other templates was being discussed. So far, I’ve been careful to insulate you from changes but I hope you will find this one easy to implement as it is a good idea and will make this magic word a more attractive, widely accepted tool. Could you please put span-based gaps on both sides of the × symbol instead of non-breaking spaces. In order to appear balanced across all platforms, the spans must be asymmetrically specified (0.30 em to the left and 0.15 em to the right), as follows: <span style="margin-left:0.3em">×<span style="margin-left:0.15em">
Carl, I realized something that you may already have figured out on your own. {{delimitnum|1.1200|25||kG}} should return 1.1200(25) kg and {{delimitnum|1.1200|||kg}} should return 1.1200 kg. In other words, regardless of whether the ‘uncertainty’ pipe has a value in it or not, your magic word shouldn't have to ever worry abut truncating trailing zeros under any circumstances. This responsibility must be in the hands of the editors in order that they can control the displayed precision of expressions.
If it would hepl get this done, can we get rid of the other stuff and have it _just_ take the first parameter and put in the commas on the left and the margin spans on the right? The other stuff can be dealt with in a template, or several templates.
*** Bug 16273 has been marked as a duplicate of this bug. ***
*** Bug 17659 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > *** Bug 16273 has been marked as a duplicate of this bug. *** > Then I'll write here: I understand that formatnum is not meant to handle complex situations (see bug 17659#c2) and it is used primarily in user messages where numbers are integers, but I can't understand why where it's configured to use the non-breaking space as separator of groups of digit (e.g. fr.wiki, which obviously follows what the Bureau international des poids et mesures states: http://www.bipm.org/en/si/si_brochure/chapter5/5-3-2.html#5-3-4) it has an inconsistent output (as reported in bug 18957#c15): {{formatnum:1234.5678}} currently gives 1 234,5678 instead of 1 234,567 8. (In reply to comment #16) > The other stuff can be dealt with in a template, or > several templates. Yes. The priority is to resolve the current inconsistencies: bug 17659#c2, bug 8327, bug 10454.
For use on en.Wikipedia, this bug request (“formatnum”) became template:delimitnum and later to the product currently used on en.Wikipedia, which is template:val. {Val} follows the practice widely recognized in the English-speaking world of delimiting numbers to the left of the decimal point with commas and also follows the practice recommended by the U.S. Government Printing Office Style Manual… [http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2008_style_manual&docid=f:chapter12.pdf] …of using narrow gaps to the right of the decimal point. If these latest threads pertain to en.Wikipedia, then the straightforward answer is that the English-speaking countries don't follow the BIPM-recommended practice for delimiting numbers; it follows the real-world practices observed by native-English-speaking readers. If this latest thread is for a tool for fr.Wikipedia, then… “sorry for bothering you.” It wasn’t clear from the above as to where this tool is supposed to be used that you are working on.
(In reply to comment #20) > If this latest thread is for a tool for fr.Wikipedia, then… “sorry for > bothering you.” It wasn’t clear from the above as to where this tool is > supposed to be used that you are working on. I'm from it.wiki, and for complex values we use [[w:it:template:M]] which is the counterpart of [[template:Val]]. I don't think that the original request of this bug is desirable, and I don't want en.wiki to follow international conventions, but I think that we should resolve the inconsistencies of the output of formatnum as it is used currently (i.e. in articles, not only in system messages). Since the requests to correct formatnum itself have been redirected here, I'm requesting that here.
Looks like a crazy template implementation has just been adopted on it.wiki for some things: https://it.wikipedia.org/wiki/Template:Sm
