Last modified: 2013-08-01 21:17:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15025, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13025 - New parser function / magic word, for "pretty-printed" numbers
New parser function / magic word, for "pretty-printed" numbers
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 16273 17659 (view as bug list)
Depends on:
Blocks: 8327 10454
  Show dependency treegraph
Reported: 2008-02-15 13:32 UTC by Random832
Modified: 2013-08-01 21:17 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

an example function for the problem (1.37 KB, text/plain)
2008-03-04 21:01 UTC, Carl Fürstenberg

Description Random832 2008-02-15 13:32:50 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.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 &nbsp;×&nbsp;10<sup>{{{3}}}</sup> after the number and uncertainty if present)
Fourth parameter - unit (output &nbsp;{{{4}}} if present)

So, the code
would have markup output of
1.356<span class="digitgroup">392</span><span class="digitgroup">733</span>(30)&nbsp;×&nbsp;10<sup>32</sup>&nbsp;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:

And an overview of the proposal being discussed can be found at:

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.
Comment 1 Random832 2008-02-15 13:37:11 UTC
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.
Comment 2 Random832 2008-02-15 20:00:53 UTC
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.
Comment 3 Greg L 2008-02-16 06:45:52 UTC
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>&nbsp;×&nbsp;10<sup>23</sup>&nbsp;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>&nbsp;×&nbsp;10<sup>50</sup></span>&nbsp;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>&nbsp;kg
Comment 4 Greg L 2008-02-16 06:49:23 UTC
Well, that didn’t work. That first example would appear as follows.

{{delimitnum:1579800.298728}} → 1,579,800.298 728
Comment 5 Random832 2008-02-16 06:49:44 UTC
Right, it delimits to the left of the decimal point with commas. I thought this was implicit in calling it a variant of formatnum.
Comment 6 SJ 2008-03-04 01:35:42 UTC
This is a great idea.  Bravo... 
Comment 8 Carl Fürstenberg 2008-03-04 21:01:28 UTC
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)&nbsp;×&nbsp;10<sup>23</sup>&nbsp;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 9 Carl Fürstenberg 2008-03-04 21:53:08 UTC
Comment on attachment 4694 [details]
an example function for the problem

Comment 10 Greg L 2008-03-08 19:09:29 UTC
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…

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.
Comment 11 Greg L 2008-03-14 22:26:01 UTC
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:
Comment 12 Greg L 2008-03-17 23:01:43 UTC

I’ve moved the proof-checking sandbox to its own separate user page, at…
Comment 13 Greg L 2008-03-20 18:50:02 UTC
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.
Comment 14 Greg L 2008-03-22 01:39:29 UTC
An entirely separate discussion got going on a new venue…

…(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">
Comment 15 Greg L 2008-03-23 00:36:52 UTC

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.
Comment 16 Random832 2008-03-26 04:18:23 UTC
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.
Comment 17 Chad H. 2009-08-25 22:45:15 UTC
*** Bug 16273 has been marked as a duplicate of this bug. ***
Comment 18 Nemo 2009-09-01 21:17:50 UTC
*** Bug 17659 has been marked as a duplicate of this bug. ***
Comment 19 Nemo 2009-09-01 21:26:18 UTC
(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., which obviously follows what the Bureau international des poids et
mesures states: it has an
inconsistent output (as reported in bug 18957#c15): {{formatnum:1234.5678}}
currently gives 1&nbsp;234,5678 instead of 1&nbsp;234,567&nbsp;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.
Comment 20 Greg L 2009-09-01 21:37:49 UTC
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…


…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.
Comment 21 Nemo 2009-09-01 21:52:32 UTC
(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, 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 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.
Comment 22 Nemo 2011-11-29 20:51:52 UTC
Looks like a crazy template implementation has just been adopted on for some things:

Note You need to log in before you can comment on or make changes to this bug.